193 files changed, 0 insertions, 202479 deletions

diff --git a/contrib/bind9/doc/Makefile.in b/contrib/bind9/doc/Makefile.in
deleted file mode 100644
index f307f41..0000000
--- a/contrib/bind9/doc/Makefile.in
+++ /dev/null
@@ -1,29 +0,0 @@
-# Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
-# Copyright (C) 2000, 2001  Internet Software Consortium.
-#
-# Permission to use, copy, modify, and distribute this software for any
-# purpose with or without fee is hereby granted, provided that the above
-# copyright notice and this permission notice appear in all copies.
-#
-# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
-# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
-# AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
-# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
-# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
-# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
-# PERFORMANCE OF THIS SOFTWARE.
-
-# $Id: Makefile.in,v 1.5.18.2 2005/07/23 04:35:12 marka Exp $
-
-# This Makefile is a placeholder.  It exists merely to make
-# sure that its directory gets created in the object directory
-# tree when doing a build using separate object directories.
-
-srcdir =	@srcdir@
-VPATH =		@srcdir@
-top_srcdir =	@top_srcdir@
-
-SUBDIRS = arm misc xsl
-TARGETS =
-
-@BIND9_MAKE_RULES@
diff --git a/contrib/bind9/doc/arm/Bv9ARM-book.xml b/contrib/bind9/doc/arm/Bv9ARM-book.xml
deleted file mode 100644
index e30ca3f..0000000
--- a/contrib/bind9/doc/arm/Bv9ARM-book.xml
+++ /dev/null
@@ -1,12326 +0,0 @@
-<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-               "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
-	       [<!ENTITY mdash "&#8212;">]>
-<!--
- - Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2000-2003  Internet Software Consortium.
- -
- - Permission to use, copy, modify, and/or distribute this software for any
- - purpose with or without fee is hereby granted, provided that the above
- - copyright notice and this permission notice appear in all copies.
- -
- - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
- - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- - PERFORMANCE OF THIS SOFTWARE.
--->
-
-<!-- File: $Id: Bv9ARM-book.xml,v 1.241.18.82 2007/09/26 03:28:27 marka Exp $ -->
-<book xmlns:xi="http://www.w3.org/2001/XInclude">
-  <title>BIND 9 Administrator Reference Manual</title>
-
-  <bookinfo>
-    <copyright>
-      <year>2004</year>
-      <year>2005</year>
-      <year>2006</year>
-      <year>2007</year>
-      <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
-    </copyright>
-    <copyright>
-      <year>2000</year>
-      <year>2001</year>
-      <year>2002</year>
-      <year>2003</year>
-      <holder>Internet Software Consortium.</holder>
-    </copyright>
-  </bookinfo>
-
-  <chapter id="Bv9ARM.ch01">
-    <title>Introduction</title>
-    <para>
-      The Internet Domain Name System (<acronym>DNS</acronym>)
-      consists of the syntax
-      to specify the names of entities in the Internet in a hierarchical
-      manner, the rules used for delegating authority over names, and the
-      system implementation that actually maps names to Internet
-      addresses.  <acronym>DNS</acronym> data is maintained in a
-      group of distributed
-      hierarchical databases.
-    </para>
-
-    <sect1>
-      <title>Scope of Document</title>
-
-      <para>
-        The Berkeley Internet Name Domain
-        (<acronym>BIND</acronym>) implements a
-        domain name server for a number of operating systems. This
-        document provides basic information about the installation and
-        care of the Internet Systems Consortium (<acronym>ISC</acronym>)
-        <acronym>BIND</acronym> version 9 software package for
-        system administrators.
-      </para>
-
-      <para>
-        This version of the manual corresponds to BIND version 9.4.
-      </para>
-
-    </sect1>
-    <sect1>
-      <title>Organization of This Document</title>
-      <para>
-        In this document, <emphasis>Section 1</emphasis> introduces
-        the basic <acronym>DNS</acronym> and <acronym>BIND</acronym> concepts. <emphasis>Section 2</emphasis>
-        describes resource requirements for running <acronym>BIND</acronym> in various
-        environments. Information in <emphasis>Section 3</emphasis> is
-        <emphasis>task-oriented</emphasis> in its presentation and is
-        organized functionally, to aid in the process of installing the
-        <acronym>BIND</acronym> 9 software. The task-oriented
-        section is followed by
-        <emphasis>Section 4</emphasis>, which contains more advanced
-        concepts that the system administrator may need for implementing
-        certain options. <emphasis>Section 5</emphasis>
-        describes the <acronym>BIND</acronym> 9 lightweight
-        resolver.  The contents of <emphasis>Section 6</emphasis> are
-        organized as in a reference manual to aid in the ongoing
-        maintenance of the software. <emphasis>Section 7</emphasis> addresses
-        security considerations, and
-        <emphasis>Section 8</emphasis> contains troubleshooting help. The
-        main body of the document is followed by several
-        <emphasis>appendices</emphasis> which contain useful reference
-        information, such as a <emphasis>bibliography</emphasis> and
-        historic information related to <acronym>BIND</acronym>
-        and the Domain Name
-        System.
-      </para>
-    </sect1>
-    <sect1>
-      <title>Conventions Used in This Document</title>
-
-      <para>
-        In this document, we use the following general typographic
-        conventions:
-      </para>
-
-      <informaltable>
-        <tgroup cols="2">
-          <colspec colname="1" colnum="1" colwidth="3.000in"/>
-          <colspec colname="2" colnum="2" colwidth="2.625in"/>
-          <tbody>
-            <row>
-              <entry colname="1">
-                <para>
-                  <emphasis>To describe:</emphasis>
-                </para>
-              </entry>
-              <entry colname="2">
-                <para>
-                  <emphasis>We use the style:</emphasis>
-                </para>
-              </entry>
-            </row>
-            <row>
-              <entry colname="1">
-                <para>
-                  a pathname, filename, URL, hostname,
-                  mailing list name, or new term or concept
-                </para>
-              </entry>
-              <entry colname="2">
-                <para>
-                  <filename>Fixed width</filename>
-                </para>
-              </entry>
-            </row>
-            <row>
-              <entry colname="1">
-                <para>
-                  literal user
-                  input
-                </para>
-              </entry>
-              <entry colname="2">
-                <para>
-                  <userinput>Fixed Width Bold</userinput>
-                </para>
-              </entry>
-            </row>
-            <row>
-              <entry colname="1">
-                <para>
-                  program output
-                </para>
-              </entry>
-              <entry colname="2">
-                <para>
-                  <computeroutput>Fixed Width</computeroutput>
-                </para>
-              </entry>
-            </row>
-          </tbody>
-        </tgroup>
-      </informaltable>
-
-      <para>
-        The following conventions are used in descriptions of the
-        <acronym>BIND</acronym> configuration file:<informaltable colsep="0" frame="all" rowsep="0">
-                  <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="2Level-table">
-                      <colspec colname="1" colnum="1" colsep="0" colwidth="3.000in"/>
-            <colspec colname="2" colnum="2" colsep="0" colwidth="2.625in"/>
-            <tbody>
-              <row rowsep="0">
-                <entry colname="1" colsep="1" rowsep="1">
-                  <para>
-                    <emphasis>To describe:</emphasis>
-                  </para>
-                </entry>
-                <entry colname="2" rowsep="1">
-                  <para>
-                    <emphasis>We use the style:</emphasis>
-                  </para>
-                </entry>
-              </row>
-              <row rowsep="0">
-                <entry colname="1" colsep="1" rowsep="1">
-                  <para>
-                    keywords
-                  </para>
-                </entry>
-                <entry colname="2" rowsep="1">
-                  <para>
-                    <literal>Fixed Width</literal>
-                  </para>
-                </entry>
-              </row>
-              <row rowsep="0">
-                <entry colname="1" colsep="1" rowsep="1">
-                  <para>
-                    variables
-                  </para>
-                </entry>
-                <entry colname="2" rowsep="1">
-                  <para>
-                    <varname>Fixed Width</varname>
-                  </para>
-                </entry>
-              </row>
-              <row rowsep="0">
-                <entry colname="1" colsep="1">
-                  <para>
-                    Optional input
-                  </para>
-                </entry>
-                <entry colname="2">
-                  <para>
-                    <optional>Text is enclosed in square brackets</optional>
-                  </para>
-                </entry>
-              </row>
-            </tbody>
-          </tgroup>
-        </informaltable>
-      </para>
-    </sect1>
-    <sect1>
-      <title>The Domain Name System (<acronym>DNS</acronym>)</title>
-      <para>
-        The purpose of this document is to explain the installation
-        and upkeep of the <acronym>BIND</acronym> (Berkeley Internet
-	Name Domain) software package, and we
-        begin by reviewing the fundamentals of the Domain Name System
-        (<acronym>DNS</acronym>) as they relate to <acronym>BIND</acronym>.
-      </para>
-
-      <sect2>
-        <title>DNS Fundamentals</title>
-
-        <para>
-          The Domain Name System (DNS) is a hierarchical, distributed
-          database.  It stores information for mapping Internet host names to
-          IP
-          addresses and vice versa, mail routing information, and other data
-          used by Internet applications.
-        </para>
-
-        <para>
-          Clients look up information in the DNS by calling a
-          <emphasis>resolver</emphasis> library, which sends queries to one or
-          more <emphasis>name servers</emphasis> and interprets the responses.
-          The <acronym>BIND</acronym> 9 software distribution
-          contains a
-          name server, <command>named</command>, and two resolver
-          libraries, <command>liblwres</command> and <command>libbind</command>.
-        </para>
-
-        </sect2><sect2>
-        <title>Domains and Domain Names</title>
-
-        <para>
-          The data stored in the DNS is identified by <emphasis>domain names</emphasis> that are organized as a tree according to
-          organizational or administrative boundaries. Each node of the tree,
-          called a <emphasis>domain</emphasis>, is given a label. The domain
-          name of the
-          node is the concatenation of all the labels on the path from the
-          node to the <emphasis>root</emphasis> node.  This is represented
-          in written form as a string of labels listed from right to left and
-          separated by dots. A label need only be unique within its parent
-          domain.
-        </para>
-
-        <para>
-          For example, a domain name for a host at the
-          company <emphasis>Example, Inc.</emphasis> could be
-          <literal>ourhost.example.com</literal>,
-          where <literal>com</literal> is the
-          top level domain to which
-          <literal>ourhost.example.com</literal> belongs,
-          <literal>example</literal> is
-          a subdomain of <literal>com</literal>, and
-          <literal>ourhost</literal> is the
-          name of the host.
-        </para>
-
-        <para>
-          For administrative purposes, the name space is partitioned into
-          areas called <emphasis>zones</emphasis>, each starting at a node and
-          extending down to the leaf nodes or to nodes where other zones
-          start.
-          The data for each zone is stored in a <emphasis>name server</emphasis>, which answers queries about the zone using the
-          <emphasis>DNS protocol</emphasis>.
-        </para>
-
-        <para>
-          The data associated with each domain name is stored in the
-          form of <emphasis>resource records</emphasis> (<acronym>RR</acronym>s).
-          Some of the supported resource record types are described in
-          <xref linkend="types_of_resource_records_and_when_to_use_them"/>.
-        </para>
-
-        <para>
-          For more detailed information about the design of the DNS and
-          the DNS protocol, please refer to the standards documents listed in
-          <xref linkend="rfcs"/>.
-        </para>
-      </sect2>
-
-      <sect2>
-        <title>Zones</title>
-        <para>
-          To properly operate a name server, it is important to understand
-          the difference between a <emphasis>zone</emphasis>
-          and a <emphasis>domain</emphasis>.
-        </para>
-
-        <para>
-          As stated previously, a zone is a point of delegation in
-          the <acronym>DNS</acronym> tree. A zone consists of
-          those contiguous parts of the domain
-          tree for which a name server has complete information and over which
-          it has authority. It contains all domain names from a certain point
-          downward in the domain tree except those which are delegated to
-          other zones. A delegation point is marked by one or more
-          <emphasis>NS records</emphasis> in the
-          parent zone, which should be matched by equivalent NS records at
-          the root of the delegated zone.
-        </para>
-
-        <para>
-          For instance, consider the <literal>example.com</literal>
-          domain which includes names
-          such as <literal>host.aaa.example.com</literal> and
-          <literal>host.bbb.example.com</literal> even though
-          the <literal>example.com</literal> zone includes
-          only delegations for the <literal>aaa.example.com</literal> and
-          <literal>bbb.example.com</literal> zones.  A zone can
-          map
-          exactly to a single domain, but could also include only part of a
-          domain, the rest of which could be delegated to other
-          name servers. Every name in the <acronym>DNS</acronym>
-          tree is a
-          <emphasis>domain</emphasis>, even if it is
-          <emphasis>terminal</emphasis>, that is, has no
-          <emphasis>subdomains</emphasis>.  Every subdomain is a domain and
-          every domain except the root is also a subdomain. The terminology is
-          not intuitive and we suggest that you read RFCs 1033, 1034 and 1035
-          to
-          gain a complete understanding of this difficult and subtle
-          topic.
-        </para>
-
-        <para>
-          Though <acronym>BIND</acronym> is called a "domain name
-          server",
-          it deals primarily in terms of zones. The master and slave
-          declarations in the <filename>named.conf</filename> file
-          specify
-          zones, not domains. When you ask some other site if it is willing to
-          be a slave server for your <emphasis>domain</emphasis>, you are
-          actually asking for slave service for some collection of zones.
-        </para>
-      </sect2>
-
-      <sect2>
-        <title>Authoritative Name Servers</title>
-
-        <para>
-          Each zone is served by at least
-          one <emphasis>authoritative name server</emphasis>,
-          which contains the complete data for the zone.
-          To make the DNS tolerant of server and network failures,
-          most zones have two or more authoritative servers, on
-          different networks.
-        </para>
-
-        <para>
-          Responses from authoritative servers have the "authoritative
-          answer" (AA) bit set in the response packets.  This makes them
-          easy to identify when debugging DNS configurations using tools like
-          <command>dig</command> (<xref linkend="diagnostic_tools"/>).
-        </para>
-
-        <sect3>
-          <title>The Primary Master</title>
-
-          <para>
-            The authoritative server where the master copy of the zone
-            data is maintained is called the
-	    <emphasis>primary master</emphasis> server, or simply the
-            <emphasis>primary</emphasis>.  Typically it loads the zone
-            contents from some local file edited by humans or perhaps
-            generated mechanically from some other local file which is
-            edited by humans.  This file is called the
-	    <emphasis>zone file</emphasis> or
-	    <emphasis>master file</emphasis>.
-          </para>
-
-	  <para>
-	    In some cases, however, the master file may not be edited
-	    by humans at all, but may instead be the result of
-	    <emphasis>dynamic update</emphasis> operations.
-	  </para>
-        </sect3>
-
-        <sect3>
-          <title>Slave Servers</title>
-          <para>
-            The other authoritative servers, the <emphasis>slave</emphasis>
-            servers (also known as <emphasis>secondary</emphasis> servers)
-            load
-            the zone contents from another server using a replication process
-            known as a <emphasis>zone transfer</emphasis>.  Typically the data
-            are
-            transferred directly from the primary master, but it is also
-            possible
-            to transfer it from another slave.  In other words, a slave server
-            may itself act as a master to a subordinate slave server.
-          </para>
-        </sect3>
-
-        <sect3>
-          <title>Stealth Servers</title>
-
-          <para>
-            Usually all of the zone's authoritative servers are listed in
-            NS records in the parent zone.  These NS records constitute
-            a <emphasis>delegation</emphasis> of the zone from the parent.
-            The authoritative servers are also listed in the zone file itself,
-            at the <emphasis>top level</emphasis> or <emphasis>apex</emphasis>
-            of the zone.  You can list servers in the zone's top-level NS
-            records that are not in the parent's NS delegation, but you cannot
-            list servers in the parent's delegation that are not present at
-            the zone's top level.
-          </para>
-
-          <para>
-            A <emphasis>stealth server</emphasis> is a server that is
-            authoritative for a zone but is not listed in that zone's NS
-            records.  Stealth servers can be used for keeping a local copy of
-            a
-            zone to speed up access to the zone's records or to make sure that
-            the
-            zone is available even if all the "official" servers for the zone
-            are
-            inaccessible.
-          </para>
-
-          <para>
-            A configuration where the primary master server itself is a
-            stealth server is often referred to as a "hidden primary"
-            configuration.  One use for this configuration is when the primary
-            master
-            is behind a firewall and therefore unable to communicate directly
-            with the outside world.
-          </para>
-
-        </sect3>
-
-      </sect2>
-      <sect2>
-
-        <title>Caching Name Servers</title>
-
-	<!--
-	  - Terminology here is inconsistent.  Probably ought to
-	  - convert to using "recursive name server" everywhere
-	  - with just a note about "caching" terminology.
-	  -->
-
-        <para>
-          The resolver libraries provided by most operating systems are
-          <emphasis>stub resolvers</emphasis>, meaning that they are not
-          capable of
-          performing the full DNS resolution process by themselves by talking
-          directly to the authoritative servers.  Instead, they rely on a
-          local
-          name server to perform the resolution on their behalf.  Such a
-          server
-          is called a <emphasis>recursive</emphasis> name server; it performs
-          <emphasis>recursive lookups</emphasis> for local clients.
-        </para>
-
-        <para>
-          To improve performance, recursive servers cache the results of
-          the lookups they perform.  Since the processes of recursion and
-          caching are intimately connected, the terms
-          <emphasis>recursive server</emphasis> and
-          <emphasis>caching server</emphasis> are often used synonymously.
-        </para>
-
-        <para>
-          The length of time for which a record may be retained in
-          the cache of a caching name server is controlled by the
-          Time To Live (TTL) field associated with each resource record.
-        </para>
-
-        <sect3>
-          <title>Forwarding</title>
-
-          <para>
-            Even a caching name server does not necessarily perform
-            the complete recursive lookup itself.  Instead, it can
-            <emphasis>forward</emphasis> some or all of the queries
-            that it cannot satisfy from its cache to another caching name
-            server,
-            commonly referred to as a <emphasis>forwarder</emphasis>.
-          </para>
-
-          <para>
-            There may be one or more forwarders,
-            and they are queried in turn until the list is exhausted or an
-            answer
-            is found. Forwarders are typically used when you do not
-            wish all the servers at a given site to interact directly with the
-            rest of
-            the Internet servers. A typical scenario would involve a number
-            of internal <acronym>DNS</acronym> servers and an
-            Internet firewall. Servers unable
-            to pass packets through the firewall would forward to the server
-            that can do it, and that server would query the Internet <acronym>DNS</acronym> servers
-            on the internal server's behalf.
-          </para>
-        </sect3>
-
-      </sect2>
-
-      <sect2>
-        <title>Name Servers in Multiple Roles</title>
-
-        <para>
-          The <acronym>BIND</acronym> name server can
-          simultaneously act as
-          a master for some zones, a slave for other zones, and as a caching
-          (recursive) server for a set of local clients.
-        </para>
-
-        <para>
-          However, since the functions of authoritative name service
-          and caching/recursive name service are logically separate, it is
-          often advantageous to run them on separate server machines.
-
-          A server that only provides authoritative name service
-          (an <emphasis>authoritative-only</emphasis> server) can run with
-          recursion disabled, improving reliability and security.
-
-          A server that is not authoritative for any zones and only provides
-          recursive service to local
-          clients (a <emphasis>caching-only</emphasis> server)
-          does not need to be reachable from the Internet at large and can
-          be placed inside a firewall.
-        </para>
-
-      </sect2>
-    </sect1>
-
-  </chapter>
-
-  <chapter id="Bv9ARM.ch02">
-    <title><acronym>BIND</acronym> Resource Requirements</title>
-
-    <sect1>
-      <title>Hardware requirements</title>
-
-      <para>
-        <acronym>DNS</acronym> hardware requirements have
-        traditionally been quite modest.
-        For many installations, servers that have been pensioned off from
-        active duty have performed admirably as <acronym>DNS</acronym> servers.
-      </para>
-      <para>
-        The DNSSEC features of <acronym>BIND</acronym> 9
-        may prove to be quite
-        CPU intensive however, so organizations that make heavy use of these
-        features may wish to consider larger systems for these applications.
-        <acronym>BIND</acronym> 9 is fully multithreaded, allowing
-        full utilization of
-        multiprocessor systems for installations that need it.
-      </para>
-    </sect1>
-    <sect1>
-      <title>CPU Requirements</title>
-      <para>
-        CPU requirements for <acronym>BIND</acronym> 9 range from
-        i486-class machines
-        for serving of static zones without caching, to enterprise-class
-        machines if you intend to process many dynamic updates and DNSSEC
-        signed zones, serving many thousands of queries per second.
-      </para>
-    </sect1>
-
-    <sect1>
-      <title>Memory Requirements</title>
-      <para>
-        The memory of the server has to be large enough to fit the
-        cache and zones loaded off disk.  The <command>max-cache-size</command>
-        option can be used to limit the amount of memory used by the cache,
-        at the expense of reducing cache hit rates and causing more <acronym>DNS</acronym>
-        traffic.
-        Additionally, if additional section caching
-        (<xref linkend="acache"/>) is enabled,
-        the <command>max-acache-size</command> option can be used to
-        limit the amount
-        of memory used by the mechanism.
-        It is still good practice to have enough memory to load
-        all zone and cache data into memory &mdash; unfortunately, the best
-        way
-        to determine this for a given installation is to watch the name server
-        in operation. After a few weeks the server process should reach
-        a relatively stable size where entries are expiring from the cache as
-        fast as they are being inserted.
-      </para>
-      <!--
-        - Add something here about leaving overhead for attacks?
-	- How much overhead?  Percentage?
-        -->
-    </sect1>
-
-    <sect1>
-      <title>Name Server Intensive Environment Issues</title>
-      <para>
-        For name server intensive environments, there are two alternative
-        configurations that may be used. The first is where clients and
-        any second-level internal name servers query a main name server, which
-        has enough memory to build a large cache. This approach minimizes
-        the bandwidth used by external name lookups. The second alternative
-        is to set up second-level internal name servers to make queries
-        independently.
-        In this configuration, none of the individual machines needs to
-        have as much memory or CPU power as in the first alternative, but
-        this has the disadvantage of making many more external queries,
-        as none of the name servers share their cached data.
-      </para>
-    </sect1>
-
-    <sect1>
-      <title>Supported Operating Systems</title>
-      <para>
-        ISC <acronym>BIND</acronym> 9 compiles and runs on a large
-        number
-        of Unix-like operating system and on NT-derived versions of
-        Microsoft Windows such as Windows 2000 and Windows XP.  For an
-        up-to-date
-        list of supported systems, see the README file in the top level
-        directory
-        of the BIND 9 source distribution.
-      </para>
-    </sect1>
-  </chapter>
-
-  <chapter id="Bv9ARM.ch03">
-    <title>Name Server Configuration</title>
-    <para>
-      In this section we provide some suggested configurations along
-      with guidelines for their use.  We suggest reasonable values for
-      certain option settings.
-    </para>
-
-    <sect1 id="sample_configuration">
-      <title>Sample Configurations</title>
-      <sect2>
-        <title>A Caching-only Name Server</title>
-        <para>
-          The following sample configuration is appropriate for a caching-only
-          name server for use by clients internal to a corporation.  All
-          queries
-          from outside clients are refused using the <command>allow-query</command>
-          option.  Alternatively, the same effect could be achieved using
-          suitable
-          firewall rules.
-        </para>
-
-<programlisting>
-// Two corporate subnets we wish to allow queries from.
-acl corpnets { 192.168.4.0/24; 192.168.7.0/24; };
-options {
-     directory "/etc/namedb";           // Working directory
-     allow-query { corpnets; };
-};
-// Provide a reverse mapping for the loopback address 127.0.0.1
-zone "0.0.127.in-addr.arpa" {
-     type master;
-     file "localhost.rev";
-     notify no;
-};
-</programlisting>
-
-      </sect2>
-
-      <sect2>
-        <title>An Authoritative-only Name Server</title>
-        <para>
-          This sample configuration is for an authoritative-only server
-          that is the master server for "<filename>example.com</filename>"
-          and a slave for the subdomain "<filename>eng.example.com</filename>".
-        </para>
-
-<programlisting>
-options {
-     directory "/etc/namedb";           // Working directory
-     allow-query-cache { none; };       // Do not allow access to cache
-     allow-query { any; };              // This is the default
-     recursion no;                      // Do not provide recursive service
-};
-
-// Provide a reverse mapping for the loopback address 127.0.0.1
-zone "0.0.127.in-addr.arpa" {
-     type master;
-     file "localhost.rev";
-     notify no;
-};
-// We are the master server for example.com
-zone "example.com" {
-     type master;
-     file "example.com.db";
-     // IP addresses of slave servers allowed to transfer example.com
-     allow-transfer {
-          192.168.4.14;
-          192.168.5.53;
-     };
-};
-// We are a slave server for eng.example.com
-zone "eng.example.com" {
-     type slave;
-     file "eng.example.com.bk";
-     // IP address of eng.example.com master server
-     masters { 192.168.4.12; };
-};
-</programlisting>
-
-      </sect2>
-    </sect1>
-
-    <sect1>
-      <title>Load Balancing</title>
-      <!--
-        - Add explanation of why load balancing is fragile at best
-	- and completely pointless in the general case.
-        -->
-
-      <para>
-        A primitive form of load balancing can be achieved in
-        the <acronym>DNS</acronym> by using multiple records
-	(such as multiple A records) for one name.
-      </para>
-
-      <para>
-        For example, if you have three WWW servers with network addresses
-        of 10.0.0.1, 10.0.0.2 and 10.0.0.3, a set of records such as the
-        following means that clients will connect to each machine one third
-        of the time:
-      </para>
-
-      <informaltable colsep="0" rowsep="0">
-        <tgroup cols="5" colsep="0" rowsep="0" tgroupstyle="2Level-table">
-          <colspec colname="1" colnum="1" colsep="0" colwidth="0.875in"/>
-          <colspec colname="2" colnum="2" colsep="0" colwidth="0.500in"/>
-          <colspec colname="3" colnum="3" colsep="0" colwidth="0.750in"/>
-          <colspec colname="4" colnum="4" colsep="0" colwidth="0.750in"/>
-          <colspec colname="5" colnum="5" colsep="0" colwidth="2.028in"/>
-          <tbody>
-            <row rowsep="0">
-              <entry colname="1">
-                <para>
-                  Name
-                </para>
-              </entry>
-              <entry colname="2">
-                <para>
-                  TTL
-                </para>
-              </entry>
-              <entry colname="3">
-                <para>
-                  CLASS
-                </para>
-              </entry>
-              <entry colname="4">
-                <para>
-                  TYPE
-                </para>
-              </entry>
-              <entry colname="5">
-                <para>
-                  Resource Record (RR) Data
-                </para>
-              </entry>
-            </row>
-            <row rowsep="0">
-              <entry colname="1">
-                <para>
-                  <literal>www</literal>
-                </para>
-              </entry>
-              <entry colname="2">
-                <para>
-                  <literal>600</literal>
-                </para>
-              </entry>
-              <entry colname="3">
-                <para>
-                  <literal>IN</literal>
-                </para>
-              </entry>
-              <entry colname="4">
-                <para>
-                  <literal>A</literal>
-                </para>
-              </entry>
-              <entry colname="5">
-                <para>
-                  <literal>10.0.0.1</literal>
-                </para>
-              </entry>
-            </row>
-            <row rowsep="0">
-              <entry colname="1">
-                <para/>
-              </entry>
-              <entry colname="2">
-                <para>
-                  <literal>600</literal>
-                </para>
-              </entry>
-              <entry colname="3">
-                <para>
-                  <literal>IN</literal>
-                </para>
-              </entry>
-              <entry colname="4">
-                <para>
-                  <literal>A</literal>
-                </para>
-              </entry>
-              <entry colname="5">
-                <para>
-                  <literal>10.0.0.2</literal>
-                </para>
-              </entry>
-            </row>
-            <row rowsep="0">
-              <entry colname="1">
-                <para/>
-              </entry>
-              <entry colname="2">
-                <para>
-                  <literal>600</literal>
-                </para>
-              </entry>
-              <entry colname="3">
-                <para>
-                  <literal>IN</literal>
-                </para>
-              </entry>
-              <entry colname="4">
-                <para>
-                  <literal>A</literal>
-                </para>
-              </entry>
-              <entry colname="5">
-                <para>
-                  <literal>10.0.0.3</literal>
-                </para>
-              </entry>
-            </row>
-          </tbody>
-        </tgroup>
-      </informaltable>
-      <para>
-        When a resolver queries for these records, <acronym>BIND</acronym> will rotate
-        them and respond to the query with the records in a different
-        order.  In the example above, clients will randomly receive
-        records in the order 1, 2, 3; 2, 3, 1; and 3, 1, 2. Most clients
-        will use the first record returned and discard the rest.
-      </para>
-      <para>
-        For more detail on ordering responses, check the
-        <command>rrset-order</command> substatement in the
-        <command>options</command> statement, see
-        <xref endterm="rrset_ordering_title" linkend="rrset_ordering"/>.
-      </para>
-
-    </sect1>
-
-    <sect1>
-      <title>Name Server Operations</title>
-
-      <sect2>
-        <title>Tools for Use With the Name Server Daemon</title>
-        <para>
-          This section describes several indispensable diagnostic,
-          administrative and monitoring tools available to the system
-          administrator for controlling and debugging the name server
-          daemon.
-        </para>
-        <sect3 id="diagnostic_tools">
-          <title>Diagnostic Tools</title>
-          <para>
-            The <command>dig</command>, <command>host</command>, and
-            <command>nslookup</command> programs are all command
-            line tools
-            for manually querying name servers.  They differ in style and
-            output format.
-          </para>
-
-          <variablelist>
-            <varlistentry>
-              <term id="dig"><command>dig</command></term>
-              <listitem>
-                <para>
-                  The domain information groper (<command>dig</command>)
-                  is the most versatile and complete of these lookup tools.
-                  It has two modes: simple interactive
-                  mode for a single query, and batch mode which executes a
-                  query for
-                  each in a list of several query lines. All query options are
-                  accessible
-                  from the command line.
-                </para>
-                <cmdsynopsis label="Usage">
-                  <command>dig</command>
-                  <arg>@<replaceable>server</replaceable></arg>
-                  <arg choice="plain"><replaceable>domain</replaceable></arg>
-                  <arg><replaceable>query-type</replaceable></arg>
-                  <arg><replaceable>query-class</replaceable></arg>
-                  <arg>+<replaceable>query-option</replaceable></arg>
-                  <arg>-<replaceable>dig-option</replaceable></arg>
-                  <arg>%<replaceable>comment</replaceable></arg>
-                </cmdsynopsis>
-                <para>
-                  The usual simple use of dig will take the form
-                </para>
-                <simpara>
-                  <command>dig @server domain query-type query-class</command>
-                </simpara>
-                <para>
-                  For more information and a list of available commands and
-                  options, see the <command>dig</command> man
-                  page.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>host</command></term>
-              <listitem>
-                <para>
-                  The <command>host</command> utility emphasizes
-                  simplicity
-                  and ease of use.  By default, it converts
-                  between host names and Internet addresses, but its
-                  functionality
-                  can be extended with the use of options.
-                </para>
-                <cmdsynopsis label="Usage">
-                  <command>host</command>
-                  <arg>-aCdlnrsTwv</arg>
-                  <arg>-c <replaceable>class</replaceable></arg>
-                  <arg>-N <replaceable>ndots</replaceable></arg>
-                  <arg>-t <replaceable>type</replaceable></arg>
-                  <arg>-W <replaceable>timeout</replaceable></arg>
-                  <arg>-R <replaceable>retries</replaceable></arg>
-                  <arg>-m <replaceable>flag</replaceable></arg>
-		  <arg>-4</arg>
-		  <arg>-6</arg>
-                  <arg choice="plain"><replaceable>hostname</replaceable></arg>
-                  <arg><replaceable>server</replaceable></arg>
-                </cmdsynopsis>
-                <para>
-                  For more information and a list of available commands and
-                  options, see the <command>host</command> man
-                  page.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>nslookup</command></term>
-              <listitem>
-                <para><command>nslookup</command>
-		  has two modes: interactive and
-                  non-interactive. Interactive mode allows the user to
-                  query name servers for information about various
-                  hosts and domains or to print a list of hosts in a
-                  domain. Non-interactive mode is used to print just
-                  the name and requested information for a host or
-                  domain.
-                </para>
-                <cmdsynopsis label="Usage">
-                  <command>nslookup</command>
-                  <arg rep="repeat">-option</arg>
-                  <group>
-                    <arg><replaceable>host-to-find</replaceable></arg>
-                    <arg>- <arg>server</arg></arg>
-                  </group>
-                </cmdsynopsis>
-                <para>
-                  Interactive mode is entered when no arguments are given (the
-                  default name server will be used) or when the first argument
-                  is a
-                  hyphen (`-') and the second argument is the host name or
-                  Internet address
-                  of a name server.
-                </para>
-                <para>
-                  Non-interactive mode is used when the name or Internet
-                  address
-                  of the host to be looked up is given as the first argument.
-                  The
-                  optional second argument specifies the host name or address
-                  of a name server.
-                </para>
-                <para>
-                  Due to its arcane user interface and frequently inconsistent
-                  behavior, we do not recommend the use of <command>nslookup</command>.
-                  Use <command>dig</command> instead.
-                </para>
-              </listitem>
-
-            </varlistentry>
-          </variablelist>
-        </sect3>
-
-        <sect3 id="admin_tools">
-          <title>Administrative Tools</title>
-          <para>
-            Administrative tools play an integral part in the management
-            of a server.
-          </para>
-          <variablelist>
-            <varlistentry id="named-checkconf" xreflabel="Named Configuration Checking application">
-
-              <term><command>named-checkconf</command></term>
-              <listitem>
-                <para>
-                  The <command>named-checkconf</command> program
-                  checks the syntax of a <filename>named.conf</filename> file.
-                </para>
-                <cmdsynopsis label="Usage">
-                  <command>named-checkconf</command>
-                  <arg>-jvz</arg>
-                  <arg>-t <replaceable>directory</replaceable></arg>
-                  <arg><replaceable>filename</replaceable></arg>
-                </cmdsynopsis>
-              </listitem>
-            </varlistentry>
-            <varlistentry id="named-checkzone" xreflabel="Zone Checking application">
-
-              <term><command>named-checkzone</command></term>
-              <listitem>
-                <para>
-                  The <command>named-checkzone</command> program
-                  checks a master file for
-                  syntax and consistency.
-                </para>
-                <cmdsynopsis label="Usage">
-                  <command>named-checkzone</command>
-                  <arg>-djqvD</arg>
-                  <arg>-c <replaceable>class</replaceable></arg>
-                  <arg>-o <replaceable>output</replaceable></arg>
-                  <arg>-t <replaceable>directory</replaceable></arg>
-                  <arg>-w <replaceable>directory</replaceable></arg>
-                  <arg>-k <replaceable>(ignore|warn|fail)</replaceable></arg>
-                  <arg>-n <replaceable>(ignore|warn|fail)</replaceable></arg>
-                  <arg>-W <replaceable>(ignore|warn)</replaceable></arg>
-                  <arg choice="plain"><replaceable>zone</replaceable></arg>
-                  <arg><replaceable>filename</replaceable></arg>
-                </cmdsynopsis>
-              </listitem>
-            </varlistentry>
-	    <varlistentry id="named-compilezone" xreflabel="Zone Compilation aplication">
-	      <term><command>named-compilezone</command></term>
-	      <listitem>
-		<para>
-		  Similar to <command>named-checkzone,</command> but
-		  it always dumps the zone content to a specified file
-		  (typically in a different format).
-		</para>
-	      </listitem>
-	    </varlistentry>
-            <varlistentry id="rndc" xreflabel="Remote Name Daemon Control application">
-
-              <term><command>rndc</command></term>
-              <listitem>
-                <para>
-                  The remote name daemon control
-                  (<command>rndc</command>) program allows the
-                  system
-                  administrator to control the operation of a name server.
-                  Since <acronym>BIND</acronym> 9.2, <command>rndc</command>
-                  supports all the commands of the BIND 8 <command>ndc</command>
-                  utility except <command>ndc start</command> and
-                  <command>ndc restart</command>, which were also
-                  not supported in <command>ndc</command>'s
-                  channel mode.
-                  If you run <command>rndc</command> without any
-                  options
-                  it will display a usage message as follows:
-                </para>
-                <cmdsynopsis label="Usage">
-                  <command>rndc</command>
-                  <arg>-c <replaceable>config</replaceable></arg>
-                  <arg>-s <replaceable>server</replaceable></arg>
-                  <arg>-p <replaceable>port</replaceable></arg>
-                  <arg>-y <replaceable>key</replaceable></arg>
-                  <arg choice="plain"><replaceable>command</replaceable></arg>
-                  <arg rep="repeat"><replaceable>command</replaceable></arg>
-                </cmdsynopsis>
-                <para>The <command>command</command>
-		  is one of the following:
-                </para>
-
-                <variablelist>
-
-                  <varlistentry>
-                    <term><userinput>reload</userinput></term>
-                    <listitem>
-                      <para>
-                        Reload configuration file and zones.
-                      </para>
-                    </listitem>
-                  </varlistentry>
-
-                  <varlistentry>
-                    <term><userinput>reload <replaceable>zone</replaceable>
-                        <optional><replaceable>class</replaceable>
-           <optional><replaceable>view</replaceable></optional></optional></userinput></term>
-                    <listitem>
-                      <para>
-                        Reload the given zone.
-                      </para>
-                    </listitem>
-                  </varlistentry>
-
-                  <varlistentry>
-                    <term><userinput>refresh <replaceable>zone</replaceable>
-                        <optional><replaceable>class</replaceable>
-           <optional><replaceable>view</replaceable></optional></optional></userinput></term>
-                    <listitem>
-                      <para>
-                        Schedule zone maintenance for the given zone.
-                      </para>
-                    </listitem>
-                  </varlistentry>
-
-                  <varlistentry>
-                    <term><userinput>retransfer <replaceable>zone</replaceable>
-
-                        <optional><replaceable>class</replaceable>
-           <optional><replaceable>view</replaceable></optional></optional></userinput></term>
-                    <listitem>
-                      <para>
-                        Retransfer the given zone from the master.
-                      </para>
-                    </listitem>
-                  </varlistentry>
-
-                  <varlistentry>
-
-                    <term><userinput>freeze
-                        <optional><replaceable>zone</replaceable>
-       <optional><replaceable>class</replaceable>
-           <optional><replaceable>view</replaceable></optional></optional></optional></userinput></term>
-                    <listitem>
-                      <para>
-                        Suspend updates to a dynamic zone.  If no zone is
-                        specified,
-                        then all zones are suspended.  This allows manual
-                        edits to be made to a zone normally updated by dynamic
-                        update.  It
-                        also causes changes in the journal file to be synced
-                        into the master
-                        and the journal file to be removed.  All dynamic
-                        update attempts will
-                        be refused while the zone is frozen.
-                      </para>
-                    </listitem>
-                  </varlistentry>
-
-                  <varlistentry>
-                    <term><userinput>thaw
-                        <optional><replaceable>zone</replaceable>
-       <optional><replaceable>class</replaceable>
-           <optional><replaceable>view</replaceable></optional></optional></optional></userinput></term>
-                    <listitem>
-                      <para>
-                        Enable updates to a frozen dynamic zone.  If no zone
-                        is
-                        specified, then all frozen zones are enabled.  This
-                        causes
-                        the server to reload the zone from disk, and
-                        re-enables dynamic updates
-                        after the load has completed.  After a zone is thawed,
-                        dynamic updates
-                        will no longer be refused.
-                      </para>
-                    </listitem>
-                  </varlistentry>
-
-                  <varlistentry>
-                    <term><userinput>notify <replaceable>zone</replaceable>
-                        <optional><replaceable>class</replaceable>
-           <optional><replaceable>view</replaceable></optional></optional></userinput></term>
-                    <listitem>
-                      <para>
-                        Resend NOTIFY messages for the zone.
-                      </para>
-                    </listitem>
-                  </varlistentry>
-
-                  <varlistentry>
-                    <term><userinput>reconfig</userinput></term>
-                    <listitem>
-                      <para>
-                        Reload the configuration file and load new zones,
-                        but do not reload existing zone files even if they
-                        have changed.
-                        This is faster than a full <command>reload</command> when there
-                        is a large number of zones because it avoids the need
-                        to examine the
-                        modification times of the zones files.
-                      </para>
-                    </listitem>
-                  </varlistentry>
-
-                  <varlistentry>
-                    <term><userinput>stats</userinput></term>
-                    <listitem>
-                      <para>
-                        Write server statistics to the statistics file.
-                      </para>
-                    </listitem>
-                  </varlistentry>
-
-                  <varlistentry>
-                    <term><userinput>querylog</userinput></term>
-                    <listitem>
-                      <para>
-                        Toggle query logging. Query logging can also be enabled
-                        by explicitly directing the <command>queries</command>
-                        <command>category</command> to a
-		        <command>channel</command> in the
-                        <command>logging</command> section of
-                        <filename>named.conf</filename> or by specifying
-			<command>querylog yes;</command> in the
-			<command>options</command> section of
-			<filename>named.conf</filename>.
-                      </para>
-                    </listitem>
-                  </varlistentry>
-
-                  <varlistentry>
-                    <term><userinput>dumpdb
-                        <optional>-all|-cache|-zone</optional>
-                        <optional><replaceable>view ...</replaceable></optional></userinput></term>
-                    <listitem>
-                      <para>
-                        Dump the server's caches (default) and/or zones to
-                        the
-                        dump file for the specified views.  If no view is
-                        specified, all
-                        views are dumped.
-                      </para>
-                    </listitem>
-                  </varlistentry>
-
-                  <varlistentry>
-                    <term><userinput>stop <optional>-p</optional></userinput></term>
-                    <listitem>
-                      <para>
-                        Stop the server, making sure any recent changes
-                        made through dynamic update or IXFR are first saved to
-                        the master files of the updated zones.
-			If -p is specified named's process id is returned.
-			This allows an external process to determine when named
-			had completed stopping.
-                      </para>
-                    </listitem>
-                  </varlistentry>
-
-                  <varlistentry>
-                    <term><userinput>halt <optional>-p</optional></userinput></term>
-                    <listitem>
-                      <para>
-                        Stop the server immediately.  Recent changes
-                        made through dynamic update or IXFR are not saved to
-                        the master files, but will be rolled forward from the
-			journal files when the server is restarted.
-			If -p is specified named's process id is returned.
-			This allows an external process to determine when named
-			had completed halting.
-                      </para>
-                    </listitem>
-                  </varlistentry>
-
-                  <varlistentry>
-                    <term><userinput>trace</userinput></term>
-                    <listitem>
-                      <para>
-                        Increment the servers debugging level by one.
-                      </para>
-                    </listitem>
-                  </varlistentry>
-
-                  <varlistentry>
-                    <term><userinput>trace <replaceable>level</replaceable></userinput></term>
-                    <listitem>
-                      <para>
-                        Sets the server's debugging level to an explicit
-                        value.
-                      </para>
-                    </listitem>
-                  </varlistentry>
-
-                  <varlistentry>
-                    <term><userinput>notrace</userinput></term>
-                    <listitem>
-                      <para>
-                        Sets the server's debugging level to 0.
-                      </para>
-                    </listitem>
-                  </varlistentry>
-
-                  <varlistentry>
-                    <term><userinput>flush</userinput></term>
-                    <listitem>
-                      <para>
-                        Flushes the server's cache.
-                      </para>
-                    </listitem>
-                  </varlistentry>
-
-                  <varlistentry>
-                    <term><userinput>flushname</userinput> <replaceable>name</replaceable></term>
-                    <listitem>
-                      <para>
-                        Flushes the given name from the server's cache.
-                      </para>
-                    </listitem>
-                  </varlistentry>
-
-                  <varlistentry>
-                    <term><userinput>status</userinput></term>
-                    <listitem>
-                      <para>
-                        Display status of the server.
-                        Note that the number of zones includes the internal <command>bind/CH</command> zone
-                        and the default <command>./IN</command>
-                        hint zone if there is not an
-                        explicit root zone configured.
-                      </para>
-                    </listitem>
-                  </varlistentry>
-
-                  <varlistentry>
-                    <term><userinput>recursing</userinput></term>
-                    <listitem>
-                      <para>
-                        Dump the list of queries named is currently recursing
-                        on.
-                      </para>
-                    </listitem>
-                  </varlistentry>
-
-                </variablelist>
-
-                <para>
-                  A configuration file is required, since all
-                  communication with the server is authenticated with
-                  digital signatures that rely on a shared secret, and
-                  there is no way to provide that secret other than with a
-                  configuration file.  The default location for the
-                  <command>rndc</command> configuration file is
-                  <filename>/etc/rndc.conf</filename>, but an
-                  alternate
-                  location can be specified with the <option>-c</option>
-                  option.  If the configuration file is not found,
-                  <command>rndc</command> will also look in
-                  <filename>/etc/rndc.key</filename> (or whatever
-                  <varname>sysconfdir</varname> was defined when
-                  the <acronym>BIND</acronym> build was
-                  configured).
-                  The <filename>rndc.key</filename> file is
-                  generated by
-                  running <command>rndc-confgen -a</command> as
-                  described in
-                  <xref linkend="controls_statement_definition_and_usage"/>.
-                </para>
-
-                <para>
-                  The format of the configuration file is similar to
-                  that of <filename>named.conf</filename>, but
-                  limited to
-                  only four statements, the <command>options</command>,
-                  <command>key</command>, <command>server</command> and
-                  <command>include</command>
-                  statements.  These statements are what associate the
-                  secret keys to the servers with which they are meant to
-                  be shared.  The order of statements is not
-                  significant.
-                </para>
-
-                <para>
-                  The <command>options</command> statement has
-                  three clauses:
-                  <command>default-server</command>, <command>default-key</command>,
-                  and <command>default-port</command>.
-                  <command>default-server</command> takes a
-                  host name or address argument  and represents the server
-                  that will
-                  be contacted if no <option>-s</option>
-                  option is provided on the command line.
-                  <command>default-key</command> takes
-                  the name of a key as its argument, as defined by a <command>key</command> statement.
-                  <command>default-port</command> specifies the
-                  port to which
-                  <command>rndc</command> should connect if no
-                  port is given on the command line or in a
-                  <command>server</command> statement.
-                </para>
-
-                <para>
-                  The <command>key</command> statement defines a
-                  key to be used
-                  by <command>rndc</command> when authenticating
-                  with
-                  <command>named</command>.  Its syntax is
-                  identical to the
-                  <command>key</command> statement in named.conf.
-                  The keyword <userinput>key</userinput> is
-                  followed by a key name, which must be a valid
-                  domain name, though it need not actually be hierarchical;
-                  thus,
-                  a string like "<userinput>rndc_key</userinput>" is a valid
-                  name.
-                  The <command>key</command> statement has two
-                  clauses:
-                  <command>algorithm</command> and <command>secret</command>.
-                  While the configuration parser will accept any string as the
-                  argument
-                  to algorithm, currently only the string "<userinput>hmac-md5</userinput>"
-                  has any meaning.  The secret is a base-64 encoded string
-		  as specified in RFC 3548.
-                </para>
-
-                <para>
-                  The <command>server</command> statement
-                  associates a key
-                  defined using the <command>key</command>
-                  statement with a server.
-                  The keyword <userinput>server</userinput> is followed by a
-                  host name or address.  The <command>server</command> statement
-                  has two clauses: <command>key</command> and <command>port</command>.
-                  The <command>key</command> clause specifies the
-                  name of the key
-                  to be used when communicating with this server, and the
-                  <command>port</command> clause can be used to
-                  specify the port <command>rndc</command> should
-                  connect
-                  to on the server.
-                </para>
-
-                <para>
-                  A sample minimal configuration file is as follows:
-                </para>
-
-<programlisting>
-key rndc_key {
-     algorithm "hmac-md5";
-     secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K";
-};
-options {
-     default-server 127.0.0.1;
-     default-key    rndc_key;
-};
-</programlisting>
-
-                <para>
-                  This file, if installed as <filename>/etc/rndc.conf</filename>,
-                  would allow the command:
-                </para>
-
-                <para>
-                  <prompt>$ </prompt><userinput>rndc reload</userinput>
-                </para>
-
-                <para>
-                  to connect to 127.0.0.1 port 953 and cause the name server
-                  to reload, if a name server on the local machine were
-                  running with
-                  following controls statements:
-                </para>
-
-<programlisting>
-controls {
-        inet 127.0.0.1 allow { localhost; } keys { rndc_key; };
-};
-</programlisting>
-
-                <para>
-                  and it had an identical key statement for
-                  <literal>rndc_key</literal>.
-                </para>
-
-                <para>
-                  Running the <command>rndc-confgen</command>
-                  program will
-                  conveniently create a <filename>rndc.conf</filename>
-                  file for you, and also display the
-                  corresponding <command>controls</command>
-                  statement that you need to
-                  add to <filename>named.conf</filename>.
-                  Alternatively,
-                  you can run <command>rndc-confgen -a</command>
-                  to set up
-                  a <filename>rndc.key</filename> file and not
-                  modify
-                  <filename>named.conf</filename> at all.
-                </para>
-
-              </listitem>
-            </varlistentry>
-          </variablelist>
-
-        </sect3>
-      </sect2>
-      <sect2>
-
-        <title>Signals</title>
-        <para>
-          Certain UNIX signals cause the name server to take specific
-          actions, as described in the following table.  These signals can
-          be sent using the <command>kill</command> command.
-        </para>
-        <informaltable frame="all">
-          <tgroup cols="2">
-            <colspec colname="1" colnum="1" colsep="0" colwidth="1.125in"/>
-            <colspec colname="2" colnum="2" colsep="0" colwidth="4.000in"/>
-            <tbody>
-              <row rowsep="0">
-                <entry colname="1">
-                  <para><command>SIGHUP</command></para>
-                </entry>
-                <entry colname="2">
-                  <para>
-                    Causes the server to read <filename>named.conf</filename> and
-                    reload the database.
-                  </para>
-                </entry>
-              </row>
-              <row rowsep="0">
-                <entry colname="1">
-                  <para><command>SIGTERM</command></para>
-                </entry>
-                <entry colname="2">
-                  <para>
-                    Causes the server to clean up and exit.
-                  </para>
-                </entry>
-              </row>
-              <row rowsep="0">
-                <entry colname="1">
-                  <para><command>SIGINT</command></para>
-                </entry>
-                <entry colname="2">
-                  <para>
-                    Causes the server to clean up and exit.
-                  </para>
-                </entry>
-              </row>
-            </tbody>
-          </tgroup>
-        </informaltable>
-      </sect2>
-    </sect1>
-  </chapter>
-
-  <chapter id="Bv9ARM.ch04">
-    <title>Advanced DNS Features</title>
-
-    <sect1 id="notify">
-
-      <title>Notify</title>
-      <para>
-        <acronym>DNS</acronym> NOTIFY is a mechanism that allows master
-        servers to notify their slave servers of changes to a zone's data. In
-        response to a <command>NOTIFY</command> from a master server, the
-        slave will check to see that its version of the zone is the
-        current version and, if not, initiate a zone transfer.
-      </para>
-
-      <para>
-        For more information about <acronym>DNS</acronym>
-        <command>NOTIFY</command>, see the description of the
-        <command>notify</command> option in <xref linkend="boolean_options"/> and
-        the description of the zone option <command>also-notify</command> in
-        <xref linkend="zone_transfers"/>.  The <command>NOTIFY</command>
-        protocol is specified in RFC 1996.
-      </para>
-
-      <note>
-	As a slave zone can also be a master to other slaves, named,
-        by default, sends <command>NOTIFY</command> messages for every zone
-	it loads.  Specifying <command>notify master-only;</command> will
-	cause named to only send <command>NOTIFY</command> for master
-	zones that it loads.
-      </note>
-
-    </sect1>
-
-    <sect1 id="dynamic_update">
-      <title>Dynamic Update</title>
-
-      <para>
-        Dynamic Update is a method for adding, replacing or deleting
-        records in a master server by sending it a special form of DNS
-        messages.  The format and meaning of these messages is specified
-        in RFC 2136.
-      </para>
-
-      <para>
-        Dynamic update is enabled by
-        including an <command>allow-update</command> or
-        <command>update-policy</command> clause in the
-        <command>zone</command> statement.
-      </para>
-
-      <para>
-        Updating of secure zones (zones using DNSSEC) follows
-        RFC 3007: RRSIG and NSEC records affected by updates are automatically
-            regenerated by the server using an online zone key.
-        Update authorization is based
-        on transaction signatures and an explicit server policy.
-      </para>
-
-      <sect2 id="journal">
-        <title>The journal file</title>
-
-        <para>
-          All changes made to a zone using dynamic update are stored
-          in the zone's journal file.  This file is automatically created
-          by the server when the first dynamic update takes place.
-          The name of the journal file is formed by appending the extension
-          <filename>.jnl</filename> to the name of the
-          corresponding zone
-          file unless specifically overridden.  The journal file is in a
-          binary format and should not be edited manually.
-        </para>
-
-        <para>
-          The server will also occasionally write ("dump")
-          the complete contents of the updated zone to its zone file.
-          This is not done immediately after
-          each dynamic update, because that would be too slow when a large
-          zone is updated frequently.  Instead, the dump is delayed by
-          up to 15 minutes, allowing additional updates to take place.
-        </para>
-
-        <para>
-          When a server is restarted after a shutdown or crash, it will replay
-              the journal file to incorporate into the zone any updates that
-          took
-          place after the last zone dump.
-        </para>
-
-        <para>
-          Changes that result from incoming incremental zone transfers are
-          also
-          journalled in a similar way.
-        </para>
-
-        <para>
-          The zone files of dynamic zones cannot normally be edited by
-          hand because they are not guaranteed to contain the most recent
-          dynamic changes &mdash; those are only in the journal file.
-          The only way to ensure that the zone file of a dynamic zone
-          is up to date is to run <command>rndc stop</command>.
-        </para>
-
-        <para>
-          If you have to make changes to a dynamic zone
-          manually, the following procedure will work: Disable dynamic updates
-              to the zone using
-          <command>rndc freeze <replaceable>zone</replaceable></command>.
-          This will also remove the zone's <filename>.jnl</filename> file
-          and update the master file.  Edit the zone file.  Run
-          <command>rndc thaw <replaceable>zone</replaceable></command>
-          to reload the changed zone and re-enable dynamic updates.
-        </para>
-
-      </sect2>
-
-    </sect1>
-
-    <sect1 id="incremental_zone_transfers">
-      <title>Incremental Zone Transfers (IXFR)</title>
-
-      <para>
-        The incremental zone transfer (IXFR) protocol is a way for
-        slave servers to transfer only changed data, instead of having to
-        transfer the entire zone. The IXFR protocol is specified in RFC
-        1995. See <xref linkend="proposed_standards"/>.
-      </para>
-
-      <para>
-        When acting as a master, <acronym>BIND</acronym> 9
-        supports IXFR for those zones
-        where the necessary change history information is available. These
-        include master zones maintained by dynamic update and slave zones
-        whose data was obtained by IXFR.  For manually maintained master
-        zones, and for slave zones obtained by performing a full zone
-        transfer (AXFR), IXFR is supported only if the option
-        <command>ixfr-from-differences</command> is set
-        to <userinput>yes</userinput>.
-      </para>
-
-      <para>
-        When acting as a slave, <acronym>BIND</acronym> 9 will
-        attempt to use IXFR unless
-        it is explicitly disabled. For more information about disabling
-        IXFR, see the description of the <command>request-ixfr</command> clause
-        of the <command>server</command> statement.
-      </para>
-    </sect1>
-
-    <sect1>
-      <title>Split DNS</title>
-      <para>
-        Setting up different views, or visibility, of the DNS space to
-        internal and external resolvers is usually referred to as a
-	<emphasis>Split DNS</emphasis> setup. There are several
-        reasons an organization would want to set up its DNS this way.
-      </para>
-      <para>
-        One common reason for setting up a DNS system this way is
-        to hide "internal" DNS information from "external" clients on the
-        Internet. There is some debate as to whether or not this is actually
-        useful.
-        Internal DNS information leaks out in many ways (via email headers,
-        for example) and most savvy "attackers" can find the information
-        they need using other means.
-	However, since listing addresses of internal servers that
-        external clients cannot possibly reach can result in
-        connection delays and other annoyances, an organization may
-        choose to use a Split DNS to present a consistent view of itself
-        to the outside world.
-      </para>
-      <para>
-        Another common reason for setting up a Split DNS system is
-        to allow internal networks that are behind filters or in RFC 1918
-        space (reserved IP space, as documented in RFC 1918) to resolve DNS
-        on the Internet. Split DNS can also be used to allow mail from outside
-        back in to the internal network.
-      </para>
-     <sect2>
-      <title>Example split DNS setup</title>
-      <para>
-        Let's say a company named <emphasis>Example, Inc.</emphasis>
-        (<literal>example.com</literal>)
-        has several corporate sites that have an internal network with
-        reserved
-        Internet Protocol (IP) space and an external demilitarized zone (DMZ),
-        or "outside" section of a network, that is available to the public.
-      </para>
-      <para>
-        <emphasis>Example, Inc.</emphasis> wants its internal clients
-        to be able to resolve external hostnames and to exchange mail with
-        people on the outside. The company also wants its internal resolvers
-        to have access to certain internal-only zones that are not available
-        at all outside of the internal network.
-      </para>
-      <para>
-        In order to accomplish this, the company will set up two sets
-        of name servers. One set will be on the inside network (in the
-        reserved
-        IP space) and the other set will be on bastion hosts, which are
-        "proxy"
-        hosts that can talk to both sides of its network, in the DMZ.
-      </para>
-      <para>
-        The internal servers will be configured to forward all queries,
-        except queries for <filename>site1.internal</filename>, <filename>site2.internal</filename>, <filename>site1.example.com</filename>,
-        and <filename>site2.example.com</filename>, to the servers
-        in the
-        DMZ. These internal servers will have complete sets of information
-        for <filename>site1.example.com</filename>, <filename>site2.example.com</filename>,<emphasis/> <filename>site1.internal</filename>,
-        and <filename>site2.internal</filename>.
-      </para>
-      <para>
-        To protect the <filename>site1.internal</filename> and <filename>site2.internal</filename> domains,
-        the internal name servers must be configured to disallow all queries
-        to these domains from any external hosts, including the bastion
-        hosts.
-      </para>
-      <para>
-        The external servers, which are on the bastion hosts, will
-        be configured to serve the "public" version of the <filename>site1</filename> and <filename>site2.example.com</filename> zones.
-        This could include things such as the host records for public servers
-        (<filename>www.example.com</filename> and <filename>ftp.example.com</filename>),
-        and mail exchange (MX)  records (<filename>a.mx.example.com</filename> and <filename>b.mx.example.com</filename>).
-      </para>
-      <para>
-        In addition, the public <filename>site1</filename> and <filename>site2.example.com</filename> zones
-        should have special MX records that contain wildcard (`*') records
-        pointing to the bastion hosts. This is needed because external mail
-        servers do not have any other way of looking up how to deliver mail
-        to those internal hosts. With the wildcard records, the mail will
-        be delivered to the bastion host, which can then forward it on to
-        internal hosts.
-      </para>
-      <para>
-        Here's an example of a wildcard MX record:
-      </para>
-      <programlisting>*   IN MX 10 external1.example.com.</programlisting>
-      <para>
-        Now that they accept mail on behalf of anything in the internal
-        network, the bastion hosts will need to know how to deliver mail
-        to internal hosts. In order for this to work properly, the resolvers
-        on
-        the bastion hosts will need to be configured to point to the internal
-        name servers for DNS resolution.
-      </para>
-      <para>
-        Queries for internal hostnames will be answered by the internal
-        servers, and queries for external hostnames will be forwarded back
-        out to the DNS servers on the bastion hosts.
-      </para>
-      <para>
-        In order for all this to work properly, internal clients will
-        need to be configured to query <emphasis>only</emphasis> the internal
-        name servers for DNS queries. This could also be enforced via
-        selective
-        filtering on the network.
-      </para>
-      <para>
-        If everything has been set properly, <emphasis>Example, Inc.</emphasis>'s
-        internal clients will now be able to:
-      </para>
-      <itemizedlist>
-        <listitem>
-          <simpara>
-            Look up any hostnames in the <literal>site1</literal>
-            and
-            <literal>site2.example.com</literal> zones.
-          </simpara>
-        </listitem>
-        <listitem>
-          <simpara>
-            Look up any hostnames in the <literal>site1.internal</literal> and
-            <literal>site2.internal</literal> domains.
-          </simpara>
-        </listitem>
-        <listitem>
-          <simpara>Look up any hostnames on the Internet.</simpara>
-        </listitem>
-        <listitem>
-          <simpara>Exchange mail with both internal and external people.</simpara>
-        </listitem>
-      </itemizedlist>
-      <para>
-        Hosts on the Internet will be able to:
-      </para>
-      <itemizedlist>
-        <listitem>
-          <simpara>
-            Look up any hostnames in the <literal>site1</literal>
-            and
-            <literal>site2.example.com</literal> zones.
-          </simpara>
-        </listitem>
-        <listitem>
-          <simpara>
-            Exchange mail with anyone in the <literal>site1</literal> and
-            <literal>site2.example.com</literal> zones.
-          </simpara>
-        </listitem>
-      </itemizedlist>
-
-      <para>
-        Here is an example configuration for the setup we just
-        described above. Note that this is only configuration information;
-        for information on how to configure your zone files, see <xref linkend="sample_configuration"/>.
-      </para>
-
-      <para>
-        Internal DNS server config:
-      </para>
-
-<programlisting>
-
-acl internals { 172.16.72.0/24; 192.168.1.0/24; };
-
-acl externals { <varname>bastion-ips-go-here</varname>; };
-
-options {
-    ...
-    ...
-    forward only;
-    forwarders {                                // forward to external servers
-        <varname>bastion-ips-go-here</varname>;
-    };
-    allow-transfer { none; };                   // sample allow-transfer (no one)
-    allow-query { internals; externals; };      // restrict query access
-    allow-recursion { internals; };             // restrict recursion
-    ...
-    ...
-};
-
-zone "site1.example.com" {                      // sample master zone
-  type master;
-  file "m/site1.example.com";
-  forwarders { };                               // do normal iterative
-                                                // resolution (do not forward)
-  allow-query { internals; externals; };
-  allow-transfer { internals; };
-};
-
-zone "site2.example.com" {                      // sample slave zone
-  type slave;
-  file "s/site2.example.com";
-  masters { 172.16.72.3; };
-  forwarders { };
-  allow-query { internals; externals; };
-  allow-transfer { internals; };
-};
-
-zone "site1.internal" {
-  type master;
-  file "m/site1.internal";
-  forwarders { };
-  allow-query { internals; };
-  allow-transfer { internals; }
-};
-
-zone "site2.internal" {
-  type slave;
-  file "s/site2.internal";
-  masters { 172.16.72.3; };
-  forwarders { };
-  allow-query { internals };
-  allow-transfer { internals; }
-};
-</programlisting>
-
-      <para>
-        External (bastion host) DNS server config:
-      </para>
-
-<programlisting>
-acl internals { 172.16.72.0/24; 192.168.1.0/24; };
-
-acl externals { bastion-ips-go-here; };
-
-options {
-  ...
-  ...
-  allow-transfer { none; };                     // sample allow-transfer (no one)
-  allow-query { any; };                         // default query access
-  allow-query-cache { internals; externals; };  // restrict cache access
-  allow-recursion { internals; externals; };    // restrict recursion
-  ...
-  ...
-};
-
-zone "site1.example.com" {                      // sample slave zone
-  type master;
-  file "m/site1.foo.com";
-  allow-transfer { internals; externals; };
-};
-
-zone "site2.example.com" {
-  type slave;
-  file "s/site2.foo.com";
-  masters { another_bastion_host_maybe; };
-  allow-transfer { internals; externals; }
-};
-</programlisting>
-
-      <para>
-        In the <filename>resolv.conf</filename> (or equivalent) on
-        the bastion host(s):
-      </para>
-
-<programlisting>
-search ...
-nameserver 172.16.72.2
-nameserver 172.16.72.3
-nameserver 172.16.72.4
-</programlisting>
-
-     </sect2>
-    </sect1>
-    <sect1 id="tsig">
-      <title>TSIG</title>
-      <para>
-        This is a short guide to setting up Transaction SIGnatures
-        (TSIG) based transaction security in <acronym>BIND</acronym>. It describes changes
-        to the configuration file as well as what changes are required for
-        different features, including the process of creating transaction
-        keys and using transaction signatures with <acronym>BIND</acronym>.
-      </para>
-      <para>
-        <acronym>BIND</acronym> primarily supports TSIG for server
-        to server communication.
-        This includes zone transfer, notify, and recursive query messages.
-        Resolvers based on newer versions of <acronym>BIND</acronym> 8 have limited support
-        for TSIG.
-      </para>
-
-      <para>
-        TSIG can also be useful for dynamic update. A primary
-        server for a dynamic zone should control access to the dynamic
-        update service, but IP-based access control is insufficient.
-        The cryptographic access control provided by TSIG
-        is far superior. The <command>nsupdate</command>
-        program supports TSIG via the <option>-k</option> and
-        <option>-y</option> command line options or inline by use
-	of the <command>key</command>.
-      </para>
-
-      <sect2>
-        <title>Generate Shared Keys for Each Pair of Hosts</title>
-        <para>
-          A shared secret is generated to be shared between <emphasis>host1</emphasis> and <emphasis>host2</emphasis>.
-          An arbitrary key name is chosen: "host1-host2.". The key name must
-          be the same on both hosts.
-        </para>
-        <sect3>
-          <title>Automatic Generation</title>
-          <para>
-            The following command will generate a 128-bit (16 byte) HMAC-MD5
-            key as described above. Longer keys are better, but shorter keys
-            are easier to read. Note that the maximum key length is 512 bits;
-            keys longer than that will be digested with MD5 to produce a
-            128-bit key.
-          </para>
-          <para>
-            <userinput>dnssec-keygen -a hmac-md5 -b 128 -n HOST host1-host2.</userinput>
-          </para>
-          <para>
-            The key is in the file <filename>Khost1-host2.+157+00000.private</filename>.
-            Nothing directly uses this file, but the base-64 encoded string
-            following "<literal>Key:</literal>"
-            can be extracted from the file and used as a shared secret:
-          </para>
-          <programlisting>Key: La/E5CjG9O+os1jq0a2jdA==</programlisting>
-          <para>
-            The string "<literal>La/E5CjG9O+os1jq0a2jdA==</literal>" can
-            be used as the shared secret.
-          </para>
-        </sect3>
-        <sect3>
-          <title>Manual Generation</title>
-          <para>
-            The shared secret is simply a random sequence of bits, encoded
-            in base-64. Most ASCII strings are valid base-64 strings (assuming
-            the length is a multiple of 4 and only valid characters are used),
-            so the shared secret can be manually generated.
-          </para>
-          <para>
-            Also, a known string can be run through <command>mmencode</command> or
-            a similar program to generate base-64 encoded data.
-          </para>
-        </sect3>
-      </sect2>
-      <sect2>
-        <title>Copying the Shared Secret to Both Machines</title>
-        <para>
-          This is beyond the scope of DNS. A secure transport mechanism
-          should be used. This could be secure FTP, ssh, telephone, etc.
-        </para>
-      </sect2>
-      <sect2>
-        <title>Informing the Servers of the Key's Existence</title>
-        <para>
-          Imagine <emphasis>host1</emphasis> and <emphasis>host 2</emphasis>
-          are
-          both servers. The following is added to each server's <filename>named.conf</filename> file:
-        </para>
-
-<programlisting>
-key host1-host2. {
-  algorithm hmac-md5;
-  secret "La/E5CjG9O+os1jq0a2jdA==";
-};
-</programlisting>
-
-        <para>
-          The algorithm, hmac-md5, is the only one supported by <acronym>BIND</acronym>.
-          The secret is the one generated above. Since this is a secret, it
-          is recommended that either <filename>named.conf</filename> be non-world
-          readable, or the key directive be added to a non-world readable
-          file that is included by
-          <filename>named.conf</filename>.
-        </para>
-        <para>
-          At this point, the key is recognized. This means that if the
-          server receives a message signed by this key, it can verify the
-          signature. If the signature is successfully verified, the
-          response is signed by the same key.
-        </para>
-      </sect2>
-
-      <sect2>
-        <title>Instructing the Server to Use the Key</title>
-        <para>
-          Since keys are shared between two hosts only, the server must
-          be told when keys are to be used. The following is added to the <filename>named.conf</filename> file
-          for <emphasis>host1</emphasis>, if the IP address of <emphasis>host2</emphasis> is
-          10.1.2.3:
-        </para>
-
-<programlisting>
-server 10.1.2.3 {
-  keys { host1-host2. ;};
-};
-</programlisting>
-
-        <para>
-          Multiple keys may be present, but only the first is used.
-          This directive does not contain any secrets, so it may be in a
-          world-readable
-          file.
-        </para>
-        <para>
-          If <emphasis>host1</emphasis> sends a message that is a request
-          to that address, the message will be signed with the specified key. <emphasis>host1</emphasis> will
-          expect any responses to signed messages to be signed with the same
-          key.
-        </para>
-        <para>
-          A similar statement must be present in <emphasis>host2</emphasis>'s
-          configuration file (with <emphasis>host1</emphasis>'s address) for <emphasis>host2</emphasis> to
-          sign request messages to <emphasis>host1</emphasis>.
-        </para>
-      </sect2>
-      <sect2>
-        <title>TSIG Key Based Access Control</title>
-        <para>
-          <acronym>BIND</acronym> allows IP addresses and ranges
-          to be specified in ACL
-          definitions and
-          <command>allow-{ query | transfer | update }</command>
-          directives.
-          This has been extended to allow TSIG keys also. The above key would
-          be denoted <command>key host1-host2.</command>
-        </para>
-        <para>
-          An example of an allow-update directive would be:
-        </para>
-
-<programlisting>
-allow-update { key host1-host2. ;};
-</programlisting>
-
-        <para>
-          This allows dynamic updates to succeed only if the request
-          was signed by a key named
-          "<command>host1-host2.</command>".
-        </para>
-	<para>
-          You may want to read about the more
-          powerful <command>update-policy</command> statement in <xref linkend="dynamic_update_policies"/>.
-        </para>
-
-      </sect2>
-      <sect2>
-        <title>Errors</title>
-
-        <para>
-          The processing of TSIG signed messages can result in
-          several errors. If a signed message is sent to a non-TSIG aware
-          server, a FORMERR (format error) will be returned, since the server will not
-          understand the record. This is a result of misconfiguration,
-          since the server must be explicitly configured to send a TSIG
-          signed message to a specific server.
-        </para>
-
-        <para>
-          If a TSIG aware server receives a message signed by an
-          unknown key, the response will be unsigned with the TSIG
-          extended error code set to BADKEY. If a TSIG aware server
-          receives a message with a signature that does not validate, the
-          response will be unsigned with the TSIG extended error code set
-          to BADSIG. If a TSIG aware server receives a message with a time
-          outside of the allowed range, the response will be signed with
-          the TSIG extended error code set to BADTIME, and the time values
-          will be adjusted so that the response can be successfully
-          verified. In any of these cases, the message's rcode (response code) is set to
-          NOTAUTH (not authenticated).
-        </para>
-
-      </sect2>
-    </sect1>
-    <sect1>
-      <title>TKEY</title>
-
-      <para><command>TKEY</command>
-        is a mechanism for automatically generating a shared secret
-        between two hosts.  There are several "modes" of
-        <command>TKEY</command> that specify how the key is generated
-        or assigned.  <acronym>BIND</acronym> 9 implements only one of
-        these modes, the Diffie-Hellman key exchange.  Both hosts are
-        required to have a Diffie-Hellman KEY record (although this
-        record is not required to be present in a zone).  The
-        <command>TKEY</command> process must use signed messages,
-        signed either by TSIG or SIG(0).  The result of
-        <command>TKEY</command> is a shared secret that can be used to
-        sign messages with TSIG.  <command>TKEY</command> can also be
-        used to delete shared secrets that it had previously
-        generated.
-      </para>
-
-      <para>
-        The <command>TKEY</command> process is initiated by a
-        client
-        or server by sending a signed <command>TKEY</command>
-        query
-        (including any appropriate KEYs) to a TKEY-aware server.  The
-        server response, if it indicates success, will contain a
-        <command>TKEY</command> record and any appropriate keys.
-        After
-        this exchange, both participants have enough information to
-        determine the shared secret; the exact process depends on the
-        <command>TKEY</command> mode.  When using the
-        Diffie-Hellman
-        <command>TKEY</command> mode, Diffie-Hellman keys are
-        exchanged,
-        and the shared secret is derived by both participants.
-      </para>
-
-    </sect1>
-    <sect1>
-      <title>SIG(0)</title>
-
-      <para>
-        <acronym>BIND</acronym> 9 partially supports DNSSEC SIG(0)
-            transaction signatures as specified in RFC 2535 and RFC2931.
-        SIG(0)
-        uses public/private keys to authenticate messages.  Access control
-        is performed in the same manner as TSIG keys; privileges can be
-        granted or denied based on the key name.
-      </para>
-
-      <para>
-        When a SIG(0) signed message is received, it will only be
-        verified if the key is known and trusted by the server; the server
-        will not attempt to locate and/or validate the key.
-      </para>
-
-      <para>
-        SIG(0) signing of multiple-message TCP streams is not
-        supported.
-      </para>
-
-      <para>
-        The only tool shipped with <acronym>BIND</acronym> 9 that
-        generates SIG(0) signed messages is <command>nsupdate</command>.
-      </para>
-
-    </sect1>
-    <sect1 id="DNSSEC">
-      <title>DNSSEC</title>
-
-      <para>
-        Cryptographic authentication of DNS information is possible
-        through the DNS Security (<emphasis>DNSSEC-bis</emphasis>) extensions,
-        defined in RFC 4033, RFC 4034, and RFC 4035.
-	This section describes the creation and use of DNSSEC signed zones.
-      </para>
-
-      <para>
-        In order to set up a DNSSEC secure zone, there are a series
-        of steps which must be followed.  <acronym>BIND</acronym>
-        9 ships
-        with several tools
-        that are used in this process, which are explained in more detail
-        below.  In all cases, the <option>-h</option> option prints a
-        full list of parameters.  Note that the DNSSEC tools require the
-        keyset files to be in the working directory or the
-        directory specified by the <option>-d</option> option, and
-        that the tools shipped with BIND 9.2.x and earlier are not compatible
-        with the current ones.
-      </para>
-
-      <para>
-        There must also be communication with the administrators of
-        the parent and/or child zone to transmit keys.  A zone's security
-        status must be indicated by the parent zone for a DNSSEC capable
-        resolver to trust its data.  This is done through the presence
-        or absence of a <literal>DS</literal> record at the
-        delegation
-        point.
-      </para>
-
-      <para>
-        For other servers to trust data in this zone, they must
-        either be statically configured with this zone's zone key or the
-        zone key of another zone above this one in the DNS tree.
-      </para>
-
-      <sect2>
-        <title>Generating Keys</title>
-
-        <para>
-          The <command>dnssec-keygen</command> program is used to
-          generate keys.
-        </para>
-
-        <para>
-          A secure zone must contain one or more zone keys.  The
-          zone keys will sign all other records in the zone, as well as
-          the zone keys of any secure delegated zones.  Zone keys must
-          have the same name as the zone, a name type of
-          <command>ZONE</command>, and must be usable for
-          authentication.
-          It is recommended that zone keys use a cryptographic algorithm
-          designated as "mandatory to implement" by the IETF; currently
-          the only one is RSASHA1.
-        </para>
-
-        <para>
-          The following command will generate a 768-bit RSASHA1 key for
-          the <filename>child.example</filename> zone:
-        </para>
-
-        <para>
-          <userinput>dnssec-keygen -a RSASHA1 -b 768 -n ZONE child.example.</userinput>
-        </para>
-
-        <para>
-          Two output files will be produced:
-          <filename>Kchild.example.+005+12345.key</filename> and
-          <filename>Kchild.example.+005+12345.private</filename>
-          (where
-          12345 is an example of a key tag).  The key filenames contain
-          the key name (<filename>child.example.</filename>),
-          algorithm (3
-          is DSA, 1 is RSAMD5, 5 is RSASHA1, etc.), and the key tag (12345 in
-          this case).
-          The private key (in the <filename>.private</filename>
-          file) is
-          used to generate signatures, and the public key (in the
-          <filename>.key</filename> file) is used for signature
-          verification.
-        </para>
-
-        <para>
-          To generate another key with the same properties (but with
-          a different key tag), repeat the above command.
-        </para>
-
-        <para>
-          The public keys should be inserted into the zone file by
-          including the <filename>.key</filename> files using
-          <command>$INCLUDE</command> statements.
-        </para>
-
-      </sect2>
-      <sect2>
-        <title>Signing the Zone</title>
-
-        <para>
-          The <command>dnssec-signzone</command> program is used
-          to
-          sign a zone.
-        </para>
-
-        <para>
-          Any <filename>keyset</filename> files corresponding
-          to secure subzones should be present.  The zone signer will
-          generate <literal>NSEC</literal> and <literal>RRSIG</literal>
-          records for the zone, as well as <literal>DS</literal>
-          for
-          the child zones if <literal>'-d'</literal> is specified.
-                If <literal>'-d'</literal> is not specified, then
-          DS RRsets for
-          the secure child zones need to be added manually.
-        </para>
-
-        <para>
-          The following command signs the zone, assuming it is in a
-          file called <filename>zone.child.example</filename>.  By
-                default, all zone keys which have an available private key are
-                used to generate signatures.
-        </para>
-
-        <para>
-          <userinput>dnssec-signzone -o child.example zone.child.example</userinput>
-        </para>
-
-        <para>
-          One output file is produced:
-          <filename>zone.child.example.signed</filename>.  This
-          file
-          should be referenced by <filename>named.conf</filename>
-          as the
-          input file for the zone.
-        </para>
-
-        <para><command>dnssec-signzone</command>
-	  will also produce a keyset and dsset files and optionally a
-          dlvset file.  These are used to provide the parent zone
-          administrators with the <literal>DNSKEYs</literal> (or their
-          corresponding <literal>DS</literal> records) that are the
-          secure entry point to the zone.
-        </para>
-
-      </sect2>
-
-      <sect2>
-        <title>Configuring Servers</title>
-
-	<para>
-	  To enable <command>named</command> to respond appropriately
-	  to DNS requests from DNSSEC aware clients,
-	  <command>dnssec-enable</command> must be set to yes.
-        </para>
-
-	<para>
-	  To enable <command>named</command> to validate answers from
-	  other servers both <command>dnssec-enable</command> and
-	  <command>dnssec-validation</command> must be set and some
-	  <command>trusted-keys</command> must be configured
-	  into <filename>named.conf</filename>.
-        </para>
-	  
-	<para>
-	  <command>trusted-keys</command> are copies of DNSKEY RRs
-	  for zones that are used to form the first link in the
-	  cryptographic chain of trust.  All keys listed in
-	  <command>trusted-keys</command> (and corresponding zones)
-	  are deemed to exist and only the listed keys will be used
-	  to validated the DNSKEY RRset that they are from.
-	</para>
-
-	<para>
-	  <command>trusted-keys</command> are described in more detail
-	  later in this document.
-	</para>
-
-	<para>
-	  Unlike <acronym>BIND</acronym> 8, <acronym>BIND</acronym>
-	  9 does not verify signatures on load, so zone keys for
-	  authoritative zones do not need to be specified in the
-	  configuration file.
-	</para>
-
-	<para>
-	  After DNSSEC gets established, a typical DNSSEC configuration
-	  will look something like the following.  It has a one or
-	  more public keys for the root.  This allows answers from
-	  outside the organization to be validated.  It will also
-	  have several keys for parts of the namespace the organization
-	  controls.  These are here to ensure that named is immune
-	  to compromises in the DNSSEC components of the security
-	  of parent zones.
-	</para>
-
-<programlisting>
-trusted-keys {
-
-	/* Root Key */
-"." 257 3 3 "BNY4wrWM1nCfJ+CXd0rVXyYmobt7sEEfK3clRbGaTwSJxrGkxJWoZu6I7PzJu/
-	     E9gx4UC1zGAHlXKdE4zYIpRhaBKnvcC2U9mZhkdUpd1Vso/HAdjNe8LmMlnzY3
-	     zy2Xy4klWOADTPzSv9eamj8V18PHGjBLaVtYvk/ln5ZApjYghf+6fElrmLkdaz
-	     MQ2OCnACR817DF4BBa7UR/beDHyp5iWTXWSi6XmoJLbG9Scqc7l70KDqlvXR3M
-	     /lUUVRbkeg1IPJSidmK3ZyCllh4XSKbje/45SKucHgnwU5jefMtq66gKodQj+M
-	     iA21AfUVe7u99WzTLzY3qlxDhxYQQ20FQ97S+LKUTpQcq27R7AT3/V5hRQxScI
-	     Nqwcz4jYqZD2fQdgxbcDTClU0CRBdiieyLMNzXG3";
-
-/* Key for our organization's forward zone */
-example.com. 257 3 5 "AwEAAaxPMcR2x0HbQV4WeZB6oEDX+r0QM65KbhTjrW1ZaARmPhEZZe
-                      3Y9ifgEuq7vZ/zGZUdEGNWy+JZzus0lUptwgjGwhUS1558Hb4JKUbb
-	              OTcM8pwXlj0EiX3oDFVmjHO444gLkBO UKUf/mC7HvfwYH/Be22GnC
-		      lrinKJp1Og4ywzO9WglMk7jbfW33gUKvirTHr25GL7STQUzBb5Usxt
-		      8lgnyTUHs1t3JwCY5hKZ6CqFxmAVZP20igTixin/1LcrgX/KMEGd/b
-		      iuvF4qJCyduieHukuY3H4XMAcR+xia2 nIUPvm/oyWR8BW/hWdzOvn
-		      SCThlHf3xiYleDbt/o1OTQ09A0=";
-
-/* Key for our reverse zone. */
-2.0.192.IN-ADDRPA.NET. 257 3 5 "AQOnS4xn/IgOUpBPJ3bogzwcxOdNax071L18QqZnQQQA
-                                VVr+iLhGTnNGp3HoWQLUIzKrJVZ3zggy3WwNT6kZo6c0
-				tszYqbtvchmgQC8CzKojM/W16i6MG/ea fGU3siaOdS0
-				yOI6BgPsw+YZdzlYMaIJGf4M4dyoKIhzdZyQ2bYQrjyQ
-				4LB0lC7aOnsMyYKHHYeRv PxjIQXmdqgOJGq+vsevG06
-			        zW+1xgYJh9rCIfnm1GX/KMgxLPG2vXTD/RnLX+D3T3UL
-				7HJYHJhAZD5L59VvjSPsZJHeDCUyWYrvPZesZDIRvhDD
-				52SKvbheeTJUm6EhkzytNN2SN96QRk8j/iI8ib";
-};
-
-options {
-	...
-	dnssec-enable yes;
-	dnssec-validation yes;
-};
-</programlisting>
-
-	<note>
-	  None of the keys listed in this example are valid.  In particular,
-	  the root key is not valid.
-	</note>
-
-      </sect2>
-
-    </sect1>
-    <sect1>
-      <title>IPv6 Support in <acronym>BIND</acronym> 9</title>
-
-      <para>
-        <acronym>BIND</acronym> 9 fully supports all currently
-        defined forms of IPv6
-        name to address and address to name lookups.  It will also use
-        IPv6 addresses to make queries when running on an IPv6 capable
-        system.
-      </para>
-
-      <para>
-        For forward lookups, <acronym>BIND</acronym> 9 supports
-        only AAAA records.  RFC 3363 deprecated the use of A6 records,
-        and client-side support for A6 records was accordingly removed
-        from <acronym>BIND</acronym> 9.
-        However, authoritative <acronym>BIND</acronym> 9 name servers still
-        load zone files containing A6 records correctly, answer queries
-        for A6 records, and accept zone transfer for a zone containing A6
-        records.
-      </para>
-
-      <para>
-        For IPv6 reverse lookups, <acronym>BIND</acronym> 9 supports
-        the traditional "nibble" format used in the
-        <emphasis>ip6.arpa</emphasis> domain, as well as the older, deprecated
-        <emphasis>ip6.int</emphasis> domain.
-        Older versions of <acronym>BIND</acronym> 9 
-        supported the "binary label" (also known as "bitstring") format,
-        but support of binary labels has been completely removed per
-        RFC 3363.
-        Many applications in <acronym>BIND</acronym> 9 do not understand
-        the binary label format at all any more, and will return an
-        error if given.
-	In particular, an authoritative <acronym>BIND</acronym> 9
-        name server will not load a zone file containing binary labels.
-      </para>
-
-      <para>
-        For an overview of the format and structure of IPv6 addresses,
-        see <xref linkend="ipv6addresses"/>.
-      </para>
-
-      <sect2>
-        <title>Address Lookups Using AAAA Records</title>
-
-        <para>
-          The IPv6 AAAA record is a parallel to the IPv4 A record,
-          and, unlike the deprecated A6 record, specifies the entire
-          IPv6 address in a single record.  For example,
-        </para>
-
-<programlisting>
-$ORIGIN example.com.
-host            3600    IN      AAAA    2001:db8::1
-</programlisting>
-
-        <para>
-          Use of IPv4-in-IPv6 mapped addresses is not recommended.
-	  If a host has an IPv4 address, use an A record, not
-          a AAAA, with <literal>::ffff:192.168.42.1</literal> as
-          the address.
-        </para>
-      </sect2>
-      <sect2>
-        <title>Address to Name Lookups Using Nibble Format</title>
-
-        <para>
-          When looking up an address in nibble format, the address
-          components are simply reversed, just as in IPv4, and
-          <literal>ip6.arpa.</literal> is appended to the
-          resulting name.
-          For example, the following would provide reverse name lookup for
-          a host with address
-          <literal>2001:db8::1</literal>.
-        </para>
-
-<programlisting>
-$ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
-1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0   14400 IN      PTR     host.example.com.
-</programlisting>
-
-      </sect2>
-    </sect1>
-  </chapter>
-
-  <chapter id="Bv9ARM.ch05">
-    <title>The <acronym>BIND</acronym> 9 Lightweight Resolver</title>
-    <sect1>
-      <title>The Lightweight Resolver Library</title>
-      <para>
-        Traditionally applications have been linked with a stub resolver
-        library that sends recursive DNS queries to a local caching name
-        server.
-      </para>
-      <para>
-        IPv6 once introduced new complexity into the resolution process,
-        such as following A6 chains and DNAME records, and simultaneous
-        lookup of IPv4 and IPv6 addresses.  Though most of the complexity was
-        then removed, these are hard or impossible
-        to implement in a traditional stub resolver.
-      </para>
-      <para>
-        <acronym>BIND</acronym> 9 therefore can also provide resolution
-        services to local clients
-        using a combination of a lightweight resolver library and a resolver
-        daemon process running on the local host.  These communicate using
-        a simple UDP-based protocol, the "lightweight resolver protocol"
-        that is distinct from and simpler than the full DNS protocol.
-      </para>
-    </sect1>
-    <sect1 id="lwresd">
-      <title>Running a Resolver Daemon</title>
-
-      <para>
-        To use the lightweight resolver interface, the system must
-        run the resolver daemon <command>lwresd</command> or a
-        local
-        name server configured with a <command>lwres</command>
-        statement.
-      </para>
-
-      <para>
-        By default, applications using the lightweight resolver library will
-        make
-        UDP requests to the IPv4 loopback address (127.0.0.1) on port 921.
-        The
-        address can be overridden by <command>lwserver</command>
-        lines in
-        <filename>/etc/resolv.conf</filename>.
-      </para>
-
-      <para>
-        The daemon currently only looks in the DNS, but in the future
-        it may use other sources such as <filename>/etc/hosts</filename>,
-        NIS, etc.
-      </para>
-
-      <para>
-        The <command>lwresd</command> daemon is essentially a
-        caching-only name server that responds to requests using the
-        lightweight
-        resolver protocol rather than the DNS protocol.  Because it needs
-        to run on each host, it is designed to require no or minimal
-        configuration.
-        Unless configured otherwise, it uses the name servers listed on
-        <command>nameserver</command> lines in <filename>/etc/resolv.conf</filename>
-        as forwarders, but is also capable of doing the resolution
-        autonomously if
-        none are specified.
-      </para>
-      <para>
-        The <command>lwresd</command> daemon may also be
-        configured with a
-        <filename>named.conf</filename> style configuration file,
-        in
-        <filename>/etc/lwresd.conf</filename> by default.  A name
-        server may also
-        be configured to act as a lightweight resolver daemon using the
-        <command>lwres</command> statement in <filename>named.conf</filename>.
-      </para>
-
-    </sect1>
-  </chapter>
-
-  <chapter id="Bv9ARM.ch06">
-    <title><acronym>BIND</acronym> 9 Configuration Reference</title>
-
-    <para>
-      <acronym>BIND</acronym> 9 configuration is broadly similar
-      to <acronym>BIND</acronym> 8; however, there are a few new
-      areas
-      of configuration, such as views. <acronym>BIND</acronym>
-      8 configuration files should work with few alterations in <acronym>BIND</acronym>
-      9, although more complex configurations should be reviewed to check
-      if they can be more efficiently implemented using the new features
-      found in <acronym>BIND</acronym> 9.
-    </para>
-
-    <para>
-      <acronym>BIND</acronym> 4 configuration files can be
-      converted to the new format
-      using the shell script
-      <filename>contrib/named-bootconf/named-bootconf.sh</filename>.
-    </para>
-    <sect1 id="configuration_file_elements">
-      <title>Configuration File Elements</title>
-      <para>
-        Following is a list of elements used throughout the <acronym>BIND</acronym> configuration
-        file documentation:
-      </para>
-      <informaltable colsep="0" rowsep="0">
-        <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="2Level-table">
-          <colspec colname="1" colnum="1" colsep="0" colwidth="1.855in"/>
-          <colspec colname="2" colnum="2" colsep="0" colwidth="3.770in"/>
-          <tbody>
-            <row rowsep="0">
-              <entry colname="1">
-                <para>
-                  <varname>acl_name</varname>
-                </para>
-              </entry>
-              <entry colname="2">
-                <para>
-                  The name of an <varname>address_match_list</varname> as
-                  defined by the <command>acl</command> statement.
-                </para>
-              </entry>
-            </row>
-            <row rowsep="0">
-              <entry colname="1">
-                <para>
-                  <varname>address_match_list</varname>
-                </para>
-              </entry>
-              <entry colname="2">
-                <para>
-                  A list of one or more
-                  <varname>ip_addr</varname>,
-                  <varname>ip_prefix</varname>, <varname>key_id</varname>,
-                  or <varname>acl_name</varname> elements, see
-                  <xref linkend="address_match_lists"/>.
-                </para>
-              </entry>
-            </row>
-            <row rowsep="0">
-              <entry colname="1">
-                <para>
-                  <varname>masters_list</varname>
-                </para>
-              </entry>
-              <entry colname="2">
-                <para>
-                  A named list of one or more <varname>ip_addr</varname>
-		  with optional <varname>key_id</varname> and/or
-		  <varname>ip_port</varname>.
-		  A <varname>masters_list</varname> may include other
-		  <varname>masters_lists</varname>.
-                </para>
-              </entry>
-            </row>
-            <row rowsep="0">
-              <entry colname="1">
-                <para>
-                  <varname>domain_name</varname>
-                </para>
-              </entry>
-              <entry colname="2">
-                <para>
-                  A quoted string which will be used as
-                  a DNS name, for example "<literal>my.test.domain</literal>".
-                </para>
-              </entry>
-            </row>
-            <row rowsep="0">
-              <entry colname="1">
-                <para>
-                  <varname>dotted_decimal</varname>
-                </para>
-              </entry>
-              <entry colname="2">
-                <para>
-                  One to four integers valued 0 through
-                  255 separated by dots (`.'), such as <command>123</command>,
-                  <command>45.67</command> or <command>89.123.45.67</command>.
-                </para>
-              </entry>
-            </row>
-            <row rowsep="0">
-              <entry colname="1">
-                <para>
-                  <varname>ip4_addr</varname>
-                </para>
-              </entry>
-              <entry colname="2">
-                <para>
-                  An IPv4 address with exactly four elements
-                  in <varname>dotted_decimal</varname> notation.
-                </para>
-              </entry>
-            </row>
-            <row rowsep="0">
-              <entry colname="1">
-                <para>
-                  <varname>ip6_addr</varname>
-                </para>
-              </entry>
-              <entry colname="2">
-                <para>
-                  An IPv6 address, such as <command>2001:db8::1234</command>.
-                  IPv6 scoped addresses that have ambiguity on their scope
-                  zones must be
-                  disambiguated by an appropriate zone ID with the percent
-                  character
-                  (`%') as delimiter.
-                  It is strongly recommended to use string zone names rather
-                  than
-                  numeric identifiers, in order to be robust against system
-                  configuration changes.
-                  However, since there is no standard mapping for such names
-                  and
-                  identifier values, currently only interface names as link
-                  identifiers
-                  are supported, assuming one-to-one mapping between
-                  interfaces and links.
-                  For example, a link-local address <command>fe80::1</command> on the
-                  link attached to the interface <command>ne0</command>
-                  can be specified as <command>fe80::1%ne0</command>.
-                  Note that on most systems link-local addresses always have
-                  the
-                  ambiguity, and need to be disambiguated.
-                </para>
-              </entry>
-            </row>
-            <row rowsep="0">
-              <entry colname="1">
-                <para>
-                  <varname>ip_addr</varname>
-                </para>
-              </entry>
-              <entry colname="2">
-                <para>
-                  An <varname>ip4_addr</varname> or <varname>ip6_addr</varname>.
-                </para>
-              </entry>
-            </row>
-            <row rowsep="0">
-              <entry colname="1">
-                <para>
-                  <varname>ip_port</varname>
-                </para>
-              </entry>
-              <entry colname="2">
-                <para>
-                  An IP port <varname>number</varname>.
-                  The <varname>number</varname> is limited to 0
-                  through 65535, with values
-                  below 1024 typically restricted to use by processes running
-                  as root.
-                  In some cases, an asterisk (`*') character can be used as a
-                  placeholder to
-                  select a random high-numbered port.
-                </para>
-              </entry>
-            </row>
-            <row rowsep="0">
-              <entry colname="1">
-                <para>
-                  <varname>ip_prefix</varname>
-                </para>
-              </entry>
-              <entry colname="2">
-                <para>
-                  An IP network specified as an <varname>ip_addr</varname>,
-                  followed by a slash (`/') and then the number of bits in the
-                  netmask.
-                  Trailing zeros in a <varname>ip_addr</varname>
-                  may omitted.
-                  For example, <command>127/8</command> is the
-                  network <command>127.0.0.0</command> with
-                  netmask <command>255.0.0.0</command> and <command>1.2.3.0/28</command> is
-                  network <command>1.2.3.0</command> with netmask <command>255.255.255.240</command>.
-                </para>
-              </entry>
-            </row>
-            <row rowsep="0">
-              <entry colname="1">
-                <para>
-                  <varname>key_id</varname>
-                </para>
-              </entry>
-              <entry colname="2">
-                <para>
-                  A <varname>domain_name</varname> representing
-                  the name of a shared key, to be used for transaction
-                  security.
-                </para>
-              </entry>
-            </row>
-            <row rowsep="0">
-              <entry colname="1">
-                <para>
-                  <varname>key_list</varname>
-                </para>
-              </entry>
-              <entry colname="2">
-                <para>
-                  A list of one or more
-                  <varname>key_id</varname>s,
-                  separated by semicolons and ending with a semicolon.
-                </para>
-              </entry>
-            </row>
-            <row rowsep="0">
-              <entry colname="1">
-                <para>
-                  <varname>number</varname>
-                </para>
-              </entry>
-              <entry colname="2">
-                <para>
-                  A non-negative 32-bit integer
-                  (i.e., a number between 0 and 4294967295, inclusive).
-                  Its acceptable value might further
-                  be limited by the context in which it is used.
-                </para>
-              </entry>
-            </row>
-            <row rowsep="0">
-              <entry colname="1">
-                <para>
-                  <varname>path_name</varname>
-                </para>
-              </entry>
-              <entry colname="2">
-                <para>
-                  A quoted string which will be used as
-                  a pathname, such as <filename>zones/master/my.test.domain</filename>.
-                </para>
-              </entry>
-            </row>
-            <row rowsep="0">
-              <entry colname="1">
-                <para>
-                  <varname>size_spec</varname>
-                </para>
-              </entry>
-              <entry colname="2">
-                <para>
-                  A number, the word <userinput>unlimited</userinput>,
-                  or the word <userinput>default</userinput>.
-                </para>
-		<para>
-                  An <varname>unlimited</varname> <varname>size_spec</varname> requests unlimited
-                  use, or the maximum available amount. A <varname>default size_spec</varname> uses
-                  the limit that was in force when the server was started.
-                </para>
-                <para>
-                  A <varname>number</varname> can optionally be
-		  followed by a scaling factor:
-		  <userinput>K</userinput> or <userinput>k</userinput>
-		  for kilobytes,
-		  <userinput>M</userinput> or <userinput>m</userinput>
-		  for megabytes, and
-		  <userinput>G</userinput> or <userinput>g</userinput> for gigabytes,
-                  which scale by 1024, 1024*1024, and 1024*1024*1024
-                  respectively.
-                </para>
-                <para>
-                  The value must be representable as a 64-bit unsigned integer
-                  (0 to 18446744073709551615, inclusive).
-                  Using <varname>unlimited</varname> is the best
-                  way
-                  to safely set a really large number.
-                </para>
-              </entry>
-            </row>
-            <row rowsep="0">
-              <entry colname="1">
-                <para>
-                  <varname>yes_or_no</varname>
-                </para>
-              </entry>
-              <entry colname="2">
-                <para>
-                  Either <userinput>yes</userinput> or <userinput>no</userinput>.
-                  The words <userinput>true</userinput> and <userinput>false</userinput> are
-                  also accepted, as are the numbers <userinput>1</userinput>
-                  and <userinput>0</userinput>.
-                </para>
-              </entry>
-            </row>
-            <row rowsep="0">
-              <entry colname="1">
-                <para>
-                  <varname>dialup_option</varname>
-                </para>
-              </entry>
-              <entry colname="2">
-                <para>
-                  One of <userinput>yes</userinput>,
-                  <userinput>no</userinput>, <userinput>notify</userinput>,
-                  <userinput>notify-passive</userinput>, <userinput>refresh</userinput> or
-                  <userinput>passive</userinput>.
-                  When used in a zone, <userinput>notify-passive</userinput>,
-                  <userinput>refresh</userinput>, and <userinput>passive</userinput>
-                  are restricted to slave and stub zones.
-                </para>
-              </entry>
-            </row>
-          </tbody>
-        </tgroup>
-      </informaltable>
-      <sect2 id="address_match_lists">
-        <title>Address Match Lists</title>
-        <sect3>
-          <title>Syntax</title>
-
-<programlisting><varname>address_match_list</varname> = address_match_list_element ;
-  <optional> address_match_list_element; ... </optional>
-<varname>address_match_list_element</varname> = <optional> ! </optional> (ip_address <optional>/length</optional> |
-   key key_id | acl_name | { address_match_list } )
-</programlisting>
-
-        </sect3>
-        <sect3>
-          <title>Definition and Usage</title>
-          <para>
-            Address match lists are primarily used to determine access
-            control for various server operations. They are also used in
-            the <command>listen-on</command> and <command>sortlist</command>
-            statements. The elements
-            which constitute an address match list can be any of the
-            following:
-          </para>
-          <itemizedlist>
-            <listitem>
-              <simpara>an IP address (IPv4 or IPv6)</simpara>
-            </listitem>
-            <listitem>
-              <simpara>an IP prefix (in `/' notation)</simpara>
-            </listitem>
-            <listitem>
-              <simpara>
-                a key ID, as defined by the <command>key</command>
-                statement
-              </simpara>
-            </listitem>
-            <listitem>
-              <simpara>the name of an address match list defined with
-                the <command>acl</command> statement
-              </simpara>
-            </listitem>
-            <listitem>
-              <simpara>a nested address match list enclosed in braces</simpara>
-            </listitem>
-          </itemizedlist>
-
-          <para>
-            Elements can be negated with a leading exclamation mark (`!'),
-            and the match list names "any", "none", "localhost", and
-            "localnets"
-            are predefined. More information on those names can be found in
-            the description of the acl statement.
-          </para>
-
-          <para>
-            The addition of the key clause made the name of this syntactic
-            element something of a misnomer, since security keys can be used
-            to validate access without regard to a host or network address.
-            Nonetheless,
-            the term "address match list" is still used throughout the
-            documentation.
-          </para>
-
-          <para>
-            When a given IP address or prefix is compared to an address
-            match list, the list is traversed in order until an element
-            matches.
-            The interpretation of a match depends on whether the list is being
-            used
-            for access control, defining listen-on ports, or in a sortlist,
-            and whether the element was negated.
-          </para>
-
-	  <para>
-	    When used as an access control list, a non-negated match
-	    allows access and a negated match denies access. If
-	    there is no match, access is denied. The clauses
-	    <command>allow-notify</command>,
-	    <command>allow-query</command>,
-	    <command>allow-query-cache</command>,
-	    <command>allow-transfer</command>,
-	    <command>allow-update</command>,
-	    <command>allow-update-forwarding</command>, and
-	    <command>blackhole</command> all use address match
-	    lists.  Similarly, the listen-on option will cause the
-	    server to not accept queries on any of the machine's
-	    addresses which do not match the list.
-	  </para>
-
-          <para>
-            Because of the first-match aspect of the algorithm, an element
-            that defines a subset of another element in the list should come
-            before the broader element, regardless of whether either is
-            negated. For
-            example, in
-            <command>1.2.3/24; ! 1.2.3.13;</command> the 1.2.3.13
-            element is
-            completely useless because the algorithm will match any lookup for
-            1.2.3.13 to the 1.2.3/24 element.
-            Using <command>! 1.2.3.13; 1.2.3/24</command> fixes
-            that problem by having 1.2.3.13 blocked by the negation but all
-            other 1.2.3.* hosts fall through.
-          </para>
-        </sect3>
-      </sect2>
-
-      <sect2>
-        <title>Comment Syntax</title>
-
-        <para>
-          The <acronym>BIND</acronym> 9 comment syntax allows for
-          comments to appear
-          anywhere that whitespace may appear in a <acronym>BIND</acronym> configuration
-          file. To appeal to programmers of all kinds, they can be written
-          in the C, C++, or shell/perl style.
-        </para>
-
-        <sect3>
-          <title>Syntax</title>
-
-          <para>
-            <programlisting>/* This is a <acronym>BIND</acronym> comment as in C */</programlisting>
-            <programlisting>// This is a <acronym>BIND</acronym> comment as in C++</programlisting>
-            <programlisting># This is a <acronym>BIND</acronym> comment as in common UNIX shells and perl</programlisting>
-          </para>
-        </sect3>
-        <sect3>
-          <title>Definition and Usage</title>
-          <para>
-            Comments may appear anywhere that whitespace may appear in
-            a <acronym>BIND</acronym> configuration file.
-          </para>
-          <para>
-            C-style comments start with the two characters /* (slash,
-            star) and end with */ (star, slash). Because they are completely
-            delimited with these characters, they can be used to comment only
-            a portion of a line or to span multiple lines.
-          </para>
-          <para>
-            C-style comments cannot be nested. For example, the following
-            is not valid because the entire comment ends with the first */:
-          </para>
-          <para>
-
-<programlisting>/* This is the start of a comment.
-   This is still part of the comment.
-/* This is an incorrect attempt at nesting a comment. */
-   This is no longer in any comment. */
-</programlisting>
-
-          </para>
-
-          <para>
-            C++-style comments start with the two characters // (slash,
-            slash) and continue to the end of the physical line. They cannot
-            be continued across multiple physical lines; to have one logical
-            comment span multiple lines, each line must use the // pair.
-          </para>
-          <para>
-            For example:
-          </para>
-          <para>
-
-<programlisting>// This is the start of a comment.  The next line
-// is a new comment, even though it is logically
-// part of the previous comment.
-</programlisting>
-
-          </para>
-          <para>
-            Shell-style (or perl-style, if you prefer) comments start
-            with the character <literal>#</literal> (number sign)
-            and continue to the end of the
-            physical line, as in C++ comments.
-          </para>
-          <para>
-            For example:
-          </para>
-
-          <para>
-
-<programlisting># This is the start of a comment.  The next line
-# is a new comment, even though it is logically
-# part of the previous comment.
-</programlisting>
-
-          </para>
-
-          <warning>
-            <para>
-              You cannot use the semicolon (`;') character
-              to start a comment such as you would in a zone file. The
-              semicolon indicates the end of a configuration
-              statement.
-            </para>
-          </warning>
-        </sect3>
-      </sect2>
-    </sect1>
-
-    <sect1 id="Configuration_File_Grammar">
-      <title>Configuration File Grammar</title>
-
-      <para>
-        A <acronym>BIND</acronym> 9 configuration consists of
-        statements and comments.
-        Statements end with a semicolon. Statements and comments are the
-        only elements that can appear without enclosing braces. Many
-        statements contain a block of sub-statements, which are also
-        terminated with a semicolon.
-      </para>
-
-      <para>
-        The following statements are supported:
-      </para>
-
-      <informaltable colsep="0" rowsep="0">
-        <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="2Level-table">
-          <colspec colname="1" colnum="1" colsep="0" colwidth="1.336in"/>
-          <colspec colname="2" colnum="2" colsep="0" colwidth="3.778in"/>
-          <tbody>
-            <row rowsep="0">
-              <entry colname="1">
-                <para><command>acl</command></para>
-              </entry>
-              <entry colname="2">
-                <para>
-                  defines a named IP address
-                  matching list, for access control and other uses.
-                </para>
-              </entry>
-            </row>
-            <row rowsep="0">
-              <entry colname="1">
-                <para><command>controls</command></para>
-              </entry>
-              <entry colname="2">
-                <para>
-                  declares control channels to be used
-                  by the <command>rndc</command> utility.
-                </para>
-              </entry>
-            </row>
-            <row rowsep="0">
-              <entry colname="1">
-                <para><command>include</command></para>
-              </entry>
-              <entry colname="2">
-                <para>
-                  includes a file.
-                </para>
-              </entry>
-            </row>
-            <row rowsep="0">
-              <entry colname="1">
-                <para><command>key</command></para>
-              </entry>
-              <entry colname="2">
-                <para>
-                  specifies key information for use in
-                  authentication and authorization using TSIG.
-                </para>
-              </entry>
-            </row>
-            <row rowsep="0">
-              <entry colname="1">
-                <para><command>logging</command></para>
-              </entry>
-              <entry colname="2">
-                <para>
-                  specifies what the server logs, and where
-                  the log messages are sent.
-                </para>
-              </entry>
-            </row>
-            <row rowsep="0">
-              <entry colname="1">
-                <para><command>lwres</command></para>
-              </entry>
-              <entry colname="2">
-                <para>
-                  configures <command>named</command> to
-                  also act as a light-weight resolver daemon (<command>lwresd</command>).
-                </para>
-              </entry>
-            </row>
-            <row rowsep="0">
-              <entry colname="1">
-                <para><command>masters</command></para>
-              </entry>
-              <entry colname="2">
-                <para>
-                  defines a named masters list for
-                  inclusion in stub and slave zone masters clauses.
-                </para>
-              </entry>
-            </row>
-            <row rowsep="0">
-              <entry colname="1">
-                <para><command>options</command></para>
-              </entry>
-              <entry colname="2">
-                <para>
-                  controls global server configuration
-                  options and sets defaults for other statements.
-                </para>
-              </entry>
-            </row>
-            <row rowsep="0">
-              <entry colname="1">
-                <para><command>server</command></para>
-              </entry>
-              <entry colname="2">
-                <para>
-                  sets certain configuration options on
-                  a per-server basis.
-                </para>
-              </entry>
-            </row>
-            <row rowsep="0">
-              <entry colname="1">
-                <para><command>trusted-keys</command></para>
-              </entry>
-              <entry colname="2">
-                <para>
-                  defines trusted DNSSEC keys.
-                </para>
-              </entry>
-            </row>
-            <row rowsep="0">
-              <entry colname="1">
-                <para><command>view</command></para>
-              </entry>
-              <entry colname="2">
-                <para>
-                  defines a view.
-                </para>
-              </entry>
-            </row>
-            <row rowsep="0">
-              <entry colname="1">
-                <para><command>zone</command></para>
-              </entry>
-              <entry colname="2">
-                <para>
-                  defines a zone.
-                </para>
-              </entry>
-            </row>
-          </tbody>
-        </tgroup>
-      </informaltable>
-
-      <para>
-        The <command>logging</command> and
-        <command>options</command> statements may only occur once
-        per
-        configuration.
-      </para>
-
-      <sect2>
-        <title><command>acl</command> Statement Grammar</title>
-
-<programlisting><command>acl</command> acl-name {
-    address_match_list
-};
-</programlisting>
-
-      </sect2>
-      <sect2 id="acl">
-        <title><command>acl</command> Statement Definition and
-          Usage</title>
-
-        <para>
-          The <command>acl</command> statement assigns a symbolic
-          name to an address match list. It gets its name from a primary
-          use of address match lists: Access Control Lists (ACLs).
-        </para>
-
-        <para>
-          Note that an address match list's name must be defined
-          with <command>acl</command> before it can be used
-          elsewhere; no
-          forward references are allowed.
-        </para>
-
-        <para>
-          The following ACLs are built-in:
-        </para>
-
-        <informaltable colsep="0" rowsep="0">
-          <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="3Level-table">
-            <colspec colname="1" colnum="1" colsep="0" colwidth="1.130in"/>
-            <colspec colname="2" colnum="2" colsep="0" colwidth="4.000in"/>
-            <tbody>
-              <row rowsep="0">
-                <entry colname="1">
-                  <para><command>any</command></para>
-                </entry>
-                <entry colname="2">
-                  <para>
-                    Matches all hosts.
-                  </para>
-                </entry>
-              </row>
-              <row rowsep="0">
-                <entry colname="1">
-                  <para><command>none</command></para>
-                </entry>
-                <entry colname="2">
-                  <para>
-                    Matches no hosts.
-                  </para>
-                </entry>
-              </row>
-              <row rowsep="0">
-                <entry colname="1">
-                  <para><command>localhost</command></para>
-                </entry>
-                <entry colname="2">
-                  <para>
-                    Matches the IPv4 and IPv6 addresses of all network
-                    interfaces on the system.
-                  </para>
-                </entry>
-              </row>
-              <row rowsep="0">
-                <entry colname="1">
-                  <para><command>localnets</command></para>
-                </entry>
-                <entry colname="2">
-                  <para>
-                    Matches any host on an IPv4 or IPv6 network
-                    for which the system has an interface.
-                    Some systems do not provide a way to determine the prefix
-                    lengths of
-                    local IPv6 addresses.
-                    In such a case, <command>localnets</command>
-                    only matches the local
-                    IPv6 addresses, just like <command>localhost</command>.
-                  </para>
-                </entry>
-              </row>
-            </tbody>
-          </tgroup>
-        </informaltable>
-
-      </sect2>
-      <sect2>
-        <title><command>controls</command> Statement Grammar</title>
-
-<programlisting><command>controls</command> {
-   [ inet ( ip_addr | * ) [ port ip_port ] allow { <replaceable> address_match_list </replaceable> }
-                keys { <replaceable>key_list</replaceable> }; ]
-   [ inet ...; ]
-   [ unix <replaceable>path</replaceable> perm <replaceable>number</replaceable> owner <replaceable>number</replaceable> group <replaceable>number</replaceable> keys { <replaceable>key_list</replaceable> }; ]
-   [ unix ...; ]
-};
-</programlisting>
-
-      </sect2>
-
-      <sect2 id="controls_statement_definition_and_usage">
-        <title><command>controls</command> Statement Definition and
-          Usage</title>
-
-        <para>
-          The <command>controls</command> statement declares control
-          channels to be used by system administrators to control the
-          operation of the name server. These control channels are
-          used by the <command>rndc</command> utility to send
-          commands to and retrieve non-DNS results from a name server.
-        </para>
-
-        <para>
-          An <command>inet</command> control channel is a TCP socket
-	  listening at the specified <command>ip_port</command> on the
-	  specified <command>ip_addr</command>, which can be an IPv4 or IPv6
-	  address.  An <command>ip_addr</command> of <literal>*</literal> (asterisk) is
-	  interpreted as the IPv4 wildcard address; connections will be
-	  accepted on any of the system's IPv4 addresses.
-	  To listen on the IPv6 wildcard address,
-          use an <command>ip_addr</command> of <literal>::</literal>.
-          If you will only use <command>rndc</command> on the local host,
-          using the loopback address (<literal>127.0.0.1</literal>
-          or <literal>::1</literal>) is recommended for maximum security.
-        </para>
-
-        <para>
-          If no port is specified, port 953 is used. The asterisk
-	  "<literal>*</literal>" cannot be used for <command>ip_port</command>.
-        </para>
-
-        <para>
-          The ability to issue commands over the control channel is
-          restricted by the <command>allow</command> and
-          <command>keys</command> clauses.
-	  Connections to the control channel are permitted based on the
-          <command>address_match_list</command>.  This is for simple
-          IP address based filtering only; any <command>key_id</command>
-          elements of the <command>address_match_list</command>
-          are ignored.
-        </para>
-
-	<para>
-	  A <command>unix</command> control channel is a UNIX domain
-	  socket listening at the specified path in the file system.
-	  Access to the socket is specified by the <command>perm</command>,
-	  <command>owner</command> and <command>group</command> clauses.
-	  Note on some platforms (SunOS and Solaris) the permissions
-	  (<command>perm</command>) are applied to the parent directory
-	  as the permissions on the socket itself are ignored.
-	</para>
-
-        <para>
-          The primary authorization mechanism of the command
-          channel is the <command>key_list</command>, which
-          contains a list of <command>key_id</command>s.
-          Each <command>key_id</command> in the <command>key_list</command>
-	  is authorized to execute commands over the control channel.
-          See <xref linkend="rndc"/> in <xref linkend="admin_tools"/>)
-	  for information about configuring keys in <command>rndc</command>.
-        </para>
-
-        <para>
-          If no <command>controls</command> statement is present,
-          <command>named</command> will set up a default
-          control channel listening on the loopback address 127.0.0.1
-          and its IPv6 counterpart ::1.
-          In this case, and also when the <command>controls</command> statement
-          is present but does not have a <command>keys</command> clause,
-          <command>named</command> will attempt to load the command channel key
-          from the file <filename>rndc.key</filename> in
-          <filename>/etc</filename> (or whatever <varname>sysconfdir</varname>
-          was specified as when <acronym>BIND</acronym> was built).
-          To create a <filename>rndc.key</filename> file, run
-          <userinput>rndc-confgen -a</userinput>.
-        </para>
-
-        <para>
-          The <filename>rndc.key</filename> feature was created to
-          ease the transition of systems from <acronym>BIND</acronym> 8,
-          which did not have digital signatures on its command channel
-          messages and thus did not have a <command>keys</command> clause.
-
-          It makes it possible to use an existing <acronym>BIND</acronym> 8
-          configuration file in <acronym>BIND</acronym> 9 unchanged,
-          and still have <command>rndc</command> work the same way
-          <command>ndc</command> worked in BIND 8, simply by executing the
-          command <userinput>rndc-confgen -a</userinput> after BIND 9 is
-          installed.
-        </para>
-
-        <para>
-          Since the <filename>rndc.key</filename> feature
-          is only intended to allow the backward-compatible usage of
-          <acronym>BIND</acronym> 8 configuration files, this
-          feature does not
-          have a high degree of configurability.  You cannot easily change
-          the key name or the size of the secret, so you should make a
-          <filename>rndc.conf</filename> with your own key if you
-          wish to change
-          those things.  The <filename>rndc.key</filename> file
-          also has its
-          permissions set such that only the owner of the file (the user that
-          <command>named</command> is running as) can access it.
-          If you
-          desire greater flexibility in allowing other users to access
-          <command>rndc</command> commands, then you need to create
-          a
-          <filename>rndc.conf</filename> file and make it group
-          readable by a group
-          that contains the users who should have access.
-        </para>
-
-        <para>
-          To disable the command channel, use an empty
-	  <command>controls</command> statement:
-	  <command>controls { };</command>.
-        </para>
-
-      </sect2>
-      <sect2>
-        <title><command>include</command> Statement Grammar</title>
-        <programlisting>include <replaceable>filename</replaceable>;</programlisting>
-      </sect2>
-      <sect2>
-        <title><command>include</command> Statement Definition and
-          Usage</title>
-
-        <para>
-          The <command>include</command> statement inserts the
-          specified file at the point where the <command>include</command>
-          statement is encountered. The <command>include</command>
-                statement facilitates the administration of configuration
-          files
-          by permitting the reading or writing of some things but not
-          others. For example, the statement could include private keys
-          that are readable only by the name server.
-        </para>
-
-      </sect2>
-      <sect2>
-        <title><command>key</command> Statement Grammar</title>
-
-<programlisting>key <replaceable>key_id</replaceable> {
-    algorithm <replaceable>string</replaceable>;
-    secret <replaceable>string</replaceable>;
-};
-</programlisting>
-
-      </sect2>
-
-      <sect2>
-        <title><command>key</command> Statement Definition and Usage</title>
-
-        <para>
-          The <command>key</command> statement defines a shared
-          secret key for use with TSIG (see <xref linkend="tsig"/>)
-          or the command channel
-          (see <xref linkend="controls_statement_definition_and_usage"/>).
-        </para>
-
-        <para>
-          The <command>key</command> statement can occur at the
-          top level
-          of the configuration file or inside a <command>view</command>
-          statement.  Keys defined in top-level <command>key</command>
-          statements can be used in all views.  Keys intended for use in
-          a <command>controls</command> statement
-          (see <xref linkend="controls_statement_definition_and_usage"/>)
-          must be defined at the top level.
-        </para>
-
-        <para>
-          The <replaceable>key_id</replaceable>, also known as the
-          key name, is a domain name uniquely identifying the key. It can
-          be used in a <command>server</command>
-          statement to cause requests sent to that
-          server to be signed with this key, or in address match lists to
-          verify that incoming requests have been signed with a key
-          matching this name, algorithm, and secret.
-        </para>
-
-	<para>
-	  The <replaceable>algorithm_id</replaceable> is a string
-	  that specifies a security/authentication algorithm.  Named
-	  supports <literal>hmac-md5</literal>,
-	  <literal>hmac-sha1</literal>, <literal>hmac-sha224</literal>,
-	  <literal>hmac-sha256</literal>, <literal>hmac-sha384</literal>
-	  and <literal>hmac-sha512</literal> TSIG authentication.
-	  Truncated hashes are supported by appending the minimum
-	  number of required bits preceded by a dash, e.g.
-	  <literal>hmac-sha1-80</literal>.  The
-	  <replaceable>secret_string</replaceable> is the secret
-	  to be used by the algorithm, and is treated as a base-64
-	  encoded string.
-	</para>
-
-      </sect2>
-      <sect2>
-        <title><command>logging</command> Statement Grammar</title>
-
-<programlisting><command>logging</command> {
-   [ <command>channel</command> <replaceable>channel_name</replaceable> {
-     ( <command>file</command> <replaceable>path name</replaceable>
-         [ <command>versions</command> ( <replaceable>number</replaceable> | <command>unlimited</command> ) ]
-         [ <command>size</command> <replaceable>size spec</replaceable> ]
-       | <command>syslog</command> <replaceable>syslog_facility</replaceable>
-       | <command>stderr</command>
-       | <command>null</command> );
-     [ <command>severity</command> (<option>critical</option> | <option>error</option> | <option>warning</option> | <option>notice</option> |
-                 <option>info</option> | <option>debug</option> [ <replaceable>level</replaceable> ] | <option>dynamic</option> ); ]
-     [ <command>print-category</command> <option>yes</option> or <option>no</option>; ]
-     [ <command>print-severity</command> <option>yes</option> or <option>no</option>; ]
-     [ <command>print-time</command> <option>yes</option> or <option>no</option>; ]
-   }; ]
-   [ <command>category</command> <replaceable>category_name</replaceable> {
-     <replaceable>channel_name</replaceable> ; [ <replaceable>channel_name</replaceable> ; ... ]
-   }; ]
-   ...
-};
-</programlisting>
-
-      </sect2>
-
-      <sect2>
-        <title><command>logging</command> Statement Definition and
-          Usage</title>
-
-        <para>
-          The <command>logging</command> statement configures a
-          wide
-          variety of logging options for the name server. Its <command>channel</command> phrase
-          associates output methods, format options and severity levels with
-          a name that can then be used with the <command>category</command> phrase
-          to select how various classes of messages are logged.
-        </para>
-        <para>
-          Only one <command>logging</command> statement is used to
-          define
-          as many channels and categories as are wanted. If there is no <command>logging</command> statement,
-          the logging configuration will be:
-        </para>
-
-<programlisting>logging {
-     category default { default_syslog; default_debug; };
-     category unmatched { null; };
-};
-</programlisting>
-
-        <para>
-          In <acronym>BIND</acronym> 9, the logging configuration
-          is only established when
-          the entire configuration file has been parsed.  In <acronym>BIND</acronym> 8, it was
-          established as soon as the <command>logging</command>
-          statement
-          was parsed. When the server is starting up, all logging messages
-          regarding syntax errors in the configuration file go to the default
-          channels, or to standard error if the "<option>-g</option>" option
-          was specified.
-        </para>
-
-        <sect3>
-          <title>The <command>channel</command> Phrase</title>
-
-          <para>
-            All log output goes to one or more <emphasis>channels</emphasis>;
-            you can make as many of them as you want.
-          </para>
-
-          <para>
-            Every channel definition must include a destination clause that
-            says whether messages selected for the channel go to a file, to a
-            particular syslog facility, to the standard error stream, or are
-            discarded. It can optionally also limit the message severity level
-            that will be accepted by the channel (the default is
-            <command>info</command>), and whether to include a
-            <command>named</command>-generated time stamp, the
-            category name
-            and/or severity level (the default is not to include any).
-          </para>
-
-          <para>
-            The <command>null</command> destination clause
-            causes all messages sent to the channel to be discarded;
-            in that case, other options for the channel are meaningless.
-          </para>
-
-          <para>
-            The <command>file</command> destination clause directs
-            the channel
-            to a disk file.  It can include limitations
-            both on how large the file is allowed to become, and how many
-            versions
-            of the file will be saved each time the file is opened.
-          </para>
-
-          <para>
-            If you use the <command>versions</command> log file
-            option, then
-            <command>named</command> will retain that many backup
-            versions of the file by
-            renaming them when opening.  For example, if you choose to keep
-            three old versions
-            of the file <filename>lamers.log</filename>, then just
-            before it is opened
-            <filename>lamers.log.1</filename> is renamed to
-            <filename>lamers.log.2</filename>, <filename>lamers.log.0</filename> is renamed
-            to <filename>lamers.log.1</filename>, and <filename>lamers.log</filename> is
-            renamed to <filename>lamers.log.0</filename>.
-            You can say <command>versions unlimited</command> to
-            not limit
-            the number of versions.
-            If a <command>size</command> option is associated with
-            the log file,
-            then renaming is only done when the file being opened exceeds the
-            indicated size.  No backup versions are kept by default; any
-            existing
-            log file is simply appended.
-          </para>
-
-          <para>
-            The <command>size</command> option for files is used
-            to limit log
-            growth. If the file ever exceeds the size, then <command>named</command> will
-            stop writing to the file unless it has a <command>versions</command> option
-            associated with it.  If backup versions are kept, the files are
-            rolled as
-            described above and a new one begun.  If there is no
-            <command>versions</command> option, no more data will
-            be written to the log
-            until some out-of-band mechanism removes or truncates the log to
-            less than the
-            maximum size.  The default behavior is not to limit the size of
-            the
-            file.
-          </para>
-
-          <para>
-            Example usage of the <command>size</command> and
-            <command>versions</command> options:
-          </para>
-
-<programlisting>channel an_example_channel {
-    file "example.log" versions 3 size 20m;
-    print-time yes;
-    print-category yes;
-};
-</programlisting>
-
-          <para>
-            The <command>syslog</command> destination clause
-            directs the
-            channel to the system log.  Its argument is a
-            syslog facility as described in the <command>syslog</command> man
-            page. Known facilities are <command>kern</command>, <command>user</command>,
-            <command>mail</command>, <command>daemon</command>, <command>auth</command>,
-            <command>syslog</command>, <command>lpr</command>, <command>news</command>,
-            <command>uucp</command>, <command>cron</command>, <command>authpriv</command>,
-            <command>ftp</command>, <command>local0</command>, <command>local1</command>,
-            <command>local2</command>, <command>local3</command>, <command>local4</command>,
-            <command>local5</command>, <command>local6</command> and
-            <command>local7</command>, however not all facilities
-            are supported on
-            all operating systems.
-            How <command>syslog</command> will handle messages
-            sent to
-            this facility is described in the <command>syslog.conf</command> man
-            page. If you have a system which uses a very old version of <command>syslog</command> that
-            only uses two arguments to the <command>openlog()</command> function,
-            then this clause is silently ignored.
-          </para>
-          <para>
-            The <command>severity</command> clause works like <command>syslog</command>'s
-            "priorities", except that they can also be used if you are writing
-            straight to a file rather than using <command>syslog</command>.
-            Messages which are not at least of the severity level given will
-            not be selected for the channel; messages of higher severity
-            levels
-            will be accepted.
-          </para>
-          <para>
-            If you are using <command>syslog</command>, then the <command>syslog.conf</command> priorities
-            will also determine what eventually passes through. For example,
-            defining a channel facility and severity as <command>daemon</command> and <command>debug</command> but
-            only logging <command>daemon.warning</command> via <command>syslog.conf</command> will
-            cause messages of severity <command>info</command> and
-            <command>notice</command> to
-            be dropped. If the situation were reversed, with <command>named</command> writing
-            messages of only <command>warning</command> or higher,
-            then <command>syslogd</command> would
-            print all messages it received from the channel.
-          </para>
-
-          <para>
-            The <command>stderr</command> destination clause
-            directs the
-            channel to the server's standard error stream.  This is intended
-            for
-            use when the server is running as a foreground process, for
-            example
-            when debugging a configuration.
-          </para>
-
-          <para>
-            The server can supply extensive debugging information when
-            it is in debugging mode. If the server's global debug level is
-            greater
-            than zero, then debugging mode will be active. The global debug
-            level is set either by starting the <command>named</command> server
-            with the <option>-d</option> flag followed by a positive integer,
-            or by running <command>rndc trace</command>.
-            The global debug level
-            can be set to zero, and debugging mode turned off, by running <command>rndc
-notrace</command>. All debugging messages in the server have a debug
-            level, and higher debug levels give more detailed output. Channels
-            that specify a specific debug severity, for example:
-          </para>
-
-<programlisting>channel specific_debug_level {
-    file "foo";
-    severity debug 3;
-};
-</programlisting>
-
-          <para>
-            will get debugging output of level 3 or less any time the
-            server is in debugging mode, regardless of the global debugging
-            level. Channels with <command>dynamic</command>
-            severity use the
-            server's global debug level to determine what messages to print.
-          </para>
-          <para>
-            If <command>print-time</command> has been turned on,
-            then
-            the date and time will be logged. <command>print-time</command> may
-            be specified for a <command>syslog</command> channel,
-            but is usually
-            pointless since <command>syslog</command> also prints
-            the date and
-            time. If <command>print-category</command> is
-            requested, then the
-            category of the message will be logged as well. Finally, if <command>print-severity</command> is
-            on, then the severity level of the message will be logged. The <command>print-</command> options may
-            be used in any combination, and will always be printed in the
-            following
-            order: time, category, severity. Here is an example where all
-            three <command>print-</command> options
-            are on:
-          </para>
-
-          <para>
-            <computeroutput>28-Feb-2000 15:05:32.863 general: notice: running</computeroutput>
-          </para>
-
-          <para>
-            There are four predefined channels that are used for
-            <command>named</command>'s default logging as follows.
-            How they are
-            used is described in <xref linkend="the_category_phrase"/>.
-          </para>
-
-<programlisting>channel default_syslog {
-    syslog daemon;                      // send to syslog's daemon
-                                        // facility
-    severity info;                      // only send priority info
-                                        // and higher
-};
-
-channel default_debug {
-    file "named.run";                   // write to named.run in
-                                        // the working directory
-                                        // Note: stderr is used instead
-                                        // of "named.run"
-                                        // if the server is started
-                                        // with the '-f' option.
-    severity dynamic;                   // log at the server's
-                                        // current debug level
-};
-
-channel default_stderr {
-    stderr;                             // writes to stderr
-    severity info;                      // only send priority info
-                                        // and higher
-};
-
-channel null {
-   null;                                // toss anything sent to
-                                        // this channel
-};
-</programlisting>
-
-          <para>
-            The <command>default_debug</command> channel has the
-            special
-            property that it only produces output when the server's debug
-            level is
-            nonzero.  It normally writes to a file called <filename>named.run</filename>
-            in the server's working directory.
-          </para>
-
-          <para>
-            For security reasons, when the "<option>-u</option>"
-            command line option is used, the <filename>named.run</filename> file
-            is created only after <command>named</command> has
-            changed to the
-            new UID, and any debug output generated while <command>named</command> is
-            starting up and still running as root is discarded.  If you need
-            to capture this output, you must run the server with the "<option>-g</option>"
-            option and redirect standard error to a file.
-          </para>
-
-          <para>
-            Once a channel is defined, it cannot be redefined. Thus you
-            cannot alter the built-in channels directly, but you can modify
-            the default logging by pointing categories at channels you have
-            defined.
-          </para>
-        </sect3>
-
-        <sect3 id="the_category_phrase">
-          <title>The <command>category</command> Phrase</title>
-
-          <para>
-            There are many categories, so you can send the logs you want
-            to see wherever you want, without seeing logs you don't want. If
-            you don't specify a list of channels for a category, then log
-            messages
-            in that category will be sent to the <command>default</command> category
-            instead. If you don't specify a default category, the following
-            "default default" is used:
-          </para>
-
-<programlisting>category default { default_syslog; default_debug; };
-</programlisting>
-
-          <para>
-            As an example, let's say you want to log security events to
-            a file, but you also want keep the default logging behavior. You'd
-            specify the following:
-          </para>
-
-<programlisting>channel my_security_channel {
-    file "my_security_file";
-    severity info;
-};
-category security {
-    my_security_channel;
-    default_syslog;
-    default_debug;
-};</programlisting>
-
-          <para>
-            To discard all messages in a category, specify the <command>null</command> channel:
-          </para>
-
-<programlisting>category xfer-out { null; };
-category notify { null; };
-</programlisting>
-
-          <para>
-            Following are the available categories and brief descriptions
-            of the types of log information they contain. More
-            categories may be added in future <acronym>BIND</acronym> releases.
-          </para>
-          <informaltable colsep="0" rowsep="0">
-            <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="4Level-table">
-              <colspec colname="1" colnum="1" colsep="0" colwidth="1.150in"/>
-              <colspec colname="2" colnum="2" colsep="0" colwidth="3.350in"/>
-              <tbody>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para><command>default</command></para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      The default category defines the logging
-                      options for those categories where no specific
-                      configuration has been
-                      defined.
-                    </para>
-                  </entry>
-                </row>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para><command>general</command></para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      The catch-all. Many things still aren't
-                      classified into categories, and they all end up here.
-                    </para>
-                  </entry>
-                </row>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para><command>database</command></para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      Messages relating to the databases used
-                      internally by the name server to store zone and cache
-                      data.
-                    </para>
-                  </entry>
-                </row>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para><command>security</command></para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      Approval and denial of requests.
-                    </para>
-                  </entry>
-                </row>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para><command>config</command></para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      Configuration file parsing and processing.
-                    </para>
-                  </entry>
-                </row>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para><command>resolver</command></para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      DNS resolution, such as the recursive
-                      lookups performed on behalf of clients by a caching name
-                      server.
-                    </para>
-                  </entry>
-                </row>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para><command>xfer-in</command></para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      Zone transfers the server is receiving.
-                    </para>
-                  </entry>
-                </row>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para><command>xfer-out</command></para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      Zone transfers the server is sending.
-                    </para>
-                  </entry>
-                </row>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para><command>notify</command></para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      The NOTIFY protocol.
-                    </para>
-                  </entry>
-                </row>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para><command>client</command></para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      Processing of client requests.
-                    </para>
-                  </entry>
-                </row>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para><command>unmatched</command></para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      Messages that named was unable to determine the
-                      class of or for which there was no matching <command>view</command>.
-                      A one line summary is also logged to the <command>client</command> category.
-                      This category is best sent to a file or stderr, by
-                      default it is sent to
-                      the <command>null</command> channel.
-                    </para>
-                  </entry>
-                </row>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para><command>network</command></para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      Network operations.
-                    </para>
-                  </entry>
-                </row>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para><command>update</command></para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      Dynamic updates.
-                    </para>
-                  </entry>
-                </row>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para><command>update-security</command></para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      Approval and denial of update requests.
-                    </para>
-                  </entry>
-                </row>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para><command>queries</command></para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      Specify where queries should be logged to.
-                    </para>
-                    <para>
-                      At startup, specifying the category <command>queries</command> will also
-                      enable query logging unless <command>querylog</command> option has been
-                      specified.
-                    </para>
-                    <para>
-                      The query log entry reports the client's IP address and
-                      port number, and the
-                      query name, class and type.  It also reports whether the
-                      Recursion Desired
-                      flag was set (+ if set, - if not set), EDNS was in use
-                      (E) or if the
-                      query was signed (S).
-                    </para>
-                    <para>
-                      <computeroutput>client 127.0.0.1#62536: query: www.example.com IN AAAA +SE</computeroutput>
-                    </para>
-                    <para>
-                      <computeroutput>client ::1#62537: query: www.example.net IN AAAA -SE</computeroutput>
-                    </para>
-                  </entry>
-                </row>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para><command>dispatch</command></para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      Dispatching of incoming packets to the
-                      server modules where they are to be processed.
-                    </para>
-                  </entry>
-                </row>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para><command>dnssec</command></para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      DNSSEC and TSIG protocol processing.
-                    </para>
-                  </entry>
-                </row>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para><command>lame-servers</command></para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      Lame servers.  These are misconfigurations
-                      in remote servers, discovered by BIND 9 when trying to
-                      query
-                      those servers during resolution.
-                    </para>
-                  </entry>
-                </row>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para><command>delegation-only</command></para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      Delegation only.  Logs queries that have have
-                      been forced to NXDOMAIN as the result of a
-                      delegation-only zone or
-                      a <command>delegation-only</command> in a
-                      hint or stub zone declaration.
-                    </para>
-                  </entry>
-                </row>
-              </tbody>
-            </tgroup>
-          </informaltable>
-        </sect3>
-      </sect2>
-
-      <sect2>
-        <title><command>lwres</command> Statement Grammar</title>
-
-        <para>
-           This is the grammar of the <command>lwres</command>
-          statement in the <filename>named.conf</filename> file:
-        </para>
-
-<programlisting><command>lwres</command> {
-    <optional> listen-on { <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; <optional> <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; ... </optional> }; </optional>
-    <optional> view <replaceable>view_name</replaceable>; </optional>
-    <optional> search { <replaceable>domain_name</replaceable> ; <optional> <replaceable>domain_name</replaceable> ; ... </optional> }; </optional>
-    <optional> ndots <replaceable>number</replaceable>; </optional>
-};
-</programlisting>
-
-      </sect2>
-      <sect2>
-        <title><command>lwres</command> Statement Definition and Usage</title>
-
-        <para>
-          The <command>lwres</command> statement configures the
-          name
-          server to also act as a lightweight resolver server. (See
-          <xref linkend="lwresd"/>.)  There may be multiple
-          <command>lwres</command> statements configuring
-          lightweight resolver servers with different properties.
-        </para>
-
-        <para>
-          The <command>listen-on</command> statement specifies a
-          list of
-          addresses (and ports) that this instance of a lightweight resolver
-          daemon
-          should accept requests on.  If no port is specified, port 921 is
-          used.
-          If this statement is omitted, requests will be accepted on
-          127.0.0.1,
-          port 921.
-        </para>
-
-        <para>
-          The <command>view</command> statement binds this
-          instance of a
-          lightweight resolver daemon to a view in the DNS namespace, so that
-          the
-          response will be constructed in the same manner as a normal DNS
-          query
-          matching this view.  If this statement is omitted, the default view
-          is
-          used, and if there is no default view, an error is triggered.
-        </para>
-
-        <para>
-          The <command>search</command> statement is equivalent to
-          the
-          <command>search</command> statement in
-          <filename>/etc/resolv.conf</filename>.  It provides a
-          list of domains
-          which are appended to relative names in queries.
-        </para>
-
-        <para>
-          The <command>ndots</command> statement is equivalent to
-          the
-          <command>ndots</command> statement in
-          <filename>/etc/resolv.conf</filename>.  It indicates the
-          minimum
-          number of dots in a relative domain name that should result in an
-          exact match lookup before search path elements are appended.
-        </para>
-      </sect2>
-      <sect2>
-        <title><command>masters</command> Statement Grammar</title>
-
-<programlisting>
-<command>masters</command> <replaceable>name</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> { ( <replaceable>masters_list</replaceable> | <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> <optional>key <replaceable>key</replaceable></optional> ) ; <optional>...</optional> };
-</programlisting>
-
-      </sect2>
-
-      <sect2>
-        <title><command>masters</command> Statement Definition and
-          Usage</title>
-        <para><command>masters</command>
-	  lists allow for a common set of masters to be easily used by
-          multiple stub and slave zones.
-        </para>
-      </sect2>
-
-      <sect2>
-        <title><command>options</command> Statement Grammar</title>
-
-        <para>
-          This is the grammar of the <command>options</command>
-          statement in the <filename>named.conf</filename> file:
-        </para>
-
-<programlisting>options {
-    <optional> version <replaceable>version_string</replaceable>; </optional>
-    <optional> hostname <replaceable>hostname_string</replaceable>; </optional>
-    <optional> server-id <replaceable>server_id_string</replaceable>; </optional>
-    <optional> directory <replaceable>path_name</replaceable>; </optional>
-    <optional> key-directory <replaceable>path_name</replaceable>; </optional>
-    <optional> named-xfer <replaceable>path_name</replaceable>; </optional>
-    <optional> tkey-domain <replaceable>domainname</replaceable>; </optional>
-    <optional> tkey-dhkey <replaceable>key_name</replaceable> <replaceable>key_tag</replaceable>; </optional>
-    <optional> cache-file <replaceable>path_name</replaceable>; </optional>
-    <optional> dump-file <replaceable>path_name</replaceable>; </optional>
-    <optional> memstatistics-file <replaceable>path_name</replaceable>; </optional>
-    <optional> pid-file <replaceable>path_name</replaceable>; </optional>
-    <optional> recursing-file <replaceable>path_name</replaceable>; </optional>
-    <optional> statistics-file <replaceable>path_name</replaceable>; </optional>
-    <optional> zone-statistics <replaceable>yes_or_no</replaceable>; </optional>
-    <optional> auth-nxdomain <replaceable>yes_or_no</replaceable>; </optional>
-    <optional> deallocate-on-exit <replaceable>yes_or_no</replaceable>; </optional>
-    <optional> dialup <replaceable>dialup_option</replaceable>; </optional>
-    <optional> fake-iquery <replaceable>yes_or_no</replaceable>; </optional>
-    <optional> fetch-glue <replaceable>yes_or_no</replaceable>; </optional>
-    <optional> flush-zones-on-shutdown <replaceable>yes_or_no</replaceable>; </optional>
-    <optional> has-old-clients <replaceable>yes_or_no</replaceable>; </optional>
-    <optional> host-statistics <replaceable>yes_or_no</replaceable>; </optional>
-    <optional> host-statistics-max <replaceable>number</replaceable>; </optional>
-    <optional> minimal-responses <replaceable>yes_or_no</replaceable>; </optional>
-    <optional> multiple-cnames <replaceable>yes_or_no</replaceable>; </optional>
-    <optional> notify <replaceable>yes_or_no</replaceable> | <replaceable>explicit</replaceable> | <replaceable>master-only</replaceable>; </optional>
-    <optional> recursion <replaceable>yes_or_no</replaceable>; </optional>
-    <optional> rfc2308-type1 <replaceable>yes_or_no</replaceable>; </optional>
-    <optional> use-id-pool <replaceable>yes_or_no</replaceable>; </optional>
-    <optional> maintain-ixfr-base <replaceable>yes_or_no</replaceable>; </optional>
-    <optional> dnssec-enable <replaceable>yes_or_no</replaceable>; </optional>
-    <optional> dnssec-validation <replaceable>yes_or_no</replaceable>; </optional>
-    <optional> dnssec-lookaside <replaceable>domain</replaceable> trust-anchor <replaceable>domain</replaceable>; </optional>
-    <optional> dnssec-must-be-secure <replaceable>domain yes_or_no</replaceable>; </optional>
-    <optional> dnssec-accept-expired <replaceable>yes_or_no</replaceable>; </optional>
-    <optional> forward ( <replaceable>only</replaceable> | <replaceable>first</replaceable> ); </optional>
-    <optional> forwarders { <optional> <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; ... </optional> }; </optional>
-    <optional> dual-stack-servers <optional>port <replaceable>ip_port</replaceable></optional> {
-        ( <replaceable>domain_name</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> |
-          <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ) ; 
-        ... }; </optional>
-    <optional> check-names ( <replaceable>master</replaceable> | <replaceable>slave</replaceable> | <replaceable>response</replaceable> )
-        ( <replaceable>warn</replaceable> | <replaceable>fail</replaceable> | <replaceable>ignore</replaceable> ); </optional>
-    <optional> check-mx ( <replaceable>warn</replaceable> | <replaceable>fail</replaceable> | <replaceable>ignore</replaceable> ); </optional>
-    <optional> check-wildcard <replaceable>yes_or_no</replaceable>; </optional>
-    <optional> check-integrity <replaceable>yes_or_no</replaceable>; </optional>
-    <optional> check-mx-cname ( <replaceable>warn</replaceable> | <replaceable>fail</replaceable> | <replaceable>ignore</replaceable> ); </optional>
-    <optional> check-srv-cname ( <replaceable>warn</replaceable> | <replaceable>fail</replaceable> | <replaceable>ignore</replaceable> ); </optional>
-    <optional> check-sibling <replaceable>yes_or_no</replaceable>; </optional>
-    <optional> allow-notify { <replaceable>address_match_list</replaceable> }; </optional>
-    <optional> allow-query { <replaceable>address_match_list</replaceable> }; </optional>
-    <optional> allow-query-cache { <replaceable>address_match_list</replaceable> }; </optional>
-    <optional> allow-transfer { <replaceable>address_match_list</replaceable> }; </optional>
-    <optional> allow-recursion { <replaceable>address_match_list</replaceable> }; </optional>
-    <optional> allow-update { <replaceable>address_match_list</replaceable> }; </optional>
-    <optional> allow-update-forwarding { <replaceable>address_match_list</replaceable> }; </optional>
-    <optional> update-check-ksk <replaceable>yes_or_no</replaceable>; </optional>
-    <optional> allow-v6-synthesis { <replaceable>address_match_list</replaceable> }; </optional>
-    <optional> blackhole { <replaceable>address_match_list</replaceable> }; </optional>
-    <optional> avoid-v4-udp-ports { <replaceable>port_list</replaceable> }; </optional>
-    <optional> avoid-v6-udp-ports { <replaceable>port_list</replaceable> }; </optional>
-    <optional> listen-on <optional> port <replaceable>ip_port</replaceable> </optional> { <replaceable>address_match_list</replaceable> }; </optional>
-    <optional> listen-on-v6 <optional> port <replaceable>ip_port</replaceable> </optional> { <replaceable>address_match_list</replaceable> }; </optional>
-    <optional> query-source ( ( <replaceable>ip4_addr</replaceable> | <replaceable>*</replaceable> )
-        <optional> port ( <replaceable>ip_port</replaceable> | <replaceable>*</replaceable> ) </optional> |
-	<optional> address ( <replaceable>ip4_addr</replaceable> | <replaceable>*</replaceable> ) </optional>
-	<optional> port ( <replaceable>ip_port</replaceable> | <replaceable>*</replaceable> ) </optional> ) ; </optional>
-    <optional> query-source-v6 ( ( <replaceable>ip6_addr</replaceable> | <replaceable>*</replaceable> )
-	<optional> port ( <replaceable>ip_port</replaceable> | <replaceable>*</replaceable> ) </optional> | 
-	<optional> address ( <replaceable>ip6_addr</replaceable> | <replaceable>*</replaceable> ) </optional> 
-	<optional> port ( <replaceable>ip_port</replaceable> | <replaceable>*</replaceable> ) </optional> ) ; </optional>
-    <optional> max-transfer-time-in <replaceable>number</replaceable>; </optional>
-    <optional> max-transfer-time-out <replaceable>number</replaceable>; </optional>
-    <optional> max-transfer-idle-in <replaceable>number</replaceable>; </optional>
-    <optional> max-transfer-idle-out <replaceable>number</replaceable>; </optional>
-    <optional> tcp-clients <replaceable>number</replaceable>; </optional>
-    <optional> recursive-clients <replaceable>number</replaceable>; </optional>
-    <optional> serial-query-rate <replaceable>number</replaceable>; </optional>
-    <optional> serial-queries <replaceable>number</replaceable>; </optional>
-    <optional> tcp-listen-queue <replaceable>number</replaceable>; </optional>
-    <optional> transfer-format <replaceable>( one-answer | many-answers )</replaceable>; </optional>
-    <optional> transfers-in  <replaceable>number</replaceable>; </optional>
-    <optional> transfers-out <replaceable>number</replaceable>; </optional>
-    <optional> transfers-per-ns <replaceable>number</replaceable>; </optional>
-    <optional> transfer-source (<replaceable>ip4_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
-    <optional> transfer-source-v6 (<replaceable>ip6_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
-    <optional> alt-transfer-source (<replaceable>ip4_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
-    <optional> alt-transfer-source-v6 (<replaceable>ip6_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
-    <optional> use-alt-transfer-source <replaceable>yes_or_no</replaceable>; </optional>
-    <optional> notify-delay <replaceable>seconds</replaceable> ; </optional>
-    <optional> notify-source (<replaceable>ip4_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
-    <optional> notify-source-v6 (<replaceable>ip6_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
-    <optional> also-notify { <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; <optional> <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; ... </optional> }; </optional>
-    <optional> max-ixfr-log-size <replaceable>number</replaceable>; </optional>
-    <optional> max-journal-size <replaceable>size_spec</replaceable>; </optional>
-    <optional> coresize <replaceable>size_spec</replaceable> ; </optional>
-    <optional> datasize <replaceable>size_spec</replaceable> ; </optional>
-    <optional> files <replaceable>size_spec</replaceable> ; </optional>
-    <optional> stacksize <replaceable>size_spec</replaceable> ; </optional>
-    <optional> cleaning-interval <replaceable>number</replaceable>; </optional>
-    <optional> heartbeat-interval <replaceable>number</replaceable>; </optional>
-    <optional> interface-interval <replaceable>number</replaceable>; </optional>
-    <optional> statistics-interval <replaceable>number</replaceable>; </optional>
-    <optional> topology { <replaceable>address_match_list</replaceable> }</optional>;
-    <optional> sortlist { <replaceable>address_match_list</replaceable> }</optional>;
-    <optional> rrset-order { <replaceable>order_spec</replaceable> ; <optional> <replaceable>order_spec</replaceable> ; ... </optional> </optional> };
-    <optional> lame-ttl <replaceable>number</replaceable>; </optional>
-    <optional> max-ncache-ttl <replaceable>number</replaceable>; </optional>
-    <optional> max-cache-ttl <replaceable>number</replaceable>; </optional>
-    <optional> sig-validity-interval <replaceable>number</replaceable> ; </optional>
-    <optional> min-roots <replaceable>number</replaceable>; </optional>
-    <optional> use-ixfr <replaceable>yes_or_no</replaceable> ; </optional>
-    <optional> provide-ixfr <replaceable>yes_or_no</replaceable>; </optional>
-    <optional> request-ixfr <replaceable>yes_or_no</replaceable>; </optional>
-    <optional> treat-cr-as-space <replaceable>yes_or_no</replaceable> ; </optional>
-    <optional> min-refresh-time <replaceable>number</replaceable> ; </optional>
-    <optional> max-refresh-time <replaceable>number</replaceable> ; </optional>
-    <optional> min-retry-time <replaceable>number</replaceable> ; </optional>
-    <optional> max-retry-time <replaceable>number</replaceable> ; </optional>
-    <optional> port <replaceable>ip_port</replaceable>; </optional>
-    <optional> additional-from-auth <replaceable>yes_or_no</replaceable> ; </optional>
-    <optional> additional-from-cache <replaceable>yes_or_no</replaceable> ; </optional>
-    <optional> random-device <replaceable>path_name</replaceable> ; </optional>
-    <optional> max-cache-size <replaceable>size_spec</replaceable> ; </optional>
-    <optional> match-mapped-addresses <replaceable>yes_or_no</replaceable>; </optional>
-    <optional> preferred-glue ( <replaceable>A</replaceable> | <replaceable>AAAA</replaceable> | <replaceable>NONE</replaceable> ); </optional>
-    <optional> edns-udp-size <replaceable>number</replaceable>; </optional>
-    <optional> max-udp-size <replaceable>number</replaceable>; </optional>
-    <optional> root-delegation-only <optional> exclude { <replaceable>namelist</replaceable> } </optional> ; </optional>
-    <optional> querylog <replaceable>yes_or_no</replaceable> ; </optional>
-    <optional> disable-algorithms <replaceable>domain</replaceable> { <replaceable>algorithm</replaceable>; <optional> <replaceable>algorithm</replaceable>; </optional> }; </optional>
-    <optional> acache-enable <replaceable>yes_or_no</replaceable> ; </optional>
-    <optional> acache-cleaning-interval <replaceable>number</replaceable>; </optional>
-    <optional> max-acache-size <replaceable>size_spec</replaceable> ; </optional>
-    <optional> clients-per-query <replaceable>number</replaceable> ; </optional>
-    <optional> max-clients-per-query <replaceable>number</replaceable> ; </optional>
-    <optional> masterfile-format (<constant>text</constant>|<constant>raw</constant>) ; </optional>
-    <optional> empty-server <replaceable>name</replaceable> ; </optional>
-    <optional> empty-contact <replaceable>name</replaceable> ; </optional>
-    <optional> empty-zones-enable <replaceable>yes_or_no</replaceable> ; </optional>
-    <optional> disable-empty-zone <replaceable>zone_name</replaceable> ; </optional>
-    <optional> zero-no-soa-ttl <replaceable>yes_or_no</replaceable> ; </optional>
-    <optional> zero-no-soa-ttl-cache <replaceable>yes_or_no</replaceable> ; </optional>
-};
-</programlisting>
-
-      </sect2>
-
-      <sect2 id="options">
-        <title><command>options</command> Statement Definition and
-          Usage</title>
-
-        <para>
-          The <command>options</command> statement sets up global
-          options
-          to be used by <acronym>BIND</acronym>. This statement
-          may appear only
-          once in a configuration file. If there is no <command>options</command>
-          statement, an options block with each option set to its default will
-          be used.
-        </para>
-
-        <variablelist>
-
-          <varlistentry>
-            <term><command>directory</command></term>
-            <listitem>
-              <para>
-                The working directory of the server.
-                Any non-absolute pathnames in the configuration file will be
-                taken
-                as relative to this directory. The default location for most
-                server
-                output files (e.g. <filename>named.run</filename>)
-                is this directory.
-                If a directory is not specified, the working directory
-                defaults to `<filename>.</filename>', the directory from
-                which the server
-                was started. The directory specified should be an absolute
-                path.
-              </para>
-            </listitem>
-          </varlistentry>
-
-          <varlistentry>
-            <term><command>key-directory</command></term>
-            <listitem>
-              <para>
-                When performing dynamic update of secure zones, the
-                directory where the public and private key files should be
-                found,
-                if different than the current working directory.  The
-                directory specified
-                must be an absolute path.
-              </para>
-            </listitem>
-          </varlistentry>
-
-          <varlistentry>
-            <term><command>named-xfer</command></term>
-            <listitem>
-              <para>
-                <emphasis>This option is obsolete.</emphasis>
-                It was used in <acronym>BIND</acronym> 8 to
-                specify the pathname to the <command>named-xfer</command> program.
-                In <acronym>BIND</acronym> 9, no separate <command>named-xfer</command> program is
-                needed; its functionality is built into the name server.
-              </para>
-
-            </listitem>
-          </varlistentry>
-
-          <varlistentry>
-            <term><command>tkey-domain</command></term>
-            <listitem>
-              <para>
-                The domain appended to the names of all
-                shared keys generated with
-                <command>TKEY</command>. When a client
-                requests a <command>TKEY</command> exchange, it
-                may or may not specify
-                the desired name for the key. If present, the name of the
-                shared
-                key will be "<varname>client specified part</varname>" +
-                "<varname>tkey-domain</varname>".
-                Otherwise, the name of the shared key will be "<varname>random hex
-digits</varname>" + "<varname>tkey-domain</varname>". In most cases,
-                the <command>domainname</command> should be the
-                server's domain
-                name.
-              </para>
-            </listitem>
-          </varlistentry>
-
-          <varlistentry>
-            <term><command>tkey-dhkey</command></term>
-            <listitem>
-              <para>
-                The Diffie-Hellman key used by the server
-                to generate shared keys with clients using the Diffie-Hellman
-                mode
-                of <command>TKEY</command>. The server must be
-                able to load the
-                public and private keys from files in the working directory.
-                In
-                most cases, the keyname should be the server's host name.
-              </para>
-            </listitem>
-          </varlistentry>
-
-          <varlistentry>
-            <term><command>cache-file</command></term>
-            <listitem>
-              <para>
-		This is for testing only.  Do not use.
-              </para>
-            </listitem>
-          </varlistentry>
-
-          <varlistentry>
-            <term><command>dump-file</command></term>
-            <listitem>
-              <para>
-                The pathname of the file the server dumps
-                the database to when instructed to do so with
-                <command>rndc dumpdb</command>.
-                If not specified, the default is <filename>named_dump.db</filename>.
-              </para>
-            </listitem>
-          </varlistentry>
-
-          <varlistentry>
-            <term><command>memstatistics-file</command></term>
-            <listitem>
-              <para>
-                The pathname of the file the server writes memory
-                usage statistics to on exit.  If specified the
-		statistics will be written to the file on exit.
-              </para>
-	      <para>
-		In <acronym>BIND</acronym> 9.5 and later this will
-		default to <filename>named.memstats</filename>.
-		<acronym>BIND</acronym> 9.5 will also introduce
-		<command>memstatistics</command> to control the
-		writing.
-	      </para>
-	    </listitem>
-	  </varlistentry>
-
-          <varlistentry>
-            <term><command>pid-file</command></term>
-            <listitem>
-              <para>
-                The pathname of the file the server writes its process ID
-                in. If not specified, the default is <filename>/var/run/named.pid</filename>.
-                The pid-file is used by programs that want to send signals to
-                the running
-                name server. Specifying <command>pid-file none</command> disables the
-                use of a PID file &mdash; no file will be written and any
-                existing one will be removed.  Note that <command>none</command>
-                is a keyword, not a filename, and therefore is not enclosed
-                in
-                double quotes.
-              </para>
-            </listitem>
-          </varlistentry>
-
-          <varlistentry>
-            <term><command>recursing-file</command></term>
-            <listitem>
-              <para>
-                The pathname of the file the server dumps
-                the queries that are currently recursing when instructed
-                to do so with <command>rndc recursing</command>.
-                If not specified, the default is <filename>named.recursing</filename>.
-              </para>
-            </listitem>
-          </varlistentry>
-
-          <varlistentry>
-            <term><command>statistics-file</command></term>
-            <listitem>
-              <para>
-                The pathname of the file the server appends statistics
-                to when instructed to do so using <command>rndc stats</command>.
-                If not specified, the default is <filename>named.stats</filename> in the
-                server's current directory.  The format of the file is
-                described
-                in <xref linkend="statsfile"/>.
-              </para>
-            </listitem>
-          </varlistentry>
-
-          <varlistentry>
-            <term><command>port</command></term>
-            <listitem>
-              <para>
-                The UDP/TCP port number the server uses for
-                receiving and sending DNS protocol traffic.
-                The default is 53.  This option is mainly intended for server
-                testing;
-                a server using a port other than 53 will not be able to
-                communicate with
-                the global DNS.
-              </para>
-            </listitem>
-          </varlistentry>
-
-          <varlistentry>
-            <term><command>random-device</command></term>
-            <listitem>
-              <para>
-                The source of entropy to be used by the server.  Entropy is
-                primarily needed
-                for DNSSEC operations, such as TKEY transactions and dynamic
-                update of signed
-                zones.  This options specifies the device (or file) from which
-                to read
-                entropy.  If this is a file, operations requiring entropy will
-                fail when the
-                file has been exhausted.  If not specified, the default value
-                is
-                <filename>/dev/random</filename>
-                (or equivalent) when present, and none otherwise.  The
-                <command>random-device</command> option takes
-                effect during
-                the initial configuration load at server startup time and
-                is ignored on subsequent reloads.
-              </para>
-            </listitem>
-          </varlistentry>
-
-          <varlistentry>
-            <term><command>preferred-glue</command></term>
-            <listitem>
-              <para>
-                If specified, the listed type (A or AAAA) will be emitted
-                before other glue
-                in the additional section of a query response.
-                The default is not to prefer any type (NONE).
-              </para>
-            </listitem>
-          </varlistentry>
-
-          <varlistentry>
-            <term><command>root-delegation-only</command></term>
-            <listitem>
-              <para>
-                Turn on enforcement of delegation-only in TLDs (top level domains) and root zones
-                with an optional
-                exclude list.
-              </para>
-              <para>
-                Note some TLDs are not delegation only (e.g. "DE", "LV", "US"
-                and "MUSEUM").
-              </para>
-
-<programlisting>
-options {
-	root-delegation-only exclude { "de"; "lv"; "us"; "museum"; };
-};
-</programlisting>
-
-            </listitem>
-          </varlistentry>
-
-          <varlistentry>
-            <term><command>disable-algorithms</command></term>
-            <listitem>
-              <para>
-                Disable the specified DNSSEC algorithms at and below the
-                specified name.
-                Multiple <command>disable-algorithms</command>
-                statements are allowed.
-                Only the most specific will be applied.
-              </para>
-            </listitem>
-          </varlistentry>
-
-          <varlistentry>
-            <term><command>dnssec-lookaside</command></term>
-            <listitem>
-              <para>
-                When set, <command>dnssec-lookaside</command>
-                provides the
-                validator with an alternate method to validate DNSKEY records
-                at the
-                top of a zone.  When a DNSKEY is at or below a domain
-                specified by the
-                deepest <command>dnssec-lookaside</command>, and
-                the normal dnssec validation
-                has left the key untrusted, the trust-anchor will be append to
-                the key
-                name and a DLV record will be looked up to see if it can
-                validate the
-                key.  If the DLV record validates a DNSKEY (similarly to the
-                way a DS
-                record does) the DNSKEY RRset is deemed to be trusted.
-              </para>
-            </listitem>
-          </varlistentry>
-
-          <varlistentry>
-            <term><command>dnssec-must-be-secure</command></term>
-            <listitem>
-              <para>
-                Specify hierarchies which must be or may not be secure (signed and
-                validated).
-                If <userinput>yes</userinput>, then named will only accept
-                answers if they
-                are secure.
-                If <userinput>no</userinput>, then normal dnssec validation
-                applies
-                allowing for insecure answers to be accepted.
-                The specified domain must be under a <command>trusted-key</command> or
-                <command>dnssec-lookaside</command> must be
-                active.
-              </para>
-            </listitem>
-          </varlistentry>
-
-        </variablelist>
-
-        <sect3 id="boolean_options">
-          <title>Boolean Options</title>
-
-          <variablelist>
-
-            <varlistentry>
-              <term><command>auth-nxdomain</command></term>
-              <listitem>
-                <para>
-                  If <userinput>yes</userinput>, then the <command>AA</command> bit
-                  is always set on NXDOMAIN responses, even if the server is
-                  not actually
-                  authoritative. The default is <userinput>no</userinput>;
-                  this is
-                  a change from <acronym>BIND</acronym> 8. If you
-                  are using very old DNS software, you
-                  may need to set it to <userinput>yes</userinput>.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>deallocate-on-exit</command></term>
-              <listitem>
-                <para>
-                  This option was used in <acronym>BIND</acronym>
-                  8 to enable checking
-                  for memory leaks on exit. <acronym>BIND</acronym> 9 ignores the option and always performs
-                  the checks.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>dialup</command></term>
-              <listitem>
-                <para>
-                  If <userinput>yes</userinput>, then the
-                  server treats all zones as if they are doing zone transfers
-                  across
-                  a dial-on-demand dialup link, which can be brought up by
-                  traffic
-                  originating from this server. This has different effects
-                  according
-                  to zone type and concentrates the zone maintenance so that
-                  it all
-                  happens in a short interval, once every <command>heartbeat-interval</command> and
-                  hopefully during the one call. It also suppresses some of
-                  the normal
-                  zone maintenance traffic. The default is <userinput>no</userinput>.
-                </para>
-                <para>
-                  The <command>dialup</command> option
-                  may also be specified in the <command>view</command> and
-                  <command>zone</command> statements,
-                  in which case it overrides the global <command>dialup</command>
-                  option.
-                </para>
-                <para>
-                  If the zone is a master zone, then the server will send out a
-                  NOTIFY
-                  request to all the slaves (default). This should trigger the
-                  zone serial
-                  number check in the slave (providing it supports NOTIFY)
-                  allowing the slave
-                  to verify the zone while the connection is active.
-                  The set of servers to which NOTIFY is sent can be controlled
-                  by
-                  <command>notify</command> and <command>also-notify</command>.
-                </para>
-                <para>
-                  If the
-                  zone is a slave or stub zone, then the server will suppress
-                  the regular
-                  "zone up to date" (refresh) queries and only perform them
-                  when the
-                  <command>heartbeat-interval</command> expires in
-                  addition to sending
-                  NOTIFY requests.
-                </para>
-                <para>
-                  Finer control can be achieved by using
-                  <userinput>notify</userinput> which only sends NOTIFY
-                  messages,
-                  <userinput>notify-passive</userinput> which sends NOTIFY
-                  messages and
-                  suppresses the normal refresh queries, <userinput>refresh</userinput>
-                  which suppresses normal refresh processing and sends refresh
-                  queries
-                  when the <command>heartbeat-interval</command>
-                  expires, and
-                  <userinput>passive</userinput> which just disables normal
-                  refresh
-                  processing.
-                </para>
-
-                <informaltable colsep="0" rowsep="0">
-                  <tgroup cols="4" colsep="0" rowsep="0" tgroupstyle="4Level-table">
-                    <colspec colname="1" colnum="1" colsep="0" colwidth="1.150in"/>
-                    <colspec colname="2" colnum="2" colsep="0" colwidth="1.150in"/>
-                    <colspec colname="3" colnum="3" colsep="0" colwidth="1.150in"/>
-                    <colspec colname="4" colnum="4" colsep="0" colwidth="1.150in"/>
-                    <tbody>
-                      <row rowsep="0">
-                        <entry colname="1">
-                          <para>
-                            dialup mode
-                          </para>
-                        </entry>
-                        <entry colname="2">
-                          <para>
-                            normal refresh
-                          </para>
-                        </entry>
-                        <entry colname="3">
-                          <para>
-                            heart-beat refresh
-                          </para>
-                        </entry>
-                        <entry colname="4">
-                          <para>
-                            heart-beat notify
-                          </para>
-                        </entry>
-                      </row>
-                      <row rowsep="0">
-                        <entry colname="1">
-                          <para><command>no</command> (default)</para>
-                        </entry>
-                        <entry colname="2">
-                          <para>
-                            yes
-                          </para>
-                        </entry>
-                        <entry colname="3">
-                          <para>
-                            no
-                          </para>
-                        </entry>
-                        <entry colname="4">
-                          <para>
-                            no
-                          </para>
-                        </entry>
-                      </row>
-                      <row rowsep="0">
-                        <entry colname="1">
-                          <para><command>yes</command></para>
-                        </entry>
-                        <entry colname="2">
-                          <para>
-                            no
-                          </para>
-                        </entry>
-                        <entry colname="3">
-                          <para>
-                            yes
-                          </para>
-                        </entry>
-                        <entry colname="4">
-                          <para>
-                            yes
-                          </para>
-                        </entry>
-                      </row>
-                      <row rowsep="0">
-                        <entry colname="1">
-                          <para><command>notify</command></para>
-                        </entry>
-                        <entry colname="2">
-                          <para>
-                            yes
-                          </para>
-                        </entry>
-                        <entry colname="3">
-                          <para>
-                            no
-                          </para>
-                        </entry>
-                        <entry colname="4">
-                          <para>
-                            yes
-                          </para>
-                        </entry>
-                      </row>
-                      <row rowsep="0">
-                        <entry colname="1">
-                          <para><command>refresh</command></para>
-                        </entry>
-                        <entry colname="2">
-                          <para>
-                            no
-                          </para>
-                        </entry>
-                        <entry colname="3">
-                          <para>
-                            yes
-                          </para>
-                        </entry>
-                        <entry colname="4">
-                          <para>
-                            no
-                          </para>
-                        </entry>
-                      </row>
-                      <row rowsep="0">
-                        <entry colname="1">
-                          <para><command>passive</command></para>
-                        </entry>
-                        <entry colname="2">
-                          <para>
-                            no
-                          </para>
-                        </entry>
-                        <entry colname="3">
-                          <para>
-                            no
-                          </para>
-                        </entry>
-                        <entry colname="4">
-                          <para>
-                            no
-                          </para>
-                        </entry>
-                      </row>
-                      <row rowsep="0">
-                        <entry colname="1">
-                          <para><command>notify-passive</command></para>
-                        </entry>
-                        <entry colname="2">
-                          <para>
-                            no
-                          </para>
-                        </entry>
-                        <entry colname="3">
-                          <para>
-                            no
-                          </para>
-                        </entry>
-                        <entry colname="4">
-                          <para>
-                            yes
-                          </para>
-                        </entry>
-                      </row>
-                    </tbody>
-                  </tgroup>
-                </informaltable>
-
-                <para>
-                  Note that normal NOTIFY processing is not affected by
-                  <command>dialup</command>.
-                </para>
-
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>fake-iquery</command></term>
-              <listitem>
-                <para>
-                  In <acronym>BIND</acronym> 8, this option
-                  enabled simulating the obsolete DNS query type
-                  IQUERY. <acronym>BIND</acronym> 9 never does
-                  IQUERY simulation.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>fetch-glue</command></term>
-              <listitem>
-                <para>
-                  This option is obsolete.
-                  In BIND 8, <userinput>fetch-glue yes</userinput>
-                  caused the server to attempt to fetch glue resource records
-                  it
-                  didn't have when constructing the additional
-                  data section of a response.  This is now considered a bad
-                  idea
-                  and BIND 9 never does it.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>flush-zones-on-shutdown</command></term>
-              <listitem>
-                <para>
-                  When the nameserver exits due receiving SIGTERM,
-                  flush or do not flush any pending zone writes.  The default
-                  is
-                  <command>flush-zones-on-shutdown</command> <userinput>no</userinput>.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>has-old-clients</command></term>
-              <listitem>
-                <para>
-                  This option was incorrectly implemented
-                  in <acronym>BIND</acronym> 8, and is ignored by <acronym>BIND</acronym> 9.
-                  To achieve the intended effect
-                  of
-                  <command>has-old-clients</command> <userinput>yes</userinput>, specify
-                  the two separate options <command>auth-nxdomain</command> <userinput>yes</userinput>
-                  and <command>rfc2308-type1</command> <userinput>no</userinput> instead.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>host-statistics</command></term>
-              <listitem>
-                <para>
-                  In BIND 8, this enables keeping of
-                  statistics for every host that the name server interacts
-                  with.
-                  Not implemented in BIND 9.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>maintain-ixfr-base</command></term>
-              <listitem>
-                <para>
-                  <emphasis>This option is obsolete</emphasis>.
-                  It was used in <acronym>BIND</acronym> 8 to
-                  determine whether a transaction log was
-                  kept for Incremental Zone Transfer. <acronym>BIND</acronym> 9 maintains a transaction
-                  log whenever possible.  If you need to disable outgoing
-                  incremental zone
-                  transfers, use <command>provide-ixfr</command> <userinput>no</userinput>.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>minimal-responses</command></term>
-              <listitem>
-                <para>
-                  If <userinput>yes</userinput>, then when generating
-                  responses the server will only add records to the authority
-                  and additional data sections when they are required (e.g.
-                  delegations, negative responses).  This may improve the
-		  performance of the server.
-                  The default is <userinput>no</userinput>.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>multiple-cnames</command></term>
-              <listitem>
-                <para>
-                  This option was used in <acronym>BIND</acronym> 8 to allow
-                  a domain name to have multiple CNAME records in violation of
-                  the DNS standards.  <acronym>BIND</acronym> 9.2 onwards
-                  always strictly enforces the CNAME rules both in master
-		  files and dynamic updates.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>notify</command></term>
-              <listitem>
-                <para>
-                  If <userinput>yes</userinput> (the default),
-                  DNS NOTIFY messages are sent when a zone the server is
-                  authoritative for
-                  changes, see <xref linkend="notify"/>.  The messages are
-                  sent to the
-                  servers listed in the zone's NS records (except the master
-                  server identified
-                  in the SOA MNAME field), and to any servers listed in the
-                  <command>also-notify</command> option.
-                </para>
-                <para>
-                  If <userinput>master-only</userinput>, notifies are only
-                  sent
-                  for master zones.
-                  If <userinput>explicit</userinput>, notifies are sent only
-                  to
-                  servers explicitly listed using <command>also-notify</command>.
-                  If <userinput>no</userinput>, no notifies are sent.
-                </para>
-                <para>
-                  The <command>notify</command> option may also be
-                  specified in the <command>zone</command>
-                  statement,
-                  in which case it overrides the <command>options notify</command> statement.
-                  It would only be necessary to turn off this option if it
-                  caused slaves
-                  to crash.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>recursion</command></term>
-              <listitem>
-                <para>
-                  If <userinput>yes</userinput>, and a
-                  DNS query requests recursion, then the server will attempt
-                  to do
-                  all the work required to answer the query. If recursion is
-                  off
-                  and the server does not already know the answer, it will
-                  return a
-                  referral response. The default is
-                  <userinput>yes</userinput>.
-                  Note that setting <command>recursion no</command> does not prevent
-                  clients from getting data from the server's cache; it only
-                  prevents new data from being cached as an effect of client
-                  queries.
-                  Caching may still occur as an effect the server's internal
-                  operation, such as NOTIFY address lookups.
-                  See also <command>fetch-glue</command> above.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>rfc2308-type1</command></term>
-              <listitem>
-                <para>
-                  Setting this to <userinput>yes</userinput> will
-                  cause the server to send NS records along with the SOA
-                  record for negative
-                  answers. The default is <userinput>no</userinput>.
-                </para>
-                <note>
-                  <simpara>
-                    Not yet implemented in <acronym>BIND</acronym>
-                    9.
-                  </simpara>
-                </note>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>use-id-pool</command></term>
-              <listitem>
-                <para>
-                  <emphasis>This option is obsolete</emphasis>.
-                  <acronym>BIND</acronym> 9 always allocates query
-                  IDs from a pool.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>zone-statistics</command></term>
-              <listitem>
-                <para>
-                  If <userinput>yes</userinput>, the server will collect
-                  statistical data on all zones (unless specifically turned
-                  off
-                  on a per-zone basis by specifying <command>zone-statistics no</command>
-                  in the <command>zone</command> statement).
-                  These statistics may be accessed
-                  using <command>rndc stats</command>, which will
-                  dump them to the file listed
-                  in the <command>statistics-file</command>.  See
-                  also <xref linkend="statsfile"/>.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>use-ixfr</command></term>
-              <listitem>
-                <para>
-                  <emphasis>This option is obsolete</emphasis>.
-                  If you need to disable IXFR to a particular server or
-                  servers, see
-                  the information on the <command>provide-ixfr</command> option
-                  in <xref linkend="server_statement_definition_and_usage"/>.
-                  See also
-                  <xref linkend="incremental_zone_transfers"/>.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>provide-ixfr</command></term>
-              <listitem>
-                <para>
-                  See the description of
-                  <command>provide-ixfr</command> in
-                  <xref linkend="server_statement_definition_and_usage"/>.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>request-ixfr</command></term>
-              <listitem>
-                <para>
-                  See the description of
-                  <command>request-ixfr</command> in
-                  <xref linkend="server_statement_definition_and_usage"/>.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>treat-cr-as-space</command></term>
-              <listitem>
-                <para>
-                  This option was used in <acronym>BIND</acronym>
-                  8 to make
-                  the server treat carriage return ("<command>\r</command>") characters the same way
-                  as a space or tab character,
-                  to facilitate loading of zone files on a UNIX system that
-                  were generated
-                  on an NT or DOS machine. In <acronym>BIND</acronym> 9, both UNIX "<command>\n</command>"
-                  and NT/DOS "<command>\r\n</command>" newlines
-                  are always accepted,
-                  and the option is ignored.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>additional-from-auth</command></term>
-              <term><command>additional-from-cache</command></term>
-              <listitem>
-
-                <para>
-                  These options control the behavior of an authoritative
-                  server when
-                  answering queries which have additional data, or when
-                  following CNAME
-                  and DNAME chains.
-                </para>
-
-                <para>
-                  When both of these options are set to <userinput>yes</userinput>
-                  (the default) and a
-                  query is being answered from authoritative data (a zone
-                  configured into the server), the additional data section of
-                  the
-                  reply will be filled in using data from other authoritative
-                  zones
-                  and from the cache.  In some situations this is undesirable,
-                  such
-                  as when there is concern over the correctness of the cache,
-                  or
-                  in servers where slave zones may be added and modified by
-                  untrusted third parties.  Also, avoiding
-                  the search for this additional data will speed up server
-                  operations
-                  at the possible expense of additional queries to resolve
-                  what would
-                  otherwise be provided in the additional section.
-                </para>
-
-                <para>
-                  For example, if a query asks for an MX record for host <literal>foo.example.com</literal>,
-                  and the record found is "<literal>MX 10 mail.example.net</literal>", normally the address
-                  records (A and AAAA) for <literal>mail.example.net</literal> will be provided as well,
-                  if known, even though they are not in the example.com zone.
-                  Setting these options to <command>no</command>
-                  disables this behavior and makes
-                  the server only search for additional data in the zone it
-                  answers from.
-                </para>
-
-                <para>
-                  These options are intended for use in authoritative-only
-                  servers, or in authoritative-only views.  Attempts to set
-                  them to <command>no</command> without also
-                  specifying
-                  <command>recursion no</command> will cause the
-                  server to
-                  ignore the options and log a warning message.
-                </para>
-
-                <para>
-                  Specifying <command>additional-from-cache no</command> actually
-                  disables the use of the cache not only for additional data
-                  lookups
-                  but also when looking up the answer.  This is usually the
-                  desired
-                  behavior in an authoritative-only server where the
-                  correctness of
-                  the cached data is an issue.
-                </para>
-
-                <para>
-                  When a name server is non-recursively queried for a name
-                  that is not
-                  below the apex of any served zone, it normally answers with
-                  an
-                  "upwards referral" to the root servers or the servers of
-                  some other
-                  known parent of the query name.  Since the data in an
-                  upwards referral
-                  comes from the cache, the server will not be able to provide
-                  upwards
-                  referrals when <command>additional-from-cache no</command>
-                  has been specified.  Instead, it will respond to such
-                  queries
-                  with REFUSED.  This should not cause any problems since
-                  upwards referrals are not required for the resolution
-                  process.
-                </para>
-
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>match-mapped-addresses</command></term>
-              <listitem>
-                <para>
-                  If <userinput>yes</userinput>, then an
-                  IPv4-mapped IPv6 address will match any address match
-                  list entries that match the corresponding IPv4 address.
-                  Enabling this option is sometimes useful on IPv6-enabled
-                  Linux
-                  systems, to work around a kernel quirk that causes IPv4
-                  TCP connections such as zone transfers to be accepted
-                  on an IPv6 socket using mapped addresses, causing
-                  address match lists designed for IPv4 to fail to match.
-                  The use of this option for any other purpose is discouraged.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>ixfr-from-differences</command></term>
-              <listitem>
-                <para>
-                  When <userinput>yes</userinput> and the server loads a new version of a master
-                  zone from its zone file or receives a new version of a slave
-                  file by a non-incremental zone transfer, it will compare
-                  the new version to the previous one and calculate a set
-                  of differences.  The differences are then logged in the
-                  zone's journal file such that the changes can be transmitted
-                  to downstream slaves as an incremental zone transfer.
-                </para>
-                <para>
-                  By allowing incremental zone transfers to be used for
-                  non-dynamic zones, this option saves bandwidth at the
-                  expense of increased CPU and memory consumption at the
-                  master.
-                  In particular, if the new version of a zone is completely
-                  different from the previous one, the set of differences
-                  will be of a size comparable to the combined size of the
-                  old and new zone version, and the server will need to
-                  temporarily allocate memory to hold this complete
-                  difference set.
-                </para>
-                <para><command>ixfr-from-differences</command>
-		  also accepts <command>master</command> and
-                  <command>slave</command> at the view and options
-                  levels which causes
-                  <command>ixfr-from-differences</command> to apply to
-                  all <command>master</command> or
-                  <command>slave</command> zones respectively.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>multi-master</command></term>
-              <listitem>
-                <para>
-                  This should be set when you have multiple masters for a zone
-                  and the
-                  addresses refer to different machines.  If <userinput>yes</userinput>, named will
-                  not log
-                  when the serial number on the master is less than what named
-                  currently
-                  has.  The default is <userinput>no</userinput>.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>dnssec-enable</command></term>
-              <listitem>
-                <para>
-                  Enable DNSSEC support in named.  Unless set to <userinput>yes</userinput>,
-                  named behaves as if it does not support DNSSEC.
-                  The default is <userinput>yes</userinput>.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>dnssec-validation</command></term>
-              <listitem>
-                <para>
-                  Enable DNSSEC validation in named.
-		  Note <command>dnssec-enable</command> also needs to be
-		  set to <userinput>yes</userinput> to be effective.
-                  The default is <userinput>no</userinput>.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>dnssec-accept-expired</command></term>
-              <listitem>
-                <para>
-		  Accept expired signatures when verifying DNSSEC signatures.
-                  The default is <userinput>no</userinput>.
-		  Setting this option to "yes" leaves named vulnerable to replay attacks.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>querylog</command></term>
-              <listitem>
-                <para>
-                  Specify whether query logging should be started when named
-                  starts.
-                  If <command>querylog</command> is not specified,
-                  then the query logging
-                  is determined by the presence of the logging category <command>queries</command>.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>check-names</command></term>
-              <listitem>
-                <para>
-                  This option is used to restrict the character set and syntax
-                  of
-                  certain domain names in master files and/or DNS responses
-                  received
-                  from the network.  The default varies according to usage
-                  area.  For
-                  <command>master</command> zones the default is <command>fail</command>.
-                  For <command>slave</command> zones the default
-                  is <command>warn</command>.
-                  For answers received from the network (<command>response</command>)
-                  the default is <command>ignore</command>.
-                </para>
-                <para>
-                  The rules for legal hostnames and mail domains are derived
-                  from RFC 952 and RFC 821 as modified by RFC 1123.
-                </para>
-                <para><command>check-names</command>
-		  applies to the owner names of A, AAA and MX records.
-		  It also applies to the domain names in the RDATA of NS, SOA
-		  and MX records.
-		  It also applies to the RDATA of PTR records where the owner
-		  name indicated that it is a reverse lookup of a hostname
-		  (the owner name ends in IN-ADDR.ARPA, IP6.ARPA, or IP6.INT).
-                </para>
-              </listitem>
-            </varlistentry>
-
-	    <varlistentry>
-	      <term><command>check-mx</command></term>
-	      <listitem>
-		<para>
-		  Check whether the MX record appears to refer to a IP address.
-		  The default is to <command>warn</command>.  Other possible
-		  values are <command>fail</command> and
-		  <command>ignore</command>.
-		</para>
-	      </listitem>
-	    </varlistentry>
-
-            <varlistentry>
-              <term><command>check-wildcard</command></term>
-              <listitem>
-                <para>
-                  This option is used to check for non-terminal wildcards.
-                  The use of non-terminal wildcards is almost always as a
-                  result of a failure
-                  to understand the wildcard matching algorithm (RFC 1034).
-                  This option
-                  affects master zones.  The default (<command>yes</command>) is to check
-                  for non-terminal wildcards and issue a warning.
-                </para>
-              </listitem>
-            </varlistentry>
-
-	    <varlistentry>
-	      <term><command>check-integrity</command></term>
-	      <listitem>
-		<para>
-		  Perform post load zone integrity checks on master
-		  zones.  This checks that MX and SRV records refer
-		  to address (A or AAAA) records and that glue
-		  address records exist for delegated zones.  For
-		  MX and SRV records only in-zone hostnames are
-		  checked (for out-of-zone hostnames use named-checkzone).
-		  For NS records only names below top of zone are
-		  checked (for out-of-zone names and glue consistency
-		  checks use named-checkzone).  The default is
-		  <command>yes</command>.
-		</para>
-	      </listitem>
-	    </varlistentry>
-
-	    <varlistentry>
-	      <term><command>check-mx-cname</command></term>
-	      <listitem>
-		<para>
-		  If <command>check-integrity</command> is set then
-		  fail, warn or ignore MX records that refer
-		  to CNAMES.  The default is to <command>warn</command>.
-		</para>
-	      </listitem>
-	    </varlistentry>
-
-	    <varlistentry>
-	      <term><command>check-srv-cname</command></term>
-	      <listitem>
-		<para>
-		  If <command>check-integrity</command> is set then
-		  fail, warn or ignore SRV records that refer
-		  to CNAMES.  The default is to <command>warn</command>.
-		</para>
-	      </listitem>
-	    </varlistentry>
-
-	    <varlistentry>
-	      <term><command>check-sibling</command></term>
-	      <listitem>
-		<para>
-		  When performing integrity checks, also check that
-		  sibling glue exists.  The default is <command>yes</command>.
-		</para>
-	      </listitem>
-	    </varlistentry>
-
-	    <varlistentry>
-	      <term><command>zero-no-soa-ttl</command></term>
-	      <listitem>
-	        <para>
-		  When returning authoritative negative responses to
-		  SOA queries set the TTL of the SOA recored returned in
-		  the authority section to zero.
-		  The default is <command>yes</command>.
-	        </para>
-	      </listitem>
-	    </varlistentry>
-
-	    <varlistentry>
-	      <term><command>zero-no-soa-ttl-cache</command></term>
-	      <listitem>
-	        <para>
-		  When caching a negative response to a SOA query
-		  set the TTL to zero.
-		  The default is <command>no</command>.
-	        </para>
-	      </listitem>
-	    </varlistentry>
-
-	    <varlistentry>
-	      <term><command>update-check-ksk</command></term>
-	      <listitem>
-	        <para>
-		  When regenerating the RRSIGs following a UPDATE
-		  request to a secure zone, check the KSK flag on
-		  the DNSKEY RR to determine if this key should be
-		  used to generate the RRSIG.  This flag is ignored
-		  if there are not DNSKEY RRs both with and without
-		  a KSK.
-		  The default is <command>yes</command>.
-		</para>
-	      </listitem>
-	    </varlistentry>
-
-          </variablelist>
-
-        </sect3>
-
-        <sect3>
-          <title>Forwarding</title>
-          <para>
-            The forwarding facility can be used to create a large site-wide
-            cache on a few servers, reducing traffic over links to external
-            name servers. It can also be used to allow queries by servers that
-            do not have direct access to the Internet, but wish to look up
-            exterior
-            names anyway. Forwarding occurs only on those queries for which
-            the server is not authoritative and does not have the answer in
-            its cache.
-          </para>
-
-          <variablelist>
-            <varlistentry>
-              <term><command>forward</command></term>
-              <listitem>
-                <para>
-                  This option is only meaningful if the
-                  forwarders list is not empty. A value of <varname>first</varname>,
-                  the default, causes the server to query the forwarders
-                  first &mdash; and
-                  if that doesn't answer the question, the server will then
-                  look for
-                  the answer itself. If <varname>only</varname> is
-                  specified, the
-                  server will only query the forwarders.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>forwarders</command></term>
-              <listitem>
-                <para>
-                  Specifies the IP addresses to be used
-                  for forwarding. The default is the empty list (no
-                  forwarding).
-                </para>
-              </listitem>
-            </varlistentry>
-
-          </variablelist>
-
-          <para>
-            Forwarding can also be configured on a per-domain basis, allowing
-            for the global forwarding options to be overridden in a variety
-            of ways. You can set particular domains to use different
-            forwarders,
-            or have a different <command>forward only/first</command> behavior,
-            or not forward at all, see <xref linkend="zone_statement_grammar"/>.
-          </para>
-        </sect3>
-
-        <sect3>
-          <title>Dual-stack Servers</title>
-          <para>
-            Dual-stack servers are used as servers of last resort to work
-            around
-            problems in reachability due the lack of support for either IPv4
-            or IPv6
-            on the host machine.
-          </para>
-
-          <variablelist>
-            <varlistentry>
-              <term><command>dual-stack-servers</command></term>
-              <listitem>
-                <para>
-                  Specifies host names or addresses of machines with access to
-                  both IPv4 and IPv6 transports. If a hostname is used, the
-                  server must be able
-                  to resolve the name using only the transport it has.  If the
-                  machine is dual
-                  stacked, then the <command>dual-stack-servers</command> have no effect unless
-                  access to a transport has been disabled on the command line
-                  (e.g. <command>named -4</command>).
-                </para>
-              </listitem>
-            </varlistentry>
-          </variablelist>
-        </sect3>
-
-        <sect3 id="access_control">
-          <title>Access Control</title>
-
-          <para>
-            Access to the server can be restricted based on the IP address
-            of the requesting system. See <xref linkend="address_match_lists"/> for
-            details on how to specify IP address lists.
-          </para>
-
-          <variablelist>
-
-            <varlistentry>
-              <term><command>allow-notify</command></term>
-              <listitem>
-                <para>
-                  Specifies which hosts are allowed to
-                  notify this server, a slave, of zone changes in addition
-                  to the zone masters.
-                  <command>allow-notify</command> may also be
-                  specified in the
-                  <command>zone</command> statement, in which case
-                  it overrides the
-                  <command>options allow-notify</command>
-                  statement.  It is only meaningful
-                  for a slave zone.  If not specified, the default is to
-                  process notify messages
-                  only from a zone's master.
-                </para>
-              </listitem>
-            </varlistentry>
-
-	    <varlistentry>
-	      <term><command>allow-query</command></term>
-	      <listitem>
-		<para>
-		  Specifies which hosts are allowed to ask ordinary
-		  DNS questions. <command>allow-query</command> may
-		  also be specified in the <command>zone</command>
-		  statement, in which case it overrides the
-		  <command>options allow-query</command> statement.
-		  If not specified, the default is to allow queries
-		  from all hosts.
-		</para>
-		<note>
-		  <para>
-		    <command>allow-query-cache</command> is now
-		    used to specify access to the cache.
-		  </para>
-		</note>
-	      </listitem>
-	    </varlistentry>
-
-	    <varlistentry>
-	      <term><command>allow-query-cache</command></term>
-	      <listitem>
-		<para>
-		  Specifies which hosts are allowed to get answers
-		  from the cache.  If <command>allow-query-cache</command>
-		  is not set then <command>allow-recursion</command>
-		  is used if set, otherwise <command>allow-query</command>
-		  is used if set, otherwise the default
-		  (<command>localnets;</command>
-		  <command>localhost;</command>) is used.
-		</para>
-	      </listitem>
-	    </varlistentry>
-
-            <varlistentry>
-              <term><command>allow-recursion</command></term>
-              <listitem>
-		<para>
-		  Specifies which hosts are allowed to make recursive
-		  queries through this server. If
-		  <command>allow-recursion</command> is not set
-		  then <command>allow-query-cache</command> is
-		  used if set, otherwise <command>allow-query</command>
-		  is used if set, otherwise the default
-		  (<command>localnets;</command>
-		  <command>localhost;</command>) is used.
-		</para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>allow-update</command></term>
-              <listitem>
-                <para>
-                  Specifies which hosts are allowed to
-                  submit Dynamic DNS updates for master zones. The default is
-                  to deny
-                  updates from all hosts.  Note that allowing updates based
-                  on the requestor's IP address is insecure; see
-                  <xref linkend="dynamic_update_security"/> for details.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>allow-update-forwarding</command></term>
-              <listitem>
-                <para>
-                  Specifies which hosts are allowed to
-                  submit Dynamic DNS updates to slave zones to be forwarded to
-                  the
-                  master.  The default is <userinput>{ none; }</userinput>,
-                  which
-                  means that no update forwarding will be performed.  To
-                  enable
-                  update forwarding, specify
-                  <userinput>allow-update-forwarding { any; };</userinput>.
-                  Specifying values other than <userinput>{ none; }</userinput> or
-                  <userinput>{ any; }</userinput> is usually
-                  counterproductive, since
-                  the responsibility for update access control should rest
-                  with the
-                  master server, not the slaves.
-                </para>
-                <para>
-                  Note that enabling the update forwarding feature on a slave
-                  server
-                  may expose master servers relying on insecure IP address
-                  based
-                  access control to attacks; see <xref linkend="dynamic_update_security"/>
-                  for more details.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>allow-v6-synthesis</command></term>
-              <listitem>
-                <para>
-                  This option was introduced for the smooth transition from
-                  AAAA
-                  to A6 and from "nibble labels" to binary labels.
-                  However, since both A6 and binary labels were then
-                  deprecated,
-                  this option was also deprecated.
-                  It is now ignored with some warning messages.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>allow-transfer</command></term>
-              <listitem>
-                <para>
-                  Specifies which hosts are allowed to
-                  receive zone transfers from the server. <command>allow-transfer</command> may
-                  also be specified in the <command>zone</command>
-                  statement, in which
-                  case it overrides the <command>options allow-transfer</command> statement.
-                  If not specified, the default is to allow transfers to all
-                  hosts.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>blackhole</command></term>
-              <listitem>
-                <para>
-                  Specifies a list of addresses that the
-                  server will not accept queries from or use to resolve a
-                  query. Queries
-                  from these addresses will not be responded to. The default
-                  is <userinput>none</userinput>.
-                </para>
-              </listitem>
-            </varlistentry>
-
-          </variablelist>
-
-        </sect3>
-
-        <sect3>
-          <title>Interfaces</title>
-          <para>
-            The interfaces and ports that the server will answer queries
-            from may be specified using the <command>listen-on</command> option. <command>listen-on</command> takes
-            an optional port, and an <varname>address_match_list</varname>.
-            The server will listen on all interfaces allowed by the address
-            match list. If a port is not specified, port 53 will be used.
-          </para>
-          <para>
-            Multiple <command>listen-on</command> statements are
-            allowed.
-            For example,
-          </para>
-
-<programlisting>listen-on { 5.6.7.8; };
-listen-on port 1234 { !1.2.3.4; 1.2/16; };
-</programlisting>
-
-          <para>
-            will enable the name server on port 53 for the IP address
-            5.6.7.8, and on port 1234 of an address on the machine in net
-            1.2 that is not 1.2.3.4.
-          </para>
-
-          <para>
-            If no <command>listen-on</command> is specified, the
-            server will listen on port 53 on all interfaces.
-          </para>
-
-          <para>
-            The <command>listen-on-v6</command> option is used to
-            specify the interfaces and the ports on which the server will
-            listen
-            for incoming queries sent using IPv6.
-          </para>
-
-          <para>
-            When <programlisting>{ any; }</programlisting> is
-            specified
-            as the <varname>address_match_list</varname> for the
-            <command>listen-on-v6</command> option,
-            the server does not bind a separate socket to each IPv6 interface
-            address as it does for IPv4 if the operating system has enough API
-            support for IPv6 (specifically if it conforms to RFC 3493 and RFC
-            3542).
-            Instead, it listens on the IPv6 wildcard address.
-            If the system only has incomplete API support for IPv6, however,
-            the behavior is the same as that for IPv4.
-          </para>
-
-          <para>
-            A list of particular IPv6 addresses can also be specified, in
-            which case
-            the server listens on a separate socket for each specified
-            address,
-            regardless of whether the desired API is supported by the system.
-          </para>
-
-          <para>
-            Multiple <command>listen-on-v6</command> options can
-            be used.
-            For example,
-          </para>
-
-<programlisting>listen-on-v6 { any; };
-listen-on-v6 port 1234 { !2001:db8::/32; any; };
-</programlisting>
-
-          <para>
-            will enable the name server on port 53 for any IPv6 addresses
-            (with a single wildcard socket),
-            and on port 1234 of IPv6 addresses that is not in the prefix
-            2001:db8::/32 (with separate sockets for each matched address.)
-          </para>
-
-          <para>
-            To make the server not listen on any IPv6 address, use
-          </para>
-
-<programlisting>listen-on-v6 { none; };
-</programlisting>
-
-          <para>
-            If no <command>listen-on-v6</command> option is
-            specified,
-            the server will not listen on any IPv6 address.
-          </para>
-        </sect3>
-
-        <sect3>
-          <title>Query Address</title>
-          <para>
-            If the server doesn't know the answer to a question, it will
-            query other name servers. <command>query-source</command> specifies
-            the address and port used for such queries. For queries sent over
-            IPv6, there is a separate <command>query-source-v6</command> option.
-            If <command>address</command> is <command>*</command> (asterisk) or is omitted,
-            a wildcard IP address (<command>INADDR_ANY</command>)
-            will be used.
-            If <command>port</command> is <command>*</command> or is omitted,
-            a random unprivileged port will be used. The <command>avoid-v4-udp-ports</command>
-            and <command>avoid-v6-udp-ports</command> options can be used
-            to prevent named
-            from selecting certain ports. The defaults are:
-          </para>
-
-<programlisting>query-source address * port *;
-query-source-v6 address * port *;
-</programlisting>
-
-          <note>
-            <para>
-              The address specified in the <command>query-source</command> option
-              is used for both UDP and TCP queries, but the port applies only
-              to
-              UDP queries.  TCP queries always use a random
-              unprivileged port.
-            </para>
-          </note>
-	  <note>
-	    <para>
-	      Solaris 2.5.1 and earlier does not support setting the source
-	      address for TCP sockets.
-	    </para>
-	  </note>
-          <note>
-            <para>
-              See also <command>transfer-source</command> and
-              <command>notify-source</command>.
-            </para>
-          </note>
-        </sect3>
-
-        <sect3 id="zone_transfers">
-          <title>Zone Transfers</title>
-          <para>
-            <acronym>BIND</acronym> has mechanisms in place to
-            facilitate zone transfers
-            and set limits on the amount of load that transfers place on the
-            system. The following options apply to zone transfers.
-          </para>
-
-          <variablelist>
-
-            <varlistentry>
-              <term><command>also-notify</command></term>
-              <listitem>
-                <para>
-                  Defines a global list of IP addresses of name servers
-                  that are also sent NOTIFY messages whenever a fresh copy of
-                  the
-                  zone is loaded, in addition to the servers listed in the
-                  zone's NS records.
-                  This helps to ensure that copies of the zones will
-                  quickly converge on stealth servers. If an <command>also-notify</command> list
-                  is given in a <command>zone</command> statement,
-                  it will override
-                  the <command>options also-notify</command>
-                  statement. When a <command>zone notify</command>
-                  statement
-                  is set to <command>no</command>, the IP
-                  addresses in the global <command>also-notify</command> list will
-                  not be sent NOTIFY messages for that zone. The default is
-                  the empty
-                  list (no global notification list).
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>max-transfer-time-in</command></term>
-              <listitem>
-                <para>
-                  Inbound zone transfers running longer than
-                  this many minutes will be terminated. The default is 120
-                  minutes
-                  (2 hours).  The maximum value is 28 days (40320 minutes).
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>max-transfer-idle-in</command></term>
-              <listitem>
-                <para>
-                  Inbound zone transfers making no progress
-                  in this many minutes will be terminated. The default is 60
-                  minutes
-                  (1 hour).  The maximum value is 28 days (40320 minutes).
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>max-transfer-time-out</command></term>
-              <listitem>
-                <para>
-                  Outbound zone transfers running longer than
-                  this many minutes will be terminated. The default is 120
-                  minutes
-                  (2 hours).  The maximum value is 28 days (40320 minutes).
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>max-transfer-idle-out</command></term>
-              <listitem>
-                <para>
-                  Outbound zone transfers making no progress
-                  in this many minutes will be terminated.  The default is 60
-                  minutes (1
-                  hour).  The maximum value is 28 days (40320 minutes).
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>serial-query-rate</command></term>
-              <listitem>
-                <para>
-                  Slave servers will periodically query master servers
-                  to find out if zone serial numbers have changed. Each such
-                  query uses
-                  a minute amount of the slave server's network bandwidth.  To
-                  limit the
-                  amount of bandwidth used, BIND 9 limits the rate at which
-                  queries are
-                  sent.  The value of the <command>serial-query-rate</command> option,
-                  an integer, is the maximum number of queries sent per
-                  second.
-                  The default is 20.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>serial-queries</command></term>
-              <listitem>
-                <para>
-                  In BIND 8, the <command>serial-queries</command>
-                  option
-                  set the maximum number of concurrent serial number queries
-                  allowed to be outstanding at any given time.
-                  BIND 9 does not limit the number of outstanding
-                  serial queries and ignores the <command>serial-queries</command> option.
-                  Instead, it limits the rate at which the queries are sent
-                  as defined using the <command>serial-query-rate</command> option.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>transfer-format</command></term>
-              <listitem>
-
-                <para>
-                  Zone transfers can be sent using two different formats,
-                  <command>one-answer</command> and
-		  <command>many-answers</command>.
-                  The <command>transfer-format</command> option is used
-                  on the master server to determine which format it sends.
-                  <command>one-answer</command> uses one DNS message per
-                  resource record transferred.
-                  <command>many-answers</command> packs as many resource
-		  records as possible into a message.
-		  <command>many-answers</command> is more efficient, but is
-		  only supported by relatively new slave servers,
-                  such as <acronym>BIND</acronym> 9, <acronym>BIND</acronym>
-		  8.x and <acronym>BIND</acronym> 4.9.5 onwards.
-	          The <command>many-answers</command> format is also supported by
-		  recent Microsoft Windows nameservers.
-		  The default is <command>many-answers</command>.
-		  <command>transfer-format</command> may be overridden on a
-		  per-server basis by using the <command>server</command>
-		  statement.
-                </para>
-
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>transfers-in</command></term>
-              <listitem>
-                <para>
-                  The maximum number of inbound zone transfers
-                  that can be running concurrently. The default value is <literal>10</literal>.
-                  Increasing <command>transfers-in</command> may
-                  speed up the convergence
-                  of slave zones, but it also may increase the load on the
-                  local system.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>transfers-out</command></term>
-              <listitem>
-                <para>
-                  The maximum number of outbound zone transfers
-                  that can be running concurrently. Zone transfer requests in
-                  excess
-                  of the limit will be refused. The default value is <literal>10</literal>.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>transfers-per-ns</command></term>
-              <listitem>
-                <para>
-                  The maximum number of inbound zone transfers
-                  that can be concurrently transferring from a given remote
-                  name server.
-                  The default value is <literal>2</literal>.
-                  Increasing <command>transfers-per-ns</command>
-                  may
-                  speed up the convergence of slave zones, but it also may
-                  increase
-                  the load on the remote name server. <command>transfers-per-ns</command> may
-                  be overridden on a per-server basis by using the <command>transfers</command> phrase
-                  of the <command>server</command> statement.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>transfer-source</command></term>
-              <listitem>
-                <para><command>transfer-source</command>
-		  determines which local address will be bound to IPv4
-                  TCP connections used to fetch zones transferred
-                  inbound by the server.  It also determines the
-                  source IPv4 address, and optionally the UDP port,
-                  used for the refresh queries and forwarded dynamic
-                  updates.  If not set, it defaults to a system
-                  controlled value which will usually be the address
-                  of the interface "closest to" the remote end. This
-                  address must appear in the remote end's
-                  <command>allow-transfer</command> option for the
-                  zone being transferred, if one is specified. This
-                  statement sets the
-                  <command>transfer-source</command> for all zones,
-                  but can be overridden on a per-view or per-zone
-                  basis by including a
-                  <command>transfer-source</command> statement within
-                  the <command>view</command> or
-                  <command>zone</command> block in the configuration
-                  file.
-                </para>
-	        <note>
-	          <para>
-	            Solaris 2.5.1 and earlier does not support setting the
-		    source address for TCP sockets.
-	          </para>
-                </note>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>transfer-source-v6</command></term>
-              <listitem>
-                <para>
-                  The same as <command>transfer-source</command>,
-                  except zone transfers are performed using IPv6.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>alt-transfer-source</command></term>
-              <listitem>
-                <para>
-                  An alternate transfer source if the one listed in
-                  <command>transfer-source</command> fails and
-                  <command>use-alt-transfer-source</command> is
-                  set.
-                </para>
-		<note>
-		  If you do not wish the alternate transfer source
-		  to be used, you should set
-		  <command>use-alt-transfer-source</command>
-		  appropriately and you should not depend upon
-		  getting a answer back to the first refresh
-		  query.
-		</note>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>alt-transfer-source-v6</command></term>
-              <listitem>
-                <para>
-                  An alternate transfer source if the one listed in
-                  <command>transfer-source-v6</command> fails and
-                  <command>use-alt-transfer-source</command> is
-                  set.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>use-alt-transfer-source</command></term>
-              <listitem>
-                <para>
-                  Use the alternate transfer sources or not.  If views are
-                  specified this defaults to <command>no</command>
-                  otherwise it defaults to
-                  <command>yes</command> (for BIND 8
-                  compatibility).
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>notify-source</command></term>
-              <listitem>
-                <para><command>notify-source</command>
-		  determines which local source address, and
-                  optionally UDP port, will be used to send NOTIFY
-                  messages.  This address must appear in the slave
-                  server's <command>masters</command> zone clause or
-                  in an <command>allow-notify</command> clause.  This
-                  statement sets the <command>notify-source</command>
-                  for all zones, but can be overridden on a per-zone or
-                  per-view basis by including a
-                  <command>notify-source</command> statement within
-                  the <command>zone</command> or
-                  <command>view</command> block in the configuration
-                  file.
-                </para>
-	        <note>
-	          <para>
-	            Solaris 2.5.1 and earlier does not support setting the
-		    source address for TCP sockets.
-	          </para>
-                </note>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>notify-source-v6</command></term>
-              <listitem>
-                <para>
-                  Like <command>notify-source</command>,
-                  but applies to notify messages sent to IPv6 addresses.
-                </para>
-              </listitem>
-            </varlistentry>
-
-          </variablelist>
-
-        </sect3>
-
-        <sect3>
-          <title>Bad UDP Port Lists</title>
-          <para><command>avoid-v4-udp-ports</command>
-	    and <command>avoid-v6-udp-ports</command> specify a list
-            of IPv4 and IPv6 UDP ports that will not be used as system
-            assigned source ports for UDP sockets.  These lists
-            prevent named from choosing as its random source port a
-            port that is blocked by your firewall.  If a query went
-            out with such a source port, the answer would not get by
-            the firewall and the name server would have to query
-            again.
-          </para>
-        </sect3>
-
-        <sect3>
-          <title>Operating System Resource Limits</title>
-
-          <para>
-            The server's usage of many system resources can be limited.
-            Scaled values are allowed when specifying resource limits.  For
-            example, <command>1G</command> can be used instead of
-            <command>1073741824</command> to specify a limit of
-            one
-            gigabyte. <command>unlimited</command> requests
-            unlimited use, or the
-            maximum available amount. <command>default</command>
-            uses the limit
-            that was in force when the server was started. See the description
-            of <command>size_spec</command> in <xref linkend="configuration_file_elements"/>.
-          </para>
-
-          <para>
-            The following options set operating system resource limits for
-            the name server process.  Some operating systems don't support
-            some or
-            any of the limits. On such systems, a warning will be issued if
-            the
-            unsupported limit is used.
-          </para>
-
-          <variablelist>
-
-            <varlistentry>
-              <term><command>coresize</command></term>
-              <listitem>
-                <para>
-                  The maximum size of a core dump. The default
-                  is <literal>default</literal>.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>datasize</command></term>
-              <listitem>
-                <para>
-                  The maximum amount of data memory the server
-                  may use. The default is <literal>default</literal>.
-                  This is a hard limit on server memory usage.
-                  If the server attempts to allocate memory in excess of this
-                  limit, the allocation will fail, which may in turn leave
-                  the server unable to perform DNS service.  Therefore,
-                  this option is rarely useful as a way of limiting the
-                  amount of memory used by the server, but it can be used
-                  to raise an operating system data size limit that is
-                  too small by default.  If you wish to limit the amount
-                  of memory used by the server, use the
-                  <command>max-cache-size</command> and
-                  <command>recursive-clients</command>
-                  options instead.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>files</command></term>
-              <listitem>
-                <para>
-                  The maximum number of files the server
-                  may have open concurrently. The default is <literal>unlimited</literal>.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>stacksize</command></term>
-              <listitem>
-                <para>
-                  The maximum amount of stack memory the server
-                  may use. The default is <literal>default</literal>.
-                </para>
-              </listitem>
-            </varlistentry>
-
-          </variablelist>
-
-        </sect3>
-
-        <sect3>
-          <title>Server  Resource Limits</title>
-
-          <para>
-            The following options set limits on the server's
-            resource consumption that are enforced internally by the
-            server rather than the operating system.
-          </para>
-
-          <variablelist>
-
-            <varlistentry>
-              <term><command>max-ixfr-log-size</command></term>
-              <listitem>
-                <para>
-                  This option is obsolete; it is accepted
-                  and ignored for BIND 8 compatibility.  The option
-                  <command>max-journal-size</command> performs a
-                  similar function in BIND 9.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>max-journal-size</command></term>
-              <listitem>
-                <para>
-                  Sets a maximum size for each journal file
-                  (see <xref linkend="journal"/>).  When the journal file
-                  approaches
-                  the specified size, some of the oldest transactions in the
-                  journal
-                  will be automatically removed.  The default is
-                  <literal>unlimited</literal>.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>host-statistics-max</command></term>
-              <listitem>
-                <para>
-                  In BIND 8, specifies the maximum number of host statistics
-                  entries to be kept.
-                  Not implemented in BIND 9.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>recursive-clients</command></term>
-              <listitem>
-                <para>
-                  The maximum number of simultaneous recursive lookups
-                  the server will perform on behalf of clients.  The default
-                  is
-                  <literal>1000</literal>.  Because each recursing
-                  client uses a fair
-                  bit of memory, on the order of 20 kilobytes, the value of
-                  the
-                  <command>recursive-clients</command> option may
-                  have to be decreased
-                  on hosts with limited memory.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>tcp-clients</command></term>
-              <listitem>
-                <para>
-                  The maximum number of simultaneous client TCP
-                  connections that the server will accept.
-                  The default is <literal>100</literal>.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>max-cache-size</command></term>
-              <listitem>
-                <para>
-                  The maximum amount of memory to use for the
-                  server's cache, in bytes.  When the amount of data in the
-                  cache
-                  reaches this limit, the server will cause records to expire
-                  prematurely so that the limit is not exceeded.  In a server
-                  with
-                  multiple views, the limit applies separately to the cache of
-                  each
-                  view.  The default is <literal>unlimited</literal>, meaning that
-                  records are purged from the cache only when their TTLs
-                  expire.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>tcp-listen-queue</command></term>
-              <listitem>
-                <para>
-                  The listen queue depth.  The default and minimum is 3.
-                  If the kernel supports the accept filter "dataready" this
-                  also controls how
-                  many TCP connections that will be queued in kernel space
-                  waiting for
-                  some data before being passed to accept.  Values less than 3
-                  will be
-                  silently raised.
-                </para>
-              </listitem>
-            </varlistentry>
-
-          </variablelist>
-
-        </sect3>
-
-        <sect3>
-          <title>Periodic Task Intervals</title>
-
-          <variablelist>
-
-            <varlistentry>
-              <term><command>cleaning-interval</command></term>
-              <listitem>
-                <para>
-                  The server will remove expired resource records
-                  from the cache every <command>cleaning-interval</command> minutes.
-                  The default is 60 minutes.  The maximum value is 28 days
-                  (40320 minutes).
-                  If set to 0, no periodic cleaning will occur.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>heartbeat-interval</command></term>
-              <listitem>
-                <para>
-                  The server will perform zone maintenance tasks
-                  for all zones marked as <command>dialup</command> whenever this
-                  interval expires. The default is 60 minutes. Reasonable
-                  values are up
-                  to 1 day (1440 minutes).  The maximum value is 28 days
-                  (40320 minutes).
-                  If set to 0, no zone maintenance for these zones will occur.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>interface-interval</command></term>
-              <listitem>
-                <para>
-                  The server will scan the network interface list
-                  every <command>interface-interval</command>
-                  minutes. The default
-                  is 60 minutes. The maximum value is 28 days (40320 minutes).
-                  If set to 0, interface scanning will only occur when
-                  the configuration file is  loaded. After the scan, the
-                  server will
-                  begin listening for queries on any newly discovered
-                  interfaces (provided they are allowed by the
-                  <command>listen-on</command> configuration), and
-                  will
-                  stop listening on interfaces that have gone away.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>statistics-interval</command></term>
-              <listitem>
-                <para>
-                  Name server statistics will be logged
-                  every <command>statistics-interval</command>
-                  minutes. The default is
-                  60. The maximum value is 28 days (40320 minutes).
-                  If set to 0, no statistics will be logged.
-                  </para><note>
-                  <simpara>
-                    Not yet implemented in
-                    <acronym>BIND</acronym> 9.
-                  </simpara>
-                </note>
-              </listitem>
-            </varlistentry>
-
-          </variablelist>
-
-        </sect3>
-
-        <sect3 id="topology">
-          <title>Topology</title>
-
-          <para>
-            All other things being equal, when the server chooses a name
-            server
-            to query from a list of name servers, it prefers the one that is
-            topologically closest to itself. The <command>topology</command> statement
-            takes an <command>address_match_list</command> and
-            interprets it
-            in a special way. Each top-level list element is assigned a
-            distance.
-            Non-negated elements get a distance based on their position in the
-            list, where the closer the match is to the start of the list, the
-            shorter the distance is between it and the server. A negated match
-            will be assigned the maximum distance from the server. If there
-            is no match, the address will get a distance which is further than
-            any non-negated list element, and closer than any negated element.
-            For example,
-          </para>
-
-<programlisting>topology {
-    10/8;
-    !1.2.3/24;
-    { 1.2/16; 3/8; };
-};</programlisting>
-
-          <para>
-            will prefer servers on network 10 the most, followed by hosts
-            on network 1.2.0.0 (netmask 255.255.0.0) and network 3, with the
-            exception of hosts on network 1.2.3 (netmask 255.255.255.0), which
-            is preferred least of all.
-          </para>
-          <para>
-            The default topology is
-          </para>
-
-<programlisting>    topology { localhost; localnets; };
-</programlisting>
-
-          <note>
-            <simpara>
-              The <command>topology</command> option
-              is not implemented in <acronym>BIND</acronym> 9.
-            </simpara>
-          </note>
-        </sect3>
-
-        <sect3 id="the_sortlist_statement">
-
-          <title>The <command>sortlist</command> Statement</title>
-
-          <para>
-            The response to a DNS query may consist of multiple resource
-            records (RRs) forming a resource records set (RRset).
-            The name server will normally return the
-            RRs within the RRset in an indeterminate order
-            (but see the <command>rrset-order</command>
-            statement in <xref linkend="rrset_ordering"/>).
-            The client resolver code should rearrange the RRs as appropriate,
-            that is, using any addresses on the local net in preference to
-            other addresses.
-            However, not all resolvers can do this or are correctly
-            configured.
-            When a client is using a local server, the sorting can be performed
-            in the server, based on the client's address. This only requires
-            configuring the name servers, not all the clients.
-          </para>
-
-          <para>
-            The <command>sortlist</command> statement (see below)
-            takes
-            an <command>address_match_list</command> and
-            interprets it even
-            more specifically than the <command>topology</command>
-            statement
-            does (<xref linkend="topology"/>).
-            Each top level statement in the <command>sortlist</command> must
-            itself be an explicit <command>address_match_list</command> with
-            one or two elements. The first element (which may be an IP
-            address,
-            an IP prefix, an ACL name or a nested <command>address_match_list</command>)
-            of each top level list is checked against the source address of
-            the query until a match is found.
-          </para>
-          <para>
-            Once the source address of the query has been matched, if
-            the top level statement contains only one element, the actual
-            primitive
-            element that matched the source address is used to select the
-            address
-            in the response to move to the beginning of the response. If the
-            statement is a list of two elements, then the second element is
-            treated the same as the <command>address_match_list</command> in
-            a <command>topology</command> statement. Each top
-            level element
-            is assigned a distance and the address in the response with the
-            minimum
-            distance is moved to the beginning of the response.
-          </para>
-          <para>
-            In the following example, any queries received from any of
-            the addresses of the host itself will get responses preferring
-            addresses
-            on any of the locally connected networks. Next most preferred are
-            addresses
-            on the 192.168.1/24 network, and after that either the
-            192.168.2/24
-            or
-            192.168.3/24 network with no preference shown between these two
-            networks. Queries received from a host on the 192.168.1/24 network
-            will prefer other addresses on that network to the 192.168.2/24
-            and
-            192.168.3/24 networks. Queries received from a host on the
-            192.168.4/24
-            or the 192.168.5/24 network will only prefer other addresses on
-            their directly connected networks.
-          </para>
-
-<programlisting>sortlist {
-    { localhost;                                   // IF   the local host
-        { localnets;                               // THEN first fit on the
-            192.168.1/24;                          //   following nets
-            { 192.168.2/24; 192.168.3/24; }; }; };
-    { 192.168.1/24;                                // IF   on class C 192.168.1
-        { 192.168.1/24;                            // THEN use .1, or .2 or .3
-            { 192.168.2/24; 192.168.3/24; }; }; };
-    { 192.168.2/24;                                // IF   on class C 192.168.2
-        { 192.168.2/24;                            // THEN use .2, or .1 or .3
-            { 192.168.1/24; 192.168.3/24; }; }; };
-    { 192.168.3/24;                                // IF   on class C 192.168.3
-        { 192.168.3/24;                            // THEN use .3, or .1 or .2
-            { 192.168.1/24; 192.168.2/24; }; }; };
-    { { 192.168.4/24; 192.168.5/24; };             // if .4 or .5, prefer that net
-    };
-};</programlisting>
-
-          <para>
-            The following example will give reasonable behavior for the
-            local host and hosts on directly connected networks. It is similar
-            to the behavior of the address sort in <acronym>BIND</acronym> 4.9.x. Responses sent
-            to queries from the local host will favor any of the directly
-            connected
-            networks. Responses sent to queries from any other hosts on a
-            directly
-            connected network will prefer addresses on that same network.
-            Responses
-            to other queries will not be sorted.
-          </para>
-
-<programlisting>sortlist {
-           { localhost; localnets; };
-           { localnets; };
-};
-</programlisting>
-
-        </sect3>
-        <sect3 id="rrset_ordering">
-          <title id="rrset_ordering_title">RRset Ordering</title>
-          <para>
-            When multiple records are returned in an answer it may be
-            useful to configure the order of the records placed into the
-            response.
-            The <command>rrset-order</command> statement permits
-            configuration
-            of the ordering of the records in a multiple record response.
-            See also the <command>sortlist</command> statement,
-            <xref linkend="the_sortlist_statement"/>.
-          </para>
-
-          <para>
-            An <command>order_spec</command> is defined as
-            follows:
-          </para>
-          <para>
-	    <optional>class <replaceable>class_name</replaceable></optional>
-            <optional>type <replaceable>type_name</replaceable></optional>
-            <optional>name <replaceable>"domain_name"</replaceable></optional>
-	    order <replaceable>ordering</replaceable>
-	  </para>
-          <para>
-            If no class is specified, the default is <command>ANY</command>.
-            If no type is specified, the default is <command>ANY</command>.
-            If no name is specified, the default is "<command>*</command>" (asterisk).
-          </para>
-          <para>
-            The legal values for <command>ordering</command> are:
-          </para>
-          <informaltable colsep="0" rowsep="0">
-            <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="4Level-table">
-              <colspec colname="1" colnum="1" colsep="0" colwidth="0.750in"/>
-              <colspec colname="2" colnum="2" colsep="0" colwidth="3.750in"/>
-              <tbody>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para><command>fixed</command></para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      Records are returned in the order they
-                      are defined in the zone file.
-                    </para>
-                  </entry>
-                </row>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para><command>random</command></para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      Records are returned in some random order.
-                    </para>
-                  </entry>
-                </row>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para><command>cyclic</command></para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      Records are returned in a round-robin
-                      order.
-                    </para>
-                  </entry>
-                </row>
-              </tbody>
-            </tgroup>
-          </informaltable>
-          <para>
-            For example:
-          </para>
-
-<programlisting>rrset-order {
-   class IN type A name "host.example.com" order random;
-   order cyclic;
-};
-</programlisting>
-
-          <para>
-            will cause any responses for type A records in class IN that
-            have "<literal>host.example.com</literal>" as a
-            suffix, to always be returned
-            in random order. All other records are returned in cyclic order.
-          </para>
-          <para>
-            If multiple <command>rrset-order</command> statements
-            appear,
-            they are not combined &mdash; the last one applies.
-          </para>
-
-          <note>
-            <simpara>
-              The <command>rrset-order</command> statement
-              is not yet fully implemented in <acronym>BIND</acronym> 9.
-              BIND 9 currently does not fully support "fixed" ordering.
-            </simpara>
-          </note>
-        </sect3>
-
-        <sect3 id="tuning">
-          <title>Tuning</title>
-
-          <variablelist>
-
-            <varlistentry>
-              <term><command>lame-ttl</command></term>
-              <listitem>
-                <para>
-                  Sets the number of seconds to cache a
-                  lame server indication. 0 disables caching. (This is
-                  <emphasis role="bold">NOT</emphasis> recommended.)
-                  The default is <literal>600</literal> (10 minutes) and the
-                  maximum value is
-                  <literal>1800</literal> (30 minutes).
-                </para>
-
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>max-ncache-ttl</command></term>
-              <listitem>
-                <para>
-                  To reduce network traffic and increase performance,
-                  the server stores negative answers. <command>max-ncache-ttl</command> is
-                  used to set a maximum retention time for these answers in
-                  the server
-                  in seconds. The default
-                  <command>max-ncache-ttl</command> is <literal>10800</literal> seconds (3 hours).
-                  <command>max-ncache-ttl</command> cannot exceed
-                  7 days and will
-                  be silently truncated to 7 days if set to a greater value.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>max-cache-ttl</command></term>
-              <listitem>
-                <para>
-		  Sets the maximum time for which the server will
-                  cache ordinary (positive) answers. The default is
-                  one week (7 days).
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>min-roots</command></term>
-              <listitem>
-                <para>
-                  The minimum number of root servers that
-                  is required for a request for the root servers to be
-                  accepted. The default
-                  is <userinput>2</userinput>.
-                </para>
-                <note>
-                  <simpara>
-                    Not implemented in <acronym>BIND</acronym> 9.
-                  </simpara>
-                </note>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>sig-validity-interval</command></term>
-              <listitem>
-                <para>
-                  Specifies the number of days into the
-                  future when DNSSEC signatures automatically generated as a
-                  result
-                  of dynamic updates (<xref linkend="dynamic_update"/>)
-                  will expire. The default is <literal>30</literal> days.
-                  The maximum value is 10 years (3660 days). The signature
-                  inception time is unconditionally set to one hour before the
-                  current time
-                  to allow for a limited amount of clock skew.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>min-refresh-time</command></term>
-              <term><command>max-refresh-time</command></term>
-              <term><command>min-retry-time</command></term>
-              <term><command>max-retry-time</command></term>
-              <listitem>
-                <para>
-                  These options control the server's behavior on refreshing a
-                  zone
-                  (querying for SOA changes) or retrying failed transfers.
-                  Usually the SOA values for the zone are used, but these
-                  values
-                  are set by the master, giving slave server administrators
-                  little
-                  control over their contents.
-                </para>
-                <para>
-                  These options allow the administrator to set a minimum and
-                  maximum
-                  refresh and retry time either per-zone, per-view, or
-                  globally.
-                  These options are valid for slave and stub zones,
-                  and clamp the SOA refresh and retry times to the specified
-                  values.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>edns-udp-size</command></term>
-              <listitem>
-                <para>
-		  Sets the advertised EDNS UDP buffer size in bytes.  Valid
-                  values are 512 to 4096 (values outside this range
-                  will be silently adjusted).  The default value is
-                  4096.  The usual reason for setting edns-udp-size to
-                  a non-default value is to get UDP answers to pass
-                  through broken firewalls that block fragmented
-                  packets and/or block UDP packets that are greater
-                  than 512 bytes.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>max-udp-size</command></term>
-              <listitem>
-                <para>
-		  Sets the maximum EDNS UDP message size named will
-		  send in bytes.  Valid values are 512 to 4096 (values outside
-		  this range will be silently adjusted).  The default
-		  value is 4096.  The usual reason for setting
-		  max-udp-size to a non-default value is to get UDP
-		  answers to pass through broken firewalls that
-		  block fragmented packets and/or block UDP packets
-		  that are greater than 512 bytes.
-		  This is independent of the advertised receive
-		  buffer (<command>edns-udp-size</command>).
-		</para>
-	      </listitem>
-	    </varlistentry>
-
-	    <varlistentry>
-	      <term><command>masterfile-format</command></term>
-	      <listitem>
-	        <para>Specifies
-		  the file format of zone files (see
-	          <xref linkend="zonefile_format"/>).
-	          The default value is <constant>text</constant>, which is the
-		  standard textual representation.  Files in other formats
-		  than <constant>text</constant> are typically expected
-		  to be generated by the <command>named-compilezone</command> tool.
-		  Note that when a zone file in a different format than
-		  <constant>text</constant> is loaded, <command>named</command>
-	          may omit some of the checks which would be performed for a
-		  file in the <constant>text</constant> format.  In particular,
-		  <command>check-names</command> checks do not apply
-		  for the <constant>raw</constant> format.  This means
-		  a zone file in the <constant>raw</constant> format
-		  must be generated with the same check level as that
-		  specified in the <command>named</command> configuration
-		  file.  This statement sets the
-		  <command>masterfile-format</command> for all zones,
-		  but can be overridden on a per-zone or per-view basis
-		  by including a <command>masterfile-format</command>
-		  statement within the <command>zone</command> or
-		  <command>view</command> block in the configuration
-		  file.
-	        </para>
-	      </listitem>
-	    </varlistentry>
-
-	    <varlistentry>
-	      <term><command>clients-per-query</command></term>
-	      <term><command>max-clients-per-query</command></term>
-              <listitem>
-		<para>These set the
-		  initial value (minimum) and maximum number of recursive
-		  simultanious clients for any given query
-		  (&lt;qname,qtype,qclass&gt;) that the server will accept
-		  before dropping additional clients.  named will attempt to
-		  self tune this value and changes will be logged.  The
-		  default values are 10 and 100.
-		</para>
-		<para>
-	          This value should reflect how many queries come in for
-		  a given name in the time it takes to resolve that name.
-		  If the number of queries exceed this value, named will
-		  assume that it is dealing with a non-responsive zone
-		  and will drop additional queries.  If it gets a response
-		  after dropping queries, it will raise the estimate.  The
-		  estimate will then be lowered in 20 minutes if it has
-		  remained unchanged.
-		</para>
-		<para>
-		  If <command>clients-per-query</command> is set to zero,
-		  then there is no limit on the number of clients per query
-		  and no queries will be dropped.
-		</para>
-		<para>
-		  If <command>max-clients-per-query</command> is set to zero,
-		  then there is no upper bound other than imposed by
-		  <command>recursive-clients</command>.
-		</para>
-              </listitem>
-	    </varlistentry>
-
-            <varlistentry>
-              <term><command>notify-delay</command></term>
-              <listitem>
-                <para>
-                  The delay, in seconds, between sending sets of notify
-                  messages for a zone.  The default is zero.
-                </para>
-              </listitem>
-            </varlistentry>
-	  </variablelist>
-
-        </sect3>
-
-        <sect3 id="builtin">
-          <title>Built-in server information zones</title>
-
-          <para>
-            The server provides some helpful diagnostic information
-            through a number of built-in zones under the
-            pseudo-top-level-domain <literal>bind</literal> in the
-            <command>CHAOS</command> class.  These zones are part
-            of a
-            built-in view (see <xref linkend="view_statement_grammar"/>) of
-            class
-            <command>CHAOS</command> which is separate from the
-            default view of
-            class <command>IN</command>; therefore, any global
-            server options
-            such as <command>allow-query</command> do not apply
-            the these zones.
-            If you feel the need to disable these zones, use the options
-            below, or hide the built-in <command>CHAOS</command>
-            view by
-            defining an explicit view of class <command>CHAOS</command>
-            that matches all clients.
-          </para>
-
-          <variablelist>
-
-            <varlistentry>
-              <term><command>version</command></term>
-              <listitem>
-                <para>
-                  The version the server should report
-                  via a query of the name <literal>version.bind</literal>
-                  with type <command>TXT</command>, class <command>CHAOS</command>.
-                  The default is the real version number of this server.
-                  Specifying <command>version none</command>
-                  disables processing of the queries.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>hostname</command></term>
-              <listitem>
-                <para>
-                  The hostname the server should report via a query of
-                  the name <filename>hostname.bind</filename>
-                  with type <command>TXT</command>, class <command>CHAOS</command>.
-                  This defaults to the hostname of the machine hosting the
-                  name server as
-                  found by the gethostname() function.  The primary purpose of such queries
-                  is to
-                  identify which of a group of anycast servers is actually
-                  answering your queries.  Specifying <command>hostname none;</command>
-                  disables processing of the queries.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>server-id</command></term>
-              <listitem>
-                <para>
-                  The ID of the server should report via a query of
-                  the name <filename>ID.SERVER</filename>
-                  with type <command>TXT</command>, class <command>CHAOS</command>.
-                  The primary purpose of such queries is to
-                  identify which of a group of anycast servers is actually
-                  answering your queries.  Specifying <command>server-id none;</command>
-                  disables processing of the queries.
-                  Specifying <command>server-id hostname;</command> will cause named to
-                  use the hostname as found by the gethostname() function.
-                  The default <command>server-id</command> is <command>none</command>.
-                </para>
-              </listitem>
-            </varlistentry>
-
-          </variablelist>
-
-        </sect3>
-
-        <sect3 id="empty">
-          <title>Built-in Empty Zones</title>
-	  <para>
-	    Named has some built-in empty zones (SOA and NS records only).
-	    These are for zones that should normally be answered locally
-	    and which queries should not be sent to the Internet's root
-	    servers.  The official servers which cover these namespaces
-	    return NXDOMAIN responses to these queries.  In particular,
-	    these cover the reverse namespace for addresses from RFC 1918 and
-	    RFC 3330.  They also include the reverse namespace for IPv6 local
-	    address (locally assigned), IPv6 link local addresses, the IPv6
-	    loopback address and the IPv6 unknown addresss.
-	  </para>
-	  <para>
-	    Named will attempt to determine if a built in zone already exists
-	    or is active (covered by a forward-only forwarding declaration)
-	    and will not not create a empty zone in that case.
-	  </para>
-	  <para>
-	    The current list of empty zones is:
-	    <itemizedlist>
-	      <listitem>10.IN-ADDR.ARPA</listitem>
-	      <listitem>127.IN-ADDR.ARPA</listitem>
-	      <listitem>254.169.IN-ADDR.ARPA</listitem>
-	      <listitem>16.172.IN-ADDR.ARPA</listitem>
-	      <listitem>17.172.IN-ADDR.ARPA</listitem>
-	      <listitem>18.172.IN-ADDR.ARPA</listitem>
-	      <listitem>19.172.IN-ADDR.ARPA</listitem>
-	      <listitem>20.172.IN-ADDR.ARPA</listitem>
-	      <listitem>21.172.IN-ADDR.ARPA</listitem>
-	      <listitem>22.172.IN-ADDR.ARPA</listitem>
-	      <listitem>23.172.IN-ADDR.ARPA</listitem>
-	      <listitem>24.172.IN-ADDR.ARPA</listitem>
-	      <listitem>25.172.IN-ADDR.ARPA</listitem>
-	      <listitem>26.172.IN-ADDR.ARPA</listitem>
-	      <listitem>27.172.IN-ADDR.ARPA</listitem>
-	      <listitem>28.172.IN-ADDR.ARPA</listitem>
-	      <listitem>29.172.IN-ADDR.ARPA</listitem>
-	      <listitem>30.172.IN-ADDR.ARPA</listitem>
-	      <listitem>31.172.IN-ADDR.ARPA</listitem>
-	      <listitem>168.192.IN-ADDR.ARPA</listitem>
-	      <listitem>2.0.192.IN-ADDR.ARPA</listitem>
-	      <listitem>0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA</listitem>
-	      <listitem>1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA</listitem>
-	      <listitem>D.F.IP6.ARPA</listitem>
-	      <listitem>8.E.F.IP6.ARPA</listitem>
-	      <listitem>9.E.F.IP6.ARPA</listitem>
-	      <listitem>A.E.F.IP6.ARPA</listitem>
-	      <listitem>B.E.F.IP6.ARPA</listitem>
-	    </itemizedlist>
-	  </para>
-	  <para>
-	    Empty zones are settable at the view level and only apply to
-	    views of class IN.  Disabled empty zones are only inherited
-	    from options if there are no disabled empty zones specified
-	    at the view level.  To override the options list of disabled
-	    zones, you can disable the root zone at the view level, for example:
-<programlisting>
-	    disable-empty-zone ".";
-</programlisting>
-	  </para>
-	  <para>
-	    If you are using the address ranges covered here, you should
-	    already have reverse zones covering the addresses you use.
-	    In practice this appears to not be the case with many queries
-	    being made to the infrastructure servers for names in these
-	    spaces.  So many in fact that sacrificial servers were needed
-	    to be deployed to channel the query load away from the
-	    infrastructure servers.
-	  </para>
-	  <note>
-	    The real parent servers for these zones should disable all
-	    empty zone under the parent zone they serve.  For the real
-	    root servers, this is all built in empty zones.  This will
-	    enable them to return referrals to deeper in the tree.
-	  </note>
-          <variablelist>
-	    <varlistentry>
-	      <term><command>empty-server</command></term>
-	      <listitem>
-	        <para>
-		  Specify what server name will appear in the returned
-		  SOA record for empty zones.  If none is specified, then
-		  the zone's name will be used.
-	        </para>
-	       </listitem>
-	    </varlistentry>
-	      
-	    <varlistentry>
-	      <term><command>empty-contact</command></term>
-	      <listitem>
-	        <para>
-		  Specify what contact name will appear in the returned
-		  SOA record for empty zones.  If none is specified, then
-		  "." will be used.
-	        </para>
-	      </listitem>
-	    </varlistentry>
-  
-	    <varlistentry>
-	      <term><command>empty-zones-enable</command></term>
-	      <listitem>
-	        <para>
-		  Enable or disable all empty zones.  By default they
-		  are enabled.
-	        </para>
-	      </listitem>
-	    </varlistentry>
-  
-	    <varlistentry>
-	    <term><command>disable-empty-zone</command></term>
-	      <listitem>
-	        <para>
-		  Disable individual empty zones.  By default none are
-		  disabled.  This option can be specified multiple times.
-	        </para>
-	      </listitem>
-	    </varlistentry>
-          </variablelist>
-        </sect3>
-  
-        <sect3 id="statsfile">
-          <title>The Statistics File</title>
-
-          <para>
-            The statistics file generated by <acronym>BIND</acronym> 9
-            is similar, but not identical, to that
-            generated by <acronym>BIND</acronym> 8.
-          </para>
-          <para>
-            The statistics dump begins with a line, like:
-	  </para>
-          <para>
-	    <command>+++ Statistics Dump +++ (973798949)</command>
-	  </para>
-	  <para>
-	    The number in parentheses is a standard
-            Unix-style timestamp, measured as seconds since January 1, 1970.
-            Following
-            that line are a series of lines containing a counter type, the
-            value of the
-            counter, optionally a zone name, and optionally a view name.
-            The lines without view and zone listed are global statistics for
-            the entire server.
-            Lines with a zone and view name for the given view and zone (the
-            view name is
-            omitted for the default view).
-	  </para>
-	  <para>
-	    The statistics dump ends with the line where the
-            number is identical to the number in the beginning line; for example:
-          </para>
-          <para>
-	    <command>--- Statistics Dump --- (973798949)</command>
-          </para>
-          <para>
-            The following statistics counters are maintained:
-          </para>
-          <informaltable colsep="0" rowsep="0">
-            <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="4Level-table">
-              <colspec colname="1" colnum="1" colsep="0" colwidth="1.150in"/>
-              <colspec colname="2" colnum="2" colsep="0" colwidth="3.350in"/>
-              <tbody>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para><command>success</command></para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      The number of
-                      successful queries made to the server or zone.  A
-                      successful query
-                      is defined as query which returns a NOERROR response
-                      with at least
-                      one answer RR.
-                    </para>
-                  </entry>
-                </row>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para><command>referral</command></para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      The number of queries which resulted
-                      in referral responses.
-                    </para>
-                  </entry>
-                </row>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para><command>nxrrset</command></para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      The number of queries which resulted in
-                      NOERROR responses with no data.
-                    </para>
-                  </entry>
-                </row>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para><command>nxdomain</command></para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      The number
-                      of queries which resulted in NXDOMAIN responses.
-                    </para>
-                  </entry>
-                </row>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para><command>failure</command></para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      The number of queries which resulted in a
-                      failure response other than those above.
-                    </para>
-                  </entry>
-                </row>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para><command>recursion</command></para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      The number of queries which caused the server
-                      to perform recursion in order to find the final answer.
-                    </para>
-                  </entry>
-                </row>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para><command>duplicate</command></para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      The number of queries which the server attempted to
-		      recurse but discover a existing query with the same
-		      IP address, port, query id, name, type and class
-		      already being processed.
-                    </para>
-                  </entry>
-                </row>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para><command>dropped</command></para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-		      The number of queries for which the server
-		      discovered a excessive number of existing
-		      recursive queries for the same name, type and
-		      class and were subsequently dropped.
-		    </para>
-		  </entry>
-		</row>
-              </tbody>
-            </tgroup>
-          </informaltable>
-
-          <para>
-            Each query received by the server will cause exactly one of
-            <command>success</command>,
-            <command>referral</command>,
-            <command>nxrrset</command>,
-            <command>nxdomain</command>, or
-            <command>failure</command>
-            to be incremented, and may additionally cause the
-            <command>recursion</command> counter to be
-            incremented.
-          </para>
-
-        </sect3>
-
-        <sect3 id="acache">
-          <title>Additional Section Caching</title>
-
-          <para>
-            The additional section cache, also called <command>acache</command>,
-            is an internal cache to improve the response performance of BIND 9.
-            When additional section caching is enabled, BIND 9 will
-            cache an internal short-cut to the additional section content for
-            each answer RR.
-            Note that <command>acache</command> is an internal caching
-            mechanism of BIND 9, and is not related to the DNS caching
-            server function.
-          </para>
-
-          <para>
-            Additional section caching does not change the
-            response content (except the RRsets ordering of the additional
-            section, see below), but can improve the response performance
-            significantly.
-            It is particularly effective when BIND 9 acts as an authoritative
-            server for a zone that has many delegations with many glue RRs.
-          </para>
-
-          <para>
-            In order to obtain the maximum performance improvement
-            from additional section caching, setting
-            <command>additional-from-cache</command>
-            to <command>no</command> is recommended, since the current
-            implementation of <command>acache</command>
-            does not short-cut of additional section information from the
-            DNS cache data.
-          </para>
-
-          <para>
-            One obvious disadvantage of <command>acache</command> is
-            that it requires much more
-            memory for the internal cached data.
-            Thus, if the response performance does not matter and memory
-            consumption is much more critical, the
-            <command>acache</command> mechanism can be
-            disabled by setting <command>acache-enable</command> to
-            <command>no</command>.
-            It is also possible to specify the upper limit of memory
-            consumption
-            for acache by using <command>max-acache-size</command>.
-          </para>
-
-          <para>
-            Additional section caching also has a minor effect on the
-            RRset ordering in the additional section.
-            Without <command>acache</command>,
-            <command>cyclic</command> order is effective for the additional
-            section as well as the answer and authority sections.
-            However, additional section caching fixes the ordering when it
-            first caches an RRset for the additional section, and the same
-            ordering will be kept in succeeding responses, regardless of the
-            setting of <command>rrset-order</command>.
-            The effect of this should be minor, however, since an
-            RRset in the additional section
-            typically only contains a small number of RRs (and in many cases
-            it only contains a single RR), in which case the
-            ordering does not matter much.
-          </para>
-
-          <para>
-            The following is a summary of options related to
-            <command>acache</command>.
-          </para>
-
-          <variablelist>
-
-            <varlistentry>
-              <term><command>acache-enable</command></term>
-              <listitem>
-                <para>
-                  If <command>yes</command>, additional section caching is
-		  enabled.  The default value is <command>no</command>.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>acache-cleaning-interval</command></term>
-              <listitem>
-                <para>
-                  The server will remove stale cache entries, based on an LRU
-                  based
-                  algorithm, every <command>acache-cleaning-interval</command> minutes.
-                  The default is 60 minutes.
-                  If set to 0, no periodic cleaning will occur.
-                </para>
-              </listitem>
-            </varlistentry>
-
-            <varlistentry>
-              <term><command>max-acache-size</command></term>
-              <listitem>
-                <para>
-                  The maximum amount of memory in bytes to use for the server's acache.
-                  When the amount of data in the acache reaches this limit,
-                  the server
-                  will clean more aggressively so that the limit is not
-                  exceeded.
-                  In a server with multiple views, the limit applies
-                  separately to the
-                  acache of each view.
-                  The default is <literal>unlimited</literal>,
-                  meaning that
-                  entries are purged from the acache only at the
-                  periodic cleaning time.
-                </para>
-              </listitem>
-            </varlistentry>
-
-          </variablelist>
-
-        </sect3>
-
-      </sect2>
-
-      <sect2 id="server_statement_grammar">
-        <title><command>server</command> Statement Grammar</title>
-
-<programlisting>server <replaceable>ip_addr[/prefixlen]</replaceable> {
-    <optional> bogus <replaceable>yes_or_no</replaceable> ; </optional>
-    <optional> provide-ixfr <replaceable>yes_or_no</replaceable> ; </optional>
-    <optional> request-ixfr <replaceable>yes_or_no</replaceable> ; </optional>
-    <optional> edns <replaceable>yes_or_no</replaceable> ; </optional>
-    <optional> edns-udp-size <replaceable>number</replaceable> ; </optional>
-    <optional> max-udp-size <replaceable>number</replaceable> ; </optional>
-    <optional> transfers <replaceable>number</replaceable> ; </optional>
-    <optional> transfer-format <replaceable>( one-answer | many-answers )</replaceable> ; ]</optional>
-    <optional> keys <replaceable>{ string ; <optional> string ; <optional>...</optional></optional> }</replaceable> ; </optional>
-    <optional> transfer-source (<replaceable>ip4_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
-    <optional> transfer-source-v6 (<replaceable>ip6_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
-    <optional> notify-source (<replaceable>ip4_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
-    <optional> notify-source-v6 (<replaceable>ip6_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
-    <optional> query-source <optional> address ( <replaceable>ip_addr</replaceable> | <replaceable>*</replaceable> ) </optional> <optional> port ( <replaceable>ip_port</replaceable> | <replaceable>*</replaceable> ) </optional>; </optional>
-    <optional> query-source-v6 <optional> address ( <replaceable>ip_addr</replaceable> | <replaceable>*</replaceable> ) </optional> <optional> port ( <replaceable>ip_port</replaceable> | <replaceable>*</replaceable> ) </optional>; </optional>
-};
-</programlisting>
-
-        </sect2>
-
-        <sect2 id="server_statement_definition_and_usage">
-          <title><command>server</command> Statement Definition and
-            Usage</title>
-
-          <para>
-            The <command>server</command> statement defines
-            characteristics
-            to be associated with a remote name server.  If a prefix length is
-            specified, then a range of servers is covered.  Only the most
-            specific
-            server clause applies regardless of the order in
-            <filename>named.conf</filename>.
-          </para>
-
-          <para>
-            The <command>server</command> statement can occur at
-            the top level of the
-            configuration file or inside a <command>view</command>
-            statement.
-            If a <command>view</command> statement contains
-            one or more <command>server</command> statements, only
-            those
-            apply to the view and any top-level ones are ignored.
-            If a view contains no <command>server</command>
-            statements,
-            any top-level <command>server</command> statements are
-            used as
-            defaults.
-          </para>
-
-          <para>
-            If you discover that a remote server is giving out bad data,
-            marking it as bogus will prevent further queries to it. The
-            default
-            value of <command>bogus</command> is <command>no</command>.
-          </para>
-          <para>
-            The <command>provide-ixfr</command> clause determines
-            whether
-            the local server, acting as master, will respond with an
-            incremental
-            zone transfer when the given remote server, a slave, requests it.
-            If set to <command>yes</command>, incremental transfer
-            will be provided
-            whenever possible. If set to <command>no</command>,
-            all transfers
-            to the remote server will be non-incremental. If not set, the
-            value
-            of the <command>provide-ixfr</command> option in the
-            view or
-            global options block is used as a default.
-          </para>
-
-          <para>
-            The <command>request-ixfr</command> clause determines
-            whether
-            the local server, acting as a slave, will request incremental zone
-            transfers from the given remote server, a master. If not set, the
-            value of the <command>request-ixfr</command> option in
-            the view or
-            global options block is used as a default.
-          </para>
-
-          <para>
-            IXFR requests to servers that do not support IXFR will
-            automatically
-            fall back to AXFR.  Therefore, there is no need to manually list
-            which servers support IXFR and which ones do not; the global
-            default
-            of <command>yes</command> should always work.
-            The purpose of the <command>provide-ixfr</command> and
-            <command>request-ixfr</command> clauses is
-            to make it possible to disable the use of IXFR even when both
-            master
-            and slave claim to support it, for example if one of the servers
-            is buggy and crashes or corrupts data when IXFR is used.
-          </para>
-
-          <para>
-            The <command>edns</command> clause determines whether
-            the local server will attempt to use EDNS when communicating
-	    with the remote server.  The default is <command>yes</command>.
-          </para>
-
-          <para>
-            The <command>edns-udp-size</command> option sets the EDNS UDP size
-	    that is advertised by named when querying the remote server.
-	    Valid values are 512 to 4096 bytes (values outside this range will be
-	    silently adjusted).  This option is useful when you wish to
-	    advertises a different value to this server than the value you
-	    advertise globally, for example, when there is a firewall at the
-	    remote site that is blocking large replies.
-          </para>
-
-          <para>
-	    The <command>max-udp-size</command> option sets the
-	    maximum EDNS UDP message size named will send.  Valid
-	    values are 512 to 4096 bytes (values outside this range will
-	    be silently adjusted).  This option is useful when you
-	    know that there is a firewall that is blocking large
-	    replies from named.
-	  </para>
-
-          <para>
-            The server supports two zone transfer methods. The first, <command>one-answer</command>,
-            uses one DNS message per resource record transferred. <command>many-answers</command> packs
-            as many resource records as possible into a message. <command>many-answers</command> is
-            more efficient, but is only known to be understood by <acronym>BIND</acronym> 9, <acronym>BIND</acronym>
-            8.x, and patched versions of <acronym>BIND</acronym>
-            4.9.5. You can specify which method
-            to use for a server with the <command>transfer-format</command> option.
-            If <command>transfer-format</command> is not
-            specified, the <command>transfer-format</command>
-            specified
-            by the <command>options</command> statement will be
-            used.
-          </para>
-
-          <para><command>transfers</command>
-	    is used to limit the number of concurrent inbound zone
-            transfers from the specified server. If no
-            <command>transfers</command> clause is specified, the
-            limit is set according to the
-            <command>transfers-per-ns</command> option.
-          </para>
-
-          <para>
-            The <command>keys</command> clause identifies a
-            <command>key_id</command> defined by the <command>key</command> statement,
-            to be used for transaction security (TSIG, <xref linkend="tsig"/>)
-            when talking to the remote server.
-            When a request is sent to the remote server, a request signature
-            will be generated using the key specified here and appended to the
-            message. A request originating from the remote server is not
-            required
-            to be signed by this key.
-          </para>
-
-          <para>
-            Although the grammar of the <command>keys</command>
-            clause
-            allows for multiple keys, only a single key per server is
-            currently
-            supported.
-          </para>
-
-          <para>
-            The <command>transfer-source</command> and
-            <command>transfer-source-v6</command> clauses specify
-            the IPv4 and IPv6 source
-            address to be used for zone transfer with the remote server,
-            respectively.
-            For an IPv4 remote server, only <command>transfer-source</command> can
-            be specified.
-            Similarly, for an IPv6 remote server, only
-            <command>transfer-source-v6</command> can be
-            specified.
-            For more details, see the description of
-            <command>transfer-source</command> and
-            <command>transfer-source-v6</command> in
-            <xref linkend="zone_transfers"/>.
-          </para>
-
-	  <para>
-	    The <command>notify-source</command> and
-	    <command>notify-source-v6</command> clauses specify the
-	    IPv4 and IPv6 source address to be used for notify
-	    messages sent to remote servers, respectively.  For an
-	    IPv4 remote server, only <command>notify-source</command>
-	    can be specified.  Similarly, for an IPv6 remote server,
-	    only <command>notify-source-v6</command> can be specified.
-	  </para>
-
-	  <para>
-	    The <command>query-source</command> and
-	    <command>query-source-v6</command> clauses specify the
-	    IPv4 and IPv6 source address to be used for queries
-	    sent to remote servers, respectively.  For an IPv4
-	    remote server, only <command>query-source</command> can
-	    be specified.  Similarly, for an IPv6 remote server,
-	    only <command>query-source-v6</command> can be specified.
-	  </para>
-
-        </sect2>
-
-        <sect2>
-          <title><command>trusted-keys</command> Statement Grammar</title>
-
-<programlisting>trusted-keys {
-    <replaceable>string</replaceable> <replaceable>number</replaceable> <replaceable>number</replaceable> <replaceable>number</replaceable> <replaceable>string</replaceable> ;
-    <optional> <replaceable>string</replaceable> <replaceable>number</replaceable> <replaceable>number</replaceable> <replaceable>number</replaceable> <replaceable>string</replaceable> ; <optional>...</optional></optional>
-};
-</programlisting>
-
-        </sect2>
-	<sect2>
-	  <title><command>trusted-keys</command> Statement Definition
-	    and Usage</title>
-	  <para>
-	    The <command>trusted-keys</command> statement defines
-	    DNSSEC security roots. DNSSEC is described in <xref
-	    linkend="DNSSEC"/>. A security root is defined when the
-	    public key for a non-authoritative zone is known, but
-	    cannot be securely obtained through DNS, either because
-	    it is the DNS root zone or because its parent zone is
-	    unsigned.  Once a key has been configured as a trusted
-	    key, it is treated as if it had been validated and
-	    proven secure. The resolver attempts DNSSEC validation
-	    on all DNS data in subdomains of a security root.
-	  </para>
-	  <para>
-	    All keys (and corresponding zones) listed in
-	    <command>trusted-keys</command> are deemed to exist regardless
-	    of what parent zones say.  Similarly for all keys listed in
-	    <command>trusted-keys</command> only those keys are
-	    used to validate the DNSKEY RRset.  The parent's DS RRset
-	    will not be used.
-	  </para>
-	  <para>
-	    The <command>trusted-keys</command> statement can contain
-	    multiple key entries, each consisting of the key's
-	    domain name, flags, protocol, algorithm, and the Base-64
-	    representation of the key data.
-	  </para>
-	</sect2>
-
-        <sect2 id="view_statement_grammar">
-          <title><command>view</command> Statement Grammar</title>
-
-<programlisting>view <replaceable>view_name</replaceable>
-      <optional><replaceable>class</replaceable></optional> {
-      match-clients { <replaceable>address_match_list</replaceable> };
-      match-destinations { <replaceable>address_match_list</replaceable> };
-      match-recursive-only <replaceable>yes_or_no</replaceable> ;
-      <optional> <replaceable>view_option</replaceable>; ...</optional>
-      <optional> <replaceable>zone_statement</replaceable>; ...</optional>
-};
-</programlisting>
-
-        </sect2>
-        <sect2>
-          <title><command>view</command> Statement Definition and Usage</title>
-
-          <para>
-            The <command>view</command> statement is a powerful
-            feature
-            of <acronym>BIND</acronym> 9 that lets a name server
-            answer a DNS query differently
-            depending on who is asking. It is particularly useful for
-            implementing
-            split DNS setups without having to run multiple servers.
-          </para>
-
-          <para>
-            Each <command>view</command> statement defines a view
-            of the
-            DNS namespace that will be seen by a subset of clients.  A client
-            matches
-            a view if its source IP address matches the
-            <varname>address_match_list</varname> of the view's
-            <command>match-clients</command> clause and its
-            destination IP address matches
-            the <varname>address_match_list</varname> of the
-            view's
-            <command>match-destinations</command> clause.  If not
-            specified, both
-            <command>match-clients</command> and <command>match-destinations</command>
-            default to matching all addresses.  In addition to checking IP
-            addresses
-            <command>match-clients</command> and <command>match-destinations</command>
-            can also take <command>keys</command> which provide an
-            mechanism for the
-            client to select the view.  A view can also be specified
-            as <command>match-recursive-only</command>, which
-            means that only recursive
-            requests from matching clients will match that view.
-            The order of the <command>view</command> statements is
-            significant &mdash;
-            a client request will be resolved in the context of the first
-            <command>view</command> that it matches.
-          </para>
-
-          <para>
-            Zones defined within a <command>view</command>
-            statement will
-            be only be accessible to clients that match the <command>view</command>.
-            By defining a zone of the same name in multiple views, different
-            zone data can be given to different clients, for example,
-            "internal"
-            and "external" clients in a split DNS setup.
-          </para>
-
-          <para>
-            Many of the options given in the <command>options</command> statement
-            can also be used within a <command>view</command>
-            statement, and then
-            apply only when resolving queries with that view.  When no
-            view-specific
-            value is given, the value in the <command>options</command> statement
-            is used as a default.  Also, zone options can have default values
-            specified
-            in the <command>view</command> statement; these
-            view-specific defaults
-            take precedence over those in the <command>options</command> statement.
-          </para>
-
-          <para>
-            Views are class specific.  If no class is given, class IN
-            is assumed.  Note that all non-IN views must contain a hint zone,
-            since only the IN class has compiled-in default hints.
-          </para>
-
-          <para>
-            If there are no <command>view</command> statements in
-            the config
-            file, a default view that matches any client is automatically
-            created
-            in class IN. Any <command>zone</command> statements
-            specified on
-            the top level of the configuration file are considered to be part
-            of
-            this default view, and the <command>options</command>
-            statement will
-            apply to the default view. If any explicit <command>view</command>
-            statements are present, all <command>zone</command>
-            statements must
-            occur inside <command>view</command> statements.
-          </para>
-
-          <para>
-            Here is an example of a typical split DNS setup implemented
-            using <command>view</command> statements:
-          </para>
-
-<programlisting>view "internal" {
-      // This should match our internal networks.
-      match-clients { 10.0.0.0/8; };
-
-      // Provide recursive service to internal clients only.
-      recursion yes;
-
-      // Provide a complete view of the example.com zone
-      // including addresses of internal hosts.
-      zone "example.com" {
-            type master;
-            file "example-internal.db";
-      };
-};
-
-view "external" {
-      // Match all clients not matched by the previous view.
-      match-clients { any; };
-
-      // Refuse recursive service to external clients.
-      recursion no;
-
-      // Provide a restricted view of the example.com zone
-      // containing only publicly accessible hosts.
-      zone "example.com" {
-           type master;
-           file "example-external.db";
-      };
-};
-</programlisting>
-
-        </sect2>
-        <sect2 id="zone_statement_grammar">
-          <title><command>zone</command>
-            Statement Grammar</title>
-
-<programlisting>zone <replaceable>zone_name</replaceable> <optional><replaceable>class</replaceable></optional> {
-    type master;
-    <optional> allow-query { <replaceable>address_match_list</replaceable> }; </optional>
-    <optional> allow-transfer { <replaceable>address_match_list</replaceable> }; </optional>
-    <optional> allow-update { <replaceable>address_match_list</replaceable> }; </optional>
-    <optional> update-policy { <replaceable>update_policy_rule</replaceable> <optional>...</optional> }; </optional>
-    <optional> also-notify { <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; <optional> <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; ... </optional> }; </optional>
-    <optional> check-names (<constant>warn</constant>|<constant>fail</constant>|<constant>ignore</constant>) ; </optional>
-    <optional> check-mx (<constant>warn</constant>|<constant>fail</constant>|<constant>ignore</constant>) ; </optional>
-    <optional> check-wildcard <replaceable>yes_or_no</replaceable>; </optional>
-    <optional> check-integrity <replaceable>yes_or_no</replaceable> ; </optional>
-    <optional> dialup <replaceable>dialup_option</replaceable> ; </optional>
-    <optional> file <replaceable>string</replaceable> ; </optional>
-    <optional> masterfile-format (<constant>text</constant>|<constant>raw</constant>) ; </optional>
-    <optional> journal <replaceable>string</replaceable> ; </optional>
-    <optional> forward (<constant>only</constant>|<constant>first</constant>) ; </optional>
-    <optional> forwarders { <optional> <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; ... </optional> }; </optional>
-    <optional> ixfr-base <replaceable>string</replaceable> ; </optional>
-    <optional> ixfr-tmp-file <replaceable>string</replaceable> ; </optional>
-    <optional> maintain-ixfr-base <replaceable>yes_or_no</replaceable> ; </optional>
-    <optional> max-ixfr-log-size <replaceable>number</replaceable> ; </optional>
-    <optional> max-transfer-idle-out <replaceable>number</replaceable> ; </optional>
-    <optional> max-transfer-time-out <replaceable>number</replaceable> ; </optional>
-    <optional> notify <replaceable>yes_or_no</replaceable> | <replaceable>explicit</replaceable> | <replaceable>master-only</replaceable> ; </optional>
-    <optional> notify-delay <replaceable>seconds</replaceable> ; </optional>
-    <optional> pubkey <replaceable>number</replaceable> <replaceable>number</replaceable> <replaceable>number</replaceable> <replaceable>string</replaceable> ; </optional>
-    <optional> notify-source (<replaceable>ip4_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
-    <optional> notify-source-v6 (<replaceable>ip6_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
-    <optional> zone-statistics <replaceable>yes_or_no</replaceable> ; </optional>
-    <optional> sig-validity-interval <replaceable>number</replaceable> ; </optional>
-    <optional> database <replaceable>string</replaceable> ; </optional>
-    <optional> min-refresh-time <replaceable>number</replaceable> ; </optional>
-    <optional> max-refresh-time <replaceable>number</replaceable> ; </optional>
-    <optional> min-retry-time <replaceable>number</replaceable> ; </optional>
-    <optional> max-retry-time <replaceable>number</replaceable> ; </optional>
-    <optional> key-directory <replaceable>path_name</replaceable>; </optional>
-    <optional> zero-no-soa-ttl <replaceable>yes_or_no</replaceable> ; </optional>
-};
-
-zone <replaceable>zone_name</replaceable> <optional><replaceable>class</replaceable></optional> {
-    type slave;
-    <optional> allow-notify { <replaceable>address_match_list</replaceable> }; </optional>
-    <optional> allow-query { <replaceable>address_match_list</replaceable> }; </optional>
-    <optional> allow-transfer { <replaceable>address_match_list</replaceable> }; </optional>
-    <optional> allow-update-forwarding { <replaceable>address_match_list</replaceable> }; </optional>
-    <optional> update-check-ksk <replaceable>yes_or_no</replaceable>; </optional>
-    <optional> also-notify { <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; <optional> <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; ... </optional> }; </optional>
-    <optional> check-names (<constant>warn</constant>|<constant>fail</constant>|<constant>ignore</constant>) ; </optional>
-    <optional> dialup <replaceable>dialup_option</replaceable> ; </optional>
-    <optional> file <replaceable>string</replaceable> ; </optional>
-    <optional> masterfile-format (<constant>text</constant>|<constant>raw</constant>) ; </optional>
-    <optional> journal <replaceable>string</replaceable> ; </optional>
-    <optional> forward (<constant>only</constant>|<constant>first</constant>) ; </optional>
-    <optional> forwarders { <optional> <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; ... </optional> }; </optional>
-    <optional> ixfr-base <replaceable>string</replaceable> ; </optional>
-    <optional> ixfr-tmp-file <replaceable>string</replaceable> ; </optional>
-    <optional> maintain-ixfr-base <replaceable>yes_or_no</replaceable> ; </optional>
-    <optional> masters <optional>port <replaceable>ip_port</replaceable></optional> { ( <replaceable>masters_list</replaceable> | <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> <optional>key <replaceable>key</replaceable></optional> ) ; <optional>...</optional> }; </optional>
-    <optional> max-ixfr-log-size <replaceable>number</replaceable> ; </optional>
-    <optional> max-transfer-idle-in <replaceable>number</replaceable> ; </optional>
-    <optional> max-transfer-idle-out <replaceable>number</replaceable> ; </optional>
-    <optional> max-transfer-time-in <replaceable>number</replaceable> ; </optional>
-    <optional> max-transfer-time-out <replaceable>number</replaceable> ; </optional>
-    <optional> notify <replaceable>yes_or_no</replaceable> | <replaceable>explicit</replaceable> | <replaceable>master-only</replaceable> ; </optional>
-    <optional> pubkey <replaceable>number</replaceable> <replaceable>number</replaceable> <replaceable>number</replaceable> <replaceable>string</replaceable> ; </optional>
-    <optional> transfer-source (<replaceable>ip4_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
-    <optional> transfer-source-v6 (<replaceable>ip6_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
-    <optional> alt-transfer-source (<replaceable>ip4_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
-    <optional> alt-transfer-source-v6 (<replaceable>ip6_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
-    <optional> use-alt-transfer-source <replaceable>yes_or_no</replaceable>; </optional>
-    <optional> notify-source (<replaceable>ip4_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
-    <optional> notify-source-v6 (<replaceable>ip6_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
-    <optional> zone-statistics <replaceable>yes_or_no</replaceable> ; </optional>
-    <optional> database <replaceable>string</replaceable> ; </optional>
-    <optional> min-refresh-time <replaceable>number</replaceable> ; </optional>
-    <optional> max-refresh-time <replaceable>number</replaceable> ; </optional>
-    <optional> min-retry-time <replaceable>number</replaceable> ; </optional>
-    <optional> max-retry-time <replaceable>number</replaceable> ; </optional>
-    <optional> multi-master <replaceable>yes_or_no</replaceable> ; </optional>
-    <optional> zero-no-soa-ttl <replaceable>yes_or_no</replaceable> ; </optional>
-};
-
-zone <replaceable>zone_name</replaceable> <optional><replaceable>class</replaceable></optional> {
-    type hint;
-    file <replaceable>string</replaceable> ;
-    <optional> delegation-only <replaceable>yes_or_no</replaceable> ; </optional>
-    <optional> check-names (<constant>warn</constant>|<constant>fail</constant>|<constant>ignore</constant>) ; // Not Implemented. </optional>
-};
-
-zone <replaceable>zone_name</replaceable> <optional><replaceable>class</replaceable></optional> {
-    type stub;
-    <optional> allow-query { <replaceable>address_match_list</replaceable> }; </optional>
-    <optional> check-names (<constant>warn</constant>|<constant>fail</constant>|<constant>ignore</constant>) ; </optional>
-    <optional> dialup <replaceable>dialup_option</replaceable> ; </optional>
-    <optional> delegation-only <replaceable>yes_or_no</replaceable> ; </optional>
-    <optional> file <replaceable>string</replaceable> ; </optional>
-    <optional> masterfile-format (<constant>text</constant>|<constant>raw</constant>) ; </optional>
-    <optional> forward (<constant>only</constant>|<constant>first</constant>) ; </optional>
-    <optional> forwarders { <optional> <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; ... </optional> }; </optional>
-    <optional> masters <optional>port <replaceable>ip_port</replaceable></optional> { ( <replaceable>masters_list</replaceable> | <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> <optional>key <replaceable>key</replaceable></optional> ) ; <optional>...</optional> }; </optional>
-    <optional> max-transfer-idle-in <replaceable>number</replaceable> ; </optional>
-    <optional> max-transfer-time-in <replaceable>number</replaceable> ; </optional>
-    <optional> pubkey <replaceable>number</replaceable> <replaceable>number</replaceable> <replaceable>number</replaceable> <replaceable>string</replaceable> ; </optional>
-    <optional> transfer-source (<replaceable>ip4_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
-    <optional> transfer-source-v6 (<replaceable>ip6_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
-    <optional> alt-transfer-source (<replaceable>ip4_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
-    <optional> alt-transfer-source-v6 (<replaceable>ip6_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
-    <optional> use-alt-transfer-source <replaceable>yes_or_no</replaceable>; </optional>
-    <optional> zone-statistics <replaceable>yes_or_no</replaceable> ; </optional>
-    <optional> database <replaceable>string</replaceable> ; </optional>
-    <optional> min-refresh-time <replaceable>number</replaceable> ; </optional>
-    <optional> max-refresh-time <replaceable>number</replaceable> ; </optional>
-    <optional> min-retry-time <replaceable>number</replaceable> ; </optional>
-    <optional> max-retry-time <replaceable>number</replaceable> ; </optional>
-    <optional> multi-master <replaceable>yes_or_no</replaceable> ; </optional>
-};
-
-zone <replaceable>zone_name</replaceable> <optional><replaceable>class</replaceable></optional> {
-    type forward;
-    <optional> forward (<constant>only</constant>|<constant>first</constant>) ; </optional>
-    <optional> forwarders { <optional> <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; ... </optional> }; </optional>
-    <optional> delegation-only <replaceable>yes_or_no</replaceable> ; </optional>
-};
-
-zone <replaceable>zone_name</replaceable> <optional><replaceable>class</replaceable></optional> {
-    type delegation-only;
-};
-
-</programlisting>
-
-        </sect2>
-        <sect2>
-          <title><command>zone</command> Statement Definition and Usage</title>
-          <sect3>
-            <title>Zone Types</title>
-            <informaltable colsep="0" rowsep="0">
-              <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="3Level-table">
-                <!--colspec colname="1" colnum="1" colsep="0" colwidth="1.108in"/-->
-                <!--colspec colname="2" colnum="2" colsep="0" colwidth="4.017in"/-->
-		<colspec colname="1" colnum="1" colsep="0"/>
-                <colspec colname="2" colnum="2" colsep="0" colwidth="4.017in"/>
-                <tbody>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        <varname>master</varname>
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        The server has a master copy of the data
-                        for the zone and will be able to provide authoritative
-                        answers for
-                        it.
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        <varname>slave</varname>
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        A slave zone is a replica of a master
-                        zone. The <command>masters</command> list
-                        specifies one or more IP addresses
-                        of master servers that the slave contacts to update
-                        its copy of the zone.
-                        Masters list elements can also be names of other
-                        masters lists.
-                        By default, transfers are made from port 53 on the
-                        servers; this can
-                        be changed for all servers by specifying a port number
-                        before the
-                        list of IP addresses, or on a per-server basis after
-                        the IP address.
-                        Authentication to the master can also be done with
-                        per-server TSIG keys.
-                        If a file is specified, then the
-                        replica will be written to this file whenever the zone
-                        is changed,
-                        and reloaded from this file on a server restart. Use
-                        of a file is
-                        recommended, since it often speeds server startup and
-                        eliminates
-                        a needless waste of bandwidth. Note that for large
-                        numbers (in the
-                        tens or hundreds of thousands) of zones per server, it
-                        is best to
-                        use a two-level naming scheme for zone filenames. For
-                        example,
-                        a slave server for the zone <literal>example.com</literal> might place
-                        the zone contents into a file called
-                        <filename>ex/example.com</filename> where <filename>ex/</filename> is
-                        just the first two letters of the zone name. (Most
-                        operating systems
-                        behave very slowly if you put 100 000 files into
-                        a single directory.)
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        <varname>stub</varname>
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        A stub zone is similar to a slave zone,
-                        except that it replicates only the NS records of a
-                        master zone instead
-                        of the entire zone. Stub zones are not a standard part
-                        of the DNS;
-                        they are a feature specific to the <acronym>BIND</acronym> implementation.
-                      </para>
-
-                      <para>
-                        Stub zones can be used to eliminate the need for glue
-                        NS record
-                        in a parent zone at the expense of maintaining a stub
-                        zone entry and
-                        a set of name server addresses in <filename>named.conf</filename>.
-                        This usage is not recommended for new configurations,
-                        and BIND 9
-                        supports it only in a limited way.
-                        In <acronym>BIND</acronym> 4/8, zone
-                        transfers of a parent zone
-                        included the NS records from stub children of that
-                        zone. This meant
-                        that, in some cases, users could get away with
-                        configuring child stubs
-                        only in the master server for the parent zone. <acronym>BIND</acronym>
-                        9 never mixes together zone data from different zones
-                        in this
-                        way. Therefore, if a <acronym>BIND</acronym> 9 master serving a parent
-                        zone has child stub zones configured, all the slave
-                        servers for the
-                        parent zone also need to have the same child stub
-                        zones
-                        configured.
-                      </para>
-
-                      <para>
-                        Stub zones can also be used as a way of forcing the
-                        resolution
-                        of a given domain to use a particular set of
-                        authoritative servers.
-                        For example, the caching name servers on a private
-                        network using
-                        RFC1918 addressing may be configured with stub zones
-                        for
-                        <literal>10.in-addr.arpa</literal>
-                        to use a set of internal name servers as the
-                        authoritative
-                        servers for that domain.
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        <varname>forward</varname>
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        A "forward zone" is a way to configure
-                        forwarding on a per-domain basis.  A <command>zone</command> statement
-                        of type <command>forward</command> can
-                        contain a <command>forward</command>
-                        and/or <command>forwarders</command>
-                        statement,
-                        which will apply to queries within the domain given by
-                        the zone
-                        name. If no <command>forwarders</command>
-                        statement is present or
-                        an empty list for <command>forwarders</command> is given, then no
-                        forwarding will be done for the domain, canceling the
-                        effects of
-                        any forwarders in the <command>options</command> statement. Thus
-                        if you want to use this type of zone to change the
-                        behavior of the
-                        global <command>forward</command> option
-                        (that is, "forward first"
-                        to, then "forward only", or vice versa, but want to
-                        use the same
-                        servers as set globally) you need to re-specify the
-                        global forwarders.
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        <varname>hint</varname>
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        The initial set of root name servers is
-                        specified using a "hint zone". When the server starts
-                        up, it uses
-                        the root hints to find a root name server and get the
-                        most recent
-                        list of root name servers. If no hint zone is
-                        specified for class
-                        IN, the server uses a compiled-in default set of root
-                        servers hints.
-                        Classes other than IN have no built-in defaults hints.
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        <varname>delegation-only</varname>
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        This is used to enforce the delegation-only
-                        status of infrastructure zones (e.g. COM, NET, ORG).
-                        Any answer that
-                        is received without an explicit or implicit delegation
-                        in the authority
-                        section will be treated as NXDOMAIN.  This does not
-                        apply to the zone
-                        apex.  This should not be applied to leaf zones.
-                      </para>
-                      <para>
-                        <varname>delegation-only</varname> has no
-                        effect on answers received
-                        from forwarders.
-                      </para>
-                    </entry>
-                  </row>
-                </tbody>
-              </tgroup>
-            </informaltable>
-          </sect3>
-
-          <sect3>
-            <title>Class</title>
-            <para>
-              The zone's name may optionally be followed by a class. If
-              a class is not specified, class <literal>IN</literal> (for <varname>Internet</varname>),
-              is assumed. This is correct for the vast majority of cases.
-            </para>
-            <para>
-              The <literal>hesiod</literal> class is
-              named for an information service from MIT's Project Athena. It
-              is
-              used to share information about various systems databases, such
-              as users, groups, printers and so on. The keyword
-              <literal>HS</literal> is
-              a synonym for hesiod.
-            </para>
-            <para>
-              Another MIT development is Chaosnet, a LAN protocol created
-              in the mid-1970s. Zone data for it can be specified with the <literal>CHAOS</literal> class.
-            </para>
-          </sect3>
-          <sect3>
-
-            <title>Zone Options</title>
-
-            <variablelist>
-
-              <varlistentry>
-                <term><command>allow-notify</command></term>
-                <listitem>
-                  <para>
-                    See the description of
-                    <command>allow-notify</command> in <xref linkend="access_control"/>.
-                  </para>
-                </listitem>
-              </varlistentry>
-
-              <varlistentry>
-                <term><command>allow-query</command></term>
-                <listitem>
-                  <para>
-                    See the description of
-                    <command>allow-query</command> in <xref linkend="access_control"/>.
-                  </para>
-                </listitem>
-              </varlistentry>
-
-              <varlistentry>
-                <term><command>allow-transfer</command></term>
-                <listitem>
-                  <para>
-                    See the description of <command>allow-transfer</command>
-                    in <xref linkend="access_control"/>.
-                  </para>
-                </listitem>
-              </varlistentry>
-
-              <varlistentry>
-                <term><command>allow-update</command></term>
-                <listitem>
-                  <para>
-                    See the description of <command>allow-update</command>
-                    in <xref linkend="access_control"/>.
-                  </para>
-                </listitem>
-              </varlistentry>
-
-              <varlistentry>
-                <term><command>update-policy</command></term>
-                <listitem>
-                  <para>
-                    Specifies a "Simple Secure Update" policy. See
-                    <xref linkend="dynamic_update_policies"/>.
-                  </para>
-                </listitem>
-              </varlistentry>
-
-              <varlistentry>
-                <term><command>allow-update-forwarding</command></term>
-                <listitem>
-                  <para>
-                    See the description of <command>allow-update-forwarding</command>
-                    in <xref linkend="access_control"/>.
-                  </para>
-                </listitem>
-              </varlistentry>
-
-              <varlistentry>
-                <term><command>also-notify</command></term>
-                <listitem>
-                  <para>
-                    Only meaningful if <command>notify</command>
-                    is
-                    active for this zone. The set of machines that will
-                    receive a
-                    <literal>DNS NOTIFY</literal> message
-                    for this zone is made up of all the listed name servers
-                    (other than
-                    the primary master) for the zone plus any IP addresses
-                    specified
-                    with <command>also-notify</command>. A port
-                    may be specified
-                    with each <command>also-notify</command>
-                    address to send the notify
-                    messages to a port other than the default of 53.
-                    <command>also-notify</command> is not
-                    meaningful for stub zones.
-                    The default is the empty list.
-                  </para>
-                </listitem>
-              </varlistentry>
-
-              <varlistentry>
-                <term><command>check-names</command></term>
-                <listitem>
-                  <para>
-                    This option is used to restrict the character set and
-                    syntax of
-                    certain domain names in master files and/or DNS responses
-                    received from the
-                    network.  The default varies according to zone type.  For <command>master</command> zones the default is <command>fail</command>.  For <command>slave</command>
-                    zones the default is <command>warn</command>.
-                  </para>
-                </listitem>
-              </varlistentry>
-
-              <varlistentry>
-                <term><command>check-mx</command></term>
-                <listitem>
-                  <para>
-                    See the description of
-                    <command>check-mx</command> in <xref linkend="boolean_options"/>.
-                  </para>
-                </listitem>
-              </varlistentry>
-
-              <varlistentry>
-                <term><command>check-wildcard</command></term>
-                <listitem>
-                  <para>
-                    See the description of
-                    <command>check-wildcard</command> in <xref linkend="boolean_options"/>.
-                  </para>
-                </listitem>
-              </varlistentry>
-
-              <varlistentry>
-                <term><command>check-integrity</command></term>
-                <listitem>
-                  <para>
-                    See the description of
-                    <command>check-integrity</command> in <xref linkend="boolean_options"/>.
-                  </para>
-                </listitem>
-              </varlistentry>
-
-              <varlistentry>
-                <term><command>check-sibling</command></term>
-                <listitem>
-                  <para>
-                    See the description of
-                    <command>check-sibling</command> in <xref linkend="boolean_options"/>.
-                  </para>
-                </listitem>
-              </varlistentry>
-
-              <varlistentry>
-                <term><command>zero-no-soa-ttl</command></term>
-                <listitem>
-                  <para>
-                    See the description of
-                    <command>zero-no-soa-ttl</command> in <xref linkend="boolean_options"/>.
-                  </para>
-                </listitem>
-              </varlistentry>
-
-	      <varlistentry>
-	        <term><command>update-check-ksk</command></term>
-                <listitem>
-                  <para>
-                    See the description of
-                    <command>update-check-ksk</command> in <xref linkend="boolean_options"/>.
-                  </para>
-                </listitem>
-              </varlistentry>
-
-              <varlistentry>
-                <term><command>database</command></term>
-                <listitem>
-                  <para>
-                    Specify the type of database to be used for storing the
-                    zone data.  The string following the <command>database</command> keyword
-                    is interpreted as a list of whitespace-delimited words.
-                    The first word
-                    identifies the database type, and any subsequent words are
-                    passed
-                    as arguments to the database to be interpreted in a way
-                    specific
-                    to the database type.
-                  </para>
-                  <para>
-                    The default is <userinput>"rbt"</userinput>, BIND 9's
-                    native in-memory
-                    red-black-tree database.  This database does not take
-                    arguments.
-                  </para>
-                  <para>
-                    Other values are possible if additional database drivers
-                    have been linked into the server.  Some sample drivers are
-                    included
-                    with the distribution but none are linked in by default.
-                  </para>
-                </listitem>
-              </varlistentry>
-
-              <varlistentry>
-                <term><command>dialup</command></term>
-                <listitem>
-                  <para>
-                    See the description of
-                    <command>dialup</command> in <xref linkend="boolean_options"/>.
-                  </para>
-                </listitem>
-              </varlistentry>
-
-              <varlistentry>
-                <term><command>delegation-only</command></term>
-                <listitem>
-                  <para>
-                    The flag only applies to hint and stub zones.  If set
-                    to <userinput>yes</userinput>, then the zone will also be
-                    treated as if it
-                    is also a delegation-only type zone.
-                  </para>
-                </listitem>
-              </varlistentry>
-
-              <varlistentry>
-                <term><command>forward</command></term>
-                <listitem>
-                  <para>
-                    Only meaningful if the zone has a forwarders
-                    list. The <command>only</command> value causes
-                    the lookup to fail
-                    after trying the forwarders and getting no answer, while <command>first</command> would
-                    allow a normal lookup to be tried.
-                  </para>
-                </listitem>
-              </varlistentry>
-
-              <varlistentry>
-                <term><command>forwarders</command></term>
-                <listitem>
-                  <para>
-                    Used to override the list of global forwarders.
-                    If it is not specified in a zone of type <command>forward</command>,
-                    no forwarding is done for the zone and the global options are
-                    not used.
-                  </para>
-                </listitem>
-              </varlistentry>
-
-              <varlistentry>
-                <term><command>ixfr-base</command></term>
-                <listitem>
-                  <para>
-                    Was used in <acronym>BIND</acronym> 8 to
-                    specify the name
-                    of the transaction log (journal) file for dynamic update
-                    and IXFR.
-                    <acronym>BIND</acronym> 9 ignores the option
-                    and constructs the name of the journal
-                    file by appending "<filename>.jnl</filename>"
-                    to the name of the
-                    zone file.
-                  </para>
-                </listitem>
-              </varlistentry>
-
-              <varlistentry>
-                <term><command>ixfr-tmp-file</command></term>
-                <listitem>
-                  <para>
-                    Was an undocumented option in <acronym>BIND</acronym> 8.
-                    Ignored in <acronym>BIND</acronym> 9.
-                  </para>
-                </listitem>
-              </varlistentry>
-
-              <varlistentry>
-                <term><command>journal</command></term>
-                <listitem>
-                  <para>
-                    Allow the default journal's filename to be overridden.
-                    The default is the zone's filename with "<filename>.jnl</filename>" appended.
-                    This is applicable to <command>master</command> and <command>slave</command> zones.
-                  </para>
-                </listitem>
-              </varlistentry>
-
-              <varlistentry>
-                <term><command>max-transfer-time-in</command></term>
-                <listitem>
-                  <para>
-                    See the description of
-                    <command>max-transfer-time-in</command> in <xref linkend="zone_transfers"/>.
-                  </para>
-                </listitem>
-              </varlistentry>
-
-              <varlistentry>
-                <term><command>max-transfer-idle-in</command></term>
-                <listitem>
-                  <para>
-                    See the description of
-                    <command>max-transfer-idle-in</command> in <xref linkend="zone_transfers"/>.
-                  </para>
-                </listitem>
-              </varlistentry>
-
-              <varlistentry>
-                <term><command>max-transfer-time-out</command></term>
-                <listitem>
-                  <para>
-                    See the description of
-                    <command>max-transfer-time-out</command> in <xref linkend="zone_transfers"/>.
-                  </para>
-                </listitem>
-              </varlistentry>
-
-              <varlistentry>
-                <term><command>max-transfer-idle-out</command></term>
-                <listitem>
-                  <para>
-                    See the description of
-                    <command>max-transfer-idle-out</command> in <xref linkend="zone_transfers"/>.
-                  </para>
-                </listitem>
-              </varlistentry>
-
-              <varlistentry>
-                <term><command>notify</command></term>
-                <listitem>
-                  <para>
-                    See the description of
-                    <command>notify</command> in <xref linkend="boolean_options"/>.
-                  </para>
-                </listitem>
-              </varlistentry>
-
-              <varlistentry>
-                <term><command>notify-delay</command></term>
-                <listitem>
-                  <para>
-                    See the description of
-                    <command>notify-delay</command> in <xref linkend="tuning"/>.
-                  </para>
-                </listitem>
-              </varlistentry>
-
-              <varlistentry>
-                <term><command>pubkey</command></term>
-                <listitem>
-                  <para>
-                    In <acronym>BIND</acronym> 8, this option was
-                    intended for specifying
-                    a public zone key for verification of signatures in DNSSEC
-                    signed
-                    zones when they are loaded from disk. <acronym>BIND</acronym> 9 does not verify signatures
-                    on load and ignores the option.
-                  </para>
-                </listitem>
-              </varlistentry>
-
-              <varlistentry>
-                <term><command>zone-statistics</command></term>
-                <listitem>
-                  <para>
-                    If <userinput>yes</userinput>, the server will keep
-                    statistical
-                    information for this zone, which can be dumped to the
-                    <command>statistics-file</command> defined in
-                    the server options.
-                  </para>
-                </listitem>
-              </varlistentry>
-
-              <varlistentry>
-                <term><command>sig-validity-interval</command></term>
-                <listitem>
-                  <para>
-                    See the description of
-                    <command>sig-validity-interval</command> in <xref linkend="tuning"/>.
-                  </para>
-                </listitem>
-              </varlistentry>
-
-              <varlistentry>
-                <term><command>transfer-source</command></term>
-                <listitem>
-                  <para>
-                    See the description of
-                    <command>transfer-source</command> in <xref linkend="zone_transfers"/>.
-                  </para>
-                </listitem>
-              </varlistentry>
-
-              <varlistentry>
-                <term><command>transfer-source-v6</command></term>
-                <listitem>
-                  <para>
-                    See the description of
-                    <command>transfer-source-v6</command> in <xref linkend="zone_transfers"/>.
-                  </para>
-                </listitem>
-              </varlistentry>
-
-              <varlistentry>
-                <term><command>alt-transfer-source</command></term>
-                <listitem>
-                  <para>
-                    See the description of
-                    <command>alt-transfer-source</command> in <xref linkend="zone_transfers"/>.
-                  </para>
-                </listitem>
-              </varlistentry>
-
-              <varlistentry>
-                <term><command>alt-transfer-source-v6</command></term>
-                <listitem>
-                  <para>
-                    See the description of
-                    <command>alt-transfer-source-v6</command> in <xref linkend="zone_transfers"/>.
-                  </para>
-                </listitem>
-              </varlistentry>
-
-              <varlistentry>
-                <term><command>use-alt-transfer-source</command></term>
-                <listitem>
-                  <para>
-                    See the description of
-                    <command>use-alt-transfer-source</command> in <xref linkend="zone_transfers"/>.
-                  </para>
-                </listitem>
-              </varlistentry>
-
-
-              <varlistentry>
-                <term><command>notify-source</command></term>
-                <listitem>
-                  <para>
-                    See the description of
-                    <command>notify-source</command> in <xref linkend="zone_transfers"/>.
-                  </para>
-                </listitem>
-              </varlistentry>
-
-              <varlistentry>
-                <term><command>notify-source-v6</command></term>
-                <listitem>
-                  <para>
-                    See the description of
-                    <command>notify-source-v6</command> in <xref linkend="zone_transfers"/>.
-                  </para>
-                </listitem>
-              </varlistentry>
-
-              <varlistentry>
-                <term><command>min-refresh-time</command></term>
-                <term><command>max-refresh-time</command></term>
-                <term><command>min-retry-time</command></term>
-                <term><command>max-retry-time</command></term>
-                <listitem>
-                  <para>
-                    See the description in <xref linkend="tuning"/>.
-                  </para>
-                </listitem>
-              </varlistentry>
-
-              <varlistentry>
-                <term><command>ixfr-from-differences</command></term>
-                <listitem>
-                  <para>
-                    See the description of
-                    <command>ixfr-from-differences</command> in <xref linkend="boolean_options"/>.
-                  </para>
-                </listitem>
-              </varlistentry>
-
-              <varlistentry>
-                <term><command>key-directory</command></term>
-                <listitem>
-                  <para>
-                    See the description of
-                    <command>key-directory</command> in <xref linkend="options"/>.
-                  </para>
-                </listitem>
-              </varlistentry>
-
-              <varlistentry>
-                <term><command>multi-master</command></term>
-                <listitem>
-                  <para>
-                    See the description of <command>multi-master</command> in
-		    <xref linkend="boolean_options"/>.
-                  </para>
-                </listitem>
-              </varlistentry>
-	
-	      <varlistentry>
-		<term><command>masterfile-format</command></term>
-		<listitem>
-		  <para>
-		    See the description of <command>masterfile-format</command>
-		    in <xref linkend="tuning"/>.
-		  </para>
-		</listitem>
-	      </varlistentry>
-
-            </variablelist>
-
-          </sect3>
-          <sect3 id="dynamic_update_policies">
-            <title>Dynamic Update Policies</title>
-            <para>
-              <acronym>BIND</acronym> 9 supports two alternative
-              methods of granting clients
-              the right to perform dynamic updates to a zone,
-              configured by the <command>allow-update</command>
-              and
-              <command>update-policy</command> option,
-              respectively.
-            </para>
-            <para>
-              The <command>allow-update</command> clause works the
-              same
-              way as in previous versions of <acronym>BIND</acronym>. It grants given clients the
-              permission to update any record of any name in the zone.
-            </para>
-            <para>
-              The <command>update-policy</command> clause is new
-              in <acronym>BIND</acronym>
-              9 and allows more fine-grained control over what updates are
-              allowed.
-              A set of rules is specified, where each rule either grants or
-              denies
-              permissions for one or more names to be updated by one or more
-              identities.
-              If the dynamic update request message is signed (that is, it
-              includes
-              either a TSIG or SIG(0) record), the identity of the signer can
-              be determined.
-            </para>
-            <para>
-              Rules are specified in the <command>update-policy</command> zone
-              option, and are only meaningful for master zones.  When the <command>update-policy</command> statement
-              is present, it is a configuration error for the <command>allow-update</command> statement
-              to be present.  The <command>update-policy</command>
-              statement only
-              examines the signer of a message; the source address is not
-              relevant.
-            </para>
-            <para>
-              This is how a rule definition looks:
-            </para>
-
-<programlisting>
-( <command>grant</command> | <command>deny</command> ) <replaceable>identity</replaceable> <replaceable>nametype</replaceable> <replaceable>name</replaceable> <optional> <replaceable>types</replaceable> </optional>
-</programlisting>
-
-            <para>
-              Each rule grants or denies privileges.  Once a message has
-              successfully matched a rule, the operation is immediately
-              granted
-              or denied and no further rules are examined.  A rule is matched
-              when the signer matches the identity field, the name matches the
-              name field in accordance with the nametype field, and the type
-              matches
-              the types specified in the type field.
-            </para>
-
-            <para>
-              The identity field specifies a name or a wildcard name.
-              Normally, this
-              is the name of the TSIG or SIG(0) key used to sign the update
-              request.  When a
-              TKEY exchange has been used to create a shared secret, the
-              identity of the
-              shared secret is the same as the identity of the key used to
-              authenticate the
-              TKEY exchange.  When the <replaceable>identity</replaceable> field specifies a
-              wildcard name, it is subject to DNS wildcard expansion, so the
-              rule will apply
-              to multiple identities.  The <replaceable>identity</replaceable> field must
-              contain a fully-qualified domain name.
-            </para>
-
-            <para>
-              The <replaceable>nametype</replaceable> field has 6
-              values:
-              <varname>name</varname>, <varname>subdomain</varname>,
-              <varname>wildcard</varname>, <varname>self</varname>,
-	       <varname>selfsub</varname>, and <varname>selfwild</varname>.
-            </para>
-            <informaltable>
-              <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="4Level-table">
-                <colspec colname="1" colnum="1" colsep="0" colwidth="0.819in"/>
-                <colspec colname="2" colnum="2" colsep="0" colwidth="3.681in"/>
-                <tbody>
-		  <row rowsep="0">
-		    <entry colname="1">
-		      <para>
-			<varname>name</varname>
-		      </para>
-		    </entry> <entry colname="2">
-		      <para>
-			Exact-match semantics.  This rule matches
-			when the name being updated is identical
-			to the contents of the
-			<replaceable>name</replaceable> field.
-		      </para>
-		    </entry>
-		  </row>
-		  <row rowsep="0">
-		    <entry colname="1">
-		      <para>
-			<varname>subdomain</varname>
-		      </para>
-		    </entry> <entry colname="2">
-		      <para>
-			This rule matches when the name being updated
-			is a subdomain of, or identical to, the
-			contents of the <replaceable>name</replaceable>
-			field.
-		      </para>
-		    </entry>
-		  </row>
-		  <row rowsep="0">
-		    <entry colname="1">
-		      <para>
-			<varname>wildcard</varname>
-		      </para>
-		    </entry> <entry colname="2">
-		      <para>
-			The <replaceable>name</replaceable> field
-			is subject to DNS wildcard expansion, and
-			this rule matches when the name being updated
-			name is a valid expansion of the wildcard.
-		      </para>
-		    </entry>
-		  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        <varname>self</varname>
-                      </para>
-                    </entry>
-                    <entry colname="2">
-		      <para>
-			This rule matches when the name being updated
-			matches the contents of the
-			<replaceable>identity</replaceable> field.
-			The <replaceable>name</replaceable> field
-			is ignored, but should be the same as the
-			<replaceable>identity</replaceable> field.
-			The <varname>self</varname> nametype is
-			most useful when allowing using one key per
-			name to update, where the key has the same
-			name as the name to be updated.  The
-			<replaceable>identity</replaceable> would
-			be specified as <constant>*</constant> (an asterisk) in
-			this case.
-		      </para>
-		    </entry>
-		  </row>
-		  <row rowsep="0">
-		    <entry colname="1">
-		      <para>
-			<varname>selfsub</varname>
-		      </para>
-		    </entry> <entry colname="2">
-		      <para>
-			This rule is similar to <varname>self</varname>
-			except that subdomains of <varname>self</varname>
-			can also be updated.
-		      </para>
-		    </entry>
-		  </row>
-		  <row rowsep="0">
-		    <entry colname="1">
-		      <para>
-			<varname>selfwild</varname>
-		      </para>
-		    </entry> <entry colname="2">
-		      <para>
-			This rule is similar to <varname>self</varname>
-			except that only subdomains of
-			<varname>self</varname> can be updated.
-		      </para>
-		    </entry>
-		  </row>
-                </tbody>
-              </tgroup>
-            </informaltable>
-
-            <para>
-              In all cases, the <replaceable>name</replaceable>
-              field must
-              specify a fully-qualified domain name.
-            </para>
-
-            <para>
-              If no types are explicitly specified, this rule matches all
-              types except
-              RRSIG, NS, SOA, and NSEC. Types may be specified by name, including
-              "ANY" (ANY matches all types except NSEC, which can never be
-              updated).
-              Note that when an attempt is made to delete all records
-              associated with a
-              name, the rules are checked for each existing record type.
-            </para>
-          </sect3>
-        </sect2>
-      </sect1>
-      <sect1>
-        <title>Zone File</title>
-        <sect2 id="types_of_resource_records_and_when_to_use_them">
-          <title>Types of Resource Records and When to Use Them</title>
-          <para>
-            This section, largely borrowed from RFC 1034, describes the
-            concept of a Resource Record (RR) and explains when each is used.
-            Since the publication of RFC 1034, several new RRs have been
-            identified
-            and implemented in the DNS. These are also included.
-          </para>
-          <sect3>
-            <title>Resource Records</title>
-
-            <para>
-              A domain name identifies a node.  Each node has a set of
-              resource information, which may be empty.  The set of resource
-              information associated with a particular name is composed of
-              separate RRs. The order of RRs in a set is not significant and
-              need not be preserved by name servers, resolvers, or other
-              parts of the DNS. However, sorting of multiple RRs is
-              permitted for optimization purposes, for example, to specify
-              that a particular nearby server be tried first. See <xref linkend="the_sortlist_statement"/> and <xref linkend="rrset_ordering"/>.
-            </para>
-
-            <para>
-              The components of a Resource Record are:
-            </para>
-            <informaltable colsep="0" rowsep="0">
-              <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="4Level-table">
-                <colspec colname="1" colnum="1" colsep="0" colwidth="1.000in"/>
-                <colspec colname="2" colnum="2" colsep="0" colwidth="3.500in"/>
-                <tbody>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        owner name
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        The domain name where the RR is found.
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        type
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        An encoded 16-bit value that specifies
-                        the type of the resource record.
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        TTL
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        The time-to-live of the RR. This field
-                        is a 32-bit integer in units of seconds, and is
-                        primarily used by
-                        resolvers when they cache RRs. The TTL describes how
-                        long a RR can
-                        be cached before it should be discarded.
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        class
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        An encoded 16-bit value that identifies
-                        a protocol family or instance of a protocol.
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        RDATA
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        The resource data.  The format of the
-                        data is type (and sometimes class) specific.
-                      </para>
-                    </entry>
-                  </row>
-                </tbody>
-              </tgroup>
-            </informaltable>
-            <para>
-              The following are <emphasis>types</emphasis> of valid RRs:
-            </para>
-            <informaltable colsep="0" rowsep="0">
-              <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="4Level-table">
-                <colspec colname="1" colnum="1" colsep="0" colwidth="0.875in"/>
-                <colspec colname="2" colnum="2" colsep="0" colwidth="3.625in"/>
-                <tbody>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        A
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        A host address.  In the IN class, this is a
-                        32-bit IP address.  Described in RFC 1035.
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        AAAA
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        IPv6 address.  Described in RFC 1886.
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        A6
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        IPv6 address.  This can be a partial
-                        address (a suffix) and an indirection to the name
-                        where the rest of the
-                        address (the prefix) can be found.  Experimental.
-                        Described in RFC 2874.
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        AFSDB
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        Location of AFS database servers.
-                        Experimental.  Described in RFC 1183.
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        APL
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        Address prefix list.  Experimental.
-                        Described in RFC 3123.
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        CERT
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        Holds a digital certificate.
-                        Described in RFC 2538.
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        CNAME
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        Identifies the canonical name of an alias.
-                        Described in RFC 1035.
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        DNAME
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        Replaces the domain name specified with
-                        another name to be looked up, effectively aliasing an
-                        entire
-                        subtree of the domain name space rather than a single
-                        record
-                        as in the case of the CNAME RR.
-                        Described in RFC 2672.
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        DNSKEY
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        Stores a public key associated with a signed
-                        DNS zone.  Described in RFC 4034.
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        DS
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        Stores the hash of a public key associated with a
-                        signed DNS zone.  Described in RFC 4034.
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        GPOS
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        Specifies the global position.  Superseded by LOC.
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        HINFO
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        Identifies the CPU and OS used by a host.
-                        Described in RFC 1035.
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        ISDN
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        Representation of ISDN addresses.
-                        Experimental.  Described in RFC 1183.
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        KEY
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        Stores a public key associated with a
-                        DNS name.  Used in original DNSSEC; replaced
-			by DNSKEY in DNSSECbis, but still used with
-			SIG(0).  Described in RFCs 2535 and 2931.
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        KX
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        Identifies a key exchanger for this
-                        DNS name.  Described in RFC 2230.
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        LOC
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        For storing GPS info.  Described in RFC 1876.
-                        Experimental.
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        MX
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        Identifies a mail exchange for the domain with
-                        a 16-bit preference value (lower is better)
-                        followed by the host name of the mail exchange.
-                        Described in RFC 974, RFC 1035.
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        NAPTR
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        Name authority pointer.  Described in RFC 2915.
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        NSAP
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        A network service access point.
-                        Described in RFC 1706.
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        NS
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        The authoritative name server for the
-                        domain.  Described in RFC 1035.
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        NSEC
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        Used in DNSSECbis to securely indicate that
-                        RRs with an owner name in a certain name interval do
-                        not exist in
-                        a zone and indicate what RR types are present for an
-                        existing name.
-                        Described in RFC 4034.
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        NXT
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        Used in DNSSEC to securely indicate that
-                        RRs with an owner name in a certain name interval do
-                        not exist in
-                        a zone and indicate what RR types are present for an
-                        existing name.
-			Used in original DNSSEC; replaced by NSEC in
-			DNSSECbis.
-                        Described in RFC 2535.
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        PTR
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        A pointer to another part of the domain
-                        name space.  Described in RFC 1035.
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        PX
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        Provides mappings between RFC 822 and X.400
-                        addresses.  Described in RFC 2163.
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        RP
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        Information on persons responsible
-                        for the domain.  Experimental.  Described in RFC 1183.
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        RRSIG
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        Contains DNSSECbis signature data.  Described
-			in RFC 4034.
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        RT
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        Route-through binding for hosts that
-                        do not have their own direct wide area network
-                        addresses.
-                        Experimental.  Described in RFC 1183.
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        SIG
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        Contains DNSSEC signature data.  Used in
-			original DNSSEC; replaced by RRSIG in
-			DNSSECbis, but still used for SIG(0).
-			Described in RFCs 2535 and 2931.
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        SOA
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        Identifies the start of a zone of authority.
-                        Described in RFC 1035.
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        SRV
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        Information about well known network
-                        services (replaces WKS).  Described in RFC 2782.
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        TXT
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        Text records.  Described in RFC 1035.
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        WKS
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        Information about which well known
-                        network services, such as SMTP, that a domain
-                        supports. Historical.
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        X25
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        Representation of X.25 network addresses.
-                        Experimental.  Described in RFC 1183.
-                      </para>
-                    </entry>
-                  </row>
-                </tbody>
-              </tgroup>
-            </informaltable>
-            <para>
-              The following <emphasis>classes</emphasis> of resource records
-              are currently valid in the DNS:
-            </para>
-            <informaltable colsep="0" rowsep="0"><tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="4Level-table">
-                <colspec colname="1" colnum="1" colsep="0" colwidth="0.875in"/>
-                <colspec colname="2" colnum="2" colsep="0" colwidth="3.625in"/>
-                <tbody>
-
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        IN
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        The Internet.
-                      </para>
-                    </entry>
-                  </row>
-
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        CH
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        Chaosnet, a LAN protocol created at MIT in the
-                        mid-1970s.
-                        Rarely used for its historical purpose, but reused for
-                        BIND's
-                        built-in server information zones, e.g.,
-                        <literal>version.bind</literal>.
-                      </para>
-                    </entry>
-                  </row>
-
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        HS
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        Hesiod, an information service
-                        developed by MIT's Project Athena. It is used to share
-                        information
-                        about various systems databases, such as users,
-                        groups, printers
-                        and so on.
-                      </para>
-                    </entry>
-                  </row>
-
-                </tbody>
-              </tgroup>
-            </informaltable>
-
-            <para>
-              The owner name is often implicit, rather than forming an
-              integral
-              part of the RR.  For example, many name servers internally form
-              tree
-              or hash structures for the name space, and chain RRs off nodes.
-              The remaining RR parts are the fixed header (type, class, TTL)
-              which is consistent for all RRs, and a variable part (RDATA)
-              that
-              fits the needs of the resource being described.
-            </para>
-            <para>
-              The meaning of the TTL field is a time limit on how long an
-              RR can be kept in a cache.  This limit does not apply to
-              authoritative
-              data in zones; it is also timed out, but by the refreshing
-              policies
-              for the zone.  The TTL is assigned by the administrator for the
-              zone where the data originates.  While short TTLs can be used to
-              minimize caching, and a zero TTL prohibits caching, the
-              realities
-              of Internet performance suggest that these times should be on
-              the
-              order of days for the typical host.  If a change can be
-              anticipated,
-              the TTL can be reduced prior to the change to minimize
-              inconsistency
-              during the change, and then increased back to its former value
-              following
-              the change.
-            </para>
-            <para>
-              The data in the RDATA section of RRs is carried as a combination
-              of binary strings and domain names.  The domain names are
-              frequently
-              used as "pointers" to other data in the DNS.
-            </para>
-          </sect3>
-          <sect3>
-            <title>Textual expression of RRs</title>
-            <para>
-              RRs are represented in binary form in the packets of the DNS
-              protocol, and are usually represented in highly encoded form
-              when
-              stored in a name server or resolver.  In the examples provided
-              in
-              RFC 1034, a style similar to that used in master files was
-              employed
-              in order to show the contents of RRs.  In this format, most RRs
-              are shown on a single line, although continuation lines are
-              possible
-              using parentheses.
-            </para>
-            <para>
-              The start of the line gives the owner of the RR.  If a line
-              begins with a blank, then the owner is assumed to be the same as
-              that of the previous RR.  Blank lines are often included for
-              readability.
-            </para>
-            <para>
-              Following the owner, we list the TTL, type, and class of the
-              RR.  Class and type use the mnemonics defined above, and TTL is
-              an integer before the type field.  In order to avoid ambiguity
-              in
-              parsing, type and class mnemonics are disjoint, TTLs are
-              integers,
-              and the type mnemonic is always last. The IN class and TTL
-              values
-              are often omitted from examples in the interests of clarity.
-            </para>
-            <para>
-              The resource data or RDATA section of the RR are given using
-              knowledge of the typical representation for the data.
-            </para>
-            <para>
-              For example, we might show the RRs carried in a message as:
-            </para>
-            <informaltable colsep="0" rowsep="0"><tgroup cols="3" colsep="0" rowsep="0" tgroupstyle="4Level-table">
-                <colspec colname="1" colnum="1" colsep="0" colwidth="1.381in"/>
-                <colspec colname="2" colnum="2" colsep="0" colwidth="1.020in"/>
-                <colspec colname="3" colnum="3" colsep="0" colwidth="2.099in"/>
-                <tbody>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        <literal>ISI.EDU.</literal>
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        <literal>MX</literal>
-                      </para>
-                    </entry>
-                    <entry colname="3">
-                      <para>
-                        <literal>10 VENERA.ISI.EDU.</literal>
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para/>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        <literal>MX</literal>
-                      </para>
-                    </entry>
-                    <entry colname="3">
-                      <para>
-                        <literal>10 VAXA.ISI.EDU</literal>
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        <literal>VENERA.ISI.EDU</literal>
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        <literal>A</literal>
-                      </para>
-                    </entry>
-                    <entry colname="3">
-                      <para>
-                        <literal>128.9.0.32</literal>
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para/>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        <literal>A</literal>
-                      </para>
-                    </entry>
-                    <entry colname="3">
-                      <para>
-                        <literal>10.1.0.52</literal>
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        <literal>VAXA.ISI.EDU</literal>
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        <literal>A</literal>
-                      </para>
-                    </entry>
-                    <entry colname="3">
-                      <para>
-                        <literal>10.2.0.27</literal>
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para/>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        <literal>A</literal>
-                      </para>
-                    </entry>
-                    <entry colname="3">
-                      <para>
-                        <literal>128.9.0.33</literal>
-                      </para>
-                    </entry>
-                  </row>
-                </tbody>
-              </tgroup>
-            </informaltable>
-            <para>
-              The MX RRs have an RDATA section which consists of a 16-bit
-              number followed by a domain name.  The address RRs use a
-              standard
-              IP address format to contain a 32-bit internet address.
-            </para>
-            <para>
-              The above example shows six RRs, with two RRs at each of three
-              domain names.
-            </para>
-            <para>
-              Similarly we might see:
-            </para>
-            <informaltable colsep="0" rowsep="0"><tgroup cols="3" colsep="0" rowsep="0" tgroupstyle="4Level-table">
-                <colspec colname="1" colnum="1" colsep="0" colwidth="1.491in"/>
-                <colspec colname="2" colnum="2" colsep="0" colwidth="1.067in"/>
-                <colspec colname="3" colnum="3" colsep="0" colwidth="2.067in"/>
-                <tbody>
-                  <row rowsep="0">
-                    <entry colname="1">
-                      <para>
-                        <literal>XX.LCS.MIT.EDU.</literal>
-                      </para>
-                    </entry>
-                    <entry colname="2">
-                      <para>
-                        <literal>IN A</literal>
-                      </para>
-                    </entry>
-                    <entry colname="3">
-                      <para>
-                        <literal>10.0.0.44</literal>
-                      </para>
-                    </entry>
-                  </row>
-                  <row rowsep="0">
-		    <entry colname="1"/>
-                    <entry colname="2">
-                      <para>
-                        <literal>CH A</literal>
-                      </para>
-                    </entry>
-                    <entry colname="3">
-                      <para>
-                        <literal>MIT.EDU. 2420</literal>
-                      </para>
-                    </entry>
-                  </row>
-                </tbody>
-              </tgroup>
-            </informaltable>
-            <para>
-              This example shows two addresses for
-	      <literal>XX.LCS.MIT.EDU</literal>, each of a different class.
-            </para>
-          </sect3>
-        </sect2>
-
-        <sect2>
-          <title>Discussion of MX Records</title>
-
-          <para>
-            As described above, domain servers store information as a
-            series of resource records, each of which contains a particular
-            piece of information about a given domain name (which is usually,
-            but not always, a host). The simplest way to think of a RR is as
-            a typed pair of data, a domain name matched with a relevant datum,
-            and stored with some additional type information to help systems
-            determine when the RR is relevant.
-          </para>
-
-          <para>
-            MX records are used to control delivery of email. The data
-            specified in the record is a priority and a domain name. The
-            priority
-            controls the order in which email delivery is attempted, with the
-            lowest number first. If two priorities are the same, a server is
-            chosen randomly. If no servers at a given priority are responding,
-            the mail transport agent will fall back to the next largest
-            priority.
-            Priority numbers do not have any absolute meaning &mdash; they are
-            relevant
-            only respective to other MX records for that domain name. The
-            domain
-            name given is the machine to which the mail will be delivered.
-	    It <emphasis>must</emphasis> have an associated address record
-	    (A or AAAA) &mdash; CNAME is not sufficient.
-          </para>
-          <para>
-            For a given domain, if there is both a CNAME record and an
-            MX record, the MX record is in error, and will be ignored.
-            Instead,
-            the mail will be delivered to the server specified in the MX
-            record
-            pointed to by the CNAME.
-          </para>
-	  <para>
-            For example:
-          </para>
-          <informaltable colsep="0" rowsep="0">
-            <tgroup cols="5" colsep="0" rowsep="0" tgroupstyle="3Level-table">
-              <colspec colname="1" colnum="1" colsep="0" colwidth="1.708in"/>
-              <colspec colname="2" colnum="2" colsep="0" colwidth="0.444in"/>
-              <colspec colname="3" colnum="3" colsep="0" colwidth="0.444in"/>
-              <colspec colname="4" colnum="4" colsep="0" colwidth="0.976in"/>
-              <colspec colname="5" colnum="5" colsep="0" colwidth="1.553in"/>
-              <tbody>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para>
-                      <literal>example.com.</literal>
-                    </para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      <literal>IN</literal>
-                    </para>
-                  </entry>
-                  <entry colname="3">
-                    <para>
-                      <literal>MX</literal>
-                    </para>
-                  </entry>
-                  <entry colname="4">
-                    <para>
-                      <literal>10</literal>
-                    </para>
-                  </entry>
-                  <entry colname="5">
-                    <para>
-                      <literal>mail.example.com.</literal>
-                    </para>
-                  </entry>
-                </row>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para/>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      <literal>IN</literal>
-                    </para>
-                  </entry>
-                  <entry colname="3">
-                    <para>
-                      <literal>MX</literal>
-                    </para>
-                  </entry>
-                  <entry colname="4">
-                    <para>
-                      <literal>10</literal>
-                    </para>
-                  </entry>
-                  <entry colname="5">
-                    <para>
-                      <literal>mail2.example.com.</literal>
-                    </para>
-                  </entry>
-                </row>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para/>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      <literal>IN</literal>
-                    </para>
-                  </entry>
-                  <entry colname="3">
-                    <para>
-                      <literal>MX</literal>
-                    </para>
-                  </entry>
-                  <entry colname="4">
-                    <para>
-                      <literal>20</literal>
-                    </para>
-                  </entry>
-                  <entry colname="5">
-                    <para>
-                      <literal>mail.backup.org.</literal>
-                    </para>
-                  </entry>
-                </row>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para>
-                      <literal>mail.example.com.</literal>
-                    </para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      <literal>IN</literal>
-                    </para>
-                  </entry>
-                  <entry colname="3">
-                    <para>
-                      <literal>A</literal>
-                    </para>
-                  </entry>
-                  <entry colname="4">
-                    <para>
-                      <literal>10.0.0.1</literal>
-                    </para>
-                  </entry>
-                  <entry colname="5">
-                    <para/>
-                  </entry>
-                </row>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para>
-                      <literal>mail2.example.com.</literal>
-                    </para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      <literal>IN</literal>
-                    </para>
-                  </entry>
-                  <entry colname="3">
-                    <para>
-                      <literal>A</literal>
-                    </para>
-                  </entry>
-                  <entry colname="4">
-                    <para>
-                      <literal>10.0.0.2</literal>
-                    </para>
-                  </entry>
-                  <entry colname="5">
-                    <para/>
-                  </entry>
-                </row>
-              </tbody>
-            </tgroup>
-            </informaltable><para>
-            Mail delivery will be attempted to <literal>mail.example.com</literal> and
-            <literal>mail2.example.com</literal> (in
-            any order), and if neither of those succeed, delivery to <literal>mail.backup.org</literal> will
-            be attempted.
-          </para>
-        </sect2>
-        <sect2 id="Setting_TTLs">
-          <title>Setting TTLs</title>
-          <para>
-            The time-to-live of the RR field is a 32-bit integer represented
-            in units of seconds, and is primarily used by resolvers when they
-            cache RRs. The TTL describes how long a RR can be cached before it
-            should be discarded. The following three types of TTL are
-            currently
-            used in a zone file.
-          </para>
-          <informaltable colsep="0" rowsep="0">
-            <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="3Level-table">
-              <colspec colname="1" colnum="1" colsep="0" colwidth="0.750in"/>
-              <colspec colname="2" colnum="2" colsep="0" colwidth="4.375in"/>
-              <tbody>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para>
-                      SOA
-                    </para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      The last field in the SOA is the negative
-                      caching TTL. This controls how long other servers will
-                      cache no-such-domain
-                      (NXDOMAIN) responses from you.
-                    </para>
-                    <para>
-                      The maximum time for
-                      negative caching is 3 hours (3h).
-                    </para>
-                  </entry>
-                </row>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para>
-                      $TTL
-                    </para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      The $TTL directive at the top of the
-                      zone file (before the SOA) gives a default TTL for every
-                      RR without
-                      a specific TTL set.
-                    </para>
-                  </entry>
-                </row>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para>
-                      RR TTLs
-                    </para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      Each RR can have a TTL as the second
-                      field in the RR, which will control how long other
-                      servers can cache
-                      the it.
-                    </para>
-                  </entry>
-                </row>
-              </tbody>
-            </tgroup>
-          </informaltable>
-          <para>
-            All of these TTLs default to units of seconds, though units
-            can be explicitly specified, for example, <literal>1h30m</literal>.
-          </para>
-        </sect2>
-        <sect2>
-          <title>Inverse Mapping in IPv4</title>
-          <para>
-            Reverse name resolution (that is, translation from IP address
-            to name) is achieved by means of the <emphasis>in-addr.arpa</emphasis> domain
-            and PTR records. Entries in the in-addr.arpa domain are made in
-            least-to-most significant order, read left to right. This is the
-            opposite order to the way IP addresses are usually written. Thus,
-            a machine with an IP address of 10.1.2.3 would have a
-            corresponding
-            in-addr.arpa name of
-            3.2.1.10.in-addr.arpa. This name should have a PTR resource record
-            whose data field is the name of the machine or, optionally,
-            multiple
-            PTR records if the machine has more than one name. For example,
-            in the <optional>example.com</optional> domain:
-          </para>
-          <informaltable colsep="0" rowsep="0">
-            <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="3Level-table">
-              <colspec colname="1" colnum="1" colsep="0" colwidth="1.125in"/>
-              <colspec colname="2" colnum="2" colsep="0" colwidth="4.000in"/>
-              <tbody>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para>
-                      <literal>$ORIGIN</literal>
-                    </para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      <literal>2.1.10.in-addr.arpa</literal>
-                    </para>
-                  </entry>
-                </row>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para>
-                      <literal>3</literal>
-                    </para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      <literal>IN PTR foo.example.com.</literal>
-                    </para>
-                  </entry>
-                </row>
-              </tbody>
-            </tgroup>
-          </informaltable>
-          <note>
-            <para>
-              The <command>$ORIGIN</command> lines in the examples
-              are for providing context to the examples only &mdash; they do not
-              necessarily
-              appear in the actual usage. They are only used here to indicate
-              that the example is relative to the listed origin.
-            </para>
-          </note>
-        </sect2>
-        <sect2>
-          <title>Other Zone File Directives</title>
-          <para>
-            The Master File Format was initially defined in RFC 1035 and
-            has subsequently been extended. While the Master File Format
-            itself
-            is class independent all records in a Master File must be of the
-            same
-            class.
-          </para>
-          <para>
-            Master File Directives include <command>$ORIGIN</command>, <command>$INCLUDE</command>,
-            and <command>$TTL.</command>
-          </para>
-          <sect3>
-            <title>The <command>$ORIGIN</command> Directive</title>
-            <para>
-              Syntax: <command>$ORIGIN</command>
-	      <replaceable>domain-name</replaceable>
-              <optional><replaceable>comment</replaceable></optional>
-            </para>
-            <para><command>$ORIGIN</command>
-	      sets the domain name that will be appended to any
-              unqualified records. When a zone is first read in there
-              is an implicit <command>$ORIGIN</command>
-              &lt;<varname>zone-name</varname>&gt;<command>.</command>
-              The current <command>$ORIGIN</command> is appended to
-              the domain specified in the <command>$ORIGIN</command>
-              argument if it is not absolute.
-            </para>
-
-<programlisting>
-$ORIGIN example.com.
-WWW     CNAME   MAIN-SERVER
-</programlisting>
-
-            <para>
-              is equivalent to
-            </para>
-
-<programlisting>
-WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.
-</programlisting>
-
-          </sect3>
-          <sect3>
-            <title>The <command>$INCLUDE</command> Directive</title>
-            <para>
-              Syntax: <command>$INCLUDE</command>
-              <replaceable>filename</replaceable>
-              <optional>
-<replaceable>origin</replaceable> </optional>
-              <optional> <replaceable>comment</replaceable> </optional>
-            </para>
-            <para>
-              Read and process the file <filename>filename</filename> as
-              if it were included into the file at this point.  If <command>origin</command> is
-              specified the file is processed with <command>$ORIGIN</command> set
-              to that value, otherwise the current <command>$ORIGIN</command> is
-              used.
-            </para>
-            <para>
-              The origin and the current domain name
-              revert to the values they had prior to the <command>$INCLUDE</command> once
-              the file has been read.
-            </para>
-            <note>
-              <para>
-                RFC 1035 specifies that the current origin should be restored
-                after
-                an <command>$INCLUDE</command>, but it is silent
-                on whether the current
-                domain name should also be restored.  BIND 9 restores both of
-                them.
-                This could be construed as a deviation from RFC 1035, a
-                feature, or both.
-              </para>
-            </note>
-          </sect3>
-          <sect3>
-            <title>The <command>$TTL</command> Directive</title>
-            <para>
-              Syntax: <command>$TTL</command>
-              <replaceable>default-ttl</replaceable>
-              <optional>
-<replaceable>comment</replaceable> </optional>
-            </para>
-            <para>
-              Set the default Time To Live (TTL) for subsequent records
-              with undefined TTLs. Valid TTLs are of the range 0-2147483647
-              seconds.
-            </para>
-            <para><command>$TTL</command>
-	       is defined in RFC 2308.
-            </para>
-          </sect3>
-        </sect2>
-        <sect2>
-          <title><acronym>BIND</acronym> Master File Extension: the  <command>$GENERATE</command> Directive</title>
-          <para>
-            Syntax: <command>$GENERATE</command>
-	    <replaceable>range</replaceable>
-	    <replaceable>lhs</replaceable>
-            <optional><replaceable>ttl</replaceable></optional>
-            <optional><replaceable>class</replaceable></optional>
-	    <replaceable>type</replaceable>
-	    <replaceable>rhs</replaceable>
-            <optional><replaceable>comment</replaceable></optional>
-          </para>
-          <para><command>$GENERATE</command>
-	    is used to create a series of resource records that only
-            differ from each other by an
-            iterator. <command>$GENERATE</command> can be used to
-            easily generate the sets of records required to support
-            sub /24 reverse delegations described in RFC 2317:
-            Classless IN-ADDR.ARPA delegation.
-          </para>
-
-<programlisting>$ORIGIN 0.0.192.IN-ADDR.ARPA.
-$GENERATE 1-2 0 NS SERVER$.EXAMPLE.
-$GENERATE 1-127 $ CNAME $.0</programlisting>
-
-          <para>
-            is equivalent to
-          </para>
-
-<programlisting>0.0.0.192.IN-ADDR.ARPA NS SERVER1.EXAMPLE.
-0.0.0.192.IN-ADDR.ARPA. NS SERVER2.EXAMPLE.
-1.0.0.192.IN-ADDR.ARPA. CNAME 1.0.0.0.192.IN-ADDR.ARPA.
-2.0.0.192.IN-ADDR.ARPA. CNAME 2.0.0.0.192.IN-ADDR.ARPA.
-...
-127.0.0.192.IN-ADDR.ARPA. CNAME 127.0.0.0.192.IN-ADDR.ARPA.
-</programlisting>
-
-          <informaltable colsep="0" rowsep="0">
-            <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="3Level-table">
-                        <colspec colname="1" colnum="1" colsep="0" colwidth="0.875in"/>
-              <colspec colname="2" colnum="2" colsep="0" colwidth="4.250in"/>
-              <tbody>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para><command>range</command></para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      This can be one of two forms: start-stop
-                      or start-stop/step. If the first form is used, then step
-                      is set to
-                      1. All of start, stop and step must be positive.
-                    </para>
-                  </entry>
-                </row>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para><command>lhs</command></para>
-                  </entry>
-                  <entry colname="2">
-                    <para>This
-		      describes the owner name of the resource records
-                      to be created.  Any single <command>$</command>
-                      (dollar sign)
-                      symbols within the <command>lhs</command> side
-                      are replaced by the iterator value.
-
-                      To get a $ in the output, you need to escape the
-                      <command>$</command> using a backslash
-                      <command>\</command>,
-                      e.g. <command>\$</command>. The
-                      <command>$</command> may optionally be followed
-                      by modifiers which change the offset from the
-                      iterator, field width and base.
-
-                      Modifiers are introduced by a
-                      <command>{</command> (left brace) immediately following the
-                      <command>$</command> as
-                      <command>${offset[,width[,base]]}</command>.
-                      For example, <command>${-20,3,d}</command>
-                      subtracts 20 from the current value, prints the
-                      result as a decimal in a zero-padded field of
-                      width 3.
-
-		      Available output forms are decimal
-                      (<command>d</command>), octal
-                      (<command>o</command>) and hexadecimal
-                      (<command>x</command> or <command>X</command>
-                      for uppercase).  The default modifier is
-                      <command>${0,0,d}</command>.  If the
-                      <command>lhs</command> is not absolute, the
-                      current <command>$ORIGIN</command> is appended
-                      to the name.
-                    </para>
-                    <para>
-                      For compatibility with earlier versions, <command>$$</command> is still
-                      recognized as indicating a literal $ in the output.
-                    </para>
-                  </entry>
-                </row>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para><command>ttl</command></para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-		      Specifies the time-to-live of the generated records. If
-                      not specified this will be inherited using the
-                      normal ttl inheritance rules.
-                    </para>
-                    <para><command>class</command>
-		      and <command>ttl</command> can be
-                      entered in either order.
-                    </para>
-                  </entry>
-                </row>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para><command>class</command></para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-		      Specifies the class of the generated records.
-                      This must match the zone class if it is
-                      specified.
-                    </para>
-                    <para><command>class</command>
-		      and <command>ttl</command> can be
-                      entered in either order.
-                    </para>
-                  </entry>
-                </row>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para><command>type</command></para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      At present the only supported types are
-                      PTR, CNAME, DNAME, A, AAAA and NS.
-                    </para>
-                  </entry>
-                </row>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para><command>rhs</command></para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      <command>rhs</command> is a domain name. It is processed
-                      similarly to lhs.
-                    </para>
-                  </entry>
-                </row>
-              </tbody>
-            </tgroup>
-          </informaltable>
-          <para>
-            The <command>$GENERATE</command> directive is a <acronym>BIND</acronym> extension
-            and not part of the standard zone file format.
-          </para>
-          <para>
-            BIND 8 does not support the optional TTL and CLASS fields.
-          </para>
-        </sect2>
-
-	<sect2 id="zonefile_format">
-	  <title>Additional File Formats</title>
-	  <para>
-	    In addition to the standard textual format, BIND 9
-	    supports the ability to read or dump to zone files in
-	    other formats.  The <constant>raw</constant> format is
-	    currently available as an additional format.  It is a
-	    binary format representing BIND 9's internal data
-	    structure directly, thereby remarkably improving the
-	    loading time.
-	  </para>
-	  <para>
-	    For a primary server, a zone file in the
-	    <constant>raw</constant> format is expected to be
-	    generated from a textual zone file by the
-	    <command>named-compilezone</command> command.  For a
-	    secondary server or for a dynamic zone, it is automatically
-	    generated (if this format is specified by the
-	    <command>masterfile-format</command> option) when
-	    <command>named</command> dumps the zone contents after
-	    zone transfer or when applying prior updates.
-	  </para>
-	  <para>
-	    If a zone file in a binary format needs manual modification,
-	    it first must be converted to a textual form by the
-	    <command>named-compilezone</command> command.  All
-	    necessary modification should go to the text file, which
-	    should then be converted to the binary form by the
-	    <command>named-compilezone</command> command again.
-	  </para>
-    	  <para>
-	     Although the <constant>raw</constant> format uses the
-	     network byte order and avoids architecture-dependent
-	     data alignment so that it is as much portable as
-	     possible, it is primarily expected to be used inside
-	     the same single system.  In order to export a zone
-	     file in the <constant>raw</constant> format or make a
-	     portable backup of the file, it is recommended to
-	     convert the file to the standard textual representation.
-	  </para>
-	</sect2>
-      </sect1>
-    </chapter>
-    <chapter id="Bv9ARM.ch07">
-      <title><acronym>BIND</acronym> 9 Security Considerations</title>
-      <sect1 id="Access_Control_Lists">
-        <title>Access Control Lists</title>
-        <para>
-          Access Control Lists (ACLs), are address match lists that
-          you can set up and nickname for future use in <command>allow-notify</command>,
-          <command>allow-query</command>, <command>allow-recursion</command>,
-          <command>blackhole</command>, <command>allow-transfer</command>,
-          etc.
-        </para>
-        <para>
-          Using ACLs allows you to have finer control over who can access
-          your name server, without cluttering up your config files with huge
-          lists of IP addresses.
-        </para>
-        <para>
-          It is a <emphasis>good idea</emphasis> to use ACLs, and to
-          control access to your server. Limiting access to your server by
-          outside parties can help prevent spoofing and denial of service (DoS) attacks against
-          your server.
-        </para>
-        <para>
-          Here is an example of how to properly apply ACLs:
-        </para>
-
-<programlisting>
-// Set up an ACL named "bogusnets" that will block RFC1918 space
-// and some reserved space, which is commonly used in spoofing attacks.
-acl bogusnets {
-	0.0.0.0/8; 1.0.0.0/8; 2.0.0.0/8; 192.0.2.0/24; 224.0.0.0/3;
-	10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16;
-};
-
-// Set up an ACL called our-nets. Replace this with the real IP numbers.
-acl our-nets { x.x.x.x/24; x.x.x.x/21; };
-options {
-  ...
-  ...
-  allow-query { our-nets; };
-  allow-recursion { our-nets; };
-  ...
-  blackhole { bogusnets; };
-  ...
-};
-
-zone "example.com" {
-  type master;
-  file "m/example.com";
-  allow-query { any; };
-};
-</programlisting>
-
-        <para>
-          This allows recursive queries of the server from the outside
-          unless recursion has been previously disabled.
-        </para>
-        <para>
-          For more information on how to use ACLs to protect your server,
-          see the <emphasis>AUSCERT</emphasis> advisory at:
-        </para>
-        <para>
-          <ulink url="ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.dns_dos"
-	             >ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.dns_dos</ulink>
-        </para>
-      </sect1>
-      <sect1>
-        <title><command>Chroot</command> and <command>Setuid</command></title>
-        <para>
-          On UNIX servers, it is possible to run <acronym>BIND</acronym> in a <emphasis>chrooted</emphasis> environment
-          (using the <command>chroot()</command> function) by specifying the "<option>-t</option>"
-          option. This can help improve system security by placing <acronym>BIND</acronym> in
-          a "sandbox", which will limit the damage done if a server is
-          compromised.
-        </para>
-        <para>
-          Another useful feature in the UNIX version of <acronym>BIND</acronym> is the
-          ability to run the daemon as an unprivileged user ( <option>-u</option> <replaceable>user</replaceable> ).
-          We suggest running as an unprivileged user when using the <command>chroot</command> feature.
-        </para>
-        <para>
-          Here is an example command line to load <acronym>BIND</acronym> in a <command>chroot</command> sandbox,
-          <command>/var/named</command>, and to run <command>named</command> <command>setuid</command> to
-          user 202:
-        </para>
-        <para>
-          <userinput>/usr/local/bin/named -u 202 -t /var/named</userinput>
-        </para>
-
-        <sect2>
-          <title>The <command>chroot</command> Environment</title>
-
-          <para>
-            In order for a <command>chroot</command> environment
-            to
-            work properly in a particular directory
-            (for example, <filename>/var/named</filename>),
-            you will need to set up an environment that includes everything
-            <acronym>BIND</acronym> needs to run.
-            From <acronym>BIND</acronym>'s point of view, <filename>/var/named</filename> is
-            the root of the filesystem.  You will need to adjust the values of
-            options like
-            like <command>directory</command> and <command>pid-file</command> to account
-            for this.
-          </para>
-          <para>
-            Unlike with earlier versions of BIND, you typically will
-            <emphasis>not</emphasis> need to compile <command>named</command>
-            statically nor install shared libraries under the new root.
-            However, depending on your operating system, you may need
-            to set up things like
-            <filename>/dev/zero</filename>,
-            <filename>/dev/random</filename>,
-            <filename>/dev/log</filename>, and
-            <filename>/etc/localtime</filename>.
-          </para>
-        </sect2>
-
-        <sect2>
-          <title>Using the <command>setuid</command> Function</title>
-
-          <para>
-            Prior to running the <command>named</command> daemon,
-            use
-            the <command>touch</command> utility (to change file
-            access and
-            modification times) or the <command>chown</command>
-            utility (to
-            set the user id and/or group id) on files
-            to which you want <acronym>BIND</acronym>
-            to write.
-          </para>
-	  <note>
-	    Note that if the <command>named</command> daemon is running as an
-            unprivileged user, it will not be able to bind to new restricted
-            ports if the server is reloaded.
-	  </note>
-        </sect2>
-      </sect1>
-
-      <sect1 id="dynamic_update_security">
-        <title>Dynamic Update Security</title>
-
-        <para>
-          Access to the dynamic
-          update facility should be strictly limited.  In earlier versions of
-          <acronym>BIND</acronym>, the only way to do this was
-          based on the IP
-          address of the host requesting the update, by listing an IP address
-          or
-          network prefix in the <command>allow-update</command>
-          zone option.
-          This method is insecure since the source address of the update UDP
-          packet
-          is easily forged.  Also note that if the IP addresses allowed by the
-          <command>allow-update</command> option include the
-          address of a slave
-          server which performs forwarding of dynamic updates, the master can
-          be
-          trivially attacked by sending the update to the slave, which will
-          forward it to the master with its own source IP address causing the
-          master to approve it without question.
-        </para>
-
-        <para>
-          For these reasons, we strongly recommend that updates be
-          cryptographically authenticated by means of transaction signatures
-          (TSIG).  That is, the <command>allow-update</command>
-          option should
-          list only TSIG key names, not IP addresses or network
-          prefixes. Alternatively, the new <command>update-policy</command>
-          option can be used.
-        </para>
-
-        <para>
-          Some sites choose to keep all dynamically-updated DNS data
-          in a subdomain and delegate that subdomain to a separate zone. This
-          way, the top-level zone containing critical data such as the IP
-          addresses
-          of public web and mail servers need not allow dynamic update at
-          all.
-        </para>
-
-      </sect1>
-    </chapter>
-
-    <chapter id="Bv9ARM.ch08">
-      <title>Troubleshooting</title>
-      <sect1>
-        <title>Common Problems</title>
-        <sect2>
-          <title>It's not working; how can I figure out what's wrong?</title>
-
-          <para>
-            The best solution to solving installation and
-            configuration issues is to take preventative measures by setting
-            up logging files beforehand. The log files provide a
-            source of hints and information that can be used to figure out
-            what went wrong and how to fix the problem.
-          </para>
-
-        </sect2>
-      </sect1>
-      <sect1>
-        <title>Incrementing and Changing the Serial Number</title>
-
-	<para>
-	  Zone serial numbers are just numbers &mdash; they aren't
-	  date related.  A lot of people set them to a number that
-	  represents a date, usually of the form YYYYMMDDRR.
-	  Occasionally they will make a mistake and set them to a
-	  "date in the future" then try to correct them by setting
-	  them to the "current date".  This causes problems because
-	  serial numbers are used to indicate that a zone has been
-	  updated.  If the serial number on the slave server is
-	  lower than the serial number on the master, the slave
-	  server will attempt to update its copy of the zone.
-	</para>
-
-        <para>
-          Setting the serial number to a lower number on the master
-          server than the slave server means that the slave will not perform
-          updates to its copy of the zone.
-        </para>
-
-        <para>
-          The solution to this is to add 2147483647 (2^31-1) to the
-          number, reload the zone and make sure all slaves have updated to
-          the new zone serial number, then reset the number to what you want
-          it to be, and reload the zone again.
-        </para>
-
-      </sect1>
-      <sect1>
-        <title>Where Can I Get Help?</title>
-
-        <para>
-          The Internet Systems Consortium
-          (<acronym>ISC</acronym>) offers a wide range
-          of support and service agreements for <acronym>BIND</acronym> and <acronym>DHCP</acronym> servers. Four
-          levels of premium support are available and each level includes
-          support for all <acronym>ISC</acronym> programs,
-          significant discounts on products
-          and training, and a recognized priority on bug fixes and
-          non-funded feature requests. In addition, <acronym>ISC</acronym> offers a standard
-          support agreement package which includes services ranging from bug
-          fix announcements to remote support. It also includes training in
-          <acronym>BIND</acronym> and <acronym>DHCP</acronym>.
-        </para>
-
-        <para>
-          To discuss arrangements for support, contact
-          <ulink url="mailto:info@isc.org">info@isc.org</ulink> or visit the
-          <acronym>ISC</acronym> web page at
-	  <ulink url="http://www.isc.org/services/support/"
-	             >http://www.isc.org/services/support/</ulink>
-          to read more.
-        </para>
-      </sect1>
-    </chapter>
-    <appendix id="Bv9ARM.ch09">
-      <title>Appendices</title>
-      <sect1>
-        <title>Acknowledgments</title>
-        <sect2 id="historical_dns_information">
-          <title>A Brief History of the <acronym>DNS</acronym> and <acronym>BIND</acronym></title>
-
-          <para>
-            Although the "official" beginning of the Domain Name
-            System occurred in 1984 with the publication of RFC 920, the
-            core of the new system was described in 1983 in RFCs 882 and
-            883. From 1984 to 1987, the ARPAnet (the precursor to today's
-            Internet) became a testbed of experimentation for developing the
-            new naming/addressing scheme in a rapidly expanding,
-            operational network environment.  New RFCs were written and
-            published in 1987 that modified the original documents to
-            incorporate improvements based on the working model. RFC 1034,
-            "Domain Names-Concepts and Facilities", and RFC 1035, "Domain
-            Names-Implementation and Specification" were published and
-            became the standards upon which all <acronym>DNS</acronym> implementations are
-            built.
-          </para>
-
-          <para>
-            The first working domain name server, called "Jeeves", was
-            written in 1983-84 by Paul Mockapetris for operation on DEC
-            Tops-20
-            machines located at the University of Southern California's
-            Information
-            Sciences Institute (USC-ISI) and SRI International's Network
-            Information
-            Center (SRI-NIC). A <acronym>DNS</acronym> server for
-            Unix machines, the Berkeley Internet
-            Name Domain (<acronym>BIND</acronym>) package, was
-            written soon after by a group of
-            graduate students at the University of California at Berkeley
-            under
-            a grant from the US Defense Advanced Research Projects
-            Administration
-            (DARPA).
-          </para>
-          <para>
-	    Versions of <acronym>BIND</acronym> through
-            4.8.3 were maintained by the Computer
-            Systems Research Group (CSRG) at UC Berkeley. Douglas Terry, Mark
-            Painter, David Riggle and Songnian Zhou made up the initial <acronym>BIND</acronym>
-            project team. After that, additional work on the software package
-            was done by Ralph Campbell. Kevin Dunlap, a Digital Equipment
-            Corporation
-            employee on loan to the CSRG, worked on <acronym>BIND</acronym> for 2 years, from 1985
-            to 1987. Many other people also contributed to <acronym>BIND</acronym> development
-            during that time: Doug Kingston, Craig Partridge, Smoot
-            Carl-Mitchell,
-            Mike Muuss, Jim Bloom and Mike Schwartz. <acronym>BIND</acronym> maintenance was subsequently
-            handled by Mike Karels and &#216;ivind Kure.
-          </para>
-          <para>
-            <acronym>BIND</acronym> versions 4.9 and 4.9.1 were
-            released by Digital Equipment
-            Corporation (now Compaq Computer Corporation). Paul Vixie, then
-            a DEC employee, became <acronym>BIND</acronym>'s
-            primary caretaker. He was assisted
-            by Phil Almquist, Robert Elz, Alan Barrett, Paul Albitz, Bryan
-            Beecher, Andrew
-            Partan, Andy Cherenson, Tom Limoncelli, Berthold Paffrath, Fuat
-            Baran, Anant Kumar, Art Harkin, Win Treese, Don Lewis, Christophe
-            Wolfhugel, and others.
-          </para>
-          <para>
-            In 1994, <acronym>BIND</acronym> version 4.9.2 was sponsored by
-            Vixie Enterprises. Paul
-            Vixie became <acronym>BIND</acronym>'s principal
-            architect/programmer.
-          </para>
-          <para>
-            <acronym>BIND</acronym> versions from 4.9.3 onward
-            have been developed and maintained
-            by the Internet Systems Consortium and its predecessor,
-            the Internet Software Consortium,  with support being provided
-            by ISC's sponsors.
-          </para>
-	  <para>
-	    As co-architects/programmers, Bob Halley and
-            Paul Vixie released the first production-ready version of
-	    <acronym>BIND</acronym> version 8 in May 1997.
-          </para>
-	  <para>
-	    BIND version 9 was released in September 2000 and is a
-	    major rewrite of nearly all aspects of the underlying
-	    BIND architecture.
-          </para>
-          <para>
-	    BIND version 4 is officially deprecated and BIND version
-	    8 development is considered maintenance-only in favor
-	    of BIND version 9. No additional development is done
-	    on BIND version 4 or BIND version 8 other than for
-	    security-related patches.
-          </para>
-          <para>
-            <acronym>BIND</acronym> development work is made
-            possible today by the sponsorship
-            of several corporations, and by the tireless work efforts of
-            numerous individuals.
-          </para>
-        </sect2>
-      </sect1>
-      <sect1>
-        <title>General <acronym>DNS</acronym> Reference Information</title>
-        <sect2 id="ipv6addresses">
-          <title>IPv6 addresses (AAAA)</title>
-          <para>
-            IPv6 addresses are 128-bit identifiers for interfaces and
-            sets of interfaces which were introduced in the <acronym>DNS</acronym> to facilitate
-            scalable Internet routing. There are three types of addresses: <emphasis>Unicast</emphasis>,
-            an identifier for a single interface;
-            <emphasis>Anycast</emphasis>,
-            an identifier for a set of interfaces; and <emphasis>Multicast</emphasis>,
-            an identifier for a set of interfaces. Here we describe the global
-            Unicast address scheme. For more information, see RFC 3587,
-	    "Global Unicast Address Format."
-          </para>
-          <para>
-	    IPv6 unicast addresses consist of a
-	    <emphasis>global routing prefix</emphasis>, a
-	    <emphasis>subnet identifier</emphasis>, and an
-	    <emphasis>interface identifier</emphasis>.
-          </para>
-          <para>
-            The global routing prefix is provided by the
-            upstream provider or ISP, and (roughly) corresponds to the
-	    IPv4 <emphasis>network</emphasis> section
-            of the address range.
-
-	    The subnet identifier is for local subnetting, much the
-            same as subnetting an
-            IPv4 /16 network into /24 subnets.
-
-	    The interface identifier is the address of an individual
-            interface on a given network; in IPv6, addresses belong to
-            interfaces rather than to machines.
-          </para>
-          <para>
-            The subnetting capability of IPv6 is much more flexible than
-            that of IPv4: subnetting can be carried out on bit boundaries,
-            in much the same way as Classless InterDomain Routing
-            (CIDR), and the DNS PTR representation ("nibble" format)
-            makes setting up reverse zones easier.
-          </para>
-          <para>
-            The Interface Identifier must be unique on the local link,
-            and is usually generated automatically by the IPv6
-            implementation, although it is usually possible to
-            override the default setting if necessary.  A typical IPv6
-            address might look like:
-	    <command>2001:db8:201:9:a00:20ff:fe81:2b32</command>
-	  </para>
-          <para>
-            IPv6 address specifications often contain long strings
-            of zeros, so the architects have included a shorthand for
-            specifying
-            them. The double colon (`::') indicates the longest possible
-            string
-            of zeros that can fit, and can be used only once in an address.
-          </para>
-        </sect2>
-      </sect1>
-      <sect1 id="bibliography">
-        <title>Bibliography (and Suggested Reading)</title>
-        <sect2 id="rfcs">
-          <title>Request for Comments (RFCs)</title>
-          <para>
-            Specification documents for the Internet protocol suite, including
-            the <acronym>DNS</acronym>, are published as part of
-            the Request for Comments (RFCs)
-            series of technical notes. The standards themselves are defined
-            by the Internet Engineering Task Force (IETF) and the Internet
-            Engineering Steering Group (IESG). RFCs can be obtained online via FTP at:
-	  </para>
-	  <para>
-            <ulink url="ftp://www.isi.edu/in-notes/">
-	      ftp://www.isi.edu/in-notes/RFC<replaceable>xxxx</replaceable>.txt
-	    </ulink>
-	  </para>
-	  <para>
-	    (where <replaceable>xxxx</replaceable> is
-            the number of the RFC). RFCs are also available via the Web at:
-	  </para>
-	  <para>
-            <ulink url="http://www.ietf.org/rfc/"
-	               >http://www.ietf.org/rfc/</ulink>.
-          </para>
-          <bibliography>
-            <bibliodiv>
-              <!-- one of (BIBLIOENTRY BIBLIOMIXED) -->
-              <title>Standards</title>
-              <biblioentry>
-                <abbrev>RFC974</abbrev>
-                <author>
-                  <surname>Partridge</surname>
-                  <firstname>C.</firstname>
-                </author>
-                <title>Mail Routing and the Domain System</title>
-                <pubdate>January 1986</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC1034</abbrev>
-                <author>
-                  <surname>Mockapetris</surname>
-                  <firstname>P.V.</firstname>
-                </author>
-                <title>Domain Names &mdash; Concepts and Facilities</title>
-                <pubdate>November 1987</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC1035</abbrev>
-                <author>
-                  <surname>Mockapetris</surname>
-                  <firstname>P. V.</firstname>
-                  </author> <title>Domain Names &mdash; Implementation and
-                  Specification</title>
-                <pubdate>November 1987</pubdate>
-              </biblioentry>
-            </bibliodiv>
-            <bibliodiv id="proposed_standards" xreflabel="Proposed Standards">
-
-              <title>Proposed Standards</title>
-              <!-- one of (BIBLIOENTRY BIBLIOMIXED) -->
-              <biblioentry>
-                <abbrev>RFC2181</abbrev>
-                <author>
-                  <surname>Elz</surname>
-                  <firstname>R., R. Bush</firstname>
-                </author>
-                <title>Clarifications to the <acronym>DNS</acronym>
-                  Specification</title>
-                <pubdate>July 1997</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC2308</abbrev>
-                <author>
-                  <surname>Andrews</surname>
-                  <firstname>M.</firstname>
-                </author>
-                <title>Negative Caching of <acronym>DNS</acronym>
-                  Queries</title>
-                <pubdate>March 1998</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC1995</abbrev>
-                <author>
-                  <surname>Ohta</surname>
-                  <firstname>M.</firstname>
-                </author>
-                <title>Incremental Zone Transfer in <acronym>DNS</acronym></title>
-                <pubdate>August 1996</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC1996</abbrev>
-                <author>
-                  <surname>Vixie</surname>
-                  <firstname>P.</firstname>
-                </author>
-                <title>A Mechanism for Prompt Notification of Zone Changes</title>
-                <pubdate>August 1996</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC2136</abbrev>
-                <authorgroup>
-                  <author>
-                    <surname>Vixie</surname>
-                    <firstname>P.</firstname>
-                  </author>
-                  <author>
-                    <firstname>S.</firstname>
-                    <surname>Thomson</surname>
-                  </author>
-                  <author>
-                    <firstname>Y.</firstname>
-                    <surname>Rekhter</surname>
-                  </author>
-                  <author>
-                    <firstname>J.</firstname>
-                    <surname>Bound</surname>
-                  </author>
-                </authorgroup>
-                <title>Dynamic Updates in the Domain Name System</title>
-                <pubdate>April 1997</pubdate>
-              </biblioentry>
-	      <biblioentry>
-                <abbrev>RFC2671</abbrev>
-                <authorgroup>
-                  <author>
-                    <firstname>P.</firstname>
-                    <surname>Vixie</surname>
-                  </author>
-                </authorgroup>
-                <title>Extension Mechanisms for DNS (EDNS0)</title>
-                <pubdate>August 1997</pubdate>
-	      </biblioentry>
-	      <biblioentry>
-                <abbrev>RFC2672</abbrev>
-                <authorgroup>
-                  <author>
-                    <firstname>M.</firstname>
-                    <surname>Crawford</surname>
-                  </author>
-                </authorgroup>
-                <title>Non-Terminal DNS Name Redirection</title>
-                <pubdate>August 1999</pubdate>
-	      </biblioentry>
-              <biblioentry>
-                <abbrev>RFC2845</abbrev>
-                <authorgroup>
-                  <author>
-                    <surname>Vixie</surname>
-                    <firstname>P.</firstname>
-                  </author>
-                  <author>
-                    <firstname>O.</firstname>
-                    <surname>Gudmundsson</surname>
-                  </author>
-                  <author>
-                    <firstname>D.</firstname>
-                    <surname>Eastlake</surname>
-                    <lineage>3rd</lineage>
-                  </author>
-                  <author>
-                    <firstname>B.</firstname>
-                    <surname>Wellington</surname>
-                  </author>
-                </authorgroup>
-                <title>Secret Key Transaction Authentication for <acronym>DNS</acronym> (TSIG)</title>
-                <pubdate>May 2000</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC2930</abbrev>
-                <authorgroup>
-                  <author>
-                    <firstname>D.</firstname>
-                    <surname>Eastlake</surname>
-                    <lineage>3rd</lineage>
-                  </author>
-                </authorgroup>
-                <title>Secret Key Establishment for DNS (TKEY RR)</title>
-                <pubdate>September 2000</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC2931</abbrev>
-                <authorgroup>
-                  <author>
-                    <firstname>D.</firstname>
-                    <surname>Eastlake</surname>
-                    <lineage>3rd</lineage>
-                  </author>
-                </authorgroup>
-                <title>DNS Request and Transaction Signatures (SIG(0)s)</title>
-                <pubdate>September 2000</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC3007</abbrev>
-                <authorgroup>
-                  <author>
-                    <firstname>B.</firstname>
-                    <surname>Wellington</surname>
-                  </author>
-                </authorgroup>
-                <title>Secure Domain Name System (DNS) Dynamic Update</title>
-                <pubdate>November 2000</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC3645</abbrev>
-                <authorgroup>
-                  <author>
-                    <firstname>S.</firstname>
-                    <surname>Kwan</surname>
-                  </author>
-                  <author>
-                    <firstname>P.</firstname>
-                    <surname>Garg</surname>
-                  </author>
-                  <author>
-                    <firstname>J.</firstname>
-                    <surname>Gilroy</surname>
-                  </author>
-                  <author>
-                    <firstname>L.</firstname>
-                    <surname>Esibov</surname>
-                  </author>
-                  <author>
-                    <firstname>J.</firstname>
-                    <surname>Westhead</surname>
-                  </author>
-                  <author>
-                    <firstname>R.</firstname>
-                    <surname>Hall</surname>
-                  </author>
-                </authorgroup>
-                <title>Generic Security Service Algorithm for Secret
-		       Key Transaction Authentication for DNS
-		       (GSS-TSIG)</title>
-                <pubdate>October 2003</pubdate>
-              </biblioentry>
-            </bibliodiv>
-	    <bibliodiv>
-	      <title><acronym>DNS</acronym> Security Proposed Standards</title>
-	      <biblioentry>
-		<abbrev>RFC3225</abbrev>
-	 	<authorgroup>
-		  <author>
-		    <firstname>D.</firstname>
-		    <surname>Conrad</surname>
-		  </author>
-	 	</authorgroup>
-		<title>Indicating Resolver Support of DNSSEC</title>
-		<pubdate>December 2001</pubdate>
-	      </biblioentry>
-	      <biblioentry>
-	        <abbrev>RFC3833</abbrev>
-	 	<authorgroup>
-		  <author>
-		    <firstname>D.</firstname>
-		    <surname>Atkins</surname>
-		  </author>
-		  <author>
-		    <firstname>R.</firstname>
-		    <surname>Austein</surname>
-		  </author>
-		</authorgroup>
-		<title>Threat Analysis of the Domain Name System (DNS)</title>
-		<pubdate>August 2004</pubdate>
-	      </biblioentry>
-	      <biblioentry>
-	        <abbrev>RFC4033</abbrev>
-	 	<authorgroup>
-		  <author>
-		    <firstname>R.</firstname>
-		    <surname>Arends</surname>
-		  </author>
-		  <author>
-		    <firstname>R.</firstname>
-		    <surname>Austein</surname>
-		  </author>
-		  <author>
-		    <firstname>M.</firstname>
-		    <surname>Larson</surname>
-		  </author>
-		  <author>
-		    <firstname>D.</firstname>
-		    <surname>Massey</surname>
-		  </author>
-		  <author>
-		    <firstname>S.</firstname>
-		    <surname>Rose</surname>
-		  </author>
-		</authorgroup>
-		<title>DNS Security Introduction and Requirements</title>
-		<pubdate>March 2005</pubdate>
-	      </biblioentry>
-	      <biblioentry>
-	        <abbrev>RFC4044</abbrev>
-	 	<authorgroup>
-		  <author>
-		    <firstname>R.</firstname>
-		    <surname>Arends</surname>
-		  </author>
-		  <author>
-		    <firstname>R.</firstname>
-		    <surname>Austein</surname>
-		  </author>
-		  <author>
-		    <firstname>M.</firstname>
-		    <surname>Larson</surname>
-		  </author>
-		  <author>
-		    <firstname>D.</firstname>
-		    <surname>Massey</surname>
-		  </author>
-		  <author>
-		    <firstname>S.</firstname>
-		    <surname>Rose</surname>
-		  </author>
-		</authorgroup>
-		<title>Resource Records for the DNS Security Extensions</title>
-		<pubdate>March 2005</pubdate>
-	      </biblioentry>
-	      <biblioentry>
-	        <abbrev>RFC4035</abbrev>
-	 	<authorgroup>
-		  <author>
-		    <firstname>R.</firstname>
-		    <surname>Arends</surname>
-		  </author>
-		  <author>
-		    <firstname>R.</firstname>
-		    <surname>Austein</surname>
-		  </author>
-		  <author>
-		    <firstname>M.</firstname>
-		    <surname>Larson</surname>
-		  </author>
-		  <author>
-		    <firstname>D.</firstname>
-		    <surname>Massey</surname>
-		  </author>
-		  <author>
-		    <firstname>S.</firstname>
-		    <surname>Rose</surname>
-		  </author>
-		</authorgroup>
-		<title>Protocol Modifications for the DNS
-		       Security Extensions</title>
-		<pubdate>March 2005</pubdate>
-	      </biblioentry>
-            </bibliodiv>
-            <bibliodiv>
-              <title>Other Important RFCs About <acronym>DNS</acronym>
-                Implementation</title>
-              <biblioentry>
-                <abbrev>RFC1535</abbrev>
-                <author>
-                  <surname>Gavron</surname>
-                  <firstname>E.</firstname>
-                </author>
-                <title>A Security Problem and Proposed Correction With Widely
-                  Deployed <acronym>DNS</acronym> Software.</title>
-                <pubdate>October 1993</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC1536</abbrev>
-                <authorgroup>
-                  <author>
-                    <surname>Kumar</surname>
-                    <firstname>A.</firstname>
-                  </author>
-                  <author>
-                    <firstname>J.</firstname>
-                    <surname>Postel</surname>
-                  </author>
-                  <author>
-                    <firstname>C.</firstname>
-                    <surname>Neuman</surname>
-                  </author>
-                  <author>
-                    <firstname>P.</firstname>
-                    <surname>Danzig</surname>
-                  </author>
-                  <author>
-                    <firstname>S.</firstname>
-                    <surname>Miller</surname>
-                  </author>
-                </authorgroup>
-                <title>Common <acronym>DNS</acronym> Implementation
-                  Errors and Suggested Fixes</title>
-                <pubdate>October 1993</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC1982</abbrev>
-                <authorgroup>
-                  <author>
-                    <surname>Elz</surname>
-                    <firstname>R.</firstname>
-                  </author>
-                  <author>
-                    <firstname>R.</firstname>
-                    <surname>Bush</surname>
-                  </author>
-                </authorgroup>
-                <title>Serial Number Arithmetic</title>
-                <pubdate>August 1996</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC4074</abbrev>
-                <authorgroup>
-                  <author>
-                    <surname>Morishita</surname>
-                    <firstname>Y.</firstname>
-                  </author>
-                  <author>
-                    <firstname>T.</firstname>
-                    <surname>Jinmei</surname>
-                  </author>
-                </authorgroup>
-                <title>Common Misbehaviour Against <acronym>DNS</acronym>
-		Queries for IPv6 Addresses</title>
-                <pubdate>May 2005</pubdate>
-              </biblioentry>
-            </bibliodiv>
-            <bibliodiv>
-              <title>Resource Record Types</title>
-              <biblioentry>
-                <abbrev>RFC1183</abbrev>
-                <authorgroup>
-                  <author>
-                    <surname>Everhart</surname>
-                    <firstname>C.F.</firstname>
-                  </author>
-                  <author>
-                    <firstname>L. A.</firstname>
-                    <surname>Mamakos</surname>
-                  </author>
-                  <author>
-                    <firstname>R.</firstname>
-                    <surname>Ullmann</surname>
-                  </author>
-                  <author>
-                    <firstname>P.</firstname>
-                    <surname>Mockapetris</surname>
-                  </author>
-                </authorgroup>
-                <title>New <acronym>DNS</acronym> RR Definitions</title>
-                <pubdate>October 1990</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC1706</abbrev>
-                <authorgroup>
-                  <author>
-                    <surname>Manning</surname>
-                    <firstname>B.</firstname>
-                  </author>
-                  <author>
-                    <firstname>R.</firstname>
-                    <surname>Colella</surname>
-                  </author>
-                </authorgroup>
-                <title><acronym>DNS</acronym> NSAP Resource Records</title>
-                <pubdate>October 1994</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC2168</abbrev>
-                <authorgroup>
-                  <author>
-                    <surname>Daniel</surname>
-                    <firstname>R.</firstname>
-                  </author>
-                  <author>
-                    <firstname>M.</firstname>
-                    <surname>Mealling</surname>
-                  </author>
-                </authorgroup>
-                <title>Resolution of Uniform Resource Identifiers using
-                  the Domain Name System</title>
-                <pubdate>June 1997</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC1876</abbrev>
-                <authorgroup>
-                  <author>
-                    <surname>Davis</surname>
-                    <firstname>C.</firstname>
-                  </author>
-                  <author>
-                    <firstname>P.</firstname>
-                    <surname>Vixie</surname>
-                  </author>
-                  <author>
-                    <firstname>T.</firstname>
-                    <firstname>Goodwin</firstname>
-                  </author>
-                  <author>
-                    <firstname>I.</firstname>
-                    <surname>Dickinson</surname>
-                  </author>
-                </authorgroup>
-                <title>A Means for Expressing Location Information in the
-                  Domain
-                  Name System</title>
-                <pubdate>January 1996</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC2052</abbrev>
-                <authorgroup>
-                  <author>
-                    <surname>Gulbrandsen</surname>
-                    <firstname>A.</firstname>
-                  </author>
-                  <author>
-                    <firstname>P.</firstname>
-                    <surname>Vixie</surname>
-                  </author>
-                </authorgroup>
-                <title>A <acronym>DNS</acronym> RR for Specifying the
-                  Location of
-                  Services.</title>
-                <pubdate>October 1996</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC2163</abbrev>
-                <author>
-                  <surname>Allocchio</surname>
-                  <firstname>A.</firstname>
-                </author>
-                <title>Using the Internet <acronym>DNS</acronym> to
-                  Distribute MIXER
-                  Conformant Global Address Mapping</title>
-                <pubdate>January 1998</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC2230</abbrev>
-                <author>
-                  <surname>Atkinson</surname>
-                  <firstname>R.</firstname>
-                </author>
-                <title>Key Exchange Delegation Record for the <acronym>DNS</acronym></title>
-                <pubdate>October 1997</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC2536</abbrev>
-                <author>
-                  <surname>Eastlake</surname>
-                  <firstname>D.</firstname>
-                  <lineage>3rd</lineage>
-                </author>
-                <title>DSA KEYs and SIGs in the Domain Name System (DNS)</title>
-                <pubdate>March 1999</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC2537</abbrev>
-                <author>
-                  <surname>Eastlake</surname>
-                  <firstname>D.</firstname>
-                  <lineage>3rd</lineage>
-                </author>
-                <title>RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)</title>
-                <pubdate>March 1999</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC2538</abbrev>
-		<authorgroup>
-                  <author>
-                    <surname>Eastlake</surname>
-                    <firstname>D.</firstname>
-                    <lineage>3rd</lineage>
-                  </author>
-		  <author>
-		    <surname>Gudmundsson</surname>
-		    <firstname>O.</firstname>
-		  </author>
-		</authorgroup>
-                <title>Storing Certificates in the Domain Name System (DNS)</title>
-                <pubdate>March 1999</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC2539</abbrev>
-		<authorgroup>
-                  <author>
-                    <surname>Eastlake</surname>
-                    <firstname>D.</firstname>
-                    <lineage>3rd</lineage>
-                  </author>
-		</authorgroup>
-                <title>Storage of Diffie-Hellman Keys in the Domain Name System (DNS)</title>
-                <pubdate>March 1999</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC2540</abbrev>
-		<authorgroup>
-                  <author>
-                    <surname>Eastlake</surname>
-                    <firstname>D.</firstname>
-                    <lineage>3rd</lineage>
-                  </author>
-		</authorgroup>
-                <title>Detached Domain Name System (DNS) Information</title>
-                <pubdate>March 1999</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC2782</abbrev>
-                <author>
-                  <surname>Gulbrandsen</surname>
-                  <firstname>A.</firstname>
-                </author>
-                <author>
-                  <surname>Vixie</surname>
-                  <firstname>P.</firstname>
-                </author>
-                <author>
-                  <surname>Esibov</surname>
-                  <firstname>L.</firstname>
-                </author>
-                <title>A DNS RR for specifying the location of services (DNS SRV)</title>
-                <pubdate>February 2000</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC2915</abbrev>
-                <author>
-                  <surname>Mealling</surname>
-                  <firstname>M.</firstname>
-                </author>
-                <author>
-                  <surname>Daniel</surname>
-                  <firstname>R.</firstname>
-                </author>
-                <title>The Naming Authority Pointer (NAPTR) DNS Resource Record</title>
-                <pubdate>September 2000</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC3110</abbrev>
-                <author>
-                    <surname>Eastlake</surname>
-                    <firstname>D.</firstname>
-                    <lineage>3rd</lineage>
-                </author>
-                <title>RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)</title>
-                <pubdate>May 2001</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC3123</abbrev>
-                <author>
-                  <surname>Koch</surname>
-                  <firstname>P.</firstname>
-                </author>
-                <title>A DNS RR Type for Lists of Address Prefixes (APL RR)</title>
-                <pubdate>June 2001</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC3596</abbrev>
-                <authorgroup>
-                  <author>
-                    <surname>Thomson</surname>
-                    <firstname>S.</firstname>
-                  </author>
-                  <author>
-                    <firstname>C.</firstname>
-                    <surname>Huitema</surname>
-                  </author>
-                  <author>
-                    <firstname>V.</firstname>
-                    <surname>Ksinant</surname>
-                  </author>
-                  <author>
-                    <firstname>M.</firstname>
-                    <surname>Souissi</surname>
-                  </author>
-                </authorgroup>
-                <title><acronym>DNS</acronym> Extensions to support IP
-                  version 6</title>
-                <pubdate>October 2003</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC3597</abbrev>
-                <author>
-                  <surname>Gustafsson</surname>
-                  <firstname>A.</firstname>
-                </author>
-                <title>Handling of Unknown DNS Resource Record (RR) Types</title>
-                <pubdate>September 2003</pubdate>
-              </biblioentry>
-            </bibliodiv>
-            <bibliodiv>
-              <title><acronym>DNS</acronym> and the Internet</title>
-              <biblioentry>
-                <abbrev>RFC1101</abbrev>
-                <author>
-                  <surname>Mockapetris</surname>
-                  <firstname>P. V.</firstname>
-                </author>
-                <title><acronym>DNS</acronym> Encoding of Network Names
-                  and Other Types</title>
-                <pubdate>April 1989</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC1123</abbrev>
-                <author>
-                  <surname>Braden</surname>
-                  <surname>R.</surname>
-                </author>
-                <title>Requirements for Internet Hosts - Application and
-                  Support</title>
-                <pubdate>October 1989</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC1591</abbrev>
-                <author>
-                  <surname>Postel</surname>
-                  <firstname>J.</firstname>
-                </author>
-                <title>Domain Name System Structure and Delegation</title>
-                <pubdate>March 1994</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC2317</abbrev>
-                <authorgroup>
-                  <author>
-                    <surname>Eidnes</surname>
-                    <firstname>H.</firstname>
-                  </author>
-                  <author>
-                    <firstname>G.</firstname>
-                    <surname>de Groot</surname>
-                  </author>
-                  <author>
-                    <firstname>P.</firstname>
-                    <surname>Vixie</surname>
-                  </author>
-                </authorgroup>
-                <title>Classless IN-ADDR.ARPA Delegation</title>
-                <pubdate>March 1998</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC2826</abbrev>
-                <authorgroup>
-                  <author>
-                    <surname>Internet Architecture Board</surname>
-                  </author>
-                </authorgroup>
-                <title>IAB Technical Comment on the Unique DNS Root</title>
-                <pubdate>May 2000</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC2929</abbrev>
-                <authorgroup>
-                  <author>
-                    <surname>Eastlake</surname>
-                    <firstname>D.</firstname>
-                    <lineage>3rd</lineage>
-                  </author>
-                  <author>
-                    <surname>Brunner-Williams</surname>
-                    <firstname>E.</firstname>
-                  </author>
-                  <author>
-                    <surname>Manning</surname>
-                    <firstname>B.</firstname>
-                  </author>
-                </authorgroup>
-                <title>Domain Name System (DNS) IANA Considerations</title>
-                <pubdate>September 2000</pubdate>
-              </biblioentry>
-            </bibliodiv>
-            <bibliodiv>
-              <title><acronym>DNS</acronym> Operations</title>
-              <biblioentry>
-                <abbrev>RFC1033</abbrev>
-                <author>
-                  <surname>Lottor</surname>
-                  <firstname>M.</firstname>
-                </author>
-                <title>Domain administrators operations guide.</title>
-                <pubdate>November 1987</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC1537</abbrev>
-                <author>
-                  <surname>Beertema</surname>
-                  <firstname>P.</firstname>
-                </author>
-                <title>Common <acronym>DNS</acronym> Data File
-                  Configuration Errors</title>
-                <pubdate>October 1993</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC1912</abbrev>
-                <author>
-                  <surname>Barr</surname>
-                  <firstname>D.</firstname>
-                </author>
-                <title>Common <acronym>DNS</acronym> Operational and
-                  Configuration Errors</title>
-                <pubdate>February 1996</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC2010</abbrev>
-                <authorgroup>
-                  <author>
-                    <surname>Manning</surname>
-                    <firstname>B.</firstname>
-                  </author>
-                  <author>
-                    <firstname>P.</firstname>
-                    <surname>Vixie</surname>
-                  </author>
-                </authorgroup>
-                <title>Operational Criteria for Root Name Servers.</title>
-                <pubdate>October 1996</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC2219</abbrev>
-                <authorgroup>
-                  <author>
-                    <surname>Hamilton</surname>
-                    <firstname>M.</firstname>
-                  </author>
-                  <author>
-                    <firstname>R.</firstname>
-                    <surname>Wright</surname>
-                  </author>
-                </authorgroup>
-                <title>Use of <acronym>DNS</acronym> Aliases for
-                  Network Services.</title>
-                <pubdate>October 1997</pubdate>
-              </biblioentry>
-            </bibliodiv>
-	    <bibliodiv>
-              <title>Internationalized Domain Names</title>
-              <biblioentry>
-                <abbrev>RFC2825</abbrev>
-		<authorgroup>
-                  <author>
-                    <surname>IAB</surname>
-                  </author>
-                  <author>
-                    <surname>Daigle</surname>
-                    <firstname>R.</firstname>
-                  </author>
-		</authorgroup>
-                <title>A Tangled Web: Issues of I18N, Domain Names,
-		       and the Other Internet protocols</title>
-                <pubdate>May 2000</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC3490</abbrev>
-		<authorgroup>
-                  <author>
-                    <surname>Faltstrom</surname>
-                    <firstname>P.</firstname>
-                  </author>
-                  <author>
-                    <surname>Hoffman</surname>
-                    <firstname>P.</firstname>
-                  </author>
-                  <author>
-                    <surname>Costello</surname>
-                    <firstname>A.</firstname>
-                  </author>
-		</authorgroup>
-                <title>Internationalizing Domain Names in Applications (IDNA)</title>
-                <pubdate>March 2003</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC3491</abbrev>
-		<authorgroup>
-                  <author>
-                    <surname>Hoffman</surname>
-                    <firstname>P.</firstname>
-                  </author>
-                  <author>
-                    <surname>Blanchet</surname>
-                    <firstname>M.</firstname>
-                  </author>
-		</authorgroup>
-                <title>Nameprep: A Stringprep Profile for Internationalized Domain Names</title>
-                <pubdate>March 2003</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC3492</abbrev>
-		<authorgroup>
-                  <author>
-                    <surname>Costello</surname>
-                    <firstname>A.</firstname>
-                  </author>
-		</authorgroup>
-                <title>Punycode: A Bootstring encoding of Unicode
-		       for Internationalized Domain Names in
-		       Applications (IDNA)</title>
-                <pubdate>March 2003</pubdate>
-              </biblioentry>
-	    </bibliodiv>
-            <bibliodiv>
-              <title>Other <acronym>DNS</acronym>-related RFCs</title>
-              <note>
-                <para>
-                  Note: the following list of RFCs, although
-                  <acronym>DNS</acronym>-related, are not
-                  concerned with implementing software.
-                </para>
-              </note>
-              <biblioentry>
-                <abbrev>RFC1464</abbrev>
-                <author>
-                  <surname>Rosenbaum</surname>
-                  <firstname>R.</firstname>
-                </author>
-                <title>Using the Domain Name System To Store Arbitrary String
-                  Attributes</title>
-                <pubdate>May 1993</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC1713</abbrev>
-                <author>
-                  <surname>Romao</surname>
-                  <firstname>A.</firstname>
-                </author>
-                <title>Tools for <acronym>DNS</acronym> Debugging</title>
-                <pubdate>November 1994</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC1794</abbrev>
-                <author>
-                  <surname>Brisco</surname>
-                  <firstname>T.</firstname>
-                </author>
-                <title><acronym>DNS</acronym> Support for Load
-                  Balancing</title>
-                <pubdate>April 1995</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC2240</abbrev>
-                <author>
-                  <surname>Vaughan</surname>
-                  <firstname>O.</firstname>
-                </author>
-                <title>A Legal Basis for Domain Name Allocation</title>
-                <pubdate>November 1997</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC2345</abbrev>
-                <authorgroup>
-                  <author>
-                    <surname>Klensin</surname>
-                    <firstname>J.</firstname>
-                  </author>
-                  <author>
-                    <firstname>T.</firstname>
-                    <surname>Wolf</surname>
-                  </author>
-                  <author>
-                    <firstname>G.</firstname>
-                    <surname>Oglesby</surname>
-                  </author>
-                </authorgroup>
-                <title>Domain Names and Company Name Retrieval</title>
-                <pubdate>May 1998</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC2352</abbrev>
-                <author>
-                  <surname>Vaughan</surname>
-                  <firstname>O.</firstname>
-                </author>
-                <title>A Convention For Using Legal Names as Domain Names</title>
-                <pubdate>May 1998</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC3071</abbrev>
-                <authorgroup>
-                  <author>
-                    <surname>Klensin</surname>
-                    <firstname>J.</firstname>
-                  </author>
-                </authorgroup>
-                <title>Reflections on the DNS, RFC 1591, and Categories of Domains</title>
-                <pubdate>February 2001</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC3258</abbrev>
-                <authorgroup>
-                  <author>
-                    <surname>Hardie</surname>
-                    <firstname>T.</firstname>
-                  </author>
-                </authorgroup>
-                <title>Distributing Authoritative Name Servers via
-		       Shared Unicast Addresses</title>
-                <pubdate>April 2002</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC3901</abbrev>
-                <authorgroup>
-                  <author>
-                    <surname>Durand</surname>
-                    <firstname>A.</firstname>
-                  </author>
-                  <author>
-                    <firstname>J.</firstname>
-                    <surname>Ihren</surname>
-                  </author>
-                </authorgroup>
-                <title>DNS IPv6 Transport Operational Guidelines</title>
-                <pubdate>September 2004</pubdate>
-              </biblioentry>
-            </bibliodiv>
-            <bibliodiv>
-              <title>Obsolete and Unimplemented Experimental RFC</title>
-              <biblioentry>
-                <abbrev>RFC1712</abbrev>
-                <authorgroup>
-                  <author>
-                    <surname>Farrell</surname>
-                    <firstname>C.</firstname>
-                  </author>
-                  <author>
-                    <firstname>M.</firstname>
-                    <surname>Schulze</surname>
-                  </author>
-                  <author>
-                    <firstname>S.</firstname>
-                    <surname>Pleitner</surname>
-                  </author>
-                  <author>
-                    <firstname>D.</firstname>
-                    <surname>Baldoni</surname>
-                  </author>
-                </authorgroup>
-                <title><acronym>DNS</acronym> Encoding of Geographical
-                  Location</title>
-                <pubdate>November 1994</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC2673</abbrev>
-                <authorgroup>
-                  <author>
-                    <surname>Crawford</surname>
-                    <firstname>M.</firstname>
-                  </author>
-                </authorgroup>
-                <title>Binary Labels in the Domain Name System</title>
-                <pubdate>August 1999</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC2874</abbrev>
-                <authorgroup>
-                  <author>
-                    <surname>Crawford</surname>
-                    <firstname>M.</firstname>
-                  </author>
-                  <author>
-                    <surname>Huitema</surname>
-                    <firstname>C.</firstname>
-                  </author>
-                </authorgroup>
-                <title>DNS Extensions to Support IPv6 Address Aggregation
-		       and Renumbering</title>
-                <pubdate>July 2000</pubdate>
-              </biblioentry>
-            </bibliodiv>
-            <bibliodiv>
-              <title>Obsoleted DNS Security RFCs</title>
-	      <note>
-		<para>
-		  Most of these have been consolidated into RFC4033,
-		  RFC4034 and RFC4035 which collectively describe DNSSECbis.
-		</para>
-	      </note>
-              <biblioentry>
-                <abbrev>RFC2065</abbrev>
-                <authorgroup>
-                  <author>
-                    <surname>Eastlake</surname>
-                    <lineage>3rd</lineage>
-                    <firstname>D.</firstname>
-                  </author>
-                  <author>
-                    <firstname>C.</firstname>
-                    <surname>Kaufman</surname>
-                  </author>
-                </authorgroup>
-                <title>Domain Name System Security Extensions</title>
-                <pubdate>January 1997</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC2137</abbrev>
-                <author>
-                  <surname>Eastlake</surname>
-                  <lineage>3rd</lineage>
-                  <firstname>D.</firstname>
-                </author>
-                <title>Secure Domain Name System Dynamic Update</title>
-                <pubdate>April 1997</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC2535</abbrev>
-                <authorgroup>
-                  <author>
-                    <surname>Eastlake</surname>
-                    <lineage>3rd</lineage>
-                    <firstname>D.</firstname>
-                  </author>
-                </authorgroup>
-                <title>Domain Name System Security Extensions</title>
-                <pubdate>March 1999</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC3008</abbrev>
-                <authorgroup>
-                  <author>
-                    <surname>Wellington</surname>
-                    <firstname>B.</firstname>
-                  </author>
-                </authorgroup>
-                <title>Domain Name System Security (DNSSEC)
-		       Signing Authority</title>
-                <pubdate>November 2000</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC3090</abbrev>
-                <authorgroup>
-                  <author>
-                    <surname>Lewis</surname>
-                    <firstname>E.</firstname>
-                  </author>
-                </authorgroup>
-                <title>DNS Security Extension Clarification on Zone Status</title>
-                <pubdate>March 2001</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC3445</abbrev>
-                <authorgroup>
-                  <author>
-                    <surname>Massey</surname>
-                    <firstname>D.</firstname>
-                  </author>
-                  <author>
-                    <surname>Rose</surname>
-                    <firstname>S.</firstname>
-                  </author>
-                </authorgroup>
-                <title>Limiting the Scope of the KEY Resource Record (RR)</title>
-                <pubdate>December 2002</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC3655</abbrev>
-                <authorgroup>
-                  <author>
-                    <surname>Wellington</surname>
-                    <firstname>B.</firstname>
-                  </author>
-                  <author>
-                    <surname>Gudmundsson</surname>
-                    <firstname>O.</firstname>
-                  </author>
-                </authorgroup>
-                <title>Redefinition of DNS Authenticated Data (AD) bit</title>
-                <pubdate>November 2003</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC3658</abbrev>
-                <authorgroup>
-                  <author>
-                    <surname>Gudmundsson</surname>
-                    <firstname>O.</firstname>
-                  </author>
-                </authorgroup>
-                <title>Delegation Signer (DS) Resource Record (RR)</title>
-                <pubdate>December 2003</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC3755</abbrev>
-                <authorgroup>
-                  <author>
-                    <surname>Weiler</surname>
-                    <firstname>S.</firstname>
-                  </author>
-                </authorgroup>
-                <title>Legacy Resolver Compatibility for Delegation Signer (DS)</title>
-                <pubdate>May 2004</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC3757</abbrev>
-                <authorgroup>
-                  <author>
-                    <surname>Kolkman</surname>
-                    <firstname>O.</firstname>
-                  </author>
-                  <author>
-                    <surname>Schlyter</surname>
-                    <firstname>J.</firstname>
-                  </author>
-                  <author>
-                    <surname>Lewis</surname>
-                    <firstname>E.</firstname>
-                  </author>
-                </authorgroup>
-                <title>Domain Name System KEY (DNSKEY) Resource Record
-		      (RR) Secure Entry Point (SEP) Flag</title>
-                <pubdate>April 2004</pubdate>
-              </biblioentry>
-              <biblioentry>
-                <abbrev>RFC3845</abbrev>
-                <authorgroup>
-                  <author>
-                    <surname>Schlyter</surname>
-                    <firstname>J.</firstname>
-                  </author>
-                </authorgroup>
-                <title>DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format</title>
-                <pubdate>August 2004</pubdate>
-              </biblioentry>
-            </bibliodiv>
-          </bibliography>
-        </sect2>
-        <sect2 id="internet_drafts">
-          <title>Internet Drafts</title>
-          <para>
-            Internet Drafts (IDs) are rough-draft working documents of
-            the Internet Engineering Task Force. They are, in essence, RFCs
-            in the preliminary stages of development. Implementors are
-            cautioned not
-            to regard IDs as archival, and they should not be quoted or cited
-            in any formal documents unless accompanied by the disclaimer that
-            they are "works in progress." IDs have a lifespan of six months
-            after which they are deleted unless updated by their authors.
-          </para>
-        </sect2>
-        <sect2>
-          <title>Other Documents About <acronym>BIND</acronym></title>
-          <para/>
-          <bibliography>
-            <biblioentry>
-              <authorgroup>
-                <author>
-                  <surname>Albitz</surname>
-                  <firstname>Paul</firstname>
-                </author>
-                <author>
-                  <firstname>Cricket</firstname>
-                  <surname>Liu</surname>
-                </author>
-              </authorgroup>
-              <title><acronym>DNS</acronym> and <acronym>BIND</acronym></title>
-              <copyright>
-                <year>1998</year>
-                <holder>Sebastopol, CA: O'Reilly and Associates</holder>
-              </copyright>
-            </biblioentry>
-          </bibliography>
-        </sect2>
-      </sect1>
-    </appendix>
-
-    <reference id="Bv9ARM.ch10">
-      <title>Manual pages</title>
-      <xi:include href="../../bin/dig/dig.docbook"/>
-      <xi:include href="../../bin/dig/host.docbook"/>
-      <xi:include href="../../bin/dnssec/dnssec-keygen.docbook"/>
-      <xi:include href="../../bin/dnssec/dnssec-signzone.docbook"/>
-      <xi:include href="../../bin/check/named-checkconf.docbook"/>
-      <xi:include href="../../bin/check/named-checkzone.docbook"/>
-      <xi:include href="../../bin/named/named.docbook"/>
-      <!-- named.conf.docbook and others? -->
-      <!-- nsupdate gives db2latex indigestion, markup problems? -->
-      <xi:include href="../../bin/rndc/rndc.docbook"/>
-      <xi:include href="../../bin/rndc/rndc.conf.docbook"/>
-      <xi:include href="../../bin/rndc/rndc-confgen.docbook"/>
-    </reference>
-
-  </book>
-
-<!--
-  - Local variables:
-  - mode: sgml
-  - End:
- -->
diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch01.html b/contrib/bind9/doc/arm/Bv9ARM.ch01.html
deleted file mode 100644
index 30e9e0d..0000000
--- a/contrib/bind9/doc/arm/Bv9ARM.ch01.html
+++ /dev/null
@@ -1,560 +0,0 @@
-<!--
- - Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2000-2003 Internet Software Consortium.
- - 
- - Permission to use, copy, modify, and distribute this software for any
- - purpose with or without fee is hereby granted, provided that the above
- - copyright notice and this permission notice appear in all copies.
- - 
- - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
- - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- - PERFORMANCE OF THIS SOFTWARE.
--->
-<!-- $Id: Bv9ARM.ch01.html,v 1.16.18.21 2007/10/31 01:35:57 marka Exp $ -->
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>Chapter 1. Introduction</title>
-<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
-<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="prev" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="next" href="Bv9ARM.ch02.html" title="Chapter 2. BIND Resource Requirements">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
-<div class="navheader">
-<table width="100%" summary="Navigation header">
-<tr><th colspan="3" align="center">Chapter 1. Introduction</th></tr>
-<tr>
-<td width="20%" align="left">
-<a accesskey="p" href="Bv9ARM.html">Prev</a> </td>
-<th width="60%" align="center"> </th>
-<td width="20%" align="right"> <a accesskey="n" href="Bv9ARM.ch02.html">Next</a>
-</td>
-</tr>
-</table>
-<hr>
-</div>
-<div class="chapter" lang="en">
-<div class="titlepage"><div><div><h2 class="title">
-<a name="Bv9ARM.ch01"></a>Chapter 1. Introduction</h2></div></div></div>
-<div class="toc">
-<p><b>Table of Contents</b></p>
-<dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564117">Scope of Document</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564140">Organization of This Document</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2563474">Conventions Used in This Document</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564816">The Domain Name System (<acronym class="acronym">DNS</acronym>)</a></span></dt>
-<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564837">DNS Fundamentals</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564871">Domains and Domain Names</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567208">Zones</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567285">Authoritative Name Servers</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567526">Caching Name Servers</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567588">Name Servers in Multiple Roles</a></span></dt>
-</dl></dd>
-</dl>
-</div>
-<p>
-      The Internet Domain Name System (<acronym class="acronym">DNS</acronym>)
-      consists of the syntax
-      to specify the names of entities in the Internet in a hierarchical
-      manner, the rules used for delegating authority over names, and the
-      system implementation that actually maps names to Internet
-      addresses.  <acronym class="acronym">DNS</acronym> data is maintained in a
-      group of distributed
-      hierarchical databases.
-    </p>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2564117"></a>Scope of Document</h2></div></div></div>
-<p>
-        The Berkeley Internet Name Domain
-        (<acronym class="acronym">BIND</acronym>) implements a
-        domain name server for a number of operating systems. This
-        document provides basic information about the installation and
-        care of the Internet Systems Consortium (<acronym class="acronym">ISC</acronym>)
-        <acronym class="acronym">BIND</acronym> version 9 software package for
-        system administrators.
-      </p>
-<p>
-        This version of the manual corresponds to BIND version 9.4.
-      </p>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2564140"></a>Organization of This Document</h2></div></div></div>
-<p>
-        In this document, <span class="emphasis"><em>Section 1</em></span> introduces
-        the basic <acronym class="acronym">DNS</acronym> and <acronym class="acronym">BIND</acronym> concepts. <span class="emphasis"><em>Section 2</em></span>
-        describes resource requirements for running <acronym class="acronym">BIND</acronym> in various
-        environments. Information in <span class="emphasis"><em>Section 3</em></span> is
-        <span class="emphasis"><em>task-oriented</em></span> in its presentation and is
-        organized functionally, to aid in the process of installing the
-        <acronym class="acronym">BIND</acronym> 9 software. The task-oriented
-        section is followed by
-        <span class="emphasis"><em>Section 4</em></span>, which contains more advanced
-        concepts that the system administrator may need for implementing
-        certain options. <span class="emphasis"><em>Section 5</em></span>
-        describes the <acronym class="acronym">BIND</acronym> 9 lightweight
-        resolver.  The contents of <span class="emphasis"><em>Section 6</em></span> are
-        organized as in a reference manual to aid in the ongoing
-        maintenance of the software. <span class="emphasis"><em>Section 7</em></span> addresses
-        security considerations, and
-        <span class="emphasis"><em>Section 8</em></span> contains troubleshooting help. The
-        main body of the document is followed by several
-        <span class="emphasis"><em>appendices</em></span> which contain useful reference
-        information, such as a <span class="emphasis"><em>bibliography</em></span> and
-        historic information related to <acronym class="acronym">BIND</acronym>
-        and the Domain Name
-        System.
-      </p>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2563474"></a>Conventions Used in This Document</h2></div></div></div>
-<p>
-        In this document, we use the following general typographic
-        conventions:
-      </p>
-<div class="informaltable"><table border="1">
-<colgroup>
-<col>
-<col>
-</colgroup>
-<tbody>
-<tr>
-<td>
-                <p>
-                  <span class="emphasis"><em>To describe:</em></span>
-                </p>
-              </td>
-<td>
-                <p>
-                  <span class="emphasis"><em>We use the style:</em></span>
-                </p>
-              </td>
-</tr>
-<tr>
-<td>
-                <p>
-                  a pathname, filename, URL, hostname,
-                  mailing list name, or new term or concept
-                </p>
-              </td>
-<td>
-                <p>
-                  <code class="filename">Fixed width</code>
-                </p>
-              </td>
-</tr>
-<tr>
-<td>
-                <p>
-                  literal user
-                  input
-                </p>
-              </td>
-<td>
-                <p>
-                  <strong class="userinput"><code>Fixed Width Bold</code></strong>
-                </p>
-              </td>
-</tr>
-<tr>
-<td>
-                <p>
-                  program output
-                </p>
-              </td>
-<td>
-                <p>
-                  <code class="computeroutput">Fixed Width</code>
-                </p>
-              </td>
-</tr>
-</tbody>
-</table></div>
-<p>
-        The following conventions are used in descriptions of the
-        <acronym class="acronym">BIND</acronym> configuration file:</p>
-<div class="informaltable"><table border="1">
-<colgroup>
-<col>
-<col>
-</colgroup>
-<tbody>
-<tr>
-<td>
-                  <p>
-                    <span class="emphasis"><em>To describe:</em></span>
-                  </p>
-                </td>
-<td>
-                  <p>
-                    <span class="emphasis"><em>We use the style:</em></span>
-                  </p>
-                </td>
-</tr>
-<tr>
-<td>
-                  <p>
-                    keywords
-                  </p>
-                </td>
-<td>
-                  <p>
-                    <code class="literal">Fixed Width</code>
-                  </p>
-                </td>
-</tr>
-<tr>
-<td>
-                  <p>
-                    variables
-                  </p>
-                </td>
-<td>
-                  <p>
-                    <code class="varname">Fixed Width</code>
-                  </p>
-                </td>
-</tr>
-<tr>
-<td>
-                  <p>
-                    Optional input
-                  </p>
-                </td>
-<td>
-                  <p>
-                    [<span class="optional">Text is enclosed in square brackets</span>]
-                  </p>
-                </td>
-</tr>
-</tbody>
-</table></div>
-<p>
-      </p>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2564816"></a>The Domain Name System (<acronym class="acronym">DNS</acronym>)</h2></div></div></div>
-<p>
-        The purpose of this document is to explain the installation
-        and upkeep of the <acronym class="acronym">BIND</acronym> (Berkeley Internet
-        Name Domain) software package, and we
-        begin by reviewing the fundamentals of the Domain Name System
-        (<acronym class="acronym">DNS</acronym>) as they relate to <acronym class="acronym">BIND</acronym>.
-      </p>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2564837"></a>DNS Fundamentals</h3></div></div></div>
-<p>
-          The Domain Name System (DNS) is a hierarchical, distributed
-          database.  It stores information for mapping Internet host names to
-          IP
-          addresses and vice versa, mail routing information, and other data
-          used by Internet applications.
-        </p>
-<p>
-          Clients look up information in the DNS by calling a
-          <span class="emphasis"><em>resolver</em></span> library, which sends queries to one or
-          more <span class="emphasis"><em>name servers</em></span> and interprets the responses.
-          The <acronym class="acronym">BIND</acronym> 9 software distribution
-          contains a
-          name server, <span><strong class="command">named</strong></span>, and two resolver
-          libraries, <span><strong class="command">liblwres</strong></span> and <span><strong class="command">libbind</strong></span>.
-        </p>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2564871"></a>Domains and Domain Names</h3></div></div></div>
-<p>
-          The data stored in the DNS is identified by <span class="emphasis"><em>domain names</em></span> that are organized as a tree according to
-          organizational or administrative boundaries. Each node of the tree,
-          called a <span class="emphasis"><em>domain</em></span>, is given a label. The domain
-          name of the
-          node is the concatenation of all the labels on the path from the
-          node to the <span class="emphasis"><em>root</em></span> node.  This is represented
-          in written form as a string of labels listed from right to left and
-          separated by dots. A label need only be unique within its parent
-          domain.
-        </p>
-<p>
-          For example, a domain name for a host at the
-          company <span class="emphasis"><em>Example, Inc.</em></span> could be
-          <code class="literal">ourhost.example.com</code>,
-          where <code class="literal">com</code> is the
-          top level domain to which
-          <code class="literal">ourhost.example.com</code> belongs,
-          <code class="literal">example</code> is
-          a subdomain of <code class="literal">com</code>, and
-          <code class="literal">ourhost</code> is the
-          name of the host.
-        </p>
-<p>
-          For administrative purposes, the name space is partitioned into
-          areas called <span class="emphasis"><em>zones</em></span>, each starting at a node and
-          extending down to the leaf nodes or to nodes where other zones
-          start.
-          The data for each zone is stored in a <span class="emphasis"><em>name server</em></span>, which answers queries about the zone using the
-          <span class="emphasis"><em>DNS protocol</em></span>.
-        </p>
-<p>
-          The data associated with each domain name is stored in the
-          form of <span class="emphasis"><em>resource records</em></span> (<acronym class="acronym">RR</acronym>s).
-          Some of the supported resource record types are described in
-          <a href="Bv9ARM.ch06.html#types_of_resource_records_and_when_to_use_them" title="Types of Resource Records and When to Use Them">the section called &#8220;Types of Resource Records and When to Use Them&#8221;</a>.
-        </p>
-<p>
-          For more detailed information about the design of the DNS and
-          the DNS protocol, please refer to the standards documents listed in
-          <a href="Bv9ARM.ch09.html#rfcs" title="Request for Comments (RFCs)">the section called &#8220;Request for Comments (RFCs)&#8221;</a>.
-        </p>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2567208"></a>Zones</h3></div></div></div>
-<p>
-          To properly operate a name server, it is important to understand
-          the difference between a <span class="emphasis"><em>zone</em></span>
-          and a <span class="emphasis"><em>domain</em></span>.
-        </p>
-<p>
-          As stated previously, a zone is a point of delegation in
-          the <acronym class="acronym">DNS</acronym> tree. A zone consists of
-          those contiguous parts of the domain
-          tree for which a name server has complete information and over which
-          it has authority. It contains all domain names from a certain point
-          downward in the domain tree except those which are delegated to
-          other zones. A delegation point is marked by one or more
-          <span class="emphasis"><em>NS records</em></span> in the
-          parent zone, which should be matched by equivalent NS records at
-          the root of the delegated zone.
-        </p>
-<p>
-          For instance, consider the <code class="literal">example.com</code>
-          domain which includes names
-          such as <code class="literal">host.aaa.example.com</code> and
-          <code class="literal">host.bbb.example.com</code> even though
-          the <code class="literal">example.com</code> zone includes
-          only delegations for the <code class="literal">aaa.example.com</code> and
-          <code class="literal">bbb.example.com</code> zones.  A zone can
-          map
-          exactly to a single domain, but could also include only part of a
-          domain, the rest of which could be delegated to other
-          name servers. Every name in the <acronym class="acronym">DNS</acronym>
-          tree is a
-          <span class="emphasis"><em>domain</em></span>, even if it is
-          <span class="emphasis"><em>terminal</em></span>, that is, has no
-          <span class="emphasis"><em>subdomains</em></span>.  Every subdomain is a domain and
-          every domain except the root is also a subdomain. The terminology is
-          not intuitive and we suggest that you read RFCs 1033, 1034 and 1035
-          to
-          gain a complete understanding of this difficult and subtle
-          topic.
-        </p>
-<p>
-          Though <acronym class="acronym">BIND</acronym> is called a "domain name
-          server",
-          it deals primarily in terms of zones. The master and slave
-          declarations in the <code class="filename">named.conf</code> file
-          specify
-          zones, not domains. When you ask some other site if it is willing to
-          be a slave server for your <span class="emphasis"><em>domain</em></span>, you are
-          actually asking for slave service for some collection of zones.
-        </p>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2567285"></a>Authoritative Name Servers</h3></div></div></div>
-<p>
-          Each zone is served by at least
-          one <span class="emphasis"><em>authoritative name server</em></span>,
-          which contains the complete data for the zone.
-          To make the DNS tolerant of server and network failures,
-          most zones have two or more authoritative servers, on
-          different networks.
-        </p>
-<p>
-          Responses from authoritative servers have the "authoritative
-          answer" (AA) bit set in the response packets.  This makes them
-          easy to identify when debugging DNS configurations using tools like
-          <span><strong class="command">dig</strong></span> (<a href="Bv9ARM.ch03.html#diagnostic_tools" title="Diagnostic Tools">the section called &#8220;Diagnostic Tools&#8221;</a>).
-        </p>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2567308"></a>The Primary Master</h4></div></div></div>
-<p>
-            The authoritative server where the master copy of the zone
-            data is maintained is called the
-            <span class="emphasis"><em>primary master</em></span> server, or simply the
-            <span class="emphasis"><em>primary</em></span>.  Typically it loads the zone
-            contents from some local file edited by humans or perhaps
-            generated mechanically from some other local file which is
-            edited by humans.  This file is called the
-            <span class="emphasis"><em>zone file</em></span> or
-            <span class="emphasis"><em>master file</em></span>.
-          </p>
-<p>
-            In some cases, however, the master file may not be edited
-            by humans at all, but may instead be the result of
-            <span class="emphasis"><em>dynamic update</em></span> operations.
-          </p>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2567338"></a>Slave Servers</h4></div></div></div>
-<p>
-            The other authoritative servers, the <span class="emphasis"><em>slave</em></span>
-            servers (also known as <span class="emphasis"><em>secondary</em></span> servers)
-            load
-            the zone contents from another server using a replication process
-            known as a <span class="emphasis"><em>zone transfer</em></span>.  Typically the data
-            are
-            transferred directly from the primary master, but it is also
-            possible
-            to transfer it from another slave.  In other words, a slave server
-            may itself act as a master to a subordinate slave server.
-          </p>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2567360"></a>Stealth Servers</h4></div></div></div>
-<p>
-            Usually all of the zone's authoritative servers are listed in
-            NS records in the parent zone.  These NS records constitute
-            a <span class="emphasis"><em>delegation</em></span> of the zone from the parent.
-            The authoritative servers are also listed in the zone file itself,
-            at the <span class="emphasis"><em>top level</em></span> or <span class="emphasis"><em>apex</em></span>
-            of the zone.  You can list servers in the zone's top-level NS
-            records that are not in the parent's NS delegation, but you cannot
-            list servers in the parent's delegation that are not present at
-            the zone's top level.
-          </p>
-<p>
-            A <span class="emphasis"><em>stealth server</em></span> is a server that is
-            authoritative for a zone but is not listed in that zone's NS
-            records.  Stealth servers can be used for keeping a local copy of
-            a
-            zone to speed up access to the zone's records or to make sure that
-            the
-            zone is available even if all the "official" servers for the zone
-            are
-            inaccessible.
-          </p>
-<p>
-            A configuration where the primary master server itself is a
-            stealth server is often referred to as a "hidden primary"
-            configuration.  One use for this configuration is when the primary
-            master
-            is behind a firewall and therefore unable to communicate directly
-            with the outside world.
-          </p>
-</div>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2567526"></a>Caching Name Servers</h3></div></div></div>
-<p>
-          The resolver libraries provided by most operating systems are
-          <span class="emphasis"><em>stub resolvers</em></span>, meaning that they are not
-          capable of
-          performing the full DNS resolution process by themselves by talking
-          directly to the authoritative servers.  Instead, they rely on a
-          local
-          name server to perform the resolution on their behalf.  Such a
-          server
-          is called a <span class="emphasis"><em>recursive</em></span> name server; it performs
-          <span class="emphasis"><em>recursive lookups</em></span> for local clients.
-        </p>
-<p>
-          To improve performance, recursive servers cache the results of
-          the lookups they perform.  Since the processes of recursion and
-          caching are intimately connected, the terms
-          <span class="emphasis"><em>recursive server</em></span> and
-          <span class="emphasis"><em>caching server</em></span> are often used synonymously.
-        </p>
-<p>
-          The length of time for which a record may be retained in
-          the cache of a caching name server is controlled by the
-          Time To Live (TTL) field associated with each resource record.
-        </p>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2567561"></a>Forwarding</h4></div></div></div>
-<p>
-            Even a caching name server does not necessarily perform
-            the complete recursive lookup itself.  Instead, it can
-            <span class="emphasis"><em>forward</em></span> some or all of the queries
-            that it cannot satisfy from its cache to another caching name
-            server,
-            commonly referred to as a <span class="emphasis"><em>forwarder</em></span>.
-          </p>
-<p>
-            There may be one or more forwarders,
-            and they are queried in turn until the list is exhausted or an
-            answer
-            is found. Forwarders are typically used when you do not
-            wish all the servers at a given site to interact directly with the
-            rest of
-            the Internet servers. A typical scenario would involve a number
-            of internal <acronym class="acronym">DNS</acronym> servers and an
-            Internet firewall. Servers unable
-            to pass packets through the firewall would forward to the server
-            that can do it, and that server would query the Internet <acronym class="acronym">DNS</acronym> servers
-            on the internal server's behalf.
-          </p>
-</div>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2567588"></a>Name Servers in Multiple Roles</h3></div></div></div>
-<p>
-          The <acronym class="acronym">BIND</acronym> name server can
-          simultaneously act as
-          a master for some zones, a slave for other zones, and as a caching
-          (recursive) server for a set of local clients.
-        </p>
-<p>
-          However, since the functions of authoritative name service
-          and caching/recursive name service are logically separate, it is
-          often advantageous to run them on separate server machines.
-
-          A server that only provides authoritative name service
-          (an <span class="emphasis"><em>authoritative-only</em></span> server) can run with
-          recursion disabled, improving reliability and security.
-
-          A server that is not authoritative for any zones and only provides
-          recursive service to local
-          clients (a <span class="emphasis"><em>caching-only</em></span> server)
-          does not need to be reachable from the Internet at large and can
-          be placed inside a firewall.
-        </p>
-</div>
-</div>
-</div>
-<div class="navfooter">
-<hr>
-<table width="100%" summary="Navigation footer">
-<tr>
-<td width="40%" align="left">
-<a accesskey="p" href="Bv9ARM.html">Prev</a> </td>
-<td width="20%" align="center"> </td>
-<td width="40%" align="right"> <a accesskey="n" href="Bv9ARM.ch02.html">Next</a>
-</td>
-</tr>
-<tr>
-<td width="40%" align="left" valign="top">BIND 9 Administrator Reference Manual </td>
-<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
-<td width="40%" align="right" valign="top"> Chapter 2. <acronym class="acronym">BIND</acronym> Resource Requirements</td>
-</tr>
-</table>
-</div>
-</body>
-</html>
diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch02.html b/contrib/bind9/doc/arm/Bv9ARM.ch02.html
deleted file mode 100644
index cbf6c15..0000000
--- a/contrib/bind9/doc/arm/Bv9ARM.ch02.html
+++ /dev/null
@@ -1,158 +0,0 @@
-<!--
- - Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2000-2003 Internet Software Consortium.
- - 
- - Permission to use, copy, modify, and distribute this software for any
- - purpose with or without fee is hereby granted, provided that the above
- - copyright notice and this permission notice appear in all copies.
- - 
- - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
- - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- - PERFORMANCE OF THIS SOFTWARE.
--->
-<!-- $Id: Bv9ARM.ch02.html,v 1.13.18.21 2007/10/31 01:35:57 marka Exp $ -->
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>Chapter 2. BIND Resource Requirements</title>
-<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
-<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="prev" href="Bv9ARM.ch01.html" title="Chapter 1. Introduction">
-<link rel="next" href="Bv9ARM.ch03.html" title="Chapter 3. Name Server Configuration">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
-<div class="navheader">
-<table width="100%" summary="Navigation header">
-<tr><th colspan="3" align="center">Chapter 2. <acronym class="acronym">BIND</acronym> Resource Requirements</th></tr>
-<tr>
-<td width="20%" align="left">
-<a accesskey="p" href="Bv9ARM.ch01.html">Prev</a> </td>
-<th width="60%" align="center"> </th>
-<td width="20%" align="right"> <a accesskey="n" href="Bv9ARM.ch03.html">Next</a>
-</td>
-</tr>
-</table>
-<hr>
-</div>
-<div class="chapter" lang="en">
-<div class="titlepage"><div><div><h2 class="title">
-<a name="Bv9ARM.ch02"></a>Chapter 2. <acronym class="acronym">BIND</acronym> Resource Requirements</h2></div></div></div>
-<div class="toc">
-<p><b>Table of Contents</b></p>
-<dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567622">Hardware requirements</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567649">CPU Requirements</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567661">Memory Requirements</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567688">Name Server Intensive Environment Issues</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567699">Supported Operating Systems</a></span></dt>
-</dl>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2567622"></a>Hardware requirements</h2></div></div></div>
-<p>
-        <acronym class="acronym">DNS</acronym> hardware requirements have
-        traditionally been quite modest.
-        For many installations, servers that have been pensioned off from
-        active duty have performed admirably as <acronym class="acronym">DNS</acronym> servers.
-      </p>
-<p>
-        The DNSSEC features of <acronym class="acronym">BIND</acronym> 9
-        may prove to be quite
-        CPU intensive however, so organizations that make heavy use of these
-        features may wish to consider larger systems for these applications.
-        <acronym class="acronym">BIND</acronym> 9 is fully multithreaded, allowing
-        full utilization of
-        multiprocessor systems for installations that need it.
-      </p>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2567649"></a>CPU Requirements</h2></div></div></div>
-<p>
-        CPU requirements for <acronym class="acronym">BIND</acronym> 9 range from
-        i486-class machines
-        for serving of static zones without caching, to enterprise-class
-        machines if you intend to process many dynamic updates and DNSSEC
-        signed zones, serving many thousands of queries per second.
-      </p>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2567661"></a>Memory Requirements</h2></div></div></div>
-<p>
-        The memory of the server has to be large enough to fit the
-        cache and zones loaded off disk.  The <span><strong class="command">max-cache-size</strong></span>
-        option can be used to limit the amount of memory used by the cache,
-        at the expense of reducing cache hit rates and causing more <acronym class="acronym">DNS</acronym>
-        traffic.
-        Additionally, if additional section caching
-        (<a href="Bv9ARM.ch06.html#acache" title="Additional Section Caching">the section called &#8220;Additional Section Caching&#8221;</a>) is enabled,
-        the <span><strong class="command">max-acache-size</strong></span> option can be used to
-        limit the amount
-        of memory used by the mechanism.
-        It is still good practice to have enough memory to load
-        all zone and cache data into memory &#8212; unfortunately, the best
-        way
-        to determine this for a given installation is to watch the name server
-        in operation. After a few weeks the server process should reach
-        a relatively stable size where entries are expiring from the cache as
-        fast as they are being inserted.
-      </p>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2567688"></a>Name Server Intensive Environment Issues</h2></div></div></div>
-<p>
-        For name server intensive environments, there are two alternative
-        configurations that may be used. The first is where clients and
-        any second-level internal name servers query a main name server, which
-        has enough memory to build a large cache. This approach minimizes
-        the bandwidth used by external name lookups. The second alternative
-        is to set up second-level internal name servers to make queries
-        independently.
-        In this configuration, none of the individual machines needs to
-        have as much memory or CPU power as in the first alternative, but
-        this has the disadvantage of making many more external queries,
-        as none of the name servers share their cached data.
-      </p>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2567699"></a>Supported Operating Systems</h2></div></div></div>
-<p>
-        ISC <acronym class="acronym">BIND</acronym> 9 compiles and runs on a large
-        number
-        of Unix-like operating system and on NT-derived versions of
-        Microsoft Windows such as Windows 2000 and Windows XP.  For an
-        up-to-date
-        list of supported systems, see the README file in the top level
-        directory
-        of the BIND 9 source distribution.
-      </p>
-</div>
-</div>
-<div class="navfooter">
-<hr>
-<table width="100%" summary="Navigation footer">
-<tr>
-<td width="40%" align="left">
-<a accesskey="p" href="Bv9ARM.ch01.html">Prev</a> </td>
-<td width="20%" align="center"> </td>
-<td width="40%" align="right"> <a accesskey="n" href="Bv9ARM.ch03.html">Next</a>
-</td>
-</tr>
-<tr>
-<td width="40%" align="left" valign="top">Chapter 1. Introduction </td>
-<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
-<td width="40%" align="right" valign="top"> Chapter 3. Name Server Configuration</td>
-</tr>
-</table>
-</div>
-</body>
-</html>
diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch03.html b/contrib/bind9/doc/arm/Bv9ARM.ch03.html
deleted file mode 100644
index 18f2711..0000000
--- a/contrib/bind9/doc/arm/Bv9ARM.ch03.html
+++ /dev/null
@@ -1,808 +0,0 @@
-<!--
- - Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2000-2003 Internet Software Consortium.
- - 
- - Permission to use, copy, modify, and distribute this software for any
- - purpose with or without fee is hereby granted, provided that the above
- - copyright notice and this permission notice appear in all copies.
- - 
- - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
- - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- - PERFORMANCE OF THIS SOFTWARE.
--->
-<!-- $Id: Bv9ARM.ch03.html,v 1.35.18.31 2007/10/31 01:35:57 marka Exp $ -->
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>Chapter 3. Name Server Configuration</title>
-<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
-<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="prev" href="Bv9ARM.ch02.html" title="Chapter 2. BIND Resource Requirements">
-<link rel="next" href="Bv9ARM.ch04.html" title="Chapter 4. Advanced DNS Features">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
-<div class="navheader">
-<table width="100%" summary="Navigation header">
-<tr><th colspan="3" align="center">Chapter 3. Name Server Configuration</th></tr>
-<tr>
-<td width="20%" align="left">
-<a accesskey="p" href="Bv9ARM.ch02.html">Prev</a> </td>
-<th width="60%" align="center"> </th>
-<td width="20%" align="right"> <a accesskey="n" href="Bv9ARM.ch04.html">Next</a>
-</td>
-</tr>
-</table>
-<hr>
-</div>
-<div class="chapter" lang="en">
-<div class="titlepage"><div><div><h2 class="title">
-<a name="Bv9ARM.ch03"></a>Chapter 3. Name Server Configuration</h2></div></div></div>
-<div class="toc">
-<p><b>Table of Contents</b></p>
-<dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch03.html#sample_configuration">Sample Configurations</a></span></dt>
-<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2568004">A Caching-only Name Server</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2568020">An Authoritative-only Name Server</a></span></dt>
-</dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568042">Load Balancing</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568465">Name Server Operations</a></span></dt>
-<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2568470">Tools for Use With the Name Server Daemon</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2570184">Signals</a></span></dt>
-</dl></dd>
-</dl>
-</div>
-<p>
-      In this section we provide some suggested configurations along
-      with guidelines for their use.  We suggest reasonable values for
-      certain option settings.
-    </p>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="sample_configuration"></a>Sample Configurations</h2></div></div></div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2568004"></a>A Caching-only Name Server</h3></div></div></div>
-<p>
-          The following sample configuration is appropriate for a caching-only
-          name server for use by clients internal to a corporation.  All
-          queries
-          from outside clients are refused using the <span><strong class="command">allow-query</strong></span>
-          option.  Alternatively, the same effect could be achieved using
-          suitable
-          firewall rules.
-        </p>
-<pre class="programlisting">
-// Two corporate subnets we wish to allow queries from.
-acl corpnets { 192.168.4.0/24; 192.168.7.0/24; };
-options {
-     directory "/etc/namedb";           // Working directory
-     allow-query { corpnets; };
-};
-// Provide a reverse mapping for the loopback address 127.0.0.1
-zone "0.0.127.in-addr.arpa" {
-     type master;
-     file "localhost.rev";
-     notify no;
-};
-</pre>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2568020"></a>An Authoritative-only Name Server</h3></div></div></div>
-<p>
-          This sample configuration is for an authoritative-only server
-          that is the master server for "<code class="filename">example.com</code>"
-          and a slave for the subdomain "<code class="filename">eng.example.com</code>".
-        </p>
-<pre class="programlisting">
-options {
-     directory "/etc/namedb";           // Working directory
-     allow-query-cache { none; };       // Do not allow access to cache
-     allow-query { any; };              // This is the default
-     recursion no;                      // Do not provide recursive service
-};
-
-// Provide a reverse mapping for the loopback address 127.0.0.1
-zone "0.0.127.in-addr.arpa" {
-     type master;
-     file "localhost.rev";
-     notify no;
-};
-// We are the master server for example.com
-zone "example.com" {
-     type master;
-     file "example.com.db";
-     // IP addresses of slave servers allowed to transfer example.com
-     allow-transfer {
-          192.168.4.14;
-          192.168.5.53;
-     };
-};
-// We are a slave server for eng.example.com
-zone "eng.example.com" {
-     type slave;
-     file "eng.example.com.bk";
-     // IP address of eng.example.com master server
-     masters { 192.168.4.12; };
-};
-</pre>
-</div>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2568042"></a>Load Balancing</h2></div></div></div>
-<p>
-        A primitive form of load balancing can be achieved in
-        the <acronym class="acronym">DNS</acronym> by using multiple records
-        (such as multiple A records) for one name.
-      </p>
-<p>
-        For example, if you have three WWW servers with network addresses
-        of 10.0.0.1, 10.0.0.2 and 10.0.0.3, a set of records such as the
-        following means that clients will connect to each machine one third
-        of the time:
-      </p>
-<div class="informaltable"><table border="1">
-<colgroup>
-<col>
-<col>
-<col>
-<col>
-<col>
-</colgroup>
-<tbody>
-<tr>
-<td>
-                <p>
-                  Name
-                </p>
-              </td>
-<td>
-                <p>
-                  TTL
-                </p>
-              </td>
-<td>
-                <p>
-                  CLASS
-                </p>
-              </td>
-<td>
-                <p>
-                  TYPE
-                </p>
-              </td>
-<td>
-                <p>
-                  Resource Record (RR) Data
-                </p>
-              </td>
-</tr>
-<tr>
-<td>
-                <p>
-                  <code class="literal">www</code>
-                </p>
-              </td>
-<td>
-                <p>
-                  <code class="literal">600</code>
-                </p>
-              </td>
-<td>
-                <p>
-                  <code class="literal">IN</code>
-                </p>
-              </td>
-<td>
-                <p>
-                  <code class="literal">A</code>
-                </p>
-              </td>
-<td>
-                <p>
-                  <code class="literal">10.0.0.1</code>
-                </p>
-              </td>
-</tr>
-<tr>
-<td>
-                <p></p>
-              </td>
-<td>
-                <p>
-                  <code class="literal">600</code>
-                </p>
-              </td>
-<td>
-                <p>
-                  <code class="literal">IN</code>
-                </p>
-              </td>
-<td>
-                <p>
-                  <code class="literal">A</code>
-                </p>
-              </td>
-<td>
-                <p>
-                  <code class="literal">10.0.0.2</code>
-                </p>
-              </td>
-</tr>
-<tr>
-<td>
-                <p></p>
-              </td>
-<td>
-                <p>
-                  <code class="literal">600</code>
-                </p>
-              </td>
-<td>
-                <p>
-                  <code class="literal">IN</code>
-                </p>
-              </td>
-<td>
-                <p>
-                  <code class="literal">A</code>
-                </p>
-              </td>
-<td>
-                <p>
-                  <code class="literal">10.0.0.3</code>
-                </p>
-              </td>
-</tr>
-</tbody>
-</table></div>
-<p>
-        When a resolver queries for these records, <acronym class="acronym">BIND</acronym> will rotate
-        them and respond to the query with the records in a different
-        order.  In the example above, clients will randomly receive
-        records in the order 1, 2, 3; 2, 3, 1; and 3, 1, 2. Most clients
-        will use the first record returned and discard the rest.
-      </p>
-<p>
-        For more detail on ordering responses, check the
-        <span><strong class="command">rrset-order</strong></span> substatement in the
-        <span><strong class="command">options</strong></span> statement, see
-        <a href="Bv9ARM.ch06.html#rrset_ordering">RRset Ordering</a>.
-      </p>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2568465"></a>Name Server Operations</h2></div></div></div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2568470"></a>Tools for Use With the Name Server Daemon</h3></div></div></div>
-<p>
-          This section describes several indispensable diagnostic,
-          administrative and monitoring tools available to the system
-          administrator for controlling and debugging the name server
-          daemon.
-        </p>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="diagnostic_tools"></a>Diagnostic Tools</h4></div></div></div>
-<p>
-            The <span><strong class="command">dig</strong></span>, <span><strong class="command">host</strong></span>, and
-            <span><strong class="command">nslookup</strong></span> programs are all command
-            line tools
-            for manually querying name servers.  They differ in style and
-            output format.
-          </p>
-<div class="variablelist"><dl>
-<dt><span class="term"><a name="dig"></a><span><strong class="command">dig</strong></span></span></dt>
-<dd>
-<p>
-                  The domain information groper (<span><strong class="command">dig</strong></span>)
-                  is the most versatile and complete of these lookup tools.
-                  It has two modes: simple interactive
-                  mode for a single query, and batch mode which executes a
-                  query for
-                  each in a list of several query lines. All query options are
-                  accessible
-                  from the command line.
-                </p>
-<div class="cmdsynopsis"><p><code class="command">dig</code>  [@<em class="replaceable"><code>server</code></em>]  <em class="replaceable"><code>domain</code></em>  [<em class="replaceable"><code>query-type</code></em>] [<em class="replaceable"><code>query-class</code></em>] [+<em class="replaceable"><code>query-option</code></em>] [-<em class="replaceable"><code>dig-option</code></em>] [%<em class="replaceable"><code>comment</code></em>]</p></div>
-<p>
-                  The usual simple use of dig will take the form
-                </p>
-<p>
-                  <span><strong class="command">dig @server domain query-type query-class</strong></span>
-                </p>
-<p>
-                  For more information and a list of available commands and
-                  options, see the <span><strong class="command">dig</strong></span> man
-                  page.
-                </p>
-</dd>
-<dt><span class="term"><span><strong class="command">host</strong></span></span></dt>
-<dd>
-<p>
-                  The <span><strong class="command">host</strong></span> utility emphasizes
-                  simplicity
-                  and ease of use.  By default, it converts
-                  between host names and Internet addresses, but its
-                  functionality
-                  can be extended with the use of options.
-                </p>
-<div class="cmdsynopsis"><p><code class="command">host</code>  [-aCdlnrsTwv] [-c <em class="replaceable"><code>class</code></em>] [-N <em class="replaceable"><code>ndots</code></em>] [-t <em class="replaceable"><code>type</code></em>] [-W <em class="replaceable"><code>timeout</code></em>] [-R <em class="replaceable"><code>retries</code></em>] [-m <em class="replaceable"><code>flag</code></em>] [-4] [-6]  <em class="replaceable"><code>hostname</code></em>  [<em class="replaceable"><code>server</code></em>]</p></div>
-<p>
-                  For more information and a list of available commands and
-                  options, see the <span><strong class="command">host</strong></span> man
-                  page.
-                </p>
-</dd>
-<dt><span class="term"><span><strong class="command">nslookup</strong></span></span></dt>
-<dd>
-<p><span><strong class="command">nslookup</strong></span>
-                  has two modes: interactive and
-                  non-interactive. Interactive mode allows the user to
-                  query name servers for information about various
-                  hosts and domains or to print a list of hosts in a
-                  domain. Non-interactive mode is used to print just
-                  the name and requested information for a host or
-                  domain.
-                </p>
-<div class="cmdsynopsis"><p><code class="command">nslookup</code>  [-option...] [[<em class="replaceable"><code>host-to-find</code></em>] |  [- [server]]]</p></div>
-<p>
-                  Interactive mode is entered when no arguments are given (the
-                  default name server will be used) or when the first argument
-                  is a
-                  hyphen (`-') and the second argument is the host name or
-                  Internet address
-                  of a name server.
-                </p>
-<p>
-                  Non-interactive mode is used when the name or Internet
-                  address
-                  of the host to be looked up is given as the first argument.
-                  The
-                  optional second argument specifies the host name or address
-                  of a name server.
-                </p>
-<p>
-                  Due to its arcane user interface and frequently inconsistent
-                  behavior, we do not recommend the use of <span><strong class="command">nslookup</strong></span>.
-                  Use <span><strong class="command">dig</strong></span> instead.
-                </p>
-</dd>
-</dl></div>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="admin_tools"></a>Administrative Tools</h4></div></div></div>
-<p>
-            Administrative tools play an integral part in the management
-            of a server.
-          </p>
-<div class="variablelist"><dl>
-<dt>
-<a name="named-checkconf"></a><span class="term"><span><strong class="command">named-checkconf</strong></span></span>
-</dt>
-<dd>
-<p>
-                  The <span><strong class="command">named-checkconf</strong></span> program
-                  checks the syntax of a <code class="filename">named.conf</code> file.
-                </p>
-<div class="cmdsynopsis"><p><code class="command">named-checkconf</code>  [-jvz] [-t <em class="replaceable"><code>directory</code></em>] [<em class="replaceable"><code>filename</code></em>]</p></div>
-</dd>
-<dt>
-<a name="named-checkzone"></a><span class="term"><span><strong class="command">named-checkzone</strong></span></span>
-</dt>
-<dd>
-<p>
-                  The <span><strong class="command">named-checkzone</strong></span> program
-                  checks a master file for
-                  syntax and consistency.
-                </p>
-<div class="cmdsynopsis"><p><code class="command">named-checkzone</code>  [-djqvD] [-c <em class="replaceable"><code>class</code></em>] [-o <em class="replaceable"><code>output</code></em>] [-t <em class="replaceable"><code>directory</code></em>] [-w <em class="replaceable"><code>directory</code></em>] [-k <em class="replaceable"><code>(ignore|warn|fail)</code></em>] [-n <em class="replaceable"><code>(ignore|warn|fail)</code></em>] [-W <em class="replaceable"><code>(ignore|warn)</code></em>]  <em class="replaceable"><code>zone</code></em>  [<em class="replaceable"><code>filename</code></em>]</p></div>
-</dd>
-<dt>
-<a name="named-compilezone"></a><span class="term"><span><strong class="command">named-compilezone</strong></span></span>
-</dt>
-<dd><p>
-                  Similar to <span><strong class="command">named-checkzone,</strong></span> but
-                  it always dumps the zone content to a specified file
-                  (typically in a different format).
-                </p></dd>
-<dt>
-<a name="rndc"></a><span class="term"><span><strong class="command">rndc</strong></span></span>
-</dt>
-<dd>
-<p>
-                  The remote name daemon control
-                  (<span><strong class="command">rndc</strong></span>) program allows the
-                  system
-                  administrator to control the operation of a name server.
-                  Since <acronym class="acronym">BIND</acronym> 9.2, <span><strong class="command">rndc</strong></span>
-                  supports all the commands of the BIND 8 <span><strong class="command">ndc</strong></span>
-                  utility except <span><strong class="command">ndc start</strong></span> and
-                  <span><strong class="command">ndc restart</strong></span>, which were also
-                  not supported in <span><strong class="command">ndc</strong></span>'s
-                  channel mode.
-                  If you run <span><strong class="command">rndc</strong></span> without any
-                  options
-                  it will display a usage message as follows:
-                </p>
-<div class="cmdsynopsis"><p><code class="command">rndc</code>  [-c <em class="replaceable"><code>config</code></em>] [-s <em class="replaceable"><code>server</code></em>] [-p <em class="replaceable"><code>port</code></em>] [-y <em class="replaceable"><code>key</code></em>]  <em class="replaceable"><code>command</code></em>  [<em class="replaceable"><code>command</code></em>...]</p></div>
-<p>The <span><strong class="command">command</strong></span>
-                  is one of the following:
-                </p>
-<div class="variablelist"><dl>
-<dt><span class="term"><strong class="userinput"><code>reload</code></strong></span></dt>
-<dd><p>
-                        Reload configuration file and zones.
-                      </p></dd>
-<dt><span class="term"><strong class="userinput"><code>reload <em class="replaceable"><code>zone</code></em>
-                        [<span class="optional"><em class="replaceable"><code>class</code></em>
-           [<span class="optional"><em class="replaceable"><code>view</code></em></span>]</span>]</code></strong></span></dt>
-<dd><p>
-                        Reload the given zone.
-                      </p></dd>
-<dt><span class="term"><strong class="userinput"><code>refresh <em class="replaceable"><code>zone</code></em>
-                        [<span class="optional"><em class="replaceable"><code>class</code></em>
-           [<span class="optional"><em class="replaceable"><code>view</code></em></span>]</span>]</code></strong></span></dt>
-<dd><p>
-                        Schedule zone maintenance for the given zone.
-                      </p></dd>
-<dt><span class="term"><strong class="userinput"><code>retransfer <em class="replaceable"><code>zone</code></em>
-
-                        [<span class="optional"><em class="replaceable"><code>class</code></em>
-           [<span class="optional"><em class="replaceable"><code>view</code></em></span>]</span>]</code></strong></span></dt>
-<dd><p>
-                        Retransfer the given zone from the master.
-                      </p></dd>
-<dt><span class="term"><strong class="userinput"><code>freeze
-                        [<span class="optional"><em class="replaceable"><code>zone</code></em>
-       [<span class="optional"><em class="replaceable"><code>class</code></em>
-           [<span class="optional"><em class="replaceable"><code>view</code></em></span>]</span>]</span>]</code></strong></span></dt>
-<dd><p>
-                        Suspend updates to a dynamic zone.  If no zone is
-                        specified,
-                        then all zones are suspended.  This allows manual
-                        edits to be made to a zone normally updated by dynamic
-                        update.  It
-                        also causes changes in the journal file to be synced
-                        into the master
-                        and the journal file to be removed.  All dynamic
-                        update attempts will
-                        be refused while the zone is frozen.
-                      </p></dd>
-<dt><span class="term"><strong class="userinput"><code>thaw
-                        [<span class="optional"><em class="replaceable"><code>zone</code></em>
-       [<span class="optional"><em class="replaceable"><code>class</code></em>
-           [<span class="optional"><em class="replaceable"><code>view</code></em></span>]</span>]</span>]</code></strong></span></dt>
-<dd><p>
-                        Enable updates to a frozen dynamic zone.  If no zone
-                        is
-                        specified, then all frozen zones are enabled.  This
-                        causes
-                        the server to reload the zone from disk, and
-                        re-enables dynamic updates
-                        after the load has completed.  After a zone is thawed,
-                        dynamic updates
-                        will no longer be refused.
-                      </p></dd>
-<dt><span class="term"><strong class="userinput"><code>notify <em class="replaceable"><code>zone</code></em>
-                        [<span class="optional"><em class="replaceable"><code>class</code></em>
-           [<span class="optional"><em class="replaceable"><code>view</code></em></span>]</span>]</code></strong></span></dt>
-<dd><p>
-                        Resend NOTIFY messages for the zone.
-                      </p></dd>
-<dt><span class="term"><strong class="userinput"><code>reconfig</code></strong></span></dt>
-<dd><p>
-                        Reload the configuration file and load new zones,
-                        but do not reload existing zone files even if they
-                        have changed.
-                        This is faster than a full <span><strong class="command">reload</strong></span> when there
-                        is a large number of zones because it avoids the need
-                        to examine the
-                        modification times of the zones files.
-                      </p></dd>
-<dt><span class="term"><strong class="userinput"><code>stats</code></strong></span></dt>
-<dd><p>
-                        Write server statistics to the statistics file.
-                      </p></dd>
-<dt><span class="term"><strong class="userinput"><code>querylog</code></strong></span></dt>
-<dd><p>
-                        Toggle query logging. Query logging can also be enabled
-                        by explicitly directing the <span><strong class="command">queries</strong></span>
-                        <span><strong class="command">category</strong></span> to a
-                        <span><strong class="command">channel</strong></span> in the
-                        <span><strong class="command">logging</strong></span> section of
-                        <code class="filename">named.conf</code> or by specifying
-                        <span><strong class="command">querylog yes;</strong></span> in the
-                        <span><strong class="command">options</strong></span> section of
-                        <code class="filename">named.conf</code>.
-                      </p></dd>
-<dt><span class="term"><strong class="userinput"><code>dumpdb
-                        [<span class="optional">-all|-cache|-zone</span>]
-                        [<span class="optional"><em class="replaceable"><code>view ...</code></em></span>]</code></strong></span></dt>
-<dd><p>
-                        Dump the server's caches (default) and/or zones to
-                        the
-                        dump file for the specified views.  If no view is
-                        specified, all
-                        views are dumped.
-                      </p></dd>
-<dt><span class="term"><strong class="userinput"><code>stop [<span class="optional">-p</span>]</code></strong></span></dt>
-<dd><p>
-                        Stop the server, making sure any recent changes
-                        made through dynamic update or IXFR are first saved to
-                        the master files of the updated zones.
-                        If -p is specified named's process id is returned.
-                        This allows an external process to determine when named
-                        had completed stopping.
-                      </p></dd>
-<dt><span class="term"><strong class="userinput"><code>halt [<span class="optional">-p</span>]</code></strong></span></dt>
-<dd><p>
-                        Stop the server immediately.  Recent changes
-                        made through dynamic update or IXFR are not saved to
-                        the master files, but will be rolled forward from the
-                        journal files when the server is restarted.
-                        If -p is specified named's process id is returned.
-                        This allows an external process to determine when named
-                        had completed halting.
-                      </p></dd>
-<dt><span class="term"><strong class="userinput"><code>trace</code></strong></span></dt>
-<dd><p>
-                        Increment the servers debugging level by one.
-                      </p></dd>
-<dt><span class="term"><strong class="userinput"><code>trace <em class="replaceable"><code>level</code></em></code></strong></span></dt>
-<dd><p>
-                        Sets the server's debugging level to an explicit
-                        value.
-                      </p></dd>
-<dt><span class="term"><strong class="userinput"><code>notrace</code></strong></span></dt>
-<dd><p>
-                        Sets the server's debugging level to 0.
-                      </p></dd>
-<dt><span class="term"><strong class="userinput"><code>flush</code></strong></span></dt>
-<dd><p>
-                        Flushes the server's cache.
-                      </p></dd>
-<dt><span class="term"><strong class="userinput"><code>flushname</code></strong> <em class="replaceable"><code>name</code></em></span></dt>
-<dd><p>
-                        Flushes the given name from the server's cache.
-                      </p></dd>
-<dt><span class="term"><strong class="userinput"><code>status</code></strong></span></dt>
-<dd><p>
-                        Display status of the server.
-                        Note that the number of zones includes the internal <span><strong class="command">bind/CH</strong></span> zone
-                        and the default <span><strong class="command">./IN</strong></span>
-                        hint zone if there is not an
-                        explicit root zone configured.
-                      </p></dd>
-<dt><span class="term"><strong class="userinput"><code>recursing</code></strong></span></dt>
-<dd><p>
-                        Dump the list of queries named is currently recursing
-                        on.
-                      </p></dd>
-</dl></div>
-<p>
-                  A configuration file is required, since all
-                  communication with the server is authenticated with
-                  digital signatures that rely on a shared secret, and
-                  there is no way to provide that secret other than with a
-                  configuration file.  The default location for the
-                  <span><strong class="command">rndc</strong></span> configuration file is
-                  <code class="filename">/etc/rndc.conf</code>, but an
-                  alternate
-                  location can be specified with the <code class="option">-c</code>
-                  option.  If the configuration file is not found,
-                  <span><strong class="command">rndc</strong></span> will also look in
-                  <code class="filename">/etc/rndc.key</code> (or whatever
-                  <code class="varname">sysconfdir</code> was defined when
-                  the <acronym class="acronym">BIND</acronym> build was
-                  configured).
-                  The <code class="filename">rndc.key</code> file is
-                  generated by
-                  running <span><strong class="command">rndc-confgen -a</strong></span> as
-                  described in
-                  <a href="Bv9ARM.ch06.html#controls_statement_definition_and_usage" title="controls Statement Definition and
-          Usage">the section called &#8220;<span><strong class="command">controls</strong></span> Statement Definition and
-          Usage&#8221;</a>.
-                </p>
-<p>
-                  The format of the configuration file is similar to
-                  that of <code class="filename">named.conf</code>, but
-                  limited to
-                  only four statements, the <span><strong class="command">options</strong></span>,
-                  <span><strong class="command">key</strong></span>, <span><strong class="command">server</strong></span> and
-                  <span><strong class="command">include</strong></span>
-                  statements.  These statements are what associate the
-                  secret keys to the servers with which they are meant to
-                  be shared.  The order of statements is not
-                  significant.
-                </p>
-<p>
-                  The <span><strong class="command">options</strong></span> statement has
-                  three clauses:
-                  <span><strong class="command">default-server</strong></span>, <span><strong class="command">default-key</strong></span>,
-                  and <span><strong class="command">default-port</strong></span>.
-                  <span><strong class="command">default-server</strong></span> takes a
-                  host name or address argument  and represents the server
-                  that will
-                  be contacted if no <code class="option">-s</code>
-                  option is provided on the command line.
-                  <span><strong class="command">default-key</strong></span> takes
-                  the name of a key as its argument, as defined by a <span><strong class="command">key</strong></span> statement.
-                  <span><strong class="command">default-port</strong></span> specifies the
-                  port to which
-                  <span><strong class="command">rndc</strong></span> should connect if no
-                  port is given on the command line or in a
-                  <span><strong class="command">server</strong></span> statement.
-                </p>
-<p>
-                  The <span><strong class="command">key</strong></span> statement defines a
-                  key to be used
-                  by <span><strong class="command">rndc</strong></span> when authenticating
-                  with
-                  <span><strong class="command">named</strong></span>.  Its syntax is
-                  identical to the
-                  <span><strong class="command">key</strong></span> statement in named.conf.
-                  The keyword <strong class="userinput"><code>key</code></strong> is
-                  followed by a key name, which must be a valid
-                  domain name, though it need not actually be hierarchical;
-                  thus,
-                  a string like "<strong class="userinput"><code>rndc_key</code></strong>" is a valid
-                  name.
-                  The <span><strong class="command">key</strong></span> statement has two
-                  clauses:
-                  <span><strong class="command">algorithm</strong></span> and <span><strong class="command">secret</strong></span>.
-                  While the configuration parser will accept any string as the
-                  argument
-                  to algorithm, currently only the string "<strong class="userinput"><code>hmac-md5</code></strong>"
-                  has any meaning.  The secret is a base-64 encoded string
-                  as specified in RFC 3548.
-                </p>
-<p>
-                  The <span><strong class="command">server</strong></span> statement
-                  associates a key
-                  defined using the <span><strong class="command">key</strong></span>
-                  statement with a server.
-                  The keyword <strong class="userinput"><code>server</code></strong> is followed by a
-                  host name or address.  The <span><strong class="command">server</strong></span> statement
-                  has two clauses: <span><strong class="command">key</strong></span> and <span><strong class="command">port</strong></span>.
-                  The <span><strong class="command">key</strong></span> clause specifies the
-                  name of the key
-                  to be used when communicating with this server, and the
-                  <span><strong class="command">port</strong></span> clause can be used to
-                  specify the port <span><strong class="command">rndc</strong></span> should
-                  connect
-                  to on the server.
-                </p>
-<p>
-                  A sample minimal configuration file is as follows:
-                </p>
-<pre class="programlisting">
-key rndc_key {
-     algorithm "hmac-md5";
-     secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K";
-};
-options {
-     default-server 127.0.0.1;
-     default-key    rndc_key;
-};
-</pre>
-<p>
-                  This file, if installed as <code class="filename">/etc/rndc.conf</code>,
-                  would allow the command:
-                </p>
-<p>
-                  <code class="prompt">$ </code><strong class="userinput"><code>rndc reload</code></strong>
-                </p>
-<p>
-                  to connect to 127.0.0.1 port 953 and cause the name server
-                  to reload, if a name server on the local machine were
-                  running with
-                  following controls statements:
-                </p>
-<pre class="programlisting">
-controls {
-        inet 127.0.0.1 allow { localhost; } keys { rndc_key; };
-};
-</pre>
-<p>
-                  and it had an identical key statement for
-                  <code class="literal">rndc_key</code>.
-                </p>
-<p>
-                  Running the <span><strong class="command">rndc-confgen</strong></span>
-                  program will
-                  conveniently create a <code class="filename">rndc.conf</code>
-                  file for you, and also display the
-                  corresponding <span><strong class="command">controls</strong></span>
-                  statement that you need to
-                  add to <code class="filename">named.conf</code>.
-                  Alternatively,
-                  you can run <span><strong class="command">rndc-confgen -a</strong></span>
-                  to set up
-                  a <code class="filename">rndc.key</code> file and not
-                  modify
-                  <code class="filename">named.conf</code> at all.
-                </p>
-</dd>
-</dl></div>
-</div>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2570184"></a>Signals</h3></div></div></div>
-<p>
-          Certain UNIX signals cause the name server to take specific
-          actions, as described in the following table.  These signals can
-          be sent using the <span><strong class="command">kill</strong></span> command.
-        </p>
-<div class="informaltable"><table border="1">
-<colgroup>
-<col>
-<col>
-</colgroup>
-<tbody>
-<tr>
-<td>
-                  <p><span><strong class="command">SIGHUP</strong></span></p>
-                </td>
-<td>
-                  <p>
-                    Causes the server to read <code class="filename">named.conf</code> and
-                    reload the database.
-                  </p>
-                </td>
-</tr>
-<tr>
-<td>
-                  <p><span><strong class="command">SIGTERM</strong></span></p>
-                </td>
-<td>
-                  <p>
-                    Causes the server to clean up and exit.
-                  </p>
-                </td>
-</tr>
-<tr>
-<td>
-                  <p><span><strong class="command">SIGINT</strong></span></p>
-                </td>
-<td>
-                  <p>
-                    Causes the server to clean up and exit.
-                  </p>
-                </td>
-</tr>
-</tbody>
-</table></div>
-</div>
-</div>
-</div>
-<div class="navfooter">
-<hr>
-<table width="100%" summary="Navigation footer">
-<tr>
-<td width="40%" align="left">
-<a accesskey="p" href="Bv9ARM.ch02.html">Prev</a> </td>
-<td width="20%" align="center"> </td>
-<td width="40%" align="right"> <a accesskey="n" href="Bv9ARM.ch04.html">Next</a>
-</td>
-</tr>
-<tr>
-<td width="40%" align="left" valign="top">Chapter 2. <acronym class="acronym">BIND</acronym> Resource Requirements </td>
-<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
-<td width="40%" align="right" valign="top"> Chapter 4. Advanced DNS Features</td>
-</tr>
-</table>
-</div>
-</body>
-</html>
diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch04.html b/contrib/bind9/doc/arm/Bv9ARM.ch04.html
deleted file mode 100644
index 09507fe..0000000
--- a/contrib/bind9/doc/arm/Bv9ARM.ch04.html
+++ /dev/null
@@ -1,1028 +0,0 @@
-<!--
- - Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2000-2003 Internet Software Consortium.
- - 
- - Permission to use, copy, modify, and distribute this software for any
- - purpose with or without fee is hereby granted, provided that the above
- - copyright notice and this permission notice appear in all copies.
- - 
- - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
- - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- - PERFORMANCE OF THIS SOFTWARE.
--->
-<!-- $Id: Bv9ARM.ch04.html,v 1.40.18.41 2007/10/31 01:35:57 marka Exp $ -->
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>Chapter 4. Advanced DNS Features</title>
-<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
-<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="prev" href="Bv9ARM.ch03.html" title="Chapter 3. Name Server Configuration">
-<link rel="next" href="Bv9ARM.ch05.html" title="Chapter 5. The BIND 9 Lightweight Resolver">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
-<div class="navheader">
-<table width="100%" summary="Navigation header">
-<tr><th colspan="3" align="center">Chapter 4. Advanced DNS Features</th></tr>
-<tr>
-<td width="20%" align="left">
-<a accesskey="p" href="Bv9ARM.ch03.html">Prev</a> </td>
-<th width="60%" align="center"> </th>
-<td width="20%" align="right"> <a accesskey="n" href="Bv9ARM.ch05.html">Next</a>
-</td>
-</tr>
-</table>
-<hr>
-</div>
-<div class="chapter" lang="en">
-<div class="titlepage"><div><div><h2 class="title">
-<a name="Bv9ARM.ch04"></a>Chapter 4. Advanced DNS Features</h2></div></div></div>
-<div class="toc">
-<p><b>Table of Contents</b></p>
-<dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#notify">Notify</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#dynamic_update">Dynamic Update</a></span></dt>
-<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch04.html#journal">The journal file</a></span></dt></dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#incremental_zone_transfers">Incremental Zone Transfers (IXFR)</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2570642">Split DNS</a></span></dt>
-<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2570660">Example split DNS setup</a></span></dt></dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#tsig">TSIG</a></span></dt>
-<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571095">Generate Shared Keys for Each Pair of Hosts</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571169">Copying the Shared Secret to Both Machines</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571179">Informing the Servers of the Key's Existence</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571219">Instructing the Server to Use the Key</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571413">TSIG Key Based Access Control</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571458">Errors</a></span></dt>
-</dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571472">TKEY</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571521">SIG(0)</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#DNSSEC">DNSSEC</a></span></dt>
-<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571725">Generating Keys</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571795">Signing the Zone</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571874">Configuring Servers</a></span></dt>
-</dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2572153">IPv6 Support in <acronym class="acronym">BIND</acronym> 9</a></span></dt>
-<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572215">Address Lookups Using AAAA Records</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572236">Address to Name Lookups Using Nibble Format</a></span></dt>
-</dl></dd>
-</dl>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="notify"></a>Notify</h2></div></div></div>
-<p>
-        <acronym class="acronym">DNS</acronym> NOTIFY is a mechanism that allows master
-        servers to notify their slave servers of changes to a zone's data. In
-        response to a <span><strong class="command">NOTIFY</strong></span> from a master server, the
-        slave will check to see that its version of the zone is the
-        current version and, if not, initiate a zone transfer.
-      </p>
-<p>
-        For more information about <acronym class="acronym">DNS</acronym>
-        <span><strong class="command">NOTIFY</strong></span>, see the description of the
-        <span><strong class="command">notify</strong></span> option in <a href="Bv9ARM.ch06.html#boolean_options" title="Boolean Options">the section called &#8220;Boolean Options&#8221;</a> and
-        the description of the zone option <span><strong class="command">also-notify</strong></span> in
-        <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>.  The <span><strong class="command">NOTIFY</strong></span>
-        protocol is specified in RFC 1996.
-      </p>
-<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-        As a slave zone can also be a master to other slaves, named,
-        by default, sends <span><strong class="command">NOTIFY</strong></span> messages for every zone
-        it loads.  Specifying <span><strong class="command">notify master-only;</strong></span> will
-        cause named to only send <span><strong class="command">NOTIFY</strong></span> for master
-        zones that it loads.
-      </div>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="dynamic_update"></a>Dynamic Update</h2></div></div></div>
-<p>
-        Dynamic Update is a method for adding, replacing or deleting
-        records in a master server by sending it a special form of DNS
-        messages.  The format and meaning of these messages is specified
-        in RFC 2136.
-      </p>
-<p>
-        Dynamic update is enabled by
-        including an <span><strong class="command">allow-update</strong></span> or
-        <span><strong class="command">update-policy</strong></span> clause in the
-        <span><strong class="command">zone</strong></span> statement.
-      </p>
-<p>
-        Updating of secure zones (zones using DNSSEC) follows
-        RFC 3007: RRSIG and NSEC records affected by updates are automatically
-            regenerated by the server using an online zone key.
-        Update authorization is based
-        on transaction signatures and an explicit server policy.
-      </p>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="journal"></a>The journal file</h3></div></div></div>
-<p>
-          All changes made to a zone using dynamic update are stored
-          in the zone's journal file.  This file is automatically created
-          by the server when the first dynamic update takes place.
-          The name of the journal file is formed by appending the extension
-          <code class="filename">.jnl</code> to the name of the
-          corresponding zone
-          file unless specifically overridden.  The journal file is in a
-          binary format and should not be edited manually.
-        </p>
-<p>
-          The server will also occasionally write ("dump")
-          the complete contents of the updated zone to its zone file.
-          This is not done immediately after
-          each dynamic update, because that would be too slow when a large
-          zone is updated frequently.  Instead, the dump is delayed by
-          up to 15 minutes, allowing additional updates to take place.
-        </p>
-<p>
-          When a server is restarted after a shutdown or crash, it will replay
-              the journal file to incorporate into the zone any updates that
-          took
-          place after the last zone dump.
-        </p>
-<p>
-          Changes that result from incoming incremental zone transfers are
-          also
-          journalled in a similar way.
-        </p>
-<p>
-          The zone files of dynamic zones cannot normally be edited by
-          hand because they are not guaranteed to contain the most recent
-          dynamic changes &#8212; those are only in the journal file.
-          The only way to ensure that the zone file of a dynamic zone
-          is up to date is to run <span><strong class="command">rndc stop</strong></span>.
-        </p>
-<p>
-          If you have to make changes to a dynamic zone
-          manually, the following procedure will work: Disable dynamic updates
-              to the zone using
-          <span><strong class="command">rndc freeze <em class="replaceable"><code>zone</code></em></strong></span>.
-          This will also remove the zone's <code class="filename">.jnl</code> file
-          and update the master file.  Edit the zone file.  Run
-          <span><strong class="command">rndc thaw <em class="replaceable"><code>zone</code></em></strong></span>
-          to reload the changed zone and re-enable dynamic updates.
-        </p>
-</div>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="incremental_zone_transfers"></a>Incremental Zone Transfers (IXFR)</h2></div></div></div>
-<p>
-        The incremental zone transfer (IXFR) protocol is a way for
-        slave servers to transfer only changed data, instead of having to
-        transfer the entire zone. The IXFR protocol is specified in RFC
-        1995. See <a href="Bv9ARM.ch09.html#proposed_standards">Proposed Standards</a>.
-      </p>
-<p>
-        When acting as a master, <acronym class="acronym">BIND</acronym> 9
-        supports IXFR for those zones
-        where the necessary change history information is available. These
-        include master zones maintained by dynamic update and slave zones
-        whose data was obtained by IXFR.  For manually maintained master
-        zones, and for slave zones obtained by performing a full zone
-        transfer (AXFR), IXFR is supported only if the option
-        <span><strong class="command">ixfr-from-differences</strong></span> is set
-        to <strong class="userinput"><code>yes</code></strong>.
-      </p>
-<p>
-        When acting as a slave, <acronym class="acronym">BIND</acronym> 9 will
-        attempt to use IXFR unless
-        it is explicitly disabled. For more information about disabling
-        IXFR, see the description of the <span><strong class="command">request-ixfr</strong></span> clause
-        of the <span><strong class="command">server</strong></span> statement.
-      </p>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2570642"></a>Split DNS</h2></div></div></div>
-<p>
-        Setting up different views, or visibility, of the DNS space to
-        internal and external resolvers is usually referred to as a
-        <span class="emphasis"><em>Split DNS</em></span> setup. There are several
-        reasons an organization would want to set up its DNS this way.
-      </p>
-<p>
-        One common reason for setting up a DNS system this way is
-        to hide "internal" DNS information from "external" clients on the
-        Internet. There is some debate as to whether or not this is actually
-        useful.
-        Internal DNS information leaks out in many ways (via email headers,
-        for example) and most savvy "attackers" can find the information
-        they need using other means.
-        However, since listing addresses of internal servers that
-        external clients cannot possibly reach can result in
-        connection delays and other annoyances, an organization may
-        choose to use a Split DNS to present a consistent view of itself
-        to the outside world.
-      </p>
-<p>
-        Another common reason for setting up a Split DNS system is
-        to allow internal networks that are behind filters or in RFC 1918
-        space (reserved IP space, as documented in RFC 1918) to resolve DNS
-        on the Internet. Split DNS can also be used to allow mail from outside
-        back in to the internal network.
-      </p>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2570660"></a>Example split DNS setup</h3></div></div></div>
-<p>
-        Let's say a company named <span class="emphasis"><em>Example, Inc.</em></span>
-        (<code class="literal">example.com</code>)
-        has several corporate sites that have an internal network with
-        reserved
-        Internet Protocol (IP) space and an external demilitarized zone (DMZ),
-        or "outside" section of a network, that is available to the public.
-      </p>
-<p>
-        <span class="emphasis"><em>Example, Inc.</em></span> wants its internal clients
-        to be able to resolve external hostnames and to exchange mail with
-        people on the outside. The company also wants its internal resolvers
-        to have access to certain internal-only zones that are not available
-        at all outside of the internal network.
-      </p>
-<p>
-        In order to accomplish this, the company will set up two sets
-        of name servers. One set will be on the inside network (in the
-        reserved
-        IP space) and the other set will be on bastion hosts, which are
-        "proxy"
-        hosts that can talk to both sides of its network, in the DMZ.
-      </p>
-<p>
-        The internal servers will be configured to forward all queries,
-        except queries for <code class="filename">site1.internal</code>, <code class="filename">site2.internal</code>, <code class="filename">site1.example.com</code>,
-        and <code class="filename">site2.example.com</code>, to the servers
-        in the
-        DMZ. These internal servers will have complete sets of information
-        for <code class="filename">site1.example.com</code>, <code class="filename">site2.example.com</code>,<span class="emphasis"><em></em></span> <code class="filename">site1.internal</code>,
-        and <code class="filename">site2.internal</code>.
-      </p>
-<p>
-        To protect the <code class="filename">site1.internal</code> and <code class="filename">site2.internal</code> domains,
-        the internal name servers must be configured to disallow all queries
-        to these domains from any external hosts, including the bastion
-        hosts.
-      </p>
-<p>
-        The external servers, which are on the bastion hosts, will
-        be configured to serve the "public" version of the <code class="filename">site1</code> and <code class="filename">site2.example.com</code> zones.
-        This could include things such as the host records for public servers
-        (<code class="filename">www.example.com</code> and <code class="filename">ftp.example.com</code>),
-        and mail exchange (MX)  records (<code class="filename">a.mx.example.com</code> and <code class="filename">b.mx.example.com</code>).
-      </p>
-<p>
-        In addition, the public <code class="filename">site1</code> and <code class="filename">site2.example.com</code> zones
-        should have special MX records that contain wildcard (`*') records
-        pointing to the bastion hosts. This is needed because external mail
-        servers do not have any other way of looking up how to deliver mail
-        to those internal hosts. With the wildcard records, the mail will
-        be delivered to the bastion host, which can then forward it on to
-        internal hosts.
-      </p>
-<p>
-        Here's an example of a wildcard MX record:
-      </p>
-<pre class="programlisting">*   IN MX 10 external1.example.com.</pre>
-<p>
-        Now that they accept mail on behalf of anything in the internal
-        network, the bastion hosts will need to know how to deliver mail
-        to internal hosts. In order for this to work properly, the resolvers
-        on
-        the bastion hosts will need to be configured to point to the internal
-        name servers for DNS resolution.
-      </p>
-<p>
-        Queries for internal hostnames will be answered by the internal
-        servers, and queries for external hostnames will be forwarded back
-        out to the DNS servers on the bastion hosts.
-      </p>
-<p>
-        In order for all this to work properly, internal clients will
-        need to be configured to query <span class="emphasis"><em>only</em></span> the internal
-        name servers for DNS queries. This could also be enforced via
-        selective
-        filtering on the network.
-      </p>
-<p>
-        If everything has been set properly, <span class="emphasis"><em>Example, Inc.</em></span>'s
-        internal clients will now be able to:
-      </p>
-<div class="itemizedlist"><ul type="disc">
-<li>
-            Look up any hostnames in the <code class="literal">site1</code>
-            and
-            <code class="literal">site2.example.com</code> zones.
-          </li>
-<li>
-            Look up any hostnames in the <code class="literal">site1.internal</code> and
-            <code class="literal">site2.internal</code> domains.
-          </li>
-<li>Look up any hostnames on the Internet.</li>
-<li>Exchange mail with both internal and external people.</li>
-</ul></div>
-<p>
-        Hosts on the Internet will be able to:
-      </p>
-<div class="itemizedlist"><ul type="disc">
-<li>
-            Look up any hostnames in the <code class="literal">site1</code>
-            and
-            <code class="literal">site2.example.com</code> zones.
-          </li>
-<li>
-            Exchange mail with anyone in the <code class="literal">site1</code> and
-            <code class="literal">site2.example.com</code> zones.
-          </li>
-</ul></div>
-<p>
-        Here is an example configuration for the setup we just
-        described above. Note that this is only configuration information;
-        for information on how to configure your zone files, see <a href="Bv9ARM.ch03.html#sample_configuration" title="Sample Configurations">the section called &#8220;Sample Configurations&#8221;</a>.
-      </p>
-<p>
-        Internal DNS server config:
-      </p>
-<pre class="programlisting">
-
-acl internals { 172.16.72.0/24; 192.168.1.0/24; };
-
-acl externals { <code class="varname">bastion-ips-go-here</code>; };
-
-options {
-    ...
-    ...
-    forward only;
-    forwarders {                                // forward to external servers
-        <code class="varname">bastion-ips-go-here</code>;
-    };
-    allow-transfer { none; };                   // sample allow-transfer (no one)
-    allow-query { internals; externals; };      // restrict query access
-    allow-recursion { internals; };             // restrict recursion
-    ...
-    ...
-};
-
-zone "site1.example.com" {                      // sample master zone
-  type master;
-  file "m/site1.example.com";
-  forwarders { };                               // do normal iterative
-                                                // resolution (do not forward)
-  allow-query { internals; externals; };
-  allow-transfer { internals; };
-};
-
-zone "site2.example.com" {                      // sample slave zone
-  type slave;
-  file "s/site2.example.com";
-  masters { 172.16.72.3; };
-  forwarders { };
-  allow-query { internals; externals; };
-  allow-transfer { internals; };
-};
-
-zone "site1.internal" {
-  type master;
-  file "m/site1.internal";
-  forwarders { };
-  allow-query { internals; };
-  allow-transfer { internals; }
-};
-
-zone "site2.internal" {
-  type slave;
-  file "s/site2.internal";
-  masters { 172.16.72.3; };
-  forwarders { };
-  allow-query { internals };
-  allow-transfer { internals; }
-};
-</pre>
-<p>
-        External (bastion host) DNS server config:
-      </p>
-<pre class="programlisting">
-acl internals { 172.16.72.0/24; 192.168.1.0/24; };
-
-acl externals { bastion-ips-go-here; };
-
-options {
-  ...
-  ...
-  allow-transfer { none; };                     // sample allow-transfer (no one)
-  allow-query { any; };                         // default query access
-  allow-query-cache { internals; externals; };  // restrict cache access
-  allow-recursion { internals; externals; };    // restrict recursion
-  ...
-  ...
-};
-
-zone "site1.example.com" {                      // sample slave zone
-  type master;
-  file "m/site1.foo.com";
-  allow-transfer { internals; externals; };
-};
-
-zone "site2.example.com" {
-  type slave;
-  file "s/site2.foo.com";
-  masters { another_bastion_host_maybe; };
-  allow-transfer { internals; externals; }
-};
-</pre>
-<p>
-        In the <code class="filename">resolv.conf</code> (or equivalent) on
-        the bastion host(s):
-      </p>
-<pre class="programlisting">
-search ...
-nameserver 172.16.72.2
-nameserver 172.16.72.3
-nameserver 172.16.72.4
-</pre>
-</div>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="tsig"></a>TSIG</h2></div></div></div>
-<p>
-        This is a short guide to setting up Transaction SIGnatures
-        (TSIG) based transaction security in <acronym class="acronym">BIND</acronym>. It describes changes
-        to the configuration file as well as what changes are required for
-        different features, including the process of creating transaction
-        keys and using transaction signatures with <acronym class="acronym">BIND</acronym>.
-      </p>
-<p>
-        <acronym class="acronym">BIND</acronym> primarily supports TSIG for server
-        to server communication.
-        This includes zone transfer, notify, and recursive query messages.
-        Resolvers based on newer versions of <acronym class="acronym">BIND</acronym> 8 have limited support
-        for TSIG.
-      </p>
-<p>
-        TSIG can also be useful for dynamic update. A primary
-        server for a dynamic zone should control access to the dynamic
-        update service, but IP-based access control is insufficient.
-        The cryptographic access control provided by TSIG
-        is far superior. The <span><strong class="command">nsupdate</strong></span>
-        program supports TSIG via the <code class="option">-k</code> and
-        <code class="option">-y</code> command line options or inline by use
-        of the <span><strong class="command">key</strong></span>.
-      </p>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2571095"></a>Generate Shared Keys for Each Pair of Hosts</h3></div></div></div>
-<p>
-          A shared secret is generated to be shared between <span class="emphasis"><em>host1</em></span> and <span class="emphasis"><em>host2</em></span>.
-          An arbitrary key name is chosen: "host1-host2.". The key name must
-          be the same on both hosts.
-        </p>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2571112"></a>Automatic Generation</h4></div></div></div>
-<p>
-            The following command will generate a 128-bit (16 byte) HMAC-MD5
-            key as described above. Longer keys are better, but shorter keys
-            are easier to read. Note that the maximum key length is 512 bits;
-            keys longer than that will be digested with MD5 to produce a
-            128-bit key.
-          </p>
-<p>
-            <strong class="userinput"><code>dnssec-keygen -a hmac-md5 -b 128 -n HOST host1-host2.</code></strong>
-          </p>
-<p>
-            The key is in the file <code class="filename">Khost1-host2.+157+00000.private</code>.
-            Nothing directly uses this file, but the base-64 encoded string
-            following "<code class="literal">Key:</code>"
-            can be extracted from the file and used as a shared secret:
-          </p>
-<pre class="programlisting">Key: La/E5CjG9O+os1jq0a2jdA==</pre>
-<p>
-            The string "<code class="literal">La/E5CjG9O+os1jq0a2jdA==</code>" can
-            be used as the shared secret.
-          </p>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2571150"></a>Manual Generation</h4></div></div></div>
-<p>
-            The shared secret is simply a random sequence of bits, encoded
-            in base-64. Most ASCII strings are valid base-64 strings (assuming
-            the length is a multiple of 4 and only valid characters are used),
-            so the shared secret can be manually generated.
-          </p>
-<p>
-            Also, a known string can be run through <span><strong class="command">mmencode</strong></span> or
-            a similar program to generate base-64 encoded data.
-          </p>
-</div>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2571169"></a>Copying the Shared Secret to Both Machines</h3></div></div></div>
-<p>
-          This is beyond the scope of DNS. A secure transport mechanism
-          should be used. This could be secure FTP, ssh, telephone, etc.
-        </p>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2571179"></a>Informing the Servers of the Key's Existence</h3></div></div></div>
-<p>
-          Imagine <span class="emphasis"><em>host1</em></span> and <span class="emphasis"><em>host 2</em></span>
-          are
-          both servers. The following is added to each server's <code class="filename">named.conf</code> file:
-        </p>
-<pre class="programlisting">
-key host1-host2. {
-  algorithm hmac-md5;
-  secret "La/E5CjG9O+os1jq0a2jdA==";
-};
-</pre>
-<p>
-          The algorithm, hmac-md5, is the only one supported by <acronym class="acronym">BIND</acronym>.
-          The secret is the one generated above. Since this is a secret, it
-          is recommended that either <code class="filename">named.conf</code> be non-world
-          readable, or the key directive be added to a non-world readable
-          file that is included by
-          <code class="filename">named.conf</code>.
-        </p>
-<p>
-          At this point, the key is recognized. This means that if the
-          server receives a message signed by this key, it can verify the
-          signature. If the signature is successfully verified, the
-          response is signed by the same key.
-        </p>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2571219"></a>Instructing the Server to Use the Key</h3></div></div></div>
-<p>
-          Since keys are shared between two hosts only, the server must
-          be told when keys are to be used. The following is added to the <code class="filename">named.conf</code> file
-          for <span class="emphasis"><em>host1</em></span>, if the IP address of <span class="emphasis"><em>host2</em></span> is
-          10.1.2.3:
-        </p>
-<pre class="programlisting">
-server 10.1.2.3 {
-  keys { host1-host2. ;};
-};
-</pre>
-<p>
-          Multiple keys may be present, but only the first is used.
-          This directive does not contain any secrets, so it may be in a
-          world-readable
-          file.
-        </p>
-<p>
-          If <span class="emphasis"><em>host1</em></span> sends a message that is a request
-          to that address, the message will be signed with the specified key. <span class="emphasis"><em>host1</em></span> will
-          expect any responses to signed messages to be signed with the same
-          key.
-        </p>
-<p>
-          A similar statement must be present in <span class="emphasis"><em>host2</em></span>'s
-          configuration file (with <span class="emphasis"><em>host1</em></span>'s address) for <span class="emphasis"><em>host2</em></span> to
-          sign request messages to <span class="emphasis"><em>host1</em></span>.
-        </p>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2571413"></a>TSIG Key Based Access Control</h3></div></div></div>
-<p>
-          <acronym class="acronym">BIND</acronym> allows IP addresses and ranges
-          to be specified in ACL
-          definitions and
-          <span><strong class="command">allow-{ query | transfer | update }</strong></span>
-          directives.
-          This has been extended to allow TSIG keys also. The above key would
-          be denoted <span><strong class="command">key host1-host2.</strong></span>
-        </p>
-<p>
-          An example of an allow-update directive would be:
-        </p>
-<pre class="programlisting">
-allow-update { key host1-host2. ;};
-</pre>
-<p>
-          This allows dynamic updates to succeed only if the request
-          was signed by a key named
-          "<span><strong class="command">host1-host2.</strong></span>".
-        </p>
-<p>
-          You may want to read about the more
-          powerful <span><strong class="command">update-policy</strong></span> statement in <a href="Bv9ARM.ch06.html#dynamic_update_policies" title="Dynamic Update Policies">the section called &#8220;Dynamic Update Policies&#8221;</a>.
-        </p>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2571458"></a>Errors</h3></div></div></div>
-<p>
-          The processing of TSIG signed messages can result in
-          several errors. If a signed message is sent to a non-TSIG aware
-          server, a FORMERR (format error) will be returned, since the server will not
-          understand the record. This is a result of misconfiguration,
-          since the server must be explicitly configured to send a TSIG
-          signed message to a specific server.
-        </p>
-<p>
-          If a TSIG aware server receives a message signed by an
-          unknown key, the response will be unsigned with the TSIG
-          extended error code set to BADKEY. If a TSIG aware server
-          receives a message with a signature that does not validate, the
-          response will be unsigned with the TSIG extended error code set
-          to BADSIG. If a TSIG aware server receives a message with a time
-          outside of the allowed range, the response will be signed with
-          the TSIG extended error code set to BADTIME, and the time values
-          will be adjusted so that the response can be successfully
-          verified. In any of these cases, the message's rcode (response code) is set to
-          NOTAUTH (not authenticated).
-        </p>
-</div>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2571472"></a>TKEY</h2></div></div></div>
-<p><span><strong class="command">TKEY</strong></span>
-        is a mechanism for automatically generating a shared secret
-        between two hosts.  There are several "modes" of
-        <span><strong class="command">TKEY</strong></span> that specify how the key is generated
-        or assigned.  <acronym class="acronym">BIND</acronym> 9 implements only one of
-        these modes, the Diffie-Hellman key exchange.  Both hosts are
-        required to have a Diffie-Hellman KEY record (although this
-        record is not required to be present in a zone).  The
-        <span><strong class="command">TKEY</strong></span> process must use signed messages,
-        signed either by TSIG or SIG(0).  The result of
-        <span><strong class="command">TKEY</strong></span> is a shared secret that can be used to
-        sign messages with TSIG.  <span><strong class="command">TKEY</strong></span> can also be
-        used to delete shared secrets that it had previously
-        generated.
-      </p>
-<p>
-        The <span><strong class="command">TKEY</strong></span> process is initiated by a
-        client
-        or server by sending a signed <span><strong class="command">TKEY</strong></span>
-        query
-        (including any appropriate KEYs) to a TKEY-aware server.  The
-        server response, if it indicates success, will contain a
-        <span><strong class="command">TKEY</strong></span> record and any appropriate keys.
-        After
-        this exchange, both participants have enough information to
-        determine the shared secret; the exact process depends on the
-        <span><strong class="command">TKEY</strong></span> mode.  When using the
-        Diffie-Hellman
-        <span><strong class="command">TKEY</strong></span> mode, Diffie-Hellman keys are
-        exchanged,
-        and the shared secret is derived by both participants.
-      </p>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2571521"></a>SIG(0)</h2></div></div></div>
-<p>
-        <acronym class="acronym">BIND</acronym> 9 partially supports DNSSEC SIG(0)
-            transaction signatures as specified in RFC 2535 and RFC2931.
-        SIG(0)
-        uses public/private keys to authenticate messages.  Access control
-        is performed in the same manner as TSIG keys; privileges can be
-        granted or denied based on the key name.
-      </p>
-<p>
-        When a SIG(0) signed message is received, it will only be
-        verified if the key is known and trusted by the server; the server
-        will not attempt to locate and/or validate the key.
-      </p>
-<p>
-        SIG(0) signing of multiple-message TCP streams is not
-        supported.
-      </p>
-<p>
-        The only tool shipped with <acronym class="acronym">BIND</acronym> 9 that
-        generates SIG(0) signed messages is <span><strong class="command">nsupdate</strong></span>.
-      </p>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="DNSSEC"></a>DNSSEC</h2></div></div></div>
-<p>
-        Cryptographic authentication of DNS information is possible
-        through the DNS Security (<span class="emphasis"><em>DNSSEC-bis</em></span>) extensions,
-        defined in RFC 4033, RFC 4034, and RFC 4035.
-        This section describes the creation and use of DNSSEC signed zones.
-      </p>
-<p>
-        In order to set up a DNSSEC secure zone, there are a series
-        of steps which must be followed.  <acronym class="acronym">BIND</acronym>
-        9 ships
-        with several tools
-        that are used in this process, which are explained in more detail
-        below.  In all cases, the <code class="option">-h</code> option prints a
-        full list of parameters.  Note that the DNSSEC tools require the
-        keyset files to be in the working directory or the
-        directory specified by the <code class="option">-d</code> option, and
-        that the tools shipped with BIND 9.2.x and earlier are not compatible
-        with the current ones.
-      </p>
-<p>
-        There must also be communication with the administrators of
-        the parent and/or child zone to transmit keys.  A zone's security
-        status must be indicated by the parent zone for a DNSSEC capable
-        resolver to trust its data.  This is done through the presence
-        or absence of a <code class="literal">DS</code> record at the
-        delegation
-        point.
-      </p>
-<p>
-        For other servers to trust data in this zone, they must
-        either be statically configured with this zone's zone key or the
-        zone key of another zone above this one in the DNS tree.
-      </p>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2571725"></a>Generating Keys</h3></div></div></div>
-<p>
-          The <span><strong class="command">dnssec-keygen</strong></span> program is used to
-          generate keys.
-        </p>
-<p>
-          A secure zone must contain one or more zone keys.  The
-          zone keys will sign all other records in the zone, as well as
-          the zone keys of any secure delegated zones.  Zone keys must
-          have the same name as the zone, a name type of
-          <span><strong class="command">ZONE</strong></span>, and must be usable for
-          authentication.
-          It is recommended that zone keys use a cryptographic algorithm
-          designated as "mandatory to implement" by the IETF; currently
-          the only one is RSASHA1.
-        </p>
-<p>
-          The following command will generate a 768-bit RSASHA1 key for
-          the <code class="filename">child.example</code> zone:
-        </p>
-<p>
-          <strong class="userinput"><code>dnssec-keygen -a RSASHA1 -b 768 -n ZONE child.example.</code></strong>
-        </p>
-<p>
-          Two output files will be produced:
-          <code class="filename">Kchild.example.+005+12345.key</code> and
-          <code class="filename">Kchild.example.+005+12345.private</code>
-          (where
-          12345 is an example of a key tag).  The key filenames contain
-          the key name (<code class="filename">child.example.</code>),
-          algorithm (3
-          is DSA, 1 is RSAMD5, 5 is RSASHA1, etc.), and the key tag (12345 in
-          this case).
-          The private key (in the <code class="filename">.private</code>
-          file) is
-          used to generate signatures, and the public key (in the
-          <code class="filename">.key</code> file) is used for signature
-          verification.
-        </p>
-<p>
-          To generate another key with the same properties (but with
-          a different key tag), repeat the above command.
-        </p>
-<p>
-          The public keys should be inserted into the zone file by
-          including the <code class="filename">.key</code> files using
-          <span><strong class="command">$INCLUDE</strong></span> statements.
-        </p>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2571795"></a>Signing the Zone</h3></div></div></div>
-<p>
-          The <span><strong class="command">dnssec-signzone</strong></span> program is used
-          to
-          sign a zone.
-        </p>
-<p>
-          Any <code class="filename">keyset</code> files corresponding
-          to secure subzones should be present.  The zone signer will
-          generate <code class="literal">NSEC</code> and <code class="literal">RRSIG</code>
-          records for the zone, as well as <code class="literal">DS</code>
-          for
-          the child zones if <code class="literal">'-d'</code> is specified.
-                If <code class="literal">'-d'</code> is not specified, then
-          DS RRsets for
-          the secure child zones need to be added manually.
-        </p>
-<p>
-          The following command signs the zone, assuming it is in a
-          file called <code class="filename">zone.child.example</code>.  By
-                default, all zone keys which have an available private key are
-                used to generate signatures.
-        </p>
-<p>
-          <strong class="userinput"><code>dnssec-signzone -o child.example zone.child.example</code></strong>
-        </p>
-<p>
-          One output file is produced:
-          <code class="filename">zone.child.example.signed</code>.  This
-          file
-          should be referenced by <code class="filename">named.conf</code>
-          as the
-          input file for the zone.
-        </p>
-<p><span><strong class="command">dnssec-signzone</strong></span>
-          will also produce a keyset and dsset files and optionally a
-          dlvset file.  These are used to provide the parent zone
-          administrators with the <code class="literal">DNSKEYs</code> (or their
-          corresponding <code class="literal">DS</code> records) that are the
-          secure entry point to the zone.
-        </p>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2571874"></a>Configuring Servers</h3></div></div></div>
-<p>
-          To enable <span><strong class="command">named</strong></span> to respond appropriately
-          to DNS requests from DNSSEC aware clients,
-          <span><strong class="command">dnssec-enable</strong></span> must be set to yes.
-        </p>
-<p>
-          To enable <span><strong class="command">named</strong></span> to validate answers from
-          other servers both <span><strong class="command">dnssec-enable</strong></span> and
-          <span><strong class="command">dnssec-validation</strong></span> must be set and some
-          <span><strong class="command">trusted-keys</strong></span> must be configured
-          into <code class="filename">named.conf</code>.
-        </p>
-<p>
-          <span><strong class="command">trusted-keys</strong></span> are copies of DNSKEY RRs
-          for zones that are used to form the first link in the
-          cryptographic chain of trust.  All keys listed in
-          <span><strong class="command">trusted-keys</strong></span> (and corresponding zones)
-          are deemed to exist and only the listed keys will be used
-          to validated the DNSKEY RRset that they are from.
-        </p>
-<p>
-          <span><strong class="command">trusted-keys</strong></span> are described in more detail
-          later in this document.
-        </p>
-<p>
-          Unlike <acronym class="acronym">BIND</acronym> 8, <acronym class="acronym">BIND</acronym>
-          9 does not verify signatures on load, so zone keys for
-          authoritative zones do not need to be specified in the
-          configuration file.
-        </p>
-<p>
-          After DNSSEC gets established, a typical DNSSEC configuration
-          will look something like the following.  It has a one or
-          more public keys for the root.  This allows answers from
-          outside the organization to be validated.  It will also
-          have several keys for parts of the namespace the organization
-          controls.  These are here to ensure that named is immune
-          to compromises in the DNSSEC components of the security
-          of parent zones.
-        </p>
-<pre class="programlisting">
-trusted-keys {
-
-        /* Root Key */
-"." 257 3 3 "BNY4wrWM1nCfJ+CXd0rVXyYmobt7sEEfK3clRbGaTwSJxrGkxJWoZu6I7PzJu/
-             E9gx4UC1zGAHlXKdE4zYIpRhaBKnvcC2U9mZhkdUpd1Vso/HAdjNe8LmMlnzY3
-             zy2Xy4klWOADTPzSv9eamj8V18PHGjBLaVtYvk/ln5ZApjYghf+6fElrmLkdaz
-             MQ2OCnACR817DF4BBa7UR/beDHyp5iWTXWSi6XmoJLbG9Scqc7l70KDqlvXR3M
-             /lUUVRbkeg1IPJSidmK3ZyCllh4XSKbje/45SKucHgnwU5jefMtq66gKodQj+M
-             iA21AfUVe7u99WzTLzY3qlxDhxYQQ20FQ97S+LKUTpQcq27R7AT3/V5hRQxScI
-             Nqwcz4jYqZD2fQdgxbcDTClU0CRBdiieyLMNzXG3";
-
-/* Key for our organization's forward zone */
-example.com. 257 3 5 "AwEAAaxPMcR2x0HbQV4WeZB6oEDX+r0QM65KbhTjrW1ZaARmPhEZZe
-                      3Y9ifgEuq7vZ/zGZUdEGNWy+JZzus0lUptwgjGwhUS1558Hb4JKUbb
-                      OTcM8pwXlj0EiX3oDFVmjHO444gLkBO UKUf/mC7HvfwYH/Be22GnC
-                      lrinKJp1Og4ywzO9WglMk7jbfW33gUKvirTHr25GL7STQUzBb5Usxt
-                      8lgnyTUHs1t3JwCY5hKZ6CqFxmAVZP20igTixin/1LcrgX/KMEGd/b
-                      iuvF4qJCyduieHukuY3H4XMAcR+xia2 nIUPvm/oyWR8BW/hWdzOvn
-                      SCThlHf3xiYleDbt/o1OTQ09A0=";
-
-/* Key for our reverse zone. */
-2.0.192.IN-ADDRPA.NET. 257 3 5 "AQOnS4xn/IgOUpBPJ3bogzwcxOdNax071L18QqZnQQQA
-                                VVr+iLhGTnNGp3HoWQLUIzKrJVZ3zggy3WwNT6kZo6c0
-                                tszYqbtvchmgQC8CzKojM/W16i6MG/ea fGU3siaOdS0
-                                yOI6BgPsw+YZdzlYMaIJGf4M4dyoKIhzdZyQ2bYQrjyQ
-                                4LB0lC7aOnsMyYKHHYeRv PxjIQXmdqgOJGq+vsevG06
-                                zW+1xgYJh9rCIfnm1GX/KMgxLPG2vXTD/RnLX+D3T3UL
-                                7HJYHJhAZD5L59VvjSPsZJHeDCUyWYrvPZesZDIRvhDD
-                                52SKvbheeTJUm6EhkzytNN2SN96QRk8j/iI8ib";
-};
-
-options {
-        ...
-        dnssec-enable yes;
-        dnssec-validation yes;
-};
-</pre>
-<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-          None of the keys listed in this example are valid.  In particular,
-          the root key is not valid.
-        </div>
-</div>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2572153"></a>IPv6 Support in <acronym class="acronym">BIND</acronym> 9</h2></div></div></div>
-<p>
-        <acronym class="acronym">BIND</acronym> 9 fully supports all currently
-        defined forms of IPv6
-        name to address and address to name lookups.  It will also use
-        IPv6 addresses to make queries when running on an IPv6 capable
-        system.
-      </p>
-<p>
-        For forward lookups, <acronym class="acronym">BIND</acronym> 9 supports
-        only AAAA records.  RFC 3363 deprecated the use of A6 records,
-        and client-side support for A6 records was accordingly removed
-        from <acronym class="acronym">BIND</acronym> 9.
-        However, authoritative <acronym class="acronym">BIND</acronym> 9 name servers still
-        load zone files containing A6 records correctly, answer queries
-        for A6 records, and accept zone transfer for a zone containing A6
-        records.
-      </p>
-<p>
-        For IPv6 reverse lookups, <acronym class="acronym">BIND</acronym> 9 supports
-        the traditional "nibble" format used in the
-        <span class="emphasis"><em>ip6.arpa</em></span> domain, as well as the older, deprecated
-        <span class="emphasis"><em>ip6.int</em></span> domain.
-        Older versions of <acronym class="acronym">BIND</acronym> 9 
-        supported the "binary label" (also known as "bitstring") format,
-        but support of binary labels has been completely removed per
-        RFC 3363.
-        Many applications in <acronym class="acronym">BIND</acronym> 9 do not understand
-        the binary label format at all any more, and will return an
-        error if given.
-        In particular, an authoritative <acronym class="acronym">BIND</acronym> 9
-        name server will not load a zone file containing binary labels.
-      </p>
-<p>
-        For an overview of the format and structure of IPv6 addresses,
-        see <a href="Bv9ARM.ch09.html#ipv6addresses" title="IPv6 addresses (AAAA)">the section called &#8220;IPv6 addresses (AAAA)&#8221;</a>.
-      </p>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2572215"></a>Address Lookups Using AAAA Records</h3></div></div></div>
-<p>
-          The IPv6 AAAA record is a parallel to the IPv4 A record,
-          and, unlike the deprecated A6 record, specifies the entire
-          IPv6 address in a single record.  For example,
-        </p>
-<pre class="programlisting">
-$ORIGIN example.com.
-host            3600    IN      AAAA    2001:db8::1
-</pre>
-<p>
-          Use of IPv4-in-IPv6 mapped addresses is not recommended.
-          If a host has an IPv4 address, use an A record, not
-          a AAAA, with <code class="literal">::ffff:192.168.42.1</code> as
-          the address.
-        </p>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2572236"></a>Address to Name Lookups Using Nibble Format</h3></div></div></div>
-<p>
-          When looking up an address in nibble format, the address
-          components are simply reversed, just as in IPv4, and
-          <code class="literal">ip6.arpa.</code> is appended to the
-          resulting name.
-          For example, the following would provide reverse name lookup for
-          a host with address
-          <code class="literal">2001:db8::1</code>.
-        </p>
-<pre class="programlisting">
-$ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
-1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0   14400 IN      PTR     host.example.com.
-</pre>
-</div>
-</div>
-</div>
-<div class="navfooter">
-<hr>
-<table width="100%" summary="Navigation footer">
-<tr>
-<td width="40%" align="left">
-<a accesskey="p" href="Bv9ARM.ch03.html">Prev</a> </td>
-<td width="20%" align="center"> </td>
-<td width="40%" align="right"> <a accesskey="n" href="Bv9ARM.ch05.html">Next</a>
-</td>
-</tr>
-<tr>
-<td width="40%" align="left" valign="top">Chapter 3. Name Server Configuration </td>
-<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
-<td width="40%" align="right" valign="top"> Chapter 5. The <acronym class="acronym">BIND</acronym> 9 Lightweight Resolver</td>
-</tr>
-</table>
-</div>
-</body>
-</html>
diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch05.html b/contrib/bind9/doc/arm/Bv9ARM.ch05.html
deleted file mode 100644
index 80418b9..0000000
--- a/contrib/bind9/doc/arm/Bv9ARM.ch05.html
+++ /dev/null
@@ -1,143 +0,0 @@
-<!--
- - Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2000-2003 Internet Software Consortium.
- - 
- - Permission to use, copy, modify, and distribute this software for any
- - purpose with or without fee is hereby granted, provided that the above
- - copyright notice and this permission notice appear in all copies.
- - 
- - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
- - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- - PERFORMANCE OF THIS SOFTWARE.
--->
-<!-- $Id: Bv9ARM.ch05.html,v 1.33.18.33 2007/10/31 01:35:58 marka Exp $ -->
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>Chapter 5. The BIND 9 Lightweight Resolver</title>
-<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
-<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="prev" href="Bv9ARM.ch04.html" title="Chapter 4. Advanced DNS Features">
-<link rel="next" href="Bv9ARM.ch06.html" title="Chapter 6. BIND 9 Configuration Reference">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
-<div class="navheader">
-<table width="100%" summary="Navigation header">
-<tr><th colspan="3" align="center">Chapter 5. The <acronym class="acronym">BIND</acronym> 9 Lightweight Resolver</th></tr>
-<tr>
-<td width="20%" align="left">
-<a accesskey="p" href="Bv9ARM.ch04.html">Prev</a> </td>
-<th width="60%" align="center"> </th>
-<td width="20%" align="right"> <a accesskey="n" href="Bv9ARM.ch06.html">Next</a>
-</td>
-</tr>
-</table>
-<hr>
-</div>
-<div class="chapter" lang="en">
-<div class="titlepage"><div><div><h2 class="title">
-<a name="Bv9ARM.ch05"></a>Chapter 5. The <acronym class="acronym">BIND</acronym> 9 Lightweight Resolver</h2></div></div></div>
-<div class="toc">
-<p><b>Table of Contents</b></p>
-<dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch05.html#id2572269">The Lightweight Resolver Library</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch05.html#lwresd">Running a Resolver Daemon</a></span></dt>
-</dl>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2572269"></a>The Lightweight Resolver Library</h2></div></div></div>
-<p>
-        Traditionally applications have been linked with a stub resolver
-        library that sends recursive DNS queries to a local caching name
-        server.
-      </p>
-<p>
-        IPv6 once introduced new complexity into the resolution process,
-        such as following A6 chains and DNAME records, and simultaneous
-        lookup of IPv4 and IPv6 addresses.  Though most of the complexity was
-        then removed, these are hard or impossible
-        to implement in a traditional stub resolver.
-      </p>
-<p>
-        <acronym class="acronym">BIND</acronym> 9 therefore can also provide resolution
-        services to local clients
-        using a combination of a lightweight resolver library and a resolver
-        daemon process running on the local host.  These communicate using
-        a simple UDP-based protocol, the "lightweight resolver protocol"
-        that is distinct from and simpler than the full DNS protocol.
-      </p>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="lwresd"></a>Running a Resolver Daemon</h2></div></div></div>
-<p>
-        To use the lightweight resolver interface, the system must
-        run the resolver daemon <span><strong class="command">lwresd</strong></span> or a
-        local
-        name server configured with a <span><strong class="command">lwres</strong></span>
-        statement.
-      </p>
-<p>
-        By default, applications using the lightweight resolver library will
-        make
-        UDP requests to the IPv4 loopback address (127.0.0.1) on port 921.
-        The
-        address can be overridden by <span><strong class="command">lwserver</strong></span>
-        lines in
-        <code class="filename">/etc/resolv.conf</code>.
-      </p>
-<p>
-        The daemon currently only looks in the DNS, but in the future
-        it may use other sources such as <code class="filename">/etc/hosts</code>,
-        NIS, etc.
-      </p>
-<p>
-        The <span><strong class="command">lwresd</strong></span> daemon is essentially a
-        caching-only name server that responds to requests using the
-        lightweight
-        resolver protocol rather than the DNS protocol.  Because it needs
-        to run on each host, it is designed to require no or minimal
-        configuration.
-        Unless configured otherwise, it uses the name servers listed on
-        <span><strong class="command">nameserver</strong></span> lines in <code class="filename">/etc/resolv.conf</code>
-        as forwarders, but is also capable of doing the resolution
-        autonomously if
-        none are specified.
-      </p>
-<p>
-        The <span><strong class="command">lwresd</strong></span> daemon may also be
-        configured with a
-        <code class="filename">named.conf</code> style configuration file,
-        in
-        <code class="filename">/etc/lwresd.conf</code> by default.  A name
-        server may also
-        be configured to act as a lightweight resolver daemon using the
-        <span><strong class="command">lwres</strong></span> statement in <code class="filename">named.conf</code>.
-      </p>
-</div>
-</div>
-<div class="navfooter">
-<hr>
-<table width="100%" summary="Navigation footer">
-<tr>
-<td width="40%" align="left">
-<a accesskey="p" href="Bv9ARM.ch04.html">Prev</a> </td>
-<td width="20%" align="center"> </td>
-<td width="40%" align="right"> <a accesskey="n" href="Bv9ARM.ch06.html">Next</a>
-</td>
-</tr>
-<tr>
-<td width="40%" align="left" valign="top">Chapter 4. Advanced DNS Features </td>
-<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
-<td width="40%" align="right" valign="top"> Chapter 6. <acronym class="acronym">BIND</acronym> 9 Configuration Reference</td>
-</tr>
-</table>
-</div>
-</body>
-</html>
diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch06.html b/contrib/bind9/doc/arm/Bv9ARM.ch06.html
deleted file mode 100644
index d829a17..0000000
--- a/contrib/bind9/doc/arm/Bv9ARM.ch06.html
+++ /dev/null
@@ -1,7114 +0,0 @@
-<!--
- - Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2000-2003 Internet Software Consortium.
- - 
- - Permission to use, copy, modify, and distribute this software for any
- - purpose with or without fee is hereby granted, provided that the above
- - copyright notice and this permission notice appear in all copies.
- - 
- - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
- - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- - PERFORMANCE OF THIS SOFTWARE.
--->
-<!-- $Id: Bv9ARM.ch06.html,v 1.82.18.73 2007/10/31 01:35:58 marka Exp $ -->
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>Chapter 6. BIND 9 Configuration Reference</title>
-<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
-<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="prev" href="Bv9ARM.ch05.html" title="Chapter 5. The BIND 9 Lightweight Resolver">
-<link rel="next" href="Bv9ARM.ch07.html" title="Chapter 7. BIND 9 Security Considerations">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
-<div class="navheader">
-<table width="100%" summary="Navigation header">
-<tr><th colspan="3" align="center">Chapter 6. <acronym class="acronym">BIND</acronym> 9 Configuration Reference</th></tr>
-<tr>
-<td width="20%" align="left">
-<a accesskey="p" href="Bv9ARM.ch05.html">Prev</a> </td>
-<th width="60%" align="center"> </th>
-<td width="20%" align="right"> <a accesskey="n" href="Bv9ARM.ch07.html">Next</a>
-</td>
-</tr>
-</table>
-<hr>
-</div>
-<div class="chapter" lang="en">
-<div class="titlepage"><div><div><h2 class="title">
-<a name="Bv9ARM.ch06"></a>Chapter 6. <acronym class="acronym">BIND</acronym> 9 Configuration Reference</h2></div></div></div>
-<div class="toc">
-<p><b>Table of Contents</b></p>
-<dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch06.html#configuration_file_elements">Configuration File Elements</a></span></dt>
-<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#address_match_lists">Address Match Lists</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2573480">Comment Syntax</a></span></dt>
-</dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch06.html#Configuration_File_Grammar">Configuration File Grammar</a></span></dt>
-<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574092"><span><strong class="command">acl</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#acl"><span><strong class="command">acl</strong></span> Statement Definition and
-          Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574282"><span><strong class="command">controls</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#controls_statement_definition_and_usage"><span><strong class="command">controls</strong></span> Statement Definition and
-          Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574711"><span><strong class="command">include</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574726"><span><strong class="command">include</strong></span> Statement Definition and
-          Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574749"><span><strong class="command">key</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574771"><span><strong class="command">key</strong></span> Statement Definition and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574930"><span><strong class="command">logging</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575056"><span><strong class="command">logging</strong></span> Statement Definition and
-          Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2576406"><span><strong class="command">lwres</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2576480"><span><strong class="command">lwres</strong></span> Statement Definition and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2576544"><span><strong class="command">masters</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2576587"><span><strong class="command">masters</strong></span> Statement Definition and
-          Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2576602"><span><strong class="command">options</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#options"><span><strong class="command">options</strong></span> Statement Definition and
-          Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#server_statement_grammar"><span><strong class="command">server</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#server_statement_definition_and_usage"><span><strong class="command">server</strong></span> Statement Definition and
-            Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2585361"><span><strong class="command">trusted-keys</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2585410"><span><strong class="command">trusted-keys</strong></span> Statement Definition
-            and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#view_statement_grammar"><span><strong class="command">view</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2585490"><span><strong class="command">view</strong></span> Statement Definition and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#zone_statement_grammar"><span><strong class="command">zone</strong></span>
-            Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2586798"><span><strong class="command">zone</strong></span> Statement Definition and Usage</a></span></dt>
-</dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch06.html#id2589080">Zone File</a></span></dt>
-<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#types_of_resource_records_and_when_to_use_them">Types of Resource Records and When to Use Them</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2591101">Discussion of MX Records</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#Setting_TTLs">Setting TTLs</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2591653">Inverse Mapping in IPv4</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2591848">Other Zone File Directives</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2592173"><acronym class="acronym">BIND</acronym> Master File Extension: the  <span><strong class="command">$GENERATE</strong></span> Directive</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#zonefile_format">Additional File Formats</a></span></dt>
-</dl></dd>
-</dl>
-</div>
-<p>
-      <acronym class="acronym">BIND</acronym> 9 configuration is broadly similar
-      to <acronym class="acronym">BIND</acronym> 8; however, there are a few new
-      areas
-      of configuration, such as views. <acronym class="acronym">BIND</acronym>
-      8 configuration files should work with few alterations in <acronym class="acronym">BIND</acronym>
-      9, although more complex configurations should be reviewed to check
-      if they can be more efficiently implemented using the new features
-      found in <acronym class="acronym">BIND</acronym> 9.
-    </p>
-<p>
-      <acronym class="acronym">BIND</acronym> 4 configuration files can be
-      converted to the new format
-      using the shell script
-      <code class="filename">contrib/named-bootconf/named-bootconf.sh</code>.
-    </p>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="configuration_file_elements"></a>Configuration File Elements</h2></div></div></div>
-<p>
-        Following is a list of elements used throughout the <acronym class="acronym">BIND</acronym> configuration
-        file documentation:
-      </p>
-<div class="informaltable"><table border="1">
-<colgroup>
-<col>
-<col>
-</colgroup>
-<tbody>
-<tr>
-<td>
-                <p>
-                  <code class="varname">acl_name</code>
-                </p>
-              </td>
-<td>
-                <p>
-                  The name of an <code class="varname">address_match_list</code> as
-                  defined by the <span><strong class="command">acl</strong></span> statement.
-                </p>
-              </td>
-</tr>
-<tr>
-<td>
-                <p>
-                  <code class="varname">address_match_list</code>
-                </p>
-              </td>
-<td>
-                <p>
-                  A list of one or more
-                  <code class="varname">ip_addr</code>,
-                  <code class="varname">ip_prefix</code>, <code class="varname">key_id</code>,
-                  or <code class="varname">acl_name</code> elements, see
-                  <a href="Bv9ARM.ch06.html#address_match_lists" title="Address Match Lists">the section called &#8220;Address Match Lists&#8221;</a>.
-                </p>
-              </td>
-</tr>
-<tr>
-<td>
-                <p>
-                  <code class="varname">masters_list</code>
-                </p>
-              </td>
-<td>
-                <p>
-                  A named list of one or more <code class="varname">ip_addr</code>
-                  with optional <code class="varname">key_id</code> and/or
-                  <code class="varname">ip_port</code>.
-                  A <code class="varname">masters_list</code> may include other
-                  <code class="varname">masters_lists</code>.
-                </p>
-              </td>
-</tr>
-<tr>
-<td>
-                <p>
-                  <code class="varname">domain_name</code>
-                </p>
-              </td>
-<td>
-                <p>
-                  A quoted string which will be used as
-                  a DNS name, for example "<code class="literal">my.test.domain</code>".
-                </p>
-              </td>
-</tr>
-<tr>
-<td>
-                <p>
-                  <code class="varname">dotted_decimal</code>
-                </p>
-              </td>
-<td>
-                <p>
-                  One to four integers valued 0 through
-                  255 separated by dots (`.'), such as <span><strong class="command">123</strong></span>,
-                  <span><strong class="command">45.67</strong></span> or <span><strong class="command">89.123.45.67</strong></span>.
-                </p>
-              </td>
-</tr>
-<tr>
-<td>
-                <p>
-                  <code class="varname">ip4_addr</code>
-                </p>
-              </td>
-<td>
-                <p>
-                  An IPv4 address with exactly four elements
-                  in <code class="varname">dotted_decimal</code> notation.
-                </p>
-              </td>
-</tr>
-<tr>
-<td>
-                <p>
-                  <code class="varname">ip6_addr</code>
-                </p>
-              </td>
-<td>
-                <p>
-                  An IPv6 address, such as <span><strong class="command">2001:db8::1234</strong></span>.
-                  IPv6 scoped addresses that have ambiguity on their scope
-                  zones must be
-                  disambiguated by an appropriate zone ID with the percent
-                  character
-                  (`%') as delimiter.
-                  It is strongly recommended to use string zone names rather
-                  than
-                  numeric identifiers, in order to be robust against system
-                  configuration changes.
-                  However, since there is no standard mapping for such names
-                  and
-                  identifier values, currently only interface names as link
-                  identifiers
-                  are supported, assuming one-to-one mapping between
-                  interfaces and links.
-                  For example, a link-local address <span><strong class="command">fe80::1</strong></span> on the
-                  link attached to the interface <span><strong class="command">ne0</strong></span>
-                  can be specified as <span><strong class="command">fe80::1%ne0</strong></span>.
-                  Note that on most systems link-local addresses always have
-                  the
-                  ambiguity, and need to be disambiguated.
-                </p>
-              </td>
-</tr>
-<tr>
-<td>
-                <p>
-                  <code class="varname">ip_addr</code>
-                </p>
-              </td>
-<td>
-                <p>
-                  An <code class="varname">ip4_addr</code> or <code class="varname">ip6_addr</code>.
-                </p>
-              </td>
-</tr>
-<tr>
-<td>
-                <p>
-                  <code class="varname">ip_port</code>
-                </p>
-              </td>
-<td>
-                <p>
-                  An IP port <code class="varname">number</code>.
-                  The <code class="varname">number</code> is limited to 0
-                  through 65535, with values
-                  below 1024 typically restricted to use by processes running
-                  as root.
-                  In some cases, an asterisk (`*') character can be used as a
-                  placeholder to
-                  select a random high-numbered port.
-                </p>
-              </td>
-</tr>
-<tr>
-<td>
-                <p>
-                  <code class="varname">ip_prefix</code>
-                </p>
-              </td>
-<td>
-                <p>
-                  An IP network specified as an <code class="varname">ip_addr</code>,
-                  followed by a slash (`/') and then the number of bits in the
-                  netmask.
-                  Trailing zeros in a <code class="varname">ip_addr</code>
-                  may omitted.
-                  For example, <span><strong class="command">127/8</strong></span> is the
-                  network <span><strong class="command">127.0.0.0</strong></span> with
-                  netmask <span><strong class="command">255.0.0.0</strong></span> and <span><strong class="command">1.2.3.0/28</strong></span> is
-                  network <span><strong class="command">1.2.3.0</strong></span> with netmask <span><strong class="command">255.255.255.240</strong></span>.
-                </p>
-              </td>
-</tr>
-<tr>
-<td>
-                <p>
-                  <code class="varname">key_id</code>
-                </p>
-              </td>
-<td>
-                <p>
-                  A <code class="varname">domain_name</code> representing
-                  the name of a shared key, to be used for transaction
-                  security.
-                </p>
-              </td>
-</tr>
-<tr>
-<td>
-                <p>
-                  <code class="varname">key_list</code>
-                </p>
-              </td>
-<td>
-                <p>
-                  A list of one or more
-                  <code class="varname">key_id</code>s,
-                  separated by semicolons and ending with a semicolon.
-                </p>
-              </td>
-</tr>
-<tr>
-<td>
-                <p>
-                  <code class="varname">number</code>
-                </p>
-              </td>
-<td>
-                <p>
-                  A non-negative 32-bit integer
-                  (i.e., a number between 0 and 4294967295, inclusive).
-                  Its acceptable value might further
-                  be limited by the context in which it is used.
-                </p>
-              </td>
-</tr>
-<tr>
-<td>
-                <p>
-                  <code class="varname">path_name</code>
-                </p>
-              </td>
-<td>
-                <p>
-                  A quoted string which will be used as
-                  a pathname, such as <code class="filename">zones/master/my.test.domain</code>.
-                </p>
-              </td>
-</tr>
-<tr>
-<td>
-                <p>
-                  <code class="varname">size_spec</code>
-                </p>
-              </td>
-<td>
-                <p>
-                  A number, the word <strong class="userinput"><code>unlimited</code></strong>,
-                  or the word <strong class="userinput"><code>default</code></strong>.
-                </p>
-                <p>
-                  An <code class="varname">unlimited</code> <code class="varname">size_spec</code> requests unlimited
-                  use, or the maximum available amount. A <code class="varname">default size_spec</code> uses
-                  the limit that was in force when the server was started.
-                </p>
-                <p>
-                  A <code class="varname">number</code> can optionally be
-                  followed by a scaling factor:
-                  <strong class="userinput"><code>K</code></strong> or <strong class="userinput"><code>k</code></strong>
-                  for kilobytes,
-                  <strong class="userinput"><code>M</code></strong> or <strong class="userinput"><code>m</code></strong>
-                  for megabytes, and
-                  <strong class="userinput"><code>G</code></strong> or <strong class="userinput"><code>g</code></strong> for gigabytes,
-                  which scale by 1024, 1024*1024, and 1024*1024*1024
-                  respectively.
-                </p>
-                <p>
-                  The value must be representable as a 64-bit unsigned integer
-                  (0 to 18446744073709551615, inclusive).
-                  Using <code class="varname">unlimited</code> is the best
-                  way
-                  to safely set a really large number.
-                </p>
-              </td>
-</tr>
-<tr>
-<td>
-                <p>
-                  <code class="varname">yes_or_no</code>
-                </p>
-              </td>
-<td>
-                <p>
-                  Either <strong class="userinput"><code>yes</code></strong> or <strong class="userinput"><code>no</code></strong>.
-                  The words <strong class="userinput"><code>true</code></strong> and <strong class="userinput"><code>false</code></strong> are
-                  also accepted, as are the numbers <strong class="userinput"><code>1</code></strong>
-                  and <strong class="userinput"><code>0</code></strong>.
-                </p>
-              </td>
-</tr>
-<tr>
-<td>
-                <p>
-                  <code class="varname">dialup_option</code>
-                </p>
-              </td>
-<td>
-                <p>
-                  One of <strong class="userinput"><code>yes</code></strong>,
-                  <strong class="userinput"><code>no</code></strong>, <strong class="userinput"><code>notify</code></strong>,
-                  <strong class="userinput"><code>notify-passive</code></strong>, <strong class="userinput"><code>refresh</code></strong> or
-                  <strong class="userinput"><code>passive</code></strong>.
-                  When used in a zone, <strong class="userinput"><code>notify-passive</code></strong>,
-                  <strong class="userinput"><code>refresh</code></strong>, and <strong class="userinput"><code>passive</code></strong>
-                  are restricted to slave and stub zones.
-                </p>
-              </td>
-</tr>
-</tbody>
-</table></div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="address_match_lists"></a>Address Match Lists</h3></div></div></div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2573277"></a>Syntax</h4></div></div></div>
-<pre class="programlisting"><code class="varname">address_match_list</code> = address_match_list_element ;
-  [<span class="optional"> address_match_list_element; ... </span>]
-<code class="varname">address_match_list_element</code> = [<span class="optional"> ! </span>] (ip_address [<span class="optional">/length</span>] |
-   key key_id | acl_name | { address_match_list } )
-</pre>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2573305"></a>Definition and Usage</h4></div></div></div>
-<p>
-            Address match lists are primarily used to determine access
-            control for various server operations. They are also used in
-            the <span><strong class="command">listen-on</strong></span> and <span><strong class="command">sortlist</strong></span>
-            statements. The elements
-            which constitute an address match list can be any of the
-            following:
-          </p>
-<div class="itemizedlist"><ul type="disc">
-<li>an IP address (IPv4 or IPv6)</li>
-<li>an IP prefix (in `/' notation)</li>
-<li>
-                a key ID, as defined by the <span><strong class="command">key</strong></span>
-                statement
-              </li>
-<li>the name of an address match list defined with
-                the <span><strong class="command">acl</strong></span> statement
-              </li>
-<li>a nested address match list enclosed in braces</li>
-</ul></div>
-<p>
-            Elements can be negated with a leading exclamation mark (`!'),
-            and the match list names "any", "none", "localhost", and
-            "localnets"
-            are predefined. More information on those names can be found in
-            the description of the acl statement.
-          </p>
-<p>
-            The addition of the key clause made the name of this syntactic
-            element something of a misnomer, since security keys can be used
-            to validate access without regard to a host or network address.
-            Nonetheless,
-            the term "address match list" is still used throughout the
-            documentation.
-          </p>
-<p>
-            When a given IP address or prefix is compared to an address
-            match list, the list is traversed in order until an element
-            matches.
-            The interpretation of a match depends on whether the list is being
-            used
-            for access control, defining listen-on ports, or in a sortlist,
-            and whether the element was negated.
-          </p>
-<p>
-            When used as an access control list, a non-negated match
-            allows access and a negated match denies access. If
-            there is no match, access is denied. The clauses
-            <span><strong class="command">allow-notify</strong></span>,
-            <span><strong class="command">allow-query</strong></span>,
-            <span><strong class="command">allow-query-cache</strong></span>,
-            <span><strong class="command">allow-transfer</strong></span>,
-            <span><strong class="command">allow-update</strong></span>,
-            <span><strong class="command">allow-update-forwarding</strong></span>, and
-            <span><strong class="command">blackhole</strong></span> all use address match
-            lists.  Similarly, the listen-on option will cause the
-            server to not accept queries on any of the machine's
-            addresses which do not match the list.
-          </p>
-<p>
-            Because of the first-match aspect of the algorithm, an element
-            that defines a subset of another element in the list should come
-            before the broader element, regardless of whether either is
-            negated. For
-            example, in
-            <span><strong class="command">1.2.3/24; ! 1.2.3.13;</strong></span> the 1.2.3.13
-            element is
-            completely useless because the algorithm will match any lookup for
-            1.2.3.13 to the 1.2.3/24 element.
-            Using <span><strong class="command">! 1.2.3.13; 1.2.3/24</strong></span> fixes
-            that problem by having 1.2.3.13 blocked by the negation but all
-            other 1.2.3.* hosts fall through.
-          </p>
-</div>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2573480"></a>Comment Syntax</h3></div></div></div>
-<p>
-          The <acronym class="acronym">BIND</acronym> 9 comment syntax allows for
-          comments to appear
-          anywhere that whitespace may appear in a <acronym class="acronym">BIND</acronym> configuration
-          file. To appeal to programmers of all kinds, they can be written
-          in the C, C++, or shell/perl style.
-        </p>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2573495"></a>Syntax</h4></div></div></div>
-<p>
-            </p>
-<pre class="programlisting">/* This is a <acronym class="acronym">BIND</acronym> comment as in C */</pre>
-<p>
-            </p>
-<pre class="programlisting">// This is a <acronym class="acronym">BIND</acronym> comment as in C++</pre>
-<p>
-            </p>
-<pre class="programlisting"># This is a <acronym class="acronym">BIND</acronym> comment as in common UNIX shells and perl</pre>
-<p>
-          </p>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2573525"></a>Definition and Usage</h4></div></div></div>
-<p>
-            Comments may appear anywhere that whitespace may appear in
-            a <acronym class="acronym">BIND</acronym> configuration file.
-          </p>
-<p>
-            C-style comments start with the two characters /* (slash,
-            star) and end with */ (star, slash). Because they are completely
-            delimited with these characters, they can be used to comment only
-            a portion of a line or to span multiple lines.
-          </p>
-<p>
-            C-style comments cannot be nested. For example, the following
-            is not valid because the entire comment ends with the first */:
-          </p>
-<p>
-
-</p>
-<pre class="programlisting">/* This is the start of a comment.
-   This is still part of the comment.
-/* This is an incorrect attempt at nesting a comment. */
-   This is no longer in any comment. */
-</pre>
-<p>
-
-          </p>
-<p>
-            C++-style comments start with the two characters // (slash,
-            slash) and continue to the end of the physical line. They cannot
-            be continued across multiple physical lines; to have one logical
-            comment span multiple lines, each line must use the // pair.
-          </p>
-<p>
-            For example:
-          </p>
-<p>
-
-</p>
-<pre class="programlisting">// This is the start of a comment.  The next line
-// is a new comment, even though it is logically
-// part of the previous comment.
-</pre>
-<p>
-
-          </p>
-<p>
-            Shell-style (or perl-style, if you prefer) comments start
-            with the character <code class="literal">#</code> (number sign)
-            and continue to the end of the
-            physical line, as in C++ comments.
-          </p>
-<p>
-            For example:
-          </p>
-<p>
-
-</p>
-<pre class="programlisting"># This is the start of a comment.  The next line
-# is a new comment, even though it is logically
-# part of the previous comment.
-</pre>
-<p>
-
-          </p>
-<div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Warning</h3>
-<p>
-              You cannot use the semicolon (`;') character
-              to start a comment such as you would in a zone file. The
-              semicolon indicates the end of a configuration
-              statement.
-            </p>
-</div>
-</div>
-</div>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="Configuration_File_Grammar"></a>Configuration File Grammar</h2></div></div></div>
-<p>
-        A <acronym class="acronym">BIND</acronym> 9 configuration consists of
-        statements and comments.
-        Statements end with a semicolon. Statements and comments are the
-        only elements that can appear without enclosing braces. Many
-        statements contain a block of sub-statements, which are also
-        terminated with a semicolon.
-      </p>
-<p>
-        The following statements are supported:
-      </p>
-<div class="informaltable"><table border="1">
-<colgroup>
-<col>
-<col>
-</colgroup>
-<tbody>
-<tr>
-<td>
-                <p><span><strong class="command">acl</strong></span></p>
-              </td>
-<td>
-                <p>
-                  defines a named IP address
-                  matching list, for access control and other uses.
-                </p>
-              </td>
-</tr>
-<tr>
-<td>
-                <p><span><strong class="command">controls</strong></span></p>
-              </td>
-<td>
-                <p>
-                  declares control channels to be used
-                  by the <span><strong class="command">rndc</strong></span> utility.
-                </p>
-              </td>
-</tr>
-<tr>
-<td>
-                <p><span><strong class="command">include</strong></span></p>
-              </td>
-<td>
-                <p>
-                  includes a file.
-                </p>
-              </td>
-</tr>
-<tr>
-<td>
-                <p><span><strong class="command">key</strong></span></p>
-              </td>
-<td>
-                <p>
-                  specifies key information for use in
-                  authentication and authorization using TSIG.
-                </p>
-              </td>
-</tr>
-<tr>
-<td>
-                <p><span><strong class="command">logging</strong></span></p>
-              </td>
-<td>
-                <p>
-                  specifies what the server logs, and where
-                  the log messages are sent.
-                </p>
-              </td>
-</tr>
-<tr>
-<td>
-                <p><span><strong class="command">lwres</strong></span></p>
-              </td>
-<td>
-                <p>
-                  configures <span><strong class="command">named</strong></span> to
-                  also act as a light-weight resolver daemon (<span><strong class="command">lwresd</strong></span>).
-                </p>
-              </td>
-</tr>
-<tr>
-<td>
-                <p><span><strong class="command">masters</strong></span></p>
-              </td>
-<td>
-                <p>
-                  defines a named masters list for
-                  inclusion in stub and slave zone masters clauses.
-                </p>
-              </td>
-</tr>
-<tr>
-<td>
-                <p><span><strong class="command">options</strong></span></p>
-              </td>
-<td>
-                <p>
-                  controls global server configuration
-                  options and sets defaults for other statements.
-                </p>
-              </td>
-</tr>
-<tr>
-<td>
-                <p><span><strong class="command">server</strong></span></p>
-              </td>
-<td>
-                <p>
-                  sets certain configuration options on
-                  a per-server basis.
-                </p>
-              </td>
-</tr>
-<tr>
-<td>
-                <p><span><strong class="command">trusted-keys</strong></span></p>
-              </td>
-<td>
-                <p>
-                  defines trusted DNSSEC keys.
-                </p>
-              </td>
-</tr>
-<tr>
-<td>
-                <p><span><strong class="command">view</strong></span></p>
-              </td>
-<td>
-                <p>
-                  defines a view.
-                </p>
-              </td>
-</tr>
-<tr>
-<td>
-                <p><span><strong class="command">zone</strong></span></p>
-              </td>
-<td>
-                <p>
-                  defines a zone.
-                </p>
-              </td>
-</tr>
-</tbody>
-</table></div>
-<p>
-        The <span><strong class="command">logging</strong></span> and
-        <span><strong class="command">options</strong></span> statements may only occur once
-        per
-        configuration.
-      </p>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2574092"></a><span><strong class="command">acl</strong></span> Statement Grammar</h3></div></div></div>
-<pre class="programlisting"><span><strong class="command">acl</strong></span> acl-name {
-    address_match_list
-};
-</pre>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="acl"></a><span><strong class="command">acl</strong></span> Statement Definition and
-          Usage</h3></div></div></div>
-<p>
-          The <span><strong class="command">acl</strong></span> statement assigns a symbolic
-          name to an address match list. It gets its name from a primary
-          use of address match lists: Access Control Lists (ACLs).
-        </p>
-<p>
-          Note that an address match list's name must be defined
-          with <span><strong class="command">acl</strong></span> before it can be used
-          elsewhere; no
-          forward references are allowed.
-        </p>
-<p>
-          The following ACLs are built-in:
-        </p>
-<div class="informaltable"><table border="1">
-<colgroup>
-<col>
-<col>
-</colgroup>
-<tbody>
-<tr>
-<td>
-                  <p><span><strong class="command">any</strong></span></p>
-                </td>
-<td>
-                  <p>
-                    Matches all hosts.
-                  </p>
-                </td>
-</tr>
-<tr>
-<td>
-                  <p><span><strong class="command">none</strong></span></p>
-                </td>
-<td>
-                  <p>
-                    Matches no hosts.
-                  </p>
-                </td>
-</tr>
-<tr>
-<td>
-                  <p><span><strong class="command">localhost</strong></span></p>
-                </td>
-<td>
-                  <p>
-                    Matches the IPv4 and IPv6 addresses of all network
-                    interfaces on the system.
-                  </p>
-                </td>
-</tr>
-<tr>
-<td>
-                  <p><span><strong class="command">localnets</strong></span></p>
-                </td>
-<td>
-                  <p>
-                    Matches any host on an IPv4 or IPv6 network
-                    for which the system has an interface.
-                    Some systems do not provide a way to determine the prefix
-                    lengths of
-                    local IPv6 addresses.
-                    In such a case, <span><strong class="command">localnets</strong></span>
-                    only matches the local
-                    IPv6 addresses, just like <span><strong class="command">localhost</strong></span>.
-                  </p>
-                </td>
-</tr>
-</tbody>
-</table></div>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2574282"></a><span><strong class="command">controls</strong></span> Statement Grammar</h3></div></div></div>
-<pre class="programlisting"><span><strong class="command">controls</strong></span> {
-   [ inet ( ip_addr | * ) [ port ip_port ] allow { <em class="replaceable"><code> address_match_list </code></em> }
-                keys { <em class="replaceable"><code>key_list</code></em> }; ]
-   [ inet ...; ]
-   [ unix <em class="replaceable"><code>path</code></em> perm <em class="replaceable"><code>number</code></em> owner <em class="replaceable"><code>number</code></em> group <em class="replaceable"><code>number</code></em> keys { <em class="replaceable"><code>key_list</code></em> }; ]
-   [ unix ...; ]
-};
-</pre>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="controls_statement_definition_and_usage"></a><span><strong class="command">controls</strong></span> Statement Definition and
-          Usage</h3></div></div></div>
-<p>
-          The <span><strong class="command">controls</strong></span> statement declares control
-          channels to be used by system administrators to control the
-          operation of the name server. These control channels are
-          used by the <span><strong class="command">rndc</strong></span> utility to send
-          commands to and retrieve non-DNS results from a name server.
-        </p>
-<p>
-          An <span><strong class="command">inet</strong></span> control channel is a TCP socket
-          listening at the specified <span><strong class="command">ip_port</strong></span> on the
-          specified <span><strong class="command">ip_addr</strong></span>, which can be an IPv4 or IPv6
-          address.  An <span><strong class="command">ip_addr</strong></span> of <code class="literal">*</code> (asterisk) is
-          interpreted as the IPv4 wildcard address; connections will be
-          accepted on any of the system's IPv4 addresses.
-          To listen on the IPv6 wildcard address,
-          use an <span><strong class="command">ip_addr</strong></span> of <code class="literal">::</code>.
-          If you will only use <span><strong class="command">rndc</strong></span> on the local host,
-          using the loopback address (<code class="literal">127.0.0.1</code>
-          or <code class="literal">::1</code>) is recommended for maximum security.
-        </p>
-<p>
-          If no port is specified, port 953 is used. The asterisk
-          "<code class="literal">*</code>" cannot be used for <span><strong class="command">ip_port</strong></span>.
-        </p>
-<p>
-          The ability to issue commands over the control channel is
-          restricted by the <span><strong class="command">allow</strong></span> and
-          <span><strong class="command">keys</strong></span> clauses.
-          Connections to the control channel are permitted based on the
-          <span><strong class="command">address_match_list</strong></span>.  This is for simple
-          IP address based filtering only; any <span><strong class="command">key_id</strong></span>
-          elements of the <span><strong class="command">address_match_list</strong></span>
-          are ignored.
-        </p>
-<p>
-          A <span><strong class="command">unix</strong></span> control channel is a UNIX domain
-          socket listening at the specified path in the file system.
-          Access to the socket is specified by the <span><strong class="command">perm</strong></span>,
-          <span><strong class="command">owner</strong></span> and <span><strong class="command">group</strong></span> clauses.
-          Note on some platforms (SunOS and Solaris) the permissions
-          (<span><strong class="command">perm</strong></span>) are applied to the parent directory
-          as the permissions on the socket itself are ignored.
-        </p>
-<p>
-          The primary authorization mechanism of the command
-          channel is the <span><strong class="command">key_list</strong></span>, which
-          contains a list of <span><strong class="command">key_id</strong></span>s.
-          Each <span><strong class="command">key_id</strong></span> in the <span><strong class="command">key_list</strong></span>
-          is authorized to execute commands over the control channel.
-          See <a href="Bv9ARM.ch03.html#rndc">Remote Name Daemon Control application</a> in <a href="Bv9ARM.ch03.html#admin_tools" title="Administrative Tools">the section called &#8220;Administrative Tools&#8221;</a>)
-          for information about configuring keys in <span><strong class="command">rndc</strong></span>.
-        </p>
-<p>
-          If no <span><strong class="command">controls</strong></span> statement is present,
-          <span><strong class="command">named</strong></span> will set up a default
-          control channel listening on the loopback address 127.0.0.1
-          and its IPv6 counterpart ::1.
-          In this case, and also when the <span><strong class="command">controls</strong></span> statement
-          is present but does not have a <span><strong class="command">keys</strong></span> clause,
-          <span><strong class="command">named</strong></span> will attempt to load the command channel key
-          from the file <code class="filename">rndc.key</code> in
-          <code class="filename">/etc</code> (or whatever <code class="varname">sysconfdir</code>
-          was specified as when <acronym class="acronym">BIND</acronym> was built).
-          To create a <code class="filename">rndc.key</code> file, run
-          <strong class="userinput"><code>rndc-confgen -a</code></strong>.
-        </p>
-<p>
-          The <code class="filename">rndc.key</code> feature was created to
-          ease the transition of systems from <acronym class="acronym">BIND</acronym> 8,
-          which did not have digital signatures on its command channel
-          messages and thus did not have a <span><strong class="command">keys</strong></span> clause.
-
-          It makes it possible to use an existing <acronym class="acronym">BIND</acronym> 8
-          configuration file in <acronym class="acronym">BIND</acronym> 9 unchanged,
-          and still have <span><strong class="command">rndc</strong></span> work the same way
-          <span><strong class="command">ndc</strong></span> worked in BIND 8, simply by executing the
-          command <strong class="userinput"><code>rndc-confgen -a</code></strong> after BIND 9 is
-          installed.
-        </p>
-<p>
-          Since the <code class="filename">rndc.key</code> feature
-          is only intended to allow the backward-compatible usage of
-          <acronym class="acronym">BIND</acronym> 8 configuration files, this
-          feature does not
-          have a high degree of configurability.  You cannot easily change
-          the key name or the size of the secret, so you should make a
-          <code class="filename">rndc.conf</code> with your own key if you
-          wish to change
-          those things.  The <code class="filename">rndc.key</code> file
-          also has its
-          permissions set such that only the owner of the file (the user that
-          <span><strong class="command">named</strong></span> is running as) can access it.
-          If you
-          desire greater flexibility in allowing other users to access
-          <span><strong class="command">rndc</strong></span> commands, then you need to create
-          a
-          <code class="filename">rndc.conf</code> file and make it group
-          readable by a group
-          that contains the users who should have access.
-        </p>
-<p>
-          To disable the command channel, use an empty
-          <span><strong class="command">controls</strong></span> statement:
-          <span><strong class="command">controls { };</strong></span>.
-        </p>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2574711"></a><span><strong class="command">include</strong></span> Statement Grammar</h3></div></div></div>
-<pre class="programlisting">include <em class="replaceable"><code>filename</code></em>;</pre>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2574726"></a><span><strong class="command">include</strong></span> Statement Definition and
-          Usage</h3></div></div></div>
-<p>
-          The <span><strong class="command">include</strong></span> statement inserts the
-          specified file at the point where the <span><strong class="command">include</strong></span>
-          statement is encountered. The <span><strong class="command">include</strong></span>
-                statement facilitates the administration of configuration
-          files
-          by permitting the reading or writing of some things but not
-          others. For example, the statement could include private keys
-          that are readable only by the name server.
-        </p>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2574749"></a><span><strong class="command">key</strong></span> Statement Grammar</h3></div></div></div>
-<pre class="programlisting">key <em class="replaceable"><code>key_id</code></em> {
-    algorithm <em class="replaceable"><code>string</code></em>;
-    secret <em class="replaceable"><code>string</code></em>;
-};
-</pre>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2574771"></a><span><strong class="command">key</strong></span> Statement Definition and Usage</h3></div></div></div>
-<p>
-          The <span><strong class="command">key</strong></span> statement defines a shared
-          secret key for use with TSIG (see <a href="Bv9ARM.ch04.html#tsig" title="TSIG">the section called &#8220;TSIG&#8221;</a>)
-          or the command channel
-          (see <a href="Bv9ARM.ch06.html#controls_statement_definition_and_usage" title="controls Statement Definition and
-          Usage">the section called &#8220;<span><strong class="command">controls</strong></span> Statement Definition and
-          Usage&#8221;</a>).
-        </p>
-<p>
-          The <span><strong class="command">key</strong></span> statement can occur at the
-          top level
-          of the configuration file or inside a <span><strong class="command">view</strong></span>
-          statement.  Keys defined in top-level <span><strong class="command">key</strong></span>
-          statements can be used in all views.  Keys intended for use in
-          a <span><strong class="command">controls</strong></span> statement
-          (see <a href="Bv9ARM.ch06.html#controls_statement_definition_and_usage" title="controls Statement Definition and
-          Usage">the section called &#8220;<span><strong class="command">controls</strong></span> Statement Definition and
-          Usage&#8221;</a>)
-          must be defined at the top level.
-        </p>
-<p>
-          The <em class="replaceable"><code>key_id</code></em>, also known as the
-          key name, is a domain name uniquely identifying the key. It can
-          be used in a <span><strong class="command">server</strong></span>
-          statement to cause requests sent to that
-          server to be signed with this key, or in address match lists to
-          verify that incoming requests have been signed with a key
-          matching this name, algorithm, and secret.
-        </p>
-<p>
-          The <em class="replaceable"><code>algorithm_id</code></em> is a string
-          that specifies a security/authentication algorithm.  Named
-          supports <code class="literal">hmac-md5</code>,
-          <code class="literal">hmac-sha1</code>, <code class="literal">hmac-sha224</code>,
-          <code class="literal">hmac-sha256</code>, <code class="literal">hmac-sha384</code>
-          and <code class="literal">hmac-sha512</code> TSIG authentication.
-          Truncated hashes are supported by appending the minimum
-          number of required bits preceded by a dash, e.g.
-          <code class="literal">hmac-sha1-80</code>.  The
-          <em class="replaceable"><code>secret_string</code></em> is the secret
-          to be used by the algorithm, and is treated as a base-64
-          encoded string.
-        </p>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2574930"></a><span><strong class="command">logging</strong></span> Statement Grammar</h3></div></div></div>
-<pre class="programlisting"><span><strong class="command">logging</strong></span> {
-   [ <span><strong class="command">channel</strong></span> <em class="replaceable"><code>channel_name</code></em> {
-     ( <span><strong class="command">file</strong></span> <em class="replaceable"><code>path name</code></em>
-         [ <span><strong class="command">versions</strong></span> ( <em class="replaceable"><code>number</code></em> | <span><strong class="command">unlimited</strong></span> ) ]
-         [ <span><strong class="command">size</strong></span> <em class="replaceable"><code>size spec</code></em> ]
-       | <span><strong class="command">syslog</strong></span> <em class="replaceable"><code>syslog_facility</code></em>
-       | <span><strong class="command">stderr</strong></span>
-       | <span><strong class="command">null</strong></span> );
-     [ <span><strong class="command">severity</strong></span> (<code class="option">critical</code> | <code class="option">error</code> | <code class="option">warning</code> | <code class="option">notice</code> |
-                 <code class="option">info</code> | <code class="option">debug</code> [ <em class="replaceable"><code>level</code></em> ] | <code class="option">dynamic</code> ); ]
-     [ <span><strong class="command">print-category</strong></span> <code class="option">yes</code> or <code class="option">no</code>; ]
-     [ <span><strong class="command">print-severity</strong></span> <code class="option">yes</code> or <code class="option">no</code>; ]
-     [ <span><strong class="command">print-time</strong></span> <code class="option">yes</code> or <code class="option">no</code>; ]
-   }; ]
-   [ <span><strong class="command">category</strong></span> <em class="replaceable"><code>category_name</code></em> {
-     <em class="replaceable"><code>channel_name</code></em> ; [ <em class="replaceable"><code>channel_name</code></em> ; ... ]
-   }; ]
-   ...
-};
-</pre>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2575056"></a><span><strong class="command">logging</strong></span> Statement Definition and
-          Usage</h3></div></div></div>
-<p>
-          The <span><strong class="command">logging</strong></span> statement configures a
-          wide
-          variety of logging options for the name server. Its <span><strong class="command">channel</strong></span> phrase
-          associates output methods, format options and severity levels with
-          a name that can then be used with the <span><strong class="command">category</strong></span> phrase
-          to select how various classes of messages are logged.
-        </p>
-<p>
-          Only one <span><strong class="command">logging</strong></span> statement is used to
-          define
-          as many channels and categories as are wanted. If there is no <span><strong class="command">logging</strong></span> statement,
-          the logging configuration will be:
-        </p>
-<pre class="programlisting">logging {
-     category default { default_syslog; default_debug; };
-     category unmatched { null; };
-};
-</pre>
-<p>
-          In <acronym class="acronym">BIND</acronym> 9, the logging configuration
-          is only established when
-          the entire configuration file has been parsed.  In <acronym class="acronym">BIND</acronym> 8, it was
-          established as soon as the <span><strong class="command">logging</strong></span>
-          statement
-          was parsed. When the server is starting up, all logging messages
-          regarding syntax errors in the configuration file go to the default
-          channels, or to standard error if the "<code class="option">-g</code>" option
-          was specified.
-        </p>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2575108"></a>The <span><strong class="command">channel</strong></span> Phrase</h4></div></div></div>
-<p>
-            All log output goes to one or more <span class="emphasis"><em>channels</em></span>;
-            you can make as many of them as you want.
-          </p>
-<p>
-            Every channel definition must include a destination clause that
-            says whether messages selected for the channel go to a file, to a
-            particular syslog facility, to the standard error stream, or are
-            discarded. It can optionally also limit the message severity level
-            that will be accepted by the channel (the default is
-            <span><strong class="command">info</strong></span>), and whether to include a
-            <span><strong class="command">named</strong></span>-generated time stamp, the
-            category name
-            and/or severity level (the default is not to include any).
-          </p>
-<p>
-            The <span><strong class="command">null</strong></span> destination clause
-            causes all messages sent to the channel to be discarded;
-            in that case, other options for the channel are meaningless.
-          </p>
-<p>
-            The <span><strong class="command">file</strong></span> destination clause directs
-            the channel
-            to a disk file.  It can include limitations
-            both on how large the file is allowed to become, and how many
-            versions
-            of the file will be saved each time the file is opened.
-          </p>
-<p>
-            If you use the <span><strong class="command">versions</strong></span> log file
-            option, then
-            <span><strong class="command">named</strong></span> will retain that many backup
-            versions of the file by
-            renaming them when opening.  For example, if you choose to keep
-            three old versions
-            of the file <code class="filename">lamers.log</code>, then just
-            before it is opened
-            <code class="filename">lamers.log.1</code> is renamed to
-            <code class="filename">lamers.log.2</code>, <code class="filename">lamers.log.0</code> is renamed
-            to <code class="filename">lamers.log.1</code>, and <code class="filename">lamers.log</code> is
-            renamed to <code class="filename">lamers.log.0</code>.
-            You can say <span><strong class="command">versions unlimited</strong></span> to
-            not limit
-            the number of versions.
-            If a <span><strong class="command">size</strong></span> option is associated with
-            the log file,
-            then renaming is only done when the file being opened exceeds the
-            indicated size.  No backup versions are kept by default; any
-            existing
-            log file is simply appended.
-          </p>
-<p>
-            The <span><strong class="command">size</strong></span> option for files is used
-            to limit log
-            growth. If the file ever exceeds the size, then <span><strong class="command">named</strong></span> will
-            stop writing to the file unless it has a <span><strong class="command">versions</strong></span> option
-            associated with it.  If backup versions are kept, the files are
-            rolled as
-            described above and a new one begun.  If there is no
-            <span><strong class="command">versions</strong></span> option, no more data will
-            be written to the log
-            until some out-of-band mechanism removes or truncates the log to
-            less than the
-            maximum size.  The default behavior is not to limit the size of
-            the
-            file.
-          </p>
-<p>
-            Example usage of the <span><strong class="command">size</strong></span> and
-            <span><strong class="command">versions</strong></span> options:
-          </p>
-<pre class="programlisting">channel an_example_channel {
-    file "example.log" versions 3 size 20m;
-    print-time yes;
-    print-category yes;
-};
-</pre>
-<p>
-            The <span><strong class="command">syslog</strong></span> destination clause
-            directs the
-            channel to the system log.  Its argument is a
-            syslog facility as described in the <span><strong class="command">syslog</strong></span> man
-            page. Known facilities are <span><strong class="command">kern</strong></span>, <span><strong class="command">user</strong></span>,
-            <span><strong class="command">mail</strong></span>, <span><strong class="command">daemon</strong></span>, <span><strong class="command">auth</strong></span>,
-            <span><strong class="command">syslog</strong></span>, <span><strong class="command">lpr</strong></span>, <span><strong class="command">news</strong></span>,
-            <span><strong class="command">uucp</strong></span>, <span><strong class="command">cron</strong></span>, <span><strong class="command">authpriv</strong></span>,
-            <span><strong class="command">ftp</strong></span>, <span><strong class="command">local0</strong></span>, <span><strong class="command">local1</strong></span>,
-            <span><strong class="command">local2</strong></span>, <span><strong class="command">local3</strong></span>, <span><strong class="command">local4</strong></span>,
-            <span><strong class="command">local5</strong></span>, <span><strong class="command">local6</strong></span> and
-            <span><strong class="command">local7</strong></span>, however not all facilities
-            are supported on
-            all operating systems.
-            How <span><strong class="command">syslog</strong></span> will handle messages
-            sent to
-            this facility is described in the <span><strong class="command">syslog.conf</strong></span> man
-            page. If you have a system which uses a very old version of <span><strong class="command">syslog</strong></span> that
-            only uses two arguments to the <span><strong class="command">openlog()</strong></span> function,
-            then this clause is silently ignored.
-          </p>
-<p>
-            The <span><strong class="command">severity</strong></span> clause works like <span><strong class="command">syslog</strong></span>'s
-            "priorities", except that they can also be used if you are writing
-            straight to a file rather than using <span><strong class="command">syslog</strong></span>.
-            Messages which are not at least of the severity level given will
-            not be selected for the channel; messages of higher severity
-            levels
-            will be accepted.
-          </p>
-<p>
-            If you are using <span><strong class="command">syslog</strong></span>, then the <span><strong class="command">syslog.conf</strong></span> priorities
-            will also determine what eventually passes through. For example,
-            defining a channel facility and severity as <span><strong class="command">daemon</strong></span> and <span><strong class="command">debug</strong></span> but
-            only logging <span><strong class="command">daemon.warning</strong></span> via <span><strong class="command">syslog.conf</strong></span> will
-            cause messages of severity <span><strong class="command">info</strong></span> and
-            <span><strong class="command">notice</strong></span> to
-            be dropped. If the situation were reversed, with <span><strong class="command">named</strong></span> writing
-            messages of only <span><strong class="command">warning</strong></span> or higher,
-            then <span><strong class="command">syslogd</strong></span> would
-            print all messages it received from the channel.
-          </p>
-<p>
-            The <span><strong class="command">stderr</strong></span> destination clause
-            directs the
-            channel to the server's standard error stream.  This is intended
-            for
-            use when the server is running as a foreground process, for
-            example
-            when debugging a configuration.
-          </p>
-<p>
-            The server can supply extensive debugging information when
-            it is in debugging mode. If the server's global debug level is
-            greater
-            than zero, then debugging mode will be active. The global debug
-            level is set either by starting the <span><strong class="command">named</strong></span> server
-            with the <code class="option">-d</code> flag followed by a positive integer,
-            or by running <span><strong class="command">rndc trace</strong></span>.
-            The global debug level
-            can be set to zero, and debugging mode turned off, by running <span><strong class="command">rndc
-notrace</strong></span>. All debugging messages in the server have a debug
-            level, and higher debug levels give more detailed output. Channels
-            that specify a specific debug severity, for example:
-          </p>
-<pre class="programlisting">channel specific_debug_level {
-    file "foo";
-    severity debug 3;
-};
-</pre>
-<p>
-            will get debugging output of level 3 or less any time the
-            server is in debugging mode, regardless of the global debugging
-            level. Channels with <span><strong class="command">dynamic</strong></span>
-            severity use the
-            server's global debug level to determine what messages to print.
-          </p>
-<p>
-            If <span><strong class="command">print-time</strong></span> has been turned on,
-            then
-            the date and time will be logged. <span><strong class="command">print-time</strong></span> may
-            be specified for a <span><strong class="command">syslog</strong></span> channel,
-            but is usually
-            pointless since <span><strong class="command">syslog</strong></span> also prints
-            the date and
-            time. If <span><strong class="command">print-category</strong></span> is
-            requested, then the
-            category of the message will be logged as well. Finally, if <span><strong class="command">print-severity</strong></span> is
-            on, then the severity level of the message will be logged. The <span><strong class="command">print-</strong></span> options may
-            be used in any combination, and will always be printed in the
-            following
-            order: time, category, severity. Here is an example where all
-            three <span><strong class="command">print-</strong></span> options
-            are on:
-          </p>
-<p>
-            <code class="computeroutput">28-Feb-2000 15:05:32.863 general: notice: running</code>
-          </p>
-<p>
-            There are four predefined channels that are used for
-            <span><strong class="command">named</strong></span>'s default logging as follows.
-            How they are
-            used is described in <a href="Bv9ARM.ch06.html#the_category_phrase" title="The category Phrase">the section called &#8220;The <span><strong class="command">category</strong></span> Phrase&#8221;</a>.
-          </p>
-<pre class="programlisting">channel default_syslog {
-    syslog daemon;                      // send to syslog's daemon
-                                        // facility
-    severity info;                      // only send priority info
-                                        // and higher
-};
-
-channel default_debug {
-    file "named.run";                   // write to named.run in
-                                        // the working directory
-                                        // Note: stderr is used instead
-                                        // of "named.run"
-                                        // if the server is started
-                                        // with the '-f' option.
-    severity dynamic;                   // log at the server's
-                                        // current debug level
-};
-
-channel default_stderr {
-    stderr;                             // writes to stderr
-    severity info;                      // only send priority info
-                                        // and higher
-};
-
-channel null {
-   null;                                // toss anything sent to
-                                        // this channel
-};
-</pre>
-<p>
-            The <span><strong class="command">default_debug</strong></span> channel has the
-            special
-            property that it only produces output when the server's debug
-            level is
-            nonzero.  It normally writes to a file called <code class="filename">named.run</code>
-            in the server's working directory.
-          </p>
-<p>
-            For security reasons, when the "<code class="option">-u</code>"
-            command line option is used, the <code class="filename">named.run</code> file
-            is created only after <span><strong class="command">named</strong></span> has
-            changed to the
-            new UID, and any debug output generated while <span><strong class="command">named</strong></span> is
-            starting up and still running as root is discarded.  If you need
-            to capture this output, you must run the server with the "<code class="option">-g</code>"
-            option and redirect standard error to a file.
-          </p>
-<p>
-            Once a channel is defined, it cannot be redefined. Thus you
-            cannot alter the built-in channels directly, but you can modify
-            the default logging by pointing categories at channels you have
-            defined.
-          </p>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="the_category_phrase"></a>The <span><strong class="command">category</strong></span> Phrase</h4></div></div></div>
-<p>
-            There are many categories, so you can send the logs you want
-            to see wherever you want, without seeing logs you don't want. If
-            you don't specify a list of channels for a category, then log
-            messages
-            in that category will be sent to the <span><strong class="command">default</strong></span> category
-            instead. If you don't specify a default category, the following
-            "default default" is used:
-          </p>
-<pre class="programlisting">category default { default_syslog; default_debug; };
-</pre>
-<p>
-            As an example, let's say you want to log security events to
-            a file, but you also want keep the default logging behavior. You'd
-            specify the following:
-          </p>
-<pre class="programlisting">channel my_security_channel {
-    file "my_security_file";
-    severity info;
-};
-category security {
-    my_security_channel;
-    default_syslog;
-    default_debug;
-};</pre>
-<p>
-            To discard all messages in a category, specify the <span><strong class="command">null</strong></span> channel:
-          </p>
-<pre class="programlisting">category xfer-out { null; };
-category notify { null; };
-</pre>
-<p>
-            Following are the available categories and brief descriptions
-            of the types of log information they contain. More
-            categories may be added in future <acronym class="acronym">BIND</acronym> releases.
-          </p>
-<div class="informaltable"><table border="1">
-<colgroup>
-<col>
-<col>
-</colgroup>
-<tbody>
-<tr>
-<td>
-                    <p><span><strong class="command">default</strong></span></p>
-                  </td>
-<td>
-                    <p>
-                      The default category defines the logging
-                      options for those categories where no specific
-                      configuration has been
-                      defined.
-                    </p>
-                  </td>
-</tr>
-<tr>
-<td>
-                    <p><span><strong class="command">general</strong></span></p>
-                  </td>
-<td>
-                    <p>
-                      The catch-all. Many things still aren't
-                      classified into categories, and they all end up here.
-                    </p>
-                  </td>
-</tr>
-<tr>
-<td>
-                    <p><span><strong class="command">database</strong></span></p>
-                  </td>
-<td>
-                    <p>
-                      Messages relating to the databases used
-                      internally by the name server to store zone and cache
-                      data.
-                    </p>
-                  </td>
-</tr>
-<tr>
-<td>
-                    <p><span><strong class="command">security</strong></span></p>
-                  </td>
-<td>
-                    <p>
-                      Approval and denial of requests.
-                    </p>
-                  </td>
-</tr>
-<tr>
-<td>
-                    <p><span><strong class="command">config</strong></span></p>
-                  </td>
-<td>
-                    <p>
-                      Configuration file parsing and processing.
-                    </p>
-                  </td>
-</tr>
-<tr>
-<td>
-                    <p><span><strong class="command">resolver</strong></span></p>
-                  </td>
-<td>
-                    <p>
-                      DNS resolution, such as the recursive
-                      lookups performed on behalf of clients by a caching name
-                      server.
-                    </p>
-                  </td>
-</tr>
-<tr>
-<td>
-                    <p><span><strong class="command">xfer-in</strong></span></p>
-                  </td>
-<td>
-                    <p>
-                      Zone transfers the server is receiving.
-                    </p>
-                  </td>
-</tr>
-<tr>
-<td>
-                    <p><span><strong class="command">xfer-out</strong></span></p>
-                  </td>
-<td>
-                    <p>
-                      Zone transfers the server is sending.
-                    </p>
-                  </td>
-</tr>
-<tr>
-<td>
-                    <p><span><strong class="command">notify</strong></span></p>
-                  </td>
-<td>
-                    <p>
-                      The NOTIFY protocol.
-                    </p>
-                  </td>
-</tr>
-<tr>
-<td>
-                    <p><span><strong class="command">client</strong></span></p>
-                  </td>
-<td>
-                    <p>
-                      Processing of client requests.
-                    </p>
-                  </td>
-</tr>
-<tr>
-<td>
-                    <p><span><strong class="command">unmatched</strong></span></p>
-                  </td>
-<td>
-                    <p>
-                      Messages that named was unable to determine the
-                      class of or for which there was no matching <span><strong class="command">view</strong></span>.
-                      A one line summary is also logged to the <span><strong class="command">client</strong></span> category.
-                      This category is best sent to a file or stderr, by
-                      default it is sent to
-                      the <span><strong class="command">null</strong></span> channel.
-                    </p>
-                  </td>
-</tr>
-<tr>
-<td>
-                    <p><span><strong class="command">network</strong></span></p>
-                  </td>
-<td>
-                    <p>
-                      Network operations.
-                    </p>
-                  </td>
-</tr>
-<tr>
-<td>
-                    <p><span><strong class="command">update</strong></span></p>
-                  </td>
-<td>
-                    <p>
-                      Dynamic updates.
-                    </p>
-                  </td>
-</tr>
-<tr>
-<td>
-                    <p><span><strong class="command">update-security</strong></span></p>
-                  </td>
-<td>
-                    <p>
-                      Approval and denial of update requests.
-                    </p>
-                  </td>
-</tr>
-<tr>
-<td>
-                    <p><span><strong class="command">queries</strong></span></p>
-                  </td>
-<td>
-                    <p>
-                      Specify where queries should be logged to.
-                    </p>
-                    <p>
-                      At startup, specifying the category <span><strong class="command">queries</strong></span> will also
-                      enable query logging unless <span><strong class="command">querylog</strong></span> option has been
-                      specified.
-                    </p>
-                    <p>
-                      The query log entry reports the client's IP address and
-                      port number, and the
-                      query name, class and type.  It also reports whether the
-                      Recursion Desired
-                      flag was set (+ if set, - if not set), EDNS was in use
-                      (E) or if the
-                      query was signed (S).
-                    </p>
-                    <p>
-                      <code class="computeroutput">client 127.0.0.1#62536: query: www.example.com IN AAAA +SE</code>
-                    </p>
-                    <p>
-                      <code class="computeroutput">client ::1#62537: query: www.example.net IN AAAA -SE</code>
-                    </p>
-                  </td>
-</tr>
-<tr>
-<td>
-                    <p><span><strong class="command">dispatch</strong></span></p>
-                  </td>
-<td>
-                    <p>
-                      Dispatching of incoming packets to the
-                      server modules where they are to be processed.
-                    </p>
-                  </td>
-</tr>
-<tr>
-<td>
-                    <p><span><strong class="command">dnssec</strong></span></p>
-                  </td>
-<td>
-                    <p>
-                      DNSSEC and TSIG protocol processing.
-                    </p>
-                  </td>
-</tr>
-<tr>
-<td>
-                    <p><span><strong class="command">lame-servers</strong></span></p>
-                  </td>
-<td>
-                    <p>
-                      Lame servers.  These are misconfigurations
-                      in remote servers, discovered by BIND 9 when trying to
-                      query
-                      those servers during resolution.
-                    </p>
-                  </td>
-</tr>
-<tr>
-<td>
-                    <p><span><strong class="command">delegation-only</strong></span></p>
-                  </td>
-<td>
-                    <p>
-                      Delegation only.  Logs queries that have have
-                      been forced to NXDOMAIN as the result of a
-                      delegation-only zone or
-                      a <span><strong class="command">delegation-only</strong></span> in a
-                      hint or stub zone declaration.
-                    </p>
-                  </td>
-</tr>
-</tbody>
-</table></div>
-</div>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2576406"></a><span><strong class="command">lwres</strong></span> Statement Grammar</h3></div></div></div>
-<p>
-           This is the grammar of the <span><strong class="command">lwres</strong></span>
-          statement in the <code class="filename">named.conf</code> file:
-        </p>
-<pre class="programlisting"><span><strong class="command">lwres</strong></span> {
-    [<span class="optional"> listen-on { <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; [<span class="optional"> <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; ... </span>] }; </span>]
-    [<span class="optional"> view <em class="replaceable"><code>view_name</code></em>; </span>]
-    [<span class="optional"> search { <em class="replaceable"><code>domain_name</code></em> ; [<span class="optional"> <em class="replaceable"><code>domain_name</code></em> ; ... </span>] }; </span>]
-    [<span class="optional"> ndots <em class="replaceable"><code>number</code></em>; </span>]
-};
-</pre>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2576480"></a><span><strong class="command">lwres</strong></span> Statement Definition and Usage</h3></div></div></div>
-<p>
-          The <span><strong class="command">lwres</strong></span> statement configures the
-          name
-          server to also act as a lightweight resolver server. (See
-          <a href="Bv9ARM.ch05.html#lwresd" title="Running a Resolver Daemon">the section called &#8220;Running a Resolver Daemon&#8221;</a>.)  There may be multiple
-          <span><strong class="command">lwres</strong></span> statements configuring
-          lightweight resolver servers with different properties.
-        </p>
-<p>
-          The <span><strong class="command">listen-on</strong></span> statement specifies a
-          list of
-          addresses (and ports) that this instance of a lightweight resolver
-          daemon
-          should accept requests on.  If no port is specified, port 921 is
-          used.
-          If this statement is omitted, requests will be accepted on
-          127.0.0.1,
-          port 921.
-        </p>
-<p>
-          The <span><strong class="command">view</strong></span> statement binds this
-          instance of a
-          lightweight resolver daemon to a view in the DNS namespace, so that
-          the
-          response will be constructed in the same manner as a normal DNS
-          query
-          matching this view.  If this statement is omitted, the default view
-          is
-          used, and if there is no default view, an error is triggered.
-        </p>
-<p>
-          The <span><strong class="command">search</strong></span> statement is equivalent to
-          the
-          <span><strong class="command">search</strong></span> statement in
-          <code class="filename">/etc/resolv.conf</code>.  It provides a
-          list of domains
-          which are appended to relative names in queries.
-        </p>
-<p>
-          The <span><strong class="command">ndots</strong></span> statement is equivalent to
-          the
-          <span><strong class="command">ndots</strong></span> statement in
-          <code class="filename">/etc/resolv.conf</code>.  It indicates the
-          minimum
-          number of dots in a relative domain name that should result in an
-          exact match lookup before search path elements are appended.
-        </p>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2576544"></a><span><strong class="command">masters</strong></span> Statement Grammar</h3></div></div></div>
-<pre class="programlisting">
-<span><strong class="command">masters</strong></span> <em class="replaceable"><code>name</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] { ( <em class="replaceable"><code>masters_list</code></em> | <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] [<span class="optional">key <em class="replaceable"><code>key</code></em></span>] ) ; [<span class="optional">...</span>] };
-</pre>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2576587"></a><span><strong class="command">masters</strong></span> Statement Definition and
-          Usage</h3></div></div></div>
-<p><span><strong class="command">masters</strong></span>
-          lists allow for a common set of masters to be easily used by
-          multiple stub and slave zones.
-        </p>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2576602"></a><span><strong class="command">options</strong></span> Statement Grammar</h3></div></div></div>
-<p>
-          This is the grammar of the <span><strong class="command">options</strong></span>
-          statement in the <code class="filename">named.conf</code> file:
-        </p>
-<pre class="programlisting">options {
-    [<span class="optional"> version <em class="replaceable"><code>version_string</code></em>; </span>]
-    [<span class="optional"> hostname <em class="replaceable"><code>hostname_string</code></em>; </span>]
-    [<span class="optional"> server-id <em class="replaceable"><code>server_id_string</code></em>; </span>]
-    [<span class="optional"> directory <em class="replaceable"><code>path_name</code></em>; </span>]
-    [<span class="optional"> key-directory <em class="replaceable"><code>path_name</code></em>; </span>]
-    [<span class="optional"> named-xfer <em class="replaceable"><code>path_name</code></em>; </span>]
-    [<span class="optional"> tkey-domain <em class="replaceable"><code>domainname</code></em>; </span>]
-    [<span class="optional"> tkey-dhkey <em class="replaceable"><code>key_name</code></em> <em class="replaceable"><code>key_tag</code></em>; </span>]
-    [<span class="optional"> cache-file <em class="replaceable"><code>path_name</code></em>; </span>]
-    [<span class="optional"> dump-file <em class="replaceable"><code>path_name</code></em>; </span>]
-    [<span class="optional"> memstatistics-file <em class="replaceable"><code>path_name</code></em>; </span>]
-    [<span class="optional"> pid-file <em class="replaceable"><code>path_name</code></em>; </span>]
-    [<span class="optional"> recursing-file <em class="replaceable"><code>path_name</code></em>; </span>]
-    [<span class="optional"> statistics-file <em class="replaceable"><code>path_name</code></em>; </span>]
-    [<span class="optional"> zone-statistics <em class="replaceable"><code>yes_or_no</code></em>; </span>]
-    [<span class="optional"> auth-nxdomain <em class="replaceable"><code>yes_or_no</code></em>; </span>]
-    [<span class="optional"> deallocate-on-exit <em class="replaceable"><code>yes_or_no</code></em>; </span>]
-    [<span class="optional"> dialup <em class="replaceable"><code>dialup_option</code></em>; </span>]
-    [<span class="optional"> fake-iquery <em class="replaceable"><code>yes_or_no</code></em>; </span>]
-    [<span class="optional"> fetch-glue <em class="replaceable"><code>yes_or_no</code></em>; </span>]
-    [<span class="optional"> flush-zones-on-shutdown <em class="replaceable"><code>yes_or_no</code></em>; </span>]
-    [<span class="optional"> has-old-clients <em class="replaceable"><code>yes_or_no</code></em>; </span>]
-    [<span class="optional"> host-statistics <em class="replaceable"><code>yes_or_no</code></em>; </span>]
-    [<span class="optional"> host-statistics-max <em class="replaceable"><code>number</code></em>; </span>]
-    [<span class="optional"> minimal-responses <em class="replaceable"><code>yes_or_no</code></em>; </span>]
-    [<span class="optional"> multiple-cnames <em class="replaceable"><code>yes_or_no</code></em>; </span>]
-    [<span class="optional"> notify <em class="replaceable"><code>yes_or_no</code></em> | <em class="replaceable"><code>explicit</code></em> | <em class="replaceable"><code>master-only</code></em>; </span>]
-    [<span class="optional"> recursion <em class="replaceable"><code>yes_or_no</code></em>; </span>]
-    [<span class="optional"> rfc2308-type1 <em class="replaceable"><code>yes_or_no</code></em>; </span>]
-    [<span class="optional"> use-id-pool <em class="replaceable"><code>yes_or_no</code></em>; </span>]
-    [<span class="optional"> maintain-ixfr-base <em class="replaceable"><code>yes_or_no</code></em>; </span>]
-    [<span class="optional"> dnssec-enable <em class="replaceable"><code>yes_or_no</code></em>; </span>]
-    [<span class="optional"> dnssec-validation <em class="replaceable"><code>yes_or_no</code></em>; </span>]
-    [<span class="optional"> dnssec-lookaside <em class="replaceable"><code>domain</code></em> trust-anchor <em class="replaceable"><code>domain</code></em>; </span>]
-    [<span class="optional"> dnssec-must-be-secure <em class="replaceable"><code>domain yes_or_no</code></em>; </span>]
-    [<span class="optional"> dnssec-accept-expired <em class="replaceable"><code>yes_or_no</code></em>; </span>]
-    [<span class="optional"> forward ( <em class="replaceable"><code>only</code></em> | <em class="replaceable"><code>first</code></em> ); </span>]
-    [<span class="optional"> forwarders { [<span class="optional"> <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; ... </span>] }; </span>]
-    [<span class="optional"> dual-stack-servers [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] {
-        ( <em class="replaceable"><code>domain_name</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] |
-          <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ) ; 
-        ... }; </span>]
-    [<span class="optional"> check-names ( <em class="replaceable"><code>master</code></em> | <em class="replaceable"><code>slave</code></em> | <em class="replaceable"><code>response</code></em> )
-        ( <em class="replaceable"><code>warn</code></em> | <em class="replaceable"><code>fail</code></em> | <em class="replaceable"><code>ignore</code></em> ); </span>]
-    [<span class="optional"> check-mx ( <em class="replaceable"><code>warn</code></em> | <em class="replaceable"><code>fail</code></em> | <em class="replaceable"><code>ignore</code></em> ); </span>]
-    [<span class="optional"> check-wildcard <em class="replaceable"><code>yes_or_no</code></em>; </span>]
-    [<span class="optional"> check-integrity <em class="replaceable"><code>yes_or_no</code></em>; </span>]
-    [<span class="optional"> check-mx-cname ( <em class="replaceable"><code>warn</code></em> | <em class="replaceable"><code>fail</code></em> | <em class="replaceable"><code>ignore</code></em> ); </span>]
-    [<span class="optional"> check-srv-cname ( <em class="replaceable"><code>warn</code></em> | <em class="replaceable"><code>fail</code></em> | <em class="replaceable"><code>ignore</code></em> ); </span>]
-    [<span class="optional"> check-sibling <em class="replaceable"><code>yes_or_no</code></em>; </span>]
-    [<span class="optional"> allow-notify { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
-    [<span class="optional"> allow-query { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
-    [<span class="optional"> allow-query-cache { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
-    [<span class="optional"> allow-transfer { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
-    [<span class="optional"> allow-recursion { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
-    [<span class="optional"> allow-update { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
-    [<span class="optional"> allow-update-forwarding { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
-    [<span class="optional"> update-check-ksk <em class="replaceable"><code>yes_or_no</code></em>; </span>]
-    [<span class="optional"> allow-v6-synthesis { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
-    [<span class="optional"> blackhole { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
-    [<span class="optional"> avoid-v4-udp-ports { <em class="replaceable"><code>port_list</code></em> }; </span>]
-    [<span class="optional"> avoid-v6-udp-ports { <em class="replaceable"><code>port_list</code></em> }; </span>]
-    [<span class="optional"> listen-on [<span class="optional"> port <em class="replaceable"><code>ip_port</code></em> </span>] { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
-    [<span class="optional"> listen-on-v6 [<span class="optional"> port <em class="replaceable"><code>ip_port</code></em> </span>] { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
-    [<span class="optional"> query-source ( ( <em class="replaceable"><code>ip4_addr</code></em> | <em class="replaceable"><code>*</code></em> )
-        [<span class="optional"> port ( <em class="replaceable"><code>ip_port</code></em> | <em class="replaceable"><code>*</code></em> ) </span>] |
-        [<span class="optional"> address ( <em class="replaceable"><code>ip4_addr</code></em> | <em class="replaceable"><code>*</code></em> ) </span>]
-        [<span class="optional"> port ( <em class="replaceable"><code>ip_port</code></em> | <em class="replaceable"><code>*</code></em> ) </span>] ) ; </span>]
-    [<span class="optional"> query-source-v6 ( ( <em class="replaceable"><code>ip6_addr</code></em> | <em class="replaceable"><code>*</code></em> )
-        [<span class="optional"> port ( <em class="replaceable"><code>ip_port</code></em> | <em class="replaceable"><code>*</code></em> ) </span>] | 
-        [<span class="optional"> address ( <em class="replaceable"><code>ip6_addr</code></em> | <em class="replaceable"><code>*</code></em> ) </span>] 
-        [<span class="optional"> port ( <em class="replaceable"><code>ip_port</code></em> | <em class="replaceable"><code>*</code></em> ) </span>] ) ; </span>]
-    [<span class="optional"> max-transfer-time-in <em class="replaceable"><code>number</code></em>; </span>]
-    [<span class="optional"> max-transfer-time-out <em class="replaceable"><code>number</code></em>; </span>]
-    [<span class="optional"> max-transfer-idle-in <em class="replaceable"><code>number</code></em>; </span>]
-    [<span class="optional"> max-transfer-idle-out <em class="replaceable"><code>number</code></em>; </span>]
-    [<span class="optional"> tcp-clients <em class="replaceable"><code>number</code></em>; </span>]
-    [<span class="optional"> recursive-clients <em class="replaceable"><code>number</code></em>; </span>]
-    [<span class="optional"> serial-query-rate <em class="replaceable"><code>number</code></em>; </span>]
-    [<span class="optional"> serial-queries <em class="replaceable"><code>number</code></em>; </span>]
-    [<span class="optional"> tcp-listen-queue <em class="replaceable"><code>number</code></em>; </span>]
-    [<span class="optional"> transfer-format <em class="replaceable"><code>( one-answer | many-answers )</code></em>; </span>]
-    [<span class="optional"> transfers-in  <em class="replaceable"><code>number</code></em>; </span>]
-    [<span class="optional"> transfers-out <em class="replaceable"><code>number</code></em>; </span>]
-    [<span class="optional"> transfers-per-ns <em class="replaceable"><code>number</code></em>; </span>]
-    [<span class="optional"> transfer-source (<em class="replaceable"><code>ip4_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
-    [<span class="optional"> transfer-source-v6 (<em class="replaceable"><code>ip6_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
-    [<span class="optional"> alt-transfer-source (<em class="replaceable"><code>ip4_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
-    [<span class="optional"> alt-transfer-source-v6 (<em class="replaceable"><code>ip6_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
-    [<span class="optional"> use-alt-transfer-source <em class="replaceable"><code>yes_or_no</code></em>; </span>]
-    [<span class="optional"> notify-delay <em class="replaceable"><code>seconds</code></em> ; </span>]
-    [<span class="optional"> notify-source (<em class="replaceable"><code>ip4_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
-    [<span class="optional"> notify-source-v6 (<em class="replaceable"><code>ip6_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
-    [<span class="optional"> also-notify { <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; [<span class="optional"> <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; ... </span>] }; </span>]
-    [<span class="optional"> max-ixfr-log-size <em class="replaceable"><code>number</code></em>; </span>]
-    [<span class="optional"> max-journal-size <em class="replaceable"><code>size_spec</code></em>; </span>]
-    [<span class="optional"> coresize <em class="replaceable"><code>size_spec</code></em> ; </span>]
-    [<span class="optional"> datasize <em class="replaceable"><code>size_spec</code></em> ; </span>]
-    [<span class="optional"> files <em class="replaceable"><code>size_spec</code></em> ; </span>]
-    [<span class="optional"> stacksize <em class="replaceable"><code>size_spec</code></em> ; </span>]
-    [<span class="optional"> cleaning-interval <em class="replaceable"><code>number</code></em>; </span>]
-    [<span class="optional"> heartbeat-interval <em class="replaceable"><code>number</code></em>; </span>]
-    [<span class="optional"> interface-interval <em class="replaceable"><code>number</code></em>; </span>]
-    [<span class="optional"> statistics-interval <em class="replaceable"><code>number</code></em>; </span>]
-    [<span class="optional"> topology { <em class="replaceable"><code>address_match_list</code></em> }</span>];
-    [<span class="optional"> sortlist { <em class="replaceable"><code>address_match_list</code></em> }</span>];
-    [<span class="optional"> rrset-order { <em class="replaceable"><code>order_spec</code></em> ; [<span class="optional"> <em class="replaceable"><code>order_spec</code></em> ; ... </span>] </span>] };
-    [<span class="optional"> lame-ttl <em class="replaceable"><code>number</code></em>; </span>]
-    [<span class="optional"> max-ncache-ttl <em class="replaceable"><code>number</code></em>; </span>]
-    [<span class="optional"> max-cache-ttl <em class="replaceable"><code>number</code></em>; </span>]
-    [<span class="optional"> sig-validity-interval <em class="replaceable"><code>number</code></em> ; </span>]
-    [<span class="optional"> min-roots <em class="replaceable"><code>number</code></em>; </span>]
-    [<span class="optional"> use-ixfr <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
-    [<span class="optional"> provide-ixfr <em class="replaceable"><code>yes_or_no</code></em>; </span>]
-    [<span class="optional"> request-ixfr <em class="replaceable"><code>yes_or_no</code></em>; </span>]
-    [<span class="optional"> treat-cr-as-space <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
-    [<span class="optional"> min-refresh-time <em class="replaceable"><code>number</code></em> ; </span>]
-    [<span class="optional"> max-refresh-time <em class="replaceable"><code>number</code></em> ; </span>]
-    [<span class="optional"> min-retry-time <em class="replaceable"><code>number</code></em> ; </span>]
-    [<span class="optional"> max-retry-time <em class="replaceable"><code>number</code></em> ; </span>]
-    [<span class="optional"> port <em class="replaceable"><code>ip_port</code></em>; </span>]
-    [<span class="optional"> additional-from-auth <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
-    [<span class="optional"> additional-from-cache <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
-    [<span class="optional"> random-device <em class="replaceable"><code>path_name</code></em> ; </span>]
-    [<span class="optional"> max-cache-size <em class="replaceable"><code>size_spec</code></em> ; </span>]
-    [<span class="optional"> match-mapped-addresses <em class="replaceable"><code>yes_or_no</code></em>; </span>]
-    [<span class="optional"> preferred-glue ( <em class="replaceable"><code>A</code></em> | <em class="replaceable"><code>AAAA</code></em> | <em class="replaceable"><code>NONE</code></em> ); </span>]
-    [<span class="optional"> edns-udp-size <em class="replaceable"><code>number</code></em>; </span>]
-    [<span class="optional"> max-udp-size <em class="replaceable"><code>number</code></em>; </span>]
-    [<span class="optional"> root-delegation-only [<span class="optional"> exclude { <em class="replaceable"><code>namelist</code></em> } </span>] ; </span>]
-    [<span class="optional"> querylog <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
-    [<span class="optional"> disable-algorithms <em class="replaceable"><code>domain</code></em> { <em class="replaceable"><code>algorithm</code></em>; [<span class="optional"> <em class="replaceable"><code>algorithm</code></em>; </span>] }; </span>]
-    [<span class="optional"> acache-enable <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
-    [<span class="optional"> acache-cleaning-interval <em class="replaceable"><code>number</code></em>; </span>]
-    [<span class="optional"> max-acache-size <em class="replaceable"><code>size_spec</code></em> ; </span>]
-    [<span class="optional"> clients-per-query <em class="replaceable"><code>number</code></em> ; </span>]
-    [<span class="optional"> max-clients-per-query <em class="replaceable"><code>number</code></em> ; </span>]
-    [<span class="optional"> masterfile-format (<code class="constant">text</code>|<code class="constant">raw</code>) ; </span>]
-    [<span class="optional"> empty-server <em class="replaceable"><code>name</code></em> ; </span>]
-    [<span class="optional"> empty-contact <em class="replaceable"><code>name</code></em> ; </span>]
-    [<span class="optional"> empty-zones-enable <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
-    [<span class="optional"> disable-empty-zone <em class="replaceable"><code>zone_name</code></em> ; </span>]
-    [<span class="optional"> zero-no-soa-ttl <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
-    [<span class="optional"> zero-no-soa-ttl-cache <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
-};
-</pre>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="options"></a><span><strong class="command">options</strong></span> Statement Definition and
-          Usage</h3></div></div></div>
-<p>
-          The <span><strong class="command">options</strong></span> statement sets up global
-          options
-          to be used by <acronym class="acronym">BIND</acronym>. This statement
-          may appear only
-          once in a configuration file. If there is no <span><strong class="command">options</strong></span>
-          statement, an options block with each option set to its default will
-          be used.
-        </p>
-<div class="variablelist"><dl>
-<dt><span class="term"><span><strong class="command">directory</strong></span></span></dt>
-<dd><p>
-                The working directory of the server.
-                Any non-absolute pathnames in the configuration file will be
-                taken
-                as relative to this directory. The default location for most
-                server
-                output files (e.g. <code class="filename">named.run</code>)
-                is this directory.
-                If a directory is not specified, the working directory
-                defaults to `<code class="filename">.</code>', the directory from
-                which the server
-                was started. The directory specified should be an absolute
-                path.
-              </p></dd>
-<dt><span class="term"><span><strong class="command">key-directory</strong></span></span></dt>
-<dd><p>
-                When performing dynamic update of secure zones, the
-                directory where the public and private key files should be
-                found,
-                if different than the current working directory.  The
-                directory specified
-                must be an absolute path.
-              </p></dd>
-<dt><span class="term"><span><strong class="command">named-xfer</strong></span></span></dt>
-<dd><p>
-                <span class="emphasis"><em>This option is obsolete.</em></span>
-                It was used in <acronym class="acronym">BIND</acronym> 8 to
-                specify the pathname to the <span><strong class="command">named-xfer</strong></span> program.
-                In <acronym class="acronym">BIND</acronym> 9, no separate <span><strong class="command">named-xfer</strong></span> program is
-                needed; its functionality is built into the name server.
-              </p></dd>
-<dt><span class="term"><span><strong class="command">tkey-domain</strong></span></span></dt>
-<dd><p>
-                The domain appended to the names of all
-                shared keys generated with
-                <span><strong class="command">TKEY</strong></span>. When a client
-                requests a <span><strong class="command">TKEY</strong></span> exchange, it
-                may or may not specify
-                the desired name for the key. If present, the name of the
-                shared
-                key will be "<code class="varname">client specified part</code>" +
-                "<code class="varname">tkey-domain</code>".
-                Otherwise, the name of the shared key will be "<code class="varname">random hex
-digits</code>" + "<code class="varname">tkey-domain</code>". In most cases,
-                the <span><strong class="command">domainname</strong></span> should be the
-                server's domain
-                name.
-              </p></dd>
-<dt><span class="term"><span><strong class="command">tkey-dhkey</strong></span></span></dt>
-<dd><p>
-                The Diffie-Hellman key used by the server
-                to generate shared keys with clients using the Diffie-Hellman
-                mode
-                of <span><strong class="command">TKEY</strong></span>. The server must be
-                able to load the
-                public and private keys from files in the working directory.
-                In
-                most cases, the keyname should be the server's host name.
-              </p></dd>
-<dt><span class="term"><span><strong class="command">cache-file</strong></span></span></dt>
-<dd><p>
-                This is for testing only.  Do not use.
-              </p></dd>
-<dt><span class="term"><span><strong class="command">dump-file</strong></span></span></dt>
-<dd><p>
-                The pathname of the file the server dumps
-                the database to when instructed to do so with
-                <span><strong class="command">rndc dumpdb</strong></span>.
-                If not specified, the default is <code class="filename">named_dump.db</code>.
-              </p></dd>
-<dt><span class="term"><span><strong class="command">memstatistics-file</strong></span></span></dt>
-<dd>
-<p>
-                The pathname of the file the server writes memory
-                usage statistics to on exit.  If specified the
-                statistics will be written to the file on exit.
-              </p>
-<p>
-                In <acronym class="acronym">BIND</acronym> 9.5 and later this will
-                default to <code class="filename">named.memstats</code>.
-                <acronym class="acronym">BIND</acronym> 9.5 will also introduce
-                <span><strong class="command">memstatistics</strong></span> to control the
-                writing.
-              </p>
-</dd>
-<dt><span class="term"><span><strong class="command">pid-file</strong></span></span></dt>
-<dd><p>
-                The pathname of the file the server writes its process ID
-                in. If not specified, the default is <code class="filename">/var/run/named.pid</code>.
-                The pid-file is used by programs that want to send signals to
-                the running
-                name server. Specifying <span><strong class="command">pid-file none</strong></span> disables the
-                use of a PID file &#8212; no file will be written and any
-                existing one will be removed.  Note that <span><strong class="command">none</strong></span>
-                is a keyword, not a filename, and therefore is not enclosed
-                in
-                double quotes.
-              </p></dd>
-<dt><span class="term"><span><strong class="command">recursing-file</strong></span></span></dt>
-<dd><p>
-                The pathname of the file the server dumps
-                the queries that are currently recursing when instructed
-                to do so with <span><strong class="command">rndc recursing</strong></span>.
-                If not specified, the default is <code class="filename">named.recursing</code>.
-              </p></dd>
-<dt><span class="term"><span><strong class="command">statistics-file</strong></span></span></dt>
-<dd><p>
-                The pathname of the file the server appends statistics
-                to when instructed to do so using <span><strong class="command">rndc stats</strong></span>.
-                If not specified, the default is <code class="filename">named.stats</code> in the
-                server's current directory.  The format of the file is
-                described
-                in <a href="Bv9ARM.ch06.html#statsfile" title="The Statistics File">the section called &#8220;The Statistics File&#8221;</a>.
-              </p></dd>
-<dt><span class="term"><span><strong class="command">port</strong></span></span></dt>
-<dd><p>
-                The UDP/TCP port number the server uses for
-                receiving and sending DNS protocol traffic.
-                The default is 53.  This option is mainly intended for server
-                testing;
-                a server using a port other than 53 will not be able to
-                communicate with
-                the global DNS.
-              </p></dd>
-<dt><span class="term"><span><strong class="command">random-device</strong></span></span></dt>
-<dd><p>
-                The source of entropy to be used by the server.  Entropy is
-                primarily needed
-                for DNSSEC operations, such as TKEY transactions and dynamic
-                update of signed
-                zones.  This options specifies the device (or file) from which
-                to read
-                entropy.  If this is a file, operations requiring entropy will
-                fail when the
-                file has been exhausted.  If not specified, the default value
-                is
-                <code class="filename">/dev/random</code>
-                (or equivalent) when present, and none otherwise.  The
-                <span><strong class="command">random-device</strong></span> option takes
-                effect during
-                the initial configuration load at server startup time and
-                is ignored on subsequent reloads.
-              </p></dd>
-<dt><span class="term"><span><strong class="command">preferred-glue</strong></span></span></dt>
-<dd><p>
-                If specified, the listed type (A or AAAA) will be emitted
-                before other glue
-                in the additional section of a query response.
-                The default is not to prefer any type (NONE).
-              </p></dd>
-<dt><span class="term"><span><strong class="command">root-delegation-only</strong></span></span></dt>
-<dd>
-<p>
-                Turn on enforcement of delegation-only in TLDs (top level domains) and root zones
-                with an optional
-                exclude list.
-              </p>
-<p>
-                Note some TLDs are not delegation only (e.g. "DE", "LV", "US"
-                and "MUSEUM").
-              </p>
-<pre class="programlisting">
-options {
-        root-delegation-only exclude { "de"; "lv"; "us"; "museum"; };
-};
-</pre>
-</dd>
-<dt><span class="term"><span><strong class="command">disable-algorithms</strong></span></span></dt>
-<dd><p>
-                Disable the specified DNSSEC algorithms at and below the
-                specified name.
-                Multiple <span><strong class="command">disable-algorithms</strong></span>
-                statements are allowed.
-                Only the most specific will be applied.
-              </p></dd>
-<dt><span class="term"><span><strong class="command">dnssec-lookaside</strong></span></span></dt>
-<dd><p>
-                When set, <span><strong class="command">dnssec-lookaside</strong></span>
-                provides the
-                validator with an alternate method to validate DNSKEY records
-                at the
-                top of a zone.  When a DNSKEY is at or below a domain
-                specified by the
-                deepest <span><strong class="command">dnssec-lookaside</strong></span>, and
-                the normal dnssec validation
-                has left the key untrusted, the trust-anchor will be append to
-                the key
-                name and a DLV record will be looked up to see if it can
-                validate the
-                key.  If the DLV record validates a DNSKEY (similarly to the
-                way a DS
-                record does) the DNSKEY RRset is deemed to be trusted.
-              </p></dd>
-<dt><span class="term"><span><strong class="command">dnssec-must-be-secure</strong></span></span></dt>
-<dd><p>
-                Specify hierarchies which must be or may not be secure (signed and
-                validated).
-                If <strong class="userinput"><code>yes</code></strong>, then named will only accept
-                answers if they
-                are secure.
-                If <strong class="userinput"><code>no</code></strong>, then normal dnssec validation
-                applies
-                allowing for insecure answers to be accepted.
-                The specified domain must be under a <span><strong class="command">trusted-key</strong></span> or
-                <span><strong class="command">dnssec-lookaside</strong></span> must be
-                active.
-              </p></dd>
-</dl></div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="boolean_options"></a>Boolean Options</h4></div></div></div>
-<div class="variablelist"><dl>
-<dt><span class="term"><span><strong class="command">auth-nxdomain</strong></span></span></dt>
-<dd><p>
-                  If <strong class="userinput"><code>yes</code></strong>, then the <span><strong class="command">AA</strong></span> bit
-                  is always set on NXDOMAIN responses, even if the server is
-                  not actually
-                  authoritative. The default is <strong class="userinput"><code>no</code></strong>;
-                  this is
-                  a change from <acronym class="acronym">BIND</acronym> 8. If you
-                  are using very old DNS software, you
-                  may need to set it to <strong class="userinput"><code>yes</code></strong>.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">deallocate-on-exit</strong></span></span></dt>
-<dd><p>
-                  This option was used in <acronym class="acronym">BIND</acronym>
-                  8 to enable checking
-                  for memory leaks on exit. <acronym class="acronym">BIND</acronym> 9 ignores the option and always performs
-                  the checks.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">dialup</strong></span></span></dt>
-<dd>
-<p>
-                  If <strong class="userinput"><code>yes</code></strong>, then the
-                  server treats all zones as if they are doing zone transfers
-                  across
-                  a dial-on-demand dialup link, which can be brought up by
-                  traffic
-                  originating from this server. This has different effects
-                  according
-                  to zone type and concentrates the zone maintenance so that
-                  it all
-                  happens in a short interval, once every <span><strong class="command">heartbeat-interval</strong></span> and
-                  hopefully during the one call. It also suppresses some of
-                  the normal
-                  zone maintenance traffic. The default is <strong class="userinput"><code>no</code></strong>.
-                </p>
-<p>
-                  The <span><strong class="command">dialup</strong></span> option
-                  may also be specified in the <span><strong class="command">view</strong></span> and
-                  <span><strong class="command">zone</strong></span> statements,
-                  in which case it overrides the global <span><strong class="command">dialup</strong></span>
-                  option.
-                </p>
-<p>
-                  If the zone is a master zone, then the server will send out a
-                  NOTIFY
-                  request to all the slaves (default). This should trigger the
-                  zone serial
-                  number check in the slave (providing it supports NOTIFY)
-                  allowing the slave
-                  to verify the zone while the connection is active.
-                  The set of servers to which NOTIFY is sent can be controlled
-                  by
-                  <span><strong class="command">notify</strong></span> and <span><strong class="command">also-notify</strong></span>.
-                </p>
-<p>
-                  If the
-                  zone is a slave or stub zone, then the server will suppress
-                  the regular
-                  "zone up to date" (refresh) queries and only perform them
-                  when the
-                  <span><strong class="command">heartbeat-interval</strong></span> expires in
-                  addition to sending
-                  NOTIFY requests.
-                </p>
-<p>
-                  Finer control can be achieved by using
-                  <strong class="userinput"><code>notify</code></strong> which only sends NOTIFY
-                  messages,
-                  <strong class="userinput"><code>notify-passive</code></strong> which sends NOTIFY
-                  messages and
-                  suppresses the normal refresh queries, <strong class="userinput"><code>refresh</code></strong>
-                  which suppresses normal refresh processing and sends refresh
-                  queries
-                  when the <span><strong class="command">heartbeat-interval</strong></span>
-                  expires, and
-                  <strong class="userinput"><code>passive</code></strong> which just disables normal
-                  refresh
-                  processing.
-                </p>
-<div class="informaltable"><table border="1">
-<colgroup>
-<col>
-<col>
-<col>
-<col>
-</colgroup>
-<tbody>
-<tr>
-<td>
-                          <p>
-                            dialup mode
-                          </p>
-                        </td>
-<td>
-                          <p>
-                            normal refresh
-                          </p>
-                        </td>
-<td>
-                          <p>
-                            heart-beat refresh
-                          </p>
-                        </td>
-<td>
-                          <p>
-                            heart-beat notify
-                          </p>
-                        </td>
-</tr>
-<tr>
-<td>
-                          <p><span><strong class="command">no</strong></span> (default)</p>
-                        </td>
-<td>
-                          <p>
-                            yes
-                          </p>
-                        </td>
-<td>
-                          <p>
-                            no
-                          </p>
-                        </td>
-<td>
-                          <p>
-                            no
-                          </p>
-                        </td>
-</tr>
-<tr>
-<td>
-                          <p><span><strong class="command">yes</strong></span></p>
-                        </td>
-<td>
-                          <p>
-                            no
-                          </p>
-                        </td>
-<td>
-                          <p>
-                            yes
-                          </p>
-                        </td>
-<td>
-                          <p>
-                            yes
-                          </p>
-                        </td>
-</tr>
-<tr>
-<td>
-                          <p><span><strong class="command">notify</strong></span></p>
-                        </td>
-<td>
-                          <p>
-                            yes
-                          </p>
-                        </td>
-<td>
-                          <p>
-                            no
-                          </p>
-                        </td>
-<td>
-                          <p>
-                            yes
-                          </p>
-                        </td>
-</tr>
-<tr>
-<td>
-                          <p><span><strong class="command">refresh</strong></span></p>
-                        </td>
-<td>
-                          <p>
-                            no
-                          </p>
-                        </td>
-<td>
-                          <p>
-                            yes
-                          </p>
-                        </td>
-<td>
-                          <p>
-                            no
-                          </p>
-                        </td>
-</tr>
-<tr>
-<td>
-                          <p><span><strong class="command">passive</strong></span></p>
-                        </td>
-<td>
-                          <p>
-                            no
-                          </p>
-                        </td>
-<td>
-                          <p>
-                            no
-                          </p>
-                        </td>
-<td>
-                          <p>
-                            no
-                          </p>
-                        </td>
-</tr>
-<tr>
-<td>
-                          <p><span><strong class="command">notify-passive</strong></span></p>
-                        </td>
-<td>
-                          <p>
-                            no
-                          </p>
-                        </td>
-<td>
-                          <p>
-                            no
-                          </p>
-                        </td>
-<td>
-                          <p>
-                            yes
-                          </p>
-                        </td>
-</tr>
-</tbody>
-</table></div>
-<p>
-                  Note that normal NOTIFY processing is not affected by
-                  <span><strong class="command">dialup</strong></span>.
-                </p>
-</dd>
-<dt><span class="term"><span><strong class="command">fake-iquery</strong></span></span></dt>
-<dd><p>
-                  In <acronym class="acronym">BIND</acronym> 8, this option
-                  enabled simulating the obsolete DNS query type
-                  IQUERY. <acronym class="acronym">BIND</acronym> 9 never does
-                  IQUERY simulation.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">fetch-glue</strong></span></span></dt>
-<dd><p>
-                  This option is obsolete.
-                  In BIND 8, <strong class="userinput"><code>fetch-glue yes</code></strong>
-                  caused the server to attempt to fetch glue resource records
-                  it
-                  didn't have when constructing the additional
-                  data section of a response.  This is now considered a bad
-                  idea
-                  and BIND 9 never does it.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">flush-zones-on-shutdown</strong></span></span></dt>
-<dd><p>
-                  When the nameserver exits due receiving SIGTERM,
-                  flush or do not flush any pending zone writes.  The default
-                  is
-                  <span><strong class="command">flush-zones-on-shutdown</strong></span> <strong class="userinput"><code>no</code></strong>.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">has-old-clients</strong></span></span></dt>
-<dd><p>
-                  This option was incorrectly implemented
-                  in <acronym class="acronym">BIND</acronym> 8, and is ignored by <acronym class="acronym">BIND</acronym> 9.
-                  To achieve the intended effect
-                  of
-                  <span><strong class="command">has-old-clients</strong></span> <strong class="userinput"><code>yes</code></strong>, specify
-                  the two separate options <span><strong class="command">auth-nxdomain</strong></span> <strong class="userinput"><code>yes</code></strong>
-                  and <span><strong class="command">rfc2308-type1</strong></span> <strong class="userinput"><code>no</code></strong> instead.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">host-statistics</strong></span></span></dt>
-<dd><p>
-                  In BIND 8, this enables keeping of
-                  statistics for every host that the name server interacts
-                  with.
-                  Not implemented in BIND 9.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">maintain-ixfr-base</strong></span></span></dt>
-<dd><p>
-                  <span class="emphasis"><em>This option is obsolete</em></span>.
-                  It was used in <acronym class="acronym">BIND</acronym> 8 to
-                  determine whether a transaction log was
-                  kept for Incremental Zone Transfer. <acronym class="acronym">BIND</acronym> 9 maintains a transaction
-                  log whenever possible.  If you need to disable outgoing
-                  incremental zone
-                  transfers, use <span><strong class="command">provide-ixfr</strong></span> <strong class="userinput"><code>no</code></strong>.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">minimal-responses</strong></span></span></dt>
-<dd><p>
-                  If <strong class="userinput"><code>yes</code></strong>, then when generating
-                  responses the server will only add records to the authority
-                  and additional data sections when they are required (e.g.
-                  delegations, negative responses).  This may improve the
-                  performance of the server.
-                  The default is <strong class="userinput"><code>no</code></strong>.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">multiple-cnames</strong></span></span></dt>
-<dd><p>
-                  This option was used in <acronym class="acronym">BIND</acronym> 8 to allow
-                  a domain name to have multiple CNAME records in violation of
-                  the DNS standards.  <acronym class="acronym">BIND</acronym> 9.2 onwards
-                  always strictly enforces the CNAME rules both in master
-                  files and dynamic updates.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">notify</strong></span></span></dt>
-<dd>
-<p>
-                  If <strong class="userinput"><code>yes</code></strong> (the default),
-                  DNS NOTIFY messages are sent when a zone the server is
-                  authoritative for
-                  changes, see <a href="Bv9ARM.ch04.html#notify" title="Notify">the section called &#8220;Notify&#8221;</a>.  The messages are
-                  sent to the
-                  servers listed in the zone's NS records (except the master
-                  server identified
-                  in the SOA MNAME field), and to any servers listed in the
-                  <span><strong class="command">also-notify</strong></span> option.
-                </p>
-<p>
-                  If <strong class="userinput"><code>master-only</code></strong>, notifies are only
-                  sent
-                  for master zones.
-                  If <strong class="userinput"><code>explicit</code></strong>, notifies are sent only
-                  to
-                  servers explicitly listed using <span><strong class="command">also-notify</strong></span>.
-                  If <strong class="userinput"><code>no</code></strong>, no notifies are sent.
-                </p>
-<p>
-                  The <span><strong class="command">notify</strong></span> option may also be
-                  specified in the <span><strong class="command">zone</strong></span>
-                  statement,
-                  in which case it overrides the <span><strong class="command">options notify</strong></span> statement.
-                  It would only be necessary to turn off this option if it
-                  caused slaves
-                  to crash.
-                </p>
-</dd>
-<dt><span class="term"><span><strong class="command">recursion</strong></span></span></dt>
-<dd><p>
-                  If <strong class="userinput"><code>yes</code></strong>, and a
-                  DNS query requests recursion, then the server will attempt
-                  to do
-                  all the work required to answer the query. If recursion is
-                  off
-                  and the server does not already know the answer, it will
-                  return a
-                  referral response. The default is
-                  <strong class="userinput"><code>yes</code></strong>.
-                  Note that setting <span><strong class="command">recursion no</strong></span> does not prevent
-                  clients from getting data from the server's cache; it only
-                  prevents new data from being cached as an effect of client
-                  queries.
-                  Caching may still occur as an effect the server's internal
-                  operation, such as NOTIFY address lookups.
-                  See also <span><strong class="command">fetch-glue</strong></span> above.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">rfc2308-type1</strong></span></span></dt>
-<dd>
-<p>
-                  Setting this to <strong class="userinput"><code>yes</code></strong> will
-                  cause the server to send NS records along with the SOA
-                  record for negative
-                  answers. The default is <strong class="userinput"><code>no</code></strong>.
-                </p>
-<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-<p>
-                    Not yet implemented in <acronym class="acronym">BIND</acronym>
-                    9.
-                  </p>
-</div>
-</dd>
-<dt><span class="term"><span><strong class="command">use-id-pool</strong></span></span></dt>
-<dd><p>
-                  <span class="emphasis"><em>This option is obsolete</em></span>.
-                  <acronym class="acronym">BIND</acronym> 9 always allocates query
-                  IDs from a pool.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">zone-statistics</strong></span></span></dt>
-<dd><p>
-                  If <strong class="userinput"><code>yes</code></strong>, the server will collect
-                  statistical data on all zones (unless specifically turned
-                  off
-                  on a per-zone basis by specifying <span><strong class="command">zone-statistics no</strong></span>
-                  in the <span><strong class="command">zone</strong></span> statement).
-                  These statistics may be accessed
-                  using <span><strong class="command">rndc stats</strong></span>, which will
-                  dump them to the file listed
-                  in the <span><strong class="command">statistics-file</strong></span>.  See
-                  also <a href="Bv9ARM.ch06.html#statsfile" title="The Statistics File">the section called &#8220;The Statistics File&#8221;</a>.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">use-ixfr</strong></span></span></dt>
-<dd><p>
-                  <span class="emphasis"><em>This option is obsolete</em></span>.
-                  If you need to disable IXFR to a particular server or
-                  servers, see
-                  the information on the <span><strong class="command">provide-ixfr</strong></span> option
-                  in <a href="Bv9ARM.ch06.html#server_statement_definition_and_usage" title="server Statement Definition and
-            Usage">the section called &#8220;<span><strong class="command">server</strong></span> Statement Definition and
-            Usage&#8221;</a>.
-                  See also
-                  <a href="Bv9ARM.ch04.html#incremental_zone_transfers" title="Incremental Zone Transfers (IXFR)">the section called &#8220;Incremental Zone Transfers (IXFR)&#8221;</a>.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">provide-ixfr</strong></span></span></dt>
-<dd><p>
-                  See the description of
-                  <span><strong class="command">provide-ixfr</strong></span> in
-                  <a href="Bv9ARM.ch06.html#server_statement_definition_and_usage" title="server Statement Definition and
-            Usage">the section called &#8220;<span><strong class="command">server</strong></span> Statement Definition and
-            Usage&#8221;</a>.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">request-ixfr</strong></span></span></dt>
-<dd><p>
-                  See the description of
-                  <span><strong class="command">request-ixfr</strong></span> in
-                  <a href="Bv9ARM.ch06.html#server_statement_definition_and_usage" title="server Statement Definition and
-            Usage">the section called &#8220;<span><strong class="command">server</strong></span> Statement Definition and
-            Usage&#8221;</a>.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">treat-cr-as-space</strong></span></span></dt>
-<dd><p>
-                  This option was used in <acronym class="acronym">BIND</acronym>
-                  8 to make
-                  the server treat carriage return ("<span><strong class="command">\r</strong></span>") characters the same way
-                  as a space or tab character,
-                  to facilitate loading of zone files on a UNIX system that
-                  were generated
-                  on an NT or DOS machine. In <acronym class="acronym">BIND</acronym> 9, both UNIX "<span><strong class="command">\n</strong></span>"
-                  and NT/DOS "<span><strong class="command">\r\n</strong></span>" newlines
-                  are always accepted,
-                  and the option is ignored.
-                </p></dd>
-<dt>
-<span class="term"><span><strong class="command">additional-from-auth</strong></span>, </span><span class="term"><span><strong class="command">additional-from-cache</strong></span></span>
-</dt>
-<dd>
-<p>
-                  These options control the behavior of an authoritative
-                  server when
-                  answering queries which have additional data, or when
-                  following CNAME
-                  and DNAME chains.
-                </p>
-<p>
-                  When both of these options are set to <strong class="userinput"><code>yes</code></strong>
-                  (the default) and a
-                  query is being answered from authoritative data (a zone
-                  configured into the server), the additional data section of
-                  the
-                  reply will be filled in using data from other authoritative
-                  zones
-                  and from the cache.  In some situations this is undesirable,
-                  such
-                  as when there is concern over the correctness of the cache,
-                  or
-                  in servers where slave zones may be added and modified by
-                  untrusted third parties.  Also, avoiding
-                  the search for this additional data will speed up server
-                  operations
-                  at the possible expense of additional queries to resolve
-                  what would
-                  otherwise be provided in the additional section.
-                </p>
-<p>
-                  For example, if a query asks for an MX record for host <code class="literal">foo.example.com</code>,
-                  and the record found is "<code class="literal">MX 10 mail.example.net</code>", normally the address
-                  records (A and AAAA) for <code class="literal">mail.example.net</code> will be provided as well,
-                  if known, even though they are not in the example.com zone.
-                  Setting these options to <span><strong class="command">no</strong></span>
-                  disables this behavior and makes
-                  the server only search for additional data in the zone it
-                  answers from.
-                </p>
-<p>
-                  These options are intended for use in authoritative-only
-                  servers, or in authoritative-only views.  Attempts to set
-                  them to <span><strong class="command">no</strong></span> without also
-                  specifying
-                  <span><strong class="command">recursion no</strong></span> will cause the
-                  server to
-                  ignore the options and log a warning message.
-                </p>
-<p>
-                  Specifying <span><strong class="command">additional-from-cache no</strong></span> actually
-                  disables the use of the cache not only for additional data
-                  lookups
-                  but also when looking up the answer.  This is usually the
-                  desired
-                  behavior in an authoritative-only server where the
-                  correctness of
-                  the cached data is an issue.
-                </p>
-<p>
-                  When a name server is non-recursively queried for a name
-                  that is not
-                  below the apex of any served zone, it normally answers with
-                  an
-                  "upwards referral" to the root servers or the servers of
-                  some other
-                  known parent of the query name.  Since the data in an
-                  upwards referral
-                  comes from the cache, the server will not be able to provide
-                  upwards
-                  referrals when <span><strong class="command">additional-from-cache no</strong></span>
-                  has been specified.  Instead, it will respond to such
-                  queries
-                  with REFUSED.  This should not cause any problems since
-                  upwards referrals are not required for the resolution
-                  process.
-                </p>
-</dd>
-<dt><span class="term"><span><strong class="command">match-mapped-addresses</strong></span></span></dt>
-<dd><p>
-                  If <strong class="userinput"><code>yes</code></strong>, then an
-                  IPv4-mapped IPv6 address will match any address match
-                  list entries that match the corresponding IPv4 address.
-                  Enabling this option is sometimes useful on IPv6-enabled
-                  Linux
-                  systems, to work around a kernel quirk that causes IPv4
-                  TCP connections such as zone transfers to be accepted
-                  on an IPv6 socket using mapped addresses, causing
-                  address match lists designed for IPv4 to fail to match.
-                  The use of this option for any other purpose is discouraged.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">ixfr-from-differences</strong></span></span></dt>
-<dd>
-<p>
-                  When <strong class="userinput"><code>yes</code></strong> and the server loads a new version of a master
-                  zone from its zone file or receives a new version of a slave
-                  file by a non-incremental zone transfer, it will compare
-                  the new version to the previous one and calculate a set
-                  of differences.  The differences are then logged in the
-                  zone's journal file such that the changes can be transmitted
-                  to downstream slaves as an incremental zone transfer.
-                </p>
-<p>
-                  By allowing incremental zone transfers to be used for
-                  non-dynamic zones, this option saves bandwidth at the
-                  expense of increased CPU and memory consumption at the
-                  master.
-                  In particular, if the new version of a zone is completely
-                  different from the previous one, the set of differences
-                  will be of a size comparable to the combined size of the
-                  old and new zone version, and the server will need to
-                  temporarily allocate memory to hold this complete
-                  difference set.
-                </p>
-<p><span><strong class="command">ixfr-from-differences</strong></span>
-                  also accepts <span><strong class="command">master</strong></span> and
-                  <span><strong class="command">slave</strong></span> at the view and options
-                  levels which causes
-                  <span><strong class="command">ixfr-from-differences</strong></span> to apply to
-                  all <span><strong class="command">master</strong></span> or
-                  <span><strong class="command">slave</strong></span> zones respectively.
-                </p>
-</dd>
-<dt><span class="term"><span><strong class="command">multi-master</strong></span></span></dt>
-<dd><p>
-                  This should be set when you have multiple masters for a zone
-                  and the
-                  addresses refer to different machines.  If <strong class="userinput"><code>yes</code></strong>, named will
-                  not log
-                  when the serial number on the master is less than what named
-                  currently
-                  has.  The default is <strong class="userinput"><code>no</code></strong>.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">dnssec-enable</strong></span></span></dt>
-<dd><p>
-                  Enable DNSSEC support in named.  Unless set to <strong class="userinput"><code>yes</code></strong>,
-                  named behaves as if it does not support DNSSEC.
-                  The default is <strong class="userinput"><code>yes</code></strong>.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">dnssec-validation</strong></span></span></dt>
-<dd><p>
-                  Enable DNSSEC validation in named.
-                  Note <span><strong class="command">dnssec-enable</strong></span> also needs to be
-                  set to <strong class="userinput"><code>yes</code></strong> to be effective.
-                  The default is <strong class="userinput"><code>no</code></strong>.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">dnssec-accept-expired</strong></span></span></dt>
-<dd><p>
-                  Accept expired signatures when verifying DNSSEC signatures.
-                  The default is <strong class="userinput"><code>no</code></strong>.
-                  Setting this option to "yes" leaves named vulnerable to replay attacks.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">querylog</strong></span></span></dt>
-<dd><p>
-                  Specify whether query logging should be started when named
-                  starts.
-                  If <span><strong class="command">querylog</strong></span> is not specified,
-                  then the query logging
-                  is determined by the presence of the logging category <span><strong class="command">queries</strong></span>.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">check-names</strong></span></span></dt>
-<dd>
-<p>
-                  This option is used to restrict the character set and syntax
-                  of
-                  certain domain names in master files and/or DNS responses
-                  received
-                  from the network.  The default varies according to usage
-                  area.  For
-                  <span><strong class="command">master</strong></span> zones the default is <span><strong class="command">fail</strong></span>.
-                  For <span><strong class="command">slave</strong></span> zones the default
-                  is <span><strong class="command">warn</strong></span>.
-                  For answers received from the network (<span><strong class="command">response</strong></span>)
-                  the default is <span><strong class="command">ignore</strong></span>.
-                </p>
-<p>
-                  The rules for legal hostnames and mail domains are derived
-                  from RFC 952 and RFC 821 as modified by RFC 1123.
-                </p>
-<p><span><strong class="command">check-names</strong></span>
-                  applies to the owner names of A, AAA and MX records.
-                  It also applies to the domain names in the RDATA of NS, SOA
-                  and MX records.
-                  It also applies to the RDATA of PTR records where the owner
-                  name indicated that it is a reverse lookup of a hostname
-                  (the owner name ends in IN-ADDR.ARPA, IP6.ARPA, or IP6.INT).
-                </p>
-</dd>
-<dt><span class="term"><span><strong class="command">check-mx</strong></span></span></dt>
-<dd><p>
-                  Check whether the MX record appears to refer to a IP address.
-                  The default is to <span><strong class="command">warn</strong></span>.  Other possible
-                  values are <span><strong class="command">fail</strong></span> and
-                  <span><strong class="command">ignore</strong></span>.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">check-wildcard</strong></span></span></dt>
-<dd><p>
-                  This option is used to check for non-terminal wildcards.
-                  The use of non-terminal wildcards is almost always as a
-                  result of a failure
-                  to understand the wildcard matching algorithm (RFC 1034).
-                  This option
-                  affects master zones.  The default (<span><strong class="command">yes</strong></span>) is to check
-                  for non-terminal wildcards and issue a warning.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">check-integrity</strong></span></span></dt>
-<dd><p>
-                  Perform post load zone integrity checks on master
-                  zones.  This checks that MX and SRV records refer
-                  to address (A or AAAA) records and that glue
-                  address records exist for delegated zones.  For
-                  MX and SRV records only in-zone hostnames are
-                  checked (for out-of-zone hostnames use named-checkzone).
-                  For NS records only names below top of zone are
-                  checked (for out-of-zone names and glue consistency
-                  checks use named-checkzone).  The default is
-                  <span><strong class="command">yes</strong></span>.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">check-mx-cname</strong></span></span></dt>
-<dd><p>
-                  If <span><strong class="command">check-integrity</strong></span> is set then
-                  fail, warn or ignore MX records that refer
-                  to CNAMES.  The default is to <span><strong class="command">warn</strong></span>.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">check-srv-cname</strong></span></span></dt>
-<dd><p>
-                  If <span><strong class="command">check-integrity</strong></span> is set then
-                  fail, warn or ignore SRV records that refer
-                  to CNAMES.  The default is to <span><strong class="command">warn</strong></span>.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">check-sibling</strong></span></span></dt>
-<dd><p>
-                  When performing integrity checks, also check that
-                  sibling glue exists.  The default is <span><strong class="command">yes</strong></span>.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">zero-no-soa-ttl</strong></span></span></dt>
-<dd><p>
-                  When returning authoritative negative responses to
-                  SOA queries set the TTL of the SOA recored returned in
-                  the authority section to zero.
-                  The default is <span><strong class="command">yes</strong></span>.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">zero-no-soa-ttl-cache</strong></span></span></dt>
-<dd><p>
-                  When caching a negative response to a SOA query
-                  set the TTL to zero.
-                  The default is <span><strong class="command">no</strong></span>.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">update-check-ksk</strong></span></span></dt>
-<dd><p>
-                  When regenerating the RRSIGs following a UPDATE
-                  request to a secure zone, check the KSK flag on
-                  the DNSKEY RR to determine if this key should be
-                  used to generate the RRSIG.  This flag is ignored
-                  if there are not DNSKEY RRs both with and without
-                  a KSK.
-                  The default is <span><strong class="command">yes</strong></span>.
-                </p></dd>
-</dl></div>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2580536"></a>Forwarding</h4></div></div></div>
-<p>
-            The forwarding facility can be used to create a large site-wide
-            cache on a few servers, reducing traffic over links to external
-            name servers. It can also be used to allow queries by servers that
-            do not have direct access to the Internet, but wish to look up
-            exterior
-            names anyway. Forwarding occurs only on those queries for which
-            the server is not authoritative and does not have the answer in
-            its cache.
-          </p>
-<div class="variablelist"><dl>
-<dt><span class="term"><span><strong class="command">forward</strong></span></span></dt>
-<dd><p>
-                  This option is only meaningful if the
-                  forwarders list is not empty. A value of <code class="varname">first</code>,
-                  the default, causes the server to query the forwarders
-                  first &#8212; and
-                  if that doesn't answer the question, the server will then
-                  look for
-                  the answer itself. If <code class="varname">only</code> is
-                  specified, the
-                  server will only query the forwarders.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">forwarders</strong></span></span></dt>
-<dd><p>
-                  Specifies the IP addresses to be used
-                  for forwarding. The default is the empty list (no
-                  forwarding).
-                </p></dd>
-</dl></div>
-<p>
-            Forwarding can also be configured on a per-domain basis, allowing
-            for the global forwarding options to be overridden in a variety
-            of ways. You can set particular domains to use different
-            forwarders,
-            or have a different <span><strong class="command">forward only/first</strong></span> behavior,
-            or not forward at all, see <a href="Bv9ARM.ch06.html#zone_statement_grammar" title="zone
-            Statement Grammar">the section called &#8220;<span><strong class="command">zone</strong></span>
-            Statement Grammar&#8221;</a>.
-          </p>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2580595"></a>Dual-stack Servers</h4></div></div></div>
-<p>
-            Dual-stack servers are used as servers of last resort to work
-            around
-            problems in reachability due the lack of support for either IPv4
-            or IPv6
-            on the host machine.
-          </p>
-<div class="variablelist"><dl>
-<dt><span class="term"><span><strong class="command">dual-stack-servers</strong></span></span></dt>
-<dd><p>
-                  Specifies host names or addresses of machines with access to
-                  both IPv4 and IPv6 transports. If a hostname is used, the
-                  server must be able
-                  to resolve the name using only the transport it has.  If the
-                  machine is dual
-                  stacked, then the <span><strong class="command">dual-stack-servers</strong></span> have no effect unless
-                  access to a transport has been disabled on the command line
-                  (e.g. <span><strong class="command">named -4</strong></span>).
-                </p></dd>
-</dl></div>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="access_control"></a>Access Control</h4></div></div></div>
-<p>
-            Access to the server can be restricted based on the IP address
-            of the requesting system. See <a href="Bv9ARM.ch06.html#address_match_lists" title="Address Match Lists">the section called &#8220;Address Match Lists&#8221;</a> for
-            details on how to specify IP address lists.
-          </p>
-<div class="variablelist"><dl>
-<dt><span class="term"><span><strong class="command">allow-notify</strong></span></span></dt>
-<dd><p>
-                  Specifies which hosts are allowed to
-                  notify this server, a slave, of zone changes in addition
-                  to the zone masters.
-                  <span><strong class="command">allow-notify</strong></span> may also be
-                  specified in the
-                  <span><strong class="command">zone</strong></span> statement, in which case
-                  it overrides the
-                  <span><strong class="command">options allow-notify</strong></span>
-                  statement.  It is only meaningful
-                  for a slave zone.  If not specified, the default is to
-                  process notify messages
-                  only from a zone's master.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">allow-query</strong></span></span></dt>
-<dd>
-<p>
-                  Specifies which hosts are allowed to ask ordinary
-                  DNS questions. <span><strong class="command">allow-query</strong></span> may
-                  also be specified in the <span><strong class="command">zone</strong></span>
-                  statement, in which case it overrides the
-                  <span><strong class="command">options allow-query</strong></span> statement.
-                  If not specified, the default is to allow queries
-                  from all hosts.
-                </p>
-<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-<p>
-                    <span><strong class="command">allow-query-cache</strong></span> is now
-                    used to specify access to the cache.
-                  </p>
-</div>
-</dd>
-<dt><span class="term"><span><strong class="command">allow-query-cache</strong></span></span></dt>
-<dd><p>
-                  Specifies which hosts are allowed to get answers
-                  from the cache.  If <span><strong class="command">allow-query-cache</strong></span>
-                  is not set then <span><strong class="command">allow-recursion</strong></span>
-                  is used if set, otherwise <span><strong class="command">allow-query</strong></span>
-                  is used if set, otherwise the default
-                  (<span><strong class="command">localnets;</strong></span>
-                  <span><strong class="command">localhost;</strong></span>) is used.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">allow-recursion</strong></span></span></dt>
-<dd><p>
-                  Specifies which hosts are allowed to make recursive
-                  queries through this server. If
-                  <span><strong class="command">allow-recursion</strong></span> is not set
-                  then <span><strong class="command">allow-query-cache</strong></span> is
-                  used if set, otherwise <span><strong class="command">allow-query</strong></span>
-                  is used if set, otherwise the default
-                  (<span><strong class="command">localnets;</strong></span>
-                  <span><strong class="command">localhost;</strong></span>) is used.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">allow-update</strong></span></span></dt>
-<dd><p>
-                  Specifies which hosts are allowed to
-                  submit Dynamic DNS updates for master zones. The default is
-                  to deny
-                  updates from all hosts.  Note that allowing updates based
-                  on the requestor's IP address is insecure; see
-                  <a href="Bv9ARM.ch07.html#dynamic_update_security" title="Dynamic Update Security">the section called &#8220;Dynamic Update Security&#8221;</a> for details.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">allow-update-forwarding</strong></span></span></dt>
-<dd>
-<p>
-                  Specifies which hosts are allowed to
-                  submit Dynamic DNS updates to slave zones to be forwarded to
-                  the
-                  master.  The default is <strong class="userinput"><code>{ none; }</code></strong>,
-                  which
-                  means that no update forwarding will be performed.  To
-                  enable
-                  update forwarding, specify
-                  <strong class="userinput"><code>allow-update-forwarding { any; };</code></strong>.
-                  Specifying values other than <strong class="userinput"><code>{ none; }</code></strong> or
-                  <strong class="userinput"><code>{ any; }</code></strong> is usually
-                  counterproductive, since
-                  the responsibility for update access control should rest
-                  with the
-                  master server, not the slaves.
-                </p>
-<p>
-                  Note that enabling the update forwarding feature on a slave
-                  server
-                  may expose master servers relying on insecure IP address
-                  based
-                  access control to attacks; see <a href="Bv9ARM.ch07.html#dynamic_update_security" title="Dynamic Update Security">the section called &#8220;Dynamic Update Security&#8221;</a>
-                  for more details.
-                </p>
-</dd>
-<dt><span class="term"><span><strong class="command">allow-v6-synthesis</strong></span></span></dt>
-<dd><p>
-                  This option was introduced for the smooth transition from
-                  AAAA
-                  to A6 and from "nibble labels" to binary labels.
-                  However, since both A6 and binary labels were then
-                  deprecated,
-                  this option was also deprecated.
-                  It is now ignored with some warning messages.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">allow-transfer</strong></span></span></dt>
-<dd><p>
-                  Specifies which hosts are allowed to
-                  receive zone transfers from the server. <span><strong class="command">allow-transfer</strong></span> may
-                  also be specified in the <span><strong class="command">zone</strong></span>
-                  statement, in which
-                  case it overrides the <span><strong class="command">options allow-transfer</strong></span> statement.
-                  If not specified, the default is to allow transfers to all
-                  hosts.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">blackhole</strong></span></span></dt>
-<dd><p>
-                  Specifies a list of addresses that the
-                  server will not accept queries from or use to resolve a
-                  query. Queries
-                  from these addresses will not be responded to. The default
-                  is <strong class="userinput"><code>none</code></strong>.
-                </p></dd>
-</dl></div>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2581153"></a>Interfaces</h4></div></div></div>
-<p>
-            The interfaces and ports that the server will answer queries
-            from may be specified using the <span><strong class="command">listen-on</strong></span> option. <span><strong class="command">listen-on</strong></span> takes
-            an optional port, and an <code class="varname">address_match_list</code>.
-            The server will listen on all interfaces allowed by the address
-            match list. If a port is not specified, port 53 will be used.
-          </p>
-<p>
-            Multiple <span><strong class="command">listen-on</strong></span> statements are
-            allowed.
-            For example,
-          </p>
-<pre class="programlisting">listen-on { 5.6.7.8; };
-listen-on port 1234 { !1.2.3.4; 1.2/16; };
-</pre>
-<p>
-            will enable the name server on port 53 for the IP address
-            5.6.7.8, and on port 1234 of an address on the machine in net
-            1.2 that is not 1.2.3.4.
-          </p>
-<p>
-            If no <span><strong class="command">listen-on</strong></span> is specified, the
-            server will listen on port 53 on all interfaces.
-          </p>
-<p>
-            The <span><strong class="command">listen-on-v6</strong></span> option is used to
-            specify the interfaces and the ports on which the server will
-            listen
-            for incoming queries sent using IPv6.
-          </p>
-<p>
-            When </p>
-<pre class="programlisting">{ any; }</pre>
-<p> is
-            specified
-            as the <code class="varname">address_match_list</code> for the
-            <span><strong class="command">listen-on-v6</strong></span> option,
-            the server does not bind a separate socket to each IPv6 interface
-            address as it does for IPv4 if the operating system has enough API
-            support for IPv6 (specifically if it conforms to RFC 3493 and RFC
-            3542).
-            Instead, it listens on the IPv6 wildcard address.
-            If the system only has incomplete API support for IPv6, however,
-            the behavior is the same as that for IPv4.
-          </p>
-<p>
-            A list of particular IPv6 addresses can also be specified, in
-            which case
-            the server listens on a separate socket for each specified
-            address,
-            regardless of whether the desired API is supported by the system.
-          </p>
-<p>
-            Multiple <span><strong class="command">listen-on-v6</strong></span> options can
-            be used.
-            For example,
-          </p>
-<pre class="programlisting">listen-on-v6 { any; };
-listen-on-v6 port 1234 { !2001:db8::/32; any; };
-</pre>
-<p>
-            will enable the name server on port 53 for any IPv6 addresses
-            (with a single wildcard socket),
-            and on port 1234 of IPv6 addresses that is not in the prefix
-            2001:db8::/32 (with separate sockets for each matched address.)
-          </p>
-<p>
-            To make the server not listen on any IPv6 address, use
-          </p>
-<pre class="programlisting">listen-on-v6 { none; };
-</pre>
-<p>
-            If no <span><strong class="command">listen-on-v6</strong></span> option is
-            specified,
-            the server will not listen on any IPv6 address.
-          </p>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2581241"></a>Query Address</h4></div></div></div>
-<p>
-            If the server doesn't know the answer to a question, it will
-            query other name servers. <span><strong class="command">query-source</strong></span> specifies
-            the address and port used for such queries. For queries sent over
-            IPv6, there is a separate <span><strong class="command">query-source-v6</strong></span> option.
-            If <span><strong class="command">address</strong></span> is <span><strong class="command">*</strong></span> (asterisk) or is omitted,
-            a wildcard IP address (<span><strong class="command">INADDR_ANY</strong></span>)
-            will be used.
-            If <span><strong class="command">port</strong></span> is <span><strong class="command">*</strong></span> or is omitted,
-            a random unprivileged port will be used. The <span><strong class="command">avoid-v4-udp-ports</strong></span>
-            and <span><strong class="command">avoid-v6-udp-ports</strong></span> options can be used
-            to prevent named
-            from selecting certain ports. The defaults are:
-          </p>
-<pre class="programlisting">query-source address * port *;
-query-source-v6 address * port *;
-</pre>
-<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-<p>
-              The address specified in the <span><strong class="command">query-source</strong></span> option
-              is used for both UDP and TCP queries, but the port applies only
-              to
-              UDP queries.  TCP queries always use a random
-              unprivileged port.
-            </p>
-</div>
-<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-<p>
-              Solaris 2.5.1 and earlier does not support setting the source
-              address for TCP sockets.
-            </p>
-</div>
-<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-<p>
-              See also <span><strong class="command">transfer-source</strong></span> and
-              <span><strong class="command">notify-source</strong></span>.
-            </p>
-</div>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="zone_transfers"></a>Zone Transfers</h4></div></div></div>
-<p>
-            <acronym class="acronym">BIND</acronym> has mechanisms in place to
-            facilitate zone transfers
-            and set limits on the amount of load that transfers place on the
-            system. The following options apply to zone transfers.
-          </p>
-<div class="variablelist"><dl>
-<dt><span class="term"><span><strong class="command">also-notify</strong></span></span></dt>
-<dd><p>
-                  Defines a global list of IP addresses of name servers
-                  that are also sent NOTIFY messages whenever a fresh copy of
-                  the
-                  zone is loaded, in addition to the servers listed in the
-                  zone's NS records.
-                  This helps to ensure that copies of the zones will
-                  quickly converge on stealth servers. If an <span><strong class="command">also-notify</strong></span> list
-                  is given in a <span><strong class="command">zone</strong></span> statement,
-                  it will override
-                  the <span><strong class="command">options also-notify</strong></span>
-                  statement. When a <span><strong class="command">zone notify</strong></span>
-                  statement
-                  is set to <span><strong class="command">no</strong></span>, the IP
-                  addresses in the global <span><strong class="command">also-notify</strong></span> list will
-                  not be sent NOTIFY messages for that zone. The default is
-                  the empty
-                  list (no global notification list).
-                </p></dd>
-<dt><span class="term"><span><strong class="command">max-transfer-time-in</strong></span></span></dt>
-<dd><p>
-                  Inbound zone transfers running longer than
-                  this many minutes will be terminated. The default is 120
-                  minutes
-                  (2 hours).  The maximum value is 28 days (40320 minutes).
-                </p></dd>
-<dt><span class="term"><span><strong class="command">max-transfer-idle-in</strong></span></span></dt>
-<dd><p>
-                  Inbound zone transfers making no progress
-                  in this many minutes will be terminated. The default is 60
-                  minutes
-                  (1 hour).  The maximum value is 28 days (40320 minutes).
-                </p></dd>
-<dt><span class="term"><span><strong class="command">max-transfer-time-out</strong></span></span></dt>
-<dd><p>
-                  Outbound zone transfers running longer than
-                  this many minutes will be terminated. The default is 120
-                  minutes
-                  (2 hours).  The maximum value is 28 days (40320 minutes).
-                </p></dd>
-<dt><span class="term"><span><strong class="command">max-transfer-idle-out</strong></span></span></dt>
-<dd><p>
-                  Outbound zone transfers making no progress
-                  in this many minutes will be terminated.  The default is 60
-                  minutes (1
-                  hour).  The maximum value is 28 days (40320 minutes).
-                </p></dd>
-<dt><span class="term"><span><strong class="command">serial-query-rate</strong></span></span></dt>
-<dd><p>
-                  Slave servers will periodically query master servers
-                  to find out if zone serial numbers have changed. Each such
-                  query uses
-                  a minute amount of the slave server's network bandwidth.  To
-                  limit the
-                  amount of bandwidth used, BIND 9 limits the rate at which
-                  queries are
-                  sent.  The value of the <span><strong class="command">serial-query-rate</strong></span> option,
-                  an integer, is the maximum number of queries sent per
-                  second.
-                  The default is 20.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">serial-queries</strong></span></span></dt>
-<dd><p>
-                  In BIND 8, the <span><strong class="command">serial-queries</strong></span>
-                  option
-                  set the maximum number of concurrent serial number queries
-                  allowed to be outstanding at any given time.
-                  BIND 9 does not limit the number of outstanding
-                  serial queries and ignores the <span><strong class="command">serial-queries</strong></span> option.
-                  Instead, it limits the rate at which the queries are sent
-                  as defined using the <span><strong class="command">serial-query-rate</strong></span> option.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">transfer-format</strong></span></span></dt>
-<dd><p>
-                  Zone transfers can be sent using two different formats,
-                  <span><strong class="command">one-answer</strong></span> and
-                  <span><strong class="command">many-answers</strong></span>.
-                  The <span><strong class="command">transfer-format</strong></span> option is used
-                  on the master server to determine which format it sends.
-                  <span><strong class="command">one-answer</strong></span> uses one DNS message per
-                  resource record transferred.
-                  <span><strong class="command">many-answers</strong></span> packs as many resource
-                  records as possible into a message.
-                  <span><strong class="command">many-answers</strong></span> is more efficient, but is
-                  only supported by relatively new slave servers,
-                  such as <acronym class="acronym">BIND</acronym> 9, <acronym class="acronym">BIND</acronym>
-                  8.x and <acronym class="acronym">BIND</acronym> 4.9.5 onwards.
-                  The <span><strong class="command">many-answers</strong></span> format is also supported by
-                  recent Microsoft Windows nameservers.
-                  The default is <span><strong class="command">many-answers</strong></span>.
-                  <span><strong class="command">transfer-format</strong></span> may be overridden on a
-                  per-server basis by using the <span><strong class="command">server</strong></span>
-                  statement.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">transfers-in</strong></span></span></dt>
-<dd><p>
-                  The maximum number of inbound zone transfers
-                  that can be running concurrently. The default value is <code class="literal">10</code>.
-                  Increasing <span><strong class="command">transfers-in</strong></span> may
-                  speed up the convergence
-                  of slave zones, but it also may increase the load on the
-                  local system.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">transfers-out</strong></span></span></dt>
-<dd><p>
-                  The maximum number of outbound zone transfers
-                  that can be running concurrently. Zone transfer requests in
-                  excess
-                  of the limit will be refused. The default value is <code class="literal">10</code>.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">transfers-per-ns</strong></span></span></dt>
-<dd><p>
-                  The maximum number of inbound zone transfers
-                  that can be concurrently transferring from a given remote
-                  name server.
-                  The default value is <code class="literal">2</code>.
-                  Increasing <span><strong class="command">transfers-per-ns</strong></span>
-                  may
-                  speed up the convergence of slave zones, but it also may
-                  increase
-                  the load on the remote name server. <span><strong class="command">transfers-per-ns</strong></span> may
-                  be overridden on a per-server basis by using the <span><strong class="command">transfers</strong></span> phrase
-                  of the <span><strong class="command">server</strong></span> statement.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">transfer-source</strong></span></span></dt>
-<dd>
-<p><span><strong class="command">transfer-source</strong></span>
-                  determines which local address will be bound to IPv4
-                  TCP connections used to fetch zones transferred
-                  inbound by the server.  It also determines the
-                  source IPv4 address, and optionally the UDP port,
-                  used for the refresh queries and forwarded dynamic
-                  updates.  If not set, it defaults to a system
-                  controlled value which will usually be the address
-                  of the interface "closest to" the remote end. This
-                  address must appear in the remote end's
-                  <span><strong class="command">allow-transfer</strong></span> option for the
-                  zone being transferred, if one is specified. This
-                  statement sets the
-                  <span><strong class="command">transfer-source</strong></span> for all zones,
-                  but can be overridden on a per-view or per-zone
-                  basis by including a
-                  <span><strong class="command">transfer-source</strong></span> statement within
-                  the <span><strong class="command">view</strong></span> or
-                  <span><strong class="command">zone</strong></span> block in the configuration
-                  file.
-                </p>
-<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-<p>
-                    Solaris 2.5.1 and earlier does not support setting the
-                    source address for TCP sockets.
-                  </p>
-</div>
-</dd>
-<dt><span class="term"><span><strong class="command">transfer-source-v6</strong></span></span></dt>
-<dd><p>
-                  The same as <span><strong class="command">transfer-source</strong></span>,
-                  except zone transfers are performed using IPv6.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">alt-transfer-source</strong></span></span></dt>
-<dd>
-<p>
-                  An alternate transfer source if the one listed in
-                  <span><strong class="command">transfer-source</strong></span> fails and
-                  <span><strong class="command">use-alt-transfer-source</strong></span> is
-                  set.
-                </p>
-<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-                  If you do not wish the alternate transfer source
-                  to be used, you should set
-                  <span><strong class="command">use-alt-transfer-source</strong></span>
-                  appropriately and you should not depend upon
-                  getting a answer back to the first refresh
-                  query.
-                </div>
-</dd>
-<dt><span class="term"><span><strong class="command">alt-transfer-source-v6</strong></span></span></dt>
-<dd><p>
-                  An alternate transfer source if the one listed in
-                  <span><strong class="command">transfer-source-v6</strong></span> fails and
-                  <span><strong class="command">use-alt-transfer-source</strong></span> is
-                  set.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">use-alt-transfer-source</strong></span></span></dt>
-<dd><p>
-                  Use the alternate transfer sources or not.  If views are
-                  specified this defaults to <span><strong class="command">no</strong></span>
-                  otherwise it defaults to
-                  <span><strong class="command">yes</strong></span> (for BIND 8
-                  compatibility).
-                </p></dd>
-<dt><span class="term"><span><strong class="command">notify-source</strong></span></span></dt>
-<dd>
-<p><span><strong class="command">notify-source</strong></span>
-                  determines which local source address, and
-                  optionally UDP port, will be used to send NOTIFY
-                  messages.  This address must appear in the slave
-                  server's <span><strong class="command">masters</strong></span> zone clause or
-                  in an <span><strong class="command">allow-notify</strong></span> clause.  This
-                  statement sets the <span><strong class="command">notify-source</strong></span>
-                  for all zones, but can be overridden on a per-zone or
-                  per-view basis by including a
-                  <span><strong class="command">notify-source</strong></span> statement within
-                  the <span><strong class="command">zone</strong></span> or
-                  <span><strong class="command">view</strong></span> block in the configuration
-                  file.
-                </p>
-<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-<p>
-                    Solaris 2.5.1 and earlier does not support setting the
-                    source address for TCP sockets.
-                  </p>
-</div>
-</dd>
-<dt><span class="term"><span><strong class="command">notify-source-v6</strong></span></span></dt>
-<dd><p>
-                  Like <span><strong class="command">notify-source</strong></span>,
-                  but applies to notify messages sent to IPv6 addresses.
-                </p></dd>
-</dl></div>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2581988"></a>Bad UDP Port Lists</h4></div></div></div>
-<p><span><strong class="command">avoid-v4-udp-ports</strong></span>
-            and <span><strong class="command">avoid-v6-udp-ports</strong></span> specify a list
-            of IPv4 and IPv6 UDP ports that will not be used as system
-            assigned source ports for UDP sockets.  These lists
-            prevent named from choosing as its random source port a
-            port that is blocked by your firewall.  If a query went
-            out with such a source port, the answer would not get by
-            the firewall and the name server would have to query
-            again.
-          </p>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2582003"></a>Operating System Resource Limits</h4></div></div></div>
-<p>
-            The server's usage of many system resources can be limited.
-            Scaled values are allowed when specifying resource limits.  For
-            example, <span><strong class="command">1G</strong></span> can be used instead of
-            <span><strong class="command">1073741824</strong></span> to specify a limit of
-            one
-            gigabyte. <span><strong class="command">unlimited</strong></span> requests
-            unlimited use, or the
-            maximum available amount. <span><strong class="command">default</strong></span>
-            uses the limit
-            that was in force when the server was started. See the description
-            of <span><strong class="command">size_spec</strong></span> in <a href="Bv9ARM.ch06.html#configuration_file_elements" title="Configuration File Elements">the section called &#8220;Configuration File Elements&#8221;</a>.
-          </p>
-<p>
-            The following options set operating system resource limits for
-            the name server process.  Some operating systems don't support
-            some or
-            any of the limits. On such systems, a warning will be issued if
-            the
-            unsupported limit is used.
-          </p>
-<div class="variablelist"><dl>
-<dt><span class="term"><span><strong class="command">coresize</strong></span></span></dt>
-<dd><p>
-                  The maximum size of a core dump. The default
-                  is <code class="literal">default</code>.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">datasize</strong></span></span></dt>
-<dd><p>
-                  The maximum amount of data memory the server
-                  may use. The default is <code class="literal">default</code>.
-                  This is a hard limit on server memory usage.
-                  If the server attempts to allocate memory in excess of this
-                  limit, the allocation will fail, which may in turn leave
-                  the server unable to perform DNS service.  Therefore,
-                  this option is rarely useful as a way of limiting the
-                  amount of memory used by the server, but it can be used
-                  to raise an operating system data size limit that is
-                  too small by default.  If you wish to limit the amount
-                  of memory used by the server, use the
-                  <span><strong class="command">max-cache-size</strong></span> and
-                  <span><strong class="command">recursive-clients</strong></span>
-                  options instead.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">files</strong></span></span></dt>
-<dd><p>
-                  The maximum number of files the server
-                  may have open concurrently. The default is <code class="literal">unlimited</code>.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">stacksize</strong></span></span></dt>
-<dd><p>
-                  The maximum amount of stack memory the server
-                  may use. The default is <code class="literal">default</code>.
-                </p></dd>
-</dl></div>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2582186"></a>Server  Resource Limits</h4></div></div></div>
-<p>
-            The following options set limits on the server's
-            resource consumption that are enforced internally by the
-            server rather than the operating system.
-          </p>
-<div class="variablelist"><dl>
-<dt><span class="term"><span><strong class="command">max-ixfr-log-size</strong></span></span></dt>
-<dd><p>
-                  This option is obsolete; it is accepted
-                  and ignored for BIND 8 compatibility.  The option
-                  <span><strong class="command">max-journal-size</strong></span> performs a
-                  similar function in BIND 9.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">max-journal-size</strong></span></span></dt>
-<dd><p>
-                  Sets a maximum size for each journal file
-                  (see <a href="Bv9ARM.ch04.html#journal" title="The journal file">the section called &#8220;The journal file&#8221;</a>).  When the journal file
-                  approaches
-                  the specified size, some of the oldest transactions in the
-                  journal
-                  will be automatically removed.  The default is
-                  <code class="literal">unlimited</code>.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">host-statistics-max</strong></span></span></dt>
-<dd><p>
-                  In BIND 8, specifies the maximum number of host statistics
-                  entries to be kept.
-                  Not implemented in BIND 9.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">recursive-clients</strong></span></span></dt>
-<dd><p>
-                  The maximum number of simultaneous recursive lookups
-                  the server will perform on behalf of clients.  The default
-                  is
-                  <code class="literal">1000</code>.  Because each recursing
-                  client uses a fair
-                  bit of memory, on the order of 20 kilobytes, the value of
-                  the
-                  <span><strong class="command">recursive-clients</strong></span> option may
-                  have to be decreased
-                  on hosts with limited memory.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">tcp-clients</strong></span></span></dt>
-<dd><p>
-                  The maximum number of simultaneous client TCP
-                  connections that the server will accept.
-                  The default is <code class="literal">100</code>.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">max-cache-size</strong></span></span></dt>
-<dd><p>
-                  The maximum amount of memory to use for the
-                  server's cache, in bytes.  When the amount of data in the
-                  cache
-                  reaches this limit, the server will cause records to expire
-                  prematurely so that the limit is not exceeded.  In a server
-                  with
-                  multiple views, the limit applies separately to the cache of
-                  each
-                  view.  The default is <code class="literal">unlimited</code>, meaning that
-                  records are purged from the cache only when their TTLs
-                  expire.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">tcp-listen-queue</strong></span></span></dt>
-<dd><p>
-                  The listen queue depth.  The default and minimum is 3.
-                  If the kernel supports the accept filter "dataready" this
-                  also controls how
-                  many TCP connections that will be queued in kernel space
-                  waiting for
-                  some data before being passed to accept.  Values less than 3
-                  will be
-                  silently raised.
-                </p></dd>
-</dl></div>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2582320"></a>Periodic Task Intervals</h4></div></div></div>
-<div class="variablelist"><dl>
-<dt><span class="term"><span><strong class="command">cleaning-interval</strong></span></span></dt>
-<dd><p>
-                  The server will remove expired resource records
-                  from the cache every <span><strong class="command">cleaning-interval</strong></span> minutes.
-                  The default is 60 minutes.  The maximum value is 28 days
-                  (40320 minutes).
-                  If set to 0, no periodic cleaning will occur.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">heartbeat-interval</strong></span></span></dt>
-<dd><p>
-                  The server will perform zone maintenance tasks
-                  for all zones marked as <span><strong class="command">dialup</strong></span> whenever this
-                  interval expires. The default is 60 minutes. Reasonable
-                  values are up
-                  to 1 day (1440 minutes).  The maximum value is 28 days
-                  (40320 minutes).
-                  If set to 0, no zone maintenance for these zones will occur.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">interface-interval</strong></span></span></dt>
-<dd><p>
-                  The server will scan the network interface list
-                  every <span><strong class="command">interface-interval</strong></span>
-                  minutes. The default
-                  is 60 minutes. The maximum value is 28 days (40320 minutes).
-                  If set to 0, interface scanning will only occur when
-                  the configuration file is  loaded. After the scan, the
-                  server will
-                  begin listening for queries on any newly discovered
-                  interfaces (provided they are allowed by the
-                  <span><strong class="command">listen-on</strong></span> configuration), and
-                  will
-                  stop listening on interfaces that have gone away.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">statistics-interval</strong></span></span></dt>
-<dd>
-<p>
-                  Name server statistics will be logged
-                  every <span><strong class="command">statistics-interval</strong></span>
-                  minutes. The default is
-                  60. The maximum value is 28 days (40320 minutes).
-                  If set to 0, no statistics will be logged.
-                  </p>
-<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-<p>
-                    Not yet implemented in
-                    <acronym class="acronym">BIND</acronym> 9.
-                  </p>
-</div>
-</dd>
-</dl></div>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="topology"></a>Topology</h4></div></div></div>
-<p>
-            All other things being equal, when the server chooses a name
-            server
-            to query from a list of name servers, it prefers the one that is
-            topologically closest to itself. The <span><strong class="command">topology</strong></span> statement
-            takes an <span><strong class="command">address_match_list</strong></span> and
-            interprets it
-            in a special way. Each top-level list element is assigned a
-            distance.
-            Non-negated elements get a distance based on their position in the
-            list, where the closer the match is to the start of the list, the
-            shorter the distance is between it and the server. A negated match
-            will be assigned the maximum distance from the server. If there
-            is no match, the address will get a distance which is further than
-            any non-negated list element, and closer than any negated element.
-            For example,
-          </p>
-<pre class="programlisting">topology {
-    10/8;
-    !1.2.3/24;
-    { 1.2/16; 3/8; };
-};</pre>
-<p>
-            will prefer servers on network 10 the most, followed by hosts
-            on network 1.2.0.0 (netmask 255.255.0.0) and network 3, with the
-            exception of hosts on network 1.2.3 (netmask 255.255.255.0), which
-            is preferred least of all.
-          </p>
-<p>
-            The default topology is
-          </p>
-<pre class="programlisting">    topology { localhost; localnets; };
-</pre>
-<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-<p>
-              The <span><strong class="command">topology</strong></span> option
-              is not implemented in <acronym class="acronym">BIND</acronym> 9.
-            </p>
-</div>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="the_sortlist_statement"></a>The <span><strong class="command">sortlist</strong></span> Statement</h4></div></div></div>
-<p>
-            The response to a DNS query may consist of multiple resource
-            records (RRs) forming a resource records set (RRset).
-            The name server will normally return the
-            RRs within the RRset in an indeterminate order
-            (but see the <span><strong class="command">rrset-order</strong></span>
-            statement in <a href="Bv9ARM.ch06.html#rrset_ordering" title="RRset Ordering">the section called &#8220;RRset Ordering&#8221;</a>).
-            The client resolver code should rearrange the RRs as appropriate,
-            that is, using any addresses on the local net in preference to
-            other addresses.
-            However, not all resolvers can do this or are correctly
-            configured.
-            When a client is using a local server, the sorting can be performed
-            in the server, based on the client's address. This only requires
-            configuring the name servers, not all the clients.
-          </p>
-<p>
-            The <span><strong class="command">sortlist</strong></span> statement (see below)
-            takes
-            an <span><strong class="command">address_match_list</strong></span> and
-            interprets it even
-            more specifically than the <span><strong class="command">topology</strong></span>
-            statement
-            does (<a href="Bv9ARM.ch06.html#topology" title="Topology">the section called &#8220;Topology&#8221;</a>).
-            Each top level statement in the <span><strong class="command">sortlist</strong></span> must
-            itself be an explicit <span><strong class="command">address_match_list</strong></span> with
-            one or two elements. The first element (which may be an IP
-            address,
-            an IP prefix, an ACL name or a nested <span><strong class="command">address_match_list</strong></span>)
-            of each top level list is checked against the source address of
-            the query until a match is found.
-          </p>
-<p>
-            Once the source address of the query has been matched, if
-            the top level statement contains only one element, the actual
-            primitive
-            element that matched the source address is used to select the
-            address
-            in the response to move to the beginning of the response. If the
-            statement is a list of two elements, then the second element is
-            treated the same as the <span><strong class="command">address_match_list</strong></span> in
-            a <span><strong class="command">topology</strong></span> statement. Each top
-            level element
-            is assigned a distance and the address in the response with the
-            minimum
-            distance is moved to the beginning of the response.
-          </p>
-<p>
-            In the following example, any queries received from any of
-            the addresses of the host itself will get responses preferring
-            addresses
-            on any of the locally connected networks. Next most preferred are
-            addresses
-            on the 192.168.1/24 network, and after that either the
-            192.168.2/24
-            or
-            192.168.3/24 network with no preference shown between these two
-            networks. Queries received from a host on the 192.168.1/24 network
-            will prefer other addresses on that network to the 192.168.2/24
-            and
-            192.168.3/24 networks. Queries received from a host on the
-            192.168.4/24
-            or the 192.168.5/24 network will only prefer other addresses on
-            their directly connected networks.
-          </p>
-<pre class="programlisting">sortlist {
-    { localhost;                                   // IF   the local host
-        { localnets;                               // THEN first fit on the
-            192.168.1/24;                          //   following nets
-            { 192.168.2/24; 192.168.3/24; }; }; };
-    { 192.168.1/24;                                // IF   on class C 192.168.1
-        { 192.168.1/24;                            // THEN use .1, or .2 or .3
-            { 192.168.2/24; 192.168.3/24; }; }; };
-    { 192.168.2/24;                                // IF   on class C 192.168.2
-        { 192.168.2/24;                            // THEN use .2, or .1 or .3
-            { 192.168.1/24; 192.168.3/24; }; }; };
-    { 192.168.3/24;                                // IF   on class C 192.168.3
-        { 192.168.3/24;                            // THEN use .3, or .1 or .2
-            { 192.168.1/24; 192.168.2/24; }; }; };
-    { { 192.168.4/24; 192.168.5/24; };             // if .4 or .5, prefer that net
-    };
-};</pre>
-<p>
-            The following example will give reasonable behavior for the
-            local host and hosts on directly connected networks. It is similar
-            to the behavior of the address sort in <acronym class="acronym">BIND</acronym> 4.9.x. Responses sent
-            to queries from the local host will favor any of the directly
-            connected
-            networks. Responses sent to queries from any other hosts on a
-            directly
-            connected network will prefer addresses on that same network.
-            Responses
-            to other queries will not be sorted.
-          </p>
-<pre class="programlisting">sortlist {
-           { localhost; localnets; };
-           { localnets; };
-};
-</pre>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="rrset_ordering"></a>RRset Ordering</h4></div></div></div>
-<p>
-            When multiple records are returned in an answer it may be
-            useful to configure the order of the records placed into the
-            response.
-            The <span><strong class="command">rrset-order</strong></span> statement permits
-            configuration
-            of the ordering of the records in a multiple record response.
-            See also the <span><strong class="command">sortlist</strong></span> statement,
-            <a href="Bv9ARM.ch06.html#the_sortlist_statement" title="The sortlist Statement">the section called &#8220;The <span><strong class="command">sortlist</strong></span> Statement&#8221;</a>.
-          </p>
-<p>
-            An <span><strong class="command">order_spec</strong></span> is defined as
-            follows:
-          </p>
-<p>
-            [<span class="optional">class <em class="replaceable"><code>class_name</code></em></span>]
-            [<span class="optional">type <em class="replaceable"><code>type_name</code></em></span>]
-            [<span class="optional">name <em class="replaceable"><code>"domain_name"</code></em></span>]
-            order <em class="replaceable"><code>ordering</code></em>
-          </p>
-<p>
-            If no class is specified, the default is <span><strong class="command">ANY</strong></span>.
-            If no type is specified, the default is <span><strong class="command">ANY</strong></span>.
-            If no name is specified, the default is "<span><strong class="command">*</strong></span>" (asterisk).
-          </p>
-<p>
-            The legal values for <span><strong class="command">ordering</strong></span> are:
-          </p>
-<div class="informaltable"><table border="1">
-<colgroup>
-<col>
-<col>
-</colgroup>
-<tbody>
-<tr>
-<td>
-                    <p><span><strong class="command">fixed</strong></span></p>
-                  </td>
-<td>
-                    <p>
-                      Records are returned in the order they
-                      are defined in the zone file.
-                    </p>
-                  </td>
-</tr>
-<tr>
-<td>
-                    <p><span><strong class="command">random</strong></span></p>
-                  </td>
-<td>
-                    <p>
-                      Records are returned in some random order.
-                    </p>
-                  </td>
-</tr>
-<tr>
-<td>
-                    <p><span><strong class="command">cyclic</strong></span></p>
-                  </td>
-<td>
-                    <p>
-                      Records are returned in a round-robin
-                      order.
-                    </p>
-                  </td>
-</tr>
-</tbody>
-</table></div>
-<p>
-            For example:
-          </p>
-<pre class="programlisting">rrset-order {
-   class IN type A name "host.example.com" order random;
-   order cyclic;
-};
-</pre>
-<p>
-            will cause any responses for type A records in class IN that
-            have "<code class="literal">host.example.com</code>" as a
-            suffix, to always be returned
-            in random order. All other records are returned in cyclic order.
-          </p>
-<p>
-            If multiple <span><strong class="command">rrset-order</strong></span> statements
-            appear,
-            they are not combined &#8212; the last one applies.
-          </p>
-<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-<p>
-              The <span><strong class="command">rrset-order</strong></span> statement
-              is not yet fully implemented in <acronym class="acronym">BIND</acronym> 9.
-              BIND 9 currently does not fully support "fixed" ordering.
-            </p>
-</div>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="tuning"></a>Tuning</h4></div></div></div>
-<div class="variablelist"><dl>
-<dt><span class="term"><span><strong class="command">lame-ttl</strong></span></span></dt>
-<dd><p>
-                  Sets the number of seconds to cache a
-                  lame server indication. 0 disables caching. (This is
-                  <span class="bold"><strong>NOT</strong></span> recommended.)
-                  The default is <code class="literal">600</code> (10 minutes) and the
-                  maximum value is
-                  <code class="literal">1800</code> (30 minutes).
-                </p></dd>
-<dt><span class="term"><span><strong class="command">max-ncache-ttl</strong></span></span></dt>
-<dd><p>
-                  To reduce network traffic and increase performance,
-                  the server stores negative answers. <span><strong class="command">max-ncache-ttl</strong></span> is
-                  used to set a maximum retention time for these answers in
-                  the server
-                  in seconds. The default
-                  <span><strong class="command">max-ncache-ttl</strong></span> is <code class="literal">10800</code> seconds (3 hours).
-                  <span><strong class="command">max-ncache-ttl</strong></span> cannot exceed
-                  7 days and will
-                  be silently truncated to 7 days if set to a greater value.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">max-cache-ttl</strong></span></span></dt>
-<dd><p>
-                  Sets the maximum time for which the server will
-                  cache ordinary (positive) answers. The default is
-                  one week (7 days).
-                </p></dd>
-<dt><span class="term"><span><strong class="command">min-roots</strong></span></span></dt>
-<dd>
-<p>
-                  The minimum number of root servers that
-                  is required for a request for the root servers to be
-                  accepted. The default
-                  is <strong class="userinput"><code>2</code></strong>.
-                </p>
-<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-<p>
-                    Not implemented in <acronym class="acronym">BIND</acronym> 9.
-                  </p>
-</div>
-</dd>
-<dt><span class="term"><span><strong class="command">sig-validity-interval</strong></span></span></dt>
-<dd><p>
-                  Specifies the number of days into the
-                  future when DNSSEC signatures automatically generated as a
-                  result
-                  of dynamic updates (<a href="Bv9ARM.ch04.html#dynamic_update" title="Dynamic Update">the section called &#8220;Dynamic Update&#8221;</a>)
-                  will expire. The default is <code class="literal">30</code> days.
-                  The maximum value is 10 years (3660 days). The signature
-                  inception time is unconditionally set to one hour before the
-                  current time
-                  to allow for a limited amount of clock skew.
-                </p></dd>
-<dt>
-<span class="term"><span><strong class="command">min-refresh-time</strong></span>, </span><span class="term"><span><strong class="command">max-refresh-time</strong></span>, </span><span class="term"><span><strong class="command">min-retry-time</strong></span>, </span><span class="term"><span><strong class="command">max-retry-time</strong></span></span>
-</dt>
-<dd>
-<p>
-                  These options control the server's behavior on refreshing a
-                  zone
-                  (querying for SOA changes) or retrying failed transfers.
-                  Usually the SOA values for the zone are used, but these
-                  values
-                  are set by the master, giving slave server administrators
-                  little
-                  control over their contents.
-                </p>
-<p>
-                  These options allow the administrator to set a minimum and
-                  maximum
-                  refresh and retry time either per-zone, per-view, or
-                  globally.
-                  These options are valid for slave and stub zones,
-                  and clamp the SOA refresh and retry times to the specified
-                  values.
-                </p>
-</dd>
-<dt><span class="term"><span><strong class="command">edns-udp-size</strong></span></span></dt>
-<dd><p>
-                  Sets the advertised EDNS UDP buffer size in bytes.  Valid
-                  values are 512 to 4096 (values outside this range
-                  will be silently adjusted).  The default value is
-                  4096.  The usual reason for setting edns-udp-size to
-                  a non-default value is to get UDP answers to pass
-                  through broken firewalls that block fragmented
-                  packets and/or block UDP packets that are greater
-                  than 512 bytes.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">max-udp-size</strong></span></span></dt>
-<dd><p>
-                  Sets the maximum EDNS UDP message size named will
-                  send in bytes.  Valid values are 512 to 4096 (values outside
-                  this range will be silently adjusted).  The default
-                  value is 4096.  The usual reason for setting
-                  max-udp-size to a non-default value is to get UDP
-                  answers to pass through broken firewalls that
-                  block fragmented packets and/or block UDP packets
-                  that are greater than 512 bytes.
-                  This is independent of the advertised receive
-                  buffer (<span><strong class="command">edns-udp-size</strong></span>).
-                </p></dd>
-<dt><span class="term"><span><strong class="command">masterfile-format</strong></span></span></dt>
-<dd><p>Specifies
-                  the file format of zone files (see
-                  <a href="Bv9ARM.ch06.html#zonefile_format" title="Additional File Formats">the section called &#8220;Additional File Formats&#8221;</a>).
-                  The default value is <code class="constant">text</code>, which is the
-                  standard textual representation.  Files in other formats
-                  than <code class="constant">text</code> are typically expected
-                  to be generated by the <span><strong class="command">named-compilezone</strong></span> tool.
-                  Note that when a zone file in a different format than
-                  <code class="constant">text</code> is loaded, <span><strong class="command">named</strong></span>
-                  may omit some of the checks which would be performed for a
-                  file in the <code class="constant">text</code> format.  In particular,
-                  <span><strong class="command">check-names</strong></span> checks do not apply
-                  for the <code class="constant">raw</code> format.  This means
-                  a zone file in the <code class="constant">raw</code> format
-                  must be generated with the same check level as that
-                  specified in the <span><strong class="command">named</strong></span> configuration
-                  file.  This statement sets the
-                  <span><strong class="command">masterfile-format</strong></span> for all zones,
-                  but can be overridden on a per-zone or per-view basis
-                  by including a <span><strong class="command">masterfile-format</strong></span>
-                  statement within the <span><strong class="command">zone</strong></span> or
-                  <span><strong class="command">view</strong></span> block in the configuration
-                  file.
-                </p></dd>
-<dt>
-<span class="term"><span><strong class="command">clients-per-query</strong></span>, </span><span class="term"><span><strong class="command">max-clients-per-query</strong></span></span>
-</dt>
-<dd>
-<p>These set the
-                  initial value (minimum) and maximum number of recursive
-                  simultanious clients for any given query
-                  (&lt;qname,qtype,qclass&gt;) that the server will accept
-                  before dropping additional clients.  named will attempt to
-                  self tune this value and changes will be logged.  The
-                  default values are 10 and 100.
-                </p>
-<p>
-                  This value should reflect how many queries come in for
-                  a given name in the time it takes to resolve that name.
-                  If the number of queries exceed this value, named will
-                  assume that it is dealing with a non-responsive zone
-                  and will drop additional queries.  If it gets a response
-                  after dropping queries, it will raise the estimate.  The
-                  estimate will then be lowered in 20 minutes if it has
-                  remained unchanged.
-                </p>
-<p>
-                  If <span><strong class="command">clients-per-query</strong></span> is set to zero,
-                  then there is no limit on the number of clients per query
-                  and no queries will be dropped.
-                </p>
-<p>
-                  If <span><strong class="command">max-clients-per-query</strong></span> is set to zero,
-                  then there is no upper bound other than imposed by
-                  <span><strong class="command">recursive-clients</strong></span>.
-                </p>
-</dd>
-<dt><span class="term"><span><strong class="command">notify-delay</strong></span></span></dt>
-<dd><p>
-                  The delay, in seconds, between sending sets of notify
-                  messages for a zone.  The default is zero.
-                </p></dd>
-</dl></div>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="builtin"></a>Built-in server information zones</h4></div></div></div>
-<p>
-            The server provides some helpful diagnostic information
-            through a number of built-in zones under the
-            pseudo-top-level-domain <code class="literal">bind</code> in the
-            <span><strong class="command">CHAOS</strong></span> class.  These zones are part
-            of a
-            built-in view (see <a href="Bv9ARM.ch06.html#view_statement_grammar" title="view Statement Grammar">the section called &#8220;<span><strong class="command">view</strong></span> Statement Grammar&#8221;</a>) of
-            class
-            <span><strong class="command">CHAOS</strong></span> which is separate from the
-            default view of
-            class <span><strong class="command">IN</strong></span>; therefore, any global
-            server options
-            such as <span><strong class="command">allow-query</strong></span> do not apply
-            the these zones.
-            If you feel the need to disable these zones, use the options
-            below, or hide the built-in <span><strong class="command">CHAOS</strong></span>
-            view by
-            defining an explicit view of class <span><strong class="command">CHAOS</strong></span>
-            that matches all clients.
-          </p>
-<div class="variablelist"><dl>
-<dt><span class="term"><span><strong class="command">version</strong></span></span></dt>
-<dd><p>
-                  The version the server should report
-                  via a query of the name <code class="literal">version.bind</code>
-                  with type <span><strong class="command">TXT</strong></span>, class <span><strong class="command">CHAOS</strong></span>.
-                  The default is the real version number of this server.
-                  Specifying <span><strong class="command">version none</strong></span>
-                  disables processing of the queries.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">hostname</strong></span></span></dt>
-<dd><p>
-                  The hostname the server should report via a query of
-                  the name <code class="filename">hostname.bind</code>
-                  with type <span><strong class="command">TXT</strong></span>, class <span><strong class="command">CHAOS</strong></span>.
-                  This defaults to the hostname of the machine hosting the
-                  name server as
-                  found by the gethostname() function.  The primary purpose of such queries
-                  is to
-                  identify which of a group of anycast servers is actually
-                  answering your queries.  Specifying <span><strong class="command">hostname none;</strong></span>
-                  disables processing of the queries.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">server-id</strong></span></span></dt>
-<dd><p>
-                  The ID of the server should report via a query of
-                  the name <code class="filename">ID.SERVER</code>
-                  with type <span><strong class="command">TXT</strong></span>, class <span><strong class="command">CHAOS</strong></span>.
-                  The primary purpose of such queries is to
-                  identify which of a group of anycast servers is actually
-                  answering your queries.  Specifying <span><strong class="command">server-id none;</strong></span>
-                  disables processing of the queries.
-                  Specifying <span><strong class="command">server-id hostname;</strong></span> will cause named to
-                  use the hostname as found by the gethostname() function.
-                  The default <span><strong class="command">server-id</strong></span> is <span><strong class="command">none</strong></span>.
-                </p></dd>
-</dl></div>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="empty"></a>Built-in Empty Zones</h4></div></div></div>
-<p>
-            Named has some built-in empty zones (SOA and NS records only).
-            These are for zones that should normally be answered locally
-            and which queries should not be sent to the Internet's root
-            servers.  The official servers which cover these namespaces
-            return NXDOMAIN responses to these queries.  In particular,
-            these cover the reverse namespace for addresses from RFC 1918 and
-            RFC 3330.  They also include the reverse namespace for IPv6 local
-            address (locally assigned), IPv6 link local addresses, the IPv6
-            loopback address and the IPv6 unknown addresss.
-          </p>
-<p>
-            Named will attempt to determine if a built in zone already exists
-            or is active (covered by a forward-only forwarding declaration)
-            and will not not create a empty zone in that case.
-          </p>
-<p>
-            The current list of empty zones is:
-            </p>
-<div class="itemizedlist"><ul type="disc">
-<li>10.IN-ADDR.ARPA</li>
-<li>127.IN-ADDR.ARPA</li>
-<li>254.169.IN-ADDR.ARPA</li>
-<li>16.172.IN-ADDR.ARPA</li>
-<li>17.172.IN-ADDR.ARPA</li>
-<li>18.172.IN-ADDR.ARPA</li>
-<li>19.172.IN-ADDR.ARPA</li>
-<li>20.172.IN-ADDR.ARPA</li>
-<li>21.172.IN-ADDR.ARPA</li>
-<li>22.172.IN-ADDR.ARPA</li>
-<li>23.172.IN-ADDR.ARPA</li>
-<li>24.172.IN-ADDR.ARPA</li>
-<li>25.172.IN-ADDR.ARPA</li>
-<li>26.172.IN-ADDR.ARPA</li>
-<li>27.172.IN-ADDR.ARPA</li>
-<li>28.172.IN-ADDR.ARPA</li>
-<li>29.172.IN-ADDR.ARPA</li>
-<li>30.172.IN-ADDR.ARPA</li>
-<li>31.172.IN-ADDR.ARPA</li>
-<li>168.192.IN-ADDR.ARPA</li>
-<li>2.0.192.IN-ADDR.ARPA</li>
-<li>0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA</li>
-<li>1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA</li>
-<li>D.F.IP6.ARPA</li>
-<li>8.E.F.IP6.ARPA</li>
-<li>9.E.F.IP6.ARPA</li>
-<li>A.E.F.IP6.ARPA</li>
-<li>B.E.F.IP6.ARPA</li>
-</ul></div>
-<p>
-          </p>
-<p>
-            Empty zones are settable at the view level and only apply to
-            views of class IN.  Disabled empty zones are only inherited
-            from options if there are no disabled empty zones specified
-            at the view level.  To override the options list of disabled
-            zones, you can disable the root zone at the view level, for example:
-</p>
-<pre class="programlisting">
-            disable-empty-zone ".";
-</pre>
-<p>
-          </p>
-<p>
-            If you are using the address ranges covered here, you should
-            already have reverse zones covering the addresses you use.
-            In practice this appears to not be the case with many queries
-            being made to the infrastructure servers for names in these
-            spaces.  So many in fact that sacrificial servers were needed
-            to be deployed to channel the query load away from the
-            infrastructure servers.
-          </p>
-<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-            The real parent servers for these zones should disable all
-            empty zone under the parent zone they serve.  For the real
-            root servers, this is all built in empty zones.  This will
-            enable them to return referrals to deeper in the tree.
-          </div>
-<div class="variablelist"><dl>
-<dt><span class="term"><span><strong class="command">empty-server</strong></span></span></dt>
-<dd><p>
-                  Specify what server name will appear in the returned
-                  SOA record for empty zones.  If none is specified, then
-                  the zone's name will be used.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">empty-contact</strong></span></span></dt>
-<dd><p>
-                  Specify what contact name will appear in the returned
-                  SOA record for empty zones.  If none is specified, then
-                  "." will be used.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">empty-zones-enable</strong></span></span></dt>
-<dd><p>
-                  Enable or disable all empty zones.  By default they
-                  are enabled.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">disable-empty-zone</strong></span></span></dt>
-<dd><p>
-                  Disable individual empty zones.  By default none are
-                  disabled.  This option can be specified multiple times.
-                </p></dd>
-</dl></div>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="statsfile"></a>The Statistics File</h4></div></div></div>
-<p>
-            The statistics file generated by <acronym class="acronym">BIND</acronym> 9
-            is similar, but not identical, to that
-            generated by <acronym class="acronym">BIND</acronym> 8.
-          </p>
-<p>
-            The statistics dump begins with a line, like:
-          </p>
-<p>
-            <span><strong class="command">+++ Statistics Dump +++ (973798949)</strong></span>
-          </p>
-<p>
-            The number in parentheses is a standard
-            Unix-style timestamp, measured as seconds since January 1, 1970.
-            Following
-            that line are a series of lines containing a counter type, the
-            value of the
-            counter, optionally a zone name, and optionally a view name.
-            The lines without view and zone listed are global statistics for
-            the entire server.
-            Lines with a zone and view name for the given view and zone (the
-            view name is
-            omitted for the default view).
-          </p>
-<p>
-            The statistics dump ends with the line where the
-            number is identical to the number in the beginning line; for example:
-          </p>
-<p>
-            <span><strong class="command">--- Statistics Dump --- (973798949)</strong></span>
-          </p>
-<p>
-            The following statistics counters are maintained:
-          </p>
-<div class="informaltable"><table border="1">
-<colgroup>
-<col>
-<col>
-</colgroup>
-<tbody>
-<tr>
-<td>
-                    <p><span><strong class="command">success</strong></span></p>
-                  </td>
-<td>
-                    <p>
-                      The number of
-                      successful queries made to the server or zone.  A
-                      successful query
-                      is defined as query which returns a NOERROR response
-                      with at least
-                      one answer RR.
-                    </p>
-                  </td>
-</tr>
-<tr>
-<td>
-                    <p><span><strong class="command">referral</strong></span></p>
-                  </td>
-<td>
-                    <p>
-                      The number of queries which resulted
-                      in referral responses.
-                    </p>
-                  </td>
-</tr>
-<tr>
-<td>
-                    <p><span><strong class="command">nxrrset</strong></span></p>
-                  </td>
-<td>
-                    <p>
-                      The number of queries which resulted in
-                      NOERROR responses with no data.
-                    </p>
-                  </td>
-</tr>
-<tr>
-<td>
-                    <p><span><strong class="command">nxdomain</strong></span></p>
-                  </td>
-<td>
-                    <p>
-                      The number
-                      of queries which resulted in NXDOMAIN responses.
-                    </p>
-                  </td>
-</tr>
-<tr>
-<td>
-                    <p><span><strong class="command">failure</strong></span></p>
-                  </td>
-<td>
-                    <p>
-                      The number of queries which resulted in a
-                      failure response other than those above.
-                    </p>
-                  </td>
-</tr>
-<tr>
-<td>
-                    <p><span><strong class="command">recursion</strong></span></p>
-                  </td>
-<td>
-                    <p>
-                      The number of queries which caused the server
-                      to perform recursion in order to find the final answer.
-                    </p>
-                  </td>
-</tr>
-<tr>
-<td>
-                    <p><span><strong class="command">duplicate</strong></span></p>
-                  </td>
-<td>
-                    <p>
-                      The number of queries which the server attempted to
-                      recurse but discover a existing query with the same
-                      IP address, port, query id, name, type and class
-                      already being processed.
-                    </p>
-                  </td>
-</tr>
-<tr>
-<td>
-                    <p><span><strong class="command">dropped</strong></span></p>
-                  </td>
-<td>
-                    <p>
-                      The number of queries for which the server
-                      discovered a excessive number of existing
-                      recursive queries for the same name, type and
-                      class and were subsequently dropped.
-                    </p>
-                  </td>
-</tr>
-</tbody>
-</table></div>
-<p>
-            Each query received by the server will cause exactly one of
-            <span><strong class="command">success</strong></span>,
-            <span><strong class="command">referral</strong></span>,
-            <span><strong class="command">nxrrset</strong></span>,
-            <span><strong class="command">nxdomain</strong></span>, or
-            <span><strong class="command">failure</strong></span>
-            to be incremented, and may additionally cause the
-            <span><strong class="command">recursion</strong></span> counter to be
-            incremented.
-          </p>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="acache"></a>Additional Section Caching</h4></div></div></div>
-<p>
-            The additional section cache, also called <span><strong class="command">acache</strong></span>,
-            is an internal cache to improve the response performance of BIND 9.
-            When additional section caching is enabled, BIND 9 will
-            cache an internal short-cut to the additional section content for
-            each answer RR.
-            Note that <span><strong class="command">acache</strong></span> is an internal caching
-            mechanism of BIND 9, and is not related to the DNS caching
-            server function.
-          </p>
-<p>
-            Additional section caching does not change the
-            response content (except the RRsets ordering of the additional
-            section, see below), but can improve the response performance
-            significantly.
-            It is particularly effective when BIND 9 acts as an authoritative
-            server for a zone that has many delegations with many glue RRs.
-          </p>
-<p>
-            In order to obtain the maximum performance improvement
-            from additional section caching, setting
-            <span><strong class="command">additional-from-cache</strong></span>
-            to <span><strong class="command">no</strong></span> is recommended, since the current
-            implementation of <span><strong class="command">acache</strong></span>
-            does not short-cut of additional section information from the
-            DNS cache data.
-          </p>
-<p>
-            One obvious disadvantage of <span><strong class="command">acache</strong></span> is
-            that it requires much more
-            memory for the internal cached data.
-            Thus, if the response performance does not matter and memory
-            consumption is much more critical, the
-            <span><strong class="command">acache</strong></span> mechanism can be
-            disabled by setting <span><strong class="command">acache-enable</strong></span> to
-            <span><strong class="command">no</strong></span>.
-            It is also possible to specify the upper limit of memory
-            consumption
-            for acache by using <span><strong class="command">max-acache-size</strong></span>.
-          </p>
-<p>
-            Additional section caching also has a minor effect on the
-            RRset ordering in the additional section.
-            Without <span><strong class="command">acache</strong></span>,
-            <span><strong class="command">cyclic</strong></span> order is effective for the additional
-            section as well as the answer and authority sections.
-            However, additional section caching fixes the ordering when it
-            first caches an RRset for the additional section, and the same
-            ordering will be kept in succeeding responses, regardless of the
-            setting of <span><strong class="command">rrset-order</strong></span>.
-            The effect of this should be minor, however, since an
-            RRset in the additional section
-            typically only contains a small number of RRs (and in many cases
-            it only contains a single RR), in which case the
-            ordering does not matter much.
-          </p>
-<p>
-            The following is a summary of options related to
-            <span><strong class="command">acache</strong></span>.
-          </p>
-<div class="variablelist"><dl>
-<dt><span class="term"><span><strong class="command">acache-enable</strong></span></span></dt>
-<dd><p>
-                  If <span><strong class="command">yes</strong></span>, additional section caching is
-                  enabled.  The default value is <span><strong class="command">no</strong></span>.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">acache-cleaning-interval</strong></span></span></dt>
-<dd><p>
-                  The server will remove stale cache entries, based on an LRU
-                  based
-                  algorithm, every <span><strong class="command">acache-cleaning-interval</strong></span> minutes.
-                  The default is 60 minutes.
-                  If set to 0, no periodic cleaning will occur.
-                </p></dd>
-<dt><span class="term"><span><strong class="command">max-acache-size</strong></span></span></dt>
-<dd><p>
-                  The maximum amount of memory in bytes to use for the server's acache.
-                  When the amount of data in the acache reaches this limit,
-                  the server
-                  will clean more aggressively so that the limit is not
-                  exceeded.
-                  In a server with multiple views, the limit applies
-                  separately to the
-                  acache of each view.
-                  The default is <code class="literal">unlimited</code>,
-                  meaning that
-                  entries are purged from the acache only at the
-                  periodic cleaning time.
-                </p></dd>
-</dl></div>
-</div>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="server_statement_grammar"></a><span><strong class="command">server</strong></span> Statement Grammar</h3></div></div></div>
-<pre class="programlisting">server <em class="replaceable"><code>ip_addr[/prefixlen]</code></em> {
-    [<span class="optional"> bogus <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
-    [<span class="optional"> provide-ixfr <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
-    [<span class="optional"> request-ixfr <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
-    [<span class="optional"> edns <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
-    [<span class="optional"> edns-udp-size <em class="replaceable"><code>number</code></em> ; </span>]
-    [<span class="optional"> max-udp-size <em class="replaceable"><code>number</code></em> ; </span>]
-    [<span class="optional"> transfers <em class="replaceable"><code>number</code></em> ; </span>]
-    [<span class="optional"> transfer-format <em class="replaceable"><code>( one-answer | many-answers )</code></em> ; ]</span>]
-    [<span class="optional"> keys <em class="replaceable"><code>{ string ; [<span class="optional"> string ; [<span class="optional">...</span>]</span>] }</code></em> ; </span>]
-    [<span class="optional"> transfer-source (<em class="replaceable"><code>ip4_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
-    [<span class="optional"> transfer-source-v6 (<em class="replaceable"><code>ip6_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
-    [<span class="optional"> notify-source (<em class="replaceable"><code>ip4_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
-    [<span class="optional"> notify-source-v6 (<em class="replaceable"><code>ip6_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
-    [<span class="optional"> query-source [<span class="optional"> address ( <em class="replaceable"><code>ip_addr</code></em> | <em class="replaceable"><code>*</code></em> ) </span>] [<span class="optional"> port ( <em class="replaceable"><code>ip_port</code></em> | <em class="replaceable"><code>*</code></em> ) </span>]; </span>]
-    [<span class="optional"> query-source-v6 [<span class="optional"> address ( <em class="replaceable"><code>ip_addr</code></em> | <em class="replaceable"><code>*</code></em> ) </span>] [<span class="optional"> port ( <em class="replaceable"><code>ip_port</code></em> | <em class="replaceable"><code>*</code></em> ) </span>]; </span>]
-};
-</pre>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="server_statement_definition_and_usage"></a><span><strong class="command">server</strong></span> Statement Definition and
-            Usage</h3></div></div></div>
-<p>
-            The <span><strong class="command">server</strong></span> statement defines
-            characteristics
-            to be associated with a remote name server.  If a prefix length is
-            specified, then a range of servers is covered.  Only the most
-            specific
-            server clause applies regardless of the order in
-            <code class="filename">named.conf</code>.
-          </p>
-<p>
-            The <span><strong class="command">server</strong></span> statement can occur at
-            the top level of the
-            configuration file or inside a <span><strong class="command">view</strong></span>
-            statement.
-            If a <span><strong class="command">view</strong></span> statement contains
-            one or more <span><strong class="command">server</strong></span> statements, only
-            those
-            apply to the view and any top-level ones are ignored.
-            If a view contains no <span><strong class="command">server</strong></span>
-            statements,
-            any top-level <span><strong class="command">server</strong></span> statements are
-            used as
-            defaults.
-          </p>
-<p>
-            If you discover that a remote server is giving out bad data,
-            marking it as bogus will prevent further queries to it. The
-            default
-            value of <span><strong class="command">bogus</strong></span> is <span><strong class="command">no</strong></span>.
-          </p>
-<p>
-            The <span><strong class="command">provide-ixfr</strong></span> clause determines
-            whether
-            the local server, acting as master, will respond with an
-            incremental
-            zone transfer when the given remote server, a slave, requests it.
-            If set to <span><strong class="command">yes</strong></span>, incremental transfer
-            will be provided
-            whenever possible. If set to <span><strong class="command">no</strong></span>,
-            all transfers
-            to the remote server will be non-incremental. If not set, the
-            value
-            of the <span><strong class="command">provide-ixfr</strong></span> option in the
-            view or
-            global options block is used as a default.
-          </p>
-<p>
-            The <span><strong class="command">request-ixfr</strong></span> clause determines
-            whether
-            the local server, acting as a slave, will request incremental zone
-            transfers from the given remote server, a master. If not set, the
-            value of the <span><strong class="command">request-ixfr</strong></span> option in
-            the view or
-            global options block is used as a default.
-          </p>
-<p>
-            IXFR requests to servers that do not support IXFR will
-            automatically
-            fall back to AXFR.  Therefore, there is no need to manually list
-            which servers support IXFR and which ones do not; the global
-            default
-            of <span><strong class="command">yes</strong></span> should always work.
-            The purpose of the <span><strong class="command">provide-ixfr</strong></span> and
-            <span><strong class="command">request-ixfr</strong></span> clauses is
-            to make it possible to disable the use of IXFR even when both
-            master
-            and slave claim to support it, for example if one of the servers
-            is buggy and crashes or corrupts data when IXFR is used.
-          </p>
-<p>
-            The <span><strong class="command">edns</strong></span> clause determines whether
-            the local server will attempt to use EDNS when communicating
-            with the remote server.  The default is <span><strong class="command">yes</strong></span>.
-          </p>
-<p>
-            The <span><strong class="command">edns-udp-size</strong></span> option sets the EDNS UDP size
-            that is advertised by named when querying the remote server.
-            Valid values are 512 to 4096 bytes (values outside this range will be
-            silently adjusted).  This option is useful when you wish to
-            advertises a different value to this server than the value you
-            advertise globally, for example, when there is a firewall at the
-            remote site that is blocking large replies.
-          </p>
-<p>
-            The <span><strong class="command">max-udp-size</strong></span> option sets the
-            maximum EDNS UDP message size named will send.  Valid
-            values are 512 to 4096 bytes (values outside this range will
-            be silently adjusted).  This option is useful when you
-            know that there is a firewall that is blocking large
-            replies from named.
-          </p>
-<p>
-            The server supports two zone transfer methods. The first, <span><strong class="command">one-answer</strong></span>,
-            uses one DNS message per resource record transferred. <span><strong class="command">many-answers</strong></span> packs
-            as many resource records as possible into a message. <span><strong class="command">many-answers</strong></span> is
-            more efficient, but is only known to be understood by <acronym class="acronym">BIND</acronym> 9, <acronym class="acronym">BIND</acronym>
-            8.x, and patched versions of <acronym class="acronym">BIND</acronym>
-            4.9.5. You can specify which method
-            to use for a server with the <span><strong class="command">transfer-format</strong></span> option.
-            If <span><strong class="command">transfer-format</strong></span> is not
-            specified, the <span><strong class="command">transfer-format</strong></span>
-            specified
-            by the <span><strong class="command">options</strong></span> statement will be
-            used.
-          </p>
-<p><span><strong class="command">transfers</strong></span>
-            is used to limit the number of concurrent inbound zone
-            transfers from the specified server. If no
-            <span><strong class="command">transfers</strong></span> clause is specified, the
-            limit is set according to the
-            <span><strong class="command">transfers-per-ns</strong></span> option.
-          </p>
-<p>
-            The <span><strong class="command">keys</strong></span> clause identifies a
-            <span><strong class="command">key_id</strong></span> defined by the <span><strong class="command">key</strong></span> statement,
-            to be used for transaction security (TSIG, <a href="Bv9ARM.ch04.html#tsig" title="TSIG">the section called &#8220;TSIG&#8221;</a>)
-            when talking to the remote server.
-            When a request is sent to the remote server, a request signature
-            will be generated using the key specified here and appended to the
-            message. A request originating from the remote server is not
-            required
-            to be signed by this key.
-          </p>
-<p>
-            Although the grammar of the <span><strong class="command">keys</strong></span>
-            clause
-            allows for multiple keys, only a single key per server is
-            currently
-            supported.
-          </p>
-<p>
-            The <span><strong class="command">transfer-source</strong></span> and
-            <span><strong class="command">transfer-source-v6</strong></span> clauses specify
-            the IPv4 and IPv6 source
-            address to be used for zone transfer with the remote server,
-            respectively.
-            For an IPv4 remote server, only <span><strong class="command">transfer-source</strong></span> can
-            be specified.
-            Similarly, for an IPv6 remote server, only
-            <span><strong class="command">transfer-source-v6</strong></span> can be
-            specified.
-            For more details, see the description of
-            <span><strong class="command">transfer-source</strong></span> and
-            <span><strong class="command">transfer-source-v6</strong></span> in
-            <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>.
-          </p>
-<p>
-            The <span><strong class="command">notify-source</strong></span> and
-            <span><strong class="command">notify-source-v6</strong></span> clauses specify the
-            IPv4 and IPv6 source address to be used for notify
-            messages sent to remote servers, respectively.  For an
-            IPv4 remote server, only <span><strong class="command">notify-source</strong></span>
-            can be specified.  Similarly, for an IPv6 remote server,
-            only <span><strong class="command">notify-source-v6</strong></span> can be specified.
-          </p>
-<p>
-            The <span><strong class="command">query-source</strong></span> and
-            <span><strong class="command">query-source-v6</strong></span> clauses specify the
-            IPv4 and IPv6 source address to be used for queries
-            sent to remote servers, respectively.  For an IPv4
-            remote server, only <span><strong class="command">query-source</strong></span> can
-            be specified.  Similarly, for an IPv6 remote server,
-            only <span><strong class="command">query-source-v6</strong></span> can be specified.
-          </p>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2585361"></a><span><strong class="command">trusted-keys</strong></span> Statement Grammar</h3></div></div></div>
-<pre class="programlisting">trusted-keys {
-    <em class="replaceable"><code>string</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>string</code></em> ;
-    [<span class="optional"> <em class="replaceable"><code>string</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>string</code></em> ; [<span class="optional">...</span>]</span>]
-};
-</pre>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2585410"></a><span><strong class="command">trusted-keys</strong></span> Statement Definition
-            and Usage</h3></div></div></div>
-<p>
-            The <span><strong class="command">trusted-keys</strong></span> statement defines
-            DNSSEC security roots. DNSSEC is described in <a href="Bv9ARM.ch04.html#DNSSEC" title="DNSSEC">the section called &#8220;DNSSEC&#8221;</a>. A security root is defined when the
-            public key for a non-authoritative zone is known, but
-            cannot be securely obtained through DNS, either because
-            it is the DNS root zone or because its parent zone is
-            unsigned.  Once a key has been configured as a trusted
-            key, it is treated as if it had been validated and
-            proven secure. The resolver attempts DNSSEC validation
-            on all DNS data in subdomains of a security root.
-          </p>
-<p>
-            All keys (and corresponding zones) listed in
-            <span><strong class="command">trusted-keys</strong></span> are deemed to exist regardless
-            of what parent zones say.  Similarly for all keys listed in
-            <span><strong class="command">trusted-keys</strong></span> only those keys are
-            used to validate the DNSKEY RRset.  The parent's DS RRset
-            will not be used.
-          </p>
-<p>
-            The <span><strong class="command">trusted-keys</strong></span> statement can contain
-            multiple key entries, each consisting of the key's
-            domain name, flags, protocol, algorithm, and the Base-64
-            representation of the key data.
-          </p>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="view_statement_grammar"></a><span><strong class="command">view</strong></span> Statement Grammar</h3></div></div></div>
-<pre class="programlisting">view <em class="replaceable"><code>view_name</code></em>
-      [<span class="optional"><em class="replaceable"><code>class</code></em></span>] {
-      match-clients { <em class="replaceable"><code>address_match_list</code></em> };
-      match-destinations { <em class="replaceable"><code>address_match_list</code></em> };
-      match-recursive-only <em class="replaceable"><code>yes_or_no</code></em> ;
-      [<span class="optional"> <em class="replaceable"><code>view_option</code></em>; ...</span>]
-      [<span class="optional"> <em class="replaceable"><code>zone_statement</code></em>; ...</span>]
-};
-</pre>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2585490"></a><span><strong class="command">view</strong></span> Statement Definition and Usage</h3></div></div></div>
-<p>
-            The <span><strong class="command">view</strong></span> statement is a powerful
-            feature
-            of <acronym class="acronym">BIND</acronym> 9 that lets a name server
-            answer a DNS query differently
-            depending on who is asking. It is particularly useful for
-            implementing
-            split DNS setups without having to run multiple servers.
-          </p>
-<p>
-            Each <span><strong class="command">view</strong></span> statement defines a view
-            of the
-            DNS namespace that will be seen by a subset of clients.  A client
-            matches
-            a view if its source IP address matches the
-            <code class="varname">address_match_list</code> of the view's
-            <span><strong class="command">match-clients</strong></span> clause and its
-            destination IP address matches
-            the <code class="varname">address_match_list</code> of the
-            view's
-            <span><strong class="command">match-destinations</strong></span> clause.  If not
-            specified, both
-            <span><strong class="command">match-clients</strong></span> and <span><strong class="command">match-destinations</strong></span>
-            default to matching all addresses.  In addition to checking IP
-            addresses
-            <span><strong class="command">match-clients</strong></span> and <span><strong class="command">match-destinations</strong></span>
-            can also take <span><strong class="command">keys</strong></span> which provide an
-            mechanism for the
-            client to select the view.  A view can also be specified
-            as <span><strong class="command">match-recursive-only</strong></span>, which
-            means that only recursive
-            requests from matching clients will match that view.
-            The order of the <span><strong class="command">view</strong></span> statements is
-            significant &#8212;
-            a client request will be resolved in the context of the first
-            <span><strong class="command">view</strong></span> that it matches.
-          </p>
-<p>
-            Zones defined within a <span><strong class="command">view</strong></span>
-            statement will
-            be only be accessible to clients that match the <span><strong class="command">view</strong></span>.
-            By defining a zone of the same name in multiple views, different
-            zone data can be given to different clients, for example,
-            "internal"
-            and "external" clients in a split DNS setup.
-          </p>
-<p>
-            Many of the options given in the <span><strong class="command">options</strong></span> statement
-            can also be used within a <span><strong class="command">view</strong></span>
-            statement, and then
-            apply only when resolving queries with that view.  When no
-            view-specific
-            value is given, the value in the <span><strong class="command">options</strong></span> statement
-            is used as a default.  Also, zone options can have default values
-            specified
-            in the <span><strong class="command">view</strong></span> statement; these
-            view-specific defaults
-            take precedence over those in the <span><strong class="command">options</strong></span> statement.
-          </p>
-<p>
-            Views are class specific.  If no class is given, class IN
-            is assumed.  Note that all non-IN views must contain a hint zone,
-            since only the IN class has compiled-in default hints.
-          </p>
-<p>
-            If there are no <span><strong class="command">view</strong></span> statements in
-            the config
-            file, a default view that matches any client is automatically
-            created
-            in class IN. Any <span><strong class="command">zone</strong></span> statements
-            specified on
-            the top level of the configuration file are considered to be part
-            of
-            this default view, and the <span><strong class="command">options</strong></span>
-            statement will
-            apply to the default view. If any explicit <span><strong class="command">view</strong></span>
-            statements are present, all <span><strong class="command">zone</strong></span>
-            statements must
-            occur inside <span><strong class="command">view</strong></span> statements.
-          </p>
-<p>
-            Here is an example of a typical split DNS setup implemented
-            using <span><strong class="command">view</strong></span> statements:
-          </p>
-<pre class="programlisting">view "internal" {
-      // This should match our internal networks.
-      match-clients { 10.0.0.0/8; };
-
-      // Provide recursive service to internal clients only.
-      recursion yes;
-
-      // Provide a complete view of the example.com zone
-      // including addresses of internal hosts.
-      zone "example.com" {
-            type master;
-            file "example-internal.db";
-      };
-};
-
-view "external" {
-      // Match all clients not matched by the previous view.
-      match-clients { any; };
-
-      // Refuse recursive service to external clients.
-      recursion no;
-
-      // Provide a restricted view of the example.com zone
-      // containing only publicly accessible hosts.
-      zone "example.com" {
-           type master;
-           file "example-external.db";
-      };
-};
-</pre>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="zone_statement_grammar"></a><span><strong class="command">zone</strong></span>
-            Statement Grammar</h3></div></div></div>
-<pre class="programlisting">zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"><em class="replaceable"><code>class</code></em></span>] {
-    type master;
-    [<span class="optional"> allow-query { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
-    [<span class="optional"> allow-transfer { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
-    [<span class="optional"> allow-update { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
-    [<span class="optional"> update-policy { <em class="replaceable"><code>update_policy_rule</code></em> [<span class="optional">...</span>] }; </span>]
-    [<span class="optional"> also-notify { <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; [<span class="optional"> <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; ... </span>] }; </span>]
-    [<span class="optional"> check-names (<code class="constant">warn</code>|<code class="constant">fail</code>|<code class="constant">ignore</code>) ; </span>]
-    [<span class="optional"> check-mx (<code class="constant">warn</code>|<code class="constant">fail</code>|<code class="constant">ignore</code>) ; </span>]
-    [<span class="optional"> check-wildcard <em class="replaceable"><code>yes_or_no</code></em>; </span>]
-    [<span class="optional"> check-integrity <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
-    [<span class="optional"> dialup <em class="replaceable"><code>dialup_option</code></em> ; </span>]
-    [<span class="optional"> file <em class="replaceable"><code>string</code></em> ; </span>]
-    [<span class="optional"> masterfile-format (<code class="constant">text</code>|<code class="constant">raw</code>) ; </span>]
-    [<span class="optional"> journal <em class="replaceable"><code>string</code></em> ; </span>]
-    [<span class="optional"> forward (<code class="constant">only</code>|<code class="constant">first</code>) ; </span>]
-    [<span class="optional"> forwarders { [<span class="optional"> <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; ... </span>] }; </span>]
-    [<span class="optional"> ixfr-base <em class="replaceable"><code>string</code></em> ; </span>]
-    [<span class="optional"> ixfr-tmp-file <em class="replaceable"><code>string</code></em> ; </span>]
-    [<span class="optional"> maintain-ixfr-base <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
-    [<span class="optional"> max-ixfr-log-size <em class="replaceable"><code>number</code></em> ; </span>]
-    [<span class="optional"> max-transfer-idle-out <em class="replaceable"><code>number</code></em> ; </span>]
-    [<span class="optional"> max-transfer-time-out <em class="replaceable"><code>number</code></em> ; </span>]
-    [<span class="optional"> notify <em class="replaceable"><code>yes_or_no</code></em> | <em class="replaceable"><code>explicit</code></em> | <em class="replaceable"><code>master-only</code></em> ; </span>]
-    [<span class="optional"> notify-delay <em class="replaceable"><code>seconds</code></em> ; </span>]
-    [<span class="optional"> pubkey <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>string</code></em> ; </span>]
-    [<span class="optional"> notify-source (<em class="replaceable"><code>ip4_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
-    [<span class="optional"> notify-source-v6 (<em class="replaceable"><code>ip6_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
-    [<span class="optional"> zone-statistics <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
-    [<span class="optional"> sig-validity-interval <em class="replaceable"><code>number</code></em> ; </span>]
-    [<span class="optional"> database <em class="replaceable"><code>string</code></em> ; </span>]
-    [<span class="optional"> min-refresh-time <em class="replaceable"><code>number</code></em> ; </span>]
-    [<span class="optional"> max-refresh-time <em class="replaceable"><code>number</code></em> ; </span>]
-    [<span class="optional"> min-retry-time <em class="replaceable"><code>number</code></em> ; </span>]
-    [<span class="optional"> max-retry-time <em class="replaceable"><code>number</code></em> ; </span>]
-    [<span class="optional"> key-directory <em class="replaceable"><code>path_name</code></em>; </span>]
-    [<span class="optional"> zero-no-soa-ttl <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
-};
-
-zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"><em class="replaceable"><code>class</code></em></span>] {
-    type slave;
-    [<span class="optional"> allow-notify { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
-    [<span class="optional"> allow-query { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
-    [<span class="optional"> allow-transfer { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
-    [<span class="optional"> allow-update-forwarding { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
-    [<span class="optional"> update-check-ksk <em class="replaceable"><code>yes_or_no</code></em>; </span>]
-    [<span class="optional"> also-notify { <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; [<span class="optional"> <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; ... </span>] }; </span>]
-    [<span class="optional"> check-names (<code class="constant">warn</code>|<code class="constant">fail</code>|<code class="constant">ignore</code>) ; </span>]
-    [<span class="optional"> dialup <em class="replaceable"><code>dialup_option</code></em> ; </span>]
-    [<span class="optional"> file <em class="replaceable"><code>string</code></em> ; </span>]
-    [<span class="optional"> masterfile-format (<code class="constant">text</code>|<code class="constant">raw</code>) ; </span>]
-    [<span class="optional"> journal <em class="replaceable"><code>string</code></em> ; </span>]
-    [<span class="optional"> forward (<code class="constant">only</code>|<code class="constant">first</code>) ; </span>]
-    [<span class="optional"> forwarders { [<span class="optional"> <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; ... </span>] }; </span>]
-    [<span class="optional"> ixfr-base <em class="replaceable"><code>string</code></em> ; </span>]
-    [<span class="optional"> ixfr-tmp-file <em class="replaceable"><code>string</code></em> ; </span>]
-    [<span class="optional"> maintain-ixfr-base <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
-    [<span class="optional"> masters [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] { ( <em class="replaceable"><code>masters_list</code></em> | <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] [<span class="optional">key <em class="replaceable"><code>key</code></em></span>] ) ; [<span class="optional">...</span>] }; </span>]
-    [<span class="optional"> max-ixfr-log-size <em class="replaceable"><code>number</code></em> ; </span>]
-    [<span class="optional"> max-transfer-idle-in <em class="replaceable"><code>number</code></em> ; </span>]
-    [<span class="optional"> max-transfer-idle-out <em class="replaceable"><code>number</code></em> ; </span>]
-    [<span class="optional"> max-transfer-time-in <em class="replaceable"><code>number</code></em> ; </span>]
-    [<span class="optional"> max-transfer-time-out <em class="replaceable"><code>number</code></em> ; </span>]
-    [<span class="optional"> notify <em class="replaceable"><code>yes_or_no</code></em> | <em class="replaceable"><code>explicit</code></em> | <em class="replaceable"><code>master-only</code></em> ; </span>]
-    [<span class="optional"> pubkey <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>string</code></em> ; </span>]
-    [<span class="optional"> transfer-source (<em class="replaceable"><code>ip4_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
-    [<span class="optional"> transfer-source-v6 (<em class="replaceable"><code>ip6_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
-    [<span class="optional"> alt-transfer-source (<em class="replaceable"><code>ip4_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
-    [<span class="optional"> alt-transfer-source-v6 (<em class="replaceable"><code>ip6_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
-    [<span class="optional"> use-alt-transfer-source <em class="replaceable"><code>yes_or_no</code></em>; </span>]
-    [<span class="optional"> notify-source (<em class="replaceable"><code>ip4_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
-    [<span class="optional"> notify-source-v6 (<em class="replaceable"><code>ip6_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
-    [<span class="optional"> zone-statistics <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
-    [<span class="optional"> database <em class="replaceable"><code>string</code></em> ; </span>]
-    [<span class="optional"> min-refresh-time <em class="replaceable"><code>number</code></em> ; </span>]
-    [<span class="optional"> max-refresh-time <em class="replaceable"><code>number</code></em> ; </span>]
-    [<span class="optional"> min-retry-time <em class="replaceable"><code>number</code></em> ; </span>]
-    [<span class="optional"> max-retry-time <em class="replaceable"><code>number</code></em> ; </span>]
-    [<span class="optional"> multi-master <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
-    [<span class="optional"> zero-no-soa-ttl <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
-};
-
-zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"><em class="replaceable"><code>class</code></em></span>] {
-    type hint;
-    file <em class="replaceable"><code>string</code></em> ;
-    [<span class="optional"> delegation-only <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
-    [<span class="optional"> check-names (<code class="constant">warn</code>|<code class="constant">fail</code>|<code class="constant">ignore</code>) ; // Not Implemented. </span>]
-};
-
-zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"><em class="replaceable"><code>class</code></em></span>] {
-    type stub;
-    [<span class="optional"> allow-query { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
-    [<span class="optional"> check-names (<code class="constant">warn</code>|<code class="constant">fail</code>|<code class="constant">ignore</code>) ; </span>]
-    [<span class="optional"> dialup <em class="replaceable"><code>dialup_option</code></em> ; </span>]
-    [<span class="optional"> delegation-only <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
-    [<span class="optional"> file <em class="replaceable"><code>string</code></em> ; </span>]
-    [<span class="optional"> masterfile-format (<code class="constant">text</code>|<code class="constant">raw</code>) ; </span>]
-    [<span class="optional"> forward (<code class="constant">only</code>|<code class="constant">first</code>) ; </span>]
-    [<span class="optional"> forwarders { [<span class="optional"> <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; ... </span>] }; </span>]
-    [<span class="optional"> masters [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] { ( <em class="replaceable"><code>masters_list</code></em> | <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] [<span class="optional">key <em class="replaceable"><code>key</code></em></span>] ) ; [<span class="optional">...</span>] }; </span>]
-    [<span class="optional"> max-transfer-idle-in <em class="replaceable"><code>number</code></em> ; </span>]
-    [<span class="optional"> max-transfer-time-in <em class="replaceable"><code>number</code></em> ; </span>]
-    [<span class="optional"> pubkey <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>string</code></em> ; </span>]
-    [<span class="optional"> transfer-source (<em class="replaceable"><code>ip4_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
-    [<span class="optional"> transfer-source-v6 (<em class="replaceable"><code>ip6_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
-    [<span class="optional"> alt-transfer-source (<em class="replaceable"><code>ip4_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
-    [<span class="optional"> alt-transfer-source-v6 (<em class="replaceable"><code>ip6_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
-    [<span class="optional"> use-alt-transfer-source <em class="replaceable"><code>yes_or_no</code></em>; </span>]
-    [<span class="optional"> zone-statistics <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
-    [<span class="optional"> database <em class="replaceable"><code>string</code></em> ; </span>]
-    [<span class="optional"> min-refresh-time <em class="replaceable"><code>number</code></em> ; </span>]
-    [<span class="optional"> max-refresh-time <em class="replaceable"><code>number</code></em> ; </span>]
-    [<span class="optional"> min-retry-time <em class="replaceable"><code>number</code></em> ; </span>]
-    [<span class="optional"> max-retry-time <em class="replaceable"><code>number</code></em> ; </span>]
-    [<span class="optional"> multi-master <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
-};
-
-zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"><em class="replaceable"><code>class</code></em></span>] {
-    type forward;
-    [<span class="optional"> forward (<code class="constant">only</code>|<code class="constant">first</code>) ; </span>]
-    [<span class="optional"> forwarders { [<span class="optional"> <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; ... </span>] }; </span>]
-    [<span class="optional"> delegation-only <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
-};
-
-zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"><em class="replaceable"><code>class</code></em></span>] {
-    type delegation-only;
-};
-
-</pre>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2586798"></a><span><strong class="command">zone</strong></span> Statement Definition and Usage</h3></div></div></div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2586806"></a>Zone Types</h4></div></div></div>
-<div class="informaltable"><table border="1">
-<colgroup>
-<col>
-<col>
-</colgroup>
-<tbody>
-<tr>
-<td>
-                      <p>
-                        <code class="varname">master</code>
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        The server has a master copy of the data
-                        for the zone and will be able to provide authoritative
-                        answers for
-                        it.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        <code class="varname">slave</code>
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        A slave zone is a replica of a master
-                        zone. The <span><strong class="command">masters</strong></span> list
-                        specifies one or more IP addresses
-                        of master servers that the slave contacts to update
-                        its copy of the zone.
-                        Masters list elements can also be names of other
-                        masters lists.
-                        By default, transfers are made from port 53 on the
-                        servers; this can
-                        be changed for all servers by specifying a port number
-                        before the
-                        list of IP addresses, or on a per-server basis after
-                        the IP address.
-                        Authentication to the master can also be done with
-                        per-server TSIG keys.
-                        If a file is specified, then the
-                        replica will be written to this file whenever the zone
-                        is changed,
-                        and reloaded from this file on a server restart. Use
-                        of a file is
-                        recommended, since it often speeds server startup and
-                        eliminates
-                        a needless waste of bandwidth. Note that for large
-                        numbers (in the
-                        tens or hundreds of thousands) of zones per server, it
-                        is best to
-                        use a two-level naming scheme for zone filenames. For
-                        example,
-                        a slave server for the zone <code class="literal">example.com</code> might place
-                        the zone contents into a file called
-                        <code class="filename">ex/example.com</code> where <code class="filename">ex/</code> is
-                        just the first two letters of the zone name. (Most
-                        operating systems
-                        behave very slowly if you put 100 000 files into
-                        a single directory.)
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        <code class="varname">stub</code>
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        A stub zone is similar to a slave zone,
-                        except that it replicates only the NS records of a
-                        master zone instead
-                        of the entire zone. Stub zones are not a standard part
-                        of the DNS;
-                        they are a feature specific to the <acronym class="acronym">BIND</acronym> implementation.
-                      </p>
-
-                      <p>
-                        Stub zones can be used to eliminate the need for glue
-                        NS record
-                        in a parent zone at the expense of maintaining a stub
-                        zone entry and
-                        a set of name server addresses in <code class="filename">named.conf</code>.
-                        This usage is not recommended for new configurations,
-                        and BIND 9
-                        supports it only in a limited way.
-                        In <acronym class="acronym">BIND</acronym> 4/8, zone
-                        transfers of a parent zone
-                        included the NS records from stub children of that
-                        zone. This meant
-                        that, in some cases, users could get away with
-                        configuring child stubs
-                        only in the master server for the parent zone. <acronym class="acronym">BIND</acronym>
-                        9 never mixes together zone data from different zones
-                        in this
-                        way. Therefore, if a <acronym class="acronym">BIND</acronym> 9 master serving a parent
-                        zone has child stub zones configured, all the slave
-                        servers for the
-                        parent zone also need to have the same child stub
-                        zones
-                        configured.
-                      </p>
-
-                      <p>
-                        Stub zones can also be used as a way of forcing the
-                        resolution
-                        of a given domain to use a particular set of
-                        authoritative servers.
-                        For example, the caching name servers on a private
-                        network using
-                        RFC1918 addressing may be configured with stub zones
-                        for
-                        <code class="literal">10.in-addr.arpa</code>
-                        to use a set of internal name servers as the
-                        authoritative
-                        servers for that domain.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        <code class="varname">forward</code>
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        A "forward zone" is a way to configure
-                        forwarding on a per-domain basis.  A <span><strong class="command">zone</strong></span> statement
-                        of type <span><strong class="command">forward</strong></span> can
-                        contain a <span><strong class="command">forward</strong></span>
-                        and/or <span><strong class="command">forwarders</strong></span>
-                        statement,
-                        which will apply to queries within the domain given by
-                        the zone
-                        name. If no <span><strong class="command">forwarders</strong></span>
-                        statement is present or
-                        an empty list for <span><strong class="command">forwarders</strong></span> is given, then no
-                        forwarding will be done for the domain, canceling the
-                        effects of
-                        any forwarders in the <span><strong class="command">options</strong></span> statement. Thus
-                        if you want to use this type of zone to change the
-                        behavior of the
-                        global <span><strong class="command">forward</strong></span> option
-                        (that is, "forward first"
-                        to, then "forward only", or vice versa, but want to
-                        use the same
-                        servers as set globally) you need to re-specify the
-                        global forwarders.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        <code class="varname">hint</code>
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        The initial set of root name servers is
-                        specified using a "hint zone". When the server starts
-                        up, it uses
-                        the root hints to find a root name server and get the
-                        most recent
-                        list of root name servers. If no hint zone is
-                        specified for class
-                        IN, the server uses a compiled-in default set of root
-                        servers hints.
-                        Classes other than IN have no built-in defaults hints.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        <code class="varname">delegation-only</code>
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        This is used to enforce the delegation-only
-                        status of infrastructure zones (e.g. COM, NET, ORG).
-                        Any answer that
-                        is received without an explicit or implicit delegation
-                        in the authority
-                        section will be treated as NXDOMAIN.  This does not
-                        apply to the zone
-                        apex.  This should not be applied to leaf zones.
-                      </p>
-                      <p>
-                        <code class="varname">delegation-only</code> has no
-                        effect on answers received
-                        from forwarders.
-                      </p>
-                    </td>
-</tr>
-</tbody>
-</table></div>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2587362"></a>Class</h4></div></div></div>
-<p>
-              The zone's name may optionally be followed by a class. If
-              a class is not specified, class <code class="literal">IN</code> (for <code class="varname">Internet</code>),
-              is assumed. This is correct for the vast majority of cases.
-            </p>
-<p>
-              The <code class="literal">hesiod</code> class is
-              named for an information service from MIT's Project Athena. It
-              is
-              used to share information about various systems databases, such
-              as users, groups, printers and so on. The keyword
-              <code class="literal">HS</code> is
-              a synonym for hesiod.
-            </p>
-<p>
-              Another MIT development is Chaosnet, a LAN protocol created
-              in the mid-1970s. Zone data for it can be specified with the <code class="literal">CHAOS</code> class.
-            </p>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2587395"></a>Zone Options</h4></div></div></div>
-<div class="variablelist"><dl>
-<dt><span class="term"><span><strong class="command">allow-notify</strong></span></span></dt>
-<dd><p>
-                    See the description of
-                    <span><strong class="command">allow-notify</strong></span> in <a href="Bv9ARM.ch06.html#access_control" title="Access Control">the section called &#8220;Access Control&#8221;</a>.
-                  </p></dd>
-<dt><span class="term"><span><strong class="command">allow-query</strong></span></span></dt>
-<dd><p>
-                    See the description of
-                    <span><strong class="command">allow-query</strong></span> in <a href="Bv9ARM.ch06.html#access_control" title="Access Control">the section called &#8220;Access Control&#8221;</a>.
-                  </p></dd>
-<dt><span class="term"><span><strong class="command">allow-transfer</strong></span></span></dt>
-<dd><p>
-                    See the description of <span><strong class="command">allow-transfer</strong></span>
-                    in <a href="Bv9ARM.ch06.html#access_control" title="Access Control">the section called &#8220;Access Control&#8221;</a>.
-                  </p></dd>
-<dt><span class="term"><span><strong class="command">allow-update</strong></span></span></dt>
-<dd><p>
-                    See the description of <span><strong class="command">allow-update</strong></span>
-                    in <a href="Bv9ARM.ch06.html#access_control" title="Access Control">the section called &#8220;Access Control&#8221;</a>.
-                  </p></dd>
-<dt><span class="term"><span><strong class="command">update-policy</strong></span></span></dt>
-<dd><p>
-                    Specifies a "Simple Secure Update" policy. See
-                    <a href="Bv9ARM.ch06.html#dynamic_update_policies" title="Dynamic Update Policies">the section called &#8220;Dynamic Update Policies&#8221;</a>.
-                  </p></dd>
-<dt><span class="term"><span><strong class="command">allow-update-forwarding</strong></span></span></dt>
-<dd><p>
-                    See the description of <span><strong class="command">allow-update-forwarding</strong></span>
-                    in <a href="Bv9ARM.ch06.html#access_control" title="Access Control">the section called &#8220;Access Control&#8221;</a>.
-                  </p></dd>
-<dt><span class="term"><span><strong class="command">also-notify</strong></span></span></dt>
-<dd><p>
-                    Only meaningful if <span><strong class="command">notify</strong></span>
-                    is
-                    active for this zone. The set of machines that will
-                    receive a
-                    <code class="literal">DNS NOTIFY</code> message
-                    for this zone is made up of all the listed name servers
-                    (other than
-                    the primary master) for the zone plus any IP addresses
-                    specified
-                    with <span><strong class="command">also-notify</strong></span>. A port
-                    may be specified
-                    with each <span><strong class="command">also-notify</strong></span>
-                    address to send the notify
-                    messages to a port other than the default of 53.
-                    <span><strong class="command">also-notify</strong></span> is not
-                    meaningful for stub zones.
-                    The default is the empty list.
-                  </p></dd>
-<dt><span class="term"><span><strong class="command">check-names</strong></span></span></dt>
-<dd><p>
-                    This option is used to restrict the character set and
-                    syntax of
-                    certain domain names in master files and/or DNS responses
-                    received from the
-                    network.  The default varies according to zone type.  For <span><strong class="command">master</strong></span> zones the default is <span><strong class="command">fail</strong></span>.  For <span><strong class="command">slave</strong></span>
-                    zones the default is <span><strong class="command">warn</strong></span>.
-                  </p></dd>
-<dt><span class="term"><span><strong class="command">check-mx</strong></span></span></dt>
-<dd><p>
-                    See the description of
-                    <span><strong class="command">check-mx</strong></span> in <a href="Bv9ARM.ch06.html#boolean_options" title="Boolean Options">the section called &#8220;Boolean Options&#8221;</a>.
-                  </p></dd>
-<dt><span class="term"><span><strong class="command">check-wildcard</strong></span></span></dt>
-<dd><p>
-                    See the description of
-                    <span><strong class="command">check-wildcard</strong></span> in <a href="Bv9ARM.ch06.html#boolean_options" title="Boolean Options">the section called &#8220;Boolean Options&#8221;</a>.
-                  </p></dd>
-<dt><span class="term"><span><strong class="command">check-integrity</strong></span></span></dt>
-<dd><p>
-                    See the description of
-                    <span><strong class="command">check-integrity</strong></span> in <a href="Bv9ARM.ch06.html#boolean_options" title="Boolean Options">the section called &#8220;Boolean Options&#8221;</a>.
-                  </p></dd>
-<dt><span class="term"><span><strong class="command">check-sibling</strong></span></span></dt>
-<dd><p>
-                    See the description of
-                    <span><strong class="command">check-sibling</strong></span> in <a href="Bv9ARM.ch06.html#boolean_options" title="Boolean Options">the section called &#8220;Boolean Options&#8221;</a>.
-                  </p></dd>
-<dt><span class="term"><span><strong class="command">zero-no-soa-ttl</strong></span></span></dt>
-<dd><p>
-                    See the description of
-                    <span><strong class="command">zero-no-soa-ttl</strong></span> in <a href="Bv9ARM.ch06.html#boolean_options" title="Boolean Options">the section called &#8220;Boolean Options&#8221;</a>.
-                  </p></dd>
-<dt><span class="term"><span><strong class="command">update-check-ksk</strong></span></span></dt>
-<dd><p>
-                    See the description of
-                    <span><strong class="command">update-check-ksk</strong></span> in <a href="Bv9ARM.ch06.html#boolean_options" title="Boolean Options">the section called &#8220;Boolean Options&#8221;</a>.
-                  </p></dd>
-<dt><span class="term"><span><strong class="command">database</strong></span></span></dt>
-<dd>
-<p>
-                    Specify the type of database to be used for storing the
-                    zone data.  The string following the <span><strong class="command">database</strong></span> keyword
-                    is interpreted as a list of whitespace-delimited words.
-                    The first word
-                    identifies the database type, and any subsequent words are
-                    passed
-                    as arguments to the database to be interpreted in a way
-                    specific
-                    to the database type.
-                  </p>
-<p>
-                    The default is <strong class="userinput"><code>"rbt"</code></strong>, BIND 9's
-                    native in-memory
-                    red-black-tree database.  This database does not take
-                    arguments.
-                  </p>
-<p>
-                    Other values are possible if additional database drivers
-                    have been linked into the server.  Some sample drivers are
-                    included
-                    with the distribution but none are linked in by default.
-                  </p>
-</dd>
-<dt><span class="term"><span><strong class="command">dialup</strong></span></span></dt>
-<dd><p>
-                    See the description of
-                    <span><strong class="command">dialup</strong></span> in <a href="Bv9ARM.ch06.html#boolean_options" title="Boolean Options">the section called &#8220;Boolean Options&#8221;</a>.
-                  </p></dd>
-<dt><span class="term"><span><strong class="command">delegation-only</strong></span></span></dt>
-<dd><p>
-                    The flag only applies to hint and stub zones.  If set
-                    to <strong class="userinput"><code>yes</code></strong>, then the zone will also be
-                    treated as if it
-                    is also a delegation-only type zone.
-                  </p></dd>
-<dt><span class="term"><span><strong class="command">forward</strong></span></span></dt>
-<dd><p>
-                    Only meaningful if the zone has a forwarders
-                    list. The <span><strong class="command">only</strong></span> value causes
-                    the lookup to fail
-                    after trying the forwarders and getting no answer, while <span><strong class="command">first</strong></span> would
-                    allow a normal lookup to be tried.
-                  </p></dd>
-<dt><span class="term"><span><strong class="command">forwarders</strong></span></span></dt>
-<dd><p>
-                    Used to override the list of global forwarders.
-                    If it is not specified in a zone of type <span><strong class="command">forward</strong></span>,
-                    no forwarding is done for the zone and the global options are
-                    not used.
-                  </p></dd>
-<dt><span class="term"><span><strong class="command">ixfr-base</strong></span></span></dt>
-<dd><p>
-                    Was used in <acronym class="acronym">BIND</acronym> 8 to
-                    specify the name
-                    of the transaction log (journal) file for dynamic update
-                    and IXFR.
-                    <acronym class="acronym">BIND</acronym> 9 ignores the option
-                    and constructs the name of the journal
-                    file by appending "<code class="filename">.jnl</code>"
-                    to the name of the
-                    zone file.
-                  </p></dd>
-<dt><span class="term"><span><strong class="command">ixfr-tmp-file</strong></span></span></dt>
-<dd><p>
-                    Was an undocumented option in <acronym class="acronym">BIND</acronym> 8.
-                    Ignored in <acronym class="acronym">BIND</acronym> 9.
-                  </p></dd>
-<dt><span class="term"><span><strong class="command">journal</strong></span></span></dt>
-<dd><p>
-                    Allow the default journal's filename to be overridden.
-                    The default is the zone's filename with "<code class="filename">.jnl</code>" appended.
-                    This is applicable to <span><strong class="command">master</strong></span> and <span><strong class="command">slave</strong></span> zones.
-                  </p></dd>
-<dt><span class="term"><span><strong class="command">max-transfer-time-in</strong></span></span></dt>
-<dd><p>
-                    See the description of
-                    <span><strong class="command">max-transfer-time-in</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>.
-                  </p></dd>
-<dt><span class="term"><span><strong class="command">max-transfer-idle-in</strong></span></span></dt>
-<dd><p>
-                    See the description of
-                    <span><strong class="command">max-transfer-idle-in</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>.
-                  </p></dd>
-<dt><span class="term"><span><strong class="command">max-transfer-time-out</strong></span></span></dt>
-<dd><p>
-                    See the description of
-                    <span><strong class="command">max-transfer-time-out</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>.
-                  </p></dd>
-<dt><span class="term"><span><strong class="command">max-transfer-idle-out</strong></span></span></dt>
-<dd><p>
-                    See the description of
-                    <span><strong class="command">max-transfer-idle-out</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>.
-                  </p></dd>
-<dt><span class="term"><span><strong class="command">notify</strong></span></span></dt>
-<dd><p>
-                    See the description of
-                    <span><strong class="command">notify</strong></span> in <a href="Bv9ARM.ch06.html#boolean_options" title="Boolean Options">the section called &#8220;Boolean Options&#8221;</a>.
-                  </p></dd>
-<dt><span class="term"><span><strong class="command">notify-delay</strong></span></span></dt>
-<dd><p>
-                    See the description of
-                    <span><strong class="command">notify-delay</strong></span> in <a href="Bv9ARM.ch06.html#tuning" title="Tuning">the section called &#8220;Tuning&#8221;</a>.
-                  </p></dd>
-<dt><span class="term"><span><strong class="command">pubkey</strong></span></span></dt>
-<dd><p>
-                    In <acronym class="acronym">BIND</acronym> 8, this option was
-                    intended for specifying
-                    a public zone key for verification of signatures in DNSSEC
-                    signed
-                    zones when they are loaded from disk. <acronym class="acronym">BIND</acronym> 9 does not verify signatures
-                    on load and ignores the option.
-                  </p></dd>
-<dt><span class="term"><span><strong class="command">zone-statistics</strong></span></span></dt>
-<dd><p>
-                    If <strong class="userinput"><code>yes</code></strong>, the server will keep
-                    statistical
-                    information for this zone, which can be dumped to the
-                    <span><strong class="command">statistics-file</strong></span> defined in
-                    the server options.
-                  </p></dd>
-<dt><span class="term"><span><strong class="command">sig-validity-interval</strong></span></span></dt>
-<dd><p>
-                    See the description of
-                    <span><strong class="command">sig-validity-interval</strong></span> in <a href="Bv9ARM.ch06.html#tuning" title="Tuning">the section called &#8220;Tuning&#8221;</a>.
-                  </p></dd>
-<dt><span class="term"><span><strong class="command">transfer-source</strong></span></span></dt>
-<dd><p>
-                    See the description of
-                    <span><strong class="command">transfer-source</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>.
-                  </p></dd>
-<dt><span class="term"><span><strong class="command">transfer-source-v6</strong></span></span></dt>
-<dd><p>
-                    See the description of
-                    <span><strong class="command">transfer-source-v6</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>.
-                  </p></dd>
-<dt><span class="term"><span><strong class="command">alt-transfer-source</strong></span></span></dt>
-<dd><p>
-                    See the description of
-                    <span><strong class="command">alt-transfer-source</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>.
-                  </p></dd>
-<dt><span class="term"><span><strong class="command">alt-transfer-source-v6</strong></span></span></dt>
-<dd><p>
-                    See the description of
-                    <span><strong class="command">alt-transfer-source-v6</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>.
-                  </p></dd>
-<dt><span class="term"><span><strong class="command">use-alt-transfer-source</strong></span></span></dt>
-<dd><p>
-                    See the description of
-                    <span><strong class="command">use-alt-transfer-source</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>.
-                  </p></dd>
-<dt><span class="term"><span><strong class="command">notify-source</strong></span></span></dt>
-<dd><p>
-                    See the description of
-                    <span><strong class="command">notify-source</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>.
-                  </p></dd>
-<dt><span class="term"><span><strong class="command">notify-source-v6</strong></span></span></dt>
-<dd><p>
-                    See the description of
-                    <span><strong class="command">notify-source-v6</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>.
-                  </p></dd>
-<dt>
-<span class="term"><span><strong class="command">min-refresh-time</strong></span>, </span><span class="term"><span><strong class="command">max-refresh-time</strong></span>, </span><span class="term"><span><strong class="command">min-retry-time</strong></span>, </span><span class="term"><span><strong class="command">max-retry-time</strong></span></span>
-</dt>
-<dd><p>
-                    See the description in <a href="Bv9ARM.ch06.html#tuning" title="Tuning">the section called &#8220;Tuning&#8221;</a>.
-                  </p></dd>
-<dt><span class="term"><span><strong class="command">ixfr-from-differences</strong></span></span></dt>
-<dd><p>
-                    See the description of
-                    <span><strong class="command">ixfr-from-differences</strong></span> in <a href="Bv9ARM.ch06.html#boolean_options" title="Boolean Options">the section called &#8220;Boolean Options&#8221;</a>.
-                  </p></dd>
-<dt><span class="term"><span><strong class="command">key-directory</strong></span></span></dt>
-<dd><p>
-                    See the description of
-                    <span><strong class="command">key-directory</strong></span> in <a href="Bv9ARM.ch06.html#options" title="options Statement Definition and
-          Usage">the section called &#8220;<span><strong class="command">options</strong></span> Statement Definition and
-          Usage&#8221;</a>.
-                  </p></dd>
-<dt><span class="term"><span><strong class="command">multi-master</strong></span></span></dt>
-<dd><p>
-                    See the description of <span><strong class="command">multi-master</strong></span> in
-                    <a href="Bv9ARM.ch06.html#boolean_options" title="Boolean Options">the section called &#8220;Boolean Options&#8221;</a>.
-                  </p></dd>
-<dt><span class="term"><span><strong class="command">masterfile-format</strong></span></span></dt>
-<dd><p>
-                    See the description of <span><strong class="command">masterfile-format</strong></span>
-                    in <a href="Bv9ARM.ch06.html#tuning" title="Tuning">the section called &#8220;Tuning&#8221;</a>.
-                  </p></dd>
-</dl></div>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="dynamic_update_policies"></a>Dynamic Update Policies</h4></div></div></div>
-<p>
-              <acronym class="acronym">BIND</acronym> 9 supports two alternative
-              methods of granting clients
-              the right to perform dynamic updates to a zone,
-              configured by the <span><strong class="command">allow-update</strong></span>
-              and
-              <span><strong class="command">update-policy</strong></span> option,
-              respectively.
-            </p>
-<p>
-              The <span><strong class="command">allow-update</strong></span> clause works the
-              same
-              way as in previous versions of <acronym class="acronym">BIND</acronym>. It grants given clients the
-              permission to update any record of any name in the zone.
-            </p>
-<p>
-              The <span><strong class="command">update-policy</strong></span> clause is new
-              in <acronym class="acronym">BIND</acronym>
-              9 and allows more fine-grained control over what updates are
-              allowed.
-              A set of rules is specified, where each rule either grants or
-              denies
-              permissions for one or more names to be updated by one or more
-              identities.
-              If the dynamic update request message is signed (that is, it
-              includes
-              either a TSIG or SIG(0) record), the identity of the signer can
-              be determined.
-            </p>
-<p>
-              Rules are specified in the <span><strong class="command">update-policy</strong></span> zone
-              option, and are only meaningful for master zones.  When the <span><strong class="command">update-policy</strong></span> statement
-              is present, it is a configuration error for the <span><strong class="command">allow-update</strong></span> statement
-              to be present.  The <span><strong class="command">update-policy</strong></span>
-              statement only
-              examines the signer of a message; the source address is not
-              relevant.
-            </p>
-<p>
-              This is how a rule definition looks:
-            </p>
-<pre class="programlisting">
-( <span><strong class="command">grant</strong></span> | <span><strong class="command">deny</strong></span> ) <em class="replaceable"><code>identity</code></em> <em class="replaceable"><code>nametype</code></em> <em class="replaceable"><code>name</code></em> [<span class="optional"> <em class="replaceable"><code>types</code></em> </span>]
-</pre>
-<p>
-              Each rule grants or denies privileges.  Once a message has
-              successfully matched a rule, the operation is immediately
-              granted
-              or denied and no further rules are examined.  A rule is matched
-              when the signer matches the identity field, the name matches the
-              name field in accordance with the nametype field, and the type
-              matches
-              the types specified in the type field.
-            </p>
-<p>
-              The identity field specifies a name or a wildcard name.
-              Normally, this
-              is the name of the TSIG or SIG(0) key used to sign the update
-              request.  When a
-              TKEY exchange has been used to create a shared secret, the
-              identity of the
-              shared secret is the same as the identity of the key used to
-              authenticate the
-              TKEY exchange.  When the <em class="replaceable"><code>identity</code></em> field specifies a
-              wildcard name, it is subject to DNS wildcard expansion, so the
-              rule will apply
-              to multiple identities.  The <em class="replaceable"><code>identity</code></em> field must
-              contain a fully-qualified domain name.
-            </p>
-<p>
-              The <em class="replaceable"><code>nametype</code></em> field has 6
-              values:
-              <code class="varname">name</code>, <code class="varname">subdomain</code>,
-              <code class="varname">wildcard</code>, <code class="varname">self</code>,
-               <code class="varname">selfsub</code>, and <code class="varname">selfwild</code>.
-            </p>
-<div class="informaltable"><table border="1">
-<colgroup>
-<col>
-<col>
-</colgroup>
-<tbody>
-<tr>
-<td>
-                      <p>
-                        <code class="varname">name</code>
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        Exact-match semantics.  This rule matches
-                        when the name being updated is identical
-                        to the contents of the
-                        <em class="replaceable"><code>name</code></em> field.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        <code class="varname">subdomain</code>
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        This rule matches when the name being updated
-                        is a subdomain of, or identical to, the
-                        contents of the <em class="replaceable"><code>name</code></em>
-                        field.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        <code class="varname">wildcard</code>
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        The <em class="replaceable"><code>name</code></em> field
-                        is subject to DNS wildcard expansion, and
-                        this rule matches when the name being updated
-                        name is a valid expansion of the wildcard.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        <code class="varname">self</code>
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        This rule matches when the name being updated
-                        matches the contents of the
-                        <em class="replaceable"><code>identity</code></em> field.
-                        The <em class="replaceable"><code>name</code></em> field
-                        is ignored, but should be the same as the
-                        <em class="replaceable"><code>identity</code></em> field.
-                        The <code class="varname">self</code> nametype is
-                        most useful when allowing using one key per
-                        name to update, where the key has the same
-                        name as the name to be updated.  The
-                        <em class="replaceable"><code>identity</code></em> would
-                        be specified as <code class="constant">*</code> (an asterisk) in
-                        this case.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        <code class="varname">selfsub</code>
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        This rule is similar to <code class="varname">self</code>
-                        except that subdomains of <code class="varname">self</code>
-                        can also be updated.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        <code class="varname">selfwild</code>
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        This rule is similar to <code class="varname">self</code>
-                        except that only subdomains of
-                        <code class="varname">self</code> can be updated.
-                      </p>
-                    </td>
-</tr>
-</tbody>
-</table></div>
-<p>
-              In all cases, the <em class="replaceable"><code>name</code></em>
-              field must
-              specify a fully-qualified domain name.
-            </p>
-<p>
-              If no types are explicitly specified, this rule matches all
-              types except
-              RRSIG, NS, SOA, and NSEC. Types may be specified by name, including
-              "ANY" (ANY matches all types except NSEC, which can never be
-              updated).
-              Note that when an attempt is made to delete all records
-              associated with a
-              name, the rules are checked for each existing record type.
-            </p>
-</div>
-</div>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2589080"></a>Zone File</h2></div></div></div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="types_of_resource_records_and_when_to_use_them"></a>Types of Resource Records and When to Use Them</h3></div></div></div>
-<p>
-            This section, largely borrowed from RFC 1034, describes the
-            concept of a Resource Record (RR) and explains when each is used.
-            Since the publication of RFC 1034, several new RRs have been
-            identified
-            and implemented in the DNS. These are also included.
-          </p>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2589098"></a>Resource Records</h4></div></div></div>
-<p>
-              A domain name identifies a node.  Each node has a set of
-              resource information, which may be empty.  The set of resource
-              information associated with a particular name is composed of
-              separate RRs. The order of RRs in a set is not significant and
-              need not be preserved by name servers, resolvers, or other
-              parts of the DNS. However, sorting of multiple RRs is
-              permitted for optimization purposes, for example, to specify
-              that a particular nearby server be tried first. See <a href="Bv9ARM.ch06.html#the_sortlist_statement" title="The sortlist Statement">the section called &#8220;The <span><strong class="command">sortlist</strong></span> Statement&#8221;</a> and <a href="Bv9ARM.ch06.html#rrset_ordering" title="RRset Ordering">the section called &#8220;RRset Ordering&#8221;</a>.
-            </p>
-<p>
-              The components of a Resource Record are:
-            </p>
-<div class="informaltable"><table border="1">
-<colgroup>
-<col>
-<col>
-</colgroup>
-<tbody>
-<tr>
-<td>
-                      <p>
-                        owner name
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        The domain name where the RR is found.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        type
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        An encoded 16-bit value that specifies
-                        the type of the resource record.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        TTL
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        The time-to-live of the RR. This field
-                        is a 32-bit integer in units of seconds, and is
-                        primarily used by
-                        resolvers when they cache RRs. The TTL describes how
-                        long a RR can
-                        be cached before it should be discarded.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        class
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        An encoded 16-bit value that identifies
-                        a protocol family or instance of a protocol.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        RDATA
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        The resource data.  The format of the
-                        data is type (and sometimes class) specific.
-                      </p>
-                    </td>
-</tr>
-</tbody>
-</table></div>
-<p>
-              The following are <span class="emphasis"><em>types</em></span> of valid RRs:
-            </p>
-<div class="informaltable"><table border="1">
-<colgroup>
-<col>
-<col>
-</colgroup>
-<tbody>
-<tr>
-<td>
-                      <p>
-                        A
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        A host address.  In the IN class, this is a
-                        32-bit IP address.  Described in RFC 1035.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        AAAA
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        IPv6 address.  Described in RFC 1886.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        A6
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        IPv6 address.  This can be a partial
-                        address (a suffix) and an indirection to the name
-                        where the rest of the
-                        address (the prefix) can be found.  Experimental.
-                        Described in RFC 2874.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        AFSDB
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        Location of AFS database servers.
-                        Experimental.  Described in RFC 1183.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        APL
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        Address prefix list.  Experimental.
-                        Described in RFC 3123.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        CERT
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        Holds a digital certificate.
-                        Described in RFC 2538.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        CNAME
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        Identifies the canonical name of an alias.
-                        Described in RFC 1035.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        DNAME
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        Replaces the domain name specified with
-                        another name to be looked up, effectively aliasing an
-                        entire
-                        subtree of the domain name space rather than a single
-                        record
-                        as in the case of the CNAME RR.
-                        Described in RFC 2672.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        DNSKEY
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        Stores a public key associated with a signed
-                        DNS zone.  Described in RFC 4034.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        DS
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        Stores the hash of a public key associated with a
-                        signed DNS zone.  Described in RFC 4034.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        GPOS
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        Specifies the global position.  Superseded by LOC.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        HINFO
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        Identifies the CPU and OS used by a host.
-                        Described in RFC 1035.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        ISDN
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        Representation of ISDN addresses.
-                        Experimental.  Described in RFC 1183.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        KEY
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        Stores a public key associated with a
-                        DNS name.  Used in original DNSSEC; replaced
-                        by DNSKEY in DNSSECbis, but still used with
-                        SIG(0).  Described in RFCs 2535 and 2931.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        KX
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        Identifies a key exchanger for this
-                        DNS name.  Described in RFC 2230.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        LOC
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        For storing GPS info.  Described in RFC 1876.
-                        Experimental.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        MX
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        Identifies a mail exchange for the domain with
-                        a 16-bit preference value (lower is better)
-                        followed by the host name of the mail exchange.
-                        Described in RFC 974, RFC 1035.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        NAPTR
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        Name authority pointer.  Described in RFC 2915.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        NSAP
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        A network service access point.
-                        Described in RFC 1706.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        NS
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        The authoritative name server for the
-                        domain.  Described in RFC 1035.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        NSEC
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        Used in DNSSECbis to securely indicate that
-                        RRs with an owner name in a certain name interval do
-                        not exist in
-                        a zone and indicate what RR types are present for an
-                        existing name.
-                        Described in RFC 4034.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        NXT
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        Used in DNSSEC to securely indicate that
-                        RRs with an owner name in a certain name interval do
-                        not exist in
-                        a zone and indicate what RR types are present for an
-                        existing name.
-                        Used in original DNSSEC; replaced by NSEC in
-                        DNSSECbis.
-                        Described in RFC 2535.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        PTR
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        A pointer to another part of the domain
-                        name space.  Described in RFC 1035.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        PX
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        Provides mappings between RFC 822 and X.400
-                        addresses.  Described in RFC 2163.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        RP
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        Information on persons responsible
-                        for the domain.  Experimental.  Described in RFC 1183.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        RRSIG
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        Contains DNSSECbis signature data.  Described
-                        in RFC 4034.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        RT
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        Route-through binding for hosts that
-                        do not have their own direct wide area network
-                        addresses.
-                        Experimental.  Described in RFC 1183.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        SIG
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        Contains DNSSEC signature data.  Used in
-                        original DNSSEC; replaced by RRSIG in
-                        DNSSECbis, but still used for SIG(0).
-                        Described in RFCs 2535 and 2931.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        SOA
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        Identifies the start of a zone of authority.
-                        Described in RFC 1035.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        SRV
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        Information about well known network
-                        services (replaces WKS).  Described in RFC 2782.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        TXT
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        Text records.  Described in RFC 1035.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        WKS
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        Information about which well known
-                        network services, such as SMTP, that a domain
-                        supports. Historical.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        X25
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        Representation of X.25 network addresses.
-                        Experimental.  Described in RFC 1183.
-                      </p>
-                    </td>
-</tr>
-</tbody>
-</table></div>
-<p>
-              The following <span class="emphasis"><em>classes</em></span> of resource records
-              are currently valid in the DNS:
-            </p>
-<div class="informaltable"><table border="1">
-<colgroup>
-<col>
-<col>
-</colgroup>
-<tbody>
-<tr>
-<td>
-                      <p>
-                        IN
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        The Internet.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        CH
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        Chaosnet, a LAN protocol created at MIT in the
-                        mid-1970s.
-                        Rarely used for its historical purpose, but reused for
-                        BIND's
-                        built-in server information zones, e.g.,
-                        <code class="literal">version.bind</code>.
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        HS
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        Hesiod, an information service
-                        developed by MIT's Project Athena. It is used to share
-                        information
-                        about various systems databases, such as users,
-                        groups, printers
-                        and so on.
-                      </p>
-                    </td>
-</tr>
-</tbody>
-</table></div>
-<p>
-              The owner name is often implicit, rather than forming an
-              integral
-              part of the RR.  For example, many name servers internally form
-              tree
-              or hash structures for the name space, and chain RRs off nodes.
-              The remaining RR parts are the fixed header (type, class, TTL)
-              which is consistent for all RRs, and a variable part (RDATA)
-              that
-              fits the needs of the resource being described.
-            </p>
-<p>
-              The meaning of the TTL field is a time limit on how long an
-              RR can be kept in a cache.  This limit does not apply to
-              authoritative
-              data in zones; it is also timed out, but by the refreshing
-              policies
-              for the zone.  The TTL is assigned by the administrator for the
-              zone where the data originates.  While short TTLs can be used to
-              minimize caching, and a zero TTL prohibits caching, the
-              realities
-              of Internet performance suggest that these times should be on
-              the
-              order of days for the typical host.  If a change can be
-              anticipated,
-              the TTL can be reduced prior to the change to minimize
-              inconsistency
-              during the change, and then increased back to its former value
-              following
-              the change.
-            </p>
-<p>
-              The data in the RDATA section of RRs is carried as a combination
-              of binary strings and domain names.  The domain names are
-              frequently
-              used as "pointers" to other data in the DNS.
-            </p>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2590513"></a>Textual expression of RRs</h4></div></div></div>
-<p>
-              RRs are represented in binary form in the packets of the DNS
-              protocol, and are usually represented in highly encoded form
-              when
-              stored in a name server or resolver.  In the examples provided
-              in
-              RFC 1034, a style similar to that used in master files was
-              employed
-              in order to show the contents of RRs.  In this format, most RRs
-              are shown on a single line, although continuation lines are
-              possible
-              using parentheses.
-            </p>
-<p>
-              The start of the line gives the owner of the RR.  If a line
-              begins with a blank, then the owner is assumed to be the same as
-              that of the previous RR.  Blank lines are often included for
-              readability.
-            </p>
-<p>
-              Following the owner, we list the TTL, type, and class of the
-              RR.  Class and type use the mnemonics defined above, and TTL is
-              an integer before the type field.  In order to avoid ambiguity
-              in
-              parsing, type and class mnemonics are disjoint, TTLs are
-              integers,
-              and the type mnemonic is always last. The IN class and TTL
-              values
-              are often omitted from examples in the interests of clarity.
-            </p>
-<p>
-              The resource data or RDATA section of the RR are given using
-              knowledge of the typical representation for the data.
-            </p>
-<p>
-              For example, we might show the RRs carried in a message as:
-            </p>
-<div class="informaltable"><table border="1">
-<colgroup>
-<col>
-<col>
-<col>
-</colgroup>
-<tbody>
-<tr>
-<td>
-                      <p>
-                        <code class="literal">ISI.EDU.</code>
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        <code class="literal">MX</code>
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        <code class="literal">10 VENERA.ISI.EDU.</code>
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p></p>
-                    </td>
-<td>
-                      <p>
-                        <code class="literal">MX</code>
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        <code class="literal">10 VAXA.ISI.EDU</code>
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        <code class="literal">VENERA.ISI.EDU</code>
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        <code class="literal">A</code>
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        <code class="literal">128.9.0.32</code>
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p></p>
-                    </td>
-<td>
-                      <p>
-                        <code class="literal">A</code>
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        <code class="literal">10.1.0.52</code>
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p>
-                        <code class="literal">VAXA.ISI.EDU</code>
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        <code class="literal">A</code>
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        <code class="literal">10.2.0.27</code>
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td>
-                      <p></p>
-                    </td>
-<td>
-                      <p>
-                        <code class="literal">A</code>
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        <code class="literal">128.9.0.33</code>
-                      </p>
-                    </td>
-</tr>
-</tbody>
-</table></div>
-<p>
-              The MX RRs have an RDATA section which consists of a 16-bit
-              number followed by a domain name.  The address RRs use a
-              standard
-              IP address format to contain a 32-bit internet address.
-            </p>
-<p>
-              The above example shows six RRs, with two RRs at each of three
-              domain names.
-            </p>
-<p>
-              Similarly we might see:
-            </p>
-<div class="informaltable"><table border="1">
-<colgroup>
-<col>
-<col>
-<col>
-</colgroup>
-<tbody>
-<tr>
-<td>
-                      <p>
-                        <code class="literal">XX.LCS.MIT.EDU.</code>
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        <code class="literal">IN A</code>
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        <code class="literal">10.0.0.44</code>
-                      </p>
-                    </td>
-</tr>
-<tr>
-<td> </td>
-<td>
-                      <p>
-                        <code class="literal">CH A</code>
-                      </p>
-                    </td>
-<td>
-                      <p>
-                        <code class="literal">MIT.EDU. 2420</code>
-                      </p>
-                    </td>
-</tr>
-</tbody>
-</table></div>
-<p>
-              This example shows two addresses for
-              <code class="literal">XX.LCS.MIT.EDU</code>, each of a different class.
-            </p>
-</div>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2591101"></a>Discussion of MX Records</h3></div></div></div>
-<p>
-            As described above, domain servers store information as a
-            series of resource records, each of which contains a particular
-            piece of information about a given domain name (which is usually,
-            but not always, a host). The simplest way to think of a RR is as
-            a typed pair of data, a domain name matched with a relevant datum,
-            and stored with some additional type information to help systems
-            determine when the RR is relevant.
-          </p>
-<p>
-            MX records are used to control delivery of email. The data
-            specified in the record is a priority and a domain name. The
-            priority
-            controls the order in which email delivery is attempted, with the
-            lowest number first. If two priorities are the same, a server is
-            chosen randomly. If no servers at a given priority are responding,
-            the mail transport agent will fall back to the next largest
-            priority.
-            Priority numbers do not have any absolute meaning &#8212; they are
-            relevant
-            only respective to other MX records for that domain name. The
-            domain
-            name given is the machine to which the mail will be delivered.
-            It <span class="emphasis"><em>must</em></span> have an associated address record
-            (A or AAAA) &#8212; CNAME is not sufficient.
-          </p>
-<p>
-            For a given domain, if there is both a CNAME record and an
-            MX record, the MX record is in error, and will be ignored.
-            Instead,
-            the mail will be delivered to the server specified in the MX
-            record
-            pointed to by the CNAME.
-          </p>
-<p>
-            For example:
-          </p>
-<div class="informaltable"><table border="1">
-<colgroup>
-<col>
-<col>
-<col>
-<col>
-<col>
-</colgroup>
-<tbody>
-<tr>
-<td>
-                    <p>
-                      <code class="literal">example.com.</code>
-                    </p>
-                  </td>
-<td>
-                    <p>
-                      <code class="literal">IN</code>
-                    </p>
-                  </td>
-<td>
-                    <p>
-                      <code class="literal">MX</code>
-                    </p>
-                  </td>
-<td>
-                    <p>
-                      <code class="literal">10</code>
-                    </p>
-                  </td>
-<td>
-                    <p>
-                      <code class="literal">mail.example.com.</code>
-                    </p>
-                  </td>
-</tr>
-<tr>
-<td>
-                    <p></p>
-                  </td>
-<td>
-                    <p>
-                      <code class="literal">IN</code>
-                    </p>
-                  </td>
-<td>
-                    <p>
-                      <code class="literal">MX</code>
-                    </p>
-                  </td>
-<td>
-                    <p>
-                      <code class="literal">10</code>
-                    </p>
-                  </td>
-<td>
-                    <p>
-                      <code class="literal">mail2.example.com.</code>
-                    </p>
-                  </td>
-</tr>
-<tr>
-<td>
-                    <p></p>
-                  </td>
-<td>
-                    <p>
-                      <code class="literal">IN</code>
-                    </p>
-                  </td>
-<td>
-                    <p>
-                      <code class="literal">MX</code>
-                    </p>
-                  </td>
-<td>
-                    <p>
-                      <code class="literal">20</code>
-                    </p>
-                  </td>
-<td>
-                    <p>
-                      <code class="literal">mail.backup.org.</code>
-                    </p>
-                  </td>
-</tr>
-<tr>
-<td>
-                    <p>
-                      <code class="literal">mail.example.com.</code>
-                    </p>
-                  </td>
-<td>
-                    <p>
-                      <code class="literal">IN</code>
-                    </p>
-                  </td>
-<td>
-                    <p>
-                      <code class="literal">A</code>
-                    </p>
-                  </td>
-<td>
-                    <p>
-                      <code class="literal">10.0.0.1</code>
-                    </p>
-                  </td>
-<td>
-                    <p></p>
-                  </td>
-</tr>
-<tr>
-<td>
-                    <p>
-                      <code class="literal">mail2.example.com.</code>
-                    </p>
-                  </td>
-<td>
-                    <p>
-                      <code class="literal">IN</code>
-                    </p>
-                  </td>
-<td>
-                    <p>
-                      <code class="literal">A</code>
-                    </p>
-                  </td>
-<td>
-                    <p>
-                      <code class="literal">10.0.0.2</code>
-                    </p>
-                  </td>
-<td>
-                    <p></p>
-                  </td>
-</tr>
-</tbody>
-</table></div>
-<p>
-            Mail delivery will be attempted to <code class="literal">mail.example.com</code> and
-            <code class="literal">mail2.example.com</code> (in
-            any order), and if neither of those succeed, delivery to <code class="literal">mail.backup.org</code> will
-            be attempted.
-          </p>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="Setting_TTLs"></a>Setting TTLs</h3></div></div></div>
-<p>
-            The time-to-live of the RR field is a 32-bit integer represented
-            in units of seconds, and is primarily used by resolvers when they
-            cache RRs. The TTL describes how long a RR can be cached before it
-            should be discarded. The following three types of TTL are
-            currently
-            used in a zone file.
-          </p>
-<div class="informaltable"><table border="1">
-<colgroup>
-<col>
-<col>
-</colgroup>
-<tbody>
-<tr>
-<td>
-                    <p>
-                      SOA
-                    </p>
-                  </td>
-<td>
-                    <p>
-                      The last field in the SOA is the negative
-                      caching TTL. This controls how long other servers will
-                      cache no-such-domain
-                      (NXDOMAIN) responses from you.
-                    </p>
-                    <p>
-                      The maximum time for
-                      negative caching is 3 hours (3h).
-                    </p>
-                  </td>
-</tr>
-<tr>
-<td>
-                    <p>
-                      $TTL
-                    </p>
-                  </td>
-<td>
-                    <p>
-                      The $TTL directive at the top of the
-                      zone file (before the SOA) gives a default TTL for every
-                      RR without
-                      a specific TTL set.
-                    </p>
-                  </td>
-</tr>
-<tr>
-<td>
-                    <p>
-                      RR TTLs
-                    </p>
-                  </td>
-<td>
-                    <p>
-                      Each RR can have a TTL as the second
-                      field in the RR, which will control how long other
-                      servers can cache
-                      the it.
-                    </p>
-                  </td>
-</tr>
-</tbody>
-</table></div>
-<p>
-            All of these TTLs default to units of seconds, though units
-            can be explicitly specified, for example, <code class="literal">1h30m</code>.
-          </p>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2591653"></a>Inverse Mapping in IPv4</h3></div></div></div>
-<p>
-            Reverse name resolution (that is, translation from IP address
-            to name) is achieved by means of the <span class="emphasis"><em>in-addr.arpa</em></span> domain
-            and PTR records. Entries in the in-addr.arpa domain are made in
-            least-to-most significant order, read left to right. This is the
-            opposite order to the way IP addresses are usually written. Thus,
-            a machine with an IP address of 10.1.2.3 would have a
-            corresponding
-            in-addr.arpa name of
-            3.2.1.10.in-addr.arpa. This name should have a PTR resource record
-            whose data field is the name of the machine or, optionally,
-            multiple
-            PTR records if the machine has more than one name. For example,
-            in the [<span class="optional">example.com</span>] domain:
-          </p>
-<div class="informaltable"><table border="1">
-<colgroup>
-<col>
-<col>
-</colgroup>
-<tbody>
-<tr>
-<td>
-                    <p>
-                      <code class="literal">$ORIGIN</code>
-                    </p>
-                  </td>
-<td>
-                    <p>
-                      <code class="literal">2.1.10.in-addr.arpa</code>
-                    </p>
-                  </td>
-</tr>
-<tr>
-<td>
-                    <p>
-                      <code class="literal">3</code>
-                    </p>
-                  </td>
-<td>
-                    <p>
-                      <code class="literal">IN PTR foo.example.com.</code>
-                    </p>
-                  </td>
-</tr>
-</tbody>
-</table></div>
-<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-<p>
-              The <span><strong class="command">$ORIGIN</strong></span> lines in the examples
-              are for providing context to the examples only &#8212; they do not
-              necessarily
-              appear in the actual usage. They are only used here to indicate
-              that the example is relative to the listed origin.
-            </p>
-</div>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2591848"></a>Other Zone File Directives</h3></div></div></div>
-<p>
-            The Master File Format was initially defined in RFC 1035 and
-            has subsequently been extended. While the Master File Format
-            itself
-            is class independent all records in a Master File must be of the
-            same
-            class.
-          </p>
-<p>
-            Master File Directives include <span><strong class="command">$ORIGIN</strong></span>, <span><strong class="command">$INCLUDE</strong></span>,
-            and <span><strong class="command">$TTL.</strong></span>
-          </p>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2591870"></a>The <span><strong class="command">$ORIGIN</strong></span> Directive</h4></div></div></div>
-<p>
-              Syntax: <span><strong class="command">$ORIGIN</strong></span>
-              <em class="replaceable"><code>domain-name</code></em>
-              [<span class="optional"><em class="replaceable"><code>comment</code></em></span>]
-            </p>
-<p><span><strong class="command">$ORIGIN</strong></span>
-              sets the domain name that will be appended to any
-              unqualified records. When a zone is first read in there
-              is an implicit <span><strong class="command">$ORIGIN</strong></span>
-              &lt;<code class="varname">zone-name</code>&gt;<span><strong class="command">.</strong></span>
-              The current <span><strong class="command">$ORIGIN</strong></span> is appended to
-              the domain specified in the <span><strong class="command">$ORIGIN</strong></span>
-              argument if it is not absolute.
-            </p>
-<pre class="programlisting">
-$ORIGIN example.com.
-WWW     CNAME   MAIN-SERVER
-</pre>
-<p>
-              is equivalent to
-            </p>
-<pre class="programlisting">
-WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.
-</pre>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2592000"></a>The <span><strong class="command">$INCLUDE</strong></span> Directive</h4></div></div></div>
-<p>
-              Syntax: <span><strong class="command">$INCLUDE</strong></span>
-              <em class="replaceable"><code>filename</code></em>
-              [<span class="optional">
-<em class="replaceable"><code>origin</code></em> </span>]
-              [<span class="optional"> <em class="replaceable"><code>comment</code></em> </span>]
-            </p>
-<p>
-              Read and process the file <code class="filename">filename</code> as
-              if it were included into the file at this point.  If <span><strong class="command">origin</strong></span> is
-              specified the file is processed with <span><strong class="command">$ORIGIN</strong></span> set
-              to that value, otherwise the current <span><strong class="command">$ORIGIN</strong></span> is
-              used.
-            </p>
-<p>
-              The origin and the current domain name
-              revert to the values they had prior to the <span><strong class="command">$INCLUDE</strong></span> once
-              the file has been read.
-            </p>
-<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-<p>
-                RFC 1035 specifies that the current origin should be restored
-                after
-                an <span><strong class="command">$INCLUDE</strong></span>, but it is silent
-                on whether the current
-                domain name should also be restored.  BIND 9 restores both of
-                them.
-                This could be construed as a deviation from RFC 1035, a
-                feature, or both.
-              </p>
-</div>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2592069"></a>The <span><strong class="command">$TTL</strong></span> Directive</h4></div></div></div>
-<p>
-              Syntax: <span><strong class="command">$TTL</strong></span>
-              <em class="replaceable"><code>default-ttl</code></em>
-              [<span class="optional">
-<em class="replaceable"><code>comment</code></em> </span>]
-            </p>
-<p>
-              Set the default Time To Live (TTL) for subsequent records
-              with undefined TTLs. Valid TTLs are of the range 0-2147483647
-              seconds.
-            </p>
-<p><span><strong class="command">$TTL</strong></span>
-               is defined in RFC 2308.
-            </p>
-</div>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2592173"></a><acronym class="acronym">BIND</acronym> Master File Extension: the  <span><strong class="command">$GENERATE</strong></span> Directive</h3></div></div></div>
-<p>
-            Syntax: <span><strong class="command">$GENERATE</strong></span>
-            <em class="replaceable"><code>range</code></em>
-            <em class="replaceable"><code>lhs</code></em>
-            [<span class="optional"><em class="replaceable"><code>ttl</code></em></span>]
-            [<span class="optional"><em class="replaceable"><code>class</code></em></span>]
-            <em class="replaceable"><code>type</code></em>
-            <em class="replaceable"><code>rhs</code></em>
-            [<span class="optional"><em class="replaceable"><code>comment</code></em></span>]
-          </p>
-<p><span><strong class="command">$GENERATE</strong></span>
-            is used to create a series of resource records that only
-            differ from each other by an
-            iterator. <span><strong class="command">$GENERATE</strong></span> can be used to
-            easily generate the sets of records required to support
-            sub /24 reverse delegations described in RFC 2317:
-            Classless IN-ADDR.ARPA delegation.
-          </p>
-<pre class="programlisting">$ORIGIN 0.0.192.IN-ADDR.ARPA.
-$GENERATE 1-2 0 NS SERVER$.EXAMPLE.
-$GENERATE 1-127 $ CNAME $.0</pre>
-<p>
-            is equivalent to
-          </p>
-<pre class="programlisting">0.0.0.192.IN-ADDR.ARPA NS SERVER1.EXAMPLE.
-0.0.0.192.IN-ADDR.ARPA. NS SERVER2.EXAMPLE.
-1.0.0.192.IN-ADDR.ARPA. CNAME 1.0.0.0.192.IN-ADDR.ARPA.
-2.0.0.192.IN-ADDR.ARPA. CNAME 2.0.0.0.192.IN-ADDR.ARPA.
-...
-127.0.0.192.IN-ADDR.ARPA. CNAME 127.0.0.0.192.IN-ADDR.ARPA.
-</pre>
-<div class="informaltable"><table border="1">
-<colgroup>
-<col>
-<col>
-</colgroup>
-<tbody>
-<tr>
-<td>
-                    <p><span><strong class="command">range</strong></span></p>
-                  </td>
-<td>
-                    <p>
-                      This can be one of two forms: start-stop
-                      or start-stop/step. If the first form is used, then step
-                      is set to
-                      1. All of start, stop and step must be positive.
-                    </p>
-                  </td>
-</tr>
-<tr>
-<td>
-                    <p><span><strong class="command">lhs</strong></span></p>
-                  </td>
-<td>
-                    <p>This
-                      describes the owner name of the resource records
-                      to be created.  Any single <span><strong class="command">$</strong></span>
-                      (dollar sign)
-                      symbols within the <span><strong class="command">lhs</strong></span> side
-                      are replaced by the iterator value.
-
-                      To get a $ in the output, you need to escape the
-                      <span><strong class="command">$</strong></span> using a backslash
-                      <span><strong class="command">\</strong></span>,
-                      e.g. <span><strong class="command">\$</strong></span>. The
-                      <span><strong class="command">$</strong></span> may optionally be followed
-                      by modifiers which change the offset from the
-                      iterator, field width and base.
-
-                      Modifiers are introduced by a
-                      <span><strong class="command">{</strong></span> (left brace) immediately following the
-                      <span><strong class="command">$</strong></span> as
-                      <span><strong class="command">${offset[,width[,base]]}</strong></span>.
-                      For example, <span><strong class="command">${-20,3,d}</strong></span>
-                      subtracts 20 from the current value, prints the
-                      result as a decimal in a zero-padded field of
-                      width 3.
-
-                      Available output forms are decimal
-                      (<span><strong class="command">d</strong></span>), octal
-                      (<span><strong class="command">o</strong></span>) and hexadecimal
-                      (<span><strong class="command">x</strong></span> or <span><strong class="command">X</strong></span>
-                      for uppercase).  The default modifier is
-                      <span><strong class="command">${0,0,d}</strong></span>.  If the
-                      <span><strong class="command">lhs</strong></span> is not absolute, the
-                      current <span><strong class="command">$ORIGIN</strong></span> is appended
-                      to the name.
-                    </p>
-                    <p>
-                      For compatibility with earlier versions, <span><strong class="command">$$</strong></span> is still
-                      recognized as indicating a literal $ in the output.
-                    </p>
-                  </td>
-</tr>
-<tr>
-<td>
-                    <p><span><strong class="command">ttl</strong></span></p>
-                  </td>
-<td>
-                    <p>
-                      Specifies the time-to-live of the generated records. If
-                      not specified this will be inherited using the
-                      normal ttl inheritance rules.
-                    </p>
-                    <p><span><strong class="command">class</strong></span>
-                      and <span><strong class="command">ttl</strong></span> can be
-                      entered in either order.
-                    </p>
-                  </td>
-</tr>
-<tr>
-<td>
-                    <p><span><strong class="command">class</strong></span></p>
-                  </td>
-<td>
-                    <p>
-                      Specifies the class of the generated records.
-                      This must match the zone class if it is
-                      specified.
-                    </p>
-                    <p><span><strong class="command">class</strong></span>
-                      and <span><strong class="command">ttl</strong></span> can be
-                      entered in either order.
-                    </p>
-                  </td>
-</tr>
-<tr>
-<td>
-                    <p><span><strong class="command">type</strong></span></p>
-                  </td>
-<td>
-                    <p>
-                      At present the only supported types are
-                      PTR, CNAME, DNAME, A, AAAA and NS.
-                    </p>
-                  </td>
-</tr>
-<tr>
-<td>
-                    <p><span><strong class="command">rhs</strong></span></p>
-                  </td>
-<td>
-                    <p>
-                      <span><strong class="command">rhs</strong></span> is a domain name. It is processed
-                      similarly to lhs.
-                    </p>
-                  </td>
-</tr>
-</tbody>
-</table></div>
-<p>
-            The <span><strong class="command">$GENERATE</strong></span> directive is a <acronym class="acronym">BIND</acronym> extension
-            and not part of the standard zone file format.
-          </p>
-<p>
-            BIND 8 does not support the optional TTL and CLASS fields.
-          </p>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="zonefile_format"></a>Additional File Formats</h3></div></div></div>
-<p>
-            In addition to the standard textual format, BIND 9
-            supports the ability to read or dump to zone files in
-            other formats.  The <code class="constant">raw</code> format is
-            currently available as an additional format.  It is a
-            binary format representing BIND 9's internal data
-            structure directly, thereby remarkably improving the
-            loading time.
-          </p>
-<p>
-            For a primary server, a zone file in the
-            <code class="constant">raw</code> format is expected to be
-            generated from a textual zone file by the
-            <span><strong class="command">named-compilezone</strong></span> command.  For a
-            secondary server or for a dynamic zone, it is automatically
-            generated (if this format is specified by the
-            <span><strong class="command">masterfile-format</strong></span> option) when
-            <span><strong class="command">named</strong></span> dumps the zone contents after
-            zone transfer or when applying prior updates.
-          </p>
-<p>
-            If a zone file in a binary format needs manual modification,
-            it first must be converted to a textual form by the
-            <span><strong class="command">named-compilezone</strong></span> command.  All
-            necessary modification should go to the text file, which
-            should then be converted to the binary form by the
-            <span><strong class="command">named-compilezone</strong></span> command again.
-          </p>
-<p>
-             Although the <code class="constant">raw</code> format uses the
-             network byte order and avoids architecture-dependent
-             data alignment so that it is as much portable as
-             possible, it is primarily expected to be used inside
-             the same single system.  In order to export a zone
-             file in the <code class="constant">raw</code> format or make a
-             portable backup of the file, it is recommended to
-             convert the file to the standard textual representation.
-          </p>
-</div>
-</div>
-</div>
-<div class="navfooter">
-<hr>
-<table width="100%" summary="Navigation footer">
-<tr>
-<td width="40%" align="left">
-<a accesskey="p" href="Bv9ARM.ch05.html">Prev</a> </td>
-<td width="20%" align="center"> </td>
-<td width="40%" align="right"> <a accesskey="n" href="Bv9ARM.ch07.html">Next</a>
-</td>
-</tr>
-<tr>
-<td width="40%" align="left" valign="top">Chapter 5. The <acronym class="acronym">BIND</acronym> 9 Lightweight Resolver </td>
-<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
-<td width="40%" align="right" valign="top"> Chapter 7. <acronym class="acronym">BIND</acronym> 9 Security Considerations</td>
-</tr>
-</table>
-</div>
-</body>
-</html>
diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch07.html b/contrib/bind9/doc/arm/Bv9ARM.ch07.html
deleted file mode 100644
index 96acfe6..0000000
--- a/contrib/bind9/doc/arm/Bv9ARM.ch07.html
+++ /dev/null
@@ -1,253 +0,0 @@
-<!--
- - Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2000-2003 Internet Software Consortium.
- - 
- - Permission to use, copy, modify, and distribute this software for any
- - purpose with or without fee is hereby granted, provided that the above
- - copyright notice and this permission notice appear in all copies.
- - 
- - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
- - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- - PERFORMANCE OF THIS SOFTWARE.
--->
-<!-- $Id: Bv9ARM.ch07.html,v 1.75.18.63 2007/10/31 01:35:59 marka Exp $ -->
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>Chapter 7. BIND 9 Security Considerations</title>
-<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
-<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="prev" href="Bv9ARM.ch06.html" title="Chapter 6. BIND 9 Configuration Reference">
-<link rel="next" href="Bv9ARM.ch08.html" title="Chapter 8. Troubleshooting">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
-<div class="navheader">
-<table width="100%" summary="Navigation header">
-<tr><th colspan="3" align="center">Chapter 7. <acronym class="acronym">BIND</acronym> 9 Security Considerations</th></tr>
-<tr>
-<td width="20%" align="left">
-<a accesskey="p" href="Bv9ARM.ch06.html">Prev</a> </td>
-<th width="60%" align="center"> </th>
-<td width="20%" align="right"> <a accesskey="n" href="Bv9ARM.ch08.html">Next</a>
-</td>
-</tr>
-</table>
-<hr>
-</div>
-<div class="chapter" lang="en">
-<div class="titlepage"><div><div><h2 class="title">
-<a name="Bv9ARM.ch07"></a>Chapter 7. <acronym class="acronym">BIND</acronym> 9 Security Considerations</h2></div></div></div>
-<div class="toc">
-<p><b>Table of Contents</b></p>
-<dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch07.html#Access_Control_Lists">Access Control Lists</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch07.html#id2592714"><span><strong class="command">Chroot</strong></span> and <span><strong class="command">Setuid</strong></span></a></span></dt>
-<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2592791">The <span><strong class="command">chroot</strong></span> Environment</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2592851">Using the <span><strong class="command">setuid</strong></span> Function</a></span></dt>
-</dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch07.html#dynamic_update_security">Dynamic Update Security</a></span></dt>
-</dl>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="Access_Control_Lists"></a>Access Control Lists</h2></div></div></div>
-<p>
-          Access Control Lists (ACLs), are address match lists that
-          you can set up and nickname for future use in <span><strong class="command">allow-notify</strong></span>,
-          <span><strong class="command">allow-query</strong></span>, <span><strong class="command">allow-recursion</strong></span>,
-          <span><strong class="command">blackhole</strong></span>, <span><strong class="command">allow-transfer</strong></span>,
-          etc.
-        </p>
-<p>
-          Using ACLs allows you to have finer control over who can access
-          your name server, without cluttering up your config files with huge
-          lists of IP addresses.
-        </p>
-<p>
-          It is a <span class="emphasis"><em>good idea</em></span> to use ACLs, and to
-          control access to your server. Limiting access to your server by
-          outside parties can help prevent spoofing and denial of service (DoS) attacks against
-          your server.
-        </p>
-<p>
-          Here is an example of how to properly apply ACLs:
-        </p>
-<pre class="programlisting">
-// Set up an ACL named "bogusnets" that will block RFC1918 space
-// and some reserved space, which is commonly used in spoofing attacks.
-acl bogusnets {
-        0.0.0.0/8; 1.0.0.0/8; 2.0.0.0/8; 192.0.2.0/24; 224.0.0.0/3;
-        10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16;
-};
-
-// Set up an ACL called our-nets. Replace this with the real IP numbers.
-acl our-nets { x.x.x.x/24; x.x.x.x/21; };
-options {
-  ...
-  ...
-  allow-query { our-nets; };
-  allow-recursion { our-nets; };
-  ...
-  blackhole { bogusnets; };
-  ...
-};
-
-zone "example.com" {
-  type master;
-  file "m/example.com";
-  allow-query { any; };
-};
-</pre>
-<p>
-          This allows recursive queries of the server from the outside
-          unless recursion has been previously disabled.
-        </p>
-<p>
-          For more information on how to use ACLs to protect your server,
-          see the <span class="emphasis"><em>AUSCERT</em></span> advisory at:
-        </p>
-<p>
-          <a href="ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.dns_dos" target="_top">ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.dns_dos</a>
-        </p>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2592714"></a><span><strong class="command">Chroot</strong></span> and <span><strong class="command">Setuid</strong></span>
-</h2></div></div></div>
-<p>
-          On UNIX servers, it is possible to run <acronym class="acronym">BIND</acronym> in a <span class="emphasis"><em>chrooted</em></span> environment
-          (using the <span><strong class="command">chroot()</strong></span> function) by specifying the "<code class="option">-t</code>"
-          option. This can help improve system security by placing <acronym class="acronym">BIND</acronym> in
-          a "sandbox", which will limit the damage done if a server is
-          compromised.
-        </p>
-<p>
-          Another useful feature in the UNIX version of <acronym class="acronym">BIND</acronym> is the
-          ability to run the daemon as an unprivileged user ( <code class="option">-u</code> <em class="replaceable"><code>user</code></em> ).
-          We suggest running as an unprivileged user when using the <span><strong class="command">chroot</strong></span> feature.
-        </p>
-<p>
-          Here is an example command line to load <acronym class="acronym">BIND</acronym> in a <span><strong class="command">chroot</strong></span> sandbox,
-          <span><strong class="command">/var/named</strong></span>, and to run <span><strong class="command">named</strong></span> <span><strong class="command">setuid</strong></span> to
-          user 202:
-        </p>
-<p>
-          <strong class="userinput"><code>/usr/local/bin/named -u 202 -t /var/named</code></strong>
-        </p>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2592791"></a>The <span><strong class="command">chroot</strong></span> Environment</h3></div></div></div>
-<p>
-            In order for a <span><strong class="command">chroot</strong></span> environment
-            to
-            work properly in a particular directory
-            (for example, <code class="filename">/var/named</code>),
-            you will need to set up an environment that includes everything
-            <acronym class="acronym">BIND</acronym> needs to run.
-            From <acronym class="acronym">BIND</acronym>'s point of view, <code class="filename">/var/named</code> is
-            the root of the filesystem.  You will need to adjust the values of
-            options like
-            like <span><strong class="command">directory</strong></span> and <span><strong class="command">pid-file</strong></span> to account
-            for this.
-          </p>
-<p>
-            Unlike with earlier versions of BIND, you typically will
-            <span class="emphasis"><em>not</em></span> need to compile <span><strong class="command">named</strong></span>
-            statically nor install shared libraries under the new root.
-            However, depending on your operating system, you may need
-            to set up things like
-            <code class="filename">/dev/zero</code>,
-            <code class="filename">/dev/random</code>,
-            <code class="filename">/dev/log</code>, and
-            <code class="filename">/etc/localtime</code>.
-          </p>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2592851"></a>Using the <span><strong class="command">setuid</strong></span> Function</h3></div></div></div>
-<p>
-            Prior to running the <span><strong class="command">named</strong></span> daemon,
-            use
-            the <span><strong class="command">touch</strong></span> utility (to change file
-            access and
-            modification times) or the <span><strong class="command">chown</strong></span>
-            utility (to
-            set the user id and/or group id) on files
-            to which you want <acronym class="acronym">BIND</acronym>
-            to write.
-          </p>
-<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-            Note that if the <span><strong class="command">named</strong></span> daemon is running as an
-            unprivileged user, it will not be able to bind to new restricted
-            ports if the server is reloaded.
-          </div>
-</div>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="dynamic_update_security"></a>Dynamic Update Security</h2></div></div></div>
-<p>
-          Access to the dynamic
-          update facility should be strictly limited.  In earlier versions of
-          <acronym class="acronym">BIND</acronym>, the only way to do this was
-          based on the IP
-          address of the host requesting the update, by listing an IP address
-          or
-          network prefix in the <span><strong class="command">allow-update</strong></span>
-          zone option.
-          This method is insecure since the source address of the update UDP
-          packet
-          is easily forged.  Also note that if the IP addresses allowed by the
-          <span><strong class="command">allow-update</strong></span> option include the
-          address of a slave
-          server which performs forwarding of dynamic updates, the master can
-          be
-          trivially attacked by sending the update to the slave, which will
-          forward it to the master with its own source IP address causing the
-          master to approve it without question.
-        </p>
-<p>
-          For these reasons, we strongly recommend that updates be
-          cryptographically authenticated by means of transaction signatures
-          (TSIG).  That is, the <span><strong class="command">allow-update</strong></span>
-          option should
-          list only TSIG key names, not IP addresses or network
-          prefixes. Alternatively, the new <span><strong class="command">update-policy</strong></span>
-          option can be used.
-        </p>
-<p>
-          Some sites choose to keep all dynamically-updated DNS data
-          in a subdomain and delegate that subdomain to a separate zone. This
-          way, the top-level zone containing critical data such as the IP
-          addresses
-          of public web and mail servers need not allow dynamic update at
-          all.
-        </p>
-</div>
-</div>
-<div class="navfooter">
-<hr>
-<table width="100%" summary="Navigation footer">
-<tr>
-<td width="40%" align="left">
-<a accesskey="p" href="Bv9ARM.ch06.html">Prev</a> </td>
-<td width="20%" align="center"> </td>
-<td width="40%" align="right"> <a accesskey="n" href="Bv9ARM.ch08.html">Next</a>
-</td>
-</tr>
-<tr>
-<td width="40%" align="left" valign="top">Chapter 6. <acronym class="acronym">BIND</acronym> 9 Configuration Reference </td>
-<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
-<td width="40%" align="right" valign="top"> Chapter 8. Troubleshooting</td>
-</tr>
-</table>
-</div>
-</body>
-</html>
diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch08.html b/contrib/bind9/doc/arm/Bv9ARM.ch08.html
deleted file mode 100644
index a475378..0000000
--- a/contrib/bind9/doc/arm/Bv9ARM.ch08.html
+++ /dev/null
@@ -1,139 +0,0 @@
-<!--
- - Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2000-2003 Internet Software Consortium.
- - 
- - Permission to use, copy, modify, and distribute this software for any
- - purpose with or without fee is hereby granted, provided that the above
- - copyright notice and this permission notice appear in all copies.
- - 
- - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
- - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- - PERFORMANCE OF THIS SOFTWARE.
--->
-<!-- $Id: Bv9ARM.ch08.html,v 1.75.18.64 2007/10/31 01:35:59 marka Exp $ -->
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>Chapter 8. Troubleshooting</title>
-<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
-<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="prev" href="Bv9ARM.ch07.html" title="Chapter 7. BIND 9 Security Considerations">
-<link rel="next" href="Bv9ARM.ch09.html" title="Appendix A. Appendices">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
-<div class="navheader">
-<table width="100%" summary="Navigation header">
-<tr><th colspan="3" align="center">Chapter 8. Troubleshooting</th></tr>
-<tr>
-<td width="20%" align="left">
-<a accesskey="p" href="Bv9ARM.ch07.html">Prev</a> </td>
-<th width="60%" align="center"> </th>
-<td width="20%" align="right"> <a accesskey="n" href="Bv9ARM.ch09.html">Next</a>
-</td>
-</tr>
-</table>
-<hr>
-</div>
-<div class="chapter" lang="en">
-<div class="titlepage"><div><div><h2 class="title">
-<a name="Bv9ARM.ch08"></a>Chapter 8. Troubleshooting</h2></div></div></div>
-<div class="toc">
-<p><b>Table of Contents</b></p>
-<dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2592999">Common Problems</a></span></dt>
-<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch08.html#id2593004">It's not working; how can I figure out what's wrong?</a></span></dt></dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2593016">Incrementing and Changing the Serial Number</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2593033">Where Can I Get Help?</a></span></dt>
-</dl>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2592999"></a>Common Problems</h2></div></div></div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2593004"></a>It's not working; how can I figure out what's wrong?</h3></div></div></div>
-<p>
-            The best solution to solving installation and
-            configuration issues is to take preventative measures by setting
-            up logging files beforehand. The log files provide a
-            source of hints and information that can be used to figure out
-            what went wrong and how to fix the problem.
-          </p>
-</div>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2593016"></a>Incrementing and Changing the Serial Number</h2></div></div></div>
-<p>
-          Zone serial numbers are just numbers &#8212; they aren't
-          date related.  A lot of people set them to a number that
-          represents a date, usually of the form YYYYMMDDRR.
-          Occasionally they will make a mistake and set them to a
-          "date in the future" then try to correct them by setting
-          them to the "current date".  This causes problems because
-          serial numbers are used to indicate that a zone has been
-          updated.  If the serial number on the slave server is
-          lower than the serial number on the master, the slave
-          server will attempt to update its copy of the zone.
-        </p>
-<p>
-          Setting the serial number to a lower number on the master
-          server than the slave server means that the slave will not perform
-          updates to its copy of the zone.
-        </p>
-<p>
-          The solution to this is to add 2147483647 (2^31-1) to the
-          number, reload the zone and make sure all slaves have updated to
-          the new zone serial number, then reset the number to what you want
-          it to be, and reload the zone again.
-        </p>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2593033"></a>Where Can I Get Help?</h2></div></div></div>
-<p>
-          The Internet Systems Consortium
-          (<acronym class="acronym">ISC</acronym>) offers a wide range
-          of support and service agreements for <acronym class="acronym">BIND</acronym> and <acronym class="acronym">DHCP</acronym> servers. Four
-          levels of premium support are available and each level includes
-          support for all <acronym class="acronym">ISC</acronym> programs,
-          significant discounts on products
-          and training, and a recognized priority on bug fixes and
-          non-funded feature requests. In addition, <acronym class="acronym">ISC</acronym> offers a standard
-          support agreement package which includes services ranging from bug
-          fix announcements to remote support. It also includes training in
-          <acronym class="acronym">BIND</acronym> and <acronym class="acronym">DHCP</acronym>.
-        </p>
-<p>
-          To discuss arrangements for support, contact
-          <a href="mailto:info@isc.org" target="_top">info@isc.org</a> or visit the
-          <acronym class="acronym">ISC</acronym> web page at
-          <a href="http://www.isc.org/services/support/" target="_top">http://www.isc.org/services/support/</a>
-          to read more.
-        </p>
-</div>
-</div>
-<div class="navfooter">
-<hr>
-<table width="100%" summary="Navigation footer">
-<tr>
-<td width="40%" align="left">
-<a accesskey="p" href="Bv9ARM.ch07.html">Prev</a> </td>
-<td width="20%" align="center"> </td>
-<td width="40%" align="right"> <a accesskey="n" href="Bv9ARM.ch09.html">Next</a>
-</td>
-</tr>
-<tr>
-<td width="40%" align="left" valign="top">Chapter 7. <acronym class="acronym">BIND</acronym> 9 Security Considerations </td>
-<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
-<td width="40%" align="right" valign="top"> Appendix A. Appendices</td>
-</tr>
-</table>
-</div>
-</body>
-</html>
diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch09.html b/contrib/bind9/doc/arm/Bv9ARM.ch09.html
deleted file mode 100644
index 3c2e779..0000000
--- a/contrib/bind9/doc/arm/Bv9ARM.ch09.html
+++ /dev/null
@@ -1,630 +0,0 @@
-<!--
- - Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2000-2003 Internet Software Consortium.
- - 
- - Permission to use, copy, modify, and distribute this software for any
- - purpose with or without fee is hereby granted, provided that the above
- - copyright notice and this permission notice appear in all copies.
- - 
- - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
- - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- - PERFORMANCE OF THIS SOFTWARE.
--->
-<!-- $Id: Bv9ARM.ch09.html,v 1.75.18.66 2007/10/31 01:35:59 marka Exp $ -->
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>Appendix A. Appendices</title>
-<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
-<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="prev" href="Bv9ARM.ch08.html" title="Chapter 8. Troubleshooting">
-<link rel="next" href="Bv9ARM.ch10.html" title="Manual pages">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
-<div class="navheader">
-<table width="100%" summary="Navigation header">
-<tr><th colspan="3" align="center">Appendix A. Appendices</th></tr>
-<tr>
-<td width="20%" align="left">
-<a accesskey="p" href="Bv9ARM.ch08.html">Prev</a> </td>
-<th width="60%" align="center"> </th>
-<td width="20%" align="right"> <a accesskey="n" href="Bv9ARM.ch10.html">Next</a>
-</td>
-</tr>
-</table>
-<hr>
-</div>
-<div class="appendix" lang="en">
-<div class="titlepage"><div><div><h2 class="title">
-<a name="Bv9ARM.ch09"></a>Appendix A. Appendices</h2></div></div></div>
-<div class="toc">
-<p><b>Table of Contents</b></p>
-<dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2593300">Acknowledgments</a></span></dt>
-<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch09.html#historical_dns_information">A Brief History of the <acronym class="acronym">DNS</acronym> and <acronym class="acronym">BIND</acronym></a></span></dt></dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2593472">General <acronym class="acronym">DNS</acronym> Reference Information</a></span></dt>
-<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch09.html#ipv6addresses">IPv6 addresses (AAAA)</a></span></dt></dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch09.html#bibliography">Bibliography (and Suggested Reading)</a></span></dt>
-<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch09.html#rfcs">Request for Comments (RFCs)</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch09.html#internet_drafts">Internet Drafts</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2596683">Other Documents About <acronym class="acronym">BIND</acronym></a></span></dt>
-</dl></dd>
-</dl>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2593300"></a>Acknowledgments</h2></div></div></div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="historical_dns_information"></a>A Brief History of the <acronym class="acronym">DNS</acronym> and <acronym class="acronym">BIND</acronym>
-</h3></div></div></div>
-<p>
-            Although the "official" beginning of the Domain Name
-            System occurred in 1984 with the publication of RFC 920, the
-            core of the new system was described in 1983 in RFCs 882 and
-            883. From 1984 to 1987, the ARPAnet (the precursor to today's
-            Internet) became a testbed of experimentation for developing the
-            new naming/addressing scheme in a rapidly expanding,
-            operational network environment.  New RFCs were written and
-            published in 1987 that modified the original documents to
-            incorporate improvements based on the working model. RFC 1034,
-            "Domain Names-Concepts and Facilities", and RFC 1035, "Domain
-            Names-Implementation and Specification" were published and
-            became the standards upon which all <acronym class="acronym">DNS</acronym> implementations are
-            built.
-          </p>
-<p>
-            The first working domain name server, called "Jeeves", was
-            written in 1983-84 by Paul Mockapetris for operation on DEC
-            Tops-20
-            machines located at the University of Southern California's
-            Information
-            Sciences Institute (USC-ISI) and SRI International's Network
-            Information
-            Center (SRI-NIC). A <acronym class="acronym">DNS</acronym> server for
-            Unix machines, the Berkeley Internet
-            Name Domain (<acronym class="acronym">BIND</acronym>) package, was
-            written soon after by a group of
-            graduate students at the University of California at Berkeley
-            under
-            a grant from the US Defense Advanced Research Projects
-            Administration
-            (DARPA).
-          </p>
-<p>
-            Versions of <acronym class="acronym">BIND</acronym> through
-            4.8.3 were maintained by the Computer
-            Systems Research Group (CSRG) at UC Berkeley. Douglas Terry, Mark
-            Painter, David Riggle and Songnian Zhou made up the initial <acronym class="acronym">BIND</acronym>
-            project team. After that, additional work on the software package
-            was done by Ralph Campbell. Kevin Dunlap, a Digital Equipment
-            Corporation
-            employee on loan to the CSRG, worked on <acronym class="acronym">BIND</acronym> for 2 years, from 1985
-            to 1987. Many other people also contributed to <acronym class="acronym">BIND</acronym> development
-            during that time: Doug Kingston, Craig Partridge, Smoot
-            Carl-Mitchell,
-            Mike Muuss, Jim Bloom and Mike Schwartz. <acronym class="acronym">BIND</acronym> maintenance was subsequently
-            handled by Mike Karels and Øivind Kure.
-          </p>
-<p>
-            <acronym class="acronym">BIND</acronym> versions 4.9 and 4.9.1 were
-            released by Digital Equipment
-            Corporation (now Compaq Computer Corporation). Paul Vixie, then
-            a DEC employee, became <acronym class="acronym">BIND</acronym>'s
-            primary caretaker. He was assisted
-            by Phil Almquist, Robert Elz, Alan Barrett, Paul Albitz, Bryan
-            Beecher, Andrew
-            Partan, Andy Cherenson, Tom Limoncelli, Berthold Paffrath, Fuat
-            Baran, Anant Kumar, Art Harkin, Win Treese, Don Lewis, Christophe
-            Wolfhugel, and others.
-          </p>
-<p>
-            In 1994, <acronym class="acronym">BIND</acronym> version 4.9.2 was sponsored by
-            Vixie Enterprises. Paul
-            Vixie became <acronym class="acronym">BIND</acronym>'s principal
-            architect/programmer.
-          </p>
-<p>
-            <acronym class="acronym">BIND</acronym> versions from 4.9.3 onward
-            have been developed and maintained
-            by the Internet Systems Consortium and its predecessor,
-            the Internet Software Consortium,  with support being provided
-            by ISC's sponsors.
-          </p>
-<p>
-            As co-architects/programmers, Bob Halley and
-            Paul Vixie released the first production-ready version of
-            <acronym class="acronym">BIND</acronym> version 8 in May 1997.
-          </p>
-<p>
-            BIND version 9 was released in September 2000 and is a
-            major rewrite of nearly all aspects of the underlying
-            BIND architecture.
-          </p>
-<p>
-            BIND version 4 is officially deprecated and BIND version
-            8 development is considered maintenance-only in favor
-            of BIND version 9. No additional development is done
-            on BIND version 4 or BIND version 8 other than for
-            security-related patches.
-          </p>
-<p>
-            <acronym class="acronym">BIND</acronym> development work is made
-            possible today by the sponsorship
-            of several corporations, and by the tireless work efforts of
-            numerous individuals.
-          </p>
-</div>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2593472"></a>General <acronym class="acronym">DNS</acronym> Reference Information</h2></div></div></div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="ipv6addresses"></a>IPv6 addresses (AAAA)</h3></div></div></div>
-<p>
-            IPv6 addresses are 128-bit identifiers for interfaces and
-            sets of interfaces which were introduced in the <acronym class="acronym">DNS</acronym> to facilitate
-            scalable Internet routing. There are three types of addresses: <span class="emphasis"><em>Unicast</em></span>,
-            an identifier for a single interface;
-            <span class="emphasis"><em>Anycast</em></span>,
-            an identifier for a set of interfaces; and <span class="emphasis"><em>Multicast</em></span>,
-            an identifier for a set of interfaces. Here we describe the global
-            Unicast address scheme. For more information, see RFC 3587,
-            "Global Unicast Address Format."
-          </p>
-<p>
-            IPv6 unicast addresses consist of a
-            <span class="emphasis"><em>global routing prefix</em></span>, a
-            <span class="emphasis"><em>subnet identifier</em></span>, and an
-            <span class="emphasis"><em>interface identifier</em></span>.
-          </p>
-<p>
-            The global routing prefix is provided by the
-            upstream provider or ISP, and (roughly) corresponds to the
-            IPv4 <span class="emphasis"><em>network</em></span> section
-            of the address range.
-
-            The subnet identifier is for local subnetting, much the
-            same as subnetting an
-            IPv4 /16 network into /24 subnets.
-
-            The interface identifier is the address of an individual
-            interface on a given network; in IPv6, addresses belong to
-            interfaces rather than to machines.
-          </p>
-<p>
-            The subnetting capability of IPv6 is much more flexible than
-            that of IPv4: subnetting can be carried out on bit boundaries,
-            in much the same way as Classless InterDomain Routing
-            (CIDR), and the DNS PTR representation ("nibble" format)
-            makes setting up reverse zones easier.
-          </p>
-<p>
-            The Interface Identifier must be unique on the local link,
-            and is usually generated automatically by the IPv6
-            implementation, although it is usually possible to
-            override the default setting if necessary.  A typical IPv6
-            address might look like:
-            <span><strong class="command">2001:db8:201:9:a00:20ff:fe81:2b32</strong></span>
-          </p>
-<p>
-            IPv6 address specifications often contain long strings
-            of zeros, so the architects have included a shorthand for
-            specifying
-            them. The double colon (`::') indicates the longest possible
-            string
-            of zeros that can fit, and can be used only once in an address.
-          </p>
-</div>
-</div>
-<div class="sect1" lang="en">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="bibliography"></a>Bibliography (and Suggested Reading)</h2></div></div></div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="rfcs"></a>Request for Comments (RFCs)</h3></div></div></div>
-<p>
-            Specification documents for the Internet protocol suite, including
-            the <acronym class="acronym">DNS</acronym>, are published as part of
-            the Request for Comments (RFCs)
-            series of technical notes. The standards themselves are defined
-            by the Internet Engineering Task Force (IETF) and the Internet
-            Engineering Steering Group (IESG). RFCs can be obtained online via FTP at:
-          </p>
-<p>
-            <a href="ftp://www.isi.edu/in-notes/" target="_top">
-              ftp://www.isi.edu/in-notes/RFC<em class="replaceable"><code>xxxx</code></em>.txt
-            </a>
-          </p>
-<p>
-            (where <em class="replaceable"><code>xxxx</code></em> is
-            the number of the RFC). RFCs are also available via the Web at:
-          </p>
-<p>
-            <a href="http://www.ietf.org/rfc/" target="_top">http://www.ietf.org/rfc/</a>.
-          </p>
-<div class="bibliography">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2593659"></a>Bibliography</h4></div></div></div>
-<div class="bibliodiv">
-<h3 class="title">Standards</h3>
-<div class="biblioentry">
-<a name="id2593670"></a><p>[<abbr class="abbrev">RFC974</abbr>] <span class="author"><span class="firstname">C.</span> <span class="surname">Partridge</span>. </span><span class="title"><i>Mail Routing and the Domain System</i>. </span><span class="pubdate">January 1986. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2593693"></a><p>[<abbr class="abbrev">RFC1034</abbr>] <span class="author"><span class="firstname">P.V.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i>Domain Names &#8212; Concepts and Facilities</i>. </span><span class="pubdate">November 1987. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2593717"></a><p>[<abbr class="abbrev">RFC1035</abbr>] <span class="author"><span class="firstname">P. V.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i>Domain Names &#8212; Implementation and
-                  Specification</i>. </span><span class="pubdate">November 1987. </span></p>
-</div>
-</div>
-<div class="bibliodiv">
-<h3 class="title">
-<a name="proposed_standards"></a>Proposed Standards</h3>
-<div class="biblioentry">
-<a name="id2593753"></a><p>[<abbr class="abbrev">RFC2181</abbr>] <span class="author"><span class="firstname">R., R. Bush</span> <span class="surname">Elz</span>. </span><span class="title"><i>Clarifications to the <acronym class="acronym">DNS</acronym>
-                  Specification</i>. </span><span class="pubdate">July 1997. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2593780"></a><p>[<abbr class="abbrev">RFC2308</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Andrews</span>. </span><span class="title"><i>Negative Caching of <acronym class="acronym">DNS</acronym>
-                  Queries</i>. </span><span class="pubdate">March 1998. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2593805"></a><p>[<abbr class="abbrev">RFC1995</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Ohta</span>. </span><span class="title"><i>Incremental Zone Transfer in <acronym class="acronym">DNS</acronym></i>. </span><span class="pubdate">August 1996. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2593830"></a><p>[<abbr class="abbrev">RFC1996</abbr>] <span class="author"><span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>A Mechanism for Prompt Notification of Zone Changes</i>. </span><span class="pubdate">August 1996. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2593853"></a><p>[<abbr class="abbrev">RFC2136</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Vixie</span>, <span class="firstname">S.</span> <span class="surname">Thomson</span>, <span class="firstname">Y.</span> <span class="surname">Rekhter</span>, and <span class="firstname">J.</span> <span class="surname">Bound</span>. </span><span class="title"><i>Dynamic Updates in the Domain Name System</i>. </span><span class="pubdate">April 1997. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2593909"></a><p>[<abbr class="abbrev">RFC2671</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>Extension Mechanisms for DNS (EDNS0)</i>. </span><span class="pubdate">August 1997. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2593936"></a><p>[<abbr class="abbrev">RFC2672</abbr>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Crawford</span>. </span><span class="title"><i>Non-Terminal DNS Name Redirection</i>. </span><span class="pubdate">August 1999. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2593962"></a><p>[<abbr class="abbrev">RFC2845</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Vixie</span>, <span class="firstname">O.</span> <span class="surname">Gudmundsson</span>, <span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>, and <span class="firstname">B.</span> <span class="surname">Wellington</span>. </span><span class="title"><i>Secret Key Transaction Authentication for <acronym class="acronym">DNS</acronym> (TSIG)</i>. </span><span class="pubdate">May 2000. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2594024"></a><p>[<abbr class="abbrev">RFC2930</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Secret Key Establishment for DNS (TKEY RR)</i>. </span><span class="pubdate">September 2000. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2594054"></a><p>[<abbr class="abbrev">RFC2931</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>DNS Request and Transaction Signatures (SIG(0)s)</i>. </span><span class="pubdate">September 2000. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2594084"></a><p>[<abbr class="abbrev">RFC3007</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Wellington</span>. </span><span class="title"><i>Secure Domain Name System (DNS) Dynamic Update</i>. </span><span class="pubdate">November 2000. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2594110"></a><p>[<abbr class="abbrev">RFC3645</abbr>] <span class="authorgroup"><span class="firstname">S.</span> <span class="surname">Kwan</span>, <span class="firstname">P.</span> <span class="surname">Garg</span>, <span class="firstname">J.</span> <span class="surname">Gilroy</span>, <span class="firstname">L.</span> <span class="surname">Esibov</span>, <span class="firstname">J.</span> <span class="surname">Westhead</span>, and <span class="firstname">R.</span> <span class="surname">Hall</span>. </span><span class="title"><i>Generic Security Service Algorithm for Secret
-                       Key Transaction Authentication for DNS
-                       (GSS-TSIG)</i>. </span><span class="pubdate">October 2003. </span></p>
-</div>
-</div>
-<div class="bibliodiv">
-<h3 class="title">
-<acronym class="acronym">DNS</acronym> Security Proposed Standards</h3>
-<div class="biblioentry">
-<a name="id2594193"></a><p>[<abbr class="abbrev">RFC3225</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Conrad</span>. </span><span class="title"><i>Indicating Resolver Support of DNSSEC</i>. </span><span class="pubdate">December 2001. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2594288"></a><p>[<abbr class="abbrev">RFC3833</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Atkins</span> and <span class="firstname">R.</span> <span class="surname">Austein</span>. </span><span class="title"><i>Threat Analysis of the Domain Name System (DNS)</i>. </span><span class="pubdate">August 2004. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2594324"></a><p>[<abbr class="abbrev">RFC4033</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Arends</span>, <span class="firstname">R.</span> <span class="surname">Austein</span>, <span class="firstname">M.</span> <span class="surname">Larson</span>, <span class="firstname">D.</span> <span class="surname">Massey</span>, and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>DNS Security Introduction and Requirements</i>. </span><span class="pubdate">March 2005. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2594389"></a><p>[<abbr class="abbrev">RFC4044</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Arends</span>, <span class="firstname">R.</span> <span class="surname">Austein</span>, <span class="firstname">M.</span> <span class="surname">Larson</span>, <span class="firstname">D.</span> <span class="surname">Massey</span>, and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>Resource Records for the DNS Security Extensions</i>. </span><span class="pubdate">March 2005. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2594454"></a><p>[<abbr class="abbrev">RFC4035</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Arends</span>, <span class="firstname">R.</span> <span class="surname">Austein</span>, <span class="firstname">M.</span> <span class="surname">Larson</span>, <span class="firstname">D.</span> <span class="surname">Massey</span>, and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>Protocol Modifications for the DNS
-                       Security Extensions</i>. </span><span class="pubdate">March 2005. </span></p>
-</div>
-</div>
-<div class="bibliodiv">
-<h3 class="title">Other Important RFCs About <acronym class="acronym">DNS</acronym>
-                Implementation</h3>
-<div class="biblioentry">
-<a name="id2594596"></a><p>[<abbr class="abbrev">RFC1535</abbr>] <span class="author"><span class="firstname">E.</span> <span class="surname">Gavron</span>. </span><span class="title"><i>A Security Problem and Proposed Correction With Widely
-                  Deployed <acronym class="acronym">DNS</acronym> Software.</i>. </span><span class="pubdate">October 1993. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2594621"></a><p>[<abbr class="abbrev">RFC1536</abbr>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Kumar</span>, <span class="firstname">J.</span> <span class="surname">Postel</span>, <span class="firstname">C.</span> <span class="surname">Neuman</span>, <span class="firstname">P.</span> <span class="surname">Danzig</span>, and <span class="firstname">S.</span> <span class="surname">Miller</span>. </span><span class="title"><i>Common <acronym class="acronym">DNS</acronym> Implementation
-                  Errors and Suggested Fixes</i>. </span><span class="pubdate">October 1993. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2594690"></a><p>[<abbr class="abbrev">RFC1982</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Elz</span> and <span class="firstname">R.</span> <span class="surname">Bush</span>. </span><span class="title"><i>Serial Number Arithmetic</i>. </span><span class="pubdate">August 1996. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2594725"></a><p>[<abbr class="abbrev">RFC4074</abbr>] <span class="authorgroup"><span class="firstname">Y.</span> <span class="surname">Morishita</span> and <span class="firstname">T.</span> <span class="surname">Jinmei</span>. </span><span class="title"><i>Common Misbehaviour Against <acronym class="acronym">DNS</acronym>
-                Queries for IPv6 Addresses</i>. </span><span class="pubdate">May 2005. </span></p>
-</div>
-</div>
-<div class="bibliodiv">
-<h3 class="title">Resource Record Types</h3>
-<div class="biblioentry">
-<a name="id2594771"></a><p>[<abbr class="abbrev">RFC1183</abbr>] <span class="authorgroup"><span class="firstname">C.F.</span> <span class="surname">Everhart</span>, <span class="firstname">L. A.</span> <span class="surname">Mamakos</span>, <span class="firstname">R.</span> <span class="surname">Ullmann</span>, and <span class="firstname">P.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i>New <acronym class="acronym">DNS</acronym> RR Definitions</i>. </span><span class="pubdate">October 1990. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2594828"></a><p>[<abbr class="abbrev">RFC1706</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Manning</span> and <span class="firstname">R.</span> <span class="surname">Colella</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> NSAP Resource Records</i>. </span><span class="pubdate">October 1994. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2594866"></a><p>[<abbr class="abbrev">RFC2168</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Daniel</span> and <span class="firstname">M.</span> <span class="surname">Mealling</span>. </span><span class="title"><i>Resolution of Uniform Resource Identifiers using
-                  the Domain Name System</i>. </span><span class="pubdate">June 1997. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2594901"></a><p>[<abbr class="abbrev">RFC1876</abbr>] <span class="authorgroup"><span class="firstname">C.</span> <span class="surname">Davis</span>, <span class="firstname">P.</span> <span class="surname">Vixie</span>, <span class="firstname">T.</span>, and <span class="firstname">I.</span> <span class="surname">Dickinson</span>. </span><span class="title"><i>A Means for Expressing Location Information in the
-                  Domain
-                  Name System</i>. </span><span class="pubdate">January 1996. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2594955"></a><p>[<abbr class="abbrev">RFC2052</abbr>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Gulbrandsen</span> and <span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>A <acronym class="acronym">DNS</acronym> RR for Specifying the
-                  Location of
-                  Services.</i>. </span><span class="pubdate">October 1996. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2594994"></a><p>[<abbr class="abbrev">RFC2163</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Allocchio</span>. </span><span class="title"><i>Using the Internet <acronym class="acronym">DNS</acronym> to
-                  Distribute MIXER
-                  Conformant Global Address Mapping</i>. </span><span class="pubdate">January 1998. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2595019"></a><p>[<abbr class="abbrev">RFC2230</abbr>] <span class="author"><span class="firstname">R.</span> <span class="surname">Atkinson</span>. </span><span class="title"><i>Key Exchange Delegation Record for the <acronym class="acronym">DNS</acronym></i>. </span><span class="pubdate">October 1997. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2595045"></a><p>[<abbr class="abbrev">RFC2536</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>DSA KEYs and SIGs in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2595072"></a><p>[<abbr class="abbrev">RFC2537</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2595098"></a><p>[<abbr class="abbrev">RFC2538</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span> and <span class="firstname">O.</span> <span class="surname">Gudmundsson</span>. </span><span class="title"><i>Storing Certificates in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2595138"></a><p>[<abbr class="abbrev">RFC2539</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Storage of Diffie-Hellman Keys in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2595168"></a><p>[<abbr class="abbrev">RFC2540</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Detached Domain Name System (DNS) Information</i>. </span><span class="pubdate">March 1999. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2595197"></a><p>[<abbr class="abbrev">RFC2782</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Gulbrandsen</span>. </span><span class="author"><span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="author"><span class="firstname">L.</span> <span class="surname">Esibov</span>. </span><span class="title"><i>A DNS RR for specifying the location of services (DNS SRV)</i>. </span><span class="pubdate">February 2000. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2595240"></a><p>[<abbr class="abbrev">RFC2915</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Mealling</span>. </span><span class="author"><span class="firstname">R.</span> <span class="surname">Daniel</span>. </span><span class="title"><i>The Naming Authority Pointer (NAPTR) DNS Resource Record</i>. </span><span class="pubdate">September 2000. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2595273"></a><p>[<abbr class="abbrev">RFC3110</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)</i>. </span><span class="pubdate">May 2001. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2595300"></a><p>[<abbr class="abbrev">RFC3123</abbr>] <span class="author"><span class="firstname">P.</span> <span class="surname">Koch</span>. </span><span class="title"><i>A DNS RR Type for Lists of Address Prefixes (APL RR)</i>. </span><span class="pubdate">June 2001. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2595323"></a><p>[<abbr class="abbrev">RFC3596</abbr>] <span class="authorgroup"><span class="firstname">S.</span> <span class="surname">Thomson</span>, <span class="firstname">C.</span> <span class="surname">Huitema</span>, <span class="firstname">V.</span> <span class="surname">Ksinant</span>, and <span class="firstname">M.</span> <span class="surname">Souissi</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> Extensions to support IP
-                  version 6</i>. </span><span class="pubdate">October 2003. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2595381"></a><p>[<abbr class="abbrev">RFC3597</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Gustafsson</span>. </span><span class="title"><i>Handling of Unknown DNS Resource Record (RR) Types</i>. </span><span class="pubdate">September 2003. </span></p>
-</div>
-</div>
-<div class="bibliodiv">
-<h3 class="title">
-<acronym class="acronym">DNS</acronym> and the Internet</h3>
-<div class="biblioentry">
-<a name="id2595413"></a><p>[<abbr class="abbrev">RFC1101</abbr>] <span class="author"><span class="firstname">P. V.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> Encoding of Network Names
-                  and Other Types</i>. </span><span class="pubdate">April 1989. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2595438"></a><p>[<abbr class="abbrev">RFC1123</abbr>] <span class="author"><span class="surname">Braden</span>. </span><span class="title"><i>Requirements for Internet Hosts - Application and
-                  Support</i>. </span><span class="pubdate">October 1989. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2595461"></a><p>[<abbr class="abbrev">RFC1591</abbr>] <span class="author"><span class="firstname">J.</span> <span class="surname">Postel</span>. </span><span class="title"><i>Domain Name System Structure and Delegation</i>. </span><span class="pubdate">March 1994. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2595484"></a><p>[<abbr class="abbrev">RFC2317</abbr>] <span class="authorgroup"><span class="firstname">H.</span> <span class="surname">Eidnes</span>, <span class="firstname">G.</span> <span class="surname">de Groot</span>, and <span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>Classless IN-ADDR.ARPA Delegation</i>. </span><span class="pubdate">March 1998. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2595530"></a><p>[<abbr class="abbrev">RFC2826</abbr>] <span class="authorgroup"><span class="surname">Internet Architecture Board</span>. </span><span class="title"><i>IAB Technical Comment on the Unique DNS Root</i>. </span><span class="pubdate">May 2000. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2595554"></a><p>[<abbr class="abbrev">RFC2929</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>, <span class="firstname">E.</span> <span class="surname">Brunner-Williams</span>, and <span class="firstname">B.</span> <span class="surname">Manning</span>. </span><span class="title"><i>Domain Name System (DNS) IANA Considerations</i>. </span><span class="pubdate">September 2000. </span></p>
-</div>
-</div>
-<div class="bibliodiv">
-<h3 class="title">
-<acronym class="acronym">DNS</acronym> Operations</h3>
-<div class="biblioentry">
-<a name="id2595611"></a><p>[<abbr class="abbrev">RFC1033</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Lottor</span>. </span><span class="title"><i>Domain administrators operations guide.</i>. </span><span class="pubdate">November 1987. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2595635"></a><p>[<abbr class="abbrev">RFC1537</abbr>] <span class="author"><span class="firstname">P.</span> <span class="surname">Beertema</span>. </span><span class="title"><i>Common <acronym class="acronym">DNS</acronym> Data File
-                  Configuration Errors</i>. </span><span class="pubdate">October 1993. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2595661"></a><p>[<abbr class="abbrev">RFC1912</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Barr</span>. </span><span class="title"><i>Common <acronym class="acronym">DNS</acronym> Operational and
-                  Configuration Errors</i>. </span><span class="pubdate">February 1996. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2595688"></a><p>[<abbr class="abbrev">RFC2010</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Manning</span> and <span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>Operational Criteria for Root Name Servers.</i>. </span><span class="pubdate">October 1996. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2595724"></a><p>[<abbr class="abbrev">RFC2219</abbr>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Hamilton</span> and <span class="firstname">R.</span> <span class="surname">Wright</span>. </span><span class="title"><i>Use of <acronym class="acronym">DNS</acronym> Aliases for
-                  Network Services.</i>. </span><span class="pubdate">October 1997. </span></p>
-</div>
-</div>
-<div class="bibliodiv">
-<h3 class="title">Internationalized Domain Names</h3>
-<div class="biblioentry">
-<a name="id2595770"></a><p>[<abbr class="abbrev">RFC2825</abbr>] <span class="authorgroup"><span class="surname">IAB</span> and <span class="firstname">R.</span> <span class="surname">Daigle</span>. </span><span class="title"><i>A Tangled Web: Issues of I18N, Domain Names,
-                       and the Other Internet protocols</i>. </span><span class="pubdate">May 2000. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2595802"></a><p>[<abbr class="abbrev">RFC3490</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Faltstrom</span>, <span class="firstname">P.</span> <span class="surname">Hoffman</span>, and <span class="firstname">A.</span> <span class="surname">Costello</span>. </span><span class="title"><i>Internationalizing Domain Names in Applications (IDNA)</i>. </span><span class="pubdate">March 2003. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2595848"></a><p>[<abbr class="abbrev">RFC3491</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Hoffman</span> and <span class="firstname">M.</span> <span class="surname">Blanchet</span>. </span><span class="title"><i>Nameprep: A Stringprep Profile for Internationalized Domain Names</i>. </span><span class="pubdate">March 2003. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2595883"></a><p>[<abbr class="abbrev">RFC3492</abbr>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Costello</span>. </span><span class="title"><i>Punycode: A Bootstring encoding of Unicode
-                       for Internationalized Domain Names in
-                       Applications (IDNA)</i>. </span><span class="pubdate">March 2003. </span></p>
-</div>
-</div>
-<div class="bibliodiv">
-<h3 class="title">Other <acronym class="acronym">DNS</acronym>-related RFCs</h3>
-<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-<p>
-                  Note: the following list of RFCs, although
-                  <acronym class="acronym">DNS</acronym>-related, are not
-                  concerned with implementing software.
-                </p>
-</div>
-<div class="biblioentry">
-<a name="id2595928"></a><p>[<abbr class="abbrev">RFC1464</abbr>] <span class="author"><span class="firstname">R.</span> <span class="surname">Rosenbaum</span>. </span><span class="title"><i>Using the Domain Name System To Store Arbitrary String
-                  Attributes</i>. </span><span class="pubdate">May 1993. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2595950"></a><p>[<abbr class="abbrev">RFC1713</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Romao</span>. </span><span class="title"><i>Tools for <acronym class="acronym">DNS</acronym> Debugging</i>. </span><span class="pubdate">November 1994. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2595976"></a><p>[<abbr class="abbrev">RFC1794</abbr>] <span class="author"><span class="firstname">T.</span> <span class="surname">Brisco</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> Support for Load
-                  Balancing</i>. </span><span class="pubdate">April 1995. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2596002"></a><p>[<abbr class="abbrev">RFC2240</abbr>] <span class="author"><span class="firstname">O.</span> <span class="surname">Vaughan</span>. </span><span class="title"><i>A Legal Basis for Domain Name Allocation</i>. </span><span class="pubdate">November 1997. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2596025"></a><p>[<abbr class="abbrev">RFC2345</abbr>] <span class="authorgroup"><span class="firstname">J.</span> <span class="surname">Klensin</span>, <span class="firstname">T.</span> <span class="surname">Wolf</span>, and <span class="firstname">G.</span> <span class="surname">Oglesby</span>. </span><span class="title"><i>Domain Names and Company Name Retrieval</i>. </span><span class="pubdate">May 1998. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2596071"></a><p>[<abbr class="abbrev">RFC2352</abbr>] <span class="author"><span class="firstname">O.</span> <span class="surname">Vaughan</span>. </span><span class="title"><i>A Convention For Using Legal Names as Domain Names</i>. </span><span class="pubdate">May 1998. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2596094"></a><p>[<abbr class="abbrev">RFC3071</abbr>] <span class="authorgroup"><span class="firstname">J.</span> <span class="surname">Klensin</span>. </span><span class="title"><i>Reflections on the DNS, RFC 1591, and Categories of Domains</i>. </span><span class="pubdate">February 2001. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2596121"></a><p>[<abbr class="abbrev">RFC3258</abbr>] <span class="authorgroup"><span class="firstname">T.</span> <span class="surname">Hardie</span>. </span><span class="title"><i>Distributing Authoritative Name Servers via
-                       Shared Unicast Addresses</i>. </span><span class="pubdate">April 2002. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2596147"></a><p>[<abbr class="abbrev">RFC3901</abbr>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Durand</span> and <span class="firstname">J.</span> <span class="surname">Ihren</span>. </span><span class="title"><i>DNS IPv6 Transport Operational Guidelines</i>. </span><span class="pubdate">September 2004. </span></p>
-</div>
-</div>
-<div class="bibliodiv">
-<h3 class="title">Obsolete and Unimplemented Experimental RFC</h3>
-<div class="biblioentry">
-<a name="id2596190"></a><p>[<abbr class="abbrev">RFC1712</abbr>] <span class="authorgroup"><span class="firstname">C.</span> <span class="surname">Farrell</span>, <span class="firstname">M.</span> <span class="surname">Schulze</span>, <span class="firstname">S.</span> <span class="surname">Pleitner</span>, and <span class="firstname">D.</span> <span class="surname">Baldoni</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> Encoding of Geographical
-                  Location</i>. </span><span class="pubdate">November 1994. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2596248"></a><p>[<abbr class="abbrev">RFC2673</abbr>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Crawford</span>. </span><span class="title"><i>Binary Labels in the Domain Name System</i>. </span><span class="pubdate">August 1999. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2596275"></a><p>[<abbr class="abbrev">RFC2874</abbr>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Crawford</span> and <span class="firstname">C.</span> <span class="surname">Huitema</span>. </span><span class="title"><i>DNS Extensions to Support IPv6 Address Aggregation
-                       and Renumbering</i>. </span><span class="pubdate">July 2000. </span></p>
-</div>
-</div>
-<div class="bibliodiv">
-<h3 class="title">Obsoleted DNS Security RFCs</h3>
-<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-<p>
-                  Most of these have been consolidated into RFC4033,
-                  RFC4034 and RFC4035 which collectively describe DNSSECbis.
-                </p>
-</div>
-<div class="biblioentry">
-<a name="id2596323"></a><p>[<abbr class="abbrev">RFC2065</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span> and <span class="firstname">C.</span> <span class="surname">Kaufman</span>. </span><span class="title"><i>Domain Name System Security Extensions</i>. </span><span class="pubdate">January 1997. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2596362"></a><p>[<abbr class="abbrev">RFC2137</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Secure Domain Name System Dynamic Update</i>. </span><span class="pubdate">April 1997. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2596389"></a><p>[<abbr class="abbrev">RFC2535</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Domain Name System Security Extensions</i>. </span><span class="pubdate">March 1999. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2596419"></a><p>[<abbr class="abbrev">RFC3008</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Wellington</span>. </span><span class="title"><i>Domain Name System Security (DNSSEC)
-                       Signing Authority</i>. </span><span class="pubdate">November 2000. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2596444"></a><p>[<abbr class="abbrev">RFC3090</abbr>] <span class="authorgroup"><span class="firstname">E.</span> <span class="surname">Lewis</span>. </span><span class="title"><i>DNS Security Extension Clarification on Zone Status</i>. </span><span class="pubdate">March 2001. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2596471"></a><p>[<abbr class="abbrev">RFC3445</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Massey</span> and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>Limiting the Scope of the KEY Resource Record (RR)</i>. </span><span class="pubdate">December 2002. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2596507"></a><p>[<abbr class="abbrev">RFC3655</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Wellington</span> and <span class="firstname">O.</span> <span class="surname">Gudmundsson</span>. </span><span class="title"><i>Redefinition of DNS Authenticated Data (AD) bit</i>. </span><span class="pubdate">November 2003. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2596544"></a><p>[<abbr class="abbrev">RFC3658</abbr>] <span class="authorgroup"><span class="firstname">O.</span> <span class="surname">Gudmundsson</span>. </span><span class="title"><i>Delegation Signer (DS) Resource Record (RR)</i>. </span><span class="pubdate">December 2003. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2596570"></a><p>[<abbr class="abbrev">RFC3755</abbr>] <span class="authorgroup"><span class="firstname">S.</span> <span class="surname">Weiler</span>. </span><span class="title"><i>Legacy Resolver Compatibility for Delegation Signer (DS)</i>. </span><span class="pubdate">May 2004. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2596597"></a><p>[<abbr class="abbrev">RFC3757</abbr>] <span class="authorgroup"><span class="firstname">O.</span> <span class="surname">Kolkman</span>, <span class="firstname">J.</span> <span class="surname">Schlyter</span>, and <span class="firstname">E.</span> <span class="surname">Lewis</span>. </span><span class="title"><i>Domain Name System KEY (DNSKEY) Resource Record
-                      (RR) Secure Entry Point (SEP) Flag</i>. </span><span class="pubdate">April 2004. </span></p>
-</div>
-<div class="biblioentry">
-<a name="id2596642"></a><p>[<abbr class="abbrev">RFC3845</abbr>] <span class="authorgroup"><span class="firstname">J.</span> <span class="surname">Schlyter</span>. </span><span class="title"><i>DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format</i>. </span><span class="pubdate">August 2004. </span></p>
-</div>
-</div>
-</div>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="internet_drafts"></a>Internet Drafts</h3></div></div></div>
-<p>
-            Internet Drafts (IDs) are rough-draft working documents of
-            the Internet Engineering Task Force. They are, in essence, RFCs
-            in the preliminary stages of development. Implementors are
-            cautioned not
-            to regard IDs as archival, and they should not be quoted or cited
-            in any formal documents unless accompanied by the disclaimer that
-            they are "works in progress." IDs have a lifespan of six months
-            after which they are deleted unless updated by their authors.
-          </p>
-</div>
-<div class="sect2" lang="en">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id2596683"></a>Other Documents About <acronym class="acronym">BIND</acronym>
-</h3></div></div></div>
-<p></p>
-<div class="bibliography">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="id2596693"></a>Bibliography</h4></div></div></div>
-<div class="biblioentry">
-<a name="id2596695"></a><p><span class="authorgroup"><span class="firstname">Paul</span> <span class="surname">Albitz</span> and <span class="firstname">Cricket</span> <span class="surname">Liu</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> and <acronym class="acronym">BIND</acronym></i>. </span><span class="copyright">Copyright © 1998 Sebastopol, CA: O'Reilly and Associates. </span></p>
-</div>
-</div>
-</div>
-</div>
-</div>
-<div class="navfooter">
-<hr>
-<table width="100%" summary="Navigation footer">
-<tr>
-<td width="40%" align="left">
-<a accesskey="p" href="Bv9ARM.ch08.html">Prev</a> </td>
-<td width="20%" align="center"> </td>
-<td width="40%" align="right"> <a accesskey="n" href="Bv9ARM.ch10.html">Next</a>
-</td>
-</tr>
-<tr>
-<td width="40%" align="left" valign="top">Chapter 8. Troubleshooting </td>
-<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
-<td width="40%" align="right" valign="top"> Manual pages</td>
-</tr>
-</table>
-</div>
-</body>
-</html>
diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch10.html b/contrib/bind9/doc/arm/Bv9ARM.ch10.html
deleted file mode 100644
index 03cce5a..0000000
--- a/contrib/bind9/doc/arm/Bv9ARM.ch10.html
+++ /dev/null
@@ -1,102 +0,0 @@
-<!--
- - Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2000-2003 Internet Software Consortium.
- - 
- - Permission to use, copy, modify, and distribute this software for any
- - purpose with or without fee is hereby granted, provided that the above
- - copyright notice and this permission notice appear in all copies.
- - 
- - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
- - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- - PERFORMANCE OF THIS SOFTWARE.
--->
-<!-- $Id: Bv9ARM.ch10.html,v 1.2.2.6 2007/01/30 00:23:46 marka Exp $ -->
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>Manual pages</title>
-<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
-<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="prev" href="Bv9ARM.ch09.html" title="Appendix A. Appendices">
-<link rel="next" href="man.dig.html" title="dig">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
-<div class="navheader">
-<table width="100%" summary="Navigation header">
-<tr><th colspan="3" align="center">Manual pages</th></tr>
-<tr>
-<td width="20%" align="left">
-<a accesskey="p" href="Bv9ARM.ch09.html">Prev</a> </td>
-<th width="60%" align="center"> </th>
-<td width="20%" align="right"> <a accesskey="n" href="man.dig.html">Next</a>
-</td>
-</tr>
-</table>
-<hr>
-</div>
-<div class="reference" lang="en">
-<div class="titlepage">
-<div><div><h1 class="title">
-<a name="Bv9ARM.ch10"></a>Manual pages</h1></div></div>
-<hr>
-</div>
-<div class="toc">
-<p><b>Table of Contents</b></p>
-<dl>
-<dt>
-<span class="refentrytitle"><a href="man.dig.html">dig</a></span><span class="refpurpose"> &#8212; DNS lookup utility</span>
-</dt>
-<dt>
-<span class="refentrytitle"><a href="man.host.html">host</a></span><span class="refpurpose"> &#8212; DNS lookup utility</span>
-</dt>
-<dt>
-<span class="refentrytitle"><a href="man.dnssec-keygen.html"><span class="application">dnssec-keygen</span></a></span><span class="refpurpose"> &#8212; DNSSEC key generation tool</span>
-</dt>
-<dt>
-<span class="refentrytitle"><a href="man.dnssec-signzone.html"><span class="application">dnssec-signzone</span></a></span><span class="refpurpose"> &#8212; DNSSEC zone signing tool</span>
-</dt>
-<dt>
-<span class="refentrytitle"><a href="man.named-checkconf.html"><span class="application">named-checkconf</span></a></span><span class="refpurpose"> &#8212; named configuration file syntax checking tool</span>
-</dt>
-<dt>
-<span class="refentrytitle"><a href="man.named-checkzone.html"><span class="application">named-checkzone</span></a></span><span class="refpurpose"> &#8212; zone file validity checking or converting tool</span>
-</dt>
-<dt>
-<span class="refentrytitle"><a href="man.named.html"><span class="application">named</span></a></span><span class="refpurpose"> &#8212; Internet domain name server</span>
-</dt>
-<dt>
-<span class="refentrytitle"><a href="man.rndc.html"><span class="application">rndc</span></a></span><span class="refpurpose"> &#8212; name server control utility</span>
-</dt>
-<dt>
-<span class="refentrytitle"><a href="man.rndc.conf.html"><code class="filename">rndc.conf</code></a></span><span class="refpurpose"> &#8212; rndc configuration file</span>
-</dt>
-<dt>
-<span class="refentrytitle"><a href="man.rndc-confgen.html"><span class="application">rndc-confgen</span></a></span><span class="refpurpose"> &#8212; rndc key generation tool</span>
-</dt>
-</dl>
-</div>
-</div>
-<div class="navfooter">
-<hr>
-<table width="100%" summary="Navigation footer">
-<tr>
-<td width="40%" align="left">
-<a accesskey="p" href="Bv9ARM.ch09.html">Prev</a> </td>
-<td width="20%" align="center"> </td>
-<td width="40%" align="right"> <a accesskey="n" href="man.dig.html">Next</a>
-</td>
-</tr>
-<tr>
-<td width="40%" align="left" valign="top">Appendix A. Appendices </td>
-<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
-<td width="40%" align="right" valign="top"> dig</td>
-</tr>
-</table>
-</div>
-</body>
-</html>
diff --git a/contrib/bind9/doc/arm/Bv9ARM.html b/contrib/bind9/doc/arm/Bv9ARM.html
deleted file mode 100644
index 8a33041..0000000
--- a/contrib/bind9/doc/arm/Bv9ARM.html
+++ /dev/null
@@ -1,262 +0,0 @@
-<!--
- - Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2000-2003 Internet Software Consortium.
- - 
- - Permission to use, copy, modify, and distribute this software for any
- - purpose with or without fee is hereby granted, provided that the above
- - copyright notice and this permission notice appear in all copies.
- - 
- - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
- - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- - PERFORMANCE OF THIS SOFTWARE.
--->
-<!-- $Id: Bv9ARM.html,v 1.85.18.68 2007/10/31 01:35:59 marka Exp $ -->
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>BIND 9 Administrator Reference Manual</title>
-<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
-<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="next" href="Bv9ARM.ch01.html" title="Chapter 1. Introduction">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
-<div class="navheader">
-<table width="100%" summary="Navigation header">
-<tr><th colspan="3" align="center">BIND 9 Administrator Reference Manual</th></tr>
-<tr>
-<td width="20%" align="left"> </td>
-<th width="60%" align="center"> </th>
-<td width="20%" align="right"> <a accesskey="n" href="Bv9ARM.ch01.html">Next</a>
-</td>
-</tr>
-</table>
-<hr>
-</div>
-<div class="book" lang="en">
-<div class="titlepage">
-<div>
-<div><h1 class="title">
-<a name="id2563155"></a>BIND 9 Administrator Reference Manual</h1></div>
-<div><p class="copyright">Copyright © 2004-2007 Internet Systems Consortium, Inc. ("ISC")</p></div>
-<div><p class="copyright">Copyright © 2000-2003 Internet Software Consortium.</p></div>
-</div>
-<hr>
-</div>
-<div class="toc">
-<p><b>Table of Contents</b></p>
-<dl>
-<dt><span class="chapter"><a href="Bv9ARM.ch01.html">1. Introduction</a></span></dt>
-<dd><dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564117">Scope of Document</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564140">Organization of This Document</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2563474">Conventions Used in This Document</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564816">The Domain Name System (<acronym class="acronym">DNS</acronym>)</a></span></dt>
-<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564837">DNS Fundamentals</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564871">Domains and Domain Names</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567208">Zones</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567285">Authoritative Name Servers</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567526">Caching Name Servers</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567588">Name Servers in Multiple Roles</a></span></dt>
-</dl></dd>
-</dl></dd>
-<dt><span class="chapter"><a href="Bv9ARM.ch02.html">2. <acronym class="acronym">BIND</acronym> Resource Requirements</a></span></dt>
-<dd><dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567622">Hardware requirements</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567649">CPU Requirements</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567661">Memory Requirements</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567688">Name Server Intensive Environment Issues</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567699">Supported Operating Systems</a></span></dt>
-</dl></dd>
-<dt><span class="chapter"><a href="Bv9ARM.ch03.html">3. Name Server Configuration</a></span></dt>
-<dd><dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch03.html#sample_configuration">Sample Configurations</a></span></dt>
-<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2568004">A Caching-only Name Server</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2568020">An Authoritative-only Name Server</a></span></dt>
-</dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568042">Load Balancing</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568465">Name Server Operations</a></span></dt>
-<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2568470">Tools for Use With the Name Server Daemon</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2570184">Signals</a></span></dt>
-</dl></dd>
-</dl></dd>
-<dt><span class="chapter"><a href="Bv9ARM.ch04.html">4. Advanced DNS Features</a></span></dt>
-<dd><dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#notify">Notify</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#dynamic_update">Dynamic Update</a></span></dt>
-<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch04.html#journal">The journal file</a></span></dt></dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#incremental_zone_transfers">Incremental Zone Transfers (IXFR)</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2570642">Split DNS</a></span></dt>
-<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2570660">Example split DNS setup</a></span></dt></dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#tsig">TSIG</a></span></dt>
-<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571095">Generate Shared Keys for Each Pair of Hosts</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571169">Copying the Shared Secret to Both Machines</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571179">Informing the Servers of the Key's Existence</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571219">Instructing the Server to Use the Key</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571413">TSIG Key Based Access Control</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571458">Errors</a></span></dt>
-</dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571472">TKEY</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571521">SIG(0)</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#DNSSEC">DNSSEC</a></span></dt>
-<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571725">Generating Keys</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571795">Signing the Zone</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571874">Configuring Servers</a></span></dt>
-</dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2572153">IPv6 Support in <acronym class="acronym">BIND</acronym> 9</a></span></dt>
-<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572215">Address Lookups Using AAAA Records</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572236">Address to Name Lookups Using Nibble Format</a></span></dt>
-</dl></dd>
-</dl></dd>
-<dt><span class="chapter"><a href="Bv9ARM.ch05.html">5. The <acronym class="acronym">BIND</acronym> 9 Lightweight Resolver</a></span></dt>
-<dd><dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch05.html#id2572269">The Lightweight Resolver Library</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch05.html#lwresd">Running a Resolver Daemon</a></span></dt>
-</dl></dd>
-<dt><span class="chapter"><a href="Bv9ARM.ch06.html">6. <acronym class="acronym">BIND</acronym> 9 Configuration Reference</a></span></dt>
-<dd><dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch06.html#configuration_file_elements">Configuration File Elements</a></span></dt>
-<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#address_match_lists">Address Match Lists</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2573480">Comment Syntax</a></span></dt>
-</dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch06.html#Configuration_File_Grammar">Configuration File Grammar</a></span></dt>
-<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574092"><span><strong class="command">acl</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#acl"><span><strong class="command">acl</strong></span> Statement Definition and
-          Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574282"><span><strong class="command">controls</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#controls_statement_definition_and_usage"><span><strong class="command">controls</strong></span> Statement Definition and
-          Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574711"><span><strong class="command">include</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574726"><span><strong class="command">include</strong></span> Statement Definition and
-          Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574749"><span><strong class="command">key</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574771"><span><strong class="command">key</strong></span> Statement Definition and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574930"><span><strong class="command">logging</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575056"><span><strong class="command">logging</strong></span> Statement Definition and
-          Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2576406"><span><strong class="command">lwres</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2576480"><span><strong class="command">lwres</strong></span> Statement Definition and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2576544"><span><strong class="command">masters</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2576587"><span><strong class="command">masters</strong></span> Statement Definition and
-          Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2576602"><span><strong class="command">options</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#options"><span><strong class="command">options</strong></span> Statement Definition and
-          Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#server_statement_grammar"><span><strong class="command">server</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#server_statement_definition_and_usage"><span><strong class="command">server</strong></span> Statement Definition and
-            Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2585361"><span><strong class="command">trusted-keys</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2585410"><span><strong class="command">trusted-keys</strong></span> Statement Definition
-            and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#view_statement_grammar"><span><strong class="command">view</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2585490"><span><strong class="command">view</strong></span> Statement Definition and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#zone_statement_grammar"><span><strong class="command">zone</strong></span>
-            Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2586798"><span><strong class="command">zone</strong></span> Statement Definition and Usage</a></span></dt>
-</dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch06.html#id2589080">Zone File</a></span></dt>
-<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#types_of_resource_records_and_when_to_use_them">Types of Resource Records and When to Use Them</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2591101">Discussion of MX Records</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#Setting_TTLs">Setting TTLs</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2591653">Inverse Mapping in IPv4</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2591848">Other Zone File Directives</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2592173"><acronym class="acronym">BIND</acronym> Master File Extension: the  <span><strong class="command">$GENERATE</strong></span> Directive</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#zonefile_format">Additional File Formats</a></span></dt>
-</dl></dd>
-</dl></dd>
-<dt><span class="chapter"><a href="Bv9ARM.ch07.html">7. <acronym class="acronym">BIND</acronym> 9 Security Considerations</a></span></dt>
-<dd><dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch07.html#Access_Control_Lists">Access Control Lists</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch07.html#id2592714"><span><strong class="command">Chroot</strong></span> and <span><strong class="command">Setuid</strong></span></a></span></dt>
-<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2592791">The <span><strong class="command">chroot</strong></span> Environment</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2592851">Using the <span><strong class="command">setuid</strong></span> Function</a></span></dt>
-</dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch07.html#dynamic_update_security">Dynamic Update Security</a></span></dt>
-</dl></dd>
-<dt><span class="chapter"><a href="Bv9ARM.ch08.html">8. Troubleshooting</a></span></dt>
-<dd><dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2592999">Common Problems</a></span></dt>
-<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch08.html#id2593004">It's not working; how can I figure out what's wrong?</a></span></dt></dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2593016">Incrementing and Changing the Serial Number</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2593033">Where Can I Get Help?</a></span></dt>
-</dl></dd>
-<dt><span class="appendix"><a href="Bv9ARM.ch09.html">A. Appendices</a></span></dt>
-<dd><dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2593300">Acknowledgments</a></span></dt>
-<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch09.html#historical_dns_information">A Brief History of the <acronym class="acronym">DNS</acronym> and <acronym class="acronym">BIND</acronym></a></span></dt></dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2593472">General <acronym class="acronym">DNS</acronym> Reference Information</a></span></dt>
-<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch09.html#ipv6addresses">IPv6 addresses (AAAA)</a></span></dt></dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch09.html#bibliography">Bibliography (and Suggested Reading)</a></span></dt>
-<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch09.html#rfcs">Request for Comments (RFCs)</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch09.html#internet_drafts">Internet Drafts</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2596683">Other Documents About <acronym class="acronym">BIND</acronym></a></span></dt>
-</dl></dd>
-</dl></dd>
-<dt><span class="reference"><a href="Bv9ARM.ch10.html">I. Manual pages</a></span></dt>
-<dd><dl>
-<dt>
-<span class="refentrytitle"><a href="man.dig.html">dig</a></span><span class="refpurpose"> &#8212; DNS lookup utility</span>
-</dt>
-<dt>
-<span class="refentrytitle"><a href="man.host.html">host</a></span><span class="refpurpose"> &#8212; DNS lookup utility</span>
-</dt>
-<dt>
-<span class="refentrytitle"><a href="man.dnssec-keygen.html"><span class="application">dnssec-keygen</span></a></span><span class="refpurpose"> &#8212; DNSSEC key generation tool</span>
-</dt>
-<dt>
-<span class="refentrytitle"><a href="man.dnssec-signzone.html"><span class="application">dnssec-signzone</span></a></span><span class="refpurpose"> &#8212; DNSSEC zone signing tool</span>
-</dt>
-<dt>
-<span class="refentrytitle"><a href="man.named-checkconf.html"><span class="application">named-checkconf</span></a></span><span class="refpurpose"> &#8212; named configuration file syntax checking tool</span>
-</dt>
-<dt>
-<span class="refentrytitle"><a href="man.named-checkzone.html"><span class="application">named-checkzone</span></a></span><span class="refpurpose"> &#8212; zone file validity checking or converting tool</span>
-</dt>
-<dt>
-<span class="refentrytitle"><a href="man.named.html"><span class="application">named</span></a></span><span class="refpurpose"> &#8212; Internet domain name server</span>
-</dt>
-<dt>
-<span class="refentrytitle"><a href="man.rndc.html"><span class="application">rndc</span></a></span><span class="refpurpose"> &#8212; name server control utility</span>
-</dt>
-<dt>
-<span class="refentrytitle"><a href="man.rndc.conf.html"><code class="filename">rndc.conf</code></a></span><span class="refpurpose"> &#8212; rndc configuration file</span>
-</dt>
-<dt>
-<span class="refentrytitle"><a href="man.rndc-confgen.html"><span class="application">rndc-confgen</span></a></span><span class="refpurpose"> &#8212; rndc key generation tool</span>
-</dt>
-</dl></dd>
-</dl>
-</div>
-</div>
-<div class="navfooter">
-<hr>
-<table width="100%" summary="Navigation footer">
-<tr>
-<td width="40%" align="left"> </td>
-<td width="20%" align="center"> </td>
-<td width="40%" align="right"> <a accesskey="n" href="Bv9ARM.ch01.html">Next</a>
-</td>
-</tr>
-<tr>
-<td width="40%" align="left" valign="top"> </td>
-<td width="20%" align="center"> </td>
-<td width="40%" align="right" valign="top"> Chapter 1. Introduction</td>
-</tr>
-</table>
-</div>
-</body>
-</html>
diff --git a/contrib/bind9/doc/arm/Bv9ARM.pdf b/contrib/bind9/doc/arm/Bv9ARM.pdf
deleted file mode 100755
index be27aa1..0000000
--- a/contrib/bind9/doc/arm/Bv9ARM.pdf
+++ /dev/null
@@ -1,12885 +0,0 @@
-%PDF-1.4
-5 0 obj
-<< /S /GoTo /D (chapter.1) >>
-endobj
-8 0 obj
-(1 Introduction)
-endobj
-9 0 obj
-<< /S /GoTo /D (section.1.1) >>
-endobj
-12 0 obj
-(1.1 Scope of Document)
-endobj
-13 0 obj
-<< /S /GoTo /D (section.1.2) >>
-endobj
-16 0 obj
-(1.2 Organization of This Document)
-endobj
-17 0 obj
-<< /S /GoTo /D (section.1.3) >>
-endobj
-20 0 obj
-(1.3 Conventions Used in This Document)
-endobj
-21 0 obj
-<< /S /GoTo /D (section.1.4) >>
-endobj
-24 0 obj
-(1.4 The Domain Name System \(DNS\))
-endobj
-25 0 obj
-<< /S /GoTo /D (subsection.1.4.1) >>
-endobj
-28 0 obj
-(1.4.1 DNS Fundamentals)
-endobj
-29 0 obj
-<< /S /GoTo /D (subsection.1.4.2) >>
-endobj
-32 0 obj
-(1.4.2 Domains and Domain Names)
-endobj
-33 0 obj
-<< /S /GoTo /D (subsection.1.4.3) >>
-endobj
-36 0 obj
-(1.4.3 Zones)
-endobj
-37 0 obj
-<< /S /GoTo /D (subsection.1.4.4) >>
-endobj
-40 0 obj
-(1.4.4 Authoritative Name Servers)
-endobj
-41 0 obj
-<< /S /GoTo /D (subsubsection.1.4.4.1) >>
-endobj
-44 0 obj
-(1.4.4.1 The Primary Master)
-endobj
-45 0 obj
-<< /S /GoTo /D (subsubsection.1.4.4.2) >>
-endobj
-48 0 obj
-(1.4.4.2 Slave Servers)
-endobj
-49 0 obj
-<< /S /GoTo /D (subsubsection.1.4.4.3) >>
-endobj
-52 0 obj
-(1.4.4.3 Stealth Servers)
-endobj
-53 0 obj
-<< /S /GoTo /D (subsection.1.4.5) >>
-endobj
-56 0 obj
-(1.4.5 Caching Name Servers)
-endobj
-57 0 obj
-<< /S /GoTo /D (subsubsection.1.4.5.1) >>
-endobj
-60 0 obj
-(1.4.5.1 Forwarding)
-endobj
-61 0 obj
-<< /S /GoTo /D (subsection.1.4.6) >>
-endobj
-64 0 obj
-(1.4.6 Name Servers in Multiple Roles)
-endobj
-65 0 obj
-<< /S /GoTo /D (chapter.2) >>
-endobj
-68 0 obj
-(2 BIND Resource Requirements)
-endobj
-69 0 obj
-<< /S /GoTo /D (section.2.1) >>
-endobj
-72 0 obj
-(2.1 Hardware requirements)
-endobj
-73 0 obj
-<< /S /GoTo /D (section.2.2) >>
-endobj
-76 0 obj
-(2.2 CPU Requirements)
-endobj
-77 0 obj
-<< /S /GoTo /D (section.2.3) >>
-endobj
-80 0 obj
-(2.3 Memory Requirements)
-endobj
-81 0 obj
-<< /S /GoTo /D (section.2.4) >>
-endobj
-84 0 obj
-(2.4 Name Server Intensive Environment Issues)
-endobj
-85 0 obj
-<< /S /GoTo /D (section.2.5) >>
-endobj
-88 0 obj
-(2.5 Supported Operating Systems)
-endobj
-89 0 obj
-<< /S /GoTo /D (chapter.3) >>
-endobj
-92 0 obj
-(3 Name Server Configuration)
-endobj
-93 0 obj
-<< /S /GoTo /D (section.3.1) >>
-endobj
-96 0 obj
-(3.1 Sample Configurations)
-endobj
-97 0 obj
-<< /S /GoTo /D (subsection.3.1.1) >>
-endobj
-100 0 obj
-(3.1.1 A Caching-only Name Server)
-endobj
-101 0 obj
-<< /S /GoTo /D (subsection.3.1.2) >>
-endobj
-104 0 obj
-(3.1.2 An Authoritative-only Name Server)
-endobj
-105 0 obj
-<< /S /GoTo /D (section.3.2) >>
-endobj
-108 0 obj
-(3.2 Load Balancing)
-endobj
-109 0 obj
-<< /S /GoTo /D (section.3.3) >>
-endobj
-112 0 obj
-(3.3 Name Server Operations)
-endobj
-113 0 obj
-<< /S /GoTo /D (subsection.3.3.1) >>
-endobj
-116 0 obj
-(3.3.1 Tools for Use With the Name Server Daemon)
-endobj
-117 0 obj
-<< /S /GoTo /D (subsubsection.3.3.1.1) >>
-endobj
-120 0 obj
-(3.3.1.1 Diagnostic Tools)
-endobj
-121 0 obj
-<< /S /GoTo /D (subsubsection.3.3.1.2) >>
-endobj
-124 0 obj
-(3.3.1.2 Administrative Tools)
-endobj
-125 0 obj
-<< /S /GoTo /D (subsection.3.3.2) >>
-endobj
-128 0 obj
-(3.3.2 Signals)
-endobj
-129 0 obj
-<< /S /GoTo /D (chapter.4) >>
-endobj
-132 0 obj
-(4 Advanced DNS Features)
-endobj
-133 0 obj
-<< /S /GoTo /D (section.4.1) >>
-endobj
-136 0 obj
-(4.1 Notify)
-endobj
-137 0 obj
-<< /S /GoTo /D (section.4.2) >>
-endobj
-140 0 obj
-(4.2 Dynamic Update)
-endobj
-141 0 obj
-<< /S /GoTo /D (subsection.4.2.1) >>
-endobj
-144 0 obj
-(4.2.1 The journal file)
-endobj
-145 0 obj
-<< /S /GoTo /D (section.4.3) >>
-endobj
-148 0 obj
-(4.3 Incremental Zone Transfers \(IXFR\))
-endobj
-149 0 obj
-<< /S /GoTo /D (section.4.4) >>
-endobj
-152 0 obj
-(4.4 Split DNS)
-endobj
-153 0 obj
-<< /S /GoTo /D (subsection.4.4.1) >>
-endobj
-156 0 obj
-(4.4.1 Example split DNS setup)
-endobj
-157 0 obj
-<< /S /GoTo /D (section.4.5) >>
-endobj
-160 0 obj
-(4.5 TSIG)
-endobj
-161 0 obj
-<< /S /GoTo /D (subsection.4.5.1) >>
-endobj
-164 0 obj
-(4.5.1 Generate Shared Keys for Each Pair of Hosts)
-endobj
-165 0 obj
-<< /S /GoTo /D (subsubsection.4.5.1.1) >>
-endobj
-168 0 obj
-(4.5.1.1 Automatic Generation)
-endobj
-169 0 obj
-<< /S /GoTo /D (subsubsection.4.5.1.2) >>
-endobj
-172 0 obj
-(4.5.1.2 Manual Generation)
-endobj
-173 0 obj
-<< /S /GoTo /D (subsection.4.5.2) >>
-endobj
-176 0 obj
-(4.5.2 Copying the Shared Secret to Both Machines)
-endobj
-177 0 obj
-<< /S /GoTo /D (subsection.4.5.3) >>
-endobj
-180 0 obj
-(4.5.3 Informing the Servers of the Key's Existence)
-endobj
-181 0 obj
-<< /S /GoTo /D (subsection.4.5.4) >>
-endobj
-184 0 obj
-(4.5.4 Instructing the Server to Use the Key)
-endobj
-185 0 obj
-<< /S /GoTo /D (subsection.4.5.5) >>
-endobj
-188 0 obj
-(4.5.5 TSIG Key Based Access Control)
-endobj
-189 0 obj
-<< /S /GoTo /D (subsection.4.5.6) >>
-endobj
-192 0 obj
-(4.5.6 Errors)
-endobj
-193 0 obj
-<< /S /GoTo /D (section.4.6) >>
-endobj
-196 0 obj
-(4.6 TKEY)
-endobj
-197 0 obj
-<< /S /GoTo /D (section.4.7) >>
-endobj
-200 0 obj
-(4.7 SIG\(0\))
-endobj
-201 0 obj
-<< /S /GoTo /D (section.4.8) >>
-endobj
-204 0 obj
-(4.8 DNSSEC)
-endobj
-205 0 obj
-<< /S /GoTo /D (subsection.4.8.1) >>
-endobj
-208 0 obj
-(4.8.1 Generating Keys)
-endobj
-209 0 obj
-<< /S /GoTo /D (subsection.4.8.2) >>
-endobj
-212 0 obj
-(4.8.2 Signing the Zone)
-endobj
-213 0 obj
-<< /S /GoTo /D (subsection.4.8.3) >>
-endobj
-216 0 obj
-(4.8.3 Configuring Servers)
-endobj
-217 0 obj
-<< /S /GoTo /D (section.4.9) >>
-endobj
-220 0 obj
-(4.9 IPv6 Support in BIND 9)
-endobj
-221 0 obj
-<< /S /GoTo /D (subsection.4.9.1) >>
-endobj
-224 0 obj
-(4.9.1 Address Lookups Using AAAA Records)
-endobj
-225 0 obj
-<< /S /GoTo /D (subsection.4.9.2) >>
-endobj
-228 0 obj
-(4.9.2 Address to Name Lookups Using Nibble Format)
-endobj
-229 0 obj
-<< /S /GoTo /D (chapter.5) >>
-endobj
-232 0 obj
-(5 The BIND 9 Lightweight Resolver)
-endobj
-233 0 obj
-<< /S /GoTo /D (section.5.1) >>
-endobj
-236 0 obj
-(5.1 The Lightweight Resolver Library)
-endobj
-237 0 obj
-<< /S /GoTo /D (section.5.2) >>
-endobj
-240 0 obj
-(5.2 Running a Resolver Daemon)
-endobj
-241 0 obj
-<< /S /GoTo /D (chapter.6) >>
-endobj
-244 0 obj
-(6 BIND 9 Configuration Reference)
-endobj
-245 0 obj
-<< /S /GoTo /D (section.6.1) >>
-endobj
-248 0 obj
-(6.1 Configuration File Elements)
-endobj
-249 0 obj
-<< /S /GoTo /D (subsection.6.1.1) >>
-endobj
-252 0 obj
-(6.1.1 Address Match Lists)
-endobj
-253 0 obj
-<< /S /GoTo /D (subsubsection.6.1.1.1) >>
-endobj
-256 0 obj
-(6.1.1.1 Syntax)
-endobj
-257 0 obj
-<< /S /GoTo /D (subsubsection.6.1.1.2) >>
-endobj
-260 0 obj
-(6.1.1.2 Definition and Usage)
-endobj
-261 0 obj
-<< /S /GoTo /D (subsection.6.1.2) >>
-endobj
-264 0 obj
-(6.1.2 Comment Syntax)
-endobj
-265 0 obj
-<< /S /GoTo /D (subsubsection.6.1.2.1) >>
-endobj
-268 0 obj
-(6.1.2.1 Syntax)
-endobj
-269 0 obj
-<< /S /GoTo /D (subsubsection.6.1.2.2) >>
-endobj
-272 0 obj
-(6.1.2.2 Definition and Usage)
-endobj
-273 0 obj
-<< /S /GoTo /D (section.6.2) >>
-endobj
-276 0 obj
-(6.2 Configuration File Grammar)
-endobj
-277 0 obj
-<< /S /GoTo /D (subsection.6.2.1) >>
-endobj
-280 0 obj
-(6.2.1 acl Statement Grammar)
-endobj
-281 0 obj
-<< /S /GoTo /D (subsection.6.2.2) >>
-endobj
-284 0 obj
-(6.2.2 acl Statement Definition and Usage)
-endobj
-285 0 obj
-<< /S /GoTo /D (subsection.6.2.3) >>
-endobj
-288 0 obj
-(6.2.3 controls Statement Grammar)
-endobj
-289 0 obj
-<< /S /GoTo /D (subsection.6.2.4) >>
-endobj
-292 0 obj
-(6.2.4 controls Statement Definition and Usage)
-endobj
-293 0 obj
-<< /S /GoTo /D (subsection.6.2.5) >>
-endobj
-296 0 obj
-(6.2.5 include Statement Grammar)
-endobj
-297 0 obj
-<< /S /GoTo /D (subsection.6.2.6) >>
-endobj
-300 0 obj
-(6.2.6 include Statement Definition and Usage)
-endobj
-301 0 obj
-<< /S /GoTo /D (subsection.6.2.7) >>
-endobj
-304 0 obj
-(6.2.7 key Statement Grammar)
-endobj
-305 0 obj
-<< /S /GoTo /D (subsection.6.2.8) >>
-endobj
-308 0 obj
-(6.2.8 key Statement Definition and Usage)
-endobj
-309 0 obj
-<< /S /GoTo /D (subsection.6.2.9) >>
-endobj
-312 0 obj
-(6.2.9 logging Statement Grammar)
-endobj
-313 0 obj
-<< /S /GoTo /D (subsection.6.2.10) >>
-endobj
-316 0 obj
-(6.2.10 logging Statement Definition and Usage)
-endobj
-317 0 obj
-<< /S /GoTo /D (subsubsection.6.2.10.1) >>
-endobj
-320 0 obj
-(6.2.10.1 The channel Phrase)
-endobj
-321 0 obj
-<< /S /GoTo /D (subsubsection.6.2.10.2) >>
-endobj
-324 0 obj
-(6.2.10.2 The category Phrase)
-endobj
-325 0 obj
-<< /S /GoTo /D (subsection.6.2.11) >>
-endobj
-328 0 obj
-(6.2.11 lwres Statement Grammar)
-endobj
-329 0 obj
-<< /S /GoTo /D (subsection.6.2.12) >>
-endobj
-332 0 obj
-(6.2.12 lwres Statement Definition and Usage)
-endobj
-333 0 obj
-<< /S /GoTo /D (subsection.6.2.13) >>
-endobj
-336 0 obj
-(6.2.13 masters Statement Grammar)
-endobj
-337 0 obj
-<< /S /GoTo /D (subsection.6.2.14) >>
-endobj
-340 0 obj
-(6.2.14 masters Statement Definition and Usage)
-endobj
-341 0 obj
-<< /S /GoTo /D (subsection.6.2.15) >>
-endobj
-344 0 obj
-(6.2.15 options Statement Grammar)
-endobj
-345 0 obj
-<< /S /GoTo /D (subsection.6.2.16) >>
-endobj
-348 0 obj
-(6.2.16 options Statement Definition and Usage)
-endobj
-349 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.1) >>
-endobj
-352 0 obj
-(6.2.16.1 Boolean Options)
-endobj
-353 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.2) >>
-endobj
-356 0 obj
-(6.2.16.2 Forwarding)
-endobj
-357 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.3) >>
-endobj
-360 0 obj
-(6.2.16.3 Dual-stack Servers)
-endobj
-361 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.4) >>
-endobj
-364 0 obj
-(6.2.16.4 Access Control)
-endobj
-365 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.5) >>
-endobj
-368 0 obj
-(6.2.16.5 Interfaces)
-endobj
-369 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.6) >>
-endobj
-372 0 obj
-(6.2.16.6 Query Address)
-endobj
-373 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.7) >>
-endobj
-376 0 obj
-(6.2.16.7 Zone Transfers)
-endobj
-377 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.8) >>
-endobj
-380 0 obj
-(6.2.16.8 Bad UDP Port Lists)
-endobj
-381 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.9) >>
-endobj
-384 0 obj
-(6.2.16.9 Operating System Resource Limits)
-endobj
-385 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.10) >>
-endobj
-388 0 obj
-(6.2.16.10 Server Resource Limits)
-endobj
-389 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.11) >>
-endobj
-392 0 obj
-(6.2.16.11 Periodic Task Intervals)
-endobj
-393 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.12) >>
-endobj
-396 0 obj
-(6.2.16.12 Topology)
-endobj
-397 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.13) >>
-endobj
-400 0 obj
-(6.2.16.13 The sortlist Statement)
-endobj
-401 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.14) >>
-endobj
-404 0 obj
-(6.2.16.14 RRset Ordering)
-endobj
-405 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.15) >>
-endobj
-408 0 obj
-(6.2.16.15 Tuning)
-endobj
-409 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.16) >>
-endobj
-412 0 obj
-(6.2.16.16 Built-in server information zones)
-endobj
-413 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.17) >>
-endobj
-416 0 obj
-(6.2.16.17 Built-in Empty Zones)
-endobj
-417 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.18) >>
-endobj
-420 0 obj
-(6.2.16.18 The Statistics File)
-endobj
-421 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.19) >>
-endobj
-424 0 obj
-(6.2.16.19 Additional Section Caching)
-endobj
-425 0 obj
-<< /S /GoTo /D (subsection.6.2.17) >>
-endobj
-428 0 obj
-(6.2.17 server Statement Grammar)
-endobj
-429 0 obj
-<< /S /GoTo /D (subsection.6.2.18) >>
-endobj
-432 0 obj
-(6.2.18 server Statement Definition and Usage)
-endobj
-433 0 obj
-<< /S /GoTo /D (subsection.6.2.19) >>
-endobj
-436 0 obj
-(6.2.19 trusted-keys Statement Grammar)
-endobj
-437 0 obj
-<< /S /GoTo /D (subsection.6.2.20) >>
-endobj
-440 0 obj
-(6.2.20 trusted-keys Statement Definition and Usage)
-endobj
-441 0 obj
-<< /S /GoTo /D (subsection.6.2.21) >>
-endobj
-444 0 obj
-(6.2.21 view Statement Grammar)
-endobj
-445 0 obj
-<< /S /GoTo /D (subsection.6.2.22) >>
-endobj
-448 0 obj
-(6.2.22 view Statement Definition and Usage)
-endobj
-449 0 obj
-<< /S /GoTo /D (subsection.6.2.23) >>
-endobj
-452 0 obj
-(6.2.23 zone Statement Grammar)
-endobj
-453 0 obj
-<< /S /GoTo /D (subsection.6.2.24) >>
-endobj
-456 0 obj
-(6.2.24 zone Statement Definition and Usage)
-endobj
-457 0 obj
-<< /S /GoTo /D (subsubsection.6.2.24.1) >>
-endobj
-460 0 obj
-(6.2.24.1 Zone Types)
-endobj
-461 0 obj
-<< /S /GoTo /D (subsubsection.6.2.24.2) >>
-endobj
-464 0 obj
-(6.2.24.2 Class)
-endobj
-465 0 obj
-<< /S /GoTo /D (subsubsection.6.2.24.3) >>
-endobj
-468 0 obj
-(6.2.24.3 Zone Options)
-endobj
-469 0 obj
-<< /S /GoTo /D (subsubsection.6.2.24.4) >>
-endobj
-472 0 obj
-(6.2.24.4 Dynamic Update Policies)
-endobj
-473 0 obj
-<< /S /GoTo /D (section.6.3) >>
-endobj
-476 0 obj
-(6.3 Zone File)
-endobj
-477 0 obj
-<< /S /GoTo /D (subsection.6.3.1) >>
-endobj
-480 0 obj
-(6.3.1 Types of Resource Records and When to Use Them)
-endobj
-481 0 obj
-<< /S /GoTo /D (subsubsection.6.3.1.1) >>
-endobj
-484 0 obj
-(6.3.1.1 Resource Records)
-endobj
-485 0 obj
-<< /S /GoTo /D (subsubsection.6.3.1.2) >>
-endobj
-488 0 obj
-(6.3.1.2 Textual expression of RRs)
-endobj
-489 0 obj
-<< /S /GoTo /D (subsection.6.3.2) >>
-endobj
-492 0 obj
-(6.3.2 Discussion of MX Records)
-endobj
-493 0 obj
-<< /S /GoTo /D (subsection.6.3.3) >>
-endobj
-496 0 obj
-(6.3.3 Setting TTLs)
-endobj
-497 0 obj
-<< /S /GoTo /D (subsection.6.3.4) >>
-endobj
-500 0 obj
-(6.3.4 Inverse Mapping in IPv4)
-endobj
-501 0 obj
-<< /S /GoTo /D (subsection.6.3.5) >>
-endobj
-504 0 obj
-(6.3.5 Other Zone File Directives)
-endobj
-505 0 obj
-<< /S /GoTo /D (subsubsection.6.3.5.1) >>
-endobj
-508 0 obj
-(6.3.5.1 The \044ORIGIN Directive)
-endobj
-509 0 obj
-<< /S /GoTo /D (subsubsection.6.3.5.2) >>
-endobj
-512 0 obj
-(6.3.5.2 The \044INCLUDE Directive)
-endobj
-513 0 obj
-<< /S /GoTo /D (subsubsection.6.3.5.3) >>
-endobj
-516 0 obj
-(6.3.5.3 The \044TTL Directive)
-endobj
-517 0 obj
-<< /S /GoTo /D (subsection.6.3.6) >>
-endobj
-520 0 obj
-(6.3.6 BIND Master File Extension: the \044GENERATE Directive)
-endobj
-521 0 obj
-<< /S /GoTo /D (subsection.6.3.7) >>
-endobj
-524 0 obj
-(6.3.7 Additional File Formats)
-endobj
-525 0 obj
-<< /S /GoTo /D (chapter.7) >>
-endobj
-528 0 obj
-(7 BIND 9 Security Considerations)
-endobj
-529 0 obj
-<< /S /GoTo /D (section.7.1) >>
-endobj
-532 0 obj
-(7.1 Access Control Lists)
-endobj
-533 0 obj
-<< /S /GoTo /D (section.7.2) >>
-endobj
-536 0 obj
-(7.2 Chroot and Setuid)
-endobj
-537 0 obj
-<< /S /GoTo /D (subsection.7.2.1) >>
-endobj
-540 0 obj
-(7.2.1 The chroot Environment)
-endobj
-541 0 obj
-<< /S /GoTo /D (subsection.7.2.2) >>
-endobj
-544 0 obj
-(7.2.2 Using the setuid Function)
-endobj
-545 0 obj
-<< /S /GoTo /D (section.7.3) >>
-endobj
-548 0 obj
-(7.3 Dynamic Update Security)
-endobj
-549 0 obj
-<< /S /GoTo /D (chapter.8) >>
-endobj
-552 0 obj
-(8 Troubleshooting)
-endobj
-553 0 obj
-<< /S /GoTo /D (section.8.1) >>
-endobj
-556 0 obj
-(8.1 Common Problems)
-endobj
-557 0 obj
-<< /S /GoTo /D (subsection.8.1.1) >>
-endobj
-560 0 obj
-(8.1.1 It's not working; how can I figure out what's wrong?)
-endobj
-561 0 obj
-<< /S /GoTo /D (section.8.2) >>
-endobj
-564 0 obj
-(8.2 Incrementing and Changing the Serial Number)
-endobj
-565 0 obj
-<< /S /GoTo /D (section.8.3) >>
-endobj
-568 0 obj
-(8.3 Where Can I Get Help?)
-endobj
-569 0 obj
-<< /S /GoTo /D (appendix.A) >>
-endobj
-572 0 obj
-(A Appendices)
-endobj
-573 0 obj
-<< /S /GoTo /D (section.A.1) >>
-endobj
-576 0 obj
-(A.1 Acknowledgments)
-endobj
-577 0 obj
-<< /S /GoTo /D (subsection.A.1.1) >>
-endobj
-580 0 obj
-(A.1.1 A Brief History of the DNS and BIND)
-endobj
-581 0 obj
-<< /S /GoTo /D (section.A.2) >>
-endobj
-584 0 obj
-(A.2 General DNS Reference Information)
-endobj
-585 0 obj
-<< /S /GoTo /D (subsection.A.2.1) >>
-endobj
-588 0 obj
-(A.2.1 IPv6 addresses \(AAAA\))
-endobj
-589 0 obj
-<< /S /GoTo /D (section.A.3) >>
-endobj
-592 0 obj
-(A.3 Bibliography \(and Suggested Reading\))
-endobj
-593 0 obj
-<< /S /GoTo /D (subsection.A.3.1) >>
-endobj
-596 0 obj
-(A.3.1 Request for Comments \(RFCs\))
-endobj
-597 0 obj
-<< /S /GoTo /D (subsection.A.3.2) >>
-endobj
-600 0 obj
-(A.3.2 Internet Drafts)
-endobj
-601 0 obj
-<< /S /GoTo /D (subsection.A.3.3) >>
-endobj
-604 0 obj
-(A.3.3 Other Documents About BIND)
-endobj
-605 0 obj
-<< /S /GoTo /D (appendix.B) >>
-endobj
-608 0 obj
-(B Manual pages)
-endobj
-609 0 obj
-<< /S /GoTo /D (section.B.1) >>
-endobj
-612 0 obj
-(B.1 dig)
-endobj
-613 0 obj
-<< /S /GoTo /D (section.B.2) >>
-endobj
-616 0 obj
-(B.2 host)
-endobj
-617 0 obj
-<< /S /GoTo /D (section.B.3) >>
-endobj
-620 0 obj
-(B.3 dnssec-keygen)
-endobj
-621 0 obj
-<< /S /GoTo /D (section.B.4) >>
-endobj
-624 0 obj
-(B.4 dnssec-signzone)
-endobj
-625 0 obj
-<< /S /GoTo /D (section.B.5) >>
-endobj
-628 0 obj
-(B.5 named-checkconf)
-endobj
-629 0 obj
-<< /S /GoTo /D (section.B.6) >>
-endobj
-632 0 obj
-(B.6 named-checkzone)
-endobj
-633 0 obj
-<< /S /GoTo /D (section.B.7) >>
-endobj
-636 0 obj
-(B.7 named)
-endobj
-637 0 obj
-<< /S /GoTo /D (section.B.8) >>
-endobj
-640 0 obj
-(B.8 rndc)
-endobj
-641 0 obj
-<< /S /GoTo /D (section.B.9) >>
-endobj
-644 0 obj
-(B.9 rndc.conf)
-endobj
-645 0 obj
-<< /S /GoTo /D (section.B.10) >>
-endobj
-648 0 obj
-(B.10 rndc-confgen)
-endobj
-649 0 obj
-<< /S /GoTo /D [650 0 R  /FitH ] >>
-endobj
-653 0 obj <<
-/Length 236       
-/Filter /FlateDecode
->>
-stream
-xÚ��ÁJA†ïó9¶‡M'™d2s´T¥‚Beoâai·Rp·t­ïïÔÕ*êArÉÿ‘ü	�/A�}È–ՓºsžŠvíèƒ
¨B)þP+!ÃlQ¡bJÕÂwìNì1úÈP©)&>áóÚÍ®˜€-A½bEM¦pæêÍÃd¾¼[L+V?ÉcºØt»~÷ršã~[÷í¶Ú~ÝNë a¤(±ø˘’å÷9·MÿÚ<Ÿ
-endobj
-650 0 obj <<
-/Type /Page
-/Contents 653 0 R
-/Resources 652 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 659 0 R
->> endobj
-651 0 obj <<
-/Type /XObject
-/Subtype /Form
-/FormType 1
-/PTEX.FileName (./isc-logo.pdf)
-/PTEX.PageNumber 1
-/PTEX.InfoDict 660 0 R 
-/Matrix [1.00000000 0.00000000 0.00000000 1.00000000 0.00000000 0.00000000]
-/BBox [0.00000000 0.00000000 255.00000000 149.00000000]
-/Resources <<
-/ProcSet [ /PDF /Text ]
-/ColorSpace <<
-/R15 661 0 R
-/R9 662 0 R
-/R11 663 0 R
-/R13 664 0 R
->>/ExtGState <<
-/R17 665 0 R
-/R8 666 0 R
->>/Font << /R19 667 0 R >>
->>
-/Length 668 0 R
-/Filter /FlateDecode
->>
-stream
-xœu˜;“d9…ýû+®Ùe´�R©—�
lG`XËkz#†10gwÙ~6ßÉ[53}+ˆ}tI%åóäÉT½ßs*{Ö?·¿××í'¿�ûŸ?lï·¼Ÿ#5Û_7}÷n³æ3õùæóýÌ»íwû7\^ûõÃVö×oøÿ_·ÒvþmÕSéœmqöÚ¾æh)ŸÏŽ™,ײ—Zjj•ÅVÊ•ëµÍÔÆn¹§±†Ö5͵[+i6}Ÿk’¨Í–§ºØ±ÖRöÝVIƒe´Ä¶yKfZWTp¾ÜÏç9ùÀ–ÆŒõÒý>R_­êÂJsJƒ¥.ŸËÊiôÝ×\
-û”_g'®Û_6´§ÖØËÍ“[8føƒ”œKj“È4­¹¯5Ã#6ÆJ²4·œª+ÚøاkÇä~¤ž19wR7ñm¦U%s˜,ÃT|
-Û2Æ�‚ŒjUçq¥K"ηbøR<™¬¨™ãŸ¹×²RU|Ñ$ÞÕZ*Š–ŒCõu«|ˆhL$,I˜–¼`¥Y|ÃNżŠLó’#pÕ‹BÖŽj9--	9@‘
€DÌ©….¶áJ{N]Á©¥Z*zÃ3…?´T®²$À“%ÁXF°Zê%.ä’@ŽO­—€!$t\'<Ž¶*W
-èj˵ãB;Žþ"%«ê;¥+ßÚ)Éú¾Œ¤IJ�5yÝGN>³ʧ*=5Dt'ŸtˇÀùiQ{
-˜‚ÚIq%˜3vH­wÁKAįr‹þq n[Uz¯!*â)ôàKG°€ÝgG-dL#¹X0¹Â“@ñ´×£^ëµ½æ
HÕÊ_7S41Ã,ëÀO%ê*\ç/1v¢\¨Î¡¨êG´P:‘Sœ¸1ÀÞ£q‹uc¤,¯J¶”e—	'‚;	F/É&N(AWÖšNfãÀŠq‚ì’htËØ“ªØOàÙ‰GÎ4óHD'ª:SÙ#Oœ™äD4�Ltæª3—=�Ý™p�ÂSè¬F$_)^"åÛ•.ªd­Ôd´ÁJŒÓ¤¨,à}‹F:I
òP<Á:‚é¡û½¶H­JŒŒÀvÎ9±”8G
-%S}8\Ž»Ä{!•pŸjyî8NíÖL-»Ä¼1_yk¦“ˆÔøèus‘#¸W�™˜ÁAŹ{�0º¤Œ4±�à8pª0ŠÚž]#HªiÓºhS”28Ú*7»Å'¤«ÎwMpíD¦9d=‹rêÀ Öd
ðlÎmF1Û\Ój�Í J$¾›ƒlHO†¯,x!Fàqê*i!ߪ‰ž£‘\·î"o6,âM(¨$‡^êP^Å>˜³ÔV¬ˆ¦#Z†ª¼§?Áj¹“LÃ¥R»š¨¦VÅo€Ž
–eõT¥Ø€ùU¢Ù�Ü*
„2ÊNvÊ@ÈËY#E?°+êEn�£±¦h“ÊFØläƒbY3Âc0CEW'ñÖÆ4€»Öm"ŒÙ©˜94A¬#—ª Áõ¢ÙëN)ÅZþÅÖ…µˆ‘ç#µxì‡Ð:Å ÑqYŠ�¢ŽÞ\U¢ÜÆÕ²hb	\´ÑP£’šð¢>�Ô9Ž¨Ñ¸ˆùUm!‰§¢�Zh!ú‹~(Ât~¿ÙA,«×
>*"œD�
0QEuÑ|Îóî`‰ö™%„U™&2WjDó5EŠ)€®ä
-«SÕ0Ý4jÆ0çU6Ñœ5Õ”ê0*ÊBóî"gܲ¥–ÃÄHgæ:2®xļô¨	¤èC�úð¨�˜*#{ëÖâsôÎ
-¯Éæ’×M�¼1ÖQQ½»î0@yP,£§"cf
6‹ÃH%aDšjÑ÷ÄPjëš(²f§ Ø®ì·q,fÙLhgÌŒ#Çd±0xDÉYWíû¾0yš’*á_�àºFî®.˜tƨj²ùKÐõàº5£7¬bi«¸3׽Ŕ
-óÔPĮ́Yu¢e¢�a�5
エ0kÓ,¤×äþ¤V��¡Ò(*�Gãë0[;=‚ÃátçX3pD¦iÜ'ÃëÑ+a�qz JC	"Ê1�ô(Œ
-FÑÞIca­Ç0Ú)	¹A¿+�ÇÀº
�¸|-Tuùa>‚s:½¯•~K
“ÒÞV�׋„OÒAŠI…
�ɪÁr2Q“°Ø¨Á>.z
-ÏÆ狼eÇNdæÌdï"gK2cëÉ—GoOá8GëÏϦ:B
Àht[
-endobj
-660 0 obj
-<<
-/Producer (AFPL Ghostscript 8.51)
-/CreationDate (D:20050606145621)
-/ModDate (D:20050606145621)
-/Title (Alternate-ISC-logo-v2.ai)
-/Creator (Adobe Illustrator\(R\) 11)
-/Author (Douglas E. Appelt)
->>
-endobj
-661 0 obj
-[/Separation/PANTONE#201805#20C/DeviceCMYK 669 0 R]
-endobj
-662 0 obj
-[/Separation/PANTONE#207506#20C/DeviceCMYK 670 0 R]
-endobj
-663 0 obj
-[/Separation/PANTONE#20301#20C/DeviceCMYK 671 0 R]
-endobj
-664 0 obj
-[/Separation/PANTONE#20871#20C/DeviceCMYK 672 0 R]
-endobj
-665 0 obj
-<<
-/Type /ExtGState
-/SA true
->>
-endobj
-666 0 obj
-<<
-/Type /ExtGState
-/OPM 1
->>
-endobj
-667 0 obj
-<<
-/BaseFont /NVXWCK#2BTrajanPro-Bold
-/FontDescriptor 673 0 R
-/Type /Font
-/FirstChar 67
-/LastChar 136
-/Widths [ 800 0 0 0 0 0 452 0 0 0 0 0 0 0 0 0 582 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 841 633 576 686 590 540 923 827 407 760]
-/Encoding 674 0 R
-/Subtype /Type1
->>
-endobj
-668 0 obj
-2362
-endobj
-669 0 obj
-<<
-/Filter /FlateDecode
-/FunctionType 4
-/Domain [ 0 1]
-/Range [ 0 1 0 1 0 1 0 1]
-/Length 39
->>
-stream
-xœ«N)-P0PÈ-ÍQH­HÎP
-endobj
-670 0 obj
-<<
-/Filter /FlateDecode
-/FunctionType 4
-/Domain [ 0 1]
-/Range [ 0 1 0 1 0 1 0 1]
-/Length 36
->>
-stream
-xœ«N)-P0PÈ-ÍQH­HÎP
-endobj
-671 0 obj
-<<
-/Filter /FlateDecode
-/FunctionType 4
-/Domain [ 0 1]
-/Range [ 0 1 0 1 0 1 0 1]
-/Length 40
->>
-stream
-xœ«N)-P0TÈ-ÍQH­HÎP
-endobj
-672 0 obj
-<<
-/Filter /FlateDecode
-/FunctionType 4
-/Domain [ 0 1]
-/Range [ 0 1 0 1 0 1 0 1]
-/Length 50
->>
-stream
-xœ«N)-P0Ð365³TÈ-ÍQH­HÎP€Š™X ‹™›#Äô-,ŒÀüZ
-endobj
-673 0 obj
-<<
-/Type /FontDescriptor
-/FontName /NVXWCK#2BTrajanPro-Bold
-/FontBBox [ -45 -17 923 767]
-/Flags 4
-/Ascent 767
-/CapHeight 767
-/Descent -17
-/ItalicAngle 0
-/StemV 138
-/MissingWidth 500
-/CharSet (/Msmall/C/Ysmall/Nsmall/Osmall/Esmall/Rsmall/S/Ssmall/I/Tsmall/Ismall/Usmall)
-/FontFile3 675 0 R
->>
-endobj
-674 0 obj
-<<
-/Type /Encoding
-/BaseEncoding /WinAnsiEncoding
-/Differences [ 127/Nsmall/Tsmall/Esmall/Rsmall/Ysmall/Ssmall/Msmall/Osmall/Ismall/Usmall]
->>
-endobj
-675 0 obj
-<<
-/Filter /FlateDecode
-/Subtype /Type1C
-/Length 2657
->>
-stream
-xœ}VkpUž!!i0dHÈ:=«°î"ŠÏ*QpYWÊD@p• ‘$$�ç$!a2ïžé×éîéǼ’ÌäÍC
Ãû)Á]^º+–B-®k)ZˆËµîÄf‹½´J«¬ýÓÕ÷ÜÛçÜïœï|§Í¦Ì1&³Ù<q™£d]IM‘£ö¾§j«J
ÓŒt�y•óûÙ#ÚØ;M¦7Õ	�“
9™§~•c�Œ†oGÛ&¢ŽIÆÁãjë6:*×V4Úzà�ìóKk_+³/ÝØÐXVÝ`/¬YS먫u”4–•ÞoŸ_Ue_bm°/)k(slÀÆ[¡í•
ö²ÊÆŠ2‡½Äî([[‰?w”•Ú%¥eÕ%ŽõöZcç'ËòÿÉ^YcǾì/ÖT«¥�ØØ`/©)��½ÔŽFYSÛTÓè¨,k¸ßd2MX°´0Dyi ècX“iºéÓL³Í<ÓLšíæ)æ»ÍÓÍ3ÌÓÌ¿1åâ|™^0!óæ13ò2­™h쬞ì=ÄêqóÇ}>þdš…Ãhëôõa3NO?œ
™iv¤è›…$}ت?‰´±èË,Ý®³"cqC;‘µjô=©ãuVú¨ÕxÓ�UîÈçðÈœCæè×éÎþŒt§Óz>Tww$Õ°,'£ÛãŸBœÐ85HqL+kc6zjœ-kŠ_ô?„>M/DãQàZçÕçɽ»Oö|
-_Àź�ŠþúD…PE¸EJ‹ˆZ»`»øâ€8(ÅA…‘}Bµ´>R&+åáE ÿf­YPxïÃôñðÌܤg~ý(qe.Ê®Fw‘›¾ä<8ò§ý“?ßúzñÛW»§Z>CšÓjùè¼9üÆûzÞƒa¸ºú=}•Úî¼ÇN7Â~â�}CØ,ÎÂÖêö–îz¹
-„W
-©š¤õ\o…„
TZ
-ˆõjIt!†CΞ«�y|×ÓhÌ£¤åËýk?^Ø^/ç/õùmþ ÉF'™nH	P¬ÏÅÛøVf1,ƒ&‰î–ÏZ†ö‡rÓ/±©‘Ò”=†&eàÇn+Ì„¹t	[r63
Î˹€ð2,TÙ¹NK½°N³çàpÎÝ1MReZò¹šDÑMV‡ƒ)v33—à�þ˜
hlßµäf9.jBˆ¨"j
-%zÈ2(bPÏIe†§VŠQ
-�'x6FöÐQ§X)®‡ZÐg¹ßÏÆwÌk6'¾¿+ãóËV¦–ªl`Ý\‚@h†¡T.Bn�·¤$tÀnv§á0¡‰Z8¦(J�\¤Kò*x¯Mˆ‰ío¡Oò¤¬­EGíjk´áïú”îÒ¶ú¨3Q�µ®Ýè…ô$¼èF¦ÔÀùi.?Ä1,0@ËL7?È¡Û™ Q<$Q>· :È:�ꥎ=‘îÉcSþH( ‚A·î»Ñ˜§ûÒ5ÞÞP8
-n¨`×rŽ`ëF†â|¼?C3A•‹“pJê�>8Åž0`ÅUI	Ó²ßÛ"à$Ö‡©®ŸÛ
ƒÐF¼›
[¸M‰m;Ðd´jëöÎ^MëŒ$”Žpç]
+rHô“Nx�k�z¨k`(¨ñG¶³a|oð1®@‹§Þ®/ô5»úôlôJë¦`œ‰‚
-ªVŶ° 
--R¶5ðöU…¢Ëðåq¡�ª±v:#“�TsOÕ¶U(G_¬xâm#¹#—ÙTpÃȤd{ód4åÌMóqŸé¦ižÏ4Õ2€3¿Ú*e%]_Nÿj6a©úâ!4æ®/Eñ@;ªªu’Ñô€pPmïSóc’
-.9,«”à%WÃ:Î-°R,6îâ	ðAZbbñn d7¥¹„‘¹yL–'®�C9‹O–¤~º]ÏC¾˜«Ý›ða2…¼N’º!ðóÙÆÆP¾—m5jA…šÒø8¹SLÃ4ÚÞ­…&bö‡ýn§ »H§âëâÎa„ïº÷§ßßg>ˆ¦¤+ÐÔŒô,·5£»Ð}hZ¡ÛÐDÝ¡wÍЋôú½ßèQ„ܱߪ?~²¡¨eý«ø­Ûk‘¹éô¡•)eúÇ~Ô|À•Tqî¦c1[Ö5ÕÒæï¬Õ2ÇóàYf-ë 1‹Ë_|åç=>–fH|
-&–ê„n>ÚÝ)D6Á
-x¸
\3§gA34–ITž-‹R8õ-ǵÛö2ªWuÉ~Á!"(0Š*FÂ͢ùĨ¸SˆˆoÊQPˆ0¦šåiFäݸVN^_!Ô‚–bž "-Qy$ÑÎsªm¥Ä¡@·âJ=Ŧ¿íÝëL	ÍDËQÆTË?GúÓlRÎ$F*�4’ƒð6–š\`�Œª Ñ“Œô�öd]˜é`û™ü9¸DijeIÛ.q
-ȼLçÇ<;—*X³«¥×ÛGâ_Y1ET�ïƒ4ˆ
Ò-U…_>´üØ¢�æ}õï÷v¼
§ádù�#¹rÛŸå¥@ÔÁ\5l…hð<8Ús·
-»O·Øèv61Bá5*È<6ÞÍ,‡bh‘˜¶ž\Î]Çé#¹#ØÔÍ1Oúñ°Ï¤5oÂ]цÆß4}h˜î0$å,6ü¼”A,¯?/å;Rôcy6Ò½UJ¿§Y½X^é¶�ÙÉŸ‡‹º–�2¸K|o½Ø”/�Ȩ�/ƒ(Â2Ð#žNMKðrˆ
rœÛf9ËyZ¸Ú}$«Ö	õ–©) h`iÎGàAç÷´€H+Šˆ…Õ&*áX$žèìVŽhª”—›¾÷‡A1Ý£¤œÏ0‰÷—Hi éƒw~I(Áö2;à]¸L ™x4[¡OÜ,¾®ÆûÂQQ°”FdQ“ƒ¢�¬„%\î¢Åâ:Ó;ÈÑ”ÌEb1ž�’�¡ˆÿ§=$¸¥?Iš¿CÐõ�3¾C=VÐ'>·¯ôÌÒ+Ü~8	ç#;úÁ_£×á*qň+ô	8®‚ãÆpêŒ_YR”¾d%a	ç¡H\eÄõãDf£Ñ¨­ŽR[�kφG¸ù/WT®ò•A5”H¥ÛVoo8h�nû)¼ÞÃDn…ñ�ëqÌzfåhý&þcQbµXÇß‚çLŽúõ;{²Ðñðué¿ÊÛÙ†-©[SÄ-Û¼ÔyubÜ�ñhüm´œ4^Ë™ ääšLÿQ‹¡endstream
-endobj
-654 0 obj <<
-/D [650 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-655 0 obj <<
-/D [650 0 R /XYZ 85.0394 769.5949 null]
->> endobj
-652 0 obj <<
-/Font << /F21 658 0 R >>
-/XObject << /Im1 651 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-678 0 obj <<
-/Length 994       
-/Filter /FlateDecode
->>
-stream
-xÚµVË’¢JÝû,5¢­©¯Z҈ʂ83³°»‰hÅ+8ý÷7¡ªDÐÛ›‰.*«ò˜yòd@4?¢&29åšÅud`bh›ý
-Qm]»ÀÒíÏ¡[?NùËk5ú�~ÕŒ,ÌrÀ¦v|™ý*Ô˜"ËäV£ŠÂýí´›•"("6 Š±þ0SצњfkZÂòUv:d•Ø%e•íK±q‹CYœªü¼PØ
�ÁÀÂÀ¿(ÕýÄ­Ø’šÔÀK/‚F‘aš¦féZÏ�ÏÕUèñ5üŽºÌ‚¾Z¼�ú_êÒÿS]ÜêHZ“¶&»«n±«Þק±‡Y_bÔ×ÏĈSÓÖ,Ê€'ŸÉ§Àãkô­z¦�8¶I³.g™�öyYæÅApª
-±žËLÖ³
yG„�¡Üï‹m¾ëœ¬[aló²:åÏçJX½æršÊ›âwÅIýûCÇóéX”ÒýžW¯ÂR¸ú¤8K1w™ÄA‚ºëpß
AÜ0hSÚk&ò=Ëø/§54d+Igñ'ßf[Åv])KF_?²V1eÍöPTù&ëÕßÖ{ìÉÚ��ÙZ•Kÿúí­©ƒpšTß„ëJ wž•Í�ÀàbŽ˜Îêb-ĵH:÷ä˜EÓôiÄéЉ剟ˆuGßý‰7»úæ:‰BÔ;a;áDºÂ˜€8þB‚� †Ì;aê{Òùä§saÅÞ̉'âJÂó•‘nIi­~$ é\Q¼C>tƒÕÄg½äþbøª–{L¢©X^ìÎÁ1²ô¡óè~ú£-´fg"®Û–bGvS?
½$AŠƒXCÉ×ûîA<AxÞ2Rz=Jê�ï<ÒžF±Ê*Ó'KÏõ�àAi{nÃQ=mÛ#Ñ
-½YàϼÐõº™¢&ró°Ðµ	é¶\d<b­’ëœ2²ûÉE‹h•v©D=Ú@-ô®(·WãrWA NkëË—^ópÚz¦ŸÝš›7‰úôbª¿ˆî~x©|ýá5VÙƺ…˜mÓûo"jÃËbRÍ{õ†8Ì9e&½Ãü_®…dµendstream
-endobj
-677 0 obj <<
-/Type /Page
-/Contents 678 0 R
-/Resources 676 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 659 0 R
->> endobj
-679 0 obj <<
-/D [677 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-676 0 obj <<
-/Font << /F23 682 0 R /F14 685 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-688 0 obj <<
-/Length 2891      
-/Filter /FlateDecode
->>
-stream
-xÚí�MsÛȆïþ¼E:p2ß
-–˜
•U~}Àô )ÚB¼k¯E–¢$6ºÝž™%fÜý³Ô0®2=K2Íf¶X½à³k÷»7/„�6Š­”û&òÛ¹Q)3©Lfs|‘——/þøZŠ™Ô,I1»ü4ø2’I©²ÙåÕ?ŽN«²)Êf}üÏË?uˬ´íûùln%Ó©J»wŠã¹àœ�—M]]mͲ*[«g—!£³\è™M3–h.ÚPú_Ö׳þŇ­ØýûçØ
-W±ïëå*¯úoÞæ®x­]Δܫ�!$j2È�¢
-¤§àâ6¿<™îÏLñ9. u“¹@†X‚‹H¤ó�c™5™B\(à¢)òÛææ–g‡"dm2È�B«B 	ƒB‚t>ÔZ3cÅPC_Cœæ‹›ey=Z=¨Tì]±ùX™2+¹’øDBÀnŽ
#„ì\¿‰�#‰ƒB„ô>ŒJ2måPS˜PS¼®êÿäÝûUÇŠþN0_aB	ÚAö&³�)6¶Ô!؈ÄA±Az†É™²z¨4¬>bë
´“þvsÛ,ïný[>T·íò7Sö™®=‚X�®É0 C
-†-9"qP0ìxLJÇpî­³„%ÊMh­séO³_ž¿{åE.ÖÕ¦^€äÅ¿7˺XÁÙx4]ኟ9åi‘Sî�ëvi£i—#Ò³ë5v¸ ]ž¬Rý .Ã1÷~üôã¨OOÿºMQ÷¢OÓ<U‡Íòþ
-9žzaCâþÚÒ�'é=
-5ž't9*?;^£·w÷O“>?Cßk¾
-ãGyiKnSñSî,Hîä;Rw�"&Eé=l»¨Œ3-¸tBûщç¦ß¼�WåíC|×åÝf{EDÈÙT"°!AÄ–&±8"hïIÊ”û.
�F'~Çm«'€Ãhõlú™ƒ8�žÉâ#CJ|œ~JüH”ø¤w˜H\éΤ𜨰1ðç*÷¥ØËü6/])–Jsè-úR˜ ß“aB†LXO¡ÇaŠÄAÁDz0Í„0P•(r™çkü®2ÑÏç‘œßh‚ÌNÆRØ`å(l"qPØ�Þ‡	HKÆE%‰
-%Éåq&�ªêÖŸ
-¥ï±�D™*ÆÓ¬ŸÚ´ßH<¹ºwkØl»*òfSã=ábOÝBÄÄâV�b¼�_ŽÈÌ®×X±.βLôC¼[ˆïªfùÉ­ïÝ�ºGÏ“|ëeacê=ˆ
‰{pKlŠ°Hi¤÷@šIÝ°®<h°Åðê¡ÌWPØ}¼»Ê7�§‰9@ôCäó<™¡ÁŽB©H´å:”R[–d:
‚†õ!,øþUmjWÀƒÔ\¶§ é�›§qé�2¤ÈÁòQèDâ Ø!½‡ÁGif3뀰'u^.†6
-2¤PÁjÉñ&ÔX*¤÷€ŠoL–BE]*w·Ë—Š©=ÔB¿åp2LfRŒa™)Æ"qPŒ‘Þ‡¹LpæÒ—
da.;ûÞ¯3×þ¬h6wm‰¤öHßd8�!–‡‚#é ‘¥Ls
u4G]^œ¿9ž»7Vb_mS$H1•3lHp¶%µ?ô�ÅApF{ƒ�H-S\
-øƒÿÝÙ/ËuS”탙‰0ß™æ�•Éš#CJsœuJóH”æ¤÷AsiX
-M…­æ:h¾nêãô¨ý�èá·oðÐkƒ
h—#öùlk…lMf
R,`5("qP,�Þ„b‰Ð
ø˜Ž~]í»=Ãמ,Åzž%húg°º
-ÁîGÓäm2ƒÅR…Bb7ŠÊõ
-RDaYåxÏN,Š)Ò;ì]¥3"�ÃÂÖÕ�gk›uÔaëê«m‘‚S)CvdXg‚±Hb¤k ,I˜†–D·œ…Ó™ó7íÉï�å4ψ}µ

™J²#HÃz¤E‚ þåzø”¦¤ð ¥Ð¯òîââìÔ-töã)˜o•OþT¦3)$¬´ÄßxÁPáïþÌeÆÒØ'�·ªïAœ+·üR#M.ŠgÎ×3ÿ¦þ�çñç/àJàí”s®Aendstream
-endobj
-687 0 obj <<
-/Type /Page
-/Contents 688 0 R
-/Resources 686 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 659 0 R
-/Annots [ 691 0 R 692 0 R 693 0 R 694 0 R 695 0 R 696 0 R 697 0 R 698 0 R 699 0 R 700 0 R 701 0 R 702 0 R 703 0 R 704 0 R 705 0 R 706 0 R 707 0 R 708 0 R 709 0 R 710 0 R 711 0 R 712 0 R 713 0 R 714 0 R 715 0 R 716 0 R 717 0 R 718 0 R 719 0 R 720 0 R 721 0 R 722 0 R 723 0 R 724 0 R 725 0 R 726 0 R 727 0 R 728 0 R 729 0 R 730 0 R 731 0 R 732 0 R 733 0 R 734 0 R 735 0 R 736 0 R 737 0 R 738 0 R 739 0 R 740 0 R ]
->> endobj
-691 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [532.6051 688.709 539.579 697.2967]
-/Subtype /Link
-/A << /S /GoTo /D (chapter.1) >>
->> endobj
-692 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [532.6051 676.5858 539.579 685.4425]
-/Subtype /Link
-/A << /S /GoTo /D (section.1.1) >>
->> endobj
-693 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [532.6051 664.4876 539.579 673.3442]
-/Subtype /Link
-/A << /S /GoTo /D (section.1.2) >>
->> endobj
-694 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [532.6051 652.3894 539.579 661.246]
-/Subtype /Link
-/A << /S /GoTo /D (section.1.3) >>
->> endobj
-695 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [532.6051 640.1914 539.579 649.1477]
-/Subtype /Link
-/A << /S /GoTo /D (section.1.4) >>
->> endobj
-696 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [532.6051 628.0932 539.579 637.0495]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.1.4.1) >>
->> endobj
-697 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [532.6051 615.995 539.579 624.9512]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.1.4.2) >>
->> endobj
-698 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [532.6051 603.8967 539.579 612.853]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.1.4.3) >>
->> endobj
-699 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [532.6051 591.7985 539.579 600.7547]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.1.4.4) >>
->> endobj
-700 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [532.6051 579.7002 539.579 588.6565]
-/Subtype /Link
-/A << /S /GoTo /D (subsubsection.1.4.4.1) >>
->> endobj
-701 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [532.6051 567.6019 539.579 576.5582]
-/Subtype /Link
-/A << /S /GoTo /D (subsubsection.1.4.4.2) >>
->> endobj
-702 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [532.6051 555.5037 539.579 564.46]
-/Subtype /Link
-/A << /S /GoTo /D (subsubsection.1.4.4.3) >>
->> endobj
-703 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 543.4055 539.579 552.5112]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.1.4.5) >>
->> endobj
-704 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 531.3072 539.579 540.413]
-/Subtype /Link
-/A << /S /GoTo /D (subsubsection.1.4.5.1) >>
->> endobj
-705 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 519.209 539.579 528.3147]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.1.4.6) >>
->> endobj
-706 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 496.7003 539.579 505.4125]
-/Subtype /Link
-/A << /S /GoTo /D (chapter.2) >>
->> endobj
-707 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 484.5772 539.579 493.5832]
-/Subtype /Link
-/A << /S /GoTo /D (section.2.1) >>
->> endobj
-708 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 472.4789 539.579 481.485]
-/Subtype /Link
-/A << /S /GoTo /D (section.2.2) >>
->> endobj
-709 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 460.3806 539.579 469.3867]
-/Subtype /Link
-/A << /S /GoTo /D (section.2.3) >>
->> endobj
-710 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 448.2824 539.579 457.2885]
-/Subtype /Link
-/A << /S /GoTo /D (section.2.4) >>
->> endobj
-711 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 436.1841 539.579 445.1902]
-/Subtype /Link
-/A << /S /GoTo /D (section.2.5) >>
->> endobj
-712 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 413.4314 539.579 422.288]
-/Subtype /Link
-/A << /S /GoTo /D (chapter.3) >>
->> endobj
-713 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 401.353 539.579 410.4588]
-/Subtype /Link
-/A << /S /GoTo /D (section.3.1) >>
->> endobj
-714 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 389.2548 539.579 398.3605]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.3.1.1) >>
->> endobj
-715 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 377.1565 539.579 386.2623]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.3.1.2) >>
->> endobj
-716 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 365.1579 539.579 374.164]
-/Subtype /Link
-/A << /S /GoTo /D (section.3.2) >>
->> endobj
-717 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 353.0597 539.579 362.0658]
-/Subtype /Link
-/A << /S /GoTo /D (section.3.3) >>
->> endobj
-718 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 340.9614 539.579 349.9675]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.3.3.1) >>
->> endobj
-719 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 328.7635 539.579 337.8693]
-/Subtype /Link
-/A << /S /GoTo /D (subsubsection.3.3.1.1) >>
->> endobj
-720 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 316.6653 539.579 325.771]
-/Subtype /Link
-/A << /S /GoTo /D (subsubsection.3.3.1.2) >>
->> endobj
-721 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 304.567 539.579 313.6728]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.3.3.2) >>
->> endobj
-722 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 281.9139 539.579 290.7706]
-/Subtype /Link
-/A << /S /GoTo /D (chapter.4) >>
->> endobj
-723 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 269.8356 539.579 278.9413]
-/Subtype /Link
-/A << /S /GoTo /D (section.4.1) >>
->> endobj
-724 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 257.7373 539.579 266.8431]
-/Subtype /Link
-/A << /S /GoTo /D (section.4.2) >>
->> endobj
-725 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 245.6391 539.579 254.7448]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.4.2.1) >>
->> endobj
-726 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 233.5408 539.579 242.4971]
-/Subtype /Link
-/A << /S /GoTo /D (section.4.3) >>
->> endobj
-727 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 221.4426 539.579 230.3988]
-/Subtype /Link
-/A << /S /GoTo /D (section.4.4) >>
->> endobj
-728 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 209.3443 539.579 218.3006]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.4.4.1) >>
->> endobj
-729 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 197.2461 539.579 206.2023]
-/Subtype /Link
-/A << /S /GoTo /D (section.4.5) >>
->> endobj
-730 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 185.1478 539.579 194.1041]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.4.5.1) >>
->> endobj
-731 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 173.0496 539.579 182.0058]
-/Subtype /Link
-/A << /S /GoTo /D (subsubsection.4.5.1.1) >>
->> endobj
-732 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 161.051 539.579 170.0571]
-/Subtype /Link
-/A << /S /GoTo /D (subsubsection.4.5.1.2) >>
->> endobj
-733 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 148.9527 539.579 157.9588]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.4.5.2) >>
->> endobj
-734 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 136.8545 539.579 145.8606]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.4.5.3) >>
->> endobj
-735 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 124.7562 539.579 133.7623]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.4.5.4) >>
->> endobj
-736 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 112.658 539.579 121.6641]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.4.5.5) >>
->> endobj
-737 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 100.4601 539.579 109.4163]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.4.5.6) >>
->> endobj
-738 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 88.3618 539.579 97.3181]
-/Subtype /Link
-/A << /S /GoTo /D (section.4.6) >>
->> endobj
-739 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 76.2636 539.579 85.2199]
-/Subtype /Link
-/A << /S /GoTo /D (section.4.7) >>
->> endobj
-740 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 64.1653 539.579 73.1216]
-/Subtype /Link
-/A << /S /GoTo /D (section.4.8) >>
->> endobj
-689 0 obj <<
-/D [687 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-690 0 obj <<
-/D [687 0 R /XYZ 85.0394 711.9273 null]
->> endobj
-686 0 obj <<
-/Font << /F21 658 0 R /F23 682 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-743 0 obj <<
-/Length 3152      
-/Filter /FlateDecode
->>
-stream
-xÚí�[wÛÆÇßõ)ø(=p»÷Ë£¯9I[Û±Õ—¦y€)Xæ	I¨$×ýô]ØÝ�¸jÛȵD&'‘la0£ùÿ¸³³X
-
÷ÕÚ?«×{qõsq`¬ Þ+ÒM©Ž¬ðž•óëUeû¹î¾ù{³òߪOÄ Ä„¬1b j1™80bPï�¡ˆÒÖEbDOÌ‹fõJùõí:ró¡^ÿ^¯Û1†‰cEe”‘�ÇbF€!ÆÔ‰›qF2q`Œ Þ
óCŽöå‘ûª&ï!qêyøñÝïº'ãöæ¦Yo»?ÌWÝ×ç?¾yÙ}ç
g�w�ù&
-&ŒŸ{L¡¸ŒrrYÌ	0Ä8�ZaœdâÀ8A½NŒl7`GLÔALæ«ÙâöªÎQ¢‰qìÐdÇ2~Tóä�ábx’ÆÐOŒïˆÍ�‘ƒ¹àh_“´NsýPä_¾õõü?x³FLe1"ÀcJ…A’‰£õ0Q”
:)s“ß꯹©¯/AΊƒ‹ö´ês^Ì0Äx‚šb<eâÀxB½ž„%‚¦QÇ>N‡GEŸ^'R[LM²Ã 
ÂaÌì�!ƒ¹Äpωa	w™Es}Ýî$Ë*ã‡<§­ç(yT»
cŠ‹Ñ
†;PB1~OG.ŒÔ{À‡I¸Ói)�>?÷˜èüvYýa
wÈe1'Àãj…q’‰ãõ¯2IÊ	§Æ
RÚ둶߶¼�¦¾«–aÖ;û\­VunÕÏrR)Ý÷îóºÚx´àÇ5«	é-†bð@ùÄøÍ
¹80xPïá<,´Sí	
-àñÉu³ÎÍt$%Úš;ðHj�ªBÅô–Â
xòI:
-O.Ü{_¡„±„I	*Ôá«U‹/ë:·ÐÇ}}Š°ŒMo¸ÒG|Ý3¦»%`ˆ¡å”ãÛzsq`(¡ÞJZ{z8(aüAP:<Ó‘Ì=¡Ñ'¤µ`ˆ!eÃ�ÉÄ�!ƒzÈ(I¨e<!søJÕ²ÚlÛûãóócéôÁþJWõ
-9.æbü@
åøŽÏ\?¨÷À�ä„J§?ò¡ø¹OåssYÌ	0Ä8�ZaœdâÀ8A½ND;á…ÝÕáKUÍM+õ&ÁÁú³¼TÅŽkjr\Ì0Äø�büdâÀøA½~˜!ÎjP§ôCñsŸVòQ×£�ËbN€!Æ	ÔJŽoýËÅ�q‚zO­8UÄ)	*’ë8Ï›fQW½¨o{:¦J¸#¾ÚÓU0Ä`€rÈñ+¹80Pïîqœ[C¿.óºY©º'¬ìn;—”Ÿn+²³WÊ4Dب£Æ—]rq làÞÖW[Ý>¬eãåmµ˜n¶Õì·;Oßß-Kßb�ˆ©*
b @)Ôxœ‹
õž@ÐŽXåCv <›Íâ­Ð/Ú
víxÑ,Ú¢qºï9%®`ˆa
…Á°ÈÄ�a�zOX(C,7ƒÚ¡:,~\ùöSåÙ¸˜jÊN·/æñ	,Æbx@�Ôx?’‹Ãõžð�Š§ÄCwxü|[·/Ú=Ð
>PAs¢"æ­˜
-`ˆQ
uQã÷©åâÀ¨@½'*„ F»ÓQÑ=…¶…âòÂÑóuµÚ|ÚM*”a',b⊱
-‹/ßuß¼‹�í¹b¹:.B¶ŠY
-‡ëXx{3xÒù‡¯›m½L�B»Ý•’Y|†Þr¾£CªÇµNP,/0Ää…	VãK¹80yQïQ^æÑÚÉÁúõÅ?ö‘‡5L?ñÆ!樔
-endobj
-742 0 obj <<
-/Type /Page
-/Contents 743 0 R
-/Resources 741 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 659 0 R
-/Annots [ 748 0 R 749 0 R 750 0 R 751 0 R 752 0 R 753 0 R 754 0 R 755 0 R 756 0 R 757 0 R 758 0 R 759 0 R 760 0 R 761 0 R 762 0 R 763 0 R 764 0 R 765 0 R 766 0 R 767 0 R 768 0 R 769 0 R 770 0 R 771 0 R 772 0 R 773 0 R 774 0 R 775 0 R 776 0 R 777 0 R 778 0 R 779 0 R 780 0 R 781 0 R 782 0 R 783 0 R 784 0 R 785 0 R 786 0 R 787 0 R 788 0 R 789 0 R 790 0 R 791 0 R 792 0 R 793 0 R 794 0 R 795 0 R 796 0 R 797 0 R 798 0 R 799 0 R 800 0 R 801 0 R 802 0 R 803 0 R 804 0 R ]
->> endobj
-748 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 758.4766 511.2325 767.4329]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.4.8.1) >>
->> endobj
-749 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 746.445 511.2325 755.4012]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.4.8.2) >>
->> endobj
-750 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 734.5129 511.2325 743.3696]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.4.8.3) >>
->> endobj
-751 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 722.3816 511.2325 731.3379]
-/Subtype /Link
-/A << /S /GoTo /D (section.4.9) >>
->> endobj
-752 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 710.3499 511.2325 719.3062]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.4.9.1) >>
->> endobj
-753 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 698.3182 511.2325 707.2745]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.4.9.2) >>
->> endobj
-754 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 675.998 511.2325 684.7301]
-/Subtype /Link
-/A << /S /GoTo /D (chapter.5) >>
->> endobj
-755 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 663.9862 511.2325 672.9425]
-/Subtype /Link
-/A << /S /GoTo /D (section.5.1) >>
->> endobj
-756 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 651.9545 511.2325 660.9108]
-/Subtype /Link
-/A << /S /GoTo /D (section.5.2) >>
->> endobj
-757 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 629.6343 511.2325 638.4909]
-/Subtype /Link
-/A << /S /GoTo /D (chapter.6) >>
->> endobj
-758 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 617.6225 511.2325 626.7282]
-/Subtype /Link
-/A << /S /GoTo /D (section.6.1) >>
->> endobj
-759 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 605.5908 511.2325 614.5471]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.6.1.1) >>
->> endobj
-760 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 593.5591 511.2325 602.5154]
-/Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.1.1.1) >>
->> endobj
-761 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 581.5275 511.2325 590.4837]
-/Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.1.1.2) >>
->> endobj
-762 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 569.4958 511.2325 578.4521]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.6.1.2) >>
->> endobj
-763 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 557.4641 511.2325 566.4204]
-/Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.1.2.1) >>
->> endobj
-764 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 545.4324 511.2325 554.3887]
-/Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.1.2.2) >>
->> endobj
-765 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 533.4007 511.2325 542.5065]
-/Subtype /Link
-/A << /S /GoTo /D (section.6.2) >>
->> endobj
-766 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 521.3691 511.2325 530.3254]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.6.2.1) >>
->> endobj
-767 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 509.3374 511.2325 518.2937]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.6.2.2) >>
->> endobj
-768 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 497.3057 511.2325 506.262]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.6.2.3) >>
->> endobj
-769 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 485.274 511.2325 494.2303]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.6.2.4) >>
->> endobj
-770 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 473.2424 511.2325 482.1986]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.6.2.5) >>
->> endobj
-771 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 461.2107 511.2325 470.167]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.6.2.6) >>
->> endobj
-772 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 449.179 511.2325 458.1353]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.6.2.7) >>
->> endobj
-773 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 437.1473 511.2325 446.1036]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.6.2.8) >>
->> endobj
-774 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 425.1157 511.2325 434.0719]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.6.2.9) >>
->> endobj
-775 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 413.084 511.2325 422.0403]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.6.2.10) >>
->> endobj
-776 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 401.0523 511.2325 410.0086]
-/Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.2.10.1) >>
->> endobj
-777 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 389.0206 511.2325 398.1264]
-/Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.2.10.2) >>
->> endobj
-778 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 377.0886 511.2325 386.0947]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.6.2.11) >>
->> endobj
-779 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 365.0569 511.2325 374.063]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.6.2.12) >>
->> endobj
-780 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 353.0252 511.2325 362.0313]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.6.2.13) >>
->> endobj
-781 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 340.9936 511.2325 349.9997]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.6.2.14) >>
->> endobj
-782 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 328.9619 511.2325 337.968]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.6.2.15) >>
->> endobj
-783 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 316.9302 511.2325 325.9363]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.6.2.16) >>
->> endobj
-784 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 304.7989 511.2325 313.9046]
-/Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.2.16.1) >>
->> endobj
-785 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 292.7672 511.2325 301.7235]
-/Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.2.16.2) >>
->> endobj
-786 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 280.7355 511.2325 289.8413]
-/Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.2.16.3) >>
->> endobj
-787 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 268.7038 511.2325 277.8096]
-/Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.2.16.4) >>
->> endobj
-788 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 256.6722 511.2325 265.6285]
-/Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.2.16.5) >>
->> endobj
-789 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 244.6405 511.2325 253.5968]
-/Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.2.16.6) >>
->> endobj
-790 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 232.6088 511.2325 241.5651]
-/Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.2.16.7) >>
->> endobj
-791 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 220.5771 511.2325 229.5334]
-/Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.2.16.8) >>
->> endobj
-792 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 208.5455 511.2325 217.5017]
-/Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.2.16.9) >>
->> endobj
-793 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 196.5138 511.2325 205.4701]
-/Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.2.16.10) >>
->> endobj
-794 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 184.4821 511.2325 193.4384]
-/Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.2.16.11) >>
->> endobj
-795 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 172.4504 511.2325 181.4067]
-/Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.2.16.12) >>
->> endobj
-796 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 160.4187 511.2325 169.375]
-/Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.2.16.13) >>
->> endobj
-797 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 148.3871 511.2325 157.3433]
-/Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.2.16.14) >>
->> endobj
-798 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 136.3554 511.2325 145.3117]
-/Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.2.16.15) >>
->> endobj
-799 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 124.3237 511.2325 133.4295]
-/Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.2.16.16) >>
->> endobj
-800 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 112.292 511.2325 121.3978]
-/Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.2.16.17) >>
->> endobj
-801 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 100.2604 511.2325 109.2166]
-/Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.2.16.18) >>
->> endobj
-802 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 88.2287 511.2325 97.3344]
-/Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.2.16.19) >>
->> endobj
-803 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 76.197 511.2325 85.3027]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.6.2.17) >>
->> endobj
-804 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 64.1653 511.2325 73.1216]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.6.2.18) >>
->> endobj
-744 0 obj <<
-/D [742 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-741 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-807 0 obj <<
-/Length 3353      
-/Filter /FlateDecode
->>
-stream
-xÚí�Ks7€ïú<¤j¥ƒ°x€ÝÖ^v”rd¯$W¶6É�&ÇËâPáÃŽ÷×/†`š"¦%8~È�J‘’¦§›Ýß4º
Ì�õ¨û�õŒ"TXÙÓVE™ê
&;´7r{¾Ãü1ûá }xÔáåÎߟ	ݳļè]¾ç2„Ãz—Ã_w�^ž]žœ]^ìý~ùÓÎÉe<)T̨¨ÏøÇί¿ÓÞÐéÿi‡a�ê}p?P¬å½ÉŽT‚()DøÍõÎÅοã	Á_W¢©¢„!Êp�ø$\€OÂ8'Æjg�²¤îoõG)wŠëâgàpÁˆ1T:õa‹Ùr¾(‡ûïÊ�s0<·2ÄrSøƒ/ýE9)«ÅÞ>Wt÷ù¬?™ôg{ûFÒ]²·¯èx‘Ö~ŠÜ­€+nHÁ)k}º¡Ù¨×¼9‡1rûPp3f›ç_Ŭذ#0�²#ÕÞ#5)´f‘N¿(1Çåo”òj¼O«æ7ýjؼy=ï�Êú­x˜œt\˜
Ä
-[|ìtBÜš

Ä Y›î†&a
ª½…†9+ZhÄ�ÐüoZ•ih¨¶ú®dÌcN=wÁÜ�
Ä`Z§é†)aª=ÂTXKŒ*d“ü"0Ý��´b�gØŠnÍ…
-"Ь…MÓNhRv ÐàÚ™’Dkm{…ÑÄR&
-PíqPÖ•”ÊÚH
÷ƒÀñx>X&Âýó	B~Óðë¹öèÃ\B  BÈZŒt÷ôhÊ„\{Kˆ¡DPi"!ÂrQ.ãjäGõË+䶾Ìç'x8› ˆñ#¨m7?	;0~Pí-?…!BÚØËÔí늟Óê}9UáÏý››ÓØçœÓWïÝÁ܈m+½˜ÍÄ�QÂIØ�1‚joQ+ÛVDyF^.®ÊYÃíæwµ¤2nÊ’Ábü¾nW„dOy
-^ÌfbŒÀ(aŒ$ìÀAµÇzUII¤°¼e$¶/®¥L¬Ø®f2,ÆýðòüôùéYbÑNj"‰þ¸5¤öö­b�u[th6.@ÃÌt¯¿¤ìÀpAµ·¸N¤‘àÂsp9=;zñúø$µ™MZˆ.^¸x|y%¸2 ˆ�C…�’°ÕÞ‚Â)q¦X
-"x¬Èt/ñ§ì@ðØÔÎ÷”HíJ}^¯è­¥Û¼\”ƒål¼øØüt4uùaXÎúͺ§ß©�
÷óØ´xó¼+‰n�Óa~ÚКZû”'Z*߉®jüzíó`0(çóè–Å*¯Mýõb<_¬þ&·kžùW]pxöU±«£(aFª=Ò¤(Ñ–úž•¤ö–»ôm™d~Ä<ºšM§‹ÄÀ*$¡’‡Ãê•ÎÄXm‰pEØÿY.–ãaêT†8T�?쉯à
-±!¨ÙÄAŒX�éÞû‘²#ÕÞ–NÀ%²íº|²>TÌqisƒN|ᚇºð¤zßT†ÓªÙ ,
-ñtb'WÁóÙ\
AŒ+YŒ«„W¨ö–«º'5”E®ÂRßëyœyO· ®1–…Ô7ïLkoãgËjÐlu—ú)¶�P·gC1¨`X1¨v`P¡ÚãðÊ$±\ú¥É¸Q­skb[ÞjU<ñÅÁN`‚O³�
‚00f0	;0`6´§º aëù	çªñ]Ðåclw6]¾¹.çWnüªóQ—{âîÛì@
¤ÙY·¬{<âŽM­©ëG7z+?E{�£édö]¼j†iç™I=M 嶵ɾ¢‚—s/( ‡\Ok1D¸Ù4ÃS‡tQXB­¿Óø
}«µõÅß|¯\Mýíg¦³wîºúgóÓÕôCófЋíÍK}�Ú¨ÙèsötÎpÕ�§ýà«ÇÑ¿\*gæ
�·Ñ'ÙÑ‚X¸×|ŽÄ;apT{ÌJ׫ú^zUÁÕ	ã´4«‹ùXÌÅݸGWýj´VãùÁx6S’gËÉ›z†Ú™ñ
-ùè¦l€ ÆÀZv` Ú#Rfü��&Ö\¿Ô;%Ú«öèÖuý¼ôWñ�åõ�»h¥ÜŽ÷B)x;% ˆ¡´M¥„JÚ“Õ„~BüÀerÎwnnÊj8”ÝóÍQìÞ%ÀJ0hŽéÞ`O‡ù`CkòrbŒ&TãƒzÕÚyað®š~¸.‡£:¥Ö{à¹ÝV^ùWOpnöÕ±«#&aFª=–_ÜÖó½Ftjxl}	5™öp6.ý®éÇóÅtöq}+uˆ�Ï.n�ØͺPAÙãA!:+(ˆ °…”
-¸ö�D¸ÑDRÁ<	¼I"Ï˪œ…
-+ù¼|ëGê*ÜmsZ½]-¯¦Ë
-û´ÖŸ¢ï²Á
- Ó=kVÙîûßáé0WlhM\Ì
-¢•lâp¸V…ÝŽG�*i~?7¿Æxä^wP¹îÖâ�@–²�
×a3Œhk™‡�7°]MëNé-m_�6A
-at�ûÒæåö¡`Š¶Ûç¯Îhw‘˜2Ã
Uq+,1þþÌÃÕ`_§¶j>/õ“ÙGõ3y¤T[¦>LÞÝÙ,µrJ ˜Œv?w.a¦;r¤41îŸI®�4�ªÕãoJbËÐ_e(¸:" ˆQCÉhwÝ™2ãUA’ŠX!
-’j@ªú“r¸?¸*ïÓêí^ýP¼-AŸLPðq6A@#Æ�Ñîê”!A¨úH�Äjã;—úÖÊ[ùT¤¶9èÓ	
->Î&bÁ2Úý
-endobj
-806 0 obj <<
-/Type /Page
-/Contents 807 0 R
-/Resources 805 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 659 0 R
-/Annots [ 809 0 R 810 0 R 811 0 R 812 0 R 813 0 R 814 0 R 815 0 R 816 0 R 817 0 R 818 0 R 819 0 R 820 0 R 821 0 R 822 0 R 823 0 R 824 0 R 825 0 R 826 0 R 827 0 R 828 0 R 829 0 R 830 0 R 831 0 R 832 0 R 833 0 R 834 0 R 835 0 R 836 0 R 837 0 R 838 0 R 839 0 R 840 0 R 841 0 R 842 0 R 843 0 R 844 0 R 845 0 R 846 0 R 847 0 R 848 0 R 849 0 R 850 0 R 851 0 R 852 0 R 853 0 R 854 0 R 855 0 R 856 0 R 857 0 R 858 0 R 859 0 R 860 0 R 864 0 R 865 0 R ]
->> endobj
-809 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 758.4766 539.579 767.4329]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.6.2.19) >>
->> endobj
-810 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 746.5215 539.579 755.4777]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.6.2.20) >>
->> endobj
-811 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 734.5663 539.579 743.5226]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.6.2.21) >>
->> endobj
-812 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 722.6111 539.579 731.5674]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.6.2.22) >>
->> endobj
-813 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 710.656 539.579 719.6122]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.6.2.23) >>
->> endobj
-814 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 698.7008 539.579 707.6571]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.6.2.24) >>
->> endobj
-815 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 686.7456 539.579 695.7019]
-/Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.2.24.1) >>
->> endobj
-816 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 674.8901 539.579 683.8962]
-/Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.2.24.2) >>
->> endobj
-817 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 662.935 539.579 671.7916]
-/Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.2.24.3) >>
->> endobj
-818 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 650.9798 539.579 659.9859]
-/Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.2.24.4) >>
->> endobj
-819 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 638.925 539.579 647.8812]
-/Subtype /Link
-/A << /S /GoTo /D (section.6.3) >>
->> endobj
-820 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 626.9698 539.579 635.9261]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.6.3.1) >>
->> endobj
-821 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 615.0146 539.579 623.9709]
-/Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.3.1.1) >>
->> endobj
-822 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 603.1591 539.579 612.0157]
-/Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.3.1.2) >>
->> endobj
-823 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 591.1043 539.579 600.0606]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.6.3.2) >>
->> endobj
-824 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 579.1491 539.579 588.1054]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.6.3.3) >>
->> endobj
-825 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 567.1939 539.579 576.1502]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.6.3.4) >>
->> endobj
-826 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 555.2388 539.579 564.1951]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.6.3.5) >>
->> endobj
-827 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 543.2836 539.579 552.2399]
-/Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.3.5.1) >>
->> endobj
-828 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 531.3284 539.579 540.2847]
-/Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.3.5.2) >>
->> endobj
-829 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 519.3733 539.579 528.3296]
-/Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.3.5.3) >>
->> endobj
-830 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 507.4181 539.579 516.3744]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.6.3.6) >>
->> endobj
-831 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 495.4629 539.579 504.5687]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.6.3.7) >>
->> endobj
-832 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 473.5253 539.579 482.2574]
-/Subtype /Link
-/A << /S /GoTo /D (chapter.7) >>
->> endobj
-833 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 461.59 539.579 470.5462]
-/Subtype /Link
-/A << /S /GoTo /D (section.7.1) >>
->> endobj
-834 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 449.6348 539.579 458.7405]
-/Subtype /Link
-/A << /S /GoTo /D (section.7.2) >>
->> endobj
-835 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 437.6796 539.579 446.7854]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.7.2.1) >>
->> endobj
-836 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 425.7245 539.579 434.8302]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.7.2.2) >>
->> endobj
-837 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 413.7693 539.579 422.875]
-/Subtype /Link
-/A << /S /GoTo /D (section.7.3) >>
->> endobj
-838 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 391.8316 539.579 400.5637]
-/Subtype /Link
-/A << /S /GoTo /D (chapter.8) >>
->> endobj
-839 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 379.8963 539.579 388.8526]
-/Subtype /Link
-/A << /S /GoTo /D (section.8.1) >>
->> endobj
-840 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 367.9411 539.579 376.8974]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.8.1.1) >>
->> endobj
-841 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 355.986 539.579 364.9423]
-/Subtype /Link
-/A << /S /GoTo /D (section.8.2) >>
->> endobj
-842 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 344.0308 539.579 352.9871]
-/Subtype /Link
-/A << /S /GoTo /D (section.8.3) >>
->> endobj
-843 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 322.0931 539.579 330.8253]
-/Subtype /Link
-/A << /S /GoTo /D (appendix.A) >>
->> endobj
-844 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 310.1578 539.579 319.1141]
-/Subtype /Link
-/A << /S /GoTo /D (section.A.1) >>
->> endobj
-845 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 298.2027 539.579 307.1589]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.A.1.1) >>
->> endobj
-846 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 286.2475 539.579 295.2038]
-/Subtype /Link
-/A << /S /GoTo /D (section.A.2) >>
->> endobj
-847 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 274.2923 539.579 283.2486]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.A.2.1) >>
->> endobj
-848 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 262.3372 539.579 271.2934]
-/Subtype /Link
-/A << /S /GoTo /D (section.A.3) >>
->> endobj
-849 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 250.382 539.579 259.3383]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.A.3.1) >>
->> endobj
-850 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 238.4268 539.579 247.5326]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.A.3.2) >>
->> endobj
-851 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 226.4717 539.579 235.5774]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.A.3.3) >>
->> endobj
-852 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 204.534 539.579 213.2661]
-/Subtype /Link
-/A << /S /GoTo /D (appendix.B) >>
->> endobj
-853 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 192.5987 539.579 201.555]
-/Subtype /Link
-/A << /S /GoTo /D (section.B.1) >>
->> endobj
-854 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [522.6425 180.6435 539.579 189.7493]
-/Subtype /Link
-/A << /S /GoTo /D (section.B.2) >>
->> endobj
-855 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [522.6425 168.6883 539.579 177.7941]
-/Subtype /Link
-/A << /S /GoTo /D (section.B.3) >>
->> endobj
-856 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [522.6425 156.7332 539.579 165.8389]
-/Subtype /Link
-/A << /S /GoTo /D (section.B.4) >>
->> endobj
-857 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [522.6425 144.778 539.579 153.8838]
-/Subtype /Link
-/A << /S /GoTo /D (section.B.5) >>
->> endobj
-858 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [522.6425 132.8228 539.579 141.9286]
-/Subtype /Link
-/A << /S /GoTo /D (section.B.6) >>
->> endobj
-859 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [522.6425 120.8677 539.579 129.9734]
-/Subtype /Link
-/A << /S /GoTo /D (section.B.7) >>
->> endobj
-860 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [522.6425 108.9125 539.579 118.0182]
-/Subtype /Link
-/A << /S /GoTo /D (section.B.8) >>
->> endobj
-864 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [522.6425 97.057 539.579 106.0631]
-/Subtype /Link
-/A << /S /GoTo /D (section.B.9) >>
->> endobj
-865 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [522.6425 85.0022 539.579 94.1079]
-/Subtype /Link
-/A << /S /GoTo /D (section.B.10) >>
->> endobj
-808 0 obj <<
-/D [806 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-805 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F39 863 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-868 0 obj <<
-/Length 69        
-/Filter /FlateDecode
->>
-stream
-xÚ3T0
-endobj
-867 0 obj <<
-/Type /Page
-/Contents 868 0 R
-/Resources 866 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 659 0 R
->> endobj
-869 0 obj <<
-/D [867 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-866 0 obj <<
-/ProcSet [ /PDF ]
->> endobj
-872 0 obj <<
-/Length 2197      
-/Filter /FlateDecode
->>
-stream
-xÚÝYÝ�ã¶÷_áG-pfù)‘y¼»¦¸ ¸¢Ý
ò�æA+qmádÉÑÇnœ¿¾C)˶|wé-РX`M�†äpæ7¿ÚlMá�­µ"T¹ÎŒ$Š2µ.ö+ºÞ»¿­XБJ%…€‡…·%4QšgëÍ|‘·«¿|ÏÙšS’¦\­ž¦½ÒL#¤Y?”?'ïvùa°Ý݆+š°»_~Ài’d:cn…-ÉÕ~‡fèÚr,†ªm‚ºXbRžFí悹Nûagai�ºi¶kì€OïÛ}^58þ˜ïƒÎý±ìÇÿ¦Š¾ÿxÌ	²¤h›¾ê‡_·Oø9Äõûc3ä¿ad[TOÇÍö»XÅ6C5T(Í’êŽ%
Ý$8£;cÄ(Å£Âa§‰;ˆà,ÉñqWÙ.ïî˜NŠ]Uä5J÷yÓ€›3™¼
�Ðh�{ÓÝéd¬Ýæn‘±·%ÊŸÚ¥­í6ªfö‡]ÛU˜yDIûlƒ®?\Ø!oÂJa+Nò>;ó'ªö‡ÚîÁ¹�놃¡Ã.wáÊT’Ø×õåûüÐã(ºT¼ÏA4‹³›X–Þ¶ïmOÀ-ˆ*ª–ù�£ZÕÇ•+° jœܳ‡ˆ[·~­v< ¢·›@ÒU�ãàQKñpR·ùcî­Š˜g’™ò€bI	Obž
-ôœA)*ìaˆÔqf§†d
-DÖñ›Öñ 	R
-}å7A,û�+£c”ú…%%”Æ8yÿiU¢¿^OI¢�0SÔƒ©C�>”‚e”<÷á!8|V5T•Ëã­Wóø·áÕÓØøú*ÉsUž›�vð>¯Jœ‹–D‚A G
-OyùœCÖ•“¦Ï@´64* >2óNgÃŒ&ÌõÀçUlN¾.ÝR Ñ#ë›0Hõ§øn*·Ø†�¤°ÝàK­{hîôËŒ�B/-RvÍi¢n0‚b‰ÒHUéŒ�
-êj»^¬ûh‚*"¸‘K4Ñ·õ3v£®tgihM2îc`ˆŠw.°Ëº>,)…¼â`7!]
->YÉàT&³ëdQ¶®ÂŠ¾QaÁô'ìL,
-¸×S^ÛIÀ“ÿõ÷7¨¹kûa¦	¼VÇêvñÍA
DŠÑ
úþ®ø�}	°ÝþüUè[o#zvÊosÜÑ—žƒ[Ñ¢gžû¾úÍql
-ôûR•Ãî6x_ÍÞ?xc _‘©!RªôKàe‚PÁ#ĆSY
VébÍ;ŒŸÁÏl£WcÄK㡪/ágnü@?y
-š[}¡[Ày5sÿ,¸áî‹®Œ¥î
-ADÆåüg¿«Ÿÿ¸§` Ô
˜¯µ^ü�0þô·Š¸_Ñ# §r”\²+·Ç_O+ÅÝþ-Õ«endstream
-endobj
-871 0 obj <<
-/Type /Page
-/Contents 872 0 R
-/Resources 870 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 886 0 R
->> endobj
-873 0 obj <<
-/D [871 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-6 0 obj <<
-/D [871 0 R /XYZ 85.0394 769.5949 null]
->> endobj
-874 0 obj <<
-/D [871 0 R /XYZ 85.0394 582.8476 null]
->> endobj
-10 0 obj <<
-/D [871 0 R /XYZ 85.0394 512.9824 null]
->> endobj
-875 0 obj <<
-/D [871 0 R /XYZ 85.0394 474.7837 null]
->> endobj
-14 0 obj <<
-/D [871 0 R /XYZ 85.0394 399.5462 null]
->> endobj
-876 0 obj <<
-/D [871 0 R /XYZ 85.0394 363.8828 null]
->> endobj
-18 0 obj <<
-/D [871 0 R /XYZ 85.0394 223.0066 null]
->> endobj
-880 0 obj <<
-/D [871 0 R /XYZ 85.0394 190.9009 null]
->> endobj
-881 0 obj <<
-/D [871 0 R /XYZ 85.0394 170.4169 null]
->> endobj
-882 0 obj <<
-/D [871 0 R /XYZ 85.0394 158.4617 null]
->> endobj
-870 0 obj <<
-/Font << /F21 658 0 R /F23 682 0 R /F47 879 0 R /F39 863 0 R /F48 885 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-889 0 obj <<
-/Length 3125      
-/Filter /FlateDecode
->>
-stream
-xÚÍ]“Û¶ñý~…u3‹~öíÛ�3“sb«“i�<P"¤ã˜"’:ùò뻋]P¤„³Ý6�fî�+`
ìö'þä"Šƒ8SÙ"É 2Zl7b±‡¹¿ÝHÆY9¤Õë›õÍ_^ëd‘Y¬âÅz7Ù+
DšÊźø°”AÜÂb¹þîÕíJEbùòíwoî	¾¿û�GßÿãýúÕÿ""ñòþ=|äíJÊ8Ëo¿»ûqýêÍKÞòÍýúÝÛ—ÿvýæíýí¯ëïo^­Gª§œI¡‘äßn>ü*0øý�t–F‹ü�Ì2µ8Ü„‘¢Pk7Rݼ¿ùiÜp2k—z%%E t¬<¢RÚ'ª(b
S(ªõƒ!övMU5§²ÞÓÏmS?šz(›º§�¼»•é’‘�½)*kú¦ßve;YÐìè;¸¾ysÿrÜü!ÔþØå¸ÀÉ_¨ÊüõR¤qÄR
-h�€½t+æ[­O«D« ’ᨯpjÚIdi²Ht¶$bR×­”rÙLe¾
™­dª´^þ|«ÄDEòï‡'�|Ã,	2™á9#-ÿw(G
wñ"0%‚(‚½½î$¦àö…Qh%öÑ<�k»E�¼ƒÿÈ&K”JèDa±_—ŸÐ²c!–?—Åðð¼´ˆ�ìO..
�
-3o­»Ë+ç	Ûã
-Ë~€Ìá8XWèE>䛼7�ãêìa á~ ÐizÚ®¬wMwp¦ð“fy»ò	¿%µbÞìl~ÉåCÓ4^c=�VÔˆú#!åEÁÇ÷…l
-€ÇrkëÑt}nS@FYѨ]؇ñü	íYŸ÷j@û�(ÚÀæ¸3ŽÈ{lØN&ü µm¶ùo0.ƒØŠÔ.û¶*AÿÖÚ¢eÕ4	:¶ô�KÖЗӷÈ\�[¹|"4ZqÊ�Ê­eÍrH…î=�CÙ,ͦ™yìPk/Z2rUB êžlÆù‚Î;�=Ði½©ææ·£éJ« @¡ëWµfº­…À÷À¦ä¡µ¨,‹æ¶S[“×ö°µì!|
-
‘(¶
-ÕVx ›–ÎC™k'HX-hÊ€®V±ŠèÊá$yI„2>zæäpd¼<VW8õÌ
-|	„S»P
-B
×ó9õÅ|›4´£xx qFPB¬ßæ©kɆO’ÉiišÁ#[	%J;…ûS8„J#E9%óhº¦\8ä̾¤rvÞe(GA„š¾§®Ã?0j”óúœ>è£mdØ
-¾•“Â` nç‰p�€rÿ0h…‚ÈfÇ#äbpÓæ`àn›À·h´p(©–w¾|È’@Ž©6®lꊓŠ�ëÞÔ%DU‚O%ìÌÊ�]]Ë7¿æüƒÏ›y¼¶÷2ŸòC[ÙËD.
G‹˜-R÷�[ÃXœ®áÀ@dB0°mm^ûÜœ‚h¡uì®ã«Ùñoêmà‹çI�ÆÚ¹Æms¬
-:fc<	
µ".ÆnŽÒ0Ÿ
Pæ3P©ƒ(	åxûÉ:#ˆ0fÚ:a^xNZæÝ̬T2Rê=@‘:Gƒ.³”D50˜WK#•yD«@ÐéÃ"6„Gi×5	Ò
-Xÿ»üGAfn˜cSï]Z0—.zSá8ä]}I�R™f\æD{Üœý0¸Í4	’0Œæ^
-b5:”ÀyÈ,º¸+¤€$u9@yß7Û’C.üƸH«#™D³dŒf
-Î
-J�}¹¯¹šÛù«Í˜Û2ñLM/ :i
5
-÷&M¾d)#þjºàZK×û^ÙÊ�ÏVøË8–rFÏõÛ‚Ãú×»=ßÆ@Š³8UWmÍmŒ>v/›øª„JÓ£¯mM‡ÅŽ lÛÖZe¶â×cú Å¬Õ+Ö4a“	XQБä5|ÔíC2:Íñ�¢Ü!;­õ–OÞ˜ád°>C$_œEI¾Ò“”×qHHS9kí=³¡­-¡:½Åø—êw½ypv»ï¸)
-S™ýä-ç깇bë¤Â�ˆ;=Ÿµmê®c?Ý*؇ñù	»”åþèmÓ+ô‚¥ÿ±%:W€Ï�$üE‰
-endobj
-888 0 obj <<
-/Type /Page
-/Contents 889 0 R
-/Resources 887 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 886 0 R
-/Annots [ 896 0 R 897 0 R ]
->> endobj
-896 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [272.8897 210.0781 329.1084 222.1378]
-/Subtype /Link
-/A << /S /GoTo /D (types_of_resource_records_and_when_to_use_them) >>
->> endobj
-897 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [190.6691 182.1322 249.6573 191.5418]
-/Subtype /Link
-/A << /S /GoTo /D (rfcs) >>
->> endobj
-890 0 obj <<
-/D [888 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-891 0 obj <<
-/D [888 0 R /XYZ 56.6929 756.8229 null]
->> endobj
-892 0 obj <<
-/D [888 0 R /XYZ 56.6929 744.8677 null]
->> endobj
-22 0 obj <<
-/D [888 0 R /XYZ 56.6929 649.0335 null]
->> endobj
-893 0 obj <<
-/D [888 0 R /XYZ 56.6929 609.5205 null]
->> endobj
-26 0 obj <<
-/D [888 0 R /XYZ 56.6929 551.1302 null]
->> endobj
-894 0 obj <<
-/D [888 0 R /XYZ 56.6929 525.7505 null]
->> endobj
-30 0 obj <<
-/D [888 0 R /XYZ 56.6929 422.4834 null]
->> endobj
-895 0 obj <<
-/D [888 0 R /XYZ 56.6929 395.8284 null]
->> endobj
-34 0 obj <<
-/D [888 0 R /XYZ 56.6929 166.2827 null]
->> endobj
-898 0 obj <<
-/D [888 0 R /XYZ 56.6929 138.253 null]
->> endobj
-887 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F47 879 0 R /F39 863 0 R /F21 658 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-903 0 obj <<
-/Length 3414      
-/Filter /FlateDecode
->>
-stream
-xÚ¥ZKsã6¾ûWè¹jÍàA
-a²¢´á¦�f²”™ËÕW„\€Ž™ ®¯Ë÷tÎ
-Bƒc34ÏõÈå‰â‘=½ r‚
öÇÇGÒ}0N:
-$¿vG"‘ÂUk"þð}O-ˆÂ´7¤›9½D¸×ð”Q½X4


-Ú½¢¤bü²êÿr…û€º–Èuüç˜â�ÙK
Šy{„°ëÐÆáäÍ0Å#÷—Ì‚² _Xy‡«4Øòǧ�Çšh>½�§Ç*x¶uÕs¿K�Á¶ÑOuÊ-~Çf->øDÄ)Ày•ZNŽ/£øLeð~È¿Qt
œOpÈëj¨¨EçÄ#é˜,¬`ÎÊ9ntáæ‹ëRÍÑO8Xð„òuÇ ‰¢¤tm}¨|Bd®@
*�4‚I îêá¥;<õ¡jÚ#GCè‰c?ÐH¯4nã5ϯôÒQ£ã‰c†é©,é›RM•…#$΃B2Ü?Ô§ù"³Ü'
ýsÝï
ï(áqór·[|+ÎðÊÔÏûRÁ]Cñüâ3ttý�=FÜÞúÊ…ï_úxÉÏÏ
JÓŠqf–³ç–ºöÕê))ªz@¸4ºW@áüù÷1�Ýá•iQ ùÜ
È@}!´úº^‚ã'T�¯:Ø
-n±=*‚«w
zŒÐx¢KìÏñ¸‹¨i{
-˜0¸†¥^!ž¥ð
-ÍÈ)´c‘Â|Fæ�æ¡f63
-O=°& wœWðdcZ*…—™¤µùiÙȸýd‰ƒ6™Ì]Ь.dJÐæ&õÅYs™©MÔ>²�W˜S·ùñMš fHÁWUOA
-fD
-_tÀ€ÌvØüM„ù¹…S &cÃQðføˆ‘€:úMÏ£Î
-4´â9§îåÌüváâ}Ï1[,ò\\ÔG	S=Ÿ^ÌÉ:ÐmZc´“1àp¨­/÷‚ã~¤Fñ_	[€ƒUÁÁÒß.¨rlõØpŸ…Ô8èm¨þ�°�·ì§_Såþpäœþå‘óß-¦ëE*ý�CŸ«g
¶ÌŒÖgeŽÑAè)�èpÅÔ%_*{ Ðå7‚¤§ºÞûÀ(Þb1AÓ!ñG¢·Âñ¦+ܪ³_Ç¥÷uÍ7kÇ=uU+
-¢ü
XÇÃÕXT
�p~ÅCê,x^®¤zç;š›ˆ|¦„§¹`õ\5mµ)"_œâ€´íÙ$X5ìÆ‹¬¦j¹Ž8Bé…D›^¿šr
-¡‚—†HÙ[�‚ÿï”(L‰Xãÿ¿ÿV5þ»,w™.
-•®piQâEpd
-�£¼(
-endobj
-902 0 obj <<
-/Type /Page
-/Contents 903 0 R
-/Resources 901 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 886 0 R
-/Annots [ 906 0 R 907 0 R ]
->> endobj
-906 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [519.8432 463.1122 539.579 475.1718]
-/Subtype /Link
-/A << /S /GoTo /D (diagnostic_tools) >>
->> endobj
-907 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [84.0431 451.8246 133.308 463.2167]
-/Subtype /Link
-/A << /S /GoTo /D (diagnostic_tools) >>
->> endobj
-904 0 obj <<
-/D [902 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-38 0 obj <<
-/D [902 0 R /XYZ 85.0394 570.5252 null]
->> endobj
-905 0 obj <<
-/D [902 0 R /XYZ 85.0394 541.3751 null]
->> endobj
-42 0 obj <<
-/D [902 0 R /XYZ 85.0394 434.1868 null]
->> endobj
-908 0 obj <<
-/D [902 0 R /XYZ 85.0394 406.5769 null]
->> endobj
-46 0 obj <<
-/D [902 0 R /XYZ 85.0394 301.1559 null]
->> endobj
-909 0 obj <<
-/D [902 0 R /XYZ 85.0394 276.6843 null]
->> endobj
-50 0 obj <<
-/D [902 0 R /XYZ 85.0394 200.1512 null]
->> endobj
-910 0 obj <<
-/D [902 0 R /XYZ 85.0394 175.6796 null]
->> endobj
-901 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F47 879 0 R /F39 863 0 R /F21 658 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-914 0 obj <<
-/Length 2458      
-/Filter /FlateDecode
->>
-stream
-xڥ˒ã¶ñ>_¡[4Uš
-Yþýî×ßÂU	üù.TžÅ«LÂ@ä¹\5wQ¬‚8RÊCê»ç»Œg«n뢤DH•ÈQIµ$ª8K(ªwp9®‹®ý†òe8j[u-
O{s¼ÙÚÐÔîyp8V�>žiÒèÞš÷æøêÇ•íM½ãqO_ÍhÖèÚîö0^·³†y væHƒ’Yé˜ Û <á¯RFûª,a3(¤zò8–îªÌ6"
z]_ô«âhý¹5´<ô<ØuÈ_ƒ‡·[	H‹1Ê�!$2
-ëÖòT„
-‚>a·£ßÑÉå£-}ùÞý©àÓA"U¾x¬Û\wÝ·á°dý)^Üï¤`êðIxåº2­í6ð0
-¢,‚Ì&Ò W2%ÿ¿Ïåô£’l]5ÞÇ
rϸn&
™òšAÜÕs¨q;
-G·{¦Â
-jÛÓ
-ú.X�êïè÷�/Ž�'·Ÿ+`cÚ¸˜‰F¿r¤rrÙ(œóíl–(ÊG¡ã™¼¡cp€IÕZÈ/–?r鼿3ÎA"Á6�wÕ«€½0UohN`K½UnP*yí"¯Æ“2çâoÒ-ÆAžÇÙ•ãÌó›¯0ÕõÞgúsÛµç¦z�†€â U07'*fÒumÚªERR�aò*Y+Nûª`,M%Ü’`�>…­™#Y]µ†Qª–¾Ö3À–ˆ»èüñ„IP0a×…ÑT1¥\1e¨pKFå‚Ç‚ÍmÏW)}sÇëªgä^8þeôi¬‰7›_¨&&@(Mí£SßwEfW^×
F<òAspƒÂÌ¡^vS)q‘ý!Ï	1«è¡°àZâ§îxÒÇeó?놯d"	ÅÜd&U˜ø€˜ÌBqº.;ç–¸ÞYôV¨2¨HJf9&,Ô««Cm,Ïn¢d„ÆT"c¦�ù”Ñt‡ñY)Ÿn—ªì|ÒhŠ¯(›¥T
-�i�â;.Pw…°s7¨ì@Va$ê÷´DF…Þ˜óY€GZF£éKõê‰÷•]ÌÝÎ\‰)ZˆÂÒì²ÖEC•(_=HyrZ~DŠ­áefkŠ(Å6Ýá’P£0-$æçÔ
—‰µWìDh¢‰‰vh¶d¹×"o�èB­#®bê<‰&dg°¬[Ìx†ÙeÇêÞKÔØá¹}¾#Elr|¨¶uÏ«]|3–ϲ{ŠÃËÞ¡ýQcLÖÇÂ�JÍý
’<_±Z0F~tmŒ0Öºå’ñ+‹áE%\�!¥yNb<[:·;_�6IÁÔ~�Lô¥ÊO½U>Nšš÷ÿþÂÁÌ· ®CO8«Þ6åÔp…õ	êâêàŸ¾tµùÓ]{®x|zO#ßzͺŸ4dq#°jà Ý*à MïD7ÃE­SzHJgoO0¦J
	tžþ ”b„[@X¬õ«¹ÚÀiçfG»XGM	ƒ»µÙ³–K9*œæ�ÞØ�] õõì·FW5ìÇîd¦ÌI蓹õȹäW9œ6´6¬=M�»Ã:·Þ¾ËÆ%ÒŽ�Ûªà	9=lá»~Ý[½µUÌŸR®åXw/c|ÏpÛA¡”Ä‹I¥EÆ©#Í}¥� ]¾êÖê4‚¸@’bÿ–A€aØÞ44êÚË×ëWw/ãbmž»X›…ÎÓ—bgëŸf�NÎF“k
Ï_’IJF³Y®ìB©ü»ÑÅwöB³i–§¾Ês—`3„£ØÍ’QVäº=MnºOX,«C6¦ˆU¤Ì.ãíÔ�SѦÈ/1•ÞVueÏ$SBCÅCL
ÚCaå.§DãZFÎàK)I]Ù/€œ_Ñ1|žóç«£Ig8ºÐÙ‚v¯Ë÷<šé-W”Iòé]	@ì®wz]ª+chft¶ýð[
-ä4	Õ’BánUàhjU
-
e*Ñ�²€Ç,EJ¡¼Mq	9jÕäå/œÆGi²5—Žøy©Ö…¯¿«vzOÖSo9¯ÞøoÒþ!²ðOH8&ºÿû—éï§(
T–Éå¿TðA8Ê€3åRjxùÿƒæ–õÿ÷Å:êendstream
-endobj
-913 0 obj <<
-/Type /Page
-/Contents 914 0 R
-/Resources 912 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 886 0 R
->> endobj
-915 0 obj <<
-/D [913 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-54 0 obj <<
-/D [913 0 R /XYZ 56.6929 717.7272 null]
->> endobj
-916 0 obj <<
-/D [913 0 R /XYZ 56.6929 690.4227 null]
->> endobj
-58 0 obj <<
-/D [913 0 R /XYZ 56.6929 550.0786 null]
->> endobj
-917 0 obj <<
-/D [913 0 R /XYZ 56.6929 525.2967 null]
->> endobj
-62 0 obj <<
-/D [913 0 R /XYZ 56.6929 393.0502 null]
->> endobj
-918 0 obj <<
-/D [913 0 R /XYZ 56.6929 363.1913 null]
->> endobj
-912 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F47 879 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-921 0 obj <<
-/Length 2095      
-/Filter /FlateDecode
->>
-stream
-xÚ•XÉ’Û6½û+täT�îË1Þ§*®T<9Å9`DHD
…
-wQàgY”îŽÓYYžûYš»‡êoïM-ÎFwû(
¼èßh[âçEâ¶
-JòÚC
2ã ÆÕŸÞ½!ú(…Éš8 ¬ýR¨ UÒ§7"Îtƒ‹3=}yÌFGòÍ¡:ƒ&q[êþ*AÏ»<ñÀÔq˜{š…ôVöItê+¹‚Ïø†ñ[ñd
•yµ—‘£f^¤¯©!r¤ã®¯Œ{3$®J×¼¥§ï
TP¥Xæ5¡'7Ö7mdk¥¤Þ±ÜqÓYâ|nÔ�n‚±S
-fhWü(½¾YhovçåvlŒ25©,*Yݳ÷›¦¿ªîÄqˆ�jØ|SüÍ‚Ø{©uÏ•cq�À]#Xg±¬,ÕI’Êøߨ	´8͸dD\2lL|£ælV‹„JnË`«.hš±š#A&Fªä=¢;I^4¥ŽTRdûC#4‹hÅ¡V�|.ÓÊhMË4`šÑ_ûiÓ\Õ�†+ït¿åab
\
rc8JK§	rgM¢ ÷Ô‘¸·~$Â&TE´´ð¬“a«ì¯n�hQYd�çJÉk„“âªÒZ�¨x
m¯v¿•|“UllÑY6HúQƒX½¾G9(©§²æ
-dXõcsý.Û~¸ý¿ Šç•‰×:%<ä7IE”èÚ–Ø’ª2yÑT
-hZvýxªY/ý‘áÝN6“dy 8xp]Óc~{î0¨”~‚’$¡½„3×|Ó$ý$ÈR¸2Æ/{ë³ý4±ò�Õc¯ÕW¹aµ¤ôó,ÎXT¦JP¶Ø¶ÖVDÙ6
-^AÁ³"r�
-DŽ49œvDü¹„šný~¹� æÒû/å¢õ>ÉÃP©_¬MËZç¹—ù
-ÜѸU‚>Gy%â*哦�tð–RW8
-Ÿ¤IhsÜ]W‰y
-Õmíš™Q‘‚z
-â~ó
¯	fÙ"‡èâ9Lt¨ž¹£j¡	mK(ÈÏbµ
-endobj
-920 0 obj <<
-/Type /Page
-/Contents 921 0 R
-/Resources 919 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 886 0 R
-/Annots [ 927 0 R 928 0 R ]
->> endobj
-927 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [519.8432 268.1131 539.579 280.1727]
-/Subtype /Link
-/A << /S /GoTo /D (acache) >>
->> endobj
-928 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [84.0431 256.1579 143.5361 268.2175]
-/Subtype /Link
-/A << /S /GoTo /D (acache) >>
->> endobj
-922 0 obj <<
-/D [920 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-66 0 obj <<
-/D [920 0 R /XYZ 85.0394 769.5949 null]
->> endobj
-923 0 obj <<
-/D [920 0 R /XYZ 85.0394 574.3444 null]
->> endobj
-70 0 obj <<
-/D [920 0 R /XYZ 85.0394 574.3444 null]
->> endobj
-924 0 obj <<
-/D [920 0 R /XYZ 85.0394 540.5052 null]
->> endobj
-74 0 obj <<
-/D [920 0 R /XYZ 85.0394 447.7637 null]
->> endobj
-925 0 obj <<
-/D [920 0 R /XYZ 85.0394 410.3389 null]
->> endobj
-78 0 obj <<
-/D [920 0 R /XYZ 85.0394 348.7624 null]
->> endobj
-926 0 obj <<
-/D [920 0 R /XYZ 85.0394 311.223 null]
->> endobj
-82 0 obj <<
-/D [920 0 R /XYZ 85.0394 189.9853 null]
->> endobj
-929 0 obj <<
-/D [920 0 R /XYZ 85.0394 156.0037 null]
->> endobj
-919 0 obj <<
-/Font << /F21 658 0 R /F23 682 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-933 0 obj <<
-/Length 611       
-/Filter /FlateDecode
->>
-stream
-xÚ¥TMs›0½ó+t3EÕtÌI�;ŽÁÓvÒ£$šbp$Í¿¯@Â&Mzêx<ˆ÷vŸvßzM
-ˆ,}Q7c‚}vû ­ƒbÓJP*ݾ-Wfü¦=»DÖ+ýÉ\Kií“ù'çs·?0¦¥ÃUõW`[ïí¡”Ï²´ÇB
>Ém[7¯ŠšæWN¸ênÈÚÊQD·�ºïZ3ô¯åcõóÁª˜¯›æ/æñß*ŒKzܹénÐ8AabD\Q½Í„¾«|Üà÷¥ÿ
¦œ@šendstream
-endobj
-932 0 obj <<
-/Type /Page
-/Contents 933 0 R
-/Resources 931 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 886 0 R
->> endobj
-934 0 obj <<
-/D [932 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-86 0 obj <<
-/D [932 0 R /XYZ 56.6929 769.5949 null]
->> endobj
-935 0 obj <<
-/D [932 0 R /XYZ 56.6929 744.7247 null]
->> endobj
-931 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-938 0 obj <<
-/Length 1222      
-/Filter /FlateDecode
->>
-stream
-xÚÍWI�ãD¾÷¯ˆúäH¸âZ¼©OÍ°‰Hs`8Tìrb�SeìrBƒæ¿ójs6sà
-©Ç¥·†EòS€Š2Of=§&ü¡W.tÀLFXôÚyÉß'1´¦÷fÓ¸<Žn§&=Z|KÁµ½áDnãÖ
[;ÑiteL-dçÞ^z@3Š Ñr0¡sSùØò¶Ð°´@EžQ/ëph‘@#†I¨„ƒÜkg+¡Û“€:cŒ£¯&L0À3LDc‚o`Â=æÕÔÕn¹ó"¦iâ$ü©ÏÍZ™Z}!W‰37µu£VDS' Ðò‡4A¤L\û6è@{{VnZ&ÜvœvR˜ò›ÍÙžÛñàVÚkÙRºåÜX³iuD·°qÅâUwñwñð—{à’ œˆ¡dCØËía~}øée	”®[³M#AJTyy+W·´@Aÿ­äóFèjc†£Þ=æ0Tè½>Ú˜ÍEq)·+\]gR½
=^Œl9¯ËσØÚ»Ç
-ÿ¨2ûù@[ –¤('ðVt„(þ°	F—7¯€ÑK‚sTRRx;Ö›#<鹎{žëøIÜý7¸Pé´«Õqþ›ð™˜1t6Ihb–{â^Ž­(áÏ!½Žm‰CÁe
-5€B=—âÿëÄæ�/n¸GÂä^xÞ`W>¾QAF?°9¯ª™Ù;ëƒû9âãòíÊwÁ®|»�0«ðœIª
Ÿ:½äÊ0
£•0ö1¦ÿ˜SM™^ÿ^r0m%©ßÑ1¡¨Ä	ûOèøéÛíü•¾]hŠÌ—ÐÒwP‰/2î#èñ4ÉPAÊ<2yazïmþ¤zt÷7¯Ì™øendstream
-endobj
-937 0 obj <<
-/Type /Page
-/Contents 938 0 R
-/Resources 936 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 944 0 R
->> endobj
-939 0 obj <<
-/D [937 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-90 0 obj <<
-/D [937 0 R /XYZ 85.0394 769.5949 null]
->> endobj
-940 0 obj <<
-/D [937 0 R /XYZ 85.0394 575.896 null]
->> endobj
-94 0 obj <<
-/D [937 0 R /XYZ 85.0394 529.2011 null]
->> endobj
-941 0 obj <<
-/D [937 0 R /XYZ 85.0394 492.9468 null]
->> endobj
-98 0 obj <<
-/D [937 0 R /XYZ 85.0394 492.9468 null]
->> endobj
-942 0 obj <<
-/D [937 0 R /XYZ 85.0394 466.0581 null]
->> endobj
-102 0 obj <<
-/D [937 0 R /XYZ 85.0394 237.1121 null]
->> endobj
-943 0 obj <<
-/D [937 0 R /XYZ 85.0394 206.4074 null]
->> endobj
-936 0 obj <<
-/Font << /F21 658 0 R /F23 682 0 R /F39 863 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-947 0 obj <<
-/Length 1859      
-/Filter /FlateDecode
->>
-stream
-xÚÍËrÛ6ð®¯àøDÍD0^$ÁæäÄvêL⸲RO'Í�"!‹>’²êvúï]<HQ2e»­gÚá
`±Ø]ì“ÄÁðÇó‘ÒÐ	BŽ<L<'ÎGع…½w#bq&-Ò¤�õf6:>g�¢Ð§¾3[ôh	„… Î,ùâ2ÄÐ(`÷òäãÙxB=ì^ŸMÇžçþƒžº:›žŒîÎ.>]^�'
¹ûöÇ“«Y‹ñ4�·Ÿ.Ï/Þ}ÞÒ�½�Í:)ú’Ì”ßG_¾b'
�ß�0b¡ðœ
L0"aH�|Ä=†<ÎX»’�®G?u{»úè æF”ùtHuá�ê¼ùŒ2­ºßËBŽ'>ÆîFÀ
PZL¢$©PT­¢#³÷‡Ô¡!"€'"…žG5�æ~e	äQÝÈêµFÅ»H‹4koÉÊ8Ê–eÝ JÞía›ç,Ê&]Üü¢4(“ÁËÿ¼íøØœ½±wF•šå«®eu׋Òò·(_eÅe>ÄaOk=Ì—WV�8JæÃÚj¥½¸²ÒÂÛɺ–µ™–+fÝɾÄv?ʲr#« ÒŽUTÔù”2¿šÂd÷È#: !EÄ<„
-Ô"xÈcÏxüçYyÜ2¢JÚ7‹â=¡�¾iìbÿóÐŒŠÐ·Ž]úhþíèQس�]ûØí�ŸÐ7Xu+žz¯L_›¥ïEzïu|N‰C8b„,¸È£ˆ’Іy:ž¤>”QbBò›(‹Š8-níqÖxpš
-ä¡	u'ã	ž»ªÒ<mRõÎj
-o›HiB�™&® yG\O㨰ëöl/Sy'-vjwu”QÀ©Ê3ÿތ뺣•¯³&]e³áʸÔcR›Å_±‡ëu¼´wÕƒªïÈ(eœ˜a�Ð!fCÛ±´�* ˆr‰:Â

-
4ás�*Xëü¯`R7]¨UîÞ—câ®
¼Ô>£p›¥¹Zš�››³Þ5Ù¤ÍÒì²Ù”Õ7³¬ŒR6¡Kí—³ETf‚Üdy°SjωÁ¶ËìÕ`Œ%bŒ4Ðo
ãCÅ+,£t€"½Ò>),,JìÌ+Â4—ôØ,#K;ÎRY4vy“f™].‹BÆGZ5ʨ½*WÆTØkÊh–©aÍðѲ­ø�²IsùÃ~M@Ú0u˜Oó9yVQB ìBì%ÿìTËG/ŽäÀœÃ@Ë‚­t»¤&­LÆCÄqØ<;þ/ÂÜgƒ†ž¯ut	?žpÁˆ;›}PøîÛ'×ÊWy@ÝÙ/WPþqB}w*ër­õ[™v¶bæÊG§Ó­‡�FM´ÿ
-ß×
-ÞƲƒZéÝ÷²ZyQ7$ºMñžÒ
-dŠx¦VØa­ôî{)­l;¬ÿ":RL� 8b ¸À¸AÛê=hùh
-€¬SËþ‘.oBff¾ï¾¹¸<5û6íµ˜e5²#’ÛÛUæîÝ¿*Û�
î–Ÿû–²*ÚÝ�ùAJ§A¨k35FfH Ž�]Õ®(ä¢Q%”E挄ڦR->‚‹Bá^ØÚؚȒœ—wº<Á6õ«
£Ak””yvog†A©KÐÞÂ0ÇÝ¥-s•á•Ö9ô•ý—ñÚŒÝÜŽÄ®›ª©¿aGªd&ØýºYÙÊ+@ëÚ¦Dà΅˜Ví©]™úkͺ*d²ÇF’ÖqÔÇí¨Zãhº*•BÃÑ«RÁrs‘4³D6Qš¸Tzät«>]¼Ñ³ƒŠS‰Ï¡Ä_ªÇ�¿kaº+Ù:%D!â3ÚÞ*¨*'e•˜æhß1ò|Á,n½ž×Êrcrp…~æƒW	h_0åöt¹jR`và检ᖣî
--”ªzå¡U$äÈ×™ÀìT·Ž
¦C¿æ¶Ø‡C�ÅQ|L§ºÞÖßúÚßã…@ŠczÌ<xΣ<ìSRL ¡¾r�©ï¡~ž!_´ý�hûKS$ê_€ö7€b%«¨ÿ¤Ë*¦Ûd~÷O’Xr³1!Ä-ˬÞëÃ>·Nt3f�k£¾ñóqÉÌz¸á…™g‹Î–©îBB°€Xñm&‰¬ã*�ëðŽì
á(3{i
ž¸’EÍuoªÐÓ趀h�Æ*ÊSÕ©åi‘Ö�ÒÅ�E2±
-endobj
-946 0 obj <<
-/Type /Page
-/Contents 947 0 R
-/Resources 945 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 944 0 R
-/Annots [ 952 0 R ]
->> endobj
-952 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [55.6967 190.8043 126.3509 202.8639]
-/Subtype /Link
-/A << /S /GoTo /D (rrset_ordering) >>
->> endobj
-948 0 obj <<
-/D [946 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-106 0 obj <<
-/D [946 0 R /XYZ 56.6929 480.2651 null]
->> endobj
-949 0 obj <<
-/D [946 0 R /XYZ 56.6929 441.7923 null]
->> endobj
-950 0 obj <<
-/D [946 0 R /XYZ 56.6929 373.7178 null]
->> endobj
-951 0 obj <<
-/D [946 0 R /XYZ 56.6929 361.7627 null]
->> endobj
-110 0 obj <<
-/D [946 0 R /XYZ 56.6929 167.4388 null]
->> endobj
-953 0 obj <<
-/D [946 0 R /XYZ 56.6929 126.8733 null]
->> endobj
-114 0 obj <<
-/D [946 0 R /XYZ 56.6929 126.8733 null]
->> endobj
-954 0 obj <<
-/D [946 0 R /XYZ 56.6929 98.4089 null]
->> endobj
-945 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F21 658 0 R /F23 682 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-958 0 obj <<
-/Length 2706      
-/Filter /FlateDecode
->>
-stream
-xÚÕZÝsÛ¸÷_¡—NåéÅA°O—Ë%×ÜÌ%×ÄiÒÌ”– ‰w©);Îô�ïÀ$EJÎø©ã
àò·ËÅ~f3
-l¦SBE.gY.IJY:[ì®èl
Ï~ºbž&	DI—ꇛ«¿¾Ù,'¹âjv³ê`iBµf³›å§ùË¿¿øõæÕû넧t.Èu’*:ûâ—W¸ò
¥éüŸ�âå»·¯ßüôñý‹ëLÎoÞ¼{{�d4—ðæåwßýúêñ½ןo~¾zu¿¢û¥Œ
-û	\}úLgKøàŸ¯(¹Ng÷0¡„å9Ÿí®d*H*…+Û«Wÿˆ€�§îÕ1Í¥B“TólDuœ�©.͉\8ÕÙof„]'ŒR:ÿ±,ÖUÝ´å¿öæš16¯ëmc¿ðD�ήHγÜ!ÝlŒ'ê2e9¡)³²Zše¹
b’äRhOóÝŠ$Z$Ø€€c(9*ã%á’Í‹j9Çaw¸–ž´j¶uýûq?‚)SÐ>Ë<áþpÍô¼^Š]ðBÏ·bì$ŸÛ-®.êÝÎ2v“mYµN�ŽtUp
èŽðÞÎþ8šÃCY­qV;�ܘÃ�94ÄJ8KÏ@ëvž1’§)êÀM[–++ÕÊp^VøÛ´[ƒC”õ±Ý[ƒP»¢%'6MaÁÑ”ÎÁ¸r6(éRM›`¤êE—g¯hÁÏóD#<{vAÁ¼”LûL­µ&œfóe½+œ†¨M¡ʺ‡kÜñ½S%ÌÿMS:fäR°6ñ
VH1Ë™·A¢�µo7²›Ò¸]
-Ü5XÛoMëéëUhü’7h7vfq�çjþÆoŠÆÛR
-’S¡ú¶ÔÞ×׉ DYšæo׉d|Þ”–)®—UkÅ¢-ïÌ#!Žœiˆ%ΰçðš³oRÀ=“øEöÉmÑ.6C¨ûMͳ8¶¦ÁYÑ…³ßAûò£{�I›Ât� ÀŸmÙx«wÚ³Þa@ÛÅ'ˆì)+cÕ'�¿Øž>¯÷Ö\�ã��,¦iÊÛàt+4¦Îp»að-<·S„TÇ5xƒTD0H‡#ÞÀ •ÂxÌU¼@Šèbœú'£0–ê‘“ÕæǦX›I™„$"ÕêY2u00ãçc2ªàb‰+ûô=ºZÚu5‘­ÒÔ»FO$ë!E8¸­'û<ŒÊû5†ŠS Ɉ–"
-Üx"âÂ×dU“
-¨€©¾PÕt©¦«šHÕ­R»LmÈ“T©ó\#Õ[1ŒÂ–Å=¾Óe8“ü|ÍÁ�iŒ‡G(<ÊÖU¦éÜìöP3”×lþÕ4¸ä¬¾\D_ñJHºÎ`ɬ€SØJÓùžxiVÅqÛÚÍPµ¸º¨+0ë¶Á·nM{oL…�6XÁ²-‹}õ"¡gR”‡Xƒ
-ˆöÆ)•ñÆY,—hÖMc‚Ñ݆ҷl½u®ŽÕšeá?Ýšo°£[o¡æKkª¥Y·n7g>‰
ÞÔ'{J9¡
-vòI´‹1�Ø#ÕÅÄ.sP.tIÏ‘©‹1�Ø#U4MïIñr¹­ÍÍý]ˆøÉb,�ð{-Cv›Ê�<‡&r˜B’·ˇjY·“x±)�€íEÀ‰ÄßÏ\ï_—ñÊ��>î	IÎC¾�„¼­‰Ê¹ì'îƒi¥ižŽ½»(îj[¬Ç>‚^¦ùOÆ‘+Ðzˆµ×4�‚dyD¿X¡}[ÉØ/xšð¹ÿ¯Éu:;è4ÚûÓ²«ä™=j’ç³k—j:»Fªá™M/Ãr
ýlÆÏsŽTX3H¬LÃNò>=/Ò:çE¶ËNx&°Ÿ¶ƒÐO‹4ë÷Ðö!nªºJ:OmêÔ>�ué±Qvon·õ}àµñ‹�…˜&UN˜à|Ðã;‘2["BVwÝ,Ìü™Œ¼@�s쩳ìÑfá™3[X+nk—JaxËÅ¡¬�þ=kM~è?Pù’Õ¯"®Šíðí¸TàŠwXpNA{�?&,„9º�ðŒ\÷žÍßöÕŠ„^‰@ëÎa`ô¶Ä‘“ž‰`é·cãG>Û‹ 2˽OÌÑÅA³@ÌæƯœ�‡c
-Ø¿±C_ñXgîUú“U„È8äAö¬*¢‹1]EDª‹U„P”¤\=ëÈ¢‹1]EDªž‹úÜ�á�Ù„ñ©†Z
-"U·FNÚ:Y•á¹ßújÂhpôÿ"ŸÄ³C×ù<ž Œ¦*ï%‡¾gë<%ŒœQ¯±$Ϊ–¸p¿q•qN!Zà
-ž=­�¶ámºKj
ðí1&Ú/L|)ŽoÌ:œ9{fغÂÈÕÀ¹+q—îsÄpÑ\£ˆ*VÆ–1å4ë¾ÀH‡.˜;ï…éæa�)ŠüŸäÏþØÔÒ8gë‚7ú‡å%l$·èu$xpŽ¢«Në0b:�Ä 3ãO@£A…™œ“äv�Nâ‘ài8ý„‘Øþb<²#T¨¹�\yfvÉ»Âïc×cg=aÙª‡+·Tãï­b](°¶®dù•£Q7˜–†
þ¢šað¸åöig[\G¨ý�
-<Cug*0‹›9xË?Ý›Ei‘Í��ßUù}�¨.Õ`ç¤ïO-ƒ13~Â>:º�V_Ó…ýuͤ ÜÐ?:Ÿ‘‘ÄnÒªXø7ñ«˜9ªÖ^
-!-h¢�è¾Þ®ÜšMqWÖN"{�ÎõüÞ#-½UíiÏÁ–(†/‡ßÛíZG®Ì4Éd,Ï•@P2©,ôYþàüccƯá4Ð~Ù
­)–d,a"·­­²IŒ(Édç~“ûûÍË]Y�*E¨
-=Ï‚PVx–%�ÿªt*úÿ
-endobj
-957 0 obj <<
-/Type /Page
-/Contents 958 0 R
-/Resources 956 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 944 0 R
->> endobj
-959 0 obj <<
-/D [957 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-118 0 obj <<
-/D [957 0 R /XYZ 85.0394 769.5949 null]
->> endobj
-911 0 obj <<
-/D [957 0 R /XYZ 85.0394 749.3395 null]
->> endobj
-122 0 obj <<
-/D [957 0 R /XYZ 85.0394 221.8894 null]
->> endobj
-963 0 obj <<
-/D [957 0 R /XYZ 85.0394 197.4323 null]
->> endobj
-956 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R /F53 962 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-966 0 obj <<
-/Length 3396      
-/Filter /FlateDecode
->>
-stream
-xÚå[Ý“Û¶¿¿BoáÍX>‚lŸœÄN�™Ú‰ïÒ´ãø�'RwŒ%R©;Ë“?¾»ø"!’’'éL;é܃Àår±X,~Ø]àØ‚Â[È„$Ï*‹‰¤L.VÛ+º¸‡wß^1˳tLË!×W·W_¾j‘‘,áÉâv=�•š¦lq[¼‹ä$Ðèõ󿿸^rI£›o¯¥Œþ
?úùÍ÷/Þ>¿VqtûêÍë›ë¥¢Y}ý·çßß:ŽË2¾~óúå«oìå\¿¿ýîêÅ­Åp¤Œ
-¯WïÞÓE
þ¥rñ”°,ã‹íU,‘±Ž²¹º¹úÁ¼ÕŸNY.–”HËÅRÄ$…þ§¸XB2‘HhO‰P 7K94dFÁEoül`ü”™erá¹Ðøu¾-‹åê¡\}øÔÔåõ2¡4z·,~ùõñ›÷îi…–úò¥iLÁ¼¡F(eµÉÛÖ0]òŒ¤©Ê,——×LÈF/�ÀæÐíÝ„Ä�ÍKì.J,ª}¹êšýqB¨ŒIÂ%;ú4!f	甩Œ1’IɯôUþ™JZÝ×;4¬,°ÆŒ¤±pR™ƉJTlžò}=!…’¡«¦”u^m@+67Õéé ë?á ÇþüÓ¤£ð”(šÆ¡£ü§‡û™ŠN¬_«”áÐkÿ’˜wb$É”JœåªM‰€2!)V$åT

- —ÅX²PT¥Ôôcy–&�rœMm1–i
-º¡»gqF“êlÿži¬@`XXï4S,Ðà¦ÚV›|‘�Qgñ/Ð;–„RæL}ËÏìÃ~Ò|Á[ôÐR¯ôo囧üØZqØîZCîJC3h�¤USweÝyÝÌçæ±Ý•«êgJyY 
-‹%§1á	eΫ™õjÊ7¥ÙfÑûã®Zå›ÍÑ�ªÚüæ槨Ö×,�ÖåL×@^7ûmÞ¡C“9÷HAÒKî1`šwÇ„ÚïëbuÚ£R„%2;Û£ã÷Ì',V"èñVÏBÊ#c�mÓÙg½z Å¢"rm¨8Cš³ÙÚx‡ŒŽÆ~Q»q�(Ä)A}<ü2#sgz¸ßç[C€ùkžZ£Mçn�mW:†b[ÕUÛísØùI»Ï”Æ(@;«Qmµ!,6»¤T8`Aã¨Y›ßÜü«*¢¶Ü?‚Û@
-uÖ˜HËÌïW_´Füê!¯ërc„o›¢çàõ¯ÖÆg1æK™„ wl¸ö×it˜RI(ˆüRyÁß84…Sû©êšƒEļ¶
-½Ñ
-ÓxÞB®3&r\¡�À	ålöÖgT�È M~7!E»òD]%�®¿Y1nE<VåÓ”.á‚%eö/
-þ}Þ–žklÌpŸÃè"KYhÍáÔ{÷¿¯˺ŸäÙ9Ž3J
-sÏ\Çð6ü½¾
-bXvÞ¨žklÕÐ/ j†¤�‡f½9´»·w!âè°+ò®lÍÖ„)KáOq¬ómµ2–2ᘰiRÝô¯L«²‚tAkiK‚Äâ´aª]˜§f½M×`¤Iýyjd¶–æÓVxh�òe�•	CĨã¼4R$xm}È­¤²¨:K6uÝ•æÕ6/ÊáS�K}ÙZ5–˰Ćc¡ajjl‡†½;â/C£AÎmíφ	µM Õí³I¾±µÊ­6?¶!A¾7LWó�h‹4ú¥9ìë|c\¨†œ�ugÛ#
-€¿±\¶4DÃy°ë{ɹ‹ù¸«CñAŸøàÃChk{
ç�}v¶G=1Øóó�ýÌ{>k˜oó®+·;=7ÜçÙœžÈ\ƒ}¬ZOÕfr­z8sÑ¿…µOe=‹_°0ˆL“ô<~
¹æñËsµò§yô
-å²ÿ+àåbÔ³í#Ù‘I§#ÙÀ¦/êüN;a’öØÅ“Ìx$sóØÏ»!÷^/-–‰$ÑX†ïë¦e(•ŒXæ L¤$NéÉ©d5À2å±L9,S¡.ðì±M
±
kô86�làíÙR�ø�-+W°0ÄÆ0a6Ô2;<SÃm>(ªöó)hÓP
-endobj
-965 0 obj <<
-/Type /Page
-/Contents 966 0 R
-/Resources 964 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 944 0 R
->> endobj
-967 0 obj <<
-/D [965 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-964 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F53 962 0 R /F14 685 0 R /F21 658 0 R /F23 682 0 R /F48 885 0 R /F55 970 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-973 0 obj <<
-/Length 3750      
-/Filter /FlateDecode
->>
-stream
-xÚ­ksã¶ñ»…¿Už9ñð$ÁöÓå’K.3½¤wîc&Éth’¶Ø£HG¤Îqû绋@R‚$OÓñx‚‹ÝÅbß ¿fðǯ�N˜ÌÕu–«D3®¯Ëí»~€wß^q³ö@ë9ÔW·W¯ßÉì:OòT¤×·÷3\&aÆðëÛê§ÕÛïÞüxûÍÇ›µÐl%“›µNÙêÛ?C3Ÿà•Ö«¿yˆ·?|x÷þÛ¿~|s“©Õíû>ܬ3–+Xyyí?~3­ûtóËí÷Wß܆]ÌwÊ™Ä-üzõÓ/캂
Å™}ý,áy.®·WJËD+)ýL{õéê/
áì­]“œ–&ÑFdÑ	9—<1©4יΓTÂ;”]SݬejVÍ@¿»nVõ¸ßuuÒHS½ºÝø—EÛöO~ÜÑoýÛXﺢŧ|õh×÷e=8°±§ßª°mÓÕôø´©Ýú®ØÖŽ‡MQ–²ß>¶° B
Ã.ל'¹ÖÂr<ŒýãcÓ=$‡ÒçLÁfUv�ñ,‘"Ï£â
-Pë9˜—2sq1«tB†´7E;‚P[ý´~üåˆ�T&™Ròê˜�åy¥&É„>ààìTQÈÕ¸©q VC½ûRïh²Ù‚4›b¬ÛçÎù
-ŽP2¾úX—u7H¹)º‡ú†¯zÞUí1Òéí64Q=Ãé4%‘Ù?V€—^ôŽÜû¼ûhÏŽ
”‹›åQ¤MÀ׫®i0_ì‰ÃÐjW´œØÈ{ÁñÏŒ‰¶^Á“ä«»½[þÔ´-�îÜ"âºm=Öû~÷D¤+BO[GÔûW¿wš;Qs4H=ðB	Éå™ç©5‘;6êa,v£µ¥²Õû{z·~\Â�uÙ Iä_X3øÃ@+B𦊑
-VŠ”ÈJñeq³æ«˜Œס±âo0Öˆ]-‰‚¯ÃÃÁß™éâ#ÉGÎtqhM“éºùv<k«©æ	癸`«s°Ó¶ p?ã®(ë#º2OŒ”ùºê˜îÒD•Jù-¿ïJ:Ÿ-ÙŠrã„Gz3xÁÞí@<ôØÖ_ê–†wÏôÛwõÑ	–dÙ%Á 3b#˜…Ð^¿Óz*5˜7Ì0Eœò•é$Í!ú�ãËÃòµ«aIj˜™3ö©‡¨,!x«Õ.JÔ+sát·þí±mÊÆ�Ï—¢ÝŸ‘´ÎY¢„0d=;-í
-w»«Ëýn@ß~ª�9O;2G´ã…Ì‚ø×ûíãÁQ¶ÍàäÔ;™ÿº¯w�÷³tÓø'ùucû<xؘˢ*R40’å)°n ž”Ê¿�Dß̤›³ÃmQ€‰tM�¶6žÆ¯ûÆ”(ŠËP,k‚(l�K ÞH!�nÆ
�¨
(ïÏpÒ)öðºq©-l
-\5‚sÒ9¼¥i+,˜G–p¶ Çaã*¶Ê¡ª]&;¾Â‰Ô™ŸE8
-Ï‘œ¡7½ÅíÙîb¥
-IPHEŒ«ãÃÒWt¶VPÕ4ëý…]×öeX °n¤�+úü	0—€ït®b×UeÌŸˆÄ°ÔGØ_ÊñEãf �ŽÌš\Pïk�âu=–¯‘XÈî#�„d9åüiº)èt)6[B•Wźl
-`z&
P;š¾óAwQ³Âw0
-[ìCL7YêX[ÇäÅU¢“¤DúxdœQíì�øLÏ&¼
Ò„ñÒ'ÃÄ}¿ïªW‘³DáCEÃò¥!�:T™¨Lx&]‚q�ßÐÓ¨íûÏ4jºˆ$2•è”§GGú¹~Ž�({ð“úg¦*&"«©ÑS“€$•KåµfxP]ªfÁŸ
-pƒÚkÌS1òªFYvÖÙXZ¶#rS0øêý‡¯]»‡ñŠÞìPÁšu]bæ8ÐÁv8¶, c¸�j
i§V&;;!'HŠ@¨Y�“S稑øCÝÕ;òŸ8mËjøÝݘվë\ä;P
.t¢4Ëfô×(Ë›�ÂêuáNXpå3Ú<Št(wÍ�kd®e&“\è|)5Ò˜Eü¤‚éÀÙºŽ^î®iðq‰=üz¾ ‰�ðR!XNVB¢b¥½L_ð-î-Ô%.Ž°ÙüŒD”‚ð¹â>DÛWÖwËÔ:è-†
™RbŠs£yÀ
Ê+P[A€Ü6m±sË{¤x„3ý}Ì•i°`Åù¬rªN9d�£y™à�×°×¾ô-P§€>£Þw‘i‹û�Sp�’§ùa÷ÔKØiv"VAÊ•3¾ðªC„U‰$¡ã
-9dì,Ë^ŠÄ¥:^D×܃a¦±Í<Qyˆ®‰áÅÊÁ$3Œ, ä Pz
-�üôŸÕԲƗO”¤À¨†¾Ä¾:��€M‘Ëeô @eÒeJc2Ü@ol>„¿šÍ‚0ë*Ž6M¹!
-´6ÐÝôûÖI
-”µƒŒ¬ªfÚ©*Xª4\õ�v:æf}�YïÔ'r³ª)h³çàv…¯£z¨íéB7Oƒg_žKÈ�U$§;ßÓKš
Å­ŠD#ƒôXЩ9(P:G
¿1le P_#Ü€¦
-m^p´9÷úçnG‘øÔ¿¡N”‘¡�s¤CYÂD0	jtEÅœçAym•¯Þ�n³Ã3x½ß|¡�‚Tuæ¿è­*b‹Xíîàõ©¦‡áI†Î	öPå¤%Ó‘Xj‘™Rfü¬DH—Õ }r‰	!_v.
+ú'8à‰Jƒyù�Þ÷ø½ŠÍµ5¹$I¾ÏQ�{å«Z�䆧Kçs1aVÛ½
uÂ5E`¦ Ÿ/EkïèaXõÛÂ@n×ðòßUä+ÛЮ®Ý"Ê­_9î‹ÖöçfT6
”±VDåOîOÔË7{[HéùÆ),n›Ïu,�ûY´Â­Ë]?¼^S :0A‘
-ŠR
Õu
-zô¦è�\Ë)î•rt½Æò±W”³¢O~êiæ\¶
-¨RâyÑ>ô;ðÛQ•Aõ
-Í““Ô¡ÄäŽÅE‘&à8ÅäZPß4¾³æ?ƒÁÎ4ùß…JE:séê±Ø
6]S©OÒ`T”eý8ºq÷Lƒ ¶JSF¡|‰¤ÒÔQ¹*
-ßxá ¨ìè:
-endobj
-972 0 obj <<
-/Type /Page
-/Contents 973 0 R
-/Resources 971 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 944 0 R
-/Annots [ 975 0 R ]
->> endobj
-975 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [120.1376 365.8002 176.3563 375.0156]
-/Subtype /Link
-/A << /S /GoTo /D (controls_statement_definition_and_usage) >>
->> endobj
-974 0 obj <<
-/D [972 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-971 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F48 885 0 R /F55 970 0 R /F21 658 0 R /F39 863 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-979 0 obj <<
-/Length 1632      
-/Filter /FlateDecode
->>
-stream
-xÚÝXmoÛ6þî_!û`Ãñmý”iêM»ÄÉÖvÅ HŠ-T–2Knýï;Š”,ÛLtÁ6þ`R<ÞŸ{îŽ	0üHÀšê@êqLx�,G8˜ÃÚɈ8™°
-‡RÏf£ƒçLiAE0»èR+E‚Yú~ÌCЀǧ‡¯Ž'!åx|~|6á||	íüõ›ã³Ã‰ŒÆ³éëÓóI(±ŽÆG/ßÌ:‰¯ë8z}ú|zr±Ñ3ù0{9:žõ§ž”`fŽðûèý¤pà—#Œ˜V<¸…	FDk,GgˆGŒuOŠÑùè§^á`µÝêEŽ`D™ >èô
-·£†1Ò¸„[�Y“ïPR•×CB
¬¸3x[­‹ÎHQT·vØ,2;Hªå2.Ó<æC¢€SJpI¤•­Þï¬h¤†©‰´”Â6.ZèWYQÅ©ÇÓÐmpŠ-bM.I.•e–4vÒ=ì£h§7ÕÊ	hÎì
-8PvH¹§H›âà-öa¯1ªÜ¯äTiĈËÆGsÀ}غ¬µç@®žQŽ'r;÷ÎzjÙÚj#ÃW€
-‹¨„¦ͳÒcZ0D¥ê„o,qç«xi-Üæ…	�†—Ÿ²2‡�wv-±é
�²±/DàbèÌ}Eú²ä½Û¶[C&ú­…»j
yÏ°vÌ2F‹º²x1&PD‰ÜÎè4¯oŠØxL¨+
-q†£>ÛÛËÚm'Pû#%†i‰"ÍÈCº	kß3øN?ù¶]�ƒk˽Ø}t¹a‡óNCëÎ2Å
Õ·³-5ERIÅNC1Š,cϧ'/.Þì‚D$!ÁY0Pø÷\ì5îû¸C�ˆIŒ-'�ûë�Ûô†ô¸/A®�¥¾LÔ‚H~C-èêÍæêºãJC:Äu¶G¶®7„èǃ‘i†$–
-endobj
-978 0 obj <<
-/Type /Page
-/Contents 979 0 R
-/Resources 977 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 944 0 R
->> endobj
-980 0 obj <<
-/D [978 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-126 0 obj <<
-/D [978 0 R /XYZ 56.6929 466.6686 null]
->> endobj
-981 0 obj <<
-/D [978 0 R /XYZ 56.6929 439.3642 null]
->> endobj
-982 0 obj <<
-/D [978 0 R /XYZ 56.6929 409.8468 null]
->> endobj
-983 0 obj <<
-/D [978 0 R /XYZ 56.6929 397.8916 null]
->> endobj
-977 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R /F48 885 0 R /F21 658 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-987 0 obj <<
-/Length 2297      
-/Filter /FlateDecode
->>
-stream
-xڥ˒۸ñ>_¡[¨*K<ÉiãÇ–÷0®x&‡Ôz’šáš"µ"egüõéF7(JâØ©ÚR•Ø
-ë2‡‰�+>ÎBØ„¿™o vfÈWt‘—»º<1c…âÕ%KS”œŸð�Xú}Fb(59J“R`cÓ1'
-cß·C¿yQQ`MÖéh&×Ê�ˆ

-GID濯œ	3ßp-“kºgÊÁ«²rò+–
-Ìg]©†q~ÄÄ%d!ÄØ"¹_4Èt6ÏÍÿB�že´=…б/û–nâ¨pØ×eó)MdÈÙ´Í@*28²É¨•d>¾{M€tΊK±LV¦¥�tã?o~û=]U ž_oR¡]‘­¾Â @@­v7F*á\fâL{swó¯‰ D°BË%Â2-Ú—-ãŽsR›ÈÜF›ªŽ,›+dŠâÛ•ÃðR€Ë‚y9×
-ln¯·Ö&MN¾q&
ÈK&s’·«‡Ás1d’p^H”0¨q@܆ԙ„JKÏÄ‚XÍH߶÷U¸øo&er‡®µ}nºÇ~UjPY,Ða!‚6}×"Áç,ÜÂia
-�1�PÞ�몧LŸ—&¥?†
--/HØÁÎy&å»À®”N¤Vº)ì|O¼…p©ŽEÞ$P¤>ÙG~²­�Y¡Ê †¿3y^¦kWÔÀàÜ•ÿZtÀ8”9ëVÞû—c×yÀ‘ópÖmD4( ×p×b„âžãÍ3è«))êþ{_a
øãdÚd]Üàöáë鳫ǧ>ØBšlƒ’p­ªÀf±è„J’*Å}ëK´ã°ñªº­Çi–K*-+>&¤�ÙqQý
-oQÈ"ú5QÚìû¶)—ª:kE¦òXÕ•-Åä…£¹ ¼>Å‚3eSojÍkâ
-}FÇ>ŒÈ	E?n�gÊ�›Ìº­Eñß`{Ó¤p0ú¡†.�[$.d2ÐèSš¥ßbà2Éq˜öƒÍݽ}
ë’–¶=÷ò¸H¶
-–ýG[¨R¹b»ðŽàK¦`ý4ðÓmpp{ì÷J0	F¦åǺ«~F“‘þÅÉe‘<ßéuô…$ÒtŒ{„"ù\?¯%dCv¿)#Oý¡ùæcq™Å£=ø!zVl”C·ëc©Ž>Ø<vø¤Cní©þï̵a¯Ÿî0Û1q:½	�ªÂ+ca´)b|ž^…¦ˆòG<t1"a8h_
-Õø†¢fðçð,‘ÍÞdT†ÏUMÓ!EÃ×Ó'öûÙ¤
˜¬N9âD¦Iï°a¹ï¯h‘‚”�OöôÖȳ»X¾jPåp]RKœfb<‡ÆµYÒåÜâ¤NJb…­
&x�¸‘ú¤€¿>ÕÝÅ2~F�
-f2€ïFt-˜¢~¶åônwâ-ú¬;]àc×BλÈs¤Hz	ƒúÅå©9Eª;4UUw—iwÉIÎ’iÌ�œæšÎž¿“²‡§þØVÓcïb¢uÕŒ1tì|w|ON~™
ˆI›ÏŠ“<>Ú<¶=
-ö
-endobj
-986 0 obj <<
-/Type /Page
-/Contents 987 0 R
-/Resources 985 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1001 0 R
-/Annots [ 991 0 R 992 0 R ]
->> endobj
-984 0 obj <<
-/Type /XObject
-/Subtype /Form
-/FormType 1
-/PTEX.FileName (/usr/local/share/db2latex/xsl/figures/note.pdf)
-/PTEX.PageNumber 1
-/PTEX.InfoDict 1002 0 R 
-/Matrix [1.00000000 0.00000000 0.00000000 1.00000000 0.00000000 0.00000000]
-/BBox [0.00000000 0.00000000 27.00000000 27.00000000]
-/Resources <<
-/ProcSet [ /PDF ]
-/ExtGState <<
-/R4 1003 0 R
->>>>
-/Length 1004 0 R
-/Filter /FlateDecode
->>
-stream
-xœeU9²,GôûeË@@Q‡�!é¡%bd(dèúʤ—÷ÿ(žÑ¯
-’$¡T¬)ÿ®ïë¯ãïãÇ_¢ýþÏaíÏc‹®½Ú¿G—=ûÌöÓ1ÄF¬lÖ]töö×ãqu‰Ý¦‹÷5š�”�<8Ç—ý:\;âúãñ‰ü<q¸Í;.\ži2c¶û~ð¶e¸í×qc¸=7Ä+Àg
¯ã�ã×ctéa³ÙL1ca·cu™šmQOƒ½¥ì-¡
{wñ¨¼&kñÄÞ
-¨9xcH
-¤Ï’ÃigÙ¥—ÇáC6uéíÛ&”\ÊGTœ„Méêö–KòlÜ’Fyu|?é%åiÈ¥K”êNÊq{vˆ�*êèJE¢]8hÍò¤p0R±ˆ$Á(+ÁnÖN¬
-q�ª„Ñ«ò�^ÿï>‹«>÷—
.13×…Óƒ!¶3¢SËAÕ”ih¥Å¨Š^…(€<Îm䦽ªšÛÆlLÊâ³ò7Ù
-г2"ïE9~ 
-n*Œ1½÷¨¾x¥Æˆpîâ‹
&Xî
Ãœ§³±è\íD¤ß�ä0}#XŒûž˜‹¸À>#^V°¡|2Îi‰9ÊÎ�r)`˜¢Xh¡Ò& „hb—H°Œe"Ãê
-þrÓGçX5¾ûû8‡´ÕªOª«t–Ô³$Ây°‰—BÒ›ÀÄ5
©/¨�vp�÷o`kA“ôr±ñœÓ4N.4Žæ
-endobj
-1002 0 obj
-<<
-/Producer (AFPL Ghostscript 6.50)
->>
-endobj
-1003 0 obj
-<<
-/Type /ExtGState
-/Name /R4
-/TR /Identity
-/OPM 1
-/SM 0.02
-/SA true
->>
-endobj
-1004 0 obj
-1049
-endobj
-991 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [470.3398 482.8902 539.579 494.9499]
-/Subtype /Link
-/A << /S /GoTo /D (boolean_options) >>
->> endobj
-992 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [316.7164 470.9351 385.3363 482.9947]
-/Subtype /Link
-/A << /S /GoTo /D (zone_transfers) >>
->> endobj
-988 0 obj <<
-/D [986 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-130 0 obj <<
-/D [986 0 R /XYZ 85.0394 769.5949 null]
->> endobj
-989 0 obj <<
-/D [986 0 R /XYZ 85.0394 582.0558 null]
->> endobj
-134 0 obj <<
-/D [986 0 R /XYZ 85.0394 582.0558 null]
->> endobj
-990 0 obj <<
-/D [986 0 R /XYZ 85.0394 543.4475 null]
->> endobj
-138 0 obj <<
-/D [986 0 R /XYZ 85.0394 324.8439 null]
->> endobj
-999 0 obj <<
-/D [986 0 R /XYZ 85.0394 292.4184 null]
->> endobj
-142 0 obj <<
-/D [986 0 R /XYZ 85.0394 174.5048 null]
->> endobj
-1000 0 obj <<
-/D [986 0 R /XYZ 85.0394 146.6189 null]
->> endobj
-985 0 obj <<
-/Font << /F21 658 0 R /F23 682 0 R /F62 995 0 R /F63 998 0 R /F39 863 0 R >>
-/XObject << /Im2 984 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1009 0 obj <<
-/Length 3382      
-/Filter /FlateDecode
->>
-stream
-xÚ¥ZÝsã6Ï_‘·*3k�$’¢toénöšN›î%¾�Ùn‰ŽÕ•%W’ãõþõ >líõfnüÀ/Aà�rxÀ/¼V±§Qz­Sé« T×ùî*¸~�±¿]…L³rD«)Õ÷ë«¿¼ú:õÓ8Š¯×›	¯Ä’$¼^¿zÒþ
p¼û‡·�w?ß=¬o´ônºYE*ð>þòpGµõãíÃÓû»Ç'j~
-Tpÿï÷�P†7+¡eä½ýáöÃúî‘Æ%s½}÷Ï›0½Û‡·wïhèÝóxw‹k­ÿñx÷tóÛúÇ«»õ°©éÆÃ@àŽþ¸úõ·àº€ýÿxø"MÔõ�¦it½»’JøJ
-ázª«§«¿'£vê¢"ÃÀ�D-h2KšT©BMVY{&Þ‹�ÍE©÷µ©¹VvTöEÖ›‚Klþ8˜º¯NVE 1DÞ}Ýõ&+Þ
-VmeOÒ2e
-*ºrW¢—ØÆ1sV¿°¡5©AD|Ru7ê,Nu¶+󑶣þ<«ë¦§îºiw Ó‰Fž™±
“'1#òè-º“g‡ŽIáLxòdÛÈ·§Þ—CÚé
±hG6’7 W«�4æcNµ·kì1§Î^sÐ>µÇ­
Y>0Œ|Š"MÝý¶±BBç(4šÚn(.­9Y�îH™²Îg³�ÖyRv
è0uwà…f[¤X21sgÆ£
žu:¾Á.&§8�QvΕæØS�cN(ÜH{“x‡EÀ'€)éë8LAb´­^­ë›=ÓO
^F¾AÂäd¢¨
-Æ„‚[£ÌÈg?Töƈ—²šYo‡4ŽðLŽ½[©àN»7-
-›˜Ýt3Ä!Á†yZ¤Á¡½5�ËP)dâë@º�^~¡›ÓjÓ6»U
| 
B™:7ÝB0HÑ�”K6ËŽÝJƾŒ‚³ 3ÃÍ�8Éd–·B–)ætZ\
½
-U,
-JÎt…Gð‹
�œwúÞý@E‹Ó+/ëUJ?ÑQ2vØs>¿£Ÿ]kl ƒÝÐk–dY³®©;¯¦
r —¬.¿:W�Þcs¨
-"<fu?ß
tЋ"ÀgÏLY|TSè'€N3‡ì·îVþ__x~±¯…—7»�HOå§1Š50Ð9+Ã^+�¶I6é9‰NºvÔÉRhÁ)²æø mPc‚P°Ÿ`{Έ°NãÌWœAŒïhx„óÁò&¼„†{OU‚tÔhÀ,kª’}k|ôÅ)|vk5=q-yf×츧0Ï”EhpÍ(%$KýÖ¦'¸—öµ
-©I3S®8!À@bÉîGG‹»d¬ÎÒ)è¨Lö¹£ªÅb"¢rg_H±ÃDÖ_ËŒ2^aW
pUÄ„Ô¥ˆHñ%Ûí+Ã_ ƒ\™Û×4¬uÙëëé[ç±+Ë?g> •âƒ!N¤g*ËN¹¨ÌwH#'¢¯í³öш­6¬ßH`ðT…ö~hŽè­.?N´Sr^£‚|•À¬¬(­ºód�¶aãF"&؇­É�Oº×8èvöH­ÁmÃ=”¸¡
-9ÐìsÉ3ÛásLÜC¶;e/hÕÒç›™E=žÍ?¹êÜKüä8UàŽs’"ºÃ²	žP~(¥Ëý�sÃ;B^~:_ؤÍZ¾‘3JŸF�åO¦ÿÎ^
À3›ûkº}h´ù=˜'	hÃÅ™î’g¹U(@^�ºÇL­@|Ú󄈥¯¤žiU°ðâ+|j—Õs ñs
-õç씯•P#¿�DÞfno.5ÃÆä“"u%½©§Î—h¦µ»Ô¢=~Â"*•ñù�g8J=x&5Že¿¥ÚÜa°Ç)
ì‡ù㚦0|ÿ�_µrˆUp[¡rR4^žv˜ÂgmùÕ-ÆWx[¶ï~þHwö%h䂌٨9	³åBÊåg#Þø›óÏž.ÿ^s¾áû\�¥Ì¬ë•Gë2ù¦u…~¬¥3̧íÝ"¥¼YDÉìž’NRBþZ�å³!R’z:2‡& O
-endobj
-1008 0 obj <<
-/Type /Page
-/Contents 1009 0 R
-/Resources 1007 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1001 0 R
-/Annots [ 1012 0 R 1013 0 R ]
->> endobj
-1012 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [464.1993 519.4233 511.2325 531.4829]
-/Subtype /Link
-/A << /S /GoTo /D (proposed_standards) >>
->> endobj
-1013 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [55.6967 508.4843 105.4 519.5278]
-/Subtype /Link
-/A << /S /GoTo /D (proposed_standards) >>
->> endobj
-1010 0 obj <<
-/D [1008 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-146 0 obj <<
-/D [1008 0 R /XYZ 56.6929 584.989 null]
->> endobj
-1011 0 obj <<
-/D [1008 0 R /XYZ 56.6929 551.635 null]
->> endobj
-150 0 obj <<
-/D [1008 0 R /XYZ 56.6929 396.4263 null]
->> endobj
-1014 0 obj <<
-/D [1008 0 R /XYZ 56.6929 360.8629 null]
->> endobj
-154 0 obj <<
-/D [1008 0 R /XYZ 56.6929 173.1662 null]
->> endobj
-1015 0 obj <<
-/D [1008 0 R /XYZ 56.6929 145.9427 null]
->> endobj
-1007 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F55 970 0 R /F39 863 0 R /F48 885 0 R /F47 879 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1019 0 obj <<
-/Length 2880      
-/Filter /FlateDecode
->>
-stream
-xÚå]sÛÆñ]¿‚o¡2æù¾qˆŸÜDi”‰ÇVÛLãÌ"!‘5E($Yéô¿w÷ö8€ )5Ó§NÆÁÝa±·ß_”˜pøOLœa\åz’åš.Ìd~sÂ'×ðîÏ'"ÀÌ"Ð,…úÓÅÉËoU6ÉYn¥�\\%¸ãΉÉÅâ—é×ß½~wqöþt&
Ÿjv:3–O_ó×S!ÄôõۯϾ¡Wß¼ý@‹oÏ^Ÿfzzñ—÷gp"œ6¾‹_~x÷ÃùE÷ůߟœ]´”¦Ü®�ÌßN~ù•OÀÔ÷'œ©Ü™Él8y.'7'Ú(f´Rñd}òáä§aòÖ:&£3Nf#â‘jL<&gVÁ+Ïùæt¦ŸVÛSᦋr[žO›ŠŽ‹ù¼º¹]¯êe8_®ê°”–%�!D±y¤Vë5×eCGw·áÛ‡€ÞÔtT]Ñɦ¸)ãWÛûr[ƒ´µË§?nÊ
²€V—áU8@z@ “™,7FzW›zµ
-BÌò�aΘȄìQZ~.ÀIKž8‚RpÁ¬È[”3�‘ýîâ–Ž�­¥b�OBîØQ]ZZ²
Á¢U:ž¢%omgAX$S™qQj"ZR
 "ç‰-á®E‹²%\-‹û
-¸ K{ñƒ©CºäÜé 0u›)ñE›)qãx6I{)n"•e	 #Ù1UÉýä>/ß]®WsŸ”ý‰ŽdhŸ\�Øc¼…kCµ7ÞS’Ù¼õä½6k3.žÉÁs€…ðÉïÕ¦ôe‡Zª>$[‚|îÖâ€T\Fv@×
¦¾£FL‹ºcÖ¿BáÓÉwÊÎðe¾¬º�.3°s3Rë(¸ÁRn,@ª”<zâÃÃÃ	äx—Í�ÉU˜Ü˜«æöNz°*Âcýè=D‡ˆ7[Ó
-Š–e±¹ö®"<So~§â#ÛϹ0†eÐ7DVØÍçgµ„èkŒî'ØÃ<X¨
-´ÇäåU¼ð/<"lìn�ÙdQ÷
-®“®|Ÿ"Á¤‹:3z°jÝ�GÛ!ŒCõŸRÐ2Jy�GÉ·Ïu)'”L]ŠØ¨—äHH:U+þô¶œ¯(Øñ雟épGïxè«{J	V0è
-_©ƒ©A˜[ÌÛªÃ3šÍ?¾ü"—3.=½­ MQ‡o(GèËuËámˆå�­L˜¦MY.|^ÂÏÊyqç³
--Âm¹]ŸŠé£ñùÊ[wÓª0á©Ö±Î$žï› í8L=t?/§þ`%ðHiž@ù
-ªºìIú³ÏÎ$ÿ¥þ08Kpó<ŸÞà3hóešf8™Nf8°iìbÂ/­xN¥|Šýï°|Gÿô?�ájQÖóíê’þ,®º¬îK,ú�˜¾­š2¢*š¸ŠDŧïQúÍFÇoE×Ø%?¿4 ½_ŽÓp·Œµrl->Vw
Ñï­�ø^£Œ¿º,‡ö¬…cN+7‘ P…ÿCz¹½žÐâ}bÚ-ü,ý`׶wñ¢ >`¹RLìPc!âä}bv¼+£`ˆ+ùiXA¸4Æ
Íy/_
ºö¾à÷Œµ`Î9*‹ùšÆ|1
Ö´ýWfàœ–ÁÿùK©_…Ãéá¿_E›¢1 î£�é´�>f«Ûzv]Í–å¶ÜƒŽrFu‹à-Žt’Ùk¢cc¾sLÐ40YVô–W |GX
-Ã?�1>øÿÇ×%&
�·srÜŒ·ÌÉ<‹D!/rÇqÚ?ØÛ%ý?mwendstream
-endobj
-1018 0 obj <<
-/Type /Page
-/Contents 1019 0 R
-/Resources 1017 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1001 0 R
-/Annots [ 1021 0 R ]
->> endobj
-1021 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [417.8476 228.9788 466.5943 241.0384]
-/Subtype /Link
-/A << /S /GoTo /D (sample_configuration) >>
->> endobj
-1020 0 obj <<
-/D [1018 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-1017 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F39 863 0 R /F47 879 0 R /F14 685 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1024 0 obj <<
-/Length 837       
-/Filter /FlateDecode
->>
-stream
-xÚÅWKSÛ0¾ûWx8%+zÙ–Ë)…Жé0”¸½
-g­Vé…³ Œ´QXK`ZyÊÈ
-endobj
-1023 0 obj <<
-/Type /Page
-/Contents 1024 0 R
-/Resources 1022 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1001 0 R
->> endobj
-1025 0 obj <<
-/D [1023 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-1022 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1028 0 obj <<
-/Length 2146      
-/Filter /FlateDecode
->>
-stream
-xÚ¥ÛrÛ¶òÝ_¡É“4	a¼"�>¸‰“¸—4'Ö9/M'‘�ÄT$^ì¨gοŸ],@‰2ݤSkÆ
-ƒÀAv·ÿžìš£S:‰‚”E©H¦”"§”I"0Jùßw(òDÀ$÷Cý³®ô‹}þ¤-:Í™þ¢ÊýN³¬.ŸÐÆL./	Ð;ß©;;5¤ð
-ΙŒ"1óhB6é{‹Wª¶ÓÍÀ�ÃF¤uáè>)/‰Ÿu]^&ñÕnWß{]£ªv­›�]Š
-.©Ô®ýŽÖúËxmÕáM2ûMº“ºú�}Mþö’îøKùI•íHpUÕÝV7W°WÔÕÇmÝvKuXé±äþ˜½¢ÊIMŠM^¾'<ú'\@ðXœ›Š¢Ø&ä‘3‹¨…!n£Ûzw©Ö„㔉0ä÷ƒùuC´õ羸S;]u
-´	²gíW€Ùtn¯8§Ðê¬oŠî`Ù´ÐnÞ¾d4½é¦Ô˜ë6kŠÞðhžmUµqÃŒè6f·®>ø¾Øô�¢‹ˆ��EPöä½ÞíÎ [ÕM\¡HbZÐü—&9A×èÙ8É‹5Â1hq»²ôÖú¨¸gS"U¶ës²ÃiìÍ¡:ÓmkÃdMcFÔTw<3Ò6
-‚!æò&tÏ
-™XDËU7ÚгvW(šL7ÈJ™
-KÖûcâf±$îfˉ&Ägqdd<h< ;‡'ȨÜc>’ᮨl–­÷��L\Ø&¥¨ŽhÊŸzœ†»IEC#Â÷#Ë!$â)IcûIlqر!pRPGÊQŠ
-ð�eÏ¢™˜…¢�“Yéî^ëŠØOŸ–�XøÎèØò	nEȤ/ϽgL	_|qzBHL÷IR9XÞž�ð*bS5«Šæ<\¢}Íû½±üÐ×ÕsêÉô¨>‡îy”>q<ÃÃ5&XHUKטpB7à¬ìÛÎ:§>kÚ
ÉÕöUíê8ÞѲ	ŸÅg@ÀÒ4G¼ìªïêŠpFD¬ÓaëðU‡!b¬ø¨±­¦<	EXÜØ‹álsôgX)¸H=Ð8-°åä1ÍW‡N»ÖSÎßürõÂûåeD+Òiitm¤½S­ê;SÉâdþs
íÞdAµM×âµ;i0"ª*¸cºmê_ÒÇNkÕ…:ŸÔ6*GŽd8[w¹3]©p•'¥úR”}9ÜAxOmŒ™mÁ�ˆ#.,ÃE‡/D!15ñÚ‘¬/©á=¦:×#�x\^@/Ô¹„slÉx¸µ±yŸÙ“Š†£a­“cƒf½3LÇNEÝ9U^µ�q<8
þBo+OѸ-Uæ•yd¡+ûò©Xô7¿Þ.í�“Ø›vçÓ›É�¥I˜UKNÏéÂ&öÑñ°~É
-endobj
-1027 0 obj <<
-/Type /Page
-/Contents 1028 0 R
-/Resources 1026 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1001 0 R
->> endobj
-1029 0 obj <<
-/D [1027 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-158 0 obj <<
-/D [1027 0 R /XYZ 85.0394 479.27 null]
->> endobj
-1030 0 obj <<
-/D [1027 0 R /XYZ 85.0394 444.0186 null]
->> endobj
-162 0 obj <<
-/D [1027 0 R /XYZ 85.0394 287.5734 null]
->> endobj
-1031 0 obj <<
-/D [1027 0 R /XYZ 85.0394 259.9325 null]
->> endobj
-166 0 obj <<
-/D [1027 0 R /XYZ 85.0394 214.4637 null]
->> endobj
-1032 0 obj <<
-/D [1027 0 R /XYZ 85.0394 191.8161 null]
->> endobj
-1026 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R /F21 658 0 R /F47 879 0 R /F48 885 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1035 0 obj <<
-/Length 2336      
-/Filter /FlateDecode
->>
-stream
-xÚ¥]sÛ6òÝ¿BÓ—HsŠ‚—éƒâ8©{M.W«÷Òö�!‰)E*"G×éï» H›¶“ëxÆ‹Åb¿b¢C&2™DIÀ4z²Þ_ðÉÖÞ\™{¤yëåòâÛ×*š$,	e8Ynz´bÆãXL–Ù/SØÀf@�O—7×ofs)d§—ß/Þ/¯~‚©æ€‚‹Wÿ�	!¦‹w—W¯péÕ»¼¾ZÌ¢`ºüù§«›ÙoË.®–ý;®,s/~ù�O2¸Êœ©$Ö“[˜p&’DNö�VLJyHqqsñŸŽ`oÕm•‰àLªPŽEŠ1¡è„…JªN(‚ÉÙ\pΧoÓ²M¼çSšcÚäUio	´T�Ÿ
-‹UæÉKÄ[¥µ™‡V‡ŠëéÛª¦C7—××D¸9æ嶦ƒ‘5œ|J‹<³7µw‚%Zã݈ªÅŠ‡û嚧uÝî
„Ë�—CaÊm³C`^÷îO÷mÑä‡bp·xJôA/Q<11æ€k�nºṉ&ìþÚÚdÀ‘ 	ÕÕ€¥¸¯šÁ-Ñ9Ší¯Ó+ƒß½3
Ç̶h&c±˜)ŽØ¢¨+ËF$Ü¥Ãhú{YÝ–8DâO��;¾ÇY<m	ÖìGU»Ý‘ö­YÄ’©0‰ál{ä~�&1b«Z² ².ä«#R'ÆÀó"%Ø
ÜÓ=±Pá×_—˜í,&Þ­@Î
‹%†²ÍÒ&eÝ:Ûr^¤B¸?û¢÷ÄËêpB1�´Q‡0¸
:«·cИזã¾/+gtÚzòz——¦~Ìwù®3Ð8DC�5(ãT9;
Àz]ÂœÍÂB"ÃÅÀˆÚÎ$íæ™°n]ªcƒ�½
.ózOvU[dþT„Y;²�ˆ:Öôtíñ¯w؈׾^¾ŸA|Ÿ>GqÔõŽF�)ÌaW•†æ¦Y?®ÙéF‘n®ËMuÜ�hÇ?¡oÂÄ	©¿ú/sz6Ó Hœ^}ÎëÆŸ'£ëõ>Ý‚.1èç9C$¼ì â‰r2`<L4aÙsŸ’H˜Ò‘êQB6å½�i+¢×iÜF‹Î
-êÓ(êܵ>WP	s!ã;•†c$$ÕK
9¼ÊËÆÅv_ûÀ²s[;ðX^áÛ2ÿŸK7
-r¥mÓd-Äô—…½!ª>.Ù14 sÚ˜zRu�nýŽ|[¢”"ç'CÖ-—¶ëx>œÉò
-%Øõæ1$¡#ÂR»^Û¶(Nçc¬òMæBBt&ƒû!¹—õ]*tM;^ÝcT?æÈþö_š�ƒ.CEÙ‚µ?��‡öþsmîçå§S°�2<¶|Ö8JÏL��]\™æÖ˜'Ím…›0h·‹¤¨n°>åwfeÇû¶n�þŠV›ª nwžü,5•g¿¾²‚zÊFä|yvnvfÄÉ…�P�„êÿÍľF8ŽÕ:‚©H$OÕ:‚é(öXTãåwk±ë÷ÝÅÈŠÏUÛý“cˆGJö«,ùd•åE½9´×L�Ö*,Ô:æf¯[
øí�”Â{Oí‘(P^üùw«†·çÖ5JèH�•¦'­hé@R5Šmuß6¸D�-ŒP°ÝêþXÓº|ÉXUú¸˜wsàe•¡eÕ \“ºG
€¦%w.Ü#‚í ª1Èßðž†Ù3/)Ó¥ËùC™òN_Œ
Þõ˜u%,P±zº„W�ô%7È5s—Æ,c5Ðe™¨KY=·ÀrŠSdöckj’”óæÁŽžG8)g5
θ͋G+Zîr›[um@äS0€êƒYS"¡„®XsýhJrq2üªf‡Ø´íÄg`€T‹6ÑÕ9˜Âêa€;§jîo~ÃÛE“.Þ�5.ß¹ÑàrÐa€N÷VÐ3‘uÛݳ„�4PCeÚàs¹eÖ}wC@^Žµx«aðdDÐg]^Zåm[ztÀ.h»±æîö#8X]äöçöìÑ>n!p<A„ÚSñt˜DwŒÓ¥“÷¶$­HÅ´ÖáÐ.‡ž3f#ŽÍp¬¾êÚ£ÅpyÚ ûE�¦"ˆ^´©œÁ· ´öV¹pEŽ/!8«âé’ÇöoV8zD(
-œ>$fN;ëÅ	Á‚ðÍÈ=ù d
-endobj
-1034 0 obj <<
-/Type /Page
-/Contents 1035 0 R
-/Resources 1033 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1001 0 R
->> endobj
-1036 0 obj <<
-/D [1034 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-170 0 obj <<
-/D [1034 0 R /XYZ 56.6929 769.5949 null]
->> endobj
-1037 0 obj <<
-/D [1034 0 R /XYZ 56.6929 752.2692 null]
->> endobj
-174 0 obj <<
-/D [1034 0 R /XYZ 56.6929 663.7495 null]
->> endobj
-1038 0 obj <<
-/D [1034 0 R /XYZ 56.6929 633.2462 null]
->> endobj
-178 0 obj <<
-/D [1034 0 R /XYZ 56.6929 587.2939 null]
->> endobj
-1039 0 obj <<
-/D [1034 0 R /XYZ 56.6929 559.4406 null]
->> endobj
-182 0 obj <<
-/D [1034 0 R /XYZ 56.6929 362.928 null]
->> endobj
-1040 0 obj <<
-/D [1034 0 R /XYZ 56.6929 335.0747 null]
->> endobj
-186 0 obj <<
-/D [1034 0 R /XYZ 56.6929 132.2109 null]
->> endobj
-1041 0 obj <<
-/D [1034 0 R /XYZ 56.6929 104.3577 null]
->> endobj
-1033 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F47 879 0 R /F39 863 0 R /F14 685 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1044 0 obj <<
-/Length 2916      
-/Filter /FlateDecode
->>
-stream
-xÚ¥YYsÛÈ~ׯà[¨*žÁ`pÄO²%¯½©õndnR[ë}€HHB–h(YI忧¯ÁEÈvUŠUœ»§»§�oz¡à§©
”É¢E’E�UÚ.6û3µ¸ƒ±δÌYùI«á¬×ë³—oM²È‚,ãÅúv@+
TšêÅzûûòÍ»‹_ÖW×ç«Ðªeœ¯l¬–—ÿ8×Z//>¼¹ºä¡Ë¹òöêâ<‰–ë_¯¯°Ge0/
-bY¹þÛÕoç¬<»Zwü
eÐÊ sŸÏ~ÿC-¶ Ê�g*0Yj�ÐP�βp±?‹¬	ldŒïÙ�}<û{Gp0JKçtbMØ4Lf”š9¥Ø,ˆ
¡R.*–µø’ﻂõ-—¹æ»]ý¸:¶y+3¶es®Óe±iËéz¬�»-WoŠ¿¢fàP²Áþj±2a�†)ï<&+µüO\¹¯]«WøÜó꿯˜ðH°	áõ}é|K}ûTåûrÃ
ÞUFÚšKwÜlŠBD¨«Ý×JQF{/‚²äŸ�…kEò\(¹ò®òndyÎ	…àÂOù†‘ˆ£â˜LÊÂA)g¤…Sá-¹
e2’¤Y‹UÙÀÆQ¼
-u6béÄk»Yßbä„2tzFåZ8˜ºŠ”
-²4´xøAñT°� >_iþsÕ4uãæ](Ì‚0V‰¸«N–:ãzS8WVwÜGÑAÇËõÇ÷?pOg÷PßÃÔüŽ|Z
-!0™mÅw-”•,-Š&ßq£hx»Æ�¿‡Yº|Ëù³û5Ç»8¶è!;îWVuµ"·
-aë˜*h^Åå±ú³ª+^…‰

-hÜD)«ûå¬uå„$[	,<!ÙfÆ2Ëöf-$¡"âD-hžøƒþά¹¹©·OsE+$j.__\"*B~î!
B™ó
-¿…iš�¡>Ñ Q¼Z4�^€|N>”<o�Ý*AÑQ�J–Ûš(C9v=ä»3ê9”4‡ý=ÃÑ3ŒÝHO§gêÆhC!"bC×@³*iE³*!ÍΘ9é9²¨g pƒTŤ¤Èú½ 6TqÔ;&Ö'*îW÷*††HY�ʽ
påÖ7n¹dyq:/5yuGj�³¯‡©NÉZy%kÅJÖ=¸âQbLûsÒ�e©l¨b誚¢bí�WsˆÀ”º~ÿÓÕnQdí ÂC
låHzóŒÎˆD
/½nÿA�b´†£ØŠ)bÇÍ8žè
-Ÿ@”ÂYA±ÝBÆ”%yõÄŠá´cÑÓu…Þ¨~{9ø¿¸
7¤¬3ļ7aײj%ñ!T󘸘 Ë?¯1Þ^üº~'0¨q^Ã8}Žª¶Ü€+n‘Ú
-$,‚ªD\†ß¬3	(‰EŠÇæ6¸ëYŸ”±¶&pr*_‘%Š£oŠëÔŸÿ¦ƒrµ]’Gç¿O-ÛbWøª‘"(yEøgÖ¦*)ïýs‡òCY�ê•<¯èÐq¦3º0ÌÛ4Ì­�¿Qe£9“6–&•UÙ–0±Iw‡˜247»’¼ëK¡ìpŸŸN}Õ–òÓ`mï!Söp¥¾‹ÿÌóùX4²úÜwGÙº�°'Ú4°qœ�í*?ˆø‡¦¤×A
-òÃ#÷{Ã÷{,ˆ§,\®†˜—žúûÝÊjÍ9¡z‡e ,œÁL`"zøÃѲ•T¶ágC"À`L&{¼šà�¶Í1ò1{³`dvžw
uQçI”V)#Ô.Œõ°gª7…lÅÏ)ñòⶥ(¦ðI�j>‰½à'”Nb°ð�7
-endobj
-1043 0 obj <<
-/Type /Page
-/Contents 1044 0 R
-/Resources 1042 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1050 0 R
-/Annots [ 1046 0 R ]
->> endobj
-1046 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [418.3461 669.297 487.0181 681.3566]
-/Subtype /Link
-/A << /S /GoTo /D (dynamic_update_policies) >>
->> endobj
-1045 0 obj <<
-/D [1043 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-190 0 obj <<
-/D [1043 0 R /XYZ 85.0394 648.2128 null]
->> endobj
-1047 0 obj <<
-/D [1043 0 R /XYZ 85.0394 619.5539 null]
->> endobj
-194 0 obj <<
-/D [1043 0 R /XYZ 85.0394 444.3683 null]
->> endobj
-1048 0 obj <<
-/D [1043 0 R /XYZ 85.0394 407.9434 null]
->> endobj
-198 0 obj <<
-/D [1043 0 R /XYZ 85.0394 220.8457 null]
->> endobj
-1049 0 obj <<
-/D [1043 0 R /XYZ 85.0394 183.187 null]
->> endobj
-1042 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F39 863 0 R /F21 658 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1054 0 obj <<
-/Length 3094      
-/Filter /FlateDecode
->>
-stream
-xÚ­Ërã6òî¯Ða«F®Œ<Ìžœ±'™d×Ùµ�=äq DØbE"‘šÏ×o7º
‘�Ij·|P£Ñ
-J$š-RÂUÆÎR‚ŒòóîcïšnÒ½t6¯Ü/B¨ÆU8TpWú½{û
=O…ÖLÊ8…¸”qeS�øIƨXÚÚK
-véÜŠÅ•ëVûzé:’Œ€hå…çÊ#eÜýÐ1
(o'Æ·
-Ž�VÞÕOt€?µ�ë’¸¢HR«ÈÞ5È"(ÛŸY¹=ͼo	ݹž‡!J†ƒˆ4é9¦9<¤¢•À+
gÊã îÔ¹}�ðL<2®w;F}
-Äœæùüëw·×DPŒ…Cñ£[×q׺_æß»}¹ÁA·n7LѯK>lÄ4È¿"Úº	„5/ّͯ\×ñõ#óùx÷q·)놶ÊâVÛvHT¹¾¬™±¥ƒ{^jîojYk°ëf3e«²sÞ®³Â[•w]œ%M•B¬"gY¬'ü	ÂŽ)RÍ$펭13pѺé;‚Kúy<
-¡°ì<Ãw¬¿)`ê¦Âkú0�ègBs¶Õcöùšyô·
-g³y¦ñªm0T=q¯hÎ’ÈÏè¼WÝ”
|ŠÊü
ùj*ŠlŠ&(®a¡ŒéÊeû>ÚH°›8[7'Ä¿§›¸„u
etàÕ—Ã)…Ejcc!¹„þÆ5Pô>úã>߃¯NÔ*Çh,CpŠçlªHd–lSUÓ�k/àâO®™Ø2CI‹P¿r1
Eúvì3T�ø+¶ôûD,Ë
tam’É|l‚p 2Öl8f�ÄAFaøn ihç½N‘®�^ÏÁ
’‹—ÊÄ,Aj_1(*T	**˜€cWô‹å<pÕOx=e•%®�Pñ9¿7@
Ck
`î¤	ÜINHÜ<0˜Ì‚ó{]ðxmUóŸ&öc©´.ß»:(�j"4Éå멲¸Õa)@ýóŽ!jN¬2³I!bKõÓ·7ƨŠD«"„Ã×´å~@K>éÐqÆ°!µ ý¨©ÄŒ' tå•Þž­ŽúÝn]S9>€ëB€X9
-‚Œ—f/Á-�ÉA�jl…ÇÓ¡ñ{�¶3Á�0 )™__ćAïvãw@aÞ¬µOù4vâ‘þ

-a+ÓtlÈ+ð˜~CYˆ|q`õ2¿œ‹ñäL
-üãqÚÑÑ\5áy-ý!Œ(p†÷O'Š›jºg¸Îa¹�lB%¾3“�õv'ã_Œ™)7þ<[eI*äÔå&KÂ¥G÷!tþ="dc‰Ü$ÆdgA2,ÊíPJy1¨Ñs¶Äro�󓢸¢
G¾�Û÷þ™gQ4ËäËþtƒ’Uýˆ«Ý {žÈ±À—%áihçJÞŽ¹°±w
-ScvøÛ»Û7ÿøñzª2„"rU.NÞÓ±£ô•Q÷g;.Å×=˜j¬Zb#÷—Dÿ·¾=âÓô¦yÕÈ_ﻸo9–Q¸=û~·0À¸÷jž§ò²JZ�ˆoC®Ÿ`RÛÄš¢8Ó©€àÛr�ÙíÚ¦ªÁ±¼	ÉÏøòä‰X?,}dzÁ˜³�ƒg—÷L²GÀ›±àO{ÂrÑ#bdõ¯
ç×]`©“ª“s;ýÝJa]“™?¬k@ÂY¡C¸»»÷Í”øT’ËTN¾ïøº?=ö-\ §áqEA<,™ˆûH€ÊnŠ
܈øŒûÒSS)–IøÔð˜
LJwEf€®'ŽÃ�”Ç­^-ªW/
-1ôr5ï7xŸFK97uBf ·õúð–BòR�½FšŽ¯Ã^Gçg‡ºæWœ»;p†n¢¡†=¹ÇY‡ÏÑîÔq—¡û©ª0yààŸÃð›ñË}–.²aŸ…ÃØgá
-endobj
-1053 0 obj <<
-/Type /Page
-/Contents 1054 0 R
-/Resources 1052 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1050 0 R
->> endobj
-1055 0 obj <<
-/D [1053 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-202 0 obj <<
-/D [1053 0 R /XYZ 56.6929 769.5949 null]
->> endobj
-1056 0 obj <<
-/D [1053 0 R /XYZ 56.6929 747.8139 null]
->> endobj
-206 0 obj <<
-/D [1053 0 R /XYZ 56.6929 540.916 null]
->> endobj
-1057 0 obj <<
-/D [1053 0 R /XYZ 56.6929 511.3349 null]
->> endobj
-210 0 obj <<
-/D [1053 0 R /XYZ 56.6929 239.6059 null]
->> endobj
-1058 0 obj <<
-/D [1053 0 R /XYZ 56.6929 207.3747 null]
->> endobj
-1052 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F47 879 0 R /F39 863 0 R /F48 885 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1061 0 obj <<
-/Length 2903      
-/Filter /FlateDecode
->>
-stream
-xÚµYI“«F¾÷¯èx«§Ýˆ¢XÃ1mOûÚl @b‘
-�WýÀ«,0,TøWIá�«῰¯6¢µ_@Æó‘3}<rÕÕ—êw(½*Œ"r⫺{�%3¬,ƒWÕüµÒèÔ&jkööÁ	l…gÞ>‘­Ôš‹7
-lr݈nf„Õ->†�évɆ€™òýæ%[

çGÎB%"ÑøiÆhk�o¬'I¨HdåÊOØQÚøð
-ºˆâ,\ÈüJtâX
 Â?‰œˆl–Ø<¹py+ɈBW™ÄLTKý!A•
-”¢4’°È8³^øÔ<óúTàì_�l”©â×ÈÆ›˜VlDîö3;éÓŸ™ÝÍì÷�…Ñ3sâ¸Lfhœ}Ôl˜"ɾOºj�ç°`	VêÝ>i£“µü3~*Å¬(”`†äPˆ&‚0¡S¨8»»”N⳪žd%&cÊç…º™‰%§SD¢Ç6LÌ|‹æHÎâ�~Nœ0rTn/W–Ƙj†t
-«‘w²‡Ì
-¬¯ñPߣe¸8‘¿‚\DÈg¥¤•žLæçÚ’®YÛQpâCß+¶EÏ"B"A�È�‹
-|ŽÍoÌ7*™$:€O�oõÑš¿FË!»Þ{ce²Ñb•®ýp›Hq«µëCÛmÛºz�÷nQûpë-ÃÍYìJ“{ïL·F×m‰%-à
ê–bßx­
îíZÇ[õÍ_w�3G¯÷ƒ‹Ñà4Åß8S;š`‡ÕNÍÜ�,yà½à¾†eλ§Ü*åÞr\kª“ûü¢Xº¿—@žtÚûú@_$ëË¡ê¦vܯmg÷.îZ^ä¦~/KÜá”7‚Zc&©ù�¯×uI›U·V³“w©®–sW\ùao°m+sãdHžÄö›'ﲚÁa™ŽUOÓ³íÁ²AwÒ›»¦ß‡›´áy¿š÷·{«ÊóþÙèØÁUöÖn˜œDÑî‡ætÿ^*Ñ­q ¶Ó–tV”å] tNÞ­éÜÖÓ)Ç~Ÿ*Òü}Ð×ÔãÔ8qÒLª©°ºœÙô67ºeV�NWãÎïקM“ÛMMû¶5šjÃÓØƬnº®•†£ûª
¿ýR|M¡îý{AŽC›„©pxžóAôY¯~Š.tÅ5éKþ¥ê•ƒ
-þÎÿJbp"dX
-Fd¯ªýa«mVKMtÏ—ïü©×Hͳku·óvøÕ°fÌÞo®ÎQƒ®6¹øÕ0]Îäú²ê,Íûø”™8o¨Ž×ÙÁ›»ö¬æ6©†`¬NY¥Æþ3�÷O§ýß>½wß<¸é
-¹›á�þRÙ—Ð]‹“„g39]æ˜îè£ÖlÎ&5fÔRÿ(Χã`Îß‚j×kÇú¤·¡}¿·±9Òo¬@žž6Át:­QuÀpä;ô£Ã‹èÝ8m5µ�°.§­{ïG½ÅÞm;…ËëH›P4Ø2‡'ñ}}Ú&ÃñíiCnÜûá~X]Ñ‡íª¥g˜¶5»úØœ³enNÇ]±nOâëûzcÞ½õPïöÚ;~È›iØï:ws“N¹ízíÓi™ü Îz
Iñ0]÷;�µ5»Ð�'·}wºòÍ“=îµOïtŽk³biÃZ¾ƒ›½î9JÔèî´q¤Û·Á¤Í]Vj³:«÷&T¡6(3BêôÖ�žSÛ4…� ,.ûù$Þô:V³¡¥Ëut™l¬xÓìÎ.N³Y¶¿ÀÍû—­cYjOóÅ–s¸§ÉhÄÍGŠ8�ä}ÕíÊî¶ûRoþû—\2Mú'ýd_~z\Í0ÌûÇ¢P‡°ìÿ
¶H¦¿ýoÊçHH=(ËÜç%OŸñ—stÎÏ•"$}Õ¼øÛåGÕÿôtúendstream
-endobj
-1060 0 obj <<
-/Type /Page
-/Contents 1061 0 R
-/Resources 1059 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1050 0 R
->> endobj
-1062 0 obj <<
-/D [1060 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-214 0 obj <<
-/D [1060 0 R /XYZ 85.0394 717.5894 null]
->> endobj
-1063 0 obj <<
-/D [1060 0 R /XYZ 85.0394 690.1986 null]
->> endobj
-1059 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1066 0 obj <<
-/Length 2379      
-/Filter /FlateDecode
->>
-stream
-xÚ¥YKsã6¾ûWð°ªÊBð"H:'gÆ“8•õxmMö�É�¡1w(RCRÖz«ö¿o7¤(šv¶jì*£
4�~|hÐ"àð+‚È0“Ê4ˆSÍ".¢`½=ãÁ˜ûùLxžeÏ´sý´:û჊ƒ”¥Fš`µÉJO¬ò?BÍR¶
-F‡ê/Ç’Ý¡ nŽ!‰\°?xRˆ8¥3Õ†ŒÓ°Þ`›„Ý£øº�<´øç¹¥©²h;›ÓlQõìEK#v¡xøïl»+-Me�—ô´�Qˆ�¨t^W4¾ËšÅRó°+ÖûhHÀó‰M]w44RÇk൪€c& G›N¡
85I“`ßWÁQj °Ž¹ü}QªZߪ"š)mä8£8àŒuœ€�œ#p>õÀ¹ßíꦣŽsß4�Ñ݇˜T&’€àÄ3ó›Í¾,ÑÜ„-Ioi"+K"Öû¦Yˆ$´UGœq˜ÛÏœËÊʨ›mK2\Â�ר*ÛZ¢ºÚKÎsØúEY•ÏΗ…”uýu¿kÙ\¼\{Ë
-§;PYÙÖDí[ëïšÁš£ÝlKC�çÞf_=û·½mŠ~úðh½Ñ›E¨¾P¿öãY5Ýe�íº±Ó>Cúm�ÊÇ,U2qʨ!“¤ThÍCæËiÀóJ&½a<¥Æ»m!–êÊù	¨Kø!Šº®In‹YÌEx÷áM+eQ¹Ý�$ÏžVÀ0e3dGÜeã÷0³;œŸ:ˆŠ
r´IÃuY@8-Û"·4Б
��3N6´Ù4xÈ<‘­ûp‡;ú°d[?Y¿åÆ�Ô[Dœ!i`Ëeâð—ú`ŸlƒµƒC0fûî±nŠîÒ';o½+rEÒ‡)P­m@Xë;$�e�åDý‡`(Ì¥ÒzÞu]uYáúdÞd0
9'&+HÈÎÚg糋"Ô^)°u{°
->1tȺ3¢ç='GžÃ
-ç3{œÖ/µZ0)¢t¤mQu3ÊJ,ž†Š‰´Å,Šãð£ÛÔí�n
›¶¤Õ&²÷	P)MxŸPQ2R-ÿPTYóL|eö`Kçgslj:˜Ï`)�ù&
-¿Võ¡"’°Âx©]Û5ƒØ�‚XÈÁç„
-ûŽFGÀÑ! ô‰%d$ªæ7x¤�€ÇZ¿÷ºÆ‚ª³MÑš¢pçL‹�g’ÑÙÕ]&ü{V9)2Ìv»²X»:¿¥ŠÅÁÄFöaŸ×Ô­\!ľ/µ�‡ãÞè@&ÉàDcöíÛÒOm)}í¹7y/Ý]Ç3Ç"înßTx¶ÔÝ�ØZB4Lwìj¿
-c˜,/<+”Ÿ}åI�®0zy'øí†È4H¥Ôb#EˆM4nM†
·K
�R„ßs÷ÝîóíÌÛ¾Q
-Œª	•æ©°ßÛxÐ}´Þ’{ÜÔâX£¬Á¾ÎΧk_©‚ÎýZk§·Š8<	˜x$”{<ÓdóÅ?oîF¯Þ�9^пÓÆÀ7•‹¸‡ë¬èkªK&™xñà1¬ƒÂ,þÅÛ{àú-^JC-˜Ç>1~Wº“Å©;"<Âx<|æ¾^¿‹RÊÿF7u>µÇ›�J3 îðÞƒë|¾vÁZЋ`E5XÔ;(�!Bªñ¢É%Jcî……¯(jð¹&0u]fÀ+x±ÉÆOêpVª+.\”yj_•ÅW{"DO¯RÕ¼!¯ÝÙu�ydÛ¹<"ŠÆbγa|ú<ò5Z¾¯ÂOU@dü˜t–Àçä�“O4è�”%	¥éß>Þ]ÿŒŸ®ð+‹_Å
-tÒ“'--$¤ƒ�Þ:Û­…k"wŸÜTx½ñ¨¡ãà:wá¹™ŠZŠ œí†ÐEôz82CT¼~1ŒCÜB—×Ñ¡h±óþ½×=ÎxKoö¡N¹¸ØÀÏ…H
ML´•‰}q7:ñ‹²v‚µ£3ÍÃT’é(–=>˜
ä>ô/Îz:¼�7® õ9	ñÿ2þ鬊Ó#Ò‰ÂÎ~Gmæ'O’
-?Qù=‘ê#Ïg�Ù¥XíÀÕXu¾ŸõùŠ�¶€$y&zT¼çNª	ÿµwQŵ³»Wdî¡!æÁûî¥ë5”ÓÂ}…×ÝlÆ`DB"zÆ^gÈŒ}Ò]„£Ã™ý�÷eç-ª]
™¢c$È6
-£”òåjÎ$PšÀƒ
-endobj
-1065 0 obj <<
-/Type /Page
-/Contents 1066 0 R
-/Resources 1064 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1050 0 R
-/Annots [ 1069 0 R ]
->> endobj
-1069 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [349.4919 384.4828 408.4801 395.2672]
-/Subtype /Link
-/A << /S /GoTo /D (ipv6addresses) >>
->> endobj
-1067 0 obj <<
-/D [1065 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-218 0 obj <<
-/D [1065 0 R /XYZ 56.6929 594.1106 null]
->> endobj
-1068 0 obj <<
-/D [1065 0 R /XYZ 56.6929 562.6395 null]
->> endobj
-222 0 obj <<
-/D [1065 0 R /XYZ 56.6929 370.2937 null]
->> endobj
-1070 0 obj <<
-/D [1065 0 R /XYZ 56.6929 341.714 null]
->> endobj
-226 0 obj <<
-/D [1065 0 R /XYZ 56.6929 214.6004 null]
->> endobj
-1071 0 obj <<
-/D [1065 0 R /XYZ 56.6929 186.0207 null]
->> endobj
-1064 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R /F62 995 0 R /F21 658 0 R /F47 879 0 R >>
-/XObject << /Im2 984 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1075 0 obj <<
-/Length 1913      
-/Filter /FlateDecode
->>
-stream
-xÚ�X_�Û8ï§È£h\KòßÇöfoÑÅ]±èÎ>]ïA±•‰P[ÊFöäæÛ)JNœqºE€˜¦(Š"©)³M?¶©‹4M¾©š<-2VlÚá]¶y†±_ß± “"-r!àeet[ˆ:-j^m¶×J>=½ûðOÎ6<KË’›§ý¼VYÕi#òfóÔý'ùÇAGuzØò"KŠ‡ÿ>ýFÓò´ª+†Ó2X¢H«&«ý„§ƒ"áOŸ¿<ÕÐã_úù0žþã«r¶
åQ+ËS‘—<h-EZ•™Q¤ìa˲,»è¿¯.ïNòôt‹M“6%/ƒj^§eÕ2ø¡É’“ìô¨­‘}ÿ
-5e"�Ç^·™Ž8ù¢�ª’�R†x½6ßUGôY�—Äpã´#êôÀêd6�&’y^~<È1LQ¦s×sÚéä4­[&�_þ 	MꤕÃÍávK›¢à~;£¥ýKzô¶•=‘­lÚ<Ó‹‘Cð£S'´ªÊ“tÖWA@Æ ¾Ï¿¿”[
«[Ó*¤ªD›Ñ[g»©ÅÝã¨QglípìÕÿôøJ lid<(bÍî˜Ð½Ä;’ÆV9÷þa霸©=ÐDéHfoûÞžý�ý1Ö¤6.ˆšnÍ+�_>þûØ/¯£_­v¸Üσá*qz˜úQe'Gzk¿OGµ{â�Wr¢æ‰ä(Ï꺰C§\
-veÒÖNϬ—ê¼g�¸rÞÊ.ÎèŒÈ¢h¡Á¾¨îý<æBh%�ÒË�Þ:z³á˜èáh�Ó»>HÅôÑhÇ L8[Ú,²j¼œ—�D>Õ/…T¿—T„
¬ñØ€0š&îm´Ù­4DÈÞY¢Bž¼è.ÈÜ&ò0§5¤RP¦†³à÷öÆ'çSʯ†í°ÓF^b ®Æû+ìY‰Óò¸ó†_Ž;oDHàJz+ÞI©!úê`Dñ:™Œ¡£Q�’â™Þ
R-ÅãT!pº 
-M&PÄqíèÙi7jÓŽ4¾§Y�yŸ"A¦͠ì‚d,"û©ì±‰kkÒ;¥)ÏR^Š:”&JÓ×9*—“²,J�ן©IW؃È!6Š‚O
-endobj
-1074 0 obj <<
-/Type /Page
-/Contents 1075 0 R
-/Resources 1073 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1050 0 R
->> endobj
-1076 0 obj <<
-/D [1074 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-230 0 obj <<
-/D [1074 0 R /XYZ 85.0394 769.5949 null]
->> endobj
-1077 0 obj <<
-/D [1074 0 R /XYZ 85.0394 576.7004 null]
->> endobj
-234 0 obj <<
-/D [1074 0 R /XYZ 85.0394 576.7004 null]
->> endobj
-1078 0 obj <<
-/D [1074 0 R /XYZ 85.0394 544.8207 null]
->> endobj
-238 0 obj <<
-/D [1074 0 R /XYZ 85.0394 403.9445 null]
->> endobj
-1079 0 obj <<
-/D [1074 0 R /XYZ 85.0394 368.2811 null]
->> endobj
-1073 0 obj <<
-/Font << /F21 658 0 R /F23 682 0 R /F39 863 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1082 0 obj <<
-/Length 69        
-/Filter /FlateDecode
->>
-stream
-xÚ3T0
-endobj
-1081 0 obj <<
-/Type /Page
-/Contents 1082 0 R
-/Resources 1080 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1050 0 R
->> endobj
-1083 0 obj <<
-/D [1081 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-1080 0 obj <<
-/ProcSet [ /PDF ]
->> endobj
-1086 0 obj <<
-/Length 3113      
-/Filter /FlateDecode
->>
-stream
-xÚÍË’ã¶ñ>_¡K*šªŒ7�ÍiýØd}p{o¶«Â‘8#ÖJ¤,R;ž|}ºÑ
-Waƒš)m%ÂÌ ™æLZEBµL€ap~ƽ¯Wq/¿£ÍïòI:pH^”ïÛÕª}Žòâäv -©YÕ]O½`ùÐV	sø·ëª¨ý’XP»ëÓXu¬,óݤÔ_´ó.>¿Eúï¾û8øoAè…žh!™å^¢óÿíîç_ùd
±âû;Δwfò8
-h\±›f¢š%žfÊÁ¾x燈v œ0“)¥ÌDsͤæEؾr¾:–‘�‚9sÀ/’dÞ9—gv6`œ�QfH„@ê8€Ñ&rf€â
-ñŸ‹S5Ë~ÐhÙx“áÔ1·ÏfNùÔP”yÃííø0^áS#íXð¹ÙV�õïN•� 7Ä£³œªð	ôcV¸}ÅéíXM¯±êa¾Gž£^äânô«‰Í™…z¯ÝfØÅ\mM:ãLÊ!!Þ©ÍÜ:èùjÆŒ³1ÊSÆe
¨-šy»�r@¬ÐƒE¦Dö
å�]U�X¨)˜Ä 7&�>nŸ&Ôùqt61ÀŸÒ|¤hÇx‘žŸªù>#†DRýcõ‚]0¢ôœœ�PW¨8Å6T#ù
-]·
-°Éä¾ešq6ÀBmã%Ħ+
Ö€*È·º¾Ú^¯zÃà: ¼Z÷ž‰YP2îC† œÍÇlLé¿p0$ÒØbü
-�-�\Š_J@…eÏûuåãd~#

ø.
-Hy‰¨Uc
�‹\`e*Y;�
Þ7hfå*óUÌ8ëÏ;xÃ
”èÚÞŠç
ßEž
w¨µzÌsÖµƒëðL;s”=—Í⫬ƒWŽi
}n‹¥÷ñ<¸u­™†šâõn=aœ�Qf¶™CyÇ�´
,„îvÛ_MQØ=Ø#ïrs`X¥<ïŒå+ Ñè$nÅõ€ñ
-׸6VêC®ÏØ?ðÂ
—/P{Ya§u3_íþ)¦m8óÍDváøôFcE9#é1•õ ôq_Ü@
"ÆÙe&º{¨L·_8É#w°QŹÂ��Õò�l"^uŽ+E}ËJ\²¸È 6F›Àó¢]—usÉ”g…·ÅöÕ±,aœ�Q梙„”ÁQyî<ˆ[ÆñÌdˆgRÛéo»{
jNáo×oé¨R›éó²0ü\‡³]çÆ0&u¼|ÐtÅ
Í·?üDãHÆ{Äxˆ�ê÷r=ËùoÒñä/RêŒAIH×`Ç’1¾°¾êz¶ß�#^Áú¬³)6!Îê:R„?îÁ†t 
.õu•0Áj-¢ºö¸±çÔu€½�ºŽQ^P×C*«y½.W×5öï!»¯‹—J Zí¶4R7}õ„ž5Œ.W»�¤Á§ìOÏ	FC_ºjSnËžàm<b+Pv]î6çˆ	ÿb†F¤Â†®áðL¿ËœÊð°Î$¯)¤Ê1ª™×ÊVÆX
-…—×*Y€’ªxToôÙÓÿ
ðv§ÿc”NÿH<“œ�þ¿ƒº†ÄôÃ?>ëØ
3Ã%dG(‰‡.GO=—�áYZèîï§Âß:wwpäÜó~¬‚)!ìDZ•Û¥Â÷K³ž„q6F™Ézäû²‰
첂dT#eµMKwgìa¤i·²‡á¾òËqSÎY„àKæk÷ajf'•‰aÏ[D¼¡EŒP^²ˆ1‰_nJt0‹=3¶píÚ%×¾å\;’é�†ˆQr.Þ.ÜÛ·°”Î�‚CÑQ8±¯£€ÇÑúݼÝ`BªÊtå#H2ŸC‹J„â½¾6ßðn{Ëòs…=7-×õÓ®î_è}hUo©V$àãÙ…˜vôo½ë"º‡*uGØ)pjÁCàÔBàe"µ›
…ÜͶ.ñ¥IEãa¡Ðûð-Í$¯£ã½Vø´¡—4sp4Ù"KÙóðÐÊMŠÉ
-1™0%ÅvQ­êuÝÓ+”7çÓ=}«#d¼�ÌæiõB#$Ûy»?· öÂÈ!�Cº ý�7+p�Ä!Žb
-ÜÑ ¤X*†aج†F›ÝºÚÖs®Àn�~�É€*íÃk¤s¤Yv/Â{+ß*ARth‰¯‡°•ø¿|‚d™þ€²½@)º>~”Þà ùTÑk"7ý[ûœÍÛGO 
-³ÆGZP[ññk(ü[wÔ6-µ]_6zü´ ‘5hÉ�sª\0Á03
-“ã…õ"GÌX€2Á K!§óÝ–(Š¯x¼‡]Ç^ 2Èíc™¨/Öìªn>EXX'»ÃîÅOÃ;"¢Ùmðx¥Z 5=J·[S­  2³¾�ÍAèAøñ¡êŸ«ªÉ²œÈK’dB©
›Êó>”_>u|¶ô&2¶‡œ­Úy¹Š(FiÁ©Ï“�Ã[ã’Ï{¬—=+K�£z©Â�©«Â&±ÂPÙ÷å|qh�
-endobj
-1085 0 obj <<
-/Type /Page
-/Contents 1086 0 R
-/Resources 1084 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1093 0 R
-/Annots [ 1092 0 R ]
->> endobj
-1092 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [356.2946 363.7923 412.5133 376.6291]
-/Subtype /Link
-/A << /S /GoTo /D (address_match_lists) >>
->> endobj
-1087 0 obj <<
-/D [1085 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-242 0 obj <<
-/D [1085 0 R /XYZ 85.0394 769.5949 null]
->> endobj
-1088 0 obj <<
-/D [1085 0 R /XYZ 85.0394 576.7004 null]
->> endobj
-246 0 obj <<
-/D [1085 0 R /XYZ 85.0394 479.565 null]
->> endobj
-1089 0 obj <<
-/D [1085 0 R /XYZ 85.0394 441.8891 null]
->> endobj
-1090 0 obj <<
-/D [1085 0 R /XYZ 85.0394 424.9629 null]
->> endobj
-1091 0 obj <<
-/D [1085 0 R /XYZ 85.0394 413.0077 null]
->> endobj
-1084 0 obj <<
-/Font << /F21 658 0 R /F23 682 0 R /F39 863 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1097 0 obj <<
-/Length 3638      
-/Filter /FlateDecode
->>
-stream
-xÚÍ[Ýsã¶÷_¡>EÎœ`|$Ó‡KâK/M.iâL’Ì…–h›s”¨ˆÔùœ¶ÿ{w
")Jvje¦s“ÁÅb±ûÛÀlBá›(M´ãnbœ$Š25™/ÏèäÞ}yÆâ˜Y;hÖõÙÕÙÅ+a&Ž8Íõäê¦CËj-›\-~šjÂÈ9P ÓÏ¿}óêõ—?~ÿòÜÈéÕëoߜϸ¢ÓW¯¿¾­Ë¯/¿¹|sõü¢ÂM?ÿÛËï®.¿ït$òÙë7_„¨~ùêòûË7Ÿ_žÿrõÕÙåUZLwÁŒ
-\Éog?ýB'X÷Wg”gÕä~PÂœã“å™T‚()DÛSžýpö�D°óÖ:&@)Ñ\‰ÉÌjÂ�V‡§
SP˜66•#Æ(;˜u¦-ÑŒâžPK8ïl‰ël‰‘ÄY31@D.üŽë¡L¬!J8·ö¡p lí¸Hf-ÁY—â>wŽŇ쭫Mƒ^¼‚ŽÝXÆ¡mN�£^®PKìôõwø4�¯z3HCŒ°:~´Ú.¯óÍq¡ˆÕJÅa jÜééÕ]>B‘ƒÚXù(ACœ€ï°¢̖ŲhòEษB'�?ï6çÌN«íí]è~„z�´'3&1œCƒ§÷T23}Ÿ•Û¼í뼬î±i§Œr:›‡u1ÏÊò!üô3åu³)æ�Ù�îí9›Öyh_ÇñëÀÚ<¯k˜9¢}V6çðájU¬nÏg‚êiVãS…‰ªª
‰J›µ
-¯ëj™‡
ó(¾€6§ÓlÕ~Ü䛢~FüLýõã�àÁÂëù]¶É€ïMü	Ÿõ8
-°s�(3ÝÖ¸@lyž�?×e6Ïïªrá	© 
-üx›6búªÚ„îüC¶\—ù‹Hˆ
Œ¼“�”7vl>M”¡¬ã‘n<,¬Qjb©8¸Öòög/ ’¦I	ÅcŽšÂ¶Ž8ºL•d„¶æ
-u>ßnŠ&?bSm}ž
mJœÒ¦(…äØÏ`5Ó„*µ©vÜélªCñˆMuù+‹ºyŠUA¸$Ã`ßBeBM«U;6Ṭ‚V�˜!n5-�F
^J¹ÓI&Q|D4ý#`_6ãxõ?¬Â'„J�–¯!ÕkB|)c|‰ÝËb^•ÕªýÑó‚	F¸šž9å«E0`0›�ËZ;Š¤ŽØPG;OeCm¹áé$Û/ÙðÄhqÔ„”ãà§!{:Z¹ÀRƒbÒu”Ã�j5[å·YS¼GÝÔt*øâïð¶X5ù­Ï£á†õÉ	n¢5!…ÞÅï8ââº#||AC_»‰ƒÈd&�6Ü)$'5L5/·5p�iÖ…›¾Æ4@p˜k>Ï×Mv]"�\‡ºHxµ„´½	½7Û
 ù&ôG(Tv…ò�Âþ¡1¯`½šð£ˆ�|WÌ£rí«:<Ñ+Xg랧&F+p£V�»?ª`JÃ2¦ÛYs·Ò
;qøl�Žg]Šûü1ʉ´ÐÕãð@4À˜%”ÙŽþk;ým[‚6ÖÍ|¡K›v×±û¾(ËÐòµ'xÆÚ´|•
-±ç‹
,݇(!úWi»Q#Ú%ÿº]µø¶?§Ä8Û)õ å‡>a*Hʸ0m0½Èo²m9IF¬LE7²«(ø¸§ð/GKk •
-
-»ͤâ£;.8d®Å}uÐ=?j)κ$G⠈…´|7ó‘=ç�3ÖÏE~Û‚‰×aiƒ•ÄœûôBQá·	;SY…	ôøÆôå¹Ì>ËíÆRð»ï³¢Óÿ\VÛ–ë
¸æÑ´O:B)uƒýÅ ~TìxòeSE-l­0Ï{¢8ë’Ü»”’X𔆻!ÖÉd í1(;H�ñAå2Ù�ß‹Ö6²ØºÏê~hp¬eÞ�¯nöì©Î7ïóÍàóºÉ6MŒ†N`tk@yÊ.MaI*iØ<‹qXµÆô2œáïp€âB™7Ôx±7¾õQ¸ÂyV_ˆ#!C­6ŸŒ`gñ§E²¿�p™½"Ró�®V›rLNU»‚w#Ô±4�˜O£…•ÓwEY]?4xà´OTQ™¾ùæ
-|+qÆÙ>ï2V¾JãNV¾êR<\¾êñ�£Ë,Â-˜ådü%Š�0È' ¬Çઋ–ÁÍK%Z'sYø$E?Ó"\Ü‹a8
-
w "p	?Œ%ì&yŒ?±.&/Â_Z3©Ô9�¹µ
-ÍGXÿ/Õ/oendstream
-endobj
-1096 0 obj <<
-/Type /Page
-/Contents 1097 0 R
-/Resources 1095 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1093 0 R
->> endobj
-1098 0 obj <<
-/D [1096 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-250 0 obj <<
-/D [1096 0 R /XYZ 56.6929 304.8746 null]
->> endobj
-1094 0 obj <<
-/D [1096 0 R /XYZ 56.6929 277.1668 null]
->> endobj
-254 0 obj <<
-/D [1096 0 R /XYZ 56.6929 277.1668 null]
->> endobj
-1099 0 obj <<
-/D [1096 0 R /XYZ 56.6929 249.2319 null]
->> endobj
-258 0 obj <<
-/D [1096 0 R /XYZ 56.6929 169.6708 null]
->> endobj
-1100 0 obj <<
-/D [1096 0 R /XYZ 56.6929 141.5207 null]
->> endobj
-1095 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R /F21 658 0 R /F48 885 0 R /F14 685 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1103 0 obj <<
-/Length 2809      
-/Filter /FlateDecode
->>
-stream
-xÚ­]sÛ6òÝ¿B™{¨œX4@ðóúÔ¸NÏ�Öí%ÎÜÍ4�9Š‚$Ž)R%©8þ÷·‹]€¤DÛ¹kG
-ùÆÓauÌF
ã�Ü–ºš Ÿ³²X�´šå9ùZL6_:ú •oÈ>ŽHd4 ©Ñˆ�€m=ÔÆ�´õås9o[°%•Èù-1ȱ„C/¦tîTÛéfG3ã
/Ä2h
ZkEÉÆqp¡¢Û*õaÃӪΨ+cÚ“vô¯­F‹U% üt¾)>[ÈͯqŠ(\`çB×úB+È*®äõnÏ~¸¢´!f�…¾>®áõÁ\T�ÒU,Œæ¢k²Ïº1‚0àÊ1‡ê£›0²C2Ù¤åÊthÎiDLhÔlDìd
-c
¸2d²I\à€�hªV‹°8�.ƒk5¼ò¢ª»b=UP‡ÝqÌÈô"/Œý`Dí�ƒn&‰…ž
-üÿƒÖ‚ê¨ø¼$QÉØÆó,wEéð4¬IÓ(|済ÄjtDŽª]S„8¢AO˜$ÑKôÆìö&ûLPƒŽPªÿ‘;¢¶
-RQ™útàè™&šBÍõ¡ØeÖ”�çRJò�6
-ÊQX‚’¬¶5,=PÚ3•Õ0é`c«›ÏS%es,ÖêŽÈ Gí;¢‘¦å
-G¨I°>¢»‹+*ýÍ´§÷’Э�†…Mß«šƒ^Ý�¤v'ñÂGá�jú·Ú^S¦Ä–o·

->tÑÏMÚ…±ÂhÊi
-â±?W[ì/Ùn_êÉ6…n{òŽá¥RÚ6Xz¾§.ýà[Ì%éüÕù"ç1POªo'<Z_»ðME�¯Üüò{¡ãU^FŽÀi§ÁÍXRÉþŠ%4›®8ªÎDè“Ü
1lÒCœê‘ü<�=ðŽqp.ëúþ°GKP¦F�I0àÁÆ3¥U¦TN&FÉ—Üí€2“ùǶ|£`&!Wù�
|¯»¥±qGûT°qì%ÒåS¹[GÙ	®kë%pDKæÑ
-¶Ùgª£ä@Ô�CÖò(hF¶±„öô~ê嫯‰\'¸´Õ{f‹üº¯®è°×ô�M
-�µCô
ž“›ãe�V«/¢g
-|EõÏR1¿ªw}½ö
[½/rƒí�GHVƒöê-~Ç…F)åvÍ‘ƒ�–ÈQ‡ÅeÂ׶»bìvØŒA·ßëŒ1Àðú
-Ê`‘žbôè¢Óí>˹3Üe�Ç‚'¢¶(¶ìÃŠJ´†Í¡±:‰c¥Æ>/’ó»óԟ״`(i§áF¶šM“Á�š–€&øà†’±ïh0bÅ&×<Ò25¹°lš\À!;ÍÀ‚Ù!Ë
ÀÕ�oÞRþ|º3h¡--/÷ºqo
-�x�S·BëˆÀ:â�}x’-dh*}Ú(.
PÑÄ1–
^("÷Ú,XñîÌC$¨qÄ1£�ô‚3gOfÕbW4^aŒ–"”g23ø%û«H=_BU4êD./‰îŸæëÍ›©Fço
u\¬yþñöæß43º¶ô°•Á‰Qý3êê¶
á{nûÐä:¾�m¶Ñ/G‡«Þ«MñÃ�Ïy¥!9rkÀ²ÎUR½[?Eà¨GíÿO:ud|paGžPÊÕÂx>øƒx¤ bm»¬éh�O•}òDP÷P$ßfM–wÆçqáò5ÁñÝ´-³Û;9|D%,j7ñå•&Ã3^_ÄP€]ü~fˆ A¤‚ƒ…‰«§+.,D<xñ¸B€ï•.¡2§N>™a^(Z»Ç]ñ‚‹HØŽ<=ˆ
-Š^8r/(8ò¡\«ÀG]Ù³3ð‚_…LZ›ˆh%”äãÇŠŽ‹m0VöîPvžtuv…:ÏiÞiÞW扗ŠwXéÓ[*
•P\Ô•†ðeßS
¼®1ÝñëºO%¦²�	
-endobj
-1102 0 obj <<
-/Type /Page
-/Contents 1103 0 R
-/Resources 1101 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1093 0 R
->> endobj
-1104 0 obj <<
-/D [1102 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-262 0 obj <<
-/D [1102 0 R /XYZ 85.0394 438.8479 null]
->> endobj
-1105 0 obj <<
-/D [1102 0 R /XYZ 85.0394 409.9891 null]
->> endobj
-266 0 obj <<
-/D [1102 0 R /XYZ 85.0394 349.7918 null]
->> endobj
-1106 0 obj <<
-/D [1102 0 R /XYZ 85.0394 323.4555 null]
->> endobj
-270 0 obj <<
-/D [1102 0 R /XYZ 85.0394 249.9022 null]
->> endobj
-1107 0 obj <<
-/D [1102 0 R /XYZ 85.0394 222.3206 null]
->> endobj
-1101 0 obj <<
-/Font << /F37 747 0 R /F14 685 0 R /F23 682 0 R /F21 658 0 R /F39 863 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1111 0 obj <<
-/Length 2453      
-/Filter /FlateDecode
->>
-stream
-xÚÍZëoÛFÿî¿B@?TB¢Í>¹Üö“ë8>—´µ}8ÚGS´E”"U>â:ý;ȕDKN¢+Œ
-©ˆF“›»€WŒp“ÉÍâ×i„(š
<=ûéûˋ]�Î$ŸÞ\þôa6§Oß]þóܶ.®Nß¿?½šÍI,Èôì§?ßœ_Ù©ÈñøáòÃ[;¢ìç	¦WçïίÎ?œ�Ï~¿ùñäü¦—%”—`¦ùóä×ßñd
bÿx‚S±˜<@#¢�¬N¸`HpÆüHqr}òKÏ0˜5KGõG0¢,¢#
-¤lL�B¡ˆÁ”VàÙ«Wó¦},2�Œ«iZ­VYÙ6¶×´IÝÚæCÞ.m«]:Úö¡r‹–I�¤mV»eoÞØïoXà¦HšåkÇN·a�ØnR.ü¦e›—�g[mí“yºênkf½|læÚ ˆ9!H	A�Tyš³9£Ñ´ÈËL[—ÅÓ›eöhÓ¤,«Ö¶o37æ±°Ý$­g$žVMcû«®hóuáˆõÆ›{4ßC;âæôzl™|t´UéEu?¬qŠ¶�f�”cb›ê[g¶ymÛY’.‡QÛZuMk[]ㆬ¦ aLßu’×ú.£~;‰£Òl÷®ª÷¿’lû�&/TÁ%ê—Äf‰æaºÍÛò_³µn¸K¤›Ú€ú›Ø�Ó
˜‡PÃí(³¿Ü#܆bÈƶ~³Ä/|ØàüÚö²�YéUu÷K·¶ÝäáÌS<ŽYÂo¸Þ‘¥—s]góªk¶d3*ÜðC`MŠc©ëëeV¡j·ñ–Xgµ›s>”;x¬:Gaîiv—Õƒgòâþf„Î;blF)âãpd}ÒoF„‰�
-¶Üõw­è9c)ÞT¸‰á
¶Q@XÅoÌÎèýÁ9IÒØo^ºhþê•mxý˾ù›�€†»þ
>@Âý¾ÈÆ’¤`¹z^–$)%øx–„ƒÆI…ùÓ¼ì:¼\Ó¯Ød5 ÎcDU¬ÂdÚ«ÿnQÄ$‰&.B‹È¨èß�‡ˆˆMk„„kc]ätC§Wæ@™^öm:½ØÖì‚%\L.
jt5ù´ çÌ…m#ý 3ðærÅ&o+�qˆéÏCÎFL
-3Ð>÷Èè¢NV«¤~"×Æ(’Šyï£àfçCKÙOºÃ?bz°É“E�Ĥø3ùì
-}›ÕŸTæŒËéõ]æé\ÖKG¡Â•£°¶OêÂ'S±‘ëaØ¢
Ûq9^ßjˆè¦•Y@Ý.“ÖqIJÇ`½Î’Ú¶õI«ÎPèûœU“—÷vî@CfdÅjú>)ÿ@;#Y'þÄgãÄ~n‹*ýc3³7Ýí|`ä’ùÃ2÷�wRwŠÆC…¬^å%,s@a
-LY;fij©uÊ�[h‹»bÌÉ’h‚ÿÔ}AÕìF`	Iž29	õñuÖ¶$’ÉžÏÒ¯xÊhÐ�ì²×hò<#JöîZWEóË¥…s‹Æ#ìAÇv`	0!+Ü´G÷·Y¯_§ôÛÇ
ÝÛmÃc…uAâÁT].Ò‘ÃAÕ¢"æ×µy‘·�3BÈt�
õ|�·mHŽhC)�”ñ
‚H,â�æµ»EvЂŽ®Ùˆ—íÑÙpœc©Ìú?b¬Å‘Œè,’ 7ºø#{<¨¯f�¥¹Ö�QY„Í"Ø
-ô‚Ϊ‡ØÆ =c_e"W�Â7éà–C)œö Æ?Š¹ÉjÔù§
-ë{sšx¹æÂaÐð~k)ŽmN)êìpB	‹$“TvS
‡œEþåÉ¢„]¶ŒøgŽÈ¼Íj0` £Aië†6AG‘ß/ÛùC¦?v¤*ÌýÐ#‹Ä�ôyuƒà±‰Õ½ƒê’wäüT ˜CѵŒ
-
-kJÞãGñŒLG£DKaA"™$ØØ‚Ütí|Óv·Žeé85…~ÞñéOUÿï73è§HöCÈP-/ÖÛ	Té*㶓ÉÈ=Uk�©žåð/j•©xz_T·æM`|–a|·T¿�¡°ÑZéhnj6˜_dwIWl¥Ödwþ½7ÀûCÍ·Çd�6^,ê'œ#*É
Ôv@±�Ò¥%£ìƒé4óqšÕCUŸŽ½ÔæÑ�Íúm3ê¼·±.’&ߧù@¨‹Õ	£PIŠsL …©ÅêmÝAÈXÌ
J~V°3åR=‹§f¹í¿ýp}}~fÛšßeç<®.�y‹)¬�ð�‡h÷âÒ&��yöð¹Jt7Ò,UtO±žçå*
DåXº�š‹¢Aöú2¥é¥{œåX
-{þõÿã]�(‚¸„è’‚ñð§;?Ñ ä�PÇQÁäþ_hD1ŠUÿ,9ö‚@	=z|²b.ªòðQgÆQ^Lô ùéŒÍ"cÒÇÿ­gÑUòèã{á[iÚùÜZ¦ÙïÇ2Å“&„©
-ÐXÓqõvt‡ÒŠ`|çäþ9»Gÿ²Ë÷endstream
-endobj
-1110 0 obj <<
-/Type /Page
-/Contents 1111 0 R
-/Resources 1109 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1093 0 R
->> endobj
-1108 0 obj <<
-/Type /XObject
-/Subtype /Form
-/FormType 1
-/PTEX.FileName (/usr/local/share/db2latex/xsl/figures/warning.pdf)
-/PTEX.PageNumber 1
-/Matrix [1.00000000 0.00000000 0.00000000 1.00000000 0.00000000 0.00000000]
-/BBox [0.00000000 0.00000000 31.00000000 31.00000000]
-/Resources <<
-/ProcSet [ /PDF ]
->>
-/Length 557
-/Filter [/FlateDecode]
->>
-stream
-xÚm”In1EOPw¨u€$ÅIg0²Êľÿ6¤¤êV5oʯÅésÀó�ή¯�ƒÖ×O²Î Ž¢‘ÿ¨#h8Çùø:„5?ùÆ [ÄIÚL’~”F ØPÈùYÌÀ¹�dˆÐzZ8å±Ýƒ²ÙËò‘–Œ€f¾Å(ÌÀ�E#@x˜oL Û¹[ƒ±ñðù
-ä
-6\>RgÈbÏWÖ¹j[†�›
-WŒÏ¢®{6;»²þFÃÇñ÷ø]š¨)Õ/Ô¬Mu;pk;Ì©Ëdh<åE–ñ¬AÏw³ð¬±±Nê¦ó¡Ä½�t•‹ùD„™Â²]°Ä(�‡;�„ ·åŽ°Š­r²ÂÙÄLûˆ
T¥Í¡誋ŠŽt’¹w_=Î]ˆ‹=¦uSä÷—ä"ï±yl±‡µÃ-ËkHsŠöreOÚ³êvg›<7ºt,‡Ýe—;ãÒèЭ/I…B÷&ê(ýê³ö󻉨YÙ¹Ç,çkRÔšÚ'^
m"	^�˜h±�ÎW9AVªy­Â©/f�ýÆ"•œãûFy-Sng	\Çdª¼˜©Æ¥†Í}B©•µŒÎ$âw1.¶&�Øíþ²C¶O–ÃVç X×9g¹E{îÇ<•ãóP)!ÍZÜÅŸLÞª~ÑÔ'¯UâXLµüc“ÅXsЖõÚ¯½˜Ó’~òBL–§èªÆ¹O¦ºNZ�_[Èü.øšŠû*]3QôçÇñ!Ö-žendstream
-endobj
-1112 0 obj <<
-/D [1110 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-274 0 obj <<
-/D [1110 0 R /XYZ 56.6929 426.5656 null]
->> endobj
-1113 0 obj <<
-/D [1110 0 R /XYZ 56.6929 394.7216 null]
->> endobj
-1114 0 obj <<
-/D [1110 0 R /XYZ 56.6929 335.9523 null]
->> endobj
-1115 0 obj <<
-/D [1110 0 R /XYZ 56.6929 323.9972 null]
->> endobj
-1109 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F39 863 0 R /F62 995 0 R /F21 658 0 R >>
-/XObject << /Im3 1108 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1118 0 obj <<
-/Length 2937      
-/Filter /FlateDecode
->>
-stream
-xÚÅZ_sÛ6÷§ÐÛÉ7ÿ	$O®ãäÜiÓ\â>µ�-Ñ6/驸ž»~÷ÛÅ$%Q¶çæFÀb±»Øý-(1áðgW^O2¯™áÂLæ«#>¹†¾·G"Ž™¥A³á¨ï.ŽþöFeϼ•vrq5àåwNL.¿LOÿ~òþâìÃñL>µìxf,Ÿ~wþî5Q<=Nz÷æüíÏNŽ3=½8ÿé‘?œ½9ûpöîôìx&œ0_F&¼9ÿáŒZo?œüøãɇãß.¾?:»èö2ܯà
-7ò¯£_~ã“lûû#Δwfr/œ	ïådu¤�bF+•(Ë£�GÿèzÃÔ1ýå˜q2Q !˜7FniÐxf•TAƒ¸i

-àœOóù’¶÷±ÍÛbUTmÜí:_­ò5îŒâFá“™ÔÌk¡³ÀÀ§Y•¯
-zû7ÎœHÅ<*eÖ‰„3‹uÑ4ŸVy;¿ù´,›6Œ�í&kÿñŠDØÞÈ 3Æ­q݆ä#z]üʹ¬Ê¶¬+¢äÕ‚?7ùu—Q‡wzqSt²ôƒ„gB8ƒ“6ö	ÄUiL3L›iÞ4åuÕÄz4÷«ËzYÎé�´Š­¶ŽÃªøU7u"ÁNƒN©¾­¸›žÇ¥®‹6®S¦FÏû*pªW[‚Ü®Kð‚{zÙ4YJi&�tÛf­¯¢Z·dB’	š(Só„|z2ŸwCN몥å£ñ~À�Ôü•~rúCOÁÂú`‘1¯Àÿqáwu[P
-Ôs“·Ø²AAHÙ;¢0؇Âü%’I
H]mšÈã2Rä9Å‚Èwe{3â2sÌóL<ìœVgqÌeqU“t´Pž'éI‹Š_¥X6ÅÝMA³^
-óÓªŽçB�ÏÄŽY`‰»<Œ�ÞNs¯"�
-Œí–D	/Ëe}W,Fõ�ç ºªqTY]Ó+i„Õå¦\¶³²z¹9…Ð,Ë291V1§´~Jì„`*̲íØùu³’ ¼×ØA	h^±™fl³šu›šAc.ór™ž ¢¼1†éÈòê~Äk¼bJ½æGôàÎhËx`nj80lWņ;¦µÕ“(ŒzþHc-ôÿOt¦`×R‹Çt¦!E
-NîXÕUñç”VÕOÓÙ@˜o¥³”ãžÎ2Í8¬3*B¹Çt¦_3AËzž/qûBq™‚øŠg:“Óó÷_4‘(‰ÉFRsÓÄ�`¹+ª¢½«×Ÿé¥¬Úb}•Ï‹c1Mª.òbY›"Osß@
-}Àt�<OϽé
-clk¿©ÊßãNs¨4¨
ŒZÕfuYDuÖwUjÉ×ëzs»OþS;Ú‰’{¢ín%;Ñè`ñŽhTt^«Ÿâµ_Y¿Üy¼~—pªM–J²N„Ñ(&¹Ú¯á•õ�bæËXô`A™Å½¤Š‡Ìoòª*–±y¤†
-ž±ÂƒžË{¢Ä<hùÒXj�·õº¡þÄa{¡Œb}0‰åÌX¾sTkp¥<êÐf”Ó¬‹	ñ>
-™IS²J>Ÿ·-%<ö†
-5®èÄÂ¥ÂpU›é(dà³SsY§§Ç^bá‡ýÑh­2`J^ì÷:‚Ë˼À«k.Â
­#pÞ²ƒÞ*,„J™™‰Pž�Úg{kÇq6d9r£`=„
¨ºay+6šG¼5ƒS‡¼|9–¥¢"Sí7ÓüìŠÔw_o°ò÷ÉGÓ†[ñkÃÎ<}•ÉGA‚6Î¢82$7‡ÕbŒ4¬X;£†Ü·3²¾½Ì矣µè4‹ÝA½¡øÙWÞÍdI&�À~bDz8Èu_”êõ¸â�5ºSü›„Èù ŒB@R6C ƒ	ðR±HWúët}ð{¹Ú¬†™oÖˆ³„ÆÌœgšk›ÐLXäüjû‚•ª³á¢ƒúbwŒ7j{0"GF‹ºo)ÄÅoCRêõ@Æ‚¢#…Qs0Œæ³ÌN£ÇÀ2Ý8á7Œ¢—¨WÔˆw
-&\÷
h
Häõ�.xø€«Ÿ�
-endobj
-1117 0 obj <<
-/Type /Page
-/Contents 1118 0 R
-/Resources 1116 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1093 0 R
->> endobj
-1119 0 obj <<
-/D [1117 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-278 0 obj <<
-/D [1117 0 R /XYZ 85.0394 769.5949 null]
->> endobj
-1120 0 obj <<
-/D [1117 0 R /XYZ 85.0394 752.4085 null]
->> endobj
-282 0 obj <<
-/D [1117 0 R /XYZ 85.0394 683.64 null]
->> endobj
-1121 0 obj <<
-/D [1117 0 R /XYZ 85.0394 653.5261 null]
->> endobj
-1122 0 obj <<
-/D [1117 0 R /XYZ 85.0394 576.1881 null]
->> endobj
-1123 0 obj <<
-/D [1117 0 R /XYZ 85.0394 564.2329 null]
->> endobj
-286 0 obj <<
-/D [1117 0 R /XYZ 85.0394 417.9499 null]
->> endobj
-1124 0 obj <<
-/D [1117 0 R /XYZ 85.0394 388.7174 null]
->> endobj
-290 0 obj <<
-/D [1117 0 R /XYZ 85.0394 267.384 null]
->> endobj
-976 0 obj <<
-/D [1117 0 R /XYZ 85.0394 235.1866 null]
->> endobj
-1116 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F39 863 0 R /F23 682 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1127 0 obj <<
-/Length 3451      
-/Filter /FlateDecode
->>
-stream
-xÚ­Z_sã¶÷§Ð#=sB
-jz_ŠÙÞçx	
$|R†<ÖéæXàe‚)ÝÅ9–Y
çÁ�í–jÜŽ¡Ï>ýyðÔQáR½-6”þLšÜä>í™ü�CwE½ïòàÏ$3c?=ÕšA˜’ÙOð^Gõ‚È°%
-5ؤéãH"˜°&¹]5Ÿ�AΔ‘�†„
-`²Ñ �_c>:©ê±à’B0¶Ðëu3-pÖî7m9@™
-Q=–ë51oŠ0 OÿÌé1/ù~Ɔ‘
-ˆQFˆäº"’vU†ÏfyS¼!øÜñÌ×MMt�«¢¢¾3à	ê7‘éW쬂ü º\ÔÛY¿ˆXú8tS®†p²·ßX:©äaóºðåš]èZåŸjåc&Ÿ¼w²—Ø›qžfT cÌÒ Rãö†åžŠ×‚¶AjŸ�R4�|zVa\‹/‡RVù,í¿Z�-n_R(€âYeÖ
-+Ô ^PPDO7„r+zá€pœ8n’>ÀŠ^xE~S´£‘Ò¦„®Øáü8XXÇçXGk4�ÎÞ †“[`�sÊ?Kaõ:ZÜ£¯z€ù°H†Ž8@¶Ž­pö‚}qða_®[ŒÓX°Ãûý¥K“šÆfdŸ9e_
o 7–ÿÌf樰|^ËPšÈN=¸ko¨¤Ú]ÚdÔ®lßÖ`Ù¡8d>Eý,qa ëdš�LdÄ\i†!^ ®æ™1àf,ÖF6öDsó*ÃÉœŠ1w
Ûw•¢µAÙÖõ:§:ýpÐÕÚp�]^5eÈ“ÖQ]ýt¼ö†ÂöBË¢B�Ã*éR$¾Pêy¦¥ =>¨x½ÎR¥Ž\j^.Ë6_ãQLo·0²œêi£`ÍÍÁ©±·sj|Ù@ÄÏ—ñÃŽ¦]íC——»¼tØ �çÉÇ‚”2,SJ¼òãîÇ}ÈC\9àº%æ›ü‰…ëñÚ@®… =TǶnšòÁŸsÉ€µ¥IöMèÈ+z_ OR–„á°)Ðoéq@9Is8@‚2ð‰_R
-û
-5º,渻ґq
-Ö
á¢)7ÛõõùA ¢Ê‡´¯â)Š:œ¢œÆ–2¸€þÇ‚”lB¥qMù¢õUUOL»r¿�úW�{ż§H@†õzü鮬f¤¶£JA!ª»Àó|„‚�Uc
-¹{ÐϺB}J.@.€zóbf¯é	’Ö��<%"¾G:›ƒâ6[0kï$HµGŸ¼ô$á—–:@ÙSR•“Ìà©ÐI^ï;‹ÎÒ ( ö/t%cÄ“.Â(IE0²*—«@],éã‚F|Ä•®ï°åºlŸ. NÀ�%ÿðùr(!ÞÑDå›Ò§¤S»e˜6úúa­=Ü¢–G
:âkh4P臡Å`H
º¹¥õ¾�›DñäeCŠU½_Ï©#µÆR:Ø.¿Òz«B‡3+€V²ƒV�¥¿  YƒðõcE�n�åb ™†ÏšÉØÖÁexÑ =r™N‹~áuÓ5ÁÛñØKb<“ÈñÀJÔWù	Ob
-BȤ†µ‡%ãâCÉåS ^Fçc6Š8’ªðÀÙÒ¤ÖÀ�ÇkàxR`8òh&¡¥:“T�ÏÙnþ
²FyFË€Ÿf Ë3nh2­Ž­Waæàò¯9¨‡^ûã
-K¹Îº{}9œ#L™­÷ó ¹»Þñ^úïrÐöXQËñ �´
u`‚¨jQ®>ß�IÄ£$¦“${…$?hûU¬šü&#øÅ‘Sít"ša!x|ƒËà9J0b	V$jä”OjDzÅÎg£;4†U»ì]¥Ã`ÞQoë2²{Ä ¡ÎÙË08gÒì+%BU8�ëßzN%Þ¶[a‡qá¬"µ|�8]ÏŒˆcM²Èg˜ ¯üw
-­qjˆ>û"»‘zG*À‹ëäP�»’x L$ð«Ã½=öl¡^î‡�¡ôÕ”Óü]ž1É{D‚Ø[|É¡âÁÓ¨å"׃CGŽ¦�¦8Ò9öowågŸqðá�Hš(K¾�7Ü#õ(A€OE ÃIuý
-endobj
-1126 0 obj <<
-/Type /Page
-/Contents 1127 0 R
-/Resources 1125 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1093 0 R
-/Annots [ 1129 0 R 1130 0 R 1135 0 R 1136 0 R ]
->> endobj
-1129 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [55.6967 676.8938 256.3816 688.9534]
-/Subtype /Link
-/A << /S /GoTo /D (rndc) >>
->> endobj
-1130 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [268.5158 676.8938 332.4306 688.9534]
-/Subtype /Link
-/A << /S /GoTo /D (admin_tools) >>
->> endobj
-1135 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [378.2799 73.4705 428.5017 85.5301]
-/Subtype /Link
-/A << /S /GoTo /D (tsig) >>
->> endobj
-1136 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [112.234 62.1828 168.4527 73.5749]
-/Subtype /Link
-/A << /S /GoTo /D (controls_statement_definition_and_usage) >>
->> endobj
-1128 0 obj <<
-/D [1126 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-294 0 obj <<
-/D [1126 0 R /XYZ 56.6929 403.8784 null]
->> endobj
-1131 0 obj <<
-/D [1126 0 R /XYZ 56.6929 377.7405 null]
->> endobj
-298 0 obj <<
-/D [1126 0 R /XYZ 56.6929 339.6466 null]
->> endobj
-1132 0 obj <<
-/D [1126 0 R /XYZ 56.6929 308.8302 null]
->> endobj
-302 0 obj <<
-/D [1126 0 R /XYZ 56.6929 236.1221 null]
->> endobj
-1133 0 obj <<
-/D [1126 0 R /XYZ 56.6929 207.0192 null]
->> endobj
-306 0 obj <<
-/D [1126 0 R /XYZ 56.6929 125.1654 null]
->> endobj
-1134 0 obj <<
-/D [1126 0 R /XYZ 56.6929 93.2531 null]
->> endobj
-1125 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F39 863 0 R /F48 885 0 R /F14 685 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1140 0 obj <<
-/Length 2602      
-/Filter /FlateDecode
->>
-stream
-xÚ­]sÛ6òÝ¿B�ôLˆâƒàÇå)M�œ{WçÎqçÒL†– ‰S‰TEÊ:_¯ÿýv±
-Olxwý÷+½¿}óÓOon/?ßýxqu×Ë2”Wp…‚üvñé3Ÿ-@ì/8SE®gG˜p&ŠBζ‰VL'JyÈæâãÅ?{‚ƒU»5¤?­r¦s™(UH�º`©‚%TàÝÚ €*¨"g™à9ÐGœ_Í£ÃQcœ4Êá´]Ù™­©;ÐO¢yYÓ ™Ï{–n­ƒ#a £®ÙdcÌÆá/GH@©©á\®û²«G!‡Ð8òUÝV+2)®™–™ê¡2Ç€T..ãz*Ø…,tô7óØÒ	ãîY¬ÒŒqÍÁ|…`…ÖÒnDk³
-´{Zܯf4¸8J�7œ;Ê9]d⣙;´¡F²äŒ
¢%€>$æ®=Ös\œQsªÄÂöÐv4²ÿs2;˜–n™\	Öß``��‘Æ3År.Aá’3ÎÁòGQAOíÌ}l£#H	ñ'Mg™°,'/	€’yž‡Ã_ÜSŒ‡$­²Æ¬IÍ’B'§“‘Åjò"gX$Å+4i
žÑ60’YôkÝk–-ý“q
D†AÕåÖØ�2ªRI+‹f[Vn?bÑèPW¿Ìæ‘f¦ê®Z>VõŠ6�BDÖ5etݘ\÷žº¶½>
v(„ûË×.Qi^x÷3û³y)Xƒ��ànãEˆyÙ‡†ý¥È#2¶Ž4Pž¢wëÒAÜ©m†QöU«>p«ní÷V.HyYõç‘R}ˆ[,ˆ—ÖáoËn¾vÁDOeáuEĦ"–óŒXÉóxƒÛq0bFU=o¶te€3Ö×僡µ{cj‚õÂÀØ	ë%
Èš``Yì);Qó¬·²¬k³jö@`ëç5Ý?_|kæÄXÇüòón
i¦¼[÷'�9w
-.
-†“Bù
-›°MK0¿Á@éRu�ß•pPðع«@,Q¯&pÕ,UÑ
ÜÕÂí;ìv;s¹Oc(иàb|këm9�·�(ÉX.yÖ«s’ît_7XJíº
RPIB鬞#•OHI™ˆ¥ˆ«’?Ë—Ôé“ÄôŸ%¦ò g�5Ó¾,u~2!'`˜%zBOù$=	ï>^¿‡Ø,ÀH±/Y ƒ*•�ÃÊÐb0šKÝ]âFÙ
-§`ÿf+¶b
eP%§ç< íL°LùÚô–@n~"j¥�ÇÒ>CAà3Ý4d)‘²
-æT*DEñÍ!ËŒ‡ÏC–Ó…ÈOSµ
(Xg:׃°…š¥›-Ä ¨»…ÆÝ„[wuþànÜV>LÖV%T{ÊÆÜáí¢“ØºÐ�…"�ç�”S%„ÿ®à,[§	MäÅ…G$Y_wôÇ,ѤɸÌèP¬ áy. 9E›fµrÍ£�ƒb_Úûr»-÷
ÃÂä–�#ç¤ÞžH
-·ò
-XVø0Jû‰0æë²®ñÕ9˜|¡Šm@Àí¹6¾FiYmú®ÄäŽ#K÷âÕc t8T-†–f'‚Þoqü_ú;Ô›j[Ù›p¸‚FŸCŽêè·ÕÌÙ2ÝpgÎ�Ú>¶ Ïáø˲œWH‡¡cý®naöû¯ Ô‡Íæ$Çë!ḃÄ`1‡öŠšÃâêf¤$8µ«íXîëÞüé
ì4„g»p3)ž—ÍhÛÂÜ!Ç•ëW�.G¨�pýÕ|(âPã¡ãÉøMc^
-ðÔUÞ'ž£2µ("öÇxËígϹ£ËMg¾ûztYO®3ƾ‘{¤@[C�æ�×O„A�IA&}üqðzÜW§D¶nË•	ä•I€·úð} 2Ÿ|<Á$%UqÞ¶‰•ÊM:z{!Ô¾spñhÛr8z(÷•A›Ä	Ö%ˆÕm�»Žâ"Nl
-6Ÿ!.Ý!‚Ü2K°Jо•ÛPÓÞP›øÒÑýsñ ŒË˜ÎòI¼Þ­÷%½q1	¶Í¼¹[ê4‡nwèhmkºu³h_ћߖn¥—ȶì•©a\Ù�'刯zöR‘¥¸o$(Þ¿¡…o÷Ù:Á�è	-NÝ�‰[»¨k	”U0®}åÜ»dàQÆÜ«´×�v•	V
fcæÎn×Í‘xùÍÁó
hÓ¸	U¨¨Ä-Ùקb˜<Ã,|˪`Y2~Ù~¨ms%I¢¦‰•G‘ô<ÅÊ3¨�’<Ð÷
-9‰s.:ØÞì0-tù×îíèÙtïÏå$¬üÒwŸÆý›T²ôÔËŠW϶ù-!bj7ˆIþ]k»€¶H9&ôMWÁm*ú¤Ãûþù{ïécx–›ç2ümHñ”å²È<S(¢Ê¦œ÷†ÏYÿ�~þØendstream
-endobj
-1139 0 obj <<
-/Type /Page
-/Contents 1140 0 R
-/Resources 1138 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1145 0 R
-/Annots [ 1142 0 R ]
->> endobj
-1142 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [103.6195 731.9163 159.8382 743.9759]
-/Subtype /Link
-/A << /S /GoTo /D (controls_statement_definition_and_usage) >>
->> endobj
-1141 0 obj <<
-/D [1139 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-310 0 obj <<
-/D [1139 0 R /XYZ 85.0394 589.1911 null]
->> endobj
-1143 0 obj <<
-/D [1139 0 R /XYZ 85.0394 558.8491 null]
->> endobj
-314 0 obj <<
-/D [1139 0 R /XYZ 85.0394 294.8462 null]
->> endobj
-1144 0 obj <<
-/D [1139 0 R /XYZ 85.0394 261.6947 null]
->> endobj
-1138 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F53 962 0 R /F39 863 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1148 0 obj <<
-/Length 4109      
-/Filter /FlateDecode
->>
-stream
-xÚ­]sã¶ñÝ¿ÂÓ—È3'?zO—Ô—\Ú\Ò«ûÐI2J¢$ö(R)ëœNÿ{w±�”!Ûio<‚X,ö{!y-àO^›$Jr•_§y!Íõrw%®7Ð÷Í•ä1s7h>õÕÝÕ—ouz�Gy¢’ë»õh®,Y&¯ïV?Í’HE70ƒ˜}ýÃû·ï¾ùû‡77i<»{÷Ãû›¹2bööÝ_n©õ͇7ßÿæÃÍ\fFξþöÍ�w·¨+á9¾z÷þOÉéqaÒ·oo?ܾÿúöæ—»ï®nïü^Æû•BãFþuõÓ/âzÛþîJD:ÏÌõ	^D$ó\]ï®b£#kí õÕß®þê'õÚOƒô“"R:Q
*" É£D+í	ßK ‹bv·-i‹ËmÑ4eM/?nEWâfaJ=šR\ÏÌà&{Sóu»¡F{ì÷ÇžÚ›¶ì¨Õ·ÜÛðjí�ž;hÈlÆKÅãã—I*p׸ã×�Ò&&ãq¯iâ‡öÈû*^ªøÈ‹�ƒ4ŒÎšñÜ–»é?Ï©hú¿~Ê#i€!¡eÈ�ßÞ—œ.IG´L’ÙªüYÕT}Õ6Ô½;v=õUͲ>®Jn|×WM1_Öű+©³ß=A»â¡#Øi[Þž»ìºbc鎃ʺ\öå�œ­°ny|a7*e”#ÇT†1™�ó£gÏOD0Kf¸�º|/y<í3³}qè«å±.ôÞ=tÄÐ^˪®ú‡)åììóÞ²!~Ðͪ°L±¢åʃ}kÝŒ=qL±ã)\GÁœd_VU·äYÊ{,Íì]O"GL¶®ìÖÛ=’¼¨k<D
ÇQwˆœÎfuµ«zž
-ò±w§Qª�*òÀ±Ü̵LvÃ<?|zFÆ—"€HI”ņWkŠl< É"ÊsíŸoʦ<–Fv±jÇ+
--¸ŽÏÞ¬¥½´ +I;;=»âÞ-\Ë-kõ€JÔE´–­Ýƒ2Yùãà¤ãœl½†¢Häœ$‰b¡çøý=æ`ó$IRh
!Îê�Å¥ˆéQBR«ÊšÀz¹‚i´zNwÆQœj§9ˆ”¸ñd_ lj+P(›ØCg„­E±üxÜSÿp^ØÓ®JØîAPÀÏK‰4™²š2�*^ÐÙ$¹WØ:áNmÏ קéì­UÔ
-ô>Vìag«Vû¢ÿœy#x™²Äœs
-öˆGÔ0‡–’½­kbe“Iø„èay¨¼hïùŽ®•

-àÑ”'jÀF%M«@ä7Çõ`n˜©¬ó2¬¬˜Uáû6Ä)ˤ™y‘ãªr%'E
-£ii…];^wUôGà
-ò`ÀG*µéúõƺâ[_ŒøSpðã<~–`*ÿÉÅZ»‚ç܃Äa|+’ÙŸ›öÄPN‡W%GÚŸ2=®b'í%ècyhÂIAq€MÓ‘’Ò!'we»@V“T½t–]QÕa­{t/NâøoU€ªíÈz&*{)2Ålÿ%d^¼¥‹‡«²˜(}é<õ>H_=¹¡yÌ*Ð×™0+¸!…	j!ÍÅS(™Œ€ãÛãq¹Í¢¢$‹³çfqnÃò<,àœ\™—¢‚g*ï>tê9úñKgZ÷ûKtò¥“Ôí²¨CQ´L„ú]óÈÿ}3žG}&|ôgš'þLû2Ÿ	Ÿ$4Vf}Êê¢?'>}k§J_€Ò\%óÛ6b£ÐI`®/ÖSKÎéê-r¢ém‡�7à¥;î÷í�s
rFÆÕŒ	b,�Q†Ã­Á´Ù­gßRŽÿ¼²
æÊäƒëö”}Ïü9ùk€Å^Ռ޸V$}­ˆË
-[@Ŧ?Òõ|ß*NR4p¼:/å,½Cy¼ãfkkòÒU'ãIuÒø^TæÔTØ�ÇEÿxdñ�W0ttÁ¡Ë<ZÈHŠL=-Ńϧ]ˆ…L.†ˆ~q¼Æá¯<,Ž=aG&±†›³ÑÏcp¦„™*“M˜« ÐH³<Ÿl$:‡f>) Á†TìóFU8…¥ã—1S<ŽÏ\FRÓlª‘lb‡-ôÌšLõ›„,NŸ¾j¡y¦=Ë_ôJñŽ«p*¦Z–áRà²éQQ
]0ú+bØýÞ›P�¥Q®³lÊÙ6y,Üý�!
.ƒÀëiÈ)W¶BϦ\½¢ò„M³ö` -�y¾!´wÀ}�
W€á0Äy!Ç0ŽR;F½ÌI˜ÎV>/CÉ`ãT.p¶ÝU~©Àþ8ùÓlYh[¨¢$�ÏÌÅ©=Öll’�õ¶SäSsà2¾œM+«{oVèlwaÛÌû^ö”Œ¯Ëvý
-/X†#©X¥ÁäŸÉGžS~–üK<vùøÎ;&z»ò`«_p_ð—g×?aÐøú'~㯢“ 3Ø$¹“ùÌ?›ÞV
9H§M¨3ÕN6:StÓG�jçjkær“™òèaÛÎ�ae
ë¤ênË[¥#áántp
ðh¯EÁg{z_ÂY¿¢°ÎcPúäü«›7Ã:ô
-endobj
-1147 0 obj <<
-/Type /Page
-/Contents 1148 0 R
-/Resources 1146 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1145 0 R
->> endobj
-1149 0 obj <<
-/D [1147 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-318 0 obj <<
-/D [1147 0 R /XYZ 56.6929 769.5949 null]
->> endobj
-1150 0 obj <<
-/D [1147 0 R /XYZ 56.6929 752.0323 null]
->> endobj
-1146 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F47 879 0 R /F39 863 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1153 0 obj <<
-/Length 2579      
-/Filter /FlateDecode
->>
-stream
-xÚÅËrÛFò®¯`ùb¨J„ç�ÇÀ>9Žd+µq²ŠrJR.’¨

-îoúHà»ë›ë»ë�ï®/—\ÅÎ{ÃÜÜþãšVïïÞþøãÛ»Ë?¾y™òË™DFþ¼øí¶(�í.X(3/öðÁBžeb±½ˆbÆ‘”R_ürñÏñÂÉ®9ê“_,U+‘z(¸O€q&RH#À®)d)†./42ÇääX…‰ÈbxñA@R&ÁýFÓ©uÝ>ä5­Ký°[ãRµþ¬-´ÈZ<hÚëõ`_lé÷?º»ä*h¯à3áAÞ”„hî[W͚жmiv]£KZ·+<»2gYðp hw©‚]ÓàYâh*©TELY–Œ
-ú
¶€´®—œóàŠ`«¶£…þw¾}¬õk¹Ì&"g@(ø”¤†Ð‚¨¹\&Ì‘PŸÌ;Ÿ¬
âÎ
¯B†?Õî
-ø$¤«¶}ñÆ`2‡CQf$ÖàY.p)	}é½ù¯7“�›%ãÊàì+´	Ág�^�‹‰ÙÈQø´¶n~-g¸”v§#쌌 ys ÅPmµ]mìÂÙž¨,>äÙóÜ8¨G¦I@V³ÎÍoy|	¨šÉŒ¸§Ç”#„TÑìrØ2|€]¥`G»Â�}5l<ž+Ê.uÁ¨<4ù¶*|AK†œK‹vT^½ë53RèÄ
±þeO{G¢¥Ó7‚�à

-Á‹T�O��9�î¶U£É ÷£›L¢
-cä.Ž¿�úm~˜>2	/Ž
 Ô’(TIÍ•’{ÈI!½&Ž˜þÐá¾@ÏC%™E³AçʦµÝ@éª2JMÁÀvy]øØä+¸×W͘I¦dðR’YýJBòºoé^#Æžž$�
Ðê,v‰@(h“¥߲xÄB¨BÒ™v
-¸gÝv=I¦‰t™$@y4J€&æQ”âÇŸ;ݺDá)î,
¢Q�ÆÁøšùÂ�‡¿ã¶u :d
Àv›�ÖÆÚáw¯kŒ2R%ÁMÕݸ¬£DPùä #*ŒèS9ŒqÄ#‡(L¹šÈ�ˆoì†M
‹÷K.¦¡
-¾\¸�¥	ýœ1G9à‡M#°z°ç€Ë(£jÍã‰2¥H¢�ÞDµìX
->´{ƒ‰èT>-Ãa+*:)#,¶L£º/ºêa7§-(O±_Ñ"f"dèÞÐÒf·^ÐânÒ=ŽøËé
ê§b8¿	üEht®ÿ)BqJ¤æPbÅ;}á¬�±ž!äü6j¾<Îc )Ñ=ƒÕã'›qŸë¦he®·móì^¢á¿ze»�
WX݈9„–s<FOðš~9�îžU^TµÍ6 �9ªðô%U³jϨi›úpJÄ“v~ÌG�˜Q“»Ã¶Õ´m¦yÂÀ_cE"Œ¾,õI+å:?mÑŒ“†c^ §P­9ÝKz.øÛqú<Ÿ&ƒ˜ëÚî_Ƨ
½U†nK ÓNÇýØ�¬È5�}Õê�|™è€
-(/}IaTÛêŒá§ž®V'Ô»–fJ@?äݠ˧î1m×ü¦—ËÕKK“É/¡×½}2uggŠ£¶‡ê—ýój*v]§›á¬!§ŠÉkœÂkœò‰�0QâS!Á !—é™9ö'�€n|vÂðÿ÷ä¯V³«g3ž†™ÄYäl‚HÈO6åghûÞQt6£¯õ£^m‹-yÊ¿§ÀI{�£kÊPô-#™ÌÕ%ÞÉt4®pÉÿ4õJ]
-p�H�ÅïPâyxå‘UÆÝÌi¹ó0é4D(æ"s%4~[jêࣦ™XÛtBP£:øÅih£VÎC‡ùßÅØ=#óTdÎeG�N^+¬D¨�D’ÐtI°)ô\D󘓯íí$pX Äs�„ãXñÙ,.N�ÿÑÈg7vžcMC�Þä×Ûï¯h5þÄ´ÖfÐsüÇ‹ó0SŸFÜÅèpXGyf,#•¥ßD¾v™¢Âª
-v�V|\	…º¯³#ï;·‰¦ÿ¨1ß4³±ÆÚ¶ÈI*í@%Gè;6Ã
©αÌÞ¡ÝÑ¢ÑÚ¾c¤	¿Eþ8ìÆÖ0•6iàÉËŒiØñŠí®¦ôÙëhÿWk7©öοM,ñ{$5¡2–ë¯u¨˜='fΘõîc¤°‘e
-e$³SÊÇŽž“þ7½6Òóendstream
-endobj
-1152 0 obj <<
-/Type /Page
-/Contents 1153 0 R
-/Resources 1151 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1145 0 R
-/Annots [ 1155 0 R ]
->> endobj
-1155 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [173.6261 500.8708 242.2981 510.2804]
-/Subtype /Link
-/A << /S /GoTo /D (the_category_phrase) >>
->> endobj
-1154 0 obj <<
-/D [1152 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-1151 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1159 0 obj <<
-/Length 2502      
-/Filter /FlateDecode
->>
-stream
-xÚÍZ_sÛ6÷§Ðô%ÔL„#’ /OnjçÜ9;9W÷Ðk;J„,N(RH»ºN¿ûíbAŠ”)É>;3?˜\,Àoÿƒâ#þø(Y{ñHÆ>\Œæ«3wtcθå™4L“.×÷Ó³¿]
-9ŠYzáhºèÈŠ˜E|4MqBæ±1Hp�÷o.¯>üûö|,}gzõñf<ñ×¹¼úç=}¸=¿¾>¿Oxpçý?Î?M/ni(´2¾¿ºù�(1ý; ôöâòâöâæýÅø·é�gÓö,ÝórWàA~?ûå7w”±<s™ˆ£`ô
-쌚©ƒøq—y"ô
-δR.z¾b
rQnzü­vÈ8Áq@1Á6‰m¥´Nî”Ý3Øzï|d
-æ#¸ëü<Ž=§¬ß¤Ä±ó¿npnu~T’ô×ä1ÔÀjû¹�âsoàO³WO°˜»þž�e¹"¦ïºÓ‘üÝ»!'Õ¾Ø8)+%±MÅÿõn¦¾ÕíÔwp¯´ôÀùÅï›ìkÀCà�<¶ê®M�V­CfzN¹Æê8ÁØeñ.¢ŸÚôœìå8­ãq|óxÀ¤ˆ¤�\E
‹=Þ®ÇY
-lC–ç—ÌEa}ëéê�…ÚL0=uC.ÛÇõ
å�9Ö1	ÇÃÈe'*ºþ.·ã¹Rï“,Of9\–Ò«b�:>Ì€¶ ÇTéù&[WYYX®rÑ,œj»V{c”æà
ýa³Jpz;kkW/‹*É
-6ÐuÙa ÚZ%Û&¢X£IS•öíhQWuWÆ®È'j® jÒl¿”çn˜�„X ƒ'ó�·˜tå^1ÿÿÍj6‚µ äê0ï€æ¹ Ë>63ú¢&í¡ ¼ŒaÍ8Úµ
-½ê
-·“°§
P§Ú ‘-�@·=èí6ˆÉÊ>iµ1]£Q­-5tÕËÿ-µgódÞvü°¥ÃzîøZzn"ÊÓE6Ö³-	ÿ¸š½H°
-GMtlï‘`‡úøæqÊОî>SCW‚ÝE[&èW¥9ç´†<ºu‹8~³îæþÜÕæêÕ*1ßå„�}µ—èžàæ–Ã	Âö,âÐ5&`;~5—”‡<Á“L
-ì§Á;S¼`‡
-fºÌ´ýž"Í…¡8t)„0{‡Ò¿y!Å~XšiꀒÐkS³"ÉèK`'Ÿª�)UÞR{7ÛÒÀî«.bfzø›^ã°M[7x—ËcñÜ‹Þ#ž¿s©—yé×�£žÏžŠ£^„?D 8Z¨ê¡Ü|9é÷7–�"(T»¦C9+;{ù–S÷ Qãá	Èx.Ù`¹NÁ/N·[ˆ‰Ù¼¹DÂ9Çàêìã[†ËuYè†'.¸ë3t¿Z“¯uµ`•ñœ$NG^‹’¤&>	Æ%]]ìÿÇ�,5Ÿúßݯ¢|ÉDyÿéñdZ
-endobj
-1158 0 obj <<
-/Type /Page
-/Contents 1159 0 R
-/Resources 1157 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1145 0 R
->> endobj
-1160 0 obj <<
-/D [1158 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-322 0 obj <<
-/D [1158 0 R /XYZ 56.6929 729.6823 null]
->> endobj
-1156 0 obj <<
-/D [1158 0 R /XYZ 56.6929 704.9004 null]
->> endobj
-1161 0 obj <<
-/D [1158 0 R /XYZ 56.6929 387.929 null]
->> endobj
-1162 0 obj <<
-/D [1158 0 R /XYZ 56.6929 375.9738 null]
->> endobj
-1157 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F39 863 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1165 0 obj <<
-/Length 2770      
-/Filter /FlateDecode
->>
-stream
-xÚ¥]oÛFòÝ¿BÀ=�žî'ÉôÉ�•œ‹ÄéÙ.p@´´’ˆR¤*Rv}‡ûï7³³K‘eÅqt—»³3»ó=#³QÿØ(Qa$R9ŠSªˆ©Ñtu�°÷áŒ9˜±w¡~º;{ó^Ä£4L5×£»yWFIÂFw³/Á»^ür7¹9s:<+?]]_ÒJJûÏ×ï¯>üzsqËàîêó5-ßLÞOn&×ï&çc–(ç¹ÃpäÀû«�š}¸¹øôéâæüëÝÏg“»ö-Ý÷²HàCþ<ûò5ÍàÙ?ŸE¡H5z„�(diÊG«3©D¨¤~¥8»=ûW‹°³k�ñOF,d\‰¼‚…)‹“ãt‰FtÝ”)JïÓ3‡RÅ Íx¨…—
-g©0)ÂD5ŠUjÁ…ËŸ[³ÉM�ì
xÑ�ÆÄJÆ@án×fšÏŸˆ§�K³9gI`èÓã°õ²Ú3šß;€¢Z,Œ[kª‰
Ú1(Å-þ‹æ|Üê&Û4Ûõ?à+
dD5/´Û,
M¦YcÕæÉÝ»÷N-C®™p?þ@
Ú3îàó¢ ÜYQWöŠcñP®úW5ev_àËⱟ³`óD_øN{WüØ–…©ë¡ò8ä’'�>ÁÉ�‚ÄbÉ\µnòª$ÜË¹'ÀaSÒ]Y…i"W²:ËÀߢˆ›Ù Ûï–†Ù[Ðïb'¦lü‰{]mG¸ñ§EpwËW¿Ð³ÙŒŽÔn#+gCôãùXè8(·«{Ð*°b�½Hµ=aw,)œ¸;
-­ƒ2[7-2$‚
-Pë#øÇþ¦Áê·àÉyD¾ãéí õÇÇÐü•­Ö…	§ÕŠ°\]Óx
ÿÑì‡ÛÉÐé.é·o‰hüQv@´4Í1¢c"Ú
("J¬5u½ð+]»�I( ‚‚'."ùœtB�*IBq"ZèÜ)sì™åõ:k¦Ë“áâÒ
’7<¨æ4æ%ÈÒ­²`�Mÿ0Öð`«©Üh&µÙ<XC„ùªšmrãŠÒ�FpÜ…©¬·\õcÒÚnVSðPÎ7J³Ë¥×q~'L¯p/P÷ÜãÂŒu³„Ÿ¦J€H$f	OŸžåõííä�ãhé¼ÀÝíÕ‡›jZœA?ÃÚÎ�_LJk…
-­ÔPúÇY+£0QüTV¥4ÜA¦Úò¬€ð4&õ=�Z}`[*u
-_cä1ÆæÚm´šŒ«¼žV%õÅv“aR`Ã_d#
-ÊD:ßj
-³°âWeñtÚ.[x�$¤Möc,
-xk	=ÌŽˆ©#
"0”ð®ò¦±¤v%‘¿¹í»Ûu·‹A/õ½9ï Û^›ÃD—¶?³pö]�-é���&ñþz ›IDpŸ—³š¦Ä
-œí¿lFcF(Ä9v:�k}Ä/x‹¸ê! Ot<eGŠz¦0ÁÀP{)!eczÏ:³)¶—¹HÛ'¶
-�ªÍ…oœ
-ß:®×P€
Áíú¸w`àdêfsžÛ)IÊ…Çê€j«p¶ÊÊ’º^TPq²Êj³Êvz,úν=ºk¹9È+,‡Rn#VÄœ®ÊVWe_WEà—wÚ)„Ë�q{fæ™-ð†¸�3
-­ÂÚNêÚó¸×’lÝ—Ù£ìbí­ù¬$³!Gºi©ØU³ÉßãØÓÿäyýg2m3uJ~Hb!¸
_ËeBõ„´†œ?dE»nÕV¦Ç*	À©õ.ïù>Òå@ÂyBÞ˜fúfc-ëX‘*ÜÌÇOP¥ø›Š½»bù̸Wf4P ÁY5'3Å<Ý+”mžì½Û2Ç,û s›­×¦œí~?ìzÇŠìg­º_E¹ÎÇËDÎÛß)õ,àÒ$eCœt¤êÖéâê�§±Ô¯¢|DÞ‰jñ~—Ä!­µWè·f9þöZ»7Q‘ž'¿çº8؃å�ö~ŠÌWÛ “ÚÿÔsêá9¸bû0’rïÉ™@Qih×¥øÒûgœµ™€ì7 pÏŸËó%ÿ°d�'­UõÇvMË÷Æõ¾Ž4SIU½â®³ÆÍLáÍ£
-û£HÚ%ýä°ŸzGm=÷ê?XØý5‡Ä~D÷·ƒž‡ñ}w)|µdõ�HB•ðxàêÿ5‘Cendstream
-endobj
-1164 0 obj <<
-/Type /Page
-/Contents 1165 0 R
-/Resources 1163 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1145 0 R
-/Annots [ 1169 0 R 1170 0 R ]
->> endobj
-1169 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [519.8432 252.798 539.579 264.8576]
-/Subtype /Link
-/A << /S /GoTo /D (lwresd) >>
->> endobj
-1170 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [84.0431 240.8428 117.8035 252.9024]
-/Subtype /Link
-/A << /S /GoTo /D (lwresd) >>
->> endobj
-1166 0 obj <<
-/D [1164 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-326 0 obj <<
-/D [1164 0 R /XYZ 85.0394 451.0558 null]
->> endobj
-1167 0 obj <<
-/D [1164 0 R /XYZ 85.0394 423.9067 null]
->> endobj
-330 0 obj <<
-/D [1164 0 R /XYZ 85.0394 301.4703 null]
->> endobj
-1168 0 obj <<
-/D [1164 0 R /XYZ 85.0394 271.3564 null]
->> endobj
-1163 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1173 0 obj <<
-/Length 1216      
-/Filter /FlateDecode
->>
-stream
-xÚ¥XKsÛ6¾ëWðh€‚o²99Žœ:Ó8­¢œ�"A	c’`ЖÛô¿@Š”Õš’G£Ás?ì~X,°´-$¶å0ˆ�Ø
-cúÈö­¤˜ k-Ç>Nl3´“@Öûùä—7´bN`ͳVQÙÖ<]\Ð�—
]\¹»¹ýømvuzóÛ/w—ÀñÑÅÍíïS]û8»úüùjv	ìÈ·/®»úc>�é¡À`¼¿½û {b]üèlz3�Mﮧ—÷óO“é¼³¥o¯�\eÈ�ÉâY©4ûÓA7Ž|ëI6´ãرŠ‰ç»Ð÷\·íÉ'_'v€½Ñ�èQþl7pŽèØ–mÃØ÷�
ƒ~×q;mW²‚º(0¤æÚʯR�Rþj\¸V&Ë�‰{;ƒ,à†RMï;�@"–¸ º¶¨X-t•VKո׭¿uñùH×À2§ÜüìäpšÖ¯à-ȳ®ÉÊ}nëÚ;3	BhÆþy§m’%�ò"è»N¼§ÉAÓò!§¤‚²R÷à2Õ•o¯I·Ö€?LJ~ä‡þôD·7Q²ìzq Ô<E�Ñ
ç9{ÒՌզO	+ŠVNŒ’,ÓåÀÁt¹"º$˜ÓüY×NŒ+ÓS4¹ UnærѬ¬å9~4£±’pxŒeКÜ
-VfGV	èA«�r»œüz81‚~J–¥
nh{õÍ!”r–ãÂXÅ-Ðm‘œ·Ð3¥£ì|º×XrQÓrmÎÔýµÒv_zøØÇ‚¶õ¿òƒÕ9©åš€¦ýæ’¦ãRZ“D°ÚĆ
-‹ÍRé0ByGÀi⃕w›¶©O—»µY�©a^×G*®¥7ý€¸Üï‚j	<†»'2š“Ó-H›¢/:P¿ …:;2ÎÑ„Ÿ¹|EÓ3%å~7ÒËËõ™Ú¿Yu6ÁEw>¾dõ²d#
-srÆI/9'	 %^ågœ#þˆsšb1–Ác9còÙ™’þeg‘®ŒËdÃêþèxó
-°’!Umô‘ÎÐ'	©„Œ�•|¤gDV?á:=Ì€”Ç<9£u›©TfLüÓÈ]"f²¬Å)™”YF¦JízmÂ4âÖ—!CÆ�ä
è·5Ü?@½!äž½[ËIåÏ\ËË€ q¶÷3F°´j5NŽ}p}¨òø#	<ê¢7.ØKñd^EÎþK@?qpB™ÇDÄ(¥,ñœš·ß^ªþ/#„¹rendstream
-endobj
-1172 0 obj <<
-/Type /Page
-/Contents 1173 0 R
-/Resources 1171 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1145 0 R
->> endobj
-1174 0 obj <<
-/D [1172 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-334 0 obj <<
-/D [1172 0 R /XYZ 56.6929 769.5949 null]
->> endobj
-1175 0 obj <<
-/D [1172 0 R /XYZ 56.6929 752.2028 null]
->> endobj
-338 0 obj <<
-/D [1172 0 R /XYZ 56.6929 693.9224 null]
->> endobj
-1176 0 obj <<
-/D [1172 0 R /XYZ 56.6929 663.1642 null]
->> endobj
-342 0 obj <<
-/D [1172 0 R /XYZ 56.6929 628.9495 null]
->> endobj
-1177 0 obj <<
-/D [1172 0 R /XYZ 56.6929 601.0964 null]
->> endobj
-1171 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F39 863 0 R /F23 682 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1180 0 obj <<
-/Length 1186      
-/Filter /FlateDecode
->>
-stream
-xÚÕYËrÛ6Ýë+¸´:O’˜¬WN�iœVUWªGC“�Ìš"‚’í4ù÷Bâ[¢lR�Ìt¼òž{îÁp
cé?lØ"*˜a	9ÂÜpç=dÌô»=œ}ò�@õ«÷£ÞÏ×Ô2&1�Ñ´‚eCdÛØyã‹«_/
†}@8º0ap]¼¿¹ý%íéÏÕçÛë›
/û»Ý|¾M»‡ƒëÁpp{5èls¬íI†°Çàúæ·AÚú0¼üôérØ¿}ì
FE,Õx1¢ë@¾ôÆwÈðtØ{RasãI? ˆ… ƼÇ8…œQš÷½?{€•·Ó&ý8µ!·‰Õ$ ¨ˆ‘
–aq
MJèFÁq˜]¸Ò}¡3—*íøq”¶æŽJdœ¶¿¥?*pV²ÖKµˆB%c¼ÖÆ Šµ
-¦Q¬SÕ+òébdÈi²>ªÇCueõ&RùêdÁߎûøòtc¿Š|¬Xz°ˆâ¤NvÝÓu€RDótˆë¯eòÌ—@ÙZ´˜”w'“¦p«ƒ9»çZÀéÚ¡¢eìî,ÍeË_°ÉÚK¾.¯ñ°% %×°Ðb”oPJ_e~*/Š­`Ó‚Ô"¬‘NbÕy%òÌ7ÖõŽÅpæ›íóÍJßUݾeL‡œÚœ­©¨­” d6c”¨V'˜	Ȩ0O(H
-e!¶i½kO­š:EÞ6g�¹«™° 1é0‚)#];SýÔ8f?F¬=ÙCZe�ù?Èž®Ó©möÔÆjî<åHü¹Ôemú&\ÎïeÜbíÚ…ˆ–É1¾´£�_‡èN#qÀ
|æ[Xkˬ–ZÉöö5öJƾd5d\”O­ýWì}©;Ûû4ÀRvä^¨®‹3½ùmgzJ ?xÚ:•Î�ð%ëW�N¹;µÉL:EZضJÜl»Ð±†�EÎUÚÞå;îê
-Ë2›£ñN¡r׸"l­Þ¯ñ¬m)¯l!´aÕªRe‡Q%ˆBB-±ç“€N²VÐÎ +AÌùž3Â×7¥%Cl!óLt‰1³I#Ý¥Ò“vŸ¼oœ�jc”ß�'ç%_ªÜ(ôT¥æ‰“!´š6eQÛ(?nÚXR&ÄÛ,ßž4å<äÁC²¹clœ4*jºTÑ€%Ë·�°�Öê•ï-ëÿyƒ š
å•Ôÿè!	õÞXš¯[µ�n›{³HW�»–­³×sçû©äûy+ãzU‘8îã1ÞÝ@:¡Î6—�ñÊ	öéßt¯N9\_†7Ü‚£¢ =úνü‡Ós߶Iq�Nhå:�"ÚDX9©uŒŒn3/.çw©ÿÏ@wJendstream
-endobj
-1179 0 obj <<
-/Type /Page
-/Contents 1180 0 R
-/Resources 1178 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1182 0 R
->> endobj
-1181 0 obj <<
-/D [1179 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-1178 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1185 0 obj <<
-/Length 1615      
-/Filter /FlateDecode
->>
-stream
-xÚ¥]sÓ8ð=¿"oçÎ`!ùÛÃS�–+s”»žJ§§ØJâÁ±Œ¤ôëà¿ßÊ’;1%	ɃV«Õîj?%“1†?‡ŠR/Çi€BLÂq¶áñÖÞ�ˆ¥q["·Kõz2zyîÇ㥑�'³¯á$!ãI~íDÈC'À
;o>^ž_¼û|uzÎäâãå‰ë…Ø9¿øëÌ@ï®N?|8½:qIçÍŸ§OήÌRdy¼¾¸|k0©~ÂôêìüìêìòÍÙÉÍäýèl²>K÷¼ûú ßF×7xœÃ±ß�0òÓ$ßÃ#’¦Þx9
-B…�ï·˜rôiôÏšagµÙ:h?‚‘çGÞ�
ÓŽ
Œ"¬â0E‘ïù�
¯OÜcgÁ¨PSF•[TŠ‰;Z|µZN™xe&7ú¸ Ó%¥aèu4Ûf4cÇ2�ŠªBª"“p ]Š×¼äóG3ûÏ4Ï“òvIU¶¸-A‚Áÿ¸yõœ2\¨
ío±B2år‘3ÑãÖ`neÍ23·¼~v!ÔÚ¡;üxõŒYJºd®R‡úcIÜ*£ÙâØÍìíé+‹¹Î/òB=†BÏ"ÏjQT®à\ɵ_Iˆâ‡™ôÈä-·NnïµàwE>Ècé‚}[1©ŽÜ­„NâL¸Tº²†|<ö�ñØ"~áªbÉŽó
-mˆH‚Ò4��XÓ´ì2ó�“Nv”ó}.ðÒ@«ÚŒó’Ouþkxs,˜(®ÇÀ™2»A²Ü@ÓG3ê7&2àdQØm[—Ôë®H…•ÓÔzeÌx&µÚ^ß3º¨úQäP=Ĥ‚¶í|%¨±®^Ó˜’éÇD˜:3ƒTÈ8’8ÌlÔÊi4Å€a£%iJ~mÙ@œl[öðNC𲑵6¢8-yöÕ€÷…¾1i
-Ájp†ÖÀ೬
¯…’6hq„’0Mû¶ÉÙŒ®Jt÷EY¨qWØÜüs´ó¨'(&$‚0÷	
-Á2Å¡þnINcIò¼ä–h@r×{+Øë‹ÖYãú^èÜsñz›™€BM@
%ŽÖ«Áò™U»ÇÖè8pô÷ˆúÓÊ’Vp7¡SÉË•²´úz©kžv±˜íòÚ�R@š(µþ$û8ê»ÓxÐLÂù
$ ýÊ*ƒ¢ÒŒæ,%ð½k‰¸YQMjhsb}\BHs¤”XiŠ6r4ÐVMX‚¶g€%—Ê@�iÀxv�¯T½²KæP²�„˜¡92‰Óû\³Uõñr$VÕ@Ž…>ŠÓij9fº­niÊKÜžSCƒçô¯©
š€Ñõ˜U\@ßZ
-}–C6{	6ÞÔKëhä
¦mÓØSDS7�öß
Cø‘� µE

-endobj
-1184 0 obj <<
-/Type /Page
-/Contents 1185 0 R
-/Resources 1183 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1182 0 R
->> endobj
-1186 0 obj <<
-/D [1184 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-346 0 obj <<
-/D [1184 0 R /XYZ 56.6929 215.7523 null]
->> endobj
-1187 0 obj <<
-/D [1184 0 R /XYZ 56.6929 183.9675 null]
->> endobj
-1183 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F21 658 0 R /F23 682 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1190 0 obj <<
-/Length 3744      
-/Filter /FlateDecode
->>
-stream
-xÚ½]sã¶ñÝ¿Âo¥'�ø"�ÉSrçKœ6—ôΙN'É-Rç$R'Rçs}w±
-¥
[
-
-îæw%Ï2'‚¿�?Áñ3g\A¦eü,Kø«ËtEʵôª31¿	‰\¥…2¢�ºƒc>1g¤Y?ƒxöOM�».À¯8ÿμ …K„D˜ÊÆ‚Ô�5ß3��,s|ž[YæF8F÷�
-u[ÞºþBƒªyDG:#GpŽ9Óf,G öqqŽ&ø�ÉÿZŽP@Œ;.eƒLÃÔ¶ó¹Ì²ìmšÈ�POM4÷Æ„_1b¥>ÃOyžûh哾8e²›È’“¿ôòžÇHàlÄPêx
*r1bÄXç#FÀ:Šz�7›DÉˤ=ÒiqšB‰1m08¸˜7”ÛÔsñC½Ùlmži4yD¡¬A2ø·½\qÒk€ùð@ÐØ,8¹´žF6nXr½§fójn¢°¡.3`#­:ùf oR×­t&ͱîSê?™ô10á‡IjðÝ°n¤F™:@­Ú
¤|ظ‘•	Ìlº²rÿ	_ñØÚÊ
}qƒP'*­(½Ú:÷/Tš>©‹B„
-í;@¨W¬êÏÕ+Xyݹ×ά
-Ϥ:�¶Gš¡=�„r�OˆS–+òQ™årx~Úñ�®
-�¸Š~òRUåh»wô|¢TFMÛû�–”ùFH•{ö‘:“/ Zjƒ;NÛömµtf	\Ug�Êy”$£­®&úµ¦[Õ«ò°‚Ú�&
Ö§0SÄ¥ßtƒ¡”MEVä×R©*„ú3�8ž­õ|n¾¸ˆ?IMʘ;!YÊQr
Íëb:+0@×R° °sV‚>^©—¬$º`%Ë&<õ¶Ê¡
s^öçÌ%—àÅ�¹ÌEÀšacd0`'¹f|ֱ̌ÁhC£}�¡ÍÑ`b`0
-MèzÃBÀÈEk“l Tï	6�W ãÊÄV`àfÆê4OµÙ®µºÔ)Ï\†¯lrì$7s:
-·ËÎs°™&'°m÷ÎÚ©€ÌUä/eà1Öy;
X¶dnªsÖ	ºÀ ]¤°fˆ�+\¨UY>&~?ß4¤hV×1šé¹hV�û–ƒkeºŽÜ²îàî�ïlbÉVØn‚� †…(&
DäÙ‘\Pe×h=Ue™™ÌÝûÜW¾¼ÝQfÒ°û\î_íí+ÒwØ„—‹Yz<s	¸ñÎÙß”KI_«
-Ÿ"ò¿øaŒÃ
-ˆÞzêçËcH&Ñ»´áÒ` |Ï@¶g’I×ãÛvŸAi@ˆKÞuƒ›³{:Ócϲ´(„wEgÇUZpæ‘ì9|²¤;P<!ikÌŒÇN&¸×AS€À™ÁŸv­ºã©—tù ÏSiðˆqÔÎö	]Ý.7]ïà/éªîðà£Ø§ ?ë7y‘C
›¿Ð뎱ÎûÍ€esV<ýÃ:ýœ÷”*…Àž_æ `Í°0=¼b‚ó*òžøËj5<‡–xŒ£ŸPÞ€Õ±‚‡±+FóŸØ;ß7u˜ §¡’Òo%þˆ7Ïrµ5	ˆ@¶ŠðGš��-aRYĹKåž}çSžÙÊ‚e�ôA©äÛ†¡¤5ß˃TZþª
-=Êo.ñ¤Áïå¢x)qçB`‚ñ’bGXÛc�³š³šÍÓ,ƒ�»ÈBÀšáaܛˡ<ÊÕ˜	JÀOD‰
zF{ôî[÷
-7BªÜÓV¸€zèç×{’2Sc'}„Ä'9—ØJ™†Àš˜cGyE¯�·ÅwÇé‰áþCFéI.Îh"HšáˆXÏqµ”€¨áãAKD51mjáÜø~
-�üúæ—W÷¯¡–A¦rØ>�3ð¥C¦#�õ»-2ø §·uóÙåd!ŸÑ6;Ð7ï>Ы.úe·q´öeèÍ/1WÓ2(>;ÌÙØAD‘¤W”°wxè˜áºÇñÂ
-‡‘‹ªþÜ,Oã"ìc"¿L>`ÍÐg|f¥3`µ�̆èîÙÒýFG‰ÏÚ7vÏ@ùâóÁ!Ruh!#|3.а_r;ý*>wûf[î›�Ó
[�Ã
lЇÛ×.åÓ�›M+Ãn‡gd ÌöÒãIX®Ñx@=zzÚs);sjûÒ:V{Hf¼EfÑE½,º¨—ù‹z™-ck‡l/é¡9*ãïP!æÎ}XøûÅœBÛÈ‹X,ÜðÃÀk•
ÆX©Ì:æS€0ú°ì¯§uc˨°Fy<$Ã_ñFúët™K	,ùÆ1⟥g
É~íN胈cŸÍž\Ø„ÎhÉ<¶á6¶l܈Ò%^ø“¼"
-Ë0^ãîáì–µþ².ý`ëVQÐB›\Cq’e¾
Ü£o¼Ïåæà(ͦ9BPQjå»0°?¯Ü%‚™4G§Rú¬Ëíi,S©‘r’Å¡è€>ÈŒö•Kã¥
£ñí„P›¶ê¶£Îß«HéúçýüÅ8Ž¡Žç£K‘ß™,£ÈR®ë„
Ô†ò£­Þ`X»‹žË�~WR‹22ƒ-¬|RŽ7m34Þñ.»wéñ@šE@w¸‹ž}{º®õ~8ìœ7o¶á6g5NäÀN»ãIyÔ¢î=ÞljÝÇ		‰ÎTþ¡Ë™âõæÿnOÿç[ÔÇ+æxoPë3EŽÈòTsSx¦P¨RM9WB§Jób†õŸ¶›‰endstream
-endobj
-1189 0 obj <<
-/Type /Page
-/Contents 1190 0 R
-/Resources 1188 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1182 0 R
-/Annots [ 1192 0 R ]
->> endobj
-1192 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [250.9056 208.6872 324.559 218.0968]
-/Subtype /Link
-/A << /S /GoTo /D (statsfile) >>
->> endobj
-1191 0 obj <<
-/D [1189 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-1188 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F47 879 0 R /F39 863 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1196 0 obj <<
-/Length 3362      
-/Filter /FlateDecode
->>
-stream
-xÚ¥]sÛÈíÝ¿ÂsOòLÄrÉår9yrbçêëÅnm§íÍÝ=PâJâ„"u"e'×é/°À®H™’“i2c‚K‹Å7@‰óþ‹óD*‹²ó4“AŠä|¾>Ï—ðìÇ3Á8S‡4íc½{<ûˇ8=Ï‚LEêüqÑ£¥ƒPkqþXü:QA\
-Bë¾nA¿…IxIÍ––.á,Z}.«ŠÖgLȬËÎSš™¼'ô„6°Ó±²°‹eÍÛ:^ò¢(§('ÔN�Å)
-@€r:NW6u^‘1µfŽ·tÓ,èšÓå��Ù~%�˜h7MÝ0×X„“G»<+Ì"ßUÝ”-]놺†®"±°üã5“fi
„Òº½»½Fñ/Œ›-He*FŸ6³>Öq3óX(•mÓtÓÂTf™£D¦M]}}alID±ˆOsá±FØ[’‘ˆÔ��Ç‹,œì¶ ’XƒJìU€
ˆIÍÆ07kSw´Ž*C¼CÆíbÉD¾j	EÜ5Z®Ì“©øõf�—uK†‰y]ÐvG
ÙSJÄÞž(þÙÔ†Õþ\v+§_¶©MßÜÌ—yµ+Xßè3VÏ 6ˆ‹W3"xÛtŒÒ6k†è–²÷ˆ¾�íÀûZ)8³2Á’Íö·(’W×ø÷
?ðç‹,šüó`ñÓþu§)ö>~z¸þô!o©�-²žfá<q„R’Ñ€}†“ÿØË4ÐQ˜sÔíK^nDÁ^~(Ìo¬ž<¸k=¸Þµf·v·ÿ}Ë1a¸5‰œŽ9\’bHÒÓ×Ç:îp·,Ê6ŸUfšWËfv³n_¸›Œ©Âä4k„‰�»ÁÁ¥zÈÅq
ÚU’C¨Šû‘žž\Ý><\¿§‡=†í³¼ã«5@˜™ªy~�b�¯m(…rà#„O±Uh	|cS²²�T…
-„„¤žç�´¢D»WÚ.ïl,󬼂C˜‚ÝæλSçâþºiÙ÷üÙæ.
-Tìï3Gl³©J$vÌÈbL·ê•â¡�uÂÈ–•JÝBŠ›VMó9oËâeùË 
3}š�5ÂÂÀÄâxbÈÿVƒ’Ò�m»7#Š”*€RË+r„åC5†�Òšñ)³6O€ÚÒ6ltzò”We‘w¶ö€[ŽÎ
-œŒ‘J6¦’­bV?Ð3�’…iFBL¬ý	ÛಷÙW¸Vžn{ÄlS[™´åº¬ò­-Ù�|sàÏ9?qï?—SÑ*áF¬Ù‡mÇ€m%ï!"
w0òµ)†µ»‹â{û9È!ÁiôZ ïcä«çTk4Ç™™¼Û¾Œæ	Ò@æ4k„�A4W2HÒ42ò€Qc�>¥“Ui¶”5ç
-MöIÎ$¨‚íaØ£¹D9+YÖV+»ÎÀ
-_†žO54áéAhÓµHê~
-�B^K@_ÍX± Rh#ÝRdÿtD–X‡.$EˆJV„òùÜl:†ëöÙl[ºA·Ä+Pr¨î¸"S½ãÔc�²%q ³ÌEкãŸepŒ®»àŠp/¸Z‘FÔ—¡:(ɨ¢AßÎ$ÕJe½Ä»x²°¡–¡£êéÒ":A žõuXœ¹‡Vb¶äJ¥ ñ¥#"ú$0Y¢92»º0Ì@>’«ãÂÖ:ôÃÝK&8ó"„s�T¡"Ð*‘ßU¼$!x½ÀÒ¯ç]ùd‚‘­¦"GÔz—Qf~‡µ0¨/„>ç]ÓTƵŸwÜz	Wqœa¿ÒÜô±Ž‡+�eÍc×­¦õÖÔ‹™|”‰'·÷X#û‹N
öÉ!£^“i,³ïsú8ì4q¨]ÅpXÀBE(SÁ/]^ŽÑÕA¢„C™¹œì+·
-Ã6'áf
j·ÿ¾ºûxysÛÏ|4‹j™AóäªC—ô9�bͽ}2[¿—;"ˆR}Ð~S$ÖZà\ú+ß�*±£‚*9'ËœJˆ¾4ÿ‚çûù—Ö¼Ã�ØDåT'êÛƒÕ['m›–awÍé2_åõÒЖªÿ×ô„§È
-
-É0=½­CÙ¶o
™@zb¸í±¡×Ý'í•H"ô%RÆâCDí"i*·S£ÐŠè�›ãZKK�ñÞÕzýàâØÙÚ–{™q·P%-¸\Ä`Lñ­u¤i�.W˜5Ú…5±$N441ÖÈ4N’IUÖŸ1cèÈ鸊}¡l•@—I;î–«Ž¸÷q$€W`q�(<óÂw C,Ë„­
g–íÖCbQ¦;KP;/>²m<+JK?– °ên¬£3Œ3GEÄÂÖ�Ü°dKL¸’tíŠýÜbÑm.àüM=‡=¶Ü«
-@ßÃ:¦ƒÐ
-ÝC"�op`‰&«fc;Êüp[ì¶ûÜ×5Ës8§�r�b™÷¼j9ˆ¶»
ñ‚zØU™†ª#=h$öŸ8Üç7Äüø`ö›X{š ¶¼g�¯}�i¥T¤©þöâ„[Í(M œŒ#÷í†3Ñè¤:ƒj]g~RíbäÁ6qh™¹ÎÀ‡þLs1�Ñ€$K¶]€ëp°6Çqða%Ñ�@c·ÉSižG8‰’@„:éÙÇè¡tìË«ŸBPè0}1pCjr¼º‘
°?Ï[>™­Ž2íRàùk
”TX*¾ñø·o?˪™yóﳞ…T¦ß �Xé¡>Xù"D](ßÎÈtÂá
-ÿðÀ}Ýñ…�·Þ¬_¬ƒôiÜ%³=Þ>�åºbq_|5uÝÿ]�+N]g?ŒP¾pñ�TÞö[ƒÃÜçüœÂûµöû¸eÅ
f{Þ¨€iªÊUųѴ…Vœ†‘�‹ŠaÄIÂ@(õj¨ˆ“ÔÍH0†M�Ò“Y%Þ7]¬Í`©õð;¹íì”ËM
-}Š ífû·0Ûª„p@Ó9 ÂüaO
óÛÁ´¼ÜU9¿…_Ê÷œa-eñºâ“?´+úÅ˜Žé}Á{®Ø’Uj¥B£Wåf£
-endobj
-1195 0 obj <<
-/Type /Page
-/Contents 1196 0 R
-/Resources 1194 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1182 0 R
->> endobj
-1197 0 obj <<
-/D [1195 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-350 0 obj <<
-/D [1195 0 R /XYZ 56.6929 387.6589 null]
->> endobj
-1005 0 obj <<
-/D [1195 0 R /XYZ 56.6929 362.5676 null]
->> endobj
-1194 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R /F48 885 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1200 0 obj <<
-/Length 3390      
-/Filter /FlateDecode
->>
-stream
-xÚÍ]sã¶ñÝ¿Bo•gŽ>Iàñrñ]�éùŸ3�4ÍO¢,62鈔}î¯ï. H‘’®i:½ñx´\,€Åb¿I1ãð'fÖ0®œžeN3Ã…™-.øìÆÞ]ˆ@“D¢¤OõíÝÅ7oU6sÌ¥2�Ý­zkYÆ­³»åÏó7~ý×»«ÛËD>OÙebR>ÿöúæ;Â8úyóáæíõ»o__fz~wýá†Ð·Wo¯n¯nÞ\]&Â
óeXáÈ„·×¹"èÝíë÷ï_ß^þr÷ýÅÕ]w–þyWx�ß.~þ…Ï–pìï/8SΚÙ3<p&œ“³‡m3Z©ˆÙ\|¼ø¡[°7ê§NÉÏ(ËŒ•Ù„
-ã†îæ÷ÍŠŒð½6å€æqX+€qÆp©¤;T’º”¥ÚsfÒ2™Á:çdœ(õe™ov�$½‡z‰¦eµ9-iÅ…"EJP“ŽP‰Le#ª½Këßx`¦$7³þ	þ;© üµÈôÿFÐV³Ô)µ´˜tj=à‚;�°
-

-«çK§á¶¼äa¬~l˺¢Ñ¢ÂraIMù°Ûä-]<ûÊ©êOM½)ü½ú»›�Ð!=EûòF¯øñêöRÙŸ.…p
~ÌÜ…Y1´ÄA‘XAå¿
uLk˜Þzþ92YWGïVƒ1hËõé»íS¿ÛŽÊßmÑ.ÖÉýfWŒ¯–ÃÔÔžÞ»£šØ|pµÊ€áõO‚»ßÑ
¦vƒi6ïpáŽ@à*U¤€‚ÈNö0 öÔVÅFï€IÊù‘*|e°cäç,ò]ã5ö �
®(•ý]"²¦ß¼m‹‡Ç–"ÒïH*
hf•êñ"�
SSï<°`µÿÅ.
-ñOË
'ó7®”
-Í0YhþPD%Å�âsÙ64´Ü„ºU”O^9pìãõ»»«Û÷¯ˆ œ�†ê°Ò²;`€ëSy%‡‚Rm9låÕK˜Eµì"%Ê� çmÙ
Z¶à ?
jßN—Æ1Ó÷GT·üü…:a¡0ÖbŸ_MTãA«Ï„ZÈe˜æ©;­^}ªãúÕQùÞ\§Ø,“Ŧ,ªv”îApdS�“tTkR8­CȘU–v>áç< ËK1¯À9Mj}·ñ�›â
˜ö�nD„™dÊaÜÖ<½]$‰kÞWuç!ñ	6y9œî@[Rkçw—T“tOgŒLÈûî(tÜ÷-Q`³³Z¡ÁZt)=ƒË›P6HߵË9P±Š=%t¯´žP±Œ9%㚘Êp9o‹VëC–Ûç:¶ƒómÞ4Ýˤuh컊¨¿ù®]'Õçeý�—S
a-'‡â›f[Bå';»ëº¾ÃíDÑ,FÑíj!·	&RbJX²}Ò5ˆßÄ.r	‘­È—Ç�RÂNžñù}ªF©ü½×M›4-dhM[.ÆF©ÁŒlªO3ÐQMp04JtòY6dÁç>Fôâ¢O‚�ˆI0@”ø†ÐøkQ<·+(žÃoïžhUoÃÔ'J{
ÄË¡ð¾ÅGa1a©˜

ì_#ä²°IɸÙÁÛ’²]oˤ�Ëðˆjý�Þ6ä'øêàLFܧ:~ÛrŠ¶ÒÂR~¦Vvò)oÆÙ1˜ºKõi6"ј
�
<‚‚ÜØð“*½Ï�
&œÚ×/¹¬e&㮋aP?‹ùuKó½G d¸¸dX:J
-,ÚÃ'´ð¸„}¶%…n�É&(Ä–rúi·yÕ€
-€ßîXÝÔ÷¤ÂHäHh„çDPUŸADúÀuµ x€Úá“U@þ�’Í1ð9î¸62íÏq%
-V‹!׫	á9È9múaÝöºÉÐqzc0±Bètl[&TW
‘kz^V(7šA¯øõ
ãšèH{Ëå»ð.ßiûî WÑ®kHÊqeHõ©SbX2b)A%£±dl¨|´ˆ‹[„&ø·]¹¯�ßxìÞÛzšMqï;!^õ•
³Âg_çõ@Vø†ŒMÙä¾}È_ºPC�»§®ÓWÄúd»Â^_µˆ–º: —üÌÙre 8ìAq£ÿ€šC€_ÙÓfק:nv•7;8B	‘8Yø
-réSNšÓtT›¦LeÊY7æz�<€)B¸4Æ*@•a(¸z€,‘x]‡Ç|³ñ­é'd¿ž*ä/€�ô±‡b:1å››×ï¯ÈX JÒø.i`,cƒ“Š¸“rþTÖÔÏ#´×(@“F
‚Ú�€�„¬Zæa
o]Š£àuÂÕs>Ø(ß<ç/M\c[R†#EµªC7©9Øu$~x;ßu™ã§º]Ó±‡ïÐ|�‚[v¤]»fù’-!Z=‚�ÀÚþ˜"+É2ÇÏô©ûT'9R
ßxôW
-ÈN”Vÿž†·÷3nû÷é“þ„‰{­‹|}Œ]MäM31jÓ)Žß)Ù
7ã>]¤:ÃÃxµ�€ëÔRÐ@6zÆ{!‡Â…qJ½q¸]wCx;
=l ˆó­ (Ãé:J¼Ú?…Õ½Âp5òV”–—N«Çæòç…ÏÉ¡‰íEÝy
„÷mF�ÝÛª-Ñ/x–ƒ©?¼&à½wAô6˨ޘ�Ta¾?<üúâ~»†ºÃì4N�Ò‚|ÓÔÉѯ" —Èt¨)±
-endobj
-1199 0 obj <<
-/Type /Page
-/Contents 1200 0 R
-/Resources 1198 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1182 0 R
-/Annots [ 1204 0 R ]
->> endobj
-1204 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [182.6146 117.0296 231.8861 129.0892]
-/Subtype /Link
-/A << /S /GoTo /D (notify) >>
->> endobj
-1201 0 obj <<
-/D [1199 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-1202 0 obj <<
-/D [1199 0 R /XYZ 85.0394 720.9574 null]
->> endobj
-1203 0 obj <<
-/D [1199 0 R /XYZ 85.0394 709.0022 null]
->> endobj
-1198 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F48 885 0 R /F21 658 0 R /F47 879 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1207 0 obj <<
-/Length 3814      
-/Filter /FlateDecode
->>
-stream
-xÚ­]sÛ6òÝ¿BoGÏD,@$0÷ä&NÎ�‹sç¸s½iû@K”Í	Eª"Õ÷ëo» H‘’Òiã™
-òÛÕÏ¿ŠÙ–ýÕ•5z¶‡"”ÖF³õU¬U¨c¥üHyõùêßÂÞ¬ûtrÿ¤#•D©Þjkõ,Õ6LLá>¾ä¸
-
²jOˆ*ÁÌ{@$¨rJÓinóÅnÛà*ŽÈZ*¥gÉz˜1ÙþñH‡‘‰dïVtŽ±é
ÚPá•ã6l|Ô2
­ŠÀý «pŸ-t°‘Á»ûÏôû·]îκ[<Àš¶!(áÕ3&ΊàQL]§É· Àôɾ(K¦Ô‚”mZvòƒKn3‚’$ûzû…Ž]£9JÍðà=sup5"&´BÁòš½ã
-S)†´i0Û¡ìV
-ýeíä¦Aëøƒ’PgËWšùRÕû#®˜U0ê°¡‘T¨
¸lá×KÞ…÷12Ì-+üÎúÃ+0Ù
-îë–©´/™#‘ÂFµmQ=O˜1pBo‹¶½c
-&�$HiÊH«#ÛQ
-¿êM¾ÍZ2+‘²A³÷8¡Ž"Ä=÷ŸïÞÿ—úÙrɲΓe]ÙmÜ‚¤>ç9Ãa
-öb^,盺.G†Q@Ø R=ë£F5¦§5„Å…È?RšúÝ¥9¤ë4öÔÔeÞN¹ضX'¦Gɉ@Vî³×Æ÷Ëz
yÿôa;tïÞñX/€À¨Á­9é²â8¼t, 3§Â@>Ožc’Y@±hFæß$2=K½“ú+P³>ùyS:ùGó¦Ä§'º—ãè.ljƒE]–ü ˆ_²‹q`€c;‹¡ µœöh·G
áøEh±«J
-f�/R
-ækº¾™‚>y¡ØƒíJ�°…‹‰E÷Ûð*�9ÄØÖmZF<ŽôQiÁU:td¬t¸ÝÖ	X˜i˜C€öiLµ\Ð×HtJºbƶs]ôjã‹BøËP\îÖƒ}Zs¯¦9G@ù(s,a‘ÄnJ¾CŸ*!E­�¶·´AsÆ7‘|�¿KtßR©.ÂNº{*$‰…EßàüÍmŸÙ»>|˜ˆúð§+ˆ¦‹ƒÙÅz¬„°ÍŒŽVà©Á±õ)Œ-Ž‡ºÀÈÛd`æͧJÁÁ$ZŸ·±}¨ÓF¶ƒê\ßï`ó�‹RÕÈœ'ì�Æ„^Ï&XÚ”CÂäôTz¨ía¿;íôl*Ùwz‰M]MF¼Ö;BPå®8›R�ÛeÑdO(ìøãî§÷Ã錚M¶IÞ•Ù–‚�
çðCw#;Þ`uVJøÅhY_0 
-0œq{ÿH­[´ï>}¦ÎÚ]ñÐ¥ 	îÜ‹PØ7Ô>ÕX&Çs	½Sç/S*@~ãùWS� JN£Þùûå,ýz¾ã%èSl€©´Kh¿U
-‡+éKá_´'¶1�õq™¡Ê÷eQù:^Öïq½o±È7pÒoüÃòÈ)MU‹çªæûñÓ¶œc¢ÕSz
-vj»8×ÈÃû�²¥–˜€MÝ4…++âpþû&¯žrG5b#ê¬ôÄ1xÍåw)uéì)”Ã?¯D­DÁÚMÞ©ÝÕ‘`�bÙÕ
-¿ˆ£·L80zÊ‚ƒèEnøZŸnày;üÅ:u¼õ‘ÀÌþRm°€SÈ•ñÕ÷D
-endobj
-1206 0 obj <<
-/Type /Page
-/Contents 1207 0 R
-/Resources 1205 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1182 0 R
-/Annots [ 1209 0 R 1210 0 R 1211 0 R 1212 0 R 1213 0 R ]
->> endobj
-1209 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [80.6033 407.9328 154.2566 417.1482]
-/Subtype /Link
-/A << /S /GoTo /D (statsfile) >>
->> endobj
-1210 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [265.4578 363.0047 326.6578 375.0643]
-/Subtype /Link
-/A << /S /GoTo /D (server_statement_definition_and_usage) >>
->> endobj
-1211 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [367.5441 363.0047 416.2908 375.0643]
-/Subtype /Link
-/A << /S /GoTo /D (incremental_zone_transfers) >>
->> endobj
-1212 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [280.9692 332.6817 342.1692 344.7414]
-/Subtype /Link
-/A << /S /GoTo /D (server_statement_definition_and_usage) >>
->> endobj
-1213 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [277.6219 302.3588 338.8219 314.4184]
-/Subtype /Link
-/A << /S /GoTo /D (server_statement_definition_and_usage) >>
->> endobj
-1208 0 obj <<
-/D [1206 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-1205 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F48 885 0 R /F62 995 0 R /F47 879 0 R /F14 685 0 R /F39 863 0 R >>
-/XObject << /Im2 984 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1217 0 obj <<
-/Length 3673      
-/Filter /FlateDecode
->>
-stream
-xÚ­Ërã6òî¯ðmåª!
ðuœL<Y§’ÉìØS9$9ÐdqM‘
-Ö8_¿ÝèHJ”&³»¥�Fh4ú
…×
üÂë4�Êôu’iat½Ú]×O0öÃUÈ8K‡´c}÷põí;•\g"‹e|ý°­•Š MÃë‡õo‹·ÿ|óááöãÍRFÁ"7Ë(ßݽÿž }ÞþòþÝÝŸ>¾¹Iôâáî—÷þxûîöãíû··7Ë0�B˜/y…3ÞÝýtK­>¾ùùç7oþxøñêöÁŸe|Þ0Px�?¯~û#¸^ñ¼
-„ÊÒèú
-%Ò$Ô^‡Pàyõ¼l݆{³*6¯,¯3»@3á%³ê›XL‹Ìn¥"�‹Ÿ*. ¯rËlÜ’®`^ÊF(žªÚ« ñ�)Eæ%É”‹ƒúX¡YS£¬ŸBŸCÞTxBÛÙ™¶ÍŸÌ¬0Ý_â†NEÆm�ù妩wËU¾²çÒòÌm„‰ã0tÓW]Ÿ—V³`ÆHeµSChË QoŽF&»uŒT¹åH15+&2é¦åcG"KŽ4‘VÅȺú¹ß£EÙâå¡$/Ø:lÑ~â bZ¦"¸ßÐhgXFïV1Vè)Ú!*xõ¾e ÐO\›¶ 
X3ÞlÙÉ•[N©æÔïÜKZdOà,
-#´ª‚¯º
-D„€–ñ,d<‹›¹ˆŽDèúm?/a¿n�ÿÉÉõTùŽ}Š' Eë<PµdªPõ^Œ= üÙ›¦p¾�î 9Ïâ5ѱåÎ…µ¼Ÿói�¦¬Þý1M{ó™Zöà¸bõ:¢n=Çt´ÞhUjÍ·’
lÒìønåȘcí�Ó÷w)u¿?�Á^3zcš&/
¡¡µ8JÒâÐêš·eM+1cÜéè†Vlë�™;TÝ¡˜€¨I
-¨¹g¯RuÔ·«8lj
¼–Wjâ% ìëdq_T+s„éTN²HKâ|§¼
-yèÑÈñHÈú–†˜œ”ïRaDS®ú2¶´�}bG¶Ębje¬~&ëö<
-¯9Tw2rœ3g+ë§'kÎ4Wð´«àéȲñ-
ÿ
ŠMÅ+è¸;Á6›b9ã>¬ «m^=^b•ó�¼¾½œ]ÑuŽk«á»†l¢íˆþ|Çû H´41Ÿ5?>³<‰iýl,Óü3²Ë|‡!%Šb	É™rè�.êåLŽä¬ånMßG¼¦)4Õ
µQ~ׯ�+BÃõ¬#A±¢�UŠM4¶[fÌ~aZÎÝé¡XÛü1€Ô´£/‡ja>ïMe­x@	,ýÙrK&‚Þ~øÄ+TÙ™]mó6hƒwnû�ó§ûhg_¨¶¡ã2	Â
-}¯’a‚Uè™ûäèZ’ÞaÃëv¨î ©€%ýK®4Øp_šŽê
‘4®
-WsB[Y#HUG’°ñ”-“8}°U(ºW®0�ðÚÕ³:1“LÕš¾5¹æ,�h»‚1׈³„£ÊvfÃ(‘Œ\®Ãzqº°RBeq<òù3µfˆdâ^|ÈGÎD±��²&9ãà
Xn§GºÖ,Uˆ¡SšSrû°-¬q‡&Çë§D�-RBBozû_ÍØD¤‰d¢ÝíC¬]	DNÂvDD¬DÙ™,E&c·KÝÌñ8ié/ñ8?-X³=)ì1w±•È0gƒa™H§’är0<Æ:{,Ë�¾ìŠåÀ‡I쫤óizyw�5³ýô]-q„Óý¹ž¶Ã×sbIVaÖ^Bƒ*åØz­{ÂÙÚÀAöûÒõìYÚÉ«e›±Oþ¼©Þ鎒4ùò£ÖÜ*|—ÑáQÙÿȼ å)ت|µs‹Ñ˜Ê²ù"Ø
-„êoT9Ò¡Ê!ÓÄ–E×´—ÚRW“JÝËM’9•Úúm‘»	ýîÑÚ”êg¢‹ÿ±m¯
-¦’¾]�߀±ÕÀòÌŠô°RƤ¢YîÇ#§´ÛÜ2((\µæÚlr¸Xÿ&0SJ•HPò.½Ûñ
ÊyýBö&`V.ë×ë‚~9,+HÓŠ‹&§
-–	¦úòökfÿÉQ#�:H¦ÜV¤éâû÷÷÷·o±�u×=¸ØŽl@@{I‡Éhñ©rל²¦™?�fª�†Qø•â~Å‹oJSVí`—œ·µÿ9€~Ád®k‡�2Î/™àSTMÅn8È�ZPçkÄKk¡Ó8þŠs�•¯0
áˆÃì²|�±ÎË—ÇÉ×K^ë܆ÙÇ2GBÆIv™�5CÃô¸��:SS"œŒáK‡“1l�¨²ý‚¿NÌ¢T-Þ×�™ñ®¶”gŽ±'jtDWœˆ(ž“é…w‚в¥fW�ŸbØ·ðÀéå/áREMMü™"Ö~”>ŠHYÎ{ëæÿ'!MõÿÁÄ…Ó„Äù²Ž°.ˆ ÃÝ
¶KÈ‹†Þ6§u4ü÷C¤.“á±fè˜ÖÑ20:!ä�¥
-vÀ1´§Qj#W0…QƒØ™½Áe´±G9Ïß¹I+,îPG¹�ÏõG!/¾í‚ŒÒ¯ýï†a£:uÀ/}YŸ#óéŒû2wYW×å«çó�RpR…_¨ÐŽ�ΔCÂsÛg_Œ]ŽEò• ˆôÅm=Òé¾Ó¿ó"Kãd²1ÿa…ªH TÒÆ¿~ðK4±F×�¥&³úZ•Z´]Þø:G^Z{öã,Ä°ñN�ú€ðè!ø†NÆ9:ˆÆlP;Up
�ÿÆ¢ñ¡ö&\¬–·‚(jY5~ÈýÆ¿TVGo–îôôg '/ŒN×�b7;WSlñu²
-	×Ù1åþ¢§¤ÿðDÂendstream
-endobj
-1216 0 obj <<
-/Type /Page
-/Contents 1217 0 R
-/Resources 1215 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1219 0 R
->> endobj
-1218 0 obj <<
-/D [1216 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-1215 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R /F21 658 0 R /F48 885 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1222 0 obj <<
-/Length 3453      
-/Filter /FlateDecode
->>
-stream
-xÚÅZYs#7~÷¯ðÛÊUã/>*3žY'�Wvö¨$m©eu�Ôí¨[vœ_€
-˜âЊÈhÓXY«1+{.´òb�-¾L‹t›UÃ+
-@ßî°Â®é¦#]i˜§6ñ÷뼺€ÉÙIùTçe
eXOÛWÙ’(uI”Ý…J&YUïòEÍ-댚ët—.êlGô*«‰žK*T¯E�þF­åŠ;e»:ÍYì²ÜRÈ"¤M�–�%HD¬ƒ
-û*}„Át,')i“‚ëÉ
-�4%™ì]êÈLVÎœ@Þd�é†h벪9À±Åe¤oÑÁ‰R
ÁQÁ-ÙŽ­
•Žµ�oþá‘a�¸gÁŒÜd&‰V,”ß–Ë|ÚKÅf•Ú¯êÃ+ïNn((¾3bVÙ·É »ŒI›Øûyúô´qÉC+Ê·ZZ^Q ”/¦9¤yË)J£Hš]R}6›Q�&-ŸþMöTÎHøº¶ÑäºföMÅOkÁÚy�×¾—Ë|Ú–ñÄeré(æïi¯Ç?3jsÛ
-™<]Àš¶ºÝI•èP•˜U‰&·÷óQ�c.ò²Î×L|ø%ªY, ¡Aˆ˜Ë|‘ÖÎ¥sZsCMÜu±žR•F~†ÄÃoÊòËþ‰%¬ˆ–RÕ1¿œÖ%+†¢åÃ5C÷¾¾™ÎÞ¿Ÿ‹ÙüöÂjr/$ßFC’‹nnº¾¹Ç\$ ã£HZØÁMrDu¹Žƒ¨†«
³íoCÁÖŠ$”ÉiÁžiDpo—“€
-gbCñ¿}o"ÄZ–î*îQvWÍ@LNéçú–«Ë%cŒ£,§_hêä~C>EÃ&+
-P9@µ‰Eûtð:ŠYT l`lzÂ�^Qg,k_�¢ól¬54õ|ŃK-"Úþ¢“ј­öœTRúÁ´¦>¾R‰DñáÛá:¾ž«
ß¼¨³GXÝ×Ãø…ƒ¹OË÷L#òûñ+…N"ÓWà6Û�m�WIL¸ÎŸà„tI4ô*µZ:§zEM.îá×»¶{ÂUã,
m/åáPݧ=䄦»ùENþÉ!œˆ(‰!<„Vp8VÝ�ÏM˜
È��Žè¼3*Òù^!ì�‘+bÏÑÑ	O¯8–7ûŒzÈ"û-¯¸+¹´ÁÓkÔ�Dsˆ`:U&„guÂ
-¦Háˆqø±‰­�#8�U¬{@>‰hcò»›Ù§«;¾IQ&‚ÃGbú®zÔ™è’gÊÇFÄ‘6_‡ä�8•IPùÞírwª†«]°j÷|Ò«NË÷L#òG|Êô8âS&H¾Æ¥`U×¥¢„]*²Þ¥€ä]*6Þ¥€HwaIߥ [»DcùˆìWM3ùJ,‰|àW¡"çÿ·_è¦;íV-Ó	¯b¦ŽSÁYñöÁJ"”Ôú¤ì†éPxÿ
Å™˜°'ý_´ÞA4y"0F ?ˆ{ˆ+à
¹º¤6¾nƒ’‡ÉA“9€è'ãȼG
ÙáBeص]K`ßp"8F©äkpýñ5”ÐEFol8]®«è¹VÊvå´(§U™Nëzs¦µƒÐœV áÑ ¿”1l$QÜW�×RyøWïá`
Ç.·@M÷õÏqi�?ó}h�à�kjøº„$�Àèî5‘ðë>Û5÷«”6�Í_°Þßÿ@‚AþN8!êPX«Ñ‡N*oÚixŠ¿ßk
-üœõTp¢¤‹
-À…ý7B
-þ@’�Ò]r
-äÝ—ŠŠtµe
Ð�Û»»P¤Òë–X*~iâŸ8�Jfüc-–¸^P¨É²3ºcs—+Xl@‡ëôJÒY
-w¢[±
-�GF|‰”Ç�=¾¡-�†©lçÐV´Ž©Ä_Ò(Úø¢æ

-endobj
-1221 0 obj <<
-/Type /Page
-/Contents 1222 0 R
-/Resources 1220 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1219 0 R
->> endobj
-1223 0 obj <<
-/D [1221 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-354 0 obj <<
-/D [1221 0 R /XYZ 56.6929 183.6365 null]
->> endobj
-1224 0 obj <<
-/D [1221 0 R /XYZ 56.6929 158.6249 null]
->> endobj
-1220 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1227 0 obj <<
-/Length 3161      
-/Filter /FlateDecode
->>
-stream
-xÚ¥]sÛ6òÝ¿Bo•g*ß
-ò÷ÅñÙ
-ŽýÛg*ófö/œ‰,“³Í…6Š­T‚TŸ.þÕmØ›
K§äg”gÆK7!@©zÆÚΜɘU0…l8‘7ó¦Ø})v8Öó粪
-Ó[Uuý™f×õ®›¤A¾mž‹K1�ð²mŠj
¢ÔBϯ×($¸Ë¬ÇŠ†9é28
-j@P�8[®ñk’N±m	oh("kçA&0ù˜)†ç£x�“{>Þ’¼Kßè´cÎðä]¢µÑrô?á}îšvÂ/yɬWÍ£H�™ƒPñc\¿£ç¶niÐ;
ò8
W×4E1¶se=:9³”ÔM˜&w3ÜöL¾Ã_ôÛüñ¾Áæ‹%ªO
-¥’I5fHË 37`èÈótX¯°q¼²Á&®j¡ÀC;!ÀšåI™‘Ia™‚ðÍ9Ÿ¿ÛçÕ¢ióåg:ç
š‰¥�ØÂ3Ú¦¿N)KQãDCïtq½�SS
-Œºé¡®	¶‚À*G…�è%ë]K3¨þ®wŸûû×ûíŠÞŸB$EÐ}Ul"4P|Òvùò1¿/«M7[í#{)¦�̾ê„ŒÕmÿôxŠêIƒ¢„
âøúã=Tg€Ød ô$׃Ǻ‰{m€·r[œŒ—Æ8¸÷J¼ìc�Ž—žqÕ]ã¢9Üü nZq>3çyè°&˜DNZk¹r1ˆœJ›(¥í|›o%ŠÏQE¬ A0å<ÃÅÐ|¾\6Aƒ.
쾦Y/-lÔ	&í…8ff„öCÕhw�½¡* o·™Å„m¡œGWª\øGÎ	ˆQ¡h?b‚4Î¥ìç7ûpj€ÞÉA™	¸H²ŒêKšxŒ¸‰Ò
Åóz£LG'ô¼;fxQz>æx8Í]8BbÊ(“˜#~COT%©yЧ˜hò.–‰þH/AÿY†Þ‰ŸÑÈq01Lðl´$ĵ@!d5ð,b$[Ƴì·Þ¸P°x&<ªê F
	ZÇ8_{òA«Í#Ú}QlSälð¦V'ì|Yo6A³ð¥"ÁÁÓ°‚=Lùné¡Úpàåé€xµqùBOˆCæ¼»KÒŽ‚
¿o!zO›ž ÞÖÛvWW¯ƒn�–$<�RP
-m^VÍPƒëç¡E„2rý’"[4“Á]oÚÓµŸ†šÉjãÏDz>ÖéXÖaÆJ`
é#r8Žb`"Ú»W¨wXäQLƒ½X?¢?¬ÿ¤˜??–ËGÊ"´ËŒx¦Ê'Ö‚ðŒGíc×E;Š	³tT �RWàþ"(X
àþ·ÞF�ólCT?I¼±2¨9DËŒ”zèC¼ñ)¼À€¶ÄÑÒ´TÜ�î%ó,ëãû	tU	e"ò&¡Ý©LÄÑ}¤×ë] ¤u‘·c„’ŒkmãÆ�ï‰6‰aÚtHoÀ1@Ƀá”(ÄÄá¼R”xK—�

¢hB·LEbÈA൅@<É&$BÎféø]Šk^YXëƬc&â ™‰|”q³þ!jù\áz_á{l0zôŠDCZÚoM ,ËÂñ…Ãxmåðø£S?ü:ðRŽbì%퇘Ó)?¦Å
-¯ ¸“ILYší»‘\F‡1žIaeßÈä
Èê<ø.ÄDk®yà#\<§}„—°—Î^qÃd6á"¤ç�$^AÔ[zÖ`ýpš

-ç°˜y\q^n c!ı/ˆ2S¨Ç#S½^�-ßj»�3"{e2Ô‘y†–r,w�Ó‚Ô`Gm
×�}Mûu�{ï§ÛÿÛ·–­>½­ã°W¦í‰;›
-R;øJÐ	.Pf¥v�¹�K$}Ó»0cµ 
-Ì(™nú8Y1¿ƒÿr~u$ØTIÈ.¤r,èKÆìø–eŠ°zãpÚƒà§ë�œ½«áL³þ±Ò΋þÖá\vàbÀ³dÊuÐMæœÌ:K¾P_­Äºaþ²XæËK$õSî™[F­³Þ7	¨\·´	½Ä¾w¬tñyÈ5±®NF�”Ôah^Âö:R.�A~¦àHýëû>�P¶Ì8äü‡¯Kߧ¯Ôu÷¡¥n!²ž‰Hpsý!äèó
©Ã9Þ‰ê¨ÅDfz˦[<k‚‡a‹G1ã ?01lñ¨.9ÆaK8ìµ
Å!,)ÅcPÌŠ6Îâ÷³]\wp9øFI+Âqñó¤QÝ7µ�À‡’X[s£)9dÐü¡íÄ8Ž�ó}E×":Z-b¯_ÇžÈ17ܵ5nÀÌ®XîwMLÖGä@ÒÎólDnß•ÏåšÈ
]tìZÍklU>—Ídâ/N|]¼·¡»ÌÿM+¡†2Ù¸±6x°S2Á°
›†t$òPÕ˼Úmós¬BñUëç©’gž[Õë˜Cädê(´b^ÈW*Ø>ÖKMX'n|`§D&_¡Ÿ�&è¬ÔB©Ë1ˆõZ©=@0LVj{Écxé¬ÔÆ6¥Åñsœ&Ôp¢/Ô%aÅcìä?<&@§/Ö"ÖL›ðb”6vôÑò+ŒGƒOÖn”’­b5lÕ‰“¶ªÄú	¿qÊ7xˤÉĈ^Š{’,Ɖd1νb¬Ò%þÕÉ5×æ,é.Çöœ‹a+ 2„XÇЙ,ñ„±
-¨š�úÛ­U~›µBò!•Pç�µ‡tÚVÒAàû§dÜÇedW’¥s¤;¤cÚÃ
-¥å€ø°Æã‡�»®Æãý�÷Ì‘B
-Àf¿	µ
-Œß½lóM¹$ªð
-%ì¸ð8¨‰Í¢ÆbÞWÅö… ’
-ðAN›™Åt\¼Òmî°ôc…ïyô•Ú±£OÔÒræ¥w=>ŽôµÃ9OR%ÀVzÔÇ=fvê`Ê0üÕÖuÞÕZßýã°Ã/ç´#�þÜþÕËÌ%¦ð ætƒþ˜õÿ
ØúÎÆendstream
-endobj
-1226 0 obj <<
-/Type /Page
-/Contents 1227 0 R
-/Resources 1225 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1219 0 R
-/Annots [ 1229 0 R 1232 0 R 1233 0 R ]
->> endobj
-1229 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [367.5469 658.7781 428.747 670.6783]
-/Subtype /Link
-/A << /S /GoTo /D (zone_statement_grammar) >>
->> endobj
-1232 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [483.4431 456.4665 539.579 468.5262]
-/Subtype /Link
-/A << /S /GoTo /D (address_match_lists) >>
->> endobj
-1233 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [213.0783 62.7905 261.825 73.5749]
-/Subtype /Link
-/A << /S /GoTo /D (dynamic_update_security) >>
->> endobj
-1228 0 obj <<
-/D [1226 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-358 0 obj <<
-/D [1226 0 R /XYZ 85.0394 642.7523 null]
->> endobj
-1230 0 obj <<
-/D [1226 0 R /XYZ 85.0394 619.131 null]
->> endobj
-362 0 obj <<
-/D [1226 0 R /XYZ 85.0394 502.2708 null]
->> endobj
-1231 0 obj <<
-/D [1226 0 R /XYZ 85.0394 478.809 null]
->> endobj
-1225 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F39 863 0 R /F21 658 0 R /F63 998 0 R /F62 995 0 R >>
-/XObject << /Im2 984 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1238 0 obj <<
-/Length 3053      
-/Filter /FlateDecode
->>
-stream
-xÚ­]sã6î=¿Â÷fÏÄ\‘ú Õ}J·I››ëv›ÍÍ=´}�m%ÖÔ–\KN껹ÿ~
->™§±�F¡DR¤q¬,ÿ®JûIÌŸÄjºÈé�‡|­,3°E(€ºfœmV7ù�
,2”zúèvVùSvØ4ôRÔÈ»»Èt¦T"�©XNþ3›'A0-�¡÷´ü/}ÔÓ2˜ø“ûæšÈ;�"CyVÖÌì:ããKf›4D» Š6'Ý(�
-#Uì”CÎêÄGÛ™«HO_‹ÍW†”�]¾JÛ|…òéôq–ªiE8y™-6Œç�†uG±@ùš�k4”§ã˜žR)d¬Ë|Á¸AÂ
û—̪ÍÊ£Óìû7U‹ÂÎgbËj ƒéK¶9 Áàº3ØÓt]Ž°.Ã\™?vÅÃ¥®i„®Ié>ÙŽxcTA12Hø“‚E8ÔÐç‘^–Õ¡kÞÙ«©V‡%G(A3!Æ«®R›â%¿ÆK'+Ê%Þmê<l€ºÞUe],ŠMÑ	
íÎ"x‹
-hc·>VÈn¶Jž:'ã
-D'iŸ²}8[uõ½Ê›¬Ø�ÑõŠ.
iD¨ Š\¬ºXçë�Õ†Ò—d^K°ÝšÒT¯DˆÀ„¥/óà±F˜è•Q"Œ‰úL<®1)O«ß¬_3LÀ<�¬ñÁ&éäó°¨·Ue
÷�G*™>Ñ÷[Ú½�ÿ¯bHBϬ\
>°Ñ/‰…2QÔ÷¦Ÿ•ŠÊbAé
>Ùd‹|S#”Þ‰¶ž.Š2Û»8˜'M:ý*œ62)ÓQÀ\°,	ó–8ÞÆÒú5÷…ǯó’ðW9…ó|	
iu=º
-ÔÕ’	[œžH)#Õ
Øô6/[ŽJ‚+­a¹Ìj[À‚i7©@QûbeˆóÜh#TlœÆÈÇj'jG}`Ðk%ýzä²úÒ@GC
œ_>9dí(ñšÓôÚ' ß«´Žì“8òÈ Ö€´°†zÞ{Bî¼ì½¬Þë°PôŪŒuµ9)/d EIçòÑkäìžã‰
-Ù9�„¯,7Eý [ÉDÄ3°h°î±OzÊ 9Ò+tö;{ªol_‚!ÅdûÊé°±«övKîÙSåÚé
׬Fûqýê Þð¥s+¶:xÁÍQ?”ÂÆ¡¦ük‹_tÃéí:/çU9"ùÜãö̈BÞh6
=±ùÒQ(ãb]“ýJ=¸=ГÎÈ6ÔÉ¢F±á‹%i™1-Ù0í5èøôÍ6Z.¶5Ã6êÕØHCe}Bc½·æ„J¤Æ˜ñ)áÜSœwIÒµË_¨ 6ihÛ=¥Ê’Ò�ÉXaËþ…L:Šo1	5AÁ­÷˜´
ðmœƒ•��à%ùè:cÇ_tIWŒI‡ò¦RB%íèŠl®çl.‹¹ø²8àI§K¶K<|�S3z •
‹ß³É¶EŽÃaLt¡¢õjtôð=ľb·uÏ@À*ýRÂh_nùzÁ)¨Û‘²¶Xì;׶æ¿g[àâzÄ‘æ&1º2ó­ìعª ‚Z˜Þ,nØ”¾$íá
-Š»¨Gíobs("&oïdriΠûA4‡2Â9é ÞõóJí¦I
-´žÑÀ|ƒE¡ŸoHIó
€€ñ7Åò°ÉöôNzEŒáä6—¶qƒMû«`„ô3}¨´-Tp‡‡qô½�lHÉ“Ù™œ0wöÆ-ƒî(‡×qÓàŒ{vUÁþÙ/BN‡ëî8ã™­hã;ŠŠk£×uN?&puÑ–“at
-06�³-ÞàÆôÿÙ=œ
›Zzäv�‰?
fåX+óåíCªE…¦oj=~º5ÿð—ü³ÝƒÿðR¡‚@~µZ˜¯¾zª÷ã'ŒýÑPüKŸ‘™"üÏÜüé?(jÿÚ*Âq”93œTÚˆÈ
-µ«ÓQ,äé0Q#¬ÿ?-�endstream
-endobj
-1237 0 obj <<
-/Type /Page
-/Contents 1238 0 R
-/Resources 1236 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1219 0 R
-/Annots [ 1240 0 R ]
->> endobj
-1240 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [369.8158 645.68 418.5625 657.7397]
-/Subtype /Link
-/A << /S /GoTo /D (dynamic_update_security) >>
->> endobj
-1239 0 obj <<
-/D [1237 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-366 0 obj <<
-/D [1237 0 R /XYZ 56.6929 475.2364 null]
->> endobj
-1241 0 obj <<
-/D [1237 0 R /XYZ 56.6929 451.0522 null]
->> endobj
-1236 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F48 885 0 R /F39 863 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1244 0 obj <<
-/Length 2446      
-/Filter /FlateDecode
->>
-stream
-xÚÍ]sÛFîÝ¿Bo¥nÂÍ~“›<¹±�sçꤎúÐkû@Kk‹c‰TEɾôæþû
‹%EI´“Žs37š—X,ÀX
-O,¸¸üÇ9�Þ_Ÿþøãéõø÷É'ç“N–¾¼‚+ä�“_磈ýÃ	gÊåfô/œ	çähy¢�bF+ÕB'ŸN~êöfÃÒ!ý•3“Ël@�R
)Ð8fL¡ËÅbœ*n_7�c�l枀U±Œ Æ¯üš uE°U½ÞÄ(‚ÜÖ¥¨>Óàòュ¹b6[�Ežø¦ñ
MþÆ
,7óˆ@À¦¬îZF€½Ù´Ëfq¶žÞû
,¯
-\ÅZè\Þ¶lG\ÑÕ’å`ðüxÇcºÆ²LX‘ëÕ¦l…ÆãZZùi‰Gìg¯žQ yÔUɤ
÷fVp
-ÐŒk—N1h	ËÐŽ9è짭_G§@H
ëP¦7�U+Žê‰£ (ÎjßTßmh⾪p‹ªy$\
-°¹3eLð
-Q -øå~ìšùÛb»ØĘü׿ùrz±w„d¢¦Fn?#�‚5`?ÊìÌkÔnÞ›híw$C?=^Çže¦¿æm
-<Aiwpíäcþ´bÚʸ“>bOŽzûìen`UàÏö½}ªrÑ$™–_Uº@Èq!"E.8‘\1«á˜ž¤Eë8ЊÃvÅAìJDå t)ª¬Ú
-§Sm0íL@i¨­‚{CåAÖ«ž«EŒ,FÉ6–€#
-æ!õÆAÖ�àõåRŽÎj�hÔª%œö)¡àè{.áÄÑpŸ:!H(ôp ÝÙ
¼¨~ŠJ³èrøÜ´
Ëö#�€DÒ‚Þ{I¦‘	çXò¤Í¦ö8²ƒRJ¤Êa»ÈE„ÜŽ�_nj¬~pôóÙGÂŒQ
R.X¥î¾«LÞá-�ë–7Hƒ {‚Ç+Š?7Èä6£XŽ!ò*lù(Á‹Õj’.œ««Åçˆ^$ð‚€Ã=0‚|`˜¢¼xDÄ…ü7ˆåÏa†yH–'Á0gW¾ãD4»{Á�ìÐ!ï€cì»Â˼ýØ8¨}Ò]—áž�!6Wö›Ð‚˜d3iÿ‚¤íŠ§âˆ„‹ØeÆ~!Ž(�Xdß4Ž(Hèd®þq¤Où™8¢¤`R;XþT/Šh€˜5å<
[`‚†TôÀÀGp£5A°,¤Q¨rqÐlW=Ç¿¡@e.ÖV�·rØ¡�^øÒÅ
-|A¯èv4õ]þÿ°aÜô)éŸòËçÿßE³j­¿ i\ñ”‹€I1¶ò�¼ŒeVÉoé"XjYéÄ·w‘>åg\D
-…GC–OÞSP.M=p‹j
ª¶JÙ@�ÑÜb”÷á}þ*…ŠAí*œ.Åß¿¥¡fÈÛ:	¼­¼ýÒý¶ÂU[~=íý~™Ñ|{÷èÛ!�Rv¸ìmÑöïxÌncO,‹=±ÖUìÓMÆBˆ$œ�_EgŒ¾$`»e^ÄöËÒOçEU6ËøŽVè-ŠÔ°‹„m0Q1-Ç‚æ&ôyôg`% u\ì÷— fÒ`QBùgëj¯?èËz[EDìf‡u1£]Bëz xööDmD–û]É]Gós³ñKÌ€À’'-ô¶^,êGªêpUW>bqYVì<nb«ùÏNñÝÎGÖ˜sÆ
ÄÕR	5ü…(â¤=¤§M¡E
-.›’ÏnŒÉ¯túù�;¤ã­÷i˜ÍÌþÞgá{@îI™‡þƒÌ’»E}S,„}a…3„YlJäƒo%=”ØHl�˜>W„µ]×PƘb·`W&—¿Ðx	;w¾‰I8„éôAÿgî+”œÚ�"Vû¾™tZ¯>Óˆ¬Q´¦Ê;“籃)‚¡R[&Ï£ÿ„L ¤BßÈ…zTv²ÚØOŸF»~o¿ïâNWŸ†Rqb}ZS70t"v"BÑñdî«8–O_5ÛV­p}DmãHNå€#ÙêyDC^â\ü,à°ë]N„åÕµyï|$RÑZ±X`½„À®X¥¦ÛPù®̻ËûÅ%w±Ygp5årØ)ܵ¹tY˪ި£Žiûõò˜õÿÔ–F{endstream
-endobj
-1243 0 obj <<
-/Type /Page
-/Contents 1244 0 R
-/Resources 1242 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1219 0 R
->> endobj
-1245 0 obj <<
-/D [1243 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-370 0 obj <<
-/D [1243 0 R /XYZ 85.0394 650.4851 null]
->> endobj
-1246 0 obj <<
-/D [1243 0 R /XYZ 85.0394 625.2941 null]
->> endobj
-374 0 obj <<
-/D [1243 0 R /XYZ 85.0394 171.1138 null]
->> endobj
-1006 0 obj <<
-/D [1243 0 R /XYZ 85.0394 149.3849 null]
->> endobj
-1242 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F39 863 0 R /F21 658 0 R /F62 995 0 R /F63 998 0 R >>
-/XObject << /Im2 984 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1249 0 obj <<
-/Length 3623      
-/Filter /FlateDecode
->>
-stream
-xÚÝ[Ýsã6Ï_á·sfÖ<~ˆù¸Ýf{é\w÷¶étîÚ>(¶œhjK®eošûë @}YvÒ¹›¹™NL‘	?€
-ã��=ÁƒÊ{=Û^%Ö›{6Wß_ý£�°7^�”Ÿ’B›TOP›ž
-=D»)›È(Õó²Á_5(¿wño>±d¦D–¤)Oóïº*&ÖÒ UŸZ&jù¡ØÕá
Nkçå�V|*7Z¨þRì÷媠§Ãc1¹WpJ<OZïe]5ÌèÅ�;'2'ý˜�¤³…q0¯u ¥„·Vªƒ0¼™‚É„²Æ÷…hÏßÌÒd̽4
-¥¼ºÈGKtÊÈ
-U%C€Á$oe�E…è
-q
-Ó\­b‘h|oÊf4g€ÍÎË==–`ÛKž%TÉ 	¹zhBi”c{j2±‰­vå¹ÜZ§ÂúXF˜Dý®àùt›ßS*Ž»VjŽD‰5„C�'%h‚G‚͇VIçdÄQDf»½Ks@0»–uµ”»ÞÑÎ`ÛÒg­¢rÒ­AHpΩ$༷Ée§Ò§:ïTZª‘xqoc�¢œH_X�i&xmDš€G¬~‹êÑ>‚S»¹Cõs©…´,\žá}´hš�$É
-G g‡–}äõâ®qv=e·}ŽÈêY
-ŒfI:dã_!XPÞö^|\â�€�{']a‹•^zª©±‚èvÂjIicÍ›©³ËdÂù$ž^ÀÇx‚	&
-’	(Ù¶õr°˜)»NzÍ4só|“Faá¨i�‚+Êì`�t[LÃ΃¿l:£Ë1î”°©;ñ±Öñ±–… „zâÛ�ëBB ‹ÁR ¨éwU„Ä´br2Î@ÍüÐBüº\5bª@®P)®§�tu;”ÍY}AP¬ñz†¦¡Ñ„m¡¦¾þð=õp-˜zC€€½ì!9ÁƲè÷.ÉI®è•(z[MíIƒý
ÿÉ+‘áE¢ÚÚ÷._þʼç
­²9ª}§ÙdTJ:å]«lÄ{C�9ÿîê¦)ï7L
-XÍãôÃ2“8ÔÂ9õZÔ;!U{ýQòêÛº‹N³yì8”ÇK¾úÑf~’dŽ_ª«�·@«9îvõR>R	²jt¦?S‚I+mòÇ›�c ÿDƒœ„&e=x¢Î;°?(AÆ0{| i�rsâw&¦ú£ì�%ÂK�uõ”³60Ñ�$cÚÔ�÷à+×1ëŸFü”QL‰ßx!]­Ö.%ßåIºÖéI5 üð—aÔ†Ôß•K*B4õš»~¼¶0´ªŸšªÊ
@$Ï^Èh»àš˜˜Ø=¨3K}òòîÕK»Ï„ÌdÖw¹ãsRØÌÿaŸšx¥Zîø(Þ?ñýäªà[žxÛ“ÓÏŽ§ï*¼š71˸~e¢ÁßÛÝTÒt"�B¥§×«gƒÈš…Éä¹LŸê|ðÑRõ…ÛLÝH8ÛÌWo©&–^m&xwn‡ë
-~ªl
˜Ï<dÓ—o©&ÖâÄ‹,ƒp}À@° Dõ²q|ˆ”h”†}u[àÆ'2!lõLÉÉ„p ˜6oBHzÆ„ø«¡²ttúS’t½zx¢) YkMßçÿ¾õ ÿõXÿ\âƒ&T{.Ÿæ\c(}±B>,jŸZ°±Òì6²z•	ŸA¡òpJe©½ŒÂ>Õy¶TCÆ“¬:-Li'’ĨË\´Tl˜ÑÇ<	d>C>¸ŒÙ¿6€‡®2È¥!%;wŽ\¨VƒË–ðH_‚HÆ"vÝ3å	öïïÙi±:=ÍÖ+!ž‚
- -r*a1Ž�8äœÄN¸Õp:°1ãç$ãºN83׃�Òg†¢Z0¶A½êÎ�ñ™�ÕåÑÑé€=tN)=:zK*>�¨®FÜô•ˆ¤ÄÀJO‰§2ð^+D8bm/<»hþªÅPì¯ù7§áq
-,óv£aSk"‰__ʱ1R¹†ë|ºÍïz
-
-ÓÁùàÅÎÔåèpÜl#Ð3hFèa“à­csdairxa�Gnq©5ß¡{¹V¡Ø¤M¸lܯó%¿ó³ÖÉrS7‹áîxER<üÊé°ÍËaçÀëÃ@î­Æ;ÖàNµ²„DÛcœ3ßíŠ|O½ámâÜ£`î¿LÖJT*¬J}û�í¦~ê>t™(Çe"‘z\ÆSg¾|7VàçêJ¶ñèýU|÷/I& F8óñƒÎ jtxAALá6lrêâùóùSÖÿ!Å^ßendstream
-endobj
-1248 0 obj <<
-/Type /Page
-/Contents 1249 0 R
-/Resources 1247 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1219 0 R
->> endobj
-1250 0 obj <<
-/D [1248 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-1247 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F39 863 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1253 0 obj <<
-/Length 2665      
-/Filter /FlateDecode
->>
-stream
-xÚÝ]oÛ8ò=¿Âo§
-{vO@"
-Uï~³ÎÛ²«8³(Ò}Sí¬�©TI0¼gت̼ëÉÆm•�
šÔX¡�Ó¢}h�v˜=RÓÈÝ$˜Zclߤ»·B
j²²ã8h>¼$Êèª'Em'ëOµQÔΧ†'7ð¿H.DD¥ÐÙÄÀ;3«>ù2
MRÎIÂêÁþ¶;)ø‰Ÿ.—bò¶†;Mú׊”§}Òþ^`‡=½ÐpÅŒ
૘bÖ3ý{½ÈÁ¤À:¼ñ—ˆT§œÀ¼šPœEY¬if^
¿ª[šÍj…æ©@{ÂLѶd}0ðågɬè„ù|]4�ÒݹdA§ñáûæsóæ#hžÍ`óì\°ä3þ‡¾˜:PCå,8c#'ý‡þ1Ý‘�t}¦» ñcš=.ÅEp¡©qí0Œ³”ù—e2UÚî^v`ñ1BvXG<ÙôѨ¥1 ! Ö?á€�k„‘A4Çh•Üãä&º’&_(oF—6)Ž—'6„¦J{^õâ_³bÕLñÁ{´@°	,Pð¥
DˆkËbNÃMC¡ÀË��æ@ÁèYøD[È$Œs'Þs‰ÖñÇë°ð"ù¢�Àðõàú 'ùˆH#|ß"·ï3`ä5Æck‘¡b]AœÃ¡Ù=Ž_Dæ�KoÔ0ÆD¿dñ€N1feÓ¢�=V5¢‚ƒ�›}o862n¹ËËE˜÷5g!r*:íMSLQÚ!vC²—9©‡ÎçÙi’´]Ü-ƒš�<&µ„-˜{‰0™ÉÔ@ÌýWw“J�/Ì2ñ­0©áÍ8ãöEäutÆÚÿ@˜ì“>&Dg]ëUš±ä	ãN½¡Á¼Æ/&¶eó@©>
-�‡OÕ ø¶á~î6Ù�¡ý× 
-H#¬S†)™•C^00	Ëú�	‡»À„£~`–S…mcq
-ÅŒ€÷yù"¶OúD+0p\üÿ÷zûý?ÝëåÒ–©ÓÙL‡uà¶ÆÊ1°QÁÀoõi&4k„…Aªg@§2ž
yøµü\Œ6ôRÛÅ�oºW­�|ØÍõaÅwlW+ÐÉ]¦ê¿!xz8&±¸©Ú!.ör©]Æ�ùȈ§æ†§Bc'PŠTe d	Íæ&…<–3™mÆ>}Bà#¤Oý
-eÕ\°ƒ2�‚þc]Χ�jº™¯¦˜n�¥!;ƒ]”¯9¤†GÙ²æd»ø……ˆžã>ä:*„i¢¾£�š
-(è"”¡)º8
-�aöTPÕÇý}›@€Tâ‘ôÖª|Ù¹ókõ’fu~"è±ZîÞ»Ÿ#Bù8÷µò¬Ij´’Óg7¤HT­ŠÜô… Ÿ�¢ŸñÍ-ƒ-¤g)ýäíkÑyls…�Û`"©7
À†›Íìa°qȸeˆóîr	(š·E¨
-endobj
-1252 0 obj <<
-/Type /Page
-/Contents 1253 0 R
-/Resources 1251 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1256 0 R
->> endobj
-1254 0 obj <<
-/D [1252 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-378 0 obj <<
-/D [1252 0 R /XYZ 85.0394 141.2512 null]
->> endobj
-1255 0 obj <<
-/D [1252 0 R /XYZ 85.0394 118.94 null]
->> endobj
-1251 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F62 995 0 R /F63 998 0 R >>
-/XObject << /Im2 984 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1259 0 obj <<
-/Length 3339      
-/Filter /FlateDecode
->>
-stream
-xÚ­ZÝsã6Ï_á·*3µNü5÷´»Íîm§Ýí%¾¹‡^d[ItkK®%'›þõ >lÙ¹½Þd2‚Hˆ
-J\07��ónÄùpÈS€SÒÅF&¦—ìu£�Ø#)c�˜`á´ä£iX
-óŠàÀ4!xhÊhÀ™=¼ Öã<" ª Í?sz¬ê.#@ <lwŒ’‹	êâz8QÙNf¥öÕØ !†h%˜ï즘ÌÄR§ÙåMr�ß”ŽËk–·ù™MI1Ö\˜&mJª! �Óbfb°)ðBÑ–h¿-YâUdÖb[ï_ˆnÃ÷ø±¸,3/%{9ý¦ÁËä¦)HÀÒ,5ß¼i H� ï^Ýà
-"IR~9�{Ÿ—
wþQL7ƒ˜nƒ¿Å;Ìpm—áZ
-G˜óÖ5óoso&¨Ïõ±ú�nÑÞ'¦ùR€9�[Ù =�iyÍ¡%ÈÅ&o<ÐÖaLÂMhëœ qaþк|9út¼ "EÞže"?†xª²€
-"ʽšO�ÉÝ…Ðöh�w\Q©ÇeQ
-~g�JY
-á¤üzïg=ßÔó)ê¢VZ_V£ãšÐcäbÊA/îHJ}U¦ú$)ã$	Û–M½)Úâ¯X
-Õ>õvç«U±ó§UÿV­¹û¡âLŒ{|!
-QÁk¬Á]áñBû%ÃG‡×øB©$Rd@¹/©
-.+±Ãß�ó÷Ô4]üsÅÄžT*ÎW#Ò)™�ª$ÊŸ·P�§±É_C‚|姲¢uÍ©D†“â¥�ÎCV™qCi‚�µ�ƒë’àõƒÅ=ëí˜XKuÙÙLç}=0ùmZíÎ:9Ä÷4�lö’äŽéTôøÈìbëR3’½eÖAiÞö4Õ„í±‡CKgÆ@/ÞýÂ�uU]4Ϻ`_ÒMG%ݾZL‡¾Š”)Þ©ŒÍù‚¶•x<6½Oý¾"�38M¾­…P±Ðâ•p=亰ë�kºB8Úy	X§!q¾(¿ãšP`4W™Å©tv¬
óµ¦ß}Í;¼×#C¨JC¿÷Eí¨ŠgéáЯO~ñƒM~¦ˆ/©ò
Û<æ
-endobj
-1258 0 obj <<
-/Type /Page
-/Contents 1259 0 R
-/Resources 1257 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1256 0 R
-/Annots [ 1262 0 R 1264 0 R ]
->> endobj
-1262 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [361.118 694.3759 409.8647 706.4356]
-/Subtype /Link
-/A << /S /GoTo /D (configuration_file_elements) >>
->> endobj
-1264 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [347.1258 314.3269 404.2417 326.3865]
-/Subtype /Link
-/A << /S /GoTo /D (journal) >>
->> endobj
-1260 0 obj <<
-/D [1258 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-382 0 obj <<
-/D [1258 0 R /XYZ 56.6929 769.5949 null]
->> endobj
-1261 0 obj <<
-/D [1258 0 R /XYZ 56.6929 749.7681 null]
->> endobj
-386 0 obj <<
-/D [1258 0 R /XYZ 56.6929 443.842 null]
->> endobj
-1263 0 obj <<
-/D [1258 0 R /XYZ 56.6929 420.887 null]
->> endobj
-1257 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1267 0 obj <<
-/Length 2860      
-/Filter /FlateDecode
->>
-stream
-xÚ­]sÛ¸ñÝ¿B}£g"ß'O¾œ“ú¦—¤®Û—ë=ÐeqB‘ŠHÛñÝô¿wP D)餓ñp±X,v�ý„Âgþñ™Õ)“¹še¹J5ãz¶Ø\°Ù̽¿àžfˆæ1ÕOw¯ßÉl–§¹fv·ŠxÙ”YËgwËß’·½útw}{9š%&½œkÃ’Ÿn>üL˜œ>o?~xwóþŸ·W—™Jîn>~ ôíõ»ëÛëo¯/çÜjë…çpbÁ»›¿]ôþöê×_¯n/¿ûåâúnÐ%Ö—3‰Š|¹øíw6[‚Ú¿\°TæVÏžaÀRžçb¶¹PZ¦ZI0õÅ?.þ>0ŒfÝÒ©óSÚ¦Z(3›k‘Zkìô)³”i8µy¦xj¸Ê†S|ꔞr¿ØÎëªëËfþå±|,Õæ:OyÆòYÌûH‚�jB‰À
žÔH†»uy9—*OH‚Iš¹„Y–Û~
×g˜ÝÓ.ËUñX÷4(š%
›ª©6�ZWu„”~íÍŠÆ}àñ¹Ü5eMp÷¸Ý¶»¾£¥H'
ç®RÁŒyšk-œÀÅb
"
¥Í’3&ê¾Üù‘jYôÅî’Û¤,–/ˆ ©~íä
¨¨»– EÛôŽ´­ýܺ}&`S4/ݽý4P7墯ڦ,/ÅsU×Ý£nÖÒù-	W5N´ ÚΓn[,JŸ‹ª¯š¬Ú�'h7~ÕCHÀV8�ŠÒÌ}9¬Û]‡»#Ü·ô¥Sƒ»y–üë2p�eG“uÙy”j’^ §mè…©ê²éë—±Vt7»¢‚�Sœ:°ÿ¹PiÎ8“”©bÜ:zŒܤœC¤`Œ%ŸÊ]Õ.«ƒ»KŽ’wŸixÓÀM?ÁýEï‚FêT
-#ÏûiLuÚO*sQ—EÇ;¯¼GŽjDX+Ï‹0PMÈ0vÔ,U67c!œó)i’D¸ä	Z=é†"sØ´OŽP'å×mE¸eLе�Xx2Â.Èš–‘®È36DÒ‡½Åb¸?•»—‰›–"O™â¨õèìÈ¥¥5©¶{FvŸëÁaÈ#¾öÜ Ä<öe‡1%c>e,ŠG™�<ð5Œ¾'ÖlŠ¯>ZÁà	½a¼\XÏ»xqÑF3Ťó,O½r^Ö‘§càCóíÊž
-^,¯wV½´ÄÜžÀy-|ë¶XbÑ7WÂ&W+WŽ�8¡\ ´d,ÂÓÁÍÙîˇÊïäû¢)uYQB	â\
¨·w•‹dR%(+"©† )Ÿk.«nÑâƾ*BÜ`O�ñj¶Tþ<UK¢R(¹ç±�”8¨ëö9pº÷¾�9LÖ¦BÙPÊxÛf2WÚ‘âW‚Öâk׃�ÃS×·[‚h§¡–pw©ÙHoŠw…¯PÖÅ“|5q‡gþX�ŸŒv
-¡åÜœw1Õéx7P¡Ú]êv}µèÎF<&Í7„¨&¤8ŒzŒgb|(°“QåáàA8Í ÌÜ{êº}xpð©Çs¨ôsÖ	��ctÇÇ¥±²Ò—l_PÄ“*Õ";¬¾½
†’³à£!aûæ¿.aëP##'lÍ6ðþîr8>رeß{)è`�ì‘38"e sPÐFA½õ¯EèoÌZ;ýZñJQÃŒ>Í‹Ö1àåÁ°bÌj¤›K�¯JBÅ&8Ü
-X&\
�’„kÚzŒÌ@Å%dG	|È>B©Ç¡už‘\
džò"­߶`óÙ—’ÊsITì´ÝŸ‚C¼¾ÙˆÙÏ-è4‹Õ
-œç1k§—±¡ƒ!ä–�JAë·ãÔj]õf“—KÁ’ҪͶ.7%8ÀÒ#úú‡H€ò£ÛWy–	=s|¾?vePæ&gзï_Ì ÆV
-HSØøp�mGóÐÚ?$!ºüòXÔà–Js_!qI”CÈźm»Ò³(èÓ¸€‰³{Jz‘BæìBE�
aµðu¡tEÇo¢ î–9O*l…Àø)…—+˜A„ô/�0ãra
-O\:Æj
yý…¦5*Ö‡yOßwe½Â¶J
åaºg`5:Ͻ_ö§/<�É(ò;›÷ûA‘W|.½tE3±˜†2YpÿbéZ>Fèìàñt¹Ã§¾‰€©0+iÓ\èïz_àÆgÍÛqœÇ,�í›s°~7�¹LVô‹õ‘�Š¥Æ2ñ2pü–�
-:%“ó±�Î<�ï’gi&Exü¢§q™Q­å-Ò=s#®sø5h÷8ì¶å¢r}?öE×\g<¹.à`ܘӼ†j¢¦µä,8QÖÁ|�µßªèºê¡)½0~#¨…{l‚ýãUfR(�ìØ^>´Í¼)
-‚A¯ÀùB¤~ÀP�è‚Æ�%!ï‹.,s5¹põµ#Ô¶í*j,p‚àÞI­èÑÒ5'CÉ-X áä™»$�«nªr.,­_
ìAä]O8Œ4ˆòsv�°ˆ~Ýîè7‡˜K¤ºôï0kÀþ¹t¿ª
-Ï!®CW�;Jf¾�iBWôjÊÈŒCKD�7èÃ>*ØÖ)†13ϸïÂûQùµÀæE	Hñ£”Ì]‹¡Ç¹an Ÿÿé”2Íñ§Î‘ꜽ¶o¦Îä/P#¦òµPo¦LþOb4¯¹yC‰œôZ3ŸÜ‘&�+ŠXüпó(çÒØgfz‰s}' ÷�A0àŒ¾þa@$›Öy¾¬ÚÐ\#6×ø]ÁYŽpÐlÒ
-endobj
-1266 0 obj <<
-/Type /Page
-/Contents 1267 0 R
-/Resources 1265 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1256 0 R
->> endobj
-1268 0 obj <<
-/D [1266 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-390 0 obj <<
-/D [1266 0 R /XYZ 85.0394 690.2056 null]
->> endobj
-1269 0 obj <<
-/D [1266 0 R /XYZ 85.0394 665.1198 null]
->> endobj
-394 0 obj <<
-/D [1266 0 R /XYZ 85.0394 302.1184 null]
->> endobj
-1270 0 obj <<
-/D [1266 0 R /XYZ 85.0394 278.2032 null]
->> endobj
-1265 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F62 995 0 R /F39 863 0 R >>
-/XObject << /Im2 984 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1273 0 obj <<
-/Length 2998      
-/Filter /FlateDecode
->>
-stream
-xÚµ]sÜ6îÝ¿bßNžÉ*â—DMžÒÄIÝi�ÖñÍ=´}�we[“]É‘´u3�þ÷PKiµ±ïœNfBˆA
-BĹ1%”ÊXe"]d‰ŒM–“‰]à]f›TD‰%�s‡ñ
¤"¢+ø_F&
4“Lf‹ÔØXkw™Åç…ˆ�çŠpØ]u/7ñò|+o¸Ð"¸“§»»+�!ìuo�àôÔ€ehÒùÕ]IwJU€*
-ú|{ñ‘¾?ïÊö�Ûâ-®`³Í
Mnw›¾5ŽhvX�fW�×mü-1Éåeƒ ¬›¦ÝVõ-­ÿ=
-´õgS Rô´^un*‹v=+ÜSa`½fV»’é‘›Ì
-ÚF…{Š
-zE‰q¦êüV'ëÍôó®b\¦4H�$žâ\ê¬CFV�IBð"ý@ú ÷QŽØìâ�ˆ��€e”™ŒÜd&)$Þuù(yè㤿¦‡>NA˜EÇêü)~\—›æ�CSÊ+>áÝq¥¨ç8P6¶�
0e”-ÈuÎ?I%åBç"ÖV?)Ï€,ÃZ{$Ë(.C’‡i†´6–03`!—Û¢_ÝMyTàY
Ã~;Š�ð¨@�:Sé˜É#šY¬R%¼¼ë5)§‚T²e×Գªžtþ¦¦™mã½~u÷åªBs^¹HOŽj!¡•›0¸V|S©8nÑtžÍ¦È#î!%„À2k�öºqÏj´ÈøUZnÁ†2(7d®�»Œ¿7ÌÅÝ)ÝqÜÆ|Ü•‡v-As�V‡GÌÄ]ÆzŒ“jAÜUZGg˜-©¡¹'`ÊÝ�Ð&Ò¬¾ª1¡ÁŽò¡XùºëJ{Äí®óôû®ÜÜ�ÕhHâU¢Ó±Õ /W™t9T�Qùçý¦ZUý;©Ž5 ~Ý‹¨Œ…bE§P3dPp>÷…—!ÉÃ*($3Ùþä£nê2¨Á!~;&=ÅǘÌÈÖ¬3yÌ�X(’‡€€Ù;骩KRæ8Ñ?4”T°bÌL3C9 "¢iÑ($¿b’‡»jŤ]5…À5ï$»�ÑùÏdEÂHÈÄõ$çÛGkˆ 
-r
-Ž­†à†-ïœdûÉ5… Øº(ÿì	oëî�(
Ô5#„}¯
?ÖË9Å�™Ml䛺Üü´‘ȱʴ±x)5-1GèªEÊv
ˆÅMO-Vë{ž€[VÜwL쾟êIJ&ÉíÁ`E
+|}8ëŸíN‚êÔ|ç»»æ¡&ðèQÞ¡$rÔ1
-J„ò6FE¿†	øÃìÀ0á« �-LQ×QwÆFÒœ»‰¿®2™·I€‚‹¹oîæ"85yC:Ä%NSL6&ëR
ã#¢™êÃu±ÕLB¥‰—ÏŒ9í¥eò©´Ìèïk–fÖ5Í0cùpºæÓ}�4ƒb¦Ò²¡õ9á¾2caæ,ÌeLß2:ÄzpˆUKàº5±±c¼`ì­†›üÆ?é§îQ¤_÷‘)	•
þmˆµ™þ¥ûqòåKZ9‡8‘°ëp	t"ßÓÖÇió›´¯¾?» è¦j=³7(¢”žáŸ%|HßxúŽç fà<21§f44ßWã)µŸúûp¤&þ˜”d_¥ì¹Ì圄ý…W›#9‚o&ûç„-¾vRjgå½ëX™±xÁÒnyBN¾Õ£ÆóÏËM>SnòÉr“O•›œÊMüßrÿ˜ÜÔ3妞,7õT¹©Çä&Ÿ#7ù<¹MЇ˜ñ
Yx]ì7¸+èÉ•ßù¾¥`A^­è¯4=¿³’8þ‡XÊÄøgc3�údø‹§gÿuÚþ¯`°Ïn­<ÒñÏ@†ˆ0Sȹ±œû?c;dý¿?¿Évendstream
-endobj
-1272 0 obj <<
-/Type /Page
-/Contents 1273 0 R
-/Resources 1271 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1256 0 R
-/Annots [ 1276 0 R 1277 0 R ]
->> endobj
-1276 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [213.6732 554.0172 286.8984 566.0768]
-/Subtype /Link
-/A << /S /GoTo /D (rrset_ordering) >>
->> endobj
-1277 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [209.702 475.7236 283.4678 487.7833]
-/Subtype /Link
-/A << /S /GoTo /D (topology) >>
->> endobj
-1274 0 obj <<
-/D [1272 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-398 0 obj <<
-/D [1272 0 R /XYZ 56.6929 622.2509 null]
->> endobj
-1275 0 obj <<
-/D [1272 0 R /XYZ 56.6929 600.0717 null]
->> endobj
-1271 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R /F62 995 0 R /F63 998 0 R /F21 658 0 R >>
-/XObject << /Im2 984 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1280 0 obj <<
-/Length 2668      
-/Filter /FlateDecode
->>
-stream
-xÚÅ]sÛ¸ñÝ¿B“'ºsÂá›@òäË9©ozNë¨Óéäò@K´Ã9ŠTD)Ž›éïP DÙÎ%7Ï °Xì.ö±	…?61ŠPaå$·’(ÊÔd¾<¡“[˜{}ÂÌ4MS¨Ÿf'?¾ùÄ«¹žÌn\†PcØd¶x—½üëÙßgçW§S®h¦ÉéTišýtqù3ŽXl^¾¹|uñúŸWg§¹Ìfo.qøêüÕùÕùåËóÓ)3ŠÁz0YðêâoçØ{}uöë¯gW§ïg¿œœÏz^R~Ž‘�'ïÞÓÉØþå„a�šÜÁ%ÌZ>YžH%ˆ’BÄ‘úäíÉ?z„ɬ_:&?%Q†ç#äbL€Ê-`Ê	pö¡Ž´ÎnÚºnïªæ?ËÏÅrU‡¹»ª®±w[}
-cëSf²²èÚ¦¸Žp×å‡âSÕ®#ÆÐÙÄ=êv^DÚnƒ½¢Yì†:ì¶
¶‹
-·™oê{™·MŸå‰øŸ2F¬RÜ3Ó”›»vý{§(¸É.ÜJg•Ãªò¬«–U]¬qpÓ†Ö§ÄÃW{³7],HK×á@×®7ˆ·jp$ê�Î$±äs âªìVmÓ•qYÙl†|Ü–ëª4ÞøMÚå{ž!l”£ë¢]I“ÝŸn°hî±ãøqm�c(Z7²­ÿL„©r�²áf‘
�±Å¶gÃ}ôlôTøAãm�'n#ú³7φ
-löT
-—ÝÄ’óó²†!܉ƒLŠ
ŽtŲ`æ%ž!LË#ÇÙ
÷�)�4A¯i7ع.±u:T.ˆÃÞÎ&ÆêpçÄ‚yÜ°®ÜQkJ³/~{­H®„ÊôBx
qB}‘|O]øþï‹1¾<<ÝÛ×à$¸6¤^‚·ÉÂ8ÇÊ4a-„WW]$ñf½
-	JhµŒ¾-÷“gܵ͘KVò Î^QSÂw0`'J_J駤[œXcÌx²5í1NS”Èä€8ná¬åncä«r>¢œIU´»*Ä„EéÌý‘ÓÂ0ŒIX÷<ø[¥¥r	ÞÍë¢ëp#5ØHH]Yب‡HLr8'1nç€ñ›%1NS”^bâ˜r·±O×\´‘˜ Ö%ÏÈÈ{”Ì»ÍýªáÜÓ<êIJ™æD´óß�éã#Lsž-!¬ÿq®wÀC®tetÐÏí²¨šOZj•µß�ñã#Œ
h$ 9`üÙç–“Û!ç»Ð9Â='Ü�ú†ñ¹z§žvèp.\.¬ Ãu™«2ÁVüPuʲÐuö\9+-?Àˆ	qÝ-X”7D�°¤u_p'Óy4û³Ë�»meÔ]‚è�8ˆƒôúHZ•ý^~ò(m6¥Í¡-Dò>¤=D›~˜6¯�ÉF p—Â0=Lb†äÆ`a ×}DïøXØáÔ€¦ô6ò—²%p*x4ˆ�*ZtГîwè³�DP‘Õci«ËÛ"dz[öNz=Bœ1€A‰Ç•b`nûä*$ªÏ\µÈ‰Tà1%dÝ\XöãÒ�²î¡ùþ±U‘—…×t”\G
WèÆûÑ"25• ˆhæH|•‚È"&Ribrªð8A�>ãÅO¤ "Ÿ¢H¯—
I“Ë€dû—
˜öù¤Œ:	 iÚŽã÷ˆ†!ía¡ÙÚ¦Ëèݪº$i˜�Û•Ö|’ŠæÛÄínf·ÿÓQÆÇOܶȅ~ì](ÐY_ÍK_q€*•{ŸÍ÷¨h!èÚe„Á�ö"I.³Äžðóm2úsÅžJ2#;g„»™ßÏëjþ§I½H
-$>…<�k©Ó‹ÕÁKPîºÂX’+%®âŠâˆGüª
…§P¶}~¼¢yÙA )*Å@8pY!ArP—ØúLÛ÷ΰÁ\Àõž¹º	”�y»|†ãÉ^hŸ/F‹‚;(TÜP|%¬/>í×�\žê!v¥ëy±íÊXö¹O0»ÚžÎ“ªµçÐõÎŽšt_I
-"r]'"‡)”]e»ˆUó]f38n9¨
-‹Ùþ
-®ý‚�é8Ö6ÝöÆQëC§K½r‹— f†P¸ñÅ_ÔwÅ}7¬R·ýü¬/³œÅÊgR=ãÓ}MpeGüʾŠ_ÜìUˆ³6iáú(Ÿ\ÓÎòö*<‘ƒÕª,<-»÷~„¹¾ç
->2r'˜ï¥Æ Q
Ôeq“º*;rì݉sín¦Ory’Ad¶JMûr¸½jý5i_\±ç�û>þÒËSÏÖ›3è4%93pcgî‚Lü29	*�
¢�'ñ¼ËfðŸgçû’
œ’¹X
Θ[æ·ž|œ@t”Ö
-Júž×�üÀ�K>ù¹Ž&	Sñ4Å왂`––ŠrWø
-endobj
-1279 0 obj <<
-/Type /Page
-/Contents 1280 0 R
-/Resources 1278 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1256 0 R
-/Annots [ 1282 0 R ]
->> endobj
-1282 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [353.6787 560.2827 427.332 572.3423]
-/Subtype /Link
-/A << /S /GoTo /D (the_sortlist_statement) >>
->> endobj
-1281 0 obj <<
-/D [1279 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-402 0 obj <<
-/D [1279 0 R /XYZ 85.0394 630.8728 null]
->> endobj
-955 0 obj <<
-/D [1279 0 R /XYZ 85.0394 603.2815 null]
->> endobj
-1283 0 obj <<
-/D [1279 0 R /XYZ 85.0394 477.5928 null]
->> endobj
-1284 0 obj <<
-/D [1279 0 R /XYZ 85.0394 465.6376 null]
->> endobj
-406 0 obj <<
-/D [1279 0 R /XYZ 85.0394 128.2785 null]
->> endobj
-1285 0 obj <<
-/D [1279 0 R /XYZ 85.0394 104.5761 null]
->> endobj
-1278 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F39 863 0 R /F21 658 0 R /F53 962 0 R /F62 995 0 R /F63 998 0 R >>
-/XObject << /Im2 984 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1288 0 obj <<
-/Length 3669      
-/Filter /FlateDecode
->>
-stream
-xÚ¥ZIwã6¾ûWè6ô{‚•
-,îšSÛA�-©×pb©äÿßÊ7E]7=ÎR~Ý”^¹PÖA^ÅsX�³_/`ÁrB�`GÖôTí÷Kw%~»jZß?c­o¯Mv‚…õ8Eó�¯ÆOœ‰fÕ}ÀÛÕ€³ÀÏCpŸÞ‹ý©$3P“kIŒÍÕËx4二G‰+Jú2�”¬ÍÅËÓ'®…ùÇp¢Ö:/àsÙ{‘åÁ? pö=¥¢£


-O»j³õ`ŒkjÌ3¿3,"ìl«ºhŸ‘âLóØtU_]³ì±t–‰
	…Ö‚ïvÞf$Ú°±SF_D¥å7u0Ÿ§²ü‚%7ÙÀH’,*üIq£_Qö€ëeG.¯ìª^·MÓw3ES
-=�¢_š:q-Ì=R4UÄJ­Ç“ø2nQ½6«O‡;ԛɚ{üzM5èÐ6h¶Ã¦~WôXBYۀͿŸªp–ak°ƒîvæ*»~Â,ÈŽf5“Yd¹–À%ÒLÀ£ØlÊ#
-c…bì1jW¦«	3¹ZM’ 
špmøJiE”Ph5ÂP¹d(/hçñLÿñz�3ˆjÖ9ÏfQ¤
h‚FF$eÞ`W¿¯¡ÒZ�Lƒ²ßëYžðí‡_½m`G«á¦ÂÀëáÈ~S9až ¹�`ˆ„Í㦼•i0âÃq_à„ñvë5~Cø%;Ó¶Ì-áÆšÕPžMEdŸ[ˆ²×çàø¯К[bŒ¶ÞY¤Pìe0“–¡„xÌ—3ª‡5šÕ¶êŸ×ˆ°…Úؤ†Ð´3œ`l‘ka#`Sè
-Õ÷Õ¡J
qhNq”&Äø›}³	a^÷¥|r÷닱�äpñЯÂá€ë8Œ\)¶+ïÛ²Û­Ýö¾Á¹ø~‰ì¹ûöyΉ3ÊÉi._ÞBâZØÃȃòœ(1âh·x…f„ë-¦Ã
-˜G�ñÙ	^µ®ã~-³¿u!:3’X3
ÏîÊ]ñXyÕ
-€ã¿h÷
ñvUý€ô? •	‰Ç2ˆ ÛçÀ%ƒ¥
-Ò£'NåSV°:·O)\êÍuZ;=;W–2‘+Ä#OVh�’gûæÎ[%y›3Q nÀ$W9ë*>àÂ"Ú¢b¯ÏÂ]ºC’[T¦Íà&ûâp\ÚV‚l4m(̤åQ¸Þ[ûöùŒëÝØÓˆ]ŠÓ¶ƒŒKw©D×’Û—�zÀt§#“×Û¶îÖ§íqÝU”óô/nšÙçNLóÉÅ$x0pMÍ“-úœl)¶à:}ÕÅœÙ
„šØòóÛŸ�twòyà{t1�ù¥{]qÏ}é±KÐìßÎÞ‚™
-ŽˆŽêJÁ§]qˆ®ž\[ø—?Ä�I´Ê)óyød3®2Â�ÀW/ÅÍST	Û˜¾Oßz[ÁÂËé…/ÅãÃ3†#›4Ý££“¦DÉ;¸6$,&xgAÂôõK¦m`~ñ)�iN,Ó¯¼
¹.[âB`s¡¾Sþ¾\û‡ß~†oB®µ|y‰ka#|“‚
-4úSHU½ÙŸ¶!_í]Ð�ÒpéÌùÿ&
-; Q]Cím¯
-ÛXV€šP©'ùý'—„êdAŒS­2ð&]Þ‹dqœœ§“o�©¨êécÓÌþ|Ü�öwáO®Ëå·išþ!ñ—ÿ
-endobj
-1287 0 obj <<
-/Type /Page
-/Contents 1288 0 R
-/Resources 1286 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1256 0 R
-/Annots [ 1290 0 R 1291 0 R ]
->> endobj
-1290 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [297.8955 476.5924 347.2449 488.6521]
-/Subtype /Link
-/A << /S /GoTo /D (dynamic_update) >>
->> endobj
-1291 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [324.9335 169.1118 381.8296 181.1714]
-/Subtype /Link
-/A << /S /GoTo /D (zonefile_format) >>
->> endobj
-1289 0 obj <<
-/D [1287 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-1286 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R /F48 885 0 R /F62 995 0 R >>
-/XObject << /Im2 984 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1295 0 obj <<
-/Length 3537      
-/Filter /FlateDecode
->>
-stream
-xÚ­Zmoã6þž_áoç
-‹x–‰ÙæJÅ2Š•”žR_}ºúçÀ0hµC§ô§â4Š…Jf©¢4
“Zf‹AkgQ"…´,ø”–}/ÔrQW¦é»ÅÖì®y:_|Ù›Ýá
ib“]L¶ŸêF$:J¥ˆg¡
-ÜœÜ\à$�†¾u»Z™¥â�•¨¥Yæ`T±stT·EC…3G´3[‹†iÓ(�µrN`ååÉ /»u»¯K*×_“¦è‰´nŸ©°!ÓƒÚ[e%áñ¼h7ŽQÕЗl
-9}¼¥rR÷¸3Y
-hp[T«²7Göe`­¶+xÉÞ®ÁNF’HZ
P<›Òä5'4>WýšÈù”™4m³pKÞ¶
àr—Éü÷ÖZ ÔnË�äÄ
-¹"ÑnÒL†�÷¸y:NÉBzÈÃ
l¨Ç£k«Ûg:lp‡°
M
£: ú¾Ç½Fbµt�œtë¼sÂY›¼j€ÏÄrö
ùw9éi X‚Ã0³H0‘:8¼x2ž`(œÎ
Êz+¢3í³%ÂïĦ}ã!–köG¬�ƒÆ�««MåXµÍÈQÔ¤£§’šo}ëpIBvâiÅ	†¡eþÆ&Ðp°¬?£^΢Tå4õbôq¢cÎTèX‰”t¬„¶:FB c¥…7=htŒUÏ iiü~k…¤Çv�úÁbkG¹ñyC]«Í¶íŒëñx˜X%¨1Ž¸Æ8(4Ç�‹(Œ_ôÔq¬¢$… �–�…¨.Œèûôb¬tº*úN„e}µ<,JSçg
 W¸u™|qê¡ÓùÜ£½Tq”AD6šœT
àh§çœÏÑQRIç�Æ °h›²³TvØ?345%!0è!¡d=šiaDÛ˜®ËWÖ®µ?�œÓa�7ÍB�ü	•ªsq,AcغŒ·¾hÊ(„Š2–` ©
-§
˜´ðþBÃ
-‡Ö¶3û²]ôívQ›'S/ÊaŸ–yD`[R€Iiá�USN(IèHhîÝÌŠ³àtç'àL�C\9ëÇOÑòÓ!�¶ñ8¦£€A.­Á	üšezŒíòò]O%«+l¦j 2¨=U晚1‡èŒ¹”Áª,@«Ý�Úv«î§r÷°ÿ¹»žqÅ~‚è“l‘gÖŒ?‡	
#q&0ÃõzEŠsnAÆ2X_‡o�
-�¶ò©Óä•mÄl†åz=¯«bMl)*ÏÀ�`³l�# p]’õo¨ÍÊY€P¡]D„Q—D,�¯›ýönêÀÐÊ[î·ÃÄdN>ÓBŒ‰ËD¡ÃªnsŸ±Åi¤%×cW°&ÃC·¶£J··*È
-ˆCÑ1'Î'eªO¶Â̓—	ç«Bd‚£PžD¡圧¹X¯€°×Ýi0—)2ŸF²ã•Ã%/T*JµÌ^ñ ×^è{¡¬k.½mŽÜ¢.ÉåËûN�lLB꘩“™É	“ä(‚­õž<xaÜ¿
´�¼ÚȺŽI’Á¡hÕò¼ä…)�”N2·õ^ Knh¯ÆNˆ“L;!ØàMi,Çîô‡¼ÆÆ—ã)†9œüÓŽ,éŽóž×�iû¥œ%Ü$S14Çp¢ëª	úÒ‘vñ£“ ÿ‰]$–ñVªÆÞ³¤ô_(mT¡<Š*{÷æEÂÜŸÐc¹ol8lïì|궻j“[sÀÊ~‡74ÂÚ]x¥Òà¾Ei
-7Ýk`#Ä�Ëa�êãRâ3‘8¡-‚+—œm©jç„/„…EÞõT!½àtŒ®El�¢ßÃ}ðý»g�Í¢T!æÚQéxS)²×à
lK¤">±qâƒøöíÔ�§'"ã…±™Œ˜b'ÇÄÿífŠé—Ñ.ìuí†^A��÷\Uyyq$âT¼<ýÐkbþ1è1H[!f	à@OÏo߇¥§`O°—œÀž>�=}{úu؃¨;S‰‡�Û÷ѧ›ûßÜO%IQ¿ú£ ‘ç,ù3‘‡•øby'DæéÉ+×=á£
‘ñ
-–Iðª¸*SOÑû:·Ù¦} +Bk¯7íã‚kt„a
£—‘Ÿ§�À$-�‚kO¨ÝxGCxÆS7Æîö±-žKÀœˆ"qØ…ƒëVw-
­š¢Þ—æâ#€�âDbÀ²Pbh'‰�~ûÓSB$k‚D–AmèXGµ¨ÙU«Æ”è:oèùÜsâóºj>¿ÄÓÞâ<‘½Ä¡ ív1µºÇ¼øì®ÄF†¿WÇJûæsÓ>7g#»É·X‡BBøgy,BƒIKÄÒ€7mlR…ÕjéúÒÇâ
°�$÷;ìS»›’ò@óµêìK”ik…Â&ôS	(ãF�…zðÀ©Ç™íI¶{&ð*oSöôbÿÒ@L·³VÇClPìñU›',n5½Ó}Ns<ÜÒc§»Qþ²Â*]zž‘q„¿
-œï៳�ÿùLJÁ뎎 tÓy‚dI”
-_œPö<{ʉeAÒ¡'Dÿ/ä×}endstream
-endobj
-1294 0 obj <<
-/Type /Page
-/Contents 1295 0 R
-/Resources 1293 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1303 0 R
-/Annots [ 1301 0 R ]
->> endobj
-1301 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [84.0431 462.4692 144.9365 474.5288]
-/Subtype /Link
-/A << /S /GoTo /D (view_statement_grammar) >>
->> endobj
-1296 0 obj <<
-/D [1294 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-410 0 obj <<
-/D [1294 0 R /XYZ 85.0394 535.1829 null]
->> endobj
-1300 0 obj <<
-/D [1294 0 R /XYZ 85.0394 508.8634 null]
->> endobj
-414 0 obj <<
-/D [1294 0 R /XYZ 85.0394 198.9245 null]
->> endobj
-1302 0 obj <<
-/D [1294 0 R /XYZ 85.0394 172.1168 null]
->> endobj
-1293 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F11 1299 0 R /F39 863 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1307 0 obj <<
-/Length 1767      
-/Filter /FlateDecode
->>
-stream
-xÚ½š]sÚ8†ïùL¯ÌLQõaÉÖîmH—Î6íRöªí…¦x†Ø“d³¿~e$áƒ#¤x:³“É K¯õžçÈ’ebõG†\ !©&2F>\Þ
ðð‡j{? F3¶¢1T½]Þ\³d(‘TkÐWŠpš’ábõ5ˆ¢‘ê
Gï>Ý\ÏÞÿ=ŸŒ’8ZÌ>݌ƔãèzöçT—ÞÏ'?Næ£1I9‰Þý1ù¼˜Îu“0}¼�Ý\é©?.t:Ÿ^OçÓ›wÓÑ÷ŇÁtqb�¼³äçàëw<\)쌘LùðQ`D¤¤Ã»AÌâ1c¶f;ø2øëÔ!h=žêÌÁˆ2A	¤Ì•@.‘`ª©Iàb“k¦åý~?"i”—]±-jSªÖú3¿ÛžtñߪÌk],êß.¦�)w'�aªcÔ$Q'D+@_MÔß0Iº¦‰ê�¤ÔojEÏMÏR•Ä¥äç¦*ͳ›ñäêjŽ&óÏ#I£ÉEpÚIBà@å
·ª ¸Ï´Á¡)¡ÉËÉ1FœÉÐL*¹UÉ}¦-y×ÔMM)WóXÈÓ‹£4&ÒOU—éOª½×ôDÿÌÔIfJ"	}9¼ ˆÄq€*¼Uá}¦-|×Ô
MIÒ>&(ŽE€*¼Uá}¦-|×Ô
MIÚž”Äêæå‡*¼Uá}¦-|×Ô
M‰ì�)Âœˆ
-”JXV¡êrÆNªPƼ¦§Œ=3ufìÌô
-]7´/#I3wS¨ò�[U�ÜgÚ’wMÝäÐ4EÓ>ìq‚bÉOPåa·ª »Ï´e١©ìÇ®öÛ‰LPåa·ª »Ï´e١é¤;N–2ðì
-²ûL[ö®©›š¾½ÈÞ\FHb!†c"U¢7SóÊ�ðÓ+CG™~Ó¨ëëüpÈn·æ(;hÉac*ŠüQ—¶ùC¾5”+]W•[Ó}¶Ûé¢:·jO­�n­›–Û¬6U³¤WEÝø¯´"wDÌO7¤X!$9×+ 	�ñ¨(7ù¾8{b"ZÏ©îtcµ;UYë¦b­+å)ªºÍ‹j++]¹jÃSµ6<Õ`ÃSµõ._ß0¦Öû˜Fm +L™I£Bg˜G‹füŒOõ�ï÷ŪèçûÁ¾%n)œoˆA¬ö%ñk]~ªîÍ{æ¬<Óꃓ�ÎYuh{Ð¥ìР&ŒÈج«½yWýOv·ÛæÇWÓo®™<ŸN	SA=Nõ�ß3>¦w¬mÆÑ+ôêwÝÅÙäŸ÷¡o³&	RT	‡SÜ�HTå}¤1Íj¥UÇËRUì³òGnÊËfLŽ­+]a/—×Íð%­S½©î·F“mµ&[5׉äÑ&{0fºAõY›
-{	Y¯³ø×:ˆ¶9�ñXÇÐîë\]U‚²hVêšÝ>[Še®�›Âœ¢¦jžíÍA3Y›Ï²ó¦p{Ô›K·©Xfµ)=‡�.Ýeå“.ý¼WaÛ`nó#�V¬rèÀ/1åzŸÕ‡ý(�î—‡ûÓ˜%j¼ò}“,} /-U(³»ÜÔ¥þT]×öœ�èl™×ÍKXô¥Òõ:bxÒZeÇžž™R�-÷lj¼,²­#ˆÇÆWæùêxi4}T®‰{kfË*ßm«';1�d37YY×T8³šŒšŸyl«Ìœ’=f¦,kð¬KiTM†
-endobj
-1306 0 obj <<
-/Type /Page
-/Contents 1307 0 R
-/Resources 1305 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1303 0 R
->> endobj
-1308 0 obj <<
-/D [1306 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-1305 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F14 685 0 R /F39 863 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1311 0 obj <<
-/Length 2674      
-/Filter /FlateDecode
->>
-stream
-xÚÍÙnÛHòÝ_¡·¥�ˆÓ'Ù=ûä$vÖÁÄžu<À“y EÊ&–"‘ò1_¿U}‘”écã0�.VWWW×ÕU-Ó�t¦dL¸³T‹X*gËõ
™]ÁÜÇêhžh1¤zwqðÓ1Og:Ö	Kf«
/¥èì"ÿ=zÿ¯Ã_/ŽÎç&I”Äó…LHôîäôƒÅh;¼?;=>ùøÛùá<ÑÅÉÙ©EŸ��¾?š/¨’Ö3Çá‘Ç'¿Yèãùáçχçó?.>]„³ÏK	ǃ|;øý2ËáØŸH̵’³[ø 1ÕšÍÖBòX
-Î=¦:ørðïÀp0k–Né/Ð,„Š/Ù–²Xk)¦·%``šŠ'xÙux9Я³êÍ›$,N	Λ—ñ¥±–’¡}5‰S
-³)ç1A˜÷lu,A‘Ž’Xr‚Š³ù"¡ÑüÏ¢£}s
-vмOt"ë*´�1ç<ä4¸§!*D¬¨HfC¾vTÛóa§Zêñþ_6Ų\�Cq®£Û묳�ÈÀu¶.ܼq"„²Í¦ÈÜ<šGcrÀKÀÍÀ‡ê"·˜/g‡Ã©ecF7¹j#çÚþ‰n�7xÐÉʸö‚ëXA†‡qmÃî1ãé0¶x¢¯„°"k1 X  ÿ¸ö|¹ 
èÒavm‘?ð\oopµXÊ„=íCªÇ�"PõN±lê.[v½BÇŒ=·} šØäRČ켂)ἂ)y‰Ú©
ÐNm€ón�°MXÒ§F±ç8eÜ¢ŸêÝ'W�c2žn!¨n
îÏ.^ã_1þ÷}n
-úBˆ+-�Ï—.ëʶ+—.Œ�K{ê$–/ä…AeŠQ¿·ö"^u±Í:/ÿ¥óÇ-WÈ åº¬@�ÐG¹r¹sÞ\7(s(*ËeVùÓxwϺîªúJ.�5géÓ'Êwë�OVWeÝúÖ]»ð²CUÖÅ[þ·øyÂ2aGev|óæÍ´	>„ÉW"‰N9ô³Zhø Ó&zp Ul½[_šR`SJÀ¸q^[›¡u“nÌì
-2ËÔ=à¹�(ªÖ�:0}ùÏŠžÆZéK^òô%-3
-ötï�ïûV
žéD
-…Iÿ�g
-×Þû
-n_Út†su{;}Üóó‡FP¸§	t¨C«¾ÎSÐ'9Qjô¾óB–~ÅãÎGHRÒçœê^¢¤M'ÛbUl·öúzÞûeÁûFï”÷Þ†HkY:3AªGO@\ýŒÛÛð°˜Åä=jìÜ>a ÁÉ_§Í¿Ô@Ø'œ«gD5ô&©´Ù¡¾ÛnÛ¢{avPƒ»	`“\ÜÙl ”·‚cûp÷ê‹+|´= Î&ûÕíú�<ë²Çí5TÄ�µ—ø¡ö’,N.›ÓDÅ,ñµÐ]Þàý÷2ƒ1)ƒÁFƒá†Î`Ž
ÆdâËOÿóáìóáÉéTzí	ÃNüw$¦bõèÛVo!b.…6XeeµÛ/$l7À. \Køb±²cK2ä:ÄïÅ’´¹ŽÛž?­
-endobj
-1310 0 obj <<
-/Type /Page
-/Contents 1311 0 R
-/Resources 1309 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1303 0 R
->> endobj
-1312 0 obj <<
-/D [1310 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-418 0 obj <<
-/D [1310 0 R /XYZ 85.0394 494.8753 null]
->> endobj
-1193 0 obj <<
-/D [1310 0 R /XYZ 85.0394 472.5641 null]
->> endobj
-1313 0 obj <<
-/D [1310 0 R /XYZ 85.0394 284.6288 null]
->> endobj
-1314 0 obj <<
-/D [1310 0 R /XYZ 85.0394 272.6736 null]
->> endobj
-1309 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F62 995 0 R /F21 658 0 R >>
-/XObject << /Im2 984 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1317 0 obj <<
-/Length 3317      
-/Filter /FlateDecode
->>
-stream
-xÚ¥ZYoä6~÷¯è·m#†‡(‰Ø§ÉÄ“8H&»y˜²Zm«££ÃvgÿüV±HmÙžl`À"‹W©Î¯¨b£#i6±	™æBo²êŒonaìû3áæ~R0ŸõíõÙ7ïU¼1ÌD2Ú\ïg{%Œ'‰Ø\ï>m#&Ù9ìÀ·ï~ùðþòû_¯ÞžÇáöúò—ç�Ô|ûþò§j}õöçŸß^�"Ñbûÿº¾¸¢¡Èíñíå‡ïˆbèñ̦Wï/®.>¼»8ÿ|ýãÙÅõø.ó÷\á‹üqöé3ßìàµ<ãL™Do Ã™0Fnª³P+¦C¥<¥<ûxöïqÃÙ¨]º&¿�&¤V À�))^8–Žàp¬k†1K$�ON
7LÀ?ØRÂÌ„ËQ'RÌt"„faobmX¤¤²:ÙµÍá�ïP60]ͦƒTbÆpλ¾ËAœa¼­‡ê&o±m›=Ñþò¶È;êì›–wEvG{¿ºËÛûÜ�ïŠ.k°'’-q
-¯ÀóÝ¢’ÇB£J�Ž²Û}ÑÔiY:ŠS76Ñ0V4+C�ïÔRÌižy{Á¹SÖÀJë¶~™_¶&!Å%ø8N
-–ˆZ
6Wb««E…)
-úG!W¾|Æ=§Ü=ËÙνÜ(‹@DPBħʹ¾:DO
-ŒÐ‘®ÒOr
-½3ÓŠöi%BÐÜ÷T¹Ôˆ£ž$BBé†êàŒ2¢¼i'
T�ñÙËÛû
-@ŒoVÊ*ú´«��_¡¬Hûâk‚
XWºŒ™Ë‚o  ¡ 梖…Ò¦Ü版9KB³d" à¶ÂKÕÕ‹QD°0âúÅ("´ü.ŒÔ&®˜ð±‚‡#åÐt]�üØž…'øN‡<+öGGt	R a:95 ápðP¥,ªâÄÉG»Õ'z·>ݸ…éÌ{oÜì¡[—ªÔPv*y¥¥��“lWü¹&W¨°¹Òñ(z¨ÎtdÔópjB(ÛO
Fœ•Ï¬Š²/ô«¢&ÿgùŸ†h§‘hBLD[&‹2ܹ#~YB$í¹sàä·s
!¿¿Öw3ô«ÊâX%µÔzºàsùü—³²ÈÖöI˜†÷pÓæ�Š
ð<ÁLH²f‚

-LÐX$|>‡½8èvzÈËrI¡õ‚�uˆ´!
-eÇ=]�—–aNÂâ&½TÛš‡Ñ@[D'¹mnHznH0‚HóÑFí
¦œXƒ�£Õñ´²íúiÏÜU‡Ú!G˜ã
HÎÙf‡ “«Ö2rnæ8�l¼ßt¢jv!z³	}jB
-¡ðü�­°e­Û^ƒfYžïü-’æi§sí6¥3ÊÜ_®Ú83ñŽáØ�¾ŠòìíVдh‰+w3	Ô”#(ÃO`tñ!¢…ƒ+S�#01[s
-`Ÿ¡ÜõÆ­¢AÆ¢”ÚÞ-Ì)Þ	*_q‘Ó$6-€±7祵arœu<8;öï²°cÌ«öª’ûµoa!@½£^J�®JÉ£¦Û~»jOOà�X :¯Š‰YxRÝa÷N»ÜÍDSþšƒA¡eîOqÕß|sú¤°bÉxÖ	b<u-�a…»Ç0¶
¨dN^û-÷M	U鸟¿H®ª*õ9ÐçÅæà¯g®	VœÍ…ŠÿZ¸~òí
->+Vá·ô@ØŸä;ÈC{³‰ä”ŸÒ_œµ7+6¶@ï¾Èl8�9îÅüÈôp(é÷vÃCÚ w�îS�˜NR•Ø>¹ovZ´=ùÜHº¸–><êY$€ŽÏ<Ê,"
-g2”¾JjËïê/AÀTb“¨Y¾TXðS °'8ùCËÅVꤣ¡slï–©ž_ôIo¸fÔÚÁEKí§iî’+d< °Pó,XaÖ.GkU>}GWí!
à~GÕL©§O©±ûŽ:ÿNó±åÑ
µý¥R›"ì[‘ðÉWT¿Gû‡/€7ÚOßÚ|_<–yý™þkßN*fðþuñnŸhÆMs‹šØtó¥i¿`¤Æî?éñyÍbÜâCÛÜ»<(÷í«{¬ýV
-$„?pZ‰–|éßþÕô#³âi’Èõ°ë~¢<SVkáÓTv®"¹Âúÿ
-endobj
-1316 0 obj <<
-/Type /Page
-/Contents 1317 0 R
-/Resources 1315 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1303 0 R
->> endobj
-1318 0 obj <<
-/D [1316 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-422 0 obj <<
-/D [1316 0 R /XYZ 56.6929 644.4755 null]
->> endobj
-930 0 obj <<
-/D [1316 0 R /XYZ 56.6929 619.6136 null]
->> endobj
-426 0 obj <<
-/D [1316 0 R /XYZ 56.6929 131.4228 null]
->> endobj
-1319 0 obj <<
-/D [1316 0 R /XYZ 56.6929 107.0033 null]
->> endobj
-1315 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1322 0 obj <<
-/Length 3405      
-/Filter /FlateDecode
->>
-stream
-xÚµk“Û¶ñûýŠû¨ëXñ"�É''>§Î4Nê\:í8O¤N¬%R©;_Úü÷îb|ïOG,€ÅîbŸ
-9cäG‘WÍ—¬]óý²)/Tw—Åá!bˆa—}~6‚	í!«šuqh¾hõr]vYKÀ_cS«®Š%L¸	ÿˆ®nÞtKÄxÓ‡˜þTÜòºÿÐ_ÓÊêj„àýý#Q
zßþãùœ6õñ°*zN˽þ˜åyÇ!¢©‹”L
`ŠR­ŒGô?d"—¦Éé
-¥!ö2R1|Ã@{l¤ìÐq¥„#Çðmv] HƼÆߨ44êUN§)»+DÓòžs^IÙbvÙ·Åœ~�3qZ…9¼ó”qr	à`S)'¶K»L%%�
-âÕ¦XS˜F:«‚‚�fÍÓÛùì*5‘]~ö˜‰B¸2*Øs½ç°—U¿Q@!Ørž
-/ €Ð˜ŽUÇ@Dó’ê_ŒöåjCÍ
óvÈ¡ë8tœôÃø`¥ôØÊÃöuû5´tpß0Ô¯²ƒ¬WÏ¥bß>œ3Êe7k$‹fS·H%$¡Ùö&ÛtlßÔ‡Oh9IÂù!ÀöÇÞʞđ�$î>wne¤•2Ovç:•!ID©Í:J£;#zÜâRçF~’ù*ùߟ´O¼?y†¬Ïº=—Ñ»y”=@™6“Ž³(2šjÃéA£óÊò:�‡VAŽÌ*ηpÖeíï•
-ýŒ4;T`¨L<¹OªÀ’îZlüÐyw; É%ÖM"&Ôµñœ,_O"ˆe­_^ýDcôü‰ .Û-iŽe9ˆª-éÊ
-È´l64èÙÒq
Á3çà£@kàt½
9x1JÏ°p0£]<ÐŒ‰#%ÑÝuF iÆÕuä3,��€rüÁÖÁ±y·º-^L}YŸvŒû<¼ž¥áÊnp¨}Ì´ËÐâkèˆ1Ù£¬z[Ò¢«"ÿ<gš‚¥³å�>'˜1SpWª«G:¥*˜©PÁƒbpû\îŽ;ìÈÎ*¶Y/ÿJDëÉ€¡ÌR¨ÎÙbõRù›O7±*¬Š¬TGJÅ3íLMJI¦&%¿ý
-‡Ïrf¬Õ�³"»—@¯±PPuOBГP$bÇ?_–`Œè½5Ô—x/�“i‘¯<
-}¼…
ÿÔˆ
ÿf»¾¥¢þÎÙÛµ}8MC¾
-
é°‘1’`›ˆƒoŸí}—#àw�–á,:KÙ‡ïÂîùbP,ç¾ï‹»ï¾økÂþSK�FÊZÙ}(8y¸H"+]ˆò_B˜)åÝg‡wIÿÝíúendstream
-endobj
-1321 0 obj <<
-/Type /Page
-/Contents 1322 0 R
-/Resources 1320 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1303 0 R
->> endobj
-1323 0 obj <<
-/D [1321 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-430 0 obj <<
-/D [1321 0 R /XYZ 85.0394 575.952 null]
->> endobj
-1214 0 obj <<
-/D [1321 0 R /XYZ 85.0394 545.1349 null]
->> endobj
-1320 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F21 658 0 R /F23 682 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1326 0 obj <<
-/Length 3013      
-/Filter /FlateDecode
->>
-stream
-xÚÅZKsÛ8¾ûWè¶r•…Ń
-F�ÇMfAo*
-�P,–6xÅó(Ńyë,C¶w¦ÒCGÄÚºnmÖ�ùŽt±(�Â˼Xùye;ÿpÏRr'Épϳ­wçQ/‹#&#žô¼‘yÏÒ‚ñ$}W¹_pEË`¯oÙãØZqÃÈ�©T”Ló%¸Ù¨¢žt,R‹Ú½Â"C`”Î5�X0€Þ±Uæ%Ð(Yb­ÆY#qÖI¨××?1Æ´+»`YŽXAHfÛcZf¨uá #òÐ
¿ã'l,³J042Gl:€
„ÀX9rëxÃScÀÎ/�Ž“.Ш£Ê ^óSÇGrpAp8íäüÆ5¿¹¾üp6<k™�ûvo˜Å Ò»ÝjB�«ÎE†Ïºã¸‡ë,ìÛÆSð¶áV„2,6F÷örpÕ5£žÙ¡4oAx¸ËÜVÌ´N×ß\c·;üEÀa᦬3ÝïXòé?½ ¢3ãû>«jêp·Ÿ›ZÔO¯çèŠ;�ÑÉZ8Øœ·�¸¦NkBG•¯Š´ÞS?vYº–ÜKç`ð»ÊŠl>¸¤Ç}EfЉßLB?&�½‹:î²V8@Bá»Óí6+–aP�õD&ÓMVUé*óOÏ�r¼ï®=uTË]¾ÊA¡m;×M³»§E€íŒØqGBÚÁß÷95–}·4Z2¼C õ‚0´�bÊ5:p|¾®ïÊýê¨÷›ÄÆj—n6éŽðæ
oÇ®º¼X›g°[3.Œ`7JM×ëò¡¢¶llöë:ß®ý”	
-
ÊŠ¤ï¨Z±öV¬öÛm¹«=	oü.	²á•=FX•ûÝ"»Fáf‘I`
è©£r•ñq¹³{3"ÚÉ7qܳ<zF¤)`nQÕÈx…ÞË_î#êr㻌ŸRRÀ.2?d¹$›U^¦óMx1÷ÒÜ
AFOàªTb
-
-ÞQtƒ(0Õk{Th
-©S,å	EW’
Ùÿu‡ �r!�é¹fUï\2ŠÃB%õ©vwüc9ïçÃq¯—ë~>3ƾ|ñå þÞÉ}~ÿaÌÖ°ŸÈ2kxû]Eò—ù•Êò–ÚÐm�_ñîñŒÆúÑÓŒ#Â:?<¡C‰:aR6Ÿ:UyiySÌ«èñÝÇëë‹·Ô¦"ZýHOTY(ëŠQ"Ü™WAá¹ãØ]8ÅldÕD!Æ#ÃyšS6ãgÝ	cTn(·Ï)a3³»
tM8$]á‡t2ŒznÒˆNº*Ày0é¬0ÉÓwöÆÞ� {Ó“³0üvj¯Rq_®ÃDì ±ÝÏ×ù‚Ú®2ÑfjÊ•/ð§(‹Yº¯ïJX/Eø§nÿCñf½oEùP¸”MOç{¿À«"llî§:gqèI
-Oeý\j´&Ã'ŸÜC«çålÓöÃN^Xi_Pµ‹�
Ô§ÂÝëÚø#Bm�OïÒŠz晫…j÷!	Ïoµojkn¢—Òc½;µSÑôŠi®îíàw8«&YiÝni@˜p—.Ã~NÅ”¶$¦÷é:_v&~Ж¬yŸcZ·ÇíoÚ›~­±*×M…1­
p¶µGÈ7 í×nóæ
-8�Lu¹(×g
0Vx•ÝmÎ,«©Ñ½Iáî5Q£¶>ªA›´W»ëÏ$­=±#ÑÑð(i)¢ðñ>Ïþ(ÿ&HŒ—õmåL¥4°R=°ÔgHV«êK—§.âMZ/îf‹u;iø¼ûÁ¼Ðâ«ñuí
-ØÈŒBÇ?fÕ×r÷µ(GsÑÍœyèß
<åGÆÿDR�Èöµ‰ƒÁœ±ÿ^“ã¿�°DÞøßþϦöß¾¢˜)kå8Ý”
-endobj
-1325 0 obj <<
-/Type /Page
-/Contents 1326 0 R
-/Resources 1324 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1303 0 R
-/Annots [ 1328 0 R 1329 0 R 1332 0 R ]
->> endobj
-1328 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [87.6538 683.0228 137.7628 695.0824]
-/Subtype /Link
-/A << /S /GoTo /D (tsig) >>
->> endobj
-1329 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [370.941 574.3534 439.613 586.4131]
-/Subtype /Link
-/A << /S /GoTo /D (zone_transfers) >>
->> endobj
-1332 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [432.8521 316.5051 481.8988 328.5648]
-/Subtype /Link
-/A << /S /GoTo /D (DNSSEC) >>
->> endobj
-1327 0 obj <<
-/D [1325 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-434 0 obj <<
-/D [1325 0 R /XYZ 56.6929 474.1474 null]
->> endobj
-1330 0 obj <<
-/D [1325 0 R /XYZ 56.6929 446.055 null]
->> endobj
-438 0 obj <<
-/D [1325 0 R /XYZ 56.6929 366.5019 null]
->> endobj
-1331 0 obj <<
-/D [1325 0 R /XYZ 56.6929 335.6 null]
->> endobj
-442 0 obj <<
-/D [1325 0 R /XYZ 56.6929 180.4336 null]
->> endobj
-1304 0 obj <<
-/D [1325 0 R /XYZ 56.6929 155.306 null]
->> endobj
-1324 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F39 863 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1335 0 obj <<
-/Length 2914      
-/Filter /FlateDecode
->>
-stream
-xÚ­ZKsÛ8¾ûW¨rYºÊb@€`sr'㩉'ëxv«vf4Y¬P¤F¤ìx·æ¿o7àC†#e6¥6�¯_ ¢ƒ_4“IÈ„Šg™ŠÃ„EɬXŸ°ÙŒ½?‰ìœ¹›4Ïz}sòò�Èf*T)Og7Ë/2)£ÙÍâ×àÍço.®Oç<aAžÎ“”¯/¯ÞR�¢Ç›Ÿ¯Þ]¾ÿåúü4‹ƒ›ËŸ¯¨ûúâÝÅõÅÕ›‹Óy$“Þç–Ã3/¼»ü邨÷×ç>œ_Ÿþ~óãÉÅM¿—ñ~#&p#œüú;›-`Û?ž°P(™Ì ÁÂH)>[ŸÄ‰“X×S�|:ùGÏp4j^õé/2L$Ï|
-T>&*LF�¾Â=¼|Ç£Y…*I8Ne³y,C%$7“P1œƒ–cÁ}©H	Ÿº¼Ók]wÔ|«cŒ×eW65õäõ‚ˆ_ÚüNÛ…ÄH$X‡'a–ÂAã:7+ÝK3LŠ,®p»8Ç,ÿ”�ÃTJi'µcÉÒ lé™ÓcÓ<èírWa+–:ïN£`·=�d ©¯YÒL‡¤”�”Ý*·<+ÝM¹ÖùÚ¾Ýêí½ÞÚÁº}èiz¼½úDÄ;½}$rQ.qù¥6RÌqƒp"TQ¦fóþd`k°©
-_Êd°Ð]/ÊúŽšFëð|X5D˜mÃ3o?Ã$€¶P"¸ì¦ƒ›|ەŮʷŽí®Õ¤ —ÍÖN_o*£Ñ~¹vS•–íût·ÛXÆe·jv�Ù
-s{ «]å÷Ä Ñ5ôÜžÂÊ7ë]Õ•°µH�mØs’a¬xb8]äÅÊ@ƒPÉ
Ä$!�#bDÄAµ˺Åf„'‡½}¤ 8Ð
bM‡Q
ö ÚM^Ø~ReUÑ”[;Öj]uû8Y§ÝÝ‚&§+U	Ò�æ±J‚s‹´ät!4t'³`�wÅ
-w�
ÄŸ”°€»±ah”K+;;©mÈpؾüh_^,ÈBÚ–Þœ°îœåN<Cq[#|}Ïi
-	¶ËD:K“ŒÇǸM*cî>§9ï9ÎÇ,ŸzD!³0Q0ÚOC1ÍÆö…¤„,ƒ¨óÝ„ì92æQÈR8ä‰�UÙv>P§a–EùÍr8C €ÿÖzBB–2gFÎ	q&‰’>Œµ	„€(“:	Š*w‚–
�0XCb¡[ð'9ì@°™©c°aG6l<6T&ýÊÏ‚M„"|–‚úÓ(ãß
l–ã|ÌÒ¶4éhá¯`-
eœeßOÆžã
cˆµOo"äsXË
-é^ª2=
-_‰”}e¡—9FÚ	†M|>L�áè˜#ÇÆšW&ÕQc³ÒI„HƒËºë37e£²
-ÀèŠÏ6V+Šû||[…ø›IÈ�ÔžcÁøWµÀŒã$ùíI|…÷ž(w­Z»¹.ÿìË7!Md£�M´øY?¶Ï$žIìà÷°*Ážáâ`cTÔÜ—4ˆT(
-þ
-¦nÃ>µTCWÝSV06ªë8%-úcÓú—@SÜ:*Xä]N}äÈ�¸µCwà l—	[ðô²SN½g¾š”*]8ý%ÇZ÷Ì‚bY	6°­ó
-齋
ìûØ\âÖ]†ØjÖ–ÍxaB
ŒÊfo}û!¯Í
�°W™tl(ð™†Ó
�e=Lô
-q’ÿê™ÕÍ0aÞÚÂvæÕNYZææðÎF
-ûóê)`ëQ*€qª/8ŒØs¸*¶bÅî$•É
èI›ˆâ¾cœÎ(FZs…)8•MC�Xå÷z‚f«vî$/1ÒØwýÛ�'êžá$:>²ô»~e/¢ ¨Øöôà ÓŠl­Ú䎆ÚØLE/t]ؾÆÞÿ!×ÆquŽÀ¿ð½PÕÅü(ÃdÑ“tÁÆC!#Ì8â©ùçiÁÜ-H
-(0ˆžÎ-íÓ�—Gñxøòj:
vk½°|¯šÎ®n͉¥¶J1‹Õs÷úý ôzg2”’’ÜoÖÉ‚ß±>!i]y[çC.À†!.¯œï¦= —ÜE³Þ”•^ÌÝðµ‹ùo'�ú¼ÔÃír4R?Œ�j=%²€3fGxÆ8V¾¼ø’¨Î¡@h
�öŽZHÚ ÇIk|¼+Þ_ó÷Ù9ô
W~øE¦hÈ:qU7¸ë˜]pª6Á�+¸=·\�*@t0÷H‘Ø‘ŠÜ1`×åUHÄyýèMÙâ"€S–ñAeA�©ž~°KL¼.ßÔ4`´gˆfC#•¾×õaHMŠzï¶öNGIÓD÷'og·åÂ"cáRë,Ì>ug&«‘ŒB,<ñÊž(ºàCÅË12³!B�Ñ�-KùœŠ2H;˜R¾o-ÀÛ–@¹�+Y¿{éÄ<pQ{K#ÃAµe ¿@ÚT”�·FePè+•yÊ·£c€5ô‘eöŽ½uÙ3.Ê£7ˆ¹P‚ˆ
-k¿®�úr«¿¶Ï¿{.‰a×"d2ÞÛ69»�÷Â%û/¨ý_£,‘@•™ì¼/_Ò”c|Hµ«fW-ˆ¶5’øEÅŽ7µjÝ=4ÛÏ£Ðñ䎥/$HóˆXh~/å+ê O¸æ[*~0dñDº�[{…�íp¡bäÕÛû²°
´Ñ§BN$À°é•ÖòE—‡óu{¼L¹]¨APt¶s8„™oe‡,ï}°ÃܾPn5ûÕŽ>“šõèÀn§ü§Û†¬­Û?>˜7Ae$Éa´€}h‡Œ–zå-BËj�ùÜÉ.n_¼²–ëãÿçƒýqˆ}Ô»öxÔðm2·'`1—î½%hkø¥srœ›­¾/›];œû7ÚĈ£áZ/ͧ¨cíÀ©d²µcÐ_7ß~
-)‡oKÓ¬�AáÂ!L[¡ÌK²}Éû?³<ý="c¢endstream
-endobj
-1334 0 obj <<
-/Type /Page
-/Contents 1335 0 R
-/Resources 1333 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1338 0 R
->> endobj
-1336 0 obj <<
-/D [1334 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-446 0 obj <<
-/D [1334 0 R /XYZ 85.0394 731.1791 null]
->> endobj
-1337 0 obj <<
-/D [1334 0 R /XYZ 85.0394 700.243 null]
->> endobj
-1333 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F21 658 0 R /F23 682 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1341 0 obj <<
-/Length 1132      
-/Filter /FlateDecode
->>
-stream
-xÚÍXÝsâ6ç¯ðä	:#Åò·§O¹”¤¹éåZŽ>Ñ£Ø‚¨ñ×I"@Êýï•-ÛØ�’™X+ë§ß®v×»Bš.H³èø†¯¹¾mÙZ÷tm.ç®{¨|T/�æ[ŸÆ½ó+ÓÕ|è;†£�g
,ꞇ´q8é;Ѐ‰ ÷/¿Þ^Ý\ÿ9º¸V|óõv
-d©ôé¶ÔÌTÍLÙ¢r°	„ðîcð$© ³6<ͦ9ï3K™¨åù Ü¡Ü`ò†5’fÅ®³‰ƒ<‚Üã¸ü¥Ûú³d3Ã4ÚÐy’2"e¨µÓ©¯ãÕ»Â-i˜…J¶&|š²i’vV�&‚Ìë
-˜ŸŠ)ú®ëh
ù6fE™b�kBÓ>Ì<9MšÎ.Mφ¦Üýƒhúžáî=«¼Æ\–j²l 
käq:O8¢¡üªßöT%Õ#=]Vø˜dÔ8™E™Ér衈·7Çÿé ÁÖGA ]ÇB´XÈ0!e$iUàfX<Eu‡åÏ„åÅ›tc„ˆ;Ø[�ÿ¨+p5m½w�Ï#üD—ù{ÊÐÓëü“{ô1½ƒñZï
-endobj
-1340 0 obj <<
-/Type /Page
-/Contents 1341 0 R
-/Resources 1339 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1338 0 R
->> endobj
-1342 0 obj <<
-/D [1340 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-450 0 obj <<
-/D [1340 0 R /XYZ 56.6929 672.4064 null]
->> endobj
-1234 0 obj <<
-/D [1340 0 R /XYZ 56.6929 645.0635 null]
->> endobj
-1339 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F21 658 0 R /F23 682 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1345 0 obj <<
-/Length 1074      
-/Filter /FlateDecode
->>
-stream
-xÚåX]“Ú6}çWø:#­%Y¶5yÚlÙ-™†´„<Q†ñ‚`Õ›H¢òß+
-vjÀµíê@átRl÷â‰q”u½Ë.ÝÄ`óU€d”â"ÂP„<k)-E4:zà8PšËd8Ærè¬û/›ÚšÏôBϦ�öá¡"ÞßñTFAxCà9�ƒ5ƒ8
-ç‹¡�JâP†Ã¥Êî¿g—ü©˜ô‚Á@æ}“XêUrÓÝø„pù½ôòã	Äl(Ác ÎsH:Z�'à—ŠH›?Ø"2çªË^íÌ,8Ô
©¾¯¶1¬
-•Xœ"}ç+Ÿg-Óè®À7ýß1žÙï“-Mf™a<J¼ä’DÓñ#—'(;Z‘r	ÄÀÌ„öÅS}9%-ƧP:
-–"Ë]ígÒJeVµ>_ǹ˜8…H^¤Èc�`�$è9ÄI�~IQÈ<ϵ
-ýëx>´eü’=3¨Tñ-žà·HÕ}M•y»f‹Ì¨ÒTéyT±M &+•458IÖÚ›pe#J�åzPZŒDží¾M`ìAäø¸4
-¦Šƒ�ò®&âaŸMàã‚Þõ ñ°³Ë;ô"ï �@â0v˜åá�_ÏŸ·˜�Aœf�%~y‰#”´ÙE_�°oØ;tpvV16é€äCÉÕSº¸Ÿ½k�RÂDËù)�S!6M™†Z€lË9×!/\Æ ŠM@ëð0À2”.»4“¾äßX>Nz“ Y‡O/
-–†vúa Ô*õJל2X=Ÿä#žL:ø®L‹]æžä!IeRاOW®ÿÄû_Ab“ZÏZ“²G‹a Â…E±ä¯R¾››ìÚŒóÙOB>æ‘æ¸OgTª³s©ÎhKg¥§�ûÄÂ0~ߦ\Î7çd©âJõLñÕ*$Í?ÞLÉ}3ãòZôJArJýƒ®\ÒþŒeéÏUÌ�[†]­xBÿ‘:äÊ	óv‚¯X‡\;YÞªCÐÿ¸¹*ݲCWBarRZrDjþ¹IÈ®O«Svø>^�µbR8k%¶}̼%©ÄD—m3_�ܾ¦þ/
$þÇendstream
-endobj
-1344 0 obj <<
-/Type /Page
-/Contents 1345 0 R
-/Resources 1343 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1338 0 R
->> endobj
-1346 0 obj <<
-/D [1344 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-1343 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1349 0 obj <<
-/Length 1975      
-/Filter /FlateDecode
->>
-stream
-xÚ­X_sÛ8÷§ð£<S±¤Dý›<¥Ý¤›�mv/õ¾\6Ó¡m:Ö­,yE¹®ïn¿û
)Ë©ÒK¯7~ ‚ ü
-É.’ér;áÓGX{7N&ôBáPêÍ|òú:Φ+Ò(�Î×]9ãy.¦óÕ}�²ˆÍ@Þþr{}óî·»ËY&ƒùÍ/·³0Jxp}óóQïî.ß¿¿¼›…"ODðöÇË_çWw´”:onn NAÃ3Jï®®¯î®nß^Íæ?M®æý]†÷<Æ‹ü9¹àÓ\û§	gq‘'ÓL8EM·™Ä,‘qì9ÕäÃäo½ÂÁªÝ:ê?ÁY§Ñ˜‹�sÎRª²¤`iÅÖ�÷³0å<تª»VÕf­ÛÐ4ûv©iñ¨ÍǦýX74ÀkÃÙ¡¬H’h¨èŸM­CÓ©®4]¹4OÐôjVªSeœ
¦kËúñk›Åpó¶¬ÃV¯[m6aWn�’z¿]èöÅlÕçÿƒkI׿I…øÒŽoUqnžêÊp«Lç7}- a³Bpy®ê¯
-r*Ê‹@Ñܤ—ÍîHT³&¡Î«ÀrOä&ýšƒ
-ê´H
-Þ‰·ÒkÍÊ+Š¾oFÝåÝ[À¬FSM‰¾s3ÐëeQ�Äı¯
-Ί
- \@.päÆøteعp‚Ë�ªõŠ&T€P¶�Ø)°À]Çgq·>ÚV6–±Ëĉß×!w¡×=ÎpÍŒ#dY!hõ
!>ŒS­•­IV�9m§í¾°¯ä‰ û¶®
-ì¡@õ†àf8@Ó5†‡PUEª4£.#dbÄEB¯dÌ#g[Õ@¦8Î)9pæl
-endobj
-1348 0 obj <<
-/Type /Page
-/Contents 1349 0 R
-/Resources 1347 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1338 0 R
->> endobj
-1350 0 obj <<
-/D [1348 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-454 0 obj <<
-/D [1348 0 R /XYZ 56.6929 493.3884 null]
->> endobj
-1351 0 obj <<
-/D [1348 0 R /XYZ 56.6929 463.2745 null]
->> endobj
-458 0 obj <<
-/D [1348 0 R /XYZ 56.6929 463.2745 null]
->> endobj
-1352 0 obj <<
-/D [1348 0 R /XYZ 56.6929 438.8631 null]
->> endobj
-1353 0 obj <<
-/D [1348 0 R /XYZ 56.6929 438.8631 null]
->> endobj
-1354 0 obj <<
-/D [1348 0 R /XYZ 56.6929 426.9079 null]
->> endobj
-1347 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F21 658 0 R /F23 682 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1357 0 obj <<
-/Length 3410      
-/Filter /FlateDecode
->>
-stream
-xÚ¥ÙnãFòÝ_¡·Ð€Åé“öÉ™x&v<Y�»@’Z¢,&©ˆ”=Ê×o]MQ�Iv`]¬¾ë®j鉂?=É|¬lî&iîb¯´ŸÌÖjò}ï/´Œ™†AÓá¨o.Þ¼³é$�óÄ$“‡Å`­,VY¦'óŸ¢·ß_ÿøps95^EI|9õ‰Š¾½½ûŽ197o?Þ½»}ÿïûëËÔE·ï}óîæþæîíÍåTg^Ã|#+¼2áÝí?ozýáÃõýå/?\Ü<ôwÞW+‹ùýâ§_Ôd×þáBÅ6Ïüä>T¬óÜLÖÎÛØ;kfuñéâ_ý‚ƒ^š:F?g²Ø'9@&Ëc¯�{}_ÞCÁ¾šÄÆJ¡�÷�j­ŸL¦^¹8ÏR}àJ>àŠvyl’®ìó8±Æ[Ún÷ˆ´yó‡ÁI§Îàþ8èHiSPýÑÔ%ãªVúªuµ*¶ÜÝ5Œ,¤oU<—‡‰WæQùyVn:Ñ-�ªŽn/u•›U5+ºRöhêÕÏ
-§‚[ǹ÷†Ž×-aukòèLž5ÔÎ[îlÜYðçºh»rË(¾b«°ÅüxF¿~Yw¯}˜‡rè’è“Ðñôl8�¯tT„©F©¨n:ÁòwÛõœG̹cSl;îÃs †Î�ˆïî>ý£Gí7X½_tQÝnˆo7å¬úY)3;>+«(±
T†÷ñCõ¬Ö›U¹†û]ÕÔñØM‰@îl��fE͸ǒ»¶œ3wCL¹Ñ©�Ë‚^
-P—<ÒG‹f˨§ÕN–aN»N�«Âh’E«¤*M©;F롧
-.Hú{¬ìIg&KE�q±y<kêň®ƒ9HÁ&ÈP�gkmô°¬dý][<ÉI
-�=êU¨Î[™>kv«9ƒO%­v	M¨—ª[†qõtì "¤U&MøVzºjËXæ/Bx0ìdÚ
"Xtštð$yÈHd°c„8Ì8p¿Ÿ Ù.iYĬ«Ï¨‚v
ÜxIûÁf2âçE,qÏ:ÂWüYê��èÞW(º­¼¬FÅ} ÀV¡¶ÊR–ö±&ªPØça#ö œ›žd†Íÿ0áˆP½£DhY´0›FŽ(ò©Üá^~ ó´îÏ©mT¬VÜ/.Îõ1ƒ
-¼lÏÌŽ<:#tÈ¡§XµÍWÙ³�§�·ä͆¾¯û«zAD$ßÉ«þN^�Ýéϼ£Êzï {G
-ƒ†ç2Œ!fŽjÛ;öó	xÞã
t·ˆ
-N0LîÃͧP¾yW<¢	p&çOjŒy¬ŒÊ{ºõÊÅ.ÍOïD1¡q2/¯Ä+;Hø0·3Î�»ìE/²m;ö<8¹kh¸A¥õÆ&b↲8ÐÏÕ¬äY*Wc’ô¸ë¸®Â|CˆÌ–N$ÂÑI¨Ú$·Ô1hÔÛ€”žVHm8“òš1$Håi°
‡Q/H%µÅþŒ�ÄËùäÿµpgD|edrwR
.õïDP2áõPGÁ
-,M¼Û ”ÏÕlDpµn8wx“œhF4ÜâÁ©H¨s>íéºýˆºô§ÂÄ…V
-bê†ÛÇ]µê¦\½=e¡U|ŽìøŠÝhäW)ùÁjd—Äü�ÃŒWí†ÑY¬ûÚÓ”Nb›åÉÄ`j™©Tˆ°*Ÿ¨4<
/?'&DÃÝ�÷&„�´‰BËE„Ø5›¨¬C¹„u�%è9Ý��Sìd1vÙ°x½Øm·½„¨aÖ?¯üùÓzX|KˆŸ(òuÑÛ�®¸ëîæ
Ÿ.¯¸î÷ñþ=:¤˜û®ëð¸S·/\^Ô!Æ"¡¬ô·z†-Jy>Âh½Ùuã‘Çmåg|_£Ê9äŒ!ħžö@é­�¢Á¬Ïû÷Œo!,”ÁY¦Ž=ÜñɪËëÜ�—Ö¹�îþûÝÇ×·w1£™³Í›R†ÐkÍádAä2öÑáJ±8ªüL´×¼Ú˜XrUŽŸç
-dü°þŒ“Žó×°ãiúú¥ˆe¨Ó_g'¦çðxþÅ×x˜ãsüÿM
-Ç€Äänå IåÊSxÃ?{Ë·
-_ØrÌú3ç:=üâ(x?4Ð.�ÓTs
¿
-½ã:X{@ЛÐLä6¾>Ü>|#KþÈ¿²QÄ5æ‚þ2šè¶;>Àù/
-`c¿G‚¡ðWÿúéðÓ0Ð8›eæ`�¤3M9Þ1ÕgþÅf±ÏL:rôÿ
^܉endstream
-endobj
-1356 0 obj <<
-/Type /Page
-/Contents 1357 0 R
-/Resources 1355 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1338 0 R
->> endobj
-1358 0 obj <<
-/D [1356 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-462 0 obj <<
-/D [1356 0 R /XYZ 85.0394 167.2075 null]
->> endobj
-1359 0 obj <<
-/D [1356 0 R /XYZ 85.0394 139.8789 null]
->> endobj
-1355 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R /F21 658 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1362 0 obj <<
-/Length 3030      
-/Filter /FlateDecode
->>
-stream
-xÚµ[Ksã6¾ûW¨ö²rU„àI‚GgâÉ:•ØY�sØMr $x̲D*$5Žóë·Á)‚¤@§â­)—@à#ú�
 Áa
-ÿØBE$Jx²ˆIej±Ù_ÐÅghûî‚9̪­ú¨o.¾þ(âEB’ˆG‹‡Ç^_šP­ÙâaûË2"œ\BtùáîöãÍw?ß_]Ærùpsw{¹âŠ.?Þüp�¥ïî¯~üñêþrÅ´bËÿºúéáú›"×Ç77·ßbM‚?g:½¿þx}}ûáúò·‡ï/®:[úö2*¬!¿_üò]lÁìï/(‰V‹x „%	_ì/¤DI!ÚšÝŧ‹wöZ›W'ýÇ(á"âäbÊ�*!‘€&ëÀ«¼¨ŸL	viµüñæÁärk¾˜]qØ›¼Æ–¬ÂßOiQå¦þ
-±L±ö‡«[|ïP^2½,êbSì°iÓÔ˜´6[×SŽP�Šûl»bIL+Éäò¿EîZ¶i�"ø±pfNŸMš[߃VŒ‘D)ÞX³68@ÕÁl²_)å�T¨xÉê',Y¹ð&�+éù&
7Sm]j»
rÜ}B”çAÁ‰ˆaµÙ¥(�0Öƒ­WDë(Z¬DL„U¹$H)mÍ�îuVäÕˆKŒÄŒE‹(fDqynì´ê£pèÙÄÐw(«PºÛ/+ÿìñu(œ1A˜¤qXz‡šß÷cš0Î}ñŸŒ9�HSØšjSf�7°¢xœðnÊ¥vƒ04bÈyM¡¥gùÐNàá±`ž�ØX~^`á¾gq‡Ÿ±xÜ/š¼9gùÀ""‡*	e	Íg¾CÍ(2îÍ*BÎ’MB ‰ &[ [‹:�ÓïGSNp�*dÞ¡&¤û\~°Høâß“l�C®ÅD¸&�XìÙäšÃÏX<î÷í\“	‰%ãa×w¨Eƽ…¹FXòt<õ*Àµu¦ºLóê–¶!Ý8…à‹dP~‡šPÀ£›
õÑPƒ÷¤[ߎ�ð¬�q–q‚R+™x¦×ágŒ÷ûvÆE1‘BŠ°÷;Ôœ"£Þ‚ŒS1l…ša\užqê4RÇìXÌ8¼Á ÒH†¥w¨	ñ>ß žë8öåÿ=¾%ßNVÙƉ¦’��o°‰¢TúnÅ·?cò¸ß¿°–ÂVWƒÎAßw¨Eƽ…Ù&#¢c®gØÖCØÖ¢¬D¡Õ¡Øe›‰Õ‚0lñÃâ;Ô„|Ÿnfz,|>uÛë
-ýŸâϯœËOÙþ°s$„1:âþŸn·(|v0ÆÀ‹+ÁhCäá
-p•†=\_ÓPkñ3¦�û�¤8`L+8‚Jˆ¼aw¨9EF½…iʼni2G«*@«5œþ+8q½¤å6Ë?�IMápT¤CMhâ,Ž`úfýâÙÀ ‰M£JôùØ&)
-s‰%�c6æ*À§uØÎn7px§rá\DYX|šïqK0"4Tyòßç :¶b <昽<›È… ÃQó4”iñ3F�û};Ób
g!ÂÎïPsŠŒzò�k
JɾõQçùÖ¡N#•åµù\fõøj'Uaù-hB¾O8J¸Ž„¯À{Î3cÈ8F
\VÁ˜D”iÏÔàÕ�ÃÏX=î÷/0Z4aïw¨9EF½…§l~žñÆõP
Ƶ¨ÓPUÙz7•k³ç”ó°ø5!ßß'BµP¾ï¹€öÌ^¢“$	\(�ó,
^8üŒÍã~ßηˆ«™±ïP3ŠŒ{óÍÞ+Âz4÷*À·Õl<MiOª«ªHWu½G8N”T"¬@‡šÐÀg\L”=ã{*¼ã&rNÃñQ°@Œ“0¸òl
Æ8‡Ÿ±zÜï_ˆq”ÄKÂîïPsŠŒzrŽ%’D±šÉôQç9סzV#ž«çéœk¢dFƒ5¡‚G:ɉTt Ãû,¬S–Äk8~EqàR^’
-ÄMúÏÖ5	[¨ŽëÊü~ÄÏf“ž–×]†ÃÃ!­š1n<Àç£ýð¶U£«ãš×f*ÿ6ò:ǤcÿÒþ%}|4»q�²Ì“ä.£×
-M§qì¯!Y/Ÿm>Öoï“Áh{
-ùG¹®ÿ1}¦uwf?=–¢ýVzNþyÉ––óÔ]ªY‰ùjoöEùŠ�è…íj½K!v×øØjê,k.Üb—:æÞ$m`…iå5Ò(iNî‘ïö:}vNòtà-¼b½sB.¿¤»#¦Xʼn*¶áPTvgm°){ÄÚt»ÍlxOwXß(r¹-3wMO6%ÙT¯�ɱ6êϘ––'Öº€%Ý]šýî½I³å§b?àƆ*=}ðÑ	=ÙnZÒmvÇíôçØøjfcÕúxZ° Ü^”äf¢ËÖ€>§×¯^*•œû@_("§oàÏ�äßþxÿô?¤ýüÜ.�Û܇¶¹TÊ:5æãÓ}å?Vý…endstream
-endobj
-1361 0 obj <<
-/Type /Page
-/Contents 1362 0 R
-/Resources 1360 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1338 0 R
-/Annots [ 1365 0 R 1366 0 R 1367 0 R 1368 0 R 1369 0 R 1370 0 R 1371 0 R 1372 0 R 1373 0 R 1374 0 R 1375 0 R 1376 0 R ]
->> endobj
-1365 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [284.2769 667.7189 352.9489 679.7785]
-/Subtype /Link
-/A << /S /GoTo /D (access_control) >>
->> endobj
-1366 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [282.0654 636.5559 350.7374 648.6156]
-/Subtype /Link
-/A << /S /GoTo /D (access_control) >>
->> endobj
-1367 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [299.7586 605.393 368.4306 617.4526]
-/Subtype /Link
-/A << /S /GoTo /D (access_control) >>
->> endobj
-1368 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [292.0084 574.23 360.6804 586.2897]
-/Subtype /Link
-/A << /S /GoTo /D (access_control) >>
->> endobj
-1369 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [330.7921 543.0671 399.4641 555.1267]
-/Subtype /Link
-/A << /S /GoTo /D (dynamic_update_policies) >>
->> endobj
-1370 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [401.5962 511.9042 470.2682 523.9638]
-/Subtype /Link
-/A << /S /GoTo /D (access_control) >>
->> endobj
-1371 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [257.6971 346.6843 326.3691 358.744]
-/Subtype /Link
-/A << /S /GoTo /D (boolean_options) >>
->> endobj
-1372 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [310.7975 315.5214 379.4695 327.581]
-/Subtype /Link
-/A << /S /GoTo /D (boolean_options) >>
->> endobj
-1373 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [308.6055 284.3584 377.2775 296.4181]
-/Subtype /Link
-/A << /S /GoTo /D (boolean_options) >>
->> endobj
-1374 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [294.1999 253.1955 362.8719 265.2551]
-/Subtype /Link
-/A << /S /GoTo /D (boolean_options) >>
->> endobj
-1375 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [303.0862 222.0326 371.7582 234.0922]
-/Subtype /Link
-/A << /S /GoTo /D (boolean_options) >>
->> endobj
-1376 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [332.9347 190.8696 401.6067 202.9292]
-/Subtype /Link
-/A << /S /GoTo /D (boolean_options) >>
->> endobj
-1363 0 obj <<
-/D [1361 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-466 0 obj <<
-/D [1361 0 R /XYZ 56.6929 726.6924 null]
->> endobj
-1364 0 obj <<
-/D [1361 0 R /XYZ 56.6929 700.1172 null]
->> endobj
-1360 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F39 863 0 R /F21 658 0 R /F48 885 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1379 0 obj <<
-/Length 2951      
-/Filter /FlateDecode
->>
-stream
-xÚµ[ÙrÜ6}×WôÛ´ªÒìË£ãÈ¥&vFVj¦*ÎÕÍ–SdO/R”¯Ÿbi® <qÊåj8Ä]pp
\Pd�áYh�03|¡G±X?^àÅ=´}A<f@«6êÛÛ‹¿¿cja�‘T.n·­¾4ÂZ“Åíæ—åÛ¼ùéöêærE^Jt¹/¿½~ÿ�«1îçí‡÷﮿ÿùæÍ¥âËÛëï]õÍÕ»«›«÷o¯.WDïSßÃÄï®ÿyåJßß¼ùñÇ77—¿ÞþpqumiÛK0³†ü÷â—_ñbfÿp�3Z,žá
#b]<^pÁ�àŒ…šòâãÅ¿b‡­ÖæÕ1ÿq¡‘ \.V
-+½Lɘ—ÊzySdåi×7–ŽQtÑîq 7¢F³–`BÒÖÄŽä�yî~|ð…M~Xï‹Ý±¨+WQo­b=3ŒB˜r*tõï	e1	2¬¨ú&R‰WFuLt�ûû…+Ü´Œ�øc‡ý:c×g³,‰D¤¯£
-af¼Q3Š{³Š 
¯=y†A¢s;ƒüò fxò2¿Ï¬é«º*_<m’Âf(¼Ã1I�Q¸+ý¶a–‘ËO³ìޖŲѣ©Ív»²ÈîáX»ß‡¢::`Vm\Õáxºs¥?ê*?@ á\-¯·¾5÷xè¡¡!×m:0ƒ'ÒóðÄ
¹J2tv˜o.W+;-*¯Z0Êw²ž‹²ôF”¯ù]n»‚€°ÑÚNPd„ M¯Çý%ÑË<;æÇÂìà~‹­ÿ=ú__ï;¶¥0=»cé&ïËÎÏ^«Ü$»¤„A4Œ¤éÕFMó+¢¬YÛzÿœí7bQ‚„"&-8¢F$wƇJ$„êŽè�ËÇ<«Šê~{*í3o\jë›�³7p¶éÁºÝVeîÇéo‡f“ïS‡c³Zñ†ÁÃî†-•'L˜YýHÄ�&ŠxÐÄI¯Í:;r/+ªXÖõg¤NïÚ5n³¢tœ¢† Âér*Ûó=Œ¾ì_À¶L<_¡²oœmt³
-ïóã1¾RÕ®2«ÏÐ%,ÍßØ
-¹|~(Êq$µfÞ:˜àt8Žy¡Y^ƒžëSéågeY?{�\MUï³ÒUw4¶Õ®.L0ª(lS$Î ~‚ùfzŠ¨Û6$ø%èïA-ö[çö'
-{W™ßØYlYß»–OXàßêÓ¾ÊJ(’P‰ié{mÆÝVn^@@±öÊî6°>;vÁžY1¡ºär”�dyýŸw7ÈÁžK²üÎ=÷SÜC,k(qpŽB2ÐÆUÆÞÖ@$Øèåi}ì¿àì·UÍd:7‘¥·Ðá‚u¶áîÅØíòÊÓ?QÊÝäb¦5ŠœR$…	!…Ùåk;+ÎoU9»jĸ‰S÷&�7Æ-¦æ�³dzâÀ©G¨Ù‰ÓB%&N@u&Îñq·òîìOn�’tF‰ˆÑ¢ã6.Q¬§Fœ>.ùPRmêõé1¯âö±n�Ó
-ÿ{>�k '#xy‰¸™‚šIOsÍ�4š§=ÝFM{:¢yâN½Q§í¤àˆ‘Ü
NQ*LWô¿ëÐai
-kß6;•GWëuûÛÁ=:xÞ¶¡´nö"ͯ_v7ye�%Xø3´tzmVûzhµtŸ’ñ\|”1Ý985�á”FÂ~�OTp‰!pHëOT(ìjÕ°æö!¬”ñ0b�jëì®ÌãÌ.ç„+$%Ý?f»=M
˜óªo£àH_° Ì9”ÙS>f�€ ÍÊŸ§Ø³RK&fØÜB%ØPÎÎßWÍR´Í}ü(óÕ0ãA”¶vó´&5¢J‡ÞÀjƒ•îêòç’::ŽÜ´E=5ŒDL)5™æaZ#n4í�HóDüŒùÃ~§Ò<ª¯6ì‚ÎÉqˆ¨E†½%Ó<ëš©¶P	Ô蘛rœ…°k†ýZZ“ˆQ¥ËB{.µÃÐÖåë¤SõYkš`!„›‹k[“d¡ÇϘ?ì÷õ,ä°wfZ¦Ç!¢fö–d!SÙu IÂhšƒ
46êÓqÀAÍ—B&õˆ ¡"]»
ÓÑä/"`Ûž¾Vh"Í4��=žm›Sð´õƒ^_Ï?	-3C0iú=¥™Ça÷FùL"¦�Jp/ ¦£Å(ùlåŒ*5¢K—~I¥zÊüEËpÛ¤~´inÅôãà4%:V'ùçñ3öûýb¤ˆJ�C
-êܾœ•ÉÎJ[Ãp7¦ƒß»-éæ¾Û‘Â
×4‰1¬áffQn�ö �ZŽ0l‡c±ÞÓÁÁ‰Ú£cJz
Åwˆ,줅ֶüëíÈW	pX³aæÿù&!|ô°j®~¡|þásžïÂ'ÞàÌ7ÕÖÞ®zòB…cvóuCq8ÞÐÒöÚwýàj×Y¿oh~7§Ç]¾qtWiŒ{Wpí´ÿÈͱB\ËÜÏ#ÓJ¹÷—8á‰øÆ&·ÀªŸÐŽ,‹®9_ÒMRŽð²Ä3q³�š&]D5f÷«§¬,6Åñee#Òþi$ß­Rh•T#¢FôèžD€tX×Qäë¬×“æó0”‘ÌÃP
-ûô¶)3y˜?cû°ß×/Üö;@p¯H�BDÍh2ì-¹p˜
XÏebÚ¨
Ê}
Ñ:7êÓ~=¼Ì6Ïg”ˆ¨-ºÁìÅ¢§Æס߄1=
FpM�l¥{Säøˇý¾þŒ™½
L�@
-ýžÆ™rrÙûG¤Á.ûÓ?pþã
-®³´qßa‰45*(eW¬¯¹`Ž¾T�¨þ?탄kendstream
-endobj
-1378 0 obj <<
-/Type /Page
-/Contents 1379 0 R
-/Resources 1377 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1392 0 R
-/Annots [ 1381 0 R 1382 0 R 1383 0 R 1384 0 R 1385 0 R 1386 0 R 1387 0 R 1388 0 R 1389 0 R 1390 0 R 1391 0 R ]
->> endobj
-1381 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [259.4835 736.902 328.1555 748.9617]
-/Subtype /Link
-/A << /S /GoTo /D (boolean_options) >>
->> endobj
-1382 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [387.5019 437.0578 456.1739 449.1174]
-/Subtype /Link
-/A << /S /GoTo /D (zone_transfers) >>
->> endobj
-1383 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [381.9629 406.178 450.6349 418.2377]
-/Subtype /Link
-/A << /S /GoTo /D (zone_transfers) >>
->> endobj
-1384 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [398.5803 375.2983 467.2523 387.358]
-/Subtype /Link
-/A << /S /GoTo /D (zone_transfers) >>
->> endobj
-1385 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [393.0412 344.4186 461.7132 356.4782]
-/Subtype /Link
-/A << /S /GoTo /D (zone_transfers) >>
->> endobj
-1386 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [255.0796 313.5389 323.7516 325.5985]
-/Subtype /Link
-/A << /S /GoTo /D (boolean_options) >>
->> endobj
-1387 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [311.5276 282.6591 385.1809 294.7188]
-/Subtype /Link
-/A << /S /GoTo /D (tuning) >>
->> endobj
-1388 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [381.2254 154.1545 454.8788 166.2141]
-/Subtype /Link
-/A << /S /GoTo /D (tuning) >>
->> endobj
-1389 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [335.4973 123.2747 404.1693 135.3344]
-/Subtype /Link
-/A << /S /GoTo /D (zone_transfers) >>
->> endobj
-1390 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [363.1733 92.395 431.8453 104.4547]
-/Subtype /Link
-/A << /S /GoTo /D (zone_transfers) >>
->> endobj
-1391 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [365.365 61.5153 434.037 73.5749]
-/Subtype /Link
-/A << /S /GoTo /D (zone_transfers) >>
->> endobj
-1380 0 obj <<
-/D [1378 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-1377 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F48 885 0 R /F39 863 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1395 0 obj <<
-/Length 3132      
-/Filter /FlateDecode
->>
-stream
-xÚµZÝsÛ¸÷_¡Gy&b
 �ö)—8©¯=çêø¦ÓÉå�‘(‹�DêDÊŽnúÇw‚¤H‘î\:™˜ °\ìÇo?@‘Ïüã3‘	Í,62PŒ«ÙrwÅf�°öþŠ;šEM´hSýðpõ§w"ž™ÀDa4{X·xé€iÍg«Oó(ƒkàÀæo>ܽ»}ÿËýëëXÎn?Ü]/BÅæïnÿ~C£÷÷¯úéõýõ‚kÅçoþúú燛{ZŠ�nïÞÒŒ¡Ë¦÷7ïnîoîÞÜ\~øñêæÁëÒÖ—3�Šüvõé3›­@í¯X ŒV³g¸a
7&œí®¤�’BÔ3Û«�Wÿð[«öÑ!ûI¥Ê,š…ÃFæAÌ9ÐÄ’ƒŒ¦1rȇŒ\S¡‘“mµ¨I^®ÓÃ5×óEYËtñ�ëÏA\!á±ö.=Y<Õ€0¢%Å„`º+ÍÇ4%/T7X¥åò�í«¬Èi¢X£`gª™8`¡4 ´Ng‚p‡îÑ,?W[D
-äk
-úÐâáqFƒû–
<ý„
ú|É
-wÌ‹*[Ÿ.a�ƒƒ§v¯‰vïø;„U‹îöß'	ö”8Û;‚zÂaÇKP�
-h%Ǩ‰è
-ã ÆUÏÝÐ�…Ø3Œû»¦š�¤ÏmcÊ
-ô}:ºIµÎÏq G�œÄºŠ�/ý„	ú|/¥<Þ‘Ð@k
-‚NÒ¢Ü#fŸÒíéšsN¸
oBíÔ²´7F„ô
-äaXCÄB½P?ÛŒG¼Ü&Ǽ'X<._KZ�â Lvõjr¢Aâh ÐáÍ÷¤ÄSVÝÊSz(AGw‡Â+"2 ámEW+GöÈiXƒËšAC˜°Htá³Àk—•¥x‹#¸[A“䧶µ—…½®|ìåVceùY
-E Ö+zÌ+_ †/G‰d¡9óK(Ä<+隧Ïnaã0cè‚h¥
bÀ=¶#}3Œž<]€å³<uÔT•¥)¶Ä¸
-äqeM(4øP‡Ý×RmÇê€ÒÐúŠû´˜Øȇ5b1O¿%ˆó’æ):`ÚG¯i.¡[—þÒÎ&øDA½Ô2%²dµrz•D�¹=ò¢rx
-6vñDmÓ§Í1X$3—:êë¦xîä�V&ÇP¶¥*kšùmQ|-ÿL&æ¬õ5�Ö1½¿ÂŒs½ˆ �¶€†ÿ¡ä–�(%á¨I8x‡é¼:íÓæŽFŸè‚K%
?_èÂ[¢ÜP•‚Ðlt‹¢¦2aˆ»8ö•)–*{ʶé#³ÒóùÒ=šÐ¥Éìðè&qÏ•Çå IPÚ
-•“:J
é²¢1%6ä]×ǃ«ðD«
@Ú¦šáØBÈ0²-Ì6v„J º¥%L>câ³#W1M}Ü›!û¤=„Äõ9F·KLÛ°µ­¬y"×(ʸÍįÇ~]×hÚ–˜L–uLȹ°ö5u€Á±Åɉâ'ç>ò¥Ò=gª%l—R‡e[U;p¨ùm˜9!.vÂ=š¶tk/g²„ˆƒYÁLB·ÏÙvµL|×îl�¡ÁÙü_KlÝÑé=WQªA1º^él²>[ríKkÿNû2€ž¯©=ü”dE#¬(BÎÍÐYÊøV
Ç­V
ñ
¶õÚ®%tyøÛÍ¿h”~[n’üÑ=j£·€âMqN7gÀuI{ø-Ûr“ø³³4u„P�/�IÈv–Ä;{¨“¬Yî°•m¶îñÒ=
-Â2’á´I„ŽDϤ°Ýîh�= žgJ`”\`ÎÖÄÅoÇdÛJs`™b—Ø÷Zî�4…ZAÿÛ;á
ž'†µáKßÁù>¬çÊ0WÒñ
&]ž’-䊡æGó@o:›Þú;adžßÅÑ«
620š×˜`YÃäCBèOu8ŪÞË¡p5q C¿”S™n×U“ÿPoHh)¸gä^­8†lî?D–¨æ¤Š½_#8¨ÀŸYh‹„yÉwËBê Æw̓ß-ã§È¿ˆQ ðÞ�×Úðß…ûþLºù†4Z_ú)N R‹p&T
-endobj
-1394 0 obj <<
-/Type /Page
-/Contents 1395 0 R
-/Resources 1393 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1392 0 R
-/Annots [ 1397 0 R 1398 0 R 1399 0 R 1400 0 R 1401 0 R 1402 0 R 1403 0 R 1404 0 R 1405 0 R ]
->> endobj
-1397 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [364.6945 737.8938 433.3665 749.9535]
-/Subtype /Link
-/A << /S /GoTo /D (zone_transfers) >>
->> endobj
-1398 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [374.6372 708.0059 443.3092 720.0656]
-/Subtype /Link
-/A << /S /GoTo /D (zone_transfers) >>
->> endobj
-1399 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [292.0276 678.118 360.6996 690.1776]
-/Subtype /Link
-/A << /S /GoTo /D (zone_transfers) >>
->> endobj
-1400 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [319.7036 648.2301 388.3756 660.2897]
-/Subtype /Link
-/A << /S /GoTo /D (zone_transfers) >>
->> endobj
-1401 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [460.1655 618.3422 533.2211 630.4018]
-/Subtype /Link
-/A << /S /GoTo /D (tuning) >>
->> endobj
-1402 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [362.144 588.4542 430.816 600.5139]
-/Subtype /Link
-/A << /S /GoTo /D (boolean_options) >>
->> endobj
-1403 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [293.1435 558.5663 354.3435 570.626]
-/Subtype /Link
-/A << /S /GoTo /D (options) >>
->> endobj
-1404 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [288.6803 528.6784 357.3523 540.738]
-/Subtype /Link
-/A << /S /GoTo /D (boolean_options) >>
->> endobj
-1405 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [328.5503 498.7905 402.2036 510.8501]
-/Subtype /Link
-/A << /S /GoTo /D (tuning) >>
->> endobj
-1396 0 obj <<
-/D [1394 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-470 0 obj <<
-/D [1394 0 R /XYZ 56.6929 484.6014 null]
->> endobj
-1051 0 obj <<
-/D [1394 0 R /XYZ 56.6929 459.8194 null]
->> endobj
-1406 0 obj <<
-/D [1394 0 R /XYZ 56.6929 84.3175 null]
->> endobj
-1407 0 obj <<
-/D [1394 0 R /XYZ 56.6929 72.3624 null]
->> endobj
-1393 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R /F53 962 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1410 0 obj <<
-/Length 3082      
-/Filter /FlateDecode
->>
-stream
-xÚÍZKsãÈ
¾ûWèH§¬^ö‹�Üfg<»³µåIdm¥²�%µ-f)R+Rãq~}€š¢dÉòij•”l¢Ñ/à
-©¬�µYs¼`Ym2‘Æé‰eãÑXi‘ËØœž‹ÆÅ07i„>˜
-$˜
-cST£¶"U2ß©1¨Q-2­í(µR¨TŒz¬‹•C)ó^é
s‹\i\™®?ón¼*ºùòr¬SµnUÔ]9oAkIGÓeÙRÏæ2‹¶•£?ÂqÏÃÒÕØ2Q·äþ°8ÊCJ‘[«üz3WÖ÷„‚ízQtnA/¸ˆ.®^TôÚ5üÄy±1oê8˜»¹Ûuû“ÚáI•Di˜Œ�zB*
-ä2
-Óôð;ƒ‘ß&CàŠ›ºz„dŽÑ(óU!4ÐÍׂ 2K¬ý‚)È“JR+r“ÈsŠµ0Fû£?”Õb^l/
-—›ÎÔóŒñ[žâ>Ïݺ£ºeÑÑì}tÌK7wGV“2Cù©¿ “™÷È©ZN{fn/Uz*ü§%`0Âè\Ÿƒ
-WÎÕ”!2/„ŠŽ‡�YÌÁ<{¨àËq¨@¨o­9•Îz
-¶šºzäE ñ=Ç@3–ʈ<µzß�?ƒÕ>×è!ór 4ðµ€²+°üw¥“×\$ÄE:�lHé|XéyRñ�ÛFd*‡ ÞJ	'æPŽ2y*ÒÌ�J>ôZíüw{õ\	v™i©¾<¤IWÛ¶£–¿¿îyô€ð¡zÿ±…” ¿Ù€ÌY¼o㊂b1p…`-
-Py�V鎮ÇÚ_ѧBÀÒ©aÒ!רÊyÙ!²®S<¿Îí¦q42îŠÐC‚à ,“îÜ-�'“Ûß]ýæöŠˆ·ß0	33Oº¹½~+ˆ6½ÌãÈÏv$
-Y�¡àÀ…½(
-Ö<²?4ûã
3nû*”GJ¬¸a“�öà>¹M¿ß#‘[7F>pÊ£›¦Ã“™<ÜT&•hù‰¡¯è:·Zs·×<WÅÂQËÙ€má*×1�Ž
ÁœâúE˶m3/¹nƒK–Ý’ÇÑ#ˆÓoÌ…™<,ÂŒ®cIÑÒÍ
-ºuW�À0ï-Û®/#îo�mä/ØÐÀC¸Á÷�¥ÅXóÅ)¡?Ò³8Ž£Ÿ}xí‹ÓeåvCöüP‹$•ýP!yðƒ{‰øĵÍv3wá
ö¸`B24þÁe²]©ó§–@P¼:â,°À÷…‘fxía„â Ú�w\ÈÈ’¨"ß;
ǬÙxJóà‹6‹îè}Eý“÷o‰îÞð$×Î7åÌ—6 ‡rà…Ì•ï> úĈ½ÒÁqæ9sO
-B´¡É„Bc?�k.H@¯Ã·§ì“$©H+¹’)L&À]G·`ÀŽ¨´[°ÞÎÀ}�/–`�ß1<éÈÐGVìë‡H¯ÝM1™ðRËâO?saC”›°c9âˆz}—«uåVÀܾ냪ͻ›[Ñ `aç‹÷âCrU|ß{ÀîáDD%ÇQ¯=b�Có,ØÞ ×ÉúÛœÆéP-õÌÒ,êòÇkR©Eù掽uMèu´) –5¸†Uð®Tð©Øé?6fÌ�þïñRJ‰c@›.9¹¦Å¡á7òØâ&.ÎiûÀ#â;yDßC�u±éÊù–BP#ûr_¨`]zµnÚ0AX¿u0²è˜@ˆ…�äôxA‰­Ìmè~ æ^h�ÚÈRed�s˜œƒZ˜Ð–÷µW&\OLò öLÎ-ØIÎy´fy¹Í'Ï#éŠõ¼ŒôTлi¯¨j$\
hMØ·<,rœQœèKcr>*MœÒ÷àéðNMM„·‘L£¶ÙðÕ1¹ÚV]¹®x¸—•b™ aí6«²#‹…Wº‘psë’Š3
-<çvƒ*ly±žÓ}.Ði,øý½
-’
-endobj
-1409 0 obj <<
-/Type /Page
-/Contents 1410 0 R
-/Resources 1408 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1392 0 R
-/Annots [ 1414 0 R 1415 0 R ]
->> endobj
-1414 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [341.1654 214.5127 414.8187 226.5723]
-/Subtype /Link
-/A << /S /GoTo /D (the_sortlist_statement) >>
->> endobj
-1415 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [434.6742 214.5127 508.3275 226.5723]
-/Subtype /Link
-/A << /S /GoTo /D (rrset_ordering) >>
->> endobj
-1411 0 obj <<
-/D [1409 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-474 0 obj <<
-/D [1409 0 R /XYZ 85.0394 424.823 null]
->> endobj
-1412 0 obj <<
-/D [1409 0 R /XYZ 85.0394 392.7174 null]
->> endobj
-478 0 obj <<
-/D [1409 0 R /XYZ 85.0394 392.7174 null]
->> endobj
-899 0 obj <<
-/D [1409 0 R /XYZ 85.0394 362.8617 null]
->> endobj
-482 0 obj <<
-/D [1409 0 R /XYZ 85.0394 306.2038 null]
->> endobj
-1413 0 obj <<
-/D [1409 0 R /XYZ 85.0394 283.8925 null]
->> endobj
-1416 0 obj <<
-/D [1409 0 R /XYZ 85.0394 197.5762 null]
->> endobj
-1417 0 obj <<
-/D [1409 0 R /XYZ 85.0394 185.621 null]
->> endobj
-1408 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R /F53 962 0 R /F21 658 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1420 0 obj <<
-/Length 2921      
-/Filter /FlateDecode
->>
-stream
-xÚÍ[[SÛH~çWøQT…ž¾_vŸ�3`�Tewf„-‚*ÆòZ’ýõ{NŸ–-;Ø
-ƒ©!©JŸnµÚÝß¹ŸVÄ€Ã_10–Ù ÃÀÍf0¼ÝáƒÏðìýŽHsöÚI{ÝYo/w~:RnX°Ò.¯;kyƽƒËÑï™eŠíÂ
-<ûÏéÉáîž4<;:þ
-Ÿuu‰aåM,pÜ,f^W³Û¼!ººÆVdÍMç¢ÊšÚæÛ4=ûƒžOFÈš�‡ó#áD‚Ü`]ÝMy[ÔÄÌá8¯kxIP·žÃòÎå�­rWø8o•ç!­´g
-„v°·`pŸÄà;Ž»‰ùkoµ60倃{Ò1î–%í;‰“ÎßàêH¼Pkä£Uši=÷þÈaDúº�«‡rò™º9É‚þÓ‘î*¸Ç-{Øy|9]Ó¬¥„�6ÍB‘ÁUïóq9JZ{^ÿc•¥sI· *F8÷w1€ªQDô6Õ×¢bâonT_ë:�ᕵN[lA£³›ªnˆÊG£¤½5šK²ã	=!µâø„Ú¨Ro€Ö¨³QEa”Z�åÔUrïªLkŸ=ò¨ÀN?¢ÀïŠz8+¯ŠÄ×r’ø{t@@bÖ+o“m)/íî)–·=ÏzÖiǬ‘²‡uF0©<iÖ>ü
ƒ«…@ïmR«%¶)ÁûáóÞn€¯³¯ç�u
°Ë[ósÚ¾±>øQç­ë�O&½² f%ˆþzðX¯²õyî*Ú3�r�Ýi>kÊ|üÝ4)z§äiî®ñúš¯ÿƒ®‹–›¬×€r2*iÝaSV¨†Ò4Uj£:1ÉoõpS$ë
-]±˜‘öÖP/ºÙîK»Ç
Ü=>Å�ñ…Øã–¦4³{€’@"‚íuu7!–<d‡_§Åñ¤ÉÇi¨+›0»Lo“l!=à±^6;Lž -dó¬²ñŽygû¬2WpªÎî]¼{º-=Ï>TÃœ¸A_rtgÐ
-lsšÑò‡"ã³qñpþ–™óiäáZ~-ñõYÌë ²Ýpt«�’V’
kDó”eŽ!zv
-ìÓò¢‹¹W¨W,×çquÕKÓª.1sH¸^ÜMð7³ºµØ^%]üpz°
ÑÎV_q|¤¹gFÃ⛕±–K±çÏÇ'G§
-ÄÁÙG"(YµAFàÀ]‘*"	Orêb
ýFXÎqáIg˜øŒ@©{ÒíÚ§­2¢Df•ï‰”4‡õ<§s_¼;�”‹‡�R²P˜GQl$U-Öiª\*[�
-
ÁÌJÇÖ8ñcs
-Ü=é¶òE²X’î«+g™´!DP¢g¨–=»RѾcÓz¤£WˆÏ:^
ûä:oEoŽÆ~ñ2Îdëvz¹¡VÍ œDGë\ü“:´½]�h$ê$M‹‘´xçÕ«ëÖRùìê®y,2¬›rœ¬iÒu R¤ÔÅñ{¬‘q¬€õz¯zž‹š¥ÚHÖKׂm¯¸Ê
ü¨ìIýäxšk
-ýшPbÕö‚öÇÜß·Á"ðõë²€Ï1%€îu•ˆ&Õg}Š�keJ©å¦l¬E/ßÀ‹Î)_q±K	Éw=¦W	ËtÐ$é€"‚+ÌŽ"¸`/kÐyº¯“
¢�-'×U,ߪ%|aJ”ué–0 ¼³iê²=^og߯ø¶A:aYO)QqÍŒòdHQ‡ê;QG÷…�Ê !ÕÊ:õHÔÛk7|až<Ã`2ERµËK×lH'z½!MJ÷“˜w{�÷§w‰DÃ6®¢Êy¯ópøªhšb–JþЧkÝ(øôµ´Yx�.q(åù@�ÄÔÎCØ„P-?˜§ß<én°ÃÇmYÖH¤5Œ{ÛØJHZ­SdYOöÏ.Ï!°åŠg'„;ú›»æ4ºùÖ¦åX‰n<¡’x/‘m
-Ä
-:ºÌ´JÕQ|-ëfu½Gœ–¥°ro)XG¢s6è=ÐÙ€:?§–>XÒÍ¿qŠã�t–¢ÔÒÒÔÆMí=V/Ÿ5Õ·Ï.“uEc[i O1O1üíë%X
-f¥îñ}Â)ÆU2ÒŸ.c«’üjO�©ö­üÒ
-/¶ËÂK³[Çy‘ÁHEáE‚„©|ƒ)ù;…W¾>á
º^­eâ
Ò•—êfö0ºÈ졳’ÙÃH3¡%k•–yD}çëusó
:ÓÆç	ø‹fâÁAÈ¢u�ÊÅ ¸!Å`ÑXâg€ZÏCÃØ!3¯÷�qF>kˆŠW}:]! Ñæ'H§o’tºÜÃZOPϹ¹Ùì—;GÅ…Q°VžëžÒ¿LiCÙãJðcŸ³¨
-Õ}9ŠÙ£w�,M§ `©ÉÙCQL¨C˜
á¥$‚
-N@|BÛŸÆ–«§ù+L)ì†
-içÈÏCËÅr,/3åèó÷Õ/–ù 7aøÑ/òÿ+
ÜŸò~MÒŸ>‘V˜ âZˆ˜³ßý
Á™TV¶³:[ÿ?
-endobj
-1419 0 obj <<
-/Type /Page
-/Contents 1420 0 R
-/Resources 1418 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1392 0 R
->> endobj
-1421 0 obj <<
-/D [1419 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-1422 0 obj <<
-/D [1419 0 R /XYZ 56.6929 695.8713 null]
->> endobj
-1423 0 obj <<
-/D [1419 0 R /XYZ 56.6929 683.9162 null]
->> endobj
-1418 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F47 879 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1426 0 obj <<
-/Length 3296      
-/Filter /FlateDecode
->>
-stream
-xÚÍ]sÛÆñ]¿‚o�f$‡;|\óäÈRÌÔ‘]‰i2Mò
-„/ÂHŽÎ£ÀWB¾•nàVCék¤sûRxéÄWQ‚œWÊt°á|(œJú©”Ñ(‰´K˜CÖß¼?=�CàÚ¸¹kW‹¬«ÚX–„ž{.‹•iCƒÕ©H½Â,
QMë‚�°
éu%còv‘U
HA&‰wùŽÀ}ç(�Q¢|EH¸@ ´dT‹¢é²wˆÀ{]˜Ùªš9	¯jXÒW‘‚ˆwÄ©@žI‡£!>�µR¥¾-�»/)­V¦AxLZ^+š¤us;þáô\E±ô.ZàX…‚Q©ð^_ßÞ^^L+;=SÍ›¬[“¸•g]üA
ŒSÈ`|"ƒ÷ˆˆŒTR=ÃôÁÛ¼ÓáÍÓ8úoäèvdzœ*_
-•c:¼x*DLL?•‰7A3IAÛuWœw¥ål»ž— ‘2ò¦U“WÍ1Û
-Gh)5‡™ÿËßoÙ¢Ð:Ž%Aa’†ÏˆjÀƒ—•£õÓ�t;Š*JS?N¤<"ªH‡~iJ‚&¿NPLà¼&§:ôŠ�1„cbkŸ¹ùÔ\òY�Ò÷yïüE5>ŠÐ{”‹)ܨÔ)p³ö-e�ÂÈ);‚e5+ŒYïÉz�`¯÷¸ÂéýÙa7k<ÎF
Ž·?MÞŸŠP{g4æD	WЃj	‚Íz¹lW�“í›Êtàöf˜¼”à†5_±ËŠ <¤ �cŒ ¸ÕJY^þF˜{D‰wS,9µÃLŽ½V*mxÀç¯>.Ehã§`°›&�ÞÉ' ŸU¡
ßö¥„²©¹�ñ¸'	’�"þÛå±öeBƒëÉvñÿ¤	 ƒØOC�€Ü…„}Ñ
¹»…Ò¤B!»?› 
-œU˜€Ëÿ?I4ø"ñNÅ ¯áÑúS%p�”šŒ¯¡ö”Q¼‘ü¸éŠ˜òaÞóRqë”\J†
-SoŒµJ5Ö ¡ÓIÄt-aLÙ{n»p«à�yWðÀÜ}¶ªÚ5ŸdÍNˆ¬ +°·1ÍL¯bOS> fåfçÜH[:ÄrU¡w3;½ÓÒ´ð ‚
%÷R
-öÕ¤°ê¹OL+ dõ¶øŸM+ðn-ùŒ
.¼äöè:l²#I‘`ò®+F-–u5«:ÛHJ½U
-Èû ‡çE¨U¶/Š‡D
ÏWèq´´m:Ümç[on|®Z>¹ø˜Áµ߹ȚÇ}ÊHt£	’#DeJ#{ïªÉjë©a‰#¨#[(h�õ¶€-3SÆÀ‚Ô[Ï\Ïôðþ’·n^B±�:­%k1 g%•2)öæøxk8òŽM›ÛT\	e%²ÇÓXQÃY	8Ÿ¡e¥!Ô&/S®§
-™€/—h?ˆ³±QÜ}„ðq_Ð
‚ˆ
-Û.÷Y½~ÒêØöátùaÿÆ
›BTÞ¹pˆ­ B(I6åé1Ç\gcuL³lµª¨Œä´6¦~%ε‹).Ÿ"úS»zäk:d¬ÛØðI}«va&aü}ïÛ
-M¸ Œ]N¨ù{™vÚ¢1»š}(:¾ÁÒ¥ÃÍ,¼>­6Ж—öh±M×Ú¬9=L¤%c�”Õ¼´[cí�¹BÖ˜Ó€é‡Øø@&8ì9�« qÅøŒœ³&ƒ¶
`[~º4©Æ°Ÿ>ˆ�Ú¶¤]fnhÄL¸¯òÝK©EœØ/êlŸsDïà÷ÏGü�‘ÁKÕÙŠÖy½ó\hCœM6à¹ÈÀ‹ñzL¼,]8xÈ(€Øöqwß0ôW	Œ#îR&	\%¦¼|š
ðÄä=Ž-hCeö	�ÊmÛø‰¼Eklç'e
z )ðÀû­]’΀±?ÃT]5ÔI‚l¤†ŒŒ~œHkÕ¬�K‚m¸Ô8¸ÄÖ÷».@®
y\œÈ\c­yÎãÊþËu,Ù÷¹_†
€7#zsHÍÎ,מ{wÚb�1ÏdtŽ;QB\œÛ` üPuå`LÖYó
ÙÇ.:¸¹â# ã[/v	ÁÝŽÖU;NÐ�-
\ë¦ByR�°µßSw…¼üý©%ÐÉj׳s)Î1¶^çΩ÷?ÓปgÓªÞü6àÀ¯ eä+úιÛWFGáŸúÉͯDUâË4=ð[›¾‘ÁD!Ë“d—òH¦~”†ÉÒÿ³Ÿk#endstream
-endobj
-1425 0 obj <<
-/Type /Page
-/Contents 1426 0 R
-/Resources 1424 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1392 0 R
->> endobj
-1427 0 obj <<
-/D [1425 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-1428 0 obj <<
-/D [1425 0 R /XYZ 85.0394 492.6335 null]
->> endobj
-1429 0 obj <<
-/D [1425 0 R /XYZ 85.0394 480.6783 null]
->> endobj
-486 0 obj <<
-/D [1425 0 R /XYZ 85.0394 173.0867 null]
->> endobj
-1430 0 obj <<
-/D [1425 0 R /XYZ 85.0394 147.5597 null]
->> endobj
-1424 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F47 879 0 R /F39 863 0 R /F21 658 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1433 0 obj <<
-/Length 2902      
-/Filter /FlateDecode
->>
-stream
-xÚÍZÝsÛ6÷_¡Gz&Æ$�{s§U§urŠ{“¹¦”D[¼J¤N¤ìø¿¿]ì‚¢$Êq÷.ñLˆ�Åb÷‡Åb±�Åð'GI*R§Ü(sF$±LF³ÕY<ºƒ¾ïÏ$Ó\¢‹>Õw7g{«³‘.Uéèæ¶ÇËŠØZ9º™ÿ¥B‹sàGÿzw}u~¡’8z;þ	JR›DE¯¸|s5¡Ž”I¿_¿¡GŸ×ï®ßŽ¿ÿeryž™èfüîšš'Wo¯&Wׯ¯Î»ùñìꦹ¯–Œ5ÊûŸ³_‹GsÐîdzXhg“ÑTb!�S£Õ™I´HŒÖ¡eyöáìÃ^¯:“Œ…Ò©ÀIé!œ'R
]ˆÓÛz¹¬ÊêîüB§YÔ.
-*ÔU±A­_Aݥѷ/˦= ½¹ùé7=®¦Ï«9µÍ–yÓ0ÏÛƒ‘“‰ ÂëQ7™QiÛWU±ª«rÖà
-R
-—$Ê«4/>űª
-à£`Qói}�R©Ts•J”™zˆ©*ê(«¶¸Í}ã´¸­7çÒFuúù±ƒdÃNU,稇‘ј¹Ð¨yàÓÖÔœß×e�j5-ï¶eûÈbðÀu¾i`1X\?Í€†¤†6
\,î ñÕ¼“*ó²ùw
š![mQù!*V½ñTÙnÒ¤uo2¬%„!r[>ä�\ÁZ%†}Cã“h|Ý—zO/ÙÓ6-îóå¶h¨¼*õm[T\\•m[ðÈ[OT¯¨V|ÎWëe`Pò
-°¨ì4,½	¿]ÓH,Xx¢¾`‰SAÛtß2ÂöÐ'1èq!vׂÿÇQ;]hãà†¦2gû÷“£{
-8a¬G9•"ɾpM�k�H�R»hî,Þcke(dÀ†E~Ï]Âû®ý@»º@+‹r¶ ÒY]5¥�ý°ÃßO�uÊôbZ¶ÔTmWSŒæ±|ë¯L¥ Õô±7HGóz•—,H•¯
-1çÞ„À'ŸÏ9k"!çéE?MÁ1E‚�ߟà
QÛ*ç`Ëß<0°ª!Ì;¨´"ýºH¸*Ú#–Oľ	ß­öâ¾]ŒÇÒ4åçNµ–í‚Å{¨ô‚ùl±‘·’)D¢4–èf0,ýP®Jˆä—�§ÃÑ¢8
-%�…í­ÍÈX°þä¹ûËý©ýåþG¡dÐé¤Vd±Ö§<nÚ%#“)¡¬£ÓïãGñÓëâçñ
”ÊetŸÃ 	6YšHàŸ1Ç0Ç™
 ½¹¿Öº>w
-ÄϤzúX0 ¼ÖÖ°#*›§ÝOçaz>­Ø9J\•Ã
-Ã>̲ÿ%‚’‡ÏÀ'�K²ÑЮWË�ÄîÍoÁË0ãàÃýÜ-éÓy7·C~è5¢“Øv>|]Ws~ÇpŠÕ°&"Б®á€jÓR5¿££ÐâÎ]2ÍmN%¸då³ßy\ÍßÀ²*>3�%	rçvuB³þFÆÑû΄p­SCäózH;rÇàÔ袩”#~¤¦|ÚÔËm[PmUäeä�æ“R5ƒ¤�¼
-üt×Õ’	ˆxk
“zÅ‘
-øm¨èÏ÷ŽUÏI`'åîýü~Y�Ž·×�½òfSŠ7[bv›11Á{'ÝûýNIø•
+8“½Oô­5}ÞÛ'ô{/	‹�¥i˜–v#ùr–iÜRìbúϾÚÃ-…¯Õ¶i"oà:“2'`šœp
-ŽíÜ;ñ8¼8Y‘‹˜ìY 5‘×q<ÞÅ;׋åuï˜ôRT<*ÌæõwVmk|˜íÍ3à‚¦�ïe~•žõw”Ú€xšY;’Ú
-›jù¬Ÿ(ÀÅ,ÉdöÇ.‰Ã£þŠÔFÐéBªT¸8sÃ7÷,��nPõXgã$fõÊ¿“A‡i
­bǹÆØúס,fÇ%ö†ÞêÜêA¾$_§Â(3­^¯9Âå/9ùdCÙ&ØX‘h~2;DÇt´GG=éFý™¿a|b%œ;õ„¶Ã'NEbù	íÕÇG`(³]‹zs÷:½y_ù‚è8	ç¯2Oo68¤SEIÄãÍ7�Ý~³>Yo½Aù<¢<‰Ooæo×x2'b{ê�-ÀcPóóÚÀö�Óï	€ÔI€zs¿@ÏÏ)þÇ…_›€�7Z¨$I‡~	�¾häÏýÝÝî·‡&ÚÚIIN^ª‘Nð"�Ù£Ÿ†_貞ðÿd`®endstream
-endobj
-1432 0 obj <<
-/Type /Page
-/Contents 1433 0 R
-/Resources 1431 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1392 0 R
->> endobj
-1434 0 obj <<
-/D [1432 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-1435 0 obj <<
-/D [1432 0 R /XYZ 56.6929 673.1367 null]
->> endobj
-1436 0 obj <<
-/D [1432 0 R /XYZ 56.6929 661.1815 null]
->> endobj
-1437 0 obj <<
-/D [1432 0 R /XYZ 56.6929 493.0122 null]
->> endobj
-1438 0 obj <<
-/D [1432 0 R /XYZ 56.6929 481.057 null]
->> endobj
-490 0 obj <<
-/D [1432 0 R /XYZ 56.6929 393.3436 null]
->> endobj
-1439 0 obj <<
-/D [1432 0 R /XYZ 56.6929 369.004 null]
->> endobj
-1440 0 obj <<
-/D [1432 0 R /XYZ 56.6929 151.2167 null]
->> endobj
-1441 0 obj <<
-/D [1432 0 R /XYZ 56.6929 139.2615 null]
->> endobj
-1431 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F39 863 0 R /F21 658 0 R /F47 879 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1444 0 obj <<
-/Length 2798      
-/Filter /FlateDecode
->>
-stream
-xÚÍZÝsÛ¸÷_¡‡>P3	ö-Û©o;UtÓÎåò@K°Å)E*"'ý뻋HJ¦ì\“Îu2B‹ÅXìÇo
‹	‡bb4ã*‹'i3Í…ž,7g|r}¯Ï„癦Ù�ëçÅÙO—*�d,Kd2YÜ
dÆ�“ÅêCôêo/ß-.æÓ™Ô<JØt¦ý|u}N”Œ>¯n®/¯^ÿ:9MãhqusMäùÅåÅüâúÕÅt&T¬%P^Äo7×ÄtyõæbúqñËÙÅ¢[òp[‚+\麟ùd»ûåŒ3•=y€œ‰,““ÍY¬Ó±R�Rž½?û{'pÐ놎©I*ÁR­&33“€ˆ
Ó#fÅfd–‚RuÆ%U§ThŽ(5,É2í”ú6/Jؼ”ÑÊ–Åg»ûŠ¿DôP”ž~ké›·­Ýl[»¢Ÿm�š‚sËS-@IICáÎì—|³--[Öq°¨,eFóÄÈ«Õ˜ÔŒqØÚ@¨|F*¨ÄH?äw®yQùmT~‡õn*ìz½âÒL˜tš
-P¼
-Á2­¥“SÜ‘�T¶h×vG?jOl×uc©Ùì—KkW/è×@±È6ª·$cZ‰áÙm¾ü×~ËêÝý˜Ú$:zö‡Òoý
-ºÃb~°˜t¹ûJÀL‚¦™€sbÐ%øç<zoÛ¶¨îIÚbñ¦YA1Ëb»á‹µ›<‰Úbcgm=Ãm…t”‚Ž<a>§ïïœK[®èGÑWN?•œÝ­ïªZ{OO"wpvKŸÆVd“Ž‹ì«¢m†3'Qc—uµjÜ‘Ð9¦L¢í®Ø仢üê4–�À-ö'ʯ ©K8׆Hk[Q6éÙ–ùÒmšóyáFÅÆ«	H Uj¬l³Ü·ÖKZ×Ô(kw
-hY¾FŠšu›ši#d@9Î…L)¥'‰””¤Ü¾¿y9�AŠáäâ¨ÌçEjèmÊ+;>©h(RÈ)Tè‰!ÞÝç­wf26oΈ1-ÖaxZë¹.êC“FƒK4YÛ�Sy3×:ªCTÕà¯;ï[à�!¾éΣ YÕ3ˆ³ëÙª†pY
ýõ?ÏoÞ¾¼ºÆ°NTï­Ûºjl3føw´Ú
Û×zÏÆœ¿s…Mþ¥Øì=7»à!»�zuñ¡º¸W-�}À%wM0q8Â5.ú‘™kn˜L9Ä÷š³d…PƒeOâšG"ÈÓv«
3&Íž±[àe±Ì(÷üÅ…‹XEzV��‰¦d
-‘‰ÎpIjÅμ¥oKÜ�[ê-Q0
-~�QØÌ=†}
-Fç%Àa±ôD¤y
-Å%Ož®ƒb ;I�; —xœ*=2‰*G8�$2=$®ìTDÞÍSMp"‰Æ‹
àŒ],ª÷÷ë#fAg�£nýTö˶,–…ÃFHïÂ�«&b°AP°ËW@/Fʉ£Ä%ÖŠ�UI2£ AEĉJÁó<*b_(\UhºÞ<ßæÛmŸë¼_½û?_=Ì­—£2È 9&Ue²iïÛ¢®¨#w»v	
-Ò1øë.¯š2÷|ÐÓ§uuõŽ¨ùjå…6Ôá:pRô3ÊÔŽ²7,mET,
-#•<º€€T¸ŒƒhpâS›#-ÁuÌÓ¥DèØä+{(©´
-}.(É#	«QÞÐíIá½aÅÊåaÞ¨+W‚@ÛR¦ÔB
-ua-عl
VQ{ßä÷·ƒi.¦›ç~6R
-åÅ‘ÌnlY4ô
-
-…u[8ÐF·wÃÓØòîð¶xYæMŠê•ÝâœU¸7O�èã•ñé7û¦=|>ìß4Ëfn¹ÝZúûq@7J†§ä1áçëÛnUËr¿²Ý…à î*°ô4cÁôÀF0˜J¡=ß‹Q
-endobj
-1443 0 obj <<
-/Type /Page
-/Contents 1444 0 R
-/Resources 1442 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1453 0 R
->> endobj
-1445 0 obj <<
-/D [1443 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-494 0 obj <<
-/D [1443 0 R /XYZ 85.0394 711.7496 null]
->> endobj
-1446 0 obj <<
-/D [1443 0 R /XYZ 85.0394 684.4451 null]
->> endobj
-1447 0 obj <<
-/D [1443 0 R /XYZ 85.0394 642.9726 null]
->> endobj
-1448 0 obj <<
-/D [1443 0 R /XYZ 85.0394 631.0174 null]
->> endobj
-498 0 obj <<
-/D [1443 0 R /XYZ 85.0394 462.3028 null]
->> endobj
-1449 0 obj <<
-/D [1443 0 R /XYZ 85.0394 432.3134 null]
->> endobj
-1450 0 obj <<
-/D [1443 0 R /XYZ 85.0394 343.0202 null]
->> endobj
-1451 0 obj <<
-/D [1443 0 R /XYZ 85.0394 331.065 null]
->> endobj
-502 0 obj <<
-/D [1443 0 R /XYZ 85.0394 138.4884 null]
->> endobj
-1452 0 obj <<
-/D [1443 0 R /XYZ 85.0394 114.5262 null]
->> endobj
-1442 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F39 863 0 R /F21 658 0 R /F47 879 0 R /F62 995 0 R /F63 998 0 R >>
-/XObject << /Im2 984 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1456 0 obj <<
-/Length 2275      
-/Filter /FlateDecode
->>
-stream
-xÚ½YÝo7÷_¡?¬€Šáç~Å
ª-ç\Ør*«ÍáÒ<¬%Ê^@Ú•µ«8¾¿þ†rŵ6‰{¹
Â9;œÎüfH³
…l bg<$™$Š25XlNèàÖÞž0Ç3òL£�ëçùÉ›‘2’Å<ÌW�¬”Ð4eƒùòCA† �Fÿ¾™N†#®htqyRñèìŸãwóÉbÇúóåôg2În¦—o›�‡‰Œæ—7SœžM.&³Éôl2ü8ÿåd2oUÍbT}O>|¤ƒ%X÷Ë	%"KÕà	~P²Œ6'R	¢¤~f}r{òk+0XµŸöº‰QÂEÌ{üÄYŸŸTFbÁEë'E¸…RÍ4Zxz3»|{éÌ=/vzÑŸ´1„Š@(
->0|^¾åS¡@™Á8w|Ëj“å¨Ì7}›Ç)áR2Çû¡Gš
-
EOÊ0Œ»«ÖíèhTöØ„
-(g‰$ÚÚ𯺮qó“xkÝ.bUI™¾Êe,má#w;Øü‚­m~Á率Õr±Þ#jžÒâF�^v9oübá„o+øÄG—«žÀ
-2õ'ciWé£@f%íJÛ£
-À�”*ºr€£»ŒmM0“.ÌXØ»º*‘çéAÛÞÝN¢€8¸
-_⃳Y?Ô}ý')å¯MŽþc	ÉOÿì•m�×}Á].EY÷¯{'•ÛÇžæyëÜõ(á¼!ÿÿ–—EA3hIJq}|`]|â
-endobj
-1455 0 obj <<
-/Type /Page
-/Contents 1456 0 R
-/Resources 1454 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1453 0 R
->> endobj
-1457 0 obj <<
-/D [1455 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-506 0 obj <<
-/D [1455 0 R /XYZ 56.6929 769.5949 null]
->> endobj
-1458 0 obj <<
-/D [1455 0 R /XYZ 56.6929 751.4464 null]
->> endobj
-510 0 obj <<
-/D [1455 0 R /XYZ 56.6929 563.3947 null]
->> endobj
-1459 0 obj <<
-/D [1455 0 R /XYZ 56.6929 537.1873 null]
->> endobj
-514 0 obj <<
-/D [1455 0 R /XYZ 56.6929 314.9763 null]
->> endobj
-1460 0 obj <<
-/D [1455 0 R /XYZ 56.6929 292.5697 null]
->> endobj
-518 0 obj <<
-/D [1455 0 R /XYZ 56.6929 211.1564 null]
->> endobj
-1461 0 obj <<
-/D [1455 0 R /XYZ 56.6929 183.865 null]
->> endobj
-1454 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F53 962 0 R /F11 1299 0 R /F39 863 0 R /F62 995 0 R /F63 998 0 R >>
-/XObject << /Im2 984 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1464 0 obj <<
-/Length 3617      
-/Filter /FlateDecode
->>
-stream
-xÚÝZKsÛ8¾ûWè�ª¥«,^|íM“(YOeœ¬íÝšÚL”HÙ¬P¤V¤ì(¿~»Ñ
-'1‹LnW=ZãQ$&·é'ïõßfoç×çSés/`çS?àÞÏ—Wo¨'¦ÇëWo/ßýãzvjïöòÃu_ÏßίçW¯ççS¡´/�€²$þõájNƒÞ^¾ŸŸ¾ýål~Ûn¹,Áî÷ßgŸ>óI
-§ûåŒ3Gþä~p&âXNÖgÚWÌ×J¹žâìæìï-ÁÞ[3uŒM¾Š˜ÉpŒOñŸü˜J*Ã'Îð_Ä’]^MgoÞ\³ÙõÇÙù4àÜ»º¡çÍüúŸókÁæ¿Í~ýø~ÎðÔ°ôTû¾|‚#$Ÿ$$ž"ôújö뜚4nlä€(iƒ|!Qù2¢´SÆÆ ×ÁŽ<±^_±„аB¨'AèƒB„ÁKTKÅŠ…<<P­ÿn–ÛVù,
-|ÿôhZ¶éfIMÛCM*IÑ*.4;ÅR0¥”?	‚�‰06lÞ&å]†l‚Áª78Ô$vnFÝÞç5˜kyˤ¤Æ"£gUšFèU+êh+j¬ªíºþëùTéÀ«›dÛLë¦ÚØY[zvý?ÕM¶
áª@y—ŽÔ½]äwÎå¶nÆôW�Aqì™-ÂsWgé	àvc\(Û‡ÕYC�¦¢§€Õµx³¢ s"‰›´í€bR¦îµ#½ÞÕ–æ"³ŸMUçMþ�é¥Ï#&ƒ@Núü1­@ýSàÇa nJý4Û)'UM‡ÈÇásª¦ ! �Ç/îëjšÜK³z¹ÍYÝŠ’ú«Ç2ÛR_™¬]çê`Ôö\D^VW;ÓXfôšz—•y¦v!”?>vÐ’F%M–Žz¦Y¹ÇЂÏË»ÂOÿø>°6Šb{¤Wc‡f~à»
¿sŸ§UQ$[G÷®„>�ºÏ½z¿^TEM¯óæ>/éžõxm¡ZÚã<
Óš4¦ÎÓŒÈ'tt¢OíM‘,³”^/ö†S)
-ÀÌD8y*Ó`áÒ“Ÿªg9ØKXº—»-©vÙÐãÀÁ†¤�Þfª^Ì°±vWØ	‰�Ðë4[æ뤠>¼ºwß2ÚÄt.%iJ¡‡wÆ‹?0ƒ§5béKâ3Œ0I^$‹"³£M
-W¨›C¤ïÒˆ»2ÿF0Ç7NŸy™æ.úBâq †çYÂLôED� ë}^ÑÃ8Ê>ƒÈ��NûÙ¦y]îø')´•_òL樅qÌjKS<›9ÞlÀÏÇ€j¨m.hù:›6Õ´€Ô›zL
-r‘9	ßgÛ¼qÎfC£€påôyП—”K;j{y»"«Ùó9Ï’—17"5ã~ìà¦Eć¢
@â‡ÎÕŒ‹b€ÖÊ$*õŽî†<½;´Óò9ÛZE'–g»?¡ï==ú£J%†ºsÎü0z®P¢%¤ÔàퟔÒS
-ï;@æ+;ßôTê½ë«9ô�¨¹]½†Û’Œ\'Íòž:-1é}Ãê߈Ïn7
-
ê>!…Þñ~Œe�ºkÁÿÅeâÄ(~CrÈt$dÿ~òèžRñ€EpÞTAŒP”­ ÕÈ=%¨?–÷B[^ÏÆ=$@Á¶^ýn~5¿6‰ôí|,ÉUŒså
-ι7KÓ¼¿ÈÛÜì­9ؘq9ˆƒ
-!¼‹ÖèÅbïüµN¶_€¶/_[ÿpœÖU’v½y?ñ7vu‰¿Œ©V›ÚãÚ0FÆ�weÛ‡¬­îóv�u
-Ðj�Bl«Žq¯Ú=TŽP
úk£Û	åààk[¤é´Ã¯é™}ô#¼%ak\­¢çÂág¯þ
-²ûompô0¶¬ ™Œ„:¸®@ƀƌ—’°˜¬Û²5étŠõð.ÃF|
XG:/c×à.ñš$#µÙ4–F �@_²w?�lL»²ÏÕÁ”t›È—ô·€º¥lš`mÂß5€.š|i®™¬
-DG†¬Îévttðƒ”yëÛƒþmŒhÅl1�íÝwÃÆk†\~''ñû”
'­FßAVÃÜ­ZÄ"_…Cõ�
œüKÐJœ.�dQ¬ÄsÀ|Ÿ:D@sW›„W¹/[ QfÍcµýB?ûÆvwÕó“n€°ñPå©¥AhoyŸ7Yê§ifªõ¥]‘@�]äw¥-eGš		˜xwOW„Zzuån“Û“»§)Æ*º„ßë�Qh!~´—tZ¶ï7U]çR2­È8��¡)äÚx«m¼Õ6ÞÂsW»7yi¿qÑ®[ªÍ×Cfûí‡<‡‚z¾}�÷QA@Àš>^kYÄö”7cRìK¨ËBZèp
{é—ø„€oa¾ÏjLÀõ‘Æ
-endobj
-1463 0 obj <<
-/Type /Page
-/Contents 1464 0 R
-/Resources 1462 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1453 0 R
->> endobj
-1465 0 obj <<
-/D [1463 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-1466 0 obj <<
-/D [1463 0 R /XYZ 85.0394 687.9013 null]
->> endobj
-1467 0 obj <<
-/D [1463 0 R /XYZ 85.0394 675.9461 null]
->> endobj
-522 0 obj <<
-/D [1463 0 R /XYZ 85.0394 283.5376 null]
->> endobj
-1292 0 obj <<
-/D [1463 0 R /XYZ 85.0394 259.198 null]
->> endobj
-1462 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F21 658 0 R /F23 682 0 R /F14 685 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1470 0 obj <<
-/Length 69        
-/Filter /FlateDecode
->>
-stream
-xÚ3T0
-endobj
-1469 0 obj <<
-/Type /Page
-/Contents 1470 0 R
-/Resources 1468 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1453 0 R
->> endobj
-1471 0 obj <<
-/D [1469 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-1468 0 obj <<
-/ProcSet [ /PDF ]
->> endobj
-1474 0 obj <<
-/Length 1368      
-/Filter /FlateDecode
->>
-stream
-xÚ•]oÛ6ð=¿ÂÈ“Ä)ês}jÓvëPCã>­{ eÚ*‰šD%͆þ÷ñx¤,Ǫ·À0t<ïŽ÷M¶ æÇYL(Ï£EšG$¦,^õ]ìÍÞÏWÌÑD1'qĹYÌì®bž‘8ÓÅjÊäÍúêö}È!%IÆ‹õn”•¤)ÉÒ8_¬·wÑjÙ-WaLƒtùçúW<‘4K£FDB²(Ïì�7~{‹Ô9~îe1t¥~ÂÕ�júr+;¡K�üXDx”„Ž_‘Œå¨@JØrÅ(¥Áë¢�}?²Ñ�ªpñ±ìµgÅ9É“0qœ8%!��Óñ|Œç—,�Gäxؽ/4¦¯ï>öæËn
-Ñ ÐK·5´Žg³E )‹¯�¨�¨�ê�n7èaªÃÐ; lFž\œ1’Çqh/.ªJ=®¥ËÝÓŒ™Œ÷¢(MÍ) ¾™á‘<cÜ ·¿ÙÍ2‹�#Cö2f„Hob†aÊÏXòn*Q|=¨JΰŠLX…ì…Õ�hú�É€s~&LY–U³Á(uA€ÖÄ	£Inœ‘‘<7‚�ìs_6{Cš˜€6A†�å`Œh…߃x�}¡4ll2&,(Ô’Ó(68õ€»4x<¸Ós Ç?Êpt.ÖÔËN§‘½IƒÇRÔ ›jЦ€îp¹g†a<ò5P¡Ðv�+
-ôU”N|æ$LŒ/ÐW{¥¶îÌVŠ¹Pa$ËSÆà	 ¶Y
-ýM#
-endobj
-1473 0 obj <<
-/Type /Page
-/Contents 1474 0 R
-/Resources 1472 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1453 0 R
->> endobj
-1475 0 obj <<
-/D [1473 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-526 0 obj <<
-/D [1473 0 R /XYZ 85.0394 769.5949 null]
->> endobj
-1476 0 obj <<
-/D [1473 0 R /XYZ 85.0394 574.5824 null]
->> endobj
-530 0 obj <<
-/D [1473 0 R /XYZ 85.0394 574.5824 null]
->> endobj
-1477 0 obj <<
-/D [1473 0 R /XYZ 85.0394 544.7049 null]
->> endobj
-1472 0 obj <<
-/Font << /F21 658 0 R /F23 682 0 R /F47 879 0 R /F39 863 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1480 0 obj <<
-/Length 3343      
-/Filter /FlateDecode
->>
-stream
-xÚ¥Z[oÛV~÷¯ÐÛÒ€Eñ\x+¸�Óº»Hº‰ŒÝ¢íEKÜP¤BRVÕ_¿3gæP”D7
Š æáp8ç2·o†³
-¬$ ƒU‚3åGax‘~_3b™úI§£ˆ…†Kï؀•N8)á¨6h8²Æ
W0Jì1¡ê˜|î¯̾µÉxTÖyµ/LÇÌ�7Žý†²*ܳëƒ8œ±;Ÿ’üÉGÛÓÞ[Nk´s·—³ôŠÂþ†A5M
®•v-`|65
é¥4ŒÍSG8&NRñ5± ‚ÌÆ.n–<aœ
-ð9«
-ìË
]³âû®¿˜ï%«ö¦f³§#"+�îÏì‚°RçPÇ'3];OÛ”‘;°^¶ÜëApŽ“'FÅ	
-€M)_ÄQr
\	ÿtŽf¹®±ðÇŽßréùg
-ñÍ7-?†bBÊS@ÛC	8‘œAQQà‚è¾J%aa‚ÛR¾ÉêµqtA-â£é:®˜l+ˆÛ¦(‘)Ïú¡NCmv®ê‡”`jJ_fŠöOŒ”ªTÕ¦´£¤ŸÊH]í‡ë2ן´B³Î`?·¢5çÁeÁ=	7µo3,‹m\ý4TÞ8�–¹„rê£ümÙS!4Õ.U
-QØ´£³À›ÐÉ^Å‚³É
-€è­=B	Áb+Ë|nD�u•£àÔ±±þ5ûGO:8ÀéãÃ_óαK	‚lƒK�µªŸÀJ­9Ï)ÎroŽ`JeN¡åiWd½qÍjî;~±]}Ï
^	Åý×WÒ+œ|¤îY>ŽŸ³œ/Þu›f_4^ñ« qPvŶ‰Úšƒ«Úš©`ÆN€!`Æ+æѪàY]§pØÁ¶Tq]£½¢áû
US`ï¶7¤UÖQ¤(¾§Ú•RÊ{ü‰YQFíø%*º”ãÔÞ¦¡²I&5Ÿ¡bbX9f£“»cÿâEVåÀª©U÷ÊÔ;¥¬…^ÖSç@†P™Þ
-\Tü·”Ã'ºm¶†É«üØ×qêðÀöæ0gUOÖ¨I2ı?¸ƒœœÚåJ…Ü.GòÖô›¦àe0
Š4N×

-@µÜœÖh¹»†X܃s]àŒ®$�Áý"pó³Š�å$ƒÑâøé
žnˆ-”üáƒdX–ɺÒ20~¦fÐÚ,väï«®áoúa©™ñ|¶ø˜´x¾hÃÓØó¥6lB¦ðªfTª|)høÍÌö‰Ú¦±�$Û1¡Z,ÎOÖÊñ
]º*{aÖáÃ
-ìÍ´phÛŽ0<PyÇEØHêRð†vc¿Œ)qZÒ6ƒz¬�2üœzÚfdN‹�m.A�œõ=궠‡+¦vC5:7ÕÈ44Ã3ç²@°»¾£ñ€ñÔðuE�÷H�è[Ë„(Þ
¿o›!~¼ðl2\½`Ï `›
-.
júl?Qëœ&=aÏl7úReQnï¾�›îù†b:óÄ'ž·�ÍÉÖ|:‹�b}Y±C¦}CL˜õmÿnmóÀÀ‹
|c›ÜVA¨ÁèfÅÒóö¸ë›u›í6®×€�³=¬ ÆöCoXЊçØš¬ž>[4A
-endobj
-1479 0 obj <<
-/Type /Page
-/Contents 1480 0 R
-/Resources 1478 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1453 0 R
-/Annots [ 1485 0 R ]
->> endobj
-1485 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[0 1 1]
-/Rect [63.4454 757.0719 452.088 767.2337]
-/Subtype/Link/A<</Type/Action/S/URI/URI(ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.dns_dos)>>
->> endobj
-1481 0 obj <<
-/D [1479 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-534 0 obj <<
-/D [1479 0 R /XYZ 56.6929 739.5018 null]
->> endobj
-1486 0 obj <<
-/D [1479 0 R /XYZ 56.6929 704.7645 null]
->> endobj
-538 0 obj <<
-/D [1479 0 R /XYZ 56.6929 563.5308 null]
->> endobj
-1487 0 obj <<
-/D [1479 0 R /XYZ 56.6929 535.7626 null]
->> endobj
-542 0 obj <<
-/D [1479 0 R /XYZ 56.6929 418.2412 null]
->> endobj
-1488 0 obj <<
-/D [1479 0 R /XYZ 56.6929 389.5504 null]
->> endobj
-546 0 obj <<
-/D [1479 0 R /XYZ 56.6929 228.1296 null]
->> endobj
-1235 0 obj <<
-/D [1479 0 R /XYZ 56.6929 194.8993 null]
->> endobj
-1478 0 obj <<
-/Font << /F37 747 0 R /F67 1484 0 R /F11 1299 0 R /F39 863 0 R /F21 658 0 R /F23 682 0 R /F47 879 0 R /F53 962 0 R /F48 885 0 R /F62 995 0 R /F63 998 0 R >>
-/XObject << /Im2 984 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1491 0 obj <<
-/Length 533       
-/Filter /FlateDecode
->>
-stream
-xÚ¥TM�›0½ó+|©¸6Æ`³IÚ²RÓ4a«ÕxT‚Ó@6Úýõµ3·¶ôTEóÆoÞ|x€"b~	Ž	“1JeŒ9¡•[� µ9ûêQÇ	Ϥð–u—{Ÿ¿°I,“(AùË�–ÀDŠòêÉÍóé"#Nü!Oˆ—Í&à‘ðXNÇ‹,4þ1[f“éb¤±Ÿga,ˆ0ñÌ)Lg£ïÙøó	P§Ôžó{oš_¹m–f»øí==T™žï=‚™
 ˜J¡­s†yÌØÙÓxKïçEðæô:4<Îæ"J¦±¡éq‰fŽìô–z«lO‰ßÕ½êÀ,7ZwÎÝkûäþ/¥và)šŒê­-¶uið[xØUE¯*8˜ØyžE_€U· ã`wXUz[€×H¶.²R�Z!—{Sô7üÐŽÛôRŠ%çÑ©
'ÂTÊä)…��Ú{�2è]·ÊÜ,#‰Ÿoê˜Çâ- ”úŸŒ‰I§Àßë]بWÕ\cÁ*uÛ›|u»vx_÷v
-endobj
-1490 0 obj <<
-/Type /Page
-/Contents 1491 0 R
-/Resources 1489 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1493 0 R
->> endobj
-1492 0 obj <<
-/D [1490 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-1489 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1496 0 obj <<
-/Length 69        
-/Filter /FlateDecode
->>
-stream
-xÚ3T0
-endobj
-1495 0 obj <<
-/Type /Page
-/Contents 1496 0 R
-/Resources 1494 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1493 0 R
->> endobj
-1497 0 obj <<
-/D [1495 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-1494 0 obj <<
-/ProcSet [ /PDF ]
->> endobj
-1500 0 obj <<
-/Length 1964      
-/Filter /FlateDecode
->>
-stream
-xÚ¥X[�ë¶~?¿ÂoѱV”D]Ò¢i³§I¶EÒ g�¢íé-imõH¢#Rv7¿¾3œ¡,ÛJS »&çÎá7äˆbÁ¿Ø2Œ’2ÝäeÊHÈMÕ¿‹6{à}óN°L*“P¦I“îV&E(‹8ßl—F¾zy÷øu,6qfY,7/¯³¯,/Â2IËÍKý�àé Ž¶¶±Œ‚âáŸ/"µ4Ì‹\ Z.d˜—Qá^„Á¨§]טƒÖ¶ö³šHÃ$ÍbVË’0Ï"òS„âa+¢(
-žtßë�þ0j0Ó›‹
–Rz	Ÿ‹Â˜M<ÛϤ´¥ÁY�Ÿ šßÐì Ï4¨{{¦Ÿ�Q隣¡™ž¼öA]™=�zØÉ‘%›2,³8ãÀ =e*RJÈ
,%©v�±42º›l‹‹Ä™Õ3õ„Ér“v
-i	·¥Ý3éÀ–yíˆùðŠ&�Â8K<æc�ø¡›‚hïCû™<»úÐŒ­êhüýÔï Æס\@�•‰ó÷w= vV
-ŠØmT¹,(¾ÊÞñ‰}�q´€¨\Â&|&d¾vKÈTÝVŒÐhÆKI›S?s�@Õ+6¸k0mHšŽµÇrRϯÄ'¨
-ýf3GÕ51b‘æi‘diNŒ�‘Œâ�±ˆ±0·"ð0àâÄßZÕ7’\sÂw
"ó‡&0ÍåþF
—?$cRÍZº”í(õåŠ:é�H^�04g¢°û(½ÀÙWáÓ
7�˜¿S,[>°úŒ¹…;î3`ô¦'b�ÕÀ¤Ö^ïöEy˜]¹œ­Þv‹íçÞa¯Úák@n@þzh|ÇütÓOÓ0J¿mºã—¿ÞeÚâš(°ÁiÇEðá
êÍ�âÀz҃ѣm§žæˆ§çOŒ$ 
-­è×ØÚ:‰óÎÐÃBYn?z·XdÌqâd¾©Üä¤ÚNí:ørðï»QÕaáƒL·CÕMucVìâªV.Wª�4 Û8Hü»Uoy)”@»Zìo+B)ˆ×­©ôD9ƒ©;B.ÊõTyåvÂ)Î6™îZds§¡ÁÓÏMí­µ°r=¶ö�ä&vÓž®é^/yr€�¡¶¯ÓP;«y Â1{9B€FãŸà{ËוÂM>p\×-ž‘7>å	èWˆÌ¨W
-¥Ìrcø-Š¼ûãËü
-“¤%œ¡i±Iæ² —â~ÚøÑŸ/¯6³Âv¡ám’rá÷Î.zïá°ú‹EØûÛxà8KQ”×ñܼÍBw1\­ýÎÆð»•s^ÀÍQŠ’säjMkç/Ú,ÜÚmR¡ÈEz�ís³ã¾‡ê
-endobj
-1499 0 obj <<
-/Type /Page
-/Contents 1500 0 R
-/Resources 1498 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1493 0 R
-/Annots [ 1507 0 R 1508 0 R ]
->> endobj
-1507 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[0 1 1]
-/Rect [348.3486 128.9523 463.9152 141.0119]
-/Subtype/Link/A<</Type/Action/S/URI/URI(mailto:info@isc.org)>>
->> endobj
-1508 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[0 1 1]
-/Rect [147.3629 116.9971 364.5484 129.0567]
-/Subtype/Link/A<</Type/Action/S/URI/URI(http://www.isc.org/services/support/)>>
->> endobj
-1501 0 obj <<
-/D [1499 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-550 0 obj <<
-/D [1499 0 R /XYZ 85.0394 769.5949 null]
->> endobj
-1502 0 obj <<
-/D [1499 0 R /XYZ 85.0394 576.7004 null]
->> endobj
-554 0 obj <<
-/D [1499 0 R /XYZ 85.0394 576.7004 null]
->> endobj
-1503 0 obj <<
-/D [1499 0 R /XYZ 85.0394 548.3785 null]
->> endobj
-558 0 obj <<
-/D [1499 0 R /XYZ 85.0394 548.3785 null]
->> endobj
-1504 0 obj <<
-/D [1499 0 R /XYZ 85.0394 518.5228 null]
->> endobj
-562 0 obj <<
-/D [1499 0 R /XYZ 85.0394 460.6968 null]
->> endobj
-1505 0 obj <<
-/D [1499 0 R /XYZ 85.0394 425.0333 null]
->> endobj
-566 0 obj <<
-/D [1499 0 R /XYZ 85.0394 260.2468 null]
->> endobj
-1506 0 obj <<
-/D [1499 0 R /XYZ 85.0394 224.698 null]
->> endobj
-1498 0 obj <<
-/Font << /F21 658 0 R /F23 682 0 R /F11 1299 0 R /F39 863 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1511 0 obj <<
-/Length 69        
-/Filter /FlateDecode
->>
-stream
-xÚ3T0
-endobj
-1510 0 obj <<
-/Type /Page
-/Contents 1511 0 R
-/Resources 1509 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1493 0 R
->> endobj
-1512 0 obj <<
-/D [1510 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-1509 0 obj <<
-/ProcSet [ /PDF ]
->> endobj
-1515 0 obj <<
-/Length 2543      
-/Filter /FlateDecode
->>
-stream
-xÚuYYsÛ8~ϯð[誑ÂûØ7[ÎádìrYÎNÕnö
"!	k’`ÒŠæ×O7ºyØéTJ@£hôñuƒö.\øç]¤ÑÚ
²ð"ÉÂuäzÑE^½s/°öù�Ç<a¬£0`²°ºŠ‚t¥~r±šorýôîÃ'ß»ðÝuûÑÅÓ~<+N’µ¥OÅ�«¦‘u¡~]®üÈu®.ÿ÷ô•ÄÂu’&Š¹pD²ã$žKäÒŒÌ^¸ÂØgæ8Z‡A’óÚ»\y®[çϵ>•²8T²îf²Þ:‹¢A6Ö^yƒì$Mú]·JîiøE™N·gšh&vGIƒ›û-
D]°èíý
\dë,öc>Ӈ˹!ë[vGÝŽ d¼~ø~gx©óÃuý\‰)´¶»ôyPu­êQ¬6sñ]	UÓø^TLÝžM'+Éó¾mñ
-�\Ó±8Ø�ãràÔòD3hÄ“0D,¤É[µ³:ÝêdÐ9 QÔ€EÒÔ'{)Áúrø®óɪ¢«q—�µÑ$”ÄêY_ÝÔ'ÿ=>\f¾sUË"'Á_‘k/ƒ“†®
-¦6pkK­é·ç÷'‘s[w²…-@Ø£å�Ì­ßp,XBšÎÞ'h7ü•¿Ù*Œpv
-÷Ãa…|‘¥nl Ø-H±ÈZyá6µ¨€÷ƒ(
-RÜŠ1ÏuL~”6�`l�¿‚~ZѨ¢<ÓCƒÚ̓
-’
r�”OœBç=Á	1j"«¢ºÑpQɧUäzý"GöÄÙ	G,ØÝfS6äÐBdz˜€z²Ó„Q™DÏ
B0q
-�ã”U#7Cã@Q²€.ÿ¾ô
-ÝD‘øñðñ^=:\è±æí
-®o¬ƒñ+ñ'E\2}8Ç’;i%Ò‡ï&ª°Wõ\~jÀaÛÍ{³˜¢GË!zeoA
_�^†NmÞxš^Xð”Ð;’ù‚Ïr{z8Ø'"Hóȃ…×UØNÑô�
-endobj
-1514 0 obj <<
-/Type /Page
-/Contents 1515 0 R
-/Resources 1513 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1493 0 R
->> endobj
-1516 0 obj <<
-/D [1514 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-570 0 obj <<
-/D [1514 0 R /XYZ 85.0394 769.5949 null]
->> endobj
-1517 0 obj <<
-/D [1514 0 R /XYZ 85.0394 573.5449 null]
->> endobj
-574 0 obj <<
-/D [1514 0 R /XYZ 85.0394 573.5449 null]
->> endobj
-1518 0 obj <<
-/D [1514 0 R /XYZ 85.0394 539.0037 null]
->> endobj
-578 0 obj <<
-/D [1514 0 R /XYZ 85.0394 539.0037 null]
->> endobj
-1519 0 obj <<
-/D [1514 0 R /XYZ 85.0394 510.2426 null]
->> endobj
-1513 0 obj <<
-/Font << /F21 658 0 R /F23 682 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1522 0 obj <<
-/Length 2893      
-/Filter /FlateDecode
->>
-stream
-xÚ­ksã¸í{~…¿Õ™‰IÔ3ÛéL.›ls×Ë¥‰;íÌíÍ”–h[]Yò‰r²¹__€
-'é<%Ø«Ô4hνd®J%µÊ‰¢¨ó¬ö­Ú­TCSßu]"�UN ‚yH‚ïäêfÈõµ)ZE¸zMˆJɦ|ãeeÉõ^e-3³”í–—ª\~4
-hfáyN†¾9fùVT²"ŸFÒÐg[Ø>k$ŒÓ­%ya4P’~¯$œø#Ìùp
-"
‡Ï®ëgýFÐ\í‰s&[ÔÂŒjp`‹1ãÄ.}Qe½ß©ª%€Ý)«+]ðq‰§
-~H¿°OQ­4Áæ:“¥$o…Ù=ŠR©–fì-DM¸û"�çËm/Èá¤ÝÒÌNßöæ@1t$ê÷Š,s¸b,Â)PøTE&u;aBá9±èèðV$ÑÜ\{؆,CfáCƒUP9'°ÐßHI"ð掉z�Û›äÄ”‰ïˆDø¼ùuõöž�è‚��"FHÜm,$BŒëàæV4P}#¡ô
-±AiÏK:·úCÛÅÂñCa×R¾_~à‰�-³¤üœö
-É‘
9R �P)�0¦†Œi‚4`(M§6ó'óÃ^S(Wr7dg51™hïŸÏ=¨m/̹?5YŽ¥ÚlË7“ìÌ(Ø… ¾È5o]÷"L¸6xc0¡q²m
-©—´¦5õÃD 	œ$ŒlH„r«å&Âçݳ5º?¾·hdµÁk+ §/-UçI0>
-è¾ÏÝG$”uf,Õ­DC¡Æüx¾;˜t
-(–
"—ÜYi4¹B™º¦qfèY'ÉíŽÑ–�\z
¬nÌ\³&ÊKŸ	‰•v(Äð1“‘㣓Æ|ÒØŠž«�ˈ�p}µ6eè£[SWöj›ŸMñ¢Âú`K@®Ö j]¼©VP%Û
-·KÊÿóWÞþCw;"Iüé¸~œ8
Ô¥V(<AêžHn?ŸŠþ_`Ý2ƒendstream
-endobj
-1521 0 obj <<
-/Type /Page
-/Contents 1522 0 R
-/Resources 1520 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1493 0 R
-/Annots [ 1526 0 R 1527 0 R ]
->> endobj
-1526 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[0 1 1]
-/Rect [253.7995 146.8976 417.685 158.9572]
-/Subtype/Link/A<</Type/Action/S/URI/URI(ftp://www.isi.edu/in-notes/)>>
->> endobj
-1527 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[0 1 1]
-/Rect [63.4454 108.9117 208.8999 119.0735]
-/Subtype/Link/A<</Type/Action/S/URI/URI(http://www.ietf.org/rfc/)>>
->> endobj
-1523 0 obj <<
-/D [1521 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-582 0 obj <<
-/D [1521 0 R /XYZ 56.6929 652.1213 null]
->> endobj
-1524 0 obj <<
-/D [1521 0 R /XYZ 56.6929 614.8935 null]
->> endobj
-586 0 obj <<
-/D [1521 0 R /XYZ 56.6929 614.8935 null]
->> endobj
-1072 0 obj <<
-/D [1521 0 R /XYZ 56.6929 584.5024 null]
->> endobj
-590 0 obj <<
-/D [1521 0 R /XYZ 56.6929 289.5256 null]
->> endobj
-1525 0 obj <<
-/D [1521 0 R /XYZ 56.6929 251.3901 null]
->> endobj
-594 0 obj <<
-/D [1521 0 R /XYZ 56.6929 251.3901 null]
->> endobj
-900 0 obj <<
-/D [1521 0 R /XYZ 56.6929 222.7156 null]
->> endobj
-1528 0 obj <<
-/D [1521 0 R /XYZ 56.6929 53.7852 null]
->> endobj
-1529 0 obj <<
-/D [1521 0 R /XYZ 56.6929 53.7852 null]
->> endobj
-1520 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F47 879 0 R /F53 962 0 R /F11 1299 0 R /F39 863 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1532 0 obj <<
-/Length 2825      
-/Filter /FlateDecode
->>
-stream
-xÚµZ]{£6¾Ï¯ð¥ý<-’ KÇö¤É4™4v·Û�α›g0¸g&ýõ{„>äζûä" ôâóžO	<òà�"†<ÊýQÈ}Ä<ÌFëý•7ÚÂÜíV2×ZèÚ–ºY]ýó
Gñ€£Õgk­yQ„G«ÍÇñôéiñ8¿û÷äš0o<E“kæyzt¶XN®Ã€‹	*¦o|swóã݇Ûçéӿʇ~ó˜7}œË›åÏ··‹åj¡nŸÓùÝã-ˆàɧÕýÕbe^ÛþiØ£â�¿úøÉmàÞ_yˆòˆ�¾Â�‡0çd´¿òȨT�dWË«ŸÌ‚ÖlýhŸª�‹HØ£+‚G#Îi)‹qPBke-«8ßÄÇM9ø[¨�(c—h²¤$4í£IK	ä�Ïïf $ÿS3EÞÝ	m¤Î±}ÛD0c(
-)kƒÏ‹}œæ’ÐÇxŸ”ŠwBBy5+òur¨Ô8èH^¼‹×i–ViRë«ó3qè!„¼ Àø‡|äi‚	£Érì¡X‰IuLK%õX¼&û—ä(ï0�B4ÈÀVüKŒXRF´”Ås0₶éb0bƒ_dänÈ’}’Wq•y‡—å!Y§¿yYËÙsr&@¿ö’#oþ>Š�(½@‘-5L‘‘ÒñÐá3N䆡3è~†ZØqš©Xœª4ßv8¨v‰¼°©\¾•U²ïs1Òç¼ÍÇLiÿ)>‚æ7ÛD�ßÇù)>¾ÕH-ÙŠpׄøˆG Z*~€O꥟ŽÅ¡(m)—^@Eäw–”ƒ;-eÜ‹s‡{9¡-òºØäÙàwùú8ÁÑXz�âñ?E®([M0Æãcœ—Ÿµ�kç�Ë>ú|Œp
-�ªèf1ˆ{²¶À,@^C-·{FæBþ¿9•;yµÈþЉ픽ý&A$¢ä–”ƒ	-e˜ ^ä`Âm1ÑÅ`ÂL¶ ÒWÕâõÎT:è~:%Ç�²›r„I@úSÑ4ßÈÄ÷U×qq=°Þ½GÃz‡¦
CP½ wKÊ¡w-eô„.pA[zïbèÝ_|«’¼4	Æ$§²“�ŒòE?¼€;Ow½g�F¡€ùŸóŽÃô1|‰KÊA�–²( 
-\Ð]ì

-lðÇ"¿–EWrܧ¹®ÈŒÆe‚©£G²I¥¯ÃC$d´ß
fÇø«`VØôëžêÞ^"ˆ|nÝÛRú7RF÷‘洞�Ð�îÏ°ûuß_&ª* lü>y“M¯UýEÐ䄼JMM’ÒEàBÂEVË»Û
!„"/bØâj<nÀCüq:Ácå$”�?¨©ÛÓfé»”E
¡Ñx®fqY]˼o Zy?‹¿h—£-#0}Û�2”_&œŒ“,ƒ\Iœ:XªôD<(›í$QQ~ÁN,)‡�h)c'œz;qA[vÒÅ°¼e' i'"}—Uü’¥åN4S®˜¹z¿P;ŠÏÏC¡3âÈçAgÓh®8ô2¸L•µ#áfÈçˆr‰!KÊÁ�–²r$2'´ÅP{€!Ü(û9ùý”è�f,»ÇŸ…ÚÒmW'ImÙ�%�׫s\9äÆÔ”ðÿ7[#àKlYR¶´”f‹z^è`Ëm±ÕÅ`ËRZ?ß'jò�j¨-ÀqM†|D·kâF¶k½Á#ƃ6IÎ0×ÞÛssƒ)�è7–”ƒ-e¸	œ9ÑmqÓÅàÆ¿Mr¨¯…bÃP•V"Ú…
Ü_Óu"§¦Ù¶€©Ý^ÎÉ°'ib%ÜËX	=>(–éæT{-éÕp!è¿].e~ót^“§<®\Ë�ÏüN9´Tô¿ÿç}õé­ì
-¶º/ÓÃi&·hÞêß¡fÔ_¦/Å«=sß²²~e|–pu?øCœejîú*ló£ýû›<€æ©»¿Ù4ª
mõÖÒwm{RßCKqšµ-5lÖFʘ5!³vB7f}†ÝoÖ-ð»|SÛ˜n+Ÿ“²È^µ¢—§Ã¡8Vgçr1ëËÔ
ƒØ±þØ?+ò£¡zž¬Ûá†
-±ŠSzIï–”CïZÊè=¢Ô¡w´¥÷.ö€ÞmðÕNFƒ”/
]xœ½•i)Źµfk
®ÕÖ\éL ®íLÐð©p’f¯M¬Šxõ%Í´Ü-ƒ‹g=	�P’Š�àã@wFªžV‹¶êi Ó$“pŒ"^Ø#µ¥†É4RšLßs‘é„nÈ<Ãî'³^Ìí¼€y¾U
É|\lN*²‹ÑZÁBX”disæлsùбØÅ”ÕĈç§òYèzº†11ú FŒ�ª;òdw$^æ!.ËDGn¹9ª [œ6LjHp•IÿnÐφé0
-=|a¿Ô–rЯ¥,ú1Ô	mÑßÅ ßWgU±.Ä.øÌC±él FD¥oíÕbD&&áÈMb‚;¹û}nýlŸ3C¯îs;s,“&,Ú63a;²}PâÚ,”G«•[ìëÞ2–Îñò_´¨‚™èÌÝvaI9ìBK5vá;΃�Ж]t±ì¹TÖó¢8„È#ëB”õMm”F*ÊSU׉‹ÆÄ�Ù�ì5,>}ñ­}ʸÞ´#š‰È21ú ÄMŒƒsu\bZFñ÷ÃY
‚©À²¸ ¡£ùÈ

-’Xï*
-endobj
-1531 0 obj <<
-/Type /Page
-/Contents 1532 0 R
-/Resources 1530 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1589 0 R
->> endobj
-1533 0 obj <<
-/D [1531 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-1534 0 obj <<
-/D [1531 0 R /XYZ 85.0394 752.3015 null]
->> endobj
-1535 0 obj <<
-/D [1531 0 R /XYZ 85.0394 752.3015 null]
->> endobj
-1536 0 obj <<
-/D [1531 0 R /XYZ 85.0394 752.3015 null]
->> endobj
-1537 0 obj <<
-/D [1531 0 R /XYZ 85.0394 746.3107 null]
->> endobj
-1538 0 obj <<
-/D [1531 0 R /XYZ 85.0394 731.5461 null]
->> endobj
-1539 0 obj <<
-/D [1531 0 R /XYZ 85.0394 728.1497 null]
->> endobj
-1540 0 obj <<
-/D [1531 0 R /XYZ 85.0394 713.3851 null]
->> endobj
-1541 0 obj <<
-/D [1531 0 R /XYZ 85.0394 709.9887 null]
->> endobj
-1542 0 obj <<
-/D [1531 0 R /XYZ 85.0394 651.9592 null]
->> endobj
-1016 0 obj <<
-/D [1531 0 R /XYZ 85.0394 651.9592 null]
->> endobj
-1543 0 obj <<
-/D [1531 0 R /XYZ 85.0394 651.9592 null]
->> endobj
-1544 0 obj <<
-/D [1531 0 R /XYZ 85.0394 648.8377 null]
->> endobj
-1545 0 obj <<
-/D [1531 0 R /XYZ 85.0394 634.0731 null]
->> endobj
-1546 0 obj <<
-/D [1531 0 R /XYZ 85.0394 630.6767 null]
->> endobj
-1547 0 obj <<
-/D [1531 0 R /XYZ 85.0394 615.9121 null]
->> endobj
-1548 0 obj <<
-/D [1531 0 R /XYZ 85.0394 612.5156 null]
->> endobj
-1549 0 obj <<
-/D [1531 0 R /XYZ 85.0394 585.7959 null]
->> endobj
-1550 0 obj <<
-/D [1531 0 R /XYZ 85.0394 582.3994 null]
->> endobj
-1551 0 obj <<
-/D [1531 0 R /XYZ 85.0394 567.6349 null]
->> endobj
-1552 0 obj <<
-/D [1531 0 R /XYZ 85.0394 564.2384 null]
->> endobj
-1553 0 obj <<
-/D [1531 0 R /XYZ 85.0394 549.5337 null]
->> endobj
-1554 0 obj <<
-/D [1531 0 R /XYZ 85.0394 546.0774 null]
->> endobj
-1555 0 obj <<
-/D [1531 0 R /XYZ 85.0394 531.3128 null]
->> endobj
-1556 0 obj <<
-/D [1531 0 R /XYZ 85.0394 527.9163 null]
->> endobj
-1557 0 obj <<
-/D [1531 0 R /XYZ 85.0394 513.1518 null]
->> endobj
-1558 0 obj <<
-/D [1531 0 R /XYZ 85.0394 509.7553 null]
->> endobj
-1559 0 obj <<
-/D [1531 0 R /XYZ 85.0394 483.0356 null]
->> endobj
-1560 0 obj <<
-/D [1531 0 R /XYZ 85.0394 479.6391 null]
->> endobj
-1561 0 obj <<
-/D [1531 0 R /XYZ 85.0394 464.8745 null]
->> endobj
-1562 0 obj <<
-/D [1531 0 R /XYZ 85.0394 461.4781 null]
->> endobj
-1563 0 obj <<
-/D [1531 0 R /XYZ 85.0394 446.7135 null]
->> endobj
-1564 0 obj <<
-/D [1531 0 R /XYZ 85.0394 443.3171 null]
->> endobj
-1565 0 obj <<
-/D [1531 0 R /XYZ 85.0394 428.5525 null]
->> endobj
-1566 0 obj <<
-/D [1531 0 R /XYZ 85.0394 425.156 null]
->> endobj
-1567 0 obj <<
-/D [1531 0 R /XYZ 85.0394 355.0758 null]
->> endobj
-1568 0 obj <<
-/D [1531 0 R /XYZ 85.0394 355.0758 null]
->> endobj
-1569 0 obj <<
-/D [1531 0 R /XYZ 85.0394 355.0758 null]
->> endobj
-1570 0 obj <<
-/D [1531 0 R /XYZ 85.0394 352.0499 null]
->> endobj
-1571 0 obj <<
-/D [1531 0 R /XYZ 85.0394 337.3452 null]
->> endobj
-1572 0 obj <<
-/D [1531 0 R /XYZ 85.0394 333.8889 null]
->> endobj
-1573 0 obj <<
-/D [1531 0 R /XYZ 85.0394 309.8192 null]
->> endobj
-1574 0 obj <<
-/D [1531 0 R /XYZ 85.0394 303.7727 null]
->> endobj
-1575 0 obj <<
-/D [1531 0 R /XYZ 85.0394 278.3282 null]
->> endobj
-1576 0 obj <<
-/D [1531 0 R /XYZ 85.0394 273.6565 null]
->> endobj
-1577 0 obj <<
-/D [1531 0 R /XYZ 85.0394 246.9367 null]
->> endobj
-1578 0 obj <<
-/D [1531 0 R /XYZ 85.0394 243.5403 null]
->> endobj
-1579 0 obj <<
-/D [1531 0 R /XYZ 85.0394 173.5556 null]
->> endobj
-1580 0 obj <<
-/D [1531 0 R /XYZ 85.0394 173.5556 null]
->> endobj
-1581 0 obj <<
-/D [1531 0 R /XYZ 85.0394 173.5556 null]
->> endobj
-1582 0 obj <<
-/D [1531 0 R /XYZ 85.0394 170.4341 null]
->> endobj
-1583 0 obj <<
-/D [1531 0 R /XYZ 85.0394 144.9896 null]
->> endobj
-1584 0 obj <<
-/D [1531 0 R /XYZ 85.0394 140.3179 null]
->> endobj
-1585 0 obj <<
-/D [1531 0 R /XYZ 85.0394 113.5982 null]
->> endobj
-1586 0 obj <<
-/D [1531 0 R /XYZ 85.0394 110.2017 null]
->> endobj
-1587 0 obj <<
-/D [1531 0 R /XYZ 85.0394 95.4372 null]
->> endobj
-1588 0 obj <<
-/D [1531 0 R /XYZ 85.0394 92.0407 null]
->> endobj
-1530 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F47 879 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1592 0 obj <<
-/Length 2889      
-/Filter /FlateDecode
->>
-stream
-xÚµšÝw›:ÀßóWøÑ>§ÑEŸ�$v·‰›µ“·ÄVN0¤·Í¿#ô�À zwÏž<¤AƒõÓŒfFà‰xâùÈ�H4	"yö&Ûý™3ù}WgXÊœ+¡sSêâþì�÷4˜D(ò‰?¹2Æ
-‘†xr¿û2�E3Á™^,/n–Ÿ®ÖñÝõ_³sâ9Ó¿ωWsq³y¸ºZlîòv½ˆçËÕˆàÙyàGÎ4¾»[¬æË?EÌGutëåb3ûzÿálq¯_ÛüiØ¡ü�¿Ÿ}ùêLvð?œ9ˆF¡7ù	7ÂQD&û3×£Ès)U-ÙÙæì_z@£·~´wª°ƒõIÏ\<ÁEžGZ“åEȧ„Ö“µfeq<l™œ¶-;q}?ƒx{eå௤€°4¤ÄKÑ>€JŠ¿Ó—õûKŒCúµ«ÓávÕZêT·k.Lä‘ ­{Å~ÂÏÇt:_mÄÅz-ØߎCò´J‹¼ž“ÎOÁŽÓJ}x	>Ð;xŠ8ÓKô~‘)c,~°Ã‡ÓçäPÕxz#»âú?™Þ&ûä¥(eïZö>dÙ>És9h’ïDóÝ“H
~[l_’WVRxÞfB½Ò¹XÂ>>m«âÞ£¦‹ÎAC„ý(B¡ïŽ6¥†	k)M8püaÂVÕ
áݽ„[ºXøé«M|§–=7¦m½˜Aw‘�ä/�ø�Òü›¸˜øh²÷²ÈX–%ò™.w˜C
-jt¼G¯
~c¬�úqe×õ‚ÐZÂNû{ÞH`dJY¨*)Mû–}ÕªÚ ÚÕÝOÕÔý ,fBò‚‹e^±CÎ*q'€óþB6¤%ìe�ÇJŠß.ÿ\¬Ååe!ì?—Ï^eÅc’‰ëx·SÎC>—¼¾rå=FïFÈÅ.5ð»"ΫÊÎ¥Q+±ìØnŸÓbÀhÃA¼^è"⮯)5ŒWKxÃa¼VÕ
Þݽx[ºùš¥;¦~m|„Ó‡<å Dcg›…–åŽåUÊã*v(EÓQº|ª|9´i_Nµ/§V_NQzÔôå‘Ø„ù`Iž²L!|14Þ"å¿å£-Ô°Ge¼–b}Ì™ƒö¢ADG@RÐJJƒ&Ô±€¶©6@wu÷ƒ6udr�/~mŸ“ü›œˆ9ËØ7µw	±­Ã…àÉ¥W›¾È*ô ‘¡íÀJ…NqÕÚ#»±“…%Èuý1
-†”…‚’Ò`¯·P°©6(tu÷S0uÏ7±øé•�°b³¼’MiÞ�weG<úvÄv¤óc SçÀ=Û%uQømBsIh‘”U–¼0ÙLkCß½Sq±°ûgM,&†af0s�†”…˜’2ˆb6Õ±®î~b¦îõ&þãvîÁÎ(j4À2¢5~Å
ñÿb›E�7
-jõ’¿¡æG(p�ÐØå���n`s¿k°‰`F�ÔÊ'­0ÝÐA>Lº¦)5SK0-»�UuóDw/Ì–îMUê]
-GtzÉbƒà“•¼Í­ò¾š!oPy£`ȯC.1Â�P„!ílòç9Cþ¬izŽ§
-™z…ñ‹ORøê¸Û!¨•Á�¹Å´ñ´ÿÄr]ˆã�؆”¶’2`GØ6Õì®î~ئn;û\(â/‚Øô©ŽZίY]™½°9–¢?•-Òõ††ë�´ë

×�-€ÀE
ÄÒ†ë
¥ë�Züý–ëõñ‰
Ë�þ�	CºÑUCÊBUI5T]KcUmPíêî§jêž³*Ù>³Ý³1Šìݨ@ôà‚Ù¥ÔõþÏ[%…42ÂþSj�–Òh‚ÐR
-5 ‰¥ngÓk�ì(îGi(Ž›t]$ãk}4HøÑ`'¿¿IËJ¦žÂ÷:íbo¸·<xúÅJãPöîFé�= ààö–j¸^È«ŠíóI�Æ
-<¢8²3„†�)!
Ì‹,¥
›ÞXWq/0S±¨¡†þªX^Ö'•°;¢¦
-ÿËãëkq¨„ÐòN4þ`‡R”Í¡Ñï«Ì9~dl„.ñ¦$ž¸.ö"_à­—²õú˜‚­&²õ³.˜C×Ç2Í“¼’]"†fUƒÓÚÚδ8¦e™öÕ€0&Ì‹·ÔClHY+)²¥š`UmPîêîÇl꾆IËô9£2¶‡ü%/~æ]£8ÜllOš\Ë´ËÞòFnu,0–Æwu,«ä©l2ÇÓí�ª3˜Öw	à—¬`Jx �Bãö9­®lé:–>8`ù,ä8Έ6¥†™k©æË3·ªn˜ŸèîeÞÒ­çc‘o‹Ý	ü«~‡—&‡éÖ?Áô~²"âø¡ÅÍ~6oZ_ˆñzH3•¼„ÃÉö"â±j�)e¡¤¤J¶ýÒªÚ ÔÕÝOÉÔ½fß�©Øãö,WÛ¡Þ"›#/~w]è
ó\ÍÝk–n�BzSÖ•ž»Ï,HžÜNáüâ�ìØ@¹Ü…Â�	Ý‘z�)e�¢¤4/²™ŽMµ
¥«»Š©{<½ßT‡ã¶n’ufÞ8ÛèÙ#ù
uÛ“ÿAÇ
-¶}ÎÁ=eês¦=÷qrê6=äé÷#ë#@ wÓ!(ôü 
¶í,c‰ÂÊŽ¥^I§‚ö;•“~f8ö•…!4LK	5eb©TÛô6¬ºŠ{Q™Šµ�sCåã܈û¸¤Õµ›s£N$—ñ*W—�+¤;vH†¾oä%MŸ´Nÿ`Ä:¥†ÇÍ”š�”šwJ¡‹º°•çâ#Èó×Ö–ei²W_,j%­Ø_kç3»Á@ÓRgñÿž¶gò“þÏŸíUñ
-endobj
-1591 0 obj <<
-/Type /Page
-/Contents 1592 0 R
-/Resources 1590 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1589 0 R
->> endobj
-1593 0 obj <<
-/D [1591 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-1594 0 obj <<
-/D [1591 0 R /XYZ 56.6929 748.5056 null]
->> endobj
-1595 0 obj <<
-/D [1591 0 R /XYZ 56.6929 748.5056 null]
->> endobj
-1596 0 obj <<
-/D [1591 0 R /XYZ 56.6929 748.5056 null]
->> endobj
-1597 0 obj <<
-/D [1591 0 R /XYZ 56.6929 743.7078 null]
->> endobj
-1598 0 obj <<
-/D [1591 0 R /XYZ 56.6929 719.6381 null]
->> endobj
-1599 0 obj <<
-/D [1591 0 R /XYZ 56.6929 711.8197 null]
->> endobj
-1600 0 obj <<
-/D [1591 0 R /XYZ 56.6929 697.0552 null]
->> endobj
-1601 0 obj <<
-/D [1591 0 R /XYZ 56.6929 691.8868 null]
->> endobj
-1602 0 obj <<
-/D [1591 0 R /XYZ 56.6929 665.1671 null]
->> endobj
-1603 0 obj <<
-/D [1591 0 R /XYZ 56.6929 659.9987 null]
->> endobj
-1604 0 obj <<
-/D [1591 0 R /XYZ 56.6929 635.929 null]
->> endobj
-1605 0 obj <<
-/D [1591 0 R /XYZ 56.6929 628.1106 null]
->> endobj
-1606 0 obj <<
-/D [1591 0 R /XYZ 56.6929 601.3909 null]
->> endobj
-1607 0 obj <<
-/D [1591 0 R /XYZ 56.6929 596.2225 null]
->> endobj
-1608 0 obj <<
-/D [1591 0 R /XYZ 56.6929 569.5028 null]
->> endobj
-1609 0 obj <<
-/D [1591 0 R /XYZ 56.6929 564.3344 null]
->> endobj
-1610 0 obj <<
-/D [1591 0 R /XYZ 56.6929 549.6297 null]
->> endobj
-1611 0 obj <<
-/D [1591 0 R /XYZ 56.6929 544.4015 null]
->> endobj
-1612 0 obj <<
-/D [1591 0 R /XYZ 56.6929 529.6968 null]
->> endobj
-1613 0 obj <<
-/D [1591 0 R /XYZ 56.6929 524.4686 null]
->> endobj
-1614 0 obj <<
-/D [1591 0 R /XYZ 56.6929 500.3989 null]
->> endobj
-1615 0 obj <<
-/D [1591 0 R /XYZ 56.6929 492.5805 null]
->> endobj
-1616 0 obj <<
-/D [1591 0 R /XYZ 56.6929 467.136 null]
->> endobj
-1617 0 obj <<
-/D [1591 0 R /XYZ 56.6929 460.6924 null]
->> endobj
-1618 0 obj <<
-/D [1591 0 R /XYZ 56.6929 436.6227 null]
->> endobj
-1619 0 obj <<
-/D [1591 0 R /XYZ 56.6929 428.8043 null]
->> endobj
-1620 0 obj <<
-/D [1591 0 R /XYZ 56.6929 414.0996 null]
->> endobj
-1621 0 obj <<
-/D [1591 0 R /XYZ 56.6929 408.8714 null]
->> endobj
-1622 0 obj <<
-/D [1591 0 R /XYZ 56.6929 382.1516 null]
->> endobj
-1623 0 obj <<
-/D [1591 0 R /XYZ 56.6929 376.9833 null]
->> endobj
-1624 0 obj <<
-/D [1591 0 R /XYZ 56.6929 350.2636 null]
->> endobj
-1625 0 obj <<
-/D [1591 0 R /XYZ 56.6929 345.0952 null]
->> endobj
-1626 0 obj <<
-/D [1591 0 R /XYZ 56.6929 321.0255 null]
->> endobj
-1627 0 obj <<
-/D [1591 0 R /XYZ 56.6929 313.2071 null]
->> endobj
-1628 0 obj <<
-/D [1591 0 R /XYZ 56.6929 298.5024 null]
->> endobj
-1629 0 obj <<
-/D [1591 0 R /XYZ 56.6929 293.2742 null]
->> endobj
-1630 0 obj <<
-/D [1591 0 R /XYZ 56.6929 267.8297 null]
->> endobj
-1631 0 obj <<
-/D [1591 0 R /XYZ 56.6929 261.3861 null]
->> endobj
-1632 0 obj <<
-/D [1591 0 R /XYZ 56.6929 199.468 null]
->> endobj
-1633 0 obj <<
-/D [1591 0 R /XYZ 56.6929 199.468 null]
->> endobj
-1634 0 obj <<
-/D [1591 0 R /XYZ 56.6929 199.468 null]
->> endobj
-1635 0 obj <<
-/D [1591 0 R /XYZ 56.6929 191.7053 null]
->> endobj
-1636 0 obj <<
-/D [1591 0 R /XYZ 56.6929 176.9408 null]
->> endobj
-1637 0 obj <<
-/D [1591 0 R /XYZ 56.6929 171.7724 null]
->> endobj
-1638 0 obj <<
-/D [1591 0 R /XYZ 56.6929 157.0677 null]
->> endobj
-1639 0 obj <<
-/D [1591 0 R /XYZ 56.6929 151.8395 null]
->> endobj
-1640 0 obj <<
-/D [1591 0 R /XYZ 56.6929 137.1348 null]
->> endobj
-1641 0 obj <<
-/D [1591 0 R /XYZ 56.6929 131.9066 null]
->> endobj
-1642 0 obj <<
-/D [1591 0 R /XYZ 56.6929 117.2018 null]
->> endobj
-1643 0 obj <<
-/D [1591 0 R /XYZ 56.6929 111.9736 null]
->> endobj
-1644 0 obj <<
-/D [1591 0 R /XYZ 56.6929 97.2091 null]
->> endobj
-1645 0 obj <<
-/D [1591 0 R /XYZ 56.6929 92.0407 null]
->> endobj
-1590 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F47 879 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1648 0 obj <<
-/Length 2544      
-/Filter /FlateDecode
->>
-stream
-xÚ¥ZKs㸾ûWè(U�€ øÈM¶l�&3¶#y²IÍî�–`™ŠTHʳ³¿>
âA�" É¦|0	4ñýu7º›ÂxS‘$˜DIàQ„éd{¸B“=ÌÝ_a)3WBsSêúùê/w$š$^úáäùÕX+öPãÉóîÛtñôtû°\ýs6÷)š.¼Ùœ"¤Fon7³y&|‚ð©M¯WןW�÷ëÅÓlj‡~E-–âfóõþþvó|+o×·‹åêáDðì·çOW·ÏúµÍ­aDø;ÿçêÛoh²ƒ~ºBIb:ù7ÈÃIâOW
%
Q#ùÕæêïzAc¶}tLU”Ä�ýhDW>ž`ì%”ú=eÑĉOZe-6b[�GV¥MVµuWÃ[\ Kˈ cd	Žþm}wŠ"¿
11E^œÀû;@µÌ50MSêÅ¡&ì²<¤Y!ö�îY‘Õ
l¾¬j1Vvºhï÷§lÇ<þŽƒ-á�zAÆðB|ÝBü‹'þ.Xsjâ¡|g‡V‰;œÄ‘gU6çKr¨Û�r(\Ii•S9Tî‚6”>Ķ¨Ý¿)‡R*^[Þ2mRqu—åL\ݔůùû“àAÞVÕÇSNÓ Ì HŸŠ§ö“©äãš±ªa‡TÎ=n›Ò #!V2ÂúªL);ZJ“‘`ßN†º#ã{œŒø(:¤¹ô�b÷g)ñ1õÂ8öû”,ieúÆ{©fñô”V?4#¡�‘vNQ|�CÊÁˆ’RŒø##.hƒ‘!¶…üLù7UÖ°*“îñZJc]—e##Jz�³aÕ;«êÑ(Åà‚qØçáZòð%-Š¬ØØî9Î?f”N³ß3fñO �0Âhê„,I!M’�I\ƒ£
°…"ùk-Õ]¾g‘giÍê
S¬ù^Vÿî(ʶlœ£0ö"?ÆO’�é!Ëåtš¤µœþ…ûQ•íßA‘‚ì%sŸ$¥�WÌ߃V¸*Àæ
-i‡ÙL‚™‡&7;kž@£Ä‹¾�)˜RvÖµ”¦=ö©�v'tÇûö8ñ=ðì<§Ï3Œ10°Ï[½„(ßGSöò×ÙœþtUקÖ
-`¦µxf…ã‡âR+¦[%òñHQ
-ͳ�pUÉç[BX#îŽ"â6å¶ÌÇ¢.ñ¡Ä<
`µ¸ëj¤uk“¹–ŸÓ†¾L3Ø¢2ÃTÆd!dõuD^FhK!E:	G@vᜀ-”È?1’ÐŽCHGh‡Å�.ŽÇ<ÛêôFx5±Z>,TÉ0<&	`&„ÁC]
-/¦”�O-ÕñIÉ£ºãó{œÏøB÷FßYѵEï”Kɬ`à|*û㽜ÚÑ]9+áU}ŒÖÛtÙî&6Fãà/��ƒ)¤Sz9j8®AÊ
-§ý©n4‰•%ˆtÓ`ÙYPBÝ'©ÈQG»p;†Àã˜ÈÂÉb
§áY…Hvà¾)ù³¸†A•áÊ8åÀ~/öê»~¬¼VY³âÄ-}¼'`(ŠÌ¦Gœºâ>]ݲòÜ”öÜêF}î<eÆï4>�òŸùüÄÓ
-2jëHøÿûYF2òHlë¹B¦žDê¥øæ2|sýË­óWÿ/§÷Áendstream
-endobj
-1647 0 obj <<
-/Type /Page
-/Contents 1648 0 R
-/Resources 1646 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1589 0 R
->> endobj
-1649 0 obj <<
-/D [1647 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-1650 0 obj <<
-/D [1647 0 R /XYZ 85.0394 748.4854 null]
->> endobj
-1651 0 obj <<
-/D [1647 0 R /XYZ 85.0394 748.4854 null]
->> endobj
-1652 0 obj <<
-/D [1647 0 R /XYZ 85.0394 748.4854 null]
->> endobj
-1653 0 obj <<
-/D [1647 0 R /XYZ 85.0394 743.3452 null]
->> endobj
-1654 0 obj <<
-/D [1647 0 R /XYZ 85.0394 728.6405 null]
->> endobj
-1655 0 obj <<
-/D [1647 0 R /XYZ 85.0394 723.1655 null]
->> endobj
-1656 0 obj <<
-/D [1647 0 R /XYZ 85.0394 708.4607 null]
->> endobj
-1657 0 obj <<
-/D [1647 0 R /XYZ 85.0394 702.9857 null]
->> endobj
-1658 0 obj <<
-/D [1647 0 R /XYZ 85.0394 688.2211 null]
->> endobj
-1659 0 obj <<
-/D [1647 0 R /XYZ 85.0394 682.8059 null]
->> endobj
-1660 0 obj <<
-/D [1647 0 R /XYZ 85.0394 668.0414 null]
->> endobj
-1661 0 obj <<
-/D [1647 0 R /XYZ 85.0394 662.6262 null]
->> endobj
-1662 0 obj <<
-/D [1647 0 R /XYZ 85.0394 599.7666 null]
->> endobj
-1663 0 obj <<
-/D [1647 0 R /XYZ 85.0394 599.7666 null]
->> endobj
-1664 0 obj <<
-/D [1647 0 R /XYZ 85.0394 599.7666 null]
->> endobj
-1665 0 obj <<
-/D [1647 0 R /XYZ 85.0394 591.7571 null]
->> endobj
-1666 0 obj <<
-/D [1647 0 R /XYZ 85.0394 565.0374 null]
->> endobj
-1667 0 obj <<
-/D [1647 0 R /XYZ 85.0394 559.6222 null]
->> endobj
-1668 0 obj <<
-/D [1647 0 R /XYZ 85.0394 534.1777 null]
->> endobj
-1669 0 obj <<
-/D [1647 0 R /XYZ 85.0394 527.4872 null]
->> endobj
-1670 0 obj <<
-/D [1647 0 R /XYZ 85.0394 502.0427 null]
->> endobj
-1671 0 obj <<
-/D [1647 0 R /XYZ 85.0394 495.3523 null]
->> endobj
-1672 0 obj <<
-/D [1647 0 R /XYZ 85.0394 420.5376 null]
->> endobj
-1673 0 obj <<
-/D [1647 0 R /XYZ 85.0394 420.5376 null]
->> endobj
-1674 0 obj <<
-/D [1647 0 R /XYZ 85.0394 420.5376 null]
->> endobj
-1675 0 obj <<
-/D [1647 0 R /XYZ 85.0394 412.5281 null]
->> endobj
-1676 0 obj <<
-/D [1647 0 R /XYZ 85.0394 388.4584 null]
->> endobj
-1677 0 obj <<
-/D [1647 0 R /XYZ 85.0394 380.3932 null]
->> endobj
-1678 0 obj <<
-/D [1647 0 R /XYZ 85.0394 365.6884 null]
->> endobj
-1679 0 obj <<
-/D [1647 0 R /XYZ 85.0394 360.2134 null]
->> endobj
-1680 0 obj <<
-/D [1647 0 R /XYZ 85.0394 345.4488 null]
->> endobj
-1681 0 obj <<
-/D [1647 0 R /XYZ 85.0394 340.0336 null]
->> endobj
-1682 0 obj <<
-/D [1647 0 R /XYZ 85.0394 325.269 null]
->> endobj
-1683 0 obj <<
-/D [1647 0 R /XYZ 85.0394 319.8539 null]
->> endobj
-1684 0 obj <<
-/D [1647 0 R /XYZ 85.0394 295.7842 null]
->> endobj
-1685 0 obj <<
-/D [1647 0 R /XYZ 85.0394 287.7189 null]
->> endobj
-1686 0 obj <<
-/D [1647 0 R /XYZ 85.0394 272.9543 null]
->> endobj
-1687 0 obj <<
-/D [1647 0 R /XYZ 85.0394 267.5392 null]
->> endobj
-1688 0 obj <<
-/D [1647 0 R /XYZ 85.0394 252.7746 null]
->> endobj
-1689 0 obj <<
-/D [1647 0 R /XYZ 85.0394 247.3594 null]
->> endobj
-1690 0 obj <<
-/D [1647 0 R /XYZ 85.0394 223.2897 null]
->> endobj
-1691 0 obj <<
-/D [1647 0 R /XYZ 85.0394 215.2245 null]
->> endobj
-1692 0 obj <<
-/D [1647 0 R /XYZ 85.0394 149.4956 null]
->> endobj
-1693 0 obj <<
-/D [1647 0 R /XYZ 85.0394 149.4956 null]
->> endobj
-1694 0 obj <<
-/D [1647 0 R /XYZ 85.0394 149.4956 null]
->> endobj
-1695 0 obj <<
-/D [1647 0 R /XYZ 85.0394 144.3554 null]
->> endobj
-1696 0 obj <<
-/D [1647 0 R /XYZ 85.0394 120.2857 null]
->> endobj
-1697 0 obj <<
-/D [1647 0 R /XYZ 85.0394 112.2205 null]
->> endobj
-1698 0 obj <<
-/D [1647 0 R /XYZ 85.0394 97.4559 null]
->> endobj
-1699 0 obj <<
-/D [1647 0 R /XYZ 85.0394 92.0407 null]
->> endobj
-1646 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F47 879 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1702 0 obj <<
-/Length 2122      
-/Filter /FlateDecode
->>
-stream
-xÚ¥YKs㸾ûWèª*Bðà37ÙÒ8žñÚŽå­d33š‚%–)R+RžÑþú4Ð J$µ•”�n ?ôQø±‘ç?âÑ(ˆ\âQæ�’Í­`ìöŠžIÍ4±¹®_®þöI£ˆD>÷G/o–¬�Ð0d£—åWgJƒê\ß]ßß=Þ>OŸþñÛxÂ=ê|£�>Ì°³øõöv¾x™›îó|:»{¸6ž~D�éÓÓüav÷oŸ*©´¡ÞÌãï/Ÿ¯æ/Ͳí­1*Ôš¿úú�Ž–°ÃÏW”ˆ(ôF? C	‹">Ú\¹ž ž+DMÉ®WÿlZ£zj§©%\ø¼ÃVœ�#‘çñ–±¼ˆø‚m¬ÇײÈd%—¸ÇÙÃÂØF&û]ZŒi>Ý”½›.4ht
G‹×&ºp¬¹ÔÒ¾‚VN}ïû©fÆ9XņU7\çº]û1�mݳb§ùxârê<Ä©ZÌYÊJn�z4�™ÿ¬d^¦E®Ít²;R„�ëR²ÿ
-S|á̈™—U¿Ë1Ã×»1�%ê‰sÓ¸1ü_âýÛ&Î�”Ïq¾�w¥¶\+š4°ƒ>8W
éE�º$Ä£:
-‰"ïÀà—Xw“uƒCÔ�ƒ’Hò’Í5€CÍUã (
pRmápª»[w�ƒCƒƒjÕ8èvƒƒ�'!,æ7˜5GºÊÓ|…�é¾Zšÿ'î3HW‘î8w®	Nü×8âŽÌ2�T:Šqá<ró*wÆêù­(Æ)¥ý˜‰ˆP7º„™Å5€YÍuÄ,¢˜
©¶0;ÕÝ�™­»'7.‚Ý›,Þ¥ß(åI\5ÄúûŸ"¯]®Š«}—Sqð°íUsãU÷òGZv;
-p¹™Ll«ežúï…ÔƒÈyx¡Î³¹ú!m¸H}o
-ÌWP%ºQ�…A=-Í@Rà:Mb;4ظýØp�¸`ÂØX\ØÔ\6—¥AÕ6§º»±±u7õ¹[×…ªÕÔçÐÖL5LI}ãE@;ñ"M1^df/B±öåúó¼Ú°ùT¤yuœµ˜?§}ÊâUÎ.»|±
ZÇĆڊ‰µs~)²w¼;«ÞgC]$ëìPµŽ„Ž¾}…�u£<1PÈ/¼t“°¹úOLÃÕœ˜p¨T}<1gº;OLKwOUzzaÐ>ù³BëB®øZ\ϳéØóœå™S$}*v›¸3�ú°ò�»mçÀqº_íËê«Ó‡±‰€�á2ª!áA¹Gýæ‘�'.Î]rsi$Ívñ[ÕULSHÊ.Dæj	֬ЫgA¾»Yi¬
-ë˜èÊÿ€\åºØg†ªµªÆ«ÄïïûßU�Qg5 %©!¹Ú>Zcn„½©SŸ!Ñƺû<3þ$)6“.|¶qžjéŒ:¯ü≀Æ2-“,N7:‡ê�¸jXóñBçç®:s%võrá‹(+d-K¢øp��uüa„ÄøÉÒ7YÂò°§O+|Ëô'66E^­Í\8ïõ¬S¸lvlԬسW�¥´^²“©¶~Ö3¯f*IM=ëÇŒ²38Ðó  LPxuµbá¥ÂÎk±7±âúîav”ëB±ê7r)‰X}y“;åF½Ïì<„RïÂõËæ:O&°lâ(LgÖŸGµóÈ™ÚÎ<ÒÒŠy„zÆ­¨o[Ê^´
5Vć9Oñ>ÃIÓ.\œHº�Sá¤É»ŽпO÷j"s¡âÜvéj­“ˈ!lÀ
Õß+Ô¼ '¸ˆàÇ%L8	üöiñ}£ÌëºpØbXWŸ,ŠB\ÛB¾ÆeUlM ÈÞLÿŽ#�y†‚43OøÜSºN®tM52…kE’ÂY.{‹8¬ê£¼hs¬ÿïÿ¥¬ê% "컊p°¯‚³(µ—È=[yýÖùÒÿš`�£endstream
-endobj
-1701 0 obj <<
-/Type /Page
-/Contents 1702 0 R
-/Resources 1700 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1589 0 R
->> endobj
-1703 0 obj <<
-/D [1701 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-1704 0 obj <<
-/D [1701 0 R /XYZ 56.6929 749.4437 null]
->> endobj
-1705 0 obj <<
-/D [1701 0 R /XYZ 56.6929 749.4437 null]
->> endobj
-1706 0 obj <<
-/D [1701 0 R /XYZ 56.6929 749.4437 null]
->> endobj
-1707 0 obj <<
-/D [1701 0 R /XYZ 56.6929 746.6461 null]
->> endobj
-1708 0 obj <<
-/D [1701 0 R /XYZ 56.6929 722.5763 null]
->> endobj
-1709 0 obj <<
-/D [1701 0 R /XYZ 56.6929 716.7581 null]
->> endobj
-1710 0 obj <<
-/D [1701 0 R /XYZ 56.6929 701.9936 null]
->> endobj
-1711 0 obj <<
-/D [1701 0 R /XYZ 56.6929 698.8254 null]
->> endobj
-1712 0 obj <<
-/D [1701 0 R /XYZ 56.6929 684.1207 null]
->> endobj
-1713 0 obj <<
-/D [1701 0 R /XYZ 56.6929 680.8926 null]
->> endobj
-1714 0 obj <<
-/D [1701 0 R /XYZ 56.6929 656.8229 null]
->> endobj
-1715 0 obj <<
-/D [1701 0 R /XYZ 56.6929 651.0047 null]
->> endobj
-1716 0 obj <<
-/D [1701 0 R /XYZ 56.6929 636.3 null]
->> endobj
-1717 0 obj <<
-/D [1701 0 R /XYZ 56.6929 633.072 null]
->> endobj
-1718 0 obj <<
-/D [1701 0 R /XYZ 56.6929 609.0023 null]
->> endobj
-1719 0 obj <<
-/D [1701 0 R /XYZ 56.6929 603.184 null]
->> endobj
-1720 0 obj <<
-/D [1701 0 R /XYZ 56.6929 579.1143 null]
->> endobj
-1721 0 obj <<
-/D [1701 0 R /XYZ 56.6929 573.2961 null]
->> endobj
-1722 0 obj <<
-/D [1701 0 R /XYZ 56.6929 558.5914 null]
->> endobj
-1723 0 obj <<
-/D [1701 0 R /XYZ 56.6929 555.3634 null]
->> endobj
-1724 0 obj <<
-/D [1701 0 R /XYZ 56.6929 540.5988 null]
->> endobj
-1725 0 obj <<
-/D [1701 0 R /XYZ 56.6929 537.4306 null]
->> endobj
-1726 0 obj <<
-/D [1701 0 R /XYZ 56.6929 510.7109 null]
->> endobj
-1727 0 obj <<
-/D [1701 0 R /XYZ 56.6929 507.5427 null]
->> endobj
-598 0 obj <<
-/D [1701 0 R /XYZ 56.6929 477.5928 null]
->> endobj
-1728 0 obj <<
-/D [1701 0 R /XYZ 56.6929 453.2532 null]
->> endobj
-602 0 obj <<
-/D [1701 0 R /XYZ 56.6929 369.7201 null]
->> endobj
-1729 0 obj <<
-/D [1701 0 R /XYZ 56.6929 345.3805 null]
->> endobj
-1730 0 obj <<
-/D [1701 0 R /XYZ 56.6929 310.6805 null]
->> endobj
-1731 0 obj <<
-/D [1701 0 R /XYZ 56.6929 310.6805 null]
->> endobj
-1732 0 obj <<
-/D [1701 0 R /XYZ 56.6929 310.6805 null]
->> endobj
-1733 0 obj <<
-/D [1701 0 R /XYZ 56.6929 310.6805 null]
->> endobj
-1700 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F47 879 0 R /F14 685 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1736 0 obj <<
-/Length 1917      
-/Filter /FlateDecode
->>
-stream
-xÚµX[�Ûº~ϯ0Ð>h�ˆáE¤¤óÔÜÚì
²)š-ú�ìƒÖ¦m!²¤#É»1Šþ÷ÎpHÙòÊÇ(ŠÖäpøq8wJ,8ü‰E¦Wy²Hó„i.ôb¹{ÅXûÛ+áy­˜N”‚ÉÌj¬UÆt&ÓE|
-òîþÕ›¿J±�œ#õâ~=žeÒ”ñ|q¿ú½m[[¯ÊŸ7±Ô<zwópÿ+íJXš¥wq8!eFiãv|.ê}Q[ll?î	S‰‘~�ÑÌp�¹=‰ç<Z•äG•2e‰qWì¬ÇQ‹œåF£SÈŒ\¸Ù�û]Ê”Fî¾Ò jšû–Æû¡¬ÊápL°\ë X"˜Ì]æë¡nÚ¾twxõñ~Ô©áL(Ðh":Wsz §ÔÉ£dœÁíw„p6QùÉ
ƒIF®ñž´õí/½ížl÷à§ñ#ÝIŸ*Ið”éÜh87«Ug{o•ÉYpñ,QÂó�˜ËL¥Yft€\VÅ, ÌY–¥ù9àú*ຬl=š|*dÊ2ÉÓsÌÿÌv3Vèë:Ëñè5°§mºáO—4��ÿvUØ‚JÅrÁÕ9Þpo8´ÿÞÏ«xèDsx	“æ…½Wá¾mwÅò—¼õ/?ìa9ç,ɹ9‡NÆ‘ypy#V€œ+.§öù†Ð�•ÆÎuÃä·½íM;0Æ.E¼J%KRñG"þârÄ�\Óˆ�·—EÓ’™\¥D´ˆß-pMEÛTÍcQÅ-ÆBŽš
j½’s?|üúþ·¿¿ýr7rOR¾ÄÇ”ÿ².(ŠGüÎ5_5»¢¬!ý'<*ëuÓ튡l� òhÓ݈,jZÛ
«ðL=­4ýι²?ËÇÊyhšŠV
-ë.¦‰’vÏnbÅÓèv *�rõÄ�ÛœC‡»Lü™ª°*
"Ö+H,ž}[O¶–ÈEÝ?Ãq�Z~›“ÕóÐxØwµ]Ñòš®²;£[ ‰n�ÊíIm¸|„‡#>ÌÐ
J»‚+k˜}nú!”ùÓk9])# ¿ìʺ¼Q?tÅÐ8á�¼ïíŒK€0ùXg.¸ô@Ê„?48Ð%÷`×~Û4(ºáG1ZZ†Õ]OK�vY n¹YÓo9øÕà%Ô^€\ÑkXÈ@ÅùÂ�õÈЊ3	
RP‰µµC0׸àf÷»Úý€þ#xôlÓ½lrÐC{?´è!D¤ßmñdýìÜh½¯—E5žÖ¬g®0›h�þ¾Â–'*Ô>²s²<×pÇœ¥iJÿ¶¶Í~³�9*ÑÐg*uÍ´2¥çÁÀUJF5ÆxUpæÔ½"ús9l‰¶lv;Ð~\•µ¥5
-‰Í~gë¡GÓi	Æ%î¢êâÚ½'Ñü±–r׬<”³3þBXSªq
-0	¤PžLÝ~L!1ÅŠ’GrbPÈ´�Ô>GCgÇL%+ër‹‰ÞíboMÃ~—î4i<Ñ90ž1U‰C=U‰'9oÂí-^¬æLD·¦Eä7Iô¼µ5�0�¼,òi΄0‰7d¼�÷*�™Ð�
-;‘
-¢ô­]–è„Kš‡²§|Á¸IÈŠ/(yÎàõ!¯)PÂ[Æó<—UåBØCQú
-o§¾÷�P�c
µ·ž­¥>"†ÞÑÒÊ®ŒžÖQ¨™ž 5P~DrÍ›ÏC‰z*‹9?€ww¼àÏÿþôåóÇÿ¼a€×-g3ÅLfähg¨ð*ºß†«Rn>½~6æ|â C¹¨D97ù2"ó„%BžÕ®ç&/ÚòÞ*dT×qñrn˜q²YkÞ»ÆJÍíýR7
-ƒ÷Ÿè—¾¸VsAOÔb±*Zšøš£á*ÜдVÙ'[�º{�ì
Õ'i},©9B:u\þŒ™�
-endobj
-1735 0 obj <<
-/Type /Page
-/Contents 1736 0 R
-/Resources 1734 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1589 0 R
->> endobj
-1737 0 obj <<
-/D [1735 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-606 0 obj <<
-/D [1735 0 R /XYZ 85.0394 769.5949 null]
->> endobj
-1738 0 obj <<
-/D [1735 0 R /XYZ 85.0394 573.0107 null]
->> endobj
-610 0 obj <<
-/D [1735 0 R /XYZ 85.0394 573.0107 null]
->> endobj
-1739 0 obj <<
-/D [1735 0 R /XYZ 85.0394 538.4209 null]
->> endobj
-1740 0 obj <<
-/D [1735 0 R /XYZ 85.0394 504.6118 null]
->> endobj
-1741 0 obj <<
-/D [1735 0 R /XYZ 85.0394 432.7569 null]
->> endobj
-1742 0 obj <<
-/D [1735 0 R /XYZ 85.0394 303.3232 null]
->> endobj
-1734 0 obj <<
-/Font << /F21 658 0 R /F23 682 0 R /F39 863 0 R /F53 962 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1745 0 obj <<
-/Length 3971      
-/Filter /FlateDecode
->>
-stream
-xÚÍZÝsÛ6÷_á™>T™‰X€
-ç\9æ=5`½Z7õ¼êñ¼j×Ëâ©œ'Ç<uf!úéÌ|ÞS÷G÷ÔqîÑ3½·¨I. |vÑ0èpÑÁÉÙôOçÃE«ö¨èš»½®`�[ߘ
¨32¿ù¾¤ãüM´U
-Æ—K½]6Ø�çtBؽQŸv…ûÑ{TØŸ[t'ìýEÇ…Ý_´ªç€x:o&N*ðR‚–çÆ·¼ÐáIAÍ7+N‚þ´­¨1'êoij°€òêŸSÇ?ßýÌ�ëË7Ü+OÆœœÓ“"8ƒ#
-“mÃ
-[Á6ÄÚé=¨ôœ
>QܼjÃOð`ì™xSÈó×’øEˆL·eÉPÜš÷ýv—"õrO_v¨÷bÑNV±ê
l?TkðI.ØOrñ5¤/	ZÆÅsœêñ %Lší«°T¡Ê5�\
-)¶;)	~cSÔ-î둾Ò:ºC“b<ˆÈ'ÿÿÝbÎN�¾rv¨‡1ý�ÉA+#¯Óîþ;Ì«Œy•‘!p‰†�õ#Æó$@�	À‰S‰<8v¼dÚEm˜ù²£¸rÎòz D)û¨zÇÑ㢢0,#ÅTdWòkOýâòê»
~ ßGžÎód’H{�Þ¨Ýâi\<å•O.ð?ríd[/)‘3é‘Ð"]ùüNiÿ8r\¹=<®Ýº±O+5ÜËuS‘\E™w‚z¼çûç.Û”�:·ç*½^Þù0ƒÑM
~ð15MûˆÑg{ØõD]>
¼£9Ò"“(‘à(P.~þîCB$º~@bX¨ªg´ÖW|ò	�žiß=dϧ[0eVþõv˜kÊ^ÕWèz>V	RIžŠì„†ƒVíÊcã¶ì"z)ˆ`$^RTÜmþq52¬Dd=ã�	o1	ØY,*í‹èʱE蘈.L6[õ}Ù†¬%ä„ý£:ƒ5z³§!´ª�¢ÀU¹WÒ…ÈZ…+Øå3¾ëÄi¾æ(yýãÅñÒïcѹ?�d8ŘDùÞ4””>1;‘þEw°=ø¼é§qûU:Û‡†�Éw«ÃŽõÎݪÝ5Æ1w˜Q@ŽG’¤Cw+L
-œk,]IvfRqé`%ýK»q—Ž8$ÏNW`r
-0+–þ*J÷,ø‚¤/€D)�ïãúµI$‚éAðe_'œÿ^fĪ0ÊĪ&¼)ÓDªŽ©ª§¨XI±Y£Î7K2mÌàæ–a×+ƒë»j-4ÚI±{!p}ïo>!òe]¹»é-g]õP.Ãw"0�
-”Ø¢/Û†H½m„ËH Ž0]um¹¼#"‰*ß+—R‰ÊõÔ¸9.Ã;ÈGtzX†«¡à ±Jôtäj£	�;þ۱ˣ,DŽÅª˜�C¹—)‰�‚ˆ˜:¾—èuÝÐgØŒé9|ûîâåôÝ«l,§ÌÒw"¨#KñÐx¢@u”'jáÑñwÞFÔÐ
ñ`ìA<Å>s"Q2ïC=Lbò
-œÀ4d‹V ½K²Üì]½„Á…s¯I°Måz°“âcÉÝ�‹ÐbKöýãjmÁL­8¥×BªÃ>]ÁãsZVM!äm˜¿§ürK?ŠvÇ€oxóEÉSy¤·‡‡ª­|0ÆØ8È9÷]Wá
-ê­yŽvQ.—_3¤¼Ý5TÉ
-weþ>Kô@yð�Ðd·cá„`
-endobj
-1744 0 obj <<
-/Type /Page
-/Contents 1745 0 R
-/Resources 1743 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1589 0 R
->> endobj
-1746 0 obj <<
-/D [1744 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-1747 0 obj <<
-/D [1744 0 R /XYZ 56.6929 752.2728 null]
->> endobj
-1748 0 obj <<
-/D [1744 0 R /XYZ 56.6929 504.0748 null]
->> endobj
-1743 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R /F48 885 0 R /F53 962 0 R /F11 1299 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1751 0 obj <<
-/Length 2762      
-/Filter /FlateDecode
->>
-stream
-xÚ­ZßoÛ8~Ï_áG»QI‘”Äö!m²EÝ6»I�=´yP,9jKYKNÎÿý
9Cê‡%åpw(PKÃ!gøñãÌ�
-_0ølj
-˜Ðrk(ÆÕbµ;c‹'hûxÆIçÂ)]tµÞߟ½ûUÄè(Œ÷ëÎXIÀ’„/î³oËËÛÛëÏW7�_„Š-ß犱åï—Ÿ¿^~BÙí¹——¯ïà5R,%nÔ"¶¼ºùxþpÿÛÙõ½w¦ë0gÂxò÷Ù·¶ÈÀïßÎX t¢¯ð®u¸Ø�I%%…p’íÙÝÙ~ÀN«í:€I ’0A c(Dšu¾É÷f®zÙlÒÆ<%Ë¢FÉ߇|_ä¾”yžÕØÞT(úQV¯®oŽM?ò#JÒ’ú¥Û§j_4›õ%+Ú[yÌ‹ò	už
¼BDË›[ßß|¾úÙ)꾃YUæ4ÈÑ, rÁy •
-íôž÷ç<YV/EF&Ø2}&áó¾H›Üô x(ÎX ­a03†™*uÑä:`:¤c&;2�„Š�A}:”€¥�¢È©5àÕ./›ý-Jì"t§Kj&©K™î
-ûþµ²Æiù‘³ù*Ï&z<o4x]<‘¹ïL±‘
|’(Ih;ü4¶qÇ.*À0&ï„Z;ñ¤ëa�Ö�.œXÄû,2Ž–ÈWÁà ‘‘ì¯'Âdͨå=q“IØ
-fžLA¤FÁ
-ê<æ@ˆÂìcóf¢–Q±”C³øðõê–¨Žk5Øчr›×nåJü½üë×?)&Sì¾ñ3Éb~¡¡n£zAC¹Ä
�«´¦(žâ�…öTe‰Y¥?0ÖzS4
-EÀB½A£ŽÖ�œ–§ÑËê„E!,wªyÃ^ëÔò€EØ&’¾id‘ô,bÄ"éY$=‹˜c‘ä=1Ç"Ùe‘J ã9°…SÚPiÕŽe“þŸŠ¶ªWÊ$‰/@»m˜’x2ÍI±  )C(.T?jt*<JäkÇ·Çtõã5m—%Éî9mŠÇb[4Çsι	S‚3ÜFã{Ê—•ùßÕ
P!Ôƒ‘­R±oé–Æ-¬™Õ¡hLÛ$ßd¬ƒP†jžo]­i¾y-�&d�jŸŸpN1(š¡n™5îµN­÷9§ú’÷ÍßË®ª…³m³?‡SV¹Jq?‘73ÃHbT3<CÌ·Å93vša;fÙNaFù8Ç<Ô14æ¡6«hÞQL΄îBDg$(êˆR*HÂd˜†ýDL™™ïMvœ	!R¨@*-ÞXÒŽÖÌ’:-»¤YµK‹òSOÛÝ8\W<JX<ï�×:u¡¿®àCÉ»çÂ�)èDäJx¨s„ÇÄc™2¤v*þBnR³Øý~°x[zÆy�Dˆ�C1ª¥;Dv'>ðVB
-™+î`�…†€TãøÅ}«Ÿó•¯¼my•Ž./„Ð�‚’§O†®¯ýÓtÈH»`–Tª6…­®">~ VB pGõwy³z·Ïëjû2u¬Ö°*¦Nh'šÐIÑLàyÜ’½þÊðÎÊPˆ\AŠÆð­}¬¸;z
„ë$€³€ó÷'cÆ?uÜ‚ZQ‹h¬Ò§$žw÷ÕàTNî)
±%†0¿§ºZÓ{Êkù0ÙÎb4LÎoÃä‰õñ0Ù3oS³	I65ƒS³‘`j6Otæн5
¸¢¦%Ë
­K<2:Žö¤>œª0ø%Fã8}ÚšæQÚBN‡g¥ˆDY:ã�®ü�¡°‘Œ·‡Mfø‡Uã‘Ξ½l܃@y:åHuåý£;ÿÛ,0Í2uZÄñ,ëhÍ°Ìiµ,ÛT¯L‹e3ñ†^ëÔƒÁ…—†
--Ø»ãžή3®o¡ë#ëXÝÿbð楀¹
ØæM^B5<Éa®Â Iâ7Ît]­i{-ÏáÕ<‡g�·>±>ÎážyËa`
Uð€A‰Ãæ	#(<|¸Â_ÃáÕ&_ýÀb
-LCÖ ç©ÐÑš¡‚Ój©°�¼!œ5ÜÞžX¿!왾Â/†SÅ!}P|$ÔŸ.ïîÜ…l^v>Ãù"ÑëRmä?‰L€ÇAGo`ÛQš†Ö)µ7‹
¬ú	¸R	ìˆYÃ^éÄrZ	;8õLÿwÈÞßú?áêJe˜¿æ™óäÿç?iÿ$FÆ�
-endobj
-1750 0 obj <<
-/Type /Page
-/Contents 1751 0 R
-/Resources 1749 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1754 0 R
->> endobj
-1752 0 obj <<
-/D [1750 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-1753 0 obj <<
-/D [1750 0 R /XYZ 85.0394 695.9587 null]
->> endobj
-1749 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F39 863 0 R /F48 885 0 R /F53 962 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1757 0 obj <<
-/Length 2840      
-/Filter /FlateDecode
->>
-stream
-xÚ¥Z[oܺ~÷¯ØGITR¤(©@$=ÈA{êž8h�ÄòŠ¶…h¥ÍJÃùõrHŠÔmO[ìƒ(qÄÎ|s£–îüè.±(’b—<N	MwûÃÙ=ÂÜ/WÔм±Do|ªw·Wú+ËvE\ˆDìn¼µò˜ä9ÝÝV_¢w1�¯a½ÿøËõ›D¤$‰ÞÞÜ|øíýÇÃ}J€‰þþö·Ïoÿ†Ïn® ûåçë»Û_¯>Ü:a|�)aJ’ïW_îÈ®¹½"1+òt÷7$¦E‘ìW<eqʳOš«OWÿtz³úÕ%ð4�Ó„‹ÝÆãø/«‰Æ¥@”¥E,XÂœšx¾¤&K¥ÔôêKÛÝ�äþ|êåtË4Écž0ï�%îŽjΆ#{ÊXÌIš„üo•¾»ÇÇF^¿a9�†'=H¢^Ã5�êöﻇ€€F¿¿ÇëW’’Ó5Í#½‰ºk‘¾’}��+  H{_8¨Û	»ïgyz¹¦”F
-oν¬â™ßçL€h°ö¶zTh©œú*	\üž«À·ÉÞQÍùO\°ˆ
·y(À¿´õÍÀzâ0B%áØ>Ø¿^€-%EL“,ÝÆmAÓ£y8fÙ¡ÃëWB’¶²‚H
-1‰`ÑñT·†kx¬€7Í¡â«…�²Áû}w8Èv°““źóp<ÛÉ
-èꇷ¶£RðÐÅp\p,!bFT‘¿]Ô¥µ4*©h×á
-28B¡Í{®R78†Óª\€V×`“¥l³ÏÕ®¶×¡ruZ6©xzm·
-ƒCYÉת
¥#]_ÿ”ŽÁzOã€N|l^&^Üswí&:î%T/µmpÿHÊôê¡që«b˜ŸB$ÝD�OµŽ Gåôý4å[äqÊ.°54s®“ª˜Aõœ±�íͨ‘/•Ñ’ŽÉN]wëú²­G=qÍœÐXé]Xý½^_̾rß8Wc�ûhF/Œ>Õ†),Õh
-•Ä”­×Möcp�ñ_®�
-¤YA·ù;ª¹
-ïýEpÌÔ#x®NÍ\Zö<½È×~«Íç/¯}ûŸþàk#¥ü~.›°<û)ñøjÚv-„¥ú}\Ý@µm[q\êܺ“0ý1ÛãF×ÿ‘ÅI&.TÑÆ ‘ôI:6
-endobj
-1756 0 obj <<
-/Type /Page
-/Contents 1757 0 R
-/Resources 1755 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1754 0 R
->> endobj
-1758 0 obj <<
-/D [1756 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-1755 0 obj <<
-/Font << /F37 747 0 R /F48 885 0 R /F23 682 0 R /F21 658 0 R /F53 962 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1761 0 obj <<
-/Length 3318      
-/Filter /FlateDecode
->>
-stream
-xÚ­ZÝsÛ6÷_¡™¾ÐÓ
-!¾HâfòàÔNÎmš¸µÓ»›¶”HÛœJ¤*RNÜ¿þv�DŠ”|Ó^2	
p�]
-×R&“ʦŽÉSá1}]M×¾¾<Ü.—‚eIÌgý5GœÕ˜µ�=Ö\¦,Sü€÷mÙ�Ï¥L£î±t�z·^”[l'QsïÆP>O–Ó„Çü‰ft�{æ›MyΣ|ëºU�zõV÷¥±aI¦ÈŽìë|]:ª�¬"e"I8Áúã…¸`±’Dq9±†aR
-E÷�ªëËœDÚò©Ûª€}ó,*ÚÏ¢mV»®d¸úl.²„	ÁñÈ93Z»ò�=7
gTÞç»Uç:OùjGãUëžtr–ò×8µeÝ][Á©ÕžŒæÕtèÐl»¼+×eMóýÁJÓ?²L1
Ø¢
¿*»å«m	xb°·û©Ò,QÜá7°v¦"{NÀƒ+€N¢ºqg S ‚­΀DF[Qa7$-ŽTôfÃp¼i„iá5è¹R*ú
-ìÓÞ6Šf�Wuë:«ªíü”>åøÖxš±Œ§¦Èqù8qW2cp
^k@Š‰¥8˜
íWrò]É«VQ¹£ZÒI9�Ç‹kÁx"“¿
-.6²äd.“T‚š&Ùi›Ú§:nS•µ©‹Ý}[ýY¾~3²ªJÁ‘rOòTcæC«ªKM¢‡Ü­U^›±ñéòÆ5
-:�Ó¸$h-ó]Kú˜»Þºký±+·Ï´M\­3«Çt�gLHi^еÕ	]óTV×Ê¢n_5R4‘0€¡>Í8P�9„/hßd6d}�¨îíid^Ù²pVYJÔVMMï÷˜Y�c¡¯ü}UÍW—õÐ�x¸˜Ðš
-H=
-D�Š2ðA'�ا:Ä@e÷õKÝü¶† ¬ZUu9Âc’±lëiþ�j,À�`ïÓ81C	n¶Æ=JdtNËÆ>‹Ö
®ªßKײç‰�Û�ØH§'`ø€ÏÜ=àhMK3íNçv«¶ÑÉ:'î.”ÂÖãn�×s‡ºdNb3´oŽo^ä‹.s†×¿¡SH휎‡;hXdlˆAìohë0TæËG78Ü“CuDªÜuѱ9Æ"½@ ª¤	ËÞçK¸M€ÉÖ¦ËÝj§>
-±™”¢ÜmB,Ÿ<
©Ë…,°¯T�âEµ>÷±B°ÚÈwÚÔ¡9+‡ ªQÓÈT·ÝnÑ'ǨØ/¾(!K®
-,˜|A€@5–à@[lb¯‡"\t�¸n0Nœ¥	˜‘ªÝ¬òg´‡

H$:4:ŽÆž4ŒR¸Üºž¿¬„÷|2Rå+4~eañC_ü`§jÉ
-BÈ.3=Ä„w¥T6ÌRB'0 Ÿ\·�Ÿ¶Ç¯P—diú•ö¨N\©§
-W
-®»-—£ëÔ1d"";Í<P�¹¯š4U|Èþ§‚�ïˆCÖÿöê[×9/îÒjûlm1ÀŽ<ûŠ•°c!p¸àÇïiFES�u|ùþç®�ž‘›d?ûãÍÝ”,îΕf™ÈøÐó�²ø¼(ªB— Û˜p4õØ£ô1ò
‚41ƒœü$ö4ÇA@4
mõ°|ÌÛ‰G°V8Áדò^?ä�©0²Ïø[Ëp. ¦ð%æ¬uÞí‚:
-,˜`-u6b†ª­{�îÖ6lØ*°ø¶ÞT+«\!tÁÖür¢¬2Á”‘ª·Ç—ŠÀ\Z–M—€ça½“¢à&€RôäöúÝ·ÿ¼¸½:~ûvƒ[zéþ{T'à©,ºíKLóßËç×_ÁŸ²„%:“§ETc†h0œ%Ò$C!lî…•ÌÒª»ÍTð�C«ÒµÑ¨HÕAw¶çY´sÕ1ìƒü4í/>4s×z‹‡‰‚§TL›P:ûº¯òk{!¨	Ũ¹€e¯l�Š
-.a*£©ƒ#÷5Φo®¯âÀNÙ‰ÃîÙ){;­I;%R4¡ÊÌ@jÜœüÛ–*¬8ï/9VW
¦%å2ÝsþŸ¬•HÀå'æ… ¥OuÜZªà±ºfcg£¨%�8#V§¹ª1û·ÅYªy:äÿ/æ\ØJ~N"7{'/�÷N̵7åÃ?×ÉÝtØÐœJ�Ü–‹ª"ïlÙ®ÇÂ	&�ºb&ƲX§Có×0Ʊ®ƒ7­1}Súïc̯8ï/9�1Tk%ôžócÖv…-Þc.š‚½�6äaàEÜíüðé=¦Gw×7ï¯ÜVütõÓõÕí„mˆ
-‡Â™àø2'éå^úUe¿�¨Ã?Ž[§jWü\¥ýtíx¸â	‹…9Hì@V™?´ß�K¶¢¶>�+F%U"˜öÖx)Rú¯
-ÐZBÀ�+ËĽÆ_cR
˜÷Ο‰�r‚‰8óíRÛ‡}C6ÎŽÐ×Î6ç$OUÕSUìlÚ"EØŽ}åE.Ib‡9*âHûjòŵ‹²]n«}™ó<WŸ¼óEóTâ¯4À¨ÑM‹Ø}A·¹!öì½sü’óÜ”=a£í@ŒÜGTHî_Û»ÁÆþþö?S€aûË
·bã¦/¨�±NI“wšga&üõæ«©=ýÂúó¦<ÀÈr•·‡¸±»›PøÒCQHûØìVÅ0žÈ=Ôûµüý”ƒüò�w«fá.>u*!è‡øHH¼\­&TRp’—Œ~�Ͻdô[	;h£IZ4˜–Z:âû¶q3ü2^™m*hË26ƒ
-’z¢ŠK"K¬@`á×ÆÛÒVš©šX”A»´ud0ºÛ¬hÜY!aAƒ€àÊ]'µñ¶mS÷N	_ô°=ÉX¶;Ÿ,LÓY*E>@{ ú>@Sž
-endobj
-1760 0 obj <<
-/Type /Page
-/Contents 1761 0 R
-/Resources 1759 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1754 0 R
->> endobj
-1762 0 obj <<
-/D [1760 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-1763 0 obj <<
-/D [1760 0 R /XYZ 85.0394 204.5196 null]
->> endobj
-1759 0 obj <<
-/Font << /F37 747 0 R /F48 885 0 R /F23 682 0 R /F53 962 0 R /F39 863 0 R /F21 658 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1766 0 obj <<
-/Length 2180      
-/Filter /FlateDecode
->>
-stream
-xÚ¥ÛrÛÊíÝ_¡‡Î”š­÷Æ[ßœØÉÑ™Û�”9í$y IÊâ„E¤ì£vúï»4%Ñ£t:| ‹Åb
,.+&>1ñÄ2ž„±f>þ$­.øäæ>\K3sD³!ÕÛåÅå{Nb2˜,W^ãQ$&Ëì‹÷–I6Üûõn±œÎ¤Hî]ÝßßÜ^Ïÿ�c4@Á¹÷ûÕíç«�„»ŸÆÒ»úp³˜~[þvq³ì¥J,¸BQ~\|ùÆ'þÛg*ŽüÉ38q,'Õ…öóµRS^,.þÞ3Ìš¥£œIÈ1Äc*Ð!Â�T��ÓY
-C¦#Xs ºfÓ
˜Gñ¨É?Ø	$âÎ…~u])ÀE/31K6›²È3T¹”^Û¶['݈3G’ùQœWœâ“�ŽÆÞâ™PÔEW˜“ÃÀYñý«$³”d+
-	WÎèTBøõC:(ñ†Ü‚·	ÿ'·	‘ãQÜJk.ÿçÛä4Ö˱™¤f2ÂÈ£|‹XÚùõ-	°ø|÷iêûÞr<¸KŸÉ8hÕjÄ(1ÿóñ\E±39y›¼‡©€À[ÛÁ®(QÇÚ£ukB’˜€úÊ}fË·u‚N˜”Å¿L
-ÔeBž�_Zig±í4òvuûJ¸
r…Û÷ó�Ô[éû(¾^æ]z¹ÍÛ¦|bpÅW½FL„°?Òüåß¿Þý~óŸK¢nÓ1¸Û›,nnH
Wwçcüºi;Œ¶ãèZ‰ñ"Cd4@fuÛæéì{¾ÌëÁ¤ÙA[5@-¦{ý}zÿZ)¬4ˆXè÷tã
-–Duê÷íç‹óGßs±�6Ì>€í	Ó5

•é—r•
€T
�@3¥g
-Tú˜¨Æ{X
-�7tÀâõ¶§z9(6�_fÉ»¬¬·íòùé›C¥c¥§Â&A»Ôš–IÛŽö)ÌICÔ3¼aZŠß¹b�5Ý«üÂø˜á§ówÕC>Ú@LJ-Ž9vg9vûÍX¶‘
-¬Íõ1¿?Îò{NŠîU~ªçG-ZzŽË£/³jd—C�Veò8¶‹f:ŒN´ {(°U2G¥Á·Ñ *Lâ0h\ß,Þ}šß/çw·#ya$,Ž·�JGÃÒ/–4øk‹jƒéHÄQ'Í„©%Øä[€+S¬áØ\gì;$MC®ìëø×°&)KË�CÂzÿ¶<¤�M9z8?¿·rfÅ@ˆä­-tí�,IÕ1”OOEj1|~HL
¦¼?¨Klmk@
-­�;,Z[ymíŸç�ΰ½Çâ)¯ßŒ˜BB”àÚw>óš)$„Jß]nÓå¹]lí¸6e†
wU•˜Pû6¶„,½{<"…„ø¾xÜ1Û'¥>‹¼QF]'IÂ?Ší”Õɽêñ
-endobj
-1765 0 obj <<
-/Type /Page
-/Contents 1766 0 R
-/Resources 1764 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1754 0 R
->> endobj
-1767 0 obj <<
-/D [1765 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-1768 0 obj <<
-/D [1765 0 R /XYZ 56.6929 626.4701 null]
->> endobj
-1769 0 obj <<
-/D [1765 0 R /XYZ 56.6929 517.4334 null]
->> endobj
-1770 0 obj <<
-/D [1765 0 R /XYZ 56.6929 438.0429 null]
->> endobj
-1771 0 obj <<
-/D [1765 0 R /XYZ 56.6929 376.8269 null]
->> endobj
-614 0 obj <<
-/D [1765 0 R /XYZ 56.6929 339.1376 null]
->> endobj
-1772 0 obj <<
-/D [1765 0 R /XYZ 56.6929 306.6767 null]
->> endobj
-1773 0 obj <<
-/D [1765 0 R /XYZ 56.6929 271.6646 null]
->> endobj
-1774 0 obj <<
-/D [1765 0 R /XYZ 56.6929 207.5268 null]
->> endobj
-1775 0 obj <<
-/D [1765 0 R /XYZ 56.6929 137.3205 null]
->> endobj
-1764 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R /F21 658 0 R /F53 962 0 R /F47 879 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1778 0 obj <<
-/Length 4061      
-/Filter /FlateDecode
->>
-stream
-xÚÍ[[wã¶~÷¯ð[åsV\\ì9}pö’ºMœíÚIÛ“ô�’h‹'©);ίïf
-ìVµWS­²IQãÓNšMW5u±bêöJºÉãn]ÖQž—Õ|I]çeÕ-a&OƒëbÍ­†_Ý|à1?jÙò÷ÍÃÉoyüºèx9r°X½q9¯gÙ´ÝÈ¢§©†�³HUÊ$7F‘�–Ínµ �ø´+·/Ô¬ê¶+¦#{øôìa#0å_n÷i-ýXUðù"EÜè|�¥³Äê<ìÁë²›¿Þ–m³zJæMý0Â?,2K¥æìq9ÕZ%Ú	s9Uа–tÿø<žR®g6HiZŒÌ!Ó$M�ã.¿#ŠÕ
-’—ê5ƒWÅ+-?íª§båµÃ˨	â躪~ì7ÂPÊ*â’¦Og9Úg ¨Y¾Eû+Nt¬N%RKõyµP2qƆ	÷ëâWÞêâH5¢6¼l¸Ïõí¿¯¤”qS`Ì,ÍÝpSþ¹,ÑÀ¤>!�4ƒ�T�‘é›1a€ž[™‡ô†Ï][.^�ˆ$-”–gD¡’Ô¥¡ÓsµZÑ EוëMÇÌ7øT“EÕnVÅK¿"߸ûášdßóÆ?Ì݃wÐø½©YfÈ€L@Å-sà�À›Ö½×ƒŸ¡Y3«�g–1X½€1aíÁêi3‚}j•NŠ]·l¶UWtÕSI¤à~LoÕH&þ¡á‘oáJ0hhí­ÎÓppúšüZ?^:�ܧ™,Ê_„Pu`höfá�nï¨ß¡Pq�bèΈ3¯¸Ô›~<4»`.ÁaEoFkàÁ¾È�ä6hÉt>®§*ÍÕTKïU·Wn²›w¸tMîß�Á!¥ Â[¿hh å]ÉÉýò…ç|U´í˜
-I‘XÜnš|¯ÛP‡òĹèq�‚åVÌÕ¼`†g%=Ñ®†¯šæ×݆h-ÛªY0ƒ[Ò;eMâ¤PÃíy³,š¶.y‹ˆ;ßäxØì|c^îSã†'¨Û‚
_/ʇb·:,øæ›[z¢#¿©»r3£7?ØlÏÙOÞƒ•ÛYÓúÑ
ìºÍ®£6�h'�e]nm5õØ×H€ÆXyÖïæÊEgã�#yÂ9ê$ƒp”n1)ŒÌ‚ÒmǦÔ&;n`ynz	 &$´Õ¼ÀósÃ"ópÏ=´{a’ƒ„/2ûú
Cb”IídY 3R©ô²
Ú†|ÝSµð
-Xí©7
-rrý‘ê_!y%‘G³œÞŽ#.mÍäJ5æajÒ
-€„àí$uó0"ü©é[yà1No‚Ã=•{ud´Šº|,z	¦ô;-¥yu`z‘ù½ÊÚ�y °pm°2Øó3°™Û¦ž²åî »yâøõiw…é.ˆ�-YpקŠ�ævϳÄZ+wÛÚÝ�s“»P'¥	*f§á`œ+pOLï‚øø–¿
-�œñj*Gµþ¾ÃEÞë½ÿØ×…yʶk¿®¾¯mLЦéxE"3ò¨¶g	gúö¨·‰ÔÙùS(‘Åé½µX¬H¢¬•
Ù4�n><¥D
-±	ˆ^&›fë3«N-ÑŸ‡ÅrØ4û?^c°�ÂkÙˆbÇÒhXù×lµI]ðìÓn\NeG°ŽÓGçølD9òŸH!s 6E^ç"«H{Ù”cØ_Ú,6VAý
ëˆð
-_Š‡·=öF`“³TaÆç
˜-µ¼Z¬
¬¹ÿ’»·]±å3ü*‚BÅvÌdñÓ‚¿›…Ïzƒæx‘,
-Œ¯¬ñ¸«¨ã%›bŽïW«æ9T²f/‡•¬ž=‚“Uøp?ÑF¬P&�\Åžr:�ø‹T:5™u#çÄ{5(èä‹'Üjèù\x3×|S=¸&âü$ñhª&{BSwäuVt§1Õ%ÊîqÉÓŒ[¾Q‰Íb3ýç‰ן Œâõ¨Üƃ˜çSÃdÿá5
üûx|561Y´‚/`-:%Xî©£¼LBü‹ùën»Ñi­ƒÓ:¬¾9�eo‘Ø{´€¯Tt7-X]í-Θ|¼¬d4 ­xÆõE£ÒM=Y‘còê@—24à¤}§	G@ê×åkÐOÞÑi‡iK~M×7üá
²ÏÜó-­O:M¢Sí>§$ebðêÀ²{ä”q”·§ok¹Df™=_~T+q|‚ÁË´šªSS¤·Á2]ÀkIÕ°£#^øÝ›*_HeÎF�Øè¡�½Ã¡}£ 7 6`%üMàÒ2ZËüÆxŸŸ‹ ØÁu™�+¶ZÈ
-H?|
-endobj
-1777 0 obj <<
-/Type /Page
-/Contents 1778 0 R
-/Resources 1776 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1754 0 R
->> endobj
-1779 0 obj <<
-/D [1777 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-1776 0 obj <<
-/Font << /F37 747 0 R /F53 962 0 R /F23 682 0 R /F21 658 0 R /F39 863 0 R /F47 879 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1782 0 obj <<
-/Length 2136      
-/Filter /FlateDecode
->>
-stream
-xÚ¥X_sÛ8ϧðÛ)3Ë?¢$î›Û¸­÷Ú4Wygî&ÛE¦MeÉkÉîæ>ý�¥H“tæÆ) àÀlFáÇf2&±âj–¨ˆHÊä¬Ø]ÐÙÞ}¼`Ž'ì™Â1×»ÕÅÛ"™)¢bÏV›‘¬”Ð4e³Õú6xG¹	4¸ºÎ²ÅûðŸ‹ÿ|\\_†L¥Ró››ÅõÕòß—!—˜�•ÒàËüú�ùgÜ»¹T<˜\d—ßW¿_,VƒZcÕF§¿.n¿ÓÙ,øý‚
7Ì~‚¦Ÿí.")ˆŒ„èwª‹ìâ_ƒÀÑ[{Ôë
-F	1÷ø‚³cDIÉ'Î�ŠÄ‚ëŒåÕ5•ýqsóõÛ¥”Áʘ‡ÅÈ‘tò˜¤Œ)<µq<lÄ“’4¢)°Žû¦í<r8#RÖ3å-\Î’àNëÚPipw,«7–Ý=n¢’°õ'•´¬;}¨ó®lê¼*ÿ«×øjÝìòÒ	©ó�V†oÚã~ߺ7°âQP:éEî˜ó¢Ð{·™×½´²ÝWùƒ×Ô¡±e
-ø‰€°Ü
-V̳÷Ë%p&ìQ	 �-ñø‰QJT$^ó'4NÇ”ï÷‡KP¥ÙʼÓÕÞQ4õIºÖ­îóC^€wp©ë¢Y—õWÍƯ"RwzÓØܺյ=j­f\Ê ®œÙ˜F9pÆ*ÀSuÛáFטgj’7Z}8Y�€nÜÓùaÁ·&òöÖBXnÐì�“}¯Q¸“™D
䧈‘öÅCsüÇ™«ò‡«Ïã¡F6ðˆÝL¤*gFek>�~mã§PppQcœ'8w*çmSCŒ	
ÖAôQ^ë9�|û�!rFaÀ¡	—î›»Ïà„Óˆp%Õ,V1(©_
NTš¦~8	‰áX$âæX7NÂÓ(y¼Ù¨xµÌæï>/<ÁIB£ˆ;St}*ñ³Õ;]wè„S‘{Wiƒ§�†«{ç<ësëOçs»([|qb­Ýîw�CáÃ(	PO¿Pâš‘dž­î�øyXãA/
-€ž	ÄÄ�®ÙûoË›Õò뵧0�÷9ÔžAj¬
-¸âÁ±uïÜð
-3ñº±¹—¨€ýfæ.3;åî`�ˆbÔJio¾±½x‚£<À€µ©ˆÈj§4õÛWËÜ(+±ŸÑÍ=Ù|$ ME³§ƒê×zm‡ÑàC\²÷ž›Î
�JBG¼äƒ¿¡ø©(�¿©Ù8v0…we‘WÕÃÙx‚áDø£G-*ò-y3 dP¨^ÁŒ×˜ÑsMšÅ	fÀ
-'8
åÑ£àÉKCàSÿ
åÉݱêJ
-endobj
-1781 0 obj <<
-/Type /Page
-/Contents 1782 0 R
-/Resources 1780 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1754 0 R
->> endobj
-1783 0 obj <<
-/D [1781 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-1784 0 obj <<
-/D [1781 0 R /XYZ 56.6929 751.8114 null]
->> endobj
-1785 0 obj <<
-/D [1781 0 R /XYZ 56.6929 637.809 null]
->> endobj
-1786 0 obj <<
-/D [1781 0 R /XYZ 56.6929 571.6272 null]
->> endobj
-618 0 obj <<
-/D [1781 0 R /XYZ 56.6929 530.4875 null]
->> endobj
-1787 0 obj <<
-/D [1781 0 R /XYZ 56.6929 492.9536 null]
->> endobj
-1788 0 obj <<
-/D [1781 0 R /XYZ 56.6929 459.984 null]
->> endobj
-1789 0 obj <<
-/D [1781 0 R /XYZ 56.6929 390.8804 null]
->> endobj
-1790 0 obj <<
-/D [1781 0 R /XYZ 56.6929 303.7532 null]
->> endobj
-1791 0 obj <<
-/D [1781 0 R /XYZ 56.6929 225.6163 null]
->> endobj
-1780 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R /F53 962 0 R /F55 970 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1794 0 obj <<
-/Length 2915      
-/Filter /FlateDecode
->>
-stream
-xÚ¥Z[sÛ6~÷¯Ð£<�\y™}rçÒ´v6Rf·Ûö�–(›ŠTEÊÞô×ï98
-Y\!O^ýöŸ¬`?]q¦`µÉ<p&ÒTN6WÚ(f´R~¤¼š_ý³[0˜µ¯‰B›„©£ÉÀšGé°À8ã0‹µ`<¸˜Có(جÂ�¾~gL€‚%©
Î,¤Ê6yû}›KDhÍbc‚‡˜ëPÜ©�¦NY¬¢¸ÏÞ|›/‹ß9—yÇ%Óö)§NýRå;ì¦SË
®�Pßòï×Bˆ)œ°ŠÌtAãéô9+÷‡w¬Tp#EÌDlÄ€Žø6œéTiÜì›––Í`bGýGõ?÷w·4ò;7|]»é—�Ì�™6 '3�jŒ´+’RÔö¯ºÂ•Ra÷e‡p!PØ×
-Rúb‚>Ý;IWffB¥ðR2•èähSGœÈˆ	nú
-5⛿R-Ú£HÓ”lì[·P’%ÉX
-Š±—šê_*û{#oÜ÷{ ñ4yȨ°ƒÑºr¯ÛTæ,ç~–ÛPb&#Åb.Gü4CQ
•¿J±ÔV!¡7vÅ鱸·û‡Ò«òÑGL—ÜŸ$‹ c¡ƒÁÆž15:eKhÌt7Õcì¸÷{üŒ‹2Y4 ¸¼Kþï0ÌNÇ�&'r8s�Z�)’qLá&WǬ¨”Lb8åý6A&Æendstream
-endobj
-1793 0 obj <<
-/Type /Page
-/Contents 1794 0 R
-/Resources 1792 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1797 0 R
->> endobj
-1795 0 obj <<
-/D [1793 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-1796 0 obj <<
-/D [1793 0 R /XYZ 85.0394 181.7045 null]
->> endobj
-1792 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F55 970 0 R /F23 682 0 R /F39 863 0 R /F14 685 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1800 0 obj <<
-/Length 1931      
-/Filter /FlateDecode
->>
-stream
-xÚ¥XKsã6¾ëWè°¹2D
-©=h„Ô‡—HPXÒh,6J€“G¬D¢(Œb�¯yÐê`˜zòB
C,-ÓWŒÃ\]‹Ñ²*›$+k3Kô_¤Ñ6ó_&¿™ÁîŠÄ#µ¬ÚÿÔКMÒX!IiOÊ
-i¥ì÷eÕÀ"Ð7¤Ø&yV¯µ*Õ.ÉÍÄn“šÙV튬®³ªôâø¾#y€dˆðõ·}4B‚I‡vR¦~‹ÌÅwY„s)zÑ(D|”˜鉰G5ž
-k«wÔ‡¢PÍ.[š©*—»Ã¶�c›Ï:CZ™õ~¹±Ò-å§ÛñµuOÇ' VíÛþÎ@ªžUiFͦگ7nl�±Ý?åZ
=Ö ¢=x;Ñpšew²VìŸ{àÉÁë‘Ň;VÚp#I9kÕ™ü:¾½ÿ4ñ 	Œ`&¥a\èx
-·9¤Ä�wEÚ=��˜¿HÄÁSÖè	DîùØP�š@iAÖsF ¤U
—Äl×èØÞD_Afí¨þ—Û\¡eUx4Eœ:^�.en»æyõ-+×fKQ8aí[µÏSC²ìàä{•þÛ£S
-�âh=×OËîg
-ÈCAbþ[Z“ù€,Áršœ¦GoѶZc¿œ&î4ÆOÊÆ:‡‹…;ƒ
Œ«Õ‰¯�e
-ß‘O¶ýåHIôÆô‡P�/ë;mÓw�
-3wÜw�‹¾|1Ä0
­9ûðzŒCº¿´Q«i/}»£2ºPð:¶@PÄDº uæŒgb lË7ƒ !q—„»
L� ò8ã'1ùdóóñŽPxXte€ïÊSïêÏ'6MŽ?Íï.
-…!O%Î.J¬«$€N5KòóÚ¨A‰_Ý�ê¢thÖÇjw^„9E˜ž6kΕÏB¡ǯ<mÛ�vž½ú7`ULU¤êùÌýÆüàõeÀ›dל»áJ ¨+:©M7z>«´“ŸC7•”ûëÑV_±„l&edkÛ`a¸áN#„½™Z<‰¡é%“›Éüúaz¿˜ÞÍ<õíÛu•''‚MiÈܽԌ:;Ö–öÐþëÏT¹œŒ¦�!¹öÖ2ÎL–„Ó,
-!@¿‹zª"Ü]¢üüúòÐù‹ÆqèYL£h•ÒÇ$˜½RÝ=Ô¾Öýÿ�~·endstream
-endobj
-1799 0 obj <<
-/Type /Page
-/Contents 1800 0 R
-/Resources 1798 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1797 0 R
->> endobj
-1801 0 obj <<
-/D [1799 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-1802 0 obj <<
-/D [1799 0 R /XYZ 56.6929 635.5323 null]
->> endobj
-1803 0 obj <<
-/D [1799 0 R /XYZ 56.6929 476.3563 null]
->> endobj
-1804 0 obj <<
-/D [1799 0 R /XYZ 56.6929 407.9215 null]
->> endobj
-622 0 obj <<
-/D [1799 0 R /XYZ 56.6929 365.2162 null]
->> endobj
-1805 0 obj <<
-/D [1799 0 R /XYZ 56.6929 326.9947 null]
->> endobj
-1806 0 obj <<
-/D [1799 0 R /XYZ 56.6929 293.3376 null]
->> endobj
-1807 0 obj <<
-/D [1799 0 R /XYZ 56.6929 221.9809 null]
->> endobj
-1808 0 obj <<
-/D [1799 0 R /XYZ 56.6929 108.6903 null]
->> endobj
-1798 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F39 863 0 R /F21 658 0 R /F48 885 0 R /F47 879 0 R /F53 962 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1811 0 obj <<
-/Length 3191      
-/Filter /FlateDecode
->>
-stream
-xÚ¥Z[wÛ6~÷¯ð#}Z±¸’D÷)mÜ4mâdk·»Ý¦´DÛl$Ò©8Þ_¿3˜
o¢¤œ³öƒÀÁ
-iÏ—›3q~}¯Î$ó,ÓbÈõÝÍÙ7?èôÜÅ.QÉùÍÝ`®,Y&ÏoVD/Þ¿¿¼zùúßeEô]|±°BDo_\ýúâ
ÑÞ_8½xuy}±�Y*S`2È–ˆèåÕõõå÷‹ëׯ®þóîêòâÏ›ŸÎ.o:Á†ÂK¡Qª¿ÏþøSœ¯`?�‰X»Ìž?Áƒˆ¥sê|sf¬Ž­Ñ:PÖg×gÿì&ôú¡sÊ°:‹m¦Òm(y.eì¬U#uX'Zi¯Žwïo^¿»ºÞÛ‰ˆ…�¥JÄN¥jÞÌ´r……g̸pÝE>]ÒéXëL_20Í,©K‚Áµtv¼äoRʨؖwÏdè|½¦Æ}QÛ¼-VôØ”÷UÞî¶2‹Š&>¤›$sq& qT7C®Ãºé¸¼n–¸ä7?X;à”"Vl+<Ër�7ÍT0©l,m–—¬ãšm¨C©Á%��cÙ®‹eùAU4¤¬ö¡ Ä5H6߬ï&Lÿ­«â°BmÃb§:à:¢ÐÀåúqN¡2ΜլÐ�Åóž:¥‰³$µÇåê¸f©S‚
g(ÙÍ…9ZÞ^,´’QÓixEÍ7ò†Gtåýµ¬î'Ü@¬·9¯ž'ý°„ÎïD6¥£›‡’g¯Û²®¨½Éy‰Ûb_8Pdì„ÊP
Œ3°©ÍnÝ–�k6y[nŽ‘´q"�;aó
×›.oóõŒÍ]ÞŸ²ÉWõ&/«=«ƒÛ-’ã’u\3¢�ƒdÓ�e{Åx
-JšS%6zùÏ�߈Ö-QA@bZ­J²RÛš¨WÐðVÅžÂ
-ˆÄŸ/‡–ä±ÕŠ—¸îfG»k‹v/¨�µáûÑ�–?>Õ*˜pC$Ö�mí%Fx•oŠÁO~¾¬ýïê°OØTÁ©'Òã>1ä:ì—÷‰ÕIX•ÛbÙÖÛ}4°"Ná$>*\`šnäÖÆ©4z,Ý›ºþHŠºyAµŒ2€Ç©ëñ
-}Äs�æ†l@ÛD2†ê:@59ûdV-ã<tnû“™m«,äSü‡¡dß9íu¦526J&'L;à:bÚÀåM{?“Od.9±d`šYr’Odi:YrÅxü]Ï:yoP:Êõª?
-C·g®7ôĦõm¶«Ñåç²i=¤Ÿ\ñ©ÉÍí(ú6õ§bu8ò ËÐBÙæp1OàòæiN¦4M›oÛžû¡Sš$=.^Ç5#ß(ø؇n¶Ëk|b(¬BcEæš1ûÊ
w>=Õˆ_�I ÿòT
-ÔÜ7o�°á¡Ÿòu	†Y(gù0FŽe^Va
-îÝKÈèEEÌá†ìÒóRË˧ðxZ•Ĥ=åö™×§Ÿj·¹
¢•<ÿïð÷öíË…ß‘Ÿ'/üñíÛëkô÷4ªê6ÇCïxVÉH	ø³ ©1P³!¨²
-<²‰èw<
bÍ9©†-&&ù'µ.NS›1+{¤Ñ
-S|=R�‰
-’Uc3�®è±G 
PÅ…sÈA×�Æ¿)ס¾œ€¬´/ì®'“�Ã>L0ƒ�¾â4j¸;m$ï;ªúé««˜ÚnØ;n*n&Φ^#c8Šì
-Yw9ÔαK[é§>qA2ä:Œ]—Ç®»Ùb9ÉtÐT½kwíâ®\ï£$T&Môqñ:®ùÆé™��MÓ±€¾LÕ2‰ªÿ!£
4˜†…&þ’M IX"úºç…Xh¡Î¥{`mÃÄx‰â�Dº¥‚\+ífÛƒ·/®XÓ3Ês€–¤±4P9�cF)¥b¨¤åØú,Á¡’Nñ{wYùÍöå–à‡}H¸X›ìÄ…Ë�ëˆ.ïC{ø¸1'–L3KŽ*0Î`'K¾ß–Uˇ~ÎÁC½ee4»Í&ß>¸Œ k®0¸â¢,÷A~¿ÛÝÄ-ÎHÊ8ÀÕ]%U
Àì-ˆ¾3cÃÔĉs#?˜³ŽJ3˜×�ÈN†\‡­Óqy딧®Ã@•Åª�ýä|4¶£²u\3Â�““Ú©K÷¯.ÓÈéç‘N�Oe½kÖÏ‹œØåì[%'�yÓ„Þœi>(ðlj>5ñW›Ø¸-†	­ÄÙ
-ÿLLƒí�2fFo“Í.t»5 óQ ‡ÖqRÝL3ýçå:”a	ÿ”3gÎS€kƒäwtg0©\„g5Méæ‹jaÒ]V£:k_Y¨®²ÈižP×e¬Û¹¦Ï
Qîàû®õar!h„Íf²Û,/ƒ½·LæÑ4b¸7“�ºçV¿OeS»iÊUA#W¼rM¿·¼ª—’®Và©©ëÊOæ<4Ìå.íñ{–Çu¾ä*Ä…PK´ëÏ2	‰Rw¤H§‚�Þ›Û?5ÄÀn¯£¿w�q ñ
q
{ÛnÒ’Ü�·[-™~[´OEÙ€{ôª‹H*T]vˆÍþ2ª�k%
âÞÑrÅ—ûñc- …Ô_�«	<B†?{'Š¸/.jCÈæa¿(ð´¬� ©O[Œür Oc­º´)ÔK
¯5z³îðó–Ëi	…›R“rºV§tK„Í„ëa aªŠLUÑi�sâ	ñ”
˜@‡?�
-…<põ	:*¯-ýjØäJæ_+á°¢¿šr
-endobj
-1810 0 obj <<
-/Type /Page
-/Contents 1811 0 R
-/Resources 1809 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1797 0 R
->> endobj
-1812 0 obj <<
-/D [1810 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-1813 0 obj <<
-/D [1810 0 R /XYZ 85.0394 751.8312 null]
->> endobj
-1809 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F55 970 0 R /F39 863 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1816 0 obj <<
-/Length 2975      
-/Filter /FlateDecode
->>
-stream
-xÚ¥ZÝsÛ6÷_¡·ÊÓÁI
-3wÅ·<Lö�º¸/Óæx¸f鎵X™˜›„`6†RšÝäD‹üxå›ÇšZõž iV”÷ÔU”kêÛåe“n=®·©ë¢ö}^懔x‚½Õ#ž<ìÇ}3L&I컬Ùå¶Ø䈧_�22Ët[WÔÛøo]\þµ
©}t (šš~?¦Û"K›êPûuÊÌOÏ@¢GÝ=ûÎ
 «:ú•×éšÔÇ�cÈ`wtÇVµ,*œ‚…Š
õlS·î½c™\–ÇÝí
cÕ†:?†kêû²ªü®¡î¾øÔ2mèëô
-ε=Ð(´d‘0vžÈ5BeOÌZ³äÙ'Ø*âzyóñ
-É’H¢Î jl#ïÅÉt?QòømÂhÈQN¸Æ7+ˆ]ðûU]wÛ¼]V¨éGzò4Ž®,øΓ¾ÿ�2ú+Ï÷øs§àÈ-œ�¸û�¹W5hŠW#»DÜ4¼]=”óN[Ć)Ó
--ÿùªÂ2kÕYõX_ѼL-Ê™…HËO8ÓT
Ú%Œ\ÀÙ€ÜÈŽ*A
-駎fØ–p¦¹’/°­ƒša[@MêK�w
-.œ±É<	-j„†ï@[#ÍmŸˆwÝ�êp̵�uš}þñjk¤÷›‡¢yØA𴮧™«8/’˜ÛAÍ07 ¦®MŸ·¢vÍSТFHèñ–d û4Üäÿ˜£!igt«M˜
OÂdP!�Í÷ÕúaÒQA>Å$0jÞQuQÓŽªE9GU�‡ *Òmjr(î‹òL7X›yÒZÔmý(Ä0¹dŸ¸ÛÀÈo.Ppltĸp˜/ßm¶ã”9e¯†²hc½ ‰æ|uœºõíÂË(­ëãng†0¶]#Ð5!?¸»Œ+#çå×EM˯E9ù}|)Ѐ„cl¦‚ŒÈà‰ç	lQ#ö¤¹7Ü$Ó'ÑIQiîÝ?¶…ŽÚ3D&µƒ·¥I‹²€èÍvµsBÐ�mt$0~
-:N»Ö4u&èÐwsut4�N8oiDã1‡×žÑ(!¶LÛÓDXü�>Mí¡™@C: ´8“ˆè
ë f4, œ†í‡[&	ãV¿°e
-U×ëì$Mé±°!Љ=¾úUSÿ_ùó]Eúžù‘|;¬r©¤S�Áq@ä3
-½\÷øýb,ö…+Q`É3ruZø¬ÒCº¦R-àˆy oëáî=	YµæǼµã¾¤ß;¿»/ìBOQ‚R¤YŸ”fX[¤«ëùîã§6¾r‡LOU¶ãX][ˆ˜Å"žÈK!Ïid…X”Y±N›¼në{>ZëË‘jÄ.p$=TÇmÖ�¶ðÌÓV‡k–Dò…«‹š±:
å¬ÎYÔ”(¦¤¶ó[ÐÈ–]^%†)nUËO‡"$tu÷¿Æ<¬_Ð\W»ý6G¿1ɉ5ÉãyŽtQÓiQŽ#�/&
Ûü1ßžÕ-5–\ä<a
4BX?c��Y@æØ£²¶z™gùÝñþ¾ÍuaÓ,‹ ڲ慂`5ò€r,ûv¦D³V˜ù-hdËžAS+ÑßòÝ}YuVÞß¼o³•zv„ª;ÜEjø0Á1LØÎ&
-ÊÒ A¦y) J¿p!»¨^ƒo@‡
-&Y’h;¿u
-
e nYÝ_Ö“ëT=]èO�bžÁƒ]
-×Ä‘«8½RHiñ±üýõ¿©“HXÓ}tÕ
-¿öˆÖšÑX
9ø*øå�fCbDk7•ùGÅuSž/…ËS
æ4¹öÓ=[®�ZÄ?G€NÖæÏ-Ï7hÁú'¨'LJM_ÿvõë§_®G"8„ì�Ã%�kœà“Òv[=7 þ§º#&Âî_S³	ý‘”;$oŸP
À%³õh´Œ~Þ$
4²Ø¢y Í›@ÔÛ›+j�Q††
§ãóòÈËú
-c­ß!+kÈ_W°L
wáŽÆ&¼–aã}ç$ì{pß
ž‹˜OCN%C7å;Œ�j!K}ö?vǺ!È�‡¢áHæî(wí6
-endobj
-1815 0 obj <<
-/Type /Page
-/Contents 1816 0 R
-/Resources 1814 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1797 0 R
->> endobj
-1817 0 obj <<
-/D [1815 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-1818 0 obj <<
-/D [1815 0 R /XYZ 56.6929 119.3275 null]
->> endobj
-1814 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F39 863 0 R /F21 658 0 R /F55 970 0 R /F48 885 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1821 0 obj <<
-/Length 1544      
-/Filter /FlateDecode
->>
-stream
-xÚ¥XmsÚ8þίàËÍÀ´VõbÉöGJH›¶!¹@çn¦Í¸5rÎ6´ô×ßÚ’ŒmÍÍMf‚-¯wWÏ>û"“>†?Ò÷9Â,pû^à"Ž	ï/¶=Ü_ów=¢e#ä4¥ÞÎ{o®™×P ¨èÏW
]>¾Oúóå—Áèþ~2½ºù{èPŽoÑÐánGÓÏ£Ojí~ÐÁèÝd6tˆ'˜B¼x0ÝN®œñûÉøãønz=|œèMæµcMç	f¥Wÿô¾<âþöð¡‡|Þÿ
7‘  ýmÏåq—1³’ôf½?k…�§Õ«608ó÷©gC#°¡Á$e
Û_Ê<�N¯å¯TFjÑYëßTýF?Ãís¡EºÕo=¡“µ¯„¹%,à›C
-8§•¡�
Iô
-cöŠxÔõl¢mµ¨t*Z¶‰vß\ÃVŽ»,E|$|�W"7RÅ´ØDå„Oé~HúNÛy­‘†¢ @„ø.(¬|ê
-Wo6™(´FŸfwöúAÂPF›yá[Gò+,ûð�èzᶚ
A.6åâíÍôJ™	´µå6–q^d!G-=4óK-݆r&¶,~™B«·ÙwQàS®ÇJ#åŒ[ô¹Q—“ºhXpshÀ‘xmøFŸçïï~�Û�„”�‘fæì�CuÐiœÊ<ÍŠx·=šus…	—K‘çCå­€Dº0žTuÂYl¢ÅwS,ªØrä	îUÂS9ãZPª<Ö›†U%)õÔUõX'X*ËŠ³ÞAÐâTZêéAáO-\*ŒåZ'iš&/!ãA¦Ï9T¬Î!``Ð
-†ÖÎ
-ÁœâÙÑô�¸¼
-ý¢sµ”Å»9E�늶{ãMUsÓ2>e›=å¥3•/<;ƒ[F¸@ÐI�džj¥›P«�å"Ù-#uslÐñ¾œ+
F¥yKË� \4…§¼®gˆòF�0é"‚N¥Ú"@Ä‘+:3]¨™kâeC°Óìz:´È˜ÇÛ8	³ä`j›ÁÌPT
mg¹I&°`¿áVCê·ŒTÅ­}×dÀ G‰ß˜4B“ÍXÂ)Ñ÷¼ŽÉû,–ÝTÞôW'¦ÉãòéiÅ�S r],šÃî¨8:¶k˜1u€¤Ž@ô3.Î
-endobj
-1820 0 obj <<
-/Type /Page
-/Contents 1821 0 R
-/Resources 1819 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1797 0 R
->> endobj
-1822 0 obj <<
-/D [1820 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-1823 0 obj <<
-/D [1820 0 R /XYZ 85.0394 562.7154 null]
->> endobj
-1824 0 obj <<
-/D [1820 0 R /XYZ 85.0394 499.03 null]
->> endobj
-626 0 obj <<
-/D [1820 0 R /XYZ 85.0394 459.6249 null]
->> endobj
-1825 0 obj <<
-/D [1820 0 R /XYZ 85.0394 426.4105 null]
->> endobj
-1826 0 obj <<
-/D [1820 0 R /XYZ 85.0394 390.6449 null]
->> endobj
-1827 0 obj <<
-/D [1820 0 R /XYZ 85.0394 324.0377 null]
->> endobj
-1828 0 obj <<
-/D [1820 0 R /XYZ 85.0394 263.3171 null]
->> endobj
-1829 0 obj <<
-/D [1820 0 R /XYZ 85.0394 199.6317 null]
->> endobj
-1819 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R /F21 658 0 R /F47 879 0 R /F53 962 0 R /F55 970 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1832 0 obj <<
-/Length 1880      
-/Filter /FlateDecode
->>
-stream
-xÚíY[sÛ¶~ׯÐ#5S!¸’à£b«­{;µ•¶Ó$´Ù<¡HE¤âª¿¾‹ER”�LÜNÏÌϘ °Ü;>`WdŒá�ŒEˆÂ˜Æã(æH`"ÆËõ�ï`í‡q4SO4mS½\Œ^|Ï¢qŒâ�†ãŪÅK",%/ÒwÁK¢	pÀÁåìõü|zöãüì?¿_]Î'S…”³7oæ—ç¿M¦T` bŒƒ×³Ë·³WvîÍ$¦Áì‡ùÍäÃâ§Ñ|Ñ(ÖVž`¦µú4z÷
�S°á§F,–bü
-ŒxÉ \Ù™úÞM,ËB«x·Û&uVvÕ*m	êÒÎÝúîÕò£J!²‹àbeg‹²¶dÕF-3ý½J¿ƒŽƒ¬¶$©Z%»¼®œ¥öä\Ü2ƒqˆ	µõZÿª^¾Ðºƒ4 OY¨ƒ�‚b!¨!V–YÇ'”¡˜`îx!GAÆͧ+¿D’DÀX Œ
åõ|ñöúÒ&ë/Bã`öê­M×^Àñˆ™ýÐh:5þ9¡’¤(¢�§V¥í„È@Õ»mQYiIaŸêã3UuRïܪ	<‰}dîUm
ŸrëÈ”åkßRU«e­R/À
°c	i°}È*5ì¯nÇ=7ó¹ýxöêæjÀÆ!§¼ÇKøG¾³Ÿ¶<õgY¨Ö²áÇÛ8D '#>Ž//.Ï-“Ø©‘®³"«jÈßrk§®ÕÊ9¡X:?¼NŠ]’¨KB‰h†�¦	ƒË®#fo?^]?í�‹¢VÛB¹ˆÞì«Z­]¬ÎÊ¢*·u¶[ÄrÄxHŽ
ÁˆðØ(‹ñ‘ûÌÞ
-Nò,Íê½}3L³âÎ%š‹ì‹Ï
-öóuYæCÇÞÕv‡ßì‹rSeUB
-8‡ö6{ÆÐÞP
xo2
!6ï¦é?úo3úÔŒ>7£¥5\t1+ÖgŸOöežTÕ
-=×gP[¨Ë&oÀ�´ƒ
-ÔZµ'(Ý÷Ný�Zz·Ã-'欇—®ñe[c¾6f8×۹ľ¶šdvÞ«:£(˜¥PFge‘äù~BÑf1k“Í&ÏtzVõ6[Ö;³d\erõYå•�¾ÝÛ§kÁi~TGôGô‚ñ„þJ{Ç÷Ú–•»z£½Êìª,ÏíH÷õ²;µ£¤rÏÂ=—µî»˜±õ²5®!vgú¯o÷)A

)Ä`À0ŠcvèãL¦Á¯
-cØ¡Qø”—â’7ÂQó·ééœh„aª2ˆ»�°+s^7ôÝ5^cAß<zÕo�î¬{"-tšöåA¤p=.ÏÓËk{)‚ë~$»òæEr›7]ÕÛÝÝ@,:e3\!àH|ÜäÍi‹�1øÓ)ƒÖØÛ6dnKØÏ»Ìw,ÍýÇŒ¦ýöô²Y*‡UèÔÏ:L_wØ�’¸I±oþÉçðãÜ}Í¥jÐ`
-‡9|z¥´ÅËã`bDYHtÿÑ®vendstream
-endobj
-1831 0 obj <<
-/Type /Page
-/Contents 1832 0 R
-/Resources 1830 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1797 0 R
->> endobj
-1833 0 obj <<
-/D [1831 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-1834 0 obj <<
-/D [1831 0 R /XYZ 56.6929 687.0104 null]
->> endobj
-1835 0 obj <<
-/D [1831 0 R /XYZ 56.6929 626.5588 null]
->> endobj
-1836 0 obj <<
-/D [1831 0 R /XYZ 56.6929 566.1072 null]
->> endobj
-630 0 obj <<
-/D [1831 0 R /XYZ 56.6929 528.949 null]
->> endobj
-1837 0 obj <<
-/D [1831 0 R /XYZ 56.6929 496.7215 null]
->> endobj
-1838 0 obj <<
-/D [1831 0 R /XYZ 56.6929 461.9427 null]
->> endobj
-1839 0 obj <<
-/D [1831 0 R /XYZ 56.6929 398.5692 null]
->> endobj
-1840 0 obj <<
-/D [1831 0 R /XYZ 56.6929 263.2909 null]
->> endobj
-1841 0 obj <<
-/D [1831 0 R /XYZ 56.6929 125.0477 null]
->> endobj
-1830 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R /F47 879 0 R /F53 962 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1844 0 obj <<
-/Length 2946      
-/Filter /FlateDecode
->>
-stream
-xÚÝZY“·~ß_ÁGn•ˆà>ײìȉÖr´‰U±ý0KÎ.Ç&9kÎP²òëÓ8çr#U*m•ˆÁô
-ûÔŒŒ±²p¨pPˆ),"|
8 lpÖ¯kÿ.ÛU¥o%;€v°h=îNa”l³ñÌV�hhÐYâî3ºlØØgµÅ€[ViXH=ê¢ÊÝ&ŠèÀú~¦m‹Ýæ¾R\‘gá›ÌâÛküC;Äš‘6À
ÊrŸGÔ¤¤­‘øI~?¾¢N¯§&äѶHìÆÜ#ÉÔ±“?D¾#i³–èÛ
qÔ×EÎs¬žqD5çç¢¢9y~øBeŠ~7E•¹’2¶Ú…ÊXƒè½?Õ¾3Ƙ®ì5?~,ªð�®„ë)²j,®#ÚC†n†qݼÛ¡Ÿ€]î惡CjSr0	–|±¦6ûç—ê�’Kc@Èé¸&]¥Tó÷ÁÿDÅaŒÏ¤P-¢é*¹êa4�’šÅÀÚf1`hý
-ÒOÈRù,[‰hÈW7•HH£:Œ�g²�™éT¶]Z®´É£šbÞ:�IA®ÃqǬëü�z³f<“j*AÃi æ…¬Ú³�S“(DHÑ4N0ƒ=‚œ©æµ©f�©T¾«{ĸbg°B`€³¬%ªÞºhQœ�è2—àÂ4´f	.¶ÓÂÅö…—.
y:Õ¾3Ö¢l«ê
RàZ™x´òÄÓ‚
-µ¹Ì\
Z\p~®ÄË>Ït.ÒÈó
-ѨôÌÑi›jš‘ÊAóðYÁÑ,_):ò5uk²MÆœç½&Kç|í³+‘16R"c49_Kpª!ÉùºjIóP5qçØŒç;(¶ô�/â�²è|;_Ž_`�ÚÕ2úµ—t+d¸øÁÅ—
-ŠÌ3<»0ÿÿQÑ
-I†ÏÜiSM[f¢r–YžOîA£VJëäQpñóÌ%ªî:öÉmÙS«.{?^+¾<õ Ë‹I|¨I»50ӳǯbd
½‰¹¿�nþ„œø.%®ñwêÎêòøiZö1ÿ¹MLë_HÄ$;ã™ÛT3ú�TNÿÕÙK-Uýi—O^j™å¬¹Ô2dmôRK‡·Æ9k2}ƒ;®ÏUÛïleÀù_èXѦ©
-rnW€—÷^5ŽWyʹt“øKO—Áñ,#N;Ó¨ó°™»2í�ä˜ï2[¯ž˜È—b²{É \«èî
-endobj
-1843 0 obj <<
-/Type /Page
-/Contents 1844 0 R
-/Resources 1842 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1846 0 R
->> endobj
-1845 0 obj <<
-/D [1843 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-1842 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F55 970 0 R /F39 863 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1849 0 obj <<
-/Length 2037      
-/Filter /FlateDecode
->>
-stream
-xÚ¥YKsÛ8¾ûW¨j÷ UYž$pt,eÖS‰âµä�­Jr )Jb…
öx~ý6�"%HJÕ–l‚­îF÷×Àd„á�Œ„‡<EÕÈW	LÄ(Loðhß~»!–gÚ2Mû\W7>1¤�ò¨7Zmz²$ÂR’Ñjýmüùhðxq÷e>›L)çÌß=>γ‡ÿ»ÀÀ,�¿Ü-žï>›µÇ‰¢ã»ßæËÉ�Õï7óUgNßd‚™¶åÏ›o?ðh
–ÿ~ƒSRŒÞà#¢¥7\0$8cíJr³¼ùw'°÷µù©Ë\H$(÷À1ß;ã(‚|B€Éçzð%.?Y&í¦i¥·ùá“=F¥?û Zs¬ã"
-«¼x?ö!
-yÄ;ÈsYÖ1�šÆz	…
-ã
$SÞømAîæEg“~†»(ü©I¿	G³Á�B’§q¦#Üü4NÖ¡éëís9^\æ2K‡Î
-‚$ÍËÊVÈ.
Ùe‹�™‡:¤pjÓ#¡¬“ʼçóÌcÄIÝji~˜›g�­£¢¬‚l}$°o¦Y
ô†»8ÛZÁÉ6/âj—š×ïXà§O÷æf*DƒËñc^–1
-BÙµl>A\ÀÔw1›ú\糩ãÒu’ë¬?i¹˜!"%¿¬¹ãr¨&ŒD0óùCÝ«®¹äiЖ»Æ˜†Ê7G=èP'_" f¾�œº0ÏhÜ0i“+žëq]ð\Ëe0Ñví“R#Lïü²ê–É¡zè9øêyþPwç¹_ò–±u`ígÇ	Ž ~Ai`>ÂŒšYèi¾z~Z˜ÿgóÒøîó³9ÿyÒJ /ë÷’3ÝCr8Ú°6=LªVu‘µÉkQýWv,©‚ª.‡{$Ãa8*̈[X¶·¨+Q\QSKÛM…[‘ºJ¿Åå÷´æܳœÏÍ�ï>/¿:öèrŠ® R׎ÛÞn<¥G¢ÞçF÷C2´"•uš©�Ú
˜	‡z়«@.� GÚšóña13ò”ÝÕÚL\Vp€Éí8øm¬O³ÐºõK�ÕЋNÕŠ¨×ÀÜ~…î	µ˜¨¡cïžWÿúútÉ£†ï!ƒ^˜E!Ëw˜’Sûû<+ó¢Šëô bÈ=jåp
-KˆöJ`5Ûp´�J¿ÀX5,›ßƒàAY/Ä6Ù(õ
5´Ò]ãʨx�
-—‹ðæÞ³|_Æåq­aPÁ¤ÇFDR$ˆûÚÚ¿¢BÇûb
ì‹0w*ÊQ;®Þ¾=ðà·)ÿÑR^G…vV
-Š·ÇIûóMl]ÇŽ¸/ɱŽÌ!oÊÀ«„é[‘þTó�p_—.É
-Ié«cÉû«NÙCj¸ä1¤ƒQ'¯ì¨Ê!yè£ñ:Á |âˆúª¹p¼,ÜŽ¥ÞÉî_;꯫ֆ
TÞs�žE¸Û&ÅÈ#À?HÒÙ|yÿôð¸zøºøÅ^éš
6¼»Ñç:¨^z
-hhÝIf‹¥Sõ‚-1>‡V
-endobj
-1848 0 obj <<
-/Type /Page
-/Contents 1849 0 R
-/Resources 1847 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1846 0 R
->> endobj
-1850 0 obj <<
-/D [1848 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-1851 0 obj <<
-/D [1848 0 R /XYZ 56.6929 496.4666 null]
->> endobj
-1852 0 obj <<
-/D [1848 0 R /XYZ 56.6929 433.6488 null]
->> endobj
-1853 0 obj <<
-/D [1848 0 R /XYZ 56.6929 370.8311 null]
->> endobj
-634 0 obj <<
-/D [1848 0 R /XYZ 56.6929 332.0288 null]
->> endobj
-1854 0 obj <<
-/D [1848 0 R /XYZ 56.6929 299.0792 null]
->> endobj
-1855 0 obj <<
-/D [1848 0 R /XYZ 56.6929 263.5784 null]
->> endobj
-1856 0 obj <<
-/D [1848 0 R /XYZ 56.6929 197.8388 null]
->> endobj
-1857 0 obj <<
-/D [1848 0 R /XYZ 56.6929 126.0307 null]
->> endobj
-1847 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F55 970 0 R /F23 682 0 R /F39 863 0 R /F47 879 0 R /F53 962 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1860 0 obj <<
-/Length 2811      
-/Filter /FlateDecode
->>
-stream
-xÚÝZÝoÛF÷_!àJáf¿—D8±/pÑ8¾ÆA´} ©•ÄV"‘t’þõ7ûE‘%ù�ôå Z.ggggg~óA“†d–„YÊg*åH`"fùæÏ–ðîÍñ4q ŠûT¯.^þ›©YŠRIåìaÑã• œ$dö0ÿ5ºº¿¿¹»¾ýå2¦G¯Ðe,0ŽÞ^Ý}¸úÑÍÝ_¦4ºzsó9gˆ”!“8º»z{s}ùûÃ7�8}‘	fF–�¿þŽgs�ü‡ŒXšˆÙ'xÀˆ¤)�m.¸`HpÆÂÌúâýÅ:†½·vé”
-K�H¨šÐ
%3BP*(A¤H2ʬÞÝ?ܾ»{pŒ°
-d¢—ôŒô©Ž[AGµ|Ê
-NnÙYÁá–SV0زoòï·þd 5KÙ9+èQ�°‚@eÏ�àBôLj2À2'x^•‹b/
-PñH<"	”³ÓòuTô%%ÂX¨¡„Æhœˆ}ZŠ‘T‰šqÄWæ&€ÃþÀjX*œu�>Ìâß0¦Ëv—5EUº·ff­Ý¸(ëFgsGmìk°|®Y»n^LÙ‘ˆ‹4HùR7ùË2Ûè¹½çYÌ$EI!&v¡‚t‡™8e(5�Íñ‚P˜H=˜(Y]Æœ‰H—ulÌ<7«¬1#¹Ùu•Í‹r^zªƒÓ›Épz³š¢luíúÝ>U»?A¶hônĵֻ§0¹�Ûã†Ä]`4§]eåRå²4*šÚ
w+«y˜î
-Ñ
tsrË@4±å ÍQˆ&‡[þÔ–#Í8tú½\x/Ý·¥wêß°À¯�
åVn¶¬|*äì´øK9®W¸V&å9½ö¨Nè5PY½.'ÒÇ$•g¶D[ŽÒÇD©Ñ–ßH¯Yx‚<ØóÚ[ìº
-^(ö®>J"!£‘]d¨›¹Þí¦œN dOvô’¸JMÕ™KêS¿¤ŽÊ^Òf
-9à H°Xg7I RKÂåiÁ:ª	ɸH¡HNE:
2µ;)9‹lÄä<Ú€MÛsm�-µÎ÷Èh¨ ®²lY›v
-=1‘}ëÄŸË>¡R†ì›³¾|*l̤nêÛAe¾`žPUn\¯ÇL¯ü l7�6äswCkäw3[�)ºlÜ„ö0È÷a×T{ÎA‰žEà\‘£½]¸™Â3-ünméûNœû<
Ô08`ÿ}`ëNÑëX™S¼ð©ˆOo â…¾V¸wǦ'²yW„Ô%‚ûÓÎ�:"³á¢ÅIOìSwÅŽÊúâö¬/n«]sèŠ%\œ–+MÈ5Ì9 TR9ìÇ¢nB“Ñ$vð±Õ»BסéKf/ß8ò
ÈÒ½/î©Î‡¾ÛÅ(8Ö¸�²-¥a—ÓnfG‚¿S	åçî´GuâN•½Óz¢ŒR	¨âä–�hbËQ¥$‘Ã-¾T<Ú¡‹RC3ö©¡Uc“5p­E^ŸÈ×Mi.9ݧëU;uq,�ÄF†
->Ø‚þ\4
-'–� €• :NŸæYb¿€	ô€Êt(Àh�òrë0ðòC·‚�s† ]Ld-)}µ÷>K¨þ%…Ä0F‚aa~×S��œø–°`4÷w—±$�ÂÇ’F7ª
¦ŒŠª$	’K»ùìãOSæ¨zc{Ú½ìÄËÛ
�]Wp¦YÿX�sÜgmÏ%iÿº¡<KœØ,ŸS¸[q¬œ+©®“gÆnNF›¬ðŸ"”GdxWzk÷íAùìTE¯nï®ÝšÔMÌõ%ÃÑÓ%¦É
-ñÃoãM¼
Á·ÈA´‚,S]á×ͧ¢‡…(•ì{¤æÁֹ𛹟EÛ´;íÆ;½6]ÃõÀ`¹	ÀL¥o_ge,�ùÔ4t÷ŸH¿Îb_(ÅÔÈHø	0r‰Ï¡XGeQ¬™ˆL)‚h¡¦ÚÁ«hJ%c³þ¶‡á)PMH7$r~oâ½vq½²!‚Êé6£IÉ{N÷tÈ»ªÓwé
[—$U¹®k×æ0[Ù؃¼ÚlœáÂÃÚe.` ®’^¶Ȭl–ÂHôØz9õbß&„ç��$Ü”8�Ì»‹wÍs_¬Ðµ>
-¼DrD¡¾	ð¦ñ„§ÿƒK„Ç€Wa¤0 ÐÜ%èêãÝìBí§h¨¿®,àþdÿg!ø¶ÓèÍQ †Œ’¦„{ Æ�žpîÀ·?>Äì÷YŸ
-endobj
-1859 0 obj <<
-/Type /Page
-/Contents 1860 0 R
-/Resources 1858 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1846 0 R
->> endobj
-1861 0 obj <<
-/D [1859 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-1862 0 obj <<
-/D [1859 0 R /XYZ 85.0394 751.3856 null]
->> endobj
-1858 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R /F55 970 0 R /F53 962 0 R /F62 995 0 R >>
-/XObject << /Im2 984 0 R /Im3 1108 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1865 0 obj <<
-/Length 2226      
-/Filter /FlateDecode
->>
-stream
-xÚµY_oÛ8ϧÐÛÉ@Íð¿DìSzMr^´n/q±ìîƒbщP[òZR’~û›!)G²e÷½C
-4Ël›=ë¢ùîç»|ÊÊ¢Þà4ÁHsËù®ÚúQ¶^ûÁ®ªšàµÜAªÎkYðÚÉ”©8¸.JÓAã×¥Ý6~î5Ô&~Ó
WCxÓ·¢
-ìRÔ~óÆfeàêS‡Ùq
A!½ÒA"ú"'å,�T[ÌhžgU‚
-ît<Á$	
:8Ýziå
÷
¯“›øåÉ–#^¸"™‘?öZ‘òη‹ÀÒh18xŠyÑ­8°É	',õ¨®­3ÌèÊœe¿>ÂÀ
-DS…žñâ§ÇA‹ÎyaÓƒõó�m²¢tn‹†{^_íàó\Ä@õ
S‡ñGøy‹ð𵟿${m vš¾•<?‡Y€¦$M@P	@¤â|}Ö
raÎ×G{*Vχ–Ñ Iõ™‰ìˆFDöC'AP£"ï,B¾—1qðlwµ^œ”íæÁ{õ‰öµhŽ®±;ºâŒ@Rc?°O�êŒ}:*gŸ×±ú‘’
-Èà[Ëlùd§+ðñCí‡$¯àÖΪ·§ÑO R„0z¨àÇ*ʳ&ó£•+ݪÍHY	7¢©GU?�§AœÖÝ)‹wpgn·V«ƒw¹]eí:Üòsa_°ï8YåIˆ©ù?©ò’ªŒÔü
ív˜“%ž„ûÖ,U?(ñ
-túõS>ú€œ�ÛCõÐË•=§ï’¥À#)ãûšûÙíüêãýH.¡X‡
µ‹#œ¡ý8T–.OµÐ§Z¿°ïK¡*á‚AUòXfXoàËú©j×x<8.>„�èT~äò<—UÙx
k¿Ç''xƒ54Ô€9¿]û8 @Ó„§]Á·+óåXë
53¤Ç@ô¦Ú±FèÃÐgùIô`i°vz½úT§ÑkO.ä_¿}ÜH5Œ�Û�ˆ€å„&зäÞTÎðË
-Ò­†0(òÔÌÌ«—ò¼yàŽ$ �Âï+24	)ÙöÍ]ïQ¸3wmËÜÐqåÕ÷ðÄ„’ë-èPz5®…�¨-sû¥¼´Þɳ„¿„RPùo_ÿ<¿™Ý~½»Bƒ/fŸç?N‹®E\%[3ò=aÀJHB™î:mÈ
-¨écëóv"Æ•µëG¤‡"XkªÊü·´Wÿ¶	‹¹­—»â¡ÛSv«Ðˬý͉@°¦÷H>ÌÙ>—í›"^¸ÄÎ	Whб—aíùs‘w_Њž£¸ãËÁ÷cE¤f]#ä�©�\团,êÌQ…[½³« {ÙEð§¬l³õˆq™N±JÔý>ëðö!Â
8¶1Þ|åz3û8ò:Ä°�«•šŸ�ó‘‹/(JŽã¼#B‘—¶Y^:?!à«ãð†ÆNéä¬ô=Ñ‘øƒð†"]¤ñ‹ÑêøÈ#qÑ{äÉ4Vgà'çÍÓ#:mžŽÈ™ç9Û]îÚ2˜h[äGÒ+yV�=Ñ‘®¥CˆÑWaÜD!ð“Ô´ÈÏ[¨ÃAp{1Ú/Ó½oþôÿ8Þþ‡#!Y¥é	_€$M`³î”ƒ2Æ�/
-.
¾r¬û¿
IË!endstream
-endobj
-1864 0 obj <<
-/Type /Page
-/Contents 1865 0 R
-/Resources 1863 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1846 0 R
->> endobj
-1866 0 obj <<
-/D [1864 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-1867 0 obj <<
-/D [1864 0 R /XYZ 56.6929 361.2723 null]
->> endobj
-1868 0 obj <<
-/D [1864 0 R /XYZ 56.6929 210.791 null]
->> endobj
-1869 0 obj <<
-/D [1864 0 R /XYZ 56.6929 130.947 null]
->> endobj
-1863 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F55 970 0 R /F23 682 0 R /F53 962 0 R /F62 995 0 R /F63 998 0 R /F39 863 0 R /F47 879 0 R /F48 885 0 R >>
-/XObject << /Im2 984 0 R /Im3 1108 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1872 0 obj <<
-/Length 2455      
-/Filter /FlateDecode
->>
-stream
-xÚ­YYoÛH~÷¯ÐÛÊÀ°Ó÷ñè8Nƃ±ã��ÅIŠ²S¤F¤ìõþú­¾(’¢ä
-Á	1¶î3]tX•Q}v,_ý¨�230ž�GÁq%âZ²aêIËÇz&\ƒhÉœ·Ùçï7—ÉÍaW4dþ²*²•ŸÙ5yàIý£YyÚµÝ{žù÷Ö¿ÛxhŸyEä•cå.DZ‚Ç"Fê
-NLr3XE�zAª‰õ^÷ן’¦}-�(=6�£-m`RÅõ>lدö_»¼iƒŒ8ÓñÐKÕ�Âø?šþ÷Íð“[ýa‡e9XhRõÆÃϺ{Wnv
![¥`“Ps®wMàüÃà<Æ–Ÿ¯!&øÇTî‡Ò™1j¬¢?÷G‰I_¤ï6þ
-zº+ésÅû‡Ã¶¤ã²ëv͈èÇIEš`G›‘¾†V—›Ó*v\:ë(ÛQR:Tòk“OÞC
*ʼn–i ü†iû�Ôe=³+uß[xf¹Ÿ°‚|x	œ>–
gø„ô‚g�U�FždÍ
-£D¹rá
Œö¹Žc´ãrͦ0Š¡$GÚÚ
@%A˜rvZ¿ŽkBÁá•�DŒNÔ60¤óÈ•
-xï¡“˜€$b&b¤%ÆiÇ5Yý‹=wbØþóE¾L
d¿Mõ¼NF‘¨å»¼ÍÞÙ`î.ɦÜhpópøm§ÁÐã:
†ÈåÀðôfÀê_F�À9´ê‚ŸV®ãšÐnpºÐ*(L†êE‚QœN^–„B»†¹2=PËgÊB¦
J—)Û½�p.Ocú‰£'B#M�>8úPÈŒtS
-"²Þ_VBiL ^ëÕ¬:K	è0�’ý•|D„ê)‰Ã"ù„`u£IÔù¥°õ%Ê×gð„|»ð#áÙol,Eö{B¢b5ØûÂ�ìkN;.–ûɉd¤CäW}ÝCע΃"UÝF£Ä¥5^ùŠ¦=êpÚØxÈNû[�鸻E&çmÍ›¡wM7ð5F�–ã¤^Ó�bCïa¢Ô@³þíà°ƒPóÎ×üm†‰-œ‰å Œüí„fz7±}ÓÁ
-®K¦Qu3¸ÅéC¯(:rÙÇ #ãì
B; ™Ú;û¸Á½þÇ Õk"m�BÇ~¼dÙ{Õ	‡Á]ñ·ØÜÿnËm]¬�”;sÄ E¥ì~	acÕ»Ÿ@uÿ‚D|Õendstream
-endobj
-1871 0 obj <<
-/Type /Page
-/Contents 1872 0 R
-/Resources 1870 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1846 0 R
->> endobj
-1873 0 obj <<
-/D [1871 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-1874 0 obj <<
-/D [1871 0 R /XYZ 85.0394 752.1052 null]
->> endobj
-1875 0 obj <<
-/D [1871 0 R /XYZ 85.0394 676.9839 null]
->> endobj
-638 0 obj <<
-/D [1871 0 R /XYZ 85.0394 637.9396 null]
->> endobj
-1876 0 obj <<
-/D [1871 0 R /XYZ 85.0394 604.8838 null]
->> endobj
-1877 0 obj <<
-/D [1871 0 R /XYZ 85.0394 569.2766 null]
->> endobj
-1878 0 obj <<
-/D [1871 0 R /XYZ 85.0394 503.1887 null]
->> endobj
-1879 0 obj <<
-/D [1871 0 R /XYZ 85.0394 431.0324 null]
->> endobj
-1880 0 obj <<
-/D [1871 0 R /XYZ 85.0394 247.0209 null]
->> endobj
-1870 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F47 879 0 R /F23 682 0 R /F39 863 0 R /F53 962 0 R /F55 970 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1883 0 obj <<
-/Length 2194      
-/Filter /FlateDecode
->>
-stream
-xÚ­ÛrÛ6öÝ_¡·¥ÚÆ�Dß\Ç麓8n¤tv¦é-R§é%){õ÷{p£H
-²§ÓLf"ðàààÜ/0™aøGfB"©¨šÅŠ#�‰˜­wxö{¿\‡³ðH‹!ÖÏ«‹Ë,ž)¤$•³Õf@+A8IÈl•ýýŒšÿ¹úõòƒ`\J�¤‰úéËÝûktýùîƒÅQ¥	²‚:Ô«ûû›»÷·ÿ™/¨À@}¾GŸ®î¾^}´°û¹¢ÑÕ/7KMìâfÕË1”•`¦…øïÅâY"ÿz�S‰˜½ÀFD):Û]pÁ�àŒyHy±¼ø­'8Ø5GCºã"A‚r	Zdˆb‡5LPL Åœ ªDÒk˜’�†=–ÖÈâÉéW0	A‰�[¥=ÕM7Õ†¢ˆ«DΆ7žðå‘|
­©bÄc5ák™W™µÈºÞíÒ*kíWWÛßÕõ½]xî&.B¨B,fr"Ãäj*ÇÄáUÛå©»µÞ8¹½{oWê_Ž…,ߤû²óÜU]3'IT—°M«*/�̽sÇÁ‚'>åÿ!Œ9}ú¬W¬ë±ŒuŸ^)cKÂ^¿Ò#®j/¦(æTŽ¯¼©Ò‡2·2?çÍCݺ�²~|,ªÇ³J�	†�{U	C¬óJ豌ag<æÎôå‡)[‰D"Æñˆ­·ž"•$I8Üžà©#Æ…„Pr,B‘MÙ#˜ AxüºÚz¬€ÞFÑ‚!”$ã[¿ÓIu[·pzšÄšà K,Îë’ÄŒò;êÒèr$dÚ)sª
¨MJú’²±!½›ˆÁþ
cú¸oÒ®¨+Ô�2GÁןWc1J ˜|7Åx‚o(Ì…bE’¿­˜Ý¾í¬ØÞ%ªúÅiâá eT¥»<³ —¢Û•Ôg3'J[‘ %„M-œÑyBDiùX7plç>mQ›¯�UòÎ}w
¤».4‚GµÁÈòÆ‚7µ[L²´ˆvyÛ¦�îÆç´,2oQø¶5nد×yžA—À¨ˆn7ZÕ
S3%‘”ž75ª@µR&(�zþ©­{Š‹!ÉScC
F4!äxóYc/8�š@�æŒcÛ°*ƒF©}Ê×…ö÷<{çN“qPÚ—¬š*[‡J.C\2/EYZÚšl£�K”uý—^0áœD�]§vS+×,Öeº×)J¯µè_«¹Í›ç¼q|wi—ïòÊQ×µ}€‹G¸¹ñ*Mˆ[9¡&ÐMH6öYã]ŠG…öe<Ã|{r6¸Ú ¶üd]¹í7¬«*'©mëV7KÍie�6ÁÂu!£
}ÐkCoÖOÌž´{·žF0<–H3Š4’ŒîêNŸÅÊs„G@§‰vm"캴0ÂN»M­¼™Ý=†²CxÙë­Ýs˜®-à˜¨)ÛjĽÖJW¬A˜l,ŒõÚÓÖ,ØIV.óx7hu¼ݺ¯ÝÖûÒu…p£eoS÷ljµÃݦÏô˜Wy“º‹-nßZ6ö÷²œÃN!Ñ´-r	ÂëâFÀé˜F˜æ��
¸ÔÒ<•¹¡
-ÈÙiç%ù’oœ6«µ;ö)­ö 4«&঄Œ�ê•×ÌÁ;ª€#Lbú†�Xe?è"Uï�	­ÿ=îu(L<ÅŠ	‹ÂïlóòÉ®\AA=G}XAV:�ãÊ3´YÒ
-òñöÓíÊ›ú¿Õíç»e@pi*�`œ¿-ŽÏ©Y�·¿<äÞ™­8Q˲wëP„ø¨ß>CIÈ@:h¾½ÿ„Y%JO÷Þö]QÝaN‰¼÷CªUºZ9÷·‚¯|àÁõTÙ4
-¿ë}ã<¨+d’0ü¾¤Ð9€M¹õs‘">›ÁÎ(=Q5î4àÛæfX¤î…A
¥
-ÅXÈך<®õƒ”xÂøwhò,ÁÅ�¢}Qr¦{AEâäxñkM
„ˆ¼om“¥éõušý
8hƒgºÊ€£c56â2>æÄÜZÎdz‹ŸÖûaŸr¼k–¹³R3�y4<Š°åÍ�=zõqù9 t ¶ˆ¶ù†ðyw,™&S`=[�͵|ô$³V,˜ÏPƒÇí$Shš)
tÌ”SSB“M¸7f8!±R=Q>#�¡ÌëØ×Õ¿?y[S·U—7•O)ËCŽ3Ü54�_Šýîx¯ž¥·'HÞ¿î9ý$C,ðnóaiô"¸ð¸(”++Ç�®è§‘ª¥PˆÆ Zˆ0¿#Ф`üFi쪎NjþÝgû(XÅ‘ƒªú©…\6M$h6!öQ"xðÑò¨¢æ‰îÕç’!‰ÓáŸKz¬3
-?aïo–×_nïuñ:£ïP|…ôÃ$ƒ½¾Í¸!ˆëÏCÊÖ»¾ÝÔ:CŸ$�ƒöùï54Ðço¶Ñ©¯S`»E
臆é+ Þ¶…$Pâ·V.<àœ@Ç耩˜˜"¬ød
-îSÁ?þëÇñÏB<F,IÎ<1S(TpXz¦´Ä„ðÓ7d¬àýÿ&t}Ûendstream
-endobj
-1882 0 obj <<
-/Type /Page
-/Contents 1883 0 R
-/Resources 1881 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1846 0 R
->> endobj
-1884 0 obj <<
-/D [1882 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-1885 0 obj <<
-/D [1882 0 R /XYZ 56.6929 546.7712 null]
->> endobj
-1886 0 obj <<
-/D [1882 0 R /XYZ 56.6929 448.103 null]
->> endobj
-1887 0 obj <<
-/D [1882 0 R /XYZ 56.6929 386.1077 null]
->> endobj
-642 0 obj <<
-/D [1882 0 R /XYZ 56.6929 347.8768 null]
->> endobj
-1888 0 obj <<
-/D [1882 0 R /XYZ 56.6929 315.1782 null]
->> endobj
-1889 0 obj <<
-/D [1882 0 R /XYZ 56.6929 279.9283 null]
->> endobj
-1890 0 obj <<
-/D [1882 0 R /XYZ 56.6929 215.0111 null]
->> endobj
-1891 0 obj <<
-/D [1882 0 R /XYZ 56.6929 155.9807 null]
->> endobj
-1881 0 obj <<
-/Font << /F37 747 0 R /F53 962 0 R /F21 658 0 R /F55 970 0 R /F23 682 0 R /F39 863 0 R /F47 879 0 R /F48 885 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1894 0 obj <<
-/Length 2682      
-/Filter /FlateDecode
->>
-stream
-xÚ­YÝsÛ6÷_¡é=”ž‹P| ˜<9‰Ós¦ù¸‹;Ó™^h‰²x¡HU¤ìsnú¿ß.€(šŠÓ¹=\€‹Å~þ3?1³šq•§³,O™æBÏ›3>»…¹Ï„_3‹æÃU/¯Ï~x£²YÎr#Íìz5àe·VÌ®—¿&?^¾}õËù\jž¼dçsÍyòîâýÏ?íãy.“‹/?Á«Ì3‹rvþÛõÛÞh5`¯òœe©F©�ñ?Þ¿~Å^}xÿ—ž]^Gq‡G\¡¬¿ŸýúŸ-ádoÏ8S¹Õ³{xáL乜mÎR­˜N•
-”úìÓÙß#ÃÁ¬ûtJEZY¦­Ì&t$Õ”ŽtÎŒ‚)<ÊÏMõoÒE×?Ôåóó¹<ù‘ú–že³¤A»¢g]5%©Iåƒøl.,Ë…&Þ»f¹`‹¶YÑÒ#a´a2S^ŸUlS›lö‹5Žò¤«6ۺܹ_ÍÄn¹fÊFM±)—'wóeÚú¥àŠçÉõº¤Íþɹ¬KÚkß•Qûõî\ؤô]_ôå¦lúî9}2¹uí¶¯Ú¦­zF“
-3›K!Xª¹ÖÒÉÑ•»;wF§}ÿ!½Aã=>—£uÎMÇÇ#=V”€Ó+ä}¬¥4e9—ÁÉ)ž% Ù¾¨ðœø†*»+ýL] Ö@«©§D0)ãÚhÏ{Y®Š}ÝϽ‹b
Æ›ôËiÚ­ò¬ÚºnïË%½Ý<г_ûeè¤{%4KS>Ò}zWR$ÅrIfî:" ‹»	z8>nˆÄ‰›¥èBZ*8lå?[·]O£ûª®itã¿Ù—~n]6žo‹O~ÄŸ¼
Ç�ëmu>(<©ïNìÛ½·P ZI‘b’ƒccHN¨[r–ÆH³¥ú„!eÆl&íÈŽèž�¹šœq©Í؈ÒúóåC#ÕQæÞˆ@ÊɽU,YÅR8 ý~]aÊò¬– ‘
-tÌ·˜:O.˜ÈLrú R0ÉÓ|sr®TBli™-Sá¡øœc’+ÜX´÷ãÍ!	BÊW‡½«åÄî
-J€Îõ W*“'[gÿö®¯\º“±mèI„m�½iÑn6.« ó7d(()‰§åÓJ‘±Œëì)õžª±��'	kÁÎû°MÕ© ×MÑ/Ö^™`#f�°Ç.[5·S	꼌9•FT:me48z*hÉÉgEðcz!ç²<D²õ‘lc$[*�H)ö kð·°&
-é–„€†tñ½ßÇÁ¿‘êa%e ¯�1c³q©ØBʦ›e'BÓ,ëé(4·í®ŸÐL–bE|›Üø«�¬ñ	V‡kÇ×�zðÀ–†P$šrè-}âœßéSí�»i{Ïʇ9Œ¼Ê\‚uÊÊ°”Ûãðr1ÅOÄ”„B“ª� Nœ^Bà
:ªˆÄ3”—^[0VÄãcH‡Øâ‡Ø’2‰´’*�"¦Ýoõ`(;¨„û°Oåe,hÆ×tü`Å
-ƒ«�w)Í@$’ñËA8tÚ…_<€6eçÃ)ÈvO~Õ"ðFýp.„H&ñåŪ?€ò)㤂e˜¼žÊË–)eÓCU¹o�Ëg
{Ô ò[ÓkÕ,êý²ôÀ»ð}C¿Cw¤ ìÔÆ#òE¸FiÇAx¿ÃDªݑâ,tgRëc¯((ÊJQGéð¡¡ÃÍÀ4|²&4'‡M¾nÛ®«njÿ‘w�çSA€U"��dº.CíÎUÄjϦ
-6Ê—TY|.iD�õª”ð¢&êÝm#Vðk§”i
-Ý�ªËðúÁWüdX]pÉÈG4ÿuäDeçÐK¥ò뽆dœçöñEÊÑ5oÝ
Žï«~�0Ÿ;7A
-5†«W �@Å!L(9H¥ä�#42ˆS(�ižYKy�‰á²;úû6´‰,3éȡõÉcE ز*¸eQ߶;8Íf*È!9ïÑ­/ÖåS‘R2)›Åî!à\˜80u¯«àÌG—"Èdcÿtêò
-ÀÌË«÷¯iqNß‘ÝîŠÍ„«ú‹;pÕã+šQnÄ‹bºÓáA¡nÒ5¯¥d
-¶õÉ4%-àó g{"î …¶û>£WB›Ù
AÇ\n™ä±+Ülœ¯•S±/™´<€è�zü>EÝy	?7í}ãÅë¦öä–¥*
¬6ÕW6UL¨¸é3¯b-×øÄ0lIuÆ#†Øò!…àP>T]Fwݸ<º½
-ãÐS¶åðR¬§½»uµ%‘‹âlî%ß÷áÎÙ2žK9ºÉòa[ÜU]Ä
i`S4á’ÿ

-õå/ï>þtéc¹
<\„9j� Ð8^O„¿nºÑâ°ØA}Qdw{Œ­ZžQÊûNT,è$öG®³Ëó£æ†óä?N3�÷twí‘¢�°¾nE�mÚ‹)l<¼x†ìÀÃ�áý…ou§vú#2ƒŠl¡‰:úÆ·ýŠÔ"â€
ÿ¿­!Q÷Ã÷§ö–©ÿ(î<ª3‡îÀó›:!õ(8ÒJ«4üãÏœÄD2Cm<i÷
IÑäëM±˜o–zò0X)J’”'ß™7ïVÿJÕ‡îKZ?ÜÈôÃU)«/¿äõJÔõÛ­¿|7}18ÃÔ_·àÉøëÄ­<žâþ[÷ð·vš1e­œþÇ-F“B¡äBè±èñàDzÿ1'¹endstream
-endobj
-1893 0 obj <<
-/Type /Page
-/Contents 1894 0 R
-/Resources 1892 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1897 0 R
->> endobj
-1895 0 obj <<
-/D [1893 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-1896 0 obj <<
-/D [1893 0 R /XYZ 85.0394 368.0049 null]
->> endobj
-1892 0 obj <<
-/Font << /F37 747 0 R /F53 962 0 R /F23 682 0 R /F39 863 0 R /F21 658 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1900 0 obj <<
-/Length 1897      
-/Filter /FlateDecode
->>
-stream
-xÚ¥X_sÛ6÷§ðåeò]ÅŠ¤(ŠÛíÁMÒ6[㶉»Û­íƒ"1±®²äYòÜìÏwHP²l+Kz;?˜A
-'"ä¼¥£ëÑûN`oÕntXÃxĆ|¡z¾PŒ‡cJI‰¾ø¢ï'~ö5ºnºÉ_Æ°1¥D	
rÛ�Ù�wÕ:oKä\,“Ô_fâ»#hyQx­ÓµnÀg!pž\ñ×ñ»èÅÏ[õÛö×íŒÿòÛÏ›÷?þx‚{ýÁãþ±‹Ï_2Þ³Äç‚Ä‘0
-£{Ú
½3
-”º=Æ^;žã<´g^8ÔlãöºcïõåôÔ¿<8KŠ	õº´«#òÆmÝ)‹ó´Hð¢Ì¸*›$/-§Ür“ÔÚ�Bœè2­²¼¼ÃYuû�Búï
@	¢Šª¶	3{‘ðŸU›{0þ}S�“H+ŒAøóHb>ßdkL \?Y!¨ç‹8³(æâ8‰eLâ�»½y�;7¨·ñUœ(B"Cþ8>H)ð
¤ƒ¿K�6î€
-‰;4 ž�N¾ŸoÀºªÖ
..x«)^
-oó
hhߘሑ ÜÔŽ=¯ÎMíªÐùwºÔ�"î*ü[CDUKާ͛cÑ<¬ç#,¿½ëÚ÷UµŒpÌß#G÷ñ�ŠÐœîT�Ÿ"÷ |¦�©P²2ùÖhÜ°W… Q¸‡üÄH-$`ª Ž‘0-gçâLsœ½;7B².‹{$´ÎÎ�±�F†ŒY0(hþ·�ä
Šb«¾x
-�„Tm†8Œ:Œô€„¬Kƒ>ráB¶<sÖUQùB
ôvŒ„Öm·Õz@xè„ÚT3`�=tm#,ŠZVôVìXu`´ZçÆ%.i8‹	åÐ}[Òì
-Á)oÕã˜}F}“�–ÒëTÌ4/Õ�ÌñS’L((}¢Õ�&TÊ»Öú@�ºçanË^»<„C”HÊÇ
ÄA$ƒÉ~ÒkÆz�–M󨻘�áHáß4[æe^7�Ø&éJßj¼÷2uÛ.“r“;pÂnFCGU`ó`jp«Öõ¹ËŒé›ë·�¿‰ó,ˆÍsà™«Î½x¸Ö&©}J ‘¢ÿ"¦ÒÔ2Ö‚âÿóı	4Š
æF]8xÅç!¼ß �ÞŽé‡ùë·W�»å°k]¶àz}_ÃU»Šq
-
�S¾YîÎ
¡	ŠºÛ�„4ê>À›?‚£Î°r	}ŸDÖ™AŸAÅà
*åqwbµùožÝ­á¶]Á牉ͪ*ž€®×÷eµªóúð˃Ñ#Ž¸éq¹dCß	 (+&L­þˆ`^Á�F;
Ç_ºÏÈslµ)ýäs;ºA‹Ä^„€ª"è RP=F��šv½ºNf: ³ýЉ¼Í‹o¹èF_„C-E×ñ€ð²‹†§_=ª¯mö�å1@ðCyë
yð&åD°ðàã	¶òøq;>_?ªn’ek]×O÷@ó¨Èt±®ª&ˇú=xQÑ…K'tó¨PxÙ
Éc!
-endobj
-1899 0 obj <<
-/Type /Page
-/Contents 1900 0 R
-/Resources 1898 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1897 0 R
->> endobj
-1901 0 obj <<
-/D [1899 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-1902 0 obj <<
-/D [1899 0 R /XYZ 56.6929 449.4646 null]
->> endobj
-1903 0 obj <<
-/D [1899 0 R /XYZ 56.6929 355.3738 null]
->> endobj
-1904 0 obj <<
-/D [1899 0 R /XYZ 56.6929 285.1933 null]
->> endobj
-646 0 obj <<
-/D [1899 0 R /XYZ 56.6929 241.275 null]
->> endobj
-1905 0 obj <<
-/D [1899 0 R /XYZ 56.6929 202.5209 null]
->> endobj
-1906 0 obj <<
-/D [1899 0 R /XYZ 56.6929 168.3311 null]
->> endobj
-1907 0 obj <<
-/D [1899 0 R /XYZ 56.6929 95.2288 null]
->> endobj
-1898 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R /F21 658 0 R /F48 885 0 R /F47 879 0 R /F53 962 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1910 0 obj <<
-/Length 3181      
-/Filter /FlateDecode
->>
-stream
-xÚ¥ZK�ã6¾÷¯ðÑ
Ä>%{šd&A›™ÙLX ›ƒÚ’»…Ø’cÉÝéüúTñeI¦ì>ˆ¦Jd©ê«'Å~l¡¡ÂÈEn$Q”©ÅzwC�pï‡æiV�h5¤úöþæÝ÷"_b2ž-î7ƒµ4¡Z³Å}ùëòý—/?}¸ûïíŠ+ºü–Ü®¥ËŸÞúåý¿ÝÜ—[×ïøøõvÅŒÌ%1Št]þüéÃw«ï>úþ‡�Ÿn»ÿñæã}dkÈ:£yúãæ×ß袄7øñ†a´Z¼ÀJ˜1|±»‘J%…3Û›¯7ÿ‰îÚGS¢PB¥yž�gƈQŠ�„¡ÉV>~ýîç»/÷wŸíÛØgNò£‹7„K–YâCS®Wë¶Ù<V�§êLN¹„§�hªCÑWÈT›%<ö?Jùãæê¶q“8³
›ö�`�IAr
-’¡‘…ÄÖœ™Oš’<_Þõ~çÂïöP¹ë±«J7*üÖEäñ¹jêªñOÛ¾:4Àï³²oÝõåP÷+däÃs"´Ì«(j`¡n�ÒdËþ©rì
-3`Wb¬Zã;kâÅTFrɵ§tòr+
¾„Qv;³n‡[¦—U·o›YHˆ$Å•1~Aص?´Û.±³0Df¹§ÃÍ‹¢ªù½zM,4 ”@Óõ€ˆ¸s,×MB:#ÚhæiŠ]UΉ'ã$ç4@îáÕ­úì§É$˜Ž4cõ¼?)vûzË[~OJà5/¥ÇŒT30q¸ÕË£Ÿ{©û'7µ;‹Ò„id·*Rb¡$*  Ý{›€Õ-Æ`í®êÝÄqï&Š„¨rMel¤´ª=çSÁòG¸þs[—ž‡'ÿÚMUù)´ÎY6WDåùˆ/.H¦”òg
v)mòŒHʦ<‚Cv<â !npÄý&DS&ΠèWÞöíc/~¸‡Oâ>ºbT)`±•” wî¼âgë=¿žJ¨gøW:Ç<ÑjH|÷y‹T'\
·4‚¡ùå-QbË¡° b
-fÔxËÖÿ�ï9öíÌg�P˜¤ÎÁ^ö×Àç/4Œ
è¿Á�Ý?Õ�ÛníÜZ&™ó×Y€H�RA<Èø›ì"Ë©ò„IwP2bû]Õ¯ÓÐͳ
vµöL¾<
ßÏÕ!±2b-T�B÷Ú¡]”õ!±þJdšhPÆØ‘½`5-»}µ®Qh¯8n¼<A¬¶£oï>}ðsáæñÞöÀ,s{`Õ¦<ËÚxÁû5Ñ¿Úkð\ó\)gWTωdÑóÍxWªÍ0¤ì™s_ë_ìúÐ÷C
¥ð�²äYvî® Ë‚x«õØ]ÍF6“E&£»¢rYVø¯±h¥Ê¢ÕÎnŠã¶wÖín缬!`5ÕÖ݉³`d·l	ê;9L#3Žp»m_ÒQ^0E´4êª&5A]6îxÎŽ
nYy™@8<WäÕi@@–R^Óœ RK1к`u`°m×ÅÖ
ŸÚÎ;huaÔ´îº9¬¿¶Î|ˆåÒ'Î5äÆ�öh´OÜïçcÓ¤å&¸ãè–Fé.l’§Cy	ªÈ˜¬V:Gî,Ž«liÜD현yÕcRAõPY° MO`}ŸÒâ~ïÒšn»_ÕžwgÊûm±Ž	<èÂú€×|©Cb+¡fÊ&g6*æßé`Q&IÑ7sJE[x´–ƒˆh'Ȩþ¬»Þ%×X»yž©ãyê·sà*�r½–G‚?P#[öâyŽŒ�!t·Á}]á
-yeË@”ØrTƬ^'[~9Ô>
¢6‚£ÔŸÚƒ7„î©ùÁ+ ÝL2§²nÚ—°®òñ3+«ÏtøæœçoYïØ°˜W�bࢴ¼¢š
ÕÕ*«šßßâƒ1´Ìúà‹¼�|ð9sI<ânäƒ1—õ:Ê|‰Ëš9=h\Æ‚£©[+`^B\Øö­¸±;ºz$‹©wá.ÏÅÖvÏ`X¶»¢nN�¤vQþ>àjê‹E+”kZË„Õ%‹Î®Â†fÄè+}©
ÑÐx"‹™ýUÌìÑÔ¦€Áì^îS�æœ)1éEBq?æj¯}_Þb!.Ì Ç;–M;zÁ*Óæ÷	‹¦�¼ñL\«x%1"VH[¨bªÆ³bómÇ
-l¾öîÙÙ¸n—ª¸%ŒÆBû�Ç"¹Ô¡#±�B´ãLŽ
™Ì	@w³0â˜=²\]ÆÑ�jH‘Ê"é�@’!™Ñ@qí.™(¨ü‹ÜEª{#H)ˆ"š²1cL)ìŒÃE-»öhõ¶®Ü´Íáê¸u4eÑnÖi¾ú³Å-’8„â²àŸÚCýWè�f\Øúïy"a)<ìtkˆrâkºW@ÝÎyek½fÆ ðîÝÔÞ¡í¹.+7‘ìô3MD<>zWVÏïü{%Â�f±·j«JXNp–®ñûÃõº²µg8x@þ"�d(Q¼i�9\ÝÎMÕuî­™Î0N¨I�ÚEŸþк@íuÝì�=I¼¥Æc×S#Ón|¦+1!óØÂ�
Iç‘ÈÇ
p9‡J,[s+/
Oyp×ÓIˆõ=ßÉ–'ác85àf'æl�†B´ùeF]Ü‚ÿ¾e3u¸(J7íd««	âŠ¯2Ÿ¦Ú.Ѐ>�©>+—*Ëa
-�(Ó}xɲءhJÛ€ô=µH&:„{V‡¾Sc4ÔÑZLPï[	èÇ|°ÅwŸuhL3ìt\Ét‡Tó-RY‡Ö]-rŠ²<x8§Šœ‹¬Å"眵d‘3âmœLñ Ζw_ܲæN—=Å¥¨È ÞQ¨¢®÷�™ÖÙ4*âê®ûŸ:åœ:圎ã¥}f>^B>D¸ÿ,^úÌŒ°éùþlÚ6md·û‡bý»/F´¥vN
-O—%»Žx“ÇO&^êíÖ-¿/€1HÞ⸵�·•7ÿÞß*JÿÙ‰`¬xzPUÖønÎ+°�ýë0`Š™¯Q4¸M�¿í°TŠh®žyXÖ…a?‹¹wm{Ñðß	k> AÚÀˆµô1ÃÍ.9·/Üg¸A½…õ'»nÚ£u8õzŠ„­GFÍr(àTã7ÇcÌ«¾‹cÄÕ*¯Z]ÉŽDóöˆ,Î�W«,ˆq‡¹*ëS±Ê:c*Ye
¹òVke­6“ó�²<WìJ§Ìpf¦VA¾�ñ°¶ƒö¥±‰7“ýÇi¬à�)Ró6Ì觧¼°C<®ÁÔPu·I¼h®ˆ¢±^wÜ¢"€T><›�Å‹mÞrp²ïÏc1¹§flúm³}�DŸá4õôŒõdÃVåÛaOá í¬ ÚxD—H b‰àÇm	pÑø9ÍÿýiäéPi{µ<�SA%¶Ž,S(*Æò)ëñ#ÊsÞÿFðl“endstream
-endobj
-1909 0 obj <<
-/Type /Page
-/Contents 1910 0 R
-/Resources 1908 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1897 0 R
->> endobj
-1911 0 obj <<
-/D [1909 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-1912 0 obj <<
-/D [1909 0 R /XYZ 85.0394 751.0357 null]
->> endobj
-1913 0 obj <<
-/D [1909 0 R /XYZ 85.0394 641.026 null]
->> endobj
-1908 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R /F55 970 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1916 0 obj <<
-/Length 733       
-/Filter /FlateDecode
->>
-stream
-xÚ¥UßO£@~ç¯à’co³ûˆZ=/Z{¶&&êì‘+‹4Æÿþ†(�.MÚaùæ›™of§Ì§ða¾ÒD[nýØJ¢(Sþºô¨¿�wgë1Ñ
-¤ÛmõÒ»°‘‹„*„íRë<j—­'x9Ú„ ¶§|Ìñw×äZ/Eû-×cÊÔíÒ-ÚëÊÝSÊ7»:m‹Ê}ÃÓ:4ÁÎaPiFA#- %Üø‹‰`FÀô´É]iès”N+�^ñ�‚êà¹.\‹fŠ?MZ>osdvÄbpð®
é"O„ƒFH�]‘@‡\†Æºªë�™ ož+—n3Ñ@b˜�=ÄjëjÛLÄ–¨NØ™`“iÕcþä¯<€Ñ*6mÚæeîÚsn{Åûb°™ÛW|*\Ô1ú‘àŒ0©5H>ŒnG–×í0 x5!¯´DÒ!¸KË<ûT_Kb¸=ôËÉaÔ[{8£3è5ºm03BÆ(—³ÆI.–W__¶Žýž*jà‹
#Ó½P£ûbGh¬a¼™ä„5ÌÔÑùü]mŸTV®hZ¸KU�G×ùSŽ3æÖýÕ¼Äë7Ñxm×Ð3¤'SzDö”T\ºè=6¹Yý¸ºþZ�s×æµË[ÌdùÚÀl5øp\¹¦ªÛbW~¶�!`·D'¶'}Kñ¿wõû’Œ‰0†¿¯áƒí+ÎzHª+Ž1ó!õa«Ìý ˳Øendstream
-endobj
-1915 0 obj <<
-/Type /Page
-/Contents 1916 0 R
-/Resources 1914 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1897 0 R
->> endobj
-1917 0 obj <<
-/D [1915 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-1918 0 obj <<
-/D [1915 0 R /XYZ 56.6929 752.4085 null]
->> endobj
-1919 0 obj <<
-/D [1915 0 R /XYZ 56.6929 626.6031 null]
->> endobj
-1920 0 obj <<
-/D [1915 0 R /XYZ 56.6929 566.5511 null]
->> endobj
-1914 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F48 885 0 R /F39 863 0 R /F47 879 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1137 0 obj
-[650 0 R /Fit]
-endobj
-1921 0 obj <<
-/Type /Encoding
-/Differences [ 0 /.notdef 1/dotaccent/fi/fl/fraction/hungarumlaut/Lslash/lslash/ogonek/ring 10/.notdef 11/breve/minus 13/.notdef 14/Zcaron/zcaron/caron/dotlessi/dotlessj/ff/ffi/ffl/notequal/infinity/lessequal/greaterequal/partialdiff/summation/product/pi/grave/quotesingle/space/exclam/quotedbl/numbersign/dollar/percent/ampersand/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon/semicolon/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O/P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/asciicircum/underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/braceleft/bar/braceright/asciitilde 127/.notdef 128/Euro/integral/quotesinglbase/florin/quotedblbase/ellipsis/dagger/daggerdbl/circumflex/perthousand/Scaron/guilsinglleft/OE/Omega/radical/approxequal 144/.notdef 147/quotedblleft/quotedblright/bullet/endash/emdash/tilde/trademark/scaron/guilsinglright/oe/Delta/lozenge/Ydieresis 160/.notdef 161/exclamdown/cent/sterling/currency/yen/brokenbar/section/dieresis/copyright/ordfeminine/guillemotleft/logicalnot/hyphen/registered/macron/degree/plusminus/twosuperior/threesuperior/acute/mu/paragraph/periodcentered/cedilla/onesuperior/ordmasculine/guillemotright/onequarter/onehalf/threequarters/questiondown/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE/Ccedilla/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex/Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis/multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute/Thorn/germandbls/agrave/aacute/acircumflex/atilde/adieresis/aring/ae/ccedilla/egrave/eacute/ecircumflex/edieresis/igrave/iacute/icircumflex/idieresis/eth/ntilde/ograve/oacute/ocircumflex/otilde/odieresis/divide/oslash/ugrave/uacute/ucircumflex/udieresis/yacute/thorn/ydieresis]
->> endobj
-1483 0 obj <<
-/Length1 1628
-/Length2 8040
-/Length3 532
-/Length 8905      
-/Filter /FlateDecode
->>
-stream
-xÚíte\Ôí¶6Ò ˆtÃÐÝÝÝÝ¡Ä000Ì ÝÝÝÝ’‚R"‚´t	ÒÈ‹>ïÞûüž³?�³?½¿w¾Ìÿ^×Z׺î7�¶‡Œ5Ü
-¬‡¹rðpr‹t�´�P(ÐWç�…C­
�f
L9g0ЇÉ]Á¢
-Äü{fXE
-0Üú÷äè¹aÖ�ÃöOÃoäæìüØã?ûÿxýœÿŒ=ì	a.ÌÁAb¡ö™9Y®
Ä£ò/z{x�Âœ*Þè—ÖÁ»2#×Dj,ïêÃ8›ÇEµyÍî;Ýoª²n
öA™ºÓÁß‹(üèX>ã.3v±ms™W`gÅúϨ¯"›
-rn­�êèš—ß¡RŽwð9£_²Ò¹Ð_8=óe4%v>oFÀk(Ù?`LÙ½¼`êú4ð±ûåÃ&9[~ƒ˜;26cLà«|r)Sƒj…×Íl(ßÛ
-b¬Å7ÎßÊçÏVð™h9�Žù,¢I‚°RÊ• e®äß·RÆ%=²ìÙ
êt›œ(†Ì%³LÇ�î)®Ž>1Ù¥‘„µ…^Ñ2¼éˆO£Ý	%õ‰>•pjÕr{2–Âw�Í<–g¬™-j—!3cäáakIè,AŒ$ÁLˆÇÆ‹J¯³nöùU»Ïm›Þ‰D3
-~"ÅVöè=”Žòíí`õ§ï3t;k‡–Bf?õ[¼„Y®¤¾ša£„+gl’ft]ÎB‚²w3ë‹,£ªˆôkêyô’­úÅ>¡ï„móW¯µrÅý¼0Ï”dË#»§BŠ¸ÝUJàžuÕñÆIÍôaòÔã·×¸§™	žL¦€Ädô<­cË-8àÒ—£t‰Äº4ú£|©D„¡¹šŒ]¸ãÏßE¯¡>ÓR·9xyôöŽ[Ìï`º~ͲûDœ¨'ˆº5e[-0GMÓ=KÊÊJþ&â&’PøS¤8ëãin,õ	2PU«r`ZÅÄí¢v8Q—ÁèÍ	×ë¯oã»o[�2ÝO2Ó¾Ðm/Ÿß×Y¿üìvV¹"_=5Ó›é�¶è áaÖ™7þv|g	“y×&"YæЖ(¾+ÐMoûÁ|°>›à¦±vZÎI ÏW´Ä%�^‘›üˆ¯­Ú]Ö%½ZÆÁ_Ï@ÄR�dçÒÄ9è©‚†õ‘kã�C¾¥HzõOlnÕž
ÝÍà™>{óbÙ7U^|ä-)G?
-8òÞ¼x“mì¾%ÿjã=!•š[žž;[#ÆŠ™éJ©/A%Ñv–µû`éióöí؜njP~^z•çQ•7˜¿\扯â	ÈÛ.|âùúÁèéá™
-¸È÷»Œq„z`²\F棖ûEœ!~õT¦¾\Ž'4/ýCîe–7,î9tãÒ¾Â1¦’·IM^y/¢˜kIm;˜¨½}O«•oÐHâ•¡Ç6—]í
7ôh`†J­TÂcweófœkÔ­—ÕRÐÓ(9%�Ö¯c
-Ó·_Ü€¡èüêr_7ýGmÔ&œÐ‰lÞÆŽ
-Kê#�TðÖ†§øñÞ¿šûDE&ñžËœ^QH¶!’Þ»¸>àáÉà̹ç$ÚxþF`Š×Í4IŽ@N@ÒÖ>_9²J¾ÃEúOê
-uÿ'¢µ?s_¯Ð‡öÿŠ˜'u
-BêH—‚?ý
-$O�íœàÅ€DÈ
-¶_O®ð-¡;…®u§uªºXÄ[AŒù××¼^L¹ê=_󱑵ħŠfJ—äÌ;7œ1¾,`_q”�¾´9›Œx•±tþ”
->C{(�©¼Ê°nwð,K
?EÚ7þBq&‚´”jÉ�¸ˆ�·?è¦ú-ŸCØüƒ%¥uXcýøââBïÅ ´;ÁµÜ3höŬ¶÷Ét(‡„šœì :î´cØ¢>:ƒ‚¯úò‚#ÑǤ_VItSÏ$ëŽ`ø~"ÔܲÜr$ŒU–Y7÷“ø?¢ê¹iâ¯ÉqÅõãÏØ�ISª5ñ4Â…èÑb“EÝêÑÑn
›p³ú†-.ä‰ìošå•Hû~B»ÎÂ�î‚T§Z§Ï_)�©OqÓzèß�÷>ë˜Ê;­dpI¡rr1ÛA
-öÝPî2Pw]¶u¢èúä»(£ý/Ž¾ªˆ§þßÜ¿~&æ[1¸Aé-KžÚEО5JÃ÷.føzßwi°h“bLñB³ß6ˆ
-ÃÐÙ²¶©HÈ 9^©�;¢Ìœp»Ãm%{r7E•�€�ÏŒµÂE±…ʨ*o,„óQÞúʭ䦀(ô$íªy{Çgk9©‘�5Â1ª0Û˜F3ŒÛ!s0¸4XàŠú#r¥Æ2á\8nqå°Ãs}䮀„s–è5)q…i¹
C9ad¼¿`u	
^<‰2@´ÄR­×$âƳ—xº>áÈïž¡wdª‡}Té†×ÎÂËõ€Èøt\1Ü~‚9 ÿ½8iaD9©ì"Ð!gÑßqÝùA“ׯøŠ
-»]‚Ä�ÙªAÓ8ﯙÎd@Iî?_ɽŽbÎJÊ8&1ß’bçy·ÌJü®J_ƒ|¡iïÂC®¡L;¡Æ–=x8"ÆÝù\šGd'—®®ðÖ/B¿ÝÞpRÆ'µsñX'MÂÁd;ŸäÕEûtGmý«†g¾ ¿¨öùWí},¾Ï†Ä›tÓk„fªõžÑ »›&�oô/L¿ÇGìü²•âBZmÎOw݉Úñ¼>–¶ü^ÝvšÉŽHk6Œ´­¶DM0¦›}Öda'¨šßo·é˾xWp¼311ïçdϘ9óÅ­Ô§?¯jò>*§¨¦‰Ð:’-+X}7¿$ÏL\œö¦nD™ðì�¡ÉX˜vWŠñ=mç¡|'M}„ç‹çÄ_’øÏ£÷rci%Åës܃ ¨ÄÏ,n±±ˆ" 5Ù½6ìÉ6úQèÒõmŽ¬öó–à+q®Æ�¾ùÃ$ô|Òî]¾öÒñÕäË&�æèñ²€Õ„KfVº”DfƒŒåZóbúä`#öZ·<Ò_Ç÷-¦�ªÏôª
-_˜lg˜¨Î>«ŠTÂ70¡ðW~—ÛC!<ZüòþÅ#(·�3¨bæ:ߨn¢Œè½Ù$ÞÄ‘Îf;®Ì*=ËnÙ†b…ƒ´ÂVE¼Á<öuBgˆÿׯxî×_ò­Ìz—XˆÖ`©Ö4s�iÝÏAí+<¾ŸãÁE.Q˜ÒQqúÖDõ”ÏÓ$`d�lÚ/BŒñY<xŽ%Á„+{æÔ¢´®³N‡­”TøTõ”V3Tj+"}âžÂr}©Xž\L$ÓÇÈš÷ŽEh®Š-x�ù
->_ŽÎr¦x‰|„ŠúNx‡<7M–/&×gaÅj[²Ë±‹4—À¤ÀÖO–|¾1_JSw{ðÐıDÃP~�ÜFY­Yy³]ˆ:¬aÔ_|žjÓM+ý­‚0@îhÅtÙl¿Êgšê…µAbDå·�Ôw¿þ}û�YÕ×iîBÕ*jòýZö˦ÏN’FéT/H
n±úÁÖ“4ÑOEìØœz~Ÿ
Þ88‡á ‹w|q£ªšîFªãÆÇ
-TT>/5—䬽%‰”dðqÚnCÃ%Î4Ã
XDmeß:#ƒU¹Ø•l1~à4±GL§%ÕëEЈ®ìÒ\;ãÛ8Å+§êJZdº×d¡K©¡ZÅIŽf3zV#W•c[Û¡*_-�߈¯Þ­—¶5k
ª€º—,ìd¿»Ìë÷S/úò¢×Ž Nâ)uóÒY~	]ßjÑ×Ù˜fšuž²K,tÊ�÷“\'gy¿÷5­<TÏ4CUMà£Æ�gÿ3Q£8Nð²Ã‰ËzN5\/MØr®]�SÝé}pæ§VD@™:]¬ÔË7>1ÌÈéC•'ÛEÆŒ!…Ù7aVì:ASQ×µ{|ãÇj9YÈ4Ö|m Î·*_íw4ø!D1 ñX¿Ù¤X•³ç
-t�‡Í=žÝbóÆÃwî6ß"£“˵?�”JËOP2RÐoQo+†â1)©w†¦ÜèådîI½ÈZ¿VÍ�­(e÷åû È
"QÔüFØs(úF�$'‘qL ®/¶!õÔ
¤HvkÖ‰Œh¼È‰¬ê؉á¶o?Ùa:Šÿ±qêcŒ°gã!_QÇ~ÏWê¡1üaœ¯UÝGmã§Yñmn%ìRãr9÷¬ß0qˆ5†/‚E…(êÚ“�†,W‚˜$Ù½ï¶åçLxËÎÔ|ú奕£w†Z|ÂV€ãž÷,éOd
-ÞyŠGÝ
 ŽÎ¨Ý3lÍ4©¿Î\×T2Zª½Ag—.7Ù#ÏPæï™v¼eŦQLÞ»±Oþ¼Ô\’	¬ÿĵJÅñ¾(š3Ç].Å*,MÎ>ÛBx�(ÃSÃó|D³uû‚Þ¡ï†{:Ò‘Á¨2G9¡Cê{É•<|?�ÒK áéá@F)Ø,êw÷ó?�È ¸¢Ëa„Çh%Ù±o^Œñ{‹6™Ý@¥-«ä%
Å~jÉwXjz1�îi´·î¬%uÕ3^¿±g�¸`d+ÎK[ŽDe—„]âò†Yè�ÖýÇ?Ï>£³HjË,èkѸÍhÔ8Š”™v_Å
[ªJÖ®²9m=·�âú?\‹k>¼à¬‡¤*³Ñ³ž,Y
ê<‹ý¹uÓZ/ZV$S·é#ƒmNOš¨5M@¿§rãÝ0Hõ7¬&7[àçŽAØñêOõƧÈêÚ5±pE6~d»Ž^.x¨T1¬µ¤$£Í7¿ÿ4òÆêüj§‹G1¬èípoóÌ3³QýÐZ:œNÍÆéç,0½‹Š‡Zg‹ðâ£à)‹Q©¯³‹X""œÛÆ0�ÏÁ¾äBvFA‚)Y9(ÎYÖý…ì¬S…|¸Ôü¾“qbæÇN.LÔX§…_�ï‚¿œ%�%½¥åŒìé|°
D>W²7}C–Í#—ZR¸
­$º`bÛGο…a¿9gÝS%\”Á/œîñ�hC|�?s§Ø…šg¯ÎÙÈ)ª¬m}ÐvÖËk†Ÿ.bÉ&O
-üõí+uqfº`Îa‡„°£â,I§ã¯½/‘�˜÷�ÇÝ›Á¤'P6ߢH‚
Ú?÷›½šÙ¹˜Žà9¦ŠmHr7:pMRYŸ#£ 'æW¥¿ðKCß|-¡mWÝ躖nᲶË0–«ÞÐ3äÛÙ=j’
¸Ë-,n–³e±€¢üb½iÙ;‘˜Hâ°l<)žL.ßÐYÖÿ°Ú·)�wL=(‚Œ£± L|�)=å'ÀÆ-Å@²öò¾µ<ÃNrä³6îµEôʃ3±d¶kÓ»¬ÿ‹%ôµøü·(kD~ô(¬_yñ‡Í;¯åä²fùOî{&*‰äyÒ¯9Û�B±T¨d>è.<Sâ¢éX3p7«Á~ª"럽Ÿ“lË´ÍÔDQÿfŒ°Ì
-*s"}Y
;Ò‰¢ú{YÌÝÇí]p¶Òݯ€Ž¶Xo³êÙ}
-endobj
-1484 0 obj <<
-/Type /Font
-/Subtype /Type1
-/Encoding 1921 0 R
-/FirstChar 67
-/LastChar 85
-/Widths 1922 0 R
-/BaseFont /NTJURL+URWPalladioL-Bold-Slant_167
-/FontDescriptor 1482 0 R
->> endobj
-1482 0 obj <<
-/Ascent 708
-/CapHeight 672
-/Descent -266
-/FontName /NTJURL+URWPalladioL-Bold-Slant_167
-/ItalicAngle -9
-/StemV 123
-/XHeight 471
-/FontBBox [-152 -301 1000 935]
-/Flags 4
-/CharSet (/C/D/E/H/I/O/R/S/T/U)
-/FontFile 1483 0 R
->> endobj
-1922 0 obj
-[722 833 611 0 0 833 389 0 0 0 0 0 833 0 0 722 611 667 778 ]
-endobj
-1298 0 obj <<
-/Length1 771
-/Length2 1151
-/Length3 532
-/Length 1711      
-/Filter /FlateDecode
->>
-stream
-xÚíRiTSבª¡¬2©¤j=,Œyn4„„1d%æÞ�[’{éå’2ˆ8PIU–EltÉ(*J…UE (µÄ*¼N¤U„,ŸEªVEÀ©¬««ôgûë­wΟ³¿ý�½¿ó�Íp	
g‰a|ˆc$bC"à/“I!. Î\.�Áð'9‰âX€œDD
-=Àj­ðV
-ÑP5r5Ç(BêÙ@¬Vƒu“7ÒÁ:$!2˜Mƒ 
-l@RPŒÆ™Ô$Å”8¼�amÚÛTB¤S¢€Û”L& DÂ8¦ÖQÒ8kqªBiù'dM/¨U«×Ê5“姜úK^®AÕú߸&MK"�á0B`Ó©ÑÈq2FµšéY))W£
-1–¢F
-W‡‹f/ô¸Unï{»c|š›Bd¿Ìèb
-\ŒïvKósJ‚£¥‘£ŽV8(j¨½ƒªé–H}k\‹Æ»P0X–ï�ZßÉó.†Ò÷0Ö%�¿düºdÇÌ'‰ÏŸ÷>{m ·<Pd¹X8Ÿíî¹ß7ÃÍ}˜ÙÎ¥[_ýÌä+W}q—û÷Ú¬2´iþíÛŸÝ<&1ÂëyN7Ž|æjæÑî‰Æ5{Ëÿ%‹sÿºÉ´;A¢³Æ^Ä>ì¯|øóÅÃ~^R |oò™ˆ›î—jÎW8ÖÌL45V-iš�÷øÍwñq\è5×Nœ0
T;ͺuE÷Ug³øã‹Ž‰<t¿ðú¡$ÒÔ8rØcQ®õÐæ©;Ù÷#–gyþbu.¤6YßéY{Âôý¼e{áˆlVØÞÔc5!5Û4úGÂ9{Ž
-ëBVåÙgŸˆ›¾S–E Î-dãÓåÌ6Æú˵�H»¢Ðç•Él"Ö÷LK+F`ƒÇdz2xg>ZÏ÷JHyÕísxÝÁê¬]<º¹rÑöõ4‘MÏ€�ž&ù´$÷õ–Ñž ­�½¤©=ÞŒÝ=j¼ý}*Ø|ö ½ÖÕ;æ«¥>-ôºóÿ[ÆâÙ+#²¸êX÷BËþ	Ü\©©ubÀNƒ—üä)nfg“Ìñ[égÌÔœfØH2½<QUÅÉìYuÒÃ…\3V)—JO©—[̸=sìq‰óàSbÓ�«Á‚†ò�°ï­ŠÐ¸ÑŠ	ï;]Ú<ÇË#…?�^!SÊ^LJïIž¯ÌÔë:çe6u•.°+×ù³Ü¶œþ(ësÞ§�›,æk¥¡ð7–ªömׯGÙj ÍÑBïÙ‘˜Ž|«ws
-WÓéŸ`†¥ucº}uÁ¥ƒ}Gv\ÌŒ|¿ÀtÇ-ʹTRòÊ26ªn¨Ý²,áOäШh¬7ì¾PYlûa”ÚŸ(�ÈW´ÝJÚ¼zXV×p|—Ívè *»¸knAó¬…;6ýèôhYFxÅ—q>çùQgù}¾s¾u]\¤"ᤜCE’ê)w%=ÁÙÏ|¿{~Ç:`tÉãè3Æ‚烪ÞÓžåÅÒáË�â›­»µ]ê¦ê҂ݲ¹5ëß	²;Ô~YtÕÎ{W{q;ÿ“¶qú2òÅ«ø“Ë�¾Ö'A
݆‡A-k2aìp`»¶·Ñ¡Í—�—'.õ뺾sD•ÔÐq­,ï',2¼�>ÑVµo™Çñi›E,Zͺ÷Á•ØO¿I®Œ�—´$^íù|4l‡à…9‘ÃL,bÉÉUÝüyæ
O2CåWÑkû¹sÑþ_ࢀB�È	×ȉTÚoU팯endstream
-endobj
-1299 0 obj <<
-/Type /Font
-/Subtype /Type1
-/Encoding 1923 0 R
-/FirstChar 60
-/LastChar 62
-/Widths 1924 0 R
-/BaseFont /AUHQZV+CMMI10
-/FontDescriptor 1297 0 R
->> endobj
-1297 0 obj <<
-/Ascent 694
-/CapHeight 683
-/Descent -194
-/FontName /AUHQZV+CMMI10
-/ItalicAngle -14.04
-/StemV 72
-/XHeight 431
-/FontBBox [-32 -250 1048 750]
-/Flags 4
-/CharSet (/less/greater)
-/FontFile 1298 0 R
->> endobj
-1924 0 obj
-[778 0 778 ]
-endobj
-1923 0 obj <<
-/Type /Encoding
-/Differences [ 0 /.notdef 60/less 61/.notdef 62/greater 63/.notdef]
->> endobj
-997 0 obj <<
-/Length1 1608
-/Length2 7939
-/Length3 532
-/Length 8790      
-/Filter /FlateDecode
->>
-stream
-xÚívgPTݶ-HPPÉIhrM‘œirNlèZº›,Q@¢ 9G%#A2HÎ9ƒäŒd� âC¿{ιõ½óëÞóëÕÛU»j¯9çsÌ9æZµY´tyd K¨"Â
ÍäåЀÙ[:£tÁj<²8pk&`a‘CBÁhÂAŒ†>B!
- ³‚:  
-uû
€¡
-	sDn³jÉ+þÅmFÿÎ�‚ݺ
ëÛHÂÊùwI|·0·^4怠¡nèß¹,¡
-a%ð21%	]F‘Ñ5 ÿ¼­ˆÕè˜÷Iï}¶ïGD³Obð²hÑ‹ëÒ@ÞÊ¡g7uî“;Ž?×U87zZÈálÍñЃ,Z/&ŽÖìG¬
"\þ|æy„I»†áž‡jKØ&Oø
6V´uÌs¯ï>jDâ~çðerÉö%e>w$ò¶J¨ˆ$k|X‰A\–³³Ëóõû9[GowWgó1Në:
Wz$>‹˜6!k˜¯S:�”‰~‘g„e.0¦ãclKP«>»àÂÌ1yÕ’ ÀdÿS¡Õ¬çn9´éçï©|e>·'ëC‹›f§—ЛÙq€úYšµ«„8ë$f
ÚõSëÁ·RÞoÛ@*¾«ʹAÔguG…*|«eB‰;}ƒv©¢]ùßÖÒï6”�‡yÛ}sx/Gj¢T«$Jñ£•H
âQ–®‹B~RlEÛ1w.ì*Çbr|¬½}$nÖ‡·Gs]> Ã?V1ò�x£+w¿³\õ9’e‡Ð†ŠØ¥ÍäÊv””7œœ¸äN­Ñ÷«/ùŠö.‹ú…&Ð)âá0äPùÝÚ…k¥èé¹éÛR§ö
-^8³÷&sݱ­|&éŸî#6cÕ¯‡‹úœ‚œEë=öÚÊÔïƒ.Œ
}(pÚéc8hXÔêëeM±¸ÄÈpefI­|š
-8xÏŽo‚¹
Lœ¸
-R!ß1Âr<;Þâ
$ûg2³£§Ä¯Cǥs‹©Ï¹å‹E#‡„2‰ó9[ª«eÖb	äBñÇ›;qäë4‹¦y,'�X
È.ó¹^Ûû¾çm}l3S@+'éY“W[ZTç¤a�y þR#ÁWeôùì¯w<Ààø!ËêHô‘ªÝ°a2Y'ŸxVc[ЃÖ̺«P‘�|m÷L¨3X´•¢|FSp	õ6!wˆ¥qi­ÍÖ)/)y4ž^ÉdÏ—“¦'»À+Oð+Wë³Ã�/HŽõ°8³:̨%¾0€°nô™¦RºNSX)šÄ©wo¸Vá"n®¡U®�uë.ýe‡°ƒ5­†�âÁ„v0äÓ=Ì­²Ðµ”ž²­ÔÂtwï‡tKy…‰	ö€À›Á²Ãí/hÆnfÔÛYÏß35|\Ã)͹b€½^s$�QÛ<.'DÑ
-(^‹òp߬h7š” ~Ý¢ñí‚…Ë.^,°�‰ðzÈî§D€×û3ÊZú’|JRA.KÞ&[å�/0õî¼2³–ÛOy«ó�CúÒB«e€öžt‹:¹ïäCA2µÅËV‘ÀP½'Ûz”êÅŒ~,ÁÑ’ØAkQè
-
Çö7=s`[šzþáÞ•M�åME÷¿€uG–h‰+÷ÜKI•9º¶Z¶ý3h#`+]¥J¢æ·šõ¬¥¸¦4G‹Æä5ÍɦŸñ
¨/„~
2…°ëIš%ƒR*µÈ¹ï¥‚CSž[çm•&ê�,œ^ˆ®ül™ò‰0¼3F£!âù2°gáȺÝYzñ‚Ä^˜X@°æ¨Í›#díQ�¿¸ ˜ßÈ?'ty…Š,ÿˆbx_¸Âæ••ÌDC«½¬}�F0j|{¯Õ\þ˜ßsžù¬—}8$QŒáinúAµ$o<½öR•eµ#�"Uòe¥rÞ‰KÿñÃ=Û`GS"“H®bʘ#6W?³æ—å‰ÖÎ+ëíø ·¯ô–-ÝI{ˆQe
Y:BøÂb¢÷‘>:_/!€ÐéË@íáÞÑȬýu¢‡3èµ+òLn¯óqŠq`Uúm�ò'ÄaeG-
-óŠW¯C鶰€®ô
-„©ÊìiÝÇ.h™³
6'�¢È6
-VÍŠ2Û71sz8o+VPÚ^­M£õ‚¨‰J®ÆÕe/ýéœGÎ>Î
-òÎqE„¹¯øç*+nû…Æ—²;OeŸöY:«*š“ïgœò'\Ý7"µkûl‡ÉqèËÑÌ'ð9‘Tgeix¿qVV^­ÐÅnOiêlÄ&Àh1ÿ¥n†	Šo-R’È!î±~x“ýè‘·ÞøyoÏõÏ4íÙ{¦Å\4X²‰¤÷•�Ï´±ÝÈ/å�µ½¸N%{’;4u)Ç!‹=íè¡ç"Â3¬¶Ðœ�š®`¬õ<xö¡Øà
- 1±#-@ëÓóÄ<ì¾âæ©)[‰Ø“9QuC—̨é-ûFæÉ€?›ëþYû|96£àj’òÖåUNºnî…XÓ°‰Ä·ÏGÑÅk'uÁêFd×É>0¼f»åæ6ç-#vƒl|¯göÕšŽù�í:qÄÔyN¿3-y„¨Å–UÇâ${Læ6¬ÆÚRøÉ™¼ó¥?"áZ¾þþË\øQ>È”	§{õîû7l]
-™mÜtW?e‡ÌŠØÇRXÝŸ¶«
qÐNøb%2t)(	æß-Ö§9¢A¸‰�Éš2žŠŸ±;Njf:¯ƒ9NÃïÊœT)š…ùïš=l“'v!V‚»ú7?êÑš\“Äk=ò†º¦ù^š-2~ë‰Uïs‘.»o¨ËªüaMfsÍ%W2b+¯ø¾
-(Ì°?ø6|Kú‘œ™µÁ86<6zlDÌ)®VésF¢¹¦GfôZ¸èøJü
P!Hl�Æ<¼H›8ºîeg©õ/¶D-¾ú‰¤÷ ã›UêYœqáÕ±ÇøË
-*�Ïp›Â¤AwÓ'v•ù7Vš4¶¨ž+jÙÚN9dB<o¬L©oÝÌ#%páÔn³òäAH41ס
tö.	Zm½0ë¼r˜$‰®XrJJ&¼è
¢—Ë™¯`¾eM¹»3µ¤¯û_ê÷ðö�}d½)(A=À_D‰ÔôÛòbN¿Ø}® ÆÿÄ5,¢Ó�c9A7!ô{•K*J^ŸÀ~™j'÷%U­YÜ{ñ•Ý‡å]ä"Lžïxiå2¬Ž/�ï�b…U¸ƒjå×)4§"ò§ªÓ
-?Uôü¬Ë÷
-žä²�5Äõv!.[7$›\ÉÌù ö)%Ü-DÇ9øÓ\¯äͯø7F Oâ×ÏžÅÚÅ8i“£òÅf&\†

--â×6™…ÈXÓØø,ï¾ÆÇ„Ék}YÆ
ð”êA±<‘‹?qâoYêL�Áoȯü¸"‚˜‰œñµŠýVw$€ÇÞ5-M¶Ãú&š{ŸQ}2Ñ»5ãùáö¶xĽuéBÿ;¤»¥ªïÕ\rþhüæx¿Í?‚^iºÇ&‹	ÕCžËQµ
b\¸THüe%¤¼®QÕ�E²üO¥}¿:y´ÀJ ÛAHù åP¤-´á€[kN�Ô/ˆ<Í©ÁEÁ‹zHÃ('¿8/ÖÈ><ï·NZN,±$�íŽÝ\ë|.ʳ�4
-Úu&IFlµPÈ‹˜<>ê¼çO}ö•>ݧ·ðgžF±;YuQTˆ §ÿ�æ‡	¬ßôtD¤ûfP˜{s“cÞ·+J�	.>xi¾’²È¦{¹3Åš®Þ~—ÛãŒd@ãa‚äÄ·Ž„kï887Kp¥ôRXŠCãóÑ°áTîEQæü^w~@³ßG±¸½Kë3rÎN¡À�K’jùÚ
-}~ÏLcÄçt>í	ÔN$c÷¬¤úœ ú=nÆ©ngþõžåÆIE^ÕÖŠ
-!dÌFæö/¨˜õpŽI^ø©Ý©²‰µ([|«F�v/f»H/>_!üËê¹ocG¥%ÅÉs5“•ŽnÇ5¾Z‚ÏÝŸ¤±ðJ©ýšžÇÝ\UËúö¡
î[Ÿ2Êíß2û²Qx„úûs‘½¯Ø«PU XäxŠnO
-IÇ�äœ÷îÍóÍè	v ó4ýð
CihTðÞ�²° ÇÒf%’2Ž
-Oyâ|g܇;Òðh¬Ù#1|éôë6Ög²›œ·UëáÇ	rk_‹öw€º«¹j!:/œ*¼È_Ô¦¶S+³�(#>û­pKÕs%ìÛø“hj£ê·ßN
-\O–ˆuõ–.½½h8¤Ëµ[%-n&í—o{Ø,OJ‹ä k ƒ$4Œsz!¼¢‡bÃ7Ú‡vçˆemÝÊ5Hcý™’W¤uÊT�ãO³‰³7	�†³Ê;B¥È†“ŸÌõáõý"¡dËUŒtúÀóñ[í¹0!Ã<Ú—(U½›È>ä9íÁ;˜Ö€7¤ÊÞ­:À¤Õ²y£7À­ÔÁT}I”C¶–�‘Qîì¹È\·ÞWõ3›Ã½ZÆ™&ÝhÄlÊÞK\o`~~çt!•†ó(à'¤§tq	Y†¶�bëÑ4r3ÛDZëòa[ö_ó>(ÁÔE7	bO;8�<0�¹8Ô4;Õª>*ËVëu?+«h–H½~šq»x/·}$ãºÊá+¡V8|ýƒ!Ù‘`Ç©³Mò×ÎàåÇøQÝ'ï³eò^JYõžâ7:¯?¾kñs”ÛqWç®fa Š’Œý4>§ ÇZ'úy]Ü;_GdRÁú	È•†bn¥æf§çƒ\Qù²1³7›
-3ú·<Ȉ›h¥=¯`·�C-ãZ*¾•‘Û3ØJ`+>…p˜;w	cÁ¿ù\å�µdf؆:îÉVÂÊ£QÏ
-Ló¶Ú±{iC¤üD8þú�ñ7.4ß=£Nƒ~ØA�·™Y¼ŸíQíì
-;dÕÚÞùYÌú.�ëÅ3¬m
-Œ·Ò'OܧZM•�ÈkÚEä»óÔAøV¿F+áÖØ\7H”ÕÁ¬–ÞÙ‹s±
-A7µ¢¿�ï?å151"yU�F�„I×íòÏfwÊ*Q�;1WG¬ä‡üÖWG9
-dòú“¢Ï¡ã6–±hò¶þ|áç RÖ/?‚jïVÈttf=]«­mîXCh-»E²`?|(“躃Øçw¹©”]“RÉÆè·¸¿½ú‚[O÷^Üä'^m[ñ™4]aÄ‘þÖ9ö5QºÄ”ÔbcÅ‘
n"¾ÿ]½GF&<ç
¤3dRµ°%‘	”Ê.Óµ­ÉÂÆWòQmw)‡GÒDa™e¹ÔÖl�NA|¦Z–ýÒ½‹Lýƒ÷ÛE}b\ÝîL» &épƒ·gr[‹÷šßžz÷ìòdÈÄº‚íüë£-«‡Z‹ÎîpnöŒ´Ð|˨)	2xqô¦S=w¶Æß
jIž6a›�6Ä.OSy]ÆñþS§oa¶Ô«ˆÌ±â£Š51r»%ob2üpȈEÐ&â§ÜÈÕöIòÊp¤ì‚è¯ôV²í­NæçiX¯Ô²»Íæá‡A$­Ñe$D{òD¾Ÿû‡‡';,Ög¦•k\�Ü Gái3¼q¸Qþ¥L�
-Xæ"¢Úbò3¸ý]ub7¾‚夨õù-ÅsÅK>ˆ<–!!’=j‰Á
bê÷](åÏi·t9ù
-KÆ.Ha½+-Ε[å�òÿÑÒñx Ciif|-i�s \‹¦ÿ€|�6±m¦ÍñŠ =“1ä`K^!y9ÊÌßIjX÷žXHO~ûLýì«œÈF7v—")òï@µW™[zb™®ÕÚ4“*ý÷L´ªŽœ0–¯z$¹Š/‚„à{>UiO³ýE©²5êæ÷”t¦=Ä;î
-€¯À4?œt€sTeù›!4J%h¹‰¸—ŽQÏ:µ¿yÓ´(kY¸³½M>X‹–
sôqÀirÐÀ³8!ÂùÕÏS€¤Sì$óÅ­$R÷Ñ•amPÍ$?çÔg•ËŸ˜V�d[ƒ�1ËiÇO°<Ø_¥¶%y�ÐœáZ�.›eˆô¤Xþ*Iò{()õŠ_¼¾êW÷ºÛ£x}kã¾ããVÔ³Ö–I͵'EÜöGi‚õÂV;áåÏ¿Ø×6™+Ý$É�ž	{ýTö"1Ðœä5v-V$ÍlÂÞ¯«ª›
bݦ´³ã)º§ÊoS6”hLGñ…îÇ,v%¹u©I~®]%¾)Ñ}ú‚¸2¸ âoJ°]^¯ÿRÓ HmØ;Âúž
-8>Ô
-²©
-3ã½+ôÞÊ•÷�aˆlª Ïn×–OBw:ëÌDöƒ^ቃ€¸Rn¹šd¢¯ÅÓò;SÓtd®ÌA~zM“èRVt}õÚ+'˜	†4~}µ÷°}³íÚš[T:áµ%|Å’Q"èXê³ÚÎÝ9"áòç0Tw�³È‹d·¿Pô@åÉ@ÅìÓEâòxOæî¹Ã	åÏIXUb_4²üQ
¨:ù©^\õ47ãÇU¸µ&�²ð�c
óŒA«`á0Ôýµ˜—™žÌ‘¥ˆß·%¢y†.Sz¾M²hàž·ãý°óg
#$SÿçÅOÁëÏàBø[yã¦5åž Šq(OÜâƒL
#‘'Þ/ãØ«*ûü©¯ð5X1œæ)ol×Ós[2L&³d´/øÿ—ÁÿøÀ
-#Ñ{0ÒŽàÿ
-endobj
-998 0 obj <<
-/Type /Font
-/Subtype /Type1
-/Encoding 1921 0 R
-/FirstChar 36
-/LastChar 121
-/Widths 1925 0 R
-/BaseFont /MTTJYO+NimbusSanL-Bold
-/FontDescriptor 996 0 R
->> endobj
-996 0 obj <<
-/Ascent 722
-/CapHeight 722
-/Descent -217
-/FontName /MTTJYO+NimbusSanL-Bold
-/ItalicAngle 0
-/StemV 141
-/XHeight 532
-/FontBBox [-173 -307 1003 949]
-/Flags 4
-/CharSet (/dollar/hyphen/semicolon/C/D/E/F/G/I/L/N/O/R/T/U/Y/a/c/d/e/f/g/h/i/l/m/n/o/p/q/r/s/t/u/w/y)
-/FontFile 997 0 R
->> endobj
-1925 0 obj
-[556 0 0 0 0 0 0 0 0 333 0 0 0 0 0 0 0 0 0 0 0 0 0 333 0 0 0 0 0 0 0 722 722 667 611 778 0 278 0 0 611 0 722 778 0 0 722 0 611 722 0 0 0 667 0 0 0 0 0 0 0 556 0 556 611 556 333 611 611 278 0 0 278 889 611 611 611 611 389 556 333 611 0 778 0 556 ]
-endobj
-994 0 obj <<
-/Length1 1166
-/Length2 8264
-/Length3 544
-/Length 9079      
-/Filter /FlateDecode
->>
-stream
-xÚízUX\[Ö-4�Á½p'hpw×*(¤€*Ü!‚»înÁ]ƒ»kÜÝ/çôºoŸîûtßîw«öZcÌ=æœcÍýíz(*r%U&3[ÐG[¨+3� 
-në3Áù
-|ØGè´£ÇÀNâ¨Ð×	éÛb®=R‡äEÚTBbCøª
¶DÞ¤W:›[öŠ¨$dEY%Š[Ót¼/oü¥¬½”ùP'û[Ä�–~�	X2­µc×42:Xµ{—%ÍøFSÓ]¢8œÞ“
’˜•G&$ÚÜ|-C­l7…�à›ò~»,Nv}»Æî,@HíŒÅfMè\ƒ•jLw~˜,r
ÿMüF]_©
-ýÍ8¶öOáÏoëÓ‚úïLîÓ¼¿œ+è¶kÎ6ÙA
Ý$=43Žºoô°Jü¨rOwVsr¶Ê¬ðšz¾Ž~ÿ²ºþëÁ‹êËõ-!蔄Wd=R9‹ò”l:VŽhÔïÀ³¼Lô
Ãaìtþ8QIVæy
U&Á¡û�«ü\žj_E‘{<ó�éYàôDËæúløa½ê£D–Îîç„xô�?¹é$Ì|’"Xûü"rø—Xu[ÊÚ6·èNâ÷�AŒ»®qmƒ½É�ý¢¹Hx7žMxÃ
_Õ[±½z
-¼*K«™Zú¹úÕ°×Wý¢Øø¹.ÔR¯�æESúLkéDÐ?«áäv%.
-šI-b´zŸŒU íÑ—þDÅyMß\…‹ÙCó«ïÓÖSätRR˜…$ùÛˆFy/Áê}äYeOÈZñ¸ÕÏ«¥¬øïc}͹ü<	ÂåŠ^úRX¿T[ÅgÝñF/yo\ky“Wb“Ë·Ú{že”Ã_¥b1‰¯ç(17•®LsT/“ks¸àýÄR–Ê8à׆h0ƒÄcsâð]€¡í"Z°p¬Ì¥`ÓTÚÕ¼��V£ˆ™×Þš¥”¾Îé;»WžÄi%(¶ØÄ5œ™,—»ì>N*�Yƒ?åïyÚóíʈfüλ�»²ɽø7ãáFWqÊZS>M…ùdT„Ǫ;£Qס3˱_‹§ÙL_¥Ÿ€(U}Üh-²CöF;5œ}ó�.T²¶/0žyÖ]±!3f\CÕ1�WR|#¯o‚Ǧ?}Fq?¯Óf�Ï ‰²¾
RŒ2Á	œðäÞ"#
-hŠÚ?åðP‘­�||èuæsSQ2¨•PbHRóŠêÐ8ꎜ¹MS^MýÜÝ´Ó›û¶ÈnØU´]IÜl(óš–ªÉô˜ÔpXò,Î%0Œ1µky„Òæ®qú§°Ä	ßÉ`hˆ	Y›½	goû[rð`jϾªN¸tÇ\®»–ü»bIBj¬÷¯Âµ^‘•H�Ý{”é·ÄÞê
-Ô
+¸'º]÷ñ@f̼ÀÜGgìdô—éËùêÛðFÔ!k£«Ã*.$|™/mßFàŽùyAO&—2Ö…Õªõ¾1Ù«<Žø+vˆý–­Dce�”­µEx`Iµ5úÐçK:™¢¦ïÝO�Ütó‡ž.erƧbÛ,H/«äíuåí™RrŠò–WW“OF3³gÃ)‡¬Då"\ßžâj��èßÓ”võVسïuÔt2C
«Æh]W*é„g̯%ä"‡È@Šr¤Bqf„�•4†Fóó<ÐP+]°¹Ng…8à„q/•ãȼ¹b–Òdù&Ê´ºdVNšùÞÕç6bÎN�é?ï…çPÒZWïn›�vÊ
-bší‘v\aۺΤ:×}¸½ø�Ú"¤#"tl~–ŠÂó5‚ws¬@ö|KéêyÏ’4%Óù|ô}É=ƒ-RK¨Ö{Öˆ“¤‹xwwa@­â©Ûæí‰ûÂŽKˆ0�oýwËŠµºÕ6©M8�³q¡ºïˆoâ³·àßYF¤i{#ØHjî˜/„†HP,9;]D»¢ôc¢bÓ*ÃzøüÆísüe¹ÔÊâ°?»ÔÎTùw}ãΗÊâÜšTÆýjy¡<w¹ï…ʼOŽ  âéMÉwï¿ÆUQ8øx¬È¬¿àñÆ3…}ð^ëaÑÄà|Ý’¯¼~¢Zw�(í
-kA,Èž¼ÃR*(^?�X5ðÙä,|í0&æ)q��¡3�5QýQ�”>1(`ãóŸ©3;çó~•�…jffl¯©È{>ë²SÕ†¬[ZÆ€ñí^m5
-îlúôü4 
}
-¸iÛ¬[
-AEÂiæ·Ü¾^Ápš¡¶²S�‹q”)ä—®}ÀÈ™’X¦‘Ñê	½ž¹I|&åYöd§œçI»Á~hÜ%i}ºZùñf�ǤXÂx,¯ðçÝÀŠÆTÀ;=ÝJi×î^‡É¦Öèz,€h?R9Ìó;@Öÿj—þY) Ƀp9:•Iß­¸ù�G«
-gwoÔЇ¼V}ŽCsg@ˆÑÕ†šÒm
^©‰iÙ;4
-ú‹�®fºÐ61^Ô˜±õƒøåiBž•1•ƒ—ÛÉŽ¸ïõ+üèªicöe	3+âòÖÛ'˜–ÍN¥ê“�7ðÉi˜ì§ï´½~2¤bêó²ãò½õþ•`×Êê¯áÞØC?¹ÕÔÌ=u¤ÛˆU¸…Í"â#øŽ\f�£N2ú
-wŸè’¡µ¸§¶”¬Õ¾Ï®HÁ=ˆÒT“³šÌ6X’>�3¡6º­1•üVŽ mjƒ3/7¯=Íôþ
&!nIy<<QDð"'É[nt”;D[sZæZÿÄŽ¥¾v™•8`±ÝÆfF—ÚsÔ|¯ï7G 9Î+
�?Iæ†]KkÛdìÓ½çÓô+(–¶ÿ5ß(äþCT°‚\ÚŸ§l±npOhÃíÜ@tþ¹�3´6PäUi·�QñGŸð*íwõÌx¿©1)mvj"§f6¦F0±ÎýèªêµÌY™i	õÞK÷òUQNÉ
g_;;C4‹±o­%bTèŠÍ†d^âFG
ÐÛk—W·>`e%aŠ{ƒ#0SÌ=²\:×Ñòz¤ØGàU%˜YM�çËá.žÜ�Ã_bÔõ~¬›Öw�ŸXöçÏ×�{7¨‡¬MÅ6ê£BÊæz‘×´‡ïÝpä÷¹QØì‡G2n2ªDö.×hE#£“	Z½¼Y‘ñ&ÐëE
\(ÃES¥cùlgK„ŽT@â91D±èc™×Àj…¤�Ði�ÞÚDÅëÁ»ÂЯ0Tµµ£bÅ$㪌íéyÑdö¸Ì
„ý�n&¢›\ ‹Hè^¶ÙôX\JÆÇH?!Ê
-F‘PÖçhé!ÍFµù„複ì‚4�ãE¢Q¢ªÈŒêË¿$Æ£}IÅD0I>àÅlPól&ÕFXÞáÅâ‹×Ž^ì÷êÑ!W‹ é·qV`ç¥Óz"!׌_j¯Ñò«E’µeä—QúŸŠGÌå«P•['ïkÈôZðÛ5%K…š�†Â¸ª¾àÛ㼿°è/©äGZ­�Ö¸µ²¤Ë›w� f§þĺ#7^•Ÿ?<Žàa¶Úñ9"	ç*‹æz]à•Öˆ·Ñôv–ý £-ÉTqÿ.åó%‚8Þkeÿ3¿[M£6ò¢@Gò‰ƒXúÞ¥çˆS&2ØŸjF[fzØ.½„ø'eCL`KI
-g.£Êù5õ\Ïc¯ªO]ffå,§m¾¼@+¬—q[¹ ,<¸¡ÎIPŸ©if8§”MIe({—Jœ~À$:­`š‘-éé;±‘¬y~�`²ŸâÑjr+Ö-±˜…>IEƒf�çl±¢ZV­®ô
ÛûUM½5
ßOÇRòˆœ�N@Èd£èF_ó³òÌu³Gö–l0êYiQ¶ˆrœÔÑeY$î9Ù
q+SÊbÁ9+²ÀYƒŒá—)mdA(Å”µˆm;ÞUÓ
ŠÊˆm-Œ/=ŠÉ?ˆ)CHÙrS¶Ô-“×ìª0Kƒk}öW­jõ‰9‡ý@F#iÍKû½D;¦$*µ±¯ˆ:vÍuš
- ¢6G4ÚWó�÷mq£Mo’¾íü0zt™žà[ΛÙóïÄ3ÕÝZsÆÈP:dVÔ/fyŨV�³Œ§²·ÞŽ%ŸðG5¤ÆA«ÀÞ«§hÏ}Kœ¤=ª4¢a3¨˜– xMPn”ªÇ#qp´ų́çxk lƒ<¶ä¥ùÁãÊ¿�aLÆòË+&ç0q�wl$^dnÜðy(ÙBÓ¶ûo‘#@¹×M±®@S#8±CjQðç}
ékŠ»*lí,¡�µ=êï�Θexí¬„¢h‹®•ëö¥°gЇ™N¬/U
tùM-w*Û¼¿<ý\ɽ~,($ۥDzÁÏ5dèrР®Êº=¸’+•"‹~tó%Ê�"â…,iãä,
-û
-àÑè.šoÏx­g6åëÚ†ÇËVDU±N…;ZÆÒ5oùOhú­—Ð>IîÌ:h^�$¼Ôlz×ÚÁÓT	@ÿ}&YƒHõEŒ(=‹qåö6õÙ¨ôW=wš’xsDs‰¼:ŒëöÊ-¶¿{´1öFi”"}±FêÃLf_ÜÅÅ;FO5æøþ|y~U¦Î ‡ëÄCš�¢Õ„’+ê´Èø–u{Ó&d¹¿*¯’E牊ô‡Mâ‰t/&%Ï©H6ÛÒ¥Š‡¬GJ×:Ìøö•¿ÒÒ•ß:–”eˆº	—ýq«É(LdOÅ"^$·u1§&j¶ÀZ¬
-Ú=;ˆðá:ØÓÏäÁÏ/én¼¡,*¢`\ÜäK}["ÊHTÆÞˆo`ÝÙýz„N¢&j¸'µ2ó‹|K×c6Qén)'	üÖœëv?.ßüê´–®PÌ£§åZ]GOŸIªvIbŒµ³ÉЄH\Ô‡óÉ}vÆé¾°å1ù{'¾ógâ݇ûmœ‡½*œ‰VákÑJÃÙ9ÿ¾�<§µÈ
i¥ßg
CL⦇X
±rX¯=Gó‹Ûìö.BÒÓ	oû~o‡´~8:_ª˜WzåHTº{‚,×d?u-ôR,ýá²ÍþcQk®‰î•üâŒ'ÄݹQì�ª¡³¾§�Æç‰g\&ÚQ„#J©Yð#Õ²á[ƒ�ËEßE(@˵¸x†üœ³/ö®:g]!$…US	](%v¨	åÑÜ팼`‰jî&^Ûœ?-ó@öùàjÙ÷<³ï�lY?XRr$Š™£-ÑTù†~ŠÇ/0‰ÌB¯7Ù×ìYSB{@&A^UEs	$DH@
-٦ϭÓ%"Òð9Ó
--ý¸Bç
hµ0ÊnnL¿ñE~„éMÇv¡“LYd< gñÕ¾ìQ±í�Å EþoÉ|Ľ„\cvê´
-Y	

É4j"¼ÒÜçÞ»6ð¯ø»(~7qBËb“½L*&=¤ö4P'©ð·@Xáѧ†÷§€R§ ÙiîÌ#k]3§&M<~èêÆŽ¬y×–=¶÷.Ö}ìh�"rr
²Ë«À±æ<³$wt•°CnEÕ@�¸*ùwN.߆Z r™LŽ:øõŒªOâTãPêŽ".!ÉMù?dð<Ÿ½h·Õð¯=B­›B]	oº×dûJèoÛ°Æ°­TFØQêP¢úC@qSÁÅùÖ÷¥7_±�¸Ôˆ²»ÞÌ3å�³_Ž¾«š’ñ #¼Ì‚�
¸~sOsÔ|ùƱ-J?§>8�_@1.æXIg5ßRic¹Rc
-endobj
-995 0 obj <<
-/Type /Font
-/Subtype /Type1
-/Encoding 1921 0 R
-/FirstChar 2
-/LastChar 151
-/Widths 1926 0 R
-/BaseFont /DHCAHC+NimbusSanL-Regu
-/FontDescriptor 993 0 R
->> endobj
-993 0 obj <<
-/Ascent 712
-/CapHeight 712
-/Descent -213
-/FontName /DHCAHC+NimbusSanL-Regu
-/ItalicAngle 0
-/StemV 85
-/XHeight 523
-/FontBBox [-174 -285 1001 953]
-/Flags 4
-/CharSet (/fi/quoteright/parenleft/parenright/comma/hyphen/period/zero/one/two/three/five/eight/nine/semicolon/A/B/C/D/F/I/L/N/O/P/R/S/T/U/Y/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/quotedblright/emdash)
-/FontFile 994 0 R
->> endobj
-1926 0 obj
-[500 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 222 333 333 0 0 278 333 278 0 556 556 556 556 0 556 0 0 556 556 0 278 0 0 0 0 0 667 667 722 722 0 611 0 0 278 0 0 556 0 722 778 667 0 722 667 611 722 0 0 0 667 0 0 0 0 0 0 222 556 556 500 556 556 278 556 556 222 222 500 222 833 556 556 556 556 333 500 278 556 500 722 500 500 500 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 333 0 0 1000 ]
-endobj
-969 0 obj <<
-/Length1 1624
-/Length2 8351
-/Length3 532
-/Length 9216      
-/Filter /FlateDecode
->>
-stream
-xÚíweT›ë¶.R´¸;A‹»Cq-î‡ H!P¼x‘Bq)-îîPZ(VÜÝݵ-íº{ï3ÖÝ¿ÎÙ¿î¸#ß;Ÿ9Ÿ©ï_˜è´t9el Ö E(ÎÉËÅ#Ð
-‚l
-°…Â
-qòØ€l1¹5 ðG—
-úhÄÃó7LÏt„ü.¿à_bó÷Øõ'rn
cE…*ìÿn·þÑÔzœ
¸ž—ðܪCmþyøÍ#+õøp
-ñ8ù„E
-â6/ÄN;0|ës2©¶òÄXˆÇ`kmH[Ǽà*õp+?ýä†5€Á#/€ˆñÚǘRóŽ¸
¯� *ÿ€9a÷æúÙ—þ¯½=�g(Ÿ6)Ù³Þa0‰{<ÁfŽ
-pÍ¢”2Ö/õ‰`”TèÄjš 3L¿àƒíá!ŠH»  �s…?VLãT‘¹Jˆ&‰g: ÉÒѧLy‰À¸Šge0å+÷&|ÂýÀê~sóTšù‡²©ttÔRmñIëëd°9:6+¶@›ÿ䧗%«ŠA~ªÎA	ý¨£±bíè0�TóYòs¢1…Ðg{Ü™ü_8X—Áx!Öy4´Ê3æmü,qÕ¡Fôž¸Uœ1”=Ê™gÊ™gÆȲüwâEÉw#A¯�òøJàú•BþS›•¤ònë®”{w‘?ßW#·TæJZ…å˜>}‡Ñ•ÁJJù‹�”ºŠÑäÊj¿¸°[f"­u¬x^Ø( HHŠ}Q¡‚ßaŽRz8Œ¶¦µ“;jÇÐ:šÈƒÏó%^�%QÓ±¬­v˜iŒ¼Æ¤|hÉÊUq”J÷¹ù»Ìã:aẖ²Åà2]½Rô¶°÷\xT;
µ7L4T3FÁ°.ÌkÛ4ä»Ïuä‰qÑÅÓÅŠ ›c´ã¨�ˆ“Ÿ¾Ú:‰Á˃NG!òç»EŽfµ4ƒvZi•M–Þc’þÆXÓ"Ã-­íêÆáP‡³ÕÌ$’_?Nˆyéå…ÓÕ½mÞ+à„_½‘sãÙ’I%pazÏl›€ÿ¶uçU«
�·\Û×Ðbjêìb>U¸)}{QŸNßà—¨ªw%=Ák±ä�fZ%Åêos[1øÉ]·êñZ¬w¹­fsƒ\û¾cx‰¾¾‰ŽµMÌ(}–"Ú\ñ|1wNkõTƒh,.Wèçh7)m|°Íü'gˆ5’S¯ŠJ2ÇM<'s�Ö+±UÇR·¬§ëÁµ&I"AkËðÖíƒÜ�c»Êþª'ºø®¾bÒ^XÛÒV¶ãž‹c&jžüõ«{Aî.5ûÛd
-Ž{âA‚ݧL3bü
J?ÙnÁ›C#ŒGÖ:ÂûSÅŸ†¸XJ½·5^9%4•Õó’‚Ò¨î_Zúäu¼AÁ�Ü݇€,23sËÛZÉzÎgIÞf­35TìQ›Ã_
?Ôn¹)-ödÙ­¤!á-æÔ‡$J›½Àzö‚õ˜»‹Š)Nü‹:¸¶’{ý[}ð|ͯÍ*Úe™à€\‡v,­�:j±ªÖÙH’R<[ݧ¹}I¡ÊíÐRò
´hst4ý¯3¥{Þë—àe¶A¥ÆÈ)f!ÁîÎÈW
n];FuéÅTK&|Õ‹æ¾\c…GîàèE9#½‘lý¤z‡X,¾t8íèëàvO¿šåj›@’ò»²·1Z1–ÈÈWc7Ü^q7÷õÛHm®#Í4š‹9.<�qÆ–7]Ï>é"घ»Ž;ʆW=™PNïÞmMj§%·™Gô(àØ/õ�]-÷'?E4œ¥ºŸê��ЗBáNI�V}f…×–Ÿý•‰ÓBýó®aˈ
-ÝìËI–Ø+¥®kª+…k{p¶MÍÍ$]Lj&”?M(ìzŽh¾ÏöÄÝá�6è g*⪈}Æôš.lÄÕÉ^wïkæXÏ7eKxvù»‡ù5QÁ°Ç•Ê.ܥ˯ŒZKòQóÂsÅhã˜\«l>[êßÝ“Ñ"bÇ
-idguÊ ÛáÜ‚Ñ9¤ëË‘'jM.~×ÿfêKÃÔŸ’ SêkÉ'ë,Fèø.JìíÜÎXѶ%Ænvâš’¤¼ò\¤ëVù¹r>guΆɩ,hè‡ÓbѤÏ_9¶¯Ë`ÔT•#ÅW}gƒ|³f<×­ð8²ÿ5È âõm`cÚ—}çêã[ÿoöþ-ΣÆgLÊôµF&Žzê_Ùºœ['Xæ tqu“G.¢/­bŸºâi$g¿Ð ÿ
-#ÄÎÝSDº“l
¹ügTù®„B'æ|pÙž2SXÁÖ=‹ç~õÎK–DÛ+Ïk¢·­ÀICÇCÜ0SApðäcZ:³ísž÷½Z÷•âKíÀDÙl”osúòÖ'+˜EŒ;�úØÏb]RN;-¿Œº(·]({5ׄX’³øö÷ô~™Ÿ=ÇŒpy¾7�rB>Ý#ÛÁr{Yƒ©3ßrƒlšê¼õ~±Y¬Ø)Õ`qyûT±ŸIJ\^Òº2¶5ù¶…Œ�¨ÆÙ½C+âa¹ÜmyüÊ€=YÙGzm’ÕŸ>ÖÃI)ª~•¢•¾·wZ䥗Q�yyŒRÂf�ff8û“‚
-¸ÜÏ„e) ªÔ5‡Ðz}Í=1¶à‡v‰ÓG<˜'}îpÂ/òʨ^ärÁÍ)¤ƒÇ¼V²YYÍsSsôaÛA ŽPWôÔ/U®øGÎ8G”„X×ö¥ïôgd” ŸŸËÀ¿ÚrsŸc¡W8DN0|’t&sõ™9©~ }Y%ÛZˆÝñ4Ã@hÁwKÇÊ0º7ñ¤‡>–"OhIåà"5àÊtþ]ÛŸe»ÝÁ†UyåÞå¼ë\_¹j†œO"	o‰¾é~iŒµb�âÔwyu«�•¾Ö:
-ÓEWº?Kûß“IœñáÕtÍ{�Be-ë	
Uu£tië9ÙVåøë_onw®YH°íy‚Þ|˯©KâÉ'zÙuLÔ‚™I…¾?Cfà.mQn%¥Ÿ•I\zQ[°³D]Yí7öT¬$&+ázªŠÜ^„§P•àÇ´ômÖSXS„α¿çd±³Á¡Y>RêÑ™½²†ò…*Ÿ~ûzr”4�6:bŒ*Ç´H]ÅúÉêXË—P/f	Îëîw¸ÑV%.Ð-HÙ¤œùÍØÁ°�ù¦µŸÏ™¿Ï³Ú/€V>ÖG—ç™~]I§ÐRúå”ù5ÝÙo<…zÅ•—Ã!rÀÜC)4ÜKÿªdÞÌ5YG¨Ò!ŠU�a	dV¦Ä`ȆՃ¶å|þFĹšÆ�#\XZ­•c…–exÍØ⻫‹
-ðŠâÅI´ÁAM8îe¹åÌ4+Ÿ`,NÍ|
-‘†“u
-jT­C©i–Tu#s¥§Ú'¨jzÇ¢’‡‘]ž>û	�Ó›ã�é4�ý}AB1ö‰pvs!œÀZý¶Ù0¸øÖ5=YÙ‘Õ®¨=×`«²Š©«åU:�¯
-$¨éå,3£¨{Q¾Qê�5¨§6µh¸‰Üüß<ü‡ŸP1[½;džF�oU—%÷UÒÞ�,²Éš5Vo1
-=JƒË¬À<2Í¢îÿ¸£»|µºÂmïÝa²‡kv¼@ˆw÷ÎÖý¢AŸyÆ«ïÌ�vÒDYœ32²
-©òc¦Y+«Æ€�§Qùsýò:ŽrM£ÅÈ*iÀ· Kö �î0ÐÇkø�Ä<æçó|;€^QÞâÝ@�öE<YÍ4Ë.8XÉË@¶ÞIǽL» ïk[¯irWÏE/f؇jÈ)Rà�Xý¯œvb~ƒ�ŸCL?;Yt^8+¾ç/*7í2êì)É=fIï#!½öôžcháîÌÃ{ØV°#ré\šùˆ58»ƒ¬«1Éz—xÝ…È®ÊÖ¡@Ñüâ—¿GÈvÄ­ð*†b>�
-ăڙ~»À?(Ç«Ì_aè3µœÌÀq•Ò·'ZÍMÈòqZ£¹§ËSÅv8à‚¼Ô
[=Ä2
MV*ÇE¸ì¬Ömpx†“‘ò°Œ¢Ç¸
+4a¯ã§À!¾Â2J	’¯Ôc2Ä»îú£	GЙÓØQö(„ªž0ôéÊ ÕZÅÅ`¹‰ÞÍ>QqÜY·TÓlFrÙ9Ä>‚$s™|
-cúÝå�99¯ vµI÷ðJÐ?½›ÉÇÎlâ—2ãÁ¯Ú÷ýŒ€%Í4ïÚ�]zôMy\U¯_éCùÅ‘Oað�áׯ™Im>�jzX <Pû0[:?Ñú"§¤ùñ’¤\H)Ìn®ö£d©ü��N_ºmíDÕã?³íÙÑÎ*–=ï;Ü�RO†vhÁnOxŸŒ={ƒ³{oà¢
;ËùNÅZϧ&ˆœ–#)¶[>P’·ž¿Á©Øô©:Ïûô.)¿¨h^iyˆpdÎ<öL#ÑÆ¥{¨Òܺ¾E¨ózÛ'¦îIÐÔñ`Ï�õ®±G‘
-F¸lqF÷wã!
ïlgVc8Agbf–FLD¿¦x9Š|s ý5þ�i.ñ½5ò.–so–¾¨ìû4§e5<eÑ”7t>CÚ±CŠH›zrŒøòx³÷ÛÅ»+Vˆ-j¼pÎén
J™m–›Ñ�s°pЭ@úEƒsFÚ-V^@6êI]§gIëEJ‚J[eƒÏ%K\ñ¸\%kÕבÊ}½Ï±ª·—´Æs‡2ßwýÕk“Òhý€×U%'ˆW(“ûh?œGØâˆÏlíä7+#ÐÖO'›Þÿ²ºéúÅç78' K*ûTâàÃF\Úÿq$qƒqê¦tMŠ+éM4Îâ§7·!…
û9B²cr˜xÔ©*ÑEö�¬!ü¯¹Š	G_á¹É³Ìkñ¹ïEãA	GþHŸ#ÑÙfÓT¼äû<û˜}!gÆÁ¥�¬…X
Wϲlq*¿ˆé©°MWfüp]ýÕST”i;Çéyù>.¯Gxf�œÕÛ[$«LTmç¨m–fîîe¬¢¦§P*†tÑ5[=ÑTQ3<“)uk¥}²ùbâŽ4¯w
-E,˜µ´´&¾Þ6º„¢ï¨Í$¹°Á�Ü<ÊÅ|˜oÏLŽ8ßx'%ì-ià_~±úáÚuY߉•ü]��<ócÉÞ„Ä�:g}ä­A™l=iÜ’Ù›Añþèuúéצ<Û­O˜àmæ5 ÜT…ò‘êÕkjÕ‹IG	¦X%
-úú\¶qŸt§D	Љ64>–_Ú�Òâ[Nlòí3«KRÁp²–Âb]ÌJ—^»6m4×Ë'rÕÏ"d^D�›y!!o<¥fN�¸È%�PZQ¯÷nœ•7Je( æ%.ÜÆÐFœ—Q� 	Ú›v¢î*ï&Q�_Ç1éÇ»OµMí÷S]Ðê—âO
-,öŠú"Erq‰3×{1NÛZ2ú

©ôeeE?qx
-‡N$ÝE¾ã!Nz(Ý}Xn×ü½aב´˜S€¯q=!ÆUwŽÛ-ÁWá‚}Ø\dæ”�Qf¨ÛÁsZY THƒ-´/â«Î-k×ÖôïÒÉRZ¤™2ûx°.��[ÿªt8HÕ«XE¥2‡U-äbO¶’g×Vs�£I5üŒõ¤JÒ´Ù¼ëâ#LAôfvñͳýn™ÖM6H·Þî�,ÙŒšípŸBIN"±Š…:2 íÀlÇV=+èw9fš ÷˜±ÁÕ"ÙÛ½�ìøù<´ÓÇ™R]Y4B²,LˆéIL׶—=™ùôÜ3BÍ]²'ÿÔ¨ ’]döŽ
-ÝݦDJ)ÙŒáÉ¡fl°«Sa¬c€²cý×Øh}ë
–7‘:©„ÑÅeƒ+"Ï	^Œæ?õl^}âï.<œEÖöþÒë’QzM‚iDÓÂÂLTª¬õºÒk=mùP©ú'·UŒ´/€›0òû
-ä–“Tf0kˆ¯¨éÞ6¡"¸FÂéq$îDY7Ê�ôµíª‡æ¢_Ä+ùXDLI¨#%ò8ß[
”:¨ËA|�’z,¯
-ø¿BówÚ]ŒßxÅ®ªÙÒš›
-r
ÒÛdê9ñb÷Cæ½óG„á·|9]°Qˆí3ˆ¥8ö•'|2
jK¢´”6¾Y¦·ü–ū؆Mì{"¶¶¤~lú…W²ÌÅ£¥ZI¼ýÇCLTb¼Ø¨�ñÉ®-üGOdfEæ—ôk'Ì,³q½Š°ÊšBa›=As_|û¢Õå|šEñ	¦Ùá`uͶ‰:ïp0nÚ”Û+•¥`¯|,_
-Q^	±ëkB˶ÉÝÏW)´XI6°,}¥¬>Ñ­
-ff|óéæîDÈ[(-’°1MXü’µÌǨæ¹Ð1½æÄCÍ`SN¡‡ÒÅ�»ïaÏB±³7,PÄ�_ˆ•Žp�²Ï‰çó×CG®t¹=6Jøwº�‡P×±f×öËÌŸ õò–ÙÍ�·¿)—UôÑþN¶Õ2¤C.®;—ÿÔvcƒ‹&çî¼Ð›íø¡¢ ?’!sÛ	yvØ·�ïœÒÎkYiÌç
hbÏ0¾IDê.¶Y_^¤+<@<«Nk¿±eopô³…+¥ºêhC‹0�Hó³�c�ŒÆÜHf
Õ»uÎTÉ"[1ò™8ÍQ áMBšHiô*ó]ƽ¨Y©ipá8i­Þñó°žÇª<FßèÍNa¼�°ã¹Q[£ðbd
Yfwp“—µ©Â·{äBŽT.‡)çN¨5# Ü\8£
¦oåc—j9^ÐbYHËoùIà3Ò"¾œ½OÒU›7œëí
Ú£xÖ°´ =|MÆË•’ë�é÷\Êã®›½›ÊLs(iï*{–2w}À ‚Sq¤”œz¬4XBc°ˆ/­ù
šNߧ}‹ÆO"¼¸ò^µ¯Å•m¹•÷h„‰rd,ŒÛà½ûJtF ˆÛÑ�W¤\ʯ¡q—�9-1;Š’‡Vû·U¢“Äç

-	a¤)•Y°žeDÿ­ö‡Ú—«~‰ÕofØB8ûzIÅ‹‹—�ç"ç6ZŠõæï?|ÙÊËûêÞVÓjˆóý ª¾$ù…è¾™A_%ãè
-½=7c…ÙG¬èÎ35µmªâÊÉmqZ†\B‘[›¸46ÊÎõÉé1‹äp#T‹ÀY̼†Ü¼²µ8c1@Ìõb$ýZÃ>ËA‡ýÿ Z*9/‹[ qM%ÛZîÔ3Ÿ"Å÷OÙýklT¢HFk�mºYüéA3—¾OpkÄ·\;±©ô‰ãìµêOX.š²ÃÙZ|©9K>�ø��
-[L-‘×_ÎlrÉÁ~Õ?·åSç& ‰Å¬}+ž¾†¸WfÊ5na­¸À®ª|êkS=öê[¢8ˆžºÐ(ú°Oæ*ÔØ…ª\LêÊ°_PÄê:‚܆Ÿ0
-o¶d©W<DÐ?§|)"¶úšzœ8…û>r‘ÓÕ$EŠÚÜÍyÆokjÄÀ”*€Ò¤'ñË']Çåú®8šŸªBžß%[Ž1FôõU~zË7†Ÿ¿Ñ&¤”D·=.Eå°¹úiˆH×
|v`—þ/õ«”WÕw°õ‚I ¾ª@+a®ó(©±ãA5¡=y=£­ñxç>USåD»<çÆÍMU�Ô›€ÙlE—û†wRŽ{ÞÉíkGo-îçDq±¯R®¾…ù ¤í€‹p¼ìoB:04B»Ëß
*pº¤¯O*=¾oFäÉ°�ïCÀIüŠkú$ÛÆ�ò
wLv'
-�OêX¡gŠÛm9#Êó2Ôq
-ÓRLvÏÍŒÆ/Ï7Xy!r8Ë!MÔ4ócKv&½›Ä4á”UO-EyÂTóT­âÑÕì}3Þ5ªV¡H·>”œ³"M*�œjnøÏ3°ï|Ú÷×’4²�{óÝéL¬!àW”¬Pfœ«ÙýFGó¼Õ‰}j™jì»�“íRÜAñÓ5Ý«rà)vw º'-¢ßGrËpnvÙ1AÛõ ·ºó\<užèÃbð‡ÖhQ�jÄcñž­Š:DqŽz,|¸>1sNñ&b®]?Mr)smWÅ€Ñûä
ÌuQØÉ
-�aàùÚîjäßÜš¨SÞ‚{ÈTvø…ùî)x“›”Vˆc†šçùÁüÿÿO
-æˆù_Â:ÐEendstream
-endobj
-970 0 obj <<
-/Type /Font
-/Subtype /Type1
-/Encoding 1921 0 R
-/FirstChar 35
-/LastChar 122
-/Widths 1927 0 R
-/BaseFont /NZFEJI+NimbusMonL-BoldObli
-/FontDescriptor 968 0 R
->> endobj
-968 0 obj <<
-/Ascent 624
-/CapHeight 552
-/Descent -126
-/FontName /NZFEJI+NimbusMonL-BoldObli
-/ItalicAngle -12
-/StemV 103
-/XHeight 439
-/FontBBox [-61 -278 840 871]
-/Flags 4
-/CharSet (/numbersign/hyphen/period/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/r/s/t/u/v/w/y/z)
-/FontFile 969 0 R
->> endobj
-1927 0 obj
-[600 0 0 0 0 0 0 0 0 0 600 600 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 0 600 600 600 600 600 600 0 600 600 ]
-endobj
-961 0 obj <<
-/Length1 1630
-/Length2 10420
-/Length3 532
-/Length 11286     
-/Filter /FlateDecode
->>
-stream
-xÚíteTœí’-î\›à.ÁÝÜ]h ‘Æww—à.!$@ð Á=¸[p· Á!—|ßœ9³Î�_3ç×]·×z{½Oíª]UÏ®·è¨Õ4Ù$-ÍArŽ(;§@ì`îæªìQbÓ
-rrq|ñpxÁ^ÈÔ]¡®.`'(à%«šŒÜßuBm€Ð?¹]Á/0ÀÑêÅÓÒÑÂíOKa/4/(†¸  OèŸ\æ €%ØÕÉèõ’û…ÌÉüWn®`ˆõ?+`¸€¬�.–ö Wךî?·óÏ>
ÿ¥{ ““½×_ÑŽyýg
`¨+ÈÞŠ�‹û%§ô%·5‚ÆñgXä!VŽ
-:€í½þ›ÀuÔý]ìðý+,¾\Š$ÄúE6.nvοÍ`W9°'ÈR
µ°
X
í_îì/»6Ääb†€^´ýëZ_‚89ÿÓ²
[ØAþˆÀû7‚Xþkù/rýU<‡¦–š†”Ë·aÿòT{™¨–—ðit•-ÿóð‡GJÊÑàÃÆÇ`ã~Ãàçç
pqùý7ÿ¢áúçYu
{9Ù99¹
-Ì;ƒ�„öé ÓBr?¦®"ÜUúV~–�`“rÌÌ#ÝXŸ³¥5>N���ïê&e�Hc­o\PÎn˜iÜ‹ñi¯�°ü-Þ×&´áÔÃàÕѧìß\3ô
ô÷uœ#vm“±ä% Ò	»#`ÒÇ:瑉hWúD±lÁ}Ù¡ŠïJÎçâY�ÊÝ¥…ŽeÌ|,PwÐÖºàóoËóÍQä‡/Kk×ØC)3ù•kKКM,y]íÝ»IWàCn‹ÿ³ÑžŸEbg¬BY¶â	EœÞïýoÕÍ%¢_¹
p¿ž²Ÿ¬?BûZ·bŒ“ˆ·d*RˆÈÕÝÆø÷@÷¯¾òðgŸoÒÙÌ2ô!í¤Øô‡~‰±ùÁpÕ}ØK³ç¸ûC׫F%=ʾü+Þxè7§Á½€Ö
-µå7„ùŸ{D/kÅ:NŠº3©1fæÁª®ÖÌ>›ˆ0œÊ-~ýdžR¨X<™6Ú4’ÑzVÆ�„öO”ðµaÕ=åƒd!?Õ–¦.OB)»OÞ8
:eõ4 ±ÎÌYÉzM—I[Øù\ó‰i·Ó¯‡‚¶j×ÍX�‰õ­æ�áBJ÷[ØE¾RS×ß½c&È1Om+bi¬NÈŸ
-"¿¹V6Õ›dJ VOÆýräªÕpê9�£åLV±Bï÷Õ&JÀà»<ëÈdRs΄5Ãc6âš<ZˆÚ½–‘õxc~Œð
-7kXp-ºZc¤ë·8*Ÿ�Ѷ•â–Ÿ÷µÓ÷“hØ4WžL^ñ¶AÞež
"<ÍyÅgWõxÅÇõo)l)ºÍ¨øß*—–£ÉÌ™üÑõ�Ê”ÒtM
-Y4<z€¶TÙ±š�m·àÇ™y„>þ=ó×½Ó#|õ‰2Ìu÷Ñà	7$tD;³Ì/>ä…¦+²Ø˜±%œýD@X;…�1OžK(„ØfAH̦Ê"m…
`²­èF5óRX¯.èÝÀ1_|qãŸ2
-òâ¸ÚqÍ\ó°aTúËî3ìlŸBØ0UmËç:<¢Lµp.«ŒHa>7÷ ¡$é
$aLŽW*æ—ôZÇÝ�ඔ‚ª�Öß.«UŸHeYê¦äñ4’5¡ö|Ž¥�òïm´ÑË­çŠß“Trו?äÖÏä‹wJf�–h÷3»7P¸bF»`œ/[ŸLÏ�>¿¦td#ø5‡ÍPÝ®gÊ|Ô«ÕCY�…#4WÚ*€¿0Z^oÖ,�F±ãƒiôŽ¬÷“Ön4
‘EMI;h!ŸQ5r²©äÂÏ †uVrŒyq ò…f~I�ØA¼þ8«+ö}¤&ØõÃu"ažyº-¡Íß*�Ã
ɹü#Líj)¸|›t¿Wu‹ü4°s!MRmYŒ5 0ÉWýŽƒýÝGiÅGÝD¥å²VŽ>5ºöæw&‚ß3F\Ü~'²Ý»µIËO™ù™õ�¯âÑG÷4•ÌËX¥+© ¬ŠD¾I_åhkˆÀ/ÀŠr2ûHïíæ÷¹Õè9D¾ÏÔK1Íœõ.ÂÖf:¥©_ˆú™4LT™M7(¥o3iså—ò»ºö½_ÚC'¿{drmcN~µG§;ÝÚq´	ÓCLs:l
‚DFLS¤ÁrÚ'»H<uw0¥ÞHÞúµ�ȘlN–D˜•’Æ·+¿Éþ7Tš2|ß=›OG~vu1b4ršTªgŒÌœÊ²ŸŠÀ_|Ž‹lÕ‡—0ûº“8_VÏ»×ö“ý#ò°R—¢“Ë-{z—ú{±Šöý‡�9¦/Ú‹]¨mȨõÖ?2T8¯f
5°Ï9[X©Ûß>íÚG�tH”ÁòaÀÉ©ZʼÎ÷h96åË—¤õÆ3ψ%6Ë�px�¢OÚe.OSåÐœ©<³Œ)˾F‹´®7}Ë”#)_Z¥¢Ê
-7ÂÃD
R	‚¿è±¡~HYÑ+RÝ,=Ä-*Òÿ‚´-°?MVC˜$™œiĵ5˜Ãù–…Z¶a8W‘OYE«Pj5úïNhŸüˆ×K�ÈÜœƒ[—ÝËŒ�ÇÓ]ûʲj
-eÕÔ×Ì:8}L¸Õ÷aÈN˜üŠûÔªÌéjb¾ú©;¯·»ñÐA¨1ÆE“¦{øc”’³l
-¶§£âŠîZ<3ýrãrö, ˜ú¡ü´sÛ£¦üÇçt
™-’,ÊÁš2šv^I4{|ãfg£!Æ-’ßÏ
-l	,vßgª[™GV©SÓÄu rbðW„_±}\7Œ]KöÜÏŸŸ=8RÄC&)Ãù13S³à™ÜˆzÖó&Ü{Òâ®;›{ºw/L=®¹>Î�i%Â+06wIœ¢¸/óÆ1qx≓–^½Û‚ŸVæø
aF©kH£ ¸p”6œB¨EAb¶¼4�ƒ"Ògå#ß–ß]ßÙ¬’ÛžâÀÓÇQ´ÝKçãëA”œ˜jô¾ð‚p?Ѓú'[yõ|#—Qb9rȾÃFNw®Å^™Ý~¹6”Ô™ÓEŠïá�bä߬í#Áæ#ÚWŒ¯*È
•:ëè$4×hÔË×öÂnD¹ïÜšÇS×¢FD¸}¸ÐXë�Ï�I¢U1Øθ3o8ú8J)u£e<Ô…Þóh|¬"=–gfíÎ1`[u˜ÅQAØÇyïóÎp%oZ
’øqa’…aÜýËC5¿‘ˆó^ÐŒ�
-ûôÐÓ]2Žá×ðÂŽk•|½Ç7�X>ëŸ�¾·Ù(´Í¾o÷ŸÔÌJmˆ•oXGUç²7w&¿#
-)FkcøÖ¥Ó‰]Í¥D¢ØM�Ðò÷*Óç”t…f�¼™�¡øÜÏÛÏF�f�ðz•¬ŒÊ�2�Î`®&qTYOý“ê9JÇÎNy…ï´Ûöpì¯lbúÐ8
Á©æf*°©Ç	6Äê••í-Î
�¡€Ñ„š_`-{F”šZ…ü‡
LAîP«Ç. :öIæñhž;³»)ÓZ\ÿ/FÉH£}QôùLÊÏ+w5]D0|ƒÆ&ÄWŽ^„IU5lª	rôÒ>0„“•¶}
-ê(O“ùRtS63ZÞ0CFv߲ͳZ
-|C·r®ÿµ?Øô¼©F¨$	@¯ÍrjB/áH
$�=@"¿ƒ£
-€�ñLœ #Ž|DøÓú$LP÷f(.€RC¿7é@
-ÿ³±Ž“ˆ¸*„e³VtØø®Ï`Áz)£`j|S’»§²×¨?È4·¼-ó5W¾”8˜‰¨WÑ÷ÒhòµÈ~à&JY�È)
0­ê¶D©:Ç4Á¬Ãšž“<Á$ ŽFô!uæýÔK~Smò¡z­2
;zëJŠfÕiu°„j–ó¼ÍÏ�}ÃGL0tW’e³Þ‚å»0\èœCå™xà¶}½©âV<=Xey
s¯”òLV²º3#†–¡ØNs‡Nɶ¢»H*åÀ›õ³?ò
-/RBùðMÍÚËW?Fóm6¡Iyþ%ÓYµšÕ¥oÅ{;sË2¯�Ó†{®G ‹LãžRê
��ú AƒíI+23—(-ãAqpå—Zâãö¥‰u#̸{OÿÌ€;Snú�äë)ªj¶§×o°O'Iª™›ßá蜼“Ñ;ö~Yå�	¦<úhDsÙ˜´\ÎCldS \“2ñœIsd„­|ü0"eq’×dÛÑ
-ÉÈصM"-!J$Th ¸þ`1/ù†ñ\âîô­ÜTQ‡ÐŒÈ[ÖNåÝW…ˆãíñò	Φ·9íïCÆ?öaô|ºé´Ó2gz µÚ|펋0T§ÃL�Òº2ÖËàÃÍÄEßþ:–@A,™Š`k­ûúm«§”G6Š+Š9gÃÀº‚r~I÷�Où­è·DÊ¢[{­‚¯´rÁ\CPÉ#†|m\¶}äh;¢µ…ÿ´fB­Ã0=­7ÍRô‡/œÀÐÀÝÔk¢1fR´^¤ÛºÙCñ®Çäß>0c(¤‚e(Ö.×ÈîJêùô
-Q9!™¨‘™y0‹½zÞ½iº˜^Ì	/D—Ó|e�æèù>JB»!|A¿,S`&ǽï.÷L5�ü±ï÷÷ˆCXæç
ÞŽ¬
å©aÜó‡Û
/}WRèŠ"µ±gÚѾ­ø�ÿ;.¾‹œ2Q‹)3–+À#'[¼„ì×jéXÜö¤ê
áEIkÀò YBUµ<ÀòÝÉÛ‹QË¢Ÿ¹Ù¨ƒ-*
-HŠ‰³ÝÒ¶X´2l‰ÀëRC/ýÕwÆY@}!ù~ƒvÖ³K®×YËE.®\ØÍ,Å»ÕB
j>š…¢«îlô~â†õàØü-³er@ÜYŒÖäž��îj«ýT"ŠÒãÛ¨×KÜð%ì_í[~«¶¬ƒxRåøž&'q.kýØ®ƒ”ÞÑ‘ccšÀs1\ÖEÔõŠbº<&zò¹d£}‘l—¾¢@ ¢¯uR$î-±ÌM
-ñ,(ZÃ
�…G!½½,‹8yKæ;~ã)_Çzá8´‹öÑÊXÐ/â&_5º(Ƀ|s5š)ˆÒá+>úÏ°c²±
lj×ú²ˆ%¯ñQ
eÃü²†‚w¾ÙÁÜUú7|Þ–ýö‹ç4Ï‘³·¾hB²’Œh'à¨]NåD¡·�T±TÎ$nñõ½Cm¼:1
S’•ÄéEÔ¨“¯Q/nHb�ç A(¯öÌ'rÀ/V±¼.p:F‹	Ö“»aûÏÕwïl0yß]Žˆ”.z2“ÖŸ~ÝÊü”— ³z^¢ä&Ÿ›ÚÕ_BXÌ].ùÞ,y4DñÓY=õN[“ou1~KM“éýeülÝQЃ$¾®QJÖ\â3¢¼ÛÚ7²_ÞU2æ°(²89j¢è‘X(ÍàRêôâ
-ïÝåJÂYsD,~ ‹�j%ûÏ.Ÿ(gªbç7ú[(�
[7™>"Ä«1íKIkJ°rÚ(t~¨,{|�†�xáï�Ò…CWá�
§­›ƒpK¾}AµþÖoX4šÝØœÙ5�)köa³Š
Göf�eÌƦ¦»#%ÝÅM'zŠX³¸·®ËÂV‹ïÞ,]0.Ù�ìëî9¡ß‡'¼Ó+}ÅNw§s»çoXçð:
¥r•Çu’Ÿ¨óUºÊ‡˜Bsûî�sŽ1ðô]¸ÑÊágE>èé6±:ËÖªbCÀÙ‘Pý\rËÿñfóªÙL[1Ë@í×õˆL
-Æý¾> X¿ ãŒ0ÛÙêpµ~è~ñnrÆÀ�f·*zW–Wµ8ÁˆåX�“7`i
vXìq|¹*ÚÓÝ;É}…ºÛKå×B@ÅSCÂHØ�jIúœº3NøÎOm‡êuHÎ&¯õHì{�ÃN�Iv-%ó2þb*BÁÁˆµ.Ú¿�ÉË(-0ÆÃ.™
�bÉJßÒú×קínjiF^Aƒ½x”®8¤á-	…Ž!�
`ܯ¥	LÑËëû.íS@&Ÿ$ 1~G„¡é!nó[‡:sHæÏÄzŠê÷ ÜP�ÒõöoaÇ�"Û£]¡{;XÎ	Fb
úzÛçŽw¯ëö
-v{Â~[ Y퉷kë[ÊF.Ëë®R2:|µ&˶ù&~t±³íšá–kAYÆ-Ò’Qíç^Ü—³AÆPR˜R†ŸAÅ%®’+Âã9ÔR´¹«{ Ó’!ŒUW2i÷ø¹ó›
oO7BÁ._«¬ëyŠ
D(aá]k~®u–	®
Ý‘»ÌF%ïýÐ×�ÙÐdf»qÅ£ˆ=#ã j)Š¸)…ào}Ú|(¤»ó$5÷)ê:×eÝ–\KÒ|ý`S';ZU©Ü
-Ÿü._¯	7#° ôcö›ÐB¥×¢fÜÈ=�°ŽÏÚÜÙê?½z��êý0íCÊ‘!´æûtÍç«1žu?K+.®o–/þRi†-zSÇ6ÊüdrhŽtFš(eL³‚/umDðN”Vï}º3,RÖŽXí;
m?´oZ92íã“Á‚?†}æ]*ý|ðÊI¡¯W•’­Ké6¤,È5ßsx˜ ™ßV$$öøu"ÛºîŒw£¸Ô
-endobj
-962 0 obj <<
-/Type /Font
-/Subtype /Type1
-/Encoding 1921 0 R
-/FirstChar 34
-/LastChar 122
-/Widths 1928 0 R
-/BaseFont /STPRBR+NimbusMonL-ReguObli
-/FontDescriptor 960 0 R
->> endobj
-960 0 obj <<
-/Ascent 625
-/CapHeight 557
-/Descent -147
-/FontName /STPRBR+NimbusMonL-ReguObli
-/ItalicAngle -12
-/StemV 43
-/XHeight 426
-/FontBBox [-61 -237 774 811]
-/Flags 4
-/CharSet (/quotedbl/numbersign/parenleft/parenright/plus/hyphen/period/colon/B/C/D/F/N/O/R/T/bracketleft/bracketright/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z)
-/FontFile 961 0 R
->> endobj
-1928 0 obj
-[600 600 0 0 0 0 600 600 0 600 0 600 600 0 0 0 0 0 0 0 0 0 0 0 600 0 0 0 0 0 0 0 600 600 600 0 600 0 0 0 0 0 0 0 600 600 0 0 600 0 600 0 0 0 0 0 0 600 0 600 0 0 0 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 ]
-endobj
-884 0 obj <<
-/Length1 1606
-/Length2 16237
-/Length3 532
-/Length 17113     
-/Filter /FlateDecode
->>
-stream
-xÚ¬¶ct§_Ó%œ¤cÛøŶmÛ¶mÛ¶�Ží¤£N:¶mÛvòöÿ¾gæ™u¿óiæùp­u�ª:»vÕ®sÖ!%TP¦4±72³·s¡e¤càÈYÚ¹:ËÚÛÉÐ
-ÙÛ˜
-"bÿæébaèòOngË¿n€½ÙßH{c×Jú—ï/Ì_¯‹¡¥�3ÀÅÔÃåŸ\F¦
-IŒ‡1†
-	í:Œ}V
-T§:jâV6ðë>z1ZVª=à
šì™ÓvÓFÑÐ54½ú!§�¶å9A6P0ð®+MG¼bê¢Y‘ßçGa�ƒæ¶ËV­c3çY?â!_¸Ù
þZk
-ÍdÖC÷Á1Ðò“#MH}:²ad†ßêÆ“5½F•çJgbqà&§¾ù4ãèØHûù”ƒyÆ<˜^ÙÎ/ÓnÉçË,³t?P“©†œê!(‡n'¼|HøúøÁ“fQ"Žë3ã²ø½6<‚QÇ?#^vyì„Q!³P¶9aíˆPJM”–Õý´ø5mœ
-�ÄGìÏÌOÍ!ö®p¥æh-	
Ìp	d‘ÕÌê0Å‘N\dǬþsÐòa[” ##ŽW”å$�‘ŒªàãFAžiXã»â�Ï4ÃÂÕüàm÷àÚ(3Ÿ)qŒ_0\¨�pZ
#rûº\ÊF/�¿«·¹Wë08÷nQ±¬,RjU‡"vÈ—7ùB7ôy¯GJfô[ˆì¥/·“ÂC
-†ØŒÌHÜ—�`¢o(8äÉJàÕª££ðèÚ>¡YÒ{§žæ¾òfƒ†/’€môú¤»AËý`˜
-q;w¾æûD"'š0@=÷a#èQÏ÷ç«î³¿k^G6ÊP ó'9TʤŽ!è§ËéסT;éîŠjè¦~C
OÃúHm~Ë.!H!§[8=f÷‹âƒ|ÝtÛ²��È€ú!"L7wðÍV¦Jq˜œT#pÊw„áËàçýÚ@ZRÏÇ&—~¿w
-
bÛŸ=ÆMF"PÆ�‹C×™‰X1±
-AUä]<·õ—™ñÉ*1EQðÎ!A&åÔ@x*aÛ 99¬®
-
8"T¾ «¥Ìˬx"-Ô¦[ð=@%ê⨹µAÇ!øÑ=wàûàÄÔ‹î3ížl4íõ¾s3&ê�š)\l^ÒÌÄšÍQõlëŒoúÞƒ´m9EMé`:Áóñ8ÕÇ7d@8‚f¸Òá`
-ì�Ÿ–
-Z€«¬_Žˆ9¶Nž9l Ú:Î\zäÏYÑ�Ž>}8êÕ:¬ÆJywkPÃíñÖ¸ÛJt�Çlɬº‘;H•"@ë]P•½ƒ¼+æ%0)¨–úKÎ3á¯>KAÍHjú…L’Ÿ[ŸÞKI-?<š	ØQAŸ@éÛ™
-be2d5ÚÜÃ%Ìœ�&Ø9«a7\Ô¦ï†F#Â#ÂìÑò#f¸E庲¨NÈ<ê¤yÈ(¢õ
œjŸZ^á&#Ø
-•¤§q^Ñ+�!d®g¬~3ûužíNO=³“Øý.�E²ª%UâÊ1Ô¬}+lF†�b
~ö°�®–V¥Þ;ç£]£ÕKï o-K�‡_JO«×<G«ºøõªA%ÉÙx¥³ºVšÈÀöáÅoˆ{YæTA”…Áø"ý5TŸnH®om"ˆ–Œ-Ç:Æ#Wj¥G]§îHJ,¨Å14Ü×X2j®éP„
ðÐ0t–›G'3¥PšS/—]†"ÃdC·2|¼ÛC»ú˜8¥ŒêKÂ&ØHHU„.×I²ä’ùZAøý9‘ÍP&FÞù˜•Ü+Œz-«Žèc¬Vd½xP!Öœ-lÌw«5¹6‹yZÄX]½!­_68T�_̧–K*)Ü•\€ þ�gŽï)—°t
�5DBv¿, UÂo·P‡Üô*¢�€\o�z.;~ATyš#^ìs·]ÔUû(\’$D÷¸%ó»LeU™¶†þ�X•ùÈJ£j}kEOž^–d˜°ØÕ¶2"ÿ",£Då“pSì c;ûÏjr[­�Vq?p úB!µ÷픞„�œ{b?eV)”Õç‹Ÿ³âô7Ë÷—*ï„=„ÜBZïH_SHbűõ�“O2æU®‘¿
-ƒ�+”{¾ÊôóóÜ–oã<�j=`Seƒ
-àLÿCîCÒê¸wCŠYøqxþ:Üzø65|Yúö ½uYN²Æp¿ý"SëPy!W8½¤¡ÐWzFµ?¢V¢²ŠËHí’qn1Ux`	º(9žì7¿P…óU@U¦6—z
-xa™ëi†µ'°'cÏæ͆�Ñ’Ãxt }EjR—ᔚöc’ËÎ(ë‡Ñ#ÔI]†kÑ›(‘…,·�:®þ&q{iIÿHR[”ÅO—ÛÒßc,n7!Úhœè”>}yä¥GöÐ
-Â=ŠÚÅ׉_ó/7——1»—¬û¦£K`«¨àrøY±|Gõ`È=ÃÖápDÏŇ`™ Ý’(ÌZ“ Röâ.¨ñ”“¬Ù’ŒZ 	eR:Ž™Ÿñs͉æ„DuaïkÕOSA`«Ñó�uÎÝU'VAŸý^RõÂly�ÄspèÈ^4ô—�Ó$¥?ÝÛõ„$x¼@§å�ËÇÅÛoÔ$Z\—¬O„Z]È\(‚u
-8-y¨u'ö8÷ó\9b€Btï1³‰+/áu?ÌeóBjŸ(³ÂMEAé¬%»…> :þ
-aÍ×#êT/ãÜp·$3x»f'Óc;‚“Zà�Cq‹4:-žørf›B!èè‰<2©ÄP¶¿°wFôŽ.¨S:=<o(vY\×ø]l 6ÃÜX2ÌçJÕºûë:ƒ €˜LôÁ‡×V•GÒËôaq!´ÏU¹"õ‚WÕ§³o®Ç¦ ’êZæf3@¼eŽY{á>ØܹDñF-M0î’s%
-ÑÁQ|®gšnîòøÃ>_adÿæþ©£ñ!Îò¦_ 'Á™Œž$\­	ÌÓÞbHz¹×szrP'ðÌïã];7wÿ]@Ë/c™&ïÑj©ØMËùgº ˆàRŠ*6?á<Q±¿h9“µ›PåÀª;g¼¿W�e�ø§eî¥Åu¸<Å]f†ß½ÒÅ{üÚEG2kI2’‰aªˆûÃ
ׂ^µñ2€Ž¾‚ºeT�R.™ã·”sÉ„5šT“ÃpÏ	ÆJa¦s#
-ª
-ˆ¤ÅúÀÌ^wrËMb�vÖºQv¸”ÀÕM€’û•}«9»\û®­µñ¶hý(t
=�Ð!yØôѼèãL[±I–ºîîfÖ ÷k6«6Ü´‚W·
-ú4.Q¶É;X¸%ÝC³‹£w1¹G[è£ëWc/hl·÷­-Ò
2[Ÿï«+Çë9?èAaOc·t�o1b
-'úrxxÅ¡®bâò¡¶(»�EìæF‘ÚòQ2Ž'™'y•Û%
-]L­÷ú0bK„‡‡sMßTÕw÷ˆž7ÛÄ1�Mˆ2çµZ¶‹h/+׃ùgo•Þ#(úyék)@;4ð•ôò,zfM?H€H€Q,Cw9ø€†¯Æm·;8^vWâ×g×Õg*¶v£2ãˆ~½s
-:ï5€.X¯N¡Cx™kãºÇ6°=T¯6d‰;͇W.‚ìeœ1Gx²MÕkÍÇ~¶]
-ÉѨzJ±[س¡£•ûLç}Ÿ’8QŸ†žèóÇ8ç°ŠÁIZ‡6§¡Ã¾¤ŽÝCkÀ.`ƒ�\oàZÌZkif»?“䀅x`mH;ÐÒSVÅÁ°¸€ÈØ%à’ŒLN•ÿQ»Ž>19½)içíö	q€ú#ó¸adã|-‘³÷ $ç¹%@»µÒó³g�x«
ÖŽ¾—©ý$œ.¹gL<§ÍòÕõñ7bƒS¢£éj%;"Á2k)à"ÿx×9=FY‡ŸwjçJ’�
R�ö‹$›¿a,~LoÇôÚ«Ñäå³8Y}òç¢I6E�ÁÑ«ÿ¨œUX¬ÍÂ\>
HnŠNß–YÁ ðV
-t/˜~ü;™�nCÌ’}8êÂ)(Û8·ñËq]>\=n;‘:NœÞãË2hk]yt5Ï2NŠºœ¹ìI*œšuÚ D.²QQD‹°•6c8r…*Øê	Í
-ÉJ2kç¤%o72mÝIËKèo5š�n$éÒŠY~èp™î/íy\mT§ë4çN²jÆjKSO}Óé†6Ñ
gô]æÉ•\Gu²Ô2%LzI|’µ–ʽ۳:½TÇÔõöãOA©!
·\x,{"ÌF‘Ýwz§ÇY2­Îž•OdçÊúÎ`/â•<Á³Û9ˆÖˆH!‹¾Ó„ˆv�Ž–,ÕõMÄ[ñ«
Ïõ^‘9¹Õ3Nr‘17'rùJÒ¢î•"bPŒÆ(#é˜�ÛSˆËZZƒ•õuÄþà35<¥¥½::ãÞ‡
�®™!‚oš”,~�"‚\Õ
U¿{’áYAäÌ(q«Í€Š�µf­Ágß‘ãÓÅ:%§££ð¨±ræ'ô*"
-Sdü=zÔýKò*<gÙ e
-ä’
-t�mQbà¯mq™‹Ó™Ãþ<}~µ[$ÌE(-$Â÷p¯¦Ãk"†½®"ÂÔÑóM¯r=PUÏ£<z`YOû€Ñ¶¡éœp¡.¼2#ëî=™j'Îgª±Ï†ÕP…êf
-ínø‡ç¨H,d10PP�
ñÌG7¼_dêÜšÃjSX[‡sò9–øî}J·tqü´óįö±jFˆ~å�^xíVî°¶+'žÔ�i¤‰Å>Œäç(–©N'Ù¦7ÍÌu<TF[•÷EÔf±ôÒðÑ¢­äj›Ü!|íó€t_ŸŒ&âɈ%Ðóm“õC#¸\!…øí…§kÃ+襴aÔÁd–ÈÀáFb�Çä‹ù­™7,jûJ<Îy|»£Ên§†“±S¸J[äA
°óc¸`tÈËu*ÉËšÇð)µßŒÒšŠz̤¨ï‘�Yq«@¡ôÒFó¤iIl.¼3� h뉵óØ}ü„qÓ~|lHþèDYYnCè&Ì´çAdúsÀíe*ª¤õ
--„xUdÛ¨û+õÇñ	Ñhå3MLÐ�Ìg•¼´æ´[Ðånd&N[I�³œ9u»Ž;h‚¦h	Ã&±v¤ðcý‚Æg[ÙÏ©R#*
-ñ¥ØDˆƒ¥™Pþh÷�ioi1ÂÿðïîÅíº”a¬M(añêâiùÃ
êÌ‹þîÜ0Æ«ŠÉ,zÃĵ:ûc
-‡ÓÕà¦^=µ®ãF–:%)Wmq
f`чÃyÜ©˜¯*Ò2|í~ð�µÜæf˜wÔªóŽ6‚ê¶SÖÞ¹†öJya×
-§[ªhÃàz\^-B}‹,�Kþý×nc�]O;EÎ�Ám±dé¹cxá˜g¸=%T]ãë÷�\†ƒ»jïÑÅðdêÅâºì´Z>»M4–‹ÎUìé´wâ; 0eÑ©€©KE*Ѽ—`0‘Êêk6_í„.‹6wVv>OÜ€@w¿‹Ê«ˆüŽnËé(Õä�^…õšjóFkƒ^Ù*® cJ#,ÆÆß“Û§FõçÆÅ¢Ê ôó¶‡aÞx’)ï
B'ƒ=Z°?é�uÊiŽ% 1~fÌ3Aù/A€NÖß
Bl‡wÜB+<{ÔÄŠ	€£iÝìG{K¿/è~¶ïõÄøìϥʰq˜X†bÝ>tÇ^hÜBÆ´½¾[â.1óÿb´$&ÄæEU¢láa/ëÔ tï˜Åpç7�/îEbØ…>	åÅ`YךŸ"3^›r¿ê‰Š;Ú�Q€µScÚï|Ö%Æûêæ%ÎÖ@äR›„L19ÒíQa[ˆb}[�2"¨œIÍžïš‰MÅîùÐÛ	Ïü.ùœ©e‡2yÇœóé(-å5Óü´�õö	´6¬±Ãþ<v‚sÖ£Ù¿1
-(led7)ÒÙsýœ¨p')ú¸ã]ž¾Îã»:N2àp6,Í×ê[®¿HÑÇn€R±PZ“Tª®¼Ø¡!Û$aìºï&Ĭ½oßlfS,åµ¢ÚxµÊ QœK;cå›@¤W?陉é�ÍBËzîrè&
’1i¶üžÅ…‘ŠI3w¨)§tÇœÅþ>Ú
™D;Ùäþºˆ_4×}‘ZQ%“›½™·]+ŒO‹àZâÃì&äÉ›Ã.²]ÝHŠöç˜ÉuÜPè95ÿ	�뢗ÁfDZbŠDl~r’nü%n†MmÂ7áC¢†æ‰‰b Msû¹(ŽãŒ¬--¿ò^Žö垌½ª»1”Ék^-ý•‹Dúft^t,¦£®ud˜'½ã0"©1oQòŠýAÕؽ6$-0,µy±ZdR3cÛ^„OKoÿ(r¯”Šµß‚¢ùe :3ĆԱhº¡³Œº:
-¤öÎ� "¦ýŽ :B;«ø&&c€'I”…Òn|]ãh¥ƒµ•
-%‘åwÕkïvm—wàpÇJ¹¾U	œ÷&“³�oP�1‘\œfr;Š|Y[âéÂn†ö¹ë°¾LTÁ¸Ÿ£d«ãÇ­!5ñ樹õS^¤X#Ûwô¨$c#Õp×RqE.84A•„�#ËPÆ4UÄ«SÚíÉ°ª\bÚô„ÑÑ`“ÇH­0åɹr,_QwæÖB“V
Ÿ4	O=“½´†?â;ežÞ¿(‡½
-7©¨�—.q`~K±
-¯3}â›ÛÉAj¸*óbŽ$k3VgzØOÜæ*PÛ=Idi)~*0vyÊ�î
-9ŽJ $W‚`ú­ýRÂ#Ëí"?æ’²†øo£qErl>í�Ïÿˆ!!(šÐ(ìÍ^÷H®²€Â#½7§”dËO€š>Äá}¿½8$�	4ûÝJ—ó^wÅý$-ZÇ;¯'ÉÔï{œU¡f
-Rs2$Ñ%º‹ë!n�ß%BÛ»C)uv÷'\ó&6Éu¨ë=Ôä:Æ	k‡z½ÌèœýU9S/ƒœþÀϨŠïw1~µ0D6Y+e»ø�ݼF‚z—P÷«údoÀ·
“T”,û«ðrJvº™‡ô¦ä‰_q ¸‰¸Oñ>Ëz0å™ð3ü™&UK&g&¥Ä²è÷˜‘[zÄ KR"áš…�Ê�Ž®è/¶ß~+˜àÔó†pJ§ã•<êw­òöViåhúyufRµÕ–4êåp\W a‚Ó\—B
-':o´ù]9>áÉ¡-Ö™)yãXp<âo_jð½äÂUZ帥þ06_VnO¨nórzcúî×Õ:L“5uþ¨8Ýi÷™¦»‚w®P€RJaa¨êé4
¯a²¿{LÑ™B”³è\@oE…Ð;çA‰
Èø,È+”qË�ájŒÂ¹’dV8G³}cÖÀdâæî‚^.ìÍûÚ�˜ÿà>*Õk …ÇÄx>2øµ•_&9¯!Æx˜ÙG"¼ï*“¹±ÌÝ»á‰V0�D)É¢‚k‹÷ž:å¯P4û
-Œ›?�yUGáõcç’£Ä%³¤™š€î°®÷�š�TYØô
-®V´:cMG	 ÏÌR\Y^( [#¶æÉù´*Ž|J¾¿µ°æêÇߎR/ð÷hïšý®dèÍß!HŨ¦µ—`èH�ÜÙ•õiÒ¥8Ÿ¢—"ƿ첈ïæÇ`é"¹º’ÆSð’ÞÈÏ–<$¸Î�â‰ã
-y#K×2ª®q1g¬›“‘-öæÙú݃ÓIÝFÍ×½Mx°<?ÑgýÆkµB-ÝNlr¥A¤M/šÅƒ¾Iµä;5
÷£,Ø¿W‰`ˆiÈäLJ©x’ ʪѾÓF/Gc à"Ç»_¹�,Ó¯+¢¸&lwsä`“ïS�&®ÖyGpˆ$9>O	cׇK2ºëAÆö¹Ì,b

šO)Ù˜•䪎ۖÜå×ïLlˆ¨¯Ø:
-:^fËër¡ó5‘ª‹�ê(foC;a'¥'Ô'pq84«Åq†‚iµ‡„
-¤¬™·yæN¡ÒÍ=Ñxhwí‡Ð¦-LêÅoR„µ ”3'ÅžŽ7vF£¼êb•r1uºÄ…›Ùaml³§W·áFIöõ»_ìß±#EÂp¯Î\R8ú�rî	,¸©n²o‰¨¡2V;�ëÃrÁÿßþî[gƶé¾ï—OžBË&í)Ü\ù#�ûÌÿ7õ|®æov·E|’ïÙ}…I%\ÜrŸø¥
7K¢ì´v,_Zµ¢e¥ÐŠÒyÛÕíŽ%_ÿœ÷ã�yìÍ2#íO¯Ö8_^{ñšÃÿ9ÊçC'±2]ØÓÔyÕáùÍ)Óç©X÷\�â~¡æô}Ù’—§Ëøb�y³Äó{K9ì™ül“íÙtß9³äí2Ë~ŸÏ�MÖYYzࢄ°TƒÎŸ8ë6‰B9ûdIF†Æ{úáª:OãÊ.,|©–u‰•Énãk“9u³3zX&jîû7WD‹ý î9�“fGÝÏòTNo½ª÷À’Ñž3(È'Pôè§b/©ˆóy§?nIËy¶ÚH©îš©ÖšÖæ-×¾$êMS|á*¹áö±k¬«¼+§Yå–óŸ}˜á·ÓÂ;œ¬ëönüÍ¢°i�òüêÕþ™6íŸLÂ6/èžµý±æc‰][K8–¾‰KQùiš¾ZnrKb]Ÿ:ß˃ü—ü¬²��´o\gl­V“Üèãë]šwó¹KÿM
“?
ÌÉ{EÝf3Ë…¼×Q©‘éÏÙ¼‚ýCÒR¥Èk_g-äM·´ÊQüµõ­öf
-
ר
ÀäœÔÄ¢’üÜÄ¢l.
-endobj
-885 0 obj <<
-/Type /Font
-/Subtype /Type1
-/Encoding 1921 0 R
-/FirstChar 34
-/LastChar 125
-/Widths 1929 0 R
-/BaseFont /NQLZDD+NimbusMonL-Bold
-/FontDescriptor 883 0 R
->> endobj
-883 0 obj <<
-/Ascent 624
-/CapHeight 552
-/Descent -126
-/FontName /NQLZDD+NimbusMonL-Bold
-/ItalicAngle 0
-/StemV 101
-/XHeight 439
-/FontBBox [-43 -278 681 871]
-/Flags 4
-/CharSet (/quotedbl/numbersign/plus/hyphen/period/slash/zero/one/two/three/five/six/seven/eight/semicolon/equal/A/B/D/E/F/G/H/K/M/N/O/R/S/T/W/Z/bracketleft/bracketright/a/b/c/d/e/f/g/h/i/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/braceleft/bar/braceright)
-/FontFile 884 0 R
->> endobj
-1929 0 obj
-[600 600 0 0 0 0 0 0 0 600 0 600 600 600 600 600 600 600 0 600 600 600 600 0 0 600 0 600 0 0 0 600 600 0 600 600 600 600 600 0 0 600 0 600 600 600 0 0 600 600 600 0 0 600 0 0 600 600 0 600 0 0 0 600 600 600 600 600 600 600 600 600 0 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 ]
-endobj
-878 0 obj <<
-/Length1 1620
-/Length2 20127
-/Length3 532
-/Length 21036     
-/Filter /FlateDecode
->>
-stream
-xÚ¬ºct¤]·.Ûv*I§cul'[£b§bÛ¶mÛ¶­Ží¤cwý¼ï·÷>cŸóëœý£jÜk^s^×Zë5FQ’)ª0›Ø
%ìlA,ŒÌ<
-o(:¨Ñ_‚ä¤ñOFuØI)Q’¬¥®‰Í:T\+kÀ2ñ´Ò(ÏË2+­Ô»Ð]é¾çAM�¾×Q­?A"tto¯�$ÏÊAœÇÛwÎB�¼ã¢ü1lþUx�q¨eÝÒäöt¼d"�$ÀÇŒ‡™M ,tEÃ2g§ö“0AC�ª•ƒÇ“IyàbL�żê|c
-)/
úh½0HéZ=`|K›@?ôî3Ob¨cËL<Bß1d÷h•ß$™§”±ù¡î]C¶Y™�GOýú!‰�ëŠ.=÷«Ý¹½.oÇ°,½ƒšt­¯”3sƒÆÖ®·qbé§0ŠÅ°ÈDY~–iÃøu(Ò˾‰ªæ³?ž�
cŠÔbdS7sYð§>ádÍíìÉQûcz‹þú7¾cèü¹$	Æ>2Í%—¹ß°%F
->@í£dJî'�¾T¨WÝ–
’ÆÑë«úþ®@Zl—,P* ï™7o6x©bäÀ×ZëíùOרc ‰^à°HY¹ê¶]¼„qGÝx-
$v·úyüJŠÑ‹lüwÝ„ze|5lÇ¢‰Û&^^Y†¯d¤å¸=眫Ø'ZðþžQ.,°#p¯ü°Éøù¨~j‡|i¯ÖÍ_)¢é<-ëqHb_Ò»S3‚4~«Ò/²Jú
-ó»kœAUyÑ®
D‰<aº/Q߆W}á{N·râ‹0¢ž¦¸2üuŠþK!Ìe§óç-õœ_…Éæé&·öŽtºö›)×öÜÑiÞÜ=39^TùyÖVÑúA`›Ë¯“Š×1³[´³Cr!F\YÔT¯É$0¹âv¬]1¹â2õ¦2˜÷¨ÏQï<^™2ÄH‘,Fð«­Ѐö

�ÕúSöËö$§f@ÂÝ}7EŠqÂl™ûÑ0†R
-CùV¿�·¬�žg&�>ˆ„’"µpVk_í+t·—$ïÒBh�tçß’¼`ª-�‘C†<l®I4@‚ŠÕÆ6Ã0;˜‚û;>Èù}îÒôƒ¡OQN¢¾hÉlÙ‚¦X©ÍÉÃÚ-ðÝ󜚮Ӳå‰f]D–„]fp`Ý
-‘ו‡ošDƒŒ¾”¹�yÙÚ<1Þö÷Š3
-9àÙ÷:Å„Ÿ\ÉFlý¹ŽNÁçµ±½F¥1¢{1I#�ù�#gÐM!Å&Ð!ùf¸¸<:â‘�[Ç‚êÞ
—dx²U�Ãü9‰Åm³{¦¨F�®Aº/b›ƒÞŸ&ŽiÊù0ÆÊ<É{–3Á—)t;¾
-I…ÆÄ8á J’«2ðÚÁF–û†t÷+àK‘D:rtËSα£³ÒFX°Y¿ƒw0¢ºãÎo‰Õ"Ú-P¼L>Vš˜ñפ2 Ynîë|CVÞZsZú Ó†x9�„ĶU&bNž\@š'üýlNÔÞû1ãWÎèjöE¡¬¨ÿI1©~´Ç)¨¥P#çP&¦B5ãrEò¬é&Ü�ìPÿgÖ©‘ŽrÏ3ä5ë(h“‹£66q¨	JÄ·­ï|à·Ë Ç#·û:[‘úìƒîi0žì­ÎÚoœ*3ö8¡|SgrJ_ˆ·¬»TáZ‡%{ÍbË„pøTþÃiK¢`È$Ñò-ž—
r
-g}%ž�¿<ÿš¦¢§y>ÕdsŸZˆ—ŸäØt‘ùB<*C�uù­
Xò4RWJY¾?Ôse4¿¦öÁGGøË=1nI6ö>â¶�dxøÛzÀÛö§úø÷^`K­™u ÒZ¹$gMÍÍE®Ý§R‰³› |~Π
;âIךÚCXFçÔ[ �"9Û
-%Všy¯Žç½wd`õ\¥
-?>Lîw\_¼__º‚+�úˆ—Ï*×5²,Üâ~‡
-ËGBÐ×4
$<]q…x\6_Ì�I_ϱȸtÓ<< ±ã[ôV(“K—�ê£hAÑLÿ�ž�ƒ«±î�«k”“Á™-H¼~„ÈëRtàÆ;ê¬ԧОSŸ«,Ä>x›ºQmMΠà¸ÀöH|’MÇD-2:s»ÁK¾jÍ)yu$–©Ó:ž•([mq!+G�Œ™SÞz‚PùÒ†�ÞjLñpö«Ys%²Ý¶p¬z.M[›t]Þ§ÀŽKxÀKPų½×ÕêL•ªçLý=à'd{ì-¥?Ö­�#†‚­¢E^+#6#–
ñ/–“õ­ñ¼ÍTñÖ<ínÀZ‰/”Ú8Y2ÓØ/gÓAÓ›øæ±,dx
-v]šÑØ}a(ôÉ:eÝX!±«AÏ�[–Ž×ÊÜ’ÀæƹƣÞ3a‘^£ãxR°šË\ì2ª<2€ÿŒÍmxÕîQžæ‘QáE‚ž�È¿¼=±HF,ÃØðªÊжÌ>Èü]¼¾Ø¨ÍqZ\Q0³“×-|/SS´æ;ª?
 [B�«˜jÜë&BØ’ÆIRòu“$€„ƒƒj°�i&ÝY³$——½å£
-ç
¨÷i
¼%0¸)xëõdïIG•&Ž¿œÃtɳ6†ž7|¸.&õ
-	-ΈŸçf™ÕÈPMC°3p§î¸eÚìq²áBÞæh‡~ò¨,þ�¶¢Æ®¹ÿã
-¥;Kƒ{jPÌ�CÛf¯¨“Ø£_:©Ãb*¬Ž–Ôº°AïhµûÞÈq‚F΃a¹¦Ô9›X´Öò€)t‘ÚQPAng©§âÏíÿ4»š†ü˜©>¹I¡Îúîá
--5ù\;³½�2>V®±*T#
+
-@0‡cz´ëðcL"¸¶©ˆ1tQ mhž7OyÙK/=mŽ1Ü´iüŒÇŠ··ôŒÄŒ%¥”v=
\lB­×9Ɔ½‰ü‘“WŽÄõÝ©s;Ú¾†øðýa_ 7,Z±jg[À6¾bV¤ÊY—qá=›TLÀTæù4¸©ŒZä¹xæÇ©D
 S7Aof„ûoŽ¦¹¶†d¬Å(?#	Í”¡4÷Ú7©¯;˜Ác%$P„P|¹Ú“k½T˜d
�pR(áæÓþ;	@UÂŽåo.P
-·?å?«ì:º;rº¶;(œåÒHBÐUQ%Wy¯ÇûcEàÝÚóÌãÁÏbמgo@¦
ð­q´ÔDÖèÈ'
)øóÁ�«ÄhåHø*²ï›#™·ZÏYHá(%Òïg!›µß¿ûW{|êõhñGÆq¡ÄL»»o–DTèd·ºãú±‚e6D²]�}~Ç¢jé‰
-S(xÚ#oÓÜõçç‚
-¦cô)E}dðHÓœGNoj<]Sç¬<âu½âyקûU�7Áê­²‹E«¤py÷á8'ËÍibHö� qT?q::جöì(ݽïRgÝý>^ØûûWM€Õ}ýÐ駋–Ê{ÅóZˆÔ(sï[6ìÂO‘zü
-I³ÙêéÇ–T©-˜R§5߇›‡þÚ@ÂÇŒçoT§÷uf‘‚‚Ÿ£;?®IÖB,$ÊqªG¶vÚâ¯PIJ	•£Æ»¨(¡àœ•SÕ`RHáRp�·É/i¼™É6rƳ¬È»ÚôÊvökU;]äW¸é­�ysV†$Zk›o��ÀëãõK„ö Î£
æe�*|LÞ¹*p¼§}¸ò× }an²éÜ¥ºÏ¡öÚò´Ú7dîyˆg9ÏÅõð¤éFOdtã’ý‰,5FYrè¼c}í¤Ná§à:†KÐe
fŸvE#Ÿ?Íю˪̘í‘0S(Ó¿£ME J+dL©¬¼I­ð^>|$½g'IàŠ´?"týy0ïù4=:9W8ùÉÝ1Õ
-6AdQ›¹Í,>N)¥Ò©ðOã’ÛÍ·o}ŠÓ3U¢ªõ3“ÏŠC…}àp)Æó
¿a™FK›ó+	•W1{‘¨íœiNŒZ?¿~Ô<îZÛ
×Áˆô~ô}“IU?û
-^ºö*ÕÊ;â˜<\éæj�B† :æ‹ãk‡o™ùžËýta�A=« ÓÔ'ŸÔÐH•ÄN!z^“«ÿw¢ëKËÌ´«vߪý'ZÎØS³_-Ÿ!¡ÑÐ9†˜­yƒ±<`–ìÜkÚìƒ8˹‚®UF¡èýÒ¿äâôëO‹¦3xª©‡ì†°b$pãÀfN2rI[	÷Ð�`-IêѸ\\AIëÇz£AÅ
;²;»¬·Ó@sûÑ’Ðë"ø	,méG(;vø™�Ùd×"|‘"¦ŠÄ`྅Óé‘«¬óõlýÖ!|t]Œjø0Š–¬¿Ö¾ª0Z
)ˆM&çEî+
É÷ÉœGÌ7kʱ—Ed`X]ŒÚE•ÀQd¸À'D5õüDU°p¯)+7sZz Ce´–
-Ý)k=g<
-ýÀ”å•LâàÛìàwD#XY«yû¸é ‰z�p£^àž¡�°óRÈÒˆþ‰B
˜D²¼¾Ý_v|˜÷ÕìÆ”¡v’S|*B‰ã˜D#ÑŒ¹N7uˆ'ôx’ÎvïNEy-‡UI9̽Ç|iýB[}¥­Ó¨�ÜE>T”;pf4_·Ñ%ÙøN} T…—Äï÷uĘ¿”õ‰¦ûñ,Ri.ï
-„y„ÑŠ<¦ª�òÐYtÍþz`Õ4ŠMÇ>f·ÅH
3¯�ð(±…¼]¨!9‡çߤ–�šà›c�à
-è°ƒXC#Ä1ž7róѧƒ†1÷‹þØ*:½Ý
-¾¬üš"¨�ùᶓ°P
¾¢®tþkºô¡�ßs˜8ÁºÌÈ8õc°ã9­•Qæ3EåŠü±¹ÙΆq«¿tÔöÙËCCY
^"fDzJ 
-ÛnÂ÷Ù'Î{ü®ÒÿŒŒ®AiD–Xg‰¸N
-Ã2k}„‡�Œ°±hd7,
=½åÒp3{9uN4Ò�œ°T—£b؆F–i$ïó‹'p‘}¾Ÿt¥™´ð^ɨ�"3±Ut¢¡zx²ØÆx4D	K¬ZógÜ–z‘xC6‹]äÂØý9&yóï³t6�?ðÌ"%
-‘¼FøCAÌÑð}>€¶6‡¢ÓVÛþ\ý	diB´«Ù�Q¯è.Ç~Þ‚´ÈÌ=ìäm’6yS$ý-Ñ¥ª¶™)P‚�´)keÅÃvM¡Gã¶Ëe·5%¬_ØYûMŠKÒ}ƒ†Œ8îÕŸÃl5wìóµ Ô<öÅ·£„²3Ç��³’œVÉ÷
-žóø.Ñ°\éd¥(š˜>¯–LãPÊ Ôš3,¿Ô16še¤³Û²˜BG»O�åÔÏæ¦_�ƵW‚®e	oÎP×½'”�@ç×ÒKLýº-/ÞJ[ýŒxw]öG8förˆVƒÉcvÄþh;Ìšé£è‡µŸõ!qîL¾ÂmÕBÇïã@håR}ºûür†¢'rû⣖í5qq!Š¥¥¾Üt¿°wô¯µžQ8É@Œ‹«}Hë%‚Õ›E1TâìGäìï¢vF9Õ´�½Öœþó«õ‚y¦
-°YN0Û�æxôÞù¾•
·Z1#‘pÐG�)œïò±ž{+¿ÝªjwÒ±E©áš=P´Þ7±ÙÑ[7û¦“¸NYYÇU¸yd
-¢ˆÉd)$±¶Š¸[a# :‘�ÁÜ.‹ÍÉü�7LÓ„�(èòGÚyö é안øžwb�MŽÓüÇÞN�Ëe?ZÎÂfRc¯PÌeš²ªéQÚ"äI8�
-4Æg÷ÎüôL¬¾¾Ò?Âlœ�á6_±Â؈u‡ëî$àÝÌ;ÇDpBÝu¢Cbî›#13º;Ï
-*‡Kò·¶‡;¼-’"+ܦ˳-ý<ÎÈt_üöYëÎ’áBÁ‚¡$üé©Ò.&�>Ùe¸R¸¡3›Áÿ]u7üaÌõñ.R8‹zAµÓãvnXLûçpYTÓôª['ÒøUÒà=|¹üº*ÚÜO�AŒ/–*CØ
¿?CÞêh67÷
Wáïx,V½ªŽ_RÆò^/H–}èÈ;‡¨=+mä káÕÊuS®ÉẇNbnN’²‹Y)êctž-yá¬JHw‡d`‹£Mó®úí}KÕ4¬�«–!øWù…�sYÚá•MS
|•Ð§DNß"æµdYDé
-Á4õ5’KÄó}†#‘.§­¤‹R�‹«
-õS—¸­oïV‚•¦x{ì—?]Ž{øjA}øé{¶$õ†BÇÃh>/o†"U¹»ý´P‡SkwUçn0þ€8âàB¶ü¾F;u¶pL)#–�à
-}c6!„L¹âP’{ƒá;D¾dçqí¨ˆz`Ë2«f§µ­])ÊFDŠÜ›/˜[öÃð"§Ê^w�HZÁ‘³"¯�oD{�¼_7züä5àb«;ýS@$ú¡W °²ZðDò¢òuÙ
Ù‡W{fMÞ2ó¥I*,~…Ä©¹#xÖÖŠì�z‰KkVß�L™E�›)¹‚¢ÞIXbÄSóùÈ»´[N[lº3íLX¬˜
üçw^@dqór
-G%vA)ÁÃ
G¬³¤f‹o¥¿ñ`Ý­LF™óVõ‹ÔK‰óÔÝwø`ø?qŸàÁ¨Í	tj@®È<a‹÷
÷äIFÞµåüïñõñ
Ú1*Oîc=÷Sï×Rf•«xh¡«>Îê3cçÈ
-ž(—NÑÄåi¾%¦�Še¿€Ù?ó‡Ÿ›o†`ƒbîª0Ø– õÚ MR�¾
-Xá�…<§õ0ØC"ôñŸjè(–ŸÚŠeÂÑ_{Ú#‹p7ƒLìÙ5`:ì¥~Áì4«¼„?ãL®Ý8Qó\‡,OÇ™ÒÀ;ŒmhT Î§µVÄ! ¿h¥¦ž;t*ê¿ôŸçq
!·Ë,·*¤Z…ΟÐWŸ¼T‘*”„6C‰:(ç›ø9ÖɵQçQÈÔGæǦߑ_<Â9ç×YÛ­ÐÚºMîƒ3u"JL	üüÒ¦Q#ÆV
_©©…vYTóVKYðçæÄÞU™gÔ»ð¼òù‘Ïz‘Z(ßC?¢1Ý=�žâD®jŠR8€‘%öøg×Èži2v»n›„¸MM¢t
Qd�Â*l%–¿‡RS7ÌÖgj¿¤‚<ÿWßÊ}#ó9¼ˆ¯†eç
^™êgÞÀ
Ïõ#²z:Ý¢
-�Ha\»¤ÿE�H
Ü„Ôçì¾f•%bA
¯üIÃvÊ¥lPsw‰8º8Ö­æŽÚz1IÝûQgÜûØÍMw­©•—#ŠC$=ꤡ ºí=ŒjâwÔŸD*/ÜÒdêÅÎV
-�ž‘�õ÷¦ÝÔÆ.3±õƒ¤9ù]v\_17OnS{‡71¼ôtÝêÅËCgû!Ìõ’+
Ì\\j·Äž¸,1Èßß62–e€Æ§¥ì¶£þ&kL¿ÜêWÎc½aàJÚQà&AY¸Úãt�¼Å+«8•�õà�ZõÐ
³…V|Òœ½ÅÆú¡/½99t<�g¸`^B?h¸Ç0Àûµ©¢ûOÛâD¥¿¸ÆŽAôÅöŸÐˆ"&üÒÙGZ‘úáMŠ÷1Ó.Ø›ÉÕ
-}É6¡©†þÇÈE…<ÊP&öÌ>sDõbÛ_ÇÜÛWp	vµe�>‡ÿö²fßé(!‡°~i0bkzì¾ÕIä­ÖÙ²¥©@ œæ‰R&ï…Ãi$|i ׶Î
³�ùòR¥ñ-f	—ºŸæžæœby,I꾟pXðØ©»›¦Æ)bF°¡K·b¬H‰ÌçubØ<A¨õ¨Y*ÓIÄ�w7y	èÃokSI‡&úÆΤ Kʱ¯¨/ÞQ�wŽŸž±“&×í1™>JŽ%Yô¶y�X}<¹ƒùÂ3éîe›i0Û~4f$­z6n/¾˜z¤ðvÀÓx$×ÂìÀˆæÑnmeõaàtçTŠEð­*>÷ËMÉCJÁ0Ýg¿WæWk¡
0[(ÃL�(”ÂÁÒ/;í�:1JÛÙÞ¯£ùþŽŠ's
-†‚˜!Y5ª¬h›Âø
-’9„©²Íºi=ÿ¨nuþò©­'h¾N«˜4Õ 
7<±–¹ûIíÓö†�÷Õ=Î)iÇN{À$dQñãTË0¿‡h¹KÝçµÙÚÒ9äó
ÌèÍï@¢ËG¢�$éðfKvHÀÑ:ÓÝ&îûAoà `žŽ“DGO?Ìd¨ö3ìŒÂ̪i¢ì'Y"-°ö-¸™¸O-õÂ5¾4¡Ã­š6rMŸ4Éì’‰üË¢¸U9F4Ò±SÑU-ÚÆ
-¡à£"Ð,‘gÏKîD~^ººÓÜÉ/Zn\Æ$ÿM­Œù–1ÄŒ)Á×�BoÅ�£E[âcQóh¨X*úêÊÒO>0”�ëw+ÇœðaÚ¨F~¶zñyþþ{‡gS(êá9‡&IdÑX2)Fžb¡8ÚËp¤‹PX,Gæ(xõš2œS`º	faj�e‰ªh.,w¤á«7
-cLÇý2 Ža®
-L­ysŽ<q›é;u	%ý¡xCߤi67k]|Õ•ðÓ�*‰I
-Ñœ±îÙª
Zˆ¼¿›7Ã_ÆvN¹—Ks6Ù\£÷ˆ[�wåÝ4
-ÒÝzI6…®uê+¤S9ü$±ì
-³î^x½«nŸN)ýŠ‚Ÿƒ.Îq:¢:+ùá�Ž{ÎúsX~²‚e–yÚÊYTº¾ws!k�œ(IÛÌÀB(ëÊ#’ØMëü««}d˜D2è9 ‰‹â—'Ì¡ø´ïƒšÛE’,6bOöO;fôu-~_Çx�ð¿7¾ØÄ(Òñ÷í/Ú݈9?’WÛïµÈßFgùè`æ}ô}4*¦
-…3©	¤ô1.aõÂ’ AÜÿJ&ªƒ0E|R*�ü(ô¯[\eZ¢¬ ÏÑZõçú½á¸sÅ%¶_,sEjìœÌ.�®Ü¨llüqÒé;¼ô½ë|i*VÖŸ
-¸Kþ­Óp’¹«³>ú±ägWüD³É÷?æKåÖ�ôm#|žZ¡£¢Ieí"b0G`½t¢n¢J¯q¨ÜÜPé¢G08mÜ8Ùªç µÝ¯Ýã¤ßRf§2e±;$D/Æ&.m�È—(Ân¹\çU"S#�Ð!=7±æ
-’Š±à÷+ÐáËú­qJ®lHsIw¹eòªzDëÞªÔ• NÚšO%ÒçÕñr‰�½¯=W¸Ë„TF%��:uÀ䀙2º,~u‘\ıáýú”�oC}xù‘Žq"4{‰
-@ûÅ#\t£¼ó�¿º™/K®Ÿ±UgR¯H€d~È
-a«Ç|…Á|e¿g½¯
}ð”uT©ûa3s+³Ì¥•¿½ã1KÇ×1¼tþ~¸O`Ë’tyQ[ýÈ—M!›ªo®J¿¦½Á'‚K›ð⊿Sî|
ÿ˜û\W�Aƒ#‰Å9Žê2]2Z³lp‰Fûû–†ÜûO¯†O
&¤ ÜDpªV¦8ï…ñ™÷óìº
è™zgØùÝg¢‚5¹’-É}P«�†öž/£y+
¢rC*î‹#&ï]:x"v˜rNµ4¥‹|ÓWíJû`føZ1mü-msFYîÐ:8[Ž–?[¯+v~ôðá²›	ó&pÀs–K‘v£y¨¤}�Üšÿˆ÷[â01%¸.cœY‰]j�˜ª:Ç¿ùö:Qqæ!åµ¾©ÏÁÈégƒ¡¾{£6jÊÑõ({ö;¯`ôô«î½A$äÆä¥=ÿ7<‰†ÐZLLSXëFŠ}Db62×,èÿv;=›#˜‡Ãc�(íˆFrEƒÎUA7Á¾ºñ°¤‘ïμ	Ÿ³ËØ
0
-·‘—Vh/†¸MƒD:•ÄÇNñü°†•:#Þþ>PLÇÒwïÿQ5GbÄñ
Òû¦ªð@`	Ìz(iVþÉOëµ6‘
-³ãÆY§uïèœÙ+�èï°9¤- ˆíRUöMxöOþúíú¡ÅsC¨3‚Džú›„àyEà·£¸q›—Rôd}ŽO±æé[ÞÄ™G`c·§;[�‰^L–çÎ(Ön^v轈î½—’‚IA?‡�Zdߦx¶ë‡0Þê5/„·ï0iñUE°—,¿"7ZE�"Y÷­à ŒçÂëáÂBG¾8˜¯§�µ#êÂ^	êa¹bÙø´­b÷VîæלuHmzæî	
-P�̪è¥Ôqõ D·Š@ÞDzˆ‹òuçöÿäüfN?ag>-šŒÊM©a7šµjª)Ð¥0c1å˜Åêž&¶Á0®ï¸‚«n9¯ÀMæW )õêP&°C˜Ù‹÷¥J@eôOqðȾÿçx˜¡ù3ÜÏú\åušà$å·=„þ’»:0¥äí
¬	{]Û7°PPÎþm1ˆ’=pËvÑ18Zµ±ˆ
ÀºrG»%±6.«ßÌ¢8Î8П«woZKÉ9'çêí#úG—ïj²X+§ÃšP8†»Œݸ¼0J…®D“-ýf¸=_U0óA­ú¤‰Lÿé-àK�‘ú¥Ïã&zŽ^Lqêm²ù›_º´~æ9ö$ |òÔ«*9k+ôûÒ—eL€<•Ëu¼É]ý	v¨Œº�_rœ!¬ß§Ìèèn"X[,#ѬR;Ry\³¥»VXÀƒ±AA+w
-©õŠÊ»üyž+¾û™%’I†2£mÞá­¥\÷¤uçó:µš¥WbÕ‘¹éˆ×h'¢I��µCŒºÛ 
-JÎtŒa½µ~öB¿çn
8b¦”W»VŽn$èÍñ�)4Üê¤÷VûËÌ�Œ;µ•èN ‰R£ËÐŪ§ýÿ×>Y¶5
(QD‰!%ÝH�îfà¨Ñ9º‘n	i’"]Ò-Ý1ºK�Ýݵ÷þ‡÷Û}îù
çÃyžã•�”4|œ"ïñ`Ûý]_€ßÿ¼�ݲí\£$«:ê¯{¶F†Æ»lìÏ3¢?ÑL$G@Öóå×vmôãŠ#Žª×°tή4ËFIñê\é±¹†òã–ÊcLÏBÙðn¶²e™i¤ÿs;<¶ ¼ÿñÏ7JŸ�¨ie/þ5÷“FàEZUuç!í¯îðœJMþ•³ŽôÓ�	}Ëß–~¸
-Âòé€z{JE‰FªM Û„�u–æG0iž³ÍÀ†�^µYkúzþ'ôÍòH¬n“È([ÒKFR}ÿ^÷ôdk
-±5b�$ßì}Cd%#vﱓ*š°ßÉ
‘ú°»­¥8hñÀÜ_Œ»Ð7¥U½2f
-b›oÒm÷ãÅY…½jãnQŒ˜�fýÊm½­�ªm&*þ8”Èç1|ñ˜a¬~– F‘«•¢ûÎòXQ;(_ÆSI0ü+p˜ý&�á¸$BF
-ý1ì_v#ZâÍ,µgªìVØ
-*‹š@i‰úû¿ž8ëäCî3luRŽn£ÒsbX‰É ýÚ�Nã0Lb£?yrK—Søƒ=Õˆ�áÜá@Æ	žÀlþ
 ¦Ã<˜
'•AÅ87gñU˜
-Üxäø›Š•XGŠyº'üá9vµ,Õ½OÓ
à¬KÏýØIC`­”¿¸9Âò§é¸ˆßcZ”Âh.RÕŒI�8¬_$òfIKmÌXró–€àÇêŸ%Ŭg”ÆÂüˆßY'ºVR, ¨B~
ÐÔAQäϲ¯u£s¢€Ý_˜Œ\@øt-ò©Ÿ’>ö‡Q÷FÉÎUŽ«l$Ô.ËW(¦8*³Ÿ{>B7@-7쑘ôy™Ù7º!„³¶QèÌL}*Ÿ$‚WVÉÉ®š±Èñ×´//2ZA$¼�§¥ªb;>~T6EÕ<Õ¿¿Vj3ps[‡Ú[ë�#.JìñåY¯ª0ûì©'™„±ŸµQÖ8}Q¥ÞÒš½.H�Òý¤ñ‘õ$=¨â¯oñöaZ]‹#6ž/¿¦Ðô¹e¸ÞZ‹ÇM{ªh=Hp¿œ¦-Õôš£åežÂúz‚€ÛÆ«ì(Onû�÷söQY²æ‰Ï&¡I(Ja]�U›-fø´Û[ˆÿÞóݦ6vº%š.[Íá§KpyJÖˆàêh2nösjJ,©VŽ&EͯU¨•x�9øW+0éOžÜX‰3„\
-‚¾¡ÉzŒ:s[­+ž:[´‚r7À«_ó熈ÑFÂ2Õ:¨Ù�˜-Aè
-œÆâO­Œ,Eß�÷�;XM«âU†æüìeçÎ&¾¸cë2“.D£T�«h8&Ëe7nV"ÎCøpÁ¨Ö#}&_ot-ç2ÃæX�L¦ºŠ�ðï"’‚Áf&ѭ탔w¤éʼŽE9Ãê¶Y|t\dà=_©Ÿiµª¯9ÅÝU5½<}âoCʬe±É·mQJ_”�–õx-�ºDïä»3¦Ÿëï"‚_
-{8þF�ÑÇæ–éì	é–sE�cø ôc/
¥Xne­£ß	Ip’XÌ,X§x©o�ÞC§C7}yñ8㟑KÓ•F<Ø—¶cÚùc§>É÷"ÊåæÔYxVì#³í³9y«bTjýé‰NÜáù„…ª�jŽ\«WÍX!Ì[Ê뺧b'ÞŒÆ)<$1ôÊÚ[,à§	ƒ@ŽWÃc3/—°WnY"¬Æ4áé[_Šüå–#xÎöf3I�¹[V¦;ñ²è2f’a_ÏãX;q)ö�&Öö4FØ…È÷Ÿ
-=X¤9�ƒ:Ø•ñÒ
-†*Nñ(ßc“À“
-ÎQÓp/6è~�
-ê™ã2ú»‚îY$óµÉ•­ßª2^IÑPYm3ïÜÚ×Juý¼=ÕùÌ~9Äÿ	2©”pmPkDÉ�	Ç¥)DcX¨Ù콘ûk*+ÇMCÆ{Ù´~­Íµ)²è5�¿¯ÅL|yÿ1ª5u‡Êë�ñ÷Òc9„ÍrU¶óBDøò3TyÈ嘙	SzH1ß+`Îð¶+§`½°W5Ó㎎²ÁÑÃiÁ™,÷ò}cýö3!§ïÒƒŒ‘PuaÛ›”Ë tòÍ|T\ÅL,p�ÈBHðì9çÑô)8H-ú�äjj*ê=êOŽ
-Œ†<\a/r¼ˆvÈxµfíÉCvP€ÕóuóföÈy§Åm4ÍÛÆajùlW¤JÕ4pñû
Z¢Aÿ6Ñ®–B�][¢µš×´B©®¦Ö
-å�UÔwUMõ»gÕ"&
-C•Á&ûA×"4ÂÌ]iÅÎ|,›ž(mÍ…pêÖ.‰ý³oRŽÕ]¸kŽ¬¢PÖ¡ZÛZŒŽT2Ê©‚pC¯–dô.Rn®f™7£žØær
ðk®–-!OõŽž1t¿9~‚ó–�‰æ·q¼mxYæó”9gK’}ÃÜÕè×å HéÏAf™\pCÊˬM‚._óBâÚjq
À¶]qL÷‡Âa¯¡n—ˆ›´¢('â¥&Cv­pñf–¿�‡OFÙ2ö
-# ð:øF(‰¥YäsäLèÆùxÂJßÓ%ÌgæÂîˆñe:‡¯#0®ÿëÊ»3¯‡óíLM¤\“wŒgßRkHäŽÅ_KØwÓªÂìni–ŠØ±
¨wŠlNþjsßÑ8v<o¸ÞâÖ²ãU8^ë|Wš�
-ÆúÁÿ%ž†ëÿ	öÿÿsK¨«»³#ÔÕûÿ
-endobj
-879 0 obj <<
-/Type /Font
-/Subtype /Type1
-/Encoding 1921 0 R
-/FirstChar 2
-/LastChar 151
-/Widths 1930 0 R
-/BaseFont /HVVXSU+URWPalladioL-Ital
-/FontDescriptor 877 0 R
->> endobj
-877 0 obj <<
-/Ascent 722
-/CapHeight 693
-/Descent -261
-/FontName /HVVXSU+URWPalladioL-Ital
-/ItalicAngle -9.5
-/StemV 78
-/XHeight 482
-/FontBBox [-170 -305 1010 941]
-/Flags 4
-/CharSet (/fi/fl/parenleft/parenright/comma/hyphen/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon/A/B/C/D/E/F/G/H/I/K/L/M/N/O/P/Q/R/S/T/U/V/W/X/Y/Z/a/b/c/d/e/f/g/h/i/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/emdash)
-/FontFile 878 0 R
->> endobj
-1930 0 obj
-[528 545 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 333 333 0 0 250 333 250 296 500 500 500 500 500 500 500 500 500 500 250 0 0 0 0 0 0 722 611 667 778 611 556 722 778 333 0 667 556 944 778 778 611 778 667 556 611 778 722 944 722 667 667 0 0 0 0 0 0 444 463 407 500 389 278 500 500 278 0 444 278 778 556 444 500 463 389 389 333 556 500 722 500 500 444 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1000 ]
-endobj
-862 0 obj <<
-/Length1 1612
-/Length2 18760
-/Length3 532
-/Length 19672     
-/Filter /FlateDecode
->>
-stream
-xÚ¬·ctåßÖ&›£’Û¶mWœT²cÛ¶m§bÛ¶]±*¶­[ÿsºûíqnß/}ß{Œßšxæ3ç3×c“)ªÐ	ÛþŠÛÚ8Ñ1Ñ3räÍ­:;ÊÙÚÈÒ)M�
�lpdd"@C's[QC' 7@h
˜™
L\\\pd
-ŠšRò
-üªm{|ÓÂv¸*Þk‚駹?ÛÜ—Ní>ö¥©F{1­(zR€—ùøÞ$T}¨›ä4
z%ˆégQžW‹²ÛZìŒê»“JÊzÅïPߧ;X`®ž¨üH\
-üÐIí�|ŒRëc1:QA¾Õžž‘'?=RŽ�õÜ@öíãÑäÄÂ’ñ¸@ ’GúÙçà	h©Ux†SA¥7!àÝ´_}jt{êå‘‘â’FX˾*šæ¯Ù´Ë¾'A¦·ð&Ê9H¶îWþÀ¼žŸŽäJœæšËýZw&sÄâmŸ
-ì¿�µ$
œÉ„®'~
-j8+¼="HOló‰à|V”LôIŽÅ_y·1A‘T5dSoEy%|Dm3N†Á‡P¥{ú¼ÞÆÙˆ
-šÔ0ã#¢DËFwˆ(¤ Ù�Ó§~¾f%ž©Y·�˜"<Ø™Él¶‹�ǹÿúä2Ý©²HˆîKöÿ¢Õê’2|Cu˜Äï4‡Ùb
-dÇ$�[ß4˜h3iï*#§†]Y·�6_¡$l¥—\5Š´
-ÖƒGÒgÏt7êz \ÄØSÂèÑÝá	Kz¬Å~»šF£¦s>y{­)ÕCóaÑýû²Ú7×	Ý#ÓF¾o¯Q2v3äòÔן¼xÒ¾#x9�s¬(ÃÇÊÒ÷öUX7Žqb‘ŠŒHö;QºÙö³ˆÊëí:²5p,sÍŠ˜VÚÜýXQý3j�.jWô…¼¬[Ç2#oîä2’«²6¢£�yé0O ÙÓËø8³)Kz¡l„ïzä^骟|‚gOH)àY	îó�¸¢e¾,Ùê›Ì,ðŒ‚þ²Êsźy&Ê⥄ñϤì*“@bKiyäúk@W�Á»¾/ÿë÷îÆ5
Ï##êáù@¹‡ŽRƒ;ÇË6ÈV|¶å9{<)¼ç	QU+ó؉¬@"9ãå·¾9Ì-–†Æ¬»î³ØŽÈ³¼…„e†tY.ž±áW�ËÔÀ;žš¹„PfÙWÐBNûŠ�X÷a|nÓd5ÕR©¡Ûo÷¿]fǧ_$¿å0[^ž‚IpƒVzrEÄsÜó^Á¤ÑÏJó„½Ë®Ïô—qŠž€3«Çþt¿ipôøɼïÆ/ÑøµÑ7d™§©M’°{<1†/ß{€"Ã�g'”Dnnë«J0V�kÜ„},j6ä²6”ª’nå'Ž`gâ[�ö
-õ	Ò””d³3þˆA*ú<ì;»ãçëȈÏÞr‘U�¦Ξƒ	¸R64yEIÝ#ب[@“4ÂS»Ð¯«±÷è(pÖg/ä/ÄX»ÐÖ@­Å»b¾äcŠÅIî n¿¿„îçç3Ã"çU=^ó»\XºwV¯”¡ûB:Ï‘
-[—ÒØ$ ´zEø}:µ`s(éHô‚Å+X—³÷¶*5Â^ÁmøÆÊ$¶ïÉéGH
->êò:Û†ç-àñw�N‰
-3“7º]Ç }"}x�t¿-i7Ÿè¹½‚•
-üƉ¾ÏÑü
Іž@S&_#‰= ]Œ% eš�PŠ†¼RŽ”oQÈJt{¸œñàº0ê8&ò½A"zXXª‰„^i$º@õÁh0škm}…“u­��@îK/²OÊ\®z��Oóu#«"ùÈR.¯AÇ„ŠòÙôÐJ©�4I°muþ`*?섨0­V2
-p‡÷/ó¢nD(0ÂD
-[Õ%:P+t¦*5Gil@ÐvmY‘ ‚œÁ‰~¦S J�Öjn5£ë—ðys¬Ø0ÒÉð¹¼tOC»¯‰æ÷­™ÄiÐDX¯Ð
-Ù¿®;ªôŠD™r]9@èšÌˆ“Ö�S|æ[Û,
('|f¤~}Ã!Ónëw¦©®n”Š\8ÖgK½Uz:'=*"Ô›%FWHO´­Ú³ÒèÒõÖDÐ_|ÌÎ\ê\Û
-qá‚ú a�¾ýGŸºî“•e
-™âîÑ~)�Ü“U‚™$¹ß“ñA=‡C“ü‘:³œW•Pv Æû§hbÖ¼ð»AàlmoÎUÁùË7…¹í\~3È
-ÂÏå±äÑs‰�TNŸ	+Ã<ˆ•9O¶¥fÈËDˆF§‹ÑÉöY廙l›¸·°6¿33ïáð\1ôb°	a÷	�Á{ó|³m«é*Ê›}½"é?Yš,µÔ¹‹e§úP�h‹ŽŸXEô¸º\©çÜ[ëgøV3C^à ±çSø�¥$š ƒÛáÃ:“É»®’´ð¾ˆïÅ^ƒÑÁ´‹¶ù´ë¬†)à!jáìKøGR~ŽCkCœùŒBΔí!$ÐdÕˆV`¨­\ ©n¿»Gó§æHðnêÚïvœ&ëÌŠ":—íÞÕ^"Æ;bÊz³N¾0UÅÕ–ûÖ1ÃÁ,Ծ㢫|7ßoV};º:Mý³éØc£ôÂà¤=™MhüCÔgaì‘7¨²Âˆ±b®5_¡·¸/ÂH:L«
>�r>Õ²"™y£6o„Aù±�RQ ¼“_;N\�¾�L©µá%7¸àÀ‘¾g$µc [ž Ü80›=~Øü.¥T¿†ñ¥™^šW`�/ž$8¢%S>ô”æý XÞ$'ñ.ά¡¥„2Éÿoƒã;At«!Äò‚´žÖ&\Åžã™dn£˜kjÓ¥³< -YRç˜oiæ
UìÚ�Æ‘ÌY	Kî%?ê5TXrz¶ë[È/¨£=gU0‰Ü„€UShW´1ûºzcw™>ÔXê1§†S\»²3Š‘ÎBaÊ�‰@,ŒëÂ?/ßu3u¤ð;…®MXÛ;Í0¾z“ƒE9–T¨ÕÖ[x,ÐÏsô1Æ÷Ìó–Q£×©VNcÌ…ËrÖs,¨ ³“eeµ‚l€N0j—;î
-??zÜ…¤Ÿ'PìE¶e6¹-Vƒú£�ò>áÂPe†–½Í•Gèf5©{AuÔ¦JÑø^V¡ÌP
-:Ù‰4GÌCe*Z­:?ß"íÖŠS$`ë¾*~=QîFf†£¾�d5 ?Užaú9v¢÷"“T!KÈ
õð;[
ùÛ
-ðþ�¿$vCÎÛš,Ù‡¦_¡ÌÐpvœY4Ô}ay=,”¸Ý
-׌’üïa,ZÆ¢O>c!Ö’&,î—AØ$l‹ˆ4`¿Ì™é„G‘9h{±IK­àôáî·3ÂF£Ýйô±Peûw
-
8ø=ÇC¦ñÙ"ê®ÒL¨ì:0%»¸vÕ´HƒŒ?˜ø¾âù¢õ3™�VF_?Òí)Û÷³qoTŒ²>ô£‚ùvî[±~á+Ó
ñ¢øøhÂ…ª>çV©Ã{‰iÜÁɾ,ÓPhF°1J4‘÷Ò�.’×l"ü<KÑ*ÊûY•eû�Ê]XODÏ^,@+Ý4‘‚èbiœüÙÄÛù§ô¥‘m
J÷e	�g§÷H9×-7,z3’ '‘nKÜ‹)«ZÞu¯,Ú.«9¡²ûÚ3Ö¥$¯Ü šc
-9P“½¥Þ8€Fl‘…RÜ⎩r«'¶&ÍÖr+v¤Ì•³7_¾‡ßm/!ÚûÑ9òÌÀæAVÔ•I°ÃL"ö„O]á²Â�!³�™¦WD§w<·¿
`Ÿœõ[ï¼¡°)!䛽'2Rj:PCø
Äfűbü]–¬L¡ÅpÝ·mñª}pÜf†Ë	ÑSYá‚ë^0Ñx‘Ê·€ýÍEÛÝöEô7N‚)ÕmÑŒªæÀ á7Š•U÷ↇK›—ß²9¯É,‡…ŒŸX¨<™¡ÌÅ…cÆ"ûgÚùÏ=j³é b«*"ìëLZaì{oFðÂ�{¹†âMAÆ	ßQƒ(°Á0ÖkøcÇǦŽtDþ<`N%ìy0ÉB´¨þ•PPˆ�?Ĭ‰…šåxùVày»—.Jª“ÈÌë/vg`ž0zðõà~¬	|ôiÄlTªœXöA¥j–çW¸�Ó·ôµœñø€l/^ôŠ^ÿ‘XÕH6«3d"Èî:¤úá_T`‚¨KÆ÷Xž³¬¦€­À›†ÚÐt
¨bØ×82ºÙ‹°Y
-g–w¸Ò_ÍÑf�4…,lÕF¯tçÜ äÊåšv…è0‚Z„•åIÝX®E˜w²b�!ZhÙ”�áÉTëkS¸¼SÉômз}P¼½ËiGýÖ´b
Â/ÚãzNÓŸylQ]*+ ºÞ"†V!�™s¾Ð›Íáüô¸Hм‘ôCÕ93Š+-q¤Õ01=*ã±ù¬�uŸrÀeÂËÇ
-{ÃbFg#‚˜–lyù>.i¾™?�#E¬4*872lºGÝ›ü”òóÕ�ƒ¹óšAúa§¢+lµh›¹cÿ[ÅU‚·_Q'ï–íMÇ7&U6æØ‹{tÍ3_ŸÔ_óerˆ$q¿E½â>$zr,¾.ÄBËëDÒ‰ú@û‡ÍDü”Ä­wPL+w1xàKDTjã_žKU÷‡Š¿÷ðN€úè±=©C;]‹‰ØÑ\z©r¸úÕ~ÈK*¼Æf:²}䥳ý]°¤Bu›B<+2¦ø¥Ø×Iÿ§½²¿S©ôûü
¨·zM­<ƒïˆn1•ùu›Ó÷^Vú#�:.æ?¿yÙž®ïµá§ðƒ£|`q^Iš©åâ:kÓãZFMd§Í‡ˆ¨><…÷Å4I)'16TØ͆Nß°`‹ð`	[€r	óz‡ÅÜl8±§’¹Ll[@Æh_ëí; Hk¢ÉjLÁf'‘Ö%З&så@µTýb[Ojöß	0®šm-�Z‡µ<"ÂVç­wSp#H¸Í°ÿ,3L\g*±Ý¾–Ýçpg¡’^�uІªH%a€ÃuQlàÎZK‡B£vHÕqe·lA�W`¬úÑ–îxüFÁŽ¸“Õ7º¼Î�IhB($y{³ÓËòMSô~¥ã# Z|Ѻ6Æ×c>ÁB’Y”ï‚*¤ÓµEkèið„ûܲ²ê6ë#¥ÊxNÛµqqŠ®k%:ЂÃÏý0{Â4Û¤8¿ŸJØTá‡ð~UâjçµDg,Vå|ÌÙ)îmÛÁÎ�n$;ùâßÎWûË)6{ô2÷Å1§ßÿ2_Q.4ÓZxWG)ûqŠ·óGŠõ{RÜh¯ºÎW¦ãrzÞõ�ÈÐKËDä]Üw¹Qöº¯G…\å#n—ë{aæÆŸð»Â¯U"¨k;`�aEw}øŽ¦¢´Äætf	µŒu	&ßéæsÜk¶Qk¥pxNšnL’v’Ô(|)²FðcˆÇY£0c…‚Ø0cX{Ò}hƒ¸eÐúƒKŸ:†ohÁhdYÔ}îw¼Vj¾]½¹cû¦wní†PžQY@V)[7ôU5:Ò³û��Ñ

-¢ðBîBZYø ¡QÚ÷¥Ä:_}ÒbeÚ*r³9ò”¯Ô¿åÏ{ݘéËáªÝ]1÷WšeÂ…5âo#”‰Nb… ¨ô>¶ïÓAÎì·¼žíÉzàá]M¸Q»„)ˆ'°&m
á"²‡8øg+Gž‹-¯ðJÁÙ¶(!‚d%šò÷F¨é’‹Íü0ÓK^žŒð§.Úf9Õºi"‚Bœ‘תÂh<MÆOOìu h9ž&ZO{èìxö6"÷rWNÕ6Ù$Çøâ0™…´žUî�Ç>‚0æ£Þ·/Dž¿V™¹6j©Û̇‡o—�
-_0ß9ø™Ü®Á³@3&i¯)BBD��‚Òr8ª¯sÿ’¶þø¶6ù5EåÇÁ�‡›3§ŸÒû�išI©R«‹ª]S¯Ðeÿzý!KþãÑÑÛ7çÙ96@:áO´ˆ�E(Q`¡W¡ÐêgÉCIචœ7·@ªÁ×N~ðOÎÏL ÔšîÑ„6t>æ€ñtFt&QòŒõk©ú¡Ì:	ZBw˜0.•�Ö 
-X˜DöBà矉uƒRá±êëŒãù³"‹‡»½øS,VëUgÈÓÑ×Hë‡
Ö•Ø®ôh3ßõ½@gYa°«¯ÃK}\)Ú�Ö„èoô}7dÔ{Â+ä’רþ‘ǟúiæpC8[bk�%u‘I0: ]¯úíŽI*]¬NꌕԲî<'âÌ€Dq¥1öYßþù4ˆù;4Ù´Ô˜¥^ðžöE›:ãZ”¢‡
ÖãßhSÁÒ"”‘æeGq	¿¸ú‚Ò®ˆ÷ñ
"‰v=}ç¾ÌÅ%ű;>RÕw´ºÊuú)DãPèñåVÂ-{
i�¢87£rC~zIu(a=/åÓ`éÇ
-`JVæ€ÝM?Ë-*\šFì\q¬w÷4³Ç"Ây'LÜi
�æI²úвTxÝCxEåÇ7#Í=䬯šÐ]ÏÂ)9™šj^wpŸi�uØ•°I/9c½šÙ;ˆ†YÂV%íÇ’:ðgEFÙÒ·O(–qS”•=Ž�M.A¥ó¾5Æ·ôŸ·¸PF×/ *ÝXåï·Dê,oö°`ÐO„&ÄÓú1¢ç)ã”au§4‚x­¦"ô£šV�Knþ?af�¿½ðÒâº-©Þ(äM×4jý€‘âª[ Âx06Ä–3±Ê�bV®gG¬$¨ˆ�X”£þÙ]0ML]B@! !k“ö'9iH„%7ØdÇýý³ê«VÂiH€ð‹Lêõº«§ÜTÉMÓ´1�=1TäöÅ¢Õæû�H&LÏ5« "ŒúÞ¶jªÏa1¾5e‘ׯŠ9³dfƒC|—fS}½Á¢^3²Ry€!©ìcÊ^Ù±•CyÞ>æäŸGY›µöLˆ²Í+ðüw…¯‰‡›]E™†ÏIœº#½Á”“W¿ig/€¶0@hçnlÊäª5Áç�®ýF6PI¥pKˆÈKUëqßoÁÎJôƒED=§É*óS½PlBø±a`
-^ñ2Ý9á4GÌMdHä:a,h�&y	að;!Ù$õÖaÖ8|Z2ÃdÞ‹J‰Óc—…6‘Ñ}Äu"å�ÈÄ7)õ)ÚÞ”L#mõ0n—Ü^žÇl¡~c[ø
ïz¡AèÖЕ–êÍ™qùÐEm)P�F½÷¢xŠÔ–ŒisØ€ç³D6
&œ<ÝÍYï’Úl¥ç¬œs·ÚCò£ypKWFsš£jƒ“ÃÉs ÈÚË~
-¸š4?æ·q|CÇÂ[9ËÞnÑŽ¯U…”kCWvܾOøHBÔfGpÊñ¦Ú™uw"£Û¬‘M+<ÂREÍœËâ`Ô
щ) SßêÓk3—�ÌŒÊy‰m:ãs‚êf“BܲþàĨÙþ†¨4ÃJ´§¹=µ¬�l%Ž»Wa*ÂÎK6#º=\{œ˜{áÒBz[òaey�}1i%œ1ˆpÊeD�Ni±`à6^¥
-“V-Á …ê©>Zw>î^’:ðëÖ£,AÎó=a¼PP?N}“­8s3zxC4-áÙ'Ð@¢¯Äa0½ÌåŠ&vù&� Ê«¹jÐ-OB;ó¹bî�Al/­�äÝÈ»÷
#o«²#yÁ?.¶Üè©®Ï²
-sf"7íȘ'z½½Aܬù;˜-Ø�„º5½ŸPoö’RnÃã—§cÄ­d>­Õ‚ëmOévXš}Ý…["�äC»Îµš Ú·ñfº ?jÊ…Šs$!ϧmAb÷yg‘Õ3–ã¾ú©Ÿ™ì‰YÊIÚÓjû[«Òaîë—e·Ù{/ûÀj�Âé‰õÙÊZXÀüì˜�à äa.ð–Ïæ\àß›¶üؼ¾~
ê¶Éþ¶ü5öZ	š‘X’oJQ˜iOÎãÅ[=Z)é!³»&ç–ÃîIëBå\Ý;»"�B7›§ c)Œ—†Þa�%ó‡ŸTÚÅLn_´´i·‘c•udg/U†Å=7
-BÎA>ȨÅt»î„ÞñMt7¡Š:»ùœ=2>ï((Ÿ!{GÅo’8DiåGÍlœ
ÊãVÍÒUŒÖº‘jÜ”Õíë
-ÞÐõ)δ¨ŠP=¥ŠúçÇ ºÚiÓNRŠÓ€„™�m:ô¹¾@1??¡–­”x!MÕT•ÛŸAsË•-&I˜·ö�@ãݪƒêE!F_Õç5²î´ÛT²«ô±.è-ó°{m
”´YÐßžëÈC&ÐöºoÕ¬ìêW5iø·Š ¹Ž–ðûï�~dÏFœöN{uÍUg¿a`BFtCÙ¾VØ-¯Vâe*ï@ì	@uòQµ
ä8L°4§2�Ir©¶Ð“†¤o§¿Ù	§¥ëÁIÆtPÕ'ÆiÎ�âsëŽÉÇTЃF`�Þ
™0Úu­5hJ»½
Ù‡,KíÜкÔP¡f|éO7§�Hf|dÑr^kç
Žß¼¥'@>¢íð@‘…„—Ä”ÄÄJÄÞ¿Ý>3„Œµ¬èZˆ›Ù¡R^XÚ9ÈÍjÕy0”Nš¯s„gA‚îWˆ™[Uú	£™2õÞzבl‡KØ6`ñ
-î†Å×°æËùß'™+¹O?àªH�‡q@…
-�…eȤ½øÛ ]Ûq};—¼¿ý%W[J¨÷¡¼–Þè	aÁþ[Ò-@^�ŸFðGH¿	ìÏÈÜ°<·eÕ@�wô¨‰Îy«(‘«xd;{”«‰U¸otÁªDÕL
-˜ªˆÍ|Îóp—aÜ^§9Lî÷‹¥¨`=1OþL
-^ú”ã�h@RÄfíÁ•6—U
-×qóp&+yPå°1¦àÙÂ¥å Xˆ|¿
ð$�6Uç»’ÄŽ¸%¼ûm'v»!†æ^™í�ç Åä.°¥6q2Œ\õº«CÛ7E.ÄÔ—¨lwBÂ�æ8=÷_so09Fµtéf²ÅoÊRaáÜJýèb;†xŸ)ｫGœþW¤ÈùQw¤ØØV„K˜7µºy$•o5MåÐà,=²æ_³4¥ñ3ž•÷°Ÿ
-áB«¦¨Û$EZk°`ë¥Y
5qÁ[œù¥ëÂF…:ÁƒN„´®jîܨ€›JV[‘
-ü™±8Éb�º¢¾9àѲœ&Â�&9h°¼§!`Z„ù“½M$¨'Ìé·Ç	ˆ‰b|ö]·[EÍ\çtHL”.=MSeî{F"ä(ËfIÜ
-ˆ4ƬÆx»ák&ªˆü•“KѡڪƎ5soõUKæU6Û‹m™³Ó<{WûFgsü2‘“+tëÑɇ¡ˆ§Ç—–Fë¹mù¨ö9¥û�Œí¬ (	Q«¿˜?©Fߧ$‹OÌr?ãZJŠM¿{m9ùœÄ1+É°‡!¨Ú‚§�¨næòY:ŸAÈ‹Wv¿˜iq“~ˆRŠ
-íqÃoØ8\"É�Äø‰m~'8
�£Éùª¤\"~Ķº…puX‚8R±·ù;¤‡,qÞ\;1´L	AÈ›œ>lϴʘ�ƒ�š¶ü¸\UÆækèK¬ôó(29÷ðJ3ôûõrï˜O²âåMçÑñBu”蓼!þ*²‰ñØx“–ãf�ðÔƒªáFb6ä([N£+þe÷#Ìó�,+CðÇUÓ3Mcf‘ÐAñn0Ja¸Þ.H”#ÓJ>U³ÂåbFµî
V?4™;>
-Û Ì_÷cvDMÄȺ„‘)˜3,fÅ·„@sž?X³¡˜ò\ªå$@Š$ÈW;ö=W!za(NGv È(èᇓÃY†CõdQ1”On?S9Ç>Oµ
-dõ›�#.
-óÕu«ðaxÍ'¢T´Æ49¿}
-„¹ƒ°yeàêÙÔSYãæœjî×]…)Å�’ÀY¡vSWòÀ­¢Ò�GÕîUê£	ãþh4×
¯DTÚè¢Ë ¾ŠŒ}dœœ'.ßñ»c)sùÂ4E©”€cr'L’q!2�XdêFÒ±!NMi€âñ¢ÂdÖ |H—^ÉuÞõ“ù¦?aÈísNfBèÈ(û;Ÿ>§[Q-„- ï$àKor§ËûI’;G¸],˜úJâAžXÚ€àvÞ9g•0žh}[ü £Å‹—T€%/WHþî×Dªÿ~Å!¬„ŒµWJQ;dZUüÁˆo	7êU
‰iT†dG�à!y×"?αLÛuº·Ô~¡šŒ{U#[Ö�÷g_SÚ�®s·ßñs=„Ñý}Ž´þ^W@�ƒ¨IÙ9¼£ýè@‡}Ó$0_>)’¤Èz®Ep,—ðóõè¦
-ÈïQš4Zl’€AÍMNÒ1B.NèL·YÏ¥£ÌÊ©“0d›±)š„¢«ëOØF'Í<
I�('Ó.DÁ=Œ”³‡pEd­ùØøõmQÜÛÓ
-~z#ë6 å˜Mmné©^«�ŠÒŽ†y§�×ù{?¤¾ó
ÃN[„!H-Èâ–‘Ôyú�ê³Ból«nsªYòU4M�ö¤
©0lÕÜ´~µÇê½æ�`
-chô„,	3 ‹
ï‘“#•ÃùG�	ÖÑŠ9$5à »l|ëQλM}ž¥’>‚ÈÔ!¦}™n¿°B=…_½' qŠ=ò¼²D½JQ:|4ù	"V&71¢‡»Ê´XGŽÌ˜Û6�¸XÉL�jðD^«Pìˆ,0ª°>«ÇŒzK„Uê• Á;ð#
zJí™ÛGÃLtåk
­' , 2ýòô™Ï�ªÍÑk|Õ[~>'}A–ž­h¦
M$™O¤�{É™™aý|Fo¾á¦›\basmç­‚‹ÝjM߃½€—RÚ·Ž¤`W<Tº;ˆˆ�³�õì&
> 5YC¶]Þ��œ}ËA…	IñFÝi„—¤>4Å1
 <ÏÜïQ»ÔäJ!¼@ïµ/g”Æ
-¹?¯²YÉLµOÿº“oc€ùÃ^vu?ÂYáQbâÔò%hñ£›Þ|ù:µ˜Â�ôʼn	"¶®œ%v ¾õ
-U¨!š»N}
�œ Ñ“;æJ›ªÙCĵ?ûœôý+¼<¹�辌Ðp—³[»õþAN
-ç´hô@ª{âN'H_È9S(rÚ·kEü&ßÏ•tÛª.Ü,çx>A(wYœÐ%
- ±(ø'E5 Í0Á{'­WÈÐÐlûù
4·Oÿæþk¨ÕÏÙ€œ“æ¬)Tlý¼SM¢ÌºtÙö:ʇOI[|¹,™á
-¸}³i¼<nU·ƒÊ'D†7Òz;
%s}S°l<•’y°4�6Ê–�TZ¹eÛ]�DÕ\Y¹ñ}˜en|(xèn��)<¸ËŒ¢�G/Çê‚«þf�$'„ƒ":è
uë	ìðx/’<€Â?‰CòSÁ064qcZŒz¸ÙÝü�\! ;‰^¼·'PZÖ‰Ev
dŒ
¢bòjGYþ=Ñh/«¹È´®ŸË	$8éÈ'k�ê¼²à
-%gsðùB§*÷Ä•TÝþô¶VÔ½~Þgÿ°s-Ãê¾ù¤‡I3ôÀâʨbŠÅ4ZŨǾdzçÏ—à	Áç‰÷ø׳ŠX]"ïe‰¥?ÂÛjš…<®ÛsÒfÔAgV+¢ÔŸ8ýdÚ¥_ÜÌl:ɶ™q
-L!�
…a¥,C-CŒ}M¾~šÞƒÔCzâë—ò'|;¦DÜ‹	Ž‹¼”ýû·NsŠŠô
c‹Ð9T#qY%%ËGð�	0Ù¥*÷f’
-.³ã׋ÏLH]DÒ.½Å¦œÈçûNcxï*ÿÍRŒõjHG�mwr$Æ›~üzXÉõ½c7G9±fRpÂÔ›õñ`ç¾/ŽFöøÍ¡Sësöe‘Ä¡ûůjrv±K±‚º‹—li¬@bÁ̧òÓµ¬FÁ§”�L¡s¾´_úm\9G�›8+¥£XmK‰^γ³æ&„m©œtðÞì]ª_l„Š@O3º] q—�ÃX;Ü3œåá›
-kƒãåxÄüÁ‡¹C ¥"QPf¦CY_v�ŠÓÑô|‚ŸŽîdœîÃ:
eФÛw‘éûe« VÑê–†P-o‰ã¶*‚½—€:GçMøŸ¥ÀOr¿/CîlMk[6qÉŠP·eÙ0ÿ¸•Ëz
ý?TRÈõó·—Ï(ªå8“j$27BjߺÌèÖ–õ¦òãȹÿäâÌ-:N
^TüÚO`bŒvï	×o(<>yýeþðHó‚Tƒƒ2¸¹ÁíåÞ(å2Çæ¬9½³g¦F³Ùå’Ë?q…ÃN�ßJšPZØcš¹ÔiΑ88›ï…wäD&oô\<朕çÞ‡.'cve‰kÎþšØuôI¡]Èš‡þý+‡¨§Ä ~¸db D:{‹ÛÖq	•¢j+˜ZÖ+·?ÜT±æ­ºŸÀÜÀ!
-û:%é5¾¯åV¾çu™J°5Jòb´â�"2jþä³àí=j¹òüÅÍ·½OÖ±¼×Ñi¥Réqødoeל}½j(áIaR�FT¼‡{°˜Të‰n°‹W÷'½y@,}H5»A¬8ÑLØÑ]��ƒ5ævYÛÐD"ßïŽÊDʺ°z¡Ž »z}ð…ˆÇÄ_@ïO>s0<#gr¹ñ´�»f!bºÛèÊ5ƒ¢Ã–x¦ÐJÚ./°A>x»! jm–²sÞ7v�ÁßC}AœíÁ÷}Žn4XìÅVÄés¡%›†¹¢{Pû< ´éÔ Ì7¹d±·ÝÖ.´?²s1‹�t¯}¼;¯±Ý½’×Gû»{U�Ô.!ó!
T-ºž¸9Çݯ~_’*gûkèŽvª��»¦$û¦ÝU‰ô¥5Sü¼
-
¨ïÃÌ'l¿:¦ðè;{3¦Íäeµ—Ä;»¯McÕÒÚ-ÿXON´Â½²ùr�0‘õC€ƒºÆ…L9ꉱSWËñÛÖþN2¼‹ÆvÃñ’ýÐ È*ö{ä•k^‡jogÊ"oØÊglÂóIüPÚ}tq(½Ÿ
-QCm�6õ
-Ê’¸È˜”m€¿™»_–pÛD�‹KÅ|iVWeeÀÀ«‰
�„lÐÁôÃ�¿ê4èT0Éëë]Ïd‹;PL¹£¥e!D*%)f­­Ð¾ì {ÄùíÐîòs
ÃÕ|0ŠLï-ûÈØÀªY‚èZ`ä<Üu´N!ìÆÂçaæ¨ÞôIJE OÕF
ÚØÙ‚™O¥ì鲟‹„œ*+aB5*êëˆYš0MŽŒ£>ÂãðSΚb¤³(=nìj‘·æÑ4W­ÁÂ-
ÕÏ·­_Ñ�±îíô‡Çº™·`î%âg›«ïW‘iІ
Jmøª º¢Ô††ß‘$1½ÑØ“](snr…„L�¹Rœ±¹UbµVfn3]ú‘ÛÀáˆÿ3�È9ÆTÄk›“¯Bšž«µW¯ôoäˆ9u“lܲ‡vxvèô3Õ ÖÞlQ;,
ÿ®w½ß,Öf9z	ïï‹?ŽJ¬äl*+pË(ÑMÁ™ž eF×gº‡@‰<·5ð˜MêÍ	jmòÏ °ñksŒ]VY:zÅPÆ]•a£¿�u_d„‰ê`”]&6ú‚–2
#³ëb…S–ä|_'UBÉ9ÇØÔ*�+‹©´ËY[–µ²�zŽ’w
-Áë±(�`°1BøÍéÑ÷kL»;B„/ˆ,à G70�“›(Y:¥ö
-ùµi¸ŸÔ§îwX\Ÿy=rû„7"¬ˆiÝe6Õ�Èý`Cõì¥o�Ø?g`ÍF朌‹ÀH‹†ò×ÓÕÏ‘`ñ»
‚ƒT~65Î.96,`³xõµôlë	Ä\θ;&¦!kÇ×å ÆæÁJôV>ÓÛnQ3­‹c…8¤„½aGãÐ$îÉ(»çf†A*"CÛï}„:¾¹Ìl{‹7nN^ÐÊ`„påƒå˘ÌV—Ûyþ2>÷{Ή	=½"ž;ôl`¦GS=)ÅhhR:êbÞ°ã}µ;�íYÏHey~aN'¡¦o¦NQ»ð%`\ô?G°2™9×Á>ìSŠ¬7…¾»Ù6ò_qÛ§ÍȒΊŽ¤¦vغä.Ù#*Íõ¹²G-–à°Ã~3º½øÕNôdàÐH¬|�ò€Ò>I6]ñs˜öüåÛ{ñ7cÌ	a8d?‡ÉNV¦æWíû�ê^ÙŸ\W’é†;ˆwÒ`–v0zA…füA©‰õ§$=›Ò¥˜�ÖÒGVöašMŒs*(±Ó8ü�ì¹äô¶^�d•àŒ1÷·»s®ÛCºDdq
-I¢BŸîÙ¿¿²ÊXãÞLbÁcÔÅã‡Î0¸±hÿŸvæû
-‡

-ïÔ2AÆìöâ©eîÛ›Ó¦;»ŠÞ¹‘°!¸„è`Ò]åU-YñÌëŸò¬ùM5ÁF³·&RGßw´+ùû�è8šŒÁÈfïyFW�
OU£wÀº$¾¿@i¼ù9ºùr¹>ÒHÝÂö§õÆe¢Íw{˜¡Ù
-,ùÌçÖ6ºþ‘ß‘—§ìä*ƒšA>SxÏå’ò§Oœ•Ã�øjäwcâ]o¸‡�´×ç?e•é%IômßÞl)·œ?�Þ4‹™æI¿´—.¦Äì Ê×AÖŒqh}Ä_J¬Qêõu‘¦�ZX´y7³�xÄ,i’¸«^飯\µ1)Ík„ÝÅ	TÅ>¹Þðô3¥Ÿ¦õ1!}KGf³[ZdɦÚ^Ýs>¶ì¨¹…ç›ý˜“]û·çÁ ~V\Yƒ°ÕæÆÐ¥–tQrÿ=<e¢w†|hó$¿åÜ£ëØÁSä<þxØI'è÷¤ïëÚ_tšd¯„§wòÒs_×àdI#ØÙÒ¿˜
-ogÓƒ1GC6E®Í]cdv®l}©µžÆÍE*û‚Xí
øVr,À8è–>7%×5/ÔQz 6@^î$Æ
-Ìkª¸â§hDlU¼v7X}ñÂúZ%fòb+†Î5ƒ;TÅHÿ$IÀÒR.X/+ùeÌö2¸Õ4•õ…6È(z¡ØîõÉìg,Í¢ÛäZ}~û JmÕg(±èe{u›"&Œ›Å?c
-áò¼\¶¿ûë¦
n
-Ý)¥ÀÓ,Ú	€ž–ñ;Þ©x%ŽÇ*:Gï­Ì‘bàÞšÈÚ±ÓÀ'“('
ø·&ᦗ„Bf
s^0©^T
-i¿5xÑ@>,Ïu> w?tiÓ¶0ûôIÏä#%(ù‰ö
-©«ˆ|LO†D¨Å÷¦gîÑå¼Þ8vÉC÷I~®O–ÙÍ>�mŒáõÞ¢‰‘}‚
-^hâŒð·¹ œ£“hZ™Í/øÅ_à7œÀ+P�¸¸&&êåî$+Nȶp®Ô
~I(�–»c¹ÚŸYªÓÅg¶%ø¥p%ö>­’H¾iL¿\ÚõÐß(¦µâ_«8Cƒ—R{‹
-Žµrð¦ëØíû‹0Ê{‡˜ÊQê¸2‰«Zœa‰ƒ†*7Äc¹äJî„I›ÏüìÒ]©æÁ 1=Š¡å©òñS€MX¡¥�GMøªéþP¢‹:*½ÙOT9†ÜD¨*ÀzÞÃ*Úž�“¬ÿ°Ë_hg
-‚œ«ê9ŸjˆŠ"J7Þ®(ðhT(ìâ ª¦¼ÜðÊ™§Ä‹V¬áÝq
-oò]ç}£¯9B‘7õ·	ö�œH{È­�’ëæi`T&éVÇãs"¹‡‡ªÃßÛçVMo¼iá÷׈â{C„^×;¿_g¿`,·÷þ2
Ún“
RÂɫǶ]ÅjÍuib°ƒãÏV!QÏÆ>²¦aO<ö”ñOÁxƒªH²$áófe°§Åû›ê�¥úКxÇÑiêÅà>ò$­–Ìy"-Ú-ŵ ôý‰¤�Ëq�¸ŠÖˆÕ"™[�Ø m¥cA¸¶¹"t8Q+P�K¥ìó÷Ñ”¶ëÛãh_“	®$��+ƒº‡¼S¾ÎúÜþµ$áØ™éezv~7EhÅZÞ‚¥ÓªãHÝ�åûm®Ý‘(ãŸÄ"Þïòwnúê›�»ÉÕ”^«¦
-endobj
-863 0 obj <<
-/Type /Font
-/Subtype /Type1
-/Encoding 1921 0 R
-/FirstChar 33
-/LastChar 125
-/Widths 1931 0 R
-/BaseFont /REOTBO+NimbusMonL-Regu
-/FontDescriptor 861 0 R
->> endobj
-861 0 obj <<
-/Ascent 625
-/CapHeight 557
-/Descent -147
-/FontName /REOTBO+NimbusMonL-Regu
-/ItalicAngle 0
-/StemV 41
-/XHeight 426
-/FontBBox [-12 -237 650 811]
-/Flags 4
-/CharSet (/exclam/quotedbl/numbersign/dollar/percent/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon/semicolon/less/equal/greater/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O/P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/underscore/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/braceleft/bar/braceright)
-/FontFile 862 0 R
->> endobj
-1931 0 obj
-[600 600 600 600 600 0 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 0 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 0 600 0 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 ]
-endobj
-746 0 obj <<
-/Length1 1630
-/Length2 15892
-/Length3 532
-/Length 16775     
-/Filter /FlateDecode
->>
-stream
-xÚ¬¹cx¥]³-Ûv¯ØfǶm¯$+6:ìض“Žm;éØè°culãëç}ÏÞû\ûœ_çÛ¿Ö=kT�ªY£æ¼îûZ”¤ÊjŒ"æ¦@I{WFV&^€†ª–²‰­­‰9ÈAžQÕÁÎð×̉@I)æ4q9Ø‹›¸y
Z@s€8ÐÀÆ`ýúõ+%@ÌÁÑËdiå
- ùËAKOÏð_–\
-ø›UY\òßuºZ™¸þ“Ûô8Xüõ4w0sûgKÿÂþÒüE]M@ö.
-`abû·Wÿ²kØ›�mAöÀ¿šþ«�
-™**À)—PHW£B¢ªU³m·W�ÛÔOrí]VÉ• $«ùqyĤ"õÂzŒf<0ëûë£Îðf}/Ÿí¤>bêFè,VØUd‹ÕƒæÔJlNÍo’©+¬O�XÏ1Ï-¼§c-NÂ1ipÝ›í\AÖ
-úêì`uvdé,RHžê$žkK‚>&Y	¤ºÛ”OØ&â„o™kâÆœm§Ù WëÙÉ
-¨œ/û«Ð[BÒó´`Ûtä¯äÍN¿GfáĈHªýmVéDÇÏ“Ÿ�”Ä÷¦Y_kÉóÍ+èü1pÇÒ¨å�Á³ñÂjD•jÊ
-Ga1�Ã8‘¯YÛ«Ÿãн>½l•ê!¾™Ç”œ±Rš¶?àW'‡Ù_NÄå�ƒÆY4!aÔ„ø‰¥–
-/ÓLòFºVÕa¥¹òÞ+sTe˜1‘G·G]<ÖlI¯7E³±+’Ò=‚��,Cš«OÒØor.¹kÕ/�ÁÓŒ’ÍU�±Hi~|ŒÖw�Úkµqš‡~ƒ¸Ö£7ö³"ÄÇYæ…ÅO	�k_ã1fo4,ëIoböm5¹‹²O½k‚uÒ¥2ƒÞ¡úd‹j¨7W})“Þ‹¤ÐϾÑdT¥wÇ„{•ü�¦ÒfË�ç«Ø™#K˜€Nƒh
çuÏÏ%¢>ÞØXñÿàÛñÝ%�rá§_&ωbksà£uÂÑj£«ÓEŸ
-ö:çkØ¥»ãÆðòvÏ5ÅΰÂÜ0p!.ZÍ2§.•`Õé;ûòÒŸ¾´E'ôòL‹~­'"Bδ	•RÛ…ê뚀ÄÌË1�ú€Þ‚`0ýzл»-õ®‰ÑÆöø�$·«|�Â9˜ ühˆô`´6GÞ£h‹º¢:"ÎÙ;¾M¯_­µJ�%îo%ÒÌnck—ý'y¾‘ýαšm¡‹¦ƒ”õí�Þ*{	iwQ[™¤kžçË tîF!cö8äÞŠNßãÇx´
’Ü!Ä’¥¼Ö¢¦¥Š—Î~_ó©àH¶ýÛ±1%Š–±Ú¹ Ͼº¦á¢Õ>ÝMÐAŸdZ˜Ê51Ýb1ܤɬUð/
-‡Ø
- օݧ�{ÌæßÖRáï›I“¬ïØÃ4†ºéd`ðe'¢ò›KþÈé•ëÀ0xö¯´ØQ¤Î]åhÓJ;ZL½"�7Ò–ñà|êTñÌãço2R°×%‚¬Xs­üòc–>`pȸÔ¢D…Üo½I[«4uÉG ‡äÇ]F?bo÷¦"1I[#–	x�%‡x‹¹žÆɬ²×Á>Эs*´Ïühd&Cîx3Ôà
9‹œkMŒ™"Sà�ÈÕÍŠL€''ƒ™C¦eòœÿ@ËÞÀ4:%½BÔ‡?Ö´OH6c{h¦5/çÕ
-5’Q�Ä„Qƒœqó™0=l­\αç
-¥×$á_~Т:ò›l
-Û…úMÚ„m>ô‹'Á��†ž§MýO³qÎCÄ�]´5CXá*\•MN£dtWî
-BJ!•l!~X‡’Õ É•aó’1Ë"/°E©ø!Jü÷™oó§KDMk§Èéw“F±§Ûˆ{¹g,˜6Q4²«lía¤WÈw©4q’7_úU0"¾B` Ï"ø?(±*ë2­³G€ ¡fÓêQXŽŠJ5úºîÚ ñ%èÐäíb¡Ê¡ÓYÉ_c¸p'vÿЮ/�]·mÐøD‘/³îwòŸÙ|&æ>¡®GSÜ°
¯d9{¶£IóJŠK÷9fã¢éŠ ©þäÁõ@ñ¼9xŒi,P¾*=cùüà‰µNm6O—^E›ªÖž©ÁôЮº
-M2tÉ»bqJCgª`AjI@vr]Ú@Ö *Óä½è¼‰_‰ä”/ú¼�æ�/
-¨á"�R’´‰öÆ$ä	ÚUW=ŽgY·'æýÕ
±M‘‚‡{}•ÜÿöA®ô5±ò½U<b´Iïqç·3Áì\³ù«çsÿ^«Qº×I?^�s2XÉOzG÷6vïáæàæiðŠáãAûÍ6ü‘îav-œ2æ¯Kr�ʃzs_4/“íBào[çç3r„¸)_&x†·¦3‘�ÂÓeX’9iÏiëxêל-9ˆ‡sA\UÛ=$˘¹¦G	ÐñSÅ¿%ÂßR�2õ«&öòôtÈZ¡EÇ£ÚùÌ.êòhnSm»Ä³=£Dý”Çõ6àÆœêk0¼îSF£4pºJÆßú„c¦…QØÉG‹Ìû,\…RXÒ<5µ[�ŽwÂ×óé	‰ªšRš,¯þþ’\™mÄ�T�0쪃ó‚×sõ`ÃO4â„W…¾lï‹Ãë"Z2µ0lÁ¬{¦'(zñ.9_ÄzÎãБ²þãbîÂÑëwS*ú[­FspÛúÛߤ_é~} ‹s\±š“fÿ{ô÷ÁÑ
#ŽÊ‡/°²V L�lQ9áŽ%Ã¥€T… h�(£Œ"Îå
-Þ_#þÍ:ÑdŒ´r@SÓ^É2çQ›¨ô]´à8UY¦�âq¿½Ÿžj_'åm~²˜O±öòÃ
–,®ùé‹‘c^·�Úû…ç C)¾Êt%E—fã$‘P9¼žˆã4yo(¢�‘d9mšjW˜/¢qg
e>KмÎf6ÞÎ'2¦g¯,5ƒŽh­óçü¨6à«ÈÇ
-g!ò)#îLI•eÇO~,EbÛà ¢.ÈÁî=íõÙL(Bćơ=²a~¡Ž LÌjSÈ�¤k²5ž€ŸH½ºFŒ§WiWམXøwÖýï…	\#A†%ñ³‘�Ë2‘j	Ç�´½Û¡õ´„P2’åíC¶²‹’³o K,\QÛ²ÔŽ‹¼Ü
3WÚ	‰SÁ™Û3èF#ëšlËñ°ÁºÌ¬§T{ô?êu5DZ—b!⺂Æ�n9Š#M‘y^Qi$ë\Êo#£
:“�ÐÇÏq`{‹!ˆC%oÝË|°¢’N½`^¾VÄ:z´ßÂØÚ˜Å,Žž”\uyFÌOà�ø6ëÞÀ…?z†t+A×ÜéEî>VµÝ´çröt'ˇÅ<Ë9¶]ÄöýÞCðò�—|fŒK¨ª£µ®ß(­Â‹%SrÜ3ÀðYÙ%ŸT<RÎm�*ˆæ“SÞÑ-ÏaŠC!)wȨÊ;ý&NÀêpêüôÈtöÅ;ÉÈ]¶ÇŒQÉ�Ž_@q²Óa–Û÷Ý n}ù‘Ûü¤ŸZù“íÓúY»hy5}îê]5P×*»a$G(®‹uý"»ÊÏc9‹z›”­
-Qm�®­.
-_Hf³ÚU;ì­^º~ÁÀÝ3µ5é
øÚ¡ºø[\Ù¡&÷Ú;Mo9E*Ûí¬E	Õm¹lê·šÒqd‹¸þýà¡xZ¯ïvô£æQ¤䨟JêÅcFv£1Xc:bv´æQ43ÜËg¡ã6jÄK¸ú¡|R¹š“øÃ÷N7œô±°ÆDL³
ÒYTmN`ÄÔŠÓi
-öYˆ=~åÇk8¨ehúRZ^±V<£‘x–@#”"s•ýÇÚdÔIðP…®÷­•úz8*uÝKœdÕY…®Ùð.Ó©¬á.‚ºuÆTaˆVÇñŸC—nXЫç«j”«žŠçµS¹	Í[džN–üèÇæz	ôÛ¶IµWV€A¶šéÝØNQõÆ6W
-ÿ·^]Ä“†[#"‡6]”�ý¬…Xí=ïóñhé¼ÜmÄ%ýÖF¢WÛþª†Úû—tµdý
-á;¬/¨`>�‘DÉF•X8)RŒ(êe+QBöìøYýú$ø𙨗wš4ÉAÑåFç[/Ìï(=Š|ú11ǹÌYf�Fã–s»Ø'ú[þµwù|¼ŽÇÛ,ë¢39i¯æ¼Žõšm!¸«uEÖê†î	.>Pr˜áËóOªbeå£/Ï”£�à?cÛ^0ô²³Ë«Lâ9}IÍv#VSgzºŽÙÑ‘ðîàê)˜¶©£p.´ÊI*ðwgÚË&)ƒâ²o�UÌäšH€+ßÞÉ¥al‘BéiWŽÎG^ç˜ÀØl8„¬~ÇH/«æ5Àc/ý
-q,‘ô¡ÇúGåKco IÛ³�ø©‚Ž	Nv#j»£)Ÿ—“Ì·‘¶ý¤C±Œmm§
-ÄáÛì‡VJ@ÂyÜ4A“ß(9�,”÷-mZË)é‹�ò8ÕªÇ+“lvÕcÊž|:"Ú�!ý XjñÕ,NÛO¤y|¯aë�ŸÚaƒ™z
-ùΦ�*-Ír»b3‚Ë1<]#°Õ¤pX%'Lèw²ƒIýohZrI ®ìñõQ„è1šØ—×¾˜I×ì
—UHð¢îq‡G[Y(|#8°ˆ¾«ü Ì¡"�@áBÔóѳ{¾¨'™†VæŒþžßˆ)Iª‡ýE«HÞË]~@wt<ª7çqÄEÔË̬´¥!yšj½7§ßÀÛ*«4øÑ?rê9�ðgÅ£ŽÈKj…4HÍD}L
Âà=™òâ1å7Ü4
S¨r/êö,m@ÍH΋pø^T*õg´ ²è‚V
e™'&¯F€™á�myÛvî
ÃQŠ€X¿6~pl“È3ÍeôÆ`âå=õïÒ3(¬•éq7¥s
šçWÐ)¿Ÿ•µ®K¬1¿!qÄI b^B,Ësb¬@¼‰ja¦•0?8ì@?N�©¶�ôÚos¬y¡¸TF3ÎRer�9IÎÊè7?°0x?Dtebv
-"q‚x”Ad€Äœˆ®wÒ4°ÈJÙ¼­Ì8ø¿Wöwm
B\ëê ìáQ�ïÞÌæºÙ2çŠ'=|J¸^Ö{~
%ÒffÞ2*„ÿ¹UU£î[œRnÖûÎçäà/�︊»æÕµ±úøÖ[²@“¬½¡Í—5NCCOQ~Ù/N»ùÞq¾!ê �‚„ÙHÔÚä5Ôû3õíya÷UTE‡3BŒýóGN½Ü‡ÄlXþÔGõ“)Âå§aow;é5’-Vy3Å„§J%™èvsQ¾ó\¥Æ0wW˜jS4ÂÒlêW
bØ9z%ò¶;,_*EéÃŒ¯ïw1wÙ=ò^D%IßïÿèÀ	‘´ÃΉ™ûÆk¸ß‰y(@ÞqH·DêÇ�ÊQsfT+Û©Õ©s>ÁK@BªB¥¦¤¹já»AÙSg(c¯Ì^¹Ÿˆ<H|…vøuMgÌ[¸åßÎe7�wjrò2DüÛ6dlœ
H.)=í:{˜;œ5vrUå(è
-«°;‡5Î9ø%ÏçL¿ôw_†�hÝ¥‰’
6°V…
-�^”ØD>#û|ïzïÔ>Œ_ƈP‰ÌäFY„“ðÉQ[ÜȾo£zsT¸8ŽZv?=�ªÅHAÓB[LÒÒâvl.èÆí“ÚGÆv‹7"E‰†O¥Ojn(`²¯—½Wb°¡vs÷;îù+®{¿ÈýÀX°«§º½[�ŽÓì1˜'½Û6ˆUÊYø“÷dÌe`3ºæç³¼6àHÅ©ÜÁ­ ¾ØÅú(n°ƒù‹"uY»¦·[F’¼3 	J
-ÓdŠ®ÂlÀZ(”ŸRO¹
Œ»“69Û€Ìà†ûŽ�DQäìUJE5ý*rÍ@
-(§[$$Òè,ŠÕ%%yÔ»´Æ”V°ß{Ó(±3·Z„Ö= (0ÜHnƒ«%1œÍBz;�¦ßŽÚsÌ9û=u›UÛþígàÑv±Ú9Ž{â’®0Ý
-�ø%IÆãа¬"£H_|B
-DÈôZ¨K~¡ºy±'§«š—˜Â2ZSŸÄ*_Žs°¬¿áüy­•4á’DˆìG„V!3ÆÓä.¦ŸõÒÀ~Yx²ÚQ3æ0ËÉ*À‚äêJÛnïPýúúx ëW1�1u‚:OwaA” ^†’ÃÆ„fÚÒRW—Ø(˜¾àBß|d9™eŸÇì	x¹|nzç¥üí’�]áÍOúåð�;={É—êž/Ý„x_
?à^ÊÃxVòWû‚¼%uÅºs+§�iTO˜²�ýôˆí^êÓqFÆï;ëá[1IÑÇ@ÑIÍEÃÎXq{tUå½ÊZ$ÊÈ/.·Ë3¨-Î
ï_ßa?›@ñÅPlTÁLþ�Œ?iy1s•ÂyK°€[å>su
ñ-UXr§m;¨:ª•Kó£*gò¤Åú‰áªY&–Ì1Z°ÏÚ¬½ÙQ‘~r"¬JÅÌ`\Š}‰rí&�–¡[@²¦Ú»Eû($:¥ºøeÖÌÈ|�½C¾Ö(ß~™„¡
-ö99'(ÜÛG(#?‚iÎä²q
-[(†ºÍöt
bÚ[·ö-
-HÉU
-’7ø“’ðüÅšŽ,<ëÀ¢
Ò�½è¥;KY±7¨n’7qÍþL3Œ8Œ@×SÿCŠtv‰jáY²Ž¶bb»¸iS
-ÕL;&�ÜÚ社Q²;»UjNN{)òèÈù¥@Ã:è0>nOG"ýya,.�ÉàÙ zi™T�Äë:q!$*nK\Â)÷.¬�’í8>‹	–
Éîu¾J~&Õ†»M[oȳ©žJ´2Ëxy˜3Ÿ�‰“ýÖ.¿”©tü.ó–�5”Ï8A�ž«Z¦´´ò�Ïn‘Kœ'‘[àõ•úV‡54›»Ü,eW~o§5X9mó‹jœkÑ$'<àY�œ@ªùA-G-�_ÚmVó` «ú„£�ù”Ó¹×”Šó“$È�»²™©CÕr1¹"ÄÃ$AŠíŽ)й¦?¤Í0HÝÅŸàcËÉ&<j	©C@×Þ¶ÃtH.‰ŸkèA™ÎÿÎ!á
-u­WfH´‰6çÈPG
-.g4“Mâ'M¦ï(ŠMÑ|éÖˆð…õ²›ÓĘ#5Ç´=È•ò~u¦5Vê£R¯/®£­óH�Ä®f§ŒŠN¿:¿lŒTmoú_ˆ[O»1Â̤§ké&èIN†‹v@‹þH,€tŒt
¦á>Õ'R¥•K.zgóJ˜ë(+Á5¯2ìkÚ Ý϶¨Â[ú3Änè^þ^×ÌæQ¡T d`v+f<�ñ'yжj~›q)ž\k,°ý”škQí—½`µ‰OÒ«cìÔ\,&	šîJ
-íiW‡fÈ“$#Ò±"÷qHÀŠJ\èWxZ'dô•ÿ
-'�î»ìØ•Ë#>¼ºê£Z*¶
?fôÑ1sm%$¥ž
-aþ2rž¯Y"`��¿
-E¢Ì®_Q²HL‰@Zá~fNS^ÿœí^®<+9;ÚyÜúMtéÔtßæN9ïJAñÀئ{½ùMÌJXQ—DÎ+vûÔÕ†|bs”F-Ë•§EJ òó8}]ÕzÙeRéÀd.Ly’ö|ÿDl>Åõ]Ãh­W[®!ûÄT‡�‡ÞuýÝ!"ƒgúˆ.’FHD•‘õÝÖÚšgì$Ð6MN
â�jpx#2ì,y]®“ê™
_ŽwrÀ%�Oqp¶,Ô†´}–úy.Ì0ØÖ³pßãOS*³ã‡�ïwâE†ó0m‘�¨ü…YiEµ‹X‚EiyÂ’“	F/ɪô¶­‚´J´ž—�‡@%aHøèÕ?7ôÝŽ¨Â'’J‡ˆ2LäÍÝDœŒŸh¸Ì¢±·,Žh¶è„CYö]Ñß´­úgmkôfÆ#ÔíÈä�¡J¸Umßý¶ªæö1ãïÕâ•Æ»Å†-eQCÕs�oŸ½Ø‰	Í™ªLlmwÓšÞ—Jš¶9¾!&5#é»~kÃÓ•±�9wX§Mk‘ŠHg¥éÌÐ6ÓÂx̱Ùõr>%Cçñ#ñ“(ž¢Rm|™$×B\µÉ AvV7Áû¯…00À(ä1˵Õ�ÝÝK¦Ü¹Ù~éo»T9
z˜~Yã{òÑ=Mq0ûJA«ø}/£1ÄíÂ�«e—Ѧn/*ómF¿Äxù
q¬äyJS*\€d­-†:¯Ø]yÜÔåTƒ‡¿øƒØE@Í�fvTü
6íÁ2~lW=_xãSeþ<ùBÐÊÒm"¿‹g|£ž�Ž/>¡„ïn‡œ0'OK_5b«F¾ìؽ°`‚ýÔš´ú&¯Ï¸?`;ãõð
æzâŠ×=k-"c	ª)k¡@2×ÜlSÕs'tÜ«f�€p!Ó«‡¢¤H|ö‘¾×Á[ú4ô‹ê9_¹ªÒSGUPâI%¸5–
-¯
-qQ)[‡ŸäW=Òлe~ÙŒB‘»ëó´#âýmω;y»Š%üŽ@D$zfªéA%OÕtØ9ø»«óu 6’RáÞŠxƒ„ï”
-2:RÒ�]š¡¸\•´²DÊ™º´^-;nðÇY~þ0Ÿ1Í»PÒø¤0«¬}¦“?f0­úÙq†cŒ¶[ú¾;¶96�Ø/
-P„é*Ë~fûiöðÐÁ±y;§‹¸Ãà’ßÐpù<3A,
-HG€BÊ!´q<6õûœp—-HM¶�Ýu'¯ýôhË)
-Ûs'&ÞHË¥Á§õŒñ¾QNç—‰Ÿ8[/»'ÚýtÐMs¾Z!Å7ÃFjA¡;Pì;ÎÓ<Ø:ô‹hX[ÇñxWÓ·MéxW�ÕòћӼaç~ݯJürÎÇû®³`ù²ÏÉF™m¨1£áú§U, Å€ÎÌ÷;:Ö�Ç9½èyÄÂ1ž�ìPUºÝS‹QRUib�3íWëA(W×â“ÙÅ€µ†„�äõ6ú¡Q{I–àÆ/Š†#¿I¨
-RW¥Ï
-Òd<—ñ*õ/^›žˆu“ ”Ö†´06f¾Dx>É3ÓÐ6
$cºŽ~{V
-´.ÎlTÖ±ð`­çÐÖátžë¾±ÉŸÜÖR)z’ºª^Å}bû»Îd7
-Á~‡+Ò«‡´¬©Bcá#šUQˆµ»ž2ßÓ5:a]C>+×­7ø×B
-lwÏÍ	¤Á;e£“/~Å©ô6€bDPö€Àì5	ßhàdÓ'±1ãŽ�ÔH®—äI¯Ãz£íFR…R꿧�ù‰´Ôö~ZB‹µü|†šïs>vŽ(B¯)ˆä<µ¢+þ‰>wÓ*>‰v»P°ÈÒÕìn݇�32B‰;¾}0ñ\d3í•©Þlýöu>Ø5
¹¿
å'Všµ«7ŽìòÂn@ÐŒ_÷ u,c!Üy&iÏ6I�¿ÓpǾ
-I3qn»#q.¢+j¨lx¥šÏw$�àmE8L/ëÄŸ4
-i}ü8c©+V\‚ØH}Hȧ¿`$¾³O4Waˆ©þ«ùů�µbâbõê¿Þ™þz[›aó�¬^QÅç¿o¹59ô>Ÿ%{q‡óx§òêÕ/	ìŸ)¨1£7i�-ɉ<ô–Îy×`áÌ~)/B,ÔŒÄ’$¯üÈà‡Š}Ðq�ƒq\­¸Ôä9XÇÊ&Y Ä~ÛÙ?FÑ«âÖ7A�hnzräÍç$"wÅ:XÞ#uq^ß>\xb1Ò»Ïtá6J•ßOõ;‹ŽÉ–a¨Û�ß„f{âe#zP$ü®)И'Â�´³ýyòÓûÕn&såÚd´‘ôòh0×Qš>™ÒsA”>2Ì„8¹º—£q}�ªé·Lm¯‚Ódx¯N›GQðLÚþ‡Yô2�V÷«½	1±ÅµXè*ýõ÷q¦69+ÛÞ¥Ÿá0ë8õ¯Ü§Xî´ÏÚæs>Þ¡v5js+¹¢ˆ´Qaïe÷
-á°âÐÑÄÕ—bJŽãû—"oRc¸°€~:ƃKÚX^ªðTp�—£™#›2¾&�úÑj±7ÊL�åzm-5?ø±�	%;7Ü'GÈav�&³}.uƒîãÑ-ÏAmixûÞ	¢²c
-MIª\ÂuTØjGI-gý�ÂÓ–GâydføæÅxÃÃ,�oÛ.رÌ*�_ùSÕúƒóØCkëÚ™­¨·>]ÙrÿÅ:K¥ÓS%œx
-æ¨5-lçÖwŠ?v¹Í“!‰P£C´é¹2üÇ6$í.ªM¬—¿òÔö�ž8ü¨=Cî<:6¤Ò*À8€Ëi¾‚’¬ˆ§eœxÁ7gSL¥�]ü÷MÁl϶É_LÎ[¯>7‘~KÔ
C¿
bÖ¡ùMÙDSG„l,Ô±ÿ…ô4¨·ÕõvOój˜ývXÚ‹>N]'#èØÌ×!óþÇ7îð*xîG™õñÌþÀ!%aó�Ц_èõ\{¸®qf__ÌjävU“j3ùêEo/ž416ìž-AXðIŸsþã¹ßZI‚–>ÛýNA¸�­s´Kp‹²�ê˜"ÏGx	�™?þ³Kl\jß»¬“aÒۗ샜+€uÊtC—hÇîá•
-¿n$rÝ	Xð�D˜t
ÎõÓ…”2§—n„sÞmOÆ„
 ˆ;²ÃßshuåU9ñÖ�&;y-sõP~K*ªÅz4rnp´�}ª÷œõ)RB—+«å—>¢cI£Ž¹w×	éhz€Ì\mm £MúHþ×<×|Ìï­&‰� Ÿw³s£Üë+\?VË´<=yò‹ØH»M'²ñÑ67Cøoí+A5x5
½·x¯'_Ë
-c!vÜ~óÓ4¶bIpµP]ãH^ŒúÀnkLßYßÙ„æÀ,•‰)tCœrÀ‘Çi†Ï±m$�hýÈn.ÿ¶»öO¿ªWÂ[–{OFChÓ'ž
WùÆ*6L‡1±’g^H]u Ââa3ð¸g@—TÕL_1@d7¾ùÁ“†µ�‹Œ:…‘XF.ÿ§�Òfb1\ÄñSÙ£�Ö®TÁIS ÒŽã{9.´ v´ôPš_$ƒºÃ™.T€Áj”¤RÚ.z�àÂiXÎ^;-”ûkwå0HMKyÃûSc-‘tkâôk'a.*bí	Û¶4ŠdÇ&ž*qÉŸX‡ÒÝÓä"c°4	*+9‚3£
-cáE¢Lg%ãŸïÁó§KíÚï©=ëg‡~Q)œu‘Še7@ô`­¥¡c˜„s2¬ìe/ï´Ã÷
5ØI*·[ÔrH�îD4;"«hntRÉ´c¬¥ŸýÝ„u å{ÿÁØ}hë 
…
-¯41¶{ºQµÚâl·Pãg;‹($@
QQ~:ú4¥ /麞e„¼æª't“Ê>~œÍÆTÂ={š÷ÈcW
ä­ë6Å͆ÇIjË‚¶{Al ¸¸
²œísè¹”Lª £ÈàýÞùqœöÇ=*Y€þK
-endobj
-747 0 obj <<
-/Type /Font
-/Subtype /Type1
-/Encoding 1921 0 R
-/FirstChar 40
-/LastChar 90
-/Widths 1932 0 R
-/BaseFont /SJDLCB+URWPalladioL-Roma-Slant_167
-/FontDescriptor 745 0 R
->> endobj
-745 0 obj <<
-/Ascent 715
-/CapHeight 680
-/Descent -282
-/FontName /SJDLCB+URWPalladioL-Roma-Slant_167
-/ItalicAngle -9
-/StemV 84
-/XHeight 469
-/FontBBox [-166 -283 1021 943]
-/Flags 4
-/CharSet (/parenleft/parenright/hyphen/period/zero/one/two/three/four/five/six/seven/eight/nine/A/B/C/D/E/F/G/H/I/K/L/M/N/O/P/Q/R/S/T/U/V/X/Y/Z)
-/FontFile 746 0 R
->> endobj
-1932 0 obj
-[333 333 0 0 0 333 250 0 500 500 500 500 500 500 500 500 500 500 0 0 0 0 0 0 0 778 611 709 774 611 556 763 832 337 0 726 611 946 831 786 604 786 668 525 613 778 722 0 667 667 667 ]
-endobj
-684 0 obj <<
-/Length1 862
-/Length2 1251
-/Length3 532
-/Length 1861      
-/Filter /FlateDecode
->>
-stream
-xÚíUkTgnõJÀ+Å€€¸
-æ2��%X4©É„’LP�
-A@0¨P¹TZ)­`�åb°¢àY#BAn¬\uÝ
ôØ¥?wíÙ™?ó>Ïó½ß3Ïû�óY˜yúœ9H슈$�Ò
wŸƒ 
-C>"ÚI`:
-—³L	$à³�EÁ €vD²-u‰à‹]ù2˜ãÉ—°y
-Ú$6e`öÂÔ$ìAHAXæð 2ÃPˆ
`îaÛ·ðÒÐßãö¡ï
,`‡Š�˜·ÿ98‘E(
-‹$‹g‹ÿ]Íåc#ƒaÌÆõt!lÇÄ�ܪ¤ò˜/Îßùá#’ÎËÖ
-M�v“_MLŸṡzÎË,XR2R¤ºzB�Uîe;žÒG¯¥{¤}5U¬ñjja™_fµ‘Øíƒ�LH•¯zmc9ÂT„8�ÿ�ʘވ>:ûí–­=S[b[õÎqÔŒCçfºt×[{Ÿ´6ßHë¹ Ýÿá|dÿ“ŽÍ5±¹7¶³ÇoßwczâÅ®©–J®“nÐ4óÀ�P*m¼†�›ï©UG
9skYi�þ²§¦)æÉÏ[|ÊdÓ©1ÆÑ¿Ý
-ÓÆßMM/šþš¥ƒk4e\ï¿£H¼¡"eÄín0u3i}dË{µ±ÕÆCþI0yÀvť᣶�Çû©“ߨµ7–Ƽ(ƒBó«sLw=�
-ÿ¾nûì~|ú1â—U§>+©SèvÕ€ú;îõ¸d¼,Ðñh×J¥¸K¯ÎÈkx'FIø¡1»ö®;»KÅ	?Ð3úîk¯€j\:r}­•Þ<4püzEÇ\ÞI3±üêÀ+æʲÕâb«
ââKq£	ô¾£`åÍŽNð�z,ýpvs‚™j�|-Æ‘ã*­›ÖËk
º«Ïʽz¦Ú}ªÌ(¥™¼BÈçžÑ�ÉHK÷ððòûR+öpSnb
-TÉIs›ò¯7”ï8�Ëlòi~H;¾n¦ñU‚•úÛŒJOó•¦E½óÅ
-endobj
-685 0 obj <<
-/Type /Font
-/Subtype /Type1
-/Encoding 1933 0 R
-/FirstChar 13
-/LastChar 110
-/Widths 1934 0 R
-/BaseFont /JTOBJF+CMSY10
-/FontDescriptor 683 0 R
->> endobj
-683 0 obj <<
-/Ascent 750
-/CapHeight 683
-/Descent -194
-/FontName /JTOBJF+CMSY10
-/ItalicAngle -14.035
-/StemV 85
-/XHeight 431
-/FontBBox [-29 -960 1116 775]
-/Flags 4
-/CharSet (/circlecopyrt/bullet/braceleft/braceright/bar/backslash)
-/FontFile 684 0 R
->> endobj
-1934 0 obj
-[1000 0 500 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 500 500 0 0 278 0 0 0 500 ]
-endobj
-1933 0 obj <<
-/Type /Encoding
-/Differences [ 0 /.notdef 13/circlecopyrt 14/.notdef 15/bullet 16/.notdef 102/braceleft/braceright 104/.notdef 106/bar 107/.notdef 110/backslash 111/.notdef]
->> endobj
-681 0 obj <<
-/Length1 1616
-/Length2 25291
-/Length3 532
-/Length 26183     
-/Filter /FlateDecode
->>
-stream
-xÚ¬ºc”¤]°%\]èª.uÙȲmÛ¶]YV—mÛ¶mtÙ¶ºlÛÖ×ï{çÎ�ug~Í7?r­çDÄÙ±#ö9±Ö“™$òJ4ƶ†@Q[GZzN€Š¢š¼�••�±¹­4�¢­µ
௙š„DÈhàhnk#làä¨
�
Â@#
-
Ó¿rÐÓÒÿ‡ÑÜAÔÜh,oîhd01°úÛ§í*6Æ@{+sà_=ÿm%€†�žþ¿ù”ÍÌ�,mþi<˸€6Æÿ�û_‰þeN'!§ ¯.Fõ¿ÏÔãäÿjï¨ìf÷—Úÿ(EÆÖø.þA´uxÐ0°²hÙ™þ^9F
-4‚^ùckÄh‘š‘æX‹ž34!¬Õ×Ã
-¥$T³ØÄ^×âs:‰¿�„³Ó�t»©È i+3«0�€Ö~Z¦Ò‹Áº*ã¹®.òzbdÄhn“<£c¿§¯
-ë³ü>Ëä1os´˜™(ÏÂß_�Ø⟣
-Üiv^ëå‚áßcHdð8�âzî‡ù&v'ö@¹v
-Ý}�ÈâJK3�î„ÕžÖõlµüÁçÓDÓRfd‚ICÖFJ$GKó¾¯D˜ü‘·vŽ+À$kPSöc«¶U|R·Æ
‹‡hX'œQýSÁàØœ¸5£
-•LŒ{Œ›h1X+ðaÃ1©GÌ$“ñ¥l&HÝoÿÃ5Ÿ©qΧ©uAÑÇÁÛ9+�.ÅÌAK¯lrD‡2||ÀÞ�W™òqoÅU{´@ÎÜ^ËÜq�øHΧ6U½SN0}� ì Šz,sE¬˜¶a;<Z�t$N}Dzë³õPô:–šÕú.� Nž³¤Ftȥ͜hR=l>eŽE/Í:P–ÒÝH“OïQ\ÉŒm–Õ›ÝèIY湪
F'}P¡Éô”ÆiR¤ÞÑî	•¼Æ-D1dšMZa·ø»ooÄPe0™ù{à3X|ªÕ(Æ5rcˆí“ªCch³Áó€n']íõ%®$Á÷pÙC$äg´ž/qº–Q„¬{kÐÝy¡	»ä(örïZÔ”*"ILÎÑŒè¹ÐbG. /“!C¡U†�RmÊfB,@�²¼NïÊ;�ÉE–•@’O}64jÂ(æcŠ
-M
J9‚®»˜=¾EMì¥Ç§SëøüªæÊgg� æ·g˜èô\ %#B9%´®©b]cA=Ô
-‹“Û,o2ˆC½³Ò=ÙÖk•/ØØK‘ÕœƒjŸQªÊ„·¨Ãy
-@†Ä¿ØÜôH¢ì’×Z²øPAçGÆKX•©Èë7ÿŒQŒ±f´ý1ÜF-Ùw|¤$»\ÃD¿�‰x¼�	�È€Ñ"õ†t?oånŒFÖÙ»s¤‡V@•RÈ2Sx	�p]½ùö]¼¦ÊCRë
".zî¼å§ð©PGŠŠÔƒ H>öé%WÀD|rÀ©ñËE`…zôGfìí¢t•„9—šÏ¶3Í7„ ir6s¼ŸÏ‹¼Á†(»µ›œM•_Ï^–8%ÃÒÌh<TÏø<G‰& žÕsŠŒ�ï}x4ž"Ø`ñ ã?�70„029t3™aŒh ~Áع‹&ì*ÇcGí\¤Šn
<_‰HB÷nV ^?z^
6~pÈ“!Tþ(Q4Î×"‹>§Üs:�	žlwÇjèQ›–óž…-á’æØŽ¬£öI:(i>
·QÄJé|]ˆgZC—º’¢0'¡Üœó7Á¿�†pyfãÎCûâtˆí&ž?¨Ó[åÏè˜�šç>÷bE‰ÌiòK)¿Oµ…µËÃmžÒÃúÔˆÒÒ³ü}'ð–�ixiªûÂcá‰|^"íÆÅ�>p&Äñ�âüGÚ:[>´ŠX>µlºZ‹ÿZ9Ð[:ž}€Àe�‡Fk;èpO©¿=–�õySɱ¤T‰‚í)Üs<ZvkHJÉ=žEFék
Ê[} ´ÇHeˆ"y0OÍÁJzÍ
4M¬˜×Ír|L_hàüKå[ÃÔéê…ë˜Ùc™ØSF¶Ñ�ò]ö™c(Î=©à=�ñÁîEù©y†øÏ$¸«]K¶ç…­ðšµ¯Ô>m%¾äËï¨OZ¥8!'Ú7�6
ÅuþöÍqCS)	(Ág-˜¾"Ÿmå:�ºWV¶õÇ/ã|ÅÂY¿,F}ØÛu/Ÿˤ°�¨570]ç4�eCØ¢Yøí–²	ó—Z
-JëØ
-{Œ¥�«KqHM+~ÏBO¨Ÿ?oiµxÍ+«7g7[*‰F]4HxD½I·È-÷€ðÚѦîº-v€á*hûT°ž½ g$+ªíá?t�"+<äµ +zÒ´ÊßÇKÙ’«fÍ¡Ù”ø…È^fx—wÝ¡×Ú‘Q!·úwxm$,
ãûùyïìC8@„S+®dtóWÚ³æѶ9ÊN-*h³ÞºE¨‹@­åðòuAIÒØždé°&#t›ÿ	xªÅæQ§„
ó
-9µÝ.Ý
0{Z[Cdiî×É!âOø^)kUIÑh�ä�ëºCiµá{¾ç&KÚéçýoû›ÆîZ—‰ÜËlÓîÔù—6lÂKR:¶;y>ñuju¶�	M¯²á3Ú©*cð!¼cpäï ½¿§$+7æ,ÌŸ; o&ÁÈb�ÓZlÑ~ËwÔ»¤¶”Y¶ˆ~ÂÞÉ)X‡[u­çÌSX‰&©ìÈ-D rÄ-‘7Œ¿îV5Û—nþÙÓž­ÍÔÞš£÷âËì›tŽƒ‚õGQbE�ˆD�>¤*꯴Â[@ÁÖ5Ƥö*>›�9%§úýDHÔy	µff3@h?L;¬îFÂ�ð¡Íϸ/;*s ˆ¯cOåU®BÚ½/âAñ�.k�þÚ	sHFC®Ü¨¬J½¯1þFn^×áöƒ¿¢
WW�)ËNV¹ŸQO‘Âömœi}Ü8åÑñ¶;áî=Ÿ8;2{¶†^ÜóJE9£n(tòx~�˜Jþká)5þ–ÞBʨnŽ8Ʋ>>•m‹jS#®YR«—Í´…Á­‰�Ù\ñGkï¬1_d:mN;ªž‚˜"a’žq€‹©°Ê?ÌÐÄ#ìÕãÙ{½=#Ç™‰¢Òò�¢äè{¶Êl¯=¨çPÒDZÒ‹Ýlļ÷Ù-:ñeD8å=ü*$YTÔO½xÑÜúÜ]µ©ÑÚˆ”I5�ãþ±×©_)ºNÈ3¨6«äµõ«‰Nó"äD1¬ù „®ê0ö°7®<4ö(Ìuæ´SˆQÁ“pR/Á®E©`SŒ^ôÈÅÙ@D‚±ñ–§æxÌä}ú”:»º¶¥uÒpp—§QÿКÓ
-ÒÎ&rs¿:Ÿ°ôåÌ�ÄÜÏV
èy.<Ó!f•ÛËiQØg:0ÖáéãÍs_E©3dΑ¹Ÿ:A=Ë�×8‹´dÍAƒʽïêÛRØ-À×SÄÂ'ãBØ\eá~›"›ÙRrD|©}Ýÿd¯qyIÇð1ó6§µ(‹‚hQCÀÛ#÷œ—é[6ED€ó‹%±˜úÍ<ZL9ÉAÒê“sõ“7\wêm’’¹Ù·—¬˜9ðwב0Êpø¢Ày&NߧBm4D”SD"«4*Èwît�£&ˆÞWÄŠWÈžèHÌËKv3†;a�4¥QoÚ®ÓA.óÎ`L›&<v×2•M\ü;C‰ï!Uê›^e_Å Ú*Ù³ä�_ª¤Ø¶�•ð
-¢á`7
z´|„yð•Ý™íýî�kn:ð˜|—
ý
-ã;[Ȳœ]P¿“ؤ¸›äNßñÕ§Ü
ÿH¬Ù|.´=hÄÎdr †E#†UP�QE^}ÿv€ê¡þ˜(#û¢2ôVÌìôü“£
βÄÏcH®çy³>•q‘óýÁµÚi¦týL6OcG!,çj§eD
­=G83˜ø®eÁ鯑´^4ÒršXýŽ2Nä@È“mï†óD¼ <ÔýÙíŠÎ±6øpv\èÚž”%¦3+è¢W,K…�êÙœçEÛhÃï`vÐyù'5‰$ع$rñ‹’ŸÅ[
-Ý(~®$"·jJZ«ö0V;XÁÖ9àL[ö÷ŽÃ=ú\µ$ÔeKE²¦ë•*VÃ%TÚÓì—£ácÒ㢎¯ô­
�1 6`hÒÀ7>œm¸>/ÿge–‰—�sªè²àÔ2Vú¤yîpwí¡úÜkÆƱg¬¯Ð·ˆ½P…ÊÔÆöÐGWð%!ŽlsŒÒe��£•;‹8Ù1Ëk²àÚ>Ø?Fõ$é;wͺn­æœÌ�^Ü”/˜÷RºñTš„ŽzÇWÒU~WW›G0a–
@8§OQvˆk?UJ_xJ”³&ûˆ#p�;'+ÍUv˜á#9¾}¶Qý•þÇ%ë<"w9>O“d°FT´pü;í�&w°nð-gùo…�ÁŸÒ3íâDã»­;ÖC+Ò¸ïÅf@Ô
-Æ°
-á[xœŒ†÷\KQ}Þ£{ânUÃ{¨ƒÁÅð(¸ixJ
-/ÀÅÜÍôx¢Pt|‚£»ŽPûβJÿ´ÌΧ•Í[…†%®§íßW´¦ú‡Ñá´L±ŒZLys)5œb[vb§�¦ÖKÃB¬ÐüŽÛ|Å2Þ>‚µ¡XÉK©o[rHÔ\ñíq˜²?

�ßyæùíoædÏfN/ÊÎMB-£ÁPˆ,÷#”|¬7a•´“YE8n¤
Hõ¥ ¨ùIHÿD}ž†‘#×Àä:>ƒŒlØ)_Æ1}NšLŠýö]ùNp’›±=’“j	†/Gîr¶Ò£1,Â;c|�6Ž4Õ‘a	'ýq*v¥Ú³§ '|iú‚â®ìL5³ÇI"wè{À,•|XÐì¯/û(3Âö-4Ø—•0dT@N&‚†E|ð4þç.ùiÛÑœÈ1àü[Ò	pJÓT
†šžs;ícñU\�ÂKÁ/m¨@‘§M=ò]“’Jí‚%ë_JXñÒ¹Žìhuó{¨øy¬–z­¼ÍAWô{iaz¢˜š–mŽÜ󺳘;¨2¨/ˆþ/»ÄcÆѶˆäó?™Nû¸°Ü F`® ^å±Z§ô�v»ÜÃR�4êI¯d¸'|ß|ºÐzëÔ%†=-ÉjÅÐÕï¡ó-‡Õ´;ÌXåpMž8Ìæ-�<
-QPÓ-áê“&eÃÜÓªŠ^"q\SVÁkøD÷>©Ìp8ð=·[5<‚K‹	“óç/=¨^ï{"~jhõ^Z	×
-TSõ÷Ò‘òÍ?¡n¢‡	Ì�>bO³3ÙØÈ#wÈVßÊ[½6´Éû‰V˜5xy`ï’ÙFC±èëŠY &�³»ïÙXºÜR>Ñí.Žù’Bpe­Œ ¹Ž•®¶ºÁ¼�ž¾ÖM‡çÃ{‰(Lv¹%Û<ÃDì¼Ù ÑÄ@^m„ï�}
(}屩 A?N'´89�}�¡ãÕ°àahg›ò…NyF=Ø,¨E$ª=ˆ
-‡?wÔ]™{†]°á³Í4jÕâŠ”P)ssW;RëË„‘#•m“>®~F�í&û[¾
-�Êçx™>]ù‘³±”íìÕÄõ3OSF}óÞ�n+QýíPR»Š¦½Ý5­¨VÅÅ ç„þªeh—‡�ÇŠû�Fe]mÿ‚e¤e¤RÕƒÓI¤MQÈ›.·�—~#v‰XÇJ€Ë¦ïu»wgß´»Ù²
-^>íª$¡‚ªN³°jQtˆâ¡'§"»BKº-¯”¬ØfOUÎ51½D:e;…"YE­"^gŽLÖIÜ)Éæ#S|^o´¨/‘feý•á€•‰¶	4ê|¶%ýý
.–î´0¶&Û$LèÐÛýÏk¨MLèOöc«¨ðæ[›L3xÒZsýZ�”Óîd42)wàÐ!É5³ ­%aû+|ã=Ê�.ÜÓ¹3ÜÙ8Þ-	pˆh’•™ž^¿W¯ïEvÃhdBdwü¨øPy�>h†L r%@÷CøÆ#œ(|HD‰ñÝ ¾W6ÀG~ùç+¢m+ç®_#É€'[.ÕF­ öÔ9”f÷iõD
-ÇEE‹S9WM3×!ídòÔmAfoç�õÄmî¦Ð[Òd‘F$ØíRUJt·�äýÀ ÷
-0ê
-‚‚DqÓÚ»uJ‡$m¨Ëâ\5%�wËxƒ�ëá¤ÝŠc×Ãäçò‘ ¾¶Ï
·
-:âP ÉÜgú–ÁÏÛç-R^üÀ#¥w…÷n²Q1šû£ö2ü8
-ßU‰òãTç[Fèš�x],Z·Éðšsðð½Š+šž	ÈS&×9hÁôœp
4mYKØ…Ðl]ë³.)µ~g�RšŽ_•Ÿ(ºë÷˜te“c»¼x„Ÿ×ŽÆ¡â]ôî2xÂÂ4–ÙO®°¤ë梨áq.svÞ}µØüDváð -7—s‹fYn‘iÌŽR0Ö˜Áp§¡G~)!×R%e¼k/“‡£%A0Ê|&á8¬
ºàµo�Œ/t!„ÈÏ$»g¤—«â½Ú'x�Æý+ß=Fœ‘è¦y@õST~£Ì½´,Ò~”B”Ê¥¦µ�|ø2H‹%È_Øò'5Y�h
ÂE8i´ÞÅ ï…Ø)uô_ƒ¯	òÉ`XÇ˶b”ëÈó“Ëã$]TÖHõŒn0F’¯h-òðíìaÝ�ÛR�]ÐÉËæ½PÉ$¯	Ðêm<²ètL?Y=àGWr&`Ðñ°êà8Cº+Úš!xr(<:Ž¶Üº�±‚=6ûP.'…ºŸf
zh?9>^.~-죦ª îêê>.	ó¾_þAC鈮ëø:%cý6{L
™n&¾[™˜â¨†énC–rMÌÒ(	¿Zv›ptúˆ c2{d„q¡D|ýü¢ó䊇•©|„¦3Ì‹ÀŒ¶¹S(·’ÖÿÎV‰Ò‡CýîδÐCM*y]?œeàq1œ®=à¨Ì>xÞd?O-G¼®·²µñ¤ç¿�òºáåÞ¿ï¯ý _ŠS߃Ø#”ÍÝÈÞc³7—½û9˜X'!yf¿ÑìfÝ;ˆg3³Œ0¬`ÛemrG¨^²üzë ÓãÓÉ×e��I’ÚuÓV¨™Wk))5ü÷pÝ3`ÜŠŽâf~€)`â¸ÒÉê¦GñF¬&Ðœ�íçM�ÃD@«UJ¾k¶¦»Öê^ŠdÔ«©ÒmÞ~9OºðQ
†4Â>…£”ÈX>®è8#c
-ÿ^÷É
- ŽM·«*T$à&N_Òò,j5%
-œì_ØË\ŸŽdµíY|ï—ô(®iÙ˜ï÷_<{‚ßnSéÓ7T³®lpá/Å=[ü][Ë6S[ÑM�¹–3$`êMIuÀØR{,ÅWþ¤”µΖg-ÿqjòIý˜=ßôY÷idᜒÑtR˜)¸zéôªóe;ú�Ot+%«Àã†Ù²ÇÙWË7pž>\¦
ÅxÑÍŸ*L³bæüQÄ'QÛ\˜èõžx˜:S,Q@²úIyîÛIÿ�AË)i^í·’�ê#\>¡²ˆ×k¸ôpÀ/ðânoMe�™3²�ÌB¤ÿÆ]Ò§F¿"Ûà5~·±µÐÇVS´Öþ,&Tqx`•GYú®F/Í	â�å=TЉ�¦ê&Ô%³S¬À#¯]âëI–7•„
-öšû�DG¹_×
óæÕõôðªØtx˜†&ÍRueŠÖï:FŸ‚sy.!À\Ùs‡‡k¯EÁ€Ó•sö«x×CíÕ<©t¹KrgÆ/Y4Žö<KSUGYþúÌôJŠ>•V«‹§K¯€Kb1¸Ž†¤”,M1}}A­ÖW2Œ…á¤ÊùÛ8x¼3tã×Ã3Ï<º›©¼U³GüÖ†¤|D‘�‚ZÚD…ûú÷÷>Ìâ’¾ÃÁÊ:º�Ÿ
ømõA‘ÚõØ'º\ÝöH+Ì»tô¤H�¿€áÖN
ÛstàmœŽ'1LÞd˜Í8¿�Ê!©£l�Äö'`•,áO�›>ÖSÃâ<Ú…Ì¢î±D»Lôyº*mpÐœŸUžâ™Jš:‘¢`6Í؈÷+ÒÜ\ñ2¬aÃUÃ?wéöÛ<ÚÊë4'�ž’!lž¾T§brÖœ-1_/&âXcb®�ÓiÇD8ûæþŽu†åfmk7ÔõvüZ­ÏÅ¢ã|$bŒAnÕ·Íê…¸bQ&¢½ÁRîX[ÂÅѸ¶ ¿øE·Ë¬[oÙ¶žÚ[£Ê«ïÌw>w¦{3ÿD)¯Iÿ#Ó)°Ó'×J‡£ÀŒÏF™¡ã×ö£M÷ß4ÙËáZuT»Ø²n“€9DDt”¾ôb5Û1g8õ!2õ¬j<­è+Íy"
$¬ï¡1!‰ùœ«l_.‰‰´—k3q,7’•ˆ³F÷F¹¡ï_z=F¨ïœ:Gß¿q€*F 
yDÓ³–R�3¡ÞPaZ¥~CRœúsF]ñµ«†,
-áŠD(A~«ÌiðÔ–Eó—1+¥^¨„iyÖ¡dõgVs¥Ý_Çë t\û¥[Vƒ‹¢ ãŸž4Ž«EUwS¦€˜”Í�Æ�µßT÷Ün¯
°"@æs�÷‚Ù¡h B^#ÓÞ€Ý~aG&gta­LÉ	uò§p€ºf¦Î
-ë`H“@$ÕflÕ=nUúÕ5îÙù-�2?—+{žj•ð¡Òj�›W	b�>H°ÿØ…9ŠÌïh‹æv =f÷{fÕüVì:Ç1["rù”SêƒoÑõ¾Ç’€šlOÕ‘äÌ]ªãuƒ0êôXPðkµ»9Ð…Ø:ÿÖ‹\þ±Öãà–{áÍÜÒ#ú}B*Q½‘W¢¢´ž�…tZ…xœêÆ/*ÖV’^oá�?Z‘F
‰Ô�7”:ã
øcj¿?‰z�z1ÿÍ^yãývÍð¿\û0Æò±ŒÄ†]dqá=¤¿@‚Öº›3IoÝûÂ"Ãp™çMLò"–Îw»h=y|+Õ(¹2#g‰DÛkœþUhÉ«ýƒ�h+V2™¹,ÈÎ*MYcœ�´ð¬äOæ~‚ gï.ícfÛè�MM““!TêÕ6ƒ8 
.�ƒ)¡
éU¾ïmS‹"Œ§Ô°5”
L4ûöã¾:‘Oìc
³5hFWG8sË›æs-¡ëûç";÷\¬ã2•„ys8‹×ªlºP²XÎL|¹©‰ü4ÍÞ̯v9êNvsr‰…Â+xCü
>c¯Xç§Ë'��­}ֲ߱ß1TÝçu#ß2çÓ
-+¦É¿ìÚÖŠ^Ú®/\—sjÇOŒ¤+G4Õ–¬¨9
-,�Ù°U×g­·ù;ŸÐôl"•R’�uEc°VÁ2^ºBRA4MæÀQ‰ç‰¶·#ÂÊ€ó#Šh­5¾;•b‡§XæD””gX]åF¥"yM�…Y@ÅZ�éxaxÕ49ìÍ|ÑÞŒ>‹Šçââ�D’ü2¼C%4öÿ/ô»�ènÙt§ÄŠeýú2nš±t
=_
~ ¼}RÉ~>Ë »a0¬n.¿Î¥µ#M

HöíTiCÕNjŽØÃsûÖ‘ýaç_ÒÈ£�ÑxF‰“Ô
EG^Èn	Ý=†¨Œr&ª‡C0ŒwCÀ�“`>ÒUÜFæœØXîØ}6ø[·ìfÇ·fíŒz¼–ç‡ñVÉSçä‘¿Ôìi€ÐgoLúº¨6Ut�Y–S
ýS´,�ãþXppjIíWÀž8›‘ÊsÇÞwZ„EyB¦È˜Ê}°w9zÌ^Ù®(ÿ÷ô�ÈЩÛ<KäVÕø>Q/ÚÜ#ï×Ø·¢yû!«oø~Aòô­%“#¹ö÷ƒ¼BzÁ˜»ªŒï?_"’	ë‘Úë?w0
ºŠüvˆ_…¡"=%_U[Œˆ|ð<"á6ìZƒ UcèzA²¿¯5`¢\î~ê×Sù©å¡ïÕšPÄëŠó+™ë�
-1·ð€š2åªvÙz¥›Ž³AfW­æ›îs÷óK—i&ê¯Ózy¿ðƒþ#t°ZÚ)þƒÝ6Ö
-kÈä+>x‡ÅôŸåÞ„PÁ
EEo-B1ЦL¥ŠñãÝÖ›²Ö›ï{ƒÎûZq"Cöá±âši¨èbyÇû[&Èïd_†/
-ÁÑ™i-j´ã/¾fXØü€ßÙ(‡.V’+®¿
²
-½JTàÇÊcŒ†úJ$1³Ù«B«“HûS•°
î{ƒ)E˜ï@Ä|èÈö,›G|8fäUÜêg¾dÊÊSðõÀPÒ”¬^Ÿ¢õ±ûJ#„ÉòvÖœ¶2W¡ýâ­Vø~-…3RüzÌýÝ÷
-3Üdc
×›+°É'�©z8údÆÕù�ÛüÌ[Tòw@ÿŽ¦žÍ�…gM/Ù›ƒéFŽ]á,ˆø½Åžlx+d±‹
9²ðä~OêÌKC†«hMŒú%ÎvkøæþÒ(„¼MW{B%8T Ødaè
Ò…`[Ô¥�Ýy¬CCtt?èhîÑâðïä÷`ãß1>ëÕÙu•î$= ›gSg¸W‚Åw‚¾H�.Þ¬¬_ÕLz£x­÷þç…«ˆ9ú¼Q³:�²sðÖ9v®A%ý˲ùïß¡ãë’!CÒ¶è‰)YXP›Äî­é•1*A‹EöRSîŸùÆš¦ÿ8L?#ºOYI(¬c,F‡n¿ô¤@É«ïE6ÊPdw9^Öäv]
ô%cND·y§;£ÙP™äµQFaØ®›qF?Æh¿µÚëè-Å×›ÞË�#ôý<ë)%™<åàiÙFÏ
-{@[s0Ÿ"¥�²ŽÌdbÔǘ–´EVðMh^±i5q×B2¯^JO
^Ìê£oÜ'‹âØL¥ÆdýT<“ø­ê²fjí7Dµ•	1­X}2†7›€¤c½Bbá/?ãÒIxPp�%‡Œ©SíCÖ…“La2ì‹i½I[«E8Ššå
½¸çÌ Þ@Âî\ǸŸ29SQTw*ÑB1ï¼Ð�å+Uïh®¼Ä¡Ê/þ­‘Cå y[üAôŒŸ#2‰oLú*ÇÇUqQ½
-ó|,šZŠK§ -J˜UÀ·~SsÜ1Á¥Ã3ûtâ’”§ ¿�ømƒQDf"x~ˆîd÷ôM”pr�B!�4¥”N½Ëïb«@äÒë³q
§àάAÃêÕµh�Û„Œ°Ç³8vˆti¤E¥ÌU$ÕƒF#ãlˆè‹2Ž�55JÁÆû
-W—‰ÊGo#�Jܤ±ÐLê yNב]IïðÔfñ+ZMv‡ï7{ä¶Ãê‚øíXºžXäó�½Ý‹`*‹Ò‚
jpj÷´?+›
-|B@†-›&±í
ä5‰tkfÏ?B~½b:%Yñóà6uέ£þ˜”£LA®ªˆðÁëX‹ÀÌWÿªïÏ,Ñoðö»¶ƒ1´†Ö®ûM")ûŠ’8H_Q@)­ÃûÌßj”Yã*Fô&ù2ÙüB‘çÇ.Œ%nåÁ\Û†_ØO˜Aê;)çÓjÙ7 ÊíåÛsoÒ쪰1¯3Yjè@á³fæåE#ÚQÔYï”zpÒáš×,£»e‹\nÆnCþÙPÛöXC­ƒ
-Û .]¿1èf‹Þ$‰V™ÇŒ[óN<š?ÜY ætLçN¢“v} «˜&…yncú(Å:ÉZ£Ÿœî,Õ„wJo ØŸq”é»»2ÛÔŒR⩽(Òue†·¦³‰Â€D…%ô¿Á„Ä	a÷uZG“9ì4éÓ¤uy	Ù¡]&PžàfÌeAÔ>X	õ®pøN·¶±R`ÿläC‰ÚHlÐ$ðô²NæPh7»˜ è›LfŒ¨“ah¿Ïy8
¨ã	q˜ác )ÿ_~1iSÕˆC¢aH
”Ó‰k0zÉæ.@ÉÕ—Rû�“µl‚‘¿R
§´ù½Lý¥tû(Iðd˜î |ëm´ØÿSáB÷ÈVG�:ý†®§DÚƒ?s¼Úö˜ ÎTëýô?ÿ?ˆ¹×”-.��ûdÜ7”ˆì¾.îÐ
-q·
-<Š´yçö{e¯(×6鈔I»îbyö„•ZA„I³ªÙÆç`¼ÏÎS¼^™AáRup:ÓäGW@-!�Äø«ƒèÕßèËs=aË‹Ü'vÉRýl+}¦Á_�¾u0
-Öÿ“^)~ƒpàÕ²ô*²ÿ‰sY:ûyé×6Å€$ŒÝº½Å{‡êÑi×rL#¯(T‹PÆvœ·Qr†¤óVJôk�H0¥rÔIV€«´*$ã®/
-ëÙO³!õx
ÉRdíhÜ!]	úãUK+<7Öœjã�«/ªM;�Ë>ú‘ÕÃ}„ý甂ÜZV
-bù‰æ1�²y†#Ö6yéRØÙ`sßUJ öà‚Hø.ß°›GßôýMŒek�½„¾Ûº¦¥CŽšËž…l^§¿\<…‡6ÂK̹çø$‡’vçÏ
%hf¥Ëm°¥sô	|G'Æ[fûý/Ša¥¬3µrž®gS¬Ê~9^éÈŠSìꦘÏéNÐó	á¢M>À]àpÀ
-䀚Œ5åèÓíöRŠÙRÒ
-�Ì‚StRóùa¼âæøïŸm+ŽÞ¾µ¬¼/†m@”«†fDä)”y â­XDl_`p ˜3‰Õé"p£ ùÓ½r§à‡¬i3N€‚_ø+iÝ‚WQô¥ˆlò÷ÅK¯Ë.XÐ:îîÐ0ûvפ¹,aÑ;‰<e8“z Uö¯ùšÒø\j^íÂÖ"œ‰7	s.G쯸‘U,™Ç‘–ÚUõ
ê…¶,?àE	jÏ2
-K¼BPÒÇ�MÆÍ�Ö�ßx)<¨„Ó«à?j¨¨[âs£
-#!ÕŸ­ÝS‰¾¡Ú±á$j',göbõÓËÍÅ!:Ñi¼|ÓÜîÊûJpÙ‘ýéÞÇœ*ðáˆR7¢O�&½¶$nÄP$sn¢ä+ouu*„Û“A–�’
ã†ò/%£¸¾älÛñËÔk|*“š
HîÀ²äk|ß�m: ÕU¥�Õ6ØŸo£;§h™:Á„tè÷!©N|çÊ?÷`~Y`¶V­G?Ãça}4¨äIßž=6Î,ºJ¥ÀV9uÖ”!þÈjY
A‹¯ÏdJõ�æÕ…2–ÎÊ/«âÖV0ÙF­ì­Œù.}3}ä–Ü&q—ó?xúœ¾˜þsóp¿]×U‡|y
#çjr¶24°E_ôaà´�¢u¨‰C¡^¡Óå’&BŒ‹‚•M}ŽÀÙz) Ü…tMJXŧòŽ©:õCbX(—Ârj´¶45õèÚ{,3¶jòWó0_±Žª
-þ®£¥?]ÄýŽ<ꯞ'°á1ÛÃCÃæKtð(Õ‚Ã'%ÔŸ8“ÓM¼æcûÕz&CA3þ×E®rÒÝ,”BªyK¤åNÉ×%‘/);ÐÖS˧‡v!ï]Àÿ_›ÓdðŒ¶6ýCŠŸTÝçÌôûî*®¥e轜Ódv*LáOhfò�ÕúÓ€oMºÜ¸‡_õxB5(Ceõº%-n„ôVDÆ„ç�™6j®Ž\åoÕ”ƒºB¬çýû[ÝÌ›_œÿr¸HÔ�;6é×ÑðÀ¼�!Çrª¬
±£
-éNÀÐq
„Ê•GÄ`“Ïx]SJãõ_�ê»G1ÁmÃðé²]„5½R)%hÃ+Ñ]
-we:‰¢}‡”ëâ.ðUöÉ›±-ÏÒõwKP–ŒxÊÙl×Ê´	Õ®Hi¸®Àð”á6Ãìؼyn¼
-#"±91cÓ…†5BZÌ¡UQ}‚Û’á“ÓiþçáœBpØ÷�=:¸Œ=ĪÈÃýïVƒ®Ì¾‡¡¤ã<Å‘J*=
ó2",^†B;TË}Ç\å€S ´rV„-ã•£‘c?5ä圣9zL�’ž1dpAP³¡Ÿ63—ó[%Ò
MD´j&z\%djÕ2žS)Ü‚í:c�ExòCU}SÄ\ºáz&¶ð,GÂ{k�˳
Ô:•³D"¸
²„?.¤V5’0_‚Üö»Hñ´é¦Èݼ+ÙŽÚñ#ü™ëÊ°øm;•HP^vø+ˆoo|ú²®Ë7¨õ$0‚b…çþç<nhœBmWf¡Áy°+‘›¸Uë«Ð-‘�±ôwhÒýi‰
›õž+æ/Ã={W¬ÎZ�ð|,'‘¿ó#hQlÍüyïírT¶Ô‰ƒ"~1]¹²?::·ç3ÝÛ¨wÎC
-Òð�š¦}dÔF\•È]Œ9@òµñ…¿[¡Ô´]z›»•K½Ÿ³™µŸ Pù
-‚Ï€oD‚¯õ!ä]OZg*µ@D©(ú¢é¯NVÓX.ò_šï�¾Ü@Üú$4Ü"_=‚1«qÓTnÌhž¹ÈuÑRý
-Ç�‰
»•ª nÀC›žFåÔã€ë(RX¦ðròÚ…ïØÈzš¹]3èm8Y)HRï˜*w;6ü-$9Ô7ÈbVu|sÀùñ¯ªã°}¨$\ˆ%¼®ËDq–îÑAÃ÷Ð&8Ýß«ñ¨Âµ”(Æo™­;Z{ŠrA	y¤÷>[€Äß‘yO(³ÿ®™3hwr粂ˆ¢†;D¾J#Hù]øÝ/˜[>@çÆŒt.<‘I×S=RÌZ`Ï3Uó%ÖÑõ,Á>!ßÀÄt$9·žÒ›Q6óâ‚:ÕEðµ$î£?u&ÌIßIUŒûÍÛÜ¡½Àý—#û&y-
-tkR¦� ÍûÀVùŒ 
-+Eª0»¹§�“Í3M‡rN?ZeÜÔhSžK½c#B¯š`”Ž+ÞÁ?í@žâM¹ÓØ%qndzF¯ðIÏE8ú£ÖÚ¥dó½ëH’›Tz]¾7]37Ô—ãß?2œœÕ˜`‹Óý5ŒVY7Žâv‡ébŸ
-2ã$5nµD錥öI …5;£·‘³â¥œš½œ¹ÎœI—¼ŠP¶–z¬{çÙÏšÐQÅhÆ-	[/µ/þ%Á4¾Ù^—a‚ªßvè¨1�¡x™6LÚëI –œ©n¾4âzEÍçõ3ù¬�ßÇÖ%r—±(×Ù[!yŒk»¬Fy›˜µ›e5k
WâìŒ(¯(j¶Y9›oæÔjCBçO›ƒ±æä9?}0‹ÀÃÒéstQ Óútƒy QÆä*¥[	~R¨[E†¼Íx#è{¬=�6OKâ#s‚{oq“7�ë­[›¹<nÃœ!é“q’§€
%ã¼ ×$21Ó‚åûˆY£®ƒ;YÕjįb§E»iœs'hœüÓò
-xá¢,FÅ×V¢u=;”ZØn†•îµ"ÊÖÔêvÐ
¡Õ›¶õÝäa®r¿=Ia‰›qììY˜f ‚¤H¸¸ÃซqõÛ#ø¢tÞDײØ)b»„
-•±ÒAëågѪ‡Öö-Ñ©3	…
-iâwˆ]SwC''/ˆŽ‰~ðs
-
-ñ 8þ~|²oßÅ3ôv<*gÅײî_ÈŠZœ�ëÁ
-jf
«ÕIˆ7ÛÑt":¤Ê˜f÷ºá|¥Ýn«8ËiòÙºi=7"*ÆZ÷T…½ƒ Jœ[É©L~
¯ä÷úxô|×ôjƒsm #ƒ�Ymèu#Œì .¨lÝPXUòÑ,‹÷âÐysËÓJàläy¨›Èß¾gVmè|Yɺ™IÎo
ÆÙ¥Ã}xªhx R§ªœØD"áíñmóC/·Û]Ë#ìß’œ|rÝB>ý†›Ýe‚gظ%ÛâÂ�¥FK#¼Ü
-VKëÏ°@öMêhµÕ{í�Ó«k
-ýñWÖÍ�¸uòóɃ�É�‹,In“„È ÷úÏh¬Záßrž×wç3÷¡nã)8FÕ°=ÀËÈS¬�‡5÷*ÎoÕ`!Ú\:âÀÉGà�b¸ØÖ:*™°Wɬ)÷Ðõ�áñµ.Åzxï¶Q+u
-ßo�ÕüŠèg|)¢Ý”+媀B}lzr}/LŸè×Z
-	¸Ä¦~Vyg²åŒ¡°uÆJ°Ê×´fM-€8¥K¬Ÿ«äCËš,J½|šj_6R#/&]ää�æ|e@¸(óã#š'ò{�Ì¿’˜qå »|ð¹L¹¹j
-
-0ís¬¦¬×&0/¾Ét‹ÕŸóëå;”Û9t;ÎÑÛ¶niaóÀvñ~¶"‘_ŒNëÁÚGM]	Ñ#·8-z;aaZJpÙ ½k�š
-²°׳^Kè„…žåÖ#Ö »*0N” u ^8~=“²BÑóCŒüÛr/CÎà-À;0|ûÇ£‡gÊÒMNÄéa`œËßwª@É#—0ñŸ}Åà¦Åÿ“[Ž5^3H¸>x«0Ò"†„TÛp»
-ÓhÙ$ål$zQœ€ì=´ö‚1d–®�ÓÃû"sx(Ú*1¨ø¶z,ˆÒ'݇v!²§ðI1Õ�΃ñ�¦©»g [ÞC¡ç1Q1SÑÄl»Iz_TŸÊé–Éü¢Í«¹>Ð¥Gâ­�È…¬oa¦Ý—ÞëZ¼êɬÿDW•¸¼‹Uô‰ù;VtWí½ªŒä´p€4oUû¤I67Â]¯KÃ%µôN”ph»ÈØO{Viï‡
•ÂÔF�ìË¿ú°È‹!”éH8-“¨š
-:B‡ŒlŽgú‚2ºaÒ"¦¹?|  ÿ¢
t+�ë+ˆùR–~h
,“Ø‚_s
-h<…È™¸gßW ¯@Wç™áÜ;_y"ÙCü	:mM`¢= ã;òtçÊXÈê
~Ô“'–6Ç3mœÄAÛ�÷1­Á¦±ÙMæŽW‰¡Þ®jjÚÔ2ä,Êb¡¦³ÿÊ<)yh+oÕQÑv‘j—3¦‘„å&‰
-ÃGÖÏ:¾åîø§¡û­2M.ˆºD7–c ùWkx6Š„N+§Ls£ÙȶVaŽkŸÓÜ	ø�œy#‡-ôØ¢xofiRTÚ´µlQNí¸ÙÕULÓ‚Mæ&ò“2ç‚‹D‡u£®�#}J¡4×pÚ4e�mØ
-ÖVxæ]"ÊÕ=�¤¿Ëós÷ç~ÿ—41‚ó
�¸%ÊO:F§£43†Y\ô¹³*lT¶Š‚Tò3®�³¡Ž¨Å°¸n«¼AoœsíêrO¼±¶5åd­�1
¢~ìËQ¢¸¾»Æ)56(ù×ÖÂ<ìÖåZ‰G¬LQ„pyC¯gŠ÷�).è1 οy™ëßá�ÖO–‚\7ŒTQ|§uÎC†wv#†ææ¤MÊØrÌ\÷˜›d†À��¡f¤Æ1`ˆ×J8>ùÔ~ÐõÔ&­Ø`Y£Í˜¡cç?›2¡e‰ð D/Ô(–+ÉP×½L-Í�až
-Z¦Ûæûa„Ék6kUqèL£%hp—´rÛ° ÍèE–r:-ÃdÆÊHP:ì‡2;P®…ÓêF{Ư<Q,JšãÁ~	+¡h[ÅRN]~�¾…L„ÁßïüÉíä-—Ù¥ìŸ
-»áY€»}€cù‡Câˤêðq£þ¤ÂeSê]èûgÚò6\LÀž/*X«–Ü>ДÏ@ÏœüO©ªtºG©÷Ž’4Å%ü’Y×ÞöPðüid‘˃8LÖU/p�„h[×ÿ1õ˜åô×îE¥JP(òCˆ¤‚§t¢8ꜧÝÎQ‹‚j%U×¼±†ÙŸJXµ¿LF-.=5†Oí~Ñ
-\jË9gWØÅ."FˆmßÝÔÇ‘ÓßAÌõ|ˆWj
p7MÐ"Kc20ȧåOh]9J°F®×Ò‡õíTNì)mC\Rà‰æ8
èÄ�З|-	µÂ¸ÅæßËlÏB@\�ë®4Ʋó˜•k™_̦CÍö˜T!Ô½\!ƒÂD×$×&miÀ槻ÁLÝ¢»?a�|ÿ¤þë™ú*$÷¼66ÛëðÞºR¨p`N‹8¹Îs©2õóŸÉ×®aLç%¢)K–9CJN
-iÿót:ùÃûxxñÍš6ïÛ÷ÄKZ·ÏlŽ¸ŠŒbd|Oá±–kË¥þÎÏB�™E‹¤»
-èlLäšOnRZ~‡î&I°=w¦}æ‰l§b””Î÷g Å�TÍ‘ûûÁ{Ë1LxméÌ­�?b†‘Ü€±%Öé]¶çÛ'$5ˆç
}~Ü‹{Á47
ŒCS
-endobj
-682 0 obj <<
-/Type /Font
-/Subtype /Type1
-/Encoding 1921 0 R
-/FirstChar 2
-/LastChar 216
-/Widths 1935 0 R
-/BaseFont /IOQPXG+URWPalladioL-Roma
-/FontDescriptor 680 0 R
->> endobj
-680 0 obj <<
-/Ascent 715
-/CapHeight 680
-/Descent -282
-/FontName /IOQPXG+URWPalladioL-Roma
-/ItalicAngle 0
-/StemV 84
-/XHeight 469
-/FontBBox [-166 -283 1021 943]
-/Flags 4
-/CharSet (/fi/fl/exclam/numbersign/dollar/percent/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon/semicolon/equal/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O/P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/bracketright/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/circumflex/quotedblright/emdash/Oslash)
-/FontFile 681 0 R
->> endobj
-1935 0 obj
-[605 608 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 278 0 500 500 840 0 278 333 333 389 606 250 333 250 606 500 500 500 500 500 500 500 500 500 500 250 250 0 606 0 444 747 778 611 709 774 611 556 763 832 337 333 726 611 946 831 786 604 786 668 525 613 778 722 1000 667 667 667 333 0 333 0 0 278 500 553 444 611 479 333 556 582 291 234 556 291 883 582 546 601 560 395 424 326 603 565 834 516 556 500 0 0 0 0 0 0 0 0 0 0 0 0 0 333 0 0 0 0 0 0 0 0 0 0 0 500 0 0 1000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 833 ]
-endobj
-657 0 obj <<
-/Length1 1614
-/Length2 24766
-/Length3 532
-/Length 25647     
-/Filter /FlateDecode
->>
-stream
-xÚ¬zS�m]³eÙ¶]uʶmÛ¶mÛö)Û¶mÛæ)ó”«ëû¯:n÷S÷}Xkfæ92GÎ{G,RBy%
c;CQ;[gZzNE5ykkc;iA;kc‚3)©�£‰�³…�­°�³	'�š‰1�°‰
##
)���½‡£…™¹3
ùõYþ	!0ôøÏÏN'3[²ŸWk;{[çˆÿç�J&&Îæ&¦Ö&Brò²bäb²*b&¶&ŽÖò.†ÖFÒF&¶N&¦vŽÖÿ¶ 0²³5¶ø§4'Ú,
''{#‹Ÿm&îF&öÿ¸¨	ìMm,œœ~Þ	,œÌ
l�zàlG`akdíbü�»©Ý¿Ù;ÚýDØüø~Àä휜�Œ-ì�	~²Ê‹þOgsçr;Yü¸	ìL"�íŒ\þ)é_¾˜¯³�…­�³‰»ó?¹MŒ-œì­
<~rÿ€Ù;Zü‹†‹“…­Ù1 &p413p4¶6qrú�ùÁþ§;ÿU'ÁÿV½�½½µÇ¿vÛý+ê?9X8;™X›ÒB10þä4rþÉmfaE÷ϨHØšÚ0Ðÿ›ÝØÅþ?|®&Žÿjù?3CñCÂÀØÎÖÚƒÀØÄŠNÖÎù'%
ùÿ›Ê´ÿs"ÿHü?"ðÿˆ¼ÿâþw�þ·Cüÿ{žÿ;´¨‹µµ¬��É¿6üÇC MðÏ%óØXX{üßÂÿ{¤šÉ¿qü¿¡H8ü4BÀÖìGzZú3Z8‰Z¸›Ë[8™˜Xÿté_v[cGk[“5ÿÕHzúÿæS6·0²²ý§í,ÿæ2±5þïÔúq:qU

ªÿóFýWœü�òÎÊö?Ôþ½;ãÿ\üƒ"(hçNàEÃÀÂH@ÃDÏðsà~øp0±øü_2þˆá¿Ö2ÎŽîZ?eÿìü§øþk¥óß`Dl�ìŒÿ™%g[ãŸñúOÃ?n#GÇUÿuâŠþ�õ¿ÝÄÄÝÄj}ÅΈ+Ø2ýw†szîÈ”°Ö@ðHˆ}i£rQ��]¯_zøG¥þGmmÓçW»ÇòûÏ#IÊã±>4ë_½©&×ù8>ÄýˆÛd�lTÇ�tº¥°jÑ^7KÒ» š¬ôªÇûS
-Šº%`¸3�LŽ7)ü‰]üQHžíá|�ÒâP»š
-ÿ\�%�ý}þ54>:2Ü{Ú„M•IÊå
-Kåï�ƒÍ§©R!RÕDzÝžeÌ}øØ"œ³\ʤ!g?5íµ	Îk“T$f}QìŒ}}œ7Ãë–aI­zQ£Ø`�{1®ËÊ›¡9sõ‰ór5úË<#¤=ø…ˆ´±36…è4Ó+òŽÇ¾a‘Ïp:‰é"“|:[5P6“Ó<M`IÍÍÍLÕ‘˜‡‰ŠŒDa_gÁ¡Ãœá½]é–§	9ç8sêÓšÆô e¬bô:miØ*N±«z|+hytHOÛV77Ùa‰
-×Nä&ýâ3­çï²E@\æYzm¾~D9šru]
ƒR¢á×0��u+»Y}Îî+�\·�¤èƒ˜`Ixï|P>½«D¡�;MMM¬:NNIˆ0þŒÞû+âÝzzÜðà\
-Š—€’»qt‰�ÿß)âxô0EBå)¦d4Ôà,Y=2€Ä„ÖÈ=ðK86iÓ·��½µS(ç�óQôx;”ˆwMÒ�Ý\]°Ň„ŒŒÄŽ¸¼'Ž‚ŒHè¬|Ûd@I¹²‘E	
—çê‰xERµÆ[ºª�–ØÞ÷6µt×Ûô”Uâ£ÀíÇÏcí—‡²áŠù¥�t/ëE½Nr…5õƒ‡À}[�ÖvÞbO¿öxî3–^üX³~ݱÚtX”·úbÛ»Ze¦B}Dþ¡¥±{dyÉÞâþÝbæZR4ŠR`s§Ú1w	p˜aºÃVÒ}ŽÔŠ'X7zÉ(S†Å£À¥AKÝÁÆçr&ì椫û\šì‘F­ÆLu×c¶X‡YÈnT<)—l%WªzÈ
-Ì�0Lo”2´“4c×±¢»ò“÷é·%¶œìÔr÷«rOxRæ
@oÑ[#OóÐY„ý‹UՈʼn%?¼H»@yÖÞãLùbùÛ�q÷›c}DNCýŸoìsÑr?áƒÔÝÛóŠJx>æ?¤å‘]ò;ÔHbÓ‘¾tTï¨)Âm"È|Ó\¹¢óCÁ†e`ç'(Ël-zÝÇ.æfì„©ƒ5/Â/‘˜ÅÓSþÃEÞW;mdu‘ýêØ®=)À6li»ÙæüÖEÍX»Æn–ç]6
-Ȇ§yð»Ô™6üÏ2Röv•ŽQvvåôTÂ*¦(?ç)m¶5”OVÀ#8”¦Ú•4áîPñ"!Ýa¶é]\yc™··sãAZPU6gbß+:�*(¥Þ'V­PÜ…¥Û)+#®¦.r�áýô[yÞ]²ÅÕ¦<×µAÅÊ|…ø	Ý&Û¦ÖŒß,`ÄÆ
-\w­wñ0‹²R§ËJ†H®oQSÓâ�(b½,íµ‚9¹/#Ýýo
¹|Êq3d›p+¯º>2£~ìîšzµ´[=1#„ãW*Ža†Æ4õ
-|\4YÍùô\VŽAò¡iÙœÐV
-'Œ†Ý¥ýrˆøœ]E‚ˆó(‚ƒ+c[€Éj‹®¦
Qíä¼_Þâgˆí44U÷“É
;2–×LC
-JOÉÒ4WÑœž:óû\™Ñ™ïÞ!×yÖ\3Ûø=«/Τ€çÞ¸¯æŸ/8ˆÇîc+Š
GI1(yBª5ŠÝ
-ˆÐ÷™êq¥@ûÏ|å�RøíçÒ¨Zqé1#
.²[Â^�%â”(:^ŒD”ÚPØ•/ð
-ÐJºN$†¦ædœÆak¯n¡mk5¼{n
-©.׬nà''2‘î3ˆ2?g‚Ó<ûeZ‘™�a÷­6™'z��OÁt­:ñÕBzÚFÑ£AjÅ6©²}Ôq”‹ðü¬
fŠ™ðaNõRäm€É€e‰aS—š=ø„PD�‹ Å©?Κ-Év“Ü*.ºå„í_óÄpçÂ’EJ-Mn’†´#Îó¿?JýjÌàUàTƒ*
-dªÑ‹ï­M1–7°¤*’±¹+DÞÄZ·íøjâ?å
-”;�çÙß
ëÀÓùÙ—8Ç!‚Kùz.Áøò¯�Xñ€¯ÈHêKŠ\�M(€Á½µBO8 çXE_æsÃYZ·èp6aaLÞ5f(wS;áKéªOÙÓzôx
-Õ§µ÷YÍÛž�—™®Î燸-f: sôqó957ì>\Ç�´¶	¬C½}8$;DPì…eªì¢V¼'­ØíÄ<È“½Ü¾NO(߈]øé¦ÛÅr_[Þ*ʇ¡ÆËÆ<Òx ç˜î®l
-Ä’£×¬÷°zJmp¤0ZgôìuáÜí™ô!F…ªä
Œb“Ð.ƒ‰¢9wØhQÝ+âGùTjx­~wtñ».^jËð‘g&rÖ̹V§
#KÚý®Œ¿çqÑHºö”Å~àlsLÓfH9�áNjn£W4`oÑ£:»Øš^ÀÅK¥ŽÒúƒ
òL9ôlÊ0Û‰B˜ÚÔ#k|yË¢\Ÿ=*XˆÕ<d0 ¢‰úJkáÜ«mµuˆ„‘¯H`Ž6彋EÖùñ�ïùBÅ«�/hüî#Ô^†§ö¬i(]‘×Z]°&�ÈC˜ìö¶ãíöù{Ùj+à€Ú‘ZQ[){Â�¤iZ_Âì“à=Fº(s!:T
KØ;Xž�ZÆ#›DÂ,vÌ4ÐüQD~ô¡²ôå *×BêbŠµÊ´è˜:³�pu þ§þ9rK28]±„»]Êö]– ÌiŽ rÆf§>Ä
 óRi×à¦H~&¸·—ϲSz…€ÕhßÝ0Ö/äH—Ì-Z‘m®Ûû
<€úQ³Õ0zÒבß8r¨tIÏ'Õ`™@*ØÆ®@fÃ&€IѪ¥v%QÏ:®Á:.s&ŸëF­¤ƒQüʸúW	›_!Ò�0sI"A4ªØ¼D×Ä÷¨C!n†Ñðú;+‘Öº{ýŠ÷ÊdÒ”üÝz/1�76ßÆÊê0l®�«ßCヤb£s0 N­÷ä?‰X! ¦œ´Î`ÿ¾‰$ý:Š¾]‘µß«�kw#+‡üåj$P®¶½¬6>žæØñ^70•öKú€ø$ˆ]ïï­�óÝo¸@g\³°G
-9ÅùbW<-—Ô9â�EjRœáÖÚîö©ÝRËâG^ì sJ¬¾bíÇAÂxÙýeØ­ÒæÊ>•¸jÀ ,WÐs
-�ñÝ‹¼I2ˆô|ß{1¦[y#²š‹9ö_ÀSƒæŸ’™fyf+(ý
-K#Îø/÷2ž;¼£§Zç$Êò^Mú½0�)íN(ïó‘µ<‘Š6lþ;9ÅуŸ)Ðæ¦óF}»ºÐ=À¸¶V
Û˜Å/éGŽIÌYW¯µ=·ŒìŶÑ;˜vìbs¯+�YÈý/âwåáNV­&Þ÷¥0óŸ7¯Â$6/	ÈÉa…�Ø藺¢z|£>†²ª
-«Mˆí&/·}�ÎI	Ø%΄%0W¦É·¤¬´{âI\5d§1ÖÙA)£7½¡TDƒÖcÆãM~ÉÛ0l4ÚÔÕÝ„ùäˆ÷)—h7¿d~aùruÖ[l¡F÷è\)ãƒ|<k�z?D	\]ò7ï2¤ÎÐdåÛTª³WdDmI!÷Ï€S‚'#Q~On	)vE6ün¡Öi¢� Ó€(IIŠ?´ëôWÞbÚ¼%­ÂbAP­`6D
-–fçÚïC%ÇÎbl·Å$ûÄÒéæÅÇDÙdÿ
-Ÿýpô¯°0TO@,{i`·Î¶ÍÆ¢ãÚâ×Kܬ	¾�yOàï–<ÀQ–
-ðÕŽ£èÈp¬­°"M¸p‘)š
!
(´Æ[É⯻¹ÑòsŸûùWÅʨBP¨hÙ'“¨¿ÞÞÀOԫøŠ½â{Ë	eÊdëô¹Kx5QªÎ™6!â–­a˦½ë}2 ¨Ýˆð+0ö|3k³Ÿr™eÈ[A˜ýl\ÊŠ}óÃ\&Ñ[Ããóqt“´ú8ûy:µlõUñ®¥"„KЯ¬’Cpeªb•^¶¨¦oÀªs'ª¹þ¯cÙKñ]ùw+VuN|äáù	s.…�¸¦Ÿn ª4—&Ðøš{«î‹½±é
-uW–ÿðžZ—â9«ÞËÛråŠi~Û�0¿<€G<æÀ›3¦?›(íPÒá“~šGÁqFëÝ�ŽíƽHšJ+3"Ê«F…@™'›ñ‡îIŸŒ‰õ‰ZêÀ7Y
-gìзt@Š™+[Ñ3²/*;œ÷Q¿.ønÐDâ]ñê “R£Þ?*ã�]£_×êCék~Á3A¬
-$1üf¡
-‰¾É%|¾Uůx¯¸;%ÒŠƒ}5]åD„¢J›œ)h#?yºâþ-^ø*#G„	Ú”¢‘
üÀÄi;IÑÉ2ç�ŽÌ/~é)Ñu	죯ã3noዯ78]P³]nÃ|¾g
-6ψ6o‘PBšP'̧AFæêdf?P0dGC×´rW›çB¼¼6&³SÊr¥Ü	•¬SS‰ÓòñÞõT9Žú¼K�)Œ\û)°bç¶Õ†3´�$ZÞ#&†×ææjsmÂCf‰àS4XäHFZ”ÔzϘ(Pt
-|ÿÖc2›#á¦$'j‡ß|c›xß3ÃlÞ“”3Bm€Ü9ºš?¨
-LÈJ„5(µ
-S|ØHˆGð—Ã=>ô�ԑʇÞw1®V®Áç€�R=äŽK‚uW—e“	4¤µZ^ öçý†Ï#ÃÎDžâØmwp#ŸT-Œä{Mô§SqêßÑZ!¯È¥û;Åcï¤ág´SƒqÑq/V1aŶõrR€ñùòdfN51©é‹å=túúöp›˜Ùøfqû—
áoœ
-#‘%‘�Ï+0{—¹�Vx³½û³IÏßç@
›A
Öå]d˜± ÜšfÓ
3.ˆ•Lçû^«ªwk
FOpªÍm“é éâKL§.ã¬f0æµ2x‘$âGÈÛ~Í…�†ÙgpèÙzœlŸTêŸß'Ah7‹#m¢(´â'Z	%åÝa
&˜P[&W)íýyÝa
HÄrÇxg+Ešê»ÎÑû ^äŽ(úÖß `–ºr¶jºù7Yþsß›ûPDS"äÊ"pqšQ¦Mê´šsËÚ‰ÉöR' 
)Ú0çöÌzlšºð•`^•¼ßÖ——úq2‹ãqÙ•ÚüŒmÄàðr²ÉEh
-¤á¾}˜D'N+�nš~¯Ðß0’ƒo™¬WOÜs:¡ðwaz;A³cJ©ÚäA çÖûÈ<’+UȯÉCvL¥ºøPô‚Û²sùô*
ze-£Šü;2 «ù«#_š¤£s¾þ vêÄ‹úñe‡Î‡CØ“¨Ï>¼»,æñ’peàùhôm2’ÏÝ°MÍ[®¼¬Ý’‹�÷	€"_o UÅôh£
ÖB57„ý^æÛT'kiWCEÏr§ó•
-©ØWÚ¿\N[Ž”ÀöŒÍ�&nâáµ9vdµÍ¢–£¡!Šã5iAÅ�@ñ/*w.¸Ã(:³›Åå×Î6
îu1Ü3î᪾ûõW¤®48ð“ã‹KÓ^¥3Tòte:ëù`Ë"‰‹º‚p­,»iAX/†HÛ˜?äµÞ)RR«Y?êxjÒ/½)‚P8ñ“—»C>Är–BŒ!†¬gÝ@¯kîÚ“èNü½?DÆF¹U<þ5”I.:´�s¾Ÿj-p“Ã䊰"Ÿ�ªcÂ#Œ:B
�+?/P— wég&åoï�²û×!æ9œa pñ|Š®¥Þ²K5lïøŠÑ9„CF	†ºž/õ¬;¿G@!íxc|ȹD¤.׎n^H$ßÄÛÂÓq]Èõ+É{¸i™’
-“*ÅûÖ€H-eëpg,eƒ|ÍaJtžŒ/d�Œú*Λ¢6ºK2;”‹x'.QŸ[å Ì�ñÚ:ŸÄTß$$¯µ“Í¥¤·4UA
-~:Š0NÇŽŸÂy¨r“Ñ$85¿Aš«`!¨WÄF'*nNÁbt*Ú*¼ëë�Âæ;ŠEôû”ÕaÇòõT~ÔÖ“S4Ÿò3<5×Ø\ÛJ´Æß&æ–“O=P©[¨P$“Óµãñ€èiªš_`Ž.Šó{h/"•"v¥¯CŸ)-FßE¶ÛA<ÝïKF‡�é9	‚'ýøa¢4*$'=ÝèOáequGf0[éÒ´ò¢ïÑÞ7™Ë©4€ÐóØxâ%%Ì:¼ã/º.@ªã#)NˆÈÌaÀSt–k	�’»´jˆ5b;¦¿J;÷Ò±C°7·ä°ƒÂKŒwA¹5S‚é%8.nN`ºê9_Žû�¡ôÓ;Sæüê\g|¢�Häae#§û×çÛu¦�;¯ºÖÈÊXšŠäo+7×m4”°‹ª0Ýë#4åâ8�hù‚˜RË9«�»åì{°S©ã£›�ªˆ¿z� rª“ÊûýÎœ•VØÖi�!z_)�õ¸¨VS[i²sõq£Ë%®µe?åw«ìbØ-…97Á �|Êš
	aü’Þ[
-4%Å5k£½02ƒ�Áw¿b¶8y<•«ápÁÒ*Á–È��p«¯
,”&«‚rÃæG€Tëƒç¦£¤å¿”X{Š”ùH;_
ÕZ ¼ë/i)ï1Èû£.5n仯ðå9
=)ÂéÌW%^}@|Ѧ{P`Áíea°,pS L§Ü”üÚ®Û7CÖÄbÀtÝzÏ3$rX§5Ø¢Pü–„˜jW~\\{	7NìySE¼9
]ºž½"„i5¿ÓúÅXôxBää\„“y”\á¼¼!‡k(MÂÖL]*/öðéžä§�FJ{Y<Á&eš¯lõ‰Ïƒï…Ì‚+üŽŠ<Ù@9vOŽ�’¤ä[RY·ZßUM�Zûp4–DagPcZ‚%V_©Þ\;=MåWÛ¾ÖG
-›¶ƒ¯ñ¦¯<¢—h¸E“;Ukê ñ
-J±&éù
雈‹˜9›âÆæZue)äG$ LË#[|íÕϬ4ÈÝÕbO
-€£AÚ¤x8mw›þÖµÔ�„±ßxèÍ#ºaýªU!˜ù´TßN.ÓÙÇ-É™Q‚«iy@ŒWc²8qá/øç ‹ïåqYw'`:ÓN·ˆ=
-*¥6©!bÆ¥$ž)ÈFå¨3Çx=H3/xRÎWGzÊt¡Dc€Ê'ÒHD´öXM-®Áö
páØîÐÌ’!#ŠÅø*ÒÕ	Íè/<Ô¢8>§Ð†ó÷‰rŠeÀìåtѦ’¾Lñp	m…
U?ˆ+
-�½ŽîÏ>¿ÇrøKKíùƒrÍAfjxy‘	^W_ª^ø‘U
ŠäNGReÈ\®v/ÖVö†¶Rú׌hÉýy3˜Œßc¼b'óÑl«ð‘Ä�›k,¢°§ƒ.ˆkx„Kªý( 9×^ÅÈ
-…d«…œ#£}þÂÀÑÜÂG( ÑhQ/Um+‹|“·^±OI$ѸÙ0ãÆVèþ)ÆJ3ÍLJ_ñ·ÿÑLÖ÷¥Ÿn­Þo”vÒJáØêqmìíçâ%�Á­Ãcœ~ªzVÈ�‘søqÕg%ŽQÌ4³æ`£E�–/T�““?§púyÂå[uïлJ÷ödhºHÐÈÜlM�
-Ås?Òr&Fd¿Ä6ë&>N´.Š ¦¾1:¹
rP1ûØ——k¡f)ØdQmŸèÄI BÐä5Mþ¦1T¿`m[;­z!î_µ±=ñp)ä5^Išõ@ÑðÈ
š¢
žAò'tG<ÞÊÁæa¯š�m-mn(Ø
-‰�|¿"]ˆnŸ†GhS”C£ãžä.%^=‰Â	žš| È%ÿÅ%Ÿ/†5¥n�tntI-¿ÊÍÈ.-ÚŠ
-˜4ƒ¿à†tæ-ws(›¢ü	À.}!Ë•™ª^‘ 805D|~ØfÌWŸ½æ°›ã‰Å9ãqÀy[eN ù~TÒ€J…gD›¼à%HõŽN´W¤VêÜ©&QXS²;^Æ#~o ÄSÙÄòQ¯¹Omº¿k�Ê–»{.�
-àé%.@”ØÀÄZPÑ}ú¥ÄÝØÇ<†,2xˆá+„PÀ:І¢€XH‚9É2¯!I‰¥“–mõ놀)Ó
LvÒÀªÊŠ‘¤®­‰ŠI¾ž´ÀJ€-um~5SµÏ?�¼‘ÞËxXkDZÎS§ꊿʥ�'ÿâA“EÈz©Ltª=ø½¿ˆÀ¯’ëÊ›2{@?ï5ºûšõ¨N…&øºòȨŽ3HKãGš‹6hXle¡ïÿ–kMžÍMxßqhìàV…Ú¤ki1IƒË‹ë°ª¶ƒÊ9UFmwY¥YññW>èYM Ð7u
-Ç:ê
hפ�­ߛ֙C9߇¬o“‚/¶z>‡”8Õ"�¬pÔ"8f@xk©óí…f¸®��söšË‚ý(†'ï»Úƒ½pLjt:1[ɘú‚ËHâûŠK¥Q¹ÞAH)†3W.‡å¬ÉüÖÀU7¹þ"ݨ²_mz$(®$åÔ^ÕìÊÆŸ‡EÄÆvPºÄ¤7/'ìl\du#vتç¾½ììÄ“QP‹qH{Ä$5ƒlíÛóyïd? 2$yá9MLºG%[!/J™Í2an¶ÁœÞOz~ØŠ9@5ꎥ;V7Î
F��FsÕàd—ûãת?siÜ5$�$éD_j(¯Ü‡ËOÒðBO¿šq€îôN»#.Æ/8ZëùkVŒè‚¹ép›ÆjÕGpéÎØz
ÇöÛI9´HÓ®"!ÕJˆá«OY¢Úîµ5¤=.J×ø�2yØPK0úÍ�ÙÃPI¼ ÌIñ$GÈ^˜ÆºÌ‚cý%úE˜òï„cijñ¼•9‹ž9Ñ’l{ˆ‰$0¢w¯¡&jjia>’4�\¸	KDÃ{pÊŒ#?ÓAþ0›9°ñ-D>"ª:c?ܺÚ~†‡^e55¸l
-:kb¾ÉLQÒcèâåSŠ�Û€ …l±Ã{Y14¯ŸË#Y‘·IUHš6‰·'&:,q[ÞÀÑçºËÔg+ñA¼dÖ/LŒn”•ÿRÔ
-ˇ—Õøê�MCEýŒw·òÞPðÃ�]ï-¼5L-§Ô²%\ðd*]®K¬qtmpMó¹{Â6Dm1Ð[�2m¢ºûw*QÝd‹Q“÷\ÒBq¶˜™2<ôÜå`ve¹¿�*9GiÐÍ
- .ÓÐ']ÒÀ^Od°â®D—üå„,?#ÞWÖ³bRªv×èSž¼˜Î§ÁØ$ôÊ`mñ
2D=ón“þ´ÁžD㔹=õk½IPïÅvƒJ<�¨±ÏÞtݘÍZ´G
U^�W0äõ¬’”¤¡ÌšÙ=JéSQŠT#’åOµŸ>]žAß÷åʇȆ³Z!“Œ®Íïå>÷Ô‹fÜ.å�¾Ó;ö§hgXUãÿ‚yXÛ%…6,˜Ä�™T¸«úÊ*1²ö°Ò”"‚ï3Y¶m"ˆ†s¸µÌ·
Rþ;ÕõµU§é±8fŠ•ì0A¾Ç¤‘oxZ¼ÒÀá¸+ÊNVk�ú÷#$ Ë£6\4ŠtóV·‘D^2'lRw‚fÈ2Ñ[£Ø߇`Ÿk5Ñs kÜË·g¤Ãs©	ÛÂÍÝ�ÍŸ¬B?1|k6*yf¡3ñÚP‘|Büu+ÁËNõ8XÄôÈä‘¡ù EUQÊFÿµð¥¸ËôiÔ2¼ð`Næ}ïT´?AËÒiÎâ ú[¼5�¿«-ŠCLÓÇUY$ÐÀéëh¤®WN�ÉJB-þ¾ÜaìÚvvÚT¤‡dŽò[µ>Æ–ø|sÔrèCd `¦Ÿü^†ÕÁÊãDÃ*ã%­ã»ò�ýÏŸ‚«ˆ›ó�ñÚ àfX¡6øvçŽÒ]©Â�—ñV¤M"BÝèù£=&w>8Kº�ä
*¯+–¡oèKᣵ4æx(
=¾$h%H
-£VâRÑ
-ï82Ö&)°"¶E;Ü´”ŤUYvƒÜìVZ9M*­µjQSJ­)‡Ÿï@LH§Ò5Èþ¥
-½~ÒoÍdW)�(Ö€çÜÀæP»€Zø¦ÂP³¢½OU®æ’mèß´¨§raäÓw@„�&7ìVÛÌyå\çøiÃH47�+ù׉L
-µQu-W€»×4~Q.£ÎÐ)ÅÈLHQ-Û(èÖü¥> ø|kúÜ„X`Ž�×¾®º]	#.ëwx+«;.ñml3ÁѪ۰çµs
-:Ê(׸B®Ó'=êû’ýeÅ9,†`óÙ‡{ß%€ª�
¢0<ý}õ¬YâÁ}‹
-ˆ¬BÙp:©Ñx”Mî§�?ó}¢Ø×4¹„“ùïüGßß�aWGÄð«à
-�«1,u6AS�£áx\|czíR¢€oÀbÐ�.P³¦‹Ý=Öö+<µU
ZäÍ&zÐÑÅReu–
-[5Öð�Æê_ka‘¢Þ÷£ø‘*q¥=¡R4Ð/@™jÂHµ0M’$Ùþz„
-˜É¦p8çˆC¡·š•òÏq0ÞSGD¼ÆS
âT2J¹Ôi­¸É½°½äA�	iÎáDµ9)î“>oâÚà�Ђ,®DOͺ؀¢À¨&¯¬±ßŸ“ãùí„í½OÄ[¢:&ßQC—Ýåy�˜1ŸÜ¨^Nò`ϯȌ)†¬!�îÍÓ¤~»,˜7Õ$á/°Ûº¤zé5"™4¾bø–ˆÛM]üè»o~E®5p‰ñðJÌs¨�{•mo�œäÜ%Ö¡A;›<Ñíô¦óñÜý¦�¦@=®Ð@ZR¸ôGv Ö}¬ÇàƒO³þ›§—ÙA´|:÷©‡ž™Ï	@pmðïÑçñ€RÀw<—a°Ý½7#øSBG�8-(v�>	Ûžq<]ù�ÞÚÖÁPdöÙò@JÞâõ•WÑ2|¥ —Ê„s’¨Ê‘i%
Ìî3² °6“NP&0ž>�>ÀI2åOø®¾Ój¬ŠÛ¯)ÒÀŠÜÚJ8¯Öß*fzU;.ÏZÜ$Úùd
-×D½í¤»a£ªâ*¶‰ÂÀÜÙš*û(Œõ¤qÁÃåäÌ°
[¨.xÔŒHhý� {§ú·–æýy�澡:ÔuÓçg¦�¨÷œ4k	ÜÀ�=ñï�El�D+Ž9Ó{û¤Î=£n„ÉÐE:x�ª»n½†í·ô
-é4NÈŠóv É.Õƒ_Þn$`¬ÓÖ)<ËEŠþê°õ�ç@‘q6I„òÝäŽO¦ù¬R²Ôg-£d–‚îAúô>l¿ 3)VÐñ,ÿ²8Änd2€ø»Ì@צÍ*€]ÉãhsÀž”nä¦(ºÎõ§ÕŸW‘ÉÒî#�ÐósD–&�ôؤžm<[ãXp.7ôâ(5%ö‘ì>B8‘�'ÇÏÉÄ-ŽM%f+ùo0à8}¤{+Ãþ/®ò ¡‹pp… ‚óìô½ÙW¬ÒCF8fÎÞßòä6ŽÓ‘æBVÎÒP,-{DÞBЪðß“úé,¢�îN`:¹ ¾ÔŒ/™t>¯‘¾ÀýÝ«9Ñ>á…‡]`5TæÑ’zûvyWX2FüºþbfO–f§>}al÷¨\ÔMê—´ìù¥ìâVPÇsp¥²oøâÇШ›x¨³N
�O_Ž»N=ð£��³§ND˜ÿ«ýzZ¯@(5Ic{Çv³cÛ¶mÛ¶mÛ¶�ƶm»Ñ™w8wóÍz€ÿ~eŸYçÞ*D+_—‚#ioÛçT¢{?ØÏ|Xž!ÃS)Ëb×ß[ñ_ˆ
-ï%,3”1•äœJñÙwG¯üûñšøoeüªyDhéNÁÁϹݎÓR
þ ~¯›GßB‚\ÌŽ™;؆r•R-ŸEGT±ùø°ãѶ÷�Žz ‡¤/z”Þ‰…3¿µf!KÜt[¢áqQ‰(¤Õþˆg§þ¬EÒudV;~_€dr‡çI;17a£ƒžq”„)b±¿²‡s(…0
-IfLt´&
-¸Õ‰]ª¼ÖÀ·ü´¨ˆúWÓž•N€ÓáÚ îËè ¥·I­Ñ—Øü:k
b-F”ÛÈØyŒÔLúcÙY>#S·ÿý�¢žæãþx5
-ŽsU	? ë{x[òq=4£øŠÉTñ�ñbEK'òmç±v�§9ˆçì‘È�$“CXcþ©\“±>ÊG˜m@>¥¼lX1
©ô¸dwO	�AþŠEÒÖ’±Sc¸I/cK+–5>¶V‘+"zg
-*»åMì•¡p_ÐV—+}¤ªÞ�TžY!�æĹ(K§i�"üÇ(*wOzŒF®¯’«X`Ž¡ÿ­Š�¢É
-™*r[¶Â—n³î+ˆm•€Î
êËÜun2qÄi"P6h£.ü·T”•OdÉ_ùüånµ~ ‡q#$i5’2Íçš�uÛOÖL[˱ÙE¶IkQñßå:¢_é²w«®º!É·Õ7ˬÞýóÌlÒλª>	^ØH•€
þfuĶgŽÍÆm4N}Ò
-žº²Ü�à9UwgÒBkÙãƒËÚž½Gr˜�u)Ôë
-èòÔAé›ðöÖ_ß5Xuïwo%~’KG`4÷B9MXÄ—›Ý*¬â=cÉwú¦¶­r±¼§˜½ïÙÌèÀXmgsÌ{ná>³.ëÀS±¾ü¾ºÈÙ”¦ŠQ®�Ÿ6È4ȤÍzÚ9Ú—¦Å÷K\
ìkCì«›!ê;àú¸èy¢Å
-	
-"¿‘©ÜŒ˜%�(–PL•„�àà�}çô—ìd¸A�4HVs_™c‚Ò„µÜÅ‘nÜŠ¡V�z*-‰To­”�â7*úï	#{y‚íl¤â:n\Æ�>‡áos.ø¨ŠsýE×õ©É¡Ã<äm¶E±¸@ˆ�x²îkrŸËÁ}G=1ôƒNl.&·´Mf‰2À4îۯ0ö€6Ñð
�G¥í¤B§R“Bt•¯º%õĪÜ~ç$`XÞ(ÿ¶ˆphíÒ[,	²�·wÄ.„ˆØeæÒ$HÃù”±åá<€;]vÛàr Öù›–ÞpuU“J¯Ð�œA£½<�ÚÓ¤ïõV1r¿Â¥“e8Õè7Þ)h(²¼Eð¥GðЖ„ñ˜WÒMæ	_Y£õ‡æÒËfcØŠ�¡ÌõCÒ0—£Û²u—§§äùp3¦~ùÌ[yÔ5!Áy˜Ý Ð-¹9¨ÉŠ%�Q-}/DšC¦—jn¦%>HLgùh:âî…¶Bldš½üuô݈°½‹IÖ#o½¿ùði9žìtå‰ò2¯̉ê³æÖ®Ê2VÂ^­.îÔ
-ëÿ8±²
-òo·�ĉè8²{ãqÍED§G×æë±ÆöåÜbùÜß°”\&Ü�‘ù­òÏ2qsÈÆ°Ûy¾�>bò´ÌOX(oÁYÓ‹Þ"4Ù†w�7«~Lé'ƒ]‰v }Oä8ÝMª)Ž�–X’�EÀ,3bQ*ÞWAš0 N5<_8%)FľJVßr”[‰=Wÿ:¯&,o/ÑQƒ�+"%N†êémü‡*VtŸ_-’È°”´sPàkX‹'ÙÊ‘FâbMüzyixû�ŸGG1SÝ(&¦F›Å8'Ç
-mÁR!/¤ïmYz'Úò”¦ÀÀh'¨1I	ÌѨ�õéI¹;b’@\Öq×Ü[¤µ*ý�ôF£½™ÃØ»ÚRqõ¶›0ý×nD%ŒãßÉ€¦]:bĨvÿŽ“U®ïqî{Ĥ
-Èù#†ð÷†(£ÃÐw¾áR¼­ñ¿ø;	h@À‘Ä8~©Lp©™¦¿RÒtª3ª5/0Ò¡S0±nÍ&9=Ó ÷-Áz;¢Ir�H©3©Òpdl²l[‹}B¿p“šÌN2ùòw
Д˜…¥Uh�pO· 
-FÖ—bowÖç'<{†Ëe/>w¤ìºO Óyf4,%[n‹¦ó<ÑȲ’Dø¯7XQ`õì¹;ðkgýÑt{D¯VC|n$è_
-5±)Ä;À†íkPAs~6wD¦l¹Y²˜'À&>)Ž:•„ΊÙtAÊ�˜xñI…Å©Ñ’"Vï�·´—Á}“Ôl—Üœ2Ê?«RÙª¦»�
Ñ2ø¡†LŠ¶Ð*¥ÕùÏ•Õz¢W¯íPO!Zñšâ:¡••3ìv{´3:9¨;8
~†»Gcã–XÇ*ؾƔrõFÉ×<ͤŸ”WSs¤ù€ûñúóRXÙlN|PLò4ŠÒñ£l8¯´Àøî[ë†4 Àñɽ.zšcF­{ý†ÄT¢¸ˆŽ¾�‘Ð
[™(�)ä ‡¦f¾ÆF£ðÝ
´Z"gº…´>Ôæ5âµlÏ
â,¥÷y”¦Ä“1Êe]#¾{Gš!ÓK±¾„OÍ÷¢ü¤ïï!Œ^{ßðÉ‘F'U0BBo÷LÉ7„ob�¨AÏqØ5ƒ£&ÜçîYd5K­ÜeíO%:Ó
6™zD�-߹̫\šM0
-¯'l­Õ_‡2›.vèKâÔ€fïø¯âˆÚ\ŸÙÊ
¡òËà.¶¸iAìU„‹Åss*’ñªÛ
-ó
Ë.ºÞJy'k<¬¾T¨u®rï
p¦±2Äé�yš˜¾Á0^øÓí ›Hv,¥wó!éùž1�ÄVûr#Âp_JI´¿4ŽÎ¸6ú˘ì{2{ã•
<[—)¾Íj°xÔo~y‘S¿mäó¼—¯ùh§NWp¡Q2¬ð‚‰>÷ËgCX ÀõVUé³½æ·ÝbM†Ðñù6 kh*†4¬†	·ÚTã’#­Ò<÷òwHÜ�2ÈAœS¼WR¬v"«¡™Ô1í2•¢¨¡;ŽÞuE@L
±Âà‘Œ”ª^4þÕŒl«áÇü̺-€¾¨“\Z™�Òçtä %p´§”î–©ÚËj�Kûr¦ä¦¥Æ¢[~ÕÇÆ
-eÁ½õiÐGÓ8¿ÙñCÊI´‚¥º]u¯˜Ôjù -JtáBÊk(W
I�)Í’ˆÇ ¨�kFîÈ�Ji…ÕFS„Éãâ…—¹l;£—¬(¯cgHÖ5§ýUj®¦›¤ÞNX*1a"˜…J[å?x¯5Mï@ 7‰íɳ't"
Mrmc
§Õnœ€rÍÖÔ<.ïo°öÝｦk¶åÎM¾×ÅŸ“p40¶Y¤ÉçŠÀ^s ëµ¬d>Rõ~YîZ_Ä둹v0§Gm‡‡N®3çï7G$*›½th•ëù�ý¹¡Òg)ˆ,&ƒM€¶ïÎ3«yÔ&o¹Ù›ïu–ž4«ô,öZÎOkÜ÷ªÔD%«†Déz¡v?ò‡/óÀ;�Š'?§îºËcšý‹Üè
-µ(à\èaª
-E‰7jŨi¥oòƒŒ:½úþ·cêSJo*>»u+Æ#@Ä«áb\[k!s&D “‹Ãd`È<HØò†T¦EÚdò:±CíkE
-j!H·îà3ÁE.
- ø!{mž/ƒòZú+p%Œ«u–}Fcí¿èýˆ/ì…Ƶ1>§ÌM)ÔÐ	O�%Sýù8½î×Ç
-dˆü�r4îŠ$#œ™/à·Ñw$–+3¸]Ì„5¼T87Å]ý—‰Ø¥–…ZPŽü¢
X¥Ì[šÿ8™XpÉþCi€ó`KpmMƒ*­y¨À&ÕÇ*é\—l¹ïˆü°xr#L?)¨ù¹kvü¯â|V{þ–aÀB$ÇÉÎàj�`ñh›Îëæîõ­QUd�j5Ë$k>7¦|©™¬âÃöõÚ¾¤,ˆÇSÎbÎ=¯	6¢ŽIÛž‚2üúð?÷ò)CÎ|æ¡î0)uktùþîo#‘Æ�$÷s‡³Wgª~„ŸÙñôÀԥ;º�aâlèQÌãæƒhË›ƒÌð`
-Z®§Ñœ8Îeä¾ÏFþ±Ã,ô\5ˆI.èÑaM
4Ž´mÇÕ‹èqWM‘±•î·egcØøí
«\[þT
-¿Á…æËU¨—xÙLDÞsäÓš
-Iö×~pºóE¦f}^!˜tQ°Ù’‹ƒEäì>‰ n|'ÆV²5D9_äå‹7â̬FJvõ˜2È­ÛŒ’ý;Û£K¿>Z&ú‰Àš¤þØɉ,-¯,Yت–=–ÏÞáÆX8?�¸#…m èÓð¥žçßèðž–u¤<5åÑwÒ6¨´Í�Ô™­×#0±q“²Qý‰±ÀåÙëã=¥—;1Â&<
-| fÉg¬,=‘¥vp‘�·xMŒé‰_b¬5
-µœóû¿ µ§öÈ4¿À#è¸?§ß7LíXʳŒ”ñkÌ€Zî»vSLR‡û
4ƒ?&4=cwÓ™7mÿ­8 ‡L¡ž~šËmé0Rƒù]N9ÄO:;e0vÈ(©6‘÷ôŒ÷ÃæÓ=Ô
èÖ‡7œŠ?­)Í'á ž	àÇ38ƬpYBà³Â|ƾC¬D?ÖD‡§-QÊ(6ò˜¤>Œö)€*#£˜ò�DUdùªé³ÓvU
-[`÷QìÿY¨OÖØJæÒ2‹„a¤.‡yMÙB.½T›.¡
-¥í’bWW�ž^¿§M?¼ªßªéë;ëš<™áh ±Kñŵž¢¨ÚÆóV1îcÖOÏ"ž³x4tÅ:l�¼t@i×uÅ«»‡‹Á0“ö�ë]RϺM'Ü>Á™?#ÉABlž=fÌì…
ïé ÚiózõÔ¨¿!…+°2Ô’Ýzôµ¥Îb—B
-y‘üP'càÜ^M#R°·ñÃ4
{LJB«œ»×ën¾HïŸMc–9|þ*S5ïV®ñKãÁ“ü�vÚJ¦‰‡’à°áR‹ÁPKw©ä;ÉͳðåH-ºOÖ²ÉâØÉ*Wü—¼éýšö•p…+èó®a7AÔºº;˜âR·~4ÿÕ|S®‘mƒ®W•~	©Ãâ‡}DL×WF5J‰åéØ|¨i÷>#\2®˜
-šÒ30D”€`Ÿ†§¾ç�4}&1xÒ¤Ö¥	ÎdP•Ý‹$ȾCO‡Ù’jÛvëö?`C&W'aÔCJ•I'sŠFðìM˼k©¡¨»°+X	ŠcAÐÀ«á¥£ùr!<s%!ÈbˆÀNÑ*d3³Ê6�†Ø0´+3ïÍNYÀ8�îj•ÛP³7Þ¨VäÎc=$0€Ž9€òõ
«£…WCÒ¸1å
Ô²9L±ž±~óŸ–äWÚyüInÐäöÀ'¼I3
ú]`+ò7vÃÝ!�’ÔËö—k«Zœ–(&4¨j�„¸`é+àpôxÿÅë«SüWâ$åM7ƒ[IZÒýš®ê~‚VƒÍ:Ø\é«…Œ
€Øy_à£öý
-.ÈëÃ6‹û¯™ÅSßcŽ¾Q&É5	fd
-ön’“,6"”@K;\ÿŸÁüø¯
-endobj
-658 0 obj <<
-/Type /Font
-/Subtype /Type1
-/Encoding 1921 0 R
-/FirstChar 2
-/LastChar 151
-/Widths 1936 0 R
-/BaseFont /HVUUYY+URWPalladioL-Bold
-/FontDescriptor 656 0 R
->> endobj
-656 0 obj <<
-/Ascent 708
-/CapHeight 672
-/Descent -266
-/FontName /HVUUYY+URWPalladioL-Bold
-/ItalicAngle 0
-/StemV 123
-/XHeight 471
-/FontBBox [-152 -301 1000 935]
-/Flags 4
-/CharSet (/fi/fl/exclam/dollar/percent/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon/semicolon/question/at/A/B/C/D/E/F/G/H/I/K/L/M/N/O/P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/bracketright/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/quotedblright/emdash)
-/FontFile 657 0 R
->> endobj
-1936 0 obj
-[611 611 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 278 0 0 500 889 0 278 333 333 444 606 250 333 250 296 500 500 500 500 500 500 500 500 500 500 250 250 0 0 0 444 747 778 667 722 833 611 556 833 833 389 0 778 611 1000 833 833 611 833 722 611 667 778 778 1000 667 667 667 333 0 333 0 0 0 500 611 444 611 500 389 556 611 333 333 611 333 889 611 556 611 611 389 444 333 611 556 833 500 556 500 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 500 0 0 1000 ]
-endobj
-659 0 obj <<
-/Type /Pages
-/Count 6
-/Parent 1937 0 R
-/Kids [650 0 R 677 0 R 687 0 R 742 0 R 806 0 R 867 0 R]
->> endobj
-886 0 obj <<
-/Type /Pages
-/Count 6
-/Parent 1937 0 R
-/Kids [871 0 R 888 0 R 902 0 R 913 0 R 920 0 R 932 0 R]
->> endobj
-944 0 obj <<
-/Type /Pages
-/Count 6
-/Parent 1937 0 R
-/Kids [937 0 R 946 0 R 957 0 R 965 0 R 972 0 R 978 0 R]
->> endobj
-1001 0 obj <<
-/Type /Pages
-/Count 6
-/Parent 1937 0 R
-/Kids [986 0 R 1008 0 R 1018 0 R 1023 0 R 1027 0 R 1034 0 R]
->> endobj
-1050 0 obj <<
-/Type /Pages
-/Count 6
-/Parent 1937 0 R
-/Kids [1043 0 R 1053 0 R 1060 0 R 1065 0 R 1074 0 R 1081 0 R]
->> endobj
-1093 0 obj <<
-/Type /Pages
-/Count 6
-/Parent 1937 0 R
-/Kids [1085 0 R 1096 0 R 1102 0 R 1110 0 R 1117 0 R 1126 0 R]
->> endobj
-1145 0 obj <<
-/Type /Pages
-/Count 6
-/Parent 1938 0 R
-/Kids [1139 0 R 1147 0 R 1152 0 R 1158 0 R 1164 0 R 1172 0 R]
->> endobj
-1182 0 obj <<
-/Type /Pages
-/Count 6
-/Parent 1938 0 R
-/Kids [1179 0 R 1184 0 R 1189 0 R 1195 0 R 1199 0 R 1206 0 R]
->> endobj
-1219 0 obj <<
-/Type /Pages
-/Count 6
-/Parent 1938 0 R
-/Kids [1216 0 R 1221 0 R 1226 0 R 1237 0 R 1243 0 R 1248 0 R]
->> endobj
-1256 0 obj <<
-/Type /Pages
-/Count 6
-/Parent 1938 0 R
-/Kids [1252 0 R 1258 0 R 1266 0 R 1272 0 R 1279 0 R 1287 0 R]
->> endobj
-1303 0 obj <<
-/Type /Pages
-/Count 6
-/Parent 1938 0 R
-/Kids [1294 0 R 1306 0 R 1310 0 R 1316 0 R 1321 0 R 1325 0 R]
->> endobj
-1338 0 obj <<
-/Type /Pages
-/Count 6
-/Parent 1938 0 R
-/Kids [1334 0 R 1340 0 R 1344 0 R 1348 0 R 1356 0 R 1361 0 R]
->> endobj
-1392 0 obj <<
-/Type /Pages
-/Count 6
-/Parent 1939 0 R
-/Kids [1378 0 R 1394 0 R 1409 0 R 1419 0 R 1425 0 R 1432 0 R]
->> endobj
-1453 0 obj <<
-/Type /Pages
-/Count 6
-/Parent 1939 0 R
-/Kids [1443 0 R 1455 0 R 1463 0 R 1469 0 R 1473 0 R 1479 0 R]
->> endobj
-1493 0 obj <<
-/Type /Pages
-/Count 6
-/Parent 1939 0 R
-/Kids [1490 0 R 1495 0 R 1499 0 R 1510 0 R 1514 0 R 1521 0 R]
->> endobj
-1589 0 obj <<
-/Type /Pages
-/Count 6
-/Parent 1939 0 R
-/Kids [1531 0 R 1591 0 R 1647 0 R 1701 0 R 1735 0 R 1744 0 R]
->> endobj
-1754 0 obj <<
-/Type /Pages
-/Count 6
-/Parent 1939 0 R
-/Kids [1750 0 R 1756 0 R 1760 0 R 1765 0 R 1777 0 R 1781 0 R]
->> endobj
-1797 0 obj <<
-/Type /Pages
-/Count 6
-/Parent 1939 0 R
-/Kids [1793 0 R 1799 0 R 1810 0 R 1815 0 R 1820 0 R 1831 0 R]
->> endobj
-1846 0 obj <<
-/Type /Pages
-/Count 6
-/Parent 1940 0 R
-/Kids [1843 0 R 1848 0 R 1859 0 R 1864 0 R 1871 0 R 1882 0 R]
->> endobj
-1897 0 obj <<
-/Type /Pages
-/Count 4
-/Parent 1940 0 R
-/Kids [1893 0 R 1899 0 R 1909 0 R 1915 0 R]
->> endobj
-1937 0 obj <<
-/Type /Pages
-/Count 36
-/Parent 1941 0 R
-/Kids [659 0 R 886 0 R 944 0 R 1001 0 R 1050 0 R 1093 0 R]
->> endobj
-1938 0 obj <<
-/Type /Pages
-/Count 36
-/Parent 1941 0 R
-/Kids [1145 0 R 1182 0 R 1219 0 R 1256 0 R 1303 0 R 1338 0 R]
->> endobj
-1939 0 obj <<
-/Type /Pages
-/Count 36
-/Parent 1941 0 R
-/Kids [1392 0 R 1453 0 R 1493 0 R 1589 0 R 1754 0 R 1797 0 R]
->> endobj
-1940 0 obj <<
-/Type /Pages
-/Count 10
-/Parent 1941 0 R
-/Kids [1846 0 R 1897 0 R]
->> endobj
-1941 0 obj <<
-/Type /Pages
-/Count 118
-/Kids [1937 0 R 1938 0 R 1939 0 R 1940 0 R]
->> endobj
-1942 0 obj <<
-/Type /Outlines
-/First 7 0 R
-/Last 607 0 R
-/Count 10
->> endobj
-647 0 obj <<
-/Title 648 0 R
-/A 645 0 R
-/Parent 607 0 R
-/Prev 643 0 R
->> endobj
-643 0 obj <<
-/Title 644 0 R
-/A 641 0 R
-/Parent 607 0 R
-/Prev 639 0 R
-/Next 647 0 R
->> endobj
-639 0 obj <<
-/Title 640 0 R
-/A 637 0 R
-/Parent 607 0 R
-/Prev 635 0 R
-/Next 643 0 R
->> endobj
-635 0 obj <<
-/Title 636 0 R
-/A 633 0 R
-/Parent 607 0 R
-/Prev 631 0 R
-/Next 639 0 R
->> endobj
-631 0 obj <<
-/Title 632 0 R
-/A 629 0 R
-/Parent 607 0 R
-/Prev 627 0 R
-/Next 635 0 R
->> endobj
-627 0 obj <<
-/Title 628 0 R
-/A 625 0 R
-/Parent 607 0 R
-/Prev 623 0 R
-/Next 631 0 R
->> endobj
-623 0 obj <<
-/Title 624 0 R
-/A 621 0 R
-/Parent 607 0 R
-/Prev 619 0 R
-/Next 627 0 R
->> endobj
-619 0 obj <<
-/Title 620 0 R
-/A 617 0 R
-/Parent 607 0 R
-/Prev 615 0 R
-/Next 623 0 R
->> endobj
-615 0 obj <<
-/Title 616 0 R
-/A 613 0 R
-/Parent 607 0 R
-/Prev 611 0 R
-/Next 619 0 R
->> endobj
-611 0 obj <<
-/Title 612 0 R
-/A 609 0 R
-/Parent 607 0 R
-/Next 615 0 R
->> endobj
-607 0 obj <<
-/Title 608 0 R
-/A 605 0 R
-/Parent 1942 0 R
-/Prev 571 0 R
-/First 611 0 R
-/Last 647 0 R
-/Count -10
->> endobj
-603 0 obj <<
-/Title 604 0 R
-/A 601 0 R
-/Parent 591 0 R
-/Prev 599 0 R
->> endobj
-599 0 obj <<
-/Title 600 0 R
-/A 597 0 R
-/Parent 591 0 R
-/Prev 595 0 R
-/Next 603 0 R
->> endobj
-595 0 obj <<
-/Title 596 0 R
-/A 593 0 R
-/Parent 591 0 R
-/Next 599 0 R
->> endobj
-591 0 obj <<
-/Title 592 0 R
-/A 589 0 R
-/Parent 571 0 R
-/Prev 583 0 R
-/First 595 0 R
-/Last 603 0 R
-/Count -3
->> endobj
-587 0 obj <<
-/Title 588 0 R
-/A 585 0 R
-/Parent 583 0 R
->> endobj
-583 0 obj <<
-/Title 584 0 R
-/A 581 0 R
-/Parent 571 0 R
-/Prev 575 0 R
-/Next 591 0 R
-/First 587 0 R
-/Last 587 0 R
-/Count -1
->> endobj
-579 0 obj <<
-/Title 580 0 R
-/A 577 0 R
-/Parent 575 0 R
->> endobj
-575 0 obj <<
-/Title 576 0 R
-/A 573 0 R
-/Parent 571 0 R
-/Next 583 0 R
-/First 579 0 R
-/Last 579 0 R
-/Count -1
->> endobj
-571 0 obj <<
-/Title 572 0 R
-/A 569 0 R
-/Parent 1942 0 R
-/Prev 551 0 R
-/Next 607 0 R
-/First 575 0 R
-/Last 591 0 R
-/Count -3
->> endobj
-567 0 obj <<
-/Title 568 0 R
-/A 565 0 R
-/Parent 551 0 R
-/Prev 563 0 R
->> endobj
-563 0 obj <<
-/Title 564 0 R
-/A 561 0 R
-/Parent 551 0 R
-/Prev 555 0 R
-/Next 567 0 R
->> endobj
-559 0 obj <<
-/Title 560 0 R
-/A 557 0 R
-/Parent 555 0 R
->> endobj
-555 0 obj <<
-/Title 556 0 R
-/A 553 0 R
-/Parent 551 0 R
-/Next 563 0 R
-/First 559 0 R
-/Last 559 0 R
-/Count -1
->> endobj
-551 0 obj <<
-/Title 552 0 R
-/A 549 0 R
-/Parent 1942 0 R
-/Prev 527 0 R
-/Next 571 0 R
-/First 555 0 R
-/Last 567 0 R
-/Count -3
->> endobj
-547 0 obj <<
-/Title 548 0 R
-/A 545 0 R
-/Parent 527 0 R
-/Prev 535 0 R
->> endobj
-543 0 obj <<
-/Title 544 0 R
-/A 541 0 R
-/Parent 535 0 R
-/Prev 539 0 R
->> endobj
-539 0 obj <<
-/Title 540 0 R
-/A 537 0 R
-/Parent 535 0 R
-/Next 543 0 R
->> endobj
-535 0 obj <<
-/Title 536 0 R
-/A 533 0 R
-/Parent 527 0 R
-/Prev 531 0 R
-/Next 547 0 R
-/First 539 0 R
-/Last 543 0 R
-/Count -2
->> endobj
-531 0 obj <<
-/Title 532 0 R
-/A 529 0 R
-/Parent 527 0 R
-/Next 535 0 R
->> endobj
-527 0 obj <<
-/Title 528 0 R
-/A 525 0 R
-/Parent 1942 0 R
-/Prev 243 0 R
-/Next 551 0 R
-/First 531 0 R
-/Last 547 0 R
-/Count -3
->> endobj
-523 0 obj <<
-/Title 524 0 R
-/A 521 0 R
-/Parent 475 0 R
-/Prev 519 0 R
->> endobj
-519 0 obj <<
-/Title 520 0 R
-/A 517 0 R
-/Parent 475 0 R
-/Prev 503 0 R
-/Next 523 0 R
->> endobj
-515 0 obj <<
-/Title 516 0 R
-/A 513 0 R
-/Parent 503 0 R
-/Prev 511 0 R
->> endobj
-511 0 obj <<
-/Title 512 0 R
-/A 509 0 R
-/Parent 503 0 R
-/Prev 507 0 R
-/Next 515 0 R
->> endobj
-507 0 obj <<
-/Title 508 0 R
-/A 505 0 R
-/Parent 503 0 R
-/Next 511 0 R
->> endobj
-503 0 obj <<
-/Title 504 0 R
-/A 501 0 R
-/Parent 475 0 R
-/Prev 499 0 R
-/Next 519 0 R
-/First 507 0 R
-/Last 515 0 R
-/Count -3
->> endobj
-499 0 obj <<
-/Title 500 0 R
-/A 497 0 R
-/Parent 475 0 R
-/Prev 495 0 R
-/Next 503 0 R
->> endobj
-495 0 obj <<
-/Title 496 0 R
-/A 493 0 R
-/Parent 475 0 R
-/Prev 491 0 R
-/Next 499 0 R
->> endobj
-491 0 obj <<
-/Title 492 0 R
-/A 489 0 R
-/Parent 475 0 R
-/Prev 479 0 R
-/Next 495 0 R
->> endobj
-487 0 obj <<
-/Title 488 0 R
-/A 485 0 R
-/Parent 479 0 R
-/Prev 483 0 R
->> endobj
-483 0 obj <<
-/Title 484 0 R
-/A 481 0 R
-/Parent 479 0 R
-/Next 487 0 R
->> endobj
-479 0 obj <<
-/Title 480 0 R
-/A 477 0 R
-/Parent 475 0 R
-/Next 491 0 R
-/First 483 0 R
-/Last 487 0 R
-/Count -2
->> endobj
-475 0 obj <<
-/Title 476 0 R
-/A 473 0 R
-/Parent 243 0 R
-/Prev 275 0 R
-/First 479 0 R
-/Last 523 0 R
-/Count -7
->> endobj
-471 0 obj <<
-/Title 472 0 R
-/A 469 0 R
-/Parent 455 0 R
-/Prev 467 0 R
->> endobj
-467 0 obj <<
-/Title 468 0 R
-/A 465 0 R
-/Parent 455 0 R
-/Prev 463 0 R
-/Next 471 0 R
->> endobj
-463 0 obj <<
-/Title 464 0 R
-/A 461 0 R
-/Parent 455 0 R
-/Prev 459 0 R
-/Next 467 0 R
->> endobj
-459 0 obj <<
-/Title 460 0 R
-/A 457 0 R
-/Parent 455 0 R
-/Next 463 0 R
->> endobj
-455 0 obj <<
-/Title 456 0 R
-/A 453 0 R
-/Parent 275 0 R
-/Prev 451 0 R
-/First 459 0 R
-/Last 471 0 R
-/Count -4
->> endobj
-451 0 obj <<
-/Title 452 0 R
-/A 449 0 R
-/Parent 275 0 R
-/Prev 447 0 R
-/Next 455 0 R
->> endobj
-447 0 obj <<
-/Title 448 0 R
-/A 445 0 R
-/Parent 275 0 R
-/Prev 443 0 R
-/Next 451 0 R
->> endobj
-443 0 obj <<
-/Title 444 0 R
-/A 441 0 R
-/Parent 275 0 R
-/Prev 439 0 R
-/Next 447 0 R
->> endobj
-439 0 obj <<
-/Title 440 0 R
-/A 437 0 R
-/Parent 275 0 R
-/Prev 435 0 R
-/Next 443 0 R
->> endobj
-435 0 obj <<
-/Title 436 0 R
-/A 433 0 R
-/Parent 275 0 R
-/Prev 431 0 R
-/Next 439 0 R
->> endobj
-431 0 obj <<
-/Title 432 0 R
-/A 429 0 R
-/Parent 275 0 R
-/Prev 427 0 R
-/Next 435 0 R
->> endobj
-427 0 obj <<
-/Title 428 0 R
-/A 425 0 R
-/Parent 275 0 R
-/Prev 347 0 R
-/Next 431 0 R
->> endobj
-423 0 obj <<
-/Title 424 0 R
-/A 421 0 R
-/Parent 347 0 R
-/Prev 419 0 R
->> endobj
-419 0 obj <<
-/Title 420 0 R
-/A 417 0 R
-/Parent 347 0 R
-/Prev 415 0 R
-/Next 423 0 R
->> endobj
-415 0 obj <<
-/Title 416 0 R
-/A 413 0 R
-/Parent 347 0 R
-/Prev 411 0 R
-/Next 419 0 R
->> endobj
-411 0 obj <<
-/Title 412 0 R
-/A 409 0 R
-/Parent 347 0 R
-/Prev 407 0 R
-/Next 415 0 R
->> endobj
-407 0 obj <<
-/Title 408 0 R
-/A 405 0 R
-/Parent 347 0 R
-/Prev 403 0 R
-/Next 411 0 R
->> endobj
-403 0 obj <<
-/Title 404 0 R
-/A 401 0 R
-/Parent 347 0 R
-/Prev 399 0 R
-/Next 407 0 R
->> endobj
-399 0 obj <<
-/Title 400 0 R
-/A 397 0 R
-/Parent 347 0 R
-/Prev 395 0 R
-/Next 403 0 R
->> endobj
-395 0 obj <<
-/Title 396 0 R
-/A 393 0 R
-/Parent 347 0 R
-/Prev 391 0 R
-/Next 399 0 R
->> endobj
-391 0 obj <<
-/Title 392 0 R
-/A 389 0 R
-/Parent 347 0 R
-/Prev 387 0 R
-/Next 395 0 R
->> endobj
-387 0 obj <<
-/Title 388 0 R
-/A 385 0 R
-/Parent 347 0 R
-/Prev 383 0 R
-/Next 391 0 R
->> endobj
-383 0 obj <<
-/Title 384 0 R
-/A 381 0 R
-/Parent 347 0 R
-/Prev 379 0 R
-/Next 387 0 R
->> endobj
-379 0 obj <<
-/Title 380 0 R
-/A 377 0 R
-/Parent 347 0 R
-/Prev 375 0 R
-/Next 383 0 R
->> endobj
-375 0 obj <<
-/Title 376 0 R
-/A 373 0 R
-/Parent 347 0 R
-/Prev 371 0 R
-/Next 379 0 R
->> endobj
-371 0 obj <<
-/Title 372 0 R
-/A 369 0 R
-/Parent 347 0 R
-/Prev 367 0 R
-/Next 375 0 R
->> endobj
-367 0 obj <<
-/Title 368 0 R
-/A 365 0 R
-/Parent 347 0 R
-/Prev 363 0 R
-/Next 371 0 R
->> endobj
-363 0 obj <<
-/Title 364 0 R
-/A 361 0 R
-/Parent 347 0 R
-/Prev 359 0 R
-/Next 367 0 R
->> endobj
-359 0 obj <<
-/Title 360 0 R
-/A 357 0 R
-/Parent 347 0 R
-/Prev 355 0 R
-/Next 363 0 R
->> endobj
-355 0 obj <<
-/Title 356 0 R
-/A 353 0 R
-/Parent 347 0 R
-/Prev 351 0 R
-/Next 359 0 R
->> endobj
-351 0 obj <<
-/Title 352 0 R
-/A 349 0 R
-/Parent 347 0 R
-/Next 355 0 R
->> endobj
-347 0 obj <<
-/Title 348 0 R
-/A 345 0 R
-/Parent 275 0 R
-/Prev 343 0 R
-/Next 427 0 R
-/First 351 0 R
-/Last 423 0 R
-/Count -19
->> endobj
-343 0 obj <<
-/Title 344 0 R
-/A 341 0 R
-/Parent 275 0 R
-/Prev 339 0 R
-/Next 347 0 R
->> endobj
-339 0 obj <<
-/Title 340 0 R
-/A 337 0 R
-/Parent 275 0 R
-/Prev 335 0 R
-/Next 343 0 R
->> endobj
-335 0 obj <<
-/Title 336 0 R
-/A 333 0 R
-/Parent 275 0 R
-/Prev 331 0 R
-/Next 339 0 R
->> endobj
-331 0 obj <<
-/Title 332 0 R
-/A 329 0 R
-/Parent 275 0 R
-/Prev 327 0 R
-/Next 335 0 R
->> endobj
-327 0 obj <<
-/Title 328 0 R
-/A 325 0 R
-/Parent 275 0 R
-/Prev 315 0 R
-/Next 331 0 R
->> endobj
-323 0 obj <<
-/Title 324 0 R
-/A 321 0 R
-/Parent 315 0 R
-/Prev 319 0 R
->> endobj
-319 0 obj <<
-/Title 320 0 R
-/A 317 0 R
-/Parent 315 0 R
-/Next 323 0 R
->> endobj
-315 0 obj <<
-/Title 316 0 R
-/A 313 0 R
-/Parent 275 0 R
-/Prev 311 0 R
-/Next 327 0 R
-/First 319 0 R
-/Last 323 0 R
-/Count -2
->> endobj
-311 0 obj <<
-/Title 312 0 R
-/A 309 0 R
-/Parent 275 0 R
-/Prev 307 0 R
-/Next 315 0 R
->> endobj
-307 0 obj <<
-/Title 308 0 R
-/A 305 0 R
-/Parent 275 0 R
-/Prev 303 0 R
-/Next 311 0 R
->> endobj
-303 0 obj <<
-/Title 304 0 R
-/A 301 0 R
-/Parent 275 0 R
-/Prev 299 0 R
-/Next 307 0 R
->> endobj
-299 0 obj <<
-/Title 300 0 R
-/A 297 0 R
-/Parent 275 0 R
-/Prev 295 0 R
-/Next 303 0 R
->> endobj
-295 0 obj <<
-/Title 296 0 R
-/A 293 0 R
-/Parent 275 0 R
-/Prev 291 0 R
-/Next 299 0 R
->> endobj
-291 0 obj <<
-/Title 292 0 R
-/A 289 0 R
-/Parent 275 0 R
-/Prev 287 0 R
-/Next 295 0 R
->> endobj
-287 0 obj <<
-/Title 288 0 R
-/A 285 0 R
-/Parent 275 0 R
-/Prev 283 0 R
-/Next 291 0 R
->> endobj
-283 0 obj <<
-/Title 284 0 R
-/A 281 0 R
-/Parent 275 0 R
-/Prev 279 0 R
-/Next 287 0 R
->> endobj
-279 0 obj <<
-/Title 280 0 R
-/A 277 0 R
-/Parent 275 0 R
-/Next 283 0 R
->> endobj
-275 0 obj <<
-/Title 276 0 R
-/A 273 0 R
-/Parent 243 0 R
-/Prev 247 0 R
-/Next 475 0 R
-/First 279 0 R
-/Last 455 0 R
-/Count -24
->> endobj
-271 0 obj <<
-/Title 272 0 R
-/A 269 0 R
-/Parent 263 0 R
-/Prev 267 0 R
->> endobj
-267 0 obj <<
-/Title 268 0 R
-/A 265 0 R
-/Parent 263 0 R
-/Next 271 0 R
->> endobj
-263 0 obj <<
-/Title 264 0 R
-/A 261 0 R
-/Parent 247 0 R
-/Prev 251 0 R
-/First 267 0 R
-/Last 271 0 R
-/Count -2
->> endobj
-259 0 obj <<
-/Title 260 0 R
-/A 257 0 R
-/Parent 251 0 R
-/Prev 255 0 R
->> endobj
-255 0 obj <<
-/Title 256 0 R
-/A 253 0 R
-/Parent 251 0 R
-/Next 259 0 R
->> endobj
-251 0 obj <<
-/Title 252 0 R
-/A 249 0 R
-/Parent 247 0 R
-/Next 263 0 R
-/First 255 0 R
-/Last 259 0 R
-/Count -2
->> endobj
-247 0 obj <<
-/Title 248 0 R
-/A 245 0 R
-/Parent 243 0 R
-/Next 275 0 R
-/First 251 0 R
-/Last 263 0 R
-/Count -2
->> endobj
-243 0 obj <<
-/Title 244 0 R
-/A 241 0 R
-/Parent 1942 0 R
-/Prev 231 0 R
-/Next 527 0 R
-/First 247 0 R
-/Last 475 0 R
-/Count -3
->> endobj
-239 0 obj <<
-/Title 240 0 R
-/A 237 0 R
-/Parent 231 0 R
-/Prev 235 0 R
->> endobj
-235 0 obj <<
-/Title 236 0 R
-/A 233 0 R
-/Parent 231 0 R
-/Next 239 0 R
->> endobj
-231 0 obj <<
-/Title 232 0 R
-/A 229 0 R
-/Parent 1942 0 R
-/Prev 131 0 R
-/Next 243 0 R
-/First 235 0 R
-/Last 239 0 R
-/Count -2
->> endobj
-227 0 obj <<
-/Title 228 0 R
-/A 225 0 R
-/Parent 219 0 R
-/Prev 223 0 R
->> endobj
-223 0 obj <<
-/Title 224 0 R
-/A 221 0 R
-/Parent 219 0 R
-/Next 227 0 R
->> endobj
-219 0 obj <<
-/Title 220 0 R
-/A 217 0 R
-/Parent 131 0 R
-/Prev 203 0 R
-/First 223 0 R
-/Last 227 0 R
-/Count -2
->> endobj
-215 0 obj <<
-/Title 216 0 R
-/A 213 0 R
-/Parent 203 0 R
-/Prev 211 0 R
->> endobj
-211 0 obj <<
-/Title 212 0 R
-/A 209 0 R
-/Parent 203 0 R
-/Prev 207 0 R
-/Next 215 0 R
->> endobj
-207 0 obj <<
-/Title 208 0 R
-/A 205 0 R
-/Parent 203 0 R
-/Next 211 0 R
->> endobj
-203 0 obj <<
-/Title 204 0 R
-/A 201 0 R
-/Parent 131 0 R
-/Prev 199 0 R
-/Next 219 0 R
-/First 207 0 R
-/Last 215 0 R
-/Count -3
->> endobj
-199 0 obj <<
-/Title 200 0 R
-/A 197 0 R
-/Parent 131 0 R
-/Prev 195 0 R
-/Next 203 0 R
->> endobj
-195 0 obj <<
-/Title 196 0 R
-/A 193 0 R
-/Parent 131 0 R
-/Prev 159 0 R
-/Next 199 0 R
->> endobj
-191 0 obj <<
-/Title 192 0 R
-/A 189 0 R
-/Parent 159 0 R
-/Prev 187 0 R
->> endobj
-187 0 obj <<
-/Title 188 0 R
-/A 185 0 R
-/Parent 159 0 R
-/Prev 183 0 R
-/Next 191 0 R
->> endobj
-183 0 obj <<
-/Title 184 0 R
-/A 181 0 R
-/Parent 159 0 R
-/Prev 179 0 R
-/Next 187 0 R
->> endobj
-179 0 obj <<
-/Title 180 0 R
-/A 177 0 R
-/Parent 159 0 R
-/Prev 175 0 R
-/Next 183 0 R
->> endobj
-175 0 obj <<
-/Title 176 0 R
-/A 173 0 R
-/Parent 159 0 R
-/Prev 163 0 R
-/Next 179 0 R
->> endobj
-171 0 obj <<
-/Title 172 0 R
-/A 169 0 R
-/Parent 163 0 R
-/Prev 167 0 R
->> endobj
-167 0 obj <<
-/Title 168 0 R
-/A 165 0 R
-/Parent 163 0 R
-/Next 171 0 R
->> endobj
-163 0 obj <<
-/Title 164 0 R
-/A 161 0 R
-/Parent 159 0 R
-/Next 175 0 R
-/First 167 0 R
-/Last 171 0 R
-/Count -2
->> endobj
-159 0 obj <<
-/Title 160 0 R
-/A 157 0 R
-/Parent 131 0 R
-/Prev 151 0 R
-/Next 195 0 R
-/First 163 0 R
-/Last 191 0 R
-/Count -6
->> endobj
-155 0 obj <<
-/Title 156 0 R
-/A 153 0 R
-/Parent 151 0 R
->> endobj
-151 0 obj <<
-/Title 152 0 R
-/A 149 0 R
-/Parent 131 0 R
-/Prev 147 0 R
-/Next 159 0 R
-/First 155 0 R
-/Last 155 0 R
-/Count -1
->> endobj
-147 0 obj <<
-/Title 148 0 R
-/A 145 0 R
-/Parent 131 0 R
-/Prev 139 0 R
-/Next 151 0 R
->> endobj
-143 0 obj <<
-/Title 144 0 R
-/A 141 0 R
-/Parent 139 0 R
->> endobj
-139 0 obj <<
-/Title 140 0 R
-/A 137 0 R
-/Parent 131 0 R
-/Prev 135 0 R
-/Next 147 0 R
-/First 143 0 R
-/Last 143 0 R
-/Count -1
->> endobj
-135 0 obj <<
-/Title 136 0 R
-/A 133 0 R
-/Parent 131 0 R
-/Next 139 0 R
->> endobj
-131 0 obj <<
-/Title 132 0 R
-/A 129 0 R
-/Parent 1942 0 R
-/Prev 91 0 R
-/Next 231 0 R
-/First 135 0 R
-/Last 219 0 R
-/Count -9
->> endobj
-127 0 obj <<
-/Title 128 0 R
-/A 125 0 R
-/Parent 111 0 R
-/Prev 115 0 R
->> endobj
-123 0 obj <<
-/Title 124 0 R
-/A 121 0 R
-/Parent 115 0 R
-/Prev 119 0 R
->> endobj
-119 0 obj <<
-/Title 120 0 R
-/A 117 0 R
-/Parent 115 0 R
-/Next 123 0 R
->> endobj
-115 0 obj <<
-/Title 116 0 R
-/A 113 0 R
-/Parent 111 0 R
-/Next 127 0 R
-/First 119 0 R
-/Last 123 0 R
-/Count -2
->> endobj
-111 0 obj <<
-/Title 112 0 R
-/A 109 0 R
-/Parent 91 0 R
-/Prev 107 0 R
-/First 115 0 R
-/Last 127 0 R
-/Count -2
->> endobj
-107 0 obj <<
-/Title 108 0 R
-/A 105 0 R
-/Parent 91 0 R
-/Prev 95 0 R
-/Next 111 0 R
->> endobj
-103 0 obj <<
-/Title 104 0 R
-/A 101 0 R
-/Parent 95 0 R
-/Prev 99 0 R
->> endobj
-99 0 obj <<
-/Title 100 0 R
-/A 97 0 R
-/Parent 95 0 R
-/Next 103 0 R
->> endobj
-95 0 obj <<
-/Title 96 0 R
-/A 93 0 R
-/Parent 91 0 R
-/Next 107 0 R
-/First 99 0 R
-/Last 103 0 R
-/Count -2
->> endobj
-91 0 obj <<
-/Title 92 0 R
-/A 89 0 R
-/Parent 1942 0 R
-/Prev 67 0 R
-/Next 131 0 R
-/First 95 0 R
-/Last 111 0 R
-/Count -3
->> endobj
-87 0 obj <<
-/Title 88 0 R
-/A 85 0 R
-/Parent 67 0 R
-/Prev 83 0 R
->> endobj
-83 0 obj <<
-/Title 84 0 R
-/A 81 0 R
-/Parent 67 0 R
-/Prev 79 0 R
-/Next 87 0 R
->> endobj
-79 0 obj <<
-/Title 80 0 R
-/A 77 0 R
-/Parent 67 0 R
-/Prev 75 0 R
-/Next 83 0 R
->> endobj
-75 0 obj <<
-/Title 76 0 R
-/A 73 0 R
-/Parent 67 0 R
-/Prev 71 0 R
-/Next 79 0 R
->> endobj
-71 0 obj <<
-/Title 72 0 R
-/A 69 0 R
-/Parent 67 0 R
-/Next 75 0 R
->> endobj
-67 0 obj <<
-/Title 68 0 R
-/A 65 0 R
-/Parent 1942 0 R
-/Prev 7 0 R
-/Next 91 0 R
-/First 71 0 R
-/Last 87 0 R
-/Count -5
->> endobj
-63 0 obj <<
-/Title 64 0 R
-/A 61 0 R
-/Parent 23 0 R
-/Prev 55 0 R
->> endobj
-59 0 obj <<
-/Title 60 0 R
-/A 57 0 R
-/Parent 55 0 R
->> endobj
-55 0 obj <<
-/Title 56 0 R
-/A 53 0 R
-/Parent 23 0 R
-/Prev 39 0 R
-/Next 63 0 R
-/First 59 0 R
-/Last 59 0 R
-/Count -1
->> endobj
-51 0 obj <<
-/Title 52 0 R
-/A 49 0 R
-/Parent 39 0 R
-/Prev 47 0 R
->> endobj
-47 0 obj <<
-/Title 48 0 R
-/A 45 0 R
-/Parent 39 0 R
-/Prev 43 0 R
-/Next 51 0 R
->> endobj
-43 0 obj <<
-/Title 44 0 R
-/A 41 0 R
-/Parent 39 0 R
-/Next 47 0 R
->> endobj
-39 0 obj <<
-/Title 40 0 R
-/A 37 0 R
-/Parent 23 0 R
-/Prev 35 0 R
-/Next 55 0 R
-/First 43 0 R
-/Last 51 0 R
-/Count -3
->> endobj
-35 0 obj <<
-/Title 36 0 R
-/A 33 0 R
-/Parent 23 0 R
-/Prev 31 0 R
-/Next 39 0 R
->> endobj
-31 0 obj <<
-/Title 32 0 R
-/A 29 0 R
-/Parent 23 0 R
-/Prev 27 0 R
-/Next 35 0 R
->> endobj
-27 0 obj <<
-/Title 28 0 R
-/A 25 0 R
-/Parent 23 0 R
-/Next 31 0 R
->> endobj
-23 0 obj <<
-/Title 24 0 R
-/A 21 0 R
-/Parent 7 0 R
-/Prev 19 0 R
-/First 27 0 R
-/Last 63 0 R
-/Count -6
->> endobj
-19 0 obj <<
-/Title 20 0 R
-/A 17 0 R
-/Parent 7 0 R
-/Prev 15 0 R
-/Next 23 0 R
->> endobj
-15 0 obj <<
-/Title 16 0 R
-/A 13 0 R
-/Parent 7 0 R
-/Prev 11 0 R
-/Next 19 0 R
->> endobj
-11 0 obj <<
-/Title 12 0 R
-/A 9 0 R
-/Parent 7 0 R
-/Next 15 0 R
->> endobj
-7 0 obj <<
-/Title 8 0 R
-/A 5 0 R
-/Parent 1942 0 R
-/Next 67 0 R
-/First 11 0 R
-/Last 23 0 R
-/Count -4
->> endobj
-1943 0 obj <<
-/Names [(Access_Control_Lists) 1477 0 R (Bv9ARM.ch01) 874 0 R (Bv9ARM.ch02) 923 0 R (Bv9ARM.ch03) 940 0 R (Bv9ARM.ch04) 989 0 R (Bv9ARM.ch05) 1077 0 R (Bv9ARM.ch06) 1088 0 R (Bv9ARM.ch07) 1476 0 R (Bv9ARM.ch08) 1502 0 R (Bv9ARM.ch09) 1517 0 R (Bv9ARM.ch10) 1738 0 R (Configuration_File_Grammar) 1113 0 R (DNSSEC) 1056 0 R (Doc-Start) 655 0 R (Setting_TTLs) 1446 0 R (acache) 930 0 R (access_control) 1231 0 R (acl) 1121 0 R (address_match_lists) 1094 0 R (admin_tools) 963 0 R (appendix.A) 570 0 R (appendix.B) 606 0 R (bibliography) 1525 0 R (boolean_options) 1005 0 R (builtin) 1300 0 R (chapter*.1) 690 0 R (chapter.1) 6 0 R (chapter.2) 66 0 R (chapter.3) 90 0 R (chapter.4) 130 0 R (chapter.5) 230 0 R (chapter.6) 242 0 R (chapter.7) 526 0 R (chapter.8) 550 0 R (cite.RFC1033) 1653 0 R (cite.RFC1034) 1537 0 R (cite.RFC1035) 1539 0 R (cite.RFC1101) 1635 0 R (cite.RFC1123) 1637 0 R (cite.RFC1183) 1597 0 R (cite.RFC1464) 1675 0 R (cite.RFC1535) 1582 0 R (cite.RFC1536) 1584 0 R (cite.RFC1537) 1655 0 R (cite.RFC1591) 1639 0 R (cite.RFC1706) 1599 0 R (cite.RFC1712) 1695 0 R (cite.RFC1713) 1677 0 R (cite.RFC1794) 1679 0 R (cite.RFC1876) 1601 0 R (cite.RFC1912) 1657 0 R (cite.RFC1982) 1586 0 R (cite.RFC1995) 1544 0 R (cite.RFC1996) 1546 0 R (cite.RFC2010) 1659 0 R (cite.RFC2052) 1603 0 R (cite.RFC2065) 1707 0 R (cite.RFC2136) 1548 0 R (cite.RFC2137) 1709 0 R (cite.RFC2163) 1605 0 R (cite.RFC2168) 1607 0 R (cite.RFC2181) 1550 0 R (cite.RFC2219) 1661 0 R (cite.RFC2230) 1609 0 R (cite.RFC2240) 1681 0 R (cite.RFC2308) 1552 0 R (cite.RFC2317) 1641 0 R (cite.RFC2345) 1683 0 R (cite.RFC2352) 1685 0 R (cite.RFC2535) 1711 0 R (cite.RFC2536) 1611 0 R (cite.RFC2537) 1613 0 R (cite.RFC2538) 1615 0 R (cite.RFC2539) 1617 0 R (cite.RFC2540) 1619 0 R (cite.RFC2671) 1554 0 R (cite.RFC2672) 1556 0 R (cite.RFC2673) 1697 0 R (cite.RFC2782) 1621 0 R (cite.RFC2825) 1665 0 R (cite.RFC2826) 1643 0 R (cite.RFC2845) 1558 0 R (cite.RFC2874) 1699 0 R (cite.RFC2915) 1623 0 R (cite.RFC2929) 1645 0 R (cite.RFC2930) 1560 0 R (cite.RFC2931) 1562 0 R (cite.RFC3007) 1564 0 R (cite.RFC3008) 1713 0 R (cite.RFC3071) 1687 0 R (cite.RFC3090) 1715 0 R (cite.RFC3110) 1625 0 R (cite.RFC3123) 1627 0 R (cite.RFC3225) 1570 0 R (cite.RFC3258) 1689 0 R (cite.RFC3445) 1717 0 R (cite.RFC3490) 1667 0 R (cite.RFC3491) 1669 0 R (cite.RFC3492) 1671 0 R (cite.RFC3596) 1629 0 R (cite.RFC3597) 1631 0 R (cite.RFC3645) 1566 0 R (cite.RFC3655) 1719 0 R (cite.RFC3658) 1721 0 R (cite.RFC3755) 1723 0 R (cite.RFC3757) 1725 0 R (cite.RFC3833) 1572 0 R (cite.RFC3845) 1727 0 R (cite.RFC3901) 1691 0 R (cite.RFC4033) 1574 0 R (cite.RFC4035) 1576 0 R (cite.RFC4044) 1578 0 R (cite.RFC4074) 1588 0 R (cite.RFC974) 1541 0 R (cite.id2499701) 1732 0 R (configuration_file_elements) 1089 0 R (controls_statement_definition_and_usage) 976 0 R (diagnostic_tools) 911 0 R (dynamic_update) 999 0 R (dynamic_update_policies) 1051 0 R (dynamic_update_security) 1235 0 R (empty) 1302 0 R (historical_dns_information) 1519 0 R (id2465026) 875 0 R (id2466484) 876 0 R (id2467305) 880 0 R (id2467506) 881 0 R (id2467714) 891 0 R (id2467891) 893 0 R (id2467912) 894 0 R (id2467946) 895 0 R (id2468030) 898 0 R (id2470292) 905 0 R (id2470315) 908 0 R (id2470345) 909 0 R (id2470435) 910 0 R (id2470465) 916 0 R (id2470500) 917 0 R (id2470595) 918 0 R (id2470629) 924 0 R (id2470656) 925 0 R (id2470668) 926 0 R (id2470694) 929 0 R (id2470705) 935 0 R (id2470805) 942 0 R (id2470821) 943 0 R (id2470843) 949 0 R (id2470860) 950 0 R (id2471334) 953 0 R (id2471339) 954 0 R (id2473122) 981 0 R (id2473133) 982 0 R (id2473511) 1014 0 R (id2473529) 1015 0 R (id2473964) 1031 0 R (id2473981) 1032 0 R (id2474020) 1037 0 R (id2474038) 1038 0 R (id2474049) 1039 0 R (id2474156) 1040 0 R (id2474282) 1041 0 R (id2474327) 1047 0 R (id2474341) 1048 0 R (id2474390) 1049 0 R (id2474595) 1057 0 R (id2474732) 1058 0 R (id2474811) 1063 0 R (id2474954) 1068 0 R (id2475084) 1070 0 R (id2475106) 1071 0 R (id2475139) 1078 0 R (id2475354) 1090 0 R (id2476147) 1099 0 R (id2476174) 1100 0 R (id2476281) 1105 0 R (id2476296) 1106 0 R (id2476394) 1107 0 R (id2476477) 1114 0 R (id2476893) 1120 0 R (id2476936) 1122 0 R (id2477152) 1124 0 R (id2477512) 1131 0 R (id2477527) 1132 0 R (id2477550) 1133 0 R (id2477572) 1134 0 R (id2477662) 1143 0 R (id2477857) 1144 0 R (id2477909) 1150 0 R (id2478602) 1161 0 R (id2479412) 1167 0 R (id2479485) 1168 0 R (id2479549) 1175 0 R (id2479593) 1176 0 R (id2479608) 1177 0 R (id2481708) 1202 0 R (id2483474) 1224 0 R (id2483532) 1230 0 R (id2483954) 1241 0 R (id2484042) 1246 0 R (id2484857) 1255 0 R (id2484872) 1261 0 R (id2485056) 1263 0 R (id2485257) 1269 0 R (id2485688) 1283 0 R (id2486990) 1313 0 R (id2488093) 1330 0 R (id2488142) 1331 0 R (id2488222) 1337 0 R (id2489668) 1351 0 R (id2489675) 1352 0 R (id2489681) 1353 0 R (id2490299) 1359 0 R (id2490332) 1364 0 R (id2491624) 1406 0 R (id2491881) 1412 0 R (id2491899) 1413 0 R (id2491920) 1416 0 R (id2492156) 1422 0 R (id2493254) 1428 0 R (id2493382) 1430 0 R (id2493403) 1435 0 R (id2493834) 1437 0 R (id2493971) 1439 0 R (id2494061) 1440 0 R (id2494466) 1447 0 R (id2494590) 1449 0 R (id2494605) 1450 0 R (id2494717) 1452 0 R (id2494876) 1458 0 R (id2494937) 1459 0 R (id2495006) 1460 0 R (id2495043) 1461 0 R (id2495105) 1466 0 R (id2495584) 1486 0 R (id2495729) 1487 0 R (id2495788) 1488 0 R (id2495868) 1503 0 R (id2495874) 1504 0 R (id2495885) 1505 0 R (id2496039) 1506 0 R (id2496101) 1518 0 R (id2496273) 1524 0 R (id2496529) 1529 0 R (id2496531) 1535 0 R (id2496539) 1540 0 R (id2496563) 1536 0 R (id2496586) 1538 0 R (id2496622) 1549 0 R (id2496649) 1551 0 R (id2496675) 1543 0 R (id2496699) 1545 0 R (id2496791) 1547 0 R (id2496846) 1553 0 R (id2496873) 1555 0 R (id2496900) 1557 0 R (id2496962) 1559 0 R (id2496992) 1561 0 R (id2497021) 1563 0 R (id2497048) 1565 0 R (id2497123) 1568 0 R (id2497198) 1569 0 R (id2497225) 1571 0 R (id2497261) 1573 0 R (id2497326) 1577 0 R (id2497392) 1575 0 R (id2497457) 1580 0 R (id2497465) 1581 0 R (id2497559) 1583 0 R (id2497627) 1585 0 R (id2497662) 1587 0 R (id2497703) 1595 0 R (id2497708) 1596 0 R (id2497766) 1598 0 R (id2497803) 1606 0 R (id2497838) 1600 0 R (id2497893) 1602 0 R (id2497931) 1604 0 R (id2497957) 1608 0 R (id2497982) 1610 0 R (id2498009) 1612 0 R (id2498036) 1614 0 R (id2498075) 1616 0 R (id2498105) 1618 0 R (id2498135) 1620 0 R (id2498178) 1622 0 R (id2498211) 1624 0 R (id2498237) 1626 0 R (id2498261) 1628 0 R (id2498318) 1630 0 R (id2498343) 1633 0 R (id2498350) 1634 0 R (id2498376) 1636 0 R (id2498398) 1638 0 R (id2498422) 1640 0 R (id2498468) 1642 0 R (id2498491) 1644 0 R (id2498541) 1651 0 R (id2498549) 1652 0 R (id2498572) 1654 0 R (id2498599) 1656 0 R (id2498626) 1658 0 R (id2498662) 1660 0 R (id2498702) 1663 0 R (id2498708) 1664 0 R (id2498740) 1666 0 R (id2498854) 1668 0 R (id2498889) 1670 0 R (id2498916) 1673 0 R (id2498934) 1674 0 R (id2498956) 1676 0 R (id2498982) 1678 0 R (id2499008) 1680 0 R (id2499031) 1682 0 R (id2499077) 1684 0 R (id2499100) 1686 0 R (id2499127) 1688 0 R (id2499153) 1690 0 R (id2499190) 1693 0 R (id2499196) 1694 0 R (id2499254) 1696 0 R (id2499281) 1698 0 R (id2499317) 1705 0 R (id2499329) 1706 0 R (id2499368) 1708 0 R (id2499395) 1710 0 R (id2499425) 1712 0 R (id2499450) 1714 0 R (id2499477) 1716 0 R (id2499513) 1718 0 R (id2499549) 1720 0 R (id2499576) 1722 0 R (id2499603) 1724 0 R (id2499648) 1726 0 R (id2499689) 1729 0 R (id2499699) 1731 0 R (id2499701) 1733 0 R (incremental_zone_transfers) 1011 0 R (internet_drafts) 1728 0 R (ipv6addresses) 1072 0 R (journal) 1000 0 R (lwresd) 1079 0 R (man.dig) 1739 0 R (man.dnssec-keygen) 1787 0 R (man.dnssec-signzone) 1805 0 R (man.host) 1772 0 R (man.named) 1854 0 R (man.named-checkconf) 1825 0 R (man.named-checkzone) 1837 0 R (man.rndc) 1876 0 R (man.rndc-confgen) 1905 0 R (man.rndc.conf) 1888 0 R (notify) 990 0 R (options) 1187 0 R (page.1) 654 0 R (page.10) 915 0 R (page.100) 1767 0 R (page.101) 1779 0 R (page.102) 1783 0 R (page.103) 1795 0 R (page.104) 1801 0 R (page.105) 1812 0 R (page.106) 1817 0 R (page.107) 1822 0 R (page.108) 1833 0 R (page.109) 1845 0 R (page.11) 922 0 R (page.110) 1850 0 R (page.111) 1861 0 R (page.112) 1866 0 R (page.113) 1873 0 R (page.114) 1884 0 R (page.115) 1895 0 R (page.116) 1901 0 R (page.117) 1911 0 R (page.118) 1917 0 R (page.12) 934 0 R (page.13) 939 0 R (page.14) 948 0 R (page.15) 959 0 R (page.16) 967 0 R (page.17) 974 0 R (page.18) 980 0 R (page.19) 988 0 R (page.2) 679 0 R (page.20) 1010 0 R (page.21) 1020 0 R (page.22) 1025 0 R (page.23) 1029 0 R (page.24) 1036 0 R (page.25) 1045 0 R (page.26) 1055 0 R (page.27) 1062 0 R (page.28) 1067 0 R (page.29) 1076 0 R (page.3) 689 0 R (page.30) 1083 0 R (page.31) 1087 0 R (page.32) 1098 0 R (page.33) 1104 0 R (page.34) 1112 0 R (page.35) 1119 0 R (page.36) 1128 0 R (page.37) 1141 0 R (page.38) 1149 0 R (page.39) 1154 0 R (page.4) 744 0 R (page.40) 1160 0 R (page.41) 1166 0 R (page.42) 1174 0 R (page.43) 1181 0 R (page.44) 1186 0 R (page.45) 1191 0 R (page.46) 1197 0 R (page.47) 1201 0 R (page.48) 1208 0 R (page.49) 1218 0 R (page.5) 808 0 R (page.50) 1223 0 R (page.51) 1228 0 R (page.52) 1239 0 R (page.53) 1245 0 R (page.54) 1250 0 R (page.55) 1254 0 R (page.56) 1260 0 R (page.57) 1268 0 R (page.58) 1274 0 R (page.59) 1281 0 R (page.6) 869 0 R (page.60) 1289 0 R (page.61) 1296 0 R (page.62) 1308 0 R (page.63) 1312 0 R (page.64) 1318 0 R (page.65) 1323 0 R (page.66) 1327 0 R (page.67) 1336 0 R (page.68) 1342 0 R (page.69) 1346 0 R (page.7) 873 0 R (page.70) 1350 0 R (page.71) 1358 0 R (page.72) 1363 0 R (page.73) 1380 0 R (page.74) 1396 0 R (page.75) 1411 0 R (page.76) 1421 0 R (page.77) 1427 0 R (page.78) 1434 0 R (page.79) 1445 0 R (page.8) 890 0 R (page.80) 1457 0 R (page.81) 1465 0 R (page.82) 1471 0 R (page.83) 1475 0 R (page.84) 1481 0 R (page.85) 1492 0 R (page.86) 1497 0 R (page.87) 1501 0 R (page.88) 1512 0 R (page.89) 1516 0 R (page.9) 904 0 R (page.90) 1523 0 R (page.91) 1533 0 R (page.92) 1593 0 R (page.93) 1649 0 R (page.94) 1703 0 R (page.95) 1737 0 R (page.96) 1746 0 R (page.97) 1752 0 R (page.98) 1758 0 R (page.99) 1762 0 R (proposed_standards) 1016 0 R (rfcs) 900 0 R (rndc) 1137 0 R (rrset_ordering) 955 0 R (sample_configuration) 941 0 R (section*.10) 1662 0 R (section*.11) 1672 0 R (section*.12) 1692 0 R (section*.13) 1704 0 R (section*.14) 1730 0 R (section*.15) 1740 0 R (section*.16) 1741 0 R (section*.17) 1742 0 R (section*.18) 1747 0 R (section*.19) 1748 0 R (section*.2) 1528 0 R (section*.20) 1753 0 R (section*.21) 1763 0 R (section*.22) 1768 0 R (section*.23) 1769 0 R (section*.24) 1770 0 R (section*.25) 1771 0 R (section*.26) 1773 0 R (section*.27) 1774 0 R (section*.28) 1775 0 R (section*.29) 1784 0 R (section*.3) 1534 0 R (section*.30) 1785 0 R (section*.31) 1786 0 R (section*.32) 1788 0 R (section*.33) 1789 0 R (section*.34) 1790 0 R (section*.35) 1791 0 R (section*.36) 1796 0 R (section*.37) 1802 0 R (section*.38) 1803 0 R (section*.39) 1804 0 R (section*.4) 1542 0 R (section*.40) 1806 0 R (section*.41) 1807 0 R (section*.42) 1808 0 R (section*.43) 1813 0 R (section*.44) 1818 0 R (section*.45) 1823 0 R (section*.46) 1824 0 R (section*.47) 1826 0 R (section*.48) 1827 0 R (section*.49) 1828 0 R (section*.5) 1567 0 R (section*.50) 1829 0 R (section*.51) 1834 0 R (section*.52) 1835 0 R (section*.53) 1836 0 R (section*.54) 1838 0 R (section*.55) 1839 0 R (section*.56) 1840 0 R (section*.57) 1841 0 R (section*.58) 1851 0 R (section*.59) 1852 0 R (section*.6) 1579 0 R (section*.60) 1853 0 R (section*.61) 1855 0 R (section*.62) 1856 0 R (section*.63) 1857 0 R (section*.64) 1862 0 R (section*.65) 1867 0 R (section*.66) 1868 0 R (section*.67) 1869 0 R (section*.68) 1874 0 R (section*.69) 1875 0 R (section*.7) 1594 0 R (section*.70) 1877 0 R (section*.71) 1878 0 R (section*.72) 1879 0 R (section*.73) 1880 0 R (section*.74) 1885 0 R (section*.75) 1886 0 R (section*.76) 1887 0 R (section*.77) 1889 0 R (section*.78) 1890 0 R (section*.79) 1891 0 R (section*.8) 1632 0 R (section*.80) 1896 0 R (section*.81) 1902 0 R (section*.82) 1903 0 R (section*.83) 1904 0 R (section*.84) 1906 0 R (section*.85) 1907 0 R (section*.86) 1912 0 R (section*.87) 1913 0 R (section*.88) 1918 0 R (section*.89) 1919 0 R (section*.9) 1650 0 R (section*.90) 1920 0 R (section.1.1) 10 0 R (section.1.2) 14 0 R (section.1.3) 18 0 R (section.1.4) 22 0 R (section.2.1) 70 0 R (section.2.2) 74 0 R (section.2.3) 78 0 R (section.2.4) 82 0 R (section.2.5) 86 0 R (section.3.1) 94 0 R (section.3.2) 106 0 R (section.3.3) 110 0 R (section.4.1) 134 0 R (section.4.2) 138 0 R (section.4.3) 146 0 R (section.4.4) 150 0 R (section.4.5) 158 0 R (section.4.6) 194 0 R (section.4.7) 198 0 R (section.4.8) 202 0 R (section.4.9) 218 0 R (section.5.1) 234 0 R (section.5.2) 238 0 R (section.6.1) 246 0 R (section.6.2) 274 0 R (section.6.3) 474 0 R (section.7.1) 530 0 R (section.7.2) 534 0 R (section.7.3) 546 0 R (section.8.1) 554 0 R (section.8.2) 562 0 R (section.8.3) 566 0 R (section.A.1) 574 0 R (section.A.2) 582 0 R (section.A.3) 590 0 R (section.B.1) 610 0 R (section.B.10) 646 0 R (section.B.2) 614 0 R (section.B.3) 618 0 R (section.B.4) 622 0 R (section.B.5) 626 0 R (section.B.6) 630 0 R (section.B.7) 634 0 R (section.B.8) 638 0 R (section.B.9) 642 0 R (server_statement_definition_and_usage) 1214 0 R (server_statement_grammar) 1319 0 R (statsfile) 1193 0 R (subsection.1.4.1) 26 0 R (subsection.1.4.2) 30 0 R (subsection.1.4.3) 34 0 R (subsection.1.4.4) 38 0 R (subsection.1.4.5) 54 0 R (subsection.1.4.6) 62 0 R (subsection.3.1.1) 98 0 R (subsection.3.1.2) 102 0 R (subsection.3.3.1) 114 0 R (subsection.3.3.2) 126 0 R (subsection.4.2.1) 142 0 R (subsection.4.4.1) 154 0 R (subsection.4.5.1) 162 0 R (subsection.4.5.2) 174 0 R (subsection.4.5.3) 178 0 R (subsection.4.5.4) 182 0 R (subsection.4.5.5) 186 0 R (subsection.4.5.6) 190 0 R (subsection.4.8.1) 206 0 R (subsection.4.8.2) 210 0 R (subsection.4.8.3) 214 0 R (subsection.4.9.1) 222 0 R (subsection.4.9.2) 226 0 R (subsection.6.1.1) 250 0 R (subsection.6.1.2) 262 0 R (subsection.6.2.1) 278 0 R (subsection.6.2.10) 314 0 R (subsection.6.2.11) 326 0 R (subsection.6.2.12) 330 0 R (subsection.6.2.13) 334 0 R (subsection.6.2.14) 338 0 R (subsection.6.2.15) 342 0 R (subsection.6.2.16) 346 0 R (subsection.6.2.17) 426 0 R (subsection.6.2.18) 430 0 R (subsection.6.2.19) 434 0 R (subsection.6.2.2) 282 0 R (subsection.6.2.20) 438 0 R (subsection.6.2.21) 442 0 R (subsection.6.2.22) 446 0 R (subsection.6.2.23) 450 0 R (subsection.6.2.24) 454 0 R (subsection.6.2.3) 286 0 R (subsection.6.2.4) 290 0 R (subsection.6.2.5) 294 0 R (subsection.6.2.6) 298 0 R (subsection.6.2.7) 302 0 R (subsection.6.2.8) 306 0 R (subsection.6.2.9) 310 0 R (subsection.6.3.1) 478 0 R (subsection.6.3.2) 490 0 R (subsection.6.3.3) 494 0 R (subsection.6.3.4) 498 0 R (subsection.6.3.5) 502 0 R (subsection.6.3.6) 518 0 R (subsection.6.3.7) 522 0 R (subsection.7.2.1) 538 0 R (subsection.7.2.2) 542 0 R (subsection.8.1.1) 558 0 R (subsection.A.1.1) 578 0 R (subsection.A.2.1) 586 0 R (subsection.A.3.1) 594 0 R (subsection.A.3.2) 598 0 R (subsection.A.3.3) 602 0 R (subsubsection.1.4.4.1) 42 0 R (subsubsection.1.4.4.2) 46 0 R (subsubsection.1.4.4.3) 50 0 R (subsubsection.1.4.5.1) 58 0 R (subsubsection.3.3.1.1) 118 0 R (subsubsection.3.3.1.2) 122 0 R (subsubsection.4.5.1.1) 166 0 R (subsubsection.4.5.1.2) 170 0 R (subsubsection.6.1.1.1) 254 0 R (subsubsection.6.1.1.2) 258 0 R (subsubsection.6.1.2.1) 266 0 R (subsubsection.6.1.2.2) 270 0 R (subsubsection.6.2.10.1) 318 0 R (subsubsection.6.2.10.2) 322 0 R (subsubsection.6.2.16.1) 350 0 R (subsubsection.6.2.16.10) 386 0 R (subsubsection.6.2.16.11) 390 0 R (subsubsection.6.2.16.12) 394 0 R (subsubsection.6.2.16.13) 398 0 R (subsubsection.6.2.16.14) 402 0 R (subsubsection.6.2.16.15) 406 0 R (subsubsection.6.2.16.16) 410 0 R (subsubsection.6.2.16.17) 414 0 R (subsubsection.6.2.16.18) 418 0 R (subsubsection.6.2.16.19) 422 0 R (subsubsection.6.2.16.2) 354 0 R (subsubsection.6.2.16.3) 358 0 R (subsubsection.6.2.16.4) 362 0 R (subsubsection.6.2.16.5) 366 0 R (subsubsection.6.2.16.6) 370 0 R (subsubsection.6.2.16.7) 374 0 R (subsubsection.6.2.16.8) 378 0 R (subsubsection.6.2.16.9) 382 0 R (subsubsection.6.2.24.1) 458 0 R (subsubsection.6.2.24.2) 462 0 R (subsubsection.6.2.24.3) 466 0 R (subsubsection.6.2.24.4) 470 0 R (subsubsection.6.3.1.1) 482 0 R (subsubsection.6.3.1.2) 486 0 R (subsubsection.6.3.5.1) 506 0 R (subsubsection.6.3.5.2) 510 0 R (subsubsection.6.3.5.3) 514 0 R (table.1.1) 882 0 R (table.1.2) 892 0 R (table.3.1) 951 0 R (table.3.2) 983 0 R (table.6.1) 1091 0 R (table.6.10) 1417 0 R (table.6.11) 1423 0 R (table.6.12) 1429 0 R (table.6.13) 1436 0 R (table.6.14) 1438 0 R (table.6.15) 1441 0 R (table.6.16) 1448 0 R (table.6.17) 1451 0 R (table.6.18) 1467 0 R (table.6.2) 1115 0 R (table.6.3) 1123 0 R (table.6.4) 1162 0 R (table.6.5) 1203 0 R (table.6.6) 1284 0 R (table.6.7) 1314 0 R (table.6.8) 1354 0 R (table.6.9) 1407 0 R (the_category_phrase) 1156 0 R (the_sortlist_statement) 1275 0 R (topology) 1270 0 R (tsig) 1030 0 R (tuning) 1285 0 R (types_of_resource_records_and_when_to_use_them) 899 0 R (view_statement_grammar) 1304 0 R (zone_statement_grammar) 1234 0 R (zone_transfers) 1006 0 R (zonefile_format) 1292 0 R]
-/Limits [(Access_Control_Lists) (zonefile_format)]
->> endobj
-1944 0 obj <<
-/Kids [1943 0 R]
->> endobj
-1945 0 obj <<
-/Dests 1944 0 R
->> endobj
-1946 0 obj <<
-/Type /Catalog
-/Pages 1941 0 R
-/Outlines 1942 0 R
-/Names 1945 0 R
-/PageMode /UseOutlines 
-/OpenAction 649 0 R
->> endobj
-1947 0 obj <<
-/Author()/Title()/Subject()/Creator(LaTeX with hyperref package)/Producer(pdfeTeX-1.21a)/Keywords()
-/CreationDate (D:20071031135044+11'00')
-/PTEX.Fullbanner (This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4) kpathsea version 3.5.4)
->> endobj
-xref
-0 1948
-0000000001 65535 f 
-0000000002 00000 f 
-0000000003 00000 f 
-0000000004 00000 f 
-0000000000 00000 f 
-0000000009 00000 n 
-0000066898 00000 n 
-0000664779 00000 n 
-0000000054 00000 n 
-0000000086 00000 n 
-0000067022 00000 n 
-0000664707 00000 n 
-0000000133 00000 n 
-0000000173 00000 n 
-0000067147 00000 n 
-0000664621 00000 n 
-0000000221 00000 n 
-0000000273 00000 n 
-0000067272 00000 n 
-0000664535 00000 n 
-0000000321 00000 n 
-0000000377 00000 n 
-0000071535 00000 n 
-0000664425 00000 n 
-0000000425 00000 n 
-0000000478 00000 n 
-0000071660 00000 n 
-0000664351 00000 n 
-0000000531 00000 n 
-0000000572 00000 n 
-0000071785 00000 n 
-0000664264 00000 n 
-0000000625 00000 n 
-0000000674 00000 n 
-0000071910 00000 n 
-0000664177 00000 n 
-0000000727 00000 n 
-0000000757 00000 n 
-0000076188 00000 n 
-0000664053 00000 n 
-0000000810 00000 n 
-0000000861 00000 n 
-0000076313 00000 n 
-0000663979 00000 n 
-0000000919 00000 n 
-0000000964 00000 n 
-0000076438 00000 n 
-0000663892 00000 n 
-0000001022 00000 n 
-0000001062 00000 n 
-0000076563 00000 n 
-0000663818 00000 n 
-0000001120 00000 n 
-0000001162 00000 n 
-0000079535 00000 n 
-0000663694 00000 n 
-0000001215 00000 n 
-0000001260 00000 n 
-0000079660 00000 n 
-0000663633 00000 n 
-0000001318 00000 n 
-0000001355 00000 n 
-0000079785 00000 n 
-0000663559 00000 n 
-0000001408 00000 n 
-0000001463 00000 n 
-0000082713 00000 n 
-0000663434 00000 n 
-0000001509 00000 n 
-0000001556 00000 n 
-0000082838 00000 n 
-0000663360 00000 n 
-0000001604 00000 n 
-0000001648 00000 n 
-0000082963 00000 n 
-0000663273 00000 n 
-0000001696 00000 n 
-0000001735 00000 n 
-0000083088 00000 n 
-0000663186 00000 n 
-0000001783 00000 n 
-0000001825 00000 n 
-0000083212 00000 n 
-0000663099 00000 n 
-0000001873 00000 n 
-0000001936 00000 n 
-0000084298 00000 n 
-0000663025 00000 n 
-0000001984 00000 n 
-0000002034 00000 n 
-0000086008 00000 n 
-0000662897 00000 n 
-0000002080 00000 n 
-0000002126 00000 n 
-0000086132 00000 n 
-0000662784 00000 n 
-0000002174 00000 n 
-0000002218 00000 n 
-0000086257 00000 n 
-0000662708 00000 n 
-0000002271 00000 n 
-0000002323 00000 n 
-0000086382 00000 n 
-0000662631 00000 n 
-0000002377 00000 n 
-0000002436 00000 n 
-0000088910 00000 n 
-0000662540 00000 n 
-0000002485 00000 n 
-0000002523 00000 n 
-0000089162 00000 n 
-0000662423 00000 n 
-0000002572 00000 n 
-0000002618 00000 n 
-0000089288 00000 n 
-0000662305 00000 n 
-0000002672 00000 n 
-0000002739 00000 n 
-0000092495 00000 n 
-0000662226 00000 n 
-0000002798 00000 n 
-0000002842 00000 n 
-0000092621 00000 n 
-0000662147 00000 n 
-0000002901 00000 n 
-0000002949 00000 n 
-0000102950 00000 n 
-0000662068 00000 n 
-0000003003 00000 n 
-0000003036 00000 n 
-0000107881 00000 n 
-0000661936 00000 n 
-0000003083 00000 n 
-0000003126 00000 n 
-0000108007 00000 n 
-0000661857 00000 n 
-0000003175 00000 n 
-0000003205 00000 n 
-0000108133 00000 n 
-0000661725 00000 n 
-0000003254 00000 n 
-0000003292 00000 n 
-0000108259 00000 n 
-0000661660 00000 n 
-0000003346 00000 n 
-0000003388 00000 n 
-0000112550 00000 n 
-0000661567 00000 n 
-0000003437 00000 n 
-0000003496 00000 n 
-0000112677 00000 n 
-0000661435 00000 n 
-0000003545 00000 n 
-0000003578 00000 n 
-0000112806 00000 n 
-0000661370 00000 n 
-0000003632 00000 n 
-0000003681 00000 n 
-0000120178 00000 n 
-0000661238 00000 n 
-0000003730 00000 n 
-0000003758 00000 n 
-0000120305 00000 n 
-0000661120 00000 n 
-0000003812 00000 n 
-0000003881 00000 n 
-0000120434 00000 n 
-0000661041 00000 n 
-0000003940 00000 n 
-0000003988 00000 n 
-0000123309 00000 n 
-0000660962 00000 n 
-0000004047 00000 n 
-0000004092 00000 n 
-0000123438 00000 n 
-0000660869 00000 n 
-0000004146 00000 n 
-0000004214 00000 n 
-0000123567 00000 n 
-0000660776 00000 n 
-0000004268 00000 n 
-0000004338 00000 n 
-0000123696 00000 n 
-0000660683 00000 n 
-0000004392 00000 n 
-0000004455 00000 n 
-0000123824 00000 n 
-0000660590 00000 n 
-0000004509 00000 n 
-0000004564 00000 n 
-0000127470 00000 n 
-0000660511 00000 n 
-0000004618 00000 n 
-0000004650 00000 n 
-0000127599 00000 n 
-0000660418 00000 n 
-0000004699 00000 n 
-0000004727 00000 n 
-0000127728 00000 n 
-0000660325 00000 n 
-0000004776 00000 n 
-0000004808 00000 n 
-0000131334 00000 n 
-0000660193 00000 n 
-0000004857 00000 n 
-0000004887 00000 n 
-0000131463 00000 n 
-0000660114 00000 n 
-0000004941 00000 n 
-0000004982 00000 n 
-0000131591 00000 n 
-0000660021 00000 n 
-0000005036 00000 n 
-0000005078 00000 n 
-0000135033 00000 n 
-0000659942 00000 n 
-0000005132 00000 n 
-0000005177 00000 n 
-0000138107 00000 n 
-0000659824 00000 n 
-0000005226 00000 n 
-0000005272 00000 n 
-0000138236 00000 n 
-0000659745 00000 n 
-0000005326 00000 n 
-0000005386 00000 n 
-0000138364 00000 n 
-0000659666 00000 n 
-0000005440 00000 n 
-0000005509 00000 n 
-0000140844 00000 n 
-0000659533 00000 n 
-0000005556 00000 n 
-0000005609 00000 n 
-0000140973 00000 n 
-0000659454 00000 n 
-0000005658 00000 n 
-0000005714 00000 n 
-0000141102 00000 n 
-0000659375 00000 n 
-0000005763 00000 n 
-0000005812 00000 n 
-0000145286 00000 n 
-0000659242 00000 n 
-0000005859 00000 n 
-0000005911 00000 n 
-0000145415 00000 n 
-0000659124 00000 n 
-0000005960 00000 n 
-0000006011 00000 n 
-0000149682 00000 n 
-0000659006 00000 n 
-0000006065 00000 n 
-0000006110 00000 n 
-0000149811 00000 n 
-0000658927 00000 n 
-0000006169 00000 n 
-0000006203 00000 n 
-0000149940 00000 n 
-0000658848 00000 n 
-0000006262 00000 n 
-0000006310 00000 n 
-0000153288 00000 n 
-0000658730 00000 n 
-0000006364 00000 n 
-0000006404 00000 n 
-0000153417 00000 n 
-0000658651 00000 n 
-0000006463 00000 n 
-0000006497 00000 n 
-0000153546 00000 n 
-0000658572 00000 n 
-0000006556 00000 n 
-0000006604 00000 n 
-0000157451 00000 n 
-0000658439 00000 n 
-0000006653 00000 n 
-0000006703 00000 n 
-0000161073 00000 n 
-0000658360 00000 n 
-0000006757 00000 n 
-0000006804 00000 n 
-0000161202 00000 n 
-0000658267 00000 n 
-0000006858 00000 n 
-0000006918 00000 n 
-0000161459 00000 n 
-0000658174 00000 n 
-0000006972 00000 n 
-0000007024 00000 n 
-0000161588 00000 n 
-0000658081 00000 n 
-0000007078 00000 n 
-0000007143 00000 n 
-0000166242 00000 n 
-0000657988 00000 n 
-0000007197 00000 n 
-0000007248 00000 n 
-0000166371 00000 n 
-0000657895 00000 n 
-0000007302 00000 n 
-0000007366 00000 n 
-0000166500 00000 n 
-0000657802 00000 n 
-0000007420 00000 n 
-0000007467 00000 n 
-0000166629 00000 n 
-0000657709 00000 n 
-0000007521 00000 n 
-0000007581 00000 n 
-0000169977 00000 n 
-0000657616 00000 n 
-0000007635 00000 n 
-0000007686 00000 n 
-0000170106 00000 n 
-0000657484 00000 n 
-0000007741 00000 n 
-0000007806 00000 n 
-0000174741 00000 n 
-0000657405 00000 n 
-0000007866 00000 n 
-0000007913 00000 n 
-0000180920 00000 n 
-0000657326 00000 n 
-0000007973 00000 n 
-0000008021 00000 n 
-0000184667 00000 n 
-0000657233 00000 n 
-0000008076 00000 n 
-0000008126 00000 n 
-0000184796 00000 n 
-0000657140 00000 n 
-0000008181 00000 n 
-0000008244 00000 n 
-0000186525 00000 n 
-0000657047 00000 n 
-0000008299 00000 n 
-0000008351 00000 n 
-0000186654 00000 n 
-0000656954 00000 n 
-0000008406 00000 n 
-0000008471 00000 n 
-0000186783 00000 n 
-0000656861 00000 n 
-0000008526 00000 n 
-0000008578 00000 n 
-0000190468 00000 n 
-0000656728 00000 n 
-0000008633 00000 n 
-0000008698 00000 n 
-0000198661 00000 n 
-0000656649 00000 n 
-0000008758 00000 n 
-0000008802 00000 n 
-0000216022 00000 n 
-0000656556 00000 n 
-0000008862 00000 n 
-0000008901 00000 n 
-0000220238 00000 n 
-0000656463 00000 n 
-0000008961 00000 n 
-0000009008 00000 n 
-0000220366 00000 n 
-0000656370 00000 n 
-0000009068 00000 n 
-0000009111 00000 n 
-0000224175 00000 n 
-0000656277 00000 n 
-0000009171 00000 n 
-0000009210 00000 n 
-0000227147 00000 n 
-0000656184 00000 n 
-0000009270 00000 n 
-0000009312 00000 n 
-0000227276 00000 n 
-0000656091 00000 n 
-0000009372 00000 n 
-0000009415 00000 n 
-0000234515 00000 n 
-0000655998 00000 n 
-0000009475 00000 n 
-0000009522 00000 n 
-0000238765 00000 n 
-0000655905 00000 n 
-0000009582 00000 n 
-0000009643 00000 n 
-0000238894 00000 n 
-0000655812 00000 n 
-0000009704 00000 n 
-0000009756 00000 n 
-0000242265 00000 n 
-0000655719 00000 n 
-0000009817 00000 n 
-0000009870 00000 n 
-0000242394 00000 n 
-0000655626 00000 n 
-0000009931 00000 n 
-0000009969 00000 n 
-0000246293 00000 n 
-0000655533 00000 n 
-0000010030 00000 n 
-0000010082 00000 n 
-0000249718 00000 n 
-0000655440 00000 n 
-0000010143 00000 n 
-0000010187 00000 n 
-0000249976 00000 n 
-0000655347 00000 n 
-0000010248 00000 n 
-0000010284 00000 n 
-0000258745 00000 n 
-0000655254 00000 n 
-0000010345 00000 n 
-0000010408 00000 n 
-0000258874 00000 n 
-0000655161 00000 n 
-0000010469 00000 n 
-0000010519 00000 n 
-0000264226 00000 n 
-0000655068 00000 n 
-0000010580 00000 n 
-0000010629 00000 n 
-0000268214 00000 n 
-0000654989 00000 n 
-0000010690 00000 n 
-0000010746 00000 n 
-0000268342 00000 n 
-0000654896 00000 n 
-0000010801 00000 n 
-0000010852 00000 n 
-0000272260 00000 n 
-0000654803 00000 n 
-0000010907 00000 n 
-0000010971 00000 n 
-0000276289 00000 n 
-0000654710 00000 n 
-0000011026 00000 n 
-0000011083 00000 n 
-0000276417 00000 n 
-0000654617 00000 n 
-0000011138 00000 n 
-0000011208 00000 n 
-0000276543 00000 n 
-0000654524 00000 n 
-0000011263 00000 n 
-0000011312 00000 n 
-0000279969 00000 n 
-0000654431 00000 n 
-0000011367 00000 n 
-0000011429 00000 n 
-0000281613 00000 n 
-0000654338 00000 n 
-0000011484 00000 n 
-0000011533 00000 n 
-0000285546 00000 n 
-0000654220 00000 n 
-0000011588 00000 n 
-0000011650 00000 n 
-0000285675 00000 n 
-0000654141 00000 n 
-0000011710 00000 n 
-0000011749 00000 n 
-0000289728 00000 n 
-0000654048 00000 n 
-0000011809 00000 n 
-0000011843 00000 n 
-0000295345 00000 n 
-0000653955 00000 n 
-0000011903 00000 n 
-0000011944 00000 n 
-0000305746 00000 n 
-0000653876 00000 n 
-0000012004 00000 n 
-0000012056 00000 n 
-0000309844 00000 n 
-0000653758 00000 n 
-0000012105 00000 n 
-0000012138 00000 n 
-0000309972 00000 n 
-0000653640 00000 n 
-0000012192 00000 n 
-0000012264 00000 n 
-0000310100 00000 n 
-0000653561 00000 n 
-0000012323 00000 n 
-0000012367 00000 n 
-0000317603 00000 n 
-0000653482 00000 n 
-0000012426 00000 n 
-0000012479 00000 n 
-0000321290 00000 n 
-0000653389 00000 n 
-0000012533 00000 n 
-0000012583 00000 n 
-0000324743 00000 n 
-0000653296 00000 n 
-0000012637 00000 n 
-0000012675 00000 n 
-0000325002 00000 n 
-0000653203 00000 n 
-0000012729 00000 n 
-0000012778 00000 n 
-0000325260 00000 n 
-0000653071 00000 n 
-0000012832 00000 n 
-0000012884 00000 n 
-0000328115 00000 n 
-0000652992 00000 n 
-0000012943 00000 n 
-0000012995 00000 n 
-0000328244 00000 n 
-0000652899 00000 n 
-0000013054 00000 n 
-0000013107 00000 n 
-0000328373 00000 n 
-0000652820 00000 n 
-0000013166 00000 n 
-0000013215 00000 n 
-0000328502 00000 n 
-0000652727 00000 n 
-0000013269 00000 n 
-0000013349 00000 n 
-0000332842 00000 n 
-0000652648 00000 n 
-0000013403 00000 n 
-0000013452 00000 n 
-0000335118 00000 n 
-0000652515 00000 n 
-0000013499 00000 n 
-0000013551 00000 n 
-0000335247 00000 n 
-0000652436 00000 n 
-0000013600 00000 n 
-0000013644 00000 n 
-0000339340 00000 n 
-0000652304 00000 n 
-0000013693 00000 n 
-0000013734 00000 n 
-0000339469 00000 n 
-0000652225 00000 n 
-0000013788 00000 n 
-0000013836 00000 n 
-0000339598 00000 n 
-0000652146 00000 n 
-0000013890 00000 n 
-0000013941 00000 n 
-0000339727 00000 n 
-0000652067 00000 n 
-0000013990 00000 n 
-0000014037 00000 n 
-0000343990 00000 n 
-0000651934 00000 n 
-0000014084 00000 n 
-0000014121 00000 n 
-0000344119 00000 n 
-0000651816 00000 n 
-0000014170 00000 n 
-0000014209 00000 n 
-0000344248 00000 n 
-0000651751 00000 n 
-0000014263 00000 n 
-0000014341 00000 n 
-0000344377 00000 n 
-0000651658 00000 n 
-0000014390 00000 n 
-0000014457 00000 n 
-0000344506 00000 n 
-0000651579 00000 n 
-0000014506 00000 n 
-0000014551 00000 n 
-0000347945 00000 n 
-0000651446 00000 n 
-0000014599 00000 n 
-0000014631 00000 n 
-0000348074 00000 n 
-0000651328 00000 n 
-0000014680 00000 n 
-0000014719 00000 n 
-0000348203 00000 n 
-0000651263 00000 n 
-0000014773 00000 n 
-0000014834 00000 n 
-0000351968 00000 n 
-0000651131 00000 n 
-0000014883 00000 n 
-0000014940 00000 n 
-0000352097 00000 n 
-0000651066 00000 n 
-0000014994 00000 n 
-0000015043 00000 n 
-0000352226 00000 n 
-0000650948 00000 n 
-0000015092 00000 n 
-0000015154 00000 n 
-0000352355 00000 n 
-0000650869 00000 n 
-0000015208 00000 n 
-0000015263 00000 n 
-0000376379 00000 n 
-0000650776 00000 n 
-0000015317 00000 n 
-0000015358 00000 n 
-0000376508 00000 n 
-0000650697 00000 n 
-0000015412 00000 n 
-0000015464 00000 n 
-0000379211 00000 n 
-0000650577 00000 n 
-0000015512 00000 n 
-0000015546 00000 n 
-0000379340 00000 n 
-0000650498 00000 n 
-0000015595 00000 n 
-0000015622 00000 n 
-0000397280 00000 n 
-0000650405 00000 n 
-0000015671 00000 n 
-0000015699 00000 n 
-0000404815 00000 n 
-0000650312 00000 n 
-0000015748 00000 n 
-0000015785 00000 n 
-0000411129 00000 n 
-0000650219 00000 n 
-0000015834 00000 n 
-0000015873 00000 n 
-0000420651 00000 n 
-0000650126 00000 n 
-0000015922 00000 n 
-0000015961 00000 n 
-0000423538 00000 n 
-0000650033 00000 n 
-0000016010 00000 n 
-0000016049 00000 n 
-0000429911 00000 n 
-0000649940 00000 n 
-0000016098 00000 n 
-0000016127 00000 n 
-0000439507 00000 n 
-0000649847 00000 n 
-0000016176 00000 n 
-0000016204 00000 n 
-0000442707 00000 n 
-0000649754 00000 n 
-0000016253 00000 n 
-0000016286 00000 n 
-0000448703 00000 n 
-0000649675 00000 n 
-0000016336 00000 n 
-0000016373 00000 n 
-0000016742 00000 n 
-0000016864 00000 n 
-0000024693 00000 n 
-0000016426 00000 n 
-0000024567 00000 n 
-0000024630 00000 n 
-0000645556 00000 n 
-0000619613 00000 n 
-0000645382 00000 n 
-0000646581 00000 n 
-0000019727 00000 n 
-0000019944 00000 n 
-0000020013 00000 n 
-0000020082 00000 n 
-0000020150 00000 n 
-0000020218 00000 n 
-0000020267 00000 n 
-0000020314 00000 n 
-0000020647 00000 n 
-0000020669 00000 n 
-0000020837 00000 n 
-0000021002 00000 n 
-0000021171 00000 n 
-0000021350 00000 n 
-0000021659 00000 n 
-0000021819 00000 n 
-0000026052 00000 n 
-0000025867 00000 n 
-0000024793 00000 n 
-0000025989 00000 n 
-0000618401 00000 n 
-0000591922 00000 n 
-0000618227 00000 n 
-0000591237 00000 n 
-0000589092 00000 n 
-0000591073 00000 n 
-0000037758 00000 n 
-0000029108 00000 n 
-0000026137 00000 n 
-0000037632 00000 n 
-0000037695 00000 n 
-0000029642 00000 n 
-0000029796 00000 n 
-0000029953 00000 n 
-0000030110 00000 n 
-0000030266 00000 n 
-0000030423 00000 n 
-0000030585 00000 n 
-0000030746 00000 n 
-0000030907 00000 n 
-0000031069 00000 n 
-0000031236 00000 n 
-0000031403 00000 n 
-0000031568 00000 n 
-0000031730 00000 n 
-0000031896 00000 n 
-0000032057 00000 n 
-0000032212 00000 n 
-0000032369 00000 n 
-0000032525 00000 n 
-0000032682 00000 n 
-0000032839 00000 n 
-0000032996 00000 n 
-0000033150 00000 n 
-0000033306 00000 n 
-0000033468 00000 n 
-0000033630 00000 n 
-0000033786 00000 n 
-0000033943 00000 n 
-0000034105 00000 n 
-0000034272 00000 n 
-0000034438 00000 n 
-0000034599 00000 n 
-0000034754 00000 n 
-0000034911 00000 n 
-0000035068 00000 n 
-0000035230 00000 n 
-0000035387 00000 n 
-0000035544 00000 n 
-0000035706 00000 n 
-0000035863 00000 n 
-0000036025 00000 n 
-0000036192 00000 n 
-0000036358 00000 n 
-0000036520 00000 n 
-0000036682 00000 n 
-0000036844 00000 n 
-0000037005 00000 n 
-0000037167 00000 n 
-0000037322 00000 n 
-0000037477 00000 n 
-0000051127 00000 n 
-0000041075 00000 n 
-0000037843 00000 n 
-0000051064 00000 n 
-0000588541 00000 n 
-0000571460 00000 n 
-0000588357 00000 n 
-0000041665 00000 n 
-0000041828 00000 n 
-0000041990 00000 n 
-0000042153 00000 n 
-0000042311 00000 n 
-0000042474 00000 n 
-0000042637 00000 n 
-0000042792 00000 n 
-0000042950 00000 n 
-0000043108 00000 n 
-0000043264 00000 n 
-0000043422 00000 n 
-0000043585 00000 n 
-0000043753 00000 n 
-0000043921 00000 n 
-0000044084 00000 n 
-0000044252 00000 n 
-0000044420 00000 n 
-0000044578 00000 n 
-0000044741 00000 n 
-0000044904 00000 n 
-0000045066 00000 n 
-0000045228 00000 n 
-0000045391 00000 n 
-0000045553 00000 n 
-0000045715 00000 n 
-0000045878 00000 n 
-0000046041 00000 n 
-0000046204 00000 n 
-0000046373 00000 n 
-0000046542 00000 n 
-0000046706 00000 n 
-0000046869 00000 n 
-0000047033 00000 n 
-0000047197 00000 n 
-0000047360 00000 n 
-0000047524 00000 n 
-0000047693 00000 n 
-0000047862 00000 n 
-0000048031 00000 n 
-0000048200 00000 n 
-0000048369 00000 n 
-0000048538 00000 n 
-0000048707 00000 n 
-0000048876 00000 n 
-0000049045 00000 n 
-0000049215 00000 n 
-0000049385 00000 n 
-0000049555 00000 n 
-0000049724 00000 n 
-0000049894 00000 n 
-0000050064 00000 n 
-0000050234 00000 n 
-0000050403 00000 n 
-0000050573 00000 n 
-0000050741 00000 n 
-0000050902 00000 n 
-0000063950 00000 n 
-0000054658 00000 n 
-0000051225 00000 n 
-0000063887 00000 n 
-0000055224 00000 n 
-0000055387 00000 n 
-0000055550 00000 n 
-0000055713 00000 n 
-0000055876 00000 n 
-0000056038 00000 n 
-0000056201 00000 n 
-0000056369 00000 n 
-0000056537 00000 n 
-0000056704 00000 n 
-0000056872 00000 n 
-0000057028 00000 n 
-0000057190 00000 n 
-0000057357 00000 n 
-0000057524 00000 n 
-0000057686 00000 n 
-0000057848 00000 n 
-0000058010 00000 n 
-0000058172 00000 n 
-0000058339 00000 n 
-0000058506 00000 n 
-0000058673 00000 n 
-0000058835 00000 n 
-0000058997 00000 n 
-0000059152 00000 n 
-0000059307 00000 n 
-0000059464 00000 n 
-0000059626 00000 n 
-0000059788 00000 n 
-0000059944 00000 n 
-0000060099 00000 n 
-0000060256 00000 n 
-0000060418 00000 n 
-0000060574 00000 n 
-0000060731 00000 n 
-0000060887 00000 n 
-0000061044 00000 n 
-0000061206 00000 n 
-0000061363 00000 n 
-0000061525 00000 n 
-0000061682 00000 n 
-0000061843 00000 n 
-0000062005 00000 n 
-0000062167 00000 n 
-0000062322 00000 n 
-0000062478 00000 n 
-0000062635 00000 n 
-0000062792 00000 n 
-0000062949 00000 n 
-0000063105 00000 n 
-0000063262 00000 n 
-0000063419 00000 n 
-0000570494 00000 n 
-0000550527 00000 n 
-0000570321 00000 n 
-0000063576 00000 n 
-0000063731 00000 n 
-0000064395 00000 n 
-0000064210 00000 n 
-0000064061 00000 n 
-0000064332 00000 n 
-0000067523 00000 n 
-0000066713 00000 n 
-0000064436 00000 n 
-0000066835 00000 n 
-0000066959 00000 n 
-0000067084 00000 n 
-0000067209 00000 n 
-0000549638 00000 n 
-0000528306 00000 n 
-0000549464 00000 n 
-0000067334 00000 n 
-0000067397 00000 n 
-0000067460 00000 n 
-0000527539 00000 n 
-0000510131 00000 n 
-0000527366 00000 n 
-0000646699 00000 n 
-0000072034 00000 n 
-0000070852 00000 n 
-0000067647 00000 n 
-0000071346 00000 n 
-0000071409 00000 n 
-0000071472 00000 n 
-0000071597 00000 n 
-0000071722 00000 n 
-0000071847 00000 n 
-0000071002 00000 n 
-0000071195 00000 n 
-0000071972 00000 n 
-0000310036 00000 n 
-0000352419 00000 n 
-0000076688 00000 n 
-0000075652 00000 n 
-0000072158 00000 n 
-0000076125 00000 n 
-0000076250 00000 n 
-0000075802 00000 n 
-0000075964 00000 n 
-0000076375 00000 n 
-0000076500 00000 n 
-0000076625 00000 n 
-0000092558 00000 n 
-0000079910 00000 n 
-0000079350 00000 n 
-0000076812 00000 n 
-0000079472 00000 n 
-0000079597 00000 n 
-0000079722 00000 n 
-0000079847 00000 n 
-0000083337 00000 n 
-0000082196 00000 n 
-0000080021 00000 n 
-0000082650 00000 n 
-0000082775 00000 n 
-0000082900 00000 n 
-0000083025 00000 n 
-0000083150 00000 n 
-0000082346 00000 n 
-0000082498 00000 n 
-0000083274 00000 n 
-0000268278 00000 n 
-0000084423 00000 n 
-0000084113 00000 n 
-0000083422 00000 n 
-0000084235 00000 n 
-0000084360 00000 n 
-0000086508 00000 n 
-0000085823 00000 n 
-0000084521 00000 n 
-0000085945 00000 n 
-0000086070 00000 n 
-0000086194 00000 n 
-0000086319 00000 n 
-0000086445 00000 n 
-0000646817 00000 n 
-0000089413 00000 n 
-0000088545 00000 n 
-0000086606 00000 n 
-0000088847 00000 n 
-0000088973 00000 n 
-0000089036 00000 n 
-0000089099 00000 n 
-0000088687 00000 n 
-0000089225 00000 n 
-0000089351 00000 n 
-0000249782 00000 n 
-0000092747 00000 n 
-0000092310 00000 n 
-0000089524 00000 n 
-0000092432 00000 n 
-0000509475 00000 n 
-0000497890 00000 n 
-0000509298 00000 n 
-0000092684 00000 n 
-0000096532 00000 n 
-0000096347 00000 n 
-0000092871 00000 n 
-0000096469 00000 n 
-0000497355 00000 n 
-0000487841 00000 n 
-0000497178 00000 n 
-0000100916 00000 n 
-0000100525 00000 n 
-0000096695 00000 n 
-0000100853 00000 n 
-0000100667 00000 n 
-0000161651 00000 n 
-0000103202 00000 n 
-0000102765 00000 n 
-0000101053 00000 n 
-0000102887 00000 n 
-0000103013 00000 n 
-0000103076 00000 n 
-0000103139 00000 n 
-0000105854 00000 n 
-0000108386 00000 n 
-0000105703 00000 n 
-0000103326 00000 n 
-0000107818 00000 n 
-0000107944 00000 n 
-0000108070 00000 n 
-0000107496 00000 n 
-0000107657 00000 n 
-0000486982 00000 n 
-0000477610 00000 n 
-0000486810 00000 n 
-0000477048 00000 n 
-0000467964 00000 n 
-0000476875 00000 n 
-0000108196 00000 n 
-0000108322 00000 n 
-0000646935 00000 n 
-0000107325 00000 n 
-0000107383 00000 n 
-0000107473 00000 n 
-0000198725 00000 n 
-0000227340 00000 n 
-0000112935 00000 n 
-0000112001 00000 n 
-0000108538 00000 n 
-0000112485 00000 n 
-0000112613 00000 n 
-0000112157 00000 n 
-0000112323 00000 n 
-0000112741 00000 n 
-0000112870 00000 n 
-0000356445 00000 n 
-0000116427 00000 n 
-0000116047 00000 n 
-0000113086 00000 n 
-0000116362 00000 n 
-0000116194 00000 n 
-0000117661 00000 n 
-0000117470 00000 n 
-0000116552 00000 n 
-0000117596 00000 n 
-0000120563 00000 n 
-0000119987 00000 n 
-0000117760 00000 n 
-0000120113 00000 n 
-0000120240 00000 n 
-0000120369 00000 n 
-0000120498 00000 n 
-0000123953 00000 n 
-0000123118 00000 n 
-0000120701 00000 n 
-0000123244 00000 n 
-0000123373 00000 n 
-0000123502 00000 n 
-0000123631 00000 n 
-0000123759 00000 n 
-0000123888 00000 n 
-0000127856 00000 n 
-0000127088 00000 n 
-0000124091 00000 n 
-0000127405 00000 n 
-0000127235 00000 n 
-0000127534 00000 n 
-0000127663 00000 n 
-0000127792 00000 n 
-0000647059 00000 n 
-0000305810 00000 n 
-0000131720 00000 n 
-0000131143 00000 n 
-0000127968 00000 n 
-0000131269 00000 n 
-0000131398 00000 n 
-0000131526 00000 n 
-0000131655 00000 n 
-0000135162 00000 n 
-0000134842 00000 n 
-0000131858 00000 n 
-0000134968 00000 n 
-0000135097 00000 n 
-0000138493 00000 n 
-0000137734 00000 n 
-0000135274 00000 n 
-0000138042 00000 n 
-0000138171 00000 n 
-0000137881 00000 n 
-0000138300 00000 n 
-0000138428 00000 n 
-0000352161 00000 n 
-0000141231 00000 n 
-0000140653 00000 n 
-0000138659 00000 n 
-0000140779 00000 n 
-0000140908 00000 n 
-0000141037 00000 n 
-0000141166 00000 n 
-0000141671 00000 n 
-0000141480 00000 n 
-0000141330 00000 n 
-0000141606 00000 n 
-0000145673 00000 n 
-0000144907 00000 n 
-0000141713 00000 n 
-0000145221 00000 n 
-0000145350 00000 n 
-0000145478 00000 n 
-0000145543 00000 n 
-0000145608 00000 n 
-0000145054 00000 n 
-0000647184 00000 n 
-0000149746 00000 n 
-0000150069 00000 n 
-0000149491 00000 n 
-0000145772 00000 n 
-0000149617 00000 n 
-0000149875 00000 n 
-0000150004 00000 n 
-0000153675 00000 n 
-0000153097 00000 n 
-0000150207 00000 n 
-0000153223 00000 n 
-0000153352 00000 n 
-0000153481 00000 n 
-0000153610 00000 n 
-0000156460 00000 n 
-0000157710 00000 n 
-0000156334 00000 n 
-0000153800 00000 n 
-0000157386 00000 n 
-0000157515 00000 n 
-0000157580 00000 n 
-0000157645 00000 n 
-0000161715 00000 n 
-0000160882 00000 n 
-0000157864 00000 n 
-0000161008 00000 n 
-0000161137 00000 n 
-0000161264 00000 n 
-0000161329 00000 n 
-0000161394 00000 n 
-0000161523 00000 n 
-0000166757 00000 n 
-0000165359 00000 n 
-0000161827 00000 n 
-0000166177 00000 n 
-0000165533 00000 n 
-0000165684 00000 n 
-0000166306 00000 n 
-0000166435 00000 n 
-0000166564 00000 n 
-0000166693 00000 n 
-0000165843 00000 n 
-0000165993 00000 n 
-0000454156 00000 n 
-0000170235 00000 n 
-0000169578 00000 n 
-0000166895 00000 n 
-0000169912 00000 n 
-0000169725 00000 n 
-0000170041 00000 n 
-0000170170 00000 n 
-0000647309 00000 n 
-0000174870 00000 n 
-0000174550 00000 n 
-0000170360 00000 n 
-0000174676 00000 n 
-0000174805 00000 n 
-0000178034 00000 n 
-0000177655 00000 n 
-0000174995 00000 n 
-0000177969 00000 n 
-0000177802 00000 n 
-0000180984 00000 n 
-0000181178 00000 n 
-0000180729 00000 n 
-0000178146 00000 n 
-0000180855 00000 n 
-0000181049 00000 n 
-0000181113 00000 n 
-0000184925 00000 n 
-0000184141 00000 n 
-0000181290 00000 n 
-0000184602 00000 n 
-0000184731 00000 n 
-0000184860 00000 n 
-0000184297 00000 n 
-0000184449 00000 n 
-0000186912 00000 n 
-0000186334 00000 n 
-0000185037 00000 n 
-0000186460 00000 n 
-0000186589 00000 n 
-0000186718 00000 n 
-0000186847 00000 n 
-0000188482 00000 n 
-0000188291 00000 n 
-0000187024 00000 n 
-0000188417 00000 n 
-0000647434 00000 n 
-0000190597 00000 n 
-0000190277 00000 n 
-0000188581 00000 n 
-0000190403 00000 n 
-0000190532 00000 n 
-0000194902 00000 n 
-0000194534 00000 n 
-0000190709 00000 n 
-0000194837 00000 n 
-0000194681 00000 n 
-0000264290 00000 n 
-0000198790 00000 n 
-0000198470 00000 n 
-0000195027 00000 n 
-0000198596 00000 n 
-0000202882 00000 n 
-0000202386 00000 n 
-0000198915 00000 n 
-0000202687 00000 n 
-0000202752 00000 n 
-0000202817 00000 n 
-0000202533 00000 n 
-0000208035 00000 n 
-0000206902 00000 n 
-0000203007 00000 n 
-0000207970 00000 n 
-0000207085 00000 n 
-0000207241 00000 n 
-0000207426 00000 n 
-0000207600 00000 n 
-0000207785 00000 n 
-0000272323 00000 n 
-0000212172 00000 n 
-0000211981 00000 n 
-0000208227 00000 n 
-0000212107 00000 n 
-0000647559 00000 n 
-0000216151 00000 n 
-0000215831 00000 n 
-0000212297 00000 n 
-0000215957 00000 n 
-0000216086 00000 n 
-0000220494 00000 n 
-0000219505 00000 n 
-0000216263 00000 n 
-0000220173 00000 n 
-0000219670 00000 n 
-0000220302 00000 n 
-0000220430 00000 n 
-0000219839 00000 n 
-0000220005 00000 n 
-0000281677 00000 n 
-0000339791 00000 n 
-0000224304 00000 n 
-0000223794 00000 n 
-0000220660 00000 n 
-0000224110 00000 n 
-0000223941 00000 n 
-0000224239 00000 n 
-0000227405 00000 n 
-0000226956 00000 n 
-0000224429 00000 n 
-0000227082 00000 n 
-0000227211 00000 n 
-0000231466 00000 n 
-0000231275 00000 n 
-0000227571 00000 n 
-0000231401 00000 n 
-0000234642 00000 n 
-0000234324 00000 n 
-0000231578 00000 n 
-0000234450 00000 n 
-0000234579 00000 n 
-0000647684 00000 n 
-0000239021 00000 n 
-0000238215 00000 n 
-0000234795 00000 n 
-0000238700 00000 n 
-0000238829 00000 n 
-0000238371 00000 n 
-0000238957 00000 n 
-0000238545 00000 n 
-0000242523 00000 n 
-0000242074 00000 n 
-0000239133 00000 n 
-0000242200 00000 n 
-0000242329 00000 n 
-0000242458 00000 n 
-0000246422 00000 n 
-0000245755 00000 n 
-0000242676 00000 n 
-0000246228 00000 n 
-0000246357 00000 n 
-0000245911 00000 n 
-0000246073 00000 n 
-0000250105 00000 n 
-0000249337 00000 n 
-0000246588 00000 n 
-0000249653 00000 n 
-0000249484 00000 n 
-0000249846 00000 n 
-0000249911 00000 n 
-0000250040 00000 n 
-0000254580 00000 n 
-0000254034 00000 n 
-0000250284 00000 n 
-0000254515 00000 n 
-0000254190 00000 n 
-0000254352 00000 n 
-0000332906 00000 n 
-0000259003 00000 n 
-0000258364 00000 n 
-0000254746 00000 n 
-0000258680 00000 n 
-0000467609 00000 n 
-0000465612 00000 n 
-0000467444 00000 n 
-0000258809 00000 n 
-0000258511 00000 n 
-0000258938 00000 n 
-0000647809 00000 n 
-0000276607 00000 n 
-0000261168 00000 n 
-0000260977 00000 n 
-0000259129 00000 n 
-0000261103 00000 n 
-0000264485 00000 n 
-0000264035 00000 n 
-0000261280 00000 n 
-0000264161 00000 n 
-0000264355 00000 n 
-0000264420 00000 n 
-0000268471 00000 n 
-0000268023 00000 n 
-0000264625 00000 n 
-0000268149 00000 n 
-0000268406 00000 n 
-0000272388 00000 n 
-0000272069 00000 n 
-0000268583 00000 n 
-0000272195 00000 n 
-0000276671 00000 n 
-0000275594 00000 n 
-0000272500 00000 n 
-0000276224 00000 n 
-0000275759 00000 n 
-0000275910 00000 n 
-0000276353 00000 n 
-0000276481 00000 n 
-0000276070 00000 n 
-0000280097 00000 n 
-0000279778 00000 n 
-0000276783 00000 n 
-0000279904 00000 n 
-0000280033 00000 n 
-0000647934 00000 n 
-0000281742 00000 n 
-0000281422 00000 n 
-0000280209 00000 n 
-0000281548 00000 n 
-0000283200 00000 n 
-0000283009 00000 n 
-0000281854 00000 n 
-0000283135 00000 n 
-0000285934 00000 n 
-0000285355 00000 n 
-0000283299 00000 n 
-0000285481 00000 n 
-0000285610 00000 n 
-0000285739 00000 n 
-0000285804 00000 n 
-0000285869 00000 n 
-0000289857 00000 n 
-0000289537 00000 n 
-0000286046 00000 n 
-0000289663 00000 n 
-0000289792 00000 n 
-0000295474 00000 n 
-0000293080 00000 n 
-0000289969 00000 n 
-0000295280 00000 n 
-0000295409 00000 n 
-0000293326 00000 n 
-0000293488 00000 n 
-0000293650 00000 n 
-0000293811 00000 n 
-0000293971 00000 n 
-0000294142 00000 n 
-0000294304 00000 n 
-0000294466 00000 n 
-0000294628 00000 n 
-0000294791 00000 n 
-0000294954 00000 n 
-0000295117 00000 n 
-0000300692 00000 n 
-0000298631 00000 n 
-0000295599 00000 n 
-0000300627 00000 n 
-0000298868 00000 n 
-0000299030 00000 n 
-0000299192 00000 n 
-0000299353 00000 n 
-0000299514 00000 n 
-0000299676 00000 n 
-0000299839 00000 n 
-0000299993 00000 n 
-0000300147 00000 n 
-0000300309 00000 n 
-0000300469 00000 n 
-0000648059 00000 n 
-0000306003 00000 n 
-0000304030 00000 n 
-0000300817 00000 n 
-0000305681 00000 n 
-0000304249 00000 n 
-0000304411 00000 n 
-0000304573 00000 n 
-0000304734 00000 n 
-0000304896 00000 n 
-0000305050 00000 n 
-0000305211 00000 n 
-0000305365 00000 n 
-0000305527 00000 n 
-0000305875 00000 n 
-0000305939 00000 n 
-0000310358 00000 n 
-0000309291 00000 n 
-0000306128 00000 n 
-0000309779 00000 n 
-0000309907 00000 n 
-0000310164 00000 n 
-0000309447 00000 n 
-0000309617 00000 n 
-0000310229 00000 n 
-0000310294 00000 n 
-0000313806 00000 n 
-0000313485 00000 n 
-0000310483 00000 n 
-0000313611 00000 n 
-0000313676 00000 n 
-0000313741 00000 n 
-0000317732 00000 n 
-0000317282 00000 n 
-0000313905 00000 n 
-0000317408 00000 n 
-0000317473 00000 n 
-0000317538 00000 n 
-0000317667 00000 n 
-0000321548 00000 n 
-0000320840 00000 n 
-0000317857 00000 n 
-0000320966 00000 n 
-0000321031 00000 n 
-0000321096 00000 n 
-0000321161 00000 n 
-0000321226 00000 n 
-0000321354 00000 n 
-0000321418 00000 n 
-0000321483 00000 n 
-0000325389 00000 n 
-0000324552 00000 n 
-0000321673 00000 n 
-0000324678 00000 n 
-0000324807 00000 n 
-0000324872 00000 n 
-0000324937 00000 n 
-0000325066 00000 n 
-0000325131 00000 n 
-0000325196 00000 n 
-0000325324 00000 n 
-0000648184 00000 n 
-0000328630 00000 n 
-0000327924 00000 n 
-0000325568 00000 n 
-0000328050 00000 n 
-0000328179 00000 n 
-0000328308 00000 n 
-0000328437 00000 n 
-0000328566 00000 n 
-0000332970 00000 n 
-0000332521 00000 n 
-0000328823 00000 n 
-0000332647 00000 n 
-0000332712 00000 n 
-0000332777 00000 n 
-0000333436 00000 n 
-0000333245 00000 n 
-0000333095 00000 n 
-0000333371 00000 n 
-0000335376 00000 n 
-0000334927 00000 n 
-0000333478 00000 n 
-0000335053 00000 n 
-0000335182 00000 n 
-0000335311 00000 n 
-0000339856 00000 n 
-0000338912 00000 n 
-0000335488 00000 n 
-0000339275 00000 n 
-0000465291 00000 n 
-0000456078 00000 n 
-0000465105 00000 n 
-0000339059 00000 n 
-0000339404 00000 n 
-0000339533 00000 n 
-0000339662 00000 n 
-0000340894 00000 n 
-0000340703 00000 n 
-0000340089 00000 n 
-0000340829 00000 n 
-0000648309 00000 n 
-0000341321 00000 n 
-0000341130 00000 n 
-0000340980 00000 n 
-0000341256 00000 n 
-0000344634 00000 n 
-0000343408 00000 n 
-0000341363 00000 n 
-0000343925 00000 n 
-0000344054 00000 n 
-0000344183 00000 n 
-0000344312 00000 n 
-0000344441 00000 n 
-0000344570 00000 n 
-0000343564 00000 n 
-0000343736 00000 n 
-0000345088 00000 n 
-0000344897 00000 n 
-0000344747 00000 n 
-0000345023 00000 n 
-0000348332 00000 n 
-0000347754 00000 n 
-0000345130 00000 n 
-0000347880 00000 n 
-0000348009 00000 n 
-0000348138 00000 n 
-0000348267 00000 n 
-0000352611 00000 n 
-0000351392 00000 n 
-0000348418 00000 n 
-0000351903 00000 n 
-0000352032 00000 n 
-0000352290 00000 n 
-0000351548 00000 n 
-0000351727 00000 n 
-0000352483 00000 n 
-0000352547 00000 n 
-0000359497 00000 n 
-0000355669 00000 n 
-0000352763 00000 n 
-0000355795 00000 n 
-0000355860 00000 n 
-0000355925 00000 n 
-0000355990 00000 n 
-0000356055 00000 n 
-0000356120 00000 n 
-0000356185 00000 n 
-0000356250 00000 n 
-0000356315 00000 n 
-0000356380 00000 n 
-0000356510 00000 n 
-0000356575 00000 n 
-0000356640 00000 n 
-0000356705 00000 n 
-0000356770 00000 n 
-0000356835 00000 n 
-0000356900 00000 n 
-0000356965 00000 n 
-0000357030 00000 n 
-0000357095 00000 n 
-0000357160 00000 n 
-0000357225 00000 n 
-0000357290 00000 n 
-0000357355 00000 n 
-0000357420 00000 n 
-0000357485 00000 n 
-0000357550 00000 n 
-0000357615 00000 n 
-0000357680 00000 n 
-0000357745 00000 n 
-0000357810 00000 n 
-0000357875 00000 n 
-0000357940 00000 n 
-0000358005 00000 n 
-0000358069 00000 n 
-0000358134 00000 n 
-0000358199 00000 n 
-0000358264 00000 n 
-0000358329 00000 n 
-0000358394 00000 n 
-0000358459 00000 n 
-0000358524 00000 n 
-0000358589 00000 n 
-0000358654 00000 n 
-0000358719 00000 n 
-0000358784 00000 n 
-0000358849 00000 n 
-0000358914 00000 n 
-0000358979 00000 n 
-0000359044 00000 n 
-0000359109 00000 n 
-0000359174 00000 n 
-0000359239 00000 n 
-0000359304 00000 n 
-0000359369 00000 n 
-0000359433 00000 n 
-0000648434 00000 n 
-0000366143 00000 n 
-0000362579 00000 n 
-0000359609 00000 n 
-0000362705 00000 n 
-0000362770 00000 n 
-0000362835 00000 n 
-0000362900 00000 n 
-0000362965 00000 n 
-0000363030 00000 n 
-0000363095 00000 n 
-0000363160 00000 n 
-0000363225 00000 n 
-0000363290 00000 n 
-0000363355 00000 n 
-0000363420 00000 n 
-0000363484 00000 n 
-0000363549 00000 n 
-0000363614 00000 n 
-0000363679 00000 n 
-0000363744 00000 n 
-0000363809 00000 n 
-0000363874 00000 n 
-0000363939 00000 n 
-0000364004 00000 n 
-0000364069 00000 n 
-0000364134 00000 n 
-0000364199 00000 n 
-0000364263 00000 n 
-0000364328 00000 n 
-0000364393 00000 n 
-0000364458 00000 n 
-0000364523 00000 n 
-0000364588 00000 n 
-0000364653 00000 n 
-0000364718 00000 n 
-0000364783 00000 n 
-0000364848 00000 n 
-0000364913 00000 n 
-0000364978 00000 n 
-0000365043 00000 n 
-0000365108 00000 n 
-0000365173 00000 n 
-0000365238 00000 n 
-0000365302 00000 n 
-0000365366 00000 n 
-0000365430 00000 n 
-0000365495 00000 n 
-0000365560 00000 n 
-0000365625 00000 n 
-0000365690 00000 n 
-0000365755 00000 n 
-0000365820 00000 n 
-0000365885 00000 n 
-0000365950 00000 n 
-0000366015 00000 n 
-0000366079 00000 n 
-0000372318 00000 n 
-0000368880 00000 n 
-0000366255 00000 n 
-0000369006 00000 n 
-0000369071 00000 n 
-0000369136 00000 n 
-0000369201 00000 n 
-0000369266 00000 n 
-0000369331 00000 n 
-0000369396 00000 n 
-0000369461 00000 n 
-0000369526 00000 n 
-0000369591 00000 n 
-0000369656 00000 n 
-0000369721 00000 n 
-0000369786 00000 n 
-0000369851 00000 n 
-0000369916 00000 n 
-0000369981 00000 n 
-0000370046 00000 n 
-0000370111 00000 n 
-0000370176 00000 n 
-0000370241 00000 n 
-0000370306 00000 n 
-0000370371 00000 n 
-0000370436 00000 n 
-0000370501 00000 n 
-0000370566 00000 n 
-0000370631 00000 n 
-0000370696 00000 n 
-0000370761 00000 n 
-0000370826 00000 n 
-0000370891 00000 n 
-0000370956 00000 n 
-0000371021 00000 n 
-0000371086 00000 n 
-0000371151 00000 n 
-0000371215 00000 n 
-0000371280 00000 n 
-0000371345 00000 n 
-0000371410 00000 n 
-0000371475 00000 n 
-0000371540 00000 n 
-0000371605 00000 n 
-0000371670 00000 n 
-0000371735 00000 n 
-0000371800 00000 n 
-0000371865 00000 n 
-0000371930 00000 n 
-0000371995 00000 n 
-0000372060 00000 n 
-0000372125 00000 n 
-0000372190 00000 n 
-0000372254 00000 n 
-0000376897 00000 n 
-0000374633 00000 n 
-0000372430 00000 n 
-0000374759 00000 n 
-0000374824 00000 n 
-0000374889 00000 n 
-0000374954 00000 n 
-0000375019 00000 n 
-0000375084 00000 n 
-0000375149 00000 n 
-0000375214 00000 n 
-0000375279 00000 n 
-0000375344 00000 n 
-0000375409 00000 n 
-0000375474 00000 n 
-0000375539 00000 n 
-0000375604 00000 n 
-0000375666 00000 n 
-0000375730 00000 n 
-0000375795 00000 n 
-0000375859 00000 n 
-0000375924 00000 n 
-0000375989 00000 n 
-0000376054 00000 n 
-0000376119 00000 n 
-0000376184 00000 n 
-0000376249 00000 n 
-0000376314 00000 n 
-0000376443 00000 n 
-0000376572 00000 n 
-0000376637 00000 n 
-0000376702 00000 n 
-0000376767 00000 n 
-0000376832 00000 n 
-0000379664 00000 n 
-0000379020 00000 n 
-0000377022 00000 n 
-0000379146 00000 n 
-0000379275 00000 n 
-0000379404 00000 n 
-0000379469 00000 n 
-0000379534 00000 n 
-0000379599 00000 n 
-0000384149 00000 n 
-0000383828 00000 n 
-0000379776 00000 n 
-0000383954 00000 n 
-0000384019 00000 n 
-0000384084 00000 n 
-0000387400 00000 n 
-0000387144 00000 n 
-0000384301 00000 n 
-0000387270 00000 n 
-0000387335 00000 n 
-0000648559 00000 n 
-0000390650 00000 n 
-0000390459 00000 n 
-0000387538 00000 n 
-0000390585 00000 n 
-0000394430 00000 n 
-0000394174 00000 n 
-0000390775 00000 n 
-0000394300 00000 n 
-0000394365 00000 n 
-0000397604 00000 n 
-0000396829 00000 n 
-0000394568 00000 n 
-0000396955 00000 n 
-0000397020 00000 n 
-0000397085 00000 n 
-0000397150 00000 n 
-0000397215 00000 n 
-0000397344 00000 n 
-0000397409 00000 n 
-0000397474 00000 n 
-0000397539 00000 n 
-0000402075 00000 n 
-0000401884 00000 n 
-0000397742 00000 n 
-0000402010 00000 n 
-0000405203 00000 n 
-0000404430 00000 n 
-0000402213 00000 n 
-0000404556 00000 n 
-0000404621 00000 n 
-0000404686 00000 n 
-0000404750 00000 n 
-0000404879 00000 n 
-0000404944 00000 n 
-0000405008 00000 n 
-0000405073 00000 n 
-0000405138 00000 n 
-0000408593 00000 n 
-0000408337 00000 n 
-0000405341 00000 n 
-0000408463 00000 n 
-0000408528 00000 n 
-0000648684 00000 n 
-0000411453 00000 n 
-0000410743 00000 n 
-0000408731 00000 n 
-0000410869 00000 n 
-0000410934 00000 n 
-0000410999 00000 n 
-0000411064 00000 n 
-0000411193 00000 n 
-0000411258 00000 n 
-0000411323 00000 n 
-0000411388 00000 n 
-0000415132 00000 n 
-0000414876 00000 n 
-0000411604 00000 n 
-0000415002 00000 n 
-0000415067 00000 n 
-0000418569 00000 n 
-0000418313 00000 n 
-0000415257 00000 n 
-0000418439 00000 n 
-0000418504 00000 n 
-0000421040 00000 n 
-0000420332 00000 n 
-0000418707 00000 n 
-0000420458 00000 n 
-0000420523 00000 n 
-0000420588 00000 n 
-0000420715 00000 n 
-0000420780 00000 n 
-0000420845 00000 n 
-0000420910 00000 n 
-0000420975 00000 n 
-0000423926 00000 n 
-0000423152 00000 n 
-0000421191 00000 n 
-0000423278 00000 n 
-0000423343 00000 n 
-0000423408 00000 n 
-0000423473 00000 n 
-0000423601 00000 n 
-0000423666 00000 n 
-0000423731 00000 n 
-0000423796 00000 n 
-0000423861 00000 n 
-0000427282 00000 n 
-0000427091 00000 n 
-0000424064 00000 n 
-0000427217 00000 n 
-0000648809 00000 n 
-0000430235 00000 n 
-0000429525 00000 n 
-0000427407 00000 n 
-0000429651 00000 n 
-0000429716 00000 n 
-0000429781 00000 n 
-0000429846 00000 n 
-0000429975 00000 n 
-0000430040 00000 n 
-0000430105 00000 n 
-0000430170 00000 n 
-0000433534 00000 n 
-0000433278 00000 n 
-0000430386 00000 n 
-0000433404 00000 n 
-0000433469 00000 n 
-0000436418 00000 n 
-0000436034 00000 n 
-0000433727 00000 n 
-0000436160 00000 n 
-0000436225 00000 n 
-0000436290 00000 n 
-0000436354 00000 n 
-0000439896 00000 n 
-0000439186 00000 n 
-0000436650 00000 n 
-0000439312 00000 n 
-0000439377 00000 n 
-0000439442 00000 n 
-0000439571 00000 n 
-0000439636 00000 n 
-0000439701 00000 n 
-0000439766 00000 n 
-0000439831 00000 n 
-0000443031 00000 n 
-0000442322 00000 n 
-0000440047 00000 n 
-0000442448 00000 n 
-0000442513 00000 n 
-0000442578 00000 n 
-0000442642 00000 n 
-0000442771 00000 n 
-0000442836 00000 n 
-0000442901 00000 n 
-0000442966 00000 n 
-0000446214 00000 n 
-0000445958 00000 n 
-0000443195 00000 n 
-0000446084 00000 n 
-0000446149 00000 n 
-0000648934 00000 n 
-0000448960 00000 n 
-0000448317 00000 n 
-0000446339 00000 n 
-0000448443 00000 n 
-0000448508 00000 n 
-0000448573 00000 n 
-0000448638 00000 n 
-0000448766 00000 n 
-0000448831 00000 n 
-0000448896 00000 n 
-0000452693 00000 n 
-0000452373 00000 n 
-0000449111 00000 n 
-0000452499 00000 n 
-0000452564 00000 n 
-0000452629 00000 n 
-0000454018 00000 n 
-0000453632 00000 n 
-0000452818 00000 n 
-0000453758 00000 n 
-0000453823 00000 n 
-0000453888 00000 n 
-0000453953 00000 n 
-0000454189 00000 n 
-0000465533 00000 n 
-0000467856 00000 n 
-0000467825 00000 n 
-0000477345 00000 n 
-0000487401 00000 n 
-0000497639 00000 n 
-0000509844 00000 n 
-0000527977 00000 n 
-0000550065 00000 n 
-0000571075 00000 n 
-0000588893 00000 n 
-0000591724 00000 n 
-0000591494 00000 n 
-0000618982 00000 n 
-0000646091 00000 n 
-0000649041 00000 n 
-0000649164 00000 n 
-0000649290 00000 n 
-0000649416 00000 n 
-0000649506 00000 n 
-0000649598 00000 n 
-0000664889 00000 n 
-0000682155 00000 n 
-0000682196 00000 n 
-0000682236 00000 n 
-0000682370 00000 n 
-trailer
-<<
-/Size 1948
-/Root 1946 0 R
-/Info 1947 0 R
-/ID [<FC34A9E475CA4461718A60185182A60D> <FC34A9E475CA4461718A60185182A60D>]
->>
-startxref
-682634
-%%EOF
diff --git a/contrib/bind9/doc/arm/Makefile.in b/contrib/bind9/doc/arm/Makefile.in
deleted file mode 100644
index 85f318d..0000000
--- a/contrib/bind9/doc/arm/Makefile.in
+++ /dev/null
@@ -1,67 +0,0 @@
-# Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
-# Copyright (C) 2001, 2002  Internet Software Consortium.
-#
-# Permission to use, copy, modify, and/or distribute this software for any
-# purpose with or without fee is hereby granted, provided that the above
-# copyright notice and this permission notice appear in all copies.
-#
-# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
-# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
-# AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
-# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
-# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
-# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
-# PERFORMANCE OF THIS SOFTWARE.
-
-# $Id: Makefile.in,v 1.12.18.8 2007/08/28 07:20:03 tbox Exp $
-
-srcdir =	@srcdir@
-VPATH =		@srcdir@
-top_srcdir =	@top_srcdir@
-
-@BIND9_MAKE_RULES@
-
-@BIND9_VERSION@
-
-MANOBJS = Bv9ARM.html
-
-PDFOBJS = Bv9ARM.pdf
-
-doc man:: ${MANOBJS} ${PDFOBJS}
-
-clean::
-	rm -f Bv9ARM.aux Bv9ARM.brf Bv9ARM.glo Bv9ARM.idx Bv9ARM.toc
-	rm -f Bv9ARM.log Bv9ARM.out Bv9ARM.tex Bv9ARM.tex.tmp
-
-docclean manclean maintainer-clean:: clean
-	rm -f *.html ${PDFOBJS}
-
-docclean manclean maintainer-clean distclean::
-	rm -f releaseinfo.xml
-
-Bv9ARM.html: Bv9ARM-book.xml releaseinfo.xml
-	expand Bv9ARM-book.xml | \
-	${XSLTPROC} --stringparam root.filename Bv9ARM \
-		${top_srcdir}/doc/xsl/isc-docbook-chunk.xsl -
-
-Bv9ARM.tex: Bv9ARM-book.xml releaseinfo.xml
-	expand Bv9ARM-book.xml | \
-	${XSLTPROC} ${top_srcdir}/doc/xsl/pre-latex.xsl - | \
-	${XSLTPROC} ${top_srcdir}/doc/xsl/isc-docbook-latex.xsl - | \
-	@PERL@ latex-fixup.pl >$@.tmp 
-	if test -s $@.tmp; then mv $@.tmp $@; else rm -f $@.tmp; exit 1; fi
-
-Bv9ARM.dvi: Bv9ARM.tex releaseinfo.xml
-	rm -f Bv9ARM-book.aux Bv9ARM-book.dvi Bv9ARM-book.log
-	${LATEX} '\batchmode\input Bv9ARM.tex' || (rm -f $@ ; exit 1)
-	${LATEX} '\batchmode\input Bv9ARM.tex' || (rm -f $@ ; exit 1)
-	${LATEX} '\batchmode\input Bv9ARM.tex' || (rm -f $@ ; exit 1)
-
-Bv9ARM.pdf: Bv9ARM.tex releaseinfo.xml
-	rm -f Bv9ARM-book.aux Bv9ARM-book.pdf Bv9ARM-book.log
-	${PDFLATEX} '\batchmode\input Bv9ARM.tex' || (rm -f $@ ; exit 1)
-	${PDFLATEX} '\batchmode\input Bv9ARM.tex' || (rm -f $@ ; exit 1)
-	${PDFLATEX} '\batchmode\input Bv9ARM.tex' || (rm -f $@ ; exit 1)
-
-releaseinfo.xml:
-	echo >$@ '<releaseinfo>BIND Version ${VERSION}</releaseinfo>'
diff --git a/contrib/bind9/doc/arm/README-SGML b/contrib/bind9/doc/arm/README-SGML
deleted file mode 100644
index e33c937..0000000
--- a/contrib/bind9/doc/arm/README-SGML
+++ /dev/null
@@ -1,329 +0,0 @@
-Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
-Copyright (C) 2000, 2001  Internet Software Consortium.
-See COPYRIGHT in the source root or http://isc.org/copyright.html for terms.
-
-The BIND v9 ARM master document is now kept in DocBook XML format.
-
-Version: $Id: README-SGML,v 1.17 2004/03/05 05:04:43 marka Exp $
-
-The entire ARM is in the single file:
-
-    Bv9ARM-book.xml
-
-All of the other documents - HTML, PDF, etc - are generated from this
-master source.
-
-This file attempts to describe what tools are necessary for the
-maintenance of this document as well as the generation of the
-alternate formats of this document.
-
-This file will also spend a very little time describing the XML and
-SGML headers so you can understand a bit what you may need to do to be
-able to work with this document in any fashion other than simply
-editing it. 
-
-We will spend almost no time on the actual tags and how to write an
-XML DocBook compliant document. If you are at all familiar with SGML
-or HTML it will be very evident. You only need to know what the tags
-are and how to use them. You can find a good resource either for this
-either online or in printed form:
-
-    DocBook: The Definitive Guide
-    By Norman Walsh and Leonard Muellner
-    ISBN: 156592-580-7
-    1st Edition, October 1999
-    Copyright (C) 1999 by O'Reilly & Associates, Inc. All rights reserved.
-
-The book is available online in HTML format:
-
-    http://docbook.org/
-
-and buried in:
-
-    http://www.nwalsh.com/docbook/defguide/index.html
-
-A lot of useful stuff is at NWalsh's site in general. You may also
-want to look at:
-
-    http://www.xml.com/
-
-The BIND v9 ARM is based on the XML 4.0 DocBook DTD. Every XML and
-SGML document begins with a prefix that tells where to find the file
-that describes the meaning and structure of the tags used in the rest
-of the document.
-
-For our XML DocBook 4.0 based document this prefix looks like this:
-
-    <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
-		   "/usr/local/share/xml/dtd/docbook/docbookx.dtd">
-
-This "DOCTYPE" statement has three parts, of which we are only using
-two:
-
-o The highest level term that represents this document (in this case
-  it is "book"
-
-o The identifier that tells us which DTD to use. This identifier has
-  two parts, the "Formal Public Identifier" (or FPI) and the system
-  identifier. In SGML you can have either a FPI or a SYSTEM identifier
-  but you have to have at least one of them. In XML you have to have a
-  SYSTEM identifier.
-
-FP & SYSTEM identifiers - These are names/lookups for the actual
-DTD. The FPI is a globally unique name that should, on a properly
-configured system, tell you exactly what DTD to use. The SYSTEM
-identifier gives an absolute location for the DTD. In XML these are
-supposed to be properly formatted URL's.
-
-SGML has these things called "catalogs" that are files that map FPI's
-in to actual files. A "catalog" can also be used to remap a SYSTEM
-identifier so you can say something like: "http://www.oasis.org/foo"
-is actually "/usr/local/share/xml/foo.dtd"
-
-When you use various SGML/XML tools they need to be configured to look
-at the same "catalog" files so that as you move from tool to tool they
-all refer to the same DTD for the same document.
-
-We will be spending most of our configuration time making sure our
-tools use the same "catalog" files and that we have the same DTD's
-installed on our machines. XML's requirement of the SYSTEM identifier
-over the FPI will probably lead to more problems as it does not
-guarantee that everyone is using the same DTD.
-
-I did my initial work with the "sgmltools" the XML 4.0 DocBook DTD and
-"jade" or "openjade."
-
-You can get the 4.0 XML DocBook DTD from:
-
-    http://www.docbook.org/xml/4.0/
-
-(download the .zip file.) NOTE: We will eventually be changing the
-SYSTEM identifier to the recommended value of:
-
-    http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd
-
-NOTE: Under FreeBSD this is the package: 
-
-    /usr/ports/textproc/docbook-xml
-
-NetBSD instructions are coming soon.
-
-With packages listed below installed under FreeBSD the "catalog" file
-that all the tools refer to at least one is in:
-
-    /usr/local/share/sgml/catalog
-
-In order for our SYSTEM identifier for the XML DocBook dtd to be found
-I create a new catalog file at the top of the XML directory created on
-FreeBSD:
-
-   /usr/local/share/xml/catalog
-
-This file has one line:
-
-   SYSTEM "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd" "/usr/local/share/xml/dtd/docbook/docbookx.dtd"
-
-Then in the main "catalog" I have it include this XML catalog:
-
-   CATALOG "/usr/local/share/xml/catalog"
-
-
-On your systems you need to replace "/usr/local/share" with your
-prefix root (probably /usr/pkg under NetBSD.)
-
-NOTE: The URL used above is supposed to the be the proper one for this
-XML DocBook DTD... but there is nothing at that URL so you really do
-need the "SYSTEM" identifier mapping in your catalog (or make the
-SYSTEM identifier in your document refer to the real location of the
-file on your local system.)
-
-HOW TO VALIDATE A DOCUMENT:
-
-I use the sgmltools "nsgmls" document validator. Since we are using
-XML we need to use the XML declarations, which are installed as part
-of the modular DSSL style sheets:
-
-    nsgmls -sv /usr/local/share/sgml/docbook/dsssl/modular/dtds/decls/xml.dcl \
-	   Bv9ARM-book.xml
-
-A convenient shell script "validate.sh" is now generated by configure
-to invoke the above command with the correct system-dependent paths.
-
-The SGML tools can be found at:
-
-    ftp://ftp.us.sgmltools.org/pub/SGMLtools/v2.0/source/ \
-    ftp://ftp.nllgg.nl/pub/SGMLtools/v2.0/source/
-
-FreeBSD package for these is: 
-
-    /usr/ports/textproc/sgmltools
-
-HOW TO RENDER A DOCUMENT AS HTML or TeX:
-
-o Generate html doc with:
-
-    openjade -v -d ./nominum-docbook-html.dsl \
-	 -t sgml \
-	 /usr/local/share/sgml/docbook/dsssl/modular/dtds/decls/xml.dcl \
-	 Bv9ARM-book.xml
-
-A convenient shell script "genhtml.sh" is now generated by configure to
-invoke the above command with the correct system-dependent paths.
-
-On NetBSD there is no port for "openjade" however "jade" does still
-work. However you need to specify the "catalog" file to use for style
-sheets on the command line AND you need to have a default "catalog"
-mapping where to find various DTDs. It seems that "jade" installed out
-of the box on NetBSD does not use a globally defined "catalog" file
-for mapping PUBLIC identifiers in to SYSTEM identifiers.
-
-So you need to have a "catalog" file in your current working directory
-that has in it this: (these are probably more entries than you need!)
-
-     CATALOG "/usr/pkg/share/sgml/iso8879/catalog"
-     CATALOG "/usr/pkg/share/sgml/docbook/2.4.1/catalog"
-     CATALOG "/usr/pkg/share/sgml/docbook/3.0/catalog"
-     CATALOG "/usr/pkg/share/sgml/docbook/3.1/catalog"
-     CATALOG "/usr/pkg/share/sgml/jade/catalog"
-     CATALOG "/usr/local/share/xml/catalog"
-
-(These would all be "/usr/local" on FreeBSD)
-
-So the command for jade on NetBSD will look like this:
-
-jade -v -c /usr/pkg/share/sgml/catalog -t sgml \
-     -d ./nominum-docbook-html.dsl \
-     /usr/pkg/share/sgml/docbook/dsssl/modular/dtds/decls/xml.dcl \
-     ./Bv9ARM-book.xml
-
-Furthermore, since the style sheet subset we define has in it a hard
-coded path to the style sheet is based, it is actually generated by
-configure from a .in file so that it will contain the correct
-system-dependent path: where on FreeBSD the second line reads:
-
-    <!ENTITY dbstyle SYSTEM "/usr/local/share/sgml/docbook/dsssl/modular/html/docbook.dsl" CDATA DSSSL>
-  
-On NetBSD it needs to read:
-
-    <!ENTITY dbstyle SYSTEM "/usr/pkg/share/sgml/docbook/dsssl/modular/html/docbook.dsl" CDATA DSSSL>
-
-NOTE: This is usually solved by having this style sheet modification
-be installed in a system directory and have it reference the style
-sheet it is based on via a relative path.
-
-o Generate TeX documentation:
-
-openjade -d ./nominum-docbook-print.dsl -t tex -v \
-     /usr/local/share/sgml/docbook/dsssl/modular/dtds/decls/xml.dcl \
-     Bv9ARM-book.xml
-
-If you have "jade" installed instead of "openjade" then use that as
-the command. There is little difference, openjade has some bug fixes
-and is in more active development.
-
-To convert the resulting TeX file in to a DVI file you need to do:
-
-    tex "&jadetex" Bv9ARM-book.tex
-
-You can also directly generate the pdf file via:
-
-    pdftex "&pdfjadetex" Bv9ARM-book.tex
-
-The scripts "genpdf.sh" and "gendvi." have been added to simply
-generating the  PDF and DVI output. These substitute the correct paths
-of NetBSD & FreeBSD. You still need to have TeX, jadeTeX, and pdfTeX
-installed and configured properly for these to work.
-
-You will need to up both the "pool_size" and "hash_extra" variables in
-your texmf.cnf file and regenerate them. See below.
-
-You can see that I am using a DSSSL style sheet for DocBook. Actually
-two different ones - one for rendering html, and one for 'print'
-media.
-
-NOTE: For HTML we are using a Nominum DSSSL style instead of the
-default one (all it does is change the chunking to the chapter level
-and makes the files end with ".html" instead of ".htm" so far.) If you
-want to use the plain jane DSSSL style sheet replace the:
-
-    -d ./nominum-docbook-html.dsl
-
-with
-
-    -d /usr/local/share/sgml/docbook/dsssl/modular/html/docbook.dsl
-
-This style sheet will attempt to reference the one above.
-
-I am currently working on fixing these up so that it works the same on
-our various systems. The main trick is knowing which DTD's and DSSSL
-stylesheets you have installed, installing the right ones, and
-configuring a CATALOG that refers to them in the same way. We will
-probably end up putting our CATALOG's in the same place and then we
-should be able to generate and validate our documents with a minimal
-number of command line arguments.
-
-When running these commands you will get a lot of messages about a
-bunch of general entities not being defined and having no default
-entity. You can ignore those for now.
-
-Also with the style sheets we have and jade as it is you will get
-messages about "xref to title" being unsupported. You can ignore these
-for now as well.
-
-=== Getting the various tools installed on FreeBSD
-(NetBSD coming soon..)
-
-o On freebsd you need to install the following packages:
-  o print/teTeX
-  o textproc/openjade
-  o textproc/docbook
-  o textproc/docbook-xml
-  o textproc/dsssl-docbook-modular
-  o textproc/dtd-catalogs
-
-o on freebsd you need to make some entities visible to the docbook xml
-  dtd by making a symlink (can probably be done with a catalog too)
-  ln -s /usr/local/share/xml/entity /usr/local/share/xml/dtd/docbook/ent
-
-o you may need to edit /usr/local/share/sgml/catalog and add the line:
-
-  CATALOG "/usr/local/share/sgml/openjade/catalog"
-
-o add "hugelatex," Enlarge pool sizes, install the jadetex TeX driver
-  file.
-
-  cd /usr/local/share/texmf/web2c/
-  sudo cp texmf.cnf texmf.cnf.bak
-
-  o edit the lines in texmf.cnf with these keys to these values:
-
-                  main_memory = 1100000
-                  hash_extra = 15000
-                  pool_size = 500000
-                  string_vacancies = 45000
-                  max_strings = 55000
-                  pool_free = 47500
-                  nest_size = 500
-                  param_size = 1500
-                  save_size = 5000
-                  stack_size = 1500
-
-  sudo tex -ini -progname=hugelatex -fmt=hugelatex latex.ltx
-  sudo texconfig init
-  sudo texhash
-
-  o For the jadetex macros you will need I recommend you get a more
-    current version than what is packaged with openjade or jade.
-
-    Checkout http://www.tug.org/applications/jadetex/
-    
-    Unzip the file you get from there (should be jadetex-2.20 or
-    newer.) 
-
-    In the directory you unzip: 
-
-      sudo make install
-      sudo texhash
-
-    NOTE: In the most uptodate "ports" for FreeBSD, jadetext is 2.20+
-    so on this platform you should be set as of 2001.01.08.
diff --git a/contrib/bind9/doc/arm/isc-logo.eps b/contrib/bind9/doc/arm/isc-logo.eps
deleted file mode 100644
index c6a1d7a..0000000
--- a/contrib/bind9/doc/arm/isc-logo.eps
+++ /dev/null
@@ -1,12253 +0,0 @@
-%!PS-Adobe-3.1 EPSF-3.0
-%%Title: Alternate-ISC-logo-v2.ai
-%%Creator: Adobe Illustrator(R) 11
-%%AI8_CreatorVersion: 11.0.0
-%AI9_PrintingDataBegin
-%%For: Douglas E. Appelt
-%%CreationDate: 10/22/04
-%%BoundingBox: 0 0 255 149
-%%HiResBoundingBox: 0 0 254.8672 148.7520
-%%CropBox: 0 0 254.8672 148.7520
-%%LanguageLevel: 2
-%%DocumentData: Clean7Bit
-%%Pages: 1
-%%DocumentNeededResources:
-%%DocumentSuppliedResources: procset Adobe_AGM_Image (1.0 0)
-%%+ procset Adobe_CoolType_Utility_T42 (1.0 0)
-%%+ procset Adobe_CoolType_Utility_MAKEOCF (1.19 0)
-%%+ procset Adobe_CoolType_Core (2.23 0)
-%%+ procset Adobe_AGM_Core (2.0 0)
-%%+ procset Adobe_AGM_Utils (1.0 0)
-%%DocumentFonts:
-%%DocumentNeededFonts:
-%%DocumentNeededFeatures:
-%%DocumentSuppliedFeatures:
-%%DocumentProcessColors:  Cyan Magenta Yellow Black
-%%DocumentCustomColors: (PANTONE 1805 C)
-%%+ (PANTONE 871 C)
-%%+ (PANTONE 301 C)
-%%+ (PANTONE 7506 C)
-%%CMYKCustomColor: 0 0.9100 1 0.2300 (PANTONE 1805 C)
-%%+ 0.3569 0.3608 0.6353 0.1882 (PANTONE 871 C)
-%%+ 1 0.4500 0 0.1800 (PANTONE 301 C)
-%%+ 0 0.0500 0.1500 0 (PANTONE 7506 C)
-%%RGBCustomColor:
-%ADO_ContainsXMP: MainFirst
-%AI7_Thumbnail: 128 76 8
-%%BeginData: 10692 Hex Bytes
-%0000330000660000990000CC0033000033330033660033990033CC0033FF
-%0066000066330066660066990066CC0066FF009900009933009966009999
-%0099CC0099FF00CC0000CC3300CC6600CC9900CCCC00CCFF00FF3300FF66
-%00FF9900FFCC3300003300333300663300993300CC3300FF333300333333
-%3333663333993333CC3333FF3366003366333366663366993366CC3366FF
-%3399003399333399663399993399CC3399FF33CC0033CC3333CC6633CC99
-%33CCCC33CCFF33FF0033FF3333FF6633FF9933FFCC33FFFF660000660033
-%6600666600996600CC6600FF6633006633336633666633996633CC6633FF
-%6666006666336666666666996666CC6666FF669900669933669966669999
-%6699CC6699FF66CC0066CC3366CC6666CC9966CCCC66CCFF66FF0066FF33
-%66FF6666FF9966FFCC66FFFF9900009900339900669900999900CC9900FF
-%9933009933339933669933999933CC9933FF996600996633996666996699
-%9966CC9966FF9999009999339999669999999999CC9999FF99CC0099CC33
-%99CC6699CC9999CCCC99CCFF99FF0099FF3399FF6699FF9999FFCC99FFFF
-%CC0000CC0033CC0066CC0099CC00CCCC00FFCC3300CC3333CC3366CC3399
-%CC33CCCC33FFCC6600CC6633CC6666CC6699CC66CCCC66FFCC9900CC9933
-%CC9966CC9999CC99CCCC99FFCCCC00CCCC33CCCC66CCCC99CCCCCCCCCCFF
-%CCFF00CCFF33CCFF66CCFF99CCFFCCCCFFFFFF0033FF0066FF0099FF00CC
-%FF3300FF3333FF3366FF3399FF33CCFF33FFFF6600FF6633FF6666FF6699
-%FF66CCFF66FFFF9900FF9933FF9966FF9999FF99CCFF99FFFFCC00FFCC33
-%FFCC66FFCC99FFCCCCFFCCFFFFFF33FFFF66FFFF99FFFFCC110000001100
-%000011111111220000002200000022222222440000004400000044444444
-%550000005500000055555555770000007700000077777777880000008800
-%000088888888AA000000AA000000AAAAAAAABB000000BB000000BBBBBBBB
-%DD000000DD000000DDDDDDDDEE000000EE000000EEEEEEEE0000000000FF
-%00FF0000FFFFFF0000FF00FFFFFF00FFFFFF
-%524C45FD1CF852FD63FFF820272726272727264B27272627272726272727
-%26272727264B20F827FD63FFF827FFFFFFCFFF84365AFFFFFFCFFFFFFFCF
-%FFFFFFCFFD04FFCAF852FD63FFF827CFCFCACFCA2F0607A8CFCACFCACFCA
-%CFCACFCACFCACFCACF7CF827FD63FFF800FFCFFFA8A8070D06A8CFFFCFFF
-%CFFFCFFFCFFFCFFFCFFFCFA7F852FD63FFF800077E2F0D060D060706537D
-%CF7D2FA8CFCACFCACFCACFCAFF7CF827FD63FFF8000D062F070D062F070D
-%062F2F0D062FCACFCFFFCFCFCFFFCFA1F852FD63FFF8050707062E517651
-%522807060706072ECFCACFCACFCACFCAFF7CF827FD63FFF8002F067C757B
-%757C757B512F072F2FFFCFCFCFFFCFFFCFFFCFA1F852FD63FFF805075251
-%75517551755175512F062FCACFCACFCACFCACFCAFF7CF827FD63FFF8F859
-%75765176757C517C757B2E2F07A8CFFFCFCFCFFFCFCFCFA1F852FD63FFF8
-%00517551757CCFCAA751755175060753CFCACFCACFCACFCACF7CF827FD63
-%FFF8F87C75757CFFCFFFCFA7517C752F072F59A8CFCFCFFFCFFFCFA7F852
-%FD04FFA87D527DA8FD5AFFF827757551A1CFCFCAFFA0755175280D060706
-%A8CFCFCACFCAFF7CF827FD05FF27F827FD5BFFF8F87C51767CFFCFFFCFA0
-%517C752F062F060D84FFCFFFCFFFCFA1F852FD05FF7DF87DFD5BFFF80552
-%7551757CC9A7A05175517606072F7E7DCFCACFC9CFCAFF6FF827FD05FF52
-%F852FD27FFA8FD33FFF80059757C7575517C517C517C2E2F06CFCFFFCFCF
-%9293CAFFCF6FF852FD05FF7DF87DFD04FFA8FD05FF7D7DA8FF527D7D7D52
-%7D52A8FFA8527D527DA8FF7D7D527D52FD05FFA8FD05FFA87D7DFFFFA852
-%7D527DA8FF527D7D7D527D52A8FD19FFF805075275755175517551752D0D
-%0653CFFFCFFFA78C6899939344F827FD05FF52F852FFFFFFA8F87DFD04FF
-%7D27FFA87D7DA8F827A87D7DFFA8F827A8527DFFA8F852A827F8A8FFFFFF
-%7DF8FD05FF2752FFFFA8F827A8527DA87D7DA8F827A87D7DFD19FFF8F82F
-%0752517C757B757C2E0D062FA8C999CFCFC28C928C8C8C6EF852FD05FF7D
-%F87DFD04FFF8F87DFFFFFF7D52FD05FFF852FD05FFF87DFD05FFF852FFFF
-%F852FFFFFF7DF8F8FD04FF7D52FFFFFFF87DFD07FFF852FD1CFFF8000607
-%062F2852282E060D0607067D928C9293688C6892688C44F827FD05FF52F8
-%52FFFFFFA85252F852FFFF7D27FD05FFF87DFD04FFA8F852FD05FFF852FF
-%FFF8A8FFFFFF7D5227F8A8FFFF527DFFFFA8F852FD07FFF87DFD1CFFF800
-%852F2F062F070D062F072F062F0D9A8C928C928C928C928C6EF852FD05FF
-%7DF87DFD04FF27FF52F852FF7D52FD05FFF852FD05FFF82752527DFFFFF8
-%52FF527DFD04FF527DFF27F8A8FF7D7DFFFFFFF82752527DFD04FFF852FD
-%1CFFF827CFCF7D2F060D062F2F7EA82F062F938C68928C8C68926E994AF8
-%27FD05FF52F852FFFFFFA827FFFF52F852A852FD05FFF87DFD04FFA8F852
-%FF7DA8FFFFF82752F8A8FD04FF7D52FFA827F8A87D7DFFFFA8F852FF7DA8
-%FD04FFF87DFD1CFFF827FFCFFFA80D062FA8CFCFCA927693928C928C9292
-%75517C7B51F852FD05FF7DF87DFFFFFFA827FFFFFF52F8F87DFD05FFF852
-%FD05FFF87DFD05FFF852FF52F8A8FFFFFF5252FFFFFF27F8277DFFFFFFF8
-%7DFD07FFF852FD1CFFF827CFCFCACF06062ECFCAFF928C688C6892688C6E
-%765175517C26F827FD05FF52F852FFFFFFA827FD04FF52F852FD05FFF852
-%FD04FFA8F852FFFFA8A8FFF87DFFFFF8F8A8FFFF5227FD04FF27F8A8FFFF
-%A8F852FFFFA8A8FFFFFFF852FD1CFFF827FFCFFFCF7E53A8CFFFCFC99292
-%8C928C92757C757C517C7551F852FD04FFA852F852A8FFFFA8F8A8FD04FF
-%527DFD04FF7DF827FD04FFA8F827525252FF7DF827FFFFFF2727A8FF5227
-%A8FD04FF52A8FFFFA8F827525252FFFFFF7DF827FD1CFFF827CFCFCACFCF
-%CFCAFD04CF93688C688C6F7651755175517C4BF827FD05FFA8FFA8FFFFFF
-%A8FFA8FD0BFFA8FFA8FFFFFFA8FFA8A8A8FFFFFFA8FFA8FFFFFFA8FFA8FF
-%A8FD09FFA8FFA8A8A8FD05FFA8FFA8FD1BFFF827FFCFCFCFFFCFCFCFFFCF
-%C38C928C8C6E7C7576517C75767551F852FD63FFF827CFCFCACFCACFCACF
-%92928C8C688C6875517551755175517526F827FD63FFF827FFCFFFCFFFCF
-%FFCA938C928C928C99517C757C517C757C7551F852FD63FFF827CFCFCACF
-%CACFCACFA093688C6892757551755175517551754BF827FD63FFF827FFCF
-%FFCFCFCFFFCFFF998C8C926E7C7576517C7576517CA7A1F852FD06FFA87D
-%527DA8FD58FFF827CFCFCACFCACFCAFFCF996892686F5175517551755175
-%7CFF7CF827FD05FF7D2752A82727A8FD57FFF827FFCFFFCFFFCFFFC2BB8C
-%928C8C6E7C757C517C757C51CFFFA1F852FD05FF2752FFFFFF52FD58FFF8
-%27CFCFCACFCACFCF99688C68928C6F5175517551755175CAFF7CF827FD04
-%FFA8F852FD5CFFF827FFCFCFCFFFCFFFA0998C928C926E7C517C7576517C
-%51CACFA1F852FD04FFA827F87DFFFFFFA8527DFD04FF527DFFFFA87D52A8
-%FF7D527D527D527D7DFF7D7D527D527DFFFFFFA8FD06FFA8FD04FFA87D7D
-%7DFD26FFF827CFCFCACFCACFCACFCF99688C6893517551755175517575FF
-%7CF827FD05FF52F8F852FFFFFF52F8A8FFFF7D27A8FF5252A8A852A852A8
-%7DF827A87D7DFFA8F852A87D52FFFFFFF8A8FD04FF5227FFFFFF7D27A8A8
-%52A8FD25FFF827FFCFFFCFFFCFFFCFFFA08C8C92927C517C757C517C7575
-%7C7CF852FD06FF52F8F852FFFFFF27F8FFFF52A8FFFFF87DFD07FFF87DFD
-%05FFF852FD06FFF827FD04FF2727FFFFFF2752FD29FFF827CFCFCACFCACF
-%CACFA799688C68927575517551755175517526F84BFD07FF52F8F87DFFFF
-%A8F87D7D52FFFFFFF8F87DFD05FFA8F852FD05FFF87DFD05FFA8F8F8A8FF
-%FF7DF8F8A8FFFF52F852A8FD27FFF827FFCFFFCFCFCFFFCF9368928C928C
-%995176517C7576517C7551F852FD08FF7DF8F8FFFFFF52F827FD05FFF8F8
-%27FD05FFF87DFD05FFF8277D527DFFFF7D52F852FFFF277DF8A8FFFFFF52
-%F8F87DFD26FFF827CFCFCACFCACFCAFF938C688C688C6875517551755175
-%517C26F827FD09FF27F8A8FFFFFFF852FD06FF52F827FFFFFFA8F852FD05
-%FFF852A8A87DFFFF527D7DF8FF7D52A8F87DFD04FF7DF8F8A8FD25FFF827
-%FFCFFFCFFFCFFFCFCFCFC98C928C92927C517C757C517C7551F852FD04FF
-%7DFD04FF7DF8FD04FFF852FD07FF7DF8A8FFFFFFF87DFD05FFF852FD05FF
-%52A8FF272752A8FFF87DFD06FFF8A8FD25FFF827CFCFCACFCACFCAFD04CF
-%99688C688C6E7651755175517C4BF827FD04FF5227FFFFA8F852FD04FFF8
-%7DFFFFFF7D7DFFFF7D27FD04FFF852FD05FFF852FFFFA8FFFF27A8FF7DF8
-%52FFFFF852FFA852FFFF7D27A8FD25FFF827FFCFCFCFFFCFCFCFFFCFCF92
-%928C928C926E7C517C75767551F852FD04FF7D272752277DFD04FF7DF827
-%FFFFFF7D27525227FD04FFA8F852A8FFFFFF7D2727525252FFA8F8A8FFFF
-%52FFFFFF2727A8FF275252527DFD26FFF827CFCFCACFCACFCACFCAFF998C
-%688C688C688C68755176517526F827FD07FFA8FD07FFA8FFA8FFFFFFA8A8
-%A8FD05FFA8FFA8FD05FFA8FFA8A8A8FFA8FFA8FD07FFA8FFFFFFA8A8FD28
-%FFF827FFCFFFCFFFCFFFCFFFCFCF92C29A928C928C928C99757C7551F852
-%FD63FFF827CFCFCACFCACFCACFCAFD04CFFF998C68928C8C6892689344F8
-%27FD63FFF827FFCFFFCFCFCFFFCFCFCFFFCFCFCFC98C928C928C928C928C
-%68F852FD63FFF827CFCFCACFCACFCAA8537ECACFCAFF938C6899688C688C
-%689244F827FD63FFF827FFCFFFCFFFCFA8072F07FFCFFFCFCF992F0D5992
-%928C928C68F852FD08FF7D7D527D52A8A8FD54FFF827CFCFCACFCACFA70D
-%060753A87DA8CA5A0607069368929AC244F827FD06FF7DF8527D7D7D52F8
-%27FD54FFF827FFCFCFCFFFCFCF2F2F070D062F072F062F07539993C2FFFF
-%76F852FD05FF7DF87DFD06FF27FD54FFF827CFCFCACFCACF7D0D060D0607
-%060D0607060753FFCACFCAFF76F827FD04FFA8F827FD07FFA8A8FD15FFA8
-%FD3DFFF827FFCFFFCFFF592F062F072F2852282F072F072F7DFFCFFFCFA7
-%F852FD04FF52F87DFD0CFFA87D7D7DFD05FFA8FD05FF7D7DA8FFFFA87D7D
-%7DFFFFFFA87D527D7DFD04FFA8527D527DA8FFFF7D527D527D527D7DFF7D
-%7D7DFFFFA8527DA8FFFFA8527DFFFFFFA8FD06FFA8FFFFF827CF5959CA53
-%07060D066F688C6892684B060D06077DCFCFCF7CF827FD04FF27F8A8FD0A
-%FFA82752A87D52F852FFFFA8F87DFD04FF7D27FFFF7D27A87D52FFFF5227
-%7DA87D27F8A8FFFFA8F827A827F8A8A852A87DF827A87D7DFFA8F852FFFF
-%A8F827FD04FF2727FFFFFFF8A8FD04FF5227FFFFF827A9062F070D062F28
-%928C928C928C928C92282F072F847E5953F852FD04FFF8F8A8FD0AFF2752
-%FD04FF7DF87DFFFFF8F852FFFFFF7D52FFFFF8A8FFFFA8FF7DF8A8FD04FF
-%27F8FFFFFFF87DFFFFF87DFD04FFF87DFD05FFF852FFFFFFF87DFD04FF27
-%52FFFFFFF827FD04FF2727FFFFF8272F07060D060D278C688C68928C8C68
-%8C688C060D0607060D06F827FFFFFFA827F87DFD09FF7DF8FD06FF27F8FF
-%A85252F852FFFF7D27FFFF27F87DFFFFFF2727FD05FF7DF852FFA8F852FF
-%A8F87DFFFFFFA8F852FD05FFF852FFFFA8F852FD04FF5252FFFFA8F8F8A8
-%FFFF7DF827A8FFF827FF2F2F070D06938C928CBCC9CFC9BB8C928C6F070D
-%062F0706F852FD04FF27F852FD09FF52F8FD06FF52F8FFFF27FF52F852FF
-%7D52FFFFA827F827A8FFF852FD06FFF852FFFFF852FF7D7DFD05FFF87DFD
-%05FFF852FFFFFFF87DFD04FF2752FFFF7D52F852FFFF277DF8A8FFF827CF
-%CF2F0D064C689268C2CFFFCFFFCFC2688C682E0607062F52F827FD04FF7D
-%F8F8A8FD08FF52F8A8FD05FF52F8FFA827FFFF52F852A852FD04FF7DF827
-%FF2727FD05FFA8F852FFA8F82752F8A8FD04FFA8F852FD05FFF852FFFFA8
-%F852FD04FF5252FFFF7D7D7DF8FF7D52A8F87DFFF827FFCF59062F6F8C8C
-%99CFFFCFFFCFFFCF938C8C4B2F0759CFA7F852FD05FF52F827FD06FF7DFF
-%A8F852FD05FFF852FFA827FFFFFF52F8F87DFD05FF7DF8FF52F8A8FD04FF
-%A8F8A8FFFFF87DFF52F8FD05FFF87DFD05FFF852FFFFFFF852FD04FF277D
-%FFFF27A8FF272752FFFFF87DFFF827CFCF2F070693688C99FFCACFCACFCA
-%FF998C686F060759CF7CF827FD05FFA852F8F87DFFFFFF5227FFFF52F87D
-%FFFFFF5227A8FFA827FD04FF52F852FF527DFFFF5227FFFFF827A8FFFFFF
-%2752FFFFFFF852FFFF27F8FFFFFFA8F852FD05FFF87DFFFFFF52F8A8FFFF
-%7D27A8FFFF27A8FF7DF852FFFFF827FFF827FFCF53062F6E928CC2FFFFCF
-%FFCFFFCFC28C926F2F077ECFA7F852FD07FFA8FD06277DFFFFFF7D27277D
-%527DFFFFFF7DF8A8FD04FF527DFFA827525252A8FFFFFF5227527D52A8FF
-%FFFFA8F852A8FFA82727A8FFA8F852A8FFFFFF7DF827FD04FF52277D5252
-%A8FFFFA8F8A8FFFF52FFFFFF2727A8F827CFCF2F07066F8C8C92FFCFCFCA
-%CFCFCF8C8C8C4B060D59CF7CF827FD0BFFA8FD09FFA8FD05FFA8FFA8FD09
-%FFA8A8FD07FFA8A8FD05FFA8FFA8FD05FFA8FFA8FFA8FD05FFA8FFA8FD05
-%FFA8FD05FFA8FFA8FD07FFA8FFF827AF2F2F070D4B928C8CA0FFCFFFCFFF
-%998C8C92280D067ECFA1F852FD63FFF8270707060D0607688C688C99C9CA
-%C9938C688C680D0607065A76F827FD63FFF8275A062F070D07528C928C92
-%8C928C928C928C2F070D062F072EF852FD63FFF84B842F597E0607064C8C
-%8C68928C8C688C6828060D0607060D52F827FD63FFF827FFCFCFCF7E060D
-%062F6F928C928C934B2F070D0684A85A59A1F852FD63FFF827CFCFCACFCA
-%590607060D06282728060D0607067ECACFCFCF7CF827FD63FFF827FFCFFF
-%CFFFCF59062F070D072F070D062F2FA8CFFFCFFFCFA7F852FD63FFF827CF
-%CFCACFCACF2F07060D0607060D06070653CFCFCACFCAFF7CF827FD63FFF8
-%27FFCFFFCFCFA82F070D59CFA8A8A859060D07FD04CFFFCFA1F852FD63FF
-%F827CFCFCACFCFA82F0D2FCFCACFCFCFA80D060DA8CFCACFCAFF7CF827FD
-%63FFF827FFCFFFCFFFCFFFA8FFCFFFCFFFCFFF7E7EA8FFCFFFCFFFFFA7F8
-%52FD63FFFD09F820FD07F820FD07F820F8F827FD63FF27F827F820F827F8
-%20F827F820F827F820F827F820F827F820F827F87CFDE2FFFF
-%%EndData
-%%EndComments
-%%BeginDefaults
-%%ViewingOrientation: 1 0 0 1
-%%EndDefaults
-%%BeginProlog
-%%BeginResource: procset Adobe_AGM_Utils 1.0 0
-%%Version: 1.0 0
-%%Copyright: Copyright (C) 2000-2003 Adobe Systems, Inc.  All Rights Reserved.
-systemdict /setpacking known
-{
-	currentpacking
-	true setpacking
-} if
-userdict /Adobe_AGM_Utils 68 dict dup begin put
-/bdf
-{
-	bind def
-} bind def
-/nd{
-	null def
-}bdf
-/xdf
-{
-	exch def
-}bdf
-/ldf
-{
-	load def
-}bdf
-/ddf
-{
-	put
-}bdf	
-/xddf
-{
-	3 -1 roll put
-}bdf	
-/xpt
-{
-	exch put
-}bdf
-/ndf
-{
-	exch dup where{
-		pop pop pop
-	}{
-		xdf
-	}ifelse
-}def
-/cdndf
-{
-	exch dup currentdict exch known{
-		pop pop
-	}{
-		exch def
-	}ifelse
-}def
-/bdict
-{
-	mark
-}bdf
-/edict
-{
-	counttomark 2 idiv dup dict begin {def} repeat pop currentdict end
-}def
-/ps_level
-	/languagelevel where{
-		pop systemdict /languagelevel get exec
-	}{
-		1
-	}ifelse
-def
-/level2
-	ps_level 2 ge
-def
-/level3
-	ps_level 3 ge
-def
-/ps_version
-	{version cvr} stopped {
-		-1
-	}if
-def
-/makereadonlyarray
-{
-	/packedarray where{
-		pop packedarray
-	}{
-		array astore readonly
-	}ifelse
-}bdf
-/map_reserved_ink_name
-{
-	dup type /stringtype eq{
-		dup /Red eq{
-			pop (_Red_)
-		}{
-			dup /Green eq{
-				pop (_Green_)
-			}{
-				dup /Blue eq{
-					pop (_Blue_)
-				}{
-					dup () cvn eq{
-						pop (Process)
-					}if
-				}ifelse
-			}ifelse
-		}ifelse
-	}if
-}bdf
-/AGMUTIL_GSTATE 22 dict def
-/get_gstate
-{
-	AGMUTIL_GSTATE begin
-	/AGMUTIL_GSTATE_clr_spc currentcolorspace def
-	/AGMUTIL_GSTATE_clr_indx 0 def
-	/AGMUTIL_GSTATE_clr_comps 12 array def
-	mark currentcolor counttomark
-		{AGMUTIL_GSTATE_clr_comps AGMUTIL_GSTATE_clr_indx 3 -1 roll put
-		/AGMUTIL_GSTATE_clr_indx AGMUTIL_GSTATE_clr_indx 1 add def} repeat pop
-	/AGMUTIL_GSTATE_fnt rootfont def
-	/AGMUTIL_GSTATE_lw currentlinewidth def
-	/AGMUTIL_GSTATE_lc currentlinecap def
-	/AGMUTIL_GSTATE_lj currentlinejoin def
-	/AGMUTIL_GSTATE_ml currentmiterlimit def
-	currentdash /AGMUTIL_GSTATE_do xdf /AGMUTIL_GSTATE_da xdf
-	/AGMUTIL_GSTATE_sa currentstrokeadjust def
-	/AGMUTIL_GSTATE_clr_rnd currentcolorrendering def
-	/AGMUTIL_GSTATE_op currentoverprint def
-	/AGMUTIL_GSTATE_bg currentblackgeneration cvlit def
-	/AGMUTIL_GSTATE_ucr currentundercolorremoval cvlit def
-	currentcolortransfer cvlit /AGMUTIL_GSTATE_gy_xfer xdf cvlit /AGMUTIL_GSTATE_b_xfer xdf
-		cvlit /AGMUTIL_GSTATE_g_xfer xdf cvlit /AGMUTIL_GSTATE_r_xfer xdf
-	/AGMUTIL_GSTATE_ht currenthalftone def
-	/AGMUTIL_GSTATE_flt currentflat def
-	end
-}def
-/set_gstate
-{
-	AGMUTIL_GSTATE begin
-	AGMUTIL_GSTATE_clr_spc setcolorspace
-	AGMUTIL_GSTATE_clr_indx {AGMUTIL_GSTATE_clr_comps AGMUTIL_GSTATE_clr_indx 1 sub get
-	/AGMUTIL_GSTATE_clr_indx AGMUTIL_GSTATE_clr_indx 1 sub def} repeat setcolor
-	AGMUTIL_GSTATE_fnt setfont
-	AGMUTIL_GSTATE_lw setlinewidth
-	AGMUTIL_GSTATE_lc setlinecap
-	AGMUTIL_GSTATE_lj setlinejoin
-	AGMUTIL_GSTATE_ml setmiterlimit
-	AGMUTIL_GSTATE_da AGMUTIL_GSTATE_do setdash
-	AGMUTIL_GSTATE_sa setstrokeadjust
-	AGMUTIL_GSTATE_clr_rnd setcolorrendering
-	AGMUTIL_GSTATE_op setoverprint
-	AGMUTIL_GSTATE_bg cvx setblackgeneration
-	AGMUTIL_GSTATE_ucr cvx setundercolorremoval
-	AGMUTIL_GSTATE_r_xfer cvx AGMUTIL_GSTATE_g_xfer cvx AGMUTIL_GSTATE_b_xfer cvx
-		AGMUTIL_GSTATE_gy_xfer cvx setcolortransfer
-	AGMUTIL_GSTATE_ht /HalftoneType get dup 9 eq exch 100 eq or
-		{
-		currenthalftone /HalftoneType get AGMUTIL_GSTATE_ht /HalftoneType get ne
-			{
-			  mark AGMUTIL_GSTATE_ht {sethalftone} stopped cleartomark
-			} if
-		}{
-		AGMUTIL_GSTATE_ht sethalftone
-		} ifelse
-	AGMUTIL_GSTATE_flt setflat
-	end
-}def
-/get_gstate_and_matrix
-{
-	AGMUTIL_GSTATE begin
-	/AGMUTIL_GSTATE_ctm matrix currentmatrix def
-	end
-	get_gstate
-}def
-/set_gstate_and_matrix
-{
-	set_gstate
-	AGMUTIL_GSTATE begin
-	AGMUTIL_GSTATE_ctm setmatrix
-	end
-}def
-/AGMUTIL_str256 256 string def
-/AGMUTIL_src256 256 string def
-/AGMUTIL_dst64 64 string def
-/AGMUTIL_srcLen nd
-/AGMUTIL_ndx nd
-/agm_sethalftone
-{
-	dup
-	begin
-		/_Data load
-		/Thresholds xdf
-	end
-	level3
-	{ sethalftone }{
-		dup /HalftoneType get 3 eq {
-			sethalftone
-		} {pop} ifelse
-	}ifelse
-} def
-/rdcmntline
-{
-	currentfile AGMUTIL_str256 readline pop
-	(%) anchorsearch {pop} if
-} bdf
-/filter_cmyk
-{	
-	dup type /filetype ne{
-		exch () /SubFileDecode filter
-	}
-	{
-		exch pop
-	}
-	ifelse
-	[
-	exch
-	{
-		AGMUTIL_src256 readstring pop
-		dup length /AGMUTIL_srcLen exch def
-		/AGMUTIL_ndx 0 def
-		AGMCORE_plate_ndx 4 AGMUTIL_srcLen 1 sub{
-			1 index exch get
-			AGMUTIL_dst64 AGMUTIL_ndx 3 -1 roll put
-			/AGMUTIL_ndx AGMUTIL_ndx 1 add def
-		}for
-		pop
-		AGMUTIL_dst64 0 AGMUTIL_ndx getinterval
-	}
-	bind
-	/exec cvx
-	] cvx
-} bdf
-/filter_indexed_devn
-{
-	cvi Names length mul names_index add Lookup exch get
-} bdf
-/filter_devn
-{	
-	4 dict begin
-	/srcStr xdf
-	/dstStr xdf
-	dup type /filetype ne{
-		0 () /SubFileDecode filter
-	}if
-	[
-	exch
-		[
-			/devicen_colorspace_dict /AGMCORE_gget cvx /begin cvx
-			currentdict /srcStr get /readstring cvx /pop cvx
-			/dup cvx /length cvx 0 /gt cvx [
-				Adobe_AGM_Utils /AGMUTIL_ndx 0 /ddf cvx
-				names_index Names length currentdict /srcStr get length 1 sub {
-					1 /index cvx /exch cvx /get cvx
-					currentdict /dstStr get /AGMUTIL_ndx /load cvx 3 -1 /roll cvx /put cvx
-					Adobe_AGM_Utils /AGMUTIL_ndx /AGMUTIL_ndx /load cvx 1 /add cvx /ddf cvx
-				} for
-				currentdict /dstStr get 0 /AGMUTIL_ndx /load cvx /getinterval cvx
-			] cvx /if cvx
-			/end cvx
-		] cvx
-		bind
-		/exec cvx
-	] cvx
-	end
-} bdf
-/AGMUTIL_imagefile nd
-/read_image_file
-{
-	AGMUTIL_imagefile 0 setfileposition
-	10 dict begin
-	/imageDict xdf
-	/imbufLen Width BitsPerComponent mul 7 add 8 idiv def
-	/imbufIdx 0 def
-	/origDataSource imageDict /DataSource get def
-	/origMultipleDataSources imageDict /MultipleDataSources get def
-	/origDecode imageDict /Decode get def
-	/dstDataStr imageDict /Width get colorSpaceElemCnt mul string def
-	/srcDataStrs [ imageDict begin
-		currentdict /MultipleDataSources known {MultipleDataSources {DataSource length}{1}ifelse}{1} ifelse
-		{
-			Width Decode length 2 div mul cvi string
-		} repeat
-		end ] def
-	imageDict /MultipleDataSources known {MultipleDataSources}{false} ifelse
-	{
-		/imbufCnt imageDict /DataSource get length def
-		/imbufs imbufCnt array def
-		0 1 imbufCnt 1 sub {
-			/imbufIdx xdf
-			imbufs imbufIdx imbufLen string put
-			imageDict /DataSource get imbufIdx [ AGMUTIL_imagefile imbufs imbufIdx get /readstring cvx /pop cvx ] cvx put
-		} for
-		DeviceN_PS2 {
-			imageDict begin
-		 	/DataSource [ DataSource /devn_sep_datasource cvx ] cvx def
-			/MultipleDataSources false def
-			/Decode [0 1] def
-			end
-		} if
-	}{
-		/imbuf imbufLen string def
-		Indexed_DeviceN level3 not and DeviceN_NoneName or {
-			imageDict begin
-		 	/DataSource [AGMUTIL_imagefile Decode BitsPerComponent false 1 /filter_indexed_devn load dstDataStr srcDataStrs devn_alt_datasource /exec cvx] cvx def
-			/Decode [0 1] def
-			end
-		}{
-			imageDict /DataSource {AGMUTIL_imagefile imbuf readstring pop} put
-		} ifelse
-	} ifelse
-	imageDict exch
-	load exec
-	imageDict /DataSource origDataSource put
-	imageDict /MultipleDataSources origMultipleDataSources put
-	imageDict /Decode origDecode put	
-	end
-} bdf
-/write_image_file
-{
-	begin
-	{ (AGMUTIL_imagefile) (w+) file } stopped{
-		false
-	}{
-		Adobe_AGM_Utils/AGMUTIL_imagefile xddf
-		2 dict begin
-		/imbufLen Width BitsPerComponent mul 7 add 8 idiv def
-		MultipleDataSources {DataSource 0 get}{DataSource}ifelse type /filetype eq {
-			/imbuf imbufLen string def
-		}if
-		1 1 Height {
-			pop
-			MultipleDataSources {
-			 	0 1 DataSource length 1 sub {
-					DataSource type dup
-					/arraytype eq {
-						pop DataSource exch get exec
-					}{
-						/filetype eq {
-							DataSource exch get imbuf readstring pop
-						}{
-							DataSource exch get
-						} ifelse
-					} ifelse
-					AGMUTIL_imagefile exch writestring
-				} for
-			}{
-				DataSource type dup
-				/arraytype eq {
-					pop DataSource exec
-				}{
-					/filetype eq {
-						DataSource imbuf readstring pop
-					}{
-						DataSource
-					} ifelse
-				} ifelse
-				AGMUTIL_imagefile exch writestring
-			} ifelse
-		}for
-		end
-		true
-	}ifelse
-	end
-} bdf
-/close_image_file
-{
-	AGMUTIL_imagefile closefile (AGMUTIL_imagefile) deletefile
-}def
-statusdict /product known userdict /AGMP_current_show known not and{
-	/pstr statusdict /product get def
-	pstr (HP LaserJet 2200) eq 	
-	pstr (HP LaserJet 4000 Series) eq or
-	pstr (HP LaserJet 4050 Series ) eq or
-	pstr (HP LaserJet 8000 Series) eq or
-	pstr (HP LaserJet 8100 Series) eq or
-	pstr (HP LaserJet 8150 Series) eq or
-	pstr (HP LaserJet 5000 Series) eq or
-	pstr (HP LaserJet 5100 Series) eq or
-	pstr (HP Color LaserJet 4500) eq or
-	pstr (HP Color LaserJet 4600) eq or
-	pstr (HP LaserJet 5Si) eq or
-	pstr (HP LaserJet 1200 Series) eq or
-	pstr (HP LaserJet 1300 Series) eq or
-	pstr (HP LaserJet 4100 Series) eq or
-	{
- 		userdict /AGMP_current_show /show load put
-		userdict /show {
-		  currentcolorspace 0 get
-		  /Pattern eq
-		  {false charpath f}
-		  {AGMP_current_show} ifelse
-		} put
-	}if
-	currentdict /pstr undef
-} if
-/consumeimagedata
-{
-	begin
-	currentdict /MultipleDataSources known not
-		{/MultipleDataSources false def} if
-	MultipleDataSources
-		{
-		1 dict begin
-		/flushbuffer Width cvi string def
-		1 1 Height cvi
-			{
-			pop
-			0 1 DataSource length 1 sub
-				{
-				DataSource exch get
-				dup type dup
-				/filetype eq
-					{
-					exch flushbuffer readstring pop pop
-					}if
-				/arraytype eq
-					{
-					exec pop
-					}if
-				}for
-			}for
-		end
-		}
-		{
-		/DataSource load type dup
-		/filetype eq
-			{
-			1 dict begin
-			/flushbuffer Width Decode length 2 div mul cvi string def
-			1 1 Height { pop DataSource flushbuffer readstring pop pop} for
-			end
-			}if
-		/arraytype eq
-			{
-			1 1 Height { pop DataSource pop } for
-			}if
-		}ifelse
-	end
-}bdf
-/addprocs
-{
-	  2{/exec load}repeat
-	  3 1 roll
-	  [ 5 1 roll ] bind cvx
-}def
-/modify_halftone_xfer
-{
-	currenthalftone dup length dict copy begin
-	 currentdict 2 index known{
-	 	1 index load dup length dict copy begin
-		currentdict/TransferFunction known{
-			/TransferFunction load
-		}{
-			currenttransfer
-		}ifelse
-		 addprocs /TransferFunction xdf
-		 currentdict end def
-		currentdict end sethalftone
-	}{
-		currentdict/TransferFunction known{
-			/TransferFunction load
-		}{
-			currenttransfer
-		}ifelse
-		addprocs /TransferFunction xdf
-		currentdict end sethalftone		
-		pop
-	}ifelse
-}def
-/clonearray
-{
-	dup xcheck exch
-	dup length array exch
-	Adobe_AGM_Core/AGMCORE_tmp -1 ddf
-	{
-	Adobe_AGM_Core/AGMCORE_tmp AGMCORE_tmp 1 add ddf
-	dup type /dicttype eq
-		{
-			AGMCORE_tmp
-			exch
-			clonedict
-			Adobe_AGM_Core/AGMCORE_tmp 4 -1 roll ddf
-		} if
-	dup type /arraytype eq
-		{
-			AGMCORE_tmp exch
-			clonearray
-			Adobe_AGM_Core/AGMCORE_tmp 4 -1 roll ddf
-		} if
-	exch dup
-	AGMCORE_tmp 4 -1 roll put
-	}forall
-	exch {cvx} if
-}bdf
-/clonedict
-{
-	dup length dict
-	begin
-		{
-		dup type /dicttype eq
-			{
-				clonedict
-			} if
-		dup type /arraytype eq
-			{
-				clonearray
-			} if
-		def
-		}forall
-	currentdict
-	end
-}bdf
-/DeviceN_PS2
-{
-	/currentcolorspace AGMCORE_gget 0 get /DeviceN eq level3 not and
-} bdf
-/Indexed_DeviceN
-{
-	/indexed_colorspace_dict AGMCORE_gget dup null ne {
-		/CSD known
-	}{
-		pop false
-	} ifelse
-} bdf
-/DeviceN_NoneName
-{	
-	/Names where {
-		pop
-		false Names
-		{
-			(None) eq or
-		} forall
-	}{
-		false
-	}ifelse
-} bdf
-/DeviceN_PS2_inRip_seps
-{
-	/AGMCORE_in_rip_sep where
-	{
-		pop dup type dup /arraytype eq exch /packedarraytype eq or
-		{
-			dup 0 get /DeviceN eq level3 not and AGMCORE_in_rip_sep and
-			{
-				/currentcolorspace exch AGMCORE_gput
-				false
-			}
-			{
-				true
-			}ifelse
-		}
-		{
-			true
-		} ifelse
-	}
-	{
-		true
-	} ifelse
-} bdf
-/base_colorspace_type
-{
-	dup type /arraytype eq {0 get} if
-} bdf
-/doc_setup{
-	Adobe_AGM_Utils begin
-}bdf
-/doc_trailer{
-	currentdict Adobe_AGM_Utils eq{
-		end
-	}if
-}bdf
-systemdict /setpacking known
-{
-	setpacking
-} if
-%%EndResource
-%%BeginResource: procset Adobe_AGM_Core 2.0 0
-%%Version: 2.0 0
-%%Copyright: Copyright (C) 1997-2003 Adobe Systems, Inc.  All Rights Reserved.
-systemdict /setpacking known
-{
-	currentpacking
-	true setpacking
-} if
-userdict /Adobe_AGM_Core 216 dict dup begin put
-/nd{
-	null def
-}bind def
-/Adobe_AGM_Core_Id /Adobe_AGM_Core_2.0_0 def
-/AGMCORE_str256 256 string def
-/AGMCORE_save nd
-/AGMCORE_graphicsave nd
-/AGMCORE_c 0 def
-/AGMCORE_m 0 def
-/AGMCORE_y 0 def
-/AGMCORE_k 0 def
-/AGMCORE_cmykbuf 4 array def
-/AGMCORE_screen [currentscreen] cvx def
-/AGMCORE_tmp 0 def
-/AGMCORE_&setgray nd
-/AGMCORE_&setcolor nd
-/AGMCORE_&setcolorspace nd
-/AGMCORE_&setcmykcolor nd
-/AGMCORE_cyan_plate nd
-/AGMCORE_magenta_plate nd
-/AGMCORE_yellow_plate nd
-/AGMCORE_black_plate nd
-/AGMCORE_plate_ndx nd
-/AGMCORE_get_ink_data nd
-/AGMCORE_is_cmyk_sep nd
-/AGMCORE_host_sep nd
-/AGMCORE_avoid_L2_sep_space nd
-/AGMCORE_distilling nd
-/AGMCORE_composite_job nd
-/AGMCORE_producing_seps nd
-/AGMCORE_ps_level -1 def
-/AGMCORE_ps_version -1 def
-/AGMCORE_environ_ok nd
-/AGMCORE_CSA_cache 0 dict def
-/AGMCORE_CSD_cache 0 dict def
-/AGMCORE_pattern_cache 0 dict def
-/AGMCORE_currentoverprint false def
-/AGMCORE_deltaX nd
-/AGMCORE_deltaY nd
-/AGMCORE_name nd
-/AGMCORE_sep_special nd
-/AGMCORE_err_strings 4 dict def
-/AGMCORE_cur_err nd
-/AGMCORE_ovp nd
-/AGMCORE_current_spot_alias false def
-/AGMCORE_inverting false def
-/AGMCORE_feature_dictCount nd
-/AGMCORE_feature_opCount nd
-/AGMCORE_feature_ctm nd
-/AGMCORE_ConvertToProcess false def
-/AGMCORE_Default_CTM matrix def
-/AGMCORE_Default_PageSize nd
-/AGMCORE_currentbg nd
-/AGMCORE_currentucr nd
-/AGMCORE_gradientcache 32 dict def
-/AGMCORE_in_pattern false def
-/knockout_unitsq nd
-/AGMCORE_CRD_cache where{
-	pop
-}{
-	/AGMCORE_CRD_cache 0 dict def
-}ifelse
-/AGMCORE_key_known
-{
-	where{
-		/Adobe_AGM_Core_Id known
-	}{
-		false
-	}ifelse
-}ndf
-/flushinput
-{
-	save
-	2 dict begin
-	/CompareBuffer 3 -1 roll def
-	/readbuffer 256 string def
-	mark
-	{
-	currentfile readbuffer {readline} stopped
-		{cleartomark mark}
-		{
-		not
-			{pop exit}
-		if
-		CompareBuffer eq
-			{exit}
-		if
-		}ifelse
-	}loop
-	cleartomark
-	end
-	restore
-}bdf
-/getspotfunction
-{
-	AGMCORE_screen exch pop exch pop
-	dup type /dicttype eq{
-		dup /HalftoneType get 1 eq{
-			/SpotFunction get
-		}{
-			dup /HalftoneType get 2 eq{
-				/GraySpotFunction get
-			}{
-				pop
-				{
-					abs exch abs 2 copy add 1 gt{
-						1 sub dup mul exch 1 sub dup mul add 1 sub
-					}{
-						dup mul exch dup mul add 1 exch sub
-					}ifelse
-				}bind
-			}ifelse
-		}ifelse
-	}if
-} def
-/clp_npth
-{
-	clip newpath
-} def
-/eoclp_npth
-{
-	eoclip newpath
-} def
-/npth_clp
-{
-	newpath clip
-} def
-/add_grad
-{
-	AGMCORE_gradientcache 3 1 roll put
-}bdf
-/exec_grad
-{
-	AGMCORE_gradientcache exch get exec
-}bdf
-/graphic_setup
-{
-	/AGMCORE_graphicsave save def
-	concat
-	0 setgray
-	0 setlinecap
-	0 setlinejoin
-	1 setlinewidth
-	[] 0 setdash
-	10 setmiterlimit
-	newpath
-	false setoverprint
-	false setstrokeadjust
-	Adobe_AGM_Core/spot_alias get exec
-	/Adobe_AGM_Image where {
-		pop
-		Adobe_AGM_Image/spot_alias 2 copy known{
-			get exec
-		}{
-			pop pop
-		}ifelse
-	} if
-	100 dict begin
-	/dictstackcount countdictstack def
-	/showpage {} def
-	mark
-} def
-/graphic_cleanup
-{
-	cleartomark
-	dictstackcount 1 countdictstack 1 sub {end}for
-	end
-	AGMCORE_graphicsave restore
-} def
-/compose_error_msg
-{
-	grestoreall initgraphics	
-	/Helvetica findfont 10 scalefont setfont
-	/AGMCORE_deltaY 100 def
-	/AGMCORE_deltaX 310 def
-	clippath pathbbox newpath pop pop 36 add exch 36 add exch moveto
-	0 AGMCORE_deltaY rlineto AGMCORE_deltaX 0 rlineto
-	0 AGMCORE_deltaY neg rlineto AGMCORE_deltaX neg 0 rlineto closepath
-	0 AGMCORE_&setgray
-	gsave 1 AGMCORE_&setgray fill grestore
-	1 setlinewidth gsave stroke grestore
-	currentpoint AGMCORE_deltaY 15 sub add exch 8 add exch moveto
-	/AGMCORE_deltaY 12 def
-	/AGMCORE_tmp 0 def
-	AGMCORE_err_strings exch get
-		{
-		dup 32 eq
-			{
-			pop
-			AGMCORE_str256 0 AGMCORE_tmp getinterval
-			stringwidth pop currentpoint pop add AGMCORE_deltaX 28 add gt
-				{
-				currentpoint AGMCORE_deltaY sub exch pop
-				clippath pathbbox pop pop pop 44 add exch moveto
-				} if
-			AGMCORE_str256 0 AGMCORE_tmp getinterval show ( ) show
-			0 1 AGMCORE_str256 length 1 sub
-				{
-				AGMCORE_str256 exch 0 put
-				}for
-			/AGMCORE_tmp 0 def
-			}
-			{
-				AGMCORE_str256 exch AGMCORE_tmp xpt
-				/AGMCORE_tmp AGMCORE_tmp 1 add def
-			} ifelse
-		} forall
-} bdf
-/doc_setup{
-	Adobe_AGM_Core begin
-	/AGMCORE_ps_version xdf
-	/AGMCORE_ps_level xdf
-	errordict /AGM_handleerror known not{
-		errordict /AGM_handleerror errordict /handleerror get put
-		errordict /handleerror {
-			Adobe_AGM_Core begin
-			$error /newerror get AGMCORE_cur_err null ne and{
-				$error /newerror false put
-				AGMCORE_cur_err compose_error_msg
-			}if
-			$error /newerror true put
-			end
-			errordict /AGM_handleerror get exec
-			} bind put
-		}if
-	/AGMCORE_environ_ok
-		ps_level AGMCORE_ps_level ge
-		ps_version AGMCORE_ps_version ge and
-		AGMCORE_ps_level -1 eq or
-	def
-	AGMCORE_environ_ok not
-		{/AGMCORE_cur_err /AGMCORE_bad_environ def} if
-	/AGMCORE_&setgray systemdict/setgray get def
-	level2{
-		/AGMCORE_&setcolor systemdict/setcolor get def
-		/AGMCORE_&setcolorspace systemdict/setcolorspace get def
-	}if
-	/AGMCORE_currentbg currentblackgeneration def
-	/AGMCORE_currentucr currentundercolorremoval def
-	/AGMCORE_distilling
-		/product where{
-			pop systemdict/setdistillerparams known product (Adobe PostScript Parser) ne and
-		}{
-			false
-		}ifelse
-	def
-	level2 not{
-		/xput{
-			dup load dup length exch maxlength eq{
-				dup dup load dup
-				length dup 0 eq {pop 1} if 2 mul dict copy def
-			}if
-			load begin
-				def
- 			end
-		}def
-	}{
-		/xput{
-			load 3 1 roll put
-		}def
-	}ifelse
-	/AGMCORE_GSTATE AGMCORE_key_known not{
-		/AGMCORE_GSTATE 21 dict def
-		/AGMCORE_tmpmatrix matrix def
-		/AGMCORE_gstack 32 array def
-		/AGMCORE_gstackptr 0 def
-		/AGMCORE_gstacksaveptr 0 def
-		/AGMCORE_gstackframekeys 10 def
-		/AGMCORE_&gsave /gsave ldf
-		/AGMCORE_&grestore /grestore ldf
-		/AGMCORE_&grestoreall /grestoreall ldf
-		/AGMCORE_&save /save ldf
-		/AGMCORE_gdictcopy {
-			begin
-			{ def } forall
-			end
-		}def
-		/AGMCORE_gput {
-			AGMCORE_gstack AGMCORE_gstackptr get
-			3 1 roll
-			put
-		}def
-		/AGMCORE_gget {
-			AGMCORE_gstack AGMCORE_gstackptr get
-			exch
-			get
-		}def
-		/gsave {
-			AGMCORE_&gsave
-			AGMCORE_gstack AGMCORE_gstackptr get
-			AGMCORE_gstackptr 1 add
-			dup 32 ge {limitcheck} if
-			Adobe_AGM_Core exch
-			/AGMCORE_gstackptr xpt
-			AGMCORE_gstack AGMCORE_gstackptr get
-			AGMCORE_gdictcopy
-		}def
-		/grestore {
-			AGMCORE_&grestore
-			AGMCORE_gstackptr 1 sub
-			dup AGMCORE_gstacksaveptr lt {1 add} if
-			Adobe_AGM_Core exch
-			/AGMCORE_gstackptr xpt
-		}def
-		/grestoreall {
-			AGMCORE_&grestoreall
-			Adobe_AGM_Core
-			/AGMCORE_gstackptr AGMCORE_gstacksaveptr put
-		}def
-		/save {
-			AGMCORE_&save
-			AGMCORE_gstack AGMCORE_gstackptr get
-			AGMCORE_gstackptr 1 add
-			dup 32 ge {limitcheck} if
-			Adobe_AGM_Core begin
-				/AGMCORE_gstackptr exch def
-				/AGMCORE_gstacksaveptr AGMCORE_gstackptr def
-			end
-			AGMCORE_gstack AGMCORE_gstackptr get
-			AGMCORE_gdictcopy
-		}def
-		0 1 AGMCORE_gstack length 1 sub {
-				AGMCORE_gstack exch AGMCORE_gstackframekeys dict put
-		} for
-	}if
-	level3 /AGMCORE_&sysshfill AGMCORE_key_known not and
-	{
-		/AGMCORE_&sysshfill systemdict/shfill get def
-		/AGMCORE_&usrshfill /shfill load def
-		/AGMCORE_&sysmakepattern systemdict/makepattern get def
-		/AGMCORE_&usrmakepattern /makepattern load def
-	}if
-	/currentcmykcolor [0 0 0 0] AGMCORE_gput
-	/currentstrokeadjust false AGMCORE_gput
-	/currentcolorspace [/DeviceGray] AGMCORE_gput
-	/sep_tint 0 AGMCORE_gput
-	/devicen_tints [0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0] AGMCORE_gput
-	/sep_colorspace_dict null AGMCORE_gput
-	/devicen_colorspace_dict null AGMCORE_gput
-	/indexed_colorspace_dict null AGMCORE_gput
-	/currentcolor_intent () AGMCORE_gput
-	/customcolor_tint 1 AGMCORE_gput
-	<<
-	/MaxPatternItem currentsystemparams /MaxPatternCache get
-	>>
-	setuserparams
-	end
-}def
-/page_setup
-{
-	/setcmykcolor where{
-		pop
-		Adobe_AGM_Core/AGMCORE_&setcmykcolor /setcmykcolor load put
-	}if
-	Adobe_AGM_Core begin
-	/setcmykcolor
-	{
-		4 copy AGMCORE_cmykbuf astore /currentcmykcolor exch AGMCORE_gput
-		1 sub 4 1 roll
-		3 {
-			3 index add neg dup 0 lt {
-				pop 0
-			} if
-			3 1 roll
-		} repeat
-		setrgbcolor pop
-	}ndf
-	/currentcmykcolor
-	{
-		/currentcmykcolor AGMCORE_gget aload pop
-	}ndf
-	/setoverprint
-	{
-		pop
-	}ndf
-	/currentoverprint
-	{
-		false
-	}ndf
-	/AGMCORE_deviceDPI 72 0 matrix defaultmatrix dtransform dup mul exch dup mul add sqrt def
-	/AGMCORE_cyan_plate 1 0 0 0 test_cmyk_color_plate def
-	/AGMCORE_magenta_plate 0 1 0 0 test_cmyk_color_plate def
-	/AGMCORE_yellow_plate 0 0 1 0 test_cmyk_color_plate def
-	/AGMCORE_black_plate 0 0 0 1 test_cmyk_color_plate def
-	/AGMCORE_plate_ndx
-		AGMCORE_cyan_plate{
-			0
-		}{
-			AGMCORE_magenta_plate{
-				1
-			}{
-				AGMCORE_yellow_plate{
-					2
-				}{
-					AGMCORE_black_plate{
-						3
-					}{
-						4
-					}ifelse
-				}ifelse
-			}ifelse
-		}ifelse
-		def
-	/AGMCORE_have_reported_unsupported_color_space false def
-	/AGMCORE_report_unsupported_color_space
-	{
-		AGMCORE_have_reported_unsupported_color_space false eq
-		{
-			(Warning: Job contains content that cannot be separated with on-host methods. This content appears on the black plate, and knocks out all other plates.) ==
-			Adobe_AGM_Core /AGMCORE_have_reported_unsupported_color_space true ddf
-		} if
-	}def
-	/AGMCORE_composite_job
-		AGMCORE_cyan_plate AGMCORE_magenta_plate and AGMCORE_yellow_plate and AGMCORE_black_plate and def
-	/AGMCORE_in_rip_sep
-		/AGMCORE_in_rip_sep where{
-			pop AGMCORE_in_rip_sep
-		}{
-			AGMCORE_distilling
-			{
-				false
-			}{
-				userdict/Adobe_AGM_OnHost_Seps known{
-					false
-				}{
-					level2{
-						currentpagedevice/Separations 2 copy known{
-							get
-						}{
-							pop pop false
-						}ifelse
-					}{
-						false
-					}ifelse
-				}ifelse
-			}ifelse
-		}ifelse
-	def
-	/AGMCORE_producing_seps AGMCORE_composite_job not AGMCORE_in_rip_sep or def
-	/AGMCORE_host_sep AGMCORE_producing_seps AGMCORE_in_rip_sep not and def
-	/AGM_preserve_spots
-		/AGM_preserve_spots where{
-			pop AGM_preserve_spots
-		}{
-			AGMCORE_distilling AGMCORE_producing_seps or
-		}ifelse
-	def
-	/AGM_is_distiller_preserving_spotimages
-	{
-		currentdistillerparams/PreserveOverprintSettings known
-		{
-			currentdistillerparams/PreserveOverprintSettings get
-				{
-					currentdistillerparams/ColorConversionStrategy known
-					{
-						currentdistillerparams/ColorConversionStrategy get
-						/LeaveColorUnchanged eq
-					}{
-						true
-					}ifelse
-				}{
-					false
-				}ifelse
-		}{
-			false
-		}ifelse
-	}def
-	/convert_spot_to_process where {pop}{
-		/convert_spot_to_process
-		{
-			dup map_alias {
-				/Name get exch pop
-			} if
-			dup dup (None) eq exch (All) eq or
-				{
-				pop false
-				}{
-				AGMCORE_host_sep
-				{
-					gsave
-					1 0 0 0 setcmykcolor currentgray 1 exch sub
-					0 1 0 0 setcmykcolor currentgray 1 exch sub
-					0 0 1 0 setcmykcolor currentgray 1 exch sub
-					0 0 0 1 setcmykcolor currentgray 1 exch sub
-					add add add 0 eq
-					{
-						pop false
-					}{
-						false setoverprint
-						1 1 1 1 5 -1 roll findcmykcustomcolor 1 setcustomcolor
-						currentgray 0 eq
-					}ifelse
-					grestore
-				}{
-					AGMCORE_distilling
-					{
-						pop AGM_is_distiller_preserving_spotimages not
-					}{
-						Adobe_AGM_Core/AGMCORE_name xddf
-						false
-						Adobe_AGM_Core/AGMCORE_in_pattern known {Adobe_AGM_Core/AGMCORE_in_pattern get}{false} ifelse
-						not currentpagedevice/OverrideSeparations known and
-							{
-							currentpagedevice/OverrideSeparations get
-								{
-								/HqnSpots /ProcSet resourcestatus
-									{
-									pop pop pop true
-									}if
-								}if
-							}if					
-							{
-							AGMCORE_name /HqnSpots /ProcSet findresource /TestSpot get exec not
-							}{
-							gsave
-							[/Separation AGMCORE_name /DeviceGray {}]setcolorspace
-							false
-							currentpagedevice/SeparationColorNames 2 copy known
-							{
-								get
-								{ AGMCORE_name eq or}forall
-							not
-							}{
-								pop pop pop true
-							}ifelse
-							grestore
-						}ifelse
-					}ifelse
-				}ifelse
-			}ifelse
-		}def
-	}ifelse
-	/convert_to_process where {pop}{
-		/convert_to_process
-		{
-			dup length 0 eq
-				{
-				pop false
-				}{
-				AGMCORE_host_sep
-				{
-				dup true exch
-					{
-					dup (Cyan) eq exch
-					dup (Magenta) eq 3 -1 roll or exch
-					dup (Yellow) eq 3 -1 roll or exch
-					dup (Black) eq 3 -1 roll or
-						{pop}
-						{convert_spot_to_process and}ifelse
-					}
-				forall
-					{
-					true exch
-						{
-						dup (Cyan) eq exch
-						dup (Magenta) eq 3 -1 roll or exch
-						dup (Yellow) eq 3 -1 roll or exch
-						(Black) eq or and
-						}forall
-						not
-					}{pop false}ifelse
-				}{
-				false exch
-					{
-					dup (Cyan) eq exch
-					dup (Magenta) eq 3 -1 roll or exch
-					dup (Yellow) eq 3 -1 roll or exch
-					dup (Black) eq 3 -1 roll or
-					{pop}
-					{convert_spot_to_process or}ifelse
-					}
-				forall
-				}ifelse
-			}ifelse
-		}def
-	}ifelse	
-	/AGMCORE_avoid_L2_sep_space
-		version cvr 2012 lt
-		level2 and
-		AGMCORE_producing_seps not and
-	def
-	/AGMCORE_is_cmyk_sep
-		AGMCORE_cyan_plate AGMCORE_magenta_plate or AGMCORE_yellow_plate or AGMCORE_black_plate or
-	def
-	/AGM_avoid_0_cmyk where{
-		pop AGM_avoid_0_cmyk
-	}{
-		AGM_preserve_spots
-		userdict/Adobe_AGM_OnHost_Seps known
-		userdict/Adobe_AGM_InRip_Seps known or
-		not and
-	}ifelse
-	{
-		/setcmykcolor[
-			{
-				4 copy add add add 0 eq currentoverprint and{
-					pop 0.0005
-				}if
-			}/exec cvx
-			/AGMCORE_&setcmykcolor load dup type/operatortype ne{
-				/exec cvx
-			}if
-		]cvx def
-	}if
-	AGMCORE_host_sep{
-		/setcolortransfer
-		{
-			AGMCORE_cyan_plate{
-				pop pop pop
-			}{
-			  	AGMCORE_magenta_plate{
-			  		4 3 roll pop pop pop
-			  	}{
-			  		AGMCORE_yellow_plate{
-			  			4 2 roll pop pop pop
-			  		}{
-			  			4 1 roll pop pop pop
-			  		}ifelse
-			  	}ifelse
-			}ifelse
-			settransfer
-		}	
-		def
-		/AGMCORE_get_ink_data
-			AGMCORE_cyan_plate{
-				{pop pop pop}
-			}{
-			  	AGMCORE_magenta_plate{
-			  		{4 3 roll pop pop pop}
-			  	}{
-			  		AGMCORE_yellow_plate{
-			  			{4 2 roll pop pop pop}
-			  		}{
-			  			{4 1 roll pop pop pop}
-			  		}ifelse
-			  	}ifelse
-			}ifelse
-		def
-		/AGMCORE_RemoveProcessColorNames
-			{
-			1 dict begin
-			/filtername
-				{
-				dup /Cyan eq 1 index (Cyan) eq or
-					{pop (_cyan_)}if
-				dup /Magenta eq 1 index (Magenta) eq or
-					{pop (_magenta_)}if
-				dup /Yellow eq 1 index (Yellow) eq or
-					{pop (_yellow_)}if
-				dup /Black eq 1 index (Black) eq or
-					{pop (_black_)}if
-				}def
-			dup type /arraytype eq
-				{[exch {filtername}forall]}
-				{filtername}ifelse
-			end
-			}def
-		/AGMCORE_IsSeparationAProcessColor
-			{
-			dup (Cyan) eq exch dup (Magenta) eq exch dup (Yellow) eq exch (Black) eq or or or
-			}def
-		level3 {
-			/AGMCORE_IsCurrentColor
-				{
-				gsave
-				false setoverprint
-				1 1 1 1 5 -1 roll findcmykcustomcolor 1 setcustomcolor
-				currentgray 0 eq
-				grestore
-				}def
-			/AGMCORE_filter_functiondatasource
-				{	
-				5 dict begin
-				/data_in xdf
-				data_in type /stringtype eq
-					{
-					/ncomp xdf
-					/comp xdf
-					/string_out data_in length ncomp idiv string def
-					0 ncomp data_in length 1 sub
-						{
-						string_out exch dup ncomp idiv exch data_in exch ncomp getinterval comp get 255 exch sub put
-						}for
-					string_out
-					}{
-					string /string_in xdf
-					/string_out 1 string def
-					/component xdf
-					[
-					data_in string_in /readstring cvx
-						[component /get cvx 255 /exch cvx /sub cvx string_out /exch cvx 0 /exch cvx /put cvx string_out]cvx
-						[/pop cvx ()]cvx /ifelse cvx
-					]cvx /ReusableStreamDecode filter
-				}ifelse
-				end
-				}def
-			/AGMCORE_separateShadingFunction
-				{
-				2 dict begin
-				/paint? xdf
-				/channel xdf
-					begin
-					FunctionType 0 eq
-						{
-						/DataSource channel Range length 2 idiv DataSource AGMCORE_filter_functiondatasource def
-						currentdict /Decode known
-							{/Decode Decode channel 2 mul 2 getinterval def}if
-						paint? not
-							{/Decode [1 1]def}if
-						}if
-					FunctionType 2 eq
-						{
-						paint?
-							{
-							/C0 [C0 channel get 1 exch sub] def
-							/C1 [C1 channel get 1 exch sub] def
-							}{
-							/C0 [1] def
-							/C1 [1] def
-							}ifelse			
-						}if
-					FunctionType 3 eq
-						{
-						/Functions [Functions {channel paint? AGMCORE_separateShadingFunction} forall] def			
-						}if
-					currentdict /Range known
-						{/Range [0 1] def}if
-					currentdict
-					end
-				end
-				}def
-			/AGMCORE_separateShading
-				{
-				3 -1 roll begin
-				currentdict /Function known
-					{
-					currentdict /Background known
-						{[1 index{Background 3 index get 1 exch sub}{1}ifelse]/Background xdf}if
-					Function 3 1 roll AGMCORE_separateShadingFunction /Function xdf
-					/ColorSpace [/DeviceGray] def
-					}{
-					ColorSpace dup type /arraytype eq {0 get}if /DeviceCMYK eq
-						{
-						/ColorSpace [/DeviceN [/_cyan_ /_magenta_ /_yellow_ /_black_] /DeviceCMYK {}] def
-						}{
-						ColorSpace dup 1 get AGMCORE_RemoveProcessColorNames 1 exch put
-						}ifelse
-					ColorSpace 0 get /Separation eq
-						{
-							{
-								[1 /exch cvx /sub cvx]cvx
-							}{
-								[/pop cvx 1]cvx
-							}ifelse
-							ColorSpace 3 3 -1 roll put
-							pop
-						}{
-							{
-								[exch ColorSpace 1 get length 1 sub exch sub /index cvx 1 /exch cvx /sub cvx ColorSpace 1 get length 1 add 1 /roll cvx ColorSpace 1 get length{/pop cvx} repeat]cvx
-							}{
-								pop [ColorSpace 1 get length {/pop cvx} repeat cvx 1]cvx
-							}ifelse
-							ColorSpace 3 3 -1 roll bind put
-						}ifelse
-					ColorSpace 2 /DeviceGray put																		
-					}ifelse
-				end
-				}def
-			/AGMCORE_separateShadingDict
-				{
-				dup /ColorSpace get
-				dup type /arraytype ne
-					{[exch]}if
-				dup 0 get /DeviceCMYK eq
-					{
-					exch begin
-					currentdict
-					AGMCORE_cyan_plate
-						{0 true}if
-					AGMCORE_magenta_plate
-						{1 true}if
-					AGMCORE_yellow_plate
-						{2 true}if
-					AGMCORE_black_plate
-						{3 true}if
-					AGMCORE_plate_ndx 4 eq
-						{0 false}if		
-					dup not currentoverprint and
-						{/AGMCORE_ignoreshade true def}if
-					AGMCORE_separateShading
-					currentdict
-					end exch
-					}if
-				dup 0 get /Separation eq
-					{
-					exch begin
-					ColorSpace 1 get dup /None ne exch /All ne and
-						{
-						ColorSpace 1 get AGMCORE_IsCurrentColor AGMCORE_plate_ndx 4 lt and ColorSpace 1 get AGMCORE_IsSeparationAProcessColor not and
-							{
-							ColorSpace 2 get dup type /arraytype eq {0 get}if /DeviceCMYK eq
-								{
-								/ColorSpace
-									[
-									/Separation
-									ColorSpace 1 get
-									/DeviceGray
-										[
-										ColorSpace 3 get /exec cvx
-										4 AGMCORE_plate_ndx sub -1 /roll cvx
-										4 1 /roll cvx
-										3 [/pop cvx]cvx /repeat cvx
-										1 /exch cvx /sub cvx
-										]cvx									
-									]def
-								}{
-								AGMCORE_report_unsupported_color_space
-								AGMCORE_black_plate not
-									{
-									currentdict 0 false AGMCORE_separateShading
-									}if
-								}ifelse
-							}{
-							currentdict ColorSpace 1 get AGMCORE_IsCurrentColor
-							0 exch
-							dup not currentoverprint and
-								{/AGMCORE_ignoreshade true def}if
-							AGMCORE_separateShading
-							}ifelse	
-						}if			
-					currentdict
-					end exch
-					}if
-				dup 0 get /DeviceN eq
-					{
-					exch begin
-					ColorSpace 1 get convert_to_process
-						{
-						ColorSpace 2 get dup type /arraytype eq {0 get}if /DeviceCMYK eq
-							{
-							/ColorSpace
-								[
-								/DeviceN
-								ColorSpace 1 get
-								/DeviceGray
-									[
-									ColorSpace 3 get /exec cvx
-									4 AGMCORE_plate_ndx sub -1 /roll cvx
-									4 1 /roll cvx
-									3 [/pop cvx]cvx /repeat cvx
-									1 /exch cvx /sub cvx
-									]cvx									
-								]def
-							}{
-							AGMCORE_report_unsupported_color_space
-							AGMCORE_black_plate not
-								{
-								currentdict 0 false AGMCORE_separateShading
-								/ColorSpace [/DeviceGray] def
-								}if
-							}ifelse
-						}{
-						currentdict
-						false -1 ColorSpace 1 get
-							{
-							AGMCORE_IsCurrentColor
-								{
-								1 add
-								exch pop true exch exit
-								}if
-							1 add
-							}forall
-						exch
-						dup not currentoverprint and
-							{/AGMCORE_ignoreshade true def}if
-						AGMCORE_separateShading
-						}ifelse
-					currentdict
-					end exch
-					}if
-				dup 0 get dup /DeviceCMYK eq exch dup /Separation eq exch /DeviceN eq or or not
-					{
-					exch begin
-					ColorSpace dup type /arraytype eq
-						{0 get}if
-					/DeviceGray ne
-						{
-						AGMCORE_report_unsupported_color_space
-						AGMCORE_black_plate not
-							{
-							ColorSpace 0 get /CIEBasedA eq
-								{
-								/ColorSpace [/Separation /_ciebaseda_ /DeviceGray {}] def
-								}if
-							ColorSpace 0 get dup /CIEBasedABC eq exch dup /CIEBasedDEF eq exch /DeviceRGB eq or or
-								{
-								/ColorSpace [/DeviceN [/_red_ /_green_ /_blue_] /DeviceRGB {}] def
-								}if
-							ColorSpace 0 get /CIEBasedDEFG eq
-								{
-								/ColorSpace [/DeviceN [/_cyan_ /_magenta_ /_yellow_ /_black_] /DeviceCMYK {}]
-								}if
-							currentdict 0 false AGMCORE_separateShading
-							}if
-						}if
-					currentdict
-					end exch
-					}if
-				pop
-				dup /AGMCORE_ignoreshade known
-					{
-					begin
-					/ColorSpace [/Separation (None) /DeviceGray {}] def
-					currentdict end
-					}if
-				}def
-			/shfill
-				{
-				clonedict
-				AGMCORE_separateShadingDict
-				dup /AGMCORE_ignoreshade known
-					{pop}
-					{AGMCORE_&sysshfill}ifelse
-				}def
-			/makepattern
-				{
-				exch
-				dup /PatternType get 2 eq
-					{
-					clonedict
-					begin
-					/Shading Shading AGMCORE_separateShadingDict def
-					currentdict end
-					exch AGMCORE_&sysmakepattern
-					}{
-					exch AGMCORE_&usrmakepattern
-					}ifelse
-				}def
-		}if
-	}if
-	AGMCORE_in_rip_sep{
-		/setcustomcolor
-		{
-			exch aload pop
-			dup 7 1 roll inRip_spot_has_ink not	{
-				4 {4 index mul 4 1 roll}
-				repeat
-				/DeviceCMYK setcolorspace
-				6 -2 roll pop pop
-			}{
-				Adobe_AGM_Core begin
-					/AGMCORE_k xdf /AGMCORE_y xdf /AGMCORE_m xdf /AGMCORE_c xdf
-				end
-				[/Separation 4 -1 roll /DeviceCMYK
-				{dup AGMCORE_c mul exch dup AGMCORE_m mul exch dup AGMCORE_y mul exch AGMCORE_k mul}
-				]
-				setcolorspace
-			}ifelse
-			setcolor
-		}ndf
-		/setseparationgray
-		{
-			[/Separation (All) /DeviceGray {}] setcolorspace_opt
-			1 exch sub setcolor
-		}ndf
-	}{
-		/setseparationgray
-		{
-			AGMCORE_&setgray
-		}ndf
-	}ifelse
-	/findcmykcustomcolor
-	{
-		5 makereadonlyarray
-	}ndf
-	/setcustomcolor
-	{
-		exch aload pop pop
-		4 {4 index mul 4 1 roll} repeat
-		setcmykcolor pop
-	}ndf
-	/has_color
-		/colorimage where{
-			AGMCORE_producing_seps{
-				pop true
-			}{
-				systemdict eq
-			}ifelse
-		}{
-			false
-		}ifelse
-	def
-	/map_index
-	{
-		1 index mul exch getinterval {255 div} forall
-	} bdf
-	/map_indexed_devn
-	{
-		Lookup Names length 3 -1 roll cvi map_index
-	} bdf
-	/n_color_components
-	{
-		base_colorspace_type
-		dup /DeviceGray eq{
-			pop 1
-		}{
-			/DeviceCMYK eq{
-				4
-			}{
-				3
-			}ifelse
-		}ifelse
-	}bdf
-	level2{
-		/mo /moveto ldf
-		/li /lineto ldf
-		/cv /curveto ldf
-		/knockout_unitsq
-		{
-			1 setgray
-			0 0 1 1 rectfill
-		}def
-		/level2ScreenFreq{
-			begin
-			60
-			HalftoneType 1 eq{
-				pop Frequency
-			}if
-			HalftoneType 2 eq{
-				pop GrayFrequency
-			}if
-			HalftoneType 5 eq{
-				pop Default level2ScreenFreq
-			}if
-			 end
-		}def
-		/currentScreenFreq{
-			currenthalftone level2ScreenFreq
-		}def
-		level2 /setcolorspace AGMCORE_key_known not and{
-			/AGMCORE_&&&setcolorspace /setcolorspace ldf
-			/AGMCORE_ReplaceMappedColor
-			{
-				dup type dup /arraytype eq exch /packedarraytype eq or
-				{
-					dup 0 get dup /Separation eq
-					{
-						pop
-						dup length array copy
-						dup dup 1 get
-						current_spot_alias
-						{
-							dup map_alias
-							{
-								begin
-								/sep_colorspace_dict currentdict AGMCORE_gput
-								pop pop	pop
-								[
-									/Separation Name
-									CSA map_csa
-									dup /MappedCSA xdf
-									/sep_colorspace_proc load
-								]
-								dup Name
-								end
-							}if
-						}if
-						map_reserved_ink_name 1 xpt
-					}{
-						/DeviceN eq
-						{
-							dup length array copy
-							dup dup 1 get [
-								exch {
-									current_spot_alias{
-										dup map_alias{
-											/Name get exch pop
-										}if
-									}if
-									map_reserved_ink_name
-								} forall
-							] 1 xpt
-						}if
-					}ifelse
-				}if
-			}def
-			/setcolorspace
-			{
-				dup type dup /arraytype eq exch /packedarraytype eq or
-				{
-					dup 0 get /Indexed eq
-					{
-						AGMCORE_distilling
-						{
-							/PhotoshopDuotoneList where
-							{
-								pop false
-							}{
-								true
-							}ifelse
-						}{
-							true
-						}ifelse
-						{
-							aload pop 3 -1 roll
-							AGMCORE_ReplaceMappedColor
-							3 1 roll 4 array astore
-						}if
-					}{
-						AGMCORE_ReplaceMappedColor
-					}ifelse
-				}if
-				DeviceN_PS2_inRip_seps {AGMCORE_&&&setcolorspace} if
-			}def
-		}if	
-	}{
-		/adj
-		{
-			currentstrokeadjust{
-				transform
-				0.25 sub round 0.25 add exch
-				0.25 sub round 0.25 add exch
-				itransform
-			}if
-		}def
-		/mo{
-			adj moveto
-		}def
-		/li{
-			adj lineto
-		}def
-		/cv{
-			6 2 roll adj
-			6 2 roll adj
-			6 2 roll adj curveto
-		}def
-		/knockout_unitsq
-		{
-			1 setgray
-			8 8 1 [8 0 0 8 0 0] {<ffffffffffffffff>} image
-		}def
-		/currentstrokeadjust{
-			/currentstrokeadjust AGMCORE_gget
-		}def
-		/setstrokeadjust{
-			/currentstrokeadjust exch AGMCORE_gput
-		}def
-		/currentScreenFreq{
-			currentscreen pop pop
-		}def
-		/setcolorspace
-		{
-			/currentcolorspace exch AGMCORE_gput
-		} def
-		/currentcolorspace
-		{
-			/currentcolorspace AGMCORE_gget
-		} def
-		/setcolor_devicecolor
-		{
-			base_colorspace_type
-			dup /DeviceGray eq{
-				pop setgray
-			}{
-				/DeviceCMYK eq{
-					setcmykcolor
-				}{
-					setrgbcolor
-				}ifelse
-			}ifelse
-		}def
-		/setcolor
-		{
-			currentcolorspace 0 get
-			dup /DeviceGray ne{
-				dup /DeviceCMYK ne{
-					dup /DeviceRGB ne{
-						dup /Separation eq{
-							pop
-							currentcolorspace 3 get exec
-							currentcolorspace 2 get
-						}{
-							dup /Indexed eq{
-								pop
-								currentcolorspace 3 get dup type /stringtype eq{
-									currentcolorspace 1 get n_color_components
-									3 -1 roll map_index
-								}{
-									exec
-								}ifelse
-								currentcolorspace 1 get
-							}{
-								/AGMCORE_cur_err /AGMCORE_invalid_color_space def
-								AGMCORE_invalid_color_space
-							}ifelse
-						}ifelse
-					}if
-				}if
-			}if
-			setcolor_devicecolor
-		} def
-	}ifelse
-	/sop /setoverprint ldf
-	/lw /setlinewidth ldf
-	/lc /setlinecap ldf
-	/lj /setlinejoin ldf
-	/ml /setmiterlimit ldf
-	/dsh /setdash ldf
-	/sadj /setstrokeadjust ldf
-	/gry /setgray ldf
-	/rgb /setrgbcolor ldf
-	/cmyk /setcmykcolor ldf
-	/sep /setsepcolor ldf
-	/devn /setdevicencolor ldf
-	/idx /setindexedcolor ldf
-	/colr /setcolor ldf
-	/csacrd /set_csa_crd ldf
-	/sepcs /setsepcolorspace ldf
-	/devncs /setdevicencolorspace ldf
-	/idxcs /setindexedcolorspace ldf
-	/cp /closepath ldf
-	/clp /clp_npth ldf
-	/eclp /eoclp_npth ldf
-	/f /fill ldf
-	/ef /eofill ldf
-	/@ /stroke ldf
-	/nclp /npth_clp ldf
-	/gset /graphic_setup ldf
-	/gcln /graphic_cleanup ldf
-	currentdict{
-		dup xcheck 1 index type dup /arraytype eq exch /packedarraytype eq or and {
-			bind
-		}if
-		def
-	}forall
-	/currentpagedevice currentpagedevice def
-/getrampcolor {
-/indx exch def
-0 1 NumComp 1 sub {
-dup
-Samples exch get
-dup type /stringtype eq { indx get } if
-exch
-Scaling exch get aload pop
-3 1 roll
-mul add
-} for
-ColorSpaceFamily /Separation eq
-	{
-	sep
-	}
-	{
-	ColorSpaceFamily /DeviceN eq
-		{
-		devn
-		}
-		{
-		setcolor
-		}ifelse
-	}ifelse
-} bind def
-/sssetbackground { aload pop setcolor } bind def
-/RadialShade {
-40 dict begin
-/ColorSpaceFamily exch def
-/background exch def
-/ext1 exch def
-/ext0 exch def
-/BBox exch def
-/r2 exch def
-/c2y exch def
-/c2x exch def
-/r1 exch def
-/c1y exch def
-/c1x exch def
-/rampdict exch def
-/setinkoverprint where {pop /setinkoverprint{pop}def}if
-gsave
-BBox length 0 gt {
-newpath
-BBox 0 get BBox 1 get moveto
-BBox 2 get BBox 0 get sub 0 rlineto
-0 BBox 3 get BBox 1 get sub rlineto
-BBox 2 get BBox 0 get sub neg 0 rlineto
-closepath
-clip
-newpath
-} if
-c1x c2x eq
-{
-c1y c2y lt {/theta 90 def}{/theta 270 def} ifelse
-}
-{
-/slope c2y c1y sub c2x c1x sub div def
-/theta slope 1 atan def
-c2x c1x lt c2y c1y ge and { /theta theta 180 sub def} if
-c2x c1x lt c2y c1y lt and { /theta theta 180 add def} if
-}
-ifelse
-gsave
-clippath
-c1x c1y translate
-theta rotate
--90 rotate
-{ pathbbox } stopped
-{ 0 0 0 0 } if
-/yMax exch def
-/xMax exch def
-/yMin exch def
-/xMin exch def
-grestore
-xMax xMin eq yMax yMin eq or
-{
-grestore
-end
-}
-{
-/max { 2 copy gt { pop } {exch pop} ifelse } bind def
-/min { 2 copy lt { pop } {exch pop} ifelse } bind def
-rampdict begin
-40 dict begin
-background length 0 gt { background sssetbackground gsave clippath fill grestore } if
-gsave
-c1x c1y translate
-theta rotate
--90 rotate
-/c2y c1x c2x sub dup mul c1y c2y sub dup mul add sqrt def
-/c1y 0 def
-/c1x 0 def
-/c2x 0 def
-ext0 {
-0 getrampcolor
-c2y r2 add r1 sub 0.0001 lt
-{
-c1x c1y r1 360 0 arcn
-pathbbox
-/aymax exch def
-/axmax exch def
-/aymin exch def
-/axmin exch def
-/bxMin xMin axmin min def
-/byMin yMin aymin min def
-/bxMax xMax axmax max def
-/byMax yMax aymax max def
-bxMin byMin moveto
-bxMax byMin lineto
-bxMax byMax lineto
-bxMin byMax lineto
-bxMin byMin lineto
-eofill
-}
-{
-c2y r1 add r2 le
-{
-c1x c1y r1 0 360 arc
-fill
-}
-{
-c2x c2y r2 0 360 arc fill
-r1 r2 eq
-{
-/p1x r1 neg def
-/p1y c1y def
-/p2x r1 def
-/p2y c1y def
-p1x p1y moveto p2x p2y lineto p2x yMin lineto p1x yMin lineto
-fill
-}
-{
-/AA r2 r1 sub c2y div def
-/theta AA 1 AA dup mul sub sqrt div 1 atan def
-/SS1 90 theta add dup sin exch cos div def
-/p1x r1 SS1 SS1 mul SS1 SS1 mul 1 add div sqrt mul neg def
-/p1y p1x SS1 div neg def
-/SS2 90 theta sub dup sin exch cos div def
-/p2x r1 SS2 SS2 mul SS2 SS2 mul 1 add div sqrt mul def
-/p2y p2x SS2 div neg def
-r1 r2 gt
-{
-/L1maxX p1x yMin p1y sub SS1 div add def
-/L2maxX p2x yMin p2y sub SS2 div add def
-}
-{
-/L1maxX 0 def
-/L2maxX 0 def
-}ifelse
-p1x p1y moveto p2x p2y lineto L2maxX L2maxX p2x sub SS2 mul p2y add lineto
-L1maxX L1maxX p1x sub SS1 mul p1y add lineto
-fill
-}
-ifelse
-}
-ifelse
-} ifelse
-} if
-c1x c2x sub dup mul
-c1y c2y sub dup mul
-add 0.5 exp
-0 dtransform
-dup mul exch dup mul add 0.5 exp 72 div
-0 72 matrix defaultmatrix dtransform dup mul exch dup mul add sqrt
-72 0 matrix defaultmatrix dtransform dup mul exch dup mul add sqrt
-1 index 1 index lt { exch } if pop
-/hires exch def
-hires mul
-/numpix exch def
-/numsteps NumSamples def
-/rampIndxInc 1 def
-/subsampling false def
-numpix 0 ne
-{
-NumSamples numpix div 0.5 gt
-{
-/numsteps numpix 2 div round cvi dup 1 le { pop 2 } if def
-/rampIndxInc NumSamples 1 sub numsteps div def
-/subsampling true def
-} if
-} if
-/xInc c2x c1x sub numsteps div def
-/yInc c2y c1y sub numsteps div def
-/rInc r2 r1 sub numsteps div def
-/cx c1x def
-/cy c1y def
-/radius r1 def
-newpath
-xInc 0 eq yInc 0 eq rInc 0 eq and and
-{
-0 getrampcolor
-cx cy radius 0 360 arc
-stroke
-NumSamples 1 sub getrampcolor
-cx cy radius 72 hires div add 0 360 arc
-0 setlinewidth
-stroke
-}
-{
-0
-numsteps
-{
-dup
-subsampling { round cvi } if
-getrampcolor
-cx cy radius 0 360 arc
-/cx cx xInc add def
-/cy cy yInc add def
-/radius radius rInc add def
-cx cy radius 360 0 arcn
-eofill
-rampIndxInc add
-}
-repeat
-pop
-} ifelse
-ext1 {
-c2y r2 add r1 lt
-{
-c2x c2y r2 0 360 arc
-fill
-}
-{
-c2y r1 add r2 sub 0.0001 le
-{
-c2x c2y r2 360 0 arcn
-pathbbox
-/aymax exch def
-/axmax exch def
-/aymin exch def
-/axmin exch def
-/bxMin xMin axmin min def
-/byMin yMin aymin min def
-/bxMax xMax axmax max def
-/byMax yMax aymax max def
-bxMin byMin moveto
-bxMax byMin lineto
-bxMax byMax lineto
-bxMin byMax lineto
-bxMin byMin lineto
-eofill
-}
-{
-c2x c2y r2 0 360 arc fill
-r1 r2 eq
-{
-/p1x r2 neg def
-/p1y c2y def
-/p2x r2 def
-/p2y c2y def
-p1x p1y moveto p2x p2y lineto p2x yMax lineto p1x yMax lineto
-fill
-}
-{
-/AA r2 r1 sub c2y div def
-/theta AA 1 AA dup mul sub sqrt div 1 atan def
-/SS1 90 theta add dup sin exch cos div def
-/p1x r2 SS1 SS1 mul SS1 SS1 mul 1 add div sqrt mul neg def
-/p1y c2y p1x SS1 div sub def
-/SS2 90 theta sub dup sin exch cos div def
-/p2x r2 SS2 SS2 mul SS2 SS2 mul 1 add div sqrt mul def
-/p2y c2y p2x SS2 div sub def
-r1 r2 lt
-{
-/L1maxX p1x yMax p1y sub SS1 div add def
-/L2maxX p2x yMax p2y sub SS2 div add def
-}
-{
-/L1maxX 0 def
-/L2maxX 0 def
-}ifelse
-p1x p1y moveto p2x p2y lineto L2maxX L2maxX p2x sub SS2 mul p2y add lineto
-L1maxX L1maxX p1x sub SS1 mul p1y add lineto
-fill
-}
-ifelse
-}
-ifelse
-} ifelse
-} if
-grestore
-grestore
-end
-end
-end
-} ifelse
-} bind def
-/GenStrips {
-40 dict begin
-/ColorSpaceFamily exch def
-/background exch def
-/ext1 exch def
-/ext0 exch def
-/BBox exch def
-/y2 exch def
-/x2 exch def
-/y1 exch def
-/x1 exch def
-/rampdict exch def
-/setinkoverprint where {pop /setinkoverprint{pop}def}if
-gsave
-BBox length 0 gt {
-newpath
-BBox 0 get BBox 1 get moveto
-BBox 2 get BBox 0 get sub 0 rlineto
-0 BBox 3 get BBox 1 get sub rlineto
-BBox 2 get BBox 0 get sub neg 0 rlineto
-closepath
-clip
-newpath
-} if
-x1 x2 eq
-{
-y1 y2 lt {/theta 90 def}{/theta 270 def} ifelse
-}
-{
-/slope y2 y1 sub x2 x1 sub div def
-/theta slope 1 atan def
-x2 x1 lt y2 y1 ge and { /theta theta 180 sub def} if
-x2 x1 lt y2 y1 lt and { /theta theta 180 add def} if
-}
-ifelse
-gsave
-clippath
-x1 y1 translate
-theta rotate
-{ pathbbox } stopped
-{ 0 0 0 0 } if
-/yMax exch def
-/xMax exch def
-/yMin exch def
-/xMin exch def
-grestore
-xMax xMin eq yMax yMin eq or
-{
-grestore
-end
-}
-{
-rampdict begin
-20 dict begin
-background length 0 gt { background sssetbackground gsave clippath fill grestore } if
-gsave
-x1 y1 translate
-theta rotate
-/xStart 0 def
-/xEnd x2 x1 sub dup mul y2 y1 sub dup mul add 0.5 exp def
-/ySpan yMax yMin sub def
-/numsteps NumSamples def
-/rampIndxInc 1 def
-/subsampling false def
-xStart 0 transform
-xEnd 0 transform
-3 -1 roll
-sub dup mul
-3 1 roll
-sub dup mul
-add 0.5 exp 72 div
-0 72 matrix defaultmatrix dtransform dup mul exch dup mul add sqrt
-72 0 matrix defaultmatrix dtransform dup mul exch dup mul add sqrt
-1 index 1 index lt { exch } if pop
-mul
-/numpix exch def
-numpix 0 ne
-{
-NumSamples numpix div 0.5 gt
-{
-/numsteps numpix 2 div round cvi dup 1 le { pop 2 } if def
-/rampIndxInc NumSamples 1 sub numsteps div def
-/subsampling true def
-} if
-} if
-ext0 {
-0 getrampcolor
-xMin xStart lt
-{ xMin yMin xMin neg ySpan rectfill } if
-} if
-/xInc xEnd xStart sub numsteps div def
-/x xStart def
-0
-numsteps
-{
-dup
-subsampling { round cvi } if
-getrampcolor
-x yMin xInc ySpan rectfill
-/x x xInc add def
-rampIndxInc add
-}
-repeat
-pop
-ext1 {
-xMax xEnd gt
-{ xEnd yMin xMax xEnd sub ySpan rectfill } if
-} if
-grestore
-grestore
-end
-end
-end
-} ifelse
-} bind def
-}def
-/page_trailer
-{
-	end
-}def
-/doc_trailer{
-}def
-systemdict /findcolorrendering known{
-	/findcolorrendering systemdict /findcolorrendering get def
-}if
-systemdict /setcolorrendering known{
-	/setcolorrendering systemdict /setcolorrendering get def
-}if
-/test_cmyk_color_plate
-{
-	gsave
-	setcmykcolor currentgray 1 ne
-	grestore
-}def
-/inRip_spot_has_ink
-{
-	dup Adobe_AGM_Core/AGMCORE_name xddf
-	convert_spot_to_process not
-}def
-/map255_to_range
-{
-	1 index sub
-	3 -1 roll 255 div mul add
-}def
-/set_csa_crd
-{
-	/sep_colorspace_dict null AGMCORE_gput
-	begin
-		CSA map_csa setcolorspace_opt
-		set_crd
-	end
-}
-def
-/setsepcolor
-{
-	/sep_colorspace_dict AGMCORE_gget begin
-		dup /sep_tint exch AGMCORE_gput
-		TintProc
-	end
-} def
-/setdevicencolor
-{
-	/devicen_colorspace_dict AGMCORE_gget begin
-		Names length copy
-		Names length 1 sub -1 0
-		{
-			/devicen_tints AGMCORE_gget 3 1 roll xpt
-		} for
-		TintProc
-	end
-} def
-/sep_colorspace_proc
-{
-	Adobe_AGM_Core/AGMCORE_tmp xddf
-	/sep_colorspace_dict AGMCORE_gget begin
-	currentdict/Components known{
-		Components aload pop
-		TintMethod/Lab eq{
-			2 {AGMCORE_tmp mul NComponents 1 roll} repeat
-			LMax sub AGMCORE_tmp mul LMax add  NComponents 1 roll
-		}{
-			TintMethod/Subtractive eq{
-				NComponents{
-					AGMCORE_tmp mul NComponents 1 roll
-				}repeat
-			}{
-				NComponents{
-					1 sub AGMCORE_tmp mul 1 add  NComponents 1 roll
-				} repeat
-			}ifelse
-		}ifelse
-	}{
-		ColorLookup AGMCORE_tmp ColorLookup length 1 sub mul round cvi get
-		aload pop
-	}ifelse
-	end
-} def
-/sep_colorspace_gray_proc
-{
-	Adobe_AGM_Core/AGMCORE_tmp xddf
-	/sep_colorspace_dict AGMCORE_gget begin
-	GrayLookup AGMCORE_tmp GrayLookup length 1 sub mul round cvi get
-	end
-} def
-/sep_proc_name
-{
-	dup 0 get
-	dup /DeviceRGB eq exch /DeviceCMYK eq or level2 not and has_color not and{
-		pop [/DeviceGray]
-		/sep_colorspace_gray_proc
-	}{
-		/sep_colorspace_proc
-	}ifelse
-} def
-/setsepcolorspace
-{
-	current_spot_alias{
-		dup begin
-			Name map_alias{
-				exch pop
-			}if
-		end
-	}if
-	dup /sep_colorspace_dict exch AGMCORE_gput
-	begin
-	/MappedCSA CSA map_csa def
-	Adobe_AGM_Core/AGMCORE_sep_special Name dup () eq exch (All) eq or ddf
-	AGMCORE_avoid_L2_sep_space{
-		[/Indexed MappedCSA sep_proc_name 255 exch
-			{ 255 div } /exec cvx 3 -1 roll [ 4 1 roll load /exec cvx ] cvx
-		] setcolorspace_opt
-		/TintProc {
-			255 mul round cvi setcolor
-		}bdf
-	}{
-		MappedCSA 0 get /DeviceCMYK eq
-		currentdict/Components known and
-		AGMCORE_sep_special not and{
-			/TintProc [
-				Components aload pop Name findcmykcustomcolor
-				/exch cvx /setcustomcolor cvx
-			] cvx bdf
-		}{
- 			AGMCORE_host_sep Name (All) eq and{
- 				/TintProc {
-					1 exch sub setseparationgray
-				}bdf
- 			}{
-				AGMCORE_in_rip_sep MappedCSA 0 get /DeviceCMYK eq and
-				AGMCORE_host_sep or
-				Name () eq and{
-					/TintProc [
-						MappedCSA sep_proc_name exch 0 get /DeviceCMYK eq{
-							cvx /setcmykcolor cvx
-						}{
-							cvx /setgray cvx
-						}ifelse
-					] cvx bdf
-				}{
-					AGMCORE_producing_seps MappedCSA 0 get dup /DeviceCMYK eq exch /DeviceGray eq or and AGMCORE_sep_special not and{
-	 					/TintProc [
-							/dup cvx
-							MappedCSA sep_proc_name cvx exch
-							0 get /DeviceGray eq{
-								1 /exch cvx /sub cvx 0 0 0 4 -1 /roll cvx
-							}if
-							/Name cvx /findcmykcustomcolor cvx /exch cvx
-							AGMCORE_host_sep{
-								AGMCORE_is_cmyk_sep
-								/Name cvx
-								/AGMCORE_IsSeparationAProcessColor load /exec cvx
-								/not cvx /and cvx
-							}{
-								Name inRip_spot_has_ink not
-							}ifelse
-							[
-		 						/pop cvx 1
-							] cvx /if cvx
-							/setcustomcolor cvx
-						] cvx bdf
- 					}{
-						/TintProc /setcolor ldf
-						[/Separation Name MappedCSA sep_proc_name load ] setcolorspace_opt
-					}ifelse
-				}ifelse
-			}ifelse
-		}ifelse
-	}ifelse
-	set_crd
-	setsepcolor
-	end
-} def
-/additive_blend
-{
-  	3 dict begin
-  	/numarrays xdf
-  	/numcolors xdf
-  	0 1 numcolors 1 sub
-  		{
-  		/c1 xdf
-  		1
-  		0 1 numarrays 1 sub
-  			{
-			1 exch add /index cvx
-  			c1 /get cvx /mul cvx
-  			}for
- 		numarrays 1 add 1 /roll cvx
-  		}for
- 	numarrays [/pop cvx] cvx /repeat cvx
-  	end
-}def
-/subtractive_blend
-{
-	3 dict begin
-	/numarrays xdf
-	/numcolors xdf
-	0 1 numcolors 1 sub
-		{
-		/c1 xdf
-		1 1
-		0 1 numarrays 1 sub
-			{
-			1 3 3 -1 roll add /index cvx
-			c1 /get cvx /sub cvx /mul cvx
-			}for
-		/sub cvx
-		numarrays 1 add 1 /roll cvx
-		}for
-	numarrays [/pop cvx] cvx /repeat cvx
-	end
-}def
-/exec_tint_transform
-{
-	/TintProc [
-		/TintTransform cvx /setcolor cvx
-	] cvx bdf
-	MappedCSA setcolorspace_opt
-} bdf
-/devn_makecustomcolor
-{
-	2 dict begin
-	/names_index xdf
-	/Names xdf
-	1 1 1 1 Names names_index get findcmykcustomcolor
-	/devicen_tints AGMCORE_gget names_index get setcustomcolor
-	Names length {pop} repeat
-	end
-} bdf
-/setdevicencolorspace
-{
-	dup /AliasedColorants known {false}{true}ifelse
-	current_spot_alias and {
-		6 dict begin
-		/names_index 0 def
-		dup /names_len exch /Names get length def
-		/new_names names_len array def
-		/new_LookupTables names_len array def
-		/alias_cnt 0 def
-		dup /Names get
-		{
-			dup map_alias {
-				exch pop
-				dup /ColorLookup known {
-					dup begin
-					new_LookupTables names_index ColorLookup put
-					end
-				}{
-					dup /Components known {
-						dup begin
-						new_LookupTables names_index Components put
-						end
-					}{
-						dup begin
-						new_LookupTables names_index [null null null null] put
-						end
-					} ifelse
-				} ifelse
-				new_names names_index 3 -1 roll /Name get put
-				/alias_cnt alias_cnt 1 add def
-			}{
-				/name xdf				
-				new_names names_index name put
-				dup /LookupTables known {
-					dup begin
-					new_LookupTables names_index LookupTables names_index get put
-					end
-				}{
-					dup begin
-					new_LookupTables names_index [null null null null] put
-					end
-				} ifelse
-			} ifelse
-			/names_index names_index 1 add def
-		} forall
-		alias_cnt 0 gt {
-			/AliasedColorants true def
-			0 1 names_len 1 sub {
-				/names_index xdf
-				new_LookupTables names_index get 0 get null eq {
-					dup /Names get names_index get /name xdf
-					name (Cyan) eq name (Magenta) eq name (Yellow) eq name (Black) eq
-					or or or not {
-						/AliasedColorants false def
-						exit
-					} if
-				} if
-			} for
-			AliasedColorants {
-				dup begin
-				/Names new_names def
-				/AliasedColorants true def
-				/LookupTables new_LookupTables def
-				currentdict /TTTablesIdx known not {
-					/TTTablesIdx -1 def
-				} if
-				currentdict /NComponents known not {
-					/NComponents TintMethod /Subtractive eq {4}{3}ifelse def
-				} if
-				end
-			} if
-		}if
-		end
-	} if
-	dup /devicen_colorspace_dict exch AGMCORE_gput
-	begin
-	/MappedCSA CSA map_csa def
-	currentdict /AliasedColorants known {
-		AliasedColorants
-	}{
-		false
-	} ifelse
-	/TintTransform load type /nulltype eq or {
-		/TintTransform [
-			0 1 Names length 1 sub
-				{
-				/TTTablesIdx TTTablesIdx 1 add def
-				dup LookupTables exch get dup 0 get null eq
-					{
-					1 index
-					Names exch get
-					dup (Cyan) eq
-						{
-						pop exch
-						LookupTables length exch sub
-						/index cvx
-						0 0 0
-						}
-						{
-						dup (Magenta) eq
-							{
-							pop exch
-							LookupTables length exch sub
-							/index cvx
-							0 /exch cvx 0 0
-							}
-							{
-							(Yellow) eq
-								{
-								exch
-								LookupTables length exch sub
-								/index cvx
-								0 0 3 -1 /roll cvx 0
-								}
-								{
-								exch
-								LookupTables length exch sub
-								/index cvx
-								0 0 0 4 -1 /roll cvx
-								} ifelse
-							} ifelse
-						} ifelse
-					5 -1 /roll cvx /astore cvx
-					}
-					{
-					dup length 1 sub
-					LookupTables length 4 -1 roll sub 1 add
-					/index cvx /mul cvx /round cvx /cvi cvx /get cvx
-					} ifelse
-					Names length TTTablesIdx add 1 add 1 /roll cvx
-				} for
-			Names length [/pop cvx] cvx /repeat cvx
-			NComponents Names length
-  			TintMethod /Subtractive eq
-  				{
-  				subtractive_blend
-  				}
-  				{
-  				additive_blend
-  				} ifelse
-		] cvx bdf
-	} if
-	AGMCORE_host_sep {
-		Names convert_to_process {
-			exec_tint_transform
-		}
-		{	
-			currentdict /AliasedColorants known {
-				AliasedColorants not
-			}{
-				false
-			} ifelse
-			5 dict begin
-			/AvoidAliasedColorants xdf
-			/painted? false def
-			/names_index 0 def
-			/names_len Names length def
-			Names {
-				AvoidAliasedColorants {
-					/currentspotalias current_spot_alias def
-					false set_spot_alias
-				} if
-				AGMCORE_is_cmyk_sep {
-					dup (Cyan) eq AGMCORE_cyan_plate and exch
-					dup (Magenta) eq AGMCORE_magenta_plate and exch
-					dup (Yellow) eq AGMCORE_yellow_plate and exch
-					(Black) eq AGMCORE_black_plate and or or or {
-						/devicen_colorspace_dict AGMCORE_gget /TintProc [
-							Names names_index /devn_makecustomcolor cvx
-						] cvx ddf
-						/painted? true def
-					} if
-					painted? {exit} if
-				}{
-					0 0 0 0 5 -1 roll findcmykcustomcolor 1 setcustomcolor currentgray 0 eq {
-					/devicen_colorspace_dict AGMCORE_gget /TintProc [
-						Names names_index /devn_makecustomcolor cvx
-					] cvx ddf
-					/painted? true def
-					exit
-					} if
-				} ifelse
-				AvoidAliasedColorants {
-					currentspotalias set_spot_alias
-				} if
-				/names_index names_index 1 add def
-			} forall
-			painted? {
-				/devicen_colorspace_dict AGMCORE_gget /names_index names_index put
-			}{
-				/devicen_colorspace_dict AGMCORE_gget /TintProc [
-					names_len [/pop cvx] cvx /repeat cvx 1 /setseparationgray cvx
-					0 0 0 0 () /findcmykcustomcolor cvx 0 /setcustomcolor cvx
-				] cvx ddf
-			} ifelse
-			end
-		} ifelse
-	}
-	{
-		AGMCORE_in_rip_sep {
-			Names convert_to_process not
-		}{
-			level3
-		} ifelse
-		{
-			[/DeviceN Names MappedCSA /TintTransform load] setcolorspace_opt
-			/TintProc level3 not AGMCORE_in_rip_sep and {
-				[
-					Names /length cvx [/pop cvx] cvx /repeat cvx
-				] cvx bdf
-			}{
-				/setcolor ldf
-			} ifelse
-		}{
-			exec_tint_transform
-		} ifelse
-	} ifelse
-	set_crd
-	/AliasedColorants false def
-	end
-} def
-/setindexedcolorspace
-{
-	dup /indexed_colorspace_dict exch AGMCORE_gput
-	begin
-		currentdict /CSD known {
-			CSD get_csd /Names known {
-				CSD get_csd begin
-				currentdict devncs
-				AGMCORE_host_sep{
-					4 dict begin
-					/devnCompCnt Names length def
-					/NewLookup HiVal 1 add string def
-					0 1 HiVal {
-						/tableIndex xdf
-						Lookup dup type /stringtype eq {
-							devnCompCnt tableIndex map_index
-						}{
-							exec
-						} ifelse
-						setdevicencolor
-						currentgray
-						tableIndex exch
-						HiVal mul cvi
-						NewLookup 3 1 roll put
-					} for
-					[/Indexed currentcolorspace HiVal NewLookup] setcolorspace_opt
-					end
-				}{
-					level3
-					{
-					[/Indexed [/DeviceN Names MappedCSA /TintTransform load] HiVal Lookup] setcolorspace_opt
-					}{
-					[/Indexed MappedCSA HiVal
-						[
-						Lookup dup type /stringtype eq
-							{/exch cvx CSD get_csd /Names get length dup /mul cvx exch /getinterval cvx {255 div} /forall cvx}
-							{/exec cvx}ifelse
-							/TintTransform load /exec cvx
-						]cvx
-					]setcolorspace_opt
-					}ifelse
-				} ifelse
-				end
-			}{
-			} ifelse
-			set_crd
-		}
-		{
-			/MappedCSA CSA map_csa def
-			AGMCORE_host_sep level2 not and{
-				0 0 0 0 setcmykcolor
-			}{
-				[/Indexed MappedCSA
-				level2 not has_color not and{
-					dup 0 get dup /DeviceRGB eq exch /DeviceCMYK eq or{
-						pop [/DeviceGray]
-					}if
-					HiVal GrayLookup
-				}{
-					HiVal
-					currentdict/RangeArray known{
-						{
-							/indexed_colorspace_dict AGMCORE_gget begin
-							Lookup exch
-							dup HiVal gt{
-								pop HiVal
-							}if
-							NComponents mul NComponents getinterval {} forall
-							NComponents 1 sub -1 0{
-								RangeArray exch 2 mul 2 getinterval aload pop map255_to_range
-								NComponents 1 roll
-							}for
-							end
-						} bind
-					}{
-						Lookup
-					}ifelse
-				}ifelse
-				] setcolorspace_opt
-				set_crd
-			}ifelse
-		}ifelse
-	end
-}def
-/setindexedcolor
-{
-	AGMCORE_host_sep {
-		/indexed_colorspace_dict AGMCORE_gget dup /CSD known {
-			begin
-			CSD get_csd begin
-			map_indexed_devn
-			devn
-			end
-			end
-		}{
-			AGMCORE_gget/Lookup get 4 3 -1 roll map_index
-			pop setcmykcolor
-		} ifelse
-	}{
-		level3 not AGMCORE_in_rip_sep and /indexed_colorspace_dict AGMCORE_gget /CSD known and {
-			/indexed_colorspace_dict AGMCORE_gget /CSD get get_csd begin
-			map_indexed_devn
-			devn
-			end
-		}
-		{
-			setcolor
-		} ifelse
-	}ifelse
-} def
-/ignoreimagedata
-{
-	currentoverprint not{
-		gsave
-		dup clonedict begin
-		1 setgray
-		/Decode [0 1] def
-		/DataSource <FF> def
-		/MultipleDataSources false def
-		/BitsPerComponent 8 def
-		currentdict end
-		systemdict /image get exec
-		grestore
-		}if
-	consumeimagedata
-}def
-/add_csa
-{
-	Adobe_AGM_Core begin
-			/AGMCORE_CSA_cache xput
-	end
-}def
-/get_csa_by_name
-{
-	dup type dup /nametype eq exch /stringtype eq or{
-		Adobe_AGM_Core begin
-		1 dict begin
-		/name xdf
-		AGMCORE_CSA_cache
-		{
-			0 get name eq {
-				exit
-			}{
-				pop
-			} ifelse
-		}forall
-		end
-		end
-	}{
-		pop
-	} ifelse
-}def
-/map_csa
-{
-	dup type /nametype eq{
-		Adobe_AGM_Core/AGMCORE_CSA_cache get exch get
-	}if
-}def
-/add_csd
-{
-	Adobe_AGM_Core begin
-		/AGMCORE_CSD_cache xput
-	end
-}def
-/get_csd
-{
-	dup type /nametype eq{
-		Adobe_AGM_Core/AGMCORE_CSD_cache get exch get
-	}if
-}def
-/pattern_buf_init
-{
-	/count get 0 0 put
-} def
-/pattern_buf_next
-{
-	dup /count get dup 0 get
-	dup 3 1 roll
-	1 add 0 xpt
-	get				
-} def
-/cachepattern_compress
-{
-	5 dict begin
-	currentfile exch 0 exch /SubFileDecode filter /ReadFilter exch def
-	/patarray 20 dict def
-	/string_size 16000 def
-	/readbuffer string_size string def
-	currentglobal true setglobal
-	patarray 1 array dup 0 1 put /count xpt
-	setglobal
-	/LZWFilter
-	{
-		exch
-		dup length 0 eq {
-			pop
-		}{
-			patarray dup length 1 sub 3 -1 roll put
-		} ifelse
-		{string_size}{0}ifelse string
-	} /LZWEncode filter def
-	{ 		
-		ReadFilter readbuffer readstring
-		exch LZWFilter exch writestring
-		not {exit} if
-	} loop
-	LZWFilter closefile
-	patarray				
-	end
-}def
-/cachepattern
-{
-	2 dict begin
-	currentfile exch 0 exch /SubFileDecode filter /ReadFilter exch def
-	/patarray 20 dict def
-	currentglobal true setglobal
-	patarray 1 array dup 0 1 put /count xpt
-	setglobal
-	{
-		ReadFilter 16000 string readstring exch
-		patarray dup length 1 sub 3 -1 roll put
-		not {exit} if
-	} loop
-	patarray dup dup length 1 sub () put					
-	end	
-}def
-/add_pattern
-{
-	Adobe_AGM_Core begin
-		/AGMCORE_pattern_cache xput
-	end
-}def
-/get_pattern
-{
-	dup type /nametype eq{
-		Adobe_AGM_Core/AGMCORE_pattern_cache get exch get
-		dup wrap_paintproc
-	}if
-}def
-/wrap_paintproc
-{
-  statusdict /currentfilenameextend known{
-	  begin
-		/OldPaintProc /PaintProc load def
-		/PaintProc
-		{
-		  mark exch
-		  dup /OldPaintProc get stopped
-		  {closefile restore end} if
-		  cleartomark
-		}  def
-	  end
-  } {pop} ifelse
-} def
-/make_pattern
-{
-	dup matrix currentmatrix matrix concatmatrix 0 0 3 2 roll itransform
-	exch 3 index /XStep get 1 index exch 2 copy div cvi mul sub sub
-	exch 3 index /YStep get 1 index exch 2 copy div cvi mul sub sub
-	matrix translate exch matrix concatmatrix
-			  1 index begin
-		BBox 0 get XStep div cvi XStep mul /xshift exch neg def
-		BBox 1 get YStep div cvi YStep mul /yshift exch neg def
-		BBox 0 get xshift add
-		BBox 1 get yshift add
-		BBox 2 get xshift add
-		BBox 3 get yshift add
-		4 array astore
-		/BBox exch def
-		[ xshift yshift /translate load null /exec load ] dup
-		3 /PaintProc load put cvx /PaintProc exch def
-		end
-	gsave 0 setgray
-	makepattern
-	grestore
-}def
-/set_pattern
-{
-	dup /PatternType get 1 eq{
-		dup /PaintType get 1 eq{
-			currentoverprint sop [/DeviceGray] setcolorspace 0 setgray
-		}if
-	}if
-	setpattern
-}def
-/setcolorspace_opt
-{
-	dup currentcolorspace eq{
-		pop
-	}{
-		setcolorspace
-	}ifelse
-}def
-/updatecolorrendering
-{
-	currentcolorrendering/Intent known{
-		currentcolorrendering/Intent get
-	}{
-		null
-	}ifelse
-	Intent ne{
-		false
-		Intent
-		AGMCORE_CRD_cache {
-			exch pop
-			begin
-				dup Intent eq{
-					currentdict setcolorrendering_opt
-					end
-					exch pop true exch	
-					exit
-				}if
-			end
-		} forall
-		pop
-		not{
-			systemdict /findcolorrendering known{
-				Intent findcolorrendering pop
-				/ColorRendering findresource
-				dup length dict copy
-				setcolorrendering_opt
-			}if
-		}if
-	}if
-} def
-/add_crd
-{
-	AGMCORE_CRD_cache 3 1 roll put
-}def
-/set_crd
-{
-	AGMCORE_host_sep not level2 and{
-		currentdict/CRD known{
-			AGMCORE_CRD_cache CRD get dup null ne{
-				setcolorrendering_opt
-			}{
-				pop
-			}ifelse
-		}{
-			currentdict/Intent known{
-				updatecolorrendering
-			}if
-		}ifelse
-		currentcolorspace dup type /arraytype eq
-			{0 get}if
-		/DeviceRGB eq
-			{
-			currentdict/UCR known
-				{/UCR}{/AGMCORE_currentucr}ifelse
-			load setundercolorremoval
-			currentdict/BG known
-				{/BG}{/AGMCORE_currentbg}ifelse
-			load setblackgeneration
-			}if
-	}if
-}def
-/setcolorrendering_opt
-{
-	dup currentcolorrendering eq{
-		pop
-	}{
-		begin
-			/Intent Intent def
-			currentdict
-		end
-		setcolorrendering
-	}ifelse
-}def
-/cpaint_gcomp
-{
-	convert_to_process Adobe_AGM_Core/AGMCORE_ConvertToProcess xddf
-	Adobe_AGM_Core/AGMCORE_ConvertToProcess get not
-	{
-		(%end_cpaint_gcomp) flushinput
-	}if
-}def
-/cpaint_gsep
-{
-	Adobe_AGM_Core/AGMCORE_ConvertToProcess get
-	{	
-		(%end_cpaint_gsep) flushinput
-	}if
-}def
-/cpaint_gend
-{
-	newpath
-}def
-/path_rez
-{
-	dup 0 ne{
-		AGMCORE_deviceDPI exch div
-		dup 1 lt{
-			pop 1
-		}if
-		setflat
-	}{
-		pop
-	}ifelse 	
-}def
-/set_spot_alias_ary
-{
-	/AGMCORE_SpotAliasAry where{
-		pop pop
-	}{
-		Adobe_AGM_Core/AGMCORE_SpotAliasAry xddf
-		true set_spot_alias
-	}ifelse
-}def
-/set_spot_alias
-{
-	/AGMCORE_SpotAliasAry where{
-		/AGMCORE_current_spot_alias 3 -1 roll put
-	}{
-		pop
-	}ifelse
-}def
-/current_spot_alias
-{
-	/AGMCORE_SpotAliasAry where{
-		/AGMCORE_current_spot_alias get
-	}{
-		false
-	}ifelse
-}def
-/map_alias
-{
-	/AGMCORE_SpotAliasAry where{
-		begin
-			/AGMCORE_name xdf
-			false	
-			AGMCORE_SpotAliasAry{
-				dup/Name get AGMCORE_name eq{
-					save exch
-					/Adobe_AGM_Core currentdict def
-					/CSD get get_csd
-					exch restore
-					exch pop true
-					exit
-				}{
-					pop
-				}ifelse
-			}forall
-		end
-	}{
-		pop false
-	}ifelse
-}bdf
-/spot_alias
-{
-	true set_spot_alias
-	/AGMCORE_&setcustomcolor AGMCORE_key_known not {
-		Adobe_AGM_Core/AGMCORE_&setcustomcolor /setcustomcolor load put
-	} if
-	/customcolor_tint 1 AGMCORE_gput
-	Adobe_AGM_Core begin
-	/setcustomcolor
-	{
-		dup /customcolor_tint exch AGMCORE_gput
-		current_spot_alias{
-			1 index 4 get map_alias{
-				mark 3 1 roll
-				setsepcolorspace
-				counttomark 0 ne{
-					setsepcolor
-				}if
-				pop
-				pop
-			}{
-				AGMCORE_&setcustomcolor
-			}ifelse
-		}{
-			AGMCORE_&setcustomcolor
-		}ifelse
-	}bdf
-	end
-}def
-/begin_feature
-{
-	Adobe_AGM_Core/AGMCORE_feature_dictCount countdictstack put
-	count Adobe_AGM_Core/AGMCORE_feature_opCount 3 -1 roll put
-	{Adobe_AGM_Core/AGMCORE_feature_ctm matrix currentmatrix put}if
-}def
-/end_feature
-{
-	2 dict begin
-	/spd /setpagedevice load def
-	/setpagedevice { get_gstate spd set_gstate } def
-	stopped{$error/newerror false put}if
-	end
-	count Adobe_AGM_Core/AGMCORE_feature_opCount get sub dup 0 gt{{pop}repeat}{pop}ifelse
-	countdictstack Adobe_AGM_Core/AGMCORE_feature_dictCount get sub dup 0 gt{{end}repeat}{pop}ifelse
-	{Adobe_AGM_Core/AGMCORE_feature_ctm get setmatrix}if
-}def
-/set_negative
-{
-	Adobe_AGM_Core begin
-	/AGMCORE_inverting exch def
-	level2{
-		currentpagedevice/NegativePrint known{
-			currentpagedevice/NegativePrint get Adobe_AGM_Core/AGMCORE_inverting get ne{
-				true begin_feature true{
-						bdict /NegativePrint Adobe_AGM_Core/AGMCORE_inverting get edict setpagedevice
-				}end_feature
-			}if
-			/AGMCORE_inverting false def
-		}if
-	}if
-	AGMCORE_inverting{
-		[{1 exch sub}/exec load dup currenttransfer exch]cvx bind settransfer
-		gsave newpath clippath 1 /setseparationgray where{pop setseparationgray}{setgray}ifelse
-		/AGMIRS_&fill where {pop AGMIRS_&fill}{fill} ifelse grestore
-	}if
-	end
-}def
-/lw_save_restore_override {
-	/md where {
-		pop
-		md begin
-		initializepage
-		/initializepage{}def
-		/pmSVsetup{} def
-		/endp{}def
-		/pse{}def
-		/psb{}def
-		/orig_showpage where
-			{pop}
-			{/orig_showpage /showpage load def}
-		ifelse
-		/showpage {orig_showpage gR} def
-		end
-	}if
-}def
-/pscript_showpage_override {
-	/NTPSOct95 where
-	{
-		begin
-		showpage
-		save
-		/showpage /restore load def
-		/restore {exch pop}def
-		end
-	}if
-}def
-/driver_media_override
-{
-	/md where {
-		pop
-		md /initializepage known {
-			md /initializepage {} put
-		} if
-		md /rC known {
-			md /rC {4{pop}repeat} put
-		} if
-	}if
-	/mysetup where {
-		/mysetup [1 0 0 1 0 0] put
-	}if
-	Adobe_AGM_Core /AGMCORE_Default_CTM matrix currentmatrix put
-	level2
-		{Adobe_AGM_Core /AGMCORE_Default_PageSize currentpagedevice/PageSize get put}if
-}def
-/driver_check_media_override
-{
-	/PrepsDict where
-		{pop}
-		{
-		Adobe_AGM_Core /AGMCORE_Default_CTM get matrix currentmatrix ne
-		Adobe_AGM_Core /AGMCORE_Default_PageSize get type /arraytype eq
-			{
-			Adobe_AGM_Core /AGMCORE_Default_PageSize get 0 get currentpagedevice/PageSize get 0 get eq and
-			Adobe_AGM_Core /AGMCORE_Default_PageSize get 1 get currentpagedevice/PageSize get 1 get eq and
-			}if
-			{
-			Adobe_AGM_Core /AGMCORE_Default_CTM get setmatrix
-			}if
-		}ifelse
-}def
-AGMCORE_err_strings begin
-	/AGMCORE_bad_environ (Environment not satisfactory for this job. Ensure that the PPD is correct or that the PostScript level requested is supported by this printer. ) def
-	/AGMCORE_color_space_onhost_seps (This job contains colors that will not separate with on-host methods. ) def
-	/AGMCORE_invalid_color_space (This job contains an invalid color space. ) def
-end
-end
-systemdict /setpacking known
-{
-	setpacking
-} if
-%%EndResource
-%%BeginResource: procset Adobe_CoolType_Core 2.23 0
-%%Copyright: Copyright 1997-2003 Adobe Systems Incorporated.  All Rights Reserved.
-%%Version: 2.23 0
-10 dict begin
-/Adobe_CoolType_Passthru currentdict def
-/Adobe_CoolType_Core_Defined userdict /Adobe_CoolType_Core known def
-Adobe_CoolType_Core_Defined
-	{ /Adobe_CoolType_Core userdict /Adobe_CoolType_Core get def }
-if
-userdict /Adobe_CoolType_Core 60 dict dup begin put
-/Adobe_CoolType_Version 2.23 def
-/Level2?
-	systemdict /languagelevel known dup
-		{ pop systemdict /languagelevel get 2 ge }
-	if def
-Level2? not
-	{
-	/currentglobal false def
-	/setglobal /pop load def
-	/gcheck { pop false } bind def
-	/currentpacking false def
-	/setpacking /pop load def
-	/SharedFontDirectory 0 dict def
-	}
-if
-currentpacking
-true setpacking
-/@_SaveStackLevels
-	{
-	Adobe_CoolType_Data
-		begin
-		@opStackCountByLevel @opStackLevel
-		2 copy known not
-			{ 2 copy 3 dict dup /args 7 index 5 add array put put get }
-			{
-			get dup /args get dup length 3 index lt
-				{
-				dup length 5 add array exch
-				1 index exch 0 exch putinterval
-				1 index exch /args exch put
-				}
-				{ pop }
-			ifelse
-			}
-		ifelse
-			begin
-			count 2 sub 1 index lt
-				{ pop count 1 sub }
-			if
-			dup /argCount exch def
-			dup 0 gt
-				{
-				exch 1 index 2 add 1 roll
-				args exch 0 exch getinterval
-			astore pop
-				}
-				{ pop }
-			ifelse
-			count 1 sub /restCount exch def
-			end
-		/@opStackLevel @opStackLevel 1 add def
-		countdictstack 1 sub
-		@dictStackCountByLevel exch @dictStackLevel exch put
-		/@dictStackLevel @dictStackLevel 1 add def
-		end
-	} bind def
-/@_RestoreStackLevels
-	{
-	Adobe_CoolType_Data
-		begin
-		/@opStackLevel @opStackLevel 1 sub def
-		@opStackCountByLevel @opStackLevel get
-			begin
-			count restCount sub dup 0 gt
-				{ { pop } repeat }
-				{ pop }
-			ifelse
-			args 0 argCount getinterval {} forall
-			end
-		/@dictStackLevel @dictStackLevel 1 sub def
-		@dictStackCountByLevel @dictStackLevel get
-		end
-	countdictstack exch sub dup 0 gt
-		{ { end } repeat }
-		{ pop }
-	ifelse
-	} bind def
-/@_PopStackLevels
-	{
-	Adobe_CoolType_Data
-		begin
-		/@opStackLevel @opStackLevel 1 sub def
-		/@dictStackLevel @dictStackLevel 1 sub def
-		end
-	} bind def
-/@Raise
-	{
-	exch cvx exch errordict exch get exec
-	stop
-	} bind def
-/@ReRaise
-	{
-	cvx $error /errorname get errordict exch get exec
-	stop
-	} bind def
-/@Stopped
-	{
-	0 @#Stopped
-	} bind def
-/@#Stopped
-	{
-	@_SaveStackLevels
-	stopped
-		{ @_RestoreStackLevels true }
-		{ @_PopStackLevels false }
-	ifelse
-	} bind def
-/@Arg
-	{
-	Adobe_CoolType_Data
-		begin
-		@opStackCountByLevel @opStackLevel 1 sub get /args get exch get
-		end
-	} bind def
-currentglobal true setglobal
-/CTHasResourceForAllBug
-	Level2?
-		{
-		1 dict dup begin
-		mark
-			{
-				(*) { pop stop } 128 string /Category
-			resourceforall
-			}
-		stopped
-		cleartomark
-		currentdict eq dup
-			{ end }
-		if
-		not
-		}
-		{ false }
-	ifelse
-	def
-/CTHasResourceStatusBug
-	Level2?
-		{
-		mark
-			{ /steveamerige /Category resourcestatus }
-		stopped
-			{ cleartomark true }
-			{ cleartomark currentglobal not }
-		ifelse
-		}
-		{ false }
-	ifelse
-	def
-setglobal
-/CTResourceStatus
-		{
-		mark 3 1 roll
-		/Category findresource
-			begin
-			({ResourceStatus} stopped) 0 () /SubFileDecode filter cvx exec
-				{ cleartomark false }
-				{ { 3 2 roll pop true } { cleartomark false } ifelse }
-			ifelse
-			end
-		} bind def
-/CTWorkAroundBugs
-	{
-	Level2?
-		{
-		/cid_PreLoad /ProcSet resourcestatus
-			{
-			pop pop
-			currentglobal
-			mark
-				{
-				(*)
-					{
-					dup /CMap CTHasResourceStatusBug
-						{ CTResourceStatus }
-						{ resourcestatus }
-					ifelse
-						{
-						pop dup 0 eq exch 1 eq or
-							{
-							dup /CMap findresource gcheck setglobal
-							/CMap undefineresource
-							}
-							{
-							pop CTHasResourceForAllBug
-								{ exit }
-								{ stop }
-							ifelse
-							}
-						ifelse
-						}
-						{ pop }
-					ifelse
-					}
-				128 string /CMap resourceforall
-				}
-			stopped
-				{ cleartomark }
-			stopped pop
-			setglobal
-			}
-		if
-		}
-	if
-	} bind def
-/doc_setup
-	{
-	Adobe_CoolType_Core
-		begin
-		CTWorkAroundBugs
-		/mov /moveto load def
-		/nfnt /newencodedfont load def
-		/mfnt /makefont load def
-		/sfnt /setfont load def
-		/ufnt /undefinefont load def
-		/chp /charpath load def
-		/awsh /awidthshow load def
-		/wsh /widthshow load def
-		/ash /ashow load def
-		/sh /show load def
-		end
-	userdict /Adobe_CoolType_Data 10 dict dup
-		begin
-		/AddWidths? false def
-		/CC 0 def
-		/charcode 2 string def
-		/@opStackCountByLevel 32 dict def
-		/@opStackLevel 0 def
-		/@dictStackCountByLevel 32 dict def
-		/@dictStackLevel 0 def
-		/InVMFontsByCMap 10 dict def
-		/InVMDeepCopiedFonts 10 dict def
-		end put
-	} bind def
-/doc_trailer
-	{
-	currentdict Adobe_CoolType_Core eq
-		{ end }
-	if
-	} bind def
-/page_setup
-	{
-	Adobe_CoolType_Core begin
-	} bind def
-/page_trailer
-	{
-	end
-	} bind def
-/unload
-	{
-	systemdict /languagelevel known
-		{
-		systemdict/languagelevel get 2 ge
-			{
-			userdict/Adobe_CoolType_Core 2 copy known
-				{ undef }
-				{ pop pop }
-			ifelse
-			}
-		if
-		}
-	if
-	} bind def
-/ndf
-	{
-	1 index where
-		{ pop pop pop }
-		{ dup xcheck { bind } if def }
-	ifelse
-	} def
-/findfont systemdict
-	begin
-	userdict
-		begin
-		/globaldict where { /globaldict get begin } if
-			dup where pop exch get
-		/globaldict where { pop end } if
-		end
-	end
-Adobe_CoolType_Core_Defined
-	{ /systemfindfont exch def }
-	{
-	/findfont 1 index def
-	/systemfindfont exch def
-	}
-ifelse
-/undefinefont
-	{ pop } ndf
-/copyfont
-	{
-	currentglobal 3 1 roll
-	1 index gcheck setglobal
-	dup null eq { 0 } { dup length } ifelse
-	2 index length add 1 add dict
-		begin
-		exch
-			{
-			1 index /FID eq
-				{ pop pop }
-				{ def }
-			ifelse
-			}
-		forall
-		dup null eq
-			{ pop }
-			{ { def } forall }
-		ifelse
-		currentdict
-		end
-	exch setglobal
-	} bind def
-/copyarray
-	{
-	currentglobal exch
-	dup gcheck setglobal
-	dup length array copy
-	exch setglobal
-	} bind def
-/newencodedfont
-	{
-	currentglobal
-		{
-		SharedFontDirectory 3 index  known
-			{ SharedFontDirectory 3 index get /FontReferenced known }
-			{ false }
-		ifelse
-		}
-		{
-		FontDirectory 3 index known
-			{ FontDirectory 3 index get /FontReferenced known }
-			{
-			SharedFontDirectory 3 index known
-				{ SharedFontDirectory 3 index get /FontReferenced known }
-				{ false }
-			ifelse
-			}
-		ifelse
-		}
-	ifelse
-	dup
-		{
-		3 index findfont /FontReferenced get
-		2 index dup type /nametype eq
-			{findfont}
-		if ne
-			{ pop false }
-		if
-		}
-	if
-		{
-		pop
-		1 index findfont
-		/Encoding get exch
-		0 1 255
-			{ 2 copy get 3 index 3 1 roll put }
-		for
-		pop pop pop
-		}
-		{
-		dup type /nametype eq
-		  { findfont }
-	  if
-		dup dup maxlength 2 add dict
-			begin
-			exch
-				{
-				1 index /FID ne
-					{def}
-					{pop pop}
-				ifelse
-				}
-			forall
-			/FontReferenced exch def
-			/Encoding exch dup length array copy def
-			/FontName 1 index dup type /stringtype eq { cvn } if def dup
-			currentdict
-			end
-		definefont def
-		}
-	ifelse
-	} bind def
-/SetSubstituteStrategy
-	{
-	$SubstituteFont
-		begin
-		dup type /dicttype ne
-			{ 0 dict }
-		if
-		currentdict /$Strategies known
-			{
-			exch $Strategies exch
-			2 copy known
-				{
-				get
-				2 copy maxlength exch maxlength add dict
-					begin
-					{ def } forall
-					{ def } forall
-					currentdict
-					dup /$Init known
-						{ dup /$Init get exec }
-					if
-					end
-				/$Strategy exch def
-				}
-				{ pop pop pop }
-			ifelse
-			}
-			{ pop pop }
-		ifelse
-		end
-	} bind def
-/scff
-	{
-	$SubstituteFont
-		begin
-		dup type /stringtype eq
-			{ dup length exch }
-			{ null }
-		ifelse
-		/$sname exch def
-		/$slen exch def
-		/$inVMIndex
-			$sname null eq
-				{
-				1 index $str cvs
-				dup length $slen sub $slen getinterval cvn
-				}
-				{ $sname }
-			ifelse def
-		end
-		{ findfont }
-	@Stopped
-		{
-		dup length 8 add string exch
-		1 index 0 (BadFont:) putinterval
-		1 index exch 8 exch dup length string cvs putinterval cvn
-			{ findfont }
-		@Stopped
-			{ pop /Courier findfont }
-		if
-		}
-	if
-	$SubstituteFont
-		begin
-		/$sname null def
-		/$slen 0 def
-		/$inVMIndex null def
-		end
-	} bind def
-/isWidthsOnlyFont
-	{
-	dup /WidthsOnly known
-		{ pop pop true }
-		{
-		dup /FDepVector known
-			{ /FDepVector get { isWidthsOnlyFont dup { exit } if } forall }
-			{
-			dup /FDArray known
-				{ /FDArray get { isWidthsOnlyFont dup { exit } if } forall }
-				{ pop }
-			ifelse
-			}
-		ifelse
-		}
-	ifelse
-	} bind def
-/?str1 256 string def
-/?set
-	{
-	$SubstituteFont
-		begin
-		/$substituteFound false def
-		/$fontname 4 index def
-		/$doSmartSub false def
-		end
-	3 index
-	currentglobal false setglobal exch
-	/CompatibleFonts /ProcSet resourcestatus
-		{
-		pop pop
-		/CompatibleFonts /ProcSet findresource
-			begin
-			dup /CompatibleFont currentexception
-			1 index /CompatibleFont true setexception
-			1 index /Font resourcestatus
-				{
-				pop pop
-				3 2 roll setglobal
-				end
-				exch
-				dup findfont
-				/CompatibleFonts /ProcSet findresource
-					begin
-					3 1 roll exch /CompatibleFont exch setexception
-					end
-				}
-				{
-				3 2 roll setglobal
-				1 index exch /CompatibleFont exch setexception
-				end
-				findfont
-				$SubstituteFont /$substituteFound true put
-				}
-			ifelse
-		}
-		{ exch setglobal findfont }
-	ifelse
-	$SubstituteFont
-		begin
-		$substituteFound
-			{
-		 false
-		 (%%[Using embedded font ) print
-		 5 index ?str1 cvs print
-		 ( to avoid the font substitution problem noted earlier.]%%\n) print
-		 }
-			{
-			dup /FontName known
-				{
-				dup /FontName get $fontname eq
-				1 index /DistillerFauxFont known not and
-				/currentdistillerparams where
-					{ pop false 2 index isWidthsOnlyFont not and }
-				if
-				}
-				{ false }
-			ifelse
-			}
-		ifelse
-		exch pop
-		/$doSmartSub true def
-		end
-		{
-		exch pop exch pop exch
-		2 dict dup /Found 3 index put
-		exch findfont exch
-		}
-		{
-		exch exec
-		exch dup findfont
-		dup /FontType get 3 eq
-	  {
-		  exch ?str1 cvs
-		  dup length 1 sub
-		  -1 0
-		{
-			  exch dup 2 index get 42 eq
-			{
-				 exch 0 exch getinterval cvn 4 1 roll 3 2 roll pop
-				 exit
-			  }
-			  {exch pop} ifelse
-		  }for
-		}
-		{
-		 exch pop
-	  } ifelse
-		2 dict dup /Downloaded 6 5 roll put
-		}
-	ifelse
-	dup /FontName 4 index put copyfont definefont pop
-	} bind def
-/?str2 256 string def
-/?add
-	{
-	1 index type /integertype eq
-		{ exch true 4 2 }
-		{ false 3 1 }
-	ifelse
-	roll
-	1 index findfont
-	dup /Widths known
-		{
-		Adobe_CoolType_Data /AddWidths? true put
-		gsave dup 1000 scalefont setfont
-		}
-	if
-	/Downloaded known
-		{
-		exec
-		exch
-			{
-			exch ?str2 cvs exch
-			findfont /Downloaded get 1 dict begin /Downloaded 1 index def ?str1 cvs length
-			?str1 1 index 1 add 3 index putinterval
-			exch length 1 add 1 index add
-			?str1 2 index (*) putinterval
-			?str1 0 2 index getinterval cvn findfont
-			?str1 3 index (+) putinterval
-			2 dict dup /FontName ?str1 0 6 index getinterval cvn put
-			dup /Downloaded Downloaded put end copyfont
-			dup /FontName get exch definefont pop pop pop
-			}
-			{
-			pop
-			}
-		ifelse
-		}
-		{
-		pop
-		exch
-			{
-			findfont
-			dup /Found get
-			dup length exch ?str1 cvs pop
-			?str1 1 index (+) putinterval
-			?str1 1 index 1 add 4 index ?str2 cvs putinterval
-			?str1 exch 0 exch 5 4 roll ?str2 cvs length 1 add add getinterval cvn
-			1 dict exch 1 index exch /FontName exch put copyfont
-			dup /FontName get exch definefont pop
-			}
-			{
-			pop
-			}
-		ifelse
-		}
-	ifelse
-	Adobe_CoolType_Data /AddWidths? get
-		{ grestore Adobe_CoolType_Data /AddWidths? false put }
-	if
-	} bind def
-/?sh
-	{
-	currentfont /Downloaded known { exch } if pop
-	} bind def
-/?chp
-	{
-	currentfont /Downloaded known { pop } { false chp } ifelse
-	} bind def
-/?mv
-	{
-	currentfont /Downloaded known { moveto pop pop } { pop pop moveto } ifelse
-	} bind def
-setpacking
-userdict /$SubstituteFont 25 dict put
-1 dict
-	begin
-	/SubstituteFont
-		dup $error exch 2 copy known
-			{ get }
-			{ pop pop { pop /Courier } bind }
-		ifelse def
-	/currentdistillerparams where dup
-		{
-		pop pop
-		currentdistillerparams /CannotEmbedFontPolicy 2 copy known
-			{ get /Error eq }
-			{ pop pop false }
-		ifelse
-		}
-	if not
-		{
-		countdictstack array dictstack 0 get
-			begin
-			userdict
-				begin
-				$SubstituteFont
-					begin
-					/$str 128 string def
-					/$fontpat 128 string def
-					/$slen 0 def
-					/$sname null def
-					/$match false def
-					/$fontname null def
-					/$substituteFound false def
-					/$inVMIndex null def
-					/$doSmartSub true def
-					/$depth 0 def
-					/$fontname null def
-					/$italicangle 26.5 def
-					/$dstack null def
-					/$Strategies 10 dict dup
-						begin
-						/$Type3Underprint
-							{
-							currentglobal exch false setglobal
-							11 dict
-								begin
-								/UseFont exch
-									$WMode 0 ne
-										{
-										dup length dict copy
-										dup /WMode $WMode put
-										/UseFont exch definefont
-										}
-									if def
-								/FontName $fontname dup type /stringtype eq { cvn } if def
-								/FontType 3 def
-								/FontMatrix [ .001 0 0 .001 0 0 ] def
-								/Encoding 256 array dup 0 1 255 { /.notdef put dup } for pop def
-								/FontBBox [ 0 0 0 0 ] def
-								/CCInfo 7 dict dup
-									begin
-									/cc null def
-									/x 0 def
-									/y 0 def
-									end def
-								/BuildChar
-									{
-									exch
-										begin
-										CCInfo
-											begin
-											1 string dup 0 3 index put exch pop
-											/cc exch def
-											UseFont 1000 scalefont setfont
-											cc stringwidth /y exch def /x exch def
-											x y setcharwidth
-											$SubstituteFont /$Strategy get /$Underprint get exec
-											0 0 moveto cc show
-											x y moveto
-											end
-										end
-									} bind def
-								currentdict
-								end
-							exch setglobal
-							} bind def
-						/$GetaTint
-							2 dict dup
-								begin
-								/$BuildFont
-									{
-									dup /WMode known
-										{ dup /WMode get }
-										{ 0 }
-									ifelse
-									/$WMode exch def
-									$fontname exch
-									dup /FontName known
-										{
-										dup /FontName get
-										dup type /stringtype eq { cvn } if
-										}
-										{ /unnamedfont }
-									ifelse
-									exch
-									Adobe_CoolType_Data /InVMDeepCopiedFonts get
-									1 index /FontName get known
-										{
-										pop
-										Adobe_CoolType_Data /InVMDeepCopiedFonts get
-										1 index get
-										null copyfont
-										}
-										{ $deepcopyfont }
-									ifelse
-									exch 1 index exch /FontBasedOn exch put
-									dup /FontName $fontname dup type /stringtype eq { cvn } if put
-									definefont
-									Adobe_CoolType_Data /InVMDeepCopiedFonts get
-										begin
-										dup /FontBasedOn get 1 index def
-										end
-									} bind def
-								/$Underprint
-									{
-									gsave
-									x abs y abs gt
-										{ /y 1000 def }
-										{ /x -1000 def 500 120 translate }
-									ifelse
-									Level2?
-										{
-										[ /Separation (All) /DeviceCMYK { 0 0 0 1 pop } ]
-										setcolorspace
-										}
-										{ 0 setgray }
-									ifelse
-									10 setlinewidth
-									x .8 mul
-									[ 7 3 ]
-										{
-										y mul 8 div 120 sub x 10 div exch moveto
-										0 y 4 div neg rlineto
-										dup 0 rlineto
-										0 y 4 div rlineto
-										closepath
-										gsave
-										Level2?
-											{ .2 setcolor }
-											{ .8 setgray }
-										ifelse
-										fill grestore
-										stroke
-										}
-									forall
-									pop
-									grestore
-									} bind def
-								end def
-						/$Oblique
-							1 dict dup
-								begin
-								/$BuildFont
-									{
-									currentglobal exch dup gcheck setglobal
-									null copyfont
-										begin
-										/FontBasedOn
-										currentdict /FontName known
-											{
-											FontName
-											dup type /stringtype eq { cvn } if
-											}
-											{ /unnamedfont }
-										ifelse
-										def
-										/FontName $fontname dup type /stringtype eq { cvn } if def
-										/currentdistillerparams where
-											{ pop }
-											{
-											/FontInfo currentdict /FontInfo known
-												{ FontInfo null copyfont }
-												{ 2 dict }
-											ifelse
-											dup
-												begin
-												/ItalicAngle $italicangle def
-												/FontMatrix FontMatrix
-												[ 1 0 ItalicAngle dup sin exch cos div 1 0 0 ]
-												matrix concatmatrix readonly
-												end
-											4 2 roll def
-											def
-											}
-										ifelse
-										FontName currentdict
-										end
-									definefont
-									exch setglobal
-									} bind def
-								end def
-						/$None
-							1 dict dup
-								begin
-								/$BuildFont {} bind def
-								end def
-						end def
-					/$Oblique SetSubstituteStrategy
-					/$findfontByEnum
-						{
-						dup type /stringtype eq { cvn } if
-						dup /$fontname exch def
-						$sname null eq
-							{ $str cvs dup length $slen sub $slen getinterval }
-							{ pop $sname }
-						ifelse
-						$fontpat dup 0 (fonts/*) putinterval exch 7 exch putinterval
-						/$match false def
-						$SubstituteFont /$dstack countdictstack array dictstack put
-						mark
-							{
-							$fontpat 0 $slen 7 add getinterval
-								{ /$match exch def exit }
-							$str filenameforall
-							}
-						stopped
-							{
-							cleardictstack
-							currentdict
-							true
-							$SubstituteFont /$dstack get
-								{
-								exch
-									{
-									1 index eq
-										{ pop false }
-										{ true }
-									ifelse
-									}
-									{ begin false }
-								ifelse
-								}
-							forall
-							pop
-							}
-						if
-						cleartomark
-						/$slen 0 def
-						$match false ne
-							{ $match (fonts/) anchorsearch pop pop cvn }
-							{ /Courier }
-						ifelse
-						} bind def
-					/$ROS 1 dict dup
-						begin
-						/Adobe 4 dict dup
-							begin
-							/Japan1  [ /Ryumin-Light /HeiseiMin-W3
-										  /GothicBBB-Medium /HeiseiKakuGo-W5
-										  /HeiseiMaruGo-W4 /Jun101-Light ] def
-							/Korea1  [ /HYSMyeongJo-Medium /HYGoThic-Medium ] def
-							/GB1	  [ /STSong-Light /STHeiti-Regular ] def
-							/CNS1	 [ /MKai-Medium /MHei-Medium ] def
-							end def
-						end def
-					/$cmapname null def
-					/$deepcopyfont
-						{
-						dup /FontType get 0 eq
-							{
-							1 dict dup /FontName /copied put copyfont
-								begin
-								/FDepVector FDepVector copyarray
-								0 1 2 index length 1 sub
-									{
-									2 copy get $deepcopyfont
-									dup /FontName /copied put
-									/copied exch definefont
-									3 copy put pop pop
-									}
-								for
-								def
-								currentdict
-								end
-							}
-							{ $Strategies /$Type3Underprint get exec }
-						ifelse
-						} bind def
-					/$buildfontname
-						{
-						dup /CIDFont findresource /CIDSystemInfo get
-							begin
-							Registry length Ordering length Supplement 8 string cvs
-							3 copy length 2 add add add string
-							dup 5 1 roll dup 0 Registry putinterval
-							dup 4 index (-) putinterval
-							dup 4 index 1 add Ordering putinterval
-							4 2 roll add 1 add 2 copy (-) putinterval
-							end
-						1 add 2 copy 0 exch getinterval $cmapname $fontpat cvs exch
-						anchorsearch
-							{ pop pop 3 2 roll putinterval cvn /$cmapname exch def }
-							{ pop pop pop pop pop }
-						ifelse
-						length
-						$str 1 index (-) putinterval 1 add
-						$str 1 index $cmapname $fontpat cvs putinterval
-						$cmapname length add
-						$str exch 0 exch getinterval cvn
-						} bind def
-					/$findfontByROS
-						{
-						/$fontname exch def
-						$ROS Registry 2 copy known
-							{
-							get Ordering 2 copy known
-								{ get }
-								{ pop pop [] }
-							ifelse
-							}
-							{ pop pop [] }
-						ifelse
-						false exch
-							{
-							dup /CIDFont resourcestatus
-								{
-								pop pop
-								save
-								1 index /CIDFont findresource
-								dup /WidthsOnly known
-									{ dup /WidthsOnly get }
-									{ false }
-								ifelse
-								exch pop
-								exch restore
-									{ pop }
-									{ exch pop true exit }
-								ifelse
-								}
-								{ pop }
-							ifelse
-							}
-						forall
-							{ $str cvs $buildfontname }
-							{
-							false (*)
-								{
-								save exch
-								dup /CIDFont findresource
-								dup /WidthsOnly known
-									{ dup /WidthsOnly get not }
-									{ true }
-								ifelse
-								exch /CIDSystemInfo get
-								dup /Registry get Registry eq
-								exch /Ordering get Ordering eq and and
-									{ exch restore exch pop true exit }
-									{ pop restore }
-								ifelse
-								}
-							$str /CIDFont resourceforall
-								{ $buildfontname }
-								{ $fontname $findfontByEnum }
-							ifelse
-							}
-						ifelse
-						} bind def
-					end
-				end
-				currentdict /$error known currentdict /languagelevel known and dup
-					{ pop $error /SubstituteFont known }
-				if
-				dup
-					{ $error }
-					{ Adobe_CoolType_Core }
-				ifelse
-				begin
-					{
-					/SubstituteFont
-					/CMap /Category resourcestatus
-						{
-						pop pop
-						{
-						$SubstituteFont
-							begin
-							/$substituteFound true def
-							dup length $slen gt
-							$sname null ne or
-							$slen 0 gt and
-								{
-								$sname null eq
-									{ dup $str cvs dup length $slen sub $slen getinterval cvn }
-									{ $sname }
-								ifelse
-								Adobe_CoolType_Data /InVMFontsByCMap get
-								1 index 2 copy known
-									{
-									get
-									false exch
-										{
-										pop
-										currentglobal
-											{
-											GlobalFontDirectory 1 index known
-												{ exch pop true exit }
-												{ pop }
-											ifelse
-											}
-											{
-											FontDirectory 1 index known
-												{ exch pop true exit }
-												{
-												GlobalFontDirectory 1 index known
-													{ exch pop true exit }
-													{ pop }
-												ifelse
-												}
-											ifelse
-											}
-										ifelse
-										}
-									forall
-									}
-									{ pop pop false }
-								ifelse
-									{
-									exch pop exch pop
-									}
-									{
-									dup /CMap resourcestatus
-										{
-										pop pop
-										dup /$cmapname exch def
-										/CMap findresource /CIDSystemInfo get { def } forall
-										$findfontByROS
-										}
-										{
-										128 string cvs
-										dup (-) search
-											{
-											3 1 roll search
-												{
-												3 1 roll pop
-													{ dup cvi }
-												stopped
-													{ pop pop pop pop pop $findfontByEnum }
-													{
-													4 2 roll pop pop
-													exch length
-													exch
-													2 index length
-													2 index
-													sub
-													exch 1 sub -1 0
-														{
-														$str cvs dup length
-														4 index
-														0
-														4 index
-														4 3 roll add
-														getinterval
-														exch 1 index exch 3 index exch
-														putinterval
-														dup /CMap resourcestatus
-															{
-															pop pop
-															4 1 roll pop pop pop
-															dup /$cmapname exch def
-															/CMap findresource /CIDSystemInfo get { def } forall
-															$findfontByROS
-															true exit
-															}
-															{ pop }
-														ifelse
-														}
-													for
-													dup type /booleantype eq
-														{ pop }
-														{ pop pop pop $findfontByEnum }
-													ifelse
-													}
-												ifelse
-												}
-												{ pop pop pop $findfontByEnum }
-											ifelse
-											}
-											{ pop pop $findfontByEnum }
-										ifelse
-										}
-									ifelse
-									}
-								ifelse
-								}
-								{ //SubstituteFont exec }
-							ifelse
-							/$slen 0 def
-							end
-						}
-						}
-						{
-						{
-						$SubstituteFont
-							begin
-							/$substituteFound true def
-							dup length $slen gt
-							$sname null ne or
-							$slen 0 gt and
-								{ $findfontByEnum }
-								{ //SubstituteFont exec }
-							ifelse
-							end
-						}
-						}
-					ifelse
-					bind readonly def
-					Adobe_CoolType_Core /scfindfont /systemfindfont load put
-					}
-					{
-					/scfindfont
-						{
-						$SubstituteFont
-							begin
-							dup systemfindfont
-							dup /FontName known
-								{ dup /FontName get dup 3 index ne }
-								{ /noname true }
-							ifelse
-							dup
-								{
-								/$origfontnamefound 2 index def
-								/$origfontname 4 index def /$substituteFound true def
-								}
-							if
-							exch pop
-								{
-								$slen 0 gt
-								$sname null ne
-								3 index length $slen gt or and
-									{
-									pop dup $findfontByEnum findfont
-									dup maxlength 1 add dict
-										begin
-											{ 1 index /FID eq { pop pop } { def } ifelse }
-										forall
-										currentdict
-										end
-									definefont
-									dup /FontName known { dup /FontName get } { null } ifelse
-									$origfontnamefound ne
-										{
-										$origfontname $str cvs print
-										( substitution revised, using ) print
-										dup /FontName known
-											{ dup /FontName get } { (unspecified font) }
-										ifelse
-										$str cvs print (.\n) print
-										}
-									if
-									}
-									{ exch pop }
-								ifelse
-								}
-								{ exch pop }
-							ifelse
-							end
-						} bind def
-					}
-				ifelse
-				end
-			end
-		Adobe_CoolType_Core_Defined not
-			{
-			Adobe_CoolType_Core /findfont
-				{
-				$SubstituteFont
-					begin
-					$depth 0 eq
-						{
-						/$fontname 1 index dup type /stringtype ne { $str cvs } if def
-						/$substituteFound false def
-						}
-					if
-					/$depth $depth 1 add def
-					end
-				scfindfont
-				$SubstituteFont
-					begin
-					/$depth $depth 1 sub def
-					$substituteFound $depth 0 eq and
-						{
-						$inVMIndex null ne
-							{ dup $inVMIndex $AddInVMFont }
-						if
-						$doSmartSub
-							{
-							currentdict /$Strategy known
-								{ $Strategy /$BuildFont get exec }
-							if
-							}
-						if
-						}
-					if
-					end
-				} bind put
-			}
-		if
-		}
-	if
-	end
-/$AddInVMFont
-	{
-	exch /FontName 2 copy known
-		{
-		get
-		1 dict dup begin exch 1 index gcheck def end exch
-		Adobe_CoolType_Data /InVMFontsByCMap get exch
-		$DictAdd
-		}
-		{ pop pop pop }
-	ifelse
-	} bind def
-/$DictAdd
-	{
-	2 copy known not
-		{ 2 copy 4 index length dict put }
-	if
-	Level2? not
-		{
-		2 copy get dup maxlength exch length 4 index length add lt
-		2 copy get dup length 4 index length add exch maxlength 1 index lt
-			{
-			2 mul dict
-				begin
-				2 copy get { forall } def
-				2 copy currentdict put
-				end
-			}
-			{ pop }
-		ifelse
-		}
-	if
-	get
-		begin
-			{ def }
-		forall
-		end
-	} bind def
-end
-end
-%%EndResource
-%%BeginResource: procset Adobe_CoolType_Utility_MAKEOCF 1.19 0
-%%Copyright: Copyright 1987-2003 Adobe Systems Incorporated.
-%%Version: 1.19 0
-systemdict /languagelevel known dup
-	{ currentglobal false setglobal }
-	{ false }
-ifelse
-exch
-userdict /Adobe_CoolType_Utility 2 copy known
-	{ 2 copy get dup maxlength 25 add dict copy }
-	{ 25 dict }
-ifelse put
-Adobe_CoolType_Utility
-	begin
-	/ct_Level2? exch def
-	/ct_Clone? 1183615869 internaldict dup
-			/CCRun known not
-			exch /eCCRun known not
-			ct_Level2? and or def
-ct_Level2?
-	{ globaldict begin currentglobal true setglobal }
-if
-	/ct_AddStdCIDMap
-		ct_Level2?
-			{ {
-			((Hex) 57 StartData
-			0615 1e27 2c39 1c60 d8a8 cc31 fe2b f6e0
-			7aa3 e541 e21c 60d8 a8c9 c3d0 6d9e 1c60
-			d8a8 c9c2 02d7 9a1c 60d8 a849 1c60 d8a8
-			cc36 74f4 1144 b13b 77) 0 () /SubFileDecode filter cvx exec
-			} }
-			{ {
-			<BAB431EA07F209EB8C4348311481D9D3F76E3D15246555577D87BC510ED54E
-		 118C39697FA9F6DB58128E60EB8A12FA24D7CDD2FA94D221FA9EC8DA3E5E6A1C
-			4ACECC8C2D39C54E7C946031DD156C3A6B4A09AD29E1867A> eexec
-			} }
-		ifelse bind def
-userdict /cid_extensions known
-dup { cid_extensions /cid_UpdateDB known and } if
-	 {
-	 cid_extensions
-	 begin
-	 /cid_GetCIDSystemInfo
-		 {
-		 1 index type /stringtype eq
-			 { exch cvn exch }
-		 if
-		 cid_extensions
-			 begin
-			 dup load 2 index known
-				 {
-				 2 copy
-				 cid_GetStatusInfo
-				 dup null ne
-					 {
-					 1 index load
-					 3 index get
-					 dup null eq
-						  { pop pop cid_UpdateDB }
-						  {
-						  exch
-						  1 index /Created get eq
-							  { exch pop exch pop }
-							  { pop cid_UpdateDB }
-						  ifelse
-						  }
-					 ifelse
-					 }
-					 { pop cid_UpdateDB }
-				 ifelse
-				 }
-				 { cid_UpdateDB }
-			 ifelse
-			 end
-		 } bind def
-	 end
-	 }
-if
-ct_Level2?
-	{ end setglobal }
-if
-	/ct_UseNativeCapability?  systemdict /composefont known def
-	/ct_MakeOCF 35 dict def
-	/ct_Vars 25 dict def
-	/ct_GlyphDirProcs 6 dict def
-	/ct_BuildCharDict 15 dict dup
-		begin
-		/charcode 2 string def
-		/dst_string 1500 string def
-		/nullstring () def
-		/usewidths? true def
-		end def
-	ct_Level2? { setglobal } { pop } ifelse
-	ct_GlyphDirProcs
-		begin
-		/GetGlyphDirectory
-			{
-			systemdict /languagelevel known
-				{ pop /CIDFont findresource /GlyphDirectory get }
-				{
-				1 index /CIDFont findresource /GlyphDirectory
-				get dup type /dicttype eq
-					{
-					dup dup maxlength exch length sub 2 index lt
-						{
-						dup length 2 index add dict copy 2 index
-						/CIDFont findresource/GlyphDirectory 2 index put
-						}
-					if
-					}
-				if
-				exch pop exch pop
-				}
-			ifelse
-			+
-			} def
-		/+
-			{
-			systemdict /languagelevel known
-				{
-				currentglobal false setglobal
-				3 dict begin
-					/vm exch def
-				}
-				{ 1 dict begin }
-			ifelse
-			/$ exch def
-			systemdict /languagelevel known
-				{
-				vm setglobal
-				/gvm currentglobal def
-				$ gcheck setglobal
-				}
-			if
-			? { $ begin } if
-			} def
-		/? { $ type /dicttype eq } def
-		/| {
-			userdict /Adobe_CoolType_Data known
-				{
-			Adobe_CoolType_Data /AddWidths? known
-				{
-				 currentdict Adobe_CoolType_Data
-					begin
-					  begin
-						AddWidths?
-								{
-								Adobe_CoolType_Data /CC 3 index put
-								? { def } { $ 3 1 roll put } ifelse
-								CC charcode exch 1 index 0 2 index 256 idiv put
-								1 index exch 1 exch 256 mod put
-								stringwidth 2 array astore
-								currentfont /Widths get exch CC exch put
-								}
-								{ ? { def } { $ 3 1 roll put } ifelse }
-							ifelse
-					end
-				end
-				}
-				{ ? { def } { $ 3 1 roll put } ifelse }	ifelse
-				}
-				{ ? { def } { $ 3 1 roll put } ifelse }
-			ifelse
-			} def
-		/!
-			{
-			? { end } if
-			systemdict /languagelevel known
-				{ gvm setglobal }
-			if
-			end
-			} def
-		/: { string currentfile exch readstring pop } executeonly def
-		end
-	ct_MakeOCF
-		begin
-		/ct_cHexEncoding
-		[/c00/c01/c02/c03/c04/c05/c06/c07/c08/c09/c0A/c0B/c0C/c0D/c0E/c0F/c10/c11/c12
-		 /c13/c14/c15/c16/c17/c18/c19/c1A/c1B/c1C/c1D/c1E/c1F/c20/c21/c22/c23/c24/c25
-		 /c26/c27/c28/c29/c2A/c2B/c2C/c2D/c2E/c2F/c30/c31/c32/c33/c34/c35/c36/c37/c38
-		 /c39/c3A/c3B/c3C/c3D/c3E/c3F/c40/c41/c42/c43/c44/c45/c46/c47/c48/c49/c4A/c4B
-		 /c4C/c4D/c4E/c4F/c50/c51/c52/c53/c54/c55/c56/c57/c58/c59/c5A/c5B/c5C/c5D/c5E
-		 /c5F/c60/c61/c62/c63/c64/c65/c66/c67/c68/c69/c6A/c6B/c6C/c6D/c6E/c6F/c70/c71
-		 /c72/c73/c74/c75/c76/c77/c78/c79/c7A/c7B/c7C/c7D/c7E/c7F/c80/c81/c82/c83/c84
-		 /c85/c86/c87/c88/c89/c8A/c8B/c8C/c8D/c8E/c8F/c90/c91/c92/c93/c94/c95/c96/c97
-		 /c98/c99/c9A/c9B/c9C/c9D/c9E/c9F/cA0/cA1/cA2/cA3/cA4/cA5/cA6/cA7/cA8/cA9/cAA
-		 /cAB/cAC/cAD/cAE/cAF/cB0/cB1/cB2/cB3/cB4/cB5/cB6/cB7/cB8/cB9/cBA/cBB/cBC/cBD
-		 /cBE/cBF/cC0/cC1/cC2/cC3/cC4/cC5/cC6/cC7/cC8/cC9/cCA/cCB/cCC/cCD/cCE/cCF/cD0
-		 /cD1/cD2/cD3/cD4/cD5/cD6/cD7/cD8/cD9/cDA/cDB/cDC/cDD/cDE/cDF/cE0/cE1/cE2/cE3
-		 /cE4/cE5/cE6/cE7/cE8/cE9/cEA/cEB/cEC/cED/cEE/cEF/cF0/cF1/cF2/cF3/cF4/cF5/cF6
-		 /cF7/cF8/cF9/cFA/cFB/cFC/cFD/cFE/cFF] def
-		/ct_CID_STR_SIZE 8000 def
-		/ct_mkocfStr100 100 string def
-		/ct_defaultFontMtx [.001 0 0 .001 0 0] def
-		/ct_1000Mtx [1000 0 0 1000 0 0] def
-		/ct_raise {exch cvx exch errordict exch get exec stop} bind def
-		/ct_reraise
-			{ cvx $error /errorname get (Error: ) print dup (						  ) cvs print
-					errordict exch get exec stop
-			} bind def
-		/ct_cvnsi
-			{
-			1 index add 1 sub 1 exch 0 4 1 roll
-				{
-				2 index exch get
-				exch 8 bitshift
-				add
-				}
-			for
-			exch pop
-			} bind def
-		/ct_GetInterval
-			{
-			Adobe_CoolType_Utility /ct_BuildCharDict get
-				begin
-				/dst_index 0 def
-				dup dst_string length gt
-					{ dup string /dst_string exch def }
-				if
-				1 index ct_CID_STR_SIZE idiv
-				/arrayIndex exch def
-				2 index arrayIndex  get
-				2 index
-				arrayIndex ct_CID_STR_SIZE mul
-				sub
-					{
-					dup 3 index add 2 index length le
-						{
-						2 index getinterval
-						dst_string  dst_index 2 index putinterval
-						length dst_index add /dst_index exch def
-						exit
-						}
-						{
-						1 index length 1 index sub
-						dup 4 1 roll
-						getinterval
-						dst_string  dst_index 2 index putinterval
-						pop dup dst_index add /dst_index exch def
-						sub
-						/arrayIndex arrayIndex 1 add def
-						2 index dup length arrayIndex gt
-							  { arrayIndex get }
-							  {
-							  pop
-							  exit
-							  }
-						ifelse
-						0
-						}
-					ifelse
-					}
-				loop
-				pop pop pop
-				dst_string 0 dst_index getinterval
-				end
-			} bind def
-		ct_Level2?
-			{
-			/ct_resourcestatus
-			currentglobal mark true setglobal
-				{ /unknowninstancename /Category resourcestatus }
-			stopped
-				{ cleartomark setglobal true }
-				{ cleartomark currentglobal not exch setglobal }
-			ifelse
-				{
-					{
-					mark 3 1 roll /Category findresource
-						begin
-						ct_Vars /vm currentglobal put
-						({ResourceStatus} stopped) 0 () /SubFileDecode filter cvx exec
-							{ cleartomark false }
-							{ { 3 2 roll pop true } { cleartomark false } ifelse }
-						ifelse
-						ct_Vars /vm get setglobal
-						end
-					}
-				}
-				{ { resourcestatus } }
-			ifelse bind def
-			/CIDFont /Category ct_resourcestatus
-				{ pop pop }
-				{
-				currentglobal  true setglobal
-				/Generic /Category findresource
-				dup length dict copy
-				dup /InstanceType /dicttype put
-				/CIDFont exch /Category defineresource pop
-				setglobal
-				}
-			ifelse
-			ct_UseNativeCapability?
-				{
-				/CIDInit /ProcSet findresource begin
-				12 dict begin
-				begincmap
-				/CIDSystemInfo 3 dict dup begin
-				  /Registry (Adobe) def
-				  /Ordering (Identity) def
-				  /Supplement 0 def
-				end def
-				/CMapName /Identity-H def
-				/CMapVersion 1.000 def
-				/CMapType 1 def
-				1 begincodespacerange
-				<0000> <FFFF>
-				endcodespacerange
-				1 begincidrange
-				<0000> <FFFF> 0
-				endcidrange
-				endcmap
-				CMapName currentdict /CMap defineresource pop
-				end
-				end
-				}
-			if
-			}
-			{
-			/ct_Category 2 dict begin
-			/CIDFont  10 dict def
-			/ProcSet	2 dict def
-			currentdict
-			end
-			def
-			/defineresource
-				{
-				ct_Category 1 index 2 copy known
-					{
-					get
-					dup dup maxlength exch length eq
-						{
-						dup length 10 add dict copy
-						ct_Category 2 index 2 index put
-						}
-					if
-					3 index 3 index put
-					pop exch pop
-					}
-					{ pop pop /defineresource /undefined ct_raise }
-				ifelse
-				} bind def
-			/findresource
-				{
-				ct_Category 1 index 2 copy known
-					{
-					get
-					2 index 2 copy known
-						{ get 3 1 roll pop pop}
-						{ pop pop /findresource /undefinedresource ct_raise }
-					ifelse
-					}
-					{ pop pop /findresource /undefined ct_raise }
-				ifelse
-				} bind def
-			/resourcestatus
-				{
-				ct_Category 1 index 2 copy known
-					{
-					get
-					2 index known
-					exch pop exch pop
-						{
-						0 -1 true
-						}
-						{
-						false
-						}
-					ifelse
-					}
-					{ pop pop /findresource /undefined ct_raise }
-				ifelse
-				} bind def
-			/ct_resourcestatus /resourcestatus load def
-			}
-		ifelse
-		/ct_CIDInit 2 dict
-			begin
-			/ct_cidfont_stream_init
-				{
-					{
-					dup (Binary) eq
-						{
-						pop
-						null
-						currentfile
-						ct_Level2?
-							{
-								{ cid_BYTE_COUNT () /SubFileDecode filter }
-							stopped
-								{ pop pop pop }
-							if
-							}
-						if
-						/readstring load
-						exit
-						}
-					if
-					dup (Hex) eq
-						{
-						pop
-						currentfile
-						ct_Level2?
-							{
-								{ null exch /ASCIIHexDecode filter /readstring }
-							stopped
-								{ pop exch pop (>) exch /readhexstring }
-							if
-							}
-							{ (>) exch /readhexstring }
-						ifelse
-						load
-						exit
-						}
-					if
-					/StartData /typecheck ct_raise
-					}
-				loop
-				cid_BYTE_COUNT ct_CID_STR_SIZE le
-					{
-					2 copy cid_BYTE_COUNT string exch exec
-					pop
-					1 array dup
-					3 -1 roll
-					0 exch put
-					}
-					{
-					cid_BYTE_COUNT ct_CID_STR_SIZE div ceiling cvi
-					dup array exch 2 sub 0 exch 1 exch
-						{
-						2 copy
-						5 index
-						ct_CID_STR_SIZE
-						string
-						6 index exec
-						pop
-						put
-						pop
-						}
-					for
-					2 index
-					cid_BYTE_COUNT ct_CID_STR_SIZE mod string
-					3 index exec
-					pop
-					1 index exch
-					1 index length 1 sub
-					exch put
-					}
-				ifelse
-				cid_CIDFONT exch /GlyphData exch put
-				2 index null eq
-					{
-					pop pop pop
-					}
-					{
-					pop /readstring load
-					1 string exch
-						{
-						3 copy exec
-						pop
-						dup length 0 eq
-							{
-							pop pop pop pop pop
-							true exit
-							}
-						if
-						4 index
-						eq
-							{
-							pop pop pop pop
-							false exit
-							}
-						if
-						}
-					loop
-					pop
-					}
-				ifelse
-				} bind def
-			/StartData
-				{
-				mark
-					{
-					currentdict
-					dup /FDArray get 0 get /FontMatrix get
-					0 get 0.001 eq
-						{
-						dup /CDevProc known not
-							{
-							/CDevProc 1183615869 internaldict /stdCDevProc 2 copy known
-								{ get }
-								{
-								pop pop
-								{ pop pop pop pop pop 0 -1000 7 index 2 div 880 }
-								}
-							ifelse
-							def
-							}
-						if
-						}
-						{
-						 /CDevProc
-							 {
-							 pop pop pop pop pop
-							 0
-							 1 cid_temp /cid_CIDFONT get
-							 /FDArray get 0 get
-							 /FontMatrix get 0 get div
-							 7 index 2 div
-							 1 index 0.88 mul
-							 } def
-						}
-					ifelse
-					/cid_temp 15 dict def
-					cid_temp
-						begin
-						/cid_CIDFONT exch def
-						3 copy pop
-						dup /cid_BYTE_COUNT exch def 0 gt
-							{
-							ct_cidfont_stream_init
-							FDArray
-								{
-								/Private get
-								dup /SubrMapOffset known
-									{
-									begin
-									/Subrs SubrCount array def
-									Subrs
-									SubrMapOffset
-									SubrCount
-									SDBytes
-									ct_Level2?
-										{
-										currentdict dup /SubrMapOffset undef
-										dup /SubrCount undef
-										/SDBytes undef
-										}
-									if
-									end
-									/cid_SD_BYTES exch def
-									/cid_SUBR_COUNT exch def
-									/cid_SUBR_MAP_OFFSET exch def
-									/cid_SUBRS exch def
-									cid_SUBR_COUNT 0 gt
-										{
-										GlyphData cid_SUBR_MAP_OFFSET cid_SD_BYTES ct_GetInterval
-										0 cid_SD_BYTES ct_cvnsi
-										0 1 cid_SUBR_COUNT 1 sub
-											{
-											exch 1 index
-											1 add
-											cid_SD_BYTES mul cid_SUBR_MAP_OFFSET add
-											GlyphData exch cid_SD_BYTES ct_GetInterval
-											0 cid_SD_BYTES ct_cvnsi
-											cid_SUBRS 4 2 roll
-											GlyphData exch
-											4 index
-											1 index
-											sub
-											ct_GetInterval
-											dup length string copy put
-											}
-										for
-										pop
-										}
-									if
-									}
-									{ pop }
-								ifelse
-								}
-							forall
-							}
-						if
-						cleartomark pop pop
-						end
-					CIDFontName currentdict /CIDFont defineresource pop
-					end end
-					}
-				stopped
-					{ cleartomark /StartData ct_reraise }
-				if
-				} bind def
-			currentdict
-			end def
-		/ct_saveCIDInit
-			{
-			/CIDInit /ProcSet ct_resourcestatus
-				{ true }
-				{ /CIDInitC /ProcSet ct_resourcestatus }
-			ifelse
-				{
-				pop pop
-				/CIDInit /ProcSet findresource
-				ct_UseNativeCapability?
-					{ pop null }
-					{ /CIDInit ct_CIDInit /ProcSet defineresource pop }
-				ifelse
-				}
-				{ /CIDInit ct_CIDInit /ProcSet defineresource pop null }
-			ifelse
-			ct_Vars exch /ct_oldCIDInit exch put
-			} bind def
-		/ct_restoreCIDInit
-			{
-			ct_Vars /ct_oldCIDInit get dup null ne
-				{ /CIDInit exch /ProcSet defineresource pop }
-				{ pop }
-			ifelse
-			} bind def
-		/ct_BuildCharSetUp
-			{
-			1 index
-				begin
-				CIDFont
-					begin
-					Adobe_CoolType_Utility /ct_BuildCharDict get
-						begin
-						/ct_dfCharCode exch def
-						/ct_dfDict exch def
-						CIDFirstByte ct_dfCharCode add
-						dup CIDCount ge
-							{ pop 0 }
-						if
-						/cid exch def
-							{
-							GlyphDirectory cid 2 copy known
-								{ get }
-								{ pop pop nullstring }
-							ifelse
-							dup length FDBytes sub 0 gt
-								{
-								dup
-								FDBytes 0 ne
-									{ 0 FDBytes ct_cvnsi }
-									{ pop 0 }
-								ifelse
-								/fdIndex exch def
-								dup length FDBytes sub FDBytes exch getinterval
-								/charstring exch def
-								exit
-								}
-								{
-								pop
-								cid 0 eq
-									{ /charstring nullstring def exit }
-								if
-								/cid 0 def
-								}
-							ifelse
-							}
-						loop
-			} def
-		/ct_SetCacheDevice
-			{
-			0 0 moveto
-			dup stringwidth
-			3 -1 roll
-			true charpath
-			pathbbox
-			0 -1000
-			7 index 2 div 880
-			setcachedevice2
-			0 0 moveto
-			} def
-		/ct_CloneSetCacheProc
-			{
-			1 eq
-				{
-				stringwidth
-				pop -2 div -880
-				0 -1000 setcharwidth
-				moveto
-				}
-				{
-				usewidths?
-					{
-					currentfont /Widths get cid
-					2 copy known
-						{ get exch pop aload pop }
-						{ pop pop stringwidth }
-					ifelse
-					}
-					{ stringwidth }
-				ifelse
-				setcharwidth
-				0 0 moveto
-				}
-			ifelse
-			} def
-		/ct_Type3ShowCharString
-			{
-			ct_FDDict fdIndex 2 copy known
-				{ get }
-				{
-				currentglobal 3 1 roll
-				1 index gcheck setglobal
-				ct_Type1FontTemplate dup maxlength dict copy
-					begin
-					FDArray fdIndex get
-					dup /FontMatrix 2 copy known
-						{ get }
-						{ pop pop ct_defaultFontMtx }
-					ifelse
-					/FontMatrix exch dup length array copy def
-					/Private get
-					/Private exch def
-					/Widths rootfont /Widths get def
-					/CharStrings 1 dict dup /.notdef
-						<d841272cf18f54fc13> dup length string copy put def
-					currentdict
-					end
-				/ct_Type1Font exch definefont
-				dup 5 1 roll put
-				setglobal
-				}
-			ifelse
-			dup /CharStrings get 1 index /Encoding get
-			ct_dfCharCode get charstring put
-			rootfont /WMode 2 copy known
-				{ get }
-				{ pop pop 0 }
-			ifelse
-			exch
-			1000 scalefont setfont
-			ct_str1 0 ct_dfCharCode put
-			ct_str1 exch ct_dfSetCacheProc
-			ct_SyntheticBold
-				{
-				currentpoint
-				ct_str1 show
-				newpath
-				moveto
-				ct_str1 true charpath
-				ct_StrokeWidth setlinewidth
-				stroke
-				}
-				{ ct_str1 show }
-			ifelse
-			} def
-		/ct_Type4ShowCharString
-			{
-			ct_dfDict ct_dfCharCode charstring
-			FDArray fdIndex get
-			dup /FontMatrix get dup ct_defaultFontMtx ct_matrixeq not
-				{ ct_1000Mtx matrix concatmatrix concat }
-				{ pop }
-			ifelse
-			/Private get
-			Adobe_CoolType_Utility /ct_Level2? get not
-				{
-				ct_dfDict /Private
-				3 -1 roll
-					{ put }
-				1183615869 internaldict /superexec get exec
-				}
-			if
-			1183615869 internaldict
-			Adobe_CoolType_Utility /ct_Level2? get
-				{ 1 index }
-				{ 3 index /Private get mark 6 1 roll }
-			ifelse
-			dup /RunInt known
-				{ /RunInt get }
-				{ pop /CCRun }
-			ifelse
-			get exec
-			Adobe_CoolType_Utility /ct_Level2? get not
-				{ cleartomark }
-			if
-			} bind def
-		/ct_BuildCharIncremental
-			{
-				{
-				Adobe_CoolType_Utility /ct_MakeOCF get begin
-				ct_BuildCharSetUp
-				ct_ShowCharString
-				}
-			stopped
-				{ stop }
-			if
-			end
-			end
-			end
-			end
-			} bind def
-		/BaseFontNameStr (BF00) def
-		/ct_Type1FontTemplate 14 dict
-			begin
-			/FontType 1 def
-			/FontMatrix  [0.001 0 0 0.001 0 0] def
-			/FontBBox  [-250 -250 1250 1250] def
-			/Encoding ct_cHexEncoding def
-			/PaintType 0 def
-			currentdict
-			end def
-		/BaseFontTemplate 11 dict
-			begin
-			/FontMatrix  [0.001 0 0 0.001 0 0] def
-			/FontBBox  [-250 -250 1250 1250] def
-			/Encoding ct_cHexEncoding def
-			/BuildChar /ct_BuildCharIncremental load def
-			ct_Clone?
-				{
-				/FontType 3 def
-				/ct_ShowCharString /ct_Type3ShowCharString load def
-				/ct_dfSetCacheProc /ct_CloneSetCacheProc load def
-				/ct_SyntheticBold false def
-				/ct_StrokeWidth 1 def
-				}
-				{
-				/FontType 4 def
-				/Private 1 dict dup /lenIV 4 put def
-				/CharStrings 1 dict dup /.notdef <d841272cf18f54fc13> put def
-				/PaintType 0 def
-				/ct_ShowCharString /ct_Type4ShowCharString load def
-				}
-			ifelse
-			/ct_str1 1 string def
-			currentdict
-			end def
-		/BaseFontDictSize BaseFontTemplate length 5 add def
-		/ct_matrixeq
-			{
-			true 0 1 5
-				{
-				dup 4 index exch get exch 3 index exch get eq and
-				dup not
-					{ exit }
-				if
-				}
-			for
-			exch pop exch pop
-			} bind def
-		/ct_makeocf
-			{
-			15 dict
-				begin
-				exch /WMode exch def
-				exch /FontName exch def
-				/FontType 0 def
-				/FMapType 2 def
-			dup /FontMatrix known
-				{ dup /FontMatrix get /FontMatrix exch def }
-				{ /FontMatrix matrix def }
-			ifelse
-				/bfCount 1 index /CIDCount get 256 idiv 1 add
-					dup 256 gt { pop 256} if def
-				/Encoding
-					256 array 0 1 bfCount 1 sub { 2 copy dup put pop } for
-					bfCount 1 255 { 2 copy bfCount put pop } for
-					def
-				/FDepVector bfCount dup 256 lt { 1 add } if array def
-				BaseFontTemplate BaseFontDictSize dict copy
-					begin
-					/CIDFont exch def
-					CIDFont /FontBBox known
-						{ CIDFont /FontBBox get /FontBBox exch def }
-					if
-					CIDFont /CDevProc known
-						{ CIDFont /CDevProc get /CDevProc exch def }
-					if
-					currentdict
-					end
-				BaseFontNameStr 3 (0) putinterval
-				0 1 bfCount dup 256 eq { 1 sub } if
-					{
-					FDepVector exch
-					2 index BaseFontDictSize dict copy
-						begin
-						dup /CIDFirstByte exch 256 mul def
-						FontType 3 eq
-							{ /ct_FDDict 2 dict def }
-						if
-						currentdict
-						end
-					1 index  16
-					BaseFontNameStr  2 2 getinterval cvrs pop
-					BaseFontNameStr exch definefont
-					put
-					}
-				for
-				ct_Clone?
-					{ /Widths 1 index /CIDFont get /GlyphDirectory get length dict def }
-				if
-				FontName
-				currentdict
-				end
-			definefont
-			ct_Clone?
-				{
-				gsave
-				dup 1000 scalefont setfont
-				ct_BuildCharDict
-					begin
-					/usewidths? false def
-					currentfont /Widths get
-						begin
-						exch /CIDFont get /GlyphDirectory get
-							{
-							pop
-							dup charcode exch 1 index 0 2 index 256 idiv put
-							1 index exch 1 exch 256 mod put
-							stringwidth 2 array astore def
-							}
-						forall
-						end
-					/usewidths? true def
-					end
-				grestore
-				}
-				{ exch pop }
-			ifelse
-			} bind def
-		/ct_ComposeFont
-			{
-			ct_UseNativeCapability?
-				{
-				2 index /CMap ct_resourcestatus
-					{ pop pop exch pop }
-					{
-					/CIDInit /ProcSet findresource
-						begin
-						12 dict
-							begin
-							begincmap
-							/CMapName 3 index def
-							/CMapVersion 1.000 def
-							/CMapType 1 def
-							exch /WMode exch def
-							/CIDSystemInfo 3 dict dup
-								begin
-								/Registry (Adobe) def
-								/Ordering
-								CMapName ct_mkocfStr100 cvs
-								(Adobe-) search
-									{
-									pop pop
-									(-) search
-										{
-										dup length string copy
-										exch pop exch pop
-										}
-										{ pop (Identity)}
-									ifelse
-									}
-									{ pop  (Identity)  }
-								ifelse
-								def
-								/Supplement 0 def
-								end def
-							1 begincodespacerange
-							<0000> <FFFF>
-							endcodespacerange
-							1 begincidrange
-							<0000> <FFFF> 0
-							endcidrange
-							endcmap
-							CMapName currentdict /CMap defineresource pop
-							end
-						end
-					}
-				ifelse
-				composefont
-				}
-				{
-				3 2 roll pop
-				0 get /CIDFont findresource
-				ct_makeocf
-				}
-			ifelse
-			} bind def
-		/ct_MakeIdentity
-			{
-			ct_UseNativeCapability?
-				{
-				1 index /CMap ct_resourcestatus
-					{ pop pop }
-					{
-					/CIDInit /ProcSet findresource begin
-					12 dict begin
-					begincmap
-					/CMapName 2 index def
-					/CMapVersion 1.000 def
-					/CMapType 1 def
-					/CIDSystemInfo 3 dict dup
-						begin
-						/Registry (Adobe) def
-						/Ordering
-						CMapName ct_mkocfStr100 cvs
-						(Adobe-) search
-							{
-							pop pop
-							(-) search
-								{ dup length string copy exch pop exch pop }
-								{ pop (Identity) }
-							ifelse
-							}
-							{ pop (Identity) }
-						ifelse
-						def
-						/Supplement 0 def
-						end def
-					1 begincodespacerange
-					<0000> <FFFF>
-					endcodespacerange
-					1 begincidrange
-					<0000> <FFFF> 0
-					endcidrange
-					endcmap
-					CMapName currentdict /CMap defineresource pop
-					end
-					end
-					}
-				ifelse
-				composefont
-				}
-				{
-				exch pop
-				0 get /CIDFont findresource
-				ct_makeocf
-				}
-			ifelse
-			} bind def
-		currentdict readonly pop
-		end
-	end
-%%EndResource
-%%BeginResource: procset Adobe_CoolType_Utility_T42 1.0 0
-%%Copyright: Copyright 1987-2003 Adobe Systems Incorporated.
-%%Version: 1.0 0
-userdict /ct_T42Dict 15 dict put
-ct_T42Dict begin
-/Is2015?
-{
-  version
-  cvi
-  2015
-  ge
-} bind def
-/AllocGlyphStorage
-{
-  Is2015?
-  {	
-		pop
-  }
-  {
-		{string} forall
-  } ifelse
-} bind def
-/Type42DictBegin
-{
-	25 dict begin
-  /FontName exch def
-  /CharStrings 256 dict
-	begin
-		  /.notdef 0 def
-		  currentdict
-	end def
-  /Encoding exch def
-  /PaintType 0 def
-  /FontType 42 def
-  /FontMatrix [1 0 0 1 0 0] def
-  4 array  astore cvx /FontBBox exch def
-  /sfnts
-} bind def
-/Type42DictEnd
-{
-	 currentdict dup /FontName get exch definefont end
-	ct_T42Dict exch
-	dup /FontName get exch put
-} bind def
-/RD {string currentfile exch readstring pop} executeonly def
-/PrepFor2015
-{
-	Is2015?
-	{		
-		 /GlyphDirectory
-		 16
-		 dict def
-		 sfnts 0 get
-		 dup
-		 2 index
-		 (glyx)
-		 putinterval
-		 2 index
-		 (locx)
-		 putinterval
-		 pop
-		 pop
-	}
-	{
-		 pop
-		 pop
-	} ifelse			
-} bind def
-/AddT42Char
-{
-	Is2015?
-	{
-		/GlyphDirectory get
-		begin
-		def
-		end
-		pop
-		pop
-	}
-	{
-		/sfnts get
-		4 index
-		get
-		3 index
-	  2 index
-		putinterval
-		pop
-		pop
-		pop
-		pop
-	} ifelse
-} bind def
-end
-%%EndResource
-Adobe_CoolType_Core begin /$Oblique SetSubstituteStrategy end
-%%BeginResource: procset Adobe_AGM_Image 1.0 0
-%%Version: 1.0 0
-%%Copyright: Copyright (C) 2000-2003 Adobe Systems, Inc.  All Rights Reserved.
-systemdict /setpacking known
-{
-	currentpacking
-	true setpacking
-} if
-userdict /Adobe_AGM_Image 75 dict dup begin put
-/Adobe_AGM_Image_Id /Adobe_AGM_Image_1.0_0 def
-/nd{
-	null def
-}bind def
-/AGMIMG_&image nd
-/AGMIMG_&colorimage nd
-/AGMIMG_&imagemask nd
-/AGMIMG_mbuf () def
-/AGMIMG_ybuf () def
-/AGMIMG_kbuf () def
-/AGMIMG_c 0 def
-/AGMIMG_m 0 def
-/AGMIMG_y 0 def
-/AGMIMG_k 0 def
-/AGMIMG_tmp nd
-/AGMIMG_imagestring0 nd
-/AGMIMG_imagestring1 nd
-/AGMIMG_imagestring2 nd
-/AGMIMG_imagestring3 nd
-/AGMIMG_imagestring4 nd
-/AGMIMG_imagestring5 nd
-/AGMIMG_cnt nd
-/AGMIMG_fsave nd
-/AGMIMG_colorAry nd
-/AGMIMG_override nd
-/AGMIMG_name nd
-/AGMIMG_maskSource nd
-/invert_image_samples nd
-/knockout_image_samples	nd
-/img nd
-/sepimg nd
-/devnimg nd
-/idximg nd
-/doc_setup
-{
-	Adobe_AGM_Core begin
-	Adobe_AGM_Image begin
-	/AGMIMG_&image systemdict/image get def
-	/AGMIMG_&imagemask systemdict/imagemask get def
-	/colorimage where{
-		pop
-		/AGMIMG_&colorimage /colorimage ldf
-	}if
-	end
-	end
-}def
-/page_setup
-{
-	Adobe_AGM_Image begin
-	/AGMIMG_ccimage_exists {/customcolorimage where
-		{
-			pop
-			/Adobe_AGM_OnHost_Seps where
-			{
-			pop false
-			}{
-			/Adobe_AGM_InRip_Seps where
-				{
-				pop false
-				}{
-					true
-				 }ifelse
-			 }ifelse
-			}{
-			false
-		}ifelse
-	}bdf
-	level2{
-		/invert_image_samples
-		{
-			Adobe_AGM_Image/AGMIMG_tmp Decode length ddf
-			/Decode [ Decode 1 get Decode 0 get] def
-		}def
-		/knockout_image_samples
-		{
-			Operator/imagemask ne{
-				/Decode [1 1] def
-			}if
-		}def
-	}{	
-		/invert_image_samples
-		{
-			{1 exch sub} currenttransfer addprocs settransfer
-		}def
-		/knockout_image_samples
-		{
-			{ pop 1 } currenttransfer addprocs settransfer
-		}def
-	}ifelse
-	/img /imageormask ldf
-	/sepimg /sep_imageormask ldf
-	/devnimg /devn_imageormask ldf
-	/idximg /indexed_imageormask ldf
-	/_ctype 7 def
-	currentdict{
-		dup xcheck 1 index type dup /arraytype eq exch /packedarraytype eq or and{
-			bind
-		}if
-		def
-	}forall
-}def
-/page_trailer
-{
-	end
-}def
-/doc_trailer
-{
-}def
-/imageormask_sys
-{
-	begin
-		save mark
-		level2{
-			currentdict
-			Operator /imagemask eq{
-				AGMIMG_&imagemask
-			}{
-				use_mask {
-					level3 {process_mask_L3 AGMIMG_&image}{masked_image_simulation}ifelse
-				}{
-					AGMIMG_&image
-				}ifelse
-			}ifelse
-		}{
-			Width Height
-			Operator /imagemask eq{
-				Decode 0 get 1 eq Decode 1 get 0 eq	and
-				ImageMatrix /DataSource load
-				AGMIMG_&imagemask
-			}{
-				BitsPerComponent ImageMatrix /DataSource load
-				AGMIMG_&image
-			}ifelse
-		}ifelse
-		cleartomark restore
-	end
-}def
-/overprint_plate
-{
-	currentoverprint {
-		0 get dup type /nametype eq {
-			dup /DeviceGray eq{
-				pop AGMCORE_black_plate not
-			}{
-				/DeviceCMYK eq{
-					AGMCORE_is_cmyk_sep not
-				}if
-			}ifelse
-		}{
-			false exch
-			{
-				 AGMOHS_sepink eq or
-			} forall
-			not
-		} ifelse
-	}{
-		pop false
-	}ifelse
-}def
-/process_mask_L3
-{
-	dup begin
-	/ImageType 1 def
-	end
-	4 dict begin
-		/DataDict exch def
-		/ImageType 3 def
-		/InterleaveType 3 def
-		/MaskDict 9 dict begin
-			/ImageType 1 def
-			/Width DataDict dup /MaskWidth known {/MaskWidth}{/Width} ifelse get def
-			/Height DataDict dup /MaskHeight known {/MaskHeight}{/Height} ifelse get def
-			/ImageMatrix [Width 0 0 Height neg 0 Height] def
-			/NComponents 1 def
-			/BitsPerComponent 1 def
-			/Decode [0 1] def
-			/DataSource AGMIMG_maskSource def
-		currentdict end def
-	currentdict end
-}def
-/use_mask
-{
-	dup type /dicttype eq
-	{
-		dup /Mask known	{
-			dup /Mask get {
-				level3
-				{true}
-				{
-					dup /MaskWidth known {dup /MaskWidth get 1 index /Width get eq}{true}ifelse exch
-					dup /MaskHeight known {dup /MaskHeight get 1 index /Height get eq}{true}ifelse
-					3 -1 roll and
-				} ifelse
-			}
-			{false} ifelse
-		}
-		{false} ifelse
-	}
-	{false} ifelse
-}def
-/make_line_source
-{
-	begin
-	MultipleDataSources {
-		[
-		Decode length 2 div cvi {Width string} repeat
-		]
-	}{
-		Width Decode length 2 div mul cvi string
-	}ifelse
-	end
-}def
-/datasource_to_str
-{
-	exch dup type
-	dup /filetype eq {
-		pop exch readstring
-	}{
-		/arraytype eq {
-			exec exch copy
-		}{
-			pop
-		}ifelse
-	}ifelse
-	pop
-}def
-/masked_image_simulation
-{
-	3 dict begin
-	dup make_line_source /line_source xdf
-	/mask_source AGMIMG_maskSource /LZWDecode filter def
-	dup /Width get 8 div ceiling cvi string /mask_str xdf
-	begin
-	gsave
-	0 1 translate 1 -1 Height div scale
-	1 1 Height {
-		pop
-		gsave
-		MultipleDataSources {
-			0 1 DataSource length 1 sub {
-				dup DataSource exch get
-				exch line_source exch get
-				datasource_to_str
-			} for
-		}{
-			DataSource line_source datasource_to_str
-		} ifelse
-		<<
-			/PatternType 1
-			/PaintProc [
-				/pop cvx
-				<<
-					/ImageType 1
-					/Width Width
-					/Height 1
-					/ImageMatrix Width 1.0 sub 1 matrix scale 0.5 0 matrix translate matrix concatmatrix
-					/MultipleDataSources MultipleDataSources
-					/DataSource line_source
-					/BitsPerComponent BitsPerComponent
-					/Decode Decode
-				>>
-				/image cvx
-			] cvx
-			/BBox [0 0 Width 1]
-			/XStep Width
-			/YStep 1
-			/PaintType 1
-			/TilingType 2
-		>>
-		matrix makepattern set_pattern
-		<<
-			/ImageType 1
-			/Width Width
-			/Height 1
-			/ImageMatrix Width 1 matrix scale
-			/MultipleDataSources false
-			/DataSource mask_source mask_str readstring pop
-			/BitsPerComponent 1
-			/Decode [0 1]
-		>>
-		imagemask
-		grestore
-		0 1 translate
-	} for
-	grestore
-	end
-	end
-}def
-/imageormask
-{
-	begin
-		SkipImageProc {
-			currentdict consumeimagedata
-		}
-		{
-			save mark
-			level2 AGMCORE_host_sep not and{
-				currentdict
-				Operator /imagemask eq DeviceN_PS2 not and {
-					imagemask
-				}{
-					AGMCORE_in_rip_sep currentoverprint and currentcolorspace 0 get /DeviceGray eq and{
-						[/Separation /Black /DeviceGray {}] setcolorspace
-						/Decode [ Decode 1 get Decode 0 get ] def
-					}if
-					use_mask {
-						level3 {process_mask_L3 image}{masked_image_simulation}ifelse
-					}{
-						DeviceN_NoneName DeviceN_PS2 Indexed_DeviceN level3 not and or or AGMCORE_in_rip_sep and
-						{
-							Names convert_to_process not {
-								2 dict begin
-								/imageDict xdf
-								/names_index 0 def
-								gsave
-								imageDict write_image_file {
-									Names {
-										dup (None) ne {
-											[/Separation 3 -1 roll /DeviceGray {1 exch sub}] setcolorspace
-											Operator imageDict read_image_file
-											names_index 0 eq {true setoverprint} if
-											/names_index names_index 1 add def
-										}{
-											pop
-										} ifelse
-									} forall
-									close_image_file
-								} if
-								grestore
-								end
-							}{
-								Operator /imagemask eq {
-									imagemask
-								}{
-									image
-								} ifelse
-							} ifelse
-						}{
-							Operator /imagemask eq {
-								imagemask
-							}{
-								image
-							} ifelse
-						} ifelse
-					}ifelse
-				}ifelse
-			}{
-				Width Height
-				Operator /imagemask eq{
-					Decode 0 get 1 eq Decode 1 get 0 eq	and
-					ImageMatrix /DataSource load
-					/Adobe_AGM_OnHost_Seps where {
-						pop imagemask
-					}{
-						currentgray 1 ne{
-							currentdict imageormask_sys
-						}{
-							currentoverprint not{
-								1 AGMCORE_&setgray
-								currentdict imageormask_sys
-							}{
-								currentdict ignoreimagedata
-							}ifelse				 		
-						}ifelse
-					}ifelse
-				}{
-					BitsPerComponent ImageMatrix
-					MultipleDataSources{
-						0 1 NComponents 1 sub{
-							DataSource exch get
-						}for
-					}{
-						/DataSource load
-					}ifelse
-					Operator /colorimage eq{
-						AGMCORE_host_sep{
-							MultipleDataSources level2 or NComponents 4 eq and{
-								AGMCORE_is_cmyk_sep{
-									MultipleDataSources{
-										/DataSource [
-											DataSource 0 get /exec cvx
-											DataSource 1 get /exec cvx
-											DataSource 2 get /exec cvx
-											DataSource 3 get /exec cvx
-											/AGMCORE_get_ink_data cvx
-										] cvx def
-									}{
-										/DataSource
-										Width BitsPerComponent mul 7 add 8 idiv Height mul 4 mul
-										/DataSource load
-										filter_cmyk 0 () /SubFileDecode filter def
-									}ifelse
-									/Decode [ Decode 0 get Decode 1 get ] def
-									/MultipleDataSources false def
-									/NComponents 1 def
-									/Operator /image def
-									invert_image_samples
-						 			1 AGMCORE_&setgray
-									currentdict imageormask_sys
-								}{
-									currentoverprint not Operator/imagemask eq and{
-  			 							1 AGMCORE_&setgray
-  			 							currentdict imageormask_sys
-  			 						}{
-  			 							currentdict ignoreimagedata
-  			 						}ifelse
-								}ifelse
-							}{	
-								MultipleDataSources NComponents AGMIMG_&colorimage						
-							}ifelse
-						}{
-							true NComponents colorimage
-						}ifelse
-					}{
-						Operator /image eq{
-							AGMCORE_host_sep{
-								/DoImage true def
-								HostSepColorImage{
-									invert_image_samples
-								}{
-									AGMCORE_black_plate not Operator/imagemask ne and{
-										/DoImage false def
-										currentdict ignoreimagedata
-					 				}if
-								}ifelse
-						 		1 AGMCORE_&setgray
-								DoImage
-									{currentdict imageormask_sys} if
-							}{
-								use_mask {
-									level3 {process_mask_L3 image}{masked_image_simulation}ifelse
-								}{
-									image
-								}ifelse
-							}ifelse
-						}{
-							Operator/knockout eq{
-								pop pop pop pop pop
-								currentcolorspace overprint_plate not{
-									knockout_unitsq
-								}if
-							}if
-						}ifelse
-					}ifelse
-				}ifelse
-			}ifelse
-			cleartomark restore
-		}ifelse
-	end
-}def
-/sep_imageormask
-{
- 	/sep_colorspace_dict AGMCORE_gget begin
-	/MappedCSA CSA map_csa def
-	begin
-	SkipImageProc {
-		currentdict consumeimagedata
-	}
-	{
-		save mark
-		AGMCORE_avoid_L2_sep_space{
-			/Decode [ Decode 0 get 255 mul Decode 1 get 255 mul ] def
-		}if
- 		AGMIMG_ccimage_exists
-		MappedCSA 0 get /DeviceCMYK eq and
-		currentdict/Components known and
-		Name () ne and
-		Name (All) ne and
-		Operator /image eq and
-		AGMCORE_producing_seps not and
-		level2 not and
-		{
-			Width Height BitsPerComponent ImageMatrix
-			[
-			/DataSource load /exec cvx
-			{
-				0 1 2 index length 1 sub{
-					1 index exch
-					2 copy get 255 xor put
-				}for
-			} /exec cvx
-			] cvx bind
-			MappedCSA 0 get /DeviceCMYK eq{
-				Components aload pop
-			}{
-				0 0 0 Components aload pop 1 exch sub
-			}ifelse
-			Name findcmykcustomcolor
-			customcolorimage
-		}{
-			AGMCORE_producing_seps not{
-				level2{
-					AGMCORE_avoid_L2_sep_space not currentcolorspace 0 get /Separation ne and{
-						[/Separation Name MappedCSA sep_proc_name exch 0 get exch load ] setcolorspace_opt
-						/sep_tint AGMCORE_gget setcolor
-					}if
-					currentdict imageormask
-				}{
-					currentdict
-					Operator /imagemask eq{
-						imageormask
-					}{
-						sep_imageormask_lev1
-					}ifelse
-				}ifelse
- 			}{
-				AGMCORE_host_sep{
-					Operator/knockout eq{
-						currentdict/ImageMatrix get concat
-						knockout_unitsq
-					}{
-						currentgray 1 ne{
- 							AGMCORE_is_cmyk_sep Name (All) ne and{
- 								level2{
-	 								[ /Separation Name [/DeviceGray]
-	 								{
-	 									sep_colorspace_proc AGMCORE_get_ink_data
-										1 exch sub
-	 								} bind
-									] AGMCORE_&setcolorspace
-									/sep_tint AGMCORE_gget AGMCORE_&setcolor
- 									currentdict imageormask_sys
-	 							}{
-	 								currentdict
-									Operator /imagemask eq{
-										imageormask_sys
-									}{
-										sep_image_lev1_sep
-									}ifelse
-	 							}ifelse
- 							}{
- 								Operator/imagemask ne{
-									invert_image_samples
- 								}if
-		 						currentdict imageormask_sys
- 							}ifelse
- 						}{
- 							currentoverprint not Name (All) eq or Operator/imagemask eq and{
-								currentdict imageormask_sys
-								}{
-								currentoverprint not
-									{
- 									gsave
- 									knockout_unitsq
- 									grestore
-									}if
-								currentdict consumeimagedata
-		 					}ifelse
- 						}ifelse
-		 			}ifelse
- 				}{
-					currentcolorspace 0 get /Separation ne{
-						[/Separation Name MappedCSA sep_proc_name exch 0 get exch load ] setcolorspace_opt
-						/sep_tint AGMCORE_gget setcolor
-					}if
-					currentoverprint
-					MappedCSA 0 get /DeviceCMYK eq and
-					Name inRip_spot_has_ink not and
-					Name (All) ne and {
-						imageormask_l2_overprint
-					}{
-						currentdict imageormask
- 					}ifelse
-				}ifelse
-			}ifelse
-		}ifelse
-		cleartomark restore
-	}ifelse
-	end
-	end
-}def
-/decode_image_sample
-{
-	4 1 roll exch dup 5 1 roll
-	sub 2 4 -1 roll exp 1 sub div mul add
-} bdf
-/colorSpaceElemCnt
-{
-	currentcolorspace 0 get dup /DeviceCMYK eq {
-		pop 4
-	}
-	{
-		/DeviceRGB eq {
-			pop 3
-		}{
-			1
-		} ifelse
-	} ifelse
-} bdf
-/devn_sep_datasource
-{
-	1 dict begin
-	/dataSource xdf
-	[
-		0 1 dataSource length 1 sub {
-			dup currentdict /dataSource get /exch cvx /get cvx /exec cvx
-			/exch cvx names_index /ne cvx [ /pop cvx ] cvx /if cvx
-		} for
-	] cvx bind
-	end
-} bdf		
-/devn_alt_datasource
-{
-	11 dict begin
-	/srcDataStrs xdf
-	/dstDataStr xdf
-	/convProc xdf
-	/origcolorSpaceElemCnt xdf
-	/origMultipleDataSources xdf
-	/origBitsPerComponent xdf
-	/origDecode xdf
-	/origDataSource xdf
-	/dsCnt origMultipleDataSources {origDataSource length}{1}ifelse def
-	/samplesNeedDecoding
-		0 0 1 origDecode length 1 sub {
-			origDecode exch get add
-		} for
-		origDecode length 2 div div
-		dup 1 eq {
-			/decodeDivisor 2 origBitsPerComponent exp 1 sub def
-		} if
-		2 origBitsPerComponent exp 1 sub ne
-	def
-	[
-		0 1 dsCnt 1 sub [
-			currentdict /origMultipleDataSources get {
-				dup currentdict /origDataSource get exch get dup type
-			}{
-				currentdict /origDataSource get dup type
-			} ifelse
-			dup /filetype eq {
-				pop currentdict /srcDataStrs get 3 -1 /roll cvx /get cvx /readstring cvx /pop cvx
-			}{
-				/stringtype ne {
-					/exec cvx
-				} if
-				currentdict /srcDataStrs get /exch cvx 3 -1 /roll cvx /xpt cvx
-			} ifelse
-		] cvx /for cvx
-		currentdict /srcDataStrs get 0 /get cvx /length cvx 0 /ne cvx [
-			0 1 Width 1 sub [
-				Adobe_AGM_Utils /AGMUTIL_ndx /xddf cvx
-				currentdict /origMultipleDataSources get {
-					0 1 dsCnt 1 sub [
-						Adobe_AGM_Utils /AGMUTIL_ndx1 /xddf cvx
-						currentdict /srcDataStrs get /AGMUTIL_ndx1 /load cvx /get cvx /AGMUTIL_ndx /load cvx /get cvx
-						samplesNeedDecoding {
-							currentdict /decodeDivisor known {
-								currentdict /decodeDivisor get /div cvx
-							}{
-								currentdict /origDecode get /AGMUTIL_ndx1 /load cvx 2 /mul cvx 2 /getinterval cvx /aload cvx /pop cvxs
-								BitsPerComponent /decode_image_sample load /exec cvx
-							} ifelse
-						} if
-					] cvx /for cvx
-				}{
-					Adobe_AGM_Utils /AGMUTIL_ndx1 0 /ddf cvx
-					currentdict /srcDataStrs get 0 /get cvx /AGMUTIL_ndx /load cvx		
-					currentdict /origDecode get length 2 idiv dup 3 1 /roll cvx /mul cvx /exch cvx /getinterval cvx
-					[
-						samplesNeedDecoding {
-							currentdict /decodeDivisor known {
-								currentdict /decodeDivisor get /div cvx
-							}{
-								currentdict /origDecode get /AGMUTIL_ndx1 /load cvx 2 /mul cvx 2 /getinterval cvx /aload cvx /pop cvx
-								BitsPerComponent /decode_image_sample load /exec cvx
-								Adobe_AGM_Utils /AGMUTIL_ndx1 /AGMUTIL_ndx1 /load cvx 1 /add cvx /ddf cvx
-							} ifelse
-						} if
-					] cvx /forall cvx
-				} ifelse
-				currentdict /convProc get /exec cvx
-				currentdict /origcolorSpaceElemCnt get 1 sub -1 0 [
-					currentdict /dstDataStr get 3 1 /roll cvx /AGMUTIL_ndx /load cvx currentdict /origcolorSpaceElemCnt get /mul cvx /add cvx /exch cvx
-					currentdict /convProc get /filter_indexed_devn load ne {
-						255 /mul cvx /cvi cvx
-					} if
-					/put cvx
-				] cvx /for cvx
-			] cvx /for cvx
-			currentdict /dstDataStr get
-		] cvx /if cvx
-	] cvx bind
-	end
-} bdf
-/devn_imageormask
-{
- 	/devicen_colorspace_dict AGMCORE_gget begin
-	/MappedCSA CSA map_csa def
-	2 dict begin
-	dup dup
-	/dstDataStr exch /Width get colorSpaceElemCnt mul string def
-	/srcDataStrs [ 3 -1 roll begin
-		currentdict /MultipleDataSources known {MultipleDataSources {DataSource length}{1}ifelse}{1} ifelse
-		{
-			Width Decode length 2 div mul cvi string
-		} repeat
-		end ] def
-	begin
-	SkipImageProc {
-		currentdict consumeimagedata
-	}
-	{
-		save mark
-		AGMCORE_producing_seps not {
-			level3 not {
-				Operator /imagemask ne {
-					/DataSource [
-						DataSource Decode BitsPerComponent currentdict /MultipleDataSources known {MultipleDataSources}{false} ifelse
-						colorSpaceElemCnt /devicen_colorspace_dict AGMCORE_gget /TintTransform get
-						dstDataStr srcDataStrs devn_alt_datasource /exec cvx
-						] cvx 0 () /SubFileDecode filter def
-					/MultipleDataSources false def
-					/Decode colorSpaceElemCnt [ exch {0 1} repeat ] def
-				} if
-			}if
-			currentdict imageormask
- 		}{
-			AGMCORE_host_sep{
-				Names convert_to_process {
-					CSA map_csa 0 get /DeviceCMYK eq {
-						/DataSource
-							Width BitsPerComponent mul 7 add 8 idiv Height mul 4 mul
-							[
-							DataSource Decode BitsPerComponent currentdict /MultipleDataSources known {MultipleDataSources}{false} ifelse
-							4 /devicen_colorspace_dict AGMCORE_gget /TintTransform get
-							dstDataStr srcDataStrs devn_alt_datasource /exec cvx
-							] cvx
-						filter_cmyk 0 () /SubFileDecode filter def
-						/MultipleDataSources false def
-						/Decode [1 0] def
-						/DeviceGray setcolorspace
-			 			currentdict imageormask_sys
- 					}{
-						AGMCORE_report_unsupported_color_space
-						AGMCORE_black_plate {
-							/DataSource [
-								DataSource Decode BitsPerComponent currentdict /MultipleDataSources known {MultipleDataSources}{false} ifelse
-								CSA map_csa 0 get /DeviceRGB eq{3}{1}ifelse /devicen_colorspace_dict AGMCORE_gget /TintTransform get
-								dstDataStr srcDataStrs devn_alt_datasource /exec cvx
-								] cvx 0 () /SubFileDecode filter def
-							/MultipleDataSources false def
-							/Decode colorSpaceElemCnt [ exch {0 1} repeat ] def
-				 			currentdict imageormask_sys
-				 		}
-						{
-	 						gsave
-	 						knockout_unitsq
-	 						grestore
-							currentdict consumeimagedata
-						} ifelse
- 					} ifelse
-				}
-				{	
-					/devicen_colorspace_dict AGMCORE_gget /names_index known {
-	 					Operator/imagemask ne{
-	 						MultipleDataSources {
-		 						/DataSource [ DataSource devn_sep_datasource /exec cvx ] cvx def
-								/MultipleDataSources false def
-	 						}{
-								/DataSource /DataSource load dstDataStr srcDataStrs 0 get filter_devn def
-	 						} ifelse
-							invert_image_samples
-	 					} if
-			 			currentdict imageormask_sys
-	 				}{
-	 					currentoverprint not Operator/imagemask eq and{
-							currentdict imageormask_sys
-							}{
-							currentoverprint not
-								{
-	 							gsave
-	 							knockout_unitsq
-	 							grestore
-								}if
-							currentdict consumeimagedata
-			 			}ifelse
-	 				}ifelse
-	 			}ifelse
- 			}{
-				currentdict imageormask
-			}ifelse
-		}ifelse
-		cleartomark restore
-	}ifelse
-	end
-	end
-	end
-}def
-/imageormask_l2_overprint
-{
-	currentdict
-	currentcmykcolor add add add 0 eq{
-		currentdict consumeimagedata
-	}{
-		level3{ 			
-			currentcmykcolor
-			/AGMIMG_k xdf
-			/AGMIMG_y xdf
-			/AGMIMG_m xdf
-			/AGMIMG_c xdf
-			Operator/imagemask eq{
-				[/DeviceN [
-				AGMIMG_c 0 ne {/Cyan} if
-				AGMIMG_m 0 ne {/Magenta} if
-				AGMIMG_y 0 ne {/Yellow} if
-				AGMIMG_k 0 ne {/Black} if
-				] /DeviceCMYK {}] setcolorspace
-				AGMIMG_c 0 ne {AGMIMG_c} if
-				AGMIMG_m 0 ne {AGMIMG_m} if
-				AGMIMG_y 0 ne {AGMIMG_y} if
-				AGMIMG_k 0 ne {AGMIMG_k} if
-				setcolor			
-			}{	
-				/Decode [ Decode 0 get 255 mul Decode 1 get 255 mul ] def
-				[/Indexed 				
-					[
-						/DeviceN [
-							AGMIMG_c 0 ne {/Cyan} if
-							AGMIMG_m 0 ne {/Magenta} if
-							AGMIMG_y 0 ne {/Yellow} if
-							AGMIMG_k 0 ne {/Black} if
-						]
-						/DeviceCMYK {
-							AGMIMG_k 0 eq {0} if
-							AGMIMG_y 0 eq {0 exch} if
-							AGMIMG_m 0 eq {0 3 1 roll} if
-							AGMIMG_c 0 eq {0 4 1 roll} if						
-						}
-					]
-					255
-					{
-						255 div
-						mark exch
-						dup	dup dup
-						AGMIMG_k 0 ne{
-							/sep_tint AGMCORE_gget mul MappedCSA sep_proc_name exch pop load exec 4 1 roll pop pop pop		
-							counttomark 1 roll
-						}{
-							pop
-						}ifelse
-						AGMIMG_y 0 ne{
-							/sep_tint AGMCORE_gget mul MappedCSA sep_proc_name exch pop load exec 4 2 roll pop pop pop		
-							counttomark 1 roll
-						}{
-							pop
-						}ifelse
-						AGMIMG_m 0 ne{
-							/sep_tint AGMCORE_gget mul MappedCSA sep_proc_name exch pop load exec 4 3 roll pop pop pop		
-							counttomark 1 roll
-						}{
-							pop
-						}ifelse
-						AGMIMG_c 0 ne{
-							/sep_tint AGMCORE_gget mul MappedCSA sep_proc_name exch pop load exec pop pop pop		
-							counttomark 1 roll
-						}{
-							pop
-						}ifelse
-						counttomark 1 add -1 roll pop
-					}
-				] setcolorspace
-			}ifelse
-			imageormask_sys
-		}{
-	write_image_file{
-		currentcmykcolor
-		0 ne{
-			[/Separation /Black /DeviceGray {}] setcolorspace
-			gsave
-			/Black
-			[{1 exch sub /sep_tint AGMCORE_gget mul} /exec cvx MappedCSA sep_proc_name cvx exch pop {4 1 roll pop pop pop 1 exch sub} /exec cvx]
-			cvx modify_halftone_xfer
-			Operator currentdict read_image_file
-			grestore
-		}if
-		0 ne{
-			[/Separation /Yellow /DeviceGray {}] setcolorspace
-			gsave
-			/Yellow
-			[{1 exch sub /sep_tint AGMCORE_gget mul} /exec cvx MappedCSA sep_proc_name cvx exch pop {4 2 roll pop pop pop 1 exch sub} /exec cvx]
-			cvx modify_halftone_xfer
-			Operator currentdict read_image_file
-			grestore
-		}if
-		0 ne{
-			[/Separation /Magenta /DeviceGray {}] setcolorspace
-			gsave
-			/Magenta
-			[{1 exch sub /sep_tint AGMCORE_gget mul} /exec cvx MappedCSA sep_proc_name cvx exch pop {4 3 roll pop pop pop 1 exch sub} /exec cvx]
-			cvx modify_halftone_xfer
-			Operator currentdict read_image_file
-			grestore
-		}if
-		0 ne{
-			[/Separation /Cyan /DeviceGray {}] setcolorspace
-			gsave
-			/Cyan
-			[{1 exch sub /sep_tint AGMCORE_gget mul} /exec cvx MappedCSA sep_proc_name cvx exch pop {pop pop pop 1 exch sub} /exec cvx]
-			cvx modify_halftone_xfer
-			Operator currentdict read_image_file
-			grestore
-		} if
-				close_image_file
-			}{
-				imageormask
-			}ifelse
-		}ifelse
-	}ifelse
-} def
-/indexed_imageormask
-{
-	begin
-		save mark
- 		currentdict
- 		AGMCORE_host_sep{
-			Operator/knockout eq{
-				/indexed_colorspace_dict AGMCORE_gget dup /CSA known {
-					/CSA get map_csa
-				}{
-					/CSD get get_csd /Names get
-				} ifelse
-				overprint_plate not{
-					knockout_unitsq
-				}if
-			}{
-				Indexed_DeviceN {
-					/devicen_colorspace_dict AGMCORE_gget /names_index known {
-			 			indexed_image_lev2_sep
-					}{
-						currentoverprint not{
-							knockout_unitsq
-			 			}if
-			 			currentdict consumeimagedata
-					} ifelse
-				}{
-		 			AGMCORE_is_cmyk_sep{
-						Operator /imagemask eq{
-							imageormask_sys
-						}{
-							level2{
-								indexed_image_lev2_sep
-							}{
-								indexed_image_lev1_sep
-							}ifelse
-						}ifelse
-					}{
-						currentoverprint not{
-							knockout_unitsq
-			 			}if
-			 			currentdict consumeimagedata
-					}ifelse
-				}ifelse
-			}ifelse
- 		}{
-			level2{
-				Indexed_DeviceN {
-					/indexed_colorspace_dict AGMCORE_gget begin
-					CSD get_csd begin
-				}{
-					/indexed_colorspace_dict AGMCORE_gget begin
-					CSA map_csa 0 get /DeviceCMYK eq ps_level 3 ge and ps_version 3015.007 lt and {
-						[/Indexed [/DeviceN [/Cyan /Magenta /Yellow /Black] /DeviceCMYK {}] HiVal Lookup]
-						setcolorspace
-					} if
-					end
-				} ifelse
-				imageormask
-				Indexed_DeviceN {
-					end
-					end
-				} if
-			}{
-				Operator /imagemask eq{
-					imageormask
-				}{
-					indexed_imageormask_lev1
-				}ifelse
-			}ifelse
- 		}ifelse
-		cleartomark restore
-	end
-}def
-/indexed_image_lev2_sep
-{
-	/indexed_colorspace_dict AGMCORE_gget begin
-	begin
-		Indexed_DeviceN not {
-			currentcolorspace
-			dup 1 /DeviceGray put
-			dup 3
-			currentcolorspace 2 get 1 add string
-			0 1 2 3 AGMCORE_get_ink_data 4 currentcolorspace 3 get length 1 sub
-			{
-			dup 4 idiv exch currentcolorspace 3 get exch get 255 exch sub 2 index 3 1 roll put
-			}for
-			put	setcolorspace
-		} if
-		currentdict
-		Operator /imagemask eq{
-			AGMIMG_&imagemask
-		}{
-			use_mask {
-				level3 {process_mask_L3 AGMIMG_&image}{masked_image_simulation}ifelse
-			}{
-				AGMIMG_&image
-			}ifelse
-		}ifelse
-	end end
-}def
-  /OPIimage
-  {
-  	dup type /dicttype ne{
-  		10 dict begin
-  			/DataSource xdf
-  			/ImageMatrix xdf
-  			/BitsPerComponent xdf
-  			/Height xdf
-  			/Width xdf
-  			/ImageType 1 def
-  			/Decode [0 1 def]
-  			currentdict
-  		end
-  	}if
-  	dup begin
-  		/NComponents 1 cdndf
-  		/MultipleDataSources false cdndf
-  		/SkipImageProc {false} cdndf
-  		/HostSepColorImage false cdndf
-  		/Decode [
-  				0
-  				currentcolorspace 0 get /Indexed eq{
-  					2 BitsPerComponent exp 1 sub
-  				}{
-  					1
-  				}ifelse
-  		] cdndf
-  		/Operator /image cdndf
-  	end
-  	/sep_colorspace_dict AGMCORE_gget null eq{
-  		imageormask
-  	}{
-  		gsave
-  		dup begin invert_image_samples end
-  		sep_imageormask
-  		grestore
-  	}ifelse
-  }def
-/cachemask_level2
-{
-	3 dict begin
-	/LZWEncode filter /WriteFilter xdf
-	/readBuffer 256 string def
-	/ReadFilter
-		currentfile
-		0 (%EndMask) /SubFileDecode filter
-		/ASCII85Decode filter
-		/RunLengthDecode filter
-	def
-	{
-		ReadFilter readBuffer readstring exch
-		WriteFilter exch writestring
-		not {exit} if
-	}loop
-	WriteFilter closefile
-	end
-}def
-/cachemask_level3
-{
-	currentfile
-	<<
-		/Filter [ /SubFileDecode /ASCII85Decode /RunLengthDecode ]
-		/DecodeParms [ << /EODCount 0 /EODString (%EndMask) >> null null ]
-		/Intent 1
-	>>
-	/ReusableStreamDecode filter
-}def
-/spot_alias
-{
-	/mapto_sep_imageormask
-	{
-		dup type /dicttype ne{
-			12 dict begin
-				/ImageType 1 def
-				/DataSource xdf
-				/ImageMatrix xdf
-				/BitsPerComponent xdf
-				/Height xdf
-				/Width xdf
-				/MultipleDataSources false def
-		}{
-			begin
-		}ifelse
-				/Decode [/customcolor_tint AGMCORE_gget 0] def
-				/Operator /image def
-				/HostSepColorImage false def
-				/SkipImageProc {false} def
-				currentdict
-			end
-		sep_imageormask
-	}bdf
-	/customcolorimage
-	{
-		Adobe_AGM_Image/AGMIMG_colorAry xddf
-		/customcolor_tint AGMCORE_gget
-		bdict
-			/Name AGMIMG_colorAry 4 get
-			/CSA [ /DeviceCMYK ]
-			/TintMethod /Subtractive
-			/TintProc null
-			/MappedCSA null
-			/NComponents 4
-			/Components [ AGMIMG_colorAry aload pop pop ]
-		edict
-		setsepcolorspace
-		mapto_sep_imageormask
-	}ndf
-	Adobe_AGM_Image/AGMIMG_&customcolorimage /customcolorimage load put
-	/customcolorimage
-	{
-		Adobe_AGM_Image/AGMIMG_override false put
-		dup 4 get map_alias{
-			/customcolor_tint AGMCORE_gget exch setsepcolorspace
-			pop
-			mapto_sep_imageormask
-		}{
-			AGMIMG_&customcolorimage
-		}ifelse			
-	}bdf
-}def
-/snap_to_device
-{
-	6 dict begin
-	matrix currentmatrix
-	dup 0 get 0 eq 1 index 3 get 0 eq and
-	1 index 1 get 0 eq 2 index 2 get 0 eq and or exch pop
-	{
-		1 1 dtransform 0 gt exch 0 gt /AGMIMG_xSign? exch def /AGMIMG_ySign? exch def
-		0 0 transform
-		AGMIMG_ySign? {floor 0.1 sub}{ceiling 0.1 add} ifelse exch
-		AGMIMG_xSign? {floor 0.1 sub}{ceiling 0.1 add} ifelse exch
-		itransform /AGMIMG_llY exch def /AGMIMG_llX exch def
-		1 1 transform
-		AGMIMG_ySign? {ceiling 0.1 add}{floor 0.1 sub} ifelse exch
-		AGMIMG_xSign? {ceiling 0.1 add}{floor 0.1 sub} ifelse exch
-		itransform /AGMIMG_urY exch def /AGMIMG_urX exch def			
-		[AGMIMG_urX AGMIMG_llX sub 0 0 AGMIMG_urY AGMIMG_llY sub  AGMIMG_llX AGMIMG_llY] concat
-	}{
-	}ifelse
-	end
-} def
-level2 not{
-	/colorbuf
-	{
-		0 1 2 index length 1 sub{
-			dup 2 index exch get
-			255 exch sub
-			2 index
-			3 1 roll
-			put
-		}for
-	}def
-	/tint_image_to_color
-	{
-		begin
-			Width Height BitsPerComponent ImageMatrix
-			/DataSource load
-		end
-		Adobe_AGM_Image begin
-			/AGMIMG_mbuf 0 string def
-			/AGMIMG_ybuf 0 string def
-			/AGMIMG_kbuf 0 string def
-			{
-				colorbuf dup length AGMIMG_mbuf length ne
-					{
-					dup length dup dup
-					/AGMIMG_mbuf exch string def
-					/AGMIMG_ybuf exch string def
-					/AGMIMG_kbuf exch string def
-					} if
-				dup AGMIMG_mbuf copy AGMIMG_ybuf copy AGMIMG_kbuf copy pop
-			}
-			addprocs
-			{AGMIMG_mbuf}{AGMIMG_ybuf}{AGMIMG_kbuf} true 4 colorimage	
-		end
-	} def			
-	/sep_imageormask_lev1
-	{
-		begin
-			MappedCSA 0 get dup /DeviceRGB eq exch /DeviceCMYK eq or has_color not and{
-				{
-					255 mul round cvi GrayLookup exch get
-				} currenttransfer addprocs settransfer
-				currentdict imageormask
-			}{
-				/sep_colorspace_dict AGMCORE_gget/Components known{
-					MappedCSA 0 get /DeviceCMYK eq{
-						Components aload pop
-					}{
-						0 0 0 Components aload pop 1 exch sub
-					}ifelse
-					Adobe_AGM_Image/AGMIMG_k xddf
-					Adobe_AGM_Image/AGMIMG_y xddf
-					Adobe_AGM_Image/AGMIMG_m xddf
-					Adobe_AGM_Image/AGMIMG_c xddf
-					AGMIMG_y 0.0 eq AGMIMG_m 0.0 eq and AGMIMG_c 0.0 eq and{
-						{AGMIMG_k mul 1 exch sub} currenttransfer addprocs settransfer
-						currentdict imageormask
-					}{
-						currentcolortransfer
-						{AGMIMG_k mul 1 exch sub} exch addprocs 4 1 roll
-						{AGMIMG_y mul 1 exch sub} exch addprocs 4 1 roll
-						{AGMIMG_m mul 1 exch sub} exch addprocs 4 1 roll
-						{AGMIMG_c mul 1 exch sub} exch addprocs 4 1 roll
-						setcolortransfer
-						currentdict tint_image_to_color
-					}ifelse
-				}{
-					MappedCSA 0 get /DeviceGray eq {
-						{255 mul round cvi ColorLookup exch get 0 get} currenttransfer addprocs settransfer
-						currentdict imageormask
-					}{
-						MappedCSA 0 get /DeviceCMYK eq {
-							currentcolortransfer
-							{255 mul round cvi ColorLookup exch get 3 get 1 exch sub} exch addprocs 4 1 roll
-							{255 mul round cvi ColorLookup exch get 2 get 1 exch sub} exch addprocs 4 1 roll
-							{255 mul round cvi ColorLookup exch get 1 get 1 exch sub} exch addprocs 4 1 roll
-							{255 mul round cvi ColorLookup exch get 0 get 1 exch sub} exch addprocs 4 1 roll
-							setcolortransfer
-							currentdict tint_image_to_color
-						}{
-							currentcolortransfer
-							{pop 1} exch addprocs 4 1 roll
-							{255 mul round cvi ColorLookup exch get 2 get} exch addprocs 4 1 roll
-							{255 mul round cvi ColorLookup exch get 1 get} exch addprocs 4 1 roll
-							{255 mul round cvi ColorLookup exch get 0 get} exch addprocs 4 1 roll
-							setcolortransfer
-							currentdict tint_image_to_color
-						}ifelse
-					}ifelse
-				}ifelse
-			}ifelse
-		end
-	}def
-	/sep_image_lev1_sep
-	{
-		begin
-			/sep_colorspace_dict AGMCORE_gget/Components known{
-				Components aload pop
-				Adobe_AGM_Image/AGMIMG_k xddf
-				Adobe_AGM_Image/AGMIMG_y xddf
-				Adobe_AGM_Image/AGMIMG_m xddf
-				Adobe_AGM_Image/AGMIMG_c xddf
-				{AGMIMG_c mul 1 exch sub}
-				{AGMIMG_m mul 1 exch sub}
-				{AGMIMG_y mul 1 exch sub}
-				{AGMIMG_k mul 1 exch sub}
-			}{
-				{255 mul round cvi ColorLookup exch get 0 get 1 exch sub}
-				{255 mul round cvi ColorLookup exch get 1 get 1 exch sub}
-				{255 mul round cvi ColorLookup exch get 2 get 1 exch sub}
-				{255 mul round cvi ColorLookup exch get 3 get 1 exch sub}
-			}ifelse
-			AGMCORE_get_ink_data currenttransfer addprocs settransfer
-			currentdict imageormask_sys
-		end
-	}def
-	/indexed_imageormask_lev1
-	{
-		/indexed_colorspace_dict AGMCORE_gget begin
-		begin
-			currentdict
-			MappedCSA 0 get dup /DeviceRGB eq exch /DeviceCMYK eq or has_color not and{
-				{HiVal mul round cvi GrayLookup exch get HiVal div} currenttransfer addprocs settransfer
-				imageormask
-			}{
-				MappedCSA 0 get /DeviceGray eq {
-					{HiVal mul round cvi Lookup exch get HiVal div} currenttransfer addprocs settransfer
-					imageormask
-				}{
-					MappedCSA 0 get /DeviceCMYK eq {
-						currentcolortransfer
-						{4 mul HiVal mul round cvi 3 add Lookup exch get HiVal div 1 exch sub} exch addprocs 4 1 roll
-						{4 mul HiVal mul round cvi 2 add Lookup exch get HiVal div 1 exch sub} exch addprocs 4 1 roll
-						{4 mul HiVal mul round cvi 1 add Lookup exch get HiVal div 1 exch sub} exch addprocs 4 1 roll
-						{4 mul HiVal mul round cvi		 Lookup exch get HiVal div 1 exch sub} exch addprocs 4 1 roll
-						setcolortransfer
-						tint_image_to_color
-					}{
-						currentcolortransfer
-						{pop 1} exch addprocs 4 1 roll
-						{3 mul HiVal mul round cvi 2 add Lookup exch get HiVal div} exch addprocs 4 1 roll
-						{3 mul HiVal mul round cvi 1 add Lookup exch get HiVal div} exch addprocs 4 1 roll
-						{3 mul HiVal mul round cvi 		Lookup exch get HiVal div} exch addprocs 4 1 roll
-						setcolortransfer
-						tint_image_to_color
-					}ifelse
-				}ifelse
-			}ifelse
-		end end
-	}def
-	/indexed_image_lev1_sep
-	{
-		/indexed_colorspace_dict AGMCORE_gget begin
-		begin
-			{4 mul HiVal mul round cvi		 Lookup exch get HiVal div 1 exch sub}
-			{4 mul HiVal mul round cvi 1 add Lookup exch get HiVal div 1 exch sub}
-			{4 mul HiVal mul round cvi 2 add Lookup exch get HiVal div 1 exch sub}
-			{4 mul HiVal mul round cvi 3 add Lookup exch get HiVal div 1 exch sub}
-			AGMCORE_get_ink_data currenttransfer addprocs settransfer
-			currentdict imageormask_sys
-		end end
-	}def
-}if
-end
-systemdict /setpacking known
-{
-	setpacking
-} if
-%%EndResource
-currentdict Adobe_AGM_Utils eq {end} if
-%%EndProlog
-%%BeginSetup
-Adobe_AGM_Utils begin
-2 2010 Adobe_AGM_Core/doc_setup get exec
-Adobe_CoolType_Core/doc_setup get exec
-Adobe_AGM_Image/doc_setup get exec
-currentdict Adobe_AGM_Utils eq {end} if
-%%EndSetup
-%%Page: Alternate-ISC-logo-v2.ai 1
-%%EndPageComments
-%%BeginPageSetup
-/currentdistillerparams where
-{pop currentdistillerparams /CoreDistVersion get 5000 lt} {true} ifelse
-{ userdict /AI11_PDFMark5 /cleartomark load put
-userdict /AI11_ReadMetadata_PDFMark5 {flushfile cleartomark } bind put}
-{ userdict /AI11_PDFMark5 /pdfmark load put
-userdict /AI11_ReadMetadata_PDFMark5 {/PUT pdfmark} bind put } ifelse
-[/NamespacePush AI11_PDFMark5
-[/_objdef {ai_metadata_stream_123} /type /stream /OBJ AI11_PDFMark5
-[{ai_metadata_stream_123}
-currentfile 0 (%  &&end XMP packet marker&&)
-/SubFileDecode filter AI11_ReadMetadata_PDFMark5
-<?xpacket begin='' id='W5M0MpCehiHzreSzNTczkc9d'?><x:xmpmeta xmlns:x='adobe:ns:meta/' x:xmptk='XMP toolkit 3.0-29, framework 1.6'>
-<rdf:RDF xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#' xmlns:iX='http://ns.adobe.com/iX/1.0/'>
-
- <rdf:Description rdf:about='uuid:8aa76b3d-2474-11d9-a8a3-000393cd9a96'
-  xmlns:pdf='http://ns.adobe.com/pdf/1.3/'>
-  <pdf:Producer>Adobe PDF library 6.66</pdf:Producer>
- </rdf:Description>
-
- <rdf:Description rdf:about='uuid:8aa76b3d-2474-11d9-a8a3-000393cd9a96'
-  xmlns:tiff='http://ns.adobe.com/tiff/1.0/'>
- </rdf:Description>
-
- <rdf:Description rdf:about='uuid:8aa76b3d-2474-11d9-a8a3-000393cd9a96'
-  xmlns:xap='http://ns.adobe.com/xap/1.0/'
-  xmlns:xapGImg='http://ns.adobe.com/xap/1.0/g/img/'>
-  <xap:CreateDate>2004-10-06T16:15:40-07:00</xap:CreateDate>
-  <xap:ModifyDate>2004-10-22T21:51:43Z</xap:ModifyDate>
-  <xap:CreatorTool>Illustrator</xap:CreatorTool>
-  <xap:MetadataDate>2004-10-06T16:15:40-07:00</xap:MetadataDate>
-  <xap:Thumbnails>
-   <rdf:Alt>
-    <rdf:li rdf:parseType='Resource'>
-     <xapGImg:format>JPEG</xapGImg:format>
-     <xapGImg:width>256</xapGImg:width>
-     <xapGImg:height>152</xapGImg:height>
-     <xapGImg:image>/9j/4AAQSkZJRgABAgEASABIAAD/7QAsUGhvdG9zaG9wIDMuMAA4QklNA+0AAAAAABAASAAAAAEA&#xA;AQBIAAAAAQAB/+4ADkFkb2JlAGTAAAAAAf/bAIQABgQEBAUEBgUFBgkGBQYJCwgGBggLDAoKCwoK&#xA;DBAMDAwMDAwQDA4PEA8ODBMTFBQTExwbGxscHx8fHx8fHx8fHwEHBwcNDA0YEBAYGhURFRofHx8f&#xA;Hx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f/8AAEQgAmAEAAwER&#xA;AAIRAQMRAf/EAaIAAAAHAQEBAQEAAAAAAAAAAAQFAwIGAQAHCAkKCwEAAgIDAQEBAQEAAAAAAAAA&#xA;AQACAwQFBgcICQoLEAACAQMDAgQCBgcDBAIGAnMBAgMRBAAFIRIxQVEGE2EicYEUMpGhBxWxQiPB&#xA;UtHhMxZi8CRygvElQzRTkqKyY3PCNUQnk6OzNhdUZHTD0uIIJoMJChgZhJRFRqS0VtNVKBry4/PE&#xA;1OT0ZXWFlaW1xdXl9WZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3OEhYaHiImKi4yNjo+Ck5SVlpeYmZ&#xA;qbnJ2en5KjpKWmp6ipqqusra6voRAAICAQIDBQUEBQYECAMDbQEAAhEDBCESMUEFURNhIgZxgZEy&#xA;obHwFMHR4SNCFVJicvEzJDRDghaSUyWiY7LCB3PSNeJEgxdUkwgJChgZJjZFGidkdFU38qOzwygp&#xA;0+PzhJSktMTU5PRldYWVpbXF1eX1RlZmdoaWprbG1ub2R1dnd4eXp7fH1+f3OEhYaHiImKi4yNjo&#xA;+DlJWWl5iZmpucnZ6fkqOkpaanqKmqq6ytrq+v/aAAwDAQACEQMRAD8AiX5AfkB5O/MTydea1rV5&#xA;qNvdW+oyWSJZSQJGY0ghlBIlhmblymPfMfLlMTQbIQBDOPM//OKX5U6B5e1DWZ9R1uSOxhaX0hcW&#xA;il2H2U5G0NOTUFcOCcskxAVuWOaoQMj0Y1+Wf5EflJ56N+kUuvWEtgImZHu7OTmJS4+Glmv2eG+3&#xA;fMvXYJ6etwb8v2uPpNRHNdCqZz/0Jp+WH/V01v8A5H2n/ZLmv/MSczww7/oTT8sP+rprf/I+0/7J&#xA;cfzEl8MO/wChNPyw/wCrprf/ACPtP+yXH8xJfDDAfzv/AOcc/JHkPyHN5g0i+1Oe9juIYVju5bd4&#xA;uMrUYkRwRNXw+LJ48xkaRKAAfT/5V/8AksPKH/bE07/qEjzJaiynFXYq7FXYq7FXYq7FXYq7FXYq&#xA;7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq+BfyU/MTzH5Nhnn0yUPbSzt9ZsZqtBJ8CAMVBFGHZ&#xA;hv8ARtmz0uihnwkS58XPryDrdVqp4sorlXL5st1/z/8AmP5whlgu7p20+b7VnCqwW9AwYL250YD7&#xA;TE5eI6TSncgS+Zccy1OoGwPD8ggfLXmTzl5HvJLzTD9X9YKtwroksUiqSVVjvTc9iDlkp6bVjhsS&#xA;+wsIxz6Y3Vfc9B1b/nJjWZ9Hhh03TYrPVmH+lXTt6sQp/vqM/wA3+UTT365iY+w4CVyNx7v1uTPt&#xA;eRjsKk9s8j+YrjzH5W0/Wbm0aymu4wzwtsCRsXTcng1KrXemaHV4RiyGAN07jT5TkgJEVae5jNzx&#xA;v/nLL/yT91/zG2v/ABM5dg+pjPk9M/Kv/wAlh5Q/7Ymnf9QkeZzjllOKuxV2KuxV2KuxV2KuxV2K&#xA;uxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV+eX5W6Yl7aztLvBDMSy/zEqtB8tsyJ644NP6fr&#xA;lI18hZcX8oMuf1fTGP6S9h0Ly3rGtzm20q1M7RgF6UVEXtyZiFHTbOa3ke8u52Adr3lvWNEnFtqt&#xA;qYWkUlCSGRx3oykqeu+DeJ7iuxDANasU07UIriJFaF29RYmAK8kILKVPVc7bsjWnUYiJfVHY/oLy&#xA;/aOlGHIDH6S+zNB1K31TRNP1K2UJb3lvFPEg6KsiBgu38taZzGaBhMxPMF6DHMSiCOoR2VM3jf8A&#xA;zll/5J+6/wCY21/4mcuwfUxnyemflX/5LDyh/wBsTTv+oSPM5xyynFXYq7FXYq7FXYq7FXYq7FXY&#xA;q7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq+A/yedP0NepT4xccie5BRR+FMxNfE8ET0uX+9bNP&#xA;IcZHWh+l9K/kxr2kW1neaZcSxwXskwmjaQhfUUqF4qT1Kla098wMUg5Mgq/nNrujzada6XDKk9+s&#xA;4mbgQ3pIEZaMR0Lcht9PhjlIWIeCebnQQ26U+MszA+AAAP31zoPZyJ4pnps6ftqQqI67s3/KGD81&#xA;YPMejRFNVh8ts6tKJ0mFp6HAsOPqDgFYUoVzYdonTGEvp4/hduJoRnE4/VwfY+lCyggEgE9B45yr&#xA;0Lxb/nLe8tYvyoe2kkCz3N7bmCM9W9NqtT5A5bhI4wFlAmBI5B6l+Vf/AJLDyh/2xNO/6hI8z3EL&#xA;y3/nLq+1nQPJem69oWsalpWoyapHZytZX11BG8UltM5BijkVK8oFoaePjir0v8ooJB+W/lq8nu7u&#xA;9vNR0uyvLy5vbme6keaeBZXPKZ34jk52XbFWYYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7F&#xA;XYq7FXYq7FXYq7FX5z/l3fy2Nq88Y5D1mDodgylE2zaafSR1GnMJfztvI0HWanUSw5xIfzf0l6Zb&#xA;a3plwnITrGe6SkIR9+x+jOdz9k6jGa4TId43dti7QwzF8Ve/Zq61zTLdORmWU9kiIcn7th9Jw6fs&#xA;nUZD9PCO+W37Vzdo4YDnfu3S3y5bW3mjzpptlqVwtnZ3U6xO5JoEFTwBAPxP9kH+Y+GdXDCNJpyI&#xA;CyBfvPf+Ojz5ynU5xxbAvozTPzt/L2W4vbT60bO109R6E8qFY5kX4SIVUF9uylakduucN+aiSbfQ&#xA;Z9gamMYkC+LoOnveJeYvzDnP5kTeatBmlMUUoayS7qRxMYSRCgbZHPLYHp4HMKWT18Qet03Zo/Kj&#xA;DkA5b179vixD84/zA8y+btFi/TEsbJaSVt44o1jVTIRy6bn7I6nMzRZJSyi+4un7Y7OxabSS8Mcz&#xA;G32N+Vf/AJLDyh/2xNO/6hI83jwxeUf85q/+Ss0r/tuW/wD1CXeKvVfyn/8AJWeTf+2Hpv8A1CR4&#xA;q8j8x/nX5n8ifnH5nGr28+o/l4tzp9rNKnxtp082nwSckAqQklWYp0Y1K/FUFV7F5gutN1/yJe6h&#xA;pmoSNaT2M1xY6jp1zJC1fRfi6SwMh2PY9+o2xVjP5faLe+ZPyb8tx3WtanDPqNraXmo6jHeXBvpD&#xA;QSMqXLSGSIOwAbifs1HeuKvOfzm0m/8ALHnz8tdI0fzJ5hhsfMmqG01aNta1GQyRC4tI6KzTEp8M&#xA;77rir2bQfIEWia5+kbXWtYurZ7SW2msNQ1G7voS7yROkyC4kk4OgjZajs2KvH9Is9R1n/nJrzd5Q&#xA;utf12Py9p+mRXtnZQavqEQjmaOxJIZZg1K3D7Vpvir2Xy/5JTSdO1PTZdW1PUbS9ujcW8l3fXUlz&#xA;bxmGKMwpcmT1uIkjZx8X7WKvB/8AnH/RPMX5gflhrGqaj5x8wQa/BqE9rYagNWvfTjEdtBLH6kLS&#xA;NG685TyqtaYq9K/5xr86+aPOH5Yw6n5kJlvYbqa1hvWADXMMQUrK3EAVDM0ZPfjirHPzm/M7zt5G&#xA;/M6wvNIt5NV8u22jC78waSrbCD620RuUG5R0LKC4FKfa23Cr1fyr5t8s+ePLcWraHeG5066HFzG7&#xA;RTROAC0UnAq8ci13FfwOKsS/JBbuS183fXNQv9Qaz8y6rp1s97eXFyUtbaVUijX1XYLxA6jfFWA6&#xA;RZ6jrP8Azk15u8oXWv67H5e0/TIr2zsoNX1CIRzNHYkkMswalbh9q03xV6vB+XE8Oi3+ijzJrJs7&#xA;2/S8W5e+uJL6GBI4gbWK8eQzIjSxFiQfssy964q8i/ObSb/yx58/LXSNH8yeYYbHzJqhtNWjbWtR&#xA;kMkQuLSOis0xKfDO+64q9n0DyDFoWvDU7XWtXurdrWW2m0/UdRur+Eu8kTpMq3MknF0EbLUdmxVl&#xA;WKuxV2KuxV2KuxV8tf8AOKPkvyrr35Z6zJq+mQ3k02qy2zTSL+8WJLa3dVRxRk+JyaqQcqnqsmMj&#xA;hkR1T4EJg8QtKPzn/LXS/JV9pzaXNNJaakJisc5VijQlKqGULUfvO4zoezNdLODxAXGnR6/SRwkc&#xA;PIsk/Ln8gtN17QNP17V9RnSO9VpPqMCKhCh2VaysXryVQ32B1+nMXW9ryxzMIgbdf2ORpezIziJS&#xA;PPownzdp3kO384XUWjyXMOkWbMrRg82kkiFCsEjVKhn25PWg+LfZc1uP2mIgRKPFLoeh9/7Ofk9P&#xA;H2GyT4JxkIxl9Q6x93f+hj2oXjXt9cXjIsbXEjStGleILmpArU985ORs2+nYcfhwEbJ4RW/PZG2X&#xA;l+4mAec+ih6LSrn6O2TjiJdNre38WI8MPXL7Pn+Pek/5j6Pa2nliWWMuW9WMfEQep9gM2GhxgZHm&#xA;O0u2cuoxGEhER8v7X2j+Vf8A5LDyh/2xNO/6hI83LzpeUf8AOapH/KrdKWu51yAgd6C0uv64q9V/&#xA;KYg/lZ5Np/1Y9N/6hI8VYb5Q0/SvMf5j/nBpWq2yXNhdzaVbXVq+4ZBp/p12oQTwqCNwehqMVea6&#xA;5Yeb/wAgZ9Tgtlm1r8qtdWWJVrym0+edCq1rQA1NK/ZkHg2Kvevyiiji/KrycqDip0TT2I93tY2Y&#xA;/STiryz/AJyO/wDJp/kv/wBtw/8AUXp+KvoDFXzXp/lvSfMH/OXnney1P6x6CaPbzJ9VurmyfmsG&#xA;nKKyWskLkUY/CWp3psMVe6+U/LmkeW0vdK064llV5hfGK5nluZo1nURqGlneSRlLQNxLH27Yq+XP&#xA;yK8n+e9f/IrzOPKfmS5025fULiJdIRLcQ3LLa2zOPXaP6xE8qNwqkqjYV74q93/Ij8xPLvmnyhBp&#xA;tjaR6Pq2hItnqnl9FMZtnj+CqI3xemxB3O4NQ2+KqFxLDN/zkwllKitGfJMpYPQhxLqiqUKkb7R4&#xA;q8984/l15r/JzzNP+YP5axNd+WZjy8w+WBXikIqzMgFf3a7lSByj90qMVehf8476tZ635O1fXrON&#xA;ooNZ8watqCJJTmFuLkugehI5BKA0xV57p/lvSfMH/OXnney1P6x6CaPbzJ9VurmyfmsGnKKyWskL&#xA;kUY/CWp3psMVe6+U/LmkeW0vdK064llV5hfGK5nluZo1nURqGlneSRlLQNxLH27Yq8e/5yO/8mn+&#xA;S/8A23D/ANRen4q+gMVdirsVdirsVdirsVfOv/OGn/ksNU/7bc//AFCWuYeo+pux8ntWreX9C1hE&#xA;TVtOttQWLl6X1mFJeHOnLhzB41oOmQx5pw+kke5M8UZ/UAUFq3mDyp5P0+zhv7iLTLI0t7KMIxUB&#xA;F+yqxq1AB36ZTlzC7kdy5ek0OTN6cUb4Q+XvzM13S9c866lqGmRJHZO4SOSMcfWKDi0xG28h36dO&#xA;u+arLIGRIfRey9PPDp4xmfV93l8EHoGmqVF5KtTX9yD2p+1/TJ4odXS9vdpkHwYH+t+r9f8AanuZ&#xA;DyTEPzS/5RKX/jNF/wASzJ0f1teb6X2H+Vf/AJLDyh/2xNO/6hI82zhlb51/K3yR52EK+aLGXUYr&#xA;ducMBvLyGJXpx5CKGaNOVO9MVTHy15Q0Ly1p0em6MlxBYQp6UFvJd3VwkaDosYnll4AduOKoTRfy&#xA;68p6Lr1/r2m29xDq2qFG1G4a9vZfXMYIT1ElmeNuAYhart2xVPNS03T9TsJ9P1G3ju7G6QxXFtMo&#xA;eN0bYqynYjFWtK0yx0rTLPS9Pi9CwsII7W0hBZgkMKBI1qxZjxVQNzXFWO+avys8j+a9VstV16xm&#xA;u7/TW9TT5heXkIgcFTyiSGaNENY1NQOoxVlFvAkEKQoXKIKAyO8jfS7lmP0nFWDXn5Gflnd69P5g&#xA;n066Ot3NPW1FNT1KOZqKEHxpcqacVAxVO9F8g+WdFsr6z02K5ij1Fle8le+vZZ3ZAFWlxLM8y0Ap&#xA;RXGKqPkr8s/JfkmGWDyxZSafbzuZZbf63dzRNIVCl/TmlkTlxUCtMVWXX5XeRbjzT/ir9Gm28wkF&#xA;ZNRs7i5s5JAQAfVFtJEslaCvMHFVWb8ufKU3mtfNklvcnzAkRt0vhfXqlYCxcxCMTCMR8mJ4caYq&#xA;yUgEUO4PUYql2g+W9D8v2cllotlHYWck0lw1vCCsYklNXKrWignstBirFLz8jPyzu9en8wT6ddHW&#xA;7mnraimp6lHM1FCD40uVNOKgYqyLyx5N8v8AllLpNHhmjN66y3Ulxc3N5I7KvFayXUkz0A7A0xVL&#xA;vNX5WeR/Neq2Wq69YzXd/prepp8wvLyEQOCp5RJDNGiGsamoHUYqyi3gSCFIULlEFAZHeRvpdyzH&#xA;6TiqpirsVdirsVdirsVfOv8Azhp/5LDVP+23P/1CWuYeo+pux8nvOY7Y8/8Azo8q6Nq/lK61O/eW&#xA;O40aCaayeJqLzYCiupqCGZVB75j6mAMbPR3XYeryYs4hGqmQC+XIYmlmjiX7UjBR82NM1z3+XIIR&#xA;MjyAtmqIqIqIKKoCqPADYZmgU+X5MhnIyPMm12Fghvzc8i6jZ/lNJ5hvHEKS3FsLe1pV2SRtnY1+&#xA;HboMy9JH1W1ZTs+nfyr/APJYeUP+2Jp3/UJHm0cQph5t84eXfKWjSaxr94tnZIwRWILvJI32Y441&#xA;DO7t2Cj8MVYZqX57aRpCQXOs+V/Mel6ZcOkUep3ViiwBpCAgfjM0sfIttzQYq9MxV2KuxV2KuxV2&#xA;KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KvnX/nDT/wAlhqn/AG25/wDqEtcw9R9Tdj5P&#xA;ecx2x4p+e3lfzteTXGr2dy7eXLa1Q3NoJ2ChkY839H7J6jf2zC1MJXfR6z2f1eniBCQ/emWxr9Lw&#xA;yw/3utv+Mqf8SGYkeYen1wvBP+pL7mZZmvmTsVZ7/wA5N6hZ6h+Rn12zINtNc2bRhabDkfh27r0O&#xA;bDTm5Boyci9X/Kv/AMlh5Q/7Ymnf9QkeZ7jF43/zl1Lrmk3vkTzVBAbvSNC1Fp7m3IPpfWFeGWES&#xA;0rtIsLqK9PpxV6v5X84+R/zX8mXB06cXFleRGDULJqLc27Ov2ZENeLKd0bcGlQTiqF1P85dE0r8w&#xA;NN8j6ppGp2OpauwXTr6ZLX6lKDWhWVbhm+0OPHhyrTbcYqnfn7z3pvkrRYtWv7S7vo5rmGyhtbBY&#xA;pLiSa4PGNUjlkh5knspJ9sVa1vz9pOg6TZX2t29zY3WozJbWGjlY576a4k+zFHHbPOrN40eg7nFV&#xA;C2/MOI6rHp2p6DqujGaGa5hur2O2Nu0cCeo/7y3nuOLcd+D0b2xVj+t/njDofl6TzFq/kvzJZaPC&#xA;sby3M0OnrxEzrGnKP676gq7qKccVRNp+cf1rSrPWU8meYho97HDPFf8Ao2DRiC4CskzLHePIE4sG&#xA;Y8dh1xVW8+/nFpHknXNH0bUtG1S7u9flNvpDWS2jpPMGjTgPUuYmU8p0HxAdcVR+kfmFNfa7a6Pe&#xA;eV9a0aW9SV7e6v47P6uTCvJkL29zcEMR0FMVTTW/OGiaLrWiaPqEpiu/MEssGnGg4GSGP1CrGu3I&#xA;bLtudsVTvFUj8u+cdD8w3utWelymWTQb06ffNQcfXWNXbgQTUKX4GtPiU/MqobzF5/0XRdZtNBEV&#xA;zqfmC+jae30iwjEs/oKeLTSF2jiij5bcpHUE9MVVPLXnBNb1HUdNl0nUNH1DTEgkuLfUY4V5JcmV&#xA;Y3ikt5biKRawOCVfFWQ4q7FXYq7FXYq7FXYq7FXYq+df+cNP/JYap/225/8AqEtcw9R9Tdj5Pecx&#xA;2x51+eHmy/0HysLa2sUuYdZE1jPPIW4xCSOlAi05MyluPxbU6HMfUzMRXe7zsHRxzZrMqMKlXfu+&#xA;YCHR6EFXU7g7EEZrn0AgEeTMrO5W5to5l/bHxAdj3H35mRlYfNNbpjgyygenL3dFbJOIxj80NQvk&#xA;8i3Fis7izluIXe35HgWVtm49K++ZWj+trzfS+u/yr/8AJYeUP+2Jp3/UJHm1cMpxrekaHr2nXeh6&#xA;vbxX1lcxgXdlLQ1jcnixA+JfiQ8WHcbbjFXx/wCefJXmT/nHvz/p3mzy1cyXHli9mMSo7fEU+1JZ&#xA;XIFA1UFUf2rsVxV9Efnb+XUf5geRuWnEx6/ptNR8vXa1WRZlAb0ww+IeqAB7NxPbFWLfk35j1D83&#xA;LrTPOOsxenY+VIhaW9r+xNrTxA3N5xB+ykLqIlP2S7HFU7/Pv8vvN/mO20LzF5MuBH5o8p3El3YW&#xA;zlQswlCc1Bf4OX7paB/hIqD1xVA/lD+ek/mzXn8necdGOh+drBWlELIyxSlFIdo1kq8T8GJpUgrU&#xA;hqbYqmH/ADlH/wCSJ8zf9GP/AHULfFWVflQA35VeTlYVB0LTQQehH1OPFXkn/OTk89v+Y35Pz29u&#xA;95PFrEjw2kbIjyut1YFY1aRkQFzsCzAeJxV61onm/wAwahr0Ol6n5SvdFR4JrlLy6uLKaP8AcsiF&#xA;V+qzXB5H1h1ptirxr/nJzRvMHmLzXZRaFM8eoeTNDm8ywrGKuXN7DH8BrXmEt3kX4TulO+Ks6i/O&#xA;car+TVj5q0dFk8x6z6el6fp43/3MzH0fTof2Uesu/wDusVxVhn/OMdldeWPP/wCYvkq8uWu5rOe3&#xA;uVuXJ5SGsgkkIPd/UQ4qmv5xeUPzP0Pz/b/mj+XcS6ldrZDT9X0dl9RpIUfn8EYKtIrUWqoeYK1F&#xA;a7Ksv/Jv839H/MewvZVsW0rzDphSDWNOloXQ1fgVchWZOQfZgCpqCO5VejYq7FXYq7FXYq7FXYq7&#xA;FXYq+df+cNP/ACWGqf8Abbn/AOoS1zD1H1N2Pk95zHbGiqkgkAlTUHwNKfxxS+UPzkutEufzA1KT&#xA;SkdOLCO+5rwU3UfwylFNDTYVr1apzV5iOI0+jdiQyR00RP4f1ejGNK1RrOQq9Wgf7Sjsf5hkYTpe&#xA;1ezBqY2Nsg5H9BZRDNFNGJImDoejDMoEF4TNgnilwzFFif5pf8olL/xmi/4lmVo/rcXN9L7D/Kv/&#xA;AMlh5Q/7Ymnf9QkebZwykHm1PzQ0f8w18xeWdIh8w6BeaZBYajpf1uO0uVnt7i4lSaJp6RfZuaHf&#xA;f2oDirH/ADj5I89/mxe6Rp3mfSI/K/k3TLpb+8tXuoru/u5kVkRF+r8ook4uwJ5k71xV7DdzSW1o&#xA;8kFs908Y/d2sJjV27UUytGg+lhirx7/nGDyX5z8keT7/AEHzPo0thcz6lLexTie0miMb28MYH7ma&#xA;R+XKE/s4qzXzNqX5haV5piutG0L/ABB5euLRIrq2huoLa5guY5Xb1Y1uWjidWRwGHMHb23VY/pvk&#xA;zzH5j/NnTvzB1/SU0CDQbGSz0ywaaK4vJpZxIjyTvbs8KIkcrBUDtua1xVGf85AeXvMnmb8r9V8u&#xA;eXtNk1HUtSNuIwstvCiCC6hnYu08kXVYzTjXFU9/LC11iw8haBpGr6bLpt/pWnWllcRyyW8oaS3h&#xA;WJijQSSgiqV3p1xV5z+fXlHz/r/nbyHq/lny9JqsHlO+a/umN1Z26y1mtZljT1plf/j3YElcVZ/p&#xA;3mfz3qGr6fay+TrrRtPeR21HULy70+ZUjWJyqpHbXE0jM8vBelAN8VSnyzpHmVvzd8z+YNU0S4tN&#xA;Jv7KxsNKuZJbSRSluJHnMkcVxI68pHAX4DXvTFWOflr+Q0vlP8ytZ1R5eflS3ma78q6dyDJFc3iB&#xA;LiUx/stCiekh7qcVdZ+TPO2hf85H635ztNElvfK+uWEdrNPBPaKVlWKD4/Rlmhf7dvStD9onFWXX&#xA;ut/mbpHmnWI4/K7+YfLtzJFNpNzZ3tpDNCBbRRywyxXckAoZkd1Kt3xVB/lr5C1ew84eavPWu28O&#xA;nap5nkhWLSbdxKttb26BAZJFCq8spHJ+OwPc1xV6RirsVdirsVdirsVdirsVdir51/5w0/8AJYap&#xA;/wBtuf8A6hLXMPUfU3Y+T3nMdsQGoa9omnT29vf30FrcXTrHbQyyKryO7cVCKTU1O2WwwzkCYgkB&#xA;hLJGJomrQd15K8p3eoXWo3WlW897ex+jczyIGZkC8e+wPHao3zGOKJNkOdDXZoxEYzIjE2Hyf5k0&#xA;uzj81alp2hRTzWkFxLHbRspaXhETy2ArQUPUVp1zWGO5p9G0+c+DGWUgSIHuspTBc3Fu/OFzG3en&#xA;eniO+AGm7Pp8eWNTAkEr896vd3Plp4JuLD1IzzpRtj7Gn4ZsNBMnJReT7d7Jw4cByQsGx12/Hxfb&#xA;v5V/+Sw8of8AbE07/qEjzePFFlOKuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV&#xA;2KuxV2KuxV86/wDOGn/ksNU/7bc//UJa5h6j6m7Hye85jtj5B/OE2S/mVrEun3KTwvKkglicOFkM&#xA;amReQJ3WSvyztuzb8CIkKeW19eMSCzGx/wCcmfMNvaWsM+k29zJDGqTztI6tKyinPYUUnqeuYM+w&#xA;4EkiRDlR7XkALDBvzG8+t5y1tNSXT49NVIkQxxkO7utfjkkCoXO9FqNhmZoezoaeyN5Hr+hp1naW&#xA;TOBAkiEeUb2vvZjpf5M+bNeg8vanNJHLYX8UL3tz6oNwkUjGQu4YDkwjYKtGY9K0zi+1cHFqZcIA&#xA;jfT7ftfRewO2oYNCIzMjkAJF7+4Wln/ORn5QaL5T8irq+k3F1KGvIYJobgo6qrh25hkRKfEoXfxy&#xA;OlwCGQENGt7ZyanBKExEcjt7w+kPyr/8lh5Q/wC2Jp3/AFCR5tnnCxj88Pzoi/LzTrSz061Gpeat&#xA;YPDSrA1KD4gvqyhSGK8moqjdjtUbnFXaF+WHnPUrGO988+dNYfV5xzmsNGuf0bZ25bf0k+rKkknD&#xA;pyL7+GKpJ5+/Lfz15b0afzB5N89a4X04fWbvTNUufr8UluhDS+m8ysyssYLDlyrSm2Kva8VdirsV&#xA;dirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVfHH5K/mFceTPyPvZrD021W98wzR2qyg&#xA;soSO0tGlYgUqKUXr+1lul0Yz5al9IH9jRqtUcWOx9RKa+aP+cgPNGu+XW0lLaLTZ5zS7vLV3BeKm&#xA;8aK1SnLueZ22za4Ox8eOfFfF3AutzdpznDhqnmkUApyfv0X+uYHavb/gyOPFRkOZ6D9r1Hs97HnU&#xA;wGbOTHGeURzkO/yH2nyVQqAEBVofYE/ed85qXbOqJvjP2Pcx9l+z4x4fCj9pPzu1jwIw+H4W/A5t&#xA;tB7RzEhHNvH+d1H4/FvOdsew+MxM9L6ZD+AmwfcTuD7yR7no/wCT/wCbcnlK4k0vWZJJNAkDsigF&#xA;3gmAJ+AdeLnYr47+Ob3tHs8ZwJwri+8PBaLWHCTCd19xX/n5+cXlzzh+Xt/pGm29zC8c1vOs1yEQ&#xA;OElClVVWc/t1zUz7MyYQJSI+Ds8WvhlJiL5Poj8q/wDyWHlD/tiad/1CR5BtL5u8+3Bv/wDnMzSL&#xA;bURW1srrTYrMP9mgt0uEpX/l4kP04q+usVaIBFDuD1GKvMPzU/MTW7LzT5d/L3yq6QeZvMzGR9Rk&#xA;QSrZWUfIyTLEdncrE/Hl8PwmuKprc/lSs9sKebPMkeohaDUE1OZfiofiNsKWp3PT0sVYX+Vv5k+d&#xA;NP8AzL1L8qfPk6alqVtGZ9F1xEETXMKp6gEqr8JJiPIECoKsGJ64qk/mP86/M/kT84/M41e3n1H8&#xA;vFudPtZpU+NtOnm0+CTkgFSEkqzFOjGpX4qgqvYvMF1puv8AkS91DTNQka0nsZrix1HTrmSFq+i/&#xA;F0lgZDsex79Rtirz6383eYPLf/OMsHm2ykn1PXhpNvdtPezS3bmacokkzGZnNIw5k49NsVVfI9jo&#xA;/nfybZavoHnbVbvzAkcMt7cDUp1CXNFd4LmwRhBGjMrLQRV4/ZJGKorzz588wal+Zenflf5Uuf0b&#xA;dzW5v9f1wIkstraAEiO3SQMnqybfEynjyFB4Kpxqn5TyT2kh07zd5isNVKn0b46lPOgfqC9rITbs&#xA;teoVF9qYqxj8kvzR806t5j1/8u/PHpyeafLvJhfwKI1urdHWMyFV4gNWRGBUCqsNgQaqsa0qz1HW&#xA;v+cmfN/k+58wa7F5fsNLjvLOzt9Xv4hHM8diSVZZq0rcOaHbfFU5/KrV/PVl+avnj8ur3WLjWtI0&#xA;i2juNN1i9P1ie3kuFjeGKSQ8WkJSY1qesZpSuKqX52eTpvJv5R6vrmkeZ/Mn6Y09bQRXk2tag9TL&#xA;dwwuzR+sI/iSRv2cVT3yT+Xh1n8v/LesnzL5ii1m+0ywv5Lg6zfyRtcSQRzNzheVozGzn4lp02FM&#xA;VY//AM5AX+sad+Zf5X22m6tqVha6/qv1XVra0vrqCKaFbmzjCmOORUX4ZnBKgVrirJv+cj5b3Sfy&#xA;d1fVdK1C+0/UdNFoLS6tby5hkAkvIYW5tHIvqVRyKvXFWUflR6z/AJa+WLu4uLi7u77S7K7urm6n&#xA;luJXmnto3kYvMztuxrQGmKsJsDej/nJi80U6lqLaPF5bXU49Oe/vGtxdC8ii9T0mlKH4CRxI4+2K&#xA;oX8/fzcvPIHm/wAivDK/6PknuZddtkJo9n+6hqyjqV9RnT/KXFXsFzrGmW2kSaxNcoumQ25u3u61&#xA;jECp6hkqP2eG+KvJf+cd/wAz9U8+XnnafUGkQQanHNY2cvW2tJ4jHDEFJ+Ha3JbsWJPc4qwz/nFD&#xA;QdH138oNY0/VrWO7tJNbn5RyDofqlrRlI3Vh2INcx55pY5iUTRZ+HGcakLDyTU7a1j1y9t7RWW0i&#xA;uJlgSQ1YRI7cQxHU8RnU6zUyxaaWT+IR+0/tdN2Xo46jWwxfwyn/ALEbn7GWflb5Oh82+bodPuiR&#xA;Ywo11ehTRmijKjgDsRyZ1Wo7Z5tihxy3fae1dZ+VwcUef0x/Hk+p7Py/oVlYiwtdPt4bMLxMCxIE&#xA;I/yhT4vpzZDHECqfPZ6nJKXFKRMu+3g357/l3pegyWuu6PCLazvZDBdWqCkaTcS6NGP2Q6q1V6Cm&#xA;2YOoxCO45PY+z/aU8wOOZuURYPk8buFHIMB1G/zGdr7O6g5NPwn+A18HgfbbRRw63ijyyR4vjyP3&#xA;X8WX/mR+VFlon5Kx+a57trnUL9rKW3iQcIoormj0Nfid+JG+w9u+U63tE5JnEBUQfudfo9EIR8Qm&#xA;yR976m/Kv/yWHlD/ALYmnf8AUJHmI5heIf8AOUv5ZeY013TfzQ8qxPNeaV6LalHEC0kbWr+pBdKg&#xA;3YL0enQAHpUhV6z+U/5y+VPzE0aGayuY7fW1QfX9HdwJo5AKsUU0Mkfg4+mhxVkHnfzlpXlPQZtT&#xA;vpYxMR6en2jtxe5uX+GKGMAMxLuQDQGg3O2KvEvzwFx5K/PPyX+Z1xE7+XkjGm6jOoLiAsJomYge&#xA;MNyWXxKnFX0LZXtnfWkV5ZTx3NpOokguIWDxujbhlZSQQfbFXhOlab/i7/nKm58z6YPV0XyhYfUr&#xA;m/XeKS9khkiMKMNmZBcNy8OPyqqyDyhp+leY/wAx/wA4NK1W2S5sLubSra6tX3DINP8ATrtQgnhU&#xA;Ebg9DUYq811yw83/AJAz6nBbLNrX5Va6ssSrXlNp886FVrWgBqaV+zIPBsVe0/l3e6Lp/wCVHkSz&#xA;1Dgtvq+l6dZRxygGOSW4sRIY2DbH1OLCncmmKvHPze/Ke0/K7U9L8/8A5cXMumajLqMFmdAVyYrl&#xA;rhifSiqeXF+NGiNVp0pTFUx84T/8q9/5yis/OOsAxeWvNdqti+pN/dQyiFIOLtSi0aCNmr+yxPY4&#xA;q+jY54ZIVnjkV4HUOkqkFSpFQwYbUp3xV4P+VWlN5k/5yB88fmNZrXy6iLpOn3Y/u7meKOCGV4mG&#xA;zov1U7jb4hiqS2Wk6vqn/OXXniDStauNBuk0eCT65bRW87Mog05fTZLqOZOJLBthXbriqffkj5qf&#xA;yz5r1v8ALfzoEg85zXcl7DrT1H6YSUkpJzcmrhBRFFBxHEAFWxVkX/OUf/kifM3/AEY/91C3xVlX&#xA;5T/+Ss8m/wDbD03/AKhI8VeVf85Hf+TT/Jf/ALbh/wCovT8VZv8A85HaVeap+Snmi1s4zLOsENxw&#xA;UEnha3MVxIaDwSJjiqY/kjrFhqv5S+U57KVZUt9LtbObiQSs1rCsEqNToQ6HFWN+Xok1T/nJTzLr&#xA;Fk/rWej6Bb6PeSrui3c1wtx6XIbFkSP4h2OxxVCeavK+n+f/AM1vNXl6+/3ktPKtvp4f7XpXF7dt&#xA;dJMFr9pTbxMNv2cVYD+WeqeavNGi235IazBLDcaBfNH5mujXidFs3V47cPt8U0pWJaf7qFcVZL+W&#xA;PDRP+coPzD0FVEUOo2kOoQqo4oSBDJRen/LU3TwOKsC/5x7/ADR0byR+VF8LqGW71C61m5a0tYxx&#xA;Vgtpagl5SOKip7VPtksWglnnsaiObVm1kcMd9yWBTXZn1Ca6ICGeR3I6hfUJr91c6DXabxNPLGOf&#xA;Dt7xydZ2TrRg1mPMeQnv7jz+xmf5V+cYPKfm+HULsH6jPG1relRVljkKtyA/yXRSfbPNcU+CVvtf&#xA;a2jOpwGMfq5j8e59U2etaPe2Iv7S9gmsqBvrKSKYwD4tWg+nNkJgi7fO54JxlwyiRLup4D+fP5ga&#xA;ZrtxaaJpE4ubSwdpbq4jNYnmI4qEYbMEUt8Q23zB1GUSNDkHs/Z/s6eEHJMVKXIda/a8duGqwUGo&#xA;A3HgTna+zmnMNPxH+M38HgvbbWxzazgibGOPCf63M/oHves/m/5m0DV/+cb7S10y8WebTjpltdQH&#xA;4ZY3iURnkh3oSux6HNbqcE4ZyZD6iSGjTZYSxARPIB75+Vf/AJLDyh/2xNO/6hI8LIspxVg+v/kl&#xA;+VOvXbXupeWrRrx25vc2/O0lZ615F7ZomLe9a4qoaR+Q35S6TqUGp2nl6Nr+2dZbe4uZ7m7ZHQhk&#xA;ZfrMsoBUio8MVZvf6fYajZzWOoW0V3ZXC8J7adFkjdT2ZGBUj54qwy1/JD8s7MsLPS5bWByS9pBf&#xA;X8Vq1a15WyTrCRv0KYqy7StG0nSNOi03SrSKwsIV4xW1sgiRR7BKUPviqT6L+XXlPRdev9e023uI&#xA;dW1Qo2o3DXt7L65jBCeokszxtwDELVdu2Kp5qWm6fqdhPp+o28d3Y3SGK4tplDxujbFWU7EYqk+p&#xA;+QPJ+qeV7XytqGmR3Og2McMVnZOzkRLbJ6cPF+XqAouwblX3xVB6P+VPkTSdSt9TttPkmv7Ov1O4&#xA;vru7v2gqKfufrcs/pmn8tMVT/WtD0bXNOl03WLKHULCYUltrhFkQ+BowO47HqMVYnbfkj+WltEbe&#xA;HS5VsmrXTzfX7WdD1H1VpzBT24YqzOysrKxtYrOyt47W0gUJDbwoscaKOiqigKo+WKsXsvyo8jWX&#xA;mqfzZbWdxH5iul4XOo/X79pJEAUcHDTlWWka7EU2GKovzf8Alz5L84NaP5h0xLyexYPZ3SvLBcRM&#xA;CG/dzwPFKvxAGgbrirfmL8v/ACt5k0BdA1yC4vtJWnK3kvbwF+Lh19WRZhJLxZQRzY0xVHeXPLOj&#xA;+XNMh0vSI5YbC3RYreCW4uLgRxpsqoZ5JSoAPQYqlPmn8rfJHmnVrHV9dsprvUNMcSafMLy8hEDg&#xA;q3KJIZo0U1jU1A6jFWTRW0UVuLccniA40lZpWIP8zSFmb6TirCh+SP5ZJczXNrpD6e9weU8en3l7&#xA;YxOf8qG1mhiP/A4qyjy/5c0Ly7pqaZodjDp9ihLCCBQoLN9p2PVmPdjviqA0nyH5Z0nX77X7GG4T&#xA;VtT9P9IXEl7eTCb0UKRc45ZnjPpqxC/Dt2xVMLPy/otlq+oaxa2ccOp6qIRqN2oo8wt1KRcz/kKa&#xA;DFUmvPyw8k3fm7/GEljKnmQoIjqMF3d27lAnphSsMsaEcRTdcVfOX/OO/wCXGled/wApJ7e+mktm&#xA;svMFzJHPCFL8XsrUOnxVA5UU/Rjj1stPMkC7DDLpY5ogHoU9/M/8hodE0RNU8r/WLtLQMdRgmZZJ&#xA;TH19VOCp9n9oAdN+xzZ6Dtc5J8OShfL9TrtZ2aIR4oWa5vHIphTi/wBDf1zF7V7A8WRyYtpHmO/3&#xA;eb0vs97Yfl4DDqAZYx9MhzA7j3j7R5qoZCvLktPmK/d1znD2Nqga4D9n38nuI+1HZ5jxeLH7b+VW&#xA;sedR9j4j49vxzcdn+zkuISz7D+b+s/qeX7Z9uIcJhpbMj/Gdq9w5376rzZn+Xv5ReYPOkFzeRyCw&#xA;sYgRDdzozLNNX7C0INB+029OmdDq+0MenqNWe4dA8Dp9HPPcifiepQv5oflBrHlD8vdZ1PWJYZJP&#xA;XtLayNuxdGV5eUjnkEYEcFA27nNZrO0o5hGML7zbsdJoZYiZS+D6p/Kv/wAlh5Q/7Ymnf9QkeYbm&#xA;FlOKuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV86/wDOGn/ksNU/&#xA;7bc//UJa5h6j6m7Hye63Mxht5ZgjSmNGcRoKs3EV4qO5PbKYizTMmg+NNH8sa75q85nSVga31C7u&#xA;He8EiFfQBYtK7qeJASvT6O+dzlzww4uK7iBt5vJwwyy5OHkSfk9Lk/5xf1YT0j16BoN/jaB1f2+A&#xA;Mw/4bNUO3o19Jv3uw/kc/wA77Hk+q6PdeW/M8um6nCJJdOuAs0RFVkRWDAivVZEoR7HNxjyDLj4o&#xA;/wAQdZPGcc6l0L7Wso7SO0hSzRI7RUUW8cahECU+EKoAAFM4ORNm+b18QK25PIf+csv/ACT91/zG&#xA;2v8AxM5Zg+pE+T0z8q//ACWHlD/tiad/1CR5nOOWU4q7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FX&#xA;Yq7FXYq7FXYq7FXYq7FXYq7FXyD5H/Lj/nLDyRpMuk+XLW1tbGedrqSN5dPlJldEjLcpGY/ZiXbK&#xA;5YxI7s4ypkX1b/nNfws/v0vI+BHuZcZUv0Z/zmb9Z+tehYfWuHp+vx0r1OFa8OXXjXemHwhVb0ji&#xA;3vZV+rf85r+Fn9+l4PAj3J4yl0nlT/nLmXVv0vLp2lyaoEWMXjx6S0oVCStGIqKV6jLBYjw2eHut&#xA;rIjxcVC0x+rf85r+Fn9+l5X4Ee5s4ykfnHyH/wA5becdEfRdftrW5055ElaJZNOiPOM1U8oyrYY4&#xA;gDYQZW+m/IelXuj+R/Luk3yhL3TtMs7S6RSGCywW6RuAw2NGU7jLWsp7irsVdirsVdirsVdirsVd&#xA;irsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVf/9k=</xapGImg:image>
-    </rdf:li>
-   </rdf:Alt>
-  </xap:Thumbnails>
- </rdf:Description>
-
- <rdf:Description rdf:about='uuid:8aa76b3d-2474-11d9-a8a3-000393cd9a96'
-  xmlns:xapMM='http://ns.adobe.com/xap/1.0/mm/'>
-  <xapMM:DocumentID>uuid:c63b31d6-45fe-11d8-8e7c-000393cd9a96</xapMM:DocumentID>
- </rdf:Description>
-
- <rdf:Description rdf:about='uuid:8aa76b3d-2474-11d9-a8a3-000393cd9a96'
-  xmlns:dc='http://purl.org/dc/elements/1.1/'>
-  <dc:format>application/postscript</dc:format>
- </rdf:Description>
-
-</rdf:RDF>
-</x:xmpmeta>
-                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                <?xpacket end='w'?>
-%  &&end XMP packet marker&&
-[{ai_metadata_stream_123}
-<</Type /Metadata /Subtype /XML>>
-/PUT AI11_PDFMark5
-[/Document
-1 dict begin /Metadata {ai_metadata_stream_123} def
-currentdict end /BDC AI11_PDFMark5
-Adobe_AGM_Utils begin
-Adobe_AGM_Core/page_setup get exec
-Adobe_CoolType_Core/page_setup get exec
-Adobe_AGM_Image/page_setup get exec
-%%EndPageSetup
-Adobe_AGM_Core/AGMCORE_save save ddf
-1 -1 scale 0 -148.752 translate
-[1 0 0 1 0 0 ]  concat
-% page clip
-gsave
-newpath
-gsave % PSGState
-0 0 mo
-0 148.752 li
-254.868 148.752 li
-254.868 0 li
-clp
-[1 0 0 1 0 0 ] concat
-54.9161 147.252 mo
-1.5 147.252 li
-1.5 1.5 li
-54.9161 1.5 li
-54.9161 147.252 li
-false sop
-/0
-<<
-/Name (PANTONE 7506 C)
-/0
-[/DeviceCMYK] add_csa
-/CSA /0
-/TintMethod /Subtractive
-/TintProc null
-/MappedCSA null
-/NComponents 4
-/Components [ 0 0.05 0.15 0 ]
->>
-add_csd
-1 /0 get_csd
-sepcs
-1 sep
-f
-7.82032 17.3956 mo
-12.9034 12.8946 20.6797 13.3624 25.1856 18.4405 cv
-29.4395 23.2481 29.1768 31.1573 24.5225 35.4014 cv
-19.4395 39.9131 11.2784 39.8477 6.76954 34.7637 cv
-2.26661 29.6758 2.73926 21.9004 7.82032 17.3956 cv
-cp
-11.7549 43.3096 mo
-12.2579 48.5938 li
-16.7979 48.8663 li
-17.9268 43.7178 li
-20.3682 43.4747 22.7608 42.7344 24.8936 41.4756 cv
-28.8946 44.7803 li
-32.2999 41.7657 li
-29.4512 37.3243 li
-30.8975 35.3721 31.9356 33.1631 32.5196 30.8428 cv
-37.9678 30.3233 li
-38.2413 25.7842 li
-33.0137 24.6417 li
-32.794 22.21 32.0909 19.837 30.8458 17.6924 cv
-34.1573 13.6866 li
-31.1416 10.2813 li
-26.8135 13.0518 li
-24.8252 11.46 22.5674 10.3506 20.1846 9.75684 cv
-19.6973 4.61329 li
-15.1592 4.34083 li
-14.0616 9.35645 li
-11.6202 9.62598 9.22754 10.4092 7.04786 11.7168 cv
-3.06153 8.42383 li
-2 9.36426 li
-2 15.0967 li
-2.42969 15.7667 li
-2.27442 15.96 2.14551 16.167 2 16.3663 cv
-2 42.168 li
-5.16114 40.1416 li
-7.12208 41.6631 9.37012 42.7315 11.7549 43.3096 cv
-/1
-<<
-/Name (PANTONE 301 C)
-/CSA /0
-/TintMethod /Subtractive
-/TintProc null
-/MappedCSA null
-/NComponents 4
-/Components [ 1 0.45 0 0.18 ]
->>
-add_csd
-1 /1 get_csd
-sepcs
-1 sep
-f
-19.8682 23.167 mo
-21.6221 25.1495 21.9336 28.1055 19.6426 30.2452 cv
-17.7315 32.5264 13.9385 32.1124 12.1084 30.046 cv
-10.2051 27.9034 10.4053 24.626 12.5489 22.7256 cv
-14.6924 20.8213 17.9698 21.0293 19.8682 23.167 cv
-cp
-24.5225 35.4014 mo
-29.1768 31.1573 29.4395 23.2481 25.1856 18.4405 cv
-20.6797 13.3624 12.9034 12.8946 7.82032 17.3956 cv
-2.73926 21.9004 2.26661 29.6758 6.76954 34.7637 cv
-11.2784 39.8477 19.4395 39.9131 24.5225 35.4014 cv
-/2
-<<
-/Name (PANTONE 871 C)
-/CSA /0
-/TintMethod /Subtractive
-/TintProc null
-/MappedCSA null
-/NComponents 4
-/Components [ 0.3569 0.3608 0.6353 0.1882 ]
->>
-add_csd
-1 /2 get_csd
-sepcs
-1 sep
-f
-42.0054 124.904 mo
-38.6949 132.106 29.9537 135.87 22.7505 132.561 cv
-15.5523 129.245 12.4058 120.72 15.7144 113.527 cv
-19.0259 106.334 27.5503 103.179 34.7427 106.488 cv
-41.5435 109.62 44.98 118.187 42.0054 124.904 cv
-cp
-52.1324 108.189 mo
-46.0132 109.425 li
-44.6382 106.935 42.775 104.731 40.4371 103.029 cv
-42.0914 97.1954 li
-37.271 94.9756 li
-33.9527 99.9629 li
-31.0816 99.1973 28.1519 99.0762 25.3277 99.5635 cv
-22.3921 94.2989 li
-17.4175 96.1416 li
-18.6011 102.011 li
-16.1207 103.443 13.9351 105.404 12.2232 107.825 cv
-6.41944 106.179 li
-4.2046 111.001 li
-9.19288 114.318 li
-8.42237 117.192 8.30616 120.126 8.78467 122.94 cv
-3.52295 125.882 li
-5.36475 130.86 li
-11.2349 129.672 li
-12.6656 132.151 14.6226 134.34 17.0562 136.049 cv
-15.4068 141.854 li
-20.23 144.069 li
-23.5582 139.057 li
-26.3648 139.764 29.271 139.844 32.0865 139.344 cv
-35.1089 144.747 li
-40.0816 142.907 li
-38.8687 136.883 li
-41.3609 135.473 43.5679 133.563 45.2554 131.213 cv
-51.0806 132.864 li
-53.2984 128.045 li
-48.1685 124.64 li
-48.7964 121.878 48.8687 119.031 48.4048 116.281 cv
-53.9722 113.169 li
-52.1324 108.189 li
-1 /1 get_csd
-sepcs
-1 sep
-f
-25.3804 126.851 mo
-21.3306 124.99 19.5601 120.199 21.4234 116.152 cv
-23.2847 112.103 28.0757 110.342 32.1226 112.198 cv
-35.8609 113.921 38.1509 117.934 36.23 122.414 cv
-34.9371 126.865 29.2769 128.645 25.3804 126.851 cv
-cp
-34.7427 106.488 mo
-27.5503 103.179 19.0259 106.334 15.7144 113.527 cv
-12.4058 120.72 15.5523 129.245 22.7505 132.561 cv
-29.9537 135.87 38.6949 132.106 42.0054 124.904 cv
-44.98 118.187 41.5435 109.62 34.7427 106.488 cv
-/3
-<<
-/Name (PANTONE 1805 C)
-/CSA /0
-/TintMethod /Subtractive
-/TintProc null
-/MappedCSA null
-/NComponents 4
-/Components [ 0 0.91 1 0.23 ]
->>
-add_csd
-1 /3 get_csd
-sepcs
-1 sep
-f
-51.919 34.2159 mo
-50.1553 34.3702 48.4336 34.6612 46.7647 35.085 cv
-45.0293 31.7598 li
-41.462 32.9639 li
-42.0958 36.6563 li
-40.4815 37.3428 38.9317 38.1573 37.4639 39.085 cv
-34.7881 36.46 li
-31.7666 38.7081 li
-33.5157 42.0323 li
-32.1993 43.1778 30.9776 44.4268 29.8624 45.7686 cv
-26.5 44.0938 li
-24.3194 47.1651 li
-27.0049 49.7813 li
-26.1094 51.2696 25.3331 52.837 24.6817 54.4659 cv
-20.9756 53.917 li
-19.8526 57.5108 li
-23.2159 59.169 li
-22.8292 60.8477 22.5831 62.5772 22.4659 64.3418 cv
-18.7579 64.9659 li
-18.7999 68.7315 li
-22.5225 69.2696 li
-22.6778 71.0323 22.9639 72.7549 23.3868 74.4249 cv
-20.0635 76.1573 li
-21.2667 79.7266 li
-24.959 79.0928 li
-25.6456 80.709 26.46 82.2569 27.3887 83.7256 cv
-24.7627 86.4004 li
-27.0127 89.4219 li
-30.336 87.6729 li
-31.4795 88.9883 32.7305 90.21 34.0713 91.3243 cv
-32.3975 94.6895 li
-35.4698 96.8663 li
-38.085 94.1827 li
-39.5743 95.0782 41.1387 95.8555 42.7725 96.5069 cv
-42.2208 100.211 li
-45.8155 101.335 li
-47.4737 97.9708 li
-49.1524 98.3584 50.8799 98.6104 52.6456 98.7227 cv
-53.2696 102.43 li
-54.8282 102.401 li
-54.8282 90.2071 li
-50.5508 90.4063 47.168 89.4581 43.1543 87.2188 cv
-31.6788 80.8194 27.5655 66.3292 33.9717 54.8516 cv
-38.3282 47.044 45.9112 42.2872 54.8282 42.667 cv
-54.8282 30.4581 li
-52.4581 30.4971 li
-51.919 34.2159 li
-1 /3 get_csd
-sepcs
-1 sep
-f
-33.9717 54.8516 mo
-27.5655 66.3292 31.6788 80.8194 43.1543 87.2188 cv
-47.168 89.4581 50.5508 90.4063 54.8282 90.2071 cv
-54.8282 73.5127 li
-54.4903 73.5616 55.1485 73.5948 54.7969 73.5948 cv
-50.8213 73.5948 47.5987 70.3731 47.5987 66.3975 cv
-47.5987 62.419 50.8213 59.1944 54.7969 59.1944 cv
-55.1485 59.1944 54.4903 59.2286 54.8282 59.2764 cv
-54.8282 42.667 li
-45.9112 42.2872 38.3282 47.044 33.9717 54.8516 cv
-1 /2 get_csd
-sepcs
-1 sep
-f
-3 lw
-0 lc
-0 lj
-4 ml
-[] 0 dsh
-true sadj
-54.9161 147.252 mo
-1.5 147.252 li
-1.5 1.5 li
-54.9161 1.5 li
-54.9161 147.252 li
-cp
-0.99 0.99 0.99 1 cmyk
-@
-0 0 0 1 cmyk
-%ADOBeginSubsetFont: TrajanPro-Bold Initial
-%ADOt1write: (1.0.21)
-13 dict dup begin
-/FontType 1 def
-/FontName /TrajanPro-Bold def
-/FontInfo 7 dict dup begin
-/Notice (Copyright 2000 Adobe Systems Incorporated. All Rights Reserved.Trajan is either a registered trademark or a trademark of Adobe Systems Incorporated in the United States and/or other countries.) def
-/Weight (Bold) def
-/ItalicAngle 0 def
-/FSType 8 def
-end def
-/PaintType 0 def
-/FontMatrix [0.001 0 0 0.001 0 0] def
-/Encoding 256 array
-0 1 255 {1 index exch /.notdef put} for
-dup 67 /C put
-dup 73 /I put
-dup 83 /S put
-dup 127 /Nsmall put
-dup 128 /Tsmall put
-dup 129 /Esmall put
-dup 130 /Rsmall put
-dup 131 /Ysmall put
-dup 132 /Ssmall put
-dup 133 /Msmall put
-dup 134 /Osmall put
-dup 135 /Ismall put
-dup 136 /Usmall put
-def
-/UniqueID 45714 def
-/FontBBox {-248 -284 1528 985} def
-end
-systemdict begin
-dup /Private
-15 dict dup begin
-/|- {def} def
-/| {put} def
-/BlueValues [-17 0 750 775 638 660] def
-/OtherBlues [301 305 405 408 -261 -256 -222 -209] def
-/FamilyBlues [-17 0 750 767 638 656] def
-/FamilyOtherBlues [301 305 405 408 -273 -255 -214 -209 -252 -239] def
-/StdHW [47] def
-/StdVW [118] def
-/StemSnapH [47 55] def
-/StemSnapV [118 126] def
-/ForceBold true def
-/password 5839 def
-/MinFeature {16 16} def
-/OtherSubrs[{}{}{}{systemdict/internaldict known not{pop 3}{1183615869
-systemdict/internaldict get exec dup/startlock known{/startlock get exec}{dup
-/strtlck known{/strtlck get exec}{pop 3}ifelse}ifelse}ifelse}executeonly]def
-/Subrs 5 array
-dup 0 <1C60D8A8CC31FE2BF6E07AA3E541E2> |
-dup 1 <1C60D8A8C9C3D06D9E> |
-dup 2 <1C60D8A8C9C202D79A> |
-dup 3 <1C60D8A849> |
-dup 4 <1C60D8A8CC3674F41144B13B77> |
-def
-put
-dup /CharStrings
-14 dict dup begin
-/C <1C60D8A8C9B6D5A0DEDEC57B918D61DDFA401F5A49FEA3B89C6864173301
-6BDC674395116B42D2387AF24DF2F1DC60C61A5B6585CC0DA86F050A110B506B
-B65171C092F0636620BAA275DBDEA04B3E655EC58BDFB8B9B535650BF4DE0E82
-1C2ADFD8C9F649E0C395722C228833505318AA21D61F3D55D035246FCF9BC983
-692D83F8C9AF492468B91F4CB872C7D1953185BF38A8E7A5B72C7F51E36572D3
-718D9C26EEF5DDFAB02F3E79248875F4CA6CC06F7C289C017B388B2CFE4B85A5
-1B0090> |-
-/I <1C60D8A8C9B77771C05B04C6A1CDBDED73825D1016AD1A9F739BE3AE28A3
-2F89A16FA0ADB365C478020BF11BB9ADC332932373DC2832A2FD54E961E2B084
-4B0EB81447C317CA2A36F9297140F653C6CF38B651D9BF313FA9254650245A3A
-6E604D8E9EFFEAAF12423E3B4CFD19A9AFAFF5FC58BD3FF4189B6F8AF938C510
-BD91FB49103F7E5C2AE8440096A8B2CFB59E1B448BD934D6C96663C7ECAD3789
-1B4FEEBF9172B6A7CCC0965D9AA12297E39BBF30EB7B8F6243DD70D9185FBD81
-8CFC74B60F41E69C4533165A53D5C2FC5A9B44BA5F12F31CB79A71FA4F70F551
-E84E63E5837361F7B7736F91> |-
-/S <1C60D8A8C9B7F51B95A0DFD92CF0B9552EA2D8DB80CD668D35E3A70F4576
-D4238E8EEA2F046EF8BC16C7785D1607E04A62100A5AFF084F37B544AFC2004C
-0BC4AE1356D2B0EC8700AB99117F620401AEDDDFA69D53F0F4E5314303A9C779
-D85053ADE7DEA169C445735EBAC333F65F31A077498B479248885315A58C9DAE
-7AD6ABA3F9562E1A36EA3EA3274E191D557F04A6CB9FA3B240660C95B31FD1EC
-ACE3874E2F240022DE09CA2256274ED580EE94FBAA5793BD5F9D37682BE7C541
-ACC5EE4D95FB35149493D2CCA9BEA729ABD0DCEC9C95E902EA9DD124CA919CBA
-F3364C7699DDBE268B46D54393CC359D98EA67700B83CEF348489F1F90A16D> |-
-/Nsmall <1C60D8A8C9B6BC88BD85FE8659C453EEEB8E1BD03325A00213B3F3D
-4D450DC128DD37CC24C857B6D60D557A08CD43D812DF35B5BD6760576A63576C
-506A238602F1E6EA5D2CF18DAD28B193AFC0FA899C7F243B47EAB7B8460C0CB0
-4242476B1602C4D8E3342E27EB421C00D297126C6E43889F0137C7A1C441FC72
-2BE08EFEBABED7A59A7395971A284A820995BDAAE7D9478AB8745D9C9402C363
-B7514AFE9E3D0AF6A39663E1D555B5F7BDA2CE94F32DDC1E19216692DC849907
-7A3E6206E838004DD8DB4A986C8F31EDCAB6E6B82F722A0EF26221ADD2189144
-83D5E5F90B6CEB939F64EF523B4531C4C0B4ED4F521923EBA94C1FE7AE3B2648
-AB7B1D48BCD570F1DED35E03DBB412CF55B5989A09E378971DDF42BBC4FD1669
-7B92AE130992922E13408AB712F27D256F7305A6C6B07A0AD7C13FE23EFB63CE
-65111A1A787D3875B8B8D9507C694904CE3BA8114CCE10FF99A55> |-
-/Tsmall <1C60D8A8C9B66C0E1D18F4614EAB544F0CEC538C8C01A016933AA12
-429EBE5390D596C5F67CFF90C2108DEC0E3557EFE47A84AD0A504C83D7E8F287
-5DCBB9233950E37680119C5422B9BA74EB5E3A2AE4E2F090670CEE3CC015972E
-6CE8DF50DCD73A5ECEE824E6627364F3B83B1B73833AA7E396445D318F119C4C
-5EA2429D5B49B0EDBDDF4808A5790BF8CDC63B184CD3A9CE7C22C4D23ACC081C
-FF7BCA42342880880724EDF5A0F6F9059ADD736C441B65FC95D81D78B14BCAE7
-32E0959A4FEDBBA605D7DB559BC1CFFED39160EF11111F189C967E86115A679A
-21BB269B7452490D7C600719A2B02BE0A92DC8D7E101DFFE6011D579AD666FD2
-6352E7C3F88546D427880A3ED55A53668B9B911F227F478005846196CB2A821D
-9436A361DD997E24624546B193AD16A013BF60C83D456FEFAB524A4C3C4DAF51
-640204EE51B9A6B98D186E77DE45F4BD3696405A93E6DE14A3A251AC1EF6440B
-3F074B20C4913F3447DE56969C6BBDB2354148031166D8E9781263F94442062C
-991765ADD918972AAE466DE6B9C6E0991428CD75BCCEE> |-
-/Esmall <1C60D8A8C9B7FBE1B006E95A68A3EFE857D335EDE0BE9AEA4BE7F95
-2FA0109C6CB803A7F2B985E7BDE818880C9FD186C7136A63CCA57CEDB6AF2828
-DE38E8685BB8771E2988A810F73E0345E8908310C31FD0F7C222F54500389519
-240356E338A96366351A20F484B5651422D1A0FDAE927D548045766A19F6150D
-CC390EA0D98D6C0EC5E1C97E0B4512533CA015299550D65A6EA9A741DBD81A7F
-575EC26534A2210CD8BC3335B163A776277B6F29843653C092C384FA226EA0E5
-F40EBE1799B10828B444468B3DA053A6ABB46879088C5CDBC46D899C794B325A
-A3C97D044BB760BC39839995FB64819C682832A40321F78B99C09513B805CEC3
-996F9F6C14C0DA278CFDCC8EE83409A0C9BCAE8289E42BA209582E05976E48A0
-66222F364CA72855AA1A8DD971B9E012D88EC883F11B6B8DD1F7A3A1A193533F
-B42207516FD3B0F5443A7865F511A1795EBD587D37DBDF03F04386AD8496835A
-76A8A2EA2B1821C0A26A3284A32DDD223178AF712B0015CA9C866D881702FB56
-88AFCD83EBB5B8B70C983ADB28C933F563180B2F5D693852DE904FE07D55275B
-BF14C6F4184BD1B4A9AECA29C644CB5A0BE9622ABA21F24CFE079641418F3570
-3415A4A73F296C050FA68AD25A13C7E948BFB4A1F5816B4ED0207AE7F70F6A21
-CEF402873ACC39E699949E03BE7A042549D2AB51127EAC04572696553A61D3AD
-7A50684611A83B8CC45B07DFB59CE66FF4633DDD79F> |-
-/Rsmall <1C60D8A8C9B6232B67C2503515E3E19A361BD6B49811E165A598B41
-3BB79166E3FDF489EB666983D5C7D39CD639562A5B5DFFD54539B03730F39196
-01122BFF4EFD30EC733326ACD5E99E075E6AD0B22300446FDA3039558CE7D82F
-A6C33C70F1D07536B16D4B1DC2398D650AD9DE1FE1EEF9FC8801CF7C62691F3D
-44ABC62967E1B752BCC2F000EEC07286667F57839EF2E6B9C04C2DA9F22FCE01
-4B7A5598EA7A603107AC2DBC5AB39CAF9666BA8BD1E17DD88F1B0183C4C1C3F1
-1214AD45BA4F39EED6AE5D1943AADDA9D1EC079FB2B1E8FDACACF0141DE87287
-5FA936F561AD9761380B6FCDEE2C83C4F292D6BC0EFBBEBA1571BC78DB7E53A3
-C2355971E9941081B36BC438EEEB16D9D4B14BD1644AC5E58981D2AC452FD6A5
-580957C704505040E5A864423A1DEC798AD589C92753FF4E99FE4D12AC55E99D
-5F0AB1E5E4B10AE2F480F509E7AF89EE8CEFA0BA716FB8CEAE96307008D32070
-D365B7F6583B829884DD2FE6EB7D95965527303A93BC3BED5A9AD904DA3DA> |-
-/Ysmall <1C60D8A8C9B7CDD8BD7DBD65E184B9680768C945EF501FFBAF34DB2
-EB89B7C35DCB2E8CDE46F9D37FB471E35DF335DEED86CBC9BD25ACBBBE505717
-85D55C56B45ACC3A263ED736CAA051A570F787892A1CB6821A2FFAD018F8067C
-A681AE9EC8078E3C7AFE94C42C7FD5A558E11749ACDE333C8BDC9884D4FA3DAC
-AE8A34DD32D0843E9B8D09766739B4ABA55282A00532DD1F8B6DE1183006D340
-67C1700BABA7CDD73E0CDB5BE2DDAE32FBEED1C6D7EEEA3B5CEB4C4205571F0D
-CF1A506D8FC5DC8499A45715F34A9B98FE00C59CEE5F28BBF36D76480FA97A6C
-7DA2BD1F5844A8385287554D6A25D036C1B44B3D155C43934FF8AA5F5EFA8691
-C8A756E6E6312D494BA1468BA6D0686CD0C8B3FDB8C0351FA65E6040F976F25D
-799285A835570C29A2FB34B27E1A794353E610FC2C4A30406992C247A28AA7F6
-E944BDFAB0BBA11598F8F567A868E003F8F3944F74A873C0B590A5CBD543024C
-D6E3B83887E8B4201> |-
-/Ssmall <1C60D8A8C9B79FB048C852057885B7FB39D71FC3016435158EC7538
-3A43C835122312509B1BFED76A61F209ED65A42B34BB62984E18488BC60B5218
-01752FF5C2563FA0352A4574582BF27E08DA350B6E25230194888F1FA389A5D9
-3FBF39576DDF170A31E4F9A79349B244BDF70FC82577F5D740926CBB4F2ACA8D
-2425F341518CF5F38A11D5613BD07DDED6A6C9CC2A89D2BA18004761AD9B9FC3
-4EDA3D0BA2574B07F9B17535C3DFBDB872ECFEEFC15F4D3F7BCA04E0B730A15B
-DD0D5BCB061E10476825BE14CC3CD57D1B8CD428D2118BB782F85F1A67B39448
-980A962927A8E8DBBBF65E6278D0AFECB529564B170722C87DEFBDB> |-
-/Msmall <1C60D8A8C9B5BDB4869BB7396C2BCC7E2D035A8DDF69463A769AD1A
-A49DB431BF0660A482C35C477875AA9502C9E16D281765C1FE89158C85EF4F3E
-57125A0E615EF95AE1B7077390D7D5D6DDBA63FCBAB687625D16C58A812887A3
-BF8B333347AF25B78756DD80DFD049480BBC5CC2E60C8AAAAAEC52485278ACB4
-CB64431DB98372ED33A1281E6970D65A9DEE7B405CB6932D27F2DFA40B98C2E6
-9A163099093F74C6495CCB4C78B91CF36A00F110217924E037A2F56731347A29
-95E8AFF22D6698D628918F5A55716FEBDE556231C95D2821D1B0DE3CCFA65E60
-C9DDB56BAFC7C7328AEA86A4824D8004029A0A0834D297E9E2EE5DAE0DFFB8A2
-CC6F17A3EDC65> |-
-/Osmall <1C60D8A8C9B6AE36D8AFC06EF7691CEA7388408CB5711A90AA9C8BB
-7DF107C83E9F4C9D93C2707EED4FFD917928C910BF7966EA41381731C2EDBAD2
-707004603AE29A600E85B2D80CC1F8253013508BECCA2FDAB8779E3B7D43916A
-0E2CE1B80BB3DF3> |-
-/Ismall <1C60D8A8C9B704CCC403F91AADD9CB2F76DB90BC6EC90EF3D45C6A9
-10C33779B027A5893F399469312EDD288FF0EA2B3848F5A530D7C0162C275993
-6728784ECB91933A5B31FC0120544923268E389858466EE39EB2181D57CD3BF7
-07FB3669BB94B89A418CD729CFF5FBF8DC7045D58C25F7CB07F19116123D927E
-59434BBF93B4FE5DBF40C126B117E6B60590BBF45DA98B6DE8B19144213326F9
-87495E510476E3585AE1A21D73828E47A902A177877DAAAB4C0EE1255BEF7F14
-75F7B919B37EA781F4D15EE851B6A63CFE7192BA2E00BB3BF61621837B8C6E3E
-7AB8CE9EC58E9FFE71C29175C76E5> |-
-/Usmall <1C60D8A8C9B6ED055F5BB1EE84E1A93ADDC8E7C125E88D8FF53587C
-17D959293900B8FD46371B21619962E4E05301A5E3EA5963AEEE83B21393A2AB
-3695359695D60CA9917C3B4C055638C566E55787F9201E25FB6F1ED940BE5C4D
-321EC5E70BC368233DBA0CBD12DA827A229D0CC8A349901F7F6297A8D2B5EE1C
-32919F009B7DEC73D0710E8891AA9A0D36238E9E944FAFD91D10D63C6B88D5BD
-C3A7985808BE85B22B832353DB0C8315F69AE576B8073207A5E9FE25F5A1E4F5
-9C748E9F7D4D5B9763098CB580B40B6CD00897D0384713B624EAD8EE1E24E326
-A2BE8083CCA899DE1FAB4FB90AF9AEB63CFCC24D405FB6596CE1D598C7EFABAD
-D016781F1785ACBA6641462356572572D87FF66C89B7A4AFB38B24B24E1E7B07
-44FD561E659DB89FDAA3D90E0980DCB66> |-
-/.notdef <1C60D8A8C9B7A73DC56ED86593A26411A239A9F576A4BB06AD4079
-CBD73625AFEDCD129CE8B573E3C4C05A38ADB9D43C2E751D7FE69FF5F6F4BCAD
-D50244964753D5C819FE275F32A27920BE3EA3D1AFD957ADA922B28CD2CD8E15
-58DDDC89C143A1> |-
-end put
-end
-dup /FontName get exch definefont pop
-end
-%ADOEndSubsetFont
-/FDJFDP+TrajanPro-Bold /TrajanPro-Bold findfont def
-/FDJFDP+TrajanPro-Bold*1
-[
-67{/.notdef}repeat /C 5{/.notdef}repeat /I 9{/.notdef}repeat /S 43{/.notdef}repeat /Nsmall
-/Tsmall /Esmall /Rsmall /Ysmall /Ssmall /Msmall /Osmall /Ismall
-/Usmall 119{/.notdef}repeat
-] FDJFDP+TrajanPro-Bold nfnt
-FDJFDP+TrajanPro-Bold*1  [32 0 -0 -32 0 0 ]mfnt sfnt
-63.709 49.9312 mov
-(I) sh
-FDJFDP+TrajanPro-Bold*1  [26 0 -0 -26 0 0 ]mfnt sfnt
-78.333 49.9312 mov
-0.080658 0 128 0.288605 0 (\177\200\201) awsh
-131.874 49.9312 mov
--1.83563 0 127 1.73947 0 (\202\177\201) awsh
-188.218 49.9312 mov
-(\200) sh
-FDJFDP+TrajanPro-Bold*1  [32 0 -0 -32 0 0 ]mfnt sfnt
-63.709 85.9316 mov
-(S) sh
-FDJFDP+TrajanPro-Bold*1  [26 0 -0 -26 0 0 ]mfnt sfnt
-81.7983 85.9316 mov
-0.213654 0 132 -0.177307 0 (\203\204\200) awsh
-127.864 85.9316 mov
--0.0141907 0 133 0.276245 0 (\201\205\204) awsh
-FDJFDP+TrajanPro-Bold*1  [32 0 -0 -32 0 0 ]mfnt sfnt
-63.709 121.932 mov
-(C) sh
-FDJFDP+TrajanPro-Bold*1  [26 0 -0 -26 0 0 ]mfnt sfnt
-88.9883 121.932 mov
-(\206) sh
-109.841 121.932 mov
-(\177) sh
-130.882 121.932 mov
-(\204) sh
-144.271 121.932 mov
-(\206) sh
-165.124 121.932 mov
-(\202) sh
-182.77 121.932 mov
-(\200) sh
-199.487 121.932 mov
-(\207) sh
-210.59 121.932 mov
-(\210) sh
-230.869 121.932 mov
-(\205) sh
-%ADOBeginClientInjection: EndPageContent "AI11EPS"
-userdict /annotatepage 2 copy known {get exec}{pop pop} ifelse
-
-%ADOEndClientInjection: EndPageContent "AI11EPS"
-% page clip
-grestore
-grestore % PSGState
-/FDJFDP+TrajanPro-Bold*1 ufnt
-Adobe_AGM_Core/AGMCORE_save get restore
-%%PageTrailer
-[/EMC AI11_PDFMark5
-[/NamespacePop AI11_PDFMark5
-Adobe_AGM_Image/page_trailer get exec
-Adobe_CoolType_Core/page_trailer get exec
-Adobe_AGM_Core/page_trailer get exec
-currentdict Adobe_AGM_Utils eq {end} if
-%%Trailer
-Adobe_AGM_Image/doc_trailer get exec
-Adobe_CoolType_Core/doc_trailer get exec
-Adobe_AGM_Core/doc_trailer get exec
-%%EOF
-%AI9_PrintingDataEnd
-
-userdict /AI9_read_buffer 256 string put
-userdict begin
-/ai9_skip_data
-{
-	mark
-	{
-		currentfile AI9_read_buffer { readline } stopped
-		{
-		}
-		{
-			not
-			{
-				exit
-			} if
-			(%AI9_PrivateDataEnd) eq
-			{
-				exit
-			} if
-		} ifelse
-	} loop
-	cleartomark
-} def
-end
-userdict /ai9_skip_data get exec
-%AI9_PrivateDataBegin
-%!PS-Adobe-3.0 EPSF-3.0
-%%Creator: Adobe Illustrator(R) 11.0
-%%AI8_CreatorVersion: 11.0.0
-%%For: (Douglas E. Appelt) (Mad Doug Software)
-%%Title: (Alternate-ISC-logo-v2.eps)
-%%CreationDate: 10/22/04 2:51 PM
-%AI9_DataStream
-%Gb"-6CMtIYE[^blnitWj!HrIdV0lorEFGN3p=d2AK:U\*q_!hY[_$iT*gP5UX1]SSqSRQ?_'$)V>TY%qP`SMZ@PZ&5]GQS5IeD7R
-%m`Y!Qle<L>GQ7K.<ATW8Y&.3ff<4tLWP85on#ub1r+t\(\B,1VnRC\d?aFN#k'iiu,P=Jej)_iEpKp\9gP9_8n(o-NJ)9&<gtdJZ
-%c"d.Iea;XG=$QIuY#bRC]XbTMbA)*>p&6?3aPlR\_,pU'rp&CDDZ00VZam^DTYCI"bGS,pf>eC0p"$ku^->l[*"R8fVlPU'FAYD.
-%pH<]YO.ZB_I5g)6.fSi&qjT5\No0V,*'aApjM1[&?VKA;s5+k>*rNhPC\4:.?Tp^0SRbF/qI]^'n%Sf"Iau[8YhK*1=8[PW@95Bj
-%feh2g<p8L3A_Z,@b<N!cr+8s4l3l4F)ZS3.jk%=mrI?bp\bL4Cb1F/eHN2#M)10h-\l(\1c#S;^"2j?\A#s>C0m5p>Dk5X:Z"Oie
-%_>('6rT`ihmf%TV6aJF?pEP/0^\r2;05#YbIeS'\a5_%#</7$:3`Y.podN#Y[0)AgpUKKQL2Ok'].nKiG?6^6&XYr6NSe+CnDck=
-%d?+"\lhda;+2Wq^BXjUsa1jXk?iT6ap8=BiCnj_^n;[HORXgF0o\5ig-[E'j?N,`?LX9Z("VI(0Lot+`kmtfVY!5/+?ThZOh>Z`D
-%M#tCQSj(t84WKTq]6a,<n([nmj8WB5P83V<H.@$R:$^2BE;aO?4\HWk:*fbtIp=)qnf&+kpXckbGFs@1$N0&_4jiKiro)Vts74)f
-%2XP7"/X?=obK]SVO13_+fi[>!Z/=Ac38STd5'sfM!j\oF_"j]3hd,(<E.%/VlgEmCN:f-1\`U)Es5in@lK@1jd58MolVGRUn*^/k
-%p9n\jC8eaE[rSTh\+/\1&lSEE_>Bg28!D:rMsrhk/^7$3khgXInb)kR&(e;*iD*,)s5!YHLWE;hFu@_jloh"cpiZ.#*V<iiGW=Q#
-%LSsUUqshkocaR!-*[$G42:&XBs2p=ngY:Q7_j)mW8(XpCrqN+dc-Hp9ct`U0FmsSpiNI=lGIs-gY(P''K5\@3^?muXp2GP[l)AZU
-%>2om4is<'4&Sd<ci?2tu#BcPh3mRc@e':62kF`Ug#CiGuFpk^d>Bk2#Kl=D(W,jr6[thj\_UF8BI"+-&1Xoq"0D1+W8Dh:JnpT+i
-%?bp*J"_3/!:^b8g,Gjj:7.;#X^kgo%N*@Djcbc(-0AOC"i%MH*E2&Y,7.;#4%A-H(@tJn;2!Os8$cW@"U!DTsAMQKsF+Q,4Oe;i,
-%kt)dRoq)"TIA=8=cXi-4#5pe=(a&[0Q=pJ:eFXd+(jnY%(n]#+6%tnan\JSBK@/*E_dD[hPe^Y)"lk6M1lI#5"BTn6]MWVJH7nt;
-%F%6*QW'`.gS%s_I:;)FS;nqP0e?[:7eW:lO"/?ORK[IWb1huk&`Wq!e(?%32O'k<#_I'5DUT;*AbSJnUaO(q4]*3rn<s79NkCb:;
-%$UPXbVZ_5/*C67Q95oNTbDaNpW:*PUhG13%oCP3E:sXtR$(GYS#r^;M!IkB),IPuVeQ5)>Og5*b&bcUD"n*]8_:'!OK[Sm3$^B[6
-%5`Z&2n8s><oMt`<n"k3lael'-#<mtp2Z2%4oM,7ZT>%6#pdm^#=2R9LnWSF!M=0COrQI(Rca192k+D=8^58KSZe<]Rr1otMX5/e.
-%i[=]kpN.KAl),"U`6Vl[i%N>*h9-geqXLul[N?!kAp]o#p95J:So\,F?=@Y?r9HTE9mTU-eQ5>%g-7NM(++>09[hd@j04R<oEk-3
-%-+gb_TBi9Xe(0#T?,LT-W5j3fcZ0Q2*hUt'rVB#`%hO6g5O3SXf2KA`7qdIri+`$@rEW41%lg\<s*"Dnr_E.MQ-(+04mgrjg*?AU
-%A:9!kHj`mNoJ>P-UK1TF%c8k1lR(l6i1KQ.D>/ZiP77uF=:=.,l*oJ5h?SSg[%2rnj-9S%rs]G0#5Y%NI9>jRd)*Dm_=p:p6Ha4(
-%%s]7ECC]5b_C2&frY,1V!dlA`)%DM2%tN!shJ!Ad=ANrJE#?0-pjfm:H\(YXcc>jYILn%7LGPCXK7=doF?NF3Tq-Amq6356p8p]/
-%6aLY9>CE'2qW-gq0ue!MF2[/GR<gh4r$VJ.CnuOdT@cBS6UD;RUk@LYQY$S.Rs)N"S[@N^<@]lf+m.A)=s,dKjrC8s[,ZTqlJ$Q>
-%ID^&7gH`q9k)StGE/[64elI6>-HA)u?IH9bK3#J6Y3dN$<6>cP#CnF3fQ7'/b18A51>EE4/c=%\dK7XPDtQBgl"Sm!\%$3Y`+g>^
-%phb4CTn#q_5Gi]fcCeRTY4"5qE(gL_B,hStRio_GnkVgFj:;#QGL.SM!pD(QA:T_K#IUb-.^[@YnKl!DO]%%E@$]M0nJRC?TJaO/
-%[/OG4$eMo?o)eM8UH$VVn0^Oaf&iE!L-:Ue^bO'_&jB#SoZSTJ1gB+)*ZLLtcG87`T*)j!Fq4E8\oG`8B]7Fc")p\s#s\DC1H6&Z
-%^V)m<pRSgHbQ.8oc3V[ZH>8VOV"`D@n-.9Ri:D?2".%s#oN+DNk$.ZdGU'mT6QL,4qBY+@H[MF!OkpI7,gZ#I6AsAq1^9,N+OLJ_
-%0Uc_EnIin#3eBHQ$c%8\>ec#;QRRJ25F&?&^'+35b_\N[GM$P^0gZ\=Xp$HD=ZE^Y$$\,Fqge4XF^7(gSot56ST)P"8AU6<-)7,Q
-%UpuHR/l2P/J=dI!&;Q><JFf>Z5h'uT%#cI\]flh6U9K+%qklsH<82S$i^Hu'LXNQmOTH#g)t?H/7.Z$'dRL#8OCRF`K,oY:V.i/9
-%6)H_q\\OhK#AX<J#(!"L_A\h\_$Iht_&o$lkoK:[J2Uh*e2orH-12:iWjJPUNmA$PJl_8dC_*=U_XlN7E$>7.#W%%<d;S#\OOU"J
-%n_GIe2X*0mItVA3*C%6<>uFnAA(PN@jK0cnHeo(4+86'6O_)EI+eS)ToS`:0W?-MjmcVDF>)bc3-+I\o]2!?0a6sf"DnFd0hfJ5)
-%\rN<<b%g\d\Ec?:]9OH#*/jqY<sf')oNIAbi(,VmE"-s&\HEd`e#ur;-HCc+O/L?AWoJX=+t8Qi\JqCc>5l"eD!!=b>g:hX64>lD
-%i`;cm+I."DJKlOj`I80gcMO&DUHLk:Uti3!YmPSWJ0`AeoMEF;oMh?aKV!aA7%S/TP\ARfcOZbDd4]kh[C4_BbZ!$4@E+trFtD[Y
-%JjO)n0TcLpVOTL6d`BmG(5\YKJ(H7+f#5moL'QgDl\XCe\.c9Y7emMN[R1WS&E\YX*rEF$ILt,.D8b;<mf7\QK1OZDH/LojECJ]8
-%@4+0%E`(?d>n1#3d.J)-X@/Vp+ZtJ<>D"11Z@q@ATG6L%WhJZTRLR+L/Zi,iT\cg0.(BXI7/.<q!,4$e\Nu<EF3n4q#"0J0CHYl#
-%K7k$l`A-m6T]B0X!U.Vs>T$`VXDO5J0!,;0gilp_l^?ft$cOeN8]rFHV4KH5c.$C>L'c39Qq9D?s5N.7<b:f"96Sm4Uh-BT!bQ*_
-%)6Jd=AAVcj9?(SD2%"It0+Ba8Au!%A+M(pAg57on`;5,MCJ;&i^[d%`7u7'i:'%*sl]RYmg:/W;<,Z?Wa4ZcS6-aCIfKs?R(W82-
-%+c1W,jA4:hKL<^sUF*@>UUD!7#`V>hS`R7pP.&nB&VgH0O'61pfquQW9(N(dBXOB*5Nth7HqL%'4duc(9>$L^\o$7a=ck_HMh$i#
-%U_*o&d28')d7gtLiXT!2b3)f(:Ab9oS^Y\CrcHUQjV/<9iG$odb.+72JK5HUV@"4Oeu45M\0cX&'5ItAGNeXIXkBQX2E9VG?LM53
-%CKeCbhf\7%kSMSsi+KF>#h5[;'N2HH[]=0C-EtO,g$UPR"maTmgp,MlBbrA4f^kY9;[:sA&NeecGlt/b"Q*&E7Z7Idl#mijK9L`g
-%M[&hpCi6ju>86t'XOXQ4>L@2Mge2HoM:Qa0HfjEu*>RsKA^(RRNqTd2E`(FL#Rgqs3'Y"qfU3"_iutR%qi/B(m>?\$dOp0Rg=9ue
-%1l7Q7BphR9il8ne78KT,**L+Plk=.OQ)n-gb-a"AQ8"Y^VGkjii-D6&3l"rNc+5U@F732Dc=;s!*\q3aT!J>rQ3O1h"^NO:8gGY)
-%:snJ:C;h5G3n>@M^BLRTdVSQ[2EAj;efM-EmQ_a%<prkZBE`?BBc4#:UK55eIM<e:@%LN_%eQl2)tkRSYfJ#ocE1`mMC;)&77XWL
-%0[n02,iX+c8r[(E<iDK>g;"`1_J$=kpM+*KnI7)=&]%"8ViA:^+gp6j'fs3%H4VrOXW9fech-gF2?f+09bSrjX;81`e2)5b>9sNr
-%Sj\lFfNjA\DD.;``k4=5K&ZX*Cun;HO#WaeO(*0e(gW`VPUjmI$^thg\cYj0T;!oOpSlAl)4nO=LN:;O4['aCP"O-AV>@Q0$`*dc
-%n^,a"[3bTF[$M"kk\9_r;ao:Flh`A6P(k/\BA*_pqk9aLN4<(!,Lu*`ZE6PV&hZ[p7s%0J?-E.\)e)pS-epH/\=ti)io;3GAS*e9
-%?n%PAXKAnm/>LfI\tR#eh?/1hlk`mP+ma!'#U?N!`H`4nF,Y9EdX&m`,@t$_OOOi42m2)37!>F5C/LT52P*U_:0/>&4@k+Cc:K]M
-%&/;@6ABkLn]ja:]&ab)FMtV-]ng8FliDD\;5slM]i2Apple@,k#IY>CV4reK?3L8]Db,J]lU[.'TemP=,K72KG!OdQ-<VSiXf#ri
-%j*#F%*-UGqPHdQ.#0K%L2Iflj7k6Fp-G&;FpS$Kg4mWGMbTV>o/QsJFs.$Jb'Q0XfDq'AX5Ds'oGR3d,LaU%1F78@74ZEh)W3pqF
-%F]%_<J8+<)]IGmC*sg7d`SY*[qTPc-RR?_+YW`UB98(bB4[FMUmealX5O'gdT>t66M/\_\F#Yef+'r0JfDs>b>N>8L>oW4@]\cZV
-%U,PR.JR9'*ej4tgqL7/9ITO0H+;@XbU/:n2c#&GbY!;)/;VoThfae;,?)JuAT>%eH4_ps&m;G4>HRJd$]fUe7m:UG:r9""Hk3`KN
-%0)UdfI!^89nu;Iae[`kQs)RjQr-Wqi_p*2_`lfIlYQ!Pf/u4j"&(ejKs39`MotCD%Er5k2iVM^!l>hCIrl`4Lo(N[H2]n'H?V@fl
-%nrMad/#mWDX^,8H^V53tjn/**pn*mSYmrpHKoNj6`fKn*Fa9cQO6Y,&Gk@Gn^SX'DWm5acF,S:EQZlF'Np>K#\p'k9*HgHO<W,6a
-%^Vm/&jd/g<_po8^*:GOFp^S@+Qg[)M00_Z@mr)SJT9&HWZhX+;?Z'bA&!rokmK!B]I_>;KS??`or;"?"koTf*I;9oWhqrkYq&]IT
-%0-BVc4rd@"pHMq]+2[=rDXSW1*'[c4pQo6:^:F+<@hjkbh0f$G]"\+U/'6u#a4ned(L(-Up#P`4rkldODsI2m#lgO"5/7,<"#j-:
-%b*V_Ss8C.21CWilh-Y%QO8o%Tk3@X"HL/4lIs'cn#Z#l]\au#SGN4H3I]AI,]8)m9a+nn0O>u+P>^q?fJ,XQ_rckuNa]L@)n]1Y"
-%%WLM&KC@7MnUr!?a<&:PW8(4=GSeQ&nAFpK>Q]Q\TEU__9DIu9r>!T@rlb6\p(Sr%oGd8'\a&bG[3%)tLO\pW-i]dM%tGc^f9+AX
-%I.d:P3f#`/lGJ[,?TrfNW@ld07JH*I2.=KgFDamIq(7m3<hnu!6`&[<V6?lHf;^tOpX`C)O&Y/#\sYe2=!(hI5(C;\<):t2S?C`+
-%"2<Y7WS5mL,R>T.U?Ln5a"Ond>hslih->ARn8ro!Hi3.!rKVl8qJMANo#!\>s4uikVrM\r^\;)5bQ+rJrU'JD#Vu8$lMEE6a%#k%
-%l-`P@2"esZs1A<')Ya/+RU3*\h#7'Dh9V^ReXr;8@Cfc&;g7KbF8Ybc=#U]IFEr<3dF6.Rc\guf-<S)?c/TP_1>GjRg]6kiid\JP
-%](p=Dn`-Gfg^3!k/jJ1LIJEBiZ\E8QiWCkphu)gn^HNZf\6;ml)_O9$!('jHDS!LWj<+.mmY.,`GK62.X&[pHN4khJrp+h+_f=6#
-%2,q<[q#(*"5G.q&GOtbZI<#l%%=KA/Idc7nNLqI%4/dW.$,2hBs5rI%s6B(@n%O2GmHqs+l;n7ZeMe%PE.@cXXoIS)e`QkSk9!d_
-%h;-obHBhOhYG`32o):r,55PgsGId\)d#6W7??q9W>kn/DWVOF*iB9i[SpfSVk3Dp_gVDS5H1o?uh]jOB]hH0JN>J0GrrtlJld)K]
-%YUYM05DBc!U2E*fr>_9"gXrcTfDd"Jk8W.r5Mk4geC7slrq8R:2g:l.(dj/COfNuC])T.e/G.5Ol3@ibDnfOA*90HESN]?dip,8?
-%Y<G6l<g+rM1C$VrJ+GU3#cF(kRp5RahZ<7n%euODYBIt4Su]'ohM]2L]"@o`AICUpqM.6"WrBc5?h^%=g[FueIi.IEnI*'Kk_ER`
-%LM?6-Y?1EV_fjZAqr'6[@l(Q'2tl8cNh]tNN,Dm]RrLOX`r1/OCS@Wr9>YT3EVF+7k/g?`BesV(S_%*WF$2I2.FQK>4NuhJc1C;7
-%@_M<tPhj!E&$C'bGgO"XNG`dpbIF_1`bhckoj(jIl[D!ua#33S4)d_tDqDVoIXTkuRqC,e\kTpW2WJE'bT"#oD`4*PB"-H3%bl<a
-%Ctig9mC0uVgeP)Po.(Q[V/:E\^T?2?]4T[_\m<&iG2mJobr`C=ml%d0Gd6]Iqg./dgO6R"pVVIP3r$@3qt5EEhsP^crVgc7&'^fM
-%%c*iQ?#=t%_3a%dD;G#gY<?Q=!A`2Hm71<_rO&VQ^\j812sqcCl:ob(X)!$2%:1<=c/`%(gpgs%2=&6mZIq.MVp2r,pXN*PD;3?C
-%4YHcVbC+8:RrdD3OL0JhmB58tcR\X`CS5_"Fa_g5h#O!OIJ*R$hY.jn#QD/N%0sW@I-p^_ijI`\c'RI+jpQU(/,s8C97D3"3kee3
-%)STstq?()O^34Tu*`(bKn?muY0a"[L?ZU7a5O7Ca,hJ?bMZ;?Uf06_TqHDLmeKgKRM$j7Oe]EMNBB0d!,Qnhrogn@f<3VVV<%sSV
-%<NqbXeRNEL.#UV8d$>5E:fiaFd$G?3;:m*.i39sY[JL>4LGZfa`a;q`'C'&YEPa)nh&^48_7>3og>_b7IdX+_oMaW@?/Kt0Y.I'1
-%pO1qB)\2r#c/$l8aDUH$ZE660ep`arpB\D(W4N8;/e$_V4F22md36I"i/rNP!OhNkFe1K<O1'\=Qd4%]`6fQ>E$X:dl<78\cmSt3
-%GK_;HJ%Dd?aqonV6mA2J&8?bbg*)Rg8>Hn3WN1!TJOm7@UjFB8)Mtgi,$cPE*KoY1,uYpa:So1&UPG(HS/jS5Y<DM9*eo1Kq[OsS
-%#*.YHL[+@bGc6ZEp7B\.=]dJDhZ=5f-6/E)'=T?<:E6!O^-epW+Kb*orX['d)Ou#)>0@HrRACLkFpt4%g"=(kbV<4C%$H@]JY8qQ
-%&o34'0rftq'FoQ.@BXstHQI'_6QLE=:<Tp-/HhK-A(<(4g#,>Qg5JQ+gtY-Hikt81cTH9eAgS#(EnD?g\A:Y.=_JYT"#aLfY/.0X
-%pN625*ng%=Qa"<IoHJo$DAIMaT:\aG-fV618m@Cd'?])J=XFB+U%ANa]0dJ&V(g'N)J(Woj0mYaSg(KfJMEm<SnM*EERuV92^k[l
-%=G+,<b;5WDCOg8TDlFk=1n%5i@pgc[R8,8pVad1G8rWm0V,bC[PZg5Q<_TZLY['T!;kR2Y?D1Ifi<>[P(nVJI-+l^I-.E^A,m7;6
-%)qeF)g>,ndS+,/[ESKau]3X@'ou5kdU,nR`WLd*QYBFONh!3Sco36nT(06C<=O"+>j^atM9_2LjJMh3`MC1M?B[NVdcLn:)H1s+%
-%l)BH[s+QL8+.X!,U,_jmcGoGikP<rpFeHRGIck.sGjIJ9T!7f+@cR9<o=ST(S7M,:V=X<-GhbB*#.4!gB]E6Zo8IGTChot3"a,8,
-%)ipEmcgGtJokcf!F.OsYSja-\auVc7NCVcVkH$bkB/cF,3R<7(c]8=WSNBXCNCRcC6)u+B_tW'aED.2jf_`LmIZUthQM,dS><hnj
-%#K#hY0m]Mb*]Pb8eYl.0:j659`Mn/&bpa9Goer7;,ipMPA\<9)ro?XtK^9ro;QsOmR!OA^&OX8&eY1F#eQ:Y#YI+,l>A57m`7S!(
-%$i"<R/fG9#fYh5.I(k4a'a%F'0W3,[FU$BOjXSUYk>C3Hqt@m&i><UgInS*rk*5Wej<<d.7Qn=Z6/F*Qc#hpdHqN70^Vd>%aZ"3i
-%VVKeZm"/5'N!!X<_=+NkI(9#up$GO>s16W;^9p`&"L8U298N5/bVbm5/=UV;iNGlQfl*$hCTa5=m*@u#MEVMmE])uoc./5_O&s<d
-%+FT73R`mXY.p40!\;nE6q>\VUF."[_05&L?rO.$PJh+8J<%pVG4J5=">)Q,J>*FrRfMp7/_qZ[HPG^sqk6T;sjV(RaQg3ZG;kB?@
-%jV(RaQg3ZG;`:IPes8dOckpjhdJr@%"hL?7ME\NV>+oVa]:^8*<<_Bc_\M`WKW>J^cW@><TdD5B,VC!+WLSTU.I-"U.%-fCDM,O2
-%$VDcsT$2bu0Wfp:g&t-W%Jm$eUj^T`76;NBN]Mko$*HrOe5o(O'tn`'[+B0A@7?75M`)M2g,eH*ri0)6'c!'o<V>kBX+/8l4fqnt
-%]#Uu=nLE[9cX544'ae#`m]+Q^]m)..<*@&pVCJ%(CWNb>A$3A8+DC^iYm)Ws%TK>aI\YGnd[0`.4cb\NY&6<tJ*P%5;F<TqY0qA*
-%R,9"cZ?g`-qWQIrn?6aX-nh1$mSI+J0SaM,IQHVt^hJYWc=fCJ1WS=G2s6e.DRA5A<A<3eb_3CG7[n2?<!1nWkpPt\P^fK6`:=Pa
-%;&!B:EqU-69QC;CUQ*PPjPoui8@>fLJf<0)L1I_:P7@>\Z.,hpPQ0*RETcDbQGpA&J(mE^heM0Amsm8am3Yrh^iD-UcUH<+E=MG_
-%9dC[]jT?Xb3_'ifktCp'7Fr5%I&Xu(M!UW.j+j[j]DL.XkG'E3jOUfm$aBk)PVTHW+]B_hH$h)2]OE#[J^tF7VN>O#>%=d_K1D[d
-%-kE9YOXLfNDGj,aF?o,h8e_Z8>%mTG.N)F;8CS)H34-i%eW-/BS7<P_/h3WU'UV@X>o<5[W$mq]<5bM2S*AK;X<ogKANG$][^Iqi
-%H=kU9coPG>mZJVMKDfgK+OiYLFg_u6)A6fC<RB)jh2M"^V37\?=K70+-*.H0UQdF=0_VehMKVIp1m4t<m#@#a(,rljKNEkn8$Y;G
-%__S\2#3[D4RU%U9pU!_S#&2d^RWpX11W'QZdq#$S^:61Ab^9oX<h-dJ_YWUZgj;s_CQ8%@eT2I+C!Tq[SQS6[KpCAUf4qt-Ot>20
-%bPC<lHC"5homX]U59.=$hg*&PnH.Qm5sKXG5Bt$%H)tlnp&<kaJt5sO2Z=l_+.dj)K@_)(heKL$G6e/>SU]P:^Xql8b'.=eS`tR#
-%>2Ql:Hgi'3^"bYRQ-I3"[glJNoC0r*_c>APr,V+B[CFQS6L/T%c,4iL4kW)gPMMF>@;Gbf]s:7IDl9(9D:gBYQnQ]m[ql_$bNp9o
-%>:&%Z7.g:E2j1plFYaEhO9:Z>ib^iT1^@1G+4%7,<A1WJBYK&8b\XLZ]r\?%YA3<[QX6r5(]KN7dd)dRKIY'AU'Zs9<0^"RdMel+
-%Vb696iq?R_cUsS%E%UVJ)N`kKLsi*#YeQOqoSPh=dCW'L\o=2[S@SJGG]H4`Y3<JD?<bfcCQ3_b+n(k^E(RGSOGeBJ<Zs/#A7ol3
-%aOC^$\*T3eD-=8L,Em2MqFnur7TPOqjEY.<6N%4&JdadIA:]).]sbuh2lrNX!\%Z;PVmVPIR\W\LFgmR<2]lLa=@eB0DDCtP4H+K
-%cFIQ[E^gO"Z2Qa+-gd%cG,S"'\tR,\[f\.i463SLepl;mB,td/'PE0l`R_G1^LI'O/aZ+67O]a+0^b,o;(0:8MSghR=X7$?.Rprs
-%Otk,!-llmn1^_;P,/YI:P`nsBZE.$R1<N7PQr.IM4k2%'bpYTIlkJ\%j_'gN,"$ts,ro-4>SAZX(qW2)MEHk229Jm\W_oo?WZYJ6
-%\46!,"Dl_@NA<Eg;i!qtm)+,rr@F6!EK-uEM[am4;,qP>iN>&<l7FpL[7400`J2"UW2d>ZE)62^4l7S9J3g?cZ&<:(_VpN9E:j9.
-%Y7sX%;jJIeF+pC@JT<S3&$EC[bq$cYLWIaU0<Z$q^<F]eO&pnbLli&]D_`rZ9t9sB&$I/b:H5lRn(f5d46,04Ec9pmLQ$G\'Ab=2
-%HUp,?b."-7EJ7H,G0l6L<.L8uhh`*Wm]K'P$9CYrlPi"?o\)=Zr#W%6^(V"41StZ-XLW<BdC8*X0t#/ZimFd?`J-E9Kb;7Tk?&]'
-%E-6U+B/hUmr9'Oe`Q%Zgb=p.oX1)2CC7\P@`A1B``9Jq?R@5N&?g,4`c@d5kmIRb1T6+)U1AN7up%g#$)P#[HWnsbLEeEuLY:;%n
-%qun241b*_j'sHPC<#K&=g`,JaX'NCkXU8ji_t%AdQO818<T_Y-Eb[Yui+-)`.dcc%Y2RT9SY-U>W%.Cq>4RYVp63@qdO.)h51P@b
-%HC\tSDVD'rk?F4@L9&r%<oq>ll?0g@\Oj;W?8u2(o9V!]mM4>PfYj9NSc9A)pA^(nH&W)(RIa(RLtdjr0/2Qj?FI[k,2u0qp$>2o
-%8M#?kO&^Gm71EE2h'ZRJR(Ki@r^So'bJ),8iP56cT@P,&P[:VB.]o;B[u'("X/G6"@Q<B4WHt$NNjsD8hBmt%Y+DZF`GhU]q6f0M
-%<n"'TlUbYFXm3=Q797m;Sen:"\>E9>:#^`&BiQf^4L!n.qj=1/<)7dE5C-!l;k@'UEQ$#UYtEVkq5T<i>PY[Vj9dE<C2qAgQr!.e
-%:K;?l0429R6:UlPEW2hMaX\('k:E'[f/[.,PoI[)K86&4@Jmcl]Y4dfI]e1s)gfrp=4%NOVM;LnRN:aSlsYr.cCVdu,fciBZ;-=(
-%<P=Z?>1BV<XfU!G?<(oTSJLmuH7S<gW)qMR=f94u?.$O`_DU/6#%#djkXl%pfm,#8?_"<SHSfUY#?=438^'5Sj'40NVoEZbs2#ga
-%2$>#n;7CVL(:D&L8Q1['m%Q.[YM2'=Mh4?9YhW63T[[X4JBl]>G+&V$37bF8Tpn&@krCh(h]?]#6W1Q]*'aA49($)^.tjGV?.^0m
-%F`^NKPE"2(kuom/bB@Z?SZ17[-Mkr.N:t)++`+<!Pj?2fS7?(o'i^1(8phId)`;N-MC1d`AWWJ34VLD/BL#Ip_KKYK.W(PfA</S8
-%OG\77m#C_]_a4"1cURIX)nqqQm!bs[HblF^4_Dis$).dY-GM#=ONF\3nLErM`#mDSbI]"Bb255Pb@j6*2D:Aoa\5BNAjVf]i,"eR
-%3A<*R[0T:n_0C)JFh.^X?6;b0/jZPi7oH6Xd-CGKn'6Z6"oVM87BoE]fNt4,iX@".5\IB#8TCadH#[q<S2n+UC1go8mRmsYE5n&Z
-%MJe^jUqB#;E.oA_bH[Qd,nA,WR%/tsQ^:t'[oU8Z]_mRkpatOnGMn2L7U(",_De#lkS\*0QEit[-G`oqi!F<W0e+:(2T[$t<K]P%
-%11%[tY"Ku5$L.Ku10k6l=$l<#ZWoW?G4F>sQ)@h=Cp]Xj="?eBjZ*Y\HWRV:SA:M^(31$5>7Q=5Pm"?<./]OYe&(e8Y^-)VlYZT"
-%A-;Z;%H/#.pP+Fl@BSJ<&3e^r>8k@-qe,7shD<oq]Q]d,PkQm#A)>DAT:r.tlUr*#/auT[7<:XRJr=`N3T[i9jek+/%6W0OBim6?
-%)=)f)kB'dmYJH?R-SO(7j?!"P<-bekY=],2-j'Q!JoGQ/.rEMUO9M=B?Bpi;/`t_)LW6LM<U\45@KXHn"WPBKkHV(pYWl(N=UY+^
-%j7-`hrV6X2F2Q]q/V$l;=l6u2VBnh`nV3Htesi\,dDoaf#SLM8,Y.j3=p:t)3q>Mc.TiNZ6/?b4Mp:NgIUp-lh+=?]"_k(P>$sjr
-%ahC)/CkpEj%@^i<fER^RaXBeo=Ye3aBi^2!EVDQIB.IJdIEY7:D`U%q[mc#D[X-,m>JT[,QYMS-P])nQK-Y,QFt)n^,-=J<GWgWp
-%>GTMe^MX_6cq%EkJ>)]X`\\73jKVQ\_3"Z+UUP^6gZ>(QLfZ7iN!X]S)J<759pRkX/%'4K/]FSAQa3<!_Q/>oi<3+B"6gdr1_)t6
-%eBGUl/AR)O\6=^$=bs]KYa\PK%>We>@N=Oo)i:EHF%-F1&AaJgRuiunKkj`@7#P!S`cG4O8D"083!(AYp!ADge;RAb)R.`WW"\b+
-%et+k"`*H'#(]1Jj[%):i?peKF0)u;[UUpMS?gUaU^87nl/N#GF(K94i<'L!`MTk$\pVV]W5#p?d6)3Q#GJf+R[(_ilA)/1FQnCK]
-%\lEN9>l9nP3c;"c]Pc4n8qf'.@-u?-]$FD-<jCjKC=F>DDm)pV&$$e^a=C.k;;<V"0cef4Xinb4_[:]^Fd='7$aH^adTE6h')4bX
-%0SD`5jIj<T6CaWG*+:ZDJ[oj@9O[f(;s5%XnTG4GfMmP)CE6kIo^^H[((m=DS&d,DWpgNF$OaE7F,i8&AU2JiX,72i+1\t\>ns!%
-%nXOASG?&:i*+*_d`T$.D=+u.*Hf'GRjI+UU4j9N9@J,?]+*2(`=(Z2p/2uTe#"J=)H\3%#dBlldV.'j:>4jd&guJ7=HHB#$k8#Z"
-%o5^,;U.(QCB=57=_@fY1H$%056D=q.FJt?>c-KY6)&Zt/0Q)KbcSf#I^=M8+,D0UB4J\tt*=Y4''i%`^amhi+\0Ope9_ZVoA@6]n
-%YBYt+\e0EMI'(:4k8MV(&l'(M;;cb_8IC4fIN4b8Z[4m56ZJeb=f))nIGqJW/U+2$W)RpLHeAOj0m[&2BbnCm$DH;L)@P.n\-ftE
-%V9jdV_e83]j"b2$e<1>XamV*Rad]<g@9`<F4WA6,)rWOM^mLr?k]HZPjTG]IWD$m0b+)$QP:%M%,aG?F<gcGj&]@WOlRWbO-R4^P
-%"Qtp[m$!YhBf^i+8OkI6Bhk'DV3G+1.1&[GJgt/4^o(hBPbHI+?d9mA"(>6D2"B.["jZNr]]c0.?VXc"mlP+BnPcK!a&nsMF>*qb
-%`j=cgcDkNJ=nMp\K<"9dY]sVWaZh.E_,hr.3BP@!a*p%nOIoSh'C\G_SEQ*a<,-'.W&Z+^92Bm/;`oa;r+HIBBZ4ocoG653RcnjZ
-%DRf2OlbJnI3E<7%3*5JZ:Y&sa(n4[s<]s?EX@_(+?KG\cq[;#"3krjIQ,5O9f'695p,,kl&(H3)#>4qV>*U''\K^1;OK$)_MRf+"
-%9)cM'fO/aS[DLk3I#9+<$_8\hU>RbOpaS*-D'f40Z5YDh.To`-+@8p>KM`]6$,dJYX,q+'P0*./Tn%/%?p"a7@N":Eq1%Ai5M7Qj
-%_O5n+g+f5qUq_0"hgQTlpqu_%eDYlQ?p@_lF8b*dIUYO9ZVJWP,F01OL<SW+dl"=;[cFm8g[0@gC5iUT2B7A'LSI[[$XO<2F`Jl[
-%?F3JE:&,,tEX+cP[H=kfb=ACPHsCEYS9Ui*2psl`_6GD2Qq]\R1U#Hd(Y1R]<f-Qdg$a(*^UWLs>!:k>Hp3@cn5C'Z?Dp<l6K5bA
-%pb*ol$]4mMikLTM0-pN)M>op%^QA4D,lZCAnKd-G=TZ22U?g/Z-Tcu>IYAYGbKe75q<RARY%UUMl<lP+VGL<I2mQR"Mu%Ac9ROY\
-%D"Vs0CLJjhXOb.O;ZfL#I%.BfNh-+"bVQ`\=`qe,G.V?-)@tTg.e66+>ou6jBB#-L-n7L7l\83n,<!`Cn1h8OkF-Vdg'U@,1$=O/
-%nr;/Y4==e5&M)`--E*H^[q@0ZbA;mEL+W#[Nd8!Nl&e!6KH:]>?8Kpai%F=JE:,k#HkdJXS`\D@fV:D'q("AuZL]QPl_Ohn5/"cX
-%8kRjk[A@0`g@J-**UK[5mb<V9mYAaCY-%,$GE4,'BZn!tr56mr.\,oql.9lE7J9\Yh_sfd8t.?:]oot:"Xgd:gg5nO10@=2npH]s
-%(YNsd^9:OYI\dOhi@Yp[',BtV]l9#_O&;uf6o'm0P6C`YB+UC"iKP#"W&V7a`iF+uX&<9(/Cd]7d'?4GFPJXe";[5USHE+LL@XKD
-%;GFi-JKD#oK>V?ecLF(dGN$,VbZ]Fr4uo0#0k?!Y/JEoU3#=G7R:e^/6JY_B&8cD[U,?-fY>7a^f1r"2P\SP6WdB0>W.bGJS(fFe
-%kQ<kogITK'<GrgJ$'C*`Qr4JtBD%Q>"bCr"D\_5j'-\n=#@KGU2\Nf;#^Xl<f!+J5&#kgFWBuk`66'skLD?pte'b6sYA<OJ[ZT*W
-%'pc>n!d@,1/?WrU2=A"TDRI"$V.10_At?QHb2kKu<ES6YGj%=ogW#Lq+2UIeYb#u?fVfd\h9a7`*p6fX5k7UF8+J%(RB"P5HQB0T
-%MQFB^Nq%R)f_AYrITuH)ISspl^T(f5RmiiKl)I_<C!U@hHh+.6ia5Xg#G[V4!B*,2<U+,e='ei(F]L'8HKFg'8-'C]12hb9Thrt-
-%,KFE)ljucYf''b&"oEl'%Q7cXW/Tt+bQ_T;&=^KQC^+t%+s?R\@k4M1<8]2548bP2'M>[@@U]1dEtlc[\;I!t'+0>C?!IPDN^HUb
-%Po&HN;&48l_["I%(j5ZJU@%WA:J\'qA,\W4E@Nh2W11qma6UH7TF=8?1-k&+&1G]ahYQ*$]*_=!FB,lprpj(3o4BXqniq?cSoBCU
-%C:j,EH,?u7YK@Qh-X?8RX%M@bc<Y^_'f%+U-mtAPe?,5\bEZjgE%ffQk5*l]9pLCf3^*^Qa4I."G,=E6,R1_UhWGN)].lM5:5@Y[
-%B\U?_UU*=6V1$eF.m<Q!f14rEOf)tYSNcnK:OIoq;"9\Anbc>QXkoE^%ir]q9u8c>ms5`.0[a>:*Dhkf9a"gHP3d+KUIQh.e_>hj
-%&,YYZ&qSEHZ?j^\%j9)r\'4gOiiIJ%b#4_hrd*_bs#CND_,Sa@:OM7"T@@8CbWb8Bm=]#r&oA@YMI.^b`sDFeoNI:hmht\Ub2sSj
-%d%_kfLq"p4nRG2U'?ocsQ:WrWI(]'pRp3PEa2X[A%t(6;L6hQOE3B:pM.i6&c_:%2W`YLl&VddO*:H8=S:b>2NB2s2+*[mK`*UWT
-%3H1#\ZBs+O<H6saMENKd>Mcg@n;5S/hS=*CTf@&9rlB*VP#%pX3/pAM@JgRgo&BfO^e%T#*7hl7m:$`hiK^0_*=orp?6pb7&f.AI
-%j'%HlN59KH+K%Tf-qKBEl'4e"F]pH#c<k\1o5^p.os,7&QXbHDQ_!WY*:$P:m"FQ`=J+k)a75Zm(LNI!`KR7tT>RP`Wkn^^L%4sC
-%duChn1@!It2SgS[B\eR;p#@7H\Vo;hZcYK'[/(K/6OVh41@s%FASjBV\uA_7HV^_=$h9pG2oCg40A-/t'7(+:[b@dJhc"7^4lsC>
-%A5n<U_/GMs32d#2Ji`qA6D*]]TiuCngVsn&6`S8/-4($DYeVVG/;QsEo'55iY*Ig'8@FC10r1G4I_P;r2A]([$Ph.c[qt*X=.H1n
-%J'&h?<94m$/).mL-S!f3c;o9%%f``m%p,gVc'P1qh=s4A(!K,+1oT7#F@<jgCs]2_9.ie$JQW3_FcG[Te5\Khq!A-k'oc3H&(aQd
-%16Y\a:Wq8caN76.iqZ<Z$fp=3ani$/FE#1IN^cKlZ$PKHLpP,Cj)i$'4Q:bQ;SDK\inWru^$\#BI)/^ojud+2E[jr$:<Pl#*;hkX
-%I`S[aj:5186R>l[ba/j(`*9an#&^_pgSml]ajr&=]qG(jo3jD#$NB]OU[1LHB1CQ4!I@t.5EtknML.ltbcMO-V6ZUm8m'WC)j<i'
-%s.'#S$`Ck,c?Ll>PT?SV/lB<u0f'-VW6R/Xjce11%o:N4RsFj=1Ol7]B(?%:?>uS8=g1j5:c`eSce/Ea98E4'oba;F[-`E#kH;ZI
-%Pc)Kl<HJ-h:KY-,B1*:n)Ge0?Cc34B9&GJ0AMKV1-<t>m!Pt6:<O*8MG9]H:S?O.K2^RJ'7,4:<)\eZtWgJ47P\[:`<lu\MZDjTk
-%Bqf'GW)=rjPP#5&5)VFmnpF3/e4j)7VCM+_.6/fB;X9TKp#H+(kIS=b^'j.deQ_IRJGN3Xjh;,$5Lj!+]7B`V^#cs9W'AgJc>5Lb
-%5SG[WB9,&64,@'Vj^1l:?$%mllTtM.bO`JJ5p'u(UG3tR6HRP2bUVh#4*55LB\5Nmp^g5H0@!PYi21fD\1&kVcI29UI_:+hrkEnJ
-%H1h.a^Ud*VIB11#g%3e.T9?=KRPcS$'.U4>5")c(NE*K!'X$<\\,\8k=)W:f!#^Kkf3!`"7cEVi<oK3=\14$nMQF?U(9CEp96=M)
-%@$!E:a1=sP)8X#mD-)5V`E+u&H_j\'eGk-=^E@M&M'#73k90XG')R:LIt)\>c2I>&_tEC-J+GT+\+LQfmm"WI*I[P(e\f;prmi=m
-%qYk`IqSSXA4Jmm`=&!a5:L1"bPCJ><p[S]af0d7MkF_;<+8inRjpV3pl;t`)rTR\TeH[Z*k<FJj0s.%ObS7ca$gDe=HF>LkIZ*c4
-%r<_BZ2'ib8JVqkerU/Ci:SINboKMY70E"PenrE@]53JcIn7-tip$i+X+rp:gCrFSSh.n#o3k>\p%Pr:+SM+0M4,1%a]'u0P%/6@Y
-%go;AJ`hDd#':_oV\CD@dJ[2kbZ50Kch%4M&\Y8nOmsP`:Om/TWC'W#7DOTK@j4o]rEV9`-^M;`&*oIk9#9,*rl<3;_^,&M#FZ5@X
-%B7_]T\;+\6B__S?J#7!7I+9[1FT^7[ICXiE\8TkQ>W,7ldocK.gr;%DmudMAe2Q_eW5F&VpR\hRGi4#j"Tg[CTa*ic"<^'UiMh89
-%5T<l11^5Lse_NjU%eh25NTUN7]f*s8_>+2Jd`M5Kk1AL7cJq2-%GrB53]cCqauV`pc?H[?(Of(4Y<!Lp1Va#"?A3=e4ahP%_gr-m
-%HniJHp(Opi?h>C0_nCeH..`OT_lT\oWOj#FngM.`JoPoR^.8#T[2s^$Z]`$,Ho3n^T#m\?^o]V=N^^)#__7^75*BGXqu283Y2pS(
-%05]]cPFrd&ecVk=<qQ;D)gn%eHpPCTFlnV8H)2MK^$ri7H5bc!Zfb3TItYKQO-^t2&BF]9E+jt2E*'u_*">h'/YKC<pP^*;OA$cI
-%6Zsd(bfD^jmii-i+oAP`Z6ooK7fWI=mLa7hF^B[C1C./4)[:[#[O9O>&Ki8+#PY=p^P7!ESc=m+@h_N(Vt>SB'6tru"7_h>kJSCI
-%<>StFc`W?'C19LIlqKPE.^h&kjre4tZacC^C&sr*N47kETGWD;$;=PZp*_d'KQ%$+Y07mp'^S[B-(XKaLa>jjd-j"P3=fu%n)N'd
-%0_X'^]94LgYIr`T<q70dle-&g1j7ch="+1'>OW#64^uqAYMR18ojt:B3O`G`"gT+1&#Q)KX."9L$q%Bfl.6Y>dmYhQZ")F>VhCa;
-%.Rp(7H!?HR4P15MmsMGM%0&pqR+'4'b;RWj4$BsW@]Wj1-eUa:+Nc7ZE&l)FEt%aEQj=d<O=PdaJr^!B;!o"lNe*XHqr:<&n:Pkt
-%Y=fRDfoK]?q7IsdB-t#?mg?k:LouatOmURg%6\gf%dV?c"*cBlb"O!j,aQiJ@n+>>/41q<pu<7b[:/`:E_;ge16=,[qV]*ZD,)md
-%1(?oGe&+>K(@[=grq@<_:lHcY#"Z\-qZJ1n\A2<6$h<Km%3Naj$tC.t/nhs.h>9V]h5?-'K*jHBg:)M\JX?YfKdHfjd)UJL!@DA6
-%kW"+iT_!DG2hMSsN'Z?jB;P'Jmc<o]JM,Kt!!$-#XrN@&=Y@eo<\68m6*2Y`'&c_8J=TmWnJ:n\kug_fR&iJFQCBrH"-@sphTsKJ
-%#&s$tiHS_UKQmsQg5'mk^2@=Fld!]:M:IC@"C!-"+Gh+32I6b%"1&,jXb%dr"JJ4Q4P-M[=J.'oD`PYB`tlJcSq(K\T\#7Q#/AY$
-%EZ`GmNmSRic:qlc(4^<N-NfML:-)G)fg*iqTT9KAYe2o*F-7_7=dJW9eEMaBAK>Ii!0*+d+Pb8&merBm,P+<GH<)HVOmaZ!,3Y)n
-%,#_tCUfM2Uq.j$OV$1s*;:3<c#)p*iBnZA$i:#JA*q>'.c-R[e4YdVAcfFs`S]b+b/6#aU9DG5mRjGoj4ZDk\#+='S$M=iZmh,bc
-%HVHiTDmkDE"+p]J"!,aLFTdD9kQ&6,ejC.;I$<k!RpGEJWj#/"&((T')ONe:EBFM"BX=e`fWh!G/7gr00pQFRK+k!dKV1mo/PkA>
-%+>O]TdO!*t!Mfa;@4'9u&b`%K@N]C*Cra_O9::`M6AA?S$h&N\\dCqo?=5[\Bo3*P44QG*4g(X>^&8@akrbMhL=IO/.]BIM[EV\.
-%P'U@U0ggL0Oa805cm+R;.;ig<0)IpO;i)0abf]K3MmsP51ZU2#a>q43=B*lcM`NT25kjb@r<>6SkU)jeTqg5ijhC2(rM9a1']]@q
-%5^i+?Y$Vu#:XrJkiV$A321aN";4h:\Gj]2p8epnB32iPBcsWI+Du6e^JJ*8GaQO7J^ip+p6mCj2psaO<;YQS7coJC_Lbd<pV5c$o
-%<NT<%=;d;X;:`Mu!X*?@+"-?d;C-bA8lad,igXJ!?`+q3lb'"@H*.%!!EoJn!KmXt!pJ'C0GDDdi$luGeDK:a7/2_UmlDdF;,hpG
-%4%(+3h_sN!Z64Fm9%>EuDI@&V>'N?,&#P-8+IH<K'@RqhAT)*h?]^8\P)W76W"d@06C!XsV7.(/6LUTSXtfJ63!U3'pJ$jU0W[%U
-%JVE'2mn.[Q\s0X0M_8QmgsuO5[$#c2L!R7]n7fQ(,,9niJRt0]>Z`?<'0jnR7DnsXZmjtK?r%k-[hT3R;_OWN*ESur$q>Tp,7=e8
-%0!$NF7B?jgT%3mC9-e.PUu@sm-HkDFT.V#^UkfiecCk8N@#"E3/nG6\f.am9"%3=WN=+Z,3`#DM<E]$(fh7_:Bo!XGRa+*o8sql6
-%Pg1*AD9$5-SkO6m^a%qPQ@fn0EDDe)A0BrF8]?ij7W-dFC.tQP1TRHf@.tU[l$s]-i.j(3@hGCiUbbPE^tTLZ0l3i)\PPSE>qG0*
-%(8ASR%4(i9MS+Rl>Z30k881c[fHe(%ZU`*@=jUC^n>qjsn-O61h")Stf*gtB2PUH[\#=\8ZWC2dXr1(+##*$B19[O^Ng9Z!`XWj<
-%J;^ga*9Zn<g3h<E5mIct`sWik:ka8P0.rakMmi:dpPMVuG]l'ml0b;$oA0`?5__>46TNK*6Wp^09sjLO_fm?mFj5A<55T>C['A/.
-%S-P-6@hXg-ZU^)p2\XTK3(9LpM2>sK*<Og8CbeMIqGSI`P+.[[H(i"I.T5IDh"l/KoEi,=$b$=6"$E[,WtqjDYRT4oGe67Kf^Q8;
-%U=lDXH"/^#&W8sZ/G&^4#E?*s+,n6UcYL,u%g+QfZ*e\FFBPu*C1CtoqU,Gd?n'(N"l";iX&&)"$XebH`9orh4\!"sqh1obXho!*
-%Rpg+bdXO@U\'-PsAc_9sbd<aA_JWl8[<CGjD4$EMS5#+21op`3F_EI#)2"*W2jM`B5u!9K"mkr!I%$,sAd?\6cPB5trA5&(.C$3k
-%B=0G`--Mgdgt=Q-HSPD(irU+k\UcYN-7Ef1inBq'4H6WOgo3GEqi6jQ*FWf'fD[)nJF/-ZB43@8V'pWAML3FUQ(cS=(T!kCaH7cG
-%'?$"F=!c.+R;9fg$WJmB*cJkQN-ids.."@nEA(PNME:cCm@l`M[Zqj5$ek/b<FAY)rr@_L.%1Co4js[a;BeJJn:\Uo(n,#^L*[U[
-%VX:c/<GCNfD"8h/NA?#*=Nq&2;?^8%(e5unB1A!P0?`4tYe\=+/JHBb)S-+=Knn;I[t2Vm0Z8JA(-us\ilMWf&X:tnRCQ%#Amnm.
-%PjPt$=Ad)64O<T:nl.4*O$\fZ^_=jEH_:`Ll@jP9VK/jG1fRmOn)d#<J_R>q'0-74TOo6t*:&>Y<RIZn;,quS'31mp;H60ROapPD
-%PVUW7rHnLU:Z5WL>>uKo'h*0Y_d^_P:"1+hB:Qf9NR\tM$B!CDV!?\SHe41)1Z3ilgdT^lZr8c^m*n-tK+t4Em;*Z1nZ9(RJjUVR
-%`)*A3Y[87C!BHQ@^FgFh%g>]ePXSRhmPMZ!]k2%X7Vp>e'5=BN.go,\n+*!EIYGf1YiM;K;6_B@'rh\?8,*eESrfu?Z7$gCAPkXe
-%b6;CCZ!\@Vgl"X@0pGm0q@Xqt`+Fk25d/DbI2UZl!]\!V3CZc9@r"Yi9Mt#LfKm;.MhNHNc&HDf`g5<:=<[7=l1uPQ7,TL$#+J%s
-%UU<W2K;C;:g537o:dPq0log^eS-t;3pT0'.WWLj:7>$hUS<T<X#&Ace!gkiA=9D"n@-9@;K3;A.;SjW?,mA9u78bJ<$G<^`?PDRk
-%E?*Q*huUcDetf+h^t6/&c01WrP6-rZd\J^.S^Sa![n^@/**B%GUa9Vgq/OEV$iHN@4f6phi3V"+ouJ_,1?]Gqbe,j-Kp,\28)@u`
-%D`53F5;MT*W.:[BA#HId]r\FA'OZVh#$E/:F)#6"m']L_b&^\:VoikD^VU[hp0u_$i^bc8[-La,P/;NUdA;$W/7Y-rLXq%,eSAV7
-%m%ZM=@9U;4ATaf.R^uWYp):\Ml^)tLGF/8TNVi1--Yh$l^j:o@D\D)MU@%Et,or1*!XQTD!5R0[^O"r&l-(LO"Ls/RbIUPF8ZAo%
-%c2=,(^UE=&7&I?lX3=#L\kjr<V2S]W>C&q4[L0Ad:Y=^5HXJ/35D*M1]jRnk^6i7LG[==#aA\b'CrP)p#I?Kh_J+r&O3inVWn?ob
-%@#MX1AL@r=?"E7-#C7d!'[%K[WV$tV'+U8"^.G[g//t(_`JXCBm'&P!U@aJ,K<7Jm"_*72#@!%E'8LePMQCjXFrfh_&r-P6WQjcr
-%N(FkEMF3dtDt[F5b2t.'%p]b-?F,Vf`c3ETL;]J#HZU6boL7<H^.KB&$qEC!bD=i^?2u1poaEY$;&H=m'.?+YT0Se\D1In^'>)$'
-%Xk<9`=HqWkju%mXJIrfj-H5C;pR+$a@b29M\XJ6Q,)jX4$K40H-F$k)L;\Q2CUD594cuS4oJBsU_</6k.=8d^qK$1-NZ9mOaKZ04
-%-ko_o1SKceG.7PZapAXI'5VC\.Rr$(A(Zfo]iVuqjh^@G>*_^@J7Cs%":5e4bMloiUDY+W>gI*B%(ue41,N(,b6%(.[(Sa(I`N/>
-%+Wuma%KW%/0He/'%$H-(bcR<4Lb@e^/N`bU<@7KLYc$uF68-bNQ:B7q*r$?p&LNOU,f4tn]L@np_^)#e$'SIVZ4ma"P3.R:E8=>W
-%JQU3PCt0Z94=ASbVW2n6EO'\j<Bj3oag/i3/LSd[D,)V>\1plDNDlNo0W7;LMNg[<&jIu\81!WI`*4_i$3H@q.P;;7Lu8mhcq78p
-%R^Je"T2rE%=X\eP'PNJ2'p>RJm>.o]V^<l/-2/AeZ]d"OY\JtIEA,SqEXnH]YQknV4VG6b9\bd]`%<t_[j5f]gsQ6i>1SnCVS`6M
-%%'^(;5dE0u6FKf?2>GO<40UMn%fim8/9;-@8M$cBk!kJC=cSdKq5i;mWfHFq1Of"iE/4C15Zr1ZOUZ7Y8:jW(Tf<MVK#E9FBuBd-
-%:uTcVL_;1V>mMkc,aJ.,f,bL5FX,iU25#haJ#ETor_2;nTFANE-1\!HeL?.mKn<iG>Sr'RlA5XbN'8_G+.:b6>]\GgUt)`sZ'$F7
-%@Wk)t">9Hhf5o[+P:i(jTULOKN!1[6"(d+Xrn=(.^c2QS%G2*]q>?2I["KQ^Re]:+ii!`uP=UIt7=L&X$8@TM.17E?'c,Sd9;,W,
-%MA_WdD^kG"p9lY%a&F2?)\#XA1og>1@K8nAk3WbYA@pPUWE#m'&1,Mr_L`,cqBQs]mlac5)?Xln9i-1@kXWDr7_Jru%n_baO'9CI
-%_,*RtOgC;co)Ua!hCE:@Mf/[/o(ereg*&k<:k<l)FA8094i^"%#$%I;;fbnIW^u<;m0lsV_("DId<\h#=[Jp:OI@fM29![/fM[hs
-%/X+GhE045rK]sX&VIn('7)[a:Sl^fT&LE9fFRTop%.S:q1lF[`KMIf30B5,3B.AfU"%!CV;N0El#A2^N@I@_5G*(h$[8LOM``4e.
-%;hE=U7qPEZ-R&/I)e@10n.WDn0oMBm)@bn$]!`GR@7G5#-'m$nU(u$06eESdQ\[h8$T[g/]g;/SAC!*Z!*nCbca4=g4<&JtZ8N"N
-%;M>ha,6BjCs"FX)cM(#i+W<Z13s9X3+ET_tn6QN3$&hqp=9@MW2XX!m$sWJ#4bgXs<KQO6Z?n7)WpJT#d*TE!U1$Vm=&?_:X1bne
-%m4F14&oB$"@L8Dh,aP![a"1jh5=fE?(1IE1kR8*@,Xe%g>6r[bi>0;;6G,a,apWHV@88_V_S@a:b#*D;TIJ9h6A/DW4bn8b&3X0C
-%9;9Lb;&mIQ65YLI^C\F_#'E*OfmMm(ZbnQ9/k#k+U:Y!T'pYJO";;+od]dt5oIf\i$-rmi9Y2n[F\/)ddXhY^s/;`H%X/L6+lP$t
-%-7%BCAD5.K8+OogdKYU;DD:o5"3VnEZ"GS).<&(/XW"aKA[>sZ6tJ\/TgY72Xo@4Eo`'$*O4D1Qd3jf^f]a'SQu)GP=:?oJ+r3Q,
-%=TO`3BPh@G-b\Mt/1P.=$hT3(:l+*D'r\Sk:g[+OP)-d[YSlNnff:"dDr)I5pS<<7#`@ZLgaM2ajiGq<!8lHhIQRS(6D3l`2I]+g
-%P+C6gh:*?E1ZN85LiYU9I)(o@-r&]7'soI\Zs)Tn)->#V?H*s@][&"$5X4EOM<?nlloqC(naq%`SMdt9`\42RmHG-#%Bu%tlL_tF
-%T)Pmf`NXO7#)atN%radm"/e65CZ9l3P5RuG4s_IJp-'d5/G)ViQ-J5@4O0X:k'\Zb9p9p@.g]d'6(GP4m&7-o3Y,qT$LFF:Ti_@u
-%B(fV10&cDlHH_/D+GY8)1JuaPq[qS2?bPnMp4htkEI!$Ok<T/sA=b'^8*3^]Wq1%"I"WVp"@#H/FF]#HF_QYC1HBhSKL?,Q(8M`,
-%`E>e,\]m<_Bs7FZ/c%6&#\>hUE#[sMm[AUSh0&&r/)Bk\2%??c1^%BulHG^1D"AFc\2Bg1:fBu+Q6Jt$4'["ukp9.oJ0KOg(2sk"
-%$gtqKP>6uc"DkEs=Mi_7?>%N.\]Jcaa!JODJL`<?E,^?XZF)9na]YZM5,DlN/S:6/LY_hQ>f;2dK7GTb(F]sT3Oe!a4M8@j$p"J_
-%$#mmRO;SXfO?;W.CpE=@q+6el<jq)[a2fYZ_b/]@B=O6L>8@@rh`B-)2/+10@!#!S%_^s0-5[2:\k3*(M9=->(7T3H^t-0IZIU5s
-%buqF4i$B_2*LB<rcn%[Z'aJXXA,o_^Z1)*h&]/uqIVY=US_]5^)9u5kDY_f7WQRfaVf@$es/P,S$H.A4Za_i2gRruR)4XW(A#CrO
-%?HZe/$X+H>=g=2DLo^PI&ZM!$!K-c(\F4G^'dn$q;YDg]"Od:pU*rRbL+!BAekpHTl]V#`dJq,hW9uG^;$,06c]isf!!!b`-MgiC
-%_to`'`YGV1/-.'Z7jOnKr5`,X+*j_qM9HN?(V&51H)bU.OU*>R5bs?Gah\;3.IF]!*LBSG)46'a'l>5I;:R_5(>K"o$Xr1,=S+pR
-%0uRNt$-S.h8jJ.c>m68lAlc=h<n:*e5nLo53!c6<_\NV2QBX)FfVgSNp3BTG2Mbumo7CDa:':G_lOfKk5LD/2-I8Ki+GH%u+a78%
-%>VbWA(,fZQ/)aimUDAVXGg;7I68X@X8r,rVi!).YoG0A=1*^FL"Z<^n;>VW/9[l64-X/Jk5,)9HR'k-H@dPF0>Dhg)l"P,skB'?i
-%[jSTMNWR/AQXq&QEluP0&jIu;>f2^t>T9NH6oG2ad\I59[]kU?-"WfY8Jk?^F$2t(e.As'B(%;D9?R*1l]oho,2lW9@KfHF:bC-R
-%4F(Z1(AK8bYSEaF=`T)hPSdB:]eV&Ze(?]YjdlUr-<9.AP%9C@"9gTL?d#)n""V]_SPM?)q,$Es/N=([3u;15h-NlKTlQ1<gh.!i
-%[f(pGk;EP4e.@TA)tkFqV\JijeI(\7PZ?C"+EtfLI!(@mUKK6JLD.@fRCVBh:-1l\"F+bHS-h-s@a1J`>#k+o0*(8lJ0u9CYrB,+
-%A]K\Pr??=0=S.>S5ec5IL#(%s2S@2s)iJ-Y2Csdl)WJW":&R`V;!N)PD"c`61b@[8TV!EnfmT?+@qTdTAXAU3FjjA/C-rjX9F"U"
-%>ILIWaZJ0F2t0:Zb>*@T@`+W%d4n#!h$grag9SoT5^TI^];,nC=k>.<XFWMS>2G,RfQEm!hpcVKbSX7/Z'Xc!h@8fq15^.*$H3l/
-%9<Zj5dPg/m^F,7c?RWjk$%3gS7A_+:7UL7))"Pa.6NnZ4SO3k0VC"PDNJgLE+Kr(_bN.#f7@:iP'5,DaL3l'%8ZmX,E6<D7LkhBe
-%#!OmEP%uIep_4>KoNk<63@/`2V/V`IS/_1ZOg8;mQI&)SM_Ogi?5?u)'>[`6WQ")2asjsi%!+Ir-WPo!0/\/uhNC?r<WT;pdgh5M
-%Ue[O?+nl;)qg^Hc:lJgPh*d$!9b_d#dmO@p4cK',KF6q22KC.qE6;5gbq(=[:j!)8"3Oi2.$0E7Xc2ntOJa:29B$g*(rN%_F9l)5
-%Ym<W>&JH(!qYW8PD4#GM]u>SZ2<D>,MZS\l.@+L8<-Uj2)lB,#:tUu)A\ZNQ*=8NIkuoj3/Z/W63h54gZr+]I!]F4u?,GfUop.'7
-%P]P+tB4,`1.-KiGFTbBD0Mn^XPOo*+r3bf+k_8[HlX58@&DQ+[nODb*kb'tYS9J$S=Qr3U2]$bGjkgr*0+fS.8T*51GbdIDD.a(%
-%,tNZ+/lFU3Q]![t+rMV/XlM'*B6KQ%nV37^(`[^6U8Ce.)7&9^0s^#:)F0NqPqkGE$qk8mBqefmHje@[E16!61_:]CK\=C9b//^8
-%gd[DW/Jk]tWi44='5&Z#2#1e^Q#*X+P,1<#,:ea;K91dp)9OBqYmdPKPRQTXN3*6EF1Q269BKiD37`.I[?U?sl-QY*m+K&+W%cDd
-%j&-hnhOXgJ)igIhq6*2Yn&Z3rE`c&^hMWrhh1uuuW]g*J%J($UP4WRXDqL6t$q=kO7Pf+eK6Cof855>T5#_F,<Os.65Rd@E-4jSu
-%JoIpE-JaoP^!gP5%OoH)/$L@nIn])6p%r:"0Xt</cm+m;Hl+2NVOJT;A"OTmi*#86J_B;:"#2Jn[Q(f5!HJ=b7UelW6"A'2f[i+t
-%6Wm(1&`&6(BFXq.hEnL6*Gs\RdZE#JmD=3!B,QJn2B8m2!8A4aG&FUWAtuW+X`GmRiY659k9OVn[M$_5ct5B\_f:rU<r)(.Nnu65
-%N?kbl-$b]@J/Q$gcQ@EEXMsBp(<0r0S1Ts5Ms5Ig`fM75d>W03EM>\k&<T\RQ6TE7G)+"K]!3[CTA^5ri-HRWQEnK"D<B><+l<_s
-%\G%W8:uB8sKc\ZVNQeD=*nhd+MHH\ofP]+c4&k[cWAguO>&sY5poFR!6CMI[`X_;[9LUb/S2'+.`c:*ZN!5g54U,rC#n6QsWON"L
-%)_c"4(M;Tara=W.dUgiWgZpW\YjB?7T6t0Z5-f6Yc?>LLA5=CC@$BZe`j(88Q6hMJdqZ#9>LJH<Uh*+N,>[1@CY?n3kM<e:h7sf:
-%:s,^l5%[of_/"\s-.4cN:sF((RrJ+_bq>`3JA:1+>gQ%h5t@c\9Uq)$eDY5VUAKa$8b:Df%k(mF5;=Z&5!SRg.=1V"+2oc>C#Y>F
-%Kcs0<C9T%?&-^5A^r2#+Ml70(d0YC!&9]LlLPnP@QjZNO.k"DkN0Q+k*74DRX'+Z,fdc;eP@=Y]^(AU#lYe5AgP\HHcY_N=g\l?-
-%9SR4G:]aQ"arJpMl%"DXKoo-CQkDkLnO^`hh+W3t]'(UW+0.#([W$LcX0OE>kq[gZJSXKj=[2J+QH"M(2[ep[m5"!t$:<27pBcZX
-%/G5O/bYXZM^_2XL,G5iIXIgc9.h!k*S+n6SFT@+X!_f^af.\%OeNQQe0mm3CGgUd(R_ZM>NBV=LM*%k#pV_[tjX[n)dqInWPs.dC
-%)EA%sQ=IG>#R2p4BOi6[nYl?+q[.*<Um,u:5<^21<J)Lc=ak)\Bo2$D+]U(5-5N@#EU<2?X&aBTN0a:TN)DG$\a#oR/5VYo,aQp?
-%!(e;FTNP*#cKJ<;9.-$,8[n)k$6#RK!:P#t0F>oj$K*nA>?NE]`0M$nV5)6ORbCCjF)&hXapCF(@iIF:W+^9!FL!<-0sZJ>"f>dS
-%;T?.)*Ot<K';kpKIBLLKcCR8:*`7788]j);\aRL1MI#dADsikEIP5#*Yte($s1nl;(Z1N23hH!'pc&D;3HBN.+I;#YS%.-lfU*MV
-%3o6Y=4]>d!kghi7Z;02'nQ^r#ghVgU.$KkB\n'j,@,L8%n[+S![3j$Uhoan]1So/1eNkoEMZ=dR,?)EKpR%A*l9a15\"E5Z$t[p6
-%3b3s=p$ANM\tk@R^g7Q<]I9OY0G<#DH+Rjam=X-+;S/:,0_[#F=SsW,R.u8UACqZBF<!n\@4!\:7Sd>pVhS&a3%Z(NZ-P!,4\;:9
-%4G%heIAUQ4Z`I>]E`rt2&Ai2ZPk\Ds"4FOMS<T`5gGi">p:2UrT>aTa^I8i4Xh;X\>d>%s](OdbWL0V>o9(gmA_:WLe7*A'aX,t.
-%a$]Lc-&3Aj]7ih]'5&]$2#3QEcJ%j[PrANa[N)g-ZeoTBJR,)erAfpFq[UPSZf8G0J^QVr5I,_R`cB@qf@&q5idI%.<hAA-a2fPW
-%[n7VsB<mg.>>"/5Bt!--SXuBaV:@hm.VpL)QK*sNG-^JgOQ7YH<Tflt%2K=e:O0KZoQK:5n$B[3`'<jBgMu=bBBRVA+*J,'nB39O
-%,>1B-H.G=q2J1WIOVR$FdW!YJ_eo4f$JAp^Ai]"R3(Sr1#"]/HFN0ZV1qaZ>(92#O:3G>%/0DN9I[3![B5:)0PU1jA,hag1X;HfX
-%lr#U(H]>,#N$CAFNU.MHQhG,7;RSfNWE:S%Yi[rG>in%H>f(n-BhF6j/!%"bOfVfBnLFcBXH'!7*2:GFCsdr2cA,k?B9Mk[L(J?`
-%a/LIjS`CJ,@\=AVikn$j'D%SLBmoMH\h*^DBs"mQJ=)d)X2&-4E=C;Q0d`ogSGJHp:ORg$iDr[1PR1uljQIKDCh7"Nn?h[;c&$F'
-%['#63pVi2N-A3\9GSr])Th+<@fG+'^'<:\,1_AoVBHTaUR'gj:qffkGDXHYUS\7E_QJ*lI('rL;%2^^O\'KG\;LjSHH2F<kC!c(^
-%-Cb4f/1)-o[:E+?"ug=^itK*o0q.l*02[[o/<A@CBs!_uR7q5I@RC0)pjaOHlkg5fN.J;OB^_H@Bh*1f]2Ugp$]VG01Gr9:K15lN
-%B-Y=*9QoRH_MF@$BbMbTO]WplC&)PaI1%T]%LciQ.Q#;Z<5<`)dH<QUqA@P]["8?fSPpb-YLoqEnk.(ucg]]1OtF`"R/32M8(3^&
-%:Sk=/n?MK+62WHt;(1D!,bsA%$1faQ)U"-rG#dI6G&GOZSK">;CbeK-fEu/;7ZAr04`/Q[Ygb*`3HjtN69F9\QM2qiUDT.mEjcuK
-%\cpDkR\Ls3_r3uA?H$%^lJR4eToG5sf/htrLY\+lYAsKJNkn@0W^Yfrgl'*sR:NaN4*L6kiOBpX)`Xpsi@(hi/bjA1;6d=5:%M-7
-%YAIuKbe+^>,HUouorhI;9+ejR[q&\dgWhM-?$8<2ZjAGW0E`XG*ufA5,j2sLgm5:9&U(LTK[pq3+!D_R`qJ5KD/i@Rm):.EZ.#l-
-%YmaPDn<1Y.6@tT\3J>PuDQDekUpA_^@H_.sa2M#)iX5-6;l7(A43j'>mbLY"@[&j;E6\bO83"n%X6q2Gi3JcWf1MRUCr23Ejd@62
-%.T.TJ.+3k*lh@>5m#/f]KQBo0]iu#&SaL(-icHgb&XK/AVXl,=:I0PVP%K8X75b0Wil&Vco;_5b9`RlY!R>GCkmZq&?u2!"B.EM,
-%"D6&4AE-8`[jDat1_%RN?iZRY;0\J8+PO8QMlcQH-\A2C;iAb;EDlLdO_Bs^o;)jopC8?5`>Lu%Pb?D/Sb4_A8"'_XBoIe2!EuFs
-%X<>]jGd]]!+]KJP1B?-"r.*gTW[.ekER<_/+s$to2mcDUQ].dmc(1P$9tL^KQft'Z4(QDFhB=#(^]P$(M,Ig(W[S0d=U^*'F$?Zu
-%VYX92aM*0J(4ut_.!3@K1)gH':cQ`2.fg@4C?V(7$O9L!R06>W)auU,0[\nE+t<u3VpnNeQu``k5toiZME7\c(td_'63!]FIP&C4
-%5\knD0W9NM:=*ck'bDB@g1&L^/i\8?c3de8ba*MnhHhI&1bUi24Y3j$c32'FQXUCLmZ8n4&B,(m$-!<P,BQS!RG8usW8a'cTZC^m
-%C)?'M\stNWg6#Q('L654SRmLd4Jj@:3:!jQ2E;H'j9gH4c3-$s)b%?F4NR)l1*=sYB4eP*nRihsCnFI&$u$+J[c8irh81Ol?O=`,
-%T3-P@j@PYU=h[penN$!%2oJ/L_>Ph>&BAlt6Ph]"lS`lU#mIt/7=GB5Q8fN,S/Y0:T9*8<lm@ck3;*sm67f&&P13?D09/@D+C@7$
-%AJel$0OK42>k@9+*aT+H_LiiL[=VkOC0%%f^m(E*U6DB,KHo#pqIkg`;Tk"9qPDbLTs3YmBI/+dNo"_*1ECK/*f9KgeT%l<:e1p\
-%A.Y<,0W7gA@U*(c0J/766DFgm&nDI<QR6C1j#H7aG`)+.>k_2_i=M@Y^1kGRVk!\4FYT13%,V+XZ%PX,^3$/?#/gqoV>$4#@sV?!
-%&Ogq0<dQ*Di!fuD_Pro`E_P9;?'XfW-cB!;Q'#B2Q'PF5fQcUI^kUn)n`"lR<)ti(MM.>$af,nq4VUt-+0,r$("beX=\DmeJYs2B
-%:Ip=YcL[uEa9X)7RtKl=Z?`J#%Hap@0(Q&U3%P<0:X+0!''gFtmhpF_0&nK\Z(MrZ</P=gq&E4fBWClucm!$:poEAh,rR@613b@c
-%X9*"t=Fb+NNV:"GPRT#ITh7d77V]nDL;59":1@NT]StedQ;iHrKjY*ogM\ml/5j^cNT1&a#dQ0g88P\i-q:9fIZe]@*'B9MN$Uk5
-%(l;Z(Q;Laj@b1s1/Q#blLaBIk4AEYV>#QWC,+`AuR,_rgWJ^mt=[LCnfKG5b:6&WL:NN%UZG\$7.;iRX>=:%2Mbm*/'IKaIeXY)/
-%rU:R$L;3qcmLYd/e1G"`#pa&62t1)ZBaK/gN)0i<%D2A/(P_=(d2_2nFOj^M^m@C@_&"t/G4;oXOH;+mY<kdIk[1Kg]$2PO/JO'h
-%'OnENXR1s/Aj;b!T?pM-@80W:igN8H#k8+f1dh1pE39b&+e5Smo*+b?#ZM^A2Y7tK(5/uYR);o27B[''?NC-B9TSFVfm?I4fYu2I
-%iI`;^6hoRPYd5c5P?-si2R7_s,r,C$YZY^o#hqOho>'cFPVsUQ(R2,aIdD[(KB>lJYp-8T,$'B)(JH%qR:dcb5sjTe^6*E$1B.Z[
-%LZ^\9R0689:)=3a:*6O+oPJ):k$$)-iNga$0N-%k1T"BN:Pk/GeRDEl$regUdR%=k/HfN+l\o94:UJ9Ko;/9oM#S&9)$5=V8erf;
-%9GEp5-SrGp=_6s$5_g!2,q@;Q<MHIg&nNaiUA4k$1Y<KjkZgZII<?0?(HRom@=dAS[ZiMLP)>ZMiN]We$j2ZP=]VE:`iNiX7AFI,
-%q+M6m"o_>-+bmlKQk4RLM%V+@=$b#5j8^'ia>cc:D_f8?UerD1F+2*&LX55s$??*413)]*SD63]/$#<m_bAD9s6hAfZaaj6Q+0p?
-%AK5?)QUi"7$/GuT-k7&Wbts6DPKcpH+$1g)RGf;'m7O,(jt7+GRFNGp@S$uNjA<6:NCZZ";!"XS+cT%0K+d;`WJ;A#q*5PcTqCL)
-%,"^^1k9apaA_1D'(OSiuAA?db-g,j%*;UlnToPn@h"g<JXs]F--?usF,!qAWh++g$'T`[NLJ-,",q'kXn?OaU0JC\/g&/:Jj/!3,
-%*NA2NM&nE<;TA=kVBcojPB?DA3RVCs]`8NNP9/3;"Y(?F2%4&Nlcc_A14X"Lo$!,#TI<HTQ7,CZbMa\+PK6DlL]U3N\qmg!(Lr@s
-%V^b//8gc/V/iZI6k.AjMB3)JSIHC7r"Gsj5I(I2#!R@(sN#AfYULr@7@[)t06V&p.r6WK#o:1NK7#+PE=pr7,E2Rg%"sudfWNdFR
-%VM-5Pc8chJ1ufu1,=8Jb=dDB*WN7?qERY'A2,(R![k[jeO*siU9s.%iS"sip$jS[^R05E.:@2C4['Pm1VI+.o:3if"Z01ndime>[
-%cT"&m:eA\RJ1:u/2#&%U(4[9a5H7!V<N'lVaE0",c?PE3:R6Kq5]<PJS%`s=m*jl\2l=EJR`<YWYE]?2S$]BC]4EA2:1.4pVl[nD
-%U;`fW*2;2aR!6tiEjchj#7)KqJjL,$H^KR<m!p_,b3mUpN?k/aF9W'H&=oNYVT&g,dJ(RC./I?8RF2s!?qnchTM>&R\_"3db30DE
-%3E=?s#"8h)&m6V+5p@huJR6YL`GI;'X/VcPI(GgsSC95>83p%J.`4.jEe.RHNpXDR&k=5GQ8g'+=2@F<Hrpb/Y*o!%*=T%PimR0@
-%(h,4uJ7N.L9*cDRJ-Rl:$T!?RAnP^SKX"!Zp?Es)p5$-A1pg+Z%.:SO=eQpLVG(:4-`)$UQV.11PY(e-nBrNW=VS7l>Xn>7[Vh)n
-%72,W?+IcNFLQ"1C`b94N`_:*/e08l=d5ckI=K-sm#V.K&90..Ie.rXh?q&;`N4CBh6d8%!P>F'_s%5bAVhDB&8nMrUZ"B2_BuTea
-%p9ZZHF%W;Q>TLYV"@s_D$6mQKWD&6cph>TJ-4DmZR5U>X'([B.#1?Ik5*Rp=b`aGX"ho+;VTn$So6J7*/_eU+T!:W*.Z5K4mC40=
-%C%,'$T1Nja!3ekZ+0-7?W(39G1rJoWI*o7FN3O.3S-D!N;2_0jPm1s-+N'?D-CkN[/'Y;PRt^/g`9Ym&_D&@6kUdIT9QFRQQ6MBI
-%0#nTnK-r<<b51%)9F!MqfUPiURoGP1.VY`ls)6_V1WSU_HZS<PS[h<F\a*ju(O(YYgg5$OaddWskCa\*`WoP`.'tPflA7f.A_/-l
-%.?V/=PQ7:LbG18ZA$SJC#J'13<5uT1IYHV0b'(M)rNU3R8n%F&YZMYm`a(c<o7&%Z/a7?-D"cj$6jmB]6s&04aYn,)%aWRjroejf
-%l;t`,rUW8Ls1\9cB!qVkK*B7Qj+,[sdqi#OHfS00rT9f#\PfmND;X9Gek_q$6(QV-n:Wh?U0eA\Nms!iX``Tf/T/RO@;FYB,(4$I
-%?4gp3^/4[r/h-FOPIS^?4)coF2RK<E*G-s\HYh=n7+ll=n(fYhY)jed(.,7P5atNt0ZR**@U%<FH<2=CFkjq95#BoRm9iF%Q0$25
-%Tl@q:2brEWltWatH;,#]mLcoi7lA)s*]rSB'Q#<@lCQ63"Z2E5h8[ViW"louPL%P-E@l:b0jU1BmZAN@h/;Lt^0A_kP+3c]qqhmr
-%3aI,O:)QhQM2o&l'h'hA$UN^KQe$^3?:b\gHs.O;bhre=64NG;4%0Q(>'LK*']uNZeN9!%*H90f8-U@iGU3q9\e_MKOhaXfRt1VD
-%V#p`p$Io:Z>LM(HqYOpAiRG6,,6&;D(])gjUt1nD(_6IN&0F*V?=A9hn_Y2PUF>&d[4Lf?D34p&e>dRR_ila?"D(Gl0XK]*"Yu_m
-%U+ckqU?YR%;.@&=P6YZM:m;7LFOt8i+F\U9O2KHCpfsdp((1G<%<B9D9Y56f(]s/eP(EX)70>^r9qZ=<7U;nsa=fbB^nmV-q-];7
-%"9]'d-3sl.:G@qR5QC0'M[2a#+q-T-LjY#Cnle@/J>c1Ak0D&(5U@s,'Tj)DjAdI'R_Vhf;No$O[7XCdngIDVCPeh9_*j\/XLo+e
-%&0VSk6R7D`$P=8=/6HLPW[JM!,#+:_*9;jO#SA%C&0a(872-'fNTgI+b9f.n7uTg6Hpc3S\9s`79'4OsNjWVMlBe0g(fEcuV2Yj_
-%n<8m)P6H.d:<Bch;FOcU-LgEf/^VDG%X)9^.s7Yc;Jo""p@=eAXCC*,Q2W1CIVh<X2'+78Hc]uq_btL^pL"A[]$1r4A7JfsOF)86
-%hRo`Z0nBeB1%jdX-C'-SqBBLEs4i>LO4k+kPVpOf5(Nm(5n%kkU%9IKW$*l(:#R.%_0)SJ9K5VSl!l-*p:7>rDBE8['.e-/.1?++
-%j[E96M%Pa*Cc7:b\ioqUJu%RK1SFl)a8qG7UUl4T5"KP,cgYg/]$t-D\R!<?[,pR24G3*l64*^/(G(EI<?gl@pY7_+%":]:ZspXf
-%0CQ=/Z*lW!N_p+Q_[458H;'+BcmLg2ou(:8Y(.;.a`YU[fW);5abeb=h5po=muh'aG!(I>Te<eTFWk!j^IRQ[?_e.qWuY!hq!uI?
-%?[]?]D>4#.p;8gj%hH_X>Ir]3J%35SP2E?i[CuEYJ%b^PiVr]&naiq7F-"rTHu]o:bk@RVV7g46KE(]'I,SF5rT\U-5Q,B2qLI]-
-%r!1)%KK;#F@Del:YJu',rk-5Mi@2t^JfXX,Js`03J"]btam\0CPgtcnmopD=K'NAl:uSuqW&oaF:Bo=0f=/fHa45Cc2[$)?*n*Dt
-%SU>\-?T[gUK22^.Q[Bd65V?pH'MIKjmmp@@QR-3JrE[uTK_<q"0OU?RJ[rXRZCg\G:(+6ToI,2hTg'X:9Hu[tpU%U;1Y-l6_!JtO
-%oajjIiHZp/^`al'=+G$J+r@'Z^(W7h1gR'R/lmU)JX>Zj$B7@)BC6iQTR>'H1`]%UXh7T_n7=Jj(fE@&9rXF8-8-NHa\':5JRBg9
-%I[B]S%7@)g:=\Bk]usUf0B&%M@0YW+E.V,dP>Y35L."R_.TM\pj>@umTj\MQ,Jq@mNc;q'[18,W(/DR3BiE]cgI"&2DFnr6nCfJ.
-%A4qtCaGL=9NXi0/q\kM^C4YJ5r^gLs^(&[OUc3`q$<P\MBZtIX:Z+WP;a3.ufac[!geul?VGLs%mC&du0X!@1iu<=:`,43DD3"57
-%@s6>3Vo+D=kUs(5TE>p*JAB8A.#T>NT`[Nr\JnfS64Z@qh+0fhA#R53%?Dn@+S;&i]bqtN/-DRN"g9!S#ji>`%bl]q2p=PFhuJ.*
-%J:MLc8M18OHp8qJ`_V'`%#O<^#bDL@&AUG.TE(a?h*-BV!.IGmA,^f`KK0VeRuZ6BNY7)aGQ&Vc#%tZAoniN3jrV)lof,Wk:!;sd
-%T[NM3U4YNMN7P6\n1C>Uf20X-?Ak36+U6,>H*h/=)4GFlgUh"G8(:qrCRZ*1;.m*LqYRG`-QE0@04AlKJc^2Eb522U#"lfp%kLf_
-%?Y136635F>P5,G!!9IgEF9=-R\GYlTE%nR((nf/F_k(7o(Jl'sKHW%&f2&c,&2<St&g%92i,[4(NEK'q%/B\($"2C`4!UiN"Ukhd
-%bs<`d[,OK*A1.TEqb__*"ub0rRJDEeDbF?pgW4pDRn&P6RWVDj,ZH8i)&Y0aW.d>80\>M2idlpF@(PQ0T?/`74f1="cKLMPQ]4.u
-%O=)W6E`G%\DsHJ:8%>N,n>+3GLs5M]:#N`$(dG$c&2Q3<=r'4a3/F\\E:+uqP*6Z3[$7gd6W-q,<E4<jH"bQQi8B&D(rh$aH"9d)
-%AU<30/9tO4l%VT*%A7"WmYR\@6W?c7&\)YCl0'Jbk\o5fh^[`fDKt$fc,V2p$HL7a9::`;Sd'ktOq)=3(U^0d7//o/]Op)sZCm\g
-%S,ejL2,+Ac-bP]09"D)TcRUPi@!-/'GW&%WH+63c5]R@ZHHGM$%jgl'M7i<QklCitDbR5,3DW5Qpo.poRK`Wi*4g7(TWJ3,\QPF2
-%GQWI*Sf#'nPuoB*n$p?51AQ<!BMY[.IaGZi;D`Z=-2K$7J!Gre_0:0/jqS69r%+25f(_Ti<[`f#I4"IDgJmd<-pB.E0,;J"9O%3*
-%)G'G+*c*6'?jb5Gapark"m@1)D^(/OjB'MW6%4C>K+Ym4l\'7XSkeP\:Rc*r@1J_YR$BZYe9>?@':P^hj&[q;ND6d-aqMO%95GQr
-%np<(tH%I3:WlLkJ*V_a>"!qJf(6/o%%?H*(AG)/L]gTjBL%lCETKRt9EAp!1)Z(SfJ_frM@Fhn1;8C''2I].ld=s[jNR.ks9YX(3
-%+jdPYC>]REZZR8%UQ"XM*&+VV\HN+#P16E48VP!]kk,L[kOHWCn0H8W%lY_O(bkS#:'cF/)t@4t:a-:S<X#far1j\;:Kij"l'L>\
-%EOegb&_KWE"b(G>Ta$QX=s-@hGLUWAPh-MTKCd?"nebtmAjg^kHndlO5.!GFU!le$9jQN"6#t,k#?2Gc.N_i-3$;8Y!k.]7(6e7o
-%WZpX>0IZuI#^H&;@2?m+Lcs5UfO>>p#!_9Ia.k2aXO7;H<tE=ZWqX;nK'Fe5JLLg?8EhY_"?7doiIj6SjNn)u,eSo+(3EIch2.*V
-%3*tCNp"c6p!0RPpV`KED)]%H8dk(mLJHCF->&R3s1re]Kd\u7BX@Z3$Y"+!DQH]D3#,oS\!RGt2C>$^O"JF7rJ5b;J_qYk8a*n:B
-%\<d8rTPa`dLTnMo6^9,0LsQ.>9#'FI<iLSYqVfWJrN@aIBB>I3/Sqt*1k"E)iYN+gr\KR%ocb>SBE['X!N9Ar:)2,kW5uX+'S],c
-%&ZT`rNNWAh.Zc's$D8j5YM=no!Z59"U"p<@bk3L'St+t0&,M,?'?E?*Gn0BtjL$dj7C4r2F@Wn'rL3Wc30D6hHA:nGPC/a>*Jg05
-%FWc)Nh9Yj;HtFWRCbW[g3JmmX1r*UPCA^4ufKd+a<:\qW(7')@pl9S"](\.f0Pk^ALu-)";GBcL*i@Y%l-KaM#Q$TM2DE`S_q?2`
-%N6ncI[tCP;?8Z,";ZI=hn\_n7,OFjYaqje&7Yo,K_h[eME`p^k9Z)9S6+n<R%4"N]B0[S*k/k'/33AktqZq9KenM>le%r1t!hbRL
-%CC22'Q%l[tk2VuZ'Jg9U5YV:GZ_?Z4.)b(n`+1PX!N^GGUPWJ4!7m\K/$#7FCWIkBMub%ZAc;^"&8[Ke6c499>in'B#j^;ch\/LM
-%I-H&h$m]j4D/7ks*glsa/V=n7LE#0U$']b-ZNNl&_&8o!S'QUC3,?71V?8rdK2k`_#4ct.EYBksIL;<E2\Wje?Il+dl6289(=BtL
-%j$ZuLp^a*n$$S@4n?Hgt;9p1LiP))[492,Y%gm]]B*W)LRWb@!<@ND:*8OT3IT+M*\-[fm9L`IlKW?[):g^[;+>9fWC20W2?oh$d
-%+FjrqdL>CQ)"L/Y66IUZJhoGqTt1:`/^Wcd%Q`l#2'F#nL,_R7bP)DfFS(p*T%A,D^8#M\!218MY8KZ;b4cI949Gb0!1c/9VKn7(
-%`*1Y"%=mRZJ=f)?Uo58`ciBL6i..C">VTX&%f(sfYso"EEJd#]EKr6l6Ik#O`'>Nu#bZ.(:^.QH#(SQ&,9C<L(-<@@:X#aa+[Yo3
-%Uh0bi1m\5a)L?PpgO]DcJ-W6;nY(uEh=)cH`IlES6kDo)4JU?S%DuS(1^Z]e+AIZo!$`0rIUl-G4ddS%TdgmR(aeOU*2"t/Z31m9
-%'9Nsuh6pC&6a1(U1HPTN#"^8jj/usQD3PBLs.1!*?Aj\P*^FtsICO3`Hi&0>Zej0R%3mQWUI%)>(N3fCnF4)&6@06Bp'H*np,Xqt
-%iSfF(9>`,toe`rT%q)\1<<*q,Ekq,EHR=MS"?"7XL(PsUi44:P'6h@,\E+sFd$i_]9FlB8inV"a\7Z?^*I&9<RE$b6rf_]5Qa\59
-%L7t"=7$N*1E8P^hN:TNN1'f;k0Nc!.]MA`&\.hSejG@tHmKknGC0I8B[*dLNN`8<#Pd(]d#XjNCgI^4@0"nD7)`'U4Pf+[G?A7>2
-%95-)0cRlE!%Q&\Jjg!SrHuPJuAUR:MZ>e^J;&^oeRP%.H)1r`Un\EVh]5\i!gph2LeRgo8#!Ogp-<'\!g'n,Y[!e#$s1)Q\Z3@+g
-%NDtJ-V*N54_,rjp3RhUX7(E$4QJ<0tWG4a*!;MA'ei+U8"lgOk1*O_%6>7cBJ5?Ir@M>@7XMTB9?j)(-I7#M5[.)[\>X^RUkRO##
-%HJr3L87!V,)N.#M=j`n<LCO<"BaN]B9M79E"f-I;GS^_bXH=BOLAqo#'mbf>PH-^7!k;1Z%7/cDZm/"Z>VNl-&W,1$h(suo34pB`
-%EMOVu4`3&MKUaXhSMH,DLg_^%C>/9JqRYd2"/`lL<$_j0\f_h(N'P=CQ9"LO=:Lr^bb"<_Gro'g[mPIa$[PWD=rXUi-NOhuj.Y^,
-%[SpS+#aH<)155h/%Hec;fHVU5?4dJ;%&A%bqcLndH(+">cNcm`a><tZ6n?8_#[#&>/Lc3f-Hdk+G?H?=cDj?AmWL!"4YN0gcG6=;
-%5kNYc%L^_$.O]S@XZ-fj-3m#EBMBcI4[9SMDus3$a`jD?G(cfsViAb82n4C,M'nEm!8f#c@#kZ#>"]mg`G3#0n&SC\PQ[C[K[]ZP
-%\WiZn<0Ncjd=D?%XF?ZK:BHQ5L+WQR4F+0Ie]'^Ao+dcH$A"St=;?o%bQcjcmPkeoMEi(oO1lXoZ/ZK&W,ij7#[jRAB;t/^fI2b:
-%,-m2qo+4oQL@0$n;H&m9FKi&ieRNG6C_O5*MAAD'/d-'I@RHf=e<=F(_u.]f/^`TB/"X?c\t"dY.G&36q.%[MD[:8kVZmEJX?!A>
-%%MPT@HsL6I@A"@AMed^]9FY!,LGclr$Z>,KFWrr=bL7#ub2il*QA]J\h9:`g3.anm0;>'^bDD,f8.8n^cmpAZ%m5C$hMgKObBWY4
-%CFHb)?ch=u#<d%n7A:WF8VR[HJR9XK&Bt0DZS+h3jB.^1_7p()0Md('BX"."">jer3<,d,jq/I_Y7Q13+KI;u_Tb#De5UL$dkHsk
-%[K5D.1,'EB.e->>3286/WH^XW`l\D%AuKE@NL#:nV87]nQ.uL@E<L6d\?PeMB/YF$rgZNtE7TnhnZ`237_]AqD6X"b0_5c$O)I8g
-%5J)@k[Jp]+.35lqOWe[f!87b&^^u=eD2;>+#Yl7WJ!,b&2Y(@6RMQ8k#%4,E<E9G&@fSuXTDp5hfX[7ESl8M[?2828?1nS])i>Df
-%[QS86lh>>4N9G+H5*.=Jdfcnf_4goP&fR!hciWRcA`Eu*]d=>rUrHe`GopIP]qg$C#ClLMqj;t(#IM)%RNZ7g>%%b_.LW/k_?OH/
-%gB?%p,ug<lhe'g>c=W4Lalg0&KF#pU?,<$G6Tdm2.eN^&6ss4c[G;]QFI1Tm6U<QbiE.Zi?[VjLcj[9FbV4E:hZSJnq83X)WEm7<
-%+D_2$r*ort@9\:;);%si`0pML:B7ac@6j`[\=d0idtEl<6\Xha:u9?0WL6$K4@f$%^)gG3S-K*F'/mhRmd28U^rI.qZR5r-$_Z2!
-%liJiSVoTKe$<F`'*<^inVP)Z4:t"<4M?.>jPX"Z533]2t&_''G4PZJ(O"D2Xc7[bb7L4=a7q#6HU0-<5:j]SZaVNcDH5/s]X>"ET
-%oK_14KY4d_0PX2-'*RG&Q69N<c:6=<@>R1/ef,Pb+<]7K2n%3:Rl&32A:G#O7dFIg[QJsH0`g4#?=PrQF!KuUl%pN)2k;Gs=@*=$
-%&AB9[**kN)1hMiWjd.^8NL97o7K@t)+!A8reqL,-30;krb#<7![\+_"it4q-:I1Lf$dRi$_M*uDIb&)kci@';k(Y&5$-sSXWK5FU
-%^l5j5-5?b'I<e]:(2R3arT5/j[R_OMq:NPi?!DTW?\\222Z>fuJidBN(W&Fs0[/iW6A6#boggSW]sr^uJM!UA?sD^O1Fue90Eq/"
-%88`CJ%Z?4H.9[+KJsRV2$@^<66SP5-3BS_?69a^rS$@n&^26.PQ!On\Tgh!/183b64T9CmDhHuoKD[q-_mITIHmlcGp#A>J*Rlfc
-%Q]bku7g"8k0ZNft!!,KhU2:)g=Q=ISXfY<K'+T-tX:s*.BoM/kFI48T.7JhM#2Fk#3C)6s0a@Rg)iu"ppGuo&:]nNZr`R89*n/;?
-%Qb4NtD:fAqKIo[HQI&3$iDU=P-)KO=38imWTGYDSESrb.64R!mmce3i`o@0[CD'&KnsVH@e]Mm1+Skpi`b/.GUk.RD3=2<g(T)jp
-%0bsRFbZgbGU\jUm#5OT?]a\^@&)(Z066b,#oHhnX7RSU^"aBC#Xq7E!7,Ys0.@WYoA6j^ZQic4%D+H5O2=M8$e)Y+11'fkV0E%8n
-%[h@LEd1Q!Ja,ShE4]tBAO"<Bl*?k#>+BbT1$sDS:5]6a+8G=k7S)F,7'pdd?#tn5+X"RI;5*d>fQ?&Wr.Uc3G0:ssQo/7j8VEjq]
-%SjAYU:d0X7IHY'0r4$$"Q6<:GG=3>#N_-676AH.TB:FMC)m;)klUD8UL*7Pt011%)T8qnNpLi,HOde+^n8rCjPfhH@if=YfmBhSM
-%cZt3X,H6q$Ysldk+d7@@Tlt<T;/h/<WT5`:iP?W-0W:IDkkToHINk'9^e"uM_fD0+X%l`"Te2^Un5bl)^.39$Km`837r'S&:&&6t
-%-k?8>GUeI;g/q*@`UZ8uF9`mdE5N(d^\<mtVG0?Qp`<%__\@JFlXn+6`g*fm4ENbCN`2@BBKAPRfs!1RG`&F;@EjbkA]hdH)%I`"
-%o#8JKFh>*.&`$.NYn9<"\QNE4-QaD_11'6`q8'a\*_*5)9Kp*Y#R]M$*_ANq/9%_F]k)^X]e:c\<Feh*?X/Fj1f#/W\(se?FE&fj
-%r8c;F*WVK>lrmu?,8T92.OL.PRiT+k*p@Z%D\Ecmj$Z'[XF\0C=jtAUL>.0s[l2:uci9(e5sNOb3.Shbq(o>drH]gU3ia]7VDhk,
-%_ijj/*a,32+l:atC=7&dp`h(F+O\Dnb"'Bs3Pk6P?X?lq`ReRFjn9_M[<tb_!Vd'i(DFM<*VUEQhfC:a""Wo0?#Iu!J#Ak+Hs-$d
-%GI\;JB-FX(V$&c8a]lSY'J:^TMeGl(+e/WgHYj>sbXAX@=m,-%@uVTY?Y;74Q'G."s4LY&/53hslsaP'^OmQ\I,30D=dTE%b>91&
-%P06Z,JD]d)e.JZ[V@5``1i_el*TD+.r%0s\L_>f;$>5<gkGV+'I^^+-dM@b=MR,!>%e]c9`FHN;`@mRZDg`Su2BtF5C%//e%^#IE
-%8m>q#(u1tH9obEVb.&HQ,+asYCM0f)`\h%m0-O;&7DTRN/(IjH%4,?AlV(S*gJT;$hA?,#r!#=br^sErZ`8Q*7oM$Z@.<]$#ZD;a
-%T)#==&Zq5]#fUcU`jb_<9hD+*%%F]U0UaLH(s;!72M4Y4+`"raI-*4*FZ3&#Bu#0Tl>8S29GC?DAq]&fE;19p0NSGZ-_E,/1VfIa
-%0TX[[9qm76!Oq[S_8L;4`=)&3fkHCE4X"P^K?Js+bSr*i,I2!7)!>dhnG(@rn%TFm/kV$X&6rh3N>D_7@q<`L9`eUB<rJ:O#P=hi
-%-(_pQ%5'Rea.0BE#4p0`,HQf^`\&(,<LMAi`Lc6I2I+)/cXqIt2XP?Zrd2p_>!`]R=lq_#P"]X;D=ur79dR//,7OL[Y2DO\B2h@b
-%j)8Ra(?b$o:RM`d.G5nEo<H52ok7;JQfMWhO:o_la*b,4nTg?.;4AiX8r+Vu'X.89/28A^5*us5To.>+Bo=Y75XtS2A,9uK-WGUD
-%B:`6:jF<OJ.P\&02:Cm7F\E#RdNfkk4jCHAYNbgBGK*jhbpj3u;U0q,<ibPP42eVE'U"CGd:3'(Fp8L/Rg5^+RY&`c%\ILaQ#SDZ
-%T0S>f.2W(`R)/SH=S52qTg92>Z?k?d"REY_8Y\u8,r0=YdDl(2Zoald+asFCJMg7#;FZCJdW)A(K#W]T.Ep77&ST7mPD>C/Aft;1
-%gnd]UT6WhfGG@PChSS*O[gDm!q)e0*nAa2)/B)F-,kr$(+fu81jCY8:jrHQ)!atMAA=YEJkPTVqM>8U'S'W,J;J3:ur$qadm%RD\
-%N[_@G&2ulg!Ej4XM>+!jdPpI%>_YiPj\LDRhJ_)X4k"uR"F?!MIUb4UIE&a<*k*<AT9BN!Q:g%dSUr[LP4`41%81J$2\d^c1a8iV
-%!(./O&'Nhlj2W\p?3'2&4GR\=R?>XUa):NUOh0kq#C&_HD#65EO;:?.e$mW#AJug\bco@'Td6#%[N(E?EqJqTfL*W7Xi^aFParo5
-%*!'Q$"-N%51jI4TI$8feF\DQe%6m-G4^=&&$\9$7hr8@/!uIP"+779B?G.k5i=o7f'A+EuVSTN3'Gl"bqjL!=M)VY=rmoo,\*<ZB
-%O\)aHf@(L&CWo;6O8CrtR;#en3[?*<3?MO\#G,B1G*$4_NA?1g^]`b.h7RWe+_GFDF&3T1UPqeUAJ.pp#tg%167[CPGeJ^p)f?M1
-%]Yq<KkmtPdo%#oZJoEhI22nF$3R>1E:67T8_f.5\Tf="1\$Wj(Qo/Z6*$I+mKo"L\j%!Gi=h(OK_1,7uhIbihF=R:(<qfXlp<8=:
-%_.q#?#:Z41R:g'\Xt#3I"uVq+TpumqBGRMML9i(kVVOXhbl.m<I7U)a,oT#epb&s0g0cN(0=_VD_#U/kT7M'-iqfjZSeo>Ae_5/F
-%;tH)T+R/8r`JSU('Vhpq2-FQ]1/ad(!jf&S>c(7Ea"mj<_Zac+1btm0fg4+nJ$J<V6@MPknuj:cMW_u21,![-WiraWnKKn7\Mt\K
-%2amBI$@"a47nmc((O@=^5V2Rj,W`cbBF"M8<'Mgt+V"^p]?M\>@H!H#iK/oE7CIib]&*t/-Se.25uG4G22gau/Ode1fhYk"f<sBO
-%q(Uo<_s:@h8iY:8p6!Iq,GmeOhGhMV(R&0(nT.0fIm7Z?F.o5::cqi+)u1?`ajH32"7jK260K$XhS<t=DhI!l,s@0>f=#Vc&QN?9
-%aFnql(47`\Lng6/EgBVOFDi"%3V.f@,P4gBkGGJS]*Joamg$nDbj.<&UE8d*A&"IRhV[<q]_$!L*b%HHa^UJ`/ki(gE>3(^G?#/f
-%JE%u#AO0/$hV0%.GJi9LjN#J&m>6g\#LgBg&DE@/9M`$6L+59)8s##!>&'5\l)OT$%n0)\$`;'-2Xfg&;R(G>UkE"X:'g"('>k1Z
-%G.M;c0--!n0Q>PVV+I%D`r:Sq&aor\k'c(L4OLJRb4-)q9?*=.BBVFA];K22.nVZuH'u(_Q1aGBbaI&o45AgMq6s;i!l#TG2BtHK
-%f4@&r1O:]e7MHIN+6iYeK";Ye,+]@k(7eN1FL\LY3sdSP`iE7<ik-ORgq9MG#_`!5%RacA7qlTaOMQF1m0(JD8;[VV5"!,sKVHkr
-%M:]ZEbNZUaR5*?k&]%+2bbU!Y?$3r$fuC7tiZVQ5bt]Tko+@*re"qj6[c_ZP@qQ$%33!QTm!>._+1(lM-Lee?@%UL3Oq\P_8)dZb
-%e+/[`N%>_5PY^/+&Q,Q;8"`9TX(pq!dk?Dh91I!eVJWKJg9d'V'D'SAmG8O\@rW0FUPoO7P=I]9::q[OT2_s2.0dYC"#7so%UYAY
-%-BoTI?si#;i>59ORG"$@Vgb60QFqe..5DZ[TbQn60<<s,j1eP3Gk`\?jR&dh5iH)V0L6X,jJR3hja_Y$lo,ZWdnjMU+pFi69R5YB
-%UQ<Ja_5Jt8ZCZ_jB9mfe]#^B$[fua7s3H%ALgorH\r:BI%r]KAa=;IpWC[$5O=E.g/X(hd&jGV&kc/o`<>BikeWRFp\l:)[KN^6.
-%X@.a-nQ=nA%7Kp-ZFAoF^Jm@$'>XVfh[0L^qI/"0c;Du."Tpn]rkX;nAFnI#9=]8>.IW3e+I%8pH,3TUE,b,UCh&sfA.`V]liNfG
-%UiqgJTP5D.j2GqZStCoL;j)t7"YJ`9N2e8Y>L@5@SP-Po+XINh!hpti-.`;F)2C-qOq95eRuYm+;arcLc.f07qg=IYFQ=?_]EC<p
-%.fXW61rZDMTDA0IDo;R@9`@qI"*;#-WGjQZKpU&p\V2Rf,LOsM5]h%U##>'V(m;R69]Ku\j_VAEa<F+/)#%"\juMjf)?c8J6,Ajc
-%N@I''nM4C@]&2t*)tgrkbWe`44H=Zl"l:)K'dl-'a_1jLeJdoAHH:[;]fA9HR,[/E!,h]am6_ptf:\ORqB!$8Z8$$:p15EHfoC]#
-%#B,fj4+4jAD;7A:Up3FWbQ6N%r,E1W$Q5P*XsA1*f&`<;9=rCb"&PF(g8FqlC(7Tp(dE3lc:,H[%!mbAj#LeMqI@kRFHg;E>Uc\k
-%E50eMroNNcaIf(\^GqH97tt\q#@W^87p,)h%s>.[PW[]8#qR,(r%<=Jk_<!D0rmFU<Z/dQ2WsurCq@/a_p2J8RYG\$A,^%KIF(sC
-%VAciuCI,_Jr,((NjB#b\b5-5!o7-XrPP^KCqj,W`41_`d3_=;IL(FfV[4u?]V6c(4dAG/tmW'*[LQ/OGrAna9m4iE(qUeEsg^#LU
-%>9;1UnTb)gW.3*%ZCTb9RJ1TXgrC7p,Ao^$8p`4dIB]<r1kX:J1iI/D2J_TWS$/;a%NmVLE?6E!6utSI^4_`2Tm'P$nC->+B<aH$
-%#Ks:q\;gIMPTfa7,@s(0BkGlU+iZW;XoeC'BpKb`)#JF@l#FOd%bD3b[&(6fWFjW(Z7EmGI31NElhAc(4OY.YRW>]bV_ftG]A*SX
-%q/l\HU&UXP.qSqD0nsQD[s(#o`9bbtSn+k3ETl3NBOoVLhI+`WL+XYPq"MFBcn;G^/%]XSL7VDZGn-B*ruf'aIQ8K9'XeTLq%\QR
-%rAoJ`d!s8k_'`t[^8cE2s7ZHdY:KWm:T*KG(jDP96D\b,GW+"%35Yd_i__q,Q93JhoVZ9*CZ+N?[%)[XAb]cnXE<F!DH^lEm/IJm
-%B)gukDoe`HF&"\Po\1[B*<Z%]=i;W%".PA_(0$TGb?.:I3i^5Keq9n,(P;M7:6It>p_e?cDo?_T7&\,@<=mBJh8\PP-&D8ek`,Ld
-%qqJ?):@)BC0G+?KFIL7.:!LVC"5#BbcEH77j%f$:AVj_._K(CeP-L400A3MP])Vk?lhra0WfZh!i*C&h(q=lWZI:/e>\'Y#X-HM1
-%)8L+Q5A*f3F2WMSmF'nNI4_.##2p#%dTi72[BcZm?t8;BpGbO4V'pu3";P/+VA!6h39/c?kA$(9":jJ%2S&1GK@gs*ANN&RZA+k/
-%^Yf&Lnt/hq,c]*men"@JgIm*o/`M2G=_4(5etarGj04D^W9*(XZ]9^OEaWNYZ\V%Sk^\JO2aK157pa^]rJ,lia,ZuYh.>?k%7X[t
-%?f1lAo)G!j^a;[m:p"JVQ*DQjeO4LE.p#)Zg]p"%Jf[P.`e\DS\KN8CF;df&,HeE.OLmJFT0jra,).Z,#-`L0Ce(Q2o&)6H`7O=i
-%7iW$!oD02J#:=Af%@6_.B4+R3\`oN2[F3L0LFWUa<6B7?;Yid\'ST)eI1?1D?m^o+/b<0D@2FMe(3Be$OZZt?23Ml-+["T*I"Zt<
-%9*#DqLjZG-W9LN\-.<S/omTQWP78L[/M:9_hT(o8iEb<G$9`02^'7Z'M29!q#m+"<\,G&7DttFhkOSAc-(;^D9WIERQ%;=9\FT1U
-%JJa`/9?83DQ(k/\UVd*A>uLNPLq\uOmQFGK*aH8NU!MZf`DoM@BG)4@SK@QP_tOEmTLGeGbA*qEQB_eca%FrX5f-.e<HspN-1o#s
-%OhY]XVB1(AYUU$*M70hSDIX1$S-b7M*QhW,E_X")0k('+`HO9nd*F!E9!ELjnm'BmO17&$NhL&BEV"i.a(F(GNJuN<?4Dl]e,qA4
-%]34\5Xf88h27+X[k<Hh1@tU0l&APm>CX<_=/1a!K>E$XBj#V36SdJR:%6Pa)iit-d]AA&RO;bSSm#,?g7h"GW]VYLB!M;0ZY$C[K
-%F9&hF\Lp>fJ3MhVO*>sV+@72Fk\Luo1D2Z@;P=8l:TsN2Fu&jo(^$:&o_%Qs`^OPK(*GF.?kNU4T[/OBK**((`kM_d<"+_:mA4]@
-%0ipJEnhh2<$_XgPKI:o$NYs\G:_Fq)r"lY\`3sRnO0E^_W3jVPB6U3F+aY$s"/)]+[k!4!-EHt]h@pag&%e4A:?PY4kEiZ*NGU,e
-%(esb@737>!o'#eqZ[l\$aCKoR1-h8jk#ItqVFTlL0FH)kVc\sa^h[o]cFsKq?pkE`r\HUKPmI27a4D^OjR'1adF-R>b(lp/We$>C
-%:[T6&P6^[V?%3=o+o4WRph37?]H0CN,eHB-9sUd(%.5GKHlH;las-E=/-O69]HiQ)HjdK@9]5(oeeo[B6EC2LhtM51%uhLXE$"Fl
-%+##.p-"[Jr-E##.I-(NcK:Xk]o[c2\jO:cu0g*=\d?NK3O)TTnf.[Eop7VdEl+i)X$J551mlrVc=BkqWZ7K%blrH@uoM4'AGP+3L
-%St*lU#<E?_RDq"Fm.WBO-D@+M+/+t+bC%(;k%ddY0iRE$5r,f:Q@t[`EAO4$g0,cFZ:]DtME+Q<72\?qMT^rL/%b2+iBW>T/,9,_
-%?WE/.Uji\,i1SQum?cFP?"-=*?_m1V,LMF?`Lc)J8g.L\k82kYVeSnIk(dY+@sFejaMKs;)W:lI<?jW;U;H]Wk_ekB0fo/r',1L8
-%^Zk`\YKPIm.YfggY*Y@@5_0PBA')BE"<bQ3.p\o[VK2aW4NC$/Z384.c/"mAptUh')PS:jX)-no)I94!(KimJZI$4NK,3bOOtWiM
-%p`6k35EFkhbK4BNmlKMj.UBoOdLdp<<`[R3(8)eT+mPnpiaTQQFe&?\R!A+M%4\>?q4q_U^-U5^\:,L&ppQ2d9Mn_a,hEL#.#_KW
-%;nH$]h1rZjg;1)ZA5$[#Ma+5Mae5geFa9Pa*nfmtXra4iBtDG=IV+O*%dI9ghK46(].SR"M&<R&?aG(gE6'V+jXF<JWp(YX-#plI
-%0AopU$5bu2>h@$;h_od`Y=2Ku'>I@rX0`P>#KT\qe-R)'!m;Y[mAfN/9e2P#VRq\A;W'I!)91Gq9+]V;Sa56*-=_h#W0*;UEJ6Qf
-%FM]/c`T!hb+Kf2jXlT<A+<Cn@@u/<^6&1bF<g]@uM/L@[M=?\nqjm6q!<o9arJ\oJ7"j)$9>)nc(VuGh>*rseddI88(ELb!n3]N=
-%&RrmU")]NZc32NQ!fJFp@.aqEX88Lu[7@T@#@8@na@X7cbb']\;DkL4_n[A#:)Cl_Ic1=5o64K)_2KstV!dhFPe;7_#Y@H<$Z8M@
-%%qbD+_ub'lZBHFi6PqC#)CI,^g<IN9Dl_5R-Pp_D5uH97GU,uGF(Km"K%l%9AUoCGcKJU(/QO:8-8GZP_;To(BG.'f16R18jutie
-%<qo%DT_#ImijDVNDC@uj3MSjdU`O2WbJliP;VCNWa'i@1B>Ps-:!nq`W*mK9:\*EgY=8UM<GqsmnM_cFIm6;,KFLuodQK/SWn_IZ
-%YC0oVCGm#q,OU%mFEpcX;p7BP2t":0TiGL4$<)K;">S73\\E%Or;f0jTZrL><eCG+,ipqgd]UBN#Z^_nVK8QV70bm_%DM$WfYAd>
-%A0[&AggY`PekSgOTVu6#YB*Pg2Q$V*5]F)$1q)-@*i=6f=@Z#!-c6QM6!9T1&6P)dI!i*JSG8"2q4X*Y^jZb==.>bR/L!-+ndPVc
-%9[!ou3.7O?VE0ZeNO^V-QSM'hk`%M"ghKHs!`hj22aQX]0m("=Gd7Gd$4AY2b:jh^Y]UVF/j%aQ`GXG^U]`S0_.Lm[+CBCmU&)Z+
-%YA3i$,R-Z6jVd2LS-K.Z.RkV)QpuU)OFA,GS$Y6Ua:d)^0k(:-IEp9:UAY_S`U'G"#_A(:DNo4d8TJU6""nY^H0lU&,npL5L!DO-
-%.p]k';nakYVYeU&<.c$)Gp/Z<Q\i>?C#>o4SErnc%tH0Ii$BY<*)/@-/@BphN:dr=:inMtUf')\`YTunL,^[`H,Q;Dk/LP="IG*0
-%YJm>JDk!gGX])4I`8h\Ckp]'a6kNo4gE<uD3JNp_M]*l@[.d(.73!djXk[o\J7*-MRT#%Vl%R=%FPhq"^eXb(Mcp#CQR@6O9d=*-
-%/3L<3*0MH38MVYrO9f)?Yen:_Dh/5V:kgZP+Y+4`$/@%Sndr4Q&r9qQm>m5VDTuK+.H'-_(iF%",a;>3]8$opdS:K@FCih7C+kXl
-%$\H&M_n_d;eg<u-!hbrR&<(J<>QFU87R^9$Y>HUuFCr51R@'=d))R"lmqPprheK/;<U!I#@d>:-!l+-p(Aq"*&h<I5&QbN@Y&.GK
-%nM9&^K?NQOWLD*ZL_&`-'>K9#bYXXJ^d)?e;&;f3,dK6`fcnZk085!EOc&7mE`0t)O#%_jft;C53,;AG/cF$L'PCEBA0Oi<YUW%!
-%J6=1H)>TgWEE*$+-8nXb@+GBJSFlQI`d.rt#j=t+S8:mQE5I'3XtIF[Z&4*"cUT1`1!/cPOCpLT,`>sOPnMO2!&1>o6u?A1hn`D<
-%(n+aH?M0t>LiS#XQ5C\`rlYWkfbIs1\4?5JB,A^p9eKNh,LY5=NsD:%E?FPoP"LTf\+T$l[1?/t!_'Y-o9:_P>3miBUUoMTUff+D
-%M:.X'$X!"LES1rNJ=\+^3Rk"q:U?Go.E+'4&jU1u1F53*m^$faJZZX$p=[>H"2U%t.HkOFW@Kisb7G$NT3ksmH;K(A9_8IO*_T/L
-%(?#UoQ"ojLCuEI%V'Cn_IQQ@Q2RM37X7U4dAlt#r>g_F5HOD*uJh?MC.Od!bQDZZ;5pARJA(ZmbY].T)!Td^0aQ;GC5l]lO":!Ea
-%m_'>e+QIF@mq=*$;M^R,8e;*IA?rLSaKpsd7n_@f/PW$>8ntF]ZHK_-<)(@DKK*KtR+''?.K-L@;!M=EArK=B&$@qAU(ha+4tZFC
-%YC`!=p#^-T/jAlk(6`h=a6ctsrC2)V=hIK6G#)ohfo505(c4#TC`tCYpm?3gF0%'NOegk9lL?/.'>=;kpBPQ]_\sob#[[Z:^7YAh
-%rZ<'GAn!NR@VleN+Q,#K>Bk)>Qj6h4H/=P)>Rl=.R%U1=WP0#oY<L2'(*$9'[7uJ&9QC(]M1DW-\a=jR;6]`'1Ml/]!-GL4/0l8U
-%>*-`>I$]2"dEZPr&H,oHR]-%;j;#2)VH@7tD3J74T@Y6\N2DY\B&,X?C^*u#kUu`L\en'cf3@DZ@n<-$8b:GMY4@b9B1[*;.++]Z
-%(g*^?JJ82YWoa4CODJ_K\pPZa>o\k+#=ZV1LQ2<S^/KHE1cY`2'Nqq;LnRuI#"JiWZlVo*fHg0TOXVeq7216=Q,Srl>=/JKU)l#[
-%o-Bu(oI4p<4%To4"ClrHe5@>@b6B1X**e*Bf9:h=Wig,8EmdN4SfUmYGt*@J..M;/Zt!"B%KfF_3f]P/,#e."3MJpm09>RA'Vc,#
-%A[[I4Xbe/B(4M/pWp\r+hOosY=@">;eYF8D&U,$b<^JJlg#n@U[@;`Ka_"!r/ul$Anktno)JJ4*PL*1soCHEUX%ml.R4KW;5YhjV
-%"/iHV\jY@@kfpJM[>U$0rY72kcb[=h010)Y\F1KJ>M+c"/a5>(`D!oAhPTV\<g#3JgUM5X0&_,b2,/nJ.:W2o#,`WP$ibNU@fSL)
-%-"^`^B9k"+odTQLROZMFS6IT#d.RL!I4T5;aP#MV"f9'mojJe*n[Wb[eK-0VA@]q)\DLnV+^$'CVS][Yp+i8F/,LVBq`I8U<Ac:J
-%^pdea`"H3`f54#\7s2GM4e1X9?>YjKKn'GZQGF17[WWY2:uak<Egb=tp0t5Agr_WE2Zm3tZ,O]1RSl_M<a)@MBI!<Gh.g,?"@bsK
-%h/h@i;nnQA>&'=7=*PQ5S(j7jjPo5&D_XLqCbR@7JDH^JWi^nn4*M+g!a)Zl%hJb:nZ`56NM2W\.h*%0`4*^r:X\(n@kb&m(_LNe
-%MGffIcr#B*"e%>L#,=ck%Ftt2!X2Pg$k_M07(?9]q&]:2<,P,d[hBLC:/)7bdgetePjsp+'hFZb>?R"n[#dfl-,Fo:<>\Tj,;3aj
-%:2IA]ZkPk9lu<`K<tTBWg1Z;UQC6`K.5jQ/H6<ZOg'D.Je4Hp>TcfDj+dcfK1Wum,gP@g"4!30)fEPm7`5;?lo%TB[[+2T6;-D0Q
-%>;`a[+qfNuLY-X*+Ghukd6MMW)DDl7co0QFZ$Q5SOH+1s6Xid[&/Y)W!aUY[@VUK0U+Np7_cAnQZDCa1\`C.C&K?As+utY3=tmHI
-%GugCi]fS&sT*'P->/aFa/gnc_Kp<@t<tUugpe4(LW,W<4ZAVTZgK^PnWmf]//O30pMr"2,j=!c)K/JOuD2>bA[,>=SL6`gn$bHH>
-%@QSQW6)t,r]7tb_dRIHPN/'Q05U/XNb>P\#"ZD!R'5,h)ki\Vrk"$q9fH+"8YZ@QU8GH+qE+pQE(:Iu'5*LD]p_OMjFatjm`&kn9
-%Q^tK8k"5a1D3qE2,T<+r>p4&GZH3&4h#]W,aQ]e+e#OeVP\*uTTXeZ/(/Oh1&=[,1((Mtr#?kM6Pa*dOr\EcJa\GB;1(D"K0,2up
-%Zk%;,MY#>d$aZ^q+b+a+JA%>MQ@rncZ"p(.1$(H3LFuL.jLDRA3_eGnb=,M]MU;`D])6@rG`fpg;nndag`4J36TV3&S!iTt[US4i
-%;!QOWXt_[c<(a';%Jb/+&ruT6C8Bb=_HPLp.#9_&&pT$3>0TeE[Us$WKfPJ4,cde*/l!8"<cR-9V8\8lHHX>$9'6Xu0^-5(gSSdg
-%J5`d.29S/j,eK0."=b$]=L5%;8u1GMN5[,IZQa''4AaJF:Z\:AK79;?XO:*:_.2SB=`'(g0\qX#(H2e\,esuD<`D39hOqi)4s]dA
-%4LO-Q#?Rm!77)%Y*`3Jj$I>rfC'kY-gm3>,'a1t>&(W:rDU.mba8cHfZdC'81G5M+l'*$h%d-dW.m3Bo,CZ1KX<Q+^d0jYi>=t/O
-%eBC.8!(ZJ63Z:^:$&MIKG"bPjG9skE;qh_,>)"$Ejj[A:J/OAUA59C/-YX>Hd^%6"/!ben+TUecM>N\Y[L/nu6!'?9;_51BlL3b>
-%i&I3D4Ci(IS>`g9%7*;@kC?ne!3>/k\MD<1;GfEH3t*!&nmO,$1i4[9bTO5tl%5NaARocF-i'Cq(:BjW70pV)<1Y3;M'=)_Gas65
-%53<b"4^`DLLZ1FgM69boR[&SB_ZCKkq?ldVkRJqPgj+7n4/h:DYf?9_`30i"<SSpOKX>bO.:`c^ZpOa,#KSY$'f`mC.3A*=fATFg
-%Pj@"g^kL2Td9l&^^p-9A'&M`V-ZIu%`[;:GVtqXI4?WH$E]>?0i,?K$E.OZCSAZ:>8#f=NmDQKX7j;'m@ZnNDLC#,tU6a<\J7#56
-%5h=T_HS,?W@\D9"79WF5:6m=2:8eqDhuM\138cM+^`#q(2A<M#fN_8NEl2dWVqErk&=S<BL$q>2&T0"Q\HADmGo%d'_>NuZ`DHI8
-%Olpa$2FP<\W*+&MN?\.KQ^0(-/<?tB<V%4$Mp,;u4[[FY@3cPFE;5!0Qcc4aV1+"-Co#%>Y`"PWa"hCF5gI1ni_;Gf@5t]Xj=_l@
-%Ig(C*Q,c/!-`_EG1dNhB_+=4QSP#i52oJVP8L<%:p=es)_JDkU;2fUAFA"3?lC3h8^Wf_D/e"e&$BRN'PQdJQnl":hX/R(<:]Asl
-%a_bsi5ThjLPu2$3LDo?U;cM,U.[L8aIoQ5FirOAX2(+V2S)ZuMB#l8Ta<o[/oK],'-psm;!f@2QMBt\Pr!:YTAEAC)r]L2toui:/
-%61^XC?%Q0a`sq[>ckBj7d<(.V:Y$PKUa*4J8W/!8:P"n71uVcgUBAnE$:>9m(n@o83-S#:`%ur2_pO$%0Fmc)':NZ'^%Rgg+A+]3
-%5c!M"0PosRJes.@%[6El5)?d?h1/%(Nac21k@oIUWN0I\A&u(^E<'S`%c;*&(3c[oVs(Hp\1-[2;gj6a4gN<,o,s'JN&q(db&r*e
-%#"Sf*`7,GV":4`:15`:Ub*_]m2u@(M&lJ!gll")nEl4Uh#oH9:%Tcl<\hMdUdqET!)f.MM@7F*K(p/VXpRK?b%1a,bc!jQI"lSi#
-%D$-8fDUbbV(75Rc(mkqmNc%P6/=-iA:U1FVD)149REM;l:Z2f%_A^-Wm1aOP1u/u2M52U,;oP5l44rAd*K)g(l6IQ<f%CI)`t^ap
-%aPrlU/L\7r#&@I_9OrmV$KU)JZLlCYpoe^@ckZ.>]t:od%7dLCS5HM?0D$KM$+$#:J?b0M_k(0Xe/;IL7sJMmq\R?goW/IVAB;0'
-%*:u8;1J.M"XXePMQ`>Bj)K@U+j[<7Hm]q=D\Jh#u<0t4rHk&XZUZe-bp>^q/]h]$Kc#$=V:X@Dh[,m[a`d%a^'UFA=O.D-CY?Qa'
-%3dGGg!B`3@:4hL4[iHd+&nRsYbe\>)JY9SJjeAW>i&m3fXns)N/-%pZX#LRDVS$tb%LuVOpEnTAdFlEdhr<cM-_-m=KJ6uID4Zoe
-%NCdm1lI,m>P$M&#7+>sZ\a:_,e"Va>Ft9j3l[[V-<Qf02E*#he3R962YL[P=\-Xi.cU:;,2H)JB&Q6!<q=]UlP,KsP$Qq:oq]biM
-%9Aff??cXsD,ZgnT8q@Q@/dOcV2V]nJ:#Sb`:8":nVfT\:']EbV[tucpgj4u@4WBDFf$*^OHVr0/L+I44LT?%F)TM6].tLVnfu).`
-%fGmJC,pFjq_:)(YNcd65,d!GX50ma`jk<ZPXRD)7ZRnI&0jOLtYT1s&hA'RD6Th'5RdAhh#ii+j7p_7k(\^'(.Sg_j9nGZe)./b&
-%HekRZc,>%6hK@u?H$j'gA3&).VKkkUF;,\15-p6.#+&mpoea)%H5.utlcH67_uRs]jaA1ik.48Q#_uR$D*#6i3;L?4dPIpad**ab
-%U[te-[2bhJMW(9']j>>"C=e(X1VZ)ns#))+eQP*0Ys2_6g8t^ba*h$"2u`4r;H1jrFqa!dKG8^T/ilKb:f-u*G9DHrF.l_r3r2^K
-%,_;a0XuT#]T4bIh.NE-mZYE<k[]T6ACdp0<A0k#k>6#bpc)WVJjnRl9^i2aXdK%H&8N#:.W7=")n1m5ZII<csCg+KSPI1kS%[Sm9
-%7Q:CP)4e\WCo`8L,3aXT!oZ(+9n@,Sc`e^a%9+rbIB$0d>2bMg4)$^BGrX^-C5$Is,-pJ[[`R/.O's7Omb-If'OJ&Rj3Cu;3Ha\`
-%5B1J,&oBCo."73TD5N8V$^K$QM[&i(?O*_W3\M&_/;_`9ZlMU\?l(C+q&#)ghlt$'((0=E_bhQe/"CZ7>Mr]>d('J#p"L][*%O_h
-%I#>rb]?S@0DQ6+ACik;rh;G.<$s-(U6"1SW"g:N0FJgj5mUA%;LAs/KL=;gGf]pLn<9'j:ZP<:ZY:V_th'EDq.%Bt/>OMn2!_hA$
-%i%rTjh57B)CDhlq:J\!i@,`PkeB6J\/M.LEH,Xh1rNL"`,16p=TrtAb&`T#dF!`+>qN,KL:/JuJFB!5Aq?Hp;s4\e;Ho3IjZ.(OB
-%].kB0]9(=8W2U3K/("f7g(l$8?J%7*:t-T\KpkoM!s%\b*LES=8iWL2`k:sumoMX2MI5-/E?V\.>/Tj5OT7aJ#u:tJJpkFHokAR^
-%oM"F@6ilT[#7S1>YrB8%*en*):BS7(WcdnF_U7XW\0?1<E(L+c6d?3X)0ZGE(J-<NW\3=>lQRh\q*a;tg?-L7`9,IUf2`\Tl.r+"
-%O"DT%4lKugX=Z7T^tW%ZfiUZLg!H>P5;8hNl"9c\&ouY!#H&$;/NiI[V=:rhV/W&Zs7c.(VM7l?[:\,tK95Gr1g;WUWADC2%'a8V
-%GV%NS9K5DD(7+41_]r.aE$^eZIqNC?c%d"H_e;Y+Nr[R`:PpC?`B"go0EnYfi[J(BQPR&@2anXJ*oZYLX@&I<KAXMO:X;"oqD?"B
-%F;ktM)Ue]>j@mXcqF<.VEgo*g2,4*E*Eus=)-%CuYn1^rSu>85i>Wp+SlN#*Y4UHDLAo'^6-ucNfc"=ADCSnGWb0d?[M9,6otWHh
-%["!2).VmStA51>":C<0J%',p8h58emrgVf2H'siM]"L?qd7l2\#_7.YPaehe0;\o:;-@^WdghKgo3#O*?tR[k!6gB2aTEZZa1YuH
-%``J[(>=m[+^iIO"E0LDKC5`EG(_uP1.GEs%L=Z,nWt&#$a3T9YN&oc)"\m!!m<4-obI!Q6CmK.:NWkc2ZM/Pf^!59)Q@W$E^B>Ya
-%)]-&XBsFXK=TR;0B[$os(Sm0)])AeNaI_[*k6S_&=ntS]O41\2=f=#lI&!X4A=3Q9M3?tN%g($57$19S%<b%Z$LLhA.0=],T5@n@
-%$Looqhr.031.\D`;[J:=`7?4*=q%*3%I\ZR/>t%hi@d:+:$ld*#f*,?_CsCEP,:u@SPA_"S+q%*bcSYo/di:T^M@PH8SYcMFnYhp
-%S]$7Ng38?X,Rj$X'O@F`$OSpJ0&/>7K%8)`]\T\d[o/mO]^.oRB:G6'1O^Z?mm.5Tl!K4'h/Mlpa#0OSJEb)N6I;G]4Jl$Ndn6f!
-%J9V@p*+%G:?\_Z)-)A#Hr/?*Ch,>TDb97BpiVfp%8O*<./(CdeG%AL5+6qOQD(eL:+5$E^@E6>:j;^M/V;$cV&gX$iWfEDtOtMtj
-%XO0M'V"dX4G4@E.cNlTc0!7Y+,Nj%$1i.^s75%*B/HfFh7P+CfLR$_.$+K"X!XEN,ZI',r)ibbg&Q-5,J3pJI'$+oH;:,:0<=+U6
-%4;[o7/;^092[(D-]*,kUlc*#-n\*.T%Q>lM=4D5@I7!@ElY,2We6ML@fH8E()ZTm25/]kg&Nc:T1o[AtTdd"WV:gp<E"OuT?5SQ0
-%,^=<-^sc,`Ef##HZ[mA2=tBZ()Y+kBF[iL91,N`6/6-?%cH$'UoPRE0!oPM[g(+Su&3P")bKA(;).U\>`f7/9AMt<Mr[MEN'g4PW
-%,,-?@9LdIH5fTEc)+P&6+FruPS$jYDB55shjm&m>3>F:*=8F.KH8fRgn`rM;$L*T0XPD8sD\J/crLjpUG9[J0n.=Lf!V;.".83#]
-%Ba/r-:*.?`\3>AnZD?[lZ8*Q?!9>$YA)62jYV)%!kTL5t``J$G)<dD$`X"T?B(0*AgO^uZ73:.I%X8h6lAcbPBA1sr_soP"F`AM^
-%*6sj1ie`F-D9PX/Ki`H1n[>##Y3rAam;Ai2=\1^\,9cB<SF?NuBe%ku?*^PnKG#/=#>F)W&VJLa^M@DDh[u9'paf(k*JAbV!R7*&
-%ra>?;2l["a/MDZg@6&A4#^3^QKLEt8OChkMS&]0rQ<.l"9G1[A(R#I="KlA(O]$RP!qAQk;84[cgNiL\dGnr9\!]n)c*:/344Vb>
-%)5s\GU.GLA!3Hs+ZOK;BbL/[)Z_<W\].?GV#I"jcY[7.<Dpb,1,nE3gC`?`[_WWXg(aD-^:/<FAqB5)l/=m1;M4#([#9`%$B^9\)
-%`6Y7*Q$<^q<W_=bTFku*dc0'uL=b0H_%[30d11Etb=4-`Rs9mV>"uOdS!H8;0OHmB/VAn-Urepe9FteH1X"a_+%dSp*6ZWA+**]^
-%>5&nfC#^_or>&[&))2k\:BCHeQ'iG,65EQNMi3;+D7ig-ZY`>^ZM9j!FY[s]UmV7F<8#aL,QRHJp3aM*[,-mI_Q<kBe'gj+F.h7s
-%j27rf2D1c1W67O.]t6mgJ/c#=,s#0!Rf"eeTtlI(@hsDHF7j^1C##T?3K+naED,1-@LG[\]XB%g9^;I4Kn\?Kj)(Z$Kb9%h8Gl.K
-%<B3)&4$KbXN0nX:fO1K_A(=>6,Mj2XA6:abMBh>!UUQZ>m>Ak2l2pcc5qtroL+BV2H35LMU^5,9;!Gq.N/0%L5(hgE+[p3Bn5^2a
-%@!=OeNSAU<KlQ-'TXpu>2>dJ#@"JDt3@[FgFnnRYq3fP6<D1_.)kUtNqQ]RU-"cgN`IeOt+XS$R:R`a"TO;uV.s4)bF-"4*]O*"3
-%RnUeB4BdWRbA:@T#]Q4V)Z[(nX->=Ii.9O[L_m(&)h<Aa+0Kr2Q<_]&Y*XVPbVBhLQM!2:%UkkhJ8>cijH`N19lLY_m9&PAgP)Qo
-%OpT_8BZ&77NGhM40"!#-<.Nn/Q?,sRSf>f4i`3IaH<C'HoYJ6MoJYAp0l^34R_clE/SF1#$`/hO+-jdY5SG9L^4g4p>t39`2%6r%
-%cq.;q`.hij'S_UN\CGa?EJouZFELen%6cFtI4%bC0_nP-11bj1SLei2^,+i6_M^c9)KoYs-s[,rG"68o8kqCQW/9P0L:nJght+*t
-%@&ZOd&;*\LhumkPr%"+mO@Uo]iDaIl4:iG1]0fLB6K!!][K=(Y+%8<ol%jg/!?feuS&SO08q"4N&>HHe*dOk5%:49h70c+Y[56P#
-%fJF>8D,]l,o,[FUUL.t:_3U#mXSZAYW*-P'&j!]SINg?F@._o;Dc=*"Lqbhp.YDQ).-k'4A&>DKcZd`c@pUNH6h8'dbOM]u/]e6@
-%$\#NN?e7N'PQ.Gu!tlt^;F[i6p*7kpRoIPW]`.mp(Xj^79X);CV_hG"1IEk<8DkEf<S21]"!6CDe1572fQY\A3=;KiJprXBfZ=]5
-%BpWZ;&ZK%&Wu$Air)BbcmNnZ^<'rV<QB!'LF:NJgn&mUpS`c<(@)OmE`?!)uFj&QWK,b4r=(.TdScC^@>:@*%>4fudhe#[+"pG9:
-%[2/0Ba[.C]F7@ct`SAfC.okEp`@GT1+M:(f46Znm*<G^V*&5u^$1SbSnPkq9=:"/VWE+22Ln`M<G99k5D>AsDGgM5&(qnF1I<AWp
-%l"9#U-'@s>l.Z=heb7YN<92I4'f9E*[-*9MXt')G'9SW3'Wm([VE%c28ErVEW2Y<4"<)Ar5,T`!.(b]Pf>Y-`i>.et=]C`n-;.U@
-%lR"EcJUX##$&]__d<&^*BQB43Ih(s//H#)Zl)QA41`.%$@OFLpLNS7a13Urb;oQ)#.>4T')KBEZc"2g8Y99(pMS4`Z,%-rbeus't
-%5\qq-f!U*P5jBTBZQnP*m.Zidi(K,h3LohcSV$Hpi"',B[@8$%3R"sX8;]Xi*6WBCK5$g[Bh_VEK=iOK?.d2t8^4;kiiY%41E"r1
-%)(6B>[$eJ].,cFt^CpI31_@WN\AWe^;i<$oLmO7TF,u=\*177X[)0GW_\B/0%Nrn,eP,]2EP>$iOpI9d(0NYoYRX+Zb2Khp$j2R%
-%-CB4oGRi179h:l#AZ^ob%DNTo8KWb!]Md6B`fV^pN!&+%))DpUIu4.QK)[TdBdghZ"Js^F4=k+^4]j\+]9NoA7f#"Z8D;Rh:(RJ[
-%%[VH`@qUU+;Wj^;@$U!>r*`So2X6/n+K6J.M7a>/`@P:Z@UF*uNd7rC$!iJGS2QNOlfZ$,3AdZ'^5UQ@`]jO5fZ<9]*D*WY"=g[#
-%`]UqAK706:PCR4VT,Q1q@3t<8d(0<@+5;[1TPX0KA0ps0raij$i<K)HV.TnI;A)4M'V22hFjn)PWs+@30+BWB]2c*V+#DGSAPfF[
-%og=?BhDKE$n1_^qoB7e6,(CKtgZ7/;l:%=F0:/**>7++-;HDe'K&[1om4#k"))>Rs[TGR9Dr)8W_[3m<*D"$/;G+$*Z8uTl9NRMB
-%9*HoI.9);gR&Mg&nms,B]8o30rbf,[2L2Q)-pS$;U_Fo'I@4]B[P)BKka@#i(Hh=PFO=o)buRFaYnSuY3hM/)6[>(M#;m'5+]i[W
-%(28J+2iQfPic&i-^6Wa7Qk#TD.OKH`GIbtq*9<HKnm.B[$@dkT;[R[_Ha1)KbEc\Xf3mLubGYSq,VIg><kbY'b!9qBnCM0_M68^7
-%+V]!#Z4\nFItbB$3DYOK%qL]t>(&8>(:5H7o6$b0NfhDpe@fZI?,t9WVR;Pt)ET!03eU1khZ\-'Ca+uL_*lKUq9)=dVS+D(JSGO\
-%3J521_UuQ.5B_rg.[jd=E+s6ElI8Hk,&Z-<[n/T$.H:mj&eDbC_?3;BA6>i"8#bD)Z]'KYE!M,2qMpi2G5/A+IFk7FMl6erRnM``
-%$rO7@7^ErRIC*ok=AmdR,X^M%L7)/<7N4'l%eA:(T&%VXl#`8[NZ^)Q7N<#idS?*=iRb]1UM2&I4-$qUZ278%!R"@IKMOHY]+'&R
-%$m4nL.U0Hr,8l%_%6mP;;9%FEB'CTlI1>me5)P[SS=lR9\BoX<3Kau^8"-C[E?',DAL-iAr8h3VeZrX8&[s?W3)O<mEgGno9Prs&
-%,H=_h3',t<K"Z>57\bs/P)*I'=p!Y&$"-.]pgLR>$u's`ps#C?rV,([DZ^[hfn@*50b:Z^.)<AEY++Ka'E69GbVb(3W6SlodWE?n
-%'GSMLLgc4RUP(ng]$e2I%eCGdf%j/"%gQFO)[@p,q-ff8EotaThJ2>`<a8W+)@Il&/"YOOqDLhHl>#/Vq\!1&((b_$>a99"6-7!M
-%)3Me=kCu'[\ua+c&VQ0eU=M_W?ogkdMcCW>!-mI1<Ah$*2`KM.>EtZsVSb'%b<$g;l$A=2;5Js@!IFcKmsq,N`R[djLu9*M&O)ON
-%&kX7kXMmqhnS:RESI;u,A;C'pk(2bpL^F3=Y+M)t&oW=R\YhIfn,L$&"&AAc"bXI#JOC*7TE%Dc2*1usXi/pr/BDsK2+Y>oUVdm<
-%I2^s=0uVaD6/a8G*/HM("e1D<M8SLeAB@#75EA\YatVbHB``eMF2"m$n[!&r&XG:oU/mV'd?b@:REMMJ*3d<q/3YU71EG+ign5Si
-%1%kQm8qoLRG'"/,CjVY7T0\-/6;Y<-9X2A"QGWC93O;un_o2[r2ld`^L;D-n'JbB:M`G'/jKpcnPRE=>RCYikKED6cBA?1R3@Ddl
-%'%O/%Y[@ss5]u5QF1tfkj(GmcflbsO+G(,(,g&S\mAmW2!+r6rU#\VGW>P,$UfSWJ\g.4+PL9X+_&qN5+o&A1D,,Na*Y&c(i8.4+
-%1E:!KAZlP,;1Gle(f\Ag&_n+Y]BkhTdCHAOK4ATb]Mg.+;hD=1R,:^F^lBo+Y\10o_R"R-*!WMXC6Jdhb$AI0b!4T)D!siF&5-HA
-%D%W*>Mam6i>]JUG$Kd=CLsAr]('0+2/nsR'k9Eo\OY]8<E$8p*VIOc7'<hGNT#)8j!XM5DHVVOs$@b<"G/5ddV+PkR;^\J@b(k!'
-%G'>k.Y@14SB#;)cH$@VHMVSig]%`Inbc1`PiWLLVccR]&;^\K1Q$=Hloe@\ok\ZJ)bTJ%'a:+_S!H@_VN"at)rm?J;^95S.MIGt^
-%X#oj!:'/+T6V3L<oA;,O2BefqlHR4X-taq'Lg0`'-g2To0EDiP&r[%p+4DU^o$AS+9Z8l=rrSn\>+<`>2eB_.1qH"0+?t%R6^,Z0
-%MUF(r7d"Fij\_RCTu7="a!)cMS3hOVnF+8c!o<s'.LH_>U"ee^G-O2V$<[feDA5PfDA?([>Fkc@Nadt\o86SIF8%U/Q-RFG?9HQ-
-%dPsTGNL2NW,p`@fA#BB[,\DI#,$19@X4[=RaFM\Kd+6-mq-Qp-Q2400^!1%FDR9*?::$oL#=lYZ;Y\Yhmnls<:gW3iZD_qKP/qff
-%?'cqu)`_4]!psOs+<3(pV/QJYM\uX+#bo@9$m]%(Q%/ouil7?Q`kmqhm-I(5P[^WiU\S;nLhVi3KW(E0IeECp;1.#O,(G7pbdto`
-%rN!(QS%o7Q38:AU[Od#65o0ru&dTUK=b`G$FI`=pArqNDk+B.dmZVX[^n9#I71mF8F1^U3fcpT%J6SMe!EauOM"Dp&d9Nb"'F)4]
-%Ui\?l#<]pq9p#s)n7q$$juF]iSOm@TT+Y4U<5:-L,\9^\%V$)pLIcllpeO#-/4#A(Q4lM(:e4"FR.P$+p_phfIQ"!9'_$%2@9JSA
-%%'uq5mQrpe1b&I)7cGl<HIG%]AL=W+p#=VmV@Y.<T;Dc!MSM?tbQiYGF]FI1'mq?23W?5r:;RLb4KJ3e9irSAISAPO>W+R>:e+fH
-%lj.h\-6l3D%"&;2SOFn6U,&n8/qZ2K@)J^mfa)N@FG..O!3?1-"-1dMVk8RIPY@:/ak2@_,5u7L2S\7PF;jEPG0]4pfB4Hs\S\0:
-%dcPfc`Ffs3m%p8F%<XZRBZ.0k,:R8JcSpmaF;UaA4&`8@-PAJG!#KF^^d6>"e8lA+KF\LQN=)L&+O(A&U00sd;FjUlE6]>&&0!")
-%R/YHnfRf$!!VV+J/l)%h?aKGa+hq<IgM0"K>PloRS3$AM$eWFbH+*-;=&W2=*N[U=Fe:=R^m:E@f9EL"I&LHn$Ll;bV"bX+fc`da
-%2D\s7hs&i;eR,R4kWddu`$Z@F/Ib>Z1#K%bk@Ybi\Xg'-5O6J*bUA(Oe"WYc^nSPnAraG^2)*C38D,N`.lTW<'_1\i;lsq;%05;n
-%AG<5:'6Jn91\bI]I<Hk3)]mTFXj(@E?5=0pb"Hqs)IuSG*-J-#,]&A>.$Lp"TPCRVob3<]*1.o:+CX+"gld>%9k==0Y=&:)TJLcR
-%D)%'EnY.M-@ILMbQ=Umea5V$rGiU_sd?K,;;*9"5Z]LJ%q*nFL-pGKsW9NY@rN)LE$)d![J!eIudmFC`\i0VL)`lL0[c+C.3B^&b
-%f#;(LeM$:"AL-#`^;N;H^o]NoWb`pPVc`35Z<cVaAqu\5NUJ<B>PfOW?C#B8i^utK]j"&K#;3h\<@C/+"fJ@6A4$\_(Pc$LNb:ed
-%Go?H;X?eKhHp5tYR_sm6\u+b3[$p/<V3TQ3.P0L3A/_hsc2C-GPu2LR2hmP12HWgKR)a5pc=RcN9urrLq7#FT)@Yfmr>$1PZ`[:l
-%;FD>+ebM$2*&d?^7&:*<_Z'bXn8o/7X73HYg/*MJ3'a<[pZn"jQegTiKdfKoV82=U:N$V"fORusVZEXs9UOp&AM_s?=a<@ldjRi\
-%ZjUAZkD=&;W2;IrPc.?gK]2ugmc<0O6CqG6QE[-7+C2-U?rHJqs-2Om#5]k^Q.Z]@0fShkROFH3S,/5^H8SY)@,=+3j1Z?Wi]'0g
-%U;A4+h.2A)N#)!jKHEFJ</OWk13\(DX^V&sku+o.=(mW>3.c/+HB<4^9Q(Mo[/J)N@2i6p@0ipI'ja,%l#"+J7?&\\$ufi%EAeN[
-%l2:TO&bS"iHeDsq,`6Xr\2&l0RL2YATd\&r@o%r\DHZ'4GCQk>K9K%ukd&KCZ$ohL0Q(DH&Wn'$`afeD$pDF[Xe7Sf&@4pq[C?qt
-%5%C^KPAkt_nn-/g:M0.fR7J?,+nUm[_33eKkFs7W^Hf-S)+F$tRsJg1-U-osUl\hk]2R[??\a"E=FI\7rb%j>B&%[Wdb?fcS-ZW6
-%ST_k<@G(Y#8BuHmT<j:X`-(%]5NPp^<n@H()/:2#Httn'qO!W5"fU\!X/aGt2Dp1MmCAK<m*sNAAd#"j[`gt--VZNei[Rb,r%tq'
-%nJR7$]?#>Jf&b(bg8GuDQ:d#<YW/TFKT@sB_6STHdrJ5gUlt54iDhF[GlQ3g_Y>'u/_mnXRi7HG$leQJY-d"?A3[eJaW$FFpG#>@
-%?Jo$nTeqj&&I%2S(rYJ0qD8lt@=q\(<N!HODW!c'`*eHSF,:JDdgY4rGRm_QhSU-?XpZGAQa!m]iF@=I.uoX8`NR5]9.'q#lH03q
-%DN"<CfZ8fX2fgS0_TlthO&M(0B1Y>R-B@[d:0`Ta>*;'9CFuQQ\.=sXb9h0p_ASpq-*P,6Ypj?WFr4#V:/gh&XlJ^3:pVXA5M@65
-%e\jD8a@$W1,rJ\Pc.&jXq-t!@:!72qfV859:08;IB6HlKSGGdVB+sC#_(f4;nX$8D_rGCF:f/=3MN+-`!JP/P:VfYpQ%K7]O1V`s
-%qeQO."Ao4!=#;RXU.Va@$PEcd$E;&k&/RsKJ86IYZQkq*cM@6*J*9B2M39!,@$s;/R]T5LQ*GH&2Z>*aR`PCMY6tJ'BSeGCiPU%%
-%X8c:6+d(HL9Ms=]<i9T8's4nq.B"`K0L4idYO^j1HM5>tVT-W`K8l;&RO"E$E;EFV#CdP:'(!>oiT]AC-]8YBEkr$I:G`Z#A=^LA
-%<4:'XTgY9H\skf2@rsYT;GGI`4LB[U*O>*Q(R\![*!.^0"^3kYTLB8AKgVbnl#%::mo>K^"h1TB&^;=/]t3X$:q0c6!((S*j7mG3
-%X,I\KWKI?r7X%FQTEs%.K#+mOklDYI!XF/>%oKW1#>1`#+oI@"]1%_&:^Y(=2?4=ci4I[R8PA)UC37jrIl`tuAW,+f.r0p[;8U0Q
-%?2@4KJ]Y[+RWUDIB.<$5YhL`0s071'9L?CF;7=%"XDZLf3K!tf-gDW67jer"T>TMcB84-!6^UuID*e1\Q&11snd.%I'l)f?=.A63
-%KJ*?fkhruG&;`N@e:],9AI:/a81K>;.JDiYk"GAt]?usI%$GB%%69#+h.5jaFOBYtX.]-P2?YJAVXj.g];*lB>%\r.],CR^(ECf%
-%#B''#`&8(m`bB)AS,'>JBdX9o<&VYXZOPb>AK'H?'%"^#_#i\V19J\lpiIXP*Qp3-7$6P(JL$/_=Pob4B$H?MO$ngk@/I1<PL3M[
-%S[dF$0XG^W\&4@SB,k2bP(P#A5NX?"IX\@'m_Xoj"tKf*e-m?lm.t;'S#q1A%7#:M>b+MeJ$aDs!4T%GY_<^!?31;p-,D<c%!-XP
-%0)_&>rK&^tXTlg^o"[4+[#HEdF[D[6B\*@!PaHp30%m4C=1jp=Xm8M$8fg^]]mQ6[Ms0>AD[.7Rr$'C072C1eUkf9j^o_"uiMGPX
-%AE.2V7J%5YkJM=YPOm]N@`:uHQ47/borgPF,^5W0$NcG(ou-bg/<6+UI&C,(<=gHa6R_0fT7H9*67_T/_$j/ILa&cCK>Z]fh-\,Z
-%`s7o1O$="#[0-.l]T`^Rfr3uhmG3G8^Y?A!"Psiuc)@3X>$^b[_G@;.jnh^JTjoUJm82%$>Wu(0^r(221ZYZoL'^DhE)8=97/rur
-%AJDSZ/@L(k!@p@ghGrjGr_AYlfuLl2BdB_mb5>SK]L1;u#pP/q&Bc_%Hn==#99nDl.OJctBnpM/(1rO(%6U\Z:?F',DKMDC&e?.m
-%,Dcj5_HKL=gukRbaaKeRVNQRg.,[X(`tqa#E-`b+XRbQSZEm%Tb*`k(HDd4[*gV8Cj9?q,AC?7J`:K`PdMu-8SV%^h+(Hb=mZ0(c
-%`.@b(TN4F)JT>#?iFT8MghWD7>t`kg@e/J$b1L1M9,6HF^E:3Lk;Xo*pn$afa%T<3>HIUI!-4ZQ-!1PN-t=EtO*ju6Qc+;q>W'1?
-%:-Gr$j/E6M,J0eC1*flD)LlJ5<U!6LI`?K&=u1:d4m`))<=SDfU#O%CeWN>JVE>rj:D?iPpV`:Pl&VF-ZHp9E'u@?L&N(7.Fn^/3
-%Y]@.3TGi/F/IG(+-SQs,/(i<,$%pbXW)ed(OpA"A6"jbRFqb.]@Cqt++mD\%j6Iibh$4,c]DLrZfT?U8^ebQiR)6j[9O6]HNjb'^
-%Fhf/l.SPR2V4"*))#8$;)&!%#IF<D<qN%HbVF<'g)8,#<=)'t=VjNmDcbF\+@+1'7ZgP"Iq+\sW2@RHuYWGEZ5F4[q<0B5]!kA0B
-%gKTRi:'U5(FfN5-"!XTjg!&o/*KsXW`*,K2jo5=M;99U*3AL=Bal?,k$9o*Z;n))>-;qdm?&HDA%WcU],mBeM9O-*+],C6X5*up6
-%n;fUF4V)AV)N+/@%_5QOQD&>Pb`>!.7-*t.>t![FZAk-FY>tbs/8W!HV1Z+KMlr>d:7Y"]ZD173Fa8i=P.)]<+Vt5u$:9MJ=7[]Y
-%9@gdY%>SoVWc!ZL,XLr"niB19#"`K"5I0\#8d<PUeB\V\5!fTB!YZrR)&b&oa-QYJ]/AKCD/8Y)/,\EQ/CQ#:eT#=a:O1\/2bW>/
-%-UH0Br^I^_s0T(LeX\qT9',0Z,R`&Ng+^rmd!7s_:0aTX/b;qTP%8DL9t2[R3ab3IJF.Z8R+1O(>CZqM*4'/'k_,cWhV,5aaU\5a
-%<`+N-iJK..hNFTN[nh;TnOsnoH6FO:_2FL=\D-Z5PH9#$bgPg!D]hfJ_TA&]g!o_b+tij3qu@r;nSELGa#CU#3)f1_[Da)eW90h&
-%&,UC'7iU6r3)mHl/@!jdbd@g5M0VcWS]O#pRhC$I<%&<HAdV-Z'$gSQ>*XD'M`74\9$O(NSk5-hpT'>;MtjqK+*iE;\_s\Hh-7-K
-%Hd\;,kY`;:_?Ku1Yl<FE<GuTG+1jDOdTr^%?l2_H7Tn1p*$Ju1bs@=2<TTS'P7c\#j"N-A3Z?^k->=t*d7>EWe_mY#)F$hXqC<`s
-%!L+Q5(g)f-D:<:N;hjU-*r+j/Mtp)n5DJn/s1E*:kgh.P'KE0XgoZUhgj*_"&?*_MrmHk*9NWGFZ1/!.!-!VF,])0dmNi!Y-[?f)
-%IKOk-`3%$1-*c<*CJm:dA5d.g=U(if4GBdkdT3(=+!^!DM#iO\A-2OAHoJD0QoAZT\<=qr81d0^#e:*YeF8]=(Blnl,)%-u=IYcF
-%r`aaRi?]sVs6/'I<'ZRB60/),;7Zm%<'$-*Qtipt_0Z7WR\WcI%?l>$U>udX"rf)&R(uf@G=o>Z5n!k88Q()s$1o5"bre4+PM&6U
-%L0D?X%I5IfZG;SaK:G2L?H</O0%\E!pas3VQ@()"LX%I/:R&/a_NP.m%4I+\dYUH9RZ;C?*J\,.V`;U#RX??D.l!79MPR%a)em?<
-%%,eieTM:]69\XrSnRe9jSr/8#!9rh(7K([%:Goo%%E!jK[E>Q[Z^lmS0I=Gb#4h-c#h1YLh'.no3\-F,;!HaJ%&6m%PN]eF9TiqK
-%ncu+S.Y\U]@gELa--n'f.=HB_=2lA/oQgtc,L8Y^QMD>V0uP9k^$L[T>6?(M5($,0V`W'RT57&8`*"PnY#;-TYFs>E,pV0!Z!=5q
-%G)JJfmBKUdL42E_(V]qaT%F]eA/Z@[ZJ7HN6#[f`a,@FD[\71KK7IfX;PC+FbPX*7Rq[>u&1\)+)'RNCL10oiINoJs2@L0"&.&M*
-%e-?NeIrnYG;O1Zu.^4pe$mV0LV(Q_[n^su?3QXmO3nf0_!(n5q[9k+@JbU#kR;-cLiOBGj;Q)7$qf8#Z$Lf(Q2*f<;C\9F)Rq[<e
-%$?HG2-l2-VCrRNtlOXJ@lYn1I2]G5I2bOah1S#-tr!K02e1L^jNb(_H+kL*X_p-#E4@omC4#Q?rO.ufT's]I5aZr)-ViSdk#b1"b
-%7:g"6LOi),".Y'IY,r$*nJp]94?naT'iiIL!aO%1iPc0p(Y([8l)<lR/M?<eLe*h(eX,1==5\\+*9O6e,2ONaJ:nN/PS!3Lmc]2Q
-%TD!DV+N@fb.b;C<F9E?DO`%!B0RG#b3?^]q@i-m1;Q]G<OMlSXo4FSd28AER#c0HUhmY&t&U:Cp;T@WaNt[uM=dG.qHm;o*jkYms
-%=AB-!]7I6V$E8Y5*35AuoFdU\PV8ZonHhoL/>XO[F=men?0JXUfShQWXsF.9FboY]CQ(4,r$^i1,s?q@."XCIL;?(0oA$(;:;)VO
-%mX9"3Xn\W*f(i'AXhs4/Hr6Gb#AmjLjdL`AN_Y</p+p3F/;C"GCmnUGT?i2aJ?]Y'?ka;BJ#GH.*5_bh-'+oITCFqcb<#ZthdmWA
-%"7^0gN+m-cG!QUKZD#!1Rtn&PqTM%YES&W'\!:+&AT4\t?P:@\MigMK&Mh:7A`R#h`!2Vmlir.585aSG$K7?n+Wr\>,S]9hI1WEd
-%:b[9Uo4FVeQ+Eu6UFgS"#Ue#L?TJp<*sIco$(Sd>E#6$*oR*S#DQnPfB*muVl2WYH2)pG7]hlf\Z#).,W"_"?=+t0'@KWF:lSK4>
-%P&OO2Zl>VT8jgQO.##2W#`sJmh1p83cd.2J;^iZ=_V5q^GciUd+C3L+1p%/Ae.?R;XBbSYJ+kR,RVrOgp4j/4kSmJC0K/1XfW,Xp
-%k;u,r@%1-=YRh`^c,cmo>)FT[P\mEmaP*HC>4-')_?NC`&Jdi>lT*+sR42rUf(F!h3A&Z(+0pPLJou<eD"10Vr1K\AJ%'R!\q<g"
-%kp]hlBo:UZ<-](uJ%UGuoc5m9ll"C5OW;IVMIY223pMfO(,oGtckNMcs%bI=OsDeAr]!52?fV(YF:jhL[kpH:$b;D0Pj>oA(o?BL
-%csm$61=4)J@>gcH<-<b<PWG85:2oE&+e;krEaGQ<<AcF"rX<d8;RF<Z&S<'B'Wt(Ka2i.?W>@9bj_&fo`&L$-$L\Xn7&kf%`d%rq
-%ISA^"B2VPI0T<Y6-:B;Qg+=L%kRjhF<fB6eoM3\>ltXKFM0]$A&gHra.;Ei\#!5;5?2B<>1dJP69["Z!h>WPh22_EA<ViXnQ_`g;
-%(]6e(dPnsQg&"n6!%HeF*nYHbCC_F'qKT\1PeEF_.).M8.lZAE@E2RVmAG=DSEn%BkjWCrS&oXp[fpi,Sc$,'jj\$"HA`<frnXmF
-%C3-bj+,#i7mP'=uf16UkW^K3n*j[&YPo$<dm+uIpYGQ6`.qX?O"I.Hi5$*GJ_=]qopEusd8h-D<rb\au.S#i)IH7YGO-sAc'C[Z*
-%e>c)VWk6E8]jf(=e>_lXTMNf4Wq&b[icM4Gi*k9mFSqN(Wm5CRjqFF5dc2l='k&#c,_3-FFt\aS&$O`+82ddI[Oe-L.ATb'CWZ/h
-%d885-G_f[a<>si;,f-VI$77>)DNZQqaQ]-M>+$*VDa9Gh%re,jkZD^pM_V@ij)4eVlIJI'"f*d&@E*[kiOoLWJ=.AI[>`@-o"(lp
-%i8T]uXX0F*l?3M>nq]i.B"^pZO*NJJKq+Fn.5RiRi&=>";K7Nu/Fp5_gH[ZG9)LP:K,PMp"_*n6"B]W3EM'&Lh,dKOf"m)MRLCf2
-%>P9XH:L=#U&#0qm^(B9L6P4oJZf/cQ^iIj$<tNT5);u\)J<[?<_2P],=q]X:+j5B31`O=$ZE^oC^B3EseJt`2>g9?*Run?2+=dfR
-%&^_0,*6o.?beplu3Vi.>\8$#JE-=5b9mJWB8pQ?*Tna8aoE`HqE%ah;(/8:k0OR8h,%,GWp55$A7G%`="uWQ'<_oSrL]Qm7\O=fp
-%iD$#h'A+.D01ljC:rS0s7OT?!0Uf<4m&Fs]N5*SWMjPJ"c!-H8pJd5KJ/g"Cfp1uC3>FcT$AOR1='k+7i24;PMgscqgd:WqNHt]7
-%r0[MbL2/P>br[6s@Tf";n`j)3=VB?eW+nj)JNLX\6F:Gc)B\K-Xqp;_0!7abiQMqZ"(e!gDQT_<X9oE@$OL['e(9ANW*Dk@O-r:f
-%R2cSciPI,O33a'!mlJ,`OQSi&OMPH8DrT<o"A/0CCkMTtnHD=4eYn/G'2GiIcaC*MVs]Ge8!oHQDU![boemol4m>LpiP@40>MPE.
-%L"0d<K<!oE:2o!:E1=(i@C'O*LM@/Y9!),(90%h[jUkNQVG=Ve[0"7n#uAu@/gSQ3qZPO]*$(i5!5;h++K`1"JY(p#eB#?G(*UZb
-%loNJ5q(!r>poGW/A#!O,9_=tR%Nu/:aQrJp[I=3<.blS^qm`HdGnO0'"nB@XpnD@Bn7gJ.>l9uN`2t^>T,+L^I#FtF$9@Zlm0[6/
-%#o^AhQLc/qps(S<H5!C"24eDh_B)Cui_#$./Y-5oSrutY`VR'ZH*U/M$K6iQ@]2=%lfOou!m)LNYt2B$lnR>Tr4ZUKoqqnA:u'l'
-%XnLf.?sb$KMH*l5<@U7tJ0cG<HKPH]kdGF<D5B:=dRL4)AQ66KGI-.<j2[rFZ-e8L%=<[h*NUbflDO-5A_EV7Ao8)"XNbm&cNa8"
-%RO&K#J(0`ggtkg@5>uEj%,SbO@9#gXZD(!@#VUnVaWSKo-\ET0.6D^`HT8-k)\#nE0rq]0UC/s#cE-"lCpi]eT<Wh6-OHt'H;I?N
-%nYXiG7RBo<QjRHCE@c7cSmF<J(q]hA2!Sp5ISA]EJcHT!&ZRk3A8'^4nWsH7"GQZaS8ta%N=qei!IAQgQ,l=%=]&$E>uj4W7??7*
-%?M6kGJ/'5PT/c-cCp_0,j9[9O#m2iH$`+m,NQh:($_e^;%o\K`86_\mfP]K4^2].>s&7gS^mlY->68nIqaFI#jA)^I`Un/$ck2rB
-%F;f=FPRAb^ib@-$Pl-b+`a+:X#fL&S5*>nKc$VK1S!rtUjT&oQSYr.JSe!,bQXn?\#W#Z=3o>fP6(/b<A)Ro7#j)A:h[[($+I+$:
-%$h.g']!XLl<AW$T9@UE`I&qM,p.dCUBYnE[V[5F<5p]]oYjlOka:DL&/@d@'Nc%.S'\<=@HV:FPL<M?o">WZ41K@SA6kQ%\]qpU8
-%bZ!![P;`sRmD#4Mi3FmpJ>fYJ(^Q=A%bF,9`j*a/FU0Y1e;7/[C=*I*K+V2h?A`bd*R+6Zj1rqqkBJ`K9,@V5Z6AKja)P:^$:+5r
-%m]sSq=r@aS7n93)TAoZC11=t3U;fjl:K==le9=lV1FkAiR)2da*"`"dl,.MDbHC@o$TKqsRG8nFKmDDG2CC`O`pjPKPu(JA*[r:P
-%1Ui1qaC>#VL<i7=-L(;s*YMOSRMf%#_8Yb"UWKcN^l++$-r/9$"V0l)SE7_CXdJr/B=Zq%L*m_g8]lHT(A&@#9LDD,-Y;\5G&LB;
-%5Afm?(u1NoF:5KhUacC8Q/en1JZ7?K#Vm'SQCRcod=<oI/<dmFVZWN5E^%`oRuX,WW%Q5*[G6!bLgJ,<$lr1"=O"r$*_p"FU-R1,
-%K,!%L.Q(.b.biga@sF\@Fi2j,N(pN$MXaQ6dOo3!EBc!87I&Ei6:f,:5iB%Y]hGq@otF3*`6Fj=HmJ]51+#YjP9iC+:Blj_Ql,d;
-%[>;SZZ"%8$V<_]"`*15,B2(-#.<)9p;-]&b^74e4mN6WR45hFros`c.+mb@GS6>i=M\aHOf:cQ!q>kPRk$F,2*;DukSM*'86`g*T
-%NIATOo)%28X>>leqnS+O]#B:u*d).@<VR"_%C%1JcoJ2$n.a3HPsTs\ah]*O-e%hO-1Rl\$qMFm*,qRNqje;#/5nXjEb+kg/khAA
-%:,NP`D21B$1\:/km(_-jkar?Bgj\+.`)NsL"]LP+_1>o&NF##+-H0^``'"]"M$r0Qe-0RabS!bRUNbk`'1K`(]F&Y,([40RO*26l
-%YZUQg9Al@d#cYd:6,1eodH\Al4(XsQr[[ig8SR#oTW9Y+H6/;;)$Vq\lVrIkbtQo/lED6UruafXMoPn"=0J>jiPV\)7+K&nc$e+_
-%8@BS)#uqaG<#DWGA6/bcPio\_VnYN7ZuK1[L(oUA^_A[>%kM9l<nqnN%P@i@'7"o+_4$`oKMXKt:%"#GdR9$.P#ok>+j7Wb:u:EY
-%3?-YrnNmU?m6Bf!Jq_pAKtnpq>CWYB#a9oA&-<sW:UH$O7kl).IctNJ6YJ0YJG?noe+QE!4>l+$,RnQ\!hg%KC0RA],`i`H:[OHg
-%_nP$P^iD"ia7D3g%qZ[@\%6T/[KDG_JFd?pQ6BH9c!9g;W-U_0ZkJ.L#/$lJ*_Qgm"RqeG=[EfjPKYG\""Bic=&,0,FegR(\'baV
-%%?5O=Ub+Y^C"BELmdrXSG[_Nf)UI/S3nfUNj;VRCV]?0i)()k!MWqog&,EhR9F2+@"AhY^=h9m?EbJW"fU=uq[d"TKSjM'D2)H_r
-%fT/R!!#-aK)\`439V&VE6U9<j$_RgV35q<A?%IB`k>_`@,eL"m,>W"m&Ch.'?_gnl1<!(hc]VmKnpOK63h8JK@C\H#^b1?L(W:9K
-%f/D7,*(8&o"DeJ9MQSueTZrL\,N8\!hT#ao^W?UH-heC)Wg$N!6*PWdI?!B+k'64Y8)5%_Fm2_93WPfs$(dWPWaN!&.KMI0N7.<k
-%,[kdSgfd#cW_-;E@bJ2-)t4*#d*]5>g`n4KL`Bf?WV[snLM6aX!Pr,]2?US2W([ULCiRaBCWS`Zo."1L.t@VP)G2;*%?)i+cZFpF
-%2J0LU5)6\)?1?hNO*\l9`.1fT[H=WNfid[+$(,,rR"/!H':)>pN=u5A.+2T,2!_sZ76FDb%ZjAE.9.S=-PjRI1iK^r"ssQ`9Ytsf
-%3/'1D9KRrtV/j*`<`k%qm:,%q7XgCJfF95mi7Cb3fOf[;0p_nP6_W8AW+-EP#DfpPXeQJqDR'io)p&FS_W:o)=CSX!/+OP&g[$0e
-%En$lXTn<@*<)F/+Y;!c0QK6b`34e=06KB@@(%<:6Do3i`'H..C;&7LLdNO381GJN#5Q^[W-fYBnFh1>>%X"2!YU$=r,7r,OXYT>J
-%$t,&#PJ2hD2CiH$9*"ujp^5ULV>N9!Qg%J0Ak>IMVjJj(7W@c#[.Mj5aDQ1E]"-V91b4VW4OJ:uc7X'EOf068#/6Hq/=5*O&N61Z
-%fcUZq\#<mhZ$I(F4N?qI$THUS1!Euu^.\^/\GZsl%qQ(Q\r40g)L5l%S$nLg<\P.]ADG_fk;1)#i\<L[l2ELW,KS.I^oA7VWrb%&
-%M>sf]lBmB(7,K%sGa&jDkam#%*@3BG_T0]9hPS&bn?NVLDYB@(Jd[,)(E'.'I5JNm(8U\Z.R6r$^gHZ8Uh\?]F5I=5VB)!pa)RDY
-%;sHan_NU]bV`$=j_T6VHJ"VF@/AM;.!Xqs,CSf=gaNLgYJ`2(ej__;;.ZZEDW1!Y93Ou[/R*Kp!gi2SV\P#+.9/??)>?HM@7F9%O
-%UETD+EVL&#7^JP#$](>$i\XfDB@BUjidHDC@M>-&kRV;2G1M_3gqB\JK,\(IP<$GRDQ5&!.Y&6_gr!0D9Do_)gP!pMqAT[YZ9PU9
-%G7W.eFB-g\f."-3L81-W#^*/nQ!(Z#Wi9F:\QnG<66YA7$!l]564mms&P4;U4-C)ZE7lL^m'^&Z/cW&%<&mRfmnSW\?+?\<"!:`@
-%Ve@jt"X4o?I2\J*m4nCFBq(f((X<\e+FcI\5Zb6qFM!o<#*?B3jCY3"+dp(biQ@$GFY@T&a93(@D/s*4[BeHJU**0Fdb><^1[WsF
-%'m@VlUtKe[_t`DJs'o+.s2q;.4crTe<V!5%H:0$Y71Ee\/j`FH7oj3H4@7BV8->-:KMD/OSpsPMAC8?4'+;jp#V5tJ($Pm5P_T"t
-%d=asG0#ZMAo&Djai)?["[KjF5*q$TOrc1!;lbJ>ojOC#c;PM8K)nsO+HP4A272Le/5;9reDHiqYQEhel4aj([eQ\7,InZQgoM$s"
-%cN(P0:#oPkj/.%;V8iuS4pD=RMsG?Ai5[,=>qd9F=M?B_2W)qY<#30_bE?P`b4>PKcpo<;O^8<XVpdG%^sU5L<';r6O8G$jG6rX>
-%;1t1EEg^`%a2+osQLGo`LjnGIOQF&HWOXH2Z,ANu4c5SoQEH=7N9S$&0=0I@E>(?9Md=@HU9SOp!\P#m0Mi%-\'Onu,$>KGVJ7F7
-%WT/ciF@Pj^c\_jT,&%qqLrc]l00SR#o6=&'3SJhSc2jtnT030hqp3uKR)NPdDj)_XJ4Iu2D3K?AKi-NhLVF*C#I8$6d^r,T;D?qG
-%/1_Oe_qdsU1#lLKaCH.#\1VGs\&^_8@ISY`:<ALc\O;UpRa3R).A7I's%]hg]5YBY%.kC\gB<G@le*KCZ2qcCd"Ldh9TnI;7Vs5`
-%\4'qHV-eqo*6=tV'4?a!SV1XOqbZj1$>3i:JTA;Z*;*EJW<oIYOCtSZ%?Lm@9Z_Qh;o`Eh].3)u]fSXj^..ZCZdNr[;C<T$"h<q\
-%3.J8-mFem(`(4$!K1BfA>P/U8Hh>d)SN><3L#J&UE@IoDmhlsDf%Q?Z#EAt-ET1%3\SCb0lo3le;tu$>:c/o8&lA<WR(%p;VZ'Z`
-%mZ8@lMcs-3Pa$bk.ia6.-DG-7&NT9?5cg*e7E)PY1fY9=BQkc?O:dn2m(YCbB0rC,--H+Ihoua/!s,s6j=/HG6H(Dk&/[FT#Q>R`
-%X/&@O%u7L)\Tr4o5R5h?PO+LPJXHO,QsHqd:h7`%/acd0e5C0:pm.FmXo/m@C-Ehr@>&+d$$[s*:El/Cr/T91<jnD/9B9AP5,hPU
-%p`@T4PY)T)%nY/flafOeEC$+\9DMF=E*$W?%"'LtXI\.TPbi194[I.;d$7(]3oMOhU6FGJ%:qS[*90L[/Esclf`J\;ZMP+D-7E"?
-%VGjoC+Gn't[dTp&9rCs%V6c5*=b(<_fpM@WPQA9V!)VGXS<.1::0qM<?pUoVRLJc3@1i&9M]/U%)M?QO2[^R;jUlKE@S%qqG9.E.
-%@=08R*#;7V.V`qW%tOBq6[>.oWTn!<k"kq[LEd;hlkK0C'P+D$V;MP+k6RcjBR\;9430(nPUc##+0_.KXU+kQ$P;2&(^s#e=lS()
-%c,pbL.ZE*^W(,>t"";G,`3DbQF;.7G3I-SFAM0h-Z,gN$P6&V(]7S=hJHPT=&D!8F[RibTV)4m5[PFh\0G!m^U],0s;.fVnit%rS
-%oKHe6nr(U%crWC0Wr#oYQ_$bp6JZI\fj+%("*pA(WCfG7Q>]'&Vq@F823TcTg<u=VeDqkRUp2iE)B-.:Q55@IgP[MqWp5Elj1@4M
-%*&RqWP+n)^eONk*'n6b/l$h7R\YUFR5]=kMUtth9mub9-TbMRBc`<D_h1cX'@6Dk')7oCK*f!"R<4Um`11=Z"5s!)1RXS_F2HUK@
-%`M#a)Y*WX1e<aHh9T]jAYM'+b%H9-oAD9:tJg,gk<26K(.d?E,]Zl9I?Z]PN14XW.\+hPW$\`1OE!d#-@_cmU'NoHRS5&)GRQ50c
-%l(BS,\T&`-jm#.m!\AIpM7o:],jDq;>Sc8^V?g'GNaY'Y!TN]MB_40H\+u$C@c^K\MCcQ/22DkfJ*Mi^H6>c5WN8W>\*15#ls#(Y
-%:l:0]/g-f8$<mgT%Zn7*K7%uW)\pm8)IR9Ug&OK1V$nJLPg:?Z<jHOqcmcuYa&r=()<'^R*,gDM.4.VZ;?D!AA5^OFWG/]K@G,W0
-%I:Eh`2$PH7hMN7_9q,8?DPDLcER-mXZmA1H;7\/)E'PQf4A\iq\t&@@*L(psiC0dA23;V7g@rL9cm29N`3%)pC6s\$hC>3R'$AA[
-%k#?JK+Ya.M-H"q4!X8@]0uPc1i@cj\,5WQAF:nBR).UJ$NVG62Ui'EuJ&qVF,1>J3s.kRJ)krhNV<.fS5JTa8.=k90K1(8mEj)2O
-%]d./[3e..*+\FYkU.nJh80PE<S/6Pd#ZQ#_W7ng]389gh^&lVWA1!UW3\>E0OXL+PcSbTfTC0??p1CVC$^@oQ6Ks/_nY%PFS7L&A
-%jPSp6i,(Zm(]TGoa`aD6Vl\sZG#fB*3iNG1@U(2-o_iPs`T&Vr/nn-);8]^;Q3,PcMA.1DLM[*L\%os^9=J$l!0;YDAp78"SdQmr
-%)/=oA2m7C]Sg2.2L,EXh=IP9Uo4k.3*!04nUG-DL6L)am?krKY92ohZC5s^"!Z>H4,5]gd/[o2A@g,UWKLCE4Ijg'W<C2j?RYMU8
-%+.t0Igd]Hsi'BjfFN]f6AtDD!(monh.`&[VI6m>?2uCbgP,W&g;OK^-V<OQu$Ib9X6;$e_*^NN0pf8u5'Kpk:@]1'Y5t=r)+/hG3
-%6J6YYC,+Pd"kDBH50oO(B2%X]mhR5E5?700#4YBYgs^X/9[hYu_$(QMU&mI/6$Fduk_*@'AM_Vp80'1^TS[@qQ"LnTF(-k2mGla(
-%lG`C<eY$45OVQ!82`3E6!ahsS,WD(Q-5#lZ4gH;:M(:@.cU_DPGsNn7G-h;N'<ls9\g>I'dmc`5OY:t_A9NegmU$[kCm6//VqUZu
-%YTcf0MT7j"oH.!JZ[4G;_bi_EoHC4WZMSM;J5p9IdTM5*fXU%<iij+@pkS!BU#]9U7lQoVOF5.9$;]]k?f'_BbcXE4SFKj'`^qpD
-%4?it7*:"(Xp2/dMli]?[n1+7*bacWp<-Uu7`/fJbMi'C^CUo&&Ep(!#ETm=lGZDP`WO[[7m"84n2cJ#f[*WhrAOrS-nR?2DpW(A=
-%8>-=<7o37h)$&a2#+]'I!P`GG:suhlZUlro0er_m45spa&&H;<"c/'`,EQ"[qP%]=:bs]FQS2)E+-ZUX+(q=&MV$$&*.R9V+W:n>
-%q,5S"!.A((N]^@P6DncOJ*GSS5fC&uFhqO"B!9ZU:#O9&(J?Qm)-'De<KrJEh:<*eImR_k>PeGd^2^;W,uZ37K2ZncL:<PUJ^CdQ
-%V'0PZkNN#07m&QO[96cGTMDh@-R@H/l^1n!jm#_k<%_$R""OWrYs5['eO_2g(dQ%l<V<BJ/K5HQ?,b`mc;AXq^s)ul%>P22a-^bS
-%OBgl!$M]OuD<^g=SQ21]U9O)q;.`<T*_Sr8I@Qe.V7a8lpd53;I#4aP@Kn;Li2Q">J<]1&Q`?3[8?\Zg'&FAPY\<^J`K'i&)=&G"
-%4WGiX?Z+\4]*MXPH;r[,CE<1%alXOrloJU`TJ0_A72)2iBF^]hY5&meP-]F2P@K;PYJ\YC:Q;?Db$*B[0TLD`&#5Vgp(E7Lca\su
-%mT;?Kn9q25N,uJ?^7H$D"=Gf;<B&03O!\50ALD0ui(/Cn+bYKZ:F)I1UjJM_b`GU%[68SW_F$2!([@=KARsST_BGSjn5<(:5a`7i
-%bdbbh_\$?\AZ=TR`!f8R7:hA>?t,P@3MkI#&0c^Mb>O05!&jbgDKJ%WcaX2+-A^Oc'PN_]6bJ1VO%-9>T%_X-pKa:IcqKM%5e@I9
-%Itih>5Wfmo$pPj*9f_W7PRJ?_^mU!dJWR]n91cuqpRA-/BKY<Vg:&;T^mHa32_eP+^Qm(b@[CLDO2#S+$S&e^\3USVFgn9r_O0O"
-%!d>:"p_]h2TEIBL,l)?g*ask6\[0.^1N+%H8aCs:Z"o!7$Mfgh'`M(h*JboP];cDbUF:4N`<7PJ0NMd!,Vlm!o0)MG*+Rf$E&?Ql
-%M3P8c#sJQ<Mr\=d7l)[H&2uD@QC.1sSFS]<0FQpZ/P87aZ@Db,T3.^sEMhp.,]@*.l9gO1(ncB2br7<`oYNE\FJ*!#?j2?BlJ;W5
-%S1#(D>!'=N7[?#*$)\cr1h[,8(5AV8&\q-DJr0!@"CJAh&E8q)UbN,d)Of[B!09UE#@;+Y1Qu!YC+R7+#_Z.'*?rC;^Qb!,dlK&,
-%]Xktep^SL:_+3-^mI;up4%rSqRsGY99tp\+**I"1jn1EE7d12+_Gioq7B$g)MpO1N(8"$rCTn-gqBf7&`E5_;2'pteT!u?k.;Z,%
-%<TURkjsqV6<2G'R_FJi\^FY(@,J-OETm=9d5pd'NCDG\c-!Q95A`Xj:.qVP&LKFg]]6QCJ&jo90+<.1`8$";(.R>5=D2-tdQmQ^<
-%St@BBe\5hiMFhOpc_*&J>jQ%/T#H+.SQ.-S[rcSp96HZ&p72B(Eq_?J0#Gb;;ELSh&ncR4FR"M<]Wm8t*J#s.:sH3b)N;26#6eIt
-%Do*f,Q.W-545]c\92?&js7S,+RRB8u\86(\qa6qli3Ma54*7]:a)0V_SW^$1nLgi`/N7WYW:5&@EVFp:aZ^t/==5a7i7p[9+&X#6
-%7E-n'><\9?f8=pE#pLo:$7'9MEpP-%`13,MMYPg>8IhqR2FaJl'>^@6(-\XSCk7'CpG,Zd'FD`X>m8GLTLdlBa0_'a_4HOI5/3.2
-%H9$8,KMn!9Q3jK\Ejk'"+a*&Y_k)_lZB7`r+%;s(i@S&6mUUS>Vi>:WnM=8B_9cQnA0$/kP"n!,d.Ts;oPlc!G;D@.jJ%qdc?FD:
-%X%=Q?;_agd=N*qQG6\h=;>+3e.\`W99_DjBh/KHhA;sOr"iFa?D-/AiP1%csSMq3+UWGXJjPn)\Z&]TK$.,3_i]W3gV#g@@6OW[-
-%s%pjnWE:2DJ!*BEKJeihAUpD#nF*J5Pm0W@jW:-``,dJ6iaD1<)XnRU3=)Zf]g1-Ki9iHi-aTi1IP%spBS]%6\Rg4mX::nsG*[7!
-%07u9[A>plS=1]C>SB4M],WHsHnU?K+mZ'u'6@OKTNM3A%L7?t0ARKg4eqhdu-mE4BbAM/6s7ti]pG.Zs:g%/Fh^T'O'n$p*9BM5u
-%r:<hA%ej&I=UsR9pCVc2AJQ<k'qm"mlL2K8J"mGhTbYDq@m)(gFXh&b*R1#RqVd!pprD-]:3e]Y,ITQaZ5OlkR^,H:7hH:s'9'gS
-%*8'EWpL^ad@(!(PV<Um,b1WHD/kn(%%3i=+e#*(=n\uKqC%rRDOgl[.:0%3HqoZJXMq/$kcr8VoJe]be<=5\/'\@^KGAeoX29htT
-%j-VZIMeOC*SP9p%5oE*:=&sm1:E_nB,((SM67/Otk\gLKqdjesNt=_co]f@CE(&(\-4qMr'MHRg"%%#"R9udZ>p5]YUK-K_P$A-s
-%1aA6P!in6B$=1"',4fHB9GU806J4sj$G))QT;W/3`)\KY056'H6>/9Ri]mf;s7q",f4j@>f*!+:F/'@/dj`/X-j!L<q>eDYK^4Ku
-%Zbn)tW&'pAg=e6kZ'njRUBm-SLo6"+a)<S2iP\/oXXPSAnFOG&kslM/_\F1&fc?/GWd7O3.YOV./u_$<\f]LkY0u:19"S'!Ed:B4
-%TI19(Gr.pG2LO0AA6`*N"q([a>/k<]H$Ze85I@T)"0/B&b.Zi<.'`h3/Sh8I^VID9J@m#dD\)bCZgaA1]JKN%9U[[8c+pa-HQA/K
-%;;Q,20q?`(lnER#Pf"WjSg\5o.Y5?I#$?i%UFJ^\P+LrfAEDL'`)JtpI`gs2JoAh#<08@r[muS$kp\fE0Yu^/7&O3@Aq.2"([M$Y
-%E=oXjXu;J"B''%ipMRU+,[#<C(Xt\!MguZH.bO]o2_)cOO\&AWCQakm#bb*8$)=(3:rA\Fo_45cg#a>q:1g%<64X./;&OO>4P\2i
-%R;L]*mBr0tR?E-=MLr/O>kQ1Q=L3'?+ioL;m$@ul(f:a',SlT>dQ9::+r&h#M+Jkfq%N^WISb(S]n:gi@"fnc:j7qs'3>)p,1j1A
-%gA1TT'ch@)G+Pt\Hd9]LdeSm?L@nU1>Nmkjo'qNt#9<:aSbaqY#$?.%otU;P@\-[F6p:CKm!T+^(5A6Zg'enP*Ru97fTBE(\0arG
-%M6$ht%]F?9*"ofM&Q-AR9q'^HY't2i<,71F-RKDk'MKP=n%1?tpS)F@'h@U1&M=J&*e8>LjGTV`aI^!6g6fJ^<&)J7=+H'eEuuPp
-%E4CI+RoAuQ3VrqAXf`WAd.T'B`*bQch^8!2F&@P9'.pX?67p1m\fX*`NGBi*6."j]J^1j'/a-3^kKSmHAb*`N`K44^kFQ.>G^4J=
-%QHRW=]8`)[BI&NAgbYT35XSClk,FEEUKdFPTZMssV:X/7L`HRT[=)'ukiU9&gXtLp9J%(:i&>Cc_gK<YH0`1(444;&f6?:2%q6_#
-%XBo+P9'a<662+@sYc:mFIkWGYWL3T7,,_HW5;9MaN4Bm#a(@]=`mi%V.=mK;-D2?73#Le:<mD\7].&`aCe#d#._"2sV76d.`Yde[
-%XGC1K5,TpgI^)5AEI+bD4M&%@NVg`YU$kZjgt-`B/.7M?'=f8O!bMNi2)]3+C3cP]L2Ip#B*/XJaq&K.o2gHU?rU`DDhD4@QG%LI
-%[UAPh1o+oa%>XRolDC$j5PM6+%$9#jOs.X2QFp*gb\qFdo>I5i7Mca:.Q'a\B4QdMBAg=O>XKoY-(?4;,@Z92ri'n<EMkc9GK1NE
-%W(ZS9"@Opqkl6g7m]e\:WJH[KgJhdCp'h665g)sgC"7kNUXq`2/"%i^5KrsKXG<=fAug7L_T-e%qQ\D8Yp_#%IrMT8nS'HslXOHZ
-%J+[pj7KSVSB+J5aj3XHLRsb\B8ftNHBV"$W`!YjP>[jU9Z">1X5fF:=#mM4G#X&`h/2L^QTe[g(`[#F>,gLRX&=frR]j=-!_aJ;W
-%*G]2e8I_/l1k/J"=B.1uQ.81R@Q?kR40FL[J0$lKeX>PY"<ccjYVMEagIfNaNh`=JG7b:*2mqDfVItAm3H9F)X-$C08?!]^7AilF
-%ArHGhcRoQ;k,DQ`hQ$iP=R[$>(r/:maS[k0"jKG.rWMj)T;%^k;T(KDfTKHGi]rBB3=)%1]#?3sHjt/jFVnf>3Xi7W'U+W-_\%#2
-%n;`5R_)4[2+@re:CTI@W:,j[EeT8:O95=(UV)L;adu<8P\o./!qf!AY0S&i?`FR;C&j:@o+T9O8c'UF5aQ@5HWt@&KfG(9M@UjUK
-%P:DGag5$LKQm^.T(L=e3I86F0U2;!HgETC[Q(SYBFXXNF9=qK69t0dO=P^M,,f="`Z"E$Y$JeG4+It)>\piqXHfu]5o9jM61;3UJ
-%G`1^"%/rP1gYWU<r#'Ef$VX;q5">2K*7+E%d]V1=hKj"7h>-n6-jV*#I/e6*j)dHYD*WmOHs%64\)3n9hKn&THA%.YD]d.Rq$hIl
-%m&sqX6KX5576@0I\3ZV`r?khGbr4-XORKa"'4rYeJm[Lm(j@N*/>%\6\U&A+D]T5%Eh9^FoorV/?g9525dO3$5QGF^POg@_e8FU[
-%4Sp`?c0iD-L0;ia=ef_f5>PYUm;ALnLq(<#i^E&*!IF!tHb>?bD8pn1AMLEOZT'/LaUj#&HI:Ls'hR<A#0^Go$,L8"i,J3X<(eTe
-%qaA@K.L-0GB7j%)jWTB_2*h8]0P93c(_E:P!f]HJVjHUWEP=9HO,c"S`EIA>.LLnc7Jul0YOc:)&LcKJ)lWTY$([Kj9A4N'WCm)M
-%`gCaqf(]4Z3`EuIP2cD\ro&*VB>Gh]D4#,OSs=3GTf$4?c_5F&:\+QCZQ>#.F0Eo8NG?uE$`TY,.8P*jO?,I]`0,[]_"G1C`R0t*
-%iUD3gmWFBLZE#.Rn7Z@O$_E=H@K;3\,Q$U(N^G64%irRKrK7P2-F4H?)d'6G82=b[9t8DTkm>*?d3lf.kZk@9'gnD\.3L#sZ0PWC
-%fJ)B.&A-(#Icf[Wqi@GK,OdY17tXZ<dQ]oSV\"i<]N\65;4p8R'^m@eJNbUtJOs5+#9AkHGWA2:U5't>*==$#1VlH+UO)=FX)CT-
-%Z1A,AbG&4neT`C5G9>/FPNsJg8;?J;/VdP#T[5,KO_gIXfU-XWrXo:mr?00dHr"7KRi4NQgR+uP#3)Su<9=%LU7`nA`,<@4=[[tV
-%-n\=,D:TOm.3U_>/<JGI3F!%_]_"O4:=@Mi:IQ%VAP@N:'(RRa@^MZS"UDpnO[tK5SiCj<,rMTQS?W&?T<Fl.,"Wr0#U#W`7!;4T
-%F.P=R<(u.4a-kH:.=6BTs5(g7/C1>8NI4kF$7^ujoc'o;@<T"t`N=k8A=%_Yrm7bTIoM1'<#a,,H\E]WSV,hV8'bh!l*hmQq]%u-
-%Csi^D;8SY.Dne6p=5)bn.P:Sj[;rEj2E1&EFt-nAhZ"'+N9@\GW"lG6+6o$7qPK>`';&PL0;dUn,Q*juT<BZWLSD>kWgDX!(eh<K
-%YL")O;m57pilCpP7#kmT[Wrn>BWfh&8C1@raA>[nY305++@-^SJYgeD`.jS`3OiU[oC7KPVOPNq3F1-uokmX>ONTf^'TiYkVhuS5
-%O*H/2(`"*UW!@LNNu!M.RkRsJ7':)brAfJh9G)Mn.$F0)9S9_.EPpNC32tP\E%k8oM9%Z0W1G*sS/=C<G<S!HC:XnJ,)^0N2^\t,
-%pJ<$hm3L$:L1=lLY4I6hMjpjiG>LhZ*K(G-g/>IKFjZ-]p7Xj_Y%!2`=^.V*NA#+a%pn*:?LG")T0N@p?iKuTs+-gAePH5$^\j_i
-%s8K5$r]g?7J,I?:r0r32H[Yl8s5s@ZgV7sUs7#Ver7aI8h;A4n:\rCIktc\c6/Hs)MiTsuPP.TI1&_%%rsq?nlc26iY=IW&rOMn)
-%Dh%cDraYg#5I(0js#pCGfXE<t_DV,a`qQ@+,aeW/p\ad#EsmHm:]J]6N(Q8Z5_)fXUPgN1dKgas67lTJq'7`Vo`<cAO@,1)!Nqje
-%9XGblJ-2;N8Gs*f2As=ZLc'n\M0a)ZF3h04$5Q,<*5Yu\j%Xfn.>AJnHn\-83pZlF#ng:6Lj+ai"bcVc2(8`$fl(@M*EAD.jFn$?
-%iR'G;i6STVAkZ(d#&4eR5#EQ:3>L*Mq6@,3kR-DP<'H`e3B>8_Ml&CO)@45m`CPfs_)rqrHg9u]d?k3U8Jij=<d5DR`8hr7q_Kl&
-%&gU'%G?sm[2'$6G#m"SQ:Jh'f6GT6r?c*FmWXQJR=ag4r")$^G8kC.E\4m#:J.5m!E82igGloGpFdMSBH*0K@[N)h+PmC/c-mM.$
-%nkoE.S6nUI*qor;6\I3tWFBkACcc,eo4")Lj_[E)(s9mFLe;amAXMsKA8hrCKre0k"JQ"(81?'6>cPRf%KNg*-h@cFe-45W^sp6+
-%jSlRJOT98Q<,='6NlU11IY4i7Z5.Z3/e]Gl5T2N<E?[^F$27i\G8IkO2@/I*qc+Ve^`j/HVJ,f4dmq/Lhub,^Od$hh'r9NL(lJ[(
-%W)>1mVP3#,7:ahun[OuYH`<o6bf#Q1Ktb;"$,X*F@74+RDe]ru_"C6[[d9H[b">X8/6'jG-euZ3g!S$,U`hH$Kri_&K,@Zh[Y#<g
-%g$T)4</c!P?DJ3r:Vhc)1Bh?d<O5&LiMJA5QR3qpQB_k?=oqYgQED7GHJR?U&FTAemEa2%QfCJpksm@kV@#uK!h%:U.[s#/75>E0
-%'Q2VFV%%ZMXG5ST:#BAu/Z&MW^*!GL`^MjO3:p+!D[c1VWpH^Q]s*uqacs$TTFoA%3Ptn"%ftf,p?pmbNX:mFq2T,F#GE5)gCA3T
-%0MM'6rm<AIhSCeJW$@j+YAoYG]=:s_qE,_ulIi#]bIX\B)@7hQ=XO[?nuDmo!2Z5MRuj5B?"L31hGZhBOee5hGpGS9.#+dZ8P%>"
-%5Ybt'@35JDK)'YLkT^Jj5d1g[5M][LjuqoXlj!O-1P$+efCt>Tnb/!b#+Xg7\c)ru/Bn/[.llp^9'q`c-H4<B=H3B5=B^/U&-Qq'
-%>QCi1_V^XL#m/ReWdjTN%JoqBNktut;&mp47E"`\m@t^ejBP*&7P';IRbl`&QYu_o`+NaF!F]Hhik_j7AXC=ee*6j0ZDtq014VBQ
-%R`dledQX27n#,c%T:R+kEgeJND=ElMqSuPPJ't!r<6ZJi%<RddL%H]7a@<FG&km(Q<Bd4:"_h/e4fM<j(ka'\^qDUndeVq,=tHPr
-%ID!PgEg1iS(oA6r>/:MMnTr8.kRRK&EH>NA,2FJnmT2!\S0(<[`^je4UojJB?la@_bk'?*iKk/M*Q!(Yj!ns-6]b4Ieh@EN6Q%q4
-%k[ZXDeJH!F#YNS6UlfCOV;R*h'16.D4XcRSfYfQ[Ea3.JO`+>u/%GD',]>lgX^W!bd+Qame7r7]=U2REpdKq^k]<$<1K\)tCJ"s0
-%cr]EtXZF0o/0pk[4m4H[Ae#h!>OboFd<C"fDE:JDf^hPI6ruIli03ZFKcENi@<RX1RV3mq,3_Bbp4^#ck/m:MU>kRE6,g-W4m\0(
-%+/-_+BTg-ee:[b4CBXT1G)8OR!<Njl_OhHt1jXfue(_3%I*cGs[00>[,8o`#j`^G9?fpA`3-d^]'`NH4C-:g4LD&838@&$Agk7@n
-%+]TWq,@FS`E6h=.4^6@^]uk[XQ[S&oo'*7M5fmC#J=J5=+OTIC0m_Cr@HB0gNV%]lS760"=ssdW'D@<8oc=dR(nbN=9VF.leT2`p
-%,WL[#jK_X?7HH#.B43Vc^P/MJ9lM=R(j*A^`"^f*_+gVII_03\Vs/MMYcK6<I9j6$s0s-Jr>BTnHC7oCjL177\#:43?fHu$pF63H
-%K/?sj2V=LeqpER'-=[d].q6sA(&e(\b7dmH%DK<Ag_QHC[4KScO3aj@,!;9ZE1,&DiqHT22fPKlD0p)ukD.>O&'ore]>UMOV$D@u
-%Fch=F\(AF4c(OEGd?\7`m@ne?r+7duRmOp\rpaP=.4gRa(NhNtm*DjR0oi8I24Jon/D!nk%HkIO6gF0([##0\8I_W%EV0TF05\^8
-%pt99ai3]!OYg5KIOSM1h_In/m'[d]S"C#+cQ\>QTdh6Ps?-<DnbE9pYcSDDE(-qilK)c3dhWLqP;"KIKgW_-LI/(%!cYSur<G/a'
-%RYWo5/L4i,X)>6_7)k4>?UpjqeW:nCZuRRaWkAA4Y<Yj7j4-#*O!f&+(]d`$eEnG._K>e4[DZi\$EX0*Z+p*UA)N+t)uT%3l<HQu
-%*MoOoGIA*kGU<*$3MKe]fTh[-o#KYKm(j9V$]qKds48UfZAfi*]aG5%XRGaT^Vk_BJ62ZiH<ZoOj!BLu)=_op'(41"TG2fG$*tHN
-%p%[!I)O@;%4Ed*"h)66?b_j@:A-f\]Ke_:fnE@!=-aVh"p9XFCU"M.l=_K<%'3U\W65n%u(Y7G*o:@9t;E3Z"GApi'cVk5QnTb#"
-%M9W<?gO-udDD06hX'6<hi+_c>J(@92^$B,N6)5j#I^.`dZi&^I,s\5Eb.XubGeEH.N^YQW,O]F,drehK0k/O/Z*(s*@c<0?2qh_P
-%^43"([6K/PXmq)2H%'uc\3E:G(JgBC>C!g*S'Sd'@ZPiH:-0=M'<A5^p:I6G&gt[VICOFb,*(Ys)cp6[^/(A*e`Wqq.(8[Cqo!B%
-%It2JFmY2[p_p`aO0b>>Jo/ImI19\IOV-pH9RNC?U<R&aHhYj!YHi<m8juM7qH8o%%adet$YhRqADscep*YO`3[+l\:Vp"@fVEQLs
-%\<0S=@8SE30pigFNadmaajElLr=/,HEbVmLg\\ZKR9enN'#\(LR9Gsk6%8P+U$R`qHD7!GkVH]AlL31[4Y<oa?RO<Qhi"B9TG7Kt
-%Lr0?tX"dskUPR5#ol2XA2X`KPZu59t7Ig3*gNI_Bd=rE4o(C_smZ/95,Pl:;`::E-IK&IbJ;a3/MsbVDpp3@@.b:S;D`Yh74ETR0
-%=$;Upn^2!fk[GP]H&.D,n-Lnj>U/LJ#nt5JC"sk,YHca"!B7amX%\jmi:@s2Oi.$CLq\?bNnKq4_Cb?ncHkP<*5%p,fs^&;kHcB8
-%BS1:mhuJfo,V*7"\AYX46d.4cN83>q7OMZkH?VfiYBi+RpJsq]K""dk.<[3G<19Z)?C,(JN<EB:.`.7F%D$diE?,Hm`((O9Br6fF
-%TFfQ]V7sPT3P*^X,ei_bEf*bg]+=t'(fk`Y7(Hd]2?HnJasoQSLm-e?&/C.#)EpZ#-\?4!EhG?8()L!ciOZ6]6VA<DMr0P>?X+6f
-%_77Oho#;M(%!0)Z3p@qrK!$>U5o^+9qi3?:BcZ?^02',514)e95Ne<:#5eiS^@T\Ndn`2eK#ZM#L^X-(CU'\/I9>WY!DDM]f25;+
-%c2!&<q_UST;JH4/a^_,/XgLu[q<"'r@<t?n^/O8lk&?QBX"Nh8,^Ws3O-:@;>,SDWGVRU`a<"@u0n,:`1Q%C@]*XZR#!m7r-\[>,
-%$OtK,A9`ou8+![@UJ[(Hg"aV-IaqKCZ?kRTOsJ"GRm(BU>d9hdnAD-PJR>h0W.R<MZfc>=X-*s[IA6T:q)<RT/>\=a^s@:`$`pmb
-%.mEq^&"5N-BERQ3MS5dZ!TZt7BT5C$O(+TlimF>L+c*E:%4J8h+3P0engq]">S8gLM'QR9EPc,VG(P)LJh#OsR3.Qd7g?gqK42]U
-%R&obU*8kF+-pi(ZQL4W[&q3^h_c;8JA<b[El3FH6Qn+A;h,gW:,"p`_.REq;.>&s0%(o"FR'VC!Uu'"VV!HhIW(t.]C.tCFM]%Ob
-%FnQqZ3HpHt^3"?(fFjYZ.(W@YX!+-9SHm*XFCAmi<(7T)"*P0maX`?a>BE-s8]FdZGYehNXu]!;QQh>3*\:OjIL_2[bFd:GQC&;R
-%W$99-H..:t!V6esGB!gL$<T9!-Nu6pRk@4!LunebJKJIRMXd<(73F`j_I/]%&W7s:n@<=,%j0)TZ-k&s&`uH)kj/H-Lf)KqqEG'4
-%">OWQ8%"LHPI1DUc3jIr\RgDb\3Lcrk,Ph]@7_^lI<kc1GX*bN@dO&jEtq&D(fdXLp_.*@Uml<068^>HC]uFlOdm7=J[g0&Lm^+5
-%;sFA,Fr0g+ef`0dXA+rD:0d&i`<HcKn<h`W=t!dk0Zieo<V8dCC/b9In=@X?U%SW;@)RaF<JH(<P4hk"cFgo1=9l9JG4AC8e@_[N
-%?AdZq-s\7DnIUK&SI?do6pJX$&sER9TX)-<kC0KFi-FWkos@9Xp7MjHB?d@@-T$)LBLSaC3XY(?r#Em]9H_b(o:WD*,Wd)V4W%u`
-%9YA*aao35C9$s!!&CF$PJ?,(K]$ULW\QIq=MCH<$1f+fV;HQJ+Fk+EpVGO)==-WcmANMFE%\PQeo;,Whc!A0&7uSJ*?;2#il;Ck$
-%ne>*,EiX7W&:T[Ia]9r\Tf@aT<;61[`\H<UC#Q]Y:EgNf@D]@ZQijI0^EJ(]/TG.;-!rN,Ke_6CN'cGY8=6ZH;dZ@M/qYn4iArj<
-%'p,PnEKfDiN;\30\s?/JYADM>'8DK)MEroa4B7KKkn63SYYu>XW46`Afe#>.cuJc*q%Gj^e.+biG)EcGC8_AB60a7T6J81Z6ie`5
-%cu$>S/.ira(aSe^$TGkJk]kMdAC_&ZbknD^S4U*G3ksZ&OD<\uLjQp]5_]?AK;EpLl0Z"[Eki3pF[=Fs?^WBfVta@OiQ(9-L/%T(
-%^Nt#iIrm.L\3X&EmEHBj-5?-0="oAF_U(Ou-/il0j,KI"<SX9cJq/'Q9Gr$*ALTL0clT@rL@RH`FhFpk`0s!e]8H`-&.D_(n],RJ
-%F`(@S:-N$FPoB"6/MYIWW5CJs%%2h0[Pb42mJMegCcd,a$JuDBj_5h2d3!kO*)*ge5DT0`XkeMVkg'lObF3()LEbqNe^++:P&GB3
-%[Pfl+a_m@tR[+Q!?buuUep7s!<K^Z/b.F*jTG07ZA5l.C;OMQpW^".I;RG'r,*M4^;2C>g/-RC4S&Q8TksRAK+b\Cg8Icq,"6LB2
-%nkY&Q,jLE:q'.03Jse%VgJiT0eV]!W`=!d5Nu6Y3@aIPrW:!b'`aQ\@EJ6S!FWUcQrNm$:_6/H6('N')n%`+_e-(]SUf.Yj_T%>E
-%U)=n,ODRTX/QIB(3$#cVnq=!5o#bg<d>PK\'$:M*p'bb6U?2a_We`-U%uqhfKbT+1M"s5Hk?[&"&$]KDcI3G%7+e;sfV'f%ZLrZY
-%Q+0JUpiM'/cUMQMlWI]uLfMA@&:$I$AI5UgC0OU.JmLmO.CqD_#qtJNUbR^%cF6l":b^?FaD)@!(*>:.P87\l@iC;jQ"u#[/?1t9
-%jK,CM!;VbJ"hG$JAeE(Vi2TT]KfT:n."VEknl"XaZ'6meFafE@+lH8n1h8s>F?&UN=>HJWJ^@E.23*8Cg&eYkKJRVT,p]^^B\Pt.
-%38o*L/_JVf"lu)pU#W]7V)r5>2,:mbNYFgWp]Nj<<qXa[riP+62`LeVlSO^M@1B3;ATjX>;-nPkHKO;W$.0*WF1Ps,K3k9S1o\Xt
-%2g$/XHj[lg*n#YM^oe3O6q@C`^AX8@[pG@HMe@`W;@d7]5RD7"dFW<$82EXu"G%3:Uci=i":OFRm#0X&CD%hS>Br%><,V+RU-sK[
-%cZA/N,&%8VZFLGdD+1+*iiNe]Se`p9.;kX/ZH5.WeJUgF"h7H)Z$hMDQjjKNr@E'(b"iSP,0nYOf-V*2CtTI5D^3Fs'Y(2%6+>EV
-%r$9<L"D\;!\&C)S(l:6s'@"2@Y`:?49L:a2,0tu<l0ZA:5\E1rEL9T<"+c$KTYe]ZBYiO+%)HPA;7q`WTi%G'kl6=r5c7`A8ZF!G
-%V7s&6oFN'TqqO)8olUr0f\X`*E_r`6L0Qa`.d,7X[-fQ<#I^rc>6u5s0sYQkrf1Cu&::=>5S_81dDoM2;&Vlp`$lP&$`V4$]snCk
-%b-GGWJHaOGZ!.8M1Uj__`l$gKC1I.PY`'8Ao%>'p1PIWQRJ!YQa2A;`g>Q^Z2F@KoXcm6MPFBus0,*@RiG1F1Uf"L:0A(m?cnuB\
-%J^^+b8$83R:#2I:/?(]rK*JE$2Q$V7guRZMb>.'`".$$*JaY-Xpm.,'oJT9N/g[^KaGmMPo`BRd"<=jVj7.pfhJU<=N>F2=SV$a/
-%3&o7[f@PE@U-Dfkp$_nO5Q:&RJ,HpNs6tO<di\VKDuRperq*'V78cK($0F&?l+a>m.Thi"9&/n5eFq]ZWF*$ciadRh]G+'<o5655
-%iSWtR_0_B^0bL:6>*>NX%@5tn4$NA9TDtrs)C`*OiR#?qg*#Dh#rYK,^#!O^Dgm/uDJ8o#HlA4rA)i\6WueD6BqS$C3q!GqU*^q&
-%Hl$`8_MrrH/\_)WmG2Xj0_Ck$#g)'hll-HhVn00l6LW[2M)=Pc^af\)Gd#A!rVZA,f)m;@S]<^oL@*l3U/1POL_H=HZeMA'Q3Mnf
-%[k5>kq47E=*e8Qu8Ni^O8K%XQBD<BL0#G)%gJ$cn8DUT*HVO%TcgTZV4FuZ5IZ]3bM\9dFlqZ<F`fBPWokm^=%,pksnV^p-8MnIb
-%4g`VF=QF9XU_8m[1rVC<^N6lFoPBMWkL-KIh:bo@maG/Uo1i53oCG%fqd&5+rRrTnr2Qkh\=.9-BWHOua2!"\GFIN\TAR367j_<F
-%L,:E?9NW<P&9("+@2[s>Msl+DkC+LU@>`_Q4*dS8XG\tJo#856S;3gDn$L&X5JM9SlPY/Uk.:Hs*^c=SBcB"C9,cf6gWF(JYP3rf
-%-ou_.O8jC2KG[$X1?s#=C\'JL^U_rdHFiD`?+9cU[FB?T"BGs'`-ZA"HD'GJIDj^pK7G@9C&W$P$\B<7YV9O,DnXW^Dgm.VYMYma
-%e>4MDk[R_HLYH[IHT/A7k52j#q!R<hme;jOLAX*o=kYjh:lZJJ!qYNqpmnkgmcSf^pYIsVLf2?mGkKh)X^4@r/<'@A>Ip6XbPf^Y
-%hF+27ZMkV#1h,'cGc[8+5nr7H(4Y`CgH0hZA)V(Y0$(fkVqk24FV?_U$qn@af&M%Ime"+\"n*Z,`1?%VB+Re&^lEP"%cf%qC\(Ul
-%^V/Al-5?@cP.H;-1S&n/gAktn;;P0bh\P,Jr6G7)[%qNO$0bPZ/'r-E?LIs!"0_H*>C?2:488Wni_A:QbZNgY^M'AHj7,H,"obAF
-%^A%GoHc>H'oW[qBs89A+nAi:jS8nH;k!6sbd:Fu.fcAR05klQ'o+!gbGPu]#M]6GsGl>29f(f7-GOB_sLjZT+`MXk2B0ZF^T:"tk
-%m.V,8RDI-*\nIHur"dGQT\#U]_j3XEmSiCeg[Un#r'\3=9L<kd%_IKpnM*L<2&OQ1'&$@pBb$8+D[Fe?l!iOY]"jUH%ffPnlB5f7
-%!;_4;]b%mK\>SX,6!TpOR*m$g?Y4b&+a.FJGlceO8CJ(`eEA;CP]D[/&H3HmfsSK3PFeTr\XiBmK3"D&2JFL>[aY&^KM`3*P2spZ
-%EG`RR/gQ#E<\8/G5+O(q+UC[t_MlUYcK$_oM\Hk3%/$gb9\UZ%SJGehq*"S%KSAo%N"^irYU(JeU^fU_\<ek_:l^&=_R#E4ZgkdU
-%[pbG]!"P>NJeL6q2;AtrJ"mdr)g7\B5Upgt96*0h@17-fJM%!I60eGlC76l#%-U.sB(^tJ5o,qpN/2%/9F8>?KF8W*Jqs\/*_;`h
-%D]Y]7\3&aY9/ibXD^).\J?Q!f]UER"FCPp?*7^d,$,OSdK_n8gPhM,";LlJk0uH#A\If6]9ak1KFfm0\MKC_S'>^?=<ip,AXEG`f
-%*_dnTD`JE$o'f3gVISJ?K2lfD\!;RIf@jKdZH0=H[Q"Pc!n)f[)DdmqoDj^rBt1s?]USs)9CU0"1SbR7K\cJ9SNBE"E+A#s8l<FF
-%YB",W,2(l%0tjirI#.EuGLA8Q,6X+Tg-L4YlI%IDdfA_:YSK7GI#fo4PLRX;9Xp%p&_sR6-@!>E)5_Jnj(-G3/i"]"ZY6)0:dB4D
-%<!=rs/&GJ-X]p6"j[Im"F5%iOdBASV^p[]5iAcA7\sRF:VD"/qHn8r]Ad*%oddicP5Z87AFnURaA*tmF,AmYe41QmUc:j!"P*GI3
-%G-1/?o,u0bmA89%9aN96cQp,@_"oJ@:?Wkr3"[_bmES[!TqnFM/VM/A%[i0XTQq'SB].<4apE*)m&Mo=&)'@YQ/@CmEI]E\4=M'2
-%/PXbMWjK/i#ucudK_2\Z-?1E/a>`,46_JSAWiEQ3)PnB.oB`Gs$>ph[JRIA%"R#$R4#EjmU'lnMXGBngdZu'XJm/:45aL:0Q`\Q=
-%1@_]LH:ch%C>#a9?_3+8,bp*9r"A:<O%jXd*jGp[*Z*=I[U_I@5(mLBK5DPuYt5[^]f.[T,iG&caC-(q&N\;m&2$Y/M`<Y`O@.f-
-%,ul4+g#0[-+Z;^n#eKJT\9V:I)$(sPeru`U%53mlY(Us0q%%MT&5(pM"&WC%?m<$4n-c6/G)GJt*^iY!)sgZ=ORYahR4>#?4<$NI
-%>qGk-RF7\gXSZ*;$>*A@r#(jQ]^JLCgl<\(pN8T^]3=J_7o[=gD6Dr_hjD_?H1q/qV49$[><+mMjdF<L/5N<,+!N#!@@`0gmpR<K
-%Q)mh%eAJ,/(XRDcfJ<uZ?1;hJ?#TTfKCZ+?rS0],]-\TaoFR3*?u1fTU@\TZUt7d&]!rrDk]4EjIS_lmkC""8f)#'VR1r?\)TA,4
-%Z%Adg1e8)8#RHDVJ-JRMTT?meJufG^%\)aLO_6\5Hr]+68\SJAM$gu_&ui-(a"sS>UbbYs2]t;;r=):HoKAIZKq'WViX[9G/0FX<
-%Y!X>g"6-D]7Lq9b=`Q4T<(Y1qcKQjLd)QVTUs3+8RDQA5GHF,<rrWuX*o5]3P\q$6SS7:26V<;*p+a)BE?PSE1bsoM^e.=cirBl_
-%]r`Z]rrPtlFcV<S;<l#&#c+;:``e*sFc\1@ckK$V8f`[NWte.RAYkc^W6_5V8!dMTQu[-1pG%YaKGi)(W2eYr0Z=qbH#J"3^WLEU
-%9I&16MnTEgNRGXggi7H"Lk00h4#mSb.IoG1Dil.p(+fO(_!-H7*'gfkftiF=amS\HN!5;@d-)J]h-6WLc'.H#e"5Wm%(T`W3[Cuc
-%jFO$r+Og`q[+,WWR7f\dHDUtV"c)(l3=k3a:H)8!R=iXEIA^g?mR@XP@U(\AqQC&9eJDV;?KKn^VRJbQRC#Ocg,N?BmK=Xg)@I&F
-%2[9UIY>%]P%q!i-NO1Q=Yb#\mHUSi<E/gZA_Z1[IKs>R-Ld[@aOJHa@\qYPSd>VTf7Z(uBT[Sl%52njEIr0gV^D\e"k7^A'-A[Vr
-%%TURS,gK>N*)B9E!?trJC2t17-G6u[Cclq'kpe"FEAZ[7])7R^au.:s\)q-J/;?Q;!km@(*Y%Q!OdH.rVuTf!F?pHXfpDR;hH'cW
-%/V"M(.g`CEgBYT!/<rd,/UO7R,r8727[:]*UK(PM^nTg'C\MpF&UKqn2U_7-bP$MC[HAtQnU,Yi:_#)Yc.GshV%?fRa7\Sc&6TWU
-%2akKEASrYj"L1h(/-GO49Nmp.g]]#6]!4mr>pYo`%3AJI`ePW*SsnX]3Pu0BlL,G:Ap*.3fME45or02t3PGS@FgDD4!<uEDE<C>q
-%ZiubPCi(I<H8\-SPhRP!'Y5i7ADs$_H84R$^cj1.o$CubmK"E'p]q7jZq6o8aN+E;%:<aoeUS0%_(fn1c7CiW1o-U9eM%2*+d]Ot
-%m/RHG!*,kmb"R)4KPad@\sCKKeDoakU^ER##s:sJg1+o8(Ej^jAP.@p2J2W#CqH_Wq;+6qJb9MN1*3J]R7proG_!p41Vtbc-,hf3
-%b3-PpW*6j%cr.b51BlsQ\?i_E_g6YGRl+!9Pb9&"ese'8!2pX"XA-\:T@pO>R(-PQbK,i7rmeaf4gRfgMFf:9dX-%`.$NCV:K7b!
-%I2_tc'R$e'mS4NJa%@Y_883'bKu2?3eabPT7/r6Q;FPPZbhHX]JO'dMkYON>pO)?cI18pC$NCYQRM^t+npLP?-L_<)a^>3>[_.uL
-%Rr6Z[[IMJ")%W,+/m9r40RNnodj.r/F5lhkK,j4<MHd*i^ors^l3,bVGd;_=Dg0r%ggekgSJ#Dh[N$:ARVVl=E6q09#__"VBg_3m
-%ft_`I#-rp4o[j8_BSm)rO3Q&5hG5J^Nj2D2$p1\1V,gH;hb=8nf_mLrYS<>r'nJGX.$@fIS&o/YnEG]tK)/WO=(*=);L(#/BZ&mp
-%O+#BMhto0i-$IBXlfc3@LN+HSJl?13#-p@ooEi\ha!7BcPbqh_Qj$=*H/'/m=?BB6QpSL4=S'_5YT=>M)kPVq;oV@#1m+*AV!$PE
-%TeLWL?qm?a@Zg#A;FZW]TSeH9P[-<fc"[r@[;K-JRfrl&S"sg!GS.''e5;GTrc#Gn-7=]P.NGajl/@K&XC1Ye?B:YDDA('2IGXFK
-%`@RP<Tdrhp9TaDZg*FUm4'-O>Vm@6l5uoop6:88.-lrF2CTN8L+jlQF#'rp/Q@:3omQEniY6s(k.;Ko.EE2:lSu;A@E+:k\O8Y$%
-%+hu_W@mjdmJ<G,]7De,AYqFo%X[:8q'@ii`2/U:+ZmJ\q3AncB-pU+</qp`d\eqa?K2N#N/a67hQ4/'UQGB4US95-/#5G!O"!qd\
-%@4_OPUNDIu=,<#6TWs>s,O,a"+-'R@rXdc`q7EGSPGT,ujok]:<D"f=Ka3#iU@UXlm2l2J*J>s^#9J0$8P75E%$I:i^P1L@<$8;i
-%Ml[P-iYac\&+9V8!d=9X$O%Yn3NOTG)aIXJ=TrqdZ+fh[]?$-/p>!2QbOauQ+h0j\/N2@Pl;Q"1+H+<9oIR:Y,S!!YCM`-3^S\&%
-%;=Zp6l-QHZot<F+[Aruc9ghb.]dpp;17roVP72%pb[Q`7]Sg/YOsT=,f]omu"[=ZfK_pFi42Q3p0&]W7QK!=k7GB+4^KjP55h(rk
-%^KqZG$e='9*F*]R,F-Es$N9E?kA=^Q8Oc9!qp68gQD%At7:s]P/D*YT?dOQXXr]ijI)r[9]&Fu(J]t3o`ngo)hhq%Sg.nn\Fq6=b
-%J7pirNXKK3XW5M6&`n)VF%2#CHsJ7S+QPiGAh./9_(!r7p)[tA+N.+=/OGYuH#s^A#HLW1<5g96Q4`RA-3]P\R0:fHb>,[^d!LG#
-%c9nmN/;or3)(Qo&j]##S3]g%0nYClHSeG+D0:]T9FhF+V3b.Md00eK=/L!fYE86og+tX9;BcI[q6kjEROX$BpFjX'UjNOcM#1X7B
-%]7<.$dZ&"Gb+&[PnH"#*ZELdLYZ\%3;9[H+or[iU4K*ftf`B`1P2`d@ieUPtpbd%,`*neHgQOkrE,9YZ7Q(]E2qTtojDCoDlU@4(
-%(?@;Do:h8;U2ukqYo7bfKo-QY4KBu0:9=.\:&(l9FQsu_J6\[IP2RBF+snm=HC#oL1E6@Ep619iO(?d472ho[5o%A:GDZ=TU:`NY
-%#_Ien"mFZcOf3eCKu-"(L_e$9S=ea.+:Tcb@AYDKkhQ%rl%qqq^WB4r*DSkoSGFZga?,Ne=k06W3b\-mS)be!H>"'+ZTDrgiBtRm
-%d_t7_oO5VeAc@X:W<_B!KY6i^9JnklRb2#cBSqd7T,T.dm._R`.a;iRjec"98[Qe)5*=E,<b2j[.!'END=R2(7R(kc66IZOXH?o0
-%)?;I8\`Gn4[TN3n4*A-)X>nZ`4K9rNqPb-Y[E;DUIB82SHEA9V`:,$L&F,cBrKtS2=:oY-Qe)sFh+;Pu&t+`K-o;GP=<S$*`)i`R
-%&Ca(m))5F,5b&9g^8W>aQTTJl"Q.fR.QSA<Xc/'h_0oeT'uJY)8U-[E#$&>\IhYh)UoVF5GH::0E.U-ErbO1C$/&'+@ndBEK,d(G
-%rYs18*R&X"LBAiJVTpcIf>"kY'nMa.d[FPi(<[6R?=%j]!\-VuMsGh:I$Mc:N7ef"2!*YXmfWZ\+ikPfB@s?uesrVA^G^bHiF?G5
-%%0\>]`YL'c-&]^KmBWf@e#lZfE?F#&>6/4V^6J#qK4LiN-VG=5_\_NFJL>7^86<f07Wsfkird2"?FW"X\W'>FqTI%P8$IZ0Ll1If
-%r@6*$_K&S4Nne):g"_RP"MANKKdqrnZKoEaa#XRfVnh3M=gb-2C2h9V7CF((4M%gk>;9c?d`Ic'UpgDZVNA6P$ilX_o,4L1/h`!e
-%<O_2<@qX;o3B_Xjba]Be@9=*(:?5nmU[T:T0:7';dFU7&lZIU6*qmkE*Cu-To;Y'NN2/.S'qf-r"A9+1k,^eg&_`E,lIqDq\>B#J
-%a7MR7!U.3J!HE'C"LXZ=>HQ`M7iX.gO5Y!RG3"pD47\ab(8S-k6';k<!!>2Io+G?sp1FuCVe1OiE@r1t6Gr<:*j<dE_#4S^ODd$/
-%kCl@2fJj_,8(=e3<12]E?jl2'ZJ>C6i$ih2Ge#611Q$bd#.Z6LJ8bsPIqRr%&QHkN_Je&%6?&bX$-SNki7h1?j:.WG@8+7H>@ftM
-%8N3/2:\K`m2A^XT?$X$6?8CjEE]O")%Zq1K^2>Ve:(g`Pm0Z`)*+r>\3$$1OC^Yc$'Ll>7p'$0mL-3`;f/QPrR1:j>/3mcC_QgJq
-%KNo/u%VB1bD-Ag?UOKeL`3JlU6U6]OX?/A:?:J(9n&LepC/X^e('!jpI97[&K+odeOi\3/O$&U-Iainqkl>;B<R;,-&9**A7=(V@
-%qCn?ae&]ZdQYn.g^kYYsV!-b,TcpI1m^];]9ncmEiAoliaE/U-7"68/@u5u8iY8`<HCG157(eB(jee<>PqIbf3f\Hk<LBO!+[.q>
-%QB42$%!G#i_&ZC-i%hVL!@]6]B.1#:&Qp/D9pQKd1>69(^I21,L0ogg\8c(6FbZ%G5S7:V+/@n@^rmQc9bL:*Th%_Tq"3#=0Ok*1
-%9D_D<,C&k&.b?XmSm4=+bnr75dd&q:1FCOO4XdY74F5r0(g8@T,8+\0?cV+hOCl!UH/D@%)et+LH>Wc:1Y+*u6`oICc*Aa#gOYh_
-%em;2g$Sk3"rnu%gZS+<=B29EB5b-4O<^2BroHlj0!BJV2hRrS=V,S,aSnA`K8jF&\#mEt6J&cqghFZG_Gree+C\DO%!Rid6AHehJ
-%2UIeYeB]7O*_i1Uc8<C6'sj9tBuC0tT1SYlBfrl&&?<mB*J'SD-_qLK#;rGb]KLZS871]Fp-m1@U$Ot7,.;#i6Cc!q>:sKf7(d[n
-%8,,ih('4Y@8dj$MP%2^?X;1hjd]ZJ!i#qi-F9hNKoj=K;M>@<!"D2J#rZHb]7UBU(8:MCS+bon<'8$#)62VHD:(Q9$kktJFV[N"7
-%BBofjLMSEbb^oI<>M82/CWZ2u9&4R<+U$B"Bg;dc2mdiPTO60b_)$2kr%Or+_<<*3=sQ`rb`@ucj!fASl#r,S+R;]5S-YGq=!aDN
-%$"aT/T@[Jm7j7'qlTb?c5Q9Krr8g`E&$Sf&iT"qO`PDOZ.A5biFoV*[WiLQZUMD!SNcW:S?[g(4(B!/R9t)e4X);'J5tqfek5OWF
-%oABO3U-IT6JYAi2rdtenjDuD%rKAdqqZsUSqdJ"npU6(k2E+&u*^>8YI:<pPgR(6GSOHdRi_m8)Fn8ki7.8RK]]V$^ndckpJ%j\8
-%Cg#*ClhDE9hsQie2YDH8j*-(KN9f1u&qN[Fd5LsZG.e+^oUou7mJ>XN?`f`%bI)-5G-1qsb\cN%5jQGep$:FKpN:p#*6S&h:&"[^
-%.3?fT4`<L@]:O6A\pA/HlLuE`Fe9*:ajoO&8'L)eEDo(&CNUS#NDI9:GFc!%I=gC/a6\c(M#6#_L;/)I+&HQfY3Tu;g!n*hpA&I@
-%^\r6WWMJ9O-B"t*1j*bfplcbA!]Jp(B9XYiH*lQ"a'6.pC&6kWq7LiG4OUg/YHGJH$]`JfqfF>;H3j/#j7_<oB=i:<:5Sn.qln##
-%Y1p2U^$(5Wjq-"8ge<4MjQ=_Z7iF$m?B=pUS*?tj>h9R3Upb;"rTsE`S*@ulGTDTMB>(139g>5Ege>JrR1@-deQ\N0/'n:R9V:?k
-%Iu``:Y^bG%5J*!FA,F7sq`HcU9q-RNXPQW89XESLHG;3+q<iD$eYYfb[a/"o^.eRIb<Do9.^;'g=@ZXNg&OGM0m#BC6^X1?/buu*
-%M5DME6CE%N&sM'DAVG+eD8UD`8_cd2D<:"CEKdl0qf+8WjS=24pptlhbC8TJ7#.BP:2;dE9KY)!&9eOSJ`\mq[pSO:gO<m9n(hO7
-%j"8:L=8grPDf6"hPY,c6FWGuQPIiqZD#AClSj,(]DXB:g$u#AsI=5a55QCALV=6TH&X(&o:i-]<:iY*)S&<dBI%A$!2]Hc>eMDTt
-%k&@_NRn/"nZu'loGAaiL>\uc6IlFptlgBCjr6487_V*7?DpKEl]5GsC:>>_1[LM6q*nB(qh9YOEm_A)V,(t(8NTFT]:HNTj5*%lf
-%G+P0a,^ZLUZcTlUFJl>2N9i9TRpIuQHO0WO$(26+Y@c8h`Y-dQXDZ]i6p3l-FqJ\4p3^nYqWr;NP`t\19L<`0$62AV5EToBKH<.]
-%_2&:UA`NBc>5B`dn=gAgL7l7qk)fPA/X$l=^$5pA]0dM<VU<tsVOAeXLi$o0j'G.^p=^J#Sgi/mKa0h!KfTjN8Kh^?,*gpOF!q[$
-%BLCD]EGl!BK'oR^Wu>$7qkX55`c'EXD!aVs&ZuF8>[P-+;N9:]@ou"32@Djp[Wmh/b[`XMg*\O/LaBoT6'r+d"[Mpg?1TjKlV#tp
-%We^D@a&\9WF.)A>`4AbSbM;6Q1r3G>eFGE9W[LF[D/G*qZ<;Po@tK&9*+7-cZt7kGGV-JjH;P[a]R:R9=q7NiVZ2j(Dhe:mW]f)L
-%7i2^h]BNtr6iSTiIV@r-'LZgW8k8pkPN2UQ#d9qO=>]`t@7ARD['u&OJ_6f<9Q*:*Mq^d%SlMYHk5ed'cHBTTA(nF^Dj,F)9almf
-%YQLgdJu%YA9Hdt%:nM8(A68*oE!?prf8XhK>sfa62FUG&:;Z4Vr#F`3FI4VG9hat&YT$[(#Z2E3A-`*M4)"UgZQ8PJMVeH%'0lT1
-%WO8iQ6QhYa+o"5rG'putAVM=[[H*?p:iQpgBda4X3WpXHKh`W))0;boW(E@,li<_[3)d%H6q8DG"1*NP_<Z&HB(5L.O))RJ*%QLI
-%4^sOe.oHZsM;CddPpfl"F:;^NS"jhH=$\D<`U,/l==-tOC8)]"`QuOaA&];7B6",Je!a!7>;9P?+4ADmq+82Xi7:>t*uR%a<FU_\
-%;nc!_9FbD1'G$.@kXk&o+g[kEl/(%=l_?tAdVj$?U.sGVlQp&YDN0BiTVND^5c'qnUE"N21mYp2mg_ISPnZQ//dg,G,_t(\aFVUM
-%Rkp)>dq!i.>[;[3^ap!pkgF*g)U<-^],^(L-r`:@'m))/9C`q;dN$QEP0rs:pAj^`-;ca_PB"@fOs4hC7d"eR3L`TqH^<T0[B[:p
-%nZB=^QREk\@L9JO0Lj77lR!?2,NpfiABANgS#\qkLZ2XP-g7U2%ne6MH>q[i"0--KosbIKUhAIJnA:+:C<d_7#(@g]gG0&TN&F-L
-%1fR@M`nap=])4'446l</&c^k3gI6S2KbS-<htLt+9NH:gOG(Rrp.6GaX></EDiQ-;M<Hl6>JsjT;%khY3l%@O\hd%)%SZi7__1"A
-%,t[]Ver##.">isu!UmiN>uUtAh1cGDk?3kfT#`h.WQk0pK?I_U,bsG%>Mm7TYlR(8ZuMc_l:$gE66(o+kdq!r5M:<M5otYHRj9AO
-%Z'=WK%.Os6ce7WI!C/Js5RS!"!LNsqI%J^QB!JNWeu\BSD/f)$b6\;D9;-K3%6$4M"nO+#>D\N8#=)=u@AK(u;iJR(]hW5>M!G5o
-%,nN-<b,mc&fuss.5X@A>Xbe0iK/&4='.6goDEj3N0oK]5H9i(:n#%1XS-s!\Mt@h>g6Xd[TW<Xsf;BJ&4luj2a_2VkG1_Q@!V6Vr
-%0iE$#r9r"s,O,Q42,Fc*5Fdt+TH4I%JMn<@/h(rl)Y+);#F#XIAN"%Z=];'#bQPu<,9GBM'QIPn;a^%2ipk\Hc>pL0"6D+g^:"&$
-%-@pb;@/"hFP=Q^YK]9Kd(^qLYE;HN!lRi;$GK^DQGT'#\L)@nW,q'JdJH?TNV$Z`bLCHlL_CcBN!(<^k%TRa9GT+kgmLV`=f%6+D
-%8D86o_:&IT!hakq*\pW]aR(2HEXl5cb?#WIlT>%B<S,I.T<;UfIQ+)Sr(Q:0kV(Rh<!bTrEQgO_A[0<`1:5KV<j!_p9mQ!a:&mT]
-%Os]"lYIGtN[7%!_AY*XMfWGkc%A8CpD]:@<Ebu^g#k-5snU^NKDLiE8307)k_\(FE:=p()R$WLR1[ZE^,$?2(bd=SYFtmHEWgpJ/
-%c*BOp3A^MgeRFDhfTlSP1oB2sTb'\M"f0P4GT-,p\rlU.hTJ$o;*<QE0JS/$4n54ja?]lu>.`6r\EuG"LaE"$qsL7;*ic#J3k^[W
-%JMeLf]ZC"eQg\&#0GiX=aB#RMdi5,Fc:S9["(s<JDGr<;'KtP+Fg5N):Y^&?C^Zco&>$_]j+XaL!:E8=n.Ni]I'tc6,!"@*MUuQ<
-%$3Ukk(e!f;@gibcF&101OC_t98FD;nB2s<!jc;0@hT_gTd0Hf^)-cCoU7e27K0)4P.=bL1g<prk.o86NKBtm""8lR4@OU7+A/NRh
-%@2BC&_W)&,6a1G?^UcFu@0:2C)GepA@"glBU&421cX!_UUPc@%eopqqF?HU6%,hfpF9/n,<tV8fMQ2]q]E3GrBrGK&ecXoQ3CY\O
-%h32pt_@+7fH@B!/o$`I]]PFlO'<hj(5%FeDjF6L=3.8ZKa3SjQS>;q#PPXda5-2X!gBM]I.M6ANC>iT!+<].%./kr@]"K0g5B%=S
-%W^5mSV4o?+5p`AYdr=/eNuuC-YuRG5&GX(fAlL&gMp_6$Ha/5(DJ]MAke!s'0mB'2,1Q93%ZdGMQRf;^hlmT("@]ErQpQ';E<aV9
-%>QIY+M^buD7i19YDEC-Fcn>iVpDfDoh%d4Si?Ue*PflJ*?'iiZkBDb0e90A]pr)dRk!"%dNHO+<*q\%\f'>JVq]7,pdoP;N<YKL\
-%C##$"ZVQ!1DLL5e?+GraQOK17?=TrhlIU5q5&FrfC-Q3WnfjT,qVC`oeQsI.Zc]gRcSmN3GdY9sjqZ1nS?dDqgKPTZR-d&EF.)EE
-%a)(JhZ^jnJ).pM;1#)\fftPRJ@$Q/\D"emT]pnS([f)3=hVusBZQ8M%m=*)lpH*!AhjA8-RXS\Rl]'S`Rjm*.T;H[ggV,6MQeAN#
-%Am9362U<6%GKb6D1#(G>\=)`/A%$T&]Zdh!A%)8og"u)\,KoIr]iDaklbM6hBb-gj"!,]g%/ofG=CCW(Z6RA3l!/G?ASlPVAf#G-
-%_@:M"Ba5!fL2e5%,[/,pj*.E\"j!U3[c[&8C_XDb?[(k2qjHp1m1JZt/`.QrQ8DT.i;<34B:d^1MB!1WGMfQES>PE&FkM1h>F)ON
-%Z`hg-cf]cKG+J4f3,[U,i]U%D+alT(oCgW"ADH>P!c#>3ccP-#HKr9/e(ai@37j^FA'O:3T)tGKrk!!Fa<Q97emfU4+9Hk`?)I.&
-%Ormq[BCt?5;gd&X.Fsigd/gdAYFE#0X>bR5G[H4DG^Cs_<XojfqsDoYj16=)'5Y(Sf,m/b?`e=te!nr[`9[/ep$?lRH.X&(QJ=S8
-%rQ.s#XnK'g)"%94NQkLN?0>(<ZZdrWB)!t3HgWhb/:#uba*P/SqlFP1?`phWB(OOXbO9ee`dFr$qX<^uCHScs?)uS_L#2Y?J-5Q'
-%IJ%'W2`P8D)&[U*'>7a3]kZEYSo!tbni^_GN<8VD+t$+*)p4^<92?:'1*V?>*_B3K`+C8KX!6hf9f#/>O-kEXo>kkE9=gLCi\o$<
-%NtYB!2,pdb@,5,M"N;fo[g3d^3nL(nQ*_PD-IBEDJjU2UQ;c?KX,G"a8%])^""J)C&.qT)86[8d$*9f]OR?EIiIpk<)-A](c8TUU
-%Hm4Hff2M.\@h$Qk6t6DFWZ4G0cnifgStr0\235ZuW0f;[)u*YX"<nM#A\SfY!*DXsJM#t2W7m(7MpSpH'Wg-uZl%9OS^j0.JO336
-%isoJ8gF%!+'rIi^*_(A]WQq_*.2mD35&Qt-,Z?I0T5:ocpZ@f/j9S%]Ak=Rt#J_5V<a:R1`DV4`AJ-2ZjS9:Rbaq7HLd`CdJnXrq
-%K.[=e(ne`*A5uPiCIoDr7Of0c/W#sqb/:oOk(e$090-mV2)d$n9jdfr;9TR!?@s`g3D%>/QC)<(8;9.o<MDeLB.TNK]/"&.;HS>b
-%r6WuJ9U'Cn59h(:Y%Z",igM;F"_IgT(r2Y#&HmE-W94]'Eckmu!@V&49tDb8JYRX8']SAd;5a+.Ks?mNV`nt&O;76k#]5bho*fqh
-%gjL?0aFI5qb)RtB\AN*'C`WD-`k5DRR-@uopZo.>MHIUA8P;pi$7XLK8n\Fp(i8IMZac(Q%qCPkML9NSDBhk.\tV#Q*":1;;mjuL
-%"(b`XrQE&r[O#Bb(eqnL`mQ,Gr!MJ7JPomH3T`ELUd/ZkeZE#.3,s8-CX:nZ9m"umV/D7Ke8(0iR"D.A/q@LF7D=f>=JNDoAVG5&
-%>7YOPbti$ZWAJ8HF.2Fk1&Ld,;]NMra%2(b"\2JE%B>#9-t2Z/T((Qek?^tZ70T&G'#+JUU@C&'+':ji)D4Zh@6n(;8h,'$0R?s0
-%k\2k<RYTN#Ce4bu=U.KX:@@%_:1C:e`6VLrW0D3fmpu\@/!FX<nP*5BR)@b"S3j4O:=6"k6D-?<lEE#-74>:*R$3t6-BiM[N'e^p
-%,K5HeJ7l;gi(H\.YqQbieN?1=3%,:VQW2Fqco=G#n=FVj>WafE#q.PfSumt\H"eU#pAsbO!<T]$U_tR<5%rX*3=k1gYXES+:#_<_
-%e6+[X#4"+62]=njhebQO7S7]'J:p67knc/N-@f3)#Pc2fk,"j_DHk^q*OHeud:'fr[T4s%WDmiS9^0uLdrh@D=h5lg&#W<l;4pN"
-%K6%U>%YS><&L*MnR\6dj<8slZ5LS+\hG3JF>I\T"D&_V,\@]Y(8.t1Zn.Q"+9jU)?9BunX+k<hEHqs>C5I#+e8F'LV>DjiHi`ok+
-%9P&rq`8fa[6fSfr)7IU6Wp?+IL/:=LcfD)^PbQOmH:LkMX(7ET86!c?hpC#HGG9g;%i^?"D^G+eqeE*W)U#HFg`>`mA:@Es`8f*O
-%p_G$.U6K`,e1/$?&TNsNU]U[li*3Qsa.UYl<qe?I7,$)E"+[h6r2Z-i`3-\!.V<:$ajIqDa%"-c1>T^Y11qa<-np5"`FPV+oMFdo
-%H.3K_)"7g"\F%B48_/2@Tu`,@)r*(Zr+O!K,2#L7,oaiXPkDg'T/<3d1AQ8gbBq\^dgSs8gcSJlZ%oQF+0Np$BItR7>_?JTKRF3#
-%GmI392[t+%24k7?:NbgKG^^XCPk@E@Ad->qD#&1ocp2dj&!o0$AhV$cQC.96gVe]GXEC4/<0loChB5"7l6b;BWeI'q2QQp]0.9>q
-%[p1R>r5I,Ecj)6+l45,XVJ9]NN"\X2g"tJ4T)%J!r&W":+#1G&eaer2Z:##05!i&g9'>[QnN^1mJs.'"fqr+*W;UOeDK=@W1-WA_
-%OK1;UM]k>O!fEK.8qIs=ShpXW0D&EAW<&'sY2@BP,N1b]6VOuQAMAVS)9eI`eMV>$n2u_KYom*mn8#rFO?8AhF&RFlX`Urc?8Gf[
-%FVJRDTQG<n0cB?n6Vh#VlM-YpfNZi&a(gPbUM?F^aZM?,A74\3"Ms@e20XlkL@;t9^MS<7F+=7hZSF?ZiPX/k4MlcH@jI*tp-cTg
-%XkDO!iqS#u#>G%.4%$]JR/^H'mC3A-TnFrlk6.o_,'*(f:O;N<oQ5nP#a`CScXj`$V'amS&S@PCF-3-3n@qO^#e\FJOT$+F5l!V0
-%(2<l<Hfe-Xmf^R:ckPR"d)BIe\fI:h$&9@YR"D27*q(L;J?p!(1tHmn/;sEc*bqoQ!"Zu]hYF7X[)6q(<*O1hQH)@9PmU[E")C*0
-%V_MaD(iAcM:hW6[K;rc*@nHoV.aK9XPR!p4e6T\6:)&Kd?NSQ0B:+&^JL_l!8:.!c'HX4m6dWL*jT?FJ_Qe4mVlj]a$J4("Z$?jf
-%p0(p@_)=&6^faA(KG5k50)2T%I4W==%\!tKIllPFknRqpD]s0fi/@sZETlNr45s@=+XlTtd5tGj>R27bYYS'jjb).;XZh]"$0"N'
-%"(N2b%b-$,&Bq5749N'ob&]<)[%E%f!;>J;.NY0J"ObeLWU.1**(To4<>fn*L57u8]$Sk3-;kYlD$`Rtmg<V'<HF9A3dQkW[%\iO
-%+]<ufJ8hkKJG`.T9*VrWa#)'p#o,@W9TVdQT;ub*k[YaeJbinq,`)f_HgEco]\NcG8g5,3+LuR8nf<K%66]C#8X"8SP%7QHY?lJ`
-%=W#QFO8\:#/s.Y_%G/RUCU1G%W>#pk/r""+^/km_3@f&VNi3Yl$uffPUrR,=7@-.6?Y+Nj#hb2nX:(a7<*_0Y#<G!!,B'I>L*<a.
-%L*gX]BqJcfVE4>La%&4"*hoNfgt[QAEE^"sjONEXoY+F"XC!UI&D`=X'qT+n5B[QZ/\"m;rBo+S"?uD:d)X2%\G)D)D(^u=Dppe?
-%MGg-IT52ui5h!WW#W#l;%N4l@;sZ*>^&R?-pPGsQ=Zt*3#l>&`."p7eG$h!8F]Ra]a%s\"@;_HWhs#ObOm%0(b+KL`.qtd4!246'
-%DL?YjS79A]88t0'-KQU?VPppJ*G&e`diY:AS0G%]fr)VC/7PQ0ep#=,e9*suB%IdXTO&?,72::]pTsSt:2iY>X4N"ZmJJSjN/+kC
-%oIF%rOT,Ig(h_8FlbRW&H+L8Mib&6O@d3Vs%#.?A@9D363KS?o"BrGc3113o+7$1<HgQS]aY\s&$S_D$^$ZL6c8`W$Ge^3X_H6CY
-%nVQIPQn3:%W5:j(A,$#_CD_JGSAp@E*@c!E+UGg$aldsaU=Z_6;kdQsj.KpWVr8*4nIfEs.\&5A0#K0E8bap1^SriF)9f`-$h+pl
-%CU+*18G`P7QE$<,H&%JmU[#,-Wh\I\`eL`dLcmA?AW)Z?hNctQkiF"X@C!=*%iKo=.#i4^XrTR:mE/!'HGA(d0M%'h<Eas`VREK\
-%#`7qh7$e]OEQN<:XYk.2Bt7TnZ(P0GFNHVAoan,;iJ"B+IBp$u-GkIfE,m5;Aj,Ghm7%FpRsiK.,"&cY3;(&L'S'BA-6$KGAN71c
-%<^gG0miD5OGZhLYnZZr8)8L+0E+jP7OK?SP''GWF+uT0GK^<l,qO)UJnm?k92+`X"DM5eF@puFTc?:"#i>=Q:Z$%blk[3]#n.Dt3
-%6mO?(`l0^-E4WeT)+WSOhDnk12QYAdrm0uUO,VK*HB+p6,cmI"rjY4'eB(2hrpY<d(p6`;qdeq)o-TEA(PAW(rV3Ot2oh5QZ=;eO
-%@`\$-0_fnRpj*A9<2E+TB.bdNBkNB?(o.1;(GT,JZ6K9u!^(pTXimp5h!-fGW!tOHJn,l#j]=MY,s=V^:md4K82AG`,l&i9!&8B5
-%rhoMfr';:?]ssjQ"ij;JV0c2Go>Bm4W\*oAY%dKt`RoMrCN;.CPn7i\_UBbpfq!cm?;+o1U(!XDPHmIK)%q.QFa0UJ"@*n-BL/VV
-%ccA@qa#ifORBd`m,K)A<[mM$,GFF<V4&'#On7A5P4>n)F10CEXS3K]/!Jc%?5#ZgTo;m*F0Rfh!7gs.[:!'fkQFM)]d%sFS$D3"Y
-%@b=j30<n,qTt)j*gd[#mS5Z1@P?rWHaIN**Y=&!U#<OBXO-Se%lZ^!^j^O)E#N6(>@]R<U?SqDV!on4/]E/!>&Il?DYtYNa;H%mH
-%kI)qaPfRa__3%uQ3!G[hJQ`SE`HI+#PpC@ZmS$\:jPKN*da6`H:gjgOU4qqN8Q$OH&Sl_=)$A!HD]AY&As#1+/(UYrgU8nK_Su!`
-%%LiYX,l("o'&ehFdMA/l%"esT8EmC\2+oM4;L;%K_0Tr['G!QUYDP=,Bn3A&r1UV"ST0X6&edIm9F/BgP1Xr:X7jZ:'-U1i=:%fE
-%JIlQ]8T8hrLLjE?>LN)`=M#(Igt,-]ek*WZ9!YNTA9Vi(SV_pj=EanJW!K,-1Aq?'`]ZH:=C$iK<%*74E=/=<e-K)GCA@EGW%,T9
-%/SIsC7@tBoCck2oL&_Xh0;0bM;9N.<i3;2cQa!1T[Kd_n&$/YIng@8G;@TcJ;jC8nrV*LOPG/>Dr;D3Gh1[j.06<X>+#[M==BrI8
-%!4Xm5o\'!)r](T-,i[6;Z\m!;gssuZrM']56NP'l5Socka!5lW+..%u5uS??npmB,_0H[r9p&a]k.,euVoD=2+d@SV7\n\C$n)=P
-%J=*-33U)nm.1WgVT1kV@8HY#;/!aU1aCrCU>?Z#cl@KOt:;@>435S?o5%(?]7jc7-MpE(/$^7jTp%U#S+>(ki9O\5A;)XAo>`c:J
-%/Ns"=_.U<@0>eX%5KkR:I)E0H4DX8g(fS&(X/=?8fNC>Jg3/Zn>Bm*o[`_[iUT8ftq)sZSF!3nngKk:F[S>*_/.Tb'(Y/H@L58"S
-%@GD,"7iOX%SVk`JN3Mf7cQoAhN6`P7Ana"rfH*NHMe@tC<NVb0Z6GsFJmnHb&\,[p'Z2nb+i_H@;.Yt8!/tA`fab?^OSj](cHFaK
-%Eor-+)j7X6rsB:$<@"';U\/sqD\3DVS*u]hp0J(qG9&OU!%0JB"3V$o4;:=GYR_]L"q1=n/JHGJi-C8*Q?8':>coa+f1=eJW&u(W
-%5?#O*!^#LZ@Z\/CDHYO%UVNF)6^G=.E!X-fAThSA..&=(AXnr5B:["%KO>0q=L^fH`aXLR1KfTm]5a9DZ;^%a%22L\.n;`Ba!,<m
-%i%^Tr8X=l9hL^tU9\Pafc/hJVFoO3:BB3r#KD.lpgDWP?ER6-I)5J5@U,7!/4ChMHFsE5R=?j@E/Nb'2Yc\g1DP^T[MIL>9^L7O*
-%!Bc*mSRDdSK0dDZe$PpY_T37%Am:0*e>?JMTt6L^`^chMEEkgYT\/pn!T`%CcS/&VJjD"m:d6^eaZ_m37lVT6T)l54`.f.;aqX90
-%'<<&'UGG*O'ug)"*^[jR9"<d9)8b:g5d`?u"a[oI`3#TM-jlK%C$Sun+^_kj=$[1\[D3dA%d&;(:Z*tR7&#>iG`eo%1SK)#A8-q$
-%oscAI\[<lj_F:GCO8G`.'ATETQNYr_\i<-HI#R+FYVLju@AF-YV&N55KM[ioHV?iU*>B:qGSg`m-r*9A`j!s=-q$),$@dtN4>tN[
-%ficS*Y75Y(90ZY`=Dg"pUNsa_@Np7AO8#M\*J`G:j:MEe_$CR8I3CG48;P<ca5KQi)8-WO+Yi^nna9,3?:%m"I\<a!.&F_k$+!Br
-%`fF\CEh8lcb(osK/m=D%IMMko]i:i]SP;k6]I`n.#IdF(W[*5ZOl-I`J<,<_kL03X8:`c8qOr.D5-tXMGCOJmOGDF?,,5d)\QQ/[
-%W@=qfH7Vgl;J6?f2#&=-IS/+lJJ[qSH63<JTJoYsc$b1q'h4KE;q@!SQ<k@k=O?N0Mc)\<.3@EHoUQ,1m?4<B0Jim)F2)fh.&#NZ
-%Kn]1*Y9[*l%iG35\TDSO*CblF2be47R)9WJdKg\%@<-:)pYj?,ADr8%lCd5c_9gOs-%TX("RR?Q@1RIrG+:OX@3D[$3%,sCW4Q/@
-%bMg<Wn!,M%g@G_]:kVgc<Q%-b)Khf+jtE2$2=b/-+G"+@Z]PZqRA+L7ch.-]5D54/q-7Fbk'kaYM70Q<8l<oBKd,n(*B5U6O[$<Y
-%#:%YqNr#`GF1qC_(C&?Jc^hiW'FLtN66A"rO+U)t$s[g:\Jqsu;lCC+Rh;=2QWO&?k0%P$+FZraAc.PH?&#oZ_MHf?fd?=:-!l^]
-%#5#.04uF?:B$rG1-A20K-Y:i[:1;O1;YO>@.an/%=8S>\j!?(j4GZSKN.r&VWWcs`^K5lNc[bP<iP_M'KtIq0;n3e3!,sta5c35Z
-%(ur&d$tVeG4<SR$9Q_[RF2<#R#G1gHE34K%3%d+qC-BX?04S/+?4sHCcG/=oai;<\dGW`iO=2%K@t&^:>IQk*'.;XgDOL?#+RpE,
-%i`#*t>"It62Pt:7gc-%#-(\Z=?qY`r@4S/M5q6G:Z&bRMRC3"p^5,b8]jiBP[-)mPE$eEA,rR2!aEXB7+s)Wj>8[Z\3LlfKdMW%u
-%GTCThYHR\qV5.5D']C!!``t;pnrVi.*\-9mOh"_=1$%/NFkr\#e'.#,=n#PRd3R_1XW0?[U%f^NI-eS/8:u[ZW^pM%=5HnF$6oma
-%9-a[=#dXgXR"ZkrE-VXFEE<S>hW7s7g:bh!8tT_#AhloVMMV9M/6N>7i,`F<Bs3ad*'=)VD38SFgp_b1+=)O!6+RM:&`*D])ai<s
-%%m_+1@P&uGm0jDukh\JEH\$IHPpSbi"Z#ck0Tc?N)dJ^h7O5<qm0tV+Lh<@PPC,!Gakf(a)P_?A8=pBh%m$)r9D2(V+`X=s*esIF
-%Oeg_uZ/Ur+%&D'SD,$&\;jY.`U2jfbSirFhC\5m!#D<P/Ac,AR>FLNe`jW(Y!dHe;"4>['nn4$f.1%Brom$iOk^F2J^g'rk[@eU=
-%?k0C@\7uQ^T&jSJ?%m^jV4o4W$X@(g;j2jA3VU85P.eI"2-q1\rTU=*6LT!ELoD/GS&@-PVer'Al7'/LJct7;c:-[NHTus9)dAl_
-%*JT7Qd0,OW5d^oIW>tmQD'Z`#TXXfe0q"*[$D^RdBZOc*co(DQ"4o<^<KFuV>>UYhh.#N)Y+G5Ll^fhAO9K/b.FH?!0fkJ"JKb8f
-%HhS>Q2"'1ljWDbl*GRq.$bMl>4"N0or0[V-pYuh#hH*[7S2S8aUp'alY,T0TL.(,'cdYnCVO16MWu5bLF?YV>,$KM%JfPl"fGf)=
-%eO?/kp#lo^B]f/X1.Rsd\r)+`mMpg+bu>B@Ye$'"WSVq/Q"T2MZG8B2CmetA?CBl?:(!5as/\(7!pm*r&Gm@<>9t_E0;_\Q`SQ"t
-%Ad(D#`(e(L%YI/m1JhA70JZeh$Qk!U<X?*5EAs(d/$Bmpj,gD*.BZqH?r/Q%aj-mIL7dcT$75ZVD2O=N6)d,eBp'YPqnbS6k--'s
-%MM]^OWI.WfeG$"uJl]Rm=Z9>F3N)bn>:(Pa>Le'cCG8mn(!lt2#1FQTSUl/I6p+Nk'VfIo3t2li":XT7Vs99s$`MgdPf#V[+=l]R
-%P@V\.?Kj(0[h4-5*Gq)p'mNK^oN\$.pVU>+EceuZQ!SK@i_aSIMT3r]j"QM]l4hkNEZ?f?.!T-A0O8*=fL<7N@&$`OFp][d)'PLn
-%Q,=;nNa,=?n2u60V>sG43BKD@kE["\JIn9i"L0.=1o]I^3<$OU!mS9FV,1>l2'?86%'inl-[DrKW<Ung)*#+)?uG,*1c&,U'lSkX
-%APahZ&q0YQktLWQgpHGMmtPP\bRN^G.Tf<iW?Mt]BKTffCVd7>_O%4X..mqQ1ad@+2oj-Y.M=#_^>ON;"9-3Eo5Z[m4Y7QZf6.bg
-%ZEt67Pj/m)""kJ:mAE!7"_gEY3Ng>I;na"\TtL`r1/I_BoFXfd_`I3S;rF*\o-!f]2h;LQo94eh_lkR_F&<YHdE,#s;sfl[AJhBd
-%.!mRMTkse2TnJ5((*+cDZ&l!A:7G\fJ/.4B'Lu)*(C&Y_!)!h,:L)I"dA;e.PB;2.hnT@+O<COd_q`TN.jk6r$ltlbRUbKBMeTK3
-%@fjk\_ZX'mS=F5*lC6CFrFk+s)3!!]CW/!LCHDh8c2Xe\qKL3#Tb%^A)+1Xs^n#'j>l+Q#-M'?Ie9!Bb3tYr=3Uo,(2T9a8WGe39
-%c4HpbU:n`>7Q+6J$Fm?iEto8K<CTiNlF0V%]p00OTCcL$SRafl2@B:0YeMq^l%ngj#d^PLpdgN<'6*:X!@2o`&.ZV[Mm++i/A/+N
-%mho*HAi7"C&^6X`)Mg@+EcQ\/iA4mXk&!1mE,FeiB46@/ZS0fj&T.^KkA2>%@+%j(a"V2D`Ci-\[AqZk7&j\6H<.'7N#/BA1:bSU
-%ikW!5Mlmjt&Rg)]EF)p3K]X\<hl!qd0>c%@T*'OH$mk$nb4@?pM]IG(>i2jtl9rBh7oM:'Xb/bH\hqQ0`#b(!$Z-o;4QdnV&ljgI
-%m$M5DWQZJ9@HS<+B=JO?U.%M@1?@\=[\X;I>IAV#kd(A)#ip$%Z\_+&>0fTA<.6^TX;"b8^s`E\!F-,p`p\P-N8rRl(Vaj515&C8
-%NN0r^C0Zl7*%H>K1`e''1!`]j;A;]F(I:7rLT.kJ)E%:DKg77,UR8<P]'bT0+/k8F)"gmu"(U37OUkV7e7%oSQ,-`+C_5I=]PiNF
-%j1J&+EXQM\UFS's]2FF/Ma$ir,,@D60=&]C^:8fH\BEjn%2%c5?s/CJ<7-IKmc?"]7(n/dNtM,cGRo19Z\>.-4Kf-<edSq.hLEU5
-%4P8W_ZRSYo!_.P'=m1SdH*s\@^*q,$3j'R^0N^hAb,poW6q(eD66RP)5lo@V/47MaYnb@\&3rV.$%>`kX;])4<GMuj-(^UW<PO;3
-%3aJf;7?in584uW)5I7+XPV-CqDn2<);#nb#[!QU$$uj>$T2A^>/5nib$u_%\'@`bg%B`hc%gRoi8f1%n@7_kL[93b?)S<CW.:ArS
-%N8rW'qR%?<N>C3lqE#s^P9"foJQ5BuI9=W217d&dYVj=Hfog`Z-qNs/[no"`?SOQ$_)6q,"A.d]S$NV!AUo9VRDb7+E`"_!H<eF0
-%bG]7u_XR((J>F-u"8L]dOs4/E8MVPnP?^Zk?7!E4Yjdo.`PskE(<@Yk:nlrTmO(2.b=#tIBf(3*FFNY\cn1.<@FH@H5Z%q9)mj4(
-%fTLl1+oG6h"9WjQLoU5$]ol+&3r*'+I.VHsRL\3NZ%_]\L4&M>F;hhTi:6D&4$-r,\I3)%E%n-EVd]'eAoX;FViF_,ernfKK:MFU
-%]k&sDVfb"ljG)>OTiB:C7?Yapmt(0(Fc?>?#GMS#Eud*7_kL9]2_(%+U@2%pRrrDao;4<Wndr8#FVoB$QRdbLKAJPI-0)3qD'[kV
-%=87ga6-JQHF\7'lp'!ibZ(ZV'bh8#a,dt'.jbE-,l@CpYE*F<OC`A?PpJ'-e<OH<jVdXj&L@hd!Q_fk0h6`m'?XTm<$f)u@J^73g
-%E3.^/1e/ZG:E>C>MCJKD[/:Y"C[;a8F#!HJ8OrNK.8uB'Ku7h/Qj5/iZ`EZ3')Ft`QId:/c[?)1_0k:+`bkuiDSc\ijX)0#9t=so
-%Br]0@B%KP#j9/n2`Jc,i[$/[Q0)#hM%K,u1]h3f?j.VNJV][eW`\=ffR-KbjMtt@qrVA,gXdic6#TSVnpsD%XMpp9+1jXZ_Y?-KN
-%b0W6T#J=u[4Y4.+<X@p;ORFZe1RaO)]Z&(rh>7RWBL<rWVT)unHfA/U*<66fh4Z,G[Si(hM%HNDZ8#p%L<"\ALqt.`'Ys4%qOW53
-%.EMN;Jq5-"pTRJS:=Vn/M3Y;B`"=jmi]YM_nMO4cG0cGD>1$Ni);TBn&?M,n;<iGlr2UP0SZ5#pWBBjD%."IiF,jm1s!((H'drdV
-%dlc;H:pQNlnd)Z`f[:>H.k*A5I^.V=,a;h,IUn06@]74HBo*rW)4O=lP=CQ_Ze(-'`,W+a_0/i.@qdVd[0H`I68@Q^Kt*n*RZU%Q
-%2,BA0E!Urm`"u6)(_:("/"N)^7n*agX!WK=P<KN$+94Whp9Sg<72]Q:4@]lF2&8O>Cu#Oodo"RW8PeS/)V;e'\B<M&X1;Rgi$_FY
-%>,Z`5m*<FcH!_U\\sG]*\HU[V$/EG>F6QYc%,@k-\fmSOi2Kk(.W%NqT1R.umd!_&G\utVo`S!qL<rdkm>!>BAMK%.4:K'%&&A"W
-%$G-.PkX/41;_VH+;a2=H.8T)gjPI3'l!dCsEQI^94cl&]#_*Ds;H7RuMZCiU)bBfnL'1m8H,-P6T"-B8jl,!I!hu#I3FhkiG=Udf
-%`d<;aTrD9.mPqJ6=bk&B]CL_tXIH;l5tO0Gd\]@]?[fRWFf5"4W58o>M=;N_VFoYIWSq9Y."s)L]:4DMhe(dX=cjTFTXOp*[[\oH
-%:EAF<,Lgk?C5#8TO7uaGXXE4XDnIDrPg$Y38J-nr%iCo&jT`%ICWMslP2nPjXJ98*Q%j%_!@pcb_#-bOYZN*0!t:\r_i8f-ZA.T/
-%@/OuolmJmS#P,ZM^i3>/WrP>$*2o/kL-0L;+1PEH=VEt&LA<$cJAI'k^D&OpaHFadUM\VtLF\H\NrjKoams?m#5\kE5%HgoE_m7g
-%RhZ[G,`/.J,=F5%6u[ks[3W[g+B\^M-lAqi8#,ndDSCNtbYJaKXDr'F>D"jpKit\YkW9RF%Qd!2pf"qu'o'ah(!2E]#L:mN%CeBM
-%A7-u1XL`WpPBSBZfD:Nr@*CcOMPCuM"@Mquq<Om;e5uN^!/*#a\Z!G?)oe'#JRcO]FA\[9X&HGCoa+`)IW9'7_8@uUmu87G#".5K
-%JD"&:+l@p`Q:6qeEH0cf%c+?MOhou4-*\7e)C#(EClb'oBd(`F7ZAXR?GU)8nei`#TYG1,2%?UFP*1ZU)2K.X7JO6[]%'IU0-fsp
-%R[PkQ?7qRCh/s"FKaUU67I.7rA^OU2q*q!`-Si'n#U;4M\8[U@,DHMBKA?*:]\ZVX%-%K-JZ3+\QsP;V9il(u_SZOI(q66#&b5'[
-%)GG_@=cIs]43=G42s5=_5#ITN,IpHCNXgPME0fim?Sr/t`b%Lmc/qb;(I;<C?'9XP!F(5Z^Za5gg$EaGW(=dL6KsHJo<JFhQsN9+
-%7dlsUjr**LfL,*=mpR%5&?2AJ%Bp"UB(OI5N]'-NDJ`'PhS:#bF9B!!K!qRr77^m:Icj9d>l'H,PT\/.*Vg0*eP:*l"]%3.;kg;b
-%h?Hea)EHOBMrH]HiL^]0nGaFN1_lV8kBA!.H@^:_X1H]Ak-k)_mkZ%>llZ#p\"Z8(/rON07>J5QCV.'<:d2'M<Y+3#qbmTge=YT7
-%jF[Z5@lpb3"dIYsU[$%O^.2*4a=R70i+I3Mda7i'c=js(PKpP?2F8QQR)LWkqn3FljAR^\*I.lP.J>a1dI[E+,e2Vd0n-qlnd$a2
-%Zd7ICE^.?nC9[d8,(;4Nmap(d1TV1GeI[MOZJf+4lt';-eD7nbg+Y?>h?Bm*,2QLPC'.i]!>9I=N@M#4MTb-8[SJ0U:s_3U$iZk,
-%a3<DR'<7-6JYPV=rYC<Q"MnI&^.i^d?TnD'J,YA@r;!Pr_`LL`1/gs^g4hm.4n7P[c^RZ)<hh,cW@!%5>ZY@5SBj*`7;DhO_VOgt
-%%)"d@7n:nTR&n"XG-7eOrGe_>[T,J'C2,4E"<S?W#$r2K5<`'[Vs>A#-J!`07T4R#qtfpT$pRoa*4EZ""8E@M>!:>Rm%+;r)=T8O
-%ML.B'%iFn`MoLjg]/eY'%B=4-Jh8qIAlY_]H?qrE5Mha#Q\Ts,m:bK]nm)3lqk-?(31%ZSfZ;f"%KsH_GD\[E=hPX/k<<T=;eCP"
-%G-<,p3?$n6l/]&&P5%IoR'.\IK&EG])QSgTO^fR2qW8MVC2\*!cgG^QdsVhlU;0*X_N*_T&tG>]1UK_aT_H".`$PW:j"t._M*2q6
-%&,cA=HLALFr6h4G4qX?3A\#%N;9o(0"s7%mbaM_sE.7Cn^_T5KouVaQYFOUrg8.mcW5<L;.2](c28['HULMQap=fh-AicH`e;^&^
-%IY!>mX)o,_,4T#OkU<`/1&D:15+aMJPLqBJ1oskZIHpEb?'"c(b"jCG-*HIP,,E6l$;-g8`;l9X(:5d7P_OKL\ki,I+5#/\"L2tE
-%:VV%Dl8Fam4\\4.a(*e_=d#"<P-GQ$&ALusPN3hJoLtE^?HuEAEp;[75+:Fr(!8it,MC'.A8+38[q%f+NLMqGJJ3MaeVTm1`@0`^
-%8-G/FM.o<!/GRlhDo@k<f^u^>1m'kd,H"#OpWf*.pP2nE_,N)NGPsrZ_e`X)2Lr\eR8E/0hB-$VYi,\9?2K<mT8r;8D$2Z/$I)Yr
-%AW"mrSF956i(0EGbNF/EPMf+ZLm1V(JX$D4YWS^[)DB(8Sklh^@_Ig5'T?;Ul/8VI11>tJ];oK,l00jkr&^+?0JnQRS33S8M=ZG&
-%)1qKZ_RJ')aaBP-RU2',oFcU8<gL'AXJneq-1TNKW6[[G%u:*)*a5-ra1KM$CX;T[fbo^o6dpQKAPMae.)h?%IM>[9q2@ODBTgU`
-%s8&5R!SY<_>_MuJ'r1<0KEr`VHp$&T)ps:$S>1A#*@^6j/8_)U-JZ_McgdPR;eJHLWHei_pIQLn.3MsoVQFiA7i>q)dMD[je3J)n
-%$>nk<7kl^pQ/..A.8LcS+8om#`N4s#!$mE:O%jDa;Cbs3BDQ.6OI`.D(c"FdVRP6Y,!MgM*t+pVG$a_olIm^IZo`g7$38AU;"j!:
-%U,r6s(*s)&(-UAu&3t+*nu@K2W=b6%al'/c-F(S2I+,n/Qk0(t^\HcqWp"P^HZ^Q\YTf/7WJPZu:Pk&,0LC#O.j$4RFpO3ac$:9]
-%?2e;V@aV4q<a_^G&V/mr.4O^"_U)4cHLDY_&kbeanB<eL0$*V/B6MJs$ga1Zj'g.GpnZE<dh.Wq4M3:qr:T`4J$J#61(eK:8qD4V
-%_g&iLll+0nmrT9hS/.\!8[AM!<8I(>TXoH7/7BXCb#PD+ZCHO'0;0%A$1b%B2XNYucgIk(g/n(_Mkoo$cBLmAD>"j2e)g8qhd,Z-
-%l`r$,D5W.e=%ZSiN`?+UP(6?D]B6Z;0XC4?0<_TS(<htsOg@CD]0ln'gc6ek0Wc'$YQ/RM?/3PXW4@\hq<_:br7[(c?7C[(e;Ho2
-%7OpA+"@jJ]<[XU]1L`pE$ne3eES+$n"?#JdmiD&ZjY4aI,%#B_.tUVd4`j0KaH_:S"%jQ2;qJq-?hZ)TT+I_`*#J4)0a!p"f9gVH
-%ghOaY4FJhKN0/)!8f6%1J$d&9q0CFqYF`.h<4$(FL8)]ToC^/)CU5MUNoMl/=/"YPKYSHOC/s_NoH!O6.1^IYfNc=&!D#,Cr6q)s
-%aM[YODM>bBR<4`@btdEN@5M6r4u.5.%7;UM!=;qSo=9ZO#-aD%<]RO<*WU%GFf+/<SXOQd7[AfugT2l3^4#G4_ps`<<Gg]&!HBs%
-%lLSs-jkF<7?=,cC3qAg^n!ul[3DLA=i2hMOc5J$m,m+XSC^@!,M%iqR!#Vem^!1"fGu9aHkh_U.S]OK$24NAKrW&uhS#'PV@ED.B
-%PF!Zn_<]m/Y?OL/i(N2YdYp:Nl@L_-_cu?re8DjE=h/njldGs)Cqk.75YZ",gjn_Brf"O[>m&s\EV\KcbG,M\&3<(&*n;b;=bspY
-%p43;=jl#ZNRL;s>UuHI<[6eK%WS%.5=-%D?.L:sRQgiYS<G4_3)RlS9L8bp[gCfM@FR,<!NiCHK]%'TR9.-\HXYl,oF/6.JiIKQD
-%R+%).A211rnu,4<p?aSa\D\Ci!d\L4*kk(tE*M9O5g>OFMo3gm3L\_$Q&5QJOjCiEUL0-USX9d@H=.Otg:+)X1R@F]Q$]W#6OK^O
-%/UZ19@t*S\_V'YPmp,hFRBs3l5d%tDVjEOA!N^LulMCCi4<5`ics'0PP#VaE?ch)dSpp>/;m.tdS/n-t`\jD`$$i+V<7QY37Pspo
-%8,:W:>p;iDB#Q-^r?fRQP>rcEEIl%0f^P7AEL.h0SFoih,j5h"]KbT"K9Dr<*eK>"-qRKp&5Eq].VVat39-b*,:(/=\g\D50mo4.
-%P7$6@5<qmDb_>89#e/"b<E<Nu[7p9\?+\/HG!$n*RW/?p]La@MG#FOr8o:n+eTmtd=c4fqDGQsa`1nF>9bH/O4KUN<\.`2=!Q37?
-%+!0=a-<\Fpj`_cfSSoYEe_hCB,0COc[fG:k[M]JRdaBchqkL],NBe0/UE\\/4QbT7n0T#='NHVNb)Ra4&ZV8+bFmRB*#K3mdeN1(
-%,:rGdXq&_1`N*G"<Xn$0\Mq9n[#1=Y3K2',9+YQVU4@72;rTI61Equ(`c36pl*6SJ7^j4mChb1oJp#!ZMs':AP4^f``K1Y.0N>Yr
-%daB\<_9@I!FD9<L7\hiu`,JRrQ)BIUT)8>sV'oOSb[n6R&>]5'WTo_U1#eDRNPI)!YU019=c4m.IPI/0RUUr?&5u8cG-0//:%3BH
-%Eg=ER^u).kWNt>2.XDdUKoTEh1-s#B]V::5CGeBJq*!_;X&sBRgp-3<'bE1$KX2Jg`bK-R.SIAb5Y:i)V@]-nYBimVIhEQm0nkH]
-%,7LqLOt`OPU/hsg2I^*o+dOE:N/phaQfWUhM(DqAR)@iZNq2F75'g6Yl:=BLVUoi'[umi0mTa0G`fmPsY0Oa$/@_&L5.J%=d?c,6
-%(J&^;SJ(CMp\PU%_/uPe$!?cf-s5c9]#glf6Dgd8b>Wd'mLKRDiX.Fl8d>=s,8O0>^"LFG8V]T_r<Z3R@Btur7&]f"UdHAFSXr/2
-%=X"(EVO*d$F<@Lm^iZ8IA=H5)1.d(s0]V\6Mep81i^KN7S)^9d#:<!OcC[fX4\WPO(h\\?q/eqZ*fDUm+B;:[C?+>U^M#HT(u%aD
-%?"ekWL]>b*mlAom=K*%4jXs_:/=V]g=S7fFP(Ig10&URO0tJN)0;cBbF0-t^`><V:=L"!4Q1Y7FJISi!FTm"G$HKbZRpjRI/;847
-%7;s5Wc`qZSo\?tL*#W)=PZ:H'\&1u;r3Gdn\/*T[k$6H$N5oQ2TSV?]1r,uX/J>#br#@54f?nae!N2E.crm$i:\&P3\q&9u<h#/E
-%N$L/dY9QVefj[rnJ;M]ijNDpsglM$;\tTXI?/uImQ@rih)c?j#UIknN+Z52I8o99-Me=e:.a_rZb_Is[hVmgRksR'"%OBmPB99R>
-%:R?>_L!I3McS#h+*agd.(!KZAZ=49l'&@Y1,%m:Y_8*S>"0XXUpk6Q-R7VsN,*Ljb1<;1KCaBZOd/.e.M^GK[a%*fRS`"B<oU!UX
-%2gW(sROjA+GsT1q$nqE466oh9`*okj<uoB]Pf'i*ZE;r%CST\riebWkeX?:[Q,+67MDiE%F9_6rYs,arB$!YD6Hr)e,_7>a'btQB
-%N1n:+q2;]GWK;m;jL+)H0+IUI;UE5>L>6!1bS3rg,bImr$u.k&J0hKXTEtj@6MI7T!BD)"9-gOH7E4B(/ZN6]6N-Mo>gGgrPk;\Z
-%9hnsD]c;kAL]>;VB/P*mq6c\gk=LRH&)2URgcg$"R6"nNYOeSPImg77s-lQC+d($Wb'Hl"rC@C$>*3S4E`PmK@hCs8#+b^)5\sHs
-%YoBQ;QjE'`S*@&PUj"<a<[?CO'!b",OYW>;&VEZ^)O$b#7d>a"IC_n2d''86hkLT4mcX(@SY6t$$<0ahr8-n7"lAJ^3l8Bu+eD';
-%W%D+r`8J'8SN_0*[a7*[oXAHJXq`Gij\tSH>SrX7ZdZi1LJI-OEH^8^#ppshcgVmAG,!,d80mdi8U?>V@96T#gLt&u^I%-4fZj*$
-%*L#%Ni&C#M(T\(?N#X38Z2QILqnM>V>@kDt?rEO2/=bK,mhrc1D[lWiW^pj?]_1bN2Q<\Pod7oS6LMO'c-P\nhbSuIqIl"%j]9hJ
-%XahDZ:\'"?l@A=-i<*Ssf[LU4:oK'k6HX34E-l^B&H&rH8Q^Zj=_]f'HkFE5lRI`aO*d))\5WX79n?B.b]?5ej^q%BN.[o)!hhDD
-%o\[$>?q5aIh^";cqNit?pj1`ua2W.KS-]U'1[c&Q,+N$:U7+JohlipFXt/*?LL(*U7aY#d:$_'l#@&F!'2:-tE8U/N#\6M8?BIoJ
-%.(FNkW!chrX_R@80S#'03ud!Da8u^I?DC*/E\9=q2_[X""eAR*BeXOW^TQ!$a1Y&O2!.FUV:@#%&)g#(QhWQ816aZVTV]JgL>(4\
-%S)+SubJU_1^'>kr,At\35kTHKnN>L9o'PoP>5P=,:&T/SM=i\0]LPOp5A`:>X`=SNV;=lihYI(m(h3!kUbRVNm\gf8ELOpD(CR@'
-%i"4RVE`9!JM+pp?Bn$17&6@=]RM,^0VJ)62\2Ss\+[As+C9t'^h!Xn,BHMB,JBVU?E$g\4S!t7fa\%VDem#GuA'%@aL3tTs)8?%0
-%JqLa=K3a3""i*Q0oO42\GtH0iCN9i7+B^tFW^,.h$rWbmj4=]@G^#tc`f;Od@7!cXSGa).$]`Q,JlAI/)CqtG;!(4FI-:j1Bdpe:
-%+3Ah-T0CTZq*]J!\p.6O8`5G5Ge<8TO06$#\O2PNM?%KoF"H5FreGMQgLQ[GBZY1-'9ucHKF8M&0l4gj:UK*5Lsk:e$<0)dn\O=7
-%<JDVsl$>\IeRT(H:A5gb]no0i]e7_/8<W9Scj1cd6I(9Tp]"glh0(A3Q7K3ni'6_-!NG$ekP\jS8L6OPfPWY%&CH/>#XV*7b<SpZ
-%Hup;*pV"S&&WsWThCOtC,N41._7=UKbY)JW`/#"bPc[Oc>=S'<bdYl\@,T5B;E'pg\ILD68F()[T?GU$e2A-13J)XBR;0t`F,^>^
-%fNGsH_3;-hWVdtg^7C^#!gY[Zj=SJS`-E28F4SsW:<?!1)$'$XP"3VVX(h012llDA:Lu#lb!'`5l'!]K=n>*4)k`+39cLC&Zi'fm
-%35Tg?j@/fg+Y[6o_T7m[Z%8gd12f6Y?A!6'>Q)[iV@&\*/KZ>JnA1l2kTB!J*i>GbN@_"bKVhkOqB[]:->[;t=m-Dkh)%/3jL5gY
-%2fQ0Mr+h]Dm!I#G%KDgkA<Dl;cYAu1q?;+1Z\,B'jG[:!pWEtnY?MdK5PL0Ud`bm4SETJ!XtPG:`t[d3NGJ&:84q&?ZGtm-$l&g/
-%[&>9%iJEm@c&*g<=DX0?)QJd]5u[qOMOLfN8KjkN'G*gc9r9rA\ZVm2_gELH$FS%jL(uH#AU\4K2)=d-Bo+j'_aIPK8k0g6$-W"N
-%OMlGMX4Uuh.piPRqiHBG*bCV81+uWOI7pmH[J>3(U8H79`XLEo^$RbM*UO[\gW4D)`6XSAO6G9*1Vr#$7#kjord&qKV=-R'Qf3L_
-%=/i.\e8jh@Neo$j=YE`h&r>l5V-g@k!-eUe:1dg3no)@U&[0Fo*]P?MYe4_IpsT)DQtCTa0T*@B<eJ7J9-9LMWLcdmohsi__[04C
-%A715Kc[rBnO4i>kG^,W,G*mJ`gL_?Oqc:/\0J*M6;Z,*);)/FJVNtbrPFY.sEo=DMk-LTF^UtZc1M-"ci[)U?A=S9ZY@"1@J=*q$
-%(/Okm@_/ZkV+gk+:<ZVX_3bNAY#N$qiD4^#WfhLo_2$9ni?G9\X&CaSKOaqF]]aH<?Eif'9iEj'">Gu#j`5Zs""Q=RZr.@9/o>.J
-%+M%cH3bBj`$aX].nQ<.3KmZb)f-7[^FkuBa*kGL^AXAM"aXDh.\be7.jRHEFOo7-5+4[etWA.(m3Z0?ap_O$tg3a`O;)K"-7N8>M
-%J@7<?+)a#33@=<IXKki+P>s1d7SY7dGhL3YKVE]Vr"Xp2Mopbmm7\7$aY7_7gY<8EVif_JOI^ru+iZ8p4?>elATP[MO`!)M2!AC-
-%BCiKP^[[M'q'dksZ""W?mP'F9P'mlHob,rjZ"%\CkUlesD07#ie)5KY^ABBh-SR@)LMCs(QX2K"X8iB`'"IkYe&[Bii[gFp:]hE&
-%oB*]B^UO\87a\_P\^*hBer:X`=&TY>T\oaQQ&IM8,7(KpE'YG@X7V)Df$pt%M(G"B#g%k8_U!*E=0kcIaHkE5DfM530p""T;dVmS
-%%(nr*?!:W36hbT-i2$\`=oNu4O"*'0p^Vk@Ac_46V_qjk7Jmn5VJiNl*3T:-ng0MpF+TG\>m(d=<dC1t\*u3`CTi)\!AFrkmgrJ(
-%AO@cdQGK1>,A%?":\FDq>K1e@IQQr/E/..Xk']89m<ERA\I$9%Ir?",1b/6E?^g3.#_]DO>Z[Qdhte2I17O2L`W3Z=P-H\$,JB]E
-%it&.:126FP1(L0mbGo/6Wd+s#WD(\Ln38Zu"fDB]/j<H\IWsXb'i!;DaLY>G<1;UIf$,%H'YEnu6FI<,F_;UC:[f.e(ke8a?UVUV
-%?Pi:BEYD:r9m';=qA"E?:H=a'ER/4&i#A]I/L?BcYn]pfF`Xc:NUuD>Ac<(mA01H,Y;KY#E<?C@ijB`_93f?k=UGs\\>];0/qt!U
-%X10gfO)saHkl1J"esX9qD(3/a%f+^oI#HgZc;5[7,)O=f1l.%"kd:gBj/s/)iNIOp$K2"RN&/Cr[slkNs/*]hl]:8$qpfk@b`(I@
-%D#%0Sr=%\1/mJH:o]oFE+*6-c5-2dp=Jcrr8m7S&3(qHff\nP2Nuqr`I[]H9>o)Z9&Au)K&Bp<=]s9:odVm_`P7@dIBXHs.Go.Mo
-%Mn\\k,+Sid1UQgFHcFe68u9E0,F?<!<2>SY0gc*R::>G0Skb2"(c[V5"1^f<s(ej>L1d'>osM/%o2,/J=k&=ck#IbFq-9e:1d0T.
-%:Xs7EB5(G,Rq]U$IP%M]AbV_rK%@V6rE?;a[=4-rja@SjqRN4fB"gH/Ud(I5icSeSWT',Ee]LrSNK[DDa]+O,.s&J+*E6lXiI\gF
-%TrkJGa\r'1aD*h][qE!ll2m4dIE>Zp>Ub3G?E83a"`LMD>LD!8;ld=@N$Cme?ab#MmhTlmp:EcDQb]^gps_JPlPf>O.+IXQB3_K;
-%U3<Y>9kM.@/).Yei>/oc[IU3r\b`_.T%@8Lef0N+blrUtGhYO..c/N3Z+]]SZ4?f&Bc?2a_*\dKAa3!rS#!cS=it-ml:MBSp&HpI
-%TZo\@pn.>\BCb\9cF?W)bX60_5E_214fO0"XqPR)MM9:7@ES`&-tM/.g(c@'j$&I#$6kf%R+:$r'$=Q2;4gY)S]SlsChQ#QAb.g,
-%lhq.?Z3knB"6/&+QD#Qp[BK=@R\E.ZR8jO0%7C.??`f6.R8q5V\mFSJ>ZV)A=!D&FD#0DQJ(9a.?$oa)++"W+[Qr4W[f1C7Yfs4k
-%R@h'1p3Z_D-5^H6gI:hdm0oAh%i/[^O`dI)A#Q^;fERu>VK\=C6Il`qH0&2aB2&i[gHA+q?e(`L:k%(K<T_34d1C]WVE-5ECQ[Jg
-%h=9>=\L%k0=Wqk-CaHHd*TZg>n$JlSkPJ#L;>5q?@gdG8I,FXb_q:%@rSt8,2J\D^Dd*i<lJV9sGNGkIchciFYTIrT!sAVri,J&N
-%Ztg\Mpr]l:[SNA/<"e!gcu]#]$sj+Y8XPNd%=GLsj6_KnhF><Ln\K"!TBl=^c#r7mH`S5>2.I8/H1"K=a4g5=4eC6Rdn;nd"2I9]
-%P63W`\3A&!Z.t%Qmab];U!@F*D=]kQek4b)btf^-^$jn0b^<sF`I1tP(SBF)2M"Z=9m2#i[kD1S*W+8)c3%@Er!&J8ZS'"D[,_,A
-%96QnjM[7ir6J74c*S9W#f3s*A`iA5p?>k=Ib_1:R<u(8=Z@)G-pADDelJK4f\?:(&DH^_T>aABK<IYocS)8Db5Dm1M?#s<r-0cK@
-%bA[TgWiDd<mM#+JUig):H`b!5[Iu[$HtY)7/2lY^Sicb+E7C102Elliq<r_olRg)cN_>H04)TKDDG@n>msIbq4]"IK3u%ebY'm\A
-%haP;sds%chqU9Yfr8GhC&Ztp-=j5fL('0QsnkipqH2/jXLL*10WH6seTWQ%W/u.f+,%'f4j0+JY1FSbqkOBt2o<-60pY,V%*54)&
-%.&FS8qtJeIY(41ULDI1\DlD8J<NVgT?@6I@AKK-8PM443DrlAcF0YOa<.[0g^7m9#0m=Y!K(>T@<rBC4:/nE)&s/kZVq[ONW?F?O
-%;2sqTYP,9)9Dc;DH#c]/H7l21dq<<_\Xa3PPaT4V40n#^QKkbQX^=$&g>:^LX%6LeI+%8FcSViaRj';Q7QBkSHl#W00`-4CF'J$k
-%V^f+B:Png0='O2][e/-nSUNa&B2NNrdWf)Gp=j@JiN(=D:E>I^7K5H=e3-?-]O0LEH(E.o$fN//$?D*<Y>O[VQiW7II[/`q1sTc?
-%-W(L>dC^7j\nBhXN;rjs]>*Ns=92_qU*V*ohQrF=]CiOND._Dm9eU#Kh3qRUbK!IiCHd[ToSlksh3NoD_/40Caj.nIft-<W`&^Ka
-%b4_BH.@R/QF\BOMro;gAIqH`>:)1QdBVf/sjS3#mG).T7orRBG1&@FShq-d8Vfg!3?]gt[0g=oI`7Wnlq;-B8GHFm=d2gU5pE+Mr
-%leCcoZT_hl@!PA4g7!ERqc0cYS"=ErQP$l$#(3D)`@tc:,-4MQSB5e&"4ee/Y(YPa'qLAnD@"`N4Hl^@#*'h>]\#-&QZI_DZc5fS
-%$`IAI/gr2=N81dX`DE\9cenQ[ISXqVYHN-!)F=+/_u$]"lMKBng63OpmG0PN[.eLpL.CrC[&9/shP+SXd>!*oihe=(G2f#JAG(TS
-%>21c$+8GRPF\:St):-D$jaI!E1d;<37sR-Q>Sc36cdh@Lr\CprlYoKEmJ=80phDQnpk]h<rYfC6h4`@GF*Cm@M!i0(;7gpI-'(^P
-%F\=X+3FAISlZs.GSW\B7j0cWlH[Km?G7F@A<t1ZF?F"E.h"jc]rX)pen#AN,e"aC:X\5OI-K'hWVF8`BM7pXGTGpZN-^287kc)Vm
-%Tm+;%\o0PfD+jOr9$s,b=I1E2]9n]oJ(aM<&CPLc)nh7qPngS*Ao9F(nPCmqQcXh\jOeP:b96f&Y+X$e]Z!dG=^mZ,=fg[Y!)9dD
-%OMtUlW7]:no1$TMba5_BTemq-P0]V_^a5re^(ISlA2Xmt<hGdJ(m%cOBO;3iK_'iq>VcRk^?*dMh^eoqaCtbAI(_)V@J%s?+Xofq
-%O\G<^qd_!4&q3rO:EOr]ZTV_36*6ds3>#Za)17+B6k7+I>H4cX(k[u$P?s(aKklEVR8T<c#"K+BU0`Ir)0Sf@NlZaX7s+b+o=c#>
-%bHW<rR!GRC/oY>E]m20(6#FOP!^b./)4!sl)EB)ViX+r4W!JQYNI[J,%%]Um].`!\6/TZBr,gFh-E@9STjBh#^/>i'`CQBgCTH*(
-%*"uR,S3uW?oB1Oc?:>F*DC9ah"K:tZql7/`RoSIs82,rT)uFDJXoo:e.aSY;.m$s676(<XXMMD1Aflg(e'S7GYI>tlCFeF_CoG?b
-%NY0GSPZ>BMSq<TRn:qhbi#Yj-puU8EJ&cpj,-4Gn/O.k)+H7ZJ1a!5ao%="JptW^PgSboejB6p?#\jiX"DheXILgl<D%o@S"Cs_U
-%$)gP;EI\X9AD8HJ3%@h\4]T7g7KBd1;bUQW5(3I51&:bWZOA`RoC6:Rc0@%4M1\-X5A<ao1hgK46ZV02=]NqDN>e'O->Jj:.tV\k
-%rF7De#a+CWT1.[^N!elO,g1RQWb@c&!s^'dA52s[:jI=2c/MdW/E8Z_J_V>jN<_/;]M\/Mp/dZC<=n0kojsa0j2"?IQ*.)u3#HY(
-%C-7lYOtF![-k,Uo-UV/<CenTbg.1'<j-Q.Y9:N<pGG"f>(bX9^5QQ%?rXpt/7cJ7.T:g$'p+T^Ad*H<MfqlT$g#HCn9$\u_rpk?L
-%Va*-XT"+RuGa#RWfHVRd<&j`oOjLK]=g5Ce/*./-YMD>3a5fH"o>7-PJUW>WrQXD*1D2bqpN81_$!cn#$W9A`r3d6>>\_A/[2c3$
-%,lM6YZ0@>l'ifSU\po>>@7b"am&i[r3b7?;i8k0W(h?TOL[HqZX[+AY8,u&aW\G[p/t%!?5H-24)U&+@];8`Nknk(sW[?JV9m&Hr
-%cF9d+CGH0oIa3(tX<Idh#e8*YAN.8LhFHg$Ht33jbAoVJ.QWc_`F@\cdoL;W<?n)YY3th1o5UoACYNPO`!8"^PB^?j0<Q"V+K+PE
-%M0je9"K494R.r+-XL?bS=2.raG0<$K^)Ofu@0k_2l/Q1]j:V?/:Zm-\V3K1MLG#"N;rGf,QdA#:AtLr*KdIXPAA,YR,BUML+k,DZ
-%.+K[@2T&rn`39;M)[F\^")`-@N)O:GGo`2,0qEJ.bmN"i,$FT=Ms)mTI#:e:qsT2RMs9fpP;2bIXq5f&4=3#-bs3gs;=rk#b<ku0
-%9\i:)?@V2#pb%\]H`RnO!,Gufo`S>2/lf#K*W^7[OUimFM+q7tX*qf;mmm#>Y,>]m(?pK^U)""eq4!raAt;3GfUpCdF!t_-Xml.c
-%Z2;93br%_e/nXY`4[tZk^n=ojMI[*`P_@.r8WGGqG+n^/eCJpB[llIU(=JIX(ZfJ@\W^AoRJ(-%;W"(;rncBhIW..SU,k/<8B'4V
-%^9^'$]j4\t"#'ki#Be=0ibhTtG1T[CSpKE-*Cb.-8:oFeM5b\l[f\hX[,jN28i]UA4h]62(Q)c.![=9X4._<O1@ak1Z1\*S?G?:u
-%B>VD["QZ:,:tss7m<Ye(fW]ujqCSuoX=K`SKKf?ll*^:p`;Qa.]&)X8]KkHdU:Hd[/"VV?U&`b[A+TX8]mTQu0<SlDFU2QPb^-/U
-%N=4Qp9R/gG&^l6DNio4(4f@#@aHQ6B^tO%QEdL#PoN\IcGW#<R]0/r"DHD0W0ndS'TDn@$j+9SmGOu9\m0VQ,>%Hh@33I'&<$,ZN
-%Y-``sQi"HLj6,GdF^Pr\KRLOFj7r8%@V#*O*?!=n8q)q+>3-JXK<&l/.HbD`fm&)*d'9]?^u$*'b.Lc5E<Tej`6,_(fAiNn193[b
-%(c(7sRKoDNhZg^3a7XQ`^2jM]l-I[_Vt+QC`p&3g8Z>KQ@U7/Q1:&"(0[:5o1uI]"?>$u9bGPSRaD3c;d.Mi+:A`O]5'8n(lSZ(K
-%>G7"R@HY,96%9@@dhmK,0dj+k"F@a8&rm)HM<G2kK(!5"U5a,_^XKlqpNUlM><??CG0"iTrU"h:lRmV;$)u$6?,dcV[PUbX_Db"m
-%hJ8cA$^3`q"Qjo/?a\LmN+:/%cWNEgiVgC+DE*0RIEln?/a[j;q8m!P?HgG)AFEIWI)4-!$J?<[q8$uVk4a5I'2QcB7iOn1pA;2]
-%#;U`,S[6__F9j`$-nj'*Y/n<fEIV^V]l!jQ@+#bTRL7sCpGCT%l.7bPJ<_+B/=7fQn.Xp+;/+IE0?a'[>4MUJg(N=INR`;LeQqb=
-%hHmTh/sO./+(niUQJ#QY/B'M1j1ISNmE>EVYIZuFkK(YFl>1c<'h(Ma8/"BTr&^@"r;>':lG7*.CbCjUDTB0@?f($QI7IaGaE(IC
-%=7iP]&LJY3a^Z.pZI1NXVcgWW>J/33CS\)K\Y%m&67%t-SE=^gYdqXCihtCVDfnD]F?pp`Uo0$^%:l0'QO.9FpMJ3[FR$@Hn\dlB
-%(p6DLgknP(.7p/_`o-N]j7`DnD^?#+;%pb;DSp1]GgX[r0(LL2aiJ\V]2ndY+"PY"Ip'`]Mtb=g,*e!b=abSU8$rgkmaU16H%DM%
-%+.19_@Ip5OT%H#iD4^[P*Th_oBqW&dNFAFMpfm^mrT_;/NDJg[$Q1aL5ULrI^7AS9L=HifAfO-"-EQ'mgo=aB5<'b&Z4s5;>N4aM
-%hSjs`\Xm_9,rpB2Ohl8QYTaJCd*F&[Oo7Xf6JXShZDd339EACZ.IF]P,3A[Nl\>i(VPd`s^SOaY+?ke"$sdq;IU55*ZEF_*C(5[c
-%OldHEd>_9V6Z8)$.R!<iNTq3j!C%J`hqJb9jaB58(Ot^f9;9>12LHk2$c_hq8&&[2G2fK(>]cpr=InJl]T7+4m`(*'s5\M)b=MF/
-%(9>4$NAoZ1D"Apo1Wp`NEShrs>=F=(Xs"YSG+M]+`S8#uiW-P=04Z34]0)\_B^JF7(c"e=FeSME-(NBEaR!,LIQ?(^:Y4s,)-;^`
-%&-/X$"%4$@RP.&3(maXRFO7<e)E\u^OF$M>B0>pjn+Y_dA\>D9$B7Cp%VL*UrOHB4k^-!j=XI;H0P7\9SeI?i?.hluQZ@Z,]2_Q*
-%W76Y2]mK#?>lV0O9ng6dX^"f`_l)Sk+ZQai&H'p6M[cS%[:BI`r;00?:o(3UD-29pGW)'qY[3um+m`+-f+\_.o6I)o/]2'KI;jdM
-%ZWgTthP?hhFR><J70t[;b-pWUnJF=(D[C[]+l5ZsoCOK3ac%CgkK*DVMr-k+i8edBbK<IDhX?.Adk$a2[O(S!0'NW=2cT.%\\<4d
-%q"gE99>3T1ZlSWoYc&?G%+0p4naYFS<pu'6)@hD&RinX[_QWX[pltATBT3qZJ!Q*Fj6OAq+4hdbWkUDTHH%e]bBJE!!`:AD<_j3)
-%aDU1/CR88sV%:;`hgH:Pc10T!^-=I=or\5MH`K@'mitO9dK?eGiaAg13r%8WoBDLHe=Q3[\"[)VJ<*uq4F%!M%O8C&$=/baWL4Xr
-%ZRI.q*'20Q'g@>!h34fkTAHLj*p*4Sm?bkghum[BpHc"SU0Ob'/%5E;(JlGb\c'ZCasiYhdZ:#/Ut8JT=)/9f`S&Krgi!5$p9P=0
-%iuo@B<Y`?<WWEPq;>P=&3ne_,8&T>hn\<j+OiID"mF/'pMY$_P7+%$YQLMVJ9-^t5?9+jp\0'b?8h9D%jCA!UHcGY=m'%(2e(]-g
-%lRt<O;E55Gf7&3bfCp<3-ND)@bgunJY:`@1q6!LXPFaLGPbOf!CP%N[:6`*I]rgH2kG\t6mHj=*-#<O]X`k/Mk*(5^)=gT&W,=La
-%:+-(U.tNcrBg)0Iq5E^D,c,n6T:C5,/"j,=N%9e:PDK+G?E]T+IU+H`\V5GIN]qPLBg]&f.i[G0Ffb98JS4F_e@oKLFBSK$SQ+(@
-%lLHr@,M]%Ql[0QTG[Fr0*V2Bc>Fde3nab*=c0siJS8)$^o%o&?A4o/'VhE80<"ZQ"A'!fig",IbN<SR*C6iBI?r-,)3u%UV<Fl2/
-%QsN[/Zh,#tne/JsEec!B&;ouPWH6s4J4tTpolT-/e+fKm`</[UkfJZE+,R@m/90M"!CucIYhN#.U<%$rjp9HAn[i.E*#EZ.#mSK)
-%\B#_F,76Fc`%;GY8c*=r:ZiCT'`lr;<`5Lt?04Re-.sVg4p$Muhl6LnaHtV8QN?Xn-s>VXJ9;M8lg.WYL;@*i9L@_Vfc7W&-=6uC
-%S$eK"N*0"KY@e&+'$N4<\tgfGr>DYZ^j05j@_fU>b!o+K8gj'9H0?/3j?tP\F,"pNjP,<Rdcf\Lj"[%4F'<#-C*:i:-n<9mfi51$
-%)TEM@+F"Y%;.F%U[-b(M>e_g;W4=U0bqp3GU7rXX5]0-m5V4Zl8*IR^,,)S9e+m;195LUmqMPg86@DW_;=QDl=/O3NTO15d!Zs.#
-%fil]MM[9;dTUT(\/fB*Fisu((&'(5i:pa+k%(K1.VDSTsZ>:`)*OL?k2'iuA1;<W'B[=(X<rFlEre<hdI*p)WX[5f?/(-mrHdC[!
-%\2VnZ-BtW@%#nIk[?jKDP.2iJ8rgN`GuFq6(S%4Po?a]a2"#n!Z#324nTFanb,/HFFc^`-[POZk5Dtn--Z;pfVBcGj*EG"tW<VNu
-%WIVf'"2)9BbTk;NTU>OS))\X&9?/Ru*YMR+Wu=QPE6lrnT)=u%p0H1\b=ZN%%h!O!0jOW<)c2hiHr:tWbhh@KO@M6fLOcr%Pm-MV
-%h?ma=\kLIXFXq7NglF!!&hiYC103;^(fh]=0D"IEh<5m\]nWCLlRJ`)Rpm6g]b^^TJRTXCrh=pkOu*oL[j#X</b=N=kq=4Sn]?\g
-%e3(AbX\;V&)'3Z5J[?hNZOJbe26h,*$8M$\,R-#Gm21#k"?DZKIg)LgA8LaW1JIf(Cu)r]Ukt`^JmJn_[:7jZ$7u0c_aT)/;!OGE
-%Qf7hG1>([YC1;paO-fW@^q9^=7EY'U?oRVM>O-C%l?SH,*gr:Oi;`kk_./Hk(SLD]Qq:CUWs2/\[-sL7kZ@<%a:*`[HW_X4N-LQW
-%EW%A9Df?)Zr$!op;$m=aQ`N]h%,.d+p'OQrG_70Z(;^Vqqtl!hk1UTt#-FVU*+FK@/!U.OLRLia3$DYKmsF:-=jrTXn\199%kfdW
-%E.KL2UhD*s$]&(0)AX)/aEX2a,A^2THEdNfAJ2W2<3g9X=ZeeiUH+GgRE]a4_#LG582c+g,[<kb7^38H!<N2@IRR2nZ,=el)AuTm
-%fkAM#i^H,131HHJIToBF&pDse8Im3H%TOrF1d[Xr9*9``('XVGfNHs&_f">SBnX\`j7hNTY*L>2j[6IsR5B!#A/'JnX)%rP6W/0V
-%P<--P2Q'u_WeOUgfXI[TZ\@SQf$K@pE?fMII#;_u*6ot6IiS6B)JqRS^R,V[_>OoA%ZIoRBK(i'1CF#;*EW`@!m2J4UgLk'HS<WH
-%AIE:^_uQ46=QEjC`IaCU"2ZT_i6QS.,PhQj!u>p`ZFl!F6bRWC++u6W/^/+f"E:9ST>)phM@DMdmYa>?ZGK\ObSV9a(n<H0F:r*A
-%&Am_PHc\!go_j\"#9M"^alG"?k2#;1Nf_DW`d.;Ik?'ZE`\)H$dhMC)AC+2XCmCNE1=8WK:8U4&:UR-0J<j'Sk:nc35V6!=K_rQt
-%*fLP;nlWD).9XXB3bu!3/?QgsZ!sTjlP+cj5=!)&>U7`nJmTYpg^6],(26rcV&Ek-cXpZt_c+sf1G$nolJ%_V6Idc4BXeM,F=fJg
-%^qL5OUs@GGjYsZ:[A;j0&'0*W2P<]!-^.PF3:<'N[tiU(+SNoFUkraBi['8h!e3-JId.LBm459:Wb)iR]7<t@((I\IcaIaoBEhB8
-%iu*1QC'q:[4rdm-R0'0o$,/FlWq_iOV'%L_37tGH?s9gQG6nqI4SG.N>dp<fjJ$5aQALVAn8-<6Ur`CIT?'tp1kZE'L5bCUgXYG!
-%ftY&nA$Nf]o)@ao)TDl`g*b@+X/ZujMPqE%aCL*YBa#b9!a(H"J-/ILe#o(8!K6BQZF=4'65saaSL?h(Bh>OH&jE62_5(WX38@i>
-%+KS/bHq?$9;,e8B9*.(Pr4T22m+WtsfLNA#PEeVQ&tp(55C'AOX:i0t94M,i4\3_Rl>U0aj%]eaL7=!`!*RI&lGUG4eT[@E"^0Sl
-%3u`NA;f'BLamr8!ErcA+=o+5W34"cp;JfC_RP2`MTg#eCAgJb1Jmo<b#C3WA%\)O=AO3Wm<e"'T'e$'"n2k6B"lHrHB?YZP64n$,
-%jTA`uZa,Q6\n&F?EK7A*Z,ADJ&VB9J8DYQPY#U'_oiV-9]Yl1c.D8iC1m;WbiQl7[CR*8.ZKO*G>9<77=>*Xof7kD^.N'"@UA4Zt
-%5&GpL>)''"c,V]Sg=J9lF_7T^5CfA<c4=,!jK.F/9Tsi],ChULao!u_/EgU+%1/unk.nEg"Nthh3M4JOQO8X2("omma[P:dbA)9s
-%_f/&4?,q#p.#a\`7)A%qjlBrq32Y"pfk4f-jFs"E2!DKerm6dC,T597OO$t9B5!+L2j(5m3Mk-T=X9H?Cs&0#>uBm@s/cS0%hRqa
-%FC'"X_Lo"$R[)Q?&?35YHA)bR*kR9pYSMS?-/3mR\Y3KJ.&5VM\b[([2g-0ubM]k^:RYA9<PT*]'nmqM3g0QQB*(5&#lk-bgS(CN
-%o$FjW\Cne5+'"Vn3?Xq\;;pYK:*.W#*Ib3OKD8?W-*%;7gj#C8Z@PVD`(PEAk$gdBY\9/0K;ga"B!E1C2d@349h5EIbRTQ5(0,nD
-%c*HN=I^Ttli:]`NZePI3QL9HTLFWG#4m)d=%g%O)gulb]8h?jF9i_Ri.CRc>NV1=GK[gE,50_$$B)XR/]VneiAh1-"WL(6%.m,/>
-%+7q=63i(sZ^t^&J8&SAWN_Ts%@c))&Lo)OP2Nq/q<OUoXgnZFc"6+hs_mlIZanJLN06`d8B'%0<7"&*=gP?Zq,$0h;O),>Ks42$G
-%PeeA/F)ie3ZWM+/Hd,r+P<%@*/ebN_2qKPH3Ep[#i-AEtG61p$^YSU#1SuhC;d?sjgWS)opZ:&MZ'9C*8T=%&TZR%%29n717n('m
-%^XrsXV?DacM5?D\n&:pW^T]/_l`l89A_SYl.E&n%bImG)fR')S?@mFq-f2rsD-0msS9j"7b'#-6.)?:h!u^3'-+--"KF+Ft=j2oR
-%"Bp>X=FHGs72!PE3>b+)[OC"lDS0g_c_AkJq1S,nWY+c%A91[gX42&g\(,.<fJ]aCgBLYk,g0PM'e]7$4UiKr#SnomW"cXN#gO+r
-%V92bajoG*e(P-=8nL4FN"c_'t5E1*[FVacW8E,NY)hERTIc,70c2EOhTk2m)>X]nNk&*>k:hLHme,ZjNW]2dicE"\@YJaM=)>Sf_
-%diKN=_8*.8;,,d%S;b55+VMOlVO"6%B#Oc0<Ss2FNiY(mE1sO:NWLCW8)oCjWe"/:@raf4P\[(5G88J_O%F;tAHj?iC3^P8ahGFP
-%Hde<CaJ>5om.',+Ho3TF!Urhn?FKoA185#4,qcc<3<*fS&Z_C;g<fP*nu!4pO&pao.Gi<S9V0VXF/8BA/DIZ2l*(Om/St9-0ZU"Y
-%#'3g5kfUiuh!]7d:%NWZBRZEHhEf)"5e7/L3U%:NEfcZML4b&]U:>9Qp^I.4!F[4jnZWdF^9$n:YXH#c;R^*:HI_Jon/77F%U%A"
-%F=7fubQ>`)mY+fboFLh/#E+Ij4q*_%8_pHa(N9/q*<AmhA%1HG7t';RRE9HSZ?_[ZG\7,]QXijDC`Ynb/"HOj!^!mt1pUK4#3:3F
-%lD"OWZ7<TR;k^Ch2e`Geq1D-.?[k&f#O]UC4mDN/-8[4TBQtRRa0$S4%=]$3;H2IoR7.<:bd(d&#pn*?K6,RElGY7-5P'"0H8+8:
-%FsoV*hkTYg%c-Ijn$R6?]bU&`@+H1XcXEJ8s-jKM&Y.m+^`<P;:n4`)Og8)-Z-+H"7D1g%[Nbg\Z/?i2oEroP0VISi][2!f%7W3F
-%gH?BB2+lsf,B;CI/grlEaC&1><Xrb16%[H;1gsr!_euliTaftqGo`)e*_h^QXMs)@C]'R%mkU].iq/)BLY_e(D[o7GYW-AT']rCt
-%h6:?n3"E#0(<+YieYn+ZhJN_>&44)^lP]]AQf1l.W,)/hgug6J`6fMn%EP1Tr^=s1CY@bI86TWuL17WihIGhBFRV=8hg:@nj#9:\
-%f0FL[k`uXU@:3I3CpJULYdj\`5VgR1Qh`YW69'tHOOa1]Cl^5:(#n?3=D9h_<('rAARn1bf`K*dL(Ej#,fqh54Hf2k%oKq>5Jqf&
-%<Fs,Q%Ks#8WcD[;EuH".fE*nZa"ZEKl^3(oO^D*C;t#lH6IrW>b>9!CUrt+k_r*9%/0j*A6BR@A"(2MG)Dbn$XX^RLDZF<9=G!UX
-%V?*c-?*OY99<=f'+afr^p]Q])&)%'S7V:8G=<-+s8K2]PV[7&1PC!A"`K9U?0W]EiQ=Q*+]L6&,4QNBp1rc+Vl9f@")'igO@U%t&
-%QNU]^9JJN[nAUYUMip14?K<%K:lT[/<el:S5MJ!4CN+E*l)BVY=3_+Q!eRh.SeZbn_g\(pc7fA4IlAVL\:9)5I]1i3/IVfjJu]<k
-%#2fH!9F<Z)2!5UB,Q(e@]T1-YYKa4*I>KQc+n"RC)%N-N/7j_klC9fj4dPe];lg#$AdhC!Kd_^MT@XFB<[Yaq6UZb#G;X=-r>Y0t
-%`aV6%at[+"&^S<36t#q%Z5EN`I*]7J#BH?m!q5,.)[c,MN66(+cXosDfsqjBjX\:ulX5R4Pl]>Qjb[do[gjB$3m+]E\j/M?DF-7h
-%7FKY'c._BJbfM2qohPj/9@hg`SYT-o5er[*[M'YkGC,A>`R)SJCiR#Jo34_V,E4#+].^"E?Y&i8RY5,SGt,kUOD!?s[cdL$cgqWS
-%pXSk>UV?+385g'r/;J>efuZ5E2+Q`LI+DuTNk%TqfYWAf2nS+/^i.pW9>A6C=Vt>uH@=K]]_CY`HE<k<l[0F1XTXYN[aC!+p%KQq
-%RJ$32;fe0rJbn`_l[:t6m7I$D:#Bgbc9hi"c<0jcT+r^F05+!2HeVTu]lJMEb0s&]Z#@3j`\[NsA'pm>;-oX!o8A$lp%;Y)b)pr6
-%_ok";%f6!85/5sd]j86f`/ZghB`s:b/IRa,oVt'Gqeb@rT6>5%pRV"Q!ShdVkIWVHc?B^l`Notj1S\>e+uRG!E&IF4I8rkK_sG<3
-%c%=Z^%T[']Kq4^G"S$h&AZuET-2F'7:J;]YERpD07fYI@1ck9lrdD6`!j/h<f<6K&_Hb1m+=:S;V@`!D`N!/E<s_KO;\+34DUb/@
-%IV@Pb4EduAXL>SO-=O"de+*W('U:@_VUFLt7BF6QCMe<$=&n77(!K!8(m#=`fEaO\\DUr?AJ+gr"5(gZ3!C!]7Pi['LT2T5%)k1(
-%,hYL1d(TSGDSo$8I)0Ab[nUit\[`s2QA(7<Udj6C&h:%Af".Ss8YAEZ;fV<WdS6Rm'`ubhg&si$\bK8D@)XOq'f54_0mLhk()p'o
-%*4nX0c3?MNo@WI#Hk"2gpK\PeDH=L+N&]I60;J'N%\7EhRDT"U,+`1=Mh]+/?4%,M(BLS6_Vn*O`,pBsfsVD9"l,_h`h=q=`b$*o
-%M`6hPZ:^)uK4R%1TJdWTlXl_Gj8*EUqI8XhLD=7,%:RBb:eAPuFG%k`alF:&"!g*l*eP82H%7ZCi&b0F6X8D"6h/uZGFMBhoo><+
-%MYJ<fnk'#+ifo+Q#hMW`1\hk/W6^-hd*C;QV.CRB[+L]SGOJ<-&b:Wb>R)FkI_ip@A-']DaE%h61P'qdG7P2:QLfcrAaEaI"qRTF
-%,Q<M&AYjoop]@Pd+jO:&)oE>LRi)<`0>m<!!D)?di"GJ<7B[#8#p:H\<3I5o5,!lV%G*M]`54OV9PdN-TUfr`146iXD.A).IDg\l
-%'al?)^aco\.TqL"=5bQ_B&[FNKb&sR'B!(UQOJI>[m2[T["aO(A@T9S/<RG>*!l%/7uG1GD2[c,:S[Gu#l$-O$6kKe,;Guui;d0a
-%EE%Ju+/=S0QW<2\/jJN1cf2k*5V>\YK7=_0dsre+'J++n=p/f@/LsGL,>T]qN"Q/_\4uOt/[AY_Ks"\-blXS\dCYJ-pP(CYW_LOk
-%YaE(9*$Ci)CK@h[r&l5GY.J*i'hj#aUqlL(d=3"#AH_T/h-=(FE:2uKB-;K`H"dsZ"-ELf7CIa9-(m[\G4P3r&kh<>997c>=GMWA
-%6t6YQ@)d8l08*mLZBfB*fSs")]Wk!.<'u)u0k*qFJX--5@G-6\1.OouPaE1W9>gA>J;0sP7.sInUq>M$hdIB^aCY(M>=9GsRmYlC
-%\ZLDh#61*a[gu\p]jfQ:Ms#nq!N-<mj!>p)c8\DpXLcnA'@URqZ1[\3GZ7'QFe8ZV(P-FS..>mqCZ8Pf20N)sq&D,EDBKguJ>VNG
-%+U=Je^aU:3oYC9V-'!##P&4a^YkYDO)IU@K/n$Z#h)U?-dHj>b"ZiDo,'BZQZ8nS)?@0SS3DeJ:prAkldZ!&GmG/"q2^E]OA7I=Z
-%_8h+")cKfp`OWUmS!>Z!c-),-)Pk*&?oTBbh2Qlr!'$==82NLJQ59J>\YES@`#^ZfAn+gX6NHRL)MJBK%4A'l&g0AHaImm,s#n-'
-%!gq.r_M>p0J0p,[#Nsr/.h\2AX>2_;*3MY/QeWe<1()M$T3BOH]_(K17[h4+^qhr1&!fgIRRB9K3<qW(pYF^;DcH9R2F4^("r^UU
-%/1)`-;1o&@kBouq`_k><XZc1qq1'`SnV63/JfnfDf5G#Z.=IiX*SkJm8u";d>5Yg^/=p(sPpgle5(kOAe^(ONg"UDd:N%TGlL!h=
-%IfBRjBtb!HMdOK5Y8F^srM6T^e,<]!;I#j7(hR[V7]@If1Z`ASBI*25b[-bJKER7Y[(lFZ5Mi0&D3f7nqsHVsU[9jY5/ZW2hb1QJ
-%e#\Iu68JS<e)&7Tr8n3"%$H0C&3'3ap)+NOc.9(,de3_#L^ZnJB'(K>;%&+I,9G=XMAFkr(=j_%qYY.qgK(MdMh\MSSgtT;,_ll_
-%['d[g#kFRaDjWu0A=ade0rEpuI=)!^hlW<9=Un!/hX\HlGdJRE[=<")S1=KtiJCi*)R:@[R]GNd2[*P)\%I*j>^GDiiUQ(ta5@f6
-%Q<>-F-?G6=GFj0Wc4BU%11M=90;mOB8d!/>RqLSpJmr,17XJZ,gaOT`+__D=6bnB6TSA:)n>6ca9L'DibaBS-p'-03[8%[nncKs%
-%D)1[:"WUB=raL"+B`;#P(2;;i[CGRp:9m7mhs6%,.,\^+e25O;4eu^mMB!l]\?gH^@;:u?,DWJbP`BK5o_+^'MA9i*PPthWh.<E#
-%qQX2/WRO#c@c[r(PT9?+&#JBrSHt!LG4W['5rX]78X9?5.S;:&Hd0i=@e9PF?^ARDANTGZqZW4$7WJd/&?MAQ1&@Y.@rNSaOMsg^
-%n<1F4Ru=2B*$b5IQGBkT.67fTDQ>H/>51OTPA,6sdRN*]TBRQjp-GUkWD1"WH$%J'[W!/2$c1_q_)K!2LjN"](pE-C(AK#-'e\uu
-%pe+_Y?r,H59]`2HJ%1OO:[,N([YIWP"?^q[i$&Oj;G:^^.10#dT^:.AaL0;IKO>go!G5u(+(!s2=R[\/8s\U\]85[/,.`SZ.WcG;
-%p0MY]\enN60^PApj546\dpI`AJ`HR,m9d^oh<Nit>V1lCq.I#S-D8jVdfP6b=D+IR&N=S%gp@-;bOg7e9iVpq2q\#Rp&o5L/$=Nr
-%XhiV%k\6F]X;j)B_e%Ki2iE_0$chO#]SBmY-iSY:^_[r&k'k*JV2qta%GRW8./CurrL@2G@Hla']G*ejL1pWO<Mnb9!^/8n_=KTa
-%;+WuMKY5-1*K&tppL>X+niHd-8hQo@=7(poTVs=U7L'u,^WL*+@!%89mhQr%<i\X2l=X7Ebk'#D?4?-0pI*G\,"Fr?<mU-aF>DS0
-%ct"F[)m93RBrT,5(h2n&Eb)1n2Ui3!h^smcZcS*,>q$9,>jW_Oc:7`Y$pNg8Gnt0NYE&Jm]?P1I(Qc@n"5b]KDmV,cY.OLnVr?[g
-%""1r@mkb^dUA*Di+J*_/Bd@4OQQKS3j#ae9MAL=$VpKH]aZHkGf5fqZJCt[gN97A)39Mu!lGEF$6j?5^QAXSaTHf:(Nbm-@<6P'R
-%XA8S:Tl;q;OW[tB2t0V?H"n*6m"m$M3`*h]2$B'*K2laJ4<+reS"m6Nf_Mo`jkagC_Ztfs(@>*e>*6QQlp'uuNP?Q)e7*;T!sNEd
-%$QSNS3:8nb6u>Ri7WV.EZt6s.*$dehCs/9u>gi3O,g*K)eU(1Xo'Udt*4Am$Z2LV<8Wo'InX>6MeGg_&R(m*A3N(?Nm@(Pb'YVPr
-%>+T&qk-TY=<SB`&aaiS5bkjh1Uq@blN"f"?#2dHV-6D@mJ?fCnO6GMQ:WX_7iJ>c1"Y$#U!Znt!GF7t(n+ZG9K/;8$n6!EW<'qtt
-%MP=WnEIBaGM5TMn9JoquOC(+%bsSm*l',CaaWpiWEIoC4B31][B%YK*)(0@MVrM"W@msMQI'Es(;=c>7+\e]UF"*bLDX1[?]'Uo;
-%bZW_ZIV:T&_CG`^$ZY/UUd0EHihdZ$#7]E-rnh9*P]u'(g%;XRhX-\5BR4+.eLpMWXH_j$KV`97,A&mqd98GU9(pEM>9(XMTc)q:
-%+,1bDC,7&)8dm><2^I[67;&$*2(a^q1KsS`]]&g*:XH'NHC[IiRM[@o1#u7d8t<m\_Su@40->)DA2.EE$[_^)1"QjX#DOFWW3#;>
-%R:,n@n!2cqSnr`i-chPl[8KlWlt*KP%e8*(S:(*QfiQ#Hd:DcPn4I6?%$)9W+G)Sl/EZJ[bg^Q8_:t@67;M]<P6HZAl1@[K8T#@"
-%E6r=d@Dt#MpQA\5ar4D^qjJu-D-;OJ=_BR$<qbOTag/Nd#uo*[J!u)[N['A`*DVUZ$tI)+0A;B__CP[+rCfAoPTFQ:%VqU1Y;AKM
-%rccs+/83mbe%$pE8\NC,_XRbo[B2(<calYXAstFuQrT2g>)#(UQ(*uVPJYYP<<e*)MrtuVpc*Yu7?/3&53-<d(BNSul&.fC3$BIs
-%67BQZ4F3GHOWj;V_;,h+M.L,@T4R7?c6(^taF2H-C;_2>bH]4OfK(uiaa>3j_!<P!=:-`rIu(_`pR-Cb_,OP7,'5QB14IeeS6:;d
-%k&^@&<!l*=f.lj:p=$F,e3`nh4e<"h<DJ$n@W'MD%.<`,XSRSd-Ta5M4V`p<7EhJbP9njpN=,]5]'u_1bWe=?)RaQjLIE,.;b"XL
-%?2aTLUtaPc@5R4jG5![^P]+iqR9,c[X0nk7H4QVu&,aZ_J,R:"qhtK^rp=(mqY1$Sn,Dg3J,#@;nTW%2J,:>fq:GZ=0E:\1+9(NV
-%J,Jr\`..Rns7fC)hZ)Pis7lWQ^F]78J,(btqZ$R[hThblc*+n]h:I/OqhOn?o,lDAJ+<<kJ,+"Ir9NDCZ1r,Irg3Zapu?jNr6,-;
-%&H0'[gQ2C3O8mi3SUUK`4Stb#ps]q9UGi)Gs8'X2\dR/$:ocFkDboAtJZn=JpdY]6af_99b$P#g5FekGoUZcR4qmZ!%kkl2)*_XH
-%.,:Oe&[XA4&Le5.Xh_su2<dkHQV+QqhEHD?gCO=Lc\j<)s5BZ\X*(-<T5BRKT8^k@*[Yk8V%<O"Of8JW8\FcWr3p>9j1'_\>)&m\
-%]m%rBWh7fA'9O`@"3d>_7#7u9,5GYk5O1D">lJu:L_KXqq1_V&ZdkXQ86Fs=R,r-Nrs7?Vl<+eR-DWb*9UKdpf_6SArF#r\Z`3H@
-%j$+78TdG4na4L^[Jsroq8!H=]!@Hn+M*g`tR+NhHq(.P:$->)^QdNS=@1Q,b?<['*22(3BDP_^3*bVjkefO"6$O;SRVdLU33,`ra
-%7ie_7>h$P1h>kHB-H(o)F*)5sJ]CKo`3[_#Pod!a2[5&p`X$JD/k4HI^5^f)\DU.&D7C3E861UacTVbT'>hctau9T)AO_6-]1r9g
-%Fr2dRa_,7kD]:7;/n*UnUO^Q$AC0iEU?QoY_8m$t&"fsaZ%4NR5<d962hY+7TbM[9a>WQ:Xm-SX:9b!YL4hm"<_`A!(Nf<b=>Fff
-%euAq!&=Kc=S][;Hpjj"=cr.?Q/LQCQMa\j#0qp4(HoO<Eo`5br_`B+\"GF"gD&/9:mn>k9&]lZ#&f/peiRhtT(0I?T7+hhL+f([O
-%ALAN!Cf^%^Z:tV2m5%_J!:Pj5Fne<t"YA]*PB%S37O.i5VM>p"2XFEa:ea-q<F@sT0S,MK'=(cHop&8i4prlOAI2LNRghLBa;Z6<
-%V=\OF5(^dpLu7g8J['q_.:ihOp6d@1G_on0D%ieeIT0r%QBR!4>?<N^?/#t`YglaYaQ`&6Q+Wj@d-tMYl023SNt%%^l`Xt3EHK!6
-%ejlg=-Qg7brIqk-952GUl0`GX+#b,EH^pA=HnNtM]WZZr**:PVfCFQ6V;]9jQ6123WXmbG=^shq:CUDGBTHr2O5f2?UJkZ`e=m%7
-%8;m-U?\!46`ap%_bVjpiqW!dhpg9g--M\u3/m>[0*MC*PB-1V7iBs`VX4>PE8+[!^9[.Cj!RE9MF=QTJ";gDu?DWCJo;/\8?Ye!=
-%SuVHkBJTb.e$=Ji(oMpCLG(>SK908BG)iL&VJ5/A]8g#tn^?@%qeG!<'ej)t^<;n7B[8HAar6A="8#!bR`9aG=\$9_IaTSm'S;@6
-%-7;B9T>Q0;`%UZX[AVanPOV7.*LiDVaq/_h(pklH:n%c<$KY-5QU)U'<1Fc7`YOOBY7;,(C[[.Pf#0.a%0B<V',J)Ofdc%7-EPnF
-%U=NuT^(+?gn-,5W@u7XjiV%=7=bYE!"OeEoJJgA-]F`Wo)6Z_Z9J^c5/6TS^e3RiYH"X2(/aF-q<sLdlV`AN8e8H/9UG#dQ)%PJP
-%lUNA-VV*m[$&GY`Z4a]N#H*JCgM2m/hOFOoktTEBa6M).2-\DD*3lXXLY=p;<@b!dSD1e$NNEC!``0Q[Kr(_^H)Lm&kXLT(<\kms
-%i<o:>Or9LiH-TeSATKg";.fSg#d2S/eS&f'<3mLHPo5Xjkg;6!>FF:]d6o=^)mmWG@+*ld^nXQQKFbD7lM'$#'=h[QS[rW/jF>hQ
-%&HL.1`72'BmA;!K0fK$lT[=$=ACo'%4=tUk'agR]/-]l)Fl^"_<5sit!P!'*T$8uA0X\O=XDdL:9O%,A\Rj<D8\&WMSF&ArhoNCE
-%nZ$11E9FK+C<]PhD.^\HSc-`B"ANlNfec%oR;b*okiFNUEAc2pAWLF"e(n)'ZB&+DbuW(,%sntIReY819ld\SZ2q:K.]]*r9,Y%d
-%.U^7-2DaeN<".?rHj/7>%*QRn<gRic+X@eh<]IK9KMWq:qZfp]L]mtDHXn&3"6'K'Y/XO#ZQKHQcL2OO\J@/<S(<%@MpS%h13q#R
-%L[9+W:kF#o6G[2LQ.bE.O\N-p?_J#PieLO0"hD48C:fpSCs0)Q3o#P8<inI?@&sC+\ba0o]C/ZkYdKWg7'l([K_,<09G.FB4;ir3
-%(+Ec8JIlEl3]`J/UVc2F1O5(O`u]'Mqut8-Pqqbd4$'U&m561BhgO,e@Ad<'_iIY>'B\^`&H-ea'$;>tK!'32!&n7DLq0_QT:s6i
-%a*KT#.LkWEp*QS)\nOSWYg</g$0+dW9HaV2r02%dm9r?HGO$%bnMUEk'FJ_-dk8<JO'M>ea`."d2fk:Sc*_Kn;>=7?HBui<',Fl!
-%PGdu>fJaI8O__=n9]+l:KjYXK?qbDU>VcC%6;YnZSJ<8G]5ggIGZ6W61?7%-Qad?Kfiu_4_C^$e-luls>sZ2!S6Aq)_Zu@V4P^jB
-%UhR\.QC]?JR^Gfb?JSd&X#6TZ%BcT7Vj`]N_!^teZ\`P:,0@DTgP*aU2LQWU1QiS!ju<1Wf5fsX$TV_V,)[4aPsoG)MhK\oU1Sln
-%V5C;:%s%_fpXct+o$fgP;gZ,N4l(CkF*LQTkY5W,eqr#%L0`(?l[HfNn9`gAVMhP/5"93Y3g"M-2s&n%$0.<^Um.kEAbQqL*t80Y
-%igc0Y0Q;G]eR%laZ.g:0X?A>F<3?*?hB+f#YS?"O1*P2>c"+9KlmhFDb11o\G!,HW*funls#tXN!?lPo^E7W0T`\J*r-^$+pp85*
-%_AnIdS+j]nd`2q^[6V,E.@)V=.tu*j;X$&NN[5KBF"(MINce+r1jB&:(?p1gVX^&XX&F(4M*N<n7JIC5EF"2WQo8;*J<RTqP.WP,
-%@#K\q"\EMg2"=Qpb>opPKMOg+1gQhFDAqjb2^MT_[QDl_pt"<tm,Y!4Q&g"KD0JsRZq,2'U4Obbb[%L/HakZ.^n-"^lh7#7dZ'rj
-%/gCe*iksBiWG&\5jN8WVk,Z)F,igi3?cSZd]8ta\G\Q.h*1"bfE2e2gbeujq<]=bh^IC0R:*uZ/hEGi</R5uq\YZaJj7LIIeO!Ch
-%12LOCB=#_(#_&-O=dEC(Q=-l<2U6L8^O>l8ojTX+FBn@!YAS#r]4@aJ)T$!;V8R$.+bQJRXat>rPFpBCV5Ag2E@Y1,1he(+(-d'$
-%!R9uV@A>2^TRE(+2f5IjA=5V.ln\9RVV"Aoahl79nnR,!i*o,'oO0*HrIPL)8)8cEpO;c#Dgq1PgAPrKL]-nLJ,^2lqqWCJGR9Q3
-%>Jk!SEgrUF*$/@7];Zs1hk%asF_!LsDblAjLA5KdnZmZEY<V(is69r\+k)[,1Y>bjl(ZH71jd-5V`T$f/nEmj"X_pJ0Fs^K;d":L
-%mNi+RPIS_3$_a`Bb8;Ht8E+^ua'9o/=K/e6\'0bk$:5B9,EIOYg`f\UX\\R]5JBVUIiPBKBuY147rcp&"N`*MN?*A8%d5c?`3@J=
-%cj7,ghjRgV;=g]rY_EC]!A.4Jfk$aaet$Y!ag2RI`O"nOi5'9F0B!7CiMuD<cShk:`\_:[8k)kY0D`@D)i+[`HBoGGZL,mp5]2MX
-%Ri=?_V$<eh5]aHE>mA-d-[!/@>sc--j;u5"Th$/21]6f/PsV#R4t;K2?,$bE5X4PDDV_mD6UE.Cm^S-,2=llt:nDI"L!1=IG"[ei
-%Ir5Ma]sAfsFa0t3%459DVNBaib\f8K_strYZNK`]3Q1"fDAHUXU3MYt_rOO4DYJRk0,M^m("!4GS/UX#5O8&"]+\aT3Ssi_0(+4N
-%Jk*n^2-lY@"Dl/ek',e?m#o[c<gIMPO6ViY`R:@5BRO6Mb1b\Ch3pEV]"HV^!NLlpG-<bRo@TU@@1`dQ>,uekKh:0TQ1i1HY?5Qr
-%F_&?Dm2k"iK/@kO;n/*[)tQL9A9U@kZ,03hq1P.%l,K0IJ(k^LJ6u+l!8pru4]29?VIpXGJoLM_Y6ZX3J3;Tn/GK&pi8=2H1CZ_.
-%+(n!,(g-Cak#rgn,')>=[^fC`f3tGs%5D)k9IhT*@YGd8/*[j4X'6*826d/45c@=q-V@XLmpJUKoWg*)oiu?'"'OoPVUu\j+.'Xm
-%^e3g<VAidh_Q^3ag;gc"=;JfOE2Qe?oiUe.;O)&%B62!Dn-p(UBSCGcB,-R1*K/`Md&NV5g#gJ(0R&k7ZK$hMOVdG/SU30N@r\D"
-%K8]:0PT`E=,E<JMO%%nTG8^&4Y-tWYj)<o67h_>q(<:=`nsT&[fNF9lN8i.nSgCc.*bN1a1?\k60Y;?/5Vc7faSI91P7%Y;*^]Y#
-%CpXbak1t$m224cZ(Cr+g63_F9*f;i<*FsgSg(D$^&qoaZrG]XFi^3/i&TX<)<LiU'J$.?QZ6alq".A,4Yt8G1p$C_]>YSm\0'g?X
-%<b]HFST%;W(b*b-%(]Q"B\%oe(6Kqt1l=H'BTWsa\JM6'3nGNLj_e]n80_`t'U8+3)M1<%<Wt<f]r!)3<sfEonQLV1VsGXAPbNJG
-%aW(<FlYKkAn("URAM1ZPEH<'!GW#E)d+`Y5:JtT+KN"*]ad\lL*1#$Wfu*%o!-qrsEHLOc3YlJ.RIu"K?PLt+89+<8R4sm(=Yh%X
-%-+pQ]\:0`p9N]P,$m_jDOa*0eIL+$uA&=!if1e5FefegRs/pdSm$)._Oq/`m-SP`f6J7<)CCFqe^MYhIQ&TTS9.GfMTJd1=:R$XK
-%5E%>A!pb5Z[)V*7-l$Rt)T[;3-BBDl.s&?&`1di:(9,=_cGA8H3t>2q)0AE(lWlJ?/ZOTEfBK4bZGtY^=.PMl.hY.<N#kS@hASY.
-%6hZ_qK@$h>99XjUi*;a;PS=uR^T=@`cDFM4/E:q$b^0Z$7O[sH23=[ugEQj@:ji=,A1#")mGMaSn,E#Fr5HGKiNN7Fb9-`JT7?gO
-%J,/Otrm),&T7(25['oOts7d]8cTh?N5Q1G>5Q9>CroIL7q=:^rs78JTiU?:&TE"[N4eDRY*rgRlX8Y_Xor;,1Z@&+E$@?@;Cl%X1
-%'%QB6Ys$pLqj;WaZ7R)oaA`<gHWGBH7;A4dI/-5/AI]"Kb.*P[?j8r03A\!:V@N?:8E^RKi(l3ss8HrtE-tcFgGU5Bn#u-`['HC;
-%g'tpqd[TP7((L(-cWi(kqn:)#U%iWFaAN,#p>^2?ZgNpDjEXnV,AUs+U&fNqZ=1TA1*QoN9\FiH,UY<Tpo,W6YSMZ?e81e<YA([Z
-%_eEVrA6RGW2'62,0fDk0kj3&()APV#84\OA2-KAu/j*0K*FbngWE$O`fn5f"pbE4ar^=)/9@t7Ufked6no?W,D/`YIi7A-d(+t7@
-%?:3@fd^cXL9^iFl"eWh50pbZ=V04,b5$k+,^edVTqn(UHFQo6k!dnLV!GXk*X03+[cDi<i,SK)?liEO;3P_`V"g%uKC52%!D'Y1n
-%7C(PmTg8r-j:$H6"'e:W[V9>0Z#W^nZdN0qn.V]3rZ+qgaXEOJ^:#?R[rh\PnJ]:^m9Zg<.UEC=hN\i'#%=0a+ZeN^Hu]9gHe$&\
-%s.[W+3NEDVEfAK;$_cI7+lpauAO&=*0F/n;90I0%:!X_=#X[N-5?p^..TN9e1TJ1LEFBPf]ci;Gl)VFVbuTS5NS]#Qc:#BUd;Tft
-%^Af$lM.I::7\f83Wg+M.1j,R/dIA3^qeECHk.<1IAmQ0T?IW&61(B<,dR&g>',]hCG;1'E-FCi%KI"huTge:G`8'<:Bm1N>DqpE2
-%2`%duroSfq<ZMEceO%Z*3UFgYQ1aQKKG9rBr*jFIk/eDM2=OM`?)oak7?Hid([Z$sqe=N?Z/+T!KTd;5jpJtE".W5>pE3_k[79q\
-%poH-+;U'<dh:V.3V<G5\IeimJ'e#LGMo(A).%.G'>4W<b1lGrsO2'(d[i?(2AlJJ_[8\,1,\TX_G$Vrb4"$!un4RqAcdetl^8M)'
-%4]nq+/B96*YoW0^SHJpk)i@U[JFAN[51,lE$p.(7UJi#fTN9>Rf;CRb4_hl/E0BmIqpDjN`Ti4hJqY@)M^./dI]oOIF?n\%J4\!j
-%Fpu3BPOKriiC/W`D0M#*,D<Gk%RooLa7>o.+"^8%DY]e-4gN&pc=@*880S)oGW,Bs(Fk>0:Mq<0>4Vr;2g1N.K?Hc$_@01@$6M1S
-%Hm^J+rsPHi3sFp*5b"X%lE(t*mC2SCY/G&!&.A6b'G3)n0T_p-]?(oa)2Od<M6"1&9NFlA<i[/)%lUh`G.k/l>M:[5gjj,U=_q@K
-%5@!0Rb.9]D._qDhO>*q7JLhWTbu;UR.9oc27(Km9KjK.*bt<LOX0#E(pb&V#@8g4_AVR>9VE_*81T"P5#o=.$[TqTl;ln!OYG/*#
-%UDWmY-fHU^]b;,.bCR9a67;t81eCdqg8>9$:8IX8Y),^^$?]jko!\*XQ>jkHjr&24GSpe6IP8_rf:It;[1k7b)BsDg27K/iYa9;m
-%>d6:s0;R!jOI)Un_W0![?t*@RjPUurSQe*7.OjU?E*U`-5agMm>Bq*b#WcUcff`n211jV.n@U\&"M]10D_2LQDK>uQ"?C5iVa)@E
-%0Q#!Qb=l3&c#0Ib',nfE_IZO`5T,=4:f^g\g!q?@@`h^u>0B6DK*/dAo5!;<l5ZkSA&oltp:CLBE6F(T@%.@L-gfl`*G3FoXt-E+
-%&M;?sDqBVR$+s?8Ik!$u7u7g2?$C\jnW1Hb@Jm+aaa]JDbMmMbX7J?3o^,5-q:rsZ@D8DkbKd;@<Ms/$0!jHF%:SW>1t1n6B1]fq
-%'/J?Y6(_R<753^LnCh@1;!am3C6;p2PP^/<!QTl(9ofb!\?lHDi7*\Tm[C@1lP%B[k(,6n%LHcY.02q;4Vl%BoJ_VlXd07-SKY/j
-%6.PE&A*R79c"'A;R6cpPHG1:AR2Rd[BkrWMkr?"m"3Ca*NRfE,r<l:+&`t<2YXW7Qn(4WeL0$?!kdY=-:^@5`6$tV<UW)31A]OGY
-%s5K0\d\]7P8<UiCEW_@nCoCC:4rTfK.+1Zk=n7F5bl[M*(RX\<88OV9>f=Jd.FS$Y^r1#2+"u-kGf"ETG\)ZTpZu5Df!E],/eDt*
-%fBQ<!-lJ<ZN]#g'4E[;QLcXoI%Dpf,e7dO?aJQU5[O'-ob2eJ;%#6<8O3fR68C7Ht:,=p=Dfj*h928%l$8mQXS0"1GWN>:'11eph
-%Frg5KRE3*S`9VH)M/;^ibV#&T4lGaF^(P_uS`")]_u],j_bOpDr\^BghW2`IR!0'W.66PG+\tbq:#]KG7fqd."%19(mBfK/+`!4.
-%Ycb=Pe*7EqD[nd=f9RQYoZGi@qEi7mN2X-4S4L(D)]E`S\IChn%U[O"+GnN:X8B!pQU1Q7iY.=?B(C$/7FJDL:qs[c5CW<@oa"p&
-%d/\/4QE:e\^.Ra*R2)>QiJ$WEG#i0si0M+l^ZLKB*LUJ2;d9A9QNNG-A-6CYkGo,pD/[9@UtmeMQac:[Nq6e),FQgraLuo?4IH\j
-%_=+XR[^8U)CK_ho2q\j_\*Z,4Vq2"@,:!nne/8Gi?@Z1:Gp=S@;HC;f.g*[kem.M9E8/8%-@G`\6`bB.Gs=N`39's$qo[Qt^IgOZ
-%&Y+X3kU(E<es%C_:F=EJ/:kOm&YG]8BI;\Y4Hs7c5NmX$.,]'EYXab*e7-H=@Wl&";fbD4Uc[*ln>GPH&C5*$*7Y_/?J>&g10u?t
-%A_WfiJ"h2@MRpC'8NRKL.\RbMp.iPC:?#loH9lHmY2^/,Yj;mRq%cH3_Mj=5cr[iS#C8VOV[q5]YN!TL^-6eHBSZL9Y0A(gG!i](
-%1L[H@e';`Q<'`7JN5VT*+g_eh5&SJd*H8<8@H5B9#qo`LrL0%$@$_[SkrbXm$X9hZCbqsM\D!LN#e2bP7^h[Gs&fg+-$oBLMc)sl
-%hrQX+WKV-Tjca:j8WE)Pl6k!+N)7I_R_(:d>aMo7fDK0iL&q[X.k3Sl,Wd>G*On1#A?8+@k^i;odq)#[jln[UK(MSlh$<OuAY;(D
-%Jainf"*?Odecl#$5<f2pA#t>GY0K3_EHAYC_sl6q;1+NEc":N#fhK36f8h#^qt[m$:oqg4k3ot/'>CNt@PD5kAU=g>r<1Hk*h>+h
-%':V8Vo[UoB]5j4lqB;@a6$AWN+"<h#C%o>6Ud0&u(*rt%\f_"?qgP(GT.G>\^O@_`Gf[gX7`)EmNpCDU)JTNRJPpT?<Y5>EJ"<X/
-%A6bkOgdi`5NQsfa+C$EB++3p5bpHtC3%Ikh"N;1?jdjY*CQBX=4dQeTlEhDN#J*D'8tPU<j2lZs6!!`-']#s32kJ<lJSq=*>rg4<
-%gn0XsC>l1'U>-dJ]L[XV=1(%O-r9P#ELL^),1#6D0LYAS"1fr!Z]iPZb<o&(,4?\0g+_)k2<(%)=rsF2T\3$Wd:or08Pe&&i`n%l
-%KBY`eJ,rkb*nYWeYP&'#@<=(\fqoUOlL42]1i0-A&_eq7.J1F&fI,X1]4e!4N.421Nr(:?2+0ou+p?.W[h>.kSo7]JWm3_iFg^ei
-%fW6r4_jjiZ@HupZ=0bo@Z@$manTK>l8JZ5#+L;kNRAUURVaen(qQUoR,[L$Vks[XJ^&KfO5-JEq0N--^/&56kaF*5$oal>Fd$aE;
-%R@`XXX1d_U+<#Q3M9*94iX:tOLJ4i<cT9-pkp:&&",,bpgNu%/(j1\5<Ze@JIBjE?ZMd1BBYk`UWcSKbPic?Aq$>3^[R<($*@4MB
-%eeq+Y,$2G#iO'Lc6,rsdRD+/@DN9UZ!&k.4pX=YqH.cF)TBOZTodOZlNn=onC0l--r&8HFU/rZ$k;$I'cnK0fMauSdb*N+t4RJ_6
-%6VgsS/C15!e?OaTjBLl2@PN'`YQEhAjLJjSId-3>_dNV#-'<uWHa(<P85YkX+Q41F@MG4nghFqs_@GY[h2g#=\H-M;3YgGTK'B1%
-%8G0ID[49*PQ"-@LX<eOaXL/fcEE7GojSXHP(k.c(&pMGi_P?TolESXqemZ\-8>o4B6t\(!haLJtA?J^k'8b[AS+i?CHrbRARHjb'
-%Cla\\=Z/Yj"Wg%Y7neX,\VBhK:l?`i)!1+>O^WDLHYa,-iX9OJRkO5S.q;*+DmC?]O(J1@O=VI76;Ntk+9(kq\Xpab3JNj/#7rTS
-%abd"\1AL79G^`\b7^hT1rUIenqff#)RlLdOW6<FKGHoE^,JgZ)6^M:Q?GQg[k&0#q)HDo$MOd]J4?.4i4bh%3@SMJoSF,Qifbkb=
-%&2q#^G07P`?bYG8L@1U=p'q"8F*b\aT`Ate*a=rn[=l!a.,6upmjq=mc-RW`F2k!C.X?tYN7`3dgk%X.4"<Pm<FY\f:34+`q:!K6
-%RLql@Y_H)OPoi5,p0<V@UF7(Y/oJ]UN72jYD3bPpeklfm?PXT2%c]T;NID)kj?ENbDZ2^m6<_52J5A@`3E_D77ll[a1?>(D)U,gL
-%KPC%[0[hN?Df7NuTTea]45T&[b+aU@;.pFdk^i#86f^7d0,"V.Y+Xe,$93K-%s^4R<iuga2:*q9.mWi0[pO_H^#"D%"EH'j4>]=d
-%)@g3H1TFURA=`XmW7kjqk];r?DPj&=4#l$(@;'-^($,KZ/'f%cV`O<?!_0U[GsS#\auB+.RW*A,8KZ6i+k.!^'G9TW@%-9N&8fiR
-%gm"on-.hZ#9Z&)4WHSYO#fIOX5uWb%0_p^D.7MRu:fsN8H$;7!lWFJC/]r^BTpsF'=KI,f=aTVGhHT4(V%((Ro=7Lj3V?'ClE9r+
-%3mUtJ$\W(@nL:$pG72sueA+L]FrGVi!RugDCHi\Pf(;U5JkPI2`"+q22_n-cWRZZ9O\O!/0O[l^TuFp'BEZc(Kl(W_^iF#^H*\0#
-%iUU0KWH/oUjW_*bBA<=l//&rd5CQ*N7VMgt^53E5[/+4,8Fd,)Ubj9$p)qX(7u4-LY7J8Z(DOKZQr&0J/9^.85,o8Io\GP$4,2W7
-%K^h<s1'MVSaoNc)cFd:p3sV`tIGuGV_l1#R?nQGo$@"%m%%bi!S.:aI.Fi9@VqB4kJJpJ,Ca<HJq,p^`l1V_]oA+SR?Sprfa`=V3
-%"$;7l4TI;Mgfm$NLkI45?tMW^A2<Ho50b[4b#kn/#VGr6[0NEQL2gLSJ$,RHb-=0h?NQU7'+6f5MJ7m%+d$6LS(ie=;p&8-1&,V/
-%2%.\Kc"0+]jj1@OI+KD=P0dJ?*DJJZR9oja+LL8pa<ihf*?R=pQjP5+*0.S#(-gh/#l:l<3BAKn`ccqmbuVNUe)L`=!,"OB+d[k@
-%ilK:&JnS,(Ae[#Hlhcn7mooS8)r`otggVp?X'uY$V.7(`P&h(X<=tB=\%V6k#cCI/V>8T3=[0=s0j(WZprF0>!SnQqYs"G-[l-7D
-%[oJ6gI`W=YADJ@Mb$e=<b8UC0]np@Z;'WQ[qM@]2SXP9O<s$_#i=V2MpaWP]e[\e]]/PTDaSe[6%:5L0b?B;dF0dtiQkE=-&%C';
-%<u36F9p]b@K&$>Hg+Fn0YW.VGNL^5mTL-:99J#Za=hi_)mt'i`hE@<kDU3/i??0*AC53&)j-nk2S@7J8P?>&L13qc[^G+oN5U_4p
-%Y"h`%p(B_)YZdTf-IGn)&W6#/r0('I7%!qe?+gf'DNZ5OaCbD$`Oap)f]S`^ARh%Y^T<]!ok`%(KhrZ?`NIa`5CT00nta''A4*+]
-%5([U[E)AQiOSLRl4Z.m)&EL_'XP^MH#_Te7`QAC>2laODpDl4lios4mEWNqd3,]W-)#G4cPB<`qR$KrsJm'9g&QlXL&qt9>DkN'g
-%>Eeeia#'*1RO?$_DciT<>o_*GWBO.$k?OY>F:\pX_*&d#BHVWf\QBF6qSrfYl2&+!5+'642k(s`P*R'*EffCHA-1WQiI!m#,b@<=
-%T5D]"rjZ6H6>DYI%Te_sjhP=Kka\M$G^"96df%[K:(+6t-6K\n3<juOio5C,#N*4Xfo@9`[Gi%'Pc/n34KIZAclZ^hj[f%^pq`jT
-%?XE1?4h4W5A.*@WI$N?:q%?>fF*41bGm^EQ#sWb=ij3;6\p=2JFdeD>E"k6t4t@^%(X$c/"he=.(D7@FMVD\Cin;Ho19'2J=M.D'
-%93D4Ln+Wgm,:J$m^\Fj&PLhm8k^L3"J<!I0_f(">;@Q-+emXZFG&sTK31])nN7f:q^h8[F>ko^krVS.M*0RhtlB=jNp<amGdm@Ag
-%^TL?[oOKkP?\.%n_"p:M^%+3IhY5rMmA4C_R[4](NI,upk8$4601*o?+kX4hD7jZ0GIA_.KWW6W?LF2A^<NMgjVbCr-G.,r(C08N
-%P91l5OgD>U9pO)7rO2!5T@JI)+s2N\#)7elFmQIG00T(M>MpVR4'Xe["]Bl(3@^YM)lL5hfTdua"kA=V$_4c^+dKcYbJD6$#ZV]$
-%Pk5/"oi=E.&O8CRRrqNP,Wh8P,3>HshOQ-P![l$LW^[+n"6<(qa4HP-FR9Ms8-.>Ij^1j&^b=gQoq4=HB>g4*QZF.0Cd\QW>>aNf
-%]E`<[-7cag%;_0#Ai$T+Ak$c&,gULF\3A\3N>+$Fm;$Tu3_qD@4F4f)U:k:K:0=YC'BjuelqeNnn]r2.MR9ZYFDO$qEOQ#foq"XW
-%.HGM+ABp2B?f?=UGNkK^neEl-6u^be(%3;9%U?Q'*u"),I=58kB0/*A.H62Z`-,6KlW&R.3Cd&$:MV_:Xn)l'mXrg>OUsoKc8.a>
-%YIdJ^W%LCD-oVl+&S>MC;S/oImd6V>2qiDbF+<TSG0c<+FC46T(&StZ"'8+]-Ya;-Y/`Df_E-N]TA+L%):36g"=]CA1(l+dE1_Y:
-%^/4#0jYC'09MP7=6l^J?22dekO77&ZW<;"`XElHT/TH.9)WDL_l1SRI:"e+<NkJ?W<0-.I)X(TS2apXg'L0d$jnZUqpRo'<i3FJD
-%ER]e(i'E-iI.YPLIXXF!35M?Uj*.\N6Sgec13$BU'81W-1$^HsSqG.#>>4Br4^4ccZ;05Bo4TcHqj2MP-Yf/(bKd2m+,cnCNr\7a
-%l=*@6MCe+"0@8_J?ll%kAbr'&\)!Q&/6O`Y)fJcH^fZ)VDUHS:P7>JY&M-p&"t@?XG]l'/V?cqDkR+hnEsB>D^pSK[G"aG.A`nXi
-%:4='VS.%h2Tt$'?#Kn\Sj^j#6fc%IQE2p;diQIOp$hnam&L_3&^\B:`0e?/&N;%MD.Rn5A#R*j@Q=fsG)lR(d_niWp^t-i9jEV&Q
-%G%$V'H/C?#&ZB#4ZN<9_2lh^9%!0_^!JrR$#*N?!$Z"6ZMLZ3E7EI#"k*>mU<'^QRo6G8I<:<"+dt:tdA]%e)HP!<:+)SsP^5\e.
-%m<450&%l2u*4J4Q(eKe@5au'p$hWkb.b4;CWptoXF#r(aY:n(KID1r^:*4AGDYITsLBOrY4aufUV>Ofu"PS_?"Po6Mhn7M+LXg]Q
-%kokL7[h=be@`A<"aW!PuRZIiq1JTP8VH2o5EVqgQm'%r;r-eZpNg9:C2I^5$-m=S;>.9Ik]sd;=@8th"*ZKVdH,r,VilfVnE'B34
-%l(c434Y'BF&XaQB9?Y;ll@^AnB$[GqQq]+!LaTfM3a=F=dl)jBU(o%cB*6UeIHeSi(`5TogGaK!J>81'Bl4S6f#B7rjhWu:^enJa
-%*=)P$fY\RqNo,+K.QIK6o;&JK.oG=l"Q":q'Wq#/TPc0/Y:e\G=WJE<16QCI#;d-K/EL>g#QoJWEV4WgDL&JMj`KGkZE_tdfRqt^
-%Op">q4$4$t\(j^KrY*Sgp8^H6?QbYW$1i*A+U7%m^!N5>B`,<Y&k!8VcJmR&h&efJr9l]93<n<!P[U.$+*<2p^_a#hVM_r>?HUD>
-%HY\X,s0s1I(!Lp1\@D@@nm7si_.7<kd.oBZXuG8KmU7#-0+7Jr?bYtn_7pG)+5R-K(LKPra2cPh5iHm<<:S32G1YLa4p#QudcurX
-%Fl58Rc\bGG@e&mRY]tppbS/;lP^GJ>hE`IVOR`u\Qcjjqga[:9kB2BtSu=#P_HNDh4M(^l0V>/F[_9JD+%NYBK=&QMLf?0U^P2pT
-%]n*nl(>3t6Te!kDC,H:ip\?Kr[YLkm_]KnsNa[u250m"B<s^((I]"85g%cb*PiY8!fl@)0a,i6halcIsihpg$3m]o0+>i_,EP#?S
-%)?fN@F&on_M6V7ha6&**4Z.*Zf@,BGE5[3t-i&1Z?0e.cGF%8c=M?PFU*ZT[5=3\S!U/&_lW2MeF-]P5lQk.XpN+Ot',S3=1]1P=
-%?k-h&N994MRB4K.%PY&!6;O3qZ6h3:eZcC%Im.H]Pht$Rn?PGtDaji#Kh4H<LLGIrT,G#?#F/!c+]),_q9aS!"g%3Yr;bWE!!ICE
-%cr[XgaE"1&Ie6iXCS9q7<NGVR.S7Tpa:t=`<d)+]L>)aukEH%tb\b=_Kn5T8k4$3&b:0,,J15b!LXfOcI#ScH$KYS[^;b+ZYB^SF
-%H9$7K7'K]$hVo:&P#Xqd@`ZXTn?.BaD:]TJ_[#SZbXthIK<TU76XOi`mH^FW"B@_HXN2ELh;OAD5@7HL/>[ImrK&'US1-N'/&F@B
-%p1ZNr-JVHL[VRV"F"G@e(AEr>LBM`FBo2DHSkK,m<(*jG0gI_S4sO]n[6"J*35`G>L1kr$Qri"cajQfIN:97FS5S)/O+gC;R5)S;
-%_Pk4qkc<<oZt:<7ArnVj1FM(+Eb^eGB1?30]m6@HIB;\d33&KY"4X+!=7%ErPWii%q/r`XVq<2+?pFr54ZEZhW8k1QY!ft:8aIIe
-%iMGAp3gQ)1A&r'A##()p4_R)rr7El70^Ncb$abL,$npF[E^)ij\6Z5Em4@7'nHGA%qU]VU/,dV5fR^I640gIHCr"5a3f8O]UL*))
-%03<;WNH.\AF0353<P5ZL3:9?:Tb6Mo1[(7&ObP#LhH[^F-<KP*22kk/#2OtS65s"M%pVlMIk[StY6H\uEP6-iOY_7Fm:BkCW$K$W
-%qC+H?h>qOko(s1G)r?,:AWQ<gK8HQe87#/rh4rE]Yk-@ncO0E\m8T]oH!V6^>*98YYE>];;a7NhT[s@;!T)MTY%Uluo<l@;X"`;4
-%'WfV)cEG\["dW"nD#.5%6(KJ2[mG65ouY/,:No]p;s'+".:t7@rLPlblMhJhGoD*i=0HZIe#V!KW5*a"9,+#_2ErF?*YjHMOBn_M
-%DQGkd^\7!]0[;*\T(9G9QnmX2T9ke]?U^D+2jl5+MpFGo?lH#;$!6["=BQ9:+?75Cn2^s*_(rrf^afR^?8h*c-NMo+>($J(^"hkO
-%OjK*MV'JBbcaAb$lqLq8Xnm,WNPa)?QgcrT)+OATMd\`,LEX:l-/Qb9*&3.?*<S'E%NSo"rim06a/[?FnQa&=S/Rc4.h&1$GZ/V*
-%;_:"6.8bH>p,\X!;#OhCs*+;*X?:*;h]NZ0KMblY&SR$_Qg-fcpq9oAQ)p(3jR$9->\f<@pZX@CZ`gKgB6#)kj[2u140XKcC@0TG
-%#$U:XUnIk"c.jbJ\/D]:#o8GQTiKmlNNQhI]IXMW^<)\)B(_NU)HirngL98I&Mn3#moIM.lmM1uQpXQG!ntmmFaMV(0_Oc?B2]uS
-%4PkN@/`rlC>FlXb0d*+%4XrNH!>%r+aEQ+<:DQ.gTXJ7Zj'a#Lnk'j$!>O];MshaZYQMj%^!K@&6E:.4YYlhuaO\SG*<eTJmAT"`
-%0pT/:jiL8BC=/TCd(heVHrf05L6AId/?N:k;A6R(lI"Zd4@[e1bn_s+Hr]Y=.?2rVYlm93)Ul6IlLNAt*dDN&n[;@d5h$_I"-c7,
-%%QIAM$tiuX=AX3VG48rD(E,FSp3Tl0:69(!<Eer2Ddd8F\0=po<P1o9V2)(d]iJ98oOuDC2PJa=BkC+b]5u$`(7GmigV2p8Iqq(k
-%Mu)\'hl3)Rnh^K$:M@rJ!;PE^N1>+)(5Ea%q`5A2Hlpg@jRFS`\j4m%.\3/5j7D@9;pR:^cV6a";40j`XV1@R@6(Idc)jH,Lja?>
-%3V7HtX!50-V/AIW<b'Al>T5F@Me2)H#]*"]"CMoQkWCAN*+VO`aciu]E\PHucDTS/82l_sl[4JnopRe+IfmpZX?fZaO7cU+'AaWR
-%mQa.$LPL1A[9K3,ls]Kf'/tQ:(IYl/eTtf%Om"\ob`i/09%rOH/p&#A>NHmJT"un??e[J/"VTUD!d!Dt*h]`T?DN`?@gsQuYXn-&
-%A35L2.foN4X-V[2Wku8Q,r6(uA]:i^WB#"A;k2DK:,"qV*5K957@La[W*8FDE&HO1DNclT)'c$jcZUsYmsKSoN[EqEnU1eZp?d+n
-%<J-3<#LFLN\0jA]?U!/3qk@XQ4\-B4&0#5&G?P*(*NmSR[AK)UfoqPo"EAQHQ9t?t.H%RW%T,K^JF(-n'&%!fJLL]<*?.(%9K([,
-%o;C]&Xk_JF2GeB5Zi/U7/@4afoW6OM@'uPt276i4gQADd4H"k8Z0AD/%l;#e?6q*J[Wg6f7>^*`/e!o(&]MoV#FEX@i'8Y%^YYZ/
-%PBc=-rL0Tj`MIa#W*3*-s4lpo$`<G@E=Xrp*qc_.WFD.64rKbZ:bnp%S.0!s(.KSGJIj/T25XQSdr+qHR1F9F:<t=RS(h?skV36a
-%Q*O*4=D]*XJDX:ke\)Dh@<oEC>OnOD"kKrE;4D-tGS_1YFqoi<WhY!KoCZrr$D_W/b&[',[6nrOFZUW"c7@!a\p8^Fk6U+a-![4"
-%DQkT5$+DtQg(G\>T&'?V&"N9(<d%]&l(dJ-?;BY7](.8hhGNgPH>,Cj)"n/3EQ"iS-dA,-10?PKV!Y*bmalXih,?e'img.+LLhN#
-%kXJB4l#S)n9.[(($!f^20KJDCbUtRd;4o]?aPpX&S0OZmd)i"C?=_Br^75qpb-g*mf0QE(*;K#T!fe*n#4MK.&<c')Ze_iJZK/%l
-%Qb%Fm6dOAgQDj>03e-g5%m#\b%\GjmjT51J.SB]3b0T,5D3]Y<VKO]lXo?b(V^>ACm'dl3N*Y;kHp907^6aW<HbO.fqo"H+IAThc
-%!Rt0f.cN?]at[<E/TO&QpSu5a6<'OaSDl@tB3h=23`c-*J01c40G-K&2)t(L\MQAe91nVk7$q"p-ku)/baVmlU3=o'9bd-=@^Y5j
-%nWTg9WK[FG]-i.aX+\bZjkd=aZ)p35UkK^,KMU/iS9Akd-(S>+NaBD5>rcogDj9I$=*!Sd16'i;09cee=Css(96XM$\0A6@7l%?@
-%F@^^5GD2J"^bH^LL&]qk*/O8M;/J8OOp*:O04sItA;R&nd&gV50^.n]k@6mC\_ADsQWaR,nWghKNqM<5nXr4+gtX7Q3Eq4cBAXp8
-%aU>/$N$qb7"O99[A&BS`2n@L3g+pc,d$qt&,Kkh[E#n6\rY,r&-pH%iVC3cK:GIB:a?/#0<n?lACZ?>$fn*eUD2X'gh]%sA,=T2k
-%p.B!s[5r"d94ml1AS%F*YSY7i@Qjk?Wkc/.;@m>GLuJ,204VHXZK/p5QE-%AZLT!iVFEqJ[d[GU]Hr[kcY&e#Wp=,r!gjSfVg80F
-%S%H>_'FRHhWC`\q=-[WQmqPQm?I@nYK;fC7<EC?;)3jR5FLTc<H)5=NVl%AGpC,5J6clI*V5bLi<b\8!'`=Jf(LSYB3uPrD<1jUk
-%<.Y_NZ#<+D0&JMbV@^<Rd?pfFUskd!(JMPaS-oJeefYWW;B4NIoi,pr]]6>p#"=5KXrN'UgRW3k2W,l'VA)M3.u"PbPP5rQg7De]
-%PN*5k#_dA-&aDe_\E\2f]+')h?M8K[oa=paZnJAWANZ`>oChj"_:4T)iaUG4*)"pM91N9ZC#3VS?>q-slhA+SS7EX?OFj(4WY4/j
-%f,)ecZj%L)b4/Nd$Q=iIlHuQjpU0)KpIghsG!HhoQjSf,nImab;q\;=o%lYP><g;C_96HS>-F[6jF<un=mj?r]"QlW;Y=r@YMrQA
-%UWCZ:k^69b()oVpIH92TG1Uhf>ZXng6ZO<]?e?M1$S+.HCm/l^;OpjK#3#nZ_'7e\oQ17Da,[cGMW2BU-1P[<+S[6>?b,)Gf&hE#
-%VXLH^!h!SQh<\(8JR^iQ+mMsgK8L)T/O)K1.Pf6"o).Jb<.XLpJ">PBCnKP9@3`G\a1ae>+_;`>s4h%=j4)o?G(k4*ph]-\e`73K
-%?m=F?aW)^mY52]@2n'D_USb*kNLf-&6if3qgH8dILnhECM!B<"H,d2^4$dPuU(@O[Rh_ii%^@JR"U[EaJP[?n[qA4'GlKb1#O1_M
-%\)9\N;=FS&mK\3%ieaE8^b5rM6jqA[nHFlKZ?bT0o?6!(W\&(uLsGNP<+=IFLTl/NG/sPb.$]@N:#%:PM0@As\WR\UUJRJcGkP+W
-%hSE-0M@`%#Y&&NrOso91`X4Xd)7^j,YMIKB1O,hjCY2Js3QUoY5%;AIB$4:*lBs)b/7!(Tj$5HLTbTl7gaOTFg.re<:e@0Lf\6=O
-%Y=X!*muaddh1tN3pbg2FS1)*PG8N-Qn$#lB<a@'YBL)EA^2%+acNQYN-;6aM4iaQ,hLJO-UbIqNI5-R%5VfJ!!"MrW32j*(\Bo$d
-%MGf[&Y7Uq4()2YVF]m8jb!:?O+E4T2VX3R+2=O5:SeuJ10T8C\J)+A$*p8V82W.W<h[m>:HtYMq^<<CCjhl.%7_;uMP`IOq;'mA%
-%[VkVX`2S7C\l&FlUg^ic;5\3`.e4Zb%5T$0(EQV*MV)Jd9\='Fic'?*p.a]0!9oGYS6aGJ[p%[$HhhjOW[rpgO-X?8P*,95GR0g/
-%NoGLQGtP2"3NsCEe!GJ\&ZblZ.6O&`!cN-1IYspDYHbmaE_D^<U+u:MY]$SVB@!SWGi(80\8;q_6E;^6/L2f@N>*\3c>C!Of;[$T
-%G2ZQJ(J"5Jci#TdboIX*jO+QI;gH/mr6V(;!+p;!OSQoIJC+/5bd2u?DD"JL)K@ZfVC-Z.K..LKYAl:!(DsY`L!2O9b5l'XJN[64
-%MW48Sl'*b`o3T=uQnCdKB11W1Pf(;o]dZmO3^kn5HS\^,QT`pS[7Q,e`SC@<'/L[r_aW;@gV*Aq?l)mPf?b5(*j;m%j[6<MXBTTS
-%a6hW<cTmFGh'q9mrk1f785__qPPUhATqaP@A0F%3=k6:V\4rF9FfC)!^!?L(mtFrBJu,B_W\Z1XfflHqBQa"<DIASHkOuW"'![Is
-%+'>6\6=Jp:3ej?epjK8a[ah=\8g5qVYi"Ta0sP`=fm0K@R<#`T)4'\:?B&jFDC4C#@$P5].k8W>k2d((;2*[1Du4F<;#WadD7nD/
-%dH0El1b2>[=DfA9TTWa-r:`rSRKT;P1Q:l=1&[1.CF%a[(*cPG5uNu#b6u1C!gW&[Y^S?(caBF<*5R$Pc=rqRC7I4ZMUO&"W4r_E
-%eh"=r]i_:ICQs_k^Q40f*HDRii\1V.e)WZ[;66k`2BlG2^1/.6IhVdoV\jLF\ViJ!FRP>J;(SrK28>Y@";Tg(hti&%6nWG.$<*8C
-%[N>;s([VXL@=pXq)h^O]>r2#2B$GIr@n]MAOnTcY1C"ct2*F'Pal&4=E3KXjKh0Yt09GAp69#t\P3P)RkTr;O_TT"R@]?EQU=(L5
-%eone1S=:A6,6ES%]sHK_2Ie@$71`&#B"uYh1FHC9Ln7W;%EjVF#p&'Dn7]K7*8!p#DKJKYQG\94YK@pDlEC_F"B8q4rQ>("(ZhZI
-%9?bMNE&)UOPC&^chC_,-GFnLD!7Pc%)96=YCJ5AU:64BJ[n^<O#lh3]:'5@CXr1*@X;@!O)aV8]637C^"Ud[N_*+%N[1&RlO)9pY
-%X"JKX:KB.:rRJ,b"_D<^o5kTRD0+-VY1P`1eC&d#a8<b7jV:%TXKoeUPLiu%r"sOapd4OD_m0?6=O;]g.=aHBM<a^[j7mJ346,T!
-%Yg4\[(nQp;l""TaX8M^^=oQ/&Me]Cg=)&2pn_Co'T]JmD)t?DM&gm8Ae2rJ"S'g-JE96[H2]hX14pWM;8BsjA[W"q8ICLAP@'\J[
-%6#a4*TpfZlRe*[nhn3P'NJ:7CD>b"%hKIM6,s)T`JprLP7f[858!Vu"eh=>r+#_i7+bMTX_%;DL.FEc(!ldS5H@,+g,%>,ShH>%*
-%CEs;mF75PY\Z<$A1=o#aXIJ6k/bT.EP5nPs5%JO-KI'FF03,tiPsP:)ZCpX]4M.qooStFGh.I>6=48^dWh3`j.[V.u>?A1FZ,pQd
-%7%cW2Q_qFOmLEqTQfRdFW$U^d#V0qhY:8%>$9,dMW*JAF`c3Y.Y<i(`9A\jF(q#!Bb>6@5p)P.)UXr=D=1*u%S[tN](@u&GE,@g8
-%-bh)`/>]Bp>tS18LggQ;M+45bMR%I'(c*sc7GRX.egh_eC')u+6F,>YiX/bi;#*g"!B7'MpB#mY`j,0pW[\h5(C21K5cut"k"I7P
-%VtkI3e^'jYh;(i/TPW<;p5iRZdaIlF8<Iu)FCRSlqk>I>_X9>I-A"cuAtm;J4JQUA&F"0$a6aG@`oA[;s%G\QBt*/#>W[MApRG/&
-%[hk>t'[aiSC2::a%E9"6Sg&`?U.+.*1r(Xs1K0/Hnn'M%2DCHdb6.ZMnf^Bt[j7.'=c7Hp'Wh8!<L57f(UCT/1T7TfNBM'M-WE%1
-%[G=m7Br,mi^5i!$'F<8-<Tb>_dl&_C:i@X`d$f7D;fmUUn$^;1'Y2J#@"aJNgU]!f%W$#$->*liDgC9KKkeW*#AEkCI?EerD%QqV
-%6-6p?FN'!5Z_iFLHD,a"^Oo0ETZti4I5CGU/l76ZXr>)^+];Z_La-3H(W+8%BD-/TmW#H/,4WpBBZP,r.+GCMncSgUd[ul&1kd^k
-%?kiD(g';D)V?Ml6m/_b;N80Z+#aJGYpk-+R`m$^eM]HA(9kAY04adTIAHacjKei1j]pr8D4.X8@0lE$&Q+OD)'?)e)`C"C<?6m5Z
-%rC2@I?:5pkli6Xhiu691iZp/#98DC#U..[J[s").8S\YfSE+bor-aH_%_EZV:!D#\`3:JLrDIGFhA&ihUqkrfhH9B_0$)tF9&'G;
-%5jVG3.kg^DXDsV<9K;/YX&j'KF@@B)VSEgQ;6Z:;;BnH=63kGf!ArQUFmAB7PX5KLHj?(nb(/criL4aJ0_6.+_$55!%48r,^(h5C
-%"g5VT6?5um4%3)."B6q2U,&X9GYnh#D#-jo9Jnj`3XuAU"^@Ein2\V9egpC$CnmMIAOS];aV&s6e4%W_?R`pt"95k=7qG*kOGnkB
-%GF@&8?]?+=IJkVe]ul6201FL!QSJM&K4Wl0\aXO[;KE(sEq*AX9:.Z(oNRM6gBDg1D]hk[*ZaM.7#Sgsod`\K'X%mE;Aun46T[7V
-%1UoXc!'9"Oerb*K*%5l$3luX5QALP-[r=S\M@i6U45Y!mqtmJ!rh`dZ,0`^3VbM#EloPP'1U8DFZKs:5jJ1(]AHjiAbTI<JDNu.U
-%BZmp;Z<:abQI4I.3p#U"7P>BpSRiJ(Jj>;V.pe:@F_.E@A9Stbi/)Om1FB*gkFsrl#)G99LPR_9@-pRKLpC)g!^n*t5ac@lFk^JD
-%_B[Gu0WHc--)YpiQ*Nhafk)6onO!p%Kp\rI@IDOKh97[>?4E8"SRqm'1OR>!LQo/IOCa_>;:)rW01$9o3L[B@M-7<W_QZX4V5i"!
-%'-F_J>3',[\[tal/X2M:.+SVN3$Jbc9*p&P!]Ni'^EMcH%E=$cd#,N2$[/N7'm=G^s4<Nf.podN@UW&23kU]%1:]u%d3M\U')AbY
-%I]6l-'jtXaY&#Q3'Ri]cJqeG7%0?W:i@nW%3\OR=*)kcJo*Q78]&bd?jrTtA6X6+m^`E!.ndJ.QF_b6RGM?e?7Q<XJ)TU__XqWHE
-%h(nnRhL*krL51'0FIk!Yf=Z7rXr@p+pOJSUPi#p)9%+STXkE4BEi3)#d4b)SbrBqMq\p3]5EB$Hq4!WI\0Vh<HLEm7@=eStf1#QC
-%IGoGUq^)B)Cs#B?j)r[t&0uG6F+5cFnB.oeTMo(EjS**s?%NM0=3dpR<<kjR1S$:KKfBh=KL::92/<BMhZrCB,$FU>72'fjVt(4M
-%^7RLhc^^+Ef&Os2a:]kl/FY[CVl)ZXgMe'.a`cV21i%$NaJO];M(7SOddLE@Pr`+q6N#V++l3je]X8N4-n/+Cr7ZP?`se[1(>R@h
-%S@NG=aXZ0l&dL(2jgM!@=)QEhEqbePA((2?C2EbFm7Rdt@FkuX^"tu?<sGeL`FAN;1L*$s*:b^QQ1ut8eCdAbf&$k^[b6?uW2^RV
-%$KW%#TODQ;4TSHab-;WC(@o:%0X#)I'5]1+bS:F2SjlZ'A0ukGKu+XDXAK2U13kOZY\P+"TK:\\Q;doURVUEo126V=,F]BWJETO#
-%,#l0s,:[I)kTk6!C3-p_V7+`e0!U:WUThDWXV>6h[jS]'2003mNn\/D62JRS?jZO<>U`"65'HB8\\mZ4(s_f?<)FHW+'/]\_r/8#
-%RKD`=n%`c*roJHaH0(sYS*W2L192Yn@f`(Q3O!mln/'&!Et)jZ$Yf[/`MA;t7LI8]5pR*U/*B_:9<h25g-<E$j1I*+IMo!3@B0>i
-%cuO@Aq1c#t3Rhq&oFq"0d>pR(?umkPDPo4km7,\dmLY0B1^c=6UI06#2[XPPGM\iUgLN^beoW-]`JPnbfYk*qhsGfF\kp-2BCZck
-%jXeOAS8Q"bP[(Q0n)AL\52?-bW;[.3&3#IZ>=33cXjD8A:gWbpbfm^iM0,61r<M_^E9:*.(RR;?jq<cT'KsacaK<LA?0W(T#WQOF
-%<lMVLl:iBs\;%Ysh(0qN7.n?a8+9oi[cI/#rmYFJdf35FWrZ\U*r&ZK_.Cp^(/d]8G`#M]%bQ1!_Qm1>F,mt!MEopuk?Yf>K6gl?
-%(q2W0R.TjL$f\F9>W5W)oiUcfm0Sm7booK]j=[<3D=.=J-_f1b4?^(2-"#L1)f#OLh,UqJ9V864K0._s0J;Ki=sUIkT:ZaV:>p3[
-%n=ZI/oj&M"j/J&1`3pthCQE-f[ntEg2o)GcpK@?=OnZ(cI7ZT&;KC'CgD66#'W9,+Wr&A,Y;'o$7A_ii<h`%-CBTaC]F3k(7aRoO
-%O0.k'/t.,HF;%Xf(_]?(Ae82&QbPlUZgI?o;*]D]+Fu[X2"/N?O!n64.gfECO-3*LS(s$rcj79E&uoORHq6;4'XX?e5l'(n(qW^S
-%%2s:X8&dN'kd:gJ/`q*&>GmFXfp7)cm)Z*[Pt7=gZ#paiA_5j=D4p]TQ`gY8nGkqZKiFedmL3!F*&3Sef9`^!c!<T&LXO[WM>i`<
-%KLk.#fq22Npcg@`]/XKJlP6=dl#09R(R&VhD@.;k4`3M\o<q!pE?K:Z-tf2DW1-\aAa[9c<_&9)RVVT]Q6[Wbf'S\N&rC^lcL,Kq
-%XYF0+194Kp((%F@3EJbVp7d:42]97nW$R!3DBci09+MH0C2c8k.X![5UFXWs!Id,&Ja!O-m?DbCMI&'I[])DkBUa$SmE_9U5dS5P
-%HXE@(;S0[&>oCge`$nGkC:jS4(F^q(#NXYI9^2?VGs<3#ogO'13S27":R0"(jXhL`UAL.dI-RE.e4e.2o"4>e'Doi0%S6FSk:h@"
-%O."K#CdT"WI8!`3;s`l0P$QH],A6[p2EA.;@,u_$a<IF_h(,#U7$sh=1sqZlQf6OK[d@(=,]eX6ds5B^M]<@7hVbk\:Km8%("l77
-%1ogDu9m/QVj&"pJ(8*r4+C7c!'\k^X\OS711NR/<!$2B]%F;2![Q"H/;!3q_[O6k<TSF!?iGC3u[A-&@0%\gh1p1#$mgt*QC7N.F
-%Lr)#b^NLo/qpTKR^A)i=o,;n<)N'ck@D1IsF\(*/j]U^[IGqAVhJXpd=O+Xf37W4C]6QL(6,rZR9l6dpC=4)p(6PBi]mEfE"OESB
-%&\2ttos]f(@99]bV+jrDl_T?n.<t$dMd^,5;FJE#9%!E)A]QuO?*3k`@qdttA(hs[ll#$H"pSrE]hMSp]m3'cI0F:;:\>Y"Fc_i8
-%,7Q?'>D^8A!.Q=[Z?0g4Cth&HCL4Qd4#NP5S/h5.muPb:\0ORScPg>P*#qi)EE&*:MAYMG,oVX-YeL^k\6TGS,GfpI>#r26Km)ee
-%92u,DGK^Z5/HL*[ZHQ;%n972h@>XKFma^$3W@)-^$=^9oG@"H;4*Q^FDYDg.[o-+G@G`SHGDNINU+gK,C6*(Q'qE[7Dl]nBnVQr3
-%5_:M',\`,)?Tjj"#LG6q4(r@06GU#m/DZPR<JS%R%:G($p#u8-`:!A8kL+Q3oiU!)dKOrtDLfeD)k`t7D1*q-adoS*%[Ei"2I/7B
-%\c#WHZ(C4Y:30T"-[4o[8lSY'Rb3:]=ec`-0Ui<!J_#6i=7jnQ'g,)VFXr[X9+=CU*5\mc8fFecZXp%L;%*B20864e)5qSi9<uKQ
-%e^gQ-fagp0jS7-#.l-O!)!)a!-#i/0q=RZ\ECG2qIXe<FJeSC3L^`%N.484(Fm;MRih'+T/%R050oo$L(/g@ko<,f\(V?nmb]j6T
-%:1Rp#-Kle0*V9?di=e/bbU@]=?*gW%Zf5+ae^5=i'%r=gQgLQ#m&j;k-DnpE@9?d#Yar4>Wb'R(U4dqSJT\-Ibr9YBn2nkt25K'!
-%\N9PVis$XYTcC_M[T*%#$/d@^]Kln+\'P'jr]<BGG5l^F6qE%dHrMqO.REa3ME)hB7EhPq[D&h00d4"Z#6Y-.V&%j?#T0HLcRYe=
-%$uF$jh?#&D"#Q9'e$Zee28OIbefh)"6;<;U,7Mp6A>E#r\"UH9g2q<>)9W%WB8IP#O%jDT-WmiCJH:CiOQFWtXb]sd<6^"?eJ<U]
-%JU+a$'UlLJXl:5oMYF!'IL!l`LiLrhfsqcsl!(YSW`8]S%4?#Q;U0AQ*t/D1CVoZm6K0N#]P_t'"5R$QU,r+WHb[fJ@qE'#Z%H`p
-%aXmnZDf<J/6EqDKgr#<5<6K%D@*;keQ))i5,/50gibiV`Kasu"&)nh!:5$k$X1\m0$JsC]p:^(U2Sc/[;H5<Df!#4a+u`obLT^)[
-%$e60Qk#/_>6n9ge5;KMQ8k@?)j^P%^HZ`+k8E+)jl7GThh:_T48R8SS[cMdQ4K8(ZP6o)#9Xh0EK/%_2(9=UN^?Hl8lJ6du264kL
-%3`d-<<['a`58004Bc`qQ`e-]0?nl)*`ia:(M=N@#WUBskj;S?VrARrP)F-I:-\]1gW0h_agaqK5`]5:E?JDb"3u;9]bb`q$U6'*]
-%e9L($IZ$oYmD."M*%qmfmtsn!@I.^?[qd'b^6d!SXf<o0-]d-.d0SQT"c,C0@Ufig@C1d],G^,"a=2*&J*iZW*_KA%]1%k95$c$r
-%NADFkc&K'>cdBIn\5gHTkCu:';&5'V%7Rac:%;VuF8-"?^-_D:mZoU97[c`$T5MSO>Ep+7GDp3.X=5R9M\3BC/)b?.\M#SK>jk7A
-%e#=pAs8"QZrDH)<?M^$5Z7Cmd%XYt?Gq%S=Q**!<m8"<]&!^r=3TqRW91a(!V3(D,eg7bdQnWVb%>?Nj\W<<c!`'V[57EVWbck0l
-%DPZ.R2f$gGg3%0'9Cl,)+p^l'P+tOfQfJI!oVC>0=!pZ.F8tNGld%-WS/JX7n_:a;8?%P"hbuqr]U`Nf!="EAV$9j$H*W8u8m:ss
-%;5Pj7oK<R-ld8Fi0F*`Pr[fTOeVgXp^1O]n)p1tq;&'ZVT;^I<!`S8+1J>Ff*NEH!1&?>O\].<r!3o,gnAtN4U:<cp8!J*!N9PIr
-%EjE2>lO%p>C6`f#O!Ib*,K4Uf2&+';h6afD`_X:e6PUi4fT;sOijLm_W8*>&G'Q1+Ql=7p_T!-2*r?mf-F$bUnPY`7[KP!@\)'LA
-%cE;<,%T[6M\K_;f.J/F9V:$&Y!7Ck/6SKT_X^ZVjbK]'cIN]IKAc@oA=ti4&:jYikp3XAD*U\5TCKp1()PG.-+Vm]e3='i@U^f9X
-%dR!*Ih_Sd*gD&X:)mnht>s=@Zb.G6&eY4,3*<ZV4f+Pjb4&XL:eHh9r3Rd&gfJm8iKGO,X\OA4$6JcE)c=^V2Cf/7-\]intaE?oT
-%k`I6:VO")*o''(dLH]V$ZH*Hfht"Lu1\ImP9"JmGRm(^Y!B'na+,`9+(?bIP2No_QF[&,S_u$!:apt?*mFsMWpjGarBN"L8ab6#p
-%04$,o-2>'`eG6s"%eZPF*TE;,,ch#QXt-[jAClc&<&7-CDoV9VqLI"sqgr$b_gX5;j<mO`^2C*Sp9W'SH&G4>2gsO(\Xp&F=EFO!
-%@8q0UIb1c-MS$PD[4luO&$U16b.OJ?64X(o\,qFI5j?[hFa#LnlA@pdN=`9O]tnB/o]_'pBW`Rk^_MS&^-@PkJSYF47lMOs-`:U3
-%.UK4['o9J8np,$t4@<6%-A<%#gQL:Bm@JuI)(>o.Cf%4b+tp^eKZ$QoQn4:6n0"4<WqJ\U(Gd<5.lFP]^Ms84*F&<5,D@Hc>@>l=
-%oj/XG*U@::SbL^1Gjj37ZgaBpK:3/\7ha)d5PJ)8>OTIf2Esjj%t/[%OL[e=@.j#XpL^Rg%YQRYf\)B`f5ck2\2)X`D91$fDteCJ
-%"`M.bnX*bqgE61GU:NfuJY&W$R[r?pjQnKP)oM&\WVSKa7ON[9WKENF)`GL.L/U6]PaG)Z?$./'.tOc:h8j&@hAiMt`q0/cX4c6t
-%lb7[GQ['m5qB]4jk("kaIK`3GhHHP=`)SJ'<a@Z\B&D-(+PG5LRn*]li7i7gg&9Y,M.doJm&:L"/PIas`/dQVna<)/feu*thc,C_
-%^5*hbA.J5^0H*)XXnIaK1)e/m3Hi#'Ffb;(VeU++GC$lN>@d*lgbsY^UOrFV!L9*3._"WHNs8ZrluHNd1q3h/\+@,eD_$1k)EU#l
-%l9f1;jP7uC*SJrp_f]7Sp;u\JS$H8MV<md:'!-V<Zrhbe>gT&^*oDp^IZ#aOaMm/1L<e_LDOs#)qhT]pg^67+1K<aU>E6S'AnAVF
-%m_Km"UA!D@PNX7$!$-4*34#e(YDBC9g(:7lFX8^5rPis"2>32iO[!LprPcp[>rmKlTL+fT/CAgH6d%b7`/GRsG++7s`q)gF_"IPE
-%*1Ghu);K5q/'*T6'LqoMU;%N,d<Hhn&(P(fF^TXmYjo7Q-g\*<1h$rlNX\6C8r*!FA(b_E\)a5t.H<%A=G*8hIfc07F,0?='$UNp
-%;?W!WHtGoYfDo^f0Rjc1o[=blIG7dB+.<Be!e892:!Js41F"o"]?RBr=K52THZk@&1"EHd"`_cOj/b-*hXEHJ8`+odFTYW)<E(j9
-%h,.08/b3ejfTG!E;<g$iIO9RX$c"TdKmm8-mHL+BYbEju7l!hNmjg*!P]X,W8AYY4G4[u+[tD<BONVK35((_Yc`1DHUlk$XSSS&1
-%IcZk7keLeZ,o9H#mNBrjN9F2c3uY2dQiu"TRrgUh)o3Q\\%]trEKFHEalO5m3n-@D$V7!!Wdi(-e-*%\C7U4pf>B\;iUjmD]P9B;
-%1Su>)lkt<\Rh4T)-`HPh10%aA2=eJ.D,ZI]r(^aZ%_)RdQ:>-ioQ%qe>\`b1#!`[U^;qjqh\A$3)X"\b&'EHq[T9I*o1]b\J\/6T
-%pAPKaY`s;mek9uGb@\5j+CH%31!?\a$t1SO+o1:Ado(cO18&!S'"qDR"3EkHo1BV'/O:CHoPr`l=Q;GKqcb\a[a-6n-hS)<VjL<u
-%.*uXX*I%l(l.;qoODeeAih5Fn>%/$KUgS]f9tW@nJQUrJ0`ZkV+fe1k];/Z2iq?k`=!N'SqWuA<MWYGQZ:HF6_&b,kef8#!X'_hd
-%8C>Jt`f1L0/S!!AphEZ1m'`Y#]dJgsJB3cL->cpa8<3=MJWpieF?N0b[lL\BQ+#c5C+8,Qilio%kZ^37g?`g7p+09crP8N;91r5Y
-%b\S&P]#I@jU26BYG*>n445bnGgaS"Q_?DM:?HTsFlkZ9NF.<OsW*ZdNX0Y751T^gla'^k0S[[fKlK6>Kn>lUjX?*sNPc4@sUq!=9
-%(1uH*eOe];%Xj73>K$W*`C6AG".P\JI_sI,COu8fE5t/)&"83sCn[T\[f1p`\Q,q>L#k8-E4GL$jQa45JI,l;fIWj'2K).t"X\B@
-%4?G$(Wq=mkDG&?^cB'+9JRp_:5k#M_^Sq,0V7`!JnO)H_>8?r=.;4M0`7<-Q$<na&Ne+%&E>>7o?%AtS8aL5I$HS/hAT#Jb:%4c6
-%YHZ:k<^7e;\o-E>W:_KY[Zl&YBD!5,>>Ff;4P5%:;2%G+<m2:d#F/6Sg=:JN+N6Np$KB[fo`uLt[$s54[9Ntf5`#,=JOpXPfrejJ
-%^HU!1#$gfP9&<KNKF(]N3RaYU3SYDHCH[QU]8$VlP"L6U'\V5H68/\YAB(QWmaeFN"ucEYDRU)rOQiVJ2M/BB,2Z:FGcL'F%Cu:4
-%G$:9+*`<Lf_rX)ti:^ibBA-?:^[ID6h-KQ:,3(`6&)e2uf06nC/M@=G.-RJ'+Z*D_mGJd90L*:!R`&u7^"`)p\uCdZRDF3:5e?.`
-%G%#2G2n>o3D>ZX>YoufjltO[IiI8LU>`"(CiG!/;Z]8nuR3i5`#nD'HQl_u0,>*<j8,%h1ehO9dAj2.g[II2\nSUa_d+D7n\f"#K
-%+h4h>*?/6c94S?#NL,l0n&fE<Yg^s*jJRts[;QsS,FY5,7CM$/.RLe9],o4@&"2O!Nk7h_C(\\79COjEktG,]]':HP'uV.W7-r,A
-%cM<H"cGPJ/\LDPf+u_@1apjFLgR<\%oZC2[[-M<<N*ltA'#Hb0HJ3KDMC.$il0m.2d/YZOIBoMr::SG%l?jR"TAge]dCl4uZGa/N
-%Pk=16=*%d>qH`2U,$TM0Wi;GF3DJV8k_'jB0g+k()/a&(^TGj5G3b/(DS3>+XW)S+hSUWphPJ3lgZcJOG[qr?9?Wu5<SBu\M>t-N
-%a^kXJYf#FrZ,nDGGB*6oIk$4#c4ZngmYe$YZ9g,!+>Eo>Q)D66RtanEno;$`Q`X`FiBG&e'-N=[df<;$kYVjD46^\%a<j`bA5Lu3
-%h0oIQ2AE#6pb\a$,IbK1[YsW*$?+bFg)F.WH8EtlC09Xc\rNN7[OTlU+3'78Mgj)3"c9,UArBiii""=o(ehW%?W-i^<(M(`2tb`4
-%X_'I(5^>\aK"=,0l9,6Vo18beia`BPb=E@,*nqls37cGoKu+orkSE]hM%:*@c#/O%jqZFVTm`3F=+A%RLg/9NXQ+;J:A#AJ.Gcs_
-%`hLgdh=XJ7FC2Qn4*QIpSQ>bD0]ni-jSuCamWY=IbuTfsd[Ro5/<XTQUYpRfVLINGYjUA]`#>J<e"SRo?-B%T[9<nPai,`>]j]CV
-%IRbqo\a1Xi_'N,84dUI>eJnOkef.?=)B&)X<4f4S6,K#"doCX]EX%2lX#Gf+$`6/jQB!;GM<bW8A6r/3;(>5[F2dr[+XDaBdaG8S
-%e3.HC2\pK@Jl*.uFZYX7oOBAZ56V:d$Im-M<qZ"SCU`oD=MCmK]i'riDlIObjU3aH,Q"N?L5TMSk@iS3DOAu^;Nmcm.J+,2OgQ1q
-%dMh,)n%l'!g)>ei1;5tdh@W!:ncld<U9Err0'sFDqhi/u2kg45]YASE;%<D?AC+dG^HfTCd%tQn$#[L85?KC[48Fs_Cs[gQpoOOs
-%1WPu>CKRQcom<G:ZIc6#r=J?gI``6I2G7_!8!M?H!bHJ]kd9.AXg#0:%Ga(E1e8&7>#j!?U`inLk4QDO@(e.tW7HYrE<ED!lR/uh
-%o`:K8Ro2/fY.`m'BKrdmBM'r^(4:d?B>9;2)c/C3<@L'L:mG7L?->,Eo/;+@;&I(]N%4-hZ9,_NOI5;^:I/P<XZ8Y<NWHH@hj?(?
-%<_T>Y[C0\[D0?H;!&sp\?eu42VKq8K"^'SL[<iFpIib88CCR&ea;]KTB(Vtg2naaM6Jpb1i`7n;hS)omEK7AIY5pE7R2uFYArIA#
-%W7ki_`]E0Zg5:i3`si5T31`c<;DXB>1G24%hs2'1Gl$h5#EUY<0()lgWJJ*<<3l3ugni"B(Z2mg01.JOs)_a4]-GIRe]`f%!.re+
-%U0$LL4uk?'<<:FJduL4nFt;8#U7F4KDmP7&^NF=n0qu:8I:P^GNd0NRb&SnTeICkfd%c71RKL8o"H6,d[Q&p.\du4m<>ElFi,9PL
-%4!Om4c'uihj5*e6I]>=:YrHo0c8?2QA\'&p*b):l<#BZ=K"+`tkTP)I[GFrXa5Q3`#,kZ1$88H<6D:9+*QhVB[m2ZZp?7OF><".1
-%g7/"^YhdI2^#/[;3:Z#rk"l'hXL]:E=%i0+h,:NTFR`"JgW_ukhE%CdN1nbd`c(&;12+`.n5h)hRNBB[jMq5dK4ZQLe[ll$SasAA
-%A^U]5R"q]N:s@-@649)n9T\6Po(tDKmrq#e,->&lA1j,7X9BfjAW1aFL#1<gP2E&rQCPT>Rc]ZSd1P'[iGZL)4mjM"+pp=2$+DY,
-%Ri$]U2][u^V1"8Sm#B8PTAMVY3+k&<=_U@aeP[VpP$'7"lW[*(AsuO-Xe)J$Y\U!l.AWbsLbarthTT4&4H0=@%\PEC@p:=ZN%k5f
-%#Q#7di.3n`:[^i[5Wh:g`DT3082&&so<[j8Hp<\:2j/AKQ[5]!8dMMG`>2nGLJ-q3[00BZKH6EWmoq>BDi];K@(^2PB>H6M\cDgG
-%YK6%&V&Ji[]DE/)BYV/>#LMc<.bp!Ief)L0VUMc>I4P74[Gu;kcNh_HO?*&.7JTg1[Rr5Q-YH(QE48mt%(Q91`8N;A$/s<VQe9P3
-%#1ssfhJ_b-gbDWTd$S]"mT:aL.qJ<XH?sSsoBun'M[kRY;:RAW`f2pg8?f>1#Q`e4&TkJDoMLg(KD->6*?/"!.8<%7Y?M%4#&u6k
-%9\\)@"d"udHlmun>?^7!&>uC8(QR.b,C%U=h0e!pqL0JR\%Vp\FQ"bJ[F(Vk57OnGL4-n/K_4!51bn!3;oi$<"=n"LEmP`^#MBJR
-%T@h*CBqal-\pK&1(g5:U>%@o(h2'B8!SMo?QCh("[gjCL`VlHTA1c"DWdrV3'3QjOAhG5-l`$HDkHX]A1\s]paD?>SMj_Of'<U%,
-%qZKd`AiXEOXdAIX8C%C^i;`.5T'plrq'bs)-l\b"CM&U:2B(H-A^S.Y6=XECh/-'[5RKe_C*>M!:h8>HV</CTh7t,GZP;rhmEX5U
-%U@2,aDi+IlMd2BWY#1I'oM#KOVlsIB[?j7d2D2W31oso4[t@6dSR>Ksa`5Ytp+Z&oM1N'N=[[6S'Hg*tJFCd<X\.T0M6hc"XsbEL
-%3u<-t,i0133M*a8E13JW=r8@PRmYSs_D)"pLsbNH2F0QCLa1['#%g#ENO\j#0k^-9qIs\'L-k9@-L)ft9Q)dH5*u@)2G&G#Q?s3t
-%,iW[g1cG1Z9$-Y\2`IuV!W'#UWH$>'Ld&f#YIP9*4+mc-^TolY%,C"B'Bmj#7fK&`D0BP'e(S\PF6e@(Z,NCUGN722WpFV(C?6X!
-%"HB51p[mrkq?RB0ErtSSH[BGc,PoCn-%aM"nOE0.c\$V+GIlGEB&5^kUX:H3i"gpJAI;/A0e6V1hRq_ENK7p[E;K/s)AMV4hB\Ol
-%`V89i&T;37`2Y0eogU-Z(\/@]8ed-sRkE'*J2Y#_"MTcMQG6sEYr_"Dq"$T/H?4L/ek%;l7FJZja]0n9CXWX8(l_"/qnI;m5pc%B
-%CXu\=G$+]khX<_=AkYp5\o*=&M@HD-"T4fkFg>k_RX[O3nNG_5;s:Zk/1n!55qLq0UhV@2iR_rNHUVOq+e8KHG>T*fA2YUE"Kb>/
-%mt0p37=kS$g:P9.$A)a;DcPare8=:F!VW>f1pCR$:%4fM(Rn;0,`G@i/ncGXFp`P;9BofPU1JCb!Rhd`_5@P87qRO0:)UiMIOOI1
-%Q$W&AgGB+n6IYFk65IaY6sdZf6$'.(0&CJ2G?/TWllh&U%-:LR2LXc=Hg<*pFn/;8Egt3herFqD&CUs!QB25Ed/p8G<>cJm;M_&@
-%l%&GW_7ngpVD#bOo"Ai&3Vr/K3cE8PltT%HRFtRrAM.b<1Cnm:jCclT0^(bdrReThMg^!L,p0o$F"L[;FcaGh@!r7IoR0uX^(thi
-%!A)D!c%6-0i)F-L^Gqt0Rq3fh"E7e8W#>j)gURReZ-S]*iuMec1-++G6ci_MU@pma"MGn`aKCpikN8_+^CR(5D99rsG1J[O-1MH4
-%^r&\h6RS(!H\02^(7u8%SF>XGoqTp$3`/CSO!O,9'H!:1KIq4)JO(59l@k,:2bcl"Q-P28m+7!Q#uuf=bfI.['C?!%HpOG6pO9`%
-%Nj2-.6m&JHm:\%c(OHZTVUibuoima+^fX8rqeM&V<+]J%(e=qO=A^-sn^GZ`U6F1ErZ.2e&F\;`oU<cF+5W1iXH`MlP:'ufj(0c5
-%*I=&CiB>1kDc7on^pt?Ser*1<@`AgkiruNf"qZ5mX&Frp<%0"'@74*+;kWiH@hLNU:WCs5A$A_iYG'-o)NWVsa#5J%WX6uc$QF_5
-%FDN28B_:'pf!NlYAdqfZdPGD&bJ3qlAn2_1M=e.R4GB-&S<=b2Q=&<&kf),Wo-OPuKJ/$^*m,$0eG%]0Z[uEn5%/h!G5oj+$7@[-
-%-$=(W/3JnX%ZqVDY1OXrH8$/*d/_P#_=h3B\oG15[@*EPZ#6%_]?+7Id%/T1I+JVCi+P/].BFbSQQAe#DW/6X?^gAOcG3nqW&Ood
-%`d'd9Uq]#FK)5E.j7&Rqol2flQEI'PB2`n@GBYAp$uk]e&2dt!/I/Ukge=Z:RjX^g1U81o%$L'Y6VZ?e":aO)2.(n>mV>X```FoG
-%luU)L^K[V^ESG\81r,L]65dB?WYmm>:sl0X7dpA1Y;U?+F%"3R/(@P\\7J"g&_LsVg+S@e@ceQ-7nO0B!7;ra9dJkWg9,Xif)Rs%
-%!@WU(@uU]>K/M<7(`N/r.@"#AG'0_ugL@T&$J85rZNV?-\hQii$c4t'0YEm$CQ"_)1S*+>8Z`$4bFS=W%rU_3b`/i!:g2;WBrYrJ
-%LOV;,Xa>#b6MW/Fn$:[WG`\?bVtS$c[6ffFHK!bY[1?6j;6;ll$8V<tCE$a?8;j@^JV':=+LNP8#U%Dd!G/_O2<iTC#E*?MArPT3
-%nKP-7S#=VVYhL)D_(Y6t6"'eZn?pTlB\]Y258O,*7=Xd$,=(GZr>ba^G1i,3<L1gg0h*m!T[Li9Wps@\dB?Pk4s<CCe9(_qLQhKT
-%\QOGkMK:<>efOMrPGZlr4/ha6-U0jTZ3/\TYaPpB/p'-#hCf78d;R'i@"4rVUGTD1J;.FNhIiWfZo<rh[N*pBV7(.$WQee8n'T88
-%7Ks@[`TX,:qMcq0o7";lqE!`,rD]aH*^fAj$n0fm>_7d#!+1"4g7KHs<?5j[D<aaW^I>*]gMM@sgXXTWd!&.WX(J>qoaO\@[*E\_
-%2STd.4l@o%l1>g<^f%5#+NMr.']=Zh=2S?TO$CtFs.u$PpXu5*&h<!D74,#,rV-&A2aZodpX$E),i;=s/%/kBG=`6i1&Uoo&3ff.
-%p$t@@W,T1C0NekO!:OqS&T,1q-Qp0>'+HT+lb7?=je]-$gT;_m2]lFAJ=l7;J(E4L[:a8sbf/WEc8m?hbsA`X5Ac;g:piCZ5EKB;
-%);m*>NO12Y<K9!&-*2101[sIdbcWOX4d+po3SB#0NGXAh.JLO8Mk'*6,F)Z`<#]*RX'!?.MsqU6MBEE_b<[N^hL/GU758`<J`\@h
-%p+eGJACRb4*9AK8LtSeGQYA94(U?gjB1eSn$@ElSG/+5]TdCU[`5@jCoj1bFMK2d\L7=ZP$Wd'r>RcT`XD<%U\<*W(he/b)5K."\
-%qKuOLYZ+^'eDjY_bI0s>)Rhe?oK1(scba&8&.R'jFtlst#*`&&b%!"o_fN?m2(*3!kZug-%F7$l5[/goM*g7[KWl(.Lqcilc`TMV
-%Y2(&Z$Jaq2UZ1)VQ!78CRk':L(W]%cO)H7!;?YKt5SaXfVL[CJ!8h?/!b3C:J2-m/U\j"a>]'Y8:QVK_M`:>>=Ji_tRbWZ1^s<Q5
-%lZOB5gJ^2=gL@E0N6n.Y1jb?f/ksU-NkaJAp=2_kZnDGA5sAsgoFYQ)Ec3*d0Ec!jHRIg4Fg@nT</VYjf`7?sCFNH`=g*kO4""qK
-%/9MPKJ!iMj_4N5[W1NM.QT0^d]CuQZ'-!uW$&qr\DR:=g771iVRtnN?f+$C)50+fDVdVEnKXUU?L,g@n9M:g+#C)%S.B<WEoH*%_
-%DAp"3R9.<)/c&-o1WU0;1tV$Zgkc<"+)<7Uh2PDee,-BHZ,KqXDEcB]2m<+9L/OpX?q(EU4W47=bG_";=/\s1s4k)nO.YQ;pAr:1
-%0*Y&#QuOUY:aEQ@7](Sh]`4l73P<pmA:-eV9L@X(%gI*e6d'WRbm\KIbP8+5Wf7TJ)$f_^57Xff/8E#aP-a_oB"]?W)ETLp&9bYX
-%<j2if8nO["<kPIK2D39;(rT;uhPFY3FFV%-Gt:n9Gl8]f0UWH?-"*@?%QZ,#;`>>KCq5')b?";'9seJ1eR["$Qa'"iSA(;J="$d]
-%4X2a]W]<RZ2B)YX,9)nV]X9qp]R_!g(&UfG0>.Q#W@Dm>P5nT`X/_q+EbUIJ"70c1K\KLX\a/1No]r]8nj7'ZZ8O@NLr,p2hIUe-
-%#l2aeU<k?^qNeU!O/hOQ5hR7n?*K[\mreX6q-^pP/sd2#kjJmE/#0+TR+VC7Mmd7l64NHA9>%LH'UaQAY">D?MdgG35)Xn9*0f94
-%l@.W/2kW6:;;\hOZ#6bZ-$<qOTfXiI-@1=8#h+tP&oA(Yr*7'*A[g"S2".T5K!!`i,cR,AG(tI\Z++<#JE_3*r;(?.&<IRkG-8XC
-%Dt;)L+`A%#[MY#iL1[%:a[cDXY$:KgYL,Kq!6mX]8*I.eZ#u%`h>dE`[/1Mh%>WT1fFOApRjrs:bG^s'MDVSLfU6)Lkk"\2"$d1X
-%e+#/12(&Ptmromu[&_$/GprpTad7;.>g12u,0X+rOI]J:`dJI\]^[g0IkU3gOOh^U':GB!!9F1uM+45!#:X@@P%$:+a`#c@gmO3A
-%;FmBV3o.W5I;>HFeuc4-RAD$HN4`U#+V]2>\!dp5Tl=e5?]<K(!Z'D42t6lh8nAc4@\V<rmt'.mnRg'&nW.&VlHB%cci3j/^\PVc
-%romef`W&"!h>d&X^]2L7s7?9f+9%>9qnjNTiV1*>nLsq$huD0o5+2H;YC?5X^\de]^]1/1q3UE6^Nf_ODuS4PIt%@ZqBc)\q1&D+
-%5JR3ZIs_.3s78#EVdJ^Bs8+JLpA_jUq0TaIhgG5\k0&VNo?L63hHfY/WA""b[&%,"?Wb'm[Z6<&q"s4t*m?@Yn,2&AobUOP?GF!S
-%;#PlMTt&W%o.RlOhsh%gZN8b!ie(i-/RW`jnM)&goNEkboSaB@[8('(\fhS\h<[[X%++"[4+@U*=T>(+8JF+l%*uc70$rtI?L6<d
-%A%-QI)r1NZ5(L?CJ+<",j^7rb&-)5crV48prQ!goh=(C80E9MEoOf3e^J<0@s5dVeT7?Y75Q1$-s70fPq3QU$j2XB6r1!`]LVL/g
-%s885`nTEg*HMuG;_RniN5$J%ab0@+#B[U^D1Mf\pkAiIu]1ia\A=*h1!HU,,GrP038-W+fd@;XJ)r`LJrTcne?!:Qs!KA[Fd%Bb+
-%:H19[iM@8e7d&:^gE!'Ikf32arckE7]l*K5.?"gUL3_Z3.VK[L"B0#.)YN\2r(5eXVbaPnbjX/1+.(h=_EJeGg54QTqeboi[Ellq
-%P<U"7p#6FAqJJC.F[puQK?CiI)UTTaLH.OoXBg0q]nG0`o.LW=:ZPX8e'n?kQs"Vsh)q\af"2=%D=1DAa+N-4@mK_SBc:TgRQS?j
-%_<45p[K"7-AqfO/qm\*KjnKr\(Ze[.5AA?UOQM7[15tYr\?U.sg6hjE&qk.O=YVj)h=TO?I]HOt;&)nB)A,<Gfk%8@N7@"5fJJ`^
-%gA?4a+$_d9P-gKu]nf8DYo+"X1+#IrMkf!TQ91'0^#XQGs'"4E`-oBNQXt;D/,]9\JH2<-oNAi7<[M_"jcarWd+#4po-(k,)GY'<
-%&G\*-QWoU\c'G;_O^!\\=/n)hMqg!:%E]N*hS9*]^iaU%X82<ki:Q"[R\dj_P9+?[L,HVAMZ`#!gG425WX8I5LAk`,di=6*o_m)M
-%#JG[@-hh4G>/B>1d9\^58%kMlDuESW13DpNh@88"A+n6@fs%iC<SK4kbW=6*no'NJH:?PI/dLLXf=*hU9L_6hA*oUhKQ.sh!147H
-%3Vb@LFp[9i!109XmE5@\bl,h%O(n*'X1?o$lkaRj,N?M(Uh@3JdflIJ&WK4@eZ,JFEh)S_l+?S!Lj:*Nf?GsuR.KW#<#Ao.(WI=O
-%p[E9A'i$it%:J7:ADbUiko&,ZGHXsCR$FU1^sX7a(:T""ipP]!OJk!d^8dO1=R=>R/K2E=<i7tQ'5lnY=`eY"hZpBPgB-bi]"IsF
-%<'r)eLuFhm-*%HHN$Se_.a4`3/fp7Uh,o#akoH>7hR-*oD0l8#qt=Nc@>&X>!9fsH1)<E7_g#b\UmB`.Qg3i>]!bgL)FatS\T,%"
-%B,.60AZdGCn650^aZHa\rRfY7bcU*;104b*/^/:T[:AJ8^:&%#/sI^nPF)+,#&+Q^efDE_5Mg6[q[Q(H>cIqcDS('80]VY-?.TR2
-%=#L5pV`A'BWh7$ujdQ;!"[e<H*Mi.Z3raT@R^P+iciR]mSHGPWkJm%LHF4+-=PV/:C4OoULY('ohjBTO@.`@<HBfkF]TF%\/Bt3:
-%g@+oNI(4eEPN?hfHEK,S>)(@]i/2*UVLFJqdX<"agH&p[7,4-[$QjHq?d$X-04VI2Q]?Shr`&0-]R;QNk_2S<^mEKS"79%R#7#2K
-%3':.!I@<PujjQSU_i:5E`<\mt2gaG#R(]i9)dOWj7aHInd;/)jMrX>5L*tluV6S.-pXknR]Z/2PNWFCc3uQdH'B4\XWRYNq3nQPk
-%^n9A-f$'/4ZXqsb$G?NXQ%dVV1]#j3".1QsVH`e`GBRD(-lD9sp6rS\+F>8q5;oQ(%;'^Z*e)=JoRG,$QW;E._QgX^913(>hBkRD
-%m+AoGp1"D1m%Xo_cFA$O::8i^S;\DRg_M^/FjVdg]uA-ng$onH2kM^N0"tkGI!N6o39Ki$+7Ags<0&i.RC+C/\27EnMKZTG`pNE.
-%1bntnj0Wj51GCiQL_S0#Wo3[W%^53n@c%s;Y:c37(>%GmH!6$E-2XpZD;7&F/Le,R4[Mk9hK-=&,Ru+23dP/Hb_@+UERrNbl")]j
-%o$hBD*G8@E^6:Cf<WQ,.Q'-*(G.+%]/N&E&]7I-^14#F-4BKH"lN<Na&YbIdM>i"8q8UCjG$o')GRNOu=7U&C8_:oP!Cf@*75nTC
-%)Q029NQ.;(iPt,8^]l$1l^56Ba1Z]]=&3hunGTm%]dg)3Tln>4e&d=c>%QJDIbOr2"E?t^f^KP??k,Z_b=lb.6t$BSfuS/N/8V=E
-%,@9Nj0:@9u5J)&u9^X1b#u/79qgt9f%2LB:=33i-B5G"Gs2+SLptH_TNAnXZ2!TYYc/Hb6dc9Dt<XU<u06>#IC27H1b*uE96kUYI
-%oC0asP<?K?Pbg5fU?1"LfD.C3BG`g%;7-4Hpd$5-eo\K:DKHK^"bCbhJSE3co3$kbgfWWH=gGfc>e3]%M=mZL2]\EWpeuHs'$&a\
-%>j=-H@_)[(7!?<1OY5J+7.C"-^0V+Q@.rH\"m0B''b@g;#?F:>Q%S4!RDj-SCELoeGmoG'B(S8.\Cldm)BWP[8r)*A8Z=EETPsh:
-%Z[/-V.?fLQO=\c/>4oiS*`Cc1qA-]jV4@$\PjkpR-q`P3=,<LlDJ[\=b:(U[5;]B,Pujof4@Y`b!qp8Lo:4HP]f5WDDd>GViot'=
-%70RQfo.6Blc,/\%)DK>*\W?lFOZNBCB[)'ISHD,]gl:)lI9r:`=k["1^U3'660k(R\N/MS'bbp_$tmR$Hc)4&#,k0nF",.@T[9R[
-%>HQ&F9gj_J[+"-WQcEk`7X_e!j4tcKlSo,;+QJ_;TAP4ii`90G4S1^WUS!G$R/9fiZ@ILm&cVZb&(J"Toa$hbQi4rWjs66m*ujZV
-%0o."oiN$T52$XeV?jtuXDVc4V+hLUc4`RDSWhQ^?'s@Z!DD0(`@:HB1ogK(.,*b_!Xd9lt2?d>:B%\DR;]VB@QL<kPVSo+<>442&
-%NrA('?(17`P`6OA27%eWCWe$%7W-(<pH#7"r7ZPebh5mSD7]L]9\2O[HgPX>_*5ol",*i^iQkFlj_t00fpYm6:sIXNR8)SkMGb2b
-%MEneZgc2'PB%[:_5bHI^<Cb=tcnjmX??'e_L6>H)llMo'm@@@YldD2d;tr(12W:8LiQ%R&HN&SOn+g<fpbpW)05u_0<LG)aT,e+(
-%D(u(ahGr6h5CG6_huA^\oWQ$fNa,,kleArP>PC26iT,C-3]o4HKMun9.kN*<;32%.Ph1+hUQ]7i<WpY3TUD.o^`T/1Cb@2#C#l73
-%`fcbQ1g.HYN^ok#NYsG(G'C<u-SUK12OgR^7XK28G>)(Z%9M?O;KBo*),QO<VX*M[Ll%<FKjs1AHjahFhRnfd%LG?TgOMnQ)3]qX
-%Am@Ul^Wb8-)b.Ws?D[d;cHAb0DAYHY$'XUbT"):@PtcD1@t&YpfG3h%PB#:/#pW(PDA95_k.WeT*!s*j)=Q1k-USVn8DV`H;/JH"
-%VU*$)juHFq[*b3pX&_0lUO]P*DD"ZG!7iFrgNU-t61Z2)*Yt*7JM1M;)9*(R-TCaBE=&&[cK-[(0+'+_93_4,nReCAE4E9?]<`9'
-%OaZJ+eo'kYSAN1tR8eCbCfK<ic,Sh=h:7m__J5T7gcu%T%G/=gG2'[AAI6%LAQQHMp+j3!GPo.<]DPR!(c,(Jb)M\TTXne_Y=sQr
-%NL=(d`c&X;7i8e>XYD3T;"aO#*Cfci1k=Vcr4rAk`W2?P2r8-!I4"unm,?"Nc1Wmc!-Ct^L1WFe_>4$._KgV+F"R,U?cLgsN&g+!
-%!9.V;r7tJ4]*:FW&;SY7M(d/Z1l%sC5.'B&C>s.T;DFHs'MhOYlo<iRW5fQ2ak+e@YYF`6r1"';UL<CWjEjQ3\Y^8IGQHOC%=sr'
-%_+<2u-MsRJO^X["+h.CMh'"DZ3P[GUB4XfUKSttp_/dNHh*^5MboL581G)60:m>?G6"Cb\b_VM%bNN8s#4N8%S*T'M=eS4cP_Q<q
-%3bVJu)7_%L]0`Zi_811;/(lOkZ5,[n21<rYT.71d!<2e%gNG%b"rNPF!)3XreDag&FTN$1LhJ_/^\cKgiHoR&Gq%O+'3UK9pA=R8
-%ol<A\YFPraCkm,(Y.lT5\$7bkI#/%mY?]lcq)S@TicZ6tJ[Hn%]J?m$p(QAKZZ2,>pZZEcq_>l4B(VLD;&+7iW3[gpq1Zo<N>$)C
-%O^8D?E!*Q,@kT+D$eE-ic3V=AT7J5iYamHF^(!,V2m[rm[H^-O*h52#p^S+s&<%)kFQ56!M$&So[Upr/3..(rC[>I3,Q6YGX,6W9
-%LQKM>"E"C>6B;1@bPMG<aif+]N*6%'0p.s^[,Q=PHR@TD[:!1?T-S0d^'JkO?QeQA:kT;?,^=_;$_BkIFUmi!^<bYpbGCt,$>1@/
-%(nL0&p_B#$Y6`.Kkl+M.**!T94VT,K;`Nel>@J25KXkq\E[kDPLWg$%h#5=HhhnW_AmA>si5nP!;"9_<A0(G3CG3>B\!iZsToZR>
-%oF>5jSD6Hl2b/]ic](AO^m!5d92iF(,.^%Cm;ah]\6"@;@>rs0_WnXu<NMpgbZ2i;dI>GtmO;6^Z!QC+-1#RgiM5Oc6&u??+lN+j
-%\o>e+!Zq:dTX=?sq+K9g9K4HfdY3b=qP>OP7:ohA)>"4G2PV)]%m$T3&Y$-MO4697.e,8@pA&j+Y9$qO[VJ'gLTo\,hP>&=<`0Y*
-%NSJE8?()bfgu>dMGr#^CGkdZ,!FOq?[eL7lroXPV?LHil^RRL$O"ZQ$l/?E,q!O2i`,R_]fQeN]WPa2YYkK14alAD-hL1GHom'=t
-%DuWT\`T^&V+$YOEl?K0hS:AScnp%/uSA<1oqVb[Dq>_meiPD^Bn3N*6b/(E0n:Hg\BkD7'R'*K1BmN)bn(!PtDFD@tf1";Y9_+UV
-%`F$*S]o_.WZZS^SB!.?\9[DMjfouQiQDSot\FCV!l/QsdYk:4#'8H\OiUD+PW")>O_sqq5.Z]AM_ZB[S=MGsD%kbZF>rXk\#9W$>
-%F2![?hgRT"[Z<)&YP>UE*Z!%8NL^jFC"8fAp\?mq#TO=?`^;`V&@rjuS7=hV(d&f@X^anF%,[)=hD$E@L6'A?o,*WSL9JWopD=Sd
-%"6a7!I14<F&c>##In0r0U_&RNL1=]P0o9mDGT9X,a#(pQlI/W`NCg#OEg7T#)Jth`m@Cmps*I<c_q_J?\rJFUbEUS?hJ/B`U)R&/
-%rET?9/a)2h6n`&ek3>EfH<Uq*H@rdErgpDMa<MkQ5$A^+T^N?GHKJXgZBSM%N3/a]#'5&_f/iI(pNdQ:J>MpXUpjX1*%eC5SL%;m
-%2PIj3%CaWs&qe.Ikr+k4R*'H\`[E`p47qM+gF>OLC08(<;NA$k@GH22!liKO,7K=/P2bR.o04#),C@9Xe(@W.)VnR\/il'M"!__?
-%:Le!<T9lejpX@C#huiVmIG8U!$.+[,,'B>Sl?LRAiD_jtH3J`^S?i"s8&1(:6eUMi473<mQWqJt#\IE;L[B?Dh5\/Pfha&_]o42g
-%"?ke8oZc0!._YE[P^IruGuAenP+%>na_M![1iC=n[6pgjcZ;":X\mK-*WlDn2[hi*_`07i-c8(><qTttk+$-e2(IW8#?,@LFBc<n
-%?tqK@1H5gRR@_!U0@B'H'j9*-Ea(2<J=Pu^E5bs/1Ha5B/mst'n4qs.k9]l8M\Q%D-64,8GY&Kt=C]14Sd<@:Hua&D);kD"_eX3U
-%B<fJ'0ij0SRsN`%bj7L7^W2KlC-,0N];pXBF_89.hYfcp"ToTI\aWd9)S4=c+i6d1_AkgQct,uQl]"JN"3cB^B$4EMP$+oTH[/s;
-%?#+%u;&3WN2UKW\1/Afro)"k+NfImfE_HY8lI+;S!XsMZ-5V0(a]ktcK8n?e=qgt+$s-Bc2#5fWMrl\;i?U,7C-.8RHA$nO/9B]j
-%r_Clu)PR["-@R!_Cr1^C69bPSYbpL5[O]EV$n+hrG[_i.FH>itVR[R'A/D`\0L[C:\P?FKZ&;dfJ@i437+"gY=I#6UQ#;Sf2!$5!
-%]jd9"T(u$>@8[]-OA!2bm%,=t[80VRf5)o^DI\;/p:/?"3'\X)ef?,g%LT/Gp&p;CJO<%U;bTm_b[n9g7I$'rEs'RlXuU#';MWf\
-%r4c2>2>iJiOc5l9$=hZiFR^)?E2-Za!!/Mj7-@>l!egH,qapJT?9uKg'[45jWp3&dGS-soh=(KKd3g%O;2EIQRk"FWSVsqVik<7b
-%n>$*=YW@2[0n'P2qQJcmM:0QE70@c]"i&rS]ZJo;<lBs.JP05b#EQ@:/"=s:NY?%_0i>p7&SES@VN#>XH3O"KL0u6?++G_)GM*]t
-%Z+6YGW8F9h4rItL+!>2>62[X2cS^7Ai84nMP:]Qg37E.m0/rL\&L2%)^3^Q9Wb,ijE,K1^lOM<?=:*lj')SM")dS<U88sJ)K4Nn7
-%io\[bG][Q;fsSArn8E:#"Jgk*LkV#<'DY/D5B)G?ME=@*G]4Tfb;RZrd@8h4]eCZE3A'ejcEIsp"f!.sbWdhlR3fQ_q^iLlc'V`%
-%j>[Ii3-40o>^Cs5h9,j24A-`S89JoP>2^N1-8St[i*)&G9.ubP3&fuEKlHD7fYU9Q@h18kB;<`/L'qfWAeNNQ+2s0J/1(.B(Qn0P
-%JSFt8[Gd>cT0TiVSXIJ=\)j+V2\)K'->N\Wf9V"<ZSS)AH#<Ji2jBQ;i=dcf@T.BhF/3b>Kj2]PCt:,r\3bI%UO'Y_l&3##9V!I;
-%a5Z9FFSh@U6k7`/Q,FlRLgk0JVN(>KlM;fXH)l-qMsh*:5UF"YK,C^5lcDGr\D^21!%UEU'<;.;[1$,84eI\Kl&ZV`>l,YO'EZ$o
-%*aW1o&A:mNYYc'ok?DIQJ1gKqClXsb-+qH^?8,kd2Q'aa#tM094Im05$U!L0(`L#+AhA')qQW>n"4D^Bl&u/2G;nS<DQ=97hB>N$
-%,BGDbYLm'*^HKAe:j2/aj[m8%BaT:,VnM<th)H(#UH3&m!t:;mm/a^1Fp#S@*EWLThm(-i8WQKWLTc_9T?L.@,W<BjoL.',!8fKu
-%g.&)N*k@/e!W\>aM[1]-i"b\0iS:6Cq&^C*+H^T+V6F?2AA`C7&1fNLp=`7dENDpc_V,tg'WG#4Z0V*[O:WHI`o\>=@K6#/gQ$*?
-%A.Y^J;:\-J`tWJ?E"mA'...VH!OUhpW9,V]iPn;XQ3CO.WHQTmocZ**5/i]JVM,b#XFl=?F[?r/]e(:\l6#6A.YkOl.`82YgO^&!
-%N+<<`Vk$5'Eu]C9ok1rr"5PQeN8=XW%ZPPUOZt'Z;,cDDT.p=oQ[)$iBIVX"":V)M/[@rOL\ATXo$B:4fKl73kVQ18SZg]0kiNW'
-%@)0NE?7o;2RFciW%SFDd/rf.1lWAtaJ6?oHT\GfQ_q)2TN$;1Jb:Ls5_Z1/?Lp@kTD.]m2,&D.YP;n0O@0!oI10HqoZ0Vl0aAN6K
-%&,e)!H'\O&bo=?*jBKJVnOOO`1f!\ZgKL.Tp]QT66L7Tl#79W(qQNu3!Jt%C6f[blgJVW=X&s#s.k*%R'#0QZ(iT'],j)g+hEeqX
-%]@\i5m$7lF4UTpIOU/DUP:srMG%PL_?5e)dM66Pr*I1LQ3V[4A(/oW_YZkF@s-c<S(TN(/(KQmk5Y/':f>,)dH'`73OR_(p[mZW%
-%=WHpa:9-FN:dMKB51G)K>1D@KV9%\iJEqj`@qb+%?dnpcZ'3Dr(ime7R.M*GX+X.INnH_%IM4LUH]$7PkD?p[\\NorNP$f<A;pK]
-%3KaU+[^6o$f]tI)8o3t++uJbGC2>Wr)n(3Tn/Xt40,M,p0U=o4rq?ZI\e'lC=lX(=5s,Iu8qanPMbj8I;"F\)Wc/mj]*l=6q6`Nk
-%+'6`;URb4GkS%[N)SaZ&(*2s`__,QS@_<C2ZGj;B]toSq]uqOWK%!JDPD3FHM^=Ds\IAX&YZO(44&5OPW.pAIe]n_I`%5MsBb.O,
-%HKcE9;H;RmZZ8m@NP\4?akApmo+6JbGV0ONB\0BIU/.`!m]LL0`mTB9\j.tKPT-U!:9Gj10G[aJ![]]"(gr4fDe:9jbge#SEj)Ot
-%+W#^s53Q-MM<ToA#N_arI)Bg$qWY/+;2VMg;&g!A4*82nIUWCiD7>b40OsO57]B!4(ehD]cJd;+r>97$p5P$4!FF6SPoYfe_[F8^
-%[KVl!j4*!l[LnP5+VmllnE$86#_on3S?=nljI!3q)d&&DbrCuOp%'+)Ui>4ofL`3G13U_#bW$G<*02m2rY?CYWMFu3DQI+s!PJOs
-%Zs#T`pGQ3@</l9BiVmcGg_K!cYmj>dVn.N8H!>uZTp>:gjo?(J"'eDkF<c98"47#%BQoL^0DQ4hY(p!B*+#CWg^j__d^Eb=`MQc<
-%Ido8<:6H7TYL*"9iW[/"-Gdj_(FN&I=D;baH_X:u5`IhnMHlB3(3j$sS=cu+a0/hE#[Y+;_=4$!co-IglNmd?(/s%$,jNA2C,X=&
-%L@u<^4I$J8SZBn\k,PN%Pr_.)5`kl>8U1^6b"K=2-?MFTL?2%M]6/g.QAs"?aV;"Eb8$lAV0]'X]mtdJg)1sP,/D94c'F'K5H=*&
-%YGg`i%6q'2'1n3r-IpY^D@cm@j>BZKJ_ZZ-\Qc(@am6#BgDDtEk64p@2poS2UlWkZ=!di.T+#)TdWQr7Bm`;$@M1if7;[*BI?@+j
-%4ZA;Nn+?^oe/9^TldE(rEfK[/Vma7g.2js--fD(hq=t@&]7Lr^FHe!bZ>]ut4q7=:DHpZ);Rsf+28i;qZM&NHmPnf0$</90?q)hA
-%gtTr?Wp:WsC`2;GS"9m!oeW!+-:e3T7AE\E'$[LmgK-cd#"qR4O`'e,SL%;CU$uk2"sAVV7g.p"$;NLt,^d#!LneZRgPUJ7eP=8s
-%R;8.D;9r\3H0?a5g9baT-JlV*:Zafl^O#jo`Fnr*_UsTLGR::pqS6,P;P=H)Tgo2/8@W]d5mj7HU4WJ&904Xp?D`oXmckLWVg2W.
-%rB7\g3"G7P]nX2E[P_3hi03g:!J59U]h?c,72<lN<t%k.@51=IXg5VneXIJDiBWV:,;Bbl$R\@:=,@+X$BHAj^N):E*PGE[9LMVJ
-%i:=KfV3r5g0)U!PEiLc_^X1ZM67jqfkur8$(V1;..X"Gc!4p(Bkd\JUCOt44<f!=@'O/]KVG37d+^RjBH"Is,fpb\e]8kHlq"l,#
-%O<1XbeaHgiC7W@f>8F[K1'@Ls:qP6l(>Go_&?VqIC:@BHeEuO:#6U7u^LM1hfI@q[<\YU+6u"i`n[Cr`*]I"Ac,qM;(g4p3&s">H
-%9n-NQV+L&R-nLOEYa]!i^8tS4:!'><GE)Dp2hu@AlWqCfV8YocK%U4?C,KLe.sh8td6ECF+:-5LqLq)JIfC:D!K0YjH7:Q19e8MI
-%SJ05hg/Kh>EsJ(p%lGU'b^QkuE12_IB:u$$L9eF&.gk16ODNC8Fn2]&^NX2=48`'en";X%E3H81:\_qY!c',?';*ES)ufgMQI47.
-%JPol\Aeela(UGQoUTYSc+$-$R.;M0r</9o4ZA3'%os1=QCcIEb&nb699ugT(@HjYXZ!8@#[(>R_2D1[M(-*TYBh"EI%$h6VU8'gt
-%q#hpa2JlRE:CFd5]9-jKL.WbLaX'k@;5k&1eJ*6MN!Y^sT>4p<Mq?CtF81QaZ7YG]e0\;Uk0gbB"t5o:QpaS[;#^+fjFJ6s9dgHD
-%m_OR9eL^:fDM]C+C4\1(c7=DB2E54ub7^<+X^5\ig.>[I,-3lQL3W565oG%"e3mt!>/%V:[2-AWe6;cRSno?iiK>+0GbhIL@/(g\
-%NB'6FVAsRb%NmU)6&c-X:5E)%!1.b/S1_Xf`X]d>'$J-LM:CP\PTO7_Q]a_'!t8il@T402&PtbJ\.p/Ap/?kN49j*ZSrj#>KTVPl
-%)umk)^/_Aa;h<gc!-RI2AoW'N+d"W:3f.+tBTVMbU&:587HN8O*1tG/A<ibP,1>.BWLO`2mJ[)K^e28<9+/o5;%p0O96h$GFIbJ1
-%%$V%:5asocJ^/Tp<UU(;+,:Fc0ku:GiNSK'\#E0U.H9jb18%'C*=4aA^pXIT<jHSVN2gr\^jVgp]U%8l#.c'F`;)c?#L60*9K+HT
-%qKGuZ24@*U<YZJb8s;G(h9>X6-V4anQBmdmGMk#:=<=(O?m5[Yo*Sg1F9&U'q]+kECdCN'"p6]5]pbDX3$u0Yf!SA;Tl[g>W)P/6
-%Zl94J88Q-Oa3c=_KJZ\o^`;[bChiWL3r&RbY"K3q?-<<ND.Z7d6rqL.$pf$NgR"R9PI=^1bKNGe\_24l)Qs#g@;MCKFCSo7jO_W>
-%GZ>_%_Dru02d3`ufm7\<b"SA`)F@qG]]&^t3L-'t6bS)b<'lAkE__-@f_L&DT,HH>JC,i54pAndZ0V8uim0AO5qPIEk%?$uOnEqZ
-%#9G9FB/YH30j4`qe>o[b1Od\%4<\2ZIX?TX=WJFB)D_^P0Q-'/q'3]MH-L[+4/WLF%14GO3Sm/.E4VL5o0%BQ2hlZp!H]K0bc"-6
-%#>YFd4X$PZl92HL[Ms?C$*52>Lap,jX4:#\`n';aatR1ff;^CP%-&TXM[aQg#AQ[[B_HVto=d6iRpo)=SH.nm_dJfdG["$J1%W-6
-%/-p;+]T@Ag<gP.:W$;>H]pl1!h%g@gAo&l((p!hFH"Ni[m=3T<+`A!IG'X-hSA?GUa8rC@%tD3Z3.W(QfZB<[(25#q=<4$lJZ\Li
-%R8O$Z+SC]qB,'^_2lsF$"ZWN4J9DnfTk,U>5_E[O_F3m\0SquhYPSe<q\8,=.Z2&01k8%.dXi&a;'I5)_G7cYTID#Mc+bQ10^oYI
-%47o*1W!89i:O-Yt(KVaKQP'RpJ53TUPMhWNr/W)Q;&Ad0f=<b2TJVCf[`l^01_ku1"']Jc/K1goof&>&N'6_`B(U$P:Q*)k)[XKS
-%a?<s^Wm#+JgNg-s3"tEdhHs,T]W\H;@t2hh?<@L./aZOG4$7mLiRc[Vk74m`EH@<+1h(ulIT#YV7:hnD$=85.FJM3#:^%hk^^/.L
-%+bY=pM9p0T.!K$^Y-")m!.,$^Omi?lTEUIFW:NLfehj^CdY1I>[JFCp$d6tM/M]L*khV*sGf94n!.NBq=#^mHqRALfg\p[)E.rMO
-%!e=WN-n%<BYDf0.Tt3PZX3PhaLe-[!g^r7C3/OskdAuXP"*EVS0RtKi`8c"dKt_kT4coKHZQOL8e&ChO`gpQ4'mU$Ph0'$6\6+If
-%=_1gY)o,dEpbO_s*]:Gt+^&ZM+R4a9.T/%L;G!$":XWD<ecXRE#5a4fNSi-n#D2YR$_jda`1a8X![[;5pjWLJ?P6<IUlOWO:ntL%
-%!f,'1dr;e<!OW>AK>;TC"d7_c=uWZV]sd?%aKUUCHtqur6oD<0e+e^HJLCr:)(6:'jeLI;7c8C$@k2)K.0>$AUc&!<989b2o1<_2
-%Pe]7\^ED`]N<3)=&#M^jUg-<(1a?u][Ond;E(.I_@;aJgWJJZ*itCQs'fd.T#HS;<("0@)F9`?Z1k<\f#LjX+bW!(GoPt(Tc`HTG
-%Jo99kBsNC]g)8_D7/=&NBN;]uQg;sJDlSA>C$5s)`&U*82)_Pmg5`DV_fa-o-h%>EnS&?18qDE6mr)Z'BBZ'MeE9[2f&;%&-CohR
-%-BiOQiaca@Ye]J,@VR/pb.SW)%h3Nk`sY`rA`&',#F2b4Z)fDRG2HaGAo+2JGm-*<?iu&8;H@./Iq"I2W&\I0S@ik`MdTf$f28?Y
-%.5I!;HFX6u]W*)o6s0R@W]!u_(7G(I&'q6Xc'9NoL2M_GW&G$Ks/@<jp1sZ=<46l<bJADTG9=:b@+kTZ17)k!fCn8+N9cX.3Wh<T
-%iiG]FRj/1[VJEdV!Big^Z6GIY?D#1(K3lumQqLaA96+%$jFjQN`g/0\l9D:Q7G4GuOJ0\p'[<lNW*cJXg;-^%$ja613!]dq1#5lj
-%Ud"Ju?eNt[.>W6M)2\H,lrt:jCKC4@<$aLEN%AhuSYgd5lc7CcLcg-A7em$:`-+ZQ;Q\mXL_un';P!Ot5[sJrEEY@9p^I>mWo_/u
-%!ml>"WB,I%Aid<BYH<?$r`hVILi\1=+d=Z4hY=oR0e6CZoj\c+LEu5W.tgOfQLnLW8no?.Rai73J/OP4XO6NP'bN"pAXb'D&o1(5
-%ER)e7f57S:2Qe03E.=HjHR*Ls&<neE7l/g6.O5hGCggkikf.Bo3LILL)ol;j[>)[N!(YFN1@I;%.HkaR7;DD@9JQ\6,KhKB=]c,(
-%NE8fac[VoDKmGO\JET]e#+,Zt$GXO)@(8*Rc@i0'CBdM/:^NA;GDIS#U+:_3`^!1b/gK#rhWUDaOAMQ,kEN2Xe(-c9h.EJ/%91I5
-%']:b(pk"H/dR*#ccj?<kM+/$?]7?ISl0T05kKT$T+o5Y;ZAU<"/MVSsi\Y?\$hS-_)H2u;D_@A9gEs9H;R1S)2a0POa,EEqNHs\2
-%mJ[86p5g9U;%ru-W,>r#BD+<V9Uc.Zo3iTiNCu[<NV+QI1o8*19&o*;k&dGSd!\FH9$9J*/":!VHaO5q)bZZ!/@Z7:KM<^o#_p4u
-%I,$h61-mI<L'k+mT[i;B=MC!4:H,8Z?I=t$d-.Zn3+E;<KO3`@71%J[r2.4u"66Xb=:q7OjRNm9%I8ZITLE^kc('kN`sk"6L0gtu
-%R_ChMOS'@SBcnCb'pFi!Ff>%1*RX;KY_0<X)0rrTXLast)(@A3+?cJ#oX"pL7/RmcE?bYb]Qu&fTg_hE_@_oH_03d]iWGj%;5gag
-%E?U;4Gbss_egUg&k@K1824u<e9u8']h<uO*1dUWg,Y4g2('U)-!l2/+&lmC9V!MZ5_/mHMmmFu&;noW3mjuc4.R7r#T5<K]a'X&T
-%W7XHLZtR%\i=\*/H)Fh2\=5&9He[^n$K@3l=g4%@r8TU,$SO,tEWpbOKo9CL'!VRF[A*73&.QV#7[$cV.@m&A>4a+CaKTGePKm_c
-%'H=>SN8Y`qm,('8noTjI5k!5C/qAX,_8,aS$8CtHK2,ui?sdb_5`g17",JPqDoU?'C#qKC'#2EK&>-U0#NmT@G]mV;ip9r@ql*H\
-%;aXfO`P3PWH,KtIE>ZElo%OSgQ#.3pcs4\D1mG#iO%"&Q=LSVZ4YNk2$SuCJOYuo<nt3$_bD:t<\2eK8\eK,gG'5jh;irUaA<hH,
-%Sep7=6kQmQ1%a'#)LEfmpHJdn[EktUh9#o1`F_.J!+Un=m&qUk$["2e@&73iA!:@*pfOkKTNORICk7:,5)b,10PZS@n,.,Zn[7KJ
-%m0kU>-D@o^)l]+Z7l6b+p+;+U`SNu+1Etf0,eL[e:f9;k!U=hX<%uq`"e'@aVAWtmO2rg<6i$UGaIO(7R5J`g(2@G&WXB+0lc..G
-%jlF_>Y<2ihD9U3HA+_=gKf_U;D&FgHITP%mM-R=CJ$(&D;Ig@KF8F_n[RBsBbVW,V#QIb6FmHe!FQ[c$S4<WNnsP7[d[SWV/knMq
-%C!LVVHmEjiZ+Je00*Qd5"Gb$VA.t9e6p+E4%^`h]5OX`WGGP0X$%aN[iK8A0VC4XT)3<:f,>%HW:jF<n*bh&RPg0C.o10OCU6H_`
-%VamKH,H:?$J3?eA+)/,Q$LWJHq`sL2;Lf9Wi<NQVOb.s+.mFT7:F,-K?2BC]IAC9n$/9*5pQ5`1VMq/#j[UNk"(hGLDEecm:R(Z2
-%]DbLBJ"Z-Ml2=+$J:hCJUU\*:Lu9[aE0N:@8g,0C'-7;mc=.20fnQ9?_bgp'X;c.[QoKt#*+UQ@,VG*t(e<PD8!/ci4cZ:Va-4Tb
-%;%VeS3oiS=j<.$7'JDK4S/`hP%ald:+tH/LQBQ@4K?26J*6_8<k"0%E-qA=mY'CSh3==acV/m\gFrhoSNoE2lTq@Mqcq-=_;.f#7
-%8TYY"H5&D$Bd+S9P9,CCNhT59i_9q=:M37tUNk:@d*tpWl6p$4+E_gk`B"?>4c!sGFLdD5?4ULP7q&WSK\1q4fRl$6;8hfenE_Q`
-%G*GjNOBaliZQ4bT*_"rr!c]S:\[1SV=eP12AbRU"GEg01M!7&.mlcL!*T[,>V#QH1JO`#B#P#Wo:>o'sn3R!A.$St><.'d7I$/5,
-%ME2d^+<SNGO0Xp=$-K#Jj\a\$5m6d-R!FqII$!<7OR,)cH_,pVO.r=\H-ljGdKeIRUVQ+c$hYp;H5'IECU"pl>E8ih%q;b5iRj@2
-%lrf;@-sV+b\:'IV4\FlY7<TaUH&E4j(<uGLoQC_%Qc^B-f!%c'io.E-8b7NA@s>_qSHY2)1k*?j5+un%0C$%%-@TEBI*d7OH5npg
-%&,_Q6U<.tIo"\OVi45?q0dlD5O_&UpiuGTk8"S%h&bNj[3YRJ_N2-^PdZNd9j?u0#ViG#_,:i)2_0$rK*Ece]%'gQ"m)VeG@'Deu
-%h2].X'8Q"s[lZD;*a!e;_V^InprFXA0Fj_bM'jA)RIYU`7NQi>OdU@;-,E.V.eL5$/rV/)k`Ib!1UZk+JU1k-*dOlK*7uKCp;!bX
-%@,[[_]16K%!t4mT1&T$CIc)A6E0a;\js(91aHo(GWukHr%ufm#\,/Pq5;L5SeFEh[qN8%3jL.;Bi/aE(1V*M'_gg\4+5-T?-%N=:
-%^enIs6&XYe\)<oun=YMT<),Df/3N,N*46`G.M!&I&.e%<#G$\V9o:=sMPJV==V]tqTQ/K839kN(2*=WK*tQL:B,-Q(hT1=-a[sM5
-%W-@g*NH3NG3=2iNBX8[X>`NPP&'?RR'q(iRb`ag,6,Vi`G4VYkF&^OIkj:KJo,M:g%XL@#g->l`TqgVoK0%CWalo[KoUq7U71VP`
-%nt9TR4Gi@Q#%h@*pl8@Zq>e'[)td4`W!IH@Y`fc6D"1rI,d.70\SOPb6ePb/]+1>04DI8IkXce[ViE6,#<f*mh5d;?eq9RF;0hK+
-%de09sFk$D:<s^tRM4KpPc6?g1H=f\/Z_L.HPG6c.HgRWXG1:UqWkU\F`BC0B*VJS:[-E[_G"2_K#IV3sZJJH2mm4/G,jfg*!.<-$
-%I*`WkWXta9$]jS-B-"psA7?%HI]B7*FQ1!*T[E=oLa2o1W%GQn_+W4>f4\;?)h-AEhW.P'nm03)61=A9)tU/*Gu39YWcK5(4<HCE
-%O8>Ls+jig)d<BlaUQ4T6k35GYoj()\W470)ApmKq4Y"/eeR9PAA=k\kht:]E9"#81[grhV#;+a:h;&<qhP6P.c_A0ED;_1Hn6'c+
-%W(q`)0n*(a5)LR,<Kp::b=?^;UQ4r@k4?d6d4*<6BDHJcMBd:@j7[VL,e8efAFRW!0Sid=c<"M5#nQM4:q<]5K"m?H[<i*c"^5T>
-%@;+iue#/k?(B5baSf,u<*O327at"dDe''cceOOZ-bkY.?6-/N/'fEQ6?ac\*3;+u%>;]S_h:.82=(G4$7]%KU./B:B\_Y!JWRtF-
-%.U\l@;@_Y#l>NoRUsXgrr;e8-24,5M:;^F4::=,5]ErU`MPk7jaN&WS[:fqE[\-7L^l3r"TIDTMS$k-B@&e2N)T$*eG>od#8t;st
-%W"s5:XAud[#f0fjb0F4H<&`sUHgRTQ\-!bG%95P0RFqqp!]NlO]68@43Wua.)3kojTG156A25iC8Sdoq:h91Jj\+jZ0piL5?H1hl
-%WrSkHLE$]Tig7uoR+:)s3878SSViFS;F]UL9N<CO;_nGY*OlE#mZ@(.hG5tsL^%V?Z[GIQ?H*JHJR)N$68#_F+Z,DrFc]p'Dap&L
-%8*pp(iHqhP%VCM)N<FRB74K`9H$1d%[k;1/P;N'_<fZAETJ,9_AX-(sqjP'oCTCfHRB0'*Wej=/I3#SZ?@b7W!C(Euj`MeYrQVC$
-%Lna\_11:r&_M!nFr%MIiiZIU3iRFq;hrG2h"Q=Ks<_4*K`W2qXRub\qCHnX^[CNVMY&lH-=ml+fd:l&_4+^dFf8WR+j5d\(S3klq
-%DrsC1neD-dJ6K)HB"R$i=LPOr,eBbJkWs0=Kaa^i_u(g*QMUo^11f?a"Msb_cfkN;r`h@CjP%R"k7'-I\cSF"7_"[aUjQLbW`"=\
-%T1B0V@mmPLQVp)#Eat3i8:!45]<7->CSgX-'[g+',?I#Bhs8HV>_QIoRZ^$Bh']2`WM@Ir7]#O:V3.^KiZ1aI)Tq`MnO899:K`Cu
-%QKRqTHHth6Q[Dqef.]!=Qn(qmS0RiVD2t"8q"SP_)IIus]V"=9VheuoS!l]j_CLFo;!7.''"DC:`.;IhoRe-HQSI)X6+Io8ABPGm
-%.<#$fq?kSNP9-4E7,"nUEWHpQI8t>k]DF,CdattHM-:XLoZNWQigedp`C7/t('mD4E\W91TYpC:M;oaJ]No,'Hkuc&B')Zo"D45d
-%8H9G\2DuA^.IDDLRkE*bcTPRCpW%I(Si]FDTe^tp4FO8)juSa)pB.$lgJWA`EnT`[n$/:-^:9"RH8/_bpM9ol?mNh%Z2]_3%E)>u
-%(!tL3`CU[_n%C'bpNl58`FbFIBaP4APm&4H8b`s#-R`-ZmOA4F<H*[fR)7>%1a5EOaq-6'8l=nI&-L>\UtWE,>::*II*%L*]7S,P
-%#ROA5ajI(I,cPisQ)tqsnJ(g$q3p9m-%W3g9Xof*e0Gn5#MB*XU"n:qOBmAcM2EAg$Y@pj)mEBB#c*0cVFV])9t:9\.l?,hX_$=Z
-%[19&<BV5rHEQk]RPnhR-D0[_-goM.VMp#-K;-,8Cq0Kq#\k4Oec$%/cBuJ/n]#9X'dVRH>3V6Yn>NuULY_usD8_J/HNnYj;=b9!+
-%/]DC8.Lt1?'MH!tRb'fF)&TOBlWUD`X_%k?CR7Y#F/mSp5!g==I3jm+JbNYUr>G7^"#Ob)p&Jf3b'P%CT]>qC]j,fW)*@oVba,VY
-%LsPYJE(\@I9fM^'<I)9Uhl<?@KVnL7qLaKN00slJ^[ui^c^=;dMi<j]kHa>N?;W(^-3l/776\pmcUi9YT76h)NaEighm&G[#\*"b
-%(Vf"C]0t>""&bAcE*.hHTL,q_XeX`'TXgJo<p>bT6=p=9(^$%Lnd\@Z9i<\6P'MaP!q)?k1c':T<:Y5(lW2'K4mH9(&2q(uV7Qm<
-%5l-pHTHW/A#&&R!ksU7&:\?'U!&gnP)>nd*^J[%sO;d3tY7I'J<RnI)\o_Ks=iaAe(`0^n*MML(+2Enu/-ZXX5:bDg^fY_O5;oKu
-%]&K\G^l3Tq7Fr]9`0/AJN'h^"0cMD_/`RNhG]cDXE'ma_A!_on;nZdR;S^910)bd.WmM*VLN0u=Pj(NH1/cbZitI*_rk=3*'U(DM
-%Vduc_6LE&1nA>G683K8>dPl!2JYDXh]e6$EN/g()Ll9EHcdmihFiZO'pO,VP&*LVD;c'Eq]%';R$Z[^;G#ZpI7B,%'I`T@YQ/ZTq
-%d%rQ!;o@ER@P!'3(ccc0b_9UpMOA!&Vp'SL,%MJATnYqdMR6ILnf8M9O8"q-1;Ja:EPps,.l.R'D0SqI-k-PTk@'J7%O:!@'3>OF
-%QR>H^8[R2IbXgs]6EU;Xj^]/E%N7STi[?ArDQs7,@GoXnEgopEZ:%k?:;P-`huP&7`heO\IS)8,[&Crfp8n/2M%Ln@.P!`r\Ps(!
-%P5K2,D8\sP].,I5&hKM63JSB2k[m<oq-IqGbl@"t?_<Kn$_1eCX"8f&60[:`iF,54+:eY,$<B,moT7ed./TQqS*JYVX-?1%fO`3'
-%K'(gq'Rn5?c/f;29*u>aPrk/QGBapP#V9^$b.\T"n<=q%:K"fg,aGif:m@Z/QX=iO"mf\X&uooMl3Ohg-);%<<^YTh';Ugf.qF(_
-%,'QIB!f&cu:%XP6FXIGd'.nZ-e;=\m9I,O+V)rN8ZX_eqJ@.fLflT)!=3_/0_>QN!H7hjAdgm3YH7Y=_)pKU9!3`mXrg7?Z^H+V@
-%XiX$"L^4EN&I%)r?<SUL@5]kXCg4NI00"Vi2noYq9tr9[NE-&mD,ts2^_4q'ZXTO,IX`/Pjqa&<7FgR%ms`_>`;o@)V^FXWZZbV*
-%BD%q<qOlVi<-^Xm_*2PQ53U33'kr`o[7@(JUF,D]IdVj>mST8D6,E:ilh@=ar1G-Ze/CNN&jIc]5H#SEFcfH<b"'/,ZSM-)MXuJ[
-%o2-HQ91\Ae;lnn:O_p_U,cs.O`sq7:9D+*R9Q._tl%dJbIF\H#FVHWp6u#&!,'RPt;G<K$*mfl8_b=9eN%4^GaoX;be<nUtR6,KO
-%0=_SXUH,?*q[q!%-M[[N,(K3NN4sdOJ/#kd$Xl5XoXKi3FBt(`Gp1:E3XA.TYLg3+EH]<cG.'I$)%cH8I0pMV4I<e:g&NBpKLmW_
-%g7YGPUCujqAQL,--\9Yh!cbisb`#,16+gBeC<BttKFdfV'9&W_lt3'c)l+'W]P(j'eW"O$.`I9&!(@5HW"C8XJ-#K:E@3$`g^%)?
-%6Z%Q7<"jpm?KS!Q\kCcZ/SIWA#L:"M1@V[T79[Q"cM/^N2S66bkJ^,@IfY>6[$j1f7KgP_nkTQg1,b]#YpIt]R^-*[P&8\b_]3g-
-%4fnbiRqYq]R0A)aIiWTAa/mu^#4@ST46H2WF+D;YiBq5IR"`32]Hb$;Tj0mN2Z`feK[[:jXBK'p3.<>S6n"G?kh2upU:Q+E.HFaf
-%-f4"p^f#uDR8LB$9Bs&OX[psLCTCD1M^:G/!WL6n`L>j&BBe\p>_3Andk]f?gC(Ds(n#.qUBHAp16BOmjY<t7Qie'E18t?AP`(Zh
-%6tIG!r@<-m<05g0r#-Rnnj2jMCssZmUj7:*c;?n]`9I=nJlg*0.-7YG,7!M]@/04:D#h_ZRM9Ph*CO*D]9]ff1Qr'*/s2iBh*RuW
-%O)TEj&O5+@7=DDKUXWpDZ2#o7:$\]_%k7[>H]]DL?5Q>o#J->7VCQDi<QPJ%0(=;F(ifgeI>*eooGgbN#)6ZJ5#YW(`fPL'1c_nY
-%eG4f\b(DTD6p"QYO!do?$02to*)<#t1dPP),I(9u/]uq\Mqi.;0%='G<UIP5g^C05TFef>c+-G_Prjk)F9B(&`PIg,$8#U7]N]Q4
-%O-#[uYeGF<6lhR9&_0mcJ&,nHk14F#KRS:">`o9G`ueP(<&Cr`F@fp[&3=/ecgqON43)e@h<56b]_X>tIpM7J>SNZU?\)"piRcla
-%QA[Odl_/KgpXG@;l+7.>cR/atIPY$(p'rdMlRau1F3A$-m0^,2oEjnAb;A4[ocbj2FRqdE@$$TI?']il$^;*.bW%RId)g&n$^u!;
-%[7f,70Pa/;"T3.g)KX;3cWo,$"sf(P1q\3_KT[ie/Nq1t6nhXnYr24:\QeTnT"EeZ<@IDPCSpgP=Yh984>nZI(RPNB1c)2)GtAk$
-%N5Qa*lm\0G.n-%/P@p&X%QrcQLpWn&C!rDT2>uiU]J.&<UG5$`cUBaqOPKs0er<#uWB$$H`sbK?<!gbu0d's3@1`oFZ(5cO@4`"C
-%&/`2!G*\Our?e'f1[]_;KK6V`P6G^Ml^"cd&IUi1XUGqQAEpk:)pGm8jTAf&Zj;o4P`RoGXK!4eUZ`0::cg=/S^6)]\+ER];)5`s
-%S22(qoT5po%UVWRoNeprW6"ltYWo:4bVu1PQZ>W/L,3;YrRE[tm3D\W6-"P1!KpE*C^ub-1o(YnW+lp!T28AuJ5q`P?oY?nRTn32
-%Q`rJDelaQ11&TOcEjn-73<_H`30k-5@/ts?<FmL9JjEMlQJ`^SJ8SO:?4M%T"0;V3^g7gF\Wg@>9,NQRCC+7F@<95jpE.Sqk0Tak
-%T*jRP1o9\W6Yr32ZPb%r<KrpD&1>&HPD*77d*.AKZ?^aUW<OI8rr!fm@.I/FN\BApo+EacQE?E77H-2bP,"7/0>27gef9Q*2<pZl
-%8,2Va5<8uZ:;kQ=34^FIDTpMi3B9T"2sSND3kAo6DVU`!GB=6(8,-.XhG4=OM>/"L+r,R4f*LF"'E+!ALC]=*j3-Ha4"eLE(@=%5
-%g'MaQqfAa^Z#^3+,D+cXT=rU2pFNHO+S`&ScinMi>+^gbH<BiYcM@@8q=3S:1Hp9WDk"X'D%8\(Eki+,&E(Jk36LHQ.s5i^9kJBd
-%UE:@d7*s?3O7;oMLZ`JiGQP(s6JW0@fgVQOZnn.9dbE"$QQ3b?ZG&.m/m;;5YXSrH-)mBJ21:"@@fVh!3olQU+/iYqV^=(I3P]5l
-%0Zk]CE8iQ:\bXUNJ_EgqiPJR?8a<Z#!(3pOgP^(T@Fik@/Zp[_5pc+!5)"KfI@s0_%C$3ZOTL>-Q`oD=Ua7^G^oAV?>FuH2?Q[&h
-%-d]^T^-V\X(>5f0:!Kb#`ak00IYW1ITmi4n8DIV56k.he''_KOWUBWlS0/G_!!PV5@U32`"#7RBo"41iRO1B2A<i!658slZ-8^C=
-%Lu*6\nAdT]dSCF.#<9U%q!\9H39)IEE>Jk9`d`!&]gs[2oNkM+W_.)QK8?N?))WtCiQq+]6)*/,pJ6F1M'3L.9=5jOQ)TV-@"QpW
-%mW'<#8M7i5jJ7tV13;GMYkjVYs03niX<.;e2#5n*oC:qiWB.UtLX#JC2W!I0rHUL)_#X]=93]0;.A^a]o=/ta&>8J))TR6S,8>o@
-%eKbub)(?9X<7sKZE#oPCo5X^(i-q0WGGk@kjoqDDD5#?kWA2J7e4g9j[]L%2/X'lP!(-^o416:iG"+1>Z/'uAKSg*B#3Z-]GkNCB
-%!t?`BG2J:@I4MV*n7g)E%^%.^!LR_BLk0?NU\ba,4N&A_B]UhOH(Sg2:2'>`a,P`K](riMCbfM\YuO/SpiL?Ng(ANk$r7,kc5:(X
-%_e\mD1$=LQqi:$mTFQ>JV?\Vlo*PA;,L]^?JC3ganAgd2hTr<b0>DPI*DaR#ADfP,n;'#NJgLhE>X/0MV.==SYaH(h&D1^ojBgi3
-%V$_4Q>_<Dd7<:2YJG3llLB0;%]#cb7CF/jF@*HO9s*f"'222%&q:It/ct`EN/bMI=lU/#ELW7sW9sd^P[a0B4%kYGTc+]hHJfe0P
-%+.J6S2C:XF0gE*.IqXgjCnlGq\GjjFrRf3ieFNR34hMN:d##tl/pQ9^BbUm@8c$]@Xitfa#qrbc4ElO++7>Eq[tQG2#k7$"M^?+Q
-%"YV[,Y&&cKXM;M&O^AHLZYBcB3auAED)J!5F\,tgG_3A[PX_@Yg0u]\b=$92GQltU\Vt=j!LIn&Hu3k5\U`D`3[@>FbY=^gaH</!
-%DBII_j'@tfp:iPg%fi._d)5$a_XW"XClEH!c2N]Prnb]of^\pi*WCJrG]V=uBP,RL2i!mJ,MS/n?<O1lT*$f<X:mnWQ_GXmD`[M(
-%%"POrL5n@t.8PcC,<F:[NHuI@1]TI2)*1U2aR4-NPN&a[;#\a!)?TN3\<_T>@DWdh/:1?JMqK+Q"2#grR4EKY)$oi:%)ardqM;^H
-%i3ON1gkVQf+oHWoeW*2[Xu6^&&IV3)^9f'CW-i:\+$ch3@J0<F`(H*-VFLsBUKhP'4qG^lasMGC@hE_*mL48MTq_/'lPe'k<JLpI
-%U&Au1\ktD(.n(QA[S)X@g0N\IW6ol`+gKDr'DObJVjVG-8>qI?6*l3d!1>1&Zq&T.WP-C%%t\4OSdIDjFVQ'!g#C*sY?`RA3J:L]
-%".4Lb#,@_tCHnNI3\%*;\b4Fi83*IX?[)rUj0AE7DJ%An&\G(]"3+M9<I:@L;p<O'!0SPg:a9Qo$Af2#9B?(Q/oETR/iu;.d=Z3;
-%buT[d[M5.f_fn^aMaT:@BW>Sp>nZWGn":oh\'._oKJ=%jp9M3o]g'Bu3EIX!2/m_&BU4!H"6&=p'p<6<6Q-3Q?;&R@\Ph30PO?`6
-%%ln?YB]a7i1"9^BZ+$96J9c4s7ITe/.!4LWA%t7FiAlZ<HKZ)j%dns]VEc'#+(&;3>COsf:U@5WYUu-mYsmVAoV!rI-PtD_/J@Vj
-%bp\)7s'tM'Qg6]8F3uA^45c1#S/d1LHhWKar35EFQ!O$Y,0/H;?+X&I#['\(5QOI"b1#f#QZ(*)[<`IP-&IiHWcO?*$r6H[H]Q?/
-%^7i3'dK!ECi"LYTLh\sh+02!mRVY&b6"J0r-Y']WKN.8:R)c$Q>]'f]P7T3t;AZX9;9Lc"R^&>K6o.1VE-YEH/V1KIXor+4&\'EA
-%WhC%gD/uHU-8_V'Xbb4-7DMKrYtIEslQoeKA[*0'\a"a.[@/Q'-e"'U]a[r1<";+J<3!tPp/GG.bjl'JG+C/d\r+ILb,"Z5k*NCn
-%<9RnGMU9k'2Wm[Oq[3@j;Ml5h9qbU]m4HHpOVjn8C4#P[7:F885``rg@BCkp]f4RNm=$@&Y71LCc@XC`fW8IKSh"d/$>Q\Z8rca)
-%oP,,qF0ZUOlDgkmSg8ga\aH,E-)BcIICE3*HVZa[b3>N6ll^,`@gdo4V:\A;K-ar<e:nk_imC>iD!&C'Cp#J4Wp"3.:olD\1SiIG
-%.SC>+?K,MNe)%8,\HE*OE6H$T_UU4aGZ?`<:sDrF<`0$e[e8<W./K\i<rKIWJg8P<h7>2*CI?dUSZSl\X#uSj:/k;u2L0Qoa,X_2
-%A^2hAO0WjaZ[`oe!;KQYqc+"Rj.n[aN(GKS&1Fi`)oT6gRK7l=\dE@`;2gi%rDJh&WEH&?.Gh*+Ca$#uW(_gK^ls[0@'>.bd:bQ$
-%$3VkJ:e#3VeM+J6cn`'\FfoBoW.Ueh]WkML=t36+-&l?&k$3ZA*_F6/'YBctQ"_kbYeQ;jYiT03l'4lID7(fBbBH682bpMV*:"[.
-%Q$YO2`t"6=X/Oc&;+IK!'THX<<^+I#72`QS_>h:ejn$"f!TLZLN)3&cf"20'(Vkf?#u7\`QP-QATH6r$OI_jYcte'ukZksmcBW4!
-%/":^jCZ#O)0>'+4G&Is^mbg7;pQ^Wd2b#FjU5nu*]8@R?9)LplZ;O@ZAX$U_AI9K^=HI?p*b9q^(QF)?5=-D.hr(mp@<Ui![7'co
-%`BBBtC7s6^.YN0:gip;XLJHik6b*L*ZT.TBLcAC:-k'aFW&d(`rNCn]L&m"ai5=1lS])g:+Bc:-GY#n4Ui%*u4:Na5L?)2^6rQHN
-%WYPB1+k>,!'l/LeCIkk@6H_5/n6.4:g*[(D;2D@$NK'pZ"r(Z"A7mF2BL<-7'tUdR2;=52D3aU-9Fa"WO^"NL)q*1EM<r6XG=-tp
-%!L;LKmG81=hiQ'#L%oRW&ic[#*)[:WBaTWKL+D>?.n#4]9#VD>ieXLP8EdQUr\u6^*)]B=fI'0WPs\0e(&#fo;<Es:F+np]8CKRA
-%oNWR>N(2%Bk/,!WFG4<=kt:7DF+%ZHV(1VI/dbHQg70`:\HsOrNeB:+MDc]Dl^\9BJ6T_I@]oZAXK5[Z(sLct.*/38R=(ih[4Et2
-%/@Qg<!/HbTCeVSE=\^4H>O_iSNQX#&<&mcI#cV;D@d;mfGLi;3BMVMu>(foH^mQfYJ.?*E\=tcpL*YB;[L*Ygo4jSP85"tPg<+F^
-%pU7a?9hE=bP&<V3e[RdlG-#5'P#/Kf8a+#roc,-H@]BhCgS@mrC5WW37X9TMJK>8NMCr,`kn[+(SkN:B6KG;bP%C6drZ9@q#gP1\
-%mT#O4V?p+VE67l$L#4Q_*otOOP,kqjAWujlE/.tO:.:(7893Wt:9[InJ"s8L1XJb##rI6%HVUNX]O'"2FtCO]@'O7s!"Hc[L3`u5
-%pSuh:Mb8g;>X:0J0kJ-]6ke675QbsZ7(^M'k>h1?NIs-%'WU%2)\Ahn,#[*>[l<f+Yu=?B77C*"0[8.R4?4N8cTp%G+=u$j8po2:
-%4;b0fi!>X!#-'ihlngFl,DBo0%e>:g5I7BJ'%"i9&gotG<(kRcTu)<E*;`IR>GRnp1$q3q;=KR?j%&oJ^6p<J'?t&30j$(2P(uWm
-%Q*EFg!/g3VKWNa63b^1c6PflqWBq+3LJj[#Fs_eGDa&\/>>5clC1^`0?*\sJMc(VkROuJDV7`ldON\^`%"hlM.CJ$T[M(#Y1b)(t
-%H!UTIDiBklFA2A+FU(U"#_Bte>]`Nn679\u9u>EV&icP?81;Ni(u1_Y/Q$5i9Qi3OO@51L:A+g_.FC^4"K<nR#E&`mRF=C\n("%&
-%(6i9Na[Il'Q+]J)fm4qb,SLZXk7'k%#TTMYVG\5F5F5lIPp&F:'r,;4bn*jMapDcq;?nk^d9>HNE`)qC0``1$H%ishXrIq8RgfR9
-%^rmmdhLc)^cIK9OZ)q-a$ar[^C_:@2.-BX?iB+[(B&6SN06c]>YfJirj/\)>"2Q/i.KYZ@D@84&j+h$II]4K:&qPhdRqfb#%r`sV
-%gu$IMjA=e'/*Q_LT8H;s@.`bck*L?=^slFB_2>?Gcj-:A&Z^tV/g)rP_'2h<LYN5?n"*P8U-^gQ85l(@[Pc;V*H@f6I&g2:XWS&N
-%R"M*4VA%(Q[M@]4=a(h-MJ"/$V(JXbapC[>J_XXR9UOAOEZhiE<sp#D<>1biL?-JF`24"9VCNCZi(\P-GiG_jSWCl!h/WmhL-:An
-%,k#'Hpd;Bp[MD/R_4*bkJS8#lFY;Xiki&7nRhD8E1l29/VcC-?77A.DF"<.*MNTqq-O6[7Gg^qg(_F3<]T>,I#c08qF0%-<%9^>u
-%Hs\DZ@+EW^#b01LNg$1oQmh*=*7$iTO8TSd!\9'.p"qI`*FN&S2hs(!d3($`PX44439,8knP]q*?6(5s,h0%M`t5'-ELohn<Mo9r
-%g+97Jo>Tb_>EHb*UL/aHR3AG>%tF1G\(q$e#07G&MRThHglLf7::_MR*(Q@*ADr^.TE*%!XZG#A%3lleC'6?_706QD>ccD,gRMF:
-%VJoVW')oNLTi$]O5LCMtL%jYrpq[mY',Tj80C__,bLROP0<9P,b[9;Ia!\`=FNL'7#+13&->cbI"]Ae:SO+k%nUp?f(SGA\-,bAa
-%d7Q5hZg(Pt(,#onN?CD6Wh69?bkm:']6Q.Ng^-hLjZ679[umMn=&q,G?T]AR1dYFn5:+QAAsM60"JSjn1*T[Aclpf+d(g^(.%<]/
-%5/^+2K^#i6@cTPQ'$&2(M+K"W<-J7hM3lW0%tIT@f]/C/,SPsSQG(]l6T/5VY,`Kr#n0/t,@73'1TO(n:JECL?i_pZ+?8Rh%9IS(
-%dB)5?1*ge:%&%7[1Td8R(/QNGFu1&O<LJpnJ`MG1OVR53cn71IAeC^LPLG+_Sc+4o"r&L)R%^'WF/\Yg`$TS@71U^iWC[5rQNkOG
-%$YFL@o?+%e'&Y&0?%b"@\dO&/&k&j)eHLr"dVY[o%$P[?P7]*_AYbD,+3aYUUrg,VkgXn)<#aYe6g6qO_`cq[G0A?Hf,_rO+=q-*
-%bY`-]h'&52"noQd&:V+.YWlj;+:]`C\.gI:2I,7,c*4Wr7[n4u*ET[eZs0H%":$.jjk<Ba3cAT_=161h1[T%lI0eihm<&$SauqYo
-%moJkrnLZf7D21'V?gJq1Q=>`pQLD?1Qr,Krn$s[UZY0-GljSq@6'?%/PrjaF'G2rW/he]gT7FSO1SP5Hi)=bc+<?RY]EC%rRpaZq
-%!p:ET2*sIOb`)TtJ1R6n-mq\2]@!F*L>5;MCF!,X3ah#.R]^n*YXE2u4>9-@-:;LGJjJ>qLK<*/X[::hSg6Bn0G;dW:bmJ6<#=qa
-%BL^$Ga\N+^OWB`Q"@]qF'W48QALEiJ^oYD1%a<Q+MB.AMSQ.b=KN]48B#3pk/SLd+m[(]7;Hd7j7aY]L()\,BeX+D>-70`t`Hd2+
-%Yua=?7WI+7;mAtO@9OT)g\atXTF3/Y-Kt.+..J.i''V7Xap^Qn"8L+J<+cBcZO[%>!=Q$fMFRB9'rY#2ZC8mk&=Zo%^/cn"!0eh[
-%22RirJSru;K0]l-1]C-bH8N.A\Q.loC('`Ll<&^t,QWNW+W$#hb%f./)Q,g=ag3mZ!k;c8`>L4'@XZ2R"2*fM0JJS1=@B96aBV=H
-%MjU:U0L8348@l2U/`]kHPdBG4DW#YO@'$KG=]5E#Z^27t$:Cf!9:W8<U(O`Ai5`Xq=QON6@?;+lWQo<7N'pZi9Elk)+^&qo%-UuV
-%l9!NVS#]`3fU87cd(*>"+jF`VjL,fU_1M35Un!aFGE-^u:3a41EWh:3"BSTtB=LTu_!.8.IKF/$dp'#EV*fF*?L_$CR.;4JfnkeH
-%7(<>Ua<[hV9Fjp"3f5C^mW3g&'VN,:f'<-qE7WojFS-B.I]WAVb_2Z]0fD3"L<;[jC5'^"c5A4m'uUCf6E=f)BP1,H+N;pSM[W7@
-%N/Eq&'K?u]65e<I=Y6hO;;.gsHkCBA>"5?7`8jek;edG*ShV'(?3?LLKLdh9aIT2+1:Sa$&55UsK[PB,'e"/JLt!6QM<9-,r/Rbl
-%I,eC*dQg9QnRS%e`&t%F@L^OlX&->MXDS2l[fY,"!;hK^^f@o&XC<AfMQhpLO/#XjFeTAR7519bfLLA.K+g+]j!_eR>8D`Ak67]0
-%pW99V:/H\6=?7YmLEkeh8`\!UD\q"<kO*E\_aQ7KdsIe@/!iN3c`0fAfqe8.D147>2APYqL-W'qa?8QBV$sf5+J)u!b6GbI[WN6s
-%mOU)0K'&n\0$H1tX/Q%ScR[r^nIU>dZN18nN3JkRGY&5Mhb2n*,Gn6C^!2ToZZk\EdmQP:iT0L:>EUpF+q(W8'F[IMaeU[H*>lac
-%H,#_[o?:(R1QC6i"%bMDJe9lmiT<IAhEi\,!G!:+T2r\V;Wp:fDiT$l6pJ8e"RHkM/c$RDOYn/G\KV\$?^-<=D:*tC+H:;??JATu
-%IrO&,A15]5R=9mR(Fts;:l'[d&GaL5!QkR*JP_f')bi7HI_Ob,dq[hpU@=CL28.4l;L/G28>`B),7:FZ,/r"$=&mV*1+D^#e-0!1
-%Y:*hDk!J"?)!\I.!9+CERqVo!o%APlUdjSM19<B"?'4'I:FIh]cb7RFm/V9[<!sH;Lo<?@-'sM_(%ub^ep90GR:$C\6Q]1],[&\3
-%oq:TVR>(<*)OR'(M%OJPMdZMc$A^2@2K4@P0ZdN^8Zko8I#bnH33^ML'DEqtAI1hJ]0g&aI1kFY]gdCMMFRkP.:$'tX;P#H&?].2
-%dNifKBqV-C+c2E>Gst[B'hT1k'k?]+F7qQKY9ec+7*?Rsm@9=G,n*GrfE.hXK;^,?mHR[knmj`U#o)Ys+3H6A!Ac`#H[*aK=\Ckr
-%EbgjMN,_:t,-=2H0$BE!#0K`l$mgMd4".H)qpS??X\Sk#j1MPaCScpak/UiuQcrBrJUQ.?W&-jcRBg#(fjnfW<%H3Qs6?\!X\m:-
-%%7*:9$6K""ds;qkr=1je\c09/nu5h+<+SKo.EAA(X[G`-$Jsk*TbjhO1)#+3b\I@L"(eXs!7>k[o[#CA'PcmlNY>Y\$2ME'L!fOT
-%2H'`Z@E*YsMXepWML\6uJD2D:E/I=l]oqLsipVN%GBKcL$QtNOWtMDc=3UDs6kM@&.#Sh5GbsDR'2%NN6P9i#hFGNsKs^?+3(%M8
-%]MJfO>)@[O6Z(eDZNtV,?]1Cc.S@rB@E<s6V4A5A"3g[`.U88@"6Z#XU&h\>Tsth'Xb9h#D%aoR'fJcbnX?9r0Zb[.'&:f$a/MP"
-%-"[d0Vq*D0h]*>skSHFt6MJ6BMts)e#m)5qUPNYoF[uT;P(Xo.W1(hU^B"<XnBtM9.sRr<5V^`"6!bHVKF*OQL14?IS!@Fl,YR0>
-%<a.Lp;8kD=Q]/W$Te\2)cD?(#l;#c50OK+an52(Y&iRZ&fY^-7^(/kl3f09b;6[>GkU9hm`AP$((E4_IENp`>Jsob^VPjSsYS"t`
-%4Agd=1>G-`[F,@i0I!Pt9HLgI*/[MSfsELW47Rq@p'^X]k2o+^5Vk.*m'Wo=7k-ef8aJAG[a?Ap>@TR4=LVH8P%h&"]'^!A@JZH#
-%Z19iN[-0deB-mr^AHil/!'NfA?lA*464^A-HB[lHYEf).<='b5'Ak<'/q7dNHTn0EDUS_l!`D^uV)TnX1Y%mmK[ZWbZ!=?@a4>Eb
-%-SDH5-I.Vm&70$kEgJ9BSuJ1;?0]aY;.4G=I30CT+><Y>fS258!Q!7h[i([21+Fe;bm["e=)jq^_G9]LY-#]4/2eFKOBKC2G[9Yq
-%E5=D1j/Jca'I9Hi(0^m9CLQs:2NDN.%Pgr1)ur\i#:T)_e^pYA(hqTqJZj4=E)Be1o0&OZBjcXXHU-H$6M*Dd"Wu0JY>C4^d#nnG
-%bf<uO6X'+*JbkIEI7VSr6K(+;HQNm<%k6S[D"@a8qB:Fg3naI^(k5)M^Ikt"T]R>Zpob8.%uUMub6[I"*-eWt&QAaA)-)C425l4t
-%=%#@cpU,!hE.*@jV7!T:ZhLDMUP5gl4.^M2<L?M,-F=p?KO/=EV1%`K/^.P%k!aSP^,/dl?=J0B)uS6>[=jOd"=5>1H#QfKMK,&9
-%$qNj%e/082/pjF.=LO[;+a1!t..E>%;DCEcS[-,8"thm]K:Y)g8;[IN<fi>pcl(&tBK7YZ;OH=sUaD:'HQ,7\6;^"nhA&asKir[l
-%_E=W0?D2Nh9Q8?jiNp[]GG\[q0V3oTfZag:`uCr[#-"9*&\jYBZdfQm)Yc$.d:V3LnhfX((\=iq\uo`J?-d2'DeVmrVo9Tg-$r>E
-%c8NBA?h051huUoDKLT8O0(1dSQQ)W$l3P<-E/.2S]gZBd/2aHJ]ACFG"u,c9Yo=\1iF*eOR#(Q,P:9R%GD<ge(8RZ0pE6Y87f`34
-%'bA+H6eM8s7"0Z`+2I<b#lPJlrrD[U9Fhsc&r[G5<g"-I&fHEQ%kHlV50_P(7M]!cPscHmAZr^f!Y$tm%NE085<VRu3gr8E+.M;_
-%+FOj<mlir54V^qM%Bn&C8m8XdA+5e+Ya;#e[n69kBWb>"5j"c;E-2P1/&/9cS,e3_iW[HJ>pOCl)AjF(q?7go'(tX)&E3'_a[X1T
-%Um2Xk@CjoA0kr"kC*hhRR$om+iu4eBXX/a^'?Pu#B>aAKPuKXF0ek\g-n3)-<KO[,V1p@odNKnraMLLN'f>-U44pIR:#JlgPD'$f
-%Y@^cSWpthi3&45XQ9sbN?Pd7N_;.4FOXmN-Q<7[m="^<f/]^-W3DDh/b0[I4O]>_?Br)J<'j%\9f^MG>[]0kf<G,7o:oZEJk16PM
-%&_:R?_rqpHN`n<d($S51@9oilc\]"GO>e:?nV!Rq)15>b/C',nRdfnrh'&I^b+i:jebibGVSP\niZ+)9Ms>mn6X8sq/gl4,6c*aQ
-%/Hg-j2]'A!"#B%*Etb[ac2RK.PI-YmHDTV0%d>\%FI8IWb[Ol"GMUT(*Tk_/ZY`c!F,)cg_d)*,]\lWsnM&^B,r9g2KmB'M]TO"h
-%gkbdVAD/RG*9!3\r$F;4VhH9b;^KJ5Acn?Hq["\jlJs(<Rj^SUMi.W%#PM`GMWcsfm,HDu//pjZBI(gk"q\r',7t"qE-5bk$pnd.
-%>;0Fkk."lk$)Af_pa"<EZ,egEUc.+oBi?<u,q2J]X(7AqX#j6(:is].WsMfq1AFZ&6#A\k_&`+.Y%AIZ1QhBPQIbYsoH#/PY7Yd;
-%#pn*O.F1?rU'NBF%Vj$@QhjHd)i.<jnjO.714C_:D1+jE%K!\4fc9ZF33\@Yj;DN"p=<W)f+&'2'0-B0S-6#9&aCl&HYGB#?83i1
-%"5!de=/H-tOpG*Ye3KFPXsS`9n](1XB<\Z/&[.e/PI-A7>fY?tMBXA]T%&/I?AW`ek[X^[:H7:/c5^#Q[sHK.oGOWI&UGGaT?.<Q
-%Y4*)8\;Z3Ea6UitUVsuWMW$60dGd24<k'ZnFTK_"T[_fP"X@(#4`L:`MJGY/@]fUL`F\C?2.-]ZN_2l<fSm>,6seW@W_CQC85F$+
-%TU:o*H,0uhC2E6`>,bU\36`Kg-"''qBVhnX#;gk;4Z0%Scub$CLZjWa5aII.kTdV6#h^7&,qbgA50sZ$,dk3Y8)Sc/?j,O46N5Tb
-%"'/;+#"]%M#n"R\L1/fR+@Tb3Xtp/]_6uh\8e_EEGHdgKQ66Jk1;V)=jdef!/#81-qSs>Na<@\HOFV?dK0R<?O+@2H*.VMfmqJXB
-%/rN[fo`MoQ$Xo.%0[+B9c%G4pL!C+p74)URTVKsbgfq]/rcaFRoLd(oW$&B)R!]^%rRhQ_Z3V=;g8qH1i#IoF7IYVE[[AR<Ze@r`
-%9GYj%M-SIuqZlfUE?MhhWLHFgaOtMF,Q.'M<dBL9^'h<0#("=c#:,U7GoD8jZpU'-Vnt9Lj@Ag.;@5g!INU9k9pV.Y1sHm'f97Kb
-%M%qNi(rLHT+Ud\!YBI]u]?b41&=s*Lk*:h?pI?&$A`SfKG=,!7Ub,>]Yp9]Z<2@6:<<9I%<o@aKo(=F>8$Et^.nh_["d)Fj#65(2
-%E)pKsnEeUI-0XSSHg$Q(F9Q>@!+h5<gFGPX+Xh^D+('Sf%q4]i!;d,UI0CHPK[?p<m8<h!Z5SHr0TbLOYlA)INOIO^J*iMYP9kdS
-%6Sm&[',SV:KDhP3a_H3@cIqOB-2gu"3dGguM9%1%ZgZSOe/n.[lt7$/(Nbf9Y7r*#bUl>ddO<`$`CVcCUbHQYf0tc'dFF4O`C3[*
-%0rru=@gD\HIn1t[c(CHcY>,t>3SW/EE0^^^,3^j3K8H)rk71`CY1]#I`8e?6*,cfY&DrS=(:]X,ITSNHOE;,B2E0Q\.td]l%fA0M
-%LD:YYT=ka"WK=mhi`8of;uAo;UNYFoJMPAQkl[4?qck)-PVpr`=&'W+$aP"qr1\X8:A3\6QQAQ)(:,qd4E").\j3[N"?%<)!^h,+
-%"OnuNW[J'iCc_2mc5R[(Ji^9r&B==\[YBRK`$"FS@LUTa"XeXm^,.AJiOk06!U1*t109g3iP@Z.6dd'F@/rEXaQghNW%8(IC/P!C
-%r<=p8P<:Moo48\YWucNZC8ZJHM^Y^3TWmSJI5^hILd3[16'eadTt%mS]S!5"o(n-Q(qiu;,$Y5MXa2\&&;7nr#[4Hl/Jnh5N[Gk>
-%.:Y&P7&u&p1"\BeSS8/(:+LlKk)(9(*[68q@^0HW5P'J)/`d?4O5b=1,#nGZ<hUC/=#0OZ-dZTT-R6:aH&Il'WW3ZNJda@XH/;NU
-%!s0<B(l`$IVh0`R3.aMH1*beknU0CdZ$Gj,3[5?6@/9.:<'%HF4PC@Y2FP*X,2rgj\KT79'pCSlmgYD.X/Nf7JoHN'>fA!!0T8B+
-%itrXo6rB!7Q7LV3+c^W"p`+oR=)as&`9@UiFb"!C@U<.*YsU)0&9YUBclJj+#IrY+N:71GG_eI'Tp1=gjtZRT"XcIO<"IC..nK%N
-%Wd=pL]n-t@ilVK3oG+b0&D97c^^guVVlSaV!D7,2dDbWT,j?ba2Ec-qE1#SA?HLS5VK33p^/bocp63UQBkJq6C;XSj@G9I.MVKnV
-%DO>[XP,($1kSpDuXeZ9+U_N6n*j-b;NY37cWK1h/P/EO,EUMp\Rc]&gk:lRM,u&KK;EDr`>tIs8A[DqG?WYZdLFKXKjP,qfh-j4M
-%+T6L1<HoglGaO#oR]JWQK/0Bm18q@](O"q'3:Ou_js96YMT(a:WNU@a*=3HMk[pFW/ELYXSuQd4k1Ks@`]fa-gf7cP/`.,UX7*(=
-%cm!Hr&&:)kliuRRL9eM4"[lg]:sRk<XoM#<]V#l$I>A]8B;gpNMKpMS!K0JsNfgFB^sNRNAskId<)m<B_j-*`7)]SuGFnF[&%I6Y
-%5eY'\js\Z2?;=PjU5Pcm9R=BM,Ff`_49L3i=`g8%B4WPdL+&?l!Ya#+HJTOV@%;[41kKGl*"oqsmZr,W:r]\>J'0hF_&Eu7T&JbH
-%)\6;a)hq(tW]LV89^(:^<EF&5DP`;p=3Ep*=s>-K-49hT(8c&3p=E&ff'sVsk8rD*,a/X(*fq'!PSW%<a0TF/fW+d"_TZt_XOPAk
-%lj]gO=LaGR8XBm,l)J^$d/"r9RZ_G`ZU3t)PKGW_6MM*X]cgq(h-joj^UGDb/2S;^!l5`P(*c\FJ3#0e)bk9ZA@7dC1]dp3<AO\t
-%&dR>b3"unr#+1X6XRs1T(tD:ep/)S>itVuk>'5jVL.K-''$66'>kbsA6DS"ZLqWB3dQGA<aZ,g[m?*C''sloJ*a5.Q$n)u4/);`@
-%(t]qGBTrg+1j#E+*&t5dQ#phSP>?7FH`Kq;6I]dEZ6c?:`TH!VNjItb<QS&fKM,*LS6RiaVJ?tH%2<Uj+UZUEiIr<_@0Gifa>9NN
-%SAp&I:u:IsP>m<U9UT&uYG,%D)0q`k.C)I+]?)\/$%#MVHT)G'-JS6/[nlS!b-c%t7@IUidOM4hMG1Sf+?%JOfcS$9Pa^qCC($gW
-%77]:X4dk'%A/)2h((MZ7C=#ac:3/&p(snd2?r_U\n:2E'5U95j>+m\/dOAW(HhEJ"o;<?uVdQ4K&'>8Hl++G-JP\t>BL#_aPLY>'
-%ikl[0_*-Hs"9'U2U#"mH)R;E+'0oPCOs/ILN@G*0"k7tIJ[I+S$^J?::YKrfib#`M;0hSuOU3hn#K17G\mh70`6k6u=7H_j*).4u
-%<LCk.Ttk*hE#;tf#tEK7m[Z+VE@*[YbS;Z'Ni_hLK).0bI3n3m1o0tI\R/H@OaE6h7bTuOHH"go'Y2a-OYd1f'9J3P!OUM(0%cEO
-%\-3$aokc"[1']XS8Tn7"CJM:%UJpFY-J:cA5A4).2D/SGlW"LC.!0'\[V\S*2C*no&BDK]T^?gN@Fsr=g'nqhf%KVKb^'@$^6K9%
-%9"90YfO!8,_c&<Q:W&AT324<s]LLJ]7dN(.!8O=W*0I)bS.5Qm%/D,KQmRQh'LN(_&_Fu/0?0AHA&u*`a39)=OKrGT&d^jVRfUd3
-%DCNGjkZ*T9SjjKQSm/T0R0:gqKS+8cjb?mL9LdXZhA%oJ^j;=I"Vk,E>U`$@PnaLh+^<-Of4BX<B#kdp_CRKRTrI/gbJr0q($)&b
-%"(KrD3+2I)b!!V:.h-J.aH;368h6-!6[GUQOjf]hBuCK=UleiSS/TgSNJOZ:8?^+=/soK9ab)Bl`(hT2QAAuaW@@OG%JEV;U_2du
-%r%jKbM3;e3gnU;ZWYa(`>f;r,`ik*@PC_.)+c\pUr#YWT;?&KmPb&l.lMg2i,".lt6C^:Ej[VEXg6;dKPo;+BD!Y1.3VdKe[TRXD
-%c?0A*^'9EOZpNM6:J/WR]?6O!jOY;*E=H$^p9"5*FRgrAILK-#LIpbq7RHuY2tr^NY#P>UR1G%E%N?F3@+a/kYQj/!UVb8;4<5j*
-%4QQ,OY^``"3EK,]._JjTpI`G#=+jbZ"/:m$RO3Y,@AG;I;Cn,?)Iu9,^h9W6>,XGc[9;(Ci2U=g\\UhbZp+27";hPNSnkI@e$p%?
-%TOcPEH)[',<5YG1.g<)1\Yc-te7&>k[:I#Z$LPj`8F-Z2r2Rt\(qisC>U0lU<-8coAeBW`]P-7+P$qOOUisr='B$Yl<E&oZV$e[7
-%A6,JM&88/X=Nt;f4RC&"66n,G!8^AKY$B>+CjCkk&5[U)K).eAl.JlV:i/-n@WE6[#l_OE-=p%XS:55T4WiNB.Ktq,]BJA`_!+Tl
-%T2d4r3IY*J:jBUGr!h9SNo5\k(@4_XCnp<rYf:5<[9N^C5rdOEY4B`>=<WbWFQfh>Y&b)!JP`VS]&.TGB<-j/-+T[cnLYnNi#_Ft
-%6ffPfaU&hs"UR%k6Tkuo-Qfhug'C_8cp//T'uNsl&r?^qB`haKT[Oo91!FflRfHG5Oo\[je^I97A7gPU@Z:k-8=VCYfbb?BXAF,"
-%=?_Im+=kqb6^j,P8s04#aXZ>fLn%npiipJuE"=nNhR3H1_JkDB2WMs"?.n;Vj"NSV`@dc.DPk%Ze_o=H2stXK&!"Qck_rUjG&I++
-%*N,bL-S&Rjf82tia?cN8]eu73&Z*@+HsrSE@8QQ9=<2IZP30"6k-.&4?7jLdlE<t&d]_5/A*/*9TR7MCfPMAR^KD_D#,3i_AV3ZR
-%\"lV5fbO?a^Z2$?HW,Z[ccSV_nu*"i^Qk^;s&g@+^h]#(pg"sk!(1=+W)sI.OFb"6DB3_HeI\SpY4-B`%/8#N?L2Q,fp19t_`G3C
-%MRMR)\'"_(J)@>P/eChM=la[RoTB6gHtnJ_TE.N6'1UN%XgCGpc@i41/@&`\>bD=jF\8ihK$fGgieUDgN\Xb_<Y>3/;h4KGZ3:Am
-%a-iAek/_kb(!BB_'t^G_:hIVW$M$oEW!uUcj$JY*7iW?;Zh4D7V]^,>UHAnAbXS6b3qr)lQhJ%=p"AX"L(ggQBh=+H8<!DfeGqT5
-%F[F[!4Ii".M;4Tm#L_$/WAhgB*@lda6h69M9?8TV#ajeD`K'3Oc23;J%E^gc\G-n'Je$]W.*-G+&SNU_&h8!@j`ISpUu@^\S^67t
-%?9@i?$Y!4/HWY=cISQ-@.dg@f*`dY1e:q>0,JQ^l0Oeu<OZcYdjHop9c;QUW!$]_i;p,MncB)^PKp$)&^1U9KISedJD[,ZW[eBIh
-%Q&7HLQkhT2?4$P.P<f1`>3*VBcqc:n,[Lg<S6i*P#oZeRVoR[*fm_0&_1Z)TA!WHO?in:^:]dgfnj,(`$;J(.\i:q(XJCi+G_F>4
-%driO%20,H($dtCrBt-A34)'shA4T3G,VE4C3Do+%Zf;sa#Z>'CAW(MX'Xbn>2[p3Q"6h2D`@F$jEL3]:<@=ORV:;f=V.HYt['5G<
-%<#60n1aqkeH")"3NB(QNfOoq422"W.RVBpn',E%_?=E_*Yra.'E%+]9[,rFVodIQs%>*;-A#:O,3@l'\9;+u;p(2:I7L.kQfTc%n
-%A@$=dnCa=""@\7cC''KO+4lAbX;:GA>'Z4*-ja$-Cr3$j&G9^/7S0LkC8Rj0)dW'P/$NDF6Y*W-nHl'f6O-_=^ce>.n+?28UJIZt
-%$0jq`9@_0(\al=%?J`AbCmT9o=+/de2cmS/#=Lm'b+TPrU,=Eq+mIA]6.5`U)'5^+P;bIsUXQl%n;!@Kn2f77HJ\VY&Dg,h;re9/
-%K[l?F;%L"-Qn*OK4`j`?\OQ#adkt5,-ml1@Oh/T13b2N%AS<*i\INml7i\d$51q[^lj?Cf?\AO7=X6=PZcu)%,37LcEW)?7kWt6u
-%=$!7$R^8<N:pI70CF*[*X;3[SbY$F$'2=[h1p]b-3AT:42]r^V6,:$":!Fl8,A=cf$DAg6P2.ZWGO4e*"r'A?5GkF[ZnlZ?P'@I*
-%Qo-"f'n`?6Ch\:'o8S?kb#=ER*G'^BYO27``*V+.1!G\=JM5/M=o&,_1(bXSA[;c]`cEV`js;e$UdJ]ZfAs`nV[6R4;a-TF;+q6X
-%1Z\tEVEm)XRK$>&OK:=T-daD4rQpGij;A;-J\F;e%?Y".p&a\Lk,e'++\m4'A2gn_fBM`TauU=/8LPWbdIfnFPb9o*s%SiFr2'-J
-%BLti%:Cdm`ArmbP8]AmWEQUBoHC7S3`h,M-Ci-&?='hB/TJGVs4roimS?DFl%#J;FUbLgi]#0-33tt:B"!b7N+YD.aKp2H58gWJ*
-%c/N/[@qQ@p8H:]TGg&k&Z_B/N!K.[O5cELn,WHJk-gE[H9Ok73_6kK7UO(A+_UC#(W^l``LP;r+MIc>9k6ZT+53$s:PVIlHWk4o$
-%Q]i^qVh.-O`p`/f15?iAo`NRiXL(gJ[Z'sL*A9Cf_-:N"[0E.4bH$?@2h8/00FgMi-j&0=77KqSB(kHP[q``5k?NQ=U)Y:"SdBs*
-%;T/<01NI,^>VQmu"IUkk8('XZ[GEld.n=?3.UC\\`0RIuV%Y2VkB`,&Fri)<+Lq$AYJ@M8>,7bH3W,-'+]`3O!lpEiHq:43Q.uIK
-%:PK\]4WNX;qX7JsMfR"oT+*&e?ncS$,Bn"O/)Lh@]r(r1/e@&-Y#Gsr5<p7Q"-BY^:8;+CkUVo.q5&j?e3>p.ot)BbqtNKLI.NLm
-%h]ui6ZBZhN1W.`PR#Ob9V"@mBE+=pT>"R7E,_!6@WEh)Hk-CcgM%2Uu*e_]1=b$`&#[OBAO97TKWN6(+P"Ljg2))"D>JM4,q1Tke
-%BVG#9PSupl#F6:PTEnssgP!LJjV+I3BWi%(M&8pUciLHI&`oOI);*2m=;g4o.74k)SLcIckIQOeYVcG^"dH]#7`>Q-cP_FW;W:Pf
-%J1+ad+&eiu"TJ[/f<2:9<;44MHQYl\c`L.Y*Rl%a9m^NbIP!p9QqP1l8S(_@AYhT68hHB<h3VQ(R$DDAalZRe"?DIeck15A&B.@s
-%_kZ\NR6%"UMMO_OPmL=S'UYu+'h1aEIJi#0l(omF&'?_g$9G:'Ii9,\)O?Uk.6f[@<Ac=B[8I!?==e5i<bnN7f<AN3Ycu`ZF(!os
-%(qL[kAf\U>`=#Ko=jIEL%j`\NTe^>[]ZBY>d/Z?JW=L9@S&#_D*%HTK#pE)f)IaG51+3o(?ce1J,u`t,rXEKgc6@ttc`mofm&]9g
-%,h*69G#0HGc2d-2,`S<5LslD\$8`C_:AYh#nu.AsKAj,RU1,Y7a+!e]Ac%:L($OhbPg$Ambcj'dEJBTc=l&ks>7]/<U7666pc/J6
-%%cO36d*j.3FU2Zo(G9hk_INZjqfGN_42-,>'qTdA)S6#Ee2hl$5k?"g%NF45W%L10n"4T4Zh4+T0Al@$rpoWdZM`X`i+Kh$fCn;j
-%?bcO3mG$7Mr:0-uRu?$:&cVXdYF!jb`'=:rlg(mXMjGeB4]1`6oL=>\s5u&mobi,"Zf[T;pg<tarj.Ns4%Ug748D,@f:BRMYQ'TQ
-%f!Kaf(t`FEg,t:"/4El3>;,-RgR$jEY.5L$cis&VS7k8e5[sLOIHQFgQ^m=89hiX%s.];KMa7_(qWshp\u."s'K\(EeD?TIYsZ/-
-%#mS+?Z'/E/qF+t<mm<jWCT>$?]1a,7QB1fATBjflJKReH"@:*LQ>@RV<<@Y$e1\qKZ/Fp7g7\.@h^*.tZ.2JVUhDms=o2rEAgHd[
-%0\Q].C]^S6$cZ5nRBZTs;o2pG2BWns8)'82QicqeKo4.5\WpP8L"iW-gk.&r>0oVSFE3`o&o5lZRWO"l:(JpQ7$!URQ+h?8a&^$.
-%_W$ff+-S$ld<;Rl:::EDa$C6->LuL?'4r(aT.T*3VsgO<ZrdL?;C3sYN3`WnG*fO+W?p9@Y1Y/Vq(9f$WOQBRY:5#0MldZ7#A!6W
-%^TRp^2Ip5ffY1X,d8$(hLsANnIrj6"nFnN2P@4\M4Vd3jq"dV%b"tUg99oo:I^1kYIc&O-.E94\0d5r;8T$YOC]^rMo!n30AGc6H
-%<8Fp&e>5[-8d1*L?=Ok@&n',4Bu\:hL-eeC'Q.?I(tcK@oW4-4<qX0\###Yr'_PRI0_:"lbDZ+a`0pa"H/Adp+lLE7-MI7`H\':,
-%6nF:f1:X25>J=_^%YIo?*\/0?pEJAY#`]#-iglR4f\OZnjOUZ?qW`fEn)Ok4j]1BZmA#O,[XfZ22%43nO:?uHhDB5*N0hj8,F++m
-%jj&&bX03CWF>sAIW@9E$e2n9NIhoLsE@YcTS+C/<XI\JBOgsX%'ppoLKh=3eSbA+*H<ZR]^'n.mPktR#Cm*N2ouUag_A1!hNffrt
-%lq,rnrU'^=ARS1B(/"_#OK_#[AFu'tP#PO14`Ga2d&mro[?DrSX92?ME[aa"K-P4d<31=4g@T\cOjH$KN!Y?iMTD[F"?;#)WMehI
-%`],fJ%]#uL%M<IHBB'UKeV;k=)kCI\jrO['=;&lKKQnd&S?tTA&1_o1R._mq-C_jl6s+ie3Nuam&o3@f^B+m["YjlRp6fQp9rJ7b
-%E#4Kj;9KCN<n8Q0<[#t,6.0uHF%m`?%rIaSd-&CBJ"DO7P"C.<0&b0a+JL]C,](@FEX=3/138ChG/j:E;4E+%>tGn6b%oW+-j\Ai
-%E&0(h=i)V@^R(b+Y_cYts5=?5>UiJr7K$R%gX,8>q!]4T-!-dBG&^3#+uhIMKo/7@!O"cjFh?e)d]Sh1;AT,-\%uVD)2Vj[McWB$
-%9S"Qq78%A,*P7)q([%%TJEeS*'K,I9Kqp>9Di:3\BMW:0CBI-1&bt,%`!OJV7LT[P\1*#`KRO4YX<cA%*YN7MNeAIe_N(@i'nd8-
-%/Jpa,"XN_/Rg08p`&-&L-#p5Spp=SV!1P,$r-Z+J'C_>l1"["_X-61+%*=6cK`+9!-EIF:KB0Mi<m\)?']mo3)e34ESP:p/eB-2\
-%:'AUTnksU?H0kb0mdVm;NPi3(.#p^QAo"'l%ag^mXPQTiV#;@-CLeS&<Iqu*aAO,H=CdspkY+8L%DHm8JtI"s9JN2k,+>Dg$YAf$
-%kC0st;pSiHF=_^-=$A#c5.fRV=op#de/];m>7PgX#OBCTcUg?g))*rh$0U#I60t=?:c5i`K#8V9:iR<FM`WSpnE8MUQ6KlZ.\_Ks
-%AP\4)-pgY:=WUZX/)5]a7&]g]+Ah5A`I4l8`scZ*Co&^MZ1)-ZFU@>uJgd"'Z9m0M82#$_3n"@u[r8/IRpup@C"=+!PelLQ`g1_E
-%2T0iF^lrDYUUe.T:sMBb)GFTJO&1GY.Fa'^=LUPJ8arUQRdOE,P=dqoBZ1`#EsNN0?B@K?P7k1DLS<\XUu6pT:[t5/f80>b$Ag00
-%N.*/fXb+beg/i&e1XYEiQ%EcqDCB.pGu`PqgiFkNJ$7r8=LXR<A<Z-Bo+S,?9a1\2XX[F7\@bFOG23=@PPC@t?AF8-0'mM@m>aS$
-%DI>Y83-<)XL8RG_>EBE*=qk?L/e@'[>F;Nk(-AWM/L1,?]%'NNC^p"KkV9p[12(WO"K:`$9IFeP8Kb;#2f^LoWkVL`<_F*c=K))-
-%(ZHD34i`(TSFDgWV0^X^P+ie[`,(o^L+E&[KZ)I0&Xk9(=;+:EclUX)NH5KRL9Zk%H#;Zkb-p'4LkrFm`'s,WLdkO(TBi2L%B+T5
-%Ket$U<b469RI,U%M'FX'!KE'[+Q6U.FI!Aj(Fnj"""FVg&;63RAfS)0@!ad_ZBU0Tf[OHg#BJm2JG*Jh`Y%DKhOItGEG>_n"%n?<
-%m+WYQ$$s3S"IQ&E+>QFG!3L=jHM#KTJ$;@TXj.Fu@kuD]`a@q6:%k8]eJ/gjc&F>&X'&/a"9s*e,nXklM;KAd+(;K/oImdbnXdr.
-%74<sUTsHW:/tNFJKZTo1"sF:h%6/XmL#2>m(L&Sf@673WcIIWN1C%RgPpm"XL>j6]nrf=qX'&?3lTn]@5F0R<NKP>M:X<#/g9Z`L
-%W)6RACfSB@ff;?,eRC=&iTr9,`dli46'Q@``ENF%_G3RP%Ohc7hpm\kg'6&g]rkX,lnGm/D.on^_dJ?JTas3@`<0:[/JiPjWamK7
-%&1@p,No<UhE%Qh,p#((O&E6nrQWfqr34\ct=LOYu8rnjKJoN_*Zkl$Jn,ah?PB7s\ILIO2Tl1mo:?D"OTCaZQ$ssc44')su37U=d
-%SgEMJ1,)/#BJ!@2icgZJ]^Y*`H]<`BFjdX]eFR[p?>,+Xh8N^;p/`_E:a/]K^(JKB)]gp'4)R!k<V8f!h1W8h>G[Ya%U^b8-NL<#
-%DWWfD3jJFfR0uX%F`9@*q3aedf2K-@W8snlQ5$1To_-_I3]qFE5<kbj9sr"?`TDeajs;AN!\/91/^M'#`OHLc%poH>.*>Z=6u\c\
-%akR/Y0B\7l[Nsd'nK"I!njtfn=Z?R5hGf]]_'OoK*+$HWErTm?RSVkBjg`@*HBkcmPP^nM(`nG[cS59klM2Z6Xq7gAnZmG8P[k`U
-%C/B.c.<3-r46B8b,p0DQ%8[/Kiamf17K`VRJuPKc!m_,e(mBhRn]i$YdOH/c`>9eZk#;^U=D1A?7XjUDS$S&9iGO:>/^e??W-%_7
-%1\-?fI57ppllY`4S*;XN)hNaLG>Rfuo[c2$L63dgIYY:[DUNV]fP-Op$%h9KOKb2(D1t,b)LT%V7+_PTE`X7C`0n?%N!7NNV2[\K
-%keO9<=9UT1OIBd18Mn6N/*R&i\sUu^:+p+DF(2II'1s-2MdjsXIOf9;$>aCNa)`#gdN?qT;5&hd]`d\f=edma!H2He)f"ngFe$X9
-%JPM=[.)]SS8qj:o3=LjEiR+[21XY:3D'`Ygg4tFj#<sal1!SCEj/I="1^b^pb,9FVjauSI0&fePnaTKOQfk>6",s%=%ArbJ,kTFr
-%6%@,o?LUk`i]Pg9-q=N7`<e\`%JLHt'<)o-"RD9m0'GS.Qpu3t$<8C(O&""@&IR6.c.P;!@-J5ff1\l4,]l6.ge8hD<9t;nJXoUM
-%lND1Pk6i"oLNp8`W0t.+l=)9d4[8fp1e&_IcH^!EXeT1Ii+u&OQn%c&k0?i5#ITKJV)DIA+%1OGUg2N?cj-Mj1I46^oo=ht#t.1D
-%ju0LK//BId930DK-:'I`9FAr$hU>*5gae.L/YL*(:_bT$b8:O+67#VCJ:!?T52"eFb(Nfg6'YP:bNoJ_@iKA-n<G@fe4SG1(I-Q6
-%^]L.'r87]O3ZDP&("'M9Sg>(UC+.\T`s#$#U3<;^7T?EodR#F`gc%L*&Keu!C[)rG-M>k`$PWp<Bg&^F6Oh9DC++LG&Rd$A&7MjM
-%)iC,*"#pQ(Cr%BgA(W3BjsSNF/gc,6GpF691Rurj@ctkO.W9cTk!0?pr^[L^QVheF"F$mqg9O.)0g7R*g6I)]-1M8f4AV[h]d/X-
-%Q$ZLHWI]pu"?-koGKg@rk.a]DnYRa#m1nXJY`O@@&PO'\<=2Ra"(f1Hd\161)1('L#=e*I@/b^64!:AEMem;`[Oac?RM+W$>ffnh
-%(0qd>^W.6^]/o^cN"r/sW6e1k%l\g0:A*aa,2a,rc\"OZKsno0Du;a7(_lY+gn6<B@]SdAajBp6!Zr<e6!\8":=MOL\9f/%;NP!H
-%"XK(^=+K-r1qar2<c5oKbk,Gj^a*UE2n75e)38s3SWJ_5[4WNu!rh8ln6@e;OS`cVqO%hF=Fn`gO/-3!^u/QhmFnC.Yi0Z=7@8ZS
-%4E_'t-3iT6/V4jccp5"sN5fbG=-BE#9&>4O:6REcB![8(n!8V=<'eg\,dMZkdQ,0D.B`;0`QgU%\X9D,gW&#lo%<qXl(E#EE"W"[
-%r.>07Wl\:%#))NV8>E<,XR<.39gTB_@"hXkf)^:VJmY0:pqMo-d<mZC_<_)o_dR^,3FkgP&.V#1W&Zo#2!D:G;s4=[M97uE"Rp3G
-%OBU$qF3IX;F,1%Z,g+b9^gpW?H)d&9KH)CGkgD4k))c79MlUeDYbP*U#`pGV$>4o4)Gpi6+_`q<[Y\E("^3CfEh!kclMjk'hPWr!
-%0`e]64;;*741)%NEsil5.a"@9T0UUOESs==eH+/'JJ(-8,,4@9+MN0.Q1^g\I7'?8(Db$ML_Hi_1]>"<N>->%_ASXt=0eN<K5'_P
-%J]M"Ns7oC@3`jjZ8;e<EM/bi,-U(LNHd"*kqD-A>:qP&CWN>/$(4@]4O>\j,7V(SO"6,"HOSJ]braK9u"/2QaY?>`,Amh:AW9bP%
-%-/pGM1,KXZc^0UsZ+5"Uq"p?W&HY=KTR?*?k=(udp00QhU,,c6"n5W-0Lk+);/'d'7Bj6h)R+TVIQb)iV.0W7-<,3?1is2lMg/[!
-%CH8.\?5WHrYeQs"Eja>GBndlC#ce9O:8EF5c":Dn'&euUXrAu+_?5!D4'AB4YQ.XBn6=V+$NjL,I\_UOirK[2b_pu].sB?W[R7Vk
-%A.r$iYS[II`DiSdILDT=Ul8mK5j%_^$?[LUk%4ubeN2(L#,og@-,'fr_@H>'g&]2N[A?k=Zfnd%%'"hSAS'VQEu$-cYZD4Z.eb"_
-%=>[?&_^\PP7TR@J(K(dlA.O;p.'Y?$,;!]IAg6\2,W$W-+0-9Z;522d<"(>"Cqk!#%a[t>FA9V3+d0IiTQPf(Ke"IXjeG^B"/;E>
-%UXU]"@pQl^E#VUoC6&IKqSR`l&W.sn,o.g6BO-@Hg<e4IRF14"UEpo.b*p?s7`f^M/Q15o88)*=X(*0p1Ml?-Lu&!5iJr^%9tI9-
-%Ql9X_f'`/1cBTfsnO,?@6e-Ojl79G'kL!.Tm($Uc#gmJM`U44D+.sZS(p>YrUd,Z:>S>?[\u^n7:$HJ.,E.RAWYT.fiW2AJN3(j4
-%%bOTSN1i\hV8MjT!,iPAZ@VgTcbr&/dob/>6WL1^+`8#J'Cs#g_*ZN+=.j-eH),?dZqA]hKOe+0F;)/;,GG_F[gpD*Dke,KSQ,1r
-%S+T6m(P[c3P&(a6TW0qbeun.F$cY<oK;n%_gd&?UE#gQHGpDrnk^!gV"CS)8h$,!+of^T8#bDCQZ4=iO-j!MKp@Tg^=;_j:q<4UE
-%/r;I,Oc1'3KUO3N/4."`?;X4_AG0$%L)LZ-"t]OE&%$-LQQ"9ePGoc6O5ikbhu[':FE@H+9`,s$^pWi=dKc]+JR7TK2Rld^iP2G^
-%?4Fi].<d\rTC(B<#N++DBNKoMT=_./&&2EJfL!*CSU[a\Qp%+eN+!-)esRE8L%E1"B!R3U?@FVH6u>E9FIcgho'X1hna%l?!6#=n
-%D#hVN6j=p,XnCn?D7e9"%YlL9TtiGk$tW2&K2TiWO;AIt!fUe%=0%2Lq[DJaSTaZ2M7D=AA):$AMoiate@K?H-.+J#0X$n=L%Nb"
-%]Uf^<Q3cbXFoc"P8mEpM-CG0o1#+p:c:]ufO)?b\Rp&QHC2huENSs&J-@Rr>K?(k5/[Wl^iN-'17pb?)AJ/#mSK-URDf[=fBR_QY
-%hb8_K:@o*kBn0lfnEL#\I!Q#0J\5`*8W4s0?k,XPH-J`:#<"hR>+>c0UI9ma!,VOK>_,l%eFk/(F^dR2kS>!7i<H6(BXA^WCW[:u
-%^\[G`4e0G'A6?p@Ho+o'A$oF[.?gK9+m7B%7Np"k9_(YE"(d>0/65jQEL8"2GS+\)m^<7uAg<%A+/ROcd,GgXl#,Ege_$Nge:7af
-%gNqPgYZ7t>m+!dY>3aUHDDa+C$/HB?!d^,Hl:1+m6ZnRE.Bk`[/JXW%#aX+qME;DTZg^-$hp[:7;p+p#,-7*K#%p0j!"$+mSY`V_
-%T:U846@,qEjCs1TJJaFp>D!2cKW&f_NJs7,YZS*%AS[,a-X-MG0juidTSHJ%.:^,"A="K.8*ik`^=6hL0ML,9(R<UX,$koLRKXJf
-%94U_M"`XY;+P7[RK&K2j*^a#'_:f"9V1l#PKk3_aQI:i=Gh]6c8kSM((7/,76NY+C/]u1gj)4,A&n*8(\RD=cB$!.AeL2A8-_URj
-%HQaSm.5!J;1]Y$fP_q<gjA`COoNkU2a+>3AC_0ac/7i!m.gq[P'APjCe9E1[LbP=;BU$\pac<X[:T;F1-3I3;MnHj7QTA3cSoYR7
-%Oa8:rPGU.0?d9N&auIE5,DNbk=M+KV>eJip5Fc!oYd.DV-V"P/*YX!-PEo;fVB("0V1goi_g.&Fdc9>pU??N)"\c1p>?VoH.DH5d
-%T*$:>N2W(S%H_o*YPr'[J/i%Jg?6;f<L2IB@a1s3MdT'GQKGS/<%#RG,_4mAYf>Vs#4h$<AhYISSY<fR2S&>P9T)'L\N/)'s/cEZ
-%VInt1l1g-K7WIage<u@/a_1(hor>\=:/)]HD*T3Lm+mMs_P3HS?m;=`bq,KO1PhsPDS?sH@)p*m@sQ>Ci_gBDJSQKU:`Vm=<M@B7
-%%=gml[V/;%e83)r[DSY$T1"7)N4ZFLBNkQCBi4@`/C7F:=:dWTU:Ir_(S<2I%h=FT[r.)%Dq#IRoYSOiaORqs>ol-+I#@&]WY*HJ
-%Ak1H\rB\95Br6@caFL!`VECk1/?2uq4Y>T:=g&KI[T##Y66P5Dg$qj_'hE-f/6C2\bA0!IC^<ZnaIImGQG@2W\%19((32$9QlCQ`
-%`L_7],:rNo8u-256"1n%+?0b&2mSb=>d+/f,7si`:`@XfFum&k[,#P+Zttd1P_1)l6PUs?^^'e#p[EX;DN@8^h<B)"a_?Dn!;iBV
-%Qjq:pLGDDjXT>iCR3W.JZOeaph(5EqO(\M_*!M<ugea7D4lS7u3@nj[ke/mYd?4gi81kGu\t^1JD%DU,j;F9@7mbs5`_KflKq2$l
-%S]!>_"#.imY;j12^]H;&Ajo)tfPY<O\+"Apm4;I:BQ[^;p6Lm"X],H[]@M4NreRqe_7VAbe7MTTbPS\,"S$u1$'/b4Sfu!;J<?k>
-%3d@8+gd$2@A6C;fXWsrlFuef,+i7T=8C$FBk!leqHHc_,MP4E\^ck%'T0YZ`*l7,hK7:rl,VTI<QufaBhM,"/_gn&%62P2J(0<0>
-%E&2iK2UI;D<LCI'[%tRO`)\$+O+f8OfV3r!`Y$@*k(g=D2+q+0W$k`%F3)LY-(bP^eX)S9^UG]\1<j<picm/A][]Rr,IBe.[O%\Z
-%%H'b0D(T+LLaA[o+4`jf/qTp10C*I;@nQ><P\;fSL'4;jkD=aif>+Z!1t@fl:P9c4=JG<Xd+n^e+tMHb+@)<Q^7<oKCS!#IH1N\V
-%`BR-kf!J,Nf/Z.%W"o@ZEQ%IjPOUt&#opOA9273[`Ig=8I2Np:N#hYTqNZkCgfMrFQ,&$jZYPt+=>(f*>G2u#QOD@'Y-CTS1\s8%
-%X(VIqk'l[(N.09,f84>\h5:b>_5=kg/"8JM'>4PopZ/W9G@#^bJ3@E6I5r/6f5QgGk'3rr3-#m$4PZ.k3L5Kt,Lj(EJ#U$;KU7/i
-%;_ii<eem\1F/r,_&RjJ`_/nq2Q;tpfJ?E=2Og?@mkYjsh()J6%qebQ,CGLSk$@.jinh-L.N0\mcihY.WAt#?42%hlm.B-6f9WJ)%
-%TURqo=GnJV-RBMe3^4OB:SrM<M%b$%j@.IJ3\,GH]Jufo?j)ft#5J`Ff$](LP1&::!)[#I[=QuYPPLV?5te)s&8@X=;6uo<:V#0t
-%?iio=B!T^H^tj+L-H(a5ZP7r6Dr)oZ;6(S#+G.5%)U:/k5Y`Sr0K#YA^/1d^hTo)bl0UoN'@[UUP=m4DiBsZM0Bqr17>g0HaqR5q
-%(g/D&C>h]8Q;Ek_)"fX/Tp&`i,1O1p/Kl.B.&Eb^/"%Ke(q2kqXN=Bna9Oe)Vd"gNh6gRo1m"Qp!<&(,'?Zj.Rg^T4AIVnaA0\jr
-%:a2dc^P>6Ukc^Lo!C2iAZp$&^LigWNGoq`p72f9?V$L1Y^<Ch:/-VfE7E>b',kWYT3Z^mOlRPT*0n(_T2iD%A3,>TP4[XKZWX@ee
-%G#>maY:JDL*d%"Z"O7uZeWukYf+#f9qPAdEB9sAcCboQu%lb<CS@h"#H8/GT]&^:VO?SLQB9W:ZFq+p>%M19.0(_sM_"p=8.4X-K
-%Mopm_V%L\!TP&-PbpjoiIOYHTbRPFG&<34'<i6;'8k,\h(^W"8+#=Oe$83Y9QU'"OeY8#EPd)io.m#?R%-`LdGQeWd>e=J-pVI8@
-%8@t2&#,Apl)eV*s5,g(i/JURI[`Bg(MsG=ol;EB3e\@a*e7L>\/oKf@6Zrp(%k0c/!#e8\mfir_1TKZ5[t=dR]M`0H`"#\QQXYE<
-%N@L(/Z_o5uX_$T1W>PjMQks@fAcZ[]^`-A(>cYOB9>d,=RMls&YS#NM(hcs$K>17Iqui<WT0P.dk2ZpgCpKSDZq07$EGDA_7ZGAf
-%I5^3m>D1)S9]dn$E[_mncJW/XR[%S<R>[dd99Mm_PM"JI<7@OmLbWQbp]eE0V.%q$(cD<p?Y;XKXjA8_1Q9WEXj',RAc3dP"fUpq
-%/C6Q17MN\)iTI'JfTa_Wot#N@2-.o+W3RlUK7e1.JD5+&bh>+1[N1S=oke^.Zjf@XeXSOgP_#)OD=/9AD9tp0K--;XO(i8e92uK7
-%L*Xf($_C.Kf")IUoijLlc"JMg5[-[EZ9>)<k,+itU1ukF</Lr[Z:IT[*<6DP"at-N8A74AA[,dU0=<:9#b(o#bmL[,mn;,,88>ba
-%U"B!(3(0j9q[I!s"cC0O\7IcW!#/;H2<@0Kk/jS9WX#sY5C&gDQZ?_+G9tbuJr%9%-]<Cc`)N<\S%8s-Pb\Jo(,BsA.\T!fFLV0N
-%^R_&SW%1RWng;iDoQ&s^G,DR7&PhFOUtuN^R_hLlJXA-q8URO;=X7!'"`V(Nemub!7QNsG$glZ*nL7&2NXM^a>@*?t@%oSen"soH
-%q^pMOA-o*Uha`Sjc7JMP;8E-h*,jJ'G83S8=_.R?8`JpYl\]a+8;)4r.!QcpJsH7`aDVC`+b(Fn%]$hp99*T]WE5PBJpC;'_.6.6
-%qmXarmIZ`O:E8Oei7^J!31C,s)(<U%Vt9AgFso+CD>"@KL)e)^+\33^KZFNP`dYs7m-nhPrbIKb4-T0Whqq]=nb2PMc/nV*:JXF'
-%"P_+Lq!@b4d_C#Ss7F:&s5g_VYBi!srR1]:jI\X5j^3K2iqGAb0D^1tr+d)I_oXRHGgkFBlcIKQIeE!;s4]"$0B29rLQc(m2ZD=C
-%S\9?ms6NO1q6/Cgmf)79n%[t6qrP#!DpQ/TrR$Nf]tOC0mAl02o8B7!Va$gRrVW/.="eJFY5-t)F*[cIo&ff8G.2tL_E7Yfo/HE'
-%_"nmsYWa['lFZ*MnuK6</md">r?&,[`Ah`g?GCp]jrku&`Yd([];,/dm.J>9D_M+eD4g1`mi)[tY&7`'45IV4VX(]mIlMq!p,DjE
-%h#e#=(sTA(GDGbcc/kGdDuOkSlMe%nhgE6^Ddu=^3rY%]IJSkmg["[[e[IK@0AgU:o")KJD]-:!H$amenLq@ahgTWl^5]P1]\_IF
-%Qe-"7ItJORGP5qSDn`op4aV6khp]0N>X.`ik5O4Y'HXq2n%Z2Y[Z)`g];>Q,U%J9O]062^o&Z@KCY!h#h,aBUh7Yn)D_<[BqTZ_-
-%bB=)@rpJQO0CKjrYQ"4<?bQ=0S$OdH2TA$Grl)ZDq"O*t2toN+2dcOH`VH!1hn6XOfg#?+c.Wd+M8s^N"Rj"]IefIkY>7>H)GEB*
-%_=[Ef=]Z_QrVksMp!I=(QH?LrMrt>NR*ml^F0q<p(=S??8foX^UW)l>Vr25C]s%DW/LIcj2Y,?>/Z&t\9`K/,p@[apZg1u5HM^Y=
-%pnKM<LKPO&XnR8XQGu:7-U+`g(s'GRo_QhUhd$*Hnr3SI"0jKHG55"Hp`I6LqXqgU)fNVaieI@1Nar$=*/s8)mJR^gnm3&Q,Nn"H
-%SdP>b?6+,<?2sdH&+17k?C\cYFa!Y6[&2^WTDV:Zj3?]YRhlU^1#L1AEUT2Vm@(5"gK=Bo>>D)A1S*DZT)Rp0cA1d\rVufb#5c:Z
-%Y1NXMro*7uB?+*>#LMMFIs#ZLig&AlVrp"BDJoL=]5Q96P!?KPa5,Vje(`W\cd"2X3'Y$)BH'6$h<jdYE:aV:kJ)LnF+&',!,'8?
-%`jF@dn[P1J>eb`/p4.."CKPYe59@<5-ZgeUC(O0u9Pi'KnEC'(5.X,[lLN1AcRr:;i=G!KIk4I;NSR?*51aGVQZ'UK\p1QH`E8`#
-%j`pc?c+u,)iO1H@lKD!pfCYf^FkuM/4anM7+*D\'lh;IZX`Q]gnh'ap`U.#^MK`n+X7UmZnHHW+h:\6LrUR3*NXpO:\#$c#@.k-0
-%N?86HEuMK=Ed32:G;FYs,"s>#V>l=dA2Z6""(3n!^A-I%X"V1IH[55=[aGOI4?UaSDJm5fk2t4=?gkUQ2Ja1J`4,:L6V/>69>8&d
-%FgdRF_jVTkrsc<"A_=oXh4D<mI![O=c9L&SFu?l.3%akL\<&V#7Xs]W[$CUiM-iUhfgVOq2>!T[$,>2M?Mn>!`\tCmL^`'gDDs?D
-%qZlkEr8[$B:k[^jo"6#"M78^@r7+iNrZ<>FGU$_oJb"UUJu8D>o8"LahJMB%GfkZJOV;c=%rV-hps%pdDdT'+?X-lA^\Q^=[p+5?
-%*dHSF7;4]#hgWqas*c*3B"%_'#35etG9]1^?Wm@,q);s<f,(X)\9N.9rW&_n=5+S5I^aO<A<._]^MRI_qq^+S[3("]hT0#M%1)\Q
-%Sr2\6X8h!Ys6.0Vk@P0^X*=79__E`$@\H!]WS>K;G`nf1Oh'A!/@YfVg'd<Os51rTJ,28,\W(T<<0+ViIU\%^jc?$>?XBirhV[W&
-%q=WjM=8.&L/h[-9,JFuYn(kCZO+,D<^'C6WJ+in<4J\P9n*Jf`S#[&&XsmYig\j&i+,Jg.3kF>c^A")kH!\*cIql1VgHE6VX)dC<
-%]=A^kq=@[Sf,&'=6%7+-hDsKVkARQ\^*@a1E-tr0jITQKH"Sre?XCIWr7enp\\2AmbXR=sS_hgihjiNZO$n<eh:_NA3@rbC*ToAH
-%d(!.Sg;k,<ZgT9HrMto_fh]%5[\Blg`R<D[h!\GcO'u&BLr/]hZRVMaA-kFc(rTIPr^ef"[Z/!C@1XA[KW"\scSlIS3`_ml]ZhDc
-%nK!/l)gsW9o&OZK]RRLXM"?To=.ZG\D0Yg4%trTZp4!D\@OjP'#_Z:tf#IoHfSFfm"@Bcq,ri]MfSFnCa\U_n0&3?QH5i:L*t/G6
-%O$JN'C:"p7]:XJp[rPH>Em-HtpRcaGilH?:"MU_WCu-PAp4k`uRgEAL@e7;_eq1g0$9p*$i;neM>N(9^8e$W:FT%'/@X]h+s/GUI
-%4hnOQp$3'<J<(H?Nf7[:pcJ:;n8EeM9Ks&_bLq\1m"&\-O5H97\UT+HX81jHVW(/2GeB]0(R0oTCh"#\\=b`8'up^IGX3?t6!`:&
-%XEo7XW;C9R>/P^#TDk5oo;FkoYG^FR['f46,<E^HY,@9'`.rY%D&q3sR*bIpYQ9dl:&d1CA%AUHDIcq2-fk5uOLgFRYdG.MO_OVF
-%:WNc9drTkUFgF[jYlU;bLI!WmM>o]J';,1%Fsm6<54AO-s520"5FcP"E&6eMaXfic^]/.n3jqFBoDg'T^D14:".4%6InO$+gDIqm
-%$0U`qG%AHM1?"24?q`P(fAbPCZT#Y0s5(?"IX1JVjn3rmo:LD!XQ,oqV#RL?e=cbr9@c7V@q[[AE#?<=,IYr"q#9G8=5VlI?GE$p
-%J2;V6+oL<d7OfBBR;ut&a5SO>kaRN[m,b!,2#OVi>jjE@n`_+]NFYpM3>HIRGLQX@HrJ2.PL'!VmH'gUXtJRIjf2LBEW4Qn87FKA
-%[P7dIkYBa]:@72Tme=<,L?-ujDC9RKVsF'uj/mDd4Ru3.-DNaN)0L;0kVa+I*Y\tYj5o/O?N'EEg%SikAM-4H7&BjuX[b6\id>s5
-%2tFO2qL"6(rd]4MV\?>rbtKk8i'-&F`]cj@pGAqQ">,Z,3f[([+*fid.-8Q*9)56aa>$;tNHI3M.C[\$:HV8FS'/"MIf'!$"jr8#
-%@2quaS!m-m"T&,WeZ52.56's9`PqN5rFB5^hVYEX^YXA;\'(7B(N2LP]m0AKc0a3WWe9fYZ]/;UG!A,;innS]lX0hZ=O?PN+<:oe
-%UOdMDOPYnHoUF%<P1OVY4FgQ%]dP]RYPKn77&_aWnUW;R]Q7`acfN^3#>bu?N=<c%qa79K4j<&:.4Y<Tk2N-=nD.mKDJBI^-L]^D
-%YP[AZ`C$YQCkN)hDO5R3AXVrK2qNF%Iit,<]jC0l2Z;PrBSeW&TK><N4.$9+?TSJW2?pSDo1,bc?[R3?hR2k-UUT@6osUf;7D(5;
-%H=<_pdG&^6[N)t4HQ2A9D0bTf3I4n)No$(s\)gHoc2BQZX*8[a]j$.[B@2(<D;VP'kd?j-S&qQ((`c),n[J9(^u9l>o?Vpd[OYbs
-%n@3:G9RH^ZO6aWRUlF.Qqu&^srR*:GD%,_QhoeNO[JSA,c'oZn-_I\k9Z_eAL\oW`Rm3KMY.cV4aN<9a;8j3op9k$Ga&N!(jKh&o
-%'n7Iu\>Q.^De7LlOG^f<Y!4fZs!)j52R;kFqNu-c8Uf)L[R!Xbpm,dZC-'ecHm!@\<k<aUQ2(`"AN'7.IMA#%CFAJ^#MP3&1+,Ra
-%R31qd4/Q_1_fj\*F*Mm?O%FHMaSgBLU@TJ@rqc<,-D;Uo3taL-Ilc/i(G@_SY<Ku$r6+tpA8\6`)g-8#lYB\?k.:QdUFl#rgCd`(
-%2'-.)HrTF9fsoZ>C"Ie'c.U:0muBN(5MhcNN4Pc)FL6[\G0kC>?6AR-c"T#,VB+0pdIjEi6!NUMd1/4k5t="MdnB0Om%A]DhG^%r
-%[Z(UK]6j"[HFMAt^[Lmp]??NO8/=j9,Q66^hAsKm(D"TEr4.km)$Kg5M^NiQ2A2T@H3-"g$2E!(gTTJJ]!u'@Va&V3%/8f5kuJio
-%61WRZl\jZW?MsQP^(8edeh&V<I!p?_FY=HtfgaC<V6b@NnE/m4mVdbAS%?1@4PnDZE28!Z6&0HUJ%9q!*pI$\6Md$EJ3;r@)M3))
-%h:(oemFh<)ZWFoV\_KfSS@/-*\+9>a9Sfqmq'#%Hp@Ns-?JcdOp"QN3o\K,Jqn\t1@9$G'GW14rq<%UE5@)"7Ik]J5?gu+j(t+t8
-%5;mP%^6SKjIU^g?Y(NhrGOZM4_Z.74m(`kmRB=^1Omlcu6[1<D_rE]9KD^LCc8Lk^Gk<&+lJBE#78&,OhZuC_*M#[*NA:>R>.XU@
-%eF\aY.6`24rR9.0[r^JgqVk#K0A_1gs(iWQn9DUb<dOa5["[7,rsqD"Ch=4`TIjbeprbP'NMFa?[$a+*S*=F?ChuUuqE_3[NMNcW
-%5Xs3l7WUDTN^hLFBNc@od:bQZ9h1uCBJ^`G1i:1iHSh0LBJ^_Cepe$:irdS'HecTHSV7oFRsmcBrC.3kA&A3,;J/56K_tYmp!(*l
-%dsF=48)glb&dJ:-e]l?eqeF%Cc\@<HY?X*^UJ83RK[FT5rV]_%^SX.>Fk?WWX&irss7Q2ELi0pi42617rBG/=0rr4fGW^GIjt"-A
-%,P)U.k#U*o,P,M2mN-i%C]Vj@['^q_s8S).-$u>N0Rn*r`CEgLHRi5)a1C"hDT""#T'L94Wo2g5Bj,Fi#mP_P,Dq4oj@m7fB"6.[
-%K1fuu@mk[W*[,PF<nDa="1ltA]7YB6Q147Vfh>TI6$:&Zd#**=($dOgCE$L:W*p](//Wk@.u!dRC0;XHP(Gjgc[Yugk5+'<>09>&
-%N;\3da7Y!t?i/YCC+LH\p\LYqRl<9f,6i@E?L(DQE,Ve9qT"R']Dl\cbKG%0#/?^ll;+>_^Ce0K.Fm@c1@&q`lh;IZX`XNHe_lL,
-%fgai(D2mOHce&F:mGh-RR@EFI:YAd[re.1c/$JFUT!GJ?rNT/OYmAqp16]2*M0mD1J%4gK`TR9jLsRBtmmp9\-%_;,=(;nIoqQ1m
-%4uR<!Xi.V2I\)_#3$gfMVj,$M^H:a'h3WW!ft7%E?+p8GDW-*04a?pcYl,n$iVQEhefL$'k6?.grYtUMl2N^=09^3^O;QE@:B&:"
-%Gd'>Hk-+j;L'BCu(EJ>75+n\@LQ.c":H]iT)p/'c\N^,pF<d*n;_mi<2fbi=SV$kR7)!=?F9;HK)1',sT&YfE\k`Z_D=qfFFFdU;
-%LH<%0jVpdSIHiQEhM$*>6L2*Yf'ra*QJXt0V#T]Qm/$D,mt#*>[r8Irs)!\Wo-'^&2eQK7jjb80R^d]oIZSn$S8?-=I&G;OUK-S@
-%l!KH4l$`#rBD'36Ch+drmA4/3pX4EG9E%;kQ@;5%n1X`srpAh77TT8Y1AF$rmt!Hc5Q'oU]n:;iP1R\d>!>sT_%BK<"<?/309mUd
-%c1^o_Q5B-oY?l'U*p1Z=LRjA#iu<Ft2'X/LEb%7[Iq$ff]TrI<;KQG*K/fOfaT&ubH26(HZ`Ulta,2)hT7?R@?i@$L?iKZi9<10A
-%U.g_'It)P<a$(^0J2e;6Y:om$H+j-2c[Pnr[_`"9`V3G@h7W$RI=(\<`U!Ql6iYB$r2TeC?bZF(D?#+bn<nWhU/*0)=n]8qs/5Pi
-%M7)E.s8$O9'E.%irdXjLrZD0n7GjZ3PM_r/TE"4P?;a/jp=X.s;gF[-S5*7-oO"_k>]oStH<\j_83B%N0qOKN5AR55ObK/8$fa&3
-%@O>N1k,4SASnkZ]b)sX<=e4i"6GiN!(29Fc\$pMN+8fu(eg3o%FYO+!Z'oHlI^S7*r`JcG^T>b%%?Z-Vl@7qDBqY)IW;LAu5Y,#r
-%/L>[Z1mT+P(nR#Rb/q2;2W`N)c-u;9pQ9H.q\QrT,jZO"26bFlb>VeWI9(B\IVGH.JnloTI8t%5#$`[Br0WB8-N!_IYGm*(s3/*J
-%Zfk'?<M4Mfp[l-0cU,_WI7SK^(nOGRdM-pZP:Xo8T1un)/b-buS$$>e6`?99[^G@&$B@1`T/iM[J)6\JDMh#7.eOP>RI*3R;fD]^
-%r,&'<l?F,WB=1JH"0U140_d>9""o<N4n*@+,l0]n:eC$NiWT7c4u"A&+uAO4m;;6]#qF.tY0oT$isEGW\8P]',/Se$ZA^>*YP)TJ
-%b7Lq@I$!`>V;`&%>_lD4gqGHHhI$mY7fs4Li3KZn+to?WI?iq!En'NSOQQgO%:3)@c]?:E?\jlOr`CXV(8Bp))7/alP%E\IBh/OT
-%F0T+jHq[7pdmVB+XprlEKsG^qTuE(h'Tu.-haHR:3F=?(l_4j\D%l"n/\ZAR9&IiSXnH$d*T-*ImG#$00>3okO`0LR:4@,uG?.D(
-%ZA*#69gNr:ErDg);V'LTo2R-#Y:C7:B>12d/!312@C(kDaBce9;6sP[I2BH<)lgB9VPl`1>[LiEM4.tJH;Znu^KPUU]$T']Zj0NP
-%p!/S^l#EPs]:7D8o<bH?G'WQCPZl^&&\Zl?)g?RRq?ZqgipWJF5$_$@[60XaH<.qJA`H7NXaYK[*q0-ZYIKeTF?c+7.")V$.EW!a
-%f!jt1MQ8@VR3pdb,RQDeYklil9K]X,Uos2:Ph`n:ol]Km]_3l:XS6T3ae\n#;judh8c=b7htQBV;4jc;[h\pDJ"F;83DH(G?H#73
-%-o]5smuk]XQ=:YB^H-WIas8Pj06c(P^"`5h"C6U3cZe9)rZU+_G@-ZMZ`;4JmOQe:C#U4A^/o_TqRo^KhmUtBM_"Y6o!'NM^M5R]
-%Td7+hr^,"(qT$)$rr3EbeA$+4Z1pg>?0/_\IB#UC=a!`5A9N?^A'b#f>K#]Rhj#T1jAX&=oW95$(/u`UX1A[+s+7CF(:qV/YC.M$
-%Y<$I<<"1lmI;eEcom_J-df)k%.`'r3b/@r=(HF3*EDEZuhQL+hDNU*OSitt<.>N&(dIB5lVbKr^QggWZ-9IULjBMUgV^jV"rSFS;
-%n\"K?8CPL%kVn7qIF4bN7ZVZ<D+!'8TAE8.5b7]56iYIt?-W<`R;s'O^W:/l,0X?CO_G,D?8=[,FL`)G:*KB3,__s'ZhLYr!S?3N
-%q'j%k\-LFUVlFb>F<0rQ;HIs,iXW?P.ot3sc2!<!9S@eMEsHaSNK;krn*c3K+8q:eaIV]WG>07Ec;0YU#-ncL^&!b)oErs\@a8,;
-%NZ?L&O+o02=4:C,W7?@$.qtljX/EhtK^Pp5[MJP@o&E+IcnUfp`I#0,EpnpU)IC;[_T'Y]efWEX<;?e\g*3jL8lb.<7OG`S,l1W)
-%U>f9K[rugm?d^Bep-DWmYFiI;H@\"ieM#d-^3`PT_Sf&[(Y2/10:L0U\%2mlnQZeNmsa$[O2AA5-H/tkOG0dnXo2h\MfL8lWF$`p
-%\k4'@j0b_e$eko.J!T:uA'RN?488WG\175VN0A.^9M\G_bopc8EdpJfGLB?/T'&2ag5;'A2e8O>Cp'Mt]i4%("RJiDnP*r@hGMk%
-%pfaLum5^a[-Q6AWaeA5=jKuE_?(Wg]s1<L_6$;3e$ElbqI4,M<P$Qirec)$'rPgeA\P?.S.$OR.TSl:"6"Sl5]%'tt3#erRd/6=1
-%pLG*7HSq-8ids[j?KmDgkmL+1TWca0.(d"Hf2L>tQ>Efc71m+[&m<it=)`JNQL&3nY&?JR[mQ;D]MGiBEQ.4^^e0#X;r3ppM&oE?
-%)H38GrirH[d&p&>k-ahG?stbD+NP!D(*5V;<SIu]#14L9<`brlm6B)=Pk.=JUYdKTZ$p]e+4R>Q"P+tK<gtIb]Ace$F-*mr$<XPg
-%Ac9'p'"SOcBMBbj:\DPc):$.mr@n+\qcI[\rgqX+1Nn-ZK=:(h+o%VW6$@.68sFJVN@H9cS+nb5AV,K`mrgl8Hp26^T7=:"k0s6;
-%8)-%2o2/6&(`ZlpWX%i9<N=n1oSu(9$VPUBZ;[4).=HPsRe2bQ`BtOqH."46GI?(JFRJ5\mG_Bt!St10N,fcHORG7C3ZQqhD+fAu
-%7GQCem7M`arS8PFNt1f[2XqK)@AGtaB!sXfq;1@;Ib1l_DN7]lWU.N#j/=V=<tXQ^me9%ED5/U(GZ2\ZMSA;`rR'SLl+K]jdncRb
-%JJ;Y#)nkt#K@%)'&M9k1QC3(]"k$k\SoHr\>o7:Ri\W^boe8gTW8pP%QERiu^WWJ2^%,BUVhhSWI:R2Gf!,1/r&on7U>f/)-7<4\
-%PBg8PHlrfNFjD[5?;F)VG=\\/V5b(??(G+FJ1a7CnTgiF^5B5TkTKHbpUdp'HW<#9$Gh.eG:%Sg05X7cj1@q<-\XL6(PPX'TGJd8
-%Zej"GT?k@q-!Kco</u"a1Mn-rLgB5;Ed#F$pQd?I;AVZAgd(S=9tIQ9ao/\EA?andoHLAYP%=sra;d8a\laA/Zs::39n[gg:EaoK
-%Njg`W-IdS4U'Y&4W%UJU'@Ca_a!/84Hm-qfF^\W/;I&:?ENgRsH.(Rq?8,0A"n)Ljk"/pB$aF0eGB(db*p]<%n6:NWs/+'+I8ib&
-%@teLZ$?CXJR`o5SPLnVRM9i8b+e>>:X>R^8b2V]U7'RQ%O-9piZ=>'6a>,H^$FI<'aP-:@[GQg<2aV[ZO1dXjZt1#e\0t^g\B/\]
-%(i!$hg#[fIWj.VKKV=l<HGuh06H"-9!li3r\Uce9&E[Hj/PdD]+KF1u+-n;n;n_5>8=Ak-5$6D!T<$[K`5M,^Xf6Ws47a^6,/(H[
-%[(aQZ4l44kH;*B)jqC?FTfdl'qaksDQFW+SgaDH6[J<5Gm3c0m(9;Jl^.A,!+E%n);f^7@a`#UKGZdGRKm6s,9dk<@$ZiTX9''9C
-%[V)%:p@cf'546%u<LCJ6n._$_S%QI7rQcg1=*65K>k46&@I?$6q251F)0@UiEW(sj.$;s>S_"P#\tBB\bR@SF9d+Mt:!\SF@KLbI
-%)HFKLk[_BK73Tfms(?N'SZ=]DGeUfd\BW)jnD3_BjC%&d"]';62\2s(_\:lKni!GAM)9.kCI>G-j!)/sB&/2`I\3ZuRhIF.i1"KW
-%Ung(RA7/8OfR>,-2sH;+FYj8);7Yfjg1@P4&GNYagPt$jlGl?3I=A\_f^'@AB;(qI?CV.r+87^OqkUuMH6L[hP+BC.";9<s=-?A5
-%1OUhL$%Ps07o?L&;7_i09hEbl`/1t7cOKo-*(G8$cZRB@DS&`(o00S<hH%hLa1co2=1R$26+]m.RbiGSK3RSO%3G41Q=he-@dmXY
-%:XGoYR6I%Hf&eJP/ihWaH6EK4TOE1*-U1(hT%NE.5K*ZC"/&.OKJ@dX7s'ID0P9Lu@YP=pPPUQs33P)jrpQ5+ITqr4i`o9H\A252
-%&lYQ%gr_tlcmp<(h)21T+dh!:f-Q8/8kP_e@T(YT&IDs5,G#6)cfF_SqHD;oaDBP7h^"*JRFEb\4k%'>8T*3Hr]!sq6>dp-"2^=o
-%Du7\'fs05CqRqIB/"Rh<4eJdA/'-2`:PBW>Np[kC7HEKKigY""aGW+9(YO!Q?2R"bU5S=cLd0)1b!\,^]GH!Fhbcn(4==IJ.E_k"
-%p;og#!_n)YW\p0fG=n!l+Ps-t^eWnS?J(VpKVph(EOu$aNO%HK<P@q9`%&,!!Dc/r?*oOg1H:<h)Tm?l0.e.NUlEPZ#U(6PY9q`r
-%m?D0_Zr+nfAjAK/UdObD;HHF)#:G@6''m)X5RoNsok9AdY(jNm8-/($i$9npAdX#B[j=2X-)b/6SbPDn>_uu07-Rl^HM3n$"3qm#
-%<Sg7YHF_,=-kcb>374m2$YRABFY`fq.B"Ok]EE;tii$Z#G$u&,@Nnl_(@PKDkF+4];,g3-`D&q=m;8hV#`C`)4I`IoFY<MG/IoKH
-%6%1@GEPHLo)Bu%ZV]^E4&dWcc%HnHui`N3=ct?OojYasqq;r#6CbU0EOqYuI]eHA:D/P^5gJl*:Vesf5@miXOi7Pn=<Q2*04h_X(
-%$R17K1>GA4P+o53MT+g]hj"P,Y!^efA(EAR:k8"-%Iqg5l8'N$M<_=d:G+u^QITls:lN"?W\k^:Y2o2j^<R%N9U"io2OaVC?\?J"
-%Q-ZqDN(O/-eGWS$`CeD?k,)u`&O6su][-5P7-\HYc-,6EoUa^dWZ2m&C$b<<#pq-8UH5@0ajW7E'H#*kk-KD&%W0)57B1m]@a$-E
-%hBrS?)lI5(@M`Lkdc1tR8n$Z>+GQ_k`HmR>eW4I(`bpC-M5aoCEBWWt84/Z0!'Sl(PtJ>o]j0p"2E3NYlCW;3a?*^2V'D[%LZoQD
-%KcaT8+@PH[Q,Sslm!5A.OndJp4mKdDl-=$$X6m'L2@34%%+%;a9fBi;`(Egn[[Sn%?F&W=n23mAD*'@%nhWfh'ceclbu(!'I5@e"
-%B@(p$Y9qhri8\cs#g$@*:6rWGqn%sN9.sp0;ET[K%Z2NqWd1bZ.bCV3`R-P2_Yu<'eo"ZAmtl^G!9WC2U,G9r**'((6kU7D1dmC?
-%Yi!1K5Y<)!Aq(??Ug$sOs$!($;QG*r]U5sG43RVa@M[,T#:RLNm+9u=O<p)j=G(Dr](;t(@EtS3n+S[m?5M=EMDWN]4\?,]qL&eZ
-%;*6)8@PaZ8HOVZRB`Xc02fo,Nl`bjAog/9L:+Tko3go([*Llo3.:OdqBqN@^J&#oomN6ac;aeNXp5':1Br,d9qH:,gW4ffhNH?2m
-%5sJ$'O?JAW6LF[(`KPNk)IaMiOd\DrUpMG/8.@_%cdbUM`?dm,8FJYWi?Rg'1MLN_I'ReQ&B)@Si0Am2cslHhH-fhQY<fDECjudP
-%./WJ*rVL4lqsp)g\p\W)ch=[us763as7MFkqu8\tTq/@]*tH4N8J;=OStpF_!6d-SLI'/Fl[qH7dcEi(Aj?1`li'*_9BYa06^Vt4
-%%K\@nBat-&8J;?E`iO^r!QX9eK:l`L_#qJ_Z8ea,5SKIF+@m/)E>YV\h)bUmAkbB.MM<H!#"Ff[%t^RMM$!`l[^c2W.:(`H?rGdu
-%5sQm``'MI$C#Yi=2#6tjFIFc)+o&Ei?$:`o=#M3,5bDRe%KSdc$O>V>Uk(mpC=9sdZ"ik&!GF?l``)DBZD%hI*4b2Z$-B.uE]*ka
-%/bT_7Okb0As2X-b\X?i4\+sgYYjD>HF7%H2jkDj`ZH5<NKOs0j%R[Qo'Dm#4OWT6iP9pdTZsi6kNbXan%`5Vn'8Iac\;>jBD;<!:
-%kVbG8#N=EViu`ejP<8[RN19(;:Ihs`9(@"nRlu3r7_7Ofho!%I59,?"PO3Arh@1FlabVm&arZ4]PFjo:onH%"!;@g5H4]XA2V(1H
-%2qXN'T\m\.4:(s69fs*j#?19q$lh3G(^a$,3!]a:"$$Vn#KqT-$b-!DO%7+(=?ccr-_34&&LU9mJr,[o4pVlNCOHaHNgi!:)95Gk
-%KT5"-%RJ-,!sdfF\;A*7Emhll(ccKn0U/(Ya$D[FfiJD%jeR`g@ccZ%4:j*"V@UJc@=SS*k+mid0QVDm4<6;7S*\8,\``Zi++Tl6
-%3r<IS*8IFsT]beq*.XY;DpZrFFD.CJM.)R^h\h0O8Y<][YH)iQr'PtoS,S&SO9CB'aeU88aS)9Ld)lk#f0Kd,!+#mHaoMK(d>&6`
-%fKl:h"50)Zn8t$<2_bBfM4sf3W1C<d:p?L<rD:"pI!l"QDP"WK5jm^^6U5kbUE'?H1\9_m^cS(F"/'itJPQO.a^cFq^Vg%5!.ZG'
-%T7\82E6]I(_@u[o5qoql#O)MQ-i\,s*"Oc`!s!Vp`$(4)]VSC/jWQfA"QnYb%Y3\uc#F:S:RX6GSgQ*0"ON>Z%YEo$Z@3?U%o"#D
-%duu*g!pX2u*!"NqD7:&-KD;Er4W30DO?I=;&C@#UE!U:+B'5#d^%l%H^jGV_LVWY[KnBAQ@fIJPi=da>+:t/%E<(qnB&We5+-+g6
-%TmUh%4;l@u]ljCG:RX6KcmMO-!9o[O%Kc=V>Our=+(jL4@%X"G&\&@HHoenNYK5/nIcaRS3lDQ#SHD-+n>[N0o95RhSDSGZo7&aq
-%bQ%#1ooCW-5Gs`j6m$Vn:41K.Y@!m6roWS%Mj#Y<JGhq:lLY!>rVuo@s4@8eJ*[,Zp?'W=mI_RX^3OjHIIZ']gFp:S4o>6<G4E9E
-%\C'%;1#7A[manZ!?C^r]k4[PJDXNV:.>J=QegW3,UF>F(]u64I.t.<DKdJf18KC#H0)YpCaL=0mE`pJQ/2%62+(@m,0M]]j+u.,F
-%8^)`g&UFr:Og'WK6c.b!5=&qA$jSVN,KJ+,:?2LD_C-32J(lW9W^73bc<j0GR<6t/io"qbI;?A-(I,>YjAqmgL0fg=4-kfJC>DlJ
-%T_ieG<bd+S`&gRXQU*<'1_eUBUPLGcPXCqfdHa%a0:Lfs8.IY8#(hNd=^6$f[rR7eOAT3XV4`W,4k_$FTQUJ]e&<WU,a/&9#6!+3
-%Yo!5(jZ2f5%BB-rnfj8S2mH-"V^nf=TX3jZI:8S-NM%uN5e]*<O!#QIkV_EoaIf2_.Fnre9OoV<\ETT[&]CD/Whu^#MAZYLjOfL2
-%&@r(?+M`a,11>@QXZfnFCK`7cAOP23Qg!"O9_BSBE`>p;Frk`X<A6^jq$K0d<Gju47LLG2J\=m\o[87$N2$]<-M&.YWWX,T$J\jq
-%7:r7^b-g>V"ZjMZ46!K0)N\]F9\'1m+VNk0Lg%\-=CDsC]88UKKp@9-?-#j*;g-l8l7a/hPAu'a+E:jT#CS,V6t8l@Dr<8/0^,Yn
-%AIu.D%*1MdUP"nZ;A5]0Z<;n7KJP2VOX8BZ-Manj-s%HBRkl84Wf0X2bsm;n?n,;QG0;BNZhoj'PKkAo,_ka*<ne>nbIXR,QVW&R
-%<acC0Xb-HZhD=D#.fF*9m0WG!oZ*E=fVPp-D>?!%ST7ufdiqc8?^hIQa=pror6Rp#^dXur.GZ$O^XZ?A[+I/Ylm>E_gIOslT:ig5
-%hNXC)GD4#F71UYU_V:hh?aDZUW\p4JUr?Qhder:E2MkOoE,%r`<P0G3eKgqm`FnsN;]_L1H4mOY`<f1LW)^cfS*2=KPJ:ErWu$bQ
-%TNlg-3!K=VI!cB!mZ!Bb>c`N*NtP_YjbU\CE]l6VBhg\Jc^o6-HD[bmqQ,agM&VfnE[%]B9+2df"h%,Z%(`%!jcrK[9,;Gu=0[r0
-%7!bS\1Dq#iAI.u)FW0k<*#J2C#8O9O'A2r:MUtfD7Ng<r=-Pp>T&oF)AKXCRI3K@RW<ZIe4Zr)?+[!dBqa$NR^j@b-aQ`(B^k*0D
-%-[(XYSqE\-c]q-moMH:j$@0=.Kl0X!l8hZT,XoImgJh.SNe,#ddtI3!#q&#g9c?/[DJ=1ma#Gq%Bs\KiS#Vk7dQkoO;b8tBN]@AS
-%W"YoP<W#rK<KUBq.J7RQ=^?0tj_>6\<kod0Uip,W-&I&/HG_ATe^XLe"&:D*q9GXi&U:B_%Y)t'lMCj;L?PmO$LjhNWUPF'0ci&]
-%kp8b>C2h`V+\<qu4Y=Hf)JUCg02^PIZ!k#R$+PT+M@q<'KmG]2fdIj`2,BajoSd?moMeaV]lB"d3gFs$?961Z85BhOTQ^?''._+h
-%N8(6/"GQ,<a?(jIK@YJaFbRed>9pK3=BOc7I&h]9dOD)o(9a3,];4<CM@1><jN,$\l4tl_G9W_a[>e!X_:rYbOs4md&IktT+O2lf
-%m*KkIN@Um^"<oHok$q7*9qD6mm"f*!\jS\<rJiX;PTq/MDuN'se-l=NE`MKn<eNmi#s'=go!bGT^sbY1!:Nn,WBTT&E*d%Hm&`Sq
-%TNoPbQ;M@LP!C!Qd:!196+D06$lSP?<QR`\#'6RZI4>lRMt/]^OOGIW3%)"p!\_j(6@*I:o\7*8f_0LjBU,.=)^QXN@m[tsn,#qQ
-%a\;0-4:.Oj_Y4Q;n)WW+`!Ns]EgCoM35><Rl6'u[l8@qr9Lp>sG]]Wp]SMt\eN*a5e$1WjF0p.G5]IF5bRq[RM;0'c58:rM3&UJN
-%1S+=MoRSFSjSe$!:BdZ3"ss'GC@U4\mOrO!l?$Q,YiqC!%VZ_-esLP`KbOcK8j[#&1Q`oE)ZQ[5m0\He/chZ8.1.72f`FpE7eW4]
-%lbMJ\U#Iq=59^%rN*hTK)r2^1l);F7f#1,srZ>WgXt*/N.uA^@rkjjOYRY+`jE8ku<r2ku:8!kR-$B=^pFf+,O[dZ%[9KY2[QPKL
-%*^7q2(thuK^c:BBlH=Q%3+EjG$s!9a@m,;=b;2lP:@)s`9AKHhTm9/8^_X*/&E(S]@Xp?@O\F^;oGNS#nFD;$e'5%7':$8[JqJK$
-%37\Gf51j)/Z,iq$nFE,s2^LEi/e2cG0,SCNAcU[tAlo&PSB2PUYG9oQ["C2sHN_/HC]Q6HG)FAg(Uunk@"@h\:P-R[q_>rA8(E%5
-%5^,m,LiE:j[HT6<@Bn;p:M\b1,92`lrMI2=h]ai@bJPO$F2BtWocT2.7r1'nT:qVhk\>`'NX\?`s*jc,@Ri7\#hYiV>$D41$[B2e
-%+><p-mWKeXa`;L)IN$mQ,9$I`cJ]SFA0G4M/I)*tm#mQ+__sp'_;H29oQT"MCk$MIjHobl4a\]1aQt_h!=J:>"MS^7YE+lWM`@jm
-%GH]nD'sfo@OnX16A#Vst6:?.1j*mDa;A%)[?hB:M,+[gQ91&fM)!er?kr1<X-LP=8;Ql?eCp7Mh6?)90aViKU5OVjP\.9F]/0s_>
-%::&aRJef?:1.lXScL,iYRodOXLT/h>-.Xf9:g2(^d4a>*6$LSBEgo5EYn9C2F&E&+&Q'Ft*^k%:3s6@N2'N5+h!PG`hBI`?!nR68
-%(,-p_?b01Sa8)jT"&cnh4Et":"O`^9+sZ["Bntr+?Z.8qRV?L,J3St@5p">\ouRB=B7qP?EGS(4dL3_NYW!SE!1Ns8HY29os0D9:
-%$UHI0aU<mV;P))V@DtW>BDhe&]HIlGf=!mEcb9u0bgZ4_MYHj4<<@e]0+Wbe!YSbU?;Mc0c.=n%Dd2.??16]FXoKE6aQ3UeFt/!U
-%7DOA':V?%N!L1$a!.DhbJt1-YUa:%\B4::R"`g"iJ]G2?Qkj)>&JCl>`96m'"\K:4FIN]Bfuk:P-9\RRH9VY6Q8H1G>JC..b41qS
-%\%n\i^:lO<er<n#7<U>J8f`8/ajJ/%NU6!4$Xo#Yo+KuND+s?drlq=uc0*E??Uo>GE&XB+DL:_X9oQuQi9.ts%o=inUeYYGqY#/.
-%h>l,Z6VY$gh<4/\&-4tDlb12RJ&fFhrA;BZ%*m30"l6rl+'cjkl)@nq.QPKiR"').A7[n/!O^i$\&L*">NI.q5oKkSp\8s#?c&Ae
-%K^KVpG)MRCqpF0XC]+:dO4!Y5bpO@rPO_Xc9-hR*<l75-]5$->jDB*qf9N2M5X2CG@N5OG5Pf$FnhM`ti$da7Ekk^*_$7nZbWt'O
-%rdJr$9-j-%*l*9!"rK/;^GLg*Hcn?Pb#)ukTKA,,]Lfe%2f2&OqK9L[Ql3Q8h+I!_R8qICGi)nB07-L3ICuH$K91YP_AgJaigWX[
-%-W+aJn;Jb\kn_*DiUjQ\A0&T=&EG?hD#7)p`ua:l36B;5p'/RB^\rPeX;MdWSU<]7l5j%,IV/'pVeCk;oq6/B\_eNe"ShrBQ7&5)
-%ZEhZs,P0M\W'sjU;jD<OUBY`ui$K?X97PT4^jVs=VSQ#D1\O)LlDoQpI0iehS(&I;bk2)fT]#1=K)W>dn!noYqt(!cf440"Zn3uP
-%[_O-)g7Q9i4sDPeG:`]5AHbftHg!'Bre"0&(/pOnIG>d=,=@?;!\%.51f`sZO1pW_IoHG+6.(kEUYs`G)7P5K_bMkZ9&6N4N4(TU
-%Nm(r^E/pSq"YK(R>K;A:g;4l_=5t4m)dSA;'m5VuPI*a*niZAVpk[Jk$D6%YT;]&^=@P@G2XX:OPNFdi>B]r"N;26]*ZG,df0NJ!
-%:T2ILW&WefUtE"5b+LYTj)CR+(5H:J$m9u3[RM=JJCU514hs?*@"`fo8oWVqrk6YN&8a"Js-iIq%T'Q(g6Q%q+>bcqJBn;p#N43n
-%fqV9=$sp$Db=#j,Jb-UNV-B!0\)7pf[gfuO$s/"$Q*$/L>@s$]F`=oFK!->f74JJfi?f)),":N>E9KU(dK;\7JV.koAk,T7gB!W=
-%l;OtID+(X=\BLW7;=4^9&,pljbFtm;["Ig#>Dor!/<DO>5^D%GlMBjcTaX5MMZfs)=1`G%NT'gsn$KkG(-,S2d4)-s`bZl#!4."V
-%PF(#pmD]oaoWGEXL=PTtDLcYYc'2gf((n^$>G*>ZT>?H7"uL,XC\nG`XX.$(AC!LZ"gG4B.LMrC3E*dP#,C(3\KN]!^.*?71F.:X
-%6U:/<7L"p/adPNQred>oTOTeQ..3.3EG)FW+)0XbRk);%'YDbB@c2FMgM[Zl&E(-;],5dbNtHR4j[Zq$J3j!o/R<nGApVsl)NHEC
-%oCO_2ks5D7S<^9C\ZcZqH-d,>MUe/C0S4R?TPdkq&+J0s*2$r;r!^.p&-<D]k4$%@aU8g9%16t]g?o$NFP#GZ;;5j)\^:2Wd#2K/
-%d^V>D#JptnU)n>f'%cV7"IoC+a<S;l5*)NTL-=#PfOk=tfh>b^9r;2u?PU<$9L0).j8cd[VEbL`fTsPRReX):El[_tkd+kc)(WHD
-%8\&MaL)8tEccDJ4$U!FNRg&e!6Er]3pfBEIX8/>ON]$iaN%!LFc2*JQULAH))narVG+o)$:d4b(R/\&[,iE)0LR4P##Vq^hVF0"X
-%kpUd?7ehYW90i"h.(EeJhqti4,6fa8@m:['!'3$(bgEj:*I\mr8dMprW\"BR>9pk^?XsI%f\c0V>iBhT[KV94BE\9qTt:A$%#^4S
-%oD[A"7G/mLYrP,6pZnJ47cuef(g"Yt=b?6m<jdhk..\Gem\-$tK9fdP0C*L)%l4j5pQGVh]C?<>+2aV5'DI]=MY'+Y2W)`+?'ZcS
-%SK`?&2`eVY&b51X?6b0[P;.ZJ@bgD0A13OGU]'\)Du9T^7MO=:P`YtR+q!9h\=MuhK#HSf;41oJ'#D$rmM4'04ZG:HK0=Jg)gF&f
-%=@%j8aWBBbKIa)-nN;GKV@E9F#0Z5:IiMBcK&X`?O2H<YP[B4HQ^1]hjNg?nk_)G["Vc2N?s>\<&EJ=0aE*hm7Lk1>e!cnp*+Q6t
-%cc6=/INsd0][LlM5YpQf@c:;?mu2CQ$bBd=r_;@W*B"GF*Ln@M\S[5Ddr7)OTlqp/W<aCffk`m*G4;g4EYEE4V,P2V3%]Hc!)`g*
-%`G8&b//\Kl09'?g?M1uo\`_cFWj2IrOR6j"PBi<&a)oO-#n!R8<'eGo)7Ui0$QoU@c@Ea@p:=Tg>c8Ei(6g'/K1.=AIBWm%2!YEb
-%a9*!Q)ZRI@EDd!Z&m_F>g3Kr.",N1g$AaL\K,9G\p5O)S&02k">X8tkC?p>-mdOd\k<cMfM'iEWl13XTeB#GH@Wpb4WB6H;[s2J?
-%`<KVgRlXX>06hjt=:NmC&<jOV$Um]$JAJ"N0&r?P@i2)eAUMD/S45=;O)@Pu!SbB`ArLkfF/61ilMK[G-:%cGT\%Ma_g+CZ2+C..
-%2C#_<bkm]''1"D<1l,S.&/K0Q#0#-`9c$8&'=<GZM_*<uO66RJ>;lrg!Y"d>)MS<`iTsc):hMZbST$<"6+0=pe^dGc+nl%2L:DOn
-%\AETB@I8@"Kd-lGma',?It?c@WHTu1f/HspqX),5'MpJ731!Q=:#/M$q+;5YTV9V9!,O6ZHQ[rSj>lu3OJa>M^^(u%5Ro!REGX+i
-%CP0.aiLrrSn])c)0+UT]<_OeO=m3`6>]3u9Y@,0nBD%p*\?HC#Utc"3HO]S4T.s')neK:LAROS`PlJ_/_m\SX>Nd`5a95/:WMG)*
-%cQAQY/l9>j&dm9!?_J^3CK\LGb=Eg[?hY;lSi]>W"op(p;MR,2kI$d%NN?@l#.h4P)um;tp8q]57A]BYpTh6n&VN0966e<<c2?@B
-%OmuEUH#9%*F5:;639SRkN/YKGpU52ge/j[G@m!Vc?p<)BhjHWnq&I1#ZGcU%&hN/1nKpNH[#Y5`FXS:Kk*]jcY`N\f(0aORDN=k[
-%Zp'/s_b'Y+"L[MX=8=7)XY#%cN$ue_g[t`Y4Nd?RPnU#t(3W)@k?j8^hI)^d@&cm(,3nOl9gEGk57%$-6LA8>>Cd`lQUMM@j%t%g
-%5@Y&K(-LG\H7]c;Z#1YMq>QFQ0l^!^k4thl]s1=_f)%U&O(JT$a1IY][W@V@2UFgM.:CO&^P9qLIIHdS/V(LDIr&=4M''Ql^Ae[)
-%HfGB89I$YJT;!D8j/&Vj>.>siUTO9g]_)s9CUcak?M;q;RrX.f`.FX0CNmk2Yf[tADt:OnI^T&*/sa.?'E6XmY-ne@CN/DJl]q9U
-%<9\`4.]55..XGgT3U]p^)8aO^Rr6?YCn.&BBK7kYaZ;jOa#j(1#?-9m6gCc`gL]tWL,J/lPq5BRL6FD1'&3/dACq>ga9<W*HYMtu
-%*q*sp:6Z-Vi+OM7BP?,E$hB$(qiWb$W%k#OUS[:!-siYhJ[RJ>:3X[<-Fa,@hl\MI0EQ9;<Z&.[p>0;KhrCAb%Aql75=S]bOk:i8
-%A(:4mq!QJ%i1GYA5=V">&;a`Um12*n&V)ncAMSbP&rn6uf3b?02d,_UZb>,l%=AP\J&7]E+n4?/(J[BiD\kb<NFhj=9>lmD-bL.s
-%]AW[lm_E7g]R_3*p/Lb,p7Y:D$27#E+n)kI*hX!&15!T,R@nuS"EO\6Rlc0I+'m>Y4=j,9./9*i5UY.'jFr#*g1'a)PS4E,1O?lP
-%]Yq/,_"+UmJ-OKroJ+bQh)Rt+*tgPF6qHXQ4_LWnd:X9tQquVpN`K3A?M['q+p.(i9FE4OTJ,r)<e\;Whc(SkT_>Id9OI/K=%us.
-%-eQp`h0]Z,ht65:@be<jomE+0T<_aOaG`.###,nTJ4S*%DpN\SUCFYkkeZR5N3k*T!Z?Pq,^?:I42Lk*g=>XEJFH(.J"s+fRgsAk
-%::]II^Hn5q8,U)26eq6Img=UnEJVZ7Jb2YoE6]DRkoRYW/oE)H8ajRjD/)gb,8-dP:Le2;^U1s_&`C5g3n[.%Y:i\ao!m=q!h$'s
-%Of$f'7)/^MSVmR7$u@'4_"[VX#^^g`,.hAK(l.+(LkkglGe60@_qhCI%@&SO;/6Xf_0fdK/\)F@Sro[R]"j8np2)(fg_!%nhrr=R
-%i5Ta\j;FA*Al]d7BJ(H9L8Dmg4=AYT:]XOD9LFkghWEd3Y`n7)J-]m-5X#P5pX"P^@GI1(\&;""XL9-;+sLCQ9E?EO.I`"Bh#n8t
-%!L_"-'!Tn+\X?erO1tu1gU2#1n#5C8Df@DVQ?puE)n(sHJhoFm<\nd0P2&Wl@R$7-fkgi%D,N[L)mgYOPA8gW,u[.2DICsg9CVg5
-%_FZ#AYmeVW$E'ma?_Z*UZB*Z>p1pquNrSC8b+.PL;],U72,F.A*3*)3A&b7dENPi+kOU%0jCW+u$Ui47`0F]11Xkd76!8/-AJ9E<
-%XR<DEpW0"F607bZ`im%K2QrEh"BQ;U9TW2'0<jUOi7[aB2e5C9$H:7B3j@$gjI9%I5iFSbonY`L2f<tD&3[u'2sOmBO*5@Zg+n(>
-%QN/2B!8?Xll>;CG:ld^Z0RC*=GoIX8SOKhRGias^T^ufTTO03jrhB::dVbH^Ag49bEis>VN$-495Jg1Wgs0-#:>a[MKB+.!pk/VY
-%_Ka/U6ig,4?XWS8#IRLE63u6&P%bHU[WI[:&W(e\qtBboKJ/G%1oUPB<!Ok&n5311P8EFF_:5D#4R_eE#H9o#7c=qtHUdR99Irs*
-%!XAb)>\<gO>a>l*gm6[t\q!GD@LYe-P%Vbse@pOs<Ht&#Cqo1E0c9!!=7or;?>C7bE3S)Lp_=*>^stW/pRO$:"i<gLBgd]V1fG.&
-%PuT.U=[5\K(nN^JpRQDZZq!!8;$%4!(SH9b_%n5&KpsOT,ca6[7VYY)K'fAcFUF([,jq_rS2KG$UTqnZMq4h)c6P)4F@J[7N*o)_
-%]Um=!RYl^%*B_t1rB;oAIW0GfjTef5#lbh27#Y&#TohCl"'0[l6DW9nIdXVGqLrHQEXL=GqeF`Y+Zd&>HMU#_STED3=&pojpU=#5
-%B!`(H0A<X8a#*pg3(,;OC-iAC]DhTj&RF.>#rC(G&'a[*h_U7=EXAu(_\_@K:+8`(TUUJG+![:E6knFl*e2MC3OTWKX#rMnMKDL"
-%C=j0BZt,E^-fa>=b3r)*bc"*0AA]mj/5ZDEmUokqjM5W\GInEjVL`^o$d#Tm."_38HY#7MI;&E<)`[#^1?NVqNu$]BdA9?18-t0d
-%[nuCFaaTHAWb/YY_]r,<A#>fTh%)g[pUl^/j<1)AI\o?].Z)1mcF*b*,G2sX$7In"FdIU_Jnht:)QYbtm+5]&Z\lH>(dMl%B+`gt
-%[M!*'K$c00/QPQ(7^qAI[R+R33F9n8ihS5`^eKHF(D2FF/+#c3aum+%[\No3Ke;_Z_b8_N(4'eUCt9!+G&S\t+2RD9^hXjor,KIO
-%Hh<ZY_@/i7QEjX2a,Q:WO"Y>A`n*6Wd'h&3]9<Ya+9d#6G].qZ8ot&IAS_G+*kWaFh72WC`:%@:]JKC(@JI`6LnQh]l`9BM!P[ui
-%b95a1;<'1JXP$1eUL8M(-D3P5RcqEF>4DPk%Y;nDJDZD"c<$CT-EU2/N:<-@I@[iA5_7U@M8^V6+ANdb%KV'l_:]&.+lIgWhEE(_
-%f.QHX[Zul<D;8XQ.0-1l]Ja?N3].s*k?_0[Vj/AmloB5"mKj&TJDYlp./el#E*eG#<&UBk^iBT8R'p#rA[ed3!?>I?[4MVNDQI4p
-%)L(=qRt(Q]CVRulVe:X2Z$Z_G#K<Je'3%jKF>C>6S=mFMGL/P`-YPXogJ3pN+Pl$FOtk=?P[gA'lZgo&3-h35UI?E;Hik5%s*F>%
-%WD`P+dig%)eD,HsR.HK*#JieeW1sqIIpXn;;ZY'cAd'rp,m/PS*;5i:A(u4jRt.Nq2E6&ai"djeqC$mD"?`u!Cg/$An1Rdnko"7+
-%03pu2YuEeao<T>Ef39juBgX_Zs7'd6'B'P!D8(RM20lpX9heVR2q\.iLTTOf;cPcA4L*pn4jCUr&t8A>ApC@>Pl,0,0^FQfb*7hI
-%@taGgYjtgclZLgEG:0PB6J"D20uLi`e`Y927P@(qiA,<a4l`;QqU(B8VkRO9pfiYId^_%*&(Css!>_-7_f!.U'hYZm*DU"Q]fI2*
-%%Kj,rF2&gqAq^eO&`f3XY$4F5T`>3R*G'cr$"UM1:]:6**Ku6r"`a#Pp/b@+-1V79!=36]*!0dpqZ6=DGiC(8ThjK`IARn'be!+'
-%J1r_,$rl_=dLHGX3Ah&68V4GZMfOFddND^5%-t&j=mZejgLa/\G[HO+T*kp25_9\hD2a7\Nf+%ri)/hBpo%e!efM&i>SE3,fteeR
-%1^1=r"N?t7i-HA301e6m$t1"u/&+W$0Lb1N%;?!p%O?d!n`o2VRd^6INgp6V"\MaUZ"ZtVYRk,K"JBB%%g?@\0R#&0-;6<feHp^a
-%SV0@M[RjR2`V"@-_kCakmRPGkqK%2+@\%:1nsj6M1_]:G2EhH%P.%T;[[1kL8HOg#>#/Ur^;Sq];m.7NOfh$ZR\.A.;#;.Y<!OqB
-%XL7\:ZVeNY[e1!8/J9&3;"7#>),$eAfQo6L1T%R6'hWh7B8\bUD?f)W36*/D>I+/Fkl*"(TK4EPLr2dfeA18`,]IXpo)!IkeNq9)
-%R9%(SpC5`Nl4psuJ+l=ZX(o>FiZH'N!$'o0_,hZ<9EN:!JBO3>9C%5#A9)Jg*!S])o?nV=-l+V='-8CoY09]_q4saL+V6+1[@)WU
-%R0AtW9'n2(nZH3sK.<066]$U1:nn(2]Ygcs>&"6+23mr!Vc$fU:qZjsS.&okf-dDb3d&7I_tcIZZ[qk.W85o:ppVclQX=qd(L6AC
-%H8Uko+2GH+!?A:4X_lm1(lHgHqVCPlH_;/g(3O:kij'-NP24aJ]EP-c5R1.P)8s1El6'[LoNm`J:>T"'"2n(%'h6q5BW4Rg]9Tgi
-%LTt^^(*<^A?\.k1o!&$!H<[D+V"(Dnc:aCR$igo:,@o!#Y*Z(M6Ytk%P.#\V#`i&n;E\QI+t@5AkmG\FS.U9=0*GR(V4-!g-2O)N
-%2K1d>H[Wk_bN=.>XffEoUX<i'NE7!S<gW1qT#Bf%KFa<"W=+kM3(oZS*n%WEM(c2WX:"bV&0>")37V!,gC%QBDpaY'j]XJd#l+&s
-%Ih\%%fMje60"C+o1'jk_WmnTfrR`h:5S1j+f40JpWli5><Si@MCN.g^>G#b*q\6"5h@YK(C9$hFhZWlUkbHKc<hN6m^Y[["+f"^2
-%5Ro$S;$RmRGR[AAEV[2m_4SUK\ekQ\MPDbGVcl.2m=2UdE4=bOU-^.5ruJPi-GWNm,/:169^#J'D\icClb6YNIM[2W)$l$nr"H<$
-%6jjap8:GU-O9jT2ELsOZ#DK/01lrZ`0W?lIP#_5Nba2ErS-G.BJ9/V`?2.qU2'T@AIKCg&@[",K8S0_86%%,C0hGB=!gHnn="A_#
-%B#[.d((I'^<mhi7P%uE:R!]OYD:N?qY_0lC$hoao*paL12Y_3D.B.QL?6)OUZUUd&C1RM]MZ6aU*oI8"C2?U:AC]E1$4RcL3K'"6
-%7@15D$#A,/0VV%ajlHu]@q]*%;T/[e_"<"hg4^en(k^U+^OaVI&Eg09@7bd`*lY_?ql<j=9u%?@0eVu])gL=/at"n1QS;hs/8_/f
-%TOp-MOqQ;=#Y#?--lLLg?<.&L+/E5AN&^<s.@aa26'9=.'62kIlqu<"pn*$9.nQQDW$IYZ(.B$]G%jS`%Na`oAC_e]pn,%PVVE8"
-%iT'6):6)]`:G.9%Zu0_D(9Lg&UBi9OTO7q;Lg9a8G1"%EGu+W_9n9\FL])OXXg8PG)B.g:a]J(6G;sf8H<<54ohfDu/qC<[Z:G/S
-%,#eARc>MaKWrO!;.2jKiFL/'n8,:p+:q9\b-jA+t<k`>%rcGc\Ej=BW-10VRm^:Z]8boAjGQfT<'8p;aEDs5h\2',C7;L(?3.R-m
-%HY(QWZrN4^Esq29kW"f^.@c0gK"PDKW=H5CeZirf"'G"<VfpJ_[2pI);Cj;?jRUG54]"*UlP*$(_Q"Sl$;pjdkh<Ikcp7Bf>I)[Q
-%D%"Q]:BfRSo_fUgQ>JET;Chr>:=r/4cEM[R':-!?jf?0dH)C^Ke,.Zq+4U^^$W2&kf1*5)[5P']?:BUI.D)QlBl^DcFHbVV@r+e.
-%X(Zf'+LOP9b>^"N0rH2$KB3CO`>3nh$7Im%kt3b7'HL&QeSeB$pc0W6L*Qhe>I7:_focCDVN[s01ibFWI'?%&W,7`45Rbt-C+p"1
-%[=rel029J&#H!#*WJ?"uFXp+sYSI'9-K0V3(mO\_KU2F@ILcqn"mk^n(6P4["o&nfOr9t+*C>!P5*Q7Pidu+t+N`RQ^h;dc0__8l
-%Zo'_F#QdFI9Mk[6)TZ!q-(#\t2ab93YUG`W<X9Wgs62QArq05e`COWQH<1$[`j,uQ,Snk4rcsPS/1k+lQ#l\KJ[R*'QX1aeP\^3'
-%07QVC\n57k@2W/?Oc@@qdcPsF5h(6)"Mc@b!ceD.<%#44$<Kij3S,%3ZJ+hXIcY9,a5_km(XPF;,6Wc8ZF;EIF>"*)n@q!g#e-@-
-%"k:?S0q?Q[+7LJEOc_68)Yo<l\HS/rYUFFC"3.XgOsGWq/O@=m%?+s4$8t_0NsS;Fff(U%S"#:-/bVR_"B6<_Rg.R^kmuF_%!nVj
-%0j\pg+EH:`(%$j)+r4:U1DCb!i^4C\<Cjcg\66;(0!<%2]Y:kg_6m=:=nnk@)n2E"D2!/4[N:%WKAoK8!O[-^a)bc`n\W?d=f.?4
-%jYkq/5)-L=&_9t*75DI9@8!K:2GaMfS:agUm(l$&INa?WQWRk5jVmAB@h7/?L.&hs''V9.A=qpa"G7)m.f0H4+sj.r">b>95n`;k
-%mUM'Yg$NjC5]$4Q0:5pu]E,g_gMf`HmqS?!QlV\AB9;-o*D?0#aE;q7rDpqp(7\p).TO:LJV2jt.tE<E9:1C.Jk@bk%^_Z3-T`=4
-%KsE<<M8b)69Bs2)Xd<"L;%U*Wcc6=;Lt7]D2%Z&?[,t)<P9[8;5tF8AV3FBrLC&$oJol0,?W#3aHj/I=,ep>l)Nr.#e;*Sc,[FuL
-%XtQKS1XMO`^6Ec$A\pdL*_M%%#85(8ifEcU^6IW<jJ!e?)$u![Eb!5Mj9GQ\RRSf/R9V,/7A!)jZJM'iD.Y4_CH*?9)sQ,ZnI;NJ
-%.`qSi9VTYK/]tN@Q.[QJh9Grt-:$:N!0PEiVdpbS74\63%j3l=;$M[T$NAZnFo+4ePqkE`073lMX!T13UfCr&\N[E4@Ee1W@+GYO
-%9X"bD`hLi0q,ZjENL7&>-F5V!P!TMZAl200FacPE3*3#0\N3`*Q4$VX@G)!2O@:u9c!inTgEA!`gD6](F,qkK8m81o`/FYAo\De-
-%2QaLL3Y.^([1$NhDu;diTFK.2"PJmuU``NE42@#mOXD9j<nh=1BI2E<=HAo(#,@"<malYBnjia2j@`pkkJ!W#.SoVV1JHb#WU.j6
-%4-*)2WqM`n!-P_[6LLu6_+L,i)3@2V=')3il;2dOmN,)`i@SV?kI7H(;YLKuBmC6G9&;)5?Ph#fqS/*e?iLRJ650a3Dd4@>(Hf=q
-%_-i=P"rPS";t5oNm)uYRP%6Fro1/RueD#Rta.dRW"`7,IX*b>GO`YV_Q6ZL4)<['R!+&buWS@R[HK6mLn/ajUPCJ9d^g+m.O-A"/
-%AXr3>/IhMR4K^dI:$Rb7``>4)>R@r?j'h\2%Vsn#eU+H1DAM,K/l'k%h<A*T(:f8PY%oYW]LS8ZZ^,n.[e/oDas3@m#4umkVO<"6
-%kuJkZ<e\oYaGQ3cFWI9@eA-4!b&Iga[CpVhat'LdJ0rMB_(PY%(Z-4$0/<Fi/t05d<%8b&&;rkinGNWqa`#r;X@[!IcR:r\(p7Ej
-%H@X,bXd;(]IKCt+$*](nY6np3o=`LM]'$t5%R"ap^1tugJde-G0?#rTq6>Q/:g;L67(uB$3RZDli+r&C_].MT63.8]+DCl[jS.5P
-%8;!bJ^B$!B!1@*t]>7HNj%D]2[HNCh`lgI1I]j^QIW@A%ZUVI=m64^M?sm"jE"]4k!H=X.1*:a5:rp>M7#a:Rn!t.YAO#-bQ;aI7
-%V5R$qs6(8+=A%5/cQDSmUK!9ukYb::@BdPGJ@_U"ajV_`s$MAYV$C!\U<Gcd)*#<Pl_W$@*`O#>mOO<frk5JE2tU1eKmr@hkeBWL
-%lu6E3^nV)QO??3C[fhM\""gha_0'9/>LJ<aYAQkC.rNWR'dSO)Bq3]LNKsF];<PX+%Ora.38S:A4^%t"!7%k:D;-SVmF)8:i9Gm,
-%!nK<U?u=R-At(U.Nh)4FHTN7lIPC4\g:$DYqJ0,3NA4P?9AVVM@ba8Y&iL'GPhU'Y_5EuY!X`87.+3$!f)]n#TEe%?R6*`f*Mc:S
-%YFsJI)m>6)^d3%GJtt>@!pWn[Z1WIA+6")\s0?afOg%+4_>T0/g:#fc>qj/C@-_E^*aE[r@,ZHAX+P[4ZF7rq[Wg/1h^OhjrB;H2
-%^/mn1jc#2Q/A2_+^B3R[SO#PJ)EkU5']93aFY(>$\;43WhcDMT]%#i_hn)$#RcY/N9XnS'E_D=84Qr$mn&m.6:Z-;B"8)gc^k(8$
-%R1*ZH^,o]s?F`Yd:?18<[t#qHj4-Q^@A:$Jenn=6o;ooj3Y-E+i/Rf$Xr6#3>dJ7+lQD]eLGS)h_q$BPG,uYJhQVNbW$VL)NF()'
-%]qp0:kq&K-jc6/Q@o.<*D@j&Kr$Dq<MU;Z2I_LWgErl#4Xp'#W3LlSJo6nV>8p`8$!n\"Xp^*ug9FB=Y-GajK9d`Rro7jk/ld]V+
-%$]E`8hYfIFhY@KJ,i3KIp[t)pZI)!#0.T)fTnJ`fV(l?Gpkp/[ERD@L4tFEV+*7OV9!Cg2']r6[jJ'?3Amm_(,)Ed0E6/^=.b1iD
-%d1V9l/bX7bIJ!A8#HC(b=Np7<B2D[M__;D[-0sd9USQ,AS5`DI-kF9=_0Oes>kda9B(XT]G86OE*]V4qjNr^"/B:ruS6VUj5f$o<
-%r@R5<]P2(_iY;H'DM7$L'BgbL$J7KEdN=3bh<"nK$uP7'X#2]&c^I@e^$\Y+(S&qI0\EOf7rl1qJ_B)O?5#'5G#-E5m0:&4J_)_n
-%(+`*bMqRPuo9#/J[Qr%.4J+1D()]Ep;QH`!=1Q0!H=[\Pn=e'=l"h`3fk+]1.*\a+#Kt+:+'71IV_-qSmO#8C$.$(p=9dd]>%1mR
-%6,PFE\@$0WW!ejG]Ujenmd'r!hl?FR+O&dh.+\D?g@AgEeEVVN6Fe+CXJnW%Q&N-WGhneMm?74<Kf3fo.6#&P3=K<VH)4#^h_8NC
-%]a*dgg,t&=YT908*Ab$u$(c)#m<g4bK&%e@K;`hNq@s%.L)pSR3C)k=*'D(:0W'(gLec(/B$\13/lUF#gNN?*\5`i?;ab8!;<,W;
-%7aUZ*7_hJHmUddZS3KHfBUVd8!>`k_S>[;o1gmN3[]bKCbcqWH6k=$Mlp`IRXQ*Bh-u:OoY3mKlk*["kTF68,BZ[MtHWAkH'K*\m
-%/$f)l9%U1&XYcH%II-Q%i*$Erj8tTje\u>o1=Uk:,7G`MlON=1^j2gEm_f[,0i+cS_O!8a`A6nuNfnJ8fe\>lmI9p6Q-ZHV]r#*Y
-%DoLM&^6B)P<Qi=")t!9Ah$j0h-r2LW\&1TQUBO_S`<*T$a1HJ)"V[,eF/_84/Df0GA:3:mU=he8mLR47/DY%fM[e24%^RAI::m`H
-%-IT"S#0'!E@?6hW+?+C^lP<RBDDj10*KR%sW#Rf*DA3J`!*3'r]HW.O+P*'//[L=l*_@4hbi?_tL6(Ga)S`c!I`7_tdBX^dHaX=b
-%K<RjTc]IC\*If.^bhi'9.P@p07GAe`7ZSF3hUVWDMWC10Y9d:r[\`:>[/V2XQ/G@ci.1S"$n>VC8mG[a(nl,*J/tUVeut#G`B82V
-%L/bPuN8@k*(<IY"-c,lD7V;c>rd',A`]u2'^bMWs[07j#`W51\;-4mT?pUH#(Va&H@/]rZJu)^a[[Cm9RAuq6WH]C*Q&^[d9pa/$
-%#Ql_,L<Q=I9N@UsPT\IT'gM$UfHl/^R*=+E"]ikcZO7&,="(OX0[B5RnGG_"?lWK$Fli':<Q$WII64BgLOi-k[=LZp01i)RBJ-<S
-%'kZ8Uo7T'f6<qNn`_Q]g*E?U;]MLep<pI"2C(`t`5l1M_[`EV9hPBRbR6mgZ65q<S$G>N5"@UDXd'c3%$L_El6$iCgW`fnR%c1%7
-%RK+])[>4\\;VN&l'MQ3Y>d2lAVqBZ)j:sj.$Ic*q3ID_f<+*Z]AQBnXDu>!OGF/An21%o%nX<TCms\gq]agsHR$\GQnE1`a>&l>;
-%D4/'`i$q_Kg`pmW;oT_sV@0+^kZ1/*bAoeRcP-B@h;tB.i@N=NC'Mp_."3)YlIlG;2r*%gkAa61p_$9kBbA&CZE@h+'/ohu=BF@7
-%n,"uN&A69WXSVAak8VWS=#O(s/B>ODHiN>$OIM<=S[/h"S5,6GdUJl:0;SpN=^r]GEP+46\%qk[4Rm1!;e1R'T7l17\5Ss*b*/FN
-%k?&K1gup^H+8nu0K>uc?PfA!u!4n:3oDQ4$^[b#_pS9V@cSq5EXYr[W0&0U!fEZUEeilJA%Sgo3GpKO-K]h<sH+1V2EMYmKT;`6%
-%dk)$C.mEf&>6G2cq[:IbK;X20B2m0]LrNA[`gjJ+,?r9IM);a1iRlF)P!Pd3RJu#O'&[r/T;2/=)`\Vpl^4r-4:L5q2u#LU#?`er
-%`&XM\cok.W[CA(sgU!dWb"rXM7'cJa-'"%minpYn[I!YcC8dI_XXnK<K0DE4i#9S%\^@<sF:89@SZ@N`dQ94_\9\XW,mL[gi1>V5
-%"tm<\B"!*#iDDQ4aNQF7cFnAVfet_2o!@1=U,BNI!KXqm#_Lipn&CDH8%Ff<)<+OR/aCPh@;IG75.@*qbDsPaaA?3NVhj_\E5!*2
-%m'pr?F;lS2Cj1UkV->sTlssLYmaldh`CU7gk%sbX<ek*YF2-B;E*746jg;98`j8p"$Y$]nLqMa4UB'T-mldU4!*;<E("p!&luh2c
-%eb%Z\c1iF)41f[^m+P_m+Kcg;M`e^l3(V=G"_E67(Hj#bd`gV?r'/X@h)\1=a7hNSPqn'`$gN5EPje^f?l$F1&2D[MeS?KRP5>\<
-%!bKO/Z,N3WH.qWjDC%gKh\P"`E%B&4J%bA+:\BLmKtX<X>oqaGdhi]1J:$$2*UgA%Xq=\0E=BSC&70@k1a<1EB#21TF]O&^FK\g,
-%]r($.k(^AeDRZ.10ZEGlEK0W)hgOA1ZhDrNmegXP4@0EccOb]k2s8uRgk"]FmPT2)cR3h]Y>R5i4)W_phojuHd'If<-k;\oeYV2r
-%4mk7!"h76O75O8I6C/QA>=Xo\X&+@_P;cFJ@fV9=W7B&$)s4P5XS3%-`6@Ok"7*Ur2>2u2J^c!9H,Qh697D&un!P_MdPJ<"eW?Eb
-%.\EXCR!J2Hd#&e1)Uf`X!eIll8$%=+'WrJJ;*edR!5&id'\*Be*8nET2)$&6WJGbRUr(_Te`%k]QXYe&=>7%(oZ2"_#JaRNXVkt0
-%c`/$Tb3%IM\_"4&igeE*RaU[30__#hVqUOrBfBumnp<kJbWM5t"Ik#@f$\CO>W[.o1k-Trh.G[1^*?+B:@nX>#oRP5Tn9%jRDq6U
-%4CGO\gL6dRs1<`0c=^kgXTRdTj?p`er[6VHF>Wd,:MpjCbp\=r0M>QY-#^j_7\j#>Br^mR#(#F8b')oeC7_)8PFs<fCu7!Wiac`=
-%%P-rD)p#i#46uIchrZupY!(!^93'B2:up4n(?_a!gMGsV-#rLEBfBMK8/hcc%P9Od04*"m**c,:>WcV/UK0(F-Y1?(O_mri?bY>k
-%fs-JJ$t;8IY>Te(0sJLiYQ(0"-\;]7R+L+E&9Milr^bZsJ&4)gV(j2NGF1rQq=2&Iat7cH+,BSRmF,M'pB6'C-?041%1LIL[:XWt
-%,A$Si@bPGgO4qe^*pJ.EQZ@&g.c]ZSW?d1T%q^^9)0U;U-o2=AhsN;`2H2O,<YB"#4.5m]$tKG*Ju$4T)!DY\])EF`_p,Lj[u36R
-%TB_PTi)s(c8k$I0^LCnlX$ikoWQQ>*hf\9OV8:=A7\jeBrK^!Kb)K^#g5++!duCk&qslbjK+b>m@T!jJD!Y+#FeP(R>L-IG>l)>n
-%J-pIg`Ss3T@bI?3S0Rs)P!WP6AODgWi:Tpgc\8rch.Y9uB^euFEn')TiY2]\2;N,%$HQ!JrgY+Klij+TcQ9C]+_=HV1:LSs\@&_b
-%U),Fu<&([pH4PDL,(U(##]=?cCB>2^ke0+&DQ,%GbS';+K.;edHfY(3Z0f(UgZg$IhG+DC6$LFq2WFV4SnRe<&?f:qhAKZ@!YhNl
-%TLuslcLm%]B8E"ZMXXn:[Co[n1<[3Ar!*7*c<\</X*-VsbsHrteD`n^"&\Bh$cpKX&o$fnW&*K6;;C6FE<uDdP/ZanZmO-Q/a!$E
-%MoGXBN9H*)b90;-q#<WQ'`58T#^f-Bhu,1FG#\i]_OYnX$>Pbb+@&mJQ]8M_o^IG["JG1dm,[`A+$`$t."H9--1\8EnkfCZO+1j?
-%;/1YpEaq$/gGW^3lR5acVjZ'QpLoG5**,Z"/tdM`VgV.u+j1olY4,>Re./3J35P((#W$A%8j+-*1*X0-r,kpEjC-J;H^d1F6(B_:
-%8LC!eJR'P!o*n+D>(2q/@4Gd&Im*Y@8*aMLCJ:U4=LT^LH8"MC\'6SK!nnjWhR/IW]rg%K</n1QCHnnrRG<1FI7)s,Gt/<S%YoSe
-%cCU(/AnjgW'a#;.8qR!AC)]$k^pa&VLiVr"h?K1VX+>PF-s2]Q%F,&(X87!Yb3YM<6;CXhO;mE(ASclIC=i7.$DW8qG0N""H$?a/
-%p(>J*bn5X*KE+';jp:D`E/nnb(J*-H/9dTjFPdXK_Cn`2F]n(@ko:',@5r!a]HiDQ<]Q,Yd5H[`!Ld0$G]1U+C<i`/RIdDNkBoGu
-%!G;TA-(1dQaX<LV(h(InoLp<Mk&>\N26l.7:'39Sj%=GhN2s1#+m.uoC&N2Zm+]*g[_LG5BsL":K+-C%nE#Qm[A6"f,<FffZdcS!
-%aHVON74ZQ\s3*[UBu9bb3KrUY92XV9(<#;PkXA=HX'XtH?%I0BUK!.L[&0sHhAiVeD>T[!d8)/Ni<&LYr^?GGUkFb3"4S@Df3&SY
-%X/1ihr.XeUXj[!Yi3G^OcMMV,;bPD<Mk5a\rBPP]>SZ<-e1L\U;Zj4cYbkV0YU@Z:]_-`BO/di_SV+M'J`=SeQ(^_:H6S-K<5RFY
-%<@Rm>BF_%["L^0^FT]Uhmkiu"4Z?tT=AnXSe_6A&05MN.IEn7PGH`!^bY9XZkHOZ?1oK"`N*mFm"XEKm^k4gFpSd736pAn3f7^;>
-%]gCI"h1W!!M[i^&?dH4[:Mr\XXlUIsTPU9*]!LS,aIJ&jMtOVV4>ReLDVi6qB&%u`\KT/GM'.YB#0>..:1Ec6g6q3!(%rA$.#[7<
-%M3A?1[5)kd\M--C.DI(*".%_:cLO:T]ZeRd)@;;V9`.rS0[5Hoo]\Jcb#;al!d[+boKE_sm4Z9!X#e+>nKfa:^5!mO;F'>68lkD6
-%qj,sO+:ujtj;S/F]Uij3F+2*L1qablOhBnriq\?HC.Vud'UR8`q90uq7elra'e1Mb)[X(0O]cUV,P1de_L?1lQYdiiYSs@TKrf?"
-%N;"%[&?@c.N]!M%ODZpZM)4B!p?Jc*I2Ct)-H1+]O>RL+YV\$*p4a?3m)f!AA.7-,0gsF9G*!QY/HR>K$l@P8NAM`6S!f4Rd=hg<
-%9AX9?('AWVN9s,ik$&JP`lA;pIj?epq=Dai>V#%/_Lf<CJj!;#'CD(e*>UKBB4,#.JMZ5'MTO@5o0QC^@YWV(*$k#H'LM'tr>f-N
-%p/%b%aY72?I&%*&g(>J4':+kJ!t,J.T<KkKA\X6*6Z\D5f_>VjKp]lhnEK"#\`;^H^bLt<N:GK>Jbn`Y9?)r9f54.nP^(>C.$VeG
-%3041E7EZN-3CgN]#$J)H>AtB#bpig?AW_Se+hj@4AR*^)JfmjmD&GPCR0t5j3UK'p,:%)Bg'Cd]WU@I[$m;V'S2@VY]OrbXi>P=W
-%K-#usLGK-aarl.[q9XQQ3C=]g4Dq\8C+0Ue\"=as1dR2-Aac$Z0c(R!1@LV)nP0)g*_G17Yl9mqJ48H$P!Vo1MHT6i_%8lCIJ<-Q
-%kJ4aZ5pQe9^c-Q>Or]97O&@pf\M,tkKim[3KJf.(2't1IMVPt$btt6/"SECm)nfbR<?C9_?6Oicdh\>=h>5,:VB^N2r1On0INg14
-%_VJE1q4&mLCUb;lS0BR%;(Q,(+^KOdZ%T#F@E.8=-%Q)-5)L\uHJ65q"G,VS3-0;rr_;s.dLa-9c7'dg-PsFl(Yh^JTkD%E#:4-h
-%@/U!Hp#TEu%K!u7=\hPY8M>I':s<O9_9YW,O6"SK=C'F/MkI?/B?A5b$3RTB3sV8Q!<-9g:1]H#94Z\T<68?n_['j$6qrWk")XO,
-%'\.BMHUARIkc)Q'[p0=G/cAV"7aAl(8]PX).aAJdi*A?Y>kD"UpEYk2<gJ]0@R<?(*lYP%+b8$dcX^YjK>YuTQ)R8gP)<Uu-t'/6
-%m[GMfQjAM2ScLSiAf!7e<Pc0Nmh6@TR&Yk8\M#1UJc/2ua$!no!^s9(B2J!>MQ0XXP9_[gFX'XTDDF>G72<Nm,hDOa9Q:F@)eu'm
-%DB4"H[bP>/SP5U*Nk&V@=r3W=%2RI4oVR#:$8ZCI<CprEJ?8f;<2EtcWpKs]iPcQ2-!p'<>iVS/?ess.(c%BX201/IZ'F^#7WK]@
-%FD&Dh=+of\11HI*pNpMP<YB.\8>.[h%KSR&AD^ZjWE`r6rFup=+@G'+0H4TJGg.PuTcD7G`u6HR8js!IbXu3)'s#VD1YCb9+I@[$
-%ad*B^1+5a%]M/d?LG$S6XMQ>^>"'4Id#=Wi5j"H6?IRh[R"?3@\Rc=WH\G0R/OTR`$sO5l-qf0*:ff)RL37AOZ8Yk5N'9jc]f+RU
-%9K>3jb8$Aifj\DKApBVVlSPC\?r,p?W<-o-RUlj'GnL6%[9Wk]=c-(\`s".KHJtFIg>3^T?Qiq6]iE9ZKpVU-#nRu;]S_).S4A1K
-%9'C-J<Z`,Pf"J*m+n4-'-BfZ&m[@uGW3e&5rR:Y+%Eq7!kD]"7\WS:("?;J.V.q/j1'!`i]:m#NhCNGS4-E5Z@L0;?E^8@gq,eM2
-%7'`Q,+S>O(Of!"^DYq^W2VUug#0SR"ONc9O#[lTdQ(\Jk>+M[+)cFHJaQM+sXMC)_Xu&hkqUfJKb46ZlQ[&+6PENR/[0c4NG?;,=
-%hKpU"Y7h=Eb7KD#MbkH_#Eu3cNS@Hdj*7.,A"V=/q/3HFEpcCLZ6b[`0'q8B@>=0G(!,pgV,Nna.u7L`*pXqEl]oL==,q;o.Oq]5
-%^B'&AnHU+-Y+4]j]KOq*Q.Ssu*bd3lm(c3WT=Aht5"8"Q;Tc;++@#H?T\u?U$L[B94THoR6=JY43UmYKq*["S_]Ineo*P/'q1q0M
-%il(<-#[>8LDpV[H+Aulp?%e,[l4_6kH+(q"6>[;1I@omGB&HHc`UST"jkcCr7h3MX+%RGEofX\OT6n.i%JaK+TURP).1q4%!mBZ1
-%e#;Gip.BEmh=2:@_rrB7Fi7k\3P<.C]h]L\k7Ooc;KHH%!#ZN,_A:HfLKh@G%3J@RoOFts(<j!(S93;pf8Y',kFa)5p`[,DfZILd
-%QL#(>NA`Jke*V+8qNFN;3`u3t>^`jLg?sXPXed52bJ/U98bSgo,r:9rMd%[J.Zsi89[u9]Zf&Al*Z*n.CFp5,/d9lBr?d%OHS&V^
-%Mqej`VtV0g*Mp&0MD&c$[sI-Olg;f=Sf:]Dq_V^?SC8LBa1DSYbY&t>.0!sh50GiZ"/EK_44^IiX:,*X!8Te"42n+Ud9[[`A)TAG
-%,"2B&,>>9uK0U?Yl,,;$;M#@!"d*-l@655tI,/k90D9_sbSGF34=V.?/^aF,T<-1P23g-+/js81M0e`()Z><#k7-8[ODT_=[rIf9
-%hS6(l-X#*Nk7KQtNJF(eM%_]o>$%^R`0.Br5n/s)V<+RLMg/]qp-'K2!)I)<E)%:6[B!s6EfJk$$T5VKF4R"j@+Ha[9)'n<"E$Ei
-%KR^^F.p;G$T%O:O=_$lA+JLWTfrj714#23>baW6*I\tY*Ub$7sVVrr5$Of,Ufelu/D#Dlt).cS\/]&T?n8&'60b$tSrgG'&1:AbM
-%/Ha)Mm(djA76.Xukhj1_,\/&P$Q*+B;KpaVJH_"[^gL+j&cOsoQ<BI]Rp>bbX%*k<UY(XR)StIDKT6:+g+6ru0,q>l`NgU50Ub5D
-%b@e_U],o8akWZ.%<AA>?f3+g1X_^C6;`8T!%UL7)9oD0B9,-"JH28^=QutT:`lM;]"g]V`_"e:7AA3N/cM#_Aq@lu3!q1pHaIRF0
-%&qkJ*CO?8k]Gj-X7te(g[b-sa@BWN)1K]pg.nmM/M^)6Ri,-cO%1?NLkt)N7&m)!YneH#JS0h!po*hO4gJ&!'kE-_dDEBd19^>EH
-%b;S.cndX%0&Sf_ZpIS)F-aLc)>s+6HU$`&IC?k`%nX`1RlIssFRZXT&<KU(AZKud!KBITcO(?Y[5%0JEQcsa9#'9+4f,)>"&gc8>
-%P[t.$pjA$>QIF'hY$-'+lO:'i-[QEu&VK7.'e@eE\%iPYE,-@Cjc>XE)^s"r..q=>-hC\^3@I%Z+42aOpA<@_C2,>_8(k^=4qY90
-%TRu]#VfN_p6a]&>\iA5q!Vh&$n55[km&X1C"#=oH\=s3J_LcJbg_'JE:!%rlHg)Lk[/>=lp!tcCc.D-IMsEYpY91sZ#\D@Y;.C,7
-%,%t]H.dd]6q&&($>0NCS^s^Z>W*\8gi2^)e8$$)'ZWfEoX@C>e#VT+,;S'aHC'*s$Sf)+['sZBgMG%dM`u0oG[Q57X14oKR*\--J
-%CHXZ8p$dR5>[@Z=DYC#LWECVihb<00KEPGKeTB<k(]YPj6>Kf`?7C7*DTP0roph'm93@IO)osMV9n:+&&l_l=IfNaSB4=]M[YJ.e
-%QPH-)/XF$Uhod$P'S(;?(VJYi%q<*<1P:8^ZtQGoOql8/$l>18CCBjm.aN!@:DU_A:!YNMXATP0FSHKHplt5Y.UuG'[FKM7Z'kh;
-%-/VMDFDg[M=ct;_@MIDKjsi]*6P,O7%%]51#KdeUShCD*kZabb2S%Ym"CuK(`i*#&a]]Q6Ks4\F5un@P^"I0Mq5-i/Y=p:NRauR2
-%1.EZ"?.UU.BZmXTN&&fGf?(:`V3&G6%6j3#X_sf3nZRI:Vi9*gH_S=a^Oh[+`)kTb+&*J!_Jk=i'kTiVq+c_?GB9+jBm#qW&%cnH
-%^lCq:-o^'/*PjCj("86'!bF&PK(P$`GF4_%:Z>;6>TLJok&IVAKn2n.2G$s%C;)LDJPH%5;=ZlBmm.`CZkeYBbi%i[I_TI<[QNHM
-%pr>76@#[;Jn)4EMpNNa6oiX5R=1qC2]"\7jr0[?K,8dG-qWA<WY)9V:oUZpnJ1P>^ln8Z6aNa&j4+YGb`3t:r1DVJTPP?QLU!:EX
-%CtQII0q8/5j,SgN_PV[Ad:>3388XQa!_@Z*cqkSGVO-N69..@Sj=S1lFlMt*!qNL2iD*fmZs\[\jp59*QtukPc'0-?5.aP:jK>n_
-%FVsQ^qj,KhV2C%^EQKP1(5o9!,s6e?jDEh`dlVCi6npNA%%q(V$hW]C5<g#t),C3rq9=n0p*FWUQP#9_(i"F$(j9<Y0p3M_T_jB%
-%"a9Z`G)rge(`g]*Z/dr,Np)GJGA"o%!EXqt`&,C[?kB_?/LF##(.mr*:KVEk>V`=`Hs(ZR3seY;O/5pIcf"/C8!)kj#-OBhCB"tA
-%,h"EmZY/+(!9BA%YS:%Ej1a*>/$jE7j/+`2$,6TSU]?d>V/9fcfbq'6^^;uRDh;J$nBTOahh%F_`Z`-B'5lk/'3Npt-K)to'3`4D
-%*^)aP;/annd]h\7DF?Md9H2+Ndn<\)co-d-jQd"0n&tPc"q#Dm2)#7n_*_?49hEGW$0RhlK)=PE-Mp4_"u2iJqD;k>/"J]1bS5"o
-%^q+EqbYAM$Y\1^5J@=3r$tekI9Xh9pm_K%*GB4ha.o8a^KS6if>2\t>U&2&>*5rmDT]HjXX?9=)-]Z08e>7NApblqWNCN%4jS?pT
-%,AY`%7N$c'd%]Y`.<^3*9oC6)iXIN@?Q-QsR;$Z6[*Kf`SWLY;4BF[:'#GRN1"Oi"WQ37$PA0o!."W4Oa7)k/>T:1!!WE,gQuAu]
-%8nMnIn$LQNF`>+5ai3W`-R7S'<LiGM_!t:SBee&8al9P3CCEa<r6tIYF[*4&CT4f<4V_+o=7Af^N9deBM2Ehdk,m`c=8**q6Yutt
-%pg_Bl*gGQ7J30`NPNoUtWqcrq+1kF/adGG>"@Xe+9=C^SVe-q'rkao=?.$m4UnYj9N7U3K5bG_QK<=bP!INU"#id3tQ#nX+PZD?&
-%bAIO[$@Xf8gF'JNdr%9N,F6Nfc&&6q4@5)X/k"JiT\L@m#NV;EAHR4Vb[-m`kNg,Ak`b'n5364)4XV.%%rh5O9:r_WVol33H%@fS
-%P$*nT]nZiEO=fiYP2MBLn/+CH_"Erdhlk*]>P%J*-o,JGMk>VA^Ygb>7.W4s(p_WW2E=c\)n'VL0Fpt!5fYa-AY5&2IX7f!VPI_B
-%1X_LNe(::r13MtW;oebC'V(K4Es'`pa,p%TmXO9K3(XNi7f4SLHEPGe=m=c"(_knGZ7nl&-V:#5L0*'h2Gfh!\0<fV8#e=b%k;n$
-%3jLaIV/R1p6TO>TA0A:*JueO,?B%VhDe@mJ!JP2/-oa.;a,hPM9V^r=B?oW,H0YG+!NJ([PAtBK<8[MA+$_bQF6lQf%S)q7ju(i[
-%MI=4`9i>fN1te+SLB;o)f7P'12CGs.d"'0!B#\RoCN,GWr.;Q5h_r5J:1nlQ8LHobh[\MPerm)E^*d'=`\0Q%H&Jn%*E9M6SXT2V
-%k00T8k[0QY-MC[\%uk]EC\\/BTkMYbgbL`#c_!"^k![-"/7*8[^!YW\G:M%>N-d1G+qN6SCCAmtga-M+Na%6,L^@gn9frZ*m;e"e
-%rfL]rP&Y62S\\KmKd+j%5'JBOmG$F@dg;@,?[+MZJ&+4$8R<lgCqEmuIb64pW(Ur=_dR(g:/EOk\O@ec=ioiu4Lcck'HK:k0mc"B
-%rSd=iN<fE^3bGg)HbiI$qb?7(SO7"72K^Z6(1`q\k,)EZDS-5]3%^#@Y1N7VO"?jjk6[`#G;LBH1Zgut7.5,S^mT)X.pWVH^C/m5
-%GJ2"MhDu-*4hSg2#_3NV]TTRihH^AM0]T!$#/,h<5.=5P4r@R7I=Z\:"M+)gDVAdGYGJtf"t(M1(@g=LqAkLPV"l$J?].`!Rft`H
-%0CEuEMj1mj+FfH6(&LU.YT(K'?Mu*+BG-)Cc`-_@Tr8s=OEPS*[PoW-TtS:)LY\(q1-R".bW/,u'q7P]*o"_pE3-C991>=]T,*br
-%`S@%,*Op/@W-ZY+s!&Ze`@PQt>8d$K1_Xl"-B*`)oI/1F<4#qZ(=^7)aCP-FDBnO71/_5mL#kfn&*Bh^lnCCV-H8;CCdsO8[3-),
-%W1"pQC'sFLQSUNCeBfC/&4nD=:3/*oLObX(7eWlE[W8'hRa^[WTXn<[$#7R1MW2mlQ6c.(&MR'8I5Sb?hFn+6pCa\o2o4rH$`l"K
-%"=L2:%%HFlcU)-lb)Fsd=\Ao'#X-\oQ@!^7_$nOjGYpW:Q=RokU9lV.?<6qN<!4'>dlrF-$gr)QD%`7e)A\k6f,@-eLCie8Z@pgc
-%BAmhbS-p(SMf.WC4D?DnB0%sg3G^U]0`l-HO*<b#^g&uN22[T@@t3(T]g!,:>UXl:IL&Kf9BustWT./e(HBE)co!eC+bsi+;@f1!
-%!nKjAaHa-N($jS:qV6:K1"8u_!^QI0n.F14fLlcF=i#j,iEWuS^?okJ_hl;bqMDa-<&44=,QK[`fK5L!0'!]C_bgi`^.Ope(2JcJ
-%nN'LM6^^heD-1]6lT"bF(lUD,q_r=62\LYuNtFRkDr/9h#0R*Z$jlKh3Y3ulrk!9KFjFI=OoN?e;t&/Bi+BLA=(H@X$gu;5U<FaT
-%(-g^=eZ%joWr<k!'iFk"Vn]FgAu-$Y7>TUMhXHE;pgG$nCD7!%S3o_#>$a&TW@a3Z:IS":D,&1(W!/kllZLNf;<rBa$:d/=#$@s*
-%A<@SG2FJ_YVR_:pa%DHT:!$O*]_gWW:(j;f^gQXiL+=N8Sue7G+:\->UkE&GGY%r!`jabsZ&W)ILmu0&$9l.aiKSFMCZ\ugAo9`$
-%Zs=BEW<7$"RLatsgBb6upJ;++J3@ApW:.'%bE;3Gl0YX?30Jq8E<f,e=a3dMJ%=gh$&sQ,M#9>9&gAh"@'\K3)]%h%YbVXM?rD7u
-%UL96^oR%DJ5Mm`YAXLG&SoW#KfeO$tGQF=30PPqE``+^qNPEM?B\6&g=*m-'5DR3_b1##76'PE/L1Y0`8F#=[%C>P8hc65u3Y5B'
-%]2B3@gfqr^1)M=^VAOXOFuk`X`'E+b!G?RRpH!!9;L@%dn:r&=WT)QaH#':&5+,V%p^CgW#A&JVkb1h+3?9I/BI1KKp:qR?BV7#h
-%9_&hmRNbNA7NAdG%mUgRWFNeP;s@u7aJ'E$KViDP]CR\KQ">^i[Jg):/Ko#P_G15qILd+poR_'E8OAe>2O>LE\P(##7_^s`2c"Ka
-%YF)Zn->.J8<YCkZ[2=/h:6fNg6]j5hR:`oa<FWp%mfSs/,7F2Ge^0iFnC@VfXehE&P,W!oo*?QO80oPr(JD%tbo(q</Y`dVHU%U*
-%Pf0[P5i;3>.O1`@8cfE"WtsH[F4IA2G;QY5M,t*I)5,!$CoH"**e<+`MA@Bgo;G8PCMF#CelOQ>cD!8-K@&g[)EeHd=]s6+3Vek$
-%jTTrG)[2mDl@^Y,nM%1M-r!g07^Z-844=Nm[)_*`Ub/R_+d^+bS`q]K!]_phabMGqgTh0rFK:PN9h6',!jqcJlTsYU,Y:I*%34?Y
-%IeGCE?j8P9p^I6c./-J\i'c$OPCW6-<7"prHioCfYb(goEjSWApF#H1__ihARQ0f"';b<Nc+.eI>>N(o;_1b#^c@0NE2f!l_"QV:
-%1;qf&0\9eh2mi%o#h-0@Nni9M[u?q-mO<bD':ZUeSubi2m@B]r99,G_q"g>,i6D8m;GBI>H7q0i(O27Y+S;:VO(/@6:8hL.Pp>!Y
-%:^gb;<=f:Gf&I5b.NuS8C`b&eF^*t&TGo6Q%0=M_XoH``(UMuH62'5Z?lX*%fr]mRMREZ_r>8rgfDQI)?GYqZoN-8hfl\4j9>Qg.
-%Yl2h.!cR#(%<&XIi@WY&q"%(nYtH0(`7^1>^JRGK7lBe+(P(qs#Q]:JGWUjN=LZmP3u2NlJd2V/4"Lmm&F$_';=Y&Ur8I$cpS<i_
-%W>eHj,fh$+>OU2dO(ced4%:6q`_3C)N3rl/Aq8?YO@mOZ]@!lP.c_bWiLZGPm4;eQ9c+-fF2m&K!i@)mEZu/*m?@k<4L6<emF7ai
-%pu*!W(N-/75gcT^%BOm>%:$7%PmB?hQ#sm+8B\_agIr)KPYf#`UN6MLL&60_^ld/F03/`FOH^>AJ=^TMI#K`d[<8GT<Y*J0Jjg2n
-%dL"V^(,^XXPTK0'H!aGu@)3_6_u2J'=qL6_E!+ARlNGp%3sEprL(;(JWD\d,k2"c9ICXu70L?]!8uhra&-0/=hR5\3>+kLqNKBAW
-%TYN]_9F&W_@n<qU6GS3D1-=f-)]6OLZL%q/+-A_]:"toD=Jh^BmfG]H!-^L.UW@EP^;OonZP`rcZA.m]\7GiYNp[`K`R]i,1QWo8
-%!P\S?g(js/[LQ()UYJmioo*\69"'3Q70'[M';U0J,,F#N2RT:iqMjG/(h#AY#.UN#0-E6i#dO\gQcN\)!l.><+N^+>;DE+@3@Hl&
-%LoYX''c>?#W5>,p#g??.$D)6Mh_U'ki7D$2'.Z0_32((#EWITH8t(,_N\upoO_.#gC+lnijAj1#1Ec"OP$#&AoOKe_p#'=a^/pM%
-%4n*5%"d&NXc6?7p')@:XLc5KI4^%MJ>)%PXg&(7!>`uP:I#jTV`/5UKL;k(L8qbn1mVVD<=>a^dUc3LZ!g&6,O'S*G/XX.sb:Af)
-%f@/Qs2]^??O$W1O*:2&gnRBM1+6pI<7Z&ljqcAM8#^VSiW+"`q+NI,o\88NAR.1h01.To#2WJEQES[Kg`>.ar)=h:gfnHm0HY85W
-%]g_A)++mhYl&0mcCWhZ7Oh4)Uei2[<8A:oBr$QHD9F+6"!EO2PVr\fD%+9;nc`DXiR,IaO"Z)$6Ub388'&X@n-F:`gb[J4Ahi7+2
-%MUV^(#6h;6)F5Fq^j9,gfn2';9A=c[]E5q[``FQjg/;Yf#H8Ck%*]&1./27W09J<0_AoiE]itQ@$m"[9empV+1G#C0p^"I\k@915
-%>%K=HM#Y3P9Ei2_oYJa;=j%jc>?25rhL5U*#c2f17ed*\OZ]^r;;sAtp7Pf(<o$@9E_idM<7l>?'N[D';24\V5^IF.'#&oiB&)2M
-%acik76Fn!0>-9BMM7S3fbbPr'#ZAMa-isaWN'!L@iPX'OF#(l8!;`I"$l%RVGAg@_X<&p\1t^`ID<8Hc0mLDAU9lLKU__U/J2f$,
-%h4,AZD0*G]gC?m(lBCU?M:d%UX'L%/pi5`cgutXE/%<rUOWC+$\.0$BjJ/^@"g:5B?j'Mmk@;JYZMk;"Ko@;E,YutVP0?qu)PIEc
-%nblnUBtkak@EKJh0+dPkgWO3K;jb.X>[=kj3Z'<b[\%Vb0R\TW?60XNKGkO?"5f,I*d/X[QM^KCaq[M]^9lQ$4YR>-DmkC%1I1K,
-%cFAqZ=hA7'o"NVO&X-Z-f>>Dl8iD!bnJ$-m5`4\5>86O:e4bn8PAF*VfJO>P<"'20qd>aXE=9Ao#9A0T/'El%FHF-s=I3l89UHU%
-%kKf:hCm-"^#Hsu>7p2(piPYLqqQJ"%-V2G<@a(ps,&i(*?Ee[/nE?@,o;1^qaM=?Qh_9LslOFb*!!^`tGn6Q?FY]c]7u&`5gA1h$
-%WNqOGN&BKYljd<9m\\QY3L@?p`sUZ/i&0k-%QP$=T5.)Y8ff<7J6_P=r;8\.V60N>=^q!%'d)B"cU5JZ@#5&bSoK5gE#tq^hU?ba
-%4cCLe;Js=,TJ-q1&uB=+UI<Sp0[uO$635Ln'4j`WQAUrN$fKo0Dc[-eh9/EVM:/t8.ahG=L[C3_h7l<`#P<op&NfJFHq4iG++4Y9
-%p"t2G;oC(#?;hSXrgVjf3ks\Fo1,F05Y(0XDVo?"bl64XJgXI.oNI%94\eaWd5ZZ05IS8B.Ga.e^ut1j>$HGW!KA[T^#&r@S6*ic
-%!dEJW#7(9XZmB$;oD2X">c8+^rRT.SNhTT^]9ZqDKtQ,DDqCIHXD&V-pg!N<Gh<?A(9r-5fQpA7BDOo0Ct7h!^l+o`$84^!Ue>D%
-%A&&cUIM4scd:+Yt'L3n,N7Jn:p2LYeU6V@JJL+=@>WL_V4rZd+g'!(#meI^YI9MBa>04-NPH.paA@Te1-_L`An0%Ir%]si]4tXSM
-%r);?9m`-A2s/EJT=9CSHe2#b3d^7`^EXW[m_5NC2#2DT^`YTB%E;Kdi\dY4-N7.9<R'3,LkL'!aTi5Y'a07a3CWd%>f5;LF,%tq6
-%!m3L[H>s&m8/LdeCQ)2poq4S76%Q-C+56!FVUScUBZUbsa1+/dAD,+P'mKkPaR_.'+Qh:PfYH.R'E!:m5`\b,\E]lP4oL>NDI&Z0
-%T9O.^-YpN^UX%eLi>?N$C'*D)r_]\2q4iK2b/q_2jA=?%UWu2o*`pj;k_!!o7ZiQHP?i*"\9I6P3)@An47'[fBPtEX(UI9R>gV.+
-%H:EZ2Lr8j4YTC4:Q;AUFLZK?L$'ZLla0@B;a)V\R.&V'5"h)WVQk$uA&+\Cr?LU!O_8tZco/p-jbq>U#RA'VWeQ[sQ-!*-(6"Pn1
-%YQ:oI"LkjqT2WOKSU_:m)*Kqb_J`c0P@2.n$uJ!YXP0_MXa^!K^M*^iVI&RY"?>Tg]e*m@$oV"#3%(PTChMl'YPiR?ai(FL@\&]-
-%Y62=.\!G[@J&"TFTkHnMWCV<,>ch&lAq/]r$',04+9r&-F'(c2/\s<eG`8<9=,[1lNR9-N8n+(rH3i_R)A)=7.iLgi5D!7^q1F3\
-%Yq8=HjA?iF,7giB+;',HX:_P,,'gMP@$8hai0H7b1bPf8!f<USX<M>B[1TWTi=Q*kS-K3BpTB-T+7AT+d[ar+WAu1)C1,=8WAL-:
-%PhSr$G-%7+Hk^EX`uP!28]DV'?*7S'mX*+lN.urd0OH@dWUg+,7rVl\7>LJC^B$VK5Fu0&1Z-7=,C#M7l8NS-gHKBRNg&lVSR2?)
-%!cf?h=/bp@Y?O)\FK<28L^N<qf<fH=HZ0]SV$\nlmd^"ZG9)L0#.G9BI6Y`n!Cjpi27Bf$n2+l55Qf%\jf5FRXd200^>B'0UY01>
-%b2iYcLG'I"ZrJfVVKU[+J\iU]TZdICF:RI'^W430D$`,""h#J:J1\k.Du6-hH?90@O9NkTdKN1r-K(?&lop$/+3g,HIkH.:'<)4p
-%\7lJXF&B`cAM$0U[8bk&PD9>*f7a9S&Eet*TmGGpZWdUm;;[Ee\$jfDK>(2IhZRoqD%@<,;m(lhjB_150EM_/qu!@q^b=9Q6@nMS
-%grHi4^%FsRG[9$Zjtd9W!]2""Kk158s*`,kqX91mT(u_ljCL##4,a^lSo#!$anb0]66;_87hJ97%u/&J\F;t:<g6K?E*dJ0_dugf
-%&"&>M84tpG(<2epo\)hnY-@$3=arq%C'Q_=lN.Jmi/-N*"1TO>e_upL\-L4X(1N^h]/4:A30@8sBalWsFp@oW`Oa+WNFi'?%MdQ7
-%e*=d9GXd9e]Rn#D(5e`7Y=S^Q7fuPa#9"Rn(57k#6[M+0R5DM[7N(tDIQd;s6o301@Z-co2-B_7<0`3=CkiH(]<uit%6E(2]W2WJ
-%9]F`:Ti'9<rfo=P.-0Hq!/+j/UnS"%7m8^8Fe]0\Z3PteXC@da")N5??1ia..i?`gUX`a+aqdF;KcD=MnX)(N]R^f.DO'iH17qlM
-%KZHE'Z(5hL&4mW"E:Lro:N?M>+r*KFc6U_AaLc103)2"HKSbX/ndG`CXSclUe/c2+'6t_UgC!)-3?ePm^qt#/B#^LalR&ek$CZ5S
-%n.pAek-\]jkWi\5fa..DD+uZ]hh#U`ICM(9qW^\A+h18g(n"_)PkCK8^cWiT6!9?/]*mm@4(DM"]'br91FX_7q@pTUF&;&kjl+$u
-%pgX0e&hHW"$k*BLJp08#/1`[lOq5(e!$3DM"@]JGl[nT7VJ0ds-,\]:6=$?qYZ"`n45K9;fIOF-'.@5m5O=]iK-f=oUtXTO9Yi/9
-%Pg7&.El$RIBf-h5OFV[&_i)R7JkLQn4DBM%5oSD""eX7a$NBcBj(#+%_^cP9(T.9NnUUq^2ZV.VOumqZfi-7u(^F[".Km6n4K!Kf
-%#LF;Pfi-C'Z<\:NE@es`Gj)\FF8S9:AAm]A4^7b]`2o&,.mc/`,YN%<->)co,^!=SK[kZLXs=BZ1(o<-8]hCl@FT+2TV$</O(<s6
-%9)ptiek"P)JER0J/>k(Up_]<F;,T>g)ppK/l=Q('M"s"hVK5-Z9l)a\/(\3al^b+SB-<(?>I8.@Sf=&%TB9L?/_A(W5YYi8$\`&J
-%R$&&G=1B(iEc0!"C./@nOT,mqYLE7]WZmIR9gJBElHr`':s;_qD7Y=?_Yh+[pgOY-i9$6,E5Xu]7+t5O@)S=S#/k!&G,gWQ@l]/O
-%`lPQb=lNRo41)RgbK5jb.iFSm,&:R@5\77^co)'3,(_h[&VdeA(#9VtaXH(4R?oF<NigGK\?.<sn,VT/^qai5"#,t0<Qk)BP7?p%
-%Z4n(>(,Y(T6bk0^B&jd":oY8K:tpZRS9,_T->Tg$#J_"rG)=kAU6%^[,K`.uYEVP(po:Am@/#W(0#PIaAmm"[M)o*pg;M;blKd%A
-%!G9`&6Rf8a8eRgias>:<>MU^cUXUKb\lm;/@FP[qR<S&;i/Wd[fYOP>$?6cqN`@qsMfsq:#(;1,Q'f^Gj?e,H[\ji@fINq8%0ZX;
-%7;[DAEsJZZG\gjQ<*++4fYi`S8hP5Jg&d<gWO9IF%cc.($qu''/Ja"l#:_^a,U>$B/7bPQ(Q>=67<XWUkutPTd#7BVq$(^t9mD&Q
-%ZQ!=f7kkp_-oeR$CFpD=Yd']`#MFa]5>Sa>`.[5pfr_9(.,?ZLMY2A_!T5%'(uI^-VJ3HX#*Y7Y#nRY6QNY&Fs3UHAq"CYk#91<%
-%*d9ZI2mM`k5l@5&!#=UK`QCLfUE\Jd^jXMG@Ga.c,R;e\[;.@WC;$h0%;I5b-"f!fK!hVL5-3(e_g\J5@Y(P#?"g%0D/q-u=&6SS
-%ILdZBi\K5m,tGAIH)VY]Y&U*s]VhMtXHsIaa^8\#dq_")r6cB0TVcel2?L=5"-[6WcLO*kphSt(30kT2>)s*Wk60;$0,2W.I19Lk
-%U[0XAEN4:$ln#bq<BV_Y#I"qE+^3'XM&Kn?@XVRJq(mdX_$#:p`4f3TZPj/%1`\TXXqS4C[l%<j5V<nelgn?--41YqfNSPd4!,p7
-%:M!S2>c&rB;+.L<-k'\maH7R\#)$iaps-Z:4EUqI>V]A3kiu=K3*tQU@5,P!i[S>K&5)[7P7Z`t(U:L$oq]_`b@StnXI"o,K.'ng
-%+tMM)E>u8ElPWdB24:[lQ;9=K#8[]E6GUUeBE==$'3XgHC`0*IT4.YcP"!lDP\F8N,W_s+fk3X5eWe&69Li[RjT.i@,b1Tk!1#dr
-%;[!GlSL);Y`1le+q5(C)9)o63oO/3I![l&D5a>WeWs%U3gr\SbHe]odpI"j;4q2G@'N".3(0J>W%_.%Z0q_\09]Q=.rZ.Ea1:q:P
-%BFS`[9JZ!rL`i_+=LV]SYoKD/g1r\jfDa>:]=HG](/PBiq_dh3Q4_9*hIhT?0+eEi0Ir8I1I@Z;;/";XPqUo]:.]``f"A\:3rheP
-%"m6_/=WkECBZe+#++\9e!`-OhI)QIu6_2i3I;onca`_'HY;CFHA=C-nZ56MY!lM4dg'0=<ZZm#SYY'7ilRL!_^A]*@4ec$`,ZBoW
-%`>'WAD$>9>llH0D\Iq($G(U7gKXE/;a=&/d+U.tk`(91$h?,->)jg,d-M"UZpNj$s$Y1]Y60ID4:cbQ!ZU-b9N"j_Deh@lp1rF_R
-%fB`dCT'hET+$oHM!;qT!Qn10(F-Wk/.$f!W0NWit&GCe)37<s'VC@rG^0V15c.7lKXS3K`49c;^5Ol$c"3@69e)$fDZVh60!EKG5
-%>DIb1]b^"lUj61dfkk-e"Q^btW9NLXd<&p5cik[($h)bd,X9B*QF$m/S0I?f#D>2],J7qs1ae/\$H\a^=L@-ON7l`nb`Rj%8SM8(
-%@^6nL5V9VF3pHi284'iF<8<X1;cjJ$>YZ'PgV:eA%Yrc\C488p^E6ri<;cC\W@7;^,FJ1HnjA:b;CtYl@>_&=9n:lk8iHd?'TJa!
-%=pp'RFPSimEXP0J493-OA(?rBJt#A3Ys%\JCZdT;G8cFCI+Cb&._C0T%t.3!YI_MJ_+ZF&0TO9U@GOg8Q0`su^39F>\OIbC2a97B
-%XLr<.l=_'@k?c^DSpu8\0Qgn0O6I@"7EUl:i1?T)a@ge[Z5$-RU0^.$H5+0`a#LLOJ-.#WEXcJ>f6<OL1<#slgiFA8]N8E^E)WG7
-%5gsA^B0?Z)SIVChHfM^Q!MT\WoiJuX\=aoR=64e0/D!eQW#2IN[7^P[#.#@s"/e!T;J'<N_M8W+QPrrkkUZg^JP$YmHe?2o*mhZZ
-%CWDTS\4^lh2_r_5$?DK_D53YD$ModS\e/U38LWaS^Zc`al8?Zjf:]V6DHJTmcu^rP3X,KOU&^6Nn>(hnN[PYiZ<2HNc9.?N8nLP-
-%B9E0Dgl0t<3#&97n0hr9JR[UK,:m:bEk%,<4-c#TPj7;O;fMu),[b;+o7==mj)f5Ln-Z?4cXe0VB1BHO#k$+sN-.s+-MCin4<p$o
-%qGuj3K%DoATNr\dlV4uHGMoq"@Jb_/8KT+HpXt2edhcmjeIRjb;Y<,FbuBr5E7Z!I8F9"Q=GZt$UlC"S4Oo'po@1MBP-?8R_bnpq
-%"e*iAa8m:R4$*]`WcHVX[dqSAIcj>\3!N4V7]hfG%#cZl1C;k8@0g!-n<aYJ^dY43Q4LeFA*=_cJce,V0a\aTGs.kaT!nP&"bUNs
-%5KqlBO7JSN:_-2"oi_f`#baNaK3!(48DDiC17BZV="3&/.8k"')>2H*+sVb]cA)B6[^_"SeDb!#F$`&##Y>K,-!mY*@VL#VaX%+d
-%Jk9aV!k\ca7u%V@N9Xf2_2<7Q_\d2LDM,hbJmgd=IE-NH^t4p'E'D#/TO<l,lbd$jbILqH\#uZBbV:6&es/6J2?r=OSj);saN.g\
-%@h/p$0>rL@nB%l<`8Q(%!b?HY7[[A]#VK=^><$Yo/-k.ToHW]7nu1.Ac<l>MgX:'g>Y-KQ_HgO"d&C)+%:e^PrL3A^0kGtSEZtOd
-%Xc>*f)gLpYbT5gLhSo)QRu&`>,pT_"a3@P;$eB`m+EsT4ms>rVR%nUHa@DZ!;RSB)CbAo/gs4Pq"Lh$_#2&2'L!FsHbP![+Pu3Ij
-%OuujE`4c:?8aS8La-o_Sq#V'S\H=UgcI+HFL<3RT"\Y@[?;?kFkr#ro6*#9)O=TQ$$:!Qg4[MH@pro/bU%\Rc>uLf:7$jb[eq-)h
-%SbX,tiYKGD#Ee23q-*neBF&SBN-T[!&bhd9*E`EWrdCD)SEd.*"<_NZhuKMR`W/J*^O0)in7lWb#S`f\FTf10Wh=lui^u07edXef
-%GYS)2-GZYEh"WcU_.I)>$hOk!p#M-l/W(\6&SK-&*3AO$YRP!pLSJTB%tE$u(2TmgP/gnX6Cq;LC:S>),!YT%]<fV)DGsetS>b!j
-%TK]tr%[)mW<P]^UMFCLf<F`E>8:We(gG2G)%+Z*`k]KfA56:nclXA0r6E>idFG@?F@1j^,Y1eJsR/*D\&hlD>_buRfqZD(\pF[S8
-%E6T?Vh?[A7Jbt,bI3-KjNH;tHO."g@k](!]*)W3Y6eE4G0Q3a6^7l6/KVc")]YiKXaEIQO\W$hWAHok*UKbNPr;(O@"h[@M5`^%P
-%FpK4OM+,"J!?,<)o?]&!i9#gJp<6nKafB8?BCao4cQIEPmsfsGDm[=6?lF:HLSU^+W^k$1"/k`Q37qd=E##5CN9Ge'M!jH1Q'ffL
-%Bub-[Ya`mUe`iMiO>)</k8P_9#4M]G0gH)uNg3l%$b3\u5j?-@fVe%@lHF:?T(tFlB0T6/UM2rRh?/%+/AuH4!'dAtArEpR`ft18
-%.0-sq"mg#p#]!C.K[_6,0,+P@e7HJ\kN?dW@)&'k$,s]dF>((.ci'sN^:YnF]r`O7-K;EUs)U[%l8$9Md^N/uH(3r%i";cnd(mQA
-%`OuZ#LV74MkL&sf`N)./UM@*%&oeCrN+KY-o/6kV;4Z#HI2T6<iK%h7YX:@KXU!B\C1=L:jtr.Ba<FQ7MfCco[*=QP.<A`4aR995
-%3L)D.f\KS12qn\9mrbej_chRC8cdCe,ATIVC@5W%T8KfO7YmaR_[EH7)Ou'`#u4W#8/Aq=hRTDN1[Ke_I2q%*UTCi'pc,6o8"OT/
-%H09oekbj`=YW[L5g8qLJaif"&,;u+)?p'9PlGl2ImDtLS.Q0$R\kZ>",K;+ofe0tpZ2hn4@K';J?p8P-5VZjk=kr]F_(ZJ>-<49E
-%g^@tc>-:M%IeON6Z[a,_[u'2QYU9MV=?,XY^V`@l5^j3Np;rfGp"h%_2OM6oVf)4J`R@1fa,J`-#0pGYVLVgeniIYV/[@X#cK-fr
-%eIf[,@h8K&bnFKYObG]V3c]]OPBg=i"N(0=Z3Q!^O3r'=<3b.ok6h)j;H?d&Us+n_^nRi+R?VGb(B^7?/DoN]01/`VlWlc,q$%1l
-%SZ*)!Yt<JHX^H&357@8]0\Y7A("D#PYIiWZA!kj>A9b)=!,H(^hs6<F:eB,J[^mF/7WL]88&RjV3D?3RrCbmcLeCD6l-%,,:k=YO
-%+MQF1%1i()@ta*+DBPJl%<T'8"lQa%mto8_E`"K/NF1N?dU3Y`+9O\D=FhJN>*6R7/8Lp,0L^KN&E^Nl\#L4.:tL&R5>[FOS-E#!
-%7d]cJgSUl73V;FSObeUDIVeimXFL:2hs,:)JQX'q2FDUpa^urr?(59AbN-mi&=0IpCHt."rrX+!C1Ri9bg;a./bVFd'7_Oi@/RpT
-%n-8a#O)+B>N_9msQs#[#]SN5%Z#@.u#]j+W9T2Fm>.P[MU$Qb+.#sJrD,Ab9",;?"kG&Q(77<s6hE^L>$20(SOc"FSA6<CB/uS)C
-%>E0i`TV<gp],[(bbKF@UL_.+"oM`R5iQTQRH'2rue'Lo/R#JA-i`jGP/LfV#j>!1,Qo(-U)#q'%qWCo-.]<-\DGoC?U!.9`:I`W8
-%A3I!P`a+W,fWh_:jVB;MHhqTuSZf6/'K&C?=%3_O6KeIZ?5^RMAddAgOscMG`jm%sLkOLB,dLA'B!>k6E@n,`bXnogFnL^Od#G)[
-%55X^J;+D9kFQ5iC=:q@+e>97#`qU@B%RuB'<-amC$=qrVNo<-t7=WL^[n(Me*T]eiTQC@6LpHdK35FF#8%n/ke(p09d&+HDn:r#l
-%7f<9EQZ4.R9g&J@TC9ra5gt?a2*@9l^u,4qkBn%:=6]r=JmVPqFgY7u-9oQkPS2W/U1V#;bKVOd_FcC1iQ.Rc$@CZ#=t+CEN7WS]
-%q"!gtYcn<jBli>;+qujui,U&FJcqnZ,R(FYO:P0CKY/h=1--aBJL,_3IsmQnTRNIM.D9;)YET?";M`KnmD\<m,E1"aR8ai+UGLA+
-%[^>6n(THRLK*Q#6N-ri>L#X[T"/H1d[ur#6nlrL1Sdm!sVLpg$O%no1*fl9/P\cs!h.Qj,n!fBt(iX/a#7S>2bbP_\,+"'V@M/!r
-%s+%>ef-'L"Lc\1<"=FtRWB;qmXk)R=$t(8mO&pS("$3IQXH:"IME<&sRE>/M[-7!pM],^2XVj,pVP$nGT7cJ2nj8^Q(U&@"Hp6mi
-%UFDV)(F(mEnQ3M:`1L2Uj=2CPJOm[]j7YnBb_TNQ\2DOI-Sl*;DV#9Of&B8Gh5MMU_m<dSN7S7#O:s3>\%F6q'R[,;Sq9L(P`XBY
-%"rY3[.?P8.W[""$0tdhG<WjPJ<dV%T*H\[t!?&#?YHS1E6Pltjs.R1/Qk17/2[&ea]#qE7X&B)W$$%JLgWJH4@/t))2I)Z))^&lW
-%&EJCe,<+5;Mpj]%Pj'dm1'*B.CFXC$Gk;E9VP:*%,&_nTOQSZf9Yc%A`<lc0c8eerE2%87l&IiJ;tJCR.i8sI^LR8Ha7QS8I^JlT
-%js0m4QjZV\VU=_sRDV_rh'0SN7l%tn4D8n&OV9lp8C$#3"`Yj-LI]BS=a:,<UQSZk'SjR^UG,PF3ndmKj^lkU93kj9T&fC'7>KIP
-%LiICY.QgSphSH75#%o4P/QloB<8biKF7:H"@_WqHVe78kg>.'F;s"?YqKGqiR:@qCpjLZ'oX6<gp?M"Y6@df(H?pg3nf)QDP1%<6
-%=!ja[2Tu2k+NUbiEs@dCs!/$(L:^o'=!fSk2e**jHQ=U>jSFogcXWZ!9M!/UCuCb#2Y>r)nUDV[otPJf:X]C<_m:3[`&Z/Nc7Nbs
-%bX&N(6t=c4ie#U+CP+Xc3.$*;@O$]%&NRK<XIUnp7f&u.4%X:.%28gHf"RWY%D(k:(e#+Rk`3CCAUK:$O;V5`;ZGq-jgMVVkr%t_
-%kBAUYpO<`NHDJ3j7fG)nc_"RR5Qq"Di3CIU8(^>t/OM6*r6Jl+V75en"05XKVTHa0f;6t=5'`V=.lP%$<FmXO%ht8[9b&srbCE8,
-%YG1=IVeW3`EWTUB1$)Q_GiRaf04e5gA<*'m(<g<(qOM/GPqL]T&Pul@2>f\GFfGE4pt1A,[gCW4@HiiV]B0"GG,:Zi%7iQECfRp'
-%rDPHF>!5=\B;lJm!d:o)_`K9XCKV`pd6JJW`**'K>=o$t-3%5#:,O"2=4bu4E1CTZ?h,7qqrJ41%aYR<f^nZ[fpVP+!8p_i8'j-k
-%-]C(Es"on;'E//\fG,1?0>0rl5YoMeY!.J:pIf95gOABupcs]b`uo3L#-W5S'.C9:8PAe>mKe+YX>qrdbD^nL2<14T2Ol+4Vk:Tp
-%$9'.+;BGT.qUZ!*?rSekaU;?,EO`m,6?m<>VR"e$_8/$F9O%*N(hCnq)NS@IPI8Wp&/_%h\dtZ@,L9gVSMX-Kj^=Z,qph$:rJNY8
-%K=1hOg[;UBK0LFUEI^RKg92)&lDP2VZ;)Il5^!RofWd5)%/5g0Wo]jS$W'>&'AQ]ak.s^LFACRQ?<G"ue,qCp\S7PuDR*Se+MTPE
-%n"BtXe"ik;l/,@$=#Lrc0b*j1+'O8gYfser#'7&VA8&&QA?j=F8-A=-T2T_Q4S.\Xqdp'XHEo7q<FDg<57*aV.O07#Ms?N`WJ&=P
-%h/=0:.`e-ONtHPprf9@aBGXo'/pSc-YHVVPO/QtP$DmbKbET#q(5'UF=JD/amUP!:NboGk7ob^uQ++(qQ^SgkqGe1ln$"_JdH;J-
-%G5V7@mTGUMcD27=URG&7DDs9*('KCQgY3LRJh*XJ8TlEo>ZY0jTn5;<q^^`odFZXT_+,&(b>hJ80@X,#l1^Pu"PEfh4PH+ki'2fr
-%Y>[(odB?o<elX9CB8fd$^K'r,5!]Wn^8cXKC"d?7?uDQ;V9G_F<%N@$4`]-q%0,,C8+=$O3?0LW5mi-WeD#ETfe%`,oADaj2VsM[
-%G"<'4+&Bg9JG1?WS9].^URJ+9-6Xi/YiN`%%0YTrDi-u<cW=<Y^ps\G1;WMQ"JoWNK<9aLCCnm6g^N7dCY^q2McRkkk*P20mJF,(
-%97s0K[L9$Ff@gug;@@S=bAl5XA@h[NjJj4''J'bF0Y:>C\\1<^a56M7#cm#7!%1le>@;VI6$\0sr9N\J!5]p6$=IdFBp<JCbl`Fa
-%2XP:+aAgFeY_1_YRXj+>8k51WWK_3Z!A,(GUsQCl5^Dhq%&e7E!X[DL>6f%<YGTd'*BC<7`lC.M?IRAo(;otWN6AQq(tFfH6bA;A
-%g"\55r-cEE]T*ep#4hQi8*.6u8HPd"]7\tBEBf_s2:?Vi.W$I9C:HO$(@cO]%A+'E&,e/K+Xq7.GbJqll6%GX^V@.X9s8H<ZKX6X
-%s-f7`eGacQXiZYI1V83C"*uIM4gOe_Ms.B)Y+9PVk^g99Na/jB"2_/FHJ@&;Ej8]V%_'dZ'.B`3&n&%VhtlZ=BqYqq9gBa5g/c&V
-%JV*l-hu>>2>.6Js0UZkkg"S%*PhN"`6!BXZ0aEE=QpY#)RY?QMG_ARq*5nTZ>1@2LC(LQW*n6Y[*^T8GJ,3U0gO9;$`BY+3r?d']
-%JIP9tQ\$:T`\3&k7GI)D>OV2!cmFRp32d4$ql;4JC*tODUeHh3K)9<(K2nh?Jg(38.N^N-4EThaq7M?ig!ZVg`.]"nnoG.i1qI_S
-%RW*drjX?L=3=+&6s.QPe?'aUMkDg:I]97afhol=FE$k7d\B=OHY<eD4ibcc+b+_q`qRW"_B@]ai1Q58sXQW?KTFQude]2t4_ohMG
-%pO$1*\P^!ke%^X>]e+^@BH%*Y*+?W)DWkiqY-"^T[4?OUQuQ2b_D2"+UC'@qG*"`>DV;-Uh""Jli!cXb6),d^=/-1Jbo#e<K0N,G
-%Q\,%L$bS;p[H=Ora<dib0%Up&(-PnRa<Q%%\ncF?cG?,NC[h_K)C!a7!QdTiP;HK'WE9A\VdN@l'Vs5(5Np(P.^i$8Vt.)i:\ms2
-%>7:<VVj"&t'f.3uWIReP7ffT'<kt0fO2XKn75KCaoTH&a(OKtsq-P2:F(]cW\kl@bNa+d%cQ2r0cY\kH[t=qk+rCj6i$#Z1=B8-!
-%>DOl)=9Wu"$3sqX[d_lJ$S]Ga`#)=(_&YrA'9*urMt0#?q[a>,K\cgd+eK<r==Lda2NXMg#5Wc>qb=k][]Kc<f(E39XDZIg[j%(h
-%gFLe#e4j+9ep+om`XuW1FFAO(!!:HI)TS@b&Xk&t1(g1F[A&&U\f&SOrs@b]!(IJSOA:bC(A<Mm(hF[<`^Y)l1_b-!L7.YmDmX%C
-%B=]oF_XTFJ<c?0_\Z`h->YW2.,;%k"@Rn7:WIsboJ8/3sV<"CMO&V6Ol3FCFKjBg.NNgUTWcVh%,iTbm!ftR.CiC/QWehl4^;.0d
-%C1>8IX,56"%PsRU\3[LP`<fo6T_D`Eo9FC/%$U6gZK,a1[TBE2+:kNVcp38JZ7ZXmZ/FEH'Qc.rhiG$P1qCbAC`ksQRSb#o)leM(
-%;?-SQ1eFBF?`\hV@VR?-]/SQnZLt=N(t?AQ*2U[_cFZ&dJsoLfA]\bE_idMiSR?_pek,Vp:mG[C3.C2[e5Nr_[&4X]I$p0Jr*7d/
-%%%!ZV'YhuP)QG7$hUE7eEtCVj&IK7qe.j9`C!7.i%4pm<kda\YP%4NbBmo>6eiE(-q]IcVWS/r/_7U=;:m=C`KgQB&C9&5Z;VT^Z
-%&X)[\jbi><_0J[Q0Q2dTat5=_B%>2U4fu_o.P'1)%9c+TY:Xmp7J49rG%n12qs/XAF\$IMJP4O;XkW<="_,U6ec\s]/8G8P!`^1=
-%Mt//%R2"b`qZVmk#)GUG%&9OU^Y4-](?2t&P;!."[:daqjT7&;ePG&PLk;gSCP0T(-RTY`U($'`]6FA;=(H5<5kT;/NAR1FCIE5b
-%,$l)'g%$@uoKrjD&_e.9>9AK)O0Ng;%12/$ONRhNQPcl>&e?@_'S=QJaNmBXa<4q@a:[M*W;VCuA(]ujpo]0Q+TfYO*.K&MHMp]u
-%@H.C^r>8aVj*oW&NidMM3%h1A^o4AB7-5rG*j.(tmP9"ML/j#/AF98Ep>=K=P*Q*gDqE\YaOqd[J!C)jXf]qC[[@g,ld5sAAp`@]
-%[0IS%b*g8sWj]VsqO?"ZPYXGt0n/KV*4[<mc/tZFrD,Yi%M)KDLG^oV7;hK#[Zprt"hRuZlIK*V'eH=biAQVIeg`"/9)S`nM5%+%
-%45`3e<Yo`tL9'/r"r?\(I#RQ?SnuRV5:;A)"+=RV)F7l=6H/+)N6Ek75aHK1=/:@,"+,*8AO_kYK@Jn,7GH<#FX'OB:mXnVQ@4Ud
-%#&?*:kH&lLXii=erKgi[RanZ"F0RbaOB0C+Q@#DAG(!KH8id7D6Po5Z>MQh9?<CCJl8[Q.`;*DW1pMKgYUno,$M#kS76lFcTP8GQ
-%[`!)M\*=L$%abAi^rls+2lWZJf549)iO[9j3a_VQ24VhFZOE`UTLks[.+@Vd;XpoJ/jPjuBZ?-hAbp21GpT;p75n:KX;Y6j1o"-@
-%![k*?;AH'%8XJ_b1>iM*In(tSQ]b[Y5UHBthV4Klnn."@Oci?u4f"*(g"!KI3l@d:(LJ<gA@cZlY%7G/s4"aLXsM82-2%K)*Vtft
-%8p4-5=d<>Pr'NNN#I9CFL?3-U@2K+BLt9YY9bJH:%f#b#Lfc/OZM$JKRbN>3TQkUiG+PY6WiXG>>S1m*24VjMq:(QQXJ4K?G`)d3
-%!@G:#C1l'q]j\97/ma)F/Vi:8I`:3N]<HXtf3,pn9_HOgfX\lu%-+nn8%u\?%rUHpi/s83;)U>9-f)-)(AYrp(_f\Qnl?\;B%\VC
-%bsa`HXlMo#qk*$gf`ErLQ58ihnkoJPBS<!6+#bp,cmNl>G?%N9p[Ca,rR6&jW*!1TFLjNrqo3Y&Cbb7J#O&QM$d,N^6Zg/q=l,[M
-%fk(MP@65eI9&o6\IB4Oa^26c`br_9bc5<$-<8W]PX#dnBaT>79!IjjDYrB3DR'"CS+K7JPGi[PtRC;>DTq!ZD"*Eo[^u]`,DHPZP
-%N6JkW9WK!r^s2nLXR/FVc0@+fBT;ajJ<'HCm:9!RI:rX'J@^S9/l`DGR5Cla+_Gepfk=?V6)`JdY@9%_o$G@Skl5AiP#?ttR.,N)
-%fgEg)FUI7/rV$!aQSDQTUC.8Rm=h)tm=1%?/OQ3<Ep+P1bR@f!^ffEo;.uQ75?-M=I2+'o,8SM2I@fQ_Q00?a)A]Qlf_B9H8J7N/
-%DB)UL9dU1&bqRg"Ynq"RdK1fq$Z9Vca@e*,6;225)k\-=):YkMrX@5Q(q6`"SEl<LaQBbAoAnT%);K+q`uIm>FKmgQddA'PDt5;'
-%)O!-ZZ>/LaA6'%8%:iKtg]O%QSZIBq?Bk*XX;SS2STUS/6jM9/RSKuk,%ENR7J5Hke;uc4k#Zdan&ND^?U-FS,=hj.=,DaX.KK:e
-%WM=T279Eu/'!,K0!C9uUp#YGVI^n4%B-$&iH0fF6l[c84cI,fOoj4Kc-/9g_nC+X<5u!*D^KchiA]8oq\N3VJ/Sk1H@_S.L1sB/,
-%,>`O[_BR)`)0IAu,n*$UCA183jDutaT7Y/bN&W`8^:i=b^sqa^!_*=;2;o'aMlAYLDkop0`hMuq(o>FI_[aT:?SW.4PV?r8r&3D<
-%Q>IuW+I#'lYi_7t0]$pJMXp('N_O75bVaB!gsT*B?s7=HC-\-f\8.qejlp6&pokf(QR;hs;Op=T^jMI6@Ia88HX&^P)(D_[GDATe
-%a*RZ1h+,mLn;`A$(;(/fQKgUP3J1B=5^u;@G6*.#H))c,fF49;-Lu^cj3(!?87XTgat35'b[\=*jslW=VSsDUS8J@%1=oa_5q94R
-%Km^L.">!?7!g[+F"=tom*(en5'r9!:]OK[\["@ePjTPlb'GiONLu^52T_gDuq".Bi'EERg*lUks*BmFQ6<Wf*lh$$gq_<NEff.o[
-%"B._!bJ<?U:5H:#KX2eJ>f&8BC)#]:=l7@=>r1eRe)-<Y#.BM;_f"0LKt>#^ccF"YH1K(8T5W6>EVY`m]8pTnr%dNEKG-PaPb^\C
-%_H;4b)28AXXhsG/b$]OH^9Y$d.o-QPVECsp8'&iTf70lpX3C)Bn6kZW.-]Nlgu9pJVsTV.(&#*RHFUS"dRfk_1\m#WUcH20[mfjK
-%9%5G<_7Ja8NeIiaK/ng]XH@%-L<hL*Uorn-VSB[nE_OeZV%nYeFVhiuao9VZ>L47(*Y]%%Y)7/+XL</7fD0.N[T$[.mF2(Rrg)9O
-%do#m/WW^`Gh#SWA1f&c5A%t$^DRa)!YuN9$"nY']NeQ"bP(\Rf!u#')%OoZ1)S>8TA5g>*<<;lTL`h;!(OUf@2aWD03B_?b+"?+_
-%0hLG\AH<jeX?qp3=_%ef&u:&.r>%NV?!HGl79F\\"s2aL!^&moha0_]!A`g=Z0c[MJ-VN#/`8)VVXBT.1g?$DY99S*"<#s+aEnfJ
-%i:o'[!;@`"dni:lK+p$N!@^-l>BkS,O4>-Gn8]W<1sqltQ=_(m55^^_@\*[%Kn$YXRt1"5/HXoN>m,8q/OK`mJg($4^A?HJqnU=,
-%,ikdj(-idM]80bG$!*490/B0JjqP@-"CE=f>/^:*Fs@L@8IqD@[=Y?2\\K9bN4a%_)&@-$Y`<$Xj:i'$Td+50**IAtCt+/Ep?#Ka
-%Z31RR'!Dk^lCg16db&Ln/mpZH(YEfUU/5P)5ncMF1Z6oMK,.?0>`e@]]%-]$qIibV@Q[%XE%Q!PjYMfW]MqoH@oHrB##kJuf.Z7^
-%cUbSC!-I%3KtRWTc[\jfmK+#H>"gH3pVe^l,Te4/$.E_^6hH8laO*](=^FWr)],\9V-#q.ik5_^hC&-FY0;/Y\B"oCGssC]"r%F.
-%KnA[h16JZ!8h.UfN-s2R6BTXQJJk5NB4.P3%fqaF:dX+U&-CIh=+a'aRfmt=7(s@)EX%nHn951`JG?q5AHXP<YVCd^T+V\Oo,5KR
-%:djpOEhBHAO<TUXh<mp.2tkHQB"--h&(iqt!5Y.7i,SCWSh(%Ej3Gp\qua0+2[tAB06au+)Y7'qa/kqt'FCl-@B&JQdW<fm4`M/B
-%W6G[i6IW<YW"'Heg'%X#O^Ldg\PSb%3d^,Wjeq>H+(DL2*R,DHT[,fSc4MAl!=rF]I++,Jp$lUt3N)G0K5.P(;e'^%3B2T]=B;k5
-%@2X7fjT(jqkdh+H3*A+N!\t2@+p%#nE(QbiC^"r,"^!F\<4=3Ip#/Vf5QY+2hPK^YL#"%$I+SO]62/nE1MXr^5&cUq4?Q6p;bN](
-%nYas^F86/-)>K>8R)kh2cbUo3.)YI4E;s;+R:Hm%eT<^dVoFqZm:GgfAWMRm2RD*)5./qgikD^7U'I(0mVk[l,kDcEZ/OtO5e8Q`
-%)a>;Tb?0'I>THs5O%lbYFR7c,H/T@UParL3bNt?^WP@,1i%a6X-?)s<AJ%e?]_N$ipoO?E\L9fE=TF[rc6-L*SpO!QV<A*f]AOJ'
-%8=&l=5=[sflh1^TY)Y3Z$6hr,OC;o-H'722L*jf&>UPHq+oE5$=SbsZ59`@[@(3p5mC:J&Pe@F^<#5T'kfI^s!0_pA(2rf7DE#f_
-%*&:*#G^gL@4-+NrgN.^BOT(_cogYrLPm/`$/Rp1**[1VpnU?-mk1XWHCBTpN3YmgV,,_!Mn*o3gg#NQjl1!4K0UsnrV,k@FXDSp'
-%H'&[#2>&JUnp=-tojo/U3.$b#^!6V3L7H)T$crRjmA;6M2[b^2XJ]Rm`55_d@4!",a]B-/-[@qn2n,mBGi`XfI/q9U;*Q**`;4NK
-%?FUD.!1+RVHdP'?%+<D*GTG7W'48ZJl16,o=]=iN_^WA3O8IG4pG.NQo<rZHBW>TF@8o!mE+]uu(%`cVeY0(Bb3I>s4$A3FD($K!
-%aj1t[Fg&0o7pRUN>.se)eAo\tApOqP//^5U_+=DokQXZ_K??W_!m#r.'H;st,D5`i*sk<AN,Jpe&a9^Mn2p9S,u?4RC)V\a*`PAV
-%:F$1%"&-Y!=[7j_L5q\]gr1>^4i3Xre=$bIqt:;i,>+igIPUVPQW<kSb4n(Wl.Hs(+S#>'^g\%W:,<MIJJ]Nrhic6aN5?):J%f<p
-%<.NduMD2iQrSV\%WfiX/D9?B#Hn^juEI(d@W_KrEB%\A.NP.Qi//)6*$hdNg0+4^1%9@N9r!8hI3^9[^#3,2MFgDIiC-HE8L-]<$
-%!qs<o'hiNlEEd(d:1Bb'j!5c6C.sODGed_=cM$r5L/b)6rc%4&n9-7LnaHU]@h82>F+Wn(Upfa%qZ4>eb5,Yrl6AO3e-RH>ii<&C
-%=`<2[V5?^$.h%C^$]+e"ku(/-\9R,l[4O&-O?2LI;V,(>^6(WADbQ=\G7rik;Jp]A%/b4Z@GXKjQ?Au^W(EU`1gETo@i!uak;i_F
-%T(<ArJ2Aia$K0/HZ/.+RVCm5c$rTm:/0MA#bFi%<5<b&!2tglMS\a?&^!kjDD_0bINoZYfo'hBtH)u3ibRY:k(%8?]><(d4%kTG9
-%WM4@(_f(+4[J$?\b@MX<F9Gt'XIaLu#uU6s=.K#VP/W`jM\a/MpZB-1A#'(V#W"U#Q+$V'n)#kQ(lHG<GFJBLk2uej(%;6Kf()Lb
-%_COj;D=_e1N!f#g(+XYJ)dr-pVVB1#f'@TG/dX0Qbt"Fi!ktiod!Hc*Ftmn_S<eobb],Pm=.mQ$5N;;N3VEqtk8t$:3*e)24omB>
-%C88kYP:9BOpVf"dFV,<":MQBYQ.mM7%=U=ZGODTg`d5DePV>Xi^,DcYZXpUsaGc&>hAJ`)E!ck1jWk"cQJqXD!dMJ670'79=]N(+
-%*FTSjq*=]b-3:>7V!WKo%r##cNI;-d1Ou_D/_6+g["<7!MVIXQWgd"-6aHI`>q2;U-f8V*'#.ah6u!gVQn&FMDU,3H9ds3(UFbT1
-%k[4QSf4bEg'YoXOn9sJXH.HK>PR;YhD/*Zr'/(M-/8;<q320U/]VnQ[H2Bs\?P<t%\U$OF"4a50+e(MHcD[0go=epe:ugG;[^M7A
-%r`1-:."K"=h2*MPZX;+rd%o7knA7s^,91"n80>s"go0E>Y,*p]be0DQ89`s6&7/t>(UMS5,-^bHbt_%VRiNk?nkhXkNR_lH=s`*g
-%_"A%,<-AX&TQpqLY'XppA's(V*BDCWe:Re"Z'GT;"3oBXi9H)>\LZ=cE&8PJ!Zp4Xan*RVAm5lA_$Sb?,A>rFVG6:NE$l^I!r`MQ
-%gnPA9B<[=(E(=E%"]Y)X!^^d7j[5V*h<KBt"Vn8Q;Ob&k7,fCHg"J'e34eQ5AZb@OaZ;Ia4VQTjc<f*5_3V(L!Zq5d*';Q[Bt;`h
-%*OniqNO<$&&&CP1p-Si`d8p)R*d`r;b2sq7k;A.'Tc+Gr4BO@3d^OL+L\.`1]RHMfFiSC(HjL3s#d!""FmBY>P6Z9@b9<t.c'KBG
-%e>4:.b-]m"DWQkWiT=;8h4*06L!^lHc\)hEdC]FlV>Cn=A*M;AXAV1Qrc!9[grSZFJ4C\3SUli,%mY]TZZE4=TZd/M'3)bncA5ZX
-%)=I!?Yg6QJ@%)WgQ.0<Bo;(D-1o[9>\?/-[L(RkZLe6b9D=Rd*2(@g2!NV6*^K:OLAL;X0C<Ol+_B9QPb&5qe]XXDF+g$Es#J&;a
-%3\5VjlG-"Do*-6rG3oL/`:Bu+ql&XM\'IXpQ5Vp%]1l-T\b0P=B/Mot(\-6%@@[YY>J"&/fdLiUD)Fr&@jje+a5-b0VIB%\R1W&h
-%(*-eg>r%V"q)2V?qODVJBX!t%b7fFZfMfFFj(AOXF$u)kSrS4KoeqHsQPI5NV,kX7Ihenh3bL.cUUg.TdW5_m`<*&lj8KH5\9IS#
-%M`h):Mp1!q+^?S_/URPul\Nh`A4,I`iPq)b5%KM('6BR-j=Zu3)6TW*c!^=R(:eNY,u6(>>3jX0%D^T#ac6,7\!d3!iR^`g43\n>
-%CcDWca.6h(a1?IPT'TAVE;JDpKPN=pjlH&n7?<T)&=YUP:G-D.D59[N*U2D?f5JmF6>"U!E9:jXr,D\+NAGpPCa<h/RHGP#o1rHY
-%,YZ3753K:BJgMW'JNas@@Lk1+i%&DYl"RUt8HMhd,Tc:2jNk'F_^lp]S6#>Z0<d*s%mWb3mc?9XE3VpQB3n$sA3UbnO)K>N.8Jhn
-%X6V?JfOl.;]4kFl(#\E$IB7oiSi42UMjMR]lNR!A,;-ETUG8L*[\J**C%$rtV#;hsKoqnAG%uL6DY:&\F=>)P!ou.^3]95fQEgJo
-%mgh-8jF84E-Yltgjm6d>mK[.ph%p+Wc!K:Z46+d^2C7A^/`r1#S!'(W?cIij%<BG"c[<Pq@UT#ccUP(h=a-rpD,7!',@ed;(jF!$
-%;Iu*Erc;2c4AP[]msOM8=IqP#E:bL]-\7s3+=cr24,1Z#T>3kqcW`dEhI#\)$=kp%8.AC\fXi=-Gb+4,TZ1OkJGR*&0kq_)5s0es
-%.nF11E*o1f?Qg-Nqt`n\G:^K7(o;@9,4T`.)6ukM21bR$kn]kNrBMhuh!BFnl%*K/JZs6qjXiS#pu-BU/TUZ#V@g5m6&dL:@Xobl
-%^!6FeS?/B.1]VHTL&ugKJ/O7P&WB.1h\\lSV,MMoBNSF\bJ[k<2-,I6YWpqpi$kVnluCkXfY$_Pg%p`EB5k1Eo'JVh0`DuW.,P*(
-%QP6RXT>AG"]q61c$4?n64iYP_W*I%lL$oE,^YSgEUi/30kqe</97sX%HF^q&U-FTrK.Du!3%4>p)@'0qQ>[e;jQ*9-!iN"qo1=#G
-%=3B-mh@MJkN_p<hs-cPI*Z5g`-t><3a$457qpN[!2*]>=l8$d7A(p1C3e(:mLEdu-d*`[G;DF=9W^Oen!hN!n:flc=%/c$-0Rk_<
-%0=Nh>C+=`?\.moh7%Cc^5i;^OC?#eq424IK-rU-)Ld#1=7Ie6?PTYs5gE.64Q<8N1""X]B]E2fBJEh,PYg,i]=fP(AS78Dd=UJ94
-%n"A`I$n.LpS]h-/?)J?Z6,fh4@b1ZAZ2QNr$l`Z9DOQ)=Ka6LEJ<G.i-)\k_\:EGS;rD_3<q\S??pq=Ia3Q59$/Ph:@fp7tHN>@_
-%^<"j0Dh*&41/:To"f,qB,AJ:YBrsVTi<!U:R_rB2%*BVsalFFg]3QTge0t#2<(A_JBOFMBND:C:=?k+GR80*#qjIRE.s>L6=MShE
-%br^/eH0&!"b"Y-fDY=>eC[f6WUXcY2gKf>[IBTl$K_.gIApD6Z^h^!A"d*6L+:TmE1Z6Ye'2U8>,6rci5:qrV%X)DE&5\;F9gFFN
-%>tH0U`IGbWZg9ION!2>jGB4@8>T\60Br##c`erfin7's,dmM;c?LDbN>A>5j?qfm*f!"1E#[(e:b4)LBmK0eT4i5P[&28]8!k.K@
-%"F7TZ*sEbuT#'abgo[O@!jt-TK%hWFTWbAN[ganB#p=qqY<eN&4@TZ0gB5bUU3?ZR;+HWjYMeo-hC_+F3HGIL[#&O<M+R-coVU3U
-%/)`3SrHkODZXp`b1S>.->%cpD<WTBOB;lE#FM:)WAjO6=f+-n+g2aFI^gVf6*!"6f7o7gjlIZhF0jK9fV*50+756#cVuW'Rj#2O)
-%=Va"+/RrSH8"4EU_!>N^qbl)&&)0,jV&Q&*'PpCYKVH_]@7%;#D&H)L'OOsH_sji_G8Lqd'gukE^p++1mq^k8;NZCAJ<VO;'8Jc:
-%S-U7A&I"u+JTWNl$Wa6uMBMD3:Kr&R0"9c\&5VAi!n)9(e*<n`3Sf:b@seQjAt(HL;Ll?7mh[dcKFbn1"p+V!S3^\MXHuiSog(h]
-%)rS.HG;(>^a;/3#,0SUI]%#P@\W=@bd<=:JE9sm$BpIJBf96B6]sE5D+se)e9bJE1qo_#9R72%EV^5\<_NF3,W_u>J_R`V)@(Yn"
-%l!+Sbl,e03L3^#",<HAc:D&eQercDHBD5o+fk=LtG`Jb@nTn+Y@VBEpc`scu=$cuM1pb,fH<f6>9@I6$3`%L$Q8=X;,A:+WU:/bU
-%+2^bSW@:_7U.#H*QE(VN%29AXX)S8`HA(U"%_b9F:o!]\#F]].Td&aW7+SWeYAgHNI^tG4)K+,0fnr/<''=Wi"dp/7Qmn^:aCGc^
-%AK?/P!%IZTC&O`!0<.6:oYhRQ312N>FAjO@%aIQhn?@@cMqR_"In)hEqD1h.LDM$<9k?VX[_2NH!]`2iY7DFh6SC\M=mK)CaNBq&
-%a\H'[&r^r!`MSU<CT0'Fg8@rd*0u'eW@eRW(,0A4n=s-UZ+/.=iptDb5*L6'q!3R/NM06oG:FOMD#3hN/Ks:@oab:/%dq1^O:uYZ
-%H&dlK*/XPnqeW*m"@?Od"f_X"Vk>'nGShBm9>0tQY.gWkAe9e_Nu.\@F,K2W6!oJ[4p,--,W14fmJT<NHnam*(9m276NDL^\W>R*
-%[4Ak9Oq/rnPuE[*JE0kUT_atg4H+F'<60b0m.94@>.j+fSB?lMlS4HTE/Qf%h-[Sn_QL@lDIrK9L;,@[1YjoYnE-1_@mfG]o(k9G
-%E6YLp#tD@'`erA@_IJqLL!L;oNqG&^VX1FpbC&9Y`E#H%4RU6WbeBqk+o\!;IB*AJ<ar)6/#>hVArTCP5_-<lrOJP<nM]DMbi.%'
-%eFVMnp;Mk@X-&N`/j-5U*$G"%,X2t<\s=8EqoVXtAFWP5YgeFmO6)Jo#3&XZFG:WhFGBO$jeNk$fj0VXqst52K%fP6^LD"O%uVB4
-%;T[p$V6TQpPLN]6Mgu5B4E:H[q;\p0jID=A=NWIWO[jAKA@X-hjT?(W%Dgf-RPT"oBr$EUG_f!u1>c05ToMo&AMIam1S4$,CXeKE
-%lUT)u4I&T9k'*)I`;CIt<W)i!Zek_)4^'WX>m?k-/q^0)hDD"G!u;u+ih-g9RVWHmbr(V!KQ`OBal6U2^7Qp!h^YZ"SRKcEGNNc6
-%:QFB#*NW`QoI$-EnA]DVA2ZV<M7(YgOd2`hf+j\UQPDb4[e3,[W*e..0>2r3N60$3VqZM(5)\'#;t#UjNmUXT\fgY2eFG87AodLH
-%Ih-.?>"[H@'5?1niep8#U>^Bb]1[)6Y]s)NZEVktTUGI'?!&!a]O:0scFdQQ6#`E7]%l&[[U^Y,EQ:D?FU`hUF3)^>1=<Y`qZLQ2
-%5qM0t%O\@:%!M9\FV<CR25kB0h<d$YSADb!LPL@-&UT3ZC#Kd7DcZ@bKo7MP'o1tt_:ALPW.`%fRV7c#I7r/M`$m>.!.DB+C4-*1
-%e*FY<Nrm`<37_5j<WUKbZq_#D>QSYmRnOJ1DJA:0U)ST4Rg_thT9C3YnT'=&h]Ig56=k*%HnkK@DrC"\Wu#+#G1nuP\$1DF6skb`
-%_V:PmlOLnPFHr2$,/.Al0LCJc0u&DG9FH^C30n!#"\p&&^;JHh/q$tM^<Qi07mR+66E?`mq"tk<!=_%0ksDB$G5C23'4AD=o2asG
-%/RL6mH-=hK]$p_H)>FE&Do&p-<<+r%gi%Ro_8s<ABj)Z[6#O]pG?4g8ecNj>H$d@"H26+j]Ti?k%S!VX+r>)8o?JFG@HflTaBJr&
-%2sq+N(*A;?Ne>s<M&)mrfBK1S^\*\^$hnfed>>K*B^SsH7j;6KM$hsE3+eqlBa02-1n:[Y)Pd0B%b+l)$["*`^dQa=C*C3`j==NO
-%CHWQ-b(>fF1ec10KN^t:VJR[ZZNYIL,D3#hh->en'J4mmGrhon9@MqjjfN$d7AnG[$`N;0'G)s&=/Us.+K#D4p#Q[iMpS($]fGsN
-%K9RSOFBZ?1gF^4;R!N*e2)GSaPLY6PEAo8!pQ*K73I\lb_>\:qWsRSk5;-&9BYd8*DYBDJOm$bL^nb1icCP?%PCB-_T!2@\dN=4^
-%k"_4Qa<[f<7_6j19b%?k@tGpV>:cADQOTNJ0t^E)?i+Bi5Ag+BCsi?Yb5[[?;*+MO&t1Y%;m+jk2+dW)c\>Ra/Dpi7.fnsEJW!G6
-%@Q"M=C`0qR$asfQb65?s]=jrFTV[:%2=OF,P)SbQ#C,ZK@9r@LFI8[/ZPF<nT<(JqYe"%&`jKVGWcc-mbUQl"S%X?aL3WnaAD)EW
-%(jfXJ0Apse4G$e6-g-(=FrTpk!uWXZC_rbhet9c>Q=)YKLca6PR4HAo*S,JMdgRM4UU8eI!m"Rgh!F**"]T,b\LpkkdGj!6g\_)U
-%F/kQ%Fru!I7kC!M>"6VJI:d</(#:1=&+l3#I\)o"\i$:oeA3\s"[8b[Ne++>@;_b'!s-,F^$ELMaX`/XS/p_1P,31?(7[UE72RoV
-%Up/Ci$L^dm/l4XPC#VQOL?\j*"=ZU2[gJH=CW4pb!QKksM(6fAQ,[9BbNGG44E<K";o$h1#@WP#057BfKdEPc_/KUGfEEcgN.BNj
-%UoDi6ACWZN^j;OnRelE4gB:dEdQGftlie0LW7Jn_@W'oc;V1Z8hsL@X0&pF("?+N2:9,f*,k3:in&k5dN!jsF=7"uPen/VrQPS^t
-%ZDXW=]'2f,%n,lLJ4k6B((tQ_!rG7eFW%6aJR*mWo#YRN^cJcu[*nTXdMEi=><q'3V-UJEX,(6dY8:D.5(i1]EIAunKBD^soHf?F
-%Heq'T6kg3:De7@0`cBq?mB)_l8.+:nd^Br&;/GLn#V&%>+!SGG]GJS?8Q'%9@Ks;;1#G=1)I2VmKB3mD^sh[_!SoOU(>+\)!7U1t
-%_8Gk'Q8uI*GRI)."2CLiI&F9CDUIS<b+K+:Enb7^p'5El9%@ksJL&lq/n[ukG0YY;RoW=r/s%>$QH,^R`$8%Zih^"o&DDZ40*gG4
-%bIZ#I0X`3iB,TBnkToOfb?/Y=dgSPF7@h+"W1r2:F]FKMpUo!(o[XG=7C%R>qd5,qF^\:NZ8g::Td<S%?XKh$en!m))$>H`JiPtb
-%h(9"6dEQ^N/o5In2P3)a?b8VUN5(\&eu^S!I:5hV'faM<qDp(Zr>!lKW0hssI$kcVL7@;Df1Sj&jgK1^YUdJ!ej$"-TTYbICU[>+
-%K^N=V``FTq73u2De].jUa1?epln0+72t8j^"%t3V+%h.6m=p.*PXu'oX[oPLqeTb6f4LFC++o>m&q7JL)[eP]c;q_ulpC5MFN5%2
-%k'i?Fm9\P?p65:`]Ss,S!j:'T+"e=:&eHiiY<:,hNSSPiUdZ(EQY17d(e9!Vhtq+pbYFlpq:M`KWOX0A<@cu;CA%h4YcD8<,"Mai
-%=HY9!gKg-1Vr;A6``SUqDlWr&/PeTn1\b@hMT,J]?N.!Ts&X^Kq`k#G5JR6WT7?a-J,&u755hr,oW/#kqSutBnbS%=p\O49ZGuDh
-%GGD25(-e$(kNS[6H\S(JRUGP6aM\$k\t?Kc??,m%9*%'6%VU$JYj+L4Trruqf*4R+?sXB>iR.o&i>s[(Cseqa/qMKQ$&Y+IRE#gB
-%:+I)__/@r8qm88X+_$`H?i#GZm?AU:ZZ@r3oBj,!0%/E0nQ\M]`Qk5JP=49u%l=1R3*L'*HuSDe#8d)V54$Fd<n,<4&@B[\,-nYG
-%-F+GZ-50NW,$0,[Wn_LKb_JbdK'&^,DquE8eS#\U3.r5fgeHUeqAic6E"c*mO(k4!P(U\H2L;Y:C^<h-'!g?g+Z4C!:k\N=e;jo1
-%,qeM/oC(6>YCjOrNhhIuni,de!BmV'i+>8*#\./bTE]AmHuWHW)N"d&+4/D(<A5g/5Q-_5Lo6m;#9Wt_UNgnn[uKK$IMaFj_MJ9U
-%"h*I$5GSZ,K-RL#cpUFkUuMUeUfCbEoLT4%IfNJdLo>a>1=4Sd:u+%[_$)B\.b441Z"isQKSWgY%7ca$Sqf`2[Xj,<!lQJ,"@Yj0
-%PR8\hYlsD4<6`,/QS$8(<cD"e^E>sele,m*@'^]Y*,OX8fF`>,>2ff"D2scIBZd'/#$7=F`rn@uL\0rOV24miY1FTb(0YGS@V;%7
-%[kf:'l0(g+$3b"(")sb1pL]k0gQN)Xe_NYN=$UsQ_R'R"XtS&"a"G_kd/d9`.nC8k@ak/UWUSV-[923na@VJURN\`'K/5\UO_o5)
-%dL-hYCQa"k$V'U&1?4k9@E#(Jod$6\$3pbK6sDAN^Ok'r#=*7cmLlcs,-K=i^m!@.QI,=aG0F57P"t*#g&^]s]j%'sf0_elQq8jR
-%Eq\H.6up+$b>Kd``kmnd=@:'`qlO#8^4I<H+!b/lc9]gl0aS`N(,#A9c1;"k\[.stfI<NG*Fa6YqFD4S(dW<:_9m,PC5^[9.X0m4
-%[iYF+"TCKTd=r3=lW.R!YQ?nnOd'=pEGQ9!e_\phE4cHYMi79!^U%mfU-+)39r#0>:uU,;=")(HBX=8k`3hjp8J+SBBg9Ca-+D8@
-%8&P'FZe.3#SmJaZ@Sm>pNNq+*2EA%a,/d^1AI,5]k7^2;n,feS:.8F"oK3Fd=q9>LRWj>#8J5:dV%/3S95!(<C='8I%k:((Mi[-s
-%T2qcEW`LY/Bs$^MWn8[6ZmJ+KBamM@XT+M1LGD.XmGVM/DDr8b.9gMBW;B/pg0:#!@!Y/q5njr1_UGgN-O%XgMO@2W#GoaBMkk7p
-%eKJBP%2E`-o[b@g=0<"Y/5]-W^n]uFYet^LoQHksob$2(kcSQ>(q@%J2je:hf.I<VEOr\+!PpU-&]$#eLEc@%nWP9bW2ogTURr7<
-%5:r@S.'_q=T,-KP/_tnSk&2G-+9d!^+7MNQ5S6eJ$(b$34J=hj&Kd)Z4Jbob;(fMmLo1@b5=stp/J1[pa8?L0,SKCDpHO$t9(AFc
-%i^S&&,&YmIDbkh,8u1u34idF5&PiZnI[VI6+s%%ZSl1V3dZd#8T-H4=`dVAS<>=qe<95S-aobWO7=7Aenq7),7M\>l:MFC3da-^I
-%C-o^7@[e_Z3"L*k'QH0p[.nMtncS,bY9<Kf!K2-%'Q0LQW_/gION'^$:ob<V=jFVN5T:C]SrsMU\]Y/NR=^M?)2#Sb*;)*/An>mN
-%)%EueiH%%lIg!Ud6kOL0j@Y$I6bpTW4-FOcX:<[%l4Q]5WfIo/$=BBd8F;Ci=^5-s)0,50DZ(]ceoBF9-@&]B,"T=.6)?T*eFY=o
-%5jQH=TGTX3inVWYk[cj#b/"KskP5Lm<ikl#X[e2*(_(%e]qFjdR+(k?qr*KGM7tQiHAt'g"d_X7\+IS+J+1jM1AqE\OT7m,]&_/e
-%H)&SseXo<-W$1j');U`WU)`t6"-M[mTX0fL$)CqRQG*U[mDad3@JsC67-9/QNSj1g>("tsN&r=-;LYGjX)/;Q,teoT,Ia26TB`!n
-%PVIQ)kMT"&-W(sh1d7)kKnpalYM6oSId@P*T<W^%lr!+R^5oU_]'Cbu<-_uSrB]k25E@"CkZFM9@kt!eZg@ohFqj,22"-;Rff#"L
-%I<'nf*@L38elH**n@I)2CO).]:uQt'I,>$M/<0Uka!U^9iT5oTdN5[Rq&EuegcS@B<\MWgY4dMQPTkR>2"W61W,hu;"PGdc=-`Q7
-%$H@DBY=u#<*4b7!d4=JVR/<R"3<h.=^u\bJ1,&?mSg;EVgYj>[iM51C&@PA4N%0C.R`.`[J*%orQk9ek8Gp43;T^KL+!jT:hsgg@
-%'`mKB"R"p?[QC4>I1DcYWVPVcD`l(UJ1#p'7LiTN^V_>X"2]p>$hrH/]idNZR'_pV%Og7f`X#@E.,<N.:rLiF$m2ir\@$\i&Pj<5
-%4DcD7cut!br_/N5gs'<qHU.[.Rq+WuVt&,[K-EKmeFBoBa$]_7MKmi+jCqh\LDD-^ib?;n%pGGbZp?DY:Re5/csGh-'amGmD;=]h
-%`QPA(9SbsJMDUA[iJ]TX;g$="c'rS9AtraY7DsH:%2,g<VdQa.#Qco-=W[9_($oeE,f1V/[D4eJ]lNP3T_HENkfZ=*:V-<`l1aeF
-%2irmkTTdaOSjO%eM(%A9DFRG!*o2,f;2!HuH:+ML%GJ`S4-2S(mgG,L:-)uE'pg,C;^;mGK'dYU+BiH$cRN4*O7L3P*SGd!5c-NH
-%4Zcc`fE.X@1rR!jXh[@om)*n1-DM:,-=n02i`nCJ8jE](*fSF9^3@mjU@BVj4'GHn+?X-HpTlYH^t'@)fDY6i7>ru6,t,nPJ9>@4
-%r@+ZdVjIX;fIXp]^#/t_@K9mRf5'SAp)Wd.#RONPBd?-c&*\Z`lqKi*/(h:.PDH*%OJY$?ri1M#WJ8gA[7qmLGLo/YPTOL%>5I4F
-%iJ572n3"X?cbtbtXKQ"Mfr\6?@="(c3'$c^7ZlX<3f<RfenC0CE#e#,4rO<ae^_Zr5g6T=qcP3<Ai[2Qm@b(g,b[KPRNse#Fn#O!
-%UVPd37W1_qA!kK@q`[G*DKD!&]4pE.JEl7)1uSWEJ`^fHV<&pfB"oT@>AI1=ccq9bL'@):3E]J\qI!1P6kS$D^%M<8^rmuKBpuT4
-%Y<NZOEPYu4dVYKi`A]-M?3`r\A&m`RIYpQlbEKOp"<\jTJ#EUm>*M:g*oJp^\tq&Em)K7R(EA==M!K<F(hqXZA34M:N9)IX/RIXL
-%rZjQf9aMQ=NK/X42eu[6@s2m:'t;TO#C:GMMr,@bWi;!7m7A!bShRCFATaOEPC?Klnk@a(p)P@N'+a^2H:N6Cm,a#)e&;^F5f&X&
-%!%PJm/-F3b^[i"VDB03qUmpR![!SeKI0\h*Gj5FAV\;gCj;bZAPgB]7qi!OfNJTnc.<@7@Hdmh,lU9hFV;l8nreV8E=XJkdG:H`d
-%QAQKq+#J!&c%"AY+6a#\f:mQoXWJ7nf-Ffj%n':0^2.F-CDMBK]<4Y9)1.EWe0hfC.N^)'hOKGB<lG3TeXSEYU$En!P>N&B?q8]0
-%)W*jcCFq^*`We4!I,T>@>6df#2>;>"@62=X-lYAf=NAu*pr,bP,V%Y<<kuDtCp?7!JEO!:6hA^A)^\Ia.T\q.9dl<;#4O%F['It#
-%;sp3`:@gSc2g?b[kWZS.C0JU"it%V*#31E]!lkr%?0mS5_/R*N7raC<r@uoV4W2]6$U:"ZOs^ioDCA46I>]0cSQ=;#YpOhmkgLW%
-%@!O+\nb$a"aU7O1Om<t([5ps9Z*,_r63J9@i=D&f7)/Y=Hi3)sc?1Qq.F]"9E$pI%`KK,d9f0UV;'+Q%G'X1:'jVGE-+F1>f`j]A
-%WXr#SH)QbpnBKE?3>mgrbG&;<`ABQiKcsT9"gZ\)&+EtJT$:r@"MAhhod!f"s(nsLCm&\`m0EZo2mJeWmY)dl$h9+3+,X7poVOU-
-%"kEalgfDI8-b)*u591@7'?,?bM$k@odj&8XbY-et);PP)0*O_BQ8Dh@O;l@s'g+I4]rD+8?mD]gg+Sm#aVHS5U/:2%5A2:t&m1gh
-%mNa6u/CjZ`?Flb3,>&)M/UbT)0bt#U?n)VYj]F%:P')(*$'P+*Jf6(SS9#b8d`9lfBg!4K'Q?]d=FV1TalrO'%.C=sE'=qDc8PcN
-%JA]2Z?AA[Dg%YutPQIH:!2ulM#*P'AEZ*0p/GHu8BRH-6&<RN-ZTUU[XMCA2L8^3\ZtjZUNY:h<VEpA=IJ)"1Ch#[H0q!XjjCmkr
-%,+s[T'N>Sb0A)53=YFIQ$A.raU?.teO;^*;b=.3tXh9T*L885@&"q-CE3%on3j"[>Jn8De)SWJ6[r$b635bs42NVVq=s@>+=nXYU
-%G8C7nKOnt-`e(U-8L[?j=,[mGC^8].$CZ*qYeu@R=L"P>iu%"c"7aWa"?(8^^Uo<s!@?BD(9$.t7tU=]G/iq5TP["j\F,;eTIsLB
-%0C5CP0&)kXa/@24RVq[$Lp6';?up9gNE<oe%'PYGWt5:N+bP@p=g,9'j'nnUp<(+Z5)[Z<==pgN&\9h,\G;+4>C_;Dpe!Js4%/?2
-%gQN_&C,`cP=)1BVTk,Cj<22[ZktfX9D'0$JX37LA)>+CGLcMMahZ-9OAm-mrlFnBD:=s#'[5?!0Z4uH6j?Q%n,iApteT!9F2hGFQ
-%C,Lb29I/8JgXuC.RC<k]`mM1M"'0@8e1\2t()P%BY)oQ^q6@PSV&U*PW8T6EjN.NH([Z+sZTG["0hMX/P!.\E`Q"FIoLT6[7/D!r
-%T+N::T`qdTA-T5hLSa10c%70-,<.XB9H!JNB=Ud^+X=DS1e+@%W#oEkE#"&nb*=WtdS0l"2c[(c\!'$7doh['XN-/dIuJnc@+:<5
-%56T*!4A&gGkW'tS=I$IL7g8*8dOhb5@%YUnc2u\Tlnk[PZhTboKc3lMAkuftYT#/gbBJB6=5[fof1XiJ5nt%\;`"!'TV)nd;YNFm
-%UZjGTYtGFoL\"X=K$2Hgq`$FL.[e#Io:4Dq:r/B<.E[6+>8r"MI*@Oj8k`jTV8H^%IVp`oYaeO\?@c.V.4;$Ea&]1-b[sXl\)9W0
-%5TlO\i.;`mr<VaZ-9r15KDLV%+*CK*J[d=n"FX.kiW,U/P8sscfR;,oM3^%b*<VD0&A<"Ba3jd[#jOMROqKF%l/d]d*J;m;M.?T-
-%]#.P4=E./sKs"O?5SCDR\g]l1ViOl>Z%=[M'\&1;aJ>n%JW$b6,Pe$AFh3#P+MZA/N05aj_)Q)g#K`rp$^H+snH72ukDmb>V<cj;
-%lcIq+AkGYbKWJq2hSlQ"8RH1%k@eKp6T2B))i;r6@Nf3idp4Fh2Mg#(&F0>dqDK8bUsl(A#uV1&5Vg'(7b"*$I'@KHkPT(QZX*iO
-%7^fZ"^%i2Mr<G3QJ_!49OU+_P1iF<]r7'K?kYD,.*\d]?M@e-la:u#R41SHSqkS_#AiQi-GYg>2H4-[>=9bK7\P0,+f>"f2*'.NP
-%Z[sn4@B9cthdHmX4Pljkme5ecf%)E/<r)QmMFFbtaR3]g\n7WJ78iQ5r.#K:H<M`A5]dX?QVhG.m++un,hU`c$!*DP5CD$ih6a8d
-%'l;DA3C)Fg[@EfbkS$@J#EoYKOU?+EVs1&S6\FJPrqWG3C_h#bej[Bt;T^2F/g_=gEdYWI3"d8^rpX'CQZ*^NE(=c'K9X'ER`[;[
-%k!/>gK_Gb]^0B`#N&GY@bH:C#D((\#[tU\UilAJY`HlhTE"<LAQX`FD/YjqUlg+j$i"fHk+.7fQO$f2qokR?Ss2:p_JQc:L0rU@1
-%O!9/g19q<$-)A&(%m<EB1,:)9ee#3MdeBCKCiPc'+6aR%HApnnX51l;NfgT/GR!?IUf"EA7Y42/^bhr[&4rt*Oa+1'[$%;\iL;f@
-%hct>\+k*N;MTnXcC;D2"VTH7gA\=-oPK3pHKl$"BThD1LS;%/WMV(4SiBQ*`ZKNn`8.-M.OL?j+LSV]na]Y':]L1B#W!Gi5KC!/H
-%&1)n,=IP\?$uVX#<lc3i2Eqp2#.J.m1LbBj\)L+-J'hS('_[c#*j(&.o3Lu0:,IIJhNeod7<jQc'Eg/<eT6L!YbJ@3!INKE'=9MB
-%9rtR4%BiC4K$7+?=bAIkVkT-j+5Zo#1b9EN^",bgDM/=2!\sYtPJjXDXDQ/6j(QX[O5o"D!Xd0u_WgL8s&Kt[8'M+BhUohkB=Z$@
-%`N\W&UN\.k"B02sjNrO'\Jr<=B?f,=8m>Fbr7WBXrrP&jK-I*`]5dI2Me*2GB_Y1be347RSpab1gCZHjS(NFVm@<p?Z.^+@:0&g6
-%Vh;uZjWZ6mn+m&B6fRhY#Hi98@.p`[TLtRQb-+!PY\:B(FD1[P_9^?Z,RCO4,WD[ADXf.9#LaSn3GRK_+0^8,SJQ77R`=*>"j99O
-%^AAGk.li^`.j-@/]Hj=F?,Xgjct`1I!>hh!LqDt\6-YpqrRNhu#m80-\s(Z:nkU]J2Ge0f5-q6nS"Z.<Ka;X12l%rB=@S(R`RM*Z
-%$-(4Mas_kuJEquFG'`?[Xe9mU)r`<dY$P$EZ,dt+XVESkc$-*&*%Zo7]jkUDj6@/PDoiN&pX,1KQ_"@I'QUY+aMegJAih/f$1M61
-%V+T^7Kjq`5WK247L!?c[ZaLN;+1a,t:9UNc+RNofb0eJ@Srdo^8JGHR0*="i8l!l5.JGkHaRhRcPLp7[cXZQIA%Pm-!hurP<gV3a
-%5'!o?8"uZ6*^4moRWi[CerB:@1kV)?Co7g#U'DU/>%,C9J-.huWVJ/)Md<\L<dOA(]NMrg^fCb2qMY>\;/5oXSL-F3SaPG#Ea-j&
-%S/QkZ$]fC=;p#/!iVCSPUaW2K?W*_4Z[Dp?J5!HrH,[S54#dNfgV/L5+4)$-_;Z769s_<uIl<3p:Hpsn8VG7r4oH`tT?lSIoIN%K
-%rXi-hn:9\2Cu/>K3Br[u/tB85SCc#hGFH:M#)c+b9ja-bF/Ji].MVa\8ZC.X_6OP=*<th\JCQe#qqRA@XasP2Rm\qCDqGG?ml=K=
-%$@_<1VCk(IC?i2`11qP9P(:qjEJK609WOrl8]s;*DR=9PAe=)/<^)D`K%b0?/.XO]`F6n+88e1aA.".uhKoj%L`ig,3:f^e?_[ld
-%f_&>3c'sI1%jXqBm2*V>9[+B6FjnQ!^]Ik/f[MFM4)'N'[XP"o5,3Z[SHB2ZRU8K?d3*W1J1k3^,B&cHq)eqg0gi3W5RGi,U%g7r
-%3_Q2JO<"mU9.-Bgk)L3;8r^2VPWR>pKH%'S9a=rJ65U7=LaXpBet+NCaW[LX3Ib)8OC?9(X2A>D'=-6__:8iUYPb,+<L]i*[LX&q
-%M9QtT;+$1QD+:mKmO@?nl5Dao^/JU/r(n;;Gd(`_gm]8U40`XokmMc\#oidRNF>$Rh2R6h=MR5C=c1MY%jsN&Vl?O#*Y+dt62+MO
-%BN9O1%C0UQm^k4CWGa1F=8uO#5I?4>041WVMR"sEUD=F/W+^Q&/9PG-LrLkXTfV>A>9m$%^'`)?_!&b1J.iY+hTEZ"e931jJh.g]
-%V;0:EE@<\JqDA4&a^X%!s(m@Dk,H%^s6C3?WT#I']df#"ICo&]FTtJ1bGGPZBP#o)r%L+_S,6#d]g+/F#V[M4b:d\'g7dFaDao\G
-%lk#jjVb+hPn.8eg<QVs6Q05f?,BHQ"2r>"%]Fk6Eq8!>eeBi9"9&m/iN)Ul*bYbMX5:k>SM(2!rkb%Zg#t53P`4dN^^uVWC$R2[>
-%(2_Z(1#5.?I25YS,SYfGH?G>9Q80^n5<D2dA.TCQ:>:?NJ=dH.,=^qV_%fA7_[;utMirROo$O#'kp(i@jg/u6=i!jJ9qW]#3\.[;
-%&7WJ^g_r!TALcJCe"UlMKi3>e^V^0-8p$!h#IYF>j3Z1)"LM[V%m2<EX9<gk$Y\4-U5D>GVu<9'KofuT@q?Dhd('hqQ`DB.[&?mS
-%+!sHuk8)Fu#5)Y@-t(ekgQD//q-d$/CeU`S52!MtUdF7K*ZOiiPk<m4UP!e[OjKgJB'/Snl:Zqh+0O`*31=.%&r9e^=IE8WBlo&#
-%ZntX9"W2+I.)H8ME_A?bXgNRGr",f=O7/K^8+DicE8<s<"kctA2qPmL^;[t/ns$'fgWW_F"LPk:771OM=`AO">X1GpIsa#?p9eqq
-%Z4A,S%;S8cR"C0\YtEHLg4(=edrDGt0A"==nF:D$($6U&NaOlMU^*V_=n9XsK0VJ1<)o90aMj'E9CU(qfS+U(WPh?bPA+`o"h=AC
-%dD?M"OaNY,6HM2$$fg'p/9[r@_br]^"2j^HgBq/#EnPYk*/0-A:%Cs_GV+%n;YRT^Bo#U^NKK^(/g-XW-4k4Ts0X'':3HZ'I.L3g
-%2m5BVj[Kc!YDZD12RER+^5R4,Zo,:N]TjA,@LH6_^U$G(JEA^&XqT["KUT#.@5e]jLsQX(<Y!=U5Xr)>3I.0KH5r/&kRns]=BH1&
-%itE8G5mrL?nokZjQpg%XhG@IX)/fY[RJ4o8Usjr"&dr6Z$rL+W$Y-Z_()H'&f"tO)<^[O*h3_C6$BKmkI7I_IYK[E#!3Jc6.ljW9
-%5]:/jV(8/Bc>DaoNnp^/=2(X)6pSb[X)'V;#e0)h/SX:g>'?JChe4$sGa$u*IVA7>:MiWH;/hHN$XuC5YA"H^`bFC3YT]B`!=lQa
-%8q2_i.#G'#Lf1A,bDl!Cpf@4.$4[GFIo['2!BR;jX[srcs6t,Ple<XD<Y=8Fe]\5@fE%E,2L.Ck's4n\'<JUcP<7-GjB@:pX]O2Y
-%U2]V.'&m'p.?t`^g>S<^muXomHDVbmCmCNL8<Zn7igl$\_87F[-Y`P;@l^DH[&rs4k)iIaUP,s)9%G_"N[A"ni'e3]YY,Bqo+).I
-%%9+RI6&J6qX^IgAR,+,4ZuT+HND8=r],&A-&#07N3H:?[E8_+*#>7O[2*V^QMhqB\/EE'6rS*MXS4EN,j8&j>He?$FY`cF90__Wt
-%HVsu1?i`47aJuh<XRAK=BX^"&.4,7:PMV.u:#8F#+JRZtC9\<=h!+#g&DQR3ZZqH7-./Ec-^n)K?$k24LaAU&<7m[q@"tNG:G4ZW
-%E7EQ<1oDh-#IK$'e_aEOSb7VIZ<Y.h]]h>R4QFYRV@*..O+)=aDu8/aJEnb^B'M&J(-e#c>T1n]-8r834!)ZY-_TRpBVn.MKg`k!
-%ieIu/Uib7t/.ge>34r,\[(rZ&I>F$t,*:;(UT6>:5E'"Q;gs$7l!XpK_b%!:M7J'C>hqAsUB-m8c2]SN!$VWe6+Q"9&/em";Xd(P
-%`I/(J4Y=\;qa&,n@sV=>0i-`9V+f\KbV5L0nqn=p_.9+M\pu3cfV0-WKle)K(gjgZX`G7/6+Tj/S[KkClXdI(53<;C:Fmd@`(E5#
-%QFJGY/c6<i5_1K7E,F>?*M^rkZ^/OS/dsik!_LS9nTOe<<1a:TJ"qVinM\fYVYkWt%)0[kHfYcTpFQ6UTR*;lc?b.(fo]+cgiJ'F
-%:VY?r;8(=e(;!)9K:8lt6h7fdUUFD0K8dM3#0N,iIpHA!Q3>rV`_3r3*M+L[(Fs0%C'$/#[^4#]J>mEm<fl\Y,.m^3h2iXRg%7l%
-%P.Gr/:_K9dlt(<jjU5+<VGD(TIIQ2s@)9W;rrGQOWLLGKLj)Tef)p7-p,u2&Gp;"q#fSUM62%K*5CdW#$B#:?==q([Q2\JUK!()/
-%@j?b6GJ)^KKQejc0'9'=r5GR@r?'Y+m@XCO`<42Zk@ONsEfX=LA9s+4Ia)@C:U/mnnc&CWH8.>(iCc5`*eNi8_;eo5!HWZ7/YI-+
-%gVGrJ'57_#O(oUu58CG!-4s>ir<FbOTe)jKT'^s@4o9e@c2sR;bBa#RA;faYX-qLcNSR%1L=$7;%/a)aajqdO7+Cu5Gd><%LNahX
-%jRr3jG!r0LV8nMH2hmF-^N*tU[\O%ffCf-7;]`nTOi4Jr8,KYu:F+G,I!Ri11rDhueMmNeZl"o&J>FH_V1o@kooCQe61@$*R.G\G
-%blUMW/>)gb\B@!Z,JM,-HUGofS&uW8olMiW+i.o*?<r$,>]Bkr-XcWCked5P-c.<aBdi2!^A/;tf[^CN2F=ZPF6tb\]fXAl]i<>u
-%91C/&7)Wi7Rl3F_?1)PBBnhc5.GT*@2gt9>OI7NpFX)//G&iqD/^FNqibJgu4,=oF&[Yfg]C%l,+\bdKY6IZfjad4$j9P)NA`0D[
-%_!GSojC=p3U%k]/]oc;:]g9RT*eRodDE9JLMf*>l0[Nq.Ge;8AqoE^7JYVh+s'Udo`aamrcc3Wr)7`d4a`oir-q+#rbMH)D_35;'
-%:RFJZ@6IH9Iu>DK'A:8D,dj8Vl.aL?(;8lON0KE>:W!^7M0I;uTjT20r=ad1RGqS&cuWt!oN-P:Rm2;s`F&Z$^3t>-mC2!Op5cua
-%a%ua*5Q&FfIf8NcDu]@ZJ+;d<\OQOAf71"(qpg1ErBnWns6DoIi=E^&rGV]&+91iJ5QBlts5S$Is7a;*rBL5Ef=t,ArVRJbs8INC
-%bs24+T>(9]^\n35qepr^:]L>3+MW1"LMss)Vr,[os5IVeo[h]EJ+]F?rqNdKqWm$Es8KLZJ,ep/?hr%Il!IcXTD$$Kor%,*r(kqZ
-%r4a'?T0Ag<rg-F\kPqr<qF;.e^S-k(q)H;kYADSCDXbZ9IPl@#P^;MahU%;260ibYR:/HbqgsZWfJ5"@#g&nrgrrnc&/_:@@KVq_
-%q:!<K6l]?k)BIEBdR]J:a1M\l^+=Ioq!DY'j!5fi9tFF.0sT?n:\RT[H.uQ0s(DLQe^8$7qR1<eJ1ud*r#l-L`MOVG4'<Mo_Vi'%
-%!H$`aom[*W+_i3=jT3YJqa%.+FnSsZ]TGn*5I0OG+J_ol'A<=Yetk'"P!`o;bn&-Sr:"?f^cd*Yh")TD0e58UXbc.Uk@'q/A+6]T
-%h]@6&7Jpu05COKRp\TeC-G3^[n*]EFqQS[?UV!YR[tc'R>(3pF+.kGMcMqAJb^]52\_cW_J,G@oct1u09A)>?B@Au]n$.N,:+VZK
-%J58<Weal!g$.4"GVNk4.8D;K_$I&B?#-2BmC@0OXa6Z:ig[l8P<<Kf*[9_\]=@\5]_:Dr:LJrMFV6J_/07?n:<N9l.@Q]ZB5$taX
-%4'8P_UpANsZ2p3U9:;;)BW&+6cY3)p62'?cBeC\.@tHe3cmT^pDW)IGXd4k^/\F4<@f=iY-L`iNs43,=hZT%nY8YC=.eTUh!]?&%
-%iLP=S2XS*DAbgi`O]5L^[sQ\l5eR2,KE:IG)EZEe8=Q#4&FZ"e_W"-VV`U_@kf*u]oH,#XB`0bCYLAAMobNG'F*@&R.EBkL,8<5@
-%$VR2<-cCa1petbY\p,^:U,f/A@R3#rF?ceWjVFh<nX[7a(TT5P?<>PArcI=5OehXW;C&j&arnM;6(Pi381%AE`uafC)u%kLL.Qt*
-%3jE;(TR$&"baH@$GtF<HUE$-"EHS<0deTfGc.U?.W"e$;>qeN8gMUTZ-Qr5:TL+O*P%9m3D@_8j]n/U\pua[r(.OIU^c[7"dqlFs
-%j12Af<?qgUbkj1E-c>^r3$ghP/T%4kXBVT`6n,$Z>UM]\\_,"b5c!pED10"3h1<I3M$>M8PG%:G;R`GKHl@?[T#J4)/udog:#IiE
-%1q++569fOsY^=u^OdaOJc`"'=7u;jZ<q.6,4VNYc<a&66-SK*RhY^h1Pr$V#ea]NNCt*FIe"33RU,RK^ghGSnBcXLlF;jsbW7fAg
-%,di*_\:M9RU>50D9NLKtb*q.JMoeB9CEp#hHA3V@do^qNNcj^8<:4giR_V%<$s,)qdcM:ao.roQ.V6#80@Mrm;Sra'VPG]XALO@3
-%VfC`?^9iK+-cp?%W23Png04]@h.Nie^/R!9[".o>ZdgMnA7u+jKRe$aceV5`UlS>bo,oUtE[.EOBL1,+((bLQ94j=7;^B(LSS'0#
-%hr1Sc.*o6/gK:-TWCT'JC2a9uBGd^[N-:jQ<aSLh*VB1J<%!p?Cl>_H!5[a3f*GJZ,!/SnUQMbmJU(SYB04BA;O9]"Af<1HL$`hN
-%Aq8(t'7<t]aWa`VC\7#2$jaSbEZ<"(OiL4li_km:mZ[t`J):TZMi.pYkNkH!gV@[1c'%f1lf?k7D;Vi15?hF<fcV%XZKd5-b?!oL
-%BjP*p3o+BLm0Qa:0Ci6,QXNrE3c5S_X?hOH+KWN"kkJ99-$"<dZ;88%^;FaJgrD=c(Ze)gFI&8qJ=1Upr!i++OCPfYPEiV_Z%ZGq
-%JA#jA@a\d[rHfunh(,J.OWQ#$BNe93m-r6S&:T-3o_Bo_&QgB)+FQfSI;;NjUT.JhCfX2$&V-2&C,8r`qKgZ]?e+lK>M/VtfGZhR
-%8B_(dS^8pRGV@q#jKN0SY?9e]ZccKo^_s3X?3,2:9`")HX,.Y/*YRA7C>CoWD5h7>r+Re92pC[Ce^1_.Tk$H0KL$(u+V.n_#bbBg
-%jqU2spM52b.7ddPemb]=Eh)bDa]DR6S<Zb,%>I'XHBosRPV]*'+A,_+;J.-[VR@;(`mAZ)5$SN&Qtj+#:r.L&+3Gun'?-&B0.,%[
-%%-8k'nBajSOFu/+cn<aIWdn6OX=%7ChaR7;crMu>pn/V/1p$CSn-s@Z[T73h\d)!O*>L8sUh2^m"s8!.)Is?rM&htk-AcB_(hS0r
-%YPMWpdBKR'(jr@Dl][Gp+e/-[W6tBLpO9(io)=O<d"m%fOAlV4Hu@PKYL-57VuYDUa3/nM4K?/R_[b480;_:b^>iYe$2X@)qO+`'
-%;U0Q0CJb#=_fHsnjdRmUVV/\QD$3WfLO#hLgSg!co).m/1%u\kkf'=jh0@MX<d^eKGAbpm[%,4%DqX2GTBd*`ej^A#4<n(hd_Dc@
-%mQ3;P6%WE#qIr5:Vs7_p=1XN(Eul:KqmTGmkMfE<(VS>t3q_BJ>i$L7NLnujek&a(,q+W(p/Ra.Yp"Tie:/J!o+2Pb$LM-@FS/'B
-%63sPf"Y#)Bo+G)F99^1J"%i%]qYYAPpN_j6i&6X,?cG48YNS+:o<;hRI@Z..Rp3SPK9sJ<[L#0VE]T)4ch6",,JU(no6%`=MjB!m
-%dfpnIj:Sg-2MoOm9dH'&;>1/eo#^!t??LB4kR48--(RP:HX'q@TYW6L?u2")Q1nWm\-t=WWM+O%RQ@=/:P@955//)07n:k#W_&@1
-%_WOe??D,'e^er/Qm[tiqS5<L[V3IER7.Ne:[he,son(7cki,AlJfS[X.#dcI'*LLX9NShkR>!.cDTj+El/ZMR,-4Sp"t.N1[,P\>
-%?2G+6iFuffH#^VVd#.h#cbM^cmGR*kY1B:r_kGSqq&rmRC]\\eo06Iu6H>PF2G&nXNV]%sY(:JQ;FX0ArS_Ls<rV[IXV$9-?2NC"
-%dlm]tU\!EcB)^neNW7,^^-Fo-:^"Kq<u^![3:e6"K.e<]&s!k+Jo0W.e+i\oHMdu]]KH.%hELkK*\W:o4J$cSStD$]+!,9[a5E9p
-%O3GYf@31J6kJu?Diu\$Xjlqg%p>PH:Ge&TTn0n,-fQfS8DY)cmF.5Z\N?0a.<ViXMIs\&"^O<%$5:Fre51I+bYJj<!_,0n5UZ0*8
-%YRB=TLUW==NJFQC)NT6-XjMoplg9=!m`>t3jhop@nS2G/jLZG)h`a/;+-5M:cO]QT%o;-(bC01B+iqFrUF.-G"G?KecO:'Kc[T7d
-%aJ+OK&JAOeofIalRLT,b_a=([h[p\\!T+V1iZ,ZW3+P%Sh\@4'4Q2nS+C`4ZcOUVUK^T6\R>C;='<-fV#o&eXmg0_sK^T6`h'VZ5
-%_F=/L^FN]6>?3s9AAgq,*C1n`nQfQJqb"URE5W:cB8;N6@=D#AaJSGii?OQU>lgbUF8.a=,c97B7hCMkMr,+9@RA@a"Hn!Sh[rI9
-%&`4<so$!i#+&8Ocn/VNUAq>D$8BI&pIr8*)1IZeB=NU,N^FQPL22=CT[,h$f5<lYg,/,S?A5D3s!_as#HU:E/49+(Y';+C4%l;m5
-%Hrlt476Cl60ua,RJk],6Fnb]\$iFXaIA8pmkIS?D%c?=AVM(T/qY!GObWTZ)I$]JKZG4:GBd1:78]db+45?&n\],PdMPSpt+0+=7
-%q=B5=SAW[6fC=[mNelNk*sr&Jc0p/\led*dleh[/LL2\`Xc^f<rTE:J$B;U$#`:_/J.#,DO-TF=Rh6Bt'0Y%ATfH\t\6:7SjHD#4
-%dTE/aFJD$=dU&U;IMj.-Ls;ct]apA,CYb-[OF@9n4M9-Hh["IAY9rY\:9ErgC8r-H:4JIP(smFGeaC[5;K[2Je!MJ9$-4#l9<2sr
-%Wb/gKT#&,G<I"W"V;L\JT#QBZrj'D[93[W5h+GRSeC-Om"i_>-V6+>N3]59FIr-=$+'$06o>VffUroPUa%$)&JV_d#5N[T'B(C!/
-%n/?.`Jo'N,L/dPAd]AoNg4m?eTED_V"GlsO@*?+:kh.^NdL61XWe$-m@_hjem/nIR/i@6'FP/)DbC0mQ3,+1b[kOj[m$\t:T\k@&
-%)a%>IXPeA@]\N^J"gF#77m%'dON1B<E;C!_BmWX+>W7^R[8>\p(1?)/QS66hd/>-51K12l[[U&c)Fr^/VRJ7JhsQ;)&1UW]V:6Pa
-%`M[*A[02l++C(pk]4\hp`_'#-d_$X8@_06+-9uF^^3I8lF10=0LZnA8ZST:KSsM4a61:$f%:/`?IBH1dHcB:Ja&Mt[j#%/K.)G%D
-%cRcjr&YW+]/+3uA&Ff0HC9l5?a!]W`rricLN01]e[L/)jDDYt:hK?U0Ci4BjD\kV\GO"2S<8ur@aRkWkb.>=/)VS!4BK$PYD9juJ
-%pM!EHqhi=7_.:0`X!o4XI7)-Hc@0<P2B3ZQ"-oM(<VKq9CEo+l0,_f^G\rHB",0X,+S7?tpp<XX'2Zb!13TPqd),+*(l<E5ZdhP)
-%LWsZ(G=6c(=#6te0&CK@F2!r`Vk&Qh'gcSG*m9aU]:-Y6_qN]OY2WE'4[^r9mJ<[Hi$F2R[#qV#+0Fp6U`M`ODJ"G:oZNDlqGMb!
-%7FsAAn8)hCqHs1,^!Te,<H\W)cT=Mif$d6ioo.Tr4^`Faa]bR1qlgP^1N(ZS,fS0'Uq6ir_bTGX#p-TU+*OkB>?#2-XUnhU*Vkn`
-%kS8eOk!!FTZ4LWT6L(W>(@\/P2Ua\9JAW/%e\M`9HVcV]AZRipKqQ;Y*oL2R5R]8$ckaOS@u\d\#f'P`W`-9ndh?9U-S'D+9<E2`
-%W[:E)"&N,k+e3NkMiS-Dp-OY81h"qO0=u!ITMsg5[I'rdYZCpF:Z$]i/XM>Jn#RU;KLkR*R*BCD1Q0NaKiJeFhE4hX.$Hls>J2p3
-%g1U^-nb^$F'gW/=oV"<?:B`DSg;\Bc&r"qI?=Qk0n@rnjb-/GA;tft:ZU2Q.kG3R<SNDF39c=c:gH)rd@1=I]^clQh-UcO.(I)_)
-%'^OlC`Dp<Cnm9N1n;RKI?M#u>F&buX!h3YD2RKQ.iQ=)2Yb3GlJK7B)2G9>Xhn\PF]k&Pnb(M:k%KXt"&!00gp/XE!pb1oAZ/CmH
-%O!")kO%B#1nC9K;gDloXYF<07I65h\E>-n\det\-kW?(:cCNbTD8Z?qH5Edu]!@jGecMLJVS_X,T;_0X6EY-")^/*J/'&?sn"?.o
-%W[KsI_$qrBjYWPnmBAANa27?q>U3:3M^LVo-V(R>8/6!)n3LqR^qGEPAt1iTHuhf@:XA66Pehc%[h[^dlEI4B4TTC#A=V^IS)Hk&
-%CZnAUEncHDBe9Lg1$6U;a)f)<G=:lHP$(o@bVcLCp5[.a2YLD:`U8Kn!cLP(bQ=<m;OT]%.,s^90N)8!BV6N"33.$$E\c25*Y!3U
-%M7\pRj$OWSL,j#NR;c@8'k]Rk$YiPB/S.0A:iG4kN$ULG"s#C$.;NW;6NScJSV$^seA!O5*`<;g:Q!du,;Wo>)df_dY!C,Z\u9UR
-%eX<`n7U]eWl!K50mRB7<>!m@tYGi_?MphE,fa4c]gTA/`_H:u8oKMp;f`ol886.1.qekpuDs1bOT>kDHh.,58UYFC5J3_q`JdB4\
-%S%X)7<H"tq3TTDR)O7_skmMb/"Du=MP07Y$eSifr%jMWapKZf<\lhg"3DfF%?h0^.WqJak@HK?M/TH\;<r6=,95;U,[Nml8I@Blt
-%o2Ac.!$05_4ieAVDRr?,7V/?k#o<PbloUl7dG2<m<l-R0@Q">/U\NN?D@dFGO5jYhD<RJZ=I8Qi#Y=@YnKH=P:s"5>%JjV+YQu==
-%jn!ST>_ffGZ6e^ak.RaO@ha%7^!*$*S4M4?&*.<`=r,0QaeQUs;00'c"[+42ouK=+A@>"rDhZ+t3@(TUb7`ZUE:J3L06&*NGZAE/
-%U^<P,qP99sc;AKn37%st*W^;;<-O#5$gu2^,\7E1J6]P+abgRD0<XrIkOc\69;1.gjb`;==)X.rpJ=N4K3/"Dn0j2kZO:@&/B;]e
-%of@=Fe5UDbbGK\EW[*h?)4@A$=euj7;`?+9dp6k>Z=U)H"+%d/;=5_(D(FFd*qbp2,@,kh=i`Nf6gumq2t>_lV\_W%*)4'ks20d,
-%Ie[9B0B>'!iQ@=cr\4l>0I^iKH^!uG-i:G5D-]?]!MjA2k_gpY?HU"0T?%S'ls7T9@>g8%B3du0O9Wr84,]bP(2fhp3[Pac/VBn=
-%R[IBe9H9e6*;M!qkX^j@3ftZ.?"pMhXtiAVH9A!/m6Fcg!s/;G/128if@0=lQDZc323kUo\,WjOV`lbSS;XLG-gln"\S0u;P065b
-%@Q?T>-eNC[.Ou,$dt2/[G2pp6J7qDA-1M,s@]&-pc#$uY5SB2o:)[bHJo!H]o.j.EH-fQm+_fABGH0lTWmS2,iM"*.FnGO69_3U1
-%%7k.*9TaS"E]cE(/W-Oj%8saD5Dj;`4'Xbm:.2n6%o8/oMPt?W,X:W7ZVn7nG$<SL;cTrtJUgtNb]K109G-1ne"s]cC(5NT1^h*e
-%-iWlmpNEos(X$2*gt<T$QCIKe51sa'*;dRtoXKZ>g[Aqk:NsjWqrj5,f/!knhT*#kDkg/[Y_GWYQ/e?sTR/b_UV4&#4OFU-Ib<:G
-%nq;Us2psp4E:B,.is+8R;i_"i7'oSp2I0g9:*7m28q+"'d;=,8XU[C8PC""$GgHG\+`aVC/7BC<![q\OVP6-j%U41h.eXJ!M^87s
-%(RP3f^>kPn?cXZF:'XI3Qs0X;kftrR8Q%G^g&]+e`iAbcOJ&NE(VY;@@U,.K+8R_Va#H#!NjN1^IUZY<U%CFJC^YH:O.C--f'foO
-%m887lXmJ,"HT>/;=ho'^Q!?DA-<k7@%%K>#j8.-Y\_0Mh</co0RcU5kM6omV405@Oggf5XTRBo%(u<WPB33VuI+b-agL[hN4L=%=
-%g3_.^6]2dCHg<I>Kg0B]I['f51"T%^V%k7a]Sn[2dL!qcpkT:0\7`$$#u0:@@7*hi3]b`G2^X_b;p`193N[_+koZ^OP'\c&W@IVW
-%T.2bF<1mmhOtGRhb10EJm"rks,+^3-cW.g%(W(Ci?[@rD0DkV#++O7dJ,[\W/Wp#s#2u135SX6r3-*b$a`Y3*^Ak;0s&:mWNP.m&
-%V";nIfOGOkd;AOCKaY]e"*\[GY2&j_/E>Ghk/S;8QI5"sZ<sk=,YdJ^&DgFAn1-(b&Asc?DGK,GVVm'J#4WohZK"%QPDN>K3_bYI
-%dp(>HYHU5aB=ctOhDY&.#KCKtO<63cfflR<NsBM?S5L71*ACD!%I;D4MQMb`WJFX?rpV/_o8T_q(&dQ[fWWu=pQ`HK"L^YCRbiKe
-%49e\uoG.5.[0"bB5GXs0\dN!Hbr[iKrij9c;efd1%,)Ku8(O>UTP<KP^"Z.LBqb`#Mk.KnW9r(A[8VSrS+,1R40TAd)Bq-eN$o74
-%;@eNr6(VjL$IWh+p93u%G3ct*;h')]BIFtm[8_Xo42Bf5B=n?:SkXb#0I)j5p$f=`3@?c"G+,R;b\p+ab583C`ddC7T)4(Xa'#hg
-%En.eV1i7QCMGZ3(Z[J:?/;_MOO<p[4p-7PkXhgBZ]F$2+Ar*D.<W(gGE4Tf"WAEC@NRfYqC2hR#CK1\]%=HhR2<</HnQ0=i+HG!2
-%_Yg`$V&HMeP[<iL/3NNo.se_%#:3Q3$jZPZ6r,lop1(N6QNU2+/CdLg+(7H-N=b$"PRSl?R7BgER@;of03oS]VPhMeK1sGtm"@SI
-%1qjuB"eXj8emrq`H;M/d_4.<GJ=a@c4/H,0(b_bC7&s=Gg4<./I-c[YCpmJq78-`46AKc;q>hd>7lNZS%YB_?APW0'Nt09p%R?$F
-%g@Z<!V<\l@]KCd]SY**(8jf34^(6]3?O3^Zq4[J[_j]Abjm*R9qF>)WfMb`[Km?$S_,VsuSO8HIo)mfo<.2$]Qtj]E9Ug/Ep^q"o
-%2F2/Fj<HOoBY>TM,mST_CJ3%AYP"15j(bI]=]dEdRa_A30-!H8PbV=`6U@S48Ei`0.m/R5AY^1-Z6+:(4sJm/!iC*%ZAZ-..V5K\
-%>+o;oG[/8nIX;O`JURU<DYCRlj]ecj[iM["*C9gsP=2O6MTXIbmi@%a`p=cr7++T,;O'i2"G@-8aY5@L:`;*i\ba'MXSQALKL,nN
-%!O7QSehm=qNnl:!J&5r^k@KXp1gk_A!sa1t$`g4i%!mPZ=jXWXlAA>PFt[0@$)Q=V$@L?LCfS4PqCVEnlEhJ1d",Pcb^4mZ33XS9
-%3Qk-7Z[9&U33)D,lQL*K,oXA]9WiIAp,Q7+n'Td%6M"/OXO%XK!/4:;16kI[U5Wt'9hE<qP!448SCXRB!Z]9/=.MU#KWgbpI3>6t
-%kS",%:IGDI9DS;GZ8r(?4F)fT8!]@6A&"@gm;6RTLo4nr7u_b2_]S=70Ii`QplA+H3\4RX5*<[Impi]H&`)f,Fl'\m$s:PgJ>!0>
-%gt'(08VVHV7cD,:8b+)a!-<GL,`4`?BjnHL/L-=-pI66`U"4-S_6H@_6RJgbqOoEQ/L1H_*A6\>,Iam[q/g8cLK.\bML)]!obG):
-%DZa!pR[3FIYtV</'L9.X<Y1DB&,$BSESf>V?5*M-R*^-/YK#B6*JVN&L>,_+c9t!j>$a=MTUonH"oSqpR]VUENZCeUEX0ded:$5h
-%8[q]GZSGPpHa:VLjM$S4M=B6Ec:ZA-D91dq%mff\1g&1n#*5(jdPTS+i;s0Pdg)R/9In*/'W8KA[X02YZ@G*d&YO4Y2S2gbcrFcL
-%TS"5Ck'[h;Aas#/mkN46lc&hU9#BqI+@sHWWKhb1Hq=Pm)t_O*7D,g,.sJ7//BVju+4e>1SB*&e%G@eaS*se]0'"<[%:;Qj&P\jJ
-%27LD^1S[e'd4b6uB%^]4gVs_jXtXi2A!nF93R_$Gg/W(75nt2e*XTX)*b+lJft/8<[,/d*0a`\5n(+KeQ?N`q-'0`F.T/?6FhY,5
-%g5C3MCEmKdc&`ZHPc%"M0E1)e55j$hs$9?E:VZ[OZ0hSRLL:)D+"nT45Q'?pR`58as7sPUs8/F;Qe_Y2-s6?oGbZqB?eQB5_lmg#
-%Rn$%1$u!"Z0KZ6k.pN%T7E7O8:/BnS_,^q7CNiQ"(O4sh\X2<P-A@g52bNJHW0=)+*.6`:?icqem`4R)\+Q>S;dO;t41[L?Mn8#&
-%*e*k?:dqb^JKqj1\Y=WYbs7M+S<U@V+3<C&??^p+71Iq1)'$7G)`2MHf$a4"[5"c"LqW$Dm`Z':*j":[J>4RpYC&9g\Vs]FDl;H(
-%.28!$l@O/Ne(.gRdT/jBU[D6l1+ET#k?f=^FD;qKnVZ?AMS)sk6I-5YFOI`bnI!ZR'X`V<F[(9J';?@[YUAn)DkNQ\%']?1d0@^r
-%=9JD_!EZ0j3B&45Z\V;c;j`]?b,df/**6dsG-c&e$DOM_JgX4fK>1XKiuEa>:cJffql0iUc,_tcoU4\_#5^JH"1)r9@IR(7$LG-_
-%W+e1,@I[S59g;Xu-t(MT#O5O[4.r$bmHpVDTXhXc'lTeQ`;Mp&4gS/O;/7V[5//qEj4`bOq:g(m=be;<-t@lE"HUf'bC*L%3qL+s
-%DS8"'9hYLb;LBLU/Z*5)mI8%3G`qr,96@[):@%2Di(7ek</<#[P4iX_j=?0jbsTshk`HI&@?h1uo;l>Ld^3&PN_(tNYq^fVn'hTq
-%/9.nZNg:d?&TNQNFdZFX?u:<^SVmjMAnfTr,%@2pAnYZ)pJ3WN0sE8ei<*h4K48nMDcU2D/okW6`=M4t?1tYFd*rt9o3WY^[tQEF
-%AD<N3a#8Im[LoNJL_#;b2@Bm'a4[+b"SnWk[cSs!#]VM>943+0!-:A0$e%jQMS^Mc@,3d&b3QV0'k?"".)aVSk%AhF>S_97SH(6L
-%eH:H\M..4dbl+*fq"isW"le+'%;Mfl"+6p]aNRDU?iYK"oJ$9@_6=ll-ibZ:/S=2G#eaV%dmRRheS<OL5XDFt[bK>UIeDu=L:2(B
-%4O@ZIgBAU.8)'^qp?G>KYbEsoW6nOX$.'1]#_*tDB-*0d>V'EBQU>E@B%E'CW/+;g4MIWoj[lH*mW,&#MK)drLf=i<H7h`Wa[<O.
-%2"Paf\HrPj>A`\)fKXPFI8n??T'e)rHb7nt"bNK'Q45HrFpB)P,&/6I"rLtS6OD!u<bg:NCto?+lDZ`)J.b]V&[-H6'@)6i'o%#A
-%=Y)lRs,E.!FoE>)SF$)nH@S?9U3*9s+RU`PB?Zn!OhrcEmokABlYMKQlZBJHaYnVEYW$Z_2K0_oG6gBV4X?C$=&"h/(sHA,7.YRN
-%aNP\#-o[TK?F_<&<uj@Z,FS[[HpeM3f,):Kn)h'_kXe$U6'b^A$r4kRa4/.<NBKf'f'<07djUlY%sYAgjPq&<8'(nIL1GhbJLF3q
-%NG1U21,Wj>l.4BINM?9>>Wp-gK_Ra,!"'X%J<e'8id37:#oOBfa(*`(a[0$Z'Gq!d,tO3ll+N(s@)7fW;b,l@NMjL@Hf'ncVagpZ
-%!$@,DXr&"<UgR5mZN6VI(>UA5MERp*"$*W](U)5d/8Fg9p"e>dX0&)m!nV?F09#82A,$EO)pFRap[3!U\[W=nknT4E\8;'G&RX"e
-%bMf9,p:.LeD$8C;n!b-2Fp9G)C)Ic(dZ=d,S`%=iCj9<]@6k@(%F^Is2Dc7#g#i>c6oel%*CJiN7SQ`eA++C(C@$N0bTNND#;*l+
-%7:_cOkm/__n*FdDH@Y>uT^YO=`dp'lR%INpe*!tlgg::lf%8JS4Ig&^TiN2-+0F>dBitGdF!DA]*'CjZ?q2tQoj)dgc_kk$;)Mjd
-%@0M_3f8*L;_&ffNf8!nGKt-<cWZB((M,.ilU^4d0eHgCpq!r4,!2$c7[2ZH(ZiQ+hE.C^Nm"N8&bPB3sKW\i6aPJ3M+.d>jemQ`T
-%@<&".,[k,t%9-+jQ])&HXrZr)'U8s/\W'2=#+c<Nl];Q=A/0hN^X5D^798Q\gurKNE2+-n`"@ecHI#.PU7$_=Tnif>BeeLuJaW>5
-%\4shQVm_H12(@^iVWp`i<lMCC;qGV(cLHLnP=^I2NnBoUXmehsIdUr)&)$(L1X;JI]_>:mI5CAdi9=Vg?3:LXW5&S>dqcCeUZr_:
-%8.2KkrDOR$DT,_0N9GZIJ^[G.@u3(E4/$@KQu8lA"[d7L?Ep1JGcW'ug5shHqD'+IJJ'cCB.uKKII]eX@%B;+2;4''S8"Cc\tLTL
-%$VP`;lH#EieQ4m3.(/.PE#o=5Kf-40K6=f1;"e?)Ts=F1mP/L%%^T-k+TRhS6qdj*Qj#E;^tAf@%LsDP-W2E72Brb..+;u,%."J8
-%3F/c68S:9nM"JePab<@q8Q^^!F]lN9*Erag>=K*#S:>]H(nS,4&-_qrCc(h&C@:Y^f)=:7BLo,Z4<mgRBK-g+m2U5Mom&7S!L:D'
-%$()JG/ERZr_h3*^Fq+jES4Qa5<oUC%M%s"/O3YjkXUZrB2&8uXP_i^bp\Mo_lfqh">k;rWQ)XoT%BsH0>;2.\P+<c1$*Oe(>@`NC
-%0)!f-5\@V'-:/XkR`4Kf%(t_\RWnGho;4%(oPURj^!*fa"T;0@,<d3H_X4e))&!4`fA(t9E^uX$1O'B[WtXtZKm[!ejV;d;Yqt.t
-%1pp:`_eHgJ7skn;FNK-'G8@hnr0^DLZo_&L<g`rfYRC5l$nSV2'Xm'(JN&WhgIYos;*1Al"IY0j9qHIjD+nS:_9=[jV97:$`@?:s
-%LS&)YlR/M_pcAtU*X]b:<I^SVq!4a?doFGQ_Doa#bp)*p\Ko`*bkS.5.:28)DP#`C2pSkD;j:$c!KkDKb$g?%Fgh@-fKc=Lb"K*h
-%m](sEr;*hGVI?2UoBW<fHF!4O0(.*uf2KWmMnh/o3go2.6li/75F_1(>t_5Y#+)45C58C[i,LS\L8S%p$-^)_Gl?=`/@#=\,*m`]
-%APWY;5YL_=bcr_\f=c_Z5i]0N$U(WKqF"b5>%k4pM4kRp)KCuMmbsIIW\-1'l:Nf;*1_k3WPnUGq:DW&(P5]QU7gj6FD6KI]@KQG
-%.,Fiel&,mP=AhC6V#m]HArFR:C+f`VkFul18Z%sB%GUk=V=kqM(ufpXnt/%a#!DmSPEP@.?gGETSU!X5j=th1fc6j)PV8.3jJb3C
-%Bg)qP,83GA#.LTXp_P\K-niSA-pR2/MH>Cd<KfEmg)W/`0l`^VH=5*r*f\Q\<BYfLfRf2E&d4n-fnQ6sKc?LkL]dB^W1AmL7]tq0
-%nKtY!FJ>oMVgO2B=.Yf70(Z]Z+UHO.dQSqkhTT6H#IWo6AW4',/-W_kH2!oDc1aWJ"@D1]>L!Bc3Obb;N[_e*DjRg%Eo[:ic39s#
-%;;fIdEe#271R\k8O_!e2**R`$>F7D:/<N85\o"cH0m+dtEfZbTSN#2=9Z<)9/UWSrMC8oJJ%g1`HOA>>S[+6_e4.(1K$+U!gZVBR
-%-Uh<Al`/XHP<"uShf4QJpuu\p&UpfQYE-?=bo>M6%o\O.KO#sf<B4`/][=4(e-%e)>B&L?<^EV=O$D%*fWd6L^FC(0$G4u2YB[UR
-%bhg6-%;1f?CabfQ?+i%\-$g'<>H9HWL86@1;7,?.3?c4mgT-_AQ56i=\6<9L3l`6r$B(ari>!R!>&54aNmXppFaNOIVeoHLARVD9
-%7uWO(<lCG=\.Y:A>7F>L,U^m2:ZcIBS]B7re-UnY_@#acU&TPEf^!&C^lgI6TX+j<]r&Ur\4S5cI!,0II-Ngn:`K%eWIrbmrloU7
-%nMG'Z@S62k1G>%@CiWF+#JS%\C5&]V*IoJ8UG)lqMQON&X?dY.o3c!OnhXqoYmRGb"M1#5#0pbk@uDA+mBZ[^%jU[m3`S@bNgf49
-%FN$&E.pL[PdA,f$VEhlOl,JCi\HdJD#3?Rh"B9Of6pm2u`_/S=!4>8e=g1#_idPgk6,`s1WP\?dTWSh`*E3a1@66@Y?6Rj#)mE,M
-%R'Ula:Si?="g#-/4(O625p]eS.Euc_4<-FrST'Jo7`.Xi">SZrY$]G?kQ$$F'l%ajdf6$1S;hL*MJ;Lg<S''n&P@eI-0KUmXi9D?
-%mlCq2A(=N%kQ<Q)Jtilf6qC^]4EbHI3Wfb^M2b6%3dl&RcI7!2Am:kBXYTg\2&7%F[0=-=peo'dGfM^[RF1:l4e)jF?!$03/On5H
-%)4NOg+$P7NDX]rs*bp9X)NLf5`MnNi#!1(b<%&iP:+WUn9.#Y[0P[<4`eliG[039-8#)&eC+7@4"OlKlpOlRGljX=mB!lpnF'YGH
-%;cB[KrkWA;-;"opU$gO)r06GYs,<InesNe@6-?kJh/-o']L.076(A^`5qgs&k=Z<@0P,RbIBMDsLDX+o4d`%=dg*=F[-W)iQ&6uM
-%5R!]N8CI_#BGnAP#:u=#Xj]PH1V=a@6o>?!L$BfP=>I.0&+\KV?X:.[8ge(6j`WS#=jnMJ*:UW-aP%BR'Z@f31?r2>D0F+q<1".g
-%ob\.=\XrF:+p'<'&@!C(hd@9])et(CK7uZal3f.DUfku+/0C>Gm'.]mAHq6Y83s*J"\?]u/G_^U-F`!`o?t"`_@GQhH4Ug]8./?t
-%U&-N@Q<SsnGg]EJjRLJN+_;mp'5)CPH`"06h;*R9GNd[FK)j9i6$C6_kJ=5eXh-G?4F*rJd[Ys!7:%M;!O[UM@N&B>/D$3,`iV)<
-%kSi$5bpFRdXaICuF:U56$]Bm"4V=?t5SP3^VE*H?gte+$%hBJ.\*pZ"9RCW27cDU>NtZ!6`D^`3g9H4Wj!"Mj",j\"04&&QDU$i7
-%V)+&VM9*'^J@N$R;`mLI]AcJ[nggk8QtPNfbRdu]Q=6d6A1ZD-hH$c/"i)c7Ad_mFh%-j@HhTW`,N6HQg&ai;4iM\,RV$-R^@Eq=
-%Y@j!?05S'CSeo-&_QuSlJg0aEpKa>7[9*S&Q.#r6Cr'.j.?t&?if!sG\.=fUB["b#a\[&OKi7WuOOPJ.I:`^uU!'+(1(;]HL8N].
-%MIJIX]'55?#O#b&Gm;F&HH!`%$b@`n-e%4>#d)$VQ'E:2Bc:s(o<g;m0:EnQgE0NV,Q,F/rF*Sn8,NBkU&Ptd%Akso`JE%'NtmUM
-%@_n'\4K.F?0XdUF\-L?jOF]@bk\6p%J_%sIY[uPrN2d9Ua2;j.0*GOiiaf8_%R'RseH6/^U)ZI<?rerB6uX%eHtP>5%bj@P*(td"
-%o>6W).4>0T-8FjWnfMU*6Zr8KLIKc`pk%#5C*5'G"_W5^cj_h!?apTCQ$`lm[WN20#!a,K.[:<lNc_.<*+ZdlPfOMe;/bb^aUb;>
-%5jnQ5n5`'@0(s61SRM44Mj7hl_Bi9jIi12\$GTRI:LQ'.fY">*is=,pn3"IsEslkTC]_p6ib7bXd.FN*ASY=:Ane68LWJ`Za!57@
-%2F^p3bmmdK'W]h&3%`p8H-h*'H*_e=<$`]uJicViS+ecTRZm-77hAhId\I:XnC.#QS:Zr=RYQC8dV[+u,IR,_?raBDg>c^)R?KV=
-%U^65F(O@pcm-)#kC/XS<@jM<O8fl+KV!BcO$`S%lfb?=*U$_9YXGsq%XcpS'X)Y#;L7ZS#Cro"gd2O%9?$7>'Gd[13T$,RiO8F#`
-%roOpE"'.!:QXIrIf->\'_K%IC1lKch5LtpZ7sdW5Bk<VGRDYE0I@%i,Ca9>1Z:d$.F"eo$M>*b?RPq&$30Q6pQg1A-%XlT"<b5Y7
-%$Ip.g3l2%G)?4VsBu4Z;NN:@KLLu,5%Ti[kYWn4GhVD40!Uu.e(8^d5[i)l]h6n*o,#%s"INYPLXk"N@]ZBXJhdEa)1-9lPNC>n$
-%f^:n&G)L",;Y!;4>bQ9i:[RXVe;_&&\<i>`.=R`.-`ip^MgnQ,5S5[qbu5nRJaT#EdoF3*/?3Y%BSY,)8',0_1KOD2G2;W$ZOB*;
-%fX;o6,OFd)YTm>X1R3&?#59F)Z&e-=,KhB]?dm/t^!J-PT_m9$N[#"+]5Qj$'>E,%!AAPCE,$0W3`W8sQB)%$5m!7qGP@Pc$afI1
-%o8%L57<Rd;k=7pE`c-D+^>m-uI>PLQ2XK$afFd=6SlU"iNa+>H/JCi`PiT"5(.B<9k,&)l*iuC6IMlA\+Wa\/@r>SDfk4_;S&!ZZ
-%/!"=aP;)O40ZdB[0rD"L<&ubcm0O'c(K+lV$_a#%Z?5f`5k^*k_JPgZ_>63H+e[2"d_sG%M]5e^"1;>$&:h>0eV?o>/Jr);N+hN4
-%Jr\B1a]][@aEZjG/j7sP`kdm7h^`nm**$qlIRi39@?6B,_dCUn0;RZM%JVijm@8V-;5T#hBqqjaX<l_kBZeSGRUa6`LiYrWVg#c+
-%Sc<0.mO)u4J^X\r^jLnc>ES*/7Vu#i`f;AM,55,'M.lB!1ARel9!12j$]K:3&Gj@Ka"jXn$F4M%B$e^B\6GEDLNBR*3"L6E<4/S&
-%M[<`\OEHJ2^Vc&bLYi+^K9baQY"tr`[BJ&4ne"pgV[^uSnd:Dp-P5)BQkt]7g5K!Ag'VLCrBt*BT4!58:.AL5oVK0agj86NS8^],
-%SMfS+C6`3W0L(NA,ZT!goO7uH8fdF:C0aI*<Tt\3fD>hD2A/@d'PHSjhZ,Ws#5n\Y8YFG,0qoVJnWbWGW\fEl6/:,@=g8WXA6*>4
-%S5KEV>f6.$`jmmP`/u?2Yi-%cBsrTu#mZ7UX9$?<__.bO33_q*dQiC%i!DjYR))s<&Tob>;Pr)=(@(#jCP-ISeBR%.&/KF8[p=k,
-%bEG3L?[S$uK^V8acDYaAe.EP*B>R=$4YdLfCC=8Omo@[HS&%Yu;E\FEbFo@XDB'+3>k^,*Ct[9kLar,r%%F("g.-t99E@j^R:f-F
-%'\Fp2d2YGn*rU`IRo@p=XS5YG(7[XI`lt!'cX>Z>a(?^6q#D!l=?l/d\/B@!p5E<>)@UCqG7V-?@\u<%Qkc7KOo11Es2c(:.Q7Ao
-%>/&a89IFH=g<?5C-4;'+4'Q8CVe$2#N^m\aKoq%5U./AT$8jUp=7h+[&G^%]SE(=h_JA;>mCRG.$JgoJ$mCWk/%oE[L(LBkOgaQ3
-%[[kW[.\M%gMoNR5Z8u"D7_TCH04G[5EgWaX/HnWh3;F2jn)N>,XR)aT2$jP$XDFd4AB-rI_[=R.P?C&/!BWWhiJa-h^)(SfL#F&c
-%:U*&F"Ua"WPa(CQ_F,L-13HFJ`XWO6d?A_r^%ShGArJm@bK,!@l"sc)rCQ!*"n6p4Xq0e(1IYN4X^e7Vm,j0^#Nd0kSo/r8\Q#<4
-%?#jQV`G^gR<HTsB"3c1>$h)\bkDOr[!8O-^Iku*a4uQ@C$&mWq]qa/ursd.:l#q'aaK?MK:M=*oct&f:aghG[S#"_c>2d\i<UDoj
-%D]WMfY)Grm)u[R`>Ui"#Xo_)<=nb$mBb(:67e^SLG`qpee.cPs)(+co9/*cYe+4/qUp:;_>NjJQ6Jqn@&2u=$7h8U'SZ)Vc%,FLR
-%%SJuR=S?cJ9HDpE4DQc-FTJ.7$!i")$fD/NU`/<d(9b@d%p7dg[\H@bHJ^V,7^+[7J:T=u=s3.6<j6Kb-WR9JRSU_FXXJR;W\!bF
-%XO0nlU1`L[U]g4ECLPM!/Tn>*,AkFukr<5@g8VeCq@.Fb$&W3[I2\*-q3"QB+JG"@.n'fL'HJ"`W:qRX#3n&<LE_F:AM/k(1oc[6
-%0I36U(i1=YA&QH'b^?c%LC0VM$/NdU>T!2#&6^!I&fKPK9Ke@6"I5nBK1AIqq>Zh/HQC@s,Y@>/qAi&!6D,5ErZ_OQ];_)a?lLYR
-%+HdZ+JdSE+H$cFCO2o@hHN=J5"dPZ@Su:R0^C_OLk%<Fu2&tO/o]`[hr^/VanKO=m7=U":U)%:I^0acT.,F(['XA!N]$u>??gS%n
-%G41K.dmpX1eiWGp\)X,b7KUi9VYW3V&.Z(8h*;6tUsIq'iN)fUXscV0npOcBF@8GX`#S'*97eTj(2,5K52hRDUJ\.`rX?Z'pE*T:
-%X(KFj3!7!2T'-pOM+\M-Ve*R:,YthR-t_ts-'-4>NIou>/i:rp]JQWmnjA<.o3n!i"'?LU(Upl2JFq"C6=_C@#jt=R_IX,&@V'Q=
-%Jld-PG[+ZZke#)oS?I%U9s[T*7qu$emp^[1fFcsu[-pT'S#M_HoH[-I5+\Ch`cj.U;D8ljdT&%N=W@/.l?q.BcCgEN^pdTu(0.M:
-%3*%%O6!I3!q]QG]:?W8so<:,i:2&B\.'/XjdIMmUIo.BEN6ogP*RS^T:4Q,ZB]h-K\m--^0Mm#5EohGcYp,%%gjfR<]Z!nXL#O:1
-%]M"FY>TiCLCS%b;[n&tIm;#pi,q`4l_K.a5cc\HpY"OWlc\6`f<nR30k)GW2RVV!3rAMns+8.n4m2+<G.9ba[Jf7XEQ>fdu]AP_o
-%aeE9[)(loLPe/5qP]i7#KSr\q<S5\f\BKZqC7[m2@1Fug07Dt.fe0rj)@B_B>3[+uC[KW6Gc<lcLpMkK[u9O1S5@rdiq7\O4)<@N
-%$LRtQVkY=Q,:D1J$=kjtL1RtkPIJr6b;WmTPIOshX!+^Xc.bJFS3i"eFO'NK<pLfnK`37mH+:kZ9G;H@c1+S7B,S;<hjDtq!17"U
-%GQu#2kNJclh$.og)In+ORo?&&]+rSL+'\k,=7cVbd?1H%)T@tV)<R=0Vf_@IitY,qT)'XbD6(JAl10\bMK[FjN[;u&d;7QsP?Q8;
-%qX?!d`ZlDS;^9Pgjmts&p2d<^R(f1Y8^'?=f/Mb\--G:48UsHg3)K;o/apo@:?jL&bjA8/Bbj#n.I1E9gioDh^CEHfGmhW^i_/>k
-%PjWL(_=,)A-OD(p$GE4SYlk`5,-7cH=?84Cc-Mor];Q_oUk!=6RY+Y_4X:k!fUmKlhJPc#?N3rd,s^0gNj4+I]kA-,U:nfN?A;6`
-%e_I';DHZ,)#9:>hn6O.JD3nnJD>JGMWNXtr6+=%i/=qH(43]b7^@.NFPFM>\!'HZFh1I"rZ'HDZd0@kl5:R6@P+GXsYA?GmQ_Xi!
-%Mjg7cgNT<.p6`.!J"_$;\?H['V4.N<phV%Q.qD.m9?nSPTTXELAWfsE<j-&.R>+a9b&3MGN1aIN!#`)Y"C^g.HP.#k$3J'#oi%4k
-%4WEcCII*JY(U)h5G&NEUD6*SHS7rGKcLN)hd'UjY<Kd:"WG4ak^-[L,NR[=K7Bq7+a[eN6)5Pu8lfF3Qhiq#Y,o)-UU,XOjIB;Di
-%+nP:l00CCN[4`]5be#^=;Vo+A1(un6`L2(=;p];A#DGk%Ng=e2O=XH<GO[b6V/Oeb(h9TAom%qOQIpQZ()sNC"CtJj8o?;`&c<o4
-%j#L7;Gj&t.O<rQl;13bJ0i(I:I2c13mLcYNOCd/nWd./=]nCFEc_ZR_.:K?k4Af;iet0q\,+t^nbdlrTK])L7%K,lt"/os`b?#gg
-%E;(IP\[i5r.O.3ZYA4@TQC^Xh">F$5*uE9r]>7rN6b#d6!*+eO+KJNP6aIn!c_HfU,3L`dZ\(1f.@ps[!In6;#@QKN:#$@KcPJcB
-%XC7kjF=8lBh8ZEp8-cXOmcDVd)o0I0qN)t3"'@o+=bSjYK<!9?WEkuU-$(uShC&"HLPAaa+O6TU83rTSL(ksa"0qSd'6u0:5Oa0e
-%*Z=(&-N_*,Z3[ro:D$EXNle,-<D[20>5Y;JPLtf(A=FN^NQR"]^S#0QqJgX$TA9!M'kp\d7W(i(!F:1-1Qe"mR]7HXh,@7&VV?-4
-%h!*67=B(O[7dfN\j`5Wre(Y,mS9H!S-8#M/.\FZJq83+^l5me@.*jKh.'IkVEob0aY.W`+,(0!IdTXS--6mX'jsK`./Rtnh'AaG4
-%kN:ql?UQg)>C$:<,uSA*It+u;C><UQ(3A7X50?/.&$eAc\`D52S?r!6=jDr`kfHrM!I>N0b&E]amM6JqW's3omjB;1VXX"+++rXf
-%c*(?4nMmRNFXfiu]5u:u^J`OsFnQOeSLN6)!h?Un(3Bp>fs^_^YV4n:DG3%ZY\'+2io;ZEPSE@=E)kU"B[!XDQ@t_eJX?3<*J+L?
-%XH2OJl7tVFc/a;rB<hC'l$'%=AYQ@SS#1OqMU@=KN@(<A=1nsqQ*C;D#r<q(G%K@o=Z0MNT=(#i8''%Jl7@P557('eRP42nbB<]*
-%CggHNe='VZ/ZLMo=E4]f=/#4&rk)c4e'\=XV"VlAqh0IVM?'2/MP%n!osiFg*BD;C8r,FLkbZ&SEEf26nmi!Y'K2,IMuBlAerP$G
-%1gYd*OP)?#*q.K5.b^o;"FSD-I;JEY<mT%mY/#mS\KFbsC@0E3N)!sa!;E+LTIAVXJ:uP`4,@cEUB2D(YZ+SJj62W;AZ)PT945>4
-%hZ/WL3Wnn(f97Uab>,ZVQQ>.Te9g_q57P&AEu++WAM/P6P#]*J)n\id",@bq#u_i`f:_k0i,D>O%S2LqJ^-DQ'>Ql@oH4pBTA":`
-%1GM^.dj-spl#-""Ng9:opLF.&(M60lEQ*de`NIi*/4ho-#4$8%r`hLU]ROb.Ijt&Gp1qhoaub2m.XHD9QK<9Not7bff$L&grSi03
-%7?+5Fq)7NXW2s!+,jhfF8j1iZ!U)%p"lCN#m$D_C/mF,EYAU9S=F6VRp4h)<A["jpTE#*37U=+ALOq%/TY0m^l-0=[r-!rRp8@&s
-%el0os>%0\&\bo=2q7>%4gF"-C7XWZ\@W''1]soaUfW'UI[$TR\>B'.6$o)MJMt@GCCC11XnKY6QC=d4*7DGRm8cm`5[OOP;$<*(T
-%kWrc_R'Wa!G@MXMN1$8(N?X2fDV)#XS&DObI]FXl=>Kepem&FaYqs9&g>GBY,us"#O<.3cl<6Vq*hC-XpL(WPlb1/!4f_:525hQV
-%GlB/bM_AK\Q]o,WCt[Z#F!#sRMN_:MXRC`<CElWhE2is7R'9VShZ\@!?IAq#*Jr5An;eI_>\:1fL8$,QYK&T,>Y]gX=?q.[XM?Cj
-%]0TV:?P3qtn/,Sj8&5P-kd8p)IB/hQ#\Yr5iAIe)=UHO0d&fM0Vk>@cfm;^q+MEMP8P@l/2QohPSEk/b<Gf9Wouqln=k*5O'Q;-j
-%\6F8rCJ".9aP7rUp6E4ClKu#t"B26+ic6*UQ-X<.8j7q\XfLNhp"+*Og,e1AG]*oX`M3pPYjKB\/4QlnooWm[*hAM,(sK<jrO7i[
-%D/,MWdJ81pQS9sHbP)g]^L;+u)VODXcW*7\&,V5MNa*Arp'-6Yc>^O*l=g7B;[s'OgV7aMQT-1n/A$h^0apmEN?od=2eMqsT#nf.
-%GG:`*\6o1?&b_g^,ZaE1]Jgm@cermaiWYJhX;#=%s-uYR<Fl37.2/6+"-$=,@%J6&LYXdZL/]>QBs*$8Fal>*IV=83KP\E^]Nn`J
-%Y05n(g=cR\A1)kim"PDeFrRk+gXgeb?BT;Qg-1(YNXr:Em[$-!P,)%[e],++oY9RTbkA[J0-YL3&8L;0*n^^YJ5MeTio=/oIt*:4
-%^TYr(Ag7S2s'5Qb77lmLp7a$QM\@3mIK&1(I5n9o](]fHZHh_0]u[*l;F`>NcuT$)/IQW59uUM4<m>\AD$80`4mKP5Xpi?5_(b*P
-%Z#`5,PF\M)6J"C'ZPUnU[''YOEK^NWig?9<=lCklr9mol!$5pTQ)#U0]'T7i27%TakrhF;IUIeU0u"MV'Ld9OX(f43"0-q7ZJESS
-%*c[.=2Y,VY%UGHCnVl3M0ig.U,KXP"+XKgW;Vllg@$[lDi6F7HV4DGm4lSs6;L7sNY?]HV5%:d*n*CJlr)&h^m/7q#%S7;Tm"&Yq
-%:#YVlC(ku_rV_8'<YKkKZ2n@$l+%_COF5u9lJ!@p*3Os+s5!#@nD5iHpe/4cro">Rl28<FXY"6q,Wi.q*Qs(%.D)`N),q.&ZB4V*
-%g2>#]$sjg!>1Z%UcWa!4,klsX(V5D!7/k<QqY]g91B!PhTe4`CP6l97$1c^Jq*4m;jh^j:1f+ZSmD'lpnkB#`aaG[r'Xk$j(jT[5
-%p>KdX0$j.Wdc]nMefWEO6KL\4)[e7XotQYT[nHn.JR"da]er=uR87:7M*h#%F*V#"-q&H.!cjk<%Z$TSd8;13Ekb=,m6qIS"+r`o
-%[)@U";(ZiBOh2`1DgT4d>YB\f6D?3!`TZT2PaG\HD2Yj9kbZ@IY&kUTa&]@4-b8$']:q9nU`JPB6Tk=)V4>0H`u]3*Ks4p!@&*ol
-%D9)\sp!&@/_Bg-B?h?_Sgj1gkDsJd(K'T`33?)?m%/hJW^84XifgYb:Qf/W_rCWn!G8L,a*kSQc$/9=2*U>h?VSFd+qNsChkM4(t
-%Xp$Ni790#IY8<bt1Jl);Fl#tkT$_TJUekE/!g-GM=?BOHf2F[les:>HSHZi)X\Xf`*`;FE\m:g@AB>DF0Cuad`g%Rs0$IuH-nR#S
-%^p'7rXhFGMPC.^Vg?*MZJS/aq#6BVIU0'iDQ1Bh![Gl!'6J@Hgr$!!&pM,0gFC+GLm'quan]2(LAVG&XI3Kub6R/u71C5!<lu?Vg
-%KlUL&c#39P'2.>p:"1\HWEHHlVAS*.A2,(uOe^\?AhR6?pia0H6nk+(kGHTF_K*#C+PS)M>gG\l+Ioue&V03m(ebCQ+-df`Np=`8
-%U5k*U"fgK\"S[\H)TeA$CB%QAE:4Lu,cF=[D8nL+F0Z,h`r[oW__c_gAlWL.`9)e]fqe$n>cYt"q>,$OVb`d@o<b+e`hLe;ZdO4(
-%BApbo9oim+ha.SPO=E,R,cG2QPU/$OY``H84#cshj-gGtdZ8nD=;lEZa@5#X6\>*rn_J37.UN""7+UARC8,R`!)'>7I7XWi6CEFr
-%S_X^WBnoUAY:e$,@B7uP8g#.L,+$,+F?/7J`s@l!cu3bHNkDN,BsNT,_pX+#'ZU+>>VZ)mru]>BVuCDZKb!M_+ui#s`ab.a;&cNn
-%9t5,B-h$@Z/%rjh84'F];a*Z>'?;aH9D?$nkX/?HP@oE[njGr,Q/Y5`lp61dMV5eCLBC3:>X4%^)/u5/E=j]YfoeKFbcV`0m<Z]g
-%9B#t/)/#-t*0%'LIj_d=F^4.g9jR0X-\QQC^c-Y+D*?kWj=oLbZP5)(3,X#p@r%YF)bGmh+(E&'2Cu1mbo!f^fHJToNPnOR%`?l@
-%KNP4G)W&@\\:pp?QVKj?[U3Ir(F(@!;("BLVn7]>WN46r^@(#;/Kb@F3BqXDR\+>O45@kg"\QH!^:aU@^bt,LFCjSbd:n%N[oNCr
-%`%fU2SMgq2qmi=+.h1:></AlraYqV'X2o4-r8uh#e6EjDe,n(%QM>ITmXFeG.p/nEVCDUuP(6O##<70BA3Zt@fsh1TO&pZ-N$gK7
-%3bQJDbt(<13f3Mo2(U-fS'>PMggXGu_g\s5`\us$R_u>i^QgKc8O]mN8Dgc@IYOP$?10?/VEL??Gp-(3$7\Ho,#Y`kGl3lQC45Cj
-%B5=B64Z/'CXj]8p80+hPX=Jmh0-*/DIB.F$S[#KH,(_="lEDOU*k[XWhJEQ:X1gaHMhU7:3Nc9[.9G1d_Ue-,jr*T+4l4b4)HP!H
-%QBET,a?4ot>;WI3ZRW)#6D7O1[t7A4N&&/.>o(\kE3Gi$>h.%:iC<?L=ZFD>gW7BgJQ2%]/-b-XUuJ*XReNEnS0`AfF*nAq@-4U)
-%=(@$WY>!Bn"^SZE9HJN//(8*KQ`^fh.Y^@+ZO8m*^I2ZdKfjKb*e&;qp:S=Zmb=4?egVRPkfE;fDC%FP9qZf,rj&*n+(UEPHgI-k
-%\]a+<]X4"D]NK_4>dR!oh9-hQ[p$kYkF=j#Gb$NA-CI)PMq<3^AAhqnO0kd!&q\Z^E=q>SN\u.2D`$U!WZbd/QE3]^C/r6aSUQ)D
-%fb\PG8oD9;E;Kr@EgZ5=\0TK&Wn3"=06Lhq=HcuOE\i>IXNmJ-MsRce-=]Mm>Lq1^-U%.^L24E91BBu7kbl52rp[g&YO?Z144ZKV
-%4RcjFnnpfN'[Q'tR:qRpdjs+b0Ib`pe4Mt<Pkq<3%mIA/g?a.C1oFN#3]?Y*B2FaF]=;GPe=s.GO.B*ni9FE6O8-hi"E4U4h%.1&
-%^&u8PC0VONT8pK_'jMMBR!'!,37m(Nfjg*ajE\Gp6-=<42hE-sG"H13R,;gdr5)#KAb@:"He9/Hg[n9k$,m>"V_^-s_rNid,q,._
-%"suVZ3\5NdfnCCfJoe#Kjo>_u2eK"4?/aldN2j=@&atPi(-S%@a_e&^gQhTOj3GqX,!X<Gqo.S+"cVH^no>,qFomPS_]#cDH]Qt%
-%Id,])NPtFLq?K6T0rYC'`A.u=`7Ft&S?*P:m*'K7ZsQh8/"3Q\3K:-a=ui!qC+DO29CW8Hffjo_,!ORRNOrZBc(]Rsdm,Q1PJn,H
-%>V51B-ji&rEWRjj2[1S&L'3]U<hs0YK"Y58/2FBh8$`jJR?]%m[>SH/[W7WC*G6BA,m(DeIqd9SGP`k%+u(=:]&u`*D5P'ZjCV:M
-%T5!J![*`%/o1TbAqGbHm1dbj/S's&WR_ccP*]YVBjim-J+deHGM7C+]dLW!>+*74=CVqt"/irbVUum!@a?KiYAi=q0m/"m2cn^;*
-%m'rF;NL(D-/BG3fT=l7%TFdt=gmU4H!SfoM#aFl2Y-c'hN3Xcb=[n=(a(,;^:e_5QZA$l4WOEU"Pum%UTYQ^S2XXi(dbN^Ao)7"1
-%/hAi%KL76T=GI?qP/[3p!)MGo&"T[k0[j"sb'rWQIJiKY@6"<#Wh.A^<&]QFaiod^P#`?bh_u325]5mSS40]k!&![JMu<=2FtXXE
-%NnSF'+A;N*P7!JL"[.@i,/Y,)lYH.,/p7i,7*#^96*4LJ/b:%c;cTKHYkjM-=!tg3#$B=Y,8/e9o)GU/QY9.!XV4kOO'>f@`<*OX
-%g@jLZT`e!cjQ393L2IfD$F]=:B)_\[mX@2%QZQ!EYA6d^;l,T=]"qp*,[cXn^H"D3SB`XZI)iOq_?,)jW[\Ygl9FY0g=6/jG1N6g
-%;kp3KmIG!6"c1[tf,J#0G:M4[-C<.PkRa&^E;(D0[*#PFXscPtrK':(al8_SM<\ml%e"P:.?jJ/*s.2Y3Yb_lEko9_>EdmI%[Q(H
-%]m.D18'AOl(1'p>6?'U2a#kk&f&u`,D-NtO]5j;apio46[i5r)\Fsmgl'%B2OKhG0"4P\@Lp]&7<aTWY3U07jO8XmM+I?n7RbGAe
-%OZVsN$]J3(F9HLGpE2n/IT7r&@FVXN#ct$l['."d1C2P5&6IRnCl?Y/cu&RacK8O//7rc__t%s<b*6!Ag4$<2dL\^Y[pVb%@7$N/
-%gK^>@fa-;n.=u-EK"_Cnq\dZ\PY(sR%[keccs;?]HFopi*r?]77*N*h-sF^8'iR#<\:A#^1e"!.8g4[\&map5JO<]V%aGK[ZZK9[
-%`piJ5?ke$bbtP3GMm]_((7S)_"a2,abbGpL808n>eJr(2c^=Jd%/12%Rua5hp-rGP?QA<2#hfnNG5U()>-prU"MgTok/XSeWA<[L
-%]an`s?sPS4GCG6pN3>M#_Z:nmBLQmm(4!I2%UhYfOV4WGpXffg_8^ik>Urp2]8@!QdSBsu-ph["Rtd@UR-c:VS%7BXEq_b!mdj4,
-%,m\D%ne_*iR$F#%F*XRN:Xp=R#7fjo4`n/2#sH/thF/l(-j'W!NJ4,[bgEIDK%;)XG\!2*frSqKB'"["X/T=)TUj=ON*I*+2Lsdl
-%Mp#q>5baj948Rt8E9q/7mZ%0e*_VqKC*Y%M5bBgQMSjW\n@Yo,ej\Ve--W:CD#%L\bRO+a6sXjSLUj!HV=&F?Dk'VI=F"3;95A8V
-%nCCIuga2p(d][ta:s%Y%*4.M"KW@b*Eg;Jhdj6Ot\dXaF(XEIHYYP].cXE)#3HrJTb`fD%Rj6F+ER:_c#gWp[HtXiaIS+YnK!#eo
-%<RK4EQo<>'I#R!qRU:,_e:XM%fCT><`l/ts1pe"(dEmpOlZ)9j+#>jOCMIH8o@i%6oo!d5WGICTE71OG:c'b]qmOsAR&D@!%MIBQ
-%>2)&`0]J87Ofm4DEr/#8UD:<%He>bTY]sY'R/9s<&nJ5>JG$*+4-@`n7.Q+!Ht3S6-p/9YfGf0jFfA.Q\;4D+_5UD13eKb@46l[*
-%V&q''.6*O`_Yu)s5QLe2V-S"ZER/8[6+CRdo2[)H+?fY4;/`YA!jFMM_R#.,8Db26$,R/e!YCUBMe$0Z<6):1qmm<M=[VE>e=c1d
-%,onUb'Xd)AqZ'RoGh#f6!mPqsZ?R"e@M.K':V/mf#!Q`XZcR8u:l]o8CsIOa0gYh>]^/G2W(Ab$Qp@pq<1^l)kTcf0(O+7YM7O7q
-%9`T+/':W]sW:^X)\U!H--$P([K*:7_"Od>\q(NH;P0>6L_>[Q%bkfisMR1iO2[%"<"#sTRd@am8$JtkA^GE<7M&9Z<:7I_^n7&:r
-%lY6/seR&MK.02j0WBfaVq$j]j=%bFC^9*$4Pb7d]j>Var6s0<.?u\g]K&-=cR]7VFB'frT4/QA[g48sSd%fO)-:f*$>p=ZtB0jFK
-%J9<?Y>eQPF2+7lH,G1F1,tJQZ[V+!RUAhu^]25%:(aE\u3Ps>!A?Ip?dI!O6!YNp`KIV6GHYhR7B(-f\1/5`)[8ZDCioXNk]5eOh
-%BW7_M9(Ln09+ektp:e&d;XCUthO,1^5D=T%/T'4KQco7\7jh%IHW=.,8\;d;C"kO=1(ro23B22F)B\\iW1?0JLC$u[WOW0-9cIO_
-%,J3`Q,HXH`-X>b-dO%(M]RD;$ZuEkX]+^^+%2Y5c3/?lSl$R307SjAn]5^O#EY#uqQT6j*>BgWe*Xpb-I*c6:l16]9N6EhiB5K_n
-%S`OWHkoW'F+VL_A^Eo"?/VU6;DoH*UrO6qX/iXBIU@liJ=agYJJtd$cY6(#Xek4I]ABe6d*JqkrhYbmkbZ'M:/kuW&FP@pWHU="j
-%<K1'M:E40=G"K7Cd]rM/Z-rEU;(c>BN/^PP52i4`&Qk`WqfQnYkLJ3BX[.]GC=)8J>u/W,/djMqA48X`9Zk":S^%*I7XG.YAqpAK
-%Ou9Qg,6bsq4^@kNQA\(2RS%N_A"*mY;H5A'a3\DVD=).+2Gn%kOtYTOBc^EeRILL7.o5+WnqtX*/89>0;9Dl1RVDVgFoB*4jguJ9
-%pTfE<dD?&<Hrr\sie1[&fjfT0g>mP7ZQrR?hi!Pn]#p?;+n2R-;&;s20Ntn#pO.I;;kh?DI%n>i9F6H,^n9qWM%[4$8YfqrWO$g6
-%0QMaPlZU"BB;>akg3HSK8:cmef<-_C')_&pqR?B+W(nDG"JSW^;bp6G3+ot1"GtBWGeHd]@r;iV8F>WtSSO6K.II4OX/lD9ZAKhS
-%<m`1Rd:g-b\;LIt?C.Wr[pkDV4_EfPI+gV1B7@/7q)&c+?mViBMd&7GMiL1tAuq"q0f!^1<ku4"';66DXK"i]E2@&6</&94]1h(X
-%Zk^X887YjRDVAjEO3nrkRX)cabf!I3No6[LB]i^EpV:Fr%IPicM2A_<j]Y:7k0r4DnM2L.@<$8gkt5bm%Dd:M"HpuqC[R@j0Z'*'
-%ESr)g[T\r3+]uZAD.u3K@GSi.X2Gn".Z1OT(`.]id)fUIqr;P.(hYP7l2jY=?L9+kk``$mR'ahZ5'5?:T^GuCl,gYEKP#2Y':=)P
-%'"c_YI:cqa`''D7Q4,ZEZ%gTT1b;^62DAQ`gVj1Zo#[Ypn1d\GA72,#oDj=C+[O4'\]aVt>CL4sbFQZR-tEo'AQ&*HdJKp0iH`*=
-%f6B<m_K_qpH9d9FVWJp!H;*Ub?qg'^8m`@5lOc&)\.a:[l$O.1Sa(S_hb4nf0Pm+lCGcFV#+aV@[F>tBL/>Ve5m5sIGtbo>1U-r)
-%S.6lZ&]D9l%7#LuZ&C&-]d0f)a=r37OIR5#N>9n>#PVHHjl$0>6nk^XO6#qp5!NBOV$LS"B%X%)';G95-"MO6hqLGb-6QPuV=F7+
-%&6.?.Shsl:rde?S:o]hsMEQm^$+e6iXEcqsW?)^8Jt1aqjY9m%l1jgk^,?e_pB#[R</@3(@DE!ZXPB>TWZ-F4fFoYG9miE!Lrn/*
-%nEG?[JCUAW(HEgU1-,IY\#e-u9Up%%G)313V/Ye^Sp-crJm$Gm!s3:joO(.WV2q$eZ>NB<`+WORN\#ZE.Zo1_Y$R147NWD<7r[nm
-%HEE-J)XEs)@2OQD*M]MC;qdm5BDViXR^m@O9>jRdHXGcfi2R85?2Kl9++f?Z7p$G[aSKHio&%H$M+3:ZM+=0G)Q.ib?26.8C$j:D
-%OA?AC.re,W:pu+V(!k,,(_s.hWN%tFG5g-TIg/.b:`6=l"Y)kBaY+ssl9Bs-ppns\+6(mJ(O2=6.N'!+]:B>ELRX.i?D'pAGIl",
-%Ol]u/Pru>2>-D^H?Or':'f>5j#8HPU`GY?mK,UudE*_/<IQqRR_^(npS-X!K`^(OCd-Dl1q2dt@UCJ?r1^R%qk]*`Uo%[b@pgKSW
-%[rW5Q'm'Me/csfAr=X_Pna1&>`_$B_e;QR?=r9QI@%9sFSAA)0e/]\L4I3eXYbEq+f)8iI.ui*LqZI2(QAU4I[:bo<M[KrYHmi*$
-%RIM,5BD-c-,VX+0WIKMl+t0OoF+sG2RqQQ.U"u#/+e<\FJnO9GjuN5YM%g_=V:[5F^9A\q',\*DBHuI$O'YH<&amp)89_L!H/V.b
-%jqL<XG6Z8cd*VLJLBrr.(oZcVj%4CW`]&\E?G,Q'0IGRpoZjU-\jSuH2c^JpTq"NrHf"GdoRSMV3[aBm7sdP+=,/iRZpp([p-GIe
-%KNGiEM+Wr08G0QsTp7uQ@q-l(=(?Le_a6$X886$9QZXLh\OS76>J:)UpA#r3%9M^nec/sU/V3r$j([kU??^/tA)Vc._n9j$@qNiW
-%AfJ_Qg&L[!eS$5]n@We60p7@'H&>'Abr\O/k#g_<Z;)R0@'oL=0\T&dRPB_nLN@'!Yd1`PhWm4jP*C=)fo/gll?ClL_4Wf2o"$Ym
-%C%I%L\31J'DGBl57\Z2L&`&:uc^*'M=]r6je=$i?4Q8,BQ-6[DFJG-<p,.%>ka@S?>=krXK_J&RVJT?,9V`9O^*PgTR[*D/T)GLe
-%S]`KNRj(Z,BeWJAh./D6#BgTZ(ja/XrRT7]OSVtV_>lpBT'M1FJ=1E.Q*(Vu6B#]BC8a/$7!Zm^nbgmCe]KYN^$8AEqt]O/[WSfF
-%MToAse+-O?htD"'*kl1V1"TEGPh;9@Hdk19+ZOAo`kagoX^&?EHpMer?S0IKoShBo)3rH<;O8oL]dLib/pGr6bU%eiXNhJY4i%]S
-%C+I+sS6g-.B.C/VcYP,Vd0#K+'+[XEasG1<[94dlpe'.aSq#91S9SWss!HPh&`8p.rN:53S[GdK,8J]7K:'0*.Sq<1\$dL2I[HI+
-%D;F"m&aTpckMjK>6EKVsGhG[@]D@;ED]ah&_O/e.h07e2C#q8UkVBDIf6=&:@^s8qPWdX\D>FK1OiJT%9g\`8,52qa%OXN,m/uUV
-%[dl4J^J]t>Jf"3Om[?MQ)&dM70[`3G1b!)PEn#C-W<"8lMH"9!>2aMmY^S63Tk,1]A[EQ`WhPJ1$S+,f)"+!Qg_VZO>hrXBRoSVt
-%$.!uI/&BRY*XktMf=0@Z[3)q"HArV]&,ts>X?,aOp[RWPRun_2"$/'3@m4K!V&7`7;%P#Ho4'Q`!7'k.Fmm"kSJWop/.9E?r:no8
-%J?W]i^_)pAl/"D<VcLBX$+qn.>p^u.,j10B&m&,;'dSM<8OoO=lZ0KbF(1`kb`+LnFM0(hd5iWlT7HHeN\?TK=q.9kXJ)<&LJDD+
-%T)^0B&N8#qV#t0s.e$m";%CF1OQF^"f1^trjanRN[--tlB(G?#l;.aZ.-2pmjC^cgaW^'7('/1M53mo@?n1$l;\deO+Ge1'<*4f3
-%5Q(^gYD1V_l&B;s9IlGR3".#I9+<)8Ot?;k6?%h3jZ^kh9Hn/KB%^f,;:g`P$Q,(3,_A@,#N#.bjVXj9h'jbJDO)B1^W^CD1^Lso
-%J(!+*Cs_EUD!ZmbRH-G-p_:!DDt1baG3@ZOj&I*(qOmuje-q*T.RD@d\DA>jPK.>NZY(@u"GOBY2OJ,2Zu6*"j]Sh0_?cAY"0j`@
-%TlH&rW:k5ToP2k5k!&dM?K=SAYRi>i0I!%cV)%B?O&98#ZYg_6HJ9Co*dn*nileM(pT=Magl4`VVqdgKb.-Rm8elf&K0du*+u444
-%=B+_P%9Re%E:jAd*`9TYl.HD5&uhPgS_,_,+"O)0'_@oK5/T-(@fFB3f8SZV=Ob32GDR[t75_.3&JP=A;S9^I:X\(C<XU%V<o$k6
-%W'U]#j?lW9+ne7$XJM6+&+$pLWke[]NJ>[c)0F3h&D*(RAM.=/_Q(/RkN@\p92uco),l%t4s`pm_bV7nWO?*-,fOo?DW3(E\[0_H
-%$4FrMpsj%1kZQAkM]FG0"lDnX@Gj^:Ef&<KfN1(V?TAkolXSJC]Q^SLWDUFbe.F?bk(c-!go=]4e-LDd/IA]VT(Ro.26">WObPDk
-%I(pK'gdudVio(sd[j3NAXB.?\]&&m+hp)r->e+L%].t9>ocUl_^&LsO^@0hc*!fPmqU\A`8*aXkbmSY@mEEP)X&SFfQI/WaCOY^.
-%=2m=q*.Q]'LbDA%0X[Ve(9;7`G>(6hcO0_KbC6p4%WfR0?PF1FVYph\fI-KLN?/lAl4PH<F%/i]Zp87"48,5am?puS\;)?o7'P7-
-%2pmZQo25[7m`9#..,u>h[Nfmpq@_k;&RhM"I:Y'SPRs;@@%ho,eXtDo>%$0D<nsk<No+8omE)[I9']\(OQ>3P/(iA%"1[TmVk;l2
-%0;X6tZ2mY`C<)O\S1TR.j2k?/"piIeTl_S*WWpt'&D&gd,X%s%P%[eFfHK>ME9=DsA8G.0!sj2R6aIFF`<[,2Phoi\n*HMSo:e1t
-%BKUGi\&$`,@5VE0OI8t,@*</;5Sd/LcB[ZDGNAMGj9pT-T0tei;UbW)V>u'[c8WSIj_d:`A$+OQ2EOZO9?4*[2t"ubeN\#Y+b+%c
-%4bC"%GWX."PLia#,#Cu'L-%Q1\\+?-e6`ES@jO1idX3q;DoHC`$2&;;O*`gPSO*mZW<a-<-u5s@GH4<WEaHYe%e]%8B^&lm,^[BF
-%o5<4894oV)9iR[PV;XhfJ9[$2=$B4)`RLpG<=c%63<m=k0a#[-;Y60rpeConlGjb=PB<SDi91S0C:9N@6*ZS$;[t1`[k-N$Y&LG:
-%U5:WuICQK3V4QC>cb&W5C-'5S5A#DQl9gih4mciN5C>RXQ&?H8pmc`&"!=X,K@Zuho-IHhM_aq32bPb';R>GG>M[hQo`LZtGH)bQ
-%+j9p$rY04ph9r7&W(W:GcIH<l^'Op4;F!*j+M&#uRA;5[m9_o_9?V"l<[hLZZ;Np1H<me*P9Tn$ZmgbfdIPq:(][=?T_\/+^EaE0
-%W(C=7(e@o6$@d%uc/PmnJ\5!ibf98K.h)IqRW%WdN>7]qV"<B>=e\6>_@H]8[p7n:j%W_BX.^L07"]_iFd2+7>Ge]QP7q0Sr#fp,
-%%)T/Z<E7PD2_`cM;!hXeh=F-A[81YHYANHIlWn\9/!'P9,+)niI+KH0_B6,0MtWD$>$eY\]GibVLrh/qIKM.CYSWW#Z/0Q-XU-2p
-%9=-Kf0ijt1Wqh]'?oui/>EmZF%H0kI9Q+s+3H@"`DY)"n6+Le7<CqSA2W-k_B1ZX3)R;Tbf[]ET+'_22$JJ'lfGfEoT0<?q*d=%n
-%%\g0O(\tP0kDLKcFC^U+S>f)XKZcoA7&WK(pO5>[qiIG-YZ5!uHHbNDY*u;1BI/`+Z"dFKfLTXa4Z4+5i(:#OB%Ot1(H$iB.;r+G
-%oNE==S&!t\#29[_Up9YD6L]et:=!]bKh!g]_$DPI3iT*_DMip!jbsG8KMkdjI1+]f!E+RV!E$iJ_=5"md$#_JM<h\4@K&g)9'fd<
-%+BnH6flkS_!ZE,US=_g":XM5I57)qtbb.sS+#d=m0\c/b1KfBXs'B#gi44Q/f"@Eh`nC+UmP19&`@"L<(7-FYPlVLOhk^$93'dl2
-%<D1?9h_qGoiA8!e>mIr04L\P#TB$Bfqdj(lU1Ul1h1I35Ya/"2o-c0k@ncNQ.E:SDY`a8_XEnmXkrp-1Q9AOrQ?Zs5h2T(2Q?u&%
-%ii<gXqJ)1baj?deLLu+@&)gC'+aW78:PbZEWO/CI6Jt9Y17"<dYW,"U#tNDUYI_WY#ShsEMAtOB[fDVOK.$-=DusT.[`VCca]95G
-%>cHf,TLk.iQcKu4Z*7L/iG<B+7IEp-C(bc,.Y1)&WG^S`if$CM.ICQ#R5/,sKQ7n*#Uu,O!W<m*/_R,An90rN^rl7daY&`DITXM^
-%)))T?-gm5Yf(ug\UmNrV#F@kkK"STeRrWj`N;@LY4n$&>qK]@h1i1j`o6Ziur_Uj'k!Btf!h3/KmI5HpaAS7YP:@(68P-YJJ.d#q
-%E7WbR:?>Dr_J1M&YCpifF1ELX,tD6]4W>cl/C3^r4umHqY.tB&^Y'`<Htn0Y2#<NAJup4c]i[[_+]"s;Cur>nq5YFl[@[>!=X>KL
-%q[pY]V*[!HH%<rAY)p=OZqlE)U3]R)Vqa%[rOKQ7I5:/DqPr&#(gt3_Ou<!GShO2(aY:-TMY7rJ/IS@;QDaJ>"u+C[cg-`<c#?Z"
-%msmJ@+hPO$cT\=Zi#"pFG-tpH4HFmK2h+.;'<OB(T3\sY4B8i0EEA_Wp]97QA3"D=Xt-c^EV&?t4M/k#&U\T)bSZ7)=l/Ki<+FUV
-%PJ:Z%Eu'*IWip(^=(/Jkj\PJf6?MX_`Wt<r5AXJQ"QUu,jlWm*/"OMB'&oi(PNRG;I8LqUEgi\nOaUC=B)R//M_uC@)d+#<i,GZ$
-%Pf"2!7m<GNg!qL`dQN.gD>,ZZ(gfqmkMY4n@U5$ITO(aD9t0/3mO^/]_-Fk[fQ"X32bBbk^[ZGJ<*/PWQbC(3#-Dq8F^#S8X))l^
-%cpt>7P5#"UCNl`e>8%"JOW)Re&nVB@qU_MF8(_D4+E%VmD_UY1r))9UrhP?DKU9AA;C6_B.6I#lG6,=0KV52,eGobE#6QOR(t?/V
-%aq4'0VPtThgUT;MViN]-"erS.^p=P4D9$T"qhfS[eN6KT.i&K.9mp9Q1.7s2^ZSd'L^/BAXEE^(hNKjVmV;2=OWq<LFn_]_WsMV-
-%,gs2^<1<22f[Jd?MNpD\VjAo@^n64$^4J@1n`KFcXE@rhq&2EZ_ct)lZ9t^;h3+_^GXf:?6CiOO!:!/7)5dDTaX2L_0E*d2X61e`
-%%](M_<QD^_XO821J#gq`%GNlNgBE2?7>0hufsE"l:`5H!q4o?NZ_\ViNbT\"53(Na<Z6:QI?_q]KkRDh,Qt,Ar,!9"foP%cSeqL9
-%+&L.0hZsQ[D?Ku&/EMs!RQ%"<DF;*#,LO1gpD\s/g3->;Y9d&6VLr*C6(6h%55Fto1%%g^X4g4uj=UUh.P]kjReFDjIPo+.,1Y8X
-%XX0C67Y,>A0s`5V]F\_ioMTH/@cdEbI77)hBum&?K6/Acl=$FZ>K?G;QGYkF:A"'?"<!0Mao^rmDa)*7?895rO1Y#Hd])=,=DXmj
-%=VaA+L7PKV7YXK,2@@]k1M+,19B2k<pt?Vqoe*rN1$89&D:FPB!NWk8fX"dIrC(.b=&6-YK#/h"<@Y]D,tK/R-7Crg(-j@KX$7AV
-%0)co_.Ek`k3%`;qTl&0S/bG>kQ^(nef)JMTi(:&I4@O"8iF?WC"1Y<kZ4;eS7sKAl>`oO&P-GA,>#uR-_ZN0L`B/2-7,H?77Qn9`
-%poNoELY[JV^pT5pIC%=UW8$%nM2aekp0sh2>7>I%qf+0UH^DNsdDIDgVI@M!@g()$UPMrF^Fkqljh&'D"W526N"MT@AiB6n7_W%N
-%'hfjNU67>Hr>L!J)S*@E$ol^$kspGHL7H6>)..as`F*EJ0PC*^I/S=AhZEu+j/'L(iU)6n$SjU#/lq"n(E`cqoP0uB>XBcY/Hr&9
-%G4SYk+0gKoU0Gi#ESp?%'&;`#*ar,kfO6Oee%,_qDU.Zo6G"l1:A,hZfF5tfQ^DA#+8-k\G7:MU^EJ4k4"[n#j>=*r5?70BZW3u/
-%XB4[df`D^hVX!/SKU),0jCH2iV#XGs^Z2.7O)@+Q_9=G$Sn$VToWf\iJuLVMG<L1.LJI2@m:e*"?A<e0V[W^1$.J2`m-KOWNOi&-
-%@pXG;3-*j:^tgq2[k4ci(3U"UbU*''A:.Gek2c\`&o573>!"aqdjh'tg;4T*JOCIN]*.ElE+d@$LtZr0d/fA)W,DFJg<-uV$^*cS
-%ZKYmG7[7(iHek".+)sr:`P*"5bD6&a1AD3Gj<'6SD4RODp\PQZ/UC[d^1U9jih0Q2ZBAf*0&!tlRH$p2%-m.r\!94N>G_%q(>mR4
-%>PBef:EFk&\tX5dc<djCK6*iNi.UPMj+"0Q2cSD9[)dSjZQcBHm5'jp%*mGGV,pfFQ7?!b!gh\$D`qpO$iDo6>1oPTUiAA=XJ6[?
-%p9@$?j+Off,*K5T,nn'',9[$a`BWr7/oQU,EdUV[r]]$TIQ3N-.(Y4Fl(!nlQB1-QM9`Ni3Cd2jZV<-9_',q\SJ>#gAfcGk2^Nb1
-%&XN"rKB`aNdb=)0DtsZhqtUY8>&#BjI@V=#p-1rap`?:F>"#t3c!3)Mp$qG!fRC)6pJnd2;_*F7O5)G/cITr*VL6OX3eAZG5#_,&
-%KV*+g@LHuXEqPX#L0"*J&i1Rf=4L(D#B5fh*P,VXhEcc\Ds>ElP6eY$eQ/"j/0;u5$ijEiE&6N0!$hZ?5Sho;(N?-!YdWlr-P3*D
-%b2.qTG%$YRe0cZON)a13[]c=Q,;i:@YCll)B.[bL:gP6L0ZM8mc$.(N6rSQ?WfVP:,uCoF8?tjnSCQ4NDh7/8TI9$>h/cMf!l\)r
-%+cqi]5th>lO;Vo(muG_&WrV3o.lCHC_f64.?Z4Nq^H@H*Om(6mC1DXc`'M+M<5FX?Wh7dY>1,Qn?#]R*/&PWFT,@"S&!c,d*8IZN
-%Za2R\95PiX([#$(WLZ>4'TOcTXXdu__Co*k>"^ak**7LArCHhcTKr_H9uQ&i_Or%p_[/,`G"CqmRlsIp$:M:8QlWg?MV])#M!'os
-%+3o"4_(EN%<En'54j#_KrKP^SDr"]])"oPS6_4rigDV&^G$i4lAeb4jDA'(/%C:CPg4`G)NLuIeYC.F[?"].TOK*"cmr,e*<;)pB
-%h*1NjL5e\D[OadSERSo;$#;m->*1l%fKN9"KP69D[6LOARD$Ft2iN=UA3]^L@,4Cpf&Y]>7NO'AF14tmd'p$D3Elh2L=0A4F1HMC
-%+cXf+n*fCYZ5+f(X'0@H^D39>T!lM8T6Qs/VSl2,#OWaaA5Bc_\4i@'58BcNl+cK?.lF1uQ=_5l.JpJ_FP:_QV`/473AF#+>S;RR
-%lmfob5s1M-(/#X87D=)uVI:dTcYOO+9+ecj8\SbY#u[O$p1`,rfG0L'WsauRR8QQo(=O]uP'A6Ul&tFsLGTs?99'rJjQ_3Zb>^6V
-%0WG--(,Sg9X!8GYRD:Qt,SU)<.;!iE(XRlHjfUDC-f_RQ_QJ+<l1.;;(X"]lZ)JdH>@VD>2(>M0K^N;fpN/7r6j%Ad3Z,%+.p:7r
-%(8=<JF0pc68sEY:DC0Hf5.+.e7]9,!j:N/[+DY;h9%LIPkH6YtTNS"MAk@8]603tO)dNWb/D=rs/>dHQ."dIL)jAg_`;;HYLGSjM
-%jWcHGU-%Qg9_^Ng0I%BoC9:C@fO/l]*:nd$fW6].P5SAR/:!O`VB-VL<c9qe`Cq(9bJ5&4AA@cs)9$4!CS[EDE&1V?`%_4rST5kb
-%*aqe*=7R0EA"H.Z265LR"j/Y\E0%QY(FlMYfg?=<@o>W`[M9$(2S5f=fnY3QArGjt@SnlLT9M-m]>1ch:S^&M_$BfO*:+C;V$'c>
-%p3bP]7B-HG+%2GrdsbKnPLsXEja)L]C@Pj\BTLgW5F0NB#]&D,$#n.LW[t8BBU2_^6T*dE[-T<D7:%C2qc]:\.TIe"T6s<aOgN.+
-%p)(9rnQBmJ1U^0I.;Qr\H4'NHkE@r`pp$S:O;Ie^dDL<!SZ_2L=9`^'^W+E)&!;KaXf2EDV`I><bdL_gHmH)HM-!#:D32NCQ&4;&
-%p0/Y9HB54`oYXc?[kY2_X!rGGQP[[\kua"S2'Nl.[&7OT8hf&,pUaf_Nt#@`JN0haB5Jg1*''g-4HY#>K/qsLG2.NeI97Hb6/bh<
-%XtYMJ4(WSt/b+7nacC:SnG/#h=*t=f1$h76U-u*;gdUW1Lq+iRjt<Goi8'_nm-kWO6GS2C$BVlh*mYSF3@Xf`U@$UtIeI`U2I!nn
-%gF_K+%bUcS+rQ7RPU)g/CMP"Vpc8.Ig+$-77X4$WflHLLZkkG\E^+H9"'*cr)UoG#!X&D+6T1=47H=*e7SeOi7H5HTOdmd"SseU$
-%&X3ZF"Cp+s?JO>ajtLjiWSX"FkAd12J=fc0A#/Y@K6GqX#Sq8$Loq+*M<*YpqZ)%15jX`>a.<a.@XNCGCta\-oE[cC^4`-4SuDRC
-%NtddtCeo^hc#Keo&QXf!qO^'b4eY_F\ZMj^LL3)ckUMm,R]gPE%U2frZ)M,IHb_JW&0kA@EGDm:/^[aU2#(i)E\1eC%h>L<USs)d
-%NZA<c5#9GV/FooF(k:YWpo^>QJnoE1,rc&Po[&W"<qk"Dk-g5P4OSAoT`%Z_ihn?<n07HQg?Ac52mgaoJ*_(o>DW9^DDGmAeas0M
-%`_Z2mpT^76Jr*0&Y(*afrU63os*1c,Nq:tQs4@;I?Tp^Sj,a65s8INIO#U2;o7+1HEN?H2jp#*A0.Wd%R`<YK%u"$TM/V;-V4/ZT
-%Hjf\YWu5dZJnAR`R$NW.3ZkEo97\JAj"i@e"F5'iaA74=:"TS*PLT`M*B\W2.NJWZdb[G"BdI*cS?i*5D=aMKh\g!WOWpq09;f_e
-%bRpb-.`0m]iWQj,qR;&*pVN<pg.O\1;aI@1,j$`_3$ut:TTj7*V_"?DZZsV1%O[#H\1'mq/icq>a$?DT\QY+NFT5J38H]67$VRI!
-%)63(;'f0)i_Bktp?:UHUcldQgaL<Ieg@"_0OY:Z^]%'l1PX2l8Wg4hs#b!=Z@FFhc!5eVfkr/tqVs9EfFFp_R^-l5&L;Dq`80"QF
-%6]Q?0OW@POZQ_=)Ms(,ijm[G+LtlBJd$>[h=qqW+@1hm!lSs8CNDeFK3j82\JkS'EDAk^O&SKX)b#J-@2XN>k_N"5&D9g63VB"OJ
-%Gm6?5mbp,j(cbnS-!:N9qj)8Qhnk]<#epAr_g'9mMS"MV_'=jU]!*/nDCn[4S/%*/(L-53"SondMG-)t!\6Ura)6Gp`\>2%=$KC_
-%H4)jNf2npPSsuFQfGZQ9kT,eDFfpLP.gE1bQspQ,H)>F/$`K__/V?b.`=(^[W@fA:X$>YC%SAo`[)r;<c5\;t78R-!o>VcAWC'a6
-%V5ndJYKs7%LV?)=>NnjBD::NdhmL1p!-_O!7buH/ek,hU.HioEs-i^4D\7'!AN0:-PmRW3,G-iNVU)EUC=8+NBbZt-=>a/,LrMP$
-%4e'J@U012<>IS))BRKB$bPu7M<]e`\OKe=RJVFDe1#*F$k3pOI-<!GDn8O/)T$F^4ldt1@.,\Ha!0NgpB1BkW,6N$7<0/<fj@]9f
-%bVT[-WpccAP#O*PLT1&%*@jB%kX>2>,<99&;<2Pd%._c4X\iO;0qVQeH"Ph&&iNeg[1Z<d;0%E>#g_k)g`5o,$&"FF8Lu2"T1:iR
-%C]dKa/\pj[>R6\mCjt\P9(kYT'1eq0g,'u9'4UtnfOWqUWN0c7X1GtZ.5=mOoR@2VM6J=>jG-F$6]m-Hk=SM+GnRQE@!=h&W/,FF
-%Mfh@tBd`k;<mB&CJr_\$CIN6kF^bYJdM@A^pe'B,"3l#Odt9,3+*o$Z+rFb"F2`U'$Ku4-gL@?0$`OC=o8'kNU]sdsqU2'Rp'UGm
-%Xc*k3KERs64G:8qNprH(YHkYZ;+dO$HG#b_V@II`R,1%",5+D!m)Wumm^8ub0J1opI'sD;;oH?Os'&0j%eH9Jhh=D<;\`9fG<a^;
-%&.b)JAs?uM;T(sjH;R3pmZOme>HAF<IK7KBrI1h+EN%6'%>^%(dWAZZF9J_BWbR^N'S8Zl4?:p.e63*'HQTGaQO?(@ggHB=G?10C
-%RQ]ENA'[6U5#_^5%WJ8V>I5nCpfmkTp5D&<.DN)Do;V!3*^_*8Vt3[pYt,/M,_4goTTfC(U,$d!1gS?Zn3jUVO]tLHEJ%ij4g,#X
-%oOa:0*H6J@#2S'_`%nO9<s7oqIKa[8/0Cs3`sS":FN'Wi:6F5OI.gLsM1hu)9\7'CbQ3UTO#e:*aF0\5++J@!Fi'7nQ[uj^`ni4m
-%^LM-LXs7B0rMcS]]Ss)cHC@R>4!>(NH+@`,iJe8h@HMD>N'SVdQ40)Y$9H4k!5S>=Q)UC=m%AcRSI=U^Asp]\Efb6G"$.k^=g!n,
-%H#\'^6S-+>?nR:fKo4kJ\_+T,&F8Z1;$E3^WC5Dpj\OS^KJ$Z4o%Gd@/TUB"nDeEsQhdOhdqfA67eK1\QRLk@[&f(*k;)QMm1qNp
-%2\_m9eU)pIk`R?G4G1JRmJF05I+bHC<B&ZjK<[:hHF*.#Y.+D#'LEAGH<3!a4%LBNqJs-)0Y7DC`tm!UYkKU"(TlA`&KUa*GY9q0
-%*.he6-qtJ"M\eba-+]f.a57kcVSgl;8_OtK(%c)9VMFXP3)%W'=9Bq!a<6OG<(?W;'u;["/*JdfCb^8Y)lZUH^YmY4N`>HO>o<15
-%^67C_<e(hh@>G3[9m6"nn?kI"a9?p:h8ikY?:jO1UN4M*4+aGdg"\Am*EF5n<'W6d01(9-'`@`q_lSa/N_Q5hXE^1X_BS%lFkQRB
-%5_Cb>he'UD1lk7]WA@dqB"$P7G0W^p*=J#j.qO>ANZZpJ+3o7,3Hh]W[j`WZXLMtsXjHC<pW>>+f0OJLS[6%jm>32s@<VjpGQl@$
-%UhF/+QmGmi/T,P7/dDhA(gTZk;/>6pZ)C(_RM#FQ>GT!s#Z:gX.c0@BTD/O1cHZ8=_>bpD&+e,](0_g4SB$2E,i&<nna/<EBT8)D
-%RXS_T^ti_3lR"!:r2J>]kYho&;3@%6[m)$ts*[Acs(C9^!hPl6aU*3d*GK9c"mFtWKuLO=Y5)W\I^GB+l28387jtko:VBo$.)MGK
-%TYB*d>9&Bt;Q;o_c,3R6W<ruK<$'h.%EXg!:[us"EfgaUI"i$LjZlf>i<5gI!O)m1_IhPfPc3HK`/1%%$'ksO-N/A'iY6WLl*k.k
-%"P%c\"1A=:!-+6?.;;WA'RY`>8[Wt];;mjtF9"TdB`D1N(20_lT%c#a'Ro7R-+:ngCt*t4.5,=N;q;Nb*4;^fr:g\RklcRG:JW;`
-%_,8GISp2M4(0&nWi]89"6/aY#Vj_A_%u[uT33qn%n?L]^.uY#9@C=[L%5;=hi8mJGiLmT]PQE&J1f-U5Md4Z&#em3dF=&`TLK>B#
-%1:Z"9$O(a.&WFldkMO!*<TqUgFp2ggle3(DE,@gnR2SjuP<OG)4!!Ni7!g?G`1Z<1J=tY>6BlCu4<.jX8KX!h=P5*S$+@g#k'Zq=
-%<\*:W/nmjZ(^Fp%-0)dX':=;?R;bPg@h1qmEhPd+;_qs`h<pLDJg!e%11G2Q85<.fokm0ZCW]m8`%gsK!aT_Cr_>,>H)37)jS]Y&
-%He?u:grcZCDRR6Vi_u5-rn/(E:@?$?hu7?BR&<To4gX4j=2hP.8'*tP6s2qnF6a1Q\>3*Cih,!R;"qOu4A!8ZZsZ>+L\i^_8W]!'
-%o0bFm&I\pbEE`YXmC^URWQ=&GB/b!^9rfmjX7&.t9ANs2)Yh5^1j#bbg&'DffLp:1]sL>F%FTqX+OR,EMjBVc'NF)n%$u_mc;ZFt
-%D.=M\p!(n8pQr*cJJZD%%\Hr*U<#$61s\+4ifOA=mD??ggj/OPl2H/!n;_3Tal,5QJ\s8Z;2JtQdgR'\r\@AE]Bq$gk"h\H8qZ:M
-%&W&g*KHHerd8r?QY/gBGJU&-fH&*4TIFZ@YI(O:C9A5&]JOOJD@4Q\h4b3tl(AYDKWuODhp[s,3rZ#65[m?!-R+4j]!%K//_.Dg:
-%0,Ic#(W[sDO&ELq#!JhI<-#L7[e1_g+4[R+Y5d1;NQA[l5j3eMqWErpnNS\^B#[VHU&-a*"/C+$%-e-UQ8NpiWlnHomG-$OMQ`.I
-%;\P_K4OLR^XNIc>lu+,]ooZlf2Apcb8DYq'5umBl)ns"Tl$<qsa^2eg]Yt&^#JnbkLeYOQW!FLsOmVbq*KKIl'MRR'Fn!<i$-j[+
-%Fgl`"bH"\AH\i=>"%rMXn^#aZ[;KVH<+rf0JcMAN*9D)KqAISk0<\jhOKEeZ_mD9.nn47mTn2",,;.E'`FNc>dK32UH7[l<Q^me)
-%#.$ooJHTj\Z<NP.7PU:.N5i[Ec0V<IN'%lherOa.]"S9,gjFqTQ%fNr>drk<IR^q1aZa\@@0.62d5_pupduR=^a2[e%'5Dk@G%+-
-%;3BXi0CLg&PFLj9Vogr-Vu619;D0YS,a:=QWaO^gaG;h\Yro09]Oa`:46hUfOU?0#in\[C[IZfo#C.&dGP3s#=Eq*o`F?ZLH',p=
-%@ntpAKq92+,M?5dMa5H<,7CYZg\+X`O&Ut+]\S`2Ye)ta*H_-&bJ<kWp66#6ba(6#HEBN<C-(.\F`UYN&fUIDqi4n$m5%Y0j-jt]
-%W#`b,fB>f]:6P^2mWl<ZgHaiCpjVQjW?+-a&d#u6/QhlC6A,S=1Z%!LTF58*/VqfQ1)uh(Ej/nA<`23nF&ZoE7F8`dOg)0V[Y5iQ
-%$;hOA&HMKFm)#Sj/o[tV51$%m1M/mQrE"fHF;A=e=#?LN!B(mp%=72,KH4k0-?fE9Wh9CL'.sfWaIj\s)fmZs6Tb5+h<b1Mnm^Uk
-%g:?5M,lqXMqZpX%#%DHb(qDFYO.`@q"cWfR,slj&:G;DHr7>+10F4.O04m*h8!gohAB<@nfM9/e$EBPmT[2QEl1<R,.U79l?V7.0
-%/GC40`!EJ^\r/]mfB!J.bE&i;SGPZ%XBYoHEM]"kMdbKoLO<V./LE&Rj"d(,!@@d^c??I*P+PEp<O3mNIXlSRiCItA7Fj7RJn?\Q
-%RXU6!U->]GUSf^TP+8L&aOI(h$YePaTOE+)aM!Tc=Y%7Y+H`RBQB)]h*2&(.+O<<=T^-kT_'p<$Gk6u(ZB-+7p4#.^Ec<qN/r9Qg
-%ps`Bld#JA_EOI6CD!3^-HY=R_ka6X;=odC',nhGJ[0.PG;e%hUGAA%a^R)6LFSbJ8ZM?TQ>B/VZGqK]X]/bd^R+P.*=8082_g,L=
-%#=VFM^h28M_*TamGi#<L7<gD$e5_bCcM?u_4e#aVJl)Fs!R\)@hS0/eh66!@gA6TA:gW3(:3]Dg=0RoFY9in-$C\9Ur=Bf9Z`l_Y
-%G9&0>7'pYRQH+2"p:U8`d*(egC.NY-a&<E7b][r@;`J,)\a/4h(%i9$N(:WFn+W\;MYQGSmT7^n@*n%pT)^VlDRZb6FE7!,g$?bD
-%O.GqX%Zgj]a)/tMNh5n5<!NLJe#Z!<^PCdU>m>A28K\VaZIu62JoG%7),0Gh!4u!t/QGH:nM'>C"pA!nk<BOo;=u]KYj6J!bGi[:
-%5)14r?p]^d`?nr>o5Y4.c'u?pP^u-noL5ue/-5`a9B2Ik)pgGWZY&W]\#X-CBV!/_O0N7/)@+e#Xc_Y,]YOmAlCW)$(/^c:-+f4I
-%&Yjq"8?p.JHJ8>DkN0XP[WXX61ng03rbT'EnK^*JM!nqMS2E5RI40qH\V5;dYgA<p#6SB&;jBc;O2'N=..%?qD#"hhk^J>g(5Xg9
-%1]8MUTI=:"c<_"cnYHd[Ms8PQW2a?hE#C!PIO4^i6G[eD:etl3O!>>6l(/iI4htbAhX(>FIn3OMqTu),)dsQM5UgP^KW6^.RV:<+
-%FgK0F9c$(4>-^>fXtZmqZa"GKDEn6EbPSQBqk_?p)@4mY(UIRD3*=1s5]a!]9nJ%mHS@i.MB?&7`>5q#nAiQ=fkS.u,[#;0R`[8P
-%`tb@1LUZTj.>]0:WSk6DembifWRDgPR`h$Y7bf^^P%JV7OOIPjkXin3:i\P`I^4DoZm(^W&J1`kc!El0_SmU#3?sM?0h0Vg<Ns/-
-%=[MQ=87h7"lV!K@h"H)X`>`_^b`4oIc\VKZfrle`m;\*s,XF4gATSMW'kqd[COkQ/0')slO<\qTQu))=Tp!G4\^Rg06&6N4WfA)R
-%g4(#)e9c8l2&AQ$raJ/K!B$N:p?>(U[tsK6F10U7d<o"uUcX?2YdiU"UHjkj:cuB$b40',UV]nV11SWOhhO/=!$%#,=JX@mq[B`[
-%:(O!,,?V(JR0-+5-E*`+:!eX*7`T5"gCus):a9PS<lfi2g<si^hR7,&%PE<5W,^ng)2uKSTJkSJ$%`W%Hkq(7\d]C]A^]7`XqC8X
-%0gJ;s7[Q1jnA<l7oMgMsa8336Wm>DoZFZ<EA\A.ml=.gKSbm_%=a6"#=\&gBn"M'b"X/b;Oodb\))Qb>ifp']7Fb'K]3<>UKeeXr
-%.jKB^TOD?;me/bn4uo[]_e`QM"0F(`GERuj6r<WU%b`61>#"I1N(mN<V4BiPN6c_Po.a#7Z+l<aart/&<hk6s.H#];C&P$A8hs^\
-%`is3+)`<sc;&L'PhE`B[W^\R;LOQnJ$eA>OO'lu%giH&[,tZSa:3Y5'6l8nh<PH0/+gKX^KDEa3aFUcX@3D2d;Y*[.\1PFHTV5Ju
-%gomb8F<4'Y#>cVLooOT`nA.J`0[JZsm]`=JWsUq3Q3;h[l]lfYWH->nYAsP[a*t.#_IS\n(%t7AoV$PqJP[Y#OBL4RTiH(MjBcI$
-%a+9/"8ced/J9U8gmRm]8_b"#S*U3.s!pL9'lF/?C'M8GG!,?2.+?,u2[G8LU$Q8,]g/AiEmns[<o4GhT&*Ij$gX8:?61Yt`J`uBb
-%r%23?:M#UPQej<2+L^Va3'b_D]P502.`4n\i-jtP*^!ETVl=dO-O_!e*@JY"DcZ_PB`QtAidMC@M(^j`nMgJMc!uMp<0?tYjH\86
-%TWj$Lb=hd<..#HgcJb+l;t+MR*W2_?d=/WB7T]f$SYEepp*lsKA7T`6G:h[]eLrZ.UbhW4j&"u"`.'4/>g#;!%N:(%:&99Sa?MM0
-%ghHL>F!B6njtm(9*@C![!^)gO4(H]`'%GA[`L)-^R_=M8,ET<5Q-/6si=]-=<eEekdfsT91Er`ZpNnoXTVbcoNW3-dlJ&RY1'gFQ
-%q>*A_bF%bu_qFDu))$.hO)Kpc'7`!M71T/=E/jg$:2N[A`EH!U0:2V>&U_7l-4RE]#i]!!.lO!&Js'Yip"obihdcTKfP1B$Fg\qb
-%MGur0WgnG>#$.oqrYeoEY#<k<N1V%uG9_!mYI]8rS,9'oZhFU=V\Y&".Nu^nXl.P&,HgJ!MaZm1)=n<M04;2Ylg)X4.Sm*OCuD!=
-%i=-^L!G]hW4_/(,Ob4c"E"5f<SJLgP#c+iO7HthJ/'74\g4)j@RA`o/#fJfgXPN&_$b'3#S+=*QGGBrIZN`!'MPWVqaO7ciK:"=B
-%cfsP'^=gl"8/q2]X0J[#)GmB"L4@#_s.us_U8)eHT'LCL%J&=^&*ja[<<e;dOI-M/e!>06bMHnJE=luOcaqc\F3\lZHkL"\/6_Y\
-%aoXuXBtf_M+"QS<h>#W%gV$c4IL+89!\8e6)Y6#3n?Qq.b_Fh]MrEc#D&<58=^*E2rT6Z)E,5Z;@9Xsr?2is<Go-?6T]FYAN5De-
-%Wdk-K`TemWU;F7O8-mjTC]R,<h"4[/ISP)']a[i;hXVFQ0RG-Z">^V^If\'-4KV#\n8A(8+M,n'ZAr$U\0m]m=P#^'9*!eh?C7>1
-%YYi<*F/X)[Fr_W*,+la%4Pu#5&7O`1e!mHUI1^$E\%,fpnB/IjVu^O_@KKWCSIpX'9ap_sl.:loQ<Uj9?lHfb#KUUTo4cI>Ef]rZ
-%E=]u(N>.6f%^_Rg;a::]Iu2eGFI;RP_;O!PG;f'UYM_,TM2J[(:ZKb%k<&QhfO-L*E\e9.HBHUWi9XOiK`MuM95N1uSNZf?Ok^;'
-%Hke>cOr>nB`4*?o;ZZ/g=Wp#J9c#ePmukXW3#S5ubjKS3q_m`K!Mfo)^1fL^qtjXO=pVS$G+3L:K'dG$!(?GC-FbQ-il-"8B5S:(
-%3+fEj95WYrSSie85.X7\,r=)(Ag&A"KUDe5A(:bgg:R%to0o+ejS-hG.6Dhu#/@h.X%B#*/7tDOI;JMt=%1kO4u602Iqp\iR5j]]
-%PCOpi)7[&NTghhHBW*^k*(&t1qS[n^rq7,@\l8WOCf?PoA?d^dQVrpa*iEF?0g)UCZU0>MGZ9c:9l(H/n:I""@HH;s?b*:fX:\W(
-%pmIUWmK%(tg/]tmcCN_A<?p<X,3QP@UA'd*%\>DJ--Hab$G3Gt_'/m"#N)V8)%c(Tp\U^A48'ZU^qF%+NC`c_lti(h,GdJMc(jN-
-%n*_SCBPE%67OD*K1oU*R;>5rl_4ul6(O=FRjjJ!Yq^@3`4\,!=U4j<.R+G"l7T"O6RaLI^#1tk:Ht:JQ5<q">pTB/7&KutNAgagk
-%5&N#0Df+]Ea[HRL(W(#A$01nQf/1-;#C"nW?3tENL.8s#@-mBDDsieUH#:4=I);%q$?hosI`RJtBrjFKl&-99rc$L9,m[@ijl=.U
-%($oP#@'d^+R)r7-FubG(:%Wt)`a$?0V&TgBg3$1VWPE7<=Rj3QTqlJ7M!E&<rtTbF_aTc(@4N&nn.hp:mad=m.XT2gVk6?s`B,o7
-%6k_uVo"<;-Y>AHT\"bKj[S-YdZ&^hc<X+>SpTo7LG*7M)\<5qt;:Daa(P=ZsN^<7NTg_9-F[KBULW7Z/^BHVeDQQrsS\)X'Y.d2#
-%n'ik5BUh*-@$6kG:+L>A-au0W@S&.ps%iF!=8)bC=_VN0I=IHG:?)9uV)7-GInZ2L1:0tJCf7(u;tj\)dH1U<UXjXPR9[)P-qsjO
-%`I/#uCaoggIb[E)\`G3ESRf"@5[Yl9-t<u<FV9k7_d^YQpqTjML_W41N-\*il[@Pi2XN#XC",nt?D%t:n/1ef.HkNSUY?pkI/s,h
-%%`:+!rDuCTNS_d"He>OGm<UMFOW(@mf4.=6mF24TeAlDd$uiD?o(gRJo*nOsIgge:<8BMS.@@O2B"?C`WccpXmsT<[<LH1+d@=H'
-%:f/7)dt`r/TF].M7BejaT:)7%AI'qFod&l@)\DgD"RMP)a-Rtb5kQg4ciVZm&U8u#Gm9+5^8)#qkndbAiF]UNpg&+bB``Mlru1N\
-%n@$74n_k*+##MP%,57;!$5)\6pU[usg)J%<AiC1qdb'l@!&h;2J%qp.]I,]ASD2K,cQAKYl_$1Crhs/DDEI?iIM's*=rL_QbWA\_
-%p:c,Ohs3%^Zhh@erSl)]'f`;\;C//O>nhY+k2l.*HOj@6Xgo#1Ra7WPm:E3Zp6&";ha:A*QqW<S)+_K-a-p7e^q!ggfB1QLj7RG?
-%O#cIj)e_IffWUt:J`ut!@j>9$`rUkC)0@c5g%OD7\Cl`s!L%B#61jQCN>+A?(pDjf5/h17l.B]Q>6mA;O=elY3.\kWNVRnU\FVfP
-%q37.ilctVjm\"PBb@J>I9cZ%u+t0BIZZ(D%'LfZ\^oo1(T]@&l&s!25pW0re38:?m3&M"L[8AE1Rt\D35s/aN>HZJclYK>2h)uUZ
-%T4#ee8s&DJPWQWB#YupCmL)IKA2N]N']Q]%mPdnaBV,)%f<tK;XpE"l8=AIEdE$e`pc4cOU<Bc,oX^T`MeVl,/lkYEZ`JTZcMUMc
-%qn<=W!ss/nK=*YGp.f'uH:d)EG=tKTrL>DHA[uQc.rgEVLuliB:IA3AX+<1OitgFA`&6_K6!p(*epMl6p/*"-a)>it+9Un48Di1S
-%Wo(Ms=Z*]f1+RP$=".-U9WOZq^l.%%\KU,%+@>)hA-E@53WFHqK,NF)kB3VOi*Uag#*#aahob6BZ!s3IfX0G<dg*I,RDiL'e8_O)
-%@GP/3=0l+"-J+FgqC]D&P'^fm*>\D&QN-pDC9VDBK6kXBo=DkFK1q[i][8eU>8b'_6snE?";=9L,J1ZHBeAJ"cDT]<^&3fbG;I=9
-%!/?RPdGq6)`QlmJ!*I4.R!'\3Wk!WW^)-4s#L%Dnqjj.JDsL*A!q_poD.'ttIiE@3"*Q#+_V]aaEuG.QG?o&7a"L&m:LJ%+(QRIZ
-%bBCXmAd#["j3udB(REpHobVkS15:X.ci8Gg9sR$LSW#)^EEGLZm!fK`&H^m3#:P1GOs\P4_sdfYLDN5_n*cU#%\VArOO5/oc4XF,
-%Nrm=R+ZeE2?ggbRTuL"6j'M`7W+NYk)g+;MBJ@%8qii[6S?;>*ObKR'H4%n:\L=SlCE2cLK%Bg?;:;2qolY?:l!j"DI-khmHY)OQ
-%9#Rukpd)(;j.;Fsi6NVk'F/KREsmMDm**RB7"ZI\SH.qkiW)X#iCY:maDTgl80R+$hj^s#?<0g.04BCE;\jheWqXuXKO1p+3S0`[
-%/;''rr\h!N/KLg,]C#=ogqT;ZHe`9@kCE!/:j$DFH.a#7G)i<;p/@oLCKN*0CB=Q4=;PY;3P8^3Q6T1X3VPm8JV6KU8d>=?&aSiD
-%%K#MpF\6]4NY=HrIXf$T\:(R-.;-^nN4K;``2q6>gY%Jq:-G6$1dMKrbg*&F7,J'$l5irRfFa?Rc(t*oLEJ,%+meh4LQStlP_9K=
-%:>Yjo1jDo!1/^NnAB/W97;>G8O?k6`>)@Y3rk_DgLRh\`Q@S@@US:4@DnE7$W@*Vok>FC6Pl8E9*"?j+UJ>f)%LBKn=c(>/?)Wl8
-%38H1j;(S>jRLc&Job_h`H3WNgJNg#/>(oIC3i(@Wr&h/W7ChKqU2ELZIsbu2FiqQO-d+=Bimq,7M=5;OmbkZ^kMGkrWOit_a2U6m
-%'8ZdQe8u(@OUTrH>kI:q!i'!]K:rdkQsce02M)/#/G].((WE&0C2JYAP[CAA*oJMMpbdqc:\"l^lG9"cN1?X+QR=K#Za8^ffOcEZ
-%haVVCJbh27Ca01H>M&O9!.Rn.gpIKG\R1#ui2^Inb+rqs_O2E=_A1j1HF]TlGn:t)fP&0Y@^-4ZbOk:((YJ1.n$P5I&^re[[\jA<
-%dh3Se\;jt6cRE:RnDfDHlWBDKF^:'_7tsj/qKe>k"W[s%QLLg:7kqf`&<B+3"apRfHUi>V=J]j87]7=PK%Xtpl`4r1FuTs^fW?`7
-%m_\D6a0(r0SMdrAP?o<ORdtK)]Sp74#;`df5]JCQ0?:Ntp^G@dkUGFl\X`I(%#e21*$CYBn0VA=Y2Dfu)&5YdN^"W?gh"!1U(IBQ
-%'E-%]mi]FRY=f%49"2D&[5(^-L0i)VQ<aou4knbUL_i'[i'V37HscjCDQRnW;Des))M-(jWP/]o#^Z*;K_G;JZhh"td_Llk:@ZPP
-%Z(&P,o+N/)GlKUY_4TMte\"rj?7^D+UuiR0.(-kGFc7u3,7K^*Fg:.7B[!2FI=YQNX\moij/'b.:_F[o*NP-Hh<mMcQ)hQL4p0oa
-%#Zkq1DrXGbWAWA%c[/9DK%pqJlIIABl=3oPQ^Ou#lfq8JI-=.'Wfl)uO/_HaZLJ?Kqe[MOf5Y0(JJqao@'Y\r4ONPZ*HTgSk@$AA
-%_0p[<:Bn4G.VSb='OT5QfUg-XAAk,ajQFKCgfH$'E<e1.@\#_p+ll5?[":IBYOg*-eNJc(`nK6IJZc.\d'I0[A0p9H.+Ifo4-#SX
-%.<HGt<2$C^0UO-P:7AAf/:L)Lh\MDiIMAXUT'5?289-(t"q9T`5skXNr]Su*bj:[KTW7fX9n%32PY\\Ib<a@]ro^-6:,;4DVlXM*
-%g4SAD!e1@us/"qWLnBUHB7,<a>_oTN&'asN&"no0)7"7_ga3g3T?]EcgYh$8o^BpIXkn4R4\\h&$I7F/bCSXND7>0^%r[89(Z?3?
-%lhV'WMJ-f<*c&+G)guQd"-',@4+mT.:IF#)f<-$?;>d#Dpc5gss0)1_?gr%6#C9>K[srk0s4dSEofrKJIsh2j=BEQCIXb9?o!5Iu
-%TDnSg>>YJ-^uTj<@/>ZXE7.1!Va>NAk"CI$?1:dBn`X"AeX6q1Y&SF2l\F,D[k82OQMGb/it"d.]G<Z?Zl;6?`GNL\`_cAEfV3DB
-%mX9RAd7HtSJg_e_\E;j2/,phRSleZH`"5k4J)KY@K#\Zh2\*Z]=:8eblGl`jrl?8BeV[j2q/4T.f6%SeJrAQO)]\8K;[O#=KYlXX
-%8oB!bBM8u1#!ad\h1P=40Qs->C]oY9MWQ-.T7:NjpieCj_/`=gC9<KR;)6q$STj$DRd!ln@]E3dra=FGB(.:%QGRP'@o8=-WdBMU
-%ii\o_cKu<thGbWmi&Pp85!SX9;u^i(K9;Fb2H;)kd7bL9nuqq"D#WA"h'!luK;Z:/g@@<YO:$R/#;]hY`)&-Gm)!`13@*%Mc[6eh
-%io7GSNG5Xj0,X8IYgDLnn[7rsac4oe-dWT:F3&].(Jt=?M#$:>BOlinN0;^4Hq:p+i@%X_ouWuH2$$K;rii2`h3ajDD"l8ll#q3?
-%0`;Y=`,I1IIi-W2)Xp44%,(\5Jt$-I+dpA<FCdW,g#RPYe/p"d%_O$rn?DY(I<ah:dma08^r_8mM_6=46G=0r(P]/=mB\U)BB\qh
-%nk$eB$K$^QjN^pHFQ6a3@HeIl<@p@%HY2B?@L[_[cgq%F@b,%gAI%Z3P&H?l!uAR&l4+/lA'hu1@VQ#Q6WcmUi2u?"iku,OB%V@e
-%9"._?%9qtip.2kN0[A^`L@O2Z\+Ff.k`\Nf*9+8_6Ns2YIg/CmeJ@&^G8JU',DVr(#la=ls.p>>_PtWq*@'(QQt-iu#^,nQb=;XZ
-%@8JpaBQVb(WT'FG?UK2e*]aUcS&]u>YLOaVU]WL!%oPk\mg-NFs5E%dkBI9[5G71&pZonI&lcO'@m7U?C_GkuZYtqH<<U]fEhCB3
-%Y<V5%C@T\7jkRDOO5SXanNI>dp@*JuhP2`BR[P=*'BXE:+kk\jjrY]H`*e4<DLA@Rlm[Xk.7uQk%KWE-pqt9aT^8GKf9BNdF?ieG
-%M1tEYSfSfm-]Gp&gUf^.r<cl7Wq\;FhBLU_8+dFqEE\?+[Op`2a=5,ODdSU)JLTX"..bY+2KqnYqFQNf<!4$hW>P@%+o99+=$BHc
-%nJW*u_#9pX&1WSO^0iar)CTGj&2af#88L0<g%rUdVH'jr']T7FeE7mdp0)#'Q"4gmWZi;+:S7R5>5IoI(B^bfAd3I^;9XY_+0",B
-%1.aB$^5b??K"HBnfN1H&,N9#V((gT-6i^_4BN/C81>UP#n/S(Oi[XB$LDPgB_fXjq-u$UB7cL,N(pWT9p\P3P%5j#&]1J2D*dr\C
-%j)V`C10C<>n/C0XXN0YO=iK8p5g`h"_Fa)nfC6jei6-4Sro+W4K&sLS5C?<L,dkg&3Au/)nU6!pb=a+9%-tsV2)B@V-<-4`/dA#=
-%CZ`26e.c5Dgk^u-H$6f8)*?qA^D?-@BtjT]>JNjp.mi%TkL!a]CjmB)W)qA]c&<h\!]/suq#Q/[`:D!HHpqnLoW#mq1^CQGO4dWI
-%V];Ff2229&q`j]\Ch9Hq.-M]o.6:lSnD&MD7o-?,$XnR`]#j+^-K?\qi`+rR5s$IO`q[G^lJ8SgLb=b+oBn0oF)212De6UImAOOS
-%/PELf-\@hsZs'M^6PQrPi=@egRVD)Di"achC5ZK,R,&of&B5fnPquBA5u)@a]h,@LJuI@NC5Ajp>7;[`4QN@ek1?Mu64@;fJXd;'
-%3I@@:;#=c#Ti3oR56r.!$0gZo6)pMc#g0XO/D.EEIm=O5L=fcN</FH1a'/)CE.bmG+dST,@kSb2cHdL-O@p?nkQ76rr"fb)g53]"
-%Z-q!#&u#go1A2.Qa>3MU7oaHD+&[#_S<L;-\hME]jL$f"0pcPC!:Yh0fDluMHL]BY#&,oN,KIm;[j$m`&<@QeK(&b.2*,-roLZ7e
-%Eb$nN:SK`]2NI&j;KuYlq+:H."PFKH@%XVG,]e=V5>o_?8*q%O!-mco`8l%JF6Jd<,C[DBe$a];'_UNX+P-9qgG/n4#EhD7DH6>q
-%nOlB-"@)YNb>#GX'Fp(G+rB>0UI7ZhYEq;N+RMAoR7<5IjeoaJo9A!X6/b_PFKi0M_F+"C=tV)6LPK:2"b`R^`dpA$co,(5A/SaK
-%;[>h13&<_r8?G@QmVCB&mJWH;6H@Vg:W#FoW&fR(k)kE=o?SC#5A_B"Zlb0T%C3,(E3\(M7]?.A7Jt[#Onkq#3LKfM0g:4sgF0lq
-%aC[VV#^3-KCZ4(J2.Z&ZW\tp04]S%=%+\j;l"`Tbb%HI;.5GNuFhN;\ls"TaJ[Z**.YW4q#/.lEW(h2'HW4LlH#j=qLMn'f2j-;_
-%5d?T7G,V#n!\+]TK??*M8PMS$%8W^pdnWH_72=NDUlJUU+LbB+KH,'\!Oo_M`mKCfUH)4aaUt>'Bf',8NrA]8\cPil/i"&di_2bW
-%%,j<\2.(E2@)r\(I@bn>^a^E8%=of00sMmXQc_VD#",5J`Ub'Yo?(R>j74!FXq?k6Cm^$*+"$NVY!g.Ch?Q9r;$g4Q[(3;)%&L\L
-%)B4*cWkFcq8Q4<ngr+6ODt#ms@pmY<:<@W$mL_n]T]U`I5!i5Wcgu![DL`.UrZDm.5homTq4u&"PM%!Dc[*>.IJMMjPE-!4YT,]+
-%Kl_AZF-RF96Vbfp%P_u0B`jl[<"^"@0#Q/(PuNc'pHFB"b!Xqh/oZA>Z8RXG\4!>mIo70`\FJqXiqnbU[Ut%DrZH&XOPooQ\&$<@
-%FRVS#qNWGFM$mM\gbp?IQ?"Z!Jqrpo*fWI3>&1LHIW%e.hiC:X5D]>X58#\UU>-[5s1T=W8bV9g`%Cbq)t?DnBJNZKob;0rppkP1
-%;HMoU0<(1c1j@J+XBkMG9Y2W5IS1U=,=d8uS<V#gp$>qAH*C0ANJDl\Y[m!G;N.n$X0(#h^^K;PoSPlGNd`a^FlmYSTjAH;^cd;%
-%cVSH9K!;A$%Y9&BcXHQBQ<96QlcD)h"E9aVrTl+l2+@2R\3:ZB,:M`j?#<-J+XBj656uVR=p8.C6(>(('Lf'@S07e2r.BLOoB>BB
-%n,VnW8TYRB8g7i0$=NicGG6YWjLE.>];LqEf'ur1]ABK]j-'ajD<g42>K^g?F+.sPXVO2/Bg>j=h3/+T^p^=ib2$TO.'>T(p!\6M
-%2Ap#M*);NeB$1H4g7k5YWOsYO!,O4`m5g[>*e6q'#qW)u0W<MMJsnOmp\-.LnZ!a%G:"]7,4ohs-Q_I;+[ON0]oI'Sn=8J04G'@@
-%"k2]MRl=I[DNMEuR6qOrM]\1+%aJN?fnE*aU_N&#%H5rGh6W1XGl48]9M%_YbP&GMVV.O(g.`tI2qZAMa8HlCO7,Wn+B$PN+Gtbp
-%#YYkY>m>KZOZV,T4mPd+;gF8>S40Q`bQl8HJ:+^NY"57@/9L1*=WFd4UY@QpUH?Cd;,$0_s314Dg$uXV5)V/$fmoR15P"3IVps>Z
-%PG[s6j2inDf6nC'HXFbdO5&W2a@2EZn,'oNcb.JtLc9-\UG4T:IV98O?IqVaOPGJiAW]j'\3\_Peg%#%6&[MGmA\op.1.oNG#,D3
-%N*VW!+Q`hk!d[!j&n\CmS$oBpBRpuTh6]S3U-Fr3&*W_Y$l4VAnKSHmn*XXd[>:k%T!6g.mY%_@DP\FtL9$;u,BSh__)uc"ap!aD
-%`Y3sY68\CO)#(-^H]3hpZR6U"YWf[2AW>5V0GHfo`Z"18$o[7:BTp.$:@&RiV%Jfjr4ILjHRYAafY946K*TIIq2VU7SEa]^A!mtU
-%XAKu;G91U!EEm)2\ZN.MYaQa)'b8D\]PhT=0:dkai^W:BWh-;_=!M<@XKlYT.occH(I^,Dn<ur]&8^o<X5uiKlrk8m)jh@ls1_oN
-%G>\!#PJgPK9t:'VJ*")J/RWW/qg%Yq2Qcu3gZs_"O!i]Js,hBZC2U1&^8WD?W73uTn&R(1gZ3'E#<$j$*tGBVAC.#3mrS^beLqKq
-%/qpW**A-*$Qk,:kD]1QH?6.\eET8*fI=C=K+>,bB*2ZMY:q7Dm?S+4Fi=@>bIro\oKa2Tb,7JquFf#pO1($I;Mcj6&XcpWm6We#e
-%g)>rG&SjnBn@6SaKL6[rLm@4GM3K8KGFQ8?WY]UZrA=iR98ZZ]'-VH"-A+("Jtu2Of%9kfU#.(*e!<$R?S>Kk*ZE)Y3UT-GU":OU
-%Zuq\2.u4'q/EL=1P)NK%*L8JH(;8%:2N?.b3\bq=+3?(M#WFk:I5e7Z!kDI5W?E2r56VDndgsf2*eClUh)'KF5jXZb*d!T`M#g<m
-%pk)3JZ%K)p9.coAgLM@L?U?Nk6gRkZk+&D&@eYjJSe6Tr=NhAb3tIJIOjS:JD_.I#9F?r>O)%>\eQo$U]?p+2_]<I_\C5;2#H_jN
-%e*A"@DjOY3F"X*Ph(^-km]j<ZrfsreOsEE+Q9Xt7k!5q([N."ED5L@u+R6O/[CO,4HTWt?,Q:N:Aq?9!(10Xe@W%94@eC0cDsoo_
-%_k!jN$pgNC2Dh?Ff`#O/(*6pa/%iR*ngG)(kf/l_Hu`/(1A;rrdV)[oh#,[<f:Q+BI)\\is.<<R4@C];'%BsMat6-^DDmGCd*8GI
-%!jNf`k">5C-X/Jo:*qS%ReSj5[.=jrFm#YN-f9t;is*7+rcnW+b4'\Z,]u^Z)+I)p3U"dVg:$`$VS&\DD>A!C^>mC"ff\bhn(L9W
-%gpo-<nCWT:L%)3.]q0nKIqI>rs*j[3,.#NR2&=g2BP;2H5Y0ei1\a"Pcb.jPk3FUbH=V=^rtG9G&(*J\a7VJ>`g2;o9_EO?;C2DT
-%Uq^gM1l^u0CS!q5=05-poOA1#-/b8@hKQgTYJlt[%Uli@2N(/<?Yd'07.JE4EEb%'S!+ko%R/Q7T['$G2Hkrro.87:1Cd7adL!i\
-%O/&JaD=YNKU"!3%(b:`RCY=U)ak*HW5D8MM5528NkNGr)rL+N:XL;8j]d@'R+\=5+0-\rb*"[2P/88t?`,X!O&H,]Z'#C,sB66a$
-%lQ.k6?YFg\r?1$$ZaCE>+'6-1?M?2i7/sJ/>MVkNE8GCE2r(,?<3tdOe_"BBd<8c`@g(J7)ZOq?On&HKW$%B8Xnabol1hG1Rbj`L
-%F:^Pk;<m3)o.@kTo[oj@3:r!_`!D80B^!:1IS''!Gnpe@o#dSpOeN[DmH>)al#MIZ\AY%E$]5rU4iBBc?\b+2VX+[-Ch]b*Ra%^9
-%F*!;U?ASC?b4IjnqKDd^MHpN]/UNUW=,nMim&=kT7)4aTEuNbir+Z@K_@j!8&XRo-;\&-naE.7$la2D0P7Y3O'MXP;B8MBhZ'%lH
-%LsLH>%t,GX%qO),9@4iX@&P)$\@HgT.c-QW3:1?44(Xj)3%1Q%'V)5h(q+SoF2"29681n]im9,]aeOE!F-ScmO-@Ir*JksXN3Alj
-%]#cT%hg+kLDT=@R--(5:/\l+h]3q&(N9>Mhmr='Hq:OBq2<mgidR)]`>#!WZGb96sp*_AhCH\,e'2+9@?f?,?*E9An&>KTt!"s7S
-%0IXa:7W_(0ebNaNf$%\ehHq&:@Q(@O'(M^$N,;,GqEW'%B^]rMTET?,TprnAg3:)T&t*$);RmK0\3IZh.`fB&.k=d+J*4c&'<Mml
-%#D^98]f/#K:)iFdqp0=b/0s2nIi/%=B>R6('l+"^+,;Y,7(kh:jdpX?h*.\H,'h_pd$0N<S!;1Ib+$QTpH*@^`V,<8erW+Lm@@^G
-%G\feYRt;G":h!GrmBEUZrDNUIlXoDa7-@QEL%2(okT0"g'*?Y'&:[M,=A-W6R;MtCT@adVK;7Er0"X93,2F:G6i1ca,>DJuefAJ+
-%46LC88[8)X:XZf`\:\Y1?K8ZS!)14QLd<4Rr8H_rn#![a[*l^VCYTNW,X+$KNSq(%A$5cEd'o7"H\e+=k$k(o+3;qJ^JY%O_,F^W
-%O8J^NT^r%pfl]ZCX]i77CO+C=aS%ggIBe%VI^'SS'S6.'q"Up`!C#28Hq4J@+YN,Il]8Op#Z<J`4btc^/Y(PV0@WOkJ^*@/$9AWZ
-%-165`;WiO:j[];(+k)d+Lu4OU#);JE=/A[3_#E-dZ'UFf`"Ft<5u#M^E>!Dnkk--Li$+K1<r%*cJC?)]Cm[AqM@8^f7nsnDG#_]s
-%q[!;/V.p8O6Nme*7W:TT28lhu8lR]jL3'KaIk2ueMk8/0X'AgjFcuVs$_ci2nJ#'B7,a*HG9*7Af`*UOn,B@jEa=GL5lq/jqNh<c
-%@_iOl!Y?6l\hj#.a@P6Weg"-H-%V"&1E[N\Gc*ujfQWctp'a)<!lofn,7am:U*,O1a%kPW1hZ9jeuh'kpGGCWi4qRq1<GraF6flJ
-%:7\E`=F70pg6.UK-DXe0V'e#EgM9E7Gupb#P^(3bD4,S:5a%%ZVbP,j3=CG`S[V4?/?[5VOlor'`WD*jC2\:>o:R((YBg%52f?EX
-%/[MZ:RAt?Ffo)Z%"!UCepd_HK.IH@A=e1dO')7&H0:r%Pc(:I=KEPW;Mu\?R[;PYH>N'65SnF5sWM$O,R^CT[lmHUF42S<A<e;[O
-%4CiG^MLk\g&Y3D;TZ<5M,L,=qL$3-ED1l`_kfgst8E4,s.5V,._DWr%@>(:VVSi;0AE+;+'B!;7Aop^u4*fdnCG9uhQI^0HX\>Dd
-%jjfOf>=sid`eta3];Ta4l4tgmS^ugto?;)!H0pJmGSO$p/U=WkD!Sqb0.n!a1C^rblVN!1=M3=+Cod8($u'+,Z7uA36Q-5d.3XGk
-%Mh1NE(3HrRnARrYAi#5JVH$BK9EILc*PUI_7T>pF?!4L<fd6_&Mfd<D*=O/AO=G6u6;:9f8UK?-dJ/>tE.5P`I^3;Dpc1M56l9IJ
-%OG`_!/PTr=`O%:o&W`[6L6f9pg1G=T>1O6cW%+a*>GO([6[.-S8I]CX/'t<^1Lb/Cr5A]A5h&K1aB([tLQtd'2Su_Y(9B%;E/DhK
-%:H3Xt[MDaPad9TrLZTM\FWcSeX*YbcVDK3);Ap&n'8os[g71SYMo(EgcB?\_mojIG3C5HtE[<JJ^j7Hs"&r7J-l;tV$%T0t+,Q[I
-%]s@"TJ_8ORQI0S;XHSCr$OL$GUh$&H,s$9?3eH#rJeA0tFU]`-eD1fL6FNs&OP4S`*?E1b)ER'r$)rM8(>Hp+d5^Ee;*qIR6lF3f
-%$p\7'd;Yq.D\@&%%;$lhWtr]:eGIm[A38_dkhB^8`/;J/WZVg8L-bT"<fE<VPX%k&C&GQ0?krfrLhhRBd=PCDC6KB_,>fSI`jm8Y
-%AT!dYc>+Y?&Vk3M*7hR(<KNChl.RNWX3kVFhhg@K0A"a!?^8D`q*D5g$.Mo%i>=Wco(L;q;G>[gkVDk(GdL=R3Q;!_B92n2/P0E"
-%qBjdj*54JJ$@8+cS5#YtT&]ac@pt7EEta:ck3*b5<W&a*h4u^/!SC#mI2->"`?no%VmOp?Ol6'f4/1$G6jJWj`SG9FACdh4GoiXR
-%AJIcD'eDVPC?=;T>945E?H@/E]l1RNWYeUB^F.mena8F<$kn^>=sIL$'08p26J!qQS;LL\0jE_hD:N#_#JgqJTp>/elt]0_NkAAP
-%9k+6gQQ;aD%cfVZMX)#IHn?/j8L@gP)F\oANo#S!cp5L^A]Pd4'\&:SDUN/Lo]4,0N3"9pq9`W&n=rt?'ZBS_Jt@BF1qGP6qj<^`
-%nVoPI2`+W"WCEXFJgZ%K'h;+X]j<&UZGXVXd1JV<:fdLp>:\BE$Y;pUoieeE3(`WLi+/+rkIqnS<l"])obPeE)@gYT.Ug<QcNAME
-%,OS1_Bh&)@&Z`p?%k2NLA'\p[;[O?\j6<45TTE9=#AB2kE1dJl\V<[F/="^*<9m)M2Z@*[J;-Oc[B].bE0El<Z$$lP!bu0hQkT\=
-%Cb!\5PdihJGt4a6+[=%'1ajF"S3_\,ng&Cs$mQM>1=[uJ]f,%I1ZXMm1?j:lQH]>ZLmr#G`b$JE:YsJlKL:GMY6`o&&43B"O_pVO
-%`A;/>)%-uD;'Kua%;eki+JgJBi9JI)nM74deXNOm3S_J@V/MR32THbJ"s<^Q%^Y=&-oc'ia-ubqV+kDP[E\re_Y@TN[_cfWUH;a&
-%6^@b3R-Vf$J"nKcLE/s#`1HlGi\!?akX;*&.!_3@Y[*k/4(sL"0XRJS7!H6Rf@\(?d3X&eJV'2m@4jV%MqMrG(M</%)EYq2XQ0!C
-%Gt@]7.mP"Y[kf0bE(dHd6NFuB^7'AFahMM#mW!Qa[KWmgTY$CeYYccXES8_Y;:;Mb8bBIbTYU2uAG!1.=+G6F3A[H22=7K-K>,:0
-%c/C@$fE#>NSqI3k8-e!OOD=?qlJ.+R/2LTQ>^MR4h8r8IDSD21AIU]?'#d"/U*jkL]L!?m>hT4XJa?J@YmME"=LId=R0AA66Cf@r
-%+7aK*HF+e4<`>\*mC+C_`E_V+E,*MJRfY>Ifr5N.E1&Ja"MGW]$_pk/fhMHR15eoqXlBRk5)ASL8[&J*,h^&L:YoM>.IDZNOu0&U
-%7Y^CGQkd#KK0r5[.WXl0R/K#<Lh?=^Y%=XDgLT,VgmK2T,M"=tHHhVE*(Fr\<fenZ=]ljf-8UF4p!DBC+,h<de4)3<JCMpaNF$fT
-%+-#P/\9*SO,*8UV2G\CK?J/o\66&Q`eB%Z$VZ@aMJ.3FkYE`J;1uTQ"lq\f`eEE$^9A`U`9m=TpPLm)F4'/j612ja*BA,VYI/n\I
-%2:doT<_'WR+R)GhU3^N)Cb1NiCP6D*@p]BZg4@i/q.g.]+jmi7jKb-dhgF1V?m/)&BnDVG!'2kg3Dfo..(/T`S5Ng6Cc>_VZ>unl
-%0#Jd-L>[g62!qcF\PFe8YKbOB[@l07?aN"cJLc)LVn5d3:-'/CN#;c@o+[aIk2Q8C+0VED>8Zuqn`adWn#Rr-@l]LPTT"UB()"(,
-%3$oU=io0$BIpPn-=UcN,Yf0-*[k-Vk%XU4dIoh^0Ycq+H,@#"abJOl\pT:UrWqDL73m`H@]N7CO$l"\`NN.92h+1s:#':^iNAk'I
-%Ji"6odRN8%SahYJ(Ie["2[YK3V.chOS>.'B*&fZ?,Mk#-:t*+`_b*dZ0PN6'm9oTqBl(+P9AG:&^0=hu,G:CC*#Lu]Q_TOZ:P5@D
-%++4DU^0qaple.BQ3&iPMs4XtTNl(:aiX$JU.=<`KW+:(F$po&)Vm[Wo4l"8@9OAHLn;R.W%Em]"=?n$V;iI0jOSnCsd0RuGSO<g=
-%=4Y(+s4EP)KiE(UF;!B0k[NS#0IA3:-$?t`;HT[^OC_RM!TU1(c&JoKqg\jsDFTV]s.oW"T5[J_5m`OQZ$E)a$+4'?'@h\u`/:F_
-%!+6F\5Hsla,8?7Sc3Xs]Z-F!1=_Y%moY<dj0oCsp9rh^(/7E(XWB0BVd8=Rk09H:1p&O+f0_%We/D8!nC*_=V6>bX_?AEX`C__G^
-%BIn!oOX\Qn3,Y6,H.,nY6`iRd=c3l.ojNYgQ*#UR`mRtR&kc0,gX?jg)O#[j@9%SD>^R`t$[gNbGIlP)b524L6VZ*Z+&uL'PoZ'n
-%/lZ(J@j+ohnlSOjjF\r0e2T]:>:aK>=5H7nS,C.*p0'P.js\6n?reUR&,IKiPK#VVSYskf2$DoMWh)`JW+\i,(Lf:fKsp'm[Vc/h
-%,j/qd^/s*jeg`)jltL?L`=*RR,a7k$l-t50!Qh"/,W^&t2`"%@.<uP\_at+V\0Gmf;2C\pPAg:Vha0=Amb[ilkATeFH2h)'gc`At
-%qWY%656(9CB0pH]p[mb"S^R-L5PXG\*ri(g`]sI`c'oNQ5Q@K3hRrdQo,#19lLf@NqYHDZ?G,-tT--5oL5c(`hu3K%msas%_cJM]
-%miT4;d:])HjdlGBZQK/@kF[.pc"H#'rSp*arVY=bc\)?WJF)nUa$4uB)-)CioY5]qU-T64IrP>'T,p]k^FONc^AHd]_qh4Gb'1oJ
-%&#TQ#8P^J@7Hdk=N.Ipll>n1L=17;M@O.7b5Tr"]D.,@/]UmNeikU91;>loq\6&Ag=/HGf6Cu<l>?'[p,(h8Dodd%N,dRulQ&*/M
-%^4HMsk*#IE[lXV=qj>f/SI>fWn0ZOAb=l=!0?MXY-m24C,mD'm7C(1IG:HD[hS'+e1EXng%U5^h3>a&tT`+k+`QQ7")N5'HU**ih
-%hHnk-bC0BVLVJpVQYYe4m]r#-,Zt'9aZGM)VSSD*aUF@k;q[>m12r&pUj&$o.S+okd$r[b.?TlVc@P^/+U5%&8Y]u]2].`XYR[IG
-%eJEJ_3kBMp%6!^O'(lnGJM=AqS>*68Lf<m&*OR`pK$4BC&nsBPgU`Y@ZX^9\Ho>&&QhQ&B<*^0l:c^:"VP$d(cHQi+BS<a+feSa%
-%K^1%J-'10#gC@5dWo8EF!bHVh;N"6J5bL6?",cZt!M3,ik"1^,W%8NAY0Jt<4W)5nmW%[E/:$L@!:.L7[j&me.%d-?VKQaiIQq9c
-%=r@_*-p'hCUAFa_F8LlH9GpURXWtc3??h>a)=>()2;;EbeTr!d#Lk>@nLKDAd^%20Lm(pA4t-M%4o272=-oug<LB!n)E%&D)(D#I
-%JPnd8igN8XjpC.Z\*')]#<`2&frF1/X%?g.lU;^RY82:K%_+O9GFCc8(/<$V!,eI^iKOWEi@\*2E<XSR031F&0R<`7;l#7u25=\]
-%Qod%7#<N/-[ibR,KOD4Cj2;bk*W$P1+pAaJ<AMb(Mi4Z=9b'g5<)?F$2'&(7!4CI=4n0+R`4rSN_mc4dqYJ1WIWis$Z_'Bd=:p>E
-%TW:EGki40,kiB!?kad]_2,ch)q$sh_c$qq9,Y+]KKVTt2TS_XKp<j>,,Cp+H9SfPGYK`l`dqb(laH!]9-'tW&2Q@9!;^X8VdYuXW
-%KC)hYRqfGe)e>LC;,Gu1PW=i*6Yf[6+JcT',bu!6N)m"@RUqYrZ"C1G>\sma9ics]A#;5`Z9K]84TH5.c_P[5fR*b>'j;p@gDTNS
-%OF`Y96Fq;h#?NSKnb0SCq<Vb@b=1[o7%&dddO%I[[2#:Z*areVe%-B/W&?86F>;.if":2/og4Z]`;rAFKbBc9g!("RXAZK/:-jDr
-%`5_mrA$1')"mq7Gqt$Yb/[G/o-7@32O;';tRdk4U$#fr82Q5S'K]AmM^JBrR.Z*,t6%Xk\_Q+,[;T?]J=Y(8tR"@n=*1ZY-)@,X3
-%a??&_S'O>Lq2@7)Nc:fERd9]>bX?Kb2Lt,ckc*3Bl8IjPBlds?JTOEb/&tb%]UXPiCsZo92u$7BD9_:S;M4"2PFK-alK-=8\>sYW
-%-Nl_nlY?d?$aHkoDmtnV>E&c]Z)'_*$6(gk3nN8uMFW:cI`#_,Z8+>YU?+],:%#t!^)E<[@S)J/4o(lZ>FS=UbOI1qOH1>gJ;LZ-
-%".g883@=#a+)l?,"LQnRi605eB6=CEhq!T2M_Fi#`S57<SF;S^)#/.Keqa?%b:]JF=LT$0k"%M6,mUHN^f$S(M/Eq"Zu<nLAYK#J
-%4B>nn+O=t!hRrrNX/RPK,I%>s0rO;,p@=q<X<!uRj1])'P5?f=dHF*_DHCm<F4s!/H/77=%^[.&fMc8h:p!VI+589cJh/e:e[dCq
-%fr;.Ja^\&0M!]83UU'dlrX0WL2/t`8WZ3D;aBbO'5gf:?@d9tE7:':Z(N/QV=4b\T(JX7,^=6b4^kqoBgNTP>H\C%jokorqm&C4=
-%Z)a=<[PX_c9lP!!?]'9klJa-ff,:sHI!#J%l][;1>VtId<(aeoY>FppMA/>Z6hl35X&JbRm.E!\eA2m!4PI@@C<!*taal<'?tog2
-%Y/KU2<AN.&C#pNUZl3(mncZ0Vjk7R.+HUH"<9m*;Io%"Yf?[99MW.kOi"?hp'au35-\-UAB"XY&dh6qZfTs%S0]/+30^Xja=G3"!
-%IdR-AIFP<!n9FiTd!.iNKJ>WJkOCqd0\sf]ZXJ*U6^:Pl1P5'f,i9Y43CqnYXJWlL/0F@U>5<q3O-\UP0s%qr,#F2aBK#67C$neN
-%ln"c.NcYO1#b&O6d,H6u_7Y\C`Zd4_gE6TQI"3>M=62>hBdPs?^J@:E?9.tpA<[Yknd&4C;uWKq9p<"4C@O[MKD-5uf<2rTI"k[i
-%f9Bl,qa4La.87Qr%rf,8:1q,62B#oIRb%Q):VT:gD3<7Fk[#6)W#@PF@MS*Wd?\Ed<[d>M+<)LE&!_+%l)SU;cu`fWF7DsE_DKi&
-%@]DWj[;KrGWtkMVHQdH/C'Nn.1H*/dhDLX+8augU+,p(IG<PFh"3BG0;B9J"P5)`)=`C-6NBs";pCYQ`Dn3755/94%V#I@IAqT4@
-%&e::Xi[PYYf02Lr@9O>#/ePmqi^1Mg,f;*1=WD[MTfYCM$DQ_U>`2(*l(Vi.e_HeZ0rX@YUj+'&Uo99:"+Z\6mH`_\%tS]q-g6c:
-%59c39*!7@6D`!Ye[(A7`gHm7qC.*VOoF?1r&.U4EdR[m&Y3k[Ll)Hg/@B$QL<"0rg2:K6npe1]_G6@@gq-l1QW:-cemTn8r>3--Q
-%h4)#sBW3gTKhJ;E6+.R+Jk@u^l*?RV"uR@pj`U/gW=$tTX;QR$)?XOjO>YQc)hf#+V4;bWYlhJ38_XfCd`1DSgr4L/Gl)QFn*IKe
-%?;bLYR!pL36[Nm3s3fLJ+jqaF67tnVIfNcBh,;JZ>=,u+OJl@YX<<j'-Vh5*'6Yq/aaAs-"S`Fk\L&eOD%deLpf:<cogUQI:=cXj
-%2J@7KK&l#u![R2UKLnS,`@ll0.2P_poe3a*n=pJXit5At*!.]RjJ`m&0LYu?Cj<`j!hcN%:^T-r;%M5pTEhCRS!rSuB;1bf,$OZ;
-%q""[C;oLX74qu1DqNVS)euB.2%Trf/r4&d>C\#HG(TruqBFIk4!Wl88)(>EY/)rWsX=kgE]QJ_ZK$GraUjc@c2"tNp@C[M.CPu#I
-%[d59`f`$WO^Y/'?EZ*1]Bftq6N:g@KEUVJ)J%YRlfKgkFMRr<[-Q1--RjqVu6.CaT5qi>TL5Mq7SXc^,@FD#^hI47Fi5E*6'5pip
-%T'V2tXW/.u#)El@@@ld6im!AAI//_#PmL8i(SuZ-]/GBPYXr5&RP[Wb+uanL3GTE%-$Jh4ZogW2Ek@ZTO9T.B9-79X8sQqTSt47s
-%ROJNu)*IA%Q[B%KLmW4jj>?pX!Vp$P'hI`f"Lsb\KOYS^d6T2BOj"lZ9EcMO0eF'0!4@GZJR\*YN4I[a(RqbiWuo\^HpY7nhuRa$
-%*+L#)^R*Qs8K!l]5TP^B\A[mX.BCd,d'0!JTbF:@niAYEVq;=qRB1YU&8fCT]rqUn8ZTiYAcm,k(O*SF^".G]aC&uu[aO;oBNX*5
-%_.g:llfflNWT!=@-?"?.O12kZfT?fZRcLTtiqOlZ"63[X+\\.2aP%9oS'hae3fAb8,@5no:m&P9^,L7R\GW14b5m6!MI/PH`mJ<W
-%FY]14)dg`^#3fm7dGnuXc`"p/_5/$pBHp[S<#DMNPjogF%1VjlH:.?aUbl*?4s7hO\O=R'UpX@?reG,f=3LJP1Je9R@:jH;?DA$g
-%_US8BSjHsJVfJUf?=kY5e#oEm+'/%G$&VXD#CO%$H()W!I;RMV=.#;/5_e"'#,ld&`O@-2'a%DJ(uBH=_3:ohpWEf#>9Ge0D'+5B
-%eH<9X\+LoS$;gUXDPX/Ph9%X]h=18$4bNML('@96Rb4K_V@5V8%dV8T42#EX@it'/g[<m9\XQR#2<)$eQ-I:<YF=i-+AgI::AGIX
-%?"g&)J]so0@TK'H1GiMl1f']uRj39d&Z&aN?+D>@8%ZLA9j9d8`lK7^@Rtt=#S71B`)DpgV2B\B>@Dlg@4fMlY4Wi\`:W=f2!g-7
-%&b6(6.sg,t.UN9U,W\m-;iCo%)9gRX>-en['99`[&cFhVS!hbKnDd'.6,p6Q"glZLO+j_^:;VIS<KrG:T].P_K!KLlGDR=7j0Bk?
-%EM$0;e8R`i"[J&#q*B.4Xk^hg.d+'f3jK(Bl&QS*pdnmp+$a$Gb+0(C*X0*==l2ei@ABX"*VJ>XP@-4V]i3_rm-GF]QRn/Hr;,Mq
-%+2;Kt`WWmV-cUqfDDn,J&KFueQD[4FGGYO_/T-PTngm?X>MlShNSBMZ'!V<;&#0G#9J(I,`XI1-DHo]u$79)O]JgeE6:>naHl0)D
-%T$WE,:$@Pe((^76H,JBCU#(er/G9&W"V?3tIEC:hP0M)8ahVbT6Wdjh)6>JnV_^oB<$IJTWgdB,F,@5a[5$`d'?d[YY19Cd9H9>B
-%W,]jTSW'5SfH+T#!quQC[W>?)Sr<\npa.>e4H!>q\H4);YirORX$!+(A:TDg+4[ht@Ip_G55BXfC,6bWCSW\ae1WEE;[(XSMF))(
-%>b2,m`nE>5%5h""!"j*C,gF3\<O#rl3hC5hX"Qcijn8GKSMia9Mo+&Q\I7R?*j"'IG.[r6![!R".#gZ3%YdW**\W*Jjk[4:i=l?b
-%HoD/dieR,'PeUGMp$%5bRMjetc,h(^7cg.oKfF:/V;mN'AqJChBjkCie^%s$44E)i(hBkQk&M%+k_!"nrU:kG@0R7<?[]JG[m0)A
-%DPH7GD%CoDPmcVRJ62r5"l?GENcDt:KR1`pk7R:<.:Yhoo\KWLK/@!6c920#p!=bs)>(%A?@s!<\h:)$RIT#tO$Lm[rV*3cX0:FT
-%>1*Gq3u['r[;FS&*%0)YDfe4pO/:quGLl0f_ch-JEci1>jV%bB<5QU8R_af\%<gm%(Fe+JY@K26<^Mt'ChK9h..kP+$Fun5`><Aq
-%gM5]p3SLLt0331.&&rO=A7k^3O96Mh7ec8modY:#]t!82-FX>^%J"VQfc!`J2*b@AiNo#uejq"g3ubB:BXUBrP(;4`O(n]6g&91R
-%Lr"qMIMd9oC>8#o\?cl+UcUmu2M9s<Ju8;C`jZ7@3-Xs+Thd#JAE?$T,FYcY-9=E:b%?B.ak?`OmZP5)MCh8(bgce)&R<f=(e4'&
-%YgfU*)5/dgigNO]:ii2o#gdOb.%sm-abEkFi"`[rI)X/&]0-?XXh@OQ=)fC0V)m%3,'m-W^c..W6/u_r.a]YC@XKbsoeMVsA1VUU
-%;hT9";^!mi,qc<em''jq"c_!`RE!lg2%hjOHs`+]'H,(^_PZ_@RdXq=CYaATN9NZ6$=aAZeA(-eZWD?/L*Oas-DR?-mskLj5#%K*
-%'2dTfJl#sY+=2u+osef<M$=(oEEJIbFrPTOI9WYm]\/7!AK50,M'"pnfkcWr+lmh;jg1H$BJeIG73@P&r#os/S;!42lmd9b86Is3
-%=U@NX3B8B-K"Aj"l\^t.=W&2Jj=6!(ls$EFL)M`b<a<]?O5_`U`3g';<AbOfCZJ2T@H:(1q,fLpjS>.CZ@][Ql?YG=fNa/.+en>/
-%dArb>p+7@-Qu*"%-=.]'@^<gM$ZatXfq!uGF,&O"S!QK4[cT/+R2I]Bh4']qAd!A.h3?Q]4bnO;C-OR,!^,DTIJN7-A(:Z2Ec!6b
-%CO@l$Ccche2ggeK_Ma$`'\>S(FqXCiZd6H./]m#.(a)0'%mS#6DB=BGN?;@k,:q8TGf!6iAkent(>u<YlXD;/L8C0@\NUY[`aVaG
-%BMV6)&l5nu9Rob,#%gZ<YsnFeIQg'Uan&;j.Um6k_+H49bkb1CpU'qVSo/V+AW6lGOko.,q^4"LUN,mm/MehSobb>[JEKD_eG0*T
-%=gH_I]afR-_R,!G9CsS1.CS.43khH>BG[l?nb*oMH0(8d)oS9;m'3>EI^8OKe+Cg;e]$2Ca(X*@S8dS%08RR`hS=Pgo'4c9D=H#T
-%j)F<"'qe,Jbk%dhARn-H<@.cVb>N7b#Y,!RDMk-gl&8?7#N22j$8J=KjFj*(Ho2\SrDPNB"K+QGEm64C^nkt'B"Y@6h^/"Xk`5(j
-%8iP-^jHh/l\oD+6ULthHB"7*`ag^FJ*T!(u/UX7hSJT_t)AqU.$Ga52rr$5$@MZ^9r>o,'8?5f1c#XZ$QNib=YucfBP>m!5gsaCg
-%\6K5DKpfAGPcP[2Nm_c!OT^;iVMTW:$6mKAh-RTfo7F!DY,*!9!9)A5k>.edmWPe^lJ%q(n.Ed>;^3<pmI,8F:rI?'.JSbJC/-[5
-%DEKM$a'5TrNk"TDg.#=`G;_rRRS]aCmh"k!!0#TBFsL=#\9!qXi8%#Prm&GT+uLi>p4*Rh7gX](bH%InKnoS\lruHH(#[BQ-_Gl_
-%:)6j=^p_T.6X7u6l0>[5dK\5*+`$aX;Q_g1T/bNl:://@QulV!"Aa%bL4sPkgKPrb@?n/NYGAVM4LW*,i"F$X>Ia7r:>CEG`[5LO
-%92":NpjA4pnE6]K#oO'lN`Fd<E"Dg1oj?$1S%2cL@T:JCQ3$U)K"M(UmS4tA:9-q.Da4U[5%F5b7#r.aNilAbXYP3fA83M>V)EmX
-%.`*I<I)WXn'->9I*uGZDba0Md!>bo2T[ibS`^!T]iH.FfPInV;Y=.TrOk*6]&VV99+e<b9g)N8qXPlfY*M@9#(X[!kEb@m^g0Q\G
-%Es;f^E7e<uSP\a:h?ErSE35nG.,>*t8+p..,7.=1Q0G$/B=J/&gtG$?1H8<-[eIiDH7)WOCFt1*8/4@=7sLB.l-oB^NhaR^9gW0M
-%HGp804D((2T#sULVfM.,4Cf]]_F1K`Pk]#SYP]qJmg(SZoOb;6#'s&`1CLY)r-C=1OGbgQS_&O@K'k&n`-8T@,k9,%a=OR=`9=3-
-%l=&@m]!D32G.JgXaik(*Q^5EMikrZ',>k_adQe@G85P;qK@=@nbqJ``JU%#\.^&2SUdS]CUrd.5_UXGAG]Ps.D;l@3kl9c]a+&N2
-%V58Yes8DZNc(B7ZF99Ea2GhbaGJl1;(>/qN[\:11%,d\1R>djde&>_B[W5L1C6i[M\Ri^7V8;Bm;o**%XRb@(AX.Bn+=8.QV"<>6
-%O8`;q<d]_FCTj"DF;:HF&/.[\>(P.I+3KtJPsLkof]Ysq7ZiGH<j14uiXqATj0/0>6h5Ce$8'E&NNnUtf4Z2+ED:aW(IdMmpiC;M
-%:_GVuOt($(Y#K6fc5Is4g-P.DfspUg4jno.7MJ7-3d&n*W[N]RM/J_9!,;+)!eN'l+%mO&Lg+p+R;@;/[!hG?d=X$1iV^8#<-X.M
-%Na@Ku@s-e4?Z.6nh/)_r4oWsAV=cZ*`P_9nUBJr[f8H9?g,>GIK,5<D^6'k"iBoo3:<W;Z+Mi`@1hN=^C-J^P,@Y0*[WS=leDdm`
-%5;$NT^_#7q%0kb1%='E.ZpU<LK/SmeX7R\sU`G(P87t'+d=u;.PY&MCiKe9$k=OS9[?,1;?g(feLR^44r]ulC4.nm3BWJ3U$UG]H
-%b1S0U]Ej@(:Uo-/7Al9^RtW(!TUW-HmoT3Z09Q9#]_e7:]hT8)Wtk34F[UU&^?jt1,L[fsU0mOU)BGc!0]6Q#$:^]P<SCAsrO&nI
-%n*=_3&%J/`m"26oBq1O$iBF@Rds@1T%O@JK[TR?InGb2Z`=&V<JBU_j[Us8,b/]?`7*T'8h@,$HNO99E#Or$qX0_Y&j.sFk\##&)
-%o"NIUMkdUPU:*d@DG!_RZD17qcr`ul8r2mpp/H%nVT5\lE2<8+n+gDX?p1lcjQq]Jp=JZ3[79F`8FX]9B&OJ]l"ai\:0Qqi/I_h,
-%;EnGXX?m>UW\9N8-D*aEJ]4]_=)a4@mg(WB.'DoK.1NDS(hM<rRQ7*g#&M-h0q=A+@*et>csk-G6dL\j<@b%Npr9XBQ-m[#WCTpn
-%gJTnr2RI'3YKq4@U'-##_IE#tM/Q#p#FG's?_t?gl#H,&j8->3M!,VfN#ilEG*U@k)NT@OfBOtC+;C7^(Mc>))Oap1_&O;81ob"U
-%V3&J/<_#)k/:hS(2,Y?.^qht'G!sS>D*0P>1b&A)NR)FdK1$fbRr\D>iSl>&Lm6n<nK?(MWZFl./0:V@=k9Uu_FBWOZ@=(goG=C,
-%.Gki_"09NdfE]'f'P??+Xgj/LCCPQO1%fcPN3aXSUO;gh9:UpfniU0"J@]T?:`5rXn;($SdpniOY^2\J6>%3<6,U:GK(Z7</k./<
-%W&rOt;G/X:HN=A'k@Z;G(/g-FI<OUT(M$mKCkWXNXZ7A=.SIET@HIj8:YM*gT^iS$Y6\$Ap?59RO_X.EJR<OqFR1HIQd)hF[_Cs^
-%"hkp&8Y>9Wj,o@i8@Oi8>7o,ULln4c9U!V`2BhV"9:*g,d'h3\Gf!i\DNLe1OD,p_Ej!C)C6cEWa@>`Wktg?&hLXcKH0VCNPr0Jn
-%Qs.=O(Je#.<pQ&B!\Fp375/RT&Qk>q2C<3-clRT=cr[.m3cqRQ\rfO&^`"GSXd6b#*#^4!)RMV3+;>/[dop6b)$(RU1NTNbGoLVf
-%)d>gBoqN.KYTT(_TS1i6%ocO5j>iVWF/_f[&0M1=gdJAgC%Q9e?rTU$[IAG^f$OaAL8Pk)V036Ro@6cCkATaO+g!f7"2!.(G]bH1
-%n0NZlPN#N""BS;0_Sb`CO?4?t_GoBOL.WY+7QNp>iP@T(QW9@0Q6]i?67$O#G\0bs,)^hRKVLj93siIEWmIR=>9K!KPqbcib!:#J
-%+j:gn^6\[]D&mG1`P6o3Dq\)K9e!>eA##BhFI?><^BB^LOP3.tO?U,q>=/hGTV1=kY7TH&]hqd`W?`:JBkrK3]!TAjPF]btj^eN?
-%kJu*TfuR?4-6&qS"e.k,*J8WYc#Ppk#A?[D/A07H;*m'E%p_4=PEBdf;\KXuZQ^q[(^&6JkL#W7XsELKXaQ,1R9*Xo8uYp;'WOa1
-%5+.R*HX%>-IVBg$.s&*-Dk$V(K:Fb`4"3gK+CII&9Kr/%+d`UmR((_nO2eTV0MJi2p9Ppd-Z*9$kdI8-dE''[]p'j9"H2g=fH7HB
-%R<?EUh5XMFQ/&7T6iVBkA8'%'WGV_=T'k<Cndq597/ls]m9tlab3tRb-e^P))t#u/gWS;,JQ*);bhYCWC-o/"HWa9(e:Ro82u>+h
-%LMF7kHnr)5-[0ZH1BKTDU0*N^7lYZgO4IrE:6:d?]/Hc(.I`nr]`))<`G\N%MV#lSF`Z7aCYHfF#89@*+1@3op1e:<'0%Nu107(G
-%@5B`gW/ZYWf_b'5-A`]b`[[$W'0_S>*bg"cY7Hn2]87\1!sMPVE#`uSMZsAncEhetLhkWb\rgn(IL3XbZ$01FL'i."YrWI05SMjR
-%Z0Xg5glc93%X"<,3pYk#'\40)#HjS0(<<MW`$JP8\:%A"3Ha?TZIBd24\aJ/:_N/9)VqH9S&$8WD`SAQJ5h%6-ojgVLB5cL\5>RE
-%PtpRWN9Mk3[5I)46[0:;R$EG9gVl_o#8r,<e[TeM)!P>U<*[qjJ,s,Sf9j#&:n7XQ&5nBsJZ(=ES<Q.F%Z3=L%_osk+J/uPj;)<?
-%F?O_`4Aht3)BjgONg3Bj47CjBQK(s'<\1.K@!kD2JQM'tGX:[MB``/<b`,HC9H+'SS)%o&0Y4A20]U@*WY0SfNN)GVc*7dfo^gKC
-%X'_Fr#E]JD7[dJK@<oSA!1d+E-4We1C9BDjYKqM5!cNqnM*L,tYJuj"[LSW[/C)bs,&%?4a80tG/lL1m=)r9#&ckYA,Sdc\_-o9<
-%r-EN&OhZkqW>X5-7CXh'HG%-6JH?H^!b<+U7dqN`pE;;6)mKW!c;mSj.kqLDM^=*65S9`>msR,a.ZLGrE.b=oa)NGWW_1GOEQ1aJ
-%PmG<R#t6aXCslEagI^O-H-k3H(<'H5&Yk^U\>B9E,m+aJ'A3K=&2SP"T9MeD(@@oYaiX"`=X;S,j[pege0[4)@jANuFjTMja"W(\
-%61LNs4tQI0Y^;74=s?s<02C=*VbQ`BMb:$d7*DW@H`t[S%_!0l[9a[f?d?W0_D&B=2W_nW8FmO#8+COu&;eWl:k`,c/>#?4I!Ak7
-%LK/-4`\hG!d7:a#enGVD`CE%hm]FDRlPkrJ%fRc0:BX<)>9i&Ug6f[kUl71W[iq7S"mUOpKO<PRN%<PBkI2g_q#t.(oJZS4h4kAl
-%<taA"+SA95QPQCD85Kh_X)fI_U`rHAnEQ)^K,qk7E&7gjY'FMr\d26J1N&Zp=dl:N-:VADnOi5]N^G5M'f7&CR?MK<E_O[I@!m^E
-%7\DEQGd!'+kM=i,qGG"rMA!__T[A2<_rN-rN4c"3=)I(SJELgh]@r2d+O[a03Z(0rb+n7k`^YQK`aG!T,9=^*]$NG*`#VS:CiJ^_
-%8\uq-5Rt`MG!kIWa"<mS?pQ:P)jiR<C1JT+,Y8UOpbBjGc.rQQ!,4_\\#9GL7-2N7DBiA.Ji7A4@uE7BJA"+`"4S\=&f^?u(Z]ma
-%LbLbp_q\'-3q!*#>'Ok^*oQ=fd#AOmglr=L"*OI0FHJ-EV'CpNe0bD0H?R93TL[-r6`rDbk:@?uedA$*(rQSD>6B,O+Kfs9"1\io
-%1_?-O/+d%3Rq!gX`sU3pT2L8lhXPGtUXh<*Ffb/gG'1["+S>>%_D`[*l:aA2a%g%^c#6bj=(QP66g!1Ph9?nL]fgkMDp`#\"P+SM
-%amhTtN_8SF&TrBgp,H<^Bcu0ep,#)`N1K7cJoOG4.S9uRO=ZWVYO\AfVC`-1n<3>nYXX1eZluFqZ%lmZ)m;.K6;s:A/`NM"Ca[t;
-%=csC\,"#9W1!T%fKp\8PNML/;"KKQTg6"p*kN*T1A)sAC@$lf0A7&6dZ9frHR2Yig>(cru#,k$D/$Qi>cp,CIdNfK]#]MrVPfq')
-%V3OQ-Rfc)'3epP>ZfML,8&s5G&L1A-;oW]7'4=r`/rabIU7D)8LG4+,FnB7/MM5*H8>u7KlJMu_aL.iVMLYbZm/58Kj,2Cnia<iI
-%4*bn[KZo*U0rTK-Wm\Ua+iG;2IF\UHN'K3uK7&t?AJ#O%>XGc"bj)_LU!/5AO]UghE:"PK12]O73,l8DP1HQW?Zsn8BhV(:NNEZs
-%Y`XjYdZP*<_U.!T;T/DUQEO+Pj5ZJ5fjmK_`$nfsE/K4[q'J&VLC+r=?.XUj94RL53k.`MEG'tUB>s-?,i5V4o33^8;VH"fX$6F;
-%3phshSP'3n_Saff>K=slCD=,Hi:!Y(KX4ETY'hXoqPOf/NXSq4c=#3,R@ntB)U&Bd@tdI=Wgn1B%m@2KfpH4/a#$uA*CIf,YRsQ$
-%,78\'iq<J=,6?KL4_LkkOEADVJN6#0`\sQJ,^+.@\;Q@FlJtn56QeSPn>1R%D`G0F1]4J"ODpCF`FK8*)C(Y)$2&r_p[dcB8V)k)
-%c5SS8pt6:e<ZVElOBNCsZoZbc"rN,Cm+>CXD9^l4XE[=O]+fHCi\:W'/H`>A/L2[%]5N*_hb!Y(^&]Y%dOl#&V+*O%6fA.a2q0>2
-%\*f_Y"Y-_/bC9H!4+C@n7H2VTqoWnCqpHi$DRU%cF'<:D8<4/89PrQ[2F!P8,6W`[M3nthmtj"`/2X3.m#36OV;\MWlPUL+:#;8m
-%m-=cSMDNF`CfF9PD%`-/QH&e-DPRdF,2R\][rGtlb9n5':4H@<`"nrKKL'gL'Vdtr?h+'DR^'lCGVSMhYldi1k8(#\`W`h-3Xjas
-%iVH;BMjf]h-c),XirXkB*Vd=1rAY7!h$g`pjQLMM#o\AV2D,5/@$W*KBP1t9:ts@S>L5<dNW@2-^n,X4qguQP0;_qZmF2_n&i$[;
-%d(30o"\0hE.qnaWJ`+!\P!MRWSt=@sXGXB5LsENZ6&/aI*e?Zm_Z2;nc>5o6Xjg?ig"a*9mr!t!1"d0?"cB?bHXe]0Io+nB3(Y;(
-%jJUNDOaT1i-^YUL7rl1E-FU2=O[%QN>?<>--=KCU;SNa.Be$GBN/=tD+V_01YtsU'1W)%QA5>/-8cFc5.^#jo@7%nkD6\*sO^&oD
-%%U*,f.7c<E@s>E.6I<[hO'4?LBT.p%U2+L,"al"8kMZu,Lm/COW-h^rS#"Qi`[8R)=H3L0!c78W_B%r&cWo/^]H\FeEAkV`a6TQ9
-%C0K(NS?R$hl+5cFjjhBDHSN&.[$\:;c'W13#D9IF@Bhk,SLbX9di$Z&;J;:O4-!=$mhkeWIIAZ8-lYZN0IPTjI)"lY:@;=Zq1Xf$
-%0O?i@HO>&n:;pL+-/NoY?t0]0+\pM@O2Yk@ja)9rKDW#unC-!mHp'Kjc&md'*$4F.<ql'Y7$0ZF*0Es-)I3='0B%.+Ns!@22)"R^
-%*@A4t*AnF(D/hi&oS^9V,"r&e"E+r1Ep\lXT#kZX`hihu@WrFQJ>*&*2_>O*<!M,35hN's`9`<0$LF[4RaUUB,-a5p>8e#bS;_OO
-%jJmbMabZn4JBPa9*P,/6d<Isa#Y;"AMc3EM>@jY[_=neGm*;II.'`:DTkQp`[#pU>1t,1qfF<n/&a%M6CNE4(D"TcU5sh!!PZ]D>
-%Od0"J`Nf&o4"5ThetH9rQt/720V:1&"&O2tSZMp%D]mOUMb%Z?"W>L$7GD6*U2@(*WHMB!<'!E/j^E;-N1oG$rq<&hlnZ`HK2niu
-%$V%@X;bC9s0.>ptno4BVLP_=#`H<%tN_aNM`M)M7MZ*_A*OXOQ6V%utJhQdV*q>]B%&aY:W^uWt1mYDH3#"jo&6n@'ZCT8T0]k\j
-%2[XD/i1qWe3ul3a*@TH:>\YnGiWd%cKu*?2IN68Cg9IF;-^#fY+I$=9+&k))k@jX^oa-4i5s'%M9QGLQBS+Y0joqVN@VOD=9#ZbJ
-%o`R\NZ?m-=V2u2CSk1)J<T?Y]U#tXgMMI!W9->W?G'*'*b4Z1.(THgKIUbt!%PB/F/0KmEX?$!IOTDaFlFm*H4ADet%Wpt9fp+Ku
-%dQWSZ'4.f)GBG;[.&Ub;,S5s"06PRGNGtuh`dO69BRgObgMDhJ?#80&cHX7'_8B1'--mVAerr`H\XhtI)*L%-8I3kJ_GHh3gd6_D
-%3O=opD05I5jJ+;[CMQEeUH#87XYGmk<u^X!4.;5dHu)]!8Y&uFPt#rT6Wgm+7iE-A*Z?j!<0i$U02eR5qmSDeTdjO0_2ec5%e"=t
-%9*b7<mM;F2!=Bmu%0Ip5g`)@K=+02O;hS*!N7o<)M],.i>H?Mp6<;dT4S[Fq)3sORXJ@M$gtR?O+[>VeB9Q85.c3g#I%Qc-A2n/X
-%lmZjWA=,5on#X$/n4<3cD-+pb1r="*D?juQTNnGu]6^bFQ9NF.Qfl1jo-?8um$hdK"LMN"7gV+,Mntna-`:;lh7r5=e(/sfh>C_K
-%h#@?s9Bk(Z't_pr-OT2lF1ce=M?umFkkGq/+&Be8-ZZNK)W%CNkqr("l(M>(7dj!#<6N[e-'V(_B</(+"-hX`k`Hthc^^$>ch41*
-%9*?oT\0Af0)&pp^+n-WAMBcM`%V;]PDMSa!P4Rh5jrd"JEX2F@l41rB-D2S&&0Vc$9VV3b30(h&@O14X-3Na.fcj%.6KC`hL%p&#
-%r%+QjeKo?,r+5;mOP6/r7)H</Br7'2>/Cn_'@ug>F.Ym:AC=LFa]2/Jkqf_Qa+jU.c'&@<W2+V5$Z*-#*?gNUA!mmtaDlDb6PY$e
-%ii9&r7*mQ0%TFpgE/:`34](Co<L3sJoZ1@lA5H08-lsn6W-YN^=rB&s0jATmV,T6*Ol-]`o]:h1;:lT:H#RP/"'OspTL8fsL[a%&
-%TJS,!=V`E$Q'p1V:E,_YRkZn&AGlQjp<IDN=[]gt_lUDSZ*=nBrAqk(hTBaU(8kNt%#,^PSU.Tu!Q",?F^=at8/qJ;.?d.SlaR6O
-%`ZPC>`i%3-J\1R<_=t(@]G:$3fmR9148a8"0i8l]\H2c(I`-Aab9Z@:7']c3V_jE/kA8/+Un?8o&-7*7Fa$'j9#RBSc]3f5%QJu%
-%YcTNDZr"Ef$FY4]kZ3_LACdj%W#*AUor1(k%!'%6XAKGoW:O!IVu!(';<B0;P&iG)(^\eH=:FHHoFk?RLKVht$TfU<eE?rf5%.3n
-%l:sEseHf,0ehbbt?i%YX7YVt`KX`'DTtoW$$bNP.e_<r-.R@WeHA30'&e-"=7g%e<66I>^UDpn:Z3-:X)gH@&c2_r/88as9poEsT
-%>_uuJI;i!6E>"/?+OWQk8*!S`iooA=8g>_q_YP;"/u<j5eHaal)B,WN".G%H,A4D]U]XkGDegVFDmgCcIMAS8da:#CJ#)GR!'5`Q
-%EeG=j7p36HRaKZ4OuP&fR+W[^i7,8CB,:-#[DOn=eLE7::t1rj/)h*il1.V]Te[ppM;ZAC7b`%AP;o7YiOLqM@Y+'M"99t7J#lX*
-%jqk<j`\blI?!&>=YiO^Ss.3)sb_;gtN0.4rj"mVn2Th[Z:`(J8;D\r?-t4cKG%&q8T'5r&3fZQfDB7:fa(^of$eCT'-rVT'=X5#I
-%nfsT&?/`IW(kT?_d,I4C0C+3M.:.^EKdne!7\8*DN`=F/aslOU[UrHCjZq_W_c94[:$6SQ-4b)pM/eQoOElC`\I'X:FlHW-/M&/^
-%Z;.7HJos:(,5gtW)3_<pL%T8#.9#bMDJ"mVf1q]E&]?q$_&6MnJ:PonA^fF2g+oIhRu!$GMFPS1CIWnH#>f<ude(4BF@khXKQ8!I
-%I.E:sC!X:]lB6>m)@)7Sg+K9a*'N5*8@N1"o-:W&526kG6i$pndk]d=N`l'RH5%j/Ak1TKku4BBLH(Zhg8!M<N/X-X%@AStDDebq
-%3p2i=?u.0,=eFd>;l[0@LuqdfdZJ:<_<7BfedZu*NN&P*TV\W"%UWA610drAT&1c"[4RbUXlF$c"*n&j#Ttd"Q5lZPO4C3W&`[R@
-%o2mLTE!G]K6ED*8E[o6,qB1Pf7fmQ;Oc=rXYAUu61(5NXhNZ[mRop&oW+t:jm4TC0RrU-S0f;'1`1h04OSrl^91eD=PN)(JKBho!
-%I&1thSeA<!!Ie#JNT+82F;!*"W[39(Ku1]KP1VKKN^>rcgUr//)<Hfn"!LWdlBeaqN"eR<DO.A"(9GYb&A+FdKmFuASRiEL-sIu<
-%VC?>[&3/.3Qo1VX=uMsh'(U&Ep?]$Ze<?t6>!hPNDRiV:caT+[HL-)-_pT[Q5\r7Z&"r5<,F!P&(&SoK59_cf]$UnWaQRBH>$De^
-%2&0Y-AQbePXm\^L`<50IAQlB?/KlVhJRV.9Um;U"d-YNV5n/J1<d%p\>SYa-/+l9-gk)CF(\7CSf$TWOp6`P_=p,a%mNUmLg.1D[
-%b\':JZU<)cX2FM%C5gU,bbX#5MZlondDV;u_a[:M^(HQAF6t^KTU)7JEFCk2TpSs">Nqe'\-?h@@90o66H+l:UFX<+?<Q<gIQ2Pe
-%!9t,Y7q5_>e@+$0]OeSVAZN#cNl6t#\gYH=Bq&M05@,-2C16MZ'+kOW<R(uJgpkmXYpGrbG7\d5JoPTs\,lNW:0;lq#lP(O36Nqj
-%CT3W3!gV@LY,<IgapWd[aLV^g4XdMpTk4'QD(K]1-$E$9(rT-/<-$jIi9Z=;p[Pb2;L%d[:E&'0<XSW+eTpY,,0+pF%OW&j70q]U
-%7l^=LJgkP1R(Aqm\+<EZL?R9bM`KS<?,t4"RYbam]&g%U@)D-#:R!4tQo/Z87Upe-`kCT2>Q3&3U=5HHNMI%aph7(T,'n"Mh_r$'
-%Wh-A(cPd4j2C$FPC.^cd4.HFOA=[+nF?b2,\\dc5<f/"snDgpfQqqiaZ<j*+!#Y:/'dZ8JM3=%B2ll^c&HX\gJe6<Zj*2/S'C!6b
-%8FrT+f4,9;>gbp"b,>a9<iW0ZZm(b"X5d.,p_[p[\npJ[oJAf59T4kj*.bahXe2AQQ#T#s32]>-6)5]+CQ6KMGm&\-J]b&fVcS+/
-%GRE^^pZ`q-KWVP,@'Yh'H=/,#a^iasR%"#,>(Wq";G#/Cg4Q5QV?%?rp!@0bMFsb6mUh/MOfI*=SP$q.p4Vn-R,SiB5ZE')"(=.)
-%8p2+50bpe[S>k(QEpl&W\_/@A+_\2\Dht,)'t0LI>f<lEc"2Ya+ZGb$+CJZ9@?E2@(Oa"%m8?A)%O!\@Ct+>Y>`%rD0HT<:)U(J/
-%I#h"t/<"J5p3;2;NKiJbm85:S5hl$ZDR&09nfEdC@Qf+>;UUR7:o0u=VIh(oe_`us%%"!gIdC-gfj!'0fH[36Qo2:h7JBE`N*gZn
-%A;R-dMK;lZE=9KmhQ*J$X_f6s8Lm`W[oC'+Bq[EG*#nll##9e[jjUfO\N68=,7+D([hUJUB'+din$+,WUK(FN-e_;WV9M0nW5QhM
-%%<7LY#a*f;(3F<.]UbMWJ"ClKX&St86C\OMert;Wj!rO\XZCBFWGqQu1`;b)6ai]TdI'\\;jei.]3/acOh?Nj.KgiW-u8:7=<Y$$
-%fqP5[M@9W;J@]'q/e`Gl:j1TN&Z7WZ\q./i5Qa]+Wjc^_U@tf$K='9r>3_%iKWF"C:t`)SmZ^Fq;?N)f\[BhsQ'3`%Ki8qiS&UVh
-%Qc;XgX1^5h^N-S=84P-dfO/PfUT61LX@=+fj@j>`2OXY<h[Gl9#tb8U@Pblr3:3c.'>ukq)CE1YULNlKXkIEG0@OH]j:Tj1P/t%"
-%hBeSQf.5++^l(r6-PcB@M==c?V#Fh;rXoNC"nVS.Z^144Cb/<pHETZ''tFRMFMn'3MUXSs&P\-nQ-#k"S/SgY'#iO+BCA^ZA-R+E
-%itQqp$+@*jr2l)&M^p6uo/Kbs`83>&o\;ZePWRCpW!t#3L<5QELKaLE@3fM4=$BW`gUX>oTiG`&*0gPD`TiORAK?aFAei9Cg;rY`
-%*cf(.41il/;FOIQ1VZ8]8--1dp(!@HUKb$:X<kJs_)U+6#T,^0^mX\t'm4G5HKA<e'_(<ZKCXK5-($_hG:eM`KTETG0XJJ>>G]6a
-%,k?ba]I_-;'@p/QmR`\b@<a9@GE%kPODI;%e)tEg#W9NH%BC5M2K/gKmVAja:uMgFGn"(aUW.%b#t.fj*ig*8W,8UTWrQ_<4kZcF
-%S&d<!QX15pTeYaAk<T[Gq(oY&E/?;,YUJi2+\Fh=%$`U:@I)i'BGJt5NKHbQTF\R'*nk?3.]DSNIe445&kB#tOs]3d)Ok3cn4/DV
-%kA,T504>uZ2dKNTIZ9dnd[7Of2?R&XorsJm08$"SCZ:YcEY=ceQ3M;Q)\+ZdSLIT+^/85g+b;r7*T.M3<4WHL"%-DgkN!j-p,"!c
-%W2l9=Q4u&0.9g,"3;s#=PtQa$jK`7<V!+r1#obnZLrK_1h?I&.2ET\p=Vt+W<K4duCZr3&]cR6K*XQ1PX=>[bH!25F!g4LE9%p')
-%8JSBRBghAYe^>cX%]WXa)`iKmO@Be1NP^*0)C`?rlsq633:LSqe$1OTQUkAiN(?THTHb3&b6)`=9eer:Y;3&.]""_U!.f';G_TH\
-%s,>?/Zbb>AC/W@/Z$%&TDM>7.ge/%`[3p4.$26GFX##Q:_SgU5.6<h%<#8Bpb\8!t]WAEbRr!a96@j$*Q'3`:%Z@_Y?R'ecQiKW(
-%l@S=-J@2#Pm%/\i?QBFn9W0O@?-!"Sb*=+h`eD5P,Qhu0>1WB)bq[q/2Kkui@J9t+&NS.$-k^j4;3M7&'KVf!5d?/+;n@#r\n3(g
-%J]i^`*LSrq?ilG!Rt;$5c&pA?c%)/O\%LZ52&rg-YAkqoQr_@0m4X^uBQZ->b"DJJJA>c<#/+D7)6+)06t9QXK*oai,P_^?o27%t
-%#H!;,G?MWuVq7Ec047;*:-:'2!'K'%aFhCkZ[h;\lY6h,/%bi:7rd3dkW)b?iBbJD83KX]1iCEW'gadJW30V`^/EKK6R1euNcFBX
-%7V^So:b=4HN<CV1f<4LRQ3C^@Z=W?lgXAd0TOp^@X[KEBR62;I[c2SW)j?9r3.eCBW24!l(R8.JDU9A]D]=9hIGKPcf"t9s!9[se
-%jBue\U#6O]6+_5dhQ%\%,J,H%%)l?uX/drD1)4FJOqV88C7O>3G=f#99&LL)H#W"jg%[TrM?>RT@\K^2D=5I1K<Z"Yn6NSJfK:)M
-%i`848\!'m^9VkUGKmNfs[Z1C2mPT&#[Z3bf#9Kn:-?6g6+jrGuRSk`i<A#PpQ,t/Ir`8"j6htZ.T^6+2DYaHs_H;jOV[;$/!$??O
-%2_s6$8m"^"C/S&gZ$`kY\9SeO3`H`98o_5+Ll@1SdQBT[\1fZWkZ1,g@%h3K#cKl/34CL4=,t'+OH<W*EPD%d,;L[^'kfq&G-oSh
-%E4*JdQ=*>#.\+S'l!+HoGMfbI[%kHg='tUY<X7/9Z5]+[CApEjX,D8W'G"Nf'L8`b235bmF+99G-JLIh[S^@1BC_:5a42(6>%9pa
-%7<'iU\b!<]-fS.nYZ,;@)C./Vi!*7D)_L1r!a(?r>Q@k13>SBkB"jju"0AKW)?oM`YrSc>GM#nhW(9pIq=)3^9_:k;UlK>8*,]BK
-%:kbo5qPi//!ZnKjiA=,k8qB2F4UEKmo(AK7psB,Rb,o//jegL>,?#hU!;t3I*kkQ&U1k&=,c3%S8(OX-NF@.nnA[;nWEZL%m?Cg\
-%6"I6q/G1pp_K@&dRUQ6@+]5N]rEb$T'R3S&rGu5/EU"d98FLB\Ls<k&8p,+:XGlK'&Zs4TqWJm[Lt!$j.e?-2YXCfFQ!kl1WE>"8
-%1.d?AobtH%3d<MQYOsW<)&sk9.Q$ADp:Zbip6A/NBnVMLpast=Sni!$&u;?=/g]KS<W:]"mg,+X\ADo;j)+?(pJ"f3;EGDDm)&#g
-%q6ds$$/G=#<B.'\=eUVHf^q$E@p1ZY/(37p`LZ3rWNr,OO4TW?qI)E9h$S#-Hck-O2pd0q]^U0XQDL^,c,=;->(YKN6n5HWA_u];
-%Ks93MA*cEW98+7ln\2%S2(+?k&L*i]9XO_Bd"^i"gb?:1A[E<mJp%Qe8l]?`V/.LS;4EO;?Q(6?\P,`;)!3TEV7,"<4P`]Y`W:EF
-%M6-Ij!glf(5/Nsm+3VG2H-'!Sn<9<b!oVpQ`0:\,_o`Sa[c>;cd$`J(`GmgO'7$*iga8FBoW8s@;Tg]KLGc@=BiG_q2$BtH#?_JB
-%#e%@-NW=SdL;r\3cEoT@b>X@Bcr3'P)d)Lq&`hb"SZA\l4!m\og&,Sq^&,FZ9CS%)PXSd!?Co=WFZ6$1qMl4.Cbp6VIDdEFdP3Z^
-%U^f"L_h@.Vl])=l`V^;"^K*=g-[2(b9Yo@-on*aDRmk1hlUW#887"u(5-0j'kftJtTH$epkfg:4):6AY0p?TkF]Udu6Zf@j:Mucd
-%;M]=`>fFF&Z:[.p>cSR*0Z,qlVm^os(eC/ZO?D5d(l[NG&(1IBXH1+LG@5%^PT,)*OkkXmN:Q[uW`s;]rK9PNB.VZSoUj?:bI`0D
-%"2eIG#&AX`.:3K+SSrE($YuM5\p%=#@OOICGFf)p3L)-j:EP,%nDS4OmIV%um)Sso_uWttFf9c<XQ]cr91S+(+Ed&Cb19FG!"r3`
-%FKQf2=*X_Qh`O]5S,/j3hc[Dpkqk"e<IKAl!j^RafO'Q9G&PBu5B56$=n`&!)4BbJs5`dT\U($k:PH#k)nRD`W>Z@Zii@$E2,UaL
-%iXR&+\"Be`?JM8u;@lMR@fm2lIRrlp%<<<PN>F5!W<5st(%7(e"$%H#@c;qrjpMd<MK;9JifP;QUGd_IpA.7MDl_WH6f^Lq&u?=*
-%*X6E.Qldogj)jJ`DE'.`$k0(Jotthm!I7HimN4:S-BLTcBPhTSgjIa?^<FTb):;uN)5W11f4tR,p[D6Sc.+cqXSC4a]Hro&=rK[M
-%5]]GfFsJo<(Hu[Q#r9Gr?T"#TL`8eO.`d,XgkL*-Z<Kj\.AF'O58kbl)E.Eq$UZ9%P#;1QiN&E099(=H^g_#%YnZF<'hbSA`=L5H
-%=i-'6eR^P<Ba$#B(TlW<DU.s$`79)rG/C7*W!4q\5t9r>:dfA71ol1K\LLd6P=9$t?QJ=l^uGXVc($</Y%Y,to3N#&G7$R(24kjf
-%NHDUH=JY'&+\jU0Z0Yegl4[k:'9OJ(Cr6deoooiL_,#UeH0kC:`on`C6[an""\!8RK^*m2?=kABi?5ZR5l9fr%;H]ICSQT+rn_.G
-%^sIB"^?k-Mjc_""c'[j+eQ"Nu+M]ar.a.m!aT??;D9RF;MN:I?-jfW]-&1hdUP3u9,MTXA*(J\;4WT!be$`e6)n$M>0kW@i8)jRQ
-%hpfsR6gX@Z6H;!+J![3Gp[km/2+SrTS#]]i&pOjS@jG1RR_F$Xl530!AiSjr1%#>bY;)0f(*SlnfMZ,VAn*TX1;+MZ9Le9*9R8PV
-%\"Fr&3p8pG#.H<Z8k67Z4.HY'V#u:LY[n]K*F(ab^,)RRBUVD2?>*?J2)Z*d&QIYb;^r&L-c634YA9,)M`+aeE-"Gj)'Z1Dm09Ep
-%lMt=e<L.q]GT/?e$5._2f[qJE>kLX\df+SiNYVm]28AD\cIg+H.LV[j]fkp!`2hX,W8,Gf<YCL^44:>:hKUU\6EeJ2/rq\fqrIl(
-%IH^@(]>?3X+l"Rr`)&8iBlt*p,-E?,Fs)GT:Q-4?@CRiP5hY)+&LB\'7)KS)*a.qq,5i<0,062IeJ>[C``<A%>dQ*2OfXR>3fHTs
-%gTF_aI][JeCY#=uf33lqrY1%7)?h.4%!h7CN'YLB5cHY#j:^iV.<Mae].,m+LQH^KKG(#'qRL-s43SGRna_,8)bB%`^jDY)FT(8@
-%0tXGGlE=/\b+aWY3]D)B-+cu/h+Jea^a=5AZIrDk[F/t"0gj6k8HbbTj&*uPeqVY+aX&6o2RdQj?.p,UDK?QFA2t[U6F&0FYu]L]
-%Wf#C[Yo90R61cki*XHS/@?3h=W>)q6E'6Trb%bT[TYVj;7aeDfP)+$S-Y>f`h#aWnlp-8&b=..VX@1>QJ[?P)@mC4*Mf=NQHh,1p
-%7cWCVdc@Z!+X`'YCNfjEA,_eUf8rPB?;mcfB*YJo=jI0BO\.HK<_W\:k+;(*f*']M,!E3E<+s\rKD7Y*JjCuq'Q3Y5@F`7SRb"Er
-%.lS:3ohO(@jeR4!Mr[>gMTI,U@jG?8eZlIP06YV0ik!CffELX?.moi/DXagM9$%O9]s3e7j`.HY'<:gHR=b*&Lur73,-7SS3(og3
-%(52gJTV<W>kqsU1dPp.U_Ed?FMlLpK:BNhkh&E@*ocrk<S)N=@Jpm$@M"f$3O,CU$XZX`I%]DE,"Bi*O=,_%7^YS76dF)_'>%rX<
-%=rTT`-YbNi[R,8ilkE)jG2nan/tP(j$]mhL0'kq.C>!34H\qu/1$<;5ZKjr$HUhARWDKu+Z3!^tE7=MCfRCjff#]1j.,Ogb2U<13
-%#;d<od0qmHKT;0OB(@<cOh0kh>uWa_fb?M?TCqkoMQ2YY`u3YA<H-*%Cd0/(L#Fq0%-Ksl<I)PuAr:mi1=Tde73/+>[2FrmLE^^h
-%1$<-1-n86%r_NpK8dKiMnr85S="?WW4@&ktL]^=?Ipj@=PF2uK\Y(0u5ZW%q,M-bN[G?Tf#Yf*i));>>Ai5H,]8hf#7;Bdljt\B(
-%>..;[!2'cYBkP^7G;^)&.^QNL%GC],8_a4.RA1c0F5[!WZ"dLM_IBKK.(gjmhiknXdnFJ;R,fVNH/-s<-)S'hD1LJNn+P"*.J38l
-%kcOV[3`*Os'R0<0mDu>"0EB'!U6f,0g,0S`?E_`;%]WprLkmMH2'(C:l4M2&BOaYNXK-=Md6*e+*I[7`*b''CYC,,[\9[blEDJN6
-%RJt]/HGFa%$[0/6*k`dF%bMF5266?-2Q)Q_+#i!jl*.gcb-9K'^TuN6+tatO6F#c+qB9>([?9#)E18X!j$r&Qri,!kFAGP9PA*4S
-%kRs(&6(mOKN#K!.hAB.La2+du*]>lTVhsMm"'P(HqZAHhH_\QP]Z#IU)VZCr>?op>?CaY##=uEao'r&kGOoDE&n\\A"E!D`/qSu>
-%*48,T$it]H-&dH"5JLcPkU-isq04gG;UdDG<E5]43!kS#^C1;.=.%\[?fquQV4/Bu6G*]7YBZBZ,Sa*;+[`B4RdmPo6PUX`<_"D&
-%N1_=KA:W*A/j?JL<eAV4>b@HYY-SVhmnZ@\2O$>X:nc_4d!Y7+!)OufW[pIGeK$D`,-YZFo*,Y%<V0u_dQdu"h11eh^Zb6^Uc"NE
-%8eYnaqbZE#S3mmWlQdH>(,N!me*6B^ckrd(6(j$,,+ru<F.\.XR]$\0'eSQ>794R,[W5C>4g`+:%*6M'UU+@D`R)WD5cYWi&QXC<
-%P=:D'EuN#67gTN*cr8XVl8o<o9^b5_9ZnUn)Hl[5'a+sr?R]QXYHOtQG2*tWUr0]"B/[)CFaspGY$/IdbUmdM?(3-*,>Sd5dW_NY
-%`![ns7dQ/?iG,M5j\SPDg32(D6[G1f@iiZ/Oo,fh=^7*.%b-%d9U6$j7_Yrl#deSd-Jli'%p,W"_cfT$hC*'Kd3_sclXp9o#$Y;G
-%g)$e2.ekp@A$I6d("bY4eU90.41nW2,<R7J6n%u!ccBJuF0&!8X%i3./Q?B=VUI-5[ZjTcJ34VujiB&thOJU_$dWXGj7@Wc>B@s:
-%2^4TGOI+/m#rr0AfT.201I65rm1-R]c;f#<23(<E\e:MR_,sdKO0%q1oSMs+YC>,qUWMj[&"<4NB0dd4\!D)6P"C!Z'ASJZ7$WFo
-%L/[AlVbK1gCVP>B>?4`O1@_WKec)pu%.?a4B+l/<;SGj^@^jNnH4E4i<CX*ZX7R_`2c=a2@XWP4K77@!qt@UE%qgQ\SWn3HrFqO7
-%=1G#^YSQ']N!OGV0#J8<UJr5t7^iuNi2j*L7KY3+Q414#&%jq[aCuZW47BQ::tqj''4_;/0",7!>+iblmpc30g?@:=NpC\<SQuQa
-%R<GC>p)V)T'=t2Z"h#1#m61(c)k?B&]&2pdSU:Kr_V$u/b?$XhZk!l[_P@FRgptfDB\/9M1\>F)O`_)!_^4<S\-B7E1fEd*D^K<K
-%<L$m\:VYS-A8)Lmerb6Nk+/cX'/-//H-p>"N'(Dbqr0Mj!M\fC4g3Oh]kK+&Cf)YJk!:BC8p7KL5+u$og*7j0gr+sm3GIf$DFLG[
-%WmK;hfj9'e\#nNEP^e,MrRYt:kHi2fT=t+!PLj0trO2.HmsXNn2g=`'s/d.+*a_)/o[ObMIsUjq++Nk1(O&ZY5(2tG]AGZPqHM!i
-%NrT.,h`Um2YDn&0adY4B?@VrE?bC[[g#k#;n($amrq,k2?bL]t?11!1A,kJ25QCAf?TnAWeP#i;#;:Pug#m$ok79fSd?!2?IJ:u6
-%YJ9lagqA48kG+Y6qr7CC5<AdRs7_^ikq3r6Pl9?,?QC/:E;[VGhSm+!hj(flhgOtjiU0Y?bO7PL;a!C'ZPj4je$FB4%hp;P8ler\
-%H`_&O-=*@gF:ldPe^aZ`iA@u&@et<"goN(&I'm@.PLn#pA$;s-R9\)8iRshC[iX.\A$\_]%J>)0h*FcroMb'j3Or-'j)c)8ae.'5
-%29,\8!N1hp#ocVaYDYE%bFs^Q"<VO->41e?Z@(hAb2[9/j-t8]IJ;"PcT_BVh)c^+nG_J.(Jiq6p#ZpuG$A_Omerb!YPpW0Nq75H
-%rVl=Oi@s!RIP/AbN4^b0ci<7bgrE0"Xi8+GB*3"MFZ4,ae9fNM@I;[89M^_I;7B$?5R,l0F^%D<Pd""bg_MZnCJh<5BAg,PY?gn1
-%NI(O3*hRlM6iXSYq!mkWht]@+J,[R=Mbiejo_ObI5C7Bd$8HoA(IY>hqsP&EoLr4t%MN4Loq)2X1W=8<VoK$<c[L*ih%)\op6Ntd
-%U]4SBVD!$13aUb75P"Z"V#S.\Gk'C8NaTZQLUtoIW^EL$43+aP6pRnX)LZK+=0FM/2U99u+s""qClZs#_*Ck`jq!_V9<;g,>B[@Y
-%L\20Z@$SabiQ+r5:V\$>hYgItWu[`WR]9k7N@]FE/lX6Y7\qUqV7P*f7gJ*",_>>Ne%$9Z<3lL0"`#S+'f3Hk?ns&iD2Y&im,g,o
-%;4[/$%sVT2:-_*G@F@k#*'un=ei8)2d67Ffk5HWVFdpL4Z:LPpHA0q+_Au@<DOg@H"GXrtW*p[r%-(1T<*2PIJPn9@D'&ht;IUH)
-%j<YFC,>#M-/L;&)W2K>9P7S&3;;9$3n!0/F)^uT%;AfRr)V*aWcE/MG#!a-E;)p)Rc0/>T@&ksrV`_C2)Q`$-d$G=u<^]>To#M_^
-%nOSS^OX"C;I#(f5.A]uE#h:b\F4k3W$m;s4W5dgR_22T[h)LhP*?15==$C!_K$sM4$<\o-KGppH,*L?5-cm:7?HZTgZ8)MKgh]t3
-%F((2aG9;+BmK\=TNuC<ppqLBeV1Q4c<;]idTi+QQh-]<g"MJHr"l`VPlrpCkN"0JbY$P6f#W>b`&#1Zl+BI5t73h(nfJN`<-aFJg
-%X'jIs,mV(C.@\Ci)kib`P>k8r:8s+24,2rO$j)6=d!fe9V%VlH93q6d?JCXEpD/>_<Lf+D)Ds@]]L*nXP7Hm(X#jK=6tsq%<cm)^
-%`Y2eG5gbd;0[D>u5)>U2K1VP@&g>jICjg/fTBiP#gs0p"2N)j%('_@[R'Z=Ng"j3-Lq*ic/ERuaBOfsD*=`Y6C9<q,1o:T5&boG5
-%VS(`>.M`1ml\]%i3m<E"39Z(eI7.SEgDsGs3=$[`6.ZJk2L04ZI@+r`H6:bLKD/NMgq(_?Z%H1u]fT/#5AiQ9ZZLp[Y1KB&qu_/f
-%$=)\:is6p<Pjfo.Fed%\EsNsW<Sa-9a=)X7"cX4lO![l+NG<fZ#XJXt]I?=lKo215"4`s*99&kOd<FG9e(0_+e_;tQIuQL7Dj&1t
-%D![XkG)"Y"G"g58RUN!=-'P;3S2&`bf##q;8%uJON63!(U'\h4Bp2)c8I/Q/(R*_$\4q(p5f0L1=(b`2M`'sX^VgUleZlm1]9)u7
-%M\s1=MY3EmW.;?tA'PO?_u0eo5%d'9CAFOgkLN<mqKt.Gf['#]iFKTIHa6*;K.F+k(MXp+X$R<7E+92OMX.Y+`:E"8<r+/-)f'[@
-%"aaGC!t_<X[imbqRpXT3D#O"^9q_U#r'KLq])J'cV'jTI07SSuA)ALVh:5$,hGI6B]_1mq,AsW`,jd[Y!6n`XZ*1k.l@%H0CDL]0
-%<TVloHh!o%CknDV[VJYMWEnr^nq3p$o6DI_4,&4R-\n!]bfOp<RJ1<@=.W$H9#MG(?K[XtoM`GCg;sk[hTfc/KC8J4o^.]<XtH&B
-%T?#c"d;GKP(N[m7qSq>s4UWT3P6KX+@D^$QfiV9bmqb*$?E%J7)*H<)UFK.^PFI?u"t0iXCdfd*ClFRs2*nHg1<hWg9f$TEj<Q&h
-%j#ENVQBR4SqbYdMXL.]<QrGgL79"-$V`66),.e_l&g"Ffd0l.=_P8IAYo1?WIba8B<0gp)/2muQnRNs[3AeXmPA*1P%<h8NXJkO'
-%]N>&EVL7S99Wc9jB=C140ptUuc,UCiAsR^c848"MB^t2q87KgNoI_+(\YbC,G)Kn<5gP;tPiQo$20*lLVUkAJ3bO:CK87,sl,?L4
-%]c^Kb:OJ"Fs1pc>1Xoh[\:_lBjGaOW,gR5b\?J/k_2]e^nj[7>jmIik3qk`;4^E@#VN8@b`6*X5ijB"C/&tq=qV/<qN;.Mdb`s9R
-%p1lmAm\uA^1\G_nZ8,'Q8p-*4OqH+8<nNH/UN9r#)OUfd"mlP<s2nNiH`O:uaho)D@RLgD78-*5jEM$(.'_cjk;^Xafo'hjQ'#q$
-%Lgdb0NfZZG_-GA/AWA<#@RIFA+aq!I8^`FiY_Sb2Upe?5HqHF.]!Xu5A4JHkPqDF#KTq1<AQtC8C2tr!@qsGZ)6%-<9c@1%\4,\Y
-%Gq`-OW1F3.6Qm21`W*;"OtC.$(0Urqn;&Z"j5AH'KtOp96(Vtk$nfS<`g*cPON\7afDS4/j`/W<hMHs[S#iYcG!1k#)K#AHX-Q-.
-%*ZZ;C?&.Hd+iV[noBRph26A%sZATCCDTeb6(2b]JnNgd@=#/5@fkMkCPpuO!;!*$DMq><jg94L0W.a4r8)iUjW6t8q$$U*Cqa/<3
-%-R>tX"N;b"Lc!`8XAJN$Y@;nUWXm9IOCW9LB8=Ga,P[cMFr&<>!X/*S1m`'_Me(F5^0P2\eC(V-%m^9]i9At'j/OKpgElQ+n_<AD
-%J#:rq1nqG-^97\:l/IqhV"P#UZnhk+!EuSjoF\SuXFAsX!N)[hbK8,;Yp%N4im(;V07uF[o9$)*+PYJuXdfi%-h@$^q7R6\l:6sU
-%2%&q`3n*s;&X-$:$4_Lj]Q]#,_01W64&sl!c#tet&J`+c(%>pnlkI?U\Il;-oP.PO0M-B=FCDt`JEknoJ@/m[;9f2c;$ZLFabWjB
-%ZP5>[$mq<u9K=UTN&+I%FQ-AhEZ2V"D&WP2T5"GeCig=f'u_sJ@8Nt5f4N4:q'cSqP&n7/g8i]50=+]%=m+RpJ.X=E?BPH'\L`PC
-%^^c]N/bRd[n$>hG]?@79EV%_jd,DO,"U-k\F1uX<eGs+2cU+4.]RFl[T.rd#nOB,I&/Q?[NK@:DToNrrrDT`76dt\NY$5"%&nUZC
-%Cmu,$3uIP=LM;"/>fgo4bjOumZG&,=NF^]#FE_]"3f9of&9,6L74^K\*;m.W&1u(nPOq4842LLH:nWGU5O'Io8>SS69-$WF$n.?W
-%o?S@%ePteS)LKRC_&!)7@oZp!qW6NtVcnJ&,cl=I]G_3Ak+<G\Uaa:"MH->==cuD+MY`PAf+pVlOLBasW<0grQ(pA&66`>1"g9=[
-%cMW3uaA\+(iR4(?/+"Ic4el(>$S^3VI&0PYqstb.^1BtGT@jX=R$n97Zifa0LZRmJRR[u`pZE+^kE(',/c`lKTJg,2'"(Rd]_>5H
-%7IM\3V`%rI=6"lAn&?p&h9i82U$cud_T'O6mLpQ,.L*ND@B?5cOB#<C_Tr!">\0L1@&p_KT1:4;_r[u+SK?s@P^mip(Jf\Bl`4[=
-%@/&nWB@l')ND&<kC).S*5J:t>k>*U\Oo28&`45h]eYR+f?_:">>cd&J1:,`CD]*\i_tGr6ise"uHVTd8J#.b`XF*/-2]YKQ.^NLg
-%;ZHn[EN^2nJYW9lhY7a9fuAH$gQ3c:![V]^@Ek%ojn@gC_L45q'U%%U\HsFM2d&pTDEID]B5UrJb'dT4oIEeM*=FBo\fDnD!IJhA
-%XE<iQ33Bj]G)WOSnAV*!8u/6Y$-=:5IGfpWTY-^u1\9[e]4`M@m'\(;<B-Lb(/8Gf9(QTLLLLTmPJb=fV3&PX_HZKHF5Q0<6^E,+
-%O]G6U_F@]Hpru93\baQ?>+,<s)en722B-?R"u[E7i<q9>eqHTGCts_KfW=$8Ek&?E(F3IrZkmsrZcO$5ibZC`>fLCC0*K=9$PqOX
-%_M;7OONhoO.$E\%/]c%f6actES,9Xe/=WEDJ1h^ViI]0f:?2K+D!pG;hcr.=$`p\FZ4#6i3P>e'FQ"DsaO''G06#>$H7p\pKqlA4
-%9:K/#&5LFK?Z;s%@)9]TXiS?\=`"1q"j+=]="F@'(>N"gY:U0gJ706[P6E2c67`L_k+S/r9tL\cCe1uLjOl5*.ibo>jNbT:%8XH"
-%9cNY@"f338G7J"tLqXVjg9?&W/@H]*:ZU:MXO%&eBE[A,(SL4uk-/[$>=`;.kcir5>Ynpj:KKc.JS0qSqBkcQ/$m_E*?L0pMUIac
-%LQ)1qY81ZjRK\`)+"J4kP[80UYf'?";#5LB,e,@jh7UJ<a*%+mj)9hF<up&F6,c'jOol*531Vq$S@^GuL-W/8htt9,J65]IklQg3
-%\hD9^nFZs,1JD$F-_MiIT*n3Rq*psJDBCaVas8"mG5I@XQ,n=B06K`<YA?bSAtP*:s#8b!h#T;#Q`N]>&R+3#Z24a@+TDU#1j;8U
-%CPi&h>=($2(O,I'pkBT#=!1"u\?TI>jiFkg#X=kJd`H)mPc*-n5j8iZQCLbJXk2a$fR/L/..u8S^2bgc]\t2h<=*.BXt'Prd*3Ng
-%]m?6>::)f),V84Vcdpe/$m'CMT#`VB$ZW5?Bp<:/4.U<02^?F!Q\gHLHhr(EqHQ<kZY=-q%$IYs6hFJP841#$Gn^'VHd'g#-m\.(
-%fhL=3ZA!!!5iMg.0u$g#0tD=K9a04p''mZ$LoA:8"Ik@cS0a^e2'aN+GV0Q7aIC6r@WatS;nLS#=]ak%\<$S87D,^1->JUCRiJ-[
-%Ib\P]cAU+%d6igDUZeoT&Pj`XF=;"?0\LWrD=V_WFr%;`7J4Z''Pb9>A'UTedG8*aaF9K/kb+'hG1ICJX1S_m9qL??[QAf3/*AQ(
-%Q)eXUNm1dr+ASbQ>is!:C)eIZ^E\7b#npk_PZH*?dp>@Y=1>HlU'+g:ErX:kqrAd9Xii.1k_=Tg;*bW<TtSIN+M!atG#.8iK`I5(
-%o#U)2iklp5lA!pn]`8lc3q/S-R=*H\Wkej]o1&Gc'^8AE03Tu$*kYB28FfJ8YUB^/2O;7dV@"fHBdeVYE?,qLj'3RON;UefUoh:_
-%0;fgY%;D4j>Xkkt5IuTG")m&9IZNcc")&nkUnrS_6H3P^V=UZ;i7\D1KG<$kM><Fm<:(W(VUn9I%3q9URR_K(oT9Cf;n;`V`h4MH
-%L(%h=LZgu(H%kSG?#4^5hFJf9:*=DS`*2DMJ>sPVZP#OTVu\HiQQuAc]WkjI'@E7J^=30'i!Pa<$]JoX0sYC6Sre@$^6g)@L-q8&
-%GHp&a)?%/-K-e#r>j[&\q&lTA5o3CZ,Z)Y9M-b![!nYdR3^cOj+u_P@_b[Qr]bFd4[oeh#&G'?dBI!hN7H\O"\rHY();r6A`K#B*
-%1f+:RL&Ih=O(co&H@jteX4,mp5bG]+dYM0l,cNaTrSir_(a5f4IsE"1/Y:pna!,g"NePmS,pc"@KR!CR)cfXZ]i55'0W0UVYgR^j
-%!Q[al..I`N43cYF0?OS2lI5=;\rZ5*2/+lE>@0cRQM0Ru)9U)AQ&@dn=kQ:'NjGF#nlB>L]M@s2)nWltXpj#%F4aRVC%r`+SCIIa
-%(],dVZ$O=EXt%1^hEe:Z*Y=4YRZj69k\,X:e/YC8?W*IYHI9p[4p6*(8XS3LVmoK]o,J%1bN,dt)mT"bD=%#\8Q).m:HlbXKCdN_
-%aOri,<DW80><eVa>cG^B>L"+Pp8StZjD,mDd?Jo5SSFDBqr)B4"alHuW0\Y3)eg!khoL85NVXHqTpC`3m$'T+_'LF<U_QAJ9P3L)
-%'W5$sH)#eD#5%n4+=bC(>aSso^_i.t_o6g7@o1J%h:6B/[s5ngDN"07g/<BV(--5JS_tWJF0ir)Ledj'nK>p7/+n9V>B*knma+JT
-%6!%QGj57mK)ng6AMn:t+iW,DX:<euHW%KB$TL+GDTtlp3XZAbP8ld`U2V_#8=WeAl[_,_4(pfue,)IH%m(4lj%%.e;Tk5C@'Fk`.
-%G]=u*>n3kNd6Co?cc8'IFL,&h-P_ec9[JqN5)EN9$L3)q7];Fo1g[kQ3&AAP+uI]h]t6X/#'6*q%m,ZVe_W<>$T_YMa*s4b@-8kM
-%/PrY[f:&k@@_jOpm^(dsoR1;.2=,k%i8-Jh)nJlo`%1aO9db[TQeI;W4c9]S,Pu;\=$p6JaS@GAYbUM:Q*jkP$=RtROu^6Li!JO`
-%Ks8];[Pn2'e_G[4[R;!87)n;t9Z$s/Bh-u:bB=32)L(sJ?"Y0$h;,`'o0$![#Z8B[O-Hl:cEF"q`f-9n?dRW#Zg3]h@--Xan#%=@
-%(b?o8$f+u8%d&>\RiN$?_r*Hi+P@=BAA5lo0CEf851$,3?Z-Nk^e4^0A[lqF%H\EC^6i@k@rj`=9,Md%`W6f)Mb`#FGp0qUZCc'A
-%3rs6&iNj?i>fZ4!5i0s!hS+?[$Tq](s#)"f/]d@G(U/7\*iRX_CbKZ7aM/?FYs#*U=FA!QSq,RC$.WkXoBWEB!4d6!kB5+[<_\0_
-%Xa@&tPZ><"<q:5g/?j-?<;4muo9s)0'Tu)&#k9beo?PZ4o*SQHXQ+mmYkDS<i_;:7pZ?=_mh*3;"8)la*a>B&r&,MM6]j\+O!eFp
-%P(]>%i^RHa]L>?5Dbsu,)a3RPf>(tYg3"%BIJ!U][Vb'=\;g)CjuSV5<7^P]O!tjg4:L(U-j.<e$mFn%'TphV.+ai0ge'+@34_0g
-%+7DD300i!*5[^2efMsf^=o::PDrYY3OQJ;:'PEgJa4V"!M,(r`XFuO#EU"M*\N8kuQL-#!i6p&r+Rm([;S,Xh=iMuQFfQa,(7iKm
-%2nDIi5jXO252XFUo8q)cAKK.E*.a)9\7+M-P38h?>oJfLT&2nJ<`Fin$aUcq\tni%gNLUE!V!YeKpQ80(-o)oNmWW<pd#/B?erdt
-%=,'h6A`m8;6*V&4ck.^\!9f(uWS7.KT]Su/aG-XI6dW"<DmfX(dekVXas.H+ZJh8FX#j`RY4(E;H06m_#HDA,]5]/'cj1%jlKh<^
-%OpJ0gA#ob!UoAkZ)T]oU05)`!pBf;tj:Ek_gek2!4elgm9)q%bU3"Ge^(Mi\2mM6^b=N/h23u1B7XH-1)@9K9Q#e8k\JB2u[^D=n
-%-pBNj5irtpOedYn$imX(>7n'JnZc^PD-=C'duE]+Bi7?(hPFZ93eqa7gC6!pgS&\gKSfS?jJb\i_le2i8Kp)#Vqk,g'*3tunk_]g
-%*he>uI.t'roQW7FaU5XI!F44jKA.uTHsV1U5n!_Y;I(ZGNmKNtG%&`[G[p#04Z09)[?\0Jo,AQqAR1%9@gK0olhe1e;gX[^=L",Z
-%$*?1m%-[o2TJ_8K.e=.8o&'CtQ)@f'gkNTsUQE0HXXB4(;rM?cf(7[pGL>s=*U8)[U=OXLP@H\gmG\VZo@KRn]@_T06MPH6[^SN[
-%h?oVX7KU8?[@65n^9)%T'm!;+2K2g,Q"W*opH$1(3#Jgej.+po?BnX&Q1tKrA?3G,cS\KT[Mfo&cd.u\W^hd\e$4+ZM;2Mj^P]9`
-%'2nl/**)?udPL)-Ca'm-q>cqoh2C#Ih]jo;(Y43#e(9`;R$$Q<5!2rDBmQC\hEYt8<7?9`8c92&XUmmV29DG(E0O?eV:`KdgOd'N
-%L>&L>OrT@(E?f*M!l,;Q\JEtp(8CNN,joU(@:W>64CQ/rPaV>e)hC=gKR#-``u-&1PdOuTmkItt:6C0s$tQo%Ho8d[D;53?!5:c5
-%H@]aQE$<8+G.cr[3)(#OC-g#&2F<ED_%DH'T:gpa,_W&JX&($gmNZ,K;3S[,/^pg1klbP0\;TYna<=.ILXqIA6nhZrRhb6Kf/sL&
-%R*IC%Ks,\/&KR[D;EH7=:LQt>eTUcA*Xk+4&'S[KHZN8J#bm7Sf[oN-QGKn52];.tjYRi_eqtTBfk.NBi`q8f]-&*]1d[Q^A3J@m
-%9iA1KI:IB+jrhj$]S)O,o!tsmA%Thlr3o0lG,1eO,'HYR7kN$%c4`/h`!dPc7RMK@Nm\Y$d@XV8eOu=k)R$^#90*dZK^Rollo<Aj
-%p3>p'AlJ=#n`s7P0AcX%`>:a#;=fs@2u\tn]HU:31>I8i*<FLm%I::U.-4IAW+!\U-!&L=.9?'0jYIPl<m^^T`mrJ:aW.?)>clD\
-%bG.V]n?>^n)<G(^K)oc40c-$ipI6I=Y,9E<l6f<b'fCB?=dbR4`gj.P6KU=deZ<snd':,.3lAkk0Mt5n@YS&CK1bGl9-Ze1O?Bus
-%>_G3Kr-UUa,JR(je7#Tl;(r3r[/b'<R_-q9SI+e$0RB+<Zm@Jfm5Bak%%KB"#&'/fQ6`u=5,Z]iX9u]aNJVWV#n.`aI7q\>@Z;NI
-%Rbc#lc%:I)#LMW[a`jl"Ca'f__Sg8-@r=#?Dpj>="+YD][;Jo..@n-,3Z0aT5"h]>:oYq[R*M]@I0lG15ZIklK8g69R)f?'"Nnkg
-%p!!c_=LZ$e0IBf*8**LInM!EN)Q-60,98G60#EWfITgb!Tn60/"Wi[t?D<n!?qlXB?@CES77Ck_VZ;PT"\1i58c3!NXpm_epL3/h
-%WU.X<"sq%h(56A5Su1"825A@o*lU.[6;8*4/a!E[hgFmNI]=nM;?>ATT-%b"Ec;%GrQZ+[P%9b?*pT)^/EW%"#Z7n-7DUH.>@dIL
-%A7A/f(R#<t8:p,@f1&C7h&CO8(rE8e]2@Gh&p*lH+b*i;eInhdBek3l_30d/DgFA]@5I32cA\3ZY(ZNPQh3=d7&7Z-7butgpUtQ`
-%%Os7I.*8#G3[;?moU[4f@_WF_f3qZZ/qD=WX7auK^UK:lC\pTp#VL$f#ul`s/V$o5b*N<XV%Ap1!`R-k&N-q)Uk6QWDo<mLEXd;L
-%WMYT^C#B#T?e\Z7i_hCmH/#"IZ?3d9"FRPZ_r%Q\B%k:&ge2Q9Ml7i6po3K8<'MU^9!)0j_>(>6pWj@CNrClnH*L\KXg5RadmPKc
-%X]/$eBItEI)PBP!0u&?ERtkfk4d_[81WCI4qdql@-AMiX6?U-(q(P[ZAsD%Y<]34PG_p<+fH%F-L_Nege[Q-omn`8tFma(4WdrUh
-%gqUeMkVLQ67T_#QQ?59aQ6dC:TWW,8J(\as%%iB6YOYm0p+n#P3g[j+,k4c,^`M46cuCSdj,6p%g[pCSh6R(jg.OqG0ZVbqbJ<OD
-%dptl2LAg_o013Q>^Nh1o+$6fB0HQ9R`GgjpPf#:U(I/I+=Z+7>IAbV'+8k?U^$*<Ts!l`WLS7rf9fMJc"@gPVXr^eb-?&^re$D8!
-%k4?Co\'<=pp4'i(mgid=q9Fo==0FhOVYaT_H/>(4Hf',=aieUPo&fUXInpO'kO3odpMk9Soq/mCrFB1f9b7-odoSb]nUpSN21KR=
-%i4EpAHMQP*lXr-Y<Xd<85.u2kl!NHOP1X+0^VN$]MdcVA[m0]A:\::=h0U6VHM-jsSVPNTs2g0pD1]oF0;S;s2-k_$H_8!!n_<sX
-%[B..7aj1Ior+J-?jLC-*5Q9no,&JK"-bU<F),PB-:*^"'R9Hl6p[@,3p>XJCf[W4c=8PY(:]**MGAR"\NrKJBdr4G,J*3"STD\Cg
-%4I0`3p<g?urR_&Ks!Rj8htfB`lg+JRJ,=$ZXag*&q>,R+f>#%bqs2#efD`IelaQkgGJ<ShHqciun%UsT?iQRDlPk?N>CZMh?dDOH
-%NV>[8hB.gYnE]kK^\2#^r7OkpnGE7-fC<)6IJE*rJ+`Anht\1>l>QU:bCB:OrXWrHS)=&\I]NJ(J+-86r."Nh++4U5ocO4mRt(!q
-%J,)lirce@J?i=o.a+*^ts5K[LPLk<R)o(s9qWeZ1rmuYi0E:Sb^Z`H'TDGs>^]+iEia;[LJ,]2WNhnK1oRH^Ms6p!\O8nkJYPo.5
-%`j`_XZ[_u#s6Ronr(hh(5P8g\I.Z=pq>^C0s60?pq5aOpj)t=ps82ilB4(Z+fC2_Rp>1;r&,s'<j+%(+DuE:X"GYD(p\mDNhE+9/
-%.U<kjlHVP*k1k$jF(V9h`u+u>MB!Ad3M;'kP;>Fr,mPAAZ,th;-0Isa,_J?R&1"8X+AjCf8<tAh+d-mp1>T_DVR?.7)B."EkMA8s
-%%rKn,pY'Ddpoa9Rn+6/g2/Z76?amrQju<(Mf4nk+);23morGgmTDf/spMAO6I0TF^@fECrqAn<G<l6P<\i+lU]7'c2or11T(B7a?
-%>3df3)VVsg]Dgoqci$Z;j"J@jA@?>SigDptr65nE`6Z*m$6*]5.Pu%j\D58QhYH'$e0=ma"nahM;kE\t1hp.'E1XQ<k-n.]Z59X;
-%qQp+oF77\]=6&,Oja$;Zs2u(hlkuQd#tn"ZYE_hc;q]=BAGbiqqBY4t1O<7#;MOHHJ+fnmX]%.Hg%T^jp<Pu'<CZ5qPtSdcH^.F3
-%Cq[i2dU(/`rdXeC++EXErP^<lX[Y`DP4^VLV`/I!Y@N3sT(od-rqrramo<E!)X5f#$ND94p3N!9mFsKNQe-QZgHWIJi\UW.F'_k\
-%B'gLJoXM'nQ]gfMp[6V4EksjZqUZP@GdH=<Djl8ZeZ)QKS=)',B_AqH*BC&sXh6^9ZYpS,]?$UocE#)lIn<1\Th<o"kqg?RWqTQZ
-%kC3G3aU4m3a"i/DCmM,il;b)kZ1d3A?G:O4d$DXL2qi%Ydd'm*+6-p^eB6kBWgM1Cr3D;d2CtDdSc2*Y7pdk*W(#1(IYoNE\6^dj
-%*FADTMP"3i4RS,uLC`iW4fdIeWHuYC.l?R^eZsM8%G#0M<iqQl_+n:EWh[9jGkU.]6XS+&=Zsa,mk:MAp$CSL=fHdtf[Elt3jgJ"
-%WP0jl.Z@JVm+U:M(D!^=db[diHa,I27h*S?REl=NTlP8pep8^Iq7QXH%6r[jc+SIAc]UROT25GLXlIJoj8(UTT+U^3nN%PI/*/e/
-%<Z&77o_mS#h!7I2O)'p6/2,N<20%cC+g"B70gG+V;R9qHj&10P?n>>ubbh]WJp6&IEW*h7jHWZe)"QXuR3OI[k3$$rQ#"bnX,32+
-%n!1q3]o[m8=uWlrJY\q:[U\JQS3<TXhAJ^6ZXNTZ]cXPRX#=\4V;P@a2i`8?\6SUNV7TH)\7jI?N;ONUcW06eI/L4W7J"0ccE+_2
-%i*D]DIF9_CY#cMMq.Rn0)?&m_B7L_73+1J,8R5!Op&"'GQQ3ON]^"@A/Q4H38c&8=%MKU1><&l\V%c'Ll*=NS?*J_5O=GPS??5Ph
-%PP:^W^L,AQH%T(p_4]ISQd$Dq,0r0'>-(.S:]FnAaq*5EH/)V>au:,hY&XL>NgVJ_`^PHYh'OfOFRdje2%&F7pj`08j<*i6T=8h'
-%2_2m+:48!s\C9G)2hKAeH#2#mnk$U1SN2#qVk;6ReLJmOa?(!F9(ZH&j2d?'9*Q[)"BVF^?U5Fh>hV'5:!u0(7cV<,/RPb.poHT=
-%a*nu8ZqC%!^@1^ij4i^>9%@_7CccS(Q/K":Sldp&WA'$@p\f(,WmBikA8qLr;c,n4D8>=i0&=0dm-?+&;S9+/n22S2#Of7th1E(l
-%F%4"?HHfR+B(`GY?*!%#ec!Z5UNT\[rgt:Hp>Gr#,ASVOcTlDZcJ<mtkSZAs[XCt0iO>/RGG"TnL5i7s%t2N%_,J\XHfSPQH7_2q
-%N7Ifl%t$++6/oaX@G%%/n6,K]YNqr2r:Y$Kae*GLB(LnZ*T%/:'DH%PJ,ZX68p!,?hfB[TlM3S9qNjqSX?!mF_Rt6aVp@.45<35t
-%nu[95Cg&rsDKm<%h\*D/IsgLWaG7IaABL4EY\)ZS]mXdRpa.LUD"Ve81NMrT>1G_6]3_R!@,[E(8+pkgebS#T2/2s^oW&.j#$mY5
-%X+%hmD]\pn@[$"(HbIZo4"nB^jZYZ5Gte.Kla3.qiS_fkqcAc8%*[TSm?.BQkfr<0*-CL0d/LR9<t9X:0\WeT8L\\$YO;@f62W)@
-%=MFP%`RB1#ogoN)is%,Bcb*u)p-0f%Xu:I@aZEU'kB>'`)qpec>C?4jq>9fegHVk/)`9N[IXfecj&^/h%7YSQK)b#0/^i*d\jgd,
-%]\R)^!F.L&D]N%DWh,[&MtR)An9'%W0Q6<KgEA>e#!H_qq)`fHn!I-'P1./km?!ocj.51A`5HtufsE?/mp`V.gp<ZC3e=:lG2oR6
-%r3"g:V`)k7'D@r?qg<_R>#*A^*E-]B53ia,lJ`.q[mF4Z@UGAf]DTGZqQM'nNN'psYI0sSj-[$>a#6\,X6--SK2s!##2YX$e'l3^
-%rl8CGp/L%`ra)<gH6k4$_$`/m\FCq_Ym6Whb]!BiWl"4CW)r*C>l.siXR$;Ll,jE=qc!"/f+6)@*9R.1k6q8P3_dE_6AbH*1oftt
-%*T-)QnX`AaW5Veq;,MW"q@e(jGND#uIXKnj!uk.q.6D"VWI*!'^5-s#k;<'qK`0<I7;KAGP>O?gJLUi3/b\T;kBD=+!mUGR^X$CP
-%r3DfiFtO`!JM/N4nuL6U],k500roRZ)a<_fPqWi0m34DlGOF+Z>e&u3DY)89F0O*U?9c*82bjKFgK?V`5KJhrDP,Uk@U)ikhZX1o
-%ou!5,Q,<rUVb2r+DZ'LteLI]4p$CJ0Gh>7'%LcrraR8K<YK!7&iO#5JoWHt2kP'H\k5A[J-pQuIW5G9ZpFY[mW:,&A<o\qbrOAuo
-%?dbBc+5!c<mEijtmJTU`j+,FcZu]8h(h-[ll!)Hg96aP+h=LM.)c?Xc=G;n'dGi9]F(X1.9X3^ZjO\;&[TW8IE?AdMlonrJs)sOr
-%E%>__hTO9`Y9-l:%>4AnqIA+u^QnSsgcK.m0'l^ffI3jbEJK=k=-Hk2]_kfVgTK5SbJu3*YLi&%FR5s?/P:_>>B.SBI/;EVc[-I`
-%KT\J7mCelhM8AZ$2braBXiUj:.W]!_D9=ZhCXq/4manj<aln-Lf<T5tN12N,>?srL^!U9)ri=EFa&WYbl*Oj<`:_/g,eY^q>F#\3
-%<3=d3n#g]Jjb#'R2(ZiE[dH4n:f\iGBT;jOa%W'Y\4ueGa]`u6f?fNGr4%%afpp$ncN!&!mA-(Ss8Ipb<FW?`D3Y]Qn%uf8rHOTM
-%1AZqJ4Wq(9ZnFUEZ,?(Q;oeO/(Rc1ZAM*l[-G4-=@!^GJFbVO+Hi@pB]5AWr4hQ0DjFEN$hW3NR]mY&NeRIK`4i^55h4m`8F`0/*
-%4+?J55qO=nJb3[6?Gc0jGK#Fr*jt">Mhs+!I:DU5ZEZ@B"Qk9ZQ8al-)-%b1J`j%DO.JCPE:^S6`XA%n%A,ao<*&+b&k`bm&<+r.
-%]`se^PTiiBY<$VWU#Y#jZ"@[;=KK[/FYnjXfDQ)h(Nd\-'e@jYjL"/]ZDti'^s0lI5F=LG:]7L1$[5`nr(c[^UFZ2,O<gUS\5`be
-%`P:d5nPo[D>tr^!MkkR4,-Z5q".Y,4(.5"GRa`^6MtDC^c6F]4*8D_nF_30gH7S0uTk3&s1p-S,eV>ct9oHK@IbHTVU;&XWYj&NZ
-%ir6K,5&,it\k&TI;eJlHoR=G!A7tQ7@+(uK<Pj_oo-HWVH>n$,a)*")NnO>_eVC=r?ZtJf_G%JUb$&gV%>cV4(Ni)$nV%lE-dJ/=
-%Ufk>rp0uS=;3T&pBrELYn+Gd<G9:)CrF'eN&*Bl`l],3Xf?E$NHY1dI?`HiUVL$;U6d'gRK9bX_G/i#Tbn?$ZSE<2:9HD\f=V912
-%CqK0ZkOQote`1PR>#*djlt6$qbMQ'p`arA&;EjlqiD4f!.i3%aEpBHO)%#'.Qg,$Mrm=-AHe#Hh*khYX9hqqJNA_kr3tp3)V&^4o
-%'A@j0O*B,u/aGtdWRlIK`:86pC%6Je.eK4DGi!Bo:23S]"uF)\SPp/F$#[ce#HgS3Mf38H^?b(`KiqA@DTflV7s0;7ET^G4cmNVC
-%SC[kte>tH@%5,n,G>G92E*qu!&XtGP(;%.jH7_fJqlW*,T*m.]/a"jljhT82gK-oKR+*%`lJ(-a4s&.RDOi,&Vm!!>E+Aq7pCc?u
-%CV/l=Rdk;9?I4WPTDIqd:4$qtbCgdUCU#c"8+^_kGW>5*qmkIBSN=JtrSfgZ/R6!\`-!X-mA#RqP2Gro)>1.ZV`"r6%NjGDjY<0k
-%n"*cCS7^[AX)o78]Q]RXPHaVq^-$H3f$2C9NugE&jQ'mDE:0@tC/D0g44D2fQS6.'n6,5.Yg;0U=Xs-r&"iTj:FT2Va7/%Nl6g\5
-%?uraI4:M/b[r:-9*R7%(%P5b_mXO+FdpUh.A!+1\rhT]I-hR>po6hG)6e;jmDaWZOhdXCbiEanGG+'/#Y!//a`l"Zla1Ntg^TSG(
-%>GY*GnCbWcNo"dUlLE\7Fre17QLDu!Bf*PrYEh=lr:!IHik#DB<f/1e(RCh7(CeK2Y=?dJmJ@;2s5DB8H[`Pt'6cslSSORph2\::
-%qIUq4mj>lh2_=Qkps0:N.u!5>fBr/72Ct:[IJW;!?``.rkK'VQG>d<7?5L)#5i]IEa"]BI%W,W%Ib(Y0.6e3?n_34PqtKI1GPKgi
-%o2fiV)/dPtn6J#f?`?8/qV2s@S&@Au.L\o)>(#/@FoCUUlSn:fbK9XQa;)&u:-U&1-8/UdZ[_fZd9"$<HM4gnIb*Od_1&3mjI.h"
-%PEhcbl4JLe=(]h%+)X8'O8N=n:TWn!N0B,$(9HE#H?Rp"d8q'!2IlWpqiB#I^K8^W4`d(q_u&IgHhM:N-n>cInP7DALTWj&Mu6q+
-%c[7g`hk\SArp\C!c*KLMFi-hH2OmGrr1<,`F7.sF]8iJtG4jq)&"?(OIBU#Fq<c0!orrgNpMX<MG5Ha6h/h>K`iTnlQUM.^4o4]@
-%F6-['G&!$#]8H@[r9,fd$feCj]4]WN^8obV097K!$@\E/`clLi8)I<maQaih3QM*Blh8`fSYHG-V$I$Hn%*^`h4U]V+`6/[A%u%b
-%k$7[n@cT'F:6WEl[JEA\on//`7h1RHc3sCH8pqcIS.25CL$s>uq1h$ar5)rH>re8GIbZj04"?:pJ)])F*4`P.>W]<%AFAiioYB!a
-%lbacKgblQ.\Gn%G0kJhU?gYaK*a:e)IV@*+oj4rmi\.fl`Ei5`IP\H;7<P3mC;Y%,NrE3fn\KpmbD%n\:Sm],ZaQBOLiN#3fA1M[
-%Q]9)U_Sb8/]g(1qk#Zi]K58Lccg+Y6&)[%P^#@.Yru*Q&J*k17AReoA7Et0CNCPPWH0WC&h",T)?Tbo:adC9T3)JQ\,8P4tn_,YM
-%)t.)n\SqGZ+\dk@3YdS&lT8b>pD8=iEH_*1W<8WU:?YTR81a"O[="mO?g^!ur>5::#C!>B5.G2"Zp*rF9H>9b2'9MBlhBR[4R(U@
-%mbPBtik*I-:@6NC<1Y/M[i4o;E93*%0&1i;\(qQQ_FJcd=>H^kdkVHO3PSap`PC0-^--N1lKt58\t&YAD?N&hh&ASN1TGdkg7o50
-%L!$e@3r=hP#C\dZou?C2p[18eh_<,sE;0'cWu'*RpjVt7cf^>Sf=FSZ]T?gSl](J;qG1>$B'\<k5Fa]YqX"#N=)Qg)Hgee'S<Rs:
-%aa%jocHY9!592hupR=lmQHpH']61O@q2SE&<2OC(@?]h+rF5H2Y;U7r2V:mD4"jjKR!`2LE:3(l+2?_-c),V6Qd)!\G"Bq[<Sr5;
-%Y``)F/mGY^f=lllNYjp.b1pR/ens3LH-=d@gCg]l>ISG*\:3!!3KqGk)pk^0HDOMXkGRU.hrg7Q<OQ.d.d<?a#7Vb4B'd%t.B[Z#
-%a,CopYZo:SQ-,s=r<5MM$5H8c;ndX5MQ*`c(!;jn?./[I#UK5$]c`oRFPEZ(9a\/1jWkNu85k)D<DpljWp&.Ljo#6lZMsUumT'<3
-%DrZ(\+@K;9fdIW+Nh,D]9l_Z4Z;Zt]gIR"#8ks0NZ@2V9D4;muQZ&ALXCGnRqe[lLUP)]IbUg[C5FhQSa`3cLOQ)MK3JEm$%bX'?
-%Ls*5TUrS%rG>]dhH5mZCDAR:5,S5O2Gi21+Q33=[j;j#s*%CHNH"2K)ChC7t/<P2Z_La0^!u"c:FW/"fV#c&\CGu8EO/oNZ,EhcK
-%o4AT\nsD/U[>5R8!NHPOJ43LtCaK;34:qTpKE@%>)ZFb/iD"?KJ-%r.$RlZa?](TU7D?ti)F!4B&Af7Ep-[+Ei)K1SM:+<siJV![
-%KH$jlY2M.p(_]`!"TYD)ch/#'K]lLITh^k'XB0jAM#]XoTZcX])TCJ>9)tsC3LZZ:+-N8B(:k"#Af3VY/;^DZ+5,sH2.2X$]H*\Q
-%#d\ZAEB[P+AD6[DJ\s"43S63b#p]VM#*DBJmii2ek_IqPJO%L+)B>=?=Ga9#!F]Dp>"_t"JUr?-*eHd-e4F:Im%?StUt-So=AUpI
-%6scC:IXoS]1RTpc(R?Bj;UZ*6QO1CRZe\/&'"s3?)GGp^H(jXd&NBjDNMB&L\fr]QM49T?:e]He16p:j.TZ$i.JF*^MaK$e\fJF7
-%T`gDD&m$M<d=@Hk0`$<n68qji&of%uUZdHR;iu/L]ZU<VP&)QuE^BfeM/CmGI(#.jn:90.&QLl$^*G`\bOh1E72XsUOpk4VYX7%_
-%i@Tos&"ram*+l&]((L1?=O)=1l\*;PMb0=R`E<8:5T\<:"/Vb;XLg[@-B>"bGU&&-a&*%LE]?DdH';![=t$]i9H2WA5kF'Zj0nHd
-%"+:SSC_H?$Ja>r^%TqoD#7<9)M+hLQ4S3?]UI5%!_T8[og?6jOQg'IY5Sc[7?*b1k(f2#X771Dg7]Sr<ZLO:_$os`'l*6--3%7qf
-%hdT%3Y\>9.Z$hp$Z&-jI33c.T-P)YJf4?uF,'W#[M(B@VC<]\T(@l=C&k)$neHKXK&pd1t4<nHdi(#&T&L\DnW<b"U63]?H4#gRE
-%-eKcl;37bKZRMh)"'64#D^[L\TZp!4/mqP?rh<F-?sF?L0.p6/f-(J@0R&PS`tokgH6X:qkGZJ8CA!Ft$^m,/DQf^WR[tQZ+8QmH
-%;Y\HN`?au88E=S@3]%t!(3VX63jLn\f`@*O<`$8B();K!F:W`-XV%Hp4miZ8RUq?P$h1Q,UpFGhWr//:?!/'X3"+U\gEi^<E\\sZ
-%6,*[q:14Um4$4jgd=M;<0RNsJ!eQK`2'(BiphEG[IgVuFN<2Ct%dIe_9j$%i[f?t3dU36M2kn;K?/coP1>\OK([f&*FRmJJ,K534
-%W%f0U@p$Ziet@Pq(%CmX4m*E$_iOEmrV)G%3E@i[qub=-r9J8CpPEEOl_CW'%]+OOYt6Cg[)^u`Q`+-N0qYDsZ1VT2Lt<V+\B^l<
-%MI(GG:@FT#2Cn6shSbIFf6m4-OfRWS"V^2dqR4IF[+DC9N?@JC=G&?gRm,[B`HmR0nsK+)BQ1-h_+G6MCA#k)'oW%6@m!Vj;_p6'
-%oV98?UR:U%/ZZm#00Op_iK"S8EKQ"#dpfS6O6FF+7F'^^2J\u)@W1BD*lQ\%&_M3Ek2:u8b!'oXr@Lo\ZWR\*I_J`Bceth]HI7`e
-%\p=Sa\/!2#oT6S1X([=>/`!6^HJdUpgobXgO_$sRLX;u?rMBuH$sEB9SLWgmJ6f4eqT.+&Q7a+KYTgc#f2ek\de(Or_k=/-/,-.6
-%_1*8<dkq`C7otC^IFO@*Ds=M74626#V2h*FQKu5X_dt/C1\oDRqqq'EDpRXu4>D-dXsP6<d#e9D]';n*m\)i0VmkEf9/1W*BK'G4
-%%(UPNn)WV[h`(Hf]gIe?-XnZ>c"kXT[b>sf2tokXn@+kBg8,XGc0'L5MLhgnQX%\X4k`-uXnIhW.>$S8k,k'-M#SNB1cP1(i:+3&
-%+,iiI&_3MeDJ:Kt]CX>F\S&p;^NH&*$c.#V,Ik\5eZ1'!TYIN[^RBN@F+nA10Q$d:2Xnaoj'r?u0AcV@48sTfM;4V>3m'*YlOU/9
-%J,HuFg_8eII(ae\,Gr*>$`\CRs%mjcnVc:HJ\PM#r@KuPFBu6=1O_pl\i[H(53;Y*\a/t&4l,&"f>?S65=%8Ve"tr=T>k;$o<.95
-%gX-'%XL@b1DXJQn8"jn?r;l&BZ6()H\uI(U]Cs6k6*^:5/+u0J]se_dV;@1+0lSQ_]_;j/fHK/8k2r6R"+O?XH6G6AaqAgIRir4,
-%00!56m^mXa,lH'Z9CU86?OiX>droul&4h8`I+VNaFo;e5\Ft3UTQ91d6jM#g[R&oW+*)GkCrXUL;m3\n:oG(gn3P*8F*;.#n(L.=
-%[Cn_r0nZ'IDBZBae[1<&EL!Vb+NOkeF)t,NMm_?]&F%)"A$Pa^n)rj"_QU#sXb4i'`qq@HiUec(<:T"H]*2,]Eb;RYmt80](RG2.
-%`m5Qj.8s=@/fas$hZ"/D(IF[AReBKmb_b8iLV[9hLQ.D0m<0HPJEco;-9ABGlPHV7luMO-mEhcgmPTDd4as-Fi"8\8HCoO.iIT`j
-%[u7ZjqKD;gAMD`d*^<H&mnH"`f,tjp^*D#SH$2K==GO#&EfZ95]39YCIfP*hhs!(H6G6L?"m6L>\@3^HIEgAM]tLU^E*';1$YHg/
-%=4A-IIseA#k,(3HhgOeM?ihdln>Gkb6UR_Hpgg[X7fA0bqS+':\ef;^@DuRPr``U3&VfZKrY+Ko%4BID-o#f9a%m%'Cp*q[gURi)
-%R=".S+(sW4mJcdf38b`ORbU4J]^D^Q5s=tY`],#u];=`J^:ocIfXcIDD],3\RSFc">FnA-3kV%Hn\^GjqH)=K%M#.=HYbp[#A1-!
-%1P[FsI\hK\lGg%e"MJP<X="ePhM/W6CVKsqY-)ORCV9.p6)pipSHf9rFSC3&j+Wo+BirQf52fkhSBB*i](;,fa,V\V&MO[kB,?Q8
-%qZ_V3Vq+bhkBt_oJ#g6mH=tO*#=70g:f#R]*\;Te<tMT3&=qF^NpRala2f?%qp7<ul5_r0kZ8GC-M4=1p8scIpL&d`^$r")&fOH3
-%P8+f,F@%Y&c+/8aC?2#]GB]?#C/8%i[qT[@jhrMZY9.>=N0TpAlc@Xg5<e@`ghTR5!]oE#h0\te^YdqM6:(p)s6/4rg>,alE?p$0
-%m-cB!$pL8t-P#d7-RL*=C`ZCEi<Q0hoDaiP?29.]Hm_^KaQI3smc,t(nTd<l3B915n0m%\cWAou$CBsYfm3CpWSB<$WL#GEE@HAJ
-%gtU'h=+d?+P@5Na\O@Ks=n746nca0L\OH1kpLYGe#6<r4^58PgQp,TcPt*uVpV71p_*L$E^#BV([lXh,e;_FQ%Hm)loFP]SSaSbD
-%(JD9<oNqH4Eg.AG3EPrKX./lLE)l;=B\VL08PktiQ]LT>4YA`O"0]l7qi"jqH2%:?#7f1)i5#?JS!K*$g&,9J]ZQXJHhHeO=7;_d
-%1D;!:r\L_WEaHdHYA5Ek^8,jfo+A`OZQohs"D>#u5keO7MY(0D-Kr1`g5:nM6pQ?'B1Wf%:_OXtKd%=Pm-_-b%>7SMceAIt@9[j@
-%g"GO:PqMU@pu5Xmmjs9"kTl(`(X\V?*ul(j/[(A5.ZH5l7:,I\Y\XDtI+$3nLd8$nK_LKKqA:?C`TP%KaZ_t/1Qn%*d-QZQ0aM)&
-%lu>Hsp,'mA`CCnGF<^aGk+`-?A!+Nf:=st6CYJki-I#S/.9jJZH'JdM8;<REmje+DHkE\q0fDWnN@],-Yfm8#ISqs_Tbooe=[XR]
-%EG\MIj]mu(5uh'R,lnH-PP&c]R*,`F-s\ZbJ^Y_,^k9W_=oQWT^!,EkTVM=IaNbU3PA:P:"$fC*K/5asIO^^TDCJ,`4Ea(!H3*Y*
-%I$^Z5K5P(q%!:p1%S=EUZ,hpfJjtVJ*`HfB!#[3:@SfD^!kP7,)?GNpV6HuK7sV94c[a$m%/msOX+2,Jk^l3$-a?hqB]-k?)`iW\
-%mR$-01IU)bjnMX`h.5l-`aAiY7#.a:_'LK*##Nj1`d6FgKg6'<JKhOS1O.j)<N>Mr^_&j"_%=k;8!T_>1dL]PUE0Pi?R2!AOt*+7
-%Q,_.>#0Maq\uXWO=bn#Ig1:^Tc^$9c%B7>I."7;?'\9i?>!82?Z"mB.3`+?s]\"Xo+;q\l_qI_aZ&8bsT:X,!JBXEu0mj2q!VAL%
-%NAsQOmJm7+0t79Jp?[A4L8T^h`AJ^4Z:b]h\4-8*SjBrL<%0^aJ0@O35'XO&0E[mP_9:*WGk`nU)Y@/EJq*tTY6EY(\k"oV$6p$t
-%cuTie(<\QIc_?,F/2!\X!$?dWOD-9&iYj-o:5Nm2SYh]I)(8?R:F8c*kRCV,T*=;(ODcunG$tr*#:+#Z!Am]M_[<W4g^tmfU'T)t
-%)k17sk_A7$%%no8gjP*p.ZNC8.%Q7KHBp2A+."a:6kS>Xd2Tr(!0kV9omaKQL8o$f!#m406&M%V5id2bjOC#8WOIGS%!<_\jBRbR
-%a;CHJ3l6O__@A'%37P!%P)gf"6XjC^ebVmCemTSB!!P?@.r^b9)^&$P6\0eZ7Mc8aXpH/m,*+^^Ee0$d)J?k716g6$/R0%tL"Sb6
-%#_O'JdD,7:^'\Q+=KJggnq)cLaYYI"8k:!K:K9su^`^uWd?jSokZ1M\JoLof@dtZ-U9(^SmHcq4!MJ.]EV%;0NRFI<2kLS#1kf'J
-%e7Do@a0qcH+?S\+X&pS(Uate40Pj2K3U!o_Jl%!E]sN?h#C4IAmV-FH5hE(oN8ZdupoFQ/7kub-PfJGqe9pKaP,k]a]O7#O/7&F2
-%cfQ_(A\eSgc1e'J%,I3AL0#^a0LhNZnc^]Pi",ql-WIbh=paXTe]\5,_))IN@#lYs+S6M>Y8iOJ-US/Q`IUG)YR8+[Tj/2T(j9DR
-%S-,h6Z?/`^H(V>fW#\Es3eV\[+XMhd"9bELd"]?#'(?\_R\Bms0np;:$hXRO/O=GN*K#^9dJ?Il]'aUA4LIJ!E=%(!;Y+W=#2N>V
-%/h;VJ"j<eoM'aZ$&m3Oi!@WW+W.A@85]Ch!a+A3M&3uU[23E^f$1D;TiMu.!);)*TpqqRCEM@>4C4)2p@6:h/aB1>s%M0a1C^P_U
-%.S2)kAk*N=,9(+#'sT$9.UlPX+PCmB6B$4GD:u(*8jW`\i/6_>PkJ'1;Gn0M5jOKL;B;Ad^Tgs]dGkkd4oqJ&'J'e'VK6lA\q5kr
-%PR.,oc>m"#!2n37(?IY,/HKZqYJRsYAA$"%"nX7)/c_e1#4GMXTGdABlGkS[n6?#eB!0,8Ub%7VW3f[g)i'q_,0Gbk>[ilgDU;0]
-%1+Y*[1ha)0.#l28.]a8oan'dS+XRX$cm.,P'u5d)/V0h\,@OQX^p?aXON*Gf2O?[Z7mUHjd".2DdNf829#tSJns)?Q,g50JK#.XD
-%Kg]Z0=M9rX(Y0pIaXZ[H4#GD+AU;uUM2C7B-/_T2$Ia)T*RRR"&$Tp(l?M7t%!o9.$Hb,ng.F:6n6E^(!YAb;-7%B4#D-6Q&iO=k
-%6lR7RW8$LF&SS02W_K%\@"jWD3Yno)gk'(56N)Lq+e!$P-O[6.GSgPc`RZodaiU-id9)D>7N=&[P(?%J#\jVS:$NOLK0&-QCmSig
-%K1$*4HS+*Y$i$6CG*YY6@ER+C'ibWpn]7GUnOjOc(#@@ChrEp6("aYr9:aF1;J^O/MkOY-Xscj5FP.D]N`]KS$#ICDL%D[F`3+`Q
-%iG0jV*Mg6=Q'oWdkib"?D+uV>[NgF]%[AAL#,M4/`C!r=^nQc'bd!IU=<$./"i!+0oE#Q"/lA=f#g:PPY@T3\,H(T+aKQ(a-U?=7
-%js#%G-hBd\OO#I/9t"V!-fXsT$tToWYooOa$js#(&P5Kup.UekVD.$0[1Le73f@C*iR/_l7KNiX7T2[[jXZm6RMnjiD6$p%00h6T
-%!u)Va0d24XD-Ab@Ymnf^!*_.cWZ?p&O@7b<EGJ)4L!ahs?Gf_dX9PeBp`_!q%&Y6'"bU>?55_Vd9UbMZdm9.Vo0mUG)TDjS"iWAl
-%Fp5%K#nYdsE!O3]<B@@81?kAQ:b>^VKk*XX6R!H[VOU9ZI$C`le"N4&!/6l%LtG$<j-tZhO/7+Z=1Vedep%Ni)0c5:%XJ=0Z\#nF
-%RpV7*d^lZfU,sT(F%GH2$'8-Y8<2@;"4Aqr!L+3;"?3)p[#?/%[]s7nTtu(0e7b_=RH;S##`68KF,S`jK6XckBfn;%3oU8'BAINP
-%Fq\OD->GT0.;1h@#,(SQ.>pYOpg0Gf&R/!O;5]j=nAn4p$nRh=@%<?b$fFFEoO)^6m1&>Pqq/3jgnS=)+B^'TH^Hr5#OSM-\t\X$
-%%3sM3O5S\j!0+r"_,TFM3FI2V$b&77]kh81au,fD_.j%ZXm2!S#-3I?HMk1%[EaPlJlpT4DkZ[mO[_2'<`_T'+m+=ogeeEK:]M(s
-%%2r(WF>?B[P6D5Lo;#->M67iTZDe)$AWs(+CX@WK)J?kK4t-DFgBF<le-PrK76Vnf%MkqfMQPN;I/^2/6:c4NXoss3F#X7c$\Gl@
-%>m.:'cOrbh<^p;JN)'I\+SY6li8er@^qs<eRKmY4p)I.'OTm_C`>^uu#QRIM@9D/6U]E$)Cc=T2el-dHf=SD*2@90)?&/u>4dV8s
-%BekVRp$F2N?CW!Kb6`r4ZouAlba\F$,((/GKm`!<5a1T7O"0($3kumbSXuTQ3mF)?,?dY#i1sb`k>P-#R97$M,QoJX=,\f?)C!%)
-%[lEA<>$H'5"F]bpMea*?/llF8aun-MPGtCBoWf9&:Y;uFK2jH[CQ&-"a%^"U5qBNo!:Qt.CeFa8KEtC!6CJP27<)T.!,c!H[NW&)
-%Hp+$J=u9RHH*i@fkZ5BgNo%Q"f(iMn$;0=l*LRl)]M=Y%+AL-@+@(XH#WONhfIHuo)3^,,H#JJp,&A"`/V'Ocp/HE[0H)r`%"_OD
-%6mm4ce!/.i9/@o.E6E!NDBt[-iJ^H2ZX>oE"s4Q":#G)$3W0<=P!:$L3Q8NoP_k4J4/Q\uo8s.:B_)O)V"o.992R4oianTlAf+T[
-%$U>o>mh-cmi@(G?m=f>d&_T=gnnQ<M-MUos3i#&<T?BT+7BS$XeV1-5cZr\V0a,s[BUiRsNJeMd4KiJc=S%fI^`gO=9%6gr$8)cs
-%bcmBjS3bRS%Z)O?5Fa::IOO#ILRA>P#dZPT]4q]lbZK6fkW@c,KJ5LEWB_Y%+qS8ela-B`Ggus^%kYbf.ij<HV3ShQhj(u6Qd'=q
-%JZ#L`*Kf+\4\:lj_Bb1T7Qr"t%.-8%3(7n@/e=j[(jlm:otV1?)^&7NFg0^K3!?(C*@L(G#2C[pcer:>VRN4"UPD*iTL0*=]n0GN
-%brdt+9S3di%AF9';!e!T`VMe>XHJX5rPsgsnKe):@]h-Y,Zp-OhBl708rC7>7s]ddqoEFc44l4c"%93fS1BH9ro[NN:Zs;-qY+>`
-%6MB+1CE2G]4^I!f'nQDYg63?6,q#OVe)TOeZLj>RL[(/I4Ln:d;rsRjmq[ajpsn8Yr=6[2NtI]n%6jSnOCPQL-)el`qd\iI7=.!"
-%$'`T2(5i2=rOG%58Wp5@6tMFN$T_GPY.Ya<!j9'Mho]1!0E1h>$P?OO^V(Ap4FP`';(*ga=!Lkb-e7nFX04uW]EfpW2>V:2r%:#5
-%%_VUn3#emB=,S!E'#.T_JDi'qD-kp[(452?R%6q1o_YRLh:!L-:o$_Z\,sF7%^>:pCVF#B'oTb+Z.aP]nL2_u*#0p=Ln?Wl[]C7X
-%jfKkH!DP[epY"@i@^/6oZ9'=F%DCiWEBLb7]G._ap40(o7]^FPTp`/fo@4X!S6sl1(2G_+GK'>NSFTGIT78X(`a[JQ9H>0#Q)luh
-%g#B7M2ZT<;i`G/qc(-Z#6<kQ8X/<p+ZG#B)RFE:e@!W&0(6c=%T>(8Zj/7^unG84C[k6tbpYo<&L@sRPGi#fZO/k3Rna*Et@Xfst
-%1'n+6:YZ\9.::pn]:lh9:S8M-Wd2;A7.W>>H9fBi$R[d_@YK3r%^-_S%Vm7bd^*`c(?aFZ0(KoSQaJlm0l"G(6S6&;H$[eEXD&uR
-%Nu+s%^J'8_7hlU0qR4cQn$Hkp!Ih:_h1mkEB(@GD,,aVRd=Ad79#<ts3@h.NXT#-\3KMq,5@B`L>ID%ca$3eRra]u4I^nn%_&0.4
-%Hq(lDEtp6+X?_kWf!o/QYuiXhUrY^qTl<ZU*P5]kd,;/io60Jf'*W^IATWTVG7Hg6E`iZ?WBTI.)*q]3/LON_oe.9(rdZ6"fSF\I
-%[g\;Im'YioPr#IF7l.+a'VWdG<<Ha->%D%62>V"(1'"eE4\<%B3U!(pS^^kgoZ!^jo2kCqR$2lD>B[AKWi!NO)t_D&9p93bm"Ebf
-%/O&""*J0#8&:",ioN9>U3PXh$$b<hBY22R[S*qP@7Bos_[QOh3]QEV^WUEka?r,q=dq?E:Ql__hkhj"!L1e5]m(#hk7[j;Jr.sjh
-%o0ll3YSmPaf67jP\F!ALEj$Nf]C73^'jo_'TI5J]Parls'jk)a7Qs$7>cd#%%2UbtVt%Uo*K)dZG9)e<Tch;,<P<'bN]n=mEarUX
-%Es/b$<Ta3I*Fd(QcAer.`MEmNkHi@$e'/P%Ko+F4LWra#\nJRDe0T!]^NNN%SYmf"ToVsDc`b#;!qea`>XD\)YEgUTZsNE:r9jH[
-%^2+I`RK*`1\ZnNg:Vg\0S8^H@UgO.FPS-Y>RZ>6:,6`RGB2?iUVf1UX_EZ>K*.-Lg1%tV0(W23HS#0f7Ji2hY!KGn6$L`Ib@Vg(4
-%+O-JE?%XT8WYK<Y8R\lB*gdhbb'J2Fi@H#S%GX&Aq2opMm*!SP`JW/`>!/+Y6V;Uhi62I,C[jk.gbIrhaID4*2>>T*5nE4M>p7cf
-%;#5AHc]69tjk:i3qYg*/.O"(<2^oTX6O2-I1H@0C$3lRA(c\[Ff3T]:3hLU;\[OK(MKS`.@_Gn;:?o^J=2c[U241ZFX"A[Y5<Sl%
-%o!Z(J[OcYfeo<dF_N0\6b9PSInZJX"*_B^ckOR^V5AqHUc6%J-DgWm7.sC>Ar('5'E1L@`3*'H2IJ(;qEHtNT[-lDjj47Oa6k7%U
-%G&E^MD"oa_HZ/Xl*q/b$@f<gpRl3L"qtK=DYY4DD.nQ:mp)Nk%E@a$H@?&0m5TnCGU\OT_!RXT0I=Cb`:Q$.3Aj8'9-MLKd=^mT@
-%i87$O7$mlgX+R<GD>j+Z,P0!iI;o%]&,4Ot3&it1/iQo>7C\sCL>r*n:S+CFDK"eOrL>WacK+0aK^7W,=AqQsK#.8ApkcUXN"2G,
-%eU$<p[[attqAF+356e6,f.:9"9[/kB*\r'5]$=*0<QrSm/\DG^:HeQJ`9Y6jO-VDf&fNp<^AEB!pH5s5pA<1i7XE4GT1?kIH1QP?
-%BY)FS`9>5=>urrXMaW5BhO'pl+Rsbs@WA_FIk*Htn'>[?F'fH=B]92Rhi.J$p;C=9erH^DMn@DM++?m5nP^sL--9,`cT^o%oX#Fc
-%F\Bq&\E\N`4TA+S&'f#4QVtH%c&s1>q*fK[+'LZc[>M!Ap>c+<*`\R42pNH"\,D6,WFFfMWqjIIhk%K,-Z:l!];PCP[:![/Nf>,M
-%!E-4;hmmO3n(PBlhnK&:I<XoMKc>7(5Bq/IcF#I?((SEeoT87t.bhU'G1UVPFmn1^c`iI3DuO@h\)2"-[q'_)Yu(8<[qY`bg"BLK
-%1E/N:U#@*RqQKCeK^bq)T3A2CIh[..7d#dt=UGkCd@s50AgQ1gCYQ4"PKkc&Q_Lr)WgMs$27p87Q;k4]"^lnRLSI./X,(\_%RsiW
-%s3kE3MFW[^ET3bjdPAoDPKcjMQY6p^8)UYdmL!h70Lu>K6ru8)Q>E09YMt4JG"+t*7">B)*DcaAKS+OC!BWXHAf-OAqTq6Oa:o=7
-%]So!MSu,b+_5g7ji-.)uj%'J%=^r6hABO[)QOt_#b\-'A]"ssZEJupkjT$ninj%f9<+d&!6%DaN\%.sH!FLjsak'-qQW_6L3&BW1
-%\-CtT&=9;Bp&k[gj>$c"_-KN1$^"_R-M@J-U,0C1o-3gJ*1Z/9MWtZO+M,q<ft,P^ED^"#lL<Ai(KCjC5WQh$HOXst/eL\O+m#Ij
-%EEV9QA#`ULjbNAOm$\%S3eX>?9.V/R]7=\B2oRpp\\=W]#eH[+3,29;].Up;!H$%8#S>-K_&a.T71=X-0*#f;["3HL`F\6;h2L?i
-%_@H`f-3M?+2NXY*#*Ks_g'`a<*Q2,mF3ksQ-dZXD9$eW3N5<7YN_E[8kOMbRZ]ZmNOLT0./A@'MLDW[Yo)oabE'>Ur/R\(E)-(fJ
-%6NMfP1'autHD;Y:+N,;98dUL#4jKci*J,6o<AjqI!B+>>FIN,=[Lm!/%#La`+V7C8#oO*ZJ4rK/EpX-]gQfQE>;0<4He"MB;DAYB
-%J?'6?0*FHoFOj;_X5LAG!(!.Udr_M*_4TL<'"=eQiNE[f\3u+)$FAd]N<D1JMsG]+?oA/8*)$rJPe>M?aL>j5.QFM>KTUVQ5QR]j
-%#g+!+HQ+]2!"NV6"NE%)>i.%#d8b.65SlKp,%XF.PdEedMB-diD?U(%H3un^I7&T3RBed*3+9dZI4kF#=VOi"SOR%VRc5t(-iadI
-%0_WhEfL,AR]?r#iNOl$c/+.1<F1M^3`'IQ<:e4CtJ;*<\HCfCK+X`*PFB"bB`!G\GA8G)0*BYQ&6s,(<n%(+pSYiQ29U3j^B>E=7
-%Fgl":#TTd[P9:i[rPF(Im[T;pq#JuW-M4_PX$P(t$H<fU)dume'c79c\M!VX"[^,r7AbJCl,OrB:e(qO@k!qTVh03q8fi."<SD+6
-%EWkqJNr&6>Q6.3IaRD;BN(Lt,(r+Y-'W_C5?I[j5(%.M'+p0[8LnT_"GYJO'+F(lZbU>(LO\q70L`Z'G-VhV5&<>(8_%dO08)["A
-%6'9h5W977a_]dAJ`9B"W4.u!e_T!DYY00,1M9d\?/JN`1&6t5JcVD"%Ko(q1%B>s24,>^/7WF1c[OjoZ%6ukmjd7Y,S:P?8l5HtP
-%#hI`#I#a;T_1B-84HLkP,V1JH2cUDA/>eB*%<4A1$3UBc,L]CX_OT89P3=8?mfngJ0`Hu5Qc1j4N)<1Oc!&P%PQ@F*Khjtr(Pq5t
-%e/OX+:jY_6:Y8U>!t`,V)htupp^6JL>7lJB*/[^I0HOFb[5_V8!luWn:Eu'\fW5f.[c7[1$"@Qba<*P,5u7X1Wj<-8e-$[e*da"T
-%'A&CT1YW[[qljdbn<`s=!?&m#=hIX*F`VMq$o%N[%OAKaBV6$ZLB=bbd5M%h<eZ>8G;nZ!E`e^Eqk5nbm*'5]AIsenf@T&<Xf[Q-
-%a>sQG,8Au!TS]D7(T;6(@3?nSTX$=q;?=Xra"ZE^*XcI43Q0Xf\.B^S.eq-D!9\S7)$4e;mb:a+rIF@5qM$+oWC,TPE&j.!_35L@
-%_*Qq.ab4&1.Y1B;#!aXJL'^F&kUIc@=@WY+&"t't#F'"UV+6dW?g`U38-3Ng9f?"q]o=a41_q7/+5!CR:*QCP0RL5,g0dW"N#SL@
-%R8F!YmQSYtgR@I6_?_Jj$+MA"R_aiCLn$.$rW3C4d4%lrAlesV(WI:KhGXGP5L0O/aF=cW&3snW73/rD!P,0>3DLhT)q`<QNgnD4
-%dKXXZfuf'b:-n5(aWO\M0N:6mic6/XLr,uB5e-l;3L8C'J\f0f0An/3$K_ss.+f\DLSE]NK+X&]gY`g2f:T:Qj4;AWAg(F&<"X14
-%m=?F$NB'ph5:qnGK'8Xo%<.t0A?iPmk!sI:k(l#lGG=C\eJ9SJ7$md)<sp@!2safi/T'_dM\nC=,d*stBqUR0"sHC^q1u-Q"@[@l
-%-:Akh*!%9-8<sDURq<pX%QF_B9#1W\LTPQXR?53*h%94T"RAIJ&%<E'"Loj22")ng,:&sY3mGb_]%"qO#*KOfSe2Yu`0:HAN);jL
-%JDD@c2F1u-g'BkI%V=:U%2Lu,[kh-dT\5nJ<1:BTs2Uh/q5qYd6msKLk64KC('l7ULI+QWG9`=dT:l3JReU-sh>^-AU^>ZA*du3V
-%Y!5(5cPuHW(B4;oYN6G.pq&X\qj6JUYJhY5o>WKH6(@h3rd)d>&_0\$)_IOLX8hi5034r>8G!o!pUi$=hss;k?GB8$V@d4cF)_rd
-%mnmKKds9kYbI$`kX$m/up9OLAjOXH1_=Bf*N)uL8X'DR:g$_AVB$^9V,X45JIf"7PV*8D"eno0Bd:'XuV1B!LA^^uVIk"?i']<A.
-%Iu]!*lU@l+8rEp&^/M3fT`D1dqN^D,@DeE^eGp`A92:;$/5iWGXg\t3_V](`UGZ#SnUBXJHL/U`UV@PI?bKk6Dsp_'/QefWG#g@/
-%?]c*Ka7Lo)Mq&e$XDofbXS-8%%c)I(^"DpfC+2?tdbVqRWKi]:XOcT24rIKJep6[g5SFh`)u7e2dMiAo/6X]4lG(K'RH%3W9Y]D5
-%fs\)N:]L"?/^nISbhD;VA11NX)cT;#pYIRBs/n=lme#Y`=i?cQhgP(>nWP>]Cms'9ZW1k#+eQUDHEB5YQ)N30&\#F-IJ2HF.B(;E
-%*P1@fm2J8134*J_Uoo]7#6X0ML7B$[>889*'g&k-`l"h%\<"Zh9[4h_j5]S]rig"SBBqc$<?!Ig7I$[eV:S1Y>G\FHl-M_F)q7O\
-%q=FJ"99Da%YP50c*c!KM3`BE&-ib-LD:GKsG(CQ7D#n,BB>AjQS$?N#q^Ji7qY?Qd'k9Zo%e!$Iq=gQ7:.A:]pTP!`k1NI\5@/RB
-%19NWTfofd?PB&'3lEc2[7K.1[*_ip2(OS6?[2:Zn!tE;n=WPWg3>D.ZLAWYGXdIl/h8Ck5cM:orU7&$(mgad7"oHhPq0k,e7JQ81
-%I9Qk4<&fjSSkBN"^2diFVj&7;HHk[5n<]=r]TX.ifl'(sX#BO4q,fFrLG:$H%18H\=XIY0l4kNW]]&6Bhn=cXm-U[/DA;\W"Sl%9
-%Z0[ATi%(rjB#3QJ_>dlB=H/&WnKFO,?ed"9kDZ7`5BLoZ0rS+i[q+G&=hVBM?fPbE>Q=MdlEOI7"mZu_(R8`3Kr0oce(:aj(&aA;
-%PP/@u[2Xs//!!fHk-MV)k"Gn'7-QFAG&3Q<?>SQ^"(1%(Q#>0'?p-r*0A>pkO@\QUhK1>.pXnP/XD6pZeneYVU!KNG9?0Dr[TL':
-%kfspL[[k%9B/mVu<?m57PoIAPmE?.;ptcX6pY7harI\\9%NSk7Wd:c.]FCo2<=G=BpnjZ9S2l$Y2ttJKT\08@X_Pp^;ec+)Q,BF8
-%<G-`@0)YV0:LChaqnslHcp/QEXrU_,B]>'_?FY7VjR(aXF'nQXhl1,AE0fnkeQ.70VN'CH"`+$l7-@_=NZJ.G=O8N\efWPNihLq<
-%*G7:T);6Vc=tj^c_9\Nr]%Il9U<%ma859'^B;][<>TT+mF2?"5oj`XKhp&i[?r:!C`pt^eqMa0SiTrT0e+DE9LFKn0.F_klq587O
-%D\&;Ip%1gAgXK>Qo$4*!UO_R8B`7Z'kHEW[i2>>?=#L\<I-J0hUH.DlhhbaOiQ$"\J!_(R3bh9jip`Pa-P"E*Lp5cHr`A!J+Yhr^
-%N6ogOPlRMgZjNJI6[o5>fi\[u9u>S[ab"A:,&j[@h!_BWIcA1tDs('^C9oW,n9+G_Idb6>";'h21P[mt_\)_4i$IuVc*t+=WNREB
-%Ce3I;(bUu^0aWGQjl#u2NmOgZI*%c-7MD]Y?_+VK^*Vt7Q>(JO'kkBA=a;kZMqhQkVEMDMOmL'`:E'L*ZcauBqn\E6h9*cE@@$c<
-%+.l9Q6<ttZ8iLEHqr9k+BC(X8`lI8YggX8l3;S_liQf_BPUouigA#Ya)nit<H<Au?P28ss%c1d[6VprFf*F(:rL32!c`.s(!0BGG
-%:r<ONc]#@ceu#ASFWFi-aPEFLY?p'C0K'#&jLH_,<4d2b=s_A:IMaGVcH-g7&Y8V]E7^'OT,r\1hu3s>(b51rhMt[F:1$4"$@$"J
-%ZI&aZ:#,o2RDUGHZQ$pq(d)[7Up`C)bKi9GYUjh`>s<8hLXYd4VjfmkhQp_B"GMHPqDg77S?%E/l_SF3T*H"@]PVb$)5oat]6kbH
-%UXu%=e)JTJoN?qj'5$srVhK,0i4r6ZH18*0G]78;LKMFdhX&93a6aP@LEo6eC<\l&chb_nI=C(om8JSAhOAX1+74+7gl["h=,]d\
-%28W@7g<T<a*r>g%oD?:+34)22pIh=-+_]VMX7i*uG3AjWS5cfKpTFM*rR%RJZke)PI(AL2Dg1WdCNjabh1,4T[6&SN?i+ipR[IIP
-%;RVFob%.mJSDC"l?er;9mkoLO\uj_rXIRtA<D%pN^92M$gNRJcpb>4&rj/g.6Bh@!Z>Dj&0i+4Z";mQNiPD>:Q=>`uPn^M-KRp;O
-%:bPIt9n6i62(F_Fa5`@r:NI5*MJ)HnYic;e8_8jP#5VP?jjf,SA9T@J$kj0PZO#S0Cgq,m[LS;la3_fGntVeL6f;KZB:Wi!i#qS=
-%)fT;Yn7"()"?;&c;kR=<?OZili0k7RPu#mPQ4["[KY1p*d]V*MiO]co&g2X\gpc2J#['Q#<e_&IOfJI11mD7Hnd-NK#?;SsCXTn8
-%A?IZGMt5jM22*KT08aZ%'D>McpC\5F_"aS_&Y+-('FSRkI$5*&)=W0`lbo"kZt-nF?"\$Z$QO+/-P_hK_=>.TR^\SZTNR"YXp!eq
-%6$+ZI#Wq+;RfQd0^;O=Y+;[OD*`HKG'(b^FJ'^$+<6J0U7)7"43IIXJ/07\lF<Jj#@;t3Jl7RDj&#:!ReRNP@q?!)t"a*Wc-D(E_
-%@tEQPi^4'1,r?t<.\a5RJOru-h*"1c#6TfK9&L=i%udX#!C=2_\b3<81G/CZLdMrV0:>0;#]WT2MJuu31G^r#OH=TZ3&cB!RUgdj
-%o^KX'6_8I?XG/\QQ9Rm5DrH3KiFj:)0&\e"<9,cT)"j<Ak`DJ!);q:>ZN85.=n.1T3hD>FC[&"m/s@Uf4(QqCj8occoNsA1ZEO%%
-%:#b:NE!A,%!-OH$[Y+&#@4qG=RFu4\")t[U,V8N!8)-Ib9@1eQlS+l%2?QO(dg@)Z[a'+&iM<cDmh\5#/33(GA=*t$JK5n)f2^'`
-%3]F9-S)!$j2A:V8R)2PZ\K]YNMS3&h5OL"IFj#Y5H397]4QVl'T%CgbNF8Bi`Fus%bbHP]Kb;UE9DGV6Ka#^'a5\maC5d^_"]'h9
-%?th:Pfd4F&A1drq"euXH/did/R\'R=+b8FjbCDP&p&tTX1ZB$=I^5T'cTi"L!M2D+I@fkLKSg8<<-`uqUTPd2#q#D+OOFm`r'HbT
-%r`J<Z!\ZB,o98@'d3V&\`i`rYLs>8lE?i?!4<F,5d($?YT+gn%>''d*!BI+l;[-;O6!PX?b>EL25ZV!QSWH-:CE4a!_KLG?g?/,c
-%NEron1uX4U78=iS%"UYDT]5BM$8k)&")]Mk:^'7G#5k1E?%BJKqiF0mP3b,>Q#86A;@-]$>mk&g!aos^hl[]qG(cmr&$nQX)4n7S
-%8M(4dE6LXi==/*cJh'lLeBA(%2uk:9%r#IG1)VhSrbbGB3:'!(/lOmY+^?(YkCR4J$:7+i@U8+T#5"<K?>ST=LT*Nm*.VNRXm#7b
-%p]Ai#=YPD\PakFB-;-*O!CI\K'*2Q%#g)*r:d<%ek;$"%#bQXu=_WKB+fKs+Li)KG;LXDsTf$CoJ;$Jl7a!$BbA?jRNZT\N2`Dm!
-%/Vi!KktZj2lrHZ'LN!pV)?>C+5mc=VBmqj*W#dL,9M"D9&S]'R8dZ\++"GHbX4T??Po*98VAVZ*L[,q)oYCO$eQXC-HU%_$T$drh
-%:n8K_NW^$:,I8T<!)`8k/5q)Y.?+9(5QY22AQp'fG^I7le%nG+aT:=6^`Jag,bQi7>H<8T6Th;gh1e5]'sK-SJF+$U%Ci((,cL_B
-%+s8#cQ2$CC#]R`$n+mA&i"QIn;G'2>MRsH3J5=OA*si3,%J0U'5eui[QsD0pGBU^(a!(7MIJl%2/,R`Gs,aF6+o`NJEE?99!\Z_'
-%^:^YRm!g\`Yl""$IN'm9/+1TAS\adp'\3&/iS@t(r>gB72ARe[3q_;9hEu0U@"lJoJ+f/*@kjac!ZbCNWY^[A?ID`.,\-o*GkMRp
-%ZsU#&`,37mX`5'Z9b>qO;pUYOqJX^#AIs4N%mf"f!J0le>'=X'8;27,f+Zkh5:S3S_0:c'.17E:*aT-+n23TUBW_/S(=2jsl1Nrr
-%0.rpOje_5[[>P.kFQ-.NYIkkPRn9Q5VSi81o@()@JfK4M?X1ZMrM3VXmPTW@^@Q6,#O2K%;!dWl(B3]m'3Sj.\4T!rfZ+?4UK"hj
-%N1SV0==e&b.Mi+`kf)G8rRJ`AY;^@M#c4Y,^0WP^@kX&r/Z!>?Hf_o+Z.R62C0+G6bHI36NhA>i/SP;NRPRbMESkW\m%*(PZ*`t#
-%'jsS%ch;7G=?<CWWf:dc(<H@fH`N)@/)BO/Ki:#fAOD/hK3N+Wjgt\JJ!@)\8;-?SB2>W62m?>t<B<-J[3i#+!2e\$/R+:']l8:9
-%qM<SeV_"7l$9k+Nco&M69oF'&K+HeMGN;-\j]CirJt-"E]620JY;p:9U8?=cVPA@5b.-"!&$8:ffMYH/2=/hf21*-qqr1Lkm\MSQ
-%2dJGE".oBoS];2YoD=uOQ`QS1SbQkJ:Yp*McHQGYZ2&\T+#U?B6gF&MV]Nq\VAK#dWnk#Ngq)d,3>7KLV=M\r$\o9@<J_=B_,5C;
-%$ZHM5(bomuYa4'+4+@]E-TV'So:nUdD!ZOlV_"In)#eK$baQZ_3fTF;>K%*\)obKm)*>9V/+sjGrpUd(n9t>0H$YG7J.:"Ap?Dh"
-%4co3M3-N0HA`)\L+.)Zb25#0*)WG_]=@IlaV^KJnR3,0KZq9;'?[k]Ij+cU6Z7E0N%X)47qgRM^p=2K5%q2uYHXOk3<L]>^_Sj$,
-%[suq`?8-MB#2RpS[s0Kbc-$B=p:pS_kC?amR.^:((JfNL8<C3X]+-I5dW]!.LcLoMlka<T@IX:]XbKiRD^)o\4+!@oAFTSVa&_i6
-%(2LQnhlbY^(4?^o*!QWIHqfSD'WkHgZ/Lp.l<)>aMn<':gN`#GV6)#I3_jZe*<./Vk<#MOH>'l:l41M?'NkX?I0S5kF6bT+*m]3B
-%h6V)lD/jW,ZWN(HNFgBe4"%$nHgb22ZhN2fER`k@G#2#1M^(&!(Y=_=0WJ&kq2Bd[76O#)<X2X^FB';bdu@Y^VlW*'^$Ft"%3K^j
-%R'/Ceig;YWCm[>%@fgYoh=KeBr,NUgN<leTT,k-'HgCU?8%[^)XQgflJ@&\XBUY?Blgg>R;'*9r'DFY]+#N0?eo>\?GHk?#+3P[O
-%j7o&TnJT8SeN_j`0HYSqFmGqW+13a@9>#"fYl7%>^?!-'P?[0kWL3<?e4%s$D*M=<qbWF;S/\C#J+ZZ>T&.ABfsAEJZMW"jCT3^R
-%mb^"9Do;L%D3E'a/P"9Mh$8A@If&QHMUV]@/Uf[+n\WC84#bCLf-Y)!PD[ei@m$YXn"Ffg0:P*Y]B'^9%SJZmn1[%dIt6k"*060>
-%Gg'[tMAt'sZ`o6cn\<>$s3fk@W7@k_)DG%0&$-*>9^j$)$0V(1kuBJh3M2a<aK/0XWG,cN2TAAa@/t]GqpL,/rtfUGo`CuRfjl*N
-%/ll`;Vj.$S.C>m!Mc@PlGplW<WEE(.E4Y(K9Gr.?k^:QqF;DgcaQ3WH[>LUs]j+GoR`(m"3rpiH6R]KZ0[i-#b[G'a$BY\\3Kf#/
-%\u\(<C^t^0-K/GOK2agQ6l(2?b4r*'O^:UV@?O&#0k:U\Ap)VZ.AP?i`j$hE]L`UTnSp!&l&qh03"$G11,tZV1Wb:2E(h-<LhjSZ
-%/gD/o8G^3^A=CYmj\7mU<]]p`q?5]XFP]mu)G1e3[e3JeR;Z\P#)qM!`6hss2FkkVaC/0Tf,+5g#s<s;BA6ep"?`oc7+38U$'Rm\
-%,R\Q(pai+hEMA]]l5nQ1$DOoGdiOH/Pdcc+J3#r1JsCL&br<0<+eMK?\f"XSYi`pd@Kk#TU+>=]e;SulQ?_%6;[QF+?j@$N'V2-9
-%gEt&CT=h<Uk8>_R.o'X=K;Kk@cE*5nfqFiU_@q1Xl/6Lg-T6-r5g6])j:;e[Ch_*fJt^fWd:22?n:!Y.P:Si\a"Al"O]0K0I$U!.
-%NE=K.n:b?P*57R<a<ZWkKBQ?eT@EMDnPm^P&DfB/*)T(YCD69id0U&8\iL4fJp5"@Q!>$D/ke"CjI>eDi/>HY#^<nT<6TAV'I$9:
-%__,Xp;CP^d_tR;b6/$r2:(EfBM?''b;=T\/.bRCGnIpqcP@1)3L;P8[Nc%@PN<q6NN*D`!GRfW/&.DZ63il%*aL2FCKlCPm9L-go
-%'=L+"O"J-oTTHJ$9"GLdfEI+dP.:f%#ZN?u&:G2Rhu`?R^J@rm>g_O8.;!\OVQ7=GLifF74QS<,*>2id/KdE.o1<]BP!o`Fk@BS9
-%<,0jK6#,fO4B/>E'Wi[>Pkru\Q*M&l[3Z(,&t;-UY(ucfRBB4H,U"<U_'\V+=+nVOlD-fm!cjU:Kg=8C;j[j.<#qIh6n&L?fYMG2
-%clXEY&82H[OffNOLg\C,aUc8#:_js2^S/QN:(ieCkRnlk<W"d0Zn^Jsp_q#HaG2b9aMqPfF*j:em)&X]#UrtXS7WWsN@'EjH#\D>
-%I-RsHe%^,e"F]PK84=1m*4hoEZWL+7EqMc&1-J+p=H#\"lJ^B0.>/611chF@Z:-kc$u&RG"IfF<6BGm-*6(#6Jm*\CQ2kfa%7cE_
-%a"Z%!#SQgoWcSXs/dp#?nc6lFN*GD""oskqGROh=GgJ6lWphm;!eOSb7P]+*he!o@a#'#q..e*(Kh\X];J(\AU&rNB8-l"X:Ml3U
-%Lt8&NK>POOifVhQ,I%fKY/[Ute/53OU\Tcf/ieI7+q8Wg/Q_EZ7!8]8/`G]pBgQ>#*7L)5#M(>n\As,.NohJA'hM6[cOl0jQeMVo
-%'J!G"6%MP4H#?Jq<Yj"ud&gD<.87Yp_$eL??f4'9eH1t-cBii?@-Ci#V\(#V@=9e7p#BHREZDq.C;S0RENFLjQj#2ai>8d@P9smm
-%LQ!)S;CcQT#!kKDW0Tk&:t'Y7@%q$PF]$la=@Q'.!/r7<6%U9?3V5Lg(pL`fOrLbr.iB[J2.M?OGRb(f)1nD)3.QXMOID>n_XMpi
-%HE<SbNCUp&ct-?M3WplmL-a"[N16VZ#_5Jb?>B9_>U_B--Hm6%k$Y-o\/6t6'!db24<_0IJ2MVC#.PL`4A!NF1o69rS&O0/[Sf9^
-%M'jtfI5f7lKc42gh7+.;F-M@\MI8b<VjVQaYHqV1Ga;;?U\Kr6`t!Hi/$rcg,<SsSeu-&p5dHfDJilo1'.+<D3V'D<8><"TU*gk.
-%bQ<F*X_CBV:j(2rVmFY(hPVObOg)4OEljIY"6ho<ckfBL7$p<KOKnkOE/h?pLo6r0"V&>7Yf!JT3hWclA#dod3_f8u>=/ZD$>6\K
-%BumETPF3TtR>0/WF&WXrgC^:L!G%8f:bp"$*Ha;nYAbRuMCtc!*0[V23j-GYJSDps-4O]g?3lW;S]r%g,D-E(/)*d/F^e0,OefcT
-%9uoTB_I9La`jLrY#!qpH&6JoVL2e\Sp0c4k.g_jH6kWq/n$>3UXb>AZ61:8.H6HBo7-eNCa?4jDmJ)Y3Zo+O9FU`r@ZJK\*c*.AL
-%*tZN9F_"Y!:T>;@<*YU/W)R"/:"#9kV9)'%nekhO'gRkL9XJ38q*"mrZ'Wk/^+JDq/=eDYWEC:+Z1t3YEn+C.c:DIm(I93Mf%<HO
-%fgniqX&3sTjV^u@N9Z)FKkE-2MAb]@C-!N)'U'4[8338S5e)@R1J8L'dh]PH"j9Ish6S+%!%<R,K$iQ9=dB@fA@+W/ljm0AKi/'Y
-%J=)[bKuJ8JAGRd]1c)uW#=@T7-b>$KAe=;HLkNc)M(Z%eU2O<HS&EgUP8-j;(.4Q:39)\0*@AC:e55<0q[BZ\SKZ8NO9f%mfk),O
-%&6M<04l]6p5n?9Q=X]to(sE`;S$3qFq52o0mKqX5_4T[74"D%[N]Q#hU=`%/`fl:iLCW"eBb)?Gq'6=L8hB?$^`$h]$C>K'U8dR9
-%)_D&6Rb5"jJAERWC64-@]&nO2jn#TRC@+n+S(9-PG,GY,i2$X9_"6n%+2S/&2Ts*4(<BXu8F=1o<.mcUODNprNtR(ZNU`R\dM[K>
-%dL,!t'i%Po'fRkpO>Bd-Nc\+b3DpZZn0-M5*`b6878k4L2]dS!%t$>:=]cHSct+OcaGhDt/D=j^$__(r$tYd-*IJZ_4TP"5.PV5G
-%RrHRm7FA!NgEo7._o(T#38Oe^D]NsZJuJ2EHjM)'4br"n&k.C3<a4]h-tCo^@>'^%-mU@707]uY8Xn`H[qfuBP6N=kjIf^^3Y[b=
-%mU@$W95F$Z.e82UZEQa*p<ZeG((QR]]OcaSA,Tk&kZSRh=QTUJm`*UZ@-lt1-$4Gs+h(F(9!X3tN?'Gd4&J?1)@?T$+EjL+&%H#a
-%%k`^;a5?:;Tn,s>T2$OiTd@\lDX`:anR4dqE$CGb(/E*q0(ts=W#Rgt%2dH[&6i(&#2Da23BYI6N+aAVK4@J@7i[bi?'VOpe?osi
-%,(j[3E!gU;b])1o\]i<TCEFp-)I)6B*!]\Dhr#LDPZ"rk_%3]g]]GI#'F0J\BO@6VX8n_kLO!CSaNb`"/1gK;l)lW.AU(5+M$R.C
-%gB\%R$MB70-,PTY[[E:!UX>GNe1ST<@B]gdR'TW93_a0N-_;S@lq/-83]qRo:(@B`BJTi3)oms!^nF:q2Fit"1d$O(a3fg0W\'t4
-%ABJS/%5OBJTtk^"3?6!nGVb6_>S^Ir\u!Mg&M)1[G7n@FdT#'5Xo8kK@VHH0LTdE9atn_OgNCF[7(UGn$f<Y+^Ck8\a:;Z<.`OaL
-%SAqY]O;:TZ5rrq1@K$j!A!l@@6RF*REaTeJLUX3r.LXhr7XJ-U#Za`bdk"iP3pL!gGbP^:hS.*1)m\Mq2k*.5W4;#SRNjD#.i1lF
-%Rh)&H,8`,&b"2(CO3^de24YAJnfCQ$,h,L_-ug%/95A3REGQUk(&PEnbMldPq]Qkl^s_YlSS!,H!^E%dBo@-]ZeGZlQtNWZ'E'=.
-%5:#fbi&2orFpPt8_lpFIU`nATliOFlW$Xo:aHG`pR48b"7LmXZ`SVIK>]O3V+`"I.YW+890Y)dXK+jCC4S04A\M3*hX")++iPGV8
-%C>sOHG(mY`N&[s]RS^^2O3eW:.7B!UfN`Sj[13R.D;)h/MKl.0)+W!W#*.,b$+-&+;74:A<EQ@\16clA(e[fXXLgO63[7]Nf=gEi
-%'mhPX!Kn?H14RpneUb^5.8hBheIrk?'J[i%\r^SE*%*/T[)l0D)(LPP3Q>J0Nd1qKOa&om;0bO'8+bS_SB6_6],[Z$%&f[J\Ml35
-%gWYR>=2*"VT`oZ(MG_sQ1_0:Kl%#!U&KSGt?1pG82J&m1kb&njCMf8o_SC\A*ChJ1!1kPQk,98XI:RN>CC,c(L26;7RO?B3;o>%.
-%fa7'TY0p;=]f>ckTIX9K<M*+pP\?7j#<Z(B/i;@.>_\+!VNt,1_[G(8R-cju$52U9_%1t0/eeRqbO[1*/^/g!'#Bdm]0]b?OH-p`
-%@G=HsY6iH9*7.2Np>H5`@>&]GTdf^>=ob90bak?T+CV2AdJ$!!WCO,NbfC=S/([5[6j"*e%rlhk`'d+,&V3RLU$('g;P74-ai@aJ
-%T95O.Vn6?G>$f-rnO1e*=P\D11N5J8Tom[(E\p>*gQ'XG0F(f<q/2m[L.!4%a(A7B+M?+m\1:%S0Pp_S2r2g^dO!:b<@Qqh:dX>D
-%$Ls?+Tp7\(KcDoWkRR=(K>loPo0b<(@&9!CF!JC/?VZ6IQKd$D&j;cq^]BoI/a?1!2)r(8aB>K3U'_<NnE"Q2FnA4'VsH`*)oQ7H
-%'KR`^(mCqJY_a>?`$+oo"kXuCEJL5<93)+DG+-PS-&TdclP]io8U-kX`a6snn"phEX*i[I!5$^f!ZCA\gUG@@gU'3nODZP0frf%q
-%3!>m^rlXPQ[3hG+2s],)C0'LU/_`06e#m2?p)TWECXt4\^T%gc)aK3:\n/V5XptCM,HNl$:pmBbmFsHJ:npV&VEo,"nW[(I"@2gp
-%+?;tA,RBN?[ap;6^-(A)6%bR:4mfPKinDU)@`"N_c%0gT5UY<`7N<E/'\)>oh$Ab+k-/nG6$11p@<a%)J9-c[Ogdq&RY9E<3JbJp
-%<Hib2B:;Yf+IEDhi1bX.Y`8^6+HS#r8-Gdre)K'0;%2'R7?%0>]E+qPPp"cLq:#qf6oYb%^^Ql'&tI+d;DV=Hi,fjN$4>l\]Ih$`
-%*!-[N@`!RXfQ#UCa$Z)j(bFbu1Vd#Qn[8`!8FU,_@VeuMRk/Sn)87Rf0EATiTads3K/"FuQ>%d<,+Q*gE&M,Hkd!FkU2tVoOFJm4
-%!Ue1rGu+2Q!%5Sm:(rS$QcCk:i$\8c1l2#;IYJ,"S,49bMeeeEQXK<+-5/\<$3p@u==")GrbZ\qJhu,40e&\'4D"X6)I-+(;Wh<L
-%WW2Y06W`:Za4B$kaN'"*#AP+aDee&O:epH.crCKl-<lofYPr&,_XQP&8gXa4&?Z\\)<RqjXtkG]\-+]+9FpUB<G;mGS4`b`BIN/`
-%S23"0qDMQk&ATr\>`":[d#iqC,soM")HA,j-nq"h)Nfj[5\@s!SuGr114UE'oHWYNi#qK=(a*eT=Wq.6Y/N%7PftM\Off!C10==Q
-%.I)(;UHM.&5naSH=!cV^:Z]QRa,qT]Ba@Fh:S^g(9l1rhHN=FEk?bCX(mZ$"[]RY;RYV'^JL&,U?$95aOdiO\-+tY9C!rBU,##G!
-%I)V?qD(jD5!%BAB(!^/S?-0QU%<ti,jS).ZXRKQe;MTIr%++ScT.bOU\HKVZS--6j8dmKU?Q43:?hoYrV.McIFPnQrFK#i[!?_fe
-%2($!:).LZV2B?/mFn"b?=8R^H6rQLq0UZN4hZsr$9u?KFbQ25Fg$rbh*_mr%5oLDDTg&O4*ll)aI5)?X(j\ercVT8D#YA1GLp@.0
-%-/9`Z_/1,3]:Q"a)4_[.K8"]3V!5p#WrsE[E!DUEkm(=B1nH]Rfr)6H-<*Jm\f^W7e[f]8-2D:*0s]GY_3uLg:,jbTAZkXm6e&G9
-%=3f%JgsM2q@QG]8"#_^*EPT2")RAlX.iI,rRM2eUr%QT"P?g."!q.#Y9]QS/26UbWM&DU*gLnSA)^`B!"Xe5E1?8'pWD$L1?s5E-
-%l(6lmJn1$SJi#S_8*gh/kWkk!/L-+NGC$:4fRcO^Z@;dTMpT-'!`nnR-;jkr[GJ:$!:15K`"89uO];FfT!mpSXs(J_4S"SMR*&-a
-%<(g>q!]e\WeI-Nb/K&BABV*IQC%QFrZ![XoRQIF`A&a2pcLql3-^pRJ](@QE9H0:T#>nDA!Y>d,bt*MI8fR9nd$LMHBJ.;cM3&mY
-%5YkIGG+98PaTX+!d@m+qYiP>J\L6[,A@aM#$b9X.#Q_Yn,qIB29S@_;R9kV]P5pot0uQu@/5`^KfGK9DBYnRSB>p,#d(r,kIY>Cn
-%%\!Ju/Z8`+N$qB\o4lQO="7=Z97fQTU:Z;G#\q=+o,V@_/?/^*c-iEI0V"9L#+)d[!-%+R'h_77J5h@DeWO`=B;KPnd6bH;XcT\)
-%c87:*J6+:lm7a"\&Oj)]'\ef@LX@K^QDRi0TA60j$^><HfotrN<%h=M=#?<U=eQ)9:;X?sbY%)8$+;1?4dR.]EVCqm24A;+d>;BF
-%-MrP_`*og_S"^%K80q*/NSGJ%=!ZDY3ljSG(faYKWiOJf`CA+2Rj_8l:L8dr&1DNWl4==K5n.KhcsZSS01Mipj;!C.9+Q'[h5V@G
-%Ii74C=oqZ]hTK;Vg8cq4a)L5BR.,E^n#FVRRMm0Ljm_m*Uqnn:jXq*TlM.q9aqk2-8Fb>$[apnq/$fpAVkF_!S'F(9fh!&8E)i'H
-%B56aK,pQ<R&eTqRFul5I;[EkDOrGBg"1?)j3C#sSiB[/AS4Lsf$:5T?f-0Q:"pNFSDa:[\_m7R$[A@kukG)j,7%U"[=6;&0$gYbH
-%@%nphC5%dqnb7X.PK+82*/"ktZt]P,)2-,'_PDmrqO0*O77n\ZE^8WG'R01ULbI-nc79G\fF$&h/OiV-WhGPHiK<%H*PTAMe-XJR
-%)"p:VbcsLJ:M<+JRML&OI&ksb^m<#5lpD3J9B-'!gH+hIR]6mC"Ouu_V=Y2@6A*arl"EE.=W0?BA9UA*_LY6kbW;8K)Mjc8N,d8L
-%4?AW0^cY!Q%#BkZPB8qWG/]2TPIJso&W"j"MKoJkL=C_p-AGG2S'>Y^L-f73mg*kR7h!/V<uDii""-TDM6j?gMng;<%9+oQeC5*K
-%mO5rI.gTG.2<b8A?*9peN6Z!N$YP:G84O2`";sthRTcR7KB2:lQWPFR(1Ea(&0t3Qn-$cSP_I4`%er=0C&m:H9cPL;9*rma,T7&6
-%OHBq_)hRgQaqQ!e+QgfY(<K(/Op+*iBJX(Y]i6HY+XmO&&e,0V1'D<TE^N5t4OKINS4ZS_.2&TKcefKEiq3U97[1lUClRF/bWfla
-%KNZ*bm<Ta1a'n'`.N'4_@1KGD7*,=\hD'`>"VZIF9S.e'>Ctcti4u]/40Rn'Z=&AbT(3l+nd*)<0i?o"b>Hk>*,d@+(9C]8i<hA'
-%0oaTimE7V(dh/52OhlR)<Z"G;l@b`Sc[nlB(FC-4d)$(iA7Q80=b3Z9Gd\f!^hGXM`ba3nP-7O2%AGQaV`^uVkC)GH:r!<0UhC6/
-%,_n<("s$[o@mD;-ZLE![LpFBH,^SO\LI=iW\0pZe,n$&:rZ96Y@^Zup!BH6`0G_NkCnm(L31nfF3AC,?(mpmM"C32S/Y%.Q.9S@8
-%2OK*!,F'\f=GPsc.?OZud0e89U<<d19b-_Q.?^bdD>X^9Kc=]GI[J9kLn<j%fCgM*&fpOt=Di]C,3p(aCf@HGP_DEn+o$]1"589e
-%:n7[n:_/qq?OFc&fU*6B$"FdF+..a,@0W=eY6&8`7k:FgM9C#8"FG.1iofdMQ$<&en&I/@<',-siJI9hC2#K&qFq;7iC&],&#u5W
-%foSc&jC"M1Q607T':^RX]I.d(O;I[6ecG^K[ENO>Ys=_#D-Ai3T'63V$6H^m=paoK_<_tX!?:iR!@'$N@5:PB06lO[L+%D/o<EFl
-%:'LP?iO/d]UPH51!i5NVVIklI]m)$ChHn,>R6h2m18Y.dL8N.o?n)M#"2u)'h5_.?&-5L]&V<7u9dH9lD&reT_,;Rq#RE2\%Qagh
-%MJ(NBFG]<^^iW*Q$p>QiU*(p_pj=6LL"HB5hP$VNAgR[iW5OXmipYFYr"G#Cad#J`c,\p0:6'>U!e@Q#1!LP#6`3q?8ONpp$$V)=
-%RQh4TZ['&GHVdPG%RKQt@(nb@2!@\^WQ7SN-#0,D8[SSj[keY!AH:I9#/S^132-U+0oV4^`F3#07,S-.N9gNE,Psr4!aQTr\Dga(
-%]+KSKoRoW%,?ck^]3M^eRY!#Ac%)_XnQcVu:B2ak-?knb$ofjTp4e6_OH&+6a2an8Jh1m12iKA>P_T?7Cj*^ipj*_rJskEH)R1gV
-%iR!+_+,()q\)EVj4,0RDWXep'acljm+d'q*$"a#F:jcI]$Z;nqD!]n?]h:B;TiF2\eAb19'LcNb!$"D8l;mtinsRfji,B78JhTa:
-%e:RrN$?(Ql3hl'Eibf1J`#sFoJjVd7MBPe)^<\tf$U"Br*WK9>bO#'ZL]kDX>d50r.+BSenoRqM!HAf4*8&3G"Rf9!^]oRo9lh$!
-%JOB86peK_U7.J.Tcs-k/LI0uU.`SNA6"c(BKb-[Jd&\4k:U:iAKa3l].km_MZ',Zj:T;fH&Bfr@'_/j\joXL,/e1D(TEuVOUY@M%
-%'[I=SFcT'#/;'=i.+,7Q?dk]<VEo)59nLIhQO<%6+$,PpYiGsi"ULScL',GGL5B<'Qr;Wl)7E)1An!PO(H5;374TODO3@N*4J<KV
-%Fc1B(Hkk!3Ip.X[2(TJL'da,#S#.W(p;@_bPOG1Qd:,Yni;a2dhOVcrC(T?UjXFdE@+7]L,]!KHn7;-DB],F.liCXrUC^,>A2#dh
-%5<@_T7$]/4>mR&l^1dl3(E?Z.^bp6ph8.g_&1L_0/>\j=HlZnM6Mp:b'U_?o*28!9m>B<m/B/GTRg57Abcq07'eTk_+_F@P1_%kh
-%;):.O]tbIm@$]%HJO9D\hc,$J9ju_lH;g1u"`^5heW':-YbIOVH2sM,er?I`+[86uE=5C-391AJ$QjqY1Y@QrDGS^dK%_&umg+g\
-%`-=<ukQ/5GRQC4\*2TF)/tpB,M4*uAE/fLnf0)!MGlBIdVM,Y*L[$&$C4bRR'$!!L0I`_]5W**lI'9M(TKZ'!kVO\Lra&OjGp=su
-%>rC[cPaPVm+M^nh>YEk-\Vs,c+p'VfLu:X@eRfA[#U5d]1hC3XalKuC_^=B$(4NPaR%8&"LL'2+Q76JB0ZkBt;#qIdgD:&GMV'6E
-%FBm`]\>@/Qb$tZIk%q]\EbWp`;9J$_AZIg+KM9`,M&$([?gpTZ)GQ.p?ULCl=MK6W*A`-/9<O/q9!4P?`9A\hWWec4MWHW&12\o$
-%`Ca_bQo.Q2KPFp`R:PkV9HmrSaD_+]%A,(`.VoJ\\<rig%e,:%_Vrli=<CQp_l0R0a5J;`Ps$RkVL>T\nW(/UC'FK2M6mN3O2Grj
-%N;5i%Qd3;X-:OZh+e+(3I9e8]I#P5Zfe"=C8iW[:kpX]I3*+.O<kW/I%$0Y:&;pUlR@R/V8,/FlM';'a('0%T"'4^fs/,-$U)sS^
-%7K*MI(%irMHO9sM\#6/;)<Hoq2KUnY9I:Gd"&Nt+/l<hp?)#/^HUS^F)?r5=6/KK0L:A!D<5%>4!@oVA,!&B/Bd$?4-BrPJ)c;Xt
-%Lq@;?:qA#_M;\>!Ya26pm73'5RafOP>'-H1*K&-pC4_j'PPnCqIc$eJ`>Bq:'Bt$$Z`q4V[%F4R%uF*:Z"%JdG8B:FFG]I@4Cb&m
-%c?3^IM-CYYCL#$os2G;O&H6Q]I"m1;)tc(PQVtKJVdT`lR!;%FOie$OI@;%'DbpL=p7ipam0IEXa]F>>O_'0<^0G,AM:;MF]pds#
-%9;pN6/=l9Y3e\J>N$1GJ1\po-%*K/!/&2uFq*f7L!ME/8+.ipFb[Y+8XDg:)n5(D+8"[]_`$NV4L,b>U"&"mIi#%oZ,%5lQ!]<7"
-%/b*Hd3u0)gVC):XNo("iTZMXlfJGSSV8P>AJM>IAKZSW4#.Om*2\)h7E?YQ:b'1s<_!uNnF2]FEXBC;&duhH`8&GlI.tAXtKG8eO
-%8%c^t3a#=%_XI"!SDgdY*"0ibggL5^B[,8j1r?"f8"b,/IKaeaV_.+)Of;8,<CS'd4^>SMVC5Ob:)s+oggA,DJ0*`i=I2U.@gONe
-%%#;)nXS7D9:L`%3#or)9ksu^IeG)Ms<csY9>S$?:l@9G9[;rbXe]?/)^_Q4:?6b;m(fiVsP73`&F=JaBf3l$?JV4'nKa:Fm$?09'
-%Xj)6<n?Rkbf5ug&e5.DP&P%`k8liglZG%#`i)'`qqQdW<!`DUm>FK@;_nt(b)!@l7$J1Kp!,-hsB$"R^QRlND#1JjST0l4i(mZ&2
-%mKLU^6)T((&*JY%=F>d!(t#E3muLc.LXLc`EU,V%bK@)+3^`caTUar5$!3X%%SB@9koN+1Bo?h`FrS@kOeiD"S^=!Cj6j55$2;]Y
-%-'WZ(Mo"nH\97;Qd&,E:8G8AC;SaA+S`G&OA3Ah,U8&U`PINrF@1?C.c".IKbM50V3aGA_U&tGJT%\CNgBtANNZ?ARn1_![+E,8h
-%Bo4;sBWX^'gm!dkIDV_r&RQ^-Ci[`'`O?,lOi]+:Yr75Y<B:/fQ6T4Ah!\eFfnmcIe#"<&J`0D*29\W9UM<]Z?;N&2_K;^m3&1eB
-%QFKi.XC*q(kQP?PANpo2#,jI]du,a/s3KPK0.)i4IDaqOE"BrH(i4ih-A)uZ3+IS^,TE4`_X<iTO8%?mQ))^jDDgA.flQinZSSto
-%8sNAjP+;4VY.d:2M3L@giV&OIk"3^6RmQ*=A/S>F7Pg+blu9m*KUdi$1E@T`TST=<m_5NBF+K]9Jj<R0jG&KOC4W5#c5A(FKn0**
-%lShF/'!rn1:fL%HA_7lL'ac-_Yq$!*BFu'lM33^X]ElG98=u1Ma9@=f60:?N;"Fp_V\m=l)"^`U/7,,jY_(b%;P?EKaiqW;:WZdr
-%91c+&Aqub:_D"Yb5;)+$6lV:cW@n]qn\hD=(RHi7TWHS.!&7k[Pa,^8gk19S"P=7`94gRib%?9iI#t.T+c;g:A#4HSM*$UK+ZPqr
-%?@U%%.V6Ok;QN(`T1,U.TG*KT/>V@4&jeFI3=]>Ndf<irC*tH.9bC+X.O@)B6ZU$Fr$44@l+ieE;6nme3C,b>!kf1]\;Cn\a&u\W
-%i(*mu)8T=0,],$nVNUfbS4-s,;,LXim-qs'e/1rf'W1ej!1(H-Q;c\`/3X,MOQ8;"#\\fDq1tPC9'H]B0PL/t#T=s>*rO,XYWkB_
-%W*:_u^GC^4/D/e`%hqUK8VTL=(]';XFCXYnp+h818]it0UAPb=!9&0)mYdm,!T,A%5tE73;:Ik"7$9B>Z=.&+P\+kN'@$W=o`S%B
-%5g;N0J&$W$R7*:R'7cJR,_@2;0.b4&?nDZl+,S280F:;G)4$9s^7<1g/\NM>-\^363*@q,8d#BQHK3qWnZ\gh5ebBo'X0uQcX9\7
-%"ElcLZfDiDSk-(;UBsdEII^i+g_`VNE.E.qKbPZaZ^c\%659S'dR5Blr!gs26a!=4bZKP2r'6R%J=%2>8tAZf*'eBX^qGqj74IIo
-%W=eXFd9AXcVm-sIH]7!>,d0Cg1k;3t@1>UoKLJS"?jqBC,#jP`_EJV>R0c=d)OHL,*QLt%_^WJ[,TS[emf>GUkX,tBI55sb7KGk(
-%8Bsc^]VlC^&qGDFJUP/_)?eh9*"epqM3>]-+]VC]@8<s5Ymh>0>h7i(-g)%#.s5"t,9XOa5[9'n71+'m8_PZI;F,c\,"up%E4cr@
-%80S"I<"A:)73mRXP[8?`h3X:L`X%rl&/r5>L2^-q:1<99A]9t&%aG_`fQ<>h3oNJ+8->:#,1;t9d`UJU$CW)'P[<g/_,;ie-We19
-%*S_lio$q,$GgDC77#4ToB8o>iTDC^H<>24AdD.T7A=F0OeLg:r1`i)B6,KONFJOpBjXKgIcB:KP2c30-JO1EqnNFZGUjJYCLmmur
-%;D'#Q'O:2K4Vj(K/Jb.^Le+S'iHU"V'>G.9%$6m,:cG3fOd7sR8pj:)Hm9oMnW"3L<+uV23Y,4fBTc>Vl4LlWP#ClC"FVGa\[2kE
-%:*:XR1h[Zfk3,b0Sba1C8p0-'Kie?O]F0/;6eW;rN<k25;_m9qZm:G6!i2dP0LU%(*28/IHjDY?90Oh5..eg.0OdI"@6/hb!c/Ic
-%9LBuFPs^FdEKOSX9BeWZ)K%!N2-/k9?'25AW+8S0\NuBP@q\gs:'V`4^e;Wq!IGQJ6K"Z,EZeH3-@R#(3`un"$_(W&LerU:PG,Y9
-%@uT>RKmKtt6:_RlAdeu%g4U'+,3<0h;S5Ft$Hg8q]AY$[#aV9Z?FWG#H!<YsRSV'o!=:O@1bij'2M#AV@Phs0qh(hM:/Gp)\H+!r
-%)I2$Z<35#5OWS9C-)4?NS[`]A'9Z+aTYrBjfoluH?:"0j'7i\2O9fi1#O!ZB,Rtq_U?n-lE&K%jG8R19.n2*AI.s"acmRcipWRZH
-%/&SJGqu5;gf<+*J2;X92DpahlOG590k1r/c*hP!s5^=k.Ti0<caS8FMa9Y9BgEO\',\Vq/#cZZo!O*HOm.%qaKUe-1I#$HGM6L)W
-%#nkk1FCDDD*Ce)*1_H#m`TV?)?8m_'%+nZ6OWFK(;C.GM;(3h3?cXUO;AI6"?g9781Ut6hdBJ!I*KLeDLO)b;O3&YEe)M]YW$/>`
-%I0'JuA4D_[VLN@S7^7)Jk'<,UN@K-krC^'D!S8W;raJi%URK!m705>T&k_FjS9H(i->*HO*n$;a'88P?W0@.8rO,h)_Tt\"q>@%q
-%,Ke1d=<!/r"\d(N%Z3G1O<NoO;,Xk:T.:cJ!\q'Ac3#BY[aEX@G"EO@(Sh)/X+TXN@5q(S'-R\/"^/;;aYHX!nuFIo`>jb,YH*5@
-%4rTH^VMl68E`WgL=(^A\Q*/`7jREGN;9B7rV_LieWX_ep*f<c!Yp`<j8i-(d$q!oT0(>;4ou'Hu%2a$YUh+2p#9*%@l)PH`RmuP2
-%UuD<Y+\1!#D``q;UNCbIHW8RU/*h@Z5==N^Q[.c;\0%#;P_M@L'q6#@_f/RqqM2"I%)LIL0LZ/bOHS-`Uk?^l0^+`%^.'1k8<OdR
-%kcou_kW<H[C.P-EctI+ZSlAQ1akIk48CsR1ig*it6"X5FF2tjhQdX><mbaEkonH\!-#&_i#(U^n.O>O6hUXIMFd[HhAB`7:A&cd!
-%nHt`7B3eT.ghZ6D^`*X$'4NdERWJoM_G=9*60f4q&V;r1@a^/@#uQG75d'ro9M,U)Qe`m\5]q+t\f4=J.J4R$])sCC>i=R7CC*R\
-%N[n7P,gZt5cVbCT`oP@;nOQbSk"9].a67XHdi0q,51=^nn?Y@#*AY:u-N8@_YJ24o:e5p&N]o<7,oQ=DoV0a#PVG[SfeZ<dAnfPb
-%)ZE++)2r6&W#pj=16YmiaWu]O<-0I%q8'HQNOpr6q+8_d+XlhRs$7Ada:'t;"X]C`7&`Ze?cYkM:I*/o.9FR^92!8mR_TQJ(8SK3
-%):Pi.9Jbpc2GN#gb'c`',ah]TKZ8asN.pmqVMK7AP`RZN!d2qAZa_P^J_lVRJ2il/G%&0j'D-u8UL-B6gl>u#([6iGdY_LG"p9FG
-%^K<hF/#g.:P+#fc>Hofj=I3I7HBN<W6%W/FPJ[EG,RYH"UK;o?aEIK?X-cj(?q<eEe+4df3#\O)l'Rm4iJ&b$V(a.VS/ImCLh%l-
-%0]V"m&b<#:HHE6t`nhZ0oN;e)A/*8_IjS'DJLZbfiYjKV9XFj/fg'oc/0"d+0jt&`ckb8)$j18)_,+=OGVIMf/EDVWkgns?m)pIp
-%E<?-!&.]?J&aO#h8*RS%#`\,b5K6+aK6\__!4t6)U?&LFH;0p2;^<e_dD8?]Lm+[T;)/LY8LC65`Fk,,-q6XOq^Wua:>d6tHD?!B
-%#Gh_63<0Jl.)-FOr[D-;O[kY'*`s^5YWfujalONL-`,9fYGE?\,0<"b&Z"/Q0N]"L3S(F5I`42dOn2>#RmLR@Yo(b&$DG$$6S)-d
-%rIbCK(<86uF59^c!^)G\Qh)iYbcZ[\8Fu_l;Ma=Fc/1..KCZN6R!&_*5_/ckEFnDGY)<m>8WYUeh@0@.=oW:qVCl5Q3NT\jZK'X!
-%A*(?]W-);(Q-4.\%Dqtr$Mg'iom5H>\2O3I2JC4tE7ioJ$*T;b/(_!:3u19`.fktIQ]FH.@]q[qYptfmU.&\$NLM]&&;:IXJ(/eQ
-%D2Zb!D@-oo[X:'1D]4bYjT+]7#;1e$Op^A9C;$g98n6YYf6])m"fZ;ZdFRjG92u6V`@-QYU@SD&NuLHm@7Xt1B`)3fA_^7#d-00t
-%^T/OSC^b[.nOd@R*e#i`N13_s.F+Ba*WJ`n:`LZV%D=?]DGBg.dAMjmi*S`+q#AG8P>"C>^K*^mY@j9W8B4U&^K=&&5Nl;GJW;JP
-%@^<rnUOS/3VFY".\Qab0R;Z3:cmqt=R1ndK,.X9?Oe+q/Pt(c^j#P.IFOc'eR^0f3E5tLK;#1O7F9A%S?KOO]SR433/]Y\[h-%9+
-%$u5`AF!\K*,5j1A`m+ot04Eh7@58V@d<(!P@d6g@j:-b)lDFjh>Y6r<fO)61>.1P?Q+qQ^W*I+^5rTKUNiFRYmALHQ7lRf.Q?4=l
-%JjYiYZV`_HKLt_<%Cn7meS@la4/[_iT*,!%U^d1k_c\!8\P$RQA`j+((27kP)5K+gd?4k)jJ\eTm.Sd_Tdh7@mU1__+M[dC"EnI@
-%D-!LU["c$7Z;S+hkr.$K?nEt2M"pGPb:tT,)H#h5BMQJ0FfR5bb$YlHP%&NJ/%k]BEJZ#W]%(+YYIIV\Wb+L$:9WS^=447:ST8R0
-%A]uGZ*&M<aWQ@!H($Ab<?#QqoeeK`;$*#LkKX3_@i;[/(P1:YsBi[rG(=inR-AtXFMXP0*.f@[4>W/(A91b.QF^,kZg;@pfO,'K(
-%bpS!D.F]7XLp"is63UPW_L8H,44Wc+B1k5TBW"a&b%N+UkWiTgkIOY\TDQMj>,A_!'`Y91oiCoh1;X7%IVq.1[d]=iqVqkOSKU&6
-%RMA.p2M_8!s%2NG)BB?dM!_k:>Ffc72.:pEXu3gK1.";'1hkHcBS=?.@lhR%)lQ!TDe6l1>.Pm8:M7cDA$gDpdFp1Y[;i8'6Yu.]
-%p#CZL.Zh.VOEo/;#qFeDU]K"9/eWt4'<@(,%E)lKFMmZk1P6/\Cb_lQ`,+G9gRN_+p8?:(ZnDAlNI/&Fr]M)rWfU)o8l+Y062.L(
-%>8qd%0MYM25;;J;7\?+NN2?O@\PX%BX2<hFq2lOZ$8_KTpg8LB00f;go:mC>/Ls`akJ*Ib=NiMSCCQ^?9G5s$Wq%VQ;Q?2rh6g2V
-%:TH4&+lEm@Y//s3%n@j$U<5uA>]3><WkV$<UX<LYkin-a.\uma37Ms\eZ!_*Z\01YggJ0-]-L>GPYJ`./.J("f[r'-gOBD'7712I
-%jh$^RYP*nP'9D>_RB"l;S^`OjQK=S'W"!#h$6NP+bgis,b(4!WrBH];W;'/j-S[gLAu#/^RnW\dK;U<F#%4/!L5iB$]9AQWgWaE[
-%D79"k;De]fN2UkY`gbER/PS?u]Km`eV>=i*p172faKI.sK7;bl2hJCl?*Xbl=age"s+c)dq**g';[oq6eL/8kCtb&*Ltl$Jd.kuc
-%0V%*jE`9@V,0/`$<2og^/tP%GAEhOYO\EjId8BX05+p1<Bg7t;,p=M3]_g@lWg1g]?TB]>1<nMYrSqaJp]'WZhRb\maAHe4R3:=%
-%-/4oKRC&\AiJ_A06`c,8>%P#uX];>!\<H;PPr"]\nSobA7h%;KD3#Y7cYE=OoAf0:15X#qC:'G3qqt!=s4^&-a6diK_if^%_*]eW
-%N;a>:"/T1F]TTCJNr7XG!<8O+a.Kfn,N0n-&S$qW)".bj61Et5Dl%1JjYgA2U"b92"qsaNCqs3+Du*75o1cGEhLp0U2teGJ21SAO
-%>''J:@>Ql!(osb:cF)#n?<\$7b)2u\epE%HVEc.04J\1^PAf$l?XtbKnmW*VEbR@u&`RbY.iX]#Hu8ib0PU1!lCg-`j2Tt$%f\.9
-%Enk@,2Kn0PP^7.1[0DA,+ofhI'?W7?c&?tfoPQe)Xq%E3_D7`u:5M!,Ep]PLb@Td):pZ27_*?9&VRUklM`X%V]o?t-3N[*qp4(#h
-%rXF;BZC'5<fJUGClXO;)O+$7^>V&L$nP<8,^Oq%"[h9ur82!F8VAKp-&0jiW=(3[P8r\>h(U^o:c2%MAo"KS\mh:0&Jb@pYiKd2"
-%ftf7Yoaa$lQ,`hns)p*d[kYSr.IZGFmFQ%HH\>WVj.QAT%TD?q[CG+)m$jQR`@ZBbmR`<'e[(mkG'hZ+6KBk*q!+pOE?jWi-\""+
-%N#4OMBXe*XbW'.SN^H8E/5i#$$?5h85/4edr2Yif0H#R4BCKY6f_f-sr]QWuot_?[#1Y$)]S!2j0'b-Hhr.t_Ie$bCXeu#'F.d54
-%D(ojIR/`GWruU=;j=nW(<6G39))^U-ro.P=J#TPld6_2iQTMprLG=Q,QQt]s63R8i:Hf^W[".j<pb<9WQVA1>I8G`-J4E.$`loe[
-%rhCiu<G'=?LF7tWD)Td%mLarDM%\5G_t-i>Q@^s@a?P!FA4Ikd7kH)L7jReH2pn!L;2FKmS*82NI_Xi0j8\>"'!<1OB,&\DCncc9
-%oL-f]6Gc1G*DQO.-]04J[=:YH(d^GBe))D>oX@];AJ5mYo;FT<bbMa!GK?O+TMbES8capQn3t?f&CEE[1H^-:JEEn77bm#':7NLX
-%h=r+T;h)Ooo8eb]&VCDC+^l<t,03'^ec@,_7NI76rdC@\gDK)Kn"W=hA]sO]*?>3$/V*\_<'Ml.GDG/t%gMX2EHP8V,)GOZ34r;1
-%@-'ri<ZVpKEA195O+&JoKl".Vc"VQfV=!K@co]]`UVFuh(^Vjf_>g(Kh!^"3qX9d$LqhQ=NK<q?2K&L(iqd#^>E[:;D"4n'HNf6)
-%L8d\eE,/([/7[fS=gg%?O!Jl**+^0gPf*Nq<(R&;TE[IAJ-9$)^d3SB77]-1hb&HL8&cN,"VtbNpOBqYc>+)g<JE^Qg?hpNb+ug^
-%X#BoiE@3],G8e?DB9Ri*>1"3/r>H2\,3%KGF]tB7UHBKC@=pf!)qLkjdONQ]?g)F.!Y"q"KtMF</i&("'gn[Nm+?PubM\$1`Smnk
-%$'q!,kT>Y?OTggN)5I"-#0$oV,%D<G!!=,QN5D'+s$QRKIl8l08.#t-<bk5,Sgs\W-AA&m*rX:Q(QB4/R1Pp=p-J_FkqD@us-=JH
-%J#>m;heuk$]9C>FETYs\NB&raokL&tdBLuI?*p+Mr^8:gLVO%V1p@[c^\dmK(5C=t\_ai,&8*sib=\bbCJT]f[d2.6KM/0g(<FL_
-%lgBIH,"@&um;06^s*HU(s8H!s4b/#4j]B.bn"*GW_Jpbij/S(d7dV`cr\^+\ZUk+/Z=KEmF!\.$c*Mf&LZ.j014A-McXSCVT9oT7
-%4Mf^MB.%\)&Yji"*nPn0`P9XVYE,m^?Xjkf:c+?RM5"t?;AorBYQ"#E9DC)@6L+#P#sSa.r[[/o=T1GXCg-<VonT)X\)##iO8jj`
-%m'RPn)5aC,6\:D-!>_KDRaKLADT.)61*8`('akTT2-H1=Or!.$STO5-oEbG.&<u(oDpD*&aS))n(A4.e''>5G=>1F"a3>XfLag;;
-%IHQ>\*3Sn+EkB6YT'O/i,>nmJI9tk[oP8<pS%bhSB;O?)ojm$\pWHpe@7sAdS.I9dN+Bk+2&Q8>DILo9aRAKL51Wq-]8B>a*^mP6
-%?Z$KWHr&AXlNA4CR-tFL`Vm_dppJmRc,Fo$d@I^F5=-V2>$3-3l&UEqo"<O>6r]A"(<FhRXX<im.)rNM<;Jt8`u0u5g[.cZ30!PA
-%N(WaqdIHMKSr)qP@i.pj0r.X?gqnGl<YR6TQG>J-\J`hea%^j7[*=A,%jN<<S*CANo^/a7Q[0$,8'k$WNm[If3BurKgL<$c8-u-G
-%,BV5q%"_'NA\`d!^chIM_f6&8!;%/4(&f21i[&@tdHZb>9NsBRJV]I+es@D$4!.CG&uVSU-_JPfEGHlpMcNbE+8U)QXb8b]eo_fn
-%=*c`<7kpSY-mn"E>N>.Dh8*/gqApq=TjN/Q55eae-&R]seuja\7MCe@h$d.%9X\"%[8KJ28imp2GmRjrPf:mj-f=K.Tl)Oc:uOrs
-%^iNmNCMbn6F@sk_NK9B?#D3V%.ggb38OA0FWHr_bOm7>Q"TCN"I+6Y6*lNt7mWMb@'b\A+_k/,-2#6?qn2K@/_e3G*Kq8>r2k@+M
-%gd5T+CA#sIot"\e/DJMfQ<UmhXJ-3sCft$rV=`U_9P0+\j.g>E[CW/=s1I*&epa`#^4+a7<u7*:k?F,c@_X51$P,mJfn-plBgq#W
-%fan%)XC/$]F0I08%9CpoXZmE:e_2qK.E,DKgpT7$H5nM@;3bWK;]`E0*BkIH'Rn`CUb.HBo4>qDg<0)ij4@6Ts8/U,j(2et/dta$
-%[F)JlBs5)mcn7<ClY>?I5!V%ml64UL3#g8rJ4<:KSQTgR<Egp[eIY77E`F:eTuuJ1g-rU#9'%#"_Du!k*GDB,lAd02[&G\nKkf/k
-%GhQqQ<Ki<?,dd$=2lrd:W#4#ILagTP.OcrtOnjR.Zn/q&fdqQ6"LP=`>&Mf?8tRC!X/fYYQ)+OM2!\nUjE3f@&!b2H$>M"A$X%%<
-%B#ZIQEgMYbknBAfL'mQSK4pOaX6$CbWeKZ%MdZ@]Y9s]h7I81SYh7K-:h4QJN(0)&1)-l?,\%/b&Rh\T5p]sW,Qe2>*['hXhgu5m
-%"L+rN7J65GY`aeM.lh;'5;)nQFOWlUKg@Gp<"]g76.4AJI\[nq_35%&6nT&])>g/C8Qm=[(.9u5\P+!BVYYW22d.jKV3P&GU7msZ
-%(B"hF.q`Ef>uJ`Y'j[rR].QQ@bK!s84oYrTjD*Ge,W`p&i);!*cpc//M4mp&)jrgYX%nVN_^qN#_\muDA4V^V]fh"aJgY#CZS3._
-%#a%oJ?iBi*#L30r+Id-=(=j8;$pi'V4rfVIL454FrD<g;nGT#CUK(L>ooL2Ef*!2pQ-<op7sfoITf)bCKjVP[j$tKkce:$SR/RA2
-%mg6:R\s'j8d\\P9S:IFV&,WKn7r($Q@hj@oX+8b(M(8/8FVhHp;B5DAG\>)3d%o2*0OG*ss7p)5#+Ls_9kuB-gQ(oEA7i]n<;&*F
-%qu6N[!rVf^&)UQSQ;p*<o:LJMJ-lG;&%H*R;qU]]rr,Cs1H[(IUlGuYk:'/h#@D[1aC\k?!%gs*>S\kO!+ESBquLIY7$<fN\97fM
-%62^+[pa]DhXd!OIFF28PCI$),aAu:PfiNudbbi<u"eW5_F%K)@i,4)jnJ?*ppQW$0L-#%GoQ^\*[g$;=_g^=8Y\MDA?b6cq*/rX'
-%5G\;:Ri\<AamV8NR):fm3R12"B^U[]0CXSGX]6AZpZT6Yq^n(Z(.Mb`BA('gYaaO#h#.1aF-B)nP>pIj(];R6Kl`B`F.]i>r7`LT
-%Ut9J]=,9('OihW$DR?^B\,M\7dLQ)>m1@10J1T!EN&LK+8Gs?'i7ZCFLrY+hGV],bc/q6lg&+E>'\LW#N(/DU=T!BtT0K1M$MmnR
-%[#"1iDPJD4@/RL/3be*'C"7u;U`H&7g=+5b[f^p0lm=.:ec$mo1JZjeOgR_:rPM(ko&S&Y#-[S^^b8SR7HR\`<b+,ndNrP$Q*]2;
-%1TPY%/*5`'2U[^?Y#$1We^#>>Q"oVLe!38+40@&F^$_,*kZANj&%R>R8o6]0hPlbE%Q5&&`faY@>I$U9_d$d=11`kmLmTkL.OkP)
-%/ZBY=D:uKdL)Z%b8Jf,$n<d&^m;(_ulE8lHO`FaeD3C2J\MD%I`C[O'lcD_.OK_acQVcmd2BC&>/(ZXtY0k:\=0>ae-)=d9Lhc4F
-%[jE1T2+!c1QY:*0Mb;Ns/N!&72N]NuIgqK/5=C,+:EZJah\4eOchaXO?W8DF7@qI>KFpL"78/Hb'p\Ti3t`1:TTuD_+.$$B3U-fk
-%UTO4#'AZH4S4a&>ZQ-2+W\kNl,]gV]R8&J-lHt1$'g`X%.rBRM@pCSS7gfBI<pI)!D9stS[AM*.^25Yp8'Q8o=X>FTe8Jf%\C'W&
-%&4M3:k!/&hFO7&@e/1c4*^$bRE0&ES&J[%Lc%4-ORalp7XIQ]tB_?&f$E\bgNm"gbg,ZM]PKKte2R5;19jRr#S[Nu]fp&@UTjM^q
-%bN!$CgM9rY]_gnN54g/_q.Y_Po0iol7D5`^)7qF6Ujctj_5EDYPub(fRj'=G)`DFoT[jGKcB;+Hfjf8/rA^u5WW$-+ruq"aIG.O%
-%BB]VrO57,?XIR$G7?["rS)[)%Gf96?N1j?j0Gl:h8p8ud80Y1X7(\/mK!Rb\V?kTmd"4*bR#8KGImu^mpL(Ch$4KGLR8&6h>mlXc
-%<\W_E^hL/.0H<?Ph[+_hb+^Om;T18_-7+dfdkZ2"8m!C[qN<U`dhUAO2!3)EaM(mI3\#gXJ[V(@cKU79e=*LZbIYBYd(m]VZ4L2$
-%JqC6YUHAB#jT_h^%>+B"[hTXXA&nnGTZOtap;uU!4dZF$Lj`H#%#QlgUN(W/ZY\338?kA,+/uun>jbAe/(h%b^F$jA4%Kbcmc%`q
-%P2[lQ*KIYQp5f_.07ZW&`#i/WrMV`6X%(?2=roOk=j<n)HOj\mc<.90Xb[q=NE'tm2FU,,[I4UZ6bAr1WgU)Li/,f9603f$6b-g0
-%%>p"b5JUmN\FA[c54)*l#&foLJ63M:BX\lA6jb`Y.&2nHXAY$t1H7glJY_>3:(WYX1`?Is_aqq/H4<H`@'_^gXO_.js55I&@6o'5
-%C,kWPD-<0umB@Ei'H%?-?#(X:;J<g8;Pnd3;St6IWGQ=Wd2N=%NO)C>UTDU1P&`CL=r\G/WN\EAPp&c,;%B6e]fYW57X>)L<Z9;Y
-%2Be>FM@QcQ>:s!Tc=a20c.8]F);$P8BJ^3.PLPIjT[:^j^WL7llqb?)C,_VNA%!ok'iO`V*_iS>HdJ,Fp(8\%8:tS2@U3(^$_f*j
-%#J72k$3ZhA-upH%'[;N8(FUVt(/q=H;s-D7RNu^kJg7!Vp58i[g7tK6US`<t:lP)rQSWOk'nKlJA)3Igao^P2`Z"lWAbW"5A0\%7
-%,HMrJj97XT3\6/<+YET+!!e[L$Ekk4R#PZgFu5mK*;OMQBT+danY?>jNQigZ,q!'U&Rq#X00Ak3\c@]r29tZ$=?f9$JnfId>72/q
-%PUe8N3`gjO)+D^KnnBC+Sru$2^gUp@NhWqAUhguHM`@ZZC_4,eEPh(t'(8HDbe$2s:;%rRVI)brVIJ[b+iSK[9?C%<b-fri_W0L)
-%(+ai:K%^Af(b4C/Q0nW6E'PPPr*MqYo0",g+R3j'j3Qn]IhlV4*6S*:S)b7.+N:TlS"A/Z[3VkS[&Cuf]%H_NRL$EqdHGYZ&TL-]
-%>8B\geBSXW2EGj.O'04]W-*G&Z;[cEgMQnGr`caoaAUt@U;a`F*U;:<"t*j#&-!W2=K9j<TW'si][cWZ6kicrS4VgPO@5N5n.3M7
-%Z`^<KJgo`fhJ$gYl5uf:UUD0EfUsF8==lIU>l3W1279i^/Z,tZPI6(4NgEXFah^S9:&]i/*tF$b%u@8t/LT:YA5u^GW"I2^JJQHG
-%28[m&F(qb;,,pYA>:<$?iTdr-56i9`I8M7*3(m^icWZe81,hToEboI4.sr#r4tqYiHpqd^[-OW6f<TDO8/3b^WaA.%O-]7\iV;_4
-%engo-bM"tB9P[t\44L:,j$p&7"dd8t[C8_+p=dNfd1gaX#5&=+d5)YZG@4i:91ABab&K%(02*W?C3dseRi?`p@m;#;A)n2p6n,.9
-%mROgp.Z:a^GG8Io3fSu'frX1Ym6;BO.p!,7JZ1-B;kL"t=e2I]]/h@@<*(BGWq.R9>$S>CN3K:a.,N&35iq5!A@7UoV.K*V@'q?1
-%+Snkn#`^%h!XV[I%E.*LUn)@FN<@83am,V.hR(ZL7i[d(4";gC.P7$+NOj(Qdcg`-Op&(-e'd8;LqhZ(UHNLCc]iK$"QOY_R]XCo
-%<b:VeNqE@6'(Ee:#kXrn[PR6\78mG'P;X_da-!R0MYGd9T4g^+&h)5;4u`"hNegbY7(f6=iYA!qYNUde746#(lA7G6'UT5]\r$UT
-%'m8#A9obs>H<JgMVDosrMGC*OF@*Zm)>2._88K7'-==S$q$N/'=)^RAJeR\i*0IG_KR<qJq8R9m=)^L?JrY5\ku#fk02('H'^$`K
-%_$ToE:<5A)7_U.OMf!<Kg'p':h2il8%6:0=O;$=W3MP>k'A<m5BfF%j,uI``5eA0[m910585Hk+NH<Nca9h6ge?k]!0A78gGUYai
-%TPuJ4hmU+R`.RD,/p1kU<$'ReH-hScU09mmTpDVj6B=/OoV`EiNuA^C]CHH14K>/sQ<-mi>".Q(g2rRKb+i,i[m"S)-QG0V7__hR
-%$JYDl!Z&])CELq:Yg#p3oE:]FXMDlU,>JM(ieW+0:'`i=OFSQN#WSP'@$ZjA?^dI7,MWDAEC.I'T[pS`[2:Xc-JFStb`(=k1)/L.
-%C2+:4:dIdqXs#A)<s>#M"jS/WSiqli,2nn&&rnstiKt8kNp0(oc;C%"KO`d_*-4H`0df(CDFTjIMi_duXU^J$L:*u'lc9]O2<(V[
-%'.2"[`)T6jX$A!XXt!Zb3UV]lj%cO5mZ<mt:8g1UULjlk<%cEic#IW9N]Wrs\=/k_n<W+Nf*Z'd=j[3toWDaO]rO'Y%l?T#!J(J[
-%qW>Z_DY5[,7/gEfZ,$4p`.,Oj5<W_fMuG4]F82;SogK?ChtQ/TiD;>d8pLX9TBYCXY[)W@Rr&kq>>HEuDd*IUopq2sRmo3ceRJ2*
-%20qj6*b5.=QY/8H?6%tE:k._$VD>dRAHqhQK\"iVmUo;`$>\\lJU:G-bFY?e]H<3fr5%N0ZuD@9^#(8M2UhKB@c]Wq,jm.l]rh7H
-%OXDmjY?u,eHq_F1&+=c<8$fs3cYSXp:(C'`PPmm`pFb\#'Sha3gVWa]0ndR<:bD*Hp):%&/2A-NWU00)#"QA]c[,<`r$mo`*XFF`
-%"5u/#?Ydpoq-<1[Kf+tjOahS.g+EPLiqhMY4ubX:ai'h/*aG;h_al0l]iXqkg/TBXc*p2l+]COlcLelBhYX4LSWd2?GknU+*_5eW
-%O;M1B*St[5ek'9n<3?u7;fAeBrGo0,NGXTSLrMtIn&*'53'F78V;"0D$%^EeC7VZ^\^i$'SDK.,__5rpWjTAPFm&[hOkm';F_gG,
-%p+_"&9m20JZ_Y+=J)p;m-K=)+NTN,2gmKFJd-`9qe">h/^H^6?530,B5*''rT<Hn<*lVK]WT2SQZd[P!M_h2.e;Lci=SMI/_sVWu
-%m2Jh(c^<O&=a5t.MQ'<NV_6;+A,AAr1=t`FYI<st@!<OZ5B#qH*VN0.Mm&8NRo/V_GO"b_\d]C\VhZUi`n&]GA,i,lV[ou)@f)n:
-%l4hKSouOi4'i*VcXLX(G8n-=m=2i5Yl9"E5fZ_hQg-*+g5L9&LT[PaER!r+b&)jFXi('=B[LK$S(<Y'#b8VD3:8?59gPFCZb6-S7
-%NF+jR<SX^]e&,???<e;6S\?/X?^l1A=qCMYcaZo?a"Z+NpWI+7UNOiLoIB%]s'G/dYr^]5pJUmi:0eo78t-'HLR7?2N]]FWMTO3K
-%Zd[H6-bb&c(GAp^L5IW;7GK?5(]@TKCS%`GH-WM?>3KYsrKc:(;(/cuo#2\mSYBH[!`.FV&*R7?!^>EA+'_5-a8ua'kHCVWe&U:k
-%=ZdflVn7[Y9<DXh\e[PP6/@7sqRN1\4k<:fNNL17R`/@7:@k1Nc'P6/;jW8_Hi0Eqr#B'K1HV_72o;G_T!g--O@c?GJPbIQO*EF,
-%Y,A,I`RCU>a6`GAA'cst[.850?Is=WHBGd%$Jh;6G1iFXKfqB6_qdJ!Vk]GUdnXi=N`N&1O4dbk6[&d5H$6+Kqh;N2X-XW7V_=BD
-%a1>#c0=9K[LM4#-dckfsoJ5Y7fUZ>rNr#*a7$uZlgMpVO:8QWKa.CG>gSE;RRo#g55@J`(\-T1I%poAAe7gmu4%3%@iC^Gcp`&V-
-%*qnn0NW8OM[Y['\2thYGm7bhmn!g9bFLn[A'K,a_mIEeA5IR>"Kp/3SO*3QIf[A$orEO^?P>8Fp_QfC=DN?/(qekWi:o!\\Y&kYF
-%k.3&[=CGo$7QN[D:'3PF\ikpU&4mOA:ZY?ZSZW(XYLNm)D,rmQEMbUXkVjI3FZPA.VPp:N86lCAbI]fO]iU%aD:RKP3pe+p](*KE
-%;p'=?f7tlMIr"cN,?0!`bZJ4$k=;U4mkq)(p;";*UO#Z#ZPD)?N?s6:C#"oUK`:;qA+e^?1&W.H+/b])^F$nDlZ_s(+19]0jf<:<
-%@VZk/qq*U)IC;!m&C%u@0AC3l=1i"I[EI)i]jt#&;=^#rD^OO\HfI2eC\q_E.k.B5@5Xn]>!JtpU_RBe^Wg\FND71EH0RJ/o<6L9
-%e=Q6]Y[['mfD)pkmE]Kl<&4FKFXq(-=C:<MotQC]Y@b2iFKa+ie#t-.AH1NYCL^2ES=-RJfBk_MhDG17aILjdVI*-;K2oa8`A2=N
-%h4HI%*A)sPH^iHR;nfX,lW3[nE^7D%K"LkX=fT1XD._;T,MUhc;Qbg9QO@Wl@ai`j9<Rk`Ki#q9hL;c;%[;,!UUL%c,@t?X:!fk%
-%]PZP*1=`Df%Pt(Xot2.keAb:UXmC"IU&"(q"*;#;ODnQ7B'.r49agCVr:QV-qt@GWhL96@h7b9:%/s9s,l!XG#>X0N+SYP@iBnu6
-%'s8h/\8tlq4ro*kf&OmGDI?Cb96TDiUA-WpXrXB0_J9'\CFq#1c.gPQo<3s@f932o`a3pThqBW+n;8Ma@*h#-lc:]8bCR'dj=%L0
-%auqm9jcCe6/r@fVqYKlOD2Us*p?]AGf&c+@iL:4\`T#MK(S5Z"E;GQ(/k@;'m%2fg=p0uEi0qj/EBVs:9!7iF\b8U(kPV+j8,q@L
-%bJYKL@1]Pi,TPRNKM"QEZ'VG%#0"q\1pT]/#5fO`>)nJtfT!!s7$'T5G\hc:GIi-DJ*\n5<[-OH,OQSq+uko,Ic'p'>N5At4SA%F
-%(\,7JIEZkZX2S7=2a#[L6H.F012Ch]O+'#3(\r:0iB=hn%IRmmVUh!ULNdjJp1V']M3<Tm%"go(-4TF4CMPRuDgBp::q.ssK?L#r
-%.be=rW/7R1SaKZr>LUF>Y*R(*WdtEpdFWcXRLd;t,;?N2AZ!?<N=\oI79\S"S-pe%nootuA)9tC]s$gH.lEh4T[OKZR#j9hr5a:S
-%hXDADU:EM2(E2CM9_'TTAqe5ll^n#$EUhNUEH;Y)9#XpdT"_ce_hu]V7/?^;r!aP&?cce7md72emN>NG)_\8+8=S9cCnT0V2IV8)
-%4Ql[*Y;r;Z)QeXS>'rZWe'$OJm=ART>0U#mmW#Ln\DEq(?8TC*p<2;9'kKSfLb@)$1JcM41p62j7k=$OIipe^6VWhUeEk#9/8kid
-%7NS'.7I;r&g1be2ImD>Zp[<,p-!3$Wqo2'd]g(ED%"kU99;[>_H*kKDZle.XBC.C$@]C\p5qSZRbZ^NVmfrXKRS9&mDD]gbH,tZ$
-%H$-R&h:Pi[%1[&fOkhuHpOS,^E0/WVf86&+2>/r5T00\6,Kn2eU_s)l\8`'@L7oU1NEo,gY8fpKTCQA4h9J#dQ\Vgb6X_eJ=UYVY
-%kiZCLn.Bb%YE'TlePHqHWlH@_&_Wrb&j$LY<tD;)nYD2R.33AQ(--6O"ap;]/Kj_J-qhXpJ4NIbjBTJp(WZ=lMV6&2aW_,VngHUp
-%k%N?^*:70]UgN0/kV["d`ea5UXE"?]F(EC[V):7oog7!VbhXp7?VY#^Rb`j]G*6Fm?<K(/9oHJu<dX2h&!^o(H!$f(amQnZ_X$I8
-%1X07.D(t^a<=X?:I:95060d`_)(V$117f;G^%;qdBJq_e'ASuc8^$qs"r3YL8;d'i%1:di%ng''O>8*GN__m<iRXTp7*)If`-fOc
-%dJII\@U=ahe`R`109$m,I!R:YVme:-gWtSG7i(LB.M%r*U0Tq@(?s?fUW!=BiKS-0<'o_08Mh_<O$jX.]4#^IHjR7HVcd\ZB0g4*
-%[X'R[Of='ZP_l0Hdj'.t,Gjcqe[ogM<.4a^K&"[9GOiT9Rr'JL!;DEj],>YqFUg#okCQmMT3/S$+[`8B=_LrFM5cWWlnp`F(2`\%
-%QcEfu8N2uR\Q@Zf9//6&4Tb*OM5=bG0e[YGo!,XYI7^RpHXDpoqNg`$8W8KO[8UeT#fV^Zc8Kq+/fI5,]XE+(WOLTc-utY"D>2HF
-%E&ks8g?dQ*T.T29.>?LP7Z"O;E;++QQo7UZVnnOm,ker0^PAYeg[H<NV5+\8$pf,J+UG"C>fNTk#-l`l/dP)Y2:c$?2cVb@*\i$A
-%TiX<YbFt:Cm+n9TkcIEfI`-PT8l*ogFm]tHbtM:qLA=MDb^o;#]j_MQhIWe@rkt&okg#*&:U)d!6juSNJb($>Ch,@NLGlI6O<-l9
-%81r6*lX\.>PTdRs#PH*3c"QM1'2tI:;du]UejKZU?V,#dT!"nZGC>nSX#l,Nlt')@k!%e$;?$4[4"FUgi(cLt6d:To_4_I$@tg:j
-%s(*s)`W3*AcHg"V?K"gCcg[aH9l6+-l;Q].HnSEZhJ>-AY0P+SFahSgNFqkce"(An(q^36lioj#gp$"+6kGb`k]r>:((YfgW?_+%
-%k$km9*sTW;_hFuLnL@8tf[Pa9mfLW=Ls+i:Lg)F'[0o^f@hocrcopg@FcQX`6uUAD?KO2`:O$/Y/fRk^GWk.m?eC'%Dr7?+K6l4p
-%C6?hrej!$W2NhPC:,FcCF2I60ZX9uuGKA&A@-^-HV\1=hm6p"-=2C!8X<C0?E;Y/J1aL*o1m]7"+:fseghj.cQ)OBemu,"u0Vp>/
-%5E5r<>cKCg%oVL<^-on@Lb9uQ"F#2"P[<;?:"`fj+UVI1>(#qO?Uq$&*\OIRn_/8e`Ksa$PfHi7IjckqAG6UP;Ehh.np<)-0O$:3
-%Z;uo-LY7,L]@1qBj'eN;hB>`HM%$DtnU8/3"$f6%T/C]c@^f*%Hf(@QPoD657]k?0[o(qL;AS$Ic+L:_!a86dB^#1*k6Dg\,F_uO
-%*L6LgiFR&JH^S@jLN<1X258]`(:gjT_VT:*?!(ESj"[:rpSJoTFP33l=LR_8D=r:=AKs;T#3GS2j6d9'L;B43/.:Y=$0LF7#a=ks
-%4N+I`I\W;o2i[V8bEKYbnb'A5HlB*Bh8eijL!/li,)80HSHD0%?Y*M%WGm7I(JZ;&:`8c.9UE1V':)3n[(7bE)'NimP/n'@#3_P*
-%7GH2n9HekHdN8iq"j:I!rG[7mn4c.?OMJC!/<3;LgoaAi!#1.-f!<Z&4RCNYq6IOQFEokAe'0)grG#OF#.8%7E6c@!+P(.oq]=F.
-%I^3U,@JOq*>klTO7:TOk?DDSDBJ5B_q'IX3a"7fl-iq5-JQ:3*)f'U=$)[)MA:TN_+br6$Nt)*L\YSB*B\E+&rU#cC#gaD/7IQV9
-%SAOmh)HWFAa0Jhe1&Om-Qo9nP7'?@M,?/`BK^e1a;>)"_J]9Ze/mSnOh,GpmMf[]3BP<>NQ4XMZ1)J-AeMA7nJN'V#rb`=QXQ;.Q
-%Wj#a5r;;Pn1;q'iogH%K>ZcuQN_jdIC.k(@F,FNdIU=-q?qFh<[X'!"Ne[bY_H&5"4FDqQq0N^YXJ`>=d`!t0F4j%ncRY==`emlA
-%H$&R]^m0/T-').tK6snbK5F>$Fr95g/6_TCSe9XoY`cXGiCKgcoPM6_\UVA1\c4SMQMY:n.WqfoCj0]PQ8lelkq.6d9AFoYNK+QK
-%b&MEY8OWNcBAYhseR_;>U\4J?g&$P`RFgnYfB]?(MlG=35-aeW=bMsDIH-tg/16Z]iu^Vro<l/'[iu`&PhY3XE@[aq:2Tcj,%&Qs
-%E7FOW^b:hpoeGiWF5.CIKIF[jm6Ifn)[4uifKou@VPbERg#j/UMGB:.F^MWH1R7A)@HMl45KsBF_b4R+ABo+^02%gWgk!;l)ka):
-%mQ`,sl40=0$PYRKP'h4eIsb;UO!+@$"K6GQj/jJW`,;ICeSi&^KuVq7"6NJ]9]e^V<nT\fqSsn$Yc_mYo3[&K^emVk.M@8S\Pt-s
-%[O,Fd,%kD4TCq524`JJ-A0,!VoeDAfjdcra\Z8\t<R0^RPoS-,K)puJ;7Vq,e+7>E28D/;eRETTYM:M3B>[tNa\eG+`?TSkY?W3L
-%R>Vq`G!&?5:#oem%ciW)J"4XV$.M4HI/Bf!B30L$5[LfD!Y5Q_CH((a<lMtD%55/up)TVcgOl/kX9[qZ8A!:$6cdptm:!D;]6:G:
-%moetOW=092DV2jBnU[@:mPtK,BWQ1CFMtGl)W8C+g0Ls;at=201jV:=gf(NT2ulG:]$n/f3RZab*ZO8]En%(?7e`7k>cDMtm/A\=
-%o[N(A5l/D'UWVP5GBsd:h\<LWS&*=FE,^S]S#tri/DYH-bk\Ms/C)6nRYtV`R-X31UC$*]oCgFV+F/]Ja)\h/>&/6`21T,"#"0[@
-%.bG^uWc=quZTlM"jM;_bQn^Re*i`[(49JuL)[erWZG&c&a^pM?2S21(Dn,Ts]Y)]Nl@eMK9A\JAo"e69e'l6>>(DpJ(+)4F]OdZN
-%RA*[dXWYg8Ksj^g-2.IE#EPqG`]6oRL:]\l,aT82RgY9dZ%*HW,PrZFJf_?*AfRqgBrNl>R"60#fX>;6S@DnE6"><nb3P]d/Qr@E
-%l(W%^*4fes+*aklSVNB9@Y(pu+e^3G;0?4-KH9[&Cq-tZ[:is9KR6.?ijsEu)3Q^H_V1buk?W_Vg"nq9CKQQdk',k:`M(uL/[A,)
-%1PURD8(L*2g=>O.7IlJm>bole"u)DXc].paYK4TJ/EgTHJR)t/kJH=jB&'A:[XEu1KJ&>5;qO4l6h'T_,[&tF?&N`5>d3uJ(;>l%
-%@h)\Lb1<>pkOS,OaJE*U:B@:p##G4jRR7qfbmW@A)!0(qqnbTQ0"<QH.dI05_NtRbjU>aJXl8-QE,Du_=rDQ?i0CjW9MWsW)S'Ku
-%M`EaR[W!SY[<;WMk(6huaE*'$OtSPOSRJ\\r/r1mmXL]4_U=s/\X<\O]$HYE92Y*0FO2IFP=$-T?t$HGi)OV3*76CIM0ADA^:mh"
-%;e]"eflY1C*#d.8.u*)kQa1)/X@J:MOn:@a@[QXVC%dWf2KHpMNGLX$h1_LN\s?is\6tIVYCcG?C]bq"p9eV;)n9K8"O1n1AF)Xr
-%7r94]Jb1ZtR[]X87uo[72o<g:UL<QVDf4so`#L'"Xg^@EH/X"'a1#KA=fZ#6bp4BGd8%rk1U>P.2r`$1a-0q_GIe+e7.D`XZ5XlD
-%*[$f)8YIIie&V'jcq5eVW"HCQYeTSe,25Nn]`@?P4p-G$"k4W5PK]6g$cqErF'2?K$_8`:9[%U>'2o_$>b58teao6R?7FV8Hh[Cb
-%98'BCV!so<9G>XZYd"W/'3[,'J1QTnj,^gV6UETgqW@<L!>=,/KuP3M%>-Es6+%bs0&$[@aoOQP%\"o;bcoL1)f<chO77UVJa&>8
-%hZ+;3jmD'=ml=t9^<HnW'tCT,\i^sU*bmF45A6'T+m=*!FLi/S_Pti:YfM]I\AH"3Y[&;3GkNmj+h0WgW-M1.!=<TU`lQ6V@^f*R
-%KRb6Ueg(gnFGZt.Zo;$9B/N=MM#jVt*aIhj18%6lS:Esg'X!Z8E+q#RMJ6<M1N/=;9XNS^;Dqob[_pd=Q4;)M.>!n:Qd*AfNOdOi
-%5n,Mc_\K`\&SC-Z_H:`/R6<LW)p)E&nL[-)Oqpcp5HJong"h'Ap.M#,Sg`+\md]92pbNJ/[`igPkYX6C)$l[;OWPjBc95iu?q2g>
-%?=^'+W-)jR@h`JWqj=5IVuWh%*u=1pWsq"TMb3OCLe1o\^C:MdHf49h3BM5G"5<EAc^7BX$]aRLJ:oi9[EOoD$'oG%Ub.HUL>g;[
-%&*I1K"jmNAlS6RO?oPhP7gVd=j9nB./-jLXC!>PTYs$tIbdW=F12hI#9Vl&bqTAe$$Xc;Es)sO?*>YN:j\MH]B7.gb["[Cd!<^si
-%W8]([+?*s*%MPAWn0lSmCj@(5K-TXcdtTHGb&VrOKIR0F0-`Ci6$b=BK$Lu1]ZKVUKW6%*P81sPOa^2GO3e^oZ-:]i/3eVG'$GGq
-%SR<p"*[X<8bh^^dEc(JDFm>otIfZg%a!$bZEiHm\nKnRLaeaaNbKCL@Lc2VLH#=-!"u#S*AJYU&HV'VQnR=(S/-G$='$KF"_t/as
-%-([aAbGsC5?`mL[)_8O4.UVrm&WqY%k3b"X8ofI[PQ8OBk,UoYaSh?af7h3lpX'hmGgafVi]ch9#BP`fptOHN%:X43S"08<0BaDM
-%BkP+Ga:M.CX*'p_plh*P$gJCHY9-#4*I7U"hG!taCX^RWAKOOEo8NkEgR,3QN_iV2=k"flcT_*-m-Jfd$*RR\`KRM+[QD2o\cUpF
-%cecDsb]dL,G-ZF2jgfC[[LhhIq"aa)QGOO5@oqX5p$f2OmDVlu]3D!,/)sGKc>W\1[I8E)%[cJf@&D9*JOJFUq,$`r2&"G%<3:ME
-%)LUR0n5-O\R;*?D[If6SFlcl"+*jegpIr!f>ipL6g2nr?IAg?D9Js*MQMs^g%`jQSq2'm,Fb>><ncKD&ldjACq2pH4Fb:nso$SV[
-%eicq`kO)I?6e+5V11[-SJVU7JcVuuO*S\CteV;\\J)m;<h/s.Ngp6:%WccWe_hp&8:c0We(*g>Us%p+@E5i\'\3\JHckg.4o";k%
-%a$\Cgn9lmoIVB<m;\6=sTNMbZfC2To?bGKp%oqp,\#/\*M`k%a5c/Kb<6YkTB&r;^"Q[iG4KaaS>kk"-?9C";6e0s"-ofHa?l`Bb
-%#0nPXGp.Dj#<7(Uf,<*-C^tNN,Au9HT'\4LHs%7J7WA(V/*87q`?IN200G_68:Z%m`ncY4387;R;`6b-_fZ@BE^=rY[F<8,Q0&dP
-%c#J'S?^0]-B6,7=(PHF:V#_7"D2c)G%+"&9B<,D<RhMC<!R<UB=RkE<3Pa=n?7fg,ZT2pf/74Y(K4f7aOIZ9'i7T+.CnhL#(nStQ
-%c??cPI#lK4fb[D.[Zc--+.g^Xc<ep,lo*d<-$.8bn8+,]UpgYg^p>&q?oTMrRff2*JZa-_2iS!df&9r%O>i.&cF0N'5'Su@D'7_=
-%bR`$S5A\-gRMB%=DDM_]Ha+;A5,1"(ME*Q-c#f<ViRsYCZ-emRkZTbLA`RX8)\NgRi!c4%!R>k?XLGd6ZNb&Xhg)\]B5;/6Ee_68
-%Hd?.=DeH+!f`oUAoldbmlr81iCj8+4CThR3cF/(NI5u4Yj4GDCTj56KBBu>AX^9=[%W!-2`T$Q,k;[5-gY);R)j^#;[P:j]"ch:[
-%f23<FrAOLWIQ`SmFF!$=lWGd3!?#P5kI4KJS05hrj8,'u)!?\p?34TkJ/%tp`;"qf13"MX\Q3NTi#9j`Jhc:MLDZWgc/BWsDM>0!
-%*b$+8OYGf[LDY5\oN.;BJJdR/*aB72mP$HLS;;16h-VX@HoW]hLD]3&-$(fZ\D#g>3Q1\ZaEhaB3"O;DEQ#A$m-%=Zj*%]&b<_(s
-%<#W`7ru>M'EqboT(jBtiho-2f$8)X%pQ$K;kJef.6B#,]U0&1?SC6%Fo<g7`j#/a&,fD\9NUPQ:72A=N0DK-B-XtkBB^mG]j!oo0
-%Ju1++0s:22r"NUFKsJ8b3Q*n4A[)BV\:YT<(I3rFYmEXI(geiK4>1069>2s9(t[3'nMXV?".9ZSY1I'2"u-UZ/+oZj5D'g9bLs9O
-%@bd[U1+-NNEi5D2od(g%+ZGYb%V>HlEG'1sc\iWQ7,7_@@XL0mAjhTa@n4cT7>r#F5`G$8C&JHLggtSUrW$D4040/41!]Z.rF1S&
-%LUkps7#WpC6S0<5^'"rQ#@^s0@a:#X`YgVAFKtcAc$TP&l%j?1$R!V_N3b970-;odpYP4V&EAf4r`k8!$b=#?`&Pk`E'NMi_5>th
-%F+`saieo&$j`jG$GJ`MP^=E(DIgRpUrIWupLiHANpeh^aMLV_QaMknF`43M"[g^3bmR=Q+6B%CH2dIb>*.-Z>T=F&GqZatuoB\+<
-%1!W,:=3V?;o:a&:Cq.[[F6IS>*:1jETu.UqZ-2`[k]#ju/.3K$_'Ass3daST&<ljNIg-pr@)H!/]QA8*1,p`C_,$`A'l:B+Z@5)]
-%\,fb4,Ns)XE$i[&V4b_kfh3t8rWG8el',d@q@RhZJdnX3`K-\0'l:C>?+CM-h!Cm+jeBX-Cq'oqGp.:>dAQUMk\tm]fJ:h4g7-$Q
-%6AO=.@(7J(\?Zp>=G8&r_bGOq91=UdfPnkCh%%fjHkG1mU;PLnh*6Z)B37_iJ.B'-=\*>;&3=(4L@b3:k!b'ONT$GWoJEt<Q[fQI
-%[L'^ar^5o=q,,K0"gb0!^b6WIY2&"frgl*I+6LVjiJP=l>d5TK_j/^:o)'Ig>bOTgVR0TM\:P06H%$5DY+.NZ1\)4CE.oKXYEggV
-%*Nk2.h)ciS7>EC(8:7X+K+:u:e)sS5-9>DJL>,*a/;+Kll7bGR%X5K;o:a((p18O5E!71u\9hL*3aC>X#0LOlk]#Vpb4toW5_gj_
-%a[C,$#p$2"@=A\,^=7NHU%VXMflAOlYK9F9=5P5Y![RUodn:c;HiM69!7^.b>VhS=;fW$%21NlHjOgnR.T:#0?cIm-VG["=^4pjC
-%ja4i+<+bU6of&E-(#t4Wk`d&Q3NZ>@O/(C3fNW<GS6_S_=W?k1W(r@=fn:T<%S>h`5_F+R`inWg6sJuBGF^_\F;Ngl2h9NCYgZ<h
-%I[I/ZH=mgOrP4aA]0'\orpa7X0.^F</f7u0$b_sEA5!tL3)aX2_-dtHM'\]NDBbHEMd313bRDm79#mI5([lH)N)nA903DF<*S&5W
-%hD`aupb\K)![?/-]Y9UHm4%H<Yh+U0pVdnED.Z\!h'.p"gP:N/>YZ[o5IImHkh>:lQ'f9?2!LAW7,dh"L^.t>l\"Ss3-sH+9Xp]G
-%rRJZHjh>DYGf7UBOBhaJV8R_Q:aFZPIS7IO0BnJG'--JSN4<ji-pu.@H.GPq!*iVI>8Ir<f<&:O=tG^:YZpmq3mF.=QU[mSgk0b\
-%G+)`3KF_t/ei:+[AP5+a/$<OPq(kd@(3pE/LR7OqR;mO:kjtBq8LrpM7ahEl9fuLT$bu#*%#MsBWN:1Ga`i\A27]iD61NbMEJ4LX
-%(YBOM6H0G*1"rqS&V7d'NaLMJ5Y]hd[Z&f'>d'f$X<k$,O)Y7Yd&s7UiV[fl/HHb)hNrDf:G6uhh"Fp,GM,[.0$?UkqfoU1C_<tS
-%1_>Ck.B44SX`#kR`cuBH*'CN-ELnq;d$XXrS.n(l)-E\nph\X%rlVK/]FIulTCZi7M_&Kp`_?[h;na)-Z:o"kOV[cAlEFK'@T,3A
-%d63i:7,,OcgLYqDBWUlIc3>22O\'qTZd57a@.M:[Qolu2Pm><2k';67,HJiOE(S^3btNGI40O7\j5#a&*ganO\%WPm.``FAXY7S"
-%_2Dk1O>,OLEPs!`Qd*<)=[5!6EhgOEVZX'\VJ395:jC:MNC%+rGlC>QJ0u;=Z'i5dikQ7L+V>a-R"Gh*,t98u#fGG;(Nu`pH`S+J
-%qoB`6gPZn'Wm&JnV1g=+e@OB2@/Zh,*A67Aq8G@-CtgA(=Y<S[91GHiN3pZK!TGZb>oBE0NXj:Oo%e?)Z6EYI^R$43CTI2UY9oaV
-%n3]^"<Lu<'`k4I3@_&pNkOH*e85mQ;T"gU;Q><PagVu=h\IRL;Y?87+OH:j%(DP&U#)dKeb7Vp2Yo'EPrRHQgZ$aS8Q9i-eLB96M
-%Eltk..[JHfDi?V"$]*nkHa1fj15hS<hT!#$B>C^_bY9#ogru#p`eiK#)_Y4ZVgM>HnWmG$l[a?HN&`HZHO'9UZ6aD"anC`+*os?p
-%liVjq)=;BirSH>^i\O<P;J/*Y0TXg]SkC^"/1R&8iBm8;_sQgHCAS9A^os6;(%jRe\D<%DQm>TsF)g8hH/NlsR]p#Pfrn2],r-Qa
-%I7NjgEjo^+[[<aW7aI>eZ1YomkLU%mjn2MuZ#pfgRZ";78]NqV)!,7L)N6U/R/Pj:G"hdCh3].'9=t2%^CaN:XBMRk2#<V+,;@>0
-%Ha@da%)?.[H`^BU:?C*hF)fZU.5@/Y`g^n-r'KQ<mdX!-Bbg'-SfrO@pBt#1N7=$J()5(IZb;#raBdS,[>MSMk9-5NSZh7l&i5=#
-%fiOeV%*61(1lBXhq(Q*fRK5I\PR+e4Zbg#AcE0678;G;G;RL,1nQmW)a5SB)hX$3)Fon8"2gffjbsZ&GPE4apiN0IbC*f%4#>aZH
-%X7##Ihjl3&n#S^c`_u,f]=#<7CJ[%GBRPg@Z-(bo>PtOIeiEYS^\Bd*<K]q?kMj&EI9R:QVsVXI<O[0nZu\FCI67#shVN9Wrm-A`
-%k@ME@Q#;Yk*Y5/Y:W9dt*f&A'X2EM-`tMYV8GaLT)RiqmX`ND!pNlij-,*aTAO=#@X5i_9WpJSi3BDA0gg]u_\!:i!%R\4^_1&=b
-%]dnhteqP!7UW\RVn[NoW(sbD>2^TKu(\M22/=FX[eiF`e5`Y"$>R89o]Ut&U61-SaMdL=0n2?_L[>MuNC2Q>S"d_`GEe2%J/J9]2
-%]=k"eWu&<um_]CrVSq3.e_tD='VW&Cr#=>XC\B7PKLk4bB)R((3/CkMmk.AECmJc.*aIUpHLAuBM0(E:.9DO)2Vot)HUtV>HI$)7
-%?<MKL\l1fnLjX>\D^TK/_i#V6?XA*T';#e!4C!RI\+-rtUiWgW'!InY1@^^K<rTUYE.=5n^$P%^pkV;/Ii#O,PG$*_/>$0ijn#N:
-%(8^bGc?LmHc5#jj&pr*`gdg`%!U\Fu21tV^:=I?!^3$4?=BVK3GU^qngE3'^OQrRuhEJ]dGP_HL<QK3#!e7$%JP<T?%d\FI@@QuH
-%J\fmCH`I`P_I>nhf@B$nQ`!XjV;o)Qpg#l/"E\)ps"3&Q/UnoBHfmc&>2)3q/[\sVXmpWtdiY/Ud&cZLiO<DRQZ]JQI]d7.\Sc7S
-%#_aVohL,:mm37bH*Y#Rc\+_1:A#FPFX/O(@G?FiSnZC<r%LK=SSo"Gt,uMltB!oP(7&UbdCHpD&/i4J^Rtp6l06HPV:T)iY$Al+R
-%g>R:Y3R.gA]o.uViU:;,NK%*'C,9jfH5R3FB:u3+`u[t\Vh_7pgh5S/d$YsC*^i-dm+H4Xjq9>]^KljTebl1uLjaV'h[Ve7;NIW(
-%B+"Zd5MV7/a)EI)no+J4s5@,"jiR3#)ZaX=#50g@rVB97Z<*Ie=>hqjH7JcGmm=`/Ge-;lG`NuAC/1InLOB!\/tVGNp;50#^(#,G
-%5+W\!eG3/?$0^:]%il6`humqBcYjIcp\&a7pu[&eND2pHA[GMDgLr!QhpM(5<(F:+O(>7<Z`V.;R2`HsDQ`(s:J5\,G:eX*O]q9l
-%8=Peb_o*qA>V#;sjq<L\r0RV_?+p!n4p&dLdTY!2=*D/OHTth*KC91Pq/+HZkURYqV_59]Vu6)TTi_%Ah%:aCZDF&,2sF,.4Ts^B
-%jf,ej'T,&n5+aU^mER]KhH>=Y1tKANjR2uc_Y8,O\EVo-MQN`C.tu":DEp#"$P@NM*FQpM1.!gaYOh'#6j_1La@23.gb%F/hBe'T
-%kbEr)l/A^G&H/)ujUg&#^(/'6SPSfPTbANBZ0'V:'0:P()CkbT<mk=E]7fnfD9:8WiHSDY5fE/2)[a2Y'D^SJ7ilSY]%p/cB<L##
-%*AicN8cIe!i^M:5mj05s[sH`[iS?GYXs%6KcpNcVI[[e]!Yr@.&4=kc?'5(3KsLC&iGJJS%^FNCZg?5[;+OlN2VPq3I\lgE3br:Z
-%F4l?Hl*:-:n=^LV_-(XKI"C\ZfYcCe+mS0s[Jl7PmVQ7jgV`PF@9hc5`LH6W?JVL5ZZ6OHpR*'scquM*PDef'B&`^8m`8H[^ACiS
-%\8JpS,CJ5C.Vs5LVeF'#EgL^!6,f9kZnD[MW9rUGS/:tsr3H';>1gr@!krt-&W6mPq1n5n>.43)8=ZP5ag.gcT0C@TmYV75UN5o'
-%p*#'QWG2Q_He,Kj8mqT[GJ6#W;1?nPRq/_*/oS%T_<_p*94H7n%N"D3pRmqF#%InCqkIET3\mNWE;Ir)2=J!Bo'NL")mJ7i@R1j7
-%kI56a\(DIC%-2VI]A?M"Y]5:b(A6cnPCj-H4*Ms,eY#`@4I[,D[Vo*;`a5X>&Qlb+na$aJAi]ti#<E9gmq)6pjFfWGk!%e&e40ld
-%%Ir[l'kC]-G-dOXAT#0FG?b8+M;1CVPAJQDXl_[8M&VHO49:(-'H5ACJ,Ha!G,.;Tn_:+B.f,oI/++HA*FWQ7InO'hdbRms2:4l8
-%"<TdgW;CtC4+'*[*'JcelIA4#Baf!glqQi\2S-ks%A[.K\*j3'])2!7HhL+fF%]u<ZiS9URb;$:H4/Cl07NOt_2B^*;CMBF#;;M(
-%a5nYU^m#ASc_j+3(/=3EO2W8Fg%3YZ(XeMf7t%0tpg:5q_<Zi3^M@u]*:W3Z>j%mYL32b**^c8gWSHKh7BIcbHF&'f*qg\]QdZj6
-%qrq/(1E[IcnRU9)^7WY.PW/^*2nEGphgM#n"t>T&NKeW87Z_*WI=&I[h99d`UQJjS\)!7cS]U'qI5jI5cYDQ77*3R7hE`m,Ibi5]
-%S?/![MA<l8XI^6ccb4>`YTIG.g-Z369q2q:O*atg?6^o-4,3@[KcN-B\j/66I2?kZX2Jee*`"`_"1jYLXj's0[eEoh0%9uYa-:/$
-%G,gtRd-)GTNVjQ]ottpZkMK:0.0etr6<rG4LD=!7as0*SpU@mV=P_U=]GH>qp9$f(\C8`&VP@;Vo[0;H`2EJ!HLUT4W-^J\8penC
-%4"N'@Qf%d3p2[V#"(kTV[pN4O8o*$K8F&WJrqR$:"+:u6-_ET00Z+H=Cj(MdH5Xiem2Z4Eq*&OE.3\uK=[QGAirnc<[hgJK&&-81
-%DmWY\I!mB)rf[XR='[AMcr&GEKH*DU_c9AX35Nt5s)+lq(C!YP>Cl9/;@oI2iTN-)J=",fZ&n_#Fli8b.A>JgTco,O2NCb3eW4Mh
-%Q!Ynt;Z6cdKe55uid*J'Fj^'06oqZ/Q38=;5[p*FfmHsn%CASSXfmjU;B$B9)0pS?G'S8?+7mgtr,umL-2\:VGOLDQmn:,dYFNlF
-%>A$7kj^p[Oe*MFkptT-Ci8'1G"N1;g;ksJ%\s'g:j#Pr,nTV=!n's/S(@/"D/,eRIC26%_>KXX/AN04_pXs'HD>MXA9GK]Jq84[k
-%.51ROLHNR;cU]-><G=81p5-bHq;+"AK5douZ0CLpYP?]'EPmYKdcF.XI2\4@GC,.QO3Xhol)1tdlpmU>;mX<[BTQ]+`3Xeu\4smW
-%g1+cs5hLmQZX;tQ!&55"3H'Or$q5Y>HolKnM>m9^eE%!`2\2"UfhNOn7q\m]:cgVXM>@.eZ1p*I`PqSr^gT3$fIc;:E`Z3%;Go&4
-%j_3X:86t;"SrjMl]-HX[]6MWCcZ,VDmAK5ub/LcT0`,Vhs%^&[3C0R9'o%Z.d9L#1md.UeRh_"XY)m)n)8D!V$6@`,nSP_g6ot?P
-%Wpn[5FDt=7hK(HKdcJt>)YQ^Tf0BD7Yn1os[R1q5Q)hn%f#EF)FYN0m/6GR@Q@#tJ$;0@J[X)1G]5cAQh(Qnm&@(,p#B;LbH8C^T
-%Lc7c@T2mIumhD7!H0ga\)FY[\ls.4>[Q\">J^)&_Cko=0r[:%AWabk<<MqL(X\%.qe(k,SPKWdfeY<);N&8gb?luHCE9&e40KB9j
-%0U1mP`cdH0I5b(^p=O&4`oFae=7IO'q0M9XU?%@3n2mt"GdtBACsl"'fM;U+ii^ek2Y;3o8jX:gJ#oF!(QlVb`E+gA=WV^JHCaU>
-%He1FR:"8l0ZZ?;A/#c%o?g.914".Yq9\'>B@ob74gWjoNWP0$)SLa,RF`m`BaE".:eh[Ks6CM\gY^9O"buI!WenT;^B;X_U%ShY3
-%>%sT9Y[U-Cl.=Kjns7cXM?BZk"bX'MYf1)9<qZE[lJV<P*K9+_c#9tdrn:^Jk%ObC"($]HBq0J\OP(3=VOrN`a6i[R1`kMmD!tot
-%;e6K37"]2u7cLNEg+KVq,$X."E84!0Mj^XF"In?A<$E44#pI:X'q'KVj5YakjqoYda%(B0pDSnRA./<3Xl?s[M(/^P]"L7U04pdY
-%2_p)nYNi/'NI;#b7HniY04sbaYe[D\4!YEpY1U9O*2YhLqMo@cB^e*iFQfCb-MlB]I89ue21uH\nJMYW`^KDU(dMI,1UIW>*UkP/
-%bUrQ>SRSaASHI3gK8O-fK6fPe(fGf\0ccG#K=X2S>7F11.YDaq,\2,?6UEW,*E8u)NEqt_C9h%0KG9`8]Y*W:(13\h6_&l\FV3oP
-%`Fd`\]A,pC(idH:3D))Z6B9HOfYcq;204%DH8K`Dc=M9P/F5=6d3jJgKUs=Zo3tfj7dn<nG(-X1'Z=7#0=up""lG$6>@"8YquebB
-%c*_BK:<_*SSI?u;3l"B`(A49Hkqh=blt,QicahN'e!-M0<3Z+*=TLBrZE.Scn"u#S[@?U5+WX;;X_]g9\5drO2_NErhGG->8[?>]
-%0@in9ZaJp_H5\"A5W^5J(Yq]N&#shp1!bqZjf-G`BM`a[$1Tb,6/bYgq:H9CqtplE#s3H7BHLp3+nak?[gr_L@F?SfO@UX5^Z')1
-%%uIY*RRF]d"*n:"cC]7B>edn+GFLJ$qb"??G=\h59QpGN1]>PO?P_tDJMK9L;U8q5_e2U)GkXphW]liCc)AU<#pmnd<%V%'W^njc
-%U3\PX;t%AH)YSkV2U#cKF0^9P(TYqA9UeIKZajSR":n:#UY%r.C::g+Y^/#eY%00/")EBk%fquB@<,TpqF[M8%ndiAG5TTu2?Us*
-%_5pd\0&Y/']#JpkNG"WX4M%FnnbrA!b@^)cf\O,1O&K];)s9baDT!iV?R_(n^KdrTb86$I7GHE&"f6"F%A[:FF^3V5RMft[m9G9k
-%g:i!K6ba)FiHh]m%O;)d;#J;G/J`9Of9[\?q`q!1T0@^dY2F4YD4]i=aNBM-NI4<Hbu3Eg>`r[eAu1mh2t%GM!A,'epUZn]p*q$Q
-%'N_UWhT?;A[\?e8Gi;-F=M,X]YGZE=dP^6tTSa!eYC'9e$?&,D&+pDkTNdRZ?%A19)h&2t11$<=[IW!lY7H!<mh5Gj2uS38gRYIP
-%HVn.TDWrcKV6q7:Lt*]>T"iWfZHW_I^p"V]bW0iJn_`r9-g`SV%p"CdYP<kOH;ipqQCO,Ds3HHORI2^&3&]3eNE@(Ng(P$.!oGV>
-%ScA="RH)"=aToMn;9XNuh[>E<V>FAk&9%kl2)-k!&47*&AkUZ37EMZHp\>"tDr=D<RuH/A-Sr9,g-sM`n)E0=f-f2sJhMcdf>2gO
-%0D0I,\JpX6:qrh7>sI$ZkrPiKHC2;<FgHY;X@"UF'&AJTdXLdJVn^L,?Jhb8Dm>KbnfE$QDPOHE(rsFm"0&h%c7(KhGHVW>r!5%8
-%4)m,<r!5$Ud-*D,@t(Dq!$"Hq%R38g,SR\F*))2TI$pj,js1/t;mP<jb97)V+gKr7b97)_RjfoFYT.*P%V*HsQ9u)Q0$0>:QkMj\
-%5re!Q#,LiP&JPX_W/18be!;jG@*[(C-r,kg/e.#E=7'ilEEK!<leT\7BrZt)\@1,3&M:e^+f7[Ac_\_XZDie\TaR?HCH4FIM7rd5
-%Q^7;@5enWF2nZ_+_pbfgZsr6;RGM<dPg6.@s5Xh:LOCSe5pp1D[D>.B0'_pKDn"pl%=.Nb^"QEY.piVqB0TPkikm:[We9^M6ROg+
-%_h9Df7BK28^bLu$B:j<l0P+Cf;jr?g\^Y:FXf:!)]0&d%L<$jUao2tI>Fmd4H4S@Ud9o8X3?2(rJD?o6rj8-e;6jOjf[>nl-5r)2
-%3/np/meN^DSgQb;8$D+n<_e1_>XGgi/r-#aU=</+K;g`INI>/jB57.hOR8Cu=24P,idW4^>NdcZ37T/=i#^ULSO+tj"u1%o>-cN&
-%R,K*a)sC_lQ:&(1*FY]8W*dndKJM(dr/p>=$"'Vc0+@UL7NQ$kLlI?4U=B%-8EfY5+usuj45cSP*C^Aq]$]hR#<-:.VA7@V1"80C
-%#2Z@(j:I+tX,L/JB:(dX^'[F9fjgaQhg$3*&6JDEmmd#oaTFr)Pm`S=+)uc&bt2t.Nn3W>)kN,EVVRSV^"K>KVR]p/+["H1rjTM*
-%8a^t#p%c>_UgLB^1Z9=U=S+RY5Q&g@H0'D!,SKak!Fi%_,'1-.l1?bR]Xi#+0sS=pil7&4Yp:J$_aO'L%^c6](,fYKd=3/rJ_Sti
-%:d7%eL>'AbD(,NtA$u+"HP[P[O(>bos#]!,m+rKrd?;-*T6Xq6^LBuW^6SR$?;:%EMr9mH4?Qu+l,pAl"T@Lq^9_t4b-gu%j6YBA
-%&gFX<,-f0j1IAEV+:5?c4[Vot=$7,d)o?h%8,-Z1c3%!>^'bemLm3PW.]V;?%7(IrU]VZ>i:&>UEZ_G"ID[RdKTEniA<Qr%>NY)o
-%`!Z$F)Is"QaFR<]'%#PpP<N9UQh%8`qi+#6Rk6Z+D<Q%al)@$?)^*;P2RJ#G`RX,B(Kk'@S.LZgeHtZZ85u*cZt?=BREACu'1qH+
-%&J<4D\c,&V1<YE*D;SZ'I)"tJ0(RD^qhT19?o6E.0@=m:)Ssb(VpQ"T\*OiB1lO4MWCYpMa.^thqZ?[UQ,V%qg-JQCqn\haG!$l?
-%N]1/h,l)Cp:QT8LdEaK(+I2$Nf_pK2&1LhY_>mmqlYS'B6:pV;@9hUCBY;HrYVf+hM5o``2]Fmj;hYJ9POk^*6Ej:YNF%.JY0`RG
-%Xl7[;1oNP1iEI&*8,\(BrJ-`ad)j[9FR((:%>MRbm5n5rJIpt.67%.U@IXmIqpUaRa@dMp`P=%^Y!/b?*H[FuH-Q&WSuJ#40k@$b
-%!MVk28ODL7n"'':e1T&*ZdV&u4q)eq-3ot[MQK8$e1Q3'J`cpKA,*PrabBJhq_\<^;5FSR@k>U(q!W7DGAD,I:$<&84!2B82K9%3
-%_/pC%I7-cD'-qLL8RoD%@X5WpW0\0/ZsiFcmPu3EFTGr>&tub\4:IeC54`I@NeFVq]U<bb&@k$&:s&&Ql7,4m)\uXD&H5ak)IkZO
-%FM*(L`_Z%b1_Lgk_n:tc]utjOd<PT--="rF*15,b91D-C0B#TQU;7C)]r=tO3.YJic#ClE%G!j\-&p34<#$s4WLgBn[L8e)3H[ef
-%j2pR]F._,g<8j=4Cd!R7cr3C^`HRNCkCK.OF<XW'LQH_/#B?qZ<nMlUN/MVNrfL#<$q109oSIq74,!7W;-;J"rBu,sl_D5NDT(dX
-%pn-aP"\_Oqkjn4@,GE*E>4+pm;X2#7kDgrIT0^R1P9csJC@CS4bL\$IUGRA;nP&ghr[PB)^M_^f*3YZ(Nh1[p+FK0\4MjrCZ:ho)
-%+Kl[29RAXuMN[ScoEk]^%noqjB0)Wsh]behTWd@n87tI!>@2`5XDXMA9VdK*8Rr_LSYi!!BSS4HUu[Z"6RC&chlnS6g_>JDlc)Vf
-%K"7fug[uS4f#$a@Gk-0JD[2jser9u+\RGo.MYk=OY/fqIe9uWP>Ib;`Gug-ZDsbP;kpeNe4qM^;nB$KLRuk/R29D24K/F8H+lp*1
-%LoZPgLUZ[9$lc_7lam[i"P$n(>n@+tl6s>8&>BL5GX&VpbF_Jr2Tbcjd6aH];"lX$4G8^h6H\Lt*`J=h;@"0m$8KqTUiu/>n]'6R
-%p8WLb7D)biiZO/>lde++$?mFUj1%npY:%)f5eEtUg3@kIp%?L<=I:Tg[aYZ%?)Dpsd)SIPQ4%\J>n7/&_`E[u<^MC[E\&2QU/>7%
-%??(W9!4K9CgFj@)fg'T0NV*]_j?HM'KQ%j&1%5`@W!]sHJrc=hok#f38ld%<pC&Q<0$hCL&7-3L&.!8S9aLFO:`"/lZ.4+j9GI$+
-%YnsHqU%V3%*t@]#9XdCZEOaLEAAA.%QmfU/[T\'j.W1u5MGZO"5),%d8Q!g/<VC"1rOq\MH1]X:\8c&qjUdcfA8<nFpXPt>fb5@Z
-%MC_RI&b]Pt*XdtcAdOaX(;lQbojTm:mN"Q;oQmst.W"79(Z%)bp3JM&(fU>D!5F>NL"a$%3UqOhi!`qBMhKffT8,tC2fA/S+=[9[
-%Pl#\TFNB;o>f+(n>0mE__O88T&r)6bL@S&FbWd-rKPdEN$+8)<0-K^3!5gCRK8!;-Q\Rpg=BIFGF$Wc)J5G6]S[(pgK>Bb"UPcUd
-%pUgSPpc')8jR6H`3[e1:fi(ko+2j9_;;)C$q9h5^%ZC<a;1r;/.LJ<HK^obakXK)7?u3$6foP#sDa%\u];9jNcZ1MmKi*J>qtA8[
-%]=HK8BcMmg$]SY5mf64jr7tUR7L&@4rW1?m'*!gTr!?0:G7$?c]nKQ#d;2BCc9TL-TS;e%5[Gjag]cQ@_.q3$.CAuZZ">Y=qGQls
-%^P)J-B')"2*T^W%;;F^,0eR\DZ<Z`;m<<JlOFVXn^l=V'[t\CtYnL*"$kcTJ_M.EA!.oN>dp(%-PFE0j-L39@[QZhS?N@#k-s5-)
-%2YIF95]ZSUS">tmA*(A=9UkjAcYT-:'LW[M$Q*]1%fdiDW#h4Y_+V1rADP?;o$?b\,0shV$o0GjfSbkeIO)KJ@e:bu>c0je\X*-p
-%Hi9LQo^"Q-h$M#^4DWa3puLF(^?FCf`j/;o!8!62$GlA9GX`rcB%)aJl(WT6D%u%+M/Rh:^'Z`j[l1(cY`C.FV#COf#fEX:7tp!p
-%987dm4A:fh<Uc)XO)[GlO,cBC2s[D5Wpd_8OIBSS)D&Vu/So.H45^AUU8ATJGoTOa@Z&-C^qttJos2]5T"$`oPRZ$l\OW`F>`C8G
-%YIDhMl\@.a(uA4/:OknGYI4'hWf8!CS30C\,tjNC=lV'd)OAg->>dJ@\-.sO7Edq^m5K59S@L^E".>WD7GK@A]j$!!SK=Y(&uW#@
-%dRi[+d<_aU/t;tuV>cA'\8e,F$^A_H\p5="hqB$",^Tui1WR;mP3<0YkCc;e%(a4TnHOf'FMC*i=_5t4RkpB@bScTA@jFM!0HDf=
-%N[5-VPXs5\NR\&Pr*"(@Zp7FafFQH@YWWc9(d'Ph5qB]Q68Wk@ZqT@r-g][&3\tH;j`Ue+#fGcr%fRi9,&#$ULCjA8#_*NGDk`J>
-%OA28=UmWA"?;ed$^%K*`+OinJRUs1uC)cL8p43knF`gt2anFWG;fj[PDK>E#1u/k,9)tN`e.DR11=Wi;0IBZ#4_mVEXQ[qYdGGJ0
-%Zf/M\JeJne9]7=6UE=#!_T1;Q1!uUciTN@"5\D<h"DoN/Vin/DCX03]<:4(_@(]Sk'@(n_%eQ[IU$hjTDQ5c#NTmf_#aX-12S+T3
-%rS=%ALqKpTYR!V9Y?Hoe-(!V"\=.9cq)*TF=9/G2hJB+[s7^]5CMb<4p'LX,+peAbA#/OYe7/*rAk31=Q9^6\#+WU9Cq):mk<Ac+
-%<@rK[4@&8DhgCj1AZ8[8?#-M;p^`-#)DjMP((U65l4nH`91@4/P>tA0gOWf%YD3=Y*KorJV&re82dXC.Ki\b25'?`Paekq*%f:jk
-%`PE#'n3F)2fkM8*Y=ge:oO6>\!D1f4)uEFo+bWVbM#77WeU?cl;;!VIVls_FS)&5:O=P60r=&QqU.mSl]X[9>m9rjs/i9NcW(ImS
-%kK1D3Ih%&4HPm!>1I2Qlb/Qrei(O[bLO.oK^u.lt"GcMUP$r;V#_I\dD\NW*"@7"rPYj+o'*Q/1Hn6->B7_6cGfhEOS-af*E$&mO
-%%*euAE3Lsi?uRFuJj[-W,@GI;#_GG=@j>B#-4#2*WuM:qo5SeI1kWQ40E?_]_'c.XPFar4jRGNT9J)P9K/5e)*(HPnL;B9##S-[8
-%&MQ2>5]H;Qp-rDF^"i%-gJipeXM.Jg%UjMqhr",BT4WRaG-1iu$:fmk-f#!j;bb<BcNeH#QAV0>Q*5hlnY(9"gJ@iqa#u*\*@O=G
-%H#o^'\gS,J=K>I[lB4m-J]?g)NJ5BAcSOC$AJZa%=-gFkZcT."N#^3^\3'!JW&[YF20/,M\-W]:m[_$#iF:MJ$1_WQ/q8-'IU\BU
-%c8[3tr'3gJ24&61S2i;kD6Mdaj5R[>g<68)Mm,9$JrV9bh/&??G"OQEgG>8CfrIpJ&BkT;gKFn6E_#T69OEm+^[h1nnbOA0-aETF
-%l*a06o;je2[g'_,GnTB8'IhD4_(19[R)40!k1<2uiVKFj3s8hKpR.tD%+\'!"<#`:29e`ITE;U[D!-3/Q?JnSIGopLL6peAl@QsH
-%,EU)e`HpeD4[^E>WE?M)UN.`gMk)f9q8RTddlkJGmS/I&@OP>#dH[?S[[oe514N5o^"2'I1ZgI-2gt_"Y>a1]#VM&.T3KLIHb$i0
-%B=\H0h9(dfk,EFG06a0Elnm86V3qN*?_r#GIRBE6[r]6)i^7moZiFI%^K`#NhdLI8BP=hSBJb`%ZNjho2g"JAWuL,K+K[2*9`3[0
-%SpLmH,ic&qrc^6]C[G<Ze\8H\jlq!&rMeV_Bsas`C+6QPgN8t'f%"':?*>@"s*cNUeXi6&et]Wd/`cU5S!t>qV07&_\'jWMk20`3
-%F2r3VgKV)O*Y)s=++>L[eY)Y!opRR#/h+Zug0<jhMj;t#lggnd6a9gs[aoqXrHXh2Z*Te?V-D7@d[Kc-(Z/O^Q&:9TZYmm+5Ptn#
-%WTb5'nd7ie/p$:Sh6$$ecrnm<b=@ukh5R+bXmNGn]6ILC3@M)l<bb5(7'E[e2<Boa);4=U;C&[KG@W@L\WAJ$N@]^.AZlUTG&nVZ
-%O51W2H:8QV<"OgJqWAY!YNt\)\a$<RJ(s@K?prHKBDJ>#Y8R9Uj^!6`V,7[4Ft>3sZL@&D01b!UXKmkG53,O+ZI_cKHM)QVr&ON9
-%NGk@McMHarJ&a15F(.lk=SPqc]qpRV(F_TImQW?;SR:V-ZT[%%[^31l:rQ8S^qhdhic6c%mZoM,F4JZoSrH),[T?B\YQ%ol.:(eI
-%bi_0^hX+\hl_a!)=uDc)![\1M_1J3_.dq*iDIIc@>qN3;j!Dh[njWF4Z[R?]]3)$#Im/f-66YJ!+hm=+IoUs+N=,<S&rSj%]f"[7
-%l<EMJSbl,n^;!.ipc?Bf]q<lGI:&SJSRnPYSKh)3I(I[[$:\E;.4eVCL$GPm./se&K>+@;gfsc%4mupNTC2HjV#P`gkga*@q955X
-%Yl36SjVS$Crl#$Z$,=^O%sOHLAe3jEm4`bR[?JnE)n!54]j/1Z=[%6II9b(E(Ar=TKPD%HlhBk^c\K_gbN_k<Di[OK3YXdXN>dCF
-%Y?sD`WGi`eB2m&1F*i3,leZ-9lM$i<VEUL"#=Qt7L[sfonX&\'m"DpsI$S+c^*BkenoQ`=;%>4jig>e,MQ%!9Jb(0oDX\Gm)l7cM
-%[mpa)bZ8`BGgGOt?Yl!)-#tV2^H&KV9Tr?WF,6T<a\d"_]_T'C2.[CH/DVLb\PucrIuE!XO,$h(MRReUhk3j_nTOV!MsZ4kH1nnG
-%Agub'I0o3;m2tJu"DXU9h82cE=1bG/mBYJ^dL.5::]Yi[*W'MYBE+;T0.>9@/p"5"no=(=2P>)_=[e4elIONpG%p?Clb14M5mA>E
-%)CqkH8\Mu3R;Y:M51cqfgb>7eVU"j5,S420.<N9B^&>&VEUPG?h4/,VKmr5%D>8(e;k\7+lVl5q+gH]5:ZfdUlClqVfum0^W*&<M
-%&70V9iKNQh,6.RUQL>,q(TM,B9rtn09)H>.l8Nm@:2Qn)#t]SuSJfHa;!W>*<k>fUqMDbqE?k"/[8M#S`.pMHc#O=L:>]oRc?gYN
-%/]34MhbA]0+:P>.^03UQIM\I/C1o!,m!Uk=[5L32FR+\<(L,_U?$DEAX3KYd[t=nm?mjX(K.e8EQB%[:3OBkQndchTci(")LX<me
-%MJYL?`A#4Z"me=G.3<-!k*C3+i<"BQYj^T$]:rX"@XkT/(L'i&L\jm>`>Sab>YV&=N]3h!4M5P&\dY-A>dK3E["jiX`8?:A%(CD/
-%YMYSN2q^!no3d/irphrOru&\"#+[X(@SoTIoB%M!ODQZFA+^"bWRC[pbT<D.)r<kL<\XEUGD]Atb]Elsba%Ed1G"Atqhr>tRt^];
-%Q0Xugo@']io#E,CdUhR@hQ+@=BQjXf1tkLEkGM/DX_-grP<fDDSREODS_7@dFF,H;HZ^EA(L+No]Wq&+Wu^0Zp<Z'%kcCCe06=8'
-%WB2MspX]7+Md2iRF?Jc%rNKKljVJiUNu;HLNV)4#g2k"R`4un[+5VFJn%./>Sa\4\J'l8M<O]W11%3IVN/hgXV9A,(b@*UE3>Edg
-%r8("Ob5-R`f2n!8$X%d_HsN3<?G/YC4m8,*l]3i<_Yac5H9/\)rbPCZ3:GGE\`ic08hG3B9LE\A:qK^XXo.RIS[3\gGP7eR\TcKH
-%/g>tqUE?NAq;6*oAVL=^9aBPO>`I)l.;U"@q($sjaLe,4i<F-Fm?Q*)f*aaeD"3b'L&O8XN:*1\Ni;*7TpEP)P]1a]l'78Xed``]
-%k6S,u.,BrQY0s7):YNH9h't(EYFL`qmZK7J#rq<TPfU*a,*=<;NtOH27V(^7?\"Y+%Rq^Qjmsm_@q.pT/"L<M,0.]Z,l!mB;'O'#
-%LlANd!_VP+(m2n'T1=_X)^DWr4Rd8;O^hlhU>gM@-$!g\8FeGJ"_C?FLkJdB)V"*GOBs0j%/WmGa2Wpoi!fW#-$!g\a@$lL@?ej<
-%0d9s+Bf6<Fm,](H8`4tNPfU*a,,&LV!7eas,;KbQ3B9@E*_X/Fru=YlfGKatYmCJ5Nl$V=gA]#UCL:ZMk:]<]HN?S]f&_1AaK[HD
-%GqRF:7#m6=BprA#6&?R#,;NI$5;^(j@RSX[_uCjP%&jrH^?8?;a2Wq2M#9bV^9>D0m!4s_jn9u;OVGd+7>W!',Efj^SjeJU)^CM$
-%fOn&*a2Wr%c/i;/,%$3>)1OF`2P8CeTGQOfNVON0Yl+m;T-Z@e@4i425>,`T92/3nr@FrDN12@Fg4#@;Hq$.Tg%MbJjth=I38+#3
-%UujJ^r\2IfZ_Z`iYeBHhrXCc'Gb8[H=]4i/!=hi4r@FrDN4e7_gWu%OcV2OR,hpY.Ra6:&4oaV^YSg9<8[b8)V"*ieq$jdZ?N0!B
-%@&"r[PANNWC-KPH9Xt$PWVHr8RrJ7-;Y-<%@l;C%Z_Z_>I[`%=p9URW1\*5`D*L[.4u<)%PAEHVC-JD:(6`T"956ZNQF)LWT-Z@e
-%@J)#'Ib&9u>Jf<fNcS'4?1mrYV5C.VfrmV(h9uPq7D=6"BN;)4eCuFm1B6&&O8eSQQ6Wa_>SeJeU/imFZ[An:bZU33CAMB_f7#8/
-%C6+@d<jhme[7I+RS]]o'd9<p$[26>radNAlp'%V==*)m@Fo`(+;RVk.TB![a:O%9T*rl4m5Bb&d1G]M(GkQ2rpYaM<amr`lZO1ar
-%rLL5]2KA%IpooI%qul7;93F@-[r^<8U/A\$KQJt1^]^Hp)-a\hC8MtXB9XM1d4.;JnoVn'^&qR5hBZ:^^";3@_\:;U*ciahO.B.d
-%3@:DGlq?)i\9Bb6PY,(NGaZAA?/eH])'OD7RZm7CWJIT?Apch=.:EHT;jkGp,i@qI6DjPrWI1=Pg(CLL"@:%/[K+:m\?><Q@=rVB
-%9&gOT[ZD-1$PII<Aft;Po<Z8e+.15VJ]il3AX'PV\eLRJ'*6R0ge&i2K<'[-q/7SXN$FQUj/=*9BDelrUo-5_<"TA."eOd`*&f)F
-%%BU=H#`$FOJHY;]c$7BR6Q5"c<gCt_5*gdK[VoY4Q_]V/1.q[!U0Nh#nK`R\PB!CRnQdg.g!CfZ97o[R_6QDPCtCc_Ju2\_4r1t7
-%9S0on7CPTk!fnUp]#qpd>];)SOtpY8.5R3HKFa,c!^+S[0U2n:IAqL?"PD'bdfSX!201NrG\]RmXfu!=6/XKBo>%)q]aTf(:P?5d
-%O'6+25sb]UY&Bo1m;O=ilq&(pF(!K8UC3B'O64"k-a6aiHn:=!ON\hskX.lSXpg[EH/bKY;A$`r>cbZ5,_h(\(A`c@juA_K:C-Pm
-%O?1krs59`L)'FG$pc8qc6?ABKB$I@@qGuB6$8=6)9FEfV6(iL_Fb!>JiFjf"0:iT*a33JQ4=f2?'O7"77QfZH,#ZdCRaGm*$^L9k
-%aT8B*#ERm_"a'sTQZRaWMmQ`)QYrS[27I!ddT=YoE.,t6g^1+0:aSV4^oR['[Us'-otePMZAp/4VEXEZNL%ZEXn^[dR.Z5%nh&p'
-%n2QdsS;QrTNP@U?8p2pmoUH>8WR/c*QuAjbAf-k$9N6"W-HJ<#qh-uLjcCUd\3u++T!0oBK&B8GSl#5P=.p`;'TFs[%`OS*Oskl+
-%M%*-Z4!$W&'>cG8/&?t!)*)lU50`h<\dc[?&7<e'588aPrIF>Laq;i\*XomTfMYAR$8U%%)i&%L)P0?1a]uCur+:reJ`f*O(2VE?
-%E?BIP7:K>L&P.:mK.?G>jFJh3ET0XUM2WHg1*@auecUR2-l*eY+9s)=#WY)r,kMSd0,uO?$_rC8K:.$,-pCZ8WWED5rij]/E7lgQ
-%Hlqm@KN2I$03n8fl+7htR$clpf7U`4NtiC%KT=aZL]l&&"0u*60.7-(">'d+-[_c$bnnggFUFcT=@3ujcru/i;?l(9='`QSJ8Ga&
-%,SA:TmmZcsYot.PO^M1r`/:]Ac&u[unQ:huVC;;'a+[=kkTaBpfUBk/%]qh4K!,sD1]@pYk/552\D4k-N0AJEEj<nD?V$"/*J0r-
-%nH=M#`tJq]^nItDe4j=0?61SWYn/CMmE3ejiZkV$0J!&LLd9sA*LW;:DD2;`;I$(n3+QU,8c7!o6('!QHj39[U]g=U,tf0C@<f:s
-%-)DET)K>J9!$O1]ERVd%o^h<RXHU$I0VX<'fuC8<eJL.dZW>L"#rWb2;Z`\T!^SIs,Ut5l;4M\ncWDh'fo[<:%Bq8??U>Te<Ru_b
-%;2C#b"-$<iOBGrs\-oMND8E68We6Xg"_RXJk<b9aOV5ITQ/I1P8O,dRE=t_Lm:>km6On-)cmUR;h2mBd6o8`^.8^Ldn=RQd*^CF,
-%5PRS?Zmj6LnG%S#5XF?n@?+st@FM<2:5rj$BP!dZ/u?Z&n9c.>es'DVaZ%!BnGM5s9b&Rs>/'LY+_*fD8WQl9Hq7:UWM)tH#ojP2
-%1L,O-&mW6(Ze$uf%uHHYB+WFa#b07r5dT^]!DoZT6bIdU#D*lcm8EKu3M.Hl34PTF#=65#F=]V`TqH%\4]8SHFmF<0(k^RcBsB$a
-%TH!#H5)7(E-H]gpA21('"J;nV$.DQ``h9sWKGpin3C;ea(_?m:\Yt@+dNM'!6UX2m+sr:Cc?L+,<PX_-AV"H)FJN\-+UFFJNN5e;
-%,0+JoC1(Ba+N\+lFkC-\)KsC`2HA!+#6D\o$D+aPD8fG*J"rqc6[,5OXu/mJ*cTaSenM_81O,'o$q<?05.scE%T@p94(fQUU#lsh
-%MsS@2^]St,?t*80P?9.kEi:J#L:/NT;2>a]2M%4c.0+H=QjZM*8!%`b?_thT'?(3'9[Pc/3MQ;+-POlAAn=&o`cpl^R]G\uE-.r[
-%<)Z:LF=F!s+fE#SH8EK@Seb@ScF$WP`s&HSVF7J!>Sq/pO^)7I*l\jGLJsQ!6,br"`=gY0C_?1&#eHHR@)D)>63eq&@T?7nYgX:_
-%80/h@NC&aJ0L\TEAJCZNN<j5^.2(&0?e^^8AsZ$(=\6%3W$qcR7rYIT8<7Qs=?`+WPoBo37G/4]("U6tQ'BVBI;ZjZ:U&&'!R\Si
-%Q1@aE;Oq?57i27eD1l^b$-f<AFN?HbTR)VI=!:s^7=oI,Sh%[HcrWo)7a;`l23O70Oj`<2-MVT?.M7VVWXDCl=nIsSdJD6eE'Bp;
-%'I3CAGcOP^/<PXrSuK^@DoqCf5adSeKNg>n4<_l!a=D657FhR)#E)"?>[O]]#Zh2,I\ijn-<9_5mR6T'$=?E(WV/*(P0Y'Zn,c/.
-%U>Zj_!MZhd0Jo-Y7*6C5a4c9V/#rP^p;A@KPH<-DjJG&j<8:tDr?r'FTgCAR)L;D>EC*6<WiRVs)^a2dE#hQ-V^_G<EGLH[:7;g!
-%Rc`%\dNpj1Pmius_&Y9f\k4J`W`<`"fkhlkUre*:1,;@HiB@M.BXC4&4ko$K.!9s@<frPCj?ksA&Gnd55o2MGosrA!A\*?KKUV.P
-%j=67tn:lNdNB%`Jl\$:I&Oc!4eCeV6O[es8\.V*)::hr%c)//aN9*V`^r`aDEYR+U&h\sa)l\Lm:!)DC^&cW[ihHAQl#r\Ukp\6@
-%5kE%te*J@1/<h8<j9.<^3_c@oOSTHVLnKIq>qRN'+PIlHG6j'A4R_+oT&+O>4SFSC.Y3WtVo-t4,YpKn4>ARZCi`_2nHBe:[R0QU
-%-E=nd\ekZ0Uf;?I)ck8$#UN5Hp-GH-ZshF?S(FkV((uTa_5?7iD]HciK1L#+K5RP?_Asr5XWd.F89#G*kU,?8[#j?iP?`1aKc;*k
-%jQGQs?oVO.7Kf$Q!&P[oN04W=Z_;=S$]0SuaI*TI@tC"\Z"P-gkX/4^OIR:9,n[CmK4se>,bDFQjYhh2$n.Dip!ZH>g4UR%MPS4S
-%5&GDh,R*Q\po[a/nn_923g/b5X;T/A:*["ZT$(nBRlJ,?Q'.jN/m;"OF1?br$T9L0/=//,QaSb62Hg,?_hG*#Cu-K*-(a0=4PKKX
-%,^S/IIiNO/>Z8@[-S`V]=CDZ_.mEVO!@<OV-L068oM)faHhZXTI2R?/(*C`mitXjHeI^'5PHs^\`h&FH-YECr'uFo1dD*WIZ5]"l
-%ks\io&sV^nY@n8MZ$h01"Jc%Fru>f9-*=r]?XB(AqY4J9%!k'N/V:).!lH-W$nH0Y<L`[+elDZeo6LB+Y5M/gGq"Hhr0?8#J6+0Q
-%*7+&d64@oElPIn!Z.;M6iAP\>UtA2lYI$_&UEP'2j(i5^i;X9IR,j1JU$O%ck0Q"dnqHtbK_,+dQ+VAM>A@I6]@-NNeF`Crl:q5M
-%?#BMB[o55VlMoA9C9)LO=FI:.iu@<]?11#mFfTS1pD6\G96C"%FQl^aomb.>&V'~>
-%AI9_PrivateDataEnd
diff --git a/contrib/bind9/doc/arm/isc-logo.pdf b/contrib/bind9/doc/arm/isc-logo.pdf
deleted file mode 100644
index 71d3fdd..0000000
--- a/contrib/bind9/doc/arm/isc-logo.pdf
+++ /dev/null
diff --git a/contrib/bind9/doc/arm/man.dig.html b/contrib/bind9/doc/arm/man.dig.html
deleted file mode 100644
index 7d0e437..0000000
--- a/contrib/bind9/doc/arm/man.dig.html
+++ /dev/null
@@ -1,665 +0,0 @@
-<!--
- - Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2000-2003 Internet Software Consortium.
- - 
- - Permission to use, copy, modify, and distribute this software for any
- - purpose with or without fee is hereby granted, provided that the above
- - copyright notice and this permission notice appear in all copies.
- - 
- - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
- - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- - PERFORMANCE OF THIS SOFTWARE.
--->
-<!-- $Id: man.dig.html,v 1.2.2.48 2007/10/31 01:35:59 marka Exp $ -->
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>dig</title>
-<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
-<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="up" href="Bv9ARM.ch10.html" title="Manual pages">
-<link rel="prev" href="Bv9ARM.ch10.html" title="Manual pages">
-<link rel="next" href="man.host.html" title="host">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
-<div class="navheader">
-<table width="100%" summary="Navigation header">
-<tr><th colspan="3" align="center">dig</th></tr>
-<tr>
-<td width="20%" align="left">
-<a accesskey="p" href="Bv9ARM.ch10.html">Prev</a> </td>
-<th width="60%" align="center">Manual pages</th>
-<td width="20%" align="right"> <a accesskey="n" href="man.host.html">Next</a>
-</td>
-</tr>
-</table>
-<hr>
-</div>
-<div class="refentry" lang="en">
-<a name="man.dig"></a><div class="titlepage"></div>
-<div class="refnamediv">
-<h2>Name</h2>
-<p>dig &#8212; DNS lookup utility</p>
-</div>
-<div class="refsynopsisdiv">
-<h2>Synopsis</h2>
-<div class="cmdsynopsis"><p><code class="command">dig</code>  [@server] [<code class="option">-b <em class="replaceable"><code>address</code></em></code>] [<code class="option">-c <em class="replaceable"><code>class</code></em></code>] [<code class="option">-f <em class="replaceable"><code>filename</code></em></code>] [<code class="option">-k <em class="replaceable"><code>filename</code></em></code>] [<code class="option">-p <em class="replaceable"><code>port#</code></em></code>] [<code class="option">-q <em class="replaceable"><code>name</code></em></code>] [<code class="option">-t <em class="replaceable"><code>type</code></em></code>] [<code class="option">-x <em class="replaceable"><code>addr</code></em></code>] [<code class="option">-y <em class="replaceable"><code>[<span class="optional">hmac:</span>]name:key</code></em></code>] [<code class="option">-4</code>] [<code class="option">-6</code>] [name] [type] [class] [queryopt...]</p></div>
-<div class="cmdsynopsis"><p><code class="command">dig</code>  [<code class="option">-h</code>]</p></div>
-<div class="cmdsynopsis"><p><code class="command">dig</code>  [global-queryopt...] [query...]</p></div>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2564025"></a><h2>DESCRIPTION</h2>
-<p><span><strong class="command">dig</strong></span>
-      (domain information groper) is a flexible tool
-      for interrogating DNS name servers.  It performs DNS lookups and
-      displays the answers that are returned from the name server(s) that
-      were queried.  Most DNS administrators use <span><strong class="command">dig</strong></span> to
-      troubleshoot DNS problems because of its flexibility, ease of use and
-      clarity of output.  Other lookup tools tend to have less functionality
-      than <span><strong class="command">dig</strong></span>.
-    </p>
-<p>
-      Although <span><strong class="command">dig</strong></span> is normally used with
-      command-line
-      arguments, it also has a batch mode of operation for reading lookup
-      requests from a file.  A brief summary of its command-line arguments
-      and options is printed when the <code class="option">-h</code> option is given.
-      Unlike earlier versions, the BIND 9 implementation of
-      <span><strong class="command">dig</strong></span> allows multiple lookups to be issued
-      from the
-      command line.
-    </p>
-<p>
-      Unless it is told to query a specific name server,
-      <span><strong class="command">dig</strong></span> will try each of the servers listed
-      in
-      <code class="filename">/etc/resolv.conf</code>.
-    </p>
-<p>
-      When no command line arguments or options are given, will perform an
-      NS query for "." (the root).
-    </p>
-<p>
-      It is possible to set per-user defaults for <span><strong class="command">dig</strong></span> via
-      <code class="filename">${HOME}/.digrc</code>.  This file is read and
-      any options in it
-      are applied before the command line arguments.
-    </p>
-<p>
-      The IN and CH class names overlap with the IN and CH top level
-      domains names.  Either use the <code class="option">-t</code> and
-      <code class="option">-c</code> options to specify the type and class or
-      use the <code class="option">-q</code> the specify the domain name or
-      use "IN." and "CH." when looking up these top level domains.
-    </p>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2569712"></a><h2>SIMPLE USAGE</h2>
-<p>
-      A typical invocation of <span><strong class="command">dig</strong></span> looks like:
-      </p>
-<pre class="programlisting"> dig @server name type </pre>
-<p>
-      where:
-
-      </p>
-<div class="variablelist"><dl>
-<dt><span class="term"><code class="constant">server</code></span></dt>
-<dd><p>
-              is the name or IP address of the name server to query.  This can
-              be an IPv4
-              address in dotted-decimal notation or an IPv6
-              address in colon-delimited notation.  When the supplied
-              <em class="parameter"><code>server</code></em> argument is a
-              hostname,
-              <span><strong class="command">dig</strong></span> resolves that name before
-              querying that name
-              server.  If no <em class="parameter"><code>server</code></em>
-              argument is provided,
-              <span><strong class="command">dig</strong></span> consults <code class="filename">/etc/resolv.conf</code>
-              and queries the name servers listed there.  The reply from the
-              name
-              server that responds is displayed.
-            </p></dd>
-<dt><span class="term"><code class="constant">name</code></span></dt>
-<dd><p>
-              is the name of the resource record that is to be looked up.
-            </p></dd>
-<dt><span class="term"><code class="constant">type</code></span></dt>
-<dd><p>
-              indicates what type of query is required &#8212;
-              ANY, A, MX, SIG, etc.
-              <em class="parameter"><code>type</code></em> can be any valid query
-              type.  If no
-              <em class="parameter"><code>type</code></em> argument is supplied,
-              <span><strong class="command">dig</strong></span> will perform a lookup for an
-              A record.
-            </p></dd>
-</dl></div>
-<p>
-    </p>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2623002"></a><h2>OPTIONS</h2>
-<p>
-      The <code class="option">-b</code> option sets the source IP address of the query
-      to <em class="parameter"><code>address</code></em>.  This must be a valid
-      address on
-      one of the host's network interfaces or "0.0.0.0" or "::".  An optional
-      port
-      may be specified by appending "#&lt;port&gt;"
-    </p>
-<p>
-      The default query class (IN for internet) is overridden by the
-      <code class="option">-c</code> option.  <em class="parameter"><code>class</code></em> is
-      any valid
-      class, such as HS for Hesiod records or CH for Chaosnet records.
-    </p>
-<p>
-      The <code class="option">-f</code> option makes <span><strong class="command">dig </strong></span>
-      operate
-      in batch mode by reading a list of lookup requests to process from the
-      file <em class="parameter"><code>filename</code></em>.  The file contains a
-      number of
-      queries, one per line.  Each entry in the file should be organized in
-      the same way they would be presented as queries to
-      <span><strong class="command">dig</strong></span> using the command-line interface.
-    </p>
-<p>
-      If a non-standard port number is to be queried, the
-      <code class="option">-p</code> option is used.  <em class="parameter"><code>port#</code></em> is
-      the port number that <span><strong class="command">dig</strong></span> will send its
-      queries
-      instead of the standard DNS port number 53.  This option would be used
-      to test a name server that has been configured to listen for queries
-      on a non-standard port number.
-    </p>
-<p>
-      The <code class="option">-4</code> option forces <span><strong class="command">dig</strong></span>
-      to only
-      use IPv4 query transport.  The <code class="option">-6</code> option forces
-      <span><strong class="command">dig</strong></span> to only use IPv6 query transport.
-    </p>
-<p>
-      The <code class="option">-t</code> option sets the query type to
-      <em class="parameter"><code>type</code></em>.  It can be any valid query type
-      which is
-      supported in BIND 9.  The default query type is "A", unless the
-      <code class="option">-x</code> option is supplied to indicate a reverse lookup.
-      A zone transfer can be requested by specifying a type of AXFR.  When
-      an incremental zone transfer (IXFR) is required,
-      <em class="parameter"><code>type</code></em> is set to <code class="literal">ixfr=N</code>.
-      The incremental zone transfer will contain the changes made to the zone
-      since the serial number in the zone's SOA record was
-      <em class="parameter"><code>N</code></em>.
-    </p>
-<p>
-      The <code class="option">-q</code> option sets the query name to 
-      <em class="parameter"><code>name</code></em>.  This useful do distinguish the
-      <em class="parameter"><code>name</code></em> from other arguments.
-    </p>
-<p>
-      Reverse lookups &#8212; mapping addresses to names &#8212; are simplified by the
-      <code class="option">-x</code> option.  <em class="parameter"><code>addr</code></em> is
-      an IPv4
-      address in dotted-decimal notation, or a colon-delimited IPv6 address.
-      When this option is used, there is no need to provide the
-      <em class="parameter"><code>name</code></em>, <em class="parameter"><code>class</code></em> and
-      <em class="parameter"><code>type</code></em> arguments.  <span><strong class="command">dig</strong></span>
-      automatically performs a lookup for a name like
-      <code class="literal">11.12.13.10.in-addr.arpa</code> and sets the
-      query type and
-      class to PTR and IN respectively.  By default, IPv6 addresses are
-      looked up using nibble format under the IP6.ARPA domain.
-      To use the older RFC1886 method using the IP6.INT domain
-      specify the <code class="option">-i</code> option.  Bit string labels (RFC2874)
-      are now experimental and are not attempted.
-    </p>
-<p>
-      To sign the DNS queries sent by <span><strong class="command">dig</strong></span> and
-      their
-      responses using transaction signatures (TSIG), specify a TSIG key file
-      using the <code class="option">-k</code> option.  You can also specify the TSIG
-      key itself on the command line using the <code class="option">-y</code> option;
-      <em class="parameter"><code>hmac</code></em> is the type of the TSIG, default HMAC-MD5,
-      <em class="parameter"><code>name</code></em> is the name of the TSIG key and
-      <em class="parameter"><code>key</code></em> is the actual key.  The key is a
-      base-64
-      encoded string, typically generated by
-      <span class="citerefentry"><span class="refentrytitle">dnssec-keygen</span>(8)</span>.
-
-      Caution should be taken when using the <code class="option">-y</code> option on
-      multi-user systems as the key can be visible in the output from
-      <span class="citerefentry"><span class="refentrytitle">ps</span>(1)</span>
-      or in the shell's history file.  When
-      using TSIG authentication with <span><strong class="command">dig</strong></span>, the name
-      server that is queried needs to know the key and algorithm that is
-      being used.  In BIND, this is done by providing appropriate
-      <span><strong class="command">key</strong></span> and <span><strong class="command">server</strong></span> statements in
-      <code class="filename">named.conf</code>.
-    </p>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2649413"></a><h2>QUERY OPTIONS</h2>
-<p><span><strong class="command">dig</strong></span>
-      provides a number of query options which affect
-      the way in which lookups are made and the results displayed.  Some of
-      these set or reset flag bits in the query header, some determine which
-      sections of the answer get printed, and others determine the timeout
-      and retry strategies.
-    </p>
-<p>
-      Each query option is identified by a keyword preceded by a plus sign
-      (<code class="literal">+</code>).  Some keywords set or reset an
-      option.  These may be preceded
-      by the string <code class="literal">no</code> to negate the meaning of
-      that keyword.  Other
-      keywords assign values to options like the timeout interval.  They
-      have the form <code class="option">+keyword=value</code>.
-      The query options are:
-
-      </p>
-<div class="variablelist"><dl>
-<dt><span class="term"><code class="option">+[no]tcp</code></span></dt>
-<dd><p>
-              Use [do not use] TCP when querying name servers.  The default
-              behavior is to use UDP unless an AXFR or IXFR query is
-              requested, in
-              which case a TCP connection is used.
-            </p></dd>
-<dt><span class="term"><code class="option">+[no]vc</code></span></dt>
-<dd><p>
-              Use [do not use] TCP when querying name servers.  This alternate
-              syntax to <em class="parameter"><code>+[no]tcp</code></em> is
-              provided for backwards
-              compatibility.  The "vc" stands for "virtual circuit".
-            </p></dd>
-<dt><span class="term"><code class="option">+[no]ignore</code></span></dt>
-<dd><p>
-              Ignore truncation in UDP responses instead of retrying with TCP.
-               By
-              default, TCP retries are performed.
-            </p></dd>
-<dt><span class="term"><code class="option">+domain=somename</code></span></dt>
-<dd><p>
-              Set the search list to contain the single domain
-              <em class="parameter"><code>somename</code></em>, as if specified in
-              a
-              <span><strong class="command">domain</strong></span> directive in
-              <code class="filename">/etc/resolv.conf</code>, and enable
-              search list
-              processing as if the <em class="parameter"><code>+search</code></em>
-              option were given.
-            </p></dd>
-<dt><span class="term"><code class="option">+[no]search</code></span></dt>
-<dd><p>
-              Use [do not use] the search list defined by the searchlist or
-              domain
-              directive in <code class="filename">resolv.conf</code> (if
-              any).
-              The search list is not used by default.
-            </p></dd>
-<dt><span class="term"><code class="option">+[no]showsearch</code></span></dt>
-<dd><p>
-              Perform [do not perform] a search showing intermediate
-	      results.
-            </p></dd>
-<dt><span class="term"><code class="option">+[no]defname</code></span></dt>
-<dd><p>
-              Deprecated, treated as a synonym for <em class="parameter"><code>+[no]search</code></em>
-            </p></dd>
-<dt><span class="term"><code class="option">+[no]aaonly</code></span></dt>
-<dd><p>
-              Sets the "aa" flag in the query.
-            </p></dd>
-<dt><span class="term"><code class="option">+[no]aaflag</code></span></dt>
-<dd><p>
-              A synonym for <em class="parameter"><code>+[no]aaonly</code></em>.
-            </p></dd>
-<dt><span class="term"><code class="option">+[no]adflag</code></span></dt>
-<dd><p>
-              Set [do not set] the AD (authentic data) bit in the query.  The
-              AD bit
-              currently has a standard meaning only in responses, not in
-              queries,
-              but the ability to set the bit in the query is provided for
-              completeness.
-            </p></dd>
-<dt><span class="term"><code class="option">+[no]cdflag</code></span></dt>
-<dd><p>
-              Set [do not set] the CD (checking disabled) bit in the query.
-              This
-              requests the server to not perform DNSSEC validation of
-              responses.
-            </p></dd>
-<dt><span class="term"><code class="option">+[no]cl</code></span></dt>
-<dd><p>
-              Display [do not display] the CLASS when printing the record.
-            </p></dd>
-<dt><span class="term"><code class="option">+[no]ttlid</code></span></dt>
-<dd><p>
-              Display [do not display] the TTL when printing the record.
-            </p></dd>
-<dt><span class="term"><code class="option">+[no]recurse</code></span></dt>
-<dd><p>
-              Toggle the setting of the RD (recursion desired) bit in the
-              query.
-              This bit is set by default, which means <span><strong class="command">dig</strong></span>
-              normally sends recursive queries.  Recursion is automatically
-              disabled
-              when the <em class="parameter"><code>+nssearch</code></em> or
-              <em class="parameter"><code>+trace</code></em> query options are
-              used.
-            </p></dd>
-<dt><span class="term"><code class="option">+[no]nssearch</code></span></dt>
-<dd><p>
-              When this option is set, <span><strong class="command">dig</strong></span>
-              attempts to find the
-              authoritative name servers for the zone containing the name
-              being
-              looked up and display the SOA record that each name server has
-              for the
-              zone.
-            </p></dd>
-<dt><span class="term"><code class="option">+[no]trace</code></span></dt>
-<dd><p>
-              Toggle tracing of the delegation path from the root name servers
-              for
-              the name being looked up.  Tracing is disabled by default.  When
-              tracing is enabled, <span><strong class="command">dig</strong></span> makes
-              iterative queries to
-              resolve the name being looked up.  It will follow referrals from
-              the
-              root servers, showing the answer from each server that was used
-              to
-              resolve the lookup.
-            </p></dd>
-<dt><span class="term"><code class="option">+[no]cmd</code></span></dt>
-<dd><p>
-              Toggles the printing of the initial comment in the output
-              identifying
-              the version of <span><strong class="command">dig</strong></span> and the query
-              options that have
-              been applied.  This comment is printed by default.
-            </p></dd>
-<dt><span class="term"><code class="option">+[no]short</code></span></dt>
-<dd><p>
-              Provide a terse answer.  The default is to print the answer in a
-              verbose form.
-            </p></dd>
-<dt><span class="term"><code class="option">+[no]identify</code></span></dt>
-<dd><p>
-              Show [or do not show] the IP address and port number that
-              supplied the
-              answer when the <em class="parameter"><code>+short</code></em> option
-              is enabled.  If
-              short form answers are requested, the default is not to show the
-              source address and port number of the server that provided the
-              answer.
-            </p></dd>
-<dt><span class="term"><code class="option">+[no]comments</code></span></dt>
-<dd><p>
-              Toggle the display of comment lines in the output.  The default
-              is to
-              print comments.
-            </p></dd>
-<dt><span class="term"><code class="option">+[no]stats</code></span></dt>
-<dd><p>
-              This query option toggles the printing of statistics: when the
-              query
-              was made, the size of the reply and so on.  The default
-              behavior is
-              to print the query statistics.
-            </p></dd>
-<dt><span class="term"><code class="option">+[no]qr</code></span></dt>
-<dd><p>
-              Print [do not print] the query as it is sent.
-              By default, the query is not printed.
-            </p></dd>
-<dt><span class="term"><code class="option">+[no]question</code></span></dt>
-<dd><p>
-              Print [do not print] the question section of a query when an
-              answer is
-              returned.  The default is to print the question section as a
-              comment.
-            </p></dd>
-<dt><span class="term"><code class="option">+[no]answer</code></span></dt>
-<dd><p>
-              Display [do not display] the answer section of a reply.  The
-              default
-              is to display it.
-            </p></dd>
-<dt><span class="term"><code class="option">+[no]authority</code></span></dt>
-<dd><p>
-              Display [do not display] the authority section of a reply.  The
-              default is to display it.
-            </p></dd>
-<dt><span class="term"><code class="option">+[no]additional</code></span></dt>
-<dd><p>
-              Display [do not display] the additional section of a reply.
-              The default is to display it.
-            </p></dd>
-<dt><span class="term"><code class="option">+[no]all</code></span></dt>
-<dd><p>
-              Set or clear all display flags.
-            </p></dd>
-<dt><span class="term"><code class="option">+time=T</code></span></dt>
-<dd><p>
-
-              Sets the timeout for a query to
-              <em class="parameter"><code>T</code></em> seconds.  The default
-	      timeout is 5 seconds.
-              An attempt to set <em class="parameter"><code>T</code></em> to less
-              than 1 will result
-              in a query timeout of 1 second being applied.
-            </p></dd>
-<dt><span class="term"><code class="option">+tries=T</code></span></dt>
-<dd><p>
-              Sets the number of times to try UDP queries to server to
-              <em class="parameter"><code>T</code></em> instead of the default, 3.
-              If
-              <em class="parameter"><code>T</code></em> is less than or equal to
-              zero, the number of
-              tries is silently rounded up to 1.
-            </p></dd>
-<dt><span class="term"><code class="option">+retry=T</code></span></dt>
-<dd><p>
-              Sets the number of times to retry UDP queries to server to
-              <em class="parameter"><code>T</code></em> instead of the default, 2.
-              Unlike
-              <em class="parameter"><code>+tries</code></em>, this does not include
-              the initial
-              query.
-            </p></dd>
-<dt><span class="term"><code class="option">+ndots=D</code></span></dt>
-<dd><p>
-              Set the number of dots that have to appear in
-              <em class="parameter"><code>name</code></em> to <em class="parameter"><code>D</code></em> for it to be
-              considered absolute.  The default value is that defined using
-              the
-              ndots statement in <code class="filename">/etc/resolv.conf</code>, or 1 if no
-              ndots statement is present.  Names with fewer dots are
-              interpreted as
-              relative names and will be searched for in the domains listed in
-              the
-              <code class="option">search</code> or <code class="option">domain</code> directive in
-              <code class="filename">/etc/resolv.conf</code>.
-            </p></dd>
-<dt><span class="term"><code class="option">+bufsize=B</code></span></dt>
-<dd><p>
-              Set the UDP message buffer size advertised using EDNS0 to
-              <em class="parameter"><code>B</code></em> bytes.  The maximum and minimum sizes
-	      of this buffer are 65535 and 0 respectively.  Values outside
-	      this range are rounded up or down appropriately.  
-	      Values other than zero will cause a EDNS query to be sent.
-            </p></dd>
-<dt><span class="term"><code class="option">+edns=#</code></span></dt>
-<dd><p>
-	       Specify the EDNS version to query with.  Valid values
-	       are 0 to 255.  Setting the EDNS version will cause a
-	       EDNS query to be sent.  <code class="option">+noedns</code> clears the
-	       remembered EDNS version.
-	    </p></dd>
-<dt><span class="term"><code class="option">+[no]multiline</code></span></dt>
-<dd><p>
-              Print records like the SOA records in a verbose multi-line
-              format with human-readable comments.  The default is to print
-              each record on a single line, to facilitate machine parsing
-              of the <span><strong class="command">dig</strong></span> output.
-            </p></dd>
-<dt><span class="term"><code class="option">+[no]fail</code></span></dt>
-<dd><p>
-              Do not try the next server if you receive a SERVFAIL.  The
-              default is
-              to not try the next server which is the reverse of normal stub
-              resolver
-              behavior.
-            </p></dd>
-<dt><span class="term"><code class="option">+[no]besteffort</code></span></dt>
-<dd><p>
-              Attempt to display the contents of messages which are malformed.
-              The default is to not display malformed answers.
-            </p></dd>
-<dt><span class="term"><code class="option">+[no]dnssec</code></span></dt>
-<dd><p>
-              Requests DNSSEC records be sent by setting the DNSSEC OK bit
-              (DO)
-              in the OPT record in the additional section of the query.
-            </p></dd>
-<dt><span class="term"><code class="option">+[no]sigchase</code></span></dt>
-<dd><p>
-              Chase DNSSEC signature chains.  Requires dig be compiled with
-              -DDIG_SIGCHASE.
-            </p></dd>
-<dt><span class="term"><code class="option">+trusted-key=####</code></span></dt>
-<dd>
-<p>
-              Specifies a file containing trusted keys to be used with
-	      <code class="option">+sigchase</code>.  Each DNSKEY record must be
-	      on its own line.
-            </p>
-<p>
-	      If not specified <span><strong class="command">dig</strong></span> will look for
-	      <code class="filename">/etc/trusted-key.key</code> then
-	      <code class="filename">trusted-key.key</code> in the current directory.
-	    </p>
-<p>
-              Requires dig be compiled with -DDIG_SIGCHASE.
-	    </p>
-</dd>
-<dt><span class="term"><code class="option">+[no]topdown</code></span></dt>
-<dd><p>
-              When chasing DNSSEC signature chains perform a top-down
-              validation.
-              Requires dig be compiled with -DDIG_SIGCHASE.
-            </p></dd>
-</dl></div>
-<p>
-
-    </p>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2650468"></a><h2>MULTIPLE QUERIES</h2>
-<p>
-      The BIND 9 implementation of <span><strong class="command">dig </strong></span>
-      supports
-      specifying multiple queries on the command line (in addition to
-      supporting the <code class="option">-f</code> batch file option).  Each of those
-      queries can be supplied with its own set of flags, options and query
-      options.
-    </p>
-<p>
-      In this case, each <em class="parameter"><code>query</code></em> argument
-      represent an
-      individual query in the command-line syntax described above.  Each
-      consists of any of the standard options and flags, the name to be
-      looked up, an optional query type and class and any query options that
-      should be applied to that query.
-    </p>
-<p>
-      A global set of query options, which should be applied to all queries,
-      can also be supplied.  These global query options must precede the
-      first tuple of name, class, type, options, flags, and query options
-      supplied on the command line.  Any global query options (except
-      the <code class="option">+[no]cmd</code> option) can be
-      overridden by a query-specific set of query options.  For example:
-      </p>
-<pre class="programlisting">
-dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr
-</pre>
-<p>
-      shows how <span><strong class="command">dig</strong></span> could be used from the
-      command line
-      to make three lookups: an ANY query for <code class="literal">www.isc.org</code>, a
-      reverse lookup of 127.0.0.1 and a query for the NS records of
-      <code class="literal">isc.org</code>.
-
-      A global query option of <em class="parameter"><code>+qr</code></em> is
-      applied, so
-      that <span><strong class="command">dig</strong></span> shows the initial query it made
-      for each
-      lookup.  The final query has a local query option of
-      <em class="parameter"><code>+noqr</code></em> which means that <span><strong class="command">dig</strong></span>
-      will not print the initial query when it looks up the NS records for
-      <code class="literal">isc.org</code>.
-    </p>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2650553"></a><h2>IDN SUPPORT</h2>
-<p>
-      If <span><strong class="command">dig</strong></span> has been built with IDN (internationalized
-      domain name) support, it can accept and display non-ASCII domain names.
-      <span><strong class="command">dig</strong></span> appropriately converts character encoding of
-      domain name before sending a request to DNS server or displaying a
-      reply from the server.
-      If you'd like to turn off the IDN support for some reason, defines
-      the <code class="envar">IDN_DISABLE</code> environment variable.
-      The IDN support is disabled if the variable is set when 
-      <span><strong class="command">dig</strong></span> runs.
-    </p>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2650582"></a><h2>FILES</h2>
-<p><code class="filename">/etc/resolv.conf</code>
-    </p>
-<p><code class="filename">${HOME}/.digrc</code>
-    </p>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2650603"></a><h2>SEE ALSO</h2>
-<p><span class="citerefentry"><span class="refentrytitle">host</span>(1)</span>,
-      <span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>,
-      <span class="citerefentry"><span class="refentrytitle">dnssec-keygen</span>(8)</span>,
-      <em class="citetitle">RFC1035</em>.
-    </p>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2650641"></a><h2>BUGS</h2>
-<p>
-      There are probably too many query options.
-    </p>
-</div>
-</div>
-<div class="navfooter">
-<hr>
-<table width="100%" summary="Navigation footer">
-<tr>
-<td width="40%" align="left">
-<a accesskey="p" href="Bv9ARM.ch10.html">Prev</a> </td>
-<td width="20%" align="center"><a accesskey="u" href="Bv9ARM.ch10.html">Up</a></td>
-<td width="40%" align="right"> <a accesskey="n" href="man.host.html">Next</a>
-</td>
-</tr>
-<tr>
-<td width="40%" align="left" valign="top">Manual pages </td>
-<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
-<td width="40%" align="right" valign="top"> host</td>
-</tr>
-</table>
-</div>
-</body>
-</html>
diff --git a/contrib/bind9/doc/arm/man.dnssec-keygen.html b/contrib/bind9/doc/arm/man.dnssec-keygen.html
deleted file mode 100644
index 3b8d2d8..0000000
--- a/contrib/bind9/doc/arm/man.dnssec-keygen.html
+++ /dev/null
@@ -1,269 +0,0 @@
-<!--
- - Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2000-2003 Internet Software Consortium.
- - 
- - Permission to use, copy, modify, and distribute this software for any
- - purpose with or without fee is hereby granted, provided that the above
- - copyright notice and this permission notice appear in all copies.
- - 
- - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
- - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- - PERFORMANCE OF THIS SOFTWARE.
--->
-<!-- $Id: man.dnssec-keygen.html,v 1.2.2.47 2007/10/31 01:35:59 marka Exp $ -->
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>dnssec-keygen</title>
-<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
-<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="up" href="Bv9ARM.ch10.html" title="Manual pages">
-<link rel="prev" href="man.host.html" title="host">
-<link rel="next" href="man.dnssec-signzone.html" title="dnssec-signzone">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
-<div class="navheader">
-<table width="100%" summary="Navigation header">
-<tr><th colspan="3" align="center"><span class="application">dnssec-keygen</span></th></tr>
-<tr>
-<td width="20%" align="left">
-<a accesskey="p" href="man.host.html">Prev</a> </td>
-<th width="60%" align="center">Manual pages</th>
-<td width="20%" align="right"> <a accesskey="n" href="man.dnssec-signzone.html">Next</a>
-</td>
-</tr>
-</table>
-<hr>
-</div>
-<div class="refentry" lang="en">
-<a name="man.dnssec-keygen"></a><div class="titlepage"></div>
-<div class="refnamediv">
-<h2>Name</h2>
-<p><span class="application">dnssec-keygen</span> &#8212; DNSSEC key generation tool</p>
-</div>
-<div class="refsynopsisdiv">
-<h2>Synopsis</h2>
-<div class="cmdsynopsis"><p><code class="command">dnssec-keygen</code>  {-a <em class="replaceable"><code>algorithm</code></em>} {-b <em class="replaceable"><code>keysize</code></em>} {-n <em class="replaceable"><code>nametype</code></em>} [<code class="option">-c <em class="replaceable"><code>class</code></em></code>] [<code class="option">-e</code>] [<code class="option">-f <em class="replaceable"><code>flag</code></em></code>] [<code class="option">-g <em class="replaceable"><code>generator</code></em></code>] [<code class="option">-h</code>] [<code class="option">-k</code>] [<code class="option">-p <em class="replaceable"><code>protocol</code></em></code>] [<code class="option">-r <em class="replaceable"><code>randomdev</code></em></code>] [<code class="option">-s <em class="replaceable"><code>strength</code></em></code>] [<code class="option">-t <em class="replaceable"><code>type</code></em></code>] [<code class="option">-v <em class="replaceable"><code>level</code></em></code>] {name}</p></div>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2597830"></a><h2>DESCRIPTION</h2>
-<p><span><strong class="command">dnssec-keygen</strong></span>
-      generates keys for DNSSEC (Secure DNS), as defined in RFC 2535
-      and RFC 4034.  It can also generate keys for use with
-      TSIG (Transaction Signatures), as defined in RFC 2845.
-    </p>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2597844"></a><h2>OPTIONS</h2>
-<div class="variablelist"><dl>
-<dt><span class="term">-a <em class="replaceable"><code>algorithm</code></em></span></dt>
-<dd>
-<p>
-            Selects the cryptographic algorithm.  The value of
-            <code class="option">algorithm</code> must be one of RSAMD5 (RSA) or RSASHA1,
-            	      DSA, DH (Diffie Hellman), or HMAC-MD5.  These values
-            are case insensitive.
-          </p>
-<p>
-            Note 1: that for DNSSEC, RSASHA1 is a mandatory to implement
-            algorithm,
-            and DSA is recommended.  For TSIG, HMAC-MD5 is mandatory.
-          </p>
-<p>
-            Note 2: HMAC-MD5 and DH automatically set the -k flag.
-          </p>
-</dd>
-<dt><span class="term">-b <em class="replaceable"><code>keysize</code></em></span></dt>
-<dd><p>
-            Specifies the number of bits in the key.  The choice of key
-            size depends on the algorithm used.  RSAMD5 / RSASHA1 keys must be
-            between
-            512 and 2048 bits.  Diffie Hellman keys must be between
-            128 and 4096 bits.  DSA keys must be between 512 and 1024
-            bits and an exact multiple of 64.  HMAC-MD5 keys must be
-            between 1 and 512 bits.
-          </p></dd>
-<dt><span class="term">-n <em class="replaceable"><code>nametype</code></em></span></dt>
-<dd><p>
-            Specifies the owner type of the key.  The value of
-            <code class="option">nametype</code> must either be ZONE (for a DNSSEC
-            zone key (KEY/DNSKEY)), HOST or ENTITY (for a key associated with
-            a host (KEY)),
-            USER (for a key associated with a user(KEY)) or OTHER (DNSKEY).
-            These values are
-            case insensitive.
-          </p></dd>
-<dt><span class="term">-c <em class="replaceable"><code>class</code></em></span></dt>
-<dd><p>
-            Indicates that the DNS record containing the key should have
-            the specified class.  If not specified, class IN is used.
-          </p></dd>
-<dt><span class="term">-e</span></dt>
-<dd><p>
-            If generating an RSAMD5/RSASHA1 key, use a large exponent.
-          </p></dd>
-<dt><span class="term">-f <em class="replaceable"><code>flag</code></em></span></dt>
-<dd><p>
-            Set the specified flag in the flag field of the KEY/DNSKEY record.
-            		The only recognized flag is KSK (Key Signing Key) DNSKEY.
-          </p></dd>
-<dt><span class="term">-g <em class="replaceable"><code>generator</code></em></span></dt>
-<dd><p>
-            If generating a Diffie Hellman key, use this generator.
-            Allowed values are 2 and 5.  If no generator
-            is specified, a known prime from RFC 2539 will be used
-            if possible; otherwise the default is 2.
-          </p></dd>
-<dt><span class="term">-h</span></dt>
-<dd><p>
-            Prints a short summary of the options and arguments to
-            <span><strong class="command">dnssec-keygen</strong></span>.
-          </p></dd>
-<dt><span class="term">-k</span></dt>
-<dd><p>
-            Generate KEY records rather than DNSKEY records.
-          </p></dd>
-<dt><span class="term">-p <em class="replaceable"><code>protocol</code></em></span></dt>
-<dd><p>
-            Sets the protocol value for the generated key.  The protocol
-            is a number between 0 and 255.  The default is 3 (DNSSEC).
-            Other possible values for this argument are listed in
-            RFC 2535 and its successors.
-          </p></dd>
-<dt><span class="term">-r <em class="replaceable"><code>randomdev</code></em></span></dt>
-<dd><p>
-            Specifies the source of randomness.  If the operating
-            system does not provide a <code class="filename">/dev/random</code>
-            or equivalent device, the default source of randomness
-            is keyboard input.  <code class="filename">randomdev</code>
-            specifies
-            the name of a character device or file containing random
-            data to be used instead of the default.  The special value
-            <code class="filename">keyboard</code> indicates that keyboard
-            input should be used.
-          </p></dd>
-<dt><span class="term">-s <em class="replaceable"><code>strength</code></em></span></dt>
-<dd><p>
-            Specifies the strength value of the key.  The strength is
-            a number between 0 and 15, and currently has no defined
-            purpose in DNSSEC.
-          </p></dd>
-<dt><span class="term">-t <em class="replaceable"><code>type</code></em></span></dt>
-<dd><p>
-            Indicates the use of the key.  <code class="option">type</code> must be
-            one of AUTHCONF, NOAUTHCONF, NOAUTH, or NOCONF.  The default
-            is AUTHCONF.  AUTH refers to the ability to authenticate
-            data, and CONF the ability to encrypt data.
-          </p></dd>
-<dt><span class="term">-v <em class="replaceable"><code>level</code></em></span></dt>
-<dd><p>
-            Sets the debugging level.
-          </p></dd>
-</dl></div>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2598187"></a><h2>GENERATED KEYS</h2>
-<p>
-      When <span><strong class="command">dnssec-keygen</strong></span> completes
-      successfully,
-      it prints a string of the form <code class="filename">Knnnn.+aaa+iiiii</code>
-      to the standard output.  This is an identification string for
-      the key it has generated.
-    </p>
-<div class="itemizedlist"><ul type="disc">
-<li><p><code class="filename">nnnn</code> is the key name.
-        </p></li>
-<li><p><code class="filename">aaa</code> is the numeric representation
-          of the
-          algorithm.
-        </p></li>
-<li><p><code class="filename">iiiii</code> is the key identifier (or
-          footprint).
-        </p></li>
-</ul></div>
-<p><span><strong class="command">dnssec-keygen</strong></span> 
-      creates two files, with names based
-      on the printed string.  <code class="filename">Knnnn.+aaa+iiiii.key</code>
-      contains the public key, and
-      <code class="filename">Knnnn.+aaa+iiiii.private</code> contains the
-      private
-      key.
-    </p>
-<p>
-      The <code class="filename">.key</code> file contains a DNS KEY record
-      that
-      can be inserted into a zone file (directly or with a $INCLUDE
-      statement).
-    </p>
-<p>
-      The <code class="filename">.private</code> file contains
-      algorithm-specific
-      fields.  For obvious security reasons, this file does not have
-      general read permission.
-    </p>
-<p>
-      Both <code class="filename">.key</code> and <code class="filename">.private</code>
-      files are generated for symmetric encryption algorithms such as
-      HMAC-MD5, even though the public and private key are equivalent.
-    </p>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2598295"></a><h2>EXAMPLE</h2>
-<p>
-      To generate a 768-bit DSA key for the domain
-      <strong class="userinput"><code>example.com</code></strong>, the following command would be
-      issued:
-    </p>
-<p><strong class="userinput"><code>dnssec-keygen -a DSA -b 768 -n ZONE example.com</code></strong>
-    </p>
-<p>
-      The command would print a string of the form:
-    </p>
-<p><strong class="userinput"><code>Kexample.com.+003+26160</code></strong>
-    </p>
-<p>
-      In this example, <span><strong class="command">dnssec-keygen</strong></span> creates
-      the files <code class="filename">Kexample.com.+003+26160.key</code>
-      and
-      <code class="filename">Kexample.com.+003+26160.private</code>.
-    </p>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2600195"></a><h2>SEE ALSO</h2>
-<p><span class="citerefentry"><span class="refentrytitle">dnssec-signzone</span>(8)</span>,
-      <em class="citetitle">BIND 9 Administrator Reference Manual</em>,
-      <em class="citetitle">RFC 2535</em>,
-      <em class="citetitle">RFC 2845</em>,
-      <em class="citetitle">RFC 2539</em>.
-    </p>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2600226"></a><h2>AUTHOR</h2>
-<p><span class="corpauthor">Internet Systems Consortium</span>
-    </p>
-</div>
-</div>
-<div class="navfooter">
-<hr>
-<table width="100%" summary="Navigation footer">
-<tr>
-<td width="40%" align="left">
-<a accesskey="p" href="man.host.html">Prev</a> </td>
-<td width="20%" align="center"><a accesskey="u" href="Bv9ARM.ch10.html">Up</a></td>
-<td width="40%" align="right"> <a accesskey="n" href="man.dnssec-signzone.html">Next</a>
-</td>
-</tr>
-<tr>
-<td width="40%" align="left" valign="top">host </td>
-<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
-<td width="40%" align="right" valign="top"> <span class="application">dnssec-signzone</span>
-</td>
-</tr>
-</table>
-</div>
-</body>
-</html>
diff --git a/contrib/bind9/doc/arm/man.dnssec-signzone.html b/contrib/bind9/doc/arm/man.dnssec-signzone.html
deleted file mode 100644
index 2d0ce06..0000000
--- a/contrib/bind9/doc/arm/man.dnssec-signzone.html
+++ /dev/null
@@ -1,323 +0,0 @@
-<!--
- - Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2000-2003 Internet Software Consortium.
- - 
- - Permission to use, copy, modify, and distribute this software for any
- - purpose with or without fee is hereby granted, provided that the above
- - copyright notice and this permission notice appear in all copies.
- - 
- - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
- - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- - PERFORMANCE OF THIS SOFTWARE.
--->
-<!-- $Id: man.dnssec-signzone.html,v 1.2.2.46 2007/10/31 01:35:59 marka Exp $ -->
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>dnssec-signzone</title>
-<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
-<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="up" href="Bv9ARM.ch10.html" title="Manual pages">
-<link rel="prev" href="man.dnssec-keygen.html" title="dnssec-keygen">
-<link rel="next" href="man.named-checkconf.html" title="named-checkconf">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
-<div class="navheader">
-<table width="100%" summary="Navigation header">
-<tr><th colspan="3" align="center"><span class="application">dnssec-signzone</span></th></tr>
-<tr>
-<td width="20%" align="left">
-<a accesskey="p" href="man.dnssec-keygen.html">Prev</a> </td>
-<th width="60%" align="center">Manual pages</th>
-<td width="20%" align="right"> <a accesskey="n" href="man.named-checkconf.html">Next</a>
-</td>
-</tr>
-</table>
-<hr>
-</div>
-<div class="refentry" lang="en">
-<a name="man.dnssec-signzone"></a><div class="titlepage"></div>
-<div class="refnamediv">
-<h2>Name</h2>
-<p><span class="application">dnssec-signzone</span> &#8212; DNSSEC zone signing tool</p>
-</div>
-<div class="refsynopsisdiv">
-<h2>Synopsis</h2>
-<div class="cmdsynopsis"><p><code class="command">dnssec-signzone</code>  [<code class="option">-a</code>] [<code class="option">-c <em class="replaceable"><code>class</code></em></code>] [<code class="option">-d <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-e <em class="replaceable"><code>end-time</code></em></code>] [<code class="option">-f <em class="replaceable"><code>output-file</code></em></code>] [<code class="option">-g</code>] [<code class="option">-h</code>] [<code class="option">-k <em class="replaceable"><code>key</code></em></code>] [<code class="option">-l <em class="replaceable"><code>domain</code></em></code>] [<code class="option">-i <em class="replaceable"><code>interval</code></em></code>] [<code class="option">-I <em class="replaceable"><code>input-format</code></em></code>] [<code class="option">-j <em class="replaceable"><code>jitter</code></em></code>] [<code class="option">-N <em class="replaceable"><code>soa-serial-format</code></em></code>] [<code class="option">-o <em class="replaceable"><code>origin</code></em></code>] [<code class="option">-O <em class="replaceable"><code>output-format</code></em></code>] [<code class="option">-p</code>] [<code class="option">-r <em class="replaceable"><code>randomdev</code></em></code>] [<code class="option">-s <em class="replaceable"><code>start-time</code></em></code>] [<code class="option">-t</code>] [<code class="option">-v <em class="replaceable"><code>level</code></em></code>] [<code class="option">-z</code>] {zonefile} [key...]</p></div>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2598823"></a><h2>DESCRIPTION</h2>
-<p><span><strong class="command">dnssec-signzone</strong></span>
-      signs a zone.  It generates
-      NSEC and RRSIG records and produces a signed version of the
-      zone. The security status of delegations from the signed zone
-      (that is, whether the child zones are secure or not) is
-      determined by the presence or absence of a
-      <code class="filename">keyset</code> file for each child zone.
-    </p>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2598842"></a><h2>OPTIONS</h2>
-<div class="variablelist"><dl>
-<dt><span class="term">-a</span></dt>
-<dd><p>
-            Verify all generated signatures.
-          </p></dd>
-<dt><span class="term">-c <em class="replaceable"><code>class</code></em></span></dt>
-<dd><p>
-            Specifies the DNS class of the zone.
-          </p></dd>
-<dt><span class="term">-k <em class="replaceable"><code>key</code></em></span></dt>
-<dd><p>
-            Treat specified key as a key signing key ignoring any
-            key flags.  This option may be specified multiple times.
-          </p></dd>
-<dt><span class="term">-l <em class="replaceable"><code>domain</code></em></span></dt>
-<dd><p>
-            Generate a DLV set in addition to the key (DNSKEY) and DS sets.
-            The domain is appended to the name of the records.
-          </p></dd>
-<dt><span class="term">-d <em class="replaceable"><code>directory</code></em></span></dt>
-<dd><p>
-            Look for <code class="filename">keyset</code> files in
-            <code class="option">directory</code> as the directory
-          </p></dd>
-<dt><span class="term">-g</span></dt>
-<dd><p>
-            Generate DS records for child zones from keyset files.
-            Existing DS records will be removed.
-          </p></dd>
-<dt><span class="term">-s <em class="replaceable"><code>start-time</code></em></span></dt>
-<dd><p>
-            Specify the date and time when the generated RRSIG records
-            become valid.  This can be either an absolute or relative
-            time.  An absolute start time is indicated by a number
-            in YYYYMMDDHHMMSS notation; 20000530144500 denotes
-            14:45:00 UTC on May 30th, 2000.  A relative start time is
-            indicated by +N, which is N seconds from the current time.
-            If no <code class="option">start-time</code> is specified, the current
-            time minus 1 hour (to allow for clock skew) is used.
-          </p></dd>
-<dt><span class="term">-e <em class="replaceable"><code>end-time</code></em></span></dt>
-<dd><p>
-            Specify the date and time when the generated RRSIG records
-            expire.  As with <code class="option">start-time</code>, an absolute
-            time is indicated in YYYYMMDDHHMMSS notation.  A time relative
-            to the start time is indicated with +N, which is N seconds from
-            the start time.  A time relative to the current time is
-            indicated with now+N.  If no <code class="option">end-time</code> is
-            specified, 30 days from the start time is used as a default.
-          </p></dd>
-<dt><span class="term">-f <em class="replaceable"><code>output-file</code></em></span></dt>
-<dd><p>
-            The name of the output file containing the signed zone.  The
-            default is to append <code class="filename">.signed</code> to
-            the
-            input filename.
-          </p></dd>
-<dt><span class="term">-h</span></dt>
-<dd><p>
-            Prints a short summary of the options and arguments to
-            <span><strong class="command">dnssec-signzone</strong></span>.
-          </p></dd>
-<dt><span class="term">-i <em class="replaceable"><code>interval</code></em></span></dt>
-<dd>
-<p>
-            When a previously-signed zone is passed as input, records
-            may be resigned.  The <code class="option">interval</code> option
-            specifies the cycle interval as an offset from the current
-            time (in seconds).  If a RRSIG record expires after the
-            cycle interval, it is retained.  Otherwise, it is considered
-            to be expiring soon, and it will be replaced.
-          </p>
-<p>
-            The default cycle interval is one quarter of the difference
-            between the signature end and start times.  So if neither
-            <code class="option">end-time</code> or <code class="option">start-time</code>
-            are specified, <span><strong class="command">dnssec-signzone</strong></span>
-            generates
-            signatures that are valid for 30 days, with a cycle
-            interval of 7.5 days.  Therefore, if any existing RRSIG records
-            are due to expire in less than 7.5 days, they would be
-            replaced.
-          </p>
-</dd>
-<dt><span class="term">-I <em class="replaceable"><code>input-format</code></em></span></dt>
-<dd><p>
-            The format of the input zone file.
-	    Possible formats are <span><strong class="command">"text"</strong></span> (default)
-	    and <span><strong class="command">"raw"</strong></span>.
-	    This option is primarily intended to be used for dynamic
-            signed zones so that the dumped zone file in a non-text
-            format containing updates can be signed directly.
-	    The use of this option does not make much sense for
-	    non-dynamic zones.
-          </p></dd>
-<dt><span class="term">-j <em class="replaceable"><code>jitter</code></em></span></dt>
-<dd>
-<p>
-            When signing a zone with a fixed signature lifetime, all
-            RRSIG records issued at the time of signing expires
-            simultaneously.  If the zone is incrementally signed, i.e.
-            a previously-signed zone is passed as input to the signer,
-            all expired signatures have to be regenerated at about the
-            same time.  The <code class="option">jitter</code> option specifies a
-            jitter window that will be used to randomize the signature
-            expire time, thus spreading incremental signature
-            regeneration over time.
-          </p>
-<p>
-            Signature lifetime jitter also to some extent benefits
-            validators and servers by spreading out cache expiration,
-            i.e. if large numbers of RRSIGs don't expire at the same time
-            from all caches there will be less congestion than if all
-            validators need to refetch at mostly the same time.
-          </p>
-</dd>
-<dt><span class="term">-n <em class="replaceable"><code>ncpus</code></em></span></dt>
-<dd><p>
-            Specifies the number of threads to use.  By default, one
-            thread is started for each detected CPU.
-          </p></dd>
-<dt><span class="term">-N <em class="replaceable"><code>soa-serial-format</code></em></span></dt>
-<dd>
-<p>
-            The SOA serial number format of the signed zone.
-	    Possible formats are <span><strong class="command">"keep"</strong></span> (default),
-            <span><strong class="command">"increment"</strong></span> and
-	    <span><strong class="command">"unixtime"</strong></span>.
-          </p>
-<div class="variablelist"><dl>
-<dt><span class="term"><span><strong class="command">"keep"</strong></span></span></dt>
-<dd><p>Do not modify the SOA serial number.</p></dd>
-<dt><span class="term"><span><strong class="command">"increment"</strong></span></span></dt>
-<dd><p>Increment the SOA serial number using RFC 1982
-                      arithmetics.</p></dd>
-<dt><span class="term"><span><strong class="command">"unixtime"</strong></span></span></dt>
-<dd><p>Set the SOA serial number to the number of seconds
-	        since epoch.</p></dd>
-</dl></div>
-</dd>
-<dt><span class="term">-o <em class="replaceable"><code>origin</code></em></span></dt>
-<dd><p>
-            The zone origin.  If not specified, the name of the zone file
-            is assumed to be the origin.
-          </p></dd>
-<dt><span class="term">-O <em class="replaceable"><code>output-format</code></em></span></dt>
-<dd><p>
-            The format of the output file containing the signed zone.
-	    Possible formats are <span><strong class="command">"text"</strong></span> (default)
-	    and <span><strong class="command">"raw"</strong></span>.
-          </p></dd>
-<dt><span class="term">-p</span></dt>
-<dd><p>
-            Use pseudo-random data when signing the zone.  This is faster,
-            but less secure, than using real random data.  This option
-            may be useful when signing large zones or when the entropy
-            source is limited.
-          </p></dd>
-<dt><span class="term">-r <em class="replaceable"><code>randomdev</code></em></span></dt>
-<dd><p>
-            Specifies the source of randomness.  If the operating
-            system does not provide a <code class="filename">/dev/random</code>
-            or equivalent device, the default source of randomness
-            is keyboard input.  <code class="filename">randomdev</code>
-            specifies
-            the name of a character device or file containing random
-            data to be used instead of the default.  The special value
-            <code class="filename">keyboard</code> indicates that keyboard
-            input should be used.
-          </p></dd>
-<dt><span class="term">-t</span></dt>
-<dd><p>
-            Print statistics at completion.
-          </p></dd>
-<dt><span class="term">-v <em class="replaceable"><code>level</code></em></span></dt>
-<dd><p>
-            Sets the debugging level.
-          </p></dd>
-<dt><span class="term">-z</span></dt>
-<dd><p>
-            Ignore KSK flag on key when determining what to sign.
-          </p></dd>
-<dt><span class="term">zonefile</span></dt>
-<dd><p>
-            The file containing the zone to be signed.
-          </p></dd>
-<dt><span class="term">key</span></dt>
-<dd><p>
-	    Specify which keys should be used to sign the zone.  If
-	    no keys are specified, then the zone will be examined
-	    for DNSKEY records at the zone apex.  If these are found and
-	    there are matching private keys, in the current directory,
-	    then these will be used for signing.
-          </p></dd>
-</dl></div>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2641307"></a><h2>EXAMPLE</h2>
-<p>
-      The following command signs the <strong class="userinput"><code>example.com</code></strong>
-      zone with the DSA key generated by <span><strong class="command">dnssec-keygen</strong></span>
-      (Kexample.com.+003+17247).  The zone's keys must be in the master
-      file (<code class="filename">db.example.com</code>).  This invocation looks
-      for <code class="filename">keyset</code> files, in the current directory,
-      so that DS records can be generated from them (<span><strong class="command">-g</strong></span>).
-    </p>
-<pre class="programlisting">% dnssec-signzone -g -o example.com db.example.com \
-Kexample.com.+003+17247
-db.example.com.signed
-%</pre>
-<p>
-      In the above example, <span><strong class="command">dnssec-signzone</strong></span> creates
-      the file <code class="filename">db.example.com.signed</code>.  This
-      file should be referenced in a zone statement in a
-      <code class="filename">named.conf</code> file.
-    </p>
-<p>
-      This example re-signs a previously signed zone with default parameters.
-      The private keys are assumed to be in the current directory.
-    </p>
-<pre class="programlisting">% cp db.example.com.signed db.example.com
-% dnssec-signzone -o example.com db.example.com
-db.example.com.signed
-%</pre>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2641380"></a><h2>SEE ALSO</h2>
-<p><span class="citerefentry"><span class="refentrytitle">dnssec-keygen</span>(8)</span>,
-      <em class="citetitle">BIND 9 Administrator Reference Manual</em>,
-      <em class="citetitle">RFC 2535</em>.
-    </p>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2641404"></a><h2>AUTHOR</h2>
-<p><span class="corpauthor">Internet Systems Consortium</span>
-    </p>
-</div>
-</div>
-<div class="navfooter">
-<hr>
-<table width="100%" summary="Navigation footer">
-<tr>
-<td width="40%" align="left">
-<a accesskey="p" href="man.dnssec-keygen.html">Prev</a> </td>
-<td width="20%" align="center"><a accesskey="u" href="Bv9ARM.ch10.html">Up</a></td>
-<td width="40%" align="right"> <a accesskey="n" href="man.named-checkconf.html">Next</a>
-</td>
-</tr>
-<tr>
-<td width="40%" align="left" valign="top">
-<span class="application">dnssec-keygen</span> </td>
-<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
-<td width="40%" align="right" valign="top"> <span class="application">named-checkconf</span>
-</td>
-</tr>
-</table>
-</div>
-</body>
-</html>
diff --git a/contrib/bind9/doc/arm/man.host.html b/contrib/bind9/doc/arm/man.host.html
deleted file mode 100644
index 6bc2188..0000000
--- a/contrib/bind9/doc/arm/man.host.html
+++ /dev/null
@@ -1,249 +0,0 @@
-<!--
- - Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2000-2003 Internet Software Consortium.
- - 
- - Permission to use, copy, modify, and distribute this software for any
- - purpose with or without fee is hereby granted, provided that the above
- - copyright notice and this permission notice appear in all copies.
- - 
- - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
- - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- - PERFORMANCE OF THIS SOFTWARE.
--->
-<!-- $Id: man.host.html,v 1.2.2.46 2007/10/31 01:35:59 marka Exp $ -->
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>host</title>
-<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
-<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="up" href="Bv9ARM.ch10.html" title="Manual pages">
-<link rel="prev" href="man.dig.html" title="dig">
-<link rel="next" href="man.dnssec-keygen.html" title="dnssec-keygen">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
-<div class="navheader">
-<table width="100%" summary="Navigation header">
-<tr><th colspan="3" align="center">host</th></tr>
-<tr>
-<td width="20%" align="left">
-<a accesskey="p" href="man.dig.html">Prev</a> </td>
-<th width="60%" align="center">Manual pages</th>
-<td width="20%" align="right"> <a accesskey="n" href="man.dnssec-keygen.html">Next</a>
-</td>
-</tr>
-</table>
-<hr>
-</div>
-<div class="refentry" lang="en">
-<a name="man.host"></a><div class="titlepage"></div>
-<div class="refnamediv">
-<h2>Name</h2>
-<p>host &#8212; DNS lookup utility</p>
-</div>
-<div class="refsynopsisdiv">
-<h2>Synopsis</h2>
-<div class="cmdsynopsis"><p><code class="command">host</code>  [<code class="option">-aCdlnrsTwv</code>] [<code class="option">-c <em class="replaceable"><code>class</code></em></code>] [<code class="option">-N <em class="replaceable"><code>ndots</code></em></code>] [<code class="option">-R <em class="replaceable"><code>number</code></em></code>] [<code class="option">-t <em class="replaceable"><code>type</code></em></code>] [<code class="option">-W <em class="replaceable"><code>wait</code></em></code>] [<code class="option">-m <em class="replaceable"><code>flag</code></em></code>] [<code class="option">-4</code>] [<code class="option">-6</code>] {name} [server]</p></div>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2597000"></a><h2>DESCRIPTION</h2>
-<p><span><strong class="command">host</strong></span>
-      is a simple utility for performing DNS lookups.
-      It is normally used to convert names to IP addresses and vice versa.
-      When no arguments or options are given,
-      <span><strong class="command">host</strong></span>
-      prints a short summary of its command line arguments and options.
-    </p>
-<p><em class="parameter"><code>name</code></em> is the domain name that is to be
-      looked
-      up.  It can also be a dotted-decimal IPv4 address or a colon-delimited
-      IPv6 address, in which case <span><strong class="command">host</strong></span> will by
-      default
-      perform a reverse lookup for that address.
-      <em class="parameter"><code>server</code></em> is an optional argument which
-      is either
-      the name or IP address of the name server that <span><strong class="command">host</strong></span>
-      should query instead of the server or servers listed in
-      <code class="filename">/etc/resolv.conf</code>.
-    </p>
-<p>
-      The <code class="option">-a</code> (all) option is equivalent to setting the
-      <code class="option">-v</code> option and asking <span><strong class="command">host</strong></span> to make
-      a query of type ANY.
-    </p>
-<p>
-      When the <code class="option">-C</code> option is used, <span><strong class="command">host</strong></span>
-      will attempt to display the SOA records for zone
-      <em class="parameter"><code>name</code></em> from all the listed
-      authoritative name
-      servers for that zone.  The list of name servers is defined by the NS
-      records that are found for the zone.
-    </p>
-<p>
-      The <code class="option">-c</code> option instructs to make a DNS query of class
-      <em class="parameter"><code>class</code></em>.  This can be used to lookup
-      Hesiod or
-      Chaosnet class resource records.  The default class is IN (Internet).
-    </p>
-<p>
-      Verbose output is generated by <span><strong class="command">host</strong></span> when
-      the
-      <code class="option">-d</code> or <code class="option">-v</code> option is used.  The two
-      options are equivalent.  They have been provided for backwards
-      compatibility.  In previous versions, the <code class="option">-d</code> option
-      switched on debugging traces and <code class="option">-v</code> enabled verbose
-      output.
-    </p>
-<p>
-      List mode is selected by the <code class="option">-l</code> option.  This makes
-      <span><strong class="command">host</strong></span> perform a zone transfer for zone
-      <em class="parameter"><code>name</code></em>.  Transfer the zone printing out
-      the NS, PTR
-      and address records (A/AAAA).  If combined with <code class="option">-a</code>
-      all records will be printed.
-    </p>
-<p>
-      The <code class="option">-i</code>
-      option specifies that reverse lookups of IPv6 addresses should
-      use the IP6.INT domain as defined in RFC1886.
-      The default is to use IP6.ARPA.
-    </p>
-<p>
-      The <code class="option">-N</code> option sets the number of dots that have to be
-      in <em class="parameter"><code>name</code></em> for it to be considered
-      absolute.  The
-      default value is that defined using the ndots statement in
-      <code class="filename">/etc/resolv.conf</code>, or 1 if no ndots
-      statement is
-      present.  Names with fewer dots are interpreted as relative names and
-      will be searched for in the domains listed in the <span class="type">search</span>
-      or <span class="type">domain</span> directive in
-      <code class="filename">/etc/resolv.conf</code>.
-    </p>
-<p>
-      The number of UDP retries for a lookup can be changed with the
-      <code class="option">-R</code> option.  <em class="parameter"><code>number</code></em>
-      indicates
-      how many times <span><strong class="command">host</strong></span> will repeat a query
-      that does
-      not get answered.  The default number of retries is 1.  If
-      <em class="parameter"><code>number</code></em> is negative or zero, the
-      number of
-      retries will default to 1.
-    </p>
-<p>
-      Non-recursive queries can be made via the <code class="option">-r</code> option.
-      Setting this option clears the <span class="type">RD</span> &#8212; recursion
-      desired &#8212; bit in the query which <span><strong class="command">host</strong></span> makes.
-      This should mean that the name server receiving the query will not
-      attempt to resolve <em class="parameter"><code>name</code></em>.  The
-      <code class="option">-r</code> option enables <span><strong class="command">host</strong></span>
-      to mimic
-      the behavior of a name server by making non-recursive queries and
-      expecting to receive answers to those queries that are usually
-      referrals to other name servers.
-    </p>
-<p>
-      By default <span><strong class="command">host</strong></span> uses UDP when making
-      queries.  The
-      <code class="option">-T</code> option makes it use a TCP connection when querying
-      the name server.  TCP will be automatically selected for queries that
-      require it, such as zone transfer (AXFR) requests.
-    </p>
-<p>
-      The <code class="option">-4</code> option forces <span><strong class="command">host</strong></span> to only
-      use IPv4 query transport.  The <code class="option">-6</code> option forces
-      <span><strong class="command">host</strong></span> to only use IPv6 query transport.
-    </p>
-<p>
-      The <code class="option">-t</code> option is used to select the query type.
-      <em class="parameter"><code>type</code></em> can be any recognized query
-      type: CNAME,
-      NS, SOA, SIG, KEY, AXFR, etc.  When no query type is specified,
-      <span><strong class="command">host</strong></span> automatically selects an appropriate
-      query
-      type.  By default it looks for A records, but if the
-      <code class="option">-C</code> option was given, queries will be made for SOA
-      records, and if <em class="parameter"><code>name</code></em> is a
-      dotted-decimal IPv4
-      address or colon-delimited IPv6 address, <span><strong class="command">host</strong></span> will
-      query for PTR records.  If a query type of IXFR is chosen the starting
-      serial number can be specified by appending an equal followed by the
-      starting serial number (e.g. -t IXFR=12345678).
-    </p>
-<p>
-      The time to wait for a reply can be controlled through the
-      <code class="option">-W</code> and <code class="option">-w</code> options.  The
-      <code class="option">-W</code> option makes <span><strong class="command">host</strong></span>
-      wait for
-      <em class="parameter"><code>wait</code></em> seconds.  If <em class="parameter"><code>wait</code></em>
-      is less than one, the wait interval is set to one second.  When the
-      <code class="option">-w</code> option is used, <span><strong class="command">host</strong></span>
-      will
-      effectively wait forever for a reply.  The time to wait for a response
-      will be set to the number of seconds given by the hardware's maximum
-      value for an integer quantity.
-    </p>
-<p>
-      The <code class="option">-s</code> option tells <span><strong class="command">host</strong></span> 
-      <span class="emphasis"><em>not</em></span> to send the query to the next nameserver
-      if any server responds with a SERVFAIL response, which is the
-      reverse of normal stub resolver behavior.
-    </p>
-<p>
-      The <code class="option">-m</code> can be used to set the memory usage debugging
-      flags
-      <em class="parameter"><code>record</code></em>, <em class="parameter"><code>usage</code></em> and
-      <em class="parameter"><code>trace</code></em>.
-    </p>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2597514"></a><h2>IDN SUPPORT</h2>
-<p>
-      If <span><strong class="command">host</strong></span> has been built with IDN (internationalized
-      domain name) support, it can accept and display non-ASCII domain names. 
-      <span><strong class="command">host</strong></span> appropriately converts character encoding of
-      domain name before sending a request to DNS server or displaying a
-      reply from the server.
-      If you'd like to turn off the IDN support for some reason, defines
-      the <code class="envar">IDN_DISABLE</code> environment variable.
-      The IDN support is disabled if the variable is set when
-      <span><strong class="command">host</strong></span> runs.
-    </p>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2597543"></a><h2>FILES</h2>
-<p><code class="filename">/etc/resolv.conf</code>
-    </p>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2597557"></a><h2>SEE ALSO</h2>
-<p><span class="citerefentry"><span class="refentrytitle">dig</span>(1)</span>,
-      <span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>.
-    </p>
-</div>
-</div>
-<div class="navfooter">
-<hr>
-<table width="100%" summary="Navigation footer">
-<tr>
-<td width="40%" align="left">
-<a accesskey="p" href="man.dig.html">Prev</a> </td>
-<td width="20%" align="center"><a accesskey="u" href="Bv9ARM.ch10.html">Up</a></td>
-<td width="40%" align="right"> <a accesskey="n" href="man.dnssec-keygen.html">Next</a>
-</td>
-</tr>
-<tr>
-<td width="40%" align="left" valign="top">dig </td>
-<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
-<td width="40%" align="right" valign="top"> <span class="application">dnssec-keygen</span>
-</td>
-</tr>
-</table>
-</div>
-</body>
-</html>
diff --git a/contrib/bind9/doc/arm/man.named-checkconf.html b/contrib/bind9/doc/arm/man.named-checkconf.html
deleted file mode 100644
index 7db5021..0000000
--- a/contrib/bind9/doc/arm/man.named-checkconf.html
+++ /dev/null
@@ -1,130 +0,0 @@
-<!--
- - Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2000-2003 Internet Software Consortium.
- - 
- - Permission to use, copy, modify, and distribute this software for any
- - purpose with or without fee is hereby granted, provided that the above
- - copyright notice and this permission notice appear in all copies.
- - 
- - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
- - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- - PERFORMANCE OF THIS SOFTWARE.
--->
-<!-- $Id: man.named-checkconf.html,v 1.2.2.49 2007/10/31 01:35:59 marka Exp $ -->
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>named-checkconf</title>
-<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
-<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="up" href="Bv9ARM.ch10.html" title="Manual pages">
-<link rel="prev" href="man.dnssec-signzone.html" title="dnssec-signzone">
-<link rel="next" href="man.named-checkzone.html" title="named-checkzone">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
-<div class="navheader">
-<table width="100%" summary="Navigation header">
-<tr><th colspan="3" align="center"><span class="application">named-checkconf</span></th></tr>
-<tr>
-<td width="20%" align="left">
-<a accesskey="p" href="man.dnssec-signzone.html">Prev</a> </td>
-<th width="60%" align="center">Manual pages</th>
-<td width="20%" align="right"> <a accesskey="n" href="man.named-checkzone.html">Next</a>
-</td>
-</tr>
-</table>
-<hr>
-</div>
-<div class="refentry" lang="en">
-<a name="man.named-checkconf"></a><div class="titlepage"></div>
-<div class="refnamediv">
-<h2>Name</h2>
-<p><span class="application">named-checkconf</span> &#8212; named configuration file syntax checking tool</p>
-</div>
-<div class="refsynopsisdiv">
-<h2>Synopsis</h2>
-<div class="cmdsynopsis"><p><code class="command">named-checkconf</code>  [<code class="option">-v</code>] [<code class="option">-j</code>] [<code class="option">-t <em class="replaceable"><code>directory</code></em></code>] {filename} [<code class="option">-z</code>]</p></div>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2599604"></a><h2>DESCRIPTION</h2>
-<p><span><strong class="command">named-checkconf</strong></span>
-      checks the syntax, but not the semantics, of a named
-      configuration file.
-    </p>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2599618"></a><h2>OPTIONS</h2>
-<div class="variablelist"><dl>
-<dt><span class="term">-t <em class="replaceable"><code>directory</code></em></span></dt>
-<dd><p>
-            Chroot to <code class="filename">directory</code> so that
-            include
-            directives in the configuration file are processed as if
-            run by a similarly chrooted named.
-          </p></dd>
-<dt><span class="term">-v</span></dt>
-<dd><p>
-            Print the version of the <span><strong class="command">named-checkconf</strong></span>
-            program and exit.
-          </p></dd>
-<dt><span class="term">-z</span></dt>
-<dd><p>
-	    Perform a test load of all master zones found in
-	    <code class="filename">named.conf</code>.
-          </p></dd>
-<dt><span class="term">-j</span></dt>
-<dd><p>
-            When loading a zonefile read the journal if it exists.
-          </p></dd>
-<dt><span class="term">filename</span></dt>
-<dd><p>
-            The name of the configuration file to be checked.  If not
-            specified, it defaults to <code class="filename">/etc/named.conf</code>.
-          </p></dd>
-</dl></div>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2599720"></a><h2>RETURN VALUES</h2>
-<p><span><strong class="command">named-checkconf</strong></span>
-      returns an exit status of 1 if
-      errors were detected and 0 otherwise.
-    </p>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2599734"></a><h2>SEE ALSO</h2>
-<p><span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>,
-      <span class="citerefentry"><span class="refentrytitle">named-checkzone</span>(8)</span>,
-      <em class="citetitle">BIND 9 Administrator Reference Manual</em>.
-    </p>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2599764"></a><h2>AUTHOR</h2>
-<p><span class="corpauthor">Internet Systems Consortium</span>
-    </p>
-</div>
-</div>
-<div class="navfooter">
-<hr>
-<table width="100%" summary="Navigation footer">
-<tr>
-<td width="40%" align="left">
-<a accesskey="p" href="man.dnssec-signzone.html">Prev</a> </td>
-<td width="20%" align="center"><a accesskey="u" href="Bv9ARM.ch10.html">Up</a></td>
-<td width="40%" align="right"> <a accesskey="n" href="man.named-checkzone.html">Next</a>
-</td>
-</tr>
-<tr>
-<td width="40%" align="left" valign="top">
-<span class="application">dnssec-signzone</span> </td>
-<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
-<td width="40%" align="right" valign="top"> <span class="application">named-checkzone</span>
-</td>
-</tr>
-</table>
-</div>
-</body>
-</html>
diff --git a/contrib/bind9/doc/arm/man.named-checkzone.html b/contrib/bind9/doc/arm/man.named-checkzone.html
deleted file mode 100644
index 93e17ec..0000000
--- a/contrib/bind9/doc/arm/man.named-checkzone.html
+++ /dev/null
@@ -1,294 +0,0 @@
-<!--
- - Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2000-2003 Internet Software Consortium.
- - 
- - Permission to use, copy, modify, and distribute this software for any
- - purpose with or without fee is hereby granted, provided that the above
- - copyright notice and this permission notice appear in all copies.
- - 
- - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
- - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- - PERFORMANCE OF THIS SOFTWARE.
--->
-<!-- $Id: man.named-checkzone.html,v 1.2.2.52 2007/10/31 01:35:59 marka Exp $ -->
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>named-checkzone</title>
-<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
-<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="up" href="Bv9ARM.ch10.html" title="Manual pages">
-<link rel="prev" href="man.named-checkconf.html" title="named-checkconf">
-<link rel="next" href="man.named.html" title="named">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
-<div class="navheader">
-<table width="100%" summary="Navigation header">
-<tr><th colspan="3" align="center"><span class="application">named-checkzone</span></th></tr>
-<tr>
-<td width="20%" align="left">
-<a accesskey="p" href="man.named-checkconf.html">Prev</a> </td>
-<th width="60%" align="center">Manual pages</th>
-<td width="20%" align="right"> <a accesskey="n" href="man.named.html">Next</a>
-</td>
-</tr>
-</table>
-<hr>
-</div>
-<div class="refentry" lang="en">
-<a name="man.named-checkzone"></a><div class="titlepage"></div>
-<div class="refnamediv">
-<h2>Name</h2>
-<p><span class="application">named-checkzone</span>, <span class="application">named-compilezone</span> &#8212; zone file validity checking or converting tool</p>
-</div>
-<div class="refsynopsisdiv">
-<h2>Synopsis</h2>
-<div class="cmdsynopsis"><p><code class="command">named-checkzone</code>  [<code class="option">-d</code>] [<code class="option">-j</code>] [<code class="option">-q</code>] [<code class="option">-v</code>] [<code class="option">-c <em class="replaceable"><code>class</code></em></code>] [<code class="option">-f <em class="replaceable"><code>format</code></em></code>] [<code class="option">-F <em class="replaceable"><code>format</code></em></code>] [<code class="option">-i <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-k <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-m <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-M <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-n <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-o <em class="replaceable"><code>filename</code></em></code>] [<code class="option">-s <em class="replaceable"><code>style</code></em></code>] [<code class="option">-S <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-t <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-w <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-D</code>] [<code class="option">-W <em class="replaceable"><code>mode</code></em></code>] {zonename} {filename}</p></div>
-<div class="cmdsynopsis"><p><code class="command">named-compilezone</code>  [<code class="option">-d</code>] [<code class="option">-j</code>] [<code class="option">-q</code>] [<code class="option">-v</code>] [<code class="option">-c <em class="replaceable"><code>class</code></em></code>] [<code class="option">-C <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-f <em class="replaceable"><code>format</code></em></code>] [<code class="option">-F <em class="replaceable"><code>format</code></em></code>] [<code class="option">-i <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-k <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-m <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-n <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-o <em class="replaceable"><code>filename</code></em></code>] [<code class="option">-s <em class="replaceable"><code>style</code></em></code>] [<code class="option">-t <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-w <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-D</code>] [<code class="option">-W <em class="replaceable"><code>mode</code></em></code>] {zonename} {filename}</p></div>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2600689"></a><h2>DESCRIPTION</h2>
-<p><span><strong class="command">named-checkzone</strong></span>
-      checks the syntax and integrity of a zone file.  It performs the
-      same checks as <span><strong class="command">named</strong></span> does when loading a
-      zone.  This makes <span><strong class="command">named-checkzone</strong></span> useful for
-      checking zone files before configuring them into a name server.
-    </p>
-<p>
-        <span><strong class="command">named-compilezone</strong></span> is similar to
-	<span><strong class="command">named-checkzone</strong></span>, but it always dumps the
-        zone contents to a specified file in a specified format.
-	Additionally, it applies stricter check levels by default,
-        since the dump output will be used as an actual zone file
-	loaded by <span><strong class="command">named</strong></span>.
-	When manually specified otherwise, the check levels must at
-        least be as strict as those specified in the
-	<span><strong class="command">named</strong></span> configuration file.
-     </p>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2600739"></a><h2>OPTIONS</h2>
-<div class="variablelist"><dl>
-<dt><span class="term">-d</span></dt>
-<dd><p>
-            Enable debugging.
-          </p></dd>
-<dt><span class="term">-q</span></dt>
-<dd><p>
-            Quiet mode - exit code only.
-          </p></dd>
-<dt><span class="term">-v</span></dt>
-<dd><p>
-            Print the version of the <span><strong class="command">named-checkzone</strong></span>
-            program and exit.
-          </p></dd>
-<dt><span class="term">-j</span></dt>
-<dd><p>
-            When loading the zone file read the journal if it exists.
-          </p></dd>
-<dt><span class="term">-c <em class="replaceable"><code>class</code></em></span></dt>
-<dd><p>
-            Specify the class of the zone.  If not specified "IN" is assumed.
-          </p></dd>
-<dt><span class="term">-i <em class="replaceable"><code>mode</code></em></span></dt>
-<dd>
-<p>
-	      Perform post-load zone integrity checks.  Possible modes are
-	      <span><strong class="command">"full"</strong></span> (default),
-	      <span><strong class="command">"full-sibling"</strong></span>,
-	      <span><strong class="command">"local"</strong></span>,
-	      <span><strong class="command">"local-sibling"</strong></span> and
-	      <span><strong class="command">"none"</strong></span>.
-	  </p>
-<p>
-	      Mode <span><strong class="command">"full"</strong></span> checks that MX records
-	      refer to A or AAAA record (both in-zone and out-of-zone
-	      hostnames).  Mode <span><strong class="command">"local"</strong></span> only
-	      checks MX records which refer to in-zone hostnames.
-	  </p>
-<p>
-	      Mode <span><strong class="command">"full"</strong></span> checks that SRV records
-	      refer to A or AAAA record (both in-zone and out-of-zone
-	      hostnames).  Mode <span><strong class="command">"local"</strong></span> only
-	      checks SRV records which refer to in-zone hostnames.
-	  </p>
-<p>
-	      Mode <span><strong class="command">"full"</strong></span> checks that delegation NS
-	      records refer to A or AAAA record (both in-zone and out-of-zone
-	      hostnames).  It also checks that glue address records
-	      in the zone match those advertised by the child.
-	      Mode <span><strong class="command">"local"</strong></span> only checks NS records which
-	      refer to in-zone hostnames or that some required glue exists,
-	      that is when the nameserver is in a child zone.
-	  </p>
-<p>
-	      Mode <span><strong class="command">"full-sibling"</strong></span> and
-	      <span><strong class="command">"local-sibling"</strong></span> disable sibling glue
-	      checks but are otherwise the same as <span><strong class="command">"full"</strong></span>
-	      and <span><strong class="command">"local"</strong></span> respectively.
-	  </p>
-<p>
-	      Mode <span><strong class="command">"none"</strong></span> disables the checks.
-	  </p>
-</dd>
-<dt><span class="term">-f <em class="replaceable"><code>format</code></em></span></dt>
-<dd><p>
-	    Specify the format of the zone file.
-	    Possible formats are <span><strong class="command">"text"</strong></span> (default)
-	    and <span><strong class="command">"raw"</strong></span>.
-	  </p></dd>
-<dt><span class="term">-F <em class="replaceable"><code>format</code></em></span></dt>
-<dd><p>
-	    Specify the format of the output file specified.
-	    Possible formats are <span><strong class="command">"text"</strong></span> (default)
-	    and <span><strong class="command">"raw"</strong></span>.
-	    For <span><strong class="command">named-checkzone</strong></span>,
-	    this does not cause any effects unless it dumps the zone
-	    contents.
-	  </p></dd>
-<dt><span class="term">-k <em class="replaceable"><code>mode</code></em></span></dt>
-<dd><p>
-            Perform <span><strong class="command">"check-names"</strong></span> checks with the
-	    specified failure mode.
-            Possible modes are <span><strong class="command">"fail"</strong></span>
-	    (default for <span><strong class="command">named-compilezone</strong></span>),
-            <span><strong class="command">"warn"</strong></span>
-	    (default for <span><strong class="command">named-checkzone</strong></span>) and
-            <span><strong class="command">"ignore"</strong></span>.
-          </p></dd>
-<dt><span class="term">-m <em class="replaceable"><code>mode</code></em></span></dt>
-<dd><p>
-            Specify whether MX records should be checked to see if they
-            are addresses.  Possible modes are <span><strong class="command">"fail"</strong></span>,
-            <span><strong class="command">"warn"</strong></span> (default) and
-            <span><strong class="command">"ignore"</strong></span>.
-          </p></dd>
-<dt><span class="term">-M <em class="replaceable"><code>mode</code></em></span></dt>
-<dd><p>
-	    Check if a MX record refers to a CNAME.
-            Possible modes are <span><strong class="command">"fail"</strong></span>,
-            <span><strong class="command">"warn"</strong></span> (default) and
-            <span><strong class="command">"ignore"</strong></span>.
-	  </p></dd>
-<dt><span class="term">-n <em class="replaceable"><code>mode</code></em></span></dt>
-<dd><p>
-            Specify whether NS records should be checked to see if they
-            are addresses.
-	    Possible modes are <span><strong class="command">"fail"</strong></span>
-	    (default for <span><strong class="command">named-compilezone</strong></span>),
-            <span><strong class="command">"warn"</strong></span>
-	    (default for <span><strong class="command">named-checkzone</strong></span>) and
-            <span><strong class="command">"ignore"</strong></span>.
-          </p></dd>
-<dt><span class="term">-o <em class="replaceable"><code>filename</code></em></span></dt>
-<dd><p>
-            Write zone output to <code class="filename">filename</code>.
-	    This is mandatory for <span><strong class="command">named-compilezone</strong></span>.
-          </p></dd>
-<dt><span class="term">-s <em class="replaceable"><code>style</code></em></span></dt>
-<dd><p>
-	    Specify the style of the dumped zone file.
-	    Possible styles are <span><strong class="command">"full"</strong></span> (default)
-	    and <span><strong class="command">"relative"</strong></span>.
-	    The full format is most suitable for processing
-	    automatically by a separate script.
-	    On the other hand, the relative format is more
-	    human-readable and is thus suitable for editing by hand.
-	    For <span><strong class="command">named-checkzone</strong></span>
-	    this does not cause any effects unless it dumps the zone
-	    contents.
-	    It also does not have any meaning if the output format
-	    is not text.
-	  </p></dd>
-<dt><span class="term">-S <em class="replaceable"><code>mode</code></em></span></dt>
-<dd><p>
-	    Check if a SRV record refers to a CNAME.
-            Possible modes are <span><strong class="command">"fail"</strong></span>,
-            <span><strong class="command">"warn"</strong></span> (default) and
-            <span><strong class="command">"ignore"</strong></span>.
-	  </p></dd>
-<dt><span class="term">-t <em class="replaceable"><code>directory</code></em></span></dt>
-<dd><p>
-            Chroot to <code class="filename">directory</code> so that
-            include
-            directives in the configuration file are processed as if
-            run by a similarly chrooted named.
-          </p></dd>
-<dt><span class="term">-w <em class="replaceable"><code>directory</code></em></span></dt>
-<dd><p>
-            chdir to <code class="filename">directory</code> so that
-            relative
-            filenames in master file $INCLUDE directives work.  This
-            is similar to the directory clause in
-            <code class="filename">named.conf</code>.
-          </p></dd>
-<dt><span class="term">-D</span></dt>
-<dd><p>
-            Dump zone file in canonical format.
-	    This is always enabled for <span><strong class="command">named-compilezone</strong></span>.
-          </p></dd>
-<dt><span class="term">-W <em class="replaceable"><code>mode</code></em></span></dt>
-<dd><p>
-            Specify whether to check for non-terminal wildcards.
-            Non-terminal wildcards are almost always the result of a
-            failure to understand the wildcard matching algorithm (RFC 1034).
-            Possible modes are <span><strong class="command">"warn"</strong></span> (default)
-            and
-            <span><strong class="command">"ignore"</strong></span>.
-          </p></dd>
-<dt><span class="term">zonename</span></dt>
-<dd><p>
-            The domain name of the zone being checked.
-          </p></dd>
-<dt><span class="term">filename</span></dt>
-<dd><p>
-            The name of the zone file.
-          </p></dd>
-</dl></div>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2655177"></a><h2>RETURN VALUES</h2>
-<p><span><strong class="command">named-checkzone</strong></span>
-      returns an exit status of 1 if
-      errors were detected and 0 otherwise.
-    </p>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2655191"></a><h2>SEE ALSO</h2>
-<p><span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>,
-      <span class="citerefentry"><span class="refentrytitle">named-checkconf</span>(8)</span>,
-      <em class="citetitle">RFC 1035</em>,
-      <em class="citetitle">BIND 9 Administrator Reference Manual</em>.
-    </p>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2655224"></a><h2>AUTHOR</h2>
-<p><span class="corpauthor">Internet Systems Consortium</span>
-    </p>
-</div>
-</div>
-<div class="navfooter">
-<hr>
-<table width="100%" summary="Navigation footer">
-<tr>
-<td width="40%" align="left">
-<a accesskey="p" href="man.named-checkconf.html">Prev</a> </td>
-<td width="20%" align="center"><a accesskey="u" href="Bv9ARM.ch10.html">Up</a></td>
-<td width="40%" align="right"> <a accesskey="n" href="man.named.html">Next</a>
-</td>
-</tr>
-<tr>
-<td width="40%" align="left" valign="top">
-<span class="application">named-checkconf</span> </td>
-<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
-<td width="40%" align="right" valign="top"> <span class="application">named</span>
-</td>
-</tr>
-</table>
-</div>
-</body>
-</html>
diff --git a/contrib/bind9/doc/arm/man.named.html b/contrib/bind9/doc/arm/man.named.html
deleted file mode 100644
index 70539b4..0000000
--- a/contrib/bind9/doc/arm/man.named.html
+++ /dev/null
@@ -1,293 +0,0 @@
-<!--
- - Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2000-2003 Internet Software Consortium.
- - 
- - Permission to use, copy, modify, and distribute this software for any
- - purpose with or without fee is hereby granted, provided that the above
- - copyright notice and this permission notice appear in all copies.
- - 
- - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
- - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- - PERFORMANCE OF THIS SOFTWARE.
--->
-<!-- $Id: man.named.html,v 1.2.2.53 2007/10/31 01:35:59 marka Exp $ -->
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>named</title>
-<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
-<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="up" href="Bv9ARM.ch10.html" title="Manual pages">
-<link rel="prev" href="man.named-checkzone.html" title="named-checkzone">
-<link rel="next" href="man.rndc.html" title="rndc">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
-<div class="navheader">
-<table width="100%" summary="Navigation header">
-<tr><th colspan="3" align="center"><span class="application">named</span></th></tr>
-<tr>
-<td width="20%" align="left">
-<a accesskey="p" href="man.named-checkzone.html">Prev</a> </td>
-<th width="60%" align="center">Manual pages</th>
-<td width="20%" align="right"> <a accesskey="n" href="man.rndc.html">Next</a>
-</td>
-</tr>
-</table>
-<hr>
-</div>
-<div class="refentry" lang="en">
-<a name="man.named"></a><div class="titlepage"></div>
-<div class="refnamediv">
-<h2>Name</h2>
-<p><span class="application">named</span> &#8212; Internet domain name server</p>
-</div>
-<div class="refsynopsisdiv">
-<h2>Synopsis</h2>
-<div class="cmdsynopsis"><p><code class="command">named</code>  [<code class="option">-4</code>] [<code class="option">-6</code>] [<code class="option">-c <em class="replaceable"><code>config-file</code></em></code>] [<code class="option">-d <em class="replaceable"><code>debug-level</code></em></code>] [<code class="option">-f</code>] [<code class="option">-g</code>] [<code class="option">-m <em class="replaceable"><code>flag</code></em></code>] [<code class="option">-n <em class="replaceable"><code>#cpus</code></em></code>] [<code class="option">-p <em class="replaceable"><code>port</code></em></code>] [<code class="option">-s</code>] [<code class="option">-t <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-u <em class="replaceable"><code>user</code></em></code>] [<code class="option">-v</code>] [<code class="option">-x <em class="replaceable"><code>cache-file</code></em></code>]</p></div>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2601798"></a><h2>DESCRIPTION</h2>
-<p><span><strong class="command">named</strong></span>
-      is a Domain Name System (DNS) server,
-      part of the BIND 9 distribution from ISC.  For more
-      information on the DNS, see RFCs 1033, 1034, and 1035.
-    </p>
-<p>
-      When invoked without arguments, <span><strong class="command">named</strong></span>
-      will
-      read the default configuration file
-      <code class="filename">/etc/named.conf</code>, read any initial
-      data, and listen for queries.
-    </p>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2601829"></a><h2>OPTIONS</h2>
-<div class="variablelist"><dl>
-<dt><span class="term">-4</span></dt>
-<dd><p>
-            Use IPv4 only even if the host machine is capable of IPv6.
-            <code class="option">-4</code> and <code class="option">-6</code> are mutually
-            exclusive.
-          </p></dd>
-<dt><span class="term">-6</span></dt>
-<dd><p>
-            Use IPv6 only even if the host machine is capable of IPv4.
-            <code class="option">-4</code> and <code class="option">-6</code> are mutually
-            exclusive.
-          </p></dd>
-<dt><span class="term">-c <em class="replaceable"><code>config-file</code></em></span></dt>
-<dd><p>
-            Use <em class="replaceable"><code>config-file</code></em> as the
-            configuration file instead of the default,
-            <code class="filename">/etc/named.conf</code>.  To
-            ensure that reloading the configuration file continues
-            to work after the server has changed its working
-            directory due to to a possible
-            <code class="option">directory</code> option in the configuration
-            file, <em class="replaceable"><code>config-file</code></em> should be
-            an absolute pathname.
-          </p></dd>
-<dt><span class="term">-d <em class="replaceable"><code>debug-level</code></em></span></dt>
-<dd><p>
-            Set the daemon's debug level to <em class="replaceable"><code>debug-level</code></em>.
-            Debugging traces from <span><strong class="command">named</strong></span> become
-            more verbose as the debug level increases.
-          </p></dd>
-<dt><span class="term">-f</span></dt>
-<dd><p>
-            Run the server in the foreground (i.e. do not daemonize).
-          </p></dd>
-<dt><span class="term">-g</span></dt>
-<dd><p>
-            Run the server in the foreground and force all logging
-            to <code class="filename">stderr</code>.
-          </p></dd>
-<dt><span class="term">-m <em class="replaceable"><code>flag</code></em></span></dt>
-<dd><p>
-	    Turn on memory usage debugging flags.  Possible flags are
-	    <em class="replaceable"><code>usage</code></em>,
-	    <em class="replaceable"><code>trace</code></em>,
-	    <em class="replaceable"><code>record</code></em>,
-	    <em class="replaceable"><code>size</code></em>, and
-	    <em class="replaceable"><code>mctx</code></em>.
-	    These correspond to the ISC_MEM_DEBUGXXXX flags described in
-	    <code class="filename">&lt;isc/mem.h&gt;</code>.
-          </p></dd>
-<dt><span class="term">-n <em class="replaceable"><code>#cpus</code></em></span></dt>
-<dd><p>
-            Create <em class="replaceable"><code>#cpus</code></em> worker threads
-            to take advantage of multiple CPUs.  If not specified,
-            <span><strong class="command">named</strong></span> will try to determine the
-            number of CPUs present and create one thread per CPU.
-            If it is unable to determine the number of CPUs, a
-            single worker thread will be created.
-          </p></dd>
-<dt><span class="term">-p <em class="replaceable"><code>port</code></em></span></dt>
-<dd><p>
-            Listen for queries on port <em class="replaceable"><code>port</code></em>.  If not
-            specified, the default is port 53.
-          </p></dd>
-<dt><span class="term">-s</span></dt>
-<dd>
-<p>
-            Write memory usage statistics to <code class="filename">stdout</code> on exit.
-          </p>
-<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-<p>
-              This option is mainly of interest to BIND 9 developers
-              and may be removed or changed in a future release.
-            </p>
-</div>
-</dd>
-<dt><span class="term">-t <em class="replaceable"><code>directory</code></em></span></dt>
-<dd>
-<p>Chroot
-	    to <em class="replaceable"><code>directory</code></em> after
-            processing the command line arguments, but before
-            reading the configuration file.
-          </p>
-<div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Warning</h3>
-<p>
-              This option should be used in conjunction with the
-              <code class="option">-u</code> option, as chrooting a process
-              running as root doesn't enhance security on most
-              systems; the way <code class="function">chroot(2)</code> is
-              defined allows a process with root privileges to
-              escape a chroot jail.
-            </p>
-</div>
-</dd>
-<dt><span class="term">-u <em class="replaceable"><code>user</code></em></span></dt>
-<dd>
-<p>Setuid
-	    to <em class="replaceable"><code>user</code></em> after completing
-            privileged operations, such as creating sockets that
-            listen on privileged ports.
-          </p>
-<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-<p>
-              On Linux, <span><strong class="command">named</strong></span> uses the kernel's
-              		capability mechanism to drop all root privileges
-              except the ability to <code class="function">bind(2)</code> to
-              a
-              privileged port and set process resource limits.
-              Unfortunately, this means that the <code class="option">-u</code>
-              option only works when <span><strong class="command">named</strong></span> is
-              run
-              on kernel 2.2.18 or later, or kernel 2.3.99-pre3 or
-              later, since previous kernels did not allow privileges
-              to be retained after <code class="function">setuid(2)</code>.
-            </p>
-</div>
-</dd>
-<dt><span class="term">-v</span></dt>
-<dd><p>
-            Report the version number and exit.
-          </p></dd>
-<dt><span class="term">-x <em class="replaceable"><code>cache-file</code></em></span></dt>
-<dd>
-<p>
-            Load data from <em class="replaceable"><code>cache-file</code></em> into the
-            cache of the default view.
-          </p>
-<div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Warning</h3>
-<p>
-              This option must not be used.  It is only of interest
-              to BIND 9 developers and may be removed or changed in a
-              future release.
-            </p>
-</div>
-</dd>
-</dl></div>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2604492"></a><h2>SIGNALS</h2>
-<p>
-      In routine operation, signals should not be used to control
-      the nameserver; <span><strong class="command">rndc</strong></span> should be used
-      instead.
-    </p>
-<div class="variablelist"><dl>
-<dt><span class="term">SIGHUP</span></dt>
-<dd><p>
-            Force a reload of the server.
-          </p></dd>
-<dt><span class="term">SIGINT, SIGTERM</span></dt>
-<dd><p>
-            Shut down the server.
-          </p></dd>
-</dl></div>
-<p>
-      The result of sending any other signals to the server is undefined.
-    </p>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2604542"></a><h2>CONFIGURATION</h2>
-<p>
-      The <span><strong class="command">named</strong></span> configuration file is too complex
-      to describe in detail here.  A complete description is provided
-      in the
-      <em class="citetitle">BIND 9 Administrator Reference Manual</em>.
-    </p>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2604562"></a><h2>FILES</h2>
-<div class="variablelist"><dl>
-<dt><span class="term"><code class="filename">/etc/named.conf</code></span></dt>
-<dd><p>
-            The default configuration file.
-          </p></dd>
-<dt><span class="term"><code class="filename">/var/run/named.pid</code></span></dt>
-<dd><p>
-            The default process-id file.
-          </p></dd>
-</dl></div>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2604605"></a><h2>SEE ALSO</h2>
-<p><em class="citetitle">RFC 1033</em>,
-      <em class="citetitle">RFC 1034</em>,
-      <em class="citetitle">RFC 1035</em>,
-      <span class="citerefentry"><span class="refentrytitle">named-checkconf</span>(8)</span>,
-      <span class="citerefentry"><span class="refentrytitle">named-checkzone</span>(8)</span>,
-      <span class="citerefentry"><span class="refentrytitle">rndc</span>(8)</span>,
-      <span class="citerefentry"><span class="refentrytitle">lwresd</span>(8)</span>,
-      <span class="citerefentry"><span class="refentrytitle">named.conf</span>(5)</span>,
-      <em class="citetitle">BIND 9 Administrator Reference Manual</em>.
-    </p>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2604881"></a><h2>AUTHOR</h2>
-<p><span class="corpauthor">Internet Systems Consortium</span>
-    </p>
-</div>
-</div>
-<div class="navfooter">
-<hr>
-<table width="100%" summary="Navigation footer">
-<tr>
-<td width="40%" align="left">
-<a accesskey="p" href="man.named-checkzone.html">Prev</a> </td>
-<td width="20%" align="center"><a accesskey="u" href="Bv9ARM.ch10.html">Up</a></td>
-<td width="40%" align="right"> <a accesskey="n" href="man.rndc.html">Next</a>
-</td>
-</tr>
-<tr>
-<td width="40%" align="left" valign="top">
-<span class="application">named-checkzone</span> </td>
-<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
-<td width="40%" align="right" valign="top"> <span class="application">rndc</span>
-</td>
-</tr>
-</table>
-</div>
-</body>
-</html>
diff --git a/contrib/bind9/doc/arm/man.rndc-confgen.html b/contrib/bind9/doc/arm/man.rndc-confgen.html
deleted file mode 100644
index 056bcbd..0000000
--- a/contrib/bind9/doc/arm/man.rndc-confgen.html
+++ /dev/null
@@ -1,222 +0,0 @@
-<!--
- - Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2000-2003 Internet Software Consortium.
- - 
- - Permission to use, copy, modify, and distribute this software for any
- - purpose with or without fee is hereby granted, provided that the above
- - copyright notice and this permission notice appear in all copies.
- - 
- - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
- - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- - PERFORMANCE OF THIS SOFTWARE.
--->
-<!-- $Id: man.rndc-confgen.html,v 1.2.2.55 2007/10/31 01:35:59 marka Exp $ -->
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>rndc-confgen</title>
-<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
-<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="up" href="Bv9ARM.ch10.html" title="Manual pages">
-<link rel="prev" href="man.rndc.conf.html" title="rndc.conf">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
-<div class="navheader">
-<table width="100%" summary="Navigation header">
-<tr><th colspan="3" align="center"><span class="application">rndc-confgen</span></th></tr>
-<tr>
-<td width="20%" align="left">
-<a accesskey="p" href="man.rndc.conf.html">Prev</a> </td>
-<th width="60%" align="center">Manual pages</th>
-<td width="20%" align="right"> </td>
-</tr>
-</table>
-<hr>
-</div>
-<div class="refentry" lang="en">
-<a name="man.rndc-confgen"></a><div class="titlepage"></div>
-<div class="refnamediv">
-<h2>Name</h2>
-<p><span class="application">rndc-confgen</span> &#8212; rndc key generation tool</p>
-</div>
-<div class="refsynopsisdiv">
-<h2>Synopsis</h2>
-<div class="cmdsynopsis"><p><code class="command">rndc-confgen</code>  [<code class="option">-a</code>] [<code class="option">-b <em class="replaceable"><code>keysize</code></em></code>] [<code class="option">-c <em class="replaceable"><code>keyfile</code></em></code>] [<code class="option">-h</code>] [<code class="option">-k <em class="replaceable"><code>keyname</code></em></code>] [<code class="option">-p <em class="replaceable"><code>port</code></em></code>] [<code class="option">-r <em class="replaceable"><code>randomfile</code></em></code>] [<code class="option">-s <em class="replaceable"><code>address</code></em></code>] [<code class="option">-t <em class="replaceable"><code>chrootdir</code></em></code>] [<code class="option">-u <em class="replaceable"><code>user</code></em></code>]</p></div>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2605524"></a><h2>DESCRIPTION</h2>
-<p><span><strong class="command">rndc-confgen</strong></span>
-      generates configuration files
-      for <span><strong class="command">rndc</strong></span>.  It can be used as a
-      convenient alternative to writing the
-      <code class="filename">rndc.conf</code> file
-      and the corresponding <span><strong class="command">controls</strong></span>
-      and <span><strong class="command">key</strong></span>
-      statements in <code class="filename">named.conf</code> by hand.
-      Alternatively, it can be run with the <span><strong class="command">-a</strong></span>
-      option to set up a <code class="filename">rndc.key</code> file and
-      avoid the need for a <code class="filename">rndc.conf</code> file
-      and a <span><strong class="command">controls</strong></span> statement altogether.
-    </p>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2605590"></a><h2>OPTIONS</h2>
-<div class="variablelist"><dl>
-<dt><span class="term">-a</span></dt>
-<dd>
-<p>
-            Do automatic <span><strong class="command">rndc</strong></span> configuration.
-            This creates a file <code class="filename">rndc.key</code>
-            in <code class="filename">/etc</code> (or whatever
-            <code class="varname">sysconfdir</code>
-            was specified as when <acronym class="acronym">BIND</acronym> was
-            built)
-            that is read by both <span><strong class="command">rndc</strong></span>
-            and <span><strong class="command">named</strong></span> on startup.  The
-            <code class="filename">rndc.key</code> file defines a default
-            command channel and authentication key allowing
-            <span><strong class="command">rndc</strong></span> to communicate with
-            <span><strong class="command">named</strong></span> on the local host
-            with no further configuration.
-          </p>
-<p>
-            Running <span><strong class="command">rndc-confgen -a</strong></span> allows
-            BIND 9 and <span><strong class="command">rndc</strong></span> to be used as
-            drop-in
-            replacements for BIND 8 and <span><strong class="command">ndc</strong></span>,
-            with no changes to the existing BIND 8
-            <code class="filename">named.conf</code> file.
-          </p>
-<p>
-            If a more elaborate configuration than that
-            generated by <span><strong class="command">rndc-confgen -a</strong></span>
-            is required, for example if rndc is to be used remotely,
-            you should run <span><strong class="command">rndc-confgen</strong></span> without
-            the
-            <span><strong class="command">-a</strong></span> option and set up a
-            <code class="filename">rndc.conf</code> and
-            <code class="filename">named.conf</code>
-            as directed.
-          </p>
-</dd>
-<dt><span class="term">-b <em class="replaceable"><code>keysize</code></em></span></dt>
-<dd><p>
-            Specifies the size of the authentication key in bits.
-            Must be between 1 and 512 bits; the default is 128.
-          </p></dd>
-<dt><span class="term">-c <em class="replaceable"><code>keyfile</code></em></span></dt>
-<dd><p>
-            Used with the <span><strong class="command">-a</strong></span> option to specify
-            an alternate location for <code class="filename">rndc.key</code>.
-          </p></dd>
-<dt><span class="term">-h</span></dt>
-<dd><p>
-            Prints a short summary of the options and arguments to
-            <span><strong class="command">rndc-confgen</strong></span>.
-          </p></dd>
-<dt><span class="term">-k <em class="replaceable"><code>keyname</code></em></span></dt>
-<dd><p>
-            Specifies the key name of the rndc authentication key.
-            This must be a valid domain name.
-            The default is <code class="constant">rndc-key</code>.
-          </p></dd>
-<dt><span class="term">-p <em class="replaceable"><code>port</code></em></span></dt>
-<dd><p>
-            Specifies the command channel port where <span><strong class="command">named</strong></span>
-            listens for connections from <span><strong class="command">rndc</strong></span>.
-            The default is 953.
-          </p></dd>
-<dt><span class="term">-r <em class="replaceable"><code>randomfile</code></em></span></dt>
-<dd><p>
-            Specifies a source of random data for generating the
-            authorization.  If the operating
-            system does not provide a <code class="filename">/dev/random</code>
-            or equivalent device, the default source of randomness
-            is keyboard input.  <code class="filename">randomdev</code>
-            specifies
-            the name of a character device or file containing random
-            data to be used instead of the default.  The special value
-            <code class="filename">keyboard</code> indicates that keyboard
-            input should be used.
-          </p></dd>
-<dt><span class="term">-s <em class="replaceable"><code>address</code></em></span></dt>
-<dd><p>
-            Specifies the IP address where <span><strong class="command">named</strong></span>
-            listens for command channel connections from
-            <span><strong class="command">rndc</strong></span>.  The default is the loopback
-            address 127.0.0.1.
-          </p></dd>
-<dt><span class="term">-t <em class="replaceable"><code>chrootdir</code></em></span></dt>
-<dd><p>
-            Used with the <span><strong class="command">-a</strong></span> option to specify
-            a directory where <span><strong class="command">named</strong></span> will run
-            chrooted.  An additional copy of the <code class="filename">rndc.key</code>
-            will be written relative to this directory so that
-            it will be found by the chrooted <span><strong class="command">named</strong></span>.
-          </p></dd>
-<dt><span class="term">-u <em class="replaceable"><code>user</code></em></span></dt>
-<dd><p>
-            Used with the <span><strong class="command">-a</strong></span> option to set the
-            owner
-            of the <code class="filename">rndc.key</code> file generated.
-            If
-            <span><strong class="command">-t</strong></span> is also specified only the file
-            in
-            the chroot area has its owner changed.
-          </p></dd>
-</dl></div>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2606454"></a><h2>EXAMPLES</h2>
-<p>
-      To allow <span><strong class="command">rndc</strong></span> to be used with
-      no manual configuration, run
-    </p>
-<p><strong class="userinput"><code>rndc-confgen -a</code></strong>
-    </p>
-<p>
-      To print a sample <code class="filename">rndc.conf</code> file and
-      corresponding <span><strong class="command">controls</strong></span> and <span><strong class="command">key</strong></span>
-      statements to be manually inserted into <code class="filename">named.conf</code>,
-      run
-    </p>
-<p><strong class="userinput"><code>rndc-confgen</code></strong>
-    </p>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2609036"></a><h2>SEE ALSO</h2>
-<p><span class="citerefentry"><span class="refentrytitle">rndc</span>(8)</span>,
-      <span class="citerefentry"><span class="refentrytitle">rndc.conf</span>(5)</span>,
-      <span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>,
-      <em class="citetitle">BIND 9 Administrator Reference Manual</em>.
-    </p>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2609075"></a><h2>AUTHOR</h2>
-<p><span class="corpauthor">Internet Systems Consortium</span>
-    </p>
-</div>
-</div>
-<div class="navfooter">
-<hr>
-<table width="100%" summary="Navigation footer">
-<tr>
-<td width="40%" align="left">
-<a accesskey="p" href="man.rndc.conf.html">Prev</a> </td>
-<td width="20%" align="center"><a accesskey="u" href="Bv9ARM.ch10.html">Up</a></td>
-<td width="40%" align="right"> </td>
-</tr>
-<tr>
-<td width="40%" align="left" valign="top">
-<code class="filename">rndc.conf</code> </td>
-<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
-<td width="40%" align="right" valign="top"> </td>
-</tr>
-</table>
-</div>
-</body>
-</html>
diff --git a/contrib/bind9/doc/arm/man.rndc.conf.html b/contrib/bind9/doc/arm/man.rndc.conf.html
deleted file mode 100644
index 4e8154c..0000000
--- a/contrib/bind9/doc/arm/man.rndc.conf.html
+++ /dev/null
@@ -1,255 +0,0 @@
-<!--
- - Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2000-2003 Internet Software Consortium.
- - 
- - Permission to use, copy, modify, and distribute this software for any
- - purpose with or without fee is hereby granted, provided that the above
- - copyright notice and this permission notice appear in all copies.
- - 
- - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
- - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- - PERFORMANCE OF THIS SOFTWARE.
--->
-<!-- $Id: man.rndc.conf.html,v 1.2.2.55 2007/10/31 01:35:59 marka Exp $ -->
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>rndc.conf</title>
-<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
-<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="up" href="Bv9ARM.ch10.html" title="Manual pages">
-<link rel="prev" href="man.rndc.html" title="rndc">
-<link rel="next" href="man.rndc-confgen.html" title="rndc-confgen">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
-<div class="navheader">
-<table width="100%" summary="Navigation header">
-<tr><th colspan="3" align="center"><code class="filename">rndc.conf</code></th></tr>
-<tr>
-<td width="20%" align="left">
-<a accesskey="p" href="man.rndc.html">Prev</a> </td>
-<th width="60%" align="center">Manual pages</th>
-<td width="20%" align="right"> <a accesskey="n" href="man.rndc-confgen.html">Next</a>
-</td>
-</tr>
-</table>
-<hr>
-</div>
-<div class="refentry" lang="en">
-<a name="man.rndc.conf"></a><div class="titlepage"></div>
-<div class="refnamediv">
-<h2>Name</h2>
-<p><code class="filename">rndc.conf</code> &#8212; rndc configuration file</p>
-</div>
-<div class="refsynopsisdiv">
-<h2>Synopsis</h2>
-<div class="cmdsynopsis"><p><code class="command">rndc.conf</code> </p></div>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2603676"></a><h2>DESCRIPTION</h2>
-<p><code class="filename">rndc.conf</code> is the configuration file
-      for <span><strong class="command">rndc</strong></span>, the BIND 9 name server control
-      utility.  This file has a similar structure and syntax to
-      <code class="filename">named.conf</code>.  Statements are enclosed
-      in braces and terminated with a semi-colon.  Clauses in
-      the statements are also semi-colon terminated.  The usual
-      comment styles are supported:
-    </p>
-<p>
-      C style: /* */
-    </p>
-<p>
-      C++ style: // to end of line
-    </p>
-<p>
-      Unix style: # to end of line
-    </p>
-<p><code class="filename">rndc.conf</code> is much simpler than
-      <code class="filename">named.conf</code>.  The file uses three
-      statements: an options statement, a server statement
-      and a key statement.
-    </p>
-<p>
-      The <code class="option">options</code> statement contains five clauses.
-      The <code class="option">default-server</code> clause is followed by the
-      name or address of a name server.  This host will be used when
-      no name server is given as an argument to
-      <span><strong class="command">rndc</strong></span>.  The <code class="option">default-key</code>
-      clause is followed by the name of a key which is identified by
-      a <code class="option">key</code> statement.  If no
-      <code class="option">keyid</code> is provided on the rndc command line,
-      and no <code class="option">key</code> clause is found in a matching
-      <code class="option">server</code> statement, this default key will be
-      used to authenticate the server's commands and responses.  The
-      <code class="option">default-port</code> clause is followed by the port
-      to connect to on the remote name server.  If no
-      <code class="option">port</code> option is provided on the rndc command
-      line, and no <code class="option">port</code> clause is found in a
-      matching <code class="option">server</code> statement, this default port
-      will be used to connect.
-      The <code class="option">default-source-address</code> and
-      <code class="option">default-source-address-v6</code> clauses which
-      can be used to set the IPv4 and IPv6 source addresses
-      respectively.
-    </p>
-<p>
-      After the <code class="option">server</code> keyword, the server
-      statement includes a string which is the hostname or address
-      for a name server.  The statement has three possible clauses:
-      <code class="option">key</code>, <code class="option">port</code> and
-      <code class="option">addresses</code>. The key name must match the
-      name of a key statement in the file.  The port number
-      specifies the port to connect to.  If an <code class="option">addresses</code>
-      clause is supplied these addresses will be used instead of
-      the server name.  Each address can take an optional port.
-      If an <code class="option">source-address</code> or <code class="option">source-address-v6</code>
-      of supplied then these will be used to specify the IPv4 and IPv6
-      source addresses respectively.
-    </p>
-<p>
-      The <code class="option">key</code> statement begins with an identifying
-      string, the name of the key.  The statement has two clauses.
-      <code class="option">algorithm</code> identifies the encryption algorithm
-      for <span><strong class="command">rndc</strong></span> to use; currently only HMAC-MD5
-      is
-      supported.  This is followed by a secret clause which contains
-      the base-64 encoding of the algorithm's encryption key.  The
-      base-64 string is enclosed in double quotes.
-    </p>
-<p>
-      There are two common ways to generate the base-64 string for the
-      secret.  The BIND 9 program <span><strong class="command">rndc-confgen</strong></span>
-      can
-      be used to generate a random key, or the
-      <span><strong class="command">mmencode</strong></span> program, also known as
-      <span><strong class="command">mimencode</strong></span>, can be used to generate a
-      base-64
-      string from known input.  <span><strong class="command">mmencode</strong></span> does
-      not
-      ship with BIND 9 but is available on many systems.  See the
-      EXAMPLE section for sample command lines for each.
-    </p>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2604121"></a><h2>EXAMPLE</h2>
-<pre class="programlisting">
-      options {
-        default-server  localhost;
-        default-key     samplekey;
-      };
-</pre>
-<p>
-    </p>
-<pre class="programlisting">
-      server localhost {
-        key             samplekey;
-      };
-</pre>
-<p>
-    </p>
-<pre class="programlisting">
-      server testserver {
-        key		testkey;
-        addresses	{ localhost port 5353; };
-      };
-</pre>
-<p>
-    </p>
-<pre class="programlisting">
-      key samplekey {
-        algorithm       hmac-md5;
-        secret          "6FMfj43Osz4lyb24OIe2iGEz9lf1llJO+lz";
-      };
-</pre>
-<p>
-    </p>
-<pre class="programlisting">
-      key testkey {
-        algorithm	hmac-md5;
-        secret		"R3HI8P6BKw9ZwXwN3VZKuQ==";
-      };
-    </pre>
-<p>
-    </p>
-<p>
-      In the above example, <span><strong class="command">rndc</strong></span> will by
-      default use
-      the server at localhost (127.0.0.1) and the key called samplekey.
-      Commands to the localhost server will use the samplekey key, which
-      must also be defined in the server's configuration file with the
-      same name and secret.  The key statement indicates that samplekey
-      uses the HMAC-MD5 algorithm and its secret clause contains the
-      base-64 encoding of the HMAC-MD5 secret enclosed in double quotes.
-    </p>
-<p>
-      If <span><strong class="command">rndc -s testserver</strong></span> is used then <span><strong class="command">rndc</strong></span> will
-      connect to server on localhost port 5353 using the key testkey.
-    </p>
-<p>
-      To generate a random secret with <span><strong class="command">rndc-confgen</strong></span>:
-    </p>
-<p><strong class="userinput"><code>rndc-confgen</code></strong>
-    </p>
-<p>
-      A complete <code class="filename">rndc.conf</code> file, including
-      the
-      randomly generated key, will be written to the standard
-      output.  Commented-out <code class="option">key</code> and
-      <code class="option">controls</code> statements for
-      <code class="filename">named.conf</code> are also printed.
-    </p>
-<p>
-      To generate a base-64 secret with <span><strong class="command">mmencode</strong></span>:
-    </p>
-<p><strong class="userinput"><code>echo "known plaintext for a secret" | mmencode</code></strong>
-    </p>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2604994"></a><h2>NAME SERVER CONFIGURATION</h2>
-<p>
-      The name server must be configured to accept rndc connections and
-      to recognize the key specified in the <code class="filename">rndc.conf</code>
-      file, using the controls statement in <code class="filename">named.conf</code>.
-      See the sections on the <code class="option">controls</code> statement in the
-      BIND 9 Administrator Reference Manual for details.
-    </p>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2605019"></a><h2>SEE ALSO</h2>
-<p><span class="citerefentry"><span class="refentrytitle">rndc</span>(8)</span>,
-      <span class="citerefentry"><span class="refentrytitle">rndc-confgen</span>(8)</span>,
-      <span class="citerefentry"><span class="refentrytitle">mmencode</span>(1)</span>,
-      <em class="citetitle">BIND 9 Administrator Reference Manual</em>.
-    </p>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2605058"></a><h2>AUTHOR</h2>
-<p><span class="corpauthor">Internet Systems Consortium</span>
-    </p>
-</div>
-</div>
-<div class="navfooter">
-<hr>
-<table width="100%" summary="Navigation footer">
-<tr>
-<td width="40%" align="left">
-<a accesskey="p" href="man.rndc.html">Prev</a> </td>
-<td width="20%" align="center"><a accesskey="u" href="Bv9ARM.ch10.html">Up</a></td>
-<td width="40%" align="right"> <a accesskey="n" href="man.rndc-confgen.html">Next</a>
-</td>
-</tr>
-<tr>
-<td width="40%" align="left" valign="top">
-<span class="application">rndc</span> </td>
-<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
-<td width="40%" align="right" valign="top"> <span class="application">rndc-confgen</span>
-</td>
-</tr>
-</table>
-</div>
-</body>
-</html>
diff --git a/contrib/bind9/doc/arm/man.rndc.html b/contrib/bind9/doc/arm/man.rndc.html
deleted file mode 100644
index 96ed547..0000000
--- a/contrib/bind9/doc/arm/man.rndc.html
+++ /dev/null
@@ -1,202 +0,0 @@
-<!--
- - Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2000-2003 Internet Software Consortium.
- - 
- - Permission to use, copy, modify, and distribute this software for any
- - purpose with or without fee is hereby granted, provided that the above
- - copyright notice and this permission notice appear in all copies.
- - 
- - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
- - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- - PERFORMANCE OF THIS SOFTWARE.
--->
-<!-- $Id: man.rndc.html,v 1.2.2.54 2007/10/31 01:35:59 marka Exp $ -->
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>rndc</title>
-<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
-<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
-<link rel="up" href="Bv9ARM.ch10.html" title="Manual pages">
-<link rel="prev" href="man.named.html" title="named">
-<link rel="next" href="man.rndc.conf.html" title="rndc.conf">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
-<div class="navheader">
-<table width="100%" summary="Navigation header">
-<tr><th colspan="3" align="center"><span class="application">rndc</span></th></tr>
-<tr>
-<td width="20%" align="left">
-<a accesskey="p" href="man.named.html">Prev</a> </td>
-<th width="60%" align="center">Manual pages</th>
-<td width="20%" align="right"> <a accesskey="n" href="man.rndc.conf.html">Next</a>
-</td>
-</tr>
-</table>
-<hr>
-</div>
-<div class="refentry" lang="en">
-<a name="man.rndc"></a><div class="titlepage"></div>
-<div class="refnamediv">
-<h2>Name</h2>
-<p><span class="application">rndc</span> &#8212; name server control utility</p>
-</div>
-<div class="refsynopsisdiv">
-<h2>Synopsis</h2>
-<div class="cmdsynopsis"><p><code class="command">rndc</code>  [<code class="option">-b <em class="replaceable"><code>source-address</code></em></code>] [<code class="option">-c <em class="replaceable"><code>config-file</code></em></code>] [<code class="option">-k <em class="replaceable"><code>key-file</code></em></code>] [<code class="option">-s <em class="replaceable"><code>server</code></em></code>] [<code class="option">-p <em class="replaceable"><code>port</code></em></code>] [<code class="option">-V</code>] [<code class="option">-y <em class="replaceable"><code>key_id</code></em></code>] {command}</p></div>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2603169"></a><h2>DESCRIPTION</h2>
-<p><span><strong class="command">rndc</strong></span>
-      controls the operation of a name
-      server.  It supersedes the <span><strong class="command">ndc</strong></span> utility
-      that was provided in old BIND releases.  If
-      <span><strong class="command">rndc</strong></span> is invoked with no command line
-      options or arguments, it prints a short summary of the
-      supported commands and the available options and their
-      arguments.
-    </p>
-<p><span><strong class="command">rndc</strong></span>
-      communicates with the name server
-      over a TCP connection, sending commands authenticated with
-      digital signatures.  In the current versions of
-      <span><strong class="command">rndc</strong></span> and <span><strong class="command">named</strong></span>,
-      the only supported authentication algorithm is HMAC-MD5,
-      which uses a shared secret on each end of the connection.
-      This provides TSIG-style authentication for the command
-      request and the name server's response.  All commands sent
-      over the channel must be signed by a key_id known to the
-      server.
-    </p>
-<p><span><strong class="command">rndc</strong></span>
-      reads a configuration file to
-      determine how to contact the name server and decide what
-      algorithm and key it should use.
-    </p>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2603219"></a><h2>OPTIONS</h2>
-<div class="variablelist"><dl>
-<dt><span class="term">-b <em class="replaceable"><code>source-address</code></em></span></dt>
-<dd><p>
-            Use <em class="replaceable"><code>source-address</code></em>
-            as the source address for the connection to the server.
-            Multiple instances are permitted to allow setting of both
-            the IPv4 and IPv6 source addresses.
-          </p></dd>
-<dt><span class="term">-c <em class="replaceable"><code>config-file</code></em></span></dt>
-<dd><p>
-            Use <em class="replaceable"><code>config-file</code></em>
-            as the configuration file instead of the default,
-            <code class="filename">/etc/rndc.conf</code>.
-          </p></dd>
-<dt><span class="term">-k <em class="replaceable"><code>key-file</code></em></span></dt>
-<dd><p>
-            Use <em class="replaceable"><code>key-file</code></em>
-            as the key file instead of the default,
-            <code class="filename">/etc/rndc.key</code>.  The key in
-            <code class="filename">/etc/rndc.key</code> will be used to
-            authenticate
-            commands sent to the server if the <em class="replaceable"><code>config-file</code></em>
-            does not exist.
-          </p></dd>
-<dt><span class="term">-s <em class="replaceable"><code>server</code></em></span></dt>
-<dd><p><em class="replaceable"><code>server</code></em> is
-            the name or address of the server which matches a
-            server statement in the configuration file for
-            <span><strong class="command">rndc</strong></span>.  If no server is supplied on the
-            command line, the host named by the default-server clause
-            in the options statement of the <span><strong class="command">rndc</strong></span>
-	    configuration file will be used.
-          </p></dd>
-<dt><span class="term">-p <em class="replaceable"><code>port</code></em></span></dt>
-<dd><p>
-            Send commands to TCP port
-            <em class="replaceable"><code>port</code></em>
-            instead
-            of BIND 9's default control channel port, 953.
-          </p></dd>
-<dt><span class="term">-V</span></dt>
-<dd><p>
-            Enable verbose logging.
-          </p></dd>
-<dt><span class="term">-y <em class="replaceable"><code>key_id</code></em></span></dt>
-<dd><p>
-            Use the key <em class="replaceable"><code>key_id</code></em>
-            from the configuration file.
-            <em class="replaceable"><code>key_id</code></em>
-            must be
-            known by named with the same algorithm and secret string
-            in order for control message validation to succeed.
-            If no <em class="replaceable"><code>key_id</code></em>
-            is specified, <span><strong class="command">rndc</strong></span> will first look
-            for a key clause in the server statement of the server
-            being used, or if no server statement is present for that
-            host, then the default-key clause of the options statement.
-            Note that the configuration file contains shared secrets
-            which are used to send authenticated control commands
-            to name servers.  It should therefore not have general read
-            or write access.
-          </p></dd>
-</dl></div>
-<p>
-      For the complete set of commands supported by <span><strong class="command">rndc</strong></span>,
-      see the BIND 9 Administrator Reference Manual or run
-      <span><strong class="command">rndc</strong></span> without arguments to see its help
-      message.
-    </p>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2603512"></a><h2>LIMITATIONS</h2>
-<p><span><strong class="command">rndc</strong></span>
-      does not yet support all the commands of
-      the BIND 8 <span><strong class="command">ndc</strong></span> utility.
-    </p>
-<p>
-      There is currently no way to provide the shared secret for a
-      <code class="option">key_id</code> without using the configuration file.
-    </p>
-<p>
-      Several error messages could be clearer.
-    </p>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2603543"></a><h2>SEE ALSO</h2>
-<p><span class="citerefentry"><span class="refentrytitle">rndc.conf</span>(5)</span>,
-      <span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>,
-      <span class="citerefentry"><span class="refentrytitle">named.conf</span>(5)</span>,
-      <span class="citerefentry"><span class="refentrytitle">ndc</span>(8)</span>,
-      <em class="citetitle">BIND 9 Administrator Reference Manual</em>.
-    </p>
-</div>
-<div class="refsect1" lang="en">
-<a name="id2603590"></a><h2>AUTHOR</h2>
-<p><span class="corpauthor">Internet Systems Consortium</span>
-    </p>
-</div>
-</div>
-<div class="navfooter">
-<hr>
-<table width="100%" summary="Navigation footer">
-<tr>
-<td width="40%" align="left">
-<a accesskey="p" href="man.named.html">Prev</a> </td>
-<td width="20%" align="center"><a accesskey="u" href="Bv9ARM.ch10.html">Up</a></td>
-<td width="40%" align="right"> <a accesskey="n" href="man.rndc.conf.html">Next</a>
-</td>
-</tr>
-<tr>
-<td width="40%" align="left" valign="top">
-<span class="application">named</span> </td>
-<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
-<td width="40%" align="right" valign="top"> <code class="filename">rndc.conf</code>
-</td>
-</tr>
-</table>
-</div>
-</body>
-</html>
diff --git a/contrib/bind9/doc/draft/draft-baba-dnsext-acl-reqts-01.txt b/contrib/bind9/doc/draft/draft-baba-dnsext-acl-reqts-01.txt
deleted file mode 100644
index 1030e57..0000000
--- a/contrib/bind9/doc/draft/draft-baba-dnsext-acl-reqts-01.txt
+++ /dev/null
@@ -1,336 +0,0 @@
-
-
-
-
-Internet-Draft                                                   T. Baba
-Expires: March 11, 2004                                         NTT Data
-                                                      September 11, 2003
-
-
-         Requirements for Access Control in Domain Name Systems
-                   draft-baba-dnsext-acl-reqts-01.txt
-
-Status of this Memo
-
-   This document is an Internet-Draft and is subject to all provisions
-   of Section 10 of RFC2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/1id-abstracts.html
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-   Distribution of this memo is unlimited.
-
-   This Internet-Draft will expire on March 11, 2004.
-
-Abstract
-
-   This document describes the requirements for access control
-   mechanisms in the Domain Name System (DNS), which authenticate
-   clients and then allow or deny access to resource records in the
-   zone according to the access control list (ACL).
-
-1. Introduction
-
-   The Domain Name System (DNS) is a hierarchical, distributed, highly
-   available database used for bi-directional mapping between domain
-   names and IP addresses, for email routing, and for other information
-   [RFC1034, 1035].  DNS security extensions (DNSSEC) have been defined
-   to authenticate the data in DNS and provide key distribution services
-   using SIG, KEY, and NXT resource records (RRs) [RFC2535].
-
-
-
-Baba                     Expires March 11, 2004                 [Page 1]
-
-Internet-Draft       DNS Access Control Requirements      September 2003
-
-
-   At the 28th IETF Meeting in Houston in 1993, DNS security design team
-   started a discussion about DNSSEC and agreed to accept the assumption
-   that "DNS data is public".  Accordingly, confidentiality for queries
-   or responses is not provided by DNSSEC, nor are any sort of access
-   control lists or other means to differentiate inquirers.  However,
-   about ten years has passed, access control in DNS has been more
-   important than before.  Currently, new RRs are proposed to add new
-   functionality to DNS such as ENUM [RFC2916].  Such new RRs may
-   contain private information.  Thus, DNS access control will be
-   needed.
-
-   Furthermore, with DNS access control mechanism, access from
-   unauthorized clients can be blocked when they perform DNS name
-   resolution.  Thus, for example, Denial of Service (DoS) attacks
-   against a server used by a closed user group can be prevented using
-   this mechanism if IP address of the server is not revealed by other
-   sources.
-
-   This document describes the requirements for access control
-   mechanisms in DNS.
-
-2. Terminology
-
-   AC-aware client
-      This is the client that understands the DNS access control
-      extensions. This client may be an end host which has a stub
-      resolver, or a cashing/recursive name server which has a
-      full-service resolver.
-
-   AC-aware server
-      This is the authoritative name server that understands the DNS
-      access control extensions.
-
-   ACE
-      An Access Control Entry.  This is the smallest unit of access
-      control policy.  It grants or denies a given set of access
-      rights to a set of principals.  An ACE is a component of an ACL,
-      which is associated with a resource.
-
-   ACL
-      An Access Control List.  This contains all of the access control
-      policies which are directly associated with a particular
-      resource.  These policies are expressed as ACEs.
-
-   Client
-      A program or host which issues DNS requests and accepts its
-      responses. A client may be an end host or a cashing/recursive name
-      server.
-
-
-
-Baba                     Expires March 11, 2004                 [Page 2]
-
-Internet-Draft       DNS Access Control Requirements      September 2003
-
-
-   RRset
-      All resource records (RRs) having the same NAME, CLASS and TYPE
-      are called a Resource Record Set (RRset).
-
-3. Requirements
-
-   This section describes the requirements for access control in DNS.
-
-3.1 Authentication
-
-3.1.1 Client Authentication Mechanism
-
-   The AC-aware server must identify AC-aware clients based on IP
-   address and/or domain name (user ID or host name), and must
-   authenticate them using strong authentication mechanism such as
-   digital signature or message authentication code (MAC).
-
-   SIG(0) RR [RFC2931] contains a domain name associated with sender's
-   public key in its signer's name field, and TSIG RR [RFC2845] also
-   contains a domain name associated with shared secret key in its key
-   name field.  Each of these domain names can be a host name or a user
-   name, and can be used as a sender's identifier for access control.
-   Furthermore, SIG(0) uses digital signatures, and TSIG uses MACs for
-   message authentication.  These mechanisms can be used to authenticate
-   AC-aware clients.
-
-   Server authentication may be also provided.
-
-3.1.2 End-to-End Authentication
-
-   In current DNS model, caching/recursive name servers are deployed
-   between end hosts and authoritative name servers.  Although
-   authoritative servers can authenticate caching/recursive name servers
-   using SIG(0) or TSIG, they cannot authenticate end hosts behind them.
-   For end-to-end authentication, the mechanism for an end host to
-   discover the target authoritative name server and directly access to
-   it bypassing caching/recursive name servers is needed.  For example,
-   an end host can get the IP addresses of the authoritative name
-   servers by retrieving NS RRs for the zone via local caching/recursive
-   name server.
-
-   In many enterprise networks, however, there are firewalls that block
-   all DNS packets other than those going to/from the particular
-   caching/recursive servers.  To deal with this problem, one can
-   implement packet forwarding function on the caching/recursive servers
-   and enable end-to-end authentication via the caching/recursive
-   servers.
-
-
-
-
-Baba                     Expires March 11, 2004                 [Page 3]
-
-Internet-Draft       DNS Access Control Requirements      September 2003
-
-
-3.1.3 Authentication Key Retrieval
-
-   Keys which are used to authenticate clients should be able to be
-   automatically retrieved.  The KEY RR is used to store a public key
-   for a zone or a host that is associated with a domain name.  SIG(0)
-   RR uses a public key in KEY RR for verifying the signature.  If
-   DNSSEC is available, the KEY RR would be protected by the SIG RR.
-   KEY RR or newly defined RR can be used to automatic key retrieval.
-
-3.2 Confidentiality
-
-3.2.1 Data Encryption
-
-   To avoid disclosure to eavesdroppers, the response containing the
-   RRsets which are restricted to access from particular users should be
-   encrypted.  Currently, no encryption mechanism is specified in DNS.
-   Therefore, new RRs should be defined for DNS message encryption.
-   Instead, IPsec [RFC2401] can be used to provide confidentiality if
-   name server and resolver can set up security associations dynamically
-   using IPsec API [IPSECAPI] when encryption is required.
-
-   In case encryption is applied, entire DNS message including DNS
-   header should be encrypted to hide information including error code.
-
-   Query encryption may be also provided for hiding query information.
-
-3.2.2 Key Exchange
-
-   If DNS message encryption is provided, automatic key exchange
-   mechanism should be also provided.  [RFC2930] specifies a TKEY RR
-   that can be used to establish and delete shared secret keys used by
-   TSIG between a client and a server.  With minor extensions, TKEY can
-   be used to establish shared secret keys used for message encryption.
-
-3.2.3 Caching
-
-   The RRset that is restricted to access from particular users must not
-   be cached.  To avoid caching, the TTL of the RR that is restricted to
-   access should be set to zero during transit.
-
-3.3 Access Control
-
-3.3.1 Granularity of Access Control
-
-   Control of access on a per-user/per-host granularity must be
-   supported.  Control of access to individual RRset (not just the
-   entire zone) must be also supported.  However, SOA, NS, SIG, NXT,
-   KEY, and DS RRs must be publicly accessible to avoid unexpected
-   results.
-   
-
-Baba                     Expires March 11, 2004                 [Page 4]
-
-Internet-Draft       DNS Access Control Requirements      September 2003
-
-
-3.3.2 ACL Representation
-
-   Access Control List (ACL) format must be standardized so that both
-   the primary and secondary AC-aware servers can recognize the same
-   ACL.  Although ACL may appear in or out of zone data, it must be
-   transferred to the secondary AC-aware server with associated zone
-   data.  It is a good idea to contain ACL in zone data, because ACL can
-   be transferred with zone data using existing zone transfer mechanisms
-   automatically.  However, ACL must not be published except for
-   authorized secondary master servers.
-   
-   In zone data master files, ACL should be specified using TXT RRs or
-   newly defined RRs.  In each access control entry (ACE), authorized
-   entities (host or user) must be described using domain name (host
-   name, user name, or IP address in in-addr.arpa/ip6.arpa format).
-   There may be other access control attributes such as access time.
-
-   It must be possible to create publicly readable entries, which may be
-   read even by unauthenticated clients.
-
-3.3.3 Zone/ACL Transfer
-
-   As mentioned above, ACL should be transferred from a primary AC-aware
-   server to a secondary AC-aware server with associated zone data.
-   When an AC-aware server receives a zone/ACL transfer request, the
-   server must authenticate the client, and should encrypt the zone
-   data and associated ACL during transfer.
-
-3.4 Backward/co-existence Compatibility
-
-   Any new protocols to be defined for access control in DNS must be
-   backward compatible with existing DNS protocol.  AC-aware servers
-   must be able to process normal DNS query without authentication, and
-   must respond if retrieving RRset is publicly accessible.
-   
-   Modifications to root/gTLD/ccTLD name servers are not allowed.
-
-4. Security Considerations
-
-   This document discusses the requirements for access control
-   mechanisms in DNS.
-
-5. Acknowledgements
-
-   This work is funded by the Telecommunications Advancement
-   Organization of Japan (TAO).
-
-   The author would like to thank the members of the NTT DATA network
-   security team for their important contribution to this work.
-
-
-Baba                     Expires March 11, 2004                 [Page 5]
-
-Internet-Draft       DNS Access Control Requirements      September 2003
-
-
-6. References
-
-   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
-              STD 13, RFC 1034, November 1987.
-
-   [RFC1035]  Mockapetris, P., "Domain names - implementation and
-              specification", STD 13, RFC 1035, November 1987.
-
-   [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
-              Internet Protocol", RFC 2401, November 1998.
-
-   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
-              RFC 2535, March 1999.
-
-   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
-              "Secret Key Transaction Authentication for DNS (TSIG)", 
-              RFC 2845, May 2000.
-
-   [RFC2916]  Faltstrom, P., "E.164 number and DNS", RFC 2916,
-              September 2000.
-
-   [RFC2930]  Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)",
-              RFC 2930, September 2000.
-
-   [RFC2931]  Eastlake, D., "DNS Request and Transaction Signatures
-              (SIG(0)s)", RFC 2931, September 2000.
-
-   [IPSECAPI] Sommerfeld, W., "Requirements for an IPsec API",
-              draft-ietf-ipsp-ipsec-apireq-00.txt, June 2003, Work in
-              Progress.
-
-
-Author's Address
-
-   Tatsuya Baba
-   NTT Data Corporation
-   Research and Development Headquarters
-   Kayabacho Tower, 1-21-2, Shinkawa, Chuo-ku,
-   Tokyo 104-0033, Japan
-   
-   Tel: +81 3 3523 8081
-   Fax: +81 3 3523 8090
-   Email: babatt@nttdata.co.jp
-
-
-
-
-
-
-
-
-Baba                     Expires March 11, 2004                 [Page 6]
diff --git a/contrib/bind9/doc/draft/draft-daigle-napstr-04.txt b/contrib/bind9/doc/draft/draft-daigle-napstr-04.txt
deleted file mode 100644
index fffa8a5..0000000
--- a/contrib/bind9/doc/draft/draft-daigle-napstr-04.txt
+++ /dev/null
@@ -1,1232 +0,0 @@
-
-
-Network Working Group                                          L. Daigle
-Internet-Draft                                                 A. Newton
-Expires: August 15, 2004                                  VeriSign, Inc.
-                                                       February 15, 2004
-
-
-    Domain-based Application Service Location Using SRV RRs and the
-              Dynamic Delegation Discovery Service (DDDS)
-                       draft-daigle-napstr-04.txt
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on August 15, 2004.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-Abstract
-
-   This memo defines a generalized mechanism for application service
-   naming that allows service location without relying on rigid domain
-   naming conventions (so-called name hacks).  The proposal defines a
-   Dynamic Delegation Discovery System (DDDS) Application to map domain
-   name, application service name, and application protocol to target
-   server and port, dynamically.
-
-
-
-
-
-
-
-Daigle & Newton          Expires August 15, 2004                [Page 1]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-Table of Contents
-
-   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  4
-   2.    Straightforward-NAPTR (S-NAPTR) Specification  . . . . . . .  4
-   2.1   Key Terms  . . . . . . . . . . . . . . . . . . . . . . . . .  4
-   2.2   S-NAPTR DDDS Application Usage . . . . . . . . . . . . . . .  5
-   2.2.1 Ordering and Preference  . . . . . . . . . . . . . . . . . .  5
-   2.2.2 Matching and non-Matching NAPTR Records  . . . . . . . . . .  5
-   2.2.3 Terminal and Non-Terminal NAPTR Records  . . . . . . . . . .  5
-   2.2.4 S-NAPTR and Successive Resolution  . . . . . . . . . . . . .  6
-   2.2.5 Clients Supporting Multiple Protocols  . . . . . . . . . . .  6
-   3.    Guidelines . . . . . . . . . . . . . . . . . . . . . . . . .  7
-   3.1   Guidelines for Application Protocol Developers . . . . . . .  7
-   3.1.1 Registration of application service and protocol tags  . . .  7
-   3.1.2 Definition of conditions for retry/failure . . . . . . . . .  8
-   3.1.3 Server identification and handshake  . . . . . . . . . . . .  8
-   3.2   Guidelines for Domain Administrators . . . . . . . . . . . .  8
-   3.3   Guidelines for Client Software Writers . . . . . . . . . . .  9
-   4.    Illustrations  . . . . . . . . . . . . . . . . . . . . . . .  9
-   4.1   Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . .  9
-   4.2   Service Discovery within a Domain  . . . . . . . . . . . . . 10
-   4.3   Multiple Protocols . . . . . . . . . . . . . . . . . . . . . 10
-   4.4   Remote Hosting . . . . . . . . . . . . . . . . . . . . . . . 11
-   4.5   Sets of NAPTR RRs  . . . . . . . . . . . . . . . . . . . . . 12
-   4.6   Sample sequence diagram  . . . . . . . . . . . . . . . . . . 12
-   5.    Motivation and Discussion  . . . . . . . . . . . . . . . . . 14
-   5.1   So, why not just SRV records?  . . . . . . . . . . . . . . . 15
-   5.2   So, why not just NAPTR records?  . . . . . . . . . . . . . . 15
-   6.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 16
-   7.    Security Considerations  . . . . . . . . . . . . . . . . . . 16
-   8.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
-         References . . . . . . . . . . . . . . . . . . . . . . . . . 17
-         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18
-   A.    Application Service Location Application of DDDS . . . . . . 18
-   A.1   Application Unique String  . . . . . . . . . . . . . . . . . 18
-   A.2   First Well Known Rule  . . . . . . . . . . . . . . . . . . . 18
-   A.3   Expected Output  . . . . . . . . . . . . . . . . . . . . . . 18
-   A.4   Flags  . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
-   A.5   Service Parameters . . . . . . . . . . . . . . . . . . . . . 19
-   A.5.1 Application Services . . . . . . . . . . . . . . . . . . . . 19
-   A.5.2 Application Protocols  . . . . . . . . . . . . . . . . . . . 20
-   A.6   Valid Rules  . . . . . . . . . . . . . . . . . . . . . . . . 20
-   A.7   Valid Databases  . . . . . . . . . . . . . . . . . . . . . . 20
-   B.    Pseudo pseudocode for S-NAPTR  . . . . . . . . . . . . . . . 20
-   B.1   Finding the first (best) target  . . . . . . . . . . . . . . 20
-   B.2   Finding subsequent targets . . . . . . . . . . . . . . . . . 21
-         Full Copyright Statement . . . . . . . . . . . . . . . . . . 23
-
-
-
-
-Daigle & Newton          Expires August 15, 2004                [Page 2]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-1. Introduction
-
-   This memo defines a generalized mechanism for application service
-   naming that allows service location without relying on rigid domain
-   naming conventions (so-called name hacks).  The proposal defines a
-   Dynamic Delegation Discovery System (DDDS -- see [6]) Application to
-   map domain name, application service name, and application protocol
-   to target server and port, dynamically.
-
-   As discussed in Section 5, existing approaches to using DNS records
-   to dynamically determining the current host for a given application
-   service are limited in terms of the use cases supported.  To address
-   some of the limitations, this document defines a DDDS Application to
-   map service+protocol+domain to specific server addresses using both
-   NAPTR [7] and SRV ([5]) DNS resource records.  This can be viewed as
-   a more general version of the use of SRV and/or a very restricted
-   application of the use of NAPTR resource records.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC2119 ([2]).
-
-2. Straightforward-NAPTR (S-NAPTR) Specification
-
-   The precise details of the specification of this DDDS application are
-   given in Appendix A.  This section defines the usage of the DDDS
-   application.
-
-2.1 Key Terms
-
-   An "application service" is a generic term for some type of
-   application, indpendent of the protocol that may be used to offer it.
-   Each application service will be associated with an IANA-registered
-   tag.  For example, instant messaging is a type of application
-   service, which can be implemented by many different application-layer
-   protocols, and the tag "IM" (used as an illustration here) could be
-   registered for it.
-
-   An "application protocol" is used to implement the application
-   service.  These are also associated with IANA-registered tags.  In
-   the case where multiple transports are available for the application,
-   separate tags should be defined for each transport.
-
-   The intention is that the combination of application service and
-   protocol tags should be specific enough that finding a known pair
-   (e.g., "IM:ProtC") is sufficient for a client to identify a server
-   with which it can communicate.
-
-
-
-
-Daigle & Newton          Expires August 15, 2004                [Page 3]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-   Some protocols support multiple application services.  For example,
-   LDAP is an application protocol, and can be found supporting various
-   services (e.g., "whitepages", "directory enabled networking", etc).
-
-2.2 S-NAPTR DDDS Application Usage
-
-   As outlined in Appendix A, NAPTR records are used to store
-   application service+protocol information for a given domain.
-   Following the DDDS standard, these records are looked up,  and the
-   rewrite rules (contained in the NAPTR records) are used to determine
-   the successive DNS lookups, until a desirable target is found.
-
-   For the rest of this section, refer to the set of NAPTR resource
-   records for example.com shown in the figure below.
-
-   example.com.
-   ;;       order pref flags service     regexp replacement
-   IN NAPTR 100   10   ""    "WP:whois++" ""    bunyip.example.
-   IN NAPTR 100   20   "s"   "WP:ldap"    ""    _ldap._tcp.myldap.example.com.
-   IN NAPTR 200   10   ""    "IM:protA"   ""    someisp.example.
-   IN NAPTR 200   30   "a"   "IM:protB"   ""    myprotB.example.com.
-
-
-2.2.1 Ordering and Preference
-
-   A client retrieves all of the NAPTR records associated with the
-   target domain name (example.com, above).  These are to be sorted in
-   terms of increasing ORDER, and increasing PREF within each ORDER.
-
-2.2.2 Matching and non-Matching NAPTR Records
-
-   Starting with the first sorted NAPTR record, the client examines the
-   SERVICE field to find a match.  In the case of the S-NAPTR DDDS
-   application, that means a SERVICE field that includes the tags for
-   the desired application service and a supported application protocol.
-
-   If more than one NAPTR record matches, they are processed in
-   increasing sort order.
-
-2.2.3 Terminal and Non-Terminal NAPTR Records
-
-   A NAPTR record with an empty FLAG field is "non-terminal".  That is,
-   more NAPTR RR lookups are to be performed.  Thus, to process a NAPTR
-   record with an empty FLAG field in S-NAPTR, the REPLACEMENT field is
-   used as the target of the next DNS lookup -- for NAPTR RRs.
-
-   In S-NAPTR, the only terminal flags are "S" and "A".  These are
-   called "terminal" NAPTR lookups because they denote the end of the
-
-
-
-Daigle & Newton          Expires August 15, 2004                [Page 4]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-   DDDS/NAPTR processing rules.  In the case of an "S" flag, the
-   REPLACEMENT field is used as the target of a DNS query for SRV RRs,
-   and normal SRV processing is applied.  In the case of an "A" flag, an
-   address record is sought for the REPLACEMENT field target (and the
-   default protocol port is assumed).
-
-2.2.4 S-NAPTR and Successive Resolution
-
-   As shown in the example NAPTR RR set above, it is possible to have
-   multiple possible targets for a single application service+protocol
-   pair.  These are to be pursued in order until a server is
-   successfully contacted or all possible matching NAPTR records have
-   been successively pursued to terminal lookups and servers contacted.
-   That is, a client must backtrack and attempt other resolution paths
-   in the case of failure.
-
-   "Failure" is declared, and backtracking must be used when
-
-   o  the designated remote server (host and port) fail to provide
-      appropriate security credentials for the *originating* domain
-
-   o  connection to the designated remote server otherwise fails -- the
-      specifics terms of which are defined when an application protocol
-      is registered
-
-   o  the S-NAPTR-designated DNS lookup fails to yield expected results
-      -- e.g., no A RR for an "A" target, no SRV record for an "S"
-      target, or no NAPTR record with appropriate application service
-      and protocol for a NAPTR lookup.  Except in the case of the very
-      first NAPTR lookup, this last is a configuration error:  the fact
-      that example.com has a NAPTR record pointing to "bunyip.example"
-      for the "WP:Whois++" service and protocol means the administrator
-      of example.com believes that service exists.  If bunyip.example
-      has no "WP:Whois++" NAPTR record, the application client MUST
-      backtrack and try the next available "WP:Whois++" option from
-      example.com.  As there is none, the whole resolution fails.
-
-   An application client first queries for the NAPTR RRs for the domain
-   of a named application service.  The application client MUST select
-   one protocol to choose The PREF field of the NAPTR RRs may be used by
-   the domain administrator to The first DNS query is for the NAPTR RRs
-   in the original target domain (example.com, above).
-
-2.2.5 Clients Supporting Multiple Protocols
-
-   In the case of an application client that supports more than one
-   protocol for a given application service, it MUST pursue S-NAPTR
-   resolution completely for one protocol before trying another.j It MAY
-
-
-
-Daigle & Newton          Expires August 15, 2004                [Page 5]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-   choose which protocol to try first based on its own preference, or
-   from the PREF ranking in the first set of NAPTR records (i.e., those
-   for the target named domain).    However, the chosen protocol MUST be
-   listed in that first NAPTR RR set.
-
-   That is, what the client MUST NOT do is start looking for one
-   protocol, observe that a successive NAPTR RR set supports another of
-   its preferred protocols, and continue the S-NAPTR resolution based on
-   that protocol.  For example, even if someisp.example offers the "IM"
-   service with protocol "ProtB", there is no reason to believe it does
-   so on behalf of example.com (since there is no such pointer in
-   example.com's NAPTR RR set).
-
-3. Guidelines
-
-3.1 Guidelines for Application Protocol Developers
-
-   The purpose of S-NAPTR is to provide application standards developers
-   with a more powerful framework (than SRV RRs alone) for naming
-   service targets, without requiring each application protocol (or
-   service) standard to define a separate DDDS application.
-
-   Note that this approach is intended specifically for use when it
-   makes sense to associate services with particular domain names (e.g.,
-   e-mail addresses, SIP addresses, etc).  A non-goal is having all
-   manner of label mapped into domain names in order to use this.
-
-   Specifically not addressed in this document is how to select the
-   domain for which the service+protocol is being sought.  It is up to
-   other conventions to define how that might be used (e.g., instant
-   messaging standards can define what domain to use from IM URIs, how
-   to step down from foobar.example.com to example.com, and so on, if
-   that is applicable).
-
-   Although this document proposes a DDDS application that does not use
-   all the features of NAPTR resource records, it does not mean to imply
-   that DNS resolvers should fail to implement all aspects of the NAPTR
-   RR standard.  A DDDS application is a client use convention.
-
-   The rest of this section outlines the specific elements that protocol
-   developers must determine and document in order to make use of S-
-   NAPTR.
-
-3.1.1 Registration of application service and protocol tags
-
-   Application protocol developers that wish to make use of S-NAPTR must
-   make provision to register any relevant application service and
-   application protocol tags, as described in Section 6.
-
-
-
-Daigle & Newton          Expires August 15, 2004                [Page 6]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-3.1.2 Definition of conditions for retry/failure
-
-   One other important aspect that must be defined is the expected
-   behaviour for interacting with the servers that are reached via S-
-   NAPTR.  Specifically,  under what circumstances should the client
-   retry a target that was found via S-NAPTR?  What should it consider a
-   failure that causes it to return to the S-NAPTR process to determine
-   the next serviceable target (a less preferred target)?
-
-   For example, if the client gets a "connection refused" from a server,
-   should it retry for some (protocol-dependent) period of time?  Or,
-   should it try the next-preferred target in the S-NAPTR chain of
-   resolution?  Should it only try the next-preferred target if it
-   receives a protocol-specific permanent error message?
-
-   The most important thing is to select one expected behaviour and
-   document it as part of the use of S-NAPTR.
-
-   As noted earlier, failure to provide appropriate credentials to
-   identify the server as being authoritative for the original taret
-   domain is always considered a failure condition.
-
-3.1.3 Server identification and handshake
-
-   As noted in Section 7, use of the DNS for server location increases
-   the importance of using protocol-specific handshakes to determine and
-   confirm the identity of the server that is eventually reached.
-
-   Therefore, application protocol developers using S-NAPTR should
-   identify the mechanics of the expected identification handshake when
-   the client connects to a server found through S-NAPTR.
-
-3.2 Guidelines for Domain Administrators
-
-   Although S-NAPTR aims to provide a "straightforward" application of
-   DDDS and use of NAPTR records, it is still possible to create very
-   complex chains and dependencies with the NAPTR and SRV records.
-
-   Therefore, domain administrators are called upon to use S-NAPTR with
-   as much restraint as possible, while still achieving their service
-   design goals.
-
-   The complete set of NAPTR, SRV and A RRs that are "reachable" through
-   the S-NAPTR process for a particular application service can be
-   thought of as a "tree".  Each NAPTR RR retrieved points to more NAPTR
-   or SRV records; each SRV record points to several A record lookups.
-   Even though a particular client can "prune" the tree to use only
-   those records referring to application protocols supported by the
-
-
-
-Daigle & Newton          Expires August 15, 2004                [Page 7]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-   client, the tree could be quite deep, and retracing the tree to retry
-   other targets can become expensive if the tree has many branches.
-
-   Therefore,
-
-   o  Fewer branches is better:  for both NAPTR and SRV records, provide
-      different targets with varying preferences where appropriate
-      (e.g., to provide backup services, etc), but don't look for
-      reasons to provide more.
-
-   o  Shallower is better:  avoid using NAPTR records to "rename"
-      services within a zone.  Use NAPTR records to identify services
-      hosted elsewhere (i.e., where you cannot reasonably provide the
-      SRV records in your own zone).
-
-
-3.3 Guidelines for Client Software Writers
-
-   To properly understand DDDS/NAPTR, an implementor must read [6].
-   However, the most important aspect to keep in mind is that, if one
-   target fails to work for the application, it is expected that the
-   application will continue through the S-NAPTR tree to try the (less
-   preferred) alternatives.
-
-4. Illustrations
-
-4.1 Use Cases
-
-   The basic intended use cases for which S-NAPTR has been developed
-   are:
-
-   o  Service discovery within a domain.  For example, this can be used
-      to find the "authoritative" server for some type of service within
-      a domain (see the specific example in Section 4.2).
-
-   o  Multiple protocols.  This is increasingly common as new
-      application services are defined.  This includes the case of
-      instant messaging (a service) which can be offered with multiple
-      protocols (see Section 4.3).
-
-   o  Remote hosting.  Each of the above use cases applies within the
-      administration of a single domain.  However, one domain operator
-      may elect to engage another organization to provide an application
-      service.  See Section 4.4 for an example that cannot be served by
-      SRV records alone.
-
-
-
-
-
-
-Daigle & Newton          Expires August 15, 2004                [Page 8]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-4.2 Service Discovery within a Domain
-
-   There are occasions when it is useful to be able to determine the
-   "authoritative" server for a given application service within a
-   domain.  This is "discovery", because there is no a priori knowledge
-   as to whether or where the service is offered; it is therefore
-   important to determine the location and characteristics of the
-   offered service.
-
-   For example, there is growing discussion of having a generic
-   mechanism for locating the keys or certificates associated with
-   particular application (servers) operated in (or for) a particular
-   domain.  Here's a hypothetical case for storing application key or
-   certificate data for a given domain.  The premise is that some
-   credentials registry (CredReg) service has been defined to be a leaf
-   node service holding the keys/certs for the servers operated by (or
-   for) the domain.  Furthermore, it is assumed that more than one
-   protocol is available to provide the service for a particular domain.
-   This DDDS-based approach is used to find the CredReg server that
-   holds the information.
-
-   Thus, the set of NAPTR records for thinkingcat.example might look
-   like this:
-
-   thinkingcat.example.
-   ;;       order pref flags service                 regexp  replacement
-   IN NAPTR 100   10   ""    "CREDREG:ldap:iris-beep" ""     theserver.thinkingcat.example.
-
-   Note that another domain, offering the same application service,
-   might offer it using a different set of application protocols:
-
-   anotherdomain.example.
-   ;;       order pref flags service                    regexp replacement
-   IN NAPTR 100   10   ""    "CREDREG:iris-lw:iris-beep" ""    foo.anotherdomain.example.
-
-
-4.3 Multiple Protocols
-
-   As it stands, there are several different protocols proposed for
-   offering "instant message" services.  Assuming that "IM" was
-   registered as an application service, this DDDS application could be
-   used to determine the available services for delivering to a target.
-
-   Two particular features of instant messaging should be noted:
-
-   1.  gatewaying is expected to bridge communications across protocols
-
-   2.  instant messaging servers are likely to be operated out of a
-
-
-
-Daigle & Newton          Expires August 15, 2004                [Page 9]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-       different domain than the instant messaging address, and servers
-       of different protocols may be offered by independent
-       organizations
-
-   For example, "thinkingcat.example" may support its own servers for
-   the "ProtA" instant messaging protocol, but rely on outsourcing from
-   "example.com" for "ProtC" and "ProtB" servers.
-
-   Using this DDDS-based approach, thinkingcat.example can indicate a
-   preference ranking for the different types of servers for the instant
-   messaging service, and yet the out-sourcer can independently rank the
-   preference and ordering of servers.  This independence is not
-   achievable through the use of SRV records alone.
-
-   Thus, to find the IM services for thinkingcat.example, the NAPTR
-   records for thinkingcat.example are retrieved:
-
-   thinkingcat.example.
-   ;;	order pref flags service   regexp replacement
-   IN NAPTR 100  10   "s"   "IM:ProtA" ""    _ProtA._tcp.thinkingcat.example.
-   IN NAPTR 100  20   "s"   "IM:ProtB" ""    _ProtB._tcp.example.com.
-   IN NAPTR 100  30   "s"   "IM:ProtC" ""    _ProtC._tcp.example.com.
-
-   and then the administrators at example.com can manage the preference
-   rankings of the servers they use to support the ProtB service:
-
-   _ProtB._tcp.example.com.
-    ;;    Pref Weight Port  Target
-   IN SRV 10    0     10001 bigiron.example.com
-   IN SRV 20    0     10001 backup.im.example.com
-   IN SRV 30    0     10001 nuclearfallout.australia-isp.example
-
-
-4.4 Remote Hosting
-
-   In the Instant Message hosting example in Section 4.3, the service
-   owner (thinkingcat.example) had to host pointers to the hosting
-   service's SRV records in the thinkingcat.example domain.
-
-   A better way to approach this is to have one NAPTR RR in the
-   thinkingcat.example domain pointing to all the hosted services, and
-   the hosting domain has NAPTR records for each service to map them to
-   whatever local hosts it chooses (and may change from time to time).
-
-
-
-
-
-
-
-
-Daigle & Newton          Expires August 15, 2004               [Page 10]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-   thinkingcat.example.
-   ;;      order pref flags service         regexp replacement
-   IN NAPTR 100  10   "s"   "IM:ProtA"       ""    _ProtA._tcp.thinkingcat.example.
-   IN NAPTR 100  20   ""    "IM:ProtB:ProtC" ""    thinkingcat.example.com.
-
-
-   and then the administrators at example.com can break out the
-   individual application protocols and manage the preference rankings
-   of the servers they use to support the ProtB service (as before):
-
-   thinkingcat.example.com.
-   ;;      order pref flags service   regexp  replacement
-   IN NAPTR 100  10   "s"   "IM:ProtC" ""     _ProtC._tcp.example.com.
-   IN NAPTR 100  20   "s"   "IM:ProtB" ""     _ProtB._tcp.example.com.
-
-
-
-   _ProtC._tcp.example.com.
-    ;;    Pref Weight Port  Target
-   IN SRV 10    0     10001 bigiron.example.com
-   IN SRV 20    0     10001 backup.im.example.com
-   IN SRV 30    0     10001 nuclearfallout.australia-isp.example
-
-
-4.5 Sets of NAPTR RRs
-
-   Note that the above sections assumed that there was one service
-   available (via S-NAPTR) per domain.  Often, that will not be the
-   case.  Assuming thinkingcat.example had the CredReg service set up as
-   described in Section 4.2 and the instant messaging service set up as
-   described in Section 4.4, then a client querying for the NAPTR RR set
-   from thinkingcat.com would get the following answer:
-
-   thinkingcat.example.
-   ;;       order pref flags service          regexp  replacement
-   IN NAPTR 100   10   "s"   "IM:ProtA"        ""     _ProtA._tcp.thinkingcat.example.
-   IN NAPTR 100   20   ""    "IM:ProtB:ProtC:" ""     thinkingcat.example.com.
-   IN NAPTR 200   10   ""    "CREDREG:ldap:iris-beep" "" bouncer.thinkingcat.example.
-
-   Sorting them by increasing "ORDER", the client would look through the
-   SERVICE strings to determine if there was a NAPTR RR that matched the
-   application service it was looking for, with an application protocol
-   it could use.  The first (lowest PREF) record that so matched is the
-   one the client would use to continue.
-
-4.6 Sample sequence diagram
-
-   Consider the example in Section 4.3.  Visually, the sequence of steps
-
-
-
-Daigle & Newton          Expires August 15, 2004               [Page 11]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-   required for the client to reach the final server for a "ProtB"
-   service for IM for the thinkingcat.example domain is as follows:
-
-
-   Client   NS for                NS for
-            thinkingcat.example   example.com    backup.im.example.com
-                |                     |                  |
-     1 -------->|                     |                  |
-     2 <--------|                     |                  |
-     3 ------------------------------>|                  |
-     4 <------------------------------|                  |
-     5 ------------------------------>|                  |
-     6 <------------------------------|                  |
-     7 ------------------------------>|                  |
-     8 <------------------------------|                  |
-     9 ------------------------------------------------->|
-    10 <-------------------------------------------------|
-    11 ------------------------------------------------->|
-    12 <-------------------------------------------------|
-   (...)
-
-
-
-   1.  the name server (NS) for thinkingcat.example is reached with a
-        request for all NAPTR records
-
-   2.  the server responds with the NAPTR records shown in Section 4.3.
-
-   3.  the second NAPTR record matches the desired criteria; that has an
-        "s" flag and a replacement fields of "_ProtB._tcp.example.com".
-        So, the client looks up SRV records for that target, ultimately
-        making the request of the NS for example.com.
-
-   4.  the response includes the SRV records listed in Section 4.3.
-
-   5.  the client attempts to reach the server with the lowest PREF in
-        the SRV list -- looking up the A record for the SRV record's
-        target (bigiron.example.com).
-
-   6.  the example.com NS responds with an error message -- no such
-        machine!
-
-   7.  the client attempts to reach the second server in the SRV list,
-        and looks up the A record for backup.im.example.com
-
-   8.  the client gets the A record with the IP address for
-        backup.im.example.com from example.com's NS.
-
-
-
-
-Daigle & Newton          Expires August 15, 2004               [Page 12]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-   9.  the client connects to that IP address, on port 10001 (from the
-        SRV record), using ProtB over tcp.
-
-   10.  the server responds with an "OK" message.
-
-   11.  the client uses ProtB to challenge that this server has
-        credentials to operate the service for the original domain
-        (thinkingcat.example)
-
-   12.  the server responds, and the rest is IM.
-
-
-5. Motivation and Discussion
-
-   Increasingly, application protocol standards are using domain names
-   to identify server targets, and stipulating that clients should look
-   up SRV resource records to determine the host and port providing the
-   server.  This enables a distinction between naming an application
-   service target and actually hosting the server.  It also increases
-   flexibility in hosting the target service:
-
-   o  the server may be operated by a completely different organization
-      without having to list the details of that organization's DNS
-      setup (SRVs)
-
-   o  multiple instances can be set up (e.g., for load balancing or
-      secondaries)
-
-   o  it can be moved from time to time without disrupting clients'
-      access, etc.
-
-   This is quite useful, but Section 5.1 outlines some of the
-   limitations inherent in the approach.
-
-   That is, while SRV records can be used to map from a specific service
-   name and protocol for a specific domain to a specific server, SRV
-   records are limited to one layer of indirection, and are focused on
-   server administration rather than on application naming.  And, while
-   the DDDS specification and use of NAPTR allows multiple levels of
-   redirection before locating the target server machine with an SRV
-   record, this proposal requires only a subset of NAPTR strictly bound
-   to domain names, without making use of the REGEXP field of NAPTR.
-   These restrictions make the client's resolution process much more
-   predictable and efficient than with some potential uses of NAPTR
-   records.  This is dubbed "S-NAPTR" -- a "S"traightforward use of
-   NAPTR records.
-
-
-
-
-
-Daigle & Newton          Expires August 15, 2004               [Page 13]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-5.1 So, why not just SRV records?
-
-   An expected question at this point is: this is so similar in
-   structure to SRV records, why are we doing this with DDDS/NAPTR?
-
-   Limitations of SRV include:
-
-   o  SRV provides a single layer of indirection -- the outcome of an
-      SRV lookup is a new domain name for which the A RR is to be found.
-
-   o  the purpose of SRV is focused on individual server administration,
-      not application naming: as stated in [5] "The SRV RR allows
-      administrators to use several servers for a single domain, to move
-      services from host to host with little fuss, and to designate some
-      hosts as primary servers for a service and others as backups."
-
-   o  target servers by "service" (e.g., "ldap") and "protocol" (e.g.,
-      "tcp") in a given domain.  The definition of these terms implies
-      specific things (e.g., that protocol should be one of UDP or TCP)
-      without being precise.  Restriction to UDP and TCP is insufficient
-      for the uses described here.
-
-   The basic answer is that SRV records provide mappings from protocol
-   names to host and port.  The use cases described herein require an
-   additional layer -- from some service label to servers that may in
-   fact be hosted within different administrative domains.  We could
-   tweak SRV to say that the next lookup could be something other than
-   an address record, but that is more complex than is necessary for
-   most applications of SRV.
-
-5.2 So, why not just NAPTR records?
-
-   That's a trick question.  NAPTR records cannot appear in the wild --
-   see [6].  They must be part of a DDDS application.
-
-   The purpose here is to define a single, common mechanism (the DDDS
-   application) to use NAPTR when all that is desired is simple DNS-
-   based location of services.  This should be easy for applications to
-   use -- some simple IANA registrations and it's done.
-
-   Also, NAPTR has very powerful tools for expressing "rewrite" rules.
-   That power (==complexity) makes some protocol designers and service
-   administrators nervous.  The concern is that it can translate into
-   unintelligible, noodle-like rule sets that are difficult to test and
-   administer.
-
-   This proposed DDDS application specifically uses a subset of NAPTR's
-   abilities.  Only "replacement" expressions are allowed, not "regular
-
-
-
-Daigle & Newton          Expires August 15, 2004               [Page 14]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-   expressions".
-
-6. IANA Considerations
-
-   This document calls for 2 IANA registries:  one for application
-   service tags, and one for application protocol tags.
-
-   Application service and protocol tags should be defined in an RFC
-   (unless the "x-" experimental form is used, in which case they are
-   unregistered).  There are no restrictions placed on the tags other
-   than that they must conform with the syntax defined below (Appendix
-   A.5).  The IANA registries should list the tags and the RFC that
-   defines their use.
-
-7. Security Considerations
-
-   The security of this approach to application service location is only
-   as good as the security of the DNS servers along the way.  If any of
-   them is compromised, bogus NAPTR and SRV records could be inserted to
-   redirect clients to unintended destinations.  This problem is hardly
-   unique to S-NAPTR (or NAPTR in general).
-
-   To protect against DNS-vectored attacks, applications should define
-   some form of end-to-end authentication to ensure that the correct
-   destination has been reached.  Many application protocols such as
-   HTTPS, BEEP, IMAP, etc...  define the necessary handshake mechansims
-   to accomplish this task.
-
-   The basic mechanism works in the following way:
-
-   1.  During some portion of the protocol handshake, the client sends
-       to the server the original name of the desired destination (i.e.
-       no transformations that may have resulted from NAPTR
-       replacements, SRV targets, or CNAME changes).  In certain cases
-       where the application protocol does not have such a feature but
-       TLS may be used, it is possible to use the "server_name" TLS
-       extension.
-
-   2.  The server sends back to the client a credential with the
-       appropriate name.  For X.509 certificates, the name would either
-       be in the subjectDN or subjectAltName fields.  For Kerberos, the
-       name would be a service principle name.
-
-   3.  Using the matching semantics defined by the application protocol,
-       the client compares the name in the credential with the name sent
-       to the server.
-
-   4.  If the names match, there is reasonable assurance that the
-
-
-
-Daigle & Newton          Expires August 15, 2004               [Page 15]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-       correct end point has been reached.
-
-   It is important to note that this document does not define either the
-   handshake mechanism, the specific credenential naming fields, nor the
-   name matching semantics.  Definitions of S-NAPTR for particular
-   application protocols MUST define these.
-
-8. Acknowledgements
-
-   Many thanks to Dave Blacka, Patrik Faltstrom, Sally Floyd for
-   discussion and input that has (hopefully!) provoked clarifying
-   revisions of this document.
-
-References
-
-   [1]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
-        Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
-
-   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [3]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
-        Specifications: ABNF", RFC 2234, November 1997.
-
-   [4]  Eastlake, D., "Domain Name System Security Extensions", RFC
-        2535, March 1999.
-
-   [5]  Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
-        specifying the location of services (DNS SRV)", RFC 2782,
-        February 2000.
-
-   [6]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
-        One: The Comprehensive DDDS", RFC 3401, October 2002.
-
-   [7]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
-        Three: The Domain Name System (DNS) Database", RFC 3403, October
-        2002.
-
-   [8]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
-        Four: The Uniform Resource Identifiers (URI)", RFC 3404, October
-        2002.
-
-
-
-
-
-
-
-
-
-
-Daigle & Newton          Expires August 15, 2004               [Page 16]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-Authors' Addresses
-
-   Leslie Daigle
-   VeriSign, Inc.
-   21355 Ridgetop Circle
-   Dulles, VA  20166
-   US
-
-   EMail: leslie@verisignlabs.com; leslie@thinkingcat.com
-
-
-   Andrew Newton
-   VeriSign, Inc.
-   21355 Ridgetop Circle
-   Dulles, VA  20166
-   US
-
-   EMail: anewton@verisignlabs.com
-
-Appendix A. Application Service Location Application of DDDS
-
-   This section defines the DDDS application, as described in [6].
-
-A.1 Application Unique String
-
-   The Application Unique String is domain label for which an
-   authoritative server for a particular service is sought.
-
-A.2 First Well Known Rule
-
-   The "First Well Known Rule" is identity -- that is, the output of the
-   rule is the Application Unique String, the domain label for which the
-   authoritative server for a particular service is sought.
-
-A.3 Expected Output
-
-   The expected output of this Application is the information necessary
-   to connect to authoritative server(s) (host, port, protocol) for an
-   application service within a given a given domain.
-
-A.4 Flags
-
-   This DDDS Application uses only 2 of the Flags defined for the
-   URI/URN Resolution Application ([8]): "S" and "A".  No other Flags
-   are valid.
-
-   Both are for terminal lookups.  This means that the Rule is the last
-   one and that the flag determines what the next stage should be.  The
-
-
-
-Daigle & Newton          Expires August 15, 2004               [Page 17]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-   "S" flag means that the output of this Rule is a domain label for
-   which one or more SRV [5] records exist.  "A" means that the output
-   of the Rule is a domain name and should be used to lookup address
-   records for that domain.
-
-   Consistent with the DDDS algorithm, if the Flag string is empty the
-   next lookup is for another NAPTR record (for the replacement target).
-
-A.5 Service Parameters
-
-   Service Parameters for this Application take the form of a string of
-   characters that follow this ABNF ([3]):
-
-      service-parms = [ [app-service] *(":" app-protocol)]
-      app-service   = experimental-service  / iana-registered-service
-      app-protocol  = experimental-protocol / iana-registered-protocol
-      experimental-service      = "x-" 1*30ALPHANUMSYM
-      experimental-protocol     = "x-" 1*30ALPHANUMSYM
-      iana-registered-service   = ALPHA *31ALPHANUMSYM
-      iana-registered-protocol  = ALPHA *31ALPHANUM
-      ALPHA         =  %x41-5A / %x61-7A   ; A-Z / a-z
-      DIGIT         =  %x30-39 ; 0-9
-      SYM           =  %x2B / %x2D / %x2E  ; "+" / "-" / "."
-      ALPHANUMSYM   =  ALPHA / DIGIT / SYM
-      ; The app-service and app-protocol tags are limited to 32
-      ; characters and must start with an alphabetic character.
-      ; The service-parms are considered case-insensitive.
-
-   Thus, the Service Parameters may consist of an empty string, just an
-   app-service, or an app-service with one or more app-protocol
-   specifications separated by the ":" symbol.
-
-   Note that this is similar to, but not the same as the syntax used in
-   the URI DDDS application ([8]).  The DDDS DNS database requires each
-   DDDS application to define the syntax of allowable service strings.
-   The syntax here is expanded to allow the characters that are valid in
-   any URI scheme name (see [1]).  Since "+" (the separator used in the
-   RFC3404 service parameter string) is an allowed character for URI
-   scheme names, ":" is chosen as the separator here.
-
-A.5.1 Application Services
-
-   The "app-service" must be a registered service [this will be an IANA
-   registry; this is not the IANA port registry, because we want to
-   define services for which there is no single protocol, and we don't
-   want to use up port space for nothing].
-
-
-
-
-
-Daigle & Newton          Expires August 15, 2004               [Page 18]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-A.5.2 Application Protocols
-
-   The protocol identifiers that are valid for the "app-protocol"
-   production are any standard, registered protocols [IANA registry
-   again -- is this the list of well known/registered ports?].
-
-A.6 Valid Rules
-
-   Only substitution Rules are permitted for this application.  That is,
-   no regular expressions are allowed.
-
-A.7 Valid Databases
-
-   At present only one DDDS Database is specified for this Application.
-   [7] specifies a DDDS Database that uses the NAPTR DNS resource record
-   to contain the rewrite rules.  The Keys for this database are encoded
-   as domain-names.
-
-   The First Well Known Rule produces a domain name, and this is the Key
-   that is used for the first lookup -- the NAPTR records for that
-   domain are requested.
-
-   DNS servers MAY interpret Flag values and use that information to
-   include appropriate NAPTR, SRV or A records in the Additional
-   Information portion of the DNS packet.  Clients are encouraged to
-   check for additional information but are not required to do so.  See
-   the Additional Information Processing section of [7] for more
-   information on NAPTR records and the Additional Information section
-   of a DNS response packet.
-
-Appendix B. Pseudo pseudocode for S-NAPTR
-
-B.1 Finding the first (best) target
-
-   Assuming the client supports 1 protocol for a particular application
-   service, the following pseudocode outlines the expected process to
-   find the first (best) target for the client, using S-NAPTR.
-
-
-    target = [initial domain]
-    naptr-done = false
-
-    while (not naptr-done)
-     {
-      NAPTR-RRset = [DNSlookup of NAPTR RRs for target]
-      [sort NAPTR-RRset by ORDER, and PREF within each ORDER]
-      rr-done = false
-      cur-rr = [first NAPTR RR]
-
-
-
-Daigle & Newton          Expires August 15, 2004               [Page 19]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-      while (not rr-done)
-         if ([SERVICE field of cur-rr contains desired application
-              service and application protocol])
-            rr-done = true
-            target= [REPLACEMENT target of NAPTR RR]
-         else
-            cur-rr = [next rr in list]
-
-         if (not empty [FLAG in cur-rr])
-            naptr-done = true
-     }
-
-    port = -1
-
-    if ([FLAG in cur-rr is "S"])
-     {
-      SRV-RRset = [DNSlookup of SRV RRs for target]
-      [sort SRV-RRset based on PREF]
-      target = [target of first RR of SRV-RRset]
-      port = [port in first RR of SRV-RRset]
-     }
-
-    ; now, whether it was an "S" or an "A" in the NAPTR, we
-    ; have the target for an A record lookup
-
-    host = [DNSlookup of target]
-
-    return (host, port)
-
-
-
-B.2 Finding subsequent targets
-
-   The pseudocode in Appendix B is crafted to find the first, most
-   preferred, host-port pair for a particular application service an
-   protocol.  If, for any reason, that host-port pair did not work
-   (connection refused, application-level error), the client is expected
-   to try the next host-port in the S-NAPTR tree.
-
-   The pseudocode above does not permit retries -- once complete, it
-   sheds all context of where in the S-NAPTR tree it finished.
-   Therefore, client software writers could
-
-   o  entwine the application-specific protocol with the DNS lookup and
-      RRset processing described in the pseudocode and continue the S-
-      NAPTR processing if the application code fails to connect to a
-      located host-port pair;
-
-
-
-
-Daigle & Newton          Expires August 15, 2004               [Page 20]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-   o  use callbacks for the S-NAPTR processing;
-
-   o  use an S-NAPTR resolution routine that finds *all* valid servers
-      for the required application service and protocol from the
-      originating domain, and provides them in sorted order for the
-      application to try in order.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daigle & Newton          Expires August 15, 2004               [Page 21]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daigle & Newton          Expires August 15, 2004               [Page 22]
-
diff --git a/contrib/bind9/doc/draft/draft-danisch-dns-rr-smtp-03.txt b/contrib/bind9/doc/draft/draft-danisch-dns-rr-smtp-03.txt
deleted file mode 100644
index 4a01d91..0000000
--- a/contrib/bind9/doc/draft/draft-danisch-dns-rr-smtp-03.txt
+++ /dev/null
@@ -1,1960 +0,0 @@
-
-
-
-INTERNET-DRAFT                                           Hadmut Danisch
-Category: Experimental                                         Oct 2003
-Expires: Apr 1, 2004
-
- The RMX DNS RR and method for lightweight SMTP sender authorization
-                   draft-danisch-dns-rr-smtp-03.txt
-
-Status of this Memo
-
-   This document is an Internet-Draft and is subject to all provisions
-   of Section 10 of RFC2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six
-   months and may be updated, replaced, or obsoleted by other
-   documents at any time.  It is inappropriate to use Internet-Drafts
-   as reference material or to cite them other than as "work in
-   progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/1id-abstracts.html
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-Abstract
-
-   This memo introduces a new authorization scheme for SMTP e-mail
-   transport. It is designed to be a simple and robust protection
-   against e-mail fraud, spam and worms. It is based solely on
-   organisational security mechanisms and does not require but still
-   allow use of cryptography. This memo also focuses on security and
-   privacy problems and requirements in context of spam defense. In
-   contrast to prior versions of the draft a new RR type is not
-   required anymore.
-
-
-
-
-
-
-
-
-
-
-
-
-Hadmut Danisch                Experimental                      [Page 1]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-                           Table of Contents
-
-
-1.  General Issues . . . . . . . . . . . . . . . . . . . . . . . . .   4
-2.  Problem and threat description . . . . . . . . . . . . . . . . .   4
-    2.1.  Mail sender forgery  . . . . . . . . . . . . . . . . . . .   4
-          2.1.1  Definition of sender forgery  . . . . . . . . . . .   4
-          2.1.2  Spam  . . . . . . . . . . . . . . . . . . . . . . .   5
-          2.1.3  E-Mail Worms  . . . . . . . . . . . . . . . . . . .   5
-          2.1.4  E-Mail spoofing and fraud . . . . . . . . . . . . .   5
-    2.2.  Indirect damage caused by forgery  . . . . . . . . . . . .   6
-    2.3.  Technical problem analysis . . . . . . . . . . . . . . . .   6
-    2.4.  Shortcomings of cryptographical approaches . . . . . . . .   7
-3.  A DNS based sender address verification  . . . . . . . . . . . .   7
-    3.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .   7
-    3.2.  Envelope vs. header sender address . . . . . . . . . . . .   9
-    3.3.  Domain part vs. full sender address  . . . . . . . . . . .   9
-4.  Mapping of E-Mail addresses to DNS names . . . . . . . . . . . .  10
-    4.1.  Domain part only . . . . . . . . . . . . . . . . . . . . .  10
-    4.2.  Full address . . . . . . . . . . . . . . . . . . . . . . .  11
-    4.3.  Empty address  . . . . . . . . . . . . . . . . . . . . . .  11
-5.  Mandatory entry types and their syntax . . . . . . . . . . . . .  11
-    5.1.  Overall structure  . . . . . . . . . . . . . . . . . . . .  11
-    5.2.  Unused . . . . . . . . . . . . . . . . . . . . . . . . . .  12
-    5.3.  IPv4 and IPv6 address ranges . . . . . . . . . . . . . . .  12
-    5.4.  DNS Hostname . . . . . . . . . . . . . . . . . . . . . . .  13
-          5.4.1  Road warriors and DynDNS entries  . . . . . . . . .  13
-    5.5.  APL Reference  . . . . . . . . . . . . . . . . . . . . . .  14
-    5.6.  Domain Member  . . . . . . . . . . . . . . . . . . . . . .  14
-    5.7.  Full Address Query . . . . . . . . . . . . . . . . . . . .  15
-    5.8.  DNS mapped authorization . . . . . . . . . . . . . . . . .  15
-    5.9.  RMX reference  . . . . . . . . . . . . . . . . . . . . . .  16
-6.  Optional and experimental entry types  . . . . . . . . . . . . .  16
-    6.1.  TLS fingerprint  . . . . . . . . . . . . . . . . . . . . .  16
-    6.2.  TLS and LDAP . . . . . . . . . . . . . . . . . . . . . . .  16
-    6.3.  PGP or S/MIME signature  . . . . . . . . . . . . . . . . .  16
-    6.4.  Transparent Challenge/Response . . . . . . . . . . . . . .  17
-    6.5.  SASL Challenge/Response  . . . . . . . . . . . . . . . . .  17
-7.  Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . .  17
-    7.1.  Alternative encoding as TXT records  . . . . . . . . . . .  17
-    7.2.  RMX Records  . . . . . . . . . . . . . . . . . . . . . . .  17
-          7.2.1  Overall structure . . . . . . . . . . . . . . . . .  18
-          7.2.2  Record encoding . . . . . . . . . . . . . . . . . .  18
-          7.2.3  Encoding of IPv4 and IPv6 address ranges  . . . . .  18
-          7.2.4  Encoding of DNS . . . . . . . . . . . . . . . . . .  18
-          7.2.5  Encoding of unused and full query . . . . . . . . .  19
-          7.2.6  Additional Records  . . . . . . . . . . . . . . . .  19
-8.  Message Headers  . . . . . . . . . . . . . . . . . . . . . . . .  19
-
-
-
-Hadmut Danisch                Experimental                      [Page 2]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-9.  SMTP error messages  . . . . . . . . . . . . . . . . . . . . . .  20
-10.  Message relaying and forwarding . . . . . . . . . . . . . . . .  20
-    10.1.  Problem description . . . . . . . . . . . . . . . . . . .  20
-    10.2.  Trusted relaying/forwarding . . . . . . . . . . . . . . .  21
-    10.3.  Untrusted relaying/forwarding . . . . . . . . . . . . . .  21
-11.  Security Considerations . . . . . . . . . . . . . . . . . . . .  22
-    11.1.  Draft specific considerations . . . . . . . . . . . . . .  22
-          11.1.1  Authentication strength  . . . . . . . . . . . . .  22
-          11.1.2  Where Authentication and Authorization end . . . .  22
-          11.1.3  Vulnerability of DNS . . . . . . . . . . . . . . .  23
-          11.1.4  Sneaking RMX attack?   . . . . . . . . . . . . . .  25
-          11.1.5  Open SMTP relays . . . . . . . . . . . . . . . . .  25
-          11.1.6  Unforged Spam  . . . . . . . . . . . . . . . . . .  25
-          11.1.7  Reliability of Whois Entries . . . . . . . . . . .  26
-          11.1.8  Hazards for Freedom of Speech  . . . . . . . . . .  26
-    11.2.  General Considerations about spam defense . . . . . . . .  27
-          11.2.1  Action vs. reaction  . . . . . . . . . . . . . . .  27
-          11.2.2  Content based Denial of Service attacks  . . . . .  27
-12.  Privacy Considerations  . . . . . . . . . . . . . . . . . . . .  28
-    12.1.  Draft specific considerations . . . . . . . . . . . . . .  28
-          12.1.1  No content leaking . . . . . . . . . . . . . . . .  28
-          12.1.2  Message reception and sender domain  . . . . . . .  28
-          12.1.3  Network structure  . . . . . . . . . . . . . . . .  29
-          12.1.4  Owner information distribution . . . . . . . . . .  29
-    12.2.  General Considerations about spam defense . . . . . . . .  29
-          12.2.1  Content leaking of content filters . . . . . . . .  29
-          12.2.2  Black- and Whitelists  . . . . . . . . . . . . . .  30
-13.  Deployment Considerations . . . . . . . . . . . . . . . . . . .  30
-    13.1.  Compatibility . . . . . . . . . . . . . . . . . . . . . .  30
-          13.1.1  Compatibility with old mail receivers  . . . . . .  30
-          13.1.2  Compatibility with old mail senders  . . . . . . .  30
-          13.1.3  Compatibility with old DNS clients . . . . . . . .  30
-          13.1.4  Compatibility with old DNS servers . . . . . . . .  30
-    13.2.  Enforcement policy  . . . . . . . . . . . . . . . . . . .  31
-14.  General considerations about fighting spam  . . . . . . . . . .  31
-    14.1.  The economical problem  . . . . . . . . . . . . . . . . .  31
-    14.2.  The POP problem . . . . . . . . . . . . . . . . . . . . .  32
-    14.3.  The network structure problem . . . . . . . . . . . . . .  33
-    14.4.  The mentality problem . . . . . . . . . . . . . . . . . .  33
-    14.5.  The identity problem  . . . . . . . . . . . . . . . . . .  33
-    14.6.  The multi-legislation problem . . . . . . . . . . . . . .  34
-Implementation and further Information . . . . . . . . . . . . . . .  34
-References . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  34
-Draft History  . . . . . . . . . . . . . . . . . . . . . . . . . . .  35
-Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . .  35
-
-
-
-
-
-
-Hadmut Danisch                Experimental                      [Page 3]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-1.  General Issues
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
-   this document are to be interpreted as described in RFC 2119 [1].
-
-2.  Problem and threat description
-
-2.1.  Mail sender forgery
-
-   The amount of e-mails with forged sender addresses has dramatically
-   increased. As a consequence, damages and annoyances caused by such
-   e-mails increased as well. In the majority of examined e-mails the
-   domain name of the envelope sender address was forged, and the e-
-   mail was sent from an IP address which does not belong to a network
-   used by the actual owner of the domain.
-
-2.1.1.  Definition of sender forgery
-
-   As discussions, comments to prior versions of this draft, and
-   different approaches to stop forgery showed, different perceptions
-   of "mail forgery" exist. For example, there are mechanisms to
-   verify e-mail addresses for mailing lists, web servers, or to stop
-   spam, which do send a message with a random number to the given
-   address and expect the user to send a reply. Here, someone is
-   considered to be allowed to use a particular e-mail address, if and
-   only if he is able to receive informations sent to this address,
-   and is able to reply to such a message. While this definition
-   appears to be quite plausible and natural, it can't be used for a
-   simple technical solution. Sending back a challenge and expecting a
-   reply is simply too much overhead and time delay, and not every
-   authorized sender is able or willing to reply (e.g. because he went
-   offline or is not a human).
-
-   Within the scope of this memo, sender forgery means that the
-   initiator of an e-mail transfer (which is the original sender in
-   contrast to relays) uses a sender address which he was not
-   authorized to use. Being authorized to use an address means that
-   the owner (administrator) of the internet domain has given
-   permission, i.e. agrees with the use of the address by that
-   particular sender. This memo will cover both the permission of the
-   full e-mail address and the domain part only for simplicity.
-
-   Within context of Internet and SMTP, the sender address usually
-   occurs twice, once as the envelope sender address in SMTP, and once
-   as the address given in the RFC822 mail header. While the following
-   considerations apply to both addresses in principle, it is
-   important to stress that both addresses have distinct semantics and
-
-
-
-Hadmut Danisch                Experimental                      [Page 4]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   are not neccessarily the same. The envelope address identifies the
-   initiator of the transport, while the header identifies the author
-   of the message content. Since this memo deals with the message
-   transport only and completely ignores the message content, the
-   method should naturally be applied to the envelope sender address.
-
-2.1.2.  Spam
-
-   A common and well known problem is the dramatic increase of
-   unsolicited e-mail, commonly called "spam". Again, the majority of
-   examined e-mails had forged sender addresses.  The abused domains
-   were mainly those of common webmailers as hotmail or yahoo, or
-   well-known companies.
-
-   Unfortunately, there is no accurate definition of spam availabe
-   yet, and neither are the concise technical criterions to filter or
-   block spam with technical mechanisms. There are efforts to design
-   content based filters, but these filters are expensive in
-   calculation time (and sometimes money), and they do not reliably
-   provide predictable results. Usually they give false positives
-   and/or require user interaction. Content filters in general suffer
-   from a design problem described later in this memo.  Therefore,
-   this proposal does not use the content based approach to block
-   spam.
-
-   As analysis of spam messages showed, most of spam messages were
-   sent with forged envelope sender addresses. This has mainly three
-   reasons.  The first reason is, that spam senders usually do not
-   want to be contacted by e-mail. The second reason is, that they do
-   not want to be blacklisted easily. The third reason is, that spam
-   is or is going to be unlawful in many countries, and the sender
-   does not want to reveal his identity. Therefore, spam is considered
-   to be a special case of sender forgery.
-
-2.1.3.  E-Mail Worms
-
-   Another example of sender forgery is the reproduction of e-mail
-   worms. Most worms do choose random sender addresses, e.g.  using
-   the addresses found in mailboxes on the infected system. In most
-   cases analyzed by the author, the e-mails sent by the reproduction
-   process can also be categorized as forged, since the infected
-   system would under normal circumstances not be authorized to send
-   e-mails with such e-mail addresses. So forgery does not require a
-   malicious human to be directly involved. This memo covers any kind
-   of e-mail sender address forgery, included those generated by
-   malicious software.
-
-2.1.4.  E-Mail spoofing and fraud
-
-
-
-Hadmut Danisch                Experimental                      [Page 5]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   Forging e-mail sender addresses for fraud or other kinds of
-   deception ("human engineering") has also dramatically increased.
-   There are many known cases where single or mass e-mails were sent
-   with wrong sender addresses, pretending to come from service
-   provider, software manufacturers etc., and asking the receiver to
-   install any software or patches, or to reply with any confidential
-   information. The Internet is becoming more and more a scene of
-   crime, and so are it's services, including e-mail. It is obvious
-   that crime based on e-mail is eased by the fact that SMTP allows
-   arbitrary sender address spoofing.
-
-2.2.  Indirect damage caused by forgery
-
-   As observed by the author, mass mails and worms with forged sender
-   addresses can cause a severe damage for the real owner of the
-   abused sender addresses. If a sender A is sending an e-mail to the
-   receiver B, pretending to be C by using a sender address of C's
-   domain, then C has currently no chance to prevent this, since C's
-   machines and software are not involved in any way in the delivery
-   process between A and B.  B will nevertheless send any error
-   messages (virus/spam alert, "no such user", etc.) to C, erroneously
-   assuming that the message was sent by C. The author found several
-   cases where this flood of error messages caused a severe denial of
-   service or a dramatic increase of costs, e.g. when C was
-   downloading the e-mail through expensive or low bandwidth
-   connections (e.g. modem or mobile phones), or where disk space was
-   limited. The author examined mass mailings, where several tens or
-   hundreds of thousands of messages were sent to several addresses
-   around the world, where these messages caused only annoyance. But
-   since several thousands of these addresses were invalid or didn't
-   accept the message, the owner of the DNS domain which was abused by
-   the spammer to forge sender addresses was flooded for several
-   months with thousands of error messages, jamming the e-mail system
-   and causing severe costs and damages.
-
-   As a consequence, when A sends a message to B, pretending to be C,
-   there must be any mechanism to allow C to inform B about the fact,
-   that A is not authorized to use C as a sender address. This is what
-   this memo is about.
-
-2.3.  Technical problem analysis
-
-   Why does e-mail forgery actually exist? Because of the lack of the
-   Simple Mail Transfer Protocol SMTP[2] to provide any kind of sender
-   authentication, authorisation, or verification. This protocol was
-   designed at a time where security was not an issue. Efforts have
-   been made to block forged e-mails by requiring the sender address
-   domain part to be resolvable.  This method provides protection from
-
-
-
-Hadmut Danisch                Experimental                      [Page 6]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   e-mails with non-existing sender domains, and indeed, for some time
-   it blocked most spam e-mails. However, since attackers and spam
-   senders began to abuse existing domain names, this method was
-   rendered ineffective.
-
-2.4.  Shortcomings of cryptographical approaches
-
-   At a first glance, the problem of sender address forgery might
-   appear to be solvable with cryptographic methods such as challenge
-   response authentications or digital signatures. A deeper analysis
-   shows that only a small, closed user group could be covered with
-   cryptographical methods. Any method used to stop spam forgery must
-   be suitable to detect forgery not only for a small number of
-   particular addresses, but for all addresses on the world. An
-   attacker does not need to know the secrets belonging to a
-   particular address. It is sufficient to be able to forge any
-   address and thus to know any secret key. Since there are several
-   hundreds of millions of users, there will always be a large amount
-   of compromised keys, thus spoiling any common cryptographic method.
-   Furthermore, cryptography has proven to be far too complicated and
-   error prone to be commonly administered and reliably implemented.
-   Many e-mail and DNS administrators do not have the knowledge
-   required to deal with cryptographic mechanisms. Many legislations
-   do not allow the general deployment of cryptography and a directory
-   service with public keys. For these reasons, cryptography is
-   applicable only to a small and closed group of users, but not to
-   all participants of the e-mail service.
-
-3.  A DNS based sender address verification
-
-3.1.  Overview
-
-   To gain improvement in e-mail authenticity while keeping as much
-   SMTP compatibility as possible, a method is suggested which doesn't
-   change SMTP at all.
-
-   The idea is to store informations about how to verify who is
-   authorized to transmit e-mails through SMTP with a particular
-   sender address (either full address or - for simplicity - only the
-   domain part of the address) in a directory service, which is
-   currently the DNS. To be precise, the verification consists of two
-   steps, the classical pair of authentication and authorization:
-
-   The first step is the authentication. While several methods are
-   possible to perform authentication (see below), the most important
-   and robust method is the verification of the sender's IP address.
-   This is done implicitely by TCP/IP and the TCP sequence number. The
-   authenticated identity is the IP address. It has to be stressed
-
-
-
-Hadmut Danisch                Experimental                      [Page 7]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   that this TCP/IP "authentication" is a weak authentication and
-   vulnerable to several attacks. It is nevertheless sufficient for
-   this purpose, especially for blocking spam. It doesn't take any
-   implementation and it doesn't cost: It is already there, it is a
-   functionality of TCP/IP. An incoming SMTP connection based on
-   TCP/IP already carries the sender's IP address without any
-   modification of SMTP. See below (section Entry types) for more
-   details about authentication methods.
-
-   The second step is the authorization. It is based on the identity
-   given by the previous authentication step, e.g. the IP address of
-   the originator of the incoming SMTP connection,  and on the
-   envelope sender address. The mechanism proposed in this memo
-   answers the question "Is that particular sender (IP address,...)
-   allowed to send with that sender address" by querying and
-   processing informations stored in a directory service, which is
-   DNS.
-
-   When the sender has issued the "MAIL FROM:" SMTP command, the
-   receiving mail transfer agent (MTA) can - and modern MTAs do -
-   perform some authorization checks, e.g. run a local rule database
-   or check whether the sender domain is resolvable.
-
-   The suggested method is to let the DNS server for the sender domain
-   provide informations about who - this means for example which IP
-   address - is authorized to use an address or a domain as a part of
-   it.  After receiving the "MAIL FROM:" SMTP command, the receiving
-   MTA can verify, whether e. g. the IP address of the sending MTA is
-   authorized to send mails with this domain name. Therefore, a list
-   of entries with authorized IP addresses or other informations is
-   provided by the authoritative DNS server of that domain. The entry
-   types are described in the subsequent chapters. Some of these
-   methods are
-
-     - An IPv4 or IPv6 network address and mask
-     - A fully qualified domain name referring to an A record
-     - A fully qualified domain name referring to an APL record
-
-   RMX records of these types would look like this:
-
-      somedomain.de.      IN RMX ipv4:10.0.0.0/8
-      rmxtest.de.         IN RMX host:relay.provider.com
-      danisch.de.         IN RMX apl:relays.rackland.de
-      relays.rackland.de. IN APL 1:213.133.101.23/32 1:1.2.3.0/24
-
-   where the machine with the example address 213.133.101.23 and the
-   machines in the example subnet 1.2.3.0/24 are the only machines
-   allowed to send e-mails with an envelope sender address of domain
-
-
-
-Hadmut Danisch                Experimental                      [Page 8]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   danisch.de. Since the APL records do not necessarily belong to the
-   same domain or zone table as the RMX records, this easily allows to
-   refer to APL records defined by someone else, e.g. the internet
-   access or server hosting provider, thus reducing administrative
-   overhead to a minimum. In the example given above, the domain
-   danisch.de and several other domains are hosted by the service
-   provider Rackland. So if the relay structure of Rackland is
-   modified, only the zone of rackland.de needs to be modified. The
-   domain owners don't need to care about such details.
-
-3.2.  Envelope vs. header sender address
-
-   Questions were raised why the proposed mechanism is based on the
-   envelope sender address, and not on the sender address given in the
-   message header. Technically, both can be used. Actually, it makes
-   sense to use the envelope address.
-
-   In common, the header sender address identifies the author of the
-   content, while the envelope sender tells who caused the
-   transmission.  The approach proposed in this memo is transmission
-   based, not content based. We can not authorize the author of a
-   message if we don't have contact with him, if the message does not
-   already contain a signature. In contrast, the sending MTA is linked
-   to an IP address which can be used for authentication. This
-   mechanism might not be very strong, but it is available and
-   sufficient to solve today's e-mail security problems.
-
-   Some people argued that it is the header address and not the sender
-   address, which is displayed in common mail readers (MUAs), and
-   where the receiver believes the mail comes from. That's true, but
-   it doesn't help. There are many cases where the header sender
-   differs from the envelope sender for good reasons (see below in the
-   consequences chapter for the discussion about relaying).  Relaying,
-   mailing lists etc. require to replace the sender address used for
-   RMX. If this were the header address, the message header would have
-   to be modified. This is undesirable.
-
-3.3.  Domain part vs. full sender address
-
-   Former versions of this draft were limited to the domain part of
-   the sender address. The first reason is that it is common and MX-
-   like, to lookup only the domain part of an e-mail address in DNS.
-   The second reason is, that it was left to the private business of
-   the domain administration to handle details of user verification.
-   The idea was that the domain administration takes care to verify
-   the left part of an e-mail address with an arbitrary method of
-   their individual taste. RMX was originally designed to ignore the
-   left part of the address and to expect the domain administration to
-
-
-
-Hadmut Danisch                Experimental                      [Page 9]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   take over responsibility for enforcing their policy. If, e.g., a
-   spam message arrived and passed the RMX mechanism, it is known to
-   be authorized by the domain administration and they can be blamed,
-   no matter what is on the left side of the sender address - it's
-   their private problem what happens on the left side of the @. By
-   far the most of the comments to prior versions of this draft agreed
-   with that. A few comments asked for a finer granularity.
-
-   And indeed, there is no technical reason against a finer
-   granularity.  All it takes is a mapping from a given envelope
-   sender address to a DNS name, and the RMX lookup for that
-   particular e-mail address could be done instead of a lookup for the
-   domain part only.  However, to my knowledge, most domain
-   administrators would not like to provide an RMX entry for every
-   single e-mail address. In many cases, this would also overload DNS
-   servers.
-
-   It is to be discussed how to cover both views. One method could be
-   to query the full address, and if no RMX records were found to
-   query the domain part only. A different approach would be to query
-   the domain part only, and if it's RMX record contain a special
-   entry, then a new query for the full address is triggered. A third
-   way would be to always query the full address and to leave the
-   problem to the wildcard mechanism of DNS. This still has to be
-   discussed and will be described in future versions of this draft.
-
-
-
-
-
-
-
-
-
-
-
-4.  Mapping of E-Mail addresses to DNS names
-
-   To perform the RMX query, a mapping is needed from E-Mail addresses
-   to DNS fully qualified domain names.
-
-   This chapter is under development and just a first approach.
-
-4.1.  Domain part only
-
-   Mapping of the domain part is trivial, since the domain part of an
-   e-mail address itself is a valid DNS name and does not need
-   translation. It might be nevertheless desirable to distinguish the
-
-
-
-Hadmut Danisch                Experimental                     [Page 10]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   RMX entries from other entries, depending of the encoding of the
-   records. If the RMX entries are encoded in TXT record types, they
-   might collide with other uses of TXT records.  It might be
-   necessary to prepend the domain part with a special prefix, e.g.
-   _rmx. So the e-mail address some.user@example.com could be mapped
-   to example.com or _rmx.example.com.
-
-4.2.  Full address
-
-   Mapping a full address is slightly more difficult. The @ sign must
-   be unambiguously translated, and therefore can not be simply
-   translated into a dot. The e-mail addresses some.user@example.com
-   and some@user.example.com must have different mappings. Therefore,
-   the @ sign could be translated into _rmx, implicitely assuming that
-   this is not an allowed domain name component of normal domain
-   names. Then the rightmost _rmx in the mapped DNS name always
-   corresponds to the @ sign. some.user@example.com would e translated
-   into some.user._rmx.example.com and can be covered by a wildcard
-   entry like *._rmx.example.com.
-
-   Character encoding and character sets are still to be discussed.
-
-4.3.  Empty address
-
-   Unfortunately, SMTP allows empty envelope sender addresses to be
-   used for error messages. Empty sender addresses can therefore not
-   be prohibited. As observed, a significant amount of spam was sent
-   with such an empty sender address. To solve this problem, the host
-   name given in the HELO or EHLO command is taken to lookup the RMX
-   records instead. This makes sense, since such messages were
-   generated by the machine, not a human.
-
-
-
-
-5.  Mandatory entry types and their syntax
-
-   The entry types described in this section MUST be supported by any
-   implementation of this draft.
-
-5.1.  Overall structure
-
-   Similar to APL, an RMX record is just a concatenation of zero or
-   more RMX entries. The entries within one record form an ordered
-   rule base as commonly usual in packet filtes and firewall rulesets,
-   i. e. they are processed one ofter another until the first entry
-   matches. This entry determines the result of the query. Once a
-   matching entry is found, the RMX processing is finished.
-
-
-
-Hadmut Danisch                Experimental                     [Page 11]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   For any domain name there should not exist more than a single RMX
-   record. Due to the structure of DNS, it is nevertheless possible to
-   have more than a single RMX record. Multiple RMX records are
-   treated as a single record consisting of the concatenation of all
-   records. While the entries in a record are ordered, the records are
-   not ordered and may be processed in arbitrary order. If the order
-   of the entries matters, it is the zone maintainer's responsibility
-   to keep those entries in a single record. For example, there are
-   negative entries, which exclude IP addresses from authorization.
-   It is important that these entries are processed before positive
-   entries giving permission to a wider address range. Since order is
-   guaranteed only within a record, corresponding negative and
-   positive entries must be put in the same record.
-
-   An RMX record may consist of one or more entries, where the entries
-   are separated by whitespace. An entry must not contain white space.
-   Each entry consists of an optional exclamation sign, a tag, a
-   colon, and the entry data:
-
-      [!] TAG : ENTRY-SPECIFIC-DATA
-
-   If the entry starts with an exclamation sign, the entry is negated.
-   See the entry type description below for details.
-
-   The TAG is the mnemonic type identifier or the decimal number of
-   the entry. The TAG is case-insensitive. It is immediately followed
-   by a colon.
-
-   The syntax and semantics of ENTRY-SPECIFIC-DATA depends of the the
-   entry type. See description below.
-
-   Example:
-
-      danisch.de.  IN RMX apl:relays.rackland.de !ipv4:1.2.3.5
-   ipv4:1.2.3.0/24
-
-5.2.  Unused
-
-   This is a primitive entry which just says that this sender address
-   will never be used as a sender address under any circumstances.
-   Example:
-
-   testdomain.danisch.de    IN RMX unused:
-
-5.3.  IPv4 and IPv6 address ranges
-
-   These entry types contain a bit sequence representing a CIDR
-   address part. If that bit sequence matches the given IP address,
-
-
-
-Hadmut Danisch                Experimental                     [Page 12]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   authorization is granted or denied, depending on the negation flag.
-
-   The entry is prepended with the tag "IPv4" or "IPv6". The colon is
-   followed with an IPv4 or IPv6 address in standard notation,
-   optionally followed by a slash and a mask length. If the negation
-   flag is set, then the given address range is excluded.  Examples:
-
-   danisch.de   IN RMX ipv4:213.133.101.23 ipv6:fe00::0
-                IN RMX ipv4:10.0.0.0/8     ipv6:fec0::0/16
-                IN RMX !ipv4:1.2.3.4
-
-   (Please note that it does not make much sense to use
-   RFC1918-Addresses in RMX records, this is just to give a syntax
-   example.)
-
-
-5.4.  DNS Hostname
-
-   This entry type simply contains a regular DNS name, which is to be
-   resolved as a host name (fetch the A record or IPv6 equivalent). If
-   the given IP address matches the result, authorization is granted
-   or denied, depending on the negation flag.  It is still to be
-   defined how to treat unresolvable entries.
-
-   The entry is prepended with the tag "host", followed by a colon and
-   the hostname. Examples:
-
-   danisch.de  IN RMX host:relay.provider.de
-               IN RMX !host:badmachine.domain.de apl:relays.domain.de
-
-5.4.1.  Road warriors and DynDNS entries
-
-   Several people argued against RMX that it would break their
-   existing installation which delivers e-mail from dynamically
-   assigned IP addresses, because their IP providers didn't assign a
-   static address, or because they are a road warrior, plugging their
-   notebook in any hotel room on the world.
-
-   RMX provides a simple solution. If such a machine has a dynamically
-   updated DNS entry (e.g. DynDNS), all it takes is an RMX entry of
-   the hostname type pointing to this dynamic DNS entry.
-
-   The cleaner solution would be to deliver mail the same way as it is
-   received: If downloaded by POP from a central relay with a static
-   address, where the MX points to, then it would be a good idea to
-   deliver e-mail the same way in reverse direction. Unfortunately,
-   plain POP does not support uploading yet.
-
-
-
-
-Hadmut Danisch                Experimental                     [Page 13]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-5.5.  APL Reference
-
-   This entry type simply contains a regular DNS name, which is to be
-   resolved as an APL record index  (fetch the APL record).  If the
-   given IP address positively  matches the APL, authorization is
-   granted. Details of the semantic (espially when the negation bit is
-   set) are still to be defined.  It is still to be defined how to
-   treat unresolvable entries.
-
-   The entry is prepended with the tag "host", followed by a colon and
-   the hostname. Example:
-
-   danisch.de     IN RMX apl:relays.rackland.de
-
-5.6.  Domain Member
-
-   In many cases it is desirable to cover all hosts of a given domain
-   with an RMX record without the need to duplicate the list of these
-   hosts. This entry type does it (thanks to Eric A. Hall for pointing
-   out this entry type).  It contains a regular DNS name.
-
-   If this entry type is given, a reverse DNS query for the IP address
-   of the sending MTA is performed to find its official fully
-   qualified domain name. To prevent spoofing, this domain name is
-   accepted only if a subsequent address query to the given domain
-   name points to exactly the IP address of the sending MTA (the usual
-   procedure to verify PTR records).
-
-   The entry matches if the fully qualified domain name of the sending
-   MTA ends in the given domain. The negation flag works as usual.
-
-   The tag for this entry type is "domain". After the colon the domain
-   name is given, but might be empty, thus pointing to itself.
-   Example:
-
-      somedomain.org  IN RMX domain:somedomain.org domain:provider.com
-
-   would authorize all machines which's hostname can be verified
-   through an PTR and A query, and which ends in "somedomain.org" or
-   "provider.com".
-
-   With such an entry, large companies with different networks can
-   easily be covered with just a single and simple RMX entry.
-   Obviously, it requires proper PTR records.
-
-   As a special shortcut, the DNS name may be empty. In this case the
-   domain name of the zone itself is taken. Thus, with a very simple
-   entry of the type
-
-
-
-Hadmut Danisch                Experimental                     [Page 14]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-     somecompany.com  IN RMX domain:
-
-   a company could authorize all machines which's IP addresses map to
-   DNS names end in somecompany.com, which applies in the majority of
-   companies.
-
-
-
-
-5.7.  Full Address Query
-
-   As described above, RMX records will in most cases apply to the
-   domain part of the sender address. In special cases it might be
-   desirable to query the RMX record for a particular address.  An RMX
-   entry of the Full Address Query type may occur in a domain RMX
-   record only. It signals that the RMX record for the full address is
-   to be fetched and processed.
-
-   This entry type does not take arguments. The negation flag is not
-   supported. The tag is "full".
-
-   If such a full address query is to be performed, the mail address
-   must be mapped to a valid and non-ambiguos DNS name. This mapping
-   is still to be defined. It is not sufficient to simply replace the
-   @ with a dot, because of case sensitivity, character sets, etc. The
-   e-mail addresses
-
-      john.doe@example.org
-      John.Doe@example.org
-      john@doe.example.org
-
-   must all be mapped to different DNS entries. This entry type might
-   vanish in future versions of the draft, depending on the discussion
-   about whether to query the domain name part only or the full
-   address.
-
-5.8.  DNS mapped authorization
-
-   As I learned from comments to prior versions of the draft and from
-   alternative proposals, many users wish to have a DNS mapped
-   authorization table, i. e. the client queries a DNS entry of the
-   form a.b.c.d.domain, where a.b.c.d is the sender's IP address.
-   Since people wish to have this, RMX will now include such a mapping
-   entry. The entry has a parameter giving the DNS domain name where
-   to look at. If the parameter is empty, then the same domain is
-   taken as for the RMX lookup.
-
-   As this is currently under construction and discussion in an IETF
-
-
-
-Hadmut Danisch                Experimental                     [Page 15]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   group, details will be published in future versions of this draft.
-
-5.9.  RMX reference
-
-   This entry type has no parameters. It means that all those machines
-   are authorized, which are pointed to by an MX record.
-
-6.  Optional and experimental entry types
-
-   The following subsections roughly describe further entry types
-   which might not be supported by all implementations and might not
-   be allowed in all legislations. These methods might vanish in
-   future versions of the draft and are just considerations about what
-   to include in RMX and what to not include. The main purpose of this
-   section is to start discussion about such entry types.
-
-   The disadvantage of the following methods is that they violate the
-   basic idea of RMX, i. e. to be simple, robust, easy to implement
-   and easy to administer. I personally do not believe that it is a
-   good idea or even feasible to implement cryptography for a world
-   wide e-mail transfer network. Keep in mind that cryptographic keys
-   can be copied.  If only <0.1% of cryptographic keys were revealed,
-   this completely compromises and spoils RMX. Cryptography is simply
-   the wrong tool for the problem RMX is intended to solve. I
-   nevertheless like to discuss these methods.
-
-6.1.  TLS fingerprint
-
-   The sender is considered to be authorized if the message was
-   transmitted through SMTP and TLS, and the sender used a certificate
-   matching the fingerprint given in the RMX record.
-
-6.2.  TLS and LDAP
-
-   This means that the receiver should perform an LDAP query for the
-   sender address (through the LDAP SRV record or given in the RMX
-   record), fetch the X.509 certificate for the sender. The sender is
-   considered to be authorized when the message was transmitted
-   through SMTP and TLS using this certificate.
-
-6.3.  PGP or S/MIME signature
-
-   It would be possible to accept a message only if it was signed with
-   PGP or S/MIME with a key which's fingerprint is given in the RMX
-   record or to be fetched from LDAP or any PGP database.  This is
-   just for discussion, since it violates the idea of RMX to focus on
-   the transport, not on the content. It would also allow replay
-   attacks and not cover the envelope sender address or message
-
-
-
-Hadmut Danisch                Experimental                     [Page 16]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   header.
-
-6.4.  Transparent Challenge/Response
-
-   It would also be possible to implement a challenge-response
-   mechanism without modifying the syntax of SMTP. For example, the
-   receiving MTA could issue a challenge with it's very first greeting
-   message, the sending MTA could hide the response in the HELO
-   parameter and when the receiving MTA later learns the sender
-   envelope address, it could verify the response based on
-   informations in the RMX record.
-
-6.5.  SASL Challenge/Response
-
-   Modern SMTP implementations already include a SASL mechanisms,
-   which easily allows to plugin new authentication mechanisms. While
-   common SASL mechanisms require to use a previously shared password,
-   a new mechanism could perform a challenge response authentication
-   as a SASL method.
-
-
-
-
-
-
-7.  Encoding
-
-7.1.  Alternative encoding as TXT records
-
-   The main objection against the prior versions of this draft was
-   that it requires a new RR entry type and upgrading all DNS servers.
-
-   Therefore and alternative encoding is proposed. Instead of using a
-   new RR type, the TXT record type is used to contain the RMX record.
-   The records would simply look as described in the entry type
-   chapters above, e.g.
-
-      _rmx.danisch.de.   IN TXT "apl:relays.rackland.de"
-
-   To allow smooth introduction of RMX without the need to immediately
-   upgrade all DNS servers, all clients (which have to be newly
-   installed anyway) MUST support both the TXT and the RMX records. A
-   client has to perform an ANY or a TXT and a RMX query. Servers/zone
-   tables may currently use TXT entries but SHOULD use RMX entries in
-   future.
-
-7.2.  RMX Records
-
-
-
-
-Hadmut Danisch                Experimental                     [Page 17]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-7.2.1.  Overall structure
-
-   Each entry starts with an octet containting the entry type and the
-   negation flag:
-
-      +---+---+---+---+---+---+---+---+------
-      | N |    Entry Type Code        | Parameters...
-      +---+---+---+---+---+---+---+---+------
-
-      N           If this bit (MSB) is set, an IP address
-                  matching this entry is not authorized,
-                  but explicitely rejected. See entry
-                  type descriptions for details.
-
-      Entry Type  A 7bit number simply determining the entry
-                  type.
-
-
-   Currently, entries do not have an explicit length field, the entry
-   length is determined implicitely by the entry type. Applications
-   are required to abort if an unknown entry type is found, instead of
-   skipping unknown entries.
-
-7.2.2.  Record encoding
-
-   A RMX record is simply a concatenation of RMX entries.
-
-7.2.3.  Encoding of IPv4 and IPv6 address ranges
-
-   After the entry type tag as described above, one octet follows
-   giving the length L of the bit sequence. Then a sequence of exactly
-   as many octets follows as needed to carry L bits of information (=
-   trunc((L+7)/8) ).
-
-      +---+---+---+---+---+---+---+---+
-      | N | Entry Type Code  (1 or 2) |
-      +---+---+---+---+---+---+---+---+
-      |         Length Field L        |
-      +---+---+---+---+---+---+---+---+
-      |           Bit Field           |
-      /        ((L+7)/8) Octets       /
-      +---+---+---+---+---+---+---+---+
-
-
-7.2.4.  Encoding of DNS
-
-   After the entry type tag immediately follows a DNS encoded and
-   compressed [3] domain name.
-
-
-
-Hadmut Danisch                Experimental                     [Page 18]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-      +---+---+---+---+---+---+---+---+
-      | N |  Entry Type Code  (3..5)  |
-      +---+---+---+---+---+---+---+---+
-      |         Length Field L        |
-      +---+---+---+---+---+---+---+---+
-      |  Encoded DNS                  |
-      /  Name as described in RFC1035 /
-      +---+---+---+---+---+---+---+---+
-
-   In contrast to earlier versions of this draft, the DNS name cannot
-   be compressed, since this would cause decompression errors when a
-   DNS server is part of the query chain which does not know this
-   particular RR type.
-
-7.2.5.  Encoding of unused and full query
-
-   These entries do not contain parameters and does not allow the
-   negation flag.  So the encoding is quite simple:
-
-      +---+---+---+---+---+---+---+---+
-      | 0 |  Entry Type Code  (6 or 7)|
-      +---+---+---+---+---+---+---+---+
-
-
-
-7.2.6.  Additional Records
-
-   In order to avoid the need of a second query to resolve the given
-   host name, a DNS server should enclose the A record for that domain
-   name in the additional section of the additional section of the DNS
-   reply, if the server happens to be authoritative.
-
-   In order to avoid the need of a second query to resolve the given
-   host name, a DNS server should enclose the APL record for that
-   domain name in the additional section of the additional section of
-   the DNS reply, if the server happens to be authoritative.
-
-
-
-8.  Message Headers
-
-   An RMX query must be followed by any kind of action depending on
-   the RMX result. One action might be to reject the message.  Another
-   action might be to add a header line to the message body, thus
-   allowing MUAs and delivery programs to filter or sort messages.
-
-   In future, the RMX result might be melted into the Received: header
-   line.
-
-
-
-Hadmut Danisch                Experimental                     [Page 19]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   The details of such entries are to be discussed. As a proposal the
-   following form is suggested:
-
-     X-RMX: RESULT addr ADDRESS by HOST on DATE mechanism MECHANISM
-
-   where
-
-   RESULT is one of "Granted", "Denied", "NotInRMX", "NoRMX",
-   "TempFail", "BadData", "Trusted".
-
-   ADDRESS is the IP address of the sending machine
-
-   HOST is the name of the machine performing the RMX query.
-
-   DATE is the date of the query.
-
-   MECHANISM is the RMX method used to authorize the sender.
-
-
-
-9.  SMTP error messages
-
-   If a message is rejected because of RMX records, an error message
-   should be issued which explains the details.  It is to be discussed
-   whether new SMTP error codes are to be defined.
-
-
-10.  Message relaying and forwarding
-
-10.1.  Problem description
-
-   Message forwarding and relaying means that an MTA which received an
-   e-mail by SMTP does not deliver it locally, but resends the message
-   - usually unchanged except for an additional Received header line
-   and maybe the recipient's address rewritten - to the next SMTP MTA.
-   Message forwarding is an essential functionality of e-mail
-   transport services, for example:
-
-     - Message transport from outer MX relay to the intranet
-     - Message forwarding and Cc-ing by .forward or .procmail-alike
-       mechanisms
-     - Mailing list processing
-     - Message reception by mail relays with low MX priority,
-       usually provided by third parties as a stand-by service
-       in case of relay failure or maintenance
-     - "Forwarding" and "Bouncing" as a MUA functionality
-
-   In all these cases a message is sent by SMTP from a host which is
-
-
-
-Hadmut Danisch                Experimental                     [Page 20]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   not covered by the original sender domain's RMX records.  While the
-   RMX records would forbid accepting this message, it still must be
-   accepted. The following subsections explain how to cope with
-   relaying.
-
-10.2.  Trusted relaying/forwarding
-
-   In some cases the receiving MTA trusts the sending MTA to not fake
-   messages and to already have checked the RMX records at message
-   reception. As a typical example, a company might have an outer mail
-   relay which receives messages from the Internet and checks the RMX
-   records. This relay then forwards the messages to the different
-   department's mail servers. It does not make sense for these
-   department mail servers to check the RMX record, since the RMX
-   records have already been checked and - since the message was
-   relayed by the outer relay - always would deny the message. In this
-   case there is a trust relationship between the department relays
-   and the outer relay.  So RMX checking is turned off for trusted
-   relays. In this example, the department relays would not check
-   messages from the outer relay (but for intranet security, they
-   could still check RMX records of the other departments sub-domains
-   to avoid internal forgery between departments).
-
-   Another common example are the low-priority MX relays, which
-   receive and cache e-mails when the high-priority relays are down.
-   In this case, the high-priority relay would trust the low-priority
-   relay to have verified the sender authorization and would not
-   perform another RMX verification (which would obviously fail).
-
-   When a relay forwards a message to a trusting machine, the envelope
-   sender address should remain unchanged.
-
-10.3.  Untrusted relaying/forwarding
-
-   If the receiving MTA does not trust the forwarding MTA, then there
-   is no chance to leave the sender envelope address unchanged. At a
-   first glance this might appear impracticable, but this is
-   absolutely necessary. If an untrusted MTA could claim to have
-   forwarded a message from a foreign sender address, it could have
-   forged the message as well. Spammers and forgers would just have to
-   act as such a relay.
-
-   Therefore, it is required that, when performing untrusted
-   forwarding, the envelope sender address has to be replaced by the
-   sender address of someone responsible for the relaying mechanism,
-   e.g. the owner of the mailing list or the mail address of the user
-   who's .forward caused the transmission. It is important to stress
-   that untrusted relaying/forwarding means taking over responsibility
-
-
-
-Hadmut Danisch                Experimental                     [Page 21]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   for the message.  It is the idea of RMX records to tie
-   responsibility to message transmission. Untrusted relaying without
-   replacing the sender address would mean to transmit without taking
-   responsibility.
-
-   The disadvantage is that the original sender address is lost.
-   Therefore, whenever a sender address replacement happens, the
-   Received-Line must contain the old address. Many of today's MTAs
-   already insert the envelope recipient address, but not the sender
-   address into the Received header line. It seems reasonable to
-   require every Received line to include both the sender and
-   recipient address of the incoming SMTP connection.
-
-
-11.  Security Considerations
-
-11.1.  Draft specific considerations
-
-11.1.1.  Authentication strength
-
-   It is important to stress, that the suggested method does not
-   provide high level security and does not completely prevent forged
-   e-mails or spam under any circumstances. It is a robust, but not
-   highly reliable and completely secure security mechanism. Keep in
-   mind that it is based on DNS, and DNS is not secure today.
-   Authorization is based on the IP address. The very same machine
-   with the very same IP address could be authorized to send e-mail
-   with a given sender address and sending spam at the same time.
-   Maybe because several users are logged in. Or because several
-   customers use the same relay of the same ISP, where one customer
-   could use the sender address of a different customer. It is up to
-   the ISP to prevent this or not. Machines can still be hijacked.
-   Spammers are also domain owners. They can simply use their own
-   domain and authorize themselves. You will always find people on the
-   world who do not care about security and open their relays and RMX
-   records for others to abuse them.  RMX is to be considered as a
-   very cheap and simple light weight mechanism, which can
-   nevertheless provide a significant improvement in mail security
-   against a certain class of attacks, until a successor of SMTP has
-   been defined and commonly accepted.
-
-11.1.2.  Where Authentication and Authorization end
-
-   Previous versions of RMX records did not cover the local part of
-   the e-mail address, i.e. what's on the left side of the @ sign.
-   This is still to be discussed. Authentication and authorization are
-   limited to the sending MTA's IP address. The authentication is
-   limited to the TCP functionality, which is sufficient for light
-
-
-
-Hadmut Danisch                Experimental                     [Page 22]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   weight authentication. The RMX records authorize the IP address of
-   the sending host only, not the particular sender of the message. So
-   if a machine is authorized to use sender addresses of more than a
-   single domain, the authentication scheme does not prevent that any
-   user on this machine can send with any of these domains. RMX is not
-   a substitute for the host security of the involved machines.
-
-   The proposed authentication scheme can be seen as a "half way
-   authentication": It does not track back an e-mail to the effective
-   sender. It tracks only half of the way, i. e. it tracks back to the
-   domain and it's DNS administrators who authorized that particular
-   sender IP address to use it for sending e-mail. How the party
-   responsible for that domain performs user authentication, whom it
-   grants access to, how it helds people responsible for abuse, is
-   completely left as the private business of those who are in charge
-   of that domain. So this draft does not interfere with the domain's
-   individual security policy or any legislation about such policies.
-   On the other hand, the proposed authentication scheme does not give
-   any statement about the nature and quality of the domain's security
-   policy. This is an essential feature of the proposal: E-mail
-   authentication must be deployed world wide, otherwise it won't do
-   the job. Any security scheme interfering with the local
-   legislations or the domain's security policy will not be accepted
-   and can't effectively deployed. Therefore, the security policy must
-   remain the domain's private business, no matter how lousy the
-   policy might be.
-
-   In order to achieve this and to make use of the only existing world
-   wide Internet directory scheme (DNS), the approach of this proposal
-   is to just ignore the local part of the sender address (i.e. what's
-   left of the @ part) and limit view to the domain part. After all,
-   that's what we do anyway when delivering to a given address with
-   SMTP.
-
-11.1.3.  Vulnerability of DNS
-
-   DNS is an essential part of the proposed authentication scheme,
-   since it requires any directory service, and DNS is currently the
-   only one available. Unfortunately, DNS is vulnerable and can be
-   spoofed and poisoned. This flaw is commonly known and weakens many
-   network services, but for reasons beyond that draft DNS has not
-   been significantly improved yet. After the first version of this
-   draft, I received several comments who asked me not to use DNS
-   because of its lack of security. I took this into consideration,
-   but came to the conclusion that this is unfeasible: Any
-   authentication scheme linked to some kind of symbolic identity (in
-   this case the domain name) needs some kind of infrastructure and
-   trusted assignment. There are basically two ways to do it: Do it
-
-
-
-Hadmut Danisch                Experimental                     [Page 23]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   yourself and trust nobody else, or let someone else do it. There
-   are methods to do it the former way, e.g. to give someone some kind
-   of authentication information after a first successful e-mail
-   exchange, e.g. some kind of cookie or special e-mail address. This
-   is certainly interesting and powerful, but it does not solve the
-   problem on a world wide scale and is far to complicated and error
-   prone for the average user, i. e. 99% of the users.
-
-   The latter method to let someone else do the symbolic name
-   assignment and create the authentication framework is well known.
-   It context of public key cryptography, this is called a Public Key
-   Infrastructure (PKI). On of the best known facts about PKIs is
-   that, until now, we don't have any covering a significant part of
-   the Internet. And we won't have any in near future. The complexity
-   is far too high, it is too expensive, and it involves cooperation
-   of every single user, which is simply unrealistic and extremely
-   error prone. So what do we have we can use? All we have is the DNS
-   and the Whois database. And we have countries who don't allow
-   cryptography. So the proposal was designed to use DNS without
-   cryptography. It does not avoid DNS because of its vulnerability,
-   it asks for a better DNS, but accepts the DNS as it is for the
-   moment. Currently there are two main threats caused by the DNS
-   weakness:
-
-      - A spammer/forger could spoof DNS in order to gain false
-        authorization to send fake e-mails.
-
-      - An attacker could spoof DNS in order to block delivery from
-        authorized machines, i. e. perform a Denial of Service attack.
-
-   The first one is rather unrealistic, because it would require an
-   average spammer to poison a significant part of the DNS servers of
-   its victims. A spammer sending messages to one million receipients
-   would need to poison at least 1-10% which is 10,000 to 100,000
-   receipient's DNS servers. This should be unfeasible in most cases.
-
-   In contrast, the second threat is a severe one. If an attacker
-   wanted to block messages from one company to another, he just needs
-   to poison the recipients DNS server with a wrong RMX record in
-   order to make the recipient's SMTP machine reject all messages. And
-   this is feasible since the attacker needs to poison only a single
-   DNS server. But does this make SMTP more vulnerable? No. Because
-   the attacker can already do even more without RMX. By poisoning the
-   sender's DNS server with wrong MX records, the attacker can also
-   block message delivery or even redirect the messages to the
-   attacker's machine, thus preventing any delivery error messages and
-   furthermore getting access to the messages.
-
-
-
-
-Hadmut Danisch                Experimental                     [Page 24]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   As a consequence, e-mail delivery by SMTP requires a better DNS
-   anyway. The requirements are not significantly expanded by RMX.
-
-11.1.4.  Sneaking RMX attack?
-
-   While writing a test implementation, a certain kind of attack came
-   into my mind. I'm still not sure, whether this attack is possible
-   on any DNS server, but I believe it should be mentioned:
-
-   Imagine an unauthorized sender is sending a forged mail (e.g.
-   spam).  At connection time, before querying the RMX record, the
-   receiving MTA usually performs a PTR query for the IP address of
-   the sending MTA. If the sender has control over the authoritative
-   name server for that particular IP address, the sender could give a
-   normal PTR answer, but could append a wrong RMX, APL, or A record
-   in the additional section of the query. A subsequent RMX query
-   could receive wrong DNS data if the DNS server used by the
-   receiving MTA accepted those forged records.
-
-11.1.5.  Open SMTP relays
-
-   Open SMTP relays (i.e. machines who accept any e-mail message from
-   anyone and deliver to the world) abused by spammers are a one of
-   the main problems of spam defense and sender backtracking. In most
-   cases this problem just vanishes because foreign open relay
-   machines will not be covered by the RMX records of the forged
-   sender address. But there are two special cases:
-
-   If the spammer knows about a domain which authorizes this
-   particular machine, that domain can be used for forgery. But in
-   this case, the IP address of the relay machine and the RMX records
-   of the domain track back to the persons responsible. Both can be
-   demanded to fix the relay or remove the RMX record for this
-   machine. An open relay is a security flaw like leaving the machine
-   open for everybody to login and send random mails from inside. Once
-   the administrative persons refuse to solve the problem, they can be
-   identified as spammers and held responsible.
-
-   The second special case is when a domain authorizes all IP
-   addresses by having the network 0.0.0.0/0 in the RMX/APL record. In
-   this case, open relays don't make things worse. It's up to the
-   recipient's MTA to reject mails from domains with loose security
-   policies.
-
-11.1.6.  Unforged Spam
-
-   This proposal does not prevent spam (which is, by the way, not yet
-   exactly defined), it prevents forgery. Since spam is against law
-
-
-
-Hadmut Danisch                Experimental                     [Page 25]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   and violates the recipients rights, spam depends on untracability
-   of the sender. In practice the sender forges the sender address
-   (other cases see below). This proposal is designed to detect such
-   forgeries.
-
-   However, the RMX approach is rendered ineffective, if the sender
-   doesn't forge. If the sender uses just a normal address of it's own
-   domain, this is just a plain, normal e-mail, which needs to be let
-   through. Since it is up to the human's taste whether this is spam
-   or not, there's no technical way to reliably identify this as spam.
-   But since the sender domain is known, this domain can be
-   blacklisted or legal steps can be gone into.
-
-11.1.7.  Reliability of Whois Entries
-
-   Once the RMX infrastructure gets deployed, what's the security
-   gain?  It allows to determine the domain which's DNS zone
-   authorized the sending machine. What's that good for? There are
-   some immediate uses of the domain name, e.g. in black- and
-   whitelisting. But in most cases this is just the starting point of
-   further investigations, either performed automatically before
-   message acceptance, or manually after spam has been received and
-   complainted about.
-
-   The next step after determining the domain is determining the
-   people responsible for this domain. This can sometimes be achieved
-   by querying the Whois databases. Unfortunately, many whois entries
-   are useless because they are incomplete, wrong, obsolete, or in
-   uncommon languages. Furthermore, there are several formats of
-   address informations which make it difficult to automatically
-   extract the address. Sometimes the whois entry identifies the
-   provider and not the owner of the domain. Whois servers are not
-   built for high availability and sometimes unreachable.
-
-   Therefore, a mandatory standard is required about the contents and
-   the format of whois entries, and the availability of the servers.
-   After receiving the MAIL FROM SMTP command with the sender envelope
-   address, the receiving MTA could check the RMX record and Whois
-   entry. If it doesn't point to a real human, the message could be
-   rejected and an error message like "Ask your provider to fix your
-   Whois entry" could be issued. Obviously, domain providers must be
-   held responsible for wrong entries. It might still be acceptable to
-   allow anonymous domains, i. e. domains which don't point to a
-   responsible human. But it is the receivers choice to accept e-mails
-   from such domains or not.
-
-11.1.8.  Hazards for Freedom of Speech
-
-
-
-
-Hadmut Danisch                Experimental                     [Page 26]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   Currently, some governments try to enforce limitations of internet
-   traffic in order to cut unwanted content providers from the
-   network. Some of these governments try to hide a whole country
-   behind firewalls, others try to force Internet providers to poison
-   DNS servers with wrong A records for web servers, e.g. one county
-   administration in Germany tries to do so. If message reception
-   depends on DNS entries, the same governments will try to block not
-   only HTTP, but SMTP also.
-
-   However, since most MTAs already reject messages from unresolvable
-   domain names this is not a new threat.
-
-11.2.  General Considerations about spam defense
-
-   After discussing security requirements of the proposal, now the
-   security advantages of the RMX approach over content based filters
-   will be explained. Basically, there are three kinds of content
-   filters:
-
-      - Those who upload the message or some digest to an external
-        third party and ask "Is this spam"?
-
-      - Those who download a set of patterns and rules from a third
-        party and apply this set to incoming messages in order to
-        determine whether it is spam.
-
-      - Those who are independent and don't contact any third party,
-        but try to learn themselves what is spam and what isn't.
-
-
-   The message filters provided by some e-mail service providers are
-   usually not a kind of their own, but a combination of the first two
-   kinds.
-
-11.2.1.  Action vs. reaction
-
-   Content filters suffer from a fundamental design problem: They are
-   late. They need to see some content of the same kind before in
-   order to learn and to block further distribution.
-
-   This works for viruses and worms, which redistribute. This doesn't
-   work for spam, since spam is usually not redistributed after the
-   first delivery. When the filters have learned or downloaded new
-   pattern sets, it's too late.
-
-   This proposal does not have this problem.
-
-11.2.2.  Content based Denial of Service attacks
-
-
-
-Hadmut Danisch                Experimental                     [Page 27]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   All three kinds of content filters, but especially the second and
-   the third kind are vulnerable to content based Denial of Service
-   attacks.
-
-   If some kind of third party (e.g. non-democratic government,
-   intellectual property warriors, religious groups, military, secret
-   services, patriots, public relation agents, etc.) wants certain
-   contents not to be distributed, they could either poison the
-   pattern/rule databases or feed wrong sets to particular receivers.
-
-   Such pattern/rule sets are the perfect tool for censoring e-mail
-   traffic and denial of service attacks by governments and other
-   parties, and a similar threat are virus filters. E. g. the content
-   industry could demand to teach all virus and spam filters to delete
-   all e-mails containing the URL of an MP3 web server outside the
-   legislations. Software manufacturers could try to block all e-mails
-   containing software license keys, thus trying to make unallowed
-   distribution more difficult. Governments could try to block
-   distribution of unwanted informations.
-
-   This proposal does not have this problem.
-
-
-12.  Privacy Considerations
-
-   (It was proposed on the 56th IETF meeting to have a privacy section
-   in drafts and RFCs.)
-
-12.1.  Draft specific considerations
-
-12.1.1.  No content leaking
-
-   Since the RMX approach doesn't touch the contents of a message in
-   any way, there is obviously no way of leaking out any information
-   about the content of the message. RMX is based solely on the
-   envelope recipient address. However, methods to fix problems not
-   covered by RMX might allow content leaking, e.g. if the acceptance
-   of a message with an empty sender address requires the reference to
-   the message id of an e-mail recently sent, this allows an attacker
-   to verify whether a certain message was delivered from there.
-
-12.1.2.  Message reception and sender domain
-
-   Message delivery triggers RMX and APL requests by the recipient.
-   Thus, the admin of the DNS server or an eavesdropper could learn
-   that the given machine has just received a message with a sender
-   from this address, even if the SMTP traffic itself had been
-   encrypted.
-
-
-
-Hadmut Danisch                Experimental                     [Page 28]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   However, most of today's MTAs do query the MX and A records of the
-   domain after the MAIL FROM command, so this is not a real new
-   threat.
-
-12.1.3.  Network structure
-
-   Since RMX and its associated APL records provide a complete list of
-   all IP addresses of hosts authorized to send messages from this
-   address, they do reveal informations about the network structure
-   and maybe the lifestyle of the domain owner, since a growing number
-   of domains are owned by single persons or families. E.g. the RMX
-   records could reveal where someone has his job or spends his time
-   at weekends.
-
-   If such informations are to be kept secret, it is the user's job to
-   not sent e-mails from there and to relay them from non-compromising
-   IP addresses.
-
-12.1.4.  Owner information distribution
-
-   As described above, RMX depends partly on the reliability of the
-   whois database entries. It does not make anonymous domains
-   impossible, but it requires to keep the database entries "true", i.
-   e. if a whois entry does not contain informations about the
-   responsible person, this must be unambigously labeled as anonymous.
-   It must not contain fake names and addresses to pretend a non-
-   existing person. However, since most Internet users on the world
-   feel extremely annoyed by spam, they will urge their MTA admin to
-   reject messages from anonymous domains. The domain owner will have
-   the choice to either remain anonymous but be not able to send e-
-   mail to everyone in the world, or to be able but to reveal his
-   identity to everyone on the world.
-
-   It would be possible to provide whois-like services only to
-   recipients of recent messages, but this would make things too
-   complicated to be commonly adopted.
-
-12.2.  General Considerations about spam defense
-
-12.2.1.  Content leaking of content filters
-
-   As described above in the Security chapter, there are spam filters
-   which inherently allow leakage of the message body. Those filters
-   upload either the message body, or in most cases just some kind of
-   checksum to a third party, which replies whether this is to be seen
-   as spam or not. The idea is to keep a databases of all digests of
-   all messages.  If a message is sent more often than some threshold,
-   it is to be considered as a mass mail and therefore tagged as spam.
-
-
-
-Hadmut Danisch                Experimental                     [Page 29]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   While the digest itself does not reveal the content of the message,
-   it perfectly reveals where a particular message has been delivered
-   to. If a government finds just a single unwanted message, if a
-   software manufacturer finds a single message with a stolen product
-   license key, if someone finds a message with unpatriotic content,
-   it takes just a single database lookup to get a list of all people
-   who received this particular message. Content filters with digest
-   upload are the perfect "Big Brother".
-
-12.2.2.  Black- and Whitelists
-
-   Some proposals against spam are based on a central database of
-   white- or blacklisted IP addresses, Sender names, Message IDs or
-   whatever. Again, there is a central database which learns who has
-   received which e-mail or from which sender with every query. This
-   allows tracking relations between persons, which is also a breach
-   of privacy.
-
-
-
-13.  Deployment Considerations
-
-13.1.  Compatibility
-
-13.1.1.  Compatibility with old mail receivers
-
-   Since the suggested extension doesn't change the SMTP protocol at
-   all, it is fully compatible with old mail receivers. They simply
-   don't ask for the RMX records and don't perform the check.
-
-13.1.2.  Compatibility with old mail senders
-
-   Since the SMTP protocol is unchanged and the SMTP sender is not
-   involved in the check, the method is fully compatible with old mail
-   senders.
-
-13.1.3.  Compatibility with old DNS clients
-
-   Since the RMX is a new RR, the existing DNS protocol and zone
-   informations remain completely untouched.
-
-   If RMX is provided as a TXT record instead, it must be ensured that
-   no other software is misinterpreting this entry.
-
-13.1.4.  Compatibility with old DNS servers
-
-   Full compatibility: If the server does not support RMX records, RMX
-   in TXT records can be used.
-
-
-
-Hadmut Danisch                Experimental                     [Page 30]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-13.2.  Enforcement policy
-
-   Obviously, for reasons of backward compatibility and smooth
-   introduction of this scheme, RMX records can't be required
-   immediately. Domains without RMX records must temporarily be
-   treated the same way as they are treated right now, i.e. e-mail
-   must be accepted from anywhere. But once the scheme becomes
-   sufficiently widespread, mail relays can start to refuse e-mails
-   with sender addresses from domains without RMX records, thus
-   forcing the owner of the domain to include a statement of
-   authorization into the domain's zone table.  Domain owners will
-   still be free to have an RMX record with a network and mask
-   0.0.0.0/0, i.e. to allow e-mails with that domain from everywhere.
-   On the other hand, mail receivers will be free to refuse mails from
-   domains without RMX records or RMX records which are too loose.
-   Advanced MTAs might have a configuration option to set the maximum
-   number of IP addresses authorized to use a domain. E-mails from a
-   domain, which's RMX records exceed this limit, would be rejected.
-   For example, a relay could reject e-mails from domains which
-   authorize more than 8 IP addresses. That allows to accept e-mails
-   only from domains with a reasonable security policy.
-
-
-
-14.  General considerations about fighting spam
-
-   Is there a concise technical solution against spam? Yes.
-
-   Will it be deployed? Certainly not.
-
-   Why not? Because of the strong non-technical interests of several
-   parties against a solution to the problem, as described below.
-   Since these are non-technical reasons, they might be beyond the
-   scope of such a draft. But since they are the main problems that
-   prevent fighting spam, it is unavoidable to address them. This
-   chapter exists temporarily only and should support the discussion
-   of solutions. It is not supposed to be included in a later RFC.
-
-14.1.  The economical problem
-
-   As has been recently illustrated in the initial session of the
-   IRTF's Anti Spam Research Group (ASRG) on the 56th IETF meeting,
-   sending spam is a business with significant revenues.
-
-   But a much bigger business is selling Anti-Spam software. This is a
-   billion dollar market, and it is rapidly growing. Any simple and
-   effective solution against spam would defeat revenues and drive
-   several companies into bankrupt, would make consultants jobless.
-
-
-
-Hadmut Danisch                Experimental                     [Page 31]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   Therefore, spam is essential for the Anti-Spam business. If there
-   is no spam, then no Anti-Spam software can be sold, similar to the
-   Anti-Virus business. There are extremely strong efforts to keep
-   this market growing. Viruses, Worms, and now spam are just perfect
-   to keep this market alive: It is not sufficient to just buy a
-   software. Databases need to be updated continuously, thus making
-   the cash flow continuously. Have a single, simple, and permanent
-   solution to the problem and - boom - this billion dollar market is
-   dead.
-
-   That's one of the reasons why people are expected to live with
-   spam. They have to live with it to make them buy Anti-Spam
-   software.  Content filters are perfect products to keep this market
-   alive.
-
-14.2.  The POP problem
-
-   Another problem is the history of mail delivery. Once upon a time,
-   there used to be very few SMTP relays which handled the e-mail
-   traffic of all the world, and everybody was happy with that. Then
-   odd things like Personal Computers, which are sometimes switched
-   off, portable computers, dynamicly assigned IP addresses, IP access
-   from hotel rooms, etc. was invented, and people became unhappy,
-   because SMTP does not support delivery to such machines. To make
-   them happy again, the Post Office Protocol[4] was invented, which
-   turned the last part of message delivery from SMTP's push style
-   into a pull style, thus making virtually every computer on the
-   world with any random IP address a potential receiver of mails for
-   random domains. Unfortunately, only receiving e-mail was covered,
-   but sending e-mail was left to SMTP.
-
-   The result is that today we have only very few SMTP relays pointed
-   to by MX records, but an extreme number of hosts sending e-mail
-   with SMTP from any IP address with sender addresses from any
-   domain. Mail delivery has become very asymmetric. Insecurity,
-   especially forgeability, has become an essential part of mail
-   transport.
-
-   That problem could easily be fixed: Use protocols which allow
-   uploading of messages to be delivered. If a host doesn't receive
-   messages by SMTP, it shouldn't deliver by SMTP.  Mail delivery
-   should go the same way back that incoming mail went in.  This is
-   not a limitation to those people on the road who plug their
-   portable computer in any hotel room's phone plug and use any
-   provider. If there is a POP server granting download access from
-   anywhere, then the same server should be ready to accept uploading
-   of outgoing messages.
-
-
-
-
-Hadmut Danisch                Experimental                     [Page 32]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   But as I saw from the comments on the first version of this draft,
-   people religiously insist on sending e-mail with their domain from
-   any computer with any IP address in the world, e.g. when visiting a
-   friend using her computer. It appears to be impossible to convince
-   people that stopping mail forgery requires every one of them to
-   give up forging.
-
-14.3.  The network structure problem
-
-   A subsequent problem is that many organisations failed to implement
-   a proper mail delivery structure and heavily based their network on
-   this asymmetry. I received harsh comments from Universities who
-   were unable to give their network a good structure. While they do
-   have a central mail relay for incoming mail to the universities
-   domain, they developed a structure where every member of the
-   University randomly sends e-mails with that University's domain as
-   a sender address from home or everywhere in the world with any
-   dynamically assigned IP address from any provider. So this domain
-   is to be used from every possible IP address on earth, and they are
-   unable to operate any authentication scheme. Furthermore, they were
-   unable to understand that such a policy heavily supports spam and
-   that they have to expect that people don't accept such e-mails
-   anymore once they become blacklisted.
-
-   As long as organisations insist on having such policies, spammers
-   will have a perfect playground.
-
-14.4.  The mentality problem
-
-   Another problem is the mentality of many internet users of certain
-   countries. I received harsh comments from people who strongly
-   insisted on the freedom to send any e-mail with any sender address
-   from anywhere, and who heavily refused any kind of authentication
-   step or any limitation, because they claimed that this would
-   infringe their constitutional "Freedom of speech". They are
-   undeviatingly convinced that "Freedom of speech" guarantees their
-   right to talk to everybody with any sender address, and that is has
-   to be kept the recipient's own problem to sort out what he doesn't
-   want to read - on the recipient's expense.
-
-   It requires a clear statement that the constitutional "Freedom of
-   Speech" does not cover molesting people with unsolicited e-mail
-   with forged sender address.
-
-14.5.  The identity problem
-
-   How does one fight against mail forgery? With authentication.  What
-   is authentication? In simple words: Making sure that the sender's
-
-
-
-Hadmut Danisch                Experimental                     [Page 33]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   real identity meets the recipients idea of who is the sender, based
-   on the sender address which came with the message.
-
-   What is identity? It is the main problem. Several countries have
-   different ideas of "identity", which turn out to be somehow
-   incompatible. In some countries people have identity cards and
-   never change their name and birthday. Identities are created by
-   human birth, not by identity changes. Other countries do not have
-   such a tight idea about identity. People's temporary identity is
-   based on nothing more than a driving license and a social security
-   number.  With this background, it is virtually impossible to create
-   a trustworthy PKI covering all Internet users. I learned that it is
-   extremely difficult to convince some people to give up random e-
-   mail sending.
-
-14.6.  The multi-legislation problem
-
-   Many proposals about fighting spam are feasible under certain
-   legislations only, and are inacceptable under some of the
-   legislations. But a world wide applicable method is required.
-   That's why the approach to ask everone on the world to sign
-   messages with cryptographic keys is not feasible.
-
-
-Implementation and further Information
-
-   Further informations and a test implementation are available at
-
-      http://www.danisch.de/work/security/antispam.html
-      http://www.danisch.de/software/rmx/
-
-
-   Additional informations and a technology overview are also
-   available at
-
-      http://www.mikerubel.org/computers/rmx_records/
-
-
-References
-
-
-
-1.   S. Bradner, "Key words for use in RFCs to Indicate Requirement Lev-
-     els," RFC 2119 (March 1997).
-
-2.   J. Klensin, "Simple Mail Transfer Protocol," RFC 2821 (April 2001).
-
-
-
-
-
-Hadmut Danisch                Experimental                     [Page 34]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-3.   P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION,"
-     RFC 1035 (November 1987).
-
-4.   J. Myers, M. Rose, "Post Office Protocol - Version 3," RFC 1939
-     (May 1996).
-
-
-Draft History
-
-   00  Dec 2002
-   01  Apr 2003
-   02  Jun 2003
-   03  Oct 2003
-
-Author's Address
-
-   Hadmut Danisch
-
-   Tennesseeallee 58
-   76149 Karlsruhe
-   Germany
-
-   Phone:  ++49-721-843004 or ++49-351-4850477
-   E-Mail: rfc@danisch.de
-
-Comments
-
-   Please send comments to rfc@danisch.de.
-
-Expiry
-
-   This drafts expires on Apr 1, 2004.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hadmut Danisch                Experimental                     [Page 35]
-
diff --git a/contrib/bind9/doc/draft/draft-dnsext-opcode-discover-02.txt b/contrib/bind9/doc/draft/draft-dnsext-opcode-discover-02.txt
deleted file mode 100644
index 7b5e8cc..0000000
--- a/contrib/bind9/doc/draft/draft-dnsext-opcode-discover-02.txt
+++ /dev/null
@@ -1,241 +0,0 @@
-
-IETF DNSEXT WG                                             Bill Manning
-draft-dnsext-opcode-discover-02.txt                              ep.net
-                                                             Paul Vixie
-                                                                    ISC
-                                                            13 Oct 2003
-
-
-                         The DISCOVER opcode
-
-This document is an Internet-Draft and is subject to all provisions of
-Section 10 of RFC2026.
-
-Comments may be submitted to the group mailing list at "mdns@zocalo.net"
-or the authors.
-
-Distribution of this memo is unlimited.
-
-Internet-Drafts are working documents of the Internet Engineering Task
-Force (IETF), its areas, and its working groups.  Note that other groups
-may also distribute working documents as Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six months and
-may be updated, replaced, or obsoleted by other documents at any time.  It
-is inappropriate to use Internet-Drafts as reference material or to cite
-them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-The capitalized keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-document are to be interpreted as described in RFC 2119
-
-0. Abstract:
-
-   The QUERY opcode in the DNS is designed for unicast. With the
-   development of multicast capabilities in the DNS, it is desireable
-   to have a more robust opcode for server interactions since a single
-   request may generate replies from multiple responders. So DISCOVER
-   is defined to deal with replies from multiple responders.
-
-   As such, this document extends the core DNS specifications to allow
-   clients to have a method for coping with replies from multiple
-   responders. Use of this new opcode may facilitate DNS operations in
-   modern networking topologies. A prototype of the DISCOVER opcode
-   was developed during the TBDS project (1999-2000), funded under DARPA
-   grant F30602-99-1-0523.
-
-1. Introduction:
-
-   This document describes an experimental extension to the DNS to receive
-   multiple responses which is the likely result when using DNS that has
-   enabled multicast queries.  This approach was developed as part of the
-   TBDS research project, funded under DARPA grant F30602-99-1-0523.  The
-   full processing rules used by TBDS are documented here for possible
-   incorporation in a future revision of the DNS specification."
-
-2. Method:
-
-        DISCOVER works like QUERY except:
-
-        1. it can be sent to a broadcast or multicast destination. QUERY
-           isn't defined for non-unicast, and arguably shouldn't be.
-
-        2. the Question section, if present, has <QNAME=zonename,QTYPE=SOA>
-           tuples. TBDS tried to augment this structure as follows:
-           <QNAME=service,QTYPE=SRV>. While this worked for our purposes in
-           TBDS, it is cleaner to place the SRV question in a separate pass.
-
-        3. if QDCOUNT equals 0 then only servers willing to do recursion should
-           answer. Other servers must silently discard the DISCOVER request.
-
-        4. if QDCOUNT is not equal to 0 then only servers who are authoritative
-           for the zones named by some QNAME should answer.
-
-        5. responses may echo the request's Question section or leave it blank,
-           just like QUERY.
-
-        6. responses have standard Answer, Authority, and Additional sections.
-           e.g. the response is the same as that to a QUERY. It is desireable
-           that zero content answers not be sent to avoid badly formed or
-           unfulfilled requests. Responses should be sent to the unicast
-           address of the requester and the source address should reflect
-           the unicast address of the responder.
-
-   Example usage for gethostby{name,addr}-style requestors:
-
-        Compute the zone name of the enclosing in-addr.arpa, ip6.int, or
-        ip6.arpa domain.
-
-        DISCOVER whether anyone in-scope is authoritative for this zone.
-
-                If so, query these authoritative servers for local
-                in-addr/ip6 names.
-
-        If not, DISCOVER whether there are recursive servers available.
-
-                If so, query these recursive servers for local
-                in-addr/ip6 names.
-
-        So, a node will issue a multicast request with the DISCOVER opcode at
-        some particular multicast scope.  Then determine, from the replies,
-        whether there are any DNS servers which are authoritative (or support
-        recursion) for the zone. Replies to DISCOVER requests MUST set the
-        Recursion Available (RA) flag in the DNS message header.
-
-        It is important to recognize that a requester must be prepared to
-        receive multiple replies from multiple responders. We expect that
-        there will be a single response per responder.
-
-        Once one learns a host's FQDN by the above means, repeat the process
-        for discovering the closest enclosing authoritative server of such
-        local name.
-
-        Cache all NS and A data learned in this process, respecting TTL's.
-
-   TBDS usage for SRV requestors:
-
-        Do the gethostbyaddr() and gethostbyname() on one's own link-local
-        address, using the above process.
-
-        Assume that the closest enclosing zone for which an authority server
-        answers an in-scope DISCOVER packet is "this host's parent domain".
-
-        Compute the SRV name as _service._transport.*.parentdomain.
-
-        This is a change to the definition as defined in RFC 1034.
-        A wildcard label ("*") in the QNAME used in a DNS message with
-        opcode DISCOVER SHOULD be evaluated with special rules.  The
-        wildcard matches any label for which the DNS server data is
-        authoritative.  For example 'x.*.example.com.' would match
-        'x.y.example.com.' and 'x.yy.example.com.' provided that the
-        server was authoritative for 'example.com.'  In this particular
-        case, we suggest the follwing considerations be made:
-
-   getservbyname() can be satisfied by issuing a request with
-   this computed SRV name.  This structure can be
-   populated by values returned from a request as follows:
-
-        s_name    The name of the service, "_service" without the
-                  preceding underscore.
-        s_aliases The names returned in the SRV RRs in replies
-                  to the query.
-        s_port    The port number in the SRV RRs replies to the
-                  query.  If these port numbers disagree - one
-                  of the port numbers is chosen, and only those
-                  names which correspond are returned.
-        s_proto   The transport protocol from named by the
-                  "_transport" label, without the preceding
-                  underscore.
-
-        Send SRV query for this name to discovered local authoritative servers.
-
-     Usage for disconnected networks with no authoritative servers:
-
-        Hosts should run a "stub server" which acts as though its FQDN is a
-        zone name.  Computed SOA gives the host's FQDN as MNAME, "." as the
-        ANAME, seconds-since-1Jan2000 as the SERIAL, low constants for EXPIRE
-        and the other timers.  Compute NS as the host's FQDN.  Compute the
-        glue as the host's link-local address. Or Hosts may run a
-        "DNS stub server" which acts as though its FQDN is a zone name.  The
-        rules governing the behavior of this stub server are given elsewhere
-        [1] [2].
-
-        Such stub servers should answer DISCOVER packets for its zone, and
-        will be found by the iterative "discover closest enclosing authority
-        server" by DISCOVER clients, either in the gethostbyname() or SRV
-        cases described above.  Note that stub servers only answer with
-        zone names which exactly match QNAME's, not with zone names which
-        are owned by QNAME's.
-
-   The main deviation from the DNS[3][4] model is that a host (like, say, a
-   printer offering LPD services) has a DNS server which answers authoritatively
-   for something which hasn't been delegated to it.  However, the only way that
-   such DNS servers can be discovered is with a new opcode, DISCOVER, which
-   is explicitly defined to discover undelegated zones for tightly scoped
-   purposes.  Therefore this isn't officially a violation of DNS's coherency
-   principles. In some cases a responder to DISCOVER may not be traditional
-   DNS software, it could be special purpose software.
-
-3. IANA Considerations
-
-        As a new opcode, the IANA will need to assign a numeric value
-        for the memnonic. The last OPCODE assigned was "5", for UPDATE.
-        Test implementations have used OPCODE "6".
-
-4. Security Considerations
-
-        No new security considerations are known to be introduced with any new
-        opcode, however using multicast for service discovery has the potential
-        for denial of service, primarly from flooding attacks. It may also be
-        possible to enable deliberate misconfiguration of clients simply by
-        running a malicious DNS resolver that claims to be authoritative for
-        things that it is not. One possible way to mitigate this effect is by
-        use of credentials, such as CERT resource records within an RR set.
-        The TBDS project took this approach.
-
-5. Attribution:
-
-        This material was generated in discussions on the mdns mailing list
-hosted by Zocalo in March 2000. Updated by discussion in September/October
-2003.  David Lawrence, Scott Rose, Stuart Cheshire, Bill Woodcock,
-Erik Guttman, Bill Manning and Paul Vixie were active contributors.
-
-6. Author's Address
-
-   Bill Manning
-   PO 12317
-   Marina del Rey, CA. 90295
-   +1.310.322.8102
-   bmanning@karoshi.com
-
-   Paul Vixie
-   Internet Software Consortium
-   950 Charter Street
-   Redwood City, CA 94063
-   +1 650 779 7001
-   <vixie@isc.org>
-
-7. References
-
-Informational References:
-
-[1]  Esibov, L., Aboba, B., Thaler, D., "Multicast DNS",
-        draft-ietf-dnsext-mdns-00.txt, November 2000. Expired
-
-[2] Woodcock, B., Manning, B., "Multicast Domain Name Service",
-        draft-manning-dnsext-mdns-00.txt,  August 2000.  Expired.
-
-Normative References:
-[3]  Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
-        RFC 1034, November 1987.
-[4]  Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION",
-        RFC 1035, November 1987
-
-        ----------------------------EOL-----------------------
-
diff --git a/contrib/bind9/doc/draft/draft-durand-dnsop-dynreverse-00.txt b/contrib/bind9/doc/draft/draft-durand-dnsop-dynreverse-00.txt
deleted file mode 100644
index 224e7ad1..0000000
--- a/contrib/bind9/doc/draft/draft-durand-dnsop-dynreverse-00.txt
+++ /dev/null
@@ -1,240 +0,0 @@
-Internet Engineering Task Force                             Alain Durand
-INTERNET-DRAFT                                          SUN Microsystems
-Feb 21, 2003
-Expires Aug 2, 2003
-
-
-
-                Dynamic reverse DNS for IPv6
-              <draft-durand-dnsop-dynreverse-00.txt>
-
-
-
-Status of this memo
-
-
-   This memo provides information to the Internet community.  It does
-   not specify an Internet standard of any kind.  This memo is in full
-   conformance with all provisions of Section 10 of RFC2026 [RFC2026].
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-
-
-Abstract
-
-   This document describes a method to dynamically generate PTR records
-   and corresponding A or AAAA records when the reverse path DNS tree is
-   not populated.
-
-   A special domain dynrev.arpa. is reserved for that purpose.
-
-
-1. Introduction
-
-   In IPv4, the reverse path tree of the DNS under in-addr.arpa.
-   although not perfectly maintained, is still mostly usable and its
-   existence is important for a number of applications that relies on
-   its existence and decent status.  Some applications performs some
-   (very) weak security checks based on it. Mail relays relies on it for
-   some anti-spams checks an some FTP server will not let you in unless
-   your IP address resolve properly with a PTR record.
-
-   IPv6 addresses being much longer (and cumbersome) than IPv4
-   addresses, it is to fear that the reverse path tree under ip6.arpa.
-   would not be as well maintained.  Also, tools like 6to4, Isatap and
-   others have made creative use of the 128 bits of an IPv6 address to
-   automatically embed an IPv4 address to enable seamless connection to
-   the IPv6 Internet. However, no provision has been made to make sure
-   the reverse path tree gets automatically updated as well for those
-   new IPv6 addresses.  One step furter, RFC3041 describes a mechanism
-   to basically use random bits in the bottom part of an IPv6 address to
-   preserver anonymity. If those addresses are to resolve in the reverse
-   path tree, it obviously has to be with anonymous data as well.
-   Another point to note is that home customer ISPs in IPv4 have a
-   current practice to pre-populate the reverse path tree with names
-   automatically derived from the IP addresses. This practice is no
-   longer possible in IPv6, where IP address allocation is not dense as
-   it is the case in IPv4. The mere size of typical customer allocation
-   (2^48 according to the recommendation of RFC3177) makes it
-   impossible.
-
-   Applications that check the existence of PTR records usually follow
-   this by checking if the name pointed by the PTR resolve in a A (or
-   AAAA for IPv6) that match the original IP address. Thus the forward
-   path tree must also include the corresponding data.
-
-   One simple approach of this problem is to simply declare the usage of
-   the reverse path DNS as described above obsolete.  The author believe
-   this is too strong an approach for now.
-
-   Similarly, a completely different approach would be to deprecate the
-   usage of DNS for the reverse tree altogether and replace it by
-   something inspired from ICMP name-info messages. The author believes
-   that this approached is an important departure from the current
-   practise and thus not very realistic.  Also, there are some concerns
-   about the the security implications of this method as any node could
-   easily impersonate any name. This approach would fundamentally change
-   the underlying assumption of "I trust what has been put in the DNS by
-   the local administrators" to "I trust what has been configured on
-   each machine I query directly".
-
-
-
-2. Dynamic record generation
-
-   If static pre-population of the tree is not possible anymore and data
-   still need to be returned to applications using getnameinfo(), the
-   alternative is dynamic record generation.  This can be done is two
-   places: in the DNS servers responsible for the allocated space (/64
-   or /48) in the ip6.arpa. domain.  or in the DNS resolvers (either the
-   sub resolver library or the recursive DNS server).
-
-   2.1. On the resolver side.
-
-   The resolver, either in the recursive DNS server or in the stub
-   library could theoretically generate this data.
-
-   In case DNSsec is in place, the recursive DNS server would have to
-   pretend these records are authentic.
-
-   If the synthesis is done in the stub-resolver library, no record
-   needs to be actually generated, only the right information needs to
-   be passed to getnameinfo() and getaddrinfo().  If the synthesis is
-   done in the recursive DNS server, no modification is required to
-   existing stub resolvers.
-
-
-2.2. On the server side.
-
-   PTR records could be generated automatically by the server
-   responsible for the reverse path tree of an IPv6 prefix (a /64 or /48
-   prefixes or basically anything in between) when static data is not
-   available.
-
-   There could be impact on DNSsec as the zone or some parts of the zone
-   may need to be resigned each time a DNS query is made for an
-   unpopulated address. This can be seen as a DOS attack on a DNSsec
-   zone, so server side synthesis is not recommended if DNSsec is
-   deployed.
-
-
-
-3. Synthesis
-
-   The algorithm is simple: Do the normal queries. If the query returns
-   No such domain, replace this answer by the synthetized one if
-   possible.
-
-3.1. PTR synthesis
-
-   The synthetized PTR for a DNS string [X] is simply [X].dynrev.arpa.
-   where [X] is any valid DNS name.
-
-   The fact that the synthetized PTR points to the dynrev.arpa. domain
-   is an indication to the applications that this record has been
-   dynamically generated.
-
-
-3.2. A synthesis
-
-   If [X] is in the form a.b.c.d.in-addr.arpa, one can synthetized an A
-   record for the string [X].dynrev.arpa. which value is d.c.b.a. with
-   a,b,c & d being integer [0..255]
-
-
-3.3. AAAA synthesis
-
-   If [X] is in the form
-   a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.s.t.u.v.w.x.y.z.A.B.C.D.E.F.in-
-   addr.arpa, one can synthetized a AAAA record for the string
-   [X].dynrev.arpa. which value is
-   FEDC:BAzy:xwvu:tsrq:ponm:lkji:hgfe:dcba with
-   a,b,c....x,y,z,A,B,C,D,E,F being hexadecimal digits.
-
-
-3.4. Server side synthesis
-
-   If synthesis is done on the server side, PTR could be set not to use
-   the dynrev.arpa domain but the local domain name instead.  It culd be
-   for instance dynrev.mydomain.com.
-
-   Note also that server side synthesis is not incompatible with
-   resolver side synthesis.
-
-
-
-4. IANA considerations
-
-   The dynrev.arpa. domain is reserved for the purpose of this document.
-
-
-
-5. Security considerations
-
-   Section 2. discusses the the interactions with DNSsec.
-
-
-
-6. Authors addresses
-
-   Alain Durand
-   SUN Microsystems, Inc
-   17, Network Circle
-   UMPK17-202
-   Menlo Park, CA 94025
-   USA
-   Mail: Alain.Durand@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-2929bis-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-2929bis-01.txt
deleted file mode 100644
index fa41e76..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-2929bis-01.txt
+++ /dev/null
@@ -1,928 +0,0 @@
-
-INTERNET-DRAFT                                    Donald E. Eastlake 3rd
-Obsoletes RFC 2929, Updates RFC 1183               Motorola Laboratories
-Expires: February 2006                                       August 2005
-
-
-
-              Domain Name System (DNS) IANA Considerations
-              ------ ---- ------ ----- ---- --------------
-                   <draft-ietf-dnsext-2929bis-01.txt>
-
-
-
-Status of This Document
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Distribution of this draft is unlimited.  It is intended to become
-   the new BCP 42 obsoleting RFC 2929.  Comments should be sent to the
-   DNS Working Group mailing list <namedroppers@ops.ietf.org>.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than a "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/1id-abstracts.html
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-
-
-Abstract
-
-   Internet Assigned Number Authority (IANA) parameter assignment
-   considerations are given for the allocation of Domain Name System
-   (DNS) classes, RR types, operation codes, error codes, RR header
-   bits, and AFSDB subtypes.
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 1]
-
-
-INTERNET-DRAFT           DNS IANA Considerations             August 2005
-
-
-Table of Contents
-
-      Status of This Document....................................1
-      Abstract...................................................1
-
-      Table of Contents..........................................2
-
-      1. Introduction............................................3
-      2. DNS Query/Response Headers..............................3
-      2.1 One Spare Bit?.........................................4
-      2.2 Opcode Assignment......................................4
-      2.3 RCODE Assignment.......................................5
-      3. DNS Resource Records....................................6
-      3.1 RR TYPE IANA Considerations............................7
-      3.1.1 DNS TYPE Allocation Policy...........................8
-      3.1.2 Special Note on the OPT RR...........................9
-      3.1.3 The AFSDB RR Subtype Field...........................9
-      3.2 RR CLASS IANA Considerations...........................9
-      3.3 RR NAME Considerations................................11
-      4. Security Considerations................................11
-
-      Appendix: Changes from RFC 2929...........................12
-
-      Copyright and Disclaimer..................................13
-      Normative References......................................13
-      Informative References....................................14
-
-      Authors Addresses.........................................16
-      Expiration and File Name..................................16
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 2]
-
-
-INTERNET-DRAFT           DNS IANA Considerations             August 2005
-
-
-1. Introduction
-
-   The Domain Name System (DNS) provides replicated distributed secure
-   hierarchical databases which hierarchically store "resource records"
-   (RRs) under domain names.  DNS data is structured into CLASSes and
-   zones which can be independently maintained.  See [RFC 1034, 1035,
-   2136, 2181, 4033] familiarity with which is assumed.
-
-   This document provides, either directly or by reference, general IANA
-   parameter assignment considerations applying across DNS query and
-   response headers and all RRs.  There may be additional IANA
-   considerations that apply to only a particular RR type or
-   query/response opcode.  See the specific RFC defining that RR type or
-   query/response opcode for such considerations if they have been
-   defined, except for AFSDB RR considerations [RFC 1183] which are
-   included herein. This RFC obsoletes [RFC 2929].
-
-   IANA currently maintains a web page of DNS parameters.  See
-   <http://www.iana.org/numbers.htm>.
-
-   "IETF Standards Action", "IETF Consensus", "Specification Required",
-   and "Private Use" are as defined in [RFC 2434].
-
-
-
-2. DNS Query/Response Headers
-
-   The header for DNS queries and responses contains field/bits in the
-   following diagram taken from [RFC 2136, 2929]:
-
-                                              1  1  1  1  1  1
-                0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
-               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-               |                      ID                       |
-               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-               |QR|   Opcode  |AA|TC|RD|RA| Z|AD|CD|   RCODE   |
-               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-               |                QDCOUNT/ZOCOUNT                |
-               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-               |                ANCOUNT/PRCOUNT                |
-               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-               |                NSCOUNT/UPCOUNT                |
-               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-               |                    ARCOUNT                    |
-               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-   The ID field identifies the query and is echoed in the response so
-   they can be matched.
-
-   The QR bit indicates whether the header is for a query or a response.
-
-
-D. Eastlake 3rd                                                 [Page 3]
-
-
-INTERNET-DRAFT           DNS IANA Considerations             August 2005
-
-
-   The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful
-   only in queries or only in responses, depending on the bit.  However,
-   many DNS implementations copy the query header as the initial value
-   of the response header without clearing bits.  Thus any attempt to
-   use a "query" bit with a different meaning in a response or to define
-   a query meaning for a "response" bit is dangerous given existing
-   implementation.  Such meanings may only be assigned by an IETF
-   Standards Action.
-
-   The unsigned fields query count (QDCOUNT), answer count (ANCOUNT),
-   authority count (NSCOUNT), and additional information count (ARCOUNT)
-   express the number of records in each section for all opcodes except
-   Update.  These fields have the same structure and data type for
-   Update but are instead the counts for the zone (ZOCOUNT),
-   prerequisite (PRCOUNT), update (UPCOUNT), and additional information
-   (ARCOUNT) sections.
-
-
-
-2.1 One Spare Bit?
-
-   There have been ancient DNS implementations for which the Z bit being
-   on in a query meant that only a response from the primary server for
-   a zone is acceptable.  It is believed that current DNS
-   implementations ignore this bit.
-
-   Assigning a meaning to the Z bit requires an IETF Standards Action.
-
-
-
-2.2 Opcode Assignment
-
-   Currently DNS OpCodes are assigned as follows:
-
-          OpCode Name                      Reference
-
-           0     Query                     [RFC 1035]
-           1     IQuery  (Inverse Query, Obsolete) [RFC 3425]
-           2     Status                    [RFC 1035]
-           3     available for assignment
-           4     Notify                    [RFC 1996]
-           5     Update                    [RFC 2136]
-          6-15   available for assignment
-
-   New OpCode assignments require an IETF Standards Action as modified
-   by [RFC 4020].
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 4]
-
-
-INTERNET-DRAFT           DNS IANA Considerations             August 2005
-
-
-2.3 RCODE Assignment
-
-   It would appear from the DNS header above that only four bits of
-   RCODE, or response/error code are available.  However, RCODEs can
-   appear not only at the top level of a DNS response but also inside
-   OPT RRs [RFC 2671], TSIG RRs [RFC 2845], and TKEY RRs [RFC 2930].
-   The OPT RR provides an eight bit extension resulting in a 12 bit
-   RCODE field and the TSIG and TKEY RRs have a 16 bit RCODE field.
-
-   Error codes appearing in the DNS header and in these three RR types
-   all refer to the same error code space with the single exception of
-   error code 16 which has a different meaning in the OPT RR from its
-   meaning in other contexts.  See table below.
-
-        RCODE   Name    Description                        Reference
-        Decimal
-          Hexadecimal
-         0    NoError   No Error                           [RFC 1035]
-         1    FormErr   Format Error                       [RFC 1035]
-         2    ServFail  Server Failure                     [RFC 1035]
-         3    NXDomain  Non-Existent Domain                [RFC 1035]
-         4    NotImp    Not Implemented                    [RFC 1035]
-         5    Refused   Query Refused                      [RFC 1035]
-         6    YXDomain  Name Exists when it should not     [RFC 2136]
-         7    YXRRSet   RR Set Exists when it should not   [RFC 2136]
-         8    NXRRSet   RR Set that should exist does not  [RFC 2136]
-         9    NotAuth   Server Not Authoritative for zone  [RFC 2136]
-        10    NotZone   Name not contained in zone         [RFC 2136]
-        11 - 15         Available for assignment
-        16    BADVERS   Bad OPT Version                    [RFC 2671]
-        16    BADSIG    TSIG Signature Failure             [RFC 2845]
-        17    BADKEY    Key not recognized                 [RFC 2845]
-        18    BADTIME   Signature out of time window       [RFC 2845]
-        19    BADMODE   Bad TKEY Mode                      [RPC 2930]
-        20    BADNAME   Duplicate key name                 [RPF 2930]
-        21    BADALG    Algorithm not supported            [RPF 2930]
-
-        22 - 3,840
-          0x0016 - 0x0F00   Available for assignment
-
-        3,841 - 4,095
-          0x0F01 - 0x0FFF   Private Use
-
-        4,096 - 65,534
-          0x1000 - 0xFFFE   Available for assignment
-
-        65,535
-          0xFFFF            Reserved, can only be allocated by an IETF
-                            Standards Action.
-
-
-
-D. Eastlake 3rd                                                 [Page 5]
-
-
-INTERNET-DRAFT           DNS IANA Considerations             August 2005
-
-
-   Since it is important that RCODEs be understood for interoperability,
-   assignment of new RCODE listed above as "available for assignment"
-   requires an IETF Consensus.
-
-
-
-3. DNS Resource Records
-
-   All RRs have the same top level format shown in the figure below
-   taken from [RFC 1035]:
-
-                                       1  1  1  1  1  1
-         0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-       |                                               |
-       /                                               /
-       /                      NAME                     /
-       |                                               |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-       |                      TYPE                     |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-       |                     CLASS                     |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-       |                      TTL                      |
-       |                                               |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-       |                   RDLENGTH                    |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
-       /                     RDATA                     /
-       /                                               /
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-   NAME is an owner name, i.e., the name of the node to which this
-   resource record pertains.  NAMEs are specific to a CLASS as described
-   in section 3.2.  NAMEs consist of an ordered sequence of one or more
-   labels each of which has a label type [RFC 1035, 2671].
-
-   TYPE is a two octet unsigned integer containing one of the RR TYPE
-   codes.  See section 3.1.
-
-   CLASS is a two octet unsigned integer containing one of the RR CLASS
-   codes.  See section 3.2.
-
-   TTL is a four octet (32 bit) bit unsigned integer that specifies the
-   number of seconds that the resource record may be cached before the
-   source of the information should again be consulted.  Zero is
-   interpreted to mean that the RR can only be used for the transaction
-   in progress.
-
-   RDLENGTH is an unsigned 16 bit integer that specifies the length in
-
-
-D. Eastlake 3rd                                                 [Page 6]
-
-
-INTERNET-DRAFT           DNS IANA Considerations             August 2005
-
-
-   octets of the RDATA field.
-
-   RDATA is a variable length string of octets that constitutes the
-   resource. The format of this information varies according to the TYPE
-   and in some cases the CLASS of the resource record.
-
-
-
-3.1 RR TYPE IANA Considerations
-
-   There are three subcategories of RR TYPE numbers: data TYPEs, QTYPEs,
-   and MetaTYPEs.
-
-   Data TYPEs are the primary means of storing data.  QTYPES can only be
-   used in queries.  Meta-TYPEs designate transient data associated with
-   an particular DNS message and in some cases can also be used in
-   queries.  Thus far, data TYPEs have been assigned from 1 upwards plus
-   the block from 100 through 103 while Q and Meta Types have been
-   assigned from 255 downwards except for the OPT Meta-RR which is
-   assigned TYPE 41.  There have been DNS implementations which made
-   caching decisions based on the top bit of the bottom byte of the RR
-   TYPE.
-
-   There are currently three Meta-TYPEs assigned: OPT [RFC 2671], TSIG
-   [RFC 2845], and TKEY [RFC 2930].
-
-   There are currently five QTYPEs assigned: * (all), MAILA, MAILB,
-   AXFR, and IXFR.
-
-   Considerations for the allocation of new RR TYPEs are as follows:
-
-     Decimal
-   Hexadecimal
-
-     0
-   0x0000 - TYPE zero is used as a special indicator for the SIG RR [RFC
-          2535] and in other circumstances and must never be allocated
-          for ordinary use.
-
-     1 - 127
-   0x0001 - 0x007F - remaining TYPEs in this range are assigned for data
-          TYPEs by the DNS TYPE Allocation Policy as specified in
-          section 3.1.1.
-
-     128 - 255
-   0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and
-          Meta TYPEs by the DNS TYPE Allocation Policy as specified in
-          section 3.1.1.
-
-
-
-
-D. Eastlake 3rd                                                 [Page 7]
-
-
-INTERNET-DRAFT           DNS IANA Considerations             August 2005
-
-
-     256 - 32,767
-   0x0100 - 0x7FFF - assigned for data, Q, or Meta TYPE use by the DNS
-          TYPE Allocation Policy as specified in section 3.1.1.
-
-     32,768 - 65,279
-   0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434].
-
-     65,280 - 65534
-   0xFF00 - 0xFFFE - Private Use.
-
-     65,535
-   0xFFFF - Reserved, can only be assigned by an IETF Standards Action.
-
-
-
-3.1.1 DNS TYPE Allocation Policy
-
-   Parameter values specified above as assigned based on DNS TYPE
-   Allocation Policy. That is, Expert Review with the additional
-   requirement that the review be based on a complete template as
-   specified below which has been posted for three weeks to the
-   namedroppers@ops.ietf.org mailing list.
-
-   Partial or draft templates may be posted with the intend of
-   soliciting feedback.
-
-
-                 DNS RR TYPE PARAMETER ALLOCATION TEMPLATE
-
-        Date:
-
-        Name and email of originator:
-
-        Pointer to internet-draft or other document giving a detailed
-        description of the protocol use of the new RR Type:
-
-        What need is the new RR TYPE intended to fix?
-
-        What existing RR TYPE(s) come closest to filling that need and why are
-        they unsatisfactory?
-
-        Does the proposed RR TYPR require special handling within the DNS
-        different from an Unknown RR TYPE?
-
-        Comments:
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 8]
-
-
-INTERNET-DRAFT           DNS IANA Considerations             August 2005
-
-
-3.1.2 Special Note on the OPT RR
-
-   The OPT (OPTion) RR, number 41, is specified in [RFC 2671].  Its
-   primary purpose is to extend the effective field size of various DNS
-   fields including RCODE, label type, OpCode, flag bits, and RDATA
-   size.  In particular, for resolvers and servers that recognize it, it
-   extends the RCODE field from 4 to 12 bits.
-
-
-
-3.1.3 The AFSDB RR Subtype Field
-
-   The AFSDB RR [RFC 1183] is a CLASS insensitive RR that has the same
-   RDATA field structure as the MX RR but the 16 bit unsigned integer
-   field at the beginning of the RDATA is interpreted as a subtype as
-   follows:
-
-     Decimal
-   Hexadecimal
-
-     0
-   0x0000 -  Allocation requires IETF Standards Action.
-
-     1
-   0x0001 - Andrews File Service v3.0 Location Service [RFC 1183].
-
-     2
-   0x0002 - DCE/NCA root cell directory node [RFC 1183].
-
-     3 - 65,279
-   0x0003 - 0xFEFF - Allocation by IETF Consensus.
-
-     65,280 - 65,534
-   0xFF00 - 0xFFFE - Private Use.
-
-     65,535
-   0xFFFF - Reserved, allocation requires IETF Standards Action.
-
-
-
-3.2 RR CLASS IANA Considerations
-
-   DNS CLASSes have been little used but constitute another dimension of
-   the DNS distributed database.  In particular, there is no necessary
-   relationship between the name space or root servers for one CLASS and
-   those for another CLASS.  The same name can have completely different
-   meanings in different CLASSes; however, the label types are the same
-   and the null label is usable only as root in every CLASS.  However,
-   as global networking and DNS have evolved, the IN, or Internet, CLASS
-   has dominated DNS use.
-
-
-D. Eastlake 3rd                                                 [Page 9]
-
-
-INTERNET-DRAFT           DNS IANA Considerations             August 2005
-
-
-   There are two subcategories of DNS CLASSes: normal data containing
-   classes and QCLASSes that are only meaningful in queries or updates.
-
-   The current CLASS assignments and considerations for future
-   assignments are as follows:
-
-     Decimal
-   Hexadecimal
-
-     0
-   0x0000 - Reserved, assignment requires an IETF Standards Action.
-
-     1
-   0x0001 - Internet (IN).
-
-     2
-   0x0002 - Available for assignment by IETF Consensus as a data CLASS.
-
-     3
-   0x0003 - Chaos (CH) [Moon 1981].
-
-     4
-   0x0004 - Hesiod (HS) [Dyer 1987].
-
-     5 - 127
-   0x0005 - 0x007F - available for assignment by IETF Consensus for data
-          CLASSes only.
-
-     128 - 253
-   0x0080 - 0x00FD - available for assignment by IETF Consensus for
-          QCLASSes only.
-
-     254
-   0x00FE - QCLASS None [RFC 2136].
-
-     255
-   0x00FF - QCLASS Any [RFC 1035].
-
-     256 - 32,767
-   0x0100 - 0x7FFF - Assigned by IETF Consensus.
-
-     32,768 - 65,279
-   0x8000 - 0xFEFF - Assigned based on Specification Required as defined
-          in [RFC 2434].
-
-     65,280 - 65,534
-   0xFF00 - 0xFFFE - Private Use.
-
-     65,535
-   0xFFFF - Reserved, can only be assigned by an IETF Standards Action.
-
-
-D. Eastlake 3rd                                                [Page 10]
-
-
-INTERNET-DRAFT           DNS IANA Considerations             August 2005
-
-
-3.3 RR NAME Considerations
-
-   DNS NAMEs are sequences of labels [RFC 1035].  The last label in each
-   NAME is "ROOT" which is the zero length label.  By definition, the
-   null or ROOT label can not be used for any other NAME purpose.
-
-   At the present time, there are two categories of label types, data
-   labels and compression labels.  Compression labels are pointers to
-   data labels elsewhere within an RR or DNS message and are intended to
-   shorten the wire encoding of NAMEs.  The two existing data label
-   types are sometimes referred to as Text and Binary.  Text labels can,
-   in fact, include any octet value including zero value octets but most
-   current uses involve only [US-ASCII].  For retrieval, Text labels are
-   defined to treat ASCII upper and lower case letter codes as matching
-   [insensitive].  Binary labels are bit sequences [RFC 2673]. The
-   Binary label type is Experimental [RFC 3363].
-
-   IANA considerations for label types are given in [RFC 2671].
-
-   NAMEs are local to a CLASS.  The Hesiod [Dyer 1987] and Chaos [Moon
-   1981] CLASSes are essentially for local use.  The IN or Internet
-   CLASS is thus the only DNS CLASS in global use on the Internet at
-   this time.
-
-   A somewhat out-of-date description of name allocation in the IN Class
-   is given in [RFC 1591].  Some information on reserved top level
-   domain names is in BCP 32 [RFC 2606].
-
-
-
-4. Security Considerations
-
-   This document addresses IANA considerations in the allocation of
-   general DNS parameters, not security.  See [RFC 4033, 4034, 4035] for
-   secure DNS considerations.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                [Page 11]
-
-
-INTERNET-DRAFT           DNS IANA Considerations             August 2005
-
-
-Appendix: Changes from RFC 2929
-
-   RFC Editor: This Appendix should be deleted for publication.
-
-   Changes from RFC 2929 to this draft:
-
-   1. Changed many "IETF Consensus" for RR TYPEs to be "DNS TYPE
-   Allocation Policy" and add the specification of that policy. Change
-   some remaining "IETF Standards Action" allocation requirements to say
-   "as modified by [RFC 4020]".
-
-   2. Updated various RFC references.
-
-   3. Mentioned that the Binary label type is now Experimental and
-   IQuery is Obsolete.
-
-   4. Changed allocation status of RR Type 0xFFFF and RCODE 0xFFFF to be
-   IETF Standards Action required.
-
-   5. Add an IANA allocation policy for the AFSDB RR Subtype field.
-
-   6. Addition of reference to case insensitive draft.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                [Page 12]
-
-
-INTERNET-DRAFT           DNS IANA Considerations             August 2005
-
-
-Copyright and Disclaimer
-
-   Copyright (C) The Internet Society (2005).  This document is subject to
-   the rights, licenses and restrictions contained in BCP 78, and except
-   as set forth therein, the authors retain all their rights.
-
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-Normative References
-
-   [RFC 1034] - Mockapetris, P., "Domain Names - Concepts and
-   Facilities", STD 13, RFC 1034, November 1987.
-
-   [RFC 1035] - Mockapetris, P., "Domain Names - Implementation and
-   Specifications", STD 13, RFC 1035, November 1987.
-
-   [RFC 1183] - Everhart, C., Mamakos, L., Ullmann, R., and P.
-   Mockapetris, "New DNS RR Definitions", RFC 1183, October 1990.
-
-   [RFC 1996] - Vixie, P., "A Mechanism for Prompt Notification of Zone
-   Changes (DNS NOTIFY)", RFC 1996, August 1996.
-
-   [RFC 2136] - Vixie, P., Thomson, S., Rekhter, Y. and J. Bound,
-   "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
-   April 1997.
-
-   [RFC 2181] - Elz, R. and R. Bush, "Clarifications to the DNS
-   Specification", RFC 2181, July 1997.
-
-   [RFC 2434] - Narten, T. and H. Alvestrand, "Guidelines for Writing an
-   IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
-
-   [RFC 2671] - Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC
-   2671, August 1999.
-
-   [RFC 2673] - Crawford, M., "Binary Labels in the Domain Name System",
-   RFC 2673, August 1999.
-
-   [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake, D. and B.
-   Wellington, "Secret Key Transaction Authentication for DNS (TSIG)",
-   RFC 2845, May 2000.
-
-
-D. Eastlake 3rd                                                [Page 13]
-
-
-INTERNET-DRAFT           DNS IANA Considerations             August 2005
-
-
-   [RFC 2930] - Eastlake, D., "Secret Key Establishment for DNS (TKEY
-   RR)", September 2000.
-
-   [RFC 3363] - Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
-   Hain, "Representing Internet Protocol version 6 (IPv6) Addresses in
-   the Domain Name System (DNS)", RFC 3363, August 2002.
-
-   [RFC 3425] - Lawrence, D., "Obsoleting IQUERY", RFC 3425, November
-   2002.
-
-   [RFC 4020] - Kompella, K. and A. Zinin, "Early IANA Allocation of
-   Standards Track Code Points", BCP 100, RFC 4020, February 2005.
-
-   [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
-   Rose, "DNS Security Introduction and Requirements", RFC 4033, March
-   2005.
-
-   [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
-   Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
-   March 2005.
-
-   [RFC 4044] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
-   Rose, "Protocol Modifications for the DNS Security Extensions", RFC
-   4035, March 2005.
-
-   [US-ASCII] - ANSI, "USA Standard Code for Information Interchange",
-   X3.4, American National Standards Institute: New York, 1968.
-
-
-
-Informative References
-
-   [Dyer 1987] - Dyer, S., and F. Hsu, "Hesiod", Project Athena
-   Technical Plan - Name Service, April 1987,
-
-   [Moon 1981] - D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts
-   Institute of Technology Artificial Intelligence Laboratory, June
-   1981.
-
-   [RFC 1591] - Postel, J., "Domain Name System Structure and
-   Delegation", RFC 1591, March 1994.
-
-   [RFC 2929] - Eastlake 3rd, D., Brunner-Williams, E., and B. Manning,
-   "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 2929,
-   September 2000.
-
-   [RFC 2606] - Eastlake, D. and A. Panitz, "Reserved Top Level DNS
-   Names", RFC 2606, June 1999.
-
-   [insensitive] - Eastlake, D., "Domain Name System (DNS) Case
-
-
-D. Eastlake 3rd                                                [Page 14]
-
-
-INTERNET-DRAFT           DNS IANA Considerations             August 2005
-
-
-   Insensitivity Clarification", draft-ietf-dnsext-insensitive-*.txt,
-   work in progress.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                [Page 15]
-
-
-INTERNET-DRAFT           DNS IANA Considerations             August 2005
-
-
-Authors Addresses
-
-   Donald E. Eastlake 3rd
-   Motorola Laboratories
-   155 Beaver Street
-   Milford, MA 01757 USA
-
-   Telephone:   +1-508-786-7554 (w)
-   email:       Donald.Eastlake@motorola.com
-
-
-
-Expiration and File Name
-
-   This draft expires February 2006.
-
-   Its file name is draft-ietf-dnsext-2929bis-01.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                [Page 16]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt
deleted file mode 100644
index f0ce70a..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt
+++ /dev/null
@@ -1,393 +0,0 @@
-
-
-
-INTERNET-DRAFT                                      Andreas Gustafsson
-draft-ietf-dnsext-axfr-clarify-05.txt                     Nominum Inc.
-                                                         November 2002
-
-
-               DNS Zone Transfer Protocol Clarifications
-
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-Abstract
-
-   In the Domain Name System, zone data is replicated among
-   authoritative DNS servers by means of the "zone transfer" protocol,
-   also known as the "AXFR" protocol.  This memo clarifies, updates, and
-   adds missing detail to the original AXFR protocol specification in
-   RFC1034.
-
-1. Introduction
-
-   The original definition of the DNS zone transfer protocol consists of
-   a single paragraph in [RFC1034] section 4.3.5 and some additional
-   notes in [RFC1035] section 6.3.  It is not sufficiently detailed to
-   serve as the sole basis for constructing interoperable
-   implementations.  This document is an attempt to provide a more
-   complete definition of the protocol.  Where the text in RFC1034
-   conflicts with existing practice, the existing practice has been
-   codified in the interest of interoperability.
-
-
-
-
-Expires May 2003                                                [Page 1]
-
-draft-ietf-dnsext-axfr-clarify-05.txt                      November 2002
-
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC 2119].
-
-2. The zone transfer request
-
-   To initiate a zone transfer, the slave server sends a zone transfer
-   request to the master server over a reliable transport such as TCP.
-   The form of this request is specified in sufficient detail in RFC1034
-   and needs no further clarification.
-
-   Implementers are advised that one server implementation in widespread
-   use sends AXFR requests where the TCP message envelope size exceeds
-   the DNS request message size by two octets.
-
-3. The zone transfer response
-
-   If the master server is unable or unwilling to provide a zone
-   transfer, it MUST respond with a single DNS message containing an
-   appropriate RCODE other than NOERROR.  If the master is not
-   authoritative for the requested zone, the RCODE SHOULD be 9
-   (NOTAUTH).
-
-   Slave servers should note that some master server implementations
-   will simply close the connection when denying the slave access to the
-   zone.  Therefore, slaves MAY interpret an immediate graceful close of
-   the TCP connection as equivalent to a "Refused" response (RCODE 5).
-
-   If a zone transfer can be provided, the master server sends one or
-   more DNS messages containing the zone data as described below.
-
-3.1. Multiple answers per message
-
-   The zone data in a zone transfer response is a sequence of answer
-   RRs.  These RRs are transmitted in the answer section(s) of one or
-   more DNS response messages.
-
-   The AXFR protocol definition in RFC1034 does not make a clear
-   distinction between response messages and answer RRs.  Historically,
-   DNS servers always transmitted a single answer RR per message.  This
-   encoding is wasteful due to the overhead of repeatedly sending DNS
-   message headers and the loss of domain name compression
-   opportunities.  To improve efficiency, some newer servers support a
-   mode where multiple RRs are transmitted in a single DNS response
-   message.
-
-   A master MAY transmit multiple answer RRs per response message up to
-   the largest number that will fit within the 65535 byte limit on TCP
-
-
-
-Expires May 2003                                                [Page 2]
-
-draft-ietf-dnsext-axfr-clarify-05.txt                      November 2002
-
-
-   DNS message size.  In the case of a small zone, this can cause the
-   entire transfer to be transmitted in a single response message.
-
-   Slaves MUST accept messages containing any number of answer RRs.  For
-   compatibility with old slaves, masters that support sending multiple
-   answers per message SHOULD be configurable to revert to the
-   historical mode of one answer per message, and the configuration
-   SHOULD be settable on a per-slave basis.
-
-3.2. DNS message header contents
-
-   RFC1034 does not specify the contents of the DNS message header of
-   the zone transfer response messages.  The header of each message MUST
-   be as follows:
-
-       ID      Copy from request
-       QR      1
-       OPCODE  QUERY
-       AA      1, but MAY be 0 when RCODE is not NOERROR
-       TC      0
-       RD      Copy from request, or 0
-       RA      Set according to availability of recursion, or 0
-       Z       0
-       AD      0
-       CD      0
-       RCODE   NOERROR on success, error code otherwise
-
-   The slave MUST check the RCODE in each message and abort the transfer
-   if it is not NOERROR.  It SHOULD check the ID of the first message
-   received and abort the transfer if it does not match the ID of the
-   request.  The ID SHOULD be ignored in subsequent messages, and fields
-   other than RCODE and ID SHOULD be ignored in all messages, to ensure
-   interoperability with certain older implementations which transmit
-   incorrect or arbitrary values in these fields.
-
-3.3. Additional section and SIG processing
-
-   Zone transfer responses are not subject to any kind of additional
-   section processing or automatic inclusion of SIG records.  SIG RRs in
-   the zone data are treated exactly the same as any other RR type.
-
-3.4. The question section
-
-   RFC1034 does not specify whether zone transfer response messages have
-   a question section or not.  The initial message of a zone transfer
-   response SHOULD have a question section identical to that in the
-   request.  Subsequent messages SHOULD NOT have a question section,
-   though the final message MAY.  The receiving slave server MUST accept
-
-
-
-Expires May 2003                                                [Page 3]
-
-draft-ietf-dnsext-axfr-clarify-05.txt                      November 2002
-
-
-   any combination of messages with and without a question section.
-
-3.5. The authority section
-
-   The master server MUST transmit messages with an empty authority
-   section.  Slaves MUST ignore any authority section contents they may
-   receive from masters that do not comply with this requirement.
-
-3.6. The additional section
-
-   The additional section MAY contain additional RRs such as transaction
-   signatures.  The slave MUST ignore any unexpected RRs in the
-   additional section.  It MUST NOT treat additional section RRs as zone
-   data.
-
-4. Zone data
-
-   The purpose of the zone transfer mechanism is to exactly replicate at
-   each slave the set of RRs associated with a particular zone at its
-   primary master.  An RR is associated with a zone by being loaded from
-   the master file of that zone at the primary master server, or by some
-   other, equivalent method for configuring zone data.
-
-   This replication shall be complete and unaltered, regardless of how
-   many and which intermediate masters/slaves are involved, and
-   regardless of what other zones those intermediate masters/slaves do
-   or do not serve, and regardless of what data may be cached in
-   resolvers associated with the intermediate masters/slaves.
-
-   Therefore, in a zone transfer the master MUST send exactly those
-   records that are associated with the zone, whether or not their owner
-   names would be considered to be "in" the zone for purposes of
-   resolution, and whether or not they would be eligible for use as glue
-   in responses.  The transfer MUST NOT include any RRs that are not
-   associated with the zone, such as RRs associated with zones other
-   than the one being transferred or present in the cache of the local
-   resolver, even if their owner names are in the zone being transferred
-   or are pointed to by NS records in the zone being transferred.
-
-   The slave MUST associate the RRs received in a zone transfer with the
-   specific zone being transferred, and maintain that association for
-   purposes of acting as a master in outgoing transfers.
-
-5. Transmission order
-
-   RFC1034 states that "The first and last messages must contain the
-   data for the top authoritative node of the zone".  This is not
-   consistent with existing practice.  All known master implementations
-
-
-
-Expires May 2003                                                [Page 4]
-
-draft-ietf-dnsext-axfr-clarify-05.txt                      November 2002
-
-
-   send, and slave implementations expect to receive, the zone's SOA RR
-   as the first and last record of the transfer.
-
-   Therefore, the quoted sentence is hereby superseded by the sentence
-   "The first and last RR transmitted must be the SOA record of the
-   zone".
-
-   The initial and final SOA record MUST be identical, with the possible
-   exception of case and compression.  In particular, they MUST have the
-   same serial number.  The slave MUST consider the transfer to be
-   complete when, and only when, it has received the message containing
-   the second SOA record.
-
-   The transmission order of all other RRs in the zone is undefined.
-   Each of them SHOULD be transmitted only once, and slaves MUST ignore
-   any duplicate RRs received.
-
-6. Security Considerations
-
-   The zone transfer protocol as defined in [RFC1034] and clarified by
-   this memo does not have any built-in mechanisms for the slave to
-   securely verify the identity of the master server and the integrity
-   of the transferred zone data.  The use of a cryptographic mechanism
-   for ensuring authenticity and integrity, such as TSIG [RFC2845],
-   IPSEC, or TLS, is RECOMMENDED.
-
-   The zone transfer protocol allows read-only public access to the
-   complete zone data.  Since data in the DNS is public by definition,
-   this is generally acceptable.  Sites that wish to avoid disclosing
-   their full zone data MAY restrict zone transfer access to authorized
-   slaves.
-
-   These clarifications are not believed to themselves introduce any new
-   security problems, nor to solve any existing ones.
-
-Acknowledgements
-
-   Many people have contributed input and commentary to earlier versions
-   of this document, including but not limited to Bob Halley, Dan
-   Bernstein, Eric A. Hall, Josh Littlefield, Kevin Darcy, Robert Elz,
-   Levon Esibov, Mark Andrews, Michael Patton, Peter Koch, Sam
-   Trenholme, and Brian Wellington.
-
-References
-
-   [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris,
-   November 1987.
-
-
-
-
-Expires May 2003                                                [Page 5]
-
-draft-ietf-dnsext-axfr-clarify-05.txt                      November 2002
-
-
-   [RFC1035] - Domain Names - Implementation and Specifications, P.
-   Mockapetris, November 1987.
-
-   [RFC2119] - Key words for use in RFCs to Indicate Requirement Levels,
-   S. Bradner, BCP 14, March 1997.
-
-   [RFC2845] - Secret Key Transaction Authentication for DNS (TSIG).  P.
-   Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, May 2000.
-
-Author's Address
-
-   Andreas Gustafsson
-   Nominum Inc.
-   2385 Bay Rd
-   Redwood City, CA 94063
-   USA
-
-   Phone: +1 650 381 6004
-
-   Email: gson@nominum.com
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2000 - 2002).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implmentation may be prepared, copied, published and
-   distributed, in whole or in part, without restriction of any kind,
-   provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-
-
-
-Expires May 2003                                                [Page 6]
-
-draft-ietf-dnsext-axfr-clarify-05.txt                      November 2002
-
-
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires May 2003                                                [Page 7]
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dhcid-rr-12.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dhcid-rr-12.txt
deleted file mode 100644
index 07749d9..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dhcid-rr-12.txt
+++ /dev/null
@@ -1,674 +0,0 @@
-
-
-
-
-DNSEXT                                                          M. Stapp
-Internet-Draft                                       Cisco Systems, Inc.
-Expires: September 1, 2006                                      T. Lemon
-                                                           Nominum, Inc.
-                                                           A. Gustafsson
-                                          Araneus Information Systems Oy
-                                                       February 28, 2006
-
-
-           A DNS RR for Encoding DHCP Information (DHCID RR)
-                  <draft-ietf-dnsext-dhcid-rr-12.txt>
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on September 1, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   It is possible for DHCP clients to attempt to update the same DNS
-   FQDN or attempt to update a DNS FQDN that has been added to the DNS
-   for another purpose as they obtain DHCP leases.  Whether the DHCP
-   server or the clients themselves perform the DNS updates, conflicts
-   can arise.  To resolve such conflicts, "Resolution of DNS Name
-
-
-
-Stapp, et al.           Expires September 1, 2006               [Page 1]
-
-Internet-Draft                The DHCID RR                 February 2006
-
-
-   Conflicts" [1] proposes storing client identifiers in the DNS to
-   unambiguously associate domain names with the DHCP clients to which
-   they refer.  This memo defines a distinct RR type for this purpose
-   for use by DHCP clients and servers, the "DHCID" RR.
-
-
-Table of Contents
-
-   1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   3.  The DHCID RR . . . . . . . . . . . . . . . . . . . . . . . . .  3
-     3.1.  DHCID RDATA format . . . . . . . . . . . . . . . . . . . .  3
-     3.2.  DHCID Presentation Format  . . . . . . . . . . . . . . . .  4
-     3.3.  The DHCID RR Identifier Type Codes . . . . . . . . . . . .  4
-     3.4.  The DHCID RR Digest Type Code  . . . . . . . . . . . . . .  4
-     3.5.  Computation of the RDATA . . . . . . . . . . . . . . . . .  5
-       3.5.1.  Using the Client's DUID  . . . . . . . . . . . . . . .  5
-       3.5.2.  Using the Client Identifier Option . . . . . . . . . .  5
-       3.5.3.  Using the Client's htype and chaddr  . . . . . . . . .  6
-     3.6.  Examples . . . . . . . . . . . . . . . . . . . . . . . . .  6
-       3.6.1.  Example 1  . . . . . . . . . . . . . . . . . . . . . .  6
-       3.6.2.  Example 2  . . . . . . . . . . . . . . . . . . . . . .  6
-       3.6.3.  Example 3  . . . . . . . . . . . . . . . . . . . . . .  7
-   4.  Use of the DHCID RR  . . . . . . . . . . . . . . . . . . . . .  7
-   5.  Updater Behavior . . . . . . . . . . . . . . . . . . . . . . .  8
-   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
-   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
-   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
-   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
-     9.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
-     9.2.  Informative References . . . . . . . . . . . . . . . . . . 10
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
-   Intellectual Property and Copyright Statements . . . . . . . . . . 12
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stapp, et al.           Expires September 1, 2006               [Page 2]
-
-Internet-Draft                The DHCID RR                 February 2006
-
-
-1.  Terminology
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [2].
-
-
-2.  Introduction
-
-   A set of procedures to allow DHCP [6] [10] clients and servers to
-   automatically update the DNS (RFC 1034 [3], RFC 1035 [4]) is proposed
-   in "Resolution of DNS Name Conflicts" [1].
-
-   Conflicts can arise if multiple DHCP clients wish to use the same DNS
-   name or a DHCP client attempts to use a name added for another
-   purpose.  To resolve such conflicts, "Resolution of DNS Name
-   Conflicts" [1] proposes storing client identifiers in the DNS to
-   unambiguously associate domain names with the DHCP clients using
-   them.  In the interest of clarity, it is preferable for this DHCP
-   information to use a distinct RR type.  This memo defines a distinct
-   RR for this purpose for use by DHCP clients or servers, the "DHCID"
-   RR.
-
-   In order to obscure potentially sensitive client identifying
-   information, the data stored is the result of a one-way SHA-256 hash
-   computation.  The hash includes information from the DHCP client's
-   message as well as the domain name itself, so that the data stored in
-   the DHCID RR will be dependent on both the client identification used
-   in the DHCP protocol interaction and the domain name.  This means
-   that the DHCID RDATA will vary if a single client is associated over
-   time with more than one name.  This makes it difficult to 'track' a
-   client as it is associated with various domain names.
-
-
-3.  The DHCID RR
-
-   The DHCID RR is defined with mnemonic DHCID and type code [TBD].  The
-   DHCID RR is only defined in the IN class.  DHCID RRs cause no
-   additional section processing.  The DHCID RR is not a singleton type.
-
-3.1.  DHCID RDATA format
-
-   The RDATA section of a DHCID RR in transmission contains RDLENGTH
-   octets of binary data.  The format of this data and its
-   interpretation by DHCP servers and clients are described below.
-
-   DNS software should consider the RDATA section to be opaque.  DHCP
-   clients or servers use the DHCID RR to associate a DHCP client's
-
-
-
-Stapp, et al.           Expires September 1, 2006               [Page 3]
-
-Internet-Draft                The DHCID RR                 February 2006
-
-
-   identity with a DNS name, so that multiple DHCP clients and servers
-   may deterministically perform dynamic DNS updates to the same zone.
-   From the updater's perspective, the DHCID resource record RDATA
-   consists of a 2-octet identifier type, in network byte order,
-   followed by a 1-octet digest type, followed by one or more octets
-   representing the actual identifier:
-
-           < 2 octets >    Identifier type code
-           < 1 octet >     Digest type code
-           < n octets >    Digest (length depends on digest type)
-
-3.2.  DHCID Presentation Format
-
-   In DNS master files, the RDATA is represented as a single block in
-   base 64 encoding identical to that used for representing binary data
-   in RFC 3548 [7].  The data may be divided up into any number of white
-   space separated substrings, down to single base 64 digits, which are
-   concatenated to form the complete RDATA.  These substrings can span
-   lines using the standard parentheses.
-
-3.3.  The DHCID RR Identifier Type Codes
-
-   The DHCID RR Identifier Type Code specifies what data from the DHCP
-   client's request was used as input into the hash function.  The
-   identifier type codes are defined in a registry maintained by IANA,
-   as specified in Section 7.  The initial list of assigned values for
-   the identifier type code is:
-
-   0x0000 = htype, chaddr from a DHCPv4 client's DHCPREQUEST [6].
-   0x0001 = The data octets (i.e., the Type and Client-Identifier
-      fields) from a DHCPv4 client's Client Identifier option [9].
-   0x0002 = The client's DUID (i.e., the data octets of a DHCPv6
-      client's Client Identifier option [10] or the DUID field from a
-      DHCPv4 client's Client Identifier option [12]).
-
-   0x0003 - 0xfffe = Available to be assigned by IANA.
-
-   0xffff = RESERVED
-
-3.4.  The DHCID RR Digest Type Code
-
-   The DHCID RR Digest Type Code is an identifier for the digest
-   algorithm used.  The digest is calculated over an identifier and the
-   canonical FQDN as described in the next section.
-
-   The digest type codes are defined in a registry maintained by IANA,
-   as specified in Section 7.  The initial list of assigned values for
-   the digest type codes is: value 0 is reserved and value 1 is SHA-256.
-
-
-
-Stapp, et al.           Expires September 1, 2006               [Page 4]
-
-Internet-Draft                The DHCID RR                 February 2006
-
-
-   Reserving other types requires IETF standards action.  Defining new
-   values will also require IETF standards action to document how DNS
-   updaters are to deal with multiple digest types.
-
-3.5.  Computation of the RDATA
-
-   The DHCID RDATA is formed by concatenating the 2-octet identifier
-   type code with variable-length data.
-
-   The RDATA for all type codes other than 0xffff, which is reserved for
-   future expansion, is formed by concatenating the 2-octet identifier
-   type code, the 1-octet digest type code, and the digest value (32
-   octets for SHA-256).
-
-       < identifier-type > < digest-type > < digest >
-
-   The input to the digest hash function is defined to be:
-
-       digest = SHA-256(< identifier > < FQDN >)
-
-   The FQDN is represented in the buffer in unambiguous canonical form
-   as described in RFC 4034 [8], section 6.1.  The identifier type code
-   and the identifier are related as specified in Section 3.3: the
-   identifier type code describes the source of the identifier.
-
-   A DHCPv4 updater uses the 0x0002 type code if a Client Identifier
-   option is present in the DHCPv4 messages and it is encoded as
-   specified in [12].  Otherwise, the updater uses 0x0001 if a Client
-   Identifier option is present and 0x0000 if not.
-
-   A DHCPv6 updater always uses the 0x0002 type code.
-
-3.5.1.  Using the Client's DUID
-
-   When the updater is using the Client's DUID (either from a DHCPv6
-   Client Identifier option or from a portion of the DHCPv4 Client
-   Identifier option encoded as specified in [12]), the first two octets
-   of the DHCID RR MUST be 0x0002, in network byte order.  The third
-   octet is the digest type code (1 for SHA-256).  The rest of the DHCID
-   RR MUST contain the results of computing the SHA-256 hash across the
-   octets of the DUID followed by the FQDN.
-
-3.5.2.  Using the Client Identifier Option
-
-   When the updater is using the DHCPv4 Client Identifier option sent by
-   the client in its DHCPREQUEST message, the first two octets of the
-   DHCID RR MUST be 0x0001, in network byte order.  The third octet is
-   the digest type code (1 for SHA-256).  The rest of the DHCID RR MUST
-
-
-
-Stapp, et al.           Expires September 1, 2006               [Page 5]
-
-Internet-Draft                The DHCID RR                 February 2006
-
-
-   contain the results of computing the SHA-256 hash across the data
-   octets (i.e., the Type and Client-Identifier fields) of the option,
-   followed by the FQDN.
-
-3.5.3.  Using the Client's htype and chaddr
-
-   When the updater is using the client's link-layer address as the
-   identifier, the first two octets of the DHCID RDATA MUST be zero.
-   The third octet is the digest type code (1 for SHA-256).  To generate
-   the rest of the resource record, the updater computes a one-way hash
-   using the SHA-256 algorithm across a buffer containing the client's
-   network hardware type, link-layer address, and the FQDN data.
-   Specifically, the first octet of the buffer contains the network
-   hardware type as it appeared in the DHCP 'htype' field of the
-   client's DHCPREQUEST message.  All of the significant octets of the
-   'chaddr' field in the client's DHCPREQUEST message follow, in the
-   same order in which the octets appear in the DHCPREQUEST message.
-   The number of significant octets in the 'chaddr' field is specified
-   in the 'hlen' field of the DHCPREQUEST message.  The FQDN data, as
-   specified above, follows.
-
-3.6.  Examples
-
-3.6.1.  Example 1
-
-   A DHCP server allocating the IPv4 address 10.0.0.1 to a client with
-   Ethernet MAC address 01:02:03:04:05:06 using domain name
-   "client.example.com" uses the client's link-layer address to identify
-   the client.  The DHCID RDATA is composed by setting the two type
-   octets to zero, the 1-octet digest type to 1 for SHA-256, and
-   performing an SHA-256 hash computation across a buffer containing the
-   Ethernet MAC type octet, 0x01, the six octets of MAC address, and the
-   domain name (represented as specified in Section 3.5).
-
-     client.example.com.   A       10.0.0.1
-     client.example.com.   DHCID   ( AAABxLmlskllE0MVjd57zHcWmEH3pCQ6V
-                                     ytcKD//7es/deY= )
-
-   If the DHCID RR type is not supported, the RDATA would be encoded
-   [13] as:
-
-     \# 35 ( 000001c4b9a5b249651343158dde7bcc77169841f7a4243a572b5c283
-             fffedeb3f75e6 )
-
-3.6.2.  Example 2
-
-   A DHCP server allocates the IPv4 address 10.0.12.99 to a client which
-   included the DHCP client-identifier option data 01:07:08:09:0a:0b:0c
-
-
-
-Stapp, et al.           Expires September 1, 2006               [Page 6]
-
-Internet-Draft                The DHCID RR                 February 2006
-
-
-   in its DHCP request.  The server updates the name "chi.example.com"
-   on the client's behalf, and uses the DHCP client identifier option
-   data as input in forming a DHCID RR.  The DHCID RDATA is formed by
-   setting the two type octets to the value 0x0001, the 1-octet digest
-   type to 1 for SHA-256, and performing a SHA-256 hash computation
-   across a buffer containing the seven octets from the client-id option
-   and the FQDN (represented as specified in Section 3.5).
-
-     chi.example.com.      A       10.0.12.99
-     chi.example.com.      DHCID   ( AAEBOSD+XR3Os/0LozeXVqcNc7FwCfQdW
-                                     L3b/NaiUDlW2No= )
-
-   If the DHCID RR type is not supported, the RDATA would be encoded
-   [13] as:
-
-     \# 35 ( 0001013920fe5d1dceb3fd0ba3379756a70d73b17009f41d58bddbfcd
-             6a2503956d8da )
-
-3.6.3.  Example 3
-
-   A DHCP server allocates the IPv6 address 2000::1234:5678 to a client
-   which included the DHCPv6 client-identifier option data 00:01:00:06:
-   41:2d:f1:66:01:02:03:04:05:06 in its DHCPv6 request.  The server
-   updates the name "chi6.example.com" on the client's behalf, and uses
-   the DHCP client identifier option data as input in forming a DHCID
-   RR.  The DHCID RDATA is formed by setting the two type octets to the
-   value 0x0002, the 1-octet digest type to 1 for SHA-256, and
-   performing a SHA-256 hash computation across a buffer containing the
-   14 octets from the client-id option and the FQDN (represented as
-   specified in Section 3.5).
-
-     chi6.example.com.     AAAA    2000::1234:5678
-     chi6.example.com.     DHCID   ( AAIBY2/AuCccgoJbsaxcQc9TUapptP69l
-                                     OjxfNuVAA2kjEA= )
-
-   If the DHCID RR type is not supported, the RDATA would be encoded
-   [13] as:
-
-     \# 35 ( 000201636fc0b8271c82825bb1ac5c41cf5351aa69b4febd94e8f17cd
-             b95000da48c40 )
-
-
-4.  Use of the DHCID RR
-
-   This RR MUST NOT be used for any purpose other than that detailed in
-   "Resolution of DNS Name Conflicts" [1].  Although this RR contains
-   data that is opaque to DNS servers, the data must be consistent
-   across all entities that update and interpret this record.
-
-
-
-Stapp, et al.           Expires September 1, 2006               [Page 7]
-
-Internet-Draft                The DHCID RR                 February 2006
-
-
-   Therefore, new data formats may only be defined through actions of
-   the DHC Working Group, as a result of revising [1].
-
-
-5.  Updater Behavior
-
-   The data in the DHCID RR allows updaters to determine whether more
-   than one DHCP client desires to use a particular FQDN.  This allows
-   site administrators to establish policy about DNS updates.  The DHCID
-   RR does not establish any policy itself.
-
-   Updaters use data from a DHCP client's request and the domain name
-   that the client desires to use to compute a client identity hash, and
-   then compare that hash to the data in any DHCID RRs on the name that
-   they wish to associate with the client's IP address.  If an updater
-   discovers DHCID RRs whose RDATA does not match the client identity
-   that they have computed, the updater SHOULD conclude that a different
-   client is currently associated with the name in question.  The
-   updater SHOULD then proceed according to the site's administrative
-   policy.  That policy might dictate that a different name be selected,
-   or it might permit the updater to continue.
-
-
-6.  Security Considerations
-
-   The DHCID record as such does not introduce any new security problems
-   into the DNS.  In order to obscure the client's identity information,
-   a one-way hash is used.  And, in order to make it difficult to
-   'track' a client by examining the names associated with a particular
-   hash value, the FQDN is included in the hash computation.  Thus, the
-   RDATA is dependent on both the DHCP client identification data and on
-   each FQDN associated with the client.
-
-   However, it should be noted that an attacker that has some knowledge,
-   such as of MAC addresses commonly used in DHCP client identification
-   data, may be able to discover the client's DHCP identify by using a
-   brute-force attack.  Even without any additional knowledge, the
-   number of unknown bits used in computing the hash is typically only
-   48 to 80.
-
-   Administrators should be wary of permitting unsecured DNS updates to
-   zones, whether or not they are exposed to the global Internet.  Both
-   DHCP clients and servers SHOULD use some form of update
-   authentication (e.g., TSIG [11]) when performing DNS updates.
-
-
-7.  IANA Considerations
-
-
-
-
-Stapp, et al.           Expires September 1, 2006               [Page 8]
-
-Internet-Draft                The DHCID RR                 February 2006
-
-
-   IANA is requested to allocate a DNS RR type number for the DHCID
-   record type.
-
-   This specification defines a new number-space for the 2-octet
-   identifier type codes associated with the DHCID RR.  IANA is
-   requested to establish a registry of the values for this number-
-   space.  Three initial values are assigned in Section 3.3, and the
-   value 0xFFFF is reserved for future use.  New DHCID RR identifier
-   type codes are assigned through Standards Action, as defined in RFC
-   2434 [5].
-
-   This specification defines a new number-space for the 1-octet digest
-   type codes associated with the DHCID RR.  IANA is requested to
-   establish a registry of the values for this number-space.  Two
-   initial values are assigned in Section 3.4.  New DHCID RR digest type
-   codes are assigned through Standards Action, as defined in RFC 2434
-   [5].
-
-
-8.  Acknowledgements
-
-   Many thanks to Harald Alvestrand, Ralph Droms, Olafur Gudmundsson,
-   Sam Hartman, Josh Littlefield, Pekka Savola, and especially Bernie
-   Volz for their review and suggestions.
-
-
-9.  References
-
-9.1.  Normative References
-
-   [1]  Stapp, M. and B. Volz, "Resolution of DNS Name Conflicts Among
-        DHCP Clients (draft-ietf-dhc-dns-resolution-*)", February 2006.
-
-   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [3]  Mockapetris, P., "Domain names - concepts and facilities",
-        STD 13, RFC 1034, November 1987.
-
-   [4]  Mockapetris, P., "Domain names - implementation and
-        specification", STD 13, RFC 1035, November 1987.
-
-   [5]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
-        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
-
-
-
-
-
-
-
-Stapp, et al.           Expires September 1, 2006               [Page 9]
-
-Internet-Draft                The DHCID RR                 February 2006
-
-
-9.2.  Informative References
-
-   [6]   Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
-         March 1997.
-
-   [7]   Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
-         RFC 3548, July 2003.
-
-   [8]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "Resource Records for the DNS Security Extensions", RFC 4034,
-         March 2005.
-
-   [9]   Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
-         Extensions", RFC 2132, March 1997.
-
-   [10]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
-         Carney, "Dynamic Host Configuration Protocol for IPv6
-         (DHCPv6)", RFC 3315, July 2003.
-
-   [11]  Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington,
-         "Secret Key Transaction Authentication for DNS (TSIG)",
-         RFC 2845, May 2000.
-
-   [12]  Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers
-         for Dynamic Host Configuration Protocol Version Four (DHCPv4)",
-         RFC 4361, February 2006.
-
-   [13]  Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
-         Types", RFC 3597, September 2003.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stapp, et al.           Expires September 1, 2006              [Page 10]
-
-Internet-Draft                The DHCID RR                 February 2006
-
-
-Authors' Addresses
-
-   Mark Stapp
-   Cisco Systems, Inc.
-   1414 Massachusetts Ave.
-   Boxborough, MA  01719
-   USA
-
-   Phone: 978.936.1535
-   Email: mjs@cisco.com
-
-
-   Ted Lemon
-   Nominum, Inc.
-   950 Charter St.
-   Redwood City, CA  94063
-   USA
-
-   Email: mellon@nominum.com
-
-
-   Andreas Gustafsson
-   Araneus Information Systems Oy
-   Ulappakatu 1
-   02320 Espoo
-   Finland
-
-   Email: gson@araneus.fi
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stapp, et al.           Expires September 1, 2006              [Page 11]
-
-Internet-Draft                The DHCID RR                 February 2006
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Stapp, et al.           Expires September 1, 2006              [Page 12]
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt
deleted file mode 100644
index 438e800..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt
+++ /dev/null
@@ -1,1397 +0,0 @@
-DNS Extensions Working Group                                   G. Sisson
-Internet-Draft                                                 B. Laurie
-Expires: January 11, 2006                                        Nominet
-                                                           July 10, 2005
-
-
-            Derivation of DNS Name Predecessor and Successor
-                   draft-ietf-dnsext-dns-name-p-s-00
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on January 11, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document describes two methods for deriving the canonically-
-   ordered predecessor and successor of a DNS name.  These methods may
-   be used for dynamic NSEC resource record synthesis, enabling
-   security-aware name servers to provide authenticated denial of
-   existence without disclosing other owner names in a DNSSEC-secured
-   zone.
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006                [Page 1]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Notational Conventions . . . . . . . . . . . . . . . . . . . .  3
-   3.  Absolute Method  . . . . . . . . . . . . . . . . . . . . . . .  4
-     3.1.  Derivation of DNS Name Predecessor . . . . . . . . . . . .  4
-     3.2.  Derivation of DNS Name Successor . . . . . . . . . . . . .  4
-   4.  Modified Method  . . . . . . . . . . . . . . . . . . . . . . .  5
-     4.1.  Derivation of DNS Name Predecessor . . . . . . . . . . . .  6
-     4.2.  Derivation of DNS Name Successor . . . . . . . . . . . . .  6
-   5.  Notes  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
-     5.1.  Case Considerations  . . . . . . . . . . . . . . . . . . .  7
-     5.2.  Choice of Range  . . . . . . . . . . . . . . . . . . . . .  7
-     5.3.  Wild Card Considerations . . . . . . . . . . . . . . . . .  8
-     5.4.  Possible Modifications . . . . . . . . . . . . . . . . . .  8
-       5.4.1.  Restriction of Effective Maximum DNS Name Length . . .  8
-       5.4.2.  Use of Modified Method With Zones Containing
-               SRV RRs  . . . . . . . . . . . . . . . . . . . . . . .  9
-   6.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
-     6.1.  Examples of Immediate Predecessors Using Absolute
-           Method . . . . . . . . . . . . . . . . . . . . . . . . . . 10
-     6.2.  Examples of Immediate Successors Using Absolute Method . . 13
-     6.3.  Examples of Predecessors Using Modified Method . . . . . . 19
-     6.4.  Examples of Successors Using Modified Method . . . . . . . 20
-   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
-   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
-   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
-     10.1. Normative References . . . . . . . . . . . . . . . . . . . 22
-     10.2. Informative References . . . . . . . . . . . . . . . . . . 22
-   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 21
-   Appendix A.  Change History  . . . . . . . . . . . . . . . . . . . 22
-     A.1.  Changes from sisson-02 to ietf-00  . . . . . . . . . . . . 22
-     A.2.  Changes from sisson-01 to sisson-02  . . . . . . . . . . . 23
-     A.3.  Changes from sisson-00 to sisson-01  . . . . . . . . . . . 23
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
-   Intellectual Property and Copyright Statements . . . . . . . . . . 25
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006                [Page 2]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-1.  Introduction
-
-   One of the proposals for avoiding the exposure of zone information
-   during the deployment DNSSEC is dynamic NSEC resource record (RR)
-   synthesis.  This technique is described in [I-D.ietf-dnsext-dnssec-
-   trans] and [I-D.ietf-dnsext-dnssec-online-signing], and involves the
-   generation of NSEC RRs that just span the query name for non-existent
-   owner names.  In order to do this, the DNS names which would occur
-   just prior to and just following a given query name must be
-   calculated in real time, as maintaining a list of all possible owner
-   names that might occur in a zone would be impracticable.
-
-   Section 6.1 of [RFC4034] defines canonical DNS name order.  This
-   document does not amend or modify this definition.  However, the
-   derivation of immediate predecessor and successor, while trivial, is
-   non-obvious.  Accordingly, several methods are described here as an
-   aid to implementors and a reference to other interested parties.
-
-   This document describes two methods:
-
-   1.  An ``absolute method'', which returns the immediate predecessor
-       or successor of a domain name such that no valid DNS name could
-       exist between that DNS name and the predecessor or successor.
-
-   2.  A ``modified method'', which returns a predecessor and successor
-       which are more economical in size and computation.  This method
-       is restricted to use with zones consisting only of single-label
-       owner names where a maximum-length owner name would not result in
-       a DNS name exceeding the maximum DNS name length.  This is,
-       however, the type of zone for which the technique of online-
-       signing is most likely to be used.
-
-
-2.  Notational Conventions
-
-   The following notational conventions are used in this document for
-   economy of expression:
-
-   N: An unspecified DNS name.
-
-   P(N): Immediate predecessor to N (absolute method).
-
-   S(N): Immediate successor to N (absolute method).
-
-   P'(N): Predecessor to N (modified method).
-
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006                [Page 3]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   S'(N): Successor to N (modified method).
-
-
-3.  Absolute Method
-
-   These derivations assume that all uppercase US-ASCII letters in N
-   have already been replaced by their corresponding lowercase
-   equivalents.  Unless otherwise specified, processing stops after the
-   first step in which a condition is met.
-
-3.1.  Derivation of DNS Name Predecessor
-
-   To derive P(N):
-
-   1.  If N is the same as the owner name of the zone apex, prepend N
-       repeatedly with labels of the maximum length possible consisting
-       of octets of the maximum sort value (e.g. 0xff) until N is the
-       maximum length possible; otherwise continue to the next step.
-
-   2.  If the least significant (left-most) label of N consists of a
-       single octet of the minimum sort value (e.g. 0x00), remove that
-       label; otherwise continue to the next step.
-
-   3.  If the least significant (right-most) octet in the least
-       significant (left-most) label of N is the minimum sort value,
-       remove the least significant octet and continue with step 5.
-
-   4.  Decrement the value of the least significant (right-most) octet,
-       skipping any values that correspond to uppercase US-ASCII
-       letters, and then append the label with as many octets as
-       possible of the maximum sort value.  Continue to the next step.
-
-   5.  Prepend N repeatedly with labels of as long a length as possible
-       consisting of octets of the maximum sort value until N is the
-       maximum length possible.
-
-3.2.  Derivation of DNS Name Successor
-
-   To derive S(N):
-
-   1.  If N is two or more octets shorter than the maximum DNS name
-       length, prepend N with a label containing a single octet of the
-       minimum sort value (e.g. 0x00); otherwise continue to the next
-       step.
-
-   2.  If N is one or more octets shorter than the maximum DNS name
-       length and the least significant (left-most) label is one or more
-       octets shorter than the maximum label length, append an octet of
-
-
-
-Sisson & Laurie         Expires January 11, 2006                [Page 4]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-       the minimum sort value to the least significant label; otherwise
-       continue to the next step.
-
-   3.  Increment the value of the least significant (right-most) octet
-       in the least significant (left-most) label that is less than the
-       maximum sort value (e.g. 0xff), skipping any values that
-       correspond to uppercase US-ASCII letters, and then remove any
-       octets to the right of that one.  If all octets in the label are
-       the maximum sort value, then continue to the next step.
-
-   4.  Remove the least significant (left-most) label.  If N is now the
-       same as the owner name of the zone apex, do nothing.  (This will
-       occur only if N is the maximum possible name in canonical DNS
-       name order, and thus has wrapped to the owner name of zone apex.)
-       Otherwise repeat starting at step 2.
-
-
-4.  Modified Method
-
-   This method is for use with zones consisting only of single-label
-   owner names where an owner name consisting of label of maximum length
-   would not result in a DNS name which exceeded the maximum DNS name
-   length.  This method is computationally simpler and returns values
-   which are more economical in size than the absolute method.  It
-   differs from the absolute method detailed above in the following
-   ways:
-
-   1.  Step 1 of the derivation P(N) has been omitted as the existence
-       of the owner name of the zone apex never requires denial.
-
-   2.  A new step 1 has been introduced which removes unnecessary
-       labels.
-
-   3.  Step 4 of the derivation P(N) has been omitted as it is only
-       necessary for zones containing owner names consisting of more
-       than one label.  This omission generally results in a significant
-       reduction of the length of derived predecessors.
-
-   4.  Step 1 of the derivation S(N) had been omitted as it is only
-       necessary for zones containing owner names consisting of more
-       than one label.  This omission results in a tiny reduction of the
-       length of derived successors, and maintains consistency with the
-       modification of step 4 of the derivation P(N) described above.
-
-   5.  Steps 2 and 4 of the derivation S(N) have been modified to
-       eliminate checks for maximum DNS name length, as it is an
-       assumption of this method that no DNS name in the zone can exceed
-       the maximum DNS name length.
-
-
-
-Sisson & Laurie         Expires January 11, 2006                [Page 5]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   These derivations assume that all uppercase US-ASCII letters in N
-   have already been replaced by their corresponding lowercase
-   equivalents.  Unless otherwise specified, processing stops after the
-   first step in which a condition is met.
-
-4.1.  Derivation of DNS Name Predecessor
-
-   To derive P'(N):
-
-   1.  If N has more labels than the number of labels in the owner name
-       of the apex + 1, repeatedly remove the least significant (left-
-       most) label until N has no more labels than the number of labels
-       in the owner name of the apex + 1; otherwise continue to next
-       step.
-
-   2.  If the least significant (left-most) label of N consists of a
-       single octet of the minimum sort value (e.g. 0x00), remove that
-       label; otherwise continue to the next step.
-
-   3.  If the least significant (right-most) octet in the least
-       significant (left-most) label of N is the minimum sort value,
-       remove the least significant octet.
-
-   4.  Decrement the value of the least significant (right-most) octet,
-       skipping any values which correspond to uppercase US-ASCII
-       letters, and then append the label with as many octets as
-       possible of the maximum sort value.
-
-4.2.  Derivation of DNS Name Successor
-
-   To derive S'(N):
-
-   1.  If N has more labels than the number of labels in the owner name
-       of the apex + 1, repeatedly remove the least significant (left-
-       most) label until N has no more labels than the number of labels
-       in the owner name of the apex + 1.  Continue to next step.
-
-   2.  If the least significant (left-most) label of N is one or more
-       octets shorter than the maximum label length, append an octet of
-       the minimum sort value to the least significant label; otherwise
-       continue to the next step.
-
-   3.  Increment the value of the least significant (right-most) octet
-       in the least significant (left-most) label that is less than the
-       maximum sort value (e.g. 0xff), skipping any values which
-       correspond to uppercase US-ASCII letters, and then remove any
-       octets to the right of that one.  If all octets in the label are
-       the maximum sort value, then continue to the next step.
-
-
-
-Sisson & Laurie         Expires January 11, 2006                [Page 6]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   4.  Remove the least significant (left-most) label.  (This will occur
-       only if the least significant label is the maximum label length
-       and consists entirely of octets of the maximum sort value, and
-       thus has wrapped to the owner name of the zone apex.)
-
-
-5.  Notes
-
-5.1.  Case Considerations
-
-   Section 3.5 of [RFC1034] specifies that "while upper and lower case
-   letters are allowed in [DNS] names, no significance is attached to
-   the case".  Additionally, Section 6.1 of [RFC4034] states that when
-   determining canonical DNS name order, "uppercase US-ASCII letters are
-   treated as if they were lowercase US-ASCII letters".  Consequently,
-   values corresponding to US-ASCII uppercase letters must be skipped
-   when decrementing and incrementing octets in the derivations
-   described in Section 3.1 and Section 3.2.
-
-   The following pseudo-code is illustrative:
-
-   Decrement the value of an octet:
-
-      if (octet == '[')       // '[' is just after uppercase 'Z'
-              octet = '@';    // '@' is just prior to uppercase 'A'
-      else
-              octet--;
-
-   Increment the value of an octet:
-
-      if (octet == '@')       // '@' is just prior to uppercase 'A'
-              octet = '[';    // '[' is just after uppercase 'Z'
-      else
-              octet++;
-
-5.2.  Choice of Range
-
-   [RFC2181] makes the clarification that "any binary string whatever
-   can be used as the label of any resource record".  Consequently the
-   minimum sort value may be set as 0x00 and the maximum sort value as
-   0xff, and the range of possible values will be any DNS name which
-   contains octets of any value other than those corresponding to
-   uppercase US-ASCII letters.
-
-   However, if all owner names in a zone are in the letter-digit-hyphen,
-   or LDH, format specified in [RFC1034], it may be desirable to
-   restrict the range of possible values to DNS names containing only
-   LDH values.  This has the effect of:
-
-
-
-Sisson & Laurie         Expires January 11, 2006                [Page 7]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   1.  making the output of tools such as `dig' and `nslookup' less
-       subject to confusion;
-
-   2.  minimising the impact that NSEC RRs containing DNS names with
-       non-LDH values (or non-printable values) might have on faulty DNS
-       resolver implementations; and
-
-   3.  preventing the possibility of results which are wildcard DNS
-       names (see Section 5.3).
-
-   This may be accomplished by using a minimum sort value of 0x1f (US-
-   ASCII character `-') and a maximum sort value of 0x7a (US-ASCII
-   character lowercase `z'), and then skipping non-LDH, non-lowercase
-   values when incrementing or decrementing octets.
-
-5.3.  Wild Card Considerations
-
-   Neither derivation avoids the possibility that the result may be a
-   DNS name containing a wildcard label, i.e. a label containing a
-   single octet with the value 0x2a (US-ASCII character `*').  With
-   additional tests, wildcard DNS names may be explicitly avoided;
-   alternatively, if the range of octet values can be restricted to
-   those corresponding to letter-digit-hyphen, or LDH, characters (see
-   Section 5.2), such DNS names will not occur.
-
-   Note that it is improbable that a result which is a wildcard DNS name
-   will occur unintentionally; even if one does occur either as the
-   owner name of, or in the RDATA of an NSEC RR, it is treated as a
-   literal DNS name with no special meaning.
-
-5.4.  Possible Modifications
-
-5.4.1.  Restriction of Effective Maximum DNS Name Length
-
-   [RFC1034] specifies that "the total number of octets that represent a
-   [DNS] name (i.e., the sum of all label octets and label lengths) is
-   limited to 255", including the null (zero-length) label which
-   represents the root.  For the purpose of deriving predecessors and
-   successors during NSEC RR synthesis, the maximum DNS name length may
-   be effectively restricted to the length of the longest DNS name in
-   the zone.  This will minimise the size of responses containing
-   synthesised NSEC RRs but, especially in the case of the modified
-   method, may result in some additional computational complexity.
-
-   Note that this modification will have the effect of revealing
-   information about the longest name in the zone.  Moreover, when the
-   contents of the zone changes, e.g. during dynamic updates and zone
-   transfers, care must be taken to ensure that the effective maximum
-
-
-
-Sisson & Laurie         Expires January 11, 2006                [Page 8]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   DNS name length agrees with the new contents.
-
-5.4.2.  Use of Modified Method With Zones Containing SRV RRs
-
-   Normally the modified method cannot be used in zones that contain
-   SRV RRs [RFC2782], as SRV RRs have owner names which contain multiple
-   labels.  However the use of SRV RRs can be accommodated by various
-   techniques.  There are at least four possible ways to do this:
-
-   1.  Use conventional NSEC RRs for the region of the zone that
-       contains first-level labels beginning with the underscore (`_')
-       character.  For the purposes of generating these NSEC RRs, the
-       existence of (possibly fictional) ownernames `9{63}' and `a'
-       could be assumed, providing a lower and upper bound for this
-       region.  Then all queries where the QNAME doesn't exist but
-       contains a first-level label beginning with an underscore could
-       be handled using the normal DNSSEC protocol.
-
-       This approach would make it possible to enumerate all DNS names
-       in the zone containing a first-level label beginning with
-       underscore, including all SRV RRs, but this may be of less a
-       concern to the zone administrator than incurring the overhead of
-       the absolute method or of the following variants of the modified
-       method.
-
-   2.  The absolute method could be used for synthesising NSEC RRs for
-       all queries where the QNAME contains a leading underscore.
-       However this re-introduces the susceptibility of the absolute
-       method to denial of service activity, as an attacker could send
-       queries for an effectively inexhaustible supply of domain names
-       beginning with a leading underscore.
-
-   3.  A variant of the modified method could be used for synthesising
-       NSEC RRs for all queries where the QNAME contains a leading
-       underscore.  This variant would assume that all predecessors and
-       successors to queries where the QNAME contains a leading
-       underscore may consist of two lablels rather than only one.  This
-       introduces a little additional complexity without incurring the
-       full increase in response size and computational complexity as
-       the absolute method.
-
-   4.  Finally, a variant the modified method which assumes that all
-       owner names in the zone consist of one or two labels could be
-       used.  However this negates much of the reduction in response
-       size of the modified method and may be nearly as computationally
-       complex as the absolute method.
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006                [Page 9]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-6.  Examples
-
-   In the following examples:
-
-      the owner name of the zone apex is "example.com.";
-
-      the range of octet values is 0x00 - 0xff excluding values
-      corresponding to uppercase US-ASCII letters; and
-
-      non-printable octet values are expressed as three-digit decimal
-      numbers preceded by a backslash (as specified in Section 5.1 of
-      [RFC1035]).
-
-6.1.  Examples of Immediate Predecessors Using Absolute Method
-
-   Example of typical case:
-
-      P(foo.example.com.) =
-
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255.\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255.\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255.fon\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255.example.com.
-
-      or, in alternate notation:
-
-           \255{49}.\255{63}.\255{63}.fon\255{60}.example.com.
-
-      where {n} represents the number of repetitions of an octet.
-
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 10]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   Example where least significant (left-most) label of DNS name
-   consists of a single octet of the minimum sort value:
-
-      P(\000.foo.example.com.) = foo.example.com.
-
-   Example where least significant (right-most) octet of least
-   significant (left-most) label has the minimum sort value:
-
-      P(foo\000.example.com.) =
-
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255.\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255.\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255.\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255.foo.example.com.
-
-      or, in alternate notation:
-
-           \255{45}.\255{63}.\255{63}.\255{63}.foo.example.com.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 11]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   Example where DNS name contains an octet which must be decremented by
-   skipping values corresponding to US-ASCII uppercase letters:
-
-      P(fo\[.example.com.) =
-
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255.\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255.\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255.fo\@\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255.example.com.
-
-      or, in alternate notation:
-
-           \255{49}.\255{63}.\255{63}.fo\@\255{60}.example.com.
-
-      where {n} represents the number of repetitions of an octet.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 12]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   Example where DNS name is the owner name of the zone apex, and
-   consequently wraps to the DNS name with the maximum possible sort
-   order in the zone:
-
-      P(example.com.) =
-
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255.\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255.\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255.\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255.example.com.
-
-      or, in alternate notation:
-
-           \255{49}.\255{63}.\255{63}.\255{63}.example.com.
-
-6.2.  Examples of Immediate Successors Using Absolute Method
-
-   Example of typical case:
-
-      S(foo.example.com.) = \000.foo.example.com.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 13]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   Example where DNS name is one octet short of the maximum DNS name
-   length:
-
-      N =  fooooooooooooooooooooooooooooooooooooooooooooooo
-           .ooooooooooooooooooooooooooooooooooooooooooooooo
-           oooooooooooooooo.ooooooooooooooooooooooooooooooo
-           oooooooooooooooooooooooooooooooo.ooooooooooooooo
-           oooooooooooooooooooooooooooooooooooooooooooooooo.example.com.
-
-      or, in alternate notation:
-
-           fo{47}.o{63}.o{63}.o{63}.example.com.
-
-      S(N) =
-
-           fooooooooooooooooooooooooooooooooooooooooooooooo
-           \000.ooooooooooooooooooooooooooooooooooooooooooo
-           oooooooooooooooooooo.ooooooooooooooooooooooooooo
-           oooooooooooooooooooooooooooooooooooo.ooooooooooo
-           oooooooooooooooooooooooooooooooooooooooooooooooo
-           oooo.example.com.
-
-      or, in alternate notation:
-
-           fo{47}\000.o{63}.o{63}.o{63}.example.com.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 14]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   Example where DNS name is the maximum DNS name length:
-
-      N  = fooooooooooooooooooooooooooooooooooooooooooooooo
-           o.oooooooooooooooooooooooooooooooooooooooooooooo
-           ooooooooooooooooo.oooooooooooooooooooooooooooooo
-           ooooooooooooooooooooooooooooooooo.oooooooooooooo
-           oooooooooooooooooooooooooooooooooooooooooooooooo
-           o.example.com.
-
-      or, in alternate notation:
-
-           fo{48}.o{63}.o{63}.o{63}.example.com.
-
-      S(N) =
-
-           fooooooooooooooooooooooooooooooooooooooooooooooo
-           p.oooooooooooooooooooooooooooooooooooooooooooooo
-           ooooooooooooooooo.oooooooooooooooooooooooooooooo
-           ooooooooooooooooooooooooooooooooo.oooooooooooooo
-           oooooooooooooooooooooooooooooooooooooooooooooooo
-           o.example.com.
-
-      or, in alternate notation:
-
-           fo{47}p.o{63}.o{63}.o{63}.example.com.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 15]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   Example where DNS name is the maximum DNS name length and the least
-   significant (left-most) label has the maximum sort value:
-
-      N =  \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255.ooooooooooooooooooooooooooooooooooooooooooo
-           oooooooooooooooooooo.ooooooooooooooooooooooooooo
-           oooooooooooooooooooooooooooooooooooo.ooooooooooo
-           oooooooooooooooooooooooooooooooooooooooooooooooo
-           oooo.example.com.
-
-      or, in alternate notation:
-
-           \255{49}.o{63}.o{63}.o{63}.example.com.
-
-      S(N) =
-
-           oooooooooooooooooooooooooooooooooooooooooooooooo
-           oooooooooooooop.oooooooooooooooooooooooooooooooo
-           ooooooooooooooooooooooooooooooo.oooooooooooooooo
-           ooooooooooooooooooooooooooooooooooooooooooooooo.
-           example.com.
-
-      or, in alternate notation:
-
-           o{62}p.o{63}.o{63}.example.com.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 16]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   Example where DNS name is the maximum DNS name length and the eight
-   least significant (right-most) octets of the least significant (left-
-   most) label have the maximum sort value:
-
-      N  = foooooooooooooooooooooooooooooooooooooooo\255
-           \255\255\255\255\255\255\255.ooooooooooooooooooo
-           oooooooooooooooooooooooooooooooooooooooooooo.ooo
-           oooooooooooooooooooooooooooooooooooooooooooooooo
-           oooooooooooo.ooooooooooooooooooooooooooooooooooo
-           oooooooooooooooooooooooooooo.example.com.
-
-      or, in alternate notation:
-
-           fo{40}\255{8}.o{63}.o{63}.o{63}.example.com.
-
-      S(N) =
-
-           fooooooooooooooooooooooooooooooooooooooop.oooooo
-           oooooooooooooooooooooooooooooooooooooooooooooooo
-           ooooooooo.oooooooooooooooooooooooooooooooooooooo
-           ooooooooooooooooooooooooo.oooooooooooooooooooooo
-           ooooooooooooooooooooooooooooooooooooooooo.example.com.
-
-      or, in alternate notation:
-
-           fo{39}p.o{63}.o{63}.o{63}.example.com.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 17]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   Example where DNS name is the maximum DNS name length and contains an
-   octet which must be incremented by skipping values corresponding to
-   US-ASCII uppercase letters:
-
-      N  = fooooooooooooooooooooooooooooooooooooooooooooooo
-           \@.ooooooooooooooooooooooooooooooooooooooooooooo
-           oooooooooooooooooo.ooooooooooooooooooooooooooooo
-           oooooooooooooooooooooooooooooooooo.ooooooooooooo
-           oooooooooooooooooooooooooooooooooooooooooooooooo
-           oo.example.com.
-
-      or, in alternate notation:
-
-           fo{47}\@.o{63}.o{63}.o{63}.example.com.
-
-      S(N) =
-
-           fooooooooooooooooooooooooooooooooooooooooooooooo
-           \[.ooooooooooooooooooooooooooooooooooooooooooooo
-           oooooooooooooooooo.ooooooooooooooooooooooooooooo
-           oooooooooooooooooooooooooooooooooo.ooooooooooooo
-           oooooooooooooooooooooooooooooooooooooooooooooooo
-           oo.example.com.
-
-      or, in alternate notation:
-
-           fo{47}\[.o{63}.o{63}.o{63}.example.com.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 18]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   Example where DNS name has the maximum possible sort order in the
-   zone, and consequently wraps to the owner name of the zone apex:
-
-      N  = \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255.\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255.\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255.\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255.example.com.
-
-      or, in alternate notation:
-
-           \255{49}.\255{63}.\255{63}.\255{63}.example.com.
-
-      S(N) = example.com.
-
-6.3.  Examples of Predecessors Using Modified Method
-
-   Example of typical case:
-
-      P'(foo.example.com.) =
-
-           fon\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255.example.com.
-
-      or, in alternate notation:
-
-           fon\255{60}.example.com.
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 19]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   Example where DNS name contains more labels than DNS names in the
-   zone:
-
-      P'(bar.foo.example.com.) = foo.example.com.
-
-   Example where least significant (right-most) octet of least
-   significant (left-most) label has the minimum sort value:
-
-      P'(foo\000.example.com.) = foo.example.com.
-
-   Example where least significant (left-most) label has the minimum
-   sort value:
-
-      P'(\000.example.com.) = example.com.
-
-   Example where DNS name is the owner name of the zone apex, and
-   consequently wraps to the DNS name with the maximum possible sort
-   order in the zone:
-
-      P'(example.com.) =
-
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255.example.com.
-
-      or, in alternate notation:
-
-           \255{63}.example.com.
-
-6.4.  Examples of Successors Using Modified Method
-
-   Example of typical case:
-
-      S'(foo.example.com.) = foo\000.example.com.
-
-   Example where DNS name contains more labels than DNS names in the
-   zone:
-
-      S'(bar.foo.example.com.) = foo\000.example.com.
-
-
-
-
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 20]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   Example where least significant (left-most) label has the maximum
-   sort value, and consequently wraps to the owner name of the zone
-   apex:
-
-      N  = \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255.example.com.
-
-      or, in alternate notation:
-
-           \255{63}.example.com.
-
-      S'(N) = example.com.
-
-
-7.  Security Considerations
-
-   The derivation of some predecessors/successors requires the testing
-   of more conditions than others.  Consequently the effectiveness of a
-   denial-of-service attack may be enhanced by sending queries that
-   require more conditions to be tested.  The modified method involves
-   the testing of fewer conditions than the absolute method and
-   consequently is somewhat less susceptible to this exposure.
-
-
-8.  IANA Considerations
-
-   This document has no IANA actions.
-
-   Note to RFC Editor: This section is included to make it clear during
-   pre-publication review that this document has no IANA actions.  It
-   may therefore be removed should it be published as an RFC.
-
-
-9.  Acknowledgments
-
-   The authors would like to thank Olaf Kolkman, Olafur Gudmundsson and
-   Niall O'Reilly for their review and input.
-
-
-10.  References
-
-
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 21]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-10.1  Normative References
-
-   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
-              STD 13, RFC 1034, November 1987.
-
-   [RFC1035]  Mockapetris, P., "Domain names - implementation and
-              specification", STD 13, RFC 1035, November 1987.
-
-   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
-              Specification", RFC 2181, July 1997.
-
-   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
-              specifying the location of services (DNS SRV)", RFC 2782,
-              February 2000.
-
-   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Resource Records for the DNS Security Extensions",
-              RFC 4034, March 2005.
-
-10.2  Informative References
-
-   [I-D.ietf-dnsext-dnssec-online-signing]
-              Ihren, J. and S. Weiler, "Minimally Covering NSEC Records
-              and DNSSEC On-line Signing",
-              draft-ietf-dnsext-dnssec-online-signing-00 (work in
-              progress), May 2005.
-
-   [I-D.ietf-dnsext-dnssec-trans]
-              Arends, R., Koch, P., and J. Schlyter, "Evaluating DNSSEC
-              Transition Mechanisms",
-              draft-ietf-dnsext-dnssec-trans-02 (work in progress),
-              February 2005.
-
-
-Appendix A.  Change History
-
-A.1.  Changes from sisson-02 to ietf-00
-
-   o  Added notes on use of SRV RRs with modified method.
-
-   o  Changed reference from weiler-dnssec-online-signing to ietf-
-      dnsext-dnssec-online-signing.
-
-   o  Changed reference from ietf-dnsext-dnssec-records to RFC 4034.
-
-   o  Miscellaneous minor changes to text.
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 22]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-A.2.  Changes from sisson-01 to sisson-02
-
-   o  Added modified version of derivation (with supporting examples).
-
-   o  Introduced notational conventions N, P(N), S(N), P'(N) and S'(N).
-
-   o  Added clarification to derivations about when processing stops.
-
-   o  Miscellaneous minor changes to text.
-
-A.3.  Changes from sisson-00 to sisson-01
-
-   o  Split step 3 of derivation of DNS name predecessor into two
-      distinct steps for clarity.
-
-   o  Added clarifying text and examples related to the requirement to
-      avoid uppercase characters when decrementing or incrementing
-      octets.
-
-   o  Added optimisation using restriction of effective maximum DNS name
-      length.
-
-   o  Changed examples to use decimal rather than octal notation as per
-      [RFC1035].
-
-   o  Corrected DNS name length of some examples.
-
-   o  Added reference to weiler-dnssec-online-signing.
-
-   o  Miscellaneous minor changes to text.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 23]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-Authors' Addresses
-
-   Geoffrey Sisson
-   Nominet
-   Sandford Gate
-   Sandy Lane West
-   Oxford
-   OX4 6LB
-   GB
-
-   Phone: +44 1865 332339
-   Email: geoff@nominet.org.uk
-
-
-   Ben Laurie
-   Nominet
-   17 Perryn Road
-   London
-   W3 7LR
-   GB
-
-   Phone: +44 20 8735 0686
-   Email: ben@algroup.co.uk
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 24]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 25]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt
deleted file mode 100644
index bcc2b4e..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt
+++ /dev/null
@@ -1,442 +0,0 @@
-
-
-INTERNET-DRAFT                                             Samuel Weiler
-Expires: June 2004                                     December 15, 2003
-Updates: RFC 2535, [DS]
-
-	 Legacy Resolver Compatibility for Delegation Signer
-	 draft-ietf-dnsext-dnssec-2535typecode-change-06.txt
-
-Status of this Memo
-
-   This document is an Internet-Draft and is subject to all provisions
-   of Section 10 of RFC2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as
-   Internet-Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six
-   months and may be updated, replaced, or obsoleted by other
-   documents at any time.  It is inappropriate to use Internet-Drafts
-   as reference material or to cite them other than as "work in
-   progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/1id-abstracts.html
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-   Comments should be sent to the author or to the DNSEXT WG mailing
-   list: namedroppers@ops.ietf.org
-
-Abstract
-
-   As the DNS Security (DNSSEC) specifications have evolved, the
-   syntax and semantics of the DNSSEC resource records (RRs) have
-   changed.  Many deployed nameservers understand variants of these
-   semantics.  Dangerous interactions can occur when a resolver that
-   understands an earlier version of these semantics queries an
-   authoritative server that understands the new delegation signer
-   semantics, including at least one failure scenario that will cause
-   an unsecured zone to be unresolvable.  This document changes the
-   type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) to
-   avoid those interactions.
-
-Changes between 05 and 06:
-
-   Signifigantly reworked the IANA section -- went back to one
-   algorithm registry.
-
-   Removed Diffie-Hellman from the list of zone-signing algorithms
-   (leaving only DSA, RSA/SHA-1, and private algorithms).
-
-   Added a DNSKEY flags field registry.
-
-Changes between 04 and 05:
-
-   IESG approved publication.
-
-   Cleaned up an internal reference in the acknowledgements section.
-
-   Retained KEY and SIG for TKEY, too.  Added TKEY (2930) reference.
-
-   Changed the names of both new registries.  Added algorithm
-   mnemonics to the new zone signing algorithm registry.  Minor
-   rewording in the IANA section for clarity.
-
-   Cleaned up formatting of references.  Replaced unknown-rr draft
-   references with RFC3597.  Bumped DS version number.
-
-Changes between 03 and 04:
-
-   Clarified that RRSIG(0) may be defined by standards action.
-
-   Created a new algorithm registry and renamed the old algorithm
-   registry for SIG(0) only.  Added references to the appropriate
-   crypto algorithm and format specifications.
-
-   Several minor rephrasings.
-
-Changes between 02 and 03:
-
-   KEY (as well as SIG) retained for SIG(0) use only.
-
-Changes between 01 and 02:
-
-   SIG(0) still uses SIG, not RRSIG.  Added 2931 reference.
-
-   Domain names embedded in NSECs and RRSIGs are not compressible and
-   are not downcased.  Added unknown-rrs reference (as informative).
-
-   Simplified the last paragraph of section 3 (NSEC doesn't always
-   signal a negative answer).
-
-   Changed the suggested type code assignments.
-
-   Added 2119 reference.
-
-   Added definitions of "unsecure delegation" and "unsecure referral",
-   since they're not clearly defined elsewhere.
-
-   Moved 2065 to informative references, not normative.
-
-1. Introduction
-
-   The DNSSEC protocol has been through many iterations whose syntax
-   and semantics are not completely compatible.  This has occurred as
-   part of the ordinary process of proposing a protocol, implementing
-   it, testing it in the increasingly complex and diverse environment
-   of the Internet, and refining the definitions of the initial
-   Proposed Standard.  In the case of DNSSEC, the process has been
-   complicated by DNS's criticality and wide deployment and the need
-   to add security while minimizing daily operational complexity.
-
-   A weak area for previous DNS specifications has been lack of detail
-   in specifying resolver behavior, leaving implementors largely on
-   their own to determine many details of resolver function.  This,
-   combined with the number of iterations the DNSSEC spec has been
-   through, has resulted in fielded code with a wide variety of
-   behaviors.  This variety makes it difficult to predict how a
-   protocol change will be handled by all deployed resolvers.  The
-   risk that a change will cause unacceptable or even catastrophic
-   failures makes it difficult to design and deploy a protocol change.
-   One strategy for managing that risk is to structure protocol
-   changes so that existing resolvers can completely ignore input that
-   might confuse them or trigger undesirable failure modes.
-
-   This document addresses a specific problem caused by Delegation
-   Signer's [DS] introduction of new semantics for the NXT RR that are
-   incompatible with the semantics in RFC 2535 [RFC2535].  Answers
-   provided by DS-aware servers can trigger an unacceptable failure
-   mode in some resolvers that implement RFC 2535, which provides a
-   great disincentive to sign zones with DS.  The changes defined in
-   this document allow for the incremental deployment of DS.
-
-1.1 Terminology
-
-   In this document, the term "unsecure delegation" means any
-   delegation for which no DS record appears at the parent.  An
-   "unsecure referral" is an answer from the parent containing an NS
-   RRset and a proof that no DS record exists for that name.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-1.2 The Problem
-
-   Delegation Signer introduces new semantics for the NXT RR that are
-   incompatible with the semantics in RFC 2535.  In RFC 2535, NXT
-   records were only required to be returned as part of a
-   non-existence proof.  With DS, an unsecure referral returns, in
-   addition to the NS, a proof of non-existence of a DS RR in the form
-   of an NXT and SIG(NXT).  RFC 2535 didn't specify how a resolver was
-   to interpret a response with both an NS and an NXT in the authority
-   section, RCODE=0, and AA=0.  Some widely deployed 2535-aware
-   resolvers interpret any answer with an NXT as a proof of
-   non-existence of the requested record.  This results in unsecure
-   delegations being invisible to 2535-aware resolvers and violates
-   the basic architectural principle that DNSSEC must do no harm --
-   the signing of zones must not prevent the resolution of unsecured
-   delegations.
-
-2. Possible Solutions
-
-   This section presents several solutions that were considered.
-   Section 3 describes the one selected.
-
-2.1. Change SIG, KEY, and NXT type codes
-
-   To avoid the problem described above, legacy (RFC2535-aware)
-   resolvers need to be kept from seeing unsecure referrals that
-   include NXT records in the authority section.  The simplest way to
-   do that is to change the type codes for SIG, KEY, and NXT.
-
-   The obvious drawback to this is that new resolvers will not be able
-   to validate zones signed with the old RRs.  This problem already
-   exists, however, because of the changes made by DS, and resolvers
-   that understand the old RRs (and have compatibility issues with DS)
-   are far more prevalent than 2535-signed zones.
-
-2.2. Change a subset of type codes
-
-   The observed problem with unsecure referrals could be addressed by
-   changing only the NXT type code or another subset of the type codes
-   that includes NXT.  This has the virtue of apparent simplicity, but
-   it risks introducing new problems or not going far enough.  It's
-   quite possible that more incompatibilities exist between DS and
-   earlier semantics.  Legacy resolvers may also be confused by seeing
-   records they recognize (SIG and KEY) while being unable to find
-   NXTs.  Although it may seem unnecessary to fix that which is not
-   obviously broken, it's far cleaner to change all of the type codes
-   at once.  This will leave legacy resolvers and tools completely
-   blinded to DNSSEC -- they will see only unknown RRs.
-
-2.3. Replace the DO bit
-
-   Another way to keep legacy resolvers from ever seeing DNSSEC
-   records with DS semantics is to have authoritative servers only
-   send that data to DS-aware resolvers.  It's been proposed that
-   assigning a new EDNS0 flag bit to signal DS-awareness (tentatively
-   called "DA"), and having authoritative servers send DNSSEC data
-   only in response to queries with the DA bit set, would accomplish
-   this.  This bit would presumably supplant the DO bit described in
-   RFC 3225.
-
-   This solution is sufficient only if all 2535-aware resolvers zero
-   out EDNS0 flags that they don't understand.  If one passed through
-   the DA bit unchanged, it would still see the new semantics, and it
-   would probably fail to see unsecure delegations.  Since it's
-   impractical to know how every DNS implementation handles unknown
-   EDNS0 flags, this is not a universal solution.  It could, though,
-   be considered in addition to changing the RR type codes.
-
-2.4. Increment the EDNS version
-
-   Another possible solution is to increment the EDNS version number
-   as defined in RFC 2671 [RFC2671], on the assumption that all
-   existing implementations will reject higher versions than they
-   support, and retain the DO bit as the signal for DNSSEC awareness.
-   This approach has not been tested.
-
-2.5. Do nothing
-
-   There is a large deployed base of DNS resolvers that understand
-   DNSSEC as defined by the standards track RFC 2535 and RFC 2065
-   and, due to under specification in those documents, interpret any
-   answer with an NXT as a non-existence proof.  So long as that is
-   the case, zone owners will have a strong incentive to not sign any
-   zones that contain unsecure delegations, lest those delegations be
-   invisible to such a large installed base.  This will dramatically
-   slow DNSSEC adoption.
-
-   Unfortunately, without signed zones there's no clear incentive for
-   operators of resolvers to upgrade their software to support the new
-   version of DNSSEC, as defined in [DS].  Historical data suggests
-   that resolvers are rarely upgraded, and that old nameserver code
-   never dies.
-
-   Rather than wait years for resolvers to be upgraded through natural
-   processes before signing zones with unsecure delegations,
-   addressing this problem with a protocol change will immediately
-   remove the disincentive for signing zones and allow widespread
-   deployment of DNSSEC.
-
-3. Protocol changes
-
-   This document changes the type codes of SIG, KEY, and NXT.  This
-   approach is the cleanest and safest of those discussed above,
-   largely because the behavior of resolvers that receive unknown type
-   codes is well understood.  This approach has also received the most
-   testing.
-
-   To avoid operational confusion, it's also necessary to change the
-   mnemonics for these RRs.  DNSKEY will be the replacement for KEY,
-   with the mnemonic indicating that these keys are not for
-   application use, per [RFC3445].  RRSIG (Resource Record SIGnature)
-   will replace SIG, and NSEC (Next SECure) will replace NXT.  These
-   new types completely replace the old types, except that SIG(0)
-   [RFC2931] and TKEY [RFC2930] will continue to use SIG and KEY.
-
-   The new types will have exactly the same syntax and semantics as
-   specified for SIG, KEY, and NXT in RFC 2535 and [DS] except for
-   the following:
-
-      1) Consistent with [RFC3597], domain names embedded in
-      RRSIG and NSEC RRs MUST NOT be compressed,
-
-      2) Embedded domain names in RRSIG and NSEC RRs are not downcased
-      for purposes of DNSSEC canonical form and ordering nor for
-      equality comparison, and
-
-      3) An RRSIG with a type-covered field of zero has undefined
-      semantics.  The meaning of such a resource record may only be
-      defined by IETF Standards Action.
-
-   If a resolver receives the old types, it SHOULD treat them as
-   unknown RRs and SHOULD NOT assign any special meaning to them or
-   give them any special treatment.  It MUST NOT use them for DNSSEC
-   validations or other DNS operational decision making.  For example,
-   a resolver MUST NOT use DNSKEYs to validate SIGs or use KEYs to
-   validate RRSIGs.  If SIG, KEY, or NXT RRs are included in a zone,
-   they MUST NOT receive special treatment.  As an example, if a SIG
-   is included in a signed zone, there MUST be an RRSIG for it.
-   Authoritative servers may wish to give error messages when loading
-   zones containing SIG or NXT records (KEY records may be included
-   for SIG(0) or TKEY).
-
-   As a clarification to previous documents, some positive responses,
-   particularly wildcard proofs and unsecure referrals, will contain
-   NSEC RRs.  Resolvers MUST NOT treat answers with NSEC RRs as
-   negative answers merely because they contain an NSEC.
-
-4. IANA Considerations
-
-4.1 DNS Resource Record Types
-
-   This document updates the IANA registry for DNS Resource Record
-   Types by assigning types 46, 47, and 48 to the RRSIG, NSEC, and
-   DNSKEY RRs, respectively.
-
-   Types 24 and 25 (SIG and KEY) are retained for SIG(0) [RFC2931] and
-   TKEY [RFC2930] use only.
-
-   Type 30 (NXT) should be marked as Obsolete.
-
-4.2 DNS Security Algorithm Numbers
-
-   To allow zone signing (DNSSEC) and transaction security mechanisms
-   (SIG(0) and TKEY) to use different sets of algorithms, the existing
-   "DNS Security Algorithm Numbers" registry is modified to include
-   the applicability of each algorithm.  Specifically, two new columns
-   are added to the registry, showing whether each algorithm may be
-   used for zone signing, transaction security mechanisms, or both.
-   Only algorithms usable for zone signing may be used in DNSKEY,
-   RRSIG, and DS RRs.  Only algorithms usable for SIG(0) and/or TSIG
-   may be used in SIG and KEY RRs.
-
-   All currently defined algorithms remain usable for transaction
-   security mechanisms.  Only RSA/SHA-1, DSA/SHA-1, and private
-   algorithms (types 253 and 254) may be used for zone signing.  Note
-   that the registry does not contain the requirement level of each
-   algorithm, only whether or not an algorithm may be used for the
-   given purposes.  For example, RSA/MD5, while allowed for
-   transaction security mechanisms, is NOT RECOMMENDED, per RFC3110.
-
-   Additionally, the presentation format algorithm mnemonics from
-   RFC2535 Section 7 are added to the registry.  This document assigns
-   RSA/SHA-1 the mnemonic RSASHA1.
-
-   As before, assignment of new algorithms in this registry requires
-   IETF Standards Action.  Additionally, modification of algorithm
-   mnemonics or applicability requires IETF Standards Action.
-   Documents defining a new algorithm must address the applicability
-   of the algorithm and should assign a presentation mnemonic to the
-   algorithm.
-
-4.3 DNSKEY Flags
-
-   Like the KEY resource record, DNSKEY contains a 16-bit flags field.
-   This document creates a new registry for the DNSKEY flags field.
-
-   Initially, this registry only contains an assignment for bit 7 (the
-   ZONE bit).  Bits 0-6 and 8-15 are available for assignment by IETF
-   Standards Action.
-
-4.4 DNSKEY Protocol Octet
-
-   Like the KEY resource record, DNSKEY contains an eight bit protocol
-   field.  The only defined value for this field is 3 (DNSSEC).  No
-   other values are allowed, hence no IANA registry is needed for this
-   field.
-
-5. Security Considerations
-
-   The changes introduced here do not materially affect security.
-   The implications of trying to use both new and legacy types
-   together are not well understood, and attempts to do so would
-   probably lead to unintended and dangerous results.
-
-   Changing type codes will leave code paths in legacy resolvers that
-   are never exercised.  Unexercised code paths are a frequent source
-   of security holes, largely because those code paths do not get
-   frequent scrutiny.
-
-   Doing nothing, as described in section 2.5, will slow DNSSEC
-   deployment.  While this does not decrease security, it also fails
-   to increase it.
-
-6. Normative references
-
-   [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
-             RFC 2535, March 1999.
-
-   [DS]      Gudmundsson, O., "Delegation Signer Resource Record",
-             draft-ietf-dnsext-delegation-signer-15.txt, work in
-             progress, June 2003.
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
-             (SIG(0)s)", RFC 2931, September 2000.
-
-   [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
-             RR)", RFC 2930, September 2000.
-
-   [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name
-             System (DNS)", RFC 2436, March 1999.
-
-   [RFC2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the
-             Domain Name System (DNS)", RFC 2539, March 1999.
-
-   [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the
-             Domain Name System (DNS)", RFC 3110, May 2001.
-
-7. Informative References
-
-   [RFC2065] Eastlake, D. and C. Kaufman, "Domain Name System Security
-             Extensions", RFC 2065, January 1997.
-
-   [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
-	     2671, August 1999.
-
-   [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
-             3225, December 2001.
-
-   [RFC2929] Eastlake, D., E. Brunner-Williams, and B. Manning,
-	     "Domain Name System (DNS) IANA Considerations", BCP 42,
-	     RFC 2929, September 2000.
-
-   [RFC3445] Massey, D., and S. Rose, "Limiting the Scope of the KEY
-	     Resource Record (RR)", RFC 3445, December 2002.
-
-   [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource
-             Record (RR) Types", RFC 3597, September 2003.
-
-8. Acknowledgments
-
-   The changes introduced here and the analysis of alternatives had
-   many contributors.  With apologies to anyone overlooked, those
-   include: Micheal Graff, John Ihren, Olaf Kolkman, Mark Kosters, Ed
-   Lewis, Bill Manning, and Suzanne Woolf.
-
-   Thanks to Jakob Schlyter and Mark Andrews for identifying the
-   incompatibility described in section 1.2.
-
-   In addition to the above, the author would like to thank Scott
-   Rose, Olafur Gudmundsson, and Sandra Murphy for their substantive
-   comments.
-
-9. Author's Address
-
-   Samuel Weiler
-   SPARTA, Inc.
-   7075 Samuel Morse Drive
-   Columbia, MD 21046
-   USA
-   weiler@tislabs.com
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt
deleted file mode 100644
index 3a800f9..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt
+++ /dev/null
@@ -1,616 +0,0 @@
-
-
-
-Network Working Group                                          S. Weiler
-Internet-Draft                                               SPARTA, Inc
-Updates: 4034, 4035 (if approved)                           May 23, 2005
-Expires: November 24, 2005
-
-
-         Clarifications and Implementation Notes for DNSSECbis
-                draft-ietf-dnsext-dnssec-bis-updates-01
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on November 24, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document is a collection of minor technical clarifications to
-   the DNSSECbis document set.  It is meant to serve as a resource to
-   implementors as well as an interim repository of possible DNSSECbis
-   errata.
-
-
-
-
-
-
-
-Weiler                  Expires November 24, 2005               [Page 1]
-
-Internet-Draft       DNSSECbis Implementation Notes             May 2005
-
-
-Proposed additions in future versions
-
-   An index sorted by the section of DNSSECbis being clarified.
-
-   A list of proposed protocol changes being made in other documents,
-   such as NSEC3 and Epsilon.  This document would not make those
-   changes, merely provide an index into the documents that are making
-   changes.
-
-Changes between -00 and -01
-
-   Document significantly restructured.
-
-   Added section on QTYPE=ANY.
-
-Changes between personal submission and first WG draft
-
-   Added Section 2.1 based on namedroppers discussions from March 9-10,
-   2005.
-
-   Added Section 3.4, Section 3.3, Section 4.3, and Section 2.2.
-
-   Added the DNSSECbis RFC numbers.
-
-   Figured out the confusion in Section 4.1.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler                  Expires November 24, 2005               [Page 2]
-
-Internet-Draft       DNSSECbis Implementation Notes             May 2005
-
-
-Table of Contents
-
-   1.  Introduction and Terminology . . . . . . . . . . . . . . . . .  4
-     1.1   Structure of this Document . . . . . . . . . . . . . . . .  4
-     1.2   Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
-   2.  Significant Concerns . . . . . . . . . . . . . . . . . . . . .  4
-     2.1   Clarifications on Non-Existence Proofs . . . . . . . . . .  4
-     2.2   Empty Non-Terminal Proofs  . . . . . . . . . . . . . . . .  5
-     2.3   Validating Responses to an ANY Query . . . . . . . . . . .  5
-   3.  Interoperability Concerns  . . . . . . . . . . . . . . . . . .  5
-     3.1   Unknown DS Message Digest Algorithms . . . . . . . . . . .  5
-     3.2   Private Algorithms . . . . . . . . . . . . . . . . . . . .  6
-     3.3   Caution About Local Policy and Multiple RRSIGs . . . . . .  6
-     3.4   Key Tag Calculation  . . . . . . . . . . . . . . . . . . .  7
-   4.  Minor Corrections and Clarifications . . . . . . . . . . . . .  7
-     4.1   Finding Zone Cuts  . . . . . . . . . . . . . . . . . . . .  7
-     4.2   Clarifications on DNSKEY Usage . . . . . . . . . . . . . .  7
-     4.3   Errors in Examples . . . . . . . . . . . . . . . . . . . .  8
-   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
-   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
-   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
-     7.1   Normative References . . . . . . . . . . . . . . . . . . .  8
-     7.2   Informative References . . . . . . . . . . . . . . . . . .  9
-       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  9
-   A.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  9
-       Intellectual Property and Copyright Statements . . . . . . . . 11
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler                  Expires November 24, 2005               [Page 3]
-
-Internet-Draft       DNSSECbis Implementation Notes             May 2005
-
-
-1.  Introduction and Terminology
-
-   This document lists some minor clarifications and corrections to
-   DNSSECbis, as described in [1], [2], and [3].
-
-   It is intended to serve as a resource for implementors and as a
-   repository of items that need to be addressed when advancing the
-   DNSSECbis documents from Proposed Standard to Draft Standard.
-
-   In this version (-01 of the WG document), feedback is particularly
-   solicited on the structure of the document and whether the text in
-   the recently added sections is correct and sufficient.
-
-   Proposed substantive additions to this document should be sent to the
-   namedroppers mailing list as well as to the editor of this document.
-   The editor would greatly prefer text suitable for direct inclusion in
-   this document.
-
-1.1  Structure of this Document
-
-   The clarifications to DNSSECbis are sorted according to the editor's
-   impression of their importance, starting with ones which could, if
-   ignored, lead to security and stability problems and progressing down
-   to clarifications that are likely to have little operational impact.
-   Mere typos and awkward phrasings are not addressed unless they could
-   lead to misinterpretation of the DNSSECbis documents.
-
-1.2  Terminology
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [4].
-
-2.  Significant Concerns
-
-   This section provides clarifications that, if overlooked, could lead
-   to security issues or major interoperability problems.
-
-2.1  Clarifications on Non-Existence Proofs
-
-   RFC4035 Section 5.4 slightly underspecifies the algorithm for
-   checking non-existence proofs.  In particular, the algorithm there
-   might incorrectly allow the NSEC from the parent side of a zone cut
-   to prove the non-existence of either other RRs at that name in the
-   child zone or other names in the child zone.  It might also allow a
-   NSEC at the same name as a DNAME to prove the non-existence of names
-   beneath that DNAME.
-
-
-
-
-Weiler                  Expires November 24, 2005               [Page 4]
-
-Internet-Draft       DNSSECbis Implementation Notes             May 2005
-
-
-   A parent-side delegation NSEC (one with the NS bit set, but no SOA
-   bit set, and with a singer field that's shorter than the owner name)
-   must not be used to assume non-existence of any RRs below that zone
-   cut (both RRs at that ownername and at ownernames with more leading
-   labels, no matter their content).  Similarly, an NSEC with the DNAME
-   bit set must not be used to assume the non-existence of any
-   descendant of that NSEC's owner name.
-
-2.2  Empty Non-Terminal Proofs
-
-   To be written, based on Roy Arends' May 11th message to namedroppers.
-
-2.3  Validating Responses to an ANY Query
-
-   RFC4035 does not address now to validate responses when QTYPE=*.  As
-   described in Section 6.2.2 of RFC1034, a proper response to QTYPE=*
-   may include a subset of the RRsets at a given name -- it is not
-   necessary to include all RRsets at the QNAME in the response.
-
-   When validating a response to QTYPE=*, validate all received RRsets
-   that match QNAME and QCLASS.  If any of those RRsets fail validation,
-   treat the answer as Bogus.  If there are no RRsets matching QNAME and
-   QCLASS, validate that fact using the rules in RFC4035 Section 5.4 (as
-   clarified in this document).  To be clear, a validator must not
-   insist on receiving all records at the QNAME in response to QTYPE=*.
-
-3.  Interoperability Concerns
-
-3.1  Unknown DS Message Digest Algorithms
-
-   Section 5.2 of RFC4035 includes rules for how to handle delegations
-   to zones that are signed with entirely unsupported algorithms, as
-   indicated by the algorithms shown in those zone's DS RRsets.  It does
-   not explicitly address how to handle DS records that use unsupported
-   message digest algorithms.  In brief, DS records using unknown or
-   unsupported message digest algorithms MUST be treated the same way as
-   DS records referring to DNSKEY RRs of unknown or unsupported
-   algorithms.
-
-   The existing text says:
-
-      If the validator does not support any of the algorithms listed
-      in an authenticated DS RRset, then the resolver has no supported
-      authentication path leading from the parent to the child.  The
-      resolver should treat this case as it would the case of an
-      authenticated NSEC RRset proving that no DS RRset exists, as
-      described above.
-
-
-
-
-Weiler                  Expires November 24, 2005               [Page 5]
-
-Internet-Draft       DNSSECbis Implementation Notes             May 2005
-
-
-   To paraphrase the above, when determining the security status of a
-   zone, a validator discards (for this purpose only) any DS records
-   listing unknown or unsupported algorithms.  If none are left, the
-   zone is treated as if it were unsigned.
-
-   Modified to consider DS message digest algorithms, a validator also
-   discards any DS records using unknown or unsupported message digest
-   algorithms.
-
-3.2  Private Algorithms
-
-   As discussed above, section 5.2 of RFC4035 requires that validators
-   make decisions about the security status of zones based on the public
-   key algorithms shown in the DS records for those zones.  In the case
-   of private algorithms, as described in RFC4034 Appendix A.1.1, the
-   eight-bit algorithm field in the DS RR is not conclusive about what
-   algorithm(s) is actually in use.
-
-   If no private algorithms appear in the DS set or if any supported
-   algorithm appears in the DS set, no special processing will be
-   needed.  In the remaining cases, the security status of the zone
-   depends on whether or not the resolver supports any of the private
-   algorithms in use (provided that these DS records use supported hash
-   functions, as discussed in Section 3.1).  In these cases, the
-   resolver MUST retrieve the corresponding DNSKEY for each private
-   algorithm DS record and examine the public key field to determine the
-   algorithm in use.  The security-aware resolver MUST ensure that the
-   hash of the DNSKEY RR's owner name and RDATA matches the digest in
-   the DS RR.  If they do not match, and no other DS establishes that
-   the zone is secure, the referral should be considered BAD data, as
-   discussed in RFC4035.
-
-   This clarification facilitates the broader use of private algorithms,
-   as suggested by [5].
-
-3.3  Caution About Local Policy and Multiple RRSIGs
-
-   When multiple RRSIGs cover a given RRset, RFC4035 Section 5.3.3
-   suggests that "the local resolver security policy determines whether
-   the resolver also has to test these RRSIG RRs and how to resolve
-   conflicts if these RRSIG RRs lead to differing results."  In most
-   cases, a resolver would be well advised to accept any valid RRSIG as
-   sufficient.  If the first RRSIG tested fails validation, a resolver
-   would be well advised to try others, giving a successful validation
-   result if any can be validated and giving a failure only if all
-   RRSIGs fail validation.
-
-   If a resolver adopts a more restrictive policy, there's a danger that
-
-
-
-Weiler                  Expires November 24, 2005               [Page 6]
-
-Internet-Draft       DNSSECbis Implementation Notes             May 2005
-
-
-   properly-signed data might unnecessarily fail validation, perhaps
-   because of cache timing issues.  Furthermore, certain zone management
-   techniques, like the Double Signature Zone-signing Key Rollover
-   method described in section 4.2.1.2 of [6] might not work reliably.
-
-3.4  Key Tag Calculation
-
-   RFC4034 Appendix B.1 incorrectly defines the Key Tag field
-   calculation for algorithm 1.  It correctly says that the Key Tag is
-   the most significant 16 of the least significant 24 bits of the
-   public key modulus.  However, RFC4034 then goes on to incorrectly say
-   that this is 4th to last and 3rd to last octets of the public key
-   modulus.  It is, in fact, the 3rd to last and 2nd to last octets.
-
-4.  Minor Corrections and Clarifications
-
-4.1  Finding Zone Cuts
-
-   Appendix C.8 of RFC4035 discusses sending DS queries to the servers
-   for a parent zone.  To do that, a resolver may first need to apply
-   special rules to discover what those servers are.
-
-   As explained in Section 3.1.4.1 of RFC4035, security-aware name
-   servers need to apply special processing rules to handle the DS RR,
-   and in some situations the resolver may also need to apply special
-   rules to locate the name servers for the parent zone if the resolver
-   does not already have the parent's NS RRset.  Section 4.2 of RFC4035
-   specifies a mechanism for doing that.
-
-4.2  Clarifications on DNSKEY Usage
-
-   Questions of the form "can I use a different DNSKEY for signing the
-   X" have occasionally arisen.
-
-   The short answer is "yes, absolutely".  You can even use a different
-   DNSKEY for each RRset in a zone, subject only to practical limits on
-   the size of the DNSKEY RRset.  However, be aware that there is no way
-   to tell resolvers what a particularly DNSKEY is supposed to be used
-   for -- any DNSKEY in the zone's signed DNSKEY RRset may be used to
-   authenticate any RRset in the zone.  For example, if a weaker or less
-   trusted DNSKEY is being used to authenticate NSEC RRsets or all
-   dynamically updated records, that same DNSKEY can also be used to
-   sign any other RRsets from the zone.
-
-   Furthermore, note that the SEP bit setting has no effect on how a
-   DNSKEY may be used -- the validation process is specifically
-   prohibited from using that bit by RFC4034 section 2.1.2.  It possible
-   to use a DNSKEY without the SEP bit set as the sole secure entry
-
-
-
-Weiler                  Expires November 24, 2005               [Page 7]
-
-Internet-Draft       DNSSECbis Implementation Notes             May 2005
-
-
-   point to the zone, yet use a DNSKEY with the SEP bit set to sign all
-   RRsets in the zone (other than the DNSKEY RRset).  It's also possible
-   to use a single DNSKEY, with or without the SEP bit set, to sign the
-   entire zone, including the DNSKEY RRset itself.
-
-4.3  Errors in Examples
-
-   The text in RFC4035 Section C.1 refers to the examples in B.1 as
-   "x.w.example.com" while B.1 uses "x.w.example".  This is painfully
-   obvious in the second paragraph where it states that the RRSIG labels
-   field value of 3 indicates that the answer was not the result of
-   wildcard expansion.  This is true for "x.w.example" but not for
-   "x.w.example.com", which of course has a label count of 4
-   (antithetically, a label count of 3 would imply the answer was the
-   result of a wildcard expansion).
-
-   The first paragraph of RFC4035 Section C.6 also has a minor error:
-   the reference to "a.z.w.w.example" should instead be "a.z.w.example",
-   as in the previous line.
-
-5.  IANA Considerations
-
-   This document specifies no IANA Actions.
-
-6.  Security Considerations
-
-   This document does not make fundamental changes to the DNSSEC
-   protocol, as it was generally understood when DNSSECbis was
-   published.  It does, however, address some ambiguities and omissions
-   in those documents that, if not recognized and addressed in
-   implementations, could lead to security failures.  In particular, the
-   validation algorithm clarifications in Section 2 are critical for
-   preserving the security properties DNSSEC offers.  Furthermore,
-   failure to address some of the interoperability concerns in Section 3
-   could limit the ability to later change or expand DNSSEC, including
-   by adding new algorithms.
-
-7.  References
-
-7.1  Normative References
-
-   [1]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "DNS Security Introduction and Requirements", RFC 4033,
-        March 2005.
-
-   [2]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Resource Records for the DNS Security Extensions", RFC 4034,
-        March 2005.
-
-
-
-Weiler                  Expires November 24, 2005               [Page 8]
-
-Internet-Draft       DNSSECbis Implementation Notes             May 2005
-
-
-   [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Protocol Modifications for the DNS Security Extensions",
-        RFC 4035, March 2005.
-
-   [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-7.2  Informative References
-
-   [5]  Blacka, D., "DNSSEC Experiments",
-        draft-blacka-dnssec-experiments-00 (work in progress),
-        December 2004.
-
-   [6]  Gieben, R. and O. Kolkman, "DNSSEC Operational Practices",
-        draft-ietf-dnsop-dnssec-operational-practices-04 (work in
-        progress), May 2005.
-
-
-Author's Address
-
-   Samuel Weiler
-   SPARTA, Inc
-   7075 Samuel Morse Drive
-   Columbia, Maryland  21046
-   US
-
-   Email: weiler@tislabs.com
-
-Appendix A.  Acknowledgments
-
-   The editor is extremely grateful to those who, in addition to finding
-   errors and omissions in the DNSSECbis document set, have provided
-   text suitable for inclusion in this document.
-
-   The lack of specificity about handling private algorithms, as
-   described in Section 3.2, and the lack of specificity in handling ANY
-   queries, as described in Section 2.3, were discovered by David
-   Blacka.
-
-   The error in algorithm 1 key tag calculation, as described in
-   Section 3.4, was found by Abhijit Hayatnagarkar.  Donald Eastlake
-   contributed text for Section 3.4.
-
-   The bug relating to delegation NSEC RR's in Section 2.1 was found by
-   Roy Badami.  Roy Arends found the related problem with DNAME.
-
-   The errors in the RFC4035 examples were found by Roy Arends, who also
-   contributed text for Section 4.3 of this document.
-
-
-
-Weiler                  Expires November 24, 2005               [Page 9]
-
-Internet-Draft       DNSSECbis Implementation Notes             May 2005
-
-
-   The editor would like to thank Olafur Gudmundsson and Scott Rose for
-   their substantive comments on the text of this document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler                  Expires November 24, 2005              [Page 10]
-
-Internet-Draft       DNSSECbis Implementation Notes             May 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Weiler                  Expires November 24, 2005              [Page 11]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt
deleted file mode 100644
index ee03583..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt
+++ /dev/null
@@ -1,784 +0,0 @@
-
-
-
-DNSEXT                                                         D. Blacka
-Internet-Draft                                            Verisign, Inc.
-Expires: January 19, 2006                                  July 18, 2005
-
-
-                           DNSSEC Experiments
-                draft-ietf-dnsext-dnssec-experiments-01
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on January 19, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   In the long history of the development of the DNS security extensions
-   [1] (DNSSEC), a number of alternate methodologies and modifications
-   have been proposed and rejected for practical, rather than strictly
-   technical, reasons.  There is a desire to be able to experiment with
-   these alternate methods in the public DNS.  This document describes a
-   methodology for deploying alternate, non-backwards-compatible, DNSSEC
-   methodologies in an experimental fashion without disrupting the
-   deployment of standard DNSSEC.
-
-
-
-
-Blacka                  Expires January 19, 2006                [Page 1]
-
-Internet-Draft             DNSSEC Experiments                  July 2005
-
-
-Table of Contents
-
-   1.   Definitions and Terminology  . . . . . . . . . . . . . . . .   3
-   2.   Overview . . . . . . . . . . . . . . . . . . . . . . . . . .   4
-   3.   Experiments  . . . . . . . . . . . . . . . . . . . . . . . .   5
-   4.   Method . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
-   5.   Defining an Experiment . . . . . . . . . . . . . . . . . . .   8
-   6.   Considerations . . . . . . . . . . . . . . . . . . . . . . .   9
-   7.   Transitions  . . . . . . . . . . . . . . . . . . . . . . . .  10
-   8.   Security Considerations  . . . . . . . . . . . . . . . . . .  11
-   9.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  12
-   10.  References . . . . . . . . . . . . . . . . . . . . . . . . .  13
-     10.1   Normative References . . . . . . . . . . . . . . . . . .  13
-     10.2   Informative References . . . . . . . . . . . . . . . . .  13
-        Author's Address . . . . . . . . . . . . . . . . . . . . . .  13
-        Intellectual Property and Copyright Statements . . . . . . .  14
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka                  Expires January 19, 2006                [Page 2]
-
-Internet-Draft             DNSSEC Experiments                  July 2005
-
-
-1.  Definitions and Terminology
-
-   Throughout this document, familiarity with the DNS system (RFC 1035
-   [4]) and the DNS security extensions ([1], [2], and [3].
-
-   The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY, and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [5].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka                  Expires January 19, 2006                [Page 3]
-
-Internet-Draft             DNSSEC Experiments                  July 2005
-
-
-2.  Overview
-
-   Historically, experimentation with DNSSEC alternatives has been a
-   problematic endeavor.  There has typically been a desire to both
-   introduce non-backwards-compatible changes to DNSSEC, and to try
-   these changes on real zones in the public DNS.  This creates a
-   problem when the change to DNSSEC would make all or part of the zone
-   using those changes appear bogus (bad) or otherwise broken to
-   existing DNSSEC-aware resolvers.
-
-   This document describes a standard methodology for setting up public
-   DNSSEC experiments.  This methodology addresses the issue of co-
-   existence with standard DNSSEC and DNS by using unknown algorithm
-   identifiers to hide the experimental DNSSEC protocol modifications
-   from standard DNSSEC-aware resolvers.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka                  Expires January 19, 2006                [Page 4]
-
-Internet-Draft             DNSSEC Experiments                  July 2005
-
-
-3.  Experiments
-
-   When discussing DNSSEC experiments, it is necessary to classify these
-   experiments into two broad categories:
-
-   Backwards-Compatible: describes experimental changes that, while not
-      strictly adhering to the DNSSEC standard, are nonetheless
-      interoperable with clients and server that do implement the DNSSEC
-      standard.
-
-   Non-Backwards-Compatible: describes experiments that would cause a
-      standard DNSSEC-aware resolver to (incorrectly) determine that all
-      or part of a zone is bogus, or to otherwise not interoperable with
-      standard DNSSEC clients and servers.
-
-   Not included in these terms are experiments with the core DNS
-   protocol itself.
-
-   The methodology described in this document is not necessary for
-   backwards-compatible experiments, although it certainly could be used
-   if desired.
-
-   Note that, in essence, this metholodolgy would also be used to
-   introduce a new DNSSEC algorithm, independently from any DNSSEC
-   experimental protocol change.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka                  Expires January 19, 2006                [Page 5]
-
-Internet-Draft             DNSSEC Experiments                  July 2005
-
-
-4.  Method
-
-   The core of the methodology is the use of strictly "unknown"
-   algorithms to sign the experimental zone, and more importantly,
-   having only unknown algorithm DS records for the delegation to the
-   zone at the parent.
-
-   This technique works because of the way DNSSEC-compliant validators
-   are expected to work in the presence of a DS set with only unknown
-   algorithms.  From [3], Section 5.2:
-
-      If the validator does not support any of the algorithms listed in
-      an authenticated DS RRset, then the resolver has no supported
-      authentication path leading from the parent to the child.  The
-      resolver should treat this case as it would the case of an
-      authenticated NSEC RRset proving that no DS RRset exists, as
-      described above.
-
-   And further:
-
-      If the resolver does not support any of the algorithms listed in
-      an authenticated DS RRset, then the resolver will not be able to
-      verify the authentication path to the child zone.  In this case,
-      the resolver SHOULD treat the child zone as if it were unsigned.
-
-   While this behavior isn't strictly mandatory (as marked by MUST), it
-   is unlikely that a validator would not implement the behavior, or,
-   more to the point, it will not violate this behavior in an unsafe way
-   (see below (Section 6).)
-
-   Because we are talking about experiments, it is RECOMMENDED that
-   private algorithm numbers be used (see [2], appendix A.1.1.  Note
-   that secure handling of private algorithms requires special handing
-   by the validator logic.  See [6] for futher details.)  Normally,
-   instead of actually inventing new signing algorithms, the recommended
-   path is to create alternate algorithm identifiers that are aliases
-   for the existing, known algorithms.  While, strictly speaking, it is
-   only necessary to create an alternate identifier for the mandatory
-   algorithms, it is RECOMMENDED that all OPTIONAL defined algorithms be
-   aliased as well.
-
-   It is RECOMMENDED that for a particular DNSSEC experiment, a
-   particular domain name base is chosen for all new algorithms, then
-   the algorithm number (or name) is prepended to it.  For example, for
-   experiment A, the base name of "dnssec-experiment-a.example.com" is
-   chosen.  Then, aliases for algorithms 3 (DSA) and 5 (RSASHA1) are
-   defined to be "3.dnssec-experiment-a.example.com" and "5.dnssec-
-   experiment-a.example.com".  However, any unique identifier will
-
-
-
-Blacka                  Expires January 19, 2006                [Page 6]
-
-Internet-Draft             DNSSEC Experiments                  July 2005
-
-
-   suffice.
-
-   Using this method, resolvers (or, more specificially, DNSSEC
-   validators) essentially indicate their ability to understand the
-   DNSSEC experiment's semantics by understanding what the new algorithm
-   identifiers signify.
-
-   This method creates two classes of DNSSEC-aware servers and
-   resolvers: servers and resolvers that are aware of the experiment
-   (and thus recognize the experiments algorithm identifiers and
-   experimental semantics), and servers and resolvers that are unware of
-   the experiment.
-
-   This method also precludes any zone from being both in an experiment
-   and in a classic DNSSEC island of security.  That is, a zone is
-   either in an experiment and only experimentally validatable, or it
-   isn't.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka                  Expires January 19, 2006                [Page 7]
-
-Internet-Draft             DNSSEC Experiments                  July 2005
-
-
-5.  Defining an Experiment
-
-   The DNSSEC experiment must define the particular set of (previously
-   unknown) algorithms that identify the experiment, and define what
-   each unknown algorithm identifier means.  Typically, unless the
-   experiment is actually experimenting with a new DNSSEC algorithm,
-   this will be a mapping of private algorithm identifiers to existing,
-   known algorithms.
-
-   Normally the experiment will choose a DNS name as the algorithm
-   identifier base.  This DNS name SHOULD be under the control of the
-   authors of the experiment.  Then the experiment will define a mapping
-   between known mandatory and optional algorithms into this private
-   algorithm identifier space.  Alternately, the experiment MAY use the
-   OID private algorithm space instead (using algorithm number 254), or
-   may choose non-private algorithm numbers, although this would require
-   an IANA allocation (see below (Section 9).)
-
-   For example, an experiment might specify in its description the DNS
-   name "dnssec-experiment-a.example.com" as the base name, and provide
-   the mapping of "3.dnssec-experiment-a.example.com" is an alias of
-   DNSSEC algorithm 3 (DSA), and "5.dnssec-experiment-a.example.com" is
-   an alias of DNSSEC algorithm 5 (RSASHA1).
-
-   Resolvers MUST then only recognize the experiment's semantics when
-   present in a zone signed by one or more of these private algorithms.
-
-   In general, however, resolvers involved in the experiment are
-   expected to understand both standard DNSSEC and the defined
-   experimental DNSSEC protocol, although this isn't required.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka                  Expires January 19, 2006                [Page 8]
-
-Internet-Draft             DNSSEC Experiments                  July 2005
-
-
-6.  Considerations
-
-   There are a number of considerations with using this methodology.
-
-   1.  Under some circumstances, it may be that the experiment will not
-       be sufficiently masked by this technique and may cause resolution
-       problem for resolvers not aware of the experiment.  For instance,
-       the resolver may look at the not validatable response and
-       conclude that the response is bogus, either due to local policy
-       or implementation details.  This is not expected to be the common
-       case, however.
-
-   2.  In general, it will not be possible for DNSSEC-aware resolvers
-       not aware of the experiment to build a chain of trust through an
-       experimental zone.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka                  Expires January 19, 2006                [Page 9]
-
-Internet-Draft             DNSSEC Experiments                  July 2005
-
-
-7.  Transitions
-
-   If an experiment is successful, there may be a desire to move the
-   experiment to a standards-track extension.  One way to do so would be
-   to move from private algorithm numbers to IANA allocated algorithm
-   numbers, with otherwise the same meaning.  This would still leave a
-   divide between resolvers that understood the extension versus
-   resolvers that did not.  It would, in essence, create an additional
-   version of DNSSEC.
-
-   An alternate technique might be to do a typecode rollover, thus
-   actually creating a definitive new version of DNSSEC.  There may be
-   other transition techniques available, as well.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka                  Expires January 19, 2006               [Page 10]
-
-Internet-Draft             DNSSEC Experiments                  July 2005
-
-
-8.  Security Considerations
-
-   Zones using this methodology will be considered insecure by all
-   resolvers except those aware of the experiment.  It is not generally
-   possible to create a secure delegation from an experimental zone that
-   will be followed by resolvers unaware of the experiment.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka                  Expires January 19, 2006               [Page 11]
-
-Internet-Draft             DNSSEC Experiments                  July 2005
-
-
-9.  IANA Considerations
-
-   IANA may need to allocate new DNSSEC algorithm numbers if that
-   transition approach is taken, or the experiment decides to use
-   allocated numbers to begin with.  No IANA action is required to
-   deploy an experiment using private algorithm identifiers.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka                  Expires January 19, 2006               [Page 12]
-
-Internet-Draft             DNSSEC Experiments                  July 2005
-
-
-10.  References
-
-10.1  Normative References
-
-   [1]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "DNS Security Introduction and Requirements", RFC 4033,
-        March 2005.
-
-   [2]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Resource Records for the DNS Security Extensions", RFC 4034,
-        March 2005.
-
-   [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Protocol Modifications for the DNS Security Extensions",
-        RFC 4035, March 2005.
-
-10.2  Informative References
-
-   [4]  Mockapetris, P., "Domain names - implementation and
-        specification", STD 13, RFC 1035, November 1987.
-
-   [5]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [6]  Weiler, S., "Clarifications and Implementation Notes for
-        DNSSECbis", draft-weiler-dnsext-dnssec-bis-updates-00 (work in
-        progress), March 2005.
-
-
-Author's Address
-
-   David Blacka
-   Verisign, Inc.
-   21355 Ridgetop Circle
-   Dulles, VA  20166
-   US
-
-   Phone: +1 703 948 3200
-   Email: davidb@verisign.com
-   URI:   http://www.verisignlabs.com
-
-
-
-
-
-
-
-
-
-
-
-Blacka                  Expires January 19, 2006               [Page 13]
-
-Internet-Draft             DNSSEC Experiments                  July 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Blacka                  Expires January 19, 2006               [Page 14]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt
deleted file mode 100644
index 7503c66..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt
+++ /dev/null
@@ -1,616 +0,0 @@
-
-
-
-Network Working Group                                          S. Weiler
-Internet-Draft                                               SPARTA, Inc
-Updates: 4034, 4035 (if approved)                               J. Ihren
-Expires: July 24, 2006                                     Autonomica AB
-                                                        January 20, 2006
-
-
-       Minimally Covering NSEC Records and DNSSEC On-line Signing
-               draft-ietf-dnsext-dnssec-online-signing-02
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on July 24, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document describes how to construct DNSSEC NSEC resource records
-   that cover a smaller range of names than called for by RFC4034.  By
-   generating and signing these records on demand, authoritative name
-   servers can effectively stop the disclosure of zone contents
-   otherwise made possible by walking the chain of NSEC records in a
-   signed zone.
-
-
-
-
-Weiler & Ihren            Expires July 24, 2006                 [Page 1]
-
-Internet-Draft                NSEC Epsilon                  January 2006
-
-
-Changes from ietf-01 to ietf-02
-
-   Clarified that a generated NSEC RR's type bitmap MUST have the RRSIG
-   and NSEC bits set, to be consistent with DNSSECbis -- previous text
-   said SHOULD.
-
-   Made the applicability statement a little less oppressive.
-
-Changes from ietf-00 to ietf-01
-
-   Added an applicability statement, making reference to ongoing work on
-   NSEC3.
-
-   Added the phrase "epsilon functions", which has been commonly used to
-   describe the technique and already appeared in the header of each
-   page, in place of "increment and decrement functions".  Also added an
-   explanatory sentence.
-
-   Corrected references from 4034 section 6.2 to section 6.1.
-
-   Fixed an out-of-date reference to [-bis] and other typos.
-
-   Replaced IANA Considerations text.
-
-   Escaped close parentheses in examples.
-
-   Added some more acknowledgements.
-
-Changes from weiler-01 to ietf-00
-
-   Inserted RFC numbers for 4033, 4034, and 4035.
-
-   Specified contents of bitmap field in synthesized NSEC RR's, pointing
-   out that this relaxes a constraint in 4035.  Added 4035 to the
-   Updates header.
-
-Changes from weiler-00 to weiler-01
-
-   Clarified that this updates RFC4034 by relaxing requirements on the
-   next name field.
-
-   Added examples covering wildcard names.
-
-   In the 'better functions' section, reiterated that perfect functions
-   aren't needed.
-
-   Added a reference to RFC 2119.
-
-
-
-
-Weiler & Ihren            Expires July 24, 2006                 [Page 2]
-
-Internet-Draft                NSEC Epsilon                  January 2006
-
-
-Table of Contents
-
-   1.  Introduction and Terminology . . . . . . . . . . . . . . . . .  4
-   2.  Applicability of This Technique  . . . . . . . . . . . . . . .  4
-   3.  Minimally Covering NSEC Records  . . . . . . . . . . . . . . .  5
-   4.  Better Epsilon Functions . . . . . . . . . . . . . . . . . . .  6
-   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
-   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
-   7.  Normative References . . . . . . . . . . . . . . . . . . . . .  8
-   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . .  8
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
-   Intellectual Property and Copyright Statements . . . . . . . . . . 11
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler & Ihren            Expires July 24, 2006                 [Page 3]
-
-Internet-Draft                NSEC Epsilon                  January 2006
-
-
-1.  Introduction and Terminology
-
-   With DNSSEC [1], an NSEC record lists the next instantiated name in
-   its zone, proving that no names exist in the "span" between the
-   NSEC's owner name and the name in the "next name" field.  In this
-   document, an NSEC record is said to "cover" the names between its
-   owner name and next name.
-
-   Through repeated queries that return NSEC records, it is possible to
-   retrieve all of the names in the zone, a process commonly called
-   "walking" the zone.  Some zone owners have policies forbidding zone
-   transfers by arbitrary clients; this side-effect of the NSEC
-   architecture subverts those policies.
-
-   This document presents a way to prevent zone walking by constructing
-   NSEC records that cover fewer names.  These records can make zone
-   walking take approximately as many queries as simply asking for all
-   possible names in a zone, making zone walking impractical.  Some of
-   these records must be created and signed on demand, which requires
-   on-line private keys.  Anyone contemplating use of this technique is
-   strongly encouraged to review the discussion of the risks of on-line
-   signing in Section 6.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [4].
-
-
-2.  Applicability of This Technique
-
-   The technique presented here may be useful to a zone owner that wants
-   to use DNSSEC, is concerned about exposure of its zone contents via
-   zone walking, and is willing to bear the costs of on-line signing.
-
-   As discussed in Section 6, on-line signing has several security
-   risks, including an increased likelihood of private keys being
-   disclosed and an increased risk of denial of service attack.  Anyone
-   contemplating use of this technique is strongly encouraged to review
-   the discussion of the risks of on-line signing in Section 6.
-
-   Furthermore, at the time this document was published, the DNSEXT
-   working group was actively working on a mechanism to prevent zone
-   walking that does not require on-line signing (tentatively called
-   NSEC3).  The new mechanism is likely to expose slightly more
-   information about the zone than this technique (e.g. the number of
-   instantiated names), but it may be preferable to this technique.
-
-
-
-
-
-Weiler & Ihren            Expires July 24, 2006                 [Page 4]
-
-Internet-Draft                NSEC Epsilon                  January 2006
-
-
-3.  Minimally Covering NSEC Records
-
-   This mechanism involves changes to NSEC records for instantiated
-   names, which can still be generated and signed in advance, as well as
-   the on-demand generation and signing of new NSEC records whenever a
-   name must be proven not to exist.
-
-   In the 'next name' field of instantiated names' NSEC records, rather
-   than list the next instantiated name in the zone, list any name that
-   falls lexically after the NSEC's owner name and before the next
-   instantiated name in the zone, according to the ordering function in
-   RFC4034 [2] section 6.1.  This relaxes the requirement in section
-   4.1.1 of RFC4034 that the 'next name' field contains the next owner
-   name in the zone.  This change is expected to be fully compatible
-   with all existing DNSSEC validators.  These NSEC records are returned
-   whenever proving something specifically about the owner name (e.g.
-   that no resource records of a given type appear at that name).
-
-   Whenever an NSEC record is needed to prove the non-existence of a
-   name, a new NSEC record is dynamically produced and signed.  The new
-   NSEC record has an owner name lexically before the QNAME but
-   lexically following any existing name and a 'next name' lexically
-   following the QNAME but before any existing name.
-
-   The generated NSEC record's type bitmap MUST have the RRSIG and NSEC
-   bits set and SHOULD NOT have any other bits set.  This relaxes the
-   requirement in Section 2.3 of RFC4035 that NSEC RRs not appear at
-   names that did not exist before the zone was signed.
-
-   The functions to generate the lexically following and proceeding
-   names need not be perfect nor consistent, but the generated NSEC
-   records must not cover any existing names.  Furthermore, this
-   technique works best when the generated NSEC records cover as few
-   names as possible.  In this document, the functions that generate the
-   nearby names are called 'epsilon' functions, a reference to the
-   mathematical convention of using the greek letter epsilon to
-   represent small deviations.
-
-   An NSEC record denying the existence of a wildcard may be generated
-   in the same way.  Since the NSEC record covering a non-existent
-   wildcard is likely to be used in response to many queries,
-   authoritative name servers using the techniques described here may
-   want to pregenerate or cache that record and its corresponding RRSIG.
-
-   For example, a query for an A record at the non-instantiated name
-   example.com might produce the following two NSEC records, the first
-   denying the existence of the name example.com and the second denying
-   the existence of a wildcard:
-
-
-
-Weiler & Ihren            Expires July 24, 2006                 [Page 5]
-
-Internet-Draft                NSEC Epsilon                  January 2006
-
-
-             exampld.com 3600 IN NSEC example-.com ( RRSIG NSEC )
-
-             \).com 3600 IN NSEC +.com ( RRSIG NSEC )
-
-   Before answering a query with these records, an authoritative server
-   must test for the existence of names between these endpoints.  If the
-   generated NSEC would cover existing names (e.g. exampldd.com or
-   *bizarre.example.com), a better epsilon function may be used or the
-   covered name closest to the QNAME could be used as the NSEC owner
-   name or next name, as appropriate.  If an existing name is used as
-   the NSEC owner name, that name's real NSEC record MUST be returned.
-   Using the same example, assuming an exampldd.com delegation exists,
-   this record might be returned from the parent:
-
-             exampldd.com 3600 IN NSEC example-.com ( NS DS RRSIG NSEC )
-
-   Like every authoritative record in the zone, each generated NSEC
-   record MUST have corresponding RRSIGs generated using each algorithm
-   (but not necessarily each DNSKEY) in the zone's DNSKEY RRset, as
-   described in RFC4035 [3] section 2.2.  To minimize the number of
-   signatures that must be generated, a zone may wish to limit the
-   number of algorithms in its DNSKEY RRset.
-
-
-4.  Better Epsilon Functions
-
-   Section 6.1 of RFC4034 defines a strict ordering of DNS names.
-   Working backwards from that definition, it should be possible to
-   define epsilon functions that generate the immediately following and
-   preceding names, respectively.  This document does not define such
-   functions.  Instead, this section presents functions that come
-   reasonably close to the perfect ones.  As described above, an
-   authoritative server should still ensure than no generated NSEC
-   covers any existing name.
-
-   To increment a name, add a leading label with a single null (zero-
-   value) octet.
-
-   To decrement a name, decrement the last character of the leftmost
-   label, then fill that label to a length of 63 octets with octets of
-   value 255.  To decrement a null (zero-value) octet, remove the octet
-   -- if an empty label is left, remove the label.  Defining this
-   function numerically: fill the left-most label to its maximum length
-   with zeros (numeric, not ASCII zeros) and subtract one.
-
-   In response to a query for the non-existent name foo.example.com,
-   these functions produce NSEC records of:
-
-
-
-
-Weiler & Ihren            Expires July 24, 2006                 [Page 6]
-
-Internet-Draft                NSEC Epsilon                  January 2006
-
-
-     fon\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255.example.com 3600 IN NSEC \000.foo.example.com ( NSEC RRSIG )
-
-     \)\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255\255.example.com 3600 IN NSEC \000.*.example.com ( NSEC RRSIG )
-
-   The first of these NSEC RRs proves that no exact match for
-   foo.example.com exists, and the second proves that there is no
-   wildcard in example.com.
-
-   Both of these functions are imperfect: they don't take into account
-   constraints on number of labels in a name nor total length of a name.
-   As noted in the previous section, though, this technique does not
-   depend on the use of perfect epsilon functions: it is sufficient to
-   test whether any instantiated names fall into the span covered by the
-   generated NSEC and, if so, substitute those instantiated owner names
-   for the NSEC owner name or next name, as appropriate.
-
-
-5.  IANA Considerations
-
-   This document specifies no IANA Actions.
-
-
-6.  Security Considerations
-
-   This approach requires on-demand generation of RRSIG records.  This
-   creates several new vulnerabilities.
-
-   First, on-demand signing requires that a zone's authoritative servers
-   have access to its private keys.  Storing private keys on well-known
-   internet-accessible servers may make them more vulnerable to
-   unintended disclosure.
-
-   Second, since generation of digital signatures tends to be
-   computationally demanding, the requirement for on-demand signing
-   makes authoritative servers vulnerable to a denial of service attack.
-
-   Lastly, if the epsilon functions are predictable, on-demand signing
-   may enable a chosen-plaintext attack on a zone's private keys.  Zones
-   using this approach should attempt to use cryptographic algorithms
-   that are resistant to chosen-plaintext attacks.  It's worth noting
-
-
-
-Weiler & Ihren            Expires July 24, 2006                 [Page 7]
-
-Internet-Draft                NSEC Epsilon                  January 2006
-
-
-   that while DNSSEC has a "mandatory to implement" algorithm, that is a
-   requirement on resolvers and validators -- there is no requirement
-   that a zone be signed with any given algorithm.
-
-   The success of using minimally covering NSEC record to prevent zone
-   walking depends greatly on the quality of the epsilon functions
-   chosen.  An increment function that chooses a name obviously derived
-   from the next instantiated name may be easily reverse engineered,
-   destroying the value of this technique.  An increment function that
-   always returns a name close to the next instantiated name is likewise
-   a poor choice.  Good choices of epsilon functions are the ones that
-   produce the immediately following and preceding names, respectively,
-   though zone administrators may wish to use less perfect functions
-   that return more human-friendly names than the functions described in
-   Section 4 above.
-
-   Another obvious but misguided concern is the danger from synthesized
-   NSEC records being replayed.  It's possible for an attacker to replay
-   an old but still validly signed NSEC record after a new name has been
-   added in the span covered by that NSEC, incorrectly proving that
-   there is no record at that name.  This danger exists with DNSSEC as
-   defined in [3].  The techniques described here actually decrease the
-   danger, since the span covered by any NSEC record is smaller than
-   before.  Choosing better epsilon functions will further reduce this
-   danger.
-
-7.  Normative References
-
-   [1]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "DNS Security Introduction and Requirements", RFC 4033,
-        March 2005.
-
-   [2]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Resource Records for the DNS Security Extensions", RFC 4034,
-        March 2005.
-
-   [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Protocol Modifications for the DNS Security Extensions",
-        RFC 4035, March 2005.
-
-   [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-
-Appendix A.  Acknowledgments
-
-   Many individuals contributed to this design.  They include, in
-   addition to the authors of this document, Olaf Kolkman, Ed Lewis,
-
-
-
-Weiler & Ihren            Expires July 24, 2006                 [Page 8]
-
-Internet-Draft                NSEC Epsilon                  January 2006
-
-
-   Peter Koch, Matt Larson, David Blacka, Suzanne Woolf, Jaap Akkerhuis,
-   Jakob Schlyter, Bill Manning, and Joao Damas.
-
-   In addition, the editors would like to thank Ed Lewis, Scott Rose,
-   and David Blacka for their careful review of the document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler & Ihren            Expires July 24, 2006                 [Page 9]
-
-Internet-Draft                NSEC Epsilon                  January 2006
-
-
-Authors' Addresses
-
-   Samuel Weiler
-   SPARTA, Inc
-   7075 Samuel Morse Drive
-   Columbia, Maryland  21046
-   US
-
-   Email: weiler@tislabs.com
-
-
-   Johan Ihren
-   Autonomica AB
-   Bellmansgatan 30
-   Stockholm  SE-118 47
-   Sweden
-
-   Email: johani@autonomica.se
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler & Ihren            Expires July 24, 2006                [Page 10]
-
-Internet-Draft                NSEC Epsilon                  January 2006
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Weiler & Ihren            Expires July 24, 2006                [Page 11]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt
deleted file mode 100644
index 17e28e8..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt
+++ /dev/null
@@ -1,896 +0,0 @@
-
-
-
-DNSEXT                                                         R. Arends
-Internet-Draft                                      Telematica Instituut
-Expires: January 19, 2006                                     M. Kosters
-                                                               D. Blacka
-                                                          Verisign, Inc.
-                                                           July 18, 2005
-
-
-                             DNSSEC Opt-In
-                   draft-ietf-dnsext-dnssec-opt-in-07
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on January 19, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   In the DNS security extensions (DNSSEC, defined in RFC 4033 [3], RFC
-   4034 [4], and RFC 4035 [5]), delegations to unsigned subzones are
-   cryptographically secured.  Maintaining this cryptography is not
-   practical or necessary.  This document describes an experimental
-   "Opt-In" model that allows administrators to omit this cryptography
-   and manage the cost of adopting DNSSEC with large zones.
-
-
-
-Arends, et al.          Expires January 19, 2006                [Page 1]
-
-Internet-Draft                DNSSEC Opt-In                    July 2005
-
-
-Table of Contents
-
-   1.  Definitions and Terminology  . . . . . . . . . . . . . . . . .  3
-   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   3.  Experimental Status  . . . . . . . . . . . . . . . . . . . . .  4
-   4.  Protocol Additions . . . . . . . . . . . . . . . . . . . . . .  4
-     4.1   Server Considerations  . . . . . . . . . . . . . . . . . .  5
-       4.1.1   Delegations Only . . . . . . . . . . . . . . . . . . .  5
-       4.1.2   Insecure Delegation Responses  . . . . . . . . . . . .  6
-       4.1.3   Wildcards and Opt-In . . . . . . . . . . . . . . . . .  6
-       4.1.4   Dynamic Update . . . . . . . . . . . . . . . . . . . .  7
-     4.2   Client Considerations  . . . . . . . . . . . . . . . . . .  7
-       4.2.1   Delegations Only . . . . . . . . . . . . . . . . . . .  7
-       4.2.2   Validation Process Changes . . . . . . . . . . . . . .  7
-       4.2.3   NSEC Record Caching  . . . . . . . . . . . . . . . . .  8
-       4.2.4   Use of the AD bit  . . . . . . . . . . . . . . . . . .  8
-   5.  Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
-   6.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
-   7.  Transition Issues  . . . . . . . . . . . . . . . . . . . . . . 10
-   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
-   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
-   10.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 12
-   11.   References . . . . . . . . . . . . . . . . . . . . . . . . . 13
-     11.1  Normative References . . . . . . . . . . . . . . . . . . . 13
-     11.2  Informative References . . . . . . . . . . . . . . . . . . 13
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
-   A.  Implementing Opt-In using "Views"  . . . . . . . . . . . . . . 14
-       Intellectual Property and Copyright Statements . . . . . . . . 16
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 19, 2006                [Page 2]
-
-Internet-Draft                DNSSEC Opt-In                    July 2005
-
-
-1.  Definitions and Terminology
-
-   Throughout this document, familiarity with the DNS system (RFC 1035
-   [1]), DNS security extensions ([3], [4], and [5], referred to in this
-   document as "standard DNSSEC"), and DNSSEC terminology (RFC 3090
-   [10]) is assumed.
-
-   The following abbreviations and terms are used in this document:
-
-   RR: is used to refer to a DNS resource record.
-   RRset: refers to a Resource Record Set, as defined by [8].  In this
-      document, the RRset is also defined to include the covering RRSIG
-      records, if any exist.
-   signed name: refers to a DNS name that has, at minimum, a (signed)
-      NSEC record.
-   unsigned name: refers to a DNS name that does not (at least) have a
-      NSEC record.
-   covering NSEC record/RRset: is the NSEC record used to prove
-      (non)existence of a particular name or RRset.  This means that for
-      a RRset or name 'N', the covering NSEC record has the name 'N', or
-      has an owner name less than 'N' and "next" name greater than 'N'.
-   delegation: refers to a NS RRset with a name different from the
-      current zone apex (non-zone-apex), signifying a delegation to a
-      subzone.
-   secure delegation: refers to a signed name containing a delegation
-      (NS RRset), and a signed DS RRset, signifying a delegation to a
-      signed subzone.
-   insecure delegation: refers to a signed name containing a delegation
-      (NS RRset), but lacking a DS RRset, signifying a delegation to an
-      unsigned subzone.
-   Opt-In insecure delegation: refers to an unsigned name containing
-      only a delegation NS RRset.  The covering NSEC record uses the
-      Opt-In methodology described in this document.
-
-   The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY, and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [7].
-
-2.  Overview
-
-   The cost to cryptographically secure delegations to unsigned zones is
-   high for large delegation-centric zones and zones where insecure
-   delegations will be updated rapidly.  For these zones, the costs of
-   maintaining the NSEC record chain may be extremely high relative to
-   the gain of cryptographically authenticating existence of unsecured
-   zones.
-
-   This document describes an experimental method of eliminating the
-
-
-
-Arends, et al.          Expires January 19, 2006                [Page 3]
-
-Internet-Draft                DNSSEC Opt-In                    July 2005
-
-
-   superfluous cryptography present in secure delegations to unsigned
-   zones.  Using "Opt-In", a zone administrator can choose to remove
-   insecure delegations from the NSEC chain.  This is accomplished by
-   extending the semantics of the NSEC record by using a redundant bit
-   in the type map.
-
-3.  Experimental Status
-
-   This document describes an EXPERIMENTAL extension to DNSSEC.  It
-   interoperates with non-experimental DNSSEC using the technique
-   described in [6].  This experiment is identified with the following
-   private algorithms (using algorithm 253):
-
-   "3.optin.verisignlabs.com": is an alias for DNSSEC algorithm 3, DSA,
-      and
-   "5.optin.verisignlabs.com": is an alias for DNSSEC algorithm 5,
-      RSASHA1.
-
-   Servers wishing to sign and serve zones that utilize Opt-In MUST sign
-   the zone with only one or more of these private algorithms.  This
-   requires the signing tools and servers to support private algorithms,
-   as well as Opt-In.
-
-   Resolvers wishing to validate Opt-In zones MUST only do so when the
-   zone is only signed using one or more of these private algorithms.
-
-   The remainder of this document assumes that the servers and resolvers
-   involved are aware of and are involved in this experiment.
-
-4.  Protocol Additions
-
-   In DNSSEC, delegation NS RRsets are not signed, but are instead
-   accompanied by a NSEC RRset of the same name and (possibly) a DS
-   record.  The security status of the subzone is determined by the
-   presence or absence of the DS RRset, cryptographically proven by the
-   NSEC record.  Opt-In expands this definition by allowing insecure
-   delegations to exist within an otherwise signed zone without the
-   corresponding NSEC record at the delegation's owner name.  These
-   insecure delegations are proven insecure by using a covering NSEC
-   record.
-
-   Since this represents a change of the interpretation of NSEC records,
-   resolvers must be able to distinguish between RFC standard DNSSEC
-   NSEC records and Opt-In NSEC records.  This is accomplished by
-   "tagging" the NSEC records that cover (or potentially cover) insecure
-   delegation nodes.  This tag is indicated by the absence of the NSEC
-   bit in the type map.  Since the NSEC bit in the type map merely
-   indicates the existence of the record itself, this bit is redundant
-
-
-
-Arends, et al.          Expires January 19, 2006                [Page 4]
-
-Internet-Draft                DNSSEC Opt-In                    July 2005
-
-
-   and safe for use as a tag.
-
-   An Opt-In tagged NSEC record does not assert the (non)existence of
-   the delegations that it covers (except for a delegation with the same
-   name).  This allows for the addition or removal of these delegations
-   without recalculating or resigning records in the NSEC chain.
-   However, Opt-In tagged NSEC records do assert the (non)existence of
-   other RRsets.
-
-   An Opt-In NSEC record MAY have the same name as an insecure
-   delegation.  In this case, the delegation is proven insecure by the
-   lack of a DS bit in type map and the signed NSEC record does assert
-   the existence of the delegation.
-
-   Zones using Opt-In MAY contain a mixture of Opt-In tagged NSEC
-   records and standard DNSSEC NSEC records.  If a NSEC record is not
-   Opt-In, there MUST NOT be any insecure delegations (or any other
-   records) between it and the RRsets indicated by the 'next domain
-   name' in the NSEC RDATA.  If it is Opt-In, there MUST only be
-   insecure delegations between it and the next node indicated by the
-   'next domain name' in the NSEC RDATA.
-
-   In summary,
-
-   o  An Opt-In NSEC type is identified by a zero-valued (or not-
-      specified) NSEC bit in the type bit map of the NSEC record.
-   o  A RFC2535bis NSEC type is identified by a one-valued NSEC bit in
-      the type bit map of the NSEC record.
-
-   and,
-
-   o  An Opt-In NSEC record does not assert the non-existence of a name
-      between its owner name and "next" name, although it does assert
-      that any name in this span MUST be an insecure delegation.
-   o  An Opt-In NSEC record does assert the (non)existence of RRsets
-      with the same owner name.
-
-4.1  Server Considerations
-
-   Opt-In imposes some new requirements on authoritative DNS servers.
-
-4.1.1  Delegations Only
-
-   This specification dictates that only insecure delegations may exist
-   between the owner and "next" names of an Opt-In tagged NSEC record.
-   Signing tools SHOULD NOT generate signed zones that violate this
-   restriction.  Servers SHOULD refuse to load and/or serve zones that
-   violate this restriction.  Servers also SHOULD reject AXFR or IXFR
-
-
-
-Arends, et al.          Expires January 19, 2006                [Page 5]
-
-Internet-Draft                DNSSEC Opt-In                    July 2005
-
-
-   responses that violate this restriction.
-
-4.1.2  Insecure Delegation Responses
-
-   When returning an Opt-In insecure delegation, the server MUST return
-   the covering NSEC RRset in the Authority section.
-
-   In standard DNSSEC, NSEC records already must be returned along with
-   the insecure delegation.  The primary difference that this proposal
-   introduces is that the Opt-In tagged NSEC record will have a
-   different owner name from the delegation RRset.  This may require
-   implementations to search for the covering NSEC RRset.
-
-4.1.3  Wildcards and Opt-In
-
-   Standard DNSSEC describes the practice of returning NSEC records to
-   prove the non-existence of an applicable wildcard in non-existent
-   name responses.  This NSEC record can be described as a "negative
-   wildcard proof".  The use of Opt-In NSEC records changes the
-   necessity for this practice.  For non-existent name responses when
-   the query name (qname) is covered by an Opt-In tagged NSEC record,
-   servers MAY choose to omit the wildcard proof record, and clients
-   MUST NOT treat the absence of this NSEC record as a validation error.
-
-   The intent of the standard DNSSEC negative wildcard proof requirement
-   is to prevent malicious users from undetectably removing valid
-   wildcard responses.  In order for this cryptographic proof to work,
-   the resolver must be able to prove:
-
-   1.  The exact qname does not exist.  This is done by the "normal"
-       NSEC record.
-   2.  No applicable wildcard exists.  This is done by returning a NSEC
-       record proving that the wildcard does not exist (this is the
-       negative wildcard proof).
-
-   However, if the NSEC record covering the exact qname is an Opt-In
-   NSEC record, the resolver will not be able to prove the first part of
-   this equation, as the qname might exist as an insecure delegation.
-   Thus, since the total proof cannot be completed, the negative
-   wildcard proof NSEC record is not useful.
-
-   The negative wildcard proof is also not useful when returned as part
-   of an Opt-In insecure delegation response for a similar reason: the
-   resolver cannot prove that the qname does or does not exist, and
-   therefore cannot prove that a wildcard expansion is valid.
-
-   The presence of an Opt-In tagged NSEC record does not change the
-   practice of returning a NSEC along with a wildcard expansion.  Even
-
-
-
-Arends, et al.          Expires January 19, 2006                [Page 6]
-
-Internet-Draft                DNSSEC Opt-In                    July 2005
-
-
-   though the Opt-In NSEC will not be able to prove that the wildcard
-   expansion is valid, it will prove that the wildcard expansion is not
-   masking any signed records.
-
-4.1.4  Dynamic Update
-
-   Opt-In changes the semantics of Secure DNS Dynamic Update [9].  In
-   particular, it introduces the need for rules that describe when to
-   add or remove a delegation name from the NSEC chain.  This document
-   does not attempt to define these rules.  Until these rules are
-   defined, servers MUST NOT process DNS Dynamic Update requests against
-   zones that use Opt-In NSEC records.  Servers SHOULD return responses
-   to update requests with RCODE=REFUSED.
-
-4.2  Client Considerations
-
-   Opt-In imposes some new requirements on security-aware resolvers
-   (caching or otherwise).
-
-4.2.1  Delegations Only
-
-   As stated in the "Server Considerations" section above, this
-   specification restricts the namespace covered by Opt-In tagged NSEC
-   records to insecure delegations only.  Thus, resolvers MUST reject as
-   invalid any records that fall within an Opt-In NSEC record's span
-   that are not NS records or corresponding glue records.
-
-4.2.2  Validation Process Changes
-
-   This specification does not change the resolver's resolution
-   algorithm.  However, it does change the DNSSEC validation process.
-   Resolvers MUST be able to use Opt-In tagged NSEC records to
-   cryptographically prove the validity and security status (as
-   insecure) of a referral.  Resolvers determine the security status of
-   the referred-to zone as follows:
-
-   o  In standard DNSSEC, the security status is proven by the existence
-      or absence of a DS RRset at the same name as the delegation.  The
-      existence of the DS RRset indicates that the referred-to zone is
-      signed.  The absence of the DS RRset is proven using a verified
-      NSEC record of the same name that does not have the DS bit set in
-      the type map.  This NSEC record MAY also be tagged as Opt-In.
-   o  Using Opt-In, the security status is proven by the existence of a
-      DS record (for signed) or the presence of a verified Opt-In tagged
-      NSEC record that covers the delegation name.  That is, the NSEC
-      record does not have the NSEC bit set in the type map, and the
-      delegation name falls between the NSEC's owner and "next" name.
-
-
-
-
-Arends, et al.          Expires January 19, 2006                [Page 7]
-
-Internet-Draft                DNSSEC Opt-In                    July 2005
-
-
-   Using Opt-In does not substantially change the nature of following
-   referrals within DNSSEC.  At every delegation point, the resolver
-   will have cryptographic proof that the referred-to subzone is signed
-   or unsigned.
-
-   When receiving either an Opt-In insecure delegation response or a
-   non-existent name response where that name is covered by an Opt-In
-   tagged NSEC record, the resolver MUST NOT require proof (in the form
-   of a NSEC record) that a wildcard did not exist.
-
-4.2.3  NSEC Record Caching
-
-   Caching resolvers MUST be able to retrieve the appropriate covering
-   Opt-In NSEC record when returning referrals that need them.  This
-   requirement differs from standard DNSSEC in that the covering NSEC
-   will not have the same owner name as the delegation.  Some
-   implementations may have to use new methods for finding these NSEC
-   records.
-
-4.2.4  Use of the AD bit
-
-   The AD bit, as defined by [2] and [5], MUST NOT be set when:
-
-   o  sending a Name Error (RCODE=3) response where the covering NSEC is
-      tagged as Opt-In.
-   o  sending an Opt-In insecure delegation response, unless the
-      covering (Opt-In) NSEC record's owner name equals the delegation
-      name.
-
-   This rule is based on what the Opt-In NSEC record actually proves:
-   for names that exist between the Opt-In NSEC record's owner and
-   "next" names, the Opt-In NSEC record cannot prove the non-existence
-   or existence of the name.  As such, not all data in the response has
-   been cryptographically verified, so the AD bit cannot be set.
-
-5.  Benefits
-
-   Using Opt-In allows administrators of large and/or changing
-   delegation-centric zones to minimize the overhead involved in
-   maintaining the security of the zone.
-
-   Opt-In accomplishes this by eliminating the need for NSEC records for
-   insecure delegations.  This, in a zone with a large number of
-   delegations to unsigned subzones, can lead to substantial space
-   savings (both in memory and on disk).  Additionally, Opt-In allows
-   for the addition or removal of insecure delegations without modifying
-   the NSEC record chain.  Zones that are frequently updating insecure
-   delegations (e.g., TLDs) can avoid the substantial overhead of
-
-
-
-Arends, et al.          Expires January 19, 2006                [Page 8]
-
-Internet-Draft                DNSSEC Opt-In                    July 2005
-
-
-   modifying and resigning the affected NSEC records.
-
-6.  Example
-
-   Consider the zone EXAMPLE, shown below.  This is a zone where all of
-   the NSEC records are tagged as Opt-In.
-
-   Example A: Fully Opt-In Zone.
-
-         EXAMPLE.               SOA    ...
-         EXAMPLE.               RRSIG  SOA ...
-         EXAMPLE.               NS     FIRST-SECURE.EXAMPLE.
-         EXAMPLE.               RRSIG  NS ...
-         EXAMPLE.               DNSKEY ...
-         EXAMPLE.               RRSIG  DNSKEY ...
-         EXAMPLE.               NSEC   FIRST-SECURE.EXAMPLE. (
-                                       SOA NS RRSIG DNSKEY )
-         EXAMPLE.               RRSIG  NSEC ...
-
-         FIRST-SECURE.EXAMPLE.  A      ...
-         FIRST-SECURE.EXAMPLE.  RRSIG  A ...
-         FIRST-SECURE.EXAMPLE.  NSEC   NOT-SECURE-2.EXAMPLE. A RRSIG
-         FIRST-SECURE.EXAMPLE.  RRSIG  NSEC ...
-
-         NOT-SECURE.EXAMPLE.    NS     NS.NOT-SECURE.EXAMPLE.
-         NS.NOT-SECURE.EXAMPLE. A      ...
-
-         NOT-SECURE-2.EXAMPLE.  NS     NS.NOT-SECURE.EXAMPLE.
-         NOT-SECURE-2.EXAMPLE   NSEC   SECOND-SECURE.EXAMPLE NS RRSIG
-         NOT-SECURE-2.EXAMPLE   RRSIG  NSEC ...
-
-         SECOND-SECURE.EXAMPLE. NS     NS.ELSEWHERE.
-         SECOND-SECURE.EXAMPLE. DS     ...
-         SECOND-SECURE.EXAMPLE. RRSIG  DS ...
-         SECOND-SECURE.EXAMPLE. NSEC   EXAMPLE. NS RRSIG DNSKEY
-         SECOND-SECURE.EXAMPLE. RRSIG  NSEC ...
-
-         UNSIGNED.EXAMPLE.      NS     NS.UNSIGNED.EXAMPLE.
-         NS.UNSIGNED.EXAMPLE.   A      ...
-
-
-   In this example, a query for a signed RRset (e.g., "FIRST-
-   SECURE.EXAMPLE A"), or a secure delegation ("WWW.SECOND-
-   SECURE.EXAMPLE A") will result in a standard DNSSEC response.
-
-   A query for a nonexistent RRset will result in a response that
-   differs from standard DNSSEC by: the NSEC record will be tagged as
-   Opt-In, there may be no NSEC record proving the non-existence of a
-
-
-
-Arends, et al.          Expires January 19, 2006                [Page 9]
-
-Internet-Draft                DNSSEC Opt-In                    July 2005
-
-
-   matching wildcard record, and the AD bit will not be set.
-
-   A query for an insecure delegation RRset (or a referral) will return
-   both the answer (in the Authority section) and the corresponding
-   Opt-In NSEC record to prove that it is not secure.
-
-   Example A.1: Response to query for WWW.UNSIGNED.EXAMPLE.  A
-
-
-         RCODE=NOERROR, AD=0
-
-         Answer Section:
-
-         Authority Section:
-         UNSIGNED.EXAMPLE.      NS     NS.UNSIGNED.EXAMPLE
-         SECOND-SECURE.EXAMPLE. NSEC   EXAMPLE. NS RRSIG DS
-         SECOND-SECURE.EXAMPLE. RRSIG  NSEC ...
-
-         Additional Section:
-         NS.UNSIGNED.EXAMPLE.   A      ...
-
-   In the Example A.1 zone, the EXAMPLE. node MAY use either style of
-   NSEC record, because there are no insecure delegations that occur
-   between it and the next node, FIRST-SECURE.EXAMPLE.  In other words,
-   Example A would still be a valid zone if the NSEC record for EXAMPLE.
-   was changed to the following RR:
-
-         EXAMPLE.               NSEC   FIRST-SECURE.EXAMPLE. (SOA NS
-                                       RRSIG DNSKEY NSEC )
-
-   However, the other NSEC records (FIRST-SECURE.EXAMPLE. and SECOND-
-   SECURE.EXAMPLE.)  MUST be tagged as Opt-In because there are insecure
-   delegations in the range they define.  (NOT-SECURE.EXAMPLE. and
-   UNSIGNED.EXAMPLE., respectively).
-
-   NOT-SECURE-2.EXAMPLE. is an example of an insecure delegation that is
-   part of the NSEC chain and also covered by an Opt-In tagged NSEC
-   record.  Because NOT-SECURE-2.EXAMPLE. is a signed name, it cannot be
-   removed from the zone without modifying and resigning the prior NSEC
-   record.  Delegations with names that fall between NOT-SECURE-
-   2.EXAMPLE. and SECOND-SECURE.EXAMPLE. may be added or removed without
-   resigning any NSEC records.
-
-7.  Transition Issues
-
-   Opt-In is not backwards compatible with standard DNSSEC and is
-   considered experimental.  Standard DNSSEC compliant implementations
-   would not recognize Opt-In tagged NSEC records as different from
-
-
-
-Arends, et al.          Expires January 19, 2006               [Page 10]
-
-Internet-Draft                DNSSEC Opt-In                    July 2005
-
-
-   standard NSEC records.  Because of this, standard DNSSEC
-   implementations, if they were to validate Opt-In style responses,
-   would reject all Opt-In insecure delegations within a zone as
-   invalid.  However, by only signing with private algorithms, standard
-   DNSSEC implementations will treat Opt-In responses as unsigned.
-
-   It should be noted that all elements in the resolution path between
-   (and including) the validator and the authoritative name server must
-   be aware of the Opt-In experiment and implement the Opt-In semantics
-   for successful validation to be possible.  In particular, this
-   includes any caching middleboxes between the validator and
-   authoritative name server.
-
-8.  Security Considerations
-
-   Opt-In allows for unsigned names, in the form of delegations to
-   unsigned subzones, to exist within an otherwise signed zone.  All
-   unsigned names are, by definition, insecure, and their validity or
-   existence cannot by cryptographically proven.
-
-   In general:
-
-   o  Records with unsigned names (whether existing or not) suffer from
-      the same vulnerabilities as records in an unsigned zone.  These
-      vulnerabilities are described in more detail in [12] (note in
-      particular sections 2.3, "Name Games" and 2.6, "Authenticated
-      Denial").
-   o  Records with signed names have the same security whether or not
-      Opt-In is used.
-
-   Note that with or without Opt-In, an insecure delegation may have its
-   contents undetectably altered by an attacker.  Because of this, the
-   primary difference in security that Opt-In introduces is the loss of
-   the ability to prove the existence or nonexistence of an insecure
-   delegation within the span of an Opt-In NSEC record.
-
-   In particular, this means that a malicious entity may be able to
-   insert or delete records with unsigned names.  These records are
-   normally NS records, but this also includes signed wildcard
-   expansions (while the wildcard record itself is signed, its expanded
-   name is an unsigned name).
-
-   For example, if a resolver received the following response from the
-   example zone above:
-
-
-
-
-
-
-
-Arends, et al.          Expires January 19, 2006               [Page 11]
-
-Internet-Draft                DNSSEC Opt-In                    July 2005
-
-
-   Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE.  A
-
-         RCODE=NOERROR
-
-         Answer Section:
-
-         Authority Section:
-         DOES-NOT-EXIST.EXAMPLE. NS     NS.FORGED.
-         EXAMPLE.                NSEC   FIRST-SECURE.EXAMPLE. SOA NS \
-                                        RRSIG DNSKEY
-         EXAMPLE.                RRSIG  NSEC ...
-
-         Additional Section:
-
-
-   The resolver would have no choice but to believe that the referral to
-   NS.FORGED. is valid.  If a wildcard existed that would have been
-   expanded to cover "WWW.DOES-NOT-EXIST.EXAMPLE.", an attacker could
-   have undetectably removed it and replaced it with the forged
-   delegation.
-
-   Note that being able to add a delegation is functionally equivalent
-   to being able to add any record type: an attacker merely has to forge
-   a delegation to nameserver under his/her control and place whatever
-   records needed at the subzone apex.
-
-   While in particular cases, this issue may not present a significant
-   security problem, in general it should not be lightly dismissed.
-   Therefore, it is strongly RECOMMENDED that Opt-In be used sparingly.
-   In particular, zone signing tools SHOULD NOT default to Opt-In, and
-   MAY choose to not support Opt-In at all.
-
-9.  IANA Considerations
-
-   None.
-
-10.  Acknowledgments
-
-   The contributions, suggestions and remarks of the following persons
-   (in alphabetic order) to this draft are acknowledged:
-
-      Mats Dufberg, Miek Gieben, Olafur Gudmundsson, Bob Halley, Olaf
-      Kolkman, Edward Lewis, Ted Lindgreen, Rip Loomis, Bill Manning,
-      Dan Massey, Scott Rose, Mike Schiraldi, Jakob Schlyter, Brian
-      Wellington.
-
-11.  References
-
-
-
-
-Arends, et al.          Expires January 19, 2006               [Page 12]
-
-Internet-Draft                DNSSEC Opt-In                    July 2005
-
-
-11.1  Normative References
-
-   [1]  Mockapetris, P., "Domain names - implementation and
-        specification", STD 13, RFC 1035, November 1987.
-
-   [2]  Wellington, B. and O. Gudmundsson, "Redefinition of DNS
-        Authenticated Data (AD) bit", RFC 3655, November 2003.
-
-   [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "DNS Security Introduction and Requirements", RFC 4033,
-        March 2005.
-
-   [4]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Resource Records for the DNS Security Extensions", RFC 4034,
-        March 2005.
-
-   [5]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Protocol Modifications for the DNS Security Extensions",
-        RFC 4035, March 2005.
-
-   [6]  Blacka, D., "DNSSEC Experiments",
-        draft-ietf-dnsext-dnssec-experiments-01 (work in progress),
-        July 2005.
-
-11.2  Informative References
-
-   [7]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
-         Levels", BCP 14, RFC 2119, March 1997.
-
-   [8]   Elz, R. and R. Bush, "Clarifications to the DNS Specification",
-         RFC 2181, July 1997.
-
-   [9]   Eastlake, D., "Secure Domain Name System Dynamic Update",
-         RFC 2137, April 1997.
-
-   [10]  Lewis, E., "DNS Security Extension Clarification on Zone
-         Status", RFC 3090, March 2001.
-
-   [11]  Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225,
-         December 2001.
-
-   [12]  Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
-         System (DNS)", RFC 3833, August 2004.
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 19, 2006               [Page 13]
-
-Internet-Draft                DNSSEC Opt-In                    July 2005
-
-
-Authors' Addresses
-
-   Roy Arends
-   Telematica Instituut
-   Drienerlolaan 5
-   7522 NB  Enschede
-   NL
-
-   Email: roy.arends@telin.nl
-
-
-   Mark Kosters
-   Verisign, Inc.
-   21355 Ridgetop Circle
-   Dulles, VA  20166
-   US
-
-   Phone: +1 703 948 3200
-   Email: markk@verisign.com
-   URI:   http://www.verisignlabs.com
-
-
-   David Blacka
-   Verisign, Inc.
-   21355 Ridgetop Circle
-   Dulles, VA  20166
-   US
-
-   Phone: +1 703 948 3200
-   Email: davidb@verisign.com
-   URI:   http://www.verisignlabs.com
-
-Appendix A.  Implementing Opt-In using "Views"
-
-   In many cases, it may be convenient to implement an Opt-In zone by
-   combining two separately maintained "views" of a zone at request
-   time.  In this context, "view" refers to a particular version of a
-   zone, not to any specific DNS implementation feature.
-
-   In this scenario, one view is the secure view, the other is the
-   insecure (or legacy) view.  The secure view consists of an entirely
-   signed zone using Opt-In tagged NSEC records.  The insecure view
-   contains no DNSSEC information.  It is helpful, although not
-   necessary, for the secure view to be a subset (minus DNSSEC records)
-   of the insecure view.
-
-   In addition, the only RRsets that may solely exist in the insecure
-   view are non-zone-apex NS RRsets.  That is, all non-NS RRsets (and
-
-
-
-Arends, et al.          Expires January 19, 2006               [Page 14]
-
-Internet-Draft                DNSSEC Opt-In                    July 2005
-
-
-   the zone apex NS RRset) MUST be signed and in the secure view.
-
-   These two views may be combined at request time to provide a virtual,
-   single Opt-In zone.  The following algorithm is used when responding
-   to each query:
-      V_A is the secure view as described above.
-      V_B is the insecure view as described above.
-      R_A is a response generated from V_A, following RFC 2535bis.
-      R_B is a response generated from V_B, following DNS resolution as
-      per RFC 1035 [1].
-      R_C is the response generated by combining R_A with R_B, as
-      described below.
-      A query is DNSSEC-aware if it either has the DO bit [11] turned
-      on, or is for a DNSSEC-specific record type.
-
-
-
-   1.  If V_A is a subset of V_B and the query is not DNSSEC-aware,
-       generate and return R_B, otherwise
-   2.  Generate R_A.
-   3.  If R_A's RCODE != NXDOMAIN, return R_A, otherwise
-   4.  Generate R_B and combine it with R_A to form R_C:
-          For each section (ANSWER, AUTHORITY, ADDITIONAL), copy the
-          records from R_A into R_B, EXCEPT the AUTHORITY section SOA
-          record, if R_B's RCODE = NOERROR.
-   5.  Return R_C.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 19, 2006               [Page 15]
-
-Internet-Draft                DNSSEC Opt-In                    July 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Arends, et al.          Expires January 19, 2006               [Page 16]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-rsasha256-00.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-rsasha256-00.txt
deleted file mode 100644
index 390420a..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-rsasha256-00.txt
+++ /dev/null
@@ -1,392 +0,0 @@
-
-
-
-DNS Extensions working group                                   J. Jansen
-Internet-Draft                                                NLnet Labs
-Expires: July 5, 2006                                       January 2006
-
-
-     Use of RSA/SHA-256 DNSKEY and RRSIG Resource Records in DNSSEC
-                 draft-ietf-dnsext-dnssec-rsasha256-00
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on July 5, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document describes how to produce RSA/SHA-256 DNSKEY and RRSIG
-   resource records for use in the Domain Name System Security
-   Extensions (DNSSEC, RFC4033, RFC4034, and RFC4035).
-
-
-
-
-
-
-
-
-
-Jansen                    Expires July 5, 2006                  [Page 1]
-
-Internet-Draft       RSA/SHA-256 DNSKEYs and RRSIGS         January 2006
-
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
-   2.  RSA/SHA-256 DNSKEY Resource Records . . . . . . . . . . . . . . 3
-   3.  RSA/SHA-256 RRSIG Resource Records  . . . . . . . . . . . . . . 3
-   4.  Implementation Considerations . . . . . . . . . . . . . . . . . 4
-   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
-   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
-   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
-   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
-     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
-     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 5
-   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 6
-   Intellectual Property and Copyright Statements  . . . . . . . . . . 7
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jansen                    Expires July 5, 2006                  [Page 2]
-
-Internet-Draft       RSA/SHA-256 DNSKEYs and RRSIGS         January 2006
-
-
-1.  Introduction
-
-   The Domain Name System (DNS) is the global hierarchical distributed
-   database for Internet Addressing.  The DNS has been extended to use
-   digital signatures and cryptographic keys for the verification of
-   data.  RFC4033 [1], RFC4034 [2], and RFC4035 [3] describe these DNS
-   Security Extensions.
-
-   RFC4034 describes how to store DNSKEY and RRSIG resource records, and
-   specifies a list of cryptographic algorithms to use.  This document
-   extends that list with the algorithm RSA/SHA-256, and specifies how
-   to store RSA/SHA-256 DNSKEY data and how to produce RSA/SHA-256 RRSIG
-   resource records.
-
-   Familiarity with the RSA [7] and SHA-256 [5] algorithms is assumed in
-   this document.
-
-
-2.  RSA/SHA-256 DNSKEY Resource Records
-
-   RSA public keys for use with RSA/SHA-256 are stored in DNSKEY
-   resource records (RRs) with the algorithm number [TBA].
-
-   The format of the DNSKEY RR can be found in RFC4034 [2] and RFC3110
-   [6].
-
-
-3.  RSA/SHA-256 RRSIG Resource Records
-
-   RSA/SHA-256 signatures are stored in the DNS using RRSIG resource
-   records (RRs) with algorithm number [TBA].
-
-   The value of the signature field in the RRSIG RR is calculated as
-   follows.  The values for the fields that precede the signature data
-   are specified in RFC4034 [2].
-
-   hash = SHA-256(data)
-
-   signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n)
-
-   Where SHA-256 is the message digest algorithm as specified in FIPS
-   180 [5], | is concatenation, 00, 01, FF and 00 are fixed octets of
-   corresponding hexadecimal value, "e" is the private exponent of the
-   signing RSA key, and "n" is the public modulus of the signing key.
-   The FF octet MUST be repeated the maximum number of times so that the
-   total length of the signature equals the length of the modulus of the
-   signer's public key ("n"). "data" is the data of the resource record
-   set that is signed, as specified in RFC4034 [2].
-
-
-
-Jansen                    Expires July 5, 2006                  [Page 3]
-
-Internet-Draft       RSA/SHA-256 DNSKEYs and RRSIGS         January 2006
-
-
-   The prefix is the ASN.1 BER SHA-256 algorithm designator prefix as
-   specified in PKCS 2.1 [4]:
-
-   hex 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20
-
-   This prefix should make the use of standard cryptographic libraries
-   easier.  These specifications are taken directly from PKCS #1 v2.1
-   section 9.2 [4].
-
-
-4.  Implementation Considerations
-
-   DNSSEC aware implementations MUST be able to support RRSIG resource
-   records with the RSA/SHA-256 algorithm.
-
-   If both RSA/SHA-256 and RSA/SHA-1 RRSIG resource records are
-   available for a certain rrset, with a secure path to their keys, the
-   validator SHOULD ignore the SHA-1 signature.  If the RSA/SHA-256
-   signature does not verify the data, and the RSA/SHA-1 does, the
-   validator SHOULD mark the data with the security status from the RSA/
-   SHA-256 signature.
-
-
-5.  IANA Considerations
-
-   IANA has not yet assigned an algorithm number for RSA/SHA-256.
-
-   The algorithm list from RFC4034 Appendix A.1 [2] is extended with the
-   following entry:
-
-                                   Zone
-   Value Algorithm    [Mnemonic] Signing  References   Status
-   ----- ----------- ----------- -------- ----------  ---------
-   [tba] RSA/SHA-256 [RSASHA256]      y        [TBA]  MANDATORY
-
-
-6.  Security Considerations
-
-   Recently, weaknesses have been discovered in the SHA-1 hashing
-   algorithm.  It is therefore strongly encouraged to deploy SHA-256
-   where SHA-1 is used now, as soon as the DNS software supports it.
-
-   SHA-256 is considered sufficiently strong for the immediate future,
-   but predictions about future development in cryptography and
-   cryptanalysis are beyond the scope of this document.
-
-
-
-
-
-
-Jansen                    Expires July 5, 2006                  [Page 4]
-
-Internet-Draft       RSA/SHA-256 DNSKEYs and RRSIGS         January 2006
-
-
-7.  Acknowledgments
-
-   This document is a minor extension to RFC4034 [2].  Also, we try to
-   follow the documents RFC3110 [6] and draft-ietf-dnsext-ds-sha256.txt
-   [8] for consistency.  The authors of and contributors to these
-   documents are gratefully acknowledged for their hard work.
-
-   The following people provided additional feedback and text: Jaap
-   Akkerhuis, Miek Gieben and Wouter Wijngaards.
-
-
-8.  References
-
-8.1.  Normative References
-
-   [1]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "DNS Security Introduction and Requirements", RFC 4033,
-        March 2005.
-
-   [2]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Resource Records for the DNS Security Extensions", RFC 4034,
-        March 2005.
-
-   [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Protocol Modifications for the DNS Security Extensions",
-        RFC 4035, March 2005.
-
-   [4]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards
-        (PKCS) #1: RSA Cryptography Specifications Version 2.1",
-        RFC 3447, February 2003.
-
-   [5]  National Institute of Standards and Technology, "Secure Hash
-        Standard", FIPS PUB 180-2, August 2002.
-
-   [6]  Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name
-        System (DNS)", RFC 3110, May 2001.
-
-8.2.  Informative References
-
-   [7]  Schneier, B., "Applied Cryptography Second Edition: protocols,
-        algorithms, and source code in C", Wiley and Sons , ISBN 0-471-
-        11709-9, 1996.
-
-   [8]  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS)
-        Resource Records (RRs)", Work in Progress Feb 2006.
-
-
-
-
-
-
-Jansen                    Expires July 5, 2006                  [Page 5]
-
-Internet-Draft       RSA/SHA-256 DNSKEYs and RRSIGS         January 2006
-
-
-Author's Address
-
-   Jelte Jansen
-   NLnet Labs
-   Kruislaan 419
-   Amsterdam  1098VA
-   NL
-
-   Email: jelte@NLnetLabs.nl
-   URI:   http://www.nlnetlabs.nl/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jansen                    Expires July 5, 2006                  [Page 6]
-
-Internet-Draft       RSA/SHA-256 DNSKEYs and RRSIGS         January 2006
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Jansen                    Expires July 5, 2006                  [Page 7]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt
deleted file mode 100644
index dd8cbf0..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt
+++ /dev/null
@@ -1,839 +0,0 @@
-
-DNS Extensions Working Group                                   R. Arends
-Internet-Draft                                      Telematica Instituut
-Expires: August 25, 2005                                         P. Koch
-                                                                DENIC eG
-                                                             J. Schlyter
-                                                                  NIC-SE
-                                                       February 21, 2005
-
-
-                Evaluating DNSSEC Transition Mechanisms
-                 draft-ietf-dnsext-dnssec-trans-02.txt
-
-Status of this Memo
-
-   This document is an Internet-Draft and is subject to all provisions
-   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
-   author represents that any applicable patent or other IPR claims of
-   which he or she is aware have been or will be disclosed, and any of
-   which he or she become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as
-   Internet-Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on August 25, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document collects and summarizes different proposals for
-   alternative and additional strategies for authenticated denial in DNS
-   responses, evaluates these proposals and gives a recommendation for a
-
-
-
-Arends, et al.           Expires August 25, 2005                [Page 1]
-
-Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
-
-
-   way forward.
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Transition Mechanisms  . . . . . . . . . . . . . . . . . . . .  3
-     2.1   Mechanisms With Need of Updating DNSSEC-bis  . . . . . . .  4
-       2.1.1   Dynamic NSEC Synthesis . . . . . . . . . . . . . . . .  4
-       2.1.2   Add Versioning/Subtyping to Current NSEC . . . . . . .  5
-       2.1.3   Type Bit Map NSEC Indicator  . . . . . . . . . . . . .  6
-       2.1.4   New Apex Type  . . . . . . . . . . . . . . . . . . . .  6
-       2.1.5   NSEC White Lies  . . . . . . . . . . . . . . . . . . .  7
-       2.1.6   NSEC Optional via DNSSKEY Flag . . . . . . . . . . . .  8
-       2.1.7   New Answer Pseudo RR Type  . . . . . . . . . . . . . .  9
-       2.1.8   SIG(0) Based Authenticated Denial  . . . . . . . . . .  9
-     2.2   Mechanisms Without Need of Updating DNSSEC-bis . . . . . . 10
-       2.2.1   Partial Type-code and Signal Rollover  . . . . . . . . 10
-       2.2.2   A Complete Type-code and Signal Rollover . . . . . . . 11
-       2.2.3   Unknown Algorithm in RRSIG . . . . . . . . . . . . . . 11
-   3.  Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 12
-   4.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
-   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
-     5.1   Normative References . . . . . . . . . . . . . . . . . . . 13
-     5.2   Informative References . . . . . . . . . . . . . . . . . . 13
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
-       Intellectual Property and Copyright Statements . . . . . . . . 15
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.           Expires August 25, 2005                [Page 2]
-
-Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
-
-
-1.  Introduction
-
-   This report shall document the process of dealing with the NSEC
-   walking problem late in the Last Call for
-   [I-D.ietf-dnsext-dnssec-intro, I-D.ietf-dnsext-dnssec-protocol,
-   I-D.ietf-dnsext-dnssec-records].  It preserves some of the discussion
-   that took place in the DNSEXT WG during the first half of June 2004
-   as well as some additional ideas that came up subsequently.
-
-   This is an edited excerpt of the chairs' mail to the WG:
-      The working group consents on not including NSEC-alt in the
-      DNSSEC-bis documents.  The working group considers to take up
-      "prevention of zone enumeration" as a work item.
-      There may be multiple mechanisms to allow for co-existence with
-      DNSSEC-bis.  The chairs allow the working group a little over a
-      week (up to June 12, 2004) to come to consensus on a possible
-      modification to the document to enable gentle rollover.  If that
-      consensus cannot be reached the DNSSEC-bis documents will go out
-      as-is.
-
-   To ease the process of getting consensus, a summary of the proposed
-   solutions and analysis of the pros and cons were written during the
-   weekend.
-
-   This summary includes:
-
-      An inventory of the proposed mechanisms to make a transition to
-      future work on authenticated denial of existence.
-      List the known Pros and Cons, possibly provide new arguments, and
-      possible security considerations of these mechanisms.
-      Provide a recommendation on a way forward that is least disruptive
-      to the DNSSEC-bis specifications as they stand and keep an open
-      path to other methods for authenticated denial of existence.
-
-   The descriptions of the proposals in this document are coarse and do
-   not cover every detail necessary for implementation.  In any case,
-   documentation and further study is needed before implementaion and/or
-   deployment, including those which seem to be solely operational in
-   nature.
-
-2.  Transition Mechanisms
-
-   In the light of recent discussions and past proposals, we have found
-   several ways to allow for transition to future expansion of
-   authenticated denial.  We tried to illuminate the paths and pitfalls
-   in these ways forward.  Some proposals lead to a versioning of
-   DNSSEC, where DNSSEC-bis may co-exist with DNSSEC-ter, other
-   proposals are 'clean' but may cause delay, while again others may be
-
-
-
-Arends, et al.           Expires August 25, 2005                [Page 3]
-
-Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
-
-
-   plain hacks.
-
-   Some paths do not introduce versioning, and might require the current
-   DNSSEC-bis documents to be fully updated to allow for extensions to
-   authenticated denial mechanisms.  Other paths introduce versioning
-   and do not (or minimally) require DNSSEC-bis documents to be updated,
-   allowing DNSSEC-bis to be deployed, while future versions can be
-   drafted independent from or partially depending on DNSSEC-bis.
-
-2.1  Mechanisms With Need of Updating DNSSEC-bis
-
-   Mechanisms in this category demand updates to the DNSSEC-bis document
-   set.
-
-2.1.1  Dynamic NSEC Synthesis
-
-   This proposal assumes that NSEC RRs and the authenticating RRSIG will
-   be generated dynamically to just cover the (non existent) query name.
-   The owner name is (the) one preceding the name queried for, the Next
-   Owner Name Field has the value of the Query Name Field + 1 (first
-   successor in canonical ordering).  A separate key (the normal ZSK or
-   a separate ZSK per authoritative server) would be used for RRSIGs on
-   NSEC RRs.  This is a defense against enumeration, though it has the
-   presumption of online signing.
-
-2.1.1.1  Coexistence and Migration
-
-   There is no change in interpretation other then that the next owner
-   name might or might not exist.
-
-2.1.1.2  Limitations
-
-   This introduces an unbalanced cost between query and response
-   generation due to dynamic generation of signatures.
-
-2.1.1.3  Amendments to DNSSEC-bis
-
-   The current DNSSEC-bis documents might need to be updated to indicate
-   that the next owner name might not be an existing name in the zone.
-   This is not a real change to the spec since implementers have been
-   warned not to synthesize with previously cached NSEC records.  A
-   specific bit to identify the dynamic signature generating key might
-   be useful as well, to prevent it from being used to fake positive
-   data.
-
-2.1.1.4  Cons
-
-   Unbalanced cost is a ground for DDoS.  Though this protects against
-
-
-
-Arends, et al.           Expires August 25, 2005                [Page 4]
-
-Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
-
-
-   enumeration, it is not really a path for versioning.
-
-2.1.1.5  Pros
-
-   Hardly any amendments to DNSSEC-bis.
-
-2.1.2  Add Versioning/Subtyping to Current NSEC
-
-   This proposal introduces versioning for the NSEC RR type (a.k.a.
-   subtyping) by adding a (one octet) version field to the NSEC RDATA.
-   Version number 0 is assigned to the current (DNSSEC-bis) meaning,
-   making this an 'Must Be Zero' (MBZ) for the to be published docset.
-
-2.1.2.1  Coexistence and Migration
-
-   Since the versioning is done inside the NSEC RR, different versions
-   may coexist.  However, depending on future methods, that may or may
-   not be useful inside a single zone.  Resolvers cannot ask for
-   specific NSEC versions but may be able to indicate version support by
-   means of a to be defined EDNS option bit.
-
-2.1.2.2  Limitations
-
-   There are no technical limitations, though it will cause delay to
-   allow testing of the (currently unknown) new NSEC interpretation.
-
-   Since the versioning and signaling is done inside the NSEC RR, future
-   methods will likely be restricted to a single RR type authenticated
-   denial (as opposed to e.g.  NSEC-alt, which currently proposes three
-   RR types).
-
-2.1.2.3  Amendments to DNSSEC-bis
-
-   Full Update of the current DNSSEC-bis documents to provide for new
-   fields in NSEC, while specifying behavior in case of unknown field
-   values.
-
-2.1.2.4  Cons
-
-   Though this is a clean and clear path without versioning DNSSEC, it
-   takes some time to design, gain consensus, update the current
-   dnssec-bis document, test and implement a new authenticated denial
-   record.
-
-2.1.2.5  Pros
-
-   Does not introduce an iteration to DNSSEC while providing a clear and
-   clean migration strategy.
-
-
-
-Arends, et al.           Expires August 25, 2005                [Page 5]
-
-Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
-
-
-2.1.3  Type Bit Map NSEC Indicator
-
-   Bits in the type-bit-map are reused or allocated to signify the
-   interpretation of NSEC.
-
-   This proposal assumes that future extensions make use of the existing
-   NSEC RDATA syntax, while it may need to change the interpretation of
-   the RDATA or introduce an alternative denial mechanism, invoked by
-   the specific type-bit-map-bits.
-
-2.1.3.1  Coexistence and migration
-
-   Old and new NSEC meaning could coexist, depending how the signaling
-   would be defined.  The bits for NXT, NSEC, RRSIG or other outdated RR
-   types are available  as well as those covering meta/query types or
-   types to be specifically allocated.
-
-2.1.3.2  Limitations
-
-   This mechanism uses an NSEC field that was not designed for that
-   purpose.  Similar methods were discussed during the Opt-In discussion
-   and the Silly-State discussion.
-
-2.1.3.3  Amendments to DNSSEC-bis
-
-   The specific type-bit-map-bits must be allocated and they need to be
-   specified as 'Must Be Zero' (MBZ) when used for standard (dnssec-bis)
-   interpretation.  Also, behaviour of the resolver and validator must
-   be documented in case unknown values are encountered for the MBZ
-   field.  Currently the protocol document specifies that the validator
-   MUST ignore the setting of the NSEC and the RRSIG bits, while other
-   bits are only used for the specific purpose of the type-bit-map field
-
-2.1.3.4  Cons
-
-   The type-bit-map was not designed for this purpose.  It is a
-   straightforward hack.  Text in protocol section 5.4 was put in
-   specially to defend against this usage.
-
-2.1.3.5  Pros
-
-   No change needed to the on-the-wire protocol as specified in the
-   current docset.
-
-2.1.4  New Apex Type
-
-   This introduces a new Apex type (parallel to the zone's SOA)
-   indicating the DNSSEC version (or authenticated denial) used in or
-
-
-
-Arends, et al.           Expires August 25, 2005                [Page 6]
-
-Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
-
-
-   for this zone.
-
-2.1.4.1  Coexistence and Migration
-
-   Depending on the design of this new RR type multiple denial
-   mechanisms may coexist in a zone.  Old validators will not understand
-   and thus ignore the new type, so interpretation of the new NSEC
-   scheme may fail, negative responses may appear 'bogus'.
-
-2.1.4.2  Limitations
-
-   A record of this kind is likely to carry additional
-   feature/versioning indications unrelated to the current question of
-   authenticated denial.
-
-2.1.4.3  Amendments to DNSSEC-bis
-
-   The current DNSSEC-bis documents need to be updated to indicate that
-   the absence of this type indicates dnssec-bis, and that the (mere)
-   presence of this type indicated unknown versions.
-
-2.1.4.4  Cons
-
-   The only other 'zone' or 'apex' record is the SOA record.  Though
-   this proposal is not new, it is yet unknown how it might fulfill
-   authenticated denial extensions.  This new RR type would only provide
-   for a generalized signaling mechanism, not the new authenticated
-   denial scheme.  Since it is likely to be general in nature, due to
-   this generality consensus is not to be reached soon.
-
-2.1.4.5  Pros
-
-   This approach would allow for a lot of other per zone information to
-   be transported or signaled to both (slave) servers and resolvers.
-
-2.1.5  NSEC White Lies
-
-   This proposal disables one part of NSEC (the pointer part) by means
-   of a special target (root, apex, owner, ...), leaving intact only the
-   ability to authenticate denial of existence of RR sets, not denial of
-   existence of domain names (NXDOMAIN).  It may be necessary to have
-   one working NSEC to prove the absence of a wildcard.
-
-2.1.5.1  Coexistence and Migration
-
-   The NSEC target can be specified per RR, so standard NSEC and 'white
-   lie' NSEC can coexist in a zone.  There is no need for migration
-   because no versioning is introduced or intended.
-
-
-
-Arends, et al.           Expires August 25, 2005                [Page 7]
-
-Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
-
-
-2.1.5.2  Limitations
-
-   This proposal breaks the protocol and is applicable to certain types
-   of zones only (no wildcard, no deep names, delegation only).  Most of
-   the burden is put on the resolver side and operational consequences
-   are yet to be studied.
-
-2.1.5.3  Amendments to DNSSEC-bis
-
-   The current DNSSEC-bis documents need to be updated to indicate that
-   the NXDOMAIN responses may be insecure.
-
-2.1.5.4  Cons
-
-   Strictly speaking this breaks the protocol and doesn't fully fulfill
-   the requirements for authenticated denial of existence.  Security
-   implications need to be carefully documented: search path problems
-   (forged denial of existence may lead to wrong expansion of non-FQDNs
-   [RFC1535]) and replay attacks to deny existence of records.
-
-2.1.5.5  Pros
-
-   Hardly any amendments to DNSSEC-bis.  Operational "trick" that is
-   available anyway.
-
-2.1.6  NSEC Optional via DNSSKEY Flag
-
-   A new DNSKEY may be defined to declare NSEC optional per zone.
-
-2.1.6.1  Coexistence and Migration
-
-   Current resolvers/validators will not understand the Flag bit and
-   will have to treat negative responses as bogus.  Otherwise, no
-   migration path is needed since NSEC is simply turned off.
-
-2.1.6.2  Limitations
-
-   NSEC can only be made completely optional at the cost of being unable
-   to prove unsecure delegations (absence of a DS RR [RFC3658]).  A next
-   to this approach would just disable authenticated denial for
-   non-existence of nodes.
-
-2.1.6.3  Amendments to DNSSEC-bis
-
-   New DNSKEY Flag to be defined.  Resolver/Validator behaviour needs to
-   be specified in the light of absence of authenticated denial.
-
-
-
-
-
-Arends, et al.           Expires August 25, 2005                [Page 8]
-
-Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
-
-
-2.1.6.4  Cons
-
-   Doesn't fully meet requirements.  Operational consequences to be
-   studied.
-
-2.1.6.5  Pros
-
-   Official version of the "trick" presented in (8).  Operational
-   problems can be addressed during future work on validators.
-
-2.1.7  New Answer Pseudo RR Type
-
-   A new pseudo RR type may be defined that will be dynamically created
-   (and signed) by the responding authoritative server.  The RR in the
-   response will cover the QNAME, QCLASS and QTYPE and will authenticate
-   both denial of existence of name (NXDOMAIN) or RRset.
-
-2.1.7.1  Coexistence and Migration
-
-   Current resolvers/validators will not understand the pseudo RR and
-   will thus not be able to process negative responses so testified.  A
-   signaling or solicitation method would have to be specified.
-
-2.1.7.2  Limitations
-
-   This method can only be used with online keys and online signing
-   capacity.
-
-2.1.7.3  Amendments to DNSSEC-bis
-
-   Signaling method needs to be defined.
-
-2.1.7.4  Cons
-
-   Keys have to be held and processed online with all security
-   implications.  An additional flag for those keys identifying them as
-   online or negative answer only keys should be considered.
-
-2.1.7.5  Pros
-
-   Expands DNSSEC authentication to the RCODE.
-
-2.1.8  SIG(0) Based Authenticated Denial
-
-
-2.1.8.1  Coexistence and Migration
-
-
-
-
-
-Arends, et al.           Expires August 25, 2005                [Page 9]
-
-Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
-
-
-2.1.8.2  Limitations
-
-
-2.1.8.3  Amendments to DNSSEC-bis
-
-
-2.1.8.4  Cons
-
-
-2.1.8.5  Pros
-
-
-2.2  Mechanisms Without Need of Updating DNSSEC-bis
-
-2.2.1  Partial Type-code and Signal Rollover
-
-   Carefully crafted type code/signal rollover to define a new
-   authenticated denial space that extends/replaces DNSSEC-bis
-   authenticated denial space.  This particular path is illuminated by
-   Paul Vixie in a Message-Id <20040602070859.0F50913951@sa.vix.com>
-   posted to <namedroppers@ops.ietf.org> 2004-06-02.
-
-2.2.1.1  Coexistence and Migration
-
-   To protect the current resolver for future versions, a new DNSSEC-OK
-   bit must be allocated to make clear it does or does not understand
-   the future version.  Also, a new DS type needs to be allocated to
-   allow differentiation between a current signed delegation and a
-   'future' signed delegation.  Also, current NSEC needs to be rolled
-   into a new authenticated denial type.
-
-2.2.1.2  Limitations
-
-   None.
-
-2.2.1.3  Amendments to DNSSEC-bis
-
-   None.
-
-2.2.1.4  Cons
-
-   It is cumbersome to carefully craft an TCR that 'just fits'.  The
-   DNSSEC-bis protocol has many 'borderline' cases that needs special
-   consideration.  It might be easier to do a full TCR, since a few of
-   the types and signals need upgrading anyway.
-
-
-
-
-
-
-Arends, et al.           Expires August 25, 2005               [Page 10]
-
-Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
-
-
-2.2.1.5  Pros
-
-   Graceful adoption of future versions of NSEC, while there are no
-   amendments to DNSSEC-bis.
-
-2.2.2  A Complete Type-code and Signal Rollover
-
-   A new DNSSEC space is defined which can exist independent of current
-   DNSSEC-bis space.
-
-   This proposal assumes that all current DNSSEC type-codes
-   (RRSIG/DNSKEY/NSEC/DS) and signals (DNSSEC-OK) are not used in any
-   future versions of DNSSEC.  Any future version of DNSSEC has its own
-   types to allow for keys, signatures, authenticated denial, etcetera.
-
-2.2.2.1  Coexistence and Migration
-
-   Both spaces can co-exist.  They can be made completely orthogonal.
-
-2.2.2.2  Limitations
-
-   None.
-
-2.2.2.3  Amendments to DNSSEC-bis
-
-   None.
-
-2.2.2.4  Cons
-
-   With this path we abandon the current DNSSEC-bis.  Though it is easy
-   to role specific well-known and well-tested parts into the re-write,
-   once deployment has started this path is very expensive for
-   implementers, registries, registrars and registrants as well as
-   resolvers/users.  A TCR is not to be expected to occur frequently, so
-   while a next generation authenticated denial may be enabled by a TCR,
-   it is likely that that TCR will only be agreed upon if it serves a
-   whole basket of changes or additions.  A quick introduction of
-   NSEC-ng should not be expected from this path.
-
-2.2.2.5  Pros
-
-   No amendments/changes to current DNSSEC-bis docset needed.  It is
-   always there as last resort.
-
-2.2.3  Unknown Algorithm in RRSIG
-
-   This proposal assumes that future extensions make use of the existing
-   NSEC RDATA syntax, while it may need to change the interpretation of
-
-
-
-Arends, et al.           Expires August 25, 2005               [Page 11]
-
-Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
-
-
-   the RDATA or introduce an alternative denial mechanism, invoked by
-   the specific unknown signing algorithm.  The different interpretation
-   would be signaled by use of different signature algorithms in the
-   RRSIG records covering the NSEC RRs.
-
-   When an entire zone is signed with a single unknown algorithm, it
-   will cause implementations that follow current dnssec-bis documents
-   to treat individual RRsets as unsigned.
-
-2.2.3.1  Coexistence and migration
-
-   Old and new NSEC RDATA interpretation or known and unknown Signatures
-   can NOT coexist in a zone since signatures cover complete (NSEC)
-   RRSets.
-
-2.2.3.2  Limitations
-
-   Validating resolvers agnostic of new interpretation will treat the
-   NSEC RRset as "not signed".  This affects wildcard and non-existence
-   proof, as well as proof for (un)secured delegations.  Also, all
-   positive signatures (RRSIGs on RRSets other than DS, NSEC) appear
-   insecure/bogus to an old validator.
-
-   The algorithm version space is split for each future version of
-   DNSSEC.  Violation of the 'modular components' concept.  We use the
-   'validator' to protect the 'resolver' from unknown interpretations.
-
-2.2.3.3  Amendments to DNSSEC-bis
-
-   None.
-
-2.2.3.4  Cons
-
-   The algorithm field was not designed for this purpose.  This is a
-   straightforward hack.
-
-2.2.3.5  Pros
-
-   No amendments/changes to current DNSSEC-bis docset needed.
-
-3.  Recommendation
-
-   The authors recommend that the working group commits to and starts
-   work on a partial TCR, allowing graceful transition towards a future
-   version of NSEC.  Meanwhile, to accomodate the need for an
-   immediately, temporary, solution against zone-traversal, we recommend
-   On-Demand NSEC synthesis.
-
-
-
-
-Arends, et al.           Expires August 25, 2005               [Page 12]
-
-Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
-
-
-   This approach does not require any mandatory changes to DNSSEC-bis,
-   does not violate the protocol and fulfills the requirements.  As a
-   side effect, it moves the cost of implementation and deployment to
-   the users (zone owners) of this mechanism.
-
-4.  Acknowledgements
-
-   The authors would like to thank Sam Weiler and Mark Andrews for their
-   input and constructive comments.
-
-5.  References
-
-5.1  Normative References
-
-   [I-D.ietf-dnsext-dnssec-intro]
-              Arends, R., Austein, R., Massey, D., Larson, M. and S.
-              Rose, "DNS Security Introduction and Requirements",
-              Internet-Draft draft-ietf-dnsext-dnssec-intro-13, October
-              2004.
-
-   [I-D.ietf-dnsext-dnssec-protocol]
-              Arends, R., "Protocol Modifications for the DNS Security
-              Extensions",
-              Internet-Draft draft-ietf-dnsext-dnssec-protocol-09,
-              October 2004.
-
-   [I-D.ietf-dnsext-dnssec-records]
-              Arends, R., "Resource Records for the DNS Security
-              Extensions",
-              Internet-Draft draft-ietf-dnsext-dnssec-records-11,
-              October 2004.
-
-   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
-              STD 13, RFC 1034, November 1987.
-
-   [RFC1035]  Mockapetris, P., "Domain names - implementation and
-              specification", STD 13, RFC 1035, November 1987.
-
-   [RFC2931]  Eastlake, D., "DNS Request and Transaction Signatures (
-              SIG(0)s)", RFC 2931, September 2000.
-
-5.2  Informative References
-
-   [RFC1535]  Gavron, E., "A Security Problem and Proposed Correction
-              With Widely Deployed DNS Software", RFC 1535, October
-              1993.
-
-   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
-
-
-
-Arends, et al.           Expires August 25, 2005               [Page 13]
-
-Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
-
-
-              RFC 2535, March 1999.
-
-   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
-              June 1999.
-
-   [RFC3658]  Gudmundsson, O., "Delegation Signer (DS) Resource Record
-              (RR)", RFC 3658, December 2003.
-
-
-Authors' Addresses
-
-   Roy Arends
-   Telematica Instituut
-   Brouwerijstraat 1
-   Enschede  7523 XC
-   The Netherlands
-
-   Phone: +31 53 4850485
-   Email: roy.arends@telin.nl
-
-
-   Peter Koch
-   DENIC eG
-   Wiesenh"uttenplatz 26
-   Frankfurt  60329
-   Germany
-
-   Phone: +49 69 27235 0
-   Email: pk@DENIC.DE
-
-
-   Jakob Schlyter
-   NIC-SE
-   Box 5774
-   Stockholm  SE-114 87
-   Sweden
-
-   Email: jakob@nic.se
-   URI:   http://www.nic.se/
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.           Expires August 25, 2005               [Page 14]
-
-Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Arends, et al.           Expires August 25, 2005               [Page 15]
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-ds-sha256-05.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-ds-sha256-05.txt
deleted file mode 100644
index 2460cb6..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-ds-sha256-05.txt
+++ /dev/null
@@ -1,504 +0,0 @@
-
-
-
-Network Working Group                                        W. Hardaker
-Internet-Draft                                                    Sparta
-Expires: August 25, 2006                               February 21, 2006
-
-
- Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
-                   draft-ietf-dnsext-ds-sha256-05.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on August 25, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document specifies how to use the SHA-256 digest type in DNS
-   Delegation Signer (DS) Resource Records (RRs).  DS records, when
-   stored in a parent zone, point to key signing DNSKEY key(s) in a
-   child zone.
-
-
-
-
-
-
-
-
-Hardaker                 Expires August 25, 2006                [Page 1]
-
-Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
-
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
-   2.  Implementing the SHA-256 algorithm for DS record support  . . . 3
-     2.1.  DS record field values  . . . . . . . . . . . . . . . . . . 3
-     2.2.  DS Record with SHA-256 Wire Format  . . . . . . . . . . . . 3
-     2.3.  Example DS Record Using SHA-256 . . . . . . . . . . . . . . 4
-   3.  Implementation Requirements . . . . . . . . . . . . . . . . . . 4
-   4.  Deployment Considerations . . . . . . . . . . . . . . . . . . . 4
-   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
-   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
-     6.1.  Potential Digest Type Downgrade Attacks . . . . . . . . . . 5
-     6.2.  SHA-1 vs SHA-256 Considerations for DS Records  . . . . . . 6
-   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
-   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
-     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
-     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
-   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 8
-   Intellectual Property and Copyright Statements  . . . . . . . . . . 9
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardaker                 Expires August 25, 2006                [Page 2]
-
-Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
-
-
-1.  Introduction
-
-   The DNSSEC [RFC4033] [RFC4034] [RFC4035] DS RR is published in parent
-   zones to distribute a cryptographic digest of a child's Key Signing
-   Key (KSK) DNSKEY RR.  The DS RRset is signed by at least one of the
-   parent zone's private zone data signing keys for each algorithm in
-   use by the parent.  Each signature is published in an RRSIG resource
-   record, owned by the same domain as the DS RRset and with a type
-   covered of DS.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-2.  Implementing the SHA-256 algorithm for DS record support
-
-   This document specifies that the digest type code [XXX: To be
-   assigned by IANA; likely 2] is to be assigned to SHA-256 [SHA256]
-   [SHA256CODE] for use within DS records.  The results of the digest
-   algorithm MUST NOT be truncated and the entire 32 byte digest result
-   is to be published in the DS record.
-
-2.1.  DS record field values
-
-   Using the SHA-256 digest algorithm within a DS record will make use
-   of the following DS-record fields:
-
-   Digest type: [XXX: To be assigned by IANA; likely 2]
-
-   Digest: A SHA-256 bit digest value calculated by using the following
-      formula ("|" denotes concatenation).  The resulting value is not
-      truncated and the entire 32 byte result is to used in the
-      resulting DS record and related calculations.
-
-        digest = SHA_256(DNSKEY owner name | DNSKEY RDATA)
-
-      where DNSKEY RDATA is defined by [RFC4034] as:
-
-        DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key
-
-   The Key Tag field and Algorithm fields remain unchanged by this
-   document and are specified in the [RFC4034] specification.
-
-2.2.  DS Record with SHA-256 Wire Format
-
-   The resulting on-the-wire format for the resulting DS record will be
-   [XXX: IANA assignment should replace the 2 below]:
-
-
-
-Hardaker                 Expires August 25, 2006                [Page 3]
-
-Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
-
-
-                           1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |           Key Tag             |  Algorithm    | DigestType=2  |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      /                                                               /
-      /            Digest  (length for SHA-256 is 32 bytes)           /
-      /                                                               /
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
-
-2.3.  Example DS Record Using SHA-256
-
-   The following is an example DNSKEY and matching DS record.  This
-   DNSKEY record comes from the example DNSKEY/DS records found in
-   section 5.4 of [RFC4034].
-
-   The DNSKEY record:
-
-   dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
-                                                fwJr1AYtsmx3TGkJaNXVbfi/
-                                                2pHm822aJ5iI9BMzNXxeYCmZ
-                                                DRD99WYwYqUSdjMmmAphXdvx
-                                                egXd/M5+X7OrzKBaMbCVdFLU
-                                                Uh6DhweJBjEVv5f2wwjM9Xzc
-                                                nOf+EPbtG9DMBmADjFDc2w/r
-                                                ljwvFw==
-                                                ) ;  key id = 60485
-
-   The resulting DS record covering the above DNSKEY record using a SHA-
-   256 digest: [RFC Editor: please replace XXX with the assigned digest
-   type (likely 2):]
-
-   dskey.example.com. 86400 IN DS 60485 5 XXX ( D4B7D520E7BB5F0F67674A0C
-                                                CEB1E3E0614B93C4F9E99B83
-                                                83F6A1E4469DA50A )
-
-
-3.  Implementation Requirements
-
-   Implementations MUST support the use of the SHA-256 algorithm in DS
-   RRs.  Validator implementations SHOULD ignore DS RRs containing SHA-1
-   digests if DS RRs with SHA-256 digests are present in the DS RRset.
-
-
-4.  Deployment Considerations
-
-   If a validator does not support the SHA-256 digest type and no other
-   DS RR exists in a zone's DS RRset with a supported digest type, then
-
-
-
-Hardaker                 Expires August 25, 2006                [Page 4]
-
-Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
-
-
-   the validator has no supported authentication path leading from the
-   parent to the child.  The resolver should treat this case as it would
-   the case of an authenticated NSEC RRset proving that no DS RRset
-   exists, as described in [RFC4035], section 5.2.
-
-   Because zone administrators can not control the deployment speed of
-   support for SHA-256 in validators that may be referencing any of
-   their zones, zone operators should consider deploying both SHA-1 and
-   SHA-256 based DS records.  This should be done for every DNSKEY for
-   which DS records are being generated.  Whether to make use of both
-   digest types and for how long is a policy decision that extends
-   beyond the scope of this document.
-
-
-5.  IANA Considerations
-
-   Only one IANA action is required by this document:
-
-   The Digest Type to be used for supporting SHA-256 within DS records
-   needs to be assigned by IANA.  This document requests that the Digest
-   Type value of 2 be assigned to the SHA-256 digest algorithm.
-
-   At the time of this writing, the current digest types assigned for
-   use in DS records are as follows:
-
-      VALUE     Digest Type          Status
-        0       Reserved                -
-        1       SHA-1                MANDATORY
-        2       SHA-256              MANDATORY
-      3-255    Unassigned               -
-
-
-6.  Security Considerations
-
-6.1.  Potential Digest Type Downgrade Attacks
-
-   A downgrade attack from a stronger digest type to a weaker one is
-   possible if all of the following are true:
-
-   o  A zone includes multiple DS records for a given child's DNSKEY,
-      each of which use a different digest type.
-
-   o  A validator accepts a weaker digest even if a stronger one is
-      present but invalid.
-
-   For example, if the following conditions are all true:
-
-
-
-
-
-Hardaker                 Expires August 25, 2006                [Page 5]
-
-Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
-
-
-   o  Both SHA-1 and SHA-256 based digests are published in DS records
-      within a parent zone for a given child zone's DNSKEY.
-
-   o  The DS record with the SHA-1 digest matches the digest computed
-      using the child zone's DNSKEY.
-
-   o  The DS record with the SHA-256 digest fails to match the digest
-      computed using the child zone's DNSKEY.
-
-   Then if the validator accepts the above situation as secure then this
-   can be used as a downgrade attack since the stronger SHA-256 digest
-   is ignored.
-
-6.2.  SHA-1 vs SHA-256 Considerations for DS Records
-
-   Users of DNSSEC are encouraged to deploy SHA-256 as soon as software
-   implementations allow for it.  SHA-256 is widely believed to be more
-   resilient to attack than SHA-1, and confidence in SHA-1's strength is
-   being eroded by recently-announced attacks.  Regardless of whether or
-   not the attacks on SHA-1 will affect DNSSEC, it is believed (at the
-   time of this writing) that SHA-256 is the better choice for use in DS
-   records.
-
-   At the time of this publication, the SHA-256 digest algorithm is
-   considered sufficiently strong for the immediate future.  It is also
-   considered sufficient for use in DNSSEC DS RRs for the immediate
-   future.  However, future published attacks may weaken the usability
-   of this algorithm within the DS RRs.  It is beyond the scope of this
-   document to speculate extensively on the cryptographic strength of
-   the SHA-256 digest algorithm.
-
-   Likewise, it is also beyond the scope of this document to specify
-   whether or for how long SHA-1 based DS records should be
-   simultaneously published alongside SHA-256 based DS records.
-
-
-7.  Acknowledgments
-
-   This document is a minor extension to the existing DNSSEC documents
-   and those authors are gratefully appreciated for the hard work that
-   went into the base documents.
-
-   The following people contributed to portions of this document in some
-   fashion: Mark Andrews, Roy Arends, Olafur Gudmundsson, Paul Hoffman,
-   Olaf M. Kolkman, Edward Lewis, Scott Rose, Stuart E. Schechter, Sam
-   Weiler.
-
-
-
-
-
-Hardaker                 Expires August 25, 2006                [Page 6]
-
-Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
-
-
-8.  References
-
-8.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "DNS Security Introduction and Requirements",
-              RFC 4033, March 2005.
-
-   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Resource Records for the DNS Security Extensions",
-              RFC 4034, March 2005.
-
-   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Protocol Modifications for the DNS Security
-              Extensions", RFC 4035, March 2005.
-
-   [SHA256]   National Institute of Standards and Technology, "Secure
-              Hash Algorithm. NIST FIPS 180-2", August 2002.
-
-8.2.  Informative References
-
-   [SHA256CODE]
-              Eastlake, D., "US Secure Hash Algorithms (SHA)",
-              June 2005.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardaker                 Expires August 25, 2006                [Page 7]
-
-Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
-
-
-Author's Address
-
-   Wes Hardaker
-   Sparta
-   P.O. Box 382
-   Davis, CA  95617
-   US
-
-   Email: hardaker@tislabs.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardaker                 Expires August 25, 2006                [Page 8]
-
-Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Hardaker                 Expires August 25, 2006                [Page 9]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-ecc-key-07.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-ecc-key-07.txt
deleted file mode 100644
index 2cdcdb1..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-ecc-key-07.txt
+++ /dev/null
@@ -1,928 +0,0 @@
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-Expires: January 2006                                          July 2005
-
-
-
-                     Elliptic Curve KEYs in the DNS
-                     -------- ----- ---- -- --- ---
-                   <draft-ietf-dnsext-ecc-key-07.txt>
-
-                         Richard C. Schroeppel
-                          Donald Eastlake 3rd
-
-
-Status of This Document
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   This draft is intended to be become a Proposed Standard RFC.
-   Distribution of this document is unlimited. Comments should be sent
-   to the DNS mailing list <namedroppers@ops.ietf.org>.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than a "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/1id-abstracts.html
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-
-Abstract
-
-   The standard method for storing elliptic curve cryptographic keys and
-   signatures in the Domain Name System is specified.
-
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005). All Rights Reserved.
-
-
-
-
-
-R. Schroeppel, et al                                            [Page 1]
-
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-
-
-Acknowledgement
-
-   The assistance of Hilarie K. Orman in the production of this document
-   is greatfully acknowledged.
-
-
-
-Table of Contents
-
-      Status of This Document....................................1
-      Abstract...................................................1
-      Copyright Notice...........................................1
-
-      Acknowledgement............................................2
-      Table of Contents..........................................2
-
-      1. Introduction............................................3
-      2. Elliptic Curve Data in Resource Records.................3
-      3. The Elliptic Curve Equation.............................9
-      4. How do I Compute Q, G, and Y?..........................10
-      5. Elliptic Curve SIG Resource Records....................11
-      6. Performance Considerations.............................13
-      7. Security Considerations................................13
-      8. IANA Considerations....................................13
-      Copyright and Disclaimer..................................14
-
-      Informational References..................................15
-      Normative Refrences.......................................15
-
-      Author's Addresses........................................16
-      Expiration and File Name..................................16
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-R. Schroeppel, et al                                            [Page 2]
-
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-
-
-1. Introduction
-
-   The Domain Name System (DNS) is the global hierarchical replicated
-   distributed database system for Internet addressing, mail proxy, and
-   other information. The DNS has been extended to include digital
-   signatures and cryptographic keys as described in [RFC 4033, 4034,
-   4035].
-
-   This document describes how to store elliptic curve cryptographic
-   (ECC) keys and signatures in the DNS so they can be used for a
-   variety of security purposes.  Familiarity with ECC cryptography is
-   assumed [Menezes].
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC 2119].
-
-
-
-2. Elliptic Curve Data in Resource Records
-
-   Elliptic curve public keys are stored in the DNS within the RDATA
-   portions of key RRs, such as RRKEY and KEY [RFC 4034] RRs, with the
-   structure shown below.
-
-   The research world continues to work on the issue of which is the
-   best elliptic curve system, which finite field to use, and how to
-   best represent elements in the field.  So, representations are
-   defined for every type of finite field, and every type of elliptic
-   curve.  The reader should be aware that there is a unique finite
-   field with a particular number of elements, but many possible
-   representations of that field and its elements.  If two different
-   representations of a field are given, they are interconvertible with
-   a tedious but practical precomputation, followed by a fast
-   computation for each field element to be converted.  It is perfectly
-   reasonable for an algorithm to work internally with one field
-   representation, and convert to and from a different external
-   representation.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-R. Schroeppel, et al                                            [Page 3]
-
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-
-
-                            1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |S M -FMT- A B Z|
-       +-+-+-+-+-+-+-+-+
-       |       LP      |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |                        P (length determined from LP)       .../
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |       LF      |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |                        F (length determined from LF)       .../
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |             DEG               |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |             DEGH              |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |             DEGI              |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |             DEGJ              |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |             TRDV              |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |S|     LH      |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |                        H (length determined from LH)       .../
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |S|     LK      |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |                        K (length determined from LK)       .../
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |       LQ      |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |                        Q (length determined from LQ)       .../
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |       LA      |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |                        A (length determined from LA)       .../
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |             ALTA              |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |       LB      |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |                        B (length determined from LB)       .../
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |       LC      |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |                        C (length determined from LC)       .../
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |       LG      |
-
-
-R. Schroeppel, et al                                            [Page 4]
-
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-
-
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |                        G (length determined from LG)       .../
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |       LY      |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |                        Y (length determined from LY)       .../
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   SMFMTABZ is a flags octet as follows:
-
-        S = 1 indicates that the remaining 7 bits of the octet selects
-           one of 128 predefined choices of finite field, element
-           representation, elliptic curve, and signature parameters.
-           MFMTABZ are omitted, as are all parameters from LP through G.
-           LY and Y are retained.
-
-        If S = 0, the remaining parameters are as in the picture and
-           described below.
-
-        M determines the type of field underlying the elliptic curve.
-
-        M = 0 if the field is a GF[2^N] field;
-
-        M = 1 if the field is a (mod P) or GF[P^D] field with P>2.
-
-        FMT is a three bit field describing the format of the field
-           representation.
-
-        FMT = 0  for a (mod P) field.
-            > 0  for an extension field, either GF[2^D] or GF[P^D].
-                The degree D of the extension, and the field polynomial
-                must be specified.  The field polynomial is always monic
-                (leading coefficient 1.)
-
-        FMT = 1  The field polynomial is given explicitly; D is implied.
-
-        If FMT >=2, the degree D is given explicitly.
-
-           = 2  The field polynomial is implicit.
-           = 3  The field polynomial is a binomial.  P>2.
-           = 4  The field polynomial is a trinomial.
-           = 5  The field polynomial is the quotient of a trinomial by a
-                short polynomial.  P=2.
-           = 6  The field polynomial is a pentanomial.  P=2.
-
-        Flags A and B apply to the elliptic curve parameters.
-
-
-
-
-
-
-R. Schroeppel, et al                                            [Page 5]
-
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-
-
-        A = 1 When P>=5, the curve parameter A is negated.  If P=2, then
-              A=1 indicates that the A parameter is special.  See the
-              ALTA parameter below, following A.  The combination A=1,
-              P=3 is forbidden.
-
-        B = 1 When P>=5, the curve parameter B is negated.  If P=2 or 3,
-              then B=1 indicates an alternate elliptic curve equation is
-              used.  When P=2 and B=1, an additional curve parameter C
-              is present.
-
-        The Z bit SHOULD be set to zero on creation of an RR and MUST be
-           ignored when processing an RR (when S=0).
-
-   Most of the remaining parameters are present in some formats and
-   absent in others.  The presence or absence of a parameter is
-   determined entirely by the flags.  When a parameter occurs, it is in
-   the order defined by the picture.
-
-   Of the remaining parameters, PFHKQABCGY are variable length.  When
-   present, each is preceded by a one-octet length field as shown in the
-   diagram above.  The length field does not include itself.  The length
-   field may have values from 0 through 110.  The parameter length in
-   octets is determined by a conditional formula: If LL<=64, the
-   parameter length is LL.  If LL>64, the parameter length is 16 times
-   (LL-60).  In some cases, a parameter value of 0 is sensible, and MAY
-   be represented by an LL value of 0, with the data field omitted.  A
-   length value of 0 represents a parameter value of 0, not an absent
-   parameter.  (The data portion occupies 0 space.)  There is no
-   requirement that a parameter be represented in the minimum number of
-   octets; high-order 0 octets are allowed at the front end.  Parameters
-   are always right adjusted, in a field of length defined by LL.  The
-   octet-order is always most-significant first, least-significant last.
-   The parameters H and K may have an optional sign bit stored in the
-   unused high-order bit of their length fields.
-
-   LP defines the length of the prime P.  P must be an odd prime.  The
-   parameters LP,P are present if and only if the flag M=1.  If M=0, the
-   prime is 2.
-
-   LF,F define an explicit field polynomial.  This parameter pair is
-   present only when FMT = 1.  The length of a polynomial coefficient is
-   ceiling(log2 P) bits.  Coefficients are in the numerical range
-   [0,P-1].  The coefficients are packed into fixed-width fields, from
-   higher order to lower order.  All coefficients must be present,
-   including any 0s and also the leading coefficient (which is required
-   to be 1).  The coefficients are right justified into the octet string
-   of length specified by LF, with the low-order "constant" coefficient
-   at the right end.  As a concession to storage efficiency, the higher
-   order bits of the leading coefficient may be elided, discarding high-
-   order 0 octets and reducing LF.  The degree is calculated by
-
-
-R. Schroeppel, et al                                            [Page 6]
-
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-
-
-   determining the bit position of the left most 1-bit in the F data
-   (counting the right most bit as position 0), and dividing by
-   ceiling(log2 P).  The division must be exact, with no remainder.  In
-   this format, all of the other degree and field parameters are
-   omitted.  The next parameters will be LQ,Q.
-
-   If FMT>=2, the degree of the field extension is specified explicitly,
-   usually along with other parameters to define the field polynomial.
-
-   DEG is a two octet field that defines the degree of the field
-   extension.  The finite field will have P^DEG elements.  DEG is
-   present when FMT>=2.
-
-   When FMT=2, the field polynomial is specified implicitly.  No other
-   parameters are required to define the field; the next parameters
-   present will be the LQ,Q pair.  The implicit field poynomial is the
-   lexicographically smallest irreducible (mod P) polynomial of the
-   correct degree.  The ordering of polynomials is by highest-degree
-   coefficients first -- the leading coefficient 1 is most important,
-   and the constant term is least important.  Coefficients are ordered
-   by sign-magnitude: 0 < 1 < -1 < 2 < -2 < ...  The first polynomial of
-   degree D is X^D (which is not irreducible).  The next is X^D+1, which
-   is sometimes irreducible, followed by X^D-1, which isn't.  Assuming
-   odd P, this series continues to X^D - (P-1)/2, and then goes to X^D +
-   X, X^D + X + 1, X^D + X - 1, etc.
-
-   When FMT=3, the field polynomial is a binomial, X^DEG + K.  P must be
-   odd.  The polynomial is determined by the degree and the low order
-   term K.  Of all the field parameters, only the LK,K parameters are
-   present.  The high-order bit of the LK octet stores on optional sign
-   for K; if the sign bit is present, the field polynomial is X^DEG - K.
-
-   When FMT=4, the field polynomial is a trinomial, X^DEG + H*X^DEGH +
-   K.  When P=2, the H and K parameters are implicitly 1, and are
-   omitted from the representation.  Only DEG and DEGH are present; the
-   next parameters are LQ,Q.  When P>2, then LH,H and LK,K are
-   specified.  Either or both of LH, LK may contain a sign bit for its
-   parameter.
-
-   When FMT=5, then P=2 (only).  The field polynomial is the exact
-   quotient of a trinomial divided by a small polynomial, the trinomial
-   divisor.  The small polynomial is right-adjusted in the two octet
-   field TRDV.  DEG specifies the degree of the field.  The degree of
-   TRDV is calculated from the position of the high-order 1 bit.  The
-   trinomial to be divided is X^(DEG+degree(TRDV)) + X^DEGH + 1.  If
-   DEGH is 0, the middle term is omitted from the trinomial.  The
-   quotient must be exact, with no remainder.
-
-   When FMT=6, then P=2 (only).  The field polynomial is a pentanomial,
-   with the degrees of the middle terms given by the three 2-octet
-
-
-R. Schroeppel, et al                                            [Page 7]
-
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-
-
-   values DEGH, DEGI, DEGJ.  The polynomial is X^DEG + X^DEGH + X^DEGI +
-   X^DEGJ + 1.  The values must satisfy the inequality DEG > DEGH > DEGI
-   > DEGJ > 0.
-
-        DEGH, DEGI, DEGJ  are two-octet fields that define the degree of
-           a term in a field polynomial.   DEGH is present when FMT = 4,
-           5, or 6.  DEGI and DEGJ are present only when FMT = 6.
-
-        TRDV is a two-octet right-adjusted binary polynomial of degree <
-           16.  It is present only for FMT=5.
-
-        LH and H define the H parameter, present only when FMT=4 and P
-           is odd.  The high bit of LH is an optional sign bit for H.
-
-        LK and K define the K parameter, present when FMT = 3 or 4, and
-           P is odd.  The high bit of LK is an optional sign bit for K.
-
-   The remaining parameters are concerned with the elliptic curve and
-   the signature algorithm.
-
-        LQ defines the length of the prime Q.  Q is a prime > 2^159.
-
-   In all 5 of the parameter pairs LA+A,LB+B,LC+C,LG+G,LY+Y, the data
-   member of the pair is an element from the finite field defined
-   earlier.  The length field defines a long octet string.  Field
-   elements are represented as (mod P) polynomials of degree < DEG, with
-   DEG or fewer coefficients.  The coefficients are stored from left to
-   right, higher degree to lower, with the constant term last.  The
-   coefficients are represented as integers in the range [0,P-1].  Each
-   coefficient is allocated an area of ceiling(log2 P) bits.  The field
-   representation is right-justified; the "constant term" of the field
-   element ends at the right most bit.  The coefficients are fitted
-   adjacently without regard for octet boundaries.  (Example: if P=5,
-   three bits are used for each coefficient.  If the field is GF[5^75],
-   then 225 bits are required for the coefficients, and as many as 29
-   octets may be needed in the data area.  Fewer octets may be used if
-   some high-order coefficients are 0.)  If a flag requires a field
-   element to be negated, each non-zero coefficient K is replaced with
-   P-K.  To save space, 0 bits may be removed from the left end of the
-   element representation, and the length field reduced appropriately.
-   This would normally only happen with A,B,C, because the designer
-   chose curve parameters with some high-order 0 coefficients or bits.
-
-   If the finite field is simply (mod P), then the field elements are
-   simply numbers (mod P), in the usual right-justified notation.  If
-   the finite field is GF[2^D], the field elements are the usual right-
-   justified polynomial basis representation.
-
-
-
-
-
-R. Schroeppel, et al                                            [Page 8]
-
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-
-
-        LA,A is the first parameter of the elliptic curve equation.
-           When P>=5, the flag A = 1 indicates A should be negated (mod
-           P).  When P=2 (indicated by the flag M=0), the flag A = 1
-           indicates that the parameter pair LA,A is replaced by the two
-           octet parameter ALTA.  In this case, the parameter A in the
-           curve equation is x^ALTA, where x is the field generator.
-           Parameter A often has the value 0, which may be indicated by
-           LA=0 (with no A data field), and sometimes A is 1, which may
-           be represented with LA=1 and a data field of 1, or by setting
-           the A flag and using an ALTA value of 0.
-
-        LB,B is the second parameter of the elliptic curve equation.
-           When P>=5, the flag B = 1 indicates B should be negated (mod
-           P).  When P=2 or 3, the flag B selects an alternate curve
-           equation.
-
-        LC,C is the third parameter of the elliptic curve equation,
-           present only when P=2 (indicated by flag M=0) and flag B=1.
-
-        LG,G defines a point on the curve, of order Q.  The W-coordinate
-           of the curve point is given explicitly; the Z-coordinate is
-           implicit.
-
-        LY,Y is the user's public signing key, another curve point of
-           order Q.  The W-coordinate is given explicitly; the Z-
-           coordinate is implicit.  The LY,Y parameter pair is always
-           present.
-
-
-
-3. The Elliptic Curve Equation
-
-   (The coordinates of an elliptic curve point are named W,Z instead of
-   the more usual X,Y to avoid confusion with the Y parameter of the
-   signing key.)
-
-   The elliptic curve equation is determined by the flag octet, together
-   with information about the prime P.  The primes 2 and 3 are special;
-   all other primes are treated identically.
-
-   If M=1, the (mod P) or GF[P^D] case, the curve equation is Z^2 = W^3
-   + A*W + B.  Z,W,A,B are all numbers (mod P) or elements of GF[P^D].
-   If A and/or B is negative (i.e., in the range from P/2 to P), and
-   P>=5, space may be saved by putting the sign bit(s) in the A and B
-   bits of the flags octet, and the magnitude(s) in the parameter
-   fields.
-
-   If M=1 and P=3, the B flag has a different meaning: it specifies an
-   alternate curve equation, Z^2 = W^3 + A*W^2 + B.  The middle term of
-   the right-hand-side is different.  When P=3, this equation is more
-
-
-R. Schroeppel, et al                                            [Page 9]
-
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-
-
-   commonly used.
-
-   If M=0, the GF[2^N] case, the curve equation is Z^2 + W*Z = W^3 +
-   A*W^2 + B.  Z,W,A,B are all elements of the field GF[2^N].  The A
-   parameter can often be 0 or 1, or be chosen as a single-1-bit value.
-   The flag B is used to select an alternate curve equation, Z^2 + C*Z =
-   W^3 + A*W + B.  This is the only time that the C parameter is used.
-
-
-
-4. How do I Compute Q, G, and Y?
-
-   The number of points on the curve is the number of solutions to the
-   curve equation, + 1 (for the "point at infinity").  The prime Q must
-   divide the number of points.  Usually the curve is chosen first, then
-   the number of points is determined with Schoof's algorithm.  This
-   number is factored, and if it has a large prime divisor, that number
-   is taken as Q.
-
-   G must be a point of order Q on the curve, satisfying the equation
-
-        Q * G  =  the point at infinity (on the elliptic curve)
-
-   G may be chosen by selecting a random [RFC 1750] curve point, and
-   multiplying it by (number-of-points-on-curve/Q).  G must not itself
-   be the "point at infinity"; in this astronomically unlikely event, a
-   new random curve point is recalculated.
-
-   G is specified by giving its W-coordinate.  The Z-coordinate is
-   calculated from the curve equation.  In general, there will be two
-   possible Z values.  The rule is to choose the "positive" value.
-
-   In the (mod P) case, the two possible Z values sum to P.  The smaller
-   value is less than P/2; it is used in subsequent calculations.  In
-   GF[P^D] fields, the highest-degree non-zero coefficient of the field
-   element Z is used; it is chosen to be less than P/2.
-
-   In the GF[2^N] case, the two possible Z values xor to W (or to the
-   parameter C with the alternate curve equation).  The numerically
-   smaller Z value (the one which does not contain the highest-order 1
-   bit of W (or C)) is used in subsequent calculations.
-
-   Y is specified by giving the W-coordinate of the user's public
-   signature key.  The Z-coordinate value is determined from the curve
-   equation.  As with G, there are two possible Z values; the same rule
-   is followed for choosing which Z to use.
-
-
-
-
-
-
-R. Schroeppel, et al                                           [Page 10]
-
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-
-
-   During the key generation process, a random [RFC 1750] number X must
-   be generated such that 1 <= X <= Q-1.  X is the private key and is
-   used in the final step of public key generation where Y is computed
-   as
-
-        Y = X * G (as points on the elliptic curve)
-
-   If the Z-coordinate of the computed point Y is wrong (i.e., Z > P/2
-   in the (mod P) case, or the high-order non-zero coefficient of Z >
-   P/2 in the GF[P^D] case, or Z sharing a high bit with W(C) in the
-   GF[2^N] case), then X must be replaced with Q-X.  This will
-   correspond to the correct Z-coordinate.
-
-
-
-5. Elliptic Curve SIG Resource Records
-
-   The signature portion of an RR RDATA area when using the EC
-   algorithm, for example in the RRSIG and SIG [RFC records] RRs is
-   shown below.
-
-                       1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                   R, (length determined from LQ)           .../
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                   S, (length determined from LQ)           .../
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   R and S are integers (mod Q).  Their length is specified by the LQ
-   field of the corresponding KEY RR and can also be calculated from the
-   SIG RR's RDLENGTH. They are right justified, high-order-octet first.
-   The same conditional formula for calculating the length from LQ is
-   used as for all the other length fields above.
-
-   The data signed is determined as specified in [RFC 2535].  Then the
-   following steps are taken where Q, P, G, and Y are as specified in
-   the public key [Schneier]:
-
-     hash = SHA-1 ( data )
-
-     Generate random [RFC 4086] K such that 0 < K < Q.  (Never sign two
-          different messages with the same K.  K should be chosen from a
-          very large space: If an opponent learns a K value for a single
-          signature, the user's signing key is compromised, and a forger
-          can sign arbitrary messages. There is no harm in signing the
-          same message multiple times with the same key or different
-          keys.)
-
-     R = (the W-coordinate of ( K*G on the elliptic curve )) interpreted
-
-
-R. Schroeppel, et al                                           [Page 11]
-
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-
-
-          as an integer, and reduced (mod Q).  (R must not be 0.  In
-          this astronomically unlikely event, generate a new random K
-          and recalculate R.)
-
-     S = ( K^(-1) * (hash + X*R) ) mod Q.
-
-     S must not be 0.  In this astronomically unlikely event, generate a
-          new random K and recalculate R and S.
-
-     If S > Q/2, set S = Q - S.
-
-     The pair (R,S) is the signature.
-
-     Another party verifies the signature as follows:
-
-          Check that 0 < R < Q and 0 < S < Q/2.  If not, it can not be a
-               valid EC sigature.
-
-          hash = SHA-1 ( data )
-
-          Sinv = S^(-1) mod Q.
-
-          U1 = (hash * Sinv) mod Q.
-
-          U2 = (R * Sinv) mod Q.
-
-          (U1 * G + U2 * Y) is computed on the elliptic curve.
-
-          V = (the W-coordinate of this point) interpreted as an integer
-               and reduced (mod Q).
-
-          The signature is valid if V = R.
-
-     The reason for requiring S < Q/2 is that, otherwise, both (R,S) and
-     (R,Q-S) would be valid signatures for the same data.  Note that a
-     signature that is valid for hash(data) is also valid for
-     hash(data)+Q or hash(data)-Q, if these happen to fall in the range
-     [0,2^160-1].  It's believed to be computationally infeasible to
-     find data that hashes to an assigned value, so this is only a
-     cosmetic blemish.  The blemish can be eliminated by using Q >
-     2^160, at the cost of having slightly longer signatures, 42 octets
-     instead of 40.
-
-     We must specify how a field-element E ("the W-coordinate") is to be
-     interpreted as an integer.  The field-element E is regarded as a
-     radix-P integer, with the digits being the coefficients in the
-     polynomial basis representation of E.  The digits are in the ragne
-     [0,P-1].  In the two most common cases, this reduces to "the
-     obvious thing".  In the (mod P) case, E is simply a residue mod P,
-     and is taken as an integer in the range [0,P-1].  In the GF[2^D]
-
-
-R. Schroeppel, et al                                           [Page 12]
-
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-
-
-     case, E is in the D-bit polynomial basis representation, and is
-     simply taken as an integer in the range [0,(2^D)-1].  For other
-     fields GF[P^D], it's necessary to do some radix conversion
-     arithmetic.
-
-
-
-  6. Performance Considerations
-
-     Elliptic curve signatures use smaller moduli or field sizes than
-     RSA and DSA.  Creation of a curve is slow, but not done very often.
-     Key generation is faster than RSA or DSA.
-
-     DNS implementations have been optimized for small transfers,
-     typically less than 512 octets including DNS overhead. Larger
-     transfers will perform correctly and and extensions have been
-     standardized to make larger transfers more efficient [RFC 2671].
-     However, it is still advisable at this time to make reasonable
-     efforts to minimize the size of RR sets stored within the DNS
-     consistent with adequate security.
-
-
-
-  7. Security Considerations
-
-     Keys retrieved from the DNS should not be trusted unless (1) they
-     have been securely obtained from a secure resolver or independently
-     verified by the user and (2) this secure resolver and secure
-     obtainment or independent verification conform to security policies
-     acceptable to the user.  As with all cryptographic algorithms,
-     evaluating the necessary strength of the key is essential and
-     dependent on local policy.
-
-     Some specific key generation considerations are given in the body
-     of this document.
-
-
-
-  8. IANA Considerations
-
-     The key and signature data structures defined herein correspond to
-     the value 4 in the Algorithm number field of the IANA registry
-
-     Assignment of meaning to the remaining ECC data flag bits or to
-     values of ECC fields outside the ranges for which meaning in
-     defined in this document requires an IETF consensus as defined in
-     [RFC 2434].
-
-
-
-
-
-R. Schroeppel, et al                                           [Page 13]
-
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-
-
-  Copyright and Disclaimer
-
-     Copyright (C) The Internet Society 2005.  This document is subject
-     to the rights, licenses and restrictions contained in BCP 78, and
-     except as set forth therein, the authors retain all their rights.
-
-
-     This document and the information contained herein are provided on
-     an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
-     REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
-     THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
-     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
-     THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
-     ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
-     PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-R. Schroeppel, et al                                           [Page 14]
-
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-
-
-  Informational References
-
-     [RFC 1034] - P. Mockapetris, "Domain names - concepts and
-     facilities", 11/01/1987.
-
-     [RFC 1035] - P. Mockapetris, "Domain names - implementation and
-     specification", 11/01/1987.
-
-     [RFC 2671] - P. Vixie, "Extension Mechanisms for DNS (EDNS0)",
-     August 1999.
-
-     [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and
-     S. Rose, "DNS Security Introduction and Requirements", RFC 4033,
-     March 2005.
-
-     [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and
-     S. Rose, "Protocol Modifications for the DNS Security Extensions",
-     RFC 4035, March 2005.
-
-     [RFC 4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker,
-     "Randomness Requirements for Security", BCP 106, RFC 4086, June
-     2005.
-
-     [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
-     Algorithms, and Source Code in C", 1996, John Wiley and Sons
-
-     [Menezes] - Alfred Menezes, "Elliptic Curve Public Key
-     Cryptosystems", 1993 Kluwer.
-
-     [Silverman] - Joseph Silverman, "The Arithmetic of Elliptic
-     Curves", 1986, Springer Graduate Texts in mathematics #106.
-
-
-
-  Normative Refrences
-
-     [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate
-     Requirement Levels", March 1997.
-
-     [RFC 2434] - T. Narten, H. Alvestrand, "Guidelines for Writing an
-     IANA Considerations Section in RFCs", October 1998.
-
-     [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and
-     S. Rose, "Resource Records for the DNS Security Extensions", RFC
-     4034, March 2005.
-
-
-
-
-
-
-
-R. Schroeppel, et al                                           [Page 15]
-
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-
-
-  Author's Addresses
-
-     Rich Schroeppel
-     500 S. Maple Drive
-     Woodland Hills, UT 84653 USA
-
-     Telephone:   +1-505-844-9079(w)
-     Email:       rschroe@sandia.gov
-
-
-     Donald E. Eastlake 3rd
-     Motorola Laboratories
-     155 Beaver Street
-     Milford, MA 01757 USA
-
-     Telephone:   +1 508-786-7554 (w)
-     EMail:       Donald.Eastlake@motorola.com
-
-
-
-  Expiration and File Name
-
-     This draft expires in January 2006.
-
-     Its file name is draft-ietf-dnsext-ecc-key-07.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-R. Schroeppel, et al                                           [Page 16]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-interop3597-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-interop3597-02.txt
deleted file mode 100644
index 160afc3..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-interop3597-02.txt
+++ /dev/null
@@ -1,334 +0,0 @@
-DNS Extensions Working Group                                 J. Schlyter
-Internet-Draft                                              May 19, 2005
-Expires: November 20, 2005
-
-
-                     RFC 3597 Interoperability Report
-                   draft-ietf-dnsext-interop3597-02.txt
-
-Status of this Memo
-
-    By submitting this Internet-Draft, each author represents that any
-    applicable patent or other IPR claims of which he or she is aware
-    have been or will be disclosed, and any of which he or she becomes
-    aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-    Internet-Drafts are working documents of the Internet Engineering
-    Task Force (IETF), its areas, and its working groups.  Note that
-    other groups may also distribute working documents as Internet-
-    Drafts.
-
-    Internet-Drafts are draft documents valid for a maximum of six months
-    and may be updated, replaced, or obsoleted by other documents at any
-    time.  It is inappropriate to use Internet-Drafts as reference
-    material or to cite them other than as "work in progress."
-
-    The list of current Internet-Drafts can be accessed at
-    http://www.ietf.org/ietf/1id-abstracts.txt.
-
-    The list of Internet-Draft Shadow Directories can be accessed at
-    http://www.ietf.org/shadow.html.
-
-    This Internet-Draft will expire on November 20, 2005.
-
-Copyright Notice
-
-    Copyright (C) The Internet Society (2005).
-
-Abstract
-
-    This memo documents the result from the RFC 3597 (Handling of Unknown
-    DNS Resource Record Types) interoperability testing.
-
-
-
-
-
-
-
-
-
-
-Schlyter                Expires November 20, 2005               [Page 1]
-
-Internet-Draft      RFC 3597 Interoperability Report            May 2005
-
-
-Table of Contents
-
-    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-    2.  Implementations  . . . . . . . . . . . . . . . . . . . . . . .  3
-    3.  Tests  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
-      3.1   Authoritative Primary Name Server  . . . . . . . . . . . .  3
-      3.2   Authoritative Secondary Name Server  . . . . . . . . . . .  3
-      3.3   Full Recursive Resolver  . . . . . . . . . . . . . . . . .  4
-      3.4   Stub Resolver  . . . . . . . . . . . . . . . . . . . . . .  4
-      3.5   DNSSEC Signer  . . . . . . . . . . . . . . . . . . . . . .  4
-    4.  Problems found . . . . . . . . . . . . . . . . . . . . . . . .  4
-    5.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
-    6.  Normative References . . . . . . . . . . . . . . . . . . . . .  4
-        Author's Address . . . . . . . . . . . . . . . . . . . . . . .  4
-    A.  Test zone data . . . . . . . . . . . . . . . . . . . . . . . .  5
-        Intellectual Property and Copyright Statements . . . . . . . .  6
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter                Expires November 20, 2005               [Page 2]
-
-Internet-Draft      RFC 3597 Interoperability Report            May 2005
-
-
-1.  Introduction
-
-    This memo documents the result from the RFC 3597 (Handling of Unknown
-    DNS Resource Record Types) interoperability testing.  The test was
-    performed during June and July 2004 by request of the IETF DNS
-    Extensions Working Group.
-
-2.  Implementations
-
-    The following is a list, in alphabetic order, of implementations
-    tested for compliance with RFC 3597:
-
-       DNSJava 1.6.4
-       ISC BIND 8.4.5
-       ISC BIND 9.3.0
-       NSD 2.1.1
-       Net::DNS 0.47 patchlevel 1
-       Nominum ANS 2.2.1.0.d
-
-    These implementations covers the following functions (number of
-    implementations tested for each function in paranthesis):
-
-       Authoritative Name Servers (4)
-       Full Recursive Resolver (2)
-       Stub Resolver (4)
-       DNSSEC Zone Signers (2)
-
-    All listed implementations are genetically different.
-
-3.  Tests
-
-    The following tests was been performed to validate compliance with
-    RFC 3597 section 3 ("Transparency"), 4 ("Domain Name Compression")
-    and 5 ("Text Representation").
-
-3.1  Authoritative Primary Name Server
-
-    The test zone data (Appendix A) was loaded into the name server
-    implementation and the server was queried for the loaded information.
-
-3.2  Authoritative Secondary Name Server
-
-    The test zone data (Appendix A) was transferred using AXFR from
-    another name server implementation and the server was queried for the
-    transferred information.
-
-
-
-
-
-
-Schlyter                Expires November 20, 2005               [Page 3]
-
-Internet-Draft      RFC 3597 Interoperability Report            May 2005
-
-
-3.3  Full Recursive Resolver
-
-    A recursive resolver was queried for resource records from a domain
-    with the test zone data (Appendix A).
-
-3.4  Stub Resolver
-
-    A stub resolver was used to query resource records from a domain with
-    the test zone data (Appendix A).
-
-3.5  DNSSEC Signer
-
-    A DNSSEC signer was used to sign a zone with test zone data
-    (Appendix A).
-
-4.  Problems found
-
-    Two implementations had problems with text presentation of zero
-    length RDATA.
-
-    One implementation had problems with text presentation of RR type
-    code and classes >= 4096.
-
-    Bug reports were filed for problems found.
-
-5.  Summary
-
-    Unknown type codes works in the tested authoritative servers,
-    recursive resolvers and stub clients.
-
-    No changes are needed to advance RFC 3597 to draft standard.
-
-6.  Normative References
-
-    [1]  Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
-         Types", RFC 3597, September 2003.
-
-
-Author's Address
-
-    Jakob Schlyter
-
-    Email: jakob@rfc.se
-
-
-
-
-
-
-
-
-Schlyter                Expires November 20, 2005               [Page 4]
-
-Internet-Draft      RFC 3597 Interoperability Report            May 2005
-
-
-Appendix A.  Test zone data
-
-    ; A-record encoded as TYPE1
-    a  TYPE1  \# 4 7f000001
-    a  TYPE1  192.0.2.1
-    a  A      \# 4 7f000002
-
-    ; draft-ietf-secsh-dns-05.txt
-    sshfp  TYPE44  \# 22 01 01 c691e90714a1629d167de8e5ee0021f12a7eaa1e
-
-    ; bogus test record (from RFC 3597)
-    type731    TYPE731    \# 6 abcd (
-                               ef 01 23 45 )
-
-    ; zero length RDATA (from RFC 3597)
-    type62347  TYPE62347  \# 0
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter                Expires November 20, 2005               [Page 5]
-
-Internet-Draft      RFC 3597 Interoperability Report            May 2005
-
-
-Intellectual Property Statement
-
-    The IETF takes no position regarding the validity or scope of any
-    Intellectual Property Rights or other rights that might be claimed to
-    pertain to the implementation or use of the technology described in
-    this document or the extent to which any license under such rights
-    might or might not be available; nor does it represent that it has
-    made any independent effort to identify any such rights.  Information
-    on the procedures with respect to rights in RFC documents can be
-    found in BCP 78 and BCP 79.
-
-    Copies of IPR disclosures made to the IETF Secretariat and any
-    assurances of licenses to be made available, or the result of an
-    attempt made to obtain a general license or permission for the use of
-    such proprietary rights by implementers or users of this
-    specification can be obtained from the IETF on-line IPR repository at
-    http://www.ietf.org/ipr.
-
-    The IETF invites any interested party to bring to its attention any
-    copyrights, patents or patent applications, or other proprietary
-    rights that may cover technology that may be required to implement
-    this standard.  Please address the information to the IETF at
-    ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-    This document and the information contained herein are provided on an
-    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-    Copyright (C) The Internet Society (2005).  This document is subject
-    to the rights, licenses and restrictions contained in BCP 78, and
-    except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-    Funding for the RFC Editor function is currently provided by the
-    Internet Society.
-
-
-
-
-Schlyter                Expires November 20, 2005               [Page 6]
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt
deleted file mode 100644
index 6bffb70..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt
+++ /dev/null
@@ -1,560 +0,0 @@
-
-DNS Extensions                                                O. Kolkman
-Internet-Draft                                                  RIPE NCC
-Expires: June 17, 2004                                       J. Schlyter
-
-                                                                E. Lewis
-                                                                    ARIN
-                                                       December 18, 2003
-
-
-                   DNSKEY RR Secure Entry Point Flag
-              draft-ietf-dnsext-keyrr-key-signing-flag-12
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups. Note that other
-   groups may also distribute working documents as Internet-Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time. It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at http://
-   www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on June 17, 2004.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-Abstract
-
-   With the Delegation Signer (DS) resource record the concept of a
-   public key acting as a secure entry point has been introduced. During
-   exchanges of public keys with the parent there is a need to
-   differentiate secure entry point keys from other public keys in the
-   DNSKEY resource record (RR) set.  A flag bit in the DNSKEY RR is
-   defined to indicate that DNSKEY is to be used as a secure entry
-   point. The flag bit is intended to assist in operational procedures
-   to correctly generate DS resource records, or to indicate what
-   DNSKEYs are intended for static configuration. The flag bit is not to
-
-
-
-Kolkman, et al.          Expires June 17, 2004                  [Page 1]
-
-Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
-
-
-   be used in the DNS verification protocol. This document updates RFC
-   2535 and RFC 3445.
-
-Table of Contents
-
-   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
-   2. The Secure Entry Point (SEP) Flag  . . . . . . . . . . . . . . . 4
-   3. DNSSEC Protocol Changes  . . . . . . . . . . . . . . . . . . . . 5
-   4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . . 5
-   5. Security Considerations  . . . . . . . . . . . . . . . . . . . . 6
-   6. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . . 6
-   7. Internationalization Considerations  . . . . . . . . . . . . . . 6
-   8. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . . 6
-      Normative References . . . . . . . . . . . . . . . . . . . . . . 7
-      Informative References . . . . . . . . . . . . . . . . . . . . . 7
-      Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
-      Intellectual Property and Copyright Statements . . . . . . . . . 9
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman, et al.          Expires June 17, 2004                  [Page 2]
-
-Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
-
-
-1. Introduction
-
-   "All keys are equal but some keys are more equal than others" [6]
-
-   With the definition of the Delegation Signer Resource Record (DS RR)
-   [5] it has become important to differentiate between the keys in the
-   DNSKEY RR set that are (to be) pointed to by parental DS RRs and the
-   other keys in the DNSKEY RR set.  We refer to these public keys as
-   Secure Entry Point (SEP) keys.  A SEP key either used to generate a
-   DS RR or is distributed to resolvers that use the key as the root of
-   a trusted subtree[3].
-
-   In early deployment tests, the use of two (kinds of) key pairs for
-   each zone has been prevalent.  For one kind of key pair the private
-   key is used to sign just the zone's DNSKEY resource record (RR) set.
-   Its public key is intended to be referenced by a DS RR at the parent
-   or configured statically in a resolver.  The private key of the other
-   kind of key pair is used to sign the rest of the zone's data sets.
-   The former key pair is called a key-signing key (KSK) and the latter
-   is called a zone-signing key (ZSK).  In practice there have been
-   usually one of each kind of key pair, but there will be multiples of
-   each at times.
-
-   It should be noted that division of keys pairs into KSK's and ZSK's
-   is not mandatory in any definition of DNSSEC, not even with the
-   introduction of the DS RR.  But, in testing, this distinction has
-   been helpful when designing key roll over (key super-cession)
-   schemes.  Given that the distinction has proven helpful, the labels
-   KSK and ZSK have begun to stick.
-
-   There is a need to differentiate the public keys for the key pairs
-   that are used for key signing from keys that are not used key signing
-   (KSKs vs ZSKs). This need is driven by knowing which DNSKEYs are to
-   be sent for generating DS RRs, which DNSKEYs are to be distributed to
-   resolvers, and which keys are fed to the signer application at the
-   appropriate time.
-
-   In other words, the SEP bit provides an in-band method to communicate
-   a DNSKEY RR's intended use to third parties. As an example we present
-   3 use cases in which the bit is useful:
-
-      The parent is a registry, the parent and the child use secured DNS
-      queries and responses, with a preexisting trust-relation, or plain
-      DNS over a secured channel to exchange the child's  DNSKEY RR
-      sets. Since a DNSKEY RR set will contain a complete DNSKEY RRset
-      the SEP bit can be used to isolate the DNSKEYs for which a DS RR
-      needs to be created.
-
-
-
-
-Kolkman, et al.          Expires June 17, 2004                  [Page 3]
-
-Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
-
-
-      An administrator has configured a DNSKEY as root for a trusted
-      subtree into security aware resolver. Using a special purpose tool
-      that queries for the KEY RRs from that domain's apex, the
-      administrator will be able to notice the roll over of the trusted
-      anchor by a change of the subset of KEY RRs with the DS flag set.
-
-      A signer might use the SEP bit on the public key to determine
-      which private key to use to exclusively sign the DNSKEY RRset and
-      which private key to use to sign the other RRsets in the zone.
-
-   As demonstrated in the above examples it is important to be able to
-   differentiate the SEP keys from the other keys in a DNSKEY RR set in
-   the flow between signer and (parental) key-collector and in the flow
-   between the signer and the resolver configuration. The SEP flag is to
-   be of no interest to the flow between the verifier and the
-   authoritative data store.
-
-   The reason for the term "SEP" is a result of the observation that the
-   distinction between KSK and ZSK key pairs is made by the signer, a
-   key pair could be used as both a KSK and a ZSK at the same time. To
-   be clear, the term SEP was coined to lessen the confusion caused by
-   the overlap. ( Once this label was applied, it had the side effect of
-   removing the temptation to have both a KSK flag bit and a ZSK flag
-   bit.)
-
-   The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED",
-   "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be
-   interpreted as described in RFC2119 [1].
-
-2. The Secure Entry Point (SEP) Flag
-
-
-                           1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |              flags          |S|   protocol    |   algorithm   |
-      |                             |E|               |               |
-      |                             |P|               |               |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |                                                               /
-      /                        public key                             /
-      /                                                               /
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-                                DNSKEY RR Format
-
-
-
-
-
-
-Kolkman, et al.          Expires June 17, 2004                  [Page 4]
-
-Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
-
-
-   This document assigns the 15'th bit in the flags field as the secure
-   entry point (SEP) bit.  If the the bit is set to 1 the key is
-   intended to be used as secure entry point key.  One SHOULD NOT assign
-   special meaning to the key if the bit is set to 0.  Operators can
-   recognize the secure entry point key by the even or odd-ness of the
-   decimal representation of the flag field.
-
-3. DNSSEC Protocol Changes
-
-   The bit MUST NOT be used during the resolving and verification
-   process. The SEP flag is only used to provide a hint about the
-   different administrative properties of the key and therefore the use
-   of the SEP flag does not change the DNS resolution protocol or the
-   resolution process.
-
-4. Operational Guidelines
-
-   The SEP bit is set by the key-pair-generator and MAY be used by the
-   zone signer to decide whether the public part of the key pair is to
-   be prepared for input to a DS RR generation function.  The SEP bit is
-   recommended to be set (to 1) whenever the public key of the key pair
-   will be distributed to the parent zone to build the authentication
-   chain or if the public key is to be distributed for static
-   configuration in verifiers.
-
-   When a key pair is created, the operator needs to indicate whether
-   the SEP bit is to be set in the DNSKEY RR.  As the SEP bit is within
-   the data that is used to compute the 'key tag field' in the SIG RR,
-   changing the SEP bit will change the identity of the key within DNS.
-   In other words, once a key is used to generate signatures, the
-   setting of the SEP bit is to remain constant. If not, a verifier will
-   not be able to find the relevant KEY RR.
-
-   When signing a zone, it is intended that the key(s) with the SEP bit
-   set (if such keys exist) are used to sign the KEY RR set of the zone.
-   The same key can be used to sign the rest of the zone data too.  It
-   is conceivable that not all keys with a SEP bit set will sign the
-   DNSKEY RR set, such keys might be pending retirement or not yet in
-   use.
-
-   When verifying a RR set, the SEP bit is not intended to play a role.
-   How the key is used by the verifier is not intended to be a
-   consideration at key creation time.
-
-   Although the SEP flag provides a hint on which public key is to be
-   used as trusted root, administrators can choose to ignore the fact
-   that a DNSKEY has its SEP bit set or not when configuring a trusted
-   root for their resolvers.
-
-
-
-Kolkman, et al.          Expires June 17, 2004                  [Page 5]
-
-Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
-
-
-   Using the SEP flag a key roll over can be automated. The parent can
-   use an existing trust relation to verify DNSKEY RR sets in which a
-   new DNSKEY RR with the SEP flag appears.
-
-5. Security Considerations
-
-   As stated in Section 3 the flag is not to be used in the resolution
-   protocol or to determine the security status of a key. The flag is to
-   be used for administrative purposes only.
-
-   No trust in a key should be inferred from this flag - trust MUST be
-   inferred from an existing chain of trust or an out-of-band exchange.
-
-   Since this flag might be used for automating public key exchanges, we
-   think the following consideration is in place.
-
-   Automated mechanisms for roll over of the DS RR might be vulnerable
-   to a class of replay attacks.  This might happen after a public key
-   exchange where a DNSKEY RR set, containing two DNSKEY RRs with the
-   SEP flag set, is sent to the parent.  The parent verifies the DNSKEY
-   RR set with the existing trust relation and creates the new DS RR
-   from the DNSKEY RR that the current DS RR is not pointing to.  This
-   key exchange might be replayed. Parents are encouraged to implement a
-   replay defense. A simple defense can be based on a registry of keys
-   that have been used to generate DS RRs during the most recent roll
-   over. These same considerations apply to entities that configure keys
-   in resolvers.
-
-6. IANA Considerations
-
-   The flag bits  in the DNSKEY RR are assigned by IETF consensus and
-   registered in the DNSKEY Flags registry (created by [4]). This
-   document assigns the 15th bit in the DNSKEY RR as the Secure Entry
-   Point (SEP) bit.
-
-7. Internationalization Considerations
-
-   Although SEP is a popular acronym in many different languages, there
-   are no internationalization considerations.
-
-8. Acknowledgments
-
-   The ideas documented in this document are inspired by communications
-   we had with numerous people and ideas published by other folk. Among
-   others Mark Andrews, Rob Austein, Miek Gieben, Olafur Gudmundsson,
-   Daniel Karrenberg, Dan Massey, Scott Rose, Marcos Sanz and Sam Weiler
-   have contributed ideas and provided feedback.
-
-
-
-
-Kolkman, et al.          Expires June 17, 2004                  [Page 6]
-
-Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
-
-
-   This document saw the light during a workshop on DNSSEC operations
-   hosted by USC/ISI in August 2002.
-
-Normative References
-
-   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [2]  Eastlake, D., "Domain Name System Security Extensions", RFC
-        2535, March 1999.
-
-   [3]  Lewis, E., "DNS Security Extension Clarification on Zone
-        Status", RFC 3090, March 2001.
-
-   [4]  Weiler, S., "Legacy Resolver Compatibility for Delegation
-        Signer", draft-ietf-dnsext-dnssec-2535typecode-change-05 (work
-        in progress), October 2003.
-
-Informative References
-
-   [5]  Gudmundsson, O., "Delegation Signer Resource Record",
-        draft-ietf-dnsext-delegation-signer-15 (work in progress), June
-        2003.
-
-   [6]  Orwell, G. and R. Steadman (illustrator), "Animal Farm; a Fairy
-        Story", ISBN 0151002177 (50th anniversary edition), April 1996.
-
-
-Authors' Addresses
-
-   Olaf M. Kolkman
-   RIPE NCC
-   Singel 256
-   Amsterdam  1016 AB
-   NL
-
-   Phone: +31 20 535 4444
-   EMail: olaf@ripe.net
-   URI:   http://www.ripe.net/
-
-
-   Jakob Schlyter
-   Karl Gustavsgatan 15
-   Goteborg  SE-411 25
-   Sweden
-
-   EMail: jakob@schlyter.se
-
-
-
-
-Kolkman, et al.          Expires June 17, 2004                  [Page 7]
-
-Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
-
-
-   Edward P. Lewis
-   ARIN
-   3635 Concorde Parkway Suite 200
-   Chantilly, VA  20151
-   US
-
-   Phone: +1 703 227 9854
-   EMail: edlewis@arin.net
-   URI:   http://www.arin.net/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman, et al.          Expires June 17, 2004                  [Page 8]
-
-Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   intellectual property or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; neither does it represent that it
-   has made any effort to identify any such rights. Information on the
-   IETF's procedures with respect to rights in standards-track and
-   standards-related documentation can be found in BCP-11. Copies of
-   claims of rights made available for publication and any assurances of
-   licenses to be made available, or the result of an attempt made to
-   obtain a general license or permission for the use of such
-   proprietary rights by implementors or users of this specification can
-   be obtained from the IETF Secretariat.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights which may cover technology that may be required to practice
-   this standard. Please address the information to the IETF Executive
-   Director.
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works. However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assignees.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-
-
-
-Kolkman, et al.          Expires June 17, 2004                  [Page 9]
-
-Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
-
-
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman, et al.          Expires June 17, 2004                 [Page 10]
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-mdns-43.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-mdns-43.txt
deleted file mode 100644
index 5de6e85..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-mdns-43.txt
+++ /dev/null
@@ -1,1740 +0,0 @@
-
-
-
-
-
-
-DNSEXT Working Group                                       Bernard Aboba
-INTERNET-DRAFT                                               Dave Thaler
-Category: Standards Track                                   Levon Esibov
-<draft-ietf-dnsext-mdns-43.txt>                    Microsoft Corporation
-29 August 2005
-
-              Linklocal Multicast Name Resolution (LLMNR)
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on March 15, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society 2005.
-
-Abstract
-
-   The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable
-   name resolution in scenarios in which conventional DNS name
-   resolution is not possible.  LLMNR supports all current and future
-   DNS formats, types and classes, while operating on a separate port
-   from DNS, and with a distinct resolver cache.  Since LLMNR only
-   operates on the local link, it cannot be considered a substitute for
-   DNS.
-
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                    [Page 1]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-Table of Contents
-
-1.     Introduction ..........................................    3
-   1.1       Requirements ....................................    4
-   1.2       Terminology .....................................    4
-2.     Name Resolution Using LLMNR ...........................    4
-   2.1       LLMNR Packet Format .............................    6
-   2.2       Sender Behavior .................................    9
-   2.3       Responder Behavior ..............................   10
-   2.4       Unicast Queries and Responses ...................   12
-   2.5       Off-link Detection ..............................   13
-   2.6       Responder Responsibilities ......................   13
-   2.7       Retransmission and Jitter .......................   14
-   2.8       DNS TTL .........................................   15
-   2.9       Use of the Authority and Additional Sections ....   15
-3.     Usage model ...........................................   16
-   3.1       LLMNR Configuration .............................   17
-4.     Conflict Resolution ...................................   18
-   4.1       Uniqueness Verification .........................   19
-   4.2       Conflict Detection and Defense ..................   20
-   4.3       Considerations for Multiple Interfaces ..........   21
-   4.4       API issues ......................................   22
-5.     Security Considerations ...............................   22
-   5.1       Denial of Service ...............................   23
-   5.2       Spoofing ...............,........................   23
-   5.3       Authentication ..................................   24
-   5.4       Cache and Port Separation .......................   25
-6.     IANA considerations ...................................   25
-7.     Constants .............................................   25
-8.     References ............................................   25
-   8.1       Normative References ............................   25
-   8.2       Informative References ..........................   26
-Acknowledgments ..............................................   27
-Authors' Addresses ...........................................   28
-Intellectual Property Statement ..............................   28
-Disclaimer of Validity .......................................   29
-Copyright Statement ..........................................   29
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                    [Page 2]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-1.  Introduction
-
-   This document discusses Link Local Multicast Name Resolution (LLMNR),
-   which is based on the DNS packet format and supports all current and
-   future DNS formats, types and classes.  LLMNR operates on a separate
-   port from the Domain Name System (DNS), with a distinct resolver
-   cache.
-
-   The goal of LLMNR is to enable name resolution in scenarios in which
-   conventional DNS name resolution is not possible.  Usage scenarios
-   (discussed in more detail in Section 3.1) include situations in which
-   hosts are not configured with the address of a DNS server; where the
-   DNS server is unavailable or unreachable; where there is no DNS
-   server authoritative for the name of a host, or where the
-   authoritative DNS server does not have the desired RRs, as described
-   in Section 2.
-
-   Since LLMNR only operates on the local link, it cannot be considered
-   a substitute for DNS.  Link-scope multicast addresses are used to
-   prevent propagation of LLMNR traffic across routers, potentially
-   flooding the network.  LLMNR queries can also be sent to a unicast
-   address, as described in Section 2.4.
-
-   Propagation of LLMNR packets on the local link is considered
-   sufficient to enable name resolution in small networks.  In such
-   networks, if a network has a gateway, then typically the network is
-   able to provide DNS server configuration.  Configuration issues are
-   discussed in Section 3.1.
-
-   In the future, it may be desirable to consider use of multicast name
-   resolution with multicast scopes beyond the link-scope.  This could
-   occur if LLMNR deployment is successful, the need arises for
-   multicast name resolution beyond the link-scope, or multicast routing
-   becomes ubiquitous.  For example, expanded support for multicast name
-   resolution might be required for mobile ad-hoc networks.
-
-   Once we have experience in LLMNR deployment in terms of
-   administrative issues, usability and impact on the network, it will
-   be possible to reevaluate which multicast scopes are appropriate for
-   use with multicast name resolution.  IPv4 administratively scoped
-   multicast usage is specified in "Administratively Scoped IP
-   Multicast" [RFC2365].
-
-   Service discovery in general, as well as discovery of DNS servers
-   using LLMNR in particular, is outside of the scope of this document,
-   as is name resolution over non-multicast capable media.
-
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                    [Page 3]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-1.1.  Requirements
-
-   In this document, several words are used to signify the requirements
-   of the specification.  The key words "MUST", "MUST NOT", "REQUIRED",
-   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY",
-   and "OPTIONAL" in this document are to be interpreted as described in
-   [RFC2119].
-
-1.2.  Terminology
-
-   This document assumes familiarity with DNS terminology defined in
-   [RFC1035].  Other terminology used in this document includes:
-
-Positively Resolved
-     Responses with RCODE set to zero are referred to in this document
-     as "positively resolved".
-
-Routable Address
-     An address other than a Link-Local address.  This includes globally
-     routable addresses, as well as private addresses.
-
-Reachable
-     An LLMNR responder considers one of its addresses reachable over a
-     link if it will respond to an ARP or Neighbor Discovery query for
-     that address received on that link.
-
-Responder
-     A host that listens to LLMNR queries, and responds to those for
-     which it is authoritative.
-
-Sender
-     A host that sends an LLMNR query.
-
-UNIQUE
-     There are some scenarios when multiple responders may respond to
-     the same query.  There are other scenarios when only one responder
-     may respond to a query.  Names for which only a single responder is
-     anticipated are referred to as UNIQUE.  Name uniqueness is
-     configured on the responder, and therefore uniqueness verification
-     is the responder's responsibility.
-
-2.  Name Resolution Using LLMNR
-
-   LLMNR is a peer-to-peer name resolution protocol that is not intended
-   as a replacement for DNS.  LLMNR queries are sent to and received on
-   port 5355.  The IPv4 link-scope multicast address a given responder
-   listens to, and to which a sender sends queries, is 224.0.0.252.  The
-   IPv6 link-scope multicast address a given responder listens to, and
-
-
-
-Aboba, Thaler & Esibov       Standards Track                    [Page 4]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-   to which a sender sends all queries, is FF02:0:0:0:0:0:1:3.
-
-   Typically a host is configured as both an LLMNR sender and a
-   responder.  A host MAY be configured as a sender, but not a
-   responder.  However, a host configured as a responder MUST act as a
-   sender, if only to verify the uniqueness of names as described in
-   Section 4.  This document does not specify how names are chosen or
-   configured.  This may occur via any mechanism, including DHCPv4
-   [RFC2131] or DHCPv6 [RFC3315].
-
-   LLMNR usage MAY be configured manually or automatically on a per
-   interface basis.  By default, LLMNR responders SHOULD be enabled on
-   all interfaces, at all times.  Enabling LLMNR for use in situations
-   where a DNS server has been configured will result in a change in
-   default behavior without a simultaneous update to configuration
-   information.  Where this is considered undesirable, LLMNR SHOULD NOT
-   be enabled by default, so that hosts will neither listen on the link-
-   scope multicast address, nor will they send queries to that address.
-
-   By default, LLMNR queries MAY be sent only when one of the following
-   conditions are met:
-
-   [1] No manual or automatic DNS configuration has been performed.
-       If DNS server address(es) have been configured, then LLMNR
-       SHOULD NOT be used as the primary name resolution mechanism,
-       although it MAY be used as a secondary name resolution
-       mechanism.  A dual stack host SHOULD attempt to reach DNS
-       servers overall protocols on which DNS server address(es) are
-       configured, prior to sending LLMNR queries.  For dual stack
-       hosts configured with DNS server address(es) for one protocol
-       but not another, this inplies that DNS queries SHOULD be sent
-       over the protocol configured with a DNS server, prior to
-       sending LLMNR queries.
-
-   [2] All attempts to resolve the name via DNS on all interfaces
-       have failed after exhausting the searchlist.  This can occur
-       because DNS servers did not respond, or because they
-       responded to DNS queries with RCODE=3 (Authoritative Name
-       Error) or RCODE=0, and an empty answer section.  Where a
-       single resolver call generates DNS queries for A and AAAA RRs,
-       an implementation MAY choose not to send LLMNR queries if any
-       of the DNS queries is successful.  An LLMNR query SHOULD only
-       be sent for the originally requested name;  a searchlist
-       is not used to form additional LLMNR queries.
-
-   While these conditions are necessary for sending an LLMNR query, they
-   are not sufficient.  While an LLMNR sender MAY send a query for any
-   name, it also MAY impose additional conditions on sending LLMNR
-
-
-
-Aboba, Thaler & Esibov       Standards Track                    [Page 5]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-   queries.  For example, a sender configured with a DNS server MAY send
-   LLMNR queries only for unqualified names and for fully qualified
-   domain names within configured zones.
-
-   A typical sequence of events for LLMNR usage is as follows:
-
-   [a]  DNS servers are not configured or attempts to resolve the
-        name via DNS have failed, after exhausting the searchlist.
-        Also, the name to be queried satisfies the restrictions
-        imposed by the implementation.
-
-   [b]  An LLMNR sender sends an LLMNR query to the link-scope
-        multicast address(es), unless a unicast query is indicated,
-        as specified in Section 2.4.
-
-   [c]  A responder responds to this query only if it is authoritative
-        for the domain name in the query.  A responder responds to a
-        multicast query by sending a unicast UDP response to the sender.
-        Unicast queries are responded to as indicated in Section 2.4.
-
-   [d]  Upon reception of the response, the sender processes it.
-
-   The sections that follow provide further details on sender and
-   responder behavior.
-
-2.1.  LLMNR Packet Format
-
-   LLMNR is based on the DNS packet format defined in [RFC1035] Section
-   4 for both queries and responses.  LLMNR implementations SHOULD send
-   UDP queries and responses only as large as are known to be
-   permissible without causing fragmentation.  When in doubt a maximum
-   packet size of 512 octets SHOULD be used.  LLMNR implementations MUST
-   accept UDP queries and responses as large as the smaller of the link
-   MTU or 9194 octets (Ethernet jumbo frame size of 9KB (9216) minus 22
-   octets for the header, VLAN tag and CRC).
-
-2.1.1.  LLMNR Header Format
-
-   LLMNR queries and responses utilize the DNS header format defined in
-   [RFC1035] with exceptions noted below:
-
-
-
-
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                    [Page 6]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-                                   1  1  1  1  1  1
-     0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
-   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-   |                      ID                       |
-   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-   |QR|   Opcode  | C|TC| T| Z| Z| Z| Z|   RCODE   |
-   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-   |                    QDCOUNT                    |
-   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-   |                    ANCOUNT                    |
-   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-   |                    NSCOUNT                    |
-   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-   |                    ARCOUNT                    |
-   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-   where:
-
-ID   A 16 bit identifier assigned by the program that generates any kind
-     of query.  This identifier is copied from the query to the response
-     and can be used by the sender to match responses to outstanding
-     queries. The ID field in a query SHOULD be set to a pseudo-random
-     value.  For advice on generation of pseudo-random values, please
-     consult [RFC1750].
-
-QR   Query/Response.  A one bit field, which if set indicates that the
-     message is an LLMNR response; if clear then the message is an LLMNR
-     query.
-
-OPCODE
-     A four bit field that specifies the kind of query in this message.
-     This value is set by the originator of a query and copied into the
-     response.  This specification defines the behavior of standard
-     queries and responses (opcode value of zero).  Future
-     specifications may define the use of other opcodes with LLMNR.
-     LLMNR senders and responders MUST support standard queries (opcode
-     value of zero).  LLMNR queries with unsupported OPCODE values MUST
-     be silently discarded by responders.
-
-C    Conflict.  When set within a request, the 'C'onflict bit indicates
-     that a sender has received multiple LLMNR responses to this query.
-     In an LLMNR response, if the name is considered UNIQUE, then the
-     'C' bit is clear, otherwise it is set.  LLMNR senders do not
-     retransmit queries with the 'C' bit set.  Responders MUST NOT
-     respond to LLMNR queries with the 'C' bit set, but may start the
-     uniqueness verification process, as described in Section 4.2.
-
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                    [Page 7]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-TC   TrunCation - specifies that this message was truncated due to
-     length greater than that permitted on the transmission channel.
-     The TC bit MUST NOT be set in an LLMNR query and if set is ignored
-     by an LLMNR responder.  If the TC bit is set in an LLMNR response,
-     then the sender SHOULD discard the response and resend the LLMNR
-     query over TCP using the unicast address of the responder as the
-     destination address.  See  [RFC2181] and Section 2.4 of this
-     specification for further discussion of the TC bit.
-
-T    Tentative.  The 'T'entative bit is set in a response if the
-     responder is authoritative for the name, but has not yet verified
-     the uniqueness of the name.  A responder MUST ignore the 'T' bit in
-     a query, if set.  A response with the 'T' bit set is silently
-     discarded by the sender, except if it is a uniqueness query, in
-     which case a conflict has been detected and a responder MUST
-     resolve the conflict as described in Section 4.1.
-
-Z    Reserved for future use.  Implementations of this specification
-     MUST set these bits to zero in both queries and responses.  If
-     these bits are set in a LLMNR query or response, implementations of
-     this specification MUST ignore them.  Since reserved bits could
-     conceivably be used for different purposes than in DNS,
-     implementors are advised not to enable processing of these bits in
-     an LLMNR implementation starting from a DNS code base.
-
-RCODE
-     Response code -- this 4 bit field is set as part of LLMNR
-     responses.  In an LLMNR query, the sender MUST set RCODE to zero;
-     the responder ignores the RCODE and assumes it to be zero.  The
-     response to a multicast LLMNR query MUST have RCODE set to zero.  A
-     sender MUST silently discard an LLMNR response with a non-zero
-     RCODE sent in response to a multicast query.
-
-     If an LLMNR responder is authoritative for the name in a multicast
-     query, but an error is encountered, the responder SHOULD send an
-     LLMNR response with an RCODE of zero, no RRs in the answer section,
-     and the TC bit set.  This will cause the query to be resent using
-     TCP, and allow the inclusion of a non-zero RCODE in the response to
-     the TCP query.  Responding with the TC bit set is preferable to not
-     sending a response, since it enables errors to be diagnosed.
-     Errors include those defined in [RFC2845], such as BADSIG(16),
-     BADKEY(17) and BADTIME(18).
-
-     Since LLMNR responders only respond to LLMNR queries for names for
-     which they are authoritative, LLMNR responders MUST NOT respond
-     with an RCODE of 3; instead, they should not respond at all.
-
-     LLMNR implementations MUST support EDNS0 [RFC2671] and extended
-
-
-
-Aboba, Thaler & Esibov       Standards Track                    [Page 8]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-     RCODE values.
-
-QDCOUNT
-     An unsigned 16 bit integer specifying the number of entries in the
-     question section.  A sender MUST place only one question into the
-     question section of an LLMNR query.  LLMNR responders MUST silently
-     discard LLMNR queries with QDCOUNT not equal to one.  LLMNR senders
-     MUST silently discard LLMNR responses with QDCOUNT not equal to
-     one.
-
-ANCOUNT
-     An unsigned 16 bit integer specifying the number of resource
-     records in the answer section.  LLMNR responders MUST silently
-     discard LLMNR queries with ANCOUNT not equal to zero.
-
-NSCOUNT
-     An unsigned 16 bit integer specifying the number of name server
-     resource records in the authority records section.  Authority
-     record section processing is described in Section 2.9.  LLMNR
-     responders MUST silently discard LLMNR queries with NSCOUNT not
-     equal to zero.
-
-ARCOUNT
-     An unsigned 16 bit integer specifying the number of resource
-     records in the additional records section.  Additional record
-     section processing is described in Section 2.9.
-
-2.2.  Sender Behavior
-
-   A sender MAY send an LLMNR query for any legal resource record  type
-   (e.g., A, AAAA, PTR, SRV, etc.) to the link-scope multicast address.
-   As described in Section 2.4, a sender MAY also send a unicast query.
-
-   The sender MUST anticipate receiving no replies to some LLMNR
-   queries, in the event that no responders are available within the
-   link-scope.  If no response is received, a resolver treats it as a
-   response that the name does not exist (RCODE=3 is returned).  A
-   sender can handle duplicate responses by discarding responses with a
-   source IP address and ID field that duplicate a response already
-   received.
-
-   When multiple valid LLMNR responses are received with the 'C' bit
-   set, they SHOULD be concatenated and treated in the same manner that
-   multiple RRs received from the same DNS server would be.  However,
-   responses with the 'C' bit set SHOULD NOT be concatenated with
-   responses with the 'C' bit clear; instead, only the responses with
-   the 'C' bit set SHOULD be returned.  If valid LLMNR response(s) are
-   received along with error response(s), then the error responses are
-
-
-
-Aboba, Thaler & Esibov       Standards Track                    [Page 9]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-   silently discarded.
-
-   If error responses are received from both DNS and LLMNR, then the
-   lowest RCODE value should be returned. For example, if either DNS or
-   LLMNR receives a response with RCODE=0, then this should returned to
-   the caller.
-
-   Since the responder may order the RRs in the response so as to
-   indicate preference, the sender SHOULD preserve ordering in the
-   response to the querying application.
-
-2.3.  Responder Behavior
-
-   An LLMNR response MUST be sent to the sender via unicast.
-
-   Upon configuring an IP address, responders typically will synthesize
-   corresponding A, AAAA and PTR RRs so as to be able to respond to
-   LLMNR queries for these RRs.  An SOA RR is synthesized only when a
-   responder has another RR in addition to the SOA RR;  the SOA RR MUST
-   NOT be the only RR that a responder has.  However, in general whether
-   RRs are manually or automatically created is an implementation
-   decision.
-
-   For example, a host configured to have computer name "host1" and to
-   be a member of the "example.com" domain, and with IPv4 address
-   192.0.2.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be
-   authoritative for the following records:
-
-   host1. IN A 192.0.2.1
-          IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
-
-   host1.example.com. IN A 192.0.2.1
-          IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
-
-   1.2.0.192.in-addr.arpa. IN PTR host1.
-          IN PTR host1.example.com.
-
-   6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.
-   ip6.arpa IN PTR host1.  (line split for formatting reasons)
-            IN PTR host1.example.com.
-
-   An LLMNR responder might be further manually configured with the name
-   of a local mail server with an MX RR included in the "host1." and
-   "host1.example.com." records.
-
-   In responding to queries:
-
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 10]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-[a]  Responders MUST listen on UDP port 5355 on the link-scope multicast
-     address(es) defined in Section 2, and on UDP and TCP port 5355 on
-     the unicast address(es) that could be set as the source address(es)
-     when the responder responds to the LLMNR query.
-
-[b]  Responders MUST direct responses to the port from which the query
-     was sent.  When queries are received via TCP this is an inherent
-     part of the transport protocol.  For queries received by UDP the
-     responder MUST take note of the source port and use that as the
-     destination port in the response.  Responses MUST always be sent
-     from the port to which they were directed.
-
-[c]  Responders MUST respond to LLMNR queries for names and addresses
-     they are authoritative for.  This applies to both forward and
-     reverse lookups, with the exception of queries with the 'C' bit
-     set, which do not elicit a response.
-
-[d]  Responders MUST NOT respond to LLMNR queries for names they are not
-     authoritative for.
-
-[e]  Responders MUST NOT respond using data from the LLMNR or DNS
-     resolver cache.
-
-[f]  If a DNS server is running on a host that supports LLMNR, the DNS
-     server MUST respond to LLMNR queries only for the RRSets relating
-     to the host on which the server is running, but MUST NOT respond
-     for other records for which the server is authoritative.  DNS
-     servers also MUST NOT send LLMNR queries in order to resolve DNS
-     queries.
-
-[g]  If a responder is authoritative for a name, it MUST respond with
-     RCODE=0 and an empty answer section, if the type of query does not
-     match a RR that the responder has.
-
-   As an example, a host configured to respond to LLMNR queries for the
-   name "foo.example.com."  is authoritative for the name
-   "foo.example.com.".  On receiving an LLMNR query for an A RR with the
-   name "foo.example.com." the host authoritatively responds with A
-   RR(s) that contain IP address(es) in the RDATA of the resource
-   record.  If the responder has a AAAA RR, but no A RR, and an A RR
-   query is received, the responder would respond with RCODE=0 and an
-   empty answer section.
-
-   In conventional DNS terminology a DNS server authoritative for a zone
-   is authoritative for all the domain names under the zone apex except
-   for the branches delegated into separate zones.  Contrary to
-   conventional DNS terminology, an LLMNR responder is authoritative
-   only for the zone apex.
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 11]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-   For example the host "foo.example.com." is not authoritative for the
-   name "child.foo.example.com." unless the host is configured with
-   multiple names, including "foo.example.com."  and
-   "child.foo.example.com.".  As a result, "foo.example.com." cannot
-   reply to an LLMNR query for "child.foo.example.com." with RCODE=3
-   (authoritative name error).  The purpose of limiting the name
-   authority scope of a responder is to prevent complications that could
-   be caused by coexistence of two or more hosts with the names
-   representing child and parent (or grandparent) nodes in the DNS tree,
-   for example, "foo.example.com." and "child.foo.example.com.".
-
-   Without the restriction on authority an LLMNR query for an A resource
-   record for the name "child.foo.example.com." would result in two
-   authoritative responses: RCODE=3 (authoritative name error) received
-   from "foo.example.com.", and a requested A record - from
-   "child.foo.example.com.".  To prevent this ambiguity, LLMNR enabled
-   hosts could perform a dynamic update of the parent (or grandparent)
-   zone with a delegation to a child zone;  for example a host
-   "child.foo.example.com." could send a dynamic update for the NS and
-   glue A record to "foo.example.com.".  However, this approach
-   significantly complicates implementation of LLMNR and would not be
-   acceptable for lightweight hosts.
-
-2.4.  Unicast Queries and Responses
-
-   Unicast queries SHOULD be sent when:
-
-   [a] A sender repeats a query after it received a response
-       with the TC bit set to the previous LLMNR multicast query, or
-
-   [b] The sender queries for a PTR RR of a fully formed IP address
-       within the "in-addr.arpa" or "ip6.arpa" zones.
-
-   Unicast LLMNR queries MUST be done using TCP and the responses MUST
-   be sent using the same TCP connection as the query.  Senders MUST
-   support sending TCP queries, and responders MUST support listening
-   for TCP queries. If the sender of a TCP query receives a response to
-   that query not using TCP, the response MUST be silently discarded.
-
-   Unicast UDP queries MUST be silently discarded.
-
-   If TCP connection setup cannot be completed in order to send a
-   unicast TCP query, this is treated as a response that no records of
-   the specified type and class exist for the specified name (it is
-   treated the same as a response with RCODE=0 and an empty answer
-   section).
-
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 12]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-2.5.  "Off link" Detection
-
-   A sender MUST select a source address for LLMNR queries that is
-   assigned on the interface on which the query is sent.  The
-   destination address of an LLMNR query MUST be a link-scope multicast
-   address or a unicast address.
-
-   A responder MUST select a source address for responses that is
-   assigned on the interface on which the query was received.  The
-   destination address of an LLMNR response MUST be a unicast address.
-
-   On receiving an LLMNR query, the responder MUST check whether it was
-   sent to a LLMNR multicast addresses defined in Section 2.  If it was
-   sent to another multicast address, then the query MUST be silently
-   discarded.
-
-   Section 2.4 discusses use of TCP for LLMNR queries and responses.  In
-   composing an LLMNR query using TCP, the sender MUST set the Hop Limit
-   field in the IPv6 header and the TTL field in the IPv4 header of the
-   response to one (1).  The responder SHOULD set the TTL or Hop Limit
-   settings on the TCP listen socket to one (1) so that SYN-ACK packets
-   will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This
-   prevents an incoming connection from off-link since the sender will
-   not receive a SYN-ACK from the responder.
-
-   For UDP queries and responses, the Hop Limit field in the IPv6 header
-   and the TTL field in the IPV4 header MAY be set to any value.
-   However, it is RECOMMENDED that the value 255 be used for
-   compatibility with Apple Bonjour [Bonjour].
-
-   Implementation note:
-
-      In the sockets API for IPv4 [POSIX], the IP_TTL and
-      IP_MULTICAST_TTL socket options are used to set the TTL of
-      outgoing unicast and multicast packets. The IP_RECVTTL socket
-      option is available on some platforms to retrieve the IPv4 TTL of
-      received packets with recvmsg().  [RFC2292] specifies similar
-      options for setting and retrieving the IPv6 Hop Limit.
-
-2.6.  Responder Responsibilities
-
-   It is the responsibility of the responder to ensure that RRs returned
-   in LLMNR responses MUST only include values that are valid on the
-   local interface, such as IPv4 or IPv6 addresses valid on the local
-   link or names defended using the mechanism described in Section 4.
-   IPv4 Link-Local addresses are defined in [RFC3927].  IPv6 Link-Local
-   addresses are defined in [RFC2373].  In particular:
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 13]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-   [a] If a link-scope IPv6 address is returned in a AAAA RR,
-       that address MUST be valid on the local link over which
-       LLMNR is used.
-
-   [b] If an IPv4 address is returned, it MUST be reachable
-       through the link over which LLMNR is used.
-
-   [c] If a name is returned (for example in a CNAME, MX
-       or SRV RR), the name MUST be resolvable on the local
-       link over which LLMNR is used.
-
-   Where multiple addresses represent valid responses to a query, the
-   order in which the addresses are returned is as follows:
-
-   [d] If the source address of the query is a link-scope address,
-       then the responder SHOULD include a link-scope address first
-       in the response, if available.
-
-   [e] If the source address of the query is a routable address,
-       then the responder MUST include a routable address first
-       in the response, if available.
-
-2.7.  Retransmission and Jitter
-
-   An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine
-   when to retransmit an LLMNR query.  An LLMNR sender SHOULD either
-   estimate the LLMNR_TIMEOUT for each interface, or set a reasonably
-   high initial timeout.  Suggested constants are described in Section
-   7.
-
-   If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT,
-   then a sender SHOULD repeat the transmission of the query in order to
-   assure that it was received by a host capable of responding to it,
-   while increasing the value of LLMNR_TIMEOUT exponentially.  An LLMNR
-   query SHOULD NOT be sent more than three times.
-
-   Where LLMNR queries are sent using TCP, retransmission is handled by
-   the transport layer.  Queries with the 'C' bit set MUST be sent using
-   multicast UDP and MUST NOT be retransmitted.
-
-   An LLMNR sender cannot know in advance if a query sent using
-   multicast will receive no response, one response, or more than one
-   response.  An LLMNR sender MUST wait for LLMNR_TIMEOUT if no response
-   has been received, or if it is necessary to collect all potential
-   responses, such as if a uniqueness verification query is being made.
-   Otherwise an LLMNR sender SHOULD consider a multicast query answered
-   after the first response is received, if that response has the 'C'
-   bit clear.
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 14]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-   However, if the first response has the 'C' bit set, then the sender
-   SHOULD wait for LLMNR_TIMEOUT in order to collect all possible
-   responses.  When multiple valid answers are received, they may first
-   be concatenated, and then treated in the same manner that multiple
-   RRs received from the same DNS server would.  A unicast query sender
-   considers the query answered after the first response is received, so
-   that it only waits for LLMNR_TIMEOUT if no response has been
-   received.
-
-   Since it is possible for a response with the 'C' bit clear to be
-   followed by a response with the 'C' bit set, an LLMNR sender SHOULD
-   be prepared to process additional responses for the purposes of
-   conflict detection and LLMNR_TIMEOUT estimation, even after it has
-   considered a query answered.
-
-   In order to avoid synchronization, the transmission of each LLMNR
-   query and response SHOULD delayed by a time randomly selected from
-   the interval 0 to JITTER_INTERVAL. This delay MAY be avoided by
-   responders responding with names which they have previously
-   determined to be UNIQUE (see Section 4 for details).
-
-2.8.  DNS TTL
-
-   The responder should insert a pre-configured TTL value in the records
-   returned in an LLMNR response.  A default value of 30 seconds is
-   RECOMMENDED.  In highly dynamic environments (such as mobile ad-hoc
-   networks), the TTL value may need to be reduced.
-
-   Due to the TTL minimalization necessary when caching an RRset, all
-   TTLs in an RRset MUST be set to the same value.
-
-2.9.  Use of the Authority and Additional Sections
-
-   Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a
-   concept of delegation.  In LLMNR, the NS resource record type may be
-   stored and queried for like any other type, but it has no special
-   delegation semantics as it does in the DNS.  Responders MAY have NS
-   records associated with the names for which they are authoritative,
-   but they SHOULD NOT include these NS records in the authority
-   sections of responses.
-
-   Responders SHOULD insert an SOA record into the authority section of
-   a negative response, to facilitate negative caching as specified in
-   [RFC2308]. The TTL of this record is set from the minimum of the
-   MINIMUM field of the SOA record and the TTL of the SOA itself, and
-   indicates how long a resolver may cache the negative answer.  The
-   owner name of the SOA record (MNAME) MUST be set to the query name.
-   The RNAME, SERIAL, REFRESH, RETRY and EXPIRE values MUST be ignored
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 15]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-   by senders.  Negative responses without SOA records SHOULD NOT be
-   cached.
-
-   In LLMNR, the additional section is primarily intended for use by
-   EDNS0, TSIG and SIG(0).  As a result, unless the 'C' bit is set,
-   senders MAY only include pseudo RR-types in the additional section of
-   a query; unless the 'C' bit is set, responders MUST ignore the
-   additional section of queries containing other RR types.
-
-   In queries where the 'C' bit is set, the sender SHOULD include the
-   conflicting RRs in the additional section.  Since conflict
-   notifications are advisory, responders SHOULD log information from
-   the additional section, but otherwise MUST ignore the additional
-   section.
-
-   Senders MUST NOT cache RRs from the authority or additional section
-   of a response as answers, though they may be used for other purposes
-   such as negative caching.
-
-3.  Usage Model
-
-   Since LLMNR is a secondary name resolution mechanism, its usage is in
-   part determined by the behavior of DNS implementations.  This
-   document does not specify any changes to DNS resolver behavior, such
-   as searchlist processing or retransmission/failover policy.  However,
-   robust DNS resolver implementations are more likely to avoid
-   unnecessary LLMNR queries.
-
-   As noted in [DNSPerf], even when DNS servers are configured, a
-   significant fraction of DNS queries do not receive a response, or
-   result in negative responses due to missing inverse mappings or NS
-   records that point to nonexistent or inappropriate hosts.  This has
-   the potential to result in a large number of unnecessary LLMNR
-   queries.
-
-   [RFC1536] describes common DNS implementation errors and fixes.  If
-   the proposed fixes are implemented, unnecessary LLMNR queries will be
-   reduced substantially, and so implementation of [RFC1536] is
-   recommended.
-
-   For example, [RFC1536] Section 1 describes issues with retransmission
-   and recommends implementation of a retransmission policy based on
-   round trip estimates, with exponential backoff.  [RFC1536] Section 4
-   describes issues with failover, and recommends that resolvers try
-   another server when they don't receive a response to a query.  These
-   policies are likely to avoid unnecessary LLMNR queries.
-
-   [RFC1536] Section 3 describes zero answer bugs, which if addressed
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 16]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-   will also reduce unnecessary LLMNR queries.
-
-   [RFC1536] Section 6 describes name error bugs and recommended
-   searchlist processing that will reduce unnecessary RCODE=3
-   (authoritative name) errors, thereby also reducing unnecessary LLMNR
-   queries.
-
-3.1.  LLMNR Configuration
-
-   Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is
-   possible for a dual stack host to be configured with the address of a
-   DNS server over IPv4, while remaining unconfigured with a DNS server
-   suitable for use over IPv6.
-
-   In these situations, a dual stack host will send AAAA queries to the
-   configured DNS server over IPv4.  However, an IPv6-only host
-   unconfigured with a DNS server suitable for use over IPv6 will be
-   unable to resolve names using DNS.  Automatic IPv6 DNS configuration
-   mechanisms (such as [RFC3315] and [DNSDisc]) are not yet widely
-   deployed, and not all DNS servers support IPv6.  Therefore lack of
-   IPv6 DNS configuration may be a common problem in the short term, and
-   LLMNR may prove useful in enabling link-local name resolution over
-   IPv6.
-
-   Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315],
-   IPv6-only hosts may not be configured with a DNS server.  Where there
-   is no DNS server authoritative for the name of a host or the
-   authoritative DNS server does not support dynamic client update over
-   IPv6 or DHCPv6-based dynamic update, then an IPv6-only host will not
-   be able to do DNS dynamic update, and other hosts will not be able to
-   resolve its name.
-
-   For example, if the configured DNS server responds to a AAAA RR query
-   sent over IPv4 or IPv6 with an authoritative name error (RCODE=3) or
-   RCODE=0 and an empty answer section, then a AAAA RR query sent using
-   LLMNR over IPv6 may be successful in resolving the name of an
-   IPv6-only host on the local link.
-
-   Similarly, if a DHCPv4 server is available providing DNS server
-   configuration, and DNS server(s) exist which are authoritative for
-   the A RRs of local hosts and support either dynamic client update
-   over IPv4 or DHCPv4-based dynamic update, then the names of local
-   IPv4 hosts can be resolved over IPv4 without LLMNR.  However,  if no
-   DNS server is authoritative for the names of local hosts, or the
-   authoritative DNS server(s) do not support dynamic update, then LLMNR
-   enables linklocal name resolution over IPv4.
-
-   Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 17]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-   configure LLMNR on an interface.  The LLMNR Enable Option, described
-   in [LLMNREnable], can be used to explicitly enable or disable use of
-   LLMNR on an interface.  The LLMNR Enable Option does not determine
-   whether or in which order DNS itself is used for name resolution.
-   The order in which various name resolution mechanisms should be used
-   can be specified using the Name Service Search Option (NSSO) for DHCP
-   [RFC2937], using the LLMNR Enable Option code carried in the NSSO
-   data.
-
-   It is possible that DNS configuration mechanisms will go in and out
-   of service.  In these circumstances, it is possible for hosts within
-   an administrative domain to be inconsistent in their DNS
-   configuration.
-
-   For example, where DHCP is used for configuring DNS servers, one or
-   more DHCP servers can fail.  As a result, hosts configured prior to
-   the outage will be configured with a DNS server, while hosts
-   configured after the outage will not.  Alternatively, it is possible
-   for the DNS configuration mechanism to continue functioning while
-   configured DNS servers fail.
-
-   An outage in the DNS configuration mechanism may result in hosts
-   continuing to use LLMNR even once the outage is repaired.  Since
-   LLMNR only enables linklocal name resolution, this represents a
-   degradation in capabilities.  As a result, hosts without a configured
-   DNS server may wish to periodically attempt to obtain DNS
-   configuration if permitted by the configuration mechanism in use.  In
-   the absence of other guidance, a default retry interval of one (1)
-   minute is RECOMMENDED.
-
-4.  Conflict Resolution
-
-   By default, a responder SHOULD be configured to behave as though its
-   name is UNIQUE on each interface on which LLMNR is enabled.  However,
-   it is also possible to configure multiple responders to be
-   authoritative for the same name.  For example, multiple responders
-   MAY respond to a query for an A or AAAA type record for a cluster
-   name (assigned to multiple hosts in the cluster).
-
-   To detect duplicate use of a name, an administrator can use a name
-   resolution utility which employs LLMNR and lists both responses and
-   responders.  This would allow an administrator to diagnose behavior
-   and potentially to intervene and reconfigure LLMNR responders who
-   should not be configured to respond to the same name.
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 18]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-4.1.  Uniqueness Verification
-
-   Prior to sending an LLMNR response with the 'T' bit clear, a
-   responder configured with a UNIQUE name MUST verify that there is no
-   other host within the scope of LLMNR query propagation that is
-   authoritative for the same name on that interface.
-
-   Once a responder has verified that its name is UNIQUE, if it receives
-   an LLMNR query for that name, with the 'C' bit clear, it MUST
-   respond, with the 'T' bit clear. Prior to verifying that its name is
-   UNIQUE, a responder MUST set the 'T' bit in responses.
-
-   Uniqueness verification is carried out when the host:
-
-     - starts up or is rebooted
-     - wakes from sleep (if the network interface was inactive
-       during sleep)
-     - is configured to respond to LLMNR queries on an interface
-       enabled for transmission and reception of IP traffic
-     - is configured to respond to LLMNR queries using additional
-       UNIQUE resource records
-     - verifies the acquisition of a new IP address and configuration
-       on an interface
-
-   To verify uniqueness, a responder MUST send an LLMNR query with the
-   'C' bit clear, over all protocols on which it responds to LLMNR
-   queries (IPv4 and/or IPv6).  It is RECOMMENDED that responders verify
-   uniqueness of a name by sending a query for the name with type='ANY'.
-
-   If no response is received, the sender retransmits the query, as
-   specified in Section 2.7.  If a response is received, the sender MUST
-   check if the source address matches the address of any of its
-   interfaces; if so, then the response is not considered a conflict,
-   since it originates from the sender.  To avoid triggering conflict
-   detection, a responder that detects that it is connected to the same
-   link on multiple interfaces SHOULD set the 'C' bit in responses.
-
-   If a response is received with the 'T' bit clear, the responder MUST
-   NOT use the name in response to LLMNR queries received over any
-   protocol (IPv4 or IPv6).  If a response is received with the 'T' bit
-   set, the responder MUST check if the source IP address in the
-   response, interpreted as an unsigned integer, is less than the source
-   IP address in the query.  If so, the responder MUST NOT use the name
-   in response to LLMNR queries received over any protocol (IPv4 or
-   IPv6).  For the purpose of uniqueness verification, the contents of
-   the answer section in a response is irrelevant.
-
-   Periodically carrying out uniqueness verification in an attempt to
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 19]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-   detect name conflicts is not necessary, wastes network bandwidth, and
-   may actually be detrimental.  For example, if network links are
-   joined only briefly, and are separated again before any new
-   communication is initiated, temporary conflicts are benign and no
-   forced reconfiguration is required.  LLMNR responders SHOULD NOT
-   periodically attempt uniqueness verification.
-
-4.2.  Conflict Detection and Defense
-
-   Hosts on disjoint network links may configure the same name for use
-   with LLMNR.  If these separate network links are later joined or
-   bridged together, then there may be multiple hosts which are now on
-   the same link, trying to use the same name.
-
-   In order to enable ongoing detection of name conflicts, when an LLMNR
-   sender receives multiple LLMNR responses to a query, it MUST check if
-   the 'C' bit is clear in any of the responses.  If so, the sender
-   SHOULD send another query for the same name, type and class, this
-   time with the 'C' bit set, with the potentially conflicting resource
-   records included in the additional section.
-
-   Queries with the 'C' bit set are considered advisory and responders
-   MUST verify the existence of a conflict before acting on it.  A
-   responder receiving a query with the 'C' bit set MUST NOT respond.
-
-   If the query is for a UNIQUE name, then the responder MUST send its
-   own query for the same name, type and class, with the 'C' bit clear.
-   If a response is received, the sender MUST check if the source
-   address matches the address of any of its interfaces; if so, then the
-   response is not considered a conflict, since it originates from the
-   sender.  To avoid triggering conflict detection, a responder that
-   detects that it is connected to the same link on multiple interfaces
-   SHOULD set the 'C' bit in responses.
-
-   An LLMNR responder MUST NOT ignore conflicts once detected and SHOULD
-   log them.  Upon detecting a conflict, an LLMNR responder MUST
-   immediately stop using the conflicting name in response to LLMNR
-   queries received over any supported protocol, if the source IP
-   address in the response, interpreted as an unsigned integer, is less
-   than the source IP address in the uniqueness verification query.
-
-   After stopping the use of a name, the responder MAY elect to
-   configure a new name.  However, since name reconfiguration may be
-   disruptive, this is not required, and a responder may have been
-   configured to respond to multiple names so that alternative names may
-   already be available.  A host that has stopped the use of a name may
-   attempt uniqueness verification again after the expiration of the TTL
-   of the conflicting response.
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 20]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-4.3.  Considerations for Multiple Interfaces
-
-   A multi-homed host may elect to configure LLMNR on only one of its
-   active interfaces.  In many situations this will be adequate.
-   However, should a host need to configure LLMNR on more than one of
-   its active interfaces, there are some additional precautions it MUST
-   take.  Implementers who are not planning to support LLMNR on multiple
-   interfaces simultaneously may skip this section.
-
-   Where a host is configured to issue LLMNR queries on more than one
-   interface, each interface maintains its own independent LLMNR
-   resolver cache, containing the responses to LLMNR queries.
-
-   A multi-homed host checks the uniqueness of UNIQUE records as
-   described in Section 4.  The situation is illustrated in figure 1.
-
-        ----------  ----------
-         |      |    |      |
-        [A]    [myhost]   [myhost]
-
-      Figure 1.  Link-scope name conflict
-
-   In this situation, the multi-homed myhost will probe for, and defend,
-   its host name on both interfaces.  A conflict will be detected on one
-   interface, but not the other.  The multi-homed myhost will not be
-   able to respond with a host RR for "myhost" on the interface on the
-   right (see Figure 1).  The multi-homed host may, however, be
-   configured to use the "myhost" name on the interface on the left.
-
-   Since names are only unique per-link, hosts on different links could
-   be using the same name.  If an LLMNR client sends requests over
-   multiple interfaces, and receives replies from more than one, the
-   result returned to the client is defined by the implementation.  The
-   situation is illustrated in figure 2.
-
-        ----------  ----------
-         |      |    |     |
-        [A]    [myhost]   [A]
-
-
-      Figure 2.  Off-segment name conflict
-
-   If host myhost is configured to use LLMNR on both interfaces, it will
-   send LLMNR queries on both interfaces.  When host myhost sends a
-   query for the host RR for name "A" it will receive a response from
-   hosts on both interfaces.
-
-   Host myhost cannot distinguish between the situation shown in Figure
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 21]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-   2, and that shown in Figure 3 where no conflict exists.
-
-                [A]
-               |   |
-           -----   -----
-               |   |
-              [myhost]
-
-      Figure 3.  Multiple paths to same host
-
-   This illustrates that the proposed name conflict resolution mechanism
-   does not support detection or resolution of conflicts between hosts
-   on different links.  This problem can also occur with DNS when a
-   multi-homed host is connected to two different networks with
-   separated name spaces.  It is not the intent of this document to
-   address the issue of uniqueness of names within DNS.
-
-4.4.  API Issues
-
-   [RFC2553] provides an API which can partially solve the name
-   ambiguity problem for applications written to use this API, since the
-   sockaddr_in6 structure exposes the scope within which each scoped
-   address exists, and this structure can be used for both IPv4 (using
-   v4-mapped IPv6 addresses) and IPv6 addresses.
-
-   Following the example in Figure 2, an application on 'myhost' issues
-   the request getaddrinfo("A", ...) with ai_family=AF_INET6 and
-   ai_flags=AI_ALL|AI_V4MAPPED.  LLMNR requests will be sent from both
-   interfaces and the resolver library will return a list containing
-   multiple addrinfo structures, each with an associated sockaddr_in6
-   structure.  This list will thus contain the IPv4 and IPv6 addresses
-   of both hosts responding to the name 'A'.  Link-local addresses will
-   have a sin6_scope_id value that disambiguates which interface is used
-   to reach the address.  Of course, to the application, Figures 2 and 3
-   are still indistinguishable, but this API allows the application to
-   communicate successfully with any address in the list.
-
-5.  Security Considerations
-
-   LLMNR is a peer-to-peer name resolution protocol designed for use on
-   the local link.  While LLMNR limits the vulnerability of responders
-   to off-link senders, it is possible for an off-link responder to
-   reach a sender.
-
-   In scenarios such as public "hotspots" attackers can be present on
-   the same link.  These threats are most serious in wireless networks
-   such as 802.11, since attackers on a wired network will require
-   physical access to the network, while wireless attackers may mount
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 22]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-   attacks from a distance.  Link-layer security such as [IEEE-802.11i]
-   can be of assistance against these threats if it is available.
-
-   This section details security measures available to mitigate threats
-   from on and off-link attackers.
-
-5.1.  Denial of Service
-
-   Attackers may take advantage of LLMNR conflict detection by
-   allocating the same name, denying service to other LLMNR responders
-   and possibly allowing an attacker to receive packets destined for
-   other hosts.  By logging conflicts, LLMNR responders can provide
-   forensic evidence of these attacks.
-
-   An attacker may spoof LLMNR queries from a victim's address in order
-   to mount a denial of service attack.  Responders setting the IPv6 Hop
-   Limit or IPv4 TTL field to a value larger than one in an LLMNR UDP
-   response may be able to reach the victim across the Internet.
-
-   While LLMNR responders only respond to queries for which they are
-   authoritative and LLMNR does not provide wildcard query support, an
-   LLMNR response may be larger than the query, and an attacker can
-   generate multiple responses to a query for a name used by multiple
-   responders.  A sender may protect itself against unsolicited
-   responses by silently discarding them as rapidly as possible.
-
-5.2.  Spoofing
-
-   LLMNR is designed to prevent reception of queries sent by an off-link
-   attacker.  LLMNR requires that responders receiving UDP queries check
-   that they are sent to a link-scope multicast address.  However, it is
-   possible that some routers may not properly implement link-scope
-   multicast, or that link-scope multicast addresses may leak into the
-   multicast routing system.  To prevent successful setup of TCP
-   connections by an off-link sender, responders receiving a TCP SYN
-   reply with a TCP SYN-ACK with TTL set to one (1).
-
-   While it is difficult for an off-link attacker to send an LLMNR query
-   to a responder,  it is possible for an off-link attacker to spoof a
-   response to a query (such as an A or AAAA query for a popular
-   Internet host), and by using a TTL or Hop Limit field larger than one
-   (1), for the forged response to reach the LLMNR sender.  Since the
-   forged response will only be accepted if it contains a matching ID
-   field, choosing a pseudo-random ID field within queries provides some
-   protection against off-link responders.
-
-   Since LLMNR queries can be sent when DNS server(s) do not respond, an
-   attacker can execute a denial of service attack on the DNS server(s)
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 23]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-   and then poison the LLMNR cache by responding to an LLMNR query with
-   incorrect information.  As noted in "Threat Analysis of the Domain
-   Name System (DNS)" [RFC3833] these threats also exist with DNS, since
-   DNS response spoofing tools are available that can allow an attacker
-   to respond to a query more quickly than a distant DNS server.
-   However, while switched networks or link layer security may make it
-   difficult for an on-link attacker to snoop unicast DNS queries,
-   multicast LLMNR queries are propagated to all hosts on the link,
-   making it possible for an on-link attacker to spoof LLMNR responses
-   without having to guess the value of the ID field in the query.
-
-   Since LLMNR queries are sent and responded to on the local-link, an
-   attacker will need to respond more quickly to provide its own
-   response prior to arrival of the response from a legitimate
-   responder.   If an LLMNR query is sent for an off-link host, spoofing
-   a response in a timely way is not difficult, since a legitimate
-   response will never be received.
-
-   Limiting the situations in which LLMNR queries are sent, as described
-   in Section 2, is the best protection against these attacks.  If LLMNR
-   is given higher priority than DNS among the enabled name resolution
-   mechanisms, a denial of service attack on the DNS server would not be
-   necessary in order to poison the LLMNR cache, since LLMNR queries
-   would be sent even when the DNS server is available.  In addition,
-   the LLMNR cache, once poisoned, would take precedence over the DNS
-   cache, eliminating the benefits of cache separation.  As a result,
-   LLMNR is only used as a name resolution mechanism of last resort.
-
-5.3.  Authentication
-
-   LLMNR is a peer-to-peer name resolution protocol, and as a result,
-   it is often deployed in situations where no trust model can be
-   assumed.  This makes it difficult to apply existing DNS security
-   mechanisms to LLMNR.
-
-   LLMNR does not support "delegated trust" (CD or AD bits).  As a
-   result, unless LLMNR senders are DNSSEC aware, it is not feasible to
-   use DNSSEC [RFC4033] with LLMNR.
-
-   If authentication is desired, and a pre-arranged security
-   configuration is possible, then the following security mechanisms may
-   be used:
-
-[a]  LLMNR implementations MAY support TSIG [RFC2845] and/or SIG(0)
-     [RFC2931] security mechanisms. "DNS Name Service based on Secure
-     Multicast DNS for IPv6 Mobile Ad Hoc Networks" [LLMNRSec] describes
-     the use of TSIG to secure LLMNR responses, based on group keys.
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 24]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-[b]  IPsec ESP with a null-transform MAY be used to authenticate unicast
-     LLMNR queries and responses or LLMNR responses to multicast
-     queries.  In a small network without a certificate authority, this
-     can be most easily accomplished through configuration of a group
-     pre-shared key for trusted hosts.
-
-   Where these mechanisms cannot be supported, responses to LLMNR
-   queries may be unauthenticated.
-
-5.4.  Cache and Port Separation
-
-   In order to prevent responses to LLMNR queries from polluting the DNS
-   cache, LLMNR implementations MUST use a distinct, isolated cache for
-   LLMNR on each interface.  The use of separate caches is most
-   effective when LLMNR is used as a name resolution mechanism of last
-   resort, since this minimizes the opportunities for poisoning the
-   LLMNR cache, and decreases reliance on it.
-
-   LLMNR operates on a separate port from DNS, reducing the likelihood
-   that a DNS server will unintentionally respond to an LLMNR query.
-
-6.  IANA Considerations
-
-   This specification creates one new name space:  the reserved bits in
-   the LLMNR header.  These are allocated by IETF Consensus, in
-   accordance with BCP 26 [RFC2434].
-
-   LLMNR requires allocation of port 5355 for both TCP and UDP.
-
-   LLMNR requires allocation of link-scope multicast IPv4 address
-   224.0.0.252, as well as link-scope multicast IPv6 address
-   FF02:0:0:0:0:0:1:3.
-
-7.  Constants
-
-   The following timing constants are used in this protocol; they are
-   not intended to be user configurable.
-
-      JITTER_INTERVAL      100 ms
-      LLMNR_TIMEOUT        1 second (if set statically on all interfaces)
-                           100 ms (IEEE 802 media, including IEEE 802.11)
-
-8.  References
-
-8.1.  Normative References
-
-[RFC1035] Mockapetris, P., "Domain Names - Implementation and
-          Specification", RFC 1035, November 1987.
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 25]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
-          Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
-          Specification", RFC 2181, July 1997.
-
-[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
-          RFC 2308, March 1998.
-
-[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
-          Architecture", RFC 2373, July 1998.
-
-[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
-          Considerations Section in RFCs", BCP 26, RFC 2434, October
-          1998.
-
-[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
-          August 1999.
-
-[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
-          "Secret Key Transaction Authentication for DNS (TSIG)", RFC
-          2845, May 2000.
-
-[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
-          (SIG(0)s)", RFC 2931, September 2000.
-
-8.2.  Informative References
-
-[Bonjour] Cheshire, S. and M. Krochmal, "Multicast DNS", Internet draft
-          (work in progress), draft-cheshire-dnsext-multicastdns-05.txt,
-          June 2005.
-
-[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of
-          Caching", IEEE/ACM Transactions on Networking, Volume 10,
-          Number 5, pp. 589, October 2002.
-
-[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local
-          unicast addresses to communicate with recursive DNS servers",
-          Internet draft (work in progress), draft-ietf-ipv6-dns-
-          discovery-07.txt, October 2002.
-
-[IEEE-802.11i]
-          Institute of Electrical and Electronics Engineers, "Supplement
-          to Standard for Telecommunications and Information Exchange
-          Between Systems - LAN/MAN Specific Requirements - Part 11:
-          Wireless LAN Medium Access Control (MAC) and Physical Layer
-          (PHY) Specifications: Specification for Enhanced Security",
-          IEEE 802.11i, July 2004.
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 26]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-[LLMNREnable]
-          Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work
-          in progress), draft-guttman-mdns-enable-02.txt, April 2002.
-
-[LLMNRSec]
-          Jeong, J., Park, J. and H. Kim, "DNS Name Service based on
-          Secure Multicast DNS for IPv6 Mobile Ad Hoc Networks", ICACT
-          2004, Phoenix Park, Korea, February 9-11, 2004.
-
-[POSIX]   IEEE Std. 1003.1-2001 Standard for Information Technology --
-          Portable Operating System Interface (POSIX). Open Group
-          Technical Standard: Base Specifications, Issue 6, December
-          2001.  ISO/IEC 9945:2002.  http://www.opengroup.org/austin
-
-[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested
-          Fixes", RFC 1536, October 1993.
-
-[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
-          Recommendations for Security", RFC 1750, December 1994.
-
-[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
-          March 1997.
-
-[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6",
-          RFC 2292, February 1998.
-
-[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
-          2365, July 1998.
-
-[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic
-          Socket Interface Extensions for IPv6", RFC 2553, March 1999.
-
-[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC
-          2937, September 2000.
-
-[RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for
-          IPv6 (DHCPv6)", RFC 3315, July 2003.
-
-[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
-          System (DNS)", RFC 3833, August 2004.
-
-[RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration
-          of Link-Local IPv4 Addresses", RFC 3927, October 2004.
-
-[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
-          "DNS Security Introduction and Requirement", RFC 4033, March
-          2005.
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 27]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-Acknowledgments
-
-   This work builds upon original work done on multicast DNS by Bill
-   Manning and Bill Woodcock.  Bill Manning's work was funded under
-   DARPA grant #F30602-99-1-0523.  The authors gratefully acknowledge
-   their contribution to the current specification.  Constructive input
-   has also been received from Mark Andrews, Rob Austein, Randy Bush,
-   Stuart Cheshire, Ralph Droms, Robert Elz, James Gilroy, Olafur
-   Gudmundsson, Andreas Gustafsson, Erik Guttman, Myron Hattig,
-   Christian Huitema, Olaf Kolkman, Mika Liljeberg, Keith Moore,
-   Tomohide Nagashima, Thomas Narten, Erik Nordmark, Markku Savela, Mike
-   St. Johns, Sander Van-Valkenburg, and Brian Zill.
-
-Authors' Addresses
-
-   Bernard Aboba
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA 98052
-
-   Phone: +1 425 706 6605
-   EMail: bernarda@microsoft.com
-
-   Dave Thaler
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA 98052
-
-   Phone: +1 425 703 8835
-   EMail: dthaler@microsoft.com
-
-   Levon Esibov
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA 98052
-
-   EMail: levone@microsoft.com
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 28]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-Open Issues
-
-   Open issues with this specification are tracked on the following web
-   site:
-
-   http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html
-
-
-
-
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 29]
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-nsec3-04.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-nsec3-04.txt
deleted file mode 100644
index 8c6c5b1..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-nsec3-04.txt
+++ /dev/null
@@ -1,2352 +0,0 @@
-
-
-
-Network Working Group                                          B. Laurie
-Internet-Draft                                                 G. Sisson
-Expires: August 5, 2006                                        R. Arends
-                                                                 Nominet
-                                                           February 2006
-
-
-             DNSSEC Hash Authenticated Denial of Existence
-                       draft-ietf-dnsext-nsec3-04
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on August 5, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   The DNS Security Extensions introduces the NSEC resource record for
-   authenticated denial of existence.  This document introduces a new
-   resource record as an alternative to NSEC that provides measures
-   against zone enumeration and allows for gradual expansion of
-   delegation-centric zones.
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                 [Page 1]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
-     1.1.  Rationale  . . . . . . . . . . . . . . . . . . . . . . . .  4
-     1.2.  Reserved Words . . . . . . . . . . . . . . . . . . . . . .  4
-     1.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
-   2.  NSEC versus NSEC3  . . . . . . . . . . . . . . . . . . . . . .  5
-   3.  The NSEC3 Resource Record  . . . . . . . . . . . . . . . . . .  5
-     3.1.  NSEC3 RDATA Wire Format  . . . . . . . . . . . . . . . . .  6
-       3.1.1.  The Hash Function Field  . . . . . . . . . . . . . . .  6
-       3.1.2.  The Opt-In Flag Field  . . . . . . . . . . . . . . . .  7
-       3.1.3.  The Iterations Field . . . . . . . . . . . . . . . . .  8
-       3.1.4.  The Salt Length Field  . . . . . . . . . . . . . . . .  8
-       3.1.5.  The Salt Field . . . . . . . . . . . . . . . . . . . .  8
-       3.1.6.  The Next Hashed Ownername Field  . . . . . . . . . . .  9
-       3.1.7.  The Type Bit Maps Field  . . . . . . . . . . . . . . .  9
-     3.2.  The NSEC3 RR Presentation Format . . . . . . . . . . . . . 10
-   4.  Creating Additional NSEC3 RRs for Empty Non-Terminals  . . . . 11
-   5.  Calculation of the Hash  . . . . . . . . . . . . . . . . . . . 11
-   6.  Including NSEC3 RRs in a Zone  . . . . . . . . . . . . . . . . 11
-   7.  Responding to NSEC3 Queries  . . . . . . . . . . . . . . . . . 12
-   8.  Special Considerations . . . . . . . . . . . . . . . . . . . . 13
-     8.1.  Proving Nonexistence . . . . . . . . . . . . . . . . . . . 13
-     8.2.  Salting  . . . . . . . . . . . . . . . . . . . . . . . . . 14
-     8.3.  Iterations . . . . . . . . . . . . . . . . . . . . . . . . 15
-     8.4.  Hash Collision . . . . . . . . . . . . . . . . . . . . . . 16
-       8.4.1.  Avoiding Hash Collisions during generation . . . . . . 16
-       8.4.2.  Second Preimage Requirement Analysis . . . . . . . . . 16
-       8.4.3.  Possible Hash Value Truncation Method  . . . . . . . . 17
-       8.4.4.  Server Response to a Run-time Collision  . . . . . . . 17
-       8.4.5.  Parameters that Cover the Zone . . . . . . . . . . . . 18
-   9.  Performance Considerations . . . . . . . . . . . . . . . . . . 18
-   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
-   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 18
-   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
-     12.1. Normative References . . . . . . . . . . . . . . . . . . . 21
-     12.2. Informative References . . . . . . . . . . . . . . . . . . 22
-   Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .
-   Appendix A.  Example Zone  . . . . . . . . . . . . . . . . . . . . 22
-   Appendix B.  Example Responses . . . . . . . . . . . . . . . . . . 27
-     B.1.  answer . . . . . . . . . . . . . . . . . . . . . . . . . . 27
-       B.1.1.  Authenticating the Example DNSKEY RRset  . . . . . . . 29
-     B.2.  Name Error . . . . . . . . . . . . . . . . . . . . . . . . 30
-     B.3.  No Data Error  . . . . . . . . . . . . . . . . . . . . . . 32
-       B.3.1.  No Data Error, Empty Non-Terminal  . . . . . . . . . . 33
-     B.4.  Referral to Signed Zone  . . . . . . . . . . . . . . . . . 34
-     B.5.  Referral to Unsigned Zone using the Opt-In Flag  . . . . . 35
-     B.6.  Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 36
-
-
-
-Laurie, et al.           Expires August 5, 2006                 [Page 2]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-     B.7.  Wildcard No Data Error . . . . . . . . . . . . . . . . . . 38
-     B.8.  DS Child Zone No Data Error  . . . . . . . . . . . . . . . 39
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
-   Intellectual Property and Copyright Statements . . . . . . . . . . 42
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                 [Page 3]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-1.  Introduction
-
-1.1.  Rationale
-
-   The DNS Security Extensions included the NSEC RR to provide
-   authenticated denial of existence.  Though the NSEC RR meets the
-   requirements for authenticated denial of existence, it introduced a
-   side-effect in that the contents of a zone can be enumerated.  This
-   property introduces undesired policy issues.
-
-   An enumerated zone can be used either directly as a source of
-   probable e-mail addresses for spam, or indirectly as a key for
-   multiple WHOIS queries to reveal registrant data which many
-   registries may be under strict legal obligations to protect.  Many
-   registries therefore prohibit copying of their zone file; however the
-   use of NSEC RRs renders these policies unenforceable.
-
-   A second problem was the requirement that the existence of all record
-   types in a zone - including unsigned delegation points - must be
-   accounted for, despite the fact that unsigned delegation point
-   records are not signed.  This requirement has a side-effect that the
-   overhead of signed zones is not related to the increase in security
-   of subzones.  This requirement does not allow the zones' size to grow
-   in relation to the growth of signed subzones.
-
-   In the past, solutions (draft-ietf-dnsext-dnssec-opt-in) have been
-   proposed as a measure against these side effects but at the time were
-   regarded as secondary over the need to have a stable DNSSEC
-   specification.  With (draft-vixie-dnssec-ter) [14] a graceful
-   transition path to future enhancements is introduced, while current
-   DNSSEC deployment can continue.  This document presents the NSEC3
-   Resource Record which mitigates these issues with the NSEC RR.
-
-   The reader is assumed to be familiar with the basic DNS and DNSSEC
-   concepts described in RFC 1034 [1], RFC 1035 [2], RFC 4033 [3], RFC
-   4034 [4], RFC 4035 [5] and subsequent RFCs that update them: RFC 2136
-   [6], RFC2181 [7] and RFC2308 [8].
-
-1.2.  Reserved Words
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [9].
-
-1.3.  Terminology
-
-   The practice of discovering the contents of a zone, i.e. enumerating
-   the domains within a zone, is known as "zone enumeration".  Zone
-
-
-
-Laurie, et al.           Expires August 5, 2006                 [Page 4]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   enumeration was not practical prior to the introduction of DNSSEC.
-
-   In this document the term "original ownername" refers to a standard
-   ownername.  Because this proposal uses the result of a hash function
-   over the original (unmodified) ownername, this result is referred to
-   as "hashed ownername".
-
-   "Hash order" means the order in which hashed ownernames are arranged
-   according to their numerical value, treating the leftmost (lowest
-   numbered) octet as the most significant octet.  Note that this is the
-   same as the canonical ordering specified in RFC 4034 [4].
-
-   An "empty non-terminal" is a domain name that owns no resource
-   records but has subdomains that do.
-
-   The "closest encloser" of a (nonexistent) domain name is the longest
-   domain name, including empty non-terminals, that matches the
-   rightmost part of the nonexistent domain name.
-
-   "Base32 encoding" is "Base 32 Encoding with Extended Hex Alphabet" as
-   specified in RFC 3548bis [15].
-
-
-2.  NSEC versus NSEC3
-
-   This document does NOT obsolete the NSEC record, but gives an
-   alternative for authenticated denial of existence.  NSEC and NSEC3
-   RRs can not co-exist in a zone.  See draft-vixie-dnssec-ter [14] for
-   a signaling mechanism to allow for graceful transition towards NSEC3.
-
-
-3.  The NSEC3 Resource Record
-
-   The NSEC3 RR provides Authenticated Denial of Existence for DNS
-   Resource Record Sets.
-
-   The NSEC3 Resource Record (RR) lists RR types present at the NSEC3
-   RR's original ownername.  It includes the next hashed ownername in
-   the hash order of the zone.  The complete set of NSEC3 RRs in a zone
-   indicates which RRsets exist for the original ownername of the RRset
-   and form a chain of hashed ownernames in the zone.  This information
-   is used to provide authenticated denial of existence for DNS data, as
-   described in RFC 4035 [5].  To provide protection against zone
-   enumeration, the ownernames used in the NSEC3 RR are cryptographic
-   hashes of the original ownername prepended to the name of the zone.
-   The NSEC3 RR indicates which hash function is used to construct the
-   hash, which salt is used, and how many iterations of the hash
-   function are performed over the original ownername.  The hashing
-
-
-
-Laurie, et al.           Expires August 5, 2006                 [Page 5]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   technique is described fully in Section 5.
-
-   Hashed ownernames of unsigned delegations may be excluded from the
-   chain.  An NSEC3 record which span covers the hash of an unsigned
-   delegation's ownername is referred to as an Opt-In NSEC3 record and
-   is indicated by the presence of a flag.
-
-   The ownername for the NSEC3 RR is the base32 encoding of the hashed
-   ownername prepended to the name of the zone..
-
-   The type value for the NSEC3 RR is XX.
-
-   The NSEC3 RR RDATA format is class independent and is described
-   below.
-
-   The class MUST be the same as the original ownername's class.
-
-   The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL
-   field.  This is in the spirit of negative caching [8].
-
-3.1.  NSEC3 RDATA Wire Format
-
-   The RDATA of the NSEC3 RR is as shown below:
-
-                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   | Hash Function |O|                Iterations                   |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |  Salt Length  |                     Salt                      /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   /                     Next Hashed Ownername                     /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   /                         Type Bit Maps                         /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   "O" is the Opt-In Flag field.
-
-3.1.1.  The Hash Function Field
-
-   The Hash Function field identifies the cryptographic hash function
-   used to construct the hash-value.
-
-   The values are as defined for the DS record (see RFC 3658 [10]).
-
-   On reception, a resolver MUST ignore an NSEC3 RR with an unknown hash
-   function value.
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                 [Page 6]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-3.1.2.  The Opt-In Flag Field
-
-   The Opt-In Flag field indicates whether this NSEC3 RR covers unsigned
-   delegations.
-
-   In DNSSEC, NS RRsets at delegation points are not signed, and may be
-   accompanied by a DS record.  The security status of the subzone is
-   determined by the presence or absence of the DS RRset,
-   cryptographically proven by the NSEC record or the signed DS RRset.
-   The presence of the Opt-In flag expands this definition by allowing
-   insecure delegations to exist within an otherwise signed zone without
-   the corresponding NSEC3 record at the delegation's (hashed) owner
-   name.  These delegations are proven insecure by using a covering
-   NSEC3 record.
-
-   Resolvers must be able to distinguish between NSEC3 records and
-   Opt-In NSEC3 records.  This is accomplished by setting the Opt-In
-   flag of the NSEC3 records that cover (or potentially cover) insecure
-   delegation nodes.
-
-   An Opt-In NSEC3 record does not assert the existence or non-existence
-   of the insecure delegations that it covers.  This allows for the
-   addition or removal of these delegations without recalculating or
-   resigning records in the NSEC3 chain.  However, Opt-In NSEC3 records
-   do assert the (non)existence of other, authoritative RRsets.
-
-   An Opt-In NSEC3 record MAY have the same original owner name as an
-   insecure delegation.  In this case, the delegation is proven insecure
-   by the lack of a DS bit in type map and the signed NSEC3 record does
-   assert the existence of the delegation.
-
-   Zones using Opt-In MAY contain a mixture of Opt-In NSEC3 records and
-   non-Opt-In NSEC3 records.  If an NSEC3 record is not Opt-In, there
-   MUST NOT be any hashed ownernames of insecure delegations (nor any
-   other records) between it and the RRsets indicated by the 'Next
-   Hashed Ownername' in the NSEC3 RDATA.  If it is Opt-In, there MUST
-   only be hashed ownernames of insecure delegations between it and the
-   next node indicated by the 'Next Hashed Ownername' in the NSEC3
-   RDATA.
-
-   In summary,
-   o  An Opt-In NSEC3 type is identified by an Opt-In Flag field value
-      of 1.
-   o  A non Opt-In NSEC3 type is identified by an Opt-In Flag field
-      value of 0.
-   and,
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                 [Page 7]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   o  An Opt-In NSEC3 record does not assert the non-existence of a hash
-      ownername between its ownername and next hashed ownername,
-      although it does assert that any hashed name in this span MUST be
-      of an insecure delegation.
-   o  An Opt-In NSEC3 record does assert the (non)existence of RRsets
-      with the same hashed owner name.
-
-3.1.3.  The Iterations Field
-
-   The Iterations field defines the number of times the hash has been
-   iterated.  More iterations results in greater resiliency of the hash
-   value against dictionary attacks, but at a higher cost for both the
-   server and resolver.  See Section 5 for details of this field's use.
-
-   Iterations make an attack more costly by making the hash computation
-   more computationally intensive, e.g. by iterating the hash function a
-   number of times.
-
-   When generating a few hashes this performance loss will not be a
-   problem, as a validator can handle a delay of a few milliseconds.
-   But when doing a dictionary attack it will also multiply the attack
-   workload by a factor, which is a problem for the attacker.
-
-3.1.4.  The Salt Length Field
-
-   The salt length field defines the length of the salt in octets.
-
-3.1.5.  The Salt Field
-
-   The Salt field is not present when the Salt Length Field has a value
-   of 0.
-
-   The Salt field is appended to the original ownername before hashing
-   in order to defend against precalculated dictionary attacks.  See
-   Section 5 for details on how the salt is used.
-
-   Salt is used to make dictionary attacks using precomputation more
-   costly.  A dictionary can only be computed after the attacker has the
-   salt, hence a new salt means that the dictionary has to be
-   regenerated with the new salt.
-
-   There MUST be a complete set of NSEC3 records covering the entire
-   zone that use the same salt value.  The requirement exists so that,
-   given any qname within a zone, at least one covering NSEC3 RRset may
-   be found.  While it may be theoretically possible to produce a set of
-   NSEC3s that use different salts that cover the entire zone, it is
-   computationally infeasible to generate such a set.  See Section 8.2
-   for further discussion.
-
-
-
-Laurie, et al.           Expires August 5, 2006                 [Page 8]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   The salt value SHOULD be changed from time to time - this is to
-   prevent the use of a precomputed dictionary to reduce the cost of
-   enumeration.
-
-3.1.6.  The Next Hashed Ownername Field
-
-   The Next Hashed Ownername field contains the next hashed ownername in
-   hash order.  That is, given the set of all hashed owernames, the Next
-   Hashed Ownername contains the hash value that immediately follows the
-   owner hash value for the given NSEC3 record.  The value of the Next
-   Hashed Ownername Field in the last NSEC3 record in the zone is the
-   same as the ownername of the first NSEC3 RR in the zone in hash
-   order.
-
-   Hashed ownernames of glue RRsets MUST NOT be listed in the Next
-   Hashed Ownername unless at least one authoritative RRset exists at
-   the same ownername.  Hashed ownernames of delegation NS RRsets MUST
-   be listed if the Opt-In bit is clear.
-
-   Note that the Next Hashed Ownername field is not encoded, unlike the
-   NSEC3 RR's ownername.  It is the unmodified binary hash value.  It
-   does not include the name of the containing zone.
-
-   The length of this field is the length of the hash value produced by
-   the hash function selected by the Hash Function field.
-
-3.1.7.  The Type Bit Maps Field
-
-   The Type Bit Maps field identifies the RRset types which exist at the
-   NSEC3 RR's original ownername.
-
-   The Type bits for the NSEC3 RR and RRSIG RR MUST be set during
-   generation, and MUST be ignored during processing.
-
-   The RR type space is split into 256 window blocks, each representing
-   the low-order 8 bits of the 16-bit RR type space.  Each block that
-   has at least one active RR type is encoded using a single octet
-   window number (from 0 to 255), a single octet bitmap length (from 1
-   to 32) indicating the number of octets used for the window block's
-   bitmap, and up to 32 octets (256 bits) of bitmap.
-
-   Blocks are present in the NSEC3 RR RDATA in increasing numerical
-   order.
-
-   "|" denotes concatenation
-
-   Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) +
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                 [Page 9]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   Each bitmap encodes the low-order 8 bits of RR types within the
-   window block, in network bit order.  The first bit is bit 0.  For
-   window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds
-   to RR type 2 (NS), and so forth.  For window block 1, bit 1
-   corresponds to RR type 257, bit 2 to RR type 258.  If a bit is set to
-   1, it indicates that an RRset of that type is present for the NSEC3
-   RR's ownername.  If a bit is set to 0, it indicates that no RRset of
-   that type is present for the NSEC3 RR's ownername.
-
-   Since bit 0 in window block 0 refers to the non-existing RR type 0,
-   it MUST be set to 0.  After verification, the validator MUST ignore
-   the value of bit 0 in window block 0.
-
-   Bits representing Meta-TYPEs or QTYPEs as specified in RFC 2929 [11]
-   (section 3.1) or within the range reserved for assignment only to
-   QTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear in
-   zone data.  If encountered, they must be ignored upon reading.
-
-   Blocks with no types present MUST NOT be included.  Trailing zero
-   octets in the bitmap MUST be omitted.  The length of each block's
-   bitmap is determined by the type code with the largest numerical
-   value, within that block, among the set of RR types present at the
-   NSEC3 RR's actual ownername.  Trailing zero octets not specified MUST
-   be interpreted as zero octets.
-
-3.2.  The NSEC3 RR Presentation Format
-
-   The presentation format of the RDATA portion is as follows:
-
-   The Opt-In Flag Field is represented as an unsigned decimal integer.
-   The value is either 0 or 1.
-
-   The Hash field is presented as a mnemonic of the hash or as an
-   unsigned decimal integer.  The value has a maximum of 127.
-
-   The Iterations field is presented as an unsigned decimal integer.
-
-   The Salt Length field is not presented.
-
-   The Salt field is represented as a sequence of case-insensitive
-   hexadecimal digits.  Whitespace is not allowed within the sequence.
-   The Salt Field is represented as "-" (without the quotes) when the
-   Salt Length field has value 0.
-
-   The Next Hashed Ownername field is represented as a sequence of case-
-   insensitive base32 digits, without whitespace.
-
-   The Type Bit Maps Field is represented as a sequence of RR type
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 10]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   mnemonics.  When the mnemonic is not known, the TYPE representation
-   as described in RFC 3597 [12] (section 5) MUST be used.
-
-
-4.  Creating Additional NSEC3 RRs for Empty Non-Terminals
-
-   In order to prove the non-existence of a record that might be covered
-   by a wildcard, it is necessary to prove the existence of its closest
-   encloser.  A closest encloser might be an empty non-terminal.
-
-   Additional NSEC3 RRs are generated for empty non-terminals.  These
-   additional NSEC3 RRs are identical in format to NSEC3 RRs that cover
-   existing RRs in the zone except that their type-maps only indicated
-   the existence of an NSEC3 RRset and an RRSIG RRset.
-
-   This relaxes the requirement in Section 2.3 of RFC4035 that NSEC RRs
-   not appear at names that did not exist before the zone was signed.
-   [Comment.1]
-
-
-5.  Calculation of the Hash
-
-   Define H(x) to be the hash of x using the hash function selected by
-   the NSEC3 record and || to indicate concatenation.  Then define:
-
-   IH(salt,x,0)=H(x || salt)
-
-   IH(salt,x,k)=H(IH(salt,x,k-1) || salt) if k > 0
-
-   Then the calculated hash of an ownername is
-   IH(salt,ownername,iterations-1), where the ownername is the canonical
-   form.
-
-   The canonical form of the ownername is the wire format of the
-   ownername where:
-   1.  The ownername is fully expanded (no DNS name compression) and
-       fully qualified;
-   2.  All uppercase US-ASCII letters are replaced by the corresponding
-       lowercase US-ASCII letters;
-   3.  If the ownername is a wildcard name, the ownername is in its
-       original unexpanded form, including the "*" label (no wildcard
-       substitution);
-   This form is as defined in section 6.2 of RFC 4034 ([4]).
-
-
-6.  Including NSEC3 RRs in a Zone
-
-   Each ownername within the zone that owns authoritative RRsets MUST
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 11]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   have a corresponding NSEC3 RR.  Ownernames that correspond to
-   unsigned delegations MAY have a corresponding NSEC3 RR, however, if
-   there is not, there MUST be a covering NSEC3 RR with the Opt-In flag
-   set to 1.  Other non-authoritative RRs are not included in the set of
-   NSEC3 RRs.
-
-   Each empty non-terminal MUST have an NSEC3 record.
-
-   The TTL value for any NSEC3 RR SHOULD be the same as the minimum TTL
-   value field in the zone SOA RR.
-
-   The type bitmap of every NSEC3 resource record in a signed zone MUST
-   indicate the presence of both the NSEC3 RR type itself and its
-   corresponding RRSIG RR type.
-
-   The following steps describe the proper construction of NSEC3
-   records.  [Comment.2]
-   1.  For each unique original ownername in the zone, add an NSEC3
-       RRset.  If Opt-In is being used, ownernames of unsigned
-       delegations may be excluded, but must be considered for empty-
-       non-terminals.  The ownername of the NSEC3 RR is the hashed
-       equivalent of the original owner name, prepended to the zone
-       name.  The Next Hashed Ownername field is left blank for the
-       moment.  If Opt-In is being used, set the Opt-In bit to one.
-   2.  For each RRset at the original owner name, set the corresponding
-       bit in the type bit map.
-   3.  If the difference in number of labels between the apex and the
-       original ownername is greater then 1, additional NSEC3s need to
-       be added for every empty non-terminal between the apex and the
-       original ownername.  This process may generate NSEC3 RRs with
-       duplicate hashed ownernames.
-   4.  Sort the set of NSEC3 RRs into hash order.  Hash order is the
-       ascending numerical order of the non-encoded hash values.
-   5.  Combine NSEC3 RRs with identical hashed ownernames by replacing
-       with a single NSEC3 RR with the type map consisting of the union
-       of the types represented by the set of NSEC3 RRs.
-   6.  In each NSEC3 RR, insert the Next Hashed Ownername by using the
-       value of the next NSEC3 RR in hash order.  The Next Hashed
-       Ownername of the last NSEC3 in the zone contains the value of the
-       hashed ownername of the first NSEC3 in the hash order.
-
-
-7.  Responding to NSEC3 Queries
-
-   Since NSEC3 ownernames are not represented in the NSEC3 chain like
-   other zone ownernames, direct queries for NSEC3 ownernames present a
-   special case.
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 12]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   The special case arises when the following are all true:
-   o  The QNAME equals an existing NSEC3 ownername, and
-   o  There are no other record types that exist at QNAME, and
-   o  The QTYPE does not equal NSEC3.
-   These conditions describe a particular case: the answer should be a
-   NOERROR/NODATA response, but there is no NSEC3 RRset for H(QNAME) to
-   include in the authority section.
-
-   However, the NSEC3 RRset with ownername equal to QNAME is able to
-   prove its own existence.  Thus, when answering this query, the
-   authoritative server MUST include the NSEC3 RRset whose ownername
-   equals QNAME.  This RRset proves that QNAME is an existing name with
-   types NSEC3 and RRSIG.  The authoritative server MUST also include
-   the NSEC3 RRset that covers the hash of QNAME.  This RRset proves
-   that no other types exist.
-
-   When validating a NOERROR/NODATA response, validators MUST check for
-   a NSEC3 RRset with ownername equals to QNAME, and MUST accept that
-   (validated) NSEC3 RRset as proof that QNAME exists.  The validator
-   MUST also check for an NSEC3 RRset that covers the hash of QNAME as
-   proof that QTYPE doesn't exist.
-
-   Other cases where the QNAME equals an existing NSEC3 ownername may be
-   answered normally.
-
-
-8.  Special Considerations
-
-   The following paragraphs clarify specific behaviour explain special
-   considerations for implementations.
-
-8.1.  Proving Nonexistence
-
-   If a wildcard resource record appears in a zone, its asterisk label
-   is treated as a literal symbol and is treated in the same way as any
-   other ownername for purposes of generating NSEC3 RRs.  RFC 4035 [5]
-   describes the impact of wildcards on authenticated denial of
-   existence.
-
-   In order to prove there exist no RRs for a domain, as well as no
-   source of synthesis, an RR must be shown for the closest encloser,
-   and non-existence must be shown for all closer labels and for the
-   wildcard at the closest encloser.
-
-   This can be done as follows.  If the QNAME in the query is
-   omega.alfa.beta.example, and the closest encloser is beta.example
-   (the nearest ancestor to omega.alfa.beta.example), then the server
-   should return an NSEC3 that demonstrates the nonexistence of
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 13]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   alfa.beta.example, an NSEC3 that demonstrates the nonexistence of
-   *.beta.example, and an NSEC3 that demonstrates the existence of
-   beta.example.  This takes between one and three NSEC3 records, since
-   a single record can, by chance, prove more than one of these facts.
-
-   When a verifier checks this response, then the existence of
-   beta.example together with the non-existence of alfa.beta.example
-   proves that the closest encloser is indeed beta.example.  The non-
-   existence of *.beta.example shows that there is no wildcard at the
-   closest encloser, and so no source of synthesis for
-   omega.alfa.beta.example.  These two facts are sufficient to satisfy
-   the resolver that the QNAME cannot be resolved.
-
-   In practice, since the NSEC3 owner and next names are hashed, if the
-   server responds with an NSEC3 for beta.example, the resolver will
-   have to try successively longer names, starting with example, moving
-   to beta.example, alfa.beta.example, and so on, until one of them
-   hashes to a value that matches the interval (but not the ownername
-   nor next owner name) of one of the returned NSEC3s (this name will be
-   alfa.beta.example).  Once it has done this, it knows the closest
-   encloser (i.e. beta.example), and can then easily check the other two
-   required proofs.
-
-   Note that it is not possible for one of the shorter names tried by
-   the resolver to be denied by one of the returned NSEC3s, since, by
-   definition, all these names exist and so cannot appear within the
-   range covered by an NSEC3.  Note, however, that the first name that
-   the resolver tries MUST be the apex of the zone, since names above
-   the apex could be denied by one of the returned NSEC3s.
-
-8.2.  Salting
-
-   Augmenting original ownernames with salt before hashing increases the
-   cost of a dictionary of pre-generated hash-values.  For every bit of
-   salt, the cost of a precomputed dictionary doubles (because there
-   must be an entry for each word combined with each possible salt
-   value).  The NSEC3 RR can use a maximum of 2040 bits (255 octets) of
-   salt, multiplying the cost by 2^2040.  This means that an attacker
-   must, in practice, recompute the dictionary each time the salt is
-   changed.
-
-   There MUST be at least one complete set of NSEC3s for the zone using
-   the same salt value.
-
-   The salt SHOULD be changed periodically to prevent precomputation
-   using a single salt.  It is RECOMMENDED that the salt be changed for
-   every resigning.
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 14]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   Note that this could cause a resolver to see records with different
-   salt values for the same zone.  This is harmless, since each record
-   stands alone (that is, it denies the set of ownernames whose hashes,
-   using the salt in the NSEC3 record, fall between the two hashes in
-   the NSEC3 record) - it is only the server that needs a complete set
-   of NSEC3 records with the same salt in order to be able to answer
-   every possible query.
-
-   There is no prohibition with having NSEC3 with different salts within
-   the same zone.  However, in order for authoritative servers to be
-   able to consistently find covering NSEC3 RRs, the authoritative
-   server MUST choose a single set of parameters (algorithm, salt, and
-   iterations) to use when selecting NSEC3s.  In the absence of any
-   other metadata, the server does this by using the parameters from the
-   zone apex NSEC3, recognizable by the presence of the SOA bit in the
-   type map.  If there is more than one NSEC3 record that meets this
-   description, then the server may arbitrarily choose one.  Because of
-   this, if there is a zone apex NSEC3 RR within a zone, it MUST be part
-   of a complete NSEC3 set.  Conversely, if there exists an incomplete
-   set of NSEC3 RRs using the same parameters within a zone, there MUST
-   NOT be an NSEC3 RR using those parameters with the SOA bit set.
-
-8.3.  Iterations
-
-   Setting the number of iterations used allows the zone owner to choose
-   the cost of computing a hash, and so the cost of generating a
-   dictionary.  Note that this is distinct from the effect of salt,
-   which prevents the use of a single precomputed dictionary for all
-   time.
-
-   Obviously the number of iterations also affects the zone owner's cost
-   of signing the zone as well as the verifiers cost of verifying the
-   zone.  We therefore impose an upper limit on the number of
-   iterations.  We base this on the number of iterations that
-   approximately doubles the cost of signing the zone.
-
-   A zone owner MUST NOT use a value higher than shown in the table
-   below for iterations.  A resolver MAY treat a response with a higher
-   value as bogus.
-
-                       +--------------+------------+
-                       | RSA Key Size | Iterations |
-                       +--------------+------------+
-                       | 1024         | 3,000      |
-                       | 2048         | 20,000     |
-                       | 4096         | 150,000    |
-                       +--------------+------------+
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 15]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-                       +--------------+------------+
-                       | DSA Key Size | Iterations |
-                       +--------------+------------+
-                       | 1024         | 1,500      |
-                       | 2048         | 5,000      |
-                       +--------------+------------+
-
-   This table is based on 150,000 SHA-1's per second, 50 RSA signs per
-   second for 1024 bit keys, 7 signs per second for 2048 bit keys, 1
-   sign per second for 4096 bit keys, 100 DSA signs per second for 1024
-   bit keys and 30 signs per second for 2048 bit keys.
-
-   Note that since RSA verifications are 10-100 times faster than
-   signatures (depending on key size), in the case of RSA the legal
-   values of iterations can substantially increase the cost of
-   verification.
-
-8.4.  Hash Collision
-
-   Hash collisions occur when different messages have the same hash
-   value.  The expected number of domain names needed to give a 1 in 2
-   chance of a single collision is about 2^(n/2) for a hash of length n
-   bits (i.e. 2^80 for SHA-1).  Though this probability is extremely
-   low, the following paragraphs deal with avoiding collisions and
-   assessing possible damage in the event of an attack using hash
-   collisions.
-
-8.4.1.  Avoiding Hash Collisions during generation
-
-   During generation of NSEC3 RRs, hash values are supposedly unique.
-   In the (academic) case of a collision occurring, an alternative salt
-   MUST be chosen and all hash values MUST be regenerated.
-
-8.4.2.  Second Preimage Requirement Analysis
-
-   A cryptographic hash function has a second-preimage resistance
-   property.  The second-preimage resistance property means that it is
-   computationally infeasible to find another message with the same hash
-   value as a given message, i.e. given preimage X, to find a second
-   preimage X' != X such that hash(X) = hash(X').  The work factor for
-   finding a second preimage is of the order of 2^160 for SHA-1.  To
-   mount an attack using an existing NSEC3 RR, an adversary needs to
-   find a second preimage.
-
-   Assuming an adversary is capable of mounting such an extreme attack,
-   the actual damage is that a response message can be generated which
-   claims that a certain QNAME (i.e. the second pre-image) does exist,
-   while in reality QNAME does not exist (a false positive), which will
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 16]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   either cause a security aware resolver to re-query for the non-
-   existent name, or to fail the initial query.  Note that the adversary
-   can't mount this attack on an existing name but only on a name that
-   the adversary can't choose and does not yet exist.
-
-8.4.3.  Possible Hash Value Truncation Method
-
-   The previous sections outlined the low probability and low impact of
-   a second-preimage attack.  When impact and probability are low, while
-   space in a DNS message is costly, truncation is tempting.  Truncation
-   might be considered to allow for shorter ownernames and rdata for
-   hashed labels.  In general, if a cryptographic hash is truncated to n
-   bits, then the expected number of domains required to give a 1 in 2
-   probability of a single collision is approximately 2^(n/2) and the
-   work factor to produce a second preimage is 2^n.
-
-   An extreme hash value truncation would be truncating to the shortest
-   possible unique label value.  This would be unwise, since the work
-   factor to produce second preimages would then approximate the size of
-   the zone (sketch of proof: if the zone has k entries, then the length
-   of the names when truncated down to uniqueness should be proportional
-   to log_2(k).  Since the work factor to produce a second pre-image is
-   2^n for an n-bit hash, then in this case it is 2^(C log_2(k)) (where
-   C is some constant), i.e.  C'k - a work factor of k).
-
-   Though the mentioned truncation can be maximized to a certain
-   extreme, the probability of collision increases exponentially for
-   every truncated bit.  Given the low impact of hash value collisions
-   and limited space in DNS messages, the balance between truncation
-   profit and collision damage may be determined by local policy.  Of
-   course, the size of the corresponding RRSIG RR is not reduced, so
-   truncation is of limited benefit.
-
-   Truncation could be signaled simply by reducing the length of the
-   first label in the ownername.  Note that there would have to be a
-   corresponding reduction in the length of the Next Hashed Ownername
-   field.
-
-8.4.4.  Server Response to a Run-time Collision
-
-   In the astronomically unlikely event that a server is unable to prove
-   nonexistence because the hash of the name that does not exist
-   collides with a name that does exist, the server is obviously broken,
-   and should, therefore, return a response with an RCODE of 2 (server
-   failure).
-
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 17]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-8.4.5.  Parameters that Cover the Zone
-
-   Secondary servers (and perhaps other entities) need to reliably
-   determine which NSEC3 parameters (that is, hash, salt and iterations)
-   are present at every hashed ownername, in order to be able to choose
-   an appropriate set of NSEC3 records for negative responses.  This is
-   indicated by the parameters at the apex: any set of parameters that
-   is used in an NSEC3 record whose original ownername is the apex of
-   the zone MUST be present throughout the zone.
-
-   A method to determine which NSEC3 in a complete chain corresponds to
-   the apex is to look for a NSEC3 RRset which has the SOA bit set in
-   the RDATA bit type maps field.
-
-
-9.  Performance Considerations
-
-   Iterated hashes impose a performance penalty on both authoritative
-   servers and resolvers.  Therefore, the number of iterations should be
-   carefully chosen.  In particular it should be noted that a high value
-   for iterations gives an attacker a very good denial of service
-   attack, since the attacker need not bother to verify the results of
-   their queries, and hence has no performance penalty of his own.
-
-   On the other hand, nameservers with low query rates and limited
-   bandwidth are already subject to a bandwidth based denial of service
-   attack, since responses are typically an order of magnitude larger
-   than queries, and hence these servers may choose a high value of
-   iterations in order to increase the difficulty of offline attempts to
-   enumerate their namespace without significantly increasing their
-   vulnerability to denial of service attacks.
-
-
-10.  IANA Considerations
-
-   IANA needs to allocate a RR type code for NSEC3 from the standard RR
-   type space (type XXX requested).  IANA needs to open a new registry
-   for the NSEC3 Hash Functions.  The range for this registry is 0-127.
-   Defined types are:
-
-      0 is reserved.
-      1 is SHA-1 ([13]).
-      127 is experimental.
-
-
-11.  Security Considerations
-
-   The NSEC3 records are still susceptible to dictionary attacks (i.e.
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 18]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   the attacker retrieves all the NSEC3 records, then calculates the
-   hashes of all likely domain names, comparing against the hashes found
-   in the NSEC3 records, and thus enumerating the zone).  These are
-   substantially more expensive than enumerating the original NSEC
-   records would have been, and in any case, such an attack could also
-   be used directly against the name server itself by performing queries
-   for all likely names, though this would obviously be more detectable.
-   The expense of this off-line attack can be chosen by setting the
-   number of iterations in the NSEC3 RR.
-
-   Domains are also susceptible to a precalculated dictionary attack -
-   that is, a list of hashes for all likely names is computed once, then
-   NSEC3 is scanned periodically and compared against the precomputed
-   hashes.  This attack is prevented by changing the salt on a regular
-   basis.
-
-   Walking the NSEC3 RRs will reveal the total number of records in the
-   zone, and also what types they are.  This could be mitigated by
-   adding dummy entries, but certainly an upper limit can always be
-   found.
-
-   Hash collisions may occur.  If they do, it will be impossible to
-   prove the non-existence of the colliding domain - however, this is
-   fantastically unlikely, and, in any case, DNSSEC already relies on
-   SHA-1 to not collide.
-
-   Responses to queries where QNAME equals an NSEC3 ownername that has
-   no other types may be undetectably changed from a NOERROR/NODATA
-   response to a NAME ERROR response.
-
-   The Opt-In Flag (O) allows for unsigned names, in the form of
-   delegations to unsigned subzones, to exist within an otherwise signed
-   zone.  All unsigned names are, by definition, insecure, and their
-   validity or existence cannot by cryptographically proven.
-
-   In general:
-      Records with unsigned names (whether existing or not) suffer from
-      the same vulnerabilities as records in an unsigned zone.  These
-      vulnerabilities are described in more detail in [16] (note in
-      particular sections 2.3, "Name Games" and 2.6, "Authenticated
-      Denial").
-      Records with signed names have the same security whether or not
-      Opt-In is used.
-
-   Note that with or without Opt-In, an insecure delegation may be
-   undetectably altered by an attacker.  Because of this, the primary
-   difference in security when using Opt-In is the loss of the ability
-   to prove the existence or nonexistence of an insecure delegation
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 19]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   within the span of an Opt-In NSEC3 record.
-
-   In particular, this means that a malicious entity may be able to
-   insert or delete records with unsigned names.  These records are
-   normally NS records, but this also includes signed wildcard
-   expansions (while the wildcard record itself is signed, its expanded
-   name is an unsigned name).
-
-   For example, if a resolver received the following response from the
-   example zone above:
-
-   Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE.  A
-
-           RCODE=NOERROR
-
-           Answer Section:
-
-           Authority Section:
-           DOES-NOT-EXIST.EXAMPLE. NS     NS.FORGED.
-           EXAMPLE.                NSEC   FIRST-SECURE.EXAMPLE. SOA NS \
-                                          RRSIG DNSKEY
-           abcd...                 RRSIG  NSEC3 ...
-
-           Additional Section:
-
-   The resolver would have no choice but to accept that the referral to
-   NS.FORGED. is valid.  If a wildcard existed that would have been
-   expanded to cover "WWW.DOES-NOT-EXIST.EXAMPLE.", an attacker could
-   have undetectably removed it and replaced it with the forged
-   delegation.
-
-   Note that being able to add a delegation is functionally equivalent
-   to being able to add any record type: an attacker merely has to forge
-   a delegation to nameserver under his/her control and place whatever
-   records needed at the subzone apex.
-
-   While in particular cases, this issue may not present a significant
-   security problem, in general it should not be lightly dismissed.
-   Therefore, it is strongly RECOMMENDED that Opt-In be used sparingly.
-   In particular, zone signing tools SHOULD NOT default to using Opt-In,
-   and MAY choose to not support Opt-In at all.
-
-
-12.  References
-
-
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 20]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-12.1.  Normative References
-
-   [1]   Mockapetris, P., "Domain names - concepts and facilities",
-         STD 13, RFC 1034, November 1987.
-
-   [2]   Mockapetris, P., "Domain names - implementation and
-         specification", STD 13, RFC 1035, November 1987.
-
-   [3]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "DNS Security Introduction and Requirements", RFC 4033,
-         March 2005.
-
-   [4]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "Resource Records for the DNS Security Extensions", RFC 4034,
-         March 2005.
-
-   [5]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "Protocol Modifications for the DNS Security Extensions",
-         RFC 4035, March 2005.
-
-   [6]   Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic
-         Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
-         April 1997.
-
-   [7]   Elz, R. and R. Bush, "Clarifications to the DNS Specification",
-         RFC 2181, July 1997.
-
-   [8]   Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
-         RFC 2308, March 1998.
-
-   [9]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
-         Levels", BCP 14, RFC 2119, March 1997.
-
-   [10]  Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
-         RFC 3658, December 2003.
-
-   [11]  Eastlake, D., Brunner-Williams, E., and B. Manning, "Domain
-         Name System (DNS) IANA Considerations", BCP 42, RFC 2929,
-         September 2000.
-
-   [12]  Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
-         Types", RFC 3597, September 2003.
-
-   [13]  Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)",
-         RFC 3174, September 2001.
-
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 21]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-12.2.  Informative References
-
-   [14]  Vixie, P., "Extending DNSSEC-BIS (DNSSEC-TER)",
-         draft-vixie-dnssec-ter-01 (work in progress), June 2004.
-
-   [15]  Josefsson, Ed., S,., "The Base16, Base32, and Base64 Data
-         Encodings.", draft-josefsson-rfc3548bis-00 (work in progress),
-         October 2005.
-
-   [16]  Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
-         System (DNS)", RFC 3833, August 2004.
-
-Editorial Comments
-
-   [Comment.1]  Although, strictly speaking, the names *did* exist.
-
-   [Comment.2]  Note that this method makes it impossible to detect
-                (extremely unlikely) hash collisions.
-
-
-Appendix A.  Example Zone
-
-   This is a zone showing its NSEC3 records.  They can also be used as
-   test vectors for the hash algorithm.
-
-   The data in the example zone is currently broken, as it uses a
-   different base32 alphabet.  This shall be fixed in the next release.
-
-
-   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
-                              1
-                              3600
-                              300
-                              3600000
-                              3600 )
-                  3600 RRSIG  SOA 5 1 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
-                              mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
-                              qYIt90txzE/4+g== )
-                  3600 NS     ns1.example.
-                  3600 NS     ns2.example.
-                  3600 RRSIG  NS 5 1 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l
-                              m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d
-                              1SH5r/wfjuCg+g== )
-                  3600 MX     1 xx.example.
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 22]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-                  3600 RRSIG  MX 5 1 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              L/ZDLMSZJKITmSxmM9Kni37/wKQsdSg6FT0l
-                              NMm14jy2Stp91Pwp1HQ1hAMkGWAqCMEKPMtU
-                              S/o/g5C8VM6ftQ== )
-                  3600 DNSKEY 257 3 5 (
-                              AQOnsGyJvywVjYmiLbh0EwIRuWYcDiB/8blX
-                              cpkoxtpe19Oicv6Zko+8brVsTMeMOpcUeGB1
-                              zsYKWJ7BvR2894hX
-                              ) ; Key ID = 21960
-                  3600 DNSKEY 256 3 5 (
-                              AQO0gEmbZUL6xbD/xQczHbnwYnf+jQjwz/sU
-                              5k44rHTt0Ty+3aOdYoome9TjGMhwkkGby1TL
-                              ExXT48OGGdbfIme5
-                              ) ; Key ID = 62699
-                  3600 RRSIG  DNSKEY 5 1 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              e6EB+K21HbyZzoLUeRDb6+g0+n8XASYe6h+Z
-                              xtnB31sQXZgq8MBHeNFDQW9eZw2hjT9zMClx
-                              mTkunTYzqWJrmQ== )
-                  3600 RRSIG  DNSKEY 5 1 3600 20050712112304 (
-                              20050612112304 21960 example.
-                              SnWLiNWLbOuiKU/F/wVMokvcg6JVzGpQ2VUk
-                              ZbKjB9ON0t3cdc+FZbOCMnEHRJiwgqlnncik
-                              3w7ZY2UWyYIvpw== )
-   5pe7ctl7pfs2cilroy5dcofx4rcnlypd.example. 3600 NSEC3  0 1 1 (
-                              deadbeaf
-                              7nomf47k3vlidh4vxahhpp47l3tgv7a2
-                              NSEC3 RRSIG )
-                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              PTWYq4WZmmtgh9UQif342HWf9DD9RuuM4ii5
-                              Z1oZQgRi5zrsoKHAgl2YXprF2Rfk1TLgsiFQ
-                              sb7KfbaUo/vzAg== )
-   7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 NSEC3  0 1 1 (
-                              deadbeaf
-                              dw4o7j64wnel3j4jh7fb3c5n7w3js2yb
-                              MX NSEC3 RRSIG )
-                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              YTcqole3h8EOsTT3HKnwhR1QS8borR0XtZaA
-                              ZrLsx6n0RDC1AAdZONYOvdqvcal9PmwtWjlo
-                              MEFQmc/gEuxojA== )
-   a.example.     3600 IN NS  ns1.a.example.
-                  3600 IN NS  ns2.a.example.
-                  3600 DS     58470 5 1 3079F1593EBAD6DC121E202A8B
-                              766A6A4837206C )
-                  3600 RRSIG  DS 5 2 3600 20050712112304 (
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 23]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-                              20050612112304 62699 example.
-                              QavhbsSmEvJLSUzGoTpsV3SKXCpaL1UO3Ehn
-                              cB0ObBIlex/Zs9kJyG/9uW1cYYt/1wvgzmX2
-                              0kx7rGKTc3RQDA== )
-   ns1.a.example. 3600 IN A   192.0.2.5
-   ns2.a.example. 3600 IN A   192.0.2.6
-   ai.example.    3600 IN A   192.0.2.9
-                  3600 RRSIG  A 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              plY5M26ED3Owe3YX0pBIhgg44j89NxUaoBrU
-                              6bLRr99HpKfFl1sIy18JiRS7evlxCETZgubq
-                              ZXW5S+1VjMZYzQ== )
-                  3600 HINFO  "KLH-10" "ITS"
-                  3600 RRSIG  HINFO 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              AR0hG/Z/e+vlRhxRQSVIFORzrJTBpdNHhwUk
-                              tiuqg+zGqKK84eIqtrqXelcE2szKnF3YPneg
-                              VGNmbgPnqDVPiA== )
-                  3600 AAAA   2001:db8:0:0:0:0:f00:baa9
-                  3600 RRSIG  AAAA 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              PNF/t7+DeosEjhfuL0kmsNJvn16qhYyLI9FV
-                              ypSCorFx/PKIlEL3syomkYM2zcXVSRwUXMns
-                              l5/UqLCJJ9BDMg== )
-   b.example.     3600 IN NS  ns1.b.example.
-                  3600 IN NS  ns2.b.example.
-   ns1.b.example. 3600 IN A   192.0.2.7
-   ns2.b.example. 3600 IN A   192.0.2.8
-   dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 NSEC3  0 1 1 (
-                              deadbeaf
-                              gmnfcccja7wkax3iv26bs75myptje3qk
-                              MX DNSKEY NS SOA NSEC3 RRSIG )
-                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              VqEbXiZLJVYmo25fmO3IuHkAX155y8NuA50D
-                              C0NmJV/D4R3rLm6tsL6HB3a3f6IBw6kKEa2R
-                              MOiKMSHozVebqw== )
-   gmnfcccja7wkax3iv26bs75myptje3qk.example. 3600 NSEC3  0 1 1 (
-                              deadbeaf
-                              jt4bbfokgbmr57qx4nqucvvn7fmo6ab6
-                              DS NS NSEC3 RRSIG )
-                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              ZqkdmF6eICpHyn1Cj7Yvw+nLcbji46Qpe76/
-                              ZetqdZV7K5sO3ol5dOc0dZyXDqsJp1is5StW
-                              OwQBGbOegrW/Zw== )
-   jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 NSEC3  0 1 1 (
-                              deadbeaf
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 24]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-                              kcll7fqfnisuhfekckeeqnmbbd4maanu
-                              NSEC3 RRSIG )
-                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              FXyCVQUdFF1EW1NcgD2V724/It0rn3lr+30V
-                              IyjmqwOMvQ4G599InTpiH46xhX3U/FmUzHOK
-                              94Zbq3k8lgdpZA== )
-   kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 NSEC3  1 1 1 (
-                              deadbeaf
-                              n42hbhnjj333xdxeybycax5ufvntux5d
-                              MX NSEC3 RRSIG )
-                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              d0g8MTOvVwByOAIwvYV9JrTHwJof1VhnMKuA
-                              IBj6Xaeney86RBZYgg7Qyt9WnQSK3uCEeNpx
-                              TOLtc5jPrkL4zQ== )
-   n42hbhnjj333xdxeybycax5ufvntux5d.example. 3600 NSEC3  0 1 1 (
-                              deadbeaf
-                              nimwfwcnbeoodmsc6npv3vuaagaevxxu
-                              A NSEC3 RRSIG )
-                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              MZGzllh+YFqZbY8SkHxARhXFiMDPS0tvQYyy
-                              91tj+lbl45L/BElD3xxB/LZMO8vQejYtMLHj
-                              xFPFGRIW3wKnrA== )
-   nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 NSEC3  0 1 1 (
-                              deadbeaf
-                              vhgwr2qgykdkf4m6iv6vkagbxozphazr
-                              HINFO A AAAA NSEC3 RRSIG )
-                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              c3zQdK68cYTHTjh1cD6pi0vblXwzyoU/m7Qx
-                              z8kaPYikbJ9vgSl9YegjZukgQSwybHUC0SYG
-                              jL33Wm1p07TBdw== )
-   ns1.example.   3600 A      192.0.2.1
-                  3600 RRSIG  A 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              QLGkaqWXxRuE+MHKkMvVlswg65HcyjvD1fyb
-                              BDZpcfiMHH9w4x1eRqRamtSDTcqLfUrcYkrr
-                              nWWLepz1PjjShQ== )
-   ns2.example.   3600 A      192.0.2.2
-                  3600 RRSIG  A 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              UoIZaC1O6XHRWGHBOl8XFQKPdYTkRCz6SYh3
-                              P2mZ3xfY22fLBCBDrEnOc8pGDGijJaLl26Cz
-                              AkeTJu3J3auUiA== )
-   vhgwr2qgykdkf4m6iv6vkagbxozphazr.example. 3600 NSEC3  0 1 1 (
-                              deadbeaf
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 25]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-                              wbyijvpnyj33pcpi3i44ecnibnaj7eiw
-                              HINFO A AAAA NSEC3 RRSIG )
-                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              leFhoF5FXZAiNOxK4OBOOA0WKdbaD5lLDT/W
-                              kLoyWnQ6WGBwsUOdsEcVmqz+1n7q9bDf8G8M
-                              5SNSHIyfpfsi6A== )
-   *.w.example.   3600 MX     1 ai.example.
-                  3600 RRSIG  MX 5 3 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              sYNUPHn1/gJ87wTHNksGdRm3vfnSFa2BbofF
-                              xGfJLF5A4deRu5f0hvxhAFDCcXfIASj7z0wQ
-                              gQlgxEwhvQDEaQ== )
-   x.w.example.   3600 MX     1 xx.example.
-                  3600 RRSIG  MX 5 3 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              s1XQ/8SlViiEDik9edYs1Ooe3XiXo453Dg7w
-                              lqQoewuDzmtd6RaLNu52W44zTM1EHJES8ujP
-                              U9VazOa1KEIq1w== )
-   x.y.w.example. 3600 MX     1 xx.example.
-                  3600 RRSIG  MX 5 4 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              aKVCGO/Fx9rm04UUsHRTTYaDA8o8dGfyq6t7
-                              uqAcYxU9xiXP+xNtLHBv7er6Q6f2JbOs6SGF
-                              9VrQvJjwbllAfA== )
-   wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 NSEC3  0 1 1 (
-                              deadbeaf
-                              zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui
-                              A NSEC3 RRSIG )
-                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              ledFAaDCqDxapQ1FvBAjjK2DP06iQj8AN6gN
-                              ZycTeSmobKLTpzbgQp8uKYYe/DPHjXYmuEhd
-                              oorBv4xkb0flXw== )
-   xx.example.    3600 A      192.0.2.10
-                  3600 RRSIG  A 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              XSuMVjNxovbZUsnKU6oQDygaK+WB+O5HYQG9
-                              tJgphHIX7TM4uZggfR3pNM+4jeC8nt2OxZZj
-                              cxwCXWj82GVGdw== )
-                  3600 HINFO  "KLH-10" "TOPS-20"
-                  3600 RRSIG  HINFO 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              ghS2DimOqPSacG9j6KMgXSfTMSjLxvoxvx3q
-                              OKzzPst4tEbAmocF2QX8IrSHr67m4ZLmd2Fk
-                              KMf4DgNBDj+dIQ== )
-                  3600 AAAA   2001:db8:0:0:0:0:f00:baaa
-                  3600 RRSIG  AAAA 5 2 3600 20050712112304 (
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 26]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-                              20050612112304 62699 example.
-                              rto7afZkXYB17IfmQCT5QoEMMrlkeOoAGXzo
-                              w8Wmcg86Fc+MQP0hyXFScI1gYNSgSSoDMXIy
-                              rzKKwb8J04/ILw== )
-   zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 NSEC3  0 1 1 (
-                              deadbeaf
-                              5pe7ctl7pfs2cilroy5dcofx4rcnlypd
-                              MX NSEC3 RRSIG )
-                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt
-                              7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny
-                              OcFlrPGPMm48/A== )
-
-
-Appendix B.  Example Responses
-
-   The examples in this section show response messages using the signed
-   zone example in Appendix A.
-
-B.1.  answer
-
-   A successful query to an authoritative server.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 27]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   ;; Header: QR AA DO RCODE=0
-   ;;
-   ;; Question
-   x.w.example.        IN MX
-
-   ;; Answer
-   x.w.example.   3600 IN MX  1 xx.example.
-   x.w.example.   3600 IN RRSIG  MX 5 3 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              s1XQ/8SlViiEDik9edYs1Ooe3XiXo453Dg7w
-                              lqQoewuDzmtd6RaLNu52W44zTM1EHJES8ujP
-                              U9VazOa1KEIq1w== )
-
-   ;; Authority
-   example.       3600 IN NS  ns1.example.
-   example.       3600 IN NS  ns2.example.
-   example.       3600 IN RRSIG  NS 5 1 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l
-                              m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d
-                              1SH5r/wfjuCg+g== )
-
-   ;; Additional
-   xx.example.    3600 IN A   192.0.2.10
-   xx.example.    3600 IN RRSIG  A 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              XSuMVjNxovbZUsnKU6oQDygaK+WB+O5HYQG9
-                              tJgphHIX7TM4uZggfR3pNM+4jeC8nt2OxZZj
-                              cxwCXWj82GVGdw== )
-   xx.example.    3600 IN AAAA   2001:db8::f00:baaa
-   xx.example.    3600 IN RRSIG  AAAA 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              rto7afZkXYB17IfmQCT5QoEMMrlkeOoAGXzo
-                              w8Wmcg86Fc+MQP0hyXFScI1gYNSgSSoDMXIy
-                              rzKKwb8J04/ILw== )
-   ns1.example.   3600 IN A   192.0.2.1
-   ns1.example.   3600 IN RRSIG  A 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              QLGkaqWXxRuE+MHKkMvVlswg65HcyjvD1fyb
-                              BDZpcfiMHH9w4x1eRqRamtSDTcqLfUrcYkrr
-                              nWWLepz1PjjShQ== )
-   ns2.example.   3600 IN A   192.0.2.2
-   ns2.example.   3600 IN RRSIG  A 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              UoIZaC1O6XHRWGHBOl8XFQKPdYTkRCz6SYh3
-                              P2mZ3xfY22fLBCBDrEnOc8pGDGijJaLl26Cz
-                              AkeTJu3J3auUiA== )
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 28]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   The query returned an MX RRset for "x.w.example".  The corresponding
-   RRSIG RR indicates that the MX RRset was signed by an "example"
-   DNSKEY with algorithm 5 and key tag 62699.  The resolver needs the
-   corresponding DNSKEY RR in order to authenticate this answer.  The
-   discussion below describes how a resolver might obtain this DNSKEY
-   RR.
-
-   The RRSIG RR indicates the original TTL of the MX RRset was 3600,
-   and, for the purpose of authentication, the current TTL is replaced
-   by 3600.  The RRSIG RR's labels field value of 3 indicates that the
-   answer was not the result of wildcard expansion.  The "x.w.example"
-   MX RRset is placed in canonical form, and, assuming the current time
-   falls between the signature inception and expiration dates, the
-   signature is authenticated.
-
-B.1.1.  Authenticating the Example DNSKEY RRset
-
-   This example shows the logical authentication process that starts
-   from a configured root DNSKEY RRset (or DS RRset) and moves down the
-   tree to authenticate the desired "example" DNSKEY RRset.  Note that
-   the logical order is presented for clarity.  An implementation may
-   choose to construct the authentication as referrals are received or
-   to construct the authentication chain only after all RRsets have been
-   obtained, or in any other combination it sees fit.  The example here
-   demonstrates only the logical process and does not dictate any
-   implementation rules.
-
-   We assume the resolver starts with a configured DNSKEY RRset for the
-   root zone (or a configured DS RRset for the root zone).  The resolver
-   checks whether this configured DNSKEY RRset is present in the root
-   DNSKEY RRset (or whether a DS RR in the DS RRset matches some DNSKEY
-   RR in the root DNSKEY RRset), whether this DNSKEY RR has signed the
-   root DNSKEY RRset, and whether the signature lifetime is valid.  If
-   all these conditions are met, all keys in the DNSKEY RRset are
-   considered authenticated.  The resolver then uses one (or more) of
-   the root DNSKEY RRs to authenticate the "example" DS RRset.  Note
-   that the resolver may have to query the root zone to obtain the root
-   DNSKEY RRset or "example" DS RRset.
-
-   Once the DS RRset has been authenticated using the root DNSKEY, the
-   resolver checks the "example" DNSKEY RRset for some "example" DNSKEY
-   RR that matches one of the authenticated "example" DS RRs.  If such a
-   matching "example" DNSKEY is found, the resolver checks whether this
-   DNSKEY RR has signed the "example" DNSKEY RRset and the signature
-   lifetime is valid.  If these conditions are met, all keys in the
-   "example" DNSKEY RRset are considered authenticated.
-
-   Finally, the resolver checks that some DNSKEY RR in the "example"
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 29]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   DNSKEY RRset uses algorithm 5 and has a key tag of 62699.  This
-   DNSKEY is used to authenticate the RRSIG included in the response.
-   If multiple "example" DNSKEY RRs match this algorithm and key tag,
-   then each DNSKEY RR is tried, and the answer is authenticated if any
-   of the matching DNSKEY RRs validate the signature as described above.
-
-B.2.  Name Error
-
-   An authoritative name error.  The NSEC3 RRs prove that the name does
-   not exist and that no covering wildcard exists.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 30]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   ;; Header: QR AA DO RCODE=3
-   ;;
-   ;; Question
-   a.c.x.w.example.         IN A
-
-   ;; Answer
-   ;; (empty)
-
-   ;; Authority
-   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
-                              1
-                              3600
-                              300
-                              3600000
-                              3600
-                              )
-   example.       3600 IN RRSIG  SOA 5 1 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
-                              mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
-                              qYIt90txzE/4+g== )
-   7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 IN NSEC3  0 1 1 (
-                              deadbeaf
-                              dw4o7j64wnel3j4jh7fb3c5n7w3js2yb
-                              MX NSEC3 RRSIG )
-   7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 IN RRSIG  NSEC3 (
-                              5 2 3600 20050712112304
-                              20050612112304 62699 example.
-                              YTcqole3h8EOsTT3HKnwhR1QS8borR0XtZaA
-                              ZrLsx6n0RDC1AAdZONYOvdqvcal9PmwtWjlo
-                              MEFQmc/gEuxojA== )
-   nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 IN NSEC3  0 1 1 (
-                              deadbeaf
-                              vhgwr2qgykdkf4m6iv6vkagbxozphazr
-                              HINFO A AAAA NSEC3 RRSIG )
-   nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 IN RRSIG  NSEC3 (
-                              5 2 3600 20050712112304
-                              20050612112304 62699 example.
-                              c3zQdK68cYTHTjh1cD6pi0vblXwzyoU/m7Qx
-                              z8kaPYikbJ9vgSl9YegjZukgQSwybHUC0SYG
-                              jL33Wm1p07TBdw== )
-   ;; Additional
-   ;; (empty)
-
-   The query returned two NSEC3 RRs that prove that the requested data
-   does not exist and no wildcard applies.  The negative reply is
-   authenticated by verifying both NSEC3 RRs.  The NSEC3 RRs are
-   authenticated in a manner identical to that of the MX RRset discussed
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 31]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   above.  At least one of the owner names of the NSEC3 RRs will match
-   the closest encloser.  At least one of the NSEC3 RRs prove that there
-   exists no longer name.  At least one of the NSEC3 RRs prove that
-   there exists no wildcard RRsets that should have been expanded.  The
-   closest encloser can be found by hashing the apex ownername (The SOA
-   RR's ownername, or the ownername of the DNSKEY RRset referred by an
-   RRSIG RR), matching it to the ownername of one of the NSEC3 RRs, and
-   if that fails, continue by adding labels.  In other words, the
-   resolver first hashes example, checks for a matching NSEC3 ownername,
-   then hashes w.example, checks, and finally hashes w.x.example and
-   checks.
-
-   In the above example, the name 'x.w.example' hashes to
-   '7nomf47k3vlidh4vxahhpp47l3tgv7a2'.  This indicates that this might
-   be the closest encloser.  To prove that 'c.x.w.example' and
-   '*.x.w.example' do not exists, these names are hashed to respectively
-   'qsgoxsf2lanysajhtmaylde4tqwnqppl' and
-   'cvljzyf6nsckjowghch4tt3nohocpdka'.  The two NSEC3 records prove that
-   these hashed ownernames do not exists, since the names are within the
-   given intervals.
-
-B.3.  No Data Error
-
-   A "no data" response.  The NSEC3 RR proves that the name exists and
-   that the requested RR type does not.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 32]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   ;; Header: QR AA DO RCODE=0
-   ;;
-   ;; Question
-   ns1.example.        IN MX
-
-   ;; Answer
-   ;; (empty)
-
-   ;; Authority
-   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
-                              1
-                              3600
-                              300
-                              3600000
-                              3600
-                              )
-   example.       3600 IN RRSIG  SOA 5 1 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
-                              mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
-                              qYIt90txzE/4+g== )
-   wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 IN NSEC3  0 1 1 (
-                              deadbeaf
-                              zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui
-                              A NSEC3 RRSIG )
-   wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 IN RRSIG  NSEC3 (
-                              5 2 3600 20050712112304
-                              20050612112304 62699 example.
-                              ledFAaDCqDxapQ1FvBAjjK2DP06iQj8AN6gN
-                              ZycTeSmobKLTpzbgQp8uKYYe/DPHjXYmuEhd
-                              oorBv4xkb0flXw== )
-   ;; Additional
-   ;; (empty)
-
-   The query returned an NSEC3 RR that proves that the requested name
-   exists ("ns1.example." hashes to "wbyijvpnyj33pcpi3i44ecnibnaj7eiw"),
-   but the requested RR type does not exist (type MX is absent in the
-   type code list of the NSEC RR).  The negative reply is authenticated
-   by verifying the NSEC3 RR.  The NSEC3 RR is authenticated in a manner
-   identical to that of the MX RRset discussed above.
-
-B.3.1.  No Data Error, Empty Non-Terminal
-
-   A "no data" response because of an empty non-terminal.  The NSEC3 RR
-   proves that the name exists and that the requested RR type does not.
-
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 33]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   ;; Header: QR AA DO RCODE=0
-   ;;
-   ;; Question
-   y.w.example.        IN A
-
-   ;; Answer
-   ;; (empty)
-
-   ;; Authority
-   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
-                              1
-                              3600
-                              300
-                              3600000
-                              3600
-                              )
-   example.       3600 IN RRSIG  SOA 5 1 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
-                              mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
-                              qYIt90txzE/4+g== )
-   jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 IN NSEC3  0 1 1 (
-                              deadbeaf
-                              kcll7fqfnisuhfekckeeqnmbbd4maanu
-                              NSEC3 RRSIG )
-   jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 IN RRSIG  NSEC3 (
-                              5 2 3600 20050712112304
-                              20050612112304 62699 example.
-                              FXyCVQUdFF1EW1NcgD2V724/It0rn3lr+30V
-                              IyjmqwOMvQ4G599InTpiH46xhX3U/FmUzHOK
-                              94Zbq3k8lgdpZA== )
-
-   The query returned an NSEC3 RR that proves that the requested name
-   exists ("y.w.example." hashes to "jt4bbfokgbmr57qx4nqucvvn7fmo6ab6"),
-   but the requested RR type does not exist (Type A is absent in the
-   type-bit-maps of the NSEC3 RR).  The negative reply is authenticated
-   by verifying the NSEC3 RR.  The NSEC3 RR is authenticated in a manner
-   identical to that of the MX RRset discussed above.  Note that, unlike
-   generic empty non terminal proof using NSECs, this is identical to
-   proving a No Data Error.  This example is solely mentioned to be
-   complete.
-
-B.4.  Referral to Signed Zone
-
-   Referral to a signed zone.  The DS RR contains the data which the
-   resolver will need to validate the corresponding DNSKEY RR in the
-   child zone's apex.
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 34]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   ;; Header: QR DO RCODE=0
-   ;;
-
-   ;; Question
-   mc.a.example.       IN MX
-
-   ;; Answer
-   ;; (empty)
-
-   ;; Authority
-   a.example.     3600 IN NS  ns1.a.example.
-   a.example.     3600 IN NS  ns2.a.example.
-   a.example.     3600 IN DS  58470 5 1 (
-                              3079F1593EBAD6DC121E202A8B766A6A4837
-                              206C )
-   a.example.     3600 IN RRSIG  DS 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              QavhbsSmEvJLSUzGoTpsV3SKXCpaL1UO3Ehn
-                              cB0ObBIlex/Zs9kJyG/9uW1cYYt/1wvgzmX2
-                              0kx7rGKTc3RQDA== )
-
-   ;; Additional
-   ns1.a.example. 3600 IN A   192.0.2.5
-   ns2.a.example. 3600 IN A   192.0.2.6
-
-   The query returned a referral to the signed "a.example." zone.  The
-   DS RR is authenticated in a manner identical to that of the MX RRset
-   discussed above.  This DS RR is used to authenticate the "a.example"
-   DNSKEY RRset.
-
-   Once the "a.example" DS RRset has been authenticated using the
-   "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset
-   for some "a.example" DNSKEY RR that matches the DS RR.  If such a
-   matching "a.example" DNSKEY is found, the resolver checks whether
-   this DNSKEY RR has signed the "a.example" DNSKEY RRset and whether
-   the signature lifetime is valid.  If all these conditions are met,
-   all keys in the "a.example" DNSKEY RRset are considered
-   authenticated.
-
-B.5.  Referral to Unsigned Zone using the Opt-In Flag
-
-   The NSEC3 RR proves that nothing for this delegation was signed in
-   the parent zone.  There is no proof that the delegation exists
-
-
-
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 35]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   ;; Header: QR DO RCODE=0
-   ;;
-   ;; Question
-   mc.b.example.       IN MX
-
-   ;; Answer
-   ;; (empty)
-
-   ;; Authority
-   b.example.     3600 IN NS  ns1.b.example.
-   b.example.     3600 IN NS  ns2.b.example.
-   kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 IN NSEC3  1 1 1 (
-                              deadbeaf
-                              n42hbhnjj333xdxeybycax5ufvntux5d
-                              MX NSEC3 RRSIG )
-   kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 IN RRSIG  NSEC3 (
-                              5 2 3600 20050712112304
-                              20050612112304 62699 example.
-                              d0g8MTOvVwByOAIwvYV9JrTHwJof1VhnMKuA
-                              IBj6Xaeney86RBZYgg7Qyt9WnQSK3uCEeNpx
-                              TOLtc5jPrkL4zQ== )
-
-   ;; Additional
-   ns1.b.example. 3600 IN A   192.0.2.7
-   ns2.b.example. 3600 IN A   192.0.2.8
-
-   The query returned a referral to the unsigned "b.example." zone.  The
-   NSEC3 proves that no authentication leads from "example" to
-   "b.example", since the hash of "b.example"
-   ("ldjpfcucebeks5azmzpty4qlel4cftzo") is within the NSEC3 interval and
-   the NSEC3 opt-in bit is set.  The NSEC3 RR is authenticated in a
-   manner identical to that of the MX RRset discussed above.
-
-B.6.  Wildcard Expansion
-
-   A successful query that was answered via wildcard expansion.  The
-   label count in the answer's RRSIG RR indicates that a wildcard RRset
-   was expanded to produce this response, and the NSEC3 RR proves that
-   no closer match exists in the zone.
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 36]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   ;; Header: QR AA DO RCODE=0
-   ;;
-   ;; Question
-   a.z.w.example.      IN MX
-
-   ;; Answer
-   a.z.w.example. 3600 IN MX  1 ai.example.
-   a.z.w.example. 3600 IN RRSIG  MX 5 3 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              sYNUPHn1/gJ87wTHNksGdRm3vfnSFa2BbofF
-                              xGfJLF5A4deRu5f0hvxhAFDCcXfIASj7z0wQ
-                              gQlgxEwhvQDEaQ== )
-   ;; Authority
-   example.       3600 NS     ns1.example.
-   example.       3600 NS     ns2.example.
-   example.       3600 IN RRSIG  NS 5 1 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l
-                              m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d
-                              1SH5r/wfjuCg+g== )
-   zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN NSEC3  0 1 1 (
-                              deadbeaf
-                              5pe7ctl7pfs2cilroy5dcofx4rcnlypd
-                              MX NSEC3 RRSIG )
-   zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN RRSIG  NSEC3 (
-                              5 2 3600 20050712112304
-                              20050612112304 62699 example.
-                              eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt
-                              7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny
-                              OcFlrPGPMm48/A== )
-   ;; Additional
-   ai.example.    3600 IN A   192.0.2.9
-   ai.example.    3600 IN RRSIG  A 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              plY5M26ED3Owe3YX0pBIhgg44j89NxUaoBrU
-                              6bLRr99HpKfFl1sIy18JiRS7evlxCETZgubq
-                              ZXW5S+1VjMZYzQ== )
-   ai.example.    3600 AAAA   2001:db8::f00:baa9
-   ai.example.    3600 IN RRSIG  AAAA 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              PNF/t7+DeosEjhfuL0kmsNJvn16qhYyLI9FV
-                              ypSCorFx/PKIlEL3syomkYM2zcXVSRwUXMns
-                              l5/UqLCJJ9BDMg== )
-
-   The query returned an answer that was produced as a result of
-   wildcard expansion.  The answer section contains a wildcard RRset
-   expanded as it would be in a traditional DNS response, and the
-   corresponding RRSIG indicates that the expanded wildcard MX RRset was
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 37]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   signed by an "example" DNSKEY with algorithm 5 and key tag 62699.
-   The RRSIG indicates that the original TTL of the MX RRset was 3600,
-   and, for the purpose of authentication, the current TTL is replaced
-   by 3600.  The RRSIG labels field value of 2 indicates that the answer
-   is the result of wildcard expansion, as the "a.z.w.example" name
-   contains 4 labels.  The name "a.z.w.example" is replaced by
-   "*.w.example", the MX RRset is placed in canonical form, and,
-   assuming that the current time falls between the signature inception
-   and expiration dates, the signature is authenticated.
-
-   The NSEC3 proves that no closer match (exact or closer wildcard)
-   could have been used to answer this query, and the NSEC3 RR must also
-   be authenticated before the answer is considered valid.
-
-B.7.  Wildcard No Data Error
-
-   A "no data" response for a name covered by a wildcard.  The NSEC3 RRs
-   prove that the matching wildcard name does not have any RRs of the
-   requested type and that no closer match exists in the zone.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 38]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   ;; Header: QR AA DO RCODE=0
-   ;;
-   ;; Question
-   a.z.w.example.      IN AAAA
-
-   ;; Answer
-   ;; (empty)
-
-   ;; Authority
-   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
-                              1
-                              3600
-                              300
-                              3600000
-                              3600
-                              )
-   example.       3600 IN RRSIG  SOA 5 1 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
-                              mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
-                              qYIt90txzE/4+g== )
-   zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN NSEC3  0 1 1 (
-                              deadbeaf
-                              5pe7ctl7pfs2cilroy5dcofx4rcnlypd
-                              MX NSEC3 RRSIG )
-   zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN RRSIG  NSEC3 (
-                              5 2 3600 20050712112304
-                              20050612112304 62699 example.
-                              eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt
-                              7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny
-                              OcFlrPGPMm48/A== )
-   ;; Additional
-   ;; (empty)
-
-   The query returned NSEC3 RRs that prove that the requested data does
-   not exist and no wildcard applies.  The negative reply is
-   authenticated by verifying both NSEC3 RRs.
-
-B.8.  DS Child Zone No Data Error
-
-   A "no data" response for a QTYPE=DS query that was mistakenly sent to
-   a name server for the child zone.
-
-
-
-
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 39]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   ;; Header: QR AA DO RCODE=0
-   ;;
-   ;; Question
-   example.            IN DS
-
-   ;; Answer
-   ;; (empty)
-
-   ;; Authority
-   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
-                              1
-                              3600
-                              300
-                              3600000
-                              3600
-                              )
-   example.       3600 IN RRSIG  SOA 5 1 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
-                              mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
-                              qYIt90txzE/4+g== )
-   dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 IN NSEC3  0 1 1 (
-                              deadbeaf
-                              gmnfcccja7wkax3iv26bs75myptje3qk
-                              MX DNSKEY NS SOA NSEC3 RRSIG )
-   dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 IN RRSIG  NSEC3 (
-                              5 2 3600 20050712112304
-                              20050612112304 62699 example.
-                              VqEbXiZLJVYmo25fmO3IuHkAX155y8NuA50D
-                              C0NmJV/D4R3rLm6tsL6HB3a3f6IBw6kKEa2R
-                              MOiKMSHozVebqw== )
-
-   ;; Additional
-   ;; (empty)
-
-   The query returned NSEC RRs that shows the requested was answered by
-   a child server ("example" server).  The NSEC RR indicates the
-   presence of an SOA RR, showing that the answer is from the child .
-   Queries for the "example" DS RRset should be sent to the parent
-   servers ("root" servers).
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 40]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-Authors' Addresses
-
-   Ben Laurie
-   Nominet
-   17 Perryn Road
-   London  W3 7LR
-   England
-
-   Phone: +44 (20) 8735 0686
-   Email: ben@algroup.co.uk
-
-
-   Geoffrey Sisson
-   Nominet
-
-
-   Roy Arends
-   Nominet
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 41]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 42]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-nsid-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-nsid-01.txt
deleted file mode 100644
index 90d1a06..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-nsid-01.txt
+++ /dev/null
@@ -1,840 +0,0 @@
-
-
-
-Network Working Group                                         R. Austein
-Internet-Draft                                                       ISC
-Expires: July 15, 2006                                  January 11, 2006
-
-
-                DNS Name Server Identifier Option (NSID)
-                       draft-ietf-dnsext-nsid-01
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on July 15, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   With the increased use of DNS anycast, load balancing, and other
-   mechanisms allowing more than one DNS name server to share a single
-   IP address, it is sometimes difficult to tell which of a pool of name
-   servers has answered a particular query.  While existing ad-hoc
-   mechanism allow an operator to send follow-up queries when it is
-   necessary to debug such a configuration, the only completely reliable
-   way to obtain the identity of the name server which responded is to
-   have the name server include this information in the response itself.
-   This note defines a protocol extension to support this functionality.
-
-
-
-Austein                   Expires July 15, 2006                 [Page 1]
-
-Internet-Draft                  DNS NSID                    January 2006
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-     1.1.  Reserved Words . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
-     2.1.  Resolver Behavior  . . . . . . . . . . . . . . . . . . . .  4
-     2.2.  Name Server Behavior . . . . . . . . . . . . . . . . . . .  4
-     2.3.  The NSID Option  . . . . . . . . . . . . . . . . . . . . .  4
-     2.4.  Presentation Format  . . . . . . . . . . . . . . . . . . .  5
-   3.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . . .  6
-     3.1.  The NSID Payload . . . . . . . . . . . . . . . . . . . . .  6
-     3.2.  NSID Is Not Transitive . . . . . . . . . . . . . . . . . .  8
-     3.3.  User Interface Issues  . . . . . . . . . . . . . . . . . .  8
-     3.4.  Truncation . . . . . . . . . . . . . . . . . . . . . . . .  9
-   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
-   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
-   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
-   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
-     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
-     7.2.  Informative References . . . . . . . . . . . . . . . . . . 13
-   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
-   Intellectual Property and Copyright Statements . . . . . . . . . . 15
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein                   Expires July 15, 2006                 [Page 2]
-
-Internet-Draft                  DNS NSID                    January 2006
-
-
-1.  Introduction
-
-   With the increased use of DNS anycast, load balancing, and other
-   mechanisms allowing more than one DNS name server to share a single
-   IP address, it is sometimes difficult to tell which of a pool of name
-   servers has answered a particular query.
-
-   Existing ad-hoc mechanisms allow an operator to send follow-up
-   queries when it is necessary to debug such a configuration, but there
-   are situations in which this is not a totally satisfactory solution,
-   since anycast routing may have changed, or the server pool in
-   question may be behind some kind of extremely dynamic load balancing
-   hardware.  Thus, while these ad-hoc mechanisms are certainly better
-   than nothing (and have the advantage of already being deployed), a
-   better solution seems desirable.
-
-   Given that a DNS query is an idempotent operation with no retained
-   state, it would appear that the only completely reliable way to
-   obtain the identity of the name server which responded to a
-   particular query is to have that name server include identifying
-   information in the response itself.  This note defines a protocol
-   enhancement to achieve this.
-
-1.1.  Reserved Words
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein                   Expires July 15, 2006                 [Page 3]
-
-Internet-Draft                  DNS NSID                    January 2006
-
-
-2.  Protocol
-
-   This note uses an EDNS [RFC2671] option to signal the resolver's
-   desire for information identifying the name server and to hold the
-   name server's response, if any.
-
-2.1.  Resolver Behavior
-
-   A resolver signals its desire for information identifying a name
-   server by sending an empty NSID option (Section 2.3) in an EDNS OPT
-   pseudo-RR in the query message.
-
-   The resolver MUST NOT include any NSID payload data in the query
-   message.
-
-   The semantics of an NSID request are not transitive.  That is: the
-   presence of an NSID option in a query is a request that the name
-   server which receives the query identify itself.  If the name server
-   side of a recursive name server receives an NSID request, the client
-   is asking the recursive name server to identify itself; if the
-   resolver side of the recursive name server wishes to receive
-   identifying information, it is free to add NSID requests in its own
-   queries, but that is a separate matter.
-
-2.2.  Name Server Behavior
-
-   A name server which understands the NSID option and chooses to honor
-   a particular NSID request responds by including identifying
-   information in a NSID option (Section 2.3) in an EDNS OPT pseudo-RR
-   in the response message.
-
-   The name server MUST ignore any NSID payload data that might be
-   present in the query message.
-
-   The NSID option is not transitive.  A name server MUST NOT send an
-   NSID option back to a resolver which did not request it.  In
-   particular, while a recursive name server may choose to add an NSID
-   option when sending a query, this has no effect on the presence or
-   absence of the NSID option in the recursive name server's response to
-   the original client.
-
-   As stated in Section 2.1, this mechanism is not restricted to
-   authoritative name servers; the semantics are intended to be equally
-   applicable to recursive name servers.
-
-2.3.  The NSID Option
-
-   The OPTION-CODE for the NSID option is [TBD].
-
-
-
-Austein                   Expires July 15, 2006                 [Page 4]
-
-Internet-Draft                  DNS NSID                    January 2006
-
-
-   The OPTION-DATA for the NSID option is an opaque byte string the
-   semantics of which are deliberately left outside the protocol.  See
-   Section 3.1 for discussion.
-
-2.4.  Presentation Format
-
-   User interfaces MUST read and write the content of the NSID option as
-   a sequence of hexadecimal digits, two digits per payload octet.
-
-   The NSID payload is binary data.  Any comparison between NSID
-   payloads MUST be a comparison of the raw binary data.  Copy
-   operations MUST NOT assume that the raw NSID payload is null-
-   terminated.  Any resemblance between raw NSID payload data and any
-   form of text is purely a convenience, and does not change the
-   underlying nature of the payload data.
-
-   See Section 3.3 for discussion.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein                   Expires July 15, 2006                 [Page 5]
-
-Internet-Draft                  DNS NSID                    January 2006
-
-
-3.  Discussion
-
-   This section discusses certain aspects of the protocol and explains
-   considerations that led to the chosen design.
-
-3.1.  The NSID Payload
-
-   The syntax and semantics of the content of the NSID option is
-   deliberately left outside the scope of this specification.  This
-   section describe some of the kinds of data that server administrators
-   might choose to provide as the content of the NSID option, and
-   explains the reasoning behind choosing a simple opaque byte string.
-
-   There are several possibilities for the payload of the NSID option:
-
-   o  It could be the "real" name of the specific name server within the
-      name server pool.
-
-   o  It could be the "real" IP address (IPv4 or IPv6) of the name
-      server within the name server pool.
-
-   o  It could be some sort of pseudo-random number generated in a
-      predictable fashion somehow using the server's IP address or name
-      as a seed value.
-
-   o  It could be some sort of probabilisticly unique identifier
-      initially derived from some sort of random number generator then
-      preserved across reboots of the name server.
-
-   o  It could be some sort of dynamicly generated identifier so that
-      only the name server operator could tell whether or not any two
-      queries had been answered by the same server.
-
-   o  It could be a blob of signed data, with a corresponding key which
-      might (or might not) be available via DNS lookups.
-
-   o  It could be a blob of encrypted data, the key for which could be
-      restricted to parties with a need to know (in the opinion of the
-      server operator).
-
-   o  It could be an arbitrary string of octets chosen at the discretion
-      of the name server operator.
-
-   Each of these options has advantages and disadvantages:
-
-   o  Using the "real" name is simple, but the name server may not have
-      a "real" name.
-
-
-
-
-Austein                   Expires July 15, 2006                 [Page 6]
-
-Internet-Draft                  DNS NSID                    January 2006
-
-
-   o  Using the "real" address is also simple, and the name server
-      almost certainly does have at least one non-anycast IP address for
-      maintenance operations, but the operator of the name server may
-      not be willing to divulge its non-anycast address.
-
-   o  Given that one common reason for using anycast DNS techniques is
-      an attempt to harden a critical name server against denial of
-      service attacks, some name server operators are likely to want an
-      identifier other than the "real" name or "real" address of the
-      name server instance.
-
-   o  Using a hash or pseudo-random number can provide a fixed length
-      value that the resolver can use to tell two name servers apart
-      without necessarily being able to tell where either one of them
-      "really" is, but makes debugging more difficult if one happens to
-      be in a friendly open environment.  Furthermore, hashing might not
-      add much value, since a hash based on an IPv4 address still only
-      involves a 32-bit search space, and DNS names used for servers
-      that operators might have to debug at 4am tend not to be very
-      random.
-
-   o  Probabilisticly unique identifiers have similar properties to
-      hashed identifiers, but (given a sufficiently good random number
-      generator) are immune to the search space issues.  However, the
-      strength of this approach is also its weakness: there is no
-      algorithmic transformation by which even the server operator can
-      associate name server instances with identifiers while debugging,
-      which might be annoying.  This approach also requires the name
-      server instance to preserve the probabilisticly unique identifier
-      across reboots, but this does not appear to be a serious
-      restriction, since authoritative nameservers almost always have
-      some form of nonvolatile storage in any case, and in the rare case
-      of a name server that does not have any way to store such an
-      identifier, nothing terrible will happen if the name server just
-      generates a new identifier every time it reboots.
-
-   o  Using an arbitrary octet string gives name server operators yet
-      another thing to configure, or mis-configure, or forget to
-      configure.  Having all the nodes in an anycast name server
-      constellation identify themselves as "My Name Server" would not be
-      particularly useful.
-
-   Given all of the issues listed above, there does not appear to be a
-   single solution that will meet all needs.  Section 2.3 therefore
-   defines the NSID payload to be an opaque byte string and leaves the
-   choice up to the implementor and name server operator.  The following
-   guidelines may be useful to implementors and server operators:
-
-
-
-
-Austein                   Expires July 15, 2006                 [Page 7]
-
-Internet-Draft                  DNS NSID                    January 2006
-
-
-   o  Operators for whom divulging the unicast address is an issue could
-      use the raw binary representation of a probabilisticly unique
-      random number.  This should probably be the default implementation
-      behavior.
-
-   o  Operators for whom divulging the unicast address is not an issue
-      could just use the raw binary representation of a unicast address
-      for simplicity.  This should only be done via an explicit
-      configuration choice by the operator.
-
-   o  Operators who really need or want the ability to set the NSID
-      payload to an arbitrary value could do so, but this should only be
-      done via an explicit configuration choice by the operator.
-
-   This approach appears to provide enough information for useful
-   debugging without unintentionally leaking the maintenance addresses
-   of anycast name servers to nogoodniks, while also allowing name
-   server operators who do not find such leakage threatening to provide
-   more information at their own discretion.
-
-3.2.  NSID Is Not Transitive
-
-   As specified in Section 2.1 and Section 2.2, the NSID option is not
-   transitive.  This is strictly a hop-by-hop mechanism.
-
-   Most of the discussion of name server identification to date has
-   focused on identifying authoritative name servers, since the best
-   known cases of anycast name servers are a subset of the name servers
-   for the root zone.  However, given that anycast DNS techniques are
-   also applicable to recursive name servers, the mechanism may also be
-   useful with recursive name servers.  The hop-by-hop semantics support
-   this.
-
-   While there might be some utility in having a transitive variant of
-   this mechanism (so that, for example, a stub resolver could ask a
-   recursive server to tell it which authoritative name server provided
-   a particular answer to the recursive name server), the semantics of
-   such a variant would be more complicated, and are left for future
-   work.
-
-3.3.  User Interface Issues
-
-   Given the range of possible payload contents described in
-   Section 3.1, it is not possible to define a single presentation
-   format for the NSID payload that is efficient, convenient,
-   unambiguous, and aesthetically pleasing.  In particular, while it is
-   tempting to use a presentation format that uses some form of textual
-   strings, attempting to support this would significantly complicate
-
-
-
-Austein                   Expires July 15, 2006                 [Page 8]
-
-Internet-Draft                  DNS NSID                    January 2006
-
-
-   what's intended to be a very simple debugging mechanism.
-
-   In some cases the content of the NSID payload may be binary data
-   meaningful only to the name server operator, and may not be
-   meaningful to the user or application, but the user or application
-   must be able to capture the entire content anyway in order for it to
-   be useful.  Thus, the presentation format must support arbitrary
-   binary data.
-
-   In cases where the name server operator derives the NSID payload from
-   textual data, a textual form such as US-ASCII or UTF-8 strings might
-   at first glance seem easier for a user to deal with.  There are,
-   however, a number of complex issues involving internationalized text
-   which, if fully addressed here, would require a set of rules
-   significantly longer than the rest of this specification.  See
-   [RFC2277] for an overview of some of these issues.
-
-   It is much more important for the NSID payload data to be passed
-   unambiguously from server administrator to user and back again than
-   it is for the payload data data to be pretty while in transit.  In
-   particular, it's critical that it be straightforward for a user to
-   cut and paste an exact copy of the NSID payload output by a debugging
-   tool into other formats such as email messages or web forms without
-   distortion.  Hexadecimal strings, while ugly, are also robust.
-
-3.4.  Truncation
-
-   In some cases, adding the NSID option to a response message may
-   trigger message truncation.  This specification does not change the
-   rules for DNS message truncation in any way, but implementors will
-   need to pay attention to this issue.
-
-   Including the NSID option in a response is always optional, so this
-   specification never requires name servers to truncate response
-   messages.
-
-   By definition, a resolver that requests NSID responses also supports
-   EDNS, so a resolver that requests NSID responses can also use the
-   "sender's UDP payload size" field of the OPT pseudo-RR to signal a
-   receive buffer size large enough to make truncation unlikely.
-
-
-
-
-
-
-
-
-
-
-
-Austein                   Expires July 15, 2006                 [Page 9]
-
-Internet-Draft                  DNS NSID                    January 2006
-
-
-4.  IANA Considerations
-
-   This mechanism requires allocation of one ENDS option code for the
-   NSID option (Section 2.3).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein                   Expires July 15, 2006                [Page 10]
-
-Internet-Draft                  DNS NSID                    January 2006
-
-
-5.  Security Considerations
-
-   This document describes a channel signaling mechanism, intended
-   primarily for debugging.  Channel signaling mechanisms are outside
-   the scope of DNSSEC per se.  Applications that require integrity
-   protection for the data being signaled will need to use a channel
-   security mechanism such as TSIG [RFC2845].
-
-   Section 3.1 discusses a number of different kinds of information that
-   a name server operator might choose to provide as the value of the
-   NSID option.  Some of these kinds of information are security
-   sensitive in some environments.  This specification deliberately
-   leaves the syntax and semantics of the NSID option content up to the
-   implementation and the name server operator.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein                   Expires July 15, 2006                [Page 11]
-
-Internet-Draft                  DNS NSID                    January 2006
-
-
-6.  Acknowledgements
-
-   Joe Abley, Harald Alvestrand, Mark Andrews, Roy Arends, Steve
-   Bellovin, Randy Bush, David Conrad, Johan Ihren, Daniel Karrenberg,
-   Peter Koch, Mike Patton, Mike StJohns, Paul Vixie, Sam Weiler, and
-   Suzanne Woolf.  Apologies to anyone inadvertently omitted from the
-   above list.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein                   Expires July 15, 2006                [Page 12]
-
-Internet-Draft                  DNS NSID                    January 2006
-
-
-7.  References
-
-7.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", RFC 2119, BCP 14, March 1997.
-
-   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
-              RFC 2671, August 1999.
-
-   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
-              Wellington, "Secret Key Transaction Authentication for DNS
-              (TSIG)", RFC 2845, May 2000.
-
-7.2.  Informative References
-
-   [RFC2277]  Alvestrand, H., "IETF Policy on Character Sets and
-              Languages", RFC 2277, BCP 18, January 1998.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein                   Expires July 15, 2006                [Page 13]
-
-Internet-Draft                  DNS NSID                    January 2006
-
-
-Author's Address
-
-   Rob Austein
-   ISC
-   950 Charter Street
-   Redwood City, CA  94063
-   USA
-
-   Email: sra@isc.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein                   Expires July 15, 2006                [Page 14]
-
-Internet-Draft                  DNS NSID                    January 2006
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Austein                   Expires July 15, 2006                [Page 15]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-06.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-06.txt
deleted file mode 100644
index 5b6d655..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-06.txt
+++ /dev/null
@@ -1,464 +0,0 @@
-
-INTERNET-DRAFT                                DSA Information in the DNS
-OBSOLETES: RFC 2536                               Donald E. Eastlake 3rd
-                                                   Motorola Laboratories
-Expires: January 2006                                          July 2005
-
-
-            DSA Keying and Signature Information in the DNS
-            --- ------ --- --------- ----------- -- --- ---
-               <draft-ietf-dnsext-rfc2536bis-dsa-06.txt>
-                         Donald E. Eastlake 3rd
-
-
-Status of This Document
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Distribution of this document is unlimited. Comments should be sent
-   to the DNS extensions working group mailing list
-   <namedroppers@ops.ietf.org>.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than a "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/1id-abstracts.html
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-
-Abstract
-
-   The standard method of encoding US Government Digital Signature
-   Algorithm keying and signature information for use in the Domain Name
-   System is specified.
-
-
-Copyright Notice
-
-   Copyright (C) The Internet Society 2005. All Rights Reserved.
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 1]
-
-
-INTERNET-DRAFT                                DSA Information in the DNS
-
-
-Table of Contents
-
-      Status of This Document....................................1
-      Abstract...................................................1
-      Copyright Notice...........................................1
-
-      Table of Contents..........................................2
-
-      1. Introduction............................................3
-      2. DSA Keying Information..................................3
-      3. DSA Signature Information...............................4
-      4. Performance Considerations..............................4
-      5. Security Considerations.................................5
-      6. IANA Considerations.....................................5
-      Copyright and Disclaimer...................................5
-
-      Normative References.......................................7
-      Informative References.....................................7
-
-      Authors Address............................................8
-      Expiration and File Name...................................8
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 2]
-
-
-INTERNET-DRAFT                                DSA Information in the DNS
-
-
-1. Introduction
-
-   The Domain Name System (DNS) is the global hierarchical replicated
-   distributed database system for Internet addressing, mail proxy, and
-   other information [RFC 1034, 1035]. The DNS has been extended to
-   include digital signatures and cryptographic keys as described in
-   [RFC 4033, 4034, 4035] and additional work is underway which would
-   require the storage of keying and signature information in the DNS.
-
-   This document describes how to encode US Government Digital Signature
-   Algorithm (DSA) keys and signatures in the DNS.  Familiarity with the
-   US Digital Signature Algorithm is assumed [FIPS 186-2, Schneier].
-
-
-
-2. DSA Keying Information
-
-   When DSA public keys are stored in the DNS, the structure of the
-   relevant part of the RDATA part of the RR being used is the fields
-   listed below in the order given.
-
-   The period of key validity is not included in this data but is
-   indicated separately, for example by an RR such as RRSIG which signs
-   and authenticates the RR containing the keying information.
-
-        Field     Size
-        -----     ----
-         T         1  octet
-         Q        20  octets
-         P        64 + T*8  octets
-         G        64 + T*8  octets
-         Y        64 + T*8  octets
-
-   As described in [FIPS 186-2] and [Schneier], T is a key size
-   parameter chosen such that 0 <= T <= 8.  (The meaning if the T octet
-   is greater than 8 is reserved and the remainder of the data may have
-   a different format in that case.)  Q is a prime number selected at
-   key generation time such that 2**159 < Q < 2**160. Thus Q is always
-   20 octets long and, as with all other fields, is stored in "big-
-   endian" network order.  P, G, and Y are calculated as directed by the
-   [FIPS 186-2] key generation algorithm [Schneier].  P is in the range
-   2**(511+64T) < P < 2**(512+64T) and thus is 64 + 8*T octets long.  G
-   and Y are quantities modulo P and so can be up to the same length as
-   P and are allocated fixed size fields with the same number of octets
-   as P.
-
-   During the key generation process, a random number X must be
-   generated such that 1 <= X <= Q-1.  X is the private key and is used
-   in the final step of public key generation where Y is computed as
-
-
-
-D. Eastlake 3rd                                                 [Page 3]
-
-
-INTERNET-DRAFT                                DSA Information in the DNS
-
-
-        Y = G**X mod P
-
-
-
-3. DSA Signature Information
-
-   The portion of the RDATA area used for US Digital Signature Algorithm
-   signature information is shown below with fields in the order they
-   are listed and the contents of each multi-octet field in "big-endian"
-   network order.
-
-        Field     Size
-        -----     ----
-         T         1 octet
-         R        20 octets
-         S        20 octets
-
-   First, the data signed must be determined.  Then the following steps
-   are taken, as specified in [FIPS 186-2], where Q, P, G, and Y are as
-   specified in the public key [Schneier]:
-
-        hash = SHA-1 ( data )
-
-        Generate a random K such that 0 < K < Q.
-
-        R = ( G**K mod P ) mod Q
-
-        S = ( K**(-1) * (hash + X*R) ) mod Q
-
-   For information on the SHA-1 hash function see [FIPS 180-2] and [RFC
-   3174].
-
-   Since Q is 160 bits long, R and S can not be larger than 20 octets,
-   which is the space allocated.
-
-   T is copied from the public key.  It is not logically necessary in
-   the SIG but is present so that values of T > 8 can more conveniently
-   be used as an escape for extended versions of DSA or other algorithms
-   as later standardized.
-
-
-
-4. Performance Considerations
-
-   General signature generation speeds are roughly the same for RSA [RFC
-   3110] and DSA.  With sufficient pre-computation, signature generation
-   with DSA is faster than RSA.  Key generation is also faster for DSA.
-   However, signature verification is an order of magnitude slower than
-   RSA when the RSA public exponent is chosen to be small, as is
-   recommended for some applications.
-
-
-D. Eastlake 3rd                                                 [Page 4]
-
-
-INTERNET-DRAFT                                DSA Information in the DNS
-
-
-   Current DNS implementations are optimized for small transfers,
-   typically less than 512 bytes including DNS overhead.  Larger
-   transfers will perform correctly and extensions have been
-   standardized [RFC 2671] to make larger transfers more efficient, it
-   is still advisable at this time to make reasonable efforts to
-   minimize the size of RR sets containing keying and/or signature
-   inforamtion consistent with adequate security.
-
-
-
-5. Security Considerations
-
-   Keys retrieved from the DNS should not be trusted unless (1) they
-   have been securely obtained from a secure resolver or independently
-   verified by the user and (2) this secure resolver and secure
-   obtainment or independent verification conform to security policies
-   acceptable to the user.  As with all cryptographic algorithms,
-   evaluating the necessary strength of the key is essential and
-   dependent on local policy.
-
-   The key size limitation of a maximum of 1024 bits ( T = 8 ) in the
-   current DSA standard may limit the security of DSA.  For particular
-   applications, implementors are encouraged to consider the range of
-   available algorithms and key sizes.
-
-   DSA assumes the ability to frequently generate high quality random
-   numbers.  See [random] for guidance.  DSA is designed so that if
-   biased rather than random numbers are used, high bandwidth covert
-   channels are possible.  See [Schneier] and more recent research.  The
-   leakage of an entire DSA private key in only two DSA signatures has
-   been demonstrated.  DSA provides security only if trusted
-   implementations, including trusted random number generation, are
-   used.
-
-
-
-6. IANA Considerations
-
-   Allocation of meaning to values of the T parameter that are not
-   defined herein (i.e., > 8 ) requires an IETF standards actions.  It
-   is intended that values unallocated herein be used to cover future
-   extensions of the DSS standard.
-
-
-
-Copyright and Disclaimer
-
-   Copyright (C) The Internet Society (2005).  This document is subject to
-   the rights, licenses and restrictions contained in BCP 78, and except
-   as set forth therein, the authors retain all their rights.
-
-
-D. Eastlake 3rd                                                 [Page 5]
-
-
-INTERNET-DRAFT                                DSA Information in the DNS
-
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 6]
-
-
-INTERNET-DRAFT                                DSA Information in the DNS
-
-
-Normative References
-
-   [FIPS 186-2] - U.S. Federal Information Processing Standard: Digital
-   Signature Standard, 27 January 2000.
-
-   [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
-   Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
-   March 2005.
-
-
-
-Informative References
-
-   [RFC 1034] - "Domain names - concepts and facilities", P.
-   Mockapetris, 11/01/1987.
-
-   [RFC 1035] - "Domain names - implementation and specification", P.
-   Mockapetris, 11/01/1987.
-
-   [RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August
-   1999.
-
-   [RFC 3110] - "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System
-   (DNS)", D.  Eastlake 3rd. May 2001.
-
-   [RFC 3174] - "US Secure Hash Algorithm 1 (SHA1)", D. Eastlake, P.
-   Jones, September 2001.
-
-   [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
-   Rose, "DNS Security Introduction and Requirements", RFC 4033, March
-   2005.
-
-   [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
-   Rose, "Protocol Modifications for the DNS Security Extensions", RFC
-   4035, March 2005.
-
-   [RFC 4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker,
-   "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
-
-   [Schneier] - "Applied Cryptography Second Edition: protocols,
-   algorithms, and source code in C" (second edition), Bruce Schneier,
-   1996, John Wiley and Sons, ISBN 0-471-11709-9.
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 7]
-
-
-INTERNET-DRAFT                                DSA Information in the DNS
-
-
-Authors Address
-
-   Donald E. Eastlake 3rd
-   Motorola Labortories
-   155 Beaver Street
-   Milford, MA 01757 USA
-
-   Telephone:   +1-508-786-7554(w)
-   EMail:       Donald.Eastlake@motorola.com
-
-
-
-Expiration and File Name
-
-   This draft expires in January 2006.
-
-   Its file name is draft-ietf-dnsext-rfc2536bis-dsa-06.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 8]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt
deleted file mode 100644
index 2ec9dbe..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt
+++ /dev/null
@@ -1,840 +0,0 @@
-
-
-
-Network Working Group                                       S. Josefsson
-Internet-Draft                                           August 30, 2005
-Expires: March 3, 2006
-
-
-          Storing Certificates in the Domain Name System (DNS)
-                    draft-ietf-dnsext-rfc2538bis-04
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on March 3, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   Cryptographic public keys are frequently published and their
-   authenticity demonstrated by certificates.  A CERT resource record
-   (RR) is defined so that such certificates and related certificate
-   revocation lists can be stored in the Domain Name System (DNS).
-
-   This document obsoletes RFC 2538.
-
-
-
-
-
-
-Josefsson                 Expires March 3, 2006                 [Page 1]
-
-Internet-Draft       Storing Certificates in the DNS         August 2005
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  The CERT Resource Record . . . . . . . . . . . . . . . . . . .  3
-     2.1.  Certificate Type Values  . . . . . . . . . . . . . . . . .  4
-     2.2.  Text Representation of CERT RRs  . . . . . . . . . . . . .  5
-     2.3.  X.509 OIDs . . . . . . . . . . . . . . . . . . . . . . . .  6
-   3.  Appropriate Owner Names for CERT RRs . . . . . . . . . . . . .  6
-     3.1.  Content-based X.509 CERT RR Names  . . . . . . . . . . . .  7
-     3.2.  Purpose-based X.509 CERT RR Names  . . . . . . . . . . . .  8
-     3.3.  Content-based OpenPGP CERT RR Names  . . . . . . . . . . .  9
-     3.4.  Purpose-based OpenPGP CERT RR Names  . . . . . . . . . . .  9
-     3.5.  Owner names for IPKIX, ISPKI, and IPGP . . . . . . . . . .  9
-   4.  Performance Considerations . . . . . . . . . . . . . . . . . . 10
-   5.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10
-   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
-   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
-   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
-   9.  Changes since RFC 2538 . . . . . . . . . . . . . . . . . . . . 11
-   Appendix A.  Copying conditions  . . . . . . . . . . . . . . . . . 12
-   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
-     10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
-     10.2. Informative References . . . . . . . . . . . . . . . . . . 13
-   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
-   Intellectual Property and Copyright Statements . . . . . . . . . . 15
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                 Expires March 3, 2006                 [Page 2]
-
-Internet-Draft       Storing Certificates in the DNS         August 2005
-
-
-1.  Introduction
-
-   Public keys are frequently published in the form of a certificate and
-   their authenticity is commonly demonstrated by certificates and
-   related certificate revocation lists (CRLs).  A certificate is a
-   binding, through a cryptographic digital signature, of a public key,
-   a validity interval and/or conditions, and identity, authorization,
-   or other information.  A certificate revocation list is a list of
-   certificates that are revoked, and incidental information, all signed
-   by the signer (issuer) of the revoked certificates.  Examples are
-   X.509 certificates/CRLs in the X.500 directory system or OpenPGP
-   certificates/revocations used by OpenPGP software.
-
-   Section 2 below specifies a CERT resource record (RR) for the storage
-   of certificates in the Domain Name System [1] [2].
-
-   Section 3 discusses appropriate owner names for CERT RRs.
-
-   Sections 4, 5, and 6 below cover performance, IANA, and security
-   considerations, respectively.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [3].
-
-
-2.  The CERT Resource Record
-
-   The CERT resource record (RR) has the structure given below.  Its RR
-   type code is 37.
-
-                       1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |             type              |             key tag           |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |   algorithm   |                                               /
-   +---------------+            certificate or CRL                 /
-   /                                                               /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
-
-   The type field is the certificate type as defined in section 2.1
-   below.
-
-   The key tag field is the 16 bit value computed for the key embedded
-   in the certificate, using the RRSIG Key Tag algorithm described in
-   Appendix B of [10].  This field is used as an efficiency measure to
-   pick which CERT RRs may be applicable to a particular key.  The key
-
-
-
-Josefsson                 Expires March 3, 2006                 [Page 3]
-
-Internet-Draft       Storing Certificates in the DNS         August 2005
-
-
-   tag can be calculated for the key in question and then only CERT RRs
-   with the same key tag need be examined.  However, the key must always
-   be transformed to the format it would have as the public key portion
-   of a DNSKEY RR before the key tag is computed.  This is only possible
-   if the key is applicable to an algorithm (and limits such as key size
-   limits) defined for DNS security.  If it is not, the algorithm field
-   MUST BE zero and the tag field is meaningless and SHOULD BE zero.
-
-   The algorithm field has the same meaning as the algorithm field in
-   DNSKEY and RRSIG RRs [10], except that a zero algorithm field
-   indicates the algorithm is unknown to a secure DNS, which may simply
-   be the result of the algorithm not having been standardized for
-   DNSSEC.
-
-2.1.  Certificate Type Values
-
-   The following values are defined or reserved:
-
-       Value  Mnemonic  Certificate Type
-       -----  --------  ----------------
-           0            reserved
-           1  PKIX      X.509 as per PKIX
-           2  SPKI      SPKI certificate
-           3  PGP       OpenPGP packet
-           4  IPKIX     The URL of an X.509 data object
-           5  ISPKI     The URL of an SPKI certificate
-           6  IPGP      The URL of an OpenPGP packet
-       7-252            available for IANA assignment
-         253  URI       URI private
-         254  OID       OID private
-   255-65534            available for IANA assignment
-       65535            reserved
-
-   The PKIX type is reserved to indicate an X.509 certificate conforming
-   to the profile being defined by the IETF PKIX working group.  The
-   certificate section will start with a one-byte unsigned OID length
-   and then an X.500 OID indicating the nature of the remainder of the
-   certificate section (see 2.3 below).  (NOTE: X.509 certificates do
-   not include their X.500 directory type designating OID as a prefix.)
-
-   The SPKI type is reserved to indicate the SPKI certificate format
-   [13], for use when the SPKI documents are moved from experimental
-   status.
-
-   The PGP type indicates an OpenPGP packet as described in [6] and its
-   extensions and successors.  Two uses are to transfer public key
-   material and revocation signatures.  The data is binary, and MUST NOT
-   be encoded into an ASCII armor.  An implementation SHOULD process
-
-
-
-Josefsson                 Expires March 3, 2006                 [Page 4]
-
-Internet-Draft       Storing Certificates in the DNS         August 2005
-
-
-   transferable public keys as described in section 10.1 of [6], but it
-   MAY handle additional OpenPGP packets.
-
-   The IPKIX, ISPKI and IPGP types indicate a URL which will serve the
-   content that would have been in the "certificate, CRL or URL" field
-   of the corresponding (PKIX, SPKI or PGP) packet types.  These types
-   are known as "indirect".  These packet types MUST be used when the
-   content is too large to fit in the CERT RR, and MAY be used at the
-   implementer's discretion.  They SHOULD NOT be used where the entire
-   UDP packet would have fit in 512 bytes.
-
-   The URI private type indicates a certificate format defined by an
-   absolute URI.  The certificate portion of the CERT RR MUST begin with
-   a null terminated URI [5] and the data after the null is the private
-   format certificate itself.  The URI SHOULD be such that a retrieval
-   from it will lead to documentation on the format of the certificate.
-   Recognition of private certificate types need not be based on URI
-   equality but can use various forms of pattern matching so that, for
-   example, subtype or version information can also be encoded into the
-   URI.
-
-   The OID private type indicates a private format certificate specified
-   by an ISO OID prefix.  The certificate section will start with a one-
-   byte unsigned OID length and then a BER encoded OID indicating the
-   nature of the remainder of the certificate section.  This can be an
-   X.509 certificate format or some other format.  X.509 certificates
-   that conform to the IETF PKIX profile SHOULD be indicated by the PKIX
-   type, not the OID private type.  Recognition of private certificate
-   types need not be based on OID equality but can use various forms of
-   pattern matching such as OID prefix.
-
-2.2.  Text Representation of CERT RRs
-
-   The RDATA portion of a CERT RR has the type field as an unsigned
-   decimal integer or as a mnemonic symbol as listed in section 2.1
-   above.
-
-   The key tag field is represented as an unsigned decimal integer.
-
-   The algorithm field is represented as an unsigned decimal integer or
-   a mnemonic symbol as listed in [10].
-
-   The certificate / CRL portion is represented in base 64 [14] and may
-   be divided up into any number of white space separated substrings,
-   down to single base 64 digits, which are concatenated to obtain the
-   full signature.  These substrings can span lines using the standard
-   parenthesis.
-
-
-
-
-Josefsson                 Expires March 3, 2006                 [Page 5]
-
-Internet-Draft       Storing Certificates in the DNS         August 2005
-
-
-   Note that the certificate / CRL portion may have internal sub-fields,
-   but these do not appear in the master file representation.  For
-   example, with type 254, there will be an OID size, an OID, and then
-   the certificate / CRL proper.  But only a single logical base 64
-   string will appear in the text representation.
-
-2.3.  X.509 OIDs
-
-   OIDs have been defined in connection with the X.500 directory for
-   user certificates, certification authority certificates, revocations
-   of certification authority, and revocations of user certificates.
-   The following table lists the OIDs, their BER encoding, and their
-   length-prefixed hex format for use in CERT RRs:
-
-       id-at-userCertificate
-           = { joint-iso-ccitt(2) ds(5) at(4) 36 }
-              == 0x 03 55 04 24
-       id-at-cACertificate
-           = { joint-iso-ccitt(2) ds(5) at(4) 37 }
-              == 0x 03 55 04 25
-       id-at-authorityRevocationList
-           = { joint-iso-ccitt(2) ds(5) at(4) 38 }
-              == 0x 03 55 04 26
-       id-at-certificateRevocationList
-           = { joint-iso-ccitt(2) ds(5) at(4) 39 }
-              == 0x 03 55 04 27
-
-
-3.  Appropriate Owner Names for CERT RRs
-
-   It is recommended that certificate CERT RRs be stored under a domain
-   name related to their subject, i.e., the name of the entity intended
-   to control the private key corresponding to the public key being
-   certified.  It is recommended that certificate revocation list CERT
-   RRs be stored under a domain name related to their issuer.
-
-   Following some of the guidelines below may result in the use in DNS
-   names of characters that require DNS quoting which is to use a
-   backslash followed by the octal representation of the ASCII code for
-   the character (e.g., \000 for NULL).
-
-   The choice of name under which CERT RRs are stored is important to
-   clients that perform CERT queries.  In some situations, the clients
-   may not know all information about the CERT RR object it wishes to
-   retrieve.  For example, a client may not know the subject name of an
-   X.509 certificate, or the e-mail address of the owner of an OpenPGP
-   key.  Further, the client might only know the hostname of a service
-   that uses X.509 certificates or the Key ID of an OpenPGP key.
-
-
-
-Josefsson                 Expires March 3, 2006                 [Page 6]
-
-Internet-Draft       Storing Certificates in the DNS         August 2005
-
-
-   Therefore, two owner name guidelines are defined: content-based owner
-   names and purpose-based owner names.  A content-based owner name is
-   derived from the content of the CERT RR data; for example, the
-   Subject field in an X.509 certificate or the User ID field in OpenPGP
-   keys.  A purpose-based owner name is a name that a client retrieving
-   CERT RRs MUST already know; for example, the host name of an X.509
-   protected service or the Key ID of an OpenPGP key.  The content-based
-   and purpose-based owner name MAY be the same; for example, when a
-   client looks up a key based on the From: address of an incoming
-   e-mail.
-
-   Implementations SHOULD use the purpose-based owner name guidelines
-   described in this document, and MAY use CNAMEs of content-based owner
-   names (or other names), pointing to the purpose-based owner name.
-
-3.1.  Content-based X.509 CERT RR Names
-
-   Some X.509 versions permit multiple names to be associated with
-   subjects and issuers under "Subject Alternate Name" and "Issuer
-   Alternate Name".  For example, X.509v3 has such Alternate Names with
-   an ASN.1 specification as follows:
-
-        GeneralName ::= CHOICE {
-           otherName                  [0] INSTANCE OF OTHER-NAME,
-           rfc822Name                 [1] IA5String,
-           dNSName                    [2] IA5String,
-           x400Address                [3] EXPLICIT OR-ADDRESS.&Type,
-           directoryName              [4] EXPLICIT Name,
-           ediPartyName               [5] EDIPartyName,
-           uniformResourceIdentifier  [6] IA5String,
-           iPAddress                  [7] OCTET STRING,
-           registeredID               [8] OBJECT IDENTIFIER
-        }
-
-   The recommended locations of CERT storage are as follows, in priority
-   order:
-   1.  If a domain name is included in the identification in the
-       certificate or CRL, that should be used.
-   2.  If a domain name is not included but an IP address is included,
-       then the translation of that IP address into the appropriate
-       inverse domain name should be used.
-   3.  If neither of the above is used, but a URI containing a domain
-       name is present, that domain name should be used.
-   4.  If none of the above is included but a character string name is
-       included, then it should be treated as described for OpenPGP
-       names below.
-
-
-
-
-
-Josefsson                 Expires March 3, 2006                 [Page 7]
-
-Internet-Draft       Storing Certificates in the DNS         August 2005
-
-
-   5.  If none of the above apply, then the distinguished name (DN)
-       should be mapped into a domain name as specified in [4].
-
-   Example 1: An X.509v3 certificate is issued to /CN=John Doe /DC=Doe/
-   DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative Names of (a)
-   string "John (the Man) Doe", (b) domain name john-doe.com, and (c)
-   uri <https://www.secure.john-doe.com:8080/>.  The storage locations
-   recommended, in priority order, would be
-   1.  john-doe.com,
-   2.  www.secure.john-doe.com, and
-   3.  Doe.com.xy.
-
-   Example 2: An X.509v3 certificate is issued to /CN=James Hacker/
-   L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names of (a)
-   domain name widget.foo.example, (b) IPv4 address 10.251.13.201, and
-   (c) string "James Hacker <hacker@mail.widget.foo.example>".  The
-   storage locations recommended, in priority order, would be
-   1.  widget.foo.example,
-   2.  201.13.251.10.in-addr.arpa, and
-   3.  hacker.mail.widget.foo.example.
-
-3.2.  Purpose-based X.509 CERT RR Names
-
-   Due to the difficulty for clients that do not already possess a
-   certificate to reconstruct the content-based owner name, purpose-
-   based owner names are recommended in this section.  Recommendations
-   for purpose-based owner names vary per scenario.  The following table
-   summarizes the purpose-based X.509 CERT RR owner name guidelines for
-   use with S/MIME [16], SSL/TLS [11], and IPSEC [12]:
-
-    Scenario             Owner name
-    ------------------   ----------------------------------------------
-    S/MIME Certificate   Standard translation of an RFC 2822 email
-                         address.  Example: An S/MIME certificate for
-                         "postmaster@example.org" will use a standard
-                         hostname translation of the owner name,
-                         "postmaster.example.org".
-
-    TLS Certificate      Hostname of the TLS server.
-
-    IPSEC Certificate    Hostname of the IPSEC machine and/or, for IPv4
-                         or IPv6 addresses, the fully qualified domain
-                         name in the appropriate reverse domain.
-
-   An alternate approach for IPSEC is to store raw public keys [15].
-
-
-
-
-
-
-Josefsson                 Expires March 3, 2006                 [Page 8]
-
-Internet-Draft       Storing Certificates in the DNS         August 2005
-
-
-3.3.  Content-based OpenPGP CERT RR Names
-
-   OpenPGP signed keys (certificates) use a general character string
-   User ID [6].  However, it is recommended by OpenPGP that such names
-   include the RFC 2822 [8] email address of the party, as in "Leslie
-   Example <Leslie@host.example>".  If such a format is used, the CERT
-   should be under the standard translation of the email address into a
-   domain name, which would be leslie.host.example in this case.  If no
-   RFC 2822 name can be extracted from the string name, no specific
-   domain name is recommended.
-
-   If a user has more than one email address, the CNAME type can be used
-   to reduce the amount of data stored in the DNS.  Example:
-
-      $ORIGIN example.org.
-      smith        IN CERT PGP 0 0 <OpenPGP binary>
-      john.smith   IN CNAME smith
-      js           IN CNAME smith
-
-3.4.  Purpose-based OpenPGP CERT RR Names
-
-   Applications that receive an OpenPGP packet containing encrypted or
-   signed data but do not know the email address of the sender will have
-   difficulties constructing the correct owner name and cannot use the
-   content-based owner name guidelines.  However, these clients commonly
-   know the key fingerprint or the Key ID.  The key ID is found in
-   OpenPGP packets, and the key fingerprint is commonly found in
-   auxilliary data that may be available.  In this case, use of an owner
-   name identical to the key fingerprint and the key ID expressed in
-   hexadecimal [14] is recommended.  Example:
-
-      $ORIGIN example.org.
-      0424D4EE81A0E3D119C6F835EDA21E94B565716F IN CERT PGP ...
-      F835EDA21E94B565716F                     IN CERT PGP ...
-      B565716F                                 IN CERT PGP ...
-
-   If the same key material is stored for several owner names, the use
-   of CNAME may be used to avoid data duplication.  Note that CNAME is
-   not always applicable, because it maps one owner name to the other
-   for all purposes, which may be sub-optimal when two keys with the
-   same Key ID are stored.
-
-3.5.  Owner names for IPKIX, ISPKI, and IPGP
-
-   These types are stored under the same owner names, both purpose- and
-   content-based, as the PKIX, SPKI and PGP types.
-
-
-
-
-
-Josefsson                 Expires March 3, 2006                 [Page 9]
-
-Internet-Draft       Storing Certificates in the DNS         August 2005
-
-
-4.  Performance Considerations
-
-   Current Domain Name System (DNS) implementations are optimized for
-   small transfers, typically not more than 512 bytes including
-   overhead.  While larger transfers will perform correctly and work is
-   underway to make larger transfers more efficient, it is still
-   advisable at this time to make every reasonable effort to minimize
-   the size of certificates stored within the DNS.  Steps that can be
-   taken may include using the fewest possible optional or extension
-   fields and using short field values for necessary variable length
-   fields.
-
-   The RDATA field in the DNS protocol may only hold data of size 65535
-   octets (64kb) or less.  This means that each CERT RR MUST NOT contain
-   more than 64kb of payload, even if the corresponding certificate or
-   certificate revocation list is larger.  This document addresses this
-   by defining "indirect" data types for each normal type.
-
-
-5.  Contributors
-
-   The majority of this document is copied verbatim from RFC 2538, by
-   Donald Eastlake 3rd and Olafur Gudmundsson.
-
-
-6.  Acknowledgements
-
-   Thanks to David Shaw and Michael Graff for their contributions to
-   earlier works that motivated, and served as inspiration for, this
-   document.
-
-   This document was improved by suggestions and comments from Olivier
-   Dubuisson, Olaf M. Kolkman, Ben Laurie, Edward Lewis, Jason
-   Sloderbeck, Samuel Weiler, and Florian Weimer.  No doubt the list is
-   incomplete.  We apologize to anyone we left out.
-
-
-7.  Security Considerations
-
-   By definition, certificates contain their own authenticating
-   signature.  Thus, it is reasonable to store certificates in non-
-   secure DNS zones or to retrieve certificates from DNS with DNS
-   security checking not implemented or deferred for efficiency.  The
-   results MAY be trusted if the certificate chain is verified back to a
-   known trusted key and this conforms with the user's security policy.
-
-   Alternatively, if certificates are retrieved from a secure DNS zone
-   with DNS security checking enabled and are verified by DNS security,
-
-
-
-Josefsson                 Expires March 3, 2006                [Page 10]
-
-Internet-Draft       Storing Certificates in the DNS         August 2005
-
-
-   the key within the retrieved certificate MAY be trusted without
-   verifying the certificate chain if this conforms with the user's
-   security policy.
-
-   If an organization chooses to issue certificates for it's employees,
-   placing CERT RR's in the DNS by owner name, and if DNSSEC (with NSEC)
-   is in use, it is possible for someone to enumerate all employees of
-   the organization.  This is usually not considered desirable, for the
-   same reason enterprise phone listings are not often publicly
-   published and are even mark confidential.
-
-   When the URI type is used, it should be understood that it introduces
-   an additional indirection that may allow for a new attack vector.
-   One method to secure that indirection is to include a hash of the
-   certificate in the URI itself.
-
-   CERT RRs are not used by DNSSEC [9], so there are no security
-   considerations related to CERT RRs and securing the DNS itself.
-
-   If DNSSEC is used, then the non-existence of a CERT RR and,
-   consequently, certificates or revocation lists can be securely
-   asserted.  Without DNSSEC, this is not possible.
-
-
-8.  IANA Considerations
-
-   Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can
-   only be assigned by an IETF standards action [7].  This document
-   assigns 0x0001 through 0x0006 and 0x00FD and 0x00FE.  Certificate
-   types 0x0100 through 0xFEFF are assigned through IETF Consensus [7]
-   based on RFC documentation of the certificate type.  The availability
-   of private types under 0x00FD and 0x00FE should satisfy most
-   requirements for proprietary or private types.
-
-   The CERT RR reuses the DNS Security Algorithm Numbers registry.  In
-   particular, the CERT RR requires that algorithm number 0 remain
-   reserved, as described in Section 2.  The IANA is directed to
-   reference the CERT RR as a user of this registry and value 0, in
-   particular.
-
-
-9.  Changes since RFC 2538
-
-   1.   Editorial changes to conform with new document requirements,
-        including splitting reference section into two parts and
-        updating the references to point at latest versions, and to add
-        some additional references.
-
-
-
-
-Josefsson                 Expires March 3, 2006                [Page 11]
-
-Internet-Draft       Storing Certificates in the DNS         August 2005
-
-
-   2.   Improve terminology.  For example replace "PGP" with "OpenPGP",
-        to align with RFC 2440.
-   3.   In section 2.1, clarify that OpenPGP public key data are binary,
-        not the ASCII armored format, and reference 10.1 in RFC 2440 on
-        how to deal with OpenPGP keys, and acknowledge that
-        implementations may handle additional packet types.
-   4.   Clarify that integers in the representation format are decimal.
-   5.   Replace KEY/SIG with DNSKEY/RRSIG etc, to align with DNSSECbis
-        terminology.  Improve reference for Key Tag Algorithm
-        calculations.
-   6.   Add examples that suggest use of CNAME to reduce bandwidth.
-   7.   In section 3, appended the last paragraphs that discuss
-        "content-based" vs "purpose-based" owner names.  Add section 3.2
-        for purpose-based X.509 CERT owner names, and section 3.4 for
-        purpose-based OpenPGP CERT owner names.
-   8.   Added size considerations.
-   9.   The SPKI types has been reserved, until RFC 2692/2693 is moved
-        from the experimental status.
-   10.  Added indirect types IPKIX, ISPKI, and IPGP.
-
-
-Appendix A.  Copying conditions
-
-   Regarding the portion of this document that was written by Simon
-   Josefsson ("the author", for the remainder of this section), the
-   author makes no guarantees and is not responsible for any damage
-   resulting from its use.  The author grants irrevocable permission to
-   anyone to use, modify, and distribute it in any way that does not
-   diminish the rights of anyone else to use, modify, and distribute it,
-   provided that redistributed derivative works do not contain
-   misleading author or version information.  Derivative works need not
-   be licensed under similar terms.
-
-
-10.  References
-
-10.1.  Normative References
-
-   [1]   Mockapetris, P., "Domain names - concepts and facilities",
-         STD 13, RFC 1034, November 1987.
-
-   [2]   Mockapetris, P., "Domain names - implementation and
-         specification", STD 13, RFC 1035, November 1987.
-
-   [3]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
-         Levels", BCP 14, RFC 2119, March 1997.
-
-   [4]   Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. Sataluri,
-
-
-
-Josefsson                 Expires March 3, 2006                [Page 12]
-
-Internet-Draft       Storing Certificates in the DNS         August 2005
-
-
-         "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247,
-         January 1998.
-
-   [5]   Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
-         Resource Identifiers (URI): Generic Syntax", RFC 2396,
-         August 1998.
-
-   [6]   Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
-         "OpenPGP Message Format", RFC 2440, November 1998.
-
-   [7]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
-         Considerations Section in RFCs", BCP 26, RFC 2434,
-         October 1998.
-
-   [8]   Resnick, P., "Internet Message Format", RFC 2822, April 2001.
-
-   [9]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "DNS Security Introduction and Requirements", RFC 4033,
-         March 2005.
-
-   [10]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "Resource Records for the DNS Security Extensions", RFC 4034,
-         March 2005.
-
-10.2.  Informative References
-
-   [11]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
-         RFC 2246, January 1999.
-
-   [12]  Kent, S. and R. Atkinson, "Security Architecture for the
-         Internet Protocol", RFC 2401, November 1998.
-
-   [13]  Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B.,
-         and T. Ylonen, "SPKI Certificate Theory", RFC 2693,
-         September 1999.
-
-   [14]  Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
-         RFC 3548, July 2003.
-
-   [15]  Richardson, M., "A Method for Storing IPsec Keying Material in
-         DNS", RFC 4025, March 2005.
-
-   [16]  Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
-         (S/MIME) Version 3.1 Message Specification", RFC 3851,
-         July 2004.
-
-
-
-
-
-
-Josefsson                 Expires March 3, 2006                [Page 13]
-
-Internet-Draft       Storing Certificates in the DNS         August 2005
-
-
-Author's Address
-
-   Simon Josefsson
-
-   Email: simon@josefsson.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                 Expires March 3, 2006                [Page 14]
-
-Internet-Draft       Storing Certificates in the DNS         August 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Josefsson                 Expires March 3, 2006                [Page 15]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-06.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-06.txt
deleted file mode 100644
index 5e6cb1d..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-06.txt
+++ /dev/null
@@ -1,580 +0,0 @@
-
-INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
-OBSOLETES: RFC 2539                               Donald E. Eastlake 3rd
-                                                   Motorola Laboratories
-Expires: January 2006                                          July 2005
-
-
-
-
-        Storage of Diffie-Hellman Keying Information in the DNS
-        ------- -- -------------- ------ ----------- -- --- ---
-               <draft-ietf-dnsext-rfc2539bis-dhk-06.txt>
-
-
-
-Status of This Document
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Distribution of this document is unlimited. Comments should be sent
-   to the DNS extensions working group mailing list
-   <namedroppers@ops.ietf.org>.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than a "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/1id-abstracts.html
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-
-Abstract
-
-   The standard method for encoding Diffie-Hellman keys in the Domain
-   Name System is specified.
-
-
-
-Copyright
-
-   Copyright (C) The Internet Society 2005.
-
-
-
-D. Eastlake 3rd                                                 [Page 1]
-
-
-INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
-
-
-Acknowledgements
-
-   Part of the format for Diffie-Hellman keys and the description
-   thereof was taken from a work in progress by Ashar Aziz, Tom Markson,
-   and Hemma Prafullchandra.  In addition, the following persons
-   provided useful comments that were incorporated into the predecessor
-   of this document: Ran Atkinson, Thomas Narten.
-
-
-
-Table of Contents
-
-      Status of This Document....................................1
-      Abstract...................................................1
-      Copyright..................................................1
-
-      Acknowledgements...........................................2
-      Table of Contents..........................................2
-
-      1. Introduction............................................3
-      1.1 About This Document....................................3
-      1.2 About Diffie-Hellman...................................3
-      2. Encoding Diffie-Hellman Keying Information..............4
-      3. Performance Considerations..............................5
-      4. IANA Considerations.....................................5
-      5. Security Considerations.................................5
-      Copyright and Disclaimer...................................5
-
-      Normative References.......................................7
-      Informative Refences.......................................7
-
-      Author Address.............................................8
-      Expiration and File Name...................................8
-
-      Appendix A: Well known prime/generator pairs...............9
-      A.1. Well-Known Group 1:  A 768 bit prime..................9
-      A.2. Well-Known Group 2:  A 1024 bit prime.................9
-      A.3. Well-Known Group 3:  A 1536 bit prime................10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 2]
-
-
-INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
-
-
-1. Introduction
-
-   The Domain Name System (DNS) is the global hierarchical replicated
-   distributed database system for Internet addressing, mail proxy, and
-   similar information [RFC 1034, 1035]. The DNS has been extended to
-   include digital signatures and cryptographic keys as described in
-   [RFC 4033, 4034, 4035] and additonal work is underway which would use
-   the storage of keying information in the DNS.
-
-
-
-1.1 About This Document
-
-   This document describes how to store Diffie-Hellman keys in the DNS.
-   Familiarity with the Diffie-Hellman key exchange algorithm is assumed
-   [Schneier, RFC 2631].
-
-
-
-1.2 About Diffie-Hellman
-
-   Diffie-Hellman requires two parties to interact to derive keying
-   information which can then be used for authentication.  Thus Diffie-
-   Hellman is inherently a key agreement algorithm. As a result, no
-   format is defined for Diffie-Hellman "signature information".  For
-   example, assume that two parties have local secrets "i" and "j".
-   Assume they each respectively calculate X and Y as follows:
-
-        X = g**i ( mod p )
-
-        Y = g**j ( mod p )
-
-   They exchange these quantities and then each calculates a Z as
-   follows:
-
-        Zi = Y**i ( mod p )
-
-        Zj = X**j ( mod p )
-
-   Zi and Zj will both be equal to g**(i*j)(mod p) and will be a shared
-   secret between the two parties that an adversary who does not know i
-   or j will not be able to learn from the exchanged messages (unless
-   the adversary can derive i or j by performing a discrete logarithm
-   mod p which is hard for strong p and g).
-
-   The private key for each party is their secret i (or j).  The public
-   key is the pair p and g, which must be the same for the parties, and
-   their individual X (or Y).
-
-   For further information about Diffie-Hellman and precautions to take
-
-
-D. Eastlake 3rd                                                 [Page 3]
-
-
-INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
-
-
-   in deciding on a p and g, see [RFC 2631].
-
-
-
-2. Encoding Diffie-Hellman Keying Information
-
-   When Diffie-Hellman keys appear within the RDATA portion of a RR,
-   they are encoded as shown below.
-
-   The period of key validity is not included in this data but is
-   indicated separately, for example by an RR such as RRSIG which signs
-   and authenticates the RR containing the keying information.
-
-                            1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |           KEY flags           |    protocol   |  algorithm=2  |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |     prime length (or flag)    |  prime (p) (or special)       /
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       /  prime (p)  (variable length) |       generator length        |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       | generator (g) (variable length)                               |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |     public value length       | public value (variable length)/
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       /  public value (g^i mod p)    (variable length)                |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   Prime length is the length of the Diffie-Hellman prime (p) in bytes
-   if it is 16 or greater.  Prime contains the binary representation of
-   the Diffie-Hellman prime with most significant byte first (i.e., in
-   network order). If "prime length" field is 1 or 2, then the "prime"
-   field is actually an unsigned index into a table of 65,536
-   prime/generator pairs and the generator length SHOULD be zero.  See
-   Appedix A for defined table entries and Section 4 for information on
-   allocating additional table entries.  The meaning of a zero or 3
-   through 15 value for "prime length" is reserved.
-
-   Generator length is the length of the generator (g) in bytes.
-   Generator is the binary representation of generator with most
-   significant byte first.  PublicValueLen is the Length of the Public
-   Value (g**i (mod p)) in bytes.  PublicValue is the binary
-   representation of the DH public value with most significant byte
-   first.
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 4]
-
-
-INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
-
-
-3. Performance Considerations
-
-   Current DNS implementations are optimized for small transfers,
-   typically less than 512 bytes including DNS overhead.  Larger
-   transfers will perform correctly and extensions have been
-   standardized [RFC 2671] to make larger transfers more efficient. But
-   it is still advisable at this time to make reasonable efforts to
-   minimize the size of RR sets containing keying information consistent
-   with adequate security.
-
-
-
-4. IANA Considerations
-
-   Assignment of meaning to Prime Lengths of 0 and 3 through 15 requires
-   an IETF consensus as defined in [RFC 2434].
-
-   Well known prime/generator pairs number 0x0000 through 0x07FF can
-   only be assigned by an IETF standards action. [RFC 2539], the
-   Proposed Standard predecessor of this document, assigned 0x0001
-   through 0x0002. This document additionally assigns 0x0003.  Pairs
-   number 0s0800 through 0xBFFF can be assigned based on RFC
-   documentation. Pairs number 0xC000 through 0xFFFF are available for
-   private use and are not centrally coordinated. Use of such private
-   pairs outside of a closed environment may result in conflicts and/or
-   security failures.
-
-
-
-5. Security Considerations
-
-   Keying information retrieved from the DNS should not be trusted
-   unless (1) it has been securely obtained from a secure resolver or
-   independently verified by the user and (2) this secure resolver and
-   secure obtainment or independent verification conform to security
-   policies acceptable to the user.  As with all cryptographic
-   algorithms, evaluating the necessary strength of the key is important
-   and dependent on security policy.
-
-   In addition, the usual Diffie-Hellman key strength considerations
-   apply. (p-1)/2 should also be prime, g should be primitive mod p, p
-   should be "large", etc. See [RFC 2631, Schneier].
-
-
-
-Copyright and Disclaimer
-
-   Copyright (C) The Internet Society (2005).  This document is subject to
-   the rights, licenses and restrictions contained in BCP 78, and except
-   as set forth therein, the authors retain all their rights.
-
-
-D. Eastlake 3rd                                                 [Page 5]
-
-
-INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
-
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 6]
-
-
-INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
-
-
-Normative References
-
-   [RFC 2631] - "Diffie-Hellman Key Agreement Method", E. Rescorla, June
-   1999.
-
-   [RFC 2434] - "Guidelines for Writing an IANA Considerations Section
-   in RFCs", T.  Narten, H. Alvestrand, October 1998.
-
-   [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
-   Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
-   March 2005.
-
-
-
-Informative Refences
-
-   [RFC 1034] - "Domain names - concepts and facilities", P.
-   Mockapetris, November 1987.
-
-   [RFC 1035] - "Domain names - implementation and specification", P.
-   Mockapetris, November 1987.
-
-   [RFC 2539] - "Storage of Diffie-Hellman Keys in the Domain Name
-   System (DNS)", D. Eastlake, March 1999, obsoleted by this RFC.
-
-   [RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August
-   1999.
-
-   [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
-   Rose, "DNS Security Introduction and Requirements", RFC 4033, March
-   2005.
-
-   [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
-   Rose, "Protocol Modifications for the DNS Security Extensions", RFC
-   4035, March 2005.
-
-   [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
-   Algorithms, and Source Code in C" (Second Edition), 1996, John Wiley
-   and Sons.
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 7]
-
-
-INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
-
-
-Author Address
-
-   Donald E. Eastlake 3rd
-   Motorola Laboratories
-   155 Beaver Street
-   Milford, MA 01757 USA
-
-   Telephone:   +1-508-786-7554
-   EMail:       Donald.Eastlake@motorola.com
-
-
-
-Expiration and File Name
-
-   This draft expires in January 2006.
-
-   Its file name is draft-ietf-dnsext-rfc2539bis-dhk-06.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 8]
-
-
-INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
-
-
-Appendix A: Well known prime/generator pairs
-
-   These numbers are copied from the IPSEC effort where the derivation of
-   these values is more fully explained and additional information is
-   available.
-   Richard Schroeppel performed all the mathematical and computational
-   work for this appendix.
-
-
-
-A.1. Well-Known Group 1:  A 768 bit prime
-
-   The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }.  Its
-   decimal value is
-          155251809230070893513091813125848175563133404943451431320235
-          119490296623994910210725866945387659164244291000768028886422
-          915080371891804634263272761303128298374438082089019628850917
-          0691316593175367469551763119843371637221007210577919
-
-   Prime modulus: Length (32 bit words): 24, Data (hex):
-            FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
-            29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
-            EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
-            E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF
-
-   Generator: Length (32 bit words): 1, Data (hex): 2
-
-
-
-A.2. Well-Known Group 2:  A 1024 bit prime
-
-   The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
-   Its decimal value is
-         179769313486231590770839156793787453197860296048756011706444
-         423684197180216158519368947833795864925541502180565485980503
-         646440548199239100050792877003355816639229553136239076508735
-         759914822574862575007425302077447712589550957937778424442426
-         617334727629299387668709205606050270810842907692932019128194
-         467627007
-
-   Prime modulus:  Length (32 bit words): 32, Data (hex):
-            FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
-            29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
-            EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
-            E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
-            EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
-            FFFFFFFF FFFFFFFF
-
-   Generator: Length (32 bit words): 1, Data (hex): 2
-
-
-
-D. Eastlake 3rd                                                 [Page 9]
-
-
-INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
-
-
-A.3. Well-Known Group 3:  A 1536 bit prime
-
-   The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] +  741804 }.
-   Its decimal value is
-            241031242692103258855207602219756607485695054850245994265411
-            694195810883168261222889009385826134161467322714147790401219
-            650364895705058263194273070680500922306273474534107340669624
-            601458936165977404102716924945320037872943417032584377865919
-            814376319377685986952408894019557734611984354530154704374720
-            774996976375008430892633929555996888245787241299381012913029
-            459299994792636526405928464720973038494721168143446471443848
-            8520940127459844288859336526896320919633919
-
-   Prime modulus Length (32 bit words): 48, Data (hex):
-              FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
-              29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
-              EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
-              E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
-              EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
-              C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
-              83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-              670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF
-
-   Generator: Length (32 bit words):  1, Data (hex): 2
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                [Page 10]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt
deleted file mode 100644
index 0af13c6..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt
+++ /dev/null
@@ -1,755 +0,0 @@
-
-
-Network Working Group                                          B. Laurie
-Internet-Draft                                                   Nominet
-Expires: March 2, 2005                                         R. Loomis
-                                                                    SAIC
-                                                          September 2004
-
-
-
-      Requirements related to DNSSEC Signed Proof of Non-Existence
-         draft-ietf-dnsext-signed-nonexistence-requirements-01
-
-
-Status of this Memo
-
-
-   This document is an Internet-Draft and is subject to all provisions
-   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
-   author represents that any applicable patent or other IPR claims of
-   which he or she is aware have been or will be disclosed, and any of
-   which he or she become aware will be disclosed, in accordance with
-   RFC 3668.
-
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as
-   Internet-Drafts.
-
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-
-   This Internet-Draft will expire on March 2, 2005.
-
-
-Copyright Notice
-
-
-   Copyright (C) The Internet Society (2004).
-
-
-Abstract
-
-
-   DNSSEC-bis uses the NSEC record to provide authenticated denial of
-   existence of RRsets.  NSEC also has the side-effect of permitting
-   zone enumeration, even if zone transfers have been forbidden.
-   Because some see this as a problem, this document has been assembled
-   to detail the possible requirements for denial of existence A/K/A
-   signed proof of non-existence.
-
-
-
-
-Laurie & Loomis          Expires March 2, 2005                  [Page 1]
-Internet-Draft      signed-nonexistence-requirements      September 2004
-
-
-
-Table of Contents
-
-
-   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
-   2.   Non-purposes . . . . . . . . . . . . . . . . . . . . . . . .   3
-   3.   Zone Enumeration . . . . . . . . . . . . . . . . . . . . . .   3
-   4.   Zone Enumeration II  . . . . . . . . . . . . . . . . . . . .   4
-   5.   Zone Enumeration III . . . . . . . . . . . . . . . . . . . .   4
-   6.   Exposure of Contents . . . . . . . . . . . . . . . . . . . .   4
-   7.   Zone Size  . . . . . . . . . . . . . . . . . . . . . . . . .   4
-   8.   Single Method  . . . . . . . . . . . . . . . . . . . . . . .   5
-   9.   Empty Non-terminals  . . . . . . . . . . . . . . . . . . . .   5
-   10.  Prevention of Precomputed Dictionary Attacks . . . . . . . .   6
-   11.  DNSSEC-Adoption and Zone-Growth Relationship . . . . . . . .   6
-   12.  Non-overlap of denial records with possible zone records . .   7
-   13.  Exposure of Private Keys . . . . . . . . . . . . . . . . . .   7
-   14.  Minimisation of Zone Signing Cost  . . . . . . . . . . . . .   8
-   15.  Minimisation of Asymmetry  . . . . . . . . . . . . . . . . .   8
-   16.  Minimisation of Client Complexity  . . . . . . . . . . . . .   8
-   17.  Completeness . . . . . . . . . . . . . . . . . . . . . . . .   8
-   18.  Purity of Namespace  . . . . . . . . . . . . . . . . . . . .   8
-   19.  Replay Attacks . . . . . . . . . . . . . . . . . . . . . . .   8
-   20.  Compatibility with NSEC  . . . . . . . . . . . . . . . . . .   8
-   21.  Compatibility with NSEC II . . . . . . . . . . . . . . . . .   9
-   22.  Compatibility with NSEC III  . . . . . . . . . . . . . . . .   9
-   23.  Coexistence with NSEC  . . . . . . . . . . . . . . . . . . .   9
-   24.  Coexistence with NSEC II . . . . . . . . . . . . . . . . . .   9
-   25.  Protocol Design  . . . . . . . . . . . . . . . . . . . . . .   9
-   26.  Process  . . . . . . . . . . . . . . . . . . . . . . . . . .   9
-   27.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . .   9
-   28.  Requirements notation  . . . . . . . . . . . . . . . . . . .   9
-   29.  Security Considerations  . . . . . . . . . . . . . . . . . .  10
-   30.  References . . . . . . . . . . . . . . . . . . . . . . . . .  10
-   30.1   Normative References . . . . . . . . . . . . . . . . . . .  10
-   30.2   Informative References . . . . . . . . . . . . . . . . . .  10
-        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  10
-        Intellectual Property and Copyright Statements . . . . . . .  11
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie & Loomis          Expires March 2, 2005                  [Page 2]
-Internet-Draft      signed-nonexistence-requirements      September 2004
-
-
-
-1.  Introduction
-
-
-   NSEC records allow trivial enumeration of zones - a situation that
-   has existed for several years but which has recently been raised as a
-   significant concern for DNSSECbis deployment in several zones.
-   Alternate proposals have been made that make zone enumeration more
-   difficult, and some previous proposals to modify DNSSEC had related
-   requirements/desirements that are relevant to the discussion.  In
-   addition the original designs for NSEC/NXT records were based on
-   working group discussions and the choices made were not always
-   documented with context and requirements-- so some of those choices
-   may need to be restated as requirements.  Overall, the working group
-   needs to better understand the requirements for denial of existence
-   (and certain other requirements related to DNSSECbis deployment) in
-   order to evaluate the proposals that may replace NSEC.
-
-
-   In the remainder of this document, "NSEC++" is used as shorthand for
-   "a denial of existence proof that will replace NSEC".  "NSECbis" has
-   also been used as shorthand for this, but we avoid that usage since
-   NSECbis will not be part of DNSSECbis and therefore there might be
-   some confusion.
-
-
-2.  Non-purposes
-
-
-   This document does not currently document the reasons why zone
-   enumeration might be "bad" from a privacy, security, business, or
-   other perspective--except insofar as those reasons result in
-   requirements.  Once the list of requirements is complete and vaguely
-   coherent, the trade-offs (reducing zone enumeration will have X cost,
-   while providing Y benefit) may be revisited.  The editors of this
-   compendium received inputs on the potential reasons why zone
-   enumeration is bad (and there was significant discussion on the
-   DNSEXT WG mailing list) but that information fell outside the scope
-   of this document.
-
-
-   Note also that this document does not assume that NSEC *must* be
-   replaced with NSEC++, if the requirements can be met through other
-   methods (e.g., "white lies" with the current NSEC).  As is stated
-   above, this document is focused on requirements collection and
-   (ideally) prioritization rather than on the actual implementation.
-
-
-3.  Zone Enumeration
-
-
-   Authenticated denial should not permit trivial zone enumeration.
-
-
-   Additional discussion:  NSEC (and NXT before it) provide a linked
-   list that could be "walked" to trivially enumerate all the signed
-   records in a zone.  This requirement is primarily (though not
-
-
-
-
-Laurie & Loomis          Expires March 2, 2005                  [Page 3]
-Internet-Draft      signed-nonexistence-requirements      September 2004
-
-
-
-   exclusively) important for zones that either are delegation-only/
-   -mostly or do not have reverse lookup (PTR) records configured, since
-   enterprises that have PTR records for all A records have already
-   provided a similar capability to enumerate the contents of DNS zones.
-
-
-   Contributor: various
-
-
-4.  Zone Enumeration II
-
-
-   Zone enumeration should be at least as difficult as it would be to
-   effect a dictionary attack using simple DNS queries to do the same in
-   an unsecured zone.
-
-
-   (Editor comment: it is not clear how to measure difficulty in this
-   case.  Some examples could be monetary cost, bandwidth, processing
-   power or some combination of these.  It has also been suggested that
-   the requirement is that the graph of difficulty of enumeration vs.
-   the fraction of the zone enumerated should be approximately the same
-   shape in the two cases)
-
-
-   Contributor: Nominet
-
-
-5.  Zone Enumeration III
-
-
-   Enumeration of a zone with random contents should computationally
-   infeasible.
-
-
-   Editor comment: this is proposed as a way of evaluating the
-   effectiveness of a proposal rather than as a requirement anyone would
-   actually have in practice.
-
-
-   Contributor: Alex Bligh
-
-
-6.  Exposure of Contents
-
-
-   NSEC++ should not expose any of the contents of the zone (apart from
-   the NSEC++ records themselves, of course).
-
-
-   Editor comment: this is a weaker requirement than prevention of
-   enumeration, but certainly any zone that satisfied this requirement
-   would also satisfy the trivial prevention of enumeration requirement.
-
-
-   Contributor: Ed Lewis
-
-
-7.  Zone Size
-
-
-   Requirement:  NSEC++ should make it possible to take precautions
-   against trivial zone size estimates.  Since not all zone owners care
-
-
-
-
-Laurie & Loomis          Expires March 2, 2005                  [Page 4]
-Internet-Draft      signed-nonexistence-requirements      September 2004
-
-
-
-   about others estimation of the size of a zone, it is not always
-   necessary to prohibit trivial estimation of the size of the zone but
-   NSEC++ should allow such measures.
-
-
-   Additional Discussion: Even with proposals based on obfuscating names
-   with hashes it is trivial to give very good estimates of the number
-   of domains in a certain zone.  Just send 10 random queries and look
-   at the range between the two hash values returned in each NSEC++.  As
-   hash output can be assumed to follow a rectangular random
-   distribution, using the mean difference between the two values, you
-   can estimate the total number of records.  It is probably sufficient
-   to look at even one NSEC++, since the two hash values should follow a
-   (I believe) Poisson distribution.
-
-
-   The concern is motivated by some wording remembered from NSEC, which
-   stated that NSEC MUST only be present for existing owner names in the
-   zone, and MUST NOT be present for non-existing owner names.  If
-   similar wording were carried over to NSEC++, introducing bogus owner
-   names in the hash chain (an otherwise simple solution to guard
-   against trivial estimates of zone size) wouldn't be allowed.
-
-
-   One simple attempt at solving this is to describe in the
-   specifications how zone signer tools can add a number of random
-   "junk" records.
-
-
-   Editor's comment: it is interesting that obfuscating names might
-   actually make it easier to estimate zone size.
-
-
-   Contributor: Simon Josefsson.
-
-
-8.  Single Method
-
-
-   Requirement:  A single NSEC++ method must be able to carry both
-   old-style denial (i.e.  plain labels) and whatever the new style
-   looks like.  Having two separate denial methods could result in
-   cornercases where one method can deny the other and vice versa.
-
-
-   Additional discussion:  This requirement can help -bis folks to a
-   smooth upgrade to -ter.  First they'd change the method while the
-   content is the same, then they can change content of the method.
-
-
-   Contributor: Roy Arends.
-
-
-9.  Empty Non-terminals
-
-
-   Requirement:  Empty-non-terminals (ENT) should remain empty.  In
-   other words, adding NSEC++ records to an existing DNS structure
-   should not cause the creation of NSEC++ records (or related records)
-
-
-
-
-Laurie & Loomis          Expires March 2, 2005                  [Page 5]
-Internet-Draft      signed-nonexistence-requirements      September 2004
-
-
-
-   at points that are otherwise ENT.
-
-
-   Additional discussion:  Currently NSEC complies with ENT requirement:
-   b.example.com NSEC a.c.example.com implies the existence of an ENT
-   with ownername c.example.com.  NSEC2 breaks that requirement, since
-   the ownername is entirely hashed causing the structure to disappear.
-   This is why EXIST was introduced.  But EXIST causes ENT to be
-   non-empty-terminals.  Next to the dissappearance of ENT, it causes
-   (some) overhead since an EXIST record needs a SIG, NSEC2 and
-   SIG(NSEC2).  DNSNR honours this requirement by hashing individual
-   labels instead of ownernames.  However this causes very long labels.
-   Truncation is a measure against very long ownernames, but that is
-   controversial.  There is a fair discussion of the validity of
-   truncation in the DNSNR draft, but that hasn't got proper review yet.
-
-
-   Contributor: Roy Arends.
-
-
-   (Editor comment: it is not clear to us that an EXIST record needs an
-   NSEC2 record, since it is a special purpose record only used for
-   denial of existence)
-
-
-10.  Prevention of Precomputed Dictionary Attacks
-
-
-   Requirement:  NSEC++ needs to provide a method to reduce the
-   effectiveness of precomputed dictionary attacks.
-
-
-   Additional Discussion:  Salt is a measure against dictionary attacks.
-   There are other possible measures (such as iterating hashes in
-   NSEC2).  The salt needs to be communicated in every response, since
-   it is needed in every verification.  Some have suggested to move the
-   salt to a special record instead of the denial record.  I think this
-   is not wise.  Response size has more priority over zone size.  An
-   extra record causes a larger response than a larger existing record.
-
-
-   Contributor: Roy Arends.
-
-
-   (Editor comment: the current version of NSEC2 also has the salt in
-   every NSEC2 record)
-
-
-11.  DNSSEC-Adoption and Zone-Growth Relationship
-
-
-   Background:  Currently with NSEC, when a delegation centric zone
-   deploys DNSSEC, the zone-size multiplies by a non-trivial factor even
-   when the DNSSEC-adoption rate of the subzones remains low--because
-   each delegation point creates at least one NSEC record and
-   corresponding signature in the parent even if the child is not
-   signed.
-
-
-
-
-
-Laurie & Loomis          Expires March 2, 2005                  [Page 6]
-Internet-Draft      signed-nonexistence-requirements      September 2004
-
-
-
-   Requirements:  A delegation-only (or delegation-mostly) zone that is
-   signed but which has no signed child zones should initially need only
-   to add SIG(SOA), DNSKEY, and SIG(DNSKEY) at the apex, along with some
-   minimal set of NSEC++ records to cover zone contents.  Further,
-   during the transition of a delegation-only zone from 0% signed
-   children to 100% signed children, the growth in the delegation-only
-   zone should be roughly proportional to the percentage of signed child
-   zones.
-
-
-   Additional Discussion: This is why DNSNR has the Authoritative Only
-   bit.  This is similar to opt-in for delegations only.  This (bit) is
-   currently the only method to help delegation-centric zone cope with
-   zone-growth due to DNSSEC adoption.  As an example, A delegation only
-   zone which deploys DNSSEC with the help of this bit, needs to add
-   SIG(SOA), DNSKEY, SIG(DNSKEY), DNSNR, SIG(DNSNR) at the apex.  No
-   more than that.
-
-
-   Contributor: Roy Arends.
-
-
-12.  Non-overlap of denial records with possible zone records
-
-
-   Requirement:  NSEC++ records should in some way be differentiated
-   from regular zone records, so that there is no possibility that a
-   record in the zone could be duplicated by a non-existence proof
-   (NSEC++) record.
-
-
-   Additional discussion:  This requirement is derived from a discussion
-   on the DNSEXT mailing list related to copyrights and domain names.
-   As was outlined there, one solution is to put NSEC++ records in a
-   separate namespace, e.g.: $ORIGIN co.uk.
-   873bcdba87401b485022b8dcd4190e3e IN NS jim.rfc1035.com ; your
-   delegation 873bcdba87401b485022b8dcd4190e3e._no IN NSEC++ 881345...
-   ; for amazon.co.uk.
-
-
-   Contributor: various
-
-
-   (Editor comment:  One of us still does not see why a conflict
-   matters.  Even if there is an apparent conflict or overlap, the
-   "conflicting" NSEC2 name _only_ appears in NSEC2 records, and the
-   other name _never_ appears in NSEC2 records.)
-
-
-13.  Exposure of Private Keys
-
-
-   Private keys associated with the public keys in the DNS should be
-   exposed as little as possible.  It is highly undesirable for private
-   keys to be distributed to nameservers, or to otherwise be available
-   in the run-time environment of nameservers.
-
-
-
-
-
-Laurie & Loomis          Expires March 2, 2005                  [Page 7]
-Internet-Draft      signed-nonexistence-requirements      September 2004
-
-
-
-   Contributors: Nominet, Olaf Kolkman, Ed Lewis
-
-
-14.  Minimisation of Zone Signing Cost
-
-
-   The additional cost of creating an NSEC++ signed zone should not
-   significantly exceed the cost of creating an ordinary signed zone.
-
-
-   Contributor: Nominet
-
-
-15.  Minimisation of Asymmetry
-
-
-   Nameservers should have to do as little additional work as necessary.
-   More precisely, it is desirable for any increase in cost incurred by
-   the nameservers to be offset by a proportionate increase in cost to
-   DNS `clients', e.g.  stub and/or `full-service' resolvers.
-
-
-   Contributor: Nominet
-
-
-16.  Minimisation of Client Complexity
-
-
-   Caching, wildcards, CNAMEs, DNAMEs should continue to work without
-   adding too much complexity at the client side.
-
-
-   Contributor: Olaf Kolkman
-
-
-17.  Completeness
-
-
-   A proof of nonexistence should be possible for all nonexistent data
-   in the zone.
-
-
-   Contributor: Olaf Kolkman
-
-
-18.  Purity of Namespace
-
-
-   The name space should not be muddied with fake names or data sets.
-
-
-   Contributor: Ed Lewis
-
-
-19.  Replay Attacks
-
-
-   NSEC++ should not allow a replay to be used to deny existence of an
-   RR that actually exists.
-
-
-   Contributor: Ed Lewis
-
-
-20.  Compatibility with NSEC
-
-
-   NSEC++ should not introduce changes incompatible with NSEC.
-
-
-
-
-Laurie & Loomis          Expires March 2, 2005                  [Page 8]
-Internet-Draft      signed-nonexistence-requirements      September 2004
-
-
-
-   Contributor: Ed Lewis
-
-
-21.  Compatibility with NSEC II
-
-
-   NSEC++ should differ from NSEC in a way that is transparent to the
-   resolver or validator.
-
-
-   Contributor: Ed Lewis
-
-
-22.  Compatibility with NSEC III
-
-
-   NSEC++ should differ from NSEC as little as possible whilst achieving
-   other requirements.
-
-
-   Contributor: Alex Bligh
-
-
-23.  Coexistence with NSEC
-
-
-   NSEC++ should be optional, allowing NSEC to be used instead.
-
-
-   Contributor: Ed Lewis, Alex Bligh
-
-
-24.  Coexistence with NSEC II
-
-
-   NSEC++ should not impose extra work on those content with NSEC.
-
-
-   Contributor: Ed Lewis
-
-
-25.  Protocol Design
-
-
-   A good security protocol would allow signing the nonexistence of some
-   selected names without revealing anything about other names.
-
-
-   Contributor: Dan Bernstein
-
-
-26.  Process
-
-
-   Clearly not all of these requirements can be met.  Therefore the next
-   phase of this document will be to either prioritise them or narrow
-   them down to a non-contradictory set, which should then allow us to
-   judge proposals on the basis of their fit.
-
-
-27.  Acknowledgements
-
-
-28.  Requirements notation
-
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-
-
-
-
-Laurie & Loomis          Expires March 2, 2005                  [Page 9]
-Internet-Draft      signed-nonexistence-requirements      September 2004
-
-
-
-   document are to be interpreted as            described in [RFC2119].
-
-
-29.  Security Considerations
-
-
-   There are currently no security considerations called out in this
-   draft.  There will be security considerations in the choice of which
-   requirements will be implemented, but there are no specific security
-   requirements during the requirements collection process.
-
-
-30.  References
-
-
-30.1  Normative References
-
-
-   [dnssecbis-protocol]
-              "DNSSECbis Protocol Definitions", BCP XX, RFC XXXX, Some
-              Month 2004.
-
-
-30.2  Informative References
-
-
-   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
-              3", BCP 9, RFC 2026, October 1996.
-
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-
-   [RFC2418]  Bradner, S., "IETF Working Group Guidelines and
-              Procedures", BCP 25, RFC 2418, September 1998.
-
-
-
-Authors' Addresses
-
-
-   Ben Laurie
-   Nominet
-   17 Perryn Road
-   London  W3 7LR
-   England
-
-
-   Phone: +44 (20) 8735 0686
-   EMail: ben@algroup.co.uk
-
-
-
-   Rip Loomis
-   Science Applications International Corporation
-   7125 Columbia Gateway Drive, Suite 300
-   Columbia, MD  21046
-   US
-
-
-   EMail: gilbert.r.loomis@saic.com
-
-
-
-
-Laurie & Loomis          Expires March 2, 2005                 [Page 10]
-Internet-Draft      signed-nonexistence-requirements      September 2004
-
-
-
-Intellectual Property Statement
-
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-
-Disclaimer of Validity
-
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-Copyright Statement
-
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-
-Acknowledgment
-
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-Laurie & Loomis          Expires March 2, 2005                 [Page 11]
\ No newline at end of file
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt
deleted file mode 100644
index 9c73c68..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt
+++ /dev/null
@@ -1,1292 +0,0 @@
-
-
-
-
-
-DNS Extensions                                              Yuji Kamite
-Internet-Draft                                       NTT Communications
-Expires: April 15, 2005                                 Masaya Nakayama
-                                                The University of Tokyo
-                                                       October 14, 2004
-
-
-
-                      TKEY Secret Key Renewal Mode
-                 draft-ietf-dnsext-tkey-renewal-mode-05
-
-
-Status of this Memo
-
-   This document is an Internet-Draft and is subject to all provisions
-   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
-   author represents that any applicable patent or other IPR claims of
-   which he or she is aware have been or will be disclosed, and any of
-   which he or she become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as
-   Internet-Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on April 15, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).
-
-Abstract
-
-   This document defines a new mode in TKEY and proposes an atomic
-   method for changing secret keys used for TSIG periodically.
-   Originally, TKEY provides methods of setting up shared secrets other
-
-
-
-Kamite, et. al.          Expires April 15, 2005                 [Page 1]
-
-INTERNET-DRAFT                                              October 2004
-
-
-   than manual exchange, but it cannot control timing of key renewal
-   very well though it can add or delete shared keys separately. This
-   proposal is a systematical key renewal procedure intended for
-   preventing signing DNS messages with old and non-safe keys
-   permanently.
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-     1.1   Defined Words  . . . . . . . . . . . . . . . . . . . . . .  3
-     1.2   New Format and Assigned Numbers  . . . . . . . . . . . . .  4
-     1.3   Overview of Secret Key Renewal Mode  . . . . . . . . . . .  4
-   2.  Shared Secret Key Renewal  . . . . . . . . . . . . . . . . . .  5
-     2.1   Key Usage Time Check . . . . . . . . . . . . . . . . . . .  5
-     2.2   Partial Revocation . . . . . . . . . . . . . . . . . . . .  6
-     2.3   Key Renewal Message Exchange . . . . . . . . . . . . . . .  7
-       2.3.1   Query for Key Renewal  . . . . . . . . . . . . . . . .  7
-       2.3.2   Response for Key Renewal . . . . . . . . . . . . . . .  7
-       2.3.3   Attributes of Generated Key  . . . . . . . . . . . . .  8
-       2.3.4   TKEY RR structure  . . . . . . . . . . . . . . . . . .  8
-     2.4   Key Adoption . . . . . . . . . . . . . . . . . . . . . . . 10
-       2.4.1   Query for Key Adoption . . . . . . . . . . . . . . . . 10
-       2.4.2   Response for Key Adoption  . . . . . . . . . . . . . . 10
-     2.5   Keying Schemes . . . . . . . . . . . . . . . . . . . . . . 11
-       2.5.1   DH Exchange for Key Renewal  . . . . . . . . . . . . . 11
-       2.5.2   Server Assigned Keying for Key Renewal . . . . . . . . 12
-       2.5.3   Resolver Assigned Keying for Key Renewal . . . . . . . 13
-     2.6   Considerations about Non-compliant Hosts . . . . . . . . . 14
-   3.  Secret Storage . . . . . . . . . . . . . . . . . . . . . . . . 15
-   4.  Compulsory Key Revocation  . . . . . . . . . . . . . . . . . . 15
-     4.1   Compulsory Key Revocation by Server  . . . . . . . . . . . 15
-     4.2   Authentication Methods Considerations  . . . . . . . . . . 15
-   5.  Special Considerations for Two Servers' Case   . . . . . . . . 16
-     5.1   To Cope with Collisions of Renewal Requests  . . . . . . . 16
-   6.  Key Name Considerations  . . . . . . . . . . . . . . . . . . . 17
-   7.  Example Usage of Secret Key Renewal Mode   . . . . . . . . . . 17
-   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
-   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
-  10.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
-  11.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
-    11.1   Normative References . . . . . . . . . . . . . . . . . . . 21
-    11.2   Informative References . . . . . . . . . . . . . . . . . . 21
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
-       Intellectual Property and Copyright Statements . . . . . . . . 23
-
-
-
-
-
-
-
-Kamite, et. al.          Expires April 15, 2005                 [Page 2]
-
-INTERNET-DRAFT                                              October 2004
-
-
-1.  Introduction
-
-   TSIG [RFC2845] provides DNS message integrity and the
-   request/transaction authentication by means of message authentication
-   codes (MAC). TSIG is a practical solution in view of calculation
-   speed and availability. However, TSIG does not have exchanging
-   mechanism of shared secret keys between server and resolver, and
-   administrators might have to exchange secret keys manually. TKEY
-   [RFC2930] is introduced to solve such problem and it can exchange
-   secrets for TSIG via networks.
-
-   In various modes of TKEY, a server and a resolver can add or delete a
-   secret key be means of TKEY message exchange. However, the existing
-   TKEY does not care fully about the management of keys which became
-   too old, or dangerous after long time usage.
-
-   It is ideal that the number of secret which a pair of hosts share
-   should be limited only one, because having too many keys for the same
-   purpose might not only be a burden to resolvers for managing and
-   distinguishing according to servers to query, but also does not seem
-   to be safe in terms of storage and protection against attackers.
-   Moreover, perhaps holding old keys long time might give attackers
-   chances to compromise by scrupulous calculation.
-
-   Therefore, when a new shared secret is established by TKEY, the
-   previous old secret should be revoked immediately. To accomplish
-   this, DNS servers must support a protocol for key renewal. This
-   document specifies procedure to refresh secret keys between two hosts
-   which is defined within the framework of TKEY, and it is called "TKEY
-   Secret Key Renewal Mode".
-
-   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY" and
-   "OPTIONAL" in this document are to be interpreted as described in
-   [RFC2119].
-
-
-1.1.  Defined Words
-
-   * Inception Time: Beginning of the shared secret key lifetime. This
-   value is determined when the key is generated.
-
-   * Expiry Limit: Time limit of the key's validity. This value is
-   determined when a new key is generated. After Expiry Limit, server
-   and client (resolver) must not authenticate TSIG signed with the key.
-   Therefore, Renewal to the next key should be carried out before
-   Expiry Limit.
-
-   * Partial Revocation Time: Time when server judges the key is too old
-
-
-
-Kamite, et. al.          Expires April 15, 2005                 [Page 3]
-
-INTERNET-DRAFT                                              October 2004
-
-
-   and must be updated. It must be between Inception Time and Expiry
-   Limit.  This value is determined by server freely following its
-   security policy. e.g., If the time from Inception to Partial
-   Revocation is short, renewal will be carried out more often, which
-   might be safer.
-
-   * Revocation Time: Time when the key becomes invalid and can be
-   removed. This value is not determined in advance because it is the
-   actual time when revocation is completed.
-
-   * Adoption Time: Time when the new key is adopted as the next key
-   formally. After Adoption, the key is valid and server and client can
-   generate or verify TSIG making use of it. Adoption Time also means
-   the time when it becomes possible to remove the previous key, so
-   Revocation and Adoption are usually done at the same time.
-
-
-                  Partial
-    Inception     Revocation    Revocation         Expiry Limit
-     |                |              |             |
-     |----------------|- - - - - - >>|- (revoked) -|
-     |                |              |             |
-    previous key      |      |       |
-                             |- - - -|-------------------->> time
-                             |       |               new key
-                         Inception   Adoption
-
-
-1.2.  New Format and Assigned Numbers
-
-   TSIG
-         ERROR = (PartialRevoke), TBD
-
-   TKEY
-         Mode  = (server assignment for key renewal), TBD
-         Mode  = (Diffie-Hellman exchange for key renewal), TBD
-         Mode  = (resolver assignment for key renewal), TBD
-         Mode  = (key adoption), TBD
-
-
-1.3.  Overview of Secret Key Renewal Mode
-
-   When a server receives a query from a client signed with a TSIG key,
-   It always checks if the present time is within the range of usage
-   duration it considers safe. If it is judged that the key is too old,
-   i.e., after Partial Revocation Time, the server comes to be in
-   Partial Revocation state about the key, and this key is called
-   partially revoked.
-
-
-
-Kamite, et. al.          Expires April 15, 2005                 [Page 4]
-
-INTERNET-DRAFT                                              October 2004
-
-
-   In this state, if a client sends a normal query (e.g., question about
-   A RR) other than TKEY Renewal request with TSIG signed with the old
-   key, the server returns an error message to notify that the time to
-   renew has come. This is called "PartialRevoke" error message. It is
-   server's choice whether it returns PartialRevoke or not. If and only
-   if the server is ready for changing its own key, it decides to return
-   PartialRevoke.
-
-   The client which got this error is able to notice that it is
-   necessary to refresh the secret. To make a new shared secret, it
-   sends a TKEY Renewal request, in which several keying methods are
-   available. It can make use of TSIG authentication signed with the
-   partially revoked key mentioned above.
-
-   After new secret establishment, the client sends a TKEY Adoption
-   request for renewal confirmation. This can also be authenticated with
-   the partially revoked key. If this is admitted by the server, the new
-   key is formally adopted, and at the same time the corresponding old
-   secret is invalidated. Then the client can send the first query again
-   signed with the new key.
-
-   Key renewal procedure is executed based on two-phase commit
-   mechanism. The first phase is the TKEY Renewal request and its
-   response, which means preparatory confirmation for key update. The
-   second phase is Adoption request and its response. If the server gets
-   request and client receives the response successfully, they can
-   finish renewal process. If any error happens and renewal process
-   fails during these phases, client should roll back to the beginning
-   of the first phase, and send TKEY Renewal request again. This
-   rollback can be done until the Expiry Limit of the key.
-
-
-2.  Shared Secret Key Renewal
-
-   Suppose a server and a client agree to change their TSIG keys
-   periodically. Key renewal procedure is defined between two hosts.
-
-2.1.  Key Usage Time Check
-
-   Whenever a server receives a query with TSIG and can find a key that
-   is used for signing it, the server checks its Inception Time, Partial
-   Revocation Time and Expiry Limit (this information is usually
-   memorized by the server).
-
-   When the present time is before Inception Time, the server MUST NOT
-   verify TSIG with the key, and server acts the same way as when the
-   key used by the client is not recognized. It follows [RFC2845] 4.5.1.
-
-
-
-
-Kamite, et. al.          Expires April 15, 2005                 [Page 5]
-
-INTERNET-DRAFT                                              October 2004
-
-
-   When the present time is equal to Inception Time, or between
-   Inception Time and Partial Revocation Time, the behavior of the
-   server is the same as when a valid key is found. It follows [RFC2845]
-   4.5.2 and 4.5.3.
-
-   When the present time is the same as the Partial Revocation Time, or
-   between the Partial Revocation Time and Expiry Limit, the server
-   comes to be in Partial Revocation state about the TSIG key and
-   behaves according to the next section.
-
-   When the present time is the same as the Expiry Time or after it, the
-   server MUST NOT verify TSIG with the key, and returns error messages
-   in the same way as when the key used by the client is not recognized.
-   It follows [RFC2845] 4.5.1.
-
-
-2.2.  Partial Revocation
-
-   In Partial Revocation state, we say the server has partially revoked
-   the key and the key has become a "partially revoked key".
-
-   If server has received a query signed with the partially revoked key
-   for TKEY Renewal request (See section 2.3.) or Key Adoption request
-   (See section 2.4.), then server does proper process following each
-   specification. If it is for TKEY key deletion request ([RFC2930]
-   4.2), server MAY process usual deletion operation defined therein.
-
-   If server receives other types of query signed with the partially
-   revoked key, and both the corresponding MAC and signed TIME are
-   verified, then server begins returning answer whose TSIG error code
-   is "PartialRevoke" (See section 9.). Server MUST randomly but with
-   increasing frequency return PartialRevoke when in the Partial
-   Revocation state.
-
-   Server can decide when it actually sends PartialRevoke, checking if
-   it is appropriate time for renewal. Server MUST NOT return
-   PartialRevoke if this is apart long lived TSIG transaction (such as
-   AXFR) that started before the Partial Revocation Time.
-
-   If the client receives PartialRevoke and understands it, then it MUST
-   retry the query with the old key unless a new key has been adopted.
-   Client SHOULD start the process to renew the TSIG key. For key
-   renewal procedure, see details in Section 2.3 and 2.4.
-
-   PartialRevoke period (i.e., time while server returns PartialRevoke
-   randomely) SHOULD be small, say 2-5% of key lifetime. This is
-   server's choice.
-
-
-
-
-Kamite, et. al.          Expires April 15, 2005                 [Page 6]
-
-INTERNET-DRAFT                                              October 2004
-
-
-   Server MUST keep track of clients ignoring PartialRevoke, thus
-   indicating ignorance of this TKEY mode.
-
-   PartialRevoke error messages have the role to inform clients of the
-   keys' partial revocation and urge them to send TKEY Renewal requests.
-   These error responses MUST be signed with those partial revoked keys
-   if the queries are signed with them. They are sent only when the
-   signing keys are found to be partially revoked. If the MAC of TSIG
-   cannot be verified with the partially revoked keys, servers MUST NOT
-   return PartialRevoke error with MAC, but MUST return another error
-   such as "BADSIG" without MAC (following [RFC2845] 4.5.3); in other
-   words, a server informs its key's partial revocation only when the
-   MAC in the received query is valid.
-
-
-2.3.  Key Renewal Message Exchange
-
-2.3.1.  Query for Key Renewal
-
-   If a client has received a PartialRevoke error and authenticated the
-   response based on TSIG MAC, it sends a TKEY query for Key Renewal (in
-   this document, we call it Renewal request, too.) to the server. The
-   request MUST be signed with TSIG or SIG(0) [RFC2931] for
-   authentication. If TSIG is selected, the client can sign it with the
-   partial revoked key.
-
-   Key Renewal can use one of several keying methods which is indicated
-   in "Mode" field of TKEY RR, and its message structure is dependent on
-   that method.
-
-
-2.3.2.  Response for Key Renewal
-
-   The server which has received Key Renewal request first tries to
-   verify TSIG or SIG(0) accompanying it. If the TSIG is signed and
-   verified with the partially revoked key, the request MUST be
-   authenticated.
-
-   After authentication, server must check existing old key's validity.
-   If the partially revoked key indicated in the request TKEY's OldName
-   and OldAlgorithm field (See section 2.3.4.) does not exist at the
-   server, "BADKEY" [RFC2845] is given in Error field for response. If
-   any other error happens, server returns appropriate error messages
-   following the specification described in section 2.5. If there are no
-   errors, server returns a Key Renewal answer. This answer MUST be
-   signed with TSIG or SIG(0) for authentication.
-
-   When this answer is successfully returned and no error is detected by
-
-
-
-Kamite, et. al.          Expires April 15, 2005                 [Page 7]
-
-INTERNET-DRAFT                                              October 2004
-
-
-   client, a new shared secret can be established. The details of
-   concrete keying procedure are given in the section 2.5.
-
-   Note:
-      Sometimes Adoption message and new Renewal request will cross on
-      the wire. In this case the newly generated key Adoption message is
-      resent.
-
-
-2.3.3.  Attributes of Generated Key
-
-   As a result of this message exchange, client comes to know the newly
-   generated key's attributes such as key's name, Inception Time and
-   Expiry Limit. They are decided by the server and told to the client;
-   in particular, however, once the server has decided Expiry Limit and
-   returned a response, it should obey the decision as far as it can. In
-   other words, they SHOULD NOT change time values for checking Expiry
-   Limit in the future without any special reason, such as security
-   issue like "Emergency Compulsory Revocation" described in section 8.
-
-   On the other hand, Partial Revocation Time of this generated key is
-   not decided based on the request, and not informed to the client. The
-   server can determine any value as long as it is between Inception
-   Time and Expiry Limit. However, the period from Inception to Partial
-   Revocation SHOULD be fixed as the server side's configuration or be
-   set the same as the corresponding old key's one.
-
-   Note:
-      Even if client sends Key Renewal request though the key described
-      in OldName has not been partially revoked yet, server does renewal
-      processes.  At the moment when the server accepts such requests
-      with valid authentication, it MUST forcibly consider the key is
-      already partially revoked, that is, the key's Partial Revocation
-      Time must be changed into the present time (i.e., the time when
-      the server receives the request).
-
-
-2.3.4.  TKEY RR structure
-
-   TKEY RR for Key Renewal message has the structure given below. In
-   principle, format and definition for each field follows [RFC2930].
-   Note that each keying scheme sometimes needs different interpretation
-   of RDATA field; for detail, see section 2.5.
-
-        Field        Type         Comment
-        -------      ------       -------
-        NAME         domain       used for a new key, see below
-        TYPE         u_int16_t    (defined in [RFC2930])
-
-
-
-Kamite, et. al.          Expires April 15, 2005                 [Page 8]
-
-INTERNET-DRAFT                                              October 2004
-
-
-        CLASS        u_int16_t    (defined in [RFC2930])
-        TTL          u_int32_t    (defined in [RFC2930])
-        RDLEN        u_int16_t    (defined in [RFC2930])
-        RDATA:
-         Algorithm:   domain       algorithm for a new key
-         Inception:   u_int32_t    about the keying material
-         Expiration:  u_int32_t    about the keying material
-         Mode:        u_int16_t    scheme for key agreement
-                                   see section 9.
-         Error:       u_int16_t    see description below
-         Key Size:    u_int16_t    see description below
-         Key Data:    octet-stream
-         Other Size:  u_int16_t    (defined in [RFC2930])
-                                   size of other data
-         Other Data:               newly defined: see description below
-
-
-     For "NAME" field, both non-root and root name are allowed. It may
-     be used for a new key's name in the same manner as [RFC2930] 2.1.
-
-     "Algorithm" specifies which algorithm is used for agreed keying
-     material, which is used for identification of the next key.
-
-     "Inception" and "Expiration" are used for the valid period of
-     keying material. The meanings differ somewhat according to whether
-     the message is request or answer, and its keying scheme.
-
-     "Key Data" has different meanings according to keying schemes.
-
-     "Mode" field stores the value in accordance with the keying method,
-     and see section 2.5. Servers and clients supporting TKEY Renewal
-     method MUST implement "Diffie-Hellman exchange for key renewal"
-     scheme. All other modes are OPTIONAL.
-
-     "Error" is an extended RCODE which includes "PartialRevoke" value
-     too. See section 9.
-
-     "Other Data" field has the structure given below.  They describe
-     attributes of the key to be renewed.
-
-        in Other Data filed:
-
-          Field            Type       Comment
-          -------          ------     -------
-          OldNAME          domain     name of the old key
-          OldAlgorithm     domain     algorithm of the old key
-
-
-
-
-
-Kamite, et. al.          Expires April 15, 2005                 [Page 9]
-
-INTERNET-DRAFT                                              October 2004
-
-
-          "OldName" indicates the name of the previous key (usually,
-          this is partially revoked key's name that client noticed by
-          PartialRevoke answer from server), and "OldAlogirthm"
-          indicates its algorithm.
-
-
-2.4.  Key Adoption
-
-2.4.1.  Query for Key Adoption
-
-   After receiving a TKEY Renewal answer, the client gets the same
-   secret as the server. Then, it sends a TKEY Adoption request. The
-   request's question section's QNAME field is the same as the NAME
-   filed of TKEY written below. In additional section, there is one TKEY
-   RR that has the structure and values described below.
-
-     "NAME" field is the new key's name to be adopted which was already
-     generated by Renewal message exchange. "Algorithm" is its
-     algorithm. "Inception" means the key's Inception Time, and
-     "Expiration" means Expiry Limit.
-
-     "Mode" field is the value of "key adoption". See section 9.
-
-     "Other Data" field in Adoption has the same structure as that of
-     Renewal request message. "OldName" means the previous old key, and
-     "OldAlogirthm" means its algorithm.
-
-   Key Adoption request MUST be signed with TSIG or SIG(0) for
-   authentication. The client can sign TSIG with the previous key. Note
-   that until Adoption is finished, the new key is treated as invalid,
-   thus it cannot be used for authentication immediately.
-
-
-2.4.2.  Response for Key Adoption
-
-   The server which has received Adoption request, it verifies TSIG or
-   SIG(0) accompanying it. If the TSIG is signed with the partially
-   revoked key and can be verified, the message MUST be authenticated.
-
-   If the next new key indicated by the request TKEY's "NAME" is not
-   present at the server, BADNAME [RFC2845] is given in Error field and
-   the error message is returned.
-
-   If the next key exists but it has not been adopted formally yet, the
-   server confirms the previous key's existence indicated by the
-   "OldName" and "OldAlgorithm" field. If it succeeds, the server
-   executes Adoption of the next key and Revocation of the previous key.
-   Response message duplicates the request's TKEY RR with NOERROR,
-
-
-
-Kamite, et. al.          Expires April 15, 2005                [Page 10]
-
-INTERNET-DRAFT                                              October 2004
-
-
-   including "OldName" and "OldAlgorithm" that indicate the revoked key.
-
-   If the next key exists but it is already adopted, the server returns
-   a response message regardless of the substance of the request TKEY's
-   "OldName". In this response, Response TKEY RR has the same data as
-   the request's one except as to its "Other Data" that is changed into
-   null (i.e., "Other Size" is zero), which is intended for telling the
-   client that the previous key name was ignored, and the new key is
-   already available.
-
-   Client sometimes has to retry Adoption request. Suppose the client
-   sent request signed with the partially revoked key, but its response
-   did not return successfully (e.g., due to the drop of UDP packet).
-   Client will probably retry Adoption request; however, the request
-   will be refused in the form of TSIG "BADKEY" error because the
-   previous key was already revoked. In this case, client will
-   retransmit Adoption request signed with the next key, and expect a
-   response which has null "Other Data" for confirming the completion of
-   renewal.
-
-
-2.5.  Keying Schemes
-
-   In Renewal message exchanges, there are no limitations as to which
-   keying method is actually used. The specification of keying
-   algorithms is independent of the general procedure of Renewal that is
-   described in section 2.3.
-
-   Now this document specifies three algorithms in this section, but
-   other future documents can make extensions defining other methods.
-
-
-2.5.1.  DH Exchange for Key Renewal
-
-   This scheme is defined as an extended method of [RFC2930] 4.1. This
-   specification only describes the difference from it and special
-   notice; assume that all other points, such as keying material
-   computation, are the exactly same as the specification of [RFC2930]
-   4.1.
-
-   Query
-      In Renewal request for type TKEY with this mode, there is one TKEY
-      RR and one KEY RR in the additional information section. KEY RR is
-      the client's Diffie-Hellman public key [RFC2539].
-
-      QNAME in question section is the same as that of "NAME" field in
-      TKEY RR, i.e., it means the requested new key's name.
-
-
-
-
-Kamite, et. al.          Expires April 15, 2005                [Page 11]
-
-INTERNET-DRAFT                                              October 2004
-
-
-      TKEY "Mode" field stores the value of "DH exchange for key
-      renewal". See section 9.
-
-      TKEY "Inception" and "Expiration" are those requested for the
-      keying material, that is, requested usage period of a new key.
-
-      TKEY "Key Data" is used as a random, following [RFC2930] 4.1.
-
-   Response
-      The server which received this request first verifies the TSIG,
-      SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the
-      old key's existence validity is checked, following section 2.3. If
-      any incompatible DH key is found in the request, "BADKEY"
-      [RFC2845] is given in Error field for response. "FORMERR" is given
-      if the query included no DH KEY.
-
-      If there are no errors, the server processes a response according
-      to Diffie-Hellman algorithm and returns the answer. In this
-      answer, there is one TKEY RR in answer section and KEY RR(s) in
-      additional section.
-
-      As long as no error has occurred, all values of TKEY are equal to
-      that of the request message except TKEY NAME, TKEY RDLEN, RDATA's
-      Inception, Expiration, Key Size and Key Data.
-
-      TKEY "NAME" field in the answer specifies the name of newly
-      produced key which the client MUST use.
-
-      TKEY "Inception" and "Expiration" mean the periods of the produced
-      key usage. "Inception" is set to be the time when the new key is
-      actually generated or the time before it, and it will be regarded
-      as Inception Time. "Expiration" is determined by the server, and
-      it will be regarded as Expiry Limit.
-
-      TKEY "Key Data" is used as an additional nonce, following
-      [RFC2930] 4.1.
-
-      The resolver supplied Diffie-Hellman KEY RR SHOULD be echoed in
-      the additional section and a server Diffie-Hellman KEY RR will
-      also be present in the answer section, following [RFC2930] 4.1.
-
-
-2.5.2.  Server Assigned Keying for Key Renewal
-
-   This scheme is defined as an extended method of [RFC2930] 4.4. This
-   specification only describes the difference from it and special
-   notice; assume that all other points, such as secret encrypting
-   method, are the exactly same as the specification of [RFC2930] 4.4.
-
-
-
-Kamite, et. al.          Expires April 15, 2005                [Page 12]
-
-INTERNET-DRAFT                                              October 2004
-
-
-   Query
-      In Renewal request for type TKEY with this mode, there is one TKEY
-      RR and one KEY RR in the additional information section. KEY RR is
-      used in encrypting the response.
-
-      QNAME in question section is the same as that of "NAME" field in
-      TKEY RR, i.e., it means the requested new key's name.
-
-      TKEY "Mode" field stores the value of "server assignment for key
-      renewal". See section 9.
-
-      TKEY "Inception" and "Expiration" are those requested for the
-      keying material, that is, requested usage period of a new key.
-
-      TKEY "Key Data" is provided following the specification of
-      [RFC2930] 4.4.
-
-   Response
-      The server which received this request first verifies the TSIG,
-      SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the
-      old key's existence validity is checked, following section 2.3.
-      "FORMERR" is given if the query specified no encryption key.
-
-      If there are no errors, the server response contains one TKEY RR
-      in the answer section, and echoes the KEY RR provided in the query
-      in the additional information section.
-
-      TKEY "NAME" field in the answer specifies the name of newly
-      produced key which the client MUST use.
-
-      TKEY "Inception" and "Expiration" mean the periods of the produced
-      key usage. "Inception" is set to be the time when the new key is
-      actually generated or the time before it, and it will be regarded
-      as Inception Time. "Expiration" is determined by the server, and
-      it will be regarded as Expiry Limit.
-
-      TKEY "Key Data" is the assigned keying data encrypted under the
-      public key in the resolver provided KEY RR, which is the same as
-      [RFC2930] 4.4.
-
-
-2.5.3.  Resolver Assigned Keying for Key Renewal
-
-   This scheme is defined as an extended method of [RFC2930] 4.5. This
-   specification only describes the difference from it and special
-   notice; assume that all other points, such as secret encrypting
-   method, are the exactly same as the specification of [RFC2930] 4.5.
-
-
-
-
-Kamite, et. al.          Expires April 15, 2005                [Page 13]
-
-INTERNET-DRAFT                                              October 2004
-
-
-   Query
-      In Renewal request for type TKEY with this mode, there is one TKEY
-      RR and one KEY RR in the additional information section. TKEY RR
-      has the encrypted keying material and KEY RR is the server public
-      key used to encrypt the data.
-
-      QNAME in question section is the same as that of "NAME" field in
-      TKEY RR, i.e., it means the requested new key's name.
-
-      TKEY "Mode" field stores the value of "resolver assignment for key
-      renewal". See section 9.
-
-      TKEY "Inception" and "Expiration" are those requested for the
-      keying material, that is, requested usage period of a new key.
-
-      TKEY "Key Data" is the encrypted keying material.
-
-   Response
-      The server which received this request first verifies the TSIG,
-      SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the
-      old key's existence validity is checked, following section 2.3.
-      "FORMERR" is given if the server does not have the corresponding
-      private key for the KEY RR that was shown sin the request.
-
-      If there are no errors, the server returns a response. The
-      response contains a TKEY RR in the answer section to tell the
-      shared key's name and its usage time values.
-
-      TKEY "NAME" field in the answer specifies the name of newly
-      produced key which the client MUST use.
-
-      TKEY "Inception" and "Expiration" mean the periods of the produced
-      key usage. "Inception" is set to be the time when the new key is
-      actually generated or the time before it, and it will be regarded
-      as Inception Time. "Expiration" is determined by the server, and
-      it will be regarded as Expiry Limit.
-
-
-2.6.  Considerations about Non-compliant Hosts
-
-   Key Renewal requests and responses must be exchanged between hosts
-   which can understand them and do proper processes. PartialRevoke
-   error messages will be only ignored if they should be returned to
-   non-compliant hosts.
-
-   Note that server does not inform actively the necessity of renewal to
-   clients, but inform it as responses invoked by client's query.
-   Server needs not care whether the PartialRevoke errors has reached
-
-
-
-Kamite, et. al.          Expires April 15, 2005                [Page 14]
-
-INTERNET-DRAFT                                              October 2004
-
-
-   client or not. If client has not received yet because of any reasons
-   such as packet drops, it will resend the queries, and finally will be
-   able to get PartialRevoke information.
-
-
-3.  Secret Storage
-
-   Every server keeps all secrets and attached information, e.g.,
-   Inception Time, Expiry Limit, etc. safely to be able to recover from
-   unexpected stop. To accomplish this, formally adopted keys SHOULD be
-   memorized not only on memory, but also be stored in the form of some
-   files. It will become more secure if they are stored in ecrypted
-   form.
-
-
-4.  Compulsory Key Revocation
-
-4.1.  Compulsory Key Revocation by Server
-
-   There is a rare but possible case that although servers have already
-   partially revoked keys, clients do not try to send any Renewal
-   requests. If this state continues, in the future it will become the
-   time of Expiry Limit. After Expiry Limit, the keys will be expired
-   and completely removed, so this is called Compulsory Key Revocation
-   by server.
-
-   If Expiry Limit is too distant from the Partial Revocation Time, then
-   even though very long time passes, clients will be able to refresh
-   secrets only if they add TSIG signed with those old partially revoked
-   keys into requests, which is not safe.
-
-   On the other hand, if Expiry Limit is too close to Partial Revocation
-   Time, perhaps clients might not be able to notice their keys' Partial
-   Revocation by getting "PartialRevoke" errors.
-
-   Therefore, servers should set proper Expiry Limit to their keys,
-   considering both their keys' safety, and enough time for clients to
-   send requests and process renewal.
-
-
-4.2.  Authentication Methods Considerations
-
-   It might be ideal to provide both SIG(0) and TSIG as authentication
-   methods. For example:
-
-     A client and a server start SIG(0) authentication at first, to
-     establish TSIG shared keys by means of "Query for Diffie-Hellman
-     Exchanged Keying" as described in [RFC2930] 4.1. Once they get
-
-
-
-Kamite, et. al.          Expires April 15, 2005                [Page 15]
-
-INTERNET-DRAFT                                              October 2004
-
-
-     shared secret, they keep using TSIG for queries and responses.
-     After a while the server returns a "ParitalRevoke" error and they
-     begin a key renewal process. Both TSIG signed with partially
-     revoked keys and SIG(0) are okay for authentication, but TSIG would
-     be easier to use considering calculation efficiency.
-
-     Suppose now client is halted for long time with some reason.
-     Because server does not execute any renewal process, it will
-     finally do Compulsory Revocation. Even if client restarts and sends
-     a key Renewal request, it will fail because old key is already
-     deleted at server.
-
-     At this moment, however, if client also uses SIG(0) as another
-     authentication method, it can make a new shared key again and
-     recover successfully by sending "Query for Diffie-Hellman Exchanged
-     Keying" with SIG(0).
-
-
-5.  Special Considerations for Two servers' Case
-
-   This section refers to the case where both hosts are DNS servers
-   which can act as full resolvers as well and using one shared key
-   only. If one server (called Server A) wants to refresh a shared key
-   (called "Key A-B"), it will await a TKEY Renewal request from the
-   other server (called Server B). However, perhaps Server A wants to
-   refresh the key right now.
-
-   In this case, Server A is allowed to send a Renewal request to Server
-   B, if Server A knows the Key A-B is too old and wants to renew it
-   immediately.
-
-   Note that the initiative in key renewal belongs to Server A because
-   it can notice the Partial Revocation Time and decide key renewal. If
-   Server B has information about Partial Revocation Time as well, it
-   can also decide for itself to send Renewal request to Server A.
-   However, it is not essential for both two servers have information
-   about key renewal timing.
-
-5.1.  To Cope with Collisions of Renewal Requests
-
-   At least one of two hosts which use Key Renewal must know their key
-   renewal information such as Partial Revocation Time. It is okay that
-   both hosts have it.
-
-   Provided that both two servers know key renewal timing information,
-   there is possibility for them to begin partial revocation and sending
-   Renewal requests to each other at the same time. Such collisions will
-   not happen so often because Renewal requests are usually invoked when
-
-
-
-Kamite, et. al.          Expires April 15, 2005                [Page 16]
-
-INTERNET-DRAFT                                              October 2004
-
-
-   hosts want to send queries, but it is possible.
-
-   When one of two servers tries to send Renewal requests, it MUST
-   protect old secrets that it has partially revoked and prevent it from
-   being refreshed by any requests from the other server (i.e., it must
-   lock the old secret during the process of renewal). While the server
-   is sending Renewal requests and waiting responses, it ignores the
-   other server's Renewal requests.
-
-   Therefore, servers might fail to change secrets by means of their own
-   requests to others. After failure they will try to resend, but they
-   should wait for random delays by the next retries. If they get any
-   Renewal requests from others while they are waiting, their shared
-   keys may be refreshed, then they do not need to send any Renewal
-   requests now for themselves.
-
-
-6.  Key Name Considerations
-
-   Since both servers and clients have only to distinguish new secrets
-   and old ones, keys' names do not need to be specified strictly.
-   However, it is recommended that some serial number or key generation
-   time be added to the name and that the names of keys between the same
-   pair of hosts should have some common labels among their keys. For
-   example, suppose A.example.com. and B.example.com. share the key
-   "<serial number>.A.example.com.B.example.com." such as
-   "10010.A.example.com.B.example.com.". After key renewal, they change
-   their secret and name into "10011.A.example.com.B.example.com."
-
-   Servers and clients must be able to use keys properly for each query.
-   Because TSIG secret keys themselves do not have any particular IDs to
-   be distinguished and would be identified by their names and
-   algorithm, it must be understood correctly what keys are refreshed.
-
-
-7.  Example Usage of Secret Key Renewal Mode
-
-   This is an example of Renewal mode usage where a Server,
-   server.example.com, and a Client, client.exmple.com have an initial
-   shared secret key named "00.client.example.com.server.example.com".
-
-     (1) The time values for key
-     "00.client.example.com.server.example.com" was set as follows:
-     Inception Time is at 1:00, Expiry Limit is at 21:00.
-
-     (2) At Server, renewal time has been set: Partial Revocation Time
-     is at 20:00.
-
-
-
-
-Kamite, et. al.          Expires April 15, 2005                [Page 17]
-
-INTERNET-DRAFT                                              October 2004
-
-
-     (3) Suppose the present time is 19:55. If Client sends a query
-     signed with key "00.client.example.com.server.example.com" to ask
-     the IP address of "www.example.com", finally it will get a proper
-     answer from Server with valid TSIG (NOERROR).
-
-     (4) At 20:05. Client sends a query to ask the IP address of
-     "www2.example.com". It is signed with key
-     "00.client.example.com.server.example.com". Server returns an
-     answer for the IP address. However, server has begun retuning
-     PartialRevoke Error randomely. This answer includes valid TSIG MAC
-     signed with "00.client.example.com.server.example.com", and its
-     Error Code indicates PartialRevoke. Client understands that the
-     current key is partially revoked.
-
-     (5) At 20:06. Client sends a Renewal request to Server. This
-     request is signed with key
-     "00.client.example.com.server.example.com". It includes data such
-     as:
-
-      Question Section:
-         QNAME = 01.client.example.com. (Client can set this freely)
-         TYPE  = TKEY
-
-      Additional Section:
-         01.client.example.com. TKEY
-          Algorithm    = hmac-md5-sig-alg.reg.int.
-          Inception    = (value meaning 20:00)
-          Expiration   = (value meaning next day's 16:00)
-          Mode         = (DH exchange for key renewal)
-          OldName      = 00.client.example.com.server.example.com.
-          OldAlgorithm = hmac-md5-sig-alg.reg.int.
-
-      Additional Section also contains a KEY RR for DH and a TSIG RR.
-
-     (6) As soon as Server receives this request, it verifies TSIG. It
-     is signed with the partially revoked key
-     "00.client.example.com.server.example.com". and Server accepts the
-     request. It creates a new key by Diffie-Hellman calculation and
-     returns an answer which includes data such as:
-
-      Answer Section:
-         01.client.example.com.server.example.com. TKEY
-          Algorithm    = hmac-md5-sig-alg.reg.int.
-          Inception    = (value meaning 20:00)
-          Expiration   = (value meaning next day's 16:00)
-          Mode         = (DH exchange for key renewal)
-          OldName      = 00.client.example.com.server.example.com.
-          OldAlgorithm = hmac-md5-sig-alg.reg.int.
-
-
-
-Kamite, et. al.          Expires April 15, 2005                [Page 18]
-
-INTERNET-DRAFT                                              October 2004
-
-
-     Answer Section also contains KEY RRs for DH.
-
-      Additional Section also contains a TSIG RR.
-     This response is signed with key
-     "00.client.example.com.server.example.com" without error.
-
-     At the same time, Server decides to set the Partial Revocation Time
-     of this new key "01.client.example.com.server.example.com." as next
-     day's 15:00.
-
-     (7) Client gets the response and checks TSIG MAC, and calculates
-     Diffie-Hellman. It will get a new key, and it has been named
-     "01.client.example.com.server.example.com" by Server.
-
-     (8) At 20:07. Client sends an Adoption request to Server. This
-     request is signed with the previous key
-     "00.client.example.com.server.example.com". It includes:
-
-      Question Section:
-         QNAME = 01.client.example.com.server.example.com.
-         TYPE  = TKEY
-
-      Additional Section:
-         01.client.example.com.server.example.com. TKEY
-          Algorithm    = hmac-md5-sig-alg.reg.int.
-          Inception    = (value meaning 20:00)
-          Expiration   = (value meaning next day's 16:00)
-          Mode         = (key adoption)
-          OldName      = 00.client.example.com.server.example.com.
-          OldAlgorithm = hmac-md5-sig-alg.reg.int.
-
-     Additional Section also contains a TSIG RR.
-
-     (9) Server verifies the query's TSIG. It is signed with the
-     previous key and authenticated. It returns a response whose TKEY RR
-     is the same as the request's one. The response is signed with key
-     "00.client.example.com.server.example.com.". As soon as the
-     response is sent, Server revokes and removes the previous key. At
-     the same time, key "01.client.example.com.server.example.com." is
-     validated.
-
-     (10) Client acknowledges the success of Adoption by receiving the
-     response.  Then, it retries to send an original question about
-     "www2.example.com". It is signed with the adopted key
-     "01.client.example.com.server.example.com", so Server authenticates
-     it and returns an answer.
-
-
-
-
-
-Kamite, et. al.          Expires April 15, 2005                [Page 19]
-
-INTERNET-DRAFT                                              October 2004
-
-
-     (11) This key is used until next day's 15:00. After that, it will
-     be partially revoked again.
-
-
-8.  Security Considerations
-
-   This document considers about how to refresh shared secret. Secret
-   changed by this method is used at servers in support of TSIG
-   [RFC2845].
-
-   [RFC2104] says that current attacks to HMAC do not indicate a
-   specific recommended frequency for key changes but periodic key
-   refreshment is a fundamental security practice that helps against
-   potential weaknesses of the function and keys, and limits the damage
-   of an exposed key. TKEY Secret Key Renewal provides the method of
-   periodical key refreshment.
-
-   In TKEY Secret Key Renewal, clients need to send two requests
-   (Renewal and Adoption) and spend time to finish their key renewal
-   processes. Thus the usage period of secrets should be considered
-   carefully based on both TKEY processing performance and security.
-
-   This document specifies the procedure of periodical key renewal, but
-   actually there is possibility for servers to have no choice other
-   than revoking their secret keys immediately especially when the keys
-   are found to be compromised by attackers. This is called "Emergency
-   Compulsory Revocation". For example, suppose the original Expiry
-   Limit was set at 21:00, Partial Revocation Time at 20:00 and
-   Inception Time at 1:00.  if at 11:00 the key is found to be
-   compromised, the server sets Expiry Limit forcibly to be 11:00 or
-   before it.
-
-   Consequently, once Compulsory Revocation (See section 4.) is carried
-   out, normal renewal process described in this document cannot be done
-   any more as far as the key is concerned. However, after such
-   accidents happened, the two hosts are able to establish secret keys
-   and begin renewal procedure only if they have other (non-compromised)
-   shared TSIG keys or safe SIG(0) keys for the authentication of
-   initial secret establishment such as Diffie-Hellman Exchanged Keying.
-
-
-9.  IANA Considerations
-
-   IANA needs to allocate a value for "DH exchange for key renewal",
-   "server assignment for key renewal", "resolver assignment for key
-   renewal" and "key adoption" in the mode filed of TKEY. It also needs
-   to allocate a value for "PartialRevoke" from the extended RCODE
-   space.
-
-
-
-Kamite, et. al.          Expires April 15, 2005                [Page 20]
-
-INTERNET-DRAFT                                              October 2004
-
-
-10.  Acknowledgements
-
-   The authors would like to thank Olafur Gudmundsson, whose helpful
-   input and comments contributed greatly to this document.
-
-
-11.  References
-
-11.1.  Normative References
-
-[RFC2119]
-     Bradner, S., "Key words for use in RFCs to Indicate Requirement
-     Levels", RFC 2119, March 1997.
-
-[RFC2539]
-     D. Eastlake 3rd, "Storage of Diffie-Hellman Keys in the Domain Name
-     System (DNS)", RFC 2539, March 1999.
-
-[RFC2845]
-     Vixie, P., Gudmundsson, O., Eastlake, D. and B.  Wellington,
-     "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845,
-     May 2000.
-
-[RFC2930]
-     D. Eastlake 3rd, ``Secret Key Establishment for DNS (TKEY RR)'',
-     RFC 2930, September 2000.
-
-[RFC2931]
-     D. Eastlake 3rd, "DNS Request and Transaction Signatures (SIG(0)s
-     )", RFC 2931, September 2000.
-
-11.2.  Informative References
-
-[RFC2104]
-     H. Krawczyk, M.Bellare, R. Canetti, "Keyed-Hashing for Message
-     Authentication", RFC2104, February 1997.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kamite, et. al.          Expires April 15, 2005                [Page 21]
-
-INTERNET-DRAFT                                              October 2004
-
-
-Authors' Addresses
-
-   Yuji Kamite
-   NTT Communications Corporation
-   Tokyo Opera City Tower
-   3-20-2 Nishi Shinjuku, Shinjuku-ku, Tokyo
-   163-1421, Japan
-   EMail: y.kamite@ntt.com
-
-
-   Masaya Nakayama
-   Information Technology Center, The University of Tokyo
-   2-11-16 Yayoi, Bunkyo-ku, Tokyo
-   113-8658, Japan
-   EMail: nakayama@nc.u-tokyo.ac.jp
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kamite, et. al.          Expires April 15, 2005                [Page 22]
-
-INTERNET-DRAFT                                              October 2004
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Kamite, et. al.          Expires April 15, 2005                [Page 23]
-
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt
deleted file mode 100644
index a598826..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt
+++ /dev/null
@@ -1,1501 +0,0 @@
-Network Working Group                                           J. Ihren
-Internet-Draft                                             Autonomica AB
-Expires: April 18, 2005                                       O. Kolkman
-                                                                RIPE NCC
-                                                              B. Manning
-                                                                  EP.net
-                                                        October 18, 2004
-
-
-
-  An In-Band Rollover Mechanism and an Out-Of-Band Priming Method for
-                         DNSSEC Trust Anchors.
-               draft-ietf-dnsext-trustupdate-threshold-00
-
-
-Status of this Memo
-
-
-   By submitting this Internet-Draft, I certify that any applicable
-   patent or other IPR claims of which I am aware have been disclosed,
-   and any of which I become aware will be disclosed, in accordance with
-   RFC 3668.
-
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as
-   Internet-Drafts.
-
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-
-   This Internet-Draft will expire on April 18, 2005.
-
-
-Copyright Notice
-
-
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-
-Abstract
-
-
-   The DNS Security Extensions (DNSSEC) works by validating so called
-   chains of authority.  The start of these chains of authority are
-   usually public keys that are anchored in the DNS clients.  These keys
-   are known as the so called trust anchors.
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                 [Page 1]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-   This memo describes a method how these client trust anchors can be
-   replaced using the DNS validation and querying mechanisms (in-band)
-   when the key pairs used for signing by zone owner are rolled.
-
-
-   This memo also describes a method to establish the validity of trust
-   anchors for initial configuration, or priming, using out of band
-   mechanisms.
-
-
-Table of Contents
-
-
-   1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
-     1.1   Key Signing Keys, Zone Signing Keys and Secure Entry
-           Points . . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Introduction and Background  . . . . . . . . . . . . . . . . .  5
-     2.1   Dangers of Stale Trust Anchors . . . . . . . . . . . . . .  5
-   3.  Threshold-based Trust Anchor Rollover  . . . . . . . . . . . .  7
-     3.1   The Rollover . . . . . . . . . . . . . . . . . . . . . . .  7
-     3.2   Threshold-based Trust Update . . . . . . . . . . . . . . .  8
-     3.3   Possible Trust Update States . . . . . . . . . . . . . . .  9
-     3.4   Implementation notes . . . . . . . . . . . . . . . . . . . 10
-     3.5   Possible transactions  . . . . . . . . . . . . . . . . . . 11
-       3.5.1   Single DNSKEY replaced . . . . . . . . . . . . . . . . 12
-       3.5.2   Addition of a new DNSKEY (no removal)  . . . . . . . . 12
-       3.5.3   Removal of old DNSKEY (no addition)  . . . . . . . . . 12
-       3.5.4   Multiple DNSKEYs replaced  . . . . . . . . . . . . . . 12
-     3.6   Removal of trust anchors for a trust point . . . . . . . . 12
-     3.7   No need for resolver-side overlap of old and new keys  . . 13
-   4.  Bootstrapping automatic rollovers  . . . . . . . . . . . . . . 14
-     4.1   Priming Keys . . . . . . . . . . . . . . . . . . . . . . . 14
-       4.1.1   Bootstrapping trust anchors using a priming key  . . . 14
-       4.1.2   Distribution of priming keys . . . . . . . . . . . . . 15
-   5.  The Threshold Rollover Mechanism vs Priming  . . . . . . . . . 16
-   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
-     6.1   Threshold-based Trust Update Security Considerations . . . 17
-     6.2   Priming Key Security Considerations  . . . . . . . . . . . 17
-   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
-   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
-   8.1   Normative References . . . . . . . . . . . . . . . . . . . . 20
-   8.2   Informative References . . . . . . . . . . . . . . . . . . . 20
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
-   A.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 22
-   B.  Document History . . . . . . . . . . . . . . . . . . . . . . . 23
-     B.1   prior to version 00  . . . . . . . . . . . . . . . . . . . 23
-     B.2   version 00 . . . . . . . . . . . . . . . . . . . . . . . . 23
-       Intellectual Property and Copyright Statements . . . . . . . . 24
-
-
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                 [Page 2]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-1.  Terminology
-
-
-   The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
-   and "MAY" in this document are to be interpreted as described in
-   RFC2119 [1].
-
-
-   The term "zone" refers to the unit of administrative control in the
-   Domain Name System.  In this document "name server" denotes a DNS
-   name server that is authoritative (i.e.  knows all there is to know)
-   for a DNS zone.  A "zone owner" is the entity responsible for signing
-   and publishing a zone on a name server.  The terms "authentication
-   chain", "bogus", "trust anchors" and "Island of Security" are defined
-   in [4].  Throughout this document we use the term "resolver" to mean
-   "Validating Stub Resolvers" as defined in [4].
-
-
-   We use the term "security apex" as the zone for which a trust anchor
-   has been configured (by validating clients) and which is therefore,
-   by definition, at the root of an island of security.  The
-   configuration of trust anchors is a client side issue.  Therefore a
-   zone owner may not always know if their zone has become a security
-   apex.
-
-
-   A "stale anchor" is a trust anchor (a public key) that relates to a
-   key that is not used for signing.  Since trust anchors indicate that
-   a zone is supposed to be secure a validator will mark the all data in
-   an island of security as bogus when all trust anchors become stale.
-
-
-   It is assumed that the reader is familiar with public key
-   cryptography concepts [REF: Schneier Applied Cryptography] and is
-   able to distinguish between the private and public parts of a key
-   based on the context in which we use the term "key".  If there is a
-   possible ambiguity we will explicitly mention if a private or a
-   public part of a key is used.
-
-
-   The term "administrator" is used loosely throughout the text.  In
-   some cases an administrator is meant to be a person, in other cases
-   the administrator may be a process that has been delegated certain
-   responsibilities.
-
-
-1.1  Key Signing Keys, Zone Signing Keys and Secure Entry Points
-
-
-   Although the DNSSEC protocol does not make a distinction between
-   different keys the operational practice is that a distinction is made
-   between zone signing keys and key signing keys.  A key signing key is
-   used to exclusively sign the DNSKEY Resource Record (RR) set at the
-   apex of a zone and the zone signing keys sign all the data in the
-   zone (including the DNSKEY RRset at the apex).
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                 [Page 3]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-   Keys that are intended to be used as the start of the authentication
-   chain for a particular zone, either because they are pointed to by a
-   parental DS RR or because they are configured as a trust anchor, are
-   called Secure Entry Point (SEP) keys.  In practice these SEP keys
-   will be key signing keys.
-
-
-   In order for the mechanism described herein to work the keys that are
-   intended to be used as secure entry points MUST have the SEP [2] flag
-   set.  In the examples it is assumed that keys with the SEP flag set
-   are used as key signing keys and thus exclusively sign the DNSKEY
-   RRset published at the apex of the zone.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                 [Page 4]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-2.  Introduction and Background
-
-
-   When DNSSEC signatures are validated the resolver constructs a chain
-   of authority from a pre-configured trust anchor to the DNSKEY
-   Resource Record (RR), which contains the public key that validates
-   the signature stored in an RRSIG RR.  DNSSEC is designed so that the
-   administrator of a resolver can validate data in multiple islands of
-   security by configuring multiple trust anchors.
-
-
-   It is expected that resolvers will have more than one trust anchor
-   configured.  Although there is no deployment experience it is not
-   unreasonable to expect resolvers to be configured with a number of
-   trust anchors that varies between order 1 and order 1000.  Because
-   zone owners are expected to roll their keys, trust anchors will have
-   to be maintained (in the resolver end) in order not to become stale.
-
-
-   Since there is no global key maintenance policy for zone owners and
-   there are no mechanisms in the DNS to signal the key maintenance
-   policy it may be very hard for resolvers administrators to keep their
-   set of trust anchors up to date.  For instance, if there is only one
-   trust anchor configured and the key maintenance policy is clearly
-   published, through some out of band trusted channel, then a resolver
-   administrator can probably keep track of key rollovers and update the
-   trust anchor manually.  However, with an increasing number of trust
-   anchors all rolled according to individual policies that are all
-   published through different channels this soon becomes an
-   unmanageable problem.
-
-
-2.1  Dangers of Stale Trust Anchors
-
-
-   Whenever a SEP key at a security apex is rolled there exists a danger
-   that "stale anchors" are created.  A stale anchor is a trust anchor
-   (i.e.  a public key configured in a validating resolver) that relates
-   to a private key that is no longer used for signing.
-
-
-   The problem with a stale anchors is that they will (from the
-   validating resolvers point of view) prove data to be false even
-   though it is actually correct.  This is because the data is either
-   signed by a new key or is no longer signed and the resolver expects
-   data to be signed by the old (now stale) key.
-
-
-   This situation is arguably worse than not having a trusted key
-   configured for the secure entry point, since with a stale key no
-   lookup is typically possible (presuming that the default
-   configuration of a validating recursive nameserver is to not give out
-   data that is signed but failed to verify.
-
-
-   The danger of making configured trust anchors become stale anchors
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                 [Page 5]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-   may be a reason for zone owners not to roll their keys.  If a
-   resolver is configured with many trust anchors that need manual
-   maintenance it may be easy to not notice a key rollover at a security
-   apex, resulting in a stale anchor.
-
-
-   In Section 3 this memo sets out a lightweight, in-DNS, mechanism to
-   track key rollovers and modify the configured trust anchors
-   accordingly.  The mechanism is stateless and does not need protocol
-   extensions.  The proposed design is that this mechanism is
-   implemented as a "trust updating machine" that is run entirely
-   separate from the validating resolver except that the trust updater
-   will have influence over the trust anchors used by the latter.
-
-
-   In Section 4 we describe a method [Editors note: for now only the
-   frame work and a set of requirements] to install trust anchors.  This
-   method can be used at first configuration or when the trust anchors
-   became stale (typically due to a failure to track several rollover
-   events).
-
-
-   The choice for which domains trust anchors are to be configured is a
-   local policy issue.  So is the choice which trust anchors has
-   prevalence if there are multiple chains of trust to a given piece of
-   DNS data (e.g.  when a parent zone and its child both have trust
-   anchors configured).  Both issues are out of the scope of this
-   document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                 [Page 6]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-3.  Threshold-based Trust Anchor Rollover
-
-
-3.1  The Rollover
-
-
-   When a key pair is replaced all signatures (in DNSSEC these are the
-   RRSIG records) created with the old key will be replaced by new
-   signatures created by the new key.  Access to the new public key is
-   needed to verify these signatures.
-
-
-   Since zone signing keys are in "the middle" of a chain of authority
-   they can be verified using the signature made by a key signing key.
-   Rollover of zone signing keys is therefore transparent to validators
-   and requires no action in the validator end.
-
-
-   But if a key signing key is rolled a resolver can determine its
-   authenticity by either following the authorization chain from the
-   parents DS record, an out-of-DNS authentication mechanism or by
-   relying on other trust anchors known for the zone in which the key is
-   rolled.
-
-
-   The threshold trust anchor rollover mechanism (or trust update),
-   described below, is based on using existing trust anchors to verify a
-   subset of the available signatures.  This is then used as the basis
-   for a decision to accept the new keys as valid trust anchors.
-
-
-   Our example pseudo zone below contains a number of key signing keys
-   numbered 1 through Y and two zone signing keys A and B.  During a key
-   rollover key 2 is replaced by key Y+1.  The zone content changes
-   from:
-
-
-          example.com.  DNSKEY key1
-          example.com.  DNSKEY key2
-          example.com.  DNSKEY key3
-          ...
-          example.com.  DNSKEY keyY
-
-
-          example.com.  DNSKEY keyA
-          example.com.  DNSKEY keyB
-
-
-          example.com.  RRSIG DNSKEY ... (key1)
-          example.com.  RRSIG DNSKEY ... (key2)
-          example.com.  RRSIG DNSKEY ... (key3)
-          ...
-          example.com.  RRSIG DNSKEY ... (keyY)
-          example.com.  RRSIG DNSKEY ... (keyA)
-          example.com.  RRSIG DNSKEY ... (keyB)
-
-
-    to:
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                 [Page 7]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-          example.com.  DNSKEY key1
-          example.com.  DNSKEY key3
-          ...
-          example.com.  DNSKEY keyY
-          example.com.  DNSKEY keyY+1
-
-
-          example.com.  RRSIG DNSKEY ... (key1)
-          example.com.  RRSIG DNSKEY ... (key3)
-          ...
-          example.com.  RRSIG DNSKEY ... (keyY)
-          example.com.  RRSIG DNSKEY ... (keyY+1)
-          example.com.  RRSIG DNSKEY ... (keyA)
-          example.com.  RRSIG DNSKEY ... (keyB)
-
-
-   When the rollover becomes visible to the verifying stub resolver it
-   will be able to verify the RRSIGs associated with key1, key3 ...
-   keyY.  There will be no RRSIG by key2 and the RRSIG by keyY+1 will
-   not be used for validation, since that key is previously unknown and
-   therefore not trusted.
-
-
-   Note that this example is simplified.  Because of operational
-   considerations described in [5] having a period during which the two
-   key signing keys are both available is necessary.
-
-
-3.2  Threshold-based Trust Update
-
-
-   The threshold-based trust update algorithm applies as follows.  If
-   for a particular secure entry point
-   o  if the DNSKEY RRset in the zone has been replaced by a more recent
-      one (as determined by comparing the RRSIG inception dates)
-   and
-   o  if at least M configured trust anchors directly verify the related
-      RRSIGs over the new DNSKEY RRset
-   and
-   o  the number of configured trust anchors that verify the related
-      RRSIGs over the new DNSKEY RRset exceed a locally defined minimum
-      number that should be greater than one
-   then all the trust anchors for the particular secure entry point are
-   replaced by the set of keys from the zones DNSKEY RRset that have the
-   SEP flag set.
-
-
-   The choices for the rollover acceptance policy parameter M is left to
-   the administrator of the resolver.  To be certain that a rollover is
-   accepted up by resolvers using this mechanism zone owners should roll
-   as few SEP keys at a time as possible (preferably just one).  That
-   way they comply to the most strict rollover acceptance policy of
-   M=N-1.
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                 [Page 8]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-   The value of M has an upper bound, limited by the number of of SEP
-   keys a zone owner publishes (i.e.  N).  But there is also a lower
-   bound, since it will not be safe to base the trust in too few
-   signatures.  The corner case is M=1 when any validating RRSIG will be
-   sufficient for a complete replacement of the trust anchors for that
-   secure entry point.  This is not a recommended configuration, since
-   that will allow an attacker to initiate rollover of the trust anchors
-   himself given access to just one compromised key.  Hence M should in
-   be strictly larger than 1 as shown by the third requirement above.
-
-
-   If the rollover acceptance policy is M=1 then the result for the
-   rollover in our example above should be that the local database of
-   trust anchors is updated by removing key "key2" from and adding key
-   "keyY+1" to the key store.
-
-
-3.3  Possible Trust Update States
-
-
-   We define five states for trust anchor configuration at the client
-   side.
-   PRIMING: There are no trust anchors configured.  There may be priming
-      keys available for initial priming of trust anchors.
-   IN-SYNC: The set of trust anchors configured exactly matches the set
-      of SEP keys used by the zone owner to sign the zone.
-   OUT-OF-SYNC: The set of trust anchors is not exactly the same as the
-      set of SEP keys used by the zone owner to sign the zone but there
-      are enough SEP key in use by the zone owner that is also in the
-      trust anchor configuration.
-   UNSYNCABLE: There is not enough overlap between the configured trust
-      anchors and the set of SEP keys used to sign the zone for the new
-      set to be accepted by the validator (i.e.  the number of
-      signatures that verify is not sufficient).
-   STALE: There is no overlap between the configured trust anchors and
-      the set of SEP keys used to sign the zone.  Here validation of
-      data is no longer possible and hence we are in a situation where
-      the trust anchors are stale.
-
-
-   Of these five states only two (IN-SYNC and OUT-OF-SYNC) are part of
-   the automatic trust update mechanism.  The PRIMING state is where a
-   validator is located before acquiring an up-to-date set of trust
-   anchors.  The transition from PRIMING to IN-SYNC is manual (see
-   Section 4 below).
-
-
-   Example: assume a secure entry point with four SEP keys and a
-   validator with the policy that it will accept any update to the set
-   of trust anchors as long as no more than two signatures fail to
-   validate (i.e.  M >= N-2) and at least two signature does validate
-   (i.e.  M >= 2).  In this case the rollover of a single key will move
-   the validator from IN-SYNC to OUT-OF-SYNC.  When the trust update
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                 [Page 9]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-   state machine updates the trust anchors it returns to state IN-SYNC.
-
-
-   If if for some reason it fails to update the trust anchors then the
-   next rollover (of a different key) will move the validator from
-   OUT-OF-SYNC to OUT-OF-SYNC (again), since there are still two keys
-   that are configured as trust anchors and that is sufficient to accpt
-   an automatic update of the trust anchors.
-
-
-   The UNSYNCABLE state is where a validator is located if it for some
-   reason fails to incorporate enough updates to the trust anchors to be
-   able to accept new updates according to its local policy.  In this
-   example (i.e.  with the policy specified above) this will either be
-   because M < N-2 or M < 2, which does not suffice to authenticate a
-   successful update of trust anchors.
-
-
-   Continuing with the previous example where two of the four SEP keys
-   have already rolled, but the validator has failed to update the set
-   of trust anchors.  When the third key rolls over there will only be
-   one trust anchor left that can do successful validation.  This is not
-   sufficient to enable automatic update of the trust anchors, hence the
-   new state is UNSYNCABLE.  Note, however, that the remaining
-   up-to-date trust anchor is still enough to do successful validation
-   so the validator is still "working" from a DNSSEC point of view.
-
-
-   The STALE state, finally, is where a validator ends up when it has
-   zero remaining current trust anchors.  This is a dangerous state,
-   since the stale trust anchors will cause all validation to fail.  The
-   escape is to remove the stale trust anchors and thereby revert to the
-   PRIMING state.
-
-
-3.4  Implementation notes
-
-
-   The DNSSEC protocol specification ordains that a DNSKEY to which a DS
-   record points should be self-signed.  Since the keys that serve as
-   trust anchors and the keys that are pointed to by DS records serve
-   the same purpose, they are both secure entry points, we RECOMMEND
-   that zone owners who want to facilitate the automated rollover scheme
-   documented herein self-sign DNSKEYs with the SEP bit set and that
-   implementation check that DNSKEYs with the SEP bit set are
-   self-signed.
-
-
-   In order to maintain a uniform way of determining that a keyset in
-   the zone has been replaced by a more recent set the automatic trust
-   update machine SHOULD only accept new DNSKEY RRsets if the
-   accompanying RRSIGs show a more recent inception date than the
-   present set of trust anchors.  This is also needed as a safe guard
-   against possible replay attacks where old updates are replayed
-   "backwards" (i.e.  one change at a time, but going in the wrong
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                [Page 10]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-   direction, thereby luring the validator into the UNSYNCABLE and
-   finally STALE states).
-
-
-   In order to be resilient against failures the implementation should
-   collect the DNSKEY RRsets from (other) authoritative servers if
-   verification of the self signatures fails.
-
-
-   The threshold-based trust update mechanism SHOULD only be applied to
-   algorithms, as represented in the algorithm field in the DNSKEY/RRSIG
-   [3], that the resolver is aware of.  In other words the SEP keys of
-   unknown algorithms should not be used when counting the number of
-   available signatures (the N constant) and the SEP keys of unknown
-   algorithm should not be entered as trust anchors.
-
-
-   When in state UNSYNCABLE or STALE manual intervention will be needed
-   to return to the IN-SYNC state.  These states should be flagged.  The
-   most appropriate action is human audit possibly followed by
-   re-priming (Section 4) the keyset (i.e.  manual transfer to the
-   PRIMING state through removal of the configured trust anchors).
-
-
-   An implementation should regularly probe the the authoritative
-   nameservers for new keys.  Since there is no mechanism to publish
-   rollover frequencies this document RECOMMENDS zone owners not to roll
-   their key signing keys more often than once per month and resolver
-   administrators to probe for key rollsovers (and apply the threshold
-   criterion for acceptance of trust update) not less often than once
-   per month.  If the rollover frequency is higher than the probing
-   frequency then trust anchors may become stale.  The exact relation
-   between the frequencies depends on the number of SEP keys rolled by
-   the zone owner and the value M configured by the resolver
-   administrator.
-
-
-   In all the cases below a transaction where the threshold criterion is
-   not satisfied should be considered bad (i.e.  possibly spoofed or
-   otherwise corrupted data).  The most appropriate action is human
-   audit.
-
-
-   There is one case where a "bad" state may be escaped from in an
-   automated fashion.  This is when entering the STALE state where all
-   DNSSEC validation starts to fail.  If this happens it is concievable
-   that it is better to completely discard the stale trust anchors
-   (thereby reverting to the PRIMING state where validation is not
-   possible).  A local policy that automates removal of stale trust
-   anchors is therefore suggested.
-
-
-3.5  Possible transactions
-
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                [Page 11]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-3.5.1  Single DNSKEY replaced
-
-
-   This is probably the most typical transaction on the zone owners
-   part.  The result should be that if the threshold criterion is
-   satisfied then the key store is updated by removal of the old trust
-   anchor and addition of the new key as a new trust anchor.  Note that
-   if the DNSKEY RRset contains exactly M keys replacement of keys is
-   not possible, i.e.  for automatic rollover to work M must be stricly
-   less than N.
-
-
-3.5.2  Addition of a new DNSKEY (no removal)
-
-
-   If the threshold criterion is satisfied then the new key is added as
-   a configured trust anchor.  Not more than N-M keys can be added at
-   once, since otherwise the algorithm will fail.
-
-
-3.5.3  Removal of old DNSKEY (no addition)
-
-
-   If the threshold criterion is satisfied then the old key is removed
-   from being a configured trust anchor.  Note that it is not possible
-   to reduce the size of the DNSKEY RRset to a size smaller than the
-   minimum required value for M.
-
-
-3.5.4  Multiple DNSKEYs replaced
-
-
-   Arguably it is not a good idea for the zone administrator to replace
-   several keys at the same time, but from the resolver point of view
-   this is exactly what will happen if the validating resolver for some
-   reason failed to notice a previous rollover event.
-
-
-   Not more than N-M keys can be replaced at one time or the threshold
-   criterion will not be satisfied.  Or, expressed another way: as long
-   as the number of changed keys is less than or equal to N-M the
-   validator is in state OUT-OF-SYNC.  When the number of changed keys
-   becomes greater than N-M the state changes to UNSYNCABLE and manual
-   action is needed.
-
-
-3.6  Removal of trust anchors for a trust point
-
-
-   If the parent of a secure entry point gets signed and it's trusted
-   keys get configured in the key store of the validating resolver then
-   the configured trust anchors for the child should be removed entirely
-   unless explicitly configured (in the utility configuration) to be an
-   exception.
-
-
-   The reason for such a configuration would be that the resolver has a
-   local policy that requires maintenance of trusted keys further down
-   the tree hierarchy than strictly needed from the point of view.
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                [Page 12]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-   The default action when the parent zone changes from unsigned to
-   signed should be to remove the configured trust anchors for the
-   child.  This form of "garbage collect" will ensure that the automatic
-   rollover machinery scales as DNSSEC deployment progresses.
-
-
-3.7  No need for resolver-side overlap of old and new keys
-
-
-   It is worth pointing out that there is no need for the resolver to
-   keep state about old keys versus new keys, beyond the requirement of
-   tracking signature inception time for the covering RRSIGs as
-   described in Section 3.4.
-
-
-   From the resolver point of view there are only trusted and not
-   trusted keys.  The reason is that the zone owner needs to do proper
-   maintenance of RRSIGs regardless of the resolver rollover mechanism
-   and hence must ensure that no key rolled out out the DNSKEY set until
-   there cannot be any RRSIGs created by this key still legally cached.
-
-
-   Hence the rollover mechanism is entirely stateless with regard to the
-   keys involved: as soon as the resolver (or in this case the rollover
-   tracking utility) detects a change in the DNSKEY RRset (i.e.  it is
-   now in the state OUT-OF-SYNC) with a sufficient number of matching
-   RRSIGs the configured trust anchors are immediately updated (and
-   thereby the machine return to state IN-SYNC).  I.e.  the rollover
-   machine changes states (mostly oscillating between IN-SYNC and
-   OUT-OF-SYNC), but the status of the DNSSEC keys is stateless.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                [Page 13]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-4.  Bootstrapping automatic rollovers
-
-
-   It is expected that with the ability to automatically roll trust
-   anchors at trust points will follow a diminished unwillingness to
-   roll these keys, since the risks associated with stale keys are
-   minimized.
-
-
-   The problem of "priming" the trust anchors, or bringing them into
-   sync (which could happen if a resolver is off line for a long period
-   in which a set of SEP keys in a zone 'evolve' away from its trust
-   anchor configuration) remains.
-
-
-   For (re)priming we can rely on out of band technology and we propose
-   the following framework.
-
-
-4.1  Priming Keys
-
-
-   If all the trust anchors roll somewhat frequently (on the order of
-   months or at most about a year) then it will not be possible to
-   design a device, or a software distribution that includes trust
-   anchors, that after being manufactured is put on a shelf for several
-   key rollover periods before being brought into use (since no trust
-   anchors that were known at the time of manufacture remain active).
-
-
-   To alleviate this we propose the concept of "priming keys".  Priming
-   keys are ordinary DNSSEC Key Signing Keys with the characteristic
-   that
-   o  The private part of a priming key signs the DNSKEY RRset at the
-      security apex, i.e.  at least one RRSIG DNSKEY is created by a
-      priming key rather than by an "ordinary" trust anchor
-   o  the public parts of priming keys are not included in the DNSKEY
-      RRset.  Instead the public parts of priming keys are only
-      available out-of-band.
-   o  The public parts of the priming keys have a validity period.
-      Within this period they can be used to obtain trust anchors.
-   o  The priming key pairs are long lived (relative to the key rollover
-      period.)
-
-
-4.1.1  Bootstrapping trust anchors using a priming key
-
-
-   To install the trust anchors for a particular security apex an
-   administrator of a validating resolver will need to:
-   o  query for the DNSKEY RRset of the zone at the security apex;
-   o  verify the self signatures of all DNSKEYs in the RRset;
-   o  verify the signature of the RRSIG made with a priming key --
-      verification using one of the public priming keys that is valid at
-      that moment is sufficient;
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                [Page 14]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-   o  create the trust anchors by extracting the DNSKEY RRs with the SEP
-      flag set.
-   The SEP keys with algorithms unknown to the validating resolver
-   SHOULD be ignored during the creation of the trust anchors.
-
-
-4.1.2  Distribution of priming keys
-
-
-   The public parts of the priming keys SHOULD be distributed
-   exclusively through out-of-DNS mechanisms.  The requirements for a
-   distribution mechanism are:
-   o  it can carry the "validity" period for the priming keys;
-   o  it can carry the self-signature of the priming keys;
-   o  and it allows for verification using trust relations outside the
-      DNS.
-   A distribution mechanism would benefit from:
-   o  the availability of revocation lists;
-   o  the ability of carrying zone owners policy information such as
-      recommended values for "M" and "N" and a rollover frequency;
-   o  and the technology on which is based is readily available.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                [Page 15]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-5.  The Threshold Rollover Mechanism vs Priming
-
-
-   There is overlap between the threshold-based trust updater and the
-   Priming method.  One could exclusively use the Priming method for
-   maintaining the trust anchors.  However the priming method probably
-   relies on "non-DNS' technology and may therefore not be available for
-   all devices that have a resolver.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                [Page 16]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-6.  Security Considerations
-
-
-6.1  Threshold-based Trust Update Security Considerations
-
-
-   A clear issue for resolvers will be how to ensure that they track all
-   rollover events for the zones they have configure trust anchors for.
-   Because of temporary outages validating resolvers may have missed a
-   rollover of a KSK.  The parameters that determine the robustness
-   against failures are: the length of the period between rollovers
-   during which the KSK set is stable and validating resolvers can
-   actually notice the change; the number of available KSKs (i.e.  N)
-   and the number of signatures that may fail to validate (i.e.  N-M).
-
-
-   With a large N (i.e.  many KSKs) and a small value of M this
-   operation becomes more robust since losing one key, for whatever
-   reason, will not be crucial.  Unfortunately the choice for the number
-   of KSKs is a local policy issue for the zone owner while the choice
-   for the parameter M is a local policy issue for the resolver
-   administrator.
-
-
-   Higher values of M increase the resilience against attacks somewhat;
-   more signatures need to verify for a rollover to be approved.  On the
-   other hand the number of rollover events that may pass unnoticed
-   before the resolver reaches the UNSYNCABLE state goes down.
-
-
-   The threshold-based trust update intentionally does not provide a
-   revocation mechanism.  In the case that a sufficient number of
-   private keys of a zone owner are simultaneously compromised the the
-   attacker may use these private keys to roll the trust anchors of (a
-   subset of) the resolvers.  This is obviously a bad situation but it
-   is not different from most other public keys systems.
-
-
-   However, it is important to point out that since any reasonable trust
-   anchor rollover policy (in validating resolvers) will require more
-   than one RRSIG to validate this proposal does provide security
-   concious zone administrators with the option of not storing the
-   individual private keys in the same location and thereby decreasing
-   the likelihood of simultaneous compromise.
-
-
-6.2  Priming Key Security Considerations
-
-
-   Since priming keys are not included in the DNSKEY RR set they are
-   less sensitive to packet size constraints and can be chosen
-   relatively large.  The private parts are only needed to sign the
-   DNSKEY RR set during the validity period of the particular priming
-   key pair.  Note that the private part of the priming key is used each
-   time when a DNSKEY RRset has to be resigned.  In practice there is
-   therefore little difference between the usage pattern of the private
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                [Page 17]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-   part of key signing keys and priming keys.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                [Page 18]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-7.  IANA Considerations
-
-
-   NONE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                [Page 19]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-8.  References
-
-
-8.1  Normative References
-
-
-   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-
-   [2]  Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY
-        (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag",
-        RFC 3757, May 2004.
-
-
-   [3]  Arends, R., "Resource Records for the DNS Security Extensions",
-        draft-ietf-dnsext-dnssec-records-10 (work in progress),
-        September 2004.
-
-
-8.2  Informative References
-
-
-   [4]  Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose,
-        "DNS Security Introduction and Requirements",
-        draft-ietf-dnsext-dnssec-intro-12 (work in progress), September
-        2004.
-
-
-   [5]  Kolkman, O., "DNSSEC Operational Practices",
-        draft-ietf-dnsop-dnssec-operational-practices-01 (work in
-        progress), May 2004.
-
-
-   [6]  Housley, R., Ford, W., Polk, T. and D. Solo, "Internet X.509
-        Public Key Infrastructure Certificate and CRL Profile", RFC
-        2459, January 1999.
-
-
-
-Authors' Addresses
-
-
-   Johan Ihren
-   Autonomica AB
-   Bellmansgatan 30
-   Stockholm  SE-118 47
-   Sweden
-
-
-   EMail: johani@autonomica.se
-
-
-
-
-
-
-
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                [Page 20]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-   Olaf M. Kolkman
-   RIPE NCC
-   Singel 256
-   Amsterdam  1016 AB
-   NL
-
-
-   Phone: +31 20 535 4444
-   EMail: olaf@ripe.net
-   URI:   http://www.ripe.net/
-
-
-
-   Bill Manning
-   EP.net
-   Marina del Rey, CA  90295
-   USA
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                [Page 21]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-Appendix A.  Acknowledgments
-
-
-   The present design for in-band automatic rollovers of DNSSEC trust
-   anchors is the result of many conversations and it is no longer
-   possible to remember exactly who contributed what.
-
-
-   In addition we've also had appreciated help from (in no particular
-   order) Paul Vixie, Sam Weiler, Suzanne Woolf, Steve Crocker, Matt
-   Larson and Mark Kosters.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                [Page 22]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-Appendix B.  Document History
-
-
-   This appendix will be removed if and when the document is submitted
-   to the RFC editor.
-
-
-   The version you are reading is tagged as $Revision: 1.1.230.1 $.
-
-
-   Text between square brackets, other than references, are editorial
-   comments and will be removed.
-
-
-B.1  prior to version 00
-
-
-   This draft was initially published as a personal submission under the
-   name draft-kolkman-dnsext-dnssec-in-band-rollover-00.txt.
-
-
-   Kolkman documented the ideas provided by Ihren and Manning.  In the
-   process of documenting (and prototyping) Kolkman changed some of the
-   details of the M-N algorithms working.  Ihren did not have a chance
-   to review the draft before Kolkman posted;
-
-
-   Kolkman takes responsibilities for omissions, fuzzy definitions and
-   mistakes.
-
-
-B.2  version 00
-   o  The name of the draft was changed as a result of the draft being
-      adopted as a working group document.
-   o  A small section on the concept of stale trust anchors was added.
-   o  The different possible states are more clearly defined, including
-      examples of transitions between states.
-   o  The terminology is changed throughout the document.  The old term
-      "M-N" is replaced by "threshold" (more or less).  Also the
-      interpretation of the constants M and N is significantly
-      simplified to bring the usage more in line with "standard"
-      threshold terminlogy.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                [Page 23]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-Intellectual Property Statement
-
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-
-Disclaimer of Validity
-
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-Copyright Statement
-
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-
-Acknowledgment
-
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                [Page 24] 
\ No newline at end of file
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-trustupdate-timers-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-trustupdate-timers-02.txt
deleted file mode 100644
index 7cb9063..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-trustupdate-timers-02.txt
+++ /dev/null
@@ -1,730 +0,0 @@
-
-
-
-
-Network Working Group                                         M. StJohns
-Internet-Draft                                             Nominum, Inc.
-Expires: July 14, 2006                                  January 10, 2006
-
-
-               Automated Updates of DNSSEC Trust Anchors
-                draft-ietf-dnsext-trustupdate-timers-02
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on July 14, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document describes a means for automated, authenticated and
-   authorized updating of DNSSEC "trust anchors".  The method provides
-   protection against single key compromise of a key in the trust point
-   key set.  Based on the trust established by the presence of a current
-   anchor, other anchors may be added at the same place in the
-   hierarchy, and, ultimately, supplant the existing anchor.
-
-   This mechanism, if adopted, will require changes to resolver
-   management behavior (but not resolver resolution behavior), and the
-
-
-
-StJohns                   Expires July 14, 2006                 [Page 1]
-
-Internet-Draft             trustanchor-update               January 2006
-
-
-   addition of a single flag bit to the DNSKEY record.
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-     1.1.  Compliance Nomenclature  . . . . . . . . . . . . . . . . .  3
-     1.2.  Changes since -00  . . . . . . . . . . . . . . . . . . . .  3
-   2.  Theory of Operation  . . . . . . . . . . . . . . . . . . . . .  4
-     2.1.  Revocation . . . . . . . . . . . . . . . . . . . . . . . .  4
-     2.2.  Add Hold-Down  . . . . . . . . . . . . . . . . . . . . . .  5
-     2.3.  Remove Hold-down . . . . . . . . . . . . . . . . . . . . .  5
-     2.4.  Active Refresh . . . . . . . . . . . . . . . . . . . . . .  6
-     2.5.  Resolver Parameters  . . . . . . . . . . . . . . . . . . .  6
-       2.5.1.  Add Hold-Down Time . . . . . . . . . . . . . . . . . .  6
-       2.5.2.  Remove Hold-Down Time  . . . . . . . . . . . . . . . .  6
-       2.5.3.  Minimum Trust Anchors per Trust Point  . . . . . . . .  6
-   3.  Changes to DNSKEY RDATA Wire Format  . . . . . . . . . . . . .  6
-   4.  State Table  . . . . . . . . . . . . . . . . . . . . . . . . .  7
-     4.1.  Events . . . . . . . . . . . . . . . . . . . . . . . . . .  7
-     4.2.  States . . . . . . . . . . . . . . . . . . . . . . . . . .  8
-     4.3.  Trust Point Deletion . . . . . . . . . . . . . . . . . . .  8
-   5.  Scenarios  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
-     5.1.  Adding A Trust Anchor  . . . . . . . . . . . . . . . . . .  9
-     5.2.  Deleting a Trust Anchor  . . . . . . . . . . . . . . . . .  9
-     5.3.  Key Roll-Over  . . . . . . . . . . . . . . . . . . . . . .  9
-     5.4.  Active Key Compromised . . . . . . . . . . . . . . . . . .  9
-     5.5.  Stand-by Key Compromised . . . . . . . . . . . . . . . . . 10
-   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
-   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
-     7.1.  Key Ownership vs Acceptance Policy . . . . . . . . . . . . 10
-     7.2.  Multiple Key Compromise  . . . . . . . . . . . . . . . . . 10
-     7.3.  Dynamic Updates  . . . . . . . . . . . . . . . . . . . . . 11
-   8.  Normative References . . . . . . . . . . . . . . . . . . . . . 11
-   Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .
-   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
-   Intellectual Property and Copyright Statements . . . . . . . . . . 13
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-StJohns                   Expires July 14, 2006                 [Page 2]
-
-Internet-Draft             trustanchor-update               January 2006
-
-
-1.  Introduction
-
-   As part of the reality of fielding DNSSEC (Domain Name System
-   Security Extensions) [RFC2535] [RFC4033][RFC4034][RFC4035], the
-   community has come to the realization that there will not be one
-   signed name space, but rather islands of signed name space each
-   originating from specific points (i.e. 'trust points') in the DNS
-   tree.  Each of those islands will be identified by the trust point
-   name, and validated by at least one associated public key.  For the
-   purpose of this document we'll call the association of that name and
-   a particular key a 'trust anchor'.  A particular trust point can have
-   more than one key designated as a trust anchor.
-
-   For a DNSSEC-aware resolver to validate information in a DNSSEC
-   protected branch of the hierarchy, it must have knowledge of a trust
-   anchor applicable to that branch.  It may also have more than one
-   trust anchor for any given trust point.  Under current rules, a chain
-   of trust for DNSSEC-protected data that chains its way back to ANY
-   known trust anchor is considered 'secure'.
-
-   Because of the probable balkanization of the DNSSEC tree due to
-   signing voids at key locations, a resolver may need to know literally
-   thousands of trust anchors to perform its duties. (e.g.  Consider an
-   unsigned ".COM".)  Requiring the owner of the resolver to manually
-   manage this many relationships is problematic.  It's even more
-   problematic when considering the eventual requirement for key
-   replacement/update for a given trust anchor.  The mechanism described
-   herein won't help with the initial configuration of the trust anchors
-   in the resolvers, but should make trust point key replacement/
-   rollover more viable.
-
-   As mentioned above, this document describes a mechanism whereby a
-   resolver can update the trust anchors for a given trust point, mainly
-   without human intervention at the resolver.  There are some corner
-   cases discussed (e.g. multiple key compromise) that may require
-   manual intervention, but they should be few and far between.  This
-   document DOES NOT discuss the general problem of the initial
-   configuration of trust anchors for the resolver.
-
-1.1.  Compliance Nomenclature
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in BCP 14, [RFC2119].
-
-1.2.  Changes since -00
-
-   Added the concept of timer triggered resolver queries to refresh the
-
-
-
-StJohns                   Expires July 14, 2006                 [Page 3]
-
-Internet-Draft             trustanchor-update               January 2006
-
-
-   resolvers view of the trust anchor key RRSet.
-
-   Re-submitted expired draft as -01.  Updated DNSSEC RFC References.
-
-   Draft -02.  Added the IANA Considerations section.  Added text to
-   describe what happens if all trust anchors at a trust point are
-   deleted.
-
-
-2.  Theory of Operation
-
-   The general concept of this mechanism is that existing trust anchors
-   can be used to authenticate new trust anchors at the same point in
-   the DNS hierarchy.  When a new SEP key is added to a trust point
-   DNSKEY RRSet, and when that RRSet is validated by an existing trust
-   anchor, then the new key can be added to the set of trust anchors.
-
-   There are some issues with this approach which need to be mitigated.
-   For example, a compromise of one of the existing keys could allow an
-   attacker to add their own 'valid' data.  This implies a need for a
-   method to revoke an existing key regardless of whether or not that
-   key is compromised.  As another example assuming a single key
-   compromise, an attacker could add a new key and revoke all the other
-   old keys.
-
-2.1.  Revocation
-
-   Assume two trust anchor keys A and B. Assume that B has been
-   compromised.  Without a specific revocation bit, B could invalidate A
-   simply by sending out a signed trust point key set which didn't
-   contain A. To fix this, we add a mechanism which requires knowledge
-   of the private key of a DNSKEY to revoke that DNSKEY.
-
-   A key is considered revoked when the resolver sees the key in a self-
-   signed RRSet and the key has the REVOKE bit (see Section 6 below) set
-   to '1'.  Once the resolver sees the REVOKE bit, it MUST NOT use this
-   key as a trust anchor or for any other purposes except validating the
-   RRSIG over the DNSKEY RRSet specifically for the purpose of
-   validating the revocation.  Unlike the 'Add' operation below,
-   revocation is immediate and permanent upon receipt of a valid
-   revocation at the resolver.
-
-   N.B. A DNSKEY with the REVOKE bit set has a different fingerprint
-   than one without the bit set.  This affects the matching of a DNSKEY
-   to DS records in the parent, or the fingerprint stored at a resolver
-   used to configure a trust point. [msj3]
-
-   In the given example, the attacker could revoke B because it has
-
-
-
-StJohns                   Expires July 14, 2006                 [Page 4]
-
-Internet-Draft             trustanchor-update               January 2006
-
-
-   knowledge of B's private key, but could not revoke A.
-
-2.2.  Add Hold-Down
-
-   Assume two trust point keys A and B. Assume that B has been
-   compromised.  An attacker could generate and add a new trust anchor
-   key - C (by adding C to the DNSKEY RRSet and signing it with B), and
-   then invalidate the compromised key.  This would result in the both
-   the attacker and owner being able to sign data in the zone and have
-   it accepted as valid by resolvers.
-
-   To mitigate, but not completely solve, this problem, we add a hold-
-   down time to the addition of the trust anchor.  When the resolver
-   sees a new SEP key in a validated trust point DNSKEY RRSet, the
-   resolver starts an acceptance timer, and remembers all the keys that
-   validated the RRSet.  If the resolver ever sees the DNSKEY RRSet
-   without the new key but validly signed, it stops the acceptance
-   process and resets the acceptance timer.  If all of the keys which
-   were originally used to validate this key are revoked prior to the
-   timer expiring, the resolver stops the acceptance process and resets
-   the timer.
-
-   Once the timer expires, the new key will be added as a trust anchor
-   the next time the validated RRSet with the new key is seen at the
-   resolver.  The resolver MUST NOT treat the new key as a trust anchor
-   until the hold down time expires AND it has retrieved and validated a
-   DNSKEY RRSet after the hold down time which contains the new key.
-
-   N.B.: Once the resolver has accepted a key as a trust anchor, the key
-   MUST be considered a valid trust anchor by that resolver until
-   explictly revoked as described above.
-
-   In the given example, the zone owner can recover from a compromise by
-   revoking B and adding a new key D and signing the DNSKEY RRSet with
-   both A and B.
-
-   The reason this does not completely solve the problem has to do with
-   the distributed nature of DNS.  The resolver only knows what it sees.
-   A determined attacker who holds one compromised key could keep a
-   single resolver from realizing that key had been compromised by
-   intercepting 'real' data from the originating zone and substituting
-   their own (e.g. using the example, signed only by B).  This is no
-   worse than the current situation assuming a compromised key.
-
-2.3.  Remove Hold-down
-
-   A new key which has been seen by the resolver, but hasn't reached
-   it's add hold-down time, MAY be removed from the DNSKEY RRSet by the
-
-
-
-StJohns                   Expires July 14, 2006                 [Page 5]
-
-Internet-Draft             trustanchor-update               January 2006
-
-
-   zone owner.  If the resolver sees a validated DNSKEY RRSet without
-   this key, it waits for the remove hold-down time and then, if the key
-   hasn't reappeared, SHOULD discard any information about the key.
-
-2.4.  Active Refresh
-
-   A resolver which has been configured for automatic update of keys
-   from a particular trust point MUST query that trust point (e.g. do a
-   lookup for the DNSKEY RRSet and related RRSIG records) no less often
-   than the lesser of 15 days or half the original TTL for the DNSKEY
-   RRSet or half the RRSIG expiration interval.  The expiration interval
-   is the amount of time from when the RRSIG was last retrieved until
-   the expiration time in the RRSIG.
-
-   If the query fails, the resolver MUST repeat the query until
-   satisfied no more often than once an hour and no less often than the
-   lesser of 1 day or 10% of the original TTL or 10% of the original
-   expiration interval.
-
-2.5.  Resolver Parameters
-
-2.5.1.  Add Hold-Down Time
-
-   The add hold-down time is 30 days or the expiration time of the TTL
-   of the first trust point DNSKEY RRSet which contained the key,
-   whichever is greater.  This ensures that at least two validated
-   DNSKEY RRSets which contain the new key MUST be seen by the resolver
-   prior to the key's acceptance.
-
-2.5.2.  Remove Hold-Down Time
-
-   The remove hold-down time is 30 days.
-
-2.5.3.  Minimum Trust Anchors per Trust Point
-
-   A compliant resolver MUST be able to manage at least five SEP keys
-   per trust point.
-
-
-3.  Changes to DNSKEY RDATA Wire Format
-
-   Bit n [msj2] of the DNSKEY Flags field is designated as the 'REVOKE'
-   flag.  If this bit is set to '1', AND the resolver sees an
-   RRSIG(DNSKEY) signed by the associated key, then the resolver MUST
-   consider this key permanently invalid for all purposes except for
-   validing the revocation.
-
-
-
-
-
-StJohns                   Expires July 14, 2006                 [Page 6]
-
-Internet-Draft             trustanchor-update               January 2006
-
-
-4.  State Table
-
-   The most important thing to understand is the resolver's view of any
-   key at a trust point.  The following state table describes that view
-   at various points in the key's lifetime.  The table is a normative
-   part of this specification.  The initial state of the key is 'Start'.
-   The resolver's view of the state of the key changes as various events
-   occur.
-
-   [msj1] This is the state of a trust point key as seen from the
-   resolver.  The column on the left indicates the current state.  The
-   header at the top shows the next state.  The intersection of the two
-   shows the event that will cause the state to transition from the
-   current state to the next.
-
-                             NEXT STATE
-           --------------------------------------------------
-    FROM   |Start  |AddPend |Valid  |Missing|Revoked|Removed|
-   ----------------------------------------------------------
-   Start   |       |NewKey  |       |       |       |       |
-   ----------------------------------------------------------
-   AddPend |KeyRem |        |AddTime|       |       |
-   ----------------------------------------------------------
-   Valid   |       |        |       |KeyRem |Revbit |       |
-   ----------------------------------------------------------
-   Missing |       |        |KeyPres|       |Revbit |       |
-   ----------------------------------------------------------
-   Revoked |       |        |       |       |       |RemTime|
-   ----------------------------------------------------------
-   Removed |       |        |       |       |       |       |
-   ----------------------------------------------------------
-
-4.1.  Events
-   NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key.
-      That key will become a new trust anchor for the named trust point
-      after its been present in the RRSet for at least 'add time'.
-   KeyPres The key has returned to the valid DNSKEY RRSet.
-   KeyRem The resolver sees a valid DNSKEY RRSet that does not contain
-      this key.
-   AddTime The key has been in every valid DNSKEY RRSet seen for at
-      least the 'add time'.
-   RemTime A revoked key has been missing from the trust point DNSKEY
-      RRSet for sufficient time to be removed from the trust set.
-   RevBit The key has appeared in the trust anchor DNSKEY RRSet with its
-      "REVOKED" bit set, and there is an RRSig over the DNSKEY RRSet
-      signed by this key.
-
-
-
-
-
-StJohns                   Expires July 14, 2006                 [Page 7]
-
-Internet-Draft             trustanchor-update               January 2006
-
-
-4.2.  States
-   Start The key doesn't yet exist as a trust anchor at the resolver.
-      It may or may not exist at the zone server, but hasn't yet been
-      seen at the resolver.
-   AddPend The key has been seen at the resolver, has its 'SEP' bit set,
-      and has been included in a validated DNSKEY RRSet.  There is a
-      hold-down time for the key before it can be used as a trust
-      anchor.
-   Valid The key has been seen at the resolver and has been included in
-      all validated DNSKEY RRSets from the time it was first seen up
-      through the hold-down time.  It is now valid for verifying RRSets
-      that arrive after the hold down time.  Clarification: The DNSKEY
-      RRSet does not need to be continuously present at the resolver
-      (e.g. its TTL might expire).  If the RRSet is seen, and is
-      validated (i.e. verifies against an existing trust anchor), this
-      key MUST be in the RRSet otherwise a 'KeyRem' event is triggered.
-   Missing This is an abnormal state.  The key remains as a valid trust
-      point key, but was not seen at the resolver in the last validated
-      DNSKEY RRSet.  This is an abnormal state because the zone operator
-      should be using the REVOKE bit prior to removal.  [Discussion
-      item: Should a missing key be considered revoked after some period
-      of time?]
-   Revoked This is the state a key moves to once the resolver sees an
-      RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet contains
-      this key with its REVOKE bit set to '1'.  Once in this state, this
-      key MUST permanently be considered invalid as a trust anchor.
-   Removed After a fairly long hold-down time, information about this
-      key may be purged from the resolver.  A key in the removed state
-      MUST NOT be considered a valid trust anchor.
-
-4.3.  Trust Point Deletion
-
-   A trust point which has all of its trust anchors revoked is
-   considered deleted and is treated as if the trust point was never
-   configured.  If there are no superior trust points, data at and below
-   the deleted trust point are considered insecure.  If there there ARE
-   superior trust points, data at and below the deleted trust point are
-   evaluated with respect to the superior trust point.
-
-
-5.  Scenarios
-
-   The suggested model for operation is to have one active key and one
-   stand-by key at each trust point.  The active key will be used to
-   sign the DNSKEY RRSet.  The stand-by key will not normally sign this
-   RRSet, but the resolver will accept it as a trust anchor if/when it
-   sees the signature on the trust point DNSKEY RRSet.
-
-
-
-
-StJohns                   Expires July 14, 2006                 [Page 8]
-
-Internet-Draft             trustanchor-update               January 2006
-
-
-   Since the stand-by key is not in active signing use, the associated
-   private key may (and SHOULD) be provided with additional protections
-   not normally available to a key that must be used frequently.  E.g.
-   locked in a safe, split among many parties, etc.  Notionally, the
-   stand-by key should be less subject to compromise than an active key,
-   but that will be dependent on operational concerns not addressed
-   here.
-
-5.1.  Adding A Trust Anchor
-
-   Assume an existing trust anchor key 'A'.
-   1.  Generate a new key pair.
-   2.  Create a DNSKEY record from the key pair and set the SEP and Zone
-       Key bits.
-   3.  Add the DNSKEY to the RRSet.
-   4.  Sign the DNSKEY RRSet ONLY with the existing trust anchor key -
-       'A'.
-   5.  Wait a while.
-
-5.2.  Deleting a Trust Anchor
-
-   Assume existing trust anchors 'A' and 'B' and that you want to revoke
-   and delete 'A'.
-   1.  Set the revolcation bit on key 'A'.
-   2.  Sign the DNSKEY RRSet with both 'A' and 'B'.
-   'A' is now revoked.  The operator SHOULD include the revoked 'A' in
-   the RRSet for at least the remove hold-down time, but then may remove
-   it from the DNSKEY RRSet.
-
-5.3.  Key Roll-Over
-
-   Assume existing keys A and B. 'A' is actively in use (i.e. has been
-   signing the DNSKEY RRSet.)  'B' was the stand-by key. (i.e. has been
-   in the DNSKEY RRSet and is a valid trust anchor, but wasn't being
-   used to sign the RRSet.)
-   1.  Generate a new key pair 'C'.
-   2.  Add 'C' to the DNSKEY RRSet.
-   3.  Set the revocation bit on key 'A'.
-   4.  Sign the RRSet with 'A' and 'B'.
-   'A' is now revoked, 'B' is now the active key, and 'C' will be the
-   stand-by key once the hold-down expires.  The operator SHOULD include
-   the revoked 'A' in the RRSet for at least the remove hold-down time,
-   but may then remove it from the DNSKEY RRSet.
-
-5.4.  Active Key Compromised
-
-   This is the same as the mechanism for Key Roll-Over (Section 5.3)
-   above assuming 'A' is the active key.
-
-
-
-StJohns                   Expires July 14, 2006                 [Page 9]
-
-Internet-Draft             trustanchor-update               January 2006
-
-
-5.5.  Stand-by Key Compromised
-
-   Using the same assumptions and naming conventions as Key Roll-Over
-   (Section 5.3) above:
-   1.  Generate a new key pair 'C'.
-   2.  Add 'C' to the DNSKEY RRSet.
-   3.  Set the revocation bit on key 'B'.
-   4.  Sign the RRSet with 'A' and 'B'.
-   'B' is now revoked, 'A' remains the active key, and 'C' will be the
-   stand-by key once the hold-down expires.  'B' SHOULD continue to be
-   included in the RRSet for the remove hold-down time.
-
-
-6.  IANA Considerations
-
-   The IANA will need to assign a bit in the DNSKEY flags field (see
-   section 4.3 of [RFC3755]) for the REVOKE bit.  There are no other
-   IANA actions required.
-
-
-7.  Security Considerations
-
-7.1.  Key Ownership vs Acceptance Policy
-
-   The reader should note that, while the zone owner is responsible
-   creating and distributing keys, it's wholly the decision of the
-   resolver owner as to whether to accept such keys for the
-   authentication of the zone information.  This implies the decision
-   update trust anchor keys based on trust for a current trust anchor
-   key is also the resolver owner's decision.
-
-   The resolver owner (and resolver implementers) MAY choose to permit
-   or prevent key status updates based on this mechanism for specific
-   trust points.  If they choose to prevent the automated updates, they
-   will need to establish a mechanism for manual or other out-of-band
-   updates outside the scope of this document.
-
-7.2.  Multiple Key Compromise
-
-   This scheme permits recovery as long as at least one valid trust
-   anchor key remains uncompromised.  E.g. if there are three keys, you
-   can recover if two of them are compromised.  The zone owner should
-   determine their own level of comfort with respect to the number of
-   active valid trust anchors in a zone and should be prepared to
-   implement recovery procedures once they detect a compromise.  A
-   manual or other out-of-band update of all resolvers will be required
-   if all trust anchor keys at a trust point are compromised.
-
-
-
-
-StJohns                   Expires July 14, 2006                [Page 10]
-
-Internet-Draft             trustanchor-update               January 2006
-
-
-7.3.  Dynamic Updates
-
-   Allowing a resolver to update its trust anchor set based in-band key
-   information is potentially less secure than a manual process.
-   However, given the nature of the DNS, the number of resolvers that
-   would require update if a trust anchor key were compromised, and the
-   lack of a standard management framework for DNS, this approach is no
-   worse than the existing situation.
-
-8.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
-              RFC 2535, March 1999.
-
-   [RFC3755]  Weiler, S., "Legacy Resolver Compatibility for Delegation
-              Signer (DS)", RFC 3755, May 2004.
-
-   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "DNS Security Introduction and Requirements",
-              RFC 4033, March 2005.
-
-   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Resource Records for the DNS Security Extensions",
-              RFC 4034, March 2005.
-
-   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Protocol Modifications for the DNS Security
-              Extensions", RFC 4035, March 2005.
-
-Editorial Comments
-
-   [msj1]  msj: N.B. This table is preliminary and will be revised to
-           match implementation experience.  For example, should there
-           be a state for "Add hold-down expired, but haven't seen the
-           new RRSet"?
-
-   [msj2]  msj: To be assigned.
-
-   [msj3]  msj: For discussion: What's the implementation guidance for
-           resolvers currently with respect to the non-assigned flag
-           bits?  If they consider the flag bit when doing key matching
-           at the trust anchor, they won't be able to match.
-
-
-
-
-
-
-StJohns                   Expires July 14, 2006                [Page 11]
-
-Internet-Draft             trustanchor-update               January 2006
-
-
-Author's Address
-
-   Michael StJohns
-   Nominum, Inc.
-   2385 Bay Road
-   Redwood City, CA  94063
-   USA
-
-   Phone: +1-301-528-4729
-   Email: Mike.StJohns@nominum.com
-   URI:   www.nominum.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-StJohns                   Expires July 14, 2006                [Page 12]
-
-Internet-Draft             trustanchor-update               January 2006
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-StJohns                   Expires July 14, 2006                [Page 13]
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-tsig-sha-06.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-tsig-sha-06.txt
deleted file mode 100644
index 00476ae..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-tsig-sha-06.txt
+++ /dev/null
@@ -1,522 +0,0 @@
-
-INTERNET-DRAFT                                    Donald E. Eastlake 3rd
-UPDATES RFC 2845                                   Motorola Laboratories
-Expires: July 2006                                          January 2006
-
-                  HMAC SHA TSIG Algorithm Identifiers
-                  ---- --- ---- --------- -----------
-                  <draft-ietf-dnsext-tsig-sha-06.txt>
-
-
-Status of This Document
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   This draft is intended to be become a Proposed Standard RFC.
-   Distribution of this document is unlimited. Comments should be sent
-   to the DNSEXT working group mailing list <namedroppers@ops.ietf.org>.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/1id-abstracts.html
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-
-Abstract
-
-   Use of the Domain Name System TSIG resource record requires
-   specification of a cryptographic message authentication code.
-   Currently identifiers have been specified only for the HMAC MD5
-   (Message Digest) and GSS (Generic Security Service) TSIG algorithms.
-   This document standardizes identifiers and implementation
-   requirements for additional HMAC SHA (Secure Hash Algorithm) TSIG
-   algorithms and standardizes how to specify and handle the truncation
-   of HMAC values in TSIG.
-
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-
-
-D. Eastlake 3rd                                                 [Page 1]
-
-
-INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
-
-
-Table of Contents
-
-      Status of This Document....................................1
-      Abstract...................................................1
-      Copyright Notice...........................................1
-
-      Table of Contents..........................................2
-
-      1. Introduction............................................3
-
-      2. Algorithms and Identifiers..............................4
-
-      3. Specifying Truncation...................................5
-      3.1 Truncation Specification...............................5
-
-      4. TSIG Truncation Policy and Error Provisions.............6
-
-      5. IANA Considerations.....................................7
-      6. Security Considerations.................................7
-      7. Copyright and Disclaimer................................7
-
-      8. Normative References....................................8
-      9. Informative References..................................8
-
-      Author's Address...........................................9
-      Additional IPR Provisions..................................9
-      Expiration and File Name...................................9
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 2]
-
-
-INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
-
-
-1. Introduction
-
-   [RFC 2845] specifies a TSIG Resource Record (RR) that can be used to
-   authenticate DNS (Domain Name System [STD 13]) queries and responses.
-   This RR contains a domain name syntax data item which names the
-   authentication algorithm used. [RFC 2845] defines the HMAC-MD5.SIG-
-   ALG.REG.INT name for authentication codes using the HMAC [RFC 2104]
-   algorithm with the MD5 [RFC 1321] hash algorithm. IANA has also
-   registered "gss-tsig" as an identifier for TSIG authentication where
-   the cryptographic operations are delegated to the Generic Security
-   Service (GSS) [RFC 3645].
-
-   It should be noted that use of TSIG presumes prior agreement, between
-   the resolver and server involved, as to the algorithm and key to be
-   used.
-
-   In Section 2, this document specifies additional names for TSIG
-   authentication algorithms based on US NIST SHA (United States,
-   National Institute of Science and Technology, Secure Hash Algorithm)
-   algorithms and HMAC and specifies the implementation requirements for
-   those algorithms.
-
-   In Section 3, this document specifies the effect of inequality
-   between the normal output size of the specified hash function and the
-   length of MAC (message authentication code) data given in the TSIG
-   RR. In particular, it specifies that a shorter length field value
-   specifies truncation and a longer length field is an error.
-
-   In Section 4, policy restrictions and implications related to
-   truncation and a new error code to indicate truncation shorter than
-   permitted by policy are described and specified.
-
-   The use herein of MUST, SHOULD, MAY, MUST NOT, and SHOULD NOT is as
-   defined in [RFC 2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 3]
-
-
-INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
-
-
-2. Algorithms and Identifiers
-
-   TSIG Resource Records (RRs) [RFC 2845] are used to authenticate DNS
-   queries and responses.  They are intended to be efficient symmetric
-   authentication codes based on a shared secret. (Asymmetric signatures
-   can be provided using the SIG RR [RFC 2931]. In particular, SIG(0)
-   can be used for transaction signatures.) Used with a strong hash
-   function, HMAC [RFC 2104] provides a way to calculate such symmetric
-   authentication codes. The only specified HMAC based TSIG algorithm
-   identifier has been HMAC-MD5.SIG-ALG.REG.INT based on MD5 [RFC 1321].
-
-   The use of SHA-1 [FIPS 180-2, RFC 3174], which is a 160 bit hash, as
-   compared with the 128 bits for MD5, and additional hash algorithms in
-   the SHA family [FIPS 180-2, RFC 3874, SHA2draft] with 224, 256, 384,
-   and 512 bits, may be preferred in some cases particularly since
-   increasingly successful cryptanalytic attacks are being made on the
-   shorter hashes.
-
-   Use of TSIG between a DNS resolver and server is by mutual agreement.
-   That agreement can include the support of additional algorithms and
-   criteria as to which algorithms and truncations are acceptable,
-   subject to the restriction and guidelines in Section 3 and 4 below.
-   Key agreement can be by the TKEY mechanism [RFC 2930] or other
-   mutually agreeable method.
-
-   The current HMAC-MD5.SIG-ALG.REG.INT and gss-tsig identifiers are
-   included in the table below for convenience.  Implementations which
-   support TSIG MUST also implement HMAC SHA1 and HMAC SHA256 and MAY
-   implement gss-tsig and the other algorithms listed below.
-
-         Mandatory      HMAC-MD5.SIG-ALG.REG.INT
-         Optional       gss-tsig
-         Mandatory      hmac-sha1
-         Optional       hmac-sha224
-         Mandatory      hmac-sha256
-         Optional       hamc-sha384
-         Optional       hmac-sha512
-
-   SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented.
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 4]
-
-
-INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
-
-
-3. Specifying Truncation
-
-   When space is at a premium and the strength of the full length of an
-   HMAC is not needed, it is reasonable to truncate the HMAC output and
-   use the truncated value for authentication. HMAC SHA-1 truncated to
-   96 bits is an option available in several IETF protocols including
-   IPSEC and TLS.
-
-   The TSIG RR [RFC 2845] includes a "MAC size" field, which gives the
-   size of the MAC field in octets. But [RFC 2845] does not specify what
-   to do if this MAC size differs from the length of the output of HMAC
-   for a particular hash function. Truncation is indicated by a MAC size
-   less than the HMAC size as specified below.
-
-
-
-3.1 Truncation Specification
-
-   The specification for TSIG handling is changed as follows:
-
-   1. If "MAC size" field is greater than HMAC output length:
-         This case MUST NOT be generated and if received MUST cause the
-      packet to be dropped and RCODE 1 (FORMERR) to be returned.
-
-   2. If "MAC size" field equals HMAC output length:
-         Operation is as described in [RFC 2845] with the entire output
-      HMAC output present.
-
-   3. "MAC size" field is less than HMAC output length but greater than
-      that specified in case 4 below:
-         This is sent when the signer has truncated the HMAC output to
-      an allowable length, as described in RFC 2104, taking initial
-      octets and discarding trailing octets. TSIG truncation can only be
-      to an integral number of octets. On receipt of a packet with
-      truncation thus indicated, the locally calculated MAC is similarly
-      truncated and only the truncated values compared for
-      authentication. The request MAC used when calculating the TSIG MAC
-      for a reply is the truncated request MAC.
-
-   4. "MAC size" field is less than the larger of 10 (octets) and half
-      the length of the hash function in use:
-         With the exception of certain TSIG error messages described in
-      RFC 2845 section 3.2 where it is permitted that the MAC size be
-      zero, this case MUST NOT be generated and if received MUST cause
-      the packet to be dropped and RCODE 1 (FORMERR) to be returned. The
-      size limit for this case can also, for the hash functions
-      mentioned in this document, be stated as less than half the hash
-      function length for hash functions other than MD5 and less than 10
-      octets for MD5.
-
-
-
-D. Eastlake 3rd                                                 [Page 5]
-
-
-INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
-
-
-4. TSIG Truncation Policy and Error Provisions
-
-   Use of TSIG is by mutual agreement between a resolver and server.
-   Implicit in such "agreement" are criterion as to acceptable keys and
-   algorithms and, with the extensions in this document, truncations.
-   Note that it is common for implementations to bind the TSIG secret
-   key or keys that may be in place at a resolver and server to
-   particular algorithms. Thus such implementations only permit the use
-   of an algorithm if there is an associated key in place. Receipt of an
-   unknown, unimplemented, or disabled algorithm typically results in a
-   BADKEY error.
-
-      Local policies MAY require the rejection of TSIGs even though they
-   use an algorithm for which implementation is mandatory.
-
-      When a local policy permits acceptance of a TSIG with a particular
-   algorithm and a particular non-zero amount of truncation it SHOULD
-   also permit the use of that algorithm with lesser truncation (a
-   longer MAC) up to the full HMAC output.
-
-      Regardless of a lower acceptable truncated MAC length specified by
-   local policy, a reply SHOULD be sent with a MAC at least as long as
-   that in the corresponding request unless the request specified a MAC
-   length longer than the HMAC output.
-
-      Implementations permitting multiple acceptable algorithms and/or
-   truncations SHOULD permit this list to be ordered by presumed
-   strength and SHOULD allow different truncations for the same
-   algorithm to be treated as separate entities in this list. When so
-   implemented, policies SHOULD accept a presumed stronger algorithm and
-   truncation than the minimum strength required by the policy.
-
-      If a TSIG is received with truncation which is permitted under
-   Section 3 above but the MAC is too short for the local policy in
-   force, an RCODE of TBA [22 suggested](BADTRUNC) MUST be returned.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 6]
-
-
-INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
-
-
-5. IANA Considerations
-
-   This document, on approval for publication as a standards track RFC,
-   (1) registers the new TSIG algorithm identifiers listed in Section 2
-   with IANA and (2) allocates the BADTRUNC RCODE TBA [22 suggested] in
-   Section 4. [RFC 2845]
-
-
-
-6. Security Considerations
-
-   For all of the message authentication code algorithms listed herein,
-   those producing longer values are believed to be stronger; however,
-   while there have been some arguments that mild truncation can
-   strengthen a MAC by reducing the information available to an
-   attacker, excessive truncation clearly weakens authentication by
-   reducing the number of bits an attacker has to try to break the
-   authentication by brute force [RFC 2104].
-
-   Significant progress has been made recently in cryptanalysis of hash
-   function of the type used herein, all of which ultimately derive from
-   the design of MD4. While the results so far should not effect HMAC,
-   the stronger SHA-1 and SHA-256 algorithms are being made mandatory
-   due to caution.
-
-   See the Security Considerations section of [RFC 2845].  See also the
-   Security Considerations section of [RFC 2104] from which the limits
-   on truncation in this RFC were taken.
-
-
-
-7. Copyright and Disclaimer
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 7]
-
-
-INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
-
-
-8. Normative References
-
-   [FIPS 180-2] - "Secure Hash Standard", (SHA-1/224/256/384/512) US
-   Federal Information Processing Standard, with Change Notice 1,
-   February 2004.
-
-   [RFC 1321] - Rivest, R., "The MD5 Message-Digest Algorithm ", RFC
-   1321, April 1992.
-
-   [RFC 2104] - Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
-   Hashing for Message Authentication", RFC 2104, February 1997.
-
-   [RFC 2119] - Bradner, S., "Key words for use in RFCs to Indicate
-   Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
-   Wellington, "Secret Key Transaction Authentication for DNS (TSIG)",
-   RFC 2845, May 2000.
-
-   [RFC 3174] - Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm
-   1 (SHA1)", RFC 3174, September 2001.
-
-   [RFC 3874] - R. Housely, "A 224-bit One-way Hash Function: SHA-224",
-   September 2004,
-
-   [SHA2draft] - Eastlake, D., T. Hansen, "US Secure Hash Algorithms
-   (SHA)", draft-eastlake-sha2-*.txt, work in progress.
-
-   [STD 13]
-         Mockapetris, P., "Domain names - concepts and facilities", STD
-         13, RFC 1034, November 1987.
-
-         Mockapetris, P., "Domain names - implementation and
-         specification", STD 13, RFC 1035, November 1987.
-
-
-
-9. Informative References.
-
-   [RFC 2930] - Eastlake 3rd, D., "Secret Key Establishment for DNS
-   (TKEY RR)", RFC 2930, September 2000.
-
-   [RFC 2931] - Eastlake 3rd, D., "DNS Request and Transaction
-   Signatures ( SIG(0)s )", RFC 2931, September 2000.
-
-   [RFC 3645] - Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead,
-   J., and R. Hall, "Generic Security Service Algorithm for Secret Key
-   Transaction Authentication for DNS (GSS-TSIG)", RFC 3645, October
-   2003.
-
-
-
-D. Eastlake 3rd                                                 [Page 8]
-
-
-INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
-
-
-Author's Address
-
-   Donald E. Eastlake 3rd
-   Motorola Laboratories
-   155 Beaver Street
-   Milford, MA 01757 USA
-
-   Telephone:   +1-508-786-7554 (w)
-
-   EMail:       Donald.Eastlake@motorola.com
-
-
-
-Additional IPR Provisions
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed
-   to pertain to the implementation or use of the technology
-   described in this document or the extent to which any license
-   under such rights might or might not be available; nor does it
-   represent that it has made any independent effort to identify any
-   such rights.  Information on the procedures with respect to
-   rights in RFC documents can be found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use
-   of such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository
-   at http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention
-   any copyrights, patents or patent applications, or other
-   proprietary rights that may cover technology that may be required
-   to implement this standard.  Please address the information to the
-   IETF at ietf-ipr@ietf.org.
-
-
-
-Expiration and File Name
-
-   This draft expires in July 2006.
-
-   Its file name is draft-ietf-dnsext-tsig-sha-06.txt
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 9]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt
deleted file mode 100644
index 9cf88a5..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt
+++ /dev/null
@@ -1,1063 +0,0 @@
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-DNSEXT Working Group                                          E. Lewis
-INTERNET DRAFT                                                 NeuStar
-Expiration Date: July 9, 2006                          January 9, 2006
-Updates RFC 1034, RFC 2672
-
-                              The Role of Wildcards
-                            in the Domain Name System
-                      draft-ietf-dnsext-wcard-clarify-10.txt
-
-Status of this Memo
-
-      By submitting this Internet-Draft, each author represents that
-      any applicable patent or other IPR claims of which he or she is
-      aware have been or will be disclosed, and any of which he or she
-      becomes aware will be disclosed, in accordance with Section 6 of
-      BCP 79.
-
-      Internet-Drafts are working documents of the Internet Engineering
-      Task Force (IETF), its areas, and its working groups.  Note that
-      other groups may also distribute working documents as Internet-
-      Drafts.
-
-      Internet-Drafts are draft documents valid for a maximum of six
-      months and may be updated, replaced, or obsoleted by other
-      documents at any time.  It is inappropriate to use Internet-Drafts
-      as reference material or to cite them other than as "work in
-      progress."
-
-      The list of current Internet-Drafts can be accessed at
-        http://www.ietf.org/ietf/1id-abstracts.txt
-
-      The list of Internet-Draft Shadow Directories can be accessed at
-        http://www.ietf.org/shadow.html
-
-      This Internet-Draft will expire on July 9, 2006.
-
-Copyright Notice
-
-      Copyright (C) The Internet Society (2006).
-
-Abstract
-
-      This is an update to the wildcard definition of RFC 1034.  The
-      interaction with wildcards and CNAME is changed, an error
-      condition removed, and the words defining some concepts central
-      to wildcards are changed.  The overall goal is not to change
-      wildcards, but to refine the definition of RFC 1034.
-
-
-
-
-DNSEXT Working Group        Expires July 9, 2006             [Page  1]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-Table of Contents
-
-1.    Introduction   .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  3
-1 1   Motivation                                                     3
-1 2   The Original Definition                                        3
-1 3   Roadmap to This Document                                       4
-1 3 1 New Terms                                                      4
-1.3.2 Changed Text                                                   5
-1.3.3 Considerations with Special Types                              5
-1.4   Standards Terminology                                          5
-2.    Wildcard Syntax   .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  6
-2.1   Identifying a Wildcard                                         6
-2.1.1 Wild Card Domain Name and Asterisk Label                       6
-2.1.2 Asterisks and Other Characters                                 6
-2.1.3 Non-terminal Wild Card Domain Names                            6
-2.2   Existence Rules                                                7
-2.2.1 An Example                                                     7
-2.2.2 Empty Non-terminals                                            9
-2.2.3 Yet Another Definition of Existence                           10
-2.3   When is a Wild Card Domain Name Not Special                   10
-3.    Impact of a Wild Card Domain Name On a Response .  .  .  .  . 10
-3.1   Step 2                                                        10
-3.2   Step 3                                                        11
-3.3   Part 'c'                                                      11
-3.3.1 Closest Encloser and the Source of Synthesis                  12
-3.3.2 Closest Encloser and Source of Synthesis Examples             12
-3.3.3 Type Matching                                                 13
-4.    Considerations with Special Types   .  .  .  .  .  .  .  .  . 13
-4.1   SOA RRSet at a Wild Card Domain Name                          13
-4.2   NS RRSet at a Wild Card Domain Name                           14
-4.2.1 Discarded Notions                                             14
-4.3   CNAME RRSet at a Wild Card Domain Name                        15
-4.4   DNAME RRSet at a Wild Card Domain Name                        15
-4.5   SRV RRSet at a Wild Card Domain Name                          16
-4.6   DS RRSet at a Wild Card Domain Name                           16
-4.7   NSEC RRSet at a Wild Card Domain Name                         17
-4.8   RRSIG at a Wild Card Domain Name                              17
-4.9   Empty Non-terminal Wild Card Domain Name                      17
-5.    Security Considerations .  .  .  .  .  .  .  .  .  .  .  .  . 17
-6.    IANA Considerations     .  .  .  .  .  .  .  .  .  .  .  .  . 17
-7.    References              .  .  .  .  .  .  .  .  .  .  .  .  . 17
-8.    Editor                  .  .  .  .  .  .  .  .  .  .  .  .  . 18
-9.    Others Contributing to the Document    .  .  .  .  .  .  .  . 18
-10.   Trailing Boilerplate    .  .  .  .  .  .  .  .  .  .  .  .  . 19
-
-
-
-
-
-
-
-
-DNSEXT Working Group        Expires July 9, 2006             [Page  2]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-1. Introduction
-
-      In RFC 1034 [RFC1034], sections 4.3.2 and 4.3.3 describe the
-      synthesis of answers from special resource records called
-      wildcards.  The definition in RFC 1034 is incomplete and has
-      proven to be confusing.  This document describes the wildcard
-      synthesis by adding to the discussion and making limited
-      modifications.  Modifications are made to close inconsistencies
-      that have led to interoperability issues.  This description
-      does not expand the service intended by the original definition.
-
-      Staying within the spirit and style of the original documents,
-      this document avoids specifying rules for DNS implementations
-      regarding wildcards.  The intention is to only describe what is
-      needed for interoperability, not restrict implementation choices.
-      In addition, consideration is given to minimize any backwards
-      compatibility issues with implementations that comply with RFC
-      1034's definition.
-
-      This document is focused on the concept of wildcards as defined
-      in RFC 1034.  Nothing is implied regarding alternative means of
-      synthesizing resource record sets, nor are alternatives discussed.
-
-1.1 Motivation
-
-      Many DNS implementations diverge, in different ways, from the
-      original definition of wildcards.  Although there is clearly a
-      need to clarify the original documents in light of this alone,
-      the impetus for this document lay in the engineering of the DNS
-      security extensions [RFC4033].  With an unclear definition of
-      wildcards the design of authenticated denial became entangled.
-
-      This document is intended to limit its changes, documenting only
-      those based on implementation experience, and to remain as close
-      to the original document as possible.  To reinforce that this
-      document is meant to clarify and adjust and not redefine wildcards,
-      relevant sections of RFC 1034 are repeated verbatim to facilitate
-      comparison of the old and new text.
-
-1.2 The Original Definition
-
-      The definition of the wildcard concept is comprised by the
-      documentation of the algorithm by which a name server prepares
-      a response (in RFC 1034's section 4.3.2) and the way in which
-      a resource record (set) is identified as being a source of
-      synthetic data (section 4.3.3).
-
-      This is the definition of the term "wildcard" as it appears in
-      RFC 1034, section 4.3.3.
-
-
-
-DNSEXT Working Group        Expires July 9, 2006             [Page  3]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-# In the previous algorithm, special treatment was given to RRs with
-# owner names starting with the label "*".  Such RRs are called
-# wildcards. Wildcard RRs can be thought of as instructions for
-# synthesizing RRs.  When the appropriate conditions are met, the name
-# server creates RRs with an owner name equal to the query name and
-# contents taken from the wildcard RRs.
-
-      This passage follows the algorithm in which the term wildcard
-      is first used.   In this definition, wildcard refers to resource
-      records.  In other usage, wildcard has referred to domain names,
-      and it has been used to describe the operational practice of
-      relying on wildcards to generate answers.  It is clear from this
-      that there is a need to define clear and unambiguous terminology
-      in the process of discussing wildcards.
-
-      The mention of the use of wildcards in the preparation of a
-      response is contained in step 3c of RFC 1034's section 4.3.2
-      entitled "Algorithm."  Note that "wildcard" does not appear in
-      the algorithm, instead references are made to the "*" label.
-      The portion of the algorithm relating to wildcards is
-      deconstructed in detail in section 3 of this document, this is
-      the beginning of the relevant portion of the "Algorithm."
-
-#    c. If at some label, a match is impossible (i.e., the
-#       corresponding label does not exist), look to see if [...]
-#       the "*" label exists.
-
-      The scope of this document is the RFC 1034 definition of
-      wildcards and the implications of updates to those documents,
-      such as DNSSEC.  Alternate schemes for synthesizing answers are
-      not considered.  (Note that there is no reference listed.  No
-      document is known to describe any alternate schemes, although
-      there has been some mention of them in mailing lists.)
-
-1.3 Roadmap to This Document
-
-      This document accomplishes these three items.
-      o Defines new terms
-      o Makes minor changes to avoid conflicting concepts
-      o Describes the actions of certain resource records as wildcards
-
-1.3.1 New Terms
-
-      To help in discussing what resource records are wildcards, two
-      terms will be defined - "asterisk label" and "wild card domain
-      name".  These are defined in section 2.1.1.
-
-      To assist in clarifying the role of wildcards in the name server
-      algorithm in RFC 1034, 4.3.2, "source of synthesis" and "closest
-      encloser" are defined.  These definitions are in section 3.3.2.
-      "Label match" is defined in section 3.2.
-
-DNSEXT Working Group        Expires July 9, 2006             [Page  4]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-      The new terms are used to make discussions of wildcards clearer.
-      Terminology doesn't directly have an impact on implementations.
-
-1.3.2 Changed Text
-
-      The definition of "existence" is changed superficially.  This
-      change will not be apparent to implementations; it is needed to
-      make descriptions more precise.  The change appears in section
-      2.2.3.
-
-      RFC 1034, section 4.3.3., seems to prohibit having two asterisk
-      labels in a wildcard owner name.  With this document the
-      restriction is removed entirely.  This change and its implications
-      are in section 2.1.3.
-
-      The actions when a source of synthesis owns a CNAME RR are
-      changed to mirror the actions if an exact match name owns a
-      CNAME RR.  This is an addition to the words in RFC 1034,
-      section 4.3.2, step 3, part c.  The discussion of this is in
-      section 3.3.3.
-
-      Only the latter change represents an impact to implementations.
-      The definition of existence is not a protocol impact.  The change
-      to the restriction on names is unlikely to have an impact, as
-      RFC 1034 contained no specification on when and how to enforce the
-      restriction.
-
-1.3.3 Considerations with Special Types
-
-      This document describes semantics of wildcard RRSets for
-      "interesting" types as well as empty non-terminal wildcards.
-      Understanding these situations in the context of wildcards has
-      been clouded because these types incur special processing if
-      they are the result of an exact match.  This discussion is in
-      section 4.
-
-      These discussions do not have an implementation impact, they cover
-      existing knowledge of the types, but to a greater level of detail.
-
-1.4 Standards Terminology
-
-      This document does not use terms as defined in "Key words for use
-      in RFCs to Indicate Requirement Levels." [RFC2119]
-
-      Quotations of RFC 1034 are denoted by a '#' in the leftmost
-      column.  References to section "4.3.2" are assumed to refer
-      to RFC 1034's section 4.3.2, simply titled "Algorithm."
-
-
-
-
-
-DNSEXT Working Group        Expires July 9, 2006             [Page  5]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-2. Wildcard Syntax
-
-      The syntax of a wildcard is the same as any other DNS resource
-      record, across all classes and types.  The only significant
-      feature is the owner name.
-
-      Because wildcards are encoded as resource records with special
-      names, they are included in zone transfers and incremental zone
-      transfers[RFC1995] just as non-wildcard resource records are.
-      This feature has been under appreciated until discussions on
-      alternative approaches to wildcards appeared on mailing lists.
-
-2.1 Identifying a Wildcard
-
-      To provide a more accurate description of wildcards, the
-      definition has to start with a discussion of the domain names
-      that appear as owners.  Two new terms are needed, "Asterisk
-      Label" and "Wild Card Domain Name."
-
-2.1.1 Wild Card Domain Name and Asterisk Label
-
-      A "wild card domain name" is defined by having its initial
-      (i.e., left-most or least significant) label be, in binary format:
-
-           0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)
-
-      The first octet is the normal label type and length for a 1 octet
-      long label, the second octet is the ASCII representation [RFC20]
-      for the '*' character.
-
-      A descriptive name of a label equaling that value is an "asterisk
-      label."
-
-      RFC 1034's definition of wildcard would be "a resource record
-      owned by a wild card domain name."
-
-2.1.2 Asterisks and Other Characters
-
-      No label values other than that in section 2.1.1 are asterisk
-      labels, hence names beginning with other labels are never wild
-      card domain names.  Labels such as 'the*' and '**' are not
-      asterisk labels so these labels do not start wild card domain
-      names.
-
-2.1.3 Non-terminal Wild Card Domain Names
-
-      In section 4.3.3, the following is stated:
-
-# ..........................  The owner name of the wildcard RRs is of
-# the form "*.<anydomain>", where <anydomain> is any domain name.
-# <anydomain> should not contain other * labels......................
-
-DNSEXT Working Group        Expires July 9, 2006             [Page  6]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-      The restriction is now removed.  The original documentation of it
-      is incomplete and the restriction does not serve any purpose
-      given years of operational experience.
-
-      There are three possible reasons for putting the restriction in
-      place, but none of the three has held up over time.  One is
-      that the restriction meant that there would never be subdomains
-      of wild card domain names, but the restriciton as stated still
-      permits "example.*.example." for instance.  Another is that
-      wild card domain names are not intended to be empty non-terminals,
-      but this situation does not disrupt the algorithm in 4.3.2.
-      Finally, "nested" wild card domain names are not ambiguous once
-      the concept of the closest encloser had been documented.
-
-      A wild card domain name can have subdomains.  There is no need
-      to inspect the subdomains to see if there is another asterisk
-      label in any subdomain.
-
-      A wild card domain name can be an empty non-terminal.  (See the
-      upcoming sections on empty non-terminals.)  In this case, any
-      lookup encountering it will terminate as would any empty
-      non-terminal match.
-
-2.2 Existence Rules
-
-      The notion that a domain name 'exists' is mentioned in the
-      definition of wildcards.  In section 4.3.3 of RFC 1034:
-
-# Wildcard RRs do not apply:
-#
-...
-#   - When the query name or a name between the wildcard domain and
-#     the query name is know[n] to exist.  For example, if a wildcard
-
-      "Existence" is therefore an important concept in the understanding
-      of wildcards.  Unfortunately, the definition of what exists, in RFC
-      1034, is unclear.  So, in sections 2.2.2. and 2.2.3, another look is
-      taken at the definition of existence.
-
-2.2.1 An Example
-
-      To illustrate what is meant by existence consider this complete
-      zone:
-
-
-
-
-
-
-
-
-
-DNSEXT Working Group        Expires July 9, 2006             [Page  7]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-        $ORIGIN example.
-        example.                 3600 IN  SOA   <SOA RDATA>
-        example.                 3600     NS    ns.example.com.
-        example.                 3600     NS    ns.example.net.
-        *.example.               3600     TXT   "this is a wild card"
-        *.example.               3600     MX    10 host1.example.
-        sub.*.example.           3600     TXT   "this is not a wild card"
-        host1.example.           3600     A     192.0.4.1
-        _ssh._tcp.host1.example. 3600     SRV  <SRV RDATA>
-        _ssh._tcp.host2.example. 3600     SRV  <SRV RDATA>
-        subdel.example.          3600     NS   ns.example.com.
-        subdel.example.          3600     NS   ns.example.net.
-
-      A look at the domain names in a tree structure is helpful:
-
-                                    |
-                    -------------example------------
-                   /           /         \          \
-                  /           /           \          \
-                 /           /             \          \
-                *          host1          host2      subdel
-                |            |             |
-                |            |             |
-               sub         _tcp          _tcp
-                             |             |
-                             |             |
-                           _ssh          _ssh
-
-      The following responses would be synthesized from one of the
-      wildcards in the zone:
-
-          QNAME=host3.example. QTYPE=MX, QCLASS=IN
-               the answer will be a "host3.example. IN MX ..."
-
-          QNAME=host3.example. QTYPE=A, QCLASS=IN
-               the answer will reflect "no error, but no data"
-               because there is no A RR set at '*.example.'
-
-          QNAME=foo.bar.example. QTYPE=TXT, QCLASS=IN
-               the answer will be "foo.bar.example. IN TXT ..."
-               because bar.example. does not exist, but the wildcard
-               does.
-
-      The following responses would not be synthesized from any of the
-      wildcards in the zone:
-
-          QNAME=host1.example., QTYPE=MX, QCLASS=IN
-               because host1.example. exists
-
-          QNAME=sub.*.example., QTYPE=MX, QCLASS=IN
-               because sub.*.example. exists
-
-DNSEXT Working Group        Expires July 9, 2006             [Page  8]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-          QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN
-               because _tcp.host1.example. exists (without data)
-
-          QNAME=host.subdel.example., QTYPE=A, QCLASS=IN
-               because subdel.example. exists (and is a zone cut)
-
-          QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN
-               because *.example. exists
-
-      The final example highlights one common misconception about
-      wildcards.  A wildcard "blocks itself" in the sense that a
-      wildcard does not match its own subdomains.  I.e. "*.example."
-      does not match all names in the "example." zone, it fails to
-      match the names below "*.example." To cover names under
-      "*.example.", another wild card domain name is needed -
-      "*.*.example." - which covers all but it's own subdomains.
-
-2.2.2 Empty Non-terminals
-
-      Empty non-terminals [RFC2136, Section 7.16] are domain names
-      that own no resource records but have subdomains that do.  In
-      section 2.2.1, "_tcp.host1.example." is an example of a empty
-      non-terminal name.  Empty non-terminals are introduced by this
-      text in section 3.1 of RFC 1034:
-
-# The domain name space is a tree structure.  Each node and leaf on
-# the tree corresponds to a resource set (which may be empty).  The
-# domain system makes no distinctions between the uses of the
-# interior nodes and leaves, and this memo uses the term "node" to
-# refer to both.
-
-      The parenthesized "which may be empty" specifies that empty non-
-      terminals are explicitly recognized, and that empty non-terminals
-      "exist."
-
-      Pedantically reading the above paragraph can lead to an
-      interpretation that all possible domains exist - up to the
-      suggested limit of 255 octets for a domain name [RFC1035].
-      For example, www.example. may have an A RR, and as far as is
-      practically concerned, is a leaf of the domain tree.  But the
-      definition can be taken to mean that sub.www.example. also
-      exists, albeit with no data.  By extension, all possible domains
-      exist, from the root on down.
-
-      As RFC 1034 also defines "an authoritative name error indicating
-      that the name does not exist" in section 4.3.1, so this apparently
-      is not the intent of the original definition, justifying the
-      need for an updated definition in the next section.
-
-
-
-
-DNSEXT Working Group        Expires July 9, 2006             [Page  9]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-2.2.3 Yet Another Definition of Existence
-
-      RFC1034's wording is fixed by the following paragraph:
-
-      The domain name space is a tree structure.  Nodes in the tree
-      either own at least one RRSet and/or have descendants that
-      collectively own at least one RRSet.  A node may exist with no
-      RRSets only if it has descendents that do, this node is an empty
-      non-terminal.
-
-      A node with no descendants is a leaf node.  Empty leaf nodes do
-      not exist.
-
-      Note that at a zone boundary, the domain name owns data,
-      including the NS RR set.  In the delegating zone, the NS RR
-      set is not authoritative, but that is of no consequence here.
-      The domain name owns data, therefore, it exists.
-
-2.3 When is a Wild Card Domain Name Not Special
-
-      When a wild card domain name appears in a message's query section,
-      no special processing occurs.  An asterisk label in a query name
-      only matches a single, corresponding asterisk label in the
-      existing zone tree when the 4.3.2 algorithm is being followed.
-
-      When a wild card domain name appears in the resource data of a
-      record, no special processing occurs.  An asterisk label in that
-      context literally means just an asterisk.
-
-3. Impact of a Wild Card Domain Name On a Response
-
-      RFC 1034's description of how wildcards impact response
-      generation is in its section 4.3.2.  That passage contains the
-      algorithm followed by a server in constructing a response.
-      Within that algorithm, step 3, part 'c' defines the behavior of
-      the wildcard.
-
-      The algorithm in section 4.3.2. is not intended to be pseudo-code,
-      i.e., its steps are not intended to be followed in strict order.
-      The "algorithm" is a suggested means of implementing the
-      requirements.  As such, in step 3, parts a, b, and c, do not have
-      to be implemented in that order, provided that the result of the
-      implemented code is compliant with the protocol's specification.
-
-3.1 Step 2
-
-      Step 2 of section 4.3.2 reads:
-
-#   2. Search the available zones for the zone which is the nearest
-#      ancestor to QNAME.  If such a zone is found, go to step 3,
-#      otherwise step 4.
-
-DNSEXT Working Group        Expires July 9, 2006             [Page 10]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-      In this step, the most appropriate zone for the response is
-      chosen.  The significance of this step is that it means all of
-      step 3 is being performed within one zone.  This has significance
-      when considering whether or not an SOA RR can be ever be used for
-      synthesis.
-
-3.2 Step 3
-
-      Step 3 is dominated by three parts, labelled 'a', 'b', and 'c'.
-      But the beginning of the step is important and needs explanation.
-
-#   3. Start matching down, label by label, in the zone.  The
-#      matching process can terminate several ways:
-
-      The word 'matching' refers to label matching.  The concept
-      is based in the view of the zone as the tree of existing names.
-      The query name is considered to be an ordered sequence of
-      labels - as if the name were a path from the root to the owner
-      of the desired data.  (Which it is - 3rd paragraph of RFC 1034,
-      section 3.1.)
-
-      The process of label matching a query name ends in exactly one of
-      three choices, the parts 'a', 'b', and 'c'.  Either the name is
-      found, the name is below a cut point, or the name is not found.
-
-      Once one of the parts is chosen, the other parts are not
-      considered.  (E.g., do not execute part 'c' and then change
-      the execution path to finish in part 'b'.)  The process of label
-      matching is also done independent of the query type (QTYPE).
-
-      Parts 'a' and 'b' are not an issue for this clarification as they
-      do not relate to record synthesis.  Part 'a' is an exact match
-      that results in an answer, part 'b' is a referral.
-
-3.3 Part 'c'
-
-      The context of part 'c' is that the process of label matching the
-      labels of the query name has resulted in a situation in which
-      there is no corresponding label in the tree.  It is as if the
-      lookup has "fallen off the tree."
-
-#     c. If at some label, a match is impossible (i.e., the
-#        corresponding label does not exist), look to see if [...]
-#        the "*" label exists.
-
-      To help describe the process of looking 'to see if [...] the "*"
-      label exists' a term has been coined to describe the last domain
-      (node) matched.  The term is "closest encloser."
-
-
-
-
-DNSEXT Working Group        Expires July 9, 2006             [Page 11]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-3.3.1 Closest Encloser and the Source of Synthesis
-
-      The closest encloser is the node in the zone's tree of existing
-      domain names that has the most labels matching the query name
-      (consecutively, counting from the root label downward). Each match
-      is a "label match" and the order of the labels is the same.
-
-      The closest encloser is, by definition, an existing name in the
-      zone.  The closest encloser might be an empty non-terminal or even
-      be a wild card domain name itself.  In no circumstances is the
-      closest encloser to be used to synthesize records for the current
-      query.
-
-      The source of synthesis is defined in the context of a query
-      process as that wild card domain name immediately descending
-      from the closest encloser, provided that this wild card domain
-      name exists.  "Immediately descending" means that the source
-      of synthesis has a name of the form:
-            <asterisk label>.<closest encloser>.
-      A source of synthesis does not guarantee having a RRSet to use
-      for synthesis.  The source of synthesis could be an empty
-      non-terminal.
-
-      If the source of synthesis does not exist (not on the domain
-      tree), there will be no wildcard synthesis.  There is no search
-      for an alternate.
-
-      The important concept is that for any given lookup process, there
-      is at most one place at which wildcard synthetic records can be
-      obtained.  If the source of synthesis does not exist, the lookup
-      terminates, the lookup does not look for other wildcard records.
-
-3.3.2 Closest Encloser and Source of Synthesis Examples
-
-      To illustrate, using the example zone in section 2.2.1 of this
-      document, the following chart shows QNAMEs and the closest
-      enclosers.
-
-      QNAME                       Closest Encloser    Source of Synthesis
-      host3.example.              example.            *.example.
-      _telnet._tcp.host1.example. _tcp.host1.example. no source
-      _telnet._tcp.host2.example. host2.example.      no source
-      _telnet._tcp.host3.example. example.            *.example.
-      _chat._udp.host3.example.   example.            *.example.
-      foobar.*.example.           *.example.          no source
-
-
-
-
-
-
-
-DNSEXT Working Group        Expires July 9, 2006             [Page 12]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-3.3.3 Type Matching
-
-       RFC 1034 concludes part 'c' with this:
-
-#            If the "*" label does not exist, check whether the name
-#            we are looking for is the original QNAME in the query
-#            or a name we have followed due to a CNAME.  If the name
-#            is original, set an authoritative name error in the
-#            response and exit.  Otherwise just exit.
-#
-#            If the "*" label does exist, match RRs at that node
-#            against QTYPE.  If any match, copy them into the answer
-#            section, but set the owner of the RR to be QNAME, and
-#            not the node with the "*" label.  Go to step 6.
-
-      The final paragraph covers the role of the QTYPE in the lookup
-      process.
-
-      Based on implementation feedback and similarities between step
-      'a' and step 'c' a change to this passage has been made.
-
-      The change is to add the following text to step 'c' prior to the
-      instructions to "go to step 6":
-
-               If the data at the source of synthesis is a CNAME, and
-               QTYPE doesn't match CNAME, copy the CNAME RR into the
-               answer section of the response changing the owner name
-               to the QNAME, change QNAME to the canonical name in the
-               CNAME RR, and go back to step 1.
-
-      This is essentially the same text in step a covering the
-      processing of CNAME RRSets.
-
-4. Considerations with Special Types
-
-      Sections 2 and 3 of this document discuss wildcard synthesis
-      with respect to names in the domain tree and ignore the impact
-      of types.  In this section, the implication of wildcards of
-      specific types are discussed.  The types covered are those
-      that have proven to be the most difficult to understand.  The
-      types are SOA, NS, CNAME, DNAME, SRV, DS, NSEC, RRSIG and
-      "none," i.e., empty non-terminal wild card domain names.
-
-4.1 SOA RRSet at a Wild Card Domain Name
-
-      A wild card domain name owning an SOA RRSet means that the
-      domain is at the root of the zone (apex).  The domain can not
-      be a source of synthesis because that is, by definition, a
-      descendent node (of the closest encloser) and a zone apex is
-      at the top of the zone.
-
-
-DNSEXT Working Group        Expires July 9, 2006             [Page 13]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-      Although a wild card domain name owning an SOA RRSet can never
-      be a source of synthesis, there is no reason to forbid the
-      ownership of an SOA RRSet.
-
-      E.g., given this zone:
-             $ORIGIN *.example.
-             @                 3600 IN  SOA   <SOA RDATA>
-                               3600     NS    ns1.example.com.
-                               3600     NS    ns1.example.net.
-             www               3600     TXT   "the www txt record"
-
-      A query for www.*.example.'s TXT record would still find the
-      "the www txt record" answer.  The asterisk label only becomes
-      significant when section 4.3.2, step 3 part 'c' is in effect.
-
-      Of course, there would need to be a delegation in the parent
-      zone, "example." for this to work too.  This is covered in the
-      next section.
-
-4.2 NS RRSet at a Wild Card Domain Name
-
-      With the definition of DNSSEC [RFC4033, RFC4034, RFC4035] now
-      in place, the semantics of a wild card domain name owning an
-      NS RRSet has come to be poorly defined.  The dilemma relates to
-      a conflict between the rules for synthesis in part 'c' and the
-      fact that the resulting synthesis generates a record for which
-      the zone is not authoritative.  In a DNSSEC signed zone, the
-      mechanics of signature management (generation and inclusion
-      in a message) have become unclear.
-
-      Salient points of the working group discussion on this topic is
-      summarized in section 4.2.1.
-
-      As a result of these discussion, there is no definition given for
-      wild card domain names owning an NS RRSet.  The semantics are
-      left undefined until there is a clear need to have a set defined,
-      and until there is a clear direction to proceed.  Operationally,
-      inclusion of wild card NS RRSets in a zone is discouraged, but
-      not barred.
-
-4.2.1 Discarded Notions
-
-      Prior to DNSSEC, a wild card domain name owning a NS RRSet
-      appeared to be workable, and there are some instances in which
-      it is found in deployments using implementations that support
-      this.  Continuing to allow this in the specification is not
-      tenable with DNSSEC.  The reason is that the synthesis of the
-      NS RRSet is being done in a zone that has delegated away the
-      responsibility for the name.  This "unauthorized" synthesis is
-      not a problem for the base DNS protocol, but DNSSEC, in affirming
-      the authorization model for DNS exposes the problem.
-
-DNSEXT Working Group        Expires July 9, 2006             [Page 14]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-      Outright banning of wildcards of type NS is also untenable as
-      the DNS protocol does not define how to handle "illegal" data.
-      Implementations may choose not to load a zone, but there is no
-      protocol definition.  The lack of the definition is complicated
-      by having to cover dynamic update [RFC 2136], zone transfers,
-      as well as loading at the master server.  The case of a client
-      (resolver, caching server) getting a wildcard of type NS in
-      a reply would also have to be considered.
-
-      Given the daunting challenge of a complete definition of how to
-      ban such records, dealing with existing implementations that
-      permit the records today is a further complication.  There are
-      uses of wild card domain name owning NS RRSets.
-
-      One compromise proposed would have redefined wildcards of type
-      NS to not be used in synthesis, this compromise fell apart
-      because it would have required significant edits to the DNSSEC
-      signing and validation work.  (Again, DNSSEC catches
-      unauthorized data.)
-
-      With no clear consensus forming on the solution to this dilemma,
-      and the realization that wildcards of type NS are a rarity in
-      operations, the best course of action is to leave this open-ended
-      until "it matters."
-
-4.3 CNAME RRSet at a Wild Card Domain Name
-
-      The issue of a CNAME RRSet owned by a wild card domain name has
-      prompted a suggested change to the last paragraph of step 3c of
-      the algorithm in 4.3.2.  The changed text appears in section
-      3.3.3 of this document.
-
-4.4 DNAME RRSet at a Wild Card Domain Name
-
-      Ownership of a DNAME [RFC2672] RRSet by a wild card domain name
-      represents a threat to the coherency of the DNS and is to be
-      avoided or outright rejected.  Such a DNAME RRSet represents
-      non-deterministic synthesis of rules fed to different caches.
-      As caches are fed the different rules (in an unpredictable
-      manner) the caches will cease to be coherent.  ("As caches
-      are fed" refers to the storage in a cache of records obtained
-      in responses by recursive or iterative servers.)
-
-      For example, assume one cache, responding to a recursive
-      request, obtains the record:
-         "a.b.example. DNAME foo.bar.example.net."
-      and another cache obtains:
-         "b.example.  DNAME foo.bar.example.net."
-      both generated from the record:
-         "*.example. DNAME foo.bar.example.net."
-      by an authoritative server.
-
-DNSEXT Working Group        Expires July 9, 2006             [Page 15]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-      The DNAME specification is not clear on whether DNAME records
-      in a cache are used to rewrite queries.  In some interpretations,
-      the rewrite occurs, in some, it is not.  Allowing for the
-      occurrence of rewriting, queries for "sub.a.b.example. A" may
-      be rewritten as "sub.foo.bar.tld. A" by the former caching
-      server and may be rewritten as "sub.a.foo.bar.tld. A" by the
-      latter.  Coherency is lost, an operational nightmare ensues.
-
-      Another justification for banning or avoiding wildcard DNAME
-      records is the observation that such a record could synthesize
-      a DNAME owned by "sub.foo.bar.example." and "foo.bar.example."
-      There is a restriction in the DNAME definition that no domain
-      exist below a DNAME-owning domain, hence, the wildcard DNAME
-      is not to be permitted.
-
-4.5 SRV RRSet at a Wild Card Domain Name
-
-      The definition of the SRV RRset is RFC 2782 [RFC2782].  In the
-      definition of the record, there is some confusion over the term
-      "Name."  The definition reads as follows:
-
-# The format of the SRV RR
-...
-#    _Service._Proto.Name TTL Class SRV Priority Weight Port Target
-...
-#  Name
-#   The domain this RR refers to.  The SRV RR is unique in that the
-#   name one searches for is not this name; the example near the end
-#   shows this clearly.
-
-      Do not confuse the definition "Name" with the owner name.  I.e.,
-      once removing the _Service and _Proto labels from the owner name
-      of the SRV RRSet, what remains could be a wild card domain name
-      but this is immaterial to the SRV RRSet.
-
-      E.g.,  If an SRV record is:
-         _foo._udp.*.example. 10800 IN SRV 0 1 9 old-slow-box.example.
-
-      *.example is a wild card domain name and although it is the Name
-      of the SRV RR, it is not the owner (domain name).  The owner
-      domain name is "_foo._udp.*.example." which is not a wild card
-      domain name.
-
-      The confusion is likely based on the mixture of the specification
-      of the SRV RR and the description of a "use case."
-
-4.6 DS RRSet at a Wild Card Domain Name
-
-      A DS RRSet owned by a wild card domain name is meaningless and
-      harmless.  This statement is made in the context that an NS RRSet
-      at a wild card domain name is undefined.  At a non-delegation
-
-DNSEXT Working Group        Expires July 9, 2006             [Page 16]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-      point, a DS RRSet has no value (no corresponding DNSKEY RRSet
-      will be used in DNSSEC validation).  If there is a synthesized
-      DS RRSet, it alone will not be very useful as it exists in the
-      context of a delegation point.
-
-4.7 NSEC RRSet at a Wild Card Domain Name
-
-      Wild card domain names in DNSSEC signed zones will have an NSEC
-      RRSet.  Synthesis of these records will only occur when the
-      query exactly matches the record.  Synthesized NSEC RR's will not
-      be harmful as they will never be used in negative caching or to
-      generate a negative response.  [RFC2308]
-
-4.8 RRSIG at a Wild Card Domain Name
-
-      RRSIG records will be present at a wild card domain name in a
-      signed zone, and will be synthesized along with data sought in a
-      query.  The fact that the owner name is synthesized is not a
-      problem as the label count in the RRSIG will instruct the
-      verifying code to ignore it.
-
-4.9 Empty Non-terminal Wild Card Domain Name
-
-      If a source of synthesis is an empty non-terminal, then the
-      response will be one of no error in the return code and no RRSet
-      in the answer section.
-
-5. Security Considerations
-
-      This document is refining the specifications to make it more
-      likely that security can be added to DNS.  No functional
-      additions are being made, just refining what is considered
-      proper to allow the DNS, security of the DNS, and extending
-      the DNS to be more predictable.
-
-6. IANA Considerations
-
-       None.
-
-7. References
-
-      Normative References
-
-      [RFC20]   ASCII Format for Network Interchange, V.G. Cerf,
-                Oct-16-1969
-
-      [RFC1034] Domain Names - Concepts and Facilities,
-                P.V. Mockapetris, Nov-01-1987
-
-      [RFC1035] Domain Names - Implementation and Specification, P.V
-                Mockapetris, Nov-01-1987
-
-DNSEXT Working Group        Expires July 9, 2006             [Page 17]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-      [RFC1995] Incremental Zone Transfer in DNS, M. Ohta, August 1996
-
-      [RFC2119] Key Words for Use in RFCs to Indicate Requirement
-                Levels, S Bradner, March 1997
-
-      [RFC2308] Negative Caching of DNS Queries (DNS NCACHE),
-                M. Andrews, March 1998
-
-      [RFC2672] Non-Terminal DNS Name Redirection, M. Crawford,
-                August 1999.
-
-      [RFC2782] A DNS RR for specifying the location of services (DNS
-                SRV), A. Gulbrandsen, et.al., February 2000
-
-      [RFC4033] DNS Security Introduction and Requirements, R. Arends,
-                et.al., March 2005
-
-      [RFC4034] Resource Records for the DNS Security Extensions,
-                R. Arends, et.al., March 2005
-
-      [RFC4035] Protocol Modifications for the DNS Security Extensions,
-                R. Arends, et.al., March 2005
-
-      Informative References
-
-      [RFC2136] Dynamic Updates in the Domain Name System (DNS UPDATE),
-                P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound,
-                April 1997
-
-8. Editor
-
-           Name:         Edward Lewis
-           Affiliation:  NeuStar
-           Address:      46000 Center Oak Plaza, Sterling, VA, 20166, US
-           Phone:        +1-571-434-5468
-           Email:        ed.lewis@neustar.biz
-
-      Comments on this document can be sent to the editor or the mailing
-      list for the DNSEXT WG, namedroppers@ops.ietf.org.
-
-9. Others Contributing to the Document
-
-      This document represents the work of a large working group.  The
-      editor merely recorded the collective wisdom of the working group.
-
-
-
-
-
-
-
-
-
-DNSEXT Working Group        Expires July 9, 2006             [Page 17]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-10. Trailing Boilerplate
-
-      Copyright (C) The Internet Society (2006).
-
-      This document is subject to the rights, licenses and restrictions
-      contained in BCP 78, and except as set forth therein, the authors
-      retain all their rights.
-
-      This document and the information contained herein are provided
-      on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION
-      HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET
-      SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
-      WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
-      ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
-      INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-      MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-      The IETF takes no position regarding the validity or scope of
-      any Intellectual Property Rights or other rights that might
-      be claimed to pertain to the implementation or use of the
-      technology described in this document or the extent to which
-      any license under such rights might or might not be available;
-      nor does it represent that it has made any independent effort
-      to identify any such rights.  Information on the procedures
-      with respect to rights in RFC documents can be found in BCP 78
-      and BCP 79.
-
-      Copies of IPR disclosures made to the IETF Secretariat and any
-      assurances of licenses to be made available, or the result of an
-      attempt made to obtain a general license or permission for the
-      use of such proprietary rights by implementers or users of this
-      specification can be obtained from the IETF on-line IPR
-      repository at http://www.ietf.org/ipr.  The IETF invites any
-      interested party to bring to its attention any copyrights,
-      patents or patent applications, or other proprietary rights
-      that may cover technology that may be required to implement
-      this standard.  Please address the information to the IETF at
-      ietf-ipr@ietf.org.
-
-Acknowledgement
-
-      Funding for the RFC Editor function is currently provided by the
-      Internet Society.
-
-Expiration
-
-      This document expires on or about July 9, 2006.
-
-
-
-DNSEXT Working Group        Expires July 9, 2006             [Page 19]
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-bad-dns-res-05.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-bad-dns-res-05.txt
deleted file mode 100644
index 0855ba3..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-bad-dns-res-05.txt
+++ /dev/null
@@ -1,1232 +0,0 @@
-
-
-
-DNS Operations                                                 M. Larson
-Internet-Draft                                                 P. Barber
-Expires: August 14, 2006                                        VeriSign
-                                                       February 10, 2006
-
-
-                  Observed DNS Resolution Misbehavior
-                    draft-ietf-dnsop-bad-dns-res-05
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on August 14, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This memo describes DNS iterative resolver behavior that results in a
-   significant query volume sent to the root and top-level domain (TLD)
-   name servers.  We offer implementation advice to iterative resolver
-   developers to alleviate these unnecessary queries.  The
-   recommendations made in this document are a direct byproduct of
-   observation and analysis of abnormal query traffic patterns seen at
-   two of the thirteen root name servers and all thirteen com/net TLD
-   name servers.
-
-
-
-Larson & Barber          Expires August 14, 2006                [Page 1]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [1].
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-     1.1.  A note about terminology in this memo  . . . . . . . . . .  3
-   2.  Observed iterative resolver misbehavior  . . . . . . . . . . .  5
-     2.1.  Aggressive requerying for delegation information . . . . .  5
-       2.1.1.  Recommendation . . . . . . . . . . . . . . . . . . . .  6
-     2.2.  Repeated queries to lame servers . . . . . . . . . . . . .  7
-       2.2.1.  Recommendation . . . . . . . . . . . . . . . . . . . .  7
-     2.3.  Inability to follow multiple levels of indirection . . . .  8
-       2.3.1.  Recommendation . . . . . . . . . . . . . . . . . . . .  9
-     2.4.  Aggressive retransmission when fetching glue . . . . . . .  9
-       2.4.1.  Recommendation . . . . . . . . . . . . . . . . . . . . 10
-     2.5.  Aggressive retransmission behind firewalls . . . . . . . . 10
-       2.5.1.  Recommendation . . . . . . . . . . . . . . . . . . . . 11
-     2.6.  Misconfigured NS records . . . . . . . . . . . . . . . . . 11
-       2.6.1.  Recommendation . . . . . . . . . . . . . . . . . . . . 12
-     2.7.  Name server records with zero TTL  . . . . . . . . . . . . 12
-       2.7.1.  Recommendation . . . . . . . . . . . . . . . . . . . . 13
-     2.8.  Unnecessary dynamic update messages  . . . . . . . . . . . 13
-       2.8.1.  Recommendation . . . . . . . . . . . . . . . . . . . . 14
-     2.9.  Queries for domain names resembling IPv4 addresses . . . . 14
-       2.9.1.  Recommendation . . . . . . . . . . . . . . . . . . . . 14
-     2.10. Misdirected recursive queries  . . . . . . . . . . . . . . 15
-       2.10.1. Recommendation . . . . . . . . . . . . . . . . . . . . 15
-     2.11. Suboptimal name server selection algorithm . . . . . . . . 15
-       2.11.1. Recommendation . . . . . . . . . . . . . . . . . . . . 16
-   3.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 17
-   4.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 18
-   5.  Security considerations  . . . . . . . . . . . . . . . . . . . 19
-   6.  Internationalization considerations  . . . . . . . . . . . . . 20
-   7.  Informative References . . . . . . . . . . . . . . . . . . . . 20
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
-   Intellectual Property and Copyright Statements . . . . . . . . . . 22
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber          Expires August 14, 2006                [Page 2]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-1.  Introduction
-
-   Observation of query traffic received by two root name servers and
-   the thirteen com/net TLD name servers has revealed that a large
-   proportion of the total traffic often consists of "requeries".  A
-   requery is the same question (<QNAME, QTYPE, QCLASS>) asked
-   repeatedly at an unexpectedly high rate.  We have observed requeries
-   from both a single IP address and multiple IP addresses (i.e., the
-   same query received simultaneously from multiple IP addresses).
-
-   By analyzing requery events we have found that the cause of the
-   duplicate traffic is almost always a deficient iterative resolver,
-   stub resolver or application implementation combined with an
-   operational anomaly.  The implementation deficiencies we have
-   identified to date include well-intentioned recovery attempts gone
-   awry, insufficient caching of failures, early abort when multiple
-   levels of indirection must be followed, and aggressive retry by stub
-   resolvers or applications.  Anomalies that we have seen trigger
-   requery events include lame delegations, unusual glue records, and
-   anything that makes all authoritative name servers for a zone
-   unreachable (DoS attacks, crashes, maintenance, routing failures,
-   congestion, etc.).
-
-   In the following sections, we provide a detailed explanation of the
-   observed behavior and recommend changes that will reduce the requery
-   rate.  None of the changes recommended affects the core DNS protocol
-   specification; instead, this document consists of guidelines to
-   implementors of iterative resolvers.
-
-1.1.  A note about terminology in this memo
-
-   To recast an old saying about standards, the nice thing about DNS
-   terms is that there are so many of them to choose from.  Writing or
-   talking about DNS can be difficult and cause confusion resulting from
-   a lack of agreed-upon terms for its various components.  Further
-   complicating matters are implementations that combine multiple roles
-   into one piece of software, which makes naming the result
-   problematic.  An example is the entity that accepts recursive
-   queries, issues iterative queries as necessary to resolve the initial
-   recursive query, caches responses it receives, and which is also able
-   to answer questions about certain zones authoritatively.  This entity
-   is an iterative resolver combined with an authoritative name server
-   and is often called a "recursive name server" or a "caching name
-   server".
-
-   This memo is concerned principally with the behavior of iterative
-   resolvers, which are typically found as part of a recursive name
-   server.  This memo uses the more precise term "iterative resolver",
-
-
-
-Larson & Barber          Expires August 14, 2006                [Page 3]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   because the focus is usually on that component.  In instances where
-   the name server role of this entity requires mentioning, this memo
-   uses the term "recursive name server".  As an example of the
-   difference, the name server component of a recursive name server
-   receives DNS queries and the iterative resolver component sends
-   queries.
-
-   The advent of IPv6 requires mentioning AAAA records as well as A
-   records when discussing glue.  To avoid continuous repetition and
-   qualification, this memo uses the general term "address record" to
-   encompass both A and AAAA records when a particular situation is
-   relevant to both types.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber          Expires August 14, 2006                [Page 4]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-2.  Observed iterative resolver misbehavior
-
-2.1.  Aggressive requerying for delegation information
-
-   There can be times when every name server in a zone's NS RRset is
-   unreachable (e.g., during a network outage), unavailable (e.g., the
-   name server process is not running on the server host) or
-   misconfigured (e.g., the name server is not authoritative for the
-   given zone, also known as "lame").  Consider an iterative resolver
-   that attempts to resolve a query for a domain name in such a zone and
-   discovers that none of the zone's name servers can provide an answer.
-   We have observed a recursive name server implementation whose
-   iterative resolver then verifies the zone's NS RRset in its cache by
-   querying for the zone's delegation information: it sends a query for
-   the zone's NS RRset to one of the parent zone's name servers.  (Note
-   that queries with QTYPE=NS are not required by the standard
-   resolution algorithm described in section 4.3.2 of RFC 1034 [2].
-   These NS queries represent this implementation's addition to that
-   algorithm.)
-
-   For example, suppose that "example.com" has the following NS RRset:
-
-     example.com.   IN   NS   ns1.example.com.
-     example.com.   IN   NS   ns2.example.com.
-
-   Upon receipt of a query for "www.example.com" and assuming that
-   neither "ns1.example.com" nor "ns2.example.com" can provide an
-   answer, this iterative resolver implementation immediately queries a
-   "com" zone name server for the "example.com" NS RRset to verify it
-   has the proper delegation information.  This implementation performs
-   this query to a zone's parent zone for each recursive query it
-   receives that fails because of a completely unresponsive set of name
-   servers for the target zone.  Consider the effect when a popular zone
-   experiences a catastrophic failure of all its name servers: now every
-   recursive query for domain names in that zone sent to this recursive
-   name server implementation results in a query to the failed zone's
-   parent name servers.  On one occasion when several dozen popular
-   zones became unreachable, the query load on the com/net name servers
-   increased by 50%.
-
-   We believe this verification query is not reasonable.  Consider the
-   circumstances: When an iterative resolver is resolving a query for a
-   domain name in a zone it has not previously searched, it uses the
-   list of name servers in the referral from the target zone's parent.
-   If on its first attempt to search the target zone, none of the name
-   servers in the referral is reachable, a verification query to the
-   parent would be pointless: this query to the parent would come so
-   quickly on the heels of the referral that it would be almost certain
-
-
-
-Larson & Barber          Expires August 14, 2006                [Page 5]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   to contain the same list of name servers.  The chance of discovering
-   any new information is slim.
-
-   The other possibility is that the iterative resolver successfully
-   contacts one of the target zone's name servers and then caches the NS
-   RRset from the authority section of a response, the proper behavior
-   according to section 5.4.1 of RFC 2181 [3], because the NS RRset from
-   the target zone is more trustworthy than delegation information from
-   the parent zone.  If, while processing a subsequent recursive query,
-   the iterative resolver discovers that none of the name servers
-   specified in the cached NS RRset is available or authoritative,
-   querying the parent would be wrong.  An NS RRset from the parent zone
-   would now be less trustworthy than data already in the cache.
-
-   For this query of the parent zone to be useful, the target zone's
-   entire set of name servers would have to change AND the former set of
-   name servers would have to be deconfigured or decommissioned AND the
-   delegation information in the parent zone would have to be updated
-   with the new set of name servers, all within the TTL of the target
-   zone's NS RRset.  We believe this scenario is uncommon:
-   administrative best practices dictate that changes to a zone's set of
-   name servers happen gradually when at all possible, with servers
-   removed from the NS RRset left authoritative for the zone as long as
-   possible.  The scenarios that we can envision that would benefit from
-   the parent requery behavior do not outweigh its damaging effects.
-
-   This section should not be understood to claim that all queries to a
-   zone's parent are bad.  In some cases, such queries are not only
-   reasonable but required.  Consider the situation when required
-   information, such as the address of a name server (i.e., the address
-   record corresponding to the RDATA of an NS record), has timed out of
-   an iterative resolver's cache before the corresponding NS record.  If
-   the name of the name server is below the apex of the zone, then the
-   name server's address record is only available as glue in the parent
-   zone.  For example, consider this NS record:
-
-     example.com.        IN   NS   ns.example.com.
-
-   If a cache has this NS record but not the address record for
-   "ns.example.com", it is unable to contact the "example.com" zone
-   directly and must query the "com" zone to obtain the address record.
-   Note, however, that such a query would not have QTYPE=NS according to
-   the standard resolution algorithm.
-
-2.1.1.  Recommendation
-
-   An iterative resolver MUST NOT send a query for the NS RRset of a
-   non-responsive zone to any of the name servers for that zone's parent
-
-
-
-Larson & Barber          Expires August 14, 2006                [Page 6]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   zone.  For the purposes of this injunction, a non-responsive zone is
-   defined as a zone for which every name server listed in the zone's NS
-   RRset:
-
-   1.  is not authoritative for the zone (i.e., lame), or,
-
-   2.  returns a server failure response (RCODE=2), or,
-
-   3.  is dead or unreachable according to section 7.2 of RFC 2308 [4].
-
-2.2.  Repeated queries to lame servers
-
-   Section 2.1 describes a catastrophic failure: when every name server
-   for a zone is unable to provide an answer for one reason or another.
-   A more common occurrence is when a subset of a zone's name servers
-   are unavailable or misconfigured.  Different failure modes have
-   different expected durations.  Some symptoms indicate problems that
-   are potentially transient; for example, various types of ICMP
-   unreachable messages because a name server process is not running or
-   a host or network is unreachable, or a complete lack of a response to
-   a query.  Such responses could be the result of a host rebooting or
-   temporary outages; these events don't necessarily require any human
-   intervention and can be reasonably expected to be temporary.
-
-   Other symptoms clearly indicate a condition requiring human
-   intervention, such as lame server: if a name server is misconfigured
-   and not authoritative for a zone delegated to it, it is reasonable to
-   assume that this condition has potential to last longer than
-   unreachability or unresponsiveness.  Consequently, repeated queries
-   to known lame servers are not useful.  In this case of a condition
-   with potential to persist for a long time, a better practice would be
-   to maintain a list of known lame servers and avoid querying them
-   repeatedly in a short interval.
-
-   It should also be noted, however, that some authoritative name server
-   implementations appear to be lame only for queries of certain types
-   as described in RFC 4074 [5].  In this case, it makes sense to retry
-   the "lame" servers for other types of queries, particularly when all
-   known authoritative name servers appear to be "lame".
-
-2.2.1.  Recommendation
-
-   Iterative resolvers SHOULD cache name servers that they discover are
-   not authoritative for zones delegated to them (i.e. lame servers).
-   If this caching is performed, lame servers MUST be cached against the
-   specific query tuple <zone name, class, server IP address>.  Zone
-   name can be derived from the owner name of the NS record that was
-   referenced to query the name server that was discovered to be lame.
-
-
-
-Larson & Barber          Expires August 14, 2006                [Page 7]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   Implementations that perform lame server caching MUST refrain from
-   sending queries to known lame servers based on a time interval from
-   when the server is discovered to be lame.  A minimum interval of
-   thirty minutes is RECOMMENDED.
-
-   An exception to this recommendation occurs if all name servers for a
-   zone are marked lame.  In that case, the iterative resolver SHOULD
-   temporarily ignore the servers' lameness status and query one or more
-   servers.  This behavior is a workaround for the type-specific
-   lameness issue described in the previous section.
-
-   Implementors should take care not to make lame server avoidance logic
-   overly broad: note that a name server could be lame for a parent zone
-   but not a child zone, e.g., lame for "example.com" but properly
-   authoritative for "sub.example.com".  Therefore a name server should
-   not be automatically considered lame for subzones.  In the case
-   above, even if a name server is known to be lame for "example.com",
-   it should be queried for QNAMEs at or below "sub.example.com" if an
-   NS record indicates it should be authoritative for that zone.
-
-2.3.  Inability to follow multiple levels of indirection
-
-   Some iterative resolver implementations are unable to follow
-   sufficient levels of indirection.  For example, consider the
-   following delegations:
-
-     foo.example.        IN   NS   ns1.example.com.
-     foo.example.        IN   NS   ns2.example.com.
-
-     example.com.        IN   NS   ns1.test.example.net.
-     example.com.        IN   NS   ns2.test.example.net.
-
-     test.example.net.   IN   NS   ns1.test.example.net.
-     test.example.net.   IN   NS   ns2.test.example.net.
-
-   An iterative resolver resolving the name "www.foo.example" must
-   follow two levels of indirection, first obtaining address records for
-   "ns1.test.example.net" or "ns2.test.example.net" in order to obtain
-   address records for "ns1.example.com" or "ns2.example.com" in order
-   to query those name servers for the address records of
-   "www.foo.example".  While this situation may appear contrived, we
-   have seen multiple similar occurrences and expect more as new generic
-   top-level domains (gTLDs) become active.  We anticipate many zones in
-   new gTLDs will use name servers in existing gTLDs, increasing the
-   number of delegations using out-of-zone name servers.
-
-
-
-
-
-
-Larson & Barber          Expires August 14, 2006                [Page 8]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-2.3.1.  Recommendation
-
-   Clearly constructing a delegation that relies on multiple levels of
-   indirection is not a good administrative practice.  However, the
-   practice is widespread enough to require that iterative resolvers be
-   able to cope with it.  Iterative resolvers SHOULD be able to handle
-   arbitrary levels of indirection resulting from out-of-zone name
-   servers.  Iterative resolvers SHOULD implement a level-of-effort
-   counter to avoid loops or otherwise performing too much work in
-   resolving pathological cases.
-
-   A best practice that avoids this entire issue of indirection is to
-   name one or more of a zone's name servers in the zone itself.  For
-   example, if the zone is named "example.com", consider naming some of
-   the name servers "ns{1,2,...}.example.com" (or similar).
-
-2.4.  Aggressive retransmission when fetching glue
-
-   When an authoritative name server responds with a referral, it
-   includes NS records in the authority section of the response.
-   According to the algorithm in section 4.3.2 of RFC 1034 [2], the name
-   server should also "put whatever addresses are available into the
-   additional section, using glue RRs if the addresses are not available
-   from authoritative data or the cache."  Some name server
-   implementations take this address inclusion a step further with a
-   feature called "glue fetching".  A name server that implements glue
-   fetching attempts to include address records for every NS record in
-   the authority section.  If necessary, the name server issues multiple
-   queries of its own to obtain any missing address records.
-
-   Problems with glue fetching can arise in the context of
-   "authoritative-only" name servers, which only serve authoritative
-   data and ignore requests for recursion.  Such an entity will not
-   normally generate any queries of its own.  Instead it answers non-
-   recursive queries from iterative resolvers looking for information in
-   zones it serves.  With glue fetching enabled, however, an
-   authoritative server invokes an iterative resolver to look up an
-   unknown address record to complete the additional section of a
-   response.
-
-   We have observed situations where the iterative resolver of a glue-
-   fetching name server can send queries that reach other name servers,
-   but is apparently prevented from receiving the responses.  For
-   example, perhaps the name server is authoritative-only and therefore
-   its administrators expect it to receive only queries and not
-   responses.  Perhaps unaware of glue fetching and presuming that the
-   name server's iterative resolver will generate no queries, its
-   administrators place the name server behind a network device that
-
-
-
-Larson & Barber          Expires August 14, 2006                [Page 9]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   prevents it from receiving responses.  If this is the case, all glue-
-   fetching queries will go answered.
-
-   We have observed name server implementations whose iterative
-   resolvers retry excessively when glue-fetching queries are
-   unanswered.  A single com/net name server has received hundreds of
-   queries per second from a single such source.  Judging from the
-   specific queries received and based on additional analysis, we
-   believe these queries result from overly aggressive glue fetching.
-
-2.4.1.  Recommendation
-
-   Implementers whose name servers support glue fetching SHOULD take
-   care to avoid sending queries at excessive rates.  Implementations
-   SHOULD support throttling logic to detect when queries are sent but
-   no responses are received.
-
-2.5.  Aggressive retransmission behind firewalls
-
-   A common occurrence and one of the largest sources of repeated
-   queries at the com/net and root name servers appears to result from
-   resolvers behind misconfigured firewalls.  In this situation, an
-   iterative resolver is apparently allowed to send queries through a
-   firewall to other name servers, but not receive the responses.  The
-   result is more queries than necessary because of retransmission, all
-   of which are useless because the responses are never received.  Just
-   as with the glue-fetching scenario described in Section 2.4, the
-   queries are sometimes sent at excessive rates.  To make matters
-   worse, sometimes the responses, sent in reply to legitimate queries,
-   trigger an alarm on the originator's intrusion detection system.  We
-   are frequently contacted by administrators responding to such alarms
-   who believe our name servers are attacking their systems.
-
-   Not only do some resolvers in this situation retransmit queries at an
-   excessive rate, but they continue to do so for days or even weeks.
-   This scenario could result from an organization with multiple
-   recursive name servers, only a subset of whose iterative resolvers'
-   traffic is improperly filtered in this manner.  Stub resolvers in the
-   organization could be configured to query multiple recursive name
-   servers.  Consider the case where a stub resolver queries a filtered
-   recursive name server first.  The iterative resolver of this
-   recursive name server sends one or more queries whose replies are
-   filtered, so it can't respond to the stub resolver, which times out.
-   Then the stub resolver retransmits to a recursive name server that is
-   able to provide an answer.  Since resolution ultimately succeeds the
-   underlying problem might not be recognized or corrected.  A popular
-   stub resolver implementation has a very aggressive retransmission
-   schedule, including simultaneous queries to multiple recursive name
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 10]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   servers, which could explain how such a situation could persist
-   without being detected.
-
-2.5.1.  Recommendation
-
-   The most obvious recommendation is that administrators SHOULD take
-   care not to place iterative resolvers behind a firewall that allows
-   queries to pass through but not the resulting replies.
-
-   Iterative resolvers SHOULD take care to avoid sending queries at
-   excessive rates.  Implementations SHOULD support throttling logic to
-   detect when queries are sent but no responses are received.
-
-2.6.  Misconfigured NS records
-
-   Sometimes a zone administrator forgets to add the trailing dot on the
-   domain names in the RDATA of a zone's NS records.  Consider this
-   fragment of the zone file for "example.com":
-
-     $ORIGIN example.com.
-     example.com.      3600   IN   NS   ns1.example.com  ; Note missing
-     example.com.      3600   IN   NS   ns2.example.com  ; trailing dots
-
-   The zone's authoritative servers will parse the NS RDATA as
-   "ns1.example.com.example.com" and "ns2.example.com.example.com" and
-   return NS records with this incorrect RDATA in responses, including
-   typically the authority section of every response containing records
-   from the "example.com" zone.
-
-   Now consider a typical sequence of queries.  An iterative resolver
-   attempting to resolve address records for "www.example.com" with no
-   cached information for this zone will query a "com" authoritative
-   server.  The "com" server responds with a referral to the
-   "example.com" zone, consisting of NS records with valid RDATA and
-   associated glue records.  (This example assumes that the
-   "example.com" zone delegation information is correct in the "com"
-   zone.)  The iterative resolver caches the NS RRset from the "com"
-   server and follows the referral by querying one of the "example.com"
-   authoritative servers.  This server responds with the
-   "www.example.com" address record in the answer section and,
-   typically, the "example.com" NS records in the authority section and,
-   if space in the message remains, glue address records in the
-   additional section.  According to Section 5.4 of RFC 2181 [3], NS
-   records in the authority section of an authoritative answer are more
-   trustworthy than NS records from the authority section of a non-
-   authoritative answer.  Thus the "example.com" NS RRset just received
-   from the "example.com" authoritative server overrides the
-   "example.com" NS RRset received moments ago from the "com"
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 11]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   authoritative server.
-
-   But the "example.com" zone contains the erroneous NS RRset as shown
-   in the example above.  Subsequent queries for names in "example.com"
-   will cause the iterative resolver to attempt to use the incorrect NS
-   records and so it will try to resolve the nonexistent names
-   "ns1.example.com.example.com" and "ns2.example.com.example.com".  In
-   this example, since all of the zone's name servers are named in the
-   zone itself (i.e., "ns1.example.com.example.com" and
-   "ns2.example.com.example.com" both end in "example.com") and all are
-   bogus, the iterative resolver cannot reach any "example.com" name
-   servers.  Therefore attempts to resolve these names result in address
-   record queries to the "com" authoritative servers.  Queries for such
-   obviously bogus glue address records occur frequently at the com/net
-   name servers.
-
-2.6.1.  Recommendation
-
-   An authoritative server can detect this situation.  A trailing dot
-   missing from an NS record's RDATA always results by definition in a
-   name server name that exists somewhere under the apex of the zone the
-   NS record appears in.  Note that further levels of delegation are
-   possible, so a missing trailing dot could inadvertently create a name
-   server name that actually exists in a subzone.
-
-   An authoritative name server SHOULD issue a warning when one of a
-   zone's NS records references a name server below the zone's apex when
-   a corresponding address record does not exist in the zone AND there
-   are no delegated subzones where the address record could exist.
-
-2.7.  Name server records with zero TTL
-
-   Sometimes a popular com/net subdomain's zone is configured with a TTL
-   of zero on the zone's NS records, which prohibits these records from
-   being cached and will result in a higher query volume to the zone's
-   authoritative servers.  The zone's administrator should understand
-   the consequences of such a configuration and provision resources
-   accordingly.  A zero TTL on the zone's NS RRset, however, carries
-   additional consequences beyond the zone itself: if an iterative
-   resolver cannot cache a zone's NS records because of a zero TTL, it
-   will be forced to query that zone's parent's name servers each time
-   it resolves a name in the zone.  The com/net authoritative servers do
-   see an increased query load when a popular com/net subdomain's zone
-   is configured with a TTL of zero on the zone's NS records.
-
-   A zero TTL on an RRset expected to change frequently is extreme but
-   permissible.  A zone's NS RRset is a special case, however, because
-   changes to it must be coordinated with the zone's parent.  In most
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 12]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   zone parent/child relationships we are aware of, there is typically
-   some delay involved in effecting changes.  Further, changes to the
-   set of a zone's authoritative name servers (and therefore to the
-   zone's NS RRset) are typically relatively rare: providing reliable
-   authoritative service requires a reasonably stable set of servers.
-   Therefore an extremely low or zero TTL on a zone's NS RRset rarely
-   makes sense, except in anticipation of an upcoming change.  In this
-   case, when the zone's administrator has planned a change and does not
-   want iterative resolvers throughout the Internet to cache the NS
-   RRset for a long period of time, a low TTL is reasonable.
-
-2.7.1.  Recommendation
-
-   Because of the additional load placed on a zone's parent's
-   authoritative servers resulting from a zero TTL on a zone's NS RRset,
-   under such circumstances authoritative name servers SHOULD issue a
-   warning when loading a zone.
-
-2.8.  Unnecessary dynamic update messages
-
-   The UPDATE message specified in RFC 2136 [6] allows an authorized
-   agent to update a zone's data on an authoritative name server using a
-   DNS message sent over the network.  Consider the case of an agent
-   desiring to add a particular resource record.  Because of zone cuts,
-   the agent does not necessarily know the proper zone to which the
-   record should be added.  The dynamic update process requires that the
-   agent determine the appropriate zone so the UPDATE message can be
-   sent to one of the zone's authoritative servers (typically the
-   primary master as specified in the zone's SOA MNAME field).
-
-   The appropriate zone to update is the closest enclosing zone, which
-   cannot be determined only by inspecting the domain name of the record
-   to be updated, since zone cuts can occur anywhere.  One way to
-   determine the closest enclosing zone entails walking up the name
-   space tree by sending repeated UPDATE messages until success.  For
-   example, consider an agent attempting to add an address record with
-   the name "foo.bar.example.com".  The agent could first attempt to
-   update the "foo.bar.example.com" zone.  If the attempt failed, the
-   update could be directed to the "bar.example.com" zone, then the
-   "example.com" zone, then the "com" zone, and finally the root zone.
-
-   A popular dynamic agent follows this algorithm.  The result is many
-   UPDATE messages received by the root name servers, the com/net
-   authoritative servers, and presumably other TLD authoritative
-   servers.  A valid question is why the algorithm proceeds to send
-   updates all the way to TLD and root name servers.  This behavior is
-   not entirely unreasonable: in enterprise DNS architectures with an
-   "internal root" design, there could conceivably be private, non-
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 13]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   public TLD or root zones that would be the appropriate targets for a
-   dynamic update.
-
-   A significant deficiency with this algorithm is that knowledge of a
-   given UPDATE message's failure is not helpful in directing future
-   UPDATE messages to the appropriate servers.  A better algorithm would
-   be to find the closest enclosing zone by walking up the name space
-   with queries for SOA or NS rather than "probing" with UPDATE
-   messages.  Once the appropriate zone is found, an UPDATE message can
-   be sent.  In addition, the results of these queries can be cached to
-   aid in determining closest enclosing zones for future updates.  Once
-   the closest enclosing zone is determined with this method, the update
-   will either succeed or fail and there is no need to send further
-   updates to higher-level zones.  The important point is that walking
-   up the tree with queries yields cacheable information, whereas
-   walking up the tree by sending UPDATE messages does not.
-
-2.8.1.  Recommendation
-
-   Dynamic update agents SHOULD send SOA or NS queries to progressively
-   higher-level names to find the closest enclosing zone for a given
-   name to update.  Only after the appropriate zone is found should the
-   client send an UPDATE message to one of the zone's authoritative
-   servers.  Update clients SHOULD NOT "probe" using UPDATE messages by
-   walking up the tree to progressively higher-level zones.
-
-2.9.  Queries for domain names resembling IPv4 addresses
-
-   The root name servers receive a significant number of A record
-   queries where the QNAME looks like an IPv4 address.  The source of
-   these queries is unknown.  It could be attributed to situations where
-   a user believes an application will accept either a domain name or an
-   IP address in a given configuration option.  The user enters an IP
-   address, but the application assumes any input is a domain name and
-   attempts to resolve it, resulting in an A record lookup.  There could
-   also be applications that produce such queries in a misguided attempt
-   to reverse map IP addresses.
-
-   These queries result in Name Error (RCODE=3) responses.  An iterative
-   resolver can negatively cache such responses, but each response
-   requires a separate cache entry, i.e., a negative cache entry for the
-   domain name "192.0.2.1" does not prevent a subsequent query for the
-   domain name "192.0.2.2".
-
-2.9.1.  Recommendation
-
-   It would be desirable for the root name servers not to have to answer
-   these queries: they unnecessarily consume CPU resources and network
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 14]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   bandwidth.  A possible solution is to delegate these numeric TLDs
-   from the root zone to a separate set of servers to absorb the
-   traffic.  The "black hole servers" used by the AS 112 Project [8],
-   which are currently delegated the in-addr.arpa zones corresponding to
-   RFC 1918 [7] private use address space, would be a possible choice to
-   receive these delegations.  Of course, the proper and usual root zone
-   change procedures would have to be followed to make such a change to
-   the root zone.
-
-2.10.  Misdirected recursive queries
-
-   The root name servers receive a significant number of recursive
-   queries (i.e., queries with the RD bit set in the header).  Since
-   none of the root servers offers recursion, the servers' response in
-   such a situation ignores the request for recursion and the response
-   probably does not contain the data the querier anticipated.  Some of
-   these queries result from users configuring stub resolvers to query a
-   root server.  (This situation is not hypothetical: we have received
-   complaints from users when this configuration does not work as
-   hoped.)  Of course, users should not direct stub resolvers to use
-   name servers that do not offer recursion, but we are not aware of any
-   stub resolver implementation that offers any feedback to the user
-   when so configured, aside from simply "not working".
-
-2.10.1.  Recommendation
-
-   When the IP address of a name server that supposedly offers recursion
-   is configured in a stub resolver using an interactive user interface,
-   the resolver could send a test query to verify that the server indeed
-   supports recursion (i.e., verify that the response has the RA bit set
-   in the header).  The user could be immediately notified if the server
-   is non-recursive.
-
-   The stub resolver could also report an error, either through a user
-   interface or in a log file, if the queried server does not support
-   recursion.  Error reporting SHOULD be throttled to avoid a
-   notification or log message for every response from a non-recursive
-   server.
-
-2.11.  Suboptimal name server selection algorithm
-
-   An entire document could be devoted to the topic of problems with
-   different implementations of the recursive resolution algorithm.  The
-   entire process of recursion is woefully under specified, requiring
-   each implementor to design an algorithm.  Sometimes implementors make
-   poor design choices that could be avoided if a suggested algorithm
-   and best practices were documented, but that is a topic for another
-   document.
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 15]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   Some deficiencies cause significant operational impact and are
-   therefore worth mentioning here.  One of these is name server
-   selection by an iterative resolver.  When an iterative resolver wants
-   to contact one of a zone's authoritative name servers, how does it
-   choose from the NS records listed in the zone's NS RRset?  If the
-   selection mechanism is suboptimal, queries are not spread evenly
-   among a zone's authoritative servers.  The details of the selection
-   mechanism are up to the implementor, but we offer some suggestions.
-
-2.11.1.  Recommendation
-
-   This list is not conclusive, but reflects the changes that would
-   produce the most impact in terms of reducing disproportionate query
-   load among a zone's authoritative servers.  I.e., these changes would
-   help spread the query load evenly.
-
-   o  Do not make assumptions based on NS RRset order: all NS RRs SHOULD
-      be treated equally.  (In the case of the "com" zone, for example,
-      most of the root servers return the NS record for "a.gtld-
-      servers.net" first in the authority section of referrals.
-      Apparently as a result, this server receives disproportionately
-      more traffic than the other 12 authoritative servers for "com".)
-
-   o  Use all NS records in an RRset.  (For example, we are aware of
-      implementations that hard-coded information for a subset of the
-      root servers.)
-
-   o  Maintain state and favor the best-performing of a zone's
-      authoritative servers.  A good definition of performance is
-      response time.  Non-responsive servers can be penalized with an
-      extremely high response time.
-
-   o  Do not lock onto the best-performing of a zone's name servers.  An
-      iterative resolver SHOULD periodically check the performance of
-      all of a zone's name servers to adjust its determination of the
-      best-performing one.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 16]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-3.  Acknowledgments
-
-   The authors would like to thank the following people for their
-   comments that improved this document: Andras Salamon, Dave Meyer,
-   Doug Barton, Jaap Akkerhuis, Jinmei Tatuya, John Brady, Kevin Darcy,
-   Olafur Gudmundsson, Pekka Savola, Peter Koch and Rob Austein.  We
-   apologize if we have omitted anyone; any oversight was unintentional.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 17]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-4.  IANA considerations
-
-   There are no new IANA considerations introduced by this memo.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 18]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-5.  Security considerations
-
-   The iterative resolver misbehavior discussed in this document exposes
-   the root and TLD name servers to increased risk of both intentional
-   and unintentional denial of service attacks.
-
-   We believe that implementation of the recommendations offered in this
-   document will reduce the amount of unnecessary traffic seen at root
-   and TLD name servers, thus reducing the opportunity for an attacker
-   to use such queries to his or her advantage.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 19]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-6.  Internationalization considerations
-
-   There are no new internationalization considerations introduced by
-   this memo.
-
-7.  Informative References
-
-   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [2]  Mockapetris, P., "Domain names - concepts and facilities",
-        STD 13, RFC 1034, November 1987.
-
-   [3]  Elz, R. and R. Bush, "Clarifications to the DNS Specification",
-        RFC 2181, July 1997.
-
-   [4]  Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
-        RFC 2308, March 1998.
-
-   [5]  Morishita, Y. and T. Jinmei, "Common Misbehavior Against DNS
-        Queries for IPv6 Addresses", RFC 4074, May 2005.
-
-   [6]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic
-        Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
-        April 1997.
-
-   [7]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E.
-        Lear, "Address Allocation for Private Internets", BCP 5,
-        RFC 1918, February 1996.
-
-   [8]  <http://www.as112.net>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 20]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-Authors' Addresses
-
-   Matt Larson
-   VeriSign, Inc.
-   21345 Ridgetop Circle
-   Dulles, VA  20166-6503
-   USA
-
-   Email: mlarson@verisign.com
-
-
-   Piet Barber
-   VeriSign, Inc.
-   21345 Ridgetop Circle
-   Dulles, VA  20166-6503
-   USA
-
-   Email: pbarber@verisign.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 21]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 22]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-08.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-08.txt
deleted file mode 100644
index 8ca68a8..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-08.txt
+++ /dev/null
@@ -1,2016 +0,0 @@
-
-
-
-DNSOP                                                         O. Kolkman
-Internet-Draft                                                 R. Gieben
-Obsoletes: 2541 (if approved)                                 NLnet Labs
-Expires: September 7, 2006                                 March 6, 2006
-
-
-                      DNSSEC Operational Practices
-          draft-ietf-dnsop-dnssec-operational-practices-08.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on September 7, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document describes a set of practices for operating the DNS with
-   security extensions (DNSSEC).  The target audience is zone
-   administrators deploying DNSSEC.
-
-   The document discusses operational aspects of using keys and
-   signatures in the DNS.  It discusses issues as key generation, key
-   storage, signature generation, key rollover and related policies.
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006               [Page 1]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   This document obsoletes RFC 2541, as it covers more operational
-   ground and gives more up to date requirements with respect to key
-   sizes and the new DNSSEC specification.
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
-     1.1.  The Use of the Term 'key'  . . . . . . . . . . . . . . . .  4
-     1.2.  Time Definitions . . . . . . . . . . . . . . . . . . . . .  5
-   2.  Keeping the Chain of Trust Intact  . . . . . . . . . . . . . .  5
-   3.  Keys Generation and Storage  . . . . . . . . . . . . . . . . .  6
-     3.1.  Zone and Key Signing Keys  . . . . . . . . . . . . . . . .  6
-       3.1.1.  Motivations for the KSK and ZSK Separation . . . . . .  7
-       3.1.2.  KSKs for High Level Zones  . . . . . . . . . . . . . .  8
-     3.2.  Key Generation . . . . . . . . . . . . . . . . . . . . . .  8
-     3.3.  Key Effectivity Period . . . . . . . . . . . . . . . . . .  9
-     3.4.  Key Algorithm  . . . . . . . . . . . . . . . . . . . . . .  9
-     3.5.  Key Sizes  . . . . . . . . . . . . . . . . . . . . . . . . 10
-     3.6.  Private Key Storage  . . . . . . . . . . . . . . . . . . . 12
-   4.  Signature generation, Key Rollover and Related Policies  . . . 12
-     4.1.  Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . 12
-       4.1.1.  Time Considerations  . . . . . . . . . . . . . . . . . 13
-     4.2.  Key Rollovers  . . . . . . . . . . . . . . . . . . . . . . 14
-       4.2.1.  Zone Signing Key Rollovers . . . . . . . . . . . . . . 15
-       4.2.2.  Key Signing Key Rollovers  . . . . . . . . . . . . . . 19
-       4.2.3.  Difference Between ZSK and KSK Rollovers . . . . . . . 20
-       4.2.4.  Automated Key Rollovers  . . . . . . . . . . . . . . . 21
-     4.3.  Planning for Emergency Key Rollover  . . . . . . . . . . . 22
-       4.3.1.  KSK Compromise . . . . . . . . . . . . . . . . . . . . 22
-       4.3.2.  ZSK Compromise . . . . . . . . . . . . . . . . . . . . 24
-       4.3.3.  Compromises of Keys Anchored in Resolvers  . . . . . . 24
-     4.4.  Parental Policies  . . . . . . . . . . . . . . . . . . . . 24
-       4.4.1.  Initial Key Exchanges and Parental Policies
-               Considerations . . . . . . . . . . . . . . . . . . . . 24
-       4.4.2.  Storing Keys or Hashes?  . . . . . . . . . . . . . . . 25
-       4.4.3.  Security Lameness  . . . . . . . . . . . . . . . . . . 25
-       4.4.4.  DS Signature Validity Period . . . . . . . . . . . . . 26
-   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 26
-   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 27
-   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 27
-   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
-     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 27
-     8.2.  Informative References . . . . . . . . . . . . . . . . . . 28
-   Appendix A.  Terminology . . . . . . . . . . . . . . . . . . . . . 29
-   Appendix B.  Zone Signing Key Rollover Howto . . . . . . . . . . . 30
-   Appendix C.  Typographic Conventions . . . . . . . . . . . . . . . 31
-   Appendix D.  Document Details and Changes  . . . . . . . . . . . . 33
-
-
-
-Kolkman & Gieben        Expires September 7, 2006               [Page 2]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-     D.1.  draft-ietf-dnsop-dnssec-operational-practices-00 . . . . . 33
-     D.2.  draft-ietf-dnsop-dnssec-operational-practices-01 . . . . . 33
-     D.3.  draft-ietf-dnsop-dnssec-operational-practices-02 . . . . . 33
-     D.4.  draft-ietf-dnsop-dnssec-operational-practices-03 . . . . . 33
-     D.5.  draft-ietf-dnsop-dnssec-operational-practices-04 . . . . . 34
-     D.6.  draft-ietf-dnsop-dnssec-operational-practices-05 . . . . . 34
-     D.7.  draft-ietf-dnsop-dnssec-operational-practices-06 . . . . . 34
-     D.8.  draft-ietf-dnsop-dnssec-operational-practices-07 . . . . . 34
-     D.9.  draft-ietf-dnsop-dnssec-operational-practices-08 . . . . . 34
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
-   Intellectual Property and Copyright Statements . . . . . . . . . . 36
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006               [Page 3]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-1.  Introduction
-
-   This document describes how to run a DNSSEC (DNS SECure) enabled
-   environment.  It is intended for operators who have knowledge of the
-   DNS (see RFC 1034 [1] and RFC 1035 [2]) and want deploy DNSSEC.  See
-   RFC 4033 [4] for an introduction into DNSSEC and RFC 4034 [5] for the
-   newly introduced Resource Records and finally RFC 4035 [6] for the
-   protocol changes.
-
-   During workshops and early operational deployment tests, operators
-   and system administrators have gained experience about operating the
-   DNS with security extensions (DNSSEC).  This document translates
-   these experiences into a set of practices for zone administrators.
-   At the time of writing, there exists very little experience with
-   DNSSEC in production environments; this document should therefore
-   explicitly not be seen as representing 'Best Current Practices'.
-
-   The procedures herein are focused on the maintenance of signed zones
-   (i.e. signing and publishing zones on authoritative servers).  It is
-   intended that maintenance of zones such as re-signing or key
-   rollovers be transparent to any verifying clients on the Internet.
-
-   The structure of this document is as follows.  In Section 2 we
-   discuss the importance of keeping the "chain of trust" intact.
-   Aspects of key generation and storage of private keys are discussed
-   in Section 3; the focus in this section is mainly on the private part
-   of the key(s).  Section 4 describes considerations concerning the
-   public part of the keys.  Since these public keys appear in the DNS
-   one has to take into account all kinds of timing issues, which are
-   discussed in Section 4.1.  Section 4.2 and Section 4.3 deal with the
-   rollover, or supercession, of keys.  Finally Section 4.4 discusses
-   considerations on how parents deal with their children's public keys
-   in order to maintain chains of trust.
-
-   The typographic conventions used in this document are explained in
-   Appendix C.
-
-   Since this is a document with operational suggestions and there are
-   no protocol specifications, the RFC 2119 [9] language does not apply.
-
-   This document obsoletes RFC 2541 [12].
-
-1.1.  The Use of the Term 'key'
-
-   It is assumed that the reader is familiar with the concept of
-   asymmetric keys on which DNSSEC is based (Public Key Cryptography
-   [18]).  Therefore, this document will use the term 'key' rather
-   loosely.  Where it is written that 'a key is used to sign data' it is
-
-
-
-Kolkman & Gieben        Expires September 7, 2006               [Page 4]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   assumed that the reader understands that it is the private part of
-   the key pair that is used for signing.  It is also assumed that the
-   reader understands that the public part of the key pair is published
-   in the DNSKEY resource record and that it is the public part that is
-   used in key exchanges.
-
-1.2.  Time Definitions
-
-   In this document we will be using a number of time related terms.
-   The following definitions apply:
-   o  "Signature validity period"
-         The period that a signature is valid.  It starts at the time
-         specified in the signature inception field of the RRSIG RR and
-         ends at the time specified in the expiration field of the RRSIG
-         RR.
-   o  "Signature publication period"
-         Time after which a signature (made with a specific key) is
-         replaced with a new signature (made with the same key).  This
-         replacement takes place by publishing the relevant RRSIG in the
-         master zone file.
-         After one stops publishing an RRSIG in a zone it may take a
-         while before the RRSIG has expired from caches and has actually
-         been removed from the DNS.
-   o  "Key effectivity period"
-         The period during which a key pair is expected to be effective.
-         This period is defined as the time between the first inception
-         time stamp and the last expiration date of any signature made
-         with this key, regardless of any discontinuity in the use of
-         the key.
-         The key effectivity period can span multiple signature validity
-         periods.
-   o  "Maximum/Minimum Zone Time to Live (TTL)"
-         The maximum or minimum value of the TTLs from the complete set
-         of RRs in a zone.  Note that the minimum TTL is not the same as
-         the MINIMUM field in the SOA RR.  See [11] for more
-         information.
-
-
-2.  Keeping the Chain of Trust Intact
-
-   Maintaining a valid chain of trust is important because broken chains
-   of trust will result in data being marked as Bogus (as defined in [4]
-   section 5), which may cause entire (sub)domains to become invisible
-   to verifying clients.  The administrators of secured zones have to
-   realize that their zone is, to verifying clients, part of a chain of
-   trust.
-
-   As mentioned in the introduction, the procedures herein are intended
-
-
-
-Kolkman & Gieben        Expires September 7, 2006               [Page 5]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   to ensure that maintenance of zones, such as re-signing or key
-   rollovers, will be transparent to the verifying clients on the
-   Internet.
-
-   Administrators of secured zones will have to keep in mind that data
-   published on an authoritative primary server will not be immediately
-   seen by verifying clients; it may take some time for the data to be
-   transferred to other secondary authoritative nameservers and clients
-   may be fetching data from caching non-authoritative servers.  In this
-   light it is good to note that the time for a zone transfer from
-   master to slave is negligible when using NOTIFY [8] and IXFR [7],
-   increasing by reliance on AXFR, and more if you rely on the SOA
-   timing parameters for zone refresh.
-
-   For the verifying clients it is important that data from secured
-   zones can be used to build chains of trust regardless of whether the
-   data came directly from an authoritative server, a caching nameserver
-   or some middle box.  Only by carefully using the available timing
-   parameters can a zone administrator assure that the data necessary
-   for verification can be obtained.
-
-   The responsibility for maintaining the chain of trust is shared by
-   administrators of secured zones in the chain of trust.  This is most
-   obvious in the case of a 'key compromise' when a trade off between
-   maintaining a valid chain of trust and replacing the compromised keys
-   as soon as possible must be made.  Then zone administrators will have
-   to make a trade off, between keeping the chain of trust intact -
-   thereby allowing for attacks with the compromised key - or to
-   deliberately break the chain of trust and making secured sub domains
-   invisible to security aware resolvers.  Also see Section 4.3.
-
-
-3.  Keys Generation and Storage
-
-   This section describes a number of considerations with respect to the
-   security of keys.  It deals with the generation, effectivity period,
-   size and storage of private keys.
-
-3.1.  Zone and Key Signing Keys
-
-   The DNSSEC validation protocol does not distinguish between different
-   types of DNSKEYs.  All DNSKEYs can be used during the validation.  In
-   practice operators use Key Signing and Zone Signing Keys and use the
-   so-called (Secure Entry Point) SEP [3] flag to distinguish between
-   them during operations.  The dynamics and considerations are
-   discussed below.
-
-   To make zone re-signing and key rollover procedures easier to
-
-
-
-Kolkman & Gieben        Expires September 7, 2006               [Page 6]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   implement, it is possible to use one or more keys as Key Signing Keys
-   (KSK).  These keys will only sign the apex DNSKEY RRSet in a zone.
-   Other keys can be used to sign all the RRSets in a zone and are
-   referred to as Zone Signing Keys (ZSK).  In this document we assume
-   that KSKs are the subset of keys that are used for key exchanges with
-   the parent and potentially for configuration as trusted anchors - the
-   SEP keys.  In this document we assume a one-to-one mapping between
-   KSK and SEP keys and we assume the SEP flag to be set on all KSKs.
-
-3.1.1.  Motivations for the KSK and ZSK Separation
-
-   Differentiating between the KSK and ZSK functions has several
-   advantages:
-
-   o  No parent/child interaction is required when ZSKs are updated.
-   o  The KSK can be made stronger (i.e. using more bits in the key
-      material).  This has little operational impact since it is only
-      used to sign a small fraction of the zone data.  Also the KSK is
-      only used to verify the zone's key set, not for other RRSets in
-      the zone.
-   o  As the KSK is only used to sign a key set, which is most probably
-      updated less frequently than other data in the zone, it can be
-      stored separately from and in a safer location than the ZSK.
-   o  A KSK can have a longer key effectivity period.
-
-   For almost any method of key management and zone signing the KSK is
-   used less frequently than the ZSK.  Once a key set is signed with the
-   KSK all the keys in the key set can be used as ZSK.  If a ZSK is
-   compromised, it can be simply dropped from the key set.  The new key
-   set is then re-signed with the KSK.
-
-   Given the assumption that for KSKs the SEP flag is set, the KSK can
-   be distinguished from a ZSK by examining the flag field in the DNSKEY
-   RR.  If the flag field is an odd number it is a KSK.  If it is an
-   even number it is a ZSK.
-
-   The zone signing key can be used to sign all the data in a zone on a
-   regular basis.  When a zone signing key is to be rolled, no
-   interaction with the parent is needed.  This allows for "Signature
-   Validity Periods" on the order of days.
-
-   The key signing key is only to be used to sign the DNSKEY RRs in a
-   zone.  If a key signing key is to be rolled over, there will be
-   interactions with parties other than the zone administrator.  These
-   can include the registry of the parent zone or administrators of
-   verifying resolvers that have the particular key configured as secure
-   entry points.  Hence, the key effectivity period of these keys can
-   and should be made much longer.  Although, given a long enough key,
-
-
-
-Kolkman & Gieben        Expires September 7, 2006               [Page 7]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   the Key Effectivity Period can be on the order of years we suggest
-   planning for a key effectivity of the order of a few months so that a
-   key rollover remains an operational routine.
-
-3.1.2.  KSKs for High Level Zones
-
-   Higher level zones are generally more sensitive than lower level
-   zones.  Anyone controlling or breaking the security of a zone thereby
-   obtains authority over all of its sub domains (except in the case of
-   resolvers that have locally configured the public key of a sub
-   domain, in which case this, and only this, sub domain wouldn't be
-   affected by the compromise of the parent zone).  Therefore, extra
-   care should be taken with high level zones and strong keys should
-   used.
-
-   The root zone is the most critical of all zones.  Someone controlling
-   or compromising the security of the root zone would control the
-   entire DNS name space of all resolvers using that root zone (except
-   in the case of resolvers that have locally configured the public key
-   of a sub domain).  Therefore, the utmost care must be taken in the
-   securing of the root zone.  The strongest and most carefully handled
-   keys should be used.  The root zone private key should always be kept
-   off line.
-
-   Many resolvers will start at a root server for their access to and
-   authentication of DNS data.  Securely updating the trust anchors in
-   an enormous population of resolvers around the world will be
-   extremely difficult.
-
-3.2.  Key Generation
-
-   Careful generation of all keys is a sometimes overlooked but
-   absolutely essential element in any cryptographically secure system.
-   The strongest algorithms used with the longest keys are still of no
-   use if an adversary can guess enough to lower the size of the likely
-   key space so that it can be exhaustively searched.  Technical
-   suggestions for the generation of random keys will be found in RFC
-   4086 [15].  One should carefully assess if the random number
-   generator used during key generation adheres to these suggestions.
-
-   Keys with a long effectivity period are particularly sensitive as
-   they will represent a more valuable target and be subject to attack
-   for a longer time than short period keys.  It is strongly recommended
-   that long term key generation occur off-line in a manner isolated
-   from the network via an air gap or, at a minimum, high level secure
-   hardware.
-
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006               [Page 8]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-3.3.  Key Effectivity Period
-
-   For various reasons keys in DNSSEC need to be changed once in a
-   while.  The longer a key is in use, the greater the probability that
-   it will have been compromised through carelessness, accident,
-   espionage, or cryptanalysis.  Furthermore when key rollovers are too
-   rare an event, they will not become part of the operational habit and
-   there is risk that nobody on-site will remember the procedure for
-   rollover when the need is there.
-
-   From a purely operational perspective a reasonable key effectivity
-   period for Key Signing Keys is 13 months, with the intent to replace
-   them after 12 months.  An intended key effectivity period of a month
-   is reasonable for Zone Signing Keys.
-
-   For key sizes that matches these effectivity periods see Section 3.5.
-
-   As argued in Section 3.1.2 securely updating trust anchors will be
-   extremely difficult.  On the other hand the "operational habit"
-   argument does also apply to trust anchor reconfiguration.  If a short
-   key-effectivity period is used and the trust anchor configuration has
-   to be revisited on a regular basis the odds that the configuration
-   tends to be forgotten is smaller.  The trade-off is against a system
-   that is so dynamic that administrators of the validating clients will
-   not be able to follow the modifications.
-
-   Key effectivity periods can be made very short, as in the order of a
-   few minutes.  But when replacing keys one has to take the
-   considerations from Section 4.1 and Section 4.2 into account.
-
-3.4.  Key Algorithm
-
-   There are currently three different types of algorithms that can be
-   used in DNSSEC: RSA, DSA and elliptic curve cryptography.  The latter
-   is fairly new and has yet to be standardized for usage in DNSSEC.
-
-   RSA has been developed in an open and transparent manner.  As the
-   patent on RSA expired in 2000, its use is now also free.
-
-   DSA has been developed by NIST.  The creation of signatures takes
-   roughly the same time as with RSA, but is 10 to 40 times as slow for
-   verification [18].
-
-   We suggest the use of RSA/SHA-1 as the preferred algorithm for the
-   key.  The current known attacks on RSA can be defeated by making your
-   key longer.  As the MD5 hashing algorithm is showing (theoretical)
-   cracks, we recommend the usage of SHA-1.
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006               [Page 9]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   At the time of publication it is known that the SHA-1 hash has
-   cryptanalysis issues.  There is work in progress on addressing these
-   issues.  We recommend the use of public key algorithms based on
-   hashes stronger than SHA-1, e.g.  SHA-256, as soon as these
-   algorithms are available in protocol specifications (See [20] and
-   [21] ) and implementations.
-
-3.5.  Key Sizes
-
-   When choosing key sizes, zone administrators will need to take into
-   account how long a key will be used, how much data will be signed
-   during the key publication period (See Section 8.10 of [18]) and,
-   optionally, how large the key size of the parent is.  As the chain of
-   trust really is "a chain", there is not much sense in making one of
-   the keys in the chain several times larger then the others.  As
-   always, it's the weakest link that defines the strength of the entire
-   chain.  Also see Section 3.1.1 for a discussion of how keys serving
-   different roles (ZSK v.  KSK) may need different key sizes.
-
-   Generating a key of the correct size is a difficult problem, RFC 3766
-   [14] tries to deal with that problem.  The first part of the
-   selection procedure in Section 1 of the RFC states:
-
-      1. Determine the attack resistance necessary to satisfy the
-         security requirements of the application.  Do this by
-         estimating the minimum number of computer operations that
-         the attacker will be forced to do in order to compromise
-         the security of the system and then take the logarithm base
-         two of that number.  Call that logarithm value "n".
-
-         A 1996 report recommended 90 bits as a good all-around choice
-         for system security.  The 90 bit number should be increased
-         by about 2/3 bit/year, or about 96 bits in 2005.
-
-   [14] goes on to explain how this number "n" can be used to calculate
-   the key sizes in public key cryptography.  This culminated in the
-   table given below (slightly modified for our purpose):
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 10]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-      +-------------+-----------+--------------+
-      | System      |           |              |
-      | requirement | Symmetric | RSA or DSA   |
-      | for attack  | key size  | modulus size |
-      | resistance  | (bits)    | (bits)       |
-      | (bits)      |           |              |
-      +-------------+-----------+--------------+
-      |     70      |     70    |      947     |
-      |     80      |     80    |     1228     |
-      |     90      |     90    |     1553     |
-      |    100      |    100    |     1926     |
-      |    150      |    150    |     4575     |
-      |    200      |    200    |     8719     |
-      |    250      |    250    |    14596     |
-      +-------------+-----------+--------------+
-
-   The key sizes given are rather large.  This is because these keys are
-   resilient against a trillionaire attacker.  Assuming this rich
-   attacker will not attack your key and that the key is rolled over
-   once a year, we come to the following recommendations about KSK
-   sizes; 1024 bits low value domains, 1300 for medium value and 2048
-   for the high value domains.
-
-   Whether a domain is of low, medium, high value depends solely on the
-   views of the zone owner.  One could for instance view leaf nodes in
-   the DNS as of low value and TLDs or the root zone of high value.  The
-   suggested key sizes should be safe for the next 5 years.
-
-   As ZSKs can be rolled over more easily (and thus more often) the key
-   sizes can be made smaller.  But as said in the introduction of this
-   paragraph, making the ZSKs' key sizes too small (in relation to the
-   KSKs' sizes) doesn't make much sense.  Try to limit the difference in
-   size to about 100 bits.
-
-   Note that nobody can see into the future, and that these key sizes
-   are only provided here as a guide.  Further information can be found
-   in [17] and Section 7.5 of [18].  It should be noted though that [17]
-   is already considered overly optimistic about what key sizes are
-   considered safe.
-
-   One final note concerning key sizes.  Larger keys will increase the
-   sizes of the RRSIG and DNSKEY records and will therefore increase the
-   chance of DNS UDP packet overflow.  Also the time it takes to
-   validate and create RRSIGs increases with larger keys, so don't
-   needlessly double your key sizes.
-
-
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 11]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-3.6.  Private Key Storage
-
-   It is recommended that, where possible, zone private keys and the
-   zone file master copy that is to be signed, be kept and used in off-
-   line, non-network connected, physically secure machines only.
-   Periodically an application can be run to add authentication to a
-   zone by adding RRSIG and NSEC RRs.  Then the augmented file can be
-   transferred.
-
-   When relying on dynamic update to manage a signed zone [10], be aware
-   that at least one private key of the zone will have to reside on the
-   master server.  This key is only as secure as the amount of exposure
-   the server receives to unknown clients and the security of the host.
-   Although not mandatory one could administer the DNS in the following
-   way.  The master that processes the dynamic updates is unavailable
-   from generic hosts on the Internet, it is not listed in the NS RR
-   set, although its name appears in the SOA RRs MNAME field.  The
-   nameservers in the NS RR set are able to receive zone updates through
-   NOTIFY, IXFR, AXFR or an out-of-band distribution mechanism.  This
-   approach is known as the "hidden master" setup.
-
-   The ideal situation is to have a one way information flow to the
-   network to avoid the possibility of tampering from the network.
-   Keeping the zone master file on-line on the network and simply
-   cycling it through an off-line signer does not do this.  The on-line
-   version could still be tampered with if the host it resides on is
-   compromised.  For maximum security, the master copy of the zone file
-   should be off net and should not be updated based on an unsecured
-   network mediated communication.
-
-   In general keeping a zone-file off-line will not be practical and the
-   machines on which zone files are maintained will be connected to a
-   network.  Operators are advised to take security measures to shield
-   unauthorized access to the master copy.
-
-   For dynamically updated secured zones [10] both the master copy and
-   the private key that is used to update signatures on updated RRs will
-   need to be on-line.
-
-
-4.  Signature generation, Key Rollover and Related Policies
-
-4.1.  Time in DNSSEC
-
-   Without DNSSEC all times in DNS are relative.  The SOA fields
-   REFRESH, RETRY and EXPIRATION are timers used to determine the time
-   elapsed after a slave server synchronized with a master server.  The
-   Time to Live (TTL) value and the SOA RR minimum TTL parameter [11]
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 12]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   are used to determine how long a forwarder should cache data after it
-   has been fetched from an authoritative server.  By using a signature
-   validity period, DNSSEC introduces the notion of an absolute time in
-   the DNS.  Signatures in DNSSEC have an expiration date after which
-   the signature is marked as invalid and the signed data is to be
-   considered Bogus.
-
-4.1.1.  Time Considerations
-
-   Because of the expiration of signatures, one should consider the
-   following:
-   o  We suggest the Maximum Zone TTL of your zone data to be a fraction
-      of your signature validity period.
-         If the TTL would be of similar order as the signature validity
-         period, then all RRSets fetched during the validity period
-         would be cached until the signature expiration time.  Section
-         7.1 of [4] suggests that "the resolver may use the time
-         remaining before expiration of the signature validity period of
-         a signed RRSet as an upper bound for the TTL".  As a result
-         query load on authoritative servers would peak at signature
-         expiration time, as this is also the time at which records
-         simultaneously expire from caches.
-         To avoid query load peaks we suggest the TTL on all the RRs in
-         your zone to be at least a few times smaller than your
-         signature validity period.
-   o  We suggest the Signature Publication Period to end at least one
-      Maximum Zone TTL duration before the end of the Signature Validity
-      Period.
-         Re-signing a zone shortly before the end of the signature
-         validity period may cause simultaneous expiration of data from
-         caches.  This in turn may lead to peaks in the load on
-         authoritative servers.
-   o  We suggest the minimum zone TTL to be long enough to both fetch
-      and verify all the RRs in the trust chain.  In workshop
-      environments it has been demonstrated [19] that a low TTL (under 5
-      to 10 minutes) caused disruptions because of the following two
-      problems:
-         1.  During validation, some data may expire before the
-         validation is complete.  The validator should be able to keep
-         all data, until is completed.  This applies to all RRs needed
-         to complete the chain of trust: DSs, DNSKEYs, RRSIGs, and the
-         final answers i.e. the RRSet that is returned for the initial
-         query.
-         2.  Frequent verification causes load on recursive nameservers.
-         Data at delegation points, DSs, DNSKEYs and RRSIGs benefit from
-         caching.  The TTL on those should be relatively long.
-
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 13]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   o  Slave servers will need to be able to fetch newly signed zones
-      well before the RRSIGs in the zone served by the slave server pass
-      their signature expiration time.
-         When a slave server is out of sync with its master and data in
-         a zone is signed by expired signatures it may be better for the
-         slave server not to give out any answer.
-         Normally a slave server that is not able to contact a master
-         server for an extended period will expire a zone.  When that
-         happens the server will respond differently to queries for that
-         zone.  Some servers issue SERVFAIL while others turn off the
-         'AA' bit in the answers.  The time of expiration is set in the
-         SOA record and is relative to the last successful refresh
-         between the master and the slave server.  There exists no
-         coupling between the signature expiration of RRSIGs in the zone
-         and the expire parameter in the SOA.
-         If the server serves a DNSSEC zone then it may well happen that
-         the signatures expire well before the SOA expiration timer
-         counts down to zero.  It is not possible to completely prevent
-         this from happening by tweaking the SOA parameters.
-         However, the effects can be minimized where the SOA expiration
-         time is equal or shorter than the signature validity period.
-         The consequence of an authoritative server not being able to
-         update a zone, whilst that zone includes expired signatures, is
-         that non-secure resolvers will continue to be able to resolve
-         data served by the particular slave servers while security
-         aware resolvers will experience problems because of answers
-         being marked as Bogus.
-         We suggest the SOA expiration timer being approximately one
-         third or one fourth of the signature validity period.  It will
-         allow problems with transfers from the master server to be
-         noticed before the actual signature times out.
-         We also suggest that operators of nameservers that supply
-         secondary services develop 'watch dogs' to spot upcoming
-         signature expirations in zones they slave, and take appropriate
-         action.
-         When determining the value for the expiration parameter one has
-         to take the following into account: What are the chances that
-         all my secondaries expire the zone; How quickly can I reach an
-         administrator of secondary servers to load a valid zone?  All
-         these arguments are not DNSSEC specific but may influence the
-         choice of your signature validity intervals.
-
-4.2.  Key Rollovers
-
-   A DNSSEC key cannot be used forever (see Section 3.3).  So key
-   rollovers -- or supercessions, as they are sometimes called -- are a
-   fact of life when using DNSSEC.  Zone administrators who are in the
-   process of rolling their keys have to take into account that data
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 14]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   published in previous versions of their zone still lives in caches.
-   When deploying DNSSEC, this becomes an important consideration;
-   ignoring data that may be in caches may lead to loss of service for
-   clients.
-
-   The most pressing example of this occurs when zone material signed
-   with an old key is being validated by a resolver which does not have
-   the old zone key cached.  If the old key is no longer present in the
-   current zone, this validation fails, marking the data Bogus.
-   Alternatively, an attempt could be made to validate data which is
-   signed with a new key against an old key that lives in a local cache,
-   also resulting in data being marked Bogus.
-
-4.2.1.  Zone Signing Key Rollovers
-
-   For zone signing key rollovers there are two ways to make sure that
-   during the rollover data still cached can be verified with the new
-   key sets or newly generated signatures can be verified with the keys
-   still in caches.  One schema, described in Section 4.2.1.2, uses
-   double signatures; the other uses key pre-publication
-   (Section 4.2.1.1).  The pros, cons and recommendations are described
-   in Section 4.2.1.3.
-
-4.2.1.1.  Pre-publish Key Rollover
-
-   This section shows how to perform a ZSK rollover without the need to
-   sign all the data in a zone twice - the so-called "pre-publish
-   rollover".This method has advantages in the case of a key compromise.
-   If the old key is compromised, the new key has already been
-   distributed in the DNS.  The zone administrator is then able to
-   quickly switch to the new key and remove the compromised key from the
-   zone.  Another major advantage is that the zone size does not double,
-   as is the case with the double signature ZSK rollover.  A small
-   "HOWTO" for this kind of rollover can be found in Appendix B.
-
-   Pre-publish Key Rollover involves four stages as follows:
-
-    initial         new DNSKEY       new RRSIGs      DNSKEY removal
-
-    SOA0            SOA1             SOA2            SOA3
-    RRSIG10(SOA0)   RRSIG10(SOA1)    RRSIG11(SOA2)   RRSIG11(SOA3)
-
-    DNSKEY1         DNSKEY1          DNSKEY1         DNSKEY1
-    DNSKEY10        DNSKEY10         DNSKEY10        DNSKEY11
-                    DNSKEY11         DNSKEY11
-    RRSIG1 (DNSKEY) RRSIG1 (DNSKEY)  RRSIG1(DNSKEY)  RRSIG1 (DNSKEY)
-    RRSIG10(DNSKEY) RRSIG10(DNSKEY)  RRSIG11(DNSKEY) RRSIG11(DNSKEY)
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 15]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   initial: Initial version of the zone: DNSKEY 1 is the key signing
-      key.  DNSKEY 10 is used to sign all the data of the zone, the zone
-      signing key.
-   new DNSKEY: DNSKEY 11 is introduced into the key set.  Note that no
-      signatures are generated with this key yet, but this does not
-      secure against brute force attacks on the public key.  The minimum
-      duration of this pre-roll phase is the time it takes for the data
-      to propagate to the authoritative servers plus TTL value of the
-      key set.
-   new RRSIGs: At the "new RRSIGs" stage (SOA serial 2) DNSKEY 11 is
-      used to sign the data in the zone exclusively (i.e. all the
-      signatures from DNSKEY 10 are removed from the zone).  DNSKEY 10
-      remains published in the key set.  This way data that was loaded
-      into caches from version 1 of the zone can still be verified with
-      key sets fetched from version 2 of the zone.
-      The minimum time that the key set including DNSKEY 10 is to be
-      published is the time that it takes for zone data from the
-      previous version of the zone to expire from old caches i.e. the
-      time it takes for this zone to propagate to all authoritative
-      servers plus the Maximum Zone TTL value of any of the data in the
-      previous version of the zone.
-   DNSKEY removal: DNSKEY 10 is removed from the zone.  The key set, now
-      only containing DNSKEY 1 and DNSKEY 11 is re-signed with the
-      DNSKEY 1.
-
-   The above scheme can be simplified by always publishing the "future"
-   key immediately after the rollover.  The scheme would look as follows
-   (we show two rollovers); the future key is introduced in "new DNSKEY"
-   as DNSKEY 12 and again a newer one, numbered 13, in "new DNSKEY
-   (II)":
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 16]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-       initial             new RRSIGs          new DNSKEY
-
-       SOA0                SOA1                SOA2
-       RRSIG10(SOA0)       RRSIG11(SOA1)       RRSIG11(SOA2)
-
-       DNSKEY1             DNSKEY1             DNSKEY1
-       DNSKEY10            DNSKEY10            DNSKEY11
-       DNSKEY11            DNSKEY11            DNSKEY12
-       RRSIG1(DNSKEY)      RRSIG1 (DNSKEY)     RRSIG1(DNSKEY)
-       RRSIG10(DNSKEY)     RRSIG11(DNSKEY)     RRSIG11(DNSKEY)
-
-
-       new RRSIGs (II)     new DNSKEY (II)
-
-       SOA3                SOA4
-       RRSIG12(SOA3)       RRSIG12(SOA4)
-
-       DNSKEY1             DNSKEY1
-       DNSKEY11            DNSKEY12
-       DNSKEY12            DNSKEY13
-       RRSIG1(DNSKEY)      RRSIG1(DNSKEY)
-       RRSIG12(DNSKEY)     RRSIG12(DNSKEY)
-
-
-   Pre-Publish Key Rollover, showing two rollovers.
-
-   Note that the key introduced in the "new DNSKEY" phase is not used
-   for production yet; the private key can thus be stored in a
-   physically secure manner and does not need to be 'fetched' every time
-   a zone needs to be signed.
-
-4.2.1.2.  Double Signature Zone Signing Key Rollover
-
-   This section shows how to perform a ZSK key rollover using the double
-   zone data signature scheme, aptly named "double sig rollover".
-
-   During the "new DNSKEY" stage the new version of the zone file will
-   need to propagate to all authoritative servers and the data that
-   exists in (distant) caches will need to expire, requiring at least
-   the maximum Zone TTL.
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 17]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   Double Signature Zone Signing Key Rollover involves three stages as
-   follows:
-
-       initial             new DNSKEY         DNSKEY removal
-
-       SOA0                SOA1               SOA2
-       RRSIG10(SOA0)       RRSIG10(SOA1)      RRSIG11(SOA2)
-                           RRSIG11(SOA1)
-
-       DNSKEY1             DNSKEY1            DNSKEY1
-       DNSKEY10            DNSKEY10           DNSKEY11
-                           DNSKEY11
-       RRSIG1(DNSKEY)      RRSIG1(DNSKEY)     RRSIG1(DNSKEY)
-       RRSIG10(DNSKEY)     RRSIG10(DNSKEY)    RRSIG11(DNSKEY)
-                           RRSIG11(DNSKEY)
-
-   initial: Initial Version of the zone: DNSKEY 1 is the key signing
-      key.  DNSKEY 10 is used to sign all the data of the zone, the zone
-      signing key.
-   new DNSKEY: At the "New DNSKEY" stage (SOA serial 1) DNSKEY 11 is
-      introduced into the key set and all the data in the zone is signed
-      with DNSKEY 10 and DNSKEY 11.  The rollover period will need to
-      continue until all data from version 0 of the zone has expired
-      from remote caches.  This will take at least the maximum Zone TTL
-      of version 0 of the zone.
-   DNSKEY removal: DNSKEY 10 is removed from the zone.  All the
-      signatures from DNSKEY 10 are removed from the zone.  The key set,
-      now only containing DNSKEY 11, is re-signed with DNSKEY 1.
-
-   At every instance, RRSIGs from the previous version of the zone can
-   be verified with the DNSKEY RRSet from the current version and the
-   other way around.  The data from the current version can be verified
-   with the data from the previous version of the zone.  The duration of
-   the "new DNSKEY" phase and the period between rollovers should be at
-   least the Maximum Zone TTL.
-
-   Making sure that the "new DNSKEY" phase lasts until the signature
-   expiration time of the data in initial version of the zone is
-   recommended.  This way all caches are cleared of the old signatures.
-   However, this duration could be considerably longer than the Maximum
-   Zone TTL, making the rollover a lengthy procedure.
-
-   Note that in this example we assumed that the zone was not modified
-   during the rollover.  New data can be introduced in the zone as long
-   as it is signed with both keys.
-
-
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 18]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-4.2.1.3.  Pros and Cons of the Schemes
-
-   Pre-publish Key Rollover: This rollover does not involve signing the
-      zone data twice.  Instead, before the actual rollover, the new key
-      is published in the key set and thus available for cryptanalysis
-      attacks.  A small disadvantage is that this process requires four
-      steps.  Also the pre-publish scheme involves more parental work
-      when used for KSK rollovers as explained in Section 4.2.3.
-   Double Signature Zone-signing Key Rollover: The drawback of this
-      signing scheme is that during the rollover the number of
-      signatures in your zone doubles, this may be prohibitive if you
-      have very big zones.  An advantage is that it only requires three
-      steps.
-
-4.2.2.  Key Signing Key Rollovers
-
-   For the rollover of a key signing key the same considerations as for
-   the rollover of a zone signing key apply.  However we can use a
-   double signature scheme to guarantee that old data (only the apex key
-   set) in caches can be verified with a new key set and vice versa.
-   Since only the key set is signed with a KSK, zone size considerations
-   do not apply.
-
-
-       initial        new DNSKEY        DS change       DNSKEY removal
-     Parent:
-       SOA0           -------->         SOA1            -------->
-       RRSIGpar(SOA0) -------->         RRSIGpar(SOA1)  -------->
-       DS1            -------->         DS2             -------->
-       RRSIGpar(DS)   -------->         RRSIGpar(DS)    -------->
-
-
-     Child:
-       SOA0            SOA1             -------->       SOA2
-       RRSIG10(SOA0)   RRSIG10(SOA1)    -------->       RRSIG10(SOA2)
-                                        -------->
-       DNSKEY1         DNSKEY1          -------->       DNSKEY2
-                       DNSKEY2          -------->
-       DNSKEY10        DNSKEY10         -------->       DNSKEY10
-       RRSIG1 (DNSKEY) RRSIG1 (DNSKEY)  -------->       RRSIG2 (DNSKEY)
-                       RRSIG2 (DNSKEY)  -------->
-       RRSIG10(DNSKEY) RRSIG10(DNSKEY)  -------->       RRSIG10(DNSKEY)
-
-   Stages of Deployment for Key Signing Key Rollover.
-
-
-
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 19]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   initial: Initial version of the zone.  The parental DS points to
-      DNSKEY1.  Before the rollover starts the child will have to verify
-      what the TTL is of the DS RR that points to DNSKEY1 - it is needed
-      during the rollover and we refer to the value as TTL_DS.
-   new DNSKEY: During the "new DNSKEY" phase the zone administrator
-      generates a second KSK, DNSKEY2.  The key is provided to the
-      parent and the child will have to wait until a new DS RR has been
-      generated that points to DNSKEY2.  After that DS RR has been
-      published on all servers authoritative for the parent's zone, the
-      zone administrator has to wait at least TTL_DS to make sure that
-      the old DS RR has expired from caches.
-   DS change: The parent replaces DS1 with DS2.
-   DNSKEY removal: DNSKEY1 has been removed.
-
-   The scenario above puts the responsibility for maintaining a valid
-   chain of trust with the child.  It also is based on the premises that
-   the parent only has one DS RR (per algorithm) per zone.  An
-   alternative mechanism has been considered.  Using an established
-   trust relation, the interaction can be performed in-band, and the
-   removal of the keys by the child can possibly be signaled by the
-   parent.  In this mechanism there are periods where there are two DS
-   RRs at the parent.  Since at the moment of writing the protocol for
-   this interaction has not been developed, further discussion is out of
-   scope for this document.
-
-4.2.3.  Difference Between ZSK and KSK Rollovers
-
-   Note that KSK rollovers and ZSK rollovers are different in the sense
-   that a KSK rollover requires interaction with the parent (and
-   possibly replacing of trust anchors) and the ensuing delay while
-   waiting for it.
-
-   A zone key rollover can be handled in two different ways: pre-publish
-   (Section Section 4.2.1.1) and double signature (Section
-   Section 4.2.1.2).
-
-   As the KSK is used to validate the key set and because the KSK is not
-   changed during a ZSK rollover, a cache is able to validate the new
-   key set of the zone.  The pre-publish method would also work for a
-   KSK rollover.  The records that are to be pre-published are the
-   parental DS RRs.  The pre-publish method has some drawbacks for KSKs.
-   We first describe the rollover scheme and then indicate these
-   drawbacks.
-
-
-
-
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 20]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-     initial         new DS           new DNSKEY      DS/DNSKEY removal
-   Parent:
-     SOA0            SOA1             -------->       SOA2
-     RRSIGpar(SOA0)  RRSIGpar(SOA1)   -------->       RRSIGpar(SOA2)
-     DS1             DS1              -------->       DS2
-                     DS2              -------->
-     RRSIGpar(DS)    RRSIGpar(DS)     -------->       RRSIGpar(DS)
-
-
-
-   Child:
-     SOA0            -------->        SOA1            SOA1
-     RRSIG10(SOA0)   -------->        RRSIG10(SOA1)   RRSIG10(SOA1)
-                     -------->
-     DNSKEY1         -------->        DNSKEY2         DNSKEY2
-                     -------->
-     DNSKEY10        -------->        DNSKEY10        DNSKEY10
-     RRSIG1 (DNSKEY) -------->        RRSIG2(DNSKEY)  RRSIG2 (DNSKEY)
-     RRSIG10(DNSKEY) -------->        RRSIG10(DNSKEY) RRSIG10(DNSKEY)
-
-   Stages of Deployment for a Pre-publish Key Signing Key rollover.
-
-   When the child zone wants to roll it notifies the parent during the
-   "new DS" phase and submits the new key (or the corresponding DS) to
-   the parent.  The parent publishes DS1 and DS2, pointing to DNSKEY1
-   and DNSKEY2 respectively.  During the rollover ("new DNSKEY" phase),
-   which can take place as soon as the new DS set propagated through the
-   DNS, the child replaces DNSKEY1 with DNSKEY2.  Immediately after that
-   ("DS/DNSKEY removal" phase) it can notify the parent that the old DS
-   record can be deleted.
-
-   The drawbacks of this scheme are that during the "new DS" phase the
-   parent cannot verify the match between the DS2 RR and DNSKEY2 using
-   the DNS -- as DNSKEY2 is not yet published.  Besides, we introduce a
-   "security lame" key (See Section 4.4.3).  Finally the child-parent
-   interaction consists of two steps.  The "double signature" method
-   only needs one interaction.
-
-4.2.4.  Automated Key Rollovers
-
-   As keys must be renewed periodically, there is some motivation to
-   automate the rollover process.  Consider that:
-
-   o  ZSK rollovers are easy to automate as only the child zone is
-      involved.
-   o  A KSK rollover needs interaction between parent and child.  Data
-      exchange is needed to provide the new keys to the parent,
-      consequently, this data must be authenticated and integrity must
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 21]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-      be guaranteed in order to avoid attacks on the rollover.
-
-4.3.  Planning for Emergency Key Rollover
-
-   This section deals with preparation for a possible key compromise.
-   Our advice is to have a documented procedure ready for when a key
-   compromise is suspected or confirmed.
-
-   When the private material of one of your keys is compromised it can
-   be used for as long as a valid trust chain exists.  A trust chain
-   remains intact for:
-   o  as long as a signature over the compromised key in the trust chain
-      is valid,
-   o  as long as a parental DS RR (and signature) points to the
-      compromised key,
-   o  as long as the key is anchored in a resolver and is used as a
-      starting point for validation (this is generally the hardest to
-      update).
-
-   While a trust chain to your compromised key exists, your name-space
-   is vulnerable to abuse by anyone who has obtained illegitimate
-   possession of the key.  Zone operators have to make a trade off if
-   the abuse of the compromised key is worse than having data in caches
-   that cannot be validated.  If the zone operator chooses to break the
-   trust chain to the compromised key, data in caches signed with this
-   key cannot be validated.  However, if the zone administrator chooses
-   to take the path of a regular roll-over, the malicious key holder can
-   spoof data so that it appears to be valid.
-
-4.3.1.  KSK Compromise
-
-   A zone containing a DNSKEY RRSet with a compromised KSK is vulnerable
-   as long as the compromised KSK is configured as trust anchor or a
-   parental DS points to it.
-
-   A compromised KSK can be used to sign the key set of an attacker's
-   zone.  That zone could be used to poison the DNS.
-
-   Therefore when the KSK has been compromised, the trust anchor or the
-   parental DS, should be replaced as soon as possible.  It is local
-   policy whether to break the trust chain during the emergency
-   rollover.  The trust chain would be broken when the compromised KSK
-   is removed from the child's zone while the parent still has a DS
-   pointing to the compromised KSK (the assumption is that there is only
-   one DS at the parent.  If there are multiple DSs this does not apply
-   -- however the chain of trust of this particular key is broken).
-
-   Note that an attacker's zone still uses the compromised KSK and the
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 22]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   presence of a parental DS would cause the data in this zone to appear
-   as valid.  Removing the compromised key would cause the attacker's
-   zone to appear as valid and the child's zone as Bogus.  Therefore we
-   advise not to remove the KSK before the parent has a DS to a new KSK
-   in place.
-
-4.3.1.1.  Keeping the Chain of Trust Intact
-
-   If we follow this advice the timing of the replacement of the KSK is
-   somewhat critical.  The goal is to remove the compromised KSK as soon
-   as the new DS RR is available at the parent.  And also make sure that
-   the signature made with a new KSK over the key set with the
-   compromised KSK in it expires just after the new DS appears at the
-   parent.  Thus removing the old cruft in one swoop.
-
-   The procedure is as follows:
-   1.  Introduce a new KSK into the key set, keep the compromised KSK in
-       the key set.
-   2.  Sign the key set, with a short validity period.  The validity
-       period should expire shortly after the DS is expected to appear
-       in the parent and the old DSs have expired from caches.
-   3.  Upload the DS for this new key to the parent.
-   4.  Follow the procedure of the regular KSK rollover: Wait for the DS
-       to appear in the authoritative servers and then wait as long as
-       the TTL of the old DS RRs.  If necessary re-sign the DNSKEY RRSet
-       and modify/extend the expiration time.
-   5.  Remove the compromised DNSKEY RR from the zone and re-sign the
-       key set using your "normal" validity interval.
-
-   An additional danger of a key compromise is that the compromised key
-   could be used to facilitate a legitimate DNSKEY/DS rollover and/or
-   nameserver changes at the parent.  When that happens the domain may
-   be in dispute.  An authenticated out-of-band and secure notify
-   mechanism to contact a parent is needed in this case.
-
-   Note that this is only a problem when the DNSKEY and or DS records
-   are used for authentication at the parent.
-
-4.3.1.2.  Breaking the Chain of Trust
-
-   There are two methods to break the chain of trust.  The first method
-   causes the child zone to appear as 'Bogus' to validating resolvers.
-   The other causes the the child zone to appear as 'insecure'.  These
-   are described below.
-
-   In the method that causes the child zone to appear as 'Bogus' to
-   validating resolvers, the child zone replaces the current KSK with a
-   new one and resigns the key set.  Next it sends the DS of the new key
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 23]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   to the parent.  Only after the parent has placed the new DS in the
-   zone, the child's chain of trust is repaired.
-
-   An alternative method of breaking the chain of trust is by removing
-   the DS RRs from the parent zone altogether.  As a result the child
-   zone would become insecure.
-
-4.3.2.  ZSK Compromise
-
-   Primarily because there is no parental interaction required when a
-   ZSK is compromised, the situation is less severe than with a KSK
-   compromise.  The zone must still be re-signed with a new ZSK as soon
-   as possible.  As this is a local operation and requires no
-   communication between the parent and child this can be achieved
-   fairly quickly.  However, one has to take into account that just as
-   with a normal rollover the immediate disappearance of the old
-   compromised key may lead to verification problems.  Also note that as
-   long as the RRSIG over the compromised ZSK is not expired the zone
-   may be still at risk.
-
-4.3.3.  Compromises of Keys Anchored in Resolvers
-
-   A key can also be pre-configured in resolvers.  For instance, if
-   DNSSEC is successfully deployed the root key may be pre-configured in
-   most security aware resolvers.
-
-   If trust-anchor keys are compromised, the resolvers using these keys
-   should be notified of this fact.  Zone administrators may consider
-   setting up a mailing list to communicate the fact that a SEP key is
-   about to be rolled over.  This communication will of course need to
-   be authenticated e.g. by using digital signatures.
-
-   End-users faced with the task of updating an anchored key should
-   always validate the new key.  New keys should be authenticated out-
-   of-band, for example, looking them up on an SSL secured announcement
-   website.
-
-4.4.  Parental Policies
-
-4.4.1.  Initial Key Exchanges and Parental Policies Considerations
-
-   The initial key exchange is always subject to the policies set by the
-   parent.  When designing a key exchange policy one should take into
-   account that the authentication and authorization mechanisms used
-   during a key exchange should be as strong as the authentication and
-   authorization mechanisms used for the exchange of delegation
-   information between parent and child.  I.e. there is no implicit need
-   in DNSSEC to make the authentication process stronger than it was in
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 24]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   DNS.
-
-   Using the DNS itself as the source for the actual DNSKEY material,
-   with an out-of-band check on the validity of the DNSKEY, has the
-   benefit that it reduces the chances of user error.  A DNSKEY query
-   tool can make use of the SEP bit [3] to select the proper key from a
-   DNSSEC key set; thereby reducing the chance that the wrong DNSKEY is
-   sent.  It can validate the self-signature over a key; thereby
-   verifying the ownership of the private key material.  Fetching the
-   DNSKEY from the DNS ensures that the chain of trust remains intact
-   once the parent publishes the DS RR indicating the child is secure.
-
-   Note: the out-of-band verification is still needed when the key-
-   material is fetched via the DNS.  The parent can never be sure
-   whether the DNSKEY RRs have been spoofed or not.
-
-4.4.2.  Storing Keys or Hashes?
-
-   When designing a registry system one should consider which of the
-   DNSKEYs and/or the corresponding DSs to store.  Since a child zone
-   might wish to have a DS published using a message digest algorithm
-   not yet understood by the registry, the registry can't count on being
-   able to generate the DS record from a raw DNSKEY.  Thus, we recommend
-   that registry systems at least support storing DS records.
-
-   It may also be useful to store DNSKEYs, since having them may help
-   during troubleshooting and, as long as the child's chosen message
-   digest is supported, the overhead of generating DS records from them
-   is minimal.  Having an out-of-band mechanism, such as a registry
-   directory (e.g.  Whois), to find out which keys are used to generate
-   DS Resource Records for specific owners and/or zones may also help
-   with troubleshooting.
-
-   The storage considerations also relate to the design of the customer
-   interface and the method by which data is transferred between
-   registrant and registry; Will the child zone administrator be able to
-   upload DS RRs with unknown hash algorithms or does the interface only
-   allow DNSKEYs?  In the registry-registrar model one can use the
-   DNSSEC EPP protocol extension [16] which allows transfer of DS RRs
-   and optionally DNSKEY RRs.
-
-4.4.3.  Security Lameness
-
-   Security Lameness is defined as what happens when a parent has a DS
-   RR pointing to a non-existing DNSKEY RR.  When this happens the
-   child's zone may be marked as "Bogus" by verifying DNS clients.
-
-   As part of a comprehensive delegation check the parent could, at key
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 25]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   exchange time, verify that the child's key is actually configured in
-   the DNS.  However if a parent does not understand the hashing
-   algorithm used by child the parental checks are limited to only
-   comparing the key id.
-
-   Child zones should be very careful removing DNSKEY material,
-   specifically SEP keys, for which a DS RR exists.
-
-   Once a zone is "security lame", a fix (e.g. removing a DS RR) will
-   take time to propagate through the DNS.
-
-4.4.4.  DS Signature Validity Period
-
-   Since the DS can be replayed as long as it has a valid signature, a
-   short signature validity period over the DS minimizes the time a
-   child is vulnerable in the case of a compromise of the child's
-   KSK(s).  A signature validity period that is too short introduces the
-   possibility that a zone is marked Bogus in case of a configuration
-   error in the signer.  There may not be enough time to fix the
-   problems before signatures expire.  Something as mundane as operator
-   unavailability during weekends shows the need for DS signature
-   validity periods longer than 2 days.  We recommend an absolute
-   minimum for a DS signature validity period of a few days.
-
-   The maximum signature validity period of the DS record depends on how
-   long child zones are willing to be vulnerable after a key compromise.
-   On the other hand shortening the DS signature validity interval
-   increases the operational risk for the parent.  Therefore the parent
-   may have policy to use a signature validity interval that is
-   considerably longer than the child would hope for.
-
-   A compromise between the operational constraints of the parent and
-   minimizing damage for the child may result in a DS signature validity
-   period somewhere between the order of a week to order of months.
-
-   In addition to the signature validity period, which sets a lower
-   bound on the number of times the zone owner will need to sign the
-   zone data and which sets an upper bound to the time a child is
-   vulnerable after key compromise, there is the TTL value on the DS
-   RRs.  Shortening the TTL means that the authoritative servers will
-   see more queries.  But on the other hand, a short TTL lowers the
-   persistence of DS RRSets in caches thereby increases the speed with
-   which updated DS RRSets propagate through the DNS.
-
-
-5.  IANA Considerations
-
-   This overview document introduces no new IANA considerations.
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 26]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-6.  Security Considerations
-
-   DNSSEC adds data integrity to the DNS.  This document tries to assess
-   the operational considerations to maintain a stable and secure DNSSEC
-   service.  Not taking into account the 'data propagation' properties
-   in the DNS will cause validation failures and may make secured zones
-   unavailable to security aware resolvers.
-
-
-7.  Acknowledgments
-
-   Most of the ideas in this draft were the result of collective efforts
-   during workshops, discussions and try outs.
-
-   At the risk of forgetting individuals who were the original
-   contributors of the ideas we would like to acknowledge people who
-   were actively involved in the compilation of this document.  In
-   random order: Rip Loomis, Olafur Gudmundsson, Wesley Griffin, Michael
-   Richardson, Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette
-   Olivier Courtay, Sam Weiler, Jelte Jansen, Niall O'Reilly, Holger
-   Zuleger, Ed Lewis, Hilarie Orman, Marcos Sanz and Peter Koch.
-
-   Some material in this document has been copied from RFC 2541 [12].
-
-   Mike StJohns designed the key exchange between parent and child
-   mentioned in the last paragraph of Section 4.2.2
-
-   Section 4.2.4 was supplied by G. Guette and O. Courtay.
-
-   Emma Bretherick, Adrian Bedford and Lindy Foster corrected many of
-   the spelling and style issues.
-
-   Kolkman and Gieben take the blame for introducing all miscakes(SIC).
-
-   Kolkman was employed by the RIPE NCC while working on this document.
-
-
-8.  References
-
-8.1.  Normative References
-
-   [1]  Mockapetris, P., "Domain names - concepts and facilities",
-        STD 13, RFC 1034, November 1987.
-
-   [2]  Mockapetris, P., "Domain names - implementation and
-        specification", STD 13, RFC 1035, November 1987.
-
-   [3]  Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System KEY
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 27]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-        (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag",
-        RFC 3757, May 2004.
-
-   [4]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "DNS Security Introduction and Requirements", RFC 4033,
-        March 2005.
-
-   [5]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Resource Records for the DNS Security Extensions", RFC 4034,
-        March 2005.
-
-   [6]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Protocol Modifications for the DNS Security Extensions",
-        RFC 4035, March 2005.
-
-8.2.  Informative References
-
-   [7]   Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
-         August 1996.
-
-   [8]   Vixie, P., "A Mechanism for Prompt Notification of Zone Changes
-         (DNS NOTIFY)", RFC 1996, August 1996.
-
-   [9]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
-         Levels", BCP 14, RFC 2119, March 1997.
-
-   [10]  Eastlake, D., "Secure Domain Name System Dynamic Update",
-         RFC 2137, April 1997.
-
-   [11]  Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
-         RFC 2308, March 1998.
-
-   [12]  Eastlake, D., "DNS Security Operational Considerations",
-         RFC 2541, March 1999.
-
-   [13]  Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
-         RFC 3658, December 2003.
-
-   [14]  Orman, H. and P. Hoffman, "Determining Strengths For Public
-         Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766,
-         April 2004.
-
-   [15]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
-         Requirements for Security", BCP 106, RFC 4086, June 2005.
-
-   [16]  Hollenbeck, S., "Domain Name System (DNS) Security Extensions
-         Mapping for the Extensible Provisioning Protocol (EPP)",
-         RFC 4310, December 2005.
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 28]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   [17]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
-         Sizes", The Journal of Cryptology 14 (255-293), 2001.
-
-   [18]  Schneier, B., "Applied Cryptography: Protocols, Algorithms, and
-         Source Code in C", ISBN (hardcover) 0-471-12845-7, ISBN
-         (paperback) 0-471-59756-2, Published by John Wiley & Sons Inc.,
-         1996.
-
-   [19]  Rose, S., "NIST DNSSEC workshop notes", June 2001.
-
-   [20]  Jansen, J., "Use of RSA/SHA-256 DNSKEY and RRSIG Resource
-         Records in DNSSEC", draft-ietf-dnsext-dnssec-rsasha256-00.txt
-         (work in progress), January 2006.
-
-   [21]  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS)
-         Resource Records (RRs)", draft-ietf-dnsext-ds-sha256-04.txt
-         (work in progress), January 2006.
-
-
-Appendix A.  Terminology
-
-   In this document there is some jargon used that is defined in other
-   documents.  In most cases we have not copied the text from the
-   documents defining the terms but given a more elaborate explanation
-   of the meaning.  Note that these explanations should not be seen as
-   authoritative.
-
-   Anchored Key: A DNSKEY configured in resolvers around the globe.
-      This key is hard to update, hence the term anchored.
-   Bogus: Also see Section 5 of [4].  An RRSet in DNSSEC is marked
-      "Bogus" when a signature of a RRSet does not validate against a
-      DNSKEY.
-   Key Signing Key or KSK: A Key Signing Key (KSK) is a key that is used
-      exclusively for signing the apex key set.  The fact that a key is
-      a KSK is only relevant to the signing tool.
-   Key size: The term 'key size' can be substituted by 'modulus size'
-      throughout the document.  It is mathematically more correct to use
-      modulus size, but as this is a document directed at operators we
-      feel more at ease with the term key size.
-   Private and Public Keys: DNSSEC secures the DNS through the use of
-      public key cryptography.  Public key cryptography is based on the
-      existence of two (mathematically related) keys, a public key and a
-      private key.  The public keys are published in the DNS by use of
-      the DNSKEY Resource Record (DNSKEY RR).  Private keys should
-      remain private.
-
-
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 29]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   Key Rollover: A key rollover (also called key supercession in some
-      environments) is the act of replacing one key pair by another at
-      the end of a key effectivity period.
-   Secure Entry Point key or SEP Key: A KSK that has a parental DS
-      record pointing to it or is configured as a trust anchor.
-      Although not required by the protocol we recommend that the SEP
-      flag [3] is set on these keys.
-   Self-signature: This is only applies to signatures over DNSKEYs; a
-      signature made with DNSKEY x, over DNSKEY x is called a self-
-      signature.  Note: without further information self-signatures
-      convey no trust, they are useful to check the authenticity of the
-      DNSKEY, i.e. they can be used as a hash.
-   Singing the Zone File: The term used for the event where an
-      administrator joyfully signs its zone file while producing melodic
-      sound patterns.
-   Signer: The system that has access to the private key material and
-      signs the Resource Record sets in a zone.  A signer may be
-      configured to sign only parts of the zone e.g. only those RRSets
-      for which existing signatures are about to expire.
-   Zone Signing Key or ZSK: A Zone Signing Key (ZSK) is a key that is
-      used for signing all data in a zone.  The fact that a key is a ZSK
-      is only relevant to the signing tool.
-   Zone Administrator: The 'role' that is responsible for signing a zone
-      and publishing it on the primary authoritative server.
-
-
-Appendix B.  Zone Signing Key Rollover Howto
-
-   Using the pre-published signature scheme and the most conservative
-   method to assure oneself that data does not live in caches, here
-   follows the "HOWTO".
-   Step 0: The preparation: Create two keys and publish both in your key
-      set.  Mark one of the keys as "active" and the other as
-      "published".  Use the "active" key for signing your zone data.
-      Store the private part of the "published" key, preferably off-
-      line.
-      The protocol does not provide for attributes to mark a key as
-      active or published.  This is something you have to do on your
-      own, through the use of a notebook or key management tool.
-   Step 1: Determine expiration: At the beginning of the rollover make a
-      note of the highest expiration time of signatures in your zone
-      file created with the current key marked as "active".
-      Wait until the expiration time marked in Step 1 has passed
-   Step 2: Then start using the key that was marked as "published" to
-      sign your data i.e. mark it as "active".  Stop using the key that
-      was marked as "active", mark it as "rolled".
-
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 30]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   Step 3: It is safe to engage in a new rollover (Step 1) after at
-      least one "signature validity period".
-
-
-Appendix C.  Typographic Conventions
-
-   The following typographic conventions are used in this document:
-   Key notation: A key is denoted by DNSKEYx, where x is a number or an
-      identifier, x could be thought of as the key id.
-   RRSet notations: RRs are only denoted by the type.  All other
-      information - owner, class, rdata and TTL - is left out.  Thus:
-      "example.com 3600 IN A 192.0.2.1" is reduced to "A".  RRSets are a
-      list of RRs.  A example of this would be: "A1, A2", specifying the
-      RRSet containing two "A" records.  This could again be abbreviated
-      to just "A".
-   Signature notation: Signatures are denoted as RRSIGx(RRSet), which
-      means that RRSet is signed with DNSKEYx.
-   Zone representation: Using the above notation we have simplified the
-      representation of a signed zone by leaving out all unnecessary
-      details such as the names and by representing all data by "SOAx"
-   SOA representation: SOAs are represented as SOAx, where x is the
-      serial number.
-   Using this notation the following signed zone:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 31]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   example.net.      86400  IN SOA  ns.example.net. bert.example.net. (
-                            2006022100   ; serial
-                            86400        ; refresh (  24 hours)
-                            7200         ; retry   (   2 hours)
-                            3600000      ; expire  (1000 hours)
-                            28800 )      ; minimum (   8 hours)
-                     86400  RRSIG   SOA 5 2 86400 20130522213204 (
-                                  20130422213204 14 example.net.
-                                  cmL62SI6iAX46xGNQAdQ... )
-                     86400  NS      a.iana-servers.net.
-                     86400  NS      b.iana-servers.net.
-                     86400  RRSIG   NS 5 2 86400 20130507213204 (
-                                  20130407213204 14 example.net.
-                                  SO5epiJei19AjXoUpFnQ ... )
-                     86400  DNSKEY  256 3 5 (
-                                  EtRB9MP5/AvOuVO0I8XDxy0... ) ; id = 14
-                     86400  DNSKEY  257 3 5 (
-                                  gsPW/Yy19GzYIY+Gnr8HABU... ) ; id = 15
-                     86400  RRSIG   DNSKEY 5 2 86400 20130522213204 (
-                                  20130422213204 14 example.net.
-                                  J4zCe8QX4tXVGjV4e1r9... )
-                     86400  RRSIG   DNSKEY 5 2 86400 20130522213204 (
-                                  20130422213204 15 example.net.
-                                  keVDCOpsSeDReyV6O... )
-                     86400  RRSIG   NSEC 5 2 86400 20130507213204 (
-                                  20130407213204 14 example.net.
-                                  obj3HEp1GjnmhRjX... )
-   a.example.net.    86400  IN TXT  "A label"
-                     86400  RRSIG   TXT 5 3 86400 20130507213204 (
-                                  20130407213204 14 example.net.
-                                  IkDMlRdYLmXH7QJnuF3v... )
-                     86400  NSEC    b.example.com. TXT RRSIG NSEC
-                     86400  RRSIG   NSEC 5 3 86400 20130507213204 (
-                                  20130407213204 14 example.net.
-                                  bZMjoZ3bHjnEz0nIsPMM... )
-                     ...
-
-   is reduced to the following representation:
-
-       SOA2006022100
-       RRSIG14(SOA2006022100)
-       DNSKEY14
-       DNSKEY15
-
-       RRSIG14(KEY)
-       RRSIG15(KEY)
-
-   The rest of the zone data has the same signature as the SOA record,
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 32]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   i.e a RRSIG created with DNSKEY 14.
-
-
-Appendix D.  Document Details and Changes
-
-   This section is to be removed by the RFC editor if and when the
-   document is published.
-
-   $Id: draft-ietf-dnsop-dnssec-operational-practices.xml,v 1.31.2.14
-   2005/03/21 15:51:41 dnssec Exp $
-
-D.1.  draft-ietf-dnsop-dnssec-operational-practices-00
-
-   Submission as working group document.  This document is a modified
-   and updated version of draft-kolkman-dnssec-operational-practices-00.
-
-D.2.  draft-ietf-dnsop-dnssec-operational-practices-01
-
-   changed the definition of "Bogus" to reflect the one in the protocol
-   draft.
-
-   Bad to Bogus
-
-   Style and spelling corrections
-
-   KSK - SEP mapping made explicit.
-
-   Updates from Sam Weiler added
-
-D.3.  draft-ietf-dnsop-dnssec-operational-practices-02
-
-   Style and errors corrected.
-
-   Added Automatic rollover requirements from I-D.ietf-dnsop-key-
-   rollover-requirements.
-
-D.4.  draft-ietf-dnsop-dnssec-operational-practices-03
-
-   Added the definition of Key effectivity period and used that term
-   instead of Key validity period.
-
-   Modified the order of the sections, based on a suggestion by Rip
-   Loomis.
-
-   Included parts from RFC 2541 [12].  Most of its ground was already
-   covered.  This document obsoletes RFC 2541 [12].  Section 3.1.2
-   deserves some review as it in contrast to RFC 2541 does _not_ give
-   recomendations about root-zone keys.
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 33]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   added a paragraph to Section 4.4.4
-
-D.5.  draft-ietf-dnsop-dnssec-operational-practices-04
-
-   Somewhat more details added about the pre-publish KSK rollover.  Also
-   moved that subsection down a bit.
-
-   Editorial and content nits that came in during wg last call were
-   fixed.
-
-D.6.  draft-ietf-dnsop-dnssec-operational-practices-05
-
-   Applied some another set of comments that came in _after_ the the
-   WGLC.
-
-   Applied comments from Hilarie Orman and made a referece to RFC 3766.
-   Deleted of a lot of key length discussion and took over the
-   recommendations from RFC 3766.
-
-   Reworked all the heading of the rollover figures
-
-D.7.  draft-ietf-dnsop-dnssec-operational-practices-06
-
-   One comment from Scott Rose applied.
-
-   Marcos Sanz gave a lots of editorial nits.  Almost all are
-   incorporated.
-
-D.8.  draft-ietf-dnsop-dnssec-operational-practices-07
-
-   Peter Koch's comments applied.
-
-   SHA-1/SHA-256 remarks added
-
-D.9.  draft-ietf-dnsop-dnssec-operational-practices-08
-
-   IESG comments applied.  Added headers and some captions to the tables
-   and applied all the nits.
-
-   IESG DISCUSS comments applied
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 34]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-Authors' Addresses
-
-   Olaf M. Kolkman
-   NLnet Labs
-   Kruislaan 419
-   Amsterdam  1098 VA
-   The Netherlands
-
-   Email: olaf@nlnetlabs.nl
-   URI:   http://www.nlnetlabs.nl
-
-
-   Miek Gieben
-   NLnet Labs
-   Kruislaan 419
-   Amsterdam  1098 VA
-   The Netherlands
-
-   Email: miek@nlnetlabs.nl
-   URI:   http://www.nlnetlabs.nl
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 35]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 36]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-inaddr-required-07.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-inaddr-required-07.txt
deleted file mode 100644
index bcd0d14..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-inaddr-required-07.txt
+++ /dev/null
@@ -1,396 +0,0 @@
-
-
-
-
-
-
-INTERNET-DRAFT                                                  D. Senie
-Category: BCP                                     Amaranth Networks Inc.
-Expires in six months                                          July 2005
-
-               Encouraging the use of DNS IN-ADDR Mapping
-		    draft-ietf-dnsop-inaddr-required-07.txt 
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-Abstract
-
-   Mapping of addresses to names has been a feature of DNS.  Many sites,
-   implement it, many others don't.  Some applications attempt to use it
-   as a part of a security strategy. The goal of this document is to
-   encourage proper deployment of address to name mappings, and provide
-   guidance for their use.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society. (2005)
-
-1. Introduction
-
-   The Domain Name Service has provision for providing mapping of IP
-   addresses to host names. It is common practice to ensure both name to
-   address, and address to name mappings are provided for networks. This
-   practice, while documented, has never been required, though it is
-   generally encouraged.  This document both encourages the presence of
-
-
-
-Senie                                                           [Page 1]
-
-Internet-Draft Encouraging the use of DNS IN-ADDR Mapping      July 2005
-
-
-   these mappings and discourages reliance on such mappings for security
-   checks.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [RFC2119].
-
-2. Discussion
-
-
-   From the early days of the Domain Name Service [RFC883] a special
-   domain has been set aside for resolving mappings of IP addresses to
-   domain names.  This was refined in [RFC1035], describing the .IN-
-   ADDR.ARPA in use today.  For the in the IPv6 address space, .IP6.ARPA
-   was added [RFC3152]. This document uses IPv4 CIDR block sizes and
-   allocation strategy where there are differences and uses IPv4
-   terminology.  Aside from these differences, this document can and
-   should be applied to both address spaces.
-
-   The assignment of blocks of IP address space was delegated to three
-   regional registries. Guidelines for the registries are specified in
-   [RFC2050], which requires regional registries to maintain IN-ADDR
-   records on the large blocks of space issued to ISPs and others.
-
-   ARIN's policy requires ISPs to maintain IN-ADDR for /16 or larger
-   allocations. For smaller allocations, ARIN can provide IN-ADDR for
-   /24 and shorter prefixes. [ARIN].  APNIC provides methods for ISPs to
-   update IN-ADDR, however the present version of its policy document
-   for IPv4 [APNIC] dropped the IN-ADDR requirements that were in draft
-   copies of this document. As of this writing, it appears APNIC has no
-   actual policy on IN-ADDR.  RIPE appears to have the strongest policy
-   in this area [RIPE302] indicating Local Internet Registries should
-   provide IN-ADDR services, and delegate those as appropriate when
-   address blocks are delegated.
-
-   As we can see, the regional registries have their own policies for
-   recommendations and/or requirements for IN-ADDR maintenance. It
-   should be noted, however, that many address blocks were allocated
-   before the creation of the regional registries, and thus it is
-   unclear whether any of the policies of the registries are binding on
-   those who hold blocks from that era.
-
-   Registries allocate address blocks on CIDR [RFC1519] boundaries.
-   Unfortunately the IN-ADDR zones are based on classful allocations.
-   Guidelines [RFC2317] for delegating on non-octet-aligned boundaries
-   exist, but are not always implemented.
-
-3. Examples of impact of missing IN-ADDR
-
-
-
-Senie                                                           [Page 2]
-
-Internet-Draft Encouraging the use of DNS IN-ADDR Mapping      July 2005
-
-
-   These are some examples of problems that may be introduced by
-   reliance on IN-ADDR.
-
-   Some applications use DNS lookups for security checks. To ensure
-   validity of claimed names, some applications will look up IN-ADDR
-   records to get names, and then look up the resultant name to see if
-   it maps back to the address originally known. Failure to resolve
-   matching names is seen as a potential security concern.
-
-   Some FTP sites will flat-out reject users, even for anonymous FTP, if
-   the IN-ADDR lookup fails or if the result of the IN-ADDR lookup when
-   itself resolved, does not match. Some Telnet servers also implement
-   this check.
-
-   Web sites are in some cases using IN-ADDR checks to verify whether
-   the client is located within a certain geopolitical entity. This
-   approach has been employed for downloads of crypto software, for
-   example, where export of that software is prohibited to some locales.
-   Credit card anti-fraud systems also use these methods for geographic
-   placement purposes.
-
-   The popular TCP Wrappers program found on most Unix and Linux systems
-   has options to enforce IN-ADDR checks and to reject any client that
-   does not resolve. This program also has a way to check to see that
-   the name given by a PTR record then resolves back to the same IP
-   address. This method provdes more comfort but no appreciable
-   additional security.
-
-   Some anti-spam (anti junk email) systems use IN-ADDR to verify the
-   presence of a PTR record, or validate the PTR value points back to
-   the same address.
-
-   Many web servers look up the IN-ADDR of visitors to be used in log
-   analysis.  This adds to the server load, but in the case of IN-ADDR
-   unavailability, it can lead to delayed responses for users.
-
-   Traceroutes with descriptive IN-ADDR naming proves useful when
-   debugging problems spanning large areas. When this information is
-   missing, the traceroutes take longer, and it takes additional steps
-   to determine that network is the cause of problems.
-
-   Wider-scale implementation of IN-ADDR on dialup, wireless access and
-   other such client-oriented portions of the Internet would result in
-   lower latency for queries (due to lack of negative caching), and
-   lower name server load and DNS traffic.
-
-4. Recommendations
-
-
-
-
-Senie                                                           [Page 3]
-
-Internet-Draft Encouraging the use of DNS IN-ADDR Mapping      July 2005
-
-
-   4.1 Delegation Recommendations
-
-
-   Regional Registries and any Local Registries to whom they delegate
-   should establish and convey a policy to those to whom they delegate
-   blocks that IN-ADDR mappings are recommended.  Policies should
-   recommend those receiving delegations to provide IN-ADDR service
-   and/or delegate to downstream customers.
-
-   Network operators should define and implement policies and procedures
-   which delegate IN-ADDR to their clients who wish to run their own IN-
-   ADDR DNS services, and provide IN-ADDR services for those who do not
-   have the resources to do it themselves.  Delegation mechanisms should
-   permit the downstream customer to implement and comply with IETF
-   recommendations application of IN-ADDR to CIDR [RFC2317].
-
-   All IP address space assigned and in use should be resolved by IN-
-   ADDR records. All PTR records must use canonical names.
-
-   All IP addresses in use within a block should have an IN-ADDR
-   mapping. Those addresses not in use, and those that are not valid for
-   use (zeros or ones broadcast addresses within a CIDR block) need not
-   have mappings.
-
-   It should be noted that due to CIDR, many addresses that appear to be
-   otherwise valid host addresses may actually be zeroes or ones
-   broadcast addresses. As such, attempting to audit a site's degree of
-   compliance may only be done with knowledge of the internal subnet
-   architecture of the site.  It can be assumed, however, any host that
-   originates an IP packet necessarily will have a valid host address,
-   and must therefore have an IN-ADDR mapping.
-
-4.2 Application Recommendations
-
-
-   Applications SHOULD NOT rely on IN-ADDR for proper operation. The use
-   of IN-ADDR, sometimes in conjunction with a lookup of the name
-   resulting from the PTR record provides no real security, can lead to
-   erroneous results and generally just increases load on DNS servers.
-   Further, in cases where address block holders fail to properly
-   configure IN-ADDR, users of those blocks are penalized.
-
-5. Security Considerations
-
-   This document has no negative impact on security. While it could be
-   argued that lack of PTR record capabilities provides a degree of
-   anonymity, this is really not valid. Trace routes, whois lookups and
-   other sources will still provide methods for discovering identity.
-
-
-
-Senie                                                           [Page 4]
-
-Internet-Draft Encouraging the use of DNS IN-ADDR Mapping      July 2005
-
-
-   By recommending applications avoid using IN-ADDR as a security
-   mechanism this document points out that this practice, despite its
-   use by many applications, is an ineffective form of security.
-   Applications should use better mechanisms of authentication.
-
-6. IANA Considerations
-
-   There are no IANA considerations for this document.
-
-7. References
-
-7.1 Normative References
-
-   [RFC883] P.V. Mockapetris, "Domain names: Implementation
-   specification," RFC883, November 1983.
-
-   [RFC1035] P.V. Mockapetris, "Domain Names: Implementation
-   Specification," RFC 1035, November 1987.
-
-   [RFC1519] V. Fuller, et. al., "Classless Inter-Domain Routing (CIDR):
-   an Address Assignment and Aggregation Strategy," RFC 1519, September
-   1993.
-
-   [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3",
-   RFC 2026, BCP 9, October 1996.
-
-   [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
-   Requirement Levels", RFC 2119, BCP 14, March 1997.
-
-   [RFC2050] K. Hubbard, et. al., "Internet Registry IP Allocation
-   Guidelines", RFC2050, BCP 12, Novebmer 1996.
-
-   [RFC2317] H. Eidnes, et. al., "Classless IN-ADDR.ARPA delegation,"
-   RFC 2317, March 1998.
-
-   [RFC3152] R. Bush, "Delegation of IP6.ARPA," RFC 3152, BCP 49, August
-   2001.
-
-7.2 Informative References
-
-   [ARIN] "ISP Guidelines for Requesting Initial IP Address Space," date
-   unknown, http://www.arin.net/regserv/initial-isp.html
-
-   [APNIC] "Policies For IPv4 Address Space Management in the Asia
-   Pacific Region," APNIC-086, 13 January 2003.
-
-   [RIPE302] "Policy for Reverse Address Delegation of IPv4 and IPv6
-   Address Space in the RIPE NCC Service Region", RIPE-302, April 26,
-
-
-
-Senie                                                           [Page 5]
-
-Internet-Draft Encouraging the use of DNS IN-ADDR Mapping      July 2005
-
-
-   2004. http://www.ripe.net//ripe/docs/rev-del.html
-
-
-
-8. Acknowledgements
-
-   Thanks to Peter Koch and Gary Miller for their input, and to many
-   people who encouraged me to write this document.
-
-9. Author's Address
-
-   Daniel Senie
-   Amaranth Networks Inc.
-   324 Still River Road
-   Bolton, MA 01740
-
-   Phone: (978) 779-5100
-
-   EMail: dts@senie.com
-
-10.  Full Copyright Statement
-
-      Copyright (C) The Internet Society (2005).
-
-      This document is subject to the rights, licenses and restrictions
-      contained in BCP 78, and except as set forth therein, the authors
-      retain all their rights.
-
-      This document and the information contained herein are provided
-      on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
-      REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
-      THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
-      EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
-      THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
-      ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
-      PARTICULAR PURPOSE.
-
-Intellectual Property
-
-      The IETF takes no position regarding the validity or scope of any
-      Intellectual Property Rights or other rights that might be claimed
-      to pertain to the implementation or use of the technology
-      described in this document or the extent to which any license
-      under such rights might or might not be available; nor does it
-      represent that it has made any independent effort to identify any
-      such rights.  Information on the procedures with respect to
-      rights in RFC documents can be found in BCP 78 and BCP 79.
-
-
-
-
-Senie                                                           [Page 6]
-
-Internet-Draft Encouraging the use of DNS IN-ADDR Mapping      July 2005
-
-
-      Copies of IPR disclosures made to the IETF Secretariat and any
-      assurances of licenses to be made available, or the result of an
-      attempt made to obtain a general license or permission for the use
-      of such proprietary rights by implementers or users of this
-      specification can be obtained from the IETF on-line IPR repository
-      at http://www.ietf.org/ipr.
-
-      The IETF invites any interested party to bring to its attention
-      any copyrights, patents or patent applications, or other
-      proprietary rights that may cover technology that may be required
-      to implement this standard.  Please address the information to the
-      IETF at ietf-ipr@ietf.org.
-
-      Internet-Drafts are working documents of the
-      Internet Engineering Task Force (IETF), its areas, and its
-      working groups. Note that other groups may also distribute
-      working documents as Internet-Drafts.
-
-      Internet-Drafts are draft documents valid for a maximum of
-      six months and may be updated, replaced, or obsoleted by
-      other documents at any time. It is inappropriate to use
-      Internet-Drafts as reference material or to cite them other
-      than as "work in progress."
-
-      The list of current Internet-Drafts can be accessed at
-      http://www.ietf.org/1id-abstracts.html
-
-      The list of Internet-Draft Shadow Directories can be
-      accessed at http://www.ietf.org/shadow.html
-
-Acknowledgement
-
-      Funding for the RFC Editor function is currently provided by the
-      Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Senie                                                           [Page 7]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt
deleted file mode 100644
index bf2afcd..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt
+++ /dev/null
@@ -1,1848 +0,0 @@
-
-
-
-DNS Operations WG                                          J. Jeong, Ed.
-Internet-Draft                              ETRI/University of Minnesota
-Expires: November 6, 2005                                    May 5, 2005
-
-
-      IPv6 Host Configuration of DNS Server Information Approaches
-             draft-ietf-dnsop-ipv6-dns-configuration-06.txt
-
-Status of this Memo
-
-   This document is an Internet-Draft and is subject to all provisions
-   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
-   author represents that any applicable patent or other IPR claims of
-   which he or she is aware have been or will be disclosed, and any of
-   which he or she become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on November 6, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document describes three approaches for IPv6 recursive DNS
-   server address configuration.  It details the operational attributes
-   of three solutions: RA option, DHCPv6 option, and Well-known anycast
-   addresses for recursive DNS servers.  Additionally, it suggests the
-   deployment scenarios in four kinds of networks, such as ISP,
-   Enterprise, 3GPP, and Unmanaged networks, considering multi-solution
-   resolution.  Therefore, this document will give the audience a
-
-
-
-Jeong                   Expires November 6, 2005                [Page 1]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-   guideline for IPv6 host DNS configuration.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jeong                   Expires November 6, 2005                [Page 2]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
-   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
-   3.  IPv6 DNS Configuration Approaches  . . . . . . . . . . . . . .  7
-     3.1   RA Option  . . . . . . . . . . . . . . . . . . . . . . . .  7
-       3.1.1   Advantages . . . . . . . . . . . . . . . . . . . . . .  8
-       3.1.2   Disadvantages  . . . . . . . . . . . . . . . . . . . .  8
-       3.1.3   Observations . . . . . . . . . . . . . . . . . . . . .  9
-     3.2   DHCPv6 Option  . . . . . . . . . . . . . . . . . . . . . .  9
-       3.2.1   Advantages . . . . . . . . . . . . . . . . . . . . . . 11
-       3.2.2   Disadvantages  . . . . . . . . . . . . . . . . . . . . 12
-       3.2.3   Observations . . . . . . . . . . . . . . . . . . . . . 12
-     3.3   Well-known Anycast Addresses . . . . . . . . . . . . . . . 12
-       3.3.1   Advantages . . . . . . . . . . . . . . . . . . . . . . 13
-       3.3.2   Disadvantages  . . . . . . . . . . . . . . . . . . . . 14
-       3.3.3   Observations . . . . . . . . . . . . . . . . . . . . . 14
-   4.  Interworking among IPv6 DNS Configuration Approaches . . . . . 15
-   5.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 16
-     5.1   ISP Network  . . . . . . . . . . . . . . . . . . . . . . . 16
-       5.1.1   RA Option Approach . . . . . . . . . . . . . . . . . . 16
-       5.1.2   DHCPv6 Option Approach . . . . . . . . . . . . . . . . 17
-       5.1.3   Well-known Anycast Addresses Approach  . . . . . . . . 17
-     5.2   Enterprise Network . . . . . . . . . . . . . . . . . . . . 17
-     5.3   3GPP Network . . . . . . . . . . . . . . . . . . . . . . . 18
-       5.3.1   Currently Available Mechanisms and Recommendations . . 19
-       5.3.2   RA Extension . . . . . . . . . . . . . . . . . . . . . 19
-       5.3.3   Stateless DHCPv6 . . . . . . . . . . . . . . . . . . . 20
-       5.3.4   Well-known Addresses . . . . . . . . . . . . . . . . . 21
-       5.3.5   Recommendations  . . . . . . . . . . . . . . . . . . . 21
-     5.4   Unmanaged Network  . . . . . . . . . . . . . . . . . . . . 22
-       5.4.1   Case A: Gateway does not provide IPv6 at all . . . . . 22
-       5.4.2   Case B: A dual-stack gateway connected to a
-               dual-stack ISP . . . . . . . . . . . . . . . . . . . . 22
-       5.4.3   Case C: A dual-stack gateway connected to an
-               IPv4-only ISP  . . . . . . . . . . . . . . . . . . . . 22
-       5.4.4   Case D: A gateway connected to an IPv6-only ISP  . . . 23
-   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 24
-     6.1   RA Option  . . . . . . . . . . . . . . . . . . . . . . . . 25
-     6.2   DHCPv6 Option  . . . . . . . . . . . . . . . . . . . . . . 25
-     6.3   Well-known Anycast Addresses . . . . . . . . . . . . . . . 25
-   7.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26
-   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
-   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
-     9.1   Normative References . . . . . . . . . . . . . . . . . . . 29
-     9.2   Informative References . . . . . . . . . . . . . . . . . . 29
-       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 31
-   A.  Link-layer Multicast Acknowledgements for RA Option  . . . . . 32
-
-
-
-Jeong                   Expires November 6, 2005                [Page 3]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-       Intellectual Property and Copyright Statements . . . . . . . . 33
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jeong                   Expires November 6, 2005                [Page 4]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-1.  Introduction
-
-   Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address
-   Autoconfiguration provide the ways to configure either fixed or
-   mobile nodes with one or more IPv6 addresses, default routes and some
-   other parameters [3][4].  To support the access to additional
-   services in the Internet that are identified by a DNS name, such as a
-   web server, the configuration of at least one recursive DNS server is
-   also needed for DNS name resolution.
-
-   This document describes three approaches of recursive DNS server
-   address configuration for IPv6 host: (a) RA option [8], (b) DHCPv6
-   option [5]-[7], and (c) Well-known anycast addresses for recursive
-   DNS servers [9].  Also, it suggests the applicable scenarios for four
-   kinds of networks: (a) ISP network, (b) Enterprise network, (c) 3GPP
-   network, and (d) Unmanaged network.
-
-   This document is just an analysis of each possible approach, and does
-   not make any recommendation on a particular one or on a combination
-   of particular ones.  Some approaches may even not be adopted at all
-   as a result of further discussion.
-
-   Therefore, the objective of this document is to help the audience
-   select the approaches suitable for IPv6 host configuration of
-   recursive DNS servers.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jeong                   Expires November 6, 2005                [Page 5]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-2.  Terminology
-
-   This document uses the terminology described in [3]-[9].  In
-   addition, a new term is defined below:
-
-   o  Recursive DNS Server (RDNSS): A Recursive DNS Server is a name
-      server that offers the recursive service of DNS name resolution.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jeong                   Expires November 6, 2005                [Page 6]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-3.  IPv6 DNS Configuration Approaches
-
-   In this section, the operational attributes of the three solutions
-   are described in detail.
-
-3.1  RA Option
-
-   The RA approach is to define a new ND option called the RDNSS option
-   that contains a recursive DNS server address.  Existing ND transport
-   mechanisms (i.e., advertisements and solicitations) are used.  This
-   works in the same way that nodes learn about routers and prefixes.
-   An IPv6 host can configure the IPv6 addresses of one or more RDNSSes
-   via RA message periodically sent by a router or solicited by a Router
-   Solicitation (RS) [8].
-
-   This approach needs RDNSS information to be configured in the routers
-   doing the advertisements.  The configuration of RDNSS addresses can
-   be performed manually by an operator or other ways, such as automatic
-   configuration through a DHCPv6 client running on the router.  When
-   advertising more than one RDNSS option, an RA message includes as
-   many RDNSS options as RDNSSes.
-
-   Through the ND protocol and RDNSS option along with a prefix
-   information option, an IPv6 host can perform its network
-   configuration of its IPv6 address and RDNSS simultaneously [3][4].
-   The RA option for RDNSS can be used on any network that supports the
-   use of ND.
-
-   However, it is worth noting that some link layers, such as Wireless
-   LANs (e.g., IEEE 802.11 a/b/g), do not support reliable multicast,
-   which means that they cannot guarantee the timely delivery of RA
-   messages [25]-[28].  This is discussed in Appendix A.
-
-   The RA approach is useful in some mobile environments where the
-   addresses of the RDNSSes are changing because the RA option includes
-   a lifetime field that allows client to use RDNSSes nearer to the
-   client.  This can be configured to a value that will require the
-   client to time out the entry and switch over to another RDNSS address
-   [8].  However, from the viewpoint of implementation, the lifetime
-   field would seem to make matters a bit more complex.  Instead of just
-   writing to a DNS configuration file, such as resolv.conf for the list
-   of RDNSS addresses, we have to have a daemon around (or a program
-   that is called at the defined intervals) that keeps monitoring the
-   lifetime of RDNSSes all the time.
-
-   The preference value of RDNSS, included in the RDNSS option, allows
-   IPv6 hosts to select primary RDNSS among several RDNSSes; this can be
-   used for the load balancing of RDNSSes [8].
-
-
-
-Jeong                   Expires November 6, 2005                [Page 7]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-3.1.1  Advantages
-
-   The RA option for RDNSS has a number of advantages.  These include:
-
-   1.  The RA option is an extension of existing ND/Autoconfig
-       mechanisms [3][4], and does not require a change in the base ND
-       protocol.
-
-   2.  This approach, like ND, works well on a variety of link types
-       including point-to-point links, point-to-multipoint, and
-       multipoint-to-multipoint (i.e., Ethernet LANs), etc.  RFC 2461
-       [3] states, however, that there may be some link types on which
-       ND is not feasible; on such links, some other mechanisms will be
-       needed for DNS configuration.
-
-   3.  All of the information a host needs to run the basic Internet
-       applications such as the email, web, ftp, etc., can be obtained
-       with the addition of this option to ND and address
-       autoconfiguration.  The use of a single mechanism is more
-       reliable and easier to provide than when the RDNSS information is
-       learned via another protocol mechanism.  Debugging problems when
-       multiple protocol mechanisms are being used is harder and much
-       more complex.
-
-   4.  This mechanism works over a broad range of scenarios and
-       leverages IPv6 ND.  This works well on links that support
-       broadcast reliably (e.g., Ethernet LANs) but not necessarily on
-       other links (e.g., Wireless LANs): Refer to Appendix A.  Also,
-       this works well on links that are high performance (e.g.,
-       Ethernet LANs) and low performance (e.g., Cellular networks).  In
-       the latter case, by combining the RDNSS information with the
-       other information in the RA, the host can learn all of the
-       information needed to use most Internet applications, such as the
-       web in a single packet.  This not only saves bandwidth where this
-       is an issue, but also minimizes the delay needed to learn the
-       RDNSS information.
-
-   5.  The RA approach could be used as a model for other similar types
-       of configuration information.  New RA options for other server
-       addresses, such as NTP server address, that are common to all
-       clients on a subnet would be easy to define.
-
-
-3.1.2  Disadvantages
-
-   1.  ND is mostly implemented in the kernel of operating system.
-       Therefore, if ND supports the configuration of some additional
-       services, such as DNS servers, ND should be extended in the
-
-
-
-Jeong                   Expires November 6, 2005                [Page 8]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-       kernel, and complemented by a user-land process.  DHCPv6,
-       however, has more flexibility for the extension of service
-       discovery because it is an application layer protocol.
-
-   2.  The current ND framework should be modified to facilitate the
-       synchronization between another ND cache for RDNSSes in the
-       kernel space and the DNS configuration file in the user space.
-       Because it is unacceptable to write and rewrite to the DNS
-       configuration file (e.g., resolv.conf) from the kernel, another
-       approach is needed.  One simple approach to solve this is to have
-       a daemon listening to what the kernel conveys, and to have the
-       daemon do these steps, but such a daemon is not needed with the
-       current ND framework.
-
-   3.  It is necessary to configure RDNSS addresses at least at one
-       router on every link where this information needs to be
-       configured via the RA option.
-
-
-3.1.3  Observations
-
-   The proposed RDNSS RA option along with the IPv6 ND and
-   Autoconfiguration allows a host to obtain all of the information it
-   needs to access the basic Internet services like the web, email, ftp,
-   etc.  This is preferable in the environments where hosts use RAs to
-   autoconfigure their addresses and all the hosts on the subnet share
-   the same router and server addresses.  If the configuration
-   information can be obtained from a single mechanism, it is preferable
-   because it does not add additional delay, and it uses a minimum of
-   bandwidth.  The environments like this include the homes, public
-   cellular networks, and enterprise environments where no per host
-   configuration is needed, but exclude public WLAN hot spots.
-
-   DHCPv6 is preferable where it is being used for address configuration
-   and if there is a need for host specific configuration [5]-[7].  The
-   environments like this are most likely to be the enterprise
-   environments where the local administration chooses to have per host
-   configuration control.
-
-Note
-
-   The observation section is based on what the proponents of each
-   approach think makes a good overall solution.
-
-3.2  DHCPv6 Option
-
-   DHCPv6 [5] includes the "DNS Recursive Name Server" option, through
-   which a host can obtain a list of IP addresses of recursive DNS
-
-
-
-Jeong                   Expires November 6, 2005                [Page 9]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-   servers [7].  The DNS Recursive Name Server option carries a list of
-   IPv6 addresses of RDNSSes to which the host may send DNS queries.
-   The DNS servers are listed in the order of preference for use by the
-   DNS resolver on the host.
-
-   The DNS Recursive Name Server option can be carried in any DHCPv6
-   Reply message, in response to either a Request or an Information
-   request message.  Thus, the DNS Recursive Name Server option can be
-   used either when DHCPv6 is used for address assignment, or when
-   DHCPv6 is used only for other configuration information as stateless
-   DHCPv6 [6].
-
-   Stateless DHCPv6 can be deployed either using DHCPv6 servers running
-   on general-purpose computers, or on router hardware.  Several router
-   vendors currently implement stateless DHCPv6 servers.  Deploying
-   stateless DHCPv6 in routers has the advantage that no special
-   hardware is required, and should work well for networks where DHCPv6
-   is needed for very straightforward configuration of network devices.
-
-   However, routers can also act as DHCPv6 relay agents.  In this case,
-   the DHCPv6 server need not be on the router - it can be on a general
-   purpose computer.  This has the potential to give the operator of the
-   DHCPv6 server more flexibility in how the DHCPv6 server responds to
-   individual clients - clients can easily be given different
-   configuration information based on their identity, or for any other
-   reason.  Nothing precludes adding this flexibility to a router, but
-   generally in current practice, DHCP servers running on general-
-   purpose hosts tend to have more configuration options than those that
-   are embedded in routers.
-
-   DHCPv6 currently provides a mechanism for reconfiguring DHCPv6
-   clients that use a stateful configuration assignment.  To do this,
-   the DHCPv6 server sends a Reconfigure message to the client.  The
-   client validates the Reconfigure message, and then contacts the
-   DHCPv6 server to obtain updated configuration information.  Using
-   this mechanism, it is currently possible to propagate new
-   configuration information to DHCPv6 clients as this information
-   changes.
-
-   The DHC Working Group is currently studying an additional mechanism
-   through which configuration information, including the list of
-   RDNSSes, can be updated.  The lifetime option for DHCPv6 [10] assigns
-   a lifetime to configuration information obtained through DHCPv6.  At
-   the expiration of the lifetime, the host contacts the DHCPv6 server
-   to obtain updated configuration information, including the list of
-   RDNSSes.  This lifetime gives the network administrator another
-   mechanism to configure hosts with new RDNSSes by controlling the time
-   at which the host refreshes the list.
-
-
-
-Jeong                   Expires November 6, 2005               [Page 10]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-   The DHC Working Group has also discussed the possibility of defining
-   an extension to DHCPv6 that would allow the use of multicast to
-   provide configuration information to multiple hosts with a single
-   DHCPv6 message.  Because of the lack of deployment experience, the WG
-   has deferred consideration of multicast DHCPv6 configuration at this
-   time.  Experience with DHCPv4 has not identified a requirement for
-   multicast message delivery, even in large service provider networks
-   with tens of thousands of hosts that may initiate a DHCPv4 message
-   exchange simultaneously.
-
-3.2.1  Advantages
-
-   The DHCPv6 option for RDNSS has a number of advantages.  These
-   include:
-
-   1.  DHCPv6 currently provides a general mechanism for conveying
-       network configuration information to clients.  So configuring
-       DHCPv6 servers allows the network administrator to configure
-       RDNSSes along with the addresses of other network services, as
-       well as location-specific information like time zones.
-
-   2.  As a consequence, when the network administrator goes to
-       configure DHCPv6, all the configuration information can be
-       managed through a single service, typically with a single user
-       interface and a single configuration database.
-
-   3.  DHCPv6 allows for the configuration of a host with information
-       specific to that host, so that hosts on the same link can be
-       configured with different RDNSSes as well as with other
-       configuration information.  This capability is important in some
-       network deployments such as service provider networks or WiFi hot
-       spots.
-
-   4.  A mechanism exists for extending DHCPv6 to support the
-       transmission of additional configuration that has not yet been
-       anticipated.
-
-   5.  Hosts that require other configuration information such as the
-       addresses of SIP servers and NTP servers are likely to need
-       DHCPv6 for other configuration information.
-
-   6.  The specification for configuration of RDNSSes through DHCPv6 is
-       available as an RFC.  No new protocol extensions such as new
-       options are necessary.
-
-   7.  Interoperability among independent implementations has been
-       demonstrated.
-
-
-
-
-Jeong                   Expires November 6, 2005               [Page 11]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-3.2.2  Disadvantages
-
-   The DHCPv6 option for RDNSS has a few disadvantages.  These include:
-
-   1.  Update currently requires message from server (however, see
-       [10]).
-
-   2.  Because DNS information is not contained in RA messages, the host
-       must receive two messages from the router, and must transmit at
-       least one message to the router.  On networks where bandwidth is
-       at a premium, this is a disadvantage, although on most networks
-       it is not a practical concern.
-
-   3.  Increased latency for initial configuration - in addition to
-       waiting for an RA message, the client must now exchange packets
-       with a DHCPv6 server; even if it is locally installed on a
-       router, this will slightly extend the time required to configure
-       the client.  For clients that are moving rapidly from one network
-       to another, this will be a disadvantage.
-
-
-3.2.3  Observations
-
-   In the general case, on general-purpose networks, stateless DHCPv6
-   provides significant advantages and no significant disadvantages.
-   Even in the case where bandwidth is at a premium and low latency is
-   desired, if hosts require other configuration information in addition
-   to a list of RDNSSes or if hosts must be configured selectively,
-   those hosts will use DHCPv6 and the use of the DHCPv6 DNS recursive
-   name server option will be advantageous.
-
-   However, we are aware of some applications where it would be
-   preferable to put the RDNSS information into an RA packet; for
-   example, on a cell phone network, where bandwidth is at a premium and
-   extremely low latency is desired.  The final DNS configuration draft
-   should be written so as to allow these special applications to be
-   handled using DNS information in the RA packet.
-
-3.3  Well-known Anycast Addresses
-
-   Anycast uses the same routing system as unicast [11].  However,
-   administrative entities are local ones.  The local entities may
-   accept unicast routes (including default routes) to anycast servers
-   from adjacent entities.  The administrative entities should not
-   advertise their peers routes to their internal anycast servers, if
-   they want to prohibit external access from some peers to the servers.
-   If some advertisement is inevitable (such as the case with default
-   routes), the packets to the servers should be blocked at the boundary
-
-
-
-Jeong                   Expires November 6, 2005               [Page 12]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-   of the entities.  Thus, for this anycast, not only unicast routing
-   but also unicast ND protocols can be used as is.
-
-   First of all, the well-known anycast addresses approach is much
-   different from that discussed at IPv6 Working Group in the past [9].
-   It should be noted that "anycast" in this memo is simpler than that
-   of RFC 1546 [11] and RFC 3513 [12] where it is assumed to be
-   prohibited to have multiple servers on a single link sharing an
-   anycast address.  That is, on a link, an anycast address is assumed
-   to be unique.  DNS clients today already have redundancy by having
-   multiple well-known anycast addresses configured as RDNSS addresses.
-   There is no point in having multiple RDNSSes sharing an anycast
-   address on a single link.
-
-   The approach with well-known anycast addresses is to set multiple
-   well-known anycast addresses in clients' resolver configuration files
-   from the beginning, say, as factory default.  Thus, there is no
-   transport mechanism and no packet format [9].
-
-   An anycast address is an address shared by multiple servers (in this
-   case, the servers are RDNSSes).  A request from a client to the
-   anycast address is routed to a server selected by the routing system.
-   However, it is a bad idea to mandate "site" boundary on anycast
-   addresses, because most users just do not have their own servers and
-   want to access their ISPs' across their site boundaries.  Larger
-   sites may also depend on their ISPs or may have their own RDNSSes
-   within "site" boundaries.
-
-3.3.1  Advantages
-
-   The basic advantage of the well-known addresses approach is that it
-   uses no transport mechanism.  Thus,
-
-   1.  There is no delay to get the response and no further delay by
-       packet losses.
-
-   2.  The approach can be combined with any other configuration
-       mechanisms, such as the RA-based approach and DHCP based
-       approach, as well as the factory default configuration.
-
-   3.  The approach works over any environment where DNS works.
-
-   Another advantage is that the approach needs to configure DNS servers
-   as a router, but nothing else.  Considering that DNS servers do need
-   configuration, the amount of overall configuration effort is
-   proportional to the number of the DNS servers and scales linearly.
-   It should be noted that, in the simplest case where a subscriber to
-   an ISP does not have any DNS server, the subscriber naturally
-
-
-
-Jeong                   Expires November 6, 2005               [Page 13]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-   accesses DNS servers of the ISP even though the subscriber and the
-   ISP do nothing and there is no protocol to exchange DNS server
-   information between the subscriber and the ISP.
-
-3.3.2  Disadvantages
-
-   Well-known anycast addresses approach requires that DNS servers (or
-   routers near it as a proxy) act as routers to advertise their anycast
-   addresses to the routing system, which requires some configuration
-   (see the last paragraph of the previous section on the scalability of
-   the effort).
-
-3.3.3  Observations
-
-   If other approaches are used in addition, the well-known anycast
-   addresses should also be set in RA or DHCP configuration files to
-   reduce the configuration effort of users.
-
-   The redundancy by multiple RDNSSes is better provided by multiple
-   servers having different anycast addresses than multiple servers
-   sharing the same anycast address because the former approach allows
-   stale servers to still generate routes to their anycast addresses.
-   Thus, in a routing domain (or domains sharing DNS servers), there
-   will be only one server having an anycast address unless the domain
-   is so large that load distribution is necessary.
-
-   Small ISPs will operate one RDNSS at each anycast address which is
-   shared by all the subscribers.  Large ISPs may operate multiple
-   RDNSSes at each anycast address to distribute and reduce load, where
-   the boundary between RDNSSes may be fixed (redundancy is still
-   provided by multiple addresses) or change dynamically.  DNS packets
-   with the well-known anycast addresses are not expected (though not
-   prohibited) to cross ISP boundaries, as ISPs are expected to be able
-   to take care of themselves.
-
-   Because "anycast" in this memo is simpler than that of RFC 1546 [11]
-   and RFC 3513 [12] where it is assumed to be administratively
-   prohibited to have multiple servers on a single link sharing an
-   anycast address, anycast in this memo should be implemented as
-   UNICAST of RFC 2461 [3] and RFC 3513 [12].  As a result, ND-related
-   instability disappears.  Thus, anycast in well-known anycast
-   addresses approach can and should use the anycast address as a source
-   unicast (according to RFC 3513 [12]) address of packets of UDP and
-   TCP responses.  With TCP, if a route flips and packets to an anycast
-   address are routed to a new server, it is expected that the flip is
-   detected by ICMP or sequence number inconsistency and the TCP
-   connection is reset and retried.
-
-
-
-
-Jeong                   Expires November 6, 2005               [Page 14]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-4.  Interworking among IPv6 DNS Configuration Approaches
-
-   Three approaches can work together for IPv6 host configuration of
-   RDNSS.  This section shows a consideration on how these approaches
-   can interwork each other.
-
-   For ordering between RA and DHCP approaches, the O (Other stateful
-   configuration) flag in RA message can be used [8][32].  If no RDNSS
-   option is included, an IPv6 host may perform DNS configuration
-   through DHCPv6 [5]-[7] regardless of whether the O flag is set or
-   not.
-
-   The well-known anycast addresses approach fully interworks with the
-   other approaches.  That is, the other approaches can remove the
-   configuration effort on servers by using the well-known addresses as
-   the default configuration.  Moreover, the clients preconfigured with
-   the well-known anycast addresses can be further configured to use
-   other approaches to override the well-known addresses, if the
-   configuration information from other approaches is available.
-   Otherwise, all the clients need to have the well-known anycast
-   addresses preconfigured.  In order to use the anycast approach along
-   with two other approaches, there are three choices as follows:
-
-   1.  The first choice is that well-known addresses are used as last
-       resort, when an IPv6 host cannot get RDNSS information through RA
-       and DHCP.  The well-known anycast addresses have to be
-       preconfigured in all of IPv6 hosts' resolver configuration files.
-
-   2.  The second is that an IPv6 host can configure well-known
-       addresses as the most preferable in its configuration file even
-       though either an RA option or DHCP option is available.
-
-   3.  The last is that the well-known anycast addresses can be set in
-       RA or DHCP configuration to reduce the configuration effort of
-       users.  According to either the RA or DHCP mechanism, the well-
-       known addresses can be obtained by an IPv6 host.  Because this
-       approach is the most convenient for users, the last option is
-       recommended.
-
-
-Note
-
-   This section does not necessarily mean this document suggests
-   adopting all these three approaches and making them interwork in the
-   way described here.  In fact, some approaches may even not be adopted
-   at all as a result of further discussion.
-
-
-
-
-
-Jeong                   Expires November 6, 2005               [Page 15]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-5.  Deployment Scenarios
-
-   Regarding the DNS configuration on the IPv6 host, several mechanisms
-   are being considered at the DNSOP Working Group such as RA option,
-   DHCPv6 option and well-known preconfigured anycast addresses as of
-   today, and this document is a final result from the long thread.  In
-   this section, we suggest four applicable scenarios of three
-   approaches for IPv6 DNS configuration.
-
-Note
-
-   In the applicable scenarios, authors do not implicitly push any
-   specific approaches into the restricted environments.  No enforcement
-   is in each scenario and all mentioned scenarios are probable.  The
-   main objective of this work is to provide a useful guideline for IPv6
-   DNS configuration.
-
-5.1  ISP Network
-
-   A characteristic of ISP network is that multiple Customer Premises
-   Equipment (CPE) devices are connected to IPv6 PE (Provider Edge)
-   routers and each PE connects multiple CPE devices to the backbone
-   network infrastructure [13].  The CPEs may be hosts or routers.
-
-   In the case where the CPE is a router, there is a customer network
-   that is connected to the ISP backbone through the CPE.  Typically,
-   each customer network gets a different IPv6 prefix from an IPv6 PE
-   router, but the same RDNSS configuration will be distributed.
-
-   This section discusses how the different approaches to distributing
-   DNS information are compared in an ISP network.
-
-5.1.1  RA Option Approach
-
-   When the CPE is a host, the RA option for RDNSS can be used to allow
-   the CPE to get RDNSS information as well as /64 prefix information
-   for stateless address autoconfiguration at the same time when the
-   host is attached to a new subnet [8].  Because an IPv6 host must
-   receive at least one RA message for stateless address
-   autoconfiguration and router configuration, the host could receive
-   RDNSS configuration information in that RA without the overhead of an
-   additional message exchange.
-
-   When the CPE is a router, the CPE may accept the RDNSS information
-   from the RA on the interface connected to the ISP, and copy that
-   information into the RAs advertised in the customer network.
-
-   This approach is more valuable in the mobile host scenario, in which
-
-
-
-Jeong                   Expires November 6, 2005               [Page 16]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-   the host must receive at least an RA message for detecting a new
-   network, than in other scenarios generally although administrator
-   should configure RDNSS information on the routers.  Secure ND [14]
-   can provide extended security when using RA messages.
-
-5.1.2  DHCPv6 Option Approach
-
-   DHCPv6 can be used for RDNSS configuration through the use of the DNS
-   option, and can provide other configuration information in the same
-   message with RDNSS configuration [5]-[7].  The DHCPv6 DNS option is
-   already in place for DHCPv6 as RFC 3646 [7] and DHCPv6-lite or
-   stateless DHCP [6] is nowhere as complex as a full DHCPv6
-   implementation.  DHCP is a client-server model protocol, so ISPs can
-   handle user identification on its network intentionally, and also
-   authenticated DHCP [15] can be used for secure message exchange.
-
-   The expected model for deployment of IPv6 service by ISPs is to
-   assign a prefix to each customer, which will be used by the customer
-   gateway to assign a /64 prefix to each network in the customer's
-   network.  Prefix delegation with DHCP (DHCPv6 PD) has already been
-   adopted by ISPs for automating the assignment of the customer prefix
-   to the customer gateway [17].  DNS configuration can be carried in
-   the same DHCPv6 message exchange used for DHCPv6 to efficiently
-   provide that information, along with any other configuration
-   information needed by the customer gateway or customer network.  This
-   service model can be useful to Home or SOHO subscribers.  The Home or
-   SOHO gateway, which is a customer gateway for ISP, can then pass that
-   RDNSS configuration information to the hosts in the customer network
-   through DHCP.
-
-5.1.3  Well-known Anycast Addresses Approach
-
-   The well-known anycast addresses approach is also a feasible and
-   simple mechanism for ISP [9].  The use of well-known anycast
-   addresses avoids some of the security risks in rogue messages sent
-   through an external protocol like RA or DHCPv6.  The configuration of
-   hosts for the use of well-known anycast addresses requires no
-   protocol or manual configuration, but the configuration of routing
-   for the anycast addresses requires intervention on the part of the
-   network administrator.  Also, the number of special addresses would
-   be equal to the number of RDNSSes that could be made available to
-   subscribers.
-
-5.2  Enterprise Network
-
-   Enterprise network is defined as a network that has multiple internal
-   links, one or more router connections, to one or more Providers and
-   is actively managed by a network operations entity [16].  An
-
-
-
-Jeong                   Expires November 6, 2005               [Page 17]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-   enterprise network can get network prefixes from an ISP by either
-   manual configuration or prefix delegation [17].  In most cases,
-   because an enterprise network manages its own DNS domains, it
-   operates its own DNS servers for the domains.  These DNS servers
-   within enterprise network process recursive DNS name resolution
-   requests from IPv6 hosts as RDNSSes.  The RDNSS configuration in the
-   enterprise network can be performed like in Section 4, in which three
-   approaches can be used together as follows:
-
-   1.  An IPv6 host can decide which approach is or may be used in its
-       subnet with the O flag in RA message [8][32].  As the first
-       choice in Section 4, well-known anycast addresses can be used as
-       a last resort when RDNSS information cannot be obtained through
-       either an RA option or DHCP option.  This case needs IPv6 hosts
-       to preconfigure the well-known anycast addresses in their DNS
-       configuration files.
-
-   2.  When the enterprise prefers the well-known anycast approach to
-       others, IPv6 hosts should preconfigure the well-known anycast
-       addresses like in the first choice.
-
-   3.  The last choice, a more convenient and transparent way, does not
-       need IPv6 hosts to preconfigure the well-known anycast addresses
-       because the addresses are delivered to IPv6 hosts via either the
-       RA option or DHCPv6 option as if they were unicast addresses.
-       This way is most recommended for the sake of user's convenience.
-
-
-5.3  3GPP Network
-
-   The IPv6 DNS configuration is a missing part of IPv6
-   autoconfiguration and an important part of the basic IPv6
-   functionality in the 3GPP User Equipment (UE).  The higher level
-   description of the 3GPP architecture can be found in [18], and
-   transition to IPv6 in 3GPP networks is analyzed in [19] and [20].
-
-   In the 3GPP architecture, there is a dedicated link between the UE
-   and the GGSN called the Packet Data Protocol (PDP) Context.  This
-   link is created through the PDP Context activation procedure [21].
-   There is a separate PDP context type for IPv4 and IPv6 traffic.  If a
-   3GPP UE user is communicating using IPv6 (having an active IPv6 PDP
-   context), it cannot be assumed that (s)he has simultaneously an
-   active IPv4 PDP context, and DNS queries could be done using IPv4.  A
-   3GPP UE can thus be an IPv6 node, and it needs to somehow discover
-   the address of the RDNSS.  Before IP-based services (e.g., web
-   browsing or e-mail) can be used, the IPv6 (and IPv4) RDNSS addresses
-   need to be discovered in the 3GPP UE.
-
-
-
-
-Jeong                   Expires November 6, 2005               [Page 18]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-   Section 5.3.1 briefly summarizes currently available mechanisms in
-   3GPP networks and recommendations. 5.3.2 analyzes the Router
-   Advertisement based solution, 5.3.3 analyzes the Stateless DHCPv6
-   mechanism, and 5.3.4 analyzes the Well-known addresses approach.
-   Section 5.3.5 finally summarizes the recommendations.
-
-5.3.1  Currently Available Mechanisms and Recommendations
-
-   3GPP has defined a mechanism, in which RDNSS addresses can be
-   received in the PDP context activation (a control plane mechanism).
-   That is called the Protocol Configuration Options Information Element
-   (PCO-IE) mechanism [22].  The RDNSS addresses can also be received
-   over the air (using text messages), or typed in manually in the UE.
-   Note that the two last mechanisms are not very well scalable.  The UE
-   user most probably does not want to type IPv6 RDNSS addresses
-   manually in his/her UE.  The use of well-known addresses is briefly
-   discussed in section 5.3.4.
-
-   It is seen that the mechanisms above most probably are not sufficient
-   for the 3GPP environment.  IPv6 is intended to operate in a zero-
-   configuration manner, no matter what the underlying network
-   infrastructure is.  Typically, the RDNSS address is needed to make an
-   IPv6 node operational - and the DNS configuration should be as simple
-   as the address autoconfiguration mechanism.  It must also be noted
-   that there will be additional IP interfaces in some near future 3GPP
-   UEs, e.g., WLAN, and 3GPP-specific DNS configuration mechanisms (such
-   as PCO-IE [22]) do not work for those IP interfaces.  In other words,
-   a good IPv6 DNS configuration mechanism should also work in a multi-
-   access network environment.
-
-   From a 3GPP point of view, the best IPv6 DNS configuration solution
-   is feasible for a very large number of IPv6-capable UEs (can be even
-   hundreds of millions in one operator's network), is automatic and
-   thus requires no user action.  It is suggested to standardize a
-   lightweight, stateless mechanism that works in all network
-   environments.  The solution could then be used for 3GPP, 3GPP2, WLAN
-   and other access network technologies.  A light, stateless IPv6 DNS
-   configuration mechanism is thus not only needed in 3GPP networks, but
-   also 3GPP networks and UEs would certainly benefit from the new
-   mechanism.
-
-5.3.2  RA Extension
-
-   Router Advertisement extension [8] is a lightweight IPv6 DNS
-   configuration mechanism that requires minor changes in the 3GPP UE
-   IPv6 stack and Gateway GPRS Support Node (GGSN, the default router in
-   the 3GPP architecture) IPv6 stack.  This solution can be specified in
-   the IETF (no action needed in the 3GPP) and taken in use in 3GPP UEs
-
-
-
-Jeong                   Expires November 6, 2005               [Page 19]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-   and GGSNs
-
-   In this solution, an IPv6-capable UE configures DNS information via
-   RA message sent by its default router (GGSN), i.e., RDNSS option for
-   recursive DNS server is included in the RA message.  This solution is
-   easily scalable for a very large number of UEs.  The operator can
-   configure the RDNSS addresses in the GGSN as a part of normal GGSN
-   configuration.  The IPv6 RDNSS address is received in the Router
-   Advertisement, and an extra Round Trip Time (RTT) for asking RDNSS
-   addresses can be avoided.
-
-   If thinking about the cons, this mechanism still requires
-   standardization effort in the IETF, and the end nodes and routers
-   need to support this mechanism.  The equipment software update
-   should, however, be pretty straightforward, and new IPv6 equipment
-   could support RA extension already from the beginning.
-
-5.3.3  Stateless DHCPv6
-
-   DHCPv6-based solution needs the implementation of Stateless DHCP [6]
-   and DHCPv6 DNS options [7] in the UE, and a DHCPv6 server in the
-   operator's network.  A possible configuration is such that the GGSN
-   works as a DHCP relay.
-
-   Pros for Stateless DHCPv6-based solution are
-
-   1.  Stateless DHCPv6 is a standardized mechanism.
-
-   2.  DHCPv6 can be used for receiving other configuration information
-       than RDNSS addresses, e.g., SIP server addresses.
-
-   3.  DHCPv6 works in different network environments.
-
-   4.  When DHCPv6 service is deployed through a single, centralized
-       server, the RDNSS configuration information can be updated by the
-       network administrator at a single source.
-
-   Some issues with DHCPv6 in 3GPP networks are listed below:
-
-   1.  DHCPv6 requires an additional server in the network unless the
-       (Stateless) DHCPv6 functionality is integrated into a router
-       already existing, and that means one box more to be maintained.
-
-   2.  DHCPv6 is not necessarily needed for 3GPP UE IPv6 addressing
-       (3GPP Stateless Address Autoconfiguration is typically used), and
-       not automatically implemented in 3GPP IPv6 UEs.
-
-
-
-
-
-Jeong                   Expires November 6, 2005               [Page 20]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-   3.  Scalability and reliability of DHCPv6 in very large 3GPP networks
-       (with tens or hundreds of millions of UEs) may be an issue, at
-       least the redundancy needs to be taken care of.  However, if the
-       DHCPv6 service is integrated into the network elements, such as a
-       router operating system, scalability and reliability is
-       comparable with other DNS configuration approaches.
-
-   4.  It is sub-optimal to utilize the radio resources in 3GPP networks
-       for DHCPv6 messages if there is a simpler alternative available.
-
-       *  The use of Stateless DHCPv6 adds one round trip delay to the
-          case in which the UE can start transmitting data right after
-          the Router Advertisement.
-
-   5.  If the DNS information (suddenly) changes, Stateless DHCPv6 can
-       not automatically update the UE, see [23].
-
-
-5.3.4  Well-known Addresses
-
-   Using well-known addresses is also a feasible and a light mechanism
-   for 3GPP UEs.  Those well-known addresses can be preconfigured in the
-   UE software and the operator makes the corresponding configuration on
-   the network side.  So this is a very easy mechanism for the UE, but
-   requires some configuration work in the network.  When using well-
-   known addresses, UE forwards queries to any of the preconfigured
-   addresses.  In the current proposal [9], IPv6 anycast addresses are
-   suggested.
-
-Note
-
-   The IPv6 DNS configuration proposal based on the use of well-known
-   site-local addresses developed at the IPv6 Working Group was seen as
-   a feasible mechanism for 3GPP UEs, but opposition by some people in
-   the IETF and finally deprecating IPv6 site-local addresses made it
-   impossible to standardize it.  Note that this mechanism is
-   implemented in some existing operating systems today (also in some
-   3GPP UEs) as a last resort of IPv6 DNS configuration.
-
-5.3.5  Recommendations
-
-   It is suggested that a lightweight, stateless DNS configuration
-   mechanism is specified as soon as possible.  From a 3GPP UE and
-   network point of view, the Router Advertisement based mechanism looks
-   most promising.  The sooner a light, stateless mechanism is
-   specified, the sooner we can get rid of using well-known site-local
-   addresses for IPv6 DNS configuration.
-
-
-
-
-Jeong                   Expires November 6, 2005               [Page 21]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-5.4  Unmanaged Network
-
-   There are 4 deployment scenarios of interest in unmanaged networks
-   [24]:
-
-   1.  A gateway which does not provide IPv6 at all;
-
-   2.  A dual-stack gateway connected to a dual-stack ISP;
-
-   3.  A dual-stack gateway connected to an IPv4-only ISP; and
-
-   4.  A gateway connected to an IPv6-only ISP.
-
-
-5.4.1  Case A: Gateway does not provide IPv6 at all
-
-   In this case, the gateway does not provide IPv6; the ISP may or may
-   not provide IPv6.  Automatic or Configured tunnels are the
-   recommended transition mechanisms for this scenario.
-
-   The case where dual-stack hosts behind an NAT, that need access to an
-   IPv6 RDNSS, cannot be entirely ruled out.  The DNS configuration
-   mechanism has to work over the tunnel, and the underlying tunneling
-   mechanism could be implementing NAT traversal.  The tunnel server
-   assumes the role of a relay (both for DHCP and Well-known anycast
-   addresses approaches).
-
-   RA-based mechanism is relatively straightforward in its operation,
-   assuming the tunnel server is also the IPv6 router emitting RAs.
-   Well-known anycast addresses approach seems also simple in operation
-   across the tunnel, but the deployment model using Well-known anycast
-   addresses in a tunneled environment is unclear or not well
-   understood.
-
-5.4.2  Case B: A dual-stack gateway connected to a dual-stack ISP
-
-   This is similar to a typical IPv4 home user scenario, where DNS
-   configuration parameters are obtained using DHCP.  Except that
-   Stateless DHCPv6 is used, as opposed to the IPv4 scenario where the
-   DHCP server is stateful (maintains the state for clients).
-
-5.4.3  Case C: A dual-stack gateway connected to an IPv4-only ISP
-
-   This is similar to Case B. If a gateway provides IPv6 connectivity by
-   managing tunnels, then it is also supposed to provide access to an
-   RDNSS.  Like this, the tunnel for IPv6 connectivity originates from
-   the dual-stack gateway instead of the host.
-
-
-
-
-Jeong                   Expires November 6, 2005               [Page 22]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-5.4.4  Case D: A gateway connected to an IPv6-only ISP
-
-   This is similar to Case B.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jeong                   Expires November 6, 2005               [Page 23]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-6.  Security Considerations
-
-   As security requirements depend solely on applications and are
-   different application by application, there can be no generic
-   requirement defined at IP or application layer for DNS.
-
-   However, it should be noted that cryptographic security requires
-   configured secret information that full autoconfiguration and
-   cryptographic security are mutually exclusive.  People insisting on
-   secure full autoconfiguration will get false security, false
-   autoconfiguration or both.
-
-   In some deployment scenarios [19], where cryptographic security is
-   required for applications, the secret information for the
-   cryptographic security is preconfigured through which application
-   specific configuration data, including those for DNS, can be securely
-   configured.  It should be noted that if applications requiring
-   cryptographic security depend on DNS, the applications also require
-   cryptographic security to DNS.  Therefore, the full autoconfiguration
-   of DNS is not acceptable.
-
-   However, with full autoconfiguration, weaker but still reasonable
-   security is being widely accepted and will continue to be acceptable.
-   That is, with full autoconfiguration, which means there is no
-   cryptographic security for the autoconfiguration, it is already
-   assumed that the local environment is secure enough that the
-   information from the local autoconfiguration server has acceptable
-   security even without cryptographic security.  Thus, the
-   communication between the local DNS client and local DNS server has
-   acceptable security.
-
-   In autoconfiguring recursive servers, DNSSEC may be overkill, because
-   DNSSEC [29] needs the configuration and reconfiguration of clients at
-   root key roll-over [30][31].  Even if additional keys for secure key
-   roll-over are added at the initial configuration, they are as
-   vulnerable as the original keys to some forms of attacks, such as
-   social hacking.  Another problem of using DNSSEC and
-   autoconfiguration together is that DNSSEC requires secure time, which
-   means secure communication with autoconfigured time servers, which
-   requires configured secret information.  Therefore, in order that the
-   autoconfiguration may be secure, it requires configured secret
-   information.
-
-   If DNSSEC [29] is used and the signatures are verified on the client
-   host, the misconfiguration of a DNS server may be simply denial of
-   service.  Also, if local routing environment is not reliable, clients
-   may be directed to a false resolver with the same IP address as the
-   true one.
-
-
-
-Jeong                   Expires November 6, 2005               [Page 24]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-6.1  RA Option
-
-   The security of RA option for RDNSS is the same as the ND protocol
-   security [3][8].  The RA option does not add any new vulnerability.
-
-   It should be noted that the vulnerability of ND is not worse and is a
-   subset of the attacks that any node attached to a LAN can do
-   independently of ND.  A malicious node on a LAN can promiscuously
-   receive packets for any router's MAC address and send packets with
-   the router's MAC address as the source MAC address in the L2 header.
-   As a result, the L2 switches send packets addressed to the router to
-   the malicious node.  Also, this attack can send redirects that tell
-   the hosts to send their traffic somewhere else.  The malicious node
-   can send unsolicited RA or NA replies, answer RS or NS requests, etc.
-   All of this can be done independently of implementing ND.  Therefore,
-   the RA option for RDNSS does not add to the vulnerability.
-
-   Security issues regarding the ND protocol were discussed at IETF SEND
-   (Securing Neighbor Discovery) Working Group and RFC 3971 for the ND
-   security has been published [14].
-
-6.2  DHCPv6 Option
-
-   The DNS Recursive Name Server option may be used by an intruder DHCP
-   server to cause DHCP clients to send DNS queries to an intruder DNS
-   recursive name server [7].  The results of these misdirected DNS
-   queries may be used to spoof DNS names.
-
-   To avoid attacks through the DNS Recursive Name Server option, the
-   DHCP client SHOULD require DHCP authentication (see section
-   "Authentication of DHCP messages" in RFC 3315 [5]) before installing
-   a list of DNS recursive name servers obtained through authenticated
-   DHCP.
-
-6.3  Well-known Anycast Addresses
-
-   Well-known anycast addresses does not require configuration security
-   since there is no protocol [9].
-
-   The DNS server with the preconfigured addresses are still reasonably
-   reliable, if local environment is reasonably secure, that is, there
-   is no active attackers receiving queries to the anycast addresses of
-   the servers and reply to them.
-
-
-
-
-
-
-
-
-Jeong                   Expires November 6, 2005               [Page 25]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-7.  Contributors
-
-   Ralph Droms
-   Cisco Systems, Inc.
-   1414 Massachusetts Ave.
-   Boxboro, MA  01719
-   US
-
-   Phone: +1 978 936 1674
-   Email: rdroms@cisco.com
-
-
-   Robert M. Hinden
-   Nokia
-   313 Fairchild Drive
-   Mountain View, CA  94043
-   US
-
-   Phone: +1 650 625 2004
-   Email: bob.hinden@nokia.com
-
-
-   Ted Lemon
-   Nominum, Inc.
-   950 Charter Street
-   Redwood City, CA  94043
-   US
-
-   Email: Ted.Lemon@nominum.com
-
-
-   Masataka Ohta
-   Tokyo Institute of Technology
-   2-12-1, O-okayama, Meguro-ku
-   Tokyo  152-8552
-   Japan
-
-   Phone: +81 3 5734 3299
-   Fax:   +81 3 5734 3299
-   Email: mohta@necom830.hpcl.titech.ac.jp
-
-
-   Soohong Daniel Park
-   Mobile Platform Laboratory, SAMSUNG Electronics
-   416 Maetan-3dong, Yeongtong-Gu
-   Suwon, Gyeonggi-Do  443-742
-   Korea
-
-
-
-
-Jeong                   Expires November 6, 2005               [Page 26]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-   Phone: +82 31 200 4508
-   Email: soohong.park@samsung.com
-
-
-   Suresh Satapati
-   Cisco Systems, Inc.
-   San Jose, CA  95134
-   US
-
-   Email: satapati@cisco.com
-
-
-   Juha Wiljakka
-   Nokia
-   Visiokatu 3
-   FIN-33720, TAMPERE
-   Finland
-
-   Phone: +358 7180 48372
-   Email: juha.wiljakka@nokia.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jeong                   Expires November 6, 2005               [Page 27]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-8.  Acknowledgements
-
-   This draft has greatly benefited from inputs by David Meyer, Rob
-   Austein, Tatuya Jinmei, Pekka Savola, Tim Chown, Luc Beloeil,
-   Christian Huitema, Thomas Narten, Pascal Thubert, and Greg Daley.
-   Also, Tony Bonanno proofread this draft.  The authors appreciate
-   their contribution.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jeong                   Expires November 6, 2005               [Page 28]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-9.  References
-
-9.1  Normative References
-
-   [1]  Bradner, S., "IETF Rights in Contributions", RFC 3667,
-        February 2004.
-
-   [2]  Bradner, S., "Intellectual Property Rights in IETF Technology",
-        RFC 3668, February 2004.
-
-   [3]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
-        for IP Version 6 (IPv6)", RFC 2461, December 1998.
-
-   [4]  Thomson, S. and T. Narten, "IPv6 Stateless Address
-        Autoconfiguration", RFC 2462, December 1998.
-
-   [5]  Droms, R., Ed., "Dynamic Host Configuration Protocol for IPv6
-        (DHCPv6)", RFC 3315, July 2003.
-
-   [6]  Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP)
-        Service for IPv6", RFC 3736, April 2004.
-
-   [7]  Droms, R., Ed., "DNS Configuration options for Dynamic Host
-        Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
-        December 2003.
-
-9.2  Informative References
-
-   [8]   Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 DNS
-         Discovery based on Router Advertisement",
-         draft-jeong-dnsop-ipv6-dns-discovery-04.txt (Work in Progress),
-         February 2005.
-
-   [9]   Ohta, M., "Preconfigured DNS Server Addresses",
-         draft-ohta-preconfigured-dns-01.txt (Work in Progress),
-         February 2004.
-
-   [10]  Venaas, S., Chown, T., and B. Volz, "Information Refresh Time
-         Option for DHCPv6", draft-ietf-dhc-lifetime-03.txt (Work in
-         Progress), January 2005.
-
-   [11]  Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting
-         Service", RFC 1546, November 1993.
-
-   [12]  Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
-         Addressing Architecture", RFC 3513, April 2003.
-
-   [13]  Lind, M., Ed., "Scenarios and Analysis for Introduction IPv6
-
-
-
-Jeong                   Expires November 6, 2005               [Page 29]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-         into ISP Networks", RFC 4029, March 2005.
-
-   [14]  Arkko, J., Ed., "SEcure Neighbor Discovery (SEND)", RFC 3971,
-         March 2005.
-
-   [15]  Droms, R. and W. Arbaugh, "Authentication for DHCP Messages",
-         RFC 3118, June 2001.
-
-   [16]  Bound, J., Ed., "IPv6 Enterprise Network Scenarios",
-         draft-ietf-v6ops-ent-scenarios-05.txt (Work in Progress),
-         July 2004.
-
-   [17]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
-         Configuration Protocol (DHCP) version 6", RFC 3633,
-         December 2003.
-
-   [18]  Wasserman, M., Ed., "Recommendations for IPv6 in 3GPP
-         Standards", RFC 3314, September 2002.
-
-   [19]  Soininen, J., Ed., "Transition Scenarios for 3GPP Networks",
-         RFC 3574, August 2003.
-
-   [20]  Wiljakka, J., Ed., "Analysis on IPv6 Transition in 3GPP
-         Networks", draft-ietf-v6ops-3gpp-analysis-11.txt (Work in
-         Progress), October 2004.
-
-   [21]  3GPP TS 23.060 V5.4.0, "General Packet Radio Service (GPRS);
-         Service description; Stage 2 (Release 5)", December 2002.
-
-   [22]  3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3
-         specification; Core network protocols; Stage 3 (Release 5)",
-         June 2003.
-
-   [23]  Chown, T., Venaas, S., and A. Vijayabhaskar, "Renumbering
-         Requirements for Stateless DHCPv6",
-         draft-ietf-dhc-stateless-dhcpv6-renumbering-02.txt (Work in
-         Progress), October 2004.
-
-   [24]  Huitema, C., Ed., "Unmanaged Networks IPv6 Transition
-         Scenarios", RFC 3750, April 2004.
-
-   [25]  ANSI/IEEE Std 802.11, "Part 11: Wireless LAN Medium Access
-         Control (MAC) and Physical Layer (PHY) Specifications",
-         March 1999.
-
-   [26]  IEEE Std 802.11a, "Part 11: Wireless LAN Medium Access Control
-         (MAC) and Physical Layer (PHY) specifications: High-speed
-         Physical Layer in the 5 GHZ Band", September 1999.
-
-
-
-Jeong                   Expires November 6, 2005               [Page 30]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-   [27]  IEEE Std 802.11b, "Part 11: Wireless LAN Medium Access Control
-         (MAC) and Physical Layer (PHY) specifications: Higher-Speed
-         Physical Layer Extension in the 2.4 GHz Band", September 1999.
-
-   [28]  IEEE P802.11g/D8.2, "Part 11: Wireless LAN Medium Access
-         Control (MAC) and Physical Layer (PHY) specifications: Further
-         Higher Data Rate Extension in the 2.4 GHz Band", April 2003.
-
-   [29]  Eastlake, D., "Domain Name System Security Extensions",
-         RFC 2535, March 1999.
-
-   [30]  Kolkman, O. and R. Gieben, "DNSSEC Operational Practices",
-         draft-ietf-dnsop-dnssec-operational-practices-03.txt (Work in
-         Progress), December 2004.
-
-   [31]  Guette, G. and O. Courtay, "Requirements for Automated Key
-         Rollover in DNSSEC",
-         draft-ietf-dnsop-key-rollover-requirements-02.txt (Work in
-         Progress), January 2005.
-
-   [32]  Park, S., Madanapalli, S., and T. Jinmei, "Considerations on M
-         and O Flags of IPv6 Router Advertisement",
-         draft-ietf-ipv6-ra-mo-flags-01.txt (Work in Progress),
-         March 2005.
-
-
-Author's Address
-
-   Jaehoon Paul Jeong (editor)
-   ETRI/Department of Computer Science and Engineering
-   University of Minnesota
-   117 Pleasant Street SE
-   Minneapolis, MN  55455
-   US
-
-   Phone: +1 651 587 7774
-   Fax:   +1 612 625 2002
-   Email: jjeong@cs.umn.edu
-   URI:   http://www.cs.umn.edu/~jjeong/
-
-
-
-
-
-
-
-
-
-
-
-
-Jeong                   Expires November 6, 2005               [Page 31]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-Appendix A.  Link-layer Multicast Acknowledgements for RA Option
-
-   One benefit of an RA option [8] is to be able to multicast the
-   advertisements, reducing the need for duplicated unicast
-   communications.
-
-   However, some link-layers may not support this as well as others.
-   Consider, for example, WLAN networks where multicast is unreliable.
-   The unreliability problem is caused by lack of ACK for multicast,
-   especially on the path from the Access Point (AP) to the Station
-   (STA), which is specific to CSMA/CA of WLAN, such as IEEE 802.11
-   a/b/g [25]-[28].  That is, a multicast packet is unacknowledged on
-   the path from the AP to the STA, but acknowledged in the reverse
-   direction from the STA to the AP [25].  For example, when a router is
-   placed at wired network connected to an AP, a host may sometimes not
-   receive RA message advertised through the AP.  Therefore, the RA
-   option solution might not work well on a congested medium that uses
-   unreliable multicast for RA.
-
-   The fact that this problem has not been addressed in Neighbor
-   Discovery [3] indicates that the extra link-layer acknowledgements
-   have not been considered a serious problem till now.
-
-   A possible mitigation technique could be to map all-nodes link- local
-   multicast address to the link-layer broadcast address, and to rely on
-   the ND retransmissions for message delivery in order to achieve more
-   reliability.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jeong                   Expires November 6, 2005               [Page 32]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Jeong                   Expires November 6, 2005               [Page 33]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt
deleted file mode 100644
index 1276f9f..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt
+++ /dev/null
@@ -1,1682 +0,0 @@
-
-
-
-
-DNS Operations WG                                              A. Durand
-Internet-Draft                                    SUN Microsystems, Inc.
-Expires: January 17, 2006                                       J. Ihren
-                                                              Autonomica
-                                                               P. Savola
-                                                               CSC/FUNET
-                                                           July 16, 2005
-
-
-          Operational Considerations and Issues with IPv6 DNS
-                draft-ietf-dnsop-ipv6-dns-issues-11.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on January 17, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This memo presents operational considerations and issues with IPv6
-   Domain Name System (DNS), including a summary of special IPv6
-   addresses, documentation of known DNS implementation misbehaviour,
-   recommendations and considerations on how to perform DNS naming for
-   service provisioning and for DNS resolver IPv6 support,
-
-
-
-Durand, et al.          Expires January 17, 2006                [Page 1]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   considerations for DNS updates for both the forward and reverse
-   trees, and miscellaneous issues.  This memo is aimed to include a
-   summary of information about IPv6 DNS considerations for those who
-   have experience with IPv4 DNS.
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
-     1.1   Representing IPv6 Addresses in DNS Records . . . . . . . .  4
-     1.2   Independence of DNS Transport and DNS Records  . . . . . .  4
-     1.3   Avoiding IPv4/IPv6 Name Space Fragmentation  . . . . . . .  5
-     1.4   Query Type '*' and A/AAAA Records  . . . . . . . . . . . .  5
-   2.  DNS Considerations about Special IPv6 Addresses  . . . . . . .  5
-     2.1   Limited-scope Addresses  . . . . . . . . . . . . . . . . .  6
-     2.2   Temporary Addresses  . . . . . . . . . . . . . . . . . . .  6
-     2.3   6to4 Addresses . . . . . . . . . . . . . . . . . . . . . .  6
-     2.4   Other Transition Mechanisms  . . . . . . . . . . . . . . .  6
-   3.  Observed DNS Implementation Misbehaviour . . . . . . . . . . .  7
-     3.1   Misbehaviour of DNS Servers and Load-balancers . . . . . .  7
-     3.2   Misbehaviour of DNS Resolvers  . . . . . . . . . . . . . .  7
-   4.  Recommendations for Service Provisioning using DNS . . . . . .  7
-     4.1   Use of Service Names instead of Node Names . . . . . . . .  8
-     4.2   Separate vs the Same Service Names for IPv4 and IPv6 . . .  8
-     4.3   Adding the Records Only when Fully IPv6-enabled  . . . . .  9
-     4.4   The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . 10
-       4.4.1   TTL With Courtesy Additional Data  . . . . . . . . . . 10
-       4.4.2   TTL With Critical Additional Data  . . . . . . . . . . 10
-     4.5   IPv6 Transport Guidelines for DNS Servers  . . . . . . . . 11
-   5.  Recommendations for DNS Resolver IPv6 Support  . . . . . . . . 11
-     5.1   DNS Lookups May Query IPv6 Records Prematurely . . . . . . 11
-     5.2   Obtaining a List of DNS Recursive Resolvers  . . . . . . . 13
-     5.3   IPv6 Transport Guidelines for Resolvers  . . . . . . . . . 13
-   6.  Considerations about Forward DNS Updating  . . . . . . . . . . 13
-     6.1   Manual or Custom DNS Updates . . . . . . . . . . . . . . . 14
-     6.2   Dynamic DNS  . . . . . . . . . . . . . . . . . . . . . . . 14
-   7.  Considerations about Reverse DNS Updating  . . . . . . . . . . 15
-     7.1   Applicability of Reverse DNS . . . . . . . . . . . . . . . 15
-     7.2   Manual or Custom DNS Updates . . . . . . . . . . . . . . . 16
-     7.3   DDNS with Stateless Address Autoconfiguration  . . . . . . 16
-     7.4   DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . 18
-     7.5   DDNS with Dynamic Prefix Delegation  . . . . . . . . . . . 18
-   8.  Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 19
-     8.1   NAT-PT with DNS-ALG  . . . . . . . . . . . . . . . . . . . 19
-     8.2   Renumbering Procedures and Applications' Use of DNS  . . . 19
-   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
-   10.   Security Considerations  . . . . . . . . . . . . . . . . . . 20
-   11.   References . . . . . . . . . . . . . . . . . . . . . . . . . 20
-     11.1  Normative References . . . . . . . . . . . . . . . . . . . 20
-
-
-
-Durand, et al.          Expires January 17, 2006                [Page 2]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-     11.2  Informative References . . . . . . . . . . . . . . . . . . 22
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
-   A.  Unique Local Addressing Considerations for DNS . . . . . . . . 25
-   B.  Behaviour of Additional Data in IPv4/IPv6 Environments . . . . 25
-     B.1   Description of Additional Data Scenarios . . . . . . . . . 26
-     B.2   Which Additional Data to Keep, If Any? . . . . . . . . . . 27
-     B.3   Discussion of the Potential Problems . . . . . . . . . . . 28
-       Intellectual Property and Copyright Statements . . . . . . . . 30
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Durand, et al.          Expires January 17, 2006                [Page 3]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-1.  Introduction
-
-   This memo presents operational considerations and issues with IPv6
-   DNS; it is meant to be an extensive summary and a list of pointers
-   for more information about IPv6 DNS considerations for those with
-   experience with IPv4 DNS.
-
-   The purpose of this document is to give information about various
-   issues and considerations related to DNS operations with IPv6; it is
-   not meant to be a normative specification or standard for IPv6 DNS.
-
-   The first section gives a brief overview of how IPv6 addresses and
-   names are represented in the DNS, how transport protocols and
-   resource records (don't) relate, and what IPv4/IPv6 name space
-   fragmentation means and how to avoid it; all of these are described
-   at more length in other documents.
-
-   The second section summarizes the special IPv6 address types and how
-   they relate to DNS.  The third section describes observed DNS
-   implementation misbehaviours which have a varying effect on the use
-   of IPv6 records with DNS.  The fourth section lists recommendations
-   and considerations for provisioning services with DNS.  The fifth
-   section in turn looks at recommendations and considerations about
-   providing IPv6 support in the resolvers.  The sixth and seventh
-   sections describe considerations with forward and reverse DNS
-   updates, respectively.  The eighth section introduces several
-   miscellaneous IPv6 issues relating to DNS for which no better place
-   has been found in this memo.  Appendix A looks briefly at the
-   requirements for unique local addressing.
-
-1.1  Representing IPv6 Addresses in DNS Records
-
-   In the forward zones, IPv6 addresses are represented using AAAA
-   records.  In the reverse zones, IPv6 address are represented using
-   PTR records in the nibble format under the ip6.arpa. tree.  See
-   [RFC3596] for more about IPv6 DNS usage, and [RFC3363] or [RFC3152]
-   for background information.
-
-   In particular one should note that the use of A6 records in the
-   forward tree or Bitlabels in the reverse tree is not recommended
-   [RFC3363].  Using DNAME records is not recommended in the reverse
-   tree in conjunction with A6 records; the document did not mean to
-   take a stance on any other use of DNAME records [RFC3364].
-
-1.2  Independence of DNS Transport and DNS Records
-
-   DNS has been designed to present a single, globally unique name space
-   [RFC2826].  This property should be maintained, as described here and
-
-
-
-Durand, et al.          Expires January 17, 2006                [Page 4]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   in Section 1.3.
-
-   The IP version used to transport the DNS queries and responses is
-   independent of the records being queried: AAAA records can be queried
-   over IPv4, and A records over IPv6.  The DNS servers must not make
-   any assumptions about what data to return for Answer and Authority
-   sections based on the underlying transport used in a query.
-
-   However, there is some debate whether the addresses in Additional
-   section could be selected or filtered using hints obtained from which
-   transport was being used; this has some obvious problems because in
-   many cases the transport protocol does not correlate with the
-   requests, and because a "bad" answer is in a way worse than no answer
-   at all (consider the case where the client is led to believe that a
-   name received in the additional record does not have any AAAA records
-   at all).
-
-   As stated in [RFC3596]:
-
-      The IP protocol version used for querying resource records is
-      independent of the protocol version of the resource records; e.g.,
-      IPv4 transport can be used to query IPv6 records and vice versa.
-
-
-1.3  Avoiding IPv4/IPv6 Name Space Fragmentation
-
-   To avoid the DNS name space from fragmenting into parts where some
-   parts of DNS are only visible using IPv4 (or IPv6) transport, the
-   recommendation is to always keep at least one authoritative server
-   IPv4-enabled, and to ensure that recursive DNS servers support IPv4.
-   See DNS IPv6 transport guidelines [RFC3901] for more information.
-
-1.4  Query Type '*' and A/AAAA Records
-
-   QTYPE=* is typically only used for debugging or management purposes;
-   it is worth keeping in mind that QTYPE=* ("ANY" queries) only return
-   any available RRsets, not *all* the RRsets, because the caches do not
-   necessarily have all the RRsets and have no way of guaranteeing that
-   they have all the RRsets.  Therefore, to get both A and AAAA records
-   reliably, two separate queries must be made.
-
-2.  DNS Considerations about Special IPv6 Addresses
-
-   There are a couple of IPv6 address types which are somewhat special;
-   these are considered here.
-
-
-
-
-
-
-Durand, et al.          Expires January 17, 2006                [Page 5]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-2.1  Limited-scope Addresses
-
-   The IPv6 addressing architecture [RFC3513] includes two kinds of
-   local-use addresses: link-local (fe80::/10) and site-local
-   (fec0::/10).  The site-local addresses have been deprecated [RFC3879]
-   but are discussed with unique local addresses in Appendix A.
-
-   Link-local addresses should never be published in DNS (whether in
-   forward or reverse tree), because they have only local (to the
-   connected link) significance [I-D.durand-dnsop-dont-publish].
-
-2.2  Temporary Addresses
-
-   Temporary addresses defined in RFC3041 [RFC3041] (sometimes called
-   "privacy addresses") use a random number as the interface identifier.
-   Having DNS AAAA records that are updated to always contain the
-   current value of a node's temporary address would defeat the purpose
-   of the mechanism and is not recommended.  However, it would still be
-   possible to return a non-identifiable name (e.g., the IPv6 address in
-   hexadecimal format), as described in [RFC3041].
-
-2.3  6to4 Addresses
-
-   6to4 [RFC3056] specifies an automatic tunneling mechanism which maps
-   a public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48.
-
-   If the reverse DNS population would be desirable (see Section 7.1 for
-   applicability), there are a number of possible ways to do so.
-
-   The main proposal [I-D.huston-6to4-reverse-dns] aims to design an
-   autonomous reverse-delegation system that anyone being capable of
-   communicating using a specific 6to4 address would be able to set up a
-   reverse delegation to the corresponding 6to4 prefix.  This could be
-   deployed by e.g., Regional Internet Registries (RIRs).  This is a
-   practical solution, but may have some scalability concerns.
-
-2.4  Other Transition Mechanisms
-
-   6to4 is mentioned as a case of an IPv6 transition mechanism requiring
-   special considerations.  In general, mechanisms which include a
-   special prefix may need a custom solution; otherwise, for example
-   when IPv4 address is embedded as the suffix or not embedded at all,
-   special solutions are likely not needed.
-
-   Note that it does not seem feasible to provide reverse DNS with
-   another automatic tunneling mechanism, Teredo [I-D.huitema-v6ops-
-   teredo]; this is because the IPv6 address is based on the IPv4
-   address and UDP port of the current NAT mapping which is likely to be
-
-
-
-Durand, et al.          Expires January 17, 2006                [Page 6]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   relatively short-lived.
-
-3.  Observed DNS Implementation Misbehaviour
-
-   Several classes of misbehaviour in DNS servers, load-balancers and
-   resolvers have been observed.  Most of these are rather generic, not
-   only applicable to IPv6 -- but in some cases, the consequences of
-   this misbehaviour are extremely severe in IPv6 environments and
-   deserve to be mentioned.
-
-3.1  Misbehaviour of DNS Servers and Load-balancers
-
-   There are several classes of misbehaviour in certain DNS servers and
-   load-balancers which have been noticed and documented [RFC4074]: some
-   implementations silently drop queries for unimplemented DNS records
-   types, or provide wrong answers to such queries (instead of a proper
-   negative reply).  While typically these issues are not limited to
-   AAAA records, the problems are aggravated by the fact that AAAA
-   records are being queried instead of (mainly) A records.
-
-   The problems are serious because when looking up a DNS name, typical
-   getaddrinfo() implementations, with AF_UNSPEC hint given, first try
-   to query the AAAA records of the name, and after receiving a
-   response, query the A records.  This is done in a serial fashion --
-   if the first query is never responded to (instead of properly
-   returning a negative answer), significant timeouts will occur.
-
-   In consequence, this is an enormous problem for IPv6 deployments, and
-   in some cases, IPv6 support in the software has even been disabled
-   due to these problems.
-
-   The solution is to fix or retire those misbehaving implementations,
-   but that is likely not going to be effective.  There are some
-   possible ways to mitigate the problem, e.g., by performing the
-   lookups somewhat in parallel and reducing the timeout as long as at
-   least one answer has been received; but such methods remain to be
-   investigated; slightly more on this is included in Section 5.
-
-3.2  Misbehaviour of DNS Resolvers
-
-   Several classes of misbehaviour have also been noticed in DNS
-   resolvers [I-D.ietf-dnsop-bad-dns-res].  However, these do not seem
-   to directly impair IPv6 use, and are only referred to for
-   completeness.
-
-4.  Recommendations for Service Provisioning using DNS
-
-   When names are added in the DNS to facilitate a service, there are
-
-
-
-Durand, et al.          Expires January 17, 2006                [Page 7]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   several general guidelines to consider to be able to do it as
-   smoothly as possible.
-
-4.1  Use of Service Names instead of Node Names
-
-   It makes sense to keep information about separate services logically
-   separate in the DNS by using a different DNS hostname for each
-   service.  There are several reasons for doing this, for example:
-
-   o  It allows more flexibility and ease for migration of (only a part
-      of) services from one node to another,
-
-   o  It allows configuring different properties (e.g., TTL) for each
-      service, and
-
-   o  It allows deciding separately for each service whether to publish
-      the IPv6 addresses or not (in cases where some services are more
-      IPv6-ready than others).
-
-   Using SRV records [RFC2782] would avoid these problems.
-   Unfortunately, those are not sufficiently widely used to be
-   applicable in most cases.  Hence an operation technique is to use
-   service names instead of node names (or, "hostnames").  This
-   operational technique is not specific to IPv6, but required to
-   understand the considerations described in Section 4.2 and
-   Section 4.3.
-
-   For example, assume a node named "pobox.example.com" provides both
-   SMTP and IMAP service.  Instead of configuring the MX records to
-   point at "pobox.example.com", and configuring the mail clients to
-   look up the mail via IMAP from "pobox.example.com", one could use
-   e.g., "smtp.example.com" for SMTP (for both message submission and
-   mail relaying between SMTP servers) and "imap.example.com" for IMAP.
-   Note that in the specific case of SMTP relaying, the server itself
-   must typically also be configured to know all its names to ensure
-   loops do not occur.  DNS can provide a layer of indirection between
-   service names and where the service actually is, and using which
-   addresses.  (Obviously, when wanting to reach a specific node, one
-   should use the hostname rather than a service name.)
-
-4.2  Separate vs the Same Service Names for IPv4 and IPv6
-
-   The service naming can be achieved in basically two ways: when a
-   service is named "service.example.com" for IPv4, the IPv6-enabled
-   service could either be added to "service.example.com", or added
-   separately under a different name, e.g., in a sub-domain, like,
-   "service.ipv6.example.com".
-
-
-
-
-Durand, et al.          Expires January 17, 2006                [Page 8]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   These two methods have different characteristics.  Using a different
-   name allows for easier service piloting, minimizing the disturbance
-   to the "regular" users of IPv4 service; however, the service would
-   not be used transparently, without the user/application explicitly
-   finding it and asking for it -- which would be a disadvantage in most
-   cases.  When the different name is under a sub-domain, if the
-   services are deployed within a restricted network (e.g., inside an
-   enterprise), it's possible to prefer them transparently, at least to
-   a degree, by modifying the DNS search path; however, this is a
-   suboptimal solution.  Using the same service name is the "long-term"
-   solution, but may degrade performance for those clients whose IPv6
-   performance is lower than IPv4, or does not work as well (see
-   Section 4.3 for more).
-
-   In most cases, it makes sense to pilot or test a service using
-   separate service names, and move to the use of the same name when
-   confident enough that the service level will not degrade for the
-   users unaware of IPv6.
-
-4.3  Adding the Records Only when Fully IPv6-enabled
-
-   The recommendation is that AAAA records for a service should not be
-   added to the DNS until all of following are true:
-
-   1.  The address is assigned to the interface on the node.
-
-   2.  The address is configured on the interface.
-
-   3.  The interface is on a link which is connected to the IPv6
-       infrastructure.
-
-   In addition, if the AAAA record is added for the node, instead of
-   service as recommended, all the services of the node should be IPv6-
-   enabled prior to adding the resource record.
-
-   For example, if an IPv6 node is isolated from an IPv6 perspective
-   (e.g., it is not connected to IPv6 Internet) constraint #3 would mean
-   that it should not have an address in the DNS.
-
-   Consider the case of two dual-stack nodes, which both have IPv6
-   enabled, but the server does not have (global) IPv6 connectivity.  As
-   the client looks up the server's name, only A records are returned
-   (if the recommendations above are followed), and no IPv6
-   communication, which would have been unsuccessful, is even attempted.
-
-   The issues are not always so black-and-white.  Usually it's important
-   that the service offered using both protocols is of roughly equal
-   quality, using the appropriate metrics for the service (e.g.,
-
-
-
-Durand, et al.          Expires January 17, 2006                [Page 9]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   latency, throughput, low packet loss, general reliability, etc.) --
-   this is typically very important especially for interactive or real-
-   time services.  In many cases, the quality of IPv6 connectivity may
-   not yet be equal to that of IPv4, at least globally -- this has to be
-   taken into consideration when enabling services.
-
-4.4  The Use of TTL for IPv4 and IPv6 RRs
-
-   The behaviour of DNS caching when different TTL values are used for
-   different RRsets of the same name calls for explicit discussion.  For
-   example, let's consider two unrelated zone fragments:
-
-      example.com.        300    IN    MX     foo.example.com.
-      foo.example.com.    300    IN    A      192.0.2.1
-      foo.example.com.    100    IN    AAAA   2001:db8::1
-
-   ...
-
-      child.example.com.    300  IN    NS     ns.child.example.com.
-      ns.child.example.com. 300  IN    A      192.0.2.1
-      ns.child.example.com. 100  IN    AAAA   2001:db8::1
-
-   In the former case, we have "courtesy" additional data; in the
-   latter, we have "critical" additional data.  See more extensive
-   background discussion of additional data handling in Appendix B.
-
-4.4.1  TTL With Courtesy Additional Data
-
-   When a caching resolver asks for the MX record of example.com, it
-   gets back "foo.example.com".  It may also get back either one or both
-   of the A and AAAA records in the additional section.  The resolver
-   must explicitly query for both A and AAAA records [RFC2821].
-
-   After 100 seconds, the AAAA record is removed from the cache(s)
-   because its TTL expired.  It could be argued to be useful for the
-   caching resolvers to discard the A record when the shorter TTL (in
-   this case, for the AAAA record) expires; this would avoid the
-   situation where there would be a window of 200 seconds when
-   incomplete information is returned from the cache.  Further argument
-   for discarding is that in the normal operation, the TTL values are so
-   high that very likely the incurred additional queries would not be
-   noticeable, compared to the obtained performance optimization.  The
-   behaviour in this scenario is unspecified.
-
-4.4.2  TTL With Critical Additional Data
-
-   The difference to courtesy additional data is that the A/AAAA records
-   served by the parent zone cannot be queried explicitly.  Therefore
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 10]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   after 100 seconds the AAAA record is removed from the cache(s), but
-   the A record remains.  Queries for the remaining 200 seconds
-   (provided that there are no further queries from the parent which
-   could refresh the caches) only return the A record, leading to a
-   potential opererational situation with unreachable servers.
-
-   Similar cache flushing strategies apply in this scenario; the record.
-
-4.5  IPv6 Transport Guidelines for DNS Servers
-
-   As described in Section 1.3 and [RFC3901], there should continue to
-   be at least one authoritative IPv4 DNS server for every zone, even if
-   the zone has only IPv6 records.  (Note that obviously, having more
-   servers with robust connectivity would be preferable, but this is the
-   minimum recommendation; also see [RFC2182].)
-
-5.  Recommendations for DNS Resolver IPv6 Support
-
-   When IPv6 is enabled on a node, there are several things to consider
-   to ensure that the process is as smooth as possible.
-
-5.1  DNS Lookups May Query IPv6 Records Prematurely
-
-   The system library that implements the getaddrinfo() function for
-   looking up names is a critical piece when considering the robustness
-   of enabling IPv6; it may come in basically three flavours:
-
-   1.  The system library does not know whether IPv6 has been enabled in
-       the kernel of the operating system: it may start looking up AAAA
-       records with getaddrinfo() and AF_UNSPEC hint when the system is
-       upgraded to a system library version which supports IPv6.
-
-   2.  The system library might start to perform IPv6 queries with
-       getaddrinfo() only when IPv6 has been enabled in the kernel.
-       However, this does not guarantee that there exists any useful
-       IPv6 connectivity (e.g., the node could be isolated from the
-       other IPv6 networks, only having link-local addresses).
-
-   3.  The system library might implement a toggle which would apply
-       some heuristics to the "IPv6-readiness" of the node before
-       starting to perform queries; for example, it could check whether
-       only link-local IPv6 address(es) exists, or if at least one
-       global IPv6 address exists.
-
-   First, let us consider generic implications of unnecessary queries
-   for AAAA records: when looking up all the records in the DNS, AAAA
-   records are typically tried first, and then A records.  These are
-   done in serial, and the A query is not performed until a response is
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 11]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   received to the AAAA query.  Considering the misbehaviour of DNS
-   servers and load-balancers, as described in Section 3.1, the look-up
-   delay for AAAA may incur additional unnecessary latency, and
-   introduce a component of unreliability.
-
-   One option here could be to do the queries partially in parallel; for
-   example, if the final response to the AAAA query is not received in
-   0.5 seconds, start performing the A query while waiting for the
-   result (immediate parallelism might be unoptimal, at least without
-   information sharing between the look-up threads, as that would
-   probably lead to duplicate non-cached delegation chain lookups).
-
-   An additional concern is the address selection, which may, in some
-   circumstances, prefer AAAA records over A records even when the node
-   does not have any IPv6 connectivity [I-D.ietf-v6ops-v6onbydefault].
-   In some cases, the implementation may attempt to connect or send a
-   datagram on a physical link [I-D.ietf-v6ops-onlinkassumption],
-   incurring very long protocol timeouts, instead of quickly failing
-   back to IPv4.
-
-   Now, we can consider the issues specific to each of the three
-   possibilities:
-
-   In the first case, the node performs a number of completely useless
-   DNS lookups as it will not be able to use the returned AAAA records
-   anyway.  (The only exception is where the application desires to know
-   what's in the DNS, but not use the result for communication.)  One
-   should be able to disable these unnecessary queries, for both latency
-   and reliability reasons.  However, as IPv6 has not been enabled, the
-   connections to IPv6 addresses fail immediately, and if the
-   application is programmed properly, the application can fall
-   gracefully back to IPv4 [RFC4038].
-
-   The second case is similar to the first, except it happens to a
-   smaller set of nodes when IPv6 has been enabled but connectivity has
-   not been provided yet; similar considerations apply, with the
-   exception that IPv6 records, when returned, will be actually tried
-   first which may typically lead to long timeouts.
-
-   The third case is a bit more complex: optimizing away the DNS lookups
-   with only link-locals is probably safe (but may be desirable with
-   different lookup services which getaddrinfo() may support), as the
-   link-locals are typically automatically generated when IPv6 is
-   enabled, and do not indicate any form of IPv6 connectivity.  That is,
-   performing DNS lookups only when a non-link-local address has been
-   configured on any interface could be beneficial -- this would be an
-   indication that either the address has been configured either from a
-   router advertisement, DHCPv6 [RFC3315], or manually.  Each would
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 12]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   indicate at least some form of IPv6 connectivity, even though there
-   would not be guarantees of it.
-
-   These issues should be analyzed at more depth, and the fixes found
-   consensus on, perhaps in a separate document.
-
-5.2  Obtaining a List of DNS Recursive Resolvers
-
-   In scenarios where DHCPv6 is available, a host can discover a list of
-   DNS recursive resolvers through DHCPv6 "DNS Recursive Name Server"
-   option [RFC3646].  This option can be passed to a host through a
-   subset of DHCPv6 [RFC3736].
-
-   The IETF is considering the development of alternative mechanisms for
-   obtaining the list of DNS recursive name servers when DHCPv6 is
-   unavailable or inappropriate.  No decision about taking on this
-   development work has been reached as of this writing (Aug 2004)
-   [I-D.ietf-dnsop-ipv6-dns-configuration].
-
-   In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms
-   under consideration for development include the use of well-known
-   addresses [I-D.ohta-preconfigured-dns] and the use of Router
-   Advertisements to convey the information [I-D.jeong-dnsop-ipv6-dns-
-   discovery].
-
-   Note that even though IPv6 DNS resolver discovery is a recommended
-   procedure, it is not required for dual-stack nodes in dual-stack
-   networks as IPv6 DNS records can be queried over IPv4 as well as
-   IPv6.  Obviously, nodes which are meant to function without manual
-   configuration in IPv6-only networks must implement the DNS resolver
-   discovery function.
-
-5.3  IPv6 Transport Guidelines for Resolvers
-
-   As described in Section 1.3 and [RFC3901], the recursive resolvers
-   should be IPv4-only or dual-stack to be able to reach any IPv4-only
-   DNS server.  Note that this requirement is also fulfilled by an IPv6-
-   only stub resolver pointing to a dual-stack recursive DNS resolver.
-
-6.  Considerations about Forward DNS Updating
-
-   While the topic of how to enable updating the forward DNS, i.e., the
-   mapping from names to the correct new addresses, is not specific to
-   IPv6, it should be considered especially due to the advent of
-   Stateless Address Autoconfiguration [RFC2462].
-
-   Typically forward DNS updates are more manageable than doing them in
-   the reverse DNS, because the updater can often be assumed to "own" a
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 13]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   certain DNS name -- and we can create a form of security relationship
-   with the DNS name and the node which is allowed to update it to point
-   to a new address.
-
-   A more complex form of DNS updates -- adding a whole new name into a
-   DNS zone, instead of updating an existing name -- is considered out
-   of scope for this memo as it could require zone-wide authentication.
-   Adding a new name in the forward zone is a problem which is still
-   being explored with IPv4, and IPv6 does not seem to add much new in
-   that area.
-
-6.1  Manual or Custom DNS Updates
-
-   The DNS mappings can also be maintained by hand, in a semi-automatic
-   fashion or by running non-standardized protocols.  These are not
-   considered at more length in this memo.
-
-6.2  Dynamic DNS
-
-   Dynamic DNS updates (DDNS) [RFC2136] [RFC3007] is a standardized
-   mechanism for dynamically updating the DNS.  It works equally well
-   with stateless address autoconfiguration (SLAAC), DHCPv6 or manual
-   address configuration.  It is important to consider how each of these
-   behave if IP address-based authentication, instead of stronger
-   mechanisms [RFC3007], was used in the updates.
-
-   1.  manual addresses are static and can be configured
-
-   2.  DHCPv6 addresses could be reasonably static or dynamic, depending
-       on the deployment, and could or could not be configured on the
-       DNS server for the long term
-
-   3.  SLAAC addresses are typically stable for a long time, but could
-       require work to be configured and maintained.
-
-   As relying on IP addresses for Dynamic DNS is rather insecure at
-   best, stronger authentication should always be used; however, this
-   requires that the authorization keying will be explicitly configured
-   using unspecified operational methods.
-
-   Note that with DHCP it is also possible that the DHCP server updates
-   the DNS, not the host.  The host might only indicate in the DHCP
-   exchange which hostname it would prefer, and the DHCP server would
-   make the appropriate updates.  Nonetheless, while this makes setting
-   up a secure channel between the updater and the DNS server easier, it
-   does not help much with "content" security, i.e., whether the
-   hostname was acceptable -- if the DNS server does not include
-   policies, they must be included in the DHCP server (e.g., a regular
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 14]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   host should not be able to state that its name is "www.example.com").
-   DHCP-initiated DDNS updates have been extensively described in
-   [I-D.ietf-dhc-ddns-resolution], [I-D.ietf-dhc-fqdn-option] and
-   [I-D.ietf-dnsext-dhcid-rr].
-
-   The nodes must somehow be configured with the information about the
-   servers where they will attempt to update their addresses, sufficient
-   security material for authenticating themselves to the server, and
-   the hostname they will be updating.  Unless otherwise configured, the
-   first could be obtained by looking up the authoritative name servers
-   for the hostname; the second must be configured explicitly unless one
-   chooses to trust the IP address-based authentication (not a good
-   idea); and lastly, the nodename is typically pre-configured somehow
-   on the node, e.g., at install time.
-
-   Care should be observed when updating the addresses not to use longer
-   TTLs for addresses than are preferred lifetimes for the addresses, so
-   that if the node is renumbered in a managed fashion, the amount of
-   stale DNS information is kept to the minimum.  That is, if the
-   preferred lifetime of an address expires, the TTL of the record needs
-   be modified unless it was already done before the expiration.  For
-   better flexibility, the DNS TTL should be much shorter (e.g., a half
-   or a third) than the lifetime of an address; that way, the node can
-   start lowering the DNS TTL if it seems like the address has not been
-   renewed/refreshed in a while.  Some discussion on how an
-   administrator could manage the DNS TTL is included in [I-D.ietf-
-   v6ops-renumbering-procedure]; this could be applied to (smart) hosts
-   as well.
-
-7.  Considerations about Reverse DNS Updating
-
-   Updating the reverse DNS zone may be difficult because of the split
-   authority over an address.  However, first we have to consider the
-   applicability of reverse DNS in the first place.
-
-7.1  Applicability of Reverse DNS
-
-   Today, some applications use reverse DNS to either look up some hints
-   about the topological information associated with an address (e.g.
-   resolving web server access logs), or as a weak form of a security
-   check, to get a feel whether the user's network administrator has
-   "authorized" the use of the address (on the premises that adding a
-   reverse record for an address would signal some form of
-   authorization).
-
-   One additional, maybe slightly more useful usage is ensuring that the
-   reverse and forward DNS contents match (by looking up the pointer to
-   the name by the IP address from the reverse tree, and ensuring that a
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 15]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   record under the name in the forward tree points to the IP address)
-   and correspond to a configured name or domain.  As a security check,
-   it is typically accompanied by other mechanisms, such as a user/
-   password login; the main purpose of the reverse+forward DNS check is
-   to weed out the majority of unauthorized users, and if someone
-   managed to bypass the checks, he would still need to authenticate
-   "properly".
-
-   It may also be desirable to store IPsec keying material corresponding
-   to an IP address in the reverse DNS, as justified and described in
-   [RFC4025].
-
-   It is not clear whether it makes sense to require or recommend that
-   reverse DNS records be updated.  In many cases, it would just make
-   more sense to use proper mechanisms for security (or topological
-   information lookup) in the first place.  At minimum, the applications
-   which use it as a generic authorization (in the sense that a record
-   exists at all) should be modified as soon as possible to avoid such
-   lookups completely.
-
-   The applicability is discussed at more length in [I-D.ietf-dnsop-
-   inaddr-required].
-
-7.2  Manual or Custom DNS Updates
-
-   Reverse DNS can of course be updated using manual or custom methods.
-   These are not further described here, except for one special case.
-
-   One way to deploy reverse DNS would be to use wildcard records, for
-   example, by configuring one name for a subnet (/64) or a site (/48).
-   As a concrete example, a site (or the site's ISP) could configure the
-   reverses of the prefix 2001:db8:f00::/48 to point to one name using a
-   wildcard record like "*.0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa.  IN PTR
-   site.example.com."  Naturally, such a name could not be verified from
-   the forward DNS, but would at least provide some form of "topological
-   information" or "weak authorization" if that is really considered to
-   be useful.  Note that this is not actually updating the DNS as such,
-   as the whole point is to avoid DNS updates completely by manually
-   configuring a generic name.
-
-7.3  DDNS with Stateless Address Autoconfiguration
-
-   Dynamic reverse DNS with SLAAC is simpler than forward DNS updates in
-   some regard, while being more difficult in another, as described
-   below.
-
-   The address space administrator decides whether the hosts are trusted
-   to update their reverse DNS records or not.  If they are trusted and
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 16]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   deployed at the same site (e.g., not across the Internet), a simple
-   address-based authorization is typically sufficient (i.e., check that
-   the DNS update is done from the same IP address as the record being
-   updated); stronger security can also be used [RFC3007].  If they
-   aren't allowed to update the reverses, no update can occur.  However,
-   such address-based update authorization operationally requires that
-   ingress filtering [RFC3704] has been set up at the border of the site
-   where the updates occur, and as close to the updater as possible.
-
-   Address-based authorization is simpler with reverse DNS (as there is
-   a connection between the record and the address) than with forward
-   DNS.  However, when a stronger form of security is used, forward DNS
-   updates are simpler to manage because the host can be assumed to have
-   an association with the domain.  Note that the user may roam to
-   different networks, and does not necessarily have any association
-   with the owner of that address space -- so, assuming stronger form of
-   authorization for reverse DNS updates than an address association is
-   generally infeasible.
-
-   Moreover, the reverse zones must be cleaned up by an unspecified
-   janitorial process: the node does not typically know a priori that it
-   will be disconnected, and cannot send a DNS update using the correct
-   source address to remove a record.
-
-   A problem with defining the clean-up process is that it is difficult
-   to ensure that a specific IP address and the corresponding record are
-   no longer being used.  Considering the huge address space, and the
-   unlikelihood of collision within 64 bits of the interface
-   identifiers, a process which would remove the record after no traffic
-   has been seen from a node in a long period of time (e.g., a month or
-   year) might be one possible approach.
-
-   To insert or update the record, the node must discover the DNS server
-   to send the update to somehow, similar to as discussed in
-   Section 6.2.  One way to automate this is looking up the DNS server
-   authoritative (e.g., through SOA record) for the IP address being
-   updated, but the security material (unless the IP address-based
-   authorization is trusted) must also be established by some other
-   means.
-
-   One should note that Cryptographically Generated Addresses [RFC3972]
-   (CGAs) may require a slightly different kind of treatment.  CGAs are
-   addresses where the interface identifier is calculated from a public
-   key, a modifier (used as a nonce), the subnet prefix, and other data.
-   Depending on the usage profile, CGAs might or might not be changed
-   periodically due to e.g., privacy reasons.  As the CGA address is not
-   predicatable, a reverse record can only reasonably be inserted in the
-   DNS by the node which generates the address.
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 17]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-7.4  DDNS with DHCP
-
-   With DHCPv4, the reverse DNS name is typically already inserted to
-   the DNS that reflects to the name (e.g., "dhcp-67.example.com").  One
-   can assume similar practice may become commonplace with DHCPv6 as
-   well; all such mappings would be pre-configured, and would require no
-   updating.
-
-   If a more explicit control is required, similar considerations as
-   with SLAAC apply, except for the fact that typically one must update
-   a reverse DNS record instead of inserting one (if an address
-   assignment policy that reassigns disused addresses is adopted) and
-   updating a record seems like a slightly more difficult thing to
-   secure.  However, it is yet uncertain how DHCPv6 is going to be used
-   for address assignment.
-
-   Note that when using DHCP, either the host or the DHCP server could
-   perform the DNS updates; see the implications in Section 6.2.
-
-   If disused addresses were to be reassigned, host-based DDNS reverse
-   updates would need policy considerations for DNS record modification,
-   as noted above.  On the other hand, if disused address were not to be
-   assigned, host-based DNS reverse updates would have similar
-   considerations as SLAAC in Section 7.3.  Server-based updates have
-   similar properties except that the janitorial process could be
-   integrated with DHCP address assignment.
-
-7.5  DDNS with Dynamic Prefix Delegation
-
-   In cases where a prefix, instead of an address, is being used and
-   updated, one should consider what is the location of the server where
-   DDNS updates are made.  That is, where the DNS server is located:
-
-   1.  At the same organization as the prefix delegator.
-
-   2.  At the site where the prefixes are delegated to.  In this case,
-       the authority of the DNS reverse zone corresponding to the
-       delegated prefix is also delegated to the site.
-
-   3.  Elsewhere; this implies a relationship between the site and where
-       DNS server is located, and such a relationship should be rather
-       straightforward to secure as well.  Like in the previous case,
-       the authority of the DNS reverse zone is also delegated.
-
-   In the first case, managing the reverse DNS (delegation) is simpler
-   as the DNS server and the prefix delegator are in the same
-   administrative domain (as there is no need to delegate anything at
-   all); alternatively, the prefix delegator might forgo DDNS reverse
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 18]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   capability altogether, and use e.g., wildcard records (as described
-   in Section 7.2).  In the other cases, it can be slighly more
-   difficult, particularly as the site will have to configure the DNS
-   server to be authoritative for the delegated reverse zone, implying
-   automatic configuration of the DNS server -- as the prefix may be
-   dynamic.
-
-   Managing the DDNS reverse updates is typically simple in the second
-   case, as the updated server is located at the local site, and
-   arguably IP address-based authentication could be sufficient (or if
-   not, setting up security relationships would be simpler).  As there
-   is an explicit (security) relationship between the parties in the
-   third case, setting up the security relationships to allow reverse
-   DDNS updates should be rather straightforward as well (but IP
-   address-based authentication might not be acceptable).  In the first
-   case, however, setting up and managing such relationships might be a
-   lot more difficult.
-
-8.  Miscellaneous DNS Considerations
-
-   This section describes miscellaneous considerations about DNS which
-   seem related to IPv6, for which no better place has been found in
-   this document.
-
-8.1  NAT-PT with DNS-ALG
-
-   The DNS-ALG component of NAT-PT mangles A records  to look like AAAA
-   records to the IPv6-only nodes.  Numerous problems have been
-   identified with DNS-ALG [I-D.ietf-v6ops-natpt-to-exprmntl].  This is
-   a strong reason not to use NAT-PT in the first place.
-
-8.2  Renumbering Procedures and Applications' Use of DNS
-
-   One of the most difficult problems of systematic IP address
-   renumbering procedures [I-D.ietf-v6ops-renumbering-procedure] is that
-   an application which looks up a DNS name disregards information such
-   as TTL, and uses the result obtained from DNS as long as it happens
-   to be stored in the memory of the application.  For applications
-   which run for a long time, this could be days, weeks or even months;
-   some applications may be clever enough to organize the data
-   structures and functions in such a manner that look-ups get refreshed
-   now and then.
-
-   While the issue appears to have a clear solution, "fix the
-   applications", practically this is not reasonable immediate advice;
-   the TTL information is not typically available in the APIs and
-   libraries (so, the advice becomes "fix the applications, APIs and
-   libraries"), and a lot more analysis is needed on how to practically
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 19]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   go about to achieve the ultimate goal of avoiding using the names
-   longer than expected.
-
-9.  Acknowledgements
-
-   Some recommendations (Section 4.3, Section 5.1) about IPv6 service
-   provisioning were moved here from [I-D.ietf-v6ops-mech-v2] by Erik
-   Nordmark and Bob Gilligan.  Havard Eidnes and Michael Patton provided
-   useful feedback and improvements.  Scott Rose, Rob Austein, Masataka
-   Ohta, and Mark Andrews helped in clarifying the issues regarding
-   additional data and the use of TTL.  Jefsey Morfin, Ralph Droms,
-   Peter Koch, Jinmei Tatuya, Iljitsch van Beijnum, Edward Lewis, and
-   Rob Austein provided useful feedback during the WG last call.  Thomas
-   Narten provided extensive feedback during the IESG evaluation.
-
-10.  Security Considerations
-
-   This document reviews the operational procedures for IPv6 DNS
-   operations and does not have security considerations in itself.
-
-   However, it is worth noting that in particular with Dynamic DNS
-   Updates, security models based on the source address validation are
-   very weak and cannot be recommended -- they could only be considered
-   in the environments where ingress filtering [RFC3704] has been
-   deployed.  On the other hand, it should be noted that setting up an
-   authorization mechanism (e.g., a shared secret, or public-private
-   keys) between a node and the DNS server has to be done manually, and
-   may require quite a bit of time and expertise.
-
-   To re-emphasize what was already stated, the reverse+forward DNS
-   check provides very weak security at best, and the only
-   (questionable) security-related use for them may be in conjunction
-   with other mechanisms when authenticating a user.
-
-11.  References
-
-11.1  Normative References
-
-   [I-D.ietf-dnsop-ipv6-dns-configuration]
-              Jeong, J., "IPv6 Host Configuration of DNS Server
-              Information Approaches",
-              draft-ietf-dnsop-ipv6-dns-configuration-06 (work in
-              progress), May 2005.
-
-   [I-D.ietf-ipv6-unique-local-addr]
-              Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
-              Addresses", draft-ietf-ipv6-unique-local-addr-09 (work in
-              progress), January 2005.
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 20]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   [I-D.ietf-v6ops-renumbering-procedure]
-              Baker, F., "Procedures for Renumbering an IPv6 Network
-              without a Flag Day",
-              draft-ietf-v6ops-renumbering-procedure-05 (work in
-              progress), March 2005.
-
-   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
-              STD 13, RFC 1034, November 1987.
-
-   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
-              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
-              RFC 2136, April 1997.
-
-   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
-              Specification", RFC 2181, July 1997.
-
-   [RFC2182]  Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection
-              and Operation of Secondary DNS Servers", BCP 16, RFC 2182,
-              July 1997.
-
-   [RFC2462]  Thomson, S. and T. Narten, "IPv6 Stateless Address
-              Autoconfiguration", RFC 2462, December 1998.
-
-   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
-              RFC 2671, August 1999.
-
-   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
-              April 2001.
-
-   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
-              Update", RFC 3007, November 2000.
-
-   [RFC3041]  Narten, T. and R. Draves, "Privacy Extensions for
-              Stateless Address Autoconfiguration in IPv6", RFC 3041,
-              January 2001.
-
-   [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
-              via IPv4 Clouds", RFC 3056, February 2001.
-
-   [RFC3152]  Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152,
-              August 2001.
-
-   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
-              and M. Carney, "Dynamic Host Configuration Protocol for
-              IPv6 (DHCPv6)", RFC 3315, July 2003.
-
-   [RFC3363]  Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
-              Hain, "Representing Internet Protocol version 6 (IPv6)
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 21]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-              Addresses in the Domain Name System (DNS)", RFC 3363,
-              August 2002.
-
-   [RFC3364]  Austein, R., "Tradeoffs in Domain Name System (DNS)
-              Support for Internet Protocol version 6 (IPv6)", RFC 3364,
-              August 2002.
-
-   [RFC3513]  Hinden, R. and S. Deering, "Internet Protocol Version 6
-              (IPv6) Addressing Architecture", RFC 3513, April 2003.
-
-   [RFC3596]  Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
-              "DNS Extensions to Support IP Version 6", RFC 3596,
-              October 2003.
-
-   [RFC3646]  Droms, R., "DNS Configuration options for Dynamic Host
-              Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
-              December 2003.
-
-   [RFC3736]  Droms, R., "Stateless Dynamic Host Configuration Protocol
-              (DHCP) Service for IPv6", RFC 3736, April 2004.
-
-   [RFC3879]  Huitema, C. and B. Carpenter, "Deprecating Site Local
-              Addresses", RFC 3879, September 2004.
-
-   [RFC3901]  Durand, A. and J. Ihren, "DNS IPv6 Transport Operational
-              Guidelines", BCP 91, RFC 3901, September 2004.
-
-   [RFC4038]  Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
-              Castro, "Application Aspects of IPv6 Transition",
-              RFC 4038, March 2005.
-
-   [RFC4074]  Morishita, Y. and T. Jinmei, "Common Misbehavior Against
-              DNS Queries for IPv6 Addresses", RFC 4074, May 2005.
-
-11.2  Informative References
-
-   [I-D.durand-dnsop-dont-publish]
-              Durand, A. and T. Chown, "To publish, or not to publish,
-              that is the question.", draft-durand-dnsop-dont-publish-00
-              (work in progress), February 2005.
-
-   [I-D.huitema-v6ops-teredo]
-              Huitema, C., "Teredo: Tunneling IPv6 over UDP through
-              NATs", draft-huitema-v6ops-teredo-05 (work in progress),
-              April 2005.
-
-   [I-D.huston-6to4-reverse-dns]
-              Huston, G., "6to4 Reverse DNS Delegation",
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 22]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-              draft-huston-6to4-reverse-dns-03 (work in progress),
-              October 2004.
-
-   [I-D.ietf-dhc-ddns-resolution]
-              Stapp, M. and B. Volz, "Resolution of FQDN Conflicts among
-              DHCP Clients", draft-ietf-dhc-ddns-resolution-09 (work in
-              progress), June 2005.
-
-   [I-D.ietf-dhc-fqdn-option]
-              Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option",
-              draft-ietf-dhc-fqdn-option-10 (work in progress),
-              February 2005.
-
-   [I-D.ietf-dnsext-dhcid-rr]
-              Stapp, M., Lemon, T., and A. Gustafsson, "A DNS RR for
-              encoding DHCP information (DHCID RR)",
-              draft-ietf-dnsext-dhcid-rr-09 (work in progress),
-              February 2005.
-
-   [I-D.ietf-dnsop-bad-dns-res]
-              Larson, M. and P. Barber, "Observed DNS Resolution
-              Misbehavior", draft-ietf-dnsop-bad-dns-res-03 (work in
-              progress), October 2004.
-
-   [I-D.ietf-dnsop-inaddr-required]
-              Senie, D., "Encouraging the use of DNS IN-ADDR Mapping",
-              draft-ietf-dnsop-inaddr-required-06 (work in progress),
-              February 2005.
-
-   [I-D.ietf-v6ops-3gpp-analysis]
-              Wiljakka, J., "Analysis on IPv6 Transition in 3GPP
-              Networks", draft-ietf-v6ops-3gpp-analysis-11 (work in
-              progress), October 2004.
-
-   [I-D.ietf-v6ops-mech-v2]
-              Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
-              for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-07
-              (work in progress), March 2005.
-
-   [I-D.ietf-v6ops-natpt-to-exprmntl]
-              Aoun, C. and E. Davies, "Reasons to Move NAT-PT to
-              Experimental", draft-ietf-v6ops-natpt-to-exprmntl-01 (work
-              in progress), July 2005.
-
-   [I-D.ietf-v6ops-onlinkassumption]
-              Roy, S., "IPv6 Neighbor Discovery On-Link Assumption
-              Considered Harmful", draft-ietf-v6ops-onlinkassumption-03
-              (work in progress), May 2005.
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 23]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   [I-D.ietf-v6ops-v6onbydefault]
-              Roy, S., Durand, A., and J. Paugh, "Issues with Dual Stack
-              IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03
-              (work in progress), July 2004.
-
-   [I-D.jeong-dnsop-ipv6-dns-discovery]
-              Jeong, J., "IPv6 DNS Configuration based on Router
-              Advertisement", draft-jeong-dnsop-ipv6-dns-discovery-04
-              (work in progress), February 2005.
-
-   [I-D.ohta-preconfigured-dns]
-              Ohta, M., "Preconfigured DNS Server Addresses",
-              draft-ohta-preconfigured-dns-01 (work in progress),
-              February 2004.
-
-   [RFC2766]  Tsirtsis, G. and P. Srisuresh, "Network Address
-              Translation - Protocol Translation (NAT-PT)", RFC 2766,
-              February 2000.
-
-   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
-              specifying the location of services (DNS SRV)", RFC 2782,
-              February 2000.
-
-   [RFC2826]  Internet Architecture Board, "IAB Technical Comment on the
-              Unique DNS Root", RFC 2826, May 2000.
-
-   [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
-              Networks", BCP 84, RFC 3704, March 2004.
-
-   [RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
-              RFC 3972, March 2005.
-
-   [RFC4025]  Richardson, M., "A Method for Storing IPsec Keying
-              Material in DNS", RFC 4025, March 2005.
-
-
-Authors' Addresses
-
-   Alain Durand
-   SUN Microsystems, Inc.
-   17 Network circle UMPL17-202
-   Menlo Park, CA  94025
-   USA
-
-   Email: Alain.Durand@sun.com
-
-
-
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 24]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   Johan Ihren
-   Autonomica
-   Bellmansgatan 30
-   SE-118 47 Stockholm
-   Sweden
-
-   Email: johani@autonomica.se
-
-
-   Pekka Savola
-   CSC/FUNET
-   Espoo
-   Finland
-
-   Email: psavola@funet.fi
-
-Appendix A.  Unique Local Addressing Considerations for DNS
-
-   Unique local addresses [I-D.ietf-ipv6-unique-local-addr] have
-   replaced the now-deprecated site-local addresses [RFC3879].  From the
-   perspective of the DNS, the locally generated unique local addresses
-   (LUL) and site-local addresses have similar properties.
-
-   The interactions with DNS come in two flavors: forward and reverse
-   DNS.
-
-   To actually use local addresses within a site, this implies the
-   deployment of a "split-faced" or a fragmented DNS name space, for the
-   zones internal to the site, and the outsiders' view to it.  The
-   procedures to achieve this are not elaborated here.  The implication
-   is that local addresses must not be published in the public DNS.
-
-   To faciliate reverse DNS (if desired) with local addresses, the stub
-   resolvers must look for DNS information from the local DNS servers,
-   not e.g. starting from the root servers, so that the local
-   information may be provided locally.  Note that the experience of
-   private addresses in IPv4 has shown that the root servers get loaded
-   for requests for private address lookups in any case.  This
-   requirement is discussed in [I-D.ietf-ipv6-unique-local-addr].
-
-Appendix B.  Behaviour of Additional Data in IPv4/IPv6 Environments
-
-   DNS responses do not always fit in a single UDP packet.  We'll
-   examine the cases which happen when this is due to too much data in
-   the Additional Section.
-
-
-
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 25]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-B.1  Description of Additional Data Scenarios
-
-   There are two kinds of additional data:
-
-   1.  "critical" additional data; this must be included in all
-       scenarios, with all the RRsets, and
-
-   2.  "courtesy" additional data; this could be sent in full, with only
-       a few RRsets, or with no RRsets, and can be fetched separately as
-       well, but at the cost of additional queries.
-
-   The responding server can algorithmically determine which type the
-   additional data is by checking whether it's at or below a zone cut.
-
-   Only those additional data records (even if sometimes carelessly
-   termed "glue") are considered "critical" or real "glue" if and only
-   if they meet the abovementioned condition, as specified in Section
-   4.2.1 of [RFC1034].
-
-   Remember that resource record sets (RRsets) are never "broken up", so
-   if a name has 4 A records and 5 AAAA records, you can either return
-   all 9, all 4 A records, all 5 AAAA records or nothing.  In
-   particular, notice that for the "critical" additional data getting
-   all the RRsets can be critical.
-
-   In particular, [RFC2181] specifies (in Section 9) that:
-
-   a.  if all the "critical" RRsets do not fit, the sender should set
-       the TC bit, and the recipient should discard the whole response
-       and retry using mechanism allowing larger responses such as TCP.
-
-   b.  "courtesy" additional data should not cause the setting of TC
-       bit, but instead all the non-fitting additional data RRsets
-       should be removed.
-
-   An example of the "courtesy" additional data is A/AAAA records in
-   conjunction with MX records as shown in Section 4.4; an example of
-   the "critical" additional data is shown below (where getting both the
-   A and AAAA RRsets is critical w.r.t. to the NS RR):
-
-      child.example.com.    IN   NS ns.child.example.com.
-      ns.child.example.com. IN    A 192.0.2.1
-      ns.child.example.com. IN AAAA 2001:db8::1
-
-   When there is too much "courtesy" additional data, at least the non-
-   fitting RRsets should be removed [RFC2181]; however, as the
-   additional data is not critical, even all of it could be safely
-   removed.
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 26]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   When there is too much "critical" additional data, TC bit will have
-   to be set, and the recipient should ignore the response and retry
-   using TCP; if some data were to be left in the UDP response, the
-   issue is which data could be retained.
-
-   Failing to discard the response with TC bit or omitting critical
-   information but not setting TC bit lead to an unrecoverable problem.
-   Omitting only some of the RRsets if all would not fit (but not
-   setting TC bit) leads to a performance problem.  These are discussed
-   in the next two subsections.
-
-B.2  Which Additional Data to Keep, If Any?
-
-   If the implementation decides to keep as much data (whether
-   "critical" or "courtesy") as possible in the UDP responses, it might
-   be tempting to use the transport of the DNS query as a hint in either
-   of these cases: return the AAAA records if the query was done over
-   IPv6, or return the A records if the query was done over IPv4.
-   However, this breaks the model of independence of DNS transport and
-   resource records, as noted in Section 1.2.
-
-   With courtesy additional data, as long as enough RRsets will be
-   removed so that TC will not be set, it is allowed to send as many
-   complete RRsets as the implementations prefers.  However, the
-   implementations are also free to omit all such RRsets, even if
-   complete.  Omitting all the RRsets (when removing only some would
-   suffice) may create a performance penalty, whereby the client may
-   need to issue one or more additional queries to obtain necessary
-   and/or consistent information.
-
-   With critical additional data, the alternatives are either returning
-   nothing (and absolutely requiring a retry with TCP) or returning
-   something (working also in the case if the recipient does not discard
-   the response and retry using TCP) in addition to setting the TC bit.
-   If the process for selecting "something" from the critical data would
-   otherwise be practically "flipping the coin" between A and AAAA
-   records, it could be argued that if one looked at the transport of
-   the query, it would have a larger possibility of being right than
-   just 50/50.  In other words, if the returned critical additional data
-   would have to be selected somehow, using something more sophisticated
-   than a random process would seem justifiable.
-
-   That is, leaving in some intelligently selected critical additional
-   data is a tradeoff between creating an optimization for those
-   resolvers which ignore the "should discard" recommendation, and
-   causing a protocol problem by propagating inconsistent information
-   about "critical" records in the caches.
-
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 27]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   Similarly, leaving in the complete courtesy additional data RRsets
-   instead of removing all the RRsets is a performance tradeoff as
-   described in the next section.
-
-B.3  Discussion of the Potential Problems
-
-   As noted above, the temptation for omitting only some of the
-   additional data could be problematic.  This is discussed more below.
-
-   For courtesy additional data, this causes a potential performance
-   problem as this requires that the clients issue re-queries for the
-   potentially omitted RRsets.  For critical additional data, this
-   causes a potential unrecoverable problem if the response is not
-   discarded and the query not re-tried with TCP, as the nameservers
-   might be reachable only through the omitted RRsets.
-
-   If an implementation would look at the transport used for the query,
-   it is worth remembering that often the host using the records is
-   different from the node requesting them from the authoritative DNS
-   server (or even a caching resolver).  So, whichever version the
-   requestor (e.g., a recursive server in the middle) uses makes no
-   difference to the ultimate user of the records, whose transport
-   capabilities might differ from those of the requestor.  This might
-   result in e.g., inappropriately returning A records to an IPv6-only
-   node, going through a translation, or opening up another IP-level
-   session (e.g., a PDP context [I-D.ietf-v6ops-3gpp-analysis]).
-   Therefore, at least in many scenarios, it would be very useful if the
-   information returned would be consistent and complete -- or if that
-   is not feasible, return no misleading information but rather leave it
-   to the client to query again.
-
-   The problem of too much additional data seems to be an operational
-   one: the zone administrator entering too many records which will be
-   returned either truncated (or missing some RRsets, depending on
-   implementations) to the users.  A protocol fix for this is using
-   EDNS0 [RFC2671] to signal the capacity for larger UDP packet sizes,
-   pushing up the relevant threshold.  Further, DNS server
-   implementations should rather omit courtesy additional data
-   completely rather than including only some RRsets [RFC2181].  An
-   operational fix for this is having the DNS server implementations
-   return a warning when the administrators create zones which would
-   result in too much additional data being returned.  Further, DNS
-   server implementations should warn of or disallow such zone
-   configurations which are recursive or otherwise difficult to manage
-   by the protocol.
-
-   Additionally, to avoid the case where an application would not get an
-   address at all due to some of courtesy additional data being omitted,
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 28]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   the resolvers should be able to query the specific records of the
-   desired protocol, not just rely on getting all the required RRsets in
-   the additional section.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 29]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 30]
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt
deleted file mode 100644
index b2e2341..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt
+++ /dev/null
@@ -1,300 +0,0 @@
-Internet Engineering Task Force                         A.Durand
-INTERNET-DRAFT                             SUN Microsystems,inc.
-November, 24, 2003                                      J. Ihren
-Expires May 25, 2004                                  Autonomica
-
-
-               DNS IPv6 transport operational guidelines
-          <draft-ietf-dnsop-ipv6-transport-guidelines-01.txt>
-
-
-
-Status of this Memo
-
-   This memo provides information to the Internet community. It does not
-   specify an Internet standard of any kind. This memo is in full
-   conformance with all provisions of Section 10 of RFC2026
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet- Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/1id-abstracts.html
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-
-Abstract
-
-   This memo provides guidelines and Best Current Practice to operate
-   DNS in a world where queries and responses are carried in a mixed
-   environment of IPv4 and IPv6 networks.
-
-
-Acknowledgment
-
-   This document is the result of many conversations that happened in
-   the DNS community at IETF and elsewhere since 2001. During that
-   period of time, a number of Internet drafts have been published to
-   clarify various aspects of the issues at stake. This document focuses
-   on the conclusion of those discussions.
-
-   The authors would like to acknowledge the role of Pekka Savola in his
-   thorough review of the document.
-
-
-1. Terminology
-
-   The phrase "IPv4 name server" indicates a name server available over
-   IPv4 transport. It does not imply anything about what DNS data is
-   served. Likewise, "IPv6 name server" indicates a name server
-   available over IPv6 transport. The phrase "dual-stack DNS server"
-   indicates a DNS server that is actually configured to run both
-   protocols, IPv4 and IPv6, and not merely a server running on a system
-   capable of running both but actually configured to run only one.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [2119].
-
-
-2. Introduction to the Problem of Name Space Fragmentation:
-     following the referral chain
-
-   The caching resolver that tries to look up a name starts out at the
-   root, and follows referrals until it is referred to a nameserver that
-   is authoritative for the name.  If somewhere down the chain of
-   referrals it is referred to a nameserver that is only accessible over
-   an unavailable type of transport, a traditional nameserver is unable
-   to finish the task.
-
-   When the Internet moves from IPv4 to a mixture of IPv4 and IPv6 it is
-   only a matter of time until this starts to happen. The complete DNS
-   hierarchy then starts to fragment into a graph where authoritative
-   nameservers for certain nodes are only accessible over a certain
-   transport. What is feared is that a node using only a particular
-   version of IP, querying information about another node using the same
-   version of IP can not do it because, somewhere in the chain of
-   servers accessed during the resolution process, one or more of them
-   will only be accessible with the other version of IP.
-
-   With all DNS data only available over IPv4 transport everything is
-   simple. IPv4 resolvers can use the intended mechanism of following
-   referrals from the root and down while IPv6 resolvers have to work
-   through a "translator", i.e. they have to use a second name server on
-   a so-called "dual stack" host as a "forwarder" since they cannot
-   access the DNS data directly.
-
-   With all DNS data only available over IPv6 transport everything would
-   be equally simple, with the exception of old legacy IPv4 name servers
-   having to switch to a forwarding configuration.
-
-   However, the second situation will not arise in a foreseeable time.
-   Instead, it is expected that the transition will be from IPv4 only to
-   a mixture of IPv4 and IPv6, with DNS data of theoretically three
-   categories depending on whether it is available only over IPv4
-   transport, only over IPv6 or both.
-
-   Having DNS data available on both transports is the best situation.
-   The major question is how to ensure that it as quickly as possible
-   becomes the norm. However, while it is obvious that some DNS data
-   will only be available over v4 transport for a long time it is also
-   obvious that it is important to avoid fragmenting the name space
-   available to IPv4 only hosts. I.e. during transition it is not
-   acceptable to break the name space that we presently have available
-   for IPv4-only hosts.
-
-
-3. Policy Based Avoidance of Name Space Fragmentation
-
-   Today there are only a few DNS "zones" on the public Internet that
-   are  available over IPv6 transport, and most of them can be regarded
-   as "experimental". However, as soon as the root and top level domains
-   are available over IPv6 transport, it is reasonable to expect that it
-   will become more common to have zones served by IPv6 servers.
-
-   Having those zones served only by IPv6-only name server would not be
-   a good development, since this will fragment the previously
-   unfragmented IPv4 name space and there are strong reasons to find a
-   mechanism to avoid it.
-
-   The RECOMMENDED approach to maintain name space continuity is to use
-   administrative policies, as described in the next section.
-
-
-4. DNS IPv6 Transport RECOMMENDED Guidelines
-
-   In order to preserve name space continuity, the following administrative
-   policies are RECOMMENDED:
-      - every recursive DNS server SHOULD be either IPv4-only or dual
-      stack,
-      - every single DNS zone SHOULD be served by at least one IPv4
-      reachable DNS server.
-
-   This rules out IPv6-only DNS servers performing full recursion and
-   DNS zones served only by IPv6-only DNS servers.  However, one could
-   very well design a configuration where a chain of IPv6 only DNS
-   servers forward queries to a set of dual stack DNS servers actually
-   performing those recursive queries.  This approach could be revisited
-   if/when translation techniques between IPv4 and IPv6 were to be
-   widely deployed.
-
-   In order to help enforcing the second point, the optional operational
-   zone validation processes SHOULD ensure that there is at least one
-   IPv4 address record available for the name servers of any child
-   delegations within the zone.
-
-
-5. Security Considerations
-
-   Being a critical piece of the Internet infrastructure, the DNS is a
-   potential value target and thus should be protected.  Great care
-   should be taken not to weaken the security of DNS while introducing
-   IPv6 operation.
-
-   Keeping the DNS name space from fragmenting is a critical thing for
-   the availability and the operation of the Internet; this memo
-   addresses this issue by clear and simple operational guidelines.
-
-   The RECOMMENDED guidelines are compatible with the operation of
-   DNSSEC and do not introduce any new security issues.
-
-
-6. Author Addresses
-
-   Alain Durand
-   SUN Microsystems, Inc
-   17 Network circle UMPK17-202
-   Menlo Park, CA, 94025
-   USA
-   Mail: Alain.Durand@sun.com
-
-   Johan Ihren
-   Autonomica
-   Bellmansgatan 30
-   SE-118 47 Stockholm, Sweden
-   Mail: johani@autonomica.se
-
-
-7. Normative References
-
-   [2119]  Bradner, S., "Key Words for Use in RFCs to Indicate
-           Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-
-8. Full Copyright Statement
-
-   "Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt
deleted file mode 100644
index 6bece56..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt
+++ /dev/null
@@ -1,389 +0,0 @@
-
-DNSOP                                                          G. Guette
-Internet-Draft                                             IRISA / INRIA
-Expires: July 19, 2005                                        O. Courtay
-                                                             Thomson R&D
-                                                        January 18, 2005
-
-           Requirements for Automated Key Rollover in DNSSEC
-           draft-ietf-dnsop-key-rollover-requirements-02.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, I certify that any applicable 
-   patent or other IPR claims of which I am aware have been disclosed, 
-   and any of which I become aware will be disclosed, in accordance with 
-   RFC 3668.  
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as
-   Internet-Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on July 19, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).  All Rights Reserved.
-
-Abstract
-
-   This document describes problems that appear during an automated
-   rollover and gives the requirements for the design of communication
-   between parent zone and child zone during an automated rollover
-   process.  This document is essentially about in-band key rollover.
-
-
-
-
-Guette & Courtay         Expires July 19, 2005                  [Page 1]
-Internet-Draft      Automated Rollover Requirements         January 2005
-
-Table of Contents
-
-   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
-   2.   The Key Rollover Process . . . . . . . . . . . . . . . . . . . 3
-   3.   Basic Requirements . . . . . . . . . . . . . . . . . . . . . . 4
-   4.   Messages authentication and information exchanged  . . . . . . 5
-   5.   Emergency Rollover . . . . . . . . . . . . . . . . . . . . . . 5
-   6.   Security consideration . . . . . . . . . . . . . . . . . . . . 6
-   7.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 6
-   8.   Normative References . . . . . . . . . . . . . . . . . . . . . 6
-        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
-   A.   Documents details and changes  . . . . . . . . . . . . . . . . 7
-        Intellectual Property and Copyright Statements . . . . . . . . 8
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Guette & Courtay         Expires July 19, 2005                  [Page 2]
-Internet-Draft      Automated Rollover Requirements         January 2005
-
-1.  Introduction
-
-   The DNS security extensions (DNSSEC) [4][6][5][7] uses public-key
-   cryptography and digital signatures.  It stores the public part of
-   keys in DNSKEY Resource Records (RRs).  Because old keys and
-   frequently used keys are vulnerable, they must be renewed
-   periodically.  In DNSSEC, this is the case for Zone Signing Keys
-   (ZSKs) and Key Signing Keys (KSKs) [1][2].  Automation of key
-   exchanges between parents and children is necessary for large zones
-   because there are too many changes to handle.
-
-   Let us consider for example a zone with 100000 secure delegations.
-   If the child zones change their keys once a year on average, that
-   implies 300 changes per day for the parent zone.  This amount of
-   changes is hard to manage manually.
-
-   Automated rollover is optional and resulting from an agreement
-   between the administrator of the parent zone and the administrator of
-   the child zone.  Of course, key rollover can also be done manually by
-   administrators.
-
-   This document describes the requirements for a protocol to perform
-   the automated key rollover process and focusses on interaction
-   between parent and child zone.
-
-2.  The Key Rollover Process
-
-   Key rollover consists of renewing the DNSSEC keys used to sign
-   resource records in a given DNS zone file.  There are two types of
-   rollover, ZSK rollovers and KSK rollovers.
-
-   During a ZSK rollover, all changes are local to the zone that renews
-   its key: there is no need to contact other zones administrators to
-   propagate the performed changes because a ZSK has no associated DS
-   record in the parent zone.
-
-   During a KSK rollover, new DS RR(s) must be created and stored in the
-   parent zone.  In consequence, data must be exchanged between child
-   and parent zones.
-
-   The key rollover is built from two parts of different nature:
-   o  An algorithm that generates new keys and signs the zone file.  It
-      can be local to the zone,
-   o  the interaction between parent and child zones.
-
-   One example of manual key rollover [3] is:
-   o  The child zone creates a new KSK,
-
-
-Guette & Courtay         Expires July 19, 2005                  [Page 3]
-Internet-Draft      Automated Rollover Requirements         January 2005
-
-   o  the child zone waits for the creation of the DS RR in its parent
-      zone,
-   o  the child zone deletes the old key,
-   o  the parent zone deletes the old DS RR.
-
-   This document concentrates on defining interactions between entities
-   present in key rollover process.
-
-3.  Basic Requirements
-
-   This section provides the requirements for automated key rollover in
-   case of normal use.  Exceptional case like emergency rollover is
-   specifically described later in this document.
-
-   The main condition during a key rollover is that the chain of trust
-   must be preserved to every validating DNS client.  No matter if this
-   client retrieves some of the RRs from recursive caching name server
-   or from the authoritative servers for the zone involved in the
-   rollover.
-
-   Automated key rollover solution may be interrupted by a manual
-   intervention.  This manual intervention should not compromise the
-   security state of the chain of trust.  If the chain is safe before
-   the manual intervention, the chain of trust must remain safe during
-   and after the manual intervention
-
-   Two entities act during a KSK rollover: the child zone and its parent
-   zone.  These zones are generally managed by different administrators.
-   These administrators should agree on some parameters like
-   availability of automated rollover, the maximum delay between
-   notification of changes in the child zone and the resigning of the
-   parent zone.  The child zone needs to know this delay to schedule its
-   changes and/or to verify that the changes had been taken into account
-   in the parent zone.  Hence, the child zone can also avoid some
-   critical cases where all child key are changed prior to the DS RR
-   creation.
-
-   By keeping some resource records during a given time, the recursive
-   cache servers can act on the automated rollover.  The existence of
-   recursive cache servers must be taken into account by automated
-   rollover solution.
-
-   Indeed, during an automated key rollover a name server could have to
-   retrieve some DNSSEC data.  An automated key rollover solution must
-   ensure that these data are not old DNSSEC material retrieved from a
-   recursive name server.
-
-
-
-Guette & Courtay         Expires July 19, 2005                  [Page 4]
-Internet-Draft      Automated Rollover Requirements         January 2005
-
-4.  Messages authentication and information exchanged
-
-   This section addresses in-band rollover, security of out-of-band
-   mechanisms is out of scope of this document.
-
-   The security provided by DNSSEC must not be compromised by the key
-   rollover, thus every exchanged message must be authenticated to avoid
-   fake rollover messages from malicious parties.
-
-   Once the changes related to a KSK are made in a child zone, there are
-   two ways for the parent zone to take this changes into account:
-   o  the child zone notify directly or not directly its parent zone in
-      order to create the new DS RR and store this DS RR in parent zone
-      file,
-   o  or the parent zone poll the child zone.
-
-   In both cases, the parent zone must receive all the child keys that
-   need the creation of associated DS RRs in the parent zone.
-
-   Because errors could occur during the transmission of keys between
-   child and parent, the key exchange protocol must be fault tolerant.
-   Should an error occured during the automated key rollover, an
-   automated key rollover solution must be able to keep the zone files
-   in a consistent state.
-
-5.  Emergency Rollover
-
-   Emergency key rollover is a special case of rollover decided by the
-   zone administrator generally for security reasons.  In consequence,
-   emergency key rollover can break some of the requirement described
-   above.
-
-   A zone key might be compromised and an attacker can use the
-   compromised key to create and sign fake records.  To avoid this, the
-   zone administrator may change the compromised key or all its keys as
-   soon as possible, without waiting for the creation of new DS RRs in
-   its parent zone.
-
-   Fast changes may break the chain of trust.  The part of DNS tree
-   having this zone as apex can become unverifiable, but the break of
-   the chain of trust is necessary if the administrator wants to prevent
-   the compromised key from being used (to spoof DNS data).
-
-   Parent and child zones sharing an automated rollover mechanism,
-   should have an out-of-band way to re-establish a consistent state at
-   the delegation point (DS and DNSKEY RRs).  This allows to avoid that
-   a malicious party uses the compromised key to roll the zone keys.
-
-
-Guette & Courtay         Expires July 19, 2005                  [Page 5]
-Internet-Draft      Automated Rollover Requirements         January 2005
-
-6.  Security consideration
-
-   The automated key rollover process in DNSSEC allows automated renewal
-   of any kind of DNS key (ZSK or KSK).  It is essential that parent
-   side and child side can do mutual authentication.  Moreover,
-   integrity of the material exchanged between the parent and child zone
-   must be provided to ensure the right DS are created.
-
-   As in any application using public key cryptography, in DNSSEC a key
-   may be compromised.  What to do in such a case can be describe in the
-   zone local policy and can violate some requirements described in this
-   draft.  The emergency rollover can break the chain of trust in order
-   to protect the zone against the use of the compromised key.
-
-7.  Acknowledgments
-
-   The authors want to thank members of IDsA project for their
-   contribution to this document.
-
-8  Normative References
-
-   [1]  Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
-        RFC 3658, December 2003.
-
-   [2]  Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY
-        (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag",
-        RFC 3757, May 2004.
-
-   [3]  Kolkman, O., "DNSSEC Operational Practices",
-        draft-ietf-dnsop-dnssec-operational-practice-01 (work in
-        progress), May 2004.
-
-   [4]  Eastlake, D., "Domain Name System Security Extensions", RFC
-        2535, March 1999.
-
-   [5]  Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
-        "Resource Records for the DNS Security Extensions",
-        draft-ietf-dnsext-dnssec-records-11 (work in progress), October
-        2004.
-
-   [6]  Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
-        "DNS Security Introduction and Requirements",
-        draft-ietf-dnsext-dnssec-intro-13 (work in progress), October
-        2004.
-
-   [7]  Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
-        "Protocol Modifications for the DNS Security Extensions",
-        draft-ietf-dnsext-dnssec-protocol-09 (work in progress), October
-
-
-Guette & Courtay         Expires July 19, 2005                  [Page 6]
-Internet-Draft      Automated Rollover Requirements         January 2005
-
-        2004.
-
-Authors' Addresses
-
-   Gilles Guette
-   IRISA / INRIA
-   Campus de Beaulieu
-   35042  Rennes CEDEX
-   FR
-
-   EMail: gilles.guette@irisa.fr
-   URI:   http://www.irisa.fr
-
-   Olivier Courtay
-   Thomson R&D
-   1, avenue Belle Fontaine
-   35510  Cesson S?vign? CEDEX
-   FR
-
-   EMail: olivier.courtay@thomson.net
-
-Appendix A.  Documents details and changes
-
-   This section is to be removed by the RFC editor if and when the
-   document is published.
-
-   Section about NS RR rollover has been removed
-
-   Remarks from Samuel Weiler and Rip Loomis added
-
-   Clarification about in-band rollover and in emergency section
-
-   Section 3, details about recursive cache servers added
-
-
-
-
-
-
-
-
-Guette & Courtay         Expires July 19, 2005                  [Page 7]
-Internet-Draft      Automated Rollover Requirements         January 2005
-
-Intellectual Property Statement
-
-     The IETF takes no position regarding the validity or scope of any 
-     intellectual property or other rights that might be claimed to 
-     pertain to the implementation or use of the technology described 
-     in this document or the extent to which any license under such 
-     rights might or might not be available; neither does it represent 
-     that it has made any effort to identify any such rights. 
-     Information on the IETF's procedures with respect to rights in 
-     IETF Documents can be found in BCP 78 and 79.   
-          
-     Copies of IPR disclosures made to the IETF Secretariat and any 
-     assurances of licenses to be made available, or the result of an 
-     attempt made to obtain a general license or permission for the use 
-     of such proprietary rights by implementers or users of this 
-     specification can be obtained from the IETF on-line IPR repository 
-     at http://www.ietf.org/ipr. 
-      
-     The IETF invites any interested party to bring to its attention 
-     any copyrights, patents or patent applications, or other 
-     proprietary rights which may cover technology that may be required 
-     to implement this standard. Please address the information to the 
-     IETF at ietf-ipr.org. 
-      
-    
- Full Copyright Statement 
-    
-   Copyright (C) The Internet Society (2005).  This document is subject 
-   to the rights, licenses and restrictions contained in BCP 78, and 
-   except as set forth therein, the authors retain all their rights. 
-    
-   This document and the information contained herein are provided on an 
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
- Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-         
-
-
-Guette & Courtay         Expires July 19, 2005                  [Page 8]
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-respsize-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-respsize-02.txt
deleted file mode 100644
index 63fe2de..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-respsize-02.txt
+++ /dev/null
@@ -1,480 +0,0 @@
-
-
-
-
-
-
-   DNSOP Working Group                                     Paul Vixie, ISC
-   INTERNET-DRAFT                                         Akira Kato, WIDE
-   <draft-ietf-dnsop-respsize-02.txt>                            July 2005
-
-                           DNS Response Size Issues
-
-   Status of this Memo
-      By submitting this Internet-Draft, each author represents that any
-      applicable patent or other IPR claims of which he or she is aware
-      have been or will be disclosed, and any of which he or she becomes
-      aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-      Internet-Drafts are working documents of the Internet Engineering
-      Task Force (IETF), its areas, and its working groups.  Note that
-      other groups may also distribute working documents as Internet-
-      Drafts.
-
-      Internet-Drafts are draft documents valid for a maximum of six months
-      and may be updated, replaced, or obsoleted by other documents at any
-      time.  It is inappropriate to use Internet-Drafts as reference
-      material or to cite them other than as "work in progress."
-
-      The list of current Internet-Drafts can be accessed at
-      http://www.ietf.org/ietf/1id-abstracts.txt
-
-      The list of Internet-Draft Shadow Directories can be accessed at
-      http://www.ietf.org/shadow.html.
-
-   Copyright Notice
-
-      Copyright (C) The Internet Society (2005).  All Rights Reserved.
-
-
-
-
-                                    Abstract
-
-      With a mandated default minimum maximum message size of 512 octets,
-      the DNS protocol presents some special problems for zones wishing to
-      expose a moderate or high number of authority servers (NS RRs).  This
-      document explains the operational issues caused by, or related to
-      this response size limit.
-
-
-
-
-
-
-   Expires December 2005                                           [Page 1]
-
-   INTERNET-DRAFT                  July 2005                       RESPSIZE
-
-
-   1 - Introduction and Overview
-
-   1.1. The DNS standard (see [RFC1035 4.2.1]) limits message size to 512
-   octets.  Even though this limitation was due to the required minimum UDP
-   reassembly limit for IPv4, it is a hard DNS protocol limit and is not
-   implicitly relaxed by changes in transport, for example to IPv6.
-
-   1.2. The EDNS0 standard (see [RFC2671 2.3, 4.5]) permits larger
-   responses by mutual agreement of the requestor and responder.  However,
-   deployment of EDNS0 cannot be expected to reach every Internet resolver
-   in the short or medium term.  The 512 octet message size limit remains
-   in practical effect at this time.
-
-   1.3. Since DNS responses include a copy of the request, the space
-   available for response data is somewhat less than the full 512 octets.
-   For negative responses, there is rarely a space constraint.  For
-   positive and delegation responses, though, every octet must be carefully
-   and sparingly allocated.  This document specifically addresses
-   delegation response sizes.
-
-   2 - Delegation Details
-
-   2.1. A delegation response will include the following elements:
-
-      Header Section: fixed length (12 octets)
-      Question Section: original query (name, class, type)
-      Answer Section: (empty)
-      Authority Section: NS RRset (nameserver names)
-      Additional Section: A and AAAA RRsets (nameserver addresses)
-
-   2.2. If the total response size would exceed 512 octets, and if the data
-   that would not fit belonged in the question, answer, or authority
-   section, then the TC bit will be set (indicating truncation) which may
-   cause the requestor to retry using TCP, depending on what information
-   was desired and what information was omitted.  If a retry using TCP is
-   needed, the total cost of the transaction is much higher.  (See [RFC1123
-   6.1.3.2] for details on the protocol requirement that UDP be attempted
-   before falling back to TCP.)
-
-   2.3. RRsets are never sent partially unless truncation occurs, in which
-   case the final apparent RRset in the final nonempty section must be
-   considered "possibly damaged".  With or without truncation, the glue
-   present in the additional data section should be considered "possibly
-   incomplete", and requestors should be prepared to re-query for any
-   damaged or missing RRsets.  For multi-transport name or mail services,
-
-
-
-   Expires December 2005                                           [Page 2]
-
-   INTERNET-DRAFT                  July 2005                       RESPSIZE
-
-
-   this can mean querying for an IPv6 (AAAA) RRset even when an IPv4 (A)
-   RRset is present.
-
-   2.4. DNS label compression allows a domain name to be instantiated only
-   once per DNS message, and then referenced with a two-octet "pointer"
-   from other locations in that same DNS message.  If all nameserver names
-   in a message are similar (for example, all ending in ".ROOT-
-   SERVERS.NET"), then more space will be available for uncompressable data
-   (such as nameserver addresses).
-
-   2.5. The query name can be as long as 255 characters of presentation
-   data, which can be up to 256 octets of network data.  In this worst case
-   scenario, the question section will be 260 octets in size, which would
-   leave only 240 octets for the authority and additional sections (after
-   deducting 12 octets for the fixed length header.)
-
-   2.6. Average and maximum question section sizes can be predicted by the
-   zone owner, since they will know what names actually exist, and can
-   measure which ones are queried for most often.  For cost and performance
-   reasons, the majority of requests should be satisfied without truncation
-   or TCP retry.
-
-   2.7. Requestors who deliberately send large queries to force truncation
-   are only increasing their own costs, and cannot effectively attack the
-   resources of an authority server since the requestor would have to retry
-   using TCP to complete the attack.  An attack that always used TCP would
-   have a lower cost.
-
-   2.8. The minimum useful number of address records is two, since with
-   only one address, the probability that it would refer to an unreachable
-   server is too high.  Truncation which occurs after two address records
-   have been added to the additional data section is therefore less
-   operationally significant than truncation which occurs earlier.
-
-   2.9. The best case is no truncation.  This is because many requestors
-   will retry using TCP by reflex, or will automatically re-query for
-   RRsets that are "possibly truncated", without considering whether the
-   omitted data was actually necessary.
-
-   2.10. Each added NS RR for a zone will add a minimum of between 16 and
-   44 octets to every untruncated referral or negative response from the
-   zone's authority servers (16 octets for an NS RR, 16 octets for an A RR,
-   and 28 octets for an AAAA RR), in addition to whatever space is taken by
-   the nameserver name (NS NSDNAME and A/AAAA owner name).
-
-
-
-
-   Expires December 2005                                           [Page 3]
-
-   INTERNET-DRAFT                  July 2005                       RESPSIZE
-
-
-   3 - Analysis
-
-   3.1. An instrumented protocol trace of a best case delegation response
-   follows.  Note that 13 servers are named, and 13 addresses are given.
-   This query was artificially designed to exactly reach the 512 octet
-   limit.
-
-      ;; flags: qr rd; QUERY: 1, ANS: 0, AUTH: 13, ADDIT: 13
-      ;; QUERY SECTION:
-      ;;  [23456789.123456789.123456789.\
-           123456789.123456789.123456789.com A IN]        ;; @80
-
-      ;; AUTHORITY SECTION:
-      com.                 86400 NS  E.GTLD-SERVERS.NET.  ;; @112
-      com.                 86400 NS  F.GTLD-SERVERS.NET.  ;; @128
-      com.                 86400 NS  G.GTLD-SERVERS.NET.  ;; @144
-      com.                 86400 NS  H.GTLD-SERVERS.NET.  ;; @160
-      com.                 86400 NS  I.GTLD-SERVERS.NET.  ;; @176
-      com.                 86400 NS  J.GTLD-SERVERS.NET.  ;; @192
-      com.                 86400 NS  K.GTLD-SERVERS.NET.  ;; @208
-      com.                 86400 NS  L.GTLD-SERVERS.NET.  ;; @224
-      com.                 86400 NS  M.GTLD-SERVERS.NET.  ;; @240
-      com.                 86400 NS  A.GTLD-SERVERS.NET.  ;; @256
-      com.                 86400 NS  B.GTLD-SERVERS.NET.  ;; @272
-      com.                 86400 NS  C.GTLD-SERVERS.NET.  ;; @288
-      com.                 86400 NS  D.GTLD-SERVERS.NET.  ;; @304
-
-      ;; ADDITIONAL SECTION:
-      A.GTLD-SERVERS.NET.  86400 A   192.5.6.30           ;; @320
-      B.GTLD-SERVERS.NET.  86400 A   192.33.14.30         ;; @336
-      C.GTLD-SERVERS.NET.  86400 A   192.26.92.30         ;; @352
-      D.GTLD-SERVERS.NET.  86400 A   192.31.80.30         ;; @368
-      E.GTLD-SERVERS.NET.  86400 A   192.12.94.30         ;; @384
-      F.GTLD-SERVERS.NET.  86400 A   192.35.51.30         ;; @400
-      G.GTLD-SERVERS.NET.  86400 A   192.42.93.30         ;; @416
-      H.GTLD-SERVERS.NET.  86400 A   192.54.112.30        ;; @432
-      I.GTLD-SERVERS.NET.  86400 A   192.43.172.30        ;; @448
-      J.GTLD-SERVERS.NET.  86400 A   192.48.79.30         ;; @464
-      K.GTLD-SERVERS.NET.  86400 A   192.52.178.30        ;; @480
-      L.GTLD-SERVERS.NET.  86400 A   192.41.162.30        ;; @496
-      M.GTLD-SERVERS.NET.  86400 A   192.55.83.30         ;; @512
-
-      ;; MSG SIZE  sent: 80  rcvd: 512
-
-
-
-
-
-   Expires December 2005                                           [Page 4]
-
-   INTERNET-DRAFT                  July 2005                       RESPSIZE
-
-
-   3.2. For longer query names, the number of address records supplied will
-   be lower.  Furthermore, it is only by using a common parent name (which
-   is GTLD-SERVERS.NET in this example) that all 13 addresses are able to
-   fit.  The following output from a response simulator demonstrates these
-   properties:
-
-      % perl respsize.pl a.dns.br b.dns.br c.dns.br d.dns.br
-      a.dns.br requires 10 bytes
-      b.dns.br requires 4 bytes
-      c.dns.br requires 4 bytes
-      d.dns.br requires 4 bytes
-      # of NS: 4
-      For maximum size query (255 byte):
-              if only A is considered:     # of A is 4 (green)
-              if A and AAAA are condered:  # of A+AAAA is 3 (yellow)
-              if prefer_glue A is assumed: # of A is 4, # of AAAA is 3 (yellow)
-      For average size query (64 byte):
-              if only A is considered:     # of A is 4 (green)
-              if A and AAAA are condered:  # of A+AAAA is 4 (green)
-              if prefer_glue A is assumed: # of A is 4, # of AAAA is 4 (green)
-
-      % perl respsize.pl ns-ext.isc.org ns.psg.com ns.ripe.net ns.eu.int
-      ns-ext.isc.org requires 16 bytes
-      ns.psg.com requires 12 bytes
-      ns.ripe.net requires 13 bytes
-      ns.eu.int requires 11 bytes
-      # of NS: 4
-      For maximum size query (255 byte):
-              if only A is considered:     # of A is 4 (green)
-              if A and AAAA are condered:  # of A+AAAA is 3 (yellow)
-              if prefer_glue A is assumed: # of A is 4, # of AAAA is 2 (yellow)
-      For average size query (64 byte):
-              if only A is considered:     # of A is 4 (green)
-              if A and AAAA are condered:  # of A+AAAA is 4 (green)
-              if prefer_glue A is assumed: # of A is 4, # of AAAA is 4 (green)
-
-   (Note: The response simulator program is shown in Section 5.)
-
-   Here we use the term "green" if all address records could fit, or
-   "orange" if two or more could fit, or "red" if fewer than two could fit.
-   It's clear that without a common parent for nameserver names, much space
-   would be lost.  For these examples we use an average/common name size of
-   15 octets, befitting our assumption of GTLD-SERVERS.NET as our common
-   parent name.
-
-
-
-
-   Expires December 2005                                           [Page 5]
-
-   INTERNET-DRAFT                  July 2005                       RESPSIZE
-
-
-   We're assuming an average query name size of 64 since that is the
-   typical average maximum size seen in trace data at the time of this
-   writing.  If Internationalized Domain Name (IDN) or any other technology
-   which results in larger query names be deployed significantly in advance
-   of EDNS, then new measurements and new estimates will have to be made.
-
-   4 - Conclusions
-
-   4.1. The current practice of giving all nameserver names a common parent
-   (such as GTLD-SERVERS.NET or ROOT-SERVERS.NET) saves space in DNS
-   responses and allows for more nameservers to be enumerated than would
-   otherwise be possible.  (Note that in this case it is wise to serve the
-   common parent domain's zone from the same servers that are named within
-   it, in order to limit external dependencies when all your eggs are in a
-   single basket.)
-
-   4.2. Thirteen (13) seems to be the effective maximum number of
-   nameserver names usable traditional (non-extended) DNS, assuming a
-   common parent domain name, and given that response truncation is
-   undesirable as an average case, and assuming mostly IPv4-only
-   reachability (only A RRs exist, not AAAA RRs).
-
-   4.3. Adding two to five IPv6 nameserver address records (AAAA RRs) to a
-   prototypical delegation that currently contains thirteen (13) IPv4
-   nameserver addresses (A RRs) for thirteen (13) nameserver names under a
-   common parent, would not have a significant negative operational impact
-   on the domain name system.
-
-   5 - Source Code
-
-   #!/usr/bin/perl
-   #
-   # SYNOPSIS
-   #    repsize.pl [ -z zone ] fqdn_ns1 fqdn_ns2 ...
-   #        if all queries are assumed to have zone suffux, such as "jp" in
-   #     JP TLD servers, specify it in -z option
-   #
-   use strict;
-   use Getopt::Std;
-   my ($sz_msg) = (512);
-   my ($sz_header, $sz_ptr, $sz_rr_a, $sz_rr_aaaa) = (12, 2, 16, 28);
-   my ($sz_type, $sz_class, $sz_ttl, $sz_rdlen) = (2, 2, 4, 2);
-   my (%namedb, $name, $nssect, %opts, $optz);
-   my $n_ns = 0;
-
-
-
-
-   Expires December 2005                                           [Page 6]
-
-   INTERNET-DRAFT                  July 2005                       RESPSIZE
-
-
-   getopt('z', opts);
-   if (defined($opts{'z'})) {
-        server_name_len($opts{'z'}); # just register it
-   }
-
-   foreach $name (@ARGV) {
-        my $len;
-        $n_ns++;
-        $len = server_name_len($name);
-           print "$name requires $len bytes\n";
-        $nssect += $sz_ptr + $sz_type + $sz_class + $sz_ttl + $sz_rdlen + $len;
-   }
-   print "# of NS: $n_ns\n";
-   arsect(255, $nssect, $n_ns, "maximum");
-   arsect(64, $nssect, $n_ns, "average");
-
-   sub server_name_len {
-       my ($name) = @_;
-       my (@labels, $len, $n, $suffix);
-
-       $name =~ tr/A-Z/a-z/;
-       @labels = split(/./, $name);
-       $len = length(join('.', @labels)) + 2;
-       for ($n = 0; $#labels >= 0; $n++, shift @labels) {
-           $suffix = join('.', @labels);
-           return length($name) - length($suffix) + $sz_ptr
-               if (defined($namedb{$suffix}));
-           $namedb{$suffix} = 1;
-       }
-       return $len;
-   }
-
-   sub arsect {
-       my ($sz_query, $nssect, $n_ns, $cond) = @_;
-       my ($space, $n_a, $n_a_aaaa, $n_p_aaaa, $ansect);
-       $ansect = $sz_query + 1 + $sz_type + $sz_class;
-       $space = $sz_msg - $sz_header - $ansect - $nssect;
-       $n_a = atmost(int($space / $sz_rr_a), $n_ns);
-       $n_a_aaaa = atmost(int($space / ($sz_rr_a + $sz_rr_aaaa)), $n_ns);
-       $n_p_aaaa = atmost(int(($space - $sz_rr_a * $n_ns) / $sz_rr_aaaa), $n_ns);
-       printf "For %s size query (%d byte):\n", $cond, $sz_query;
-       printf "if only A is considered:     ";
-       printf "# of A is %d (%s)\n", $n_a, &judge($n_a, $n_ns);
-       printf "if A and AAAA are condered:  ";
-       printf "# of A+AAAA is %d (%s)\n", $n_a_aaaa, &judge($n_a_aaaa, $n_ns);
-
-
-
-   Expires December 2005                                           [Page 7]
-
-   INTERNET-DRAFT                  July 2005                       RESPSIZE
-
-
-       printf "if prefer_glue A is assumed: ";
-       printf "# of A is %d, # of AAAA is %d (%s)\n",
-           $n_a, $n_p_aaaa, &judge($n_p_aaaa, $n_ns);
-   }
-
-   sub judge {
-       my ($n, $n_ns) = @_;
-       return "green" if ($n >= $n_ns);
-       return "yellow" if ($n >= 2);
-       return "orange" if ($n == 1);
-       return "red";
-   }
-
-   sub atmost {
-       my ($a, $b) = @_;
-       return 0 if ($a < 0);
-       return $b if ($a > $b);
-       return $a;
-   }
-
-   Security Considerations
-
-   The recommendations contained in this document have no known security
-   implications.
-
-   IANA Considerations
-
-   This document does not call for changes or additions to any IANA
-   registry.
-
-   IPR Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject to
-   the rights, licenses and restrictions contained in BCP 78, and except as
-   set forth therein, the authors retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
-   IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-   Expires December 2005                                           [Page 8]
-
-   INTERNET-DRAFT                  July 2005                       RESPSIZE
-
-
-   Authors' Addresses
-
-   Paul Vixie
-      950 Charter Street
-      Redwood City, CA 94063
-      +1 650 423 1301
-      vixie@isc.org
-
-   Akira Kato
-      University of Tokyo, Information Technology Center
-      2-11-16 Yayoi Bunkyo
-      Tokyo 113-8658, JAPAN
-      +81 3 5841 2750
-      kato@wide.ad.jp
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-   Expires December 2005                                           [Page 9]
-
\ No newline at end of file
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-06.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-06.txt
deleted file mode 100644
index c6ec7e4..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-06.txt
+++ /dev/null
@@ -1,618 +0,0 @@
-
-
-
-
-Network Working Group                                           S. Woolf
-Internet-Draft                         Internet Systems Consortium, Inc.
-Expires: September 6, 2006                                     D. Conrad
-                                                           Nominum, Inc.
-                                                           March 5, 2006
-
-
-    Requirements for a Mechanism Identifying a Name Server Instance
-                      draft-ietf-dnsop-serverid-06
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on September 6, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   With the increased use of DNS anycast, load balancing, and other
-   mechanisms allowing more than one DNS name server to share a single
-   IP address, it is sometimes difficult to tell which of a pool of name
-   servers has answered a particular query.  A standardized mechanism to
-   determine the identity of a name server responding to a particular
-   query would be useful, particularly as a diagnostic aid for
-   administrators.  Existing ad hoc mechanisms for addressing this need
-
-
-
-Woolf & Conrad          Expires September 6, 2006               [Page 1]
-
-Internet-Draft                  Serverid                      March 2006
-
-
-   have some shortcomings, not the least of which is the lack of prior
-   analysis of exactly how such a mechanism should be designed and
-   deployed.  This document describes the existing convention used in
-   some widely deployed implementations of the DNS protocol, including
-   advantages and disadvantages, and discusses some attributes of an
-   improved mechanism.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad          Expires September 6, 2006               [Page 2]
-
-Internet-Draft                  Serverid                      March 2006
-
-
-1.  Introduction and Rationale
-
-   Identifying which name server is responding to queries is often
-   useful, particularly in attempting to diagnose name server
-   difficulties.  This is most obviously useful for authoritative
-   nameservers in the attempt to diagnose the source or prevalence of
-   inaccurate data, but can also conceivably be useful for caching
-   resolvers in similar and other situations.  Furthermore, the ability
-   to identify which server is responding to a query has become more
-   useful as DNS has become more critical to more Internet users, and as
-   network and server deployment topologies have become more complex.
-
-   The traditional means for determining which of several possible
-   servers is answering a query has traditionally been based on the use
-   of the server's IP address as a unique identifier.  However, the
-   modern Internet has seen the deployment of various load balancing,
-   fault-tolerance, or attack-resistance schemes such as shared use of
-   unicast IP addresses as documented in [RFC3258].  An unfortunate side
-   effect of these schemes has been to make the use of IP addresses as
-   identifiers somewhat problematic.  Specifically, a dedicated DNS
-   query may not go to the same server as answered a previous query,
-   even though sent to the same IP address.  Non-DNS methods such as
-   ICMP ping, TCP connections, or non-DNS UDP packets (such as those
-   generated by tools like "traceroute"), etc., may well be even less
-   certain to reach the same server as the one which receives the DNS
-   queries.
-
-   There is a well-known and frequently-used technique for determining
-   an identity for a nameserver more specific than the possibly-non-
-   unique "server that answered the query I sent to IP address XXX".
-   The widespread use of the existing convention suggests a need for a
-   documented, interoperable means of querying the identity of a
-   nameserver that may be part of an anycast or load-balancing cluster.
-   At the same time, however, it also has some drawbacks that argue
-   against standardizing it as it's been practiced so far.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad          Expires September 6, 2006               [Page 3]
-
-Internet-Draft                  Serverid                      March 2006
-
-
-2.  Existing Conventions
-
-   For some time, the commonly deployed Berkeley Internet Name Domain
-   implementation of the DNS protocol suite from the Internet Systems
-   Consortium [BIND] has supported a way of identifying a particular
-   server via the use of a standards-compliant, if somewhat unusual, DNS
-   query.  Specifically, a query to a recent BIND server for a TXT
-   resource record in class 3 (CHAOS) for the domain name
-   "HOSTNAME.BIND." will return a string that can be configured by the
-   name server administrator to provide a unique identifier for the
-   responding server.  (The value defaults to the result of a
-   gethostname() call).  This mechanism, which is an extension of the
-   BIND convention of using CHAOS class TXT RR queries to sub-domains of
-   the "BIND." domain for version information, has been copied by
-   several name server vendors.
-
-   A refinement to the BIND-based mechanism, which dropped the
-   implementation-specific string, replaces ".BIND" with ".SERVER".
-   Thus the query string to learn the unique name of a server may be
-   queried as "ID.SERVER".
-
-   (For reference, the other well-known name used by recent versions of
-   BIND within the CHAOS class "BIND." domain is "VERSION.BIND."  A
-   query for a CHAOS TXT RR for this name will return an
-   administratively defined string which defaults to the version of the
-   server responding.  This is, however, not generally implemented by
-   other vendors.)
-
-2.1.  Advantages
-
-   There are several valuable attributes to this mechanism, which
-   account for its usefulness.
-
-   1.  The "HOSTNAME.BIND" or "ID.SERVER" query response mechanism is
-       within the DNS protocol itself.  An identification mechanism that
-       relies on the DNS protocol is more likely to be successful
-       (although not guaranteed) in going to the same system as a
-       "normal" DNS query.
-
-   2.  Since the identity information is requested and returned within
-       the DNS protocol, it doesn't require allowing any other query
-       mechanism to the server, such as holes in firewalls for
-       otherwise-unallowed ICMP Echo requests.  Thus it is likely to
-       reach the same server over a path subject to the same routing,
-       resource, and security policy as the query, without any special
-       exceptions to site security policy.
-
-
-
-
-
-Woolf & Conrad          Expires September 6, 2006               [Page 4]
-
-Internet-Draft                  Serverid                      March 2006
-
-
-   3.  It is simple to configure.  An administrator can easily turn on
-       this feature and control the results of the relevant query.
-
-   4.  It allows the administrator complete control of what information
-       is given out in the response, minimizing passive leakage of
-       implementation or configuration details.  Such details are often
-       considered sensitive by infrastructure operators.
-
-   5.  Hypothetically, since it's an ordinary DNS record and the
-       relevant DNSSEC RRs are class independent, the id.server response
-       RR could be signed, which has the advantages described in
-       [RFC4033].
-
-2.2.  Disadvantages
-
-   At the same time, there are some serious drawbacks to the CHAOS/TXT
-   query mechanism that argue against standardizing it as it currently
-   operates.
-
-   1.  It requires an additional query to correlate between the answer
-       to a DNS query under normal conditions and the supposed identity
-       of the server receiving the query.  There are a number of
-       situations in which this simply isn't reliable.
-
-   2.  It reserves an entire class in the DNS (CHAOS) for what amounts
-       to one zone.  While CHAOS class is defined in [RFC1034] and
-       [RFC1035], it's not clear that supporting it solely for this
-       purpose is a good use of the namespace or of implementation
-       effort.
-
-   3.  The initial and still common form, using .BIND, is implementation
-       specific.  BIND is one DNS implementation.  At the time of this
-       writing, it is probably the most prevalent for authoritative
-       servers.  This does not justify standardizing on its ad hoc
-       solution to a problem shared across many operators and
-       implementors.  Meanwhile, the proposed refinement changes the
-       string but preserves the ad hoc CHAOS/TXT mechanism.
-
-   4.  There is no convention or shared understanding of what
-       information an answer to such a query for a server identity could
-       or should include, including a possible encoding or
-       authentication mechanism.
-
-   The first of the listed disadvantages may be technically the most
-   serious.  It argues for an attempt to design a good answer to the
-   problem that "I need to know what nameserver is answering my
-   queries", not simply a convenient one.
-
-
-
-
-Woolf & Conrad          Expires September 6, 2006               [Page 5]
-
-Internet-Draft                  Serverid                      March 2006
-
-
-2.3.  Characteristics of an Implementation Neutral Convention
-
-   The discussion above of advantages and disadvantages to the
-   HOSTNAME.BIND mechanism suggest some requirements for a better
-   solution to the server identification problem.  These are summarized
-   here as guidelines for any effort to provide appropriate protocol
-   extensions:
-
-   1.  The mechanism adopted must be in-band for the DNS protocol.  That
-       is, it needs to allow the query for the server's identifying
-       information to be part of a normal, operational query.  It should
-       also permit a separate, dedicated query for the server's
-       identifying information.  But it should preserve the ability of
-       the CHAOS/TXT query-based mechanism to work through firewalls and
-       in other situations where only DNS can be relied upon to reach
-       the server of interest.
-
-   2.  The new mechanism should not require dedicated namespaces or
-       other reserved values outside of the existing protocol mechanisms
-       for these, i.e. the OPT pseudo-RR.  In particular, it should not
-       propagate the existing drawback of requiring support for a CLASS
-       and top level domain in the authoritative server (or the querying
-       tool) to be useful.
-
-   3.  Support for the identification functionality should be easy to
-       implement and easy to enable.  It must be easy to disable and
-       should lend itself to access controls on who can query for it.
-
-   4.  It should be possible to return a unique identifier for a server
-       without requiring the exposure of information that may be non-
-       public and considered sensitive by the operator, such as a
-       hostname or unicast IP address maintained for administrative
-       purposes.
-
-   5.  It should be possible to authenticate the received data by some
-       mechanism analogous to those provided by DNSSEC.  In this
-       context, the need could be met by including encryption options in
-       the specification of a new mechanism.
-
-   6.  The identification mechanism should not be implementation-
-       specific.
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad          Expires September 6, 2006               [Page 6]
-
-Internet-Draft                  Serverid                      March 2006
-
-
-3.  IANA Considerations
-
-   This document proposes no specific IANA action.  Protocol extensions,
-   if any, to meet the requirements described are out of scope for this
-   document.  A proposed extension, specified and adopted by normal IETF
-   process, is described in [NSID], including relevant IANA action.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad          Expires September 6, 2006               [Page 7]
-
-Internet-Draft                  Serverid                      March 2006
-
-
-4.  Security Considerations
-
-   Providing identifying information as to which server is responding to
-   a particular query from a particular location in the Internet can be
-   seen as information leakage and thus a security risk.  This motivates
-   the suggestion above that a new mechanism for server identification
-   allow the administrator to disable the functionality altogether or
-   partially restrict availability of the data.  It also suggests that
-   the serverid data should not be readily correlated with a hostname or
-   unicast IP address that may be considered private to the nameserver
-   operator's management infrastructure.
-
-   Propagation of protocol or service meta-data can sometimes expose the
-   application to denial of service or other attack.  As DNS is a
-   critically important infrastructure service for the production
-   Internet, extra care needs to be taken against this risk for
-   designers, implementors, and operators of a new mechanism for server
-   identification.
-
-   Both authentication and confidentiality of serverid data are
-   potentially of interest to administrators-- that is, operators may
-   wish to make serverid data available and reliable to themselves and
-   their chosen associates only.  This would imply both an ability to
-   authenticate it to themselves and keep it private from arbitrary
-   other parties.  This led to Characteristics 4 and 5 of an improved
-   solution.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad          Expires September 6, 2006               [Page 8]
-
-Internet-Draft                  Serverid                      March 2006
-
-
-5.  Acknowledgements
-
-   The technique for host identification documented here was initially
-   implemented by Paul Vixie of the Internet Software Consortium in the
-   Berkeley Internet Name Daemon package.  Comments and questions on
-   earlier drafts were provided by Bob Halley, Brian Wellington, Andreas
-   Gustafsson, Ted Hardie, Chris Yarnell, Randy Bush, and members of the
-   ICANN Root Server System Advisory Committee.  The newest version
-   takes a significantly different direction from previous versions,
-   owing to discussion among contributors to the DNSOP working group and
-   others, particularly Olafur Gudmundsson, Ed Lewis, Bill Manning, Sam
-   Weiler, and Rob Austein.
-
-6.  References
-
-   [1]  Mockapetris, P., "Domain Names - Concepts and Facilities",
-        RFC 1034, STD 0013, November 1987.
-
-   [2]  Mockapetris, P., "Domain Names - Implementation and
-        Specification", RFC 1035, STD 0013, November 1987.
-
-   [3]  Hardie, T., "Distributing Authoritative Name Servers via Shared
-        Unicast Addresses", RFC 3258, April 2002.
-
-   [4]  ISC, "BIND 9 Configuration Reference".
-
-   [5]  Austein, S., "DNS Name Server Identifier Option (NSID)",
-        Internet Drafts http://www.ietf.org/internet-drafts/
-        draft-ietf-dnsext-nsid-01.txt, January 2006.
-
-   [6]  Arends, R., Austein, S., Larson, M., Massey, D., and S. Rose,
-        "DNS Security Introduction and Requirements", RFC 4033,
-        March 2005.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad          Expires September 6, 2006               [Page 9]
-
-Internet-Draft                  Serverid                      March 2006
-
-
-Authors' Addresses
-
-   Suzanne Woolf
-   Internet Systems Consortium, Inc.
-   950 Charter Street
-   Redwood City, CA  94063
-   US
-
-   Phone: +1 650 423-1333
-   Email: woolf@isc.org
-   URI:   http://www.isc.org/
-
-
-   David Conrad
-   Nominum, Inc.
-   2385 Bay Road
-   Redwood City, CA  94063
-   US
-
-   Phone: +1 1 650 381 6003
-   Email: david.conrad@nominum.com
-   URI:   http://www.nominum.com/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad          Expires September 6, 2006              [Page 10]
-
-Internet-Draft                  Serverid                      March 2006
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Woolf & Conrad          Expires September 6, 2006              [Page 11]
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt b/contrib/bind9/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt
deleted file mode 100644
index 3353b3b..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt
+++ /dev/null
@@ -1,1588 +0,0 @@
-
-                                                            Mark Foster 
-Internet Draft                                              Tom McGarry 
-Document: <draft-ietf-enum-e164-gstn-np-05.txt>                James Yu 
-                                                          NeuStar, Inc. 
-Category: Informational                                   June 24, 2002 
- 
- 
-              Number Portability in the GSTN: An Overview 
- 
- 
-Status of this Memo 
- 
-   This document is an Internet-Draft and is in full conformance with 
-   all provisions of Section 10 of RFC2026 [RFC].  
- 
-   Internet-Drafts are working documents of the Internet Engineering 
-   Task Force (IETF), its areas, and its working groups. Note that 
-   other groups may also distribute working documents as Internet-
-   Drafts. Internet-Drafts are draft documents valid for a maximum of 
-   six months and may be updated, replaced, or obsoleted by other 
-   documents at any time. It is inappropriate to use Internet- Drafts 
-   as reference material or to cite them other than as "work in 
-   progress."  
-    
-   The list of current Internet-Drafts can be accessed at 
-   http://www.ietf.org/ietf/1id-abstracts.txt. 
-     
-   The list of Internet-Draft Shadow Directories can be accessed at 
-   http://www.ietf.org/shadow.html. 
-    
- 
-   Copyright Notice 
- 
-      Copyright (C) The Internet Society (2002).  All rights reserved. 
-    
-    
-   Abstract 
-    
-   This document provides an overview of E.164 telephone number 
-   portability (NP) in the Global Switched Telephone Network (GSTN).    
-   NP is a regulatory imperative seeking to liberalize local telephony 
-   service competition, by enabling end-users to retain telephone 
-   numbers while changing service providers.  NP changes the 
-   fundamental nature of a dialed E.164 number from a hierarchical 
-   physical routing address to a virtual address, thereby requiring the 
-   transparent translation of the later to the former.  In addition, 
-   there are various regulatory constraints that establish relevant 
-   parameters for NP implementation, most of which are not network 
-   technology specific.  Consequently, the implementation of NP 
-   behavior consistent with applicable regulatory constraints, as well 
-   as the need for interoperation with the existing GSTN NP 
-   implementations, are relevant topics for numerous areas of IP 
-   telephony work-in-progress at IETF. 
-  
-Foster,McGarry,Yu         Expired on December 23, 2002        [Page 1] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-    
-   Table of Contents 
-    
-    1.  Introduction ...............................................  2 
-    2.  Abbreviations and Acronyms .................................  4 
-    3.  Types of Number Portability ................................  5 
-    4.  Service Provider Number Portability Schemes ................  7 
-       4.1   All Call Query (ACQ) ..................................  7 
-       4.2   Query on Release (QoR) ................................  8 
-       4.3   Call Dropback .........................................  9 
-       4.4   Onward Routing (OR) ...................................  9 
-       4.5   Comparisons of the Four Schemes ....................... 10 
-    5.  Database Queries in the NP Environment ..................... 11 
-       5.1   U.S. and Canada ....................................... 12 
-       5.2   Europe ................................................ 13 
-    6.  Call Routing in the NP Environment ......................... 14 
-       6.1   U.S. and Canada ....................................... 14 
-       6.2   Europe ................................................ 15 
-    7.  NP Implementations for Geographic E.164 Numbers ............ 17 
-    8.  Number Conservation Method Enabled By NP ................... 20 
-       8.1   Block Pooling ......................................... 20 
-       8.2   ITN Pooling ........................................... 21 
-    9.  Potential Implications ..................................... 21 
-   10.  Security Considerations .................................... 24 
-   11.  IANA Considerations ........................................ 24 
-   12.  Normative References ....................................... 24 
-   13.  Informative References ..................................... 25 
-   14.  Acknowledgement ............................................ 25 
-   15.  AuthorsË Addresses ......................................... 25 
-    
- 
-    
-1. Introduction 
-    
-   This document provides an overview of E.164 telephone number 
-   portability in the Global Switched Telephone Network (GSTN).  There 
-   are considered to be three types of number portability (NP): service 
-   provider portability (SPNP), location portability (not to be 
-   confused with terminal mobility), and service portability. 
-    
-   Service provider portability (SPNP), the focus of the present draft, 
-   is a regulatory imperative in many countries seeking to liberalize 
-   telephony service competition, especially local service.  
-   Historically, local telephony service (as compared to long distance 
-   or international service) has been regulated as a utility-like form 
-   of service.  While a number of countries had begun liberalization 
-   (e.g. privatization, de-regulation, or re-regulation) some years 
-   ago, the advent of NP is relatively recent (since ~1995). 
-    
-   E.164 numbers can be non-geographic and geographic numbers.  Non-
-   geographic numbers do not reveal the locations information of those 
-   numbers.  Geographic E.164 numbers were intentionally designed as 
-   hierarchical routing addresses which could systematically be digit-
-   analyzed to ascertain the country, serving network provider, serving 
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 2] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   end-office switch, and specific line of the called party.  As such, 
-   without NP a subscriber wishing to change service providers would 
-   incur a number change as a consequence of being served off of a 
-   different end-office switch operated by the new service provider.  
-   The cost and convenience impact to the subscriber of changing 
-   numbers is seen as barrier to competition.  Hence NP has become 
-   associated with GSTN infrastructure enhancements associated with a 
-   competitive environment driven by regulatory directives. 
-    
-   Forms of SPNP have been deployed or are being deployed widely in the 
-   GSTN in various parts of the world, including the U.S., Canada, 
-   Western Europe, Australia, and the Pacific Rim (e.g. Hong Kong). 
-   Other regions, such as South America (e.g. Brazil) are actively 
-   considering it. 
-    
-   Implementation of NP within a national telephony infrastructure 
-   entails potentially significant changes to numbering administration, 
-   network element signaling, call routing and processing, billing, 
-   service management, and other functions. 
-    
-   NP changes the fundamental nature of a dialed E.164 number from a 
-   hierarchical physical routing address to a virtual address.  NP 
-   implementations attempt to encapsulate the impacts to the GSTN and 
-   make NP transparent to subscribers by incorporating a translation 
-   function to map a dialed, potentially ported E.164 address, into a 
-   network routing address (either a number prefix or another E.164 
-   address) which can be hierarchically routed. 
-    
-   This is roughly analogous to the use of network address translation 
-   on IP addresses to enable IP address portability by containing the 
-   impact of the address change to the edge of the network and retain 
-   the use of CIDR blocks in the core which can be route aggregated by 
-   the network service provider to the rest of the internet. 
-    
-   NP bifurcates the historical role of a subscriberËs E.164 address 
-   into two or more data elements (a dialed or virtual address, and a 
-   network routing address) that must be made available to network 
-   elements through an NP translations database, carried by forward 
-   call signaling, and recorded on call detail records.  Not only is 
-   call processing and routing affected, but also so is SS7/C7 
-   messaging.  A number of TCAP-based SS7 messaging sets utilize an 
-   E.164 address as an application-level network element address in the 
-   global title address (GTA) field of the SCCP message header.  
-   Consequently, SS7/C7 signaling transfer points (STPs) and gateways 
-   need to be able to perform n-digit global title translation (GTT) to 
-   translate a dialed E.164 address into its network address 
-   counterpart via the NP database. 
-    
-   In addition, there are various national regulatory constraints that 
-   establish relevant parameters for NP implementation, most of which 
-   are not network technology specific.  Consequently, implementations 
-   of NP behavior in IP telephony consistent with applicable regulatory 
-   constraints, as well as the need for interoperation with the 
-
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 3] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   existing GSTN NP implementations, are relevant topics for numerous 
-   areas of IP telephony work-in-progress at IETF. 
-    
-   This document describes three types of number portability and the 
-   four schemes that have been standardized to support SPNP for 
-   geographic E.164 numbersspecifically.  Following that, specific 
-   information regarding the call routing and database query 
-   implementations are described for several regions (North American 
-   and Europe) and industries (wireless vs. wireline). The Number 
-   Portability Database (NPDB) interfaces and the call routing schemes 
-   that are used in the North America and Europe are described to show 
-   the variety of standards that may be implemented worldwide.  A 
-   glance of the NP implementations worldwide is provided.  Number 
-   pooling is briefly discussed to show how NP is being enhanced in the 
-   U.S. to conserve North American area codes.  The conclusion briefly 
-   touches the potential impacts of NP on IP & Telecommunications 
-   Interoperability.  Appendix A provides some specific technical and 
-   regulatory information on NP in North America.  Appendix B describes 
-   the number portability administration process that manages the 
-   number portability database in North America. 
-    
-    
-2. Abbreviations and Acronyms 
-    
-   ACQ     All Call Query 
-   AIN     Advanced Intelligent Network 
-   AMPS    Advanced Mobile Phone System 
-   ANSI    American National Standards Institute 
-   CDMA    Code Division Multiple Access 
-   CdPA    Called Party Address 
-   CdPN    Called Party Number 
-   CH      Code Holder 
-   CMIP    Common Management Information Protocol 
-   CS1     Capability Set 1 
-   CS2     Capability Set 2 
-   DN      Directory Number 
-   DNS     Domain Name System 
-   ETSI    European Technical Standards Institute 
-   FCI     Forward Call Indicator 
-   GAP     Generic Address Parameter 
-   GMSC    Gateway Mobile Services Switching Center or Gateway Mobile 
-           Switching Center 
-   GSM     Global System for Mobile Communications 
-   GSTN    Global Switched Telephone Network 
-   GW      Gateways 
-   HLR     Home Location Register 
-   IAM     Initial Address Message 
-   IETF    Internet Engineering Task Force 
-   ILNP    Interim LNP 
-   IN      Intelligent Network 
-   INAP    Intelligent Network Application Part 
-   INP     Interim NP     
-   IP      Internet Protocol 
-   IS-41   Interim Standards Number 41 
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 4] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   ISDN    Integrated Services Digital Network 
-   ISUP    ISDN User Part 
-   ITN     Individual Telephony Number  
-   ITU     International Telecommunication Union 
-   ITU-TS  ITU-Telecommunication Sector 
-   LDAP    Lightweight Directory Access Protocol  
-   LEC     Local Exchange Carrier 
-   LERG    Local Exchange Routing Guide 
-   LNP     Local Number Portability 
-   LRN     Location Routing Number 
-   MAP     Mobile Application Part 
-   MNP     Mobile Number Portability 
-   MSRN    Mobile Station Roaming Number 
-   MTP     Message Transfer Part 
-   NANP    North American Numbering Plan 
-   NP      Number Portability 
-   NPDB    Number Portability Database 
-   NRN     Network Routing Number 
-   OR      Onward Routing 
-   OSS     Operation Support System 
-   PCS     Personal Communication Services 
-   PNTI    Ported Number Translation Indicator 
-   PODP    Public Office Dialing Plan 
-   PUC     Public Utility Commission 
-   QoR     Query on Release 
-   RN      Routing Number 
-   RTP     Return to Pivot 
-   SCCP    Signaling Connection Control Part 
-   SCP     Service Control Point  
-   SIP     Session Initiation Protocol 
-   SMR     Special Mobile Radio 
-   SMS     Service Management System 
-   SPNP    Service Provider Number Portability 
-   SRF     Signaling Relaying Function 
-   SRI     Send Routing Information 
-   SS7     Signaling System Number 7 
-   STP     Signaling Transfer Point 
-   TCAP    Transaction Capabilities Application Part 
-   TDMA    Time Division Multiple Access 
-   TN      Telephone Number 
-   TRIP    Telephony Routing Information Protocol 
-   URL     Universal Resource Locator 
-   U.S.    United States 
-    
-    
-3. Types of Number Portability 
-    
-   As there are several types of E.164 numbers (telephone numbers, or 
-   just TN) in the GSTN, there are correspondingly several types of 
-   E.164 NP in the GSTN.  First there are so-call non-geographic E.164 
-   numbers, commonly used for service-specific applications such as 
-   freephone (800 or 0800).  Portability of these numbers is called 
-   non-geographic number portability (NGNP).  NGNP, for example, was 
-   deployed in the U.S. in 1986-92. 
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 5] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-    
-   Geographic number portability, which includes traditional fixed or 
-   wireline numbers as well as mobile numbers which are allocated out 
-   of geographic number range prefixes, is called NP or GNP or in the 
-   U.S. local number portability (LNP). 
-    
-   Number portability allows the telephony subscribers in the Global 
-   Switched Telephone Network (GSTN) to keep their phone numbers when 
-   they change their service providers or subscribed services, or when 
-   they move to a new location.   
-    
-   The ability to change the service provider while keeping the same 
-   phone number is called service provider portability (SPNP) also 
-   known as "operator portability." 
-    
-   The ability to change the subscriberËs fixed service location while 
-   keeping the same phone number is called location portability. 
-    
-   The ability to change the subscribed services (e.g., from the plain 
-   old telephone service to Integrated Services Digital Network (ISDN) 
-   services) while keeping the same phone number is called service 
-   portability.  Another aspect of service portability is to allow the 
-   subscribers to enjoy the subscribed services in the same way when 
-   they roam outside their home networks as is supported by the 
-   cellular/wireless networks. 
-    
-   In addition, mobile number portability (MNP) refers to specific NP 
-   implementation in mobile networks either as part of a broader NP 
-   implementation in the GSTN or on a stand-alone basis.  Where 
-   interoperation of LNP and MNP is supported, service portability 
-   between fixed and mobile service types is possible. 
-    
-   At present, SPNP has been the primary form of NP deployed due to its 
-   relevance in enabling local service competition. 
-    
-   Also in use in the GSTN are the terms interim NP (INP) or Interim 
-   LNP (ILNP) and true NP.  Interim NP usually refers to the use of 
-   remote call forwarding-like measures to forward calls to ported 
-   numbers through the donor network to the new service network.  These 
-   are considered interim relative to true NP, which seeks to remove 
-   the donor network or old service provider from the call or signaling 
-   path altogether.  Often the distinction between interim and true NP 
-   is a national regulatory matter relative to the 
-   technical/operational requirements imposed on NP in that country. 
-    
-   Implementations of true NP in certain countries (e.g. U.S., Canada, 
-   Spain, Belgium, Denmark) may pose specific requirements for IP 
-   telephony implementations as a result of regulatory and industry 
-   requirements for providing call routing and signaling independent of 
-   the donor network or last previous serving network. 
-    
-    
-    
-    
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 6] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
- 
-4. Service Provider Number Portability Schemes 
-    
-   Four schemes can be used to support service provider portability and 
-   are briefly described below.  But first, some further terms are 
-   introduced. 
-    
-   The donor network is the network that first assigned a telephone 
-   number (e.g., TN +1-202-533-1234) to a subscriber, out of a number 
-   range administratively (e.g., +1 202-533) assigned to it.  The 
-   current service provider (new SP) or new serving network is the 
-   network that currently serves the ported number. The old serving 
-   network (or old SP) is the network that previously served the ported 
-   number before the number was ported to the new serving network. 
-   Since a TN can port a number of times, the old SP is not necessarily 
-   the same as the donor network, except for the first time the TN 
-   ports away, or if the TN ports back into the donor network and away 
-   again.  While the new SP and old SP roles are transitory as a TN 
-   ports around, the donor network is always the same for any 
-   particular TN based on the service provider to whom the subtending 
-   number range was administratively assigned.  See the discussion 
-   below on number pooling, as this enhancement to NP further 
-   bifurcates the role of donor network into two (the number range or 
-   code holder network, and the block holder network). 
-    
-   To simplify the illustration, all the transit networks are ignored, 
-   the originating or donor network is the one that performs the 
-   database queries or call redirection, and the dialed directory 
-   number (TN) has been ported out of the donor network before.  
-    
-   It is assumed that the old serving network, the new serving network 
-   and the donor network are different networks so as to show which 
-   networks are involved in call handling and routing and database 
-   queries in each of four schemes.  Please note that the port of the 
-   number (process of moving it from one network to another) happened 
-   prior to the call setup and is not included in the call steps.  
-   Information carried in the signaling messages to support each of the 
-   four schemes is not discussed to simplify the explanation. 
-    
-    
-4.1 All Call Query (ACQ) 
-    
-   Figure 1 shows the call steps for the ACQ scheme.  Those call steps 
-   are as follows: 
- 
-   (1) The Originating Network receives a call from the caller and 
-       sends a query to a centrally administered Number Portability 
-       Database (NPDB), a copy of which is usually resident on a 
-       network element within its network or through a third party 
-       provider. 
-   (2) The NPDB returns the routing number associated with the dialed 
-       directory number.  The routing number is discussed later in 
-       Section 6. 
-
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 7] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   (3) The Originating Network uses the routing number to route the 
-       call to the new serving network. 
-    
-    
-   +-------------+              +-----------+    Number   +-----------+ 
-   | Centralized |              | New Serv. |    ported   | Old Serv. | 
-   |    NPDB     |    +-------->|  Network  |<------------|  Network  | 
-   +-------------+    |         +-----------+             +-----------+ 
-       ^  |           | 
-       |  |           | 
-      1|  |         3.| 
-       |  | 2.        | 
-       |  |           | 
-       |  v           | 
-    +----------+      |         +----------+           +----------+ 
-    |   Orig.  |------+         |   Donor  |           | Internal | 
-    |  Network |                |  Network |           |   NPDB   | 
-    +----------+                +----------+           +----------+ 
-    
-    
-              Figure 1 - All Call Query (ACQ) Scheme. 
- 
- 
-4.2 Query on Release (QoR) 
- 
-  Figure 2 shows the call steps for the QoR scheme.  Those call steps 
-  are as follows: 
-    
-    
-   +-------------+              +-----------+    Number   +-----------+ 
-   | Centralized |              | New Serv. |    ported   | Old Serv. | 
-   |    NPDB     |              |  Network  |<------------|  Network  | 
-   +-------------+              +-----------+             +-----------+ 
-       ^  |                          ^ 
-       |  | 4.                       | 
-     3.|  |              5.          | 
-       |  |   +----------------------+ 
-       |  |   | 
-       |  v   | 
-    +----------+      2.        +----------+           +----------+ 
-    |   Orig.  |<---------------|   Donor  |           | Internal | 
-    |  Network |--------------->|  Network |           |   NPDB   | 
-    +----------+      1.        +----------+           +----------+ 
-    
-                   
-                Figure 2 - Query on Release (QoR) Scheme. 
-    
-   (1) The Originating Network receives a call from the caller and 
-       routes the call to the donor network. 
-   (2) The donor network releases the call and indicates that the 
-       dialed directory number has been ported out of that switch. 
-   (3) The Originating Network sends a query to its copy of the 
-       centrally administered NPDB. 
-
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 8] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   (4) The NPDB returns the routing number associated with the dialed 
-       directory number.   
-   (5) The Originating Network uses the routing number to route the 
-       call to the new serving network. 
-    
-    
-4.3 Call Dropback 
-    
-  Figure 3 shows the call steps for the Dropback scheme.  This scheme 
-  is also known as "Return to Pivot (RTP)."  Those call steps are as 
-  follows: 
-    
-   (1) The Originating Network receives a call from the caller and 
-       routes the call to the donor network. 
-   (2) The donor network detects that the dialed directory number has 
-       been ported out of the donor switch and checks with an internal 
-       network-specific NPDB.  
-   (3) The internal NPDB returns the routing number associated with the 
-       dialed directory number. 
-   (4) The donor network releases the call by providing the routing 
-       number. 
-   (5) The Originating Network uses the routing number to route the 
-       call to the new serving network. 
-    
-   +-------------+              +-----------+    Number   +-----------+ 
-   | Centralized |              | New Serv. |    porting  | Old Serv. | 
-   |    NPDB     |              |  Network  |<------------|  Network  | 
-   +-------------+              +-----------+             +-----------+ 
-                                    /\ 
-                                     | 
-                           5.        | 
-            +------------------------+ 
-            | 
-            | 
-    +----------+       4.       +----------+     3.    +----------+ 
-    |   Orig.  |<---------------|   Donor  |<----------| Internal | 
-    |  Network |--------------->|  Network |---------->|   NPDB   | 
-    +----------+      1.        +----------+    2.     +----------+ 
-    
-                   
-                      Figure 3 - Dropback Scheme. 
-    
-    
-4.4 Onward Routing (OR) 
-    
-  Figure 4 shows the call steps for the OR scheme.  Those call steps 
-  are as follows: 
-    
-   (1) The Originating Network receives a call from the caller and 
-       routes the call to the donor network. 
-   (2) The donor network detects that the dialed directory number has 
-       been ported out of the donor switch and checks with an internal 
-       network-specific NPDB.  
-
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 9] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   (3) The internal NPDB returns the routing number associated with the 
-       dialed directory number. 
-   (4) The donor network uses the routing number to route the call to 
-       the new serving network. 
- 
-    
-   +-------------+              +-----------+    Number   +-----------+ 
-   | Centralized |              | New Serv. |    porting  | Old Serv. | 
-   |    NPDB     |              |  Network  |<------------|  Network  | 
-   +-------------+              +-----------+             +-----------+ 
-                                    /\ 
-                                     | 
-                                   4.| 
-                                     | 
-    +----------+                +----------+     3.    +----------+ 
-    |   Orig.  |                |   Donor  |<----------| Internal | 
-    |  Network |--------------->|  Network |---------->|   NPDB   | 
-    +----------+      1.        +----------+    2.     +----------+ 
-    
-                   
-                 Figure 4 - Onward Routing (OR) Scheme. 
- 
-4.5 Comparisons of the Four Schemes 
-    
-   Only the ACQ scheme does not involve the donor network when routing 
-   the call to the new serving network of the dialed ported number.  
-   The other three schemes involve call setup to or signaling with the 
-   donor network.   
-    
-   Only the OR scheme requires the setup of two physical call segments, 
-   one from the Originating Network to the donor network and the other 
-   from the donor network to the new serving network.  The OR scheme is 
-   the least efficient in terms of using the network transmission 
-   facilities.  The QoR and Dropback schemes set up calls to the donor 
-   network first but release the call back to the Originating Network 
-   that then initiates a new call to the Current Serving Network.  For 
-   the QoR and Dropback schemes, circuits are still reserved one by one 
-   between the Originating Network and the donor network when the 
-   Originating Network sets up the call towards the donor network.  
-   Those circuits are released one by one when the call is released 
-   from the donor network back to the Originating Network.  The ACQ 
-   scheme is the most efficient in terms of using the switching and 
-   transmission facilities for the call. 
-    
-   Both the ACQ and QoR schemes involve Centralized NPDBs for the 
-   Originating Network to retrieve the routing information.  
-   Centralized NPDB means that the NPDB contains ported number 
-   information from multiple networks.  This is in contrast to the 
-   internal network-specific NPDB that is used for the Dropback and OR 
-   schemes.  The internal NPDB only contains information about the 
-   numbers that were ported out of the donor network.  The internal 
-   NPDB can be a stand-alone database that contains information about 
-   all or some ported-out numbers from the donor network.  It can also 
-   reside on the donor switch and only contains information about those 
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 10] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   numbers ported out of the donor switch.  In that case, no query to a 
-   stand-alone internal NPDB is required.  The donor switch for a 
-   particular phone number is the switch to which the number range is 
-   assigned from which that phone number was originally assigned. 
-    
-   For example, number ranges in the North American Numbering Plan 
-   (NANP) are usually assigned in the form of central office codes (CO 
-   codes) comprising a six-digit prefix formatted as a NPA+NXX.  Thus a 
-   switch serving +1-202-533 would typically serve +1-202-533-0000 
-   through +1-202-533-9999. In major cities, switches usually host 
-   several CO codes.  NPA stands for Numbering Plan Area that is also 
-   known as the area code.  It is three-digit long and has the format 
-   of NXX where N is any digit from 2 to 9 and X is any digit from 0 to 
-   9.  NXX in the NPA+NXX format is known as the office code that has 
-   the same format as the NPA.  When a NPA+NXX code is set as 
-   Ÿportable÷ in the Local Exchange Routing Guide (LERG), it becomes a 
-   "portable NPA+NXX" code. 
-    
-   Similarly, in other national E.164 numbering plans, number ranges 
-   cover a contiguous range of numbers within that range.  Once a 
-   number within that range has ported away from the donor network, all 
-   numbers in that range are considered potentially ported and should 
-   be queried in the NPDB. 
-    
-   The ACQ scheme has two versions.  One version is for the Originating 
-   Network to always query the NPDB when a call is received from the 
-   caller regardless whether the dialed directory number belongs to any 
-   number range that is portable or has at least one number ported out. 
-   The other version is to check whether the dialed directory number 
-   belongs to any number range that is portable or has at least one 
-   number ported out.  If yes, an NPDB query is sent. If not, no NPDB 
-   query is sent.  The former performs better when there are many 
-   portable number ranges.  The latter performs better when there are 
-   not too many portable number ranges at the expense of checking every 
-   call to see whether NPDB query is needed.  The latter ACQ scheme is 
-   similar to the QoR scheme except that the QoR scheme uses call setup 
-   and relies on the donor network to indicate "number ported out" 
-   before launching the NPDB query. 
-    
-    
-5. Database Queries in the NP Environment 
-    
-   As indicated earlier, the ACQ and QoR schemes require that a switch 
-   query the NPDB for routing information.  Various standards have been 
-   defined for the switch-to-NPDB interface.  Those interfaces with 
-   their protocol stacks are briefly described below.  The term "NPDB" 
-   is used for a stand-alone database that may support just one or some 
-   or all of the interfaces mentioned below.  The NPDB query contains 
-   the dialed directory number and the NPDB response contains the 
-   routing number.  There are certainly other information that is sent 
-   in the query and response.  The primary interest is to get the 
-   routing number from the NPDB to the switch for call routing. 
-    
-    
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 11] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-5.1 U.S. and Canada 
-    
-   One of the following five NPDB interfaces can be used to query an 
-   NPDB: 
-    
-   (a) Advanced Intelligent Network (AIN) using the American National 
-       Standards Institute (ANSI)  version of the Intelligent Network 
-       Application Part (INAP) [ANSI SS] [ANSI DB].  The INAP is 
-       carried on top of the protocol stack that includes the (ANSI) 
-       Message Transfer Part (MTP) Levels 1 through 3, ANSI Signaling 
-       Connection Control Part (SCCP), and ANSI Transaction 
-       Capabilities Application Part (TCAP).  This interface can be 
-       used by the wireline or wireless switches, is specific to the NP 
-       implementation in North America, and is modeled on the Public 
-       Office Dialing Plan (PODP) trigger defined in the Advanced 
-       Intelligent Network (AIN) 0.1 call model.  
-    
-   (b) Intelligent Network (IN), which is similar to the one used for 
-       querying the 800 databases.  The IN protocol is carried on top 
-       of the protocol stack that includes the ANSI MTP Levels 1 
-       through 3, ANSI SCCP, and ANSI TCAP.  This interface can be used 
-       by the wireline or wireless switches. 
-    
-   (c) ANSI IS-41 [IS41] [ISNP], which is carried on top of the 
-       protocol stack that includes the ANSI MTP Levels 1 through 3, 
-       ANSI SCCP, and ANSI TCAP.  This interface can be used by the IS-
-       41 based cellular/Personal Communication Services (PCS) wireless 
-       switches (e.g., AMPS, TDMA and CDMA).  Cellular systems use 
-       spectrum at 800 MHz range and PCS systems use spectrum at 1900 
-       MHz range. 
-    
-   (d) Global System for Mobile Communication Mobile Application Part 
-       (GSM MAP) [GSM], which is carried on top of the protocol stack 
-       that includes the ANSI MTP Levels 1 through 3, ANSI SCCP, and 
-       International Telecommunication Union - Telecommunication Sector  
-       (ITU-TS) TCAP.  It can be used by the PCS1900 wireless switches 
-       that are based on the GSM technologies.  GSM is a series of 
-       wireless standards defined by the European Telecommunications 
-       Standards Institute (ETSI). 
-    
-   (e) ISUP triggerless translation.  NP translations are performed 
-       transparently to the switching network by the signaling network 
-       (e.g. Signaling Transfer Points (STPs) or signaling gateways).  
-       ISUP IAM messages are examined to determine if the CdPN field 
-       has already been translated, and if not, an NPDB query is 
-       performed, and the appropriate parameters in the IAM message 
-       modified to reflect the results of the translation.   The 
-       modified IAM message is forwarded by the signaling node on to 
-       the designated DPC in a transparent manner to continue call 
-       setup.  The NPDB can be integrated with the signaling node or be 
-       accessed via an API locally or by a query to a remote NPDB using 
-       a proprietary protocol or the schemes described above. 
-    
-    
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 12] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   Wireline switches have the choice of using either (a), (b), or (e).  
-   IS-41 based wireless switches have the choice of using (a), (b), 
-   (c), or (e).  PCS1900 wireless switches have the choice of using 
-   (a), (b), (d), or (e). In the United States, service provider 
-   portability will be supported by both the wireline and wireless 
-   systems, not only within the wireline or wireless domain but also 
-   across the wireline/wireless boundary.  However, this is not true in 
-   Europe where service provider portability is usually supported only 
-   within the wireline or wireless domain, not across the 
-   wireline/wireless boundary due to explicit use of service-specific 
-   number range prefixes.  The reason is to avoid caller confusion 
-   about the call charge. GSM systems in Europe are assigned 
-   distinctive destination network codes, and the caller pays a higher 
-   charge when calling a GSM directory number. 
-    
-      
-5.2 Europe 
-    
-   One of the following two interfaces can be used to query an NPDB: 
-    
-   (a) Capability Set 1 (CS1) of the ITU-TS INAP [CS1], which is 
-       carried on top of the protocol stack that includes the ITU-TS 
-       MTP Levels 1 through 3, ITU-TS SCCP, and ITU-TS TCAP. 
-    
-   (b) Capability Set 2 (CS2) of the ITU-TS INAP [CS2], which is 
-       carried on top of the protocol stack that includes the ITU-TS 
-       MTP Levels 1 through ITU-TS MTP Levels 1 through 3, ITU-TS SCCP, 
-       and ITU-TS TCAP. 
-    
-   Wireline switches have the choice of using either (a) or (b); 
-   however, all the implementations in Europe so far are based on CS1.  
-   As indicated earlier that number portability in Europe does not go 
-   across the wireline/wireless boundary.  The wireless switches can 
-   also use (a) or (b) to query the NPDBs if those NPDBs contains 
-   ported wireless directory numbers.  The term "Mobile Number 
-   Portability (MNP)" is used for the support of service provider 
-   portability by the GSM networks in Europe.  
-    
-   In most, if not all, cases in Europe, the calls to the wireless 
-   directory numbers are routed to the wireless donor network first.  
-   Over there, an internal NPDB is queried to determine whether the 
-   dialed wireless directory number has been ported out or not.  In 
-   this case, the interface to the internal NPDB is not subject to 
-   standardization. 
-
-   MNP in Europe can also be supported via MNP Signaling Relay Function 
-   (MNP-SRF).  Again, an internal NPDB or a database integrated at the 
-   MNP-SRF is used to modify the SCCP Called Party Address parameter in 
-   the GSM MAP messages so that they can be re-directed to the wireless 
-   serving network.   Call routing involving MNP will be explained in 
-   Section 6.2. 
-    
-    
-    
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 13] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-6. Call Routing in the NP Environment 
- 
-   This section discusses the call routing after the routing 
-   information has been retrieved either through an NPDB query or an 
-   internal database lookup at the donor switch, or from the Integrated 
-   Services Digital Network User Part (ISUP) signaling message (e.g., 
-   for the Dropback scheme).  For the ACQ, QoR and Dropback schemes, it 
-   is the Originating Network that has the routing information and is 
-   ready to route the call.  For the OR scheme, it is the donor network 
-   that has the routing information and is ready to route the call.   
-    
-   A number of triggering schemes may be employed that determine where 
-   in the call path the NPDB query is performed.  In the U.S. an ŸN-1÷ 
-   policy is used, which essentially says that for domestic calls, the 
-   originating local carriers performs the query, otherwise, the long 
-   distance carrier is expected to.  To ensure independence of the 
-   actual trigger policy employed in any one carrier, forward call 
-   signaling is used to flag that an NPDB query has already been 
-   performed and to therefore suppress any subsequent NP triggers that 
-   may be encountered in downstream switches, in downstream networks.  
-   This allows the earliest able network in the call path to perform 
-   the query without introducing additional costs and call setup delays 
-   were redundant queries performed downstream. 
-    
-     
-6.1 U.S. and Canada 
-    
-   In the U.S. and Canada, a ten-digit North American Numbering Plan 
-   (NANP) number called Location Routing Number (LRN) is assigned to 
-   every switch involved in NP.  In the NANP, a switch is not reachable 
-   unless it has a unique number range (CO code) assigned to it.  
-   Consequently, the LRN for a switch is always assigned out of a CO 
-   code that is assigned to that switch. 
-    
-   The LRN assigned to a switch currently serving a particular ported 
-   telephone number is returned as the network routing address in the 
-   NPDB response.  The service portability scheme that was adopted in 
-   the North America is very often referred to as the LRN scheme or 
-   method. 
-    
-   LRN serves as a network address for terminating calls served off 
-   that switch using ported numbers.  The LRN is assigned by the switch 
-   operator using any of the unique CO codes (NPA+NXX) assigned to that 
-   switch.  The LRN is considered a non-dialable address, as the same 
-   10-digit number value may be assigned to a line on that switch.  A 
-   switch may have more than one LRN. 
-    
-   During call routing/processing, a switch performs an NPDB query to 
-   obtain the LRN associated with the dialed directory number. NPDB 
-   queries are performed for all the dialed directory numbers whose 
-   NPA+NXX codes are marked as portable NPA+NXX at that switch. When 
-   formulating the ISUP Initial Address Message (IAM) to be sent to the 
-   next switch, the switch puts the ten-digit LRN in the ISUP Called 
-   Party Number (CdPN) parameter and the originally dialed directory 
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 14] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   number in the ISUP Generic Address parameter (GAP).  A new code in 
-   the GAP was defined to indicate that the address information in the 
-   GAP is the dialed directory number. A new bit in the ISUP Forward 
-   Call Indicator (FCI) parameter, the Ported Number Translation 
-   Indicator (PNTI) bit, is set to imply that NPDB query has already 
-   been performed.  All the switches in the downstream will not perform 
-   the NPDB query if the PNTI bit is set. 
-    
-   When the terminating switch receives the IAM and sees the PNTI bit 
-   in the FCI parameter set and its own LRN in the CdPN parameter, it 
-   retrieves the originally dialed directory number from the GAP and 
-   uses the dialed directory number to terminate the call. 
-    
-   A dialed directory number with a portable NPA+NXX does not imply 
-   that directory number has been ported.  The NPDBs currently do not 
-   store records for non-ported directory numbers.  In that case, the 
-   NPDB will return the same dialed directory number instead of the 
-   LRN.  The switch will then set the PNTI bit but keep the dialed 
-   directory number in the CdPN parameter. 
-    
-   In the real world environment, the Originating Network is not always 
-   the one that performs the NPDB query.  For example, it is usually 
-   the long distance carriers that query the NPDBs for long distance 
-   calls.  In that case, the Originating Network operated by the local 
-   exchange carrier (LEC) simply routes the call to the long distance 
-   carrier that is to handle that call.   A wireless network acting as 
-   the Originating Network can also route the call to the 
-   interconnected local exchange carrier network if it does not want to 
-   support the NPDB interface at its mobile switches. 
-    
-    
-6.2 Europe 
-    
-   In some European countries, a routing number is prefixed to the 
-   dialed directory number.  The ISUP CdPN parameter in the IAM will 
-   contain the routing prefix and the dialed directory number.  For 
-   example, United Kingdom uses routing prefixes with the format of 
-   5XXXXX and Italy uses C600XXXXX as the routing prefix.  The networks 
-   use the information in the ISUP CdPN parameter to route the call to 
-   the New/Current Serving Network. 
-    
-   The routing prefix can identify the Current Serving Network or the 
-   Current Serving Switch of a ported number.  For the former case, 
-   another query to the "internal" NPDB at the Current Serving Network 
-   is required to identify the Current Serving Switch before routing 
-   the call to that switch.  This shields the Current Serving Switch 
-   information for a ported number from the other networks at the 
-   expense of an additional NPDB query.  Another routing number, may be 
-   meaningful within the Current Serving Network, will replace the 
-   previously prefixed routing number in the ISUP CdPN parameter.  For 
-   the latter case, the call is routed to the Current Serving Switch 
-   without an additional NPDB query. 
-    
-
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 15] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   When the terminating switch receives the IAM and sees its own 
-   routing prefix in the CdPN parameter, it retrieves the originally 
-   dialed directory number after the routing prefix, and uses the 
-   dialed directory number to terminate the call.  
-    
-   The call routing example described above shows one of the three 
-   methods that can be used to transport the Directory Number (DN) and 
-   the Routing Number (RN) in the ISUP IAM message.  In addition, some 
-   other information may be added/modified as is listed in the ETSI 302 
-   097 document [ETSIISUP], which is based on the ITU-T Recommendation 
-   Q.769.1 [ITUISUP].  The three methods and the enhancements in the 
-   ISUP to support number portability are briefly described below 
-    
-   (a) Two separate parameters with the CdPN parameter containing the 
-      RN and a new Called Directory Number (CdDN) parameter containing 
-      the DN.  A new value for the Nature of Address (NOA) indicator in 
-      the CdPN parameter is defined to indicate that the RN is in the 
-      CdPN parameter.  The switches use the CdPN parameter to route the 
-      call as is done today. 
-    
-   (b) Two separate parameters with the CdPN parameter containing the 
-      DN and a new Network Routing Number (NRN) parameter containing 
-      the RN.  This method requires that the switches use the NRN 
-      parameter to route the call. 
-    
-   (c) Concatenated parameter with the CdPN parameter containing the RN 
-      plus the DN.  A new Nature of Address (NOA) indicator in the CdPN 
-      parameter is defined to indicate that the RN is concatenated with 
-      the DN in the CdPN parameter.  Some countries may not use new NOA 
-      value because the routing prefix does not overlap with the dialed 
-      directory numbers.  But if the routing prefix overlaps with the 
-      dialed directory numbers, a new NOA value must be assigned.  For 
-      example, Spain uses "XXXXXX" as the routing prefix to identify 
-      the new serving network and uses a new NOA value of 126. 
-    
-   There is also a network option to add a new ISUP parameter called 
-   Number Portability Forwarding Information parameter.  This parameter 
-   has a four-bit Number Portability Status Indicator field that can 
-   provide an indication whether number portability query is done for 
-   the called directory number and whether the called directory number 
-   is ported or not if the number portability query is done. 
- 
-   Please note that all those NP enhancements for a ported number can 
-   only be used in the country that defined them.  This is because 
-   number portability is supported within a nation.  Within each 
-   nation, the telecommunications industry or the regulatory bodies can 
-   decide which method or methods to use.  Number portability related 
-   parameters and coding are usually not passed across the national 
-   boundaries unless the interconnection agreements allow that.  For 
-   example, a UK routing prefix can only be used in UK, and would cause 
-   routing problem if it appears outside UK. 
-    
-
-
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 16] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   As indicated earlier, an originating wireless network can query the 
-   NPDB and concatenate the RN with DN in the CdPN parameter and route 
-   the call directly to the Current Serving Network.   
-    
-   If NPDBs do not contain information about the wireless directory 
-   numbers, the call, originated from either a wireline or a wireless 
-   network, will be routed to the Wireless donor network.  Over there, 
-   an internal NPDB is queried to retrieve the RN that then is 
-   concatenated with the DN in the CdPN parameter. 
-    
-   There are several ways of realizing MNP.  When MNP-SRF is supported, 
-   the Gateway Mobile Services Switching Center (GMSC) at the wireless 
-   donor network, when receiving a call from the wireline network, can 
-   send the GSM MAP Send Routing Information (SRI) message to the MNP-
-   SRF.  The MNP-SRF interrogates an internal or integrated NPDB for 
-   the RN of the MNP-SRF of the wireless Current Serving Network and 
-   prefixes the RN to the dialed wireless directory number in the 
-   global title address information in the SCCP Called Party Address 
-   (CdPA) parameter.  This SRI message will be routed to the MNP-SRF of 
-   the wireless Current Serving Network, which then responds with an 
-   acknowledgement by providing the RN plus the dialed wireless 
-   directory number as the Mobile Station Roaming Number (MSRN).  The 
-   GMSC of the wireless donor network formulates the ISUP IAM with the 
-   RN plus the dialed wireless directory number in the CdPN parameter 
-   and routes the call to the wireless Current Serving Network.  A GMSC 
-   of the wireless Current Serving Network receives the call and sends 
-   an SRI message to the associated MNP-SRF where the global title 
-   address information of the SCCP CdPA parameter contains only the 
-   dialed wireless directory number.  The MNP-SRF then replaces the 
-   global title address information in the SCCP CdPA parameter with the 
-   address information associated with a Home Location Register (HLR) 
-   that hosts the dialed wireless directory number and forwards the 
-   message to that HLR after verifying that the dialed wireless 
-   directory number is a ported-in number.   The HLR then returns an 
-   acknowledgement by providing an MSRN for the GMSC to route the call 
-   to the MSC that currently serves the mobile station that is 
-   associated with the dialed wireless directory number.  Please see 
-   [MNP] for details and additional scenarios. 
-    
-    
-7. NP Implementations for Geographic E.164 Numbers 
- 
-   This section shows the known SPNP implementations worldwide.  
-    
-   +-------------+----------------------------------------------------+ 
-   +   Country   +             SPNP Implementation                    + 
-   +-------------+----------------------------------------------------+ 
-   +  Argentina  + Analyzing operative viability now. Will determine  + 
-   +             + whether portability should be made obligatory      + 
-   +             + after a technical solution has been determined.    + 
-   +-------------+----------------------------------------------------+ 
-   +  Australia  + NP supported by wireline operators since 11/30/99. + 
-   +             + NP among wireless operators in March/April 2000,   + 
-
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 17] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   +             + but may be delayed to 1Q01. The access provider    + 
-   +             + or long distance provider has the obligation to    + 
-   +             + route the call to the correct destination. The     + 
-   +             + donor network is obligated to maintain and make    + 
-   +             + available a register of numbers ported away from   +  
-   +             + its network.  Telstra uses onward routing via an   + 
-   +             + on-switch solution.                                + 
-   +-------------+----------------------------------------------------+ 
-   +   Austria   + Uses onward routing at the donor network.  Routing + 
-   +             + prefix is "86xx" where "xx" identifies the         + 
-   +             + recipient network.                                 + 
-   +-------------+----------------------------------------------------+ 
-   +  Belgium    + ACQ selected by the industry. Routing prefix is    + 
-   +             + "Cxxxx" where "xxxx" identifies the recipient      + 
-   +             + switch. Another routing prefix is "C00xx" with "xx"+ 
-   +             + identifying the recipient network.  Plan to use NOA+ 
-   +             + to identify concatenated numbers and abandon the   + 
-   +             + hexadecimal routing prefix.                        + 
-   +-------------+----------------------------------------------------+ 
-   +  Brazil     + Considering NP for wireless users.                 + 
-   +-------------+----------------------------------------------------+ 
-   +  Chile      + There has been discussions lately on NP.           + 
-   +-------------+----------------------------------------------------+ 
-   +  Colombia   + There was an Article 3.1 on NP to support NP prior + 
-   +             + to December 31, 1999 when NP became technically    + 
-   +             + possible. Regulator has not yet issued regulations + 
-   +             + concerning this matter.                            + 
-   +-------------+----------------------------------------------------+ 
-   +  Denmark    + Uses ACQ. Routing number not passed between        + 
-   +             + operators; however, NOA is set to "112" to         + 
-   +             + indicate "ported number."  QoR can be used based   + 
-   +             + on bilateral agreements.                           +        
-   +-------------+----------------------------------------------------+ 
-   +  Finland    + Uses ACQ.  Routing prefix is "1Dxxy" where "xxy"   + 
-   +             + identifies the recipient network and service type. + 
-   +-------------+----------------------------------------------------+ 
-   +  France     + Uses onward routing.  Routing prefix is "Z0xxx"    + 
-   +             + where "xxx" identifies the recipient switch.       + 
-   +-------------+----------------------------------------------------+ 
-   +  Germany    + The originating network needs to do necessary      + 
-   +             + rerouting.  Operators decide their own solution(s).+ 
-   +             + Deutsche Telekom uses ACQ.  Routing prefix is      + 
-   +             + "Dxxx" where "xxx" identifies the recipient        + 
-   +             + network.                                           + 
-   +-------------+----------------------------------------------------+ 
-   +  Hong Kong  + Recipient network informs other networks about     + 
-   +             + ported-in numbers.  Routing prefix is "14x" where  + 
-   +             + "14x" identifies the recipient network, or a       + 
-   +             + routing number of "4x" plus 7 or 8 digits is used  +  
-   +             + where "4x" identifies the recipient network and    + 
-   +             + the rest of digits identify the called party.      + 
-   +-------------+----------------------------------------------------+ 
-   +  Ireland    + Operators choose their own solution but use onward + 
-   +             + routing now. Routing prefix is "1750" as the intra-+ 
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 18] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   +             + network routing code (network-specific) and        + 
-   +             + "1752xxx" to "1759xxx" for GNP where "xxx"         + 
-   +             + identifies the recipient switch.                   + 
-   +-------------+----------------------------------------------------+ 
-   +  Italy      + Uses onward routing. Routing prefix is "C600xxxxx" + 
-   +             + where "xxxxx" identifies the recipient switch.     + 
-   +             + Telecom Italia uses IN solution and other operators+              
-   +             + use on-switch solution.                            + 
-   +-------------+----------------------------------------------------+ 
-   +  Japan      + Uses onward routing.  Donor switch uses IN to get  + 
-   +             + routing number.                                    + 
-   +-------------+----------------------------------------------------+ 
-   +  Mexico     + NP is considered in the Telecom law; however, the  + 
-   +             + regulator (Cofetel) or the new local entrants have + 
-   +             + started no initiatives on this process.            + 
-   +-------------+----------------------------------------------------+ 
-   + Netherlands + Operators decide NP scheme to use.  Operators have + 
-   +             + chosen ACQ or QoR.  KPN implemented IN solution    + 
-   +             + similar to U.S. solution.  Routing prefix is not   + 
-   +             + passed between operators.                          + 
-   +-------------+----------------------------------------------------+ 
-   +  Norway     + OR for short-term and ACQ for long-term.  QoR is   + 
-   +             + optional. Routing prefix can be "xxx" with NOA=8,  + 
-   +             + or "142xx" with NOA=3 where "xxx" or "xx"          + 
-   +             + identifies the recipient network.                  + 
-   +------------ +----------------------------------------------------+ 
-   +  Peru       + Wireline NP may be supported in 2001.              + 
-   +-------------+----------------------------------------------------+ 
-   +  Portugal   + No NP today.                                       + 
-   +-------------+----------------------------------------------------+ 
-   +  Spain      + Uses ACQ.  Telefonica uses QoR within its network. + 
-   +             + Routing prefix is  "xxyyzz" where "xxyyzz"         + 
-   +             + identifies the recipient network.  NOA is set to   + 
-   +             + 126.                                               + 
-   +-------------+----------------------------------------------------+ 
-   +  Sweden     + Standardized the ACQ but OR for operators without  + 
-   +             + IN. Routing prefix is "xxx" with NOA=8 or "394xxx" + 
-   +             + with NOA=3 where "xxx" identifies the recipient    + 
-   +             + network. But operators decide NP scheme to use.    + 
-   +             + Telia uses onward routing between operators.       + 
-   +-------------+----------------------------------------------------+ 
-   + Switzerland + Uses OR now and QoR in 2001.  Routing prefix is    + 
-   +             + "980xxx" where "xxx" identifies the recipient      +        
-   +             + network.                                           + 
-   +-------------+----------------------------------------------------+ 
-   +  UK         + Uses onward routing. Routing prefix is "5xxxxx"    + 
-   +             + where "xxxxx" identifies the recipient switch. NOA + 
-   +             + is 126. BT uses the dropback scheme in some parts  + 
-   +             + of its network.                                    + 
-   +-------------+----------------------------------------------------+ 
-   +  US         + Uses ACQ.  "Location Routing Number (LRN)" is used + 
-   +             + in the Called Party Number parameter.  Called party+ 
-   +             + number is carried in the Generic Address Parameter + 
-   +             + Use a PNTI indicator in the Forward Call Indicator + 
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 19] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   +             + parameter to indicate that NPDB dip has been       + 
-   +             + performed.                                         + 
-   +-------------+----------------------------------------------------+ 
-    
-    
-8. Number Conservation Methods Enabled by NP 
- 
-   In addition to porting numbers NP provides the ability for number 
-   administrators to assign numbering resources to operators in smaller 
-   increments.  Today it is common for numbering resources to be 
-   assigned to telephone operators in a large block of consecutive 
-   telephone numbers (TNs).  For example, in North America each of 
-   these blocks contains 10,000 TNs and is of the format NXX+0000 to 
-   NXX+9999.  Operators are assigned a specific NXX, or block.  That 
-   operator is referred to as the block holder.  In that block there 
-   are 10,000 TNs with line numbers ranging from 0000 to 9999.   
-    
-   Instead of assigning an entire block to the operator NP allows the 
-   administrator to assign a sub-block or even an individual telephone 
-   number.  This is referred to as block pooling and individual 
-   telephone number (ITN) pooling, respectively.  
-     
-    
-8.1 Block Pooling 
-    
-   Block Pooling refers to the process whereby the number administrator 
-   assigns a range of numbers defined by a logical sub-block of the 
-   existing block.  Using North America as an example, block pooling 
-   would allow the administrator to assign sub-blocks of 1,000 TNs to 
-   multiple operators.  That is, NXX+0000 to NXX+0999 can be assigned 
-   to operator A, NXX+1000 to NXX+1999 can be assigned to operator B, 
-   NXX-2000 to 2999 can be assigned to operator C, etc.  In this 
-   example block pooling divides one block of 10,000 TNs into ten 
-   blocks of 1,000 TNs.   
-    
-   Porting the sub-blocks from the block holder enables block pooling.  
-   Using the example above operator A is the block holder, as well as, 
-   the holder of the first sub-block, NXX+0000 to NXX+0999.  The second 
-   sub-block, NXX+1000 to NXX+1999, is ported from operator A to 
-   operator B.  The third sub-block, NXX+2000 to NXX+2999, is ported 
-   from operator A to operator C, and so on.  NP administrative 
-   processes and call processing will enable proper and efficient 
-   routing.   
-    
-   From a number administration and NP administration perspective block 
-   pooling introduces a new concept, that of the sub-block holder.  
-   Block pooling requires coordination between the number 
-   administrator, the NP administrator, the block holder, and the sub-
-   block holder.  Block pooling must be implemented in a manner that 
-   allows for NP within the sub-blocks.  Each TN can have a different 
-   serving operator, sub-block holder, and block holder. 
-      
-    
-    
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 20] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-8.2 ITN Pooling 
-    
-   ITN pooling refers to the process whereby the number administrator 
-   assigns individual telephone numbers to operators.  Using the North 
-   American example, one block of 10,000 TNs can be divided into 10,000 
-   ITNs.  ITN is more commonly deployed in freephone services.   
-    
-   In ITN the block is not assigned to an operator but to a central 
-   administrator.  The administrator then assigns ITNs to operators.  
-   NP administrative processes and call processing will enable proper 
-   and efficient routing. 
-    
- 
-9. Potential Implications 
-    
-   There are three general areas of impact to IP telephony work-in-
-   progress at IETF: 
-    
-   - Interoperation between NP in GSTN and IP telephony 
-   - NP implementation or emulation in IP telephony 
-   - Interconnection to NP administrative environment 
-    
-   A good understanding of how number portability is supported in the 
-   GSTN is important when addressing the interworking issues between 
-   IP-based networks and the GSTN.  This is especially important when 
-   the IP-based network needs to route the calls to the GSTN.  As shown 
-   in Section 5, there are a variety of standards with various protocol 
-   stacks for the switch-to-NPDB interface.  Not only that, the 
-   national variations of the protocol standards make it very 
-   complicated to deal with in a global environment.  If an entity in 
-   the IP-based network needs to query those existing NPDBs for routing 
-   number information to terminate the calls to the destination GSTN, 
-   it would be impractical, if not an impossible, job for that entity 
-   to support all those interface standards to access the NPDBs in many 
-   countries. 
-    
-   Several alternatives may address this particular problem.  One 
-   alternative is to use certain entities in the IP-based networks for 
-   dealing with NP query, similar to the International Switches that 
-   are used in the GSTN to interwork different national ISUP 
-   variations.  This will force signaling information associated with 
-   the calls to certain NP-capable networks in the terminating GSTN to 
-   be routed to those IP entities that support the NP functions.  Those 
-   IP entities then query the NPDBs in the terminating country.   This 
-   will limit the number of NPDB interfaces that certain IP entities 
-   need to support.  Another alternative can be to define a "common" 
-   interface to be supported by all the NPDBs so that all the IP 
-   entities use that standardized protocol to query them.   The 
-   existing NPDBs can support this additional interface, or new NPDBs 
-   can be deployed that contain the same information but support the 
-   common IP interface. The candidates for such a common interface 
-   include Lightweight Directory Access Protocol (LDAP) and SIP 
-   [SIP](e.g., using the SIP redirection capability).  Certainly 
-
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 21] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   another possibility is to use interworking function to convert from 
-   one protocol to another. 
-    
-   IP-based networks can handle the domestic calls between two GSTNs.  
-   If the originating GSTN has performed NPDB query, SIP will need to 
-   transport and make use of some of the ISUP signaling information 
-   even if ISUP signaling may be encapsulated in SIP.  Also, IP-based 
-   networks may perform the NPDB queries, as the N-1 carrier.  In that 
-   case, SIP also needs to transport the NP related information while 
-   the call is being routed to the destination GSTN.  There are three 
-   pieces of NP related information that SIP needs to transport.  They 
-   are 1) the called directory number, 2) a routing number, and 3) a 
-   NPDB dip indicator.  The NPDB dip indicator is needed so that the 
-   terminating GSTN will not perform another NPDB dip.  The routing 
-   number is needed so that it is used to route the call to the 
-   destination network or switch in the destination GSTN.  The called 
-   directory number is needed so that the terminating GSTN switch can 
-   terminate the call.  When the routing number is present, the NPDB 
-   dip indicator may not be present because there are cases where 
-   routing number is added for routing the call even if NP is not 
-   involved.  One issue is how to transport the NP related information 
-   via SIP.  The SIP Universal Resource Locator (URL) is one mechanism.  
-   Another better choice may be to add an extension to the "tel" URL 
-   [TEL] that is also supported by SIP.  Please see [TELNP] for the 
-   proposed extensions to the "tel" URL to support NP and freephone 
-   service.  Those extensions to the "tel" URL will be automatically 
-   supported by SIP because they can be carried as the optional 
-   parameters in the user portion of the "sip" URL. 
-    
-   For a called directory number that belongs to a country that 
-   supports NP, and if the IP-based network is to perform the NPDB 
-   query, the logical step is to perform the NPDB dip first to retrieve 
-   the routing number and use that routing number to select the correct 
-   IP telephony gateways that can reach the serving switch that serves 
-   the called directory number.  Therefore, if the "rn" parameter is 
-   present in the "tel" URL or sip URL in the SIP INVITE message, it 
-   instead of the called directory number should be used for making 
-   routing decisions assuming that no other higher priority routing-
-   related parameters such as the Ÿcic÷ are present.  If "rn" is not 
-   present, then the dialed directory number can be used as the routing 
-   number for making routing decisions.   
-    
-   Telephony Routing Information Protocol (TRIP) [TRIP] is a policy 
-   driven inter-administrative domain protocol for advertising the 
-   reachability of telephony destinations between location servers, and 
-   for advertising attributes of the routes to those destinations.  
-   With the NP in mind, it is very important to know that it is the 
-   routing number, if present, not the called directory number that 
-   should be used to check against the TRIP tables for making the 
-   routing decisions.   
-    
-   Overlap signaling exists in the GSTN today.  For a call routing from 
-   the originating GSTN to the IP-based network that involves overlap 
-   signaling, NP will impact the call processing within the IP-based 
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 22] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   networks if they must deal with the overlap signaling.  The entities 
-   in the IP-based networks that are to retrieve the NP information 
-   (e.g., the routing number) must collect a complete called directory 
-   number information before retrieving the NP information for a ported 
-   number.  Otherwise, the information retrieval won't be successful.   
-   This is an issue for the IP-based networks if the originating GSTN 
-   does not handle the overlap signaling by collecting the complete 
-   called directory number. 
-    
-   The IETF enum working group is defining the use of Domain Name 
-   System (DNS) for identifying available services associated with a 
-   particular E.164 number [ENUM].  [ENUMPO] outlines the principles 
-   for the operation of a telephone number service that resolves 
-   telephone numbers into Internet domain name addresses and service-
-   specific directory discovery.  [ENUMPO] implements a three-level 
-   approach where the first level is the mapping of the telephone 
-   number delegation tree to the authority to which the number has been 
-   delegated, the second level is the provision of the requested DNS 
-   resource records from a service registrar, and the third level is 
-   the provision of service specific data from the service provider 
-   itself.  NP certainly must be considered at the first level because 
-   the telephony service providers do not "own" or control the 
-   telephone numbers under the NP environment; therefore, they may not 
-   be the proper entities to have the authority for a given E.164 
-   number.  Not only that, there is a regulatory requirement on NP in 
-   some countries that the donor network should not be relied on to 
-   reach the delegated authority during the DNS process .  The 
-   delegated authority for a given E.164 number is likely to be an 
-   entity designated by the end user that owns/controls a specific 
-   telephone number or one that is designated by the service registrar. 
-    
-   Since the telephony service providers may have the need to use ENUM 
-   for their network-related services (e.g., map an E.164 number to a 
-   HLR Identifier in the wireless networks), their ENUM records must be 
-   collocated with those of the telephony subscribers.  If that is the 
-   case, NP will impact ENUM when a telephony subscriber who has ENUM 
-   service changes the telephony service provider.  This is because 
-   that the ENUM records from the new telephony service provider must 
-   replace those from the old telephony service provider.  To avoid the 
-   NP impact on ENUM, it is recommended that the telephony service 
-   providers use a different domain tree for their network-related 
-   service.  For example, if e164.arpa is chosen for Ÿend user÷ ENUM, a 
-   domain tree different from e164.arpa should be used for Ÿcarrier÷ 
-   ENUM. 
-    
-   The IP-based networks also may need to support some forms of number 
-   portability in the future if E.164 numbers [E164] are assigned to 
-   the IP-based end users.  One method is to assign a GSTN routing 
-   number for each IP-based network domain or entity in a NP-capable 
-   country.  This may increase the number of digits in the routing 
-   number to incorporate the IP entities and impact the existing 
-   routing in the GSTN.  Another method is to associate each IP entity 
-   with a particular GSTN gateway.  At that particular GSTN gateway, 
-   the called directory number then is used to locate the IP-entity 
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 23] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   that serves that dialed directory number.  Yet, another method can 
-   be to assign a special routing number so that the call to an end 
-   user currently served by an IP entity is routed to the nearest GSTN 
-   gateway.  The called directory number then is used to locate the IP-
-   entity that serves that dialed directory number.  A mechanism can be 
-   developed or used for the IP-based network to locate the IP entity 
-   that serves a particular dialed directory number.  Many other types 
-   of networks use E.164 numbers to identify the end users or terminals 
-   in those networks.  Number portability among GSTN, IP-based network 
-   and those various types of networks may also need to be supported in 
-   the future. 
-    
- 
-10. Security Considerations 
- 
-   This document does not raise any security issues. 
- 
- 
-11. IANA Considerations 
- 
-   This document introduces no new values for IANA registration. 
-    
- 
-12. Normative References  
- 
-   [ANSI OSS] ANSI Technical Requirements No. 1, "Number Portability -
-        Operator Services Switching Systems," April 1999. 
-    
-   [ANSI SS] ANSI Technical Requirements No. 2, "Number Portability -
-        Switching Systems," April 1999. 
-             
-   [ANSI DB] ANSI Technical Requirements No. 3, "Number Portability 
-        Database and Global Title Translation," April 1999.         
-          
-   [CS1] ITU-T Q-series  Recommendations - Supplement 4, "Number 
-        portability Capability set 1 requirements for service provider 
-        portability (All call query and onward routing)," May 1998. 
-    
-   [CS2] ITU-T Q-series  Recommendations - Supplement 5, "Number 
-        portability -Capability set 2 requirements for service provider 
-        portability (Query on release and Dropback)," March 1999. 
-    
-   [E164] ITU-T Recommendation E.164, "The International Public 
-        Telecommunications Numbering Plan," 1997. 
-    
-   [ENUM] P. Falstrom, "E.164 number and DNS," RFC 2916. 
-    
-   [ETSIISUP] ETSI EN 302 097 V.1.2.2, ŸIntegrated Services Digital 
-        Network (ISDN); Signalling System No.7 (SS7); ISDN User Part 
-        (ISUP); Enhancement for support of Number Portability (NP) 
-        [ITU-T Recommendation Q.769.1 (2000), modified] 
-    
-   [GSM]  GSM 09.02: "Digital cellular telecommunications system (Phase 
-        2+); Mobile Application Part (MAP) specification". 
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 24] 
-
-Number Portability in the GSTN: An Overview              March 1, 2002 
- 
- 
- 
-   [IS41] TIA/EIA IS-756 Rev. A, "TIA/EIA-41-D Enhancements for 
-        Wireless Number Portability Phase II (December 1998)"Number 
-        Portability Network Support," April 1998. 
-    
-   [ITUISUP] ITU-T Recommendation Q.769.1, "Signaling System No. 7 - 
-        ISDN User Part Enhancements for the Support of Number 
-        Portability," December 1999. 
-    
-   [MNP] ETSI EN 301 716 (2000-10) European Standard 
-        (Telecommunications series) Digital cellular telecommunications 
-        system (Phase 2+); Support of Mobile Number Portability (MNP); 
-        Technical Realisation; Stage 2; (GSM 03.66 Version 7.2.0 
-        Release 1998). 
-    
-   [RFC] Scott Bradner, RFC2026, "The Internet Standards Process -- 
-        Revision 3," October 1996. 
-    
- 
-13. Informative References  
- 
-   [ENUMPO] A. Brown and G. Vaudreuil, "ENUM Service Specific 
-        Provisioning: Principles of Operations," draft-ietf-enum-
-        operation-02.txt, February 23, 2001. 
-    
-   [SIP] J. Rosenberg, et al., draft-ietf-sip-rfc2543bis-09.txt, "SIP: 
-        Session Initiation Protocol," February 27, 2002. 
-    
-   [TEL] H. Schulzrinne and A. Vaha-Sipila, draft-antti-rfc2806bis-
-        04.txt, "URIs for Telephone Calls," May 24, 2002. 
- 
-   [TELNP] J. Yu, draft-yu-tel-url-05.txt, "Extensions to the "tel" URL 
-        to support Number Portability and Freephone Service," June 14, 
-        2002. 
-    
-   [TRIP] J. Rosenberg, H. Salama and M. Squire, RFC 3219, "Telephony 
-        Routing Information Protocol (TRIP)," January 2002. 
-    
-    
-14. Acknowledgment 
-    
-   The authors would like to thank Monika Muench for providing 
-   information on ISUP and MNP. 
-    
-    
-15. Authors' Addresses 
-    
-   Mark D. Foster 
-   NeuStar, Inc. 
-   1120 Vermont Avenue, NW, 
-   Suite 400 
-   Washington, D.C. 20005 
-   United States 
-  
-Foster,McGarry,Yu           Expired on August 31, 2002        [Page 25] 
-
-Number Portability in the GSTN: An Overview              March 1, 2002 
- 
- 
-    
-   Phone: +1-202-533-2800 
-   Fax:   +1-202-533-2987 
-   Email: mark.foster@neustar.biz 
-          
-   Tom McGarry 
-   NeuStar, Inc. 
-   1120 Vermont Avenue, NW, 
-   Suite 400 
-   Washington, D.C. 20005 
-   United States 
-    
-   Phone: +1-202-533-2810 
-   Fax:   +1-202-533-2987 
-   Email: tom.mcgarry@neustar.biz 
-    
-   James Yu 
-   NeuStar, Inc. 
-   1120 Vermont Avenue, NW,  
-   Suite 400 
-   Washington, D.C. 20005 
-   United States 
-    
-   Phone: +1-202-533-2814 
-   Fax:   +1-202-533-2987 
-   Email: james.yu@neustar.biz 
-    
-    
-    
-Full Copyright Statement 
- 
-   "Copyright (C) The Internet Society (2002). All Rights Reserved. 
-    
-   This document and translations of it may be copied and furnished to 
-   others, and derivative works that comment on or otherwise explain it 
-   or assist in its implementation may be prepared, copied, published 
-   and distributed, in whole or in part, without restriction of any 
-   kind, provided that the above copyright notice and this paragraph 
-   are included on all such copies and derivative works. However, this 
-   document itself may not be modified in any way, such as by removing 
-   the copyright notice or references to the Internet Society or other 
-   Internet organizations, except as needed for the purpose of 
-   developing Internet standards in which case the procedures for 
-   copyrights defined in the Internet Standards process must be 
-   followed, or as required to translate it into languages other than 
-   English. 
-    
-   The limited permissions granted above are perpetual and will not be 
-   revoked by the Internet Society or its successors or assigns. 
-    
-
-  
-Foster,McGarry,Yu           Expired on August 31, 2002        [Page 26] 
-
-Number Portability in the GSTN: An Overview              March 1, 2002 
- 
- 
-   This document and the information contained herein is provided on an 
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
-    
-    
-Acknowledgement 
- 
-   Funding for the RFC Editor function is currently provided by the 
-   Internet Society. 
- 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-  
-Foster,McGarry,Yu           Expired on August 31, 2002        [Page 27] 
-
\ No newline at end of file
diff --git a/contrib/bind9/doc/draft/draft-ietf-ipv6-node-requirements-08.txt b/contrib/bind9/doc/draft/draft-ietf-ipv6-node-requirements-08.txt
deleted file mode 100644
index 2d5c87e..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-ipv6-node-requirements-08.txt
+++ /dev/null
@@ -1,1200 +0,0 @@
-
-
-
-
-
-
-IPv6 Working Group                                 John Loughney (ed)
-Internet-Draft                                                  Nokia
-                                                     January 14, 2004
-
-Expires: July 14, 2004
-
-
-
-                         IPv6 Node Requirements
-                draft-ietf-ipv6-node-requirements-08.txt
-
-
-
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-Abstract
-
-   This document defines requirements for IPv6 nodes.  It is expected
-   that IPv6 will be deployed in a wide range of devices and situations.
-   Specifying the requirements for IPv6 nodes allows IPv6 to function
-   well and interoperate in a large number of situations and
-   deployments.
-
-
-
-
-
-Loughney (editor)          February 16, 2004                    [Page 1]
-
-
-
-
-
-Internet-Draft
-
-
-Table of Contents
-
-   1.   Introduction
-   1.1 Requirement Language
-   1.2  Scope of this Document
-   1.3  Description of IPv6 Nodes
-   2.   Abbreviations Used in This Document
-   3.   Sub-IP Layer
-   3.1  Transmission of IPv6 Packets over Ethernet Networks - RFC2464
-   3.2  IP version 6 over PPP - RFC2472
-   3.3  IPv6 over ATM Networks - RFC2492
-   4.   IP Layer
-   4.1  Internet Protocol Version 6 - RFC2460
-   4.2  Neighbor Discovery for IPv6 - RFC2461
-   4.3  Path MTU Discovery & Packet Size
-   4.4  ICMP for the Internet Protocol Version 6 (IPv6) - RFC2463
-   4.5  Addressing
-   4.6  Multicast Listener Discovery (MLD) for IPv6 - RFC2710
-   5.   Transport and DNS
-   5.1  Transport Layer
-   5.2  DNS
-   5.3  Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
-   6.   IPv4 Support and Transition
-   6.1  Transition Mechanisms
-   7.   Mobility
-   8.   Security
-   8.1  Basic Architecture
-   8.2  Security Protocols
-   8.3  Transforms and Algorithms
-   8.4  Key Management Methods
-   9.   Router Functionality
-   9.1  General
-   10.  Network Management
-   10.1 MIBs
-   11.  Security Considerations
-   12.  References
-   12.1 Normative
-   12.2 Non-Normative
-   13.  Authors and Acknowledgements
-   14.  Editor's Address
-   Notices
-
-
-
-
-
-
-
-
-
-
-Loughney (editor)          February 16, 2004                    [Page 2]
-
-
-
-
-
-Internet-Draft
-
-
-1. Introduction
-
-   The goal of this document is to define the common functionality
-   required from both IPv6 hosts and routers.  Many IPv6 nodes will
-   implement optional or additional features, but all IPv6 nodes can be
-   expected to implement the mandatory requirements listed in this
-   document.
-
-   This document tries to avoid discussion of protocol details, and
-   references RFCs for this purpose.  In case of any conflicting text,
-   this document takes less precedence than the normative RFCs, unless
-   additional clarifying text is included in this document.
-
-   Although the document points to different specifications, it should
-   be noted that in most cases, the granularity of requirements are
-   smaller than a single specification, as many specifications define
-   multiple, independent pieces, some of which may not be mandatory.
-
-   As it is not always possible for an implementer to know the exact
-   usage of IPv6 in a node, an overriding requirement for IPv6 nodes is
-   that they should adhere to Jon Postel's Robustness Principle:
-
-      Be conservative in what you do, be liberal in what you accept from
-      others [RFC-793].
-
-1.1 Requirement Language
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [RFC-2119].
-
-1.2 Scope of this Document
-
-   IPv6 covers many specifications.  It is intended that IPv6 will be
-   deployed in many different situations and environments.  Therefore,
-   it is important to develop the requirements for IPv6 nodes, in order
-   to ensure interoperability.
-
-   This document assumes that all IPv6 nodes meet the minimum
-   requirements specified here.
-
-1.3 Description of IPv6 Nodes
-
-   From Internet Protocol, Version 6 (IPv6) Specification [RFC-2460] we
-   have the following definitions:
-
-      Description of an IPv6 Node
-
-
-
-
-Loughney (editor)          February 16, 2004                    [Page 3]
-
-
-
-
-
-Internet-Draft
-
-
-       - a device that implements IPv6
-
-      Description of an IPv6 router
-
-       - a node that forwards IPv6 packets not explicitly addressed to
-         itself.
-
-      Description of an IPv6 Host
-
-       - any node that is not a router.
-
-2. Abbreviations Used in This Document
-
-   ATM   Asynchronous Transfer Mode
-
-   AH    Authentication Header
-
-   DAD   Duplicate Address Detection
-
-   ESP   Encapsulating Security Payload
-
-   ICMP  Internet Control Message Protocol
-
-   IKE   Internet Key Exchange
-
-   MIB   Management Information Base
-
-   MLD   Multicast Listener Discovery
-
-   MTU   Maximum Transfer Unit
-
-   NA    Neighbor Advertisement
-
-   NBMA  Non-Broadcast Multiple Access
-
-   ND    Neighbor Discovery
-
-   NS    Neighbor Solicitation
-
-   NUD   Neighbor Unreachability Detection
-
-   PPP   Point-to-Point Protocol
-
-   PVC   Permanent Virtual Circuit
-
-   SVC   Switched Virtual Circuit
-
-3. Sub-IP Layer
-
-
-
-Loughney (editor)          February 16, 2004                    [Page 4]
-
-
-
-
-
-Internet-Draft
-
-
-   An IPv6 node must include support for one or more IPv6 link-layer
-   specifications.  Which link-layer specifications are included will
-   depend upon what link-layers are supported by the hardware available
-   on the system.  It is possible for a conformant IPv6 node to support
-   IPv6 on some of its interfaces and not on others.
-
-   As IPv6 is run over new layer 2 technologies, it is expected that new
-   specifications will be issued.  This section highlights some major
-   layer 2 technologies and is not intended to be complete.
-
-3.1 Transmission of IPv6 Packets over Ethernet Networks - RFC2464
-
-   Nodes supporting IPv6 over Ethernet interfaces MUST implement
-   Transmission of IPv6 Packets over Ethernet Networks [RFC-2464].
-
-3.2 IP version 6 over PPP - RFC2472
-
-   Nodes supporting IPv6 over PPP MUST implement IPv6 over PPP [RFC-
-   2472].
-
-3.3 IPv6 over ATM Networks - RFC2492
-
-   Nodes supporting IPv6 over ATM Networks MUST implement IPv6 over ATM
-   Networks [RFC-2492].  Additionally, RFC 2492 states:
-
-      A minimally conforming IPv6/ATM driver SHALL support the PVC mode
-      of operation. An IPv6/ATM driver that supports the full SVC mode
-      SHALL also support PVC mode of operation.
-
-4. IP Layer
-
-4.1 Internet Protocol Version 6 - RFC2460
-
-   The Internet Protocol Version 6 is specified in [RFC-2460]. This
-   specification MUST be supported.
-
-   Unrecognized options in Hop-by-Hop Options or Destination Options
-   extensions MUST be processed as described in RFC 2460.
-
-   The node MUST follow the packet transmission rules in RFC 2460.
-
-   Nodes MUST always be able to send, receive and process fragment
-   headers.  All conformant IPv6 implementations MUST be capable of
-   sending and receving IPv6 packets; forwarding functionality MAY be
-   supported
-
-   RFC 2460 specifies extension headers and the processing for these
-   headers.
-
-
-
-Loughney (editor)          February 16, 2004                    [Page 5]
-
-
-
-
-
-Internet-Draft
-
-
-      A full implementation of IPv6 includes implementation of the
-      following extension headers: Hop-by-Hop Options, Routing (Type 0),
-      Fragment, Destination Options, Authentication and Encapsulating
-      Security Payload. [RFC-2460]
-
-   An IPv6 node MUST be able to process these headers.  It should be
-   noted that there is some discussion about the use of Routing Headers
-   and possible security threats [IPv6-RH] caused by them.
-
-4.2 Neighbor Discovery for IPv6 - RFC2461
-
-   Neighbor Discovery SHOULD be supported.  RFC 2461 states:
-
-      "Unless specified otherwise (in a document that covers operating
-      IP over a particular link type) this document applies to all link
-      types. However, because ND uses link-layer multicast for some of
-      its services, it is possible that on some link types (e.g., NBMA
-      links) alternative protocols or mechanisms to implement those
-      services will be specified (in the appropriate document covering
-      the operation of IP over a particular link type).  The services
-      described in this document that are not directly dependent on
-      multicast, such as Redirects, Next-hop determination, Neighbor
-      Unreachability Detection, etc., are expected to be provided as
-      specified in this document.  The details of how one uses ND on
-      NBMA links is an area for further study."
-
-   Some detailed analysis of Neighbor Discovery follows:
-
-   Router Discovery is how hosts locate routers that reside on an
-   attached link. Router Discovery MUST be supported for
-   implementations.
-
-   Prefix Discovery is how hosts discover the set of address prefixes
-   that define which destinations are on-link for an attached link.
-   Prefix discovery MUST be supported for implementations. Neighbor
-   Unreachability Detection (NUD) MUST be supported for all paths
-   between hosts and neighboring nodes. It is not required for paths
-   between routers.  However, when a node receives a unicast Neighbor
-   Solicitation (NS) message (that may be a NUD's NS), the node MUST
-   respond to it (i.e. send a unicast Neighbor Advertisement).
-
-   Duplicate Address Detection MUST be supported on all links supporting
-   link-layer multicast (RFC2462 section 5.4 specifies DAD MUST take
-   place on all unicast addresses).
-
-   A host implementation MUST support sending Router Solicitations.
-
-   Receiving and processing Router Advertisements MUST be supported for
-
-
-
-Loughney (editor)          February 16, 2004                    [Page 6]
-
-
-
-
-
-Internet-Draft
-
-
-   host implementations. The ability to understand specific Router
-   Advertisement options is dependent on supporting the specification
-   where the RA is specified.
-
-   Sending and Receiving Neighbor Solicitation (NS) and Neighbor
-   Advertisement (NA) MUST be supported. NS and NA messages are required
-   for Duplicate Address Detection (DAD).
-
-   Redirect functionality SHOULD be supported. If the node is a router,
-   Redirect functionality MUST be supported.
-
-4.3 Path MTU Discovery & Packet Size
-
-4.3.1 Path MTU Discovery - RFC1981
-
-   Path MTU Discovery [RFC-1981] SHOULD be supported, though minimal
-   implementations MAY choose to not support it and avoid large packets.
-   The rules in RFC 2460 MUST be followed for packet fragmentation and
-   reassembly.
-
-4.3.2 IPv6 Jumbograms - RFC2675
-
-   IPv6 Jumbograms [RFC-2675] MAY be supported.
-
-4.4  ICMP for the Internet Protocol Version 6 (IPv6) - RFC2463
-
-   ICMPv6 [RFC-2463] MUST be supported.
-
-4.5 Addressing
-
-4.5.1 IP Version 6 Addressing Architecture - RFC3513
-
-   The IPv6 Addressing Architecture [RFC-3513] MUST be supported.
-
-4.5.2 IPv6 Stateless Address Autoconfiguration - RFC2462
-
-   IPv6 Stateless Address Autoconfiguration is defined in [RFC-2462].
-   This specification MUST be supported for nodes that are hosts.
-
-   Nodes that are routers MUST be able to generate link local addresses
-   as described in RFC 2462 [RFC-2462].
-
-   From 2462:
-
-      The autoconfiguration process specified in this document applies
-      only to hosts and not routers. Since host autoconfiguration uses
-      information advertised by routers, routers will need to be
-      configured by some other means. However, it is expected that
-
-
-
-Loughney (editor)          February 16, 2004                    [Page 7]
-
-
-
-
-
-Internet-Draft
-
-
-      routers will generate link-local addresses using the mechanism
-      described in this document. In addition, routers are expected to
-      successfully pass the Duplicate Address Detection procedure
-      described in this document on all addresses prior to assigning
-      them to an interface.
-
-   Duplicate Address Detection (DAD) MUST be supported.
-
-4.5.3 Privacy Extensions for Address Configuration in IPv6 - RFC3041
-
-   Privacy Extensions for Stateless Address Autoconfiguration [RFC-3041]
-   SHOULD be supported.  It is recommended that this behavior be
-   configurable on a connection basis within each application when
-   available.  It is noted that a number of applications do not work
-   with addresses generated with this method, while other applications
-   work quite well with them.
-
-4.5.4 Default Address Selection for IPv6 - RFC3484
-
-   The rules specified in the Default Address Selection for IPv6 [RFC-
-   3484] document MUST be implemented. It is expected that IPv6 nodes
-   will need to deal with multiple addresses.
-
-4.5.5 Stateful Address Autoconfiguration
-
-   Stateful Address Autoconfiguration MAY be supported. DHCPv6 [RFC-
-   3315] is the standard stateful address configuration protocol; see
-   section 5.3 for DHCPv6 support.
-
-   Nodes which do not support Stateful Address Autoconfiguration may be
-   unable to obtain any IPv6 addresses aside from link-local addresses
-   when it receives a router advertisement with the 'M' flag (Managed
-   address configuration) set and which contains no prefixes advertised
-   for Stateless Address Autoconfiguration (see section 4.5.2).
-   Additionally, such nodes will be unable to obtain other configuration
-   information such as the addresses of DNS servers when it is connected
-   to a link over which the node receives a router advertisement in
-   which the 'O' flag ("Other stateful configuration") is set.
-
-4.6 Multicast Listener Discovery (MLD) for IPv6 - RFC2710
-
-   Nodes that need to join multicast groups SHOULD implement MLDv2
-   [MLDv2]. However, if the node has applications, which only need
-   support for Any- Source Multicast [RFC3569], the node MAY implement
-   MLDv1 [MLDv1] instead. If the node has applications, which need
-   support for Source- Specific Multicast [RFC3569, SSMARCH], the node
-   MUST support MLDv2 [MLDv2].
-
-
-
-
-Loughney (editor)          February 16, 2004                    [Page 8]
-
-
-
-
-
-Internet-Draft
-
-
-   When MLD is used, the rules in "Source Address Selection for the
-   Multicast Listener Discovery (MLD) Protocol" [RFC-3590] MUST be
-   followed.
-
-5. Transport Layer and DNS
-
-5.1 Transport Layer
-
-5.1.1 TCP and UDP over IPv6 Jumbograms - RFC2147
-
-   This specification MUST be supported if jumbograms are implemented
-   [RFC- 2675].
-
-5.2 DNS
-
-   DNS, as described in [RFC-1034], [RFC-1035], [RFC-3152], [RFC-3363]
-   and [RFC-3596] MAY be supported.  Not all nodes will need to resolve
-   names. All nodes that need to resolve names SHOULD implement stub-
-   resolver [RFC-1034] functionality, in RFC 1034 section 5.3.1 with
-   support for:
-
-    - AAAA type Resource Records [RFC-3596];
-    - reverse addressing in ip6.arpa using PTR records [RFC-3152];
-    - EDNS0 [RFC-2671] to allow for DNS packet sizes larger than 512
-      octets.
-
-   Those nodes are RECOMMENDED to support DNS security extentions
-   [DNSSEC- INTRO], [DNSSEC-REC] and [DNSSEC-PROT].
-
-   Those nodes are NOT RECOMMENDED to support the experimental A6 and
-   DNAME Resource Records [RFC-3363].
-
-5.2.2 Format for Literal IPv6 Addresses in URL's - RFC2732
-
-   RFC 2732 MUST be supported if applications on the node use URL's.
-
-5.3 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - RFC3315
-
-5.3.1 Managed Address Configuration
-
-   Those IPv6 Nodes that use DHCP for address assignment initiate DHCP
-   to obtain IPv6 addresses and other configuration information upon
-   receipt of a Router Advertisement with the 'M' flag set, as described
-   in section 5.5.3 of RFC 2462.  In addition, in the absence of a
-   router, those IPv6 Nodes that use DHCP for address assignment MUST
-   initiate DHCP to obtain IPv6 addresses and other configuration
-   information, as described in section 5.5.2 of RFC 2462.  Those IPv6
-   nodes that do not use DHCP for address assignment can ignore the 'M'
-
-
-
-Loughney (editor)          February 16, 2004                    [Page 9]
-
-
-
-
-
-Internet-Draft
-
-
-   flag in Router Advertisements.
-
-5.3.2 Other Configuration Information
-
-   Those IPv6 Nodes that use DHCP to obtain other configuration
-   information initiate DHCP for other configuration information upon
-   receipt of a Router Advertisement with the 'O' flag set, as described
-   in section 5.5.3 of RFC 2462.  Those IPv6 nodes that do not use DHCP
-   for other configuration information can ignore the 'O' flag in Router
-   Advertisements.
-
-   An IPv6 Node can use the subset of DHCP described in [DHCPv6-SL] to
-   obtain other configuration information.
-
-6. IPv4 Support and Transition
-
-   IPv6 nodes MAY support IPv4.
-
-6.1 Transition Mechanisms
-
-6.1.1 Transition Mechanisms for IPv6 Hosts and Routers - RFC2893
-
-   If an IPv6 node implements dual stack and tunneling, then RFC2893
-   MUST be supported.
-
-   RFC 2893 is currently being updated.
-
-7. Mobile IP
-
-   The Mobile IPv6 [MIPv6] specification defines requirements for the
-   following types of nodes:
-
-       - mobile nodes
-       - correspondent nodes with support for route optimization
-       - home agents
-       - all IPv6 routers
-
-   Hosts MAY support mobile node functionality described in Section 8.5
-   of [MIPv6], including support of generic packet tunneling [RFC-2473]
-   and secure home agent communications [MIPv6-HASEC].
-
-   Hosts SHOULD support route optimization requirements for
-   correspondent nodes described in Section 8.2 of [MIPv6].
-
-   Routers SHOULD support the generic mobility-related requirements for
-   all IPv6 routers described in Section 8.3 of [MIPv6]. Routers MAY
-   support the home agent functionality described in Section 8.4 of
-   [MIPv6], including support of [RFC-2473] and [MIPv6-HASEC].
-
-
-
-Loughney (editor)          February 16, 2004                   [Page 10]
-
-
-
-
-
-Internet-Draft
-
-
-8. Security
-
-   This section describes the specification of IPsec for the IPv6 node.
-
-8.1 Basic Architecture
-
-   Security Architecture for the Internet Protocol [RFC-2401] MUST be
-   supported. RFC-2401 is being updated by the IPsec Working Group.
-
-8.2 Security Protocols
-
-   ESP [RFC-2406] MUST be supported. AH [RFC-2402] MUST be supported.
-   RFC- 2406 and RFC 2402 are being updated by the IPsec Working Group.
-
-
-8.3 Transforms and Algorithms
-
-   Current IPsec RFCs specify the support of certain transforms and
-   algorithms, NULL encryption, DES-CBC, HMAC-SHA-1-96, and HMAC-MD5-96.
-   The requirements for these are discussed first, and then additional
-   algorithms 3DES-CBC, AES-128-CBC and HMAC-SHA-256-96 are discussed.
-
-   NULL encryption algorithm [RFC-2410] MUST be supported for providing
-   integrity service and also for debugging use.
-
-   The "ESP DES-CBC Cipher Algorithm With Explicit IV" [RFC-2405] SHOULD
-   NOT be supported. Security issues related to the use of DES are
-   discussed in [DESDIFF], [DESINT], [DESCRACK]. It is still listed as
-   required by the existing IPsec RFCs, but as it is currently viewed as
-   an inherently weak algorithm, and no longer fulfills its intended
-   role.
-
-   The NULL authentication algorithm [RFC-2406] MUST be supported within
-   ESP. The use of HMAC-SHA-1-96 within AH and ESP, described in [RFC-
-   2404] MUST be supported. The use of HMAC-MD5-96 within AH and ESP,
-   described in [RFC-2403] MUST be supported. An implementer MUST refer
-   to Keyed- Hashing for Message Authentication [RFC-2104].
-
-   3DES-CBC does not suffer from the issues related to DES-CBC. 3DES-CBC
-   and ESP CBC-Mode Cipher Algorithms [RFC-2451] MAY be supported. AES-
-   CBC Cipher Algorithm [RFC-3602] MUST be supported, as it is expected
-   to be a widely available, secure algorithm that is required for
-   interoperability. It is not required by the current IPsec RFCs, but
-   is expected to become required in the future.
-
-   In addition to the above requirements, "Cryptographic Algorithm
-   Implementation Requirements For ESP And AH" [CRYPTREQ] contains the
-   current set of mandatory to implement algorithms for ESP and AH as
-
-
-
-Loughney (editor)          February 16, 2004                   [Page 11]
-
-
-
-
-
-Internet-Draft
-
-
-   well as specifying algorithms that should be implemented because they
-   may be promoted to mandatory at some future time.  It is RECOMMENDED
-   that IPv6 nodes conform to the requirements in this document.
-
-8.4 Key Management Methods
-
-   Manual keying MUST be supported.
-
-   IKE [RFC-2407] [RFC-2408] [RFC-2409] MAY be supported for unicast
-   traffic. Where key refresh, anti-replay features of AH and ESP, or
-   on- demand creation of Security Associations (SAs) is required,
-   automated keying MUST be supported. Note that the IPsec WG is working
-   on the successor to IKE [IKE2]. Key management methods for multicast
-   traffic are also being worked on by the MSEC WG.
-
-   "Cryptographic Algorithms for use in the Internet Key Exchange
-   Version 2" [IKEv2ALGO] defines the current set of mandatory to
-   implement algorithms for use of IKEv2 as well as specifying
-   algorithms that should be implemented because they made be promoted
-   to mandatory at some future time. It is RECOMMENDED that IPv6 nodes
-   implementing IKEv2 conform to the requirements in this
-   document.
-
-9. Router-Specific Functionality
-
-   This section defines general host considerations for IPv6 nodes that
-   act as routers.  Currently, this section does not discuss routing-
-   specific requirements.
-
-9.1 General
-
-9.1.1 IPv6 Router Alert Option - RFC2711
-
-
-   The IPv6 Router Alert Option [RFC-2711] is an optional IPv6 Hop-by-
-   Hop Header that is used in conjunction with some protocols (e.g.,
-   RSVP [RFC- 2205], or MLD [RFC-2710]). The Router Alert option will
-   need to be implemented whenever protocols that mandate its usage are
-   implemented. See Section 4.6.
-
-9.1.2 Neighbor Discovery for IPv6 - RFC2461
-
-   Sending Router Advertisements and processing Router Solicitation MUST
-   be supported.
-
-10. Network Management
-
-   Network Management MAY be supported by IPv6 nodes.  However, for IPv6
-
-
-
-Loughney (editor)          February 16, 2004                   [Page 12]
-
-
-
-
-
-Internet-Draft
-
-
-   nodes that are embedded devices, network management may be the only
-   possibility to control these nodes.
-
-10.1 Management Information Base Modules (MIBs)
-
-   The following two MIBs SHOULD be supported by nodes that support an
-   SNMP agent.
-
-10.1.1  IP Forwarding Table MIB
-
-   IP Forwarding Table MIB [RFC-2096BIS] SHOULD be supported by nodes
-   that support an SNMP agent.
-
-10.1.2 Management Information Base for the Internet Protocol (IP)
-
-   IP MIB [RFC-2011BIS] SHOULD be supported by nodes that support an
-   SNMP agent.
-
-11. Security Considerations
-
-   This draft does not affect the security of the Internet, but
-   implementations of IPv6 are expected to support a minimum set of
-   security features to ensure security on the Internet.  "IP Security
-   Document Roadmap" [RFC-2411] is important for everyone to read.
-
-   The security considerations in RFC2460 describe the following:
-
-      The security features of IPv6 are described in the Security
-      Architecture for the Internet Protocol [RFC-2401].
-
-12. References
-
-12.1 Normative
-
-   [CRYPTREQ]     D. Eastlake 3rd, "Cryptographic Algorithm Implementa-
-                  tion Requirements For ESP And AH", draft-ietf-ipsec-
-                  esp-ah-algorithms-01.txt, January 2004.
-
-   [IKEv2ALGO]    J. Schiller, "Cryptographic Algorithms for use in the
-                  Internet Key Exchange Version 2", draft-ietf-ipsec-
-                  ikev2-algorithms-04.txt, Work in Progress.
-
-   [DHCPv6-SL]    R. Droms, "A Guide to Implementing Stateless DHCPv6
-                  Service", draft- ietf-dhc-dhcpv6-stateless-00.txt,
-                  Work in Progress.
-
-   [MIPv6]        J. Arkko, D. Johnson and C. Perkins, "Mobility Support
-                  in IPv6", draft- ietf-mobileip-ipv6-24.txt, Work in
-
-
-
-Loughney (editor)          February 16, 2004                   [Page 13]
-
-
-
-
-
-Internet-Draft
-
-
-                  progress.
-
-   [MIPv6-HASEC]  J. Arkko, V. Devarapalli and F. Dupont, "Using IPsec
-                  to Protect Mobile IPv6 Signaling between Mobile Nodes
-                  and Home Agents", draft-ietf- mobileip-mipv6-ha-
-                  ipsec-06.txt, Work in Progress.
-
-   [MLDv2]        Vida, R. et al., "Multicast Listener Discovery Version
-                  2 (MLDv2) for IPv6", draft-vida-mld-v2-07.txt, Work in
-                  Progress.
-
-   [RFC-1035]     Mockapetris, P., "Domain names - implementation and
-                  specification", STD 13, RFC 1035, November 1987.
-
-   [RFC-1981]     McCann, J., Mogul, J. and Deering, S., "Path MTU
-                  Discovery for IP version 6", RFC 1981, August 1996.
-
-   [RFC-2096BIS]  Haberman, B. and Wasserman, M., "IP Forwarding Table
-                  MIB", draft-ietf- ipv6-rfc2096-update-07.txt, Work in
-                  Progress.
-
-   [RFC-2011BIS]  Routhier, S (ed), "Management Information Base for the
-                  Internet Protocol (IP)", draft-ietf-ipv6-rfc2011-
-                  update-07.txt, Work in progress.
-
-   [RFC-2104]     Krawczyk, K., Bellare, M., and Canetti, R., "HMAC:
-                  Keyed-Hashing for Message Authentication", RFC 2104,
-                  February 1997.
-
-   [RFC-2119]     Bradner, S., "Key words for use in RFCs to Indicate
-                  Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC-2401]     Kent, S. and Atkinson, R., "Security Architecture for
-                  the Internet Protocol", RFC 2401, November 1998.
-
-   [RFC-2402]     Kent, S. and Atkinson, R.,  "IP Authentication
-                  Header", RFC 2402, November 1998.
-
-   [RFC-2403]     Madson, C., and Glenn, R., "The Use of HMAC-MD5 within
-                  ESP and AH", RFC 2403, November 1998.
-
-   [RFC-2404]     Madson, C., and Glenn, R., "The Use of HMAC-SHA-1
-                  within ESP and AH", RFC 2404, November 1998.
-
-   [RFC-2405]     Madson, C. and Doraswamy, N., "The ESP DES-CBC Cipher
-                  Algorithm With Explicit IV", RFC 2405, November 1998.
-
-   [RFC-2406]     Kent, S. and Atkinson, R., "IP Encapsulating Security
-
-
-
-Loughney (editor)          February 16, 2004                   [Page 14]
-
-
-
-
-
-Internet-Draft
-
-
-                  Protocol (ESP)", RFC 2406, November 1998.
-
-   [RFC-2407]     Piper, D., "The Internet IP Security Domain of
-                  Interpretation for ISAKMP", RFC 2407, November 1998.
-
-   [RFC-2408]     Maughan, D., Schertler, M., Schneider, M., and Turner,
-                  J., "Internet Security Association and Key Management
-                  Protocol (ISAKMP)", RFC 2408, November 1998.
-
-   [RFC-2409]     Harkins, D., and Carrel, D., "The Internet Key
-                  Exchange (IKE)", RFC 2409, November 1998.
-
-   [RFC-2410]     Glenn, R. and Kent, S., "The NULL Encryption Algorithm
-                  and Its Use With IPsec", RFC 2410, November 1998.
-
-   [RFC-2451]     Pereira, R. and Adams, R., "The ESP CBC-Mode Cipher
-                  Algorithms", RFC 2451, November 1998.
-
-   [RFC-2460]     Deering, S. and Hinden, R., "Internet Protocol, Ver-
-                  sion 6 (IPv6) Specification", RFC 2460, December 1998.
-
-   [RFC-2461]     Narten, T., Nordmark, E. and Simpson, W., "Neighbor
-                  Discovery for IP Version 6 (IPv6)", RFC 2461, December
-                  1998.
-
-   [RFC-2462]     Thomson, S. and Narten, T., "IPv6 Stateless Address
-                  Autoconfiguration", RFC 2462.
-
-   [RFC-2463]     Conta, A. and Deering, S., "ICMP for the Internet Pro-
-                  tocol Version 6 (IPv6)", RFC 2463, December 1998.
-
-   [RFC-2472]     Haskin, D. and Allen, E., "IP version 6 over PPP", RFC
-                  2472, December 1998.
-
-   [RFC-2473]     Conta, A. and Deering, S., "Generic Packet Tunneling
-                  in IPv6 Specification", RFC 2473, December 1998.  Xxx
-                  add
-
-   [RFC-2671]     Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
-                  2671, August 1999.
-
-   [RFC-2710]     Deering, S., Fenner, W. and Haberman, B., "Multicast
-                  Listener Discovery (MLD) for IPv6", RFC 2710, October
-                  1999.
-
-   [RFC-2711]     Partridge, C. and Jackson, A., "IPv6 Router Alert
-                  Option", RFC 2711, October 1999.
-
-
-
-
-Loughney (editor)          February 16, 2004                   [Page 15]
-
-
-
-
-
-Internet-Draft
-
-
-   [RFC-3041]     Narten, T. and Draves, R., "Privacy Extensions for
-                  Stateless Address Autoconfiguration in IPv6", RFC
-                  3041, January 2001.
-
-   [RFC-3152]     Bush, R., "Delegation of IP6.ARPA", RFC 3152, August
-                  2001.
-
-   [RFC-3315]     Bound, J. et al., "Dynamic Host Configuration Protocol
-                  for IPv6 (DHCPv6)", RFC 3315, July 2003.
-
-   [RFC-3363]     Bush, R., et al., "Representing Internet Protocol ver-
-                  sion 6 (IPv6) Addresses in the Domain Name System
-                  (DNS)", RFC 3363, August 2002.
-
-   [RFC-3484]     Draves, R., "Default Address Selection for IPv6", RFC
-                  3484, February 2003.
-
-   [RFC-3513]     Hinden, R. and Deering, S. "IP Version 6 Addressing
-                  Architecture", RFC 3513, April 2003.
-
-   [RFC-3590]     Haberman, B., "Source Address Selection for the Multi-
-                  cast Listener Discovery (MLD) Protocol", RFC 3590,
-                  September 2003.
-
-   [RFC-3596]     Thomson, S., et al., "DNS Extensions to support IP
-                  version 6", RFC 3596, October 2003.
-
-   [RFC-3602]     S. Frankel, "The AES-CBC Cipher Algorithm and Its Use
-                  with IPsec", RFC 3602, September 2003.
-
-12.2 Non-Normative
-
-   [ANYCAST]      Hagino, J and Ettikan K., "An Analysis of IPv6 Anycast",
-                  draft-ietf- ipngwg-ipv6-anycast-analysis-02.txt, Work in
-                  Progress.
-
-   [DESDIFF]      Biham, E., Shamir, A., "Differential Cryptanalysis of
-                  DES-like cryptosystems", Journal of Cryptology Vol 4, Jan
-                  1991.
-
-   [DESCRACK]     Cracking DES, O'Reilly & Associates, Sebastapol, CA 2000.
-   
-   [DESINT]       Bellovin, S., "An Issue With DES-CBC When Used Without
-                  Strong Integrity", Proceedings of the 32nd IETF, Danvers,
-                  MA, April 1995.
-
-   [DHCPv6-SL]    Droms, R., "A Guide to Implementing Stateless DHCPv6 Ser-
-                  vice", draft- ietf-dhc-dhcpv6-stateless-02.txt, Work in
-
-
-
-Loughney (editor)          February 16, 2004                   [Page 16]
-
-
-
-
-
-Internet-Draft
-
-
-                  Progress.
-
-   [DNSSEC-INTRO] Arends, R., Austein, R., Larson, M., Massey, D. and Rose,
-                  S., "DNS Security Introduction and Requirements" draft-
-                  ietf-dnsext-dnssec-intro- 06.txt, Work in Progress.
-
-   [DNSSEC-REC]   Arends, R., Austein, R., Larson, M., Massey, D. and Rose,
-                  S., "Resource Records for the DNS Security Extensions",
-                  draft-ietf-dnsext-dnssec- records-04.txt, Work in Pro-
-                  gress.
-
-   [DNSSEC-PROT]  Arends, R., Austein, R., Larson, M., Massey, D. and Rose,
-                  S., "Protocol Modifications for the DNS Security Exten-
-                  sions", draft-ietf-dnsext- dnssec-protocol-02.txt, Work
-                  in Progress.
-
-   [IKE2]         Kaufman, C. (ed), "Internet Key Exchange (IKEv2) Proto-
-                  col", draft-ietf- ipsec-ikev2-10.txt, Work in Progress.
-  
-   [IPv6-RH]      P. Savola, "Security of IPv6 Routing Header and Home
-                  Address Options", draft-savola-ipv6-rh-ha-security-
-                  03.txt, Work in Progress, March 2002.
-
-   [MC-THREAT]    Ballardie A. and Crowcroft, J.; Multicast-Specific Secu-
-                  rity Threats and Counter-Measures; In Proceedings "Sympo-
-                  sium on Network and Distributed System Security", Febru-
-                  ary 1995, pp.2-16.
-
-   [RFC-793]      Postel, J., "Transmission Control Protocol", RFC 793,
-                  August 1980.
-
-   [RFC-1034]     Mockapetris, P., "Domain names - concepts and facili-
-                  ties", RFC 1034, November 1987.
-
-   [RFC-2147]     Borman, D., "TCP and UDP over IPv6 Jumbograms", RFC 2147,
-                  May 1997.
-
-   [RFC-2205]     Braden, B. (ed.), Zhang, L., Berson, S., Herzog, S. and
-                  S. Jamin, "Resource ReSerVation Protocol (RSVP)", RFC
-                  2205, September 1997.
-
-   [RFC-2464]     Crawford, M., "Transmission of IPv6 Packets over Ethernet
-                  Networks", RFC 2462, December 1998.
-
-   [RFC-2492]     G. Armitage, M. Jork, P. Schulter, G. Harter, IPv6 over
-                  ATM Networks", RFC 2492, January 1999.
-
-   [RFC-2675]     Borman, D., Deering, S. and Hinden, B., "IPv6
-
-
-
-Loughney (editor)          February 16, 2004                   [Page 17]
-
-
-
-
-
-Internet-Draft
-
-
-                  Jumbograms", RFC 2675, August 1999.
-
-   [RFC-2732]     R. Hinden, B. Carpenter, L. Masinter, "Format for Literal
-                  IPv6 Addresses in URL's", RFC 2732, December 1999.
-
-   [RFC-2851]     M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder,
-                  "Textual Conventions for Internet Network Addresses", RFC
-                  2851, June 2000.
-
-   [RFC-2893]     Gilligan, R. and Nordmark, E., "Transition Mechanisms for
-                  IPv6 Hosts and Routers", RFC 2893, August 2000.
-
-   [RFC-3569]     S. Bhattacharyya, Ed., "An Overview of Source-Specific
-                  Multicast (SSM)", RFC 3569, July 2003.
-
-   [SSM-ARCH]     H. Holbrook, B. Cain, "Source-Specific Multicast for IP",
-                  draft-ietf- ssm-arch-03.txt, Work in Progress.
-
-13. Authors and Acknowledgements
-
-   This document was written by the IPv6 Node Requirements design team:
-
-      Jari Arkko
-      [jari.arkko@ericsson.com]
-
-      Marc Blanchet
-      [marc.blanchet@viagenie.qc.ca]
-
-      Samita Chakrabarti
-      [samita.chakrabarti@eng.sun.com]
-
-      Alain Durand
-      [alain.durand@sun.com]
-
-      Gerard Gastaud
-      [gerard.gastaud@alcatel.fr]
-
-      Jun-ichiro itojun Hagino
-      [itojun@iijlab.net]
-
-      Atsushi Inoue
-      [inoue@isl.rdc.toshiba.co.jp]
-
-      Masahiro Ishiyama
-      [masahiro@isl.rdc.toshiba.co.jp]
-
-      John Loughney
-      [john.loughney@nokia.com]
-
-
-
-Loughney (editor)          February 16, 2004                   [Page 18]
-
-
-
-
-
-Internet-Draft
-
-
-      Rajiv Raghunarayan
-      [raraghun@cisco.com]
-
-      Shoichi Sakane
-      [shouichi.sakane@jp.yokogawa.com]
-
-      Dave Thaler
-      [dthaler@windows.microsoft.com]
-
-      Juha Wiljakka
-      [juha.wiljakka@Nokia.com]
-
-   The authors would like to thank Ran Atkinson, Jim Bound, Brian Car-
-   penter, Ralph Droms, Christian Huitema, Adam Machalek, Thomas Narten,
-   Juha Ollila and Pekka Savola for their comments.
-
-14. Editor's Contact Information
-
-   Comments or questions regarding this document should be sent to the
-   IPv6 Working Group mailing list (ipv6@ietf.org) or to:
-
-      John Loughney
-      Nokia Research Center
-      Itamerenkatu 11-13
-      00180 Helsinki
-      Finland
-
-      Phone: +358 50 483 6242
-      Email: John.Loughney@Nokia.com
-
-Notices
-
-   The IETF takes no position regarding the validity or scope of any
-   intellectual property or other rights that might be claimed to per-
-   tain to the implementation or use of the technology described in this
-   document or the extent to which any license under such rights might
-   or might not be available; neither does it represent that it has made
-   any effort to identify any such rights.  Information on the IETF's
-   procedures with respect to rights in standards-track and standards-
-   related documentation can be found in BCP-11.  Copies of claims of
-   rights made available for publication and any assurances of licenses
-   to be made available, or the result of an attempt made to obtain a
-   general license or permission for the use of such proprietary rights
-   by implementors or users of this specification can be obtained from
-   the IETF Secretariat.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-
-
-
-Loughney (editor)          February 16, 2004                   [Page 19]
-
-
-
-
-
-Internet-Draft
-
-
-   rights, which may cover technology that may be required to practice
-   this standard.  Please address the information to the IETF Executive
-   Director.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Loughney (editor)          February 16, 2004                   [Page 20]
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-secsh-dns-05.txt b/contrib/bind9/doc/draft/draft-ietf-secsh-dns-05.txt
deleted file mode 100644
index a272d81..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-secsh-dns-05.txt
+++ /dev/null
@@ -1,614 +0,0 @@
-Secure Shell Working Group                                   J. Schlyter
-Internet-Draft                                                   OpenSSH
-Expires: March 5, 2004                                        W. Griffin
-                                                                  SPARTA
-                                                       September 5, 2003
-
-
-           Using DNS to Securely Publish SSH Key Fingerprints
-                      draft-ietf-secsh-dns-05.txt
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups. Note that other
-   groups may also distribute working documents as Internet-Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time. It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at http://
-   www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on March 5, 2004.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-Abstract
-
-   This document describes a method to verify SSH host keys using
-   DNSSEC. The document defines a new DNS resource record that contains
-   a standard SSH key fingerprint.
-
-
-
-
-
-
-
-
-
-
-
-Schlyter & Griffin       Expires March 5, 2004                  [Page 1]
-
-Internet-Draft          DNS and SSH Fingerprints          September 2003
-
-
-Table of Contents
-
-   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.    SSH Host Key Verification  . . . . . . . . . . . . . . . . .  3
-   2.1   Method . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.2   Implementation Notes . . . . . . . . . . . . . . . . . . . .  3
-   2.3   Fingerprint Matching . . . . . . . . . . . . . . . . . . . .  4
-   2.4   Authentication . . . . . . . . . . . . . . . . . . . . . . .  4
-   3.    The SSHFP Resource Record  . . . . . . . . . . . . . . . . .  4
-   3.1   The SSHFP RDATA Format . . . . . . . . . . . . . . . . . . .  5
-   3.1.1 Algorithm Number Specification . . . . . . . . . . . . . . .  5
-   3.1.2 Fingerprint Type Specification . . . . . . . . . . . . . . .  5
-   3.1.3 Fingerprint  . . . . . . . . . . . . . . . . . . . . . . . .  5
-   3.2   Presentation Format of the SSHFP RR  . . . . . . . . . . . .  6
-   4.    Security Considerations  . . . . . . . . . . . . . . . . . .  6
-   5.    IANA Considerations  . . . . . . . . . . . . . . . . . . . .  7
-         Normative References . . . . . . . . . . . . . . . . . . . .  8
-         Informational References . . . . . . . . . . . . . . . . . .  8
-         Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  9
-   A.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  9
-         Intellectual Property and Copyright Statements . . . . . . . 10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter & Griffin       Expires March 5, 2004                  [Page 2]
-
-Internet-Draft          DNS and SSH Fingerprints          September 2003
-
-
-1. Introduction
-
-   The SSH [6] protocol provides secure remote login and other secure
-   network services over an insecure network.  The security of the
-   connection relies on the server authenticating itself to the client
-   as well as the user authenticating itself to the server.
-
-   If a connection is established to a server whose public key is not
-   already known to the client, a fingerprint of the key is presented to
-   the user for verification.  If the user decides that the fingerprint
-   is correct and accepts the key, the key is saved locally and used for
-   verification for all following connections. While some
-   security-conscious users verify the fingerprint out-of-band before
-   accepting the key, many users blindly accept the presented key.
-
-   The method described here can provide out-of-band verification by
-   looking up a fingerprint of the server public key in the DNS [1][2]
-   and using DNSSEC [5] to verify the lookup.
-
-   In order to distribute the fingerprint using DNS, this document
-   defines a new DNS resource record, "SSHFP", to carry the fingerprint.
-
-   Basic understanding of the DNS system [1][2] and the DNS security
-   extensions [5] is assumed by this document.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [3].
-
-2. SSH Host Key Verification
-
-2.1 Method
-
-   Upon connection to a SSH server, the SSH client MAY look up the SSHFP
-   resource record(s) for the host it is connecting to.  If the
-   algorithm and fingerprint of the key received from the SSH server
-   match the algorithm and fingerprint of one of the SSHFP resource
-   record(s) returned from DNS, the client MAY accept the identity of
-   the server.
-
-2.2 Implementation Notes
-
-   Client implementors SHOULD provide a configurable policy used to
-   select the order of methods used to verify a host key. This document
-   defines one method: Fingerprint storage in DNS. Another method
-   defined in the SSH Architecture [6] uses local files to store keys
-   for comparison. Other methods that could be defined in the future
-   might include storing fingerprints in LDAP or other databases. A
-
-
-
-Schlyter & Griffin       Expires March 5, 2004                  [Page 3]
-
-Internet-Draft          DNS and SSH Fingerprints          September 2003
-
-
-   configurable policy will allow administrators to determine which
-   methods they want to use and in what order the methods should be
-   prioritized. This will allow administrators to determine how much
-   trust they want to place in the different methods.
-
-   One specific scenario for having a configurable policy is where
-   clients do not use fully qualified host names to connect to servers.
-   In this scenario, the implementation SHOULD verify the host key
-   against a local database before verifying the key via the fingerprint
-   returned from DNS. This would help prevent an attacker from injecting
-   a DNS search path into the local resolver and forcing the client to
-   connect to a different host.
-
-2.3 Fingerprint Matching
-
-   The public key and the SSHFP resource record are matched together by
-   comparing algorithm number and fingerprint.
-
-      The public key algorithm and the SSHFP algorithm number MUST
-      match.
-
-      A message digest of the public key, using the message digest
-      algorithm specified in the SSHFP fingerprint type, MUST match the
-      SSHFP fingerprint.
-
-
-2.4 Authentication
-
-   A public key verified using this method MUST NOT be trusted if the
-   SSHFP resource record (RR) used for verification was not
-   authenticated by a trusted SIG RR.
-
-   Clients that do validate the DNSSEC signatures themselves SHOULD use
-   standard DNSSEC validation procedures.
-
-   Clients that do not validate the DNSSEC signatures themselves MUST
-   use a secure transport, e.g. TSIG [9], SIG(0) [10] or IPsec [8],
-   between themselves and the entity performing the signature
-   validation.
-
-3. The SSHFP Resource Record
-
-   The SSHFP resource record (RR) is used to store a fingerprint of a
-   SSH public host key that is associated with a Domain Name System
-   (DNS) name.
-
-   The RR type code for the SSHFP RR is TBA.
-
-
-
-
-Schlyter & Griffin       Expires March 5, 2004                  [Page 4]
-
-Internet-Draft          DNS and SSH Fingerprints          September 2003
-
-
-3.1 The SSHFP RDATA Format
-
-   The RDATA for a SSHFP RR consists of an algorithm number, fingerprint
-   type and the fingerprint of the public host key.
-
-         1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-         |   algorithm   |    fp type    |                               /
-         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               /
-         /                                                               /
-         /                          fingerprint                          /
-         /                                                               /
-         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-3.1.1 Algorithm Number Specification
-
-   This algorithm number octet describes the algorithm of the public
-   key.  The following values are assigned:
-
-          Value    Algorithm name
-          -----    --------------
-          0        reserved
-          1        RSA
-          2        DSS
-
-   Reserving other types requires IETF consensus [4].
-
-3.1.2 Fingerprint Type Specification
-
-   The fingerprint type octet describes the message-digest algorithm
-   used to calculate the fingerprint of the public key.  The following
-   values are assigned:
-
-          Value    Fingerprint type
-          -----    ----------------
-          0        reserved
-          1        SHA-1
-
-   Reserving other types requires IETF consensus [4].
-
-   For interoperability reasons, as few fingerprint types as possible
-   should be reserved.  The only reason to reserve additional types is
-   to increase security.
-
-3.1.3 Fingerprint
-
-
-
-
-Schlyter & Griffin       Expires March 5, 2004                  [Page 5]
-
-Internet-Draft          DNS and SSH Fingerprints          September 2003
-
-
-   The fingerprint is calculated over the public key blob as described
-   in [7].
-
-   The message-digest algorithm is presumed to produce an opaque octet
-   string output which is placed as-is in the RDATA fingerprint field.
-
-3.2 Presentation Format of the SSHFP RR
-
-   The RDATA of the presentation format of the SSHFP resource record
-   consists of two numbers (algorithm and fingerprint type) followed by
-   the fingerprint itself presented in hex, e.g:
-
-         host.example.  SSHFP 2 1 123456789abcdef67890123456789abcdef67890
-
-   The use of mnemonics instead of numbers is not allowed.
-
-4. Security Considerations
-
-   Currently, the amount of trust a user can realistically place in a
-   server key is proportional to the amount of attention paid to
-   verifying that the public key presented actually corresponds to the
-   private key of the server. If a user accepts a key without verifying
-   the fingerprint with something learned through a secured channel, the
-   connection is vulnerable to a man-in-the-middle attack.
-
-   The overall security of using SSHFP for SSH host key verification is
-   dependent on the security policies of the SSH host administrator and
-   DNS zone administrator (in transferring the fingerprint), detailed
-   aspects of how verification is done in the SSH implementation, and in
-   the client's diligence in accessing the DNS in a secure manner.
-
-   One such aspect is in which order fingerprints are looked up (e.g.
-   first checking local file and then SSHFP).  We note that in addition
-   to protecting the first-time transfer of host keys, SSHFP can
-   optionally be used for stronger host key protection.
-
-      If SSHFP is checked first, new SSH host keys may be distributed by
-      replacing the corresponding SSHFP in DNS.
-
-      If SSH host key verification can be configured to require SSHFP,
-      SSH host key revocation can be implemented by removing the
-      corresponding SSHFP from DNS.
-
-   As stated in Section 2.2, we recommend that SSH implementors provide
-   a policy mechanism to control the order of methods used for host key
-   verification. One specific scenario for having a configurable policy
-   is where clients use unqualified host names to connect to servers. In
-   this case, we recommend that SSH implementations check the host key
-
-
-
-Schlyter & Griffin       Expires March 5, 2004                  [Page 6]
-
-Internet-Draft          DNS and SSH Fingerprints          September 2003
-
-
-   against a local database before verifying the key via the fingerprint
-   returned from DNS. This would help prevent an attacker from injecting
-   a DNS search path into the local resolver and forcing the client to
-   connect to a different host.
-
-   A different approach to solve the DNS search path issue would be for
-   clients to use a trusted DNS search path, i.e., one not acquired
-   through DHCP or other autoconfiguration mechanisms. Since there is no
-   way with current DNS lookup APIs to tell whether a search path is
-   from a trusted source, the entire client system would need to be
-   configured with this trusted DNS search path.
-
-   Another dependency is on the implementation of DNSSEC itself.  As
-   stated in Section 2.4, we mandate the use of secure methods for
-   lookup and that SSHFP RRs are authenticated by trusted SIG RRs.  This
-   is especially important if SSHFP is to be used as a basis for host
-   key rollover and/or revocation, as described above.
-
-   Since DNSSEC only protects the integrity of the host key fingerprint
-   after it is signed by the DNS zone administrator, the fingerprint
-   must be transferred securely from the SSH host administrator to the
-   DNS zone administrator.  This could be done manually between the
-   administrators or automatically using secure DNS dynamic update [11]
-   between the SSH server and the nameserver.  We note that this is no
-   different from other key enrollment situations, e.g. a client sending
-   a certificate request to a certificate authority for signing.
-
-5. IANA Considerations
-
-   IANA needs to allocate a RR type code for SSHFP from the standard RR
-   type space (type 44 requested).
-
-   IANA needs to open a new registry for the SSHFP RR type for public
-   key algorithms.  Defined types are:
-
-         0 is reserved
-         1 is RSA
-         2 is DSA
-
-    Adding new reservations requires IETF consensus [4].
-
-   IANA needs to open a new registry for the SSHFP RR type for
-   fingerprint types.  Defined types are:
-
-         0 is reserved
-         1 is SHA-1
-
-    Adding new reservations requires IETF consensus [4].
-
-
-
-Schlyter & Griffin       Expires March 5, 2004                  [Page 7]
-
-Internet-Draft          DNS and SSH Fingerprints          September 2003
-
-
-Normative References
-
-   [1]  Mockapetris, P., "Domain names - concepts and facilities", STD
-        13, RFC 1034, November 1987.
-
-   [2]  Mockapetris, P., "Domain names - implementation and
-        specification", STD 13, RFC 1035, November 1987.
-
-   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [4]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
-        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
-
-   [5]  Eastlake, D., "Domain Name System Security Extensions", RFC
-        2535, March 1999.
-
-   [6]  Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S.
-        Lehtinen, "SSH Protocol Architecture",
-        draft-ietf-secsh-architecture-14 (work in progress), July 2003.
-
-   [7]  Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S.
-        Lehtinen, "SSH Transport Layer Protocol",
-        draft-ietf-secsh-transport-16 (work in progress), July 2003.
-
-Informational References
-
-   [8]   Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document
-         Roadmap", RFC 2411, November 1998.
-
-   [9]   Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
-         "Secret Key Transaction Authentication for DNS (TSIG)", RFC
-         2845, May 2000.
-
-   [10]  Eastlake, D., "DNS Request and Transaction Signatures (
-         SIG(0)s)", RFC 2931, September 2000.
-
-   [11]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
-         Update", RFC 3007, November 2000.
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter & Griffin       Expires March 5, 2004                  [Page 8]
-
-Internet-Draft          DNS and SSH Fingerprints          September 2003
-
-
-Authors' Addresses
-
-   Jakob Schlyter
-   OpenSSH
-   812 23rd Avenue SE
-   Calgary, Alberta  T2G 1N8
-   Canada
-
-   EMail: jakob@openssh.com
-   URI:   http://www.openssh.com/
-
-
-   Wesley Griffin
-   SPARTA
-   7075 Samuel Morse Drive
-   Columbia, MD  21046
-   USA
-
-   EMail: wgriffin@sparta.com
-   URI:   http://www.sparta.com/
-
-Appendix A. Acknowledgements
-
-   The authors gratefully acknowledge, in no particular order, the
-   contributions of the following persons:
-
-      Martin Fredriksson
-
-      Olafur Gudmundsson
-
-      Edward Lewis
-
-      Bill Sommerfeld
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter & Griffin       Expires March 5, 2004                  [Page 9]
-
-Internet-Draft          DNS and SSH Fingerprints          September 2003
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   intellectual property or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; neither does it represent that it
-   has made any effort to identify any such rights. Information on the
-   IETF's procedures with respect to rights in standards-track and
-   standards-related documentation can be found in BCP-11. Copies of
-   claims of rights made available for publication and any assurances of
-   licenses to be made available, or the result of an attempt made to
-   obtain a general license or permission for the use of such
-   proprietary rights by implementors or users of this specification can
-   be obtained from the IETF Secretariat.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights which may cover technology that may be required to practice
-   this standard. Please address the information to the IETF Executive
-   Director.
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works. However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assignees.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-
-
-
-Schlyter & Griffin       Expires March 5, 2004                 [Page 10]
-
-Internet-Draft          DNS and SSH Fingerprints          September 2003
-
-
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter & Griffin       Expires March 5, 2004                 [Page 11]
-
diff --git a/contrib/bind9/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt b/contrib/bind9/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt
deleted file mode 100644
index 3578d2a..0000000
--- a/contrib/bind9/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt
+++ /dev/null
@@ -1,519 +0,0 @@
-
-Internet Draft                                          Johan Ihren
-draft-ihren-dnsext-threshold-validation-00.txt          Autonomica
-February 2003
-Expires in six months
-
-
-                        Threshold Validation: 
-
-	 A Mechanism for Improved Trust and Redundancy for DNSSEC Keys
-
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups. Note that
-   other groups may also distribute working documents as
-   Internet-Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six
-   months and may be updated, replaced, or obsoleted by other
-   documents at any time. It is inappropriate to use Internet-Drafts
-   as reference material or to cite them other than as "work in
-   progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-
-Abstract
-
-   This memo documents a proposal for a different method of validation
-   for DNSSEC aware resolvers. The key change is that by changing from
-   a model of one Key Signing Key, KSK, at a time to multiple KSKs it
-   will be possible to increase the aggregated trust in the signed
-   keys by leveraging from the trust associated with the different
-   signees. 
-
-   By having multiple keys to chose from validating resolvers get the
-   opportunity to use local policy to reflect actual trust in
-   different keys. For instance, it is possible to trust a single,
-   particular key ultimately, while requiring multiple valid
-   signatures by less trusted keys for validation to succeed.
-   Furthermore, with multiple KSKs there are additional redundancy
-   benefits available since it is possible to roll over different KSKs
-   at different times which may make rollover scenarios easier to
-   manage.
-
-Contents
-
-	1. Terminology
-	2. Introduction and Background
-
-	3. Trust in DNSSEC Keys
-	3.1. Key Management, Split Keys and Trust Models
-	3.2. Trust Expansion: Authentication versus Authorization
-
-	4. Proposed Semantics for Signing the KEY Resource Record 
-           Set
-	4.1. Packet Size Considerations
-
-	5. Proposed Use of Multiple "Trusted Keys" in a Validating 
-           Resolver
-	5.1. Not All Possible KSKs Need to Be Trusted
-	5.2. Possible to do Threshold Validation
-	5.3. Not All Trusted Keys Will Be Available
-
-	6. Additional Benefits from Having Multiple KSKs
-	6.1. More Robust Key Rollovers
-	6.2. Evaluation of Multiple Key Distribution Mechanisms
-
-	7. Security Considerations
-	8. IANA Considerations.
-	9. References
-	9.1. Normative.
-	9.2. Informative.
-	10. Acknowledgments.
-	11. Authors' Address
-
-
-1. Terminology
-
-   The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
-   and "MAY" in this document are to be interpreted as described in
-   RFC 2119. 
-
-   The term "zone" refers to the unit of administrative control in the
-   Domain Name System. "Name server" denotes a DNS name server that is
-   authoritative (i.e. knows all there is to know) for a DNS zone,
-   typically the root zone. A "resolver", is a DNS "client", i.e. an
-   entity that sends DNS queries to authoritative nameservers and
-   interpret the results. A "validating resolver" is a resolver that
-   attempts to perform DNSSEC validation on data it retrieves by doing
-   DNS lookups.
-
-
-2. Introduction and Background
-
-   From a protocol perspective there is no real difference between
-   different keys in DNSSEC. They are all just keys. However, in
-   actual use there is lots of difference. First and foremost, most
-   DNSSEC keys have in-band verification. I.e. the keys are signed by
-   some other key, and this other key is in its turn also signed by
-   yet another key. This way a "chain of trust" is created. Such
-   chains have to end in what is referred to as a "trusted key" for
-   validation of DNS lookups to be possible. 
-
-   A "trusted key" is a the public part of a key that the resolver
-   acquired by some other means than by looking it up in DNS. The
-   trusted key has to be explicitly configured.
-
-   A node in the DNS hierarchy that issues such out-of-band "trusted
-   keys" is called a "security apex" and the trusted key for that apex
-   is the ultimate source of trust for all DNS lookups within that
-   entire subtree.
-
-   DNSSEC is designed to be able to work with more than on security
-   apex. These apexes will all share the problem of how to distribute
-   their "trusted keys" in a way that provides validating resolvers
-   confidence in the distributed keys. 
-
-   Maximizing that confidence is crucial to the usefulness of DNSSEC
-   and this document tries to address this issue.
-
-
-3. Trust in DNSSEC Keys
-
-   In the end the trust that a validating resolver will be able to put
-   in a key that it cannot validate within DNSSEC will have to be a
-   function of
-
-   	    * trust in the key issuer, aka the KSK holder
-
-	    * trust in the distribution method
-
-	    * trust in extra, out-of-band verification
-
-   The KSK holder needs to be trusted not to accidentally lose private
-   keys in public places. Furthermore it needs to be trusted to
-   perform correct identification of the ZSK holders in case they are
-   separate from the KSK holder itself.
-
-   The distribution mechanism can be more or less tamper-proof. If the
-   key holder publishes the public key, or perhaps just a secure
-   fingerprint of the key in a major newspaper it may be rather
-   difficult to tamper with. A key acquired that way may be easier to
-   trust than if it had just been downloaded from a web page.
-
-   Out-of-band verification can for instance be the key being signed
-   by a certificate issued by a known Certificate Authority that the
-   resolver has reason to trust.
-
-3.1. Simplicity vs Trust 
-
-   The fewer keys that are in use the simpler the key management
-   becomes. Therefore increasing the number of keys should only be
-   considered when the complexity is not the major concern. A perfect
-   example of this is the distinction between so called Key Signing
-   Keys, KSK, and Zone Signing Keys, ZSK. This distinction adds
-   overall complexity but simplifies real life operations and was an
-   overall gain since operational simplification was considered to be
-   a more crucial issue than the added complexity.
-
-   In the case of a security apex there are additional issues to
-   consider, among them
-
-      * maximizing trust in the KSK received out-of-band
-
-      * authenticating the legitimacy of the ZSKs used
-
-   In some cases this will be easy, since the same entity will manage
-   both ZSKs and KSKs (i.e. it will authenticate itself, somewhat
-   similar to a self-signed certificate). In some environments it will
-   be possible to get the trusted key installed in the resolver end by
-   decree (this would seem to be a likely method within corporate and
-   government environments).
-
-   In other cases, however, this will possibly not be sufficient. In
-   the case of the root zone this is obvious, but there may well be
-   other cases.
-
-3.2. Expanding the "Trust Base"
-
-   For a security apex where the ZSKs and KSK are not held by the same
-   entity the KSK will effectively authenticate the identity of
-   whoever does real operational zone signing. The amount of trust
-   that the data signed by a ZSK will get is directly dependent on
-   whether the end resolver trusts the KSK or not, since the resolver
-   has no OOB access to the public part of the ZSKs (for practical
-   reasons).
-
-   Since the KSK holder is distinct from the ZSK holder the obvious
-   question is whether it would then be possible to further improve
-   the situation by using multiple KSK holders and thereby expanding
-   the trust base to the union of that available to each individual
-   KSK holder. "Trust base" is an invented term intended to signify
-   the aggregate of Internet resolvers that will eventually choose to
-   trust a key issued by a particular KSK holder.
-
-   A crucial issue when considering trust expansion through addition
-   of multiple KSK holders is that the KSK holders are only used to
-   authenticate the ZSKs used for signing the zone. I.e. the function
-   performed by the KSK is basically:
-
-   	     "This is indeed the official ZSK holder for this zone,
-   	     I've verified this fact to the best of my abilitites."
-
-   Which can be thought of as similar to the service of a public
-   notary. I.e. the point with adding more KSK holders is to improve
-   the public trust in data signed by the ZSK holders by improving the
-   strength of available authentication. 
-
-   Therefore adding more KSK holders, each with their own trust base,
-   is by definition a good thing. More authentication is not
-   controversial. On the contrary, when it comes to authentication,
-   the more the merrier.
-
-   
-4. Proposed Semantics for Signing the KEY Resource Record Set
-
-   In DNSSEC according to RFC2535 all KEY Resource Records are used to
-   sign all authoritative data in the zone, including the KEY RRset
-   itself, since RFC2535 makes no distinction between Key Signing
-   Keys, KSK, and Zone Signing Keys, ZSK.  With Delegation Signer [DS]
-   it is possible to change this to the KEY RRset being signed with
-   all KSKs and ZSKs but the rest of the zone only being signed by the
-   ZSKs.
-
-   This proposal changes this one step further, by recommending that
-   the KEY RRset is only signed by the Key Signing Keys, KSK, and
-   explicitly not by the Zone Signing Keys, ZSK. The reason for this
-   is to maximize the amount of space in the DNS response packet that
-   is available for additional KSKs and signatures thereof. The rest
-   of the authoritative zone contents are as previously signed by only
-   the ZSKs.
-
-4.1. Packet Size Considerations
-
-   The reason for the change is to keep down the size of the aggregate
-   of KEY RRset plus SIG(KEY) that resolvers will need to acquire to
-   perform validation of data below a security apex. For DNSSEC data
-   to be returned the DNSSEC OK bit in the EDNS0 OPT Record has to be
-   set, and therefore the allowed packet size can be assumed to be at
-   least the EDNS0 minimum of 4000 bytes.
-
-   When querying for KEY + SIG(KEY) for "." (the case that is assumed
-   to be most crucial) the size of the response packet after the
-   change to only sign the KEY RR with the KSKs break down into a
-   rather large space of possibilities. Here are a few examples for
-   the possible alternatives for different numbers of KSKs and ZSKs
-   for some different key lengths (all RSA keys, with a public
-   exponent that is < 254). This is all based upon the size of the
-   response for the particular example of querying for
-   
-	". KEY IN"
-
-   with a response of entire KEY + SIG(KEY) with the authority and
-   additional sections empty:
-
-   	      ZSK/768 and KSK/1024   (real small)
-	      Max 12 KSK +  3 ZSK  at 3975
-	          10 KSK +  8 ZSK  at 3934
-		   8 KSK + 13 ZSK  at 3893
-
-	      ZSK/768 + KSK/1280
-	      MAX 10 KSK +  2 ZSK  at 3913
-	           8 KSK +  9 ZSK  at 3970
-                   6 KSK + 15 ZSK  at 3914
-
-	      ZSK/768 + KSK/1536
-	      MAX  8 KSK +  4 ZSK  at 3917
-                   7 KSK +  8 ZSK  at 3938
-                   6 KSK + 12 ZSK  at 3959
-
-              ZSK/768 + KSK/2048
-              MAX  6 KSK +  5 ZSK  at 3936
-                   5 KSK + 10 ZSK  at 3942
-
-              ZSK/1024 + KSK/1024
-              MAX 12 KSK +  2 ZSK  at 3943
-                  11 KSK +  4 ZSK  at 3930
-                  10 KSK +  6 ZSK  at 3917
-                   8 KSK + 10 ZSK  at 3891
-
-              ZSK/1024 + KSK/1536
-              MAX  8 KSK +  3 ZSK  at 3900
-                   7 KSK +  6 ZSK  at 3904
-                   6 KSK +  9 ZSK  at 3908
-
-              ZSK/1024 + KSK/2048
-              MAX  6 KSK +  4 ZSK  at 3951
-                   5 KSK +  8 ZSK  at 3972
-                   4 KSK + 12 ZSK  at 3993
-
-   Note that these are just examples and this document is not making
-   any recommendations on suitable choices of either key lengths nor
-   number of different keys employed at a security apex.
-
-   This document does however, based upon the above figures, make the
-   recommendation that at a security apex that expects to distribute
-   "trusted keys" the KEY RRset should only be signed with the KSKs
-   and not with the ZSKs to keep the size of the response packets
-   down.
-
-
-5. Proposed Use of Multiple "Trusted Keys" in a Validating Resolver
-
-   In DNSSEC according to RFC2535[RFC2535] validation is the process
-   of tracing a chain of signatures (and keys) upwards through the DNS
-   hierarchy until a "trusted key" is reached. If there is a known
-   trusted key present at a security apex above the starting point
-   validation becomes an exercise with a binary outcome: either the
-   validation succeeds or it fails. No intermediate states are
-   possible.
-
-   With multiple "trusted keys" (i.e. the KEY RRset for the security
-   apex signed by multiple KSKs) this changes into a more complicated
-   space of alternatives. From the perspective of complexity that may
-   be regarded as a change for the worse. However, from a perspective
-   of maximizing available trust the multiple KSKs add value to the
-   system.
-
-5.1. Possible to do Threshold Validation
-
-   With multiple KSKs a new option that opens for the security
-   concious resolver is to not trust a key individually. Instead the
-   resolver may decide to require the validated signatures to exceed a
-   threshold. For instance, given M trusted keys it is possible for
-   the resolver to require N-of-M signatures to treat the data as
-   validated.
-
-   I.e. with the following pseudo-configuration in a validating
-   resolver
-
-   	security-apex "." IN {
-	   keys { ksk-1 .... ;
-      	          ksk-2 .... ;
-	          ksk-3 .... ; 
-		  ksk-4 .... ;
-		  ksk-5 .... ;
-	        };
-	   validation {
-	      # Note that ksk-4 is not present below
-	      keys { ksk-1; ksk-2; ksk-3; ksk-5; }; 
-              # 3 signatures needed with 4 possible keys, aka 75%
-              needed-signatures 3;
-           };
-	};
-
-   we configure five trusted keys for the root zone, but require two
-   valid signatures for the top-most KEY for validation to
-   succeed. I.e.  threshold validation does not force multiple
-   signatures on the entire signature chain, only on the top-most
-   signature, closest to the security apex for which the resolver has
-   trusted keys.		    
-
-5.2. Not All Trusted Keys Will Be Available
-
-   With multiple KSKs held and managed by separate entities the end
-   resolvers will not always manage to get access to all possible
-   trusted keys. In the case of just a single KSK this would be fatal
-   to validation and necessary to avoid at whatever cost. But with
-   several fully trusted keys available the resolver can decide to
-   trust several of them individually. An example based upon more
-   pseudo-configuration:
-
-   	security-apex "." IN {
-	   keys { ksk-1 .... ;
-      	          ksk-2 .... ;
-	          ksk-3 .... ; 
-		  ksk-4 .... ;
-		  ksk-5 .... ;
-	        };
-	   validation {
-	      # Only these two keys are trusted independently
-	      keys { ksk-1; ksk-4; }; 
-              # With these keys a single signature is sufficient
-	      needed-signatures 1;
-           };
-	};
-
-   Here we have the same five keys and instruct the validating
-   resolver to fully trust data that ends up with just one signature
-   from by a fully trusted key.
-
-   The typical case where this will be useful is for the case where
-   there is a risk of the resolver not catching a rollover event by
-   one of the KSKs. By doing rollovers of different KSKs with
-   different schedules it is possible for a resolver to "survive"
-   missing a rollover without validation breaking. This improves
-   overall robustness from a management point of view.
-
-5.3. Not All Possible KSKs Need to Be Trusted
-
-   With just one key available it simply has to be trusted, since that
-   is the only option available. With multiple KSKs the validating
-   resolver immediately get the option of implementing a local policy
-   of only trusting some of the possible keys.
-
-   This local policy can be implemented either by simply not
-   configuring keys that are not trusted or, possibly, configure them
-   but specify to the resolver that certain keys are not to be
-   ultimately trusted alone.
-
-
-6. Additional Benefits from Having Multiple KSKs
-
-6.1. More Robust Key Rollovers
-
-   With only one KSK the rollover operation will be a delicate
-   operation since the new trusted key needs to reach every validating
-   resolver before the old key is retired. For this reason it is
-   expected that long periods of overlap will be needed.
-
-   With multiple KSKs this changes into a system where different
-   "series" of KSKs can have different rollover schedules, thereby
-   changing from one "big" rollover to several "smaller" rollovers.
-
-   If the resolver trusts several of the available keys individually
-   then even a failure to track a certain rollover operation within
-   the overlap period will not be fatal to validation since the other
-   available trusted keys will be sufficient.
-
-6.2. Evaluation of Multiple Key Distribution Mechanisms
-
-   Distribution of the trusted keys for the DNS root zone is
-   recognized to be a difficult problem that ...
-
-   With only one trusted key, from one single "source" to distribute
-   it will be difficult to evaluate what distribution mechanism works
-   best. With multiple KSKs, held by separate entitites it will be
-   possible to measure how large fraction of the resolver population
-   that is trusting what subsets of KSKs.
-
-
-7. Security Considerations
-
-   From a systems perspective the simplest design is arguably the
-   best, i.e. one single holder of both KSK and ZSKs. However, if that
-   is not possible in all cases a more complex scheme is needed where
-   additional trust is injected by using multiple KSK holders, each
-   contributing trust, then there are only two alternatives
-   available. The first is so called "split keys", where a single key
-   is split up among KSK holders, each contributing trust. The second
-   is the multiple KSK design outlined in this proposal.
-
-   Both these alternatives provide for threshold mechanisms. However
-   split keys makes the threshold integral to the key generating
-   mechanism (i.e. it will be a property of the keys how many
-   signatures are needed). In the case of multiple KSKs the threshold
-   validation is not a property of the keys but rather local policy in
-   the validating resolver. A benefit from this is that it is possible
-   for different resolvers to use different trust policies. Some may
-   configure threshold validation requiring multiple signatures and
-   specific keys (optimizing for security) while others may choose to
-   accept a single signature from a larger set of keys (optimizing for
-   redundancy). Since the security requirements are different it would
-   seem to be a good idea to make this choice local policy rather than
-   global policy.
-
-   Furthermore, a clear issue for validating resolvers will be how to
-   ensure that they track all rollover events for keys they
-   trust. Even with operlap during the rollover (which is clearly
-   needed) there is still a need to be exceedingly careful not to miss
-   any rollovers (or fail to acquire a new key) since without this
-   single key validation will fail. With multiple KSKs this operation
-   becomes more robust, since different KSKs may roll at different
-   times according to different rollover schedules and losing one key,
-   for whatever reason, will not be crucial unless the resolver
-   intentionally chooses to be completely dependent on that exact key.
-
-8. IANA Considerations.
-
-   NONE.
-
-
-9. References
-
-9.1. Normative.
-
-   [RFC2535] Domain Name System Security Extensions. D. Eastlake. 
-	     March 1999.
-
-   [RFC3090] DNS Security Extension Clarification on Zone Status. 
-	     E. Lewis.  March 2001.
-
-
-9.2. Informative.
-
-   [RFC3110] RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System
-	     (DNS). D.  Eastlake 3rd. May 2001.
-
-   [RFC3225] Indicating Resolver Support of DNSSEC. D. Conrad. 
-	     December 2001.
-
-   [DS]      Delegation Signer Resource Record. 
-	     O. Gudmundsson. October 2002. Work In Progress.
-
-10. Acknowledgments.
-
-   Bill Manning came up with the original idea of moving complexity
-   from the signing side down to the resolver in the form of threshold
-   validation. I've also had much appreciated help from (in no
-   particular order) Jakob Schlyter, Paul Vixie, Olafur Gudmundson and
-   Olaf Kolkman.
-
-
-11. Authors' Address
-Johan Ihren
-Autonomica AB
-Bellmansgatan 30
-SE-118 47 Stockholm, Sweden
-johani@autonomica.se
diff --git a/contrib/bind9/doc/draft/draft-kato-dnsop-local-zones-00.txt b/contrib/bind9/doc/draft/draft-kato-dnsop-local-zones-00.txt
deleted file mode 100644
index d857cd9..0000000
--- a/contrib/bind9/doc/draft/draft-kato-dnsop-local-zones-00.txt
+++ /dev/null
@@ -1,295 +0,0 @@
-
-
-
-Internet Engineering Task Force                         Akira Kato, WIDE
-INTERNET-DRAFT                                           Paul Vixie, ISC
-Expires: August 24, 2003                               February 24, 2003
-
-
-          Operational Guidelines for "local" zones in the DNS
-                  draft-kato-dnsop-local-zones-00.txt
-
-Status of this Memo
-
-
-This document is an Internet-Draft and is in full conformance with all
-provisions of Section 10 of RFC2026.
-
-Internet-Drafts are working documents of the Internet Engineering Task
-Force (IETF), its areas, and its working groups.  Note that other groups
-may also distribute working documents as Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six months
-and may be updated, replaced, or obsoleted by other documents at any
-time.  It is inappropriate to use Internet-Drafts as reference material
-or to cite them other than as ``work in progress.''
-
-To view the list Internet-Draft Shadow Directories, see
-http://www.ietf.org/shadow.html.
-
-Distribution of this memo is unlimited.
-
-The internet-draft will expire in 6 months.  The date of expiration will
-be August 24, 2003.
-
-
-Abstract
-
-A large number of DNS queries regarding to the "local" zones are sent
-over the Internet in every second.  This memo describes operational
-guidelines to reduce the unnecessary DNS traffic as well as the load of
-the Root DNS Servers.
-
-1.  Introduction
-
-While it has yet been described in a RFC, .local is used to provide a
-local subspace of the DNS tree.  Formal delegation process has not been
-completed for this TLD.  In spite of this informal status, .local has
-been used in many installations regardless of the awareness of the
-users.  Usually, the local DNS servers are not authoritative to the
-.local domain, they end up to send queries to the Root DNS Servers.
-
-There are several other DNS zones which describe the "local"
-information.  .localhost has been used to describe the localhost for
-more than a couple of decades and virtually all of the DNS servers are
-configured authoritative for .localhost and its reverse zone .127.in-
-
-
-KATO                    Expires: August 24, 2003                [Page 1]
-
-
-DRAFT                        DNS local zones               February 2003
-
-addr.arpa.  However, there are other "local" zones currently used in the
-Internet or Intranets connected to the Internet through NATs or similar
-devices.
-
-At a DNS server of an university in Japan, half of the DNS queries sent
-to one of the 13 Root DNS Servers were regarding to the .local.  At
-another DNS Server running in one of the Major ISPs in Japan, the 1/4
-were .local.  If those "local" queries are able to direct other DNS
-servers than Root, or they can be resolved locally, it contributes the
-reduction of the Root DNS Servers.
-
-2.  Rationale
-
-Any DNS queries regarding to "local" names should not be sent to the DNS
-servers on the Internet.
-
-3.  Operational Guidelines
-
-Those queries should be processed at the DNS servers internal to each
-site so that the severs respond with NXDOMAIN rather than sending
-queries to the DNS servers outside.
-
-The "local" names have common DNS suffixes which are listed below:
-
-3.1.  Local host related zones:
-
-Following two zones are described in [Barr, 1996] and .localhost is also
-defined in [Eastlake, 1999] .
-
-     o .localhost
-     o .127.in-addr.arpa
-
-
-Following two zones are for the loopback address in IPv6 [Hinden, 1998]
-.  While the TLD for IPv6 reverse lookup is .arpa as defined in [Bush,
-2001] , the old TLD .int has been used for this purpose for years
-[Thomson, 1995] and many implementations still use .int.  So it is
-suggested that both zones should be provided for each IPv6 reverse
-lookup zone for a while.
-
-     o 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.int
-     o 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa
-
-
-3.2.  Locally created name space
-
-While the use of .local has been proposed in several Internet-Drafts, it
-has not been described in any Internet documents with formal status.
-However, the amount of the queries for .local is much larger than
-others, it is suggested to resolve the following zone locally:
-
-
-
-
-KATO                    Expires: August 24, 2003                [Page 2]
-
-
-DRAFT                        DNS local zones               February 2003
-
-     o .local
-
-
-
-3.3.  Private or site-local addresses
-
-The following IPv4 "private" addresses [Rekhter, 1996] and IPv6 site-
-local addresses [Hinden, 1998] should be resolved locally:
-
-     o 10.in-addr.arpa
-     o 16.172.in-addr.arpa
-     o 17.172.in-addr.arpa
-     o 18.172.in-addr.arpa
-     o 19.172.in-addr.arpa
-     o 20.172.in-addr.arpa
-     o 21.172.in-addr.arpa
-     o 22.172.in-addr.arpa
-     o 23.172.in-addr.arpa
-     o 24.172.in-addr.arpa
-     o 25.172.in-addr.arpa
-     o 26.172.in-addr.arpa
-     o 27.172.in-addr.arpa
-     o 28.172.in-addr.arpa
-     o 29.172.in-addr.arpa
-     o 30.172.in-addr.arpa
-     o 31.172.in-addr.arpa
-     o 168.192.in-addr.arpa
-     o c.e.f.ip6.int
-     o d.e.f.ip6.int
-     o e.e.f.ip6.int
-     o f.e.f.ip6.int
-     o c.e.f.ip6.arpa
-     o d.e.f.ip6.arpa
-     o e.e.f.ip6.arpa
-     o f.e.f.ip6.arpa
-
-
-3.4.  Link-local addresses
-
-The link-local address blocks for IPv4 [IANA, 2002] and IPv6 [Hinden,
-1998] should be resolved locally:
-
-     o 254.169.in-addr.arpa
-     o 8.e.f.ip6.int
-     o 9.e.f.ip6.int
-     o a.e.f.ip6.int
-     o b.e.f.ip6.int
-     o 8.e.f.ip6.arpa
-     o 9.e.f.ip6.arpa
-     o a.e.f.ip6.arpa
-     o b.e.f.ip6.arpa
-
-
-
-KATO                    Expires: August 24, 2003                [Page 3]
-
-
-DRAFT                        DNS local zones               February 2003
-
-4.  Suggestions to developers
-
-4.1.  Suggestions to DNS software implementors
-
-In order to avoid unnecessary traffic, it is suggested that DNS software
-implementors provide configuration templates or default configurations
-so that the names described in the previous section are resolved locally
-rather than sent to other DNS servers in the Internet.
-
-4.2.  Suggestions to developers of NATs or similar devices
-
-There are many NAT or similar devices available in the market.
-Regardless of the availability of DNS Servers in those devices, it is
-suggested that those devices are able to filter the DNS traffic or
-respond to the DNS traffic related to "local" zones by configuration
-regardless of its ability of DNS service.  It is suggested that this
-functionality is activated by default.
-
-5.  IANA Consideration
-
-While .local TLD has yet defined officially, there are substantial
-queries to the Root DNS Servers as of writing. About 1/4 to 1/2% of the
-traffic sent to the Root DNS Servers are related to the .local zone.
-Therefore, while it is not formally defined, it is suggested that IANA
-delegates .local TLD to an organization.
-
-The AS112 Project [Vixie, ] serves authoritative DNS service for RFC1918
-address and the link-local address.  It has several DNS server instances
-around the world by using BGP Anycast [Hardie, 2002] .  So the AS112
-Project is one of the candidates to host the .local TLD.
-
-Authors' addresses
-
-     Akira Kato
-     The University of Tokyo, Information Technology Center
-     2-11-16 Yayoi Bunkyo
-     Tokyo 113-8658, JAPAN
-     Tel: +81 3-5841-2750
-     Email: kato@wide.ad.jp
-
-
-     Paul Vixie
-     Internet Software Consortium
-     950 Charter Street
-     Redwood City, CA 94063, USA
-     Tel: +1 650-779-7001
-     Email: vixie@isc.org
-
-
-
-
-
-
-
-KATO                    Expires: August 24, 2003                [Page 4]
-
-
-DRAFT                        DNS local zones               February 2003
-
-References
-
-To be filled
-
-References
-
-Barr, 1996.
-D. Barr, "Common DNS Operational and Configuration Errors" in RFC1912
-(February 1996).
-
-Eastlake, 1999.
-D. Eastlake, "Reserved Top Level DNS Names" in RFC2606 (June 1999).
-
-Hinden, 1998.
-R. Hinden and S. Deering, "IP Version 6 Addressing Architecture" in
-RFC2373 (July 1998).
-
-Bush, 2001.
-R. Bush, "Delegation of IP6.ARPA" in RFC3152 (August 2001).
-
-Thomson, 1995.
-S. Thomson and C. Huitema, "DNS Extensions to support IP version 6" in
-RFC1886 (December 1995).
-
-Rekhter, 1996.
-Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, and E. Lear,
-"Address Allocation for Private Internets" in RFC1918 (February 1996).
-
-IANA, 2002.
-IANA, "Special-Use IPv4 Addresses" in RFC3330 (September 2002).
-
-Vixie, .
-P. Vixie, "AS112 Project" in AS112. http://www.as112.net/.
-
-Hardie, 2002.
-T. Hardie, "Distributing Authoritative Name Servers via Shared Unicast
-Addresses" in RFC3258 (April 2002).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-KATO                    Expires: August 24, 2003                [Page 5]
-
diff --git a/contrib/bind9/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt b/contrib/bind9/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt
deleted file mode 100644
index f9eaf26..0000000
--- a/contrib/bind9/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt
+++ /dev/null
@@ -1,1830 +0,0 @@
-  
-  
-  
-  INTERNET-DRAFT                                       S. Daniel Park
-  Expires: October 2003                              Syam Madanapalli
-  File:                                           SAMSUNG Electronics
-  draft-park-ipv6-extensions-dns-pnp-00.txt                April 2003
-  
-  
-  
-  
-                 IPv6 Extensions for DNS Plug and Play
-  
-  
-  
-  Status of This Memo   
-  
-  This document is an Internet-Draft and is in full conformance with
-  all provisions of Section 10 of RFC2026.
-
-  Internet-Drafts are working documents of the Internet Engineering
-  Task Force (IETF), its areas, and its working groups. Note that
-  other groups may also distribute working documents as
-  Internet-Drafts.
-
-  Internet-Drafts are draft documents valid for a maximum of six
-  months and may be updated, replaced, or obsoleted by other
-  documents at any time. It is inappropriate to use Internet-Drafts
-  as reference material or to cite them other than as "work in
-  progress."
-
-  The list of current Internet-Drafts can be accessed at
-  http://www.ietf.org/ietf/1id-abstracts.txt
-
-  The list of Internet-Draft Shadow Directories can be accessed at
-  http://www.ietf.org/shadow.html.
-  
-  
-  
-  Abstract  
-  
-  This document proposes automatic configuration of domain name (FQDN)
-  for IPv6 nodes using Domain Name Auto-Configuration (called 6DNAC) as
-  a part of IPv6 plug and play feature. 6DNAC allows the automatic
-  registration of domain name and corresponding IPv6 Addresses with
-  the DNS server. In order to provide 6DNAC function, Neighbor Discovery
-  Protocol [2461] will be used. Moreover, 6DNAC does not require any
-  changes to the existing DNS system.
-  
-  
-  Table of Contents 
-  
-  1.       Introduction .............................................  3
-  2.       Terminology ..............................................  3
-  3.       6DNAC Design Principles ..................................  4
-  4.       6DNAC Overview ...........................................  4
-  5.       6DNAC Requirements .......................................  5
-  5.1.     6DANR Client Requirements ................................  5
-  5.2.     6DNAC Server Requirements ................................  6
-    
-Park & Madanapalli             Expires October 2003             [Page 1]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003    
-    
-  6.       6DNAC Messages and Option Formats ........................  6
-  6.1.     Router Advertisement (RA) Message Format .................  6
-  6.2.     Neighbor Solicitation (NS) Message Format ................  7
-  6.3.     Neighbor Advertisement (NA) Message Format ...............  8
-  6.4.     Option Formats ...........................................  8
-  6.4.1.   DNS Zone Suffix Information Option Format ................  8
-  6.4.2.   Domain Name (FQDN) Option Format .........................  9
-  6.4.3.   Router Alert Option for 6DNAC ............................ 10
-  7.       6DNAC Operation .......................................... 10
-  7.1.     6DNAC Network Topology ................................... 11
-  7.2.     6DNAC Operational Scenarios .............................. 12
-  7.2.1.   Domain Name Registration-Success Case .................... 12
-  7.2.2.   Domain Name Registration-with DupAddrDetectTransmits=2.... 14
-  7.2.3.   Domain Name Registration-Defend Case ..................... 16
-  7.2.4.   Domain Name Registration in Retry Mode ................... 19
-  7.2.5.   Domain Name Registration when DAD Fails .................. 20
-  7.3.     DNS Zone Suffix Discovery and FQDN Construction .......... 22
-  7.3.1.   Sending Router Advertisement Messages .................... 22
-  7.3.2.   Processing Router Advertisement Messages ................. 22
-  7.3.3.   FQDN Lifetime expiry ..................................... 23
-  7.3.4.   Host Naming Algorithm .................................... 23
-  7.4.     Duplicate Domain Name Detection .......................... 23
-  7.4.1.   DAD with All Nodes Multicast Address ..................... 24
-  7.4.1.1. Sending Neighbor Solicitation Messages ................... 24
-  7.4.1.2. Processing Neighbor Solicitation Messages ................ 24
-  7.4.1.3. Sending Neighbor Advertisement Messages .................. 25
-  7.4.1.4. Processing Neighbor Advertisement Messages ............... 25
-  7.4.1.5. Pros and Cons ............................................ 25
-  7.4.2.   DAD with Router Alert Option for 6DNAC ................... 25
-  7.4.2.1. Sending Neighbor Solicitation Messages ................... 25
-  7.4.2.2. Processing Neighbor Solicitation Messages ................ 26
-  7.4.2.3. Sending Neighbor Advertisement Messages .................. 26
-  7.4.2.4. Processing Neighbor Advertisement Messages ............... 26
-  7.4.2.5. Pros and Cons ............................................ 26
-  7.4.3.   Explicit Detection of Duplicate Domain Name .............. 26
-  7.4.3.1. Sending Neighbor Solicitation Messages ................... 26
-  7.4.3.2. Processing Neighbor Solicitation Messages ................ 26
-  7.4.3.3. Sending Neighbor Advertisement Messages .................. 27
-  7.4.3.4. Processing Neighbor Advertisement Messages ............... 27
-  7.4.3.5. Pros and Cons ............................................ 27
-  7.4.4.   Retry Mode for Re-registering Domain Name ................ 27
-  7.5.     Domain Name Registration ................................. 27
-  8.       Security Consideration ................................... 27
-  9.       IANA Consideration ....................................... 28
-  10.      Acknowledgement .......................................... 28
-  11.      Intellectual Property .................................... 28
-  12.      Copyright ................................................ 28
-  13.      References ............................................... 29
-  14.      Author's Addresses ....................................... 30
-
-
-
-
-
-
-
-
-Park & Madanapalli             Expires October 2003             [Page 2]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003  
-  
-  1. Introduction 
-  
-  Today, most networks use DNS[1034][1035] for convenience. In case of
-  IPv6, DNS is more important element because of IPv6 long addresses
-  which are difficult to remember. In addition, small networks like home
-  networks using IPv6, should be able to make network easily without
-  manual configuration. Also, these small networks may not have DHCP
-  Server, DNS Server etc. that are used to configure the network. This
-  document discusses IPv6 Domain Name Auto-Configuration(6DNAC) procedure
-  for generating and registering the Domain Name and IPv6 addresses with
-  the DNS Server automatically. In order to use 6DNAC, IPv6 nodes are
-  required to implement lightweight functions specified in this document.
-  6DNAC can be applied to all defined IPv6 unicast addresses except Link
-  local IPv6 addresses, viz: Site-local and Global addresses.
-  
-  6DNAC uses Neighbor Discovery Protocol [2461] with new additions
-  (defined in section 6) and DAD procedures for generating and 
-  registering the Domain Name with the DNS server automatically.
-  
-  
-  2. Terminology
-
-  6DNAC         - IPv6 Domain Name Auto Configuration. It can provide
-                  IPv6 hosts with Domain Name Generation and 
-                  Registration automatically.
-  
-  6DNAC Client  - An IPv6 node that can generate its own unique Domain
-                  Name. Section 3 identifies the new requirements that
-                  6DNAC places on an IPv6 node to be a 6DNAC node.
-                  
-  6DNAC Server  - An IPv6 node that can collect and registrate Domain
-                  Name and IPv6 addresses automatically. 6DNAC server
-                  uses the information from the DAD operation messages
-                  with newly defined options for the registration of the 
-                  Domain Name and IPv6 Addresses. Section 3 identifies
-                  the new requirements that 6DNAC places on an IPv6 
-                  node to be a 6DNAC server. Also 6DNAC server can have 
-                  various other functions depending on network 
-                  environment and the network operator. For instance 
-                  6DNAC Server can acts as a Gateway as well Home Server
-                  in Home Networks.
- 
-  DAD           - Duplicate Address Detection (is defined [2461]) 
-  
-  DFQDND        - Duplicate Domain Name Detection
-
-  FQDN          - Fully Qualified Domain Name - FQDN and Domain Name are 
-                  used interchangeably in this document.
-  
-  NA            - Neighbor Advertisement message (is defined [2461]) 
-  
-  NS            - Neighbor Solicitation message (is defined [2461])
-
-  RA            - Router Advertisement message (is defined [2461]) 
-
-  SLAAC         - Stateless Address Autoconfiguration [2462].
-
-Park & Madanapalli             Expires October 2003             [Page 3]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003  
-  
-  3. 6DNAC Design Principles
-  
-  This section discusses the design principles of 6DNAC mechanism.
-  
-  1. The new procedures for plug and play DNS should not cause changes
-     to existing DNS system. 6DNAC requires lightweight functions to be 
-     implemented only at the client side of the DNS system, and uses the 
-     existing DDNS UPDATE [2136] to communicate with DNS Servers.
-  
-  2. Introducing a new protocol will always introduce new problems. 
-     6DNAC uses the existing protocols NDP [2461] with minor extensions 
-     for generating and registering the domain name automatically 
-     without defining a new protocol
-  
-  3. Reusing proven and well understood design principles/patterns 
-     will always yield a robust system. 6DNAC is based on IPv6 Address 
-     Auotoconfiguration principle, where routers advertise the prefix
-     and host adds the interface ID to the prefix and forms the IPv6 
-     address. Domain Name (FQDN) also contains two parts: host name 
-     and DNS zone suffix. Routers can advertise the DNS zone suffix 
-     on a particular link in Router Advertisements (RA Messages) and 
-     hosts can prefix their preferred host name to the DNS zone suffix
-     and form the fully qualified domain name. Also the detection of
-     duplicate domain name is similar to Duplicate Address Detection
-     (DAD) and can be part of DAD operation itself.
-  
-  
-  4. 6DNAC Overview
-  
-  6DNAC proposes minor extensions to NDP [2461] for automatic generation
-  and registration of domain name with the DNS server. It introduces two
-  new options: DNS Zone Suffix and Fully Qualified Domain Name. DNS Zone
-  Suffix option is carried in Router Advertisement (RA) messages for
-  notifying IPv6 nodes about the valid DNS Zone Suffix on the link and
-  FQDN option in Neighbor Solicitation (NS) and Neighbor Advertisement
-  (NA) messages to detect duplicate domain name. 6DNAC consists of two
-  components: 6DNAC Client and 6DNAC Server. 6DNAC Clients generate the
-  domain name based on DNS Zone Suffix using Host Naming Algorithm (see
-  section 7.3.1) and 6DNAC Server collects and registers the DNS
-  information with the DNS Server on behalf of 6DNAC Clients.
-
-  The automatic configuration of domain name using 6DNAC consists of
-  three parts.
-
-     - DNS Zone Suffix Discovery and FQDN Construction:
-
-       IPv6 Nodes collect DNS Zone Suffix information from Router
-       Advertisements and constructs FQDN by prefixing host name to the
-       DNS Zone Suffix. The IPv6 Nodes are required to implement Host 
-       Naming Algorithm for generating host part of the FQDN in the 
-       absence of administrator.
-
-  Generation of node's FQDN within the node itself has advantages. Nodes
-  can provide forward and reverse name lookups independent of the DNS
-  System by sending queries directly to IPv6 nodes [NIQ]. Moreover Domain
-  Name is some thing that is owned by the node.
-
-Park & Madanapalli             Expires October 2003             [Page 4]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
-  
-     - Duplicate Domain Name Detection
-
-       All nodes are expected to go for DAD for all new IPv6 unicast
-       addresses, regardless of whether they are obtained through 
-       stateful, stateless or manual configuration. 6DNAC uses the DAD 
-       messages with new option for carrying the Domain Name along with 
-       the new IPv6 Address. 6DNAC Server captures this information and
-       updates DNS Server provided that the IPv6 Address and its domain
-       name are not duplicate. If the domain name is already in use, 
-       the 6DNAC server replies to the sender with FQDN Option in NA 
-       message indicating that the domain name is duplicate. Then the
-       node is expected to generate another domain name using host 
-       naming algorithm and go for DAD. This time the DAD is only for
-       duplicate domain name detection (DFQDND). In order to avoid
-       confusion with the normal NDP processing, the target address 
-       field of the NS message must carry the unspecified address 
-       in retry mode.  This can be repeated depending on number of
-       retries defined by the administrator in the host naming algorithm.
-
-  
-     - Domain Name Registration
-
-       6DNAC Server detects the DNS information (IPv6 Address and 
-       corresponding FQDN) from DAD/DFQDND messages and updates DNS 
-       Server using existing protocol DDNS UPDATE [2136] provided that
-       the IPv6 Address and its domain name are not duplicate.
-  
-  If an IPv6 Address is duplicate, the IPv6 node cannot perform
-  stateless address autoconfiguration repeatedly. Unlike IPv6 stateless 
-  address autoconfiguration, 6DNAC allows the automatic configuration of
-  domain name repeatedly if the domain name is duplicate depending on 
-  number of retries defined by the administrator in the host naming 
-  algorithm.
-  
-  
-  5. 6DNAC Requirements 
-  
-  Depending on the 6DNAC functionality, the IPv6 nodes implement, they
-  are called either 6DNAC Clients or 6DNAC Servers. The following 
-  sections lists the requirements that the 6DNAC Client and 6DNAC server
-  must support.
-   
-   
-  5.1. 6DANC Client Requirements
-  
-        - 6DNAC Client must recognize and process the following NDP 
-          extensions
-
-              - DNS Zone Suffix option in RA messages for generating its
-                domain name (FQDN).
-
-              - Domain Name option in NS and NA messages for detecting 
-                the duplicate domain name
- 
- 
- 
-
-Park & Madanapalli             Expires October 2003             [Page 5]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003 
-  
-        - It must generate its domain name (FQDN) based on the DNS 
-          suffix that it got from the router advertisement. And it must 
-          have a host naming algorithm for generating the host part of
-          the FQDN.
-
-        - If NA message is received with unspecified target address and
-          FQDN option, then the node must treat that the domain is 
-          duplicate.
-  
-  
-  5.2. 6DNAC Server Requirements
-  
-        - 6DNAC Server must recognize and process the following NDP
-          extensions
-      
-              - If the 6DNAC Server is a router on the link, then it
-                must advertise DNS Zone Suffix option in RA messages
-                for hosts to generate their domain name (FQDN).
-
-              - FQDN option in NS messages for detecting new DNS
-                information for of nodes on the link for which it
-                must update the AAAA RR and PTR RR in DNS Server.
-
-              - FQDN option in NA messages for notifying duplicate
-                domain name with unspecified target address.
-  
-        - 6DNAC server must update the DNS Server (both AAAA RR and
-          PTR RR) dynamically using DDNS UPDATE [2136].
-  
-        - 6DNAC server must cache this (newly detected) FQDN, Link
-          Layer Address, and IPv6 Address information, so that it can
-          decide whether it really needs to update DNS Server or not,
-          to avoid redundant updates. This information will also be
-          used for notifying the duplicate domain name.
-  
-  
-  6. 6DNAC Messages and Option Formats
-  
-  In order to achieve the plug and play DNS, 6DNAC proposes new 
-  extensions to the NDP [2461]. This section specifies the new
-  additions to NDP messages and formats of new options.
-  
-  
-  6.1. Router Advertisement (RA) Message Format
-  
-  Routers send out Router Advertisement (RA) message periodically, or
-  in response to a Router Solicitation. 6DNAC does not modify the format
-  of the RA message, but proposes new option (DNS Zone Suffix Information)
-  to be carried in RA messages.
-
-
-
-
-
-
-
-
-Park & Madanapalli             Expires October 2003             [Page 6]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
-  
-      0                   1                   2                   3
-      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |     Type      |     Code      |          Checksum             |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     | Cur Hop Limit |M|O|  Reserved |       Router Lifetime         |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |                         Reachable Time                        |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |                          Retrans Timer                        |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |   Options ...                                                 |
-     /                                                               /
-     |                  DNS Zone Suffix Information                  |
-     |                                                               |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-  
-  
-                          <Figure: 1 RA message>
-  
-  
-  
-  6.2. Neighbor Solicitation (NS) Message Format 
-  
-  6DNAC does not modify the format of the Neighbor Solicitation (NS)
-  message, but proposes new option (FQDN Option) to be carried in NS
-  messages. When a node is going for DAD, the node must include FQDN
-  option in NS message to participate in plug and play DNS. If the
-  node is going for Explicit Detection of Duplicate Domain Name, the
-  node must use FQDN option in NS message and unspecified address in
-  the target address field.
-  
-  
-      0                   1                   2                   3 
-      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |     Type      |     Code      |          Checksum             |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |                           Reserved                            |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |                                                               |
-     +                                                               +
-     |                                                               |
-     +                       Target Address                          +
-     |                                                               |
-     +                                                               +
-     |                                                               |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |   Options ...                                                 |
-     /                                                               /
-     |                         Domain Name                           |
-     |                                                               |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-  
-  
-                         <Figure: 2 NS message>
-  
-Park & Madanapalli             Expires October 2003             [Page 7]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003  
-  
-  6.3. Neighbor Advertisement (NA) Message Format 
-  
-  6DNAC does not modify the format of the Neighbor Advertisement (NA)
-  message, but proposes new option (FQDN Option) to be carried in NA
-  messages. 6DNAC Server sends NA message with FQDN option to 6DNAC
-  Client that is performing duplicate domain name detection in case
-  the domain name found to be duplicate.
-
-      0                   1                   2                   3
-      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |     Type      |     Code      |          Checksum             |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |R|S|O|                     Reserved                            |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |                                                               |
-     +                                                               +
-     |                                                               |
-     +                       Target Address                          +
-     |                                                               |
-     +                                                               +
-     |                                                               |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |   Options ...                                                 |
-     /                                                               /
-     |                         FQDN Option                           |
-     |                                                               |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-  
-  
-                          <Figure: 3 NA message> 
-  
-  
-  6.4 Option Formats
-  
-  6.4.1. DNS Zone Suffix Information Option Format
-  
-  IPv6 nodes require DNS Zone Suffix for constructing their FQDN.
-  6DNAC introduces new option for routers to advertise the DNS Zone
-  Suffix Information for IPv6 nodes on the link. The suffix information
-  should be configured into routers manually.
-
-      0                   1                   2                   3
-      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |     Type      |    Length     |          Reserved             |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |                          Valid Lifetime                       |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |                                                               |
-     /                       DNS Zone Suffix                         /
-     |                                                               |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-  
-  
-                   <Figure: 4 DNS Zone Suffix Information>
-
-Park & Madanapalli             Expires October 2003             [Page 8]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003  
-  
-  Type              [TBD]
-  
-  Length            8-bit unsigned integer. The length of the option
-                    (including the type and length fields) in units of
-                    8 octets.
-  
-  Reserved          This field is unused. It must be initialized to zero
-                    by the sender and must be ignored by the receiver.
-  
-  Valid Life Time   32-bit signed integer.  The maximum time, in 
-                    seconds, over which this suffix is valid. Nodes 
-                    should treat this as the life time for their domain
-                    name. Nodes should contact the source of this
-                    information before expiry of this time interval.
-                    A value of all one bits (0xFFFFFFFF) represents
-                    infinity.
-  
-  DNS Zone Suffix   The suffix part of the FQDN. The data in the DNS 
-                    Zone Suffix field should be encoded according to 
-                    DNS encoding rules specified in [1035].
-  
-  
-  
-  6.4.2. Domain Name (FQDN) Option Format
-  
-  
-      0                   1                   2                   3
-      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |     Type      |    Length     |          Reserved             |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |                          Valid Lifetime                       |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |                                                               |
-     +                                                               +
-     |                                                               |
-     +                       FQDN Target Address                     +
-     |                                                               |
-     +                                                               +
-     |                                                               |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |                                                               |
-     /                         Domain Name                           /
-     |                                                               |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-  
-  
-                      <Figure: 5 FQDN Information>
-  
-  Type                 [TBD]
-  
-  Length               8-bit unsigned integer. The length of the option
-                       (including the type and length fields) in units 
-                       of 8 octets.  It must be greater than 3.
-                       
-                       
-
-Park & Madanapalli             Expires October 2003             [Page 9]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003                       
-  
-  Reserved             This field is unused. It must be initialized to
-                       zero by the sender and must be ignored by the
-                       receiver.
-  
-  Valid Life Time      32-bit signed integer.  The maximum time, in 
-                       seconds, over which this domain name is valid
-                       6DNAC should deregister this domain name at
-                       the expiry of this interval. 6DNAC clients
-                       should send updates by the expiry of this 
-                       interval. A value of all one bits (0xFFFFFFFF)
-                       represents infinity.
-
-  FQDN Target Address  The Address for which the FQDN maps to.  It 
-                       should be same as Target Address field of the 
-                       NS message in case of DAD & duplicate FQDN are
-                       running in parallel.
-
-  Domain Name          The domain name (FQDN) of the node. The data in
-                       the domain name should be encoded according to
-                       DNS encoding rules specified in [1035].
-  
-  
-  6.4.3. Router Alert Option for 6DNAC
-
-  Router Alert Option for 6DNAC is new option within the IPv6 Hop-by-Hop
-  Header for using in NDP messages.  The presence of this option in NS
-  message informs the router that this NS message is carrying Domain
-  Name information and must be processed by the 6DNAC Server on the router.
-  6DNAC Clients can use this option for sending DAD packets instead
-  of addressing the DAD packets to the all-nodes multicast address
-  when 6DNAC Server is implemented on router.
- 
-  The Router Alert option has the following format:
-
-  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-  |0 0 0|0 0 1 0 1|0 0 0 0 0 0 1 0|        Value (2 octets)       |
-  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-                     Length = 2
-
-  Values are registered and maintained by the IANA. For 6DNAC, the 
-  value has to be assigned by IANA.
-
-  Further information about this option can be obtained from 
-  IPv6 Router Alert Option [2711].
-
-
-  7. 6DNAC Operation
-  
-  6DNAC provides mechanisms for automatic generation of domain name
-  and registering it with the DNS Server for IPv6 nodes. 6DNAC consists
-  of two components: 6DNAC Client and 6DNAC Server. All nodes that want
-  to participate in plug and play DNS are required to implement 6DNAC
-  Client functionality, and one of the IPv6 nodes is required to 
-  implement 6DNAC Server functionality. The IPv6 node that implements 
-  the 6DNAC Server functionality must know the location of the DNS 
-  Server and must be a trusted node to send DDNS UPDATE [2136] messages.
-
-Park & Madanapalli             Expires October 2003            [Page 10]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003  
-  
-  7.1. 6DNAC Network Topology
-  
-  This section identifies the possible locations for the 6DNAC Server.
-  Note that, all nodes are required to implement 6DNAC Client 
-  functionality for constructing the domain name from the DNS Zone 
-  Suffix Information advertised by the router.  Figure 6 illustrates 
-  IPv6 host (H4) implementing 6DNAC Server functionality. In this case 
-  H4 can serve only one link (that it belongs to) for automatic 
-  registration of domain name. H4 must observe the DAD packets on the 
-  link to detect the DNS information, this requires all nodes on the 
-  link must belong to same solicited node multicast address. In general,
-  this may not be the case. So the node that is going for DAD must use
-  all nodes multicast address for DAD packets, so that the 6DNAC Server
-  (H4) can observe the DAD packets, detects IPv6 address and 
-  corresponding domain name, checks if this domain name is duplicate 
-  and finally registers the domain name with the DNS Server.
- 
-  
-                          6DNAC Server
-      +---+                   +---+                     +----------+
-      | H1|                   | H4|<--- DDNS UPDATE --->|DNS Server|
-      +-+-+                   +-+-+                     +----+-----+
-        |                       |           +----+       +---/
-        |                       |           |    |      /
-     ---+-----+-----------+-----+-----------+ R1 +-----+
-              |           |                 |    |
-              |           |                 +----+
-            +-+-+       +-+-+
-            | H2|       | H3|
-            +---+       +---+
-  
-  
-  H1, H2, H3 - 6DNAC Clients
-  H4         - 6DNAC Server
-  R1         - Router
-  
-  
-                  <Figure: 6 Example of 6DNAC Topology>
-  
-  
-  Figure 7 shows the 6DNAC Server implemented on a router R1. In this
-  case a single 6DNAC server can serve multiple links for automatic
-  configuration of the domain name. This topology also has flexibility
-  of using DAD packets with Router Alert option instead of sending DAD
-  packets to all nodes multicast address. The routers are required to
-  process all the packets with Router Alert option as per [2711].
-
-  In case of Home Networks, R1 is will acts as a Home Gateway (CPE)
-  connected to ISP. R1 delegates the prefix from the ISP edge router.
-  After delegating the prefix the CPE can advertise the DNS Zone suffix
-  along with the prefix information to the nodes on the links to which
-  the router is connected to. Note that the R1 must be configured with
-  the DNS Zone suffix Information manually. 
-
-
-
-
-Park & Madanapalli             Expires October 2003            [Page 11]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
-  
-                         +---+       +---+ 
-                         | H3+       | H4|
-                         +-+-+       +-+-+
-                           |           |
-                           |   LINK2   |
-      +---+             ---+--------+--+--          +----------+
-      | H1|                         |               |DNS Server|
-      +-+-+                         |               +----+-----+
-        |                        +--+-+           -------/
-        |         LINK 1         |    |          /
-     ---+-----+------------------+ R1 +---------+
-              |                  |    |      DDNS UPDATE
-              |                  +----+
-            +-+-+             6DNAC Server
-            | H2|
-            +---+
-  
-  
-  H1, H2 - 6DNAC Clients on Link1
-  H3, H4 - 6DNAC Clients on Link2
-  R1     - Router with 6DNAC Server, serving both Link1 and Link2
-  
-  
-       <Figure: 7 Example of 6DNAC Server serving multiple links>
-  
-  
-  7.2. 6DNAC Operational Scenarios
-  
-  This section provides message sequence charts for various 6DNAC
-  operational scenarios assuming that the 6DNAC Server is implemented
-  on a router. All the scenarios assume that the normal boot up time
-  stateless address autoconfiguration of Link Local address derived
-  from the Interface Identifier has been completed successfully. And
-  it is also assumed that the router is already configured with the
-  DNS Zone Suffix Information.
-
-  
-  Legend:
-  
-  6DNAC-A, B, C  : 6DNAC Clients
-  6DNAC-S        : 6DNAC Server/Router
-  DAD            : Duplicate Address Detection
-  DFQDND         : Duplicate Domain Name Detection
-  DNS-S          : DNS Server
-  
-  
-  7.2.1. Domain Name Registration-Successful Case 
-
-  This scenario starts when a 6DNAC Client receives RA message with
-  DNS Zone Suffix and other parameters including address prefix as
-  specified in NDP [2461] and wants configure its IPv6 address (Global
-  or Site Local) and domain name. It is Assumed that the 
-  DupAddrDetectTransmits is set to 1.
-
-
-
-
-Park & Madanapalli             Expires October 2003            [Page 12]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
-  
-   +---------+      +---------+      +---------+
-   | 6DNAC-C |      | 6DNAC-S |      |  DNS-S  |
-   +----+----+      +----+----+      +----+----+
-        |                |                |
-        |     RA with    |                |
-        | DNS Suffix Opt |                |
-        |<---------------|                |
-        |       #1       |                |
-        |---+            |                |
-  Construct |#2          |                |
-    FQDN    |            |                |
-        |<--+            |                |
-DAD/DFQDND Starts        |                |
-        |                |                |
-        |                |                |
-        |    NS With     |                |
-        |    FQDN Opt    |                |
-        |--------------->|                |
-        |       #3       |                |
-        |                |                |
-        |                |------+         |
-        |          Create FQDN  | #4      |
-        |            <FQDN,C>   |         |
-        |                |<-----+         |
-        |                |                |
-        |                |  Register FQDN |
-        |                |--------------->|
-        |                |       #5       |
-        |   #6           |                |
-        |--------+       |                |
-   No Response   |       |                |
-  DFQDND-Success |       |                |
-        |<-------+       |                |
-        |                |                |
-        |                |                |
-        v                V                v  
-
-
-          <Figure: 8 Domain Name Generation and Registration>
-           
-  
-  #1. 6DNAC Server (Router) sends out router advertisement with DNS
-      Suffix information along with other parameters as specified in
-      NDP [2461].
-  
-  #2. 6DNAC Client processes the router advertisement and constructs
-      the FQDN by prefixing hostname to the DNS Zone Suffix. It also
-      constructs IPv6 address from the autoconfiguration prefix
-      information option.
-
-  #3. 6DNAC Client starts duplicate address & FQDN detection for the
-      IPv6 address & FQDN constructed and sends out a Neighbor
-      Solicitation message with FQDN option. 
-
-      Note that the DAD packets must be addressed to all nodes multicast
-      address if Router Alert option is not used. 
-      
-Park & Madanapalli             Expires October 2003            [Page 13]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003          
-
-  #4. 6DNAC Server processes the Neighbor Solicitation message sent by
-      6DNAC Client as part of duplicate FQDN detection procedure and
-      creates a FQDN entry in its FQDN Cache (assuming that there is no
-      entry <FQDN,C>), where C is Link Layer Address of the 6DNAC Client.
-
-  #5.  6DNAC Server then registers FQDN and corresponding IPv6 address
-       through the existing protocol DDNS UPDATE.
-
-  #6.  6DNAC Client times out and observes that there is no response to
-       defend its duplicate FQDN detection procedure and the node is
-       successful in configuring its domain name.
-  
-  Note that, Stateless Address Autoconfiguration DAD procedure is not
-  depicted in the following message sequence chart, which simultaneously
-  happens along with duplicate FQDN detection.
-  
-
-  7.2.2. Domain Name Registration-with DupAddrDetectTransmits=2 
-
-  This scenario starts when a 6DNAC Client receives RA message with
-  DNS Zone Suffix and other parameters including address prefix as
-  specified in NDP [2461] and wants configure its IPv6 address (Global
-  or Site Local) and domain name. The node is configured with 
-  DupAddrDetectTransmits = 2 for reliability in delivering DAD messages.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Park & Madanapalli             Expires October 2003            [Page 14]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003 
-
-   +---------+      +---------+      +---------+
-   | 6DNAC-C |      | 6DNAC-S |      |  DNS-S  |
-   +----+----+      +----+----+      +----+----+
-        |                |                |
-        |     RA with    |                |
-        | DNS Suffix Opt |                |
-        |<---------------|                |
-        |       #1       |                |
-        |---+            |                |
-  Construct |#2          |                |
-    FQDN    |            |                |
-        |<--+            |                |
-DAD/DFQDND Starts        |                |
-        |                |                |
-        |                |                |
-        |    NS With     |                |
-        |    FQDN Opt    |                |
-        |--------------->|                |
-        |       #3       |                |
-        |                |                |
-        |                |------+         |
-        |          Create FQDN  | #4      |
-        |            <FQDN,C>   |         |
-        |                |<-----+         |
-        |                |                |
-        |                |  Register FQDN |
-        |                |--------------->|
-        |                |       #5       |
-        |    NS With     |                |
-        |    FQDN Opt    |                |
-        |--------------->|                |
-        |      #6        |                |
-        |                |                |
-        |          Lookup FQDN            |
-        |          Entry exists           |
-        |                |------+         |
-        |             Ignore    | #7      |
-        |                |<-----+         |
-        |   #8           |                |
-        |--------+       |                |
-   No Response   |       |                |
-  DFQDND-Success |       |                |
-        |<-------+       |                |
-        |                |                |
-        |                |                |
-        v                V                v  
-
-  
-  
-            <Figure: 9 Verification of duplicated Domain Name>
-
-
-  Steps from #1 to #5 are same as that of scenario.7.2.1.
-  
-  #6. 6DNAC Client sends out second Neighbor Solicitation message with
-      FQDN option as part of duplicate FQDN detection.
-      
-Park & Madanapalli             Expires October 2003            [Page 15]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003      
-
-  #7. 6DNAC Server receives and observes that the FQDN Cache exactly
-      matches with that of the NS information and ignores the NS message.
-
-  #8. 6DNAC Client times out and observes that there is no response to
-      defend its duplicate FQDN detection procedure and the node is
-      successful in configuring its domain name..
-
-  
-  7.2.3. Domain Name Registration-Defend Case 
-
-  This scenario starts when two 6DNAC Client receive RA message with
-  DNS Zone Suffix and other parameters including address prefix as
-  specified in NDP [2461] and both the nodes want configure their IPv6
-  address (Global or Site Local) and domain name. In this scenario both
-  the nodes want to have same domain name.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Park & Madanapalli             Expires October 2003            [Page 16]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
-
-
-
-   +---------+      +---------+      +---------+      +---------+
-   | 6DNAC-A |      | 6DNAC-S |      | 6DNAC-B |      |  DNS-S  |
-   +----+----+      +----+----+      +----+----+      +----+----+
-        |                |                |                |
-        |     RA with    |     RA with    |                |
-        | DNS Suffix Opt | DNS Suffix Opt |                |
-        |<---------------|--------------->|                |
-        |       #1       |       #1       |                |
-        |---+            |                |---+            |
-  Construct | #2         |          Construct | #2         |
-      FQDN  |            |              FQDN  |            |
-        |<--+            |                |<--+            |
- DAD/DFQDND Starts       |         DAD/DFQDND Starts       |
-        |                |            <DELAYED>            |
-        |                |                |                |
-        |    NS with     |                |                |
-        |    FQDN Opt    |                |                |
-        |--------------->|                |                |
-        |      #3        |                |                |
-        |            No Entry             |                |
-        |                |------+         |                |
-        |          Create FQDN  | #4      |                |
-        |            <FQDN,A>   |         |                |
-        |                |<-----+         |                |
-        |                |                |                |
-        |                |         Register FQDN #5        |
-        |                |-------------------------------->|
-        |                |                |                |
-        |                |    NS with     |                |
-        |                |    FQDN Opt    |                |
-        |                |<---------------|                |
-        |                |       #6       |                |
-        |                |------+         |                |
-        |         FQDN is in use|         |                |
-        |          Defend DFQDND| #7      |                |
-        |                |<-----+         |                |
-        |                |                |                |
-        |                |    NA with     |                |
-        |                |    D-flag Set  |                |
-        |                |--------------->|                |
-        |                |       #8       |                |
-        |------+         |                |---+            |
- No Response   | #9      |            Enter   | #10        |
- DFQDND Success|         |          Retry Mode|            |
-        |<-----+         |                |<--+            |
-        |                |                |                |
-        v                v                v                v
-
-         
-       <Figure: 10 Multiple Hosts Requesting Same Domain Name>
-
-
-
-
-
-Park & Madanapalli             Expires October 2003            [Page 17]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003          
-
-  #1. 6DNAC Server (Router) sends out router advertisement with DNS
-      Suffix information.
-      
-  #2. 6DNAC Clients A&B process the router advertisement and construct
-      their FQDN by prefixing hostname to the DNS Zone Suffix.  They
-      also construct IPv6 address from the autoconfiguration prefix
-      information option.
-      
-      When each host is trying to go for DAD, all hosts must have
-      random delay to avoid the traffic congestion according to [2461].
-      So here it is assumed that 6DNAC Client-A starts DAD first and
-      6DNAC Client-B starts DAD later.
-
-  #3. 6DNAC Client-A starts duplicate address & FQDN detection for the
-      IPv6 address & FQDN constructed and sends out a Neighbor
-      Solicitation message with FQDN option.
-   
-  #4. 6DNAC Server processes the Neighbor Solicitation message sent by
-      6DNAC Client-A as part of duplicate FQDN detection procedure and
-      creates a FQDN entry in its FQDN Cache (assuming that there is no
-      entry <FQDN,A>), where A is Link Layer Address of the 6DNAC Client-A.
-
-  #5. 6DNAC Server then registers FQDN and corresponding IPv6 address
-      through the existing protocol DDNS UPDATE.
-
-  #6. 6DNAC Client-B starts duplicate address & FQDN detection for the
-      IPv6 address & FQDN constructed and sends out a Neighbor Solicitation
-      message with FQDN option. 
-
-  #7. 6DNAC Server processes the Neighbor Solicitation message sent by
-      6DNAC Client-B as part of duplicate FQDN detection procedure and 
-      finds that the domain name is already in use by the 6DNAC Client-A.
-      Hence, concludes to defend the duplicate FQDN detection of 6DNAC
-      Client-B.
-
-  #8. 6DNAC Server sends out Neighbor Advertisement message with FQDN
-      option to 6DNAC Client-B to defend its duplicate FQDN detection.
-
-  #9. 6DNAC Client-A times out and observes that there is no response to
-      defend its duplicate FQDN detection procedure and the node is 
-      successful in configuring its domain name.
-
-  #10. 6DNAC Client-B observes that there is a NA with FQDN option
-       indicating that the domain name is duplicate and enters Retry
-       Mode. In retry mode, 6DNAC Client constructs another FQDN based
-       on Host Naming Algorithm. The number of retries is defined by the
-       administrator and must be a configurable value.
-  
-
-
-
-
-
-
-
-
-
-Park & Madanapalli             Expires October 2003            [Page 18]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003  
-  
-  7.2.4. Domain Name Registration in Retry Mode
-
-  Pre-Conditions:
-
-  1. Duplicate Address Detection has succeeded 
-  2. Duplicate FQDN Detection FAILED
-  3. FQDN is the first FQDN one constructed and FAILED
-  4. FQDN2 is the second FQDN to be constructed
-  5. The Neighbor Solicitation in the 'Retry Mode'
-    carries unspecified address in its target field (NS*).
-
-   +---------+      +---------+      +---------+
-   | 6DNAC-C |      | 6DNAC-S |      |  DNS-S  |
-   +----+----+      +----+----+      +----+----+
-        |                |                |
-        |--------+       |                |
-    Construct    | #1    |                |
-    new FQDN2    |       |                |
-        |<-------+       |                |
-        |                |                |
-  DFQDND Restarts        |                |
-        |                |                |
-        |                |                |
-        |    NS* With    |                |
-        |    FQDN Opt    |                |
-        |--------------->|                |
-        |       #2       |                |
-        |                |                |
-        |            No Entry             |
-        |                |------+         |
-        |          Create FQDN  | #3      |
-        |            <FQDN2,C>  |         |
-        |                |<-----+         |
-        |                |                |
-        |                | Register FQDN2 |
-        |                |--------------->|
-        |                |       #4       |
-        |                |                |
-        |--------+       |                |
-   No Response   | #5    |                |
-  DFQDND-Success |       |                |
-        |<-------+       |                |
-        |                |                |
-        v                V                v
-
-                
-                <Figure: 11 Regeneration of Domain Name>
-                
-
-
-
-
-
-
-
-
-
-Park & Madanapalli             Expires October 2003            [Page 19]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
- 
-  #1. 6DNAC Client constructs the FQDN again as per Host Naming Algorithm,
-      the DNS Zone Suffix, and it is FQDN2.
-  #2. It then starts Duplicate Detection only for Domain Name. 6DNAC
-      Client sends out NS with FQDN option and unspecified target
-      address.
-
-  #3. 6DNAC Server processes the Retry Mode NS message and finds that
-      the FQDN2 is not in use and creates Cache entry as <FQDN2, C>.
-
-  #4. It then starts registration procedures with the DNS Server.
-
-  #5. Meanwhile, 6DNAC Client timesout and observes that there is no
-      defending NA for its DFQDND NS sent out and successfully
-      configures its domain name.
-
-
-  7.2.5. Domain Name Registration when DAD Fails
-
-  Duplicate domain name detection and subsequent registration starts 
-  if and only if the DAD for IPv6 address succeeds. If the DAD for
-  IPv6 address fails then no actions are taken for domain name. When
-  DAD fails for stateless address autoconfiguration, then the domain
-  configuration starts only when the address has been configured using 
-  Stateful Address Configuration methods and the node is going on DAD
-  for this address.
-
-  This scenario starts when a 6DNAC Client receives RA message with
-  DNS Zone Suffix and other parameters including address prefix as
-  specified in NDP [2461] and wants configure its IPv6 address (Global
-  or Site Local) and domain name.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Park & Madanapalli             Expires October 2003            [Page 20]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
-
-   +---------+      +---------+      +---------+      +---------+
-   | 6DNAC-A |      | 6DNAC-S |      | 6DNAC-B |      |  DNS-S  |
-   +----+----+      +----+----+      +----+----+      +----+----+
-        |                |                |                |
-        |                |                |                |
-        |     RA with    |                |                |
-        | DNS Suffix Opt |                |                |
-        |<---------------|                |                |
-        |       #1       |                |                |
-        |-----+          |                |                |
-    Construct |          |                |                |
-      FQDN&   | #2       |                |                |
-    IPv6 Addr |          |                |                |
-        |<----+          |                |                |
- DAD/DFQDND Starts       |                |                |
-        |                |                |                |
-        |                |                |                |
-        |    NS with     |                |                |
-        |    FQDN Opt    |                |                |
-        |--------------->+--------------->|                |
-        |       #3       |        #3      |                |
-        |            No Entry             |                |
-        |                |------+         |                |
-        |          Create FQDN  |         |                |
-        |            <FQDN,A>   | #4      |                |
-        |                |<-----+         |                |
-        |                |                |                |
-        |                |                |------+         |
-        |                |           My IPv6 Addr| #5      |
-        |                |                |<-----+         |
-        |                |   Defend DAD   |                |
-        |                |    with NA     |                |
-        |<---------------+<---------------|                |
-        |      #6        |       #6       |                |
-        |              Entry              |                |
-        |                |------+         |                |
-        |          Delete FQDN  | #7      |                |
-        |                |<-----+         |                |
-        |                |                |                |
-        |----+           |                |                |
-  DAD Failed | #8        |                |                |
- Stop DFQDND |           |                |                |
-        |<---+           |                |                |
-        |                |                |                |
-        v                v                v                v
-
-                     <Figure: 12 DAD failure>
-
-  #1. 6DNAC Server sends out Router Advertisement to 6DNAC Client-A.
-
-  #2. 6DNAC Client-A constructs IPv6 Address based on the prefix and
-      FQDN as per Host Naming Algorithm. 
-
-  #3. It then starts Duplicate address & FQDN Detection, for the newly 
-      constructed IPv6 address and FQDN, and sends out DAD/DFQDND NS
-      with FQDN option.  
-
-Park & Madanapalli             Expires October 2003            [Page 21]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003      
-
-  #4. 6DNAC Server processes the DAD/DFQDND NS message and finds 
-      that there is no entry for the FQDN in its cache. And,
-      creates Cache entry as <FQDN, A> and starts a Registration
-      timer with RegistrationWaitTime seconds.
-
-  #5. 6DNAC Client-B finds that the DAD/DFQDND-NS target address is 
-      in its unicast address list.  
-
-  #6. It then starts defending DAD by sending NA to all-nodes multicast.
-
-  #7. 6DNAC Server finds that the DAD has failed for 6DNAC Client-A.  
-      And, deletes its FQDN Cache entry <FQDN,A>.
-      
-  #8. 6DNAC Client gets defending DAD-NA and desists from DAD. 
-      And also, stops Duplicate FQDN Detection as well.
-      At this point the address must be configured using stateful 
-      methods and the domain name registration starts with the DAD
-      for the newly constructed IPv6 address.
-  
-  7.3. DNS Zone Suffix Discovery and FQDN Construction
-  
-  7.3.1. Sending Router Advertisement Messages
-
-  Routers send out Router Advertisement message periodically, 
-  or in response to a Router Solicitation. Router should include 
-  the DNS Zone Suffix Option in their advertisements. If the DNS
-  Zone Suffix changes (similar to Site Renumbering), then it should
-  advertise the Old Zone Suffix with zero Valid Lifetime and New
-  Zone Suffix with proper non-zero Valid Lifetime.  In any other
-  case, a router should not send this option twice in a single
-  router advertisement.
-
-  7.3.2. Processing Router Advertisement Messages  
-
-  For each DNS Zone Suffix Option in Router Advertisement,
-
-  a. 6DNAC node stores the Zone Suffix information in its local
-     database.  Also, constructs FQDN as per Host Naming Algorithm.
-
-  b. If the node has not configured FQDN yet,
-
-     1. If the node is going to perform DAD for either Site local or 
-        Global Address, then it should include FQDN option to perform
-        Duplicate FQDN Detection in parallel with DAD.
-
-     2. If the node has already got either Site local or Global 
-        address, then it should send out NS with FQDN option and 
-        unspecified target address to perform Duplicate FQDN 
-        Detection.
-
-  c. If the node has already configured FQDN, and if the 
-     advertisement carries two DNS Zone Suffix Options,
-     First DNS Zone Suffix should match with the configured FQDN 
-     Suffix and its Valid Lifetime must be zero. Second DNS Zone
-
-
-
-Park & Madanapalli             Expires October 2003            [Page 22]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
-
-
-     Suffix should have non-zero Valid Lifetime. In this case, the
-     node constructs new FQDN based on the new DNS Zone Suffix (from
-     second DNS Zone Suffix option), and perform Duplicate FQDN 
-     Detection with unspecified target address.  Also, it should
-     overwrite the old FQDN with the newly constructed FQDN.
-     
-
-  7.3.3. FQDN Lifetime expiry
-
-  6DNAC Server:  
-  It should delete the FQDN cache entry and should de-register from
-  the DNS Server.
-
-  6DNAC Client:
-  It should send update to 6DNAC Server by restarting the Duplicate 
-  FQDN Detection. 
-  
-  7.3.4. Host Naming Algorithm
- 
-  A node constructs FQDN by combining DNS Zone Suffix and the hostname
-  as depicted in the following diagram.
-
-     +------------------+----------------------------------+
-     |     Host Name    |          Advertised Suffix       |
-     +------------------+----------------------------------+
-
-          <Figure 13: Fully Qualified Domain Name format>
-
-  A node can choose Host Name using any of the following methods:
- 
-  a. String form of random number generated from the Interface 
-     Identifier.
-     
-  b. List of configured Host Names provided by the administrator.
-
-  
-  The number of retries must be specified in this algorithm in 
-  case of domain name duplication.
-  
-    
-  7.4. Duplicate Domain Name Detection
-  
-  The procedure for detecting duplicated FQDNs uses Neighbor
-  Solicitation and Advertisement messages as described below.
-
-  If a duplicate FQDN is detected during the procedure, the
-  FQDN cannot be assigned to the node.
-
-  An FQDN on which the DFQDND Procedure is applied is said 
-  to be tentative until the procedure has completed successfully.  
-  A tentative FQDN is not considered "assigned to the node" in the 
-  traditional sense.  That is, the node must accept Neighbor 
-  Advertisement message containing the tentative FQDN in the FQDN 
-  Option.
-
-
-Park & Madanapalli             Expires October 2003            [Page 23]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
-
-
-  It should also be noted that DFQDN must be performed prior to 
-  registering with DNS Server to prevent multiple nodes from using 
-  the same FQDN simultaneously. All the Duplicate Address Detection 
-  Neighbor Solicitation messages must carry Source Link Layer Address 
-  Option as specified in NDP [2461]. 
-
-  The detection of duplicate FQDN can be achieved through one of the
-  following three types of procedures.
-  
-  1. DAD with All Nodes Multicast Address
-  2. DAD with Router Alert Option for 6DNAC.
-  3. Explicit Detection of Duplicate Domain Name
-   
-  Even though three solutions are listed, authors prefer only one 
-  procedure to be followed in future based on further analysis and
-  comments received from others. 
-  
-  7.4.1. DAD with All Nodes Multicast Address
-  
-  7.4.1.1. Sending Neighbor Solicitation Messages
-
-  6DNAC Client sends Neighbor Solicitation Messages as part
-  of Duplicate Address Detection SLAAC [2462] with the following 
-  extra information and modifications:
-
-  a. Include FQDN Option in the DAD Neighbor Solicitation Message
-  b. Destination Address is set to All Nodes Multicast Address
-
-  There may be a case where DAD has succeeded but DFQDND is in Retry 
-  Mode. In such case, the Neighbor Solicitation must carry unspecified 
-  address in the ICMP target address field and new domain name in FQDN
-  option to re-try the registration of the domain name.
-
-  7.4.1.2. Processing Neighbor Solicitation Messages
-
-  6DNAC Clients must ignore the FQDN option found in any of the
-  neighbor solicitation messages.
-
-  6DNAC Server processes FQDN Option found in the Duplicate Address 
-  Detection Neighbor Solicitation Messages as described below:
-
-  Lookup FQDN Cache for the domain name in FQDN Option.
-
-  If the entry exists and 
-   i. Link Layer Address matches with SLLA option, this is the case, 
-      where node has changed its IPv6 address or updating the valid 
-      life time. 6DNAC Server updates its cache and also updates DNS
-      Server using DDNS-UPDATE. If there is no change in IPv6 address
-      or life time then no updates are sent to the DNS server. 
-
-  ii. Link Layer Address differs with SLLA option, defend the duplicate 
-      FQDN Detection by sending Neighbor Advertisement Message as 
-      described in $7.4.1.3$.
-
-
-
-Park & Madanapalli             Expires October 2003            [Page 24]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
-
-
-  else,
-    Lookup FQDN Cache for the Link Layer Address in SLLA Option.
-
-    If the entry exists, update the FQDN Cache and update DNS Server 
-    using DDNS-UPDATE. This is the case, where node has changed its
-    domain name (similar to Site Re-numbering).
-
-    If then entry does not exists, then it means that this is the new 
-    registration. It must create a cache entry and start Registration    
-    
-    timer with RegistrationWaitTime. At the expiry of the Registration
-    timer, it should update DNS Server with DDNS-UPDATE.
-
-  7.4.1.3. Sending Neighbor Advertisement Messages
-
-  6DNAC Server sends Neighbor Advertisement Messages as part
-  of Duplicate Address Detection SLAAC [2462] with the FQDN Option 
-  in Neighbor Advertisement message to defend duplicate FQDN 
-  detection.
-
-  There may be the case where defending of duplicate address detection 
-  is not required but defending of FQDN is required.  In such instance, 
-  the defending Neighbor Advertisement must carry FQDN and unspecified
-  address in the ICMP target address field.
-
-  7.4.1.4. Processing Neighbor Advertisement Messages
-
-  6DNAC Server must ignore the any FQDN option found any of 
-  the neighbor advertisement messages.  If the Neighbor Advertisement
-  is a DAD defending, then it must delete its FQDN Cache entry created 
-  on the reception of DAD Neighbor Solicitation message.
-
-  When 6DNAC Clients gets the duplicate address detection neighbor
-  advertisement messages with FQDN option set it means that its
-  duplicate FQDN detection failed and enters Retry Mode.
-
-  7.4.1.5. Pros and Cons
-  
-  The advantage of this procedure is that it does not need any 
-  extension header options to be included. The disadvantage of this 
-  procedure is that, it needs change in the existing DAD procedure.
-  The change is only that the DAD neighbor solicitations are to be 
-  addressed to all nodes multicast address instead of solicited 
-  node multicast address. The another disadvantage is that, it needs 
-  the existence of Duplicate Address Detection Procedure to 
-  perform duplicate FQDN detection. 
-  
-  7.4.2. DAD with Router Alert Option for 6DNAC
-
-  7.4.2.1. Sending Neighbor Solicitation Messages
-
-  6DNAC Client sends Neighbor Solicitation Messages as part
-  of Duplicate Address Detection SLAAC [2462] with the following 
-  extra information:
-
-
-Park & Madanapalli             Expires October 2003            [Page 25]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
-
-
-  a. Include Hop-by-Hop extension Header with Router Alert Option
-     for 6DNAC as described in IPv6 Router Alert Option[2711].
-
-  b. Include FQDN Option in the DAD Neighbor Solicitation Message
-
-  7.4.2.2. Processing Neighbor Solicitation Messages
-
-  This is same as described in $7.4.1.2$. 
-
-  7.4.2.3. Sending Neighbor Advertisement Messages
-
-  This is same as described in $7.4.1.3$. 
-
-  7.4.2.4. Processing Neighbor Advertisement Messages
-
-  This is same as described in $7.4.1.4$.
-
-  7.4.2.5. Pros and Cons
-
-  The advantage of this procedure is that it does not disturb
-  the existing implementation and their way of processing the 
-  packets.  The disadvantage is that, it needs the existence 
-  of Duplicate Address Detection Procedure to perform duplicate 
-  FQDN detection. Another disadvantage is that this procedure 
-  requires 6DNAC Server functionality to be implemented on Router.
-  However, in this case 6DNAC Server can serve multiple links.
-  
-  7.4.3. Explicit Detection of Duplicate Domain Name
-
-  In this procedure Duplicate FQDN Detection starts after completion
-  of successful Site local or Global Address configuration.
-  
-  7.4.3.1. Sending Neighbor Solicitation Messages
-
-  6DNAC Client sends Neighbor Solicitation Messages as part
-  of Duplicate FQDN Detection with the following information:
-
-  a. Include FQDN Option in the Neighbor Solicitation Message
-
-  b. Destination Address is set to All Nodes Multicast Address
-     or uses Router Alert Option for 6DNAC, when 6DNAC Server is 
-     implemented on router.
-
-  c. Target Address is set to Unspecified Address
-
-  d. Other fields are set as per DAD SLAAC [2462].
-
-  7.4.3.2. Processing Neighbor Solicitation Messages
-
-  This is same as described in $7.4.1.2$.
-
-
-
-
-
-
-Park & Madanapalli             Expires October 2003            [Page 26]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003 
-
-
-  7.4.3.3. Sending Neighbor Advertisement Messages
-
-  This is same as described in $7.4.1.3$.
-
-  7.4.3.4. Processing Neighbor Advertisement Messages
-
-  This is same as described in $7.4.1.4$.
-
-  7.4.3.5. Pros and Cons
-
-  The advantage of this procedure is that it does not need the
-  existing duplicate address detection procedure.  This is introduced
-  as the DAD procedure is found to be redundant in when IPv6 addresses
-  are constructed from the interface ID [DIID].
-
-  Note that, if 6DNAC Clients know the address of 6DNAC Server then
-  they can directly send DFQDND-NS to 6DNAC Server. 
-
-  7.4.4. Retry Mode for Re-registering Domain Name
-
-  In retry mode, nodes construct new FQDN as per Host Naming Algorithm.
-  Then they restart Duplicate FQDN Detection as described in $7.4.3$.
-
-
-  7.5. Domain Name Registration
-  
-  6DNAC Server must be an authenticated to update the DNS Server.
-  6DNAC Server must also be configured with the DNS Server 
-  information.
-
-  6DNAC Server detects the DNS information (IPv6 Address and 
-  corresponding FQDN) from DAD/DFQDND messages and caches the
-  information. It also have an associated Registration Timer with 
-  RegistrationWaitTime to wait for the successful completion of 
-  DFQDND and update DNS Server using existing protocol DDNS UPDATE 
-  [2136].
-  
-                 
-  8. Security Consideration
-   
-  If someone wants to hijack correct Domain Name registration, they 
-  could send a NS message with incorrect or same Domain Name to the
-  6DNAC server repeatedly and server would start the Domain Name 
-  registration through above mechanism, which is a security hole. 
-  As described in [2461], a host can check validity of NDP messages.
-  If the NDP message include an IP Authentication Header, the message
-  authenticates correctly. For DNS UPDATE processing, secure DNS
-  Dynamic Update is described in [3007].
-  
-
-
-
-
-
-
-
-Park & Madanapalli             Expires October 2003            [Page 27]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
-
-  
-  9. IANA Consideration
-  
-  Values in the Router Alert Option are registered and maintained by
-  IANA. For 6DNAC, the value has to be assigned by IANA. Also IANA is
-  required to assign the Type values for DNS Zone Suffix Information
-  option and FADN option.
-
-  
-  10. Acknowledgement
-  
-  Special thanks are due to Badrinarayana N.S. and Christian Huitema for
-  many helpful suggestions and revisions. 
-  
-  
-  11. Intellectual Property
-
-  The following notice is copied from RFC 2026 [Bradner, 1996],
-  Section 10.4, and describes the position of the IETF concerning
-  intellectual property claims made against this document.
-
-  The IETF takes no position regarding the validity or scope of any
-  intellectual property or other rights that might be claimed to
-  pertain to the implementation or use other technology described in
-
-  this document or the extent to which any license under such rights
-  might or might not be available; neither does it represent that it
-  
-  has made any effort to identify any such rights.  Information on the
-  IETF's procedures with respect to rights in standards-track and
-  standards-related documentation can be found in BCP-11.  Copies of
-  claims of rights made available for publication and any assurances
-  of licenses to be made available, or the result of an attempt made
-  to obtain a general license or permission for the use of such
-  proprietary rights by implementers or users of this specification
-  can be obtained from the IETF Secretariat.
-
-  The IETF invites any interested party to bring to its attention any
-  copyrights, patents or patent applications, or other proprietary
-  rights which may cover technology that may be required to practice
-  this standard.  Please address the information to the IETF Executive
-  Director.
-  
-  
-  12. Copyright
-
-  The following copyright notice is copied from RFC 2026 [Bradner,
-  1996], Section 10.4, and describes the applicable copyright for this
-  document.
-
-  Copyright (C) The Internet Society July 12, 2001. All Rights
-  Reserved.
-  
-  This document and translations of it may be copied and furnished to
-  others, and derivative works that comment on or otherwise explain it
-  or assist in its implementation may be prepared, copied, published
-
-Park & Madanapalli             Expires October 2003            [Page 28]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
-
-
-  and distributed, in whole or in part, without restriction of any
-  kind, provided that the above copyright notice and this paragraph
-  are included on all such copies and derivative works.  However, this
-  
-  document itself may not be modified in any way, such as by removing
-  the copyright notice or references to the Internet Society or other
-  Internet organizations, except as needed for the purpose of
-  developing Internet standards in which case the procedures for
-  copyrights defined in the Internet Standards process must be
-  followed, or as required to translate it into languages other than
-  English.
-
-  The limited permissions granted above are perpetual and will not be
-  revoked by the Internet Society or its successors or assignees.
-
-  This document and the information contained herein is provided on an
-  "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-  TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-  BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-  HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-  MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-  
-  
-  13. References
-   
-  [2373]        Hinden, R. and S. Deering, "IP Version 6 Addressing 
-                Architecture", RFC 2373, July 1998. 
-       
-  [2460]        Deering, S. abd R. Hinden, "Internet Protocol, 
-                Version 6 (IPv6) Specification", RFC 2460, 
-                December 1998. 
-               
-  [2461]        Narten, T., Nordmark, E. and W. Simpson, "Neighbor 
-                Discovery for IP version 6(IPv6)", RFC 2461, December 
-                1998. 
-
-  [2462]        S. Thomson and Narten T, "IPv6 Stateless Address Auto- 
-                Configuration", RFC 2462, December 1998. 
-               
-  [2711]        C. Patridge and A.Jackson, "IPv6 Router Alert Option",
-                RFC 2711, October 1999. 
-             
-  [1034]        P. Mockapetris, "DOMAIN NAMES - CONCEPTS AND 
-                FACILITIES", RFC 1034, November 1987. 
-               
-  [1035]        P. Mockapetris, "Domain Names - Implementation and 
-                Specification" RFC 1035, November 1987. 
-
-  [2136]        P. Vixie et al., "Dynamic Updates in the Domain Name
-                System (DNS UPDATE)", RFC2136, April 1997.
-                
-  [3007]        B. Wellington, "Secure Domain Name System (DNS) Dynamic 
-                Update", RFC 3007, November 2000.
-
-
-
-Park & Madanapalli             Expires October 2003            [Page 29]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
-
-                 
-  [DIID]        yokohama-dad-vs-diid.pdf
-                at http://playground.sun.com/ipng/presentations/July2002/
-                
-  [DNSISSUES]   Durand, A., "IPv6 DNS transition issues", draft-ietf-              
-                dnsop-ipv6-dns-issues-00.txt, work in progress.
-                
-  [PREFIX]      S. Miyakawa, R. Droms, "Requirements for IPv6 prefix
-                delegation", draft-ietf-ipv6-prefix-delegation-
-                requirement-01.txt, work in progress.
-   
-  [Autoreg]     H. Kitamura, "Domain Name Auto-Registration for 
-                Plugged-in IPv6 Nodes", draft-ietf-dnsext-ipv6-name-
-                auto-reg-00.txt, work in progress.
-
-  [NIQ]         Matt Crawford, "IPv6 Node Information Queries", <draft-
-                ietf-ipngwg-icmp-name-lookups-09.txt>, work in progress.
-                  
-  
-  14. Author's Addresses 
-  
-  Soohong Daniel Park 
-  Mobile Platform Laboratory, SAMSUNG Electronics, KOREA 
-  Phone: +82-31-200-3728 
-  Email:soohong.park@samsung.com
-  
-  Syam Madanapalli
-  Network Systems Division, SAMSUNG India Software Operations, INDIA
-  Phone: +91-80-5550555
-  Email:syam@samsung.com
-  
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Park & Madanapalli             Expires October 2003            [Page 30]
diff --git a/contrib/bind9/doc/draft/update b/contrib/bind9/doc/draft/update
deleted file mode 100644
index 6ac2090..0000000
--- a/contrib/bind9/doc/draft/update
+++ /dev/null
@@ -1,46 +0,0 @@
-#!/bin/sh
-commit=
-for i
-do
-	z=`expr "$i" : 'http://www.ietf.org/internet-drafts/\(.*\)'`
-	if test -n "$z"
-	then
-		i="$z"
-	fi
-	if test -f "$i"
-	then
-		continue
-	fi
-	pat=`echo "$i" | sed 's/...txt/??.txt/'`
-	old=`echo $pat 2> /dev/null`
-	if test "X$old" != "X$pat"
-	then
-		newer=0
-		for j in $old
-		do
-			if test $j ">" $i
-			then
-				 newer=1
-			fi
-		done
-		if test $newer = 1
-		then
-			continue;
-		fi
-	fi
-	if fetch "http://www.ietf.org/internet-drafts/$i" 
-	then
-		cvs add "$i" 
-		if test "X$old" != "X$pat"
-		then
-			rm $old
-			cvs delete $old
-			commit="$commit $old"
-		fi
-		commit="$commit $i"
-	fi
-done
-if test -n "$commit"
-then
-	cvs commit -m "new draft" $commit
-fi
diff --git a/contrib/bind9/doc/misc/Makefile.in b/contrib/bind9/doc/misc/Makefile.in
deleted file mode 100644
index 40a62fe..0000000
--- a/contrib/bind9/doc/misc/Makefile.in
+++ /dev/null
@@ -1,47 +0,0 @@
-# Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
-# Copyright (C) 2001  Internet Software Consortium.
-#
-# Permission to use, copy, modify, and/or distribute this software for any
-# purpose with or without fee is hereby granted, provided that the above
-# copyright notice and this permission notice appear in all copies.
-#
-# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
-# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
-# AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
-# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
-# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
-# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
-# PERFORMANCE OF THIS SOFTWARE.
-
-# $Id: Makefile.in,v 1.3.18.3 2007/08/28 07:20:03 tbox Exp $
-
-srcdir =	@srcdir@
-VPATH =		@srcdir@
-top_srcdir =	@top_srcdir@
-
-@BIND9_MAKE_RULES@
-
-PERL = @PERL@
-
-MANOBJS = options
-
-doc man:: ${MANOBJS}
-
-docclean manclean maintainer-clean::
-	rm -f options
-
-# Do not make options depend on ../../bin/tests/cfg_test, doing so
-# will cause excessively clever versions of make to attempt to build
-# that program right here, right now, if it is missing, which will
-# cause make doc to bomb.
-
-CFG_TEST = ../../bin/tests/cfg_test
-
-options: FORCE
-	if test -x ${CFG_TEST} && \
-	   ${CFG_TEST} --named --grammar | \
-	   ${PERL} ${srcdir}/format-options.pl >$@.new ; then \
-		mv -f $@.new $@ ; \
-	else \
-		rm -f $@.new ; \
-	fi
diff --git a/contrib/bind9/doc/misc/dnssec b/contrib/bind9/doc/misc/dnssec
deleted file mode 100644
index 4451e6c..0000000
--- a/contrib/bind9/doc/misc/dnssec
+++ /dev/null
@@ -1,84 +0,0 @@
-Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
-Copyright (C) 2000-2002  Internet Software Consortium.
-See COPYRIGHT in the source root or http://isc.org/copyright.html for terms.
-
-DNSSEC Release Notes
-
-This document summarizes the state of the DNSSEC implementation in
-this release of BIND9.
-
-
-OpenSSL Library Required
-
-To support DNSSEC, BIND 9 must be linked with version 0.9.6e or newer of
-the OpenSSL library.  As of BIND 9.2, the library is no longer
-included in the distribution - it must be provided by the operating
-system or installed separately.
-
-To build BIND 9 with OpenSSL, use "configure --with-openssl".  If
-the OpenSSL library is installed in a nonstandard location, you can
-specify a path as in "configure --with-openssl=/var".
-
-
-Key Generation and Signing
-
-The tools for generating DNSSEC keys and signatures are now in the
-bin/dnssec directory.  Documentation for these programs can be found
-in doc/arm/Bv9ARM.4.html and the man pages.
-
-The random data used in generating DNSSEC keys and signatures comes
-from either /dev/random (if the OS supports it) or keyboard input.
-Alternatively, a device or file containing entropy/random data can be
-specified.
-
-
-Serving Secure Zones
-
-When acting as an authoritative name server, BIND9 includes KEY, SIG
-and NXT records in responses as specified in RFC2535 when the request
-has the DO flag set in the query.
-
-
-Secure Resolution
-
-Basic support for validation of DNSSEC signatures in responses has
-been implemented but should still be considered experimental.
-
-When acting as a caching name server, BIND9 is capable of performing
-basic DNSSEC validation of positive as well as nonexistence responses.
-This functionality is enabled by including a "trusted-keys" clause
-in the configuration file, containing the top-level zone key of the
-the DNSSEC tree.
-
-Validation of wildcard responses is not currently supported.  In
-particular, a "name does not exist" response will validate
-successfully even if it does not contain the NXT records to prove the
-nonexistence of a matching wildcard.
-
-Proof of insecure status for insecure zones delegated from secure
-zones works when the zones are completely insecure.  Privately
-secured zones delegated from secure zones will not work in all cases,
-such as when the privately secured zone is served by the same server
-as an ancestor (but not parent) zone.
-
-Handling of the CD bit in queries is now fully implemented.  Validation
-is not attempted for recursive queries if CD is set.
-
-
-Secure Dynamic Update
-
-Dynamic update of secure zones has been implemented, but may not be
-complete.  Affected NXT and SIG records are updated by the server when
-an update occurs.  Advanced access control is possible using the
-"update-policy" statement in the zone definition.
-
-
-Secure Zone Transfers
-
-BIND 9 does not implement the zone transfer security mechanisms of
-RFC2535 section 5.6, and we have no plans to implement them in the
-future as we consider them inferior to the use of TSIG or SIG(0) to
-ensure the integrity of zone transfers.
-
-
-$Id: dnssec,v 1.19 2004/03/05 05:04:53 marka Exp $
diff --git a/contrib/bind9/doc/misc/format-options.pl b/contrib/bind9/doc/misc/format-options.pl
deleted file mode 100644
index 70b334e..0000000
--- a/contrib/bind9/doc/misc/format-options.pl
+++ /dev/null
@@ -1,36 +0,0 @@
-#!/usr/bin/perl
-#
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
-# Copyright (C) 2001  Internet Software Consortium.
-#
-# Permission to use, copy, modify, and distribute this software for any
-# purpose with or without fee is hereby granted, provided that the above
-# copyright notice and this permission notice appear in all copies.
-#
-# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
-# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
-# AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
-# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
-# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
-# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
-# PERFORMANCE OF THIS SOFTWARE.
-
-# $Id: format-options.pl,v 1.2 2004/03/05 05:04:53 marka Exp $
-
-print <<END;
-
-This is a summary of the named.conf options supported by 
-this version of BIND 9.
-
-END
-
-# Break long lines
-while (<>) {
-	s/\t/        /g;
-	if (length >= 79) {
-		m!^( *)!;
-		my $indent = $1;
-		s!^(.{0,75}) (.*)$!\1\n$indent    \2!;
-	}
-	print;
-}
diff --git a/contrib/bind9/doc/misc/ipv6 b/contrib/bind9/doc/misc/ipv6
deleted file mode 100644
index aeba275..0000000
--- a/contrib/bind9/doc/misc/ipv6
+++ /dev/null
@@ -1,113 +0,0 @@
-Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
-Copyright (C) 2000, 2001  Internet Software Consortium.
-See COPYRIGHT in the source root or http://isc.org/copyright.html for terms.
-
-Currently, there are multiple interesting problems with ipv6
-implementations on various platforms.  These problems range from not
-being able to use ipv6 with bind9 (or in particular the ISC socket
-library, contained in libisc) to listen-on lists not being respected,
-to strange warnings but seemingly correct behavior of named.
-
-COMPILE-TIME ISSUES
--------------------
-
-The socket library requires a certain level of support from the
-operating system.  In particular, it must follow the advanced ipv6
-socket API to be usable.  The systems which do not follow this will
-currently not get any warnings or errors, but ipv6 will simply not
-function on them.
-
-These systems currently include, but are not limited to:
-
-	AIX 3.4 (with ipv6 patches)
-
-
-RUN-TIME ISSUES
----------------
-
-In the original drafts of the ipv6 RFC documents, binding an ipv6
-socket to the ipv6 wildcard address would also cause the socket to
-accept ipv4 connections and datagrams.  When an ipv4 packet is
-received on these systems, it is mapped into an ipv6 address.  For
-example, 1.2.3.4 would be mapped into ::ffff:1.2.3.4.  The intent of
-this mapping was to make transition from an ipv4-only application into
-ipv6 easier, by only requiring one socket to be open on a given port.
-
-Later, it was discovered that this was generally a bad idea.  For one,
-many firewalls will block connection to 1.2.3.4, but will let through
-::ffff:1.2.3.4.  This, of course, is bad.  Also, access control lists
-written to accept only ipv4 addresses were suddenly ignored unless
-they were rewritten to handle the ipv6 mapped addresses as well.
-
-Partly because of these problems, the latest IPv6 API introduces an
-explicit knob (the "IPV6_V6ONLY" socket option ) to turn off the ipv6
-mapped address usage.
-
-In bind9, we first check if both the advanced API and the IPV6_V6ONLY
-socket option are available.  If both of them are available, bind9
-named will bind to the ipv6 wildcard port for both TCP and UDP.
-Otherwise named will make a warning and try to bind to all available
-ipv6 addresses separately.
-
-In any case, bind9 named binds to specific addresses for ipv4 sockets.
-
-The followings are historical notes when we always bound to the ipv6
-wildcard port regardless of the availability of the API support.
-These problems should not happen with the closer checks above.
-
-
-IPV6 Sockets Accept IPV4, Specific IPV4 Addresses Bindings Fail
----------------------------------------------------------------
-
-The only OS which seems to do this is (some kernel versions of) linux.
-If an ipv6 socket is bound to the ipv6 wildcard socket, and a specific
-ipv4 socket is later bound (say, to 1.2.3.4 port 53) the ipv4 binding
-will fail.
-
-What this means to bind9 is that the application will log warnings
-about being unable to bind to a socket because the address is already
-in use.  Since the ipv6 socket will accept ipv4 packets and map them,
-however, the ipv4 addresses continue to function.
-
-The effect is that the config file listen-on directive will not be
-respected on these systems.
-
-
-IPV6 Sockets Accept IPV4, Specific IPV4 Address Bindings Succeed
-----------------------------------------------------------------
-
-In this case, the system allows opening an ipv6 wildcard address
-socket and then binding to a more specific ipv4 address later.  An
-example of this type of system is Digital Unix with ipv6 patches
-applied.
-
-What this means to bind9 is that the application will respect
-listen-on in regards to ipv4 sockets, but it will use mapped ipv6
-addresses for any that do not match the listen-on list.  This, in
-effect, makes listen-on useless for these machines as well.
-
-
-IPV6 Sockets Do Not Accept IPV4
--------------------------------
-
-On these systems, opening an IPV6 socket does not implicitly open any
-ipv4 sockets.  An example of these systems are NetBSD-current with the
-latest KAME patch, and other systems which use the latest KAME patches
-as their ipv6 implementation.
-
-On these systems, listen-on is fully functional, as the ipv6 socket
-only accepts ipv6 packets, and the ipv4 sockets will handle the ipv4
-packets.
-
-
-RELEVANT RFCs
--------------
-
-3513:  Internet Protocol Version 6 (IPv6) Addressing Architecture
-
-3493:  Basic Socket Interface Extensions for IPv6
-
-3542:  Advanced Sockets Application Program Interface (API) for IPv6
-
-
-$Id: ipv6,v 1.6.18.3 2004/08/10 04:28:41 jinmei Exp $
diff --git a/contrib/bind9/doc/misc/migration b/contrib/bind9/doc/misc/migration
deleted file mode 100644
index b48371b..0000000
--- a/contrib/bind9/doc/misc/migration
+++ /dev/null
@@ -1,257 +0,0 @@
-Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
-Copyright (C) 2000, 2001, 2003  Internet Software Consortium.
-See COPYRIGHT in the source root or http://isc.org/copyright.html for terms.
-
-                   BIND 8 to BIND 9 Migration Notes
-
-BIND 9 is designed to be mostly upwards compatible with BIND 8, but
-there is still a number of caveats you should be aware of when
-upgrading an existing BIND 8 installation to use BIND 9.
-
-
-1. Configuration File Compatibility
-
-1.1. Unimplemented Options and Changed Defaults
-
-BIND 9 supports most, but not all of the named.conf options of BIND 8.
-For a complete list of implemented options, see doc/misc/options.
-
-If your named.conf file uses an unimplemented option, named will log a
-warning message.  A message is also logged about each option whose
-default has changed unless the option is set explicitly in named.conf.
-
-The default of the "transfer-format" option has changed from
-"one-answer" to "many-answers".  If you have slave servers that do not
-understand the many-answers zone transfer format (e.g., BIND 4.9.5 or
-older) you need to explicitly specify "transfer-format one-answer;" in
-either the options block or a server statement.
-
-1.2. Handling of Configuration File Errors
-
-In BIND 9, named refuses to start if it detects an error in
-named.conf.  Earlier versions would start despite errors, causing the
-server to run with a partial configuration.  Errors detected during
-subsequent reloads do not cause the server to exit.
-
-Errors in master files do not cause the server to exit, but they
-do cause the zone not to load.
-
-1.3. Logging
-
-The set of logging categories in BIND 9 is different from that
-in BIND 8.  If you have customised your logging on a per-category
-basis, you need to modify your logging statement to use the
-new categories.
-
-Another difference is that the "logging" statement only takes effect
-after the entire named.conf file has been read.  This means that when
-the server starts up, any messages about errors in the configuration
-file are always logged to the default destination (syslog) when the
-server first starts up, regardless of the contents of the "logging"
-statement.  In BIND 8, the new logging configuration took effect
-immediately after the "logging" statement was read.
-
-1.4. Notify messages and Refresh queries
-
-The source address and port for these is now controlled by
-"notify-source" and "transfer-source", respectively, rather that
-query-source as in BIND 8.
-
-1.5. Multiple Classes.
-
-Multiple classes have to be put into explicit views for each class.
-
-
-2. Zone File Compatibility
-
-2.1. Strict RFC1035 Interpretation of TTLs in Zone Files
-
-BIND 9 strictly complies with the RFC1035 and RFC2308 rules regarding
-omitted TTLs in zone files.  Omitted TTLs are replaced by the value
-specified with the $TTL directive, or by the previous explicit TTL if
-there is no $TTL directive.
-
-If there is no $TTL directive and the first RR in the file does not
-have an explicit TTL field, the zone file is illegal according to
-RFC1035 since the TTL of the first RR is undefined.  Unfortunately,
-BIND 4 and many versions of BIND 8 accept such files without warning
-and use the value of the SOA MINTTL field as a default for missing TTL
-values.
-
-BIND 9.0 and 9.1 completely refused to load such files.  BIND 9.2
-emulates the nonstandard BIND 4/8 SOA MINTTL behaviour and loads the
-files anyway (provided the SOA is the first record in the file), but
-will issue the warning message "no TTL specified; using SOA MINTTL
-instead".
-
-To avoid problems, we recommend that you use a $TTL directive in each
-zone file.
-
-2.2. Periods in SOA Serial Numbers Deprecated
-
-Some versions of BIND allow SOA serial numbers with an embedded
-period, like "3.002", and convert them into integers in a rather
-unintuitive way.  This feature is not supported by BIND 9; serial
-numbers must be integers.
-
-2.3. Handling of Unbalanced Quotes
-
-TXT records with unbalanced quotes, like 'host TXT "foo', were not
-treated as errors in some versions of BIND.  If your zone files
-contain such records, you will get potentially confusing error
-messages like "unexpected end of file" because BIND 9 will interpret
-everything up to the next quote character as a literal string.
-
-2.4. Handling of Line Breaks
-
-Some versions of BIND accept RRs containing line breaks that are not
-properly quoted with parentheses, like the following SOA:
-
-	@	IN SOA	ns.example. hostmaster.example.
-			( 1 3600 1800 1814400 3600 )
-
-This is not legal master file syntax and will be treated as an error
-by BIND 9.  The fix is to move the opening parenthesis to the first
-line.
-
-2.5. Unimplemented BIND 8 Extensions
-
-$GENERATE: The "$$" construct for getting a literal $ into a domain
-name is deprecated.  Use \$ instead.
-
-2.6. TXT records are no longer automatically split.
-
-Some versions of BIND accepted strings in TXT RDATA consisting of more
-than 255 characters and silently split them to be able to encode the
-strings in a protocol conformant way. You may now see errors like this
-        dns_rdata_fromtext: local.db:119: ran out of space
-if you have TXT RRs with too longs strings. Make sure to split the
-string in the zone data file at or before a single one reaches 255
-characters.
-
-3. Interoperability Impact of New Protocol Features
-
-3.1. EDNS0
-
-BIND 9 uses EDNS0 (RFC2671) to advertise its receive buffer size.  It
-also sets DO EDNS flag bit in queries to indicate that it wishes to
-receive DNSSEC responses.
-
-Most older servers that do not support EDNS0, including prior versions
-of BIND, will send a FORMERR or NOTIMP response to these queries.
-When this happens, BIND 9 will automatically retry the query without
-EDNS0.
-
-Unfortunately, there exists at least one non-BIND name server
-implementation that silently ignores these queries instead of sending
-an error response.  Resolving names in zones where all or most
-authoritative servers use this server will be very slow or fail
-completely.  We have contacted the manufacturer of the name server in
-case, and they are working on a solution.
-
-When BIND 9 communicates with a server that does support EDNS0, such as
-another BIND 9 server, responses of up to 4096 bytes may be
-transmitted as a single UDP datagram which is subject to fragmentation
-at the IP level.  If a firewall incorrectly drops IP fragments, it can
-cause resolution to slow down dramatically or fail.
-
-3.2. Zone Transfers
-
-Outgoing zone transfers now use the "many-answers" format by default.
-This format is not understood by certain old versions of BIND 4.  
-You can work around this problem using the option "transfer-format
-one-answer;", but since these old versions all have known security
-problems, the correct fix is to upgrade the slave servers.
-
-Zone transfers to Windows 2000 DNS servers sometimes fail due to a
-bug in the Windows 2000 DNS server where DNS messages larger than
-16K are not handled properly.  Obtain the latest service pack for
-Windows 2000 from Microsoft to address this issue.  In the meantime,
-the problem can be worked around by setting "transfer-format one-answer;".
-http://support.microsoft.com/default.aspx?scid=kb;en-us;297936
-
-4. Unrestricted Character Set
-
-		BIND 9.2 only
-
-BIND 9 does not restrict the character set of domain names - it is
-fully 8-bit clean in accordance with RFC2181 section 11.
-
-It is strongly recommended that hostnames published in the DNS follow
-the RFC952 rules, but BIND 9 will not enforce this restriction.
-
-Historically, some applications have suffered from security flaws
-where data originating from the network, such as names returned by
-gethostbyaddr(), are used with insufficient checking and may cause a
-breach of security when containing unexpected characters; see
-<http://www.cert.org/advisories/CA-96.04.corrupt_info_from_servers.html>
-for details.  Some earlier versions of BIND attempt to protect these
-flawed applications from attack by discarding data containing
-characters deemed inappropriate in host names or mail addresses, under
-the control of the "check-names" option in named.conf and/or "options
-no-check-names" in resolv.conf.  BIND 9 provides no such protection;
-if applications with these flaws are still being used, they should
-be upgraded.
-
-	BIND 9.3 onwards implements check-names.
-
-5. Server Administration Tools
-
-5.1 Ndc Replaced by Rndc
-
-The "ndc" program has been replaced by "rndc", which is capable of
-remote operation.  Unlike ndc, rndc requires a configuration file.
-The easiest way to generate a configuration file is to run
-"rndc-confgen -a"; see the man pages for rndc(8), rndc-confgen(8),
-and rndc.conf(5) for details.
-
-5.2. Nsupdate Differences
-
-The BIND 8 implementation of nsupdate had an undocumented feature
-where an update request would be broken down into multiple requests
-based upon the discovered zones that contained the records.  This
-behaviour has not been implemented in BIND 9.  Each update request
-must pertain to a single zone, but it is still possible to do multiple
-updates in a single invocation of nsupdate by terminating each update
-with an empty line or a "send" command.
-
-
-6. No Information Leakage between Zones
-
-BIND 9 stores the authoritative data for each zone in a separate data
-structure, as recommended in RFC1035 and as required by DNSSEC and
-IXFR.  When a BIND 9 server is authoritative for both a child zone and
-its parent, it will have two distinct sets of NS records at the
-delegation point: the authoritative NS records at the child's apex,
-and a set of glue NS records in the parent.
-
-BIND 8 was unable to properly distinguish between these two sets of NS
-records and would "leak" the child's NS records into the parent,
-effectively causing the parent zone to be silently modified: responses
-and zone transfers from the parent contained the child's NS records
-rather than the glue configured into the parent (if any).  In the case
-of children of type "stub", this behaviour was documented as a feature,
-allowing the glue NS records to be omitted from the parent
-configuration.
-
-Sites that were relying on this BIND 8 behaviour need to add any
-omitted glue NS records, and any necessary glue A records, to the
-parent zone.
-
-Although stub zones can no longer be used as a mechanism for injecting
-NS records into their parent zones, they are still useful as a way of
-directing queries for a given domain to a particular set of name
-servers.
-
-
-7. Umask not Modified
-
-The BIND 8 named unconditionally sets the umask to 022.  BIND 9 does
-not; the umask inherited from the parent process remains in effect.
-This may cause files created by named, such as journal files, to be
-created with different file permissions than they did in BIND 8.  If
-necessary, the umask should be set explicitly in the script used to
-start the named process.
-
-
-$Id: migration,v 1.45.18.2 2007/09/07 06:34:21 marka Exp $
diff --git a/contrib/bind9/doc/misc/migration-4to9 b/contrib/bind9/doc/misc/migration-4to9
deleted file mode 100644
index 008cbed..0000000
--- a/contrib/bind9/doc/misc/migration-4to9
+++ /dev/null
@@ -1,57 +0,0 @@
-Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
-Copyright (C) 2001  Internet Software Consortium.
-See COPYRIGHT in the source root or http://isc.org/copyright.html for terms.
-
-$Id: migration-4to9,v 1.4 2004/03/05 05:04:53 marka Exp $
-
-		   BIND 4 to BIND 9 Migration Notes
-
-To transition from BIND 4 to BIND 9 you first need to convert your
-configuration file to the new format.  There is a conversion tool in
-contrib/named-bootconf that allows you to do this.
-
-	named-bootconf.sh < /etc/named.boot > /etc/named.conf
-
-BIND 9 uses a system assigned port for the UDP queries it makes rather
-than port 53 that BIND 4 uses.  This may conflict with some firewalls.
-The following directives in /etc/named.conf allows you to specify
-a port to use.
-
-	query-source address * port 53;
-	transfer-source * port 53;
-	notify-source * port 53;
-
-BIND 9 no longer uses the minimum field to specify the TTL of records
-without a explicit TTL.  Use the $TTL directive to specify a default TTL
-before the first record without a explicit TTL.
-
-	$TTL 3600
-	@	IN	SOA	ns1.example.com. hostmaster.example.com. (
-				2001021100
-				7200
-				1200
-				3600000
-				7200 )
-
-BIND 9 does not support multiple CNAMEs with the same owner name.
-	
-	Illegal:
-	www.example.com. CNAME host1.example.com.
-	www.example.com. CNAME host2.example.com.
-
-BIND 9 does not support "CNAMEs with other data" with the same owner name,
-ignoring the DNSSEC records (SIG, NXT, KEY) that BIND 4 did not support.
-
-	Illegal:
-	www.example.com. CNAME host1.example.com.
-	www.example.com. MX 10 host2.example.com.
-
-BIND 9 is less tolerant of errors in master files, so check your logs and
-fix any errors reported.  The named-checkzone program can also be to check
-master files.
-
-Outgoing zone transfers now use the "many-answers" format by default.
-This format is not understood by certain old versions of BIND 4.  
-You can work around this problem using the option "transfer-format
-one-answer;", but since these old versions all have known security
-problems, the correct fix is to upgrade the slave servers.
diff --git a/contrib/bind9/doc/misc/options b/contrib/bind9/doc/misc/options
deleted file mode 100644
index a17c522..0000000
--- a/contrib/bind9/doc/misc/options
+++ /dev/null
@@ -1,481 +0,0 @@
-
-This is a summary of the named.conf options supported by 
-this version of BIND 9.
-
-options {
-        avoid-v4-udp-ports { <port>; ... };
-        avoid-v6-udp-ports { <port>; ... };
-        blackhole { <address_match_element>; ... };
-        coresize <size>;
-        datasize <size>;
-        deallocate-on-exit <boolean>; // obsolete
-        directory <quoted_string>;
-        dump-file <quoted_string>;
-        fake-iquery <boolean>; // obsolete
-        files <size>;
-        has-old-clients <boolean>; // obsolete
-        heartbeat-interval <integer>;
-        host-statistics <boolean>; // not implemented
-        host-statistics-max <integer>; // not implemented
-        hostname ( <quoted_string> | none );
-        interface-interval <integer>;
-        listen-on [ port <integer> ] { <address_match_element>; ... };
-        listen-on-v6 [ port <integer> ] { <address_match_element>; ... };
-        match-mapped-addresses <boolean>;
-        memstatistics-file <quoted_string>;
-        multiple-cnames <boolean>; // obsolete
-        named-xfer <quoted_string>; // obsolete
-        pid-file ( <quoted_string> | none );
-        port <integer>;
-        querylog <boolean>;
-        recursing-file <quoted_string>;
-        random-device <quoted_string>;
-        recursive-clients <integer>;
-        serial-queries <integer>; // obsolete
-        serial-query-rate <integer>;
-        server-id ( <quoted_string> | none |;
-        stacksize <size>;
-        statistics-file <quoted_string>;
-        statistics-interval <integer>; // not yet implemented
-        tcp-clients <integer>;
-        tcp-listen-queue <integer>;
-        tkey-dhkey <quoted_string> <integer>;
-        tkey-gssapi-credential <quoted_string>;
-        tkey-domain <quoted_string>;
-        transfers-per-ns <integer>;
-        transfers-in <integer>;
-        transfers-out <integer>;
-        treat-cr-as-space <boolean>; // obsolete
-        use-id-pool <boolean>; // obsolete
-        use-ixfr <boolean>;
-        version ( <quoted_string> | none );
-        flush-zones-on-shutdown <boolean>;
-        allow-query-cache { <address_match_element>; ... };
-        allow-recursion { <address_match_element>; ... };
-        allow-v6-synthesis { <address_match_element>; ... }; // obsolete
-        sortlist { <address_match_element>; ... };
-        topology { <address_match_element>; ... }; // not implemented
-        auth-nxdomain <boolean>; // default changed
-        minimal-responses <boolean>;
-        recursion <boolean>;
-        rrset-order { [ class <string> ] [ type <string> ] [ name
-            <quoted_string> ] <string> <string>; ... };
-        provide-ixfr <boolean>;
-        request-ixfr <boolean>;
-        fetch-glue <boolean>; // obsolete
-        rfc2308-type1 <boolean>; // not yet implemented
-        additional-from-auth <boolean>;
-        additional-from-cache <boolean>;
-        query-source <querysource4>;
-        query-source-v6 <querysource6>;
-        cleaning-interval <integer>;
-        min-roots <integer>; // not implemented
-        lame-ttl <integer>;
-        max-ncache-ttl <integer>;
-        max-cache-ttl <integer>;
-        transfer-format ( many-answers | one-answer );
-        max-cache-size <size_no_default>;
-        check-names ( master | slave | response ) ( fail | warn | ignore );
-        cache-file <quoted_string>;
-        suppress-initial-notify <boolean>; // not yet implemented
-        preferred-glue <string>;
-        dual-stack-servers [ port <integer> ] { ( <quoted_string> [port
-            <integer>] | <ipv4_address> [port <integer>] | <ipv6_address> [port <integer>] ); ... };
-        edns-udp-size <integer>;
-        max-udp-size <integer>;
-        root-delegation-only [ exclude { <quoted_string>; ... } ];
-        disable-algorithms <string> { <string>; ... };
-        dnssec-enable <boolean>;
-        dnssec-validation <boolean>;
-        dnssec-lookaside <string> trust-anchor <string>;
-        dnssec-must-be-secure <string> <boolean>;
-        dnssec-accept-expired <boolean>;
-        ixfr-from-differences <ixfrdiff>;
-        acache-enable <boolean>;
-        acache-cleaning-interval <integer>;
-        max-acache-size <size_no_default>;
-        clients-per-query <integer>;
-        max-clients-per-query <integer>;
-        empty-server <string>;
-        empty-contact <string>;
-        empty-zones-enable <boolean>;
-        disable-empty-zone <string>;
-        zero-no-soa-ttl-cache <boolean>;
-        allow-query { <address_match_element>; ... };
-        allow-transfer { <address_match_element>; ... };
-        allow-update { <address_match_element>; ... };
-        allow-update-forwarding { <address_match_element>; ... };
-        allow-notify { <address_match_element>; ... };
-        masterfile-format ( text | raw );
-        notify <notifytype>;
-        notify-source ( <ipv4_address> | * ) [ port ( <integer> | * ) ];
-        notify-source-v6 ( <ipv6_address> | * ) [ port ( <integer> | * ) ];
-        also-notify [ port <integer> ] { ( <ipv4_address> | <ipv6_address>
-            ) [ port <integer> ]; ... };
-        notify-delay <integer>;
-        dialup <dialuptype>;
-        forward ( first | only );
-        forwarders [ port <integer> ] { ( <ipv4_address> | <ipv6_address> )
-            [ port <integer> ]; ... };
-        maintain-ixfr-base <boolean>; // obsolete
-        max-ixfr-log-size <size>; // obsolete
-        max-journal-size <size_no_default>;
-        max-transfer-time-in <integer>;
-        max-transfer-time-out <integer>;
-        max-transfer-idle-in <integer>;
-        max-transfer-idle-out <integer>;
-        max-retry-time <integer>;
-        min-retry-time <integer>;
-        max-refresh-time <integer>;
-        min-refresh-time <integer>;
-        multi-master <boolean>;
-        sig-validity-interval <integer>;
-        transfer-source ( <ipv4_address> | * ) [ port ( <integer> | * ) ];
-        transfer-source-v6 ( <ipv6_address> | * ) [ port ( <integer> | * ) ];
-        alt-transfer-source ( <ipv4_address> | * ) [ port ( <integer> | * )
-            ];
-        alt-transfer-source-v6 ( <ipv6_address> | * ) [ port ( <integer> |
-            * ) ];
-        use-alt-transfer-source <boolean>;
-        zone-statistics <boolean>;
-        key-directory <quoted_string>;
-        check-wildcard <boolean>;
-        check-integrity <boolean>;
-        check-mx ( fail | warn | ignore );
-        check-mx-cname ( fail | warn | ignore );
-        check-srv-cname ( fail | warn | ignore );
-        check-sibling <boolean>;
-        zero-no-soa-ttl <boolean>;
-        update-check-ksk <boolean>;
-};
-
-controls {
-        inet ( <ipv4_address> | <ipv6_address> | * ) [ port ( <integer> | *
-            ) ] allow { <address_match_element>; ... } [ keys { <string>; ... } ];
-        unix <quoted_string> perm <integer> owner <integer> group <integer>
-            [ keys { <string>; ... } ];
-};
-
-acl <string> { <address_match_element>; ... };
-
-masters <string> [ port <integer> ] { ( <masters> | <ipv4_address> [port
-    <integer>] | <ipv6_address> [port <integer>] ) [ key <string> ]; ... };
-
-logging {
-        channel <string> {
-                file <log_file>;
-                syslog <optional_facility>;
-                null;
-                stderr;
-                severity <log_severity>;
-                print-time <boolean>;
-                print-severity <boolean>;
-                print-category <boolean>;
-        };
-        category <string> { <string>; ... };
-};
-
-view <string> <optional_class> {
-        match-clients { <address_match_element>; ... };
-        match-destinations { <address_match_element>; ... };
-        match-recursive-only <boolean>;
-        key <string> {
-                algorithm <string>;
-                secret <string>;
-        };
-        zone <string> <optional_class> {
-                type ( master | slave | stub | hint | forward |
-                    delegation-only );
-                file <quoted_string>;
-                journal <quoted_string>;
-                ixfr-base <quoted_string>; // obsolete
-                ixfr-tmp-file <quoted_string>; // obsolete
-                masters [ port <integer> ] { ( <masters> | <ipv4_address>
-                    [port <integer>] | <ipv6_address> [port <integer>] ) [ key <string> ]; ... };
-                pubkey <integer> <integer> <integer> <quoted_string>; //
-                    obsolete
-                update-policy { ( grant | deny ) <string> ( name |
-                    subdomain | wildcard | self | selfsub | selfwild ) <string> <rrtypelist>; ... };
-                database <string>;
-                delegation-only <boolean>;
-                check-names ( fail | warn | ignore );
-                ixfr-from-differences <boolean>;
-                allow-query { <address_match_element>; ... };
-                allow-transfer { <address_match_element>; ... };
-                allow-update { <address_match_element>; ... };
-                allow-update-forwarding { <address_match_element>; ... };
-                allow-notify { <address_match_element>; ... };
-                masterfile-format ( text | raw );
-                notify <notifytype>;
-                notify-source ( <ipv4_address> | * ) [ port ( <integer> | *
-                    ) ];
-                notify-source-v6 ( <ipv6_address> | * ) [ port ( <integer>
-                    | * ) ];
-                also-notify [ port <integer> ] { ( <ipv4_address> |
-                    <ipv6_address> ) [ port <integer> ]; ... };
-                notify-delay <integer>;
-                dialup <dialuptype>;
-                forward ( first | only );
-                forwarders [ port <integer> ] { ( <ipv4_address> |
-                    <ipv6_address> ) [ port <integer> ]; ... };
-                maintain-ixfr-base <boolean>; // obsolete
-                max-ixfr-log-size <size>; // obsolete
-                max-journal-size <size_no_default>;
-                max-transfer-time-in <integer>;
-                max-transfer-time-out <integer>;
-                max-transfer-idle-in <integer>;
-                max-transfer-idle-out <integer>;
-                max-retry-time <integer>;
-                min-retry-time <integer>;
-                max-refresh-time <integer>;
-                min-refresh-time <integer>;
-                multi-master <boolean>;
-                sig-validity-interval <integer>;
-                transfer-source ( <ipv4_address> | * ) [ port ( <integer> |
-                    * ) ];
-                transfer-source-v6 ( <ipv6_address> | * ) [ port (
-                    <integer> | * ) ];
-                alt-transfer-source ( <ipv4_address> | * ) [ port (
-                    <integer> | * ) ];
-                alt-transfer-source-v6 ( <ipv6_address> | * ) [ port (
-                    <integer> | * ) ];
-                use-alt-transfer-source <boolean>;
-                zone-statistics <boolean>;
-                key-directory <quoted_string>;
-                check-wildcard <boolean>;
-                check-integrity <boolean>;
-                check-mx ( fail | warn | ignore );
-                check-mx-cname ( fail | warn | ignore );
-                check-srv-cname ( fail | warn | ignore );
-                check-sibling <boolean>;
-                zero-no-soa-ttl <boolean>;
-                update-check-ksk <boolean>;
-        };
-        dlz <string> {
-                database <string>;
-        };
-        server <netprefix> {
-                bogus <boolean>;
-                provide-ixfr <boolean>;
-                request-ixfr <boolean>;
-                support-ixfr <boolean>; // obsolete
-                transfers <integer>;
-                transfer-format ( many-answers | one-answer );
-                keys <server_key>;
-                edns <boolean>;
-                edns-udp-size <integer>;
-                max-udp-size <integer>;
-                notify-source ( <ipv4_address> | * ) [ port ( <integer> | *
-                    ) ];
-                notify-source-v6 ( <ipv6_address> | * ) [ port ( <integer>
-                    | * ) ];
-                query-source <querysource4>;
-                query-source-v6 <querysource6>;
-                transfer-source ( <ipv4_address> | * ) [ port ( <integer> |
-                    * ) ];
-                transfer-source-v6 ( <ipv6_address> | * ) [ port (
-                    <integer> | * ) ];
-        };
-        trusted-keys { <string> <integer> <integer> <integer>
-            <quoted_string>; ... };
-        allow-query-cache { <address_match_element>; ... };
-        allow-recursion { <address_match_element>; ... };
-        allow-v6-synthesis { <address_match_element>; ... }; // obsolete
-        sortlist { <address_match_element>; ... };
-        topology { <address_match_element>; ... }; // not implemented
-        auth-nxdomain <boolean>; // default changed
-        minimal-responses <boolean>;
-        recursion <boolean>;
-        rrset-order { [ class <string> ] [ type <string> ] [ name
-            <quoted_string> ] <string> <string>; ... };
-        provide-ixfr <boolean>;
-        request-ixfr <boolean>;
-        fetch-glue <boolean>; // obsolete
-        rfc2308-type1 <boolean>; // not yet implemented
-        additional-from-auth <boolean>;
-        additional-from-cache <boolean>;
-        query-source <querysource4>;
-        query-source-v6 <querysource6>;
-        cleaning-interval <integer>;
-        min-roots <integer>; // not implemented
-        lame-ttl <integer>;
-        max-ncache-ttl <integer>;
-        max-cache-ttl <integer>;
-        transfer-format ( many-answers | one-answer );
-        max-cache-size <size_no_default>;
-        check-names ( master | slave | response ) ( fail | warn | ignore );
-        cache-file <quoted_string>;
-        suppress-initial-notify <boolean>; // not yet implemented
-        preferred-glue <string>;
-        dual-stack-servers [ port <integer> ] { ( <quoted_string> [port
-            <integer>] | <ipv4_address> [port <integer>] | <ipv6_address> [port <integer>] ); ... };
-        edns-udp-size <integer>;
-        max-udp-size <integer>;
-        root-delegation-only [ exclude { <quoted_string>; ... } ];
-        disable-algorithms <string> { <string>; ... };
-        dnssec-enable <boolean>;
-        dnssec-validation <boolean>;
-        dnssec-lookaside <string> trust-anchor <string>;
-        dnssec-must-be-secure <string> <boolean>;
-        dnssec-accept-expired <boolean>;
-        ixfr-from-differences <ixfrdiff>;
-        acache-enable <boolean>;
-        acache-cleaning-interval <integer>;
-        max-acache-size <size_no_default>;
-        clients-per-query <integer>;
-        max-clients-per-query <integer>;
-        empty-server <string>;
-        empty-contact <string>;
-        empty-zones-enable <boolean>;
-        disable-empty-zone <string>;
-        zero-no-soa-ttl-cache <boolean>;
-        allow-query { <address_match_element>; ... };
-        allow-transfer { <address_match_element>; ... };
-        allow-update { <address_match_element>; ... };
-        allow-update-forwarding { <address_match_element>; ... };
-        allow-notify { <address_match_element>; ... };
-        masterfile-format ( text | raw );
-        notify <notifytype>;
-        notify-source ( <ipv4_address> | * ) [ port ( <integer> | * ) ];
-        notify-source-v6 ( <ipv6_address> | * ) [ port ( <integer> | * ) ];
-        also-notify [ port <integer> ] { ( <ipv4_address> | <ipv6_address>
-            ) [ port <integer> ]; ... };
-        notify-delay <integer>;
-        dialup <dialuptype>;
-        forward ( first | only );
-        forwarders [ port <integer> ] { ( <ipv4_address> | <ipv6_address> )
-            [ port <integer> ]; ... };
-        maintain-ixfr-base <boolean>; // obsolete
-        max-ixfr-log-size <size>; // obsolete
-        max-journal-size <size_no_default>;
-        max-transfer-time-in <integer>;
-        max-transfer-time-out <integer>;
-        max-transfer-idle-in <integer>;
-        max-transfer-idle-out <integer>;
-        max-retry-time <integer>;
-        min-retry-time <integer>;
-        max-refresh-time <integer>;
-        min-refresh-time <integer>;
-        multi-master <boolean>;
-        sig-validity-interval <integer>;
-        transfer-source ( <ipv4_address> | * ) [ port ( <integer> | * ) ];
-        transfer-source-v6 ( <ipv6_address> | * ) [ port ( <integer> | * ) ];
-        alt-transfer-source ( <ipv4_address> | * ) [ port ( <integer> | * )
-            ];
-        alt-transfer-source-v6 ( <ipv6_address> | * ) [ port ( <integer> |
-            * ) ];
-        use-alt-transfer-source <boolean>;
-        zone-statistics <boolean>;
-        key-directory <quoted_string>;
-        check-wildcard <boolean>;
-        check-integrity <boolean>;
-        check-mx ( fail | warn | ignore );
-        check-mx-cname ( fail | warn | ignore );
-        check-srv-cname ( fail | warn | ignore );
-        check-sibling <boolean>;
-        zero-no-soa-ttl <boolean>;
-        update-check-ksk <boolean>;
-        database <string>;
-};
-
-lwres {
-        listen-on [ port <integer> ] { ( <ipv4_address> | <ipv6_address> )
-            [ port <integer> ]; ... };
-        view <string> <optional_class>;
-        search { <string>; ... };
-        ndots <integer>;
-};
-
-key <string> {
-        algorithm <string>;
-        secret <string>;
-};
-
-zone <string> <optional_class> {
-        type ( master | slave | stub | hint | forward | delegation-only );
-        file <quoted_string>;
-        journal <quoted_string>;
-        ixfr-base <quoted_string>; // obsolete
-        ixfr-tmp-file <quoted_string>; // obsolete
-        masters [ port <integer> ] { ( <masters> | <ipv4_address> [port
-            <integer>] | <ipv6_address> [port <integer>] ) [ key <string> ]; ... };
-        pubkey <integer> <integer> <integer> <quoted_string>; // obsolete
-        update-policy { ( grant | deny ) <string> ( name | subdomain |
-            wildcard | self | selfsub | selfwild ) <string> <rrtypelist>; ... };
-        database <string>;
-        delegation-only <boolean>;
-        check-names ( fail | warn | ignore );
-        ixfr-from-differences <boolean>;
-        allow-query { <address_match_element>; ... };
-        allow-transfer { <address_match_element>; ... };
-        allow-update { <address_match_element>; ... };
-        allow-update-forwarding { <address_match_element>; ... };
-        allow-notify { <address_match_element>; ... };
-        masterfile-format ( text | raw );
-        notify <notifytype>;
-        notify-source ( <ipv4_address> | * ) [ port ( <integer> | * ) ];
-        notify-source-v6 ( <ipv6_address> | * ) [ port ( <integer> | * ) ];
-        also-notify [ port <integer> ] { ( <ipv4_address> | <ipv6_address>
-            ) [ port <integer> ]; ... };
-        notify-delay <integer>;
-        dialup <dialuptype>;
-        forward ( first | only );
-        forwarders [ port <integer> ] { ( <ipv4_address> | <ipv6_address> )
-            [ port <integer> ]; ... };
-        maintain-ixfr-base <boolean>; // obsolete
-        max-ixfr-log-size <size>; // obsolete
-        max-journal-size <size_no_default>;
-        max-transfer-time-in <integer>;
-        max-transfer-time-out <integer>;
-        max-transfer-idle-in <integer>;
-        max-transfer-idle-out <integer>;
-        max-retry-time <integer>;
-        min-retry-time <integer>;
-        max-refresh-time <integer>;
-        min-refresh-time <integer>;
-        multi-master <boolean>;
-        sig-validity-interval <integer>;
-        transfer-source ( <ipv4_address> | * ) [ port ( <integer> | * ) ];
-        transfer-source-v6 ( <ipv6_address> | * ) [ port ( <integer> | * ) ];
-        alt-transfer-source ( <ipv4_address> | * ) [ port ( <integer> | * )
-            ];
-        alt-transfer-source-v6 ( <ipv6_address> | * ) [ port ( <integer> |
-            * ) ];
-        use-alt-transfer-source <boolean>;
-        zone-statistics <boolean>;
-        key-directory <quoted_string>;
-        check-wildcard <boolean>;
-        check-integrity <boolean>;
-        check-mx ( fail | warn | ignore );
-        check-mx-cname ( fail | warn | ignore );
-        check-srv-cname ( fail | warn | ignore );
-        check-sibling <boolean>;
-        zero-no-soa-ttl <boolean>;
-        update-check-ksk <boolean>;
-};
-
-dlz <string> {
-        database <string>;
-};
-
-server <netprefix> {
-        bogus <boolean>;
-        provide-ixfr <boolean>;
-        request-ixfr <boolean>;
-        support-ixfr <boolean>; // obsolete
-        transfers <integer>;
-        transfer-format ( many-answers | one-answer );
-        keys <server_key>;
-        edns <boolean>;
-        edns-udp-size <integer>;
-        max-udp-size <integer>;
-        notify-source ( <ipv4_address> | * ) [ port ( <integer> | * ) ];
-        notify-source-v6 ( <ipv6_address> | * ) [ port ( <integer> | * ) ];
-        query-source <querysource4>;
-        query-source-v6 <querysource6>;
-        transfer-source ( <ipv4_address> | * ) [ port ( <integer> | * ) ];
-        transfer-source-v6 ( <ipv6_address> | * ) [ port ( <integer> | * ) ];
-};
-
-trusted-keys { <string> <integer> <integer> <integer> <quoted_string>; ... };
-
diff --git a/contrib/bind9/doc/misc/rfc-compliance b/contrib/bind9/doc/misc/rfc-compliance
deleted file mode 100644
index 4c87c66..0000000
--- a/contrib/bind9/doc/misc/rfc-compliance
+++ /dev/null
@@ -1,62 +0,0 @@
-Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
-Copyright (C) 2001  Internet Software Consortium.
-See COPYRIGHT in the source root or http://isc.org/copyright.html for terms.
-
-$Id: rfc-compliance,v 1.4 2004/03/05 05:04:53 marka Exp $
-
-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.
-
-  RFC1034
-  RFC1035 [1] [2]
-  RFC1123
-  RFC1183
-  RFC1535
-  RFC1536
-  RFC1706
-  RFC1712
-  RFC1750
-  RFC1876
-  RFC1982
-  RFC1995
-  RFC1996
-  RFC2136
-  RFC2163
-  RFC2181
-  RFC2230
-  RFC2308
-  RFC2535 [3] [4]
-  RFC2536
-  RFC2537
-  RFC2538
-  RFC2539
-  RFC2671
-  RFC2672
-  RFC2673
-  RFC2782
-  RFC2915
-  RFC2930
-  RFC2931 [5]
-  RFC3007
-
-
-[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.
-
-[3] Wildcard records are not supported in DNSSEC secure zones.
-
-[4] Servers authoritative for secure zones being resolved by BIND 9
-must support EDNS0 (RFC2671), and must return all relevant SIGs and
-NXTs in responses rather than relying on the resolving server to
-perform separate queries for missing SIGs and NXTs.
-
-[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.
diff --git a/contrib/bind9/doc/misc/roadmap b/contrib/bind9/doc/misc/roadmap
deleted file mode 100644
index f63a469..0000000
--- a/contrib/bind9/doc/misc/roadmap
+++ /dev/null
@@ -1,47 +0,0 @@
-Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
-Copyright (C) 2000, 2001  Internet Software Consortium.
-See COPYRIGHT in the source root or http://isc.org/copyright.html for terms.
-
-$Id: roadmap,v 1.2 2004/03/05 05:04:54 marka Exp $
-
-Road Map to the BIND 9 Source Tree
-
-bin/named		The name server.  This relies heavily on the
-			libraries in lib/isc and lib/dns.
-    client.c		Handling of incoming client requests
-    query.c		Query processing
-bin/rndc		The remote name daemon control program
-bin/dig			The "dig" program
-bin/dnssec		The DNSSEC signer and other DNSSEC tools
-bin/nsupdate		The "nsupdate" program
-bin/tests		Test suites and miscellaneous test programs
-bin/tests/system	System tests; see bin/tests/system/README
-lib/dns			The DNS library
-    resolver.c		The "full resolver" (performs recursive lookups)
-    validator.c		The DNSSEC validator
-    db.c		The database interface
-    sdb.c		The simple database interface
-    rbtdb.c		The red-black tree database
-lib/dns/rdata		Routines for handling the various RR types
-lib/dns/sec		Cryptographic libraries for DNSSEC
-lib/isc			The ISC library
-    task.c		Task library
-    unix/socket.c	Unix implementation of socket library
-lib/isccfg		Routines for reading and writing ISC-style
-			configuration files like named.conf and rndc.conf
-lib/isccc		The command channel library, used by rndc.
-lib/tests		Support code for the test suites.
-lib/lwres		The lightweight resolver library.
-doc/draft		Current internet-drafts pertaining to the DNS
-doc/rfc			RFCs pertaining to the DNS
-doc/misc		Miscellaneous documentation
-doc/arm			The BIND 9 Administrator Reference Manual
-doc/man			Man pages
-contrib			Contributed and other auxiliary code
-contrib/idn/mdnkit	The multilingual domain name evaluation kit
-contrib/sdb		Sample drivers for the simple database interface
-make			Makefile fragments, used by configure
-
-The library interfaces are mainly documented in the form of comments
-in the header files.  For example, the task subsystem is documented in
-lib/isc/include/isc/task.h
diff --git a/contrib/bind9/doc/misc/sdb b/contrib/bind9/doc/misc/sdb
deleted file mode 100644
index 552028a..0000000
--- a/contrib/bind9/doc/misc/sdb
+++ /dev/null
@@ -1,169 +0,0 @@
-Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
-Copyright (C) 2000, 2001  Internet Software Consortium.
-See COPYRIGHT in the source root or http://isc.org/copyright.html for terms.
-
-Using the BIND 9 Simplified Database Interface
-
-This document describes the care and feeding of the BIND 9 Simplified
-Database Interface, which allows you to extend BIND 9 with new ways
-of obtaining the data that is published as DNS zones.
-
-
-The Original BIND 9 Database Interface
-
-BIND 9 has a well-defined "back-end database interface" that makes it
-possible to replace the component of the name server responsible for
-the storage and retrieval of zone data, called the "database", on a
-per-zone basis.  The default database is an in-memory, red-black-tree
-data structure commonly referred to as "rbtdb", but it is possible to
-write drivers to support any number of alternative database
-technologies such as in-memory hash tables, application specific
-persistent on-disk databases, object databases, or relational
-databases.
-
-The original BIND 9 database interface defined in <dns/db.h> is
-designed to efficiently support the full set of database functionality
-needed by a name server that implements the complete DNS protocols,
-including features such as zone transfers, dynamic update, and DNSSEC.
-Each of these aspects of name server operations places its own set of
-demands on the data store, with the result that the database API is
-quite complex and contains operations that are highly specific to the
-DNS.  For example, data are stored in a binary format, the name space
-is tree structured, and sets of data records are conceptually
-associated with DNSSEC signature sets.  For these reasons, writing a
-driver using this interface is a highly nontrivial undertaking.
-
-
-The Simplified Database Interface
-
-Many BIND users wish to provide access to various data sources through
-the DNS, but are not necessarily interested in completely replacing
-the in-memory "rbt" database or in supporting features like dynamic
-update, DNSSEC, or even zone transfers.
-
-Often, all you want is limited, read-only DNS access to an existing
-system.  For example, you may have an existing relational database
-containing hostname/address mappings and wish to provide forvard and
-reverse DNS lookups based on this information.  Or perhaps you want to
-set up a simple DNS-based load balancing system where the name server
-answers queries about a single DNS name with a dynamically changing
-set of A records.
-
-BIND 9.1 introduced a new, simplified database interface, or "sdb",
-which greatly simplifies the writing of drivers for these kinds of
-applications.
-
-
-The sdb Driver
-
-An sdb driver is an object module, typically written in C, which is
-linked into the name server and registers itself with the sdb
-subsystem.  It provides a set of callback functions, which also serve
-to advertise its capabilities.  When the name server receives DNS
-queries, invokes the callback functions to obtain the data to respond
-with.
-
-Unlike the full database interface, the sdb interface represents all
-domain names and resource records as ASCII text.
-
-
-Writing an sdb Driver
-
-When a driver is registered, it specifies its name, a list of callback
-functions, and flags.
-
-The flags specify whether the driver wants to use relative domain
-names where possible.
-
-The callback functions are as follows.  The only one that must be
-defined is lookup().
-
-  - create(zone, argc, argv, driverdata, dbdata)
-	  Create a database object for "zone".
-
-  - destroy(zone, driverdata, dbdata)
-	  Destroy the database object for "zone".
-
-  - lookup(zone, name, dbdata, lookup)
-	  Return all the records at the domain name "name".
-
-  - authority(zone, dbdata, lookup)
-	  Return the SOA and NS records at the zone apex.
-
-  - allnodes(zone, dbdata, allnodes)
-	  Return all data in the zone, for zone transfers.
-
-For more detail about these functions and their parameters, see
-bind9/lib/dns/include/dns/sdb.h.  For example drivers, see
-bind9/contrib/sdb.
-
-
-Rebuilding the Server
-
-The driver module and header file must be copied to (or linked into)
-the bind9/bin/named and bind9/bin/named/include directories
-respectively, and must be added to the DBDRIVER_OBJS and DBDRIVER_SRCS
-lines in bin/named/Makefile.in (e.g. for the timedb sample sdb driver,
-add timedb.c to DBDRIVER_SRCS and timedb.@O@ to DBDRIVER_OBJS).  If
-the driver needs additional header files or libraries in nonstandard
-places, the DBDRIVER_INCLUDES and DBDRIVER_LIBS lines should also be
-updated.
-
-Calls to dns_sdb_register() and dns_sdb_unregister() (or wrappers,
-e.g. timedb_init() and timedb_clear() for the timedb sample sdb
-driver) must be inserted into the server, in bind9/bin/named/main.c.
-Registration should be in setup(), before the call to
-ns_server_create().  Unregistration should be in cleanup(),
-after the call to ns_server_destroy().  A #include should be added
-corresponding to the driver header file.
-
-You should try doing this with one or more of the sample drivers
-before attempting to write a driver of your own.
-
-
-Configuring the Server
-
-To make a zone use a new database driver, specify a "database" option
-in its "zone" statement in named.conf.  For example, if the driver
-registers itself under the name "acmedb", you might say
-
-   zone "foo.com" {
-	   database "acmedb";
-   };
-
-You can pass arbitrary arguments to the create() function of the
-driver by adding any number of whitespace-separated words after the
-driver name:
-
-   zone "foo.com" {
-	   database "acmedb -mode sql -connect 10.0.0.1";
-   };
-
-
-Hints for Driver Writers
-
- - If a driver is generating data on the fly, it probably should
-   not implement the allnodes() function, since a zone transfer
-   will not be meaningful.  The allnodes() function is more relevant
-   with data from a database.
-
- - The authority() function is necessary if and only if the lookup()
-   function will not add SOA and NS records at the zone apex.  If
-   SOA and NS records are provided by the lookup() function,
-   the authority() function should be NULL.
-
- - When a driver is registered, an opaque object can be provided.  This
-   object is passed into the database create() and destroy() functions.
-
- - When a database is created, an opaque object can be created that
-   is associated with that database.  This object is passed into the
-   lookup(), authority(), and allnodes() functions, and is
-   destroyed by the destroy() function.
-
-
-Future Directions
-
-A future release may support dynamic loading of sdb drivers.
-
-
-$Id: sdb,v 1.6 2004/03/05 05:04:54 marka Exp $
diff --git a/contrib/bind9/doc/rfc/index b/contrib/bind9/doc/rfc/index
deleted file mode 100644
index 990d4a9..0000000
--- a/contrib/bind9/doc/rfc/index
+++ /dev/null
@@ -1,114 +0,0 @@
- 952:	DOD INTERNET HOST TABLE SPECIFICATION
-1032:	DOMAIN ADMINISTRATORS GUIDE
-1033:	DOMAIN ADMINISTRATORS OPERATIONS GUIDE
-1034:	DOMAIN NAMES - CONCEPTS AND FACILITIES
-1035:	DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
-1101:	DNS Encoding of Network Names and Other Types
-1122:	Requirements for Internet Hosts -- Communication Layers
-1123:	Requirements for Internet Hosts -- Application and Support
-1183:	New DNS RR Definitions (AFSDB, RP, X25, ISDN and RT)
-1348:	DNS NSAP RRs
-1535:	A Security Problem and Proposed Correction
-	   With Widely Deployed DNS Software
-1536:	Common DNS Implementation Errors and Suggested Fixes
-1537:	Common DNS Data File Configuration Errors
-1591:	Domain Name System Structure and Delegation
-1611:	DNS Server MIB Extensions
-1612:	DNS Resolver MIB Extensions
-1706:	DNS NSAP Resource Records
-1712:	DNS Encoding of Geographical Location
-1750:	Randomness Recommendations for Security
-1876:	A Means for Expressing Location Information in the Domain Name System
-1886:	DNS Extensions to support IP version 6
-1982:	Serial Number Arithmetic
-1995:	Incremental Zone Transfer in DNS
-1996:	A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
-2052:	A DNS RR for specifying the location of services (DNS SRV)
-2104:	HMAC: Keyed-Hashing for Message Authentication
-2119:	Key words for use in RFCs to Indicate Requirement Levels
-2133:	Basic Socket Interface Extensions for IPv6
-2136:	Dynamic Updates in the Domain Name System (DNS UPDATE)
-2137:	Secure Domain Name System Dynamic Update
-2163:	Using the Internet DNS to Distribute MIXER
-	 Conformant Global Address Mapping (MCGAM)
-2168:	Resolution of Uniform Resource Identifiers using the Domain Name System
-2181:	Clarifications to the DNS Specification
-2230:	Key Exchange Delegation Record for the DNS
-2308:	Negative Caching of DNS Queries (DNS NCACHE)
-2317:	Classless IN-ADDR.ARPA delegation
-2373:	IP Version 6 Addressing Architecture
-2374:	An IPv6 Aggregatable Global Unicast Address Format
-2375:	IPv6 Multicast Address Assignments
-2418:	IETF Working Group Guidelines and Procedures
-2535:	Domain Name System Security Extensions
-2536:	DSA KEYs and SIGs in the Domain Name System (DNS)
-2537:	RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)
-2538:	Storing Certificates in the Domain Name System (DNS)
-2539:	Storage of Diffie-Hellman Keys in the Domain Name System (DNS)
-2540:	Detached Domain Name System (DNS) Information
-2541:	DNS Security Operational Considerations
-2553:	Basic Socket Interface Extensions for IPv6
-2671:	Extension Mechanisms for DNS (EDNS0)
-2672:	Non-Terminal DNS Name Redirection
-2673:	Binary Labels in the Domain Name System
-2782:	A DNS RR for specifying the location of services (DNS SRV)
-2825:	A Tangled Web: Issues of I18N, Domain Names, and the
-	 Other Internet protocols
-2826:	IAB Technical Comment on the Unique DNS Root
-2845:	Secret Key Transaction Authentication for DNS (TSIG)
-2874:	DNS Extensions to Support IPv6 Address Aggregation and Renumbering
-2915:	The Naming Authority Pointer (NAPTR) DNS Resource Record
-2929:	Domain Name System (DNS) IANA Considerations
-2930:	Secret Key Establishment for DNS (TKEY RR)
-2931:	DNS Request and Transaction Signatures ( SIG(0)s )
-3007:	Secure Domain Name System (DNS) Dynamic Update
-3008:	Domain Name System Security (DNSSEC) Signing Authority
-3071:	Reflections on the DNS, RFC 1591, and Categories of Domains
-3090:	DNS Security Extension Clarification on Zone Status
-3110:	RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)
-3123:	A DNS RR Type for Lists of Address Prefixes (APL RR)
-3152:	Delegation of IP6.ARPA
-3197:	Applicability Statement for DNS MIB Extensions
-3225:	Indicating Resolver Support of DNSSEC
-3226:	DNSSEC and IPv6 A6 aware server/resolver message size requirements
-3258:	Distributing Authoritative Name Servers via Shared Unicast Addresses
-3363:	Representing Internet Protocol version 6 (IPv6)
-	 Addresses in the Domain Name System (DNS)
-3364:	Tradeoffs in Domain Name System (DNS) Support
-	 for Internet Protocol version 6 (IPv6)
-3425:	Obsoleting IQUERY
-3445:	Limiting the Scope of the KEY Resource Record (RR)
-3490:	Internationalizing Domain Names In Applications (IDNA)
-3491:	Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)
-3492:	Punycode:A Bootstring encoding of Unicode for
-	  Internationalized Domain Names in Applications (IDNA)
-3493:	Basic Socket Interface Extensions for IPv6
-3513:	Internet Protocol Version 6 (IPv6) Addressing Architecture
-3596:	DNS Extensions to Support IP Version 6
-3597:	Handling of Unknown DNS Resource Record (RR) Types
-3645:	Generic Security Service Algorithm for
-	  Secret Key Transaction Authentication for DNS (GSS-TSIG)
-3655:	Redefinition of DNS Authenticated Data (AD) bit
-3658:	Delegation Signer (DS) Resource Record (RR)
-3757:	Domain Name System KEY (DNSKEY) Resource Record (RR)
-	  Secure Entry Point (SEP) Flag
-3833:	Threat Analysis of the Domain Name System (DNS)
-3845:	DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format
-3901:	DNS IPv6 Transport Operational Guidelines
-4025:	A Method for Storing IPsec Keying Material in DNS
-4033:	DNS Security Introduction and Requirements
-4034:	Resource Records for the DNS Security Extensions
-4035:	Protocol Modifications for the DNS Security Extensions
-4074:	Common Misbehavior Against DNS Queries for IPv6 Addresses
-4159:	Deprecation of "ip6.int"
-4193:	Unique Local IPv6 Unicast Addresses
-4255:	Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints
-4343:	Domain Name System (DNS) Case Insensitivity Clarification
-4367:	What's in a Name: False Assumptions about DNS Names
-4398:	Storing Certificates in the Domain Name System (DNS)
-4431:	The DNSSEC Lookaside Validation (DLV) DNS Resource Record
-4408:	Sender Policy Framework (SPF) for Authorizing Use of Domains
-	 in E-Mail, Version 1
-4470:	Minimally Covering NSEC Records and DNSSEC On-line Signing
-4634:	US Secure Hash Algorithms (SHA and HMAC-SHA)
-4641:	DNSSEC Operational Practices
diff --git a/contrib/bind9/doc/rfc/rfc1032.txt b/contrib/bind9/doc/rfc/rfc1032.txt
deleted file mode 100644
index 0e82721..0000000
--- a/contrib/bind9/doc/rfc/rfc1032.txt
+++ /dev/null
@@ -1,781 +0,0 @@
-Network Working Group                                       M. Stahl
-Request for Comments: 1032                         SRI International
-                                                       November 1987
-
-
-                      DOMAIN ADMINISTRATORS GUIDE
-
-
-STATUS OF THIS MEMO
-
-   This memo describes procedures for registering a domain with the
-   Network Information Center (NIC) of Defense Data Network (DDN), and
-   offers guidelines on the establishment and administration of a domain
-   in accordance with the requirements specified in RFC-920.  It is
-   intended for use by domain administrators.  This memo should be used
-   in conjunction with RFC-920, which is an official policy statement of
-   the Internet Activities Board (IAB) and the Defense Advanced Research
-   Projects Agency (DARPA).  Distribution of this memo is unlimited.
-
-BACKGROUND
-
-   Domains are administrative entities that provide decentralized
-   management of host naming and addressing.  The domain-naming system
-   is distributed and hierarchical.
-
-   The NIC is designated by the Defense Communications Agency (DCA) to
-   provide registry services for the domain-naming system on the DDN and
-   DARPA portions of the Internet.
-
-   As registrar of top-level and second-level domains, as well as
-   administrator of the root domain name servers on behalf of DARPA and
-   DDN, the NIC is responsible for maintaining the root server zone
-   files and their binary equivalents.  In addition, the NIC is
-   responsible for administering the top-level domains of "ARPA," "COM,"
-   "EDU," "ORG," "GOV," and "MIL" on behalf of DCA and DARPA until it
-   becomes feasible for other appropriate organizations to assume those
-   responsibilities.
-
-   It is recommended that the guidelines described in this document be
-   used by domain administrators in the establishment and control of
-   second-level domains.
-
-THE DOMAIN ADMINISTRATOR
-
-   The role of the domain administrator (DA) is that of coordinator,
-   manager, and technician.  If his domain is established at the second
-   level or lower in the tree, the DA must register by interacting with
-   the management of the domain directly above his, making certain that
-
-
-
-Stahl                                                           [Page 1]
-
-RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
-
-
-   his domain satisfies all the requirements of the administration under
-   which his domain would be situated.  To find out who has authority
-   over the name space he wishes to join, the DA can ask the NIC
-   Hostmaster.  Information on contacts for the top-level and second-
-   level domains can also be found on line in the file NETINFO:DOMAIN-
-   CONTACTS.TXT, which is available from the NIC via anonymous FTP.
-
-   The DA should be technically competent; he should understand the
-   concepts and procedures for operating a domain server, as described
-   in RFC-1034, and make sure that the service provided is reliable and
-   uninterrupted.  It is his responsibility or that of his delegate to
-   ensure that the data will be current at all times.  As a manager, the
-   DA must be able to handle complaints about service provided by his
-   domain name server.  He must be aware of the behavior of the hosts in
-   his domain, and take prompt action on reports of problems, such as
-   protocol violations or other serious misbehavior.  The administrator
-   of a domain must be a responsible person who has the authority to
-   either enforce these actions himself or delegate them to someone
-   else.
-
-   Name assignments within a domain are controlled by the DA, who should
-   verify that names are unique within his domain and that they conform
-   to standard naming conventions.  He furnishes access to names and
-   name-related information to users both inside and outside his domain.
-   He should work closely with the personnel he has designated as the
-   "technical and zone" contacts for his domain, for many administrative
-   decisions will be made on the basis of input from these people.
-
-THE DOMAIN TECHNICAL AND ZONE CONTACT
-
-   A zone consists of those contiguous parts of the domain tree for
-   which a domain server has complete information and over which it has
-   authority.  A domain server may be authoritative for more than one
-   zone.  The domain technical/zone contact is the person who tends to
-   the technical aspects of maintaining the domain's name server and
-   resolver software, and database files.  He keeps the name server
-   running, and interacts with technical people in other domains and
-   zones to solve problems that affect his zone.
-
-POLICIES
-
-   Domain or host name choices and the allocation of domain name space
-   are considered to be local matters.  In the event of conflicts, it is
-   the policy of the NIC not to get involved in local disputes or in the
-   local decision-making process.  The NIC will not act as referee in
-   disputes over such matters as who has the "right" to register a
-   particular top-level or second-level domain for an organization.  The
-   NIC considers this a private local matter that must be settled among
-
-
-
-Stahl                                                           [Page 2]
-
-RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
-
-
-   the parties involved prior to their commencing the registration
-   process with the NIC.  Therefore, it is assumed that the responsible
-   person for a domain will have resolved any local conflicts among the
-   members of his domain before registering that domain with the NIC.
-   The NIC will give guidance, if requested, by answering specific
-   technical questions, but will not provide arbitration in disputes at
-   the local level.  This policy is also in keeping with the distributed
-   hierarchical nature of the domain-naming system in that it helps to
-   distribute the tasks of solving problems and handling questions.
-
-   Naming conventions for hosts should follow the rules specified in
-   RFC-952.  From a technical standpoint, domain names can be very long.
-   Each segment of a domain name may contain up to 64 characters, but
-   the NIC strongly advises DAs to choose names that are 12 characters
-   or fewer, because behind every domain system there is a human being
-   who must keep track of the names, addresses, contacts, and other data
-   in a database.  The longer the name, the more likely the data
-   maintainer is to make a mistake.  Users also will appreciate shorter
-   names.  Most people agree that short names are easier to remember and
-   type; most domain names registered so far are 12 characters or fewer.
-
-   Domain name assignments are made on a first-come-first-served basis.
-   The NIC has chosen not to register individual hosts directly under
-   the top-level domains it administers.  One advantage of the domain
-   naming system is that administration and data maintenance can be
-   delegated down a hierarchical tree.  Registration of hosts at the
-   same level in the tree as a second-level domain would dilute the
-   usefulness of this feature.  In addition, the administrator of a
-   domain is responsible for the actions of hosts within his domain.  We
-   would not want to find ourselves in the awkward position of policing
-   the actions of individual hosts.  Rather, the subdomains registered
-   under these top-level domains retain the responsibility for this
-   function.
-
-   Countries that wish to be registered as top-level domains are
-   required to name themselves after the two-letter country code listed
-   in the international standard ISO-3166.  In some cases, however, the
-   two-letter ISO country code is identical to a state code used by the
-   U.S. Postal Service.  Requests made by countries to use the three-
-   letter form of country code specified in the ISO-3166 standard will
-   be considered in such cases so as to prevent possible conflicts and
-   confusion.
-
-
-
-
-
-
-
-
-
-Stahl                                                           [Page 3]
-
-RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
-
-
-HOW TO REGISTER
-
-   Obtain a domain questionnaire from the NIC hostmaster, or FTP the
-   file NETINFO:DOMAIN-TEMPLATE.TXT from host SRI-NIC.ARPA.
-
-   Fill out the questionnaire completely.  Return it via electronic mail
-   to HOSTMASTER@SRI-NIC.ARPA.
-
-   The APPENDIX to this memo contains the application form for
-   registering a top-level or second-level domain with the NIC.  It
-   supersedes the version of the questionnaire found in RFC-920.  The
-   application should be submitted by the person administratively
-   responsible for the domain, and must be filled out completely before
-   the NIC will authorize establishment of a top-level or second-level
-   domain.  The DA is responsible for keeping his domain's data current
-   with the NIC or with the registration agent with which his domain is
-   registered.  For example, the CSNET and UUCP managements act as
-   domain filters, processing domain applications for their own
-   organizations.  They pass pertinent information along periodically to
-   the NIC for incorporation into the domain database and root server
-   files.  The online file NETINFO:ALTERNATE-DOMAIN-PROCEDURE.TXT
-   outlines this procedure.  It is highly recommended that the DA review
-   this information periodically and provide any corrections or
-   additions.  Corrections should be submitted via electronic mail.
-
-WHICH DOMAIN NAME?
-
-   The designers of the domain-naming system initiated several general
-   categories of names as top-level domain names, so that each could
-   accommodate a variety of organizations.  The current top-level
-   domains registered with the DDN Network Information Center are ARPA,
-   COM, EDU, GOV, MIL, NET, and ORG, plus a number of top-level country
-   domains.  To join one of these, a DA needs to be aware of the purpose
-   for which it was intended.
-
-      "ARPA" is a temporary domain.  It is by default appended to the
-      names of hosts that have not yet joined a domain.  When the system
-      was begun in 1984, the names of all hosts in the Official DoD
-      Internet Host Table maintained by the NIC were changed by adding
-      of the label ".ARPA" in order to accelerate a transition to the
-      domain-naming system.  Another reason for the blanket name changes
-      was to force hosts to become accustomed to using the new style
-      names and to modify their network software, if necessary.  This
-      was done on a network-wide basis and was directed by DCA in DDN
-      Management Bulletin No. 22.  Hosts that fall into this domain will
-      eventually move to other branches of the domain tree.
-
-
-
-
-
-Stahl                                                           [Page 4]
-
-RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
-
-
-      "COM" is meant to incorporate subdomains of companies and
-      businesses.
-
-      "EDU" was initiated to accommodate subdomains set up by
-      universities and other educational institutions.
-
-      "GOV" exists to act as parent domain for subdomains set up by
-      government agencies.
-
-      "MIL" was initiated to act as parent to subdomains that are
-      developed by military organizations.
-
-      "NET" was introduced as a parent domain for various network-type
-      organizations.  Organizations that belong within this top-level
-      domain are generic or network-specific, such as network service
-      centers and consortia.  "NET" also encompasses network
-      management-related organizations, such as information centers and
-      operations centers.
-
-      "ORG" exists as a parent to subdomains that do not clearly fall
-      within the other top-level domains.  This may include technical-
-      support groups, professional societies, or similar organizations.
-
-   One of the guidelines in effect in the domain-naming system is that a
-   host should have only one name regardless of what networks it is
-   connected to.  This implies, that, in general, domain names should
-   not include routing information or addresses.  For example, a host
-   that has one network connection to the Internet and another to BITNET
-   should use the same name when talking to either network.  For a
-   description of the syntax of domain names, please refer to Section 3
-   of RFC-1034.
-
-VERIFICATION OF DATA
-
-   The verification process can be accomplished in several ways.  One of
-   these is through the NIC WHOIS server.  If he has access to WHOIS,
-   the DA can type the command "whois domain <domain name><return>".
-   The reply from WHOIS will supply the following: the name and address
-   of the organization "owning" the domain; the name of the domain; its
-   administrative, technical, and zone contacts; the host names and
-   network addresses of sites providing name service for the domain.
-
-
-
-
-
-
-
-
-
-
-Stahl                                                           [Page 5]
-
-RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
-
-
-         Example:
-
-         @whois domain rice.edu<Return>
-
-            Rice University (RICE-DOM)
-            Advanced Studies and Research
-            Houston, TX 77001
-
-            Domain Name: RICE.EDU
-
-               Administrative Contact:
-               Kennedy, Ken  (KK28)  Kennedy@LLL-CRG.ARPA (713) 527-4834
-               Technical Contact, Zone Contact:
-               Riffle, Vicky R.  (VRR)  rif@RICE.EDU
-               (713) 527-8101 ext 3844
-
-            Domain servers:
-
-            RICE.EDU                     128.42.5.1
-            PENDRAGON.CS.PURDUE.EDU      128.10.2.5
-
-
-   Alternatively, the DA can send an electronic mail message to
-   SERVICE@SRI-NIC.ARPA.  In the subject line of the message header, the
-   DA should type "whois domain <domain name>".  The requested
-   information will be returned via electronic mail.  This method is
-   convenient for sites that do not have access to the NIC WHOIS
-   service.
-
-   The initial application for domain authorization should be submitted
-   via electronic mail, if possible, to HOSTMASTER@SRI-NIC.ARPA.  The
-   questionnaire described in the appendix may be used or a separate
-   application can be FTPed from host SRI-NIC.ARPA.  The information
-   provided by the administrator will be reviewed by hostmaster
-   personnel for completeness.  There will most likely be a few
-   exchanges of correspondence via electronic mail, the preferred method
-   of communication, prior to authorization of the domain.
-
-HOW TO GET MORE INFORMATION
-
-   An informational table of the top-level domains and their root
-   servers is contained in the file NETINFO:DOMAINS.TXT online at SRI-
-   NIC.ARPA. This table can be obtained by FTPing the file.
-   Alternatively, the information can be acquired by opening a TCP or
-   UDP connection to the NIC Host Name Server, port 101 on SRI-NIC.ARPA,
-   and invoking the command "ALL-DOM".
-
-
-
-
-
-Stahl                                                           [Page 6]
-
-RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
-
-
-   The following online files, all available by FTP from SRI-NIC.ARPA,
-   contain pertinent domain information:
-
-      - NETINFO:DOMAINS.TXT, a table of all top-level domains and the
-        network addresses of the machines providing domain name
-        service for them.  It is updated each time a new top-level
-        domain is approved.
-
-      - NETINFO:DOMAIN-INFO.TXT contains a concise list of all
-        top-level and second-level domain names registered with the
-        NIC and is updated monthly.
-
-      - NETINFO:DOMAIN-CONTACTS.TXT also contains a list of all the
-        top level and second-level domains, but includes the
-        administrative, technical and zone contacts for each as well.
-
-      - NETINFO:DOMAIN-TEMPLATE.TXT contains the questionnaire to be
-        completed before registering a top-level or second-level
-        domain.
-
-   For either general or specific information on the domain system, do
-   one or more of the following:
-
-      1. Send electronic mail to HOSTMASTER@SRI-NIC.ARPA
-
-      2. Call the toll-free NIC hotline at (800) 235-3155
-
-      3. Use FTP to get background RFCs and other files maintained
-         online at the NIC.  Some pertinent RFCs are listed below in
-         the REFERENCES section of this memo.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stahl                                                           [Page 7]
-
-RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
-
-
-REFERENCES
-
-   The references listed here provide important background information
-   on the domain-naming system.  Path names of the online files
-   available via anonymous FTP from the SRI-NIC.ARPA host are noted in
-   brackets.
-
-      1. Defense Communications Agency DDN Defense Communications
-         System, DDN Management Bulletin No. 22, Domain Names
-         Transition, March 1984.
-         [ DDN-NEWS:DDN-MGT-BULLETIN-22.TXT ]
-
-      2. Defense Communications Agency DDN Defense Communications
-         System, DDN Management Bulletin No. 32, Phase I of the Domain
-         Name Implementation, January 1987.
-         [ DDN-NEWS:DDN-MGT-BULLETIN-32.TXT ]
-
-      3. Harrenstien, K., M. Stahl, and E. Feinler, "Hostname
-         Server", RFC-953, DDN Network Information Center, SRI
-         International, October 1985.  [ RFC:RFC953.TXT ]
-
-      4. Harrenstien, K., M. Stahl, and E. Feinler, "Official DoD
-         Internet Host Table Specification", RFC-952, DDN Network
-         Information Center, SRI International, October 1985.
-         [ RFC:RFC952.TXT ]
-
-      5. ISO, "Codes for the Representation of Names of Countries",
-         ISO-3166, International Standards Organization, May 1981.
-         [ Not online ]
-
-      6. Lazear, W.D., "MILNET Name Domain Transition", RFC-1031,
-         Mitre Corporation, October 1987.  [ RFC:RFC1031.TXT ]
-
-      7. Lottor, M.K., "Domain Administrators Operations Guide",
-         RFC-1033, DDN Network Information Center, SRI International,
-         July 1987.  [ RFC:RFC1033.TXT ]
-
-      8. Mockapetris, P., "Domain Names - Concepts and Facilities",
-         RFC-1034, USC Information Sciences Institute, October 1987.
-         [ RFC:RFC1034.TXT ]
-
-      9. Mockapetris, P., "Domain Names - Implementation and
-         Specification", RFC-1035, USC Information Sciences Institute,
-         October 1987.  [ RFC:RFC1035.TXT ]
-
-     10. Mockapetris, P., "The Domain Name System", Proceedings of the
-         IFIP 6.5 Working Conference on Computer Message Services,
-         Nottingham, England, May 1984.  Also as ISI/RS-84-133, June
-
-
-
-Stahl                                                           [Page 8]
-
-RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
-
-
-         1984.  [ Not online ]
-
-     11. Mockapetris, P., J. Postel, and P. Kirton, "Name Server
-         Design for Distributed Systems", Proceedings of the Seventh
-         International Conference on Computer Communication, October
-         30 to November 3 1984, Sidney, Australia.  Also as
-         ISI/RS-84-132, June 1984.  [ Not online ]
-
-     12. Partridge, C., "Mail Routing and the Domain System", RFC-974,
-         CSNET-CIC, BBN Laboratories, January 1986.
-         [ RFC:RFC974.TXT ]
-
-     13. Postel, J., "The Domain Names Plan and Schedule", RFC-881,
-         USC Information Sciences Institute, November 1983.
-         [ RFC:RFC881.TXT ]
-
-     14. Reynolds, J., and Postel, J., "Assigned Numbers", RFC-1010
-         USC Information Sciences Institute, May 1986.
-         [ RFC:RFC1010.TXT ]
-
-     15. Romano, S., and Stahl, M., "Internet Numbers", RFC-1020,
-         SRI, November 1987.
-         [ RFC:RFC1020.TXT ]
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stahl                                                           [Page 9]
-
-RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
-
-
-APPENDIX
-
-   The following questionnaire may be FTPed from SRI-NIC.ARPA as
-   NETINFO:DOMAIN-TEMPLATE.TXT.
-
-   ---------------------------------------------------------------------
-
-   To establish a domain, the following information must be sent to the
-   NIC Domain Registrar (HOSTMASTER@SRI-NIC.ARPA):
-
-   NOTE: The key people must have electronic mailboxes and NIC
-   "handles," unique NIC database identifiers.  If you have access to
-   "WHOIS", please check to see if you are registered and if so, make
-   sure the information is current.  Include only your handle and any
-   changes (if any) that need to be made in your entry.  If you do not
-   have access to "WHOIS", please provide all the information indicated
-   and a NIC handle will be assigned.
-
-   (1)  The name of the top-level domain to join.
-
-         For example:  COM
-
-   (2) The NIC handle of the administrative head of the organization.
-   Alternately, the person's name, title, mailing address, phone number,
-   organization, and network mailbox.  This is the contact point for
-   administrative and policy questions about the domain.  In the case of
-   a research project, this should be the principal investigator.
-
-         For example:
-
-            Administrator
-
-               Organization  The NetWorthy Corporation
-               Name          Penelope Q. Sassafrass
-               Title         President
-               Mail Address  The NetWorthy Corporation
-                             4676 Andrews Way, Suite 100
-                             Santa Clara, CA 94302-1212
-               Phone Number  (415) 123-4567
-               Net Mailbox   Sassafrass@ECHO.TNC.COM
-               NIC Handle    PQS
-
-   (3)  The NIC handle of the technical contact for the domain.
-   Alternately, the person's name, title, mailing address, phone number,
-   organization, and network mailbox.  This is the contact point for
-   problems concerning the domain or zone, as well as for updating
-   information about the domain or zone.
-
-
-
-
-Stahl                                                          [Page 10]
-
-RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
-
-
-         For example:
-
-            Technical and Zone Contact
-
-               Organization  The NetWorthy Corporation
-               Name          Ansel A. Aardvark
-               Title         Executive Director
-               Mail Address  The NetWorthy Corporation
-                             4676 Andrews Way, Suite 100
-                             Santa Clara, CA. 94302-1212
-               Phone Number  (415) 123-6789
-               Net Mailbox   Aardvark@ECHO.TNC.COM
-               NIC Handle    AAA2
-
-   (4)  The name of the domain (up to 12 characters).  This is the name
-   that will be used in tables and lists associating the domain with the
-   domain server addresses.  [While, from a technical standpoint, domain
-   names can be quite long (programmers beware), shorter names are
-   easier for people to cope with.]
-
-         For example:  TNC
-
-   (5)  A description of the servers that provide the domain service for
-   translating names to addresses for hosts in this domain, and the date
-   they will be operational.
-
-         A good way to answer this question is to say "Our server is
-         supplied by person or company X and does whatever their standard
-         issue server does."
-
-            For example:  Our server is a copy of the one operated by
-            the NIC; it will be installed and made operational on
-            1 November 1987.
-
-   (6) Domains must provide at least two independent servers for the
-   domain.  Establishing the servers in physically separate locations
-   and on different PSNs is strongly recommended.  A description of the
-   server machine and its backup, including
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stahl                                                          [Page 11]
-
-RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
-
-
-         (a) Hardware and software (using keywords from the Assigned
-         Numbers RFC).
-
-         (b) Host domain name and network addresses (which host on which
-         network for each connected network).
-
-         (c) Any domain-style nicknames (please limit your domain-style
-         nickname request to one)
-
-         For example:
-
-            - Hardware and software
-
-               VAX-11/750  and  UNIX,    or
-               IBM-PC      and  MS-DOS,  or
-               DEC-1090    and  TOPS-20
-
-            - Host domain names and network addresses
-
-               BAR.FOO.COM 10.9.0.193 on ARPANET
-
-            - Domain-style nickname
-
-               BR.FOO.COM (same as BAR.FOO.COM 10.9.0.13 on ARPANET)
-
-   (7)  Planned mapping of names of any other network hosts, other than
-   the server machines, into the new domain's naming space.
-
-         For example:
-
-            BAR-FOO2.ARPA (10.8.0.193) -> FOO2.BAR.COM
-            BAR-FOO3.ARPA (10.7.0.193) -> FOO3.BAR.COM
-            BAR-FOO4.ARPA (10.6.0.193) -> FOO4.BAR.COM
-
-
-   (8)  An estimate of the number of hosts that will be in the domain.
-
-         (a) Initially
-         (b) Within one year
-         (c) Two years
-         (d) Five years.
-
-         For example:
-
-            (a) Initially  =   50
-            (b) One year   =  100
-            (c) Two years  =  200
-            (d) Five years =  500
-
-
-
-Stahl                                                          [Page 12]
-
-RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
-
-
-   (9)  The date you expect the fully qualified domain name to become
-   the official host name in HOSTS.TXT.
-
-         Please note: If changing to a fully qualified domain name (e.g.,
-         FOO.BAR.COM) causes a change in the official host name of an
-         ARPANET or MILNET host, DCA approval must be obtained beforehand.
-         Allow 10 working days for your requested changes to be processed.
-
-         ARPANET sites should contact ARPANETMGR@DDN1.ARPA.  MILNET sites
-         should contact HOSTMASTER@SRI-NIC.ARPA, 800-235-3155, for
-         further instructions.
-
-   (10) Please describe your organization briefly.
-
-         For example: The NetWorthy Corporation is a consulting
-         organization of people working with UNIX and the C language in an
-         electronic networking environment.  It sponsors two technical
-         conferences annually and distributes a bimonthly newsletter.
-
-   ---------------------------------------------------------------------
-
-   This example of a completed application corresponds to the examples
-   found in the companion document RFC-1033, "Domain Administrators
-   Operations Guide."
-
-   (1)  The name of the top-level domain to join.
-
-            COM
-
-   (2)  The NIC handle of the administrative contact person.
-
-            NIC Handle    JAKE
-
-   (3)  The NIC handle of the domain's technical and zone
-         contact person.
-
-            NIC Handle    DLE6
-
-   (4)  The name of the domain.
-
-            SRI
-
-   (5)  A description of the servers.
-
-            Our server is the TOPS20 server JEEVES supplied by ISI; it
-            will be installed and made operational on 1 July 1987.
-
-
-
-
-
-Stahl                                                          [Page 13]
-
-RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
-
-
-   (6)  A description of the server machine and its backup:
-
-            (a) Hardware and software
-
-               DEC-1090T   and  TOPS20
-               DEC-2065    and  TOPS20
-
-            (b) Host domain name and network address
-
-               KL.SRI.COM  10.1.0.2 on ARPANET, 128.18.10.6 on SRINET
-               STRIPE.SRI.COM  10.4.0.2 on ARPANET, 128.18.10.4 on SRINET
-
-            (c) Domain-style nickname
-
-               None
-
-   (7)  Planned mapping of names of any other network hosts, other than
-   the server machines, into the new domain's naming space.
-
-            SRI-Blackjack.ARPA (128.18.2.1) -> Blackjack.SRI.COM
-            SRI-CSL.ARPA (192.12.33.2) -> CSL.SRI.COM
-
-   (8)  An estimate of the number of hosts that will be directly within
-   this domain.
-
-            (a) Initially  =   50
-            (b) One year   =  100
-            (c) Two years  =  200
-            (d) Five years =  500
-
-   (9)  A date when you expect the fully qualified domain name to become
-   the official host name in HOSTS.TXT.
-
-            31 September 1987
-
-   (10)  Brief description of organization.
-
-            SRI International is an independent, nonprofit, scientific
-            research organization.  It performs basic and applied research
-            for government and commercial clients, and contributes to
-            worldwide economic, scientific, industrial, and social progress
-            through research and related services.
-
-
-
-
-
-
-
-
-
-Stahl                                                          [Page 14]
-
diff --git a/contrib/bind9/doc/rfc/rfc1033.txt b/contrib/bind9/doc/rfc/rfc1033.txt
deleted file mode 100644
index 37029fd..0000000
--- a/contrib/bind9/doc/rfc/rfc1033.txt
+++ /dev/null
@@ -1,1229 +0,0 @@
-Network Working Group                                         M. Lottor
-Request For Comments:  1033                           SRI International
-                                                          November 1987
-
-
-                 DOMAIN ADMINISTRATORS OPERATIONS GUIDE
-
-
-
-STATUS OF THIS MEMO
-
-   This RFC provides guidelines for domain administrators in operating a
-   domain server and maintaining their portion of the hierarchical
-   database.  Familiarity with the domain system is assumed.
-   Distribution of this memo is unlimited.
-
-ACKNOWLEDGMENTS
-
-   This memo is a formatted collection of notes and excerpts from the
-   references listed at the end of this document.  Of particular mention
-   are Paul Mockapetris and Kevin Dunlap.
-
-INTRODUCTION
-
-   A domain server requires a few files to get started.  It will
-   normally have some number of boot/startup files (also known as the
-   "safety belt" files).  One section will contain a list of possible
-   root servers that the server will use to find the up-to-date list of
-   root servers.  Another section will list the zone files to be loaded
-   into the server for your local domain information.  A zone file
-   typically contains all the data for a particular domain.  This guide
-   describes the data formats that can be used in zone files and
-   suggested parameters to use for certain fields.  If you are
-   attempting to do anything advanced or tricky, consult the appropriate
-   domain RFC's for more details.
-
-   Note:  Each implementation of domain software may require different
-   files.  Zone files are standardized but some servers may require
-   other startup files.  See the appropriate documentation that comes
-   with your software.  See the appendix for some specific examples.
-
-ZONES
-
-   A zone defines the contents of a contiguous section of the domain
-   space, usually bounded by administrative boundaries.  There will
-   typically be a separate data file for each zone.  The data contained
-   in a zone file is composed of entries called Resource Records (RRs).
-
-
-
-
-Lottor                                                          [Page 1]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-   You may only put data in your domain server that you are
-   authoritative for.  You must not add entries for domains other than
-   your own (except for the special case of "glue records").
-
-   A domain server will probably read a file on start-up that lists the
-   zones it should load into its database.  The format of this file is
-   not standardized and is different for most domain server
-   implementations.  For each zone it will normally contain the domain
-   name of the zone and the file name that contains the data to load for
-   the zone.
-
-ROOT SERVERS
-
-   A resolver will need to find the root servers when it first starts.
-   When the resolver boots, it will typically read a list of possible
-   root servers from a file.
-
-   The resolver will cycle through the list trying to contact each one.
-   When it finds a root server, it will ask it for the current list of
-   root servers.  It will then discard the list of root servers it read
-   from the data file and replace it with the current list it received.
-
-   Root servers will not change very often.  You can get the names of
-   current root servers from the NIC.
-
-   FTP the file NETINFO:ROOT-SERVERS.TXT or send a mail request to
-   NIC@SRI-NIC.ARPA.
-
-   As of this date (June 1987) they are:
-
-           SRI-NIC.ARPA       10.0.0.51    26.0.0.73
-           C.ISI.EDU          10.0.0.52
-           BRL-AOS.ARPA       192.5.25.82  192.5.22.82   128.20.1.2
-           A.ISI.EDU          26.3.0.103
-
-RESOURCE RECORDS
-
-   Records in the zone data files are called resource records (RRs).
-   They are specified in RFC-883 and RFC-973.  An RR has a standard
-   format as shown:
-
-           <name>   [<ttl>]   [<class>]   <type>   <data>
-
-   The record is divided into fields which are separated by white space.
-
-      <name>
-
-         The name field defines what domain name applies to the given
-
-
-
-Lottor                                                          [Page 2]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-         RR.  In some cases the name field can be left blank and it will
-         default to the name field of the previous RR.
-
-      <ttl>
-
-         TTL stands for Time To Live.  It specifies how long a domain
-         resolver should cache the RR before it throws it out and asks a
-         domain server again.  See the section on TTL's.  If you leave
-         the TTL field blank it will default to the minimum time
-         specified in the SOA record (described later).
-
-      <class>
-
-         The class field specifies the protocol group.  If left blank it
-         will default to the last class specified.
-
-      <type>
-
-         The type field specifies what type of data is in the RR.  See
-         the section on types.
-
-      <data>
-
-         The data field is defined differently for each type and class
-         of data.  Popular RR data formats are described later.
-
-   The domain system does not guarantee to preserve the order of
-   resource records.  Listing RRs (such as multiple address records) in
-   a certain order does not guarantee they will be used in that order.
-
-   Case is preserved in names and data fields when loaded into the name
-   server.  All comparisons and lookups in the name server are case
-   insensitive.
-
-   Parenthesis ("(",")") are used to group data that crosses a line
-   boundary.
-
-   A semicolon (";") starts a comment; the remainder of the line is
-   ignored.
-
-   The asterisk ("*") is used for wildcarding.
-
-   The at-sign ("@") denotes the current default domain name.
-
-
-
-
-
-
-
-
-Lottor                                                          [Page 3]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-NAMES
-
-   A domain name is a sequence of labels separated by dots.
-
-   Domain names in the zone files can be one of two types, either
-   absolute or relative.  An absolute name is the fully qualified domain
-   name and is terminated with a period.  A relative name does not
-   terminate with a period, and the current default domain is appended
-   to it.  The default domain is usually the name of the domain that was
-   specified in the boot file that loads each zone.
-
-   The domain system allows a label to contain any 8-bit character.
-   Although the domain system has no restrictions, other protocols such
-   as SMTP do have name restrictions.  Because of other protocol
-   restrictions, only the following characters are recommended for use
-   in a host name (besides the dot separator):
-
-           "A-Z", "a-z", "0-9", dash and underscore
-
-TTL's  (Time To Live)
-
-   It is important that TTLs are set to appropriate values.  The TTL is
-   the time (in seconds) that a resolver will use the data it got from
-   your server before it asks your server again.  If you set the value
-   too low, your server will get loaded down with lots of repeat
-   requests.  If you set it too high, then information you change will
-   not get distributed in a reasonable amount of time.  If you leave the
-   TTL field blank, it will default to what is specified in the SOA
-   record for the zone.
-
-   Most host information does not change much over long time periods.  A
-   good way to set up your TTLs would be to set them at a high value,
-   and then lower the value if you know a change will be coming soon.
-   You might set most TTLs to anywhere between a day (86400) and a week
-   (604800).  Then, if you know some data will be changing in the near
-   future, set the TTL for that RR down to a lower value (an hour to a
-   day) until the change takes place, and then put it back up to its
-   previous value.
-
-   Also, all RRs with the same name, class, and type should have the
-   same TTL value.
-
-CLASSES
-
-   The domain system was designed to be protocol independent.  The class
-   field is used to identify the protocol group that each RR is in.
-
-   The class of interest to people using TCP/IP software is the class
-
-
-
-Lottor                                                          [Page 4]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-   "Internet".  Its standard designation is "IN".
-
-   A zone file should only contain RRs of the same class.
-
-TYPES
-
-   There are many defined RR types.  For a complete list, see the domain
-   specification RFCs.  Here is a list of current commonly used types.
-   The data for each type is described in the data section.
-
-                Designation                Description
-              ==========================================
-               SOA                 Start Of Authority
-               NS                  Name Server
-
-               A                   Internet Address
-               CNAME               Canonical Name (nickname pointer)
-               HINFO               Host Information
-               WKS                 Well Known Services
-
-               MX                  Mail Exchanger
-
-               PTR                 Pointer
-
-SOA  (Start Of Authority)
-
-           <name>  [<ttl>]  [<class>]  SOA  <origin>  <person>  (
-                           <serial>
-                           <refresh>
-                           <retry>
-                           <expire>
-                           <minimum> )
-
-   The Start Of Authority record designates the start of a zone.  The
-   zone ends at the next SOA record.
-
-   <name> is the name of the zone.
-
-   <origin> is the name of the host on which the master zone file
-   resides.
-
-   <person> is a mailbox for the person responsible for the zone.  It is
-   formatted like a mailing address but the at-sign that normally
-   separates the user from the host name is replaced with a dot.
-
-   <serial> is the version number of the zone file.  It should be
-   incremented anytime a change is made to data in the zone.
-
-
-
-
-Lottor                                                          [Page 5]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-   <refresh> is how long, in seconds, a secondary name server is to
-   check with the primary name server to see if an update is needed.  A
-   good value here would be one hour (3600).
-
-   <retry> is how long, in seconds, a secondary name server is to retry
-   after a failure to check for a refresh.  A good value here would be
-   10 minutes (600).
-
-   <expire> is the upper limit, in seconds, that a secondary name server
-   is to use the data before it expires for lack of getting a refresh.
-   You want this to be rather large, and a nice value is 3600000, about
-   42 days.
-
-   <minimum> is the minimum number of seconds to be used for TTL values
-   in RRs.  A minimum of at least a day is a good value here (86400).
-
-   There should only be one SOA record per zone.  A sample SOA record
-   would look something like:
-
-           @   IN   SOA   SRI-NIC.ARPA.   HOSTMASTER.SRI-NIC.ARPA. (
-                           45         ;serial
-                           3600       ;refresh
-                           600        ;retry
-                           3600000    ;expire
-                           86400 )    ;minimum
-
-
-NS  (Name Server)
-
-           <domain>   [<ttl>] [<class>]   NS   <server>
-
-   The NS record lists the name of a machine that provides domain
-   service for a particular domain.  The name associated with the RR is
-   the domain name and the data portion is the name of a host that
-   provides the service.  If machines SRI-NIC.ARPA and C.ISI.EDU provide
-   name lookup service for the domain COM then the following entries
-   would be used:
-
-           COM.    NS      SRI-NIC.ARPA.
-                   NS      C.ISI.EDU.
-
-   Note that the machines providing name service do not have to live in
-   the named domain.  There should be one NS record for each server for
-   a domain.  Also note that the name "COM" defaults for the second NS
-   record.
-
-   NS records for a domain exist in both the zone that delegates the
-   domain, and in the domain itself.
-
-
-
-Lottor                                                          [Page 6]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-GLUE RECORDS
-
-   If the name server host for a particular domain is itself inside the
-   domain, then a 'glue' record will be needed.  A glue record is an A
-   (address) RR that specifies the address of the server.  Glue records
-   are only needed in the server delegating the domain, not in the
-   domain itself.  If for example the name server for domain SRI.COM was
-   KL.SRI.COM, then the NS record would look like this, but you will
-   also need to have the following A record.
-
-           SRI.COM.	NS	KL.SRI.COM.
-           KL.SRI.COM.  A	10.1.0.2
-
-
-A  (Address)
-
-           <host>   [<ttl>] [<class>]   A   <address>
-
-   The data for an A record is an internet address in dotted decimal
-   form.  A sample A record might look like:
-
-           SRI-NIC.ARPA.           A       10.0.0.51
-
-   There should be one A record for each address of a host.
-
-CNAME ( Canonical Name)
-
-           <nickname>   [<ttl>] [<class>]   CNAME   <host>
-
-   The CNAME record is used for nicknames.  The name associated with the
-   RR is the nickname.  The data portion is the official name.  For
-   example, a machine named SRI-NIC.ARPA may want to have the nickname
-   NIC.ARPA.  In that case, the following RR would be used:
-
-           NIC.ARPA.       CNAME   SRI-NIC.ARPA.
-
-   There must not be any other RRs associated with a nickname of the
-   same class.
-
-   Nicknames are also useful when a host changes it's name.  In that
-   case, it is usually a good idea to have a CNAME pointer so that
-   people still using the old name will get to the right place.
-
-
-
-
-
-
-
-
-
-Lottor                                                          [Page 7]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-HINFO (Host Info)
-
-           <host>   [<ttl>] [<class>]   HINFO   <hardware>   <software>
-
-   The HINFO record gives information about a particular host.  The data
-   is two strings separated by whitespace.  The first string is a
-   hardware description and the second is software.  The hardware is
-   usually a manufacturer name followed by a dash and model designation.
-   The software string is usually the name of the operating system.
-
-   Official HINFO types can be found in the latest Assigned Numbers RFC,
-   the latest of which is RFC-1010.  The Hardware type is called the
-   Machine name and the Software type is called the System name.
-
-   Some sample HINFO records:
-
-           SRI-NIC.ARPA.           HINFO   DEC-2060 TOPS20
-           UCBARPA.Berkeley.EDU.   HINFO   VAX-11/780 UNIX
-
-
-WKS (Well Known Services)
-
-           <host> [<ttl>] [<class>] WKS <address> <protocol> <services>
-
-   The WKS record is used to list Well Known Services a host provides.
-   WKS's are defined to be services on port numbers below 256.  The WKS
-   record lists what services are available at a certain address using a
-   certain protocol.  The common protocols are TCP or UDP.  A sample WKS
-   record for a host offering the same services on all address would
-   look like:
-
-   Official protocol names can be found in the latest Assigned Numbers
-   RFC, the latest of which is RFC-1010.
-
-           SRI-NIC.ARPA.   WKS  10.0.0.51  TCP  TELNET FTP SMTP
-                           WKS  10.0.0.51  UDP  TIME
-                           WKS  26.0.0.73  TCP  TELNET FTP SMTP
-                           WKS  26.0.0.73  UDP  TIME
-
-MX (Mail Exchanger)  (See RFC-974 for more details.)
-
-           <name>   [<ttl>] [<class>]   MX   <preference>   <host>
-
-   MX records specify where mail for a domain name should be delivered.
-   There may be multiple MX records for a particular name.  The
-   preference value specifies the order a mailer should try multiple MX
-   records when delivering mail.  Zero is the highest preference.
-   Multiple records for the same name may have the same preference.
-
-
-
-Lottor                                                          [Page 8]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-   A host BAR.FOO.COM may want its mail to be delivered to the host
-   PO.FOO.COM and would then use the MX record:
-
-           BAR.FOO.COM.    MX      10      PO.FOO.COM.
-
-   A host BAZ.FOO.COM may want its mail to be delivered to one of three
-   different machines, in the following order:
-
-           BAZ.FOO.COM.    MX      10      PO1.FOO.COM.
-                           MX      20      PO2.FOO.COM.
-                           MX      30      PO3.FOO.COM.
-
-   An entire domain of hosts not connected to the Internet may want
-   their mail to go through a mail gateway that knows how to deliver
-   mail to them.  If they would like mail addressed to any host in the
-   domain FOO.COM to go through the mail gateway they might use:
-
-           FOO.COM.        MX       10     RELAY.CS.NET.
-           *.FOO.COM.      MX       20     RELAY.CS.NET.
-
-   Note that you can specify a wildcard in the MX record to match on
-   anything in FOO.COM, but that it won't match a plain FOO.COM.
-
-IN-ADDR.ARPA
-
-   The structure of names in the domain system is set up in a
-   hierarchical way such that the address of a name can be found by
-   tracing down the domain tree contacting a server for each label of
-   the name.  Because of this 'indexing' based on name, there is no easy
-   way to translate a host address back into its host name.
-
-   In order to do the reverse translation easily, a domain was created
-   that uses hosts' addresses as part of a name that then points to the
-   data for that host.  In this way, there is now an 'index' to hosts'
-   RRs based on their address.  This address mapping domain is called
-   IN-ADDR.ARPA.  Within that domain are subdomains for each network,
-   based on network number.  Also, for consistency and natural
-   groupings, the 4 octets of a host number are reversed.
-
-   For example, the ARPANET is net 10.  That means there is a domain
-   called 10.IN-ADDR.ARPA.  Within this domain there is a PTR RR at
-   51.0.0.10.IN-ADDR that points to the RRs for the host SRI-NIC.ARPA
-   (who's address is 10.0.0.51).  Since the NIC is also on the MILNET
-   (Net 26, address 26.0.0.73), there is also a PTR RR at 73.0.0.26.IN-
-   ADDR.ARPA that points to the same RR's for SRI-NIC.ARPA.  The format
-   of these special pointers is defined below along with the examples
-   for the NIC.
-
-
-
-
-Lottor                                                          [Page 9]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-PTR
-
-           <special-name>   [<ttl>] [<class>]   PTR   <name>
-
-   The PTR record is used to let special names point to some other
-   location in the domain tree.  They are mainly used in the IN-
-   ADDR.ARPA records for translation of addresses to names.  PTR's
-   should use official names and not aliases.
-
-   For example, host SRI-NIC.ARPA with addresses 10.0.0.51 and 26.0.0.73
-   would have the following records in the respective zone files for net
-   10 and net 26:
-
-           51.0.0.10.IN-ADDR.ARPA.  PTR   SRI-NIC.ARPA.
-           73.0.0.26.IN-ADDR.ARPA.  PTR   SRI-NIC.ARPA.
-
-GATEWAY PTR's
-
-   The IN-ADDR tree is also used to locate gateways on a particular
-   network.  Gateways have the same kind of PTR RRs as hosts (as above)
-   but in addition they have other PTRs used to locate them by network
-   number alone.  These records have only 1, 2, or 3 octets as part of
-   the name depending on whether they are class A, B, or C networks,
-   respectively.
-
-   Lets take the SRI-CSL gateway for example.  It connects 3 different
-   networks, one class A, one class B and one class C.  It will have the
-   standard RR's for a host in the CSL.SRI.COM zone:
-
-           GW.CSL.SRI.COM.    A    10.2.0.2
-                              A    128.18.1.1
-                              A    192.12.33.2
-
-   Also, in 3 different zones (one for each network), it will have one
-   of the following number to name translation pointers:
-
-           2.0.2.10.IN-ADDR.ARPA.      PTR   GW.CSL.SRI.COM.
-           1.1.18.128.IN-ADDR.ARPA.    PTR   GW.CSL.SRI.COM.
-           1.33.12.192.IN-ADDR.ARPA.   PTR   GW.CSL.SRI.COM.
-
-   In addition, in each of the same 3 zones will be one of the following
-   gateway location pointers:
-
-           10.IN-ADDR.ARPA.            PTR   GW.CSL.SRI.COM.
-           18.128.IN-ADDR.ARPA.        PTR   GW.CSL.SRI.COM.
-           33.12.192.IN-ADDR.ARPA.     PTR   GW.CSL.SRI.COM.
-
-
-
-
-
-Lottor                                                         [Page 10]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-INSTRUCTIONS
-
-   Adding a subdomain.
-
-      To add a new subdomain to your domain:
-
-         Setup the other domain server and/or the new zone file.
-
-         Add an NS record for each server of the new domain to the zone
-         file of the parent domain.
-
-         Add any necessary glue RRs.
-
-   Adding a host.
-
-      To add a new host to your zone files:
-
-         Edit the appropriate zone file for the domain the host is in.
-
-         Add an entry for each address of the host.
-
-         Optionally add CNAME, HINFO, WKS, and MX records.
-
-         Add the reverse IN-ADDR entry for each host address in the
-         appropriate zone files for each network the host in on.
-
-   Deleting a host.
-
-      To delete a host from the zone files:
-
-         Remove all the hosts' resource records from the zone file of
-         the domain the host is in.
-
-         Remove all the hosts' PTR records from the IN-ADDR zone files
-         for each network the host was on.
-
-   Adding gateways.
-
-         Follow instructions for adding a host.
-
-         Add the gateway location PTR records for each network the
-         gateway is on.
-
-   Deleting gateways.
-
-         Follow instructions for deleting a host.
-
-         Also delete the gateway location PTR records for each network
-
-
-
-Lottor                                                         [Page 11]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-         the gateway was on.
-
-COMPLAINTS
-
-   These are the suggested steps you should take if you are having
-   problems that you believe are caused by someone else's name server:
-
-
-   1.  Complain privately to the responsible person for the domain.  You
-   can find their mailing address in the SOA record for the domain.
-
-   2.  Complain publicly to the responsible person for the domain.
-
-   3.  Ask the NIC for the administrative person responsible for the
-   domain.  Complain.  You can also find domain contacts on the NIC in
-   the file NETINFO:DOMAIN-CONTACTS.TXT
-
-   4.  Complain to the parent domain authorities.
-
-   5.  Ask the parent authorities to excommunicate the domain.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lottor                                                         [Page 12]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-EXAMPLE DOMAIN SERVER DATABASE FILES
-
-   The following examples show how zone files are set up for a typical
-   organization.  SRI will be used as the example organization.  SRI has
-   decided to divided their domain SRI.COM into a few subdomains, one
-   for each group that wants one.  The subdomains are CSL and ISTC.
-
-   Note the following interesting items:
-
-      There are both hosts and domains under SRI.COM.
-
-      CSL.SRI.COM is both a domain name and a host name.
-
-      All the domains are serviced by the same pair of domain servers.
-
-      All hosts at SRI are on net 128.18 except hosts in the CSL domain
-      which are on net 192.12.33.  Note that a domain does not have to
-      correspond to a physical network.
-
-      The examples do not necessarily correspond to actual data in use
-      by the SRI domain.
-
-                       SRI Domain Organization
-
-                               +-------+
-                               |  COM  |
-                               +-------+
-                                   |
-                               +-------+
-                               |  SRI  |
-                               +-------+
-                                   |
-                        +----------++-----------+
-                        |           |           |
-                    +-------+    +------+   +-------+
-                    |  CSL  |    | ISTC |   | Hosts |
-                    +-------+    +------+   +-------+
-                        |           |
-                    +-------+    +-------+
-                    | Hosts |    | Hosts |
-                    +-------+    +-------+
-
-
-
-
-
-
-
-
-
-
-Lottor                                                         [Page 13]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-   [File "CONFIG.CMD".  Since bootstrap files are not standardized, this
-   file is presented using a pseudo configuration file syntax.]
-
-   load root server list             from file ROOT.SERVERS
-   load zone SRI.COM.                from file SRI.ZONE
-   load zone CSL.SRI.COM.            from file CSL.ZONE
-   load zone ISTC.SRI.COM.           from file ISTC.ZONE
-   load zone 18.128.IN-ADDR.ARPA.    from file SRINET.ZONE
-   load zone 33.12.192.IN-ADDR.ARPA. from file SRI-CSL-NET.ZONE
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lottor                                                         [Page 14]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-   [File "ROOT.SERVERS".  Again, the format of this file is not
-   standardized.]
-
-   ;list of possible root servers
-   SRI-NIC.ARPA       10.0.0.51    26.0.0.73
-   C.ISI.EDU          10.0.0.52
-   BRL-AOS.ARPA       192.5.25.82  192.5.22.82   128.20.1.2
-   A.ISI.EDU          26.3.0.103
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lottor                                                         [Page 15]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-   [File "SRI.ZONE"]
-
-   SRI.COM.        IN      SOA     KL.SRI.COM. DLE.STRIPE.SRI.COM. (
-                                   870407  ;serial
-                                   1800    ;refresh every 30 minutes
-                                   600     ;retry every 10 minutes
-                                   604800  ;expire after a week
-                                   86400   ;default of an hour
-                                   )
-
-   SRI.COM.        NS      KL.SRI.COM.
-                   NS      STRIPE.SRI.COM.
-                   MX      10      KL.SRI.COM.
-
-   ;SRI.COM hosts
-
-   KL              A       10.1.0.2
-                   A       128.18.10.6
-                   MX      10      KL.SRI.COM.
-
-   STRIPE          A       10.4.0.2
-   STRIPE          A       128.18.10.4
-                   MX      10      STRIPE.SRI.COM.
-
-   NIC             CNAME   SRI-NIC.ARPA.
-
-   Blackjack       A       128.18.2.1
-                   HINFO   VAX-11/780      UNIX
-                   WKS     128.18.2.1      TCP TELNET FTP
-
-   CSL             A       192.12.33.2
-                   HINFO   FOONLY-F4       TOPS20
-                   WKS     192.12.33.2     TCP TELNET FTP SMTP FINGER
-                   MX      10      CSL.SRI.COM.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lottor                                                         [Page 16]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-   [File "CSL.ZONE"]
-
-   CSL.SRI.COM.    IN      SOA     KL.SRI.COM. DLE.STRIPE.SRI.COM. (
-                                   870330  ;serial
-                                   1800    ;refresh every 30 minutes
-                                   600     ;retry every 10 minutes
-                                   604800  ;expire after a week
-                                   86400   ;default of a day
-                                   )
-
-   CSL.SRI.COM.    NS              KL.SRI.COM.
-                   NS              STRIPE.SRI.COM.
-                   A               192.12.33.2
-
-   ;CSL.SRI.COM hosts
-
-   A               CNAME   CSL.SRI.COM.
-   B               A       192.12.33.3
-                   HINFO   FOONLY-F4       TOPS20
-                   WKS     192.12.33.3     TCP TELNET FTP SMTP
-   GW              A       10.2.0.2
-                   A       192.12.33.1
-                   A       128.18.1.1
-                   HINFO   PDP-11/23       MOS
-   SMELLY          A       192.12.33.4
-                   HINFO   IMAGEN          IMAGEN
-   SQUIRREL        A       192.12.33.5
-                   HINFO   XEROX-1100      INTERLISP
-   VENUS           A       192.12.33.7
-                   HINFO   SYMBOLICS-3600  LISPM
-   HELIUM          A       192.12.33.30
-                   HINFO   SUN-3/160       UNIX
-   ARGON           A       192.12.33.31
-                   HINFO   SUN-3/75        UNIX
-   RADON           A       192.12.33.32
-                   HINFO   SUN-3/75        UNIX
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lottor                                                         [Page 17]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-   [File "ISTC.ZONE"]
-
-   ISTC.SRI.COM.   IN  SOA     KL.SRI.COM. roemers.JOYCE.ISTC.SRI.COM. (
-                               870406      ;serial
-                               1800        ;refresh every 30 minutes
-                               600         ;retry every 10 minutes
-                               604800      ;expire after a week
-                               86400       ;default of a day
-                               )
-
-   ISTC.SRI.COM.   NS              KL.SRI.COM.
-                   NS              STRIPE.SRI.COM.
-                   MX              10      SPAM.ISTC.SRI.COM.
-
-   ; ISTC hosts
-
-   joyce           A       128.18.4.2
-                   HINFO   VAX-11/750 UNIX
-   bozo            A       128.18.0.6
-                   HINFO   SUN UNIX
-   sundae          A       128.18.0.11
-                   HINFO   SUN UNIX
-   tsca            A       128.18.0.201
-                   A       10.3.0.2
-                   HINFO   VAX-11/750 UNIX
-                   MX      10  TSCA.ISTC.SRI.COM.
-   tsc             CNAME   tsca
-   prmh            A       128.18.0.203
-                   A       10.2.0.51
-                   HINFO   PDP-11/44 UNIX
-   spam            A       128.18.4.3
-                   A       10.2.0.107
-                   HINFO   VAX-11/780 UNIX
-                   MX      10  SPAM.ISTC.SRI.COM.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lottor                                                         [Page 18]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-   [File "SRINET.ZONE"]
-
-   18.128.IN-ADDR.ARPA.    IN  SOA  KL.SRI.COM  DLE.STRIPE.SRI.COM. (
-                               870406  ;serial
-                               1800    ;refresh every 30 minutes
-                               600     ;retry every 10 minutes
-                               604800  ;expire after a week
-                               86400   ;default of a day
-                               )
-
-   18.128.IN-ADDR.ARPA.    NS      KL.SRI.COM.
-                           NS      STRIPE.SRI.COM.
-                           PTR     GW.CSL.SRI.COM.
-
-   ; SRINET [128.18.0.0] Address Translations
-
-   ; SRI.COM Hosts
-   1.2.18.128.IN-ADDR.ARPA.        PTR     Blackjack.SRI.COM.
-
-   ; ISTC.SRI.COM Hosts
-   2.4.18.128.IN-ADDR.ARPA.        PTR     joyce.ISTC.SRI.COM.
-   6.0.18.128.IN-ADDR.ARPA.        PTR     bozo.ISTC.SRI.COM.
-   11.0.18.128.IN-ADDR.ARPA.       PTR     sundae.ISTC.SRI.COM.
-   201.0.18.128.IN-ADDR.ARPA.      PTR     tsca.ISTC.SRI.COM.
-   203.0.18.128.IN-ADDR.ARPA.      PTR     prmh.ISTC.SRI.COM.
-   3.4.18.128.IN-ADDR.ARPA.        PTR     spam.ISTC.SRI.COM.
-
-   ; CSL.SRI.COM Hosts
-   1.1.18.128.IN-ADDR.ARPA.        PTR     GW.CSL.SRI.COM.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lottor                                                         [Page 19]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-   [File "SRI-CSL-NET.ZONE"]
-
-   33.12.192.IN-ADDR.ARPA. IN  SOA KL.SRI.COM  DLE.STRIPE.SRI.COM. (
-                               870404  ;serial
-                               1800    ;refresh every 30 minutes
-                               600     ;retry every 10 minutes
-                               604800  ;expire after a week
-                               86400   ;default of a day
-                               )
-
-   33.12.192.IN-ADDR.ARPA. NS      KL.SRI.COM.
-                           NS      STRIPE.SRI.COM.
-                           PTR     GW.CSL.SRI.COM.
-
-   ; SRI-CSL-NET [192.12.33.0] Address Translations
-
-   ; SRI.COM Hosts
-   2.33.12.192.IN-ADDR.ARPA.       PTR     CSL.SRI.COM.
-
-   ; CSL.SRI.COM Hosts
-   1.33.12.192.IN-ADDR.ARPA.       PTR     GW.CSL.SRI.COM.
-   3.33.12.192.IN-ADDR.ARPA.       PTR     B.CSL.SRI.COM.
-   4.33.12.192.IN-ADDR.ARPA.       PTR     SMELLY.CSL.SRI.COM.
-   5.33.12.192.IN-ADDR.ARPA.       PTR     SQUIRREL.CSL.SRI.COM.
-   7.33.12.192.IN-ADDR.ARPA.       PTR     VENUS.CSL.SRI.COM.
-   30.33.12.192.IN-ADDR.ARPA.      PTR     HELIUM.CSL.SRI.COM.
-   31.33.12.192.IN-ADDR.ARPA.      PTR     ARGON.CSL.SRI.COM.
-   32.33.12.192.IN-ADDR.ARPA.      PTR     RADON.CSL.SRI.COM.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lottor                                                         [Page 20]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-APPENDIX
-
-   BIND (Berkeley Internet Name Domain server) distributed with 4.3 BSD
-   UNIX
-
-   This section describes two BIND implementation specific files; the
-   boot file and the cache file.  BIND has other options, files, and
-   specifications that are not described here.  See the Name Server
-   Operations Guide for BIND for details.
-
-   The boot file for BIND is usually called "named.boot".  This
-   corresponds to file "CONFIG.CMD" in the example section.
-
-           --------------------------------------------------------
-           cache         .                         named.ca
-           primary       SRI.COM                   SRI.ZONE
-           primary       CSL.SRI.COM               CSL.ZONE
-           primary       ISTC.SRI.COM              ISTC.ZONE
-           primary       18.128.IN-ADDR.ARPA       SRINET.ZONE
-           primary       33.12.192.IN-ADDR.ARPA    SRI-CSL-NET.ZONE
-           --------------------------------------------------------
-
-   The cache file for BIND is usually called "named.ca".  This
-   corresponds to file "ROOT.SERVERS" in the example section.
-
-           -------------------------------------------------
-           ;list of possible root servers
-           .       1          IN   NS   SRI-NIC.ARPA.
-                                   NS   C.ISI.EDU.
-                                   NS   BRL-AOS.ARPA.
-                                   NS   C.ISI.EDU.
-           ;and their addresses
-           SRI-NIC.ARPA.           A    10.0.0.51
-                                   A    26.0.0.73
-           C.ISI.EDU.              A    10.0.0.52
-           BRL-AOS.ARPA.           A    192.5.25.82
-                                   A    192.5.22.82
-                                   A    128.20.1.2
-           A.ISI.EDU.              A    26.3.0.103
-           -------------------------------------------------
-
-
-
-
-
-
-
-
-
-
-
-Lottor                                                         [Page 21]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-REFERENCES
-
-   [1]  Dunlap, K., "Name Server Operations Guide for BIND", CSRG,
-        Department of Electrical Engineering and Computer Sciences,
-        University of California, Berkeley, California.
-
-   [2]  Partridge, C., "Mail Routing and the Domain System", RFC-974,
-        CSNET CIC BBN Laboratories, January 1986.
-
-   [3]  Mockapetris, P., "Domains Names - Concepts and Facilities",
-        RFC-1034, USC/Information Sciences Institute, November 1987.
-
-   [4]  Mockapetris, P., "Domain Names - Implementations Specification",
-        RFC-1035, USC/Information Sciences Institute, November 1987.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lottor                                                         [Page 22]
-
diff --git a/contrib/bind9/doc/rfc/rfc1034.txt b/contrib/bind9/doc/rfc/rfc1034.txt
deleted file mode 100644
index 55cdb21..0000000
--- a/contrib/bind9/doc/rfc/rfc1034.txt
+++ /dev/null
@@ -1,3077 +0,0 @@
-Network Working Group                                     P. Mockapetris
-Request for Comments: 1034                                           ISI
-Obsoletes: RFCs 882, 883, 973                              November 1987
-
-
-                 DOMAIN NAMES - CONCEPTS AND FACILITIES
-
-
-
-1. STATUS OF THIS MEMO
-
-This RFC is an introduction to the Domain Name System (DNS), and omits
-many details which can be found in a companion RFC, "Domain Names -
-Implementation and Specification" [RFC-1035].  That RFC assumes that the
-reader is familiar with the concepts discussed in this memo.
-
-A subset of DNS functions and data types constitute an official
-protocol.  The official protocol includes standard queries and their
-responses and most of the Internet class data formats (e.g., host
-addresses).
-
-However, the domain system is intentionally extensible.  Researchers are
-continuously proposing, implementing and experimenting with new data
-types, query types, classes, functions, etc.  Thus while the components
-of the official protocol are expected to stay essentially unchanged and
-operate as a production service, experimental behavior should always be
-expected in extensions beyond the official protocol.  Experimental or
-obsolete features are clearly marked in these RFCs, and such information
-should be used with caution.
-
-The reader is especially cautioned not to depend on the values which
-appear in examples to be current or complete, since their purpose is
-primarily pedagogical.  Distribution of this memo is unlimited.
-
-2. INTRODUCTION
-
-This RFC introduces domain style names, their use for Internet mail and
-host address support, and the protocols and servers used to implement
-domain name facilities.
-
-2.1. The history of domain names
-
-The impetus for the development of the domain system was growth in the
-Internet:
-
-   - Host name to address mappings were maintained by the Network
-     Information Center (NIC) in a single file (HOSTS.TXT) which
-     was FTPed by all hosts [RFC-952, RFC-953].  The total network
-
-
-
-Mockapetris                                                     [Page 1]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-     bandwidth consumed in distributing a new version by this
-     scheme is proportional to the square of the number of hosts in
-     the network, and even when multiple levels of FTP are used,
-     the outgoing FTP load on the NIC host is considerable.
-     Explosive growth in the number of hosts didn't bode well for
-     the future.
-
-   - The network population was also changing in character.  The
-     timeshared hosts that made up the original ARPANET were being
-     replaced with local networks of workstations.  Local
-     organizations were administering their own names and
-     addresses, but had to wait for the NIC to change HOSTS.TXT to
-     make changes visible to the Internet at large.  Organizations
-     also wanted some local structure on the name space.
-
-   - The applications on the Internet were getting more
-     sophisticated and creating a need for general purpose name
-     service.
-
-
-The result was several ideas about name spaces and their management
-[IEN-116, RFC-799, RFC-819, RFC-830].  The proposals varied, but a
-common thread was the idea of a hierarchical name space, with the
-hierarchy roughly corresponding to organizational structure, and names
-using "."  as the character to mark the boundary between hierarchy
-levels.  A design using a distributed database and generalized resources
-was described in [RFC-882, RFC-883].  Based on experience with several
-implementations, the system evolved into the scheme described in this
-memo.
-
-The terms "domain" or "domain name" are used in many contexts beyond the
-DNS described here.  Very often, the term domain name is used to refer
-to a name with structure indicated by dots, but no relation to the DNS.
-This is particularly true in mail addressing [Quarterman 86].
-
-2.2. DNS design goals
-
-The design goals of the DNS influence its structure.  They are:
-
-   - The primary goal is a consistent name space which will be used
-     for referring to resources.  In order to avoid the problems
-     caused by ad hoc encodings, names should not be required to
-     contain network identifiers, addresses, routes, or similar
-     information as part of the name.
-
-   - The sheer size of the database and frequency of updates
-     suggest that it must be maintained in a distributed manner,
-     with local caching to improve performance.  Approaches that
-
-
-
-Mockapetris                                                     [Page 2]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-     attempt to collect a consistent copy of the entire database
-     will become more and more expensive and difficult, and hence
-     should be avoided.  The same principle holds for the structure
-     of the name space, and in particular mechanisms for creating
-     and deleting names; these should also be distributed.
-
-   - Where there tradeoffs between the cost of acquiring data, the
-     speed of updates, and the accuracy of caches, the source of
-     the data should control the tradeoff.
-
-   - The costs of implementing such a facility dictate that it be
-     generally useful, and not restricted to a single application.
-     We should be able to use names to retrieve host addresses,
-     mailbox data, and other as yet undetermined information.  All
-     data associated with a name is tagged with a type, and queries
-     can be limited to a single type.
-
-   - Because we want the name space to be useful in dissimilar
-     networks and applications, we provide the ability to use the
-     same name space with different protocol families or
-     management.  For example, host address formats differ between
-     protocols, though all protocols have the notion of address.
-     The DNS tags all data with a class as well as the type, so
-     that we can allow parallel use of different formats for data
-     of type address.
-
-   - We want name server transactions to be independent of the
-     communications system that carries them.  Some systems may
-     wish to use datagrams for queries and responses, and only
-     establish virtual circuits for transactions that need the
-     reliability (e.g., database updates, long transactions); other
-     systems will use virtual circuits exclusively.
-
-   - The system should be useful across a wide spectrum of host
-     capabilities.  Both personal computers and large timeshared
-     hosts should be able to use the system, though perhaps in
-     different ways.
-
-2.3. Assumptions about usage
-
-The organization of the domain system derives from some assumptions
-about the needs and usage patterns of its user community and is designed
-to avoid many of the the complicated problems found in general purpose
-database systems.
-
-The assumptions are:
-
-   - The size of the total database will initially be proportional
-
-
-
-Mockapetris                                                     [Page 3]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-     to the number of hosts using the system, but will eventually
-     grow to be proportional to the number of users on those hosts
-     as mailboxes and other information are added to the domain
-     system.
-
-   - Most of the data in the system will change very slowly (e.g.,
-     mailbox bindings, host addresses), but that the system should
-     be able to deal with subsets that change more rapidly (on the
-     order of seconds or minutes).
-
-   - The administrative boundaries used to distribute
-     responsibility for the database will usually correspond to
-     organizations that have one or more hosts.  Each organization
-     that has responsibility for a particular set of domains will
-     provide redundant name servers, either on the organization's
-     own hosts or other hosts that the organization arranges to
-     use.
-
-   - Clients of the domain system should be able to identify
-     trusted name servers they prefer to use before accepting
-     referrals to name servers outside of this "trusted" set.
-
-   - Access to information is more critical than instantaneous
-     updates or guarantees of consistency.  Hence the update
-     process allows updates to percolate out through the users of
-     the domain system rather than guaranteeing that all copies are
-     simultaneously updated.  When updates are unavailable due to
-     network or host failure, the usual course is to believe old
-     information while continuing efforts to update it.  The
-     general model is that copies are distributed with timeouts for
-     refreshing.  The distributor sets the timeout value and the
-     recipient of the distribution is responsible for performing
-     the refresh.  In special situations, very short intervals can
-     be specified, or the owner can prohibit copies.
-
-   - In any system that has a distributed database, a particular
-     name server may be presented with a query that can only be
-     answered by some other server.  The two general approaches to
-     dealing with this problem are "recursive", in which the first
-     server pursues the query for the client at another server, and
-     "iterative", in which the server refers the client to another
-     server and lets the client pursue the query.  Both approaches
-     have advantages and disadvantages, but the iterative approach
-     is preferred for the datagram style of access.  The domain
-     system requires implementation of the iterative approach, but
-     allows the recursive approach as an option.
-
-
-
-
-
-Mockapetris                                                     [Page 4]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-The domain system assumes that all data originates in master files
-scattered through the hosts that use the domain system.  These master
-files are updated by local system administrators.  Master files are text
-files that are read by a local name server, and hence become available
-through the name servers to users of the domain system.  The user
-programs access name servers through standard programs called resolvers.
-
-The standard format of master files allows them to be exchanged between
-hosts (via FTP, mail, or some other mechanism); this facility is useful
-when an organization wants a domain, but doesn't want to support a name
-server.  The organization can maintain the master files locally using a
-text editor, transfer them to a foreign host which runs a name server,
-and then arrange with the system administrator of the name server to get
-the files loaded.
-
-Each host's name servers and resolvers are configured by a local system
-administrator [RFC-1033].  For a name server, this configuration data
-includes the identity of local master files and instructions on which
-non-local master files are to be loaded from foreign servers.  The name
-server uses the master files or copies to load its zones.  For
-resolvers, the configuration data identifies the name servers which
-should be the primary sources of information.
-
-The domain system defines procedures for accessing the data and for
-referrals to other name servers.  The domain system also defines
-procedures for caching retrieved data and for periodic refreshing of
-data defined by the system administrator.
-
-The system administrators provide:
-
-   - The definition of zone boundaries.
-
-   - Master files of data.
-
-   - Updates to master files.
-
-   - Statements of the refresh policies desired.
-
-The domain system provides:
-
-   - Standard formats for resource data.
-
-   - Standard methods for querying the database.
-
-   - Standard methods for name servers to refresh local data from
-     foreign name servers.
-
-
-
-
-
-Mockapetris                                                     [Page 5]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-2.4. Elements of the DNS
-
-The DNS has three major components:
-
-   - The DOMAIN NAME SPACE and RESOURCE RECORDS, which are
-     specifications for a tree structured name space and data
-     associated with the names.  Conceptually, each node and leaf
-     of the domain name space tree names a set of information, and
-     query operations are attempts to extract specific types of
-     information from a particular set.  A query names the domain
-     name of interest and describes the type of resource
-     information that is desired.  For example, the Internet
-     uses some of its domain names to identify hosts; queries for
-     address resources return Internet host addresses.
-
-   - NAME SERVERS are server programs which hold information about
-     the domain tree's structure and set information.  A name
-     server may cache structure or set information about any part
-     of the domain tree, but in general a particular name server
-     has complete information about a subset of the domain space,
-     and pointers to other name servers that can be used to lead to
-     information from any part of the domain tree.  Name servers
-     know the parts of the domain tree for which they have complete
-     information; a name server is said to be an AUTHORITY for
-     these parts of the name space.  Authoritative information is
-     organized into units called ZONEs, and these zones can be
-     automatically distributed to the name servers which provide
-     redundant service for the data in a zone.
-
-   - RESOLVERS are programs that extract information from name
-     servers in response to client requests.  Resolvers must be
-     able to access at least one name server and use that name
-     server's information to answer a query directly, or pursue the
-     query using referrals to other name servers.  A resolver will
-     typically be a system routine that is directly accessible to
-     user programs; hence no protocol is necessary between the
-     resolver and the user program.
-
-These three components roughly correspond to the three layers or views
-of the domain system:
-
-   - From the user's point of view, the domain system is accessed
-     through a simple procedure or OS call to a local resolver.
-     The domain space consists of a single tree and the user can
-     request information from any section of the tree.
-
-   - From the resolver's point of view, the domain system is
-     composed of an unknown number of name servers.  Each name
-
-
-
-Mockapetris                                                     [Page 6]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-     server has one or more pieces of the whole domain tree's data,
-     but the resolver views each of these databases as essentially
-     static.
-
-   - From a name server's point of view, the domain system consists
-     of separate sets of local information called zones.  The name
-     server has local copies of some of the zones.  The name server
-     must periodically refresh its zones from master copies in
-     local files or foreign name servers.  The name server must
-     concurrently process queries that arrive from resolvers.
-
-In the interests of performance, implementations may couple these
-functions.  For example, a resolver on the same machine as a name server
-might share a database consisting of the the zones managed by the name
-server and the cache managed by the resolver.
-
-3. DOMAIN NAME SPACE and RESOURCE RECORDS
-
-3.1. Name space specifications and terminology
-
-The domain name space is a tree structure.  Each node and leaf on the
-tree corresponds to a resource set (which may be empty).  The domain
-system makes no distinctions between the uses of the interior nodes and
-leaves, and this memo uses the term "node" to refer to both.
-
-Each node has a label, which is zero to 63 octets in length.  Brother
-nodes may not have the same label, although the same label can be used
-for nodes which are not brothers.  One label is reserved, and that is
-the null (i.e., zero length) label used for the root.
-
-The domain name of a node is the list of the labels on the path from the
-node to the root of the tree.  By convention, the labels that compose a
-domain name are printed or read left to right, from the most specific
-(lowest, farthest from the root) to the least specific (highest, closest
-to the root).
-
-Internally, programs that manipulate domain names should represent them
-as sequences of labels, where each label is a length octet followed by
-an octet string.  Because all domain names end at the root, which has a
-null string for a label, these internal representations can use a length
-byte of zero to terminate a domain name.
-
-By convention, domain names can be stored with arbitrary case, but
-domain name comparisons for all present domain functions are done in a
-case-insensitive manner, assuming an ASCII character set, and a high
-order zero bit.  This means that you are free to create a node with
-label "A" or a node with label "a", but not both as brothers; you could
-refer to either using "a" or "A".  When you receive a domain name or
-
-
-
-Mockapetris                                                     [Page 7]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-label, you should preserve its case.  The rationale for this choice is
-that we may someday need to add full binary domain names for new
-services; existing services would not be changed.
-
-When a user needs to type a domain name, the length of each label is
-omitted and the labels are separated by dots (".").  Since a complete
-domain name ends with the root label, this leads to a printed form which
-ends in a dot.  We use this property to distinguish between:
-
-   - a character string which represents a complete domain name
-     (often called "absolute").  For example, "poneria.ISI.EDU."
-
-   - a character string that represents the starting labels of a
-     domain name which is incomplete, and should be completed by
-     local software using knowledge of the local domain (often
-     called "relative").  For example, "poneria" used in the
-     ISI.EDU domain.
-
-Relative names are either taken relative to a well known origin, or to a
-list of domains used as a search list.  Relative names appear mostly at
-the user interface, where their interpretation varies from
-implementation to implementation, and in master files, where they are
-relative to a single origin domain name.  The most common interpretation
-uses the root "." as either the single origin or as one of the members
-of the search list, so a multi-label relative name is often one where
-the trailing dot has been omitted to save typing.
-
-To simplify implementations, the total number of octets that represent a
-domain name (i.e., the sum of all label octets and label lengths) is
-limited to 255.
-
-A domain is identified by a domain name, and consists of that part of
-the domain name space that is at or below the domain name which
-specifies the domain.  A domain is a subdomain of another domain if it
-is contained within that domain.  This relationship can be tested by
-seeing if the subdomain's name ends with the containing domain's name.
-For example, A.B.C.D is a subdomain of B.C.D, C.D, D, and " ".
-
-3.2. Administrative guidelines on use
-
-As a matter of policy, the DNS technical specifications do not mandate a
-particular tree structure or rules for selecting labels; its goal is to
-be as general as possible, so that it can be used to build arbitrary
-applications.  In particular, the system was designed so that the name
-space did not have to be organized along the lines of network
-boundaries, name servers, etc.  The rationale for this is not that the
-name space should have no implied semantics, but rather that the choice
-of implied semantics should be left open to be used for the problem at
-
-
-
-Mockapetris                                                     [Page 8]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-hand, and that different parts of the tree can have different implied
-semantics.  For example, the IN-ADDR.ARPA domain is organized and
-distributed by network and host address because its role is to translate
-from network or host numbers to names; NetBIOS domains [RFC-1001, RFC-
-1002] are flat because that is appropriate for that application.
-
-However, there are some guidelines that apply to the "normal" parts of
-the name space used for hosts, mailboxes, etc., that will make the name
-space more uniform, provide for growth, and minimize problems as
-software is converted from the older host table.  The political
-decisions about the top levels of the tree originated in RFC-920.
-Current policy for the top levels is discussed in [RFC-1032].  MILNET
-conversion issues are covered in [RFC-1031].
-
-Lower domains which will eventually be broken into multiple zones should
-provide branching at the top of the domain so that the eventual
-decomposition can be done without renaming.  Node labels which use
-special characters, leading digits, etc., are likely to break older
-software which depends on more restrictive choices.
-
-3.3. Technical guidelines on use
-
-Before the DNS can be used to hold naming information for some kind of
-object, two needs must be met:
-
-   - A convention for mapping between object names and domain
-     names.  This describes how information about an object is
-     accessed.
-
-   - RR types and data formats for describing the object.
-
-These rules can be quite simple or fairly complex.  Very often, the
-designer must take into account existing formats and plan for upward
-compatibility for existing usage.  Multiple mappings or levels of
-mapping may be required.
-
-For hosts, the mapping depends on the existing syntax for host names
-which is a subset of the usual text representation for domain names,
-together with RR formats for describing host addresses, etc.  Because we
-need a reliable inverse mapping from address to host name, a special
-mapping for addresses into the IN-ADDR.ARPA domain is also defined.
-
-For mailboxes, the mapping is slightly more complex.  The usual mail
-address <local-part>@<mail-domain> is mapped into a domain name by
-converting <local-part> into a single label (regardles of dots it
-contains), converting <mail-domain> into a domain name using the usual
-text format for domain names (dots denote label breaks), and
-concatenating the two to form a single domain name.  Thus the mailbox
-
-
-
-Mockapetris                                                     [Page 9]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-HOSTMASTER@SRI-NIC.ARPA is represented as a domain name by
-HOSTMASTER.SRI-NIC.ARPA.  An appreciation for the reasons behind this
-design also must take into account the scheme for mail exchanges [RFC-
-974].
-
-The typical user is not concerned with defining these rules, but should
-understand that they usually are the result of numerous compromises
-between desires for upward compatibility with old usage, interactions
-between different object definitions, and the inevitable urge to add new
-features when defining the rules.  The way the DNS is used to support
-some object is often more crucial than the restrictions inherent in the
-DNS.
-
-3.4. Example name space
-
-The following figure shows a part of the current domain name space, and
-is used in many examples in this RFC.  Note that the tree is a very
-small subset of the actual name space.
-
-                                   |
-                                   |
-             +---------------------+------------------+
-             |                     |                  |
-            MIL                   EDU                ARPA
-             |                     |                  |
-             |                     |                  |
-       +-----+-----+               |     +------+-----+-----+
-       |     |     |               |     |      |           |
-      BRL  NOSC  DARPA             |  IN-ADDR  SRI-NIC     ACC
-                                   |
-       +--------+------------------+---------------+--------+
-       |        |                  |               |        |
-      UCI      MIT                 |              UDEL     YALE
-                |                 ISI
-                |                  |
-            +---+---+              |
-            |       |              |
-           LCS  ACHILLES  +--+-----+-----+--------+
-            |             |  |     |     |        |
-            XX            A  C   VAXA  VENERA Mockapetris
-
-In this example, the root domain has three immediate subdomains: MIL,
-EDU, and ARPA.  The LCS.MIT.EDU domain has one immediate subdomain named
-XX.LCS.MIT.EDU.  All of the leaves are also domains.
-
-3.5. Preferred name syntax
-
-The DNS specifications attempt to be as general as possible in the rules
-
-
-
-Mockapetris                                                    [Page 10]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-for constructing domain names.  The idea is that the name of any
-existing object can be expressed as a domain name with minimal changes.
-However, when assigning a domain name for an object, the prudent user
-will select a name which satisfies both the rules of the domain system
-and any existing rules for the object, whether these rules are published
-or implied by existing programs.
-
-For example, when naming a mail domain, the user should satisfy both the
-rules of this memo and those in RFC-822.  When creating a new host name,
-the old rules for HOSTS.TXT should be followed.  This avoids problems
-when old software is converted to use domain names.
-
-The following syntax will result in fewer problems with many
-applications that use domain names (e.g., mail, TELNET).
-
-<domain> ::= <subdomain> | " "
-
-<subdomain> ::= <label> | <subdomain> "." <label>
-
-<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
-
-<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
-
-<let-dig-hyp> ::= <let-dig> | "-"
-
-<let-dig> ::= <letter> | <digit>
-
-<letter> ::= any one of the 52 alphabetic characters A through Z in
-upper case and a through z in lower case
-
-<digit> ::= any one of the ten digits 0 through 9
-
-Note that while upper and lower case letters are allowed in domain
-names, no significance is attached to the case.  That is, two names with
-the same spelling but different case are to be treated as if identical.
-
-The labels must follow the rules for ARPANET host names.  They must
-start with a letter, end with a letter or digit, and have as interior
-characters only letters, digits, and hyphen.  There are also some
-restrictions on the length.  Labels must be 63 characters or less.
-
-For example, the following strings identify hosts in the Internet:
-
-A.ISI.EDU  XX.LCS.MIT.EDU  SRI-NIC.ARPA
-
-3.6. Resource Records
-
-A domain name identifies a node.  Each node has a set of resource
-
-
-
-Mockapetris                                                    [Page 11]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-information, which may be empty.  The set of resource information
-associated with a particular name is composed of separate resource
-records (RRs).  The order of RRs in a set is not significant, and need
-not be preserved by name servers, resolvers, or other parts of the DNS.
-
-When we talk about a specific RR, we assume it has the following:
-
-owner           which is the domain name where the RR is found.
-
-type            which is an encoded 16 bit value that specifies the type
-                of the resource in this resource record.  Types refer to
-                abstract resources.
-
-                This memo uses the following types:
-
-                A               a host address
-
-                CNAME           identifies the canonical name of an
-                                alias
-
-                HINFO           identifies the CPU and OS used by a host
-
-                MX              identifies a mail exchange for the
-                                domain.  See [RFC-974 for details.
-
-                NS
-                the authoritative name server for the domain
-
-                PTR
-                a pointer to another part of the domain name space
-
-                SOA
-                identifies the start of a zone of authority]
-
-class           which is an encoded 16 bit value which identifies a
-                protocol family or instance of a protocol.
-
-                This memo uses the following classes:
-
-                IN              the Internet system
-
-                CH              the Chaos system
-
-TTL             which is the time to live of the RR.  This field is a 32
-                bit integer in units of seconds, an is primarily used by
-                resolvers when they cache RRs.  The TTL describes how
-                long a RR can be cached before it should be discarded.
-
-
-
-
-Mockapetris                                                    [Page 12]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-RDATA           which is the type and sometimes class dependent data
-                which describes the resource:
-
-                A               For the IN class, a 32 bit IP address
-
-                                For the CH class, a domain name followed
-                                by a 16 bit octal Chaos address.
-
-                CNAME           a domain name.
-
-                MX              a 16 bit preference value (lower is
-                                better) followed by a host name willing
-                                to act as a mail exchange for the owner
-                                domain.
-
-                NS              a host name.
-
-                PTR             a domain name.
-
-                SOA             several fields.
-
-The owner name is often implicit, rather than forming an integral part
-of the RR.  For example, many name servers internally form tree or hash
-structures for the name space, and chain RRs off nodes.  The remaining
-RR parts are the fixed header (type, class, TTL) which is consistent for
-all RRs, and a variable part (RDATA) that fits the needs of the resource
-being described.
-
-The meaning of the TTL field is a time limit on how long an RR can be
-kept in a cache.  This limit does not apply to authoritative data in
-zones; it is also timed out, but by the refreshing policies for the
-zone.  The TTL is assigned by the administrator for the zone where the
-data originates.  While short TTLs can be used to minimize caching, and
-a zero TTL prohibits caching, the realities of Internet performance
-suggest that these times should be on the order of days for the typical
-host.  If a change can be anticipated, the TTL can be reduced prior to
-the change to minimize inconsistency during the change, and then
-increased back to its former value following the change.
-
-The data in the RDATA section of RRs is carried as a combination of
-binary strings and domain names.  The domain names are frequently used
-as "pointers" to other data in the DNS.
-
-3.6.1. Textual expression of RRs
-
-RRs are represented in binary form in the packets of the DNS protocol,
-and are usually represented in highly encoded form when stored in a name
-server or resolver.  In this memo, we adopt a style similar to that used
-
-
-
-Mockapetris                                                    [Page 13]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-in master files in order to show the contents of RRs.  In this format,
-most RRs are shown on a single line, although continuation lines are
-possible using parentheses.
-
-The start of the line gives the owner of the RR.  If a line begins with
-a blank, then the owner is assumed to be the same as that of the
-previous RR.  Blank lines are often included for readability.
-
-Following the owner, we list the TTL, type, and class of the RR.  Class
-and type use the mnemonics defined above, and TTL is an integer before
-the type field.  In order to avoid ambiguity in parsing, type and class
-mnemonics are disjoint, TTLs are integers, and the type mnemonic is
-always last. The IN class and TTL values are often omitted from examples
-in the interests of clarity.
-
-The resource data or RDATA section of the RR are given using knowledge
-of the typical representation for the data.
-
-For example, we might show the RRs carried in a message as:
-
-    ISI.EDU.        MX      10 VENERA.ISI.EDU.
-                    MX      10 VAXA.ISI.EDU.
-    VENERA.ISI.EDU. A       128.9.0.32
-                    A       10.1.0.52
-    VAXA.ISI.EDU.   A       10.2.0.27
-                    A       128.9.0.33
-
-The MX RRs have an RDATA section which consists of a 16 bit number
-followed by a domain name.  The address RRs use a standard IP address
-format to contain a 32 bit internet address.
-
-This example shows six RRs, with two RRs at each of three domain names.
-
-Similarly we might see:
-
-    XX.LCS.MIT.EDU. IN      A       10.0.0.44
-                    CH      A       MIT.EDU. 2420
-
-This example shows two addresses for XX.LCS.MIT.EDU, each of a different
-class.
-
-3.6.2. Aliases and canonical names
-
-In existing systems, hosts and other resources often have several names
-that identify the same resource.  For example, the names C.ISI.EDU and
-USC-ISIC.ARPA both identify the same host.  Similarly, in the case of
-mailboxes, many organizations provide many names that actually go to the
-same mailbox; for example Mockapetris@C.ISI.EDU, Mockapetris@B.ISI.EDU,
-
-
-
-Mockapetris                                                    [Page 14]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-and PVM@ISI.EDU all go to the same mailbox (although the mechanism
-behind this is somewhat complicated).
-
-Most of these systems have a notion that one of the equivalent set of
-names is the canonical or primary name and all others are aliases.
-
-The domain system provides such a feature using the canonical name
-(CNAME) RR.  A CNAME RR identifies its owner name as an alias, and
-specifies the corresponding canonical name in the RDATA section of the
-RR.  If a CNAME RR is present at a node, no other data should be
-present; this ensures that the data for a canonical name and its aliases
-cannot be different.  This rule also insures that a cached CNAME can be
-used without checking with an authoritative server for other RR types.
-
-CNAME RRs cause special action in DNS software.  When a name server
-fails to find a desired RR in the resource set associated with the
-domain name, it checks to see if the resource set consists of a CNAME
-record with a matching class.  If so, the name server includes the CNAME
-record in the response and restarts the query at the domain name
-specified in the data field of the CNAME record.  The one exception to
-this rule is that queries which match the CNAME type are not restarted.
-
-For example, suppose a name server was processing a query with for USC-
-ISIC.ARPA, asking for type A information, and had the following resource
-records:
-
-    USC-ISIC.ARPA   IN      CNAME   C.ISI.EDU
-
-    C.ISI.EDU       IN      A       10.0.0.52
-
-Both of these RRs would be returned in the response to the type A query,
-while a type CNAME or * query should return just the CNAME.
-
-Domain names in RRs which point at another name should always point at
-the primary name and not the alias.  This avoids extra indirections in
-accessing information.  For example, the address to name RR for the
-above host should be:
-
-    52.0.0.10.IN-ADDR.ARPA  IN      PTR     C.ISI.EDU
-
-rather than pointing at USC-ISIC.ARPA.  Of course, by the robustness
-principle, domain software should not fail when presented with CNAME
-chains or loops; CNAME chains should be followed and CNAME loops
-signalled as an error.
-
-3.7. Queries
-
-Queries are messages which may be sent to a name server to provoke a
-
-
-
-Mockapetris                                                    [Page 15]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-response.  In the Internet, queries are carried in UDP datagrams or over
-TCP connections.  The response by the name server either answers the
-question posed in the query, refers the requester to another set of name
-servers, or signals some error condition.
-
-In general, the user does not generate queries directly, but instead
-makes a request to a resolver which in turn sends one or more queries to
-name servers and deals with the error conditions and referrals that may
-result.  Of course, the possible questions which can be asked in a query
-does shape the kind of service a resolver can provide.
-
-DNS queries and responses are carried in a standard message format.  The
-message format has a header containing a number of fixed fields which
-are always present, and four sections which carry query parameters and
-RRs.
-
-The most important field in the header is a four bit field called an
-opcode which separates different queries.  Of the possible 16 values,
-one (standard query) is part of the official protocol, two (inverse
-query and status query) are options, one (completion) is obsolete, and
-the rest are unassigned.
-
-The four sections are:
-
-Question        Carries the query name and other query parameters.
-
-Answer          Carries RRs which directly answer the query.
-
-Authority       Carries RRs which describe other authoritative servers.
-                May optionally carry the SOA RR for the authoritative
-                data in the answer section.
-
-Additional      Carries RRs which may be helpful in using the RRs in the
-                other sections.
-
-Note that the content, but not the format, of these sections varies with
-header opcode.
-
-3.7.1. Standard queries
-
-A standard query specifies a target domain name (QNAME), query type
-(QTYPE), and query class (QCLASS) and asks for RRs which match.  This
-type of query makes up such a vast majority of DNS queries that we use
-the term "query" to mean standard query unless otherwise specified.  The
-QTYPE and QCLASS fields are each 16 bits long, and are a superset of
-defined types and classes.
-
-
-
-
-
-Mockapetris                                                    [Page 16]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-The QTYPE field may contain:
-
-<any type>      matches just that type. (e.g., A, PTR).
-
-AXFR            special zone transfer QTYPE.
-
-MAILB           matches all mail box related RRs (e.g. MB and MG).
-
-*               matches all RR types.
-
-The QCLASS field may contain:
-
-<any class>     matches just that class (e.g., IN, CH).
-
-*               matches aLL RR classes.
-
-Using the query domain name, QTYPE, and QCLASS, the name server looks
-for matching RRs.  In addition to relevant records, the name server may
-return RRs that point toward a name server that has the desired
-information or RRs that are expected to be useful in interpreting the
-relevant RRs.  For example, a name server that doesn't have the
-requested information may know a name server that does; a name server
-that returns a domain name in a relevant RR may also return the RR that
-binds that domain name to an address.
-
-For example, a mailer tying to send mail to Mockapetris@ISI.EDU might
-ask the resolver for mail information about ISI.EDU, resulting in a
-query for QNAME=ISI.EDU, QTYPE=MX, QCLASS=IN.  The response's answer
-section would be:
-
-    ISI.EDU.        MX      10 VENERA.ISI.EDU.
-                    MX      10 VAXA.ISI.EDU.
-
-while the additional section might be:
-
-    VAXA.ISI.EDU.   A       10.2.0.27
-                    A       128.9.0.33
-    VENERA.ISI.EDU. A       10.1.0.52
-                    A       128.9.0.32
-
-Because the server assumes that if the requester wants mail exchange
-information, it will probably want the addresses of the mail exchanges
-soon afterward.
-
-Note that the QCLASS=* construct requires special interpretation
-regarding authority.  Since a particular name server may not know all of
-the classes available in the domain system, it can never know if it is
-authoritative for all classes.  Hence responses to QCLASS=* queries can
-
-
-
-Mockapetris                                                    [Page 17]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-never be authoritative.
-
-3.7.2. Inverse queries (Optional)
-
-Name servers may also support inverse queries that map a particular
-resource to a domain name or domain names that have that resource.  For
-example, while a standard query might map a domain name to a SOA RR, the
-corresponding inverse query might map the SOA RR back to the domain
-name.
-
-Implementation of this service is optional in a name server, but all
-name servers must at least be able to understand an inverse query
-message and return a not-implemented error response.
-
-The domain system cannot guarantee the completeness or uniqueness of
-inverse queries because the domain system is organized by domain name
-rather than by host address or any other resource type.  Inverse queries
-are primarily useful for debugging and database maintenance activities.
-
-Inverse queries may not return the proper TTL, and do not indicate cases
-where the identified RR is one of a set (for example, one address for a
-host having multiple addresses).  Therefore, the RRs returned in inverse
-queries should never be cached.
-
-Inverse queries are NOT an acceptable method for mapping host addresses
-to host names; use the IN-ADDR.ARPA domain instead.
-
-A detailed discussion of inverse queries is contained in [RFC-1035].
-
-3.8. Status queries (Experimental)
-
-To be defined.
-
-3.9. Completion queries (Obsolete)
-
-The optional completion services described in RFCs 882 and 883 have been
-deleted.  Redesigned services may become available in the future, or the
-opcodes may be reclaimed for other use.
-
-4. NAME SERVERS
-
-4.1. Introduction
-
-Name servers are the repositories of information that make up the domain
-database.  The database is divided up into sections called zones, which
-are distributed among the name servers.  While name servers can have
-several optional functions and sources of data, the essential task of a
-name server is to answer queries using data in its zones.  By design,
-
-
-
-Mockapetris                                                    [Page 18]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-name servers can answer queries in a simple manner; the response can
-always be generated using only local data, and either contains the
-answer to the question or a referral to other name servers "closer" to
-the desired information.
-
-A given zone will be available from several name servers to insure its
-availability in spite of host or communication link failure.  By
-administrative fiat, we require every zone to be available on at least
-two servers, and many zones have more redundancy than that.
-
-A given name server will typically support one or more zones, but this
-gives it authoritative information about only a small section of the
-domain tree.  It may also have some cached non-authoritative data about
-other parts of the tree.  The name server marks its responses to queries
-so that the requester can tell whether the response comes from
-authoritative data or not.
-
-4.2. How the database is divided into zones
-
-The domain database is partitioned in two ways: by class, and by "cuts"
-made in the name space between nodes.
-
-The class partition is simple.  The database for any class is organized,
-delegated, and maintained separately from all other classes.  Since, by
-convention, the name spaces are the same for all classes, the separate
-classes can be thought of as an array of parallel namespace trees.  Note
-that the data attached to nodes will be different for these different
-parallel classes.  The most common reasons for creating a new class are
-the necessity for a new data format for existing types or a desire for a
-separately managed version of the existing name space.
-
-Within a class, "cuts" in the name space can be made between any two
-adjacent nodes.  After all cuts are made, each group of connected name
-space is a separate zone.  The zone is said to be authoritative for all
-names in the connected region.  Note that the "cuts" in the name space
-may be in different places for different classes, the name servers may
-be different, etc.
-
-These rules mean that every zone has at least one node, and hence domain
-name, for which it is authoritative, and all of the nodes in a
-particular zone are connected.  Given, the tree structure, every zone
-has a highest node which is closer to the root than any other node in
-the zone.  The name of this node is often used to identify the zone.
-
-It would be possible, though not particularly useful, to partition the
-name space so that each domain name was in a separate zone or so that
-all nodes were in a single zone.  Instead, the database is partitioned
-at points where a particular organization wants to take over control of
-
-
-
-Mockapetris                                                    [Page 19]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-a subtree.  Once an organization controls its own zone it can
-unilaterally change the data in the zone, grow new tree sections
-connected to the zone, delete existing nodes, or delegate new subzones
-under its zone.
-
-If the organization has substructure, it may want to make further
-internal partitions to achieve nested delegations of name space control.
-In some cases, such divisions are made purely to make database
-maintenance more convenient.
-
-4.2.1. Technical considerations
-
-The data that describes a zone has four major parts:
-
-   - Authoritative data for all nodes within the zone.
-
-   - Data that defines the top node of the zone (can be thought of
-     as part of the authoritative data).
-
-   - Data that describes delegated subzones, i.e., cuts around the
-     bottom of the zone.
-
-   - Data that allows access to name servers for subzones
-     (sometimes called "glue" data).
-
-All of this data is expressed in the form of RRs, so a zone can be
-completely described in terms of a set of RRs.  Whole zones can be
-transferred between name servers by transferring the RRs, either carried
-in a series of messages or by FTPing a master file which is a textual
-representation.
-
-The authoritative data for a zone is simply all of the RRs attached to
-all of the nodes from the top node of the zone down to leaf nodes or
-nodes above cuts around the bottom edge of the zone.
-
-Though logically part of the authoritative data, the RRs that describe
-the top node of the zone are especially important to the zone's
-management.  These RRs are of two types: name server RRs that list, one
-per RR, all of the servers for the zone, and a single SOA RR that
-describes zone management parameters.
-
-The RRs that describe cuts around the bottom of the zone are NS RRs that
-name the servers for the subzones.  Since the cuts are between nodes,
-these RRs are NOT part of the authoritative data of the zone, and should
-be exactly the same as the corresponding RRs in the top node of the
-subzone.  Since name servers are always associated with zone boundaries,
-NS RRs are only found at nodes which are the top node of some zone.  In
-the data that makes up a zone, NS RRs are found at the top node of the
-
-
-
-Mockapetris                                                    [Page 20]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-zone (and are authoritative) and at cuts around the bottom of the zone
-(where they are not authoritative), but never in between.
-
-One of the goals of the zone structure is that any zone have all the
-data required to set up communications with the name servers for any
-subzones.  That is, parent zones have all the information needed to
-access servers for their children zones.  The NS RRs that name the
-servers for subzones are often not enough for this task since they name
-the servers, but do not give their addresses.  In particular, if the
-name of the name server is itself in the subzone, we could be faced with
-the situation where the NS RRs tell us that in order to learn a name
-server's address, we should contact the server using the address we wish
-to learn.  To fix this problem, a zone contains "glue" RRs which are not
-part of the authoritative data, and are address RRs for the servers.
-These RRs are only necessary if the name server's name is "below" the
-cut, and are only used as part of a referral response.
-
-4.2.2. Administrative considerations
-
-When some organization wants to control its own domain, the first step
-is to identify the proper parent zone, and get the parent zone's owners
-to agree to the delegation of control.  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.  For example, one university might choose to use
-a single zone, while another might choose to organize by subzones
-dedicated to individual departments or schools.  [RFC-1033] catalogs
-available DNS software an discusses administration procedures.
-
-Once the proper name for the new subzone is selected, the new owners
-should be required to demonstrate redundant name server support.  Note
-that there is no requirement that the servers for a zone reside in a
-host which has a name in that domain.  In many cases, a zone will be
-more accessible to the internet at large if its servers are widely
-distributed rather than being within the physical facilities controlled
-by the same organization that manages the zone.  For example, in the
-current DNS, one of the name servers for the United Kingdom, or UK
-domain, is found in the US.  This allows US hosts to get UK data without
-using limited transatlantic bandwidth.
-
-As the last installation step, the delegation NS RRs and glue RRs
-necessary to make the delegation effective should be added to the parent
-zone.  The administrators of both zones should insure that the NS and
-glue RRs which mark both sides of the cut are consistent and remain so.
-
-4.3. Name server internals
-
-
-
-
-Mockapetris                                                    [Page 21]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-4.3.1. Queries and responses
-
-The principal activity of name servers is to answer standard queries.
-Both the query and its response are carried in a standard message format
-which is described in [RFC-1035].  The query contains a QTYPE, QCLASS,
-and QNAME, which describe the types and classes of desired information
-and the name of interest.
-
-The way that the name server answers the query depends upon whether it
-is operating in recursive mode or not:
-
-   - The simplest mode for the server is non-recursive, since it
-     can answer queries using only local information: the response
-     contains an error, the answer, or a referral to some other
-     server "closer" to the answer.  All name servers must
-     implement non-recursive queries.
-
-   - The simplest mode for the client is recursive, since in this
-     mode the name server acts in the role of a resolver and
-     returns either an error or the answer, but never referrals.
-     This service is optional in a name server, and the name server
-     may also choose to restrict the clients which can use
-     recursive mode.
-
-Recursive service is helpful in several situations:
-
-   - a relatively simple requester that lacks the ability to use
-     anything other than a direct answer to the question.
-
-   - a request that needs to cross protocol or other boundaries and
-     can be sent to a server which can act as intermediary.
-
-   - a network where we want to concentrate the cache rather than
-     having a separate cache for each client.
-
-Non-recursive service is appropriate if the requester is capable of
-pursuing referrals and interested in information which will aid future
-requests.
-
-The use of recursive mode is limited to cases where both the client and
-the name server agree to its use.  The agreement is negotiated through
-the use of two bits in query and response messages:
-
-   - The recursion available, or RA bit, is set or cleared by a
-     name server in all responses.  The bit is true if the name
-     server is willing to provide recursive service for the client,
-     regardless of whether the client requested recursive service.
-     That is, RA signals availability rather than use.
-
-
-
-Mockapetris                                                    [Page 22]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-   - Queries contain a bit called recursion desired or RD.  This
-     bit specifies specifies whether the requester wants recursive
-     service for this query.  Clients may request recursive service
-     from any name server, though they should depend upon receiving
-     it only from servers which have previously sent an RA, or
-     servers which have agreed to provide service through private
-     agreement or some other means outside of the DNS protocol.
-
-The recursive mode occurs when a query with RD set arrives at a server
-which is willing to provide recursive service; the client can verify
-that recursive mode was used by checking that both RA and RD are set in
-the reply.  Note that the name server should never perform recursive
-service unless asked via RD, since this interferes with trouble shooting
-of name servers and their databases.
-
-If recursive service is requested and available, the recursive response
-to a query will be one of the following:
-
-   - The answer to the query, possibly preface by one or more CNAME
-     RRs that specify aliases encountered on the way to an answer.
-
-   - A name error indicating that the name does not exist.  This
-     may include CNAME RRs that indicate that the original query
-     name was an alias for a name which does not exist.
-
-   - A temporary error indication.
-
-If recursive service is not requested or is not available, the non-
-recursive response will be one of the following:
-
-   - An authoritative name error indicating that the name does not
-     exist.
-
-   - A temporary error indication.
-
-   - Some combination of:
-
-     RRs that answer the question, together with an indication
-     whether the data comes from a zone or is cached.
-
-     A referral to name servers which have zones which are closer
-     ancestors to the name than the server sending the reply.
-
-   - RRs that the name server thinks will prove useful to the
-     requester.
-
-
-
-
-
-
-Mockapetris                                                    [Page 23]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-4.3.2. Algorithm
-
-The actual algorithm used by the name server will depend on the local OS
-and data structures used to store RRs.  The following algorithm assumes
-that the RRs are organized in several tree structures, one for each
-zone, and another for the cache:
-
-   1. Set or clear the value of recursion available in the response
-      depending on whether the name server is willing to provide
-      recursive service.  If recursive service is available and
-      requested via the RD bit in the query, go to step 5,
-      otherwise step 2.
-
-   2. Search the available zones for the zone which is the nearest
-      ancestor to QNAME.  If such a zone is found, go to step 3,
-      otherwise step 4.
-
-   3. Start matching down, label by label, in the zone.  The
-      matching process can terminate several ways:
-
-         a. If the whole of QNAME is matched, we have found the
-            node.
-
-            If the data at the node is a CNAME, and QTYPE doesn't
-            match CNAME, copy the CNAME RR into the answer section
-            of the response, change QNAME to the canonical name in
-            the CNAME RR, and go back to step 1.
-
-            Otherwise, copy all RRs which match QTYPE into the
-            answer section and go to step 6.
-
-         b. If a match would take us out of the authoritative data,
-            we have a referral.  This happens when we encounter a
-            node with NS RRs marking cuts along the bottom of a
-            zone.
-
-            Copy the NS RRs for the subzone into the authority
-            section of the reply.  Put whatever addresses are
-            available into the additional section, using glue RRs
-            if the addresses are not available from authoritative
-            data or the cache.  Go to step 4.
-
-         c. If at some label, a match is impossible (i.e., the
-            corresponding label does not exist), look to see if a
-            the "*" label exists.
-
-            If the "*" label does not exist, check whether the name
-            we are looking for is the original QNAME in the query
-
-
-
-Mockapetris                                                    [Page 24]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-            or a name we have followed due to a CNAME.  If the name
-            is original, set an authoritative name error in the
-            response and exit.  Otherwise just exit.
-
-            If the "*" label does exist, match RRs at that node
-            against QTYPE.  If any match, copy them into the answer
-            section, but set the owner of the RR to be QNAME, and
-            not the node with the "*" label.  Go to step 6.
-
-   4. Start matching down in the cache.  If QNAME is found in the
-      cache, copy all RRs attached to it that match QTYPE into the
-      answer section.  If there was no delegation from
-      authoritative data, look for the best one from the cache, and
-      put it in the authority section.  Go to step 6.
-
-   5. Using the local resolver or a copy of its algorithm (see
-      resolver section of this memo) to answer the query.  Store
-      the results, including any intermediate CNAMEs, in the answer
-      section of the response.
-
-   6. Using local data only, attempt to add other RRs which may be
-      useful to the additional section of the query.  Exit.
-
-4.3.3. Wildcards
-
-In the previous algorithm, special treatment was given to RRs with owner
-names starting with the label "*".  Such RRs are called wildcards.
-Wildcard RRs can be thought of as instructions for synthesizing RRs.
-When the appropriate conditions are met, the name server creates RRs
-with an owner name equal to the query name and contents taken from the
-wildcard RRs.
-
-This facility is most often used to create a zone which will be used to
-forward mail from the Internet to some other mail system.  The general
-idea is that any name in that zone which is presented to server in a
-query will be assumed to exist, with certain properties, unless explicit
-evidence exists to the contrary.  Note that the use of the term zone
-here, instead of domain, is intentional; such defaults do not propagate
-across zone boundaries, although a subzone may choose to achieve that
-appearance by setting up similar defaults.
-
-The contents of the wildcard RRs follows the usual rules and formats for
-RRs.  The wildcards in the zone have an owner name that controls the
-query names they will match.  The owner name of the wildcard RRs is of
-the form "*.<anydomain>", where <anydomain> is any domain name.
-<anydomain> should not contain other * labels, and should be in the
-authoritative data of the zone.  The wildcards potentially apply to
-descendants of <anydomain>, but not to <anydomain> itself.  Another way
-
-
-
-Mockapetris                                                    [Page 25]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-to look at this is that the "*" label always matches at least one whole
-label and sometimes more, but always whole labels.
-
-Wildcard RRs do not apply:
-
-   - When the query is in another zone.  That is, delegation cancels
-     the wildcard defaults.
-
-   - When the query name or a name between the wildcard domain and
-     the query name is know to exist.  For example, if a wildcard
-     RR has an owner name of "*.X", and the zone also contains RRs
-     attached to B.X, the wildcards would apply to queries for name
-     Z.X (presuming there is no explicit information for Z.X), but
-     not to B.X, A.B.X, or X.
-
-A * label appearing in a query name has no special effect, but can be
-used to test for wildcards in an authoritative zone; such a query is the
-only way to get a response containing RRs with an owner name with * in
-it.  The result of such a query should not be cached.
-
-Note that the contents of the wildcard RRs are not modified when used to
-synthesize RRs.
-
-To illustrate the use of wildcard RRs, suppose a large company with a
-large, non-IP/TCP, network wanted to create a mail gateway.  If the
-company was called X.COM, and IP/TCP capable gateway machine was called
-A.X.COM, the following RRs might be entered into the COM zone:
-
-    X.COM           MX      10      A.X.COM
-
-    *.X.COM         MX      10      A.X.COM
-
-    A.X.COM         A       1.2.3.4
-    A.X.COM         MX      10      A.X.COM
-
-    *.A.X.COM       MX      10      A.X.COM
-
-This would cause any MX query for any domain name ending in X.COM to
-return an MX RR pointing at A.X.COM.  Two wildcard RRs are required
-since the effect of the wildcard at *.X.COM is inhibited in the A.X.COM
-subtree by the explicit data for A.X.COM.  Note also that the explicit
-MX data at X.COM and A.X.COM is required, and that none of the RRs above
-would match a query name of XX.COM.
-
-4.3.4. Negative response caching (Optional)
-
-The DNS provides an optional service which allows name servers to
-distribute, and resolvers to cache, negative results with TTLs.  For
-
-
-
-Mockapetris                                                    [Page 26]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-example, a name server can distribute a TTL along with a name error
-indication, and a resolver receiving such information is allowed to
-assume that the name does not exist during the TTL period without
-consulting authoritative data.  Similarly, a resolver can make a query
-with a QTYPE which matches multiple types, and cache the fact that some
-of the types are not present.
-
-This feature can be particularly important in a system which implements
-naming shorthands that use search lists beacuse a popular shorthand,
-which happens to require a suffix toward the end of the search list,
-will generate multiple name errors whenever it is used.
-
-The method is that a name server may add an SOA RR to the additional
-section of a response when that response is authoritative.  The SOA must
-be that of the zone which was the source of the authoritative data in
-the answer section, or name error if applicable.  The MINIMUM field of
-the SOA controls the length of time that the negative result may be
-cached.
-
-Note that in some circumstances, the answer section may contain multiple
-owner names.  In this case, the SOA mechanism should only be used for
-the data which matches QNAME, which is the only authoritative data in
-this section.
-
-Name servers and resolvers should never attempt to add SOAs to the
-additional section of a non-authoritative response, or attempt to infer
-results which are not directly stated in an authoritative response.
-There are several reasons for this, including: cached information isn't
-usually enough to match up RRs and their zone names, SOA RRs may be
-cached due to direct SOA queries, and name servers are not required to
-output the SOAs in the authority section.
-
-This feature is optional, although a refined version is expected to
-become part of the standard protocol in the future.  Name servers are
-not required to add the SOA RRs in all authoritative responses, nor are
-resolvers required to cache negative results.  Both are recommended.
-All resolvers and recursive name servers are required to at least be
-able to ignore the SOA RR when it is present in a response.
-
-Some experiments have also been proposed which will use this feature.
-The idea is that if cached data is known to come from a particular zone,
-and if an authoritative copy of the zone's SOA is obtained, and if the
-zone's SERIAL has not changed since the data was cached, then the TTL of
-the cached data can be reset to the zone MINIMUM value if it is smaller.
-This usage is mentioned for planning purposes only, and is not
-recommended as yet.
-
-
-
-
-
-Mockapetris                                                    [Page 27]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-4.3.5. Zone maintenance and transfers
-
-Part of the job of a zone administrator is to maintain the zones at all
-of the name servers which are authoritative for the zone.  When the
-inevitable changes are made, they must be distributed to all of the name
-servers.  While this distribution can be accomplished using FTP or some
-other ad hoc procedure, the preferred method is the zone transfer part
-of the DNS protocol.
-
-The general model of automatic zone transfer or refreshing is that one
-of the name servers is the master or primary for the zone.  Changes are
-coordinated at the primary, typically by editing a master file for the
-zone.  After editing, the administrator signals the master server to
-load the new zone.  The other non-master or secondary servers for the
-zone periodically check for changes (at a selectable interval) and
-obtain new zone copies when changes have been made.
-
-To detect changes, secondaries just check the SERIAL field of the SOA
-for the zone.  In addition to whatever other changes are made, the
-SERIAL field in the SOA of the zone is always advanced whenever any
-change is made to the zone.  The advancing can be a simple increment, or
-could be based on the write date and time of the master file, etc.  The
-purpose is to make it possible to determine which of two copies of a
-zone is more recent by comparing serial numbers.  Serial number advances
-and comparisons use sequence space arithmetic, so there is a theoretic
-limit on how fast a zone can be updated, basically that old copies must
-die out before the serial number covers half of its 32 bit range.  In
-practice, the only concern is that the compare operation deals properly
-with comparisons around the boundary between the most positive and most
-negative 32 bit numbers.
-
-The periodic polling of the secondary servers is controlled by
-parameters in the SOA RR for the zone, which set the minimum acceptable
-polling intervals.  The parameters are called REFRESH, RETRY, and
-EXPIRE.  Whenever a new zone is loaded in a secondary, the secondary
-waits REFRESH seconds before checking with the primary for a new serial.
-If this check cannot be completed, new checks are started every RETRY
-seconds.  The check is a simple query to the primary for the SOA RR of
-the zone.  If the serial field in the secondary's zone copy is equal to
-the serial returned by the primary, then no changes have occurred, and
-the REFRESH interval wait is restarted.  If the secondary finds it
-impossible to perform a serial check for the EXPIRE interval, it must
-assume that its copy of the zone is obsolete an discard it.
-
-When the poll shows that the zone has changed, then the secondary server
-must request a zone transfer via an AXFR request for the zone.  The AXFR
-may cause an error, such as refused, but normally is answered by a
-sequence of response messages.  The first and last messages must contain
-
-
-
-Mockapetris                                                    [Page 28]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-the data for the top authoritative node of the zone.  Intermediate
-messages carry all of the other RRs from the zone, including both
-authoritative and non-authoritative RRs.  The stream of messages allows
-the secondary to construct a copy of the zone.  Because accuracy is
-essential, TCP or some other reliable protocol must be used for AXFR
-requests.
-
-Each secondary server is required to perform the following operations
-against the master, but may also optionally perform these operations
-against other secondary servers.  This strategy can improve the transfer
-process when the primary is unavailable due to host downtime or network
-problems, or when a secondary server has better network access to an
-"intermediate" secondary than to the primary.
-
-5. RESOLVERS
-
-5.1. Introduction
-
-Resolvers are programs that interface user programs to domain name
-servers.  In the simplest case, a resolver receives a request from a
-user program (e.g., mail programs, TELNET, FTP) in the form of a
-subroutine call, system call etc., and returns the desired information
-in a form compatible with the local host's data formats.
-
-The resolver is located on the same machine as the program that requests
-the resolver's services, but it may need to consult name servers on
-other hosts.  Because a resolver may need to consult several name
-servers, or may have the requested information in a local cache, the
-amount of time that a resolver will take to complete can vary quite a
-bit, from milliseconds to several seconds.
-
-A very important goal of the resolver is to eliminate network delay and
-name server load from most requests by answering them from its cache of
-prior results.  It follows that caches which are shared by multiple
-processes, users, machines, etc., are more efficient than non-shared
-caches.
-
-5.2. Client-resolver interface
-
-5.2.1. Typical functions
-
-The client interface to the resolver is influenced by the local host's
-conventions, but the typical resolver-client interface has three
-functions:
-
-   1. Host name to host address translation.
-
-      This function is often defined to mimic a previous HOSTS.TXT
-
-
-
-Mockapetris                                                    [Page 29]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-      based function.  Given a character string, the caller wants
-      one or more 32 bit IP addresses.  Under the DNS, it
-      translates into a request for type A RRs.  Since the DNS does
-      not preserve the order of RRs, this function may choose to
-      sort the returned addresses or select the "best" address if
-      the service returns only one choice to the client.  Note that
-      a multiple address return is recommended, but a single
-      address may be the only way to emulate prior HOSTS.TXT
-      services.
-
-   2. Host address to host name translation
-
-      This function will often follow the form of previous
-      functions.  Given a 32 bit IP address, the caller wants a
-      character string.  The octets of the IP address are reversed,
-      used as name components, and suffixed with "IN-ADDR.ARPA".  A
-      type PTR query is used to get the RR with the primary name of
-      the host.  For example, a request for the host name
-      corresponding to IP address 1.2.3.4 looks for PTR RRs for
-      domain name "4.3.2.1.IN-ADDR.ARPA".
-
-   3. General lookup function
-
-      This function retrieves arbitrary information from the DNS,
-      and has no counterpart in previous systems.  The caller
-      supplies a QNAME, QTYPE, and QCLASS, and wants all of the
-      matching RRs.  This function will often use the DNS format
-      for all RR data instead of the local host's, and returns all
-      RR content (e.g., TTL) instead of a processed form with local
-      quoting conventions.
-
-When the resolver performs the indicated function, it usually has one of
-the following results to pass back to the client:
-
-   - One or more RRs giving the requested data.
-
-     In this case the resolver returns the answer in the
-     appropriate format.
-
-   - A name error (NE).
-
-     This happens when the referenced name does not exist.  For
-     example, a user may have mistyped a host name.
-
-   - A data not found error.
-
-     This happens when the referenced name exists, but data of the
-     appropriate type does not.  For example, a host address
-
-
-
-Mockapetris                                                    [Page 30]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-     function applied to a mailbox name would return this error
-     since the name exists, but no address RR is present.
-
-It is important to note that the functions for translating between host
-names and addresses may combine the "name error" and "data not found"
-error conditions into a single type of error return, but the general
-function should not.  One reason for this is that applications may ask
-first for one type of information about a name followed by a second
-request to the same name for some other type of information; if the two
-errors are combined, then useless queries may slow the application.
-
-5.2.2. Aliases
-
-While attempting to resolve a particular request, the resolver may find
-that the name in question is an alias.  For example, the resolver might
-find that the name given for host name to address translation is an
-alias when it finds the CNAME RR.  If possible, the alias condition
-should be signalled back from the resolver to the client.
-
-In most cases a resolver simply restarts the query at the new name when
-it encounters a CNAME.  However, when performing the general function,
-the resolver should not pursue aliases when the CNAME RR matches the
-query type.  This allows queries which ask whether an alias is present.
-For example, if the query type is CNAME, the user is interested in the
-CNAME RR itself, and not the RRs at the name it points to.
-
-Several special conditions can occur with aliases.  Multiple levels of
-aliases should be avoided due to their lack of efficiency, but should
-not be signalled as an error.  Alias loops and aliases which point to
-non-existent names should be caught and an error condition passed back
-to the client.
-
-5.2.3. Temporary failures
-
-In a less than perfect world, all resolvers will occasionally be unable
-to resolve a particular request.  This condition can be caused by a
-resolver which becomes separated from the rest of the network due to a
-link failure or gateway problem, or less often by coincident failure or
-unavailability of all servers for a particular domain.
-
-It is essential that this sort of condition should not be signalled as a
-name or data not present error to applications.  This sort of behavior
-is annoying to humans, and can wreak havoc when mail systems use the
-DNS.
-
-While in some cases it is possible to deal with such a temporary problem
-by blocking the request indefinitely, this is usually not a good choice,
-particularly when the client is a server process that could move on to
-
-
-
-Mockapetris                                                    [Page 31]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-other tasks.  The recommended solution is to always have temporary
-failure as one of the possible results of a resolver function, even
-though this may make emulation of existing HOSTS.TXT functions more
-difficult.
-
-5.3. Resolver internals
-
-Every resolver implementation uses slightly different algorithms, and
-typically spends much more logic dealing with errors of various sorts
-than typical occurances.  This section outlines a recommended basic
-strategy for resolver operation, but leaves details to [RFC-1035].
-
-5.3.1. Stub resolvers
-
-One option for implementing a resolver is to move the resolution
-function out of the local machine and into a name server which supports
-recursive queries.  This can provide an easy method of providing domain
-service in a PC which lacks the resources to perform the resolver
-function, or can centralize the cache for a whole local network or
-organization.
-
-All that the remaining stub needs is a list of name server addresses
-that will perform the recursive requests.  This type of resolver
-presumably needs the information in a configuration file, since it
-probably lacks the sophistication to locate it in the domain database.
-The user also needs to verify that the listed servers will perform the
-recursive service; a name server is free to refuse to perform recursive
-services for any or all clients.  The user should consult the local
-system administrator to find name servers willing to perform the
-service.
-
-This type of service suffers from some drawbacks.  Since the recursive
-requests may take an arbitrary amount of time to perform, the stub may
-have difficulty optimizing retransmission intervals to deal with both
-lost UDP packets and dead servers; the name server can be easily
-overloaded by too zealous a stub if it interprets retransmissions as new
-requests.  Use of TCP may be an answer, but TCP may well place burdens
-on the host's capabilities which are similar to those of a real
-resolver.
-
-5.3.2. Resources
-
-In addition to its own resources, the resolver may also have shared
-access to zones maintained by a local name server.  This gives the
-resolver the advantage of more rapid access, but the resolver must be
-careful to never let cached information override zone data.  In this
-discussion the term "local information" is meant to mean the union of
-the cache and such shared zones, with the understanding that
-
-
-
-Mockapetris                                                    [Page 32]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-authoritative data is always used in preference to cached data when both
-are present.
-
-The following resolver algorithm assumes that all functions have been
-converted to a general lookup function, and uses the following data
-structures to represent the state of a request in progress in the
-resolver:
-
-SNAME           the domain name we are searching for.
-
-STYPE           the QTYPE of the search request.
-
-SCLASS          the QCLASS of the search request.
-
-SLIST           a structure which describes the name servers and the
-                zone which the resolver is currently trying to query.
-                This structure keeps track of the resolver's current
-                best guess about which name servers hold the desired
-                information; it is updated when arriving information
-                changes the guess.  This structure includes the
-                equivalent of a zone name, the known name servers for
-                the zone, the known addresses for the name servers, and
-                history information which can be used to suggest which
-                server is likely to be the best one to try next.  The
-                zone name equivalent is a match count of the number of
-                labels from the root down which SNAME has in common with
-                the zone being queried; this is used as a measure of how
-                "close" the resolver is to SNAME.
-
-SBELT           a "safety belt" structure of the same form as SLIST,
-                which is initialized from a configuration file, and
-                lists servers which should be used when the resolver
-                doesn't have any local information to guide name server
-                selection.  The match count will be -1 to indicate that
-                no labels are known to match.
-
-CACHE           A structure which stores the results from previous
-                responses.  Since resolvers are responsible for
-                discarding old RRs whose TTL has expired, most
-                implementations convert the interval specified in
-                arriving RRs to some sort of absolute time when the RR
-                is stored in the cache.  Instead of counting the TTLs
-                down individually, the resolver just ignores or discards
-                old RRs when it runs across them in the course of a
-                search, or discards them during periodic sweeps to
-                reclaim the memory consumed by old RRs.
-
-
-
-
-
-Mockapetris                                                    [Page 33]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-5.3.3. Algorithm
-
-The top level algorithm has four steps:
-
-   1. See if the answer is in local information, and if so return
-      it to the client.
-
-   2. Find the best servers to ask.
-
-   3. Send them queries until one returns a response.
-
-   4. Analyze the response, either:
-
-         a. if the response answers the question or contains a name
-            error, cache the data as well as returning it back to
-            the client.
-
-         b. if the response contains a better delegation to other
-            servers, cache the delegation information, and go to
-            step 2.
-
-         c. if the response shows a CNAME and that is not the
-            answer itself, cache the CNAME, change the SNAME to the
-            canonical name in the CNAME RR and go to step 1.
-
-         d. if the response shows a servers failure or other
-            bizarre contents, delete the server from the SLIST and
-            go back to step 3.
-
-Step 1 searches the cache for the desired data. If the data is in the
-cache, it is assumed to be good enough for normal use.  Some resolvers
-have an option at the user interface which will force the resolver to
-ignore the cached data and consult with an authoritative server.  This
-is not recommended as the default.  If the resolver has direct access to
-a name server's zones, it should check to see if the desired data is
-present in authoritative form, and if so, use the authoritative data in
-preference to cached data.
-
-Step 2 looks for a name server to ask for the required data.  The
-general strategy is to look for locally-available name server RRs,
-starting at SNAME, then the parent domain name of SNAME, the
-grandparent, and so on toward the root.  Thus if SNAME were
-Mockapetris.ISI.EDU, this step would look for NS RRs for
-Mockapetris.ISI.EDU, then ISI.EDU, then EDU, and then . (the root).
-These NS RRs list the names of hosts for a zone at or above SNAME.  Copy
-the names into SLIST.  Set up their addresses using local data.  It may
-be the case that the addresses are not available.  The resolver has many
-choices here; the best is to start parallel resolver processes looking
-
-
-
-Mockapetris                                                    [Page 34]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-for the addresses while continuing onward with the addresses which are
-available.  Obviously, the design choices and options are complicated
-and a function of the local host's capabilities.  The recommended
-priorities for the resolver designer are:
-
-   1. Bound the amount of work (packets sent, parallel processes
-      started) so that a request can't get into an infinite loop or
-      start off a chain reaction of requests or queries with other
-      implementations EVEN IF SOMEONE HAS INCORRECTLY CONFIGURED
-      SOME DATA.
-
-   2. Get back an answer if at all possible.
-
-   3. Avoid unnecessary transmissions.
-
-   4. Get the answer as quickly as possible.
-
-If the search for NS RRs fails, then the resolver initializes SLIST from
-the safety belt SBELT.  The basic idea is that when the resolver has no
-idea what servers to ask, it should use information from a configuration
-file that lists several servers which are expected to be helpful.
-Although there are special situations, the usual choice is two of the
-root servers and two of the servers for the host's domain.  The reason
-for two of each is for redundancy.  The root servers will provide
-eventual access to all of the domain space.  The two local servers will
-allow the resolver to continue to resolve local names if the local
-network becomes isolated from the internet due to gateway or link
-failure.
-
-In addition to the names and addresses of the servers, the SLIST data
-structure can be sorted to use the best servers first, and to insure
-that all addresses of all servers are used in a round-robin manner.  The
-sorting can be a simple function of preferring addresses on the local
-network over others, or may involve statistics from past events, such as
-previous response times and batting averages.
-
-Step 3 sends out queries until a response is received.  The strategy is
-to cycle around all of the addresses for all of the servers with a
-timeout between each transmission.  In practice it is important to use
-all addresses of a multihomed host, and too aggressive a retransmission
-policy actually slows response when used by multiple resolvers
-contending for the same name server and even occasionally for a single
-resolver.  SLIST typically contains data values to control the timeouts
-and keep track of previous transmissions.
-
-Step 4 involves analyzing responses.  The resolver should be highly
-paranoid in its parsing of responses.  It should also check that the
-response matches the query it sent using the ID field in the response.
-
-
-
-Mockapetris                                                    [Page 35]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-The ideal answer is one from a server authoritative for the query which
-either gives the required data or a name error.  The data is passed back
-to the user and entered in the cache for future use if its TTL is
-greater than zero.
-
-If the response shows a delegation, the resolver should check to see
-that the delegation is "closer" to the answer than the servers in SLIST
-are.  This can be done by comparing the match count in SLIST with that
-computed from SNAME and the NS RRs in the delegation.  If not, the reply
-is bogus and should be ignored.  If the delegation is valid the NS
-delegation RRs and any address RRs for the servers should be cached.
-The name servers are entered in the SLIST, and the search is restarted.
-
-If the response contains a CNAME, the search is restarted at the CNAME
-unless the response has the data for the canonical name or if the CNAME
-is the answer itself.
-
-Details and implementation hints can be found in [RFC-1035].
-
-6. A SCENARIO
-
-In our sample domain space, suppose we wanted separate administrative
-control for the root, MIL, EDU, MIT.EDU and ISI.EDU zones.  We might
-allocate name servers as follows:
-
-
-                                   |(C.ISI.EDU,SRI-NIC.ARPA
-                                   | A.ISI.EDU)
-             +---------------------+------------------+
-             |                     |                  |
-            MIL                   EDU                ARPA
-             |(SRI-NIC.ARPA,       |(SRI-NIC.ARPA,    |
-             | A.ISI.EDU           | C.ISI.EDU)       |
-       +-----+-----+               |     +------+-----+-----+
-       |     |     |               |     |      |           |
-      BRL  NOSC  DARPA             |  IN-ADDR  SRI-NIC     ACC
-                                   |
-       +--------+------------------+---------------+--------+
-       |        |                  |               |        |
-      UCI      MIT                 |              UDEL     YALE
-                |(XX.LCS.MIT.EDU, ISI
-                |ACHILLES.MIT.EDU) |(VAXA.ISI.EDU,VENERA.ISI.EDU,
-            +---+---+              | A.ISI.EDU)
-            |       |              |
-           LCS   ACHILLES +--+-----+-----+--------+
-            |             |  |     |     |        |
-            XX            A  C   VAXA  VENERA Mockapetris
-
-
-
-
-Mockapetris                                                    [Page 36]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-In this example, the authoritative name server is shown in parentheses
-at the point in the domain tree at which is assumes control.
-
-Thus the root name servers are on C.ISI.EDU, SRI-NIC.ARPA, and
-A.ISI.EDU.  The MIL domain is served by SRI-NIC.ARPA and A.ISI.EDU.  The
-EDU domain is served by SRI-NIC.ARPA. and C.ISI.EDU.  Note that servers
-may have zones which are contiguous or disjoint.  In this scenario,
-C.ISI.EDU has contiguous zones at the root and EDU domains.  A.ISI.EDU
-has contiguous zones at the root and MIL domains, but also has a non-
-contiguous zone at ISI.EDU.
-
-6.1. C.ISI.EDU name server
-
-C.ISI.EDU is a name server for the root, MIL, and EDU domains of the IN
-class, and would have zones for these domains.  The zone data for the
-root domain might be:
-
-    .       IN      SOA     SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
-                            870611          ;serial
-                            1800            ;refresh every 30 min
-                            300             ;retry every 5 min
-                            604800          ;expire after a week
-                            86400)          ;minimum of a day
-                    NS      A.ISI.EDU.
-                    NS      C.ISI.EDU.
-                    NS      SRI-NIC.ARPA.
-
-    MIL.    86400   NS      SRI-NIC.ARPA.
-            86400   NS      A.ISI.EDU.
-
-    EDU.    86400   NS      SRI-NIC.ARPA.
-            86400   NS      C.ISI.EDU.
-
-    SRI-NIC.ARPA.   A       26.0.0.73
-                    A       10.0.0.51
-                    MX      0 SRI-NIC.ARPA.
-                    HINFO   DEC-2060 TOPS20
-
-    ACC.ARPA.       A       26.6.0.65
-                    HINFO   PDP-11/70 UNIX
-                    MX      10 ACC.ARPA.
-
-    USC-ISIC.ARPA.  CNAME   C.ISI.EDU.
-
-    73.0.0.26.IN-ADDR.ARPA.  PTR    SRI-NIC.ARPA.
-    65.0.6.26.IN-ADDR.ARPA.  PTR    ACC.ARPA.
-    51.0.0.10.IN-ADDR.ARPA.  PTR    SRI-NIC.ARPA.
-    52.0.0.10.IN-ADDR.ARPA.  PTR    C.ISI.EDU.
-
-
-
-Mockapetris                                                    [Page 37]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-    103.0.3.26.IN-ADDR.ARPA. PTR    A.ISI.EDU.
-
-    A.ISI.EDU. 86400 A      26.3.0.103
-    C.ISI.EDU. 86400 A      10.0.0.52
-
-This data is represented as it would be in a master file.  Most RRs are
-single line entries; the sole exception here is the SOA RR, which uses
-"(" to start a multi-line RR and ")" to show the end of a multi-line RR.
-Since the class of all RRs in a zone must be the same, only the first RR
-in a zone need specify the class.  When a name server loads a zone, it
-forces the TTL of all authoritative RRs to be at least the MINIMUM field
-of the SOA, here 86400 seconds, or one day.  The NS RRs marking
-delegation of the MIL and EDU domains, together with the glue RRs for
-the servers host addresses, are not part of the authoritative data in
-the zone, and hence have explicit TTLs.
-
-Four RRs are attached to the root node: the SOA which describes the root
-zone and the 3 NS RRs which list the name servers for the root.  The
-data in the SOA RR describes the management of the zone.  The zone data
-is maintained on host SRI-NIC.ARPA, and the responsible party for the
-zone is HOSTMASTER@SRI-NIC.ARPA.  A key item in the SOA is the 86400
-second minimum TTL, which means that all authoritative data in the zone
-has at least that TTL, although higher values may be explicitly
-specified.
-
-The NS RRs for the MIL and EDU domains mark the boundary between the
-root zone and the MIL and EDU zones.  Note that in this example, the
-lower zones happen to be supported by name servers which also support
-the root zone.
-
-The master file for the EDU zone might be stated relative to the origin
-EDU.  The zone data for the EDU domain might be:
-
-    EDU.  IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
-                            870729 ;serial
-                            1800 ;refresh every 30 minutes
-                            300 ;retry every 5 minutes
-                            604800 ;expire after a week
-                            86400 ;minimum of a day
-                            )
-                    NS SRI-NIC.ARPA.
-                    NS C.ISI.EDU.
-
-    UCI 172800 NS ICS.UCI
-                    172800 NS ROME.UCI
-    ICS.UCI 172800 A 192.5.19.1
-    ROME.UCI 172800 A 192.5.19.31
-
-
-
-
-Mockapetris                                                    [Page 38]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-    ISI 172800 NS VAXA.ISI
-                    172800 NS A.ISI
-                    172800 NS VENERA.ISI.EDU.
-    VAXA.ISI 172800 A 10.2.0.27
-                    172800 A 128.9.0.33
-    VENERA.ISI.EDU. 172800 A 10.1.0.52
-                    172800 A 128.9.0.32
-    A.ISI 172800 A 26.3.0.103
-
-    UDEL.EDU.  172800 NS LOUIE.UDEL.EDU.
-                    172800 NS UMN-REI-UC.ARPA.
-    LOUIE.UDEL.EDU. 172800 A 10.0.0.96
-                    172800 A 192.5.39.3
-
-    YALE.EDU.  172800 NS YALE.ARPA.
-    YALE.EDU.  172800 NS YALE-BULLDOG.ARPA.
-
-    MIT.EDU.  43200 NS XX.LCS.MIT.EDU.
-                      43200 NS ACHILLES.MIT.EDU.
-    XX.LCS.MIT.EDU.  43200 A 10.0.0.44
-    ACHILLES.MIT.EDU. 43200 A 18.72.0.8
-
-Note the use of relative names here.  The owner name for the ISI.EDU. is
-stated using a relative name, as are two of the name server RR contents.
-Relative and absolute domain names may be freely intermixed in a master
-
-6.2. Example standard queries
-
-The following queries and responses illustrate name server behavior.
-Unless otherwise noted, the queries do not have recursion desired (RD)
-in the header.  Note that the answers to non-recursive queries do depend
-on the server being asked, but do not depend on the identity of the
-requester.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 39]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-6.2.1. QNAME=SRI-NIC.ARPA, QTYPE=A
-
-The query would look like:
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY                                     |
-               +---------------------------------------------------+
-    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A           |
-               +---------------------------------------------------+
-    Answer     | <empty>                                           |
-               +---------------------------------------------------+
-    Authority  | <empty>                                           |
-               +---------------------------------------------------+
-    Additional | <empty>                                           |
-               +---------------------------------------------------+
-
-The response from C.ISI.EDU would be:
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
-               +---------------------------------------------------+
-    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A           |
-               +---------------------------------------------------+
-    Answer     | SRI-NIC.ARPA. 86400 IN A 26.0.0.73                |
-               |               86400 IN A 10.0.0.51                |
-               +---------------------------------------------------+
-    Authority  | <empty>                                           |
-               +---------------------------------------------------+
-    Additional | <empty>                                           |
-               +---------------------------------------------------+
-
-The header of the response looks like the header of the query, except
-that the RESPONSE bit is set, indicating that this message is a
-response, not a query, and the Authoritative Answer (AA) bit is set
-indicating that the address RRs in the answer section are from
-authoritative data.  The question section of the response matches the
-question section of the query.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 40]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-If the same query was sent to some other server which was not
-authoritative for SRI-NIC.ARPA, the response might be:
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY,RESPONSE                            |
-               +---------------------------------------------------+
-    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A           |
-               +---------------------------------------------------+
-    Answer     | SRI-NIC.ARPA. 1777 IN A 10.0.0.51                 |
-               |               1777 IN A 26.0.0.73                 |
-               +---------------------------------------------------+
-    Authority  | <empty>                                           |
-               +---------------------------------------------------+
-    Additional | <empty>                                           |
-               +---------------------------------------------------+
-
-This response is different from the previous one in two ways: the header
-does not have AA set, and the TTLs are different.  The inference is that
-the data did not come from a zone, but from a cache.  The difference
-between the authoritative TTL and the TTL here is due to aging of the
-data in a cache.  The difference in ordering of the RRs in the answer
-section is not significant.
-
-6.2.2. QNAME=SRI-NIC.ARPA, QTYPE=*
-
-A query similar to the previous one, but using a QTYPE of *, would
-receive the following response from C.ISI.EDU:
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
-               +---------------------------------------------------+
-    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=*           |
-               +---------------------------------------------------+
-    Answer     | SRI-NIC.ARPA. 86400 IN  A     26.0.0.73           |
-               |                         A     10.0.0.51           |
-               |                         MX    0 SRI-NIC.ARPA.     |
-               |                         HINFO DEC-2060 TOPS20     |
-               +---------------------------------------------------+
-    Authority  | <empty>                                           |
-               +---------------------------------------------------+
-    Additional | <empty>                                           |
-               +---------------------------------------------------+
-
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 41]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-If a similar query was directed to two name servers which are not
-authoritative for SRI-NIC.ARPA, the responses might be:
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY, RESPONSE                           |
-               +---------------------------------------------------+
-    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=*           |
-               +---------------------------------------------------+
-    Answer     | SRI-NIC.ARPA. 12345 IN     A       26.0.0.73      |
-               |                            A       10.0.0.51      |
-               +---------------------------------------------------+
-    Authority  | <empty>                                           |
-               +---------------------------------------------------+
-    Additional | <empty>                                           |
-               +---------------------------------------------------+
-
-and
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY, RESPONSE                           |
-               +---------------------------------------------------+
-    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=*           |
-               +---------------------------------------------------+
-    Answer     | SRI-NIC.ARPA. 1290 IN HINFO  DEC-2060 TOPS20      |
-               +---------------------------------------------------+
-    Authority  | <empty>                                           |
-               +---------------------------------------------------+
-    Additional | <empty>                                           |
-               +---------------------------------------------------+
-
-Neither of these answers have AA set, so neither response comes from
-authoritative data.  The different contents and different TTLs suggest
-that the two servers cached data at different times, and that the first
-server cached the response to a QTYPE=A query and the second cached the
-response to a HINFO query.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 42]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-6.2.3. QNAME=SRI-NIC.ARPA, QTYPE=MX
-
-This type of query might be result from a mailer trying to look up
-routing information for the mail destination HOSTMASTER@SRI-NIC.ARPA.
-The response from C.ISI.EDU would be:
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
-               +---------------------------------------------------+
-    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=MX          |
-               +---------------------------------------------------+
-    Answer     | SRI-NIC.ARPA. 86400 IN     MX      0 SRI-NIC.ARPA.|
-               +---------------------------------------------------+
-    Authority  | <empty>                                           |
-               +---------------------------------------------------+
-    Additional | SRI-NIC.ARPA. 86400 IN     A       26.0.0.73      |
-               |                            A       10.0.0.51      |
-               +---------------------------------------------------+
-
-This response contains the MX RR in the answer section of the response.
-The additional section contains the address RRs because the name server
-at C.ISI.EDU guesses that the requester will need the addresses in order
-to properly use the information carried by the MX.
-
-6.2.4. QNAME=SRI-NIC.ARPA, QTYPE=NS
-
-C.ISI.EDU would reply to this query with:
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
-               +---------------------------------------------------+
-    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=NS          |
-               +---------------------------------------------------+
-    Answer     | <empty>                                           |
-               +---------------------------------------------------+
-    Authority  | <empty>                                           |
-               +---------------------------------------------------+
-    Additional | <empty>                                           |
-               +---------------------------------------------------+
-
-The only difference between the response and the query is the AA and
-RESPONSE bits in the header.  The interpretation of this response is
-that the server is authoritative for the name, and the name exists, but
-no RRs of type NS are present there.
-
-6.2.5. QNAME=SIR-NIC.ARPA, QTYPE=A
-
-If a user mistyped a host name, we might see this type of query.
-
-
-
-Mockapetris                                                    [Page 43]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-C.ISI.EDU would answer it with:
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY, RESPONSE, AA, RCODE=NE             |
-               +---------------------------------------------------+
-    Question   | QNAME=SIR-NIC.ARPA., QCLASS=IN, QTYPE=A           |
-               +---------------------------------------------------+
-    Answer     | <empty>                                           |
-               +---------------------------------------------------+
-    Authority  | . SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA.      |
-               |       870611 1800 300 604800 86400                |
-               +---------------------------------------------------+
-    Additional | <empty>                                           |
-               +---------------------------------------------------+
-
-This response states that the name does not exist.  This condition is
-signalled in the response code (RCODE) section of the header.
-
-The SOA RR in the authority section is the optional negative caching
-information which allows the resolver using this response to assume that
-the name will not exist for the SOA MINIMUM (86400) seconds.
-
-6.2.6. QNAME=BRL.MIL, QTYPE=A
-
-If this query is sent to C.ISI.EDU, the reply would be:
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY, RESPONSE                           |
-               +---------------------------------------------------+
-    Question   | QNAME=BRL.MIL, QCLASS=IN, QTYPE=A                 |
-               +---------------------------------------------------+
-    Answer     | <empty>                                           |
-               +---------------------------------------------------+
-    Authority  | MIL.             86400 IN NS       SRI-NIC.ARPA.  |
-               |                  86400    NS       A.ISI.EDU.     |
-               +---------------------------------------------------+
-    Additional | A.ISI.EDU.                A        26.3.0.103     |
-               | SRI-NIC.ARPA.             A        26.0.0.73      |
-               |                           A        10.0.0.51      |
-               +---------------------------------------------------+
-
-This response has an empty answer section, but is not authoritative, so
-it is a referral.  The name server on C.ISI.EDU, realizing that it is
-not authoritative for the MIL domain, has referred the requester to
-servers on A.ISI.EDU and SRI-NIC.ARPA, which it knows are authoritative
-for the MIL domain.
-
-
-
-
-
-Mockapetris                                                    [Page 44]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-6.2.7. QNAME=USC-ISIC.ARPA, QTYPE=A
-
-The response to this query from A.ISI.EDU would be:
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
-               +---------------------------------------------------+
-    Question   | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A          |
-               +---------------------------------------------------+
-    Answer     | USC-ISIC.ARPA. 86400 IN CNAME      C.ISI.EDU.     |
-               | C.ISI.EDU.     86400 IN A          10.0.0.52      |
-               +---------------------------------------------------+
-    Authority  | <empty>                                           |
-               +---------------------------------------------------+
-    Additional | <empty>                                           |
-               +---------------------------------------------------+
-
-Note that the AA bit in the header guarantees that the data matching
-QNAME is authoritative, but does not say anything about whether the data
-for C.ISI.EDU is authoritative.  This complete reply is possible because
-A.ISI.EDU happens to be authoritative for both the ARPA domain where
-USC-ISIC.ARPA is found and the ISI.EDU domain where C.ISI.EDU data is
-found.
-
-If the same query was sent to C.ISI.EDU, its response might be the same
-as shown above if it had its own address in its cache, but might also
-be:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 45]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
-               +---------------------------------------------------+
-    Question   | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A          |
-               +---------------------------------------------------+
-    Answer     | USC-ISIC.ARPA.   86400 IN CNAME   C.ISI.EDU.      |
-               +---------------------------------------------------+
-    Authority  | ISI.EDU.        172800 IN NS      VAXA.ISI.EDU.   |
-               |                           NS      A.ISI.EDU.      |
-               |                           NS      VENERA.ISI.EDU. |
-               +---------------------------------------------------+
-    Additional | VAXA.ISI.EDU.   172800    A       10.2.0.27       |
-               |                 172800    A       128.9.0.33      |
-               | VENERA.ISI.EDU. 172800    A       10.1.0.52       |
-               |                 172800    A       128.9.0.32      |
-               | A.ISI.EDU.      172800    A       26.3.0.103      |
-               +---------------------------------------------------+
-
-This reply contains an authoritative reply for the alias USC-ISIC.ARPA,
-plus a referral to the name servers for ISI.EDU.  This sort of reply
-isn't very likely given that the query is for the host name of the name
-server being asked, but would be common for other aliases.
-
-6.2.8. QNAME=USC-ISIC.ARPA, QTYPE=CNAME
-
-If this query is sent to either A.ISI.EDU or C.ISI.EDU, the reply would
-be:
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
-               +---------------------------------------------------+
-    Question   | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A          |
-               +---------------------------------------------------+
-    Answer     | USC-ISIC.ARPA. 86400 IN CNAME      C.ISI.EDU.     |
-               +---------------------------------------------------+
-    Authority  | <empty>                                           |
-               +---------------------------------------------------+
-    Additional | <empty>                                           |
-               +---------------------------------------------------+
-
-Because QTYPE=CNAME, the CNAME RR itself answers the query, and the name
-server doesn't attempt to look up anything for C.ISI.EDU.  (Except
-possibly for the additional section.)
-
-6.3. Example resolution
-
-The following examples illustrate the operations a resolver must perform
-for its client.  We assume that the resolver is starting without a
-
-
-
-Mockapetris                                                    [Page 46]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-cache, as might be the case after system boot.  We further assume that
-the system is not one of the hosts in the data and that the host is
-located somewhere on net 26, and that its safety belt (SBELT) data
-structure has the following information:
-
-    Match count = -1
-    SRI-NIC.ARPA.   26.0.0.73       10.0.0.51
-    A.ISI.EDU.      26.3.0.103
-
-This information specifies servers to try, their addresses, and a match
-count of -1, which says that the servers aren't very close to the
-target.  Note that the -1 isn't supposed to be an accurate closeness
-measure, just a value so that later stages of the algorithm will work.
-
-The following examples illustrate the use of a cache, so each example
-assumes that previous requests have completed.
-
-6.3.1. Resolve MX for ISI.EDU.
-
-Suppose the first request to the resolver comes from the local mailer,
-which has mail for PVM@ISI.EDU.  The mailer might then ask for type MX
-RRs for the domain name ISI.EDU.
-
-The resolver would look in its cache for MX RRs at ISI.EDU, but the
-empty cache wouldn't be helpful.  The resolver would recognize that it
-needed to query foreign servers and try to determine the best servers to
-query.  This search would look for NS RRs for the domains ISI.EDU, EDU,
-and the root.  These searches of the cache would also fail.  As a last
-resort, the resolver would use the information from the SBELT, copying
-it into its SLIST structure.
-
-At this point the resolver would need to pick one of the three available
-addresses to try.  Given that the resolver is on net 26, it should
-choose either 26.0.0.73 or 26.3.0.103 as its first choice.  It would
-then send off a query of the form:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 47]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY                                     |
-               +---------------------------------------------------+
-    Question   | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX               |
-               +---------------------------------------------------+
-    Answer     | <empty>                                           |
-               +---------------------------------------------------+
-    Authority  | <empty>                                           |
-               +---------------------------------------------------+
-    Additional | <empty>                                           |
-               +---------------------------------------------------+
-
-The resolver would then wait for a response to its query or a timeout.
-If the timeout occurs, it would try different servers, then different
-addresses of the same servers, lastly retrying addresses already tried.
-It might eventually receive a reply from SRI-NIC.ARPA:
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY, RESPONSE                           |
-               +---------------------------------------------------+
-    Question   | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX               |
-               +---------------------------------------------------+
-    Answer     | <empty>                                           |
-               +---------------------------------------------------+
-    Authority  | ISI.EDU.        172800 IN NS       VAXA.ISI.EDU.  |
-               |                           NS       A.ISI.EDU.     |
-               |                           NS       VENERA.ISI.EDU.|
-               +---------------------------------------------------+
-    Additional | VAXA.ISI.EDU.   172800    A        10.2.0.27      |
-               |                 172800    A        128.9.0.33     |
-               | VENERA.ISI.EDU. 172800    A        10.1.0.52      |
-               |                 172800    A        128.9.0.32     |
-               | A.ISI.EDU.      172800    A        26.3.0.103     |
-               +---------------------------------------------------+
-
-The resolver would notice that the information in the response gave a
-closer delegation to ISI.EDU than its existing SLIST (since it matches
-three labels).  The resolver would then cache the information in this
-response and use it to set up a new SLIST:
-
-    Match count = 3
-    A.ISI.EDU.      26.3.0.103
-    VAXA.ISI.EDU.   10.2.0.27       128.9.0.33
-    VENERA.ISI.EDU. 10.1.0.52       128.9.0.32
-
-A.ISI.EDU appears on this list as well as the previous one, but that is
-purely coincidental.  The resolver would again start transmitting and
-waiting for responses.  Eventually it would get an answer:
-
-
-
-Mockapetris                                                    [Page 48]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
-               +---------------------------------------------------+
-    Question   | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX               |
-               +---------------------------------------------------+
-    Answer     | ISI.EDU.                MX 10 VENERA.ISI.EDU.     |
-               |                         MX 20 VAXA.ISI.EDU.       |
-               +---------------------------------------------------+
-    Authority  | <empty>                                           |
-               +---------------------------------------------------+
-    Additional | VAXA.ISI.EDU.   172800  A  10.2.0.27              |
-               |                 172800  A  128.9.0.33             |
-               | VENERA.ISI.EDU. 172800  A  10.1.0.52              |
-               |                 172800  A  128.9.0.32             |
-               +---------------------------------------------------+
-
-The resolver would add this information to its cache, and return the MX
-RRs to its client.
-
-6.3.2. Get the host name for address 26.6.0.65
-
-The resolver would translate this into a request for PTR RRs for
-65.0.6.26.IN-ADDR.ARPA.  This information is not in the cache, so the
-resolver would look for foreign servers to ask.  No servers would match,
-so it would use SBELT again.  (Note that the servers for the ISI.EDU
-domain are in the cache, but ISI.EDU is not an ancestor of
-65.0.6.26.IN-ADDR.ARPA, so the SBELT is used.)
-
-Since this request is within the authoritative data of both servers in
-SBELT, eventually one would return:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 49]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
-               +---------------------------------------------------+
-    Question   | QNAME=65.0.6.26.IN-ADDR.ARPA.,QCLASS=IN,QTYPE=PTR |
-               +---------------------------------------------------+
-    Answer     | 65.0.6.26.IN-ADDR.ARPA.    PTR     ACC.ARPA.      |
-               +---------------------------------------------------+
-    Authority  | <empty>                                           |
-               +---------------------------------------------------+
-    Additional | <empty>                                           |
-               +---------------------------------------------------+
-
-6.3.3. Get the host address of poneria.ISI.EDU
-
-This request would translate into a type A request for poneria.ISI.EDU.
-The resolver would not find any cached data for this name, but would
-find the NS RRs in the cache for ISI.EDU when it looks for foreign
-servers to ask.  Using this data, it would construct a SLIST of the
-form:
-
-    Match count = 3
-
-    A.ISI.EDU.      26.3.0.103
-    VAXA.ISI.EDU.   10.2.0.27       128.9.0.33
-    VENERA.ISI.EDU. 10.1.0.52
-
-A.ISI.EDU is listed first on the assumption that the resolver orders its
-choices by preference, and A.ISI.EDU is on the same network.
-
-One of these servers would answer the query.
-
-7. REFERENCES and BIBLIOGRAPHY
-
-[Dyer 87]       Dyer, S., and F. Hsu, "Hesiod", Project Athena
-                Technical Plan - Name Service, April 1987, version 1.9.
-
-                Describes the fundamentals of the Hesiod name service.
-
-[IEN-116]       J. Postel, "Internet Name Server", IEN-116,
-                USC/Information Sciences Institute, August 1979.
-
-                A name service obsoleted by the Domain Name System, but
-                still in use.
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 50]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-[Quarterman 86] Quarterman, J., and J. Hoskins, "Notable Computer
-                Networks",Communications of the ACM, October 1986,
-                volume 29, number 10.
-
-[RFC-742]       K. Harrenstien, "NAME/FINGER", RFC-742, Network
-                Information Center, SRI International, December 1977.
-
-[RFC-768]       J. Postel, "User Datagram Protocol", RFC-768,
-                USC/Information Sciences Institute, August 1980.
-
-[RFC-793]       J. Postel, "Transmission Control Protocol", RFC-793,
-                USC/Information Sciences Institute, September 1981.
-
-[RFC-799]       D. Mills, "Internet Name Domains", RFC-799, COMSAT,
-                September 1981.
-
-                Suggests introduction of a hierarchy in place of a flat
-                name space for the Internet.
-
-[RFC-805]       J. Postel, "Computer Mail Meeting Notes", RFC-805,
-                USC/Information Sciences Institute, February 1982.
-
-[RFC-810]       E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD
-                Internet Host Table Specification", RFC-810, Network
-                Information Center, SRI International, March 1982.
-
-                Obsolete.  See RFC-952.
-
-[RFC-811]       K. Harrenstien, V. White, and E. Feinler, "Hostnames
-                Server", RFC-811, Network Information Center, SRI
-                International, March 1982.
-
-                Obsolete.  See RFC-953.
-
-[RFC-812]       K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC-812,
-                Network Information Center, SRI International, March
-                1982.
-
-[RFC-819]       Z. Su, and J. Postel, "The Domain Naming Convention for
-                Internet User Applications", RFC-819, Network
-                Information Center, SRI International, August 1982.
-
-                Early thoughts on the design of the domain system.
-                Current implementation is completely different.
-
-[RFC-821]       J. Postel, "Simple Mail Transfer Protocol", RFC-821,
-                USC/Information Sciences Institute, August 1980.
-
-
-
-
-Mockapetris                                                    [Page 51]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-[RFC-830]       Z. Su, "A Distributed System for Internet Name Service",
-                RFC-830, Network Information Center, SRI International,
-                October 1982.
-
-                Early thoughts on the design of the domain system.
-                Current implementation is completely different.
-
-[RFC-882]       P. Mockapetris, "Domain names - Concepts and
-                Facilities," RFC-882, USC/Information Sciences
-                Institute, November 1983.
-
-                Superceeded by this memo.
-
-[RFC-883]       P. Mockapetris, "Domain names - Implementation and
-                Specification," RFC-883, USC/Information Sciences
-                Institute, November 1983.
-
-                Superceeded by this memo.
-
-[RFC-920]       J. Postel and J. Reynolds, "Domain Requirements",
-                RFC-920, USC/Information Sciences Institute
-                October 1984.
-
-                Explains the naming scheme for top level domains.
-
-[RFC-952]       K. Harrenstien, M. Stahl, E. Feinler, "DoD Internet Host
-                Table Specification", RFC-952, SRI, October 1985.
-
-                Specifies the format of HOSTS.TXT, the host/address
-                table replaced by the DNS.
-
-[RFC-953]       K. Harrenstien, M. Stahl, E. Feinler, "HOSTNAME Server",
-                RFC-953, SRI, October 1985.
-
-                This RFC contains the official specification of the
-                hostname server protocol, which is obsoleted by the DNS.
-                This TCP based protocol accesses information stored in
-                the RFC-952 format, and is used to obtain copies of the
-                host table.
-
-[RFC-973]       P. Mockapetris, "Domain System Changes and
-                Observations", RFC-973, USC/Information Sciences
-                Institute, January 1986.
-
-                Describes changes to RFC-882 and RFC-883 and reasons for
-                them.  Now obsolete.
-
-
-
-
-
-Mockapetris                                                    [Page 52]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-[RFC-974]       C. Partridge, "Mail routing and the domain system",
-                RFC-974, CSNET CIC BBN Labs, January 1986.
-
-                Describes the transition from HOSTS.TXT based mail
-                addressing to the more powerful MX system used with the
-                domain system.
-
-[RFC-1001]      NetBIOS Working Group, "Protocol standard for a NetBIOS
-                service on a TCP/UDP transport: Concepts and Methods",
-                RFC-1001, March 1987.
-
-                This RFC and RFC-1002 are a preliminary design for
-                NETBIOS on top of TCP/IP which proposes to base NetBIOS
-                name service on top of the DNS.
-
-[RFC-1002]      NetBIOS Working Group, "Protocol standard for a NetBIOS
-                service on a TCP/UDP transport: Detailed
-                Specifications", RFC-1002, March 1987.
-
-[RFC-1010]      J. Reynolds and J. Postel, "Assigned Numbers", RFC-1010,
-                USC/Information Sciences Institute, May 1987
-
-                Contains socket numbers and mnemonics for host names,
-                operating systems, etc.
-
-[RFC-1031]      W. Lazear, "MILNET Name Domain Transition", RFC-1031,
-                November 1987.
-
-                Describes a plan for converting the MILNET to the DNS.
-
-[RFC-1032]      M. K. Stahl, "Establishing a Domain - Guidelines for
-                Administrators", RFC-1032, November 1987.
-
-                Describes the registration policies used by the NIC to
-                administer the top level domains and delegate subzones.
-
-[RFC-1033]      M. K. Lottor, "Domain Administrators Operations Guide",
-                RFC-1033, November 1987.
-
-                A cookbook for domain administrators.
-
-[Solomon 82]    M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET
-                Name Server", Computer Networks, vol 6, nr 3, July 1982.
-
-                Describes a name service for CSNET which is independent
-                from the DNS and DNS use in the CSNET.
-
-
-
-
-
-Mockapetris                                                    [Page 53]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-Index
-
-          A   12
-          Absolute names   8
-          Aliases   14, 31
-          Authority   6
-          AXFR   17
-
-          Case of characters   7
-          CH   12
-          CNAME   12, 13, 31
-          Completion queries   18
-
-          Domain name   6, 7
-
-          Glue RRs   20
-
-          HINFO   12
-
-          IN   12
-          Inverse queries   16
-          Iterative   4
-
-          Label   7
-
-          Mailbox names   9
-          MX   12
-
-          Name error   27, 36
-          Name servers   5, 17
-          NE   30
-          Negative caching   44
-          NS   12
-
-          Opcode   16
-
-          PTR   12
-
-          QCLASS   16
-          QTYPE   16
-
-          RDATA   13
-          Recursive   4
-          Recursive service   22
-          Relative names   7
-          Resolvers   6
-          RR   12
-
-
-
-
-Mockapetris                                                    [Page 54]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-          Safety belt   33
-          Sections   16
-          SOA   12
-          Standard queries   22
-
-          Status queries   18
-          Stub resolvers   32
-
-          TTL   12, 13
-
-          Wildcards   25
-
-          Zone transfers   28
-          Zones   19
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 55]
-
diff --git a/contrib/bind9/doc/rfc/rfc1035.txt b/contrib/bind9/doc/rfc/rfc1035.txt
deleted file mode 100644
index b1a9bf5..0000000
--- a/contrib/bind9/doc/rfc/rfc1035.txt
+++ /dev/null
@@ -1,3077 +0,0 @@
-Network Working Group                                     P. Mockapetris
-Request for Comments: 1035                                           ISI
-                                                           November 1987
-Obsoletes: RFCs 882, 883, 973
-
-            DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
-
-
-1. STATUS OF THIS MEMO
-
-This RFC describes the details of the domain system and protocol, and
-assumes that the reader is familiar with the concepts discussed in a
-companion RFC, "Domain Names - Concepts and Facilities" [RFC-1034].
-
-The domain system is a mixture of functions and data types which are an
-official protocol and functions and data types which are still
-experimental.  Since the domain system is intentionally extensible, new
-data types and experimental behavior should always be expected in parts
-of the system beyond the official protocol.  The official protocol parts
-include standard queries, responses and the Internet class RR data
-formats (e.g., host addresses).  Since the previous RFC set, several
-definitions have changed, so some previous definitions are obsolete.
-
-Experimental or obsolete features are clearly marked in these RFCs, and
-such information should be used with caution.
-
-The reader is especially cautioned not to depend on the values which
-appear in examples to be current or complete, since their purpose is
-primarily pedagogical.  Distribution of this memo is unlimited.
-
-                           Table of Contents
-
-  1. STATUS OF THIS MEMO                                              1
-  2. INTRODUCTION                                                     3
-      2.1. Overview                                                   3
-      2.2. Common configurations                                      4
-      2.3. Conventions                                                7
-          2.3.1. Preferred name syntax                                7
-          2.3.2. Data Transmission Order                              8
-          2.3.3. Character Case                                       9
-          2.3.4. Size limits                                         10
-  3. DOMAIN NAME SPACE AND RR DEFINITIONS                            10
-      3.1. Name space definitions                                    10
-      3.2. RR definitions                                            11
-          3.2.1. Format                                              11
-          3.2.2. TYPE values                                         12
-          3.2.3. QTYPE values                                        12
-          3.2.4. CLASS values                                        13
-
-
-
-Mockapetris                                                     [Page 1]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-          3.2.5. QCLASS values                                       13
-      3.3. Standard RRs                                              13
-          3.3.1. CNAME RDATA format                                  14
-          3.3.2. HINFO RDATA format                                  14
-          3.3.3. MB RDATA format (EXPERIMENTAL)                      14
-          3.3.4. MD RDATA format (Obsolete)                          15
-          3.3.5. MF RDATA format (Obsolete)                          15
-          3.3.6. MG RDATA format (EXPERIMENTAL)                      16
-          3.3.7. MINFO RDATA format (EXPERIMENTAL)                   16
-          3.3.8. MR RDATA format (EXPERIMENTAL)                      17
-          3.3.9. MX RDATA format                                     17
-          3.3.10. NULL RDATA format (EXPERIMENTAL)                   17
-          3.3.11. NS RDATA format                                    18
-          3.3.12. PTR RDATA format                                   18
-          3.3.13. SOA RDATA format                                   19
-          3.3.14. TXT RDATA format                                   20
-      3.4. ARPA Internet specific RRs                                20
-          3.4.1. A RDATA format                                      20
-          3.4.2. WKS RDATA format                                    21
-      3.5. IN-ADDR.ARPA domain                                       22
-      3.6. Defining new types, classes, and special namespaces       24
-  4. MESSAGES                                                        25
-      4.1. Format                                                    25
-          4.1.1. Header section format                               26
-          4.1.2. Question section format                             28
-          4.1.3. Resource record format                              29
-          4.1.4. Message compression                                 30
-      4.2. Transport                                                 32
-          4.2.1. UDP usage                                           32
-          4.2.2. TCP usage                                           32
-  5. MASTER FILES                                                    33
-      5.1. Format                                                    33
-      5.2. Use of master files to define zones                       35
-      5.3. Master file example                                       36
-  6. NAME SERVER IMPLEMENTATION                                      37
-      6.1. Architecture                                              37
-          6.1.1. Control                                             37
-          6.1.2. Database                                            37
-          6.1.3. Time                                                39
-      6.2. Standard query processing                                 39
-      6.3. Zone refresh and reload processing                        39
-      6.4. Inverse queries (Optional)                                40
-          6.4.1. The contents of inverse queries and responses       40
-          6.4.2. Inverse query and response example                  41
-          6.4.3. Inverse query processing                            42
-
-
-
-
-
-
-Mockapetris                                                     [Page 2]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-      6.5. Completion queries and responses                          42
-  7. RESOLVER IMPLEMENTATION                                         43
-      7.1. Transforming a user request into a query                  43
-      7.2. Sending the queries                                       44
-      7.3. Processing responses                                      46
-      7.4. Using the cache                                           47
-  8. MAIL SUPPORT                                                    47
-      8.1. Mail exchange binding                                     48
-      8.2. Mailbox binding (Experimental)                            48
-  9. REFERENCES and BIBLIOGRAPHY                                     50
-  Index                                                              54
-
-2. INTRODUCTION
-
-2.1. Overview
-
-The goal of domain names is to provide a mechanism for naming resources
-in such a way that the names are usable in different hosts, networks,
-protocol families, internets, and administrative organizations.
-
-From the user's point of view, domain names are useful as arguments to a
-local agent, called a resolver, which retrieves information associated
-with the domain name.  Thus a user might ask for the host address or
-mail information associated with a particular domain name.  To enable
-the user to request a particular type of information, an appropriate
-query type is passed to the resolver with the domain name.  To the user,
-the domain tree is a single information space; the resolver is
-responsible for hiding the distribution of data among name servers from
-the user.
-
-From the resolver's point of view, the database that makes up the domain
-space is distributed among various name servers.  Different parts of the
-domain space are stored in different name servers, although a particular
-data item will be stored redundantly in two or more name servers.  The
-resolver starts with knowledge of at least one name server.  When the
-resolver processes a user query it asks a known name server for the
-information; in return, the resolver either receives the desired
-information or a referral to another name server.  Using these
-referrals, resolvers learn the identities and contents of other name
-servers.  Resolvers are responsible for dealing with the distribution of
-the domain space and dealing with the effects of name server failure by
-consulting redundant databases in other servers.
-
-Name servers manage two kinds of data.  The first kind of data held in
-sets called zones; each zone is the complete database for a particular
-"pruned" subtree of the domain space.  This data is called
-authoritative.  A name server periodically checks to make sure that its
-zones are up to date, and if not, obtains a new copy of updated zones
-
-
-
-Mockapetris                                                     [Page 3]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-from master files stored locally or in another name server.  The second
-kind of data is cached data which was acquired by a local resolver.
-This data may be incomplete, but improves the performance of the
-retrieval process when non-local data is repeatedly accessed.  Cached
-data is eventually discarded by a timeout mechanism.
-
-This functional structure isolates the problems of user interface,
-failure recovery, and distribution in the resolvers and isolates the
-database update and refresh problems in the name servers.
-
-2.2. Common configurations
-
-A host can participate in the domain name system in a number of ways,
-depending on whether the host runs programs that retrieve information
-from the domain system, name servers that answer queries from other
-hosts, or various combinations of both functions.  The simplest, and
-perhaps most typical, configuration is shown below:
-
-                 Local Host                        |  Foreign
-                                                   |
-    +---------+               +----------+         |  +--------+
-    |         | user queries  |          |queries  |  |        |
-    |  User   |-------------->|          |---------|->|Foreign |
-    | Program |               | Resolver |         |  |  Name  |
-    |         |<--------------|          |<--------|--| Server |
-    |         | user responses|          |responses|  |        |
-    +---------+               +----------+         |  +--------+
-                                |     A            |
-                cache additions |     | references |
-                                V     |            |
-                              +----------+         |
-                              |  cache   |         |
-                              +----------+         |
-
-User programs interact with the domain name space through resolvers; the
-format of user queries and user responses is specific to the host and
-its operating system.  User queries will typically be operating system
-calls, and the resolver and its cache will be part of the host operating
-system.  Less capable hosts may choose to implement the resolver as a
-subroutine to be linked in with every program that needs its services.
-Resolvers answer user queries with information they acquire via queries
-to foreign name servers and the local cache.
-
-Note that the resolver may have to make several queries to several
-different foreign name servers to answer a particular user query, and
-hence the resolution of a user query may involve several network
-accesses and an arbitrary amount of time.  The queries to foreign name
-servers and the corresponding responses have a standard format described
-
-
-
-Mockapetris                                                     [Page 4]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-in this memo, and may be datagrams.
-
-Depending on its capabilities, a name server could be a stand alone
-program on a dedicated machine or a process or processes on a large
-timeshared host.  A simple configuration might be:
-
-                 Local Host                        |  Foreign
-                                                   |
-      +---------+                                  |
-     /         /|                                  |
-    +---------+ |             +----------+         |  +--------+
-    |         | |             |          |responses|  |        |
-    |         | |             |   Name   |---------|->|Foreign |
-    |  Master |-------------->|  Server  |         |  |Resolver|
-    |  files  | |             |          |<--------|--|        |
-    |         |/              |          | queries |  +--------+
-    +---------+               +----------+         |
-
-Here a primary name server acquires information about one or more zones
-by reading master files from its local file system, and answers queries
-about those zones that arrive from foreign resolvers.
-
-The DNS requires that all zones be redundantly supported by more than
-one name server.  Designated secondary servers can acquire zones and
-check for updates from the primary server using the zone transfer
-protocol of the DNS.  This configuration is shown below:
-
-                 Local Host                        |  Foreign
-                                                   |
-      +---------+                                  |
-     /         /|                                  |
-    +---------+ |             +----------+         |  +--------+
-    |         | |             |          |responses|  |        |
-    |         | |             |   Name   |---------|->|Foreign |
-    |  Master |-------------->|  Server  |         |  |Resolver|
-    |  files  | |             |          |<--------|--|        |
-    |         |/              |          | queries |  +--------+
-    +---------+               +----------+         |
-                                A     |maintenance |  +--------+
-                                |     +------------|->|        |
-                                |      queries     |  |Foreign |
-                                |                  |  |  Name  |
-                                +------------------|--| Server |
-                             maintenance responses |  +--------+
-
-In this configuration, the name server periodically establishes a
-virtual circuit to a foreign name server to acquire a copy of a zone or
-to check that an existing copy has not changed.  The messages sent for
-
-
-
-Mockapetris                                                     [Page 5]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-these maintenance activities follow the same form as queries and
-responses, but the message sequences are somewhat different.
-
-The information flow in a host that supports all aspects of the domain
-name system is shown below:
-
-                 Local Host                        |  Foreign
-                                                   |
-    +---------+               +----------+         |  +--------+
-    |         | user queries  |          |queries  |  |        |
-    |  User   |-------------->|          |---------|->|Foreign |
-    | Program |               | Resolver |         |  |  Name  |
-    |         |<--------------|          |<--------|--| Server |
-    |         | user responses|          |responses|  |        |
-    +---------+               +----------+         |  +--------+
-                                |     A            |
-                cache additions |     | references |
-                                V     |            |
-                              +----------+         |
-                              |  Shared  |         |
-                              | database |         |
-                              +----------+         |
-                                A     |            |
-      +---------+     refreshes |     | references |
-     /         /|               |     V            |
-    +---------+ |             +----------+         |  +--------+
-    |         | |             |          |responses|  |        |
-    |         | |             |   Name   |---------|->|Foreign |
-    |  Master |-------------->|  Server  |         |  |Resolver|
-    |  files  | |             |          |<--------|--|        |
-    |         |/              |          | queries |  +--------+
-    +---------+               +----------+         |
-                                A     |maintenance |  +--------+
-                                |     +------------|->|        |
-                                |      queries     |  |Foreign |
-                                |                  |  |  Name  |
-                                +------------------|--| Server |
-                             maintenance responses |  +--------+
-
-The shared database holds domain space data for the local name server
-and resolver.  The contents of the shared database will typically be a
-mixture of authoritative data maintained by the periodic refresh
-operations of the name server and cached data from previous resolver
-requests.  The structure of the domain data and the necessity for
-synchronization between name servers and resolvers imply the general
-characteristics of this database, but the actual format is up to the
-local implementor.
-
-
-
-
-Mockapetris                                                     [Page 6]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-Information flow can also be tailored so that a group of hosts act
-together to optimize activities.  Sometimes this is done to offload less
-capable hosts so that they do not have to implement a full resolver.
-This can be appropriate for PCs or hosts which want to minimize the
-amount of new network code which is required.  This scheme can also
-allow a group of hosts can share a small number of caches rather than
-maintaining a large number of separate caches, on the premise that the
-centralized caches will have a higher hit ratio.  In either case,
-resolvers are replaced with stub resolvers which act as front ends to
-resolvers located in a recursive server in one or more name servers
-known to perform that service:
-
-                   Local Hosts                     |  Foreign
-                                                   |
-    +---------+                                    |
-    |         | responses                          |
-    | Stub    |<--------------------+              |
-    | Resolver|                     |              |
-    |         |----------------+    |              |
-    +---------+ recursive      |    |              |
-                queries        |    |              |
-                               V    |              |
-    +---------+ recursive     +----------+         |  +--------+
-    |         | queries       |          |queries  |  |        |
-    | Stub    |-------------->| Recursive|---------|->|Foreign |
-    | Resolver|               | Server   |         |  |  Name  |
-    |         |<--------------|          |<--------|--| Server |
-    +---------+ responses     |          |responses|  |        |
-                              +----------+         |  +--------+
-                              |  Central |         |
-                              |   cache  |         |
-                              +----------+         |
-
-In any case, note that domain components are always replicated for
-reliability whenever possible.
-
-2.3. Conventions
-
-The domain system has several conventions dealing with low-level, but
-fundamental, issues.  While the implementor is free to violate these
-conventions WITHIN HIS OWN SYSTEM, he must observe these conventions in
-ALL behavior observed from other hosts.
-
-2.3.1. Preferred name syntax
-
-The DNS specifications attempt to be as general as possible in the rules
-for constructing domain names.  The idea is that the name of any
-existing object can be expressed as a domain name with minimal changes.
-
-
-
-Mockapetris                                                     [Page 7]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-However, when assigning a domain name for an object, the prudent user
-will select a name which satisfies both the rules of the domain system
-and any existing rules for the object, whether these rules are published
-or implied by existing programs.
-
-For example, when naming a mail domain, the user should satisfy both the
-rules of this memo and those in RFC-822.  When creating a new host name,
-the old rules for HOSTS.TXT should be followed.  This avoids problems
-when old software is converted to use domain names.
-
-The following syntax will result in fewer problems with many
-
-applications that use domain names (e.g., mail, TELNET).
-
-<domain> ::= <subdomain> | " "
-
-<subdomain> ::= <label> | <subdomain> "." <label>
-
-<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
-
-<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
-
-<let-dig-hyp> ::= <let-dig> | "-"
-
-<let-dig> ::= <letter> | <digit>
-
-<letter> ::= any one of the 52 alphabetic characters A through Z in
-upper case and a through z in lower case
-
-<digit> ::= any one of the ten digits 0 through 9
-
-Note that while upper and lower case letters are allowed in domain
-names, no significance is attached to the case.  That is, two names with
-the same spelling but different case are to be treated as if identical.
-
-The labels must follow the rules for ARPANET host names.  They must
-start with a letter, end with a letter or digit, and have as interior
-characters only letters, digits, and hyphen.  There are also some
-restrictions on the length.  Labels must be 63 characters or less.
-
-For example, the following strings identify hosts in the Internet:
-
-A.ISI.EDU XX.LCS.MIT.EDU SRI-NIC.ARPA
-
-2.3.2. Data Transmission Order
-
-The order of transmission of the header and data described in this
-document is resolved to the octet level.  Whenever a diagram shows a
-
-
-
-Mockapetris                                                     [Page 8]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-group of octets, the order of transmission of those octets is the normal
-order in which they are read in English.  For example, in the following
-diagram, the octets are transmitted in the order they are numbered.
-
-     0                   1
-     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |       1       |       2       |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |       3       |       4       |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |       5       |       6       |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-Whenever an octet represents a numeric quantity, the left most bit in
-the diagram is the high order or most significant bit.  That is, the bit
-labeled 0 is the most significant bit.  For example, the following
-diagram represents the value 170 (decimal).
-
-     0 1 2 3 4 5 6 7
-    +-+-+-+-+-+-+-+-+
-    |1 0 1 0 1 0 1 0|
-    +-+-+-+-+-+-+-+-+
-
-Similarly, whenever a multi-octet field represents a numeric quantity
-the left most bit of the whole field is the most significant bit.  When
-a multi-octet quantity is transmitted the most significant octet is
-transmitted first.
-
-2.3.3. Character Case
-
-For all parts of the DNS that are part of the official protocol, all
-comparisons between character strings (e.g., labels, domain names, etc.)
-are done in a case-insensitive manner.  At present, this rule is in
-force throughout the domain system without exception.  However, future
-additions beyond current usage may need to use the full binary octet
-capabilities in names, so attempts to store domain names in 7-bit ASCII
-or use of special bytes to terminate labels, etc., should be avoided.
-
-When data enters the domain system, its original case should be
-preserved whenever possible.  In certain circumstances this cannot be
-done.  For example, if two RRs are stored in a database, one at x.y and
-one at X.Y, they are actually stored at the same place in the database,
-and hence only one casing would be preserved.  The basic rule is that
-case can be discarded only when data is used to define structure in a
-database, and two names are identical when compared in a case
-insensitive manner.
-
-
-
-
-Mockapetris                                                     [Page 9]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-Loss of case sensitive data must be minimized.  Thus while data for x.y
-and X.Y may both be stored under a single location x.y or X.Y, data for
-a.x and B.X would never be stored under A.x, A.X, b.x, or b.X.  In
-general, this preserves the case of the first label of a domain name,
-but forces standardization of interior node labels.
-
-Systems administrators who enter data into the domain database should
-take care to represent the data they supply to the domain system in a
-case-consistent manner if their system is case-sensitive.  The data
-distribution system in the domain system will ensure that consistent
-representations are preserved.
-
-2.3.4. Size limits
-
-Various objects and parameters in the DNS have size limits.  They are
-listed below.  Some could be easily changed, others are more
-fundamental.
-
-labels          63 octets or less
-
-names           255 octets or less
-
-TTL             positive values of a signed 32 bit number.
-
-UDP messages    512 octets or less
-
-3. DOMAIN NAME SPACE AND RR DEFINITIONS
-
-3.1. Name space definitions
-
-Domain names in messages are expressed in terms of a sequence of labels.
-Each label is represented as a one octet length field followed by that
-number of octets.  Since every domain name ends with the null label of
-the root, a domain name is terminated by a length byte of zero.  The
-high order two bits of every length octet must be zero, and the
-remaining six bits of the length field limit the label to 63 octets or
-less.
-
-To simplify implementations, the total length of a domain name (i.e.,
-label octets and label length octets) is restricted to 255 octets or
-less.
-
-Although labels can contain any 8 bit values in octets that make up a
-label, it is strongly recommended that labels follow the preferred
-syntax described elsewhere in this memo, which is compatible with
-existing host naming conventions.  Name servers and resolvers must
-compare labels in a case-insensitive manner (i.e., A=a), assuming ASCII
-with zero parity.  Non-alphabetic codes must match exactly.
-
-
-
-Mockapetris                                                    [Page 10]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-3.2. RR definitions
-
-3.2.1. Format
-
-All RRs have the same top level format shown below:
-
-                                    1  1  1  1  1  1
-      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                                               |
-    /                                               /
-    /                      NAME                     /
-    |                                               |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                      TYPE                     |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                     CLASS                     |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                      TTL                      |
-    |                                               |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                   RDLENGTH                    |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
-    /                     RDATA                     /
-    /                                               /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-
-where:
-
-NAME            an owner name, i.e., the name of the node to which this
-                resource record pertains.
-
-TYPE            two octets containing one of the RR TYPE codes.
-
-CLASS           two octets containing one of the RR CLASS codes.
-
-TTL             a 32 bit signed integer that specifies the time interval
-                that the resource record may be cached before the source
-                of the information should again be consulted.  Zero
-                values are interpreted to mean that the RR can only be
-                used for the transaction in progress, and should not be
-                cached.  For example, SOA records are always distributed
-                with a zero TTL to prohibit caching.  Zero values can
-                also be used for extremely volatile data.
-
-RDLENGTH        an unsigned 16 bit integer that specifies the length in
-                octets of the RDATA field.
-
-
-
-Mockapetris                                                    [Page 11]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-RDATA           a variable length string of octets that describes the
-                resource.  The format of this information varies
-                according to the TYPE and CLASS of the resource record.
-
-3.2.2. TYPE values
-
-TYPE fields are used in resource records.  Note that these types are a
-subset of QTYPEs.
-
-TYPE            value and meaning
-
-A               1 a host address
-
-NS              2 an authoritative name server
-
-MD              3 a mail destination (Obsolete - use MX)
-
-MF              4 a mail forwarder (Obsolete - use MX)
-
-CNAME           5 the canonical name for an alias
-
-SOA             6 marks the start of a zone of authority
-
-MB              7 a mailbox domain name (EXPERIMENTAL)
-
-MG              8 a mail group member (EXPERIMENTAL)
-
-MR              9 a mail rename domain name (EXPERIMENTAL)
-
-NULL            10 a null RR (EXPERIMENTAL)
-
-WKS             11 a well known service description
-
-PTR             12 a domain name pointer
-
-HINFO           13 host information
-
-MINFO           14 mailbox or mail list information
-
-MX              15 mail exchange
-
-TXT             16 text strings
-
-3.2.3. QTYPE values
-
-QTYPE fields appear in the question part of a query.  QTYPES are a
-superset of TYPEs, hence all TYPEs are valid QTYPEs.  In addition, the
-following QTYPEs are defined:
-
-
-
-Mockapetris                                                    [Page 12]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-AXFR            252 A request for a transfer of an entire zone
-
-MAILB           253 A request for mailbox-related records (MB, MG or MR)
-
-MAILA           254 A request for mail agent RRs (Obsolete - see MX)
-
-*               255 A request for all records
-
-3.2.4. CLASS values
-
-CLASS fields appear in resource records.  The following CLASS mnemonics
-and values are defined:
-
-IN              1 the Internet
-
-CS              2 the CSNET class (Obsolete - used only for examples in
-                some obsolete RFCs)
-
-CH              3 the CHAOS class
-
-HS              4 Hesiod [Dyer 87]
-
-3.2.5. QCLASS values
-
-QCLASS fields appear in the question section of a query.  QCLASS values
-are a superset of CLASS values; every CLASS is a valid QCLASS.  In
-addition to CLASS values, the following QCLASSes are defined:
-
-*               255 any class
-
-3.3. Standard RRs
-
-The following RR definitions are expected to occur, at least
-potentially, in all classes.  In particular, NS, SOA, CNAME, and PTR
-will be used in all classes, and have the same format in all classes.
-Because their RDATA format is known, all domain names in the RDATA
-section of these RRs may be compressed.
-
-<domain-name> is a domain name represented as a series of labels, and
-terminated by a label with zero length.  <character-string> is a single
-length octet followed by that number of characters.  <character-string>
-is treated as binary information, and can be up to 256 characters in
-length (including the length octet).
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 13]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-3.3.1. CNAME RDATA format
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                     CNAME                     /
-    /                                               /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-CNAME           A <domain-name> which specifies the canonical or primary
-                name for the owner.  The owner name is an alias.
-
-CNAME RRs cause no additional section processing, but name servers may
-choose to restart the query at the canonical name in certain cases.  See
-the description of name server logic in [RFC-1034] for details.
-
-3.3.2. HINFO RDATA format
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                      CPU                      /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                       OS                      /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-CPU             A <character-string> which specifies the CPU type.
-
-OS              A <character-string> which specifies the operating
-                system type.
-
-Standard values for CPU and OS can be found in [RFC-1010].
-
-HINFO records are used to acquire general information about a host.  The
-main use is for protocols such as FTP that can use special procedures
-when talking between machines or operating systems of the same type.
-
-3.3.3. MB RDATA format (EXPERIMENTAL)
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                   MADNAME                     /
-    /                                               /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-MADNAME         A <domain-name> which specifies a host which has the
-                specified mailbox.
-
-
-
-Mockapetris                                                    [Page 14]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-MB records cause additional section processing which looks up an A type
-RRs corresponding to MADNAME.
-
-3.3.4. MD RDATA format (Obsolete)
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                   MADNAME                     /
-    /                                               /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-MADNAME         A <domain-name> which specifies a host which has a mail
-                agent for the domain which should be able to deliver
-                mail for the domain.
-
-MD records cause additional section processing which looks up an A type
-record corresponding to MADNAME.
-
-MD is obsolete.  See the definition of MX and [RFC-974] for details of
-the new scheme.  The recommended policy for dealing with MD RRs found in
-a master file is to reject them, or to convert them to MX RRs with a
-preference of 0.
-
-3.3.5. MF RDATA format (Obsolete)
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                   MADNAME                     /
-    /                                               /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-MADNAME         A <domain-name> which specifies a host which has a mail
-                agent for the domain which will accept mail for
-                forwarding to the domain.
-
-MF records cause additional section processing which looks up an A type
-record corresponding to MADNAME.
-
-MF is obsolete.  See the definition of MX and [RFC-974] for details ofw
-the new scheme.  The recommended policy for dealing with MD RRs found in
-a master file is to reject them, or to convert them to MX RRs with a
-preference of 10.
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 15]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-3.3.6. MG RDATA format (EXPERIMENTAL)
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                   MGMNAME                     /
-    /                                               /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-MGMNAME         A <domain-name> which specifies a mailbox which is a
-                member of the mail group specified by the domain name.
-
-MG records cause no additional section processing.
-
-3.3.7. MINFO RDATA format (EXPERIMENTAL)
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                    RMAILBX                    /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                    EMAILBX                    /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-RMAILBX         A <domain-name> which specifies a mailbox which is
-                responsible for the mailing list or mailbox.  If this
-                domain name names the root, the owner of the MINFO RR is
-                responsible for itself.  Note that many existing mailing
-                lists use a mailbox X-request for the RMAILBX field of
-                mailing list X, e.g., Msgroup-request for Msgroup.  This
-                field provides a more general mechanism.
-
-
-EMAILBX         A <domain-name> which specifies a mailbox which is to
-                receive error messages related to the mailing list or
-                mailbox specified by the owner of the MINFO RR (similar
-                to the ERRORS-TO: field which has been proposed).  If
-                this domain name names the root, errors should be
-                returned to the sender of the message.
-
-MINFO records cause no additional section processing.  Although these
-records can be associated with a simple mailbox, they are usually used
-with a mailing list.
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 16]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-3.3.8. MR RDATA format (EXPERIMENTAL)
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                   NEWNAME                     /
-    /                                               /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-NEWNAME         A <domain-name> which specifies a mailbox which is the
-                proper rename of the specified mailbox.
-
-MR records cause no additional section processing.  The main use for MR
-is as a forwarding entry for a user who has moved to a different
-mailbox.
-
-3.3.9. MX RDATA format
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                  PREFERENCE                   |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                   EXCHANGE                    /
-    /                                               /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-PREFERENCE      A 16 bit integer which specifies the preference given to
-                this RR among others at the same owner.  Lower values
-                are preferred.
-
-EXCHANGE        A <domain-name> which specifies a host willing to act as
-                a mail exchange for the owner name.
-
-MX records cause type A additional section processing for the host
-specified by EXCHANGE.  The use of MX RRs is explained in detail in
-[RFC-974].
-
-3.3.10. NULL RDATA format (EXPERIMENTAL)
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                  <anything>                   /
-    /                                               /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-Anything at all may be in the RDATA field so long as it is 65535 octets
-or less.
-
-
-
-
-Mockapetris                                                    [Page 17]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-NULL records cause no additional section processing.  NULL RRs are not
-allowed in master files.  NULLs are used as placeholders in some
-experimental extensions of the DNS.
-
-3.3.11. NS RDATA format
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                   NSDNAME                     /
-    /                                               /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-NSDNAME         A <domain-name> which specifies a host which should be
-                authoritative for the specified class and domain.
-
-NS records cause both the usual additional section processing to locate
-a type A record, and, when used in a referral, a special search of the
-zone in which they reside for glue information.
-
-The NS RR states that the named host should be expected to have a zone
-starting at owner name of the specified class.  Note that the class may
-not indicate the protocol family which should be used to communicate
-with the host, although it is typically a strong hint.  For example,
-hosts which are name servers for either Internet (IN) or Hesiod (HS)
-class information are normally queried using IN class protocols.
-
-3.3.12. PTR RDATA format
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                   PTRDNAME                    /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-PTRDNAME        A <domain-name> which points to some location in the
-                domain name space.
-
-PTR records cause no additional section processing.  These RRs are used
-in special domains to point to some other location in the domain space.
-These records are simple data, and don't imply any special processing
-similar to that performed by CNAME, which identifies aliases.  See the
-description of the IN-ADDR.ARPA domain for an example.
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 18]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-3.3.13. SOA RDATA format
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                     MNAME                     /
-    /                                               /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                     RNAME                     /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                    SERIAL                     |
-    |                                               |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                    REFRESH                    |
-    |                                               |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                     RETRY                     |
-    |                                               |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                    EXPIRE                     |
-    |                                               |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                    MINIMUM                    |
-    |                                               |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-MNAME           The <domain-name> of the name server that was the
-                original or primary source of data for this zone.
-
-RNAME           A <domain-name> which specifies the mailbox of the
-                person responsible for this zone.
-
-SERIAL          The unsigned 32 bit version number of the original copy
-                of the zone.  Zone transfers preserve this value.  This
-                value wraps and should be compared using sequence space
-                arithmetic.
-
-REFRESH         A 32 bit time interval before the zone should be
-                refreshed.
-
-RETRY           A 32 bit time interval that should elapse before a
-                failed refresh should be retried.
-
-EXPIRE          A 32 bit time value that specifies the upper limit on
-                the time interval that can elapse before the zone is no
-                longer authoritative.
-
-
-
-
-
-Mockapetris                                                    [Page 19]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-MINIMUM         The unsigned 32 bit minimum TTL field that should be
-                exported with any RR from this zone.
-
-SOA records cause no additional section processing.
-
-All times are in units of seconds.
-
-Most of these fields are pertinent only for name server maintenance
-operations.  However, MINIMUM is used in all query operations that
-retrieve RRs from a zone.  Whenever a RR is sent in a response to a
-query, the TTL field is set to the maximum of the TTL field from the RR
-and the MINIMUM field in the appropriate SOA.  Thus MINIMUM is a lower
-bound on the TTL field for all RRs in a zone.  Note that this use of
-MINIMUM should occur when the RRs are copied into the response and not
-when the zone is loaded from a master file or via a zone transfer.  The
-reason for this provison is to allow future dynamic update facilities to
-change the SOA RR with known semantics.
-
-
-3.3.14. TXT RDATA format
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                   TXT-DATA                    /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-TXT-DATA        One or more <character-string>s.
-
-TXT RRs are used to hold descriptive text.  The semantics of the text
-depends on the domain where it is found.
-
-3.4. Internet specific RRs
-
-3.4.1. A RDATA format
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                    ADDRESS                    |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-ADDRESS         A 32 bit Internet address.
-
-Hosts that have multiple Internet addresses will have multiple A
-records.
-
-
-
-
-
-Mockapetris                                                    [Page 20]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-A records cause no additional section processing.  The RDATA section of
-an A line in a master file is an Internet address expressed as four
-decimal numbers separated by dots without any imbedded spaces (e.g.,
-"10.2.0.52" or "192.0.5.6").
-
-3.4.2. WKS RDATA format
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                    ADDRESS                    |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |       PROTOCOL        |                       |
-    +--+--+--+--+--+--+--+--+                       |
-    |                                               |
-    /                   <BIT MAP>                   /
-    /                                               /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-ADDRESS         An 32 bit Internet address
-
-PROTOCOL        An 8 bit IP protocol number
-
-<BIT MAP>       A variable length bit map.  The bit map must be a
-                multiple of 8 bits long.
-
-The WKS record is used to describe the well known services supported by
-a particular protocol on a particular internet address.  The PROTOCOL
-field specifies an IP protocol number, and the bit map has one bit per
-port of the specified protocol.  The first bit corresponds to port 0,
-the second to port 1, etc.  If the bit map does not include a bit for a
-protocol of interest, that bit is assumed zero.  The appropriate values
-and mnemonics for ports and protocols are specified in [RFC-1010].
-
-For example, if PROTOCOL=TCP (6), the 26th bit corresponds to TCP port
-25 (SMTP).  If this bit is set, a SMTP server should be listening on TCP
-port 25; if zero, SMTP service is not supported on the specified
-address.
-
-The purpose of WKS RRs is to provide availability information for
-servers for TCP and UDP.  If a server supports both TCP and UDP, or has
-multiple Internet addresses, then multiple WKS RRs are used.
-
-WKS RRs cause no additional section processing.
-
-In master files, both ports and protocols are expressed using mnemonics
-or decimal numbers.
-
-
-
-
-Mockapetris                                                    [Page 21]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-3.5. IN-ADDR.ARPA domain
-
-The Internet uses a special domain to support gateway location and
-Internet address to host mapping.  Other classes may employ a similar
-strategy in other domains.  The intent of this domain is to provide a
-guaranteed method to perform host address to host name mapping, and to
-facilitate queries to locate all gateways on a particular network in the
-Internet.
-
-Note that both of these services are similar to functions that could be
-performed by inverse queries; the difference is that this part of the
-domain name space is structured according to address, and hence can
-guarantee that the appropriate data can be located without an exhaustive
-search of the domain space.
-
-The domain begins at IN-ADDR.ARPA and has a substructure which follows
-the Internet addressing structure.
-
-Domain names in the IN-ADDR.ARPA domain are defined to have up to four
-labels in addition to the IN-ADDR.ARPA suffix.  Each label represents
-one octet of an Internet address, and is expressed as a character string
-for a decimal value in the range 0-255 (with leading zeros omitted
-except in the case of a zero octet which is represented by a single
-zero).
-
-Host addresses are represented by domain names that have all four labels
-specified.  Thus data for Internet address 10.2.0.52 is located at
-domain name 52.0.2.10.IN-ADDR.ARPA.  The reversal, though awkward to
-read, allows zones to be delegated which are exactly one network of
-address space.  For example, 10.IN-ADDR.ARPA can be a zone containing
-data for the ARPANET, while 26.IN-ADDR.ARPA can be a separate zone for
-MILNET.  Address nodes are used to hold pointers to primary host names
-in the normal domain space.
-
-Network numbers correspond to some non-terminal nodes at various depths
-in the IN-ADDR.ARPA domain, since Internet network numbers are either 1,
-2, or 3 octets.  Network nodes are used to hold pointers to the primary
-host names of gateways attached to that network.  Since a gateway is, by
-definition, on more than one network, it will typically have two or more
-network nodes which point at it.  Gateways will also have host level
-pointers at their fully qualified addresses.
-
-Both the gateway pointers at network nodes and the normal host pointers
-at full address nodes use the PTR RR to point back to the primary domain
-names of the corresponding hosts.
-
-For example, the IN-ADDR.ARPA domain will contain information about the
-ISI gateway between net 10 and 26, an MIT gateway from net 10 to MIT's
-
-
-
-Mockapetris                                                    [Page 22]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-net 18, and hosts A.ISI.EDU and MULTICS.MIT.EDU.  Assuming that ISI
-gateway has addresses 10.2.0.22 and 26.0.0.103, and a name MILNET-
-GW.ISI.EDU, and the MIT gateway has addresses 10.0.0.77 and 18.10.0.4
-and a name GW.LCS.MIT.EDU, the domain database would contain:
-
-    10.IN-ADDR.ARPA.           PTR MILNET-GW.ISI.EDU.
-    10.IN-ADDR.ARPA.           PTR GW.LCS.MIT.EDU.
-    18.IN-ADDR.ARPA.           PTR GW.LCS.MIT.EDU.
-    26.IN-ADDR.ARPA.           PTR MILNET-GW.ISI.EDU.
-    22.0.2.10.IN-ADDR.ARPA.    PTR MILNET-GW.ISI.EDU.
-    103.0.0.26.IN-ADDR.ARPA.   PTR MILNET-GW.ISI.EDU.
-    77.0.0.10.IN-ADDR.ARPA.    PTR GW.LCS.MIT.EDU.
-    4.0.10.18.IN-ADDR.ARPA.    PTR GW.LCS.MIT.EDU.
-    103.0.3.26.IN-ADDR.ARPA.   PTR A.ISI.EDU.
-    6.0.0.10.IN-ADDR.ARPA.     PTR MULTICS.MIT.EDU.
-
-Thus a program which wanted to locate gateways on net 10 would originate
-a query of the form QTYPE=PTR, QCLASS=IN, QNAME=10.IN-ADDR.ARPA.  It
-would receive two RRs in response:
-
-    10.IN-ADDR.ARPA.           PTR MILNET-GW.ISI.EDU.
-    10.IN-ADDR.ARPA.           PTR GW.LCS.MIT.EDU.
-
-The program could then originate QTYPE=A, QCLASS=IN queries for MILNET-
-GW.ISI.EDU. and GW.LCS.MIT.EDU. to discover the Internet addresses of
-these gateways.
-
-A resolver which wanted to find the host name corresponding to Internet
-host address 10.0.0.6 would pursue a query of the form QTYPE=PTR,
-QCLASS=IN, QNAME=6.0.0.10.IN-ADDR.ARPA, and would receive:
-
-    6.0.0.10.IN-ADDR.ARPA.     PTR MULTICS.MIT.EDU.
-
-Several cautions apply to the use of these services:
-   - Since the IN-ADDR.ARPA special domain and the normal domain
-     for a particular host or gateway will be in different zones,
-     the possibility exists that that the data may be inconsistent.
-
-   - Gateways will often have two names in separate domains, only
-     one of which can be primary.
-
-   - Systems that use the domain database to initialize their
-     routing tables must start with enough gateway information to
-     guarantee that they can access the appropriate name server.
-
-   - The gateway data only reflects the existence of a gateway in a
-     manner equivalent to the current HOSTS.TXT file.  It doesn't
-     replace the dynamic availability information from GGP or EGP.
-
-
-
-Mockapetris                                                    [Page 23]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-3.6. Defining new types, classes, and special namespaces
-
-The previously defined types and classes are the ones in use as of the
-date of this memo.  New definitions should be expected.  This section
-makes some recommendations to designers considering additions to the
-existing facilities.  The mailing list NAMEDROPPERS@SRI-NIC.ARPA is the
-forum where general discussion of design issues takes place.
-
-In general, a new type is appropriate when new information is to be
-added to the database about an existing object, or we need new data
-formats for some totally new object.  Designers should attempt to define
-types and their RDATA formats that are generally applicable to all
-classes, and which avoid duplication of information.  New classes are
-appropriate when the DNS is to be used for a new protocol, etc which
-requires new class-specific data formats, or when a copy of the existing
-name space is desired, but a separate management domain is necessary.
-
-New types and classes need mnemonics for master files; the format of the
-master files requires that the mnemonics for type and class be disjoint.
-
-TYPE and CLASS values must be a proper subset of QTYPEs and QCLASSes
-respectively.
-
-The present system uses multiple RRs to represent multiple values of a
-type rather than storing multiple values in the RDATA section of a
-single RR.  This is less efficient for most applications, but does keep
-RRs shorter.  The multiple RRs assumption is incorporated in some
-experimental work on dynamic update methods.
-
-The present system attempts to minimize the duplication of data in the
-database in order to insure consistency.  Thus, in order to find the
-address of the host for a mail exchange, you map the mail domain name to
-a host name, then the host name to addresses, rather than a direct
-mapping to host address.  This approach is preferred because it avoids
-the opportunity for inconsistency.
-
-In defining a new type of data, multiple RR types should not be used to
-create an ordering between entries or express different formats for
-equivalent bindings, instead this information should be carried in the
-body of the RR and a single type used.  This policy avoids problems with
-caching multiple types and defining QTYPEs to match multiple types.
-
-For example, the original form of mail exchange binding used two RR
-types one to represent a "closer" exchange (MD) and one to represent a
-"less close" exchange (MF).  The difficulty is that the presence of one
-RR type in a cache doesn't convey any information about the other
-because the query which acquired the cached information might have used
-a QTYPE of MF, MD, or MAILA (which matched both).  The redesigned
-
-
-
-Mockapetris                                                    [Page 24]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-service used a single type (MX) with a "preference" value in the RDATA
-section which can order different RRs.  However, if any MX RRs are found
-in the cache, then all should be there.
-
-4. MESSAGES
-
-4.1. Format
-
-All communications inside of the domain protocol are carried in a single
-format called a message.  The top level format of message is divided
-into 5 sections (some of which are empty in certain cases) shown below:
-
-    +---------------------+
-    |        Header       |
-    +---------------------+
-    |       Question      | the question for the name server
-    +---------------------+
-    |        Answer       | RRs answering the question
-    +---------------------+
-    |      Authority      | RRs pointing toward an authority
-    +---------------------+
-    |      Additional     | RRs holding additional information
-    +---------------------+
-
-The header section is always present.  The header includes fields that
-specify which of the remaining sections are present, and also specify
-whether the message is a query or a response, a standard query or some
-other opcode, etc.
-
-The names of the sections after the header are derived from their use in
-standard queries.  The question section contains fields that describe a
-question to a name server.  These fields are a query type (QTYPE), a
-query class (QCLASS), and a query domain name (QNAME).  The last three
-sections have the same format: a possibly empty list of concatenated
-resource records (RRs).  The answer section contains RRs that answer the
-question; the authority section contains RRs that point toward an
-authoritative name server; the additional records section contains RRs
-which relate to the query, but are not strictly answers for the
-question.
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 25]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-4.1.1. Header section format
-
-The header contains the following fields:
-
-                                    1  1  1  1  1  1
-      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                      ID                       |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |QR|   Opcode  |AA|TC|RD|RA|   Z    |   RCODE   |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                    QDCOUNT                    |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                    ANCOUNT                    |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                    NSCOUNT                    |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                    ARCOUNT                    |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-ID              A 16 bit identifier assigned by the program that
-                generates any kind of query.  This identifier is copied
-                the corresponding reply and can be used by the requester
-                to match up replies to outstanding queries.
-
-QR              A one bit field that specifies whether this message is a
-                query (0), or a response (1).
-
-OPCODE          A four bit field that specifies kind of query in this
-                message.  This value is set by the originator of a query
-                and copied into the response.  The values are:
-
-                0               a standard query (QUERY)
-
-                1               an inverse query (IQUERY)
-
-                2               a server status request (STATUS)
-
-                3-15            reserved for future use
-
-AA              Authoritative Answer - this bit is valid in responses,
-                and specifies that the responding name server is an
-                authority for the domain name in question section.
-
-                Note that the contents of the answer section may have
-                multiple owner names because of aliases.  The AA bit
-
-
-
-Mockapetris                                                    [Page 26]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-                corresponds to the name which matches the query name, or
-                the first owner name in the answer section.
-
-TC              TrunCation - specifies that this message was truncated
-                due to length greater than that permitted on the
-                transmission channel.
-
-RD              Recursion Desired - this bit may be set in a query and
-                is copied into the response.  If RD is set, it directs
-                the name server to pursue the query recursively.
-                Recursive query support is optional.
-
-RA              Recursion Available - this be is set or cleared in a
-                response, and denotes whether recursive query support is
-                available in the name server.
-
-Z               Reserved for future use.  Must be zero in all queries
-                and responses.
-
-RCODE           Response code - this 4 bit field is set as part of
-                responses.  The values have the following
-                interpretation:
-
-                0               No error condition
-
-                1               Format error - The name server was
-                                unable to interpret the query.
-
-                2               Server failure - The name server was
-                                unable to process this query due to a
-                                problem with the name server.
-
-                3               Name Error - Meaningful only for
-                                responses from an authoritative name
-                                server, this code signifies that the
-                                domain name referenced in the query does
-                                not exist.
-
-                4               Not Implemented - The name server does
-                                not support the requested kind of query.
-
-                5               Refused - The name server refuses to
-                                perform the specified operation for
-                                policy reasons.  For example, a name
-                                server may not wish to provide the
-                                information to the particular requester,
-                                or a name server may not wish to perform
-                                a particular operation (e.g., zone
-
-
-
-Mockapetris                                                    [Page 27]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-                                transfer) for particular data.
-
-                6-15            Reserved for future use.
-
-QDCOUNT         an unsigned 16 bit integer specifying the number of
-                entries in the question section.
-
-ANCOUNT         an unsigned 16 bit integer specifying the number of
-                resource records in the answer section.
-
-NSCOUNT         an unsigned 16 bit integer specifying the number of name
-                server resource records in the authority records
-                section.
-
-ARCOUNT         an unsigned 16 bit integer specifying the number of
-                resource records in the additional records section.
-
-4.1.2. Question section format
-
-The question section is used to carry the "question" in most queries,
-i.e., the parameters that define what is being asked.  The section
-contains QDCOUNT (usually 1) entries, each of the following format:
-
-                                    1  1  1  1  1  1
-      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                                               |
-    /                     QNAME                     /
-    /                                               /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                     QTYPE                     |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                     QCLASS                    |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-QNAME           a domain name represented as a sequence of labels, where
-                each label consists of a length octet followed by that
-                number of octets.  The domain name terminates with the
-                zero length octet for the null label of the root.  Note
-                that this field may be an odd number of octets; no
-                padding is used.
-
-QTYPE           a two octet code which specifies the type of the query.
-                The values for this field include all codes valid for a
-                TYPE field, together with some more general codes which
-                can match more than one type of RR.
-
-
-
-Mockapetris                                                    [Page 28]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-QCLASS          a two octet code that specifies the class of the query.
-                For example, the QCLASS field is IN for the Internet.
-
-4.1.3. Resource record format
-
-The answer, authority, and additional sections all share the same
-format: a variable number of resource records, where the number of
-records is specified in the corresponding count field in the header.
-Each resource record has the following format:
-                                    1  1  1  1  1  1
-      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                                               |
-    /                                               /
-    /                      NAME                     /
-    |                                               |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                      TYPE                     |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                     CLASS                     |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                      TTL                      |
-    |                                               |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                   RDLENGTH                    |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
-    /                     RDATA                     /
-    /                                               /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-NAME            a domain name to which this resource record pertains.
-
-TYPE            two octets containing one of the RR type codes.  This
-                field specifies the meaning of the data in the RDATA
-                field.
-
-CLASS           two octets which specify the class of the data in the
-                RDATA field.
-
-TTL             a 32 bit unsigned integer that specifies the time
-                interval (in seconds) that the resource record may be
-                cached before it should be discarded.  Zero values are
-                interpreted to mean that the RR can only be used for the
-                transaction in progress, and should not be cached.
-
-
-
-
-
-Mockapetris                                                    [Page 29]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-RDLENGTH        an unsigned 16 bit integer that specifies the length in
-                octets of the RDATA field.
-
-RDATA           a variable length string of octets that describes the
-                resource.  The format of this information varies
-                according to the TYPE and CLASS of the resource record.
-                For example, the if the TYPE is A and the CLASS is IN,
-                the RDATA field is a 4 octet ARPA Internet address.
-
-4.1.4. Message compression
-
-In order to reduce the size of messages, the domain system utilizes a
-compression scheme which eliminates the repetition of domain names in a
-message.  In this scheme, an entire domain name or a list of labels at
-the end of a domain name is replaced with a pointer to a prior occurance
-of the same name.
-
-The pointer takes the form of a two octet sequence:
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    | 1  1|                OFFSET                   |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-The first two bits are ones.  This allows a pointer to be distinguished
-from a label, since the label must begin with two zero bits because
-labels are restricted to 63 octets or less.  (The 10 and 01 combinations
-are reserved for future use.)  The OFFSET field specifies an offset from
-the start of the message (i.e., the first octet of the ID field in the
-domain header).  A zero offset specifies the first byte of the ID field,
-etc.
-
-The compression scheme allows a domain name in a message to be
-represented as either:
-
-   - a sequence of labels ending in a zero octet
-
-   - a pointer
-
-   - a sequence of labels ending with a pointer
-
-Pointers can only be used for occurances of a domain name where the
-format is not class specific.  If this were not the case, a name server
-or resolver would be required to know the format of all RRs it handled.
-As yet, there are no such cases, but they may occur in future RDATA
-formats.
-
-If a domain name is contained in a part of the message subject to a
-length field (such as the RDATA section of an RR), and compression is
-
-
-
-Mockapetris                                                    [Page 30]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-used, the length of the compressed name is used in the length
-calculation, rather than the length of the expanded name.
-
-Programs are free to avoid using pointers in messages they generate,
-although this will reduce datagram capacity, and may cause truncation.
-However all programs are required to understand arriving messages that
-contain pointers.
-
-For example, a datagram might need to use the domain names F.ISI.ARPA,
-FOO.F.ISI.ARPA, ARPA, and the root.  Ignoring the other fields of the
-message, these domain names might be represented as:
-
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    20 |           1           |           F           |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    22 |           3           |           I           |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    24 |           S           |           I           |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    26 |           4           |           A           |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    28 |           R           |           P           |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    30 |           A           |           0           |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    40 |           3           |           F           |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    42 |           O           |           O           |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    44 | 1  1|                20                       |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    64 | 1  1|                26                       |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    92 |           0           |                       |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-The domain name for F.ISI.ARPA is shown at offset 20.  The domain name
-FOO.F.ISI.ARPA is shown at offset 40; this definition uses a pointer to
-concatenate a label for FOO to the previously defined F.ISI.ARPA.  The
-domain name ARPA is defined at offset 64 using a pointer to the ARPA
-component of the name F.ISI.ARPA at 20; note that this pointer relies on
-ARPA being the last label in the string at 20.  The root domain name is
-
-
-
-Mockapetris                                                    [Page 31]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-defined by a single octet of zeros at 92; the root domain name has no
-labels.
-
-4.2. Transport
-
-The DNS assumes that messages will be transmitted as datagrams or in a
-byte stream carried by a virtual circuit.  While virtual circuits can be
-used for any DNS activity, datagrams are preferred for queries due to
-their lower overhead and better performance.  Zone refresh activities
-must use virtual circuits because of the need for reliable transfer.
-
-The Internet supports name server access using TCP [RFC-793] on server
-port 53 (decimal) as well as datagram access using UDP [RFC-768] on UDP
-port 53 (decimal).
-
-4.2.1. UDP usage
-
-Messages sent using UDP user server port 53 (decimal).
-
-Messages carried by UDP are restricted to 512 bytes (not counting the IP
-or UDP headers).  Longer messages are truncated and the TC bit is set in
-the header.
-
-UDP is not acceptable for zone transfers, but is the recommended method
-for standard queries in the Internet.  Queries sent using UDP may be
-lost, and hence a retransmission strategy is required.  Queries or their
-responses may be reordered by the network, or by processing in name
-servers, so resolvers should not depend on them being returned in order.
-
-The optimal UDP retransmission policy will vary with performance of the
-Internet and the needs of the client, but the following are recommended:
-
-   - The client should try other servers and server addresses
-     before repeating a query to a specific address of a server.
-
-   - The retransmission interval should be based on prior
-     statistics if possible.  Too aggressive retransmission can
-     easily slow responses for the community at large.  Depending
-     on how well connected the client is to its expected servers,
-     the minimum retransmission interval should be 2-5 seconds.
-
-More suggestions on server selection and retransmission policy can be
-found in the resolver section of this memo.
-
-4.2.2. TCP usage
-
-Messages sent over TCP connections use server port 53 (decimal).  The
-message is prefixed with a two byte length field which gives the message
-
-
-
-Mockapetris                                                    [Page 32]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-length, excluding the two byte length field.  This length field allows
-the low-level processing to assemble a complete message before beginning
-to parse it.
-
-Several connection management policies are recommended:
-
-   - The server should not block other activities waiting for TCP
-     data.
-
-   - The server should support multiple connections.
-
-   - The server should assume that the client will initiate
-     connection closing, and should delay closing its end of the
-     connection until all outstanding client requests have been
-     satisfied.
-
-   - If the server needs to close a dormant connection to reclaim
-     resources, it should wait until the connection has been idle
-     for a period on the order of two minutes.  In particular, the
-     server should allow the SOA and AXFR request sequence (which
-     begins a refresh operation) to be made on a single connection.
-     Since the server would be unable to answer queries anyway, a
-     unilateral close or reset may be used instead of a graceful
-     close.
-
-5. MASTER FILES
-
-Master files are text files that contain RRs in text form.  Since the
-contents of a zone can be expressed in the form of a list of RRs a
-master file is most often used to define a zone, though it can be used
-to list a cache's contents.  Hence, this section first discusses the
-format of RRs in a master file, and then the special considerations when
-a master file is used to create a zone in some name server.
-
-5.1. Format
-
-The format of these files is a sequence of entries.  Entries are
-predominantly line-oriented, though parentheses can be used to continue
-a list of items across a line boundary, and text literals can contain
-CRLF within the text.  Any combination of tabs and spaces act as a
-delimiter between the separate items that make up an entry.  The end of
-any line in the master file can end with a comment.  The comment starts
-with a ";" (semicolon).
-
-The following entries are defined:
-
-    <blank>[<comment>]
-
-
-
-
-Mockapetris                                                    [Page 33]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-    $ORIGIN <domain-name> [<comment>]
-
-    $INCLUDE <file-name> [<domain-name>] [<comment>]
-
-    <domain-name><rr> [<comment>]
-
-    <blank><rr> [<comment>]
-
-Blank lines, with or without comments, are allowed anywhere in the file.
-
-Two control entries are defined: $ORIGIN and $INCLUDE.  $ORIGIN is
-followed by a domain name, and resets the current origin for relative
-domain names to the stated name.  $INCLUDE inserts the named file into
-the current file, and may optionally specify a domain name that sets the
-relative domain name origin for the included file.  $INCLUDE may also
-have a comment.  Note that a $INCLUDE entry never changes the relative
-origin of the parent file, regardless of changes to the relative origin
-made within the included file.
-
-The last two forms represent RRs.  If an entry for an RR begins with a
-blank, then the RR is assumed to be owned by the last stated owner.  If
-an RR entry begins with a <domain-name>, then the owner name is reset.
-
-<rr> contents take one of the following forms:
-
-    [<TTL>] [<class>] <type> <RDATA>
-
-    [<class>] [<TTL>] <type> <RDATA>
-
-The RR begins with optional TTL and class fields, followed by a type and
-RDATA field appropriate to the type and class.  Class and type use the
-standard mnemonics, TTL is a decimal integer.  Omitted class and TTL
-values are default to the last explicitly stated values.  Since type and
-class mnemonics are disjoint, the parse is unique.  (Note that this
-order is different from the order used in examples and the order used in
-the actual RRs; the given order allows easier parsing and defaulting.)
-
-<domain-name>s make up a large share of the data in the master file.
-The labels in the domain name are expressed as character strings and
-separated by dots.  Quoting conventions allow arbitrary characters to be
-stored in domain names.  Domain names that end in a dot are called
-absolute, and are taken as complete.  Domain names which do not end in a
-dot are called relative; the actual domain name is the concatenation of
-the relative part with an origin specified in a $ORIGIN, $INCLUDE, or as
-an argument to the master file loading routine.  A relative name is an
-error when no origin is available.
-
-
-
-
-
-Mockapetris                                                    [Page 34]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-<character-string> is expressed in one or two ways: as a contiguous set
-of characters without interior spaces, or as a string beginning with a "
-and ending with a ".  Inside a " delimited string any character can
-occur, except for a " itself, which must be quoted using \ (back slash).
-
-Because these files are text files several special encodings are
-necessary to allow arbitrary data to be loaded.  In particular:
-
-                of the root.
-
-@               A free standing @ is used to denote the current origin.
-
-\X              where X is any character other than a digit (0-9), is
-                used to quote that character so that its special meaning
-                does not apply.  For example, "\." can be used to place
-                a dot character in a label.
-
-\DDD            where each D is a digit is the octet corresponding to
-                the decimal number described by DDD.  The resulting
-                octet is assumed to be text and is not checked for
-                special meaning.
-
-( )             Parentheses are used to group data that crosses a line
-                boundary.  In effect, line terminations are not
-                recognized within parentheses.
-
-;               Semicolon is used to start a comment; the remainder of
-                the line is ignored.
-
-5.2. Use of master files to define zones
-
-When a master file is used to load a zone, the operation should be
-suppressed if any errors are encountered in the master file.  The
-rationale for this is that a single error can have widespread
-consequences.  For example, suppose that the RRs defining a delegation
-have syntax errors; then the server will return authoritative name
-errors for all names in the subzone (except in the case where the
-subzone is also present on the server).
-
-Several other validity checks that should be performed in addition to
-insuring that the file is syntactically correct:
-
-   1. All RRs in the file should have the same class.
-
-   2. Exactly one SOA RR should be present at the top of the zone.
-
-   3. If delegations are present and glue information is required,
-      it should be present.
-
-
-
-Mockapetris                                                    [Page 35]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-   4. Information present outside of the authoritative nodes in the
-      zone should be glue information, rather than the result of an
-      origin or similar error.
-
-5.3. Master file example
-
-The following is an example file which might be used to define the
-ISI.EDU zone.and is loaded with an origin of ISI.EDU:
-
-@   IN  SOA     VENERA      Action\.domains (
-                                 20     ; SERIAL
-                                 7200   ; REFRESH
-                                 600    ; RETRY
-                                 3600000; EXPIRE
-                                 60)    ; MINIMUM
-
-        NS      A.ISI.EDU.
-        NS      VENERA
-        NS      VAXA
-        MX      10      VENERA
-        MX      20      VAXA
-
-A       A       26.3.0.103
-
-VENERA  A       10.1.0.52
-        A       128.9.0.32
-
-VAXA    A       10.2.0.27
-        A       128.9.0.33
-
-
-$INCLUDE <SUBSYS>ISI-MAILBOXES.TXT
-
-Where the file <SUBSYS>ISI-MAILBOXES.TXT is:
-
-    MOE     MB      A.ISI.EDU.
-    LARRY   MB      A.ISI.EDU.
-    CURLEY  MB      A.ISI.EDU.
-    STOOGES MG      MOE
-            MG      LARRY
-            MG      CURLEY
-
-Note the use of the \ character in the SOA RR to specify the responsible
-person mailbox "Action.domains@E.ISI.EDU".
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 36]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-6. NAME SERVER IMPLEMENTATION
-
-6.1. Architecture
-
-The optimal structure for the name server will depend on the host
-operating system and whether the name server is integrated with resolver
-operations, either by supporting recursive service, or by sharing its
-database with a resolver.  This section discusses implementation
-considerations for a name server which shares a database with a
-resolver, but most of these concerns are present in any name server.
-
-6.1.1. Control
-
-A name server must employ multiple concurrent activities, whether they
-are implemented as separate tasks in the host's OS or multiplexing
-inside a single name server program.  It is simply not acceptable for a
-name server to block the service of UDP requests while it waits for TCP
-data for refreshing or query activities.  Similarly, a name server
-should not attempt to provide recursive service without processing such
-requests in parallel, though it may choose to serialize requests from a
-single client, or to regard identical requests from the same client as
-duplicates.  A name server should not substantially delay requests while
-it reloads a zone from master files or while it incorporates a newly
-refreshed zone into its database.
-
-6.1.2. Database
-
-While name server implementations are free to use any internal data
-structures they choose, the suggested structure consists of three major
-parts:
-
-   - A "catalog" data structure which lists the zones available to
-     this server, and a "pointer" to the zone data structure.  The
-     main purpose of this structure is to find the nearest ancestor
-     zone, if any, for arriving standard queries.
-
-   - Separate data structures for each of the zones held by the
-     name server.
-
-   - A data structure for cached data. (or perhaps separate caches
-     for different classes)
-
-All of these data structures can be implemented an identical tree
-structure format, with different data chained off the nodes in different
-parts: in the catalog the data is pointers to zones, while in the zone
-and cache data structures, the data will be RRs.  In designing the tree
-framework the designer should recognize that query processing will need
-to traverse the tree using case-insensitive label comparisons; and that
-
-
-
-Mockapetris                                                    [Page 37]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-in real data, a few nodes have a very high branching factor (100-1000 or
-more), but the vast majority have a very low branching factor (0-1).
-
-One way to solve the case problem is to store the labels for each node
-in two pieces: a standardized-case representation of the label where all
-ASCII characters are in a single case, together with a bit mask that
-denotes which characters are actually of a different case.  The
-branching factor diversity can be handled using a simple linked list for
-a node until the branching factor exceeds some threshold, and
-transitioning to a hash structure after the threshold is exceeded.  In
-any case, hash structures used to store tree sections must insure that
-hash functions and procedures preserve the casing conventions of the
-DNS.
-
-The use of separate structures for the different parts of the database
-is motivated by several factors:
-
-   - The catalog structure can be an almost static structure that
-     need change only when the system administrator changes the
-     zones supported by the server.  This structure can also be
-     used to store parameters used to control refreshing
-     activities.
-
-   - The individual data structures for zones allow a zone to be
-     replaced simply by changing a pointer in the catalog.  Zone
-     refresh operations can build a new structure and, when
-     complete, splice it into the database via a simple pointer
-     replacement.  It is very important that when a zone is
-     refreshed, queries should not use old and new data
-     simultaneously.
-
-   - With the proper search procedures, authoritative data in zones
-     will always "hide", and hence take precedence over, cached
-     data.
-
-   - Errors in zone definitions that cause overlapping zones, etc.,
-     may cause erroneous responses to queries, but problem
-     determination is simplified, and the contents of one "bad"
-     zone can't corrupt another.
-
-   - Since the cache is most frequently updated, it is most
-     vulnerable to corruption during system restarts.  It can also
-     become full of expired RR data.  In either case, it can easily
-     be discarded without disturbing zone data.
-
-A major aspect of database design is selecting a structure which allows
-the name server to deal with crashes of the name server's host.  State
-information which a name server should save across system crashes
-
-
-
-Mockapetris                                                    [Page 38]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-includes the catalog structure (including the state of refreshing for
-each zone) and the zone data itself.
-
-6.1.3. Time
-
-Both the TTL data for RRs and the timing data for refreshing activities
-depends on 32 bit timers in units of seconds.  Inside the database,
-refresh timers and TTLs for cached data conceptually "count down", while
-data in the zone stays with constant TTLs.
-
-A recommended implementation strategy is to store time in two ways:  as
-a relative increment and as an absolute time.  One way to do this is to
-use positive 32 bit numbers for one type and negative numbers for the
-other.  The RRs in zones use relative times; the refresh timers and
-cache data use absolute times.  Absolute numbers are taken with respect
-to some known origin and converted to relative values when placed in the
-response to a query.  When an absolute TTL is negative after conversion
-to relative, then the data is expired and should be ignored.
-
-6.2. Standard query processing
-
-The major algorithm for standard query processing is presented in
-[RFC-1034].
-
-When processing queries with QCLASS=*, or some other QCLASS which
-matches multiple classes, the response should never be authoritative
-unless the server can guarantee that the response covers all classes.
-
-When composing a response, RRs which are to be inserted in the
-additional section, but duplicate RRs in the answer or authority
-sections, may be omitted from the additional section.
-
-When a response is so long that truncation is required, the truncation
-should start at the end of the response and work forward in the
-datagram.  Thus if there is any data for the authority section, the
-answer section is guaranteed to be unique.
-
-The MINIMUM value in the SOA should be used to set a floor on the TTL of
-data distributed from a zone.  This floor function should be done when
-the data is copied into a response.  This will allow future dynamic
-update protocols to change the SOA MINIMUM field without ambiguous
-semantics.
-
-6.3. Zone refresh and reload processing
-
-In spite of a server's best efforts, it may be unable to load zone data
-from a master file due to syntax errors, etc., or be unable to refresh a
-zone within the its expiration parameter.  In this case, the name server
-
-
-
-Mockapetris                                                    [Page 39]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-should answer queries as if it were not supposed to possess the zone.
-
-If a master is sending a zone out via AXFR, and a new version is created
-during the transfer, the master should continue to send the old version
-if possible.  In any case, it should never send part of one version and
-part of another.  If completion is not possible, the master should reset
-the connection on which the zone transfer is taking place.
-
-6.4. Inverse queries (Optional)
-
-Inverse queries are an optional part of the DNS.  Name servers are not
-required to support any form of inverse queries.  If a name server
-receives an inverse query that it does not support, it returns an error
-response with the "Not Implemented" error set in the header.  While
-inverse query support is optional, all name servers must be at least
-able to return the error response.
-
-6.4.1. The contents of inverse queries and responses          Inverse
-queries reverse the mappings performed by standard query operations;
-while a standard query maps a domain name to a resource, an inverse
-query maps a resource to a domain name.  For example, a standard query
-might bind a domain name to a host address; the corresponding inverse
-query binds the host address to a domain name.
-
-Inverse queries take the form of a single RR in the answer section of
-the message, with an empty question section.  The owner name of the
-query RR and its TTL are not significant.  The response carries
-questions in the question section which identify all names possessing
-the query RR WHICH THE NAME SERVER KNOWS.  Since no name server knows
-about all of the domain name space, the response can never be assumed to
-be complete.  Thus inverse queries are primarily useful for database
-management and debugging activities.  Inverse queries are NOT an
-acceptable method of mapping host addresses to host names; use the IN-
-ADDR.ARPA domain instead.
-
-Where possible, name servers should provide case-insensitive comparisons
-for inverse queries.  Thus an inverse query asking for an MX RR of
-"Venera.isi.edu" should get the same response as a query for
-"VENERA.ISI.EDU"; an inverse query for HINFO RR "IBM-PC UNIX" should
-produce the same result as an inverse query for "IBM-pc unix".  However,
-this cannot be guaranteed because name servers may possess RRs that
-contain character strings but the name server does not know that the
-data is character.
-
-When a name server processes an inverse query, it either returns:
-
-   1. zero, one, or multiple domain names for the specified
-      resource as QNAMEs in the question section
-
-
-
-Mockapetris                                                    [Page 40]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-   2. an error code indicating that the name server doesn't support
-      inverse mapping of the specified resource type.
-
-When the response to an inverse query contains one or more QNAMEs, the
-owner name and TTL of the RR in the answer section which defines the
-inverse query is modified to exactly match an RR found at the first
-QNAME.
-
-RRs returned in the inverse queries cannot be cached using the same
-mechanism as is used for the replies to standard queries.  One reason
-for this is that a name might have multiple RRs of the same type, and
-only one would appear.  For example, an inverse query for a single
-address of a multiply homed host might create the impression that only
-one address existed.
-
-6.4.2. Inverse query and response example          The overall structure
-of an inverse query for retrieving the domain name that corresponds to
-Internet address 10.1.0.52 is shown below:
-
-                         +-----------------------------------------+
-           Header        |          OPCODE=IQUERY, ID=997          |
-                         +-----------------------------------------+
-          Question       |                 <empty>                 |
-                         +-----------------------------------------+
-           Answer        |        <anyname> A IN 10.1.0.52         |
-                         +-----------------------------------------+
-          Authority      |                 <empty>                 |
-                         +-----------------------------------------+
-         Additional      |                 <empty>                 |
-                         +-----------------------------------------+
-
-This query asks for a question whose answer is the Internet style
-address 10.1.0.52.  Since the owner name is not known, any domain name
-can be used as a placeholder (and is ignored).  A single octet of zero,
-signifying the root, is usually used because it minimizes the length of
-the message.  The TTL of the RR is not significant.  The response to
-this query might be:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 41]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-                         +-----------------------------------------+
-           Header        |         OPCODE=RESPONSE, ID=997         |
-                         +-----------------------------------------+
-          Question       |QTYPE=A, QCLASS=IN, QNAME=VENERA.ISI.EDU |
-                         +-----------------------------------------+
-           Answer        |  VENERA.ISI.EDU  A IN 10.1.0.52         |
-                         +-----------------------------------------+
-          Authority      |                 <empty>                 |
-                         +-----------------------------------------+
-         Additional      |                 <empty>                 |
-                         +-----------------------------------------+
-
-Note that the QTYPE in a response to an inverse query is the same as the
-TYPE field in the answer section of the inverse query.  Responses to
-inverse queries may contain multiple questions when the inverse is not
-unique.  If the question section in the response is not empty, then the
-RR in the answer section is modified to correspond to be an exact copy
-of an RR at the first QNAME.
-
-6.4.3. Inverse query processing
-
-Name servers that support inverse queries can support these operations
-through exhaustive searches of their databases, but this becomes
-impractical as the size of the database increases.  An alternative
-approach is to invert the database according to the search key.
-
-For name servers that support multiple zones and a large amount of data,
-the recommended approach is separate inversions for each zone.  When a
-particular zone is changed during a refresh, only its inversions need to
-be redone.
-
-Support for transfer of this type of inversion may be included in future
-versions of the domain system, but is not supported in this version.
-
-6.5. Completion queries and responses
-
-The optional completion services described in RFC-882 and RFC-883 have
-been deleted.  Redesigned services may become available in the future.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 42]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-7. RESOLVER IMPLEMENTATION
-
-The top levels of the recommended resolver algorithm are discussed in
-[RFC-1034].  This section discusses implementation details assuming the
-database structure suggested in the name server implementation section
-of this memo.
-
-7.1. Transforming a user request into a query
-
-The first step a resolver takes is to transform the client's request,
-stated in a format suitable to the local OS, into a search specification
-for RRs at a specific name which match a specific QTYPE and QCLASS.
-Where possible, the QTYPE and QCLASS should correspond to a single type
-and a single class, because this makes the use of cached data much
-simpler.  The reason for this is that the presence of data of one type
-in a cache doesn't confirm the existence or non-existence of data of
-other types, hence the only way to be sure is to consult an
-authoritative source.  If QCLASS=* is used, then authoritative answers
-won't be available.
-
-Since a resolver must be able to multiplex multiple requests if it is to
-perform its function efficiently, each pending request is usually
-represented in some block of state information.  This state block will
-typically contain:
-
-   - A timestamp indicating the time the request began.
-     The timestamp is used to decide whether RRs in the database
-     can be used or are out of date.  This timestamp uses the
-     absolute time format previously discussed for RR storage in
-     zones and caches.  Note that when an RRs TTL indicates a
-     relative time, the RR must be timely, since it is part of a
-     zone.  When the RR has an absolute time, it is part of a
-     cache, and the TTL of the RR is compared against the timestamp
-     for the start of the request.
-
-     Note that using the timestamp is superior to using a current
-     time, since it allows RRs with TTLs of zero to be entered in
-     the cache in the usual manner, but still used by the current
-     request, even after intervals of many seconds due to system
-     load, query retransmission timeouts, etc.
-
-   - Some sort of parameters to limit the amount of work which will
-     be performed for this request.
-
-     The amount of work which a resolver will do in response to a
-     client request must be limited to guard against errors in the
-     database, such as circular CNAME references, and operational
-     problems, such as network partition which prevents the
-
-
-
-Mockapetris                                                    [Page 43]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-     resolver from accessing the name servers it needs.  While
-     local limits on the number of times a resolver will retransmit
-     a particular query to a particular name server address are
-     essential, the resolver should have a global per-request
-     counter to limit work on a single request.  The counter should
-     be set to some initial value and decremented whenever the
-     resolver performs any action (retransmission timeout,
-     retransmission, etc.)  If the counter passes zero, the request
-     is terminated with a temporary error.
-
-     Note that if the resolver structure allows one request to
-     start others in parallel, such as when the need to access a
-     name server for one request causes a parallel resolve for the
-     name server's addresses, the spawned request should be started
-     with a lower counter.  This prevents circular references in
-     the database from starting a chain reaction of resolver
-     activity.
-
-   - The SLIST data structure discussed in [RFC-1034].
-
-     This structure keeps track of the state of a request if it
-     must wait for answers from foreign name servers.
-
-7.2. Sending the queries
-
-As described in [RFC-1034], the basic task of the resolver is to
-formulate a query which will answer the client's request and direct that
-query to name servers which can provide the information.  The resolver
-will usually only have very strong hints about which servers to ask, in
-the form of NS RRs, and may have to revise the query, in response to
-CNAMEs, or revise the set of name servers the resolver is asking, in
-response to delegation responses which point the resolver to name
-servers closer to the desired information.  In addition to the
-information requested by the client, the resolver may have to call upon
-its own services to determine the address of name servers it wishes to
-contact.
-
-In any case, the model used in this memo assumes that the resolver is
-multiplexing attention between multiple requests, some from the client,
-and some internally generated.  Each request is represented by some
-state information, and the desired behavior is that the resolver
-transmit queries to name servers in a way that maximizes the probability
-that the request is answered, minimizes the time that the request takes,
-and avoids excessive transmissions.  The key algorithm uses the state
-information of the request to select the next name server address to
-query, and also computes a timeout which will cause the next action
-should a response not arrive.  The next action will usually be a
-transmission to some other server, but may be a temporary error to the
-
-
-
-Mockapetris                                                    [Page 44]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-client.
-
-The resolver always starts with a list of server names to query (SLIST).
-This list will be all NS RRs which correspond to the nearest ancestor
-zone that the resolver knows about.  To avoid startup problems, the
-resolver should have a set of default servers which it will ask should
-it have no current NS RRs which are appropriate.  The resolver then adds
-to SLIST all of the known addresses for the name servers, and may start
-parallel requests to acquire the addresses of the servers when the
-resolver has the name, but no addresses, for the name servers.
-
-To complete initialization of SLIST, the resolver attaches whatever
-history information it has to the each address in SLIST.  This will
-usually consist of some sort of weighted averages for the response time
-of the address, and the batting average of the address (i.e., how often
-the address responded at all to the request).  Note that this
-information should be kept on a per address basis, rather than on a per
-name server basis, because the response time and batting average of a
-particular server may vary considerably from address to address.  Note
-also that this information is actually specific to a resolver address /
-server address pair, so a resolver with multiple addresses may wish to
-keep separate histories for each of its addresses.  Part of this step
-must deal with addresses which have no such history; in this case an
-expected round trip time of 5-10 seconds should be the worst case, with
-lower estimates for the same local network, etc.
-
-Note that whenever a delegation is followed, the resolver algorithm
-reinitializes SLIST.
-
-The information establishes a partial ranking of the available name
-server addresses.  Each time an address is chosen and the state should
-be altered to prevent its selection again until all other addresses have
-been tried.  The timeout for each transmission should be 50-100% greater
-than the average predicted value to allow for variance in response.
-
-Some fine points:
-
-   - The resolver may encounter a situation where no addresses are
-     available for any of the name servers named in SLIST, and
-     where the servers in the list are precisely those which would
-     normally be used to look up their own addresses.  This
-     situation typically occurs when the glue address RRs have a
-     smaller TTL than the NS RRs marking delegation, or when the
-     resolver caches the result of a NS search.  The resolver
-     should detect this condition and restart the search at the
-     next ancestor zone, or alternatively at the root.
-
-
-
-
-
-Mockapetris                                                    [Page 45]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-   - If a resolver gets a server error or other bizarre response
-     from a name server, it should remove it from SLIST, and may
-     wish to schedule an immediate transmission to the next
-     candidate server address.
-
-7.3. Processing responses
-
-The first step in processing arriving response datagrams is to parse the
-response.  This procedure should include:
-
-   - Check the header for reasonableness.  Discard datagrams which
-     are queries when responses are expected.
-
-   - Parse the sections of the message, and insure that all RRs are
-     correctly formatted.
-
-   - As an optional step, check the TTLs of arriving data looking
-     for RRs with excessively long TTLs.  If a RR has an
-     excessively long TTL, say greater than 1 week, either discard
-     the whole response, or limit all TTLs in the response to 1
-     week.
-
-The next step is to match the response to a current resolver request.
-The recommended strategy is to do a preliminary matching using the ID
-field in the domain header, and then to verify that the question section
-corresponds to the information currently desired.  This requires that
-the transmission algorithm devote several bits of the domain ID field to
-a request identifier of some sort.  This step has several fine points:
-
-   - Some name servers send their responses from different
-     addresses than the one used to receive the query.  That is, a
-     resolver cannot rely that a response will come from the same
-     address which it sent the corresponding query to.  This name
-     server bug is typically encountered in UNIX systems.
-
-   - If the resolver retransmits a particular request to a name
-     server it should be able to use a response from any of the
-     transmissions.  However, if it is using the response to sample
-     the round trip time to access the name server, it must be able
-     to determine which transmission matches the response (and keep
-     transmission times for each outgoing message), or only
-     calculate round trip times based on initial transmissions.
-
-   - A name server will occasionally not have a current copy of a
-     zone which it should have according to some NS RRs.  The
-     resolver should simply remove the name server from the current
-     SLIST, and continue.
-
-
-
-
-Mockapetris                                                    [Page 46]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-7.4. Using the cache
-
-In general, we expect a resolver to cache all data which it receives in
-responses since it may be useful in answering future client requests.
-However, there are several types of data which should not be cached:
-
-   - When several RRs of the same type are available for a
-     particular owner name, the resolver should either cache them
-     all or none at all.  When a response is truncated, and a
-     resolver doesn't know whether it has a complete set, it should
-     not cache a possibly partial set of RRs.
-
-   - Cached data should never be used in preference to
-     authoritative data, so if caching would cause this to happen
-     the data should not be cached.
-
-   - The results of an inverse query should not be cached.
-
-   - The results of standard queries where the QNAME contains "*"
-     labels if the data might be used to construct wildcards.  The
-     reason is that the cache does not necessarily contain existing
-     RRs or zone boundary information which is necessary to
-     restrict the application of the wildcard RRs.
-
-   - RR data in responses of dubious reliability.  When a resolver
-     receives unsolicited responses or RR data other than that
-     requested, it should discard it without caching it.  The basic
-     implication is that all sanity checks on a packet should be
-     performed before any of it is cached.
-
-In a similar vein, when a resolver has a set of RRs for some name in a
-response, and wants to cache the RRs, it should check its cache for
-already existing RRs.  Depending on the circumstances, either the data
-in the response or the cache is preferred, but the two should never be
-combined.  If the data in the response is from authoritative data in the
-answer section, it is always preferred.
-
-8. MAIL SUPPORT
-
-The domain system defines a standard for mapping mailboxes into domain
-names, and two methods for using the mailbox information to derive mail
-routing information.  The first method is called mail exchange binding
-and the other method is mailbox binding.  The mailbox encoding standard
-and mail exchange binding are part of the DNS official protocol, and are
-the recommended method for mail routing in the Internet.  Mailbox
-binding is an experimental feature which is still under development and
-subject to change.
-
-
-
-
-Mockapetris                                                    [Page 47]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-The mailbox encoding standard assumes a mailbox name of the form
-"<local-part>@<mail-domain>".  While the syntax allowed in each of these
-sections varies substantially between the various mail internets, the
-preferred syntax for the ARPA Internet is given in [RFC-822].
-
-The DNS encodes the <local-part> as a single label, and encodes the
-<mail-domain> as a domain name.  The single label from the <local-part>
-is prefaced to the domain name from <mail-domain> to form the domain
-name corresponding to the mailbox.  Thus the mailbox HOSTMASTER@SRI-
-NIC.ARPA is mapped into the domain name HOSTMASTER.SRI-NIC.ARPA.  If the
-<local-part> contains dots or other special characters, its
-representation in a master file will require the use of backslash
-quoting to ensure that the domain name is properly encoded.  For
-example, the mailbox Action.domains@ISI.EDU would be represented as
-Action\.domains.ISI.EDU.
-
-8.1. Mail exchange binding
-
-Mail exchange binding uses the <mail-domain> part of a mailbox
-specification to determine where mail should be sent.  The <local-part>
-is not even consulted.  [RFC-974] specifies this method in detail, and
-should be consulted before attempting to use mail exchange support.
-
-One of the advantages of this method is that it decouples mail
-destination naming from the hosts used to support mail service, at the
-cost of another layer of indirection in the lookup function.  However,
-the addition layer should eliminate the need for complicated "%", "!",
-etc encodings in <local-part>.
-
-The essence of the method is that the <mail-domain> is used as a domain
-name to locate type MX RRs which list hosts willing to accept mail for
-<mail-domain>, together with preference values which rank the hosts
-according to an order specified by the administrators for <mail-domain>.
-
-In this memo, the <mail-domain> ISI.EDU is used in examples, together
-with the hosts VENERA.ISI.EDU and VAXA.ISI.EDU as mail exchanges for
-ISI.EDU.  If a mailer had a message for Mockapetris@ISI.EDU, it would
-route it by looking up MX RRs for ISI.EDU.  The MX RRs at ISI.EDU name
-VENERA.ISI.EDU and VAXA.ISI.EDU, and type A queries can find the host
-addresses.
-
-8.2. Mailbox binding (Experimental)
-
-In mailbox binding, the mailer uses the entire mail destination
-specification to construct a domain name.  The encoded domain name for
-the mailbox is used as the QNAME field in a QTYPE=MAILB query.
-
-Several outcomes are possible for this query:
-
-
-
-Mockapetris                                                    [Page 48]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-   1. The query can return a name error indicating that the mailbox
-      does not exist as a domain name.
-
-      In the long term, this would indicate that the specified
-      mailbox doesn't exist.  However, until the use of mailbox
-      binding is universal, this error condition should be
-      interpreted to mean that the organization identified by the
-      global part does not support mailbox binding.  The
-      appropriate procedure is to revert to exchange binding at
-      this point.
-
-   2. The query can return a Mail Rename (MR) RR.
-
-      The MR RR carries new mailbox specification in its RDATA
-      field.  The mailer should replace the old mailbox with the
-      new one and retry the operation.
-
-   3. The query can return a MB RR.
-
-      The MB RR carries a domain name for a host in its RDATA
-      field.  The mailer should deliver the message to that host
-      via whatever protocol is applicable, e.g., b,SMTP.
-
-   4. The query can return one or more Mail Group (MG) RRs.
-
-      This condition means that the mailbox was actually a mailing
-      list or mail group, rather than a single mailbox.  Each MG RR
-      has a RDATA field that identifies a mailbox that is a member
-      of the group.  The mailer should deliver a copy of the
-      message to each member.
-
-   5. The query can return a MB RR as well as one or more MG RRs.
-
-      This condition means the the mailbox was actually a mailing
-      list.  The mailer can either deliver the message to the host
-      specified by the MB RR, which will in turn do the delivery to
-      all members, or the mailer can use the MG RRs to do the
-      expansion itself.
-
-In any of these cases, the response may include a Mail Information
-(MINFO) RR.  This RR is usually associated with a mail group, but is
-legal with a MB.  The MINFO RR identifies two mailboxes.  One of these
-identifies a responsible person for the original mailbox name.  This
-mailbox should be used for requests to be added to a mail group, etc.
-The second mailbox name in the MINFO RR identifies a mailbox that should
-receive error messages for mail failures.  This is particularly
-appropriate for mailing lists when errors in member names should be
-reported to a person other than the one who sends a message to the list.
-
-
-
-Mockapetris                                                    [Page 49]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-New fields may be added to this RR in the future.
-
-
-9. REFERENCES and BIBLIOGRAPHY
-
-[Dyer 87]       S. Dyer, F. Hsu, "Hesiod", Project Athena
-                Technical Plan - Name Service, April 1987, version 1.9.
-
-                Describes the fundamentals of the Hesiod name service.
-
-[IEN-116]       J. Postel, "Internet Name Server", IEN-116,
-                USC/Information Sciences Institute, August 1979.
-
-                A name service obsoleted by the Domain Name System, but
-                still in use.
-
-[Quarterman 86] J. Quarterman, and J. Hoskins, "Notable Computer Networks",
-                Communications of the ACM, October 1986, volume 29, number
-                10.
-
-[RFC-742]       K. Harrenstien, "NAME/FINGER", RFC-742, Network
-                Information Center, SRI International, December 1977.
-
-[RFC-768]       J. Postel, "User Datagram Protocol", RFC-768,
-                USC/Information Sciences Institute, August 1980.
-
-[RFC-793]       J. Postel, "Transmission Control Protocol", RFC-793,
-                USC/Information Sciences Institute, September 1981.
-
-[RFC-799]       D. Mills, "Internet Name Domains", RFC-799, COMSAT,
-                September 1981.
-
-                Suggests introduction of a hierarchy in place of a flat
-                name space for the Internet.
-
-[RFC-805]       J. Postel, "Computer Mail Meeting Notes", RFC-805,
-                USC/Information Sciences Institute, February 1982.
-
-[RFC-810]       E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD
-                Internet Host Table Specification", RFC-810, Network
-                Information Center, SRI International, March 1982.
-
-                Obsolete.  See RFC-952.
-
-[RFC-811]       K. Harrenstien, V. White, and E. Feinler, "Hostnames
-                Server", RFC-811, Network Information Center, SRI
-                International, March 1982.
-
-
-
-
-Mockapetris                                                    [Page 50]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-                Obsolete.  See RFC-953.
-
-[RFC-812]       K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC-812,
-                Network Information Center, SRI International, March
-                1982.
-
-[RFC-819]       Z. Su, and J. Postel, "The Domain Naming Convention for
-                Internet User Applications", RFC-819, Network
-                Information Center, SRI International, August 1982.
-
-                Early thoughts on the design of the domain system.
-                Current implementation is completely different.
-
-[RFC-821]       J. Postel, "Simple Mail Transfer Protocol", RFC-821,
-                USC/Information Sciences Institute, August 1980.
-
-[RFC-830]       Z. Su, "A Distributed System for Internet Name Service",
-                RFC-830, Network Information Center, SRI International,
-                October 1982.
-
-                Early thoughts on the design of the domain system.
-                Current implementation is completely different.
-
-[RFC-882]       P. Mockapetris, "Domain names - Concepts and
-                Facilities," RFC-882, USC/Information Sciences
-                Institute, November 1983.
-
-                Superceeded by this memo.
-
-[RFC-883]       P. Mockapetris, "Domain names - Implementation and
-                Specification," RFC-883, USC/Information Sciences
-                Institute, November 1983.
-
-                Superceeded by this memo.
-
-[RFC-920]       J. Postel and J. Reynolds, "Domain Requirements",
-                RFC-920, USC/Information Sciences Institute,
-                October 1984.
-
-                Explains the naming scheme for top level domains.
-
-[RFC-952]       K. Harrenstien, M. Stahl, E. Feinler, "DoD Internet Host
-                Table Specification", RFC-952, SRI, October 1985.
-
-                Specifies the format of HOSTS.TXT, the host/address
-                table replaced by the DNS.
-
-
-
-
-
-Mockapetris                                                    [Page 51]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-[RFC-953]       K. Harrenstien, M. Stahl, E. Feinler, "HOSTNAME Server",
-                RFC-953, SRI, October 1985.
-
-                This RFC contains the official specification of the
-                hostname server protocol, which is obsoleted by the DNS.
-                This TCP based protocol accesses information stored in
-                the RFC-952 format, and is used to obtain copies of the
-                host table.
-
-[RFC-973]       P. Mockapetris, "Domain System Changes and
-                Observations", RFC-973, USC/Information Sciences
-                Institute, January 1986.
-
-                Describes changes to RFC-882 and RFC-883 and reasons for
-                them.
-
-[RFC-974]       C. Partridge, "Mail routing and the domain system",
-                RFC-974, CSNET CIC BBN Labs, January 1986.
-
-                Describes the transition from HOSTS.TXT based mail
-                addressing to the more powerful MX system used with the
-                domain system.
-
-[RFC-1001]      NetBIOS Working Group, "Protocol standard for a NetBIOS
-                service on a TCP/UDP transport: Concepts and Methods",
-                RFC-1001, March 1987.
-
-                This RFC and RFC-1002 are a preliminary design for
-                NETBIOS on top of TCP/IP which proposes to base NetBIOS
-                name service on top of the DNS.
-
-[RFC-1002]      NetBIOS Working Group, "Protocol standard for a NetBIOS
-                service on a TCP/UDP transport: Detailed
-                Specifications", RFC-1002, March 1987.
-
-[RFC-1010]      J. Reynolds, and J. Postel, "Assigned Numbers", RFC-1010,
-                USC/Information Sciences Institute, May 1987.
-
-                Contains socket numbers and mnemonics for host names,
-                operating systems, etc.
-
-[RFC-1031]      W. Lazear, "MILNET Name Domain Transition", RFC-1031,
-                November 1987.
-
-                Describes a plan for converting the MILNET to the DNS.
-
-[RFC-1032]      M. Stahl, "Establishing a Domain - Guidelines for
-                Administrators", RFC-1032, November 1987.
-
-
-
-Mockapetris                                                    [Page 52]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-                Describes the registration policies used by the NIC to
-                administer the top level domains and delegate subzones.
-
-[RFC-1033]      M. Lottor, "Domain Administrators Operations Guide",
-                RFC-1033, November 1987.
-
-                A cookbook for domain administrators.
-
-[Solomon 82]    M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET
-                Name Server", Computer Networks, vol 6, nr 3, July 1982.
-
-                Describes a name service for CSNET which is independent
-                from the DNS and DNS use in the CSNET.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 53]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-Index
-
-          *   13
-
-          ;   33, 35
-
-          <character-string>   35
-          <domain-name>   34
-
-          @   35
-
-          \   35
-
-          A   12
-
-          Byte order   8
-
-          CH   13
-          Character case   9
-          CLASS   11
-          CNAME   12
-          Completion   42
-          CS   13
-
-          Hesiod   13
-          HINFO   12
-          HS   13
-
-          IN   13
-          IN-ADDR.ARPA domain   22
-          Inverse queries   40
-
-          Mailbox names   47
-          MB   12
-          MD   12
-          MF   12
-          MG   12
-          MINFO   12
-          MINIMUM   20
-          MR   12
-          MX   12
-
-          NS   12
-          NULL   12
-
-          Port numbers   32
-          Primary server   5
-          PTR   12, 18
-
-
-
-Mockapetris                                                    [Page 54]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-          QCLASS   13
-          QTYPE   12
-
-          RDATA   12
-          RDLENGTH  11
-
-          Secondary server   5
-          SOA   12
-          Stub resolvers   7
-
-          TCP   32
-          TXT   12
-          TYPE   11
-
-          UDP   32
-
-          WKS   12
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 55]
-
diff --git a/contrib/bind9/doc/rfc/rfc1101.txt b/contrib/bind9/doc/rfc/rfc1101.txt
deleted file mode 100644
index 66c9d8b..0000000
--- a/contrib/bind9/doc/rfc/rfc1101.txt
+++ /dev/null
@@ -1,787 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                     P. Mockapetris
-Request for Comments: 1101                                           ISI
-Updates: RFCs 1034, 1035                                      April 1989
-
-
-             DNS Encoding of Network Names and Other Types
-
-
-1. STATUS OF THIS MEMO
-
-   This RFC proposes two extensions to the Domain Name System:
-
-      - A specific method for entering and retrieving RRs which map
-        between network names and numbers.
-
-      - Ideas for a general method for describing mappings between
-        arbitrary identifiers and numbers.
-
-   The method for mapping between network names and addresses is a
-   proposed standard, the ideas for a general method are experimental.
-
-   This RFC assumes that the reader is familiar with the DNS [RFC 1034,
-   RFC 1035] and its use.  The data shown is for pedagogical use and
-   does not necessarily reflect the real Internet.
-
-   Distribution of this memo is unlimited.
-
-2. INTRODUCTION
-
-   The DNS is extensible and can be used for a virtually unlimited
-   number of data types, name spaces, etc.  New type definitions are
-   occasionally necessary as are revisions or deletions of old types
-   (e.g., MX replacement of MD and MF [RFC 974]), and changes described
-   in [RFC 973].  This RFC describes changes due to the general need to
-   map between identifiers and values, and a specific need for network
-   name support.
-
-   Users wish to be able to use the DNS to map between network names and
-   numbers.  This need is the only capability found in HOSTS.TXT which
-   is not available from the DNS.  In designing a method to do this,
-   there were two major areas of concern:
-
-      - Several tradeoffs involving control of network names, the
-        syntax of network names, backward compatibility, etc.
-
-      - A desire to create a method which would be sufficiently
-        general to set a good precedent for future mappings,
-        for example, between TCP-port names and numbers,
-
-
-
-Mockapetris                                                     [Page 1]
-
-RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
-
-
-        autonomous system names and numbers, X.500 Relative
-        Distinguished Names (RDNs) and their servers, or whatever.
-
-   It was impossible to reconcile these two areas of concern for network
-   names because of the desire to unify network number support within
-   existing IP address to host name support.  The existing support is
-   the IN-ADDR.ARPA section of the DNS name space.  As a result this RFC
-   describes one structure for network names which builds on the
-   existing support for host names, and another family of structures for
-   future yellow pages (YP) functions such as conversions between TCP-
-   port numbers and mnemonics.
-
-   Both structures are described in following sections.  Each structure
-   has a discussion of design issues and specific structure
-   recommendations.
-
-   We wish to avoid defining structures and methods which can work but
-   do not because of indifference or errors on the part of system
-   administrators when maintaining the database.  The WKS RR is an
-   example.  Thus, while we favor distribution as a general method, we
-   also recognize that centrally maintained tables (such as HOSTS.TXT)
-   are usually more consistent though less maintainable and timely.
-   Hence we recommend both specific methods for mapping network names,
-   addresses, and subnets, as well as an instance of the general method
-   for mapping between allocated network numbers and network names.
-   (Allocation is centrally performed by the SRI Network Information
-   Center, aka the NIC).
-
-3. NETWORK NAME ISSUES AND DISCUSSION
-
-   The issues involved in the design were the definition of network name
-   syntax, the mappings to be provided, and possible support for similar
-   functions at the subnet level.
-
-3.1. Network name syntax
-
-   The current syntax for network names, as defined by [RFC 952] is an
-   alphanumeric string of up to 24 characters, which begins with an
-   alpha, and may include "." and "-" except as first and last
-   characters.  This is the format which was also used for host names
-   before the DNS.  Upward compatibility with existing names might be a
-   goal of any new scheme.
-
-   However, the present syntax has been used to define a flat name
-   space, and hence would prohibit the same distributed name allocation
-   method used for host names.  There is some sentiment for allowing the
-   NIC to continue to allocate and regulate network names, much as it
-   allocates numbers, but the majority opinion favors local control of
-
-
-
-Mockapetris                                                     [Page 2]
-
-RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
-
-
-   network names.  Although it would be possible to provide a flat space
-   or a name space in which, for example, the last label of a domain
-   name captured the old-style network name, any such approach would add
-   complexity to the method and create different rules for network names
-   and host names.
-
-   For these reasons, we assume that the syntax of network names will be
-   the same as the expanded syntax for host names permitted in [HR].
-   The new syntax expands the set of names to allow leading digits, so
-   long as the resulting representations do not conflict with IP
-   addresses in decimal octet form.  For example, 3Com.COM and 3M.COM
-   are now legal, although 26.0.0.73.COM is not.  See [HR] for details.
-
-   The price is that network names will get as complicated as host
-   names.  An administrator will be able to create network names in any
-   domain under his control, and also create network number to name
-   entries in IN-ADDR.ARPA domains under his control.  Thus, the name
-   for the ARPANET might become NET.ARPA, ARPANET.ARPA or Arpa-
-   network.MIL., depending on the preferences of the owner.
-
-3.2. Mappings
-
-   The desired mappings, ranked by priority with most important first,
-   are:
-
-      - Mapping a IP address or network number to a network name.
-
-        This mapping is for use in debugging tools and status displays
-        of various sorts.  The conversion from IP address to network
-        number is well known for class A, B, and C IP addresses, and
-        involves a simple mask operation.  The needs of other classes
-        are not yet defined and are ignored for the rest of this RFC.
-
-      - Mapping a network name to a network address.
-
-        This facility is of less obvious application, but a
-        symmetrical mapping seems desirable.
-
-      - Mapping an organization to its network names and numbers.
-
-        This facility is useful because it may not always be possible
-        to guess the local choice for network names, but the
-        organization name is often well known.
-
-      - Similar mappings for subnets, even when nested.
-
-        The primary application is to be able to identify all of the
-        subnets involved in a particular IP address.  A secondary
-
-
-
-Mockapetris                                                     [Page 3]
-
-RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
-
-
-        requirement is to retrieve address mask information.
-
-3.3. Network address section of the name space
-
-   The network name syntax discussed above can provide domain names
-   which will contain mappings from network names to various quantities,
-   but we also need a section of the name space, organized by network
-   and subnet number to hold the inverse mappings.
-
-   The choices include:
-
-      - The same network number slots already assigned and delegated
-        in the IN-ADDR.ARPA section of the name space.
-
-        For example, 10.IN-ADDR.ARPA for class A net 10,
-        2.128.IN-ADDR.ARPA for class B net 128.2, etc.
-
-      - Host-zero addresses in the IN-ADDR.ARPA tree.  (A host field
-        of all zero in an IP address is prohibited because of
-        confusion related to broadcast addresses, et al.)
-
-        For example, 0.0.0.10.IN-ADDR.ARPA for class A net 10,
-        0.0.2.128.IN-ADDR.arpa for class B net 128.2, etc.  Like the
-        first scheme, it uses in-place name space delegations to
-        distribute control.
-
-        The main advantage of this scheme over the first is that it
-        allows convenient names for subnets as well as networks.  A
-        secondary advantage is that it uses names which are not in use
-        already, and hence it is possible to test whether an
-        organization has entered this information in its domain
-        database.
-
-      - Some new section of the name space.
-
-        While this option provides the most opportunities, it creates
-        a need to delegate a whole new name space.  Since the IP
-        address space is so closely related to the network number
-        space, most believe that the overhead of creating such a new
-        space is overwhelming and would lead to the WKS syndrome.  (As
-        of February, 1989, approximately 400 sections of the
-        IN-ADDR.ARPA tree are already delegated, usually at network
-        boundaries.)
-
-
-
-
-
-
-
-
-Mockapetris                                                     [Page 4]
-
-RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
-
-
-4. SPECIFICS FOR NETWORK NAME MAPPINGS
-
-   The proposed solution uses information stored at:
-
-      - Names in the IN-ADDR.ARPA tree that correspond to host-zero IP
-        addresses.  The same method is used for subnets in a nested
-        fashion.  For example, 0.0.0.10.IN-ADDR.ARPA. for net 10.
-
-        Two types of information are stored here: PTR RRs which point
-        to the network name in their data sections, and A RRs, which
-        are present if the network (or subnet) is subnetted further.
-        If a type A RR is present, then it has the address mask as its
-        data.  The general form is:
-
-        <reversed-host-zero-number>.IN-ADDR.ARPA. PTR <network-name>
-        <reversed-host-zero-number>.IN-ADDR.ARPA. A   <subnet-mask>
-
-        For example:
-
-        0.0.0.10.IN-ADDR.ARPA.  PTR     ARPANET.ARPA.
-
-        or
-
-        0.0.2.128.IN-ADDR.ARPA. PTR     cmu-net.cmu.edu.
-                                A       255.255.255.0
-
-        In general, this information will be added to an existing
-        master file for some IN-ADDR.ARPA domain for each network
-        involved.  Similar RRs can be used at host-zero subnet
-        entries.
-
-      - Names which are network names.
-
-        The data stored here is PTR RRs pointing at the host-zero
-        entries.  The general form is:
-
-        <network-name> ptr <reversed-host-zero-number>.IN-ADDR.ARPA
-
-        For example:
-
-        ARPANET.ARPA.           PTR     0.0.0.10.IN-ADDR.ARPA.
-
-        or
-
-        isi-net.isi.edu.        PTR     0.0.9.128.IN-ADDR.ARPA.
-
-        In general, this information will be inserted in the master
-        file for the domain name of the organization; this is a
-
-
-
-Mockapetris                                                     [Page 5]
-
-RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
-
-
-        different file from that which holds the information below
-        IN-ADDR.ARPA.  Similar PTR RRs can be used at subnet names.
-
-      - Names corresponding to organizations.
-
-        The data here is one or more PTR RRs pointing at the
-        IN-ADDR.ARPA names corresponding to host-zero entries for
-        networks.
-
-        For example:
-
-        ISI.EDU.        PTR     0.0.9.128.IN-ADDR.ARPA.
-
-        MCC.COM.        PTR     0.167.5.192.IN-ADDR.ARPA.
-                        PTR     0.168.5.192.IN-ADDR.ARPA.
-                        PTR     0.169.5.192.IN-ADDR.ARPA.
-                        PTR     0.0.62.128.IN-ADDR.ARPA.
-
-4.1. A simple example
-
-   The ARPANET is a Class A network without subnets.  The RRs which
-   would be added, assuming the ARPANET.ARPA was selected as a network
-   name, would be:
-
-   ARPA.                   PTR     0.0.0.10.IN-ADDR.ARPA.
-
-   ARPANET.ARPA.           PTR     0.0.0.10.IN-ADDR.ARPA.
-
-   0.0.0.10.IN-ADDR.ARPA.  PTR     ARPANET.ARPA.
-
-   The first RR states that the organization named ARPA owns net 10 (It
-   might also own more network numbers, and these would be represented
-   with an additional RR per net.)  The second states that the network
-   name ARPANET.ARPA. maps to net 10.  The last states that net 10 is
-   named ARPANET.ARPA.
-
-   Note that all of the usual host and corresponding IN-ADDR.ARPA
-   entries would still be required.
-
-4.2. A complicated, subnetted example
-
-   The ISI network is 128.9, a class B number.  Suppose the ISI network
-   was organized into two levels of subnet, with the first level using
-   an additional 8 bits of address, and the second level using 4 bits,
-   for address masks of x'FFFFFF00' and X'FFFFFFF0'.
-
-   Then the following RRs would be entered in ISI's master file for the
-   ISI.EDU zone:
-
-
-
-Mockapetris                                                     [Page 6]
-
-RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
-
-
-   ; Define network entry
-   isi-net.isi.edu.                PTR  0.0.9.128.IN-ADDR.ARPA.
-
-   ; Define first level subnets
-   div1-subnet.isi.edu.            PTR  0.1.9.128.IN-ADDR.ARPA.
-   div2-subnet.isi.edu.            PTR  0.2.9.128.IN-ADDR.ARPA.
-
-   ; Define second level subnets
-   inc-subsubnet.isi.edu.          PTR  16.2.9.128.IN-ADDR.ARPA.
-
-   in the 9.128.IN-ADDR.ARPA zone:
-
-   ; Define network number and address mask
-   0.0.9.128.IN-ADDR.ARPA.         PTR  isi-net.isi.edu.
-                                   A    255.255.255.0  ;aka X'FFFFFF00'
-
-   ; Define one of the first level subnet numbers and masks
-   0.1.9.128.IN-ADDR.ARPA.         PTR  div1-subnet.isi.edu.
-                                   A    255.255.255.240 ;aka X'FFFFFFF0'
-
-   ; Define another first level subnet number and mask
-   0.2.9.128.IN-ADDR.ARPA.         PTR  div2-subnet.isi.edu.
-                                   A    255.255.255.240 ;aka X'FFFFFFF0'
-
-   ; Define second level subnet number
-   16.2.9.128.IN-ADDR.ARPA.        PTR  inc-subsubnet.isi.edu.
-
-   This assumes that the ISI network is named isi-net.isi.edu., first
-   level subnets are named div1-subnet.isi.edu. and div2-
-   subnet.isi.edu., and a second level subnet is called inc-
-   subsubnet.isi.edu.  (In a real system as complicated as this there
-   would be more first and second level subnets defined, but we have
-   shown enough to illustrate the ideas.)
-
-4.3. Procedure for using an IP address to get network name
-
-   Depending on whether the IP address is class A, B, or C, mask off the
-   high one, two, or three bytes, respectively.  Reverse the octets,
-   suffix IN-ADDR.ARPA, and do a PTR query.
-
-   For example, suppose the IP address is 10.0.0.51.
-
-      1. Since this is a class A address, use a mask x'FF000000' and
-         get 10.0.0.0.
-
-      2. Construct the name 0.0.0.10.IN-ADDR.ARPA.
-
-      3. Do a PTR query.  Get back
-
-
-
-Mockapetris                                                     [Page 7]
-
-RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
-
-
-         0.0.0.10.IN-ADDR.ARPA.  PTR     ARPANET.ARPA.
-
-      4. Conclude that the network name is "ARPANET.ARPA."
-
-   Suppose that the IP address is 128.9.2.17.
-
-      1. Since this is a class B address, use a mask of x'FFFF0000'
-         and get 128.9.0.0.
-
-      2. Construct the name 0.0.9.128.IN-ADDR.ARPA.
-
-      3. Do a PTR query.  Get back
-
-         0.0.9.128.IN-ADDR.ARPA.       PTR     isi-net.isi.edu
-
-      4. Conclude that the network name is "isi-net.isi.edu."
-
-4.4. Procedure for finding all subnets involved with an IP address
-
-   This is a simple extension of the IP address to network name method.
-   When the network entry is located, do a lookup for a possible A RR.
-   If the A RR is found, look up the next level of subnet using the
-   original IP address and the mask in the A RR.  Repeat this procedure
-   until no A RR is found.
-
-   For example, repeating the use of 128.9.2.17.
-
-      1. As before construct a query for 0.0.9.128.IN-ADDR.ARPA.
-         Retrieve:
-
-         0.0.9.128.IN-ADDR.ARPA.  PTR    isi-net.isi.edu.
-                                  A      255.255.255.0
-
-      2. Since an A RR was found, repeat using mask from RR
-         (255.255.255.0), constructing a query for
-         0.2.9.128.IN-ADDR.ARPA.  Retrieve:
-
-         0.2.9.128.IN-ADDR.ARPA.  PTR    div2-subnet.isi.edu.
-                                  A      255.255.255.240
-
-      3. Since another A RR was found, repeat using mask
-         255.255.255.240 (x'FFFFFFF0').  constructing a query for
-         16.2.9.128.IN-ADDR.ARPA.  Retrieve:
-
-         16.2.9.128.IN-ADDR.ARPA. PTR    inc-subsubnet.isi.edu.
-
-      4. Since no A RR is present at 16.2.9.128.IN-ADDR.ARPA., there
-         are no more subnet levels.
-
-
-
-Mockapetris                                                     [Page 8]
-
-RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
-
-
-5. YP ISSUES AND DISCUSSION
-
-   The term "Yellow Pages" is used in almost as many ways as the term
-   "domain", so it is useful to define what is meant herein by YP.  The
-   general problem to be solved is to create a method for creating
-   mappings from one kind of identifier to another, often with an
-   inverse capability.  The traditional methods are to search or use a
-   precomputed index of some kind.
-
-   Searching is impractical when the search is too large, and
-   precomputed indexes are possible only when it is possible to specify
-   search criteria in advance, and pay for the resources necessary to
-   build the index.  For example, it is impractical to search the entire
-   domain tree to find a particular address RR, so we build the IN-
-   ADDR.ARPA YP.  Similarly, we could never build an Internet-wide index
-   of "hosts with a load average of less than 2" in less time than it
-   would take for the data to change, so indexes are a useless approach
-   for that problem.
-
-   Such a precomputed index is what we mean by YP, and we regard the
-   IN-ADDR.ARPA domain as the first instance of a YP in the DNS.
-   Although a single, centrally-managed YP for well-known values such as
-   TCP-port is desirable, we regard organization-specific YPs for, say,
-   locally defined TCP ports as a natural extension, as are combinations
-   of YPs using search lists to merge the two.
-
-   In examining Internet Numbers [RFC 997] and Assigned Numbers [RFC
-   1010], it is clear that there are several mappings which might be of
-   value.  For example:
-
-   <assigned-network-name> <==> <IP-address>
-   <autonomous-system-id>  <==> <number>
-   <protocol-id>           <==> <number>
-   <port-id>               <==> <number>
-   <ethernet-type>         <==> <number>
-   <public-data-net>       <==> <IP-address>
-
-   Following the IN-ADDR example, the YP takes the form of a domain tree
-   organized to optimize retrieval by search key and distribution via
-   normal DNS rules.  The name used as a key must include:
-
-      1. A well known origin.  For example, IN-ADDR.ARPA is the
-         current IP-address to host name YP.
-
-      2. A "from" data type.  This identifies the input type of the
-         mapping.  This is necessary because we may be mapping
-         something as anonymous as a number to any number of
-         mnemonics, etc.
-
-
-
-Mockapetris                                                     [Page 9]
-
-RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
-
-
-      3. A "to" data type.  Since we assume several symmetrical
-         mnemonic <==> number mappings, this is also necessary.
-
-   This ordering reflects the natural scoping of control, and hence the
-   order of the components in a domain name.  Thus domain names would be
-   of the form:
-
-   <from-value>.<to-data-type>.<from-data-type>.<YP-origin>
-
-   To make this work, we need to define well-know strings for each of
-   these metavariables, as well as encoding rules for converting a
-   <from-value> into a domain name.  We might define:
-
-   <YP-origin>     :=YP
-   <from-data-type>:=TCP-port | IN-ADDR | Number |
-                     Assigned-network-number | Name
-   <to-data-type>  :=<from-data-type>
-
-   Note that "YP" is NOT a valid country code under [ISO 3166] (although
-   we may want to worry about the future), and the existence of a
-   syntactically valid <to-data-type>.<from-data-type> pair does not
-   imply that a meaningful mapping exists, or is even possible.
-
-   The encoding rules might be:
-
-   TCP-port        Six character alphanumeric
-
-   IN-ADDR         Reversed 4-octet decimal string
-
-   Number          decimal integer
-
-   Assigned-network-number
-                   Reversed 4-octet decimal string
-
-   Name            Domain name
-
-6. SPECIFICS FOR YP MAPPINGS
-
-6.1. TCP-PORT
-
-   $origin Number.TCP-port.YP.
-
-   23              PTR     TELNET.TCP-port.Number.YP.
-   25              PTR     SMTP.TCP-port.Number.YP.
-
-   $origin TCP-port.Number.YP.
-
-   TELNET          PTR     23.Number.TCP-port.YP.
-
-
-
-Mockapetris                                                    [Page 10]
-
-RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
-
-
-   SMTP            PTR     25.Number.TCP-port.YP.
-
-   Thus the mapping between 23 and TELNET is represented by a pair of
-   PTR RRs, one for each direction of the mapping.
-
-6.2. Assigned networks
-
-   Network numbers are assigned by the NIC and reported in "Internet
-   Numbers" RFCs.  To create a YP, the NIC would set up two domains:
-
-   Name.Assigned-network-number.YP and Assigned-network-number.YP
-
-   The first would contain entries of the form:
-
-   $origin Name.Assigned-network-number.YP.
-
-   0.0.0.4         PTR     SATNET.Assigned-network-number.Name.YP.
-   0.0.0.10        PTR     ARPANET.Assigned-network-number.Name.YP.
-
-   The second would contain entries of the form:
-
-   $origin Assigned-network-number.Name.YP.
-
-   SATNET.         PTR     0.0.0.4.Name.Assigned-network-number.YP.
-   ARPANET.        PTR     0.0.0.10.Name.Assigned-network-number.YP.
-
-   These YPs are not in conflict with the network name support described
-   in the first half of this RFC since they map between ASSIGNED network
-   names and numbers, not those allocated by the organizations
-   themselves.  That is, they document the NIC's decisions about
-   allocating network numbers but do not automatically track any
-   renaming performed by the new owners.
-
-   As a practical matter, we might want to create both of these domains
-   to enable users on the Internet to experiment with centrally
-   maintained support as well as the distributed version, or might want
-   to implement only the allocated number to name mapping and request
-   organizations to convert their allocated network names to the network
-   names described in the distributed model.
-
-6.3. Operational improvements
-
-   We could imagine that all conversion routines using these YPs might
-   be instructed to use "YP.<local-domain>" followed by "YP."  as a
-   search list.  Thus, if the organization ISI.EDU wished to define
-   locally meaningful TCP-PORT, it would define the domains:
-
-   <TCP-port.Number.YP.ISI.EDU> and <Number.TCP-port.YP.ISI.EDU>.
-
-
-
-Mockapetris                                                    [Page 11]
-
-RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
-
-
-   We could add another level of indirection in the YP lookup, defining
-   the <to-data-type>.<from-data-type>.<YP-origin> nodes to point to the
-   YP tree, rather than being the YP tree directly.  This would enable
-   entries of the form:
-
-   IN-ADDR.Netname.YP.   PTR     IN-ADDR.ARPA.
-
-   to splice in YPs from other origins or existing spaces.
-
-   Another possibility would be to shorten the RDATA section of the RRs
-   which map back and forth by deleting the origin.  This could be done
-   either by allowing the domain name in the RDATA portion to not
-   identify a real domain name, or by defining a new RR which used a
-   simple text string rather than a domain name.
-
-   Thus, we might replace
-
-   $origin Assigned-network-number.Name.YP.
-
-   SATNET.         PTR     0.0.0.4.Name.Assigned-network-number.YP.
-   ARPANET.        PTR     0.0.0.10.Name.Assigned-network-number.YP.
-
-   with
-
-   $origin Assigned-network-number.Name.YP.
-
-   SATNET.         PTR     0.0.0.4.
-   ARPANET.        PTR     0.0.0.10.
-
-   or
-
-   $origin Assigned-network-number.Name.YP.
-
-   SATNET.         PTT     "0.0.0.4"
-   ARPANET.        PTT     "0.0.0.10"
-
-   where PTT is a new type whose RDATA section is a text string.
-
-7. ACKNOWLEDGMENTS
-
-   Drew Perkins, Mark Lottor, and Rob Austein contributed several of the
-   ideas in this RFC.  Numerous contributions, criticisms, and
-   compromises were produced in the IETF Domain working group and the
-   NAMEDROPPERS mailing list.
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 12]
-
-RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
-
-
-8. REFERENCES
-
-   [HR]        Braden, B., editor, "Requirements for Internet Hosts",
-               RFC in preparation.
-
-   [ISO 3166]  ISO, "Codes for the Representation of Names of
-               Countries", 1981.
-
-   [RFC 882]   Mockapetris, P., "Domain names - Concepts and
-               Facilities", RFC 882, USC/Information Sciences Institute,
-               November 1983.
-
-               Superseded by RFC 1034.
-
-   [RFC 883]   Mockapetris, P.,"Domain names - Implementation and
-               Specification", RFC 883, USC/Information Sciences
-               Institute, November 1983.
-
-               Superceeded by RFC 1035.
-
-   [RFC 920]   Postel, J. and J. Reynolds, "Domain Requirements", RFC
-               920, October 1984.
-
-               Explains the naming scheme for top level domains.
-
-   [RFC 952]   Harrenstien, K., M. Stahl, and E. Feinler, "DoD Internet
-               Host Table Specification", RFC 952, SRI, October 1985.
-
-               Specifies the format of HOSTS.TXT, the host/address table
-               replaced by the DNS
-
-   [RFC 973]   Mockapetris, P., "Domain System Changes and
-               Observations", RFC 973, USC/Information Sciences
-               Institute, January 1986.
-
-               Describes changes to RFCs 882 and 883 and reasons for
-               them.
-
-   [RFC 974]   Partridge, C., "Mail routing and the domain system", RFC
-               974, CSNET CIC BBN Labs, January 1986.
-
-               Describes the transition from HOSTS.TXT based mail
-               addressing to the more powerful MX system used with the
-               domain system.
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 13]
-
-RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
-
-
-   [RFC 997]   Reynolds, J., and J. Postel, "Internet Numbers", RFC 997,
-               USC/Information Sciences Institute, March 1987
-
-               Contains network numbers, autonomous system numbers, etc.
-
-   [RFC 1010]  Reynolds, J., and J. Postel, "Assigned Numbers", RFC
-               1010, USC/Information Sciences Institute, May 1987
-
-               Contains socket numbers and mnemonics for host names,
-               operating systems, etc.
-
-
-   [RFC 1034]  Mockapetris, P., "Domain names - Concepts and
-               Facilities", RFC 1034, USC/Information Sciences
-               Institute, November 1987.
-
-               Introduction/overview of the DNS.
-
-   [RFC 1035]  Mockapetris, P., "Domain names - Implementation and
-               Specification", RFC 1035, USC/Information Sciences
-               Institute, November 1987.
-
-               DNS implementation instructions.
-
-Author's Address:
-
-   Paul Mockapetris
-   USC/Information Sciences Institute
-   4676 Admiralty Way
-   Marina del Rey, CA 90292
-
-   Phone: (213) 822-1511
-
-   Email: PVM@ISI.EDU
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 14]
-
\ No newline at end of file
diff --git a/contrib/bind9/doc/rfc/rfc1122.txt b/contrib/bind9/doc/rfc/rfc1122.txt
deleted file mode 100644
index c14f2e5..0000000
--- a/contrib/bind9/doc/rfc/rfc1122.txt
+++ /dev/null
@@ -1,6844 +0,0 @@
-
-
-
-
-
-
-Network Working Group                    Internet Engineering Task Force
-Request for Comments: 1122                             R. Braden, Editor
-                                                            October 1989
-
-
-        Requirements for Internet Hosts -- Communication Layers
-
-
-Status of This Memo
-
-   This RFC is an official specification for the Internet community.  It
-   incorporates by reference, amends, corrects, and supplements the
-   primary protocol standards documents relating to hosts.  Distribution
-   of this document is unlimited.
-
-Summary
-
-   This is one RFC of a pair that defines and discusses the requirements
-   for Internet host software.  This RFC covers the communications
-   protocol layers: link layer, IP layer, and transport layer; its
-   companion RFC-1123 covers the application and support protocols.
-
-
-
-                           Table of Contents
-
-
-
-
-   1.  INTRODUCTION ...............................................    5
-      1.1  The Internet Architecture ..............................    6
-         1.1.1  Internet Hosts ....................................    6
-         1.1.2  Architectural Assumptions .........................    7
-         1.1.3  Internet Protocol Suite ...........................    8
-         1.1.4  Embedded Gateway Code .............................   10
-      1.2  General Considerations .................................   12
-         1.2.1  Continuing Internet Evolution .....................   12
-         1.2.2  Robustness Principle ..............................   12
-         1.2.3  Error Logging .....................................   13
-         1.2.4  Configuration .....................................   14
-      1.3  Reading this Document ..................................   15
-         1.3.1  Organization ......................................   15
-         1.3.2  Requirements ......................................   16
-         1.3.3  Terminology .......................................   17
-      1.4  Acknowledgments ........................................   20
-
-   2. LINK LAYER ..................................................   21
-      2.1  INTRODUCTION ...........................................   21
-
-
-
-Internet Engineering Task Force                                 [Page 1]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-      2.2  PROTOCOL WALK-THROUGH ..................................   21
-      2.3  SPECIFIC ISSUES ........................................   21
-         2.3.1  Trailer Protocol Negotiation ......................   21
-         2.3.2  Address Resolution Protocol -- ARP ................   22
-            2.3.2.1  ARP Cache Validation .........................   22
-            2.3.2.2  ARP Packet Queue .............................   24
-         2.3.3  Ethernet and IEEE 802 Encapsulation ...............   24
-      2.4  LINK/INTERNET LAYER INTERFACE ..........................   25
-      2.5  LINK LAYER REQUIREMENTS SUMMARY ........................   26
-
-   3. INTERNET LAYER PROTOCOLS ....................................   27
-      3.1 INTRODUCTION ............................................   27
-      3.2  PROTOCOL WALK-THROUGH ..................................   29
-         3.2.1 Internet Protocol -- IP ............................   29
-            3.2.1.1  Version Number ...............................   29
-            3.2.1.2  Checksum .....................................   29
-            3.2.1.3  Addressing ...................................   29
-            3.2.1.4  Fragmentation and Reassembly .................   32
-            3.2.1.5  Identification ...............................   32
-            3.2.1.6  Type-of-Service ..............................   33
-            3.2.1.7  Time-to-Live .................................   34
-            3.2.1.8  Options ......................................   35
-         3.2.2 Internet Control Message Protocol -- ICMP ..........   38
-            3.2.2.1  Destination Unreachable ......................   39
-            3.2.2.2  Redirect .....................................   40
-            3.2.2.3  Source Quench ................................   41
-            3.2.2.4  Time Exceeded ................................   41
-            3.2.2.5  Parameter Problem ............................   42
-            3.2.2.6  Echo Request/Reply ...........................   42
-            3.2.2.7  Information Request/Reply ....................   43
-            3.2.2.8  Timestamp and Timestamp Reply ................   43
-            3.2.2.9  Address Mask Request/Reply ...................   45
-         3.2.3  Internet Group Management Protocol IGMP ...........   47
-      3.3  SPECIFIC ISSUES ........................................   47
-         3.3.1  Routing Outbound Datagrams ........................   47
-            3.3.1.1  Local/Remote Decision ........................   47
-            3.3.1.2  Gateway Selection ............................   48
-            3.3.1.3  Route Cache ..................................   49
-            3.3.1.4  Dead Gateway Detection .......................   51
-            3.3.1.5  New Gateway Selection ........................   55
-            3.3.1.6  Initialization ...............................   56
-         3.3.2  Reassembly ........................................   56
-         3.3.3  Fragmentation .....................................   58
-         3.3.4  Local Multihoming .................................   60
-            3.3.4.1  Introduction .................................   60
-            3.3.4.2  Multihoming Requirements .....................   61
-            3.3.4.3  Choosing a Source Address ....................   64
-         3.3.5  Source Route Forwarding ...........................   65
-
-
-
-Internet Engineering Task Force                                 [Page 2]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-         3.3.6  Broadcasts ........................................   66
-         3.3.7  IP Multicasting ...................................   67
-         3.3.8  Error Reporting ...................................   69
-      3.4  INTERNET/TRANSPORT LAYER INTERFACE .....................   69
-      3.5  INTERNET LAYER REQUIREMENTS SUMMARY ....................   72
-
-   4. TRANSPORT PROTOCOLS .........................................   77
-      4.1  USER DATAGRAM PROTOCOL -- UDP ..........................   77
-         4.1.1  INTRODUCTION ......................................   77
-         4.1.2  PROTOCOL WALK-THROUGH .............................   77
-         4.1.3  SPECIFIC ISSUES ...................................   77
-            4.1.3.1  Ports ........................................   77
-            4.1.3.2  IP Options ...................................   77
-            4.1.3.3  ICMP Messages ................................   78
-            4.1.3.4  UDP Checksums ................................   78
-            4.1.3.5  UDP Multihoming ..............................   79
-            4.1.3.6  Invalid Addresses ............................   79
-         4.1.4  UDP/APPLICATION LAYER INTERFACE ...................   79
-         4.1.5  UDP REQUIREMENTS SUMMARY ..........................   80
-      4.2  TRANSMISSION CONTROL PROTOCOL -- TCP ...................   82
-         4.2.1  INTRODUCTION ......................................   82
-         4.2.2  PROTOCOL WALK-THROUGH .............................   82
-            4.2.2.1  Well-Known Ports .............................   82
-            4.2.2.2  Use of Push ..................................   82
-            4.2.2.3  Window Size ..................................   83
-            4.2.2.4  Urgent Pointer ...............................   84
-            4.2.2.5  TCP Options ..................................   85
-            4.2.2.6  Maximum Segment Size Option ..................   85
-            4.2.2.7  TCP Checksum .................................   86
-            4.2.2.8  TCP Connection State Diagram .................   86
-            4.2.2.9  Initial Sequence Number Selection ............   87
-            4.2.2.10  Simultaneous Open Attempts ..................   87
-            4.2.2.11  Recovery from Old Duplicate SYN .............   87
-            4.2.2.12  RST Segment .................................   87
-            4.2.2.13  Closing a Connection ........................   87
-            4.2.2.14  Data Communication ..........................   89
-            4.2.2.15  Retransmission Timeout ......................   90
-            4.2.2.16  Managing the Window .........................   91
-            4.2.2.17  Probing Zero Windows ........................   92
-            4.2.2.18  Passive OPEN Calls ..........................   92
-            4.2.2.19  Time to Live ................................   93
-            4.2.2.20  Event Processing ............................   93
-            4.2.2.21  Acknowledging Queued Segments ...............   94
-         4.2.3  SPECIFIC ISSUES ...................................   95
-            4.2.3.1  Retransmission Timeout Calculation ...........   95
-            4.2.3.2  When to Send an ACK Segment ..................   96
-            4.2.3.3  When to Send a Window Update .................   97
-            4.2.3.4  When to Send Data ............................   98
-
-
-
-Internet Engineering Task Force                                 [Page 3]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-            4.2.3.5  TCP Connection Failures ......................  100
-            4.2.3.6  TCP Keep-Alives ..............................  101
-            4.2.3.7  TCP Multihoming ..............................  103
-            4.2.3.8  IP Options ...................................  103
-            4.2.3.9  ICMP Messages ................................  103
-            4.2.3.10  Remote Address Validation ...................  104
-            4.2.3.11  TCP Traffic Patterns ........................  104
-            4.2.3.12  Efficiency ..................................  105
-         4.2.4  TCP/APPLICATION LAYER INTERFACE ...................  106
-            4.2.4.1  Asynchronous Reports .........................  106
-            4.2.4.2  Type-of-Service ..............................  107
-            4.2.4.3  Flush Call ...................................  107
-            4.2.4.4  Multihoming ..................................  108
-         4.2.5  TCP REQUIREMENT SUMMARY ...........................  108
-
-   5.  REFERENCES .................................................  112
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                 [Page 4]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-1.  INTRODUCTION
-
-   This document is one of a pair that defines and discusses the
-   requirements for host system implementations of the Internet protocol
-   suite.  This RFC covers the communication protocol layers:  link
-   layer, IP layer, and transport layer.  Its companion RFC,
-   "Requirements for Internet Hosts -- Application and Support"
-   [INTRO:1], covers the application layer protocols.  This document
-   should also be read in conjunction with "Requirements for Internet
-   Gateways" [INTRO:2].
-
-   These documents are intended to provide guidance for vendors,
-   implementors, and users of Internet communication software.  They
-   represent the consensus of a large body of technical experience and
-   wisdom, contributed by the members of the Internet research and
-   vendor communities.
-
-   This RFC enumerates standard protocols that a host connected to the
-   Internet must use, and it incorporates by reference the RFCs and
-   other documents describing the current specifications for these
-   protocols.  It corrects errors in the referenced documents and adds
-   additional discussion and guidance for an implementor.
-
-   For each protocol, this document also contains an explicit set of
-   requirements, recommendations, and options.  The reader must
-   understand that the list of requirements in this document is
-   incomplete by itself; the complete set of requirements for an
-   Internet host is primarily defined in the standard protocol
-   specification documents, with the corrections, amendments, and
-   supplements contained in this RFC.
-
-   A good-faith implementation of the protocols that was produced after
-   careful reading of the RFC's and with some interaction with the
-   Internet technical community, and that followed good communications
-   software engineering practices, should differ from the requirements
-   of this document in only minor ways.  Thus, in many cases, the
-   "requirements" in this RFC are already stated or implied in the
-   standard protocol documents, so that their inclusion here is, in a
-   sense, redundant.  However, they were included because some past
-   implementation has made the wrong choice, causing problems of
-   interoperability, performance, and/or robustness.
-
-   This document includes discussion and explanation of many of the
-   requirements and recommendations.  A simple list of requirements
-   would be dangerous, because:
-
-   o    Some required features are more important than others, and some
-        features are optional.
-
-
-
-Internet Engineering Task Force                                 [Page 5]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-   o    There may be valid reasons why particular vendor products that
-        are designed for restricted contexts might choose to use
-        different specifications.
-
-   However, the specifications of this document must be followed to meet
-   the general goal of arbitrary host interoperation across the
-   diversity and complexity of the Internet system.  Although most
-   current implementations fail to meet these requirements in various
-   ways, some minor and some major, this specification is the ideal
-   towards which we need to move.
-
-   These requirements are based on the current level of Internet
-   architecture.  This document will be updated as required to provide
-   additional clarifications or to include additional information in
-   those areas in which specifications are still evolving.
-
-   This introductory section begins with a brief overview of the
-   Internet architecture as it relates to hosts, and then gives some
-   general advice to host software vendors.  Finally, there is some
-   guidance on reading the rest of the document and some terminology.
-
-   1.1  The Internet Architecture
-
-      General background and discussion on the Internet architecture and
-      supporting protocol suite can be found in the DDN Protocol
-      Handbook [INTRO:3]; for background see for example [INTRO:9],
-      [INTRO:10], and [INTRO:11].  Reference [INTRO:5] describes the
-      procedure for obtaining Internet protocol documents, while
-      [INTRO:6] contains a list of the numbers assigned within Internet
-      protocols.
-
-      1.1.1  Internet Hosts
-
-         A host computer, or simply "host," is the ultimate consumer of
-         communication services.  A host generally executes application
-         programs on behalf of user(s), employing network and/or
-         Internet communication services in support of this function.
-         An Internet host corresponds to the concept of an "End-System"
-         used in the OSI protocol suite [INTRO:13].
-
-         An Internet communication system consists of interconnected
-         packet networks supporting communication among host computers
-         using the Internet protocols.  The networks are interconnected
-         using packet-switching computers called "gateways" or "IP
-         routers" by the Internet community, and "Intermediate Systems"
-         by the OSI world [INTRO:13].  The RFC "Requirements for
-         Internet Gateways" [INTRO:2] contains the official
-         specifications for Internet gateways.  That RFC together with
-
-
-
-Internet Engineering Task Force                                 [Page 6]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-         the present document and its companion [INTRO:1] define the
-         rules for the current realization of the Internet architecture.
-
-         Internet hosts span a wide range of size, speed, and function.
-         They range in size from small microprocessors through
-         workstations to mainframes and supercomputers.  In function,
-         they range from single-purpose hosts (such as terminal servers)
-         to full-service hosts that support a variety of online network
-         services, typically including remote login, file transfer, and
-         electronic mail.
-
-         A host is generally said to be multihomed if it has more than
-         one interface to the same or to different networks.  See
-         Section 1.1.3 on "Terminology".
-
-      1.1.2  Architectural Assumptions
-
-         The current Internet architecture is based on a set of
-         assumptions about the communication system.  The assumptions
-         most relevant to hosts are as follows:
-
-         (a)  The Internet is a network of networks.
-
-              Each host is directly connected to some particular
-              network(s); its connection to the Internet is only
-              conceptual.  Two hosts on the same network communicate
-              with each other using the same set of protocols that they
-              would use to communicate with hosts on distant networks.
-
-         (b)  Gateways don't keep connection state information.
-
-              To improve robustness of the communication system,
-              gateways are designed to be stateless, forwarding each IP
-              datagram independently of other datagrams.  As a result,
-              redundant paths can be exploited to provide robust service
-              in spite of failures of intervening gateways and networks.
-
-              All state information required for end-to-end flow control
-              and reliability is implemented in the hosts, in the
-              transport layer or in application programs.  All
-              connection control information is thus co-located with the
-              end points of the communication, so it will be lost only
-              if an end point fails.
-
-         (c)  Routing complexity should be in the gateways.
-
-              Routing is a complex and difficult problem, and ought to
-              be performed by the gateways, not the hosts.  An important
-
-
-
-Internet Engineering Task Force                                 [Page 7]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-              objective is to insulate host software from changes caused
-              by the inevitable evolution of the Internet routing
-              architecture.
-
-         (d)  The System must tolerate wide network variation.
-
-              A basic objective of the Internet design is to tolerate a
-              wide range of network characteristics -- e.g., bandwidth,
-              delay, packet loss, packet reordering, and maximum packet
-              size.  Another objective is robustness against failure of
-              individual networks, gateways, and hosts, using whatever
-              bandwidth is still available.  Finally, the goal is full
-              "open system interconnection": an Internet host must be
-              able to interoperate robustly and effectively with any
-              other Internet host, across diverse Internet paths.
-
-              Sometimes host implementors have designed for less
-              ambitious goals.  For example, the LAN environment is
-              typically much more benign than the Internet as a whole;
-              LANs have low packet loss and delay and do not reorder
-              packets.  Some vendors have fielded host implementations
-              that are adequate for a simple LAN environment, but work
-              badly for general interoperation.  The vendor justifies
-              such a product as being economical within the restricted
-              LAN market.  However, isolated LANs seldom stay isolated
-              for long; they are soon gatewayed to each other, to
-              organization-wide internets, and eventually to the global
-              Internet system.  In the end, neither the customer nor the
-              vendor is served by incomplete or substandard Internet
-              host software.
-
-              The requirements spelled out in this document are designed
-              for a full-function Internet host, capable of full
-              interoperation over an arbitrary Internet path.
-
-
-      1.1.3  Internet Protocol Suite
-
-         To communicate using the Internet system, a host must implement
-         the layered set of protocols comprising the Internet protocol
-         suite.  A host typically must implement at least one protocol
-         from each layer.
-
-         The protocol layers used in the Internet architecture are as
-         follows [INTRO:4]:
-
-
-         o  Application Layer
-
-
-
-Internet Engineering Task Force                                 [Page 8]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-              The application layer is the top layer of the Internet
-              protocol suite.  The Internet suite does not further
-              subdivide the application layer, although some of the
-              Internet application layer protocols do contain some
-              internal sub-layering.  The application layer of the
-              Internet suite essentially combines the functions of the
-              top two layers -- Presentation and Application -- of the
-              OSI reference model.
-
-              We distinguish two categories of application layer
-              protocols:  user protocols that provide service directly
-              to users, and support protocols that provide common system
-              functions.  Requirements for user and support protocols
-              will be found in the companion RFC [INTRO:1].
-
-              The most common Internet user protocols are:
-
-                o  Telnet (remote login)
-                o  FTP    (file transfer)
-                o  SMTP   (electronic mail delivery)
-
-              There are a number of other standardized user protocols
-              [INTRO:4] and many private user protocols.
-
-              Support protocols, used for host name mapping, booting,
-              and management, include SNMP, BOOTP, RARP, and the Domain
-              Name System (DNS) protocols.
-
-
-         o  Transport Layer
-
-              The transport layer provides end-to-end communication
-              services for applications.  There are two primary
-              transport layer protocols at present:
-
-                o Transmission Control Protocol (TCP)
-                o User Datagram Protocol (UDP)
-
-              TCP is a reliable connection-oriented transport service
-              that provides end-to-end reliability, resequencing, and
-              flow control.  UDP is a connectionless ("datagram")
-              transport service.
-
-              Other transport protocols have been developed by the
-              research community, and the set of official Internet
-              transport protocols may be expanded in the future.
-
-              Transport layer protocols are discussed in Chapter 4.
-
-
-
-Internet Engineering Task Force                                 [Page 9]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-         o  Internet Layer
-
-              All Internet transport protocols use the Internet Protocol
-              (IP) to carry data from source host to destination host.
-              IP is a connectionless or datagram internetwork service,
-              providing no end-to-end delivery guarantees. Thus, IP
-              datagrams may arrive at the destination host damaged,
-              duplicated, out of order, or not at all.  The layers above
-              IP are responsible for reliable delivery service when it
-              is required.  The IP protocol includes provision for
-              addressing, type-of-service specification, fragmentation
-              and reassembly, and security information.
-
-              The datagram or connectionless nature of the IP protocol
-              is a fundamental and characteristic feature of the
-              Internet architecture.  Internet IP was the model for the
-              OSI Connectionless Network Protocol [INTRO:12].
-
-              ICMP is a control protocol that is considered to be an
-              integral part of IP, although it is architecturally
-              layered upon IP, i.e., it uses IP to carry its data end-
-              to-end just as a transport protocol like TCP or UDP does.
-              ICMP provides error reporting, congestion reporting, and
-              first-hop gateway redirection.
-
-              IGMP is an Internet layer protocol used for establishing
-              dynamic host groups for IP multicasting.
-
-              The Internet layer protocols IP, ICMP, and IGMP are
-              discussed in Chapter 3.
-
-
-         o  Link Layer
-
-              To communicate on its directly-connected network, a host
-              must implement the communication protocol used to
-              interface to that network.  We call this a link layer or
-              media-access layer protocol.
-
-              There is a wide variety of link layer protocols,
-              corresponding to the many different types of networks.
-              See Chapter 2.
-
-
-      1.1.4  Embedded Gateway Code
-
-         Some Internet host software includes embedded gateway
-         functionality, so that these hosts can forward packets as a
-
-
-
-Internet Engineering Task Force                                [Page 10]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-         gateway would, while still performing the application layer
-         functions of a host.
-
-         Such dual-purpose systems must follow the Gateway Requirements
-         RFC [INTRO:2]  with respect to their gateway functions, and
-         must follow the present document with respect to their host
-         functions.  In all overlapping cases, the two specifications
-         should be in agreement.
-
-         There are varying opinions in the Internet community about
-         embedded gateway functionality.  The main arguments are as
-         follows:
-
-         o    Pro: in a local network environment where networking is
-              informal, or in isolated internets, it may be convenient
-              and economical to use existing host systems as gateways.
-
-              There is also an architectural argument for embedded
-              gateway functionality: multihoming is much more common
-              than originally foreseen, and multihoming forces a host to
-              make routing decisions as if it were a gateway.  If the
-              multihomed  host contains an embedded gateway, it will
-              have full routing knowledge and as a result will be able
-              to make more optimal routing decisions.
-
-         o    Con: Gateway algorithms and protocols are still changing,
-              and they will continue to change as the Internet system
-              grows larger.  Attempting to include a general gateway
-              function within the host IP layer will force host system
-              maintainers to track these (more frequent) changes.  Also,
-              a larger pool of gateway implementations will make
-              coordinating the changes more difficult.  Finally, the
-              complexity of a gateway IP layer is somewhat greater than
-              that of a host, making the implementation and operation
-              tasks more complex.
-
-              In addition, the style of operation of some hosts is not
-              appropriate for providing stable and robust gateway
-              service.
-
-         There is considerable merit in both of these viewpoints.  One
-         conclusion can be drawn: an host administrator must have
-         conscious control over whether or not a given host acts as a
-         gateway.  See Section 3.1 for the detailed requirements.
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 11]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-   1.2  General Considerations
-
-      There are two important lessons that vendors of Internet host
-      software have learned and which a new vendor should consider
-      seriously.
-
-      1.2.1  Continuing Internet Evolution
-
-         The enormous growth of the Internet has revealed problems of
-         management and scaling in a large datagram-based packet
-         communication system.  These problems are being addressed, and
-         as a result there will be continuing evolution of the
-         specifications described in this document.  These changes will
-         be carefully planned and controlled, since there is extensive
-         participation in this planning by the vendors and by the
-         organizations responsible for operations of the networks.
-
-         Development, evolution, and revision are characteristic of
-         computer network protocols today, and this situation will
-         persist for some years.  A vendor who develops computer
-         communication software for the Internet protocol suite (or any
-         other protocol suite!) and then fails to maintain and update
-         that software for changing specifications is going to leave a
-         trail of unhappy customers.  The Internet is a large
-         communication network, and the users are in constant contact
-         through it.  Experience has shown that knowledge of
-         deficiencies in vendor software propagates quickly through the
-         Internet technical community.
-
-      1.2.2  Robustness Principle
-
-         At every layer of the protocols, there is a general rule whose
-         application can lead to enormous benefits in robustness and
-         interoperability [IP:1]:
-
-                "Be liberal in what you accept, and
-                 conservative in what you send"
-
-         Software should be written to deal with every conceivable
-         error, no matter how unlikely; sooner or later a packet will
-         come in with that particular combination of errors and
-         attributes, and unless the software is prepared, chaos can
-         ensue.  In general, it is best to assume that the network is
-         filled with malevolent entities that will send in packets
-         designed to have the worst possible effect.  This assumption
-         will lead to suitable protective design, although the most
-         serious problems in the Internet have been caused by
-         unenvisaged mechanisms triggered by low-probability events;
-
-
-
-Internet Engineering Task Force                                [Page 12]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-         mere human malice would never have taken so devious a course!
-
-         Adaptability to change must be designed into all levels of
-         Internet host software.  As a simple example, consider a
-         protocol specification that contains an enumeration of values
-         for a particular header field -- e.g., a type field, a port
-         number, or an error code; this enumeration must be assumed to
-         be incomplete.  Thus, if a protocol specification defines four
-         possible error codes, the software must not break when a fifth
-         code shows up.  An undefined code might be logged (see below),
-         but it must not cause a failure.
-
-         The second part of the principle is almost as important:
-         software on other hosts may contain deficiencies that make it
-         unwise to exploit legal but obscure protocol features.  It is
-         unwise to stray far from the obvious and simple, lest untoward
-         effects result elsewhere.  A corollary of this is "watch out
-         for misbehaving hosts"; host software should be prepared, not
-         just to survive other misbehaving hosts, but also to cooperate
-         to limit the amount of disruption such hosts can cause to the
-         shared communication facility.
-
-      1.2.3  Error Logging
-
-         The Internet includes a great variety of host and gateway
-         systems, each implementing many protocols and protocol layers,
-         and some of these contain bugs and mis-features in their
-         Internet protocol software.  As a result of complexity,
-         diversity, and distribution of function, the diagnosis of
-         Internet problems is often very difficult.
-
-         Problem diagnosis will be aided if host implementations include
-         a carefully designed facility for logging erroneous or
-         "strange" protocol events.  It is important to include as much
-         diagnostic information as possible when an error is logged.  In
-         particular, it is often useful to record the header(s) of a
-         packet that caused an error.  However, care must be taken to
-         ensure that error logging does not consume prohibitive amounts
-         of resources or otherwise interfere with the operation of the
-         host.
-
-         There is a tendency for abnormal but harmless protocol events
-         to overflow error logging files; this can be avoided by using a
-         "circular" log, or by enabling logging only while diagnosing a
-         known failure.  It may be useful to filter and count duplicate
-         successive messages.  One strategy that seems to work well is:
-         (1) always count abnormalities and make such counts accessible
-         through the management protocol (see [INTRO:1]); and (2) allow
-
-
-
-Internet Engineering Task Force                                [Page 13]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-         the logging of a great variety of events to be selectively
-         enabled.  For example, it might useful to be able to "log
-         everything" or to "log everything for host X".
-
-         Note that different managements may have differing policies
-         about the amount of error logging that they want normally
-         enabled in a host.  Some will say, "if it doesn't hurt me, I
-         don't want to know about it", while others will want to take a
-         more watchful and aggressive attitude about detecting and
-         removing protocol abnormalities.
-
-      1.2.4  Configuration
-
-         It would be ideal if a host implementation of the Internet
-         protocol suite could be entirely self-configuring.  This would
-         allow the whole suite to be implemented in ROM or cast into
-         silicon, it would simplify diskless workstations, and it would
-         be an immense boon to harried LAN administrators as well as
-         system vendors.  We have not reached this ideal; in fact, we
-         are not even close.
-
-         At many points in this document, you will find a requirement
-         that a parameter be a configurable option.  There are several
-         different reasons behind such requirements.  In a few cases,
-         there is current uncertainty or disagreement about the best
-         value, and it may be necessary to update the recommended value
-         in the future.  In other cases, the value really depends on
-         external factors -- e.g., the size of the host and the
-         distribution of its communication load, or the speeds and
-         topology of nearby networks -- and self-tuning algorithms are
-         unavailable and may be insufficient.  In some cases,
-         configurability is needed because of administrative
-         requirements.
-
-         Finally, some configuration options are required to communicate
-         with obsolete or incorrect implementations of the protocols,
-         distributed without sources, that unfortunately persist in many
-         parts of the Internet.  To make correct systems coexist with
-         these faulty systems, administrators often have to "mis-
-         configure" the correct systems.  This problem will correct
-         itself gradually as the faulty systems are retired, but it
-         cannot be ignored by vendors.
-
-         When we say that a parameter must be configurable, we do not
-         intend to require that its value be explicitly read from a
-         configuration file at every boot time.  We recommend that
-         implementors set up a default for each parameter, so a
-         configuration file is only necessary to override those defaults
-
-
-
-Internet Engineering Task Force                                [Page 14]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-         that are inappropriate in a particular installation.  Thus, the
-         configurability requirement is an assurance that it will be
-         POSSIBLE to override the default when necessary, even in a
-         binary-only or ROM-based product.
-
-         This document requires a particular value for such defaults in
-         some cases.  The choice of default is a sensitive issue when
-         the configuration item controls the accommodation to existing
-         faulty systems.  If the Internet is to converge successfully to
-         complete interoperability, the default values built into
-         implementations must implement the official protocol, not
-         "mis-configurations" to accommodate faulty implementations.
-         Although marketing considerations have led some vendors to
-         choose mis-configuration defaults, we urge vendors to choose
-         defaults that will conform to the standard.
-
-         Finally, we note that a vendor needs to provide adequate
-         documentation on all configuration parameters, their limits and
-         effects.
-
-
-   1.3  Reading this Document
-
-      1.3.1  Organization
-
-         Protocol layering, which is generally used as an organizing
-         principle in implementing network software, has also been used
-         to organize this document.  In describing the rules, we assume
-         that an implementation does strictly mirror the layering of the
-         protocols.  Thus, the following three major sections specify
-         the requirements for the link layer, the internet layer, and
-         the transport layer, respectively.  A companion RFC [INTRO:1]
-         covers application level software.  This layerist organization
-         was chosen for simplicity and clarity.
-
-         However, strict layering is an imperfect model, both for the
-         protocol suite and for recommended implementation approaches.
-         Protocols in different layers interact in complex and sometimes
-         subtle ways, and particular functions often involve multiple
-         layers.  There are many design choices in an implementation,
-         many of which involve creative "breaking" of strict layering.
-         Every implementor is urged to read references [INTRO:7] and
-         [INTRO:8].
-
-         This document describes the conceptual service interface
-         between layers using a functional ("procedure call") notation,
-         like that used in the TCP specification [TCP:1].  A host
-         implementation must support the logical information flow
-
-
-
-Internet Engineering Task Force                                [Page 15]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-         implied by these calls, but need not literally implement the
-         calls themselves.  For example, many implementations reflect
-         the coupling between the transport layer and the IP layer by
-         giving them shared access to common data structures.  These
-         data structures, rather than explicit procedure calls, are then
-         the agency for passing much of the information that is
-         required.
-
-         In general, each major section of this document is organized
-         into the following subsections:
-
-         (1)  Introduction
-
-         (2)  Protocol Walk-Through -- considers the protocol
-              specification documents section-by-section, correcting
-              errors, stating requirements that may be ambiguous or
-              ill-defined, and providing further clarification or
-              explanation.
-
-         (3)  Specific Issues -- discusses protocol design and
-              implementation issues that were not included in the walk-
-              through.
-
-         (4)  Interfaces -- discusses the service interface to the next
-              higher layer.
-
-         (5)  Summary -- contains a summary of the requirements of the
-              section.
-
-
-         Under many of the individual topics in this document, there is
-         parenthetical material labeled "DISCUSSION" or
-         "IMPLEMENTATION". This material is intended to give
-         clarification and explanation of the preceding requirements
-         text.  It also includes some suggestions on possible future
-         directions or developments.  The implementation material
-         contains suggested approaches that an implementor may want to
-         consider.
-
-         The summary sections are intended to be guides and indexes to
-         the text, but are necessarily cryptic and incomplete.  The
-         summaries should never be used or referenced separately from
-         the complete RFC.
-
-      1.3.2  Requirements
-
-         In this document, the words that are used to define the
-         significance of each particular requirement are capitalized.
-
-
-
-Internet Engineering Task Force                                [Page 16]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-         These words are:
-
-         *    "MUST"
-
-              This word or the adjective "REQUIRED" means that the item
-              is an absolute requirement of the specification.
-
-         *    "SHOULD"
-
-              This word or the adjective "RECOMMENDED" means that there
-              may exist valid reasons in particular circumstances to
-              ignore this item, but the full implications should be
-              understood and the case carefully weighed before choosing
-              a different course.
-
-         *    "MAY"
-
-              This word or the adjective "OPTIONAL" means that this item
-              is truly optional.  One vendor may choose to include the
-              item because a particular marketplace requires it or
-              because it enhances the product, for example; another
-              vendor may omit the same item.
-
-
-         An implementation is not compliant if it fails to satisfy one
-         or more of the MUST requirements for the protocols it
-         implements.  An implementation that satisfies all the MUST and
-         all the SHOULD requirements for its protocols is said to be
-         "unconditionally compliant"; one that satisfies all the MUST
-         requirements but not all the SHOULD requirements for its
-         protocols is said to be "conditionally compliant".
-
-      1.3.3  Terminology
-
-         This document uses the following technical terms:
-
-         Segment
-              A segment is the unit of end-to-end transmission in the
-              TCP protocol.  A segment consists of a TCP header followed
-              by application data.  A segment is transmitted by
-              encapsulation inside an IP datagram.
-
-         Message
-              In this description of the lower-layer protocols, a
-              message is the unit of transmission in a transport layer
-              protocol.  In particular, a TCP segment is a message.  A
-              message consists of a transport protocol header followed
-              by application protocol data.  To be transmitted end-to-
-
-
-
-Internet Engineering Task Force                                [Page 17]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-              end through the Internet, a message must be encapsulated
-              inside a datagram.
-
-         IP Datagram
-              An IP datagram is the unit of end-to-end transmission in
-              the IP protocol.  An IP datagram consists of an IP header
-              followed by transport layer data, i.e., of an IP header
-              followed by a message.
-
-              In the description of the internet layer (Section 3), the
-              unqualified term "datagram" should be understood to refer
-              to an IP datagram.
-
-         Packet
-              A packet is the unit of data passed across the interface
-              between the internet layer and the link layer.  It
-              includes an IP header and data.  A packet may be a
-              complete IP datagram or a fragment of an IP datagram.
-
-         Frame
-              A frame is the unit of transmission in a link layer
-              protocol, and consists of a link-layer header followed by
-              a packet.
-
-         Connected Network
-              A network to which a host is interfaced is often known as
-              the "local network" or the "subnetwork" relative to that
-              host.  However, these terms can cause confusion, and
-              therefore we use the term "connected network" in this
-              document.
-
-         Multihomed
-              A host is said to be multihomed if it has multiple IP
-              addresses.  For a discussion of multihoming, see Section
-              3.3.4 below.
-
-         Physical network interface
-              This is a physical interface to a connected network and
-              has a (possibly unique) link-layer address.  Multiple
-              physical network interfaces on a single host may share the
-              same link-layer address, but the address must be unique
-              for different hosts on the same physical network.
-
-         Logical [network] interface
-              We define a logical [network] interface to be a logical
-              path, distinguished by a unique IP address, to a connected
-              network.  See Section 3.3.4.
-
-
-
-
-Internet Engineering Task Force                                [Page 18]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-         Specific-destination address
-              This is the effective destination address of a datagram,
-              even if it is broadcast or multicast; see Section 3.2.1.3.
-
-         Path
-              At a given moment, all the IP datagrams from a particular
-              source host to a particular destination host will
-              typically traverse the same sequence of gateways.  We use
-              the term "path" for this sequence.  Note that a path is
-              uni-directional; it is not unusual to have different paths
-              in the two directions between a given host pair.
-
-         MTU
-              The maximum transmission unit, i.e., the size of the
-              largest packet that can be transmitted.
-
-
-         The terms frame, packet, datagram, message, and segment are
-         illustrated by the following schematic diagrams:
-
-         A. Transmission on connected network:
-           _______________________________________________
-          | LL hdr | IP hdr |         (data)              |
-          |________|________|_____________________________|
-
-           <---------- Frame ----------------------------->
-                    <----------Packet -------------------->
-
-
-         B. Before IP fragmentation or after IP reassembly:
-                    ______________________________________
-                   | IP hdr | transport| Application Data |
-                   |________|____hdr___|__________________|
-
-                    <--------  Datagram ------------------>
-                             <-------- Message ----------->
-           or, for TCP:
-                    ______________________________________
-                   | IP hdr |  TCP hdr | Application Data |
-                   |________|__________|__________________|
-
-                    <--------  Datagram ------------------>
-                             <-------- Segment ----------->
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 19]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-   1.4  Acknowledgments
-
-      This document incorporates contributions and comments from a large
-      group of Internet protocol experts, including representatives of
-      university and research labs, vendors, and government agencies.
-      It was assembled primarily by the Host Requirements Working Group
-      of the Internet Engineering Task Force (IETF).
-
-      The Editor would especially like to acknowledge the tireless
-      dedication of the following people, who attended many long
-      meetings and generated 3 million bytes of electronic mail over the
-      past 18 months in pursuit of this document: Philip Almquist, Dave
-      Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve
-      Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore),
-      John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG),
-      Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge
-      (BBN), Drew Perkins (CMU), and James Van Bokkelen (FTP Software).
-
-      In addition, the following people made major contributions to the
-      effort: Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia
-      (BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA),
-      Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL),
-      John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill
-      Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul
-      (DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue
-      Technology), and Mike StJohns (DCA).  The following also made
-      significant contributions to particular areas: Eric Allman
-      (Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic
-      (Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn
-      (IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann
-      (Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun
-      Welch (Ohio State), Bill Westfield (Cisco), and Rayan Zachariassen
-      (Toronto).
-
-      We are grateful to all, including any contributors who may have
-      been inadvertently omitted from this list.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 20]
-
-
-
-
-RFC1122                        LINK LAYER                   October 1989
-
-
-2. LINK LAYER
-
-   2.1  INTRODUCTION
-
-      All Internet systems, both hosts and gateways, have the same
-      requirements for link layer protocols.  These requirements are
-      given in Chapter 3 of "Requirements for Internet Gateways"
-      [INTRO:2], augmented with the material in this section.
-
-   2.2  PROTOCOL WALK-THROUGH
-
-      None.
-
-   2.3  SPECIFIC ISSUES
-
-      2.3.1  Trailer Protocol Negotiation
-
-         The trailer protocol [LINK:1] for link-layer encapsulation MAY
-         be used, but only when it has been verified that both systems
-         (host or gateway) involved in the link-layer communication
-         implement trailers.  If the system does not dynamically
-         negotiate use of the trailer protocol on a per-destination
-         basis, the default configuration MUST disable the protocol.
-
-         DISCUSSION:
-              The trailer protocol is a link-layer encapsulation
-              technique that rearranges the data contents of packets
-              sent on the physical network.  In some cases, trailers
-              improve the throughput of higher layer protocols by
-              reducing the amount of data copying within the operating
-              system.  Higher layer protocols are unaware of trailer
-              use, but both the sending and receiving host MUST
-              understand the protocol if it is used.
-
-              Improper use of trailers can result in very confusing
-              symptoms.  Only packets with specific size attributes are
-              encapsulated using trailers, and typically only a small
-              fraction of the packets being exchanged have these
-              attributes.  Thus, if a system using trailers exchanges
-              packets with a system that does not, some packets
-              disappear into a black hole while others are delivered
-              successfully.
-
-         IMPLEMENTATION:
-              On an Ethernet, packets encapsulated with trailers use a
-              distinct Ethernet type [LINK:1], and trailer negotiation
-              is performed at the time that ARP is used to discover the
-              link-layer address of a destination system.
-
-
-
-Internet Engineering Task Force                                [Page 21]
-
-
-
-
-RFC1122                        LINK LAYER                   October 1989
-
-
-              Specifically, the ARP exchange is completed in the usual
-              manner using the normal IP protocol type, but a host that
-              wants to speak trailers will send an additional "trailer
-              ARP reply" packet, i.e., an ARP reply that specifies the
-              trailer encapsulation protocol type but otherwise has the
-              format of a normal ARP reply.  If a host configured to use
-              trailers receives a trailer ARP reply message from a
-              remote machine, it can add that machine to the list of
-              machines that understand trailers, e.g., by marking the
-              corresponding entry in the ARP cache.
-
-              Hosts wishing to receive trailer encapsulations send
-              trailer ARP replies whenever they complete exchanges of
-              normal ARP messages for IP.  Thus, a host that received an
-              ARP request for its IP protocol address would send a
-              trailer ARP reply in addition to the normal IP ARP reply;
-              a host that sent the IP ARP request would send a trailer
-              ARP reply when it received the corresponding IP ARP reply.
-              In this way, either the requesting or responding host in
-              an IP ARP exchange may request that it receive trailer
-              encapsulations.
-
-              This scheme, using extra trailer ARP reply packets rather
-              than sending an ARP request for the trailer protocol type,
-              was designed to avoid a continuous exchange of ARP packets
-              with a misbehaving host that, contrary to any
-              specification or common sense, responded to an ARP reply
-              for trailers with another ARP reply for IP.  This problem
-              is avoided by sending a trailer ARP reply in response to
-              an IP ARP reply only when the IP ARP reply answers an
-              outstanding request; this is true when the hardware
-              address for the host is still unknown when the IP ARP
-              reply is received.  A trailer ARP reply may always be sent
-              along with an IP ARP reply responding to an IP ARP
-              request.
-
-      2.3.2  Address Resolution Protocol -- ARP
-
-         2.3.2.1  ARP Cache Validation
-
-            An implementation of the Address Resolution Protocol (ARP)
-            [LINK:2] MUST provide a mechanism to flush out-of-date cache
-            entries.  If this mechanism involves a timeout, it SHOULD be
-            possible to configure the timeout value.
-
-            A mechanism to prevent ARP flooding (repeatedly sending an
-            ARP Request for the same IP address, at a high rate) MUST be
-            included.  The recommended maximum rate is 1 per second per
-
-
-
-Internet Engineering Task Force                                [Page 22]
-
-
-
-
-RFC1122                        LINK LAYER                   October 1989
-
-
-            destination.
-
-            DISCUSSION:
-                 The ARP specification [LINK:2] suggests but does not
-                 require a timeout mechanism to invalidate cache entries
-                 when hosts change their Ethernet addresses.  The
-                 prevalence of proxy ARP (see Section 2.4 of [INTRO:2])
-                 has significantly increased the likelihood that cache
-                 entries in hosts will become invalid, and therefore
-                 some ARP-cache invalidation mechanism is now required
-                 for hosts.  Even in the absence of proxy ARP, a long-
-                 period cache timeout is useful in order to
-                 automatically correct any bad ARP data that might have
-                 been cached.
-
-            IMPLEMENTATION:
-                 Four mechanisms have been used, sometimes in
-                 combination, to flush out-of-date cache entries.
-
-                 (1)  Timeout -- Periodically time out cache entries,
-                      even if they are in use.  Note that this timeout
-                      should be restarted when the cache entry is
-                      "refreshed" (by observing the source fields,
-                      regardless of target address, of an ARP broadcast
-                      from the system in question).  For proxy ARP
-                      situations, the timeout needs to be on the order
-                      of a minute.
-
-                 (2)  Unicast Poll -- Actively poll the remote host by
-                      periodically sending a point-to-point ARP Request
-                      to it, and delete the entry if no ARP Reply is
-                      received from N successive polls.  Again, the
-                      timeout should be on the order of a minute, and
-                      typically N is 2.
-
-                 (3)  Link-Layer Advice -- If the link-layer driver
-                      detects a delivery problem, flush the
-                      corresponding ARP cache entry.
-
-                 (4)  Higher-layer Advice -- Provide a call from the
-                      Internet layer to the link layer to indicate a
-                      delivery problem.  The effect of this call would
-                      be to invalidate the corresponding cache entry.
-                      This call would be analogous to the
-                      "ADVISE_DELIVPROB()" call from the transport layer
-                      to the Internet layer (see Section 3.4), and in
-                      fact the ADVISE_DELIVPROB routine might in turn
-                      call the link-layer advice routine to invalidate
-
-
-
-Internet Engineering Task Force                                [Page 23]
-
-
-
-
-RFC1122                        LINK LAYER                   October 1989
-
-
-                      the ARP cache entry.
-
-                 Approaches (1) and (2) involve ARP cache timeouts on
-                 the order of a minute or less.  In the absence of proxy
-                 ARP, a timeout this short could create noticeable
-                 overhead traffic on a very large Ethernet.  Therefore,
-                 it may be necessary to configure a host to lengthen the
-                 ARP cache timeout.
-
-         2.3.2.2  ARP Packet Queue
-
-            The link layer SHOULD save (rather than discard) at least
-            one (the latest) packet of each set of packets destined to
-            the same unresolved IP address, and transmit the saved
-            packet when the address has been resolved.
-
-            DISCUSSION:
-                 Failure to follow this recommendation causes the first
-                 packet of every exchange to be lost.  Although higher-
-                 layer protocols can generally cope with packet loss by
-                 retransmission, packet loss does impact performance.
-                 For example, loss of a TCP open request causes the
-                 initial round-trip time estimate to be inflated.  UDP-
-                 based applications such as the Domain Name System are
-                 more seriously affected.
-
-      2.3.3  Ethernet and IEEE 802 Encapsulation
-
-         The IP encapsulation for Ethernets is described in RFC-894
-         [LINK:3], while RFC-1042 [LINK:4] describes the IP
-         encapsulation for IEEE 802 networks.  RFC-1042 elaborates and
-         replaces the discussion in Section 3.4 of [INTRO:2].
-
-         Every Internet host connected to a 10Mbps Ethernet cable:
-
-         o    MUST be able to send and receive packets using RFC-894
-              encapsulation;
-
-         o    SHOULD be able to receive RFC-1042 packets, intermixed
-              with RFC-894 packets; and
-
-         o    MAY be able to send packets using RFC-1042 encapsulation.
-
-
-         An Internet host that implements sending both the RFC-894 and
-         the RFC-1042 encapsulations MUST provide a configuration switch
-         to select which is sent, and this switch MUST default to RFC-
-         894.
-
-
-
-Internet Engineering Task Force                                [Page 24]
-
-
-
-
-RFC1122                        LINK LAYER                   October 1989
-
-
-         Note that the standard IP encapsulation in RFC-1042 does not
-         use the protocol id value (K1=6) that IEEE reserved for IP;
-         instead, it uses a value (K1=170) that implies an extension
-         (the "SNAP") which can be used to hold the Ether-Type field.
-         An Internet system MUST NOT send 802 packets using K1=6.
-
-         Address translation from Internet addresses to link-layer
-         addresses on Ethernet and IEEE 802 networks MUST be managed by
-         the Address Resolution Protocol (ARP).
-
-         The MTU for an Ethernet is 1500 and for 802.3 is 1492.
-
-         DISCUSSION:
-              The IEEE 802.3 specification provides for operation over a
-              10Mbps Ethernet cable, in which case Ethernet and IEEE
-              802.3 frames can be physically intermixed.  A receiver can
-              distinguish Ethernet and 802.3 frames by the value of the
-              802.3 Length field; this two-octet field coincides in the
-              header with the Ether-Type field of an Ethernet frame.  In
-              particular, the 802.3 Length field must be less than or
-              equal to 1500, while all valid Ether-Type values are
-              greater than 1500.
-
-              Another compatibility problem arises with link-layer
-              broadcasts.  A broadcast sent with one framing will not be
-              seen by hosts that can receive only the other framing.
-
-              The provisions of this section were designed to provide
-              direct interoperation between 894-capable and 1042-capable
-              systems on the same cable, to the maximum extent possible.
-              It is intended to support the present situation where
-              894-only systems predominate, while providing an easy
-              transition to a possible future in which 1042-capable
-              systems become common.
-
-              Note that 894-only systems cannot interoperate directly
-              with 1042-only systems.  If the two system types are set
-              up as two different logical networks on the same cable,
-              they can communicate only through an IP gateway.
-              Furthermore, it is not useful or even possible for a
-              dual-format host to discover automatically which format to
-              send, because of the problem of link-layer broadcasts.
-
-   2.4  LINK/INTERNET LAYER INTERFACE
-
-      The packet receive interface between the IP layer and the link
-      layer MUST include a flag to indicate whether the incoming packet
-      was addressed to a link-layer broadcast address.
-
-
-
-Internet Engineering Task Force                                [Page 25]
-
-
-
-
-RFC1122                        LINK LAYER                   October 1989
-
-
-      DISCUSSION
-           Although the IP layer does not generally know link layer
-           addresses (since every different network medium typically has
-           a different address format), the broadcast address on a
-           broadcast-capable medium is an important special case.  See
-           Section 3.2.2, especially the DISCUSSION concerning broadcast
-           storms.
-
-      The packet send interface between the IP and link layers MUST
-      include the 5-bit TOS field (see Section 3.2.1.6).
-
-      The link layer MUST NOT report a Destination Unreachable error to
-      IP solely because there is no ARP cache entry for a destination.
-
-   2.5  LINK LAYER REQUIREMENTS SUMMARY
-
-                                                  |       | | | |S| |
-                                                  |       | | | |H| |F
-                                                  |       | | | |O|M|o
-                                                  |       | |S| |U|U|o
-                                                  |       | |H| |L|S|t
-                                                  |       |M|O| |D|T|n
-                                                  |       |U|U|M| | |o
-                                                  |       |S|L|A|N|N|t
-                                                  |       |T|D|Y|O|O|t
-FEATURE                                           |SECTION| | | |T|T|e
---------------------------------------------------|-------|-|-|-|-|-|--
-                                                  |       | | | | | |
-Trailer encapsulation                             |2.3.1  | | |x| | |
-Send Trailers by default without negotiation      |2.3.1  | | | | |x|
-ARP                                               |2.3.2  | | | | | |
-  Flush out-of-date ARP cache entries             |2.3.2.1|x| | | | |
-  Prevent ARP floods                              |2.3.2.1|x| | | | |
-  Cache timeout configurable                      |2.3.2.1| |x| | | |
-  Save at least one (latest) unresolved pkt       |2.3.2.2| |x| | | |
-Ethernet and IEEE 802 Encapsulation               |2.3.3  | | | | | |
-  Host able to:                                   |2.3.3  | | | | | |
-    Send & receive RFC-894 encapsulation          |2.3.3  |x| | | | |
-    Receive RFC-1042 encapsulation                |2.3.3  | |x| | | |
-    Send RFC-1042 encapsulation                   |2.3.3  | | |x| | |
-      Then config. sw. to select, RFC-894 dflt    |2.3.3  |x| | | | |
-  Send K1=6 encapsulation                         |2.3.3  | | | | |x|
-  Use ARP on Ethernet and IEEE 802 nets           |2.3.3  |x| | | | |
-Link layer report b'casts to IP layer             |2.4    |x| | | | |
-IP layer pass TOS to link layer                   |2.4    |x| | | | |
-No ARP cache entry treated as Dest. Unreach.      |2.4    | | | | |x|
-
-
-
-
-
-Internet Engineering Task Force                                [Page 26]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-3. INTERNET LAYER PROTOCOLS
-
-   3.1 INTRODUCTION
-
-      The Robustness Principle: "Be liberal in what you accept, and
-      conservative in what you send" is particularly important in the
-      Internet layer, where one misbehaving host can deny Internet
-      service to many other hosts.
-
-      The protocol standards used in the Internet layer are:
-
-      o    RFC-791 [IP:1] defines the IP protocol and gives an
-           introduction to the architecture of the Internet.
-
-      o    RFC-792 [IP:2] defines ICMP, which provides routing,
-           diagnostic and error functionality for IP.  Although ICMP
-           messages are encapsulated within IP datagrams, ICMP
-           processing is considered to be (and is typically implemented
-           as) part of the IP layer.  See Section 3.2.2.
-
-      o    RFC-950 [IP:3] defines the mandatory subnet extension to the
-           addressing architecture.
-
-      o    RFC-1112 [IP:4] defines the Internet Group Management
-           Protocol IGMP, as part of a recommended extension to hosts
-           and to the host-gateway interface to support Internet-wide
-           multicasting at the IP level.  See Section 3.2.3.
-
-           The target of an IP multicast may be an arbitrary group of
-           Internet hosts.  IP multicasting is designed as a natural
-           extension of the link-layer multicasting facilities of some
-           networks, and it provides a standard means for local access
-           to such link-layer multicasting facilities.
-
-      Other important references are listed in Section 5 of this
-      document.
-
-      The Internet layer of host software MUST implement both IP and
-      ICMP.  See Section 3.3.7 for the requirements on support of IGMP.
-
-      The host IP layer has two basic functions:  (1) choose the "next
-      hop" gateway or host for outgoing IP datagrams and (2) reassemble
-      incoming IP datagrams.  The IP layer may also (3) implement
-      intentional fragmentation of outgoing datagrams.  Finally, the IP
-      layer must (4) provide diagnostic and error functionality.  We
-      expect that IP layer functions may increase somewhat in the
-      future, as further Internet control and management facilities are
-      developed.
-
-
-
-Internet Engineering Task Force                                [Page 27]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-      For normal datagrams, the processing is straightforward.  For
-      incoming datagrams, the IP layer:
-
-      (1)  verifies that the datagram is correctly formatted;
-
-      (2)  verifies that it is destined to the local host;
-
-      (3)  processes options;
-
-      (4)  reassembles the datagram if necessary; and
-
-      (5)  passes the encapsulated message to the appropriate
-           transport-layer protocol module.
-
-      For outgoing datagrams, the IP layer:
-
-      (1)  sets any fields not set by the transport layer;
-
-      (2)  selects the correct first hop on the connected network (a
-           process called "routing");
-
-      (3)  fragments the datagram if necessary and if intentional
-           fragmentation is implemented (see Section 3.3.3); and
-
-      (4)  passes the packet(s) to the appropriate link-layer driver.
-
-
-      A host is said to be multihomed if it has multiple IP addresses.
-      Multihoming introduces considerable confusion and complexity into
-      the protocol suite, and it is an area in which the Internet
-      architecture falls seriously short of solving all problems.  There
-      are two distinct problem areas in multihoming:
-
-      (1)  Local multihoming --  the host itself is multihomed; or
-
-      (2)  Remote multihoming -- the local host needs to communicate
-           with a remote multihomed host.
-
-      At present, remote multihoming MUST be handled at the application
-      layer, as discussed in the companion RFC [INTRO:1].  A host MAY
-      support local multihoming, which is discussed in this document,
-      and in particular in Section 3.3.4.
-
-      Any host that forwards datagrams generated by another host is
-      acting as a gateway and MUST also meet the specifications laid out
-      in the gateway requirements RFC [INTRO:2].  An Internet host that
-      includes embedded gateway code MUST have a configuration switch to
-      disable the gateway function, and this switch MUST default to the
-
-
-
-Internet Engineering Task Force                                [Page 28]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-      non-gateway mode.  In this mode, a datagram arriving through one
-      interface will not be forwarded to another host or gateway (unless
-      it is source-routed), regardless of whether the host is single-
-      homed or multihomed.  The host software MUST NOT automatically
-      move into gateway mode if the host has more than one interface, as
-      the operator of the machine may neither want to provide that
-      service nor be competent to do so.
-
-      In the following, the action specified in certain cases is to
-      "silently discard" a received datagram.  This means that the
-      datagram will be discarded without further processing and that the
-      host will not send any ICMP error message (see Section 3.2.2) as a
-      result.  However, for diagnosis of problems a host SHOULD provide
-      the capability of logging the error (see Section 1.2.3), including
-      the contents of the silently-discarded datagram, and SHOULD record
-      the event in a statistics counter.
-
-      DISCUSSION:
-           Silent discard of erroneous datagrams is generally intended
-           to prevent "broadcast storms".
-
-   3.2  PROTOCOL WALK-THROUGH
-
-      3.2.1 Internet Protocol -- IP
-
-         3.2.1.1  Version Number: RFC-791 Section 3.1
-
-            A datagram whose version number is not 4 MUST be silently
-            discarded.
-
-         3.2.1.2  Checksum: RFC-791 Section 3.1
-
-            A host MUST verify the IP header checksum on every received
-            datagram and silently discard every datagram that has a bad
-            checksum.
-
-         3.2.1.3  Addressing: RFC-791 Section 3.2
-
-            There are now five classes of IP addresses: Class A through
-            Class E.  Class D addresses are used for IP multicasting
-            [IP:4], while Class E addresses are reserved for
-            experimental use.
-
-            A multicast (Class D) address is a 28-bit logical address
-            that stands for a group of hosts, and may be either
-            permanent or transient.  Permanent multicast addresses are
-            allocated by the Internet Assigned Number Authority
-            [INTRO:6], while transient addresses may be allocated
-
-
-
-Internet Engineering Task Force                                [Page 29]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-            dynamically to transient groups.  Group membership is
-            determined dynamically using IGMP [IP:4].
-
-            We now summarize the important special cases for Class A, B,
-            and C IP addresses, using the following notation for an IP
-            address:
-
-                { <Network-number>, <Host-number> }
-
-            or
-                { <Network-number>, <Subnet-number>, <Host-number> }
-
-            and the notation "-1" for a field that contains all 1 bits.
-            This notation is not intended to imply that the 1-bits in an
-            address mask need be contiguous.
-
-            (a)  { 0, 0 }
-
-                 This host on this network.  MUST NOT be sent, except as
-                 a source address as part of an initialization procedure
-                 by which the host learns its own IP address.
-
-                 See also Section 3.3.6 for a non-standard use of {0,0}.
-
-            (b)  { 0, <Host-number> }
-
-                 Specified host on this network.  It MUST NOT be sent,
-                 except as a source address as part of an initialization
-                 procedure by which the host learns its full IP address.
-
-            (c)  { -1, -1 }
-
-                 Limited broadcast.  It MUST NOT be used as a source
-                 address.
-
-                 A datagram with this destination address will be
-                 received by every host on the connected physical
-                 network but will not be forwarded outside that network.
-
-            (d)  { <Network-number>, -1 }
-
-                 Directed broadcast to the specified network.  It MUST
-                 NOT be used as a source address.
-
-            (e)  { <Network-number>, <Subnet-number>, -1 }
-
-                 Directed broadcast to the specified subnet.  It MUST
-                 NOT be used as a source address.
-
-
-
-Internet Engineering Task Force                                [Page 30]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-            (f)  { <Network-number>, -1, -1 }
-
-                 Directed broadcast to all subnets of the specified
-                 subnetted network.  It MUST NOT be used as a source
-                 address.
-
-            (g)  { 127, <any> }
-
-                 Internal host loopback address.  Addresses of this form
-                 MUST NOT appear outside a host.
-
-            The <Network-number> is administratively assigned so that
-            its value will be unique in the entire world.
-
-            IP addresses are not permitted to have the value 0 or -1 for
-            any of the <Host-number>, <Network-number>, or <Subnet-
-            number> fields (except in the special cases listed above).
-            This implies that each of these fields will be at least two
-            bits long.
-
-            For further discussion of broadcast addresses, see Section
-            3.3.6.
-
-            A host MUST support the subnet extensions to IP [IP:3].  As
-            a result, there will be an address mask of the form:
-            {-1, -1, 0} associated with each of the host's local IP
-            addresses; see Sections 3.2.2.9 and 3.3.1.1.
-
-            When a host sends any datagram, the IP source address MUST
-            be one of its own IP addresses (but not a broadcast or
-            multicast address).
-
-            A host MUST silently discard an incoming datagram that is
-            not destined for the host.  An incoming datagram is destined
-            for the host if the datagram's destination address field is:
-
-            (1)  (one of) the host's IP address(es); or
-
-            (2)  an IP broadcast address valid for the connected
-                 network; or
-
-            (3)  the address for a multicast group of which the host is
-                 a member on the incoming physical interface.
-
-            For most purposes, a datagram addressed to a broadcast or
-            multicast destination is processed as if it had been
-            addressed to one of the host's IP addresses; we use the term
-            "specific-destination address" for the equivalent local IP
-
-
-
-Internet Engineering Task Force                                [Page 31]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-            address of the host.  The specific-destination address is
-            defined to be the destination address in the IP header
-            unless the header contains a broadcast or multicast address,
-            in which case the specific-destination is an IP address
-            assigned to the physical interface on which the datagram
-            arrived.
-
-            A host MUST silently discard an incoming datagram containing
-            an IP source address that is invalid by the rules of this
-            section.  This validation could be done in either the IP
-            layer or by each protocol in the transport layer.
-
-            DISCUSSION:
-                 A mis-addressed datagram might be caused by a link-
-                 layer broadcast of a unicast datagram or by a gateway
-                 or host that is confused or mis-configured.
-
-                 An architectural goal for Internet hosts was to allow
-                 IP addresses to be featureless 32-bit numbers, avoiding
-                 algorithms that required a knowledge of the IP address
-                 format.  Otherwise, any future change in the format or
-                 interpretation of IP addresses will require host
-                 software changes.  However, validation of broadcast and
-                 multicast addresses violates this goal; a few other
-                 violations are described elsewhere in this document.
-
-                 Implementers should be aware that applications
-                 depending upon the all-subnets directed broadcast
-                 address (f) may be unusable on some networks.  All-
-                 subnets broadcast is not widely implemented in vendor
-                 gateways at present, and even when it is implemented, a
-                 particular network administration may disable it in the
-                 gateway configuration.
-
-         3.2.1.4  Fragmentation and Reassembly: RFC-791 Section 3.2
-
-            The Internet model requires that every host support
-            reassembly.  See Sections 3.3.2 and 3.3.3 for the
-            requirements on fragmentation and reassembly.
-
-         3.2.1.5  Identification: RFC-791 Section 3.2
-
-            When sending an identical copy of an earlier datagram, a
-            host MAY optionally retain the same Identification field in
-            the copy.
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 32]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-            DISCUSSION:
-                 Some Internet protocol experts have maintained that
-                 when a host sends an identical copy of an earlier
-                 datagram, the new copy should contain the same
-                 Identification value as the original.  There are two
-                 suggested advantages:  (1) if the datagrams are
-                 fragmented and some of the fragments are lost, the
-                 receiver may be able to reconstruct a complete datagram
-                 from fragments of the original and the copies; (2) a
-                 congested gateway might use the IP Identification field
-                 (and Fragment Offset) to discard duplicate datagrams
-                 from the queue.
-
-                 However, the observed patterns of datagram loss in the
-                 Internet do not favor the probability of retransmitted
-                 fragments filling reassembly gaps, while other
-                 mechanisms (e.g., TCP repacketizing upon
-                 retransmission) tend to prevent retransmission of an
-                 identical datagram [IP:9].  Therefore, we believe that
-                 retransmitting the same Identification field is not
-                 useful.  Also, a connectionless transport protocol like
-                 UDP would require the cooperation of the application
-                 programs to retain the same Identification value in
-                 identical datagrams.
-
-         3.2.1.6  Type-of-Service: RFC-791 Section 3.2
-
-            The "Type-of-Service" byte in the IP header is divided into
-            two sections:  the Precedence field (high-order 3 bits), and
-            a field that is customarily called "Type-of-Service" or
-            "TOS" (low-order 5 bits).  In this document, all references
-            to "TOS" or the "TOS field" refer to the low-order 5 bits
-            only.
-
-            The Precedence field is intended for Department of Defense
-            applications of the Internet protocols.  The use of non-zero
-            values in this field is outside the scope of this document
-            and the IP standard specification.  Vendors should consult
-            the Defense Communication Agency (DCA) for guidance on the
-            IP Precedence field and its implications for other protocol
-            layers.  However, vendors should note that the use of
-            precedence will most likely require that its value be passed
-            between protocol layers in just the same way as the TOS
-            field is passed.
-
-            The IP layer MUST provide a means for the transport layer to
-            set the TOS field of every datagram that is sent; the
-            default is all zero bits.  The IP layer SHOULD pass received
-
-
-
-Internet Engineering Task Force                                [Page 33]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-            TOS values up to the transport layer.
-
-            The particular link-layer mappings of TOS contained in RFC-
-            795 SHOULD NOT be implemented.
-
-            DISCUSSION:
-                 While the TOS field has been little used in the past,
-                 it is expected to play an increasing role in the near
-                 future.  The TOS field is expected to be used to
-                 control two aspects of gateway operations: routing and
-                 queueing algorithms.  See Section 2 of [INTRO:1] for
-                 the requirements on application programs to specify TOS
-                 values.
-
-                 The TOS field may also be mapped into link-layer
-                 service selectors.  This has been applied to provide
-                 effective sharing of serial lines by different classes
-                 of TCP traffic, for example.  However, the mappings
-                 suggested in RFC-795 for networks that were included in
-                 the Internet as of 1981 are now obsolete.
-
-         3.2.1.7  Time-to-Live: RFC-791 Section 3.2
-
-            A host MUST NOT send a datagram with a Time-to-Live (TTL)
-            value of zero.
-
-            A host MUST NOT discard a datagram just because it was
-            received with TTL less than 2.
-
-            The IP layer MUST provide a means for the transport layer to
-            set the TTL field of every datagram that is sent.  When a
-            fixed TTL value is used, it MUST be configurable.  The
-            current suggested value will be published in the "Assigned
-            Numbers" RFC.
-
-            DISCUSSION:
-                 The TTL field has two functions: limit the lifetime of
-                 TCP segments (see RFC-793 [TCP:1], p. 28), and
-                 terminate Internet routing loops.  Although TTL is a
-                 time in seconds, it also has some attributes of a hop-
-                 count, since each gateway is required to reduce the TTL
-                 field by at least one.
-
-                 The intent is that TTL expiration will cause a datagram
-                 to be discarded by a gateway but not by the destination
-                 host; however, hosts that act as gateways by forwarding
-                 datagrams must follow the gateway rules for TTL.
-
-
-
-
-Internet Engineering Task Force                                [Page 34]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                 A higher-layer protocol may want to set the TTL in
-                 order to implement an "expanding scope" search for some
-                 Internet resource.  This is used by some diagnostic
-                 tools, and is expected to be useful for locating the
-                 "nearest" server of a given class using IP
-                 multicasting, for example.  A particular transport
-                 protocol may also want to specify its own TTL bound on
-                 maximum datagram lifetime.
-
-                 A fixed value must be at least big enough for the
-                 Internet "diameter," i.e., the longest possible path.
-                 A reasonable value is about twice the diameter, to
-                 allow for continued Internet growth.
-
-         3.2.1.8  Options: RFC-791 Section 3.2
-
-            There MUST be a means for the transport layer to specify IP
-            options to be included in transmitted IP datagrams (see
-            Section 3.4).
-
-            All IP options (except NOP or END-OF-LIST) received in
-            datagrams MUST be passed to the transport layer (or to ICMP
-            processing when the datagram is an ICMP message).  The IP
-            and transport layer MUST each interpret those IP options
-            that they understand and silently ignore the others.
-
-            Later sections of this document discuss specific IP option
-            support required by each of ICMP, TCP, and UDP.
-
-            DISCUSSION:
-                 Passing all received IP options to the transport layer
-                 is a deliberate "violation of strict layering" that is
-                 designed to ease the introduction of new transport-
-                 relevant IP options in the future.  Each layer must
-                 pick out any options that are relevant to its own
-                 processing and ignore the rest.  For this purpose,
-                 every IP option except NOP and END-OF-LIST will include
-                 a specification of its own length.
-
-                 This document does not define the order in which a
-                 receiver must process multiple options in the same IP
-                 header.  Hosts sending multiple options must be aware
-                 that this introduces an ambiguity in the meaning of
-                 certain options when combined with a source-route
-                 option.
-
-            IMPLEMENTATION:
-                 The IP layer must not crash as the result of an option
-
-
-
-Internet Engineering Task Force                                [Page 35]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                 length that is outside the possible range.  For
-                 example, erroneous option lengths have been observed to
-                 put some IP implementations into infinite loops.
-
-            Here are the requirements for specific IP options:
-
-
-            (a)  Security Option
-
-                 Some environments require the Security option in every
-                 datagram; such a requirement is outside the scope of
-                 this document and the IP standard specification.  Note,
-                 however, that the security options described in RFC-791
-                 and RFC-1038 are obsolete.  For DoD applications,
-                 vendors should consult [IP:8] for guidance.
-
-
-            (b)  Stream Identifier Option
-
-                 This option is obsolete; it SHOULD NOT be sent, and it
-                 MUST be silently ignored if received.
-
-
-            (c)  Source Route Options
-
-                 A host MUST support originating a source route and MUST
-                 be able to act as the final destination of a source
-                 route.
-
-                 If host receives a datagram containing a completed
-                 source route (i.e., the pointer points beyond the last
-                 field), the datagram has reached its final destination;
-                 the option as received (the recorded route) MUST be
-                 passed up to the transport layer (or to ICMP message
-                 processing).  This recorded route will be reversed and
-                 used to form a return source route for reply datagrams
-                 (see discussion of IP Options in Section 4).  When a
-                 return source route is built, it MUST be correctly
-                 formed even if the recorded route included the source
-                 host (see case (B) in the discussion below).
-
-                 An IP header containing more than one Source Route
-                 option MUST NOT be sent; the effect on routing of
-                 multiple Source Route options is implementation-
-                 specific.
-
-                 Section 3.3.5 presents the rules for a host acting as
-                 an intermediate hop in a source route, i.e., forwarding
-
-
-
-Internet Engineering Task Force                                [Page 36]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                 a source-routed datagram.
-
-                 DISCUSSION:
-                      If a source-routed datagram is fragmented, each
-                      fragment will contain a copy of the source route.
-                      Since the processing of IP options (including a
-                      source route) must precede reassembly, the
-                      original datagram will not be reassembled until
-                      the final destination is reached.
-
-                      Suppose a source routed datagram is to be routed
-                      from host S to host D via gateways G1, G2, ... Gn.
-                      There was an ambiguity in the specification over
-                      whether the source route option in a datagram sent
-                      out by S should be (A) or (B):
-
-                          (A):  {>>G2, G3, ... Gn, D}     <--- CORRECT
-
-                          (B):  {S, >>G2, G3, ... Gn, D}  <---- WRONG
-
-                      (where >> represents the pointer).  If (A) is
-                      sent, the datagram received at D will contain the
-                      option: {G1, G2, ... Gn >>}, with S and D as the
-                      IP source and destination addresses.  If (B) were
-                      sent, the datagram received at D would again
-                      contain S and D as the same IP source and
-                      destination addresses, but the option would be:
-                      {S, G1, ...Gn >>}; i.e., the originating host
-                      would be the first hop in the route.
-
-
-            (d)  Record Route Option
-
-                 Implementation of originating and processing the Record
-                 Route option is OPTIONAL.
-
-
-            (e)  Timestamp Option
-
-                 Implementation of originating and processing the
-                 Timestamp option is OPTIONAL.  If it is implemented,
-                 the following rules apply:
-
-                 o    The originating host MUST record a timestamp in a
-                      Timestamp option whose Internet address fields are
-                      not pre-specified or whose first pre-specified
-                      address is the host's interface address.
-
-
-
-
-Internet Engineering Task Force                                [Page 37]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                 o    The destination host MUST (if possible) add the
-                      current timestamp to a Timestamp option before
-                      passing the option to the transport layer or to
-                      ICMP for processing.
-
-                 o    A timestamp value MUST follow the rules given in
-                      Section 3.2.2.8 for the ICMP Timestamp message.
-
-
-      3.2.2 Internet Control Message Protocol -- ICMP
-
-         ICMP messages are grouped into two classes.
-
-         *
-              ICMP error messages:
-
-               Destination Unreachable   (see Section 3.2.2.1)
-               Redirect                  (see Section 3.2.2.2)
-               Source Quench             (see Section 3.2.2.3)
-               Time Exceeded             (see Section 3.2.2.4)
-               Parameter Problem         (see Section 3.2.2.5)
-
-
-         *
-              ICMP query messages:
-
-                Echo                     (see Section 3.2.2.6)
-                Information              (see Section 3.2.2.7)
-                Timestamp                (see Section 3.2.2.8)
-                Address Mask             (see Section 3.2.2.9)
-
-
-         If an ICMP message of unknown type is received, it MUST be
-         silently discarded.
-
-         Every ICMP error message includes the Internet header and at
-         least the first 8 data octets of the datagram that triggered
-         the error; more than 8 octets MAY be sent; this header and data
-         MUST be unchanged from the received datagram.
-
-         In those cases where the Internet layer is required to pass an
-         ICMP error message to the transport layer, the IP protocol
-         number MUST be extracted from the original header and used to
-         select the appropriate transport protocol entity to handle the
-         error.
-
-         An ICMP error message SHOULD be sent with normal (i.e., zero)
-         TOS bits.
-
-
-
-Internet Engineering Task Force                                [Page 38]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-         An ICMP error message MUST NOT be sent as the result of
-         receiving:
-
-         *    an ICMP error message, or
-
-         *    a datagram destined to an IP broadcast or IP multicast
-              address, or
-
-         *    a datagram sent as a link-layer broadcast, or
-
-         *    a non-initial fragment, or
-
-         *    a datagram whose source address does not define a single
-              host -- e.g., a zero address, a loopback address, a
-              broadcast address, a multicast address, or a Class E
-              address.
-
-         NOTE: THESE RESTRICTIONS TAKE PRECEDENCE OVER ANY REQUIREMENT
-         ELSEWHERE IN THIS DOCUMENT FOR SENDING ICMP ERROR MESSAGES.
-
-         DISCUSSION:
-              These rules will prevent the "broadcast storms" that have
-              resulted from hosts returning ICMP error messages in
-              response to broadcast datagrams.  For example, a broadcast
-              UDP segment to a non-existent port could trigger a flood
-              of ICMP Destination Unreachable datagrams from all
-              machines that do not have a client for that destination
-              port.  On a large Ethernet, the resulting collisions can
-              render the network useless for a second or more.
-
-              Every datagram that is broadcast on the connected network
-              should have a valid IP broadcast address as its IP
-              destination (see Section 3.3.6).  However, some hosts
-              violate this rule.  To be certain to detect broadcast
-              datagrams, therefore, hosts are required to check for a
-              link-layer broadcast as well as an IP-layer broadcast
-              address.
-
-         IMPLEMENTATION:
-              This requires that the link layer inform the IP layer when
-              a link-layer broadcast datagram has been received; see
-              Section 2.4.
-
-         3.2.2.1  Destination Unreachable: RFC-792
-
-            The following additional codes are hereby defined:
-
-                    6 = destination network unknown
-
-
-
-Internet Engineering Task Force                                [Page 39]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                    7 = destination host unknown
-
-                    8 = source host isolated
-
-                    9 = communication with destination network
-                            administratively prohibited
-
-                   10 = communication with destination host
-                            administratively prohibited
-
-                   11 = network unreachable for type of service
-
-                   12 = host unreachable for type of service
-
-            A host SHOULD generate Destination Unreachable messages with
-            code:
-
-            2    (Protocol Unreachable), when the designated transport
-                 protocol is not supported; or
-
-            3    (Port Unreachable), when the designated transport
-                 protocol (e.g., UDP) is unable to demultiplex the
-                 datagram but has no protocol mechanism to inform the
-                 sender.
-
-            A Destination Unreachable message that is received MUST be
-            reported to the transport layer.  The transport layer SHOULD
-            use the information appropriately; for example, see Sections
-            4.1.3.3, 4.2.3.9, and 4.2.4 below.  A transport protocol
-            that has its own mechanism for notifying the sender that a
-            port is unreachable (e.g., TCP, which sends RST segments)
-            MUST nevertheless accept an ICMP Port Unreachable for the
-            same purpose.
-
-            A Destination Unreachable message that is received with code
-            0 (Net), 1 (Host), or 5 (Bad Source Route) may result from a
-            routing transient and MUST therefore be interpreted as only
-            a hint, not proof, that the specified destination is
-            unreachable [IP:11].  For example, it MUST NOT be used as
-            proof of a dead gateway (see Section 3.3.1).
-
-         3.2.2.2  Redirect: RFC-792
-
-            A host SHOULD NOT send an ICMP Redirect message; Redirects
-            are to be sent only by gateways.
-
-            A host receiving a Redirect message MUST update its routing
-            information accordingly.  Every host MUST be prepared to
-
-
-
-Internet Engineering Task Force                                [Page 40]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-            accept both Host and Network Redirects and to process them
-            as described in Section 3.3.1.2 below.
-
-            A Redirect message SHOULD be silently discarded if the new
-            gateway address it specifies is not on the same connected
-            (sub-) net through which the Redirect arrived [INTRO:2,
-            Appendix A], or if the source of the Redirect is not the
-            current first-hop gateway for the specified destination (see
-            Section 3.3.1).
-
-         3.2.2.3  Source Quench: RFC-792
-
-            A host MAY send a Source Quench message if it is
-            approaching, or has reached, the point at which it is forced
-            to discard incoming datagrams due to a shortage of
-            reassembly buffers or other resources.  See Section 2.2.3 of
-            [INTRO:2] for suggestions on when to send Source Quench.
-
-            If a Source Quench message is received, the IP layer MUST
-            report it to the transport layer (or ICMP processing). In
-            general, the transport or application layer SHOULD implement
-            a mechanism to respond to Source Quench for any protocol
-            that can send a sequence of datagrams to the same
-            destination and which can reasonably be expected to maintain
-            enough state information to make this feasible.  See Section
-            4 for the handling of Source Quench by TCP and UDP.
-
-            DISCUSSION:
-                 A Source Quench may be generated by the target host or
-                 by some gateway in the path of a datagram.  The host
-                 receiving a Source Quench should throttle itself back
-                 for a period of time, then gradually increase the
-                 transmission rate again.  The mechanism to respond to
-                 Source Quench may be in the transport layer (for
-                 connection-oriented protocols like TCP) or in the
-                 application layer (for protocols that are built on top
-                 of UDP).
-
-                 A mechanism has been proposed [IP:14] to make the IP
-                 layer respond directly to Source Quench by controlling
-                 the rate at which datagrams are sent, however, this
-                 proposal is currently experimental and not currently
-                 recommended.
-
-         3.2.2.4  Time Exceeded: RFC-792
-
-            An incoming Time Exceeded message MUST be passed to the
-            transport layer.
-
-
-
-Internet Engineering Task Force                                [Page 41]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-            DISCUSSION:
-                 A gateway will send a Time Exceeded Code 0 (In Transit)
-                 message when it discards a datagram due to an expired
-                 TTL field.  This indicates either a gateway routing
-                 loop or too small an initial TTL value.
-
-                 A host may receive a Time Exceeded Code 1 (Reassembly
-                 Timeout) message from a destination host that has timed
-                 out and discarded an incomplete datagram; see Section
-                 3.3.2 below.  In the future, receipt of this message
-                 might be part of some "MTU discovery" procedure, to
-                 discover the maximum datagram size that can be sent on
-                 the path without fragmentation.
-
-         3.2.2.5  Parameter Problem: RFC-792
-
-            A host SHOULD generate Parameter Problem messages.  An
-            incoming Parameter Problem message MUST be passed to the
-            transport layer, and it MAY be reported to the user.
-
-            DISCUSSION:
-                 The ICMP Parameter Problem message is sent to the
-                 source host for any problem not specifically covered by
-                 another ICMP message.  Receipt of a Parameter Problem
-                 message generally indicates some local or remote
-                 implementation error.
-
-            A new variant on the Parameter Problem message is hereby
-            defined:
-              Code 1 = required option is missing.
-
-            DISCUSSION:
-                 This variant is currently in use in the military
-                 community for a missing security option.
-
-         3.2.2.6  Echo Request/Reply: RFC-792
-
-            Every host MUST implement an ICMP Echo server function that
-            receives Echo Requests and sends corresponding Echo Replies.
-            A host SHOULD also implement an application-layer interface
-            for sending an Echo Request and receiving an Echo Reply, for
-            diagnostic purposes.
-
-            An ICMP Echo Request destined to an IP broadcast or IP
-            multicast address MAY be silently discarded.
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 42]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-            DISCUSSION:
-                 This neutral provision results from a passionate debate
-                 between those who feel that ICMP Echo to a broadcast
-                 address provides a valuable diagnostic capability and
-                 those who feel that misuse of this feature can too
-                 easily create packet storms.
-
-            The IP source address in an ICMP Echo Reply MUST be the same
-            as the specific-destination address (defined in Section
-            3.2.1.3) of the corresponding ICMP Echo Request message.
-
-            Data received in an ICMP Echo Request MUST be entirely
-            included in the resulting Echo Reply.  However, if sending
-            the Echo Reply requires intentional fragmentation that is
-            not implemented, the datagram MUST be truncated to maximum
-            transmission size (see Section 3.3.3) and sent.
-
-            Echo Reply messages MUST be passed to the ICMP user
-            interface, unless the corresponding Echo Request originated
-            in the IP layer.
-
-            If a Record Route and/or Time Stamp option is received in an
-            ICMP Echo Request, this option (these options) SHOULD be
-            updated to include the current host and included in the IP
-            header of the Echo Reply message, without "truncation".
-            Thus, the recorded route will be for the entire round trip.
-
-            If a Source Route option is received in an ICMP Echo
-            Request, the return route MUST be reversed and used as a
-            Source Route option for the Echo Reply message.
-
-         3.2.2.7  Information Request/Reply: RFC-792
-
-            A host SHOULD NOT implement these messages.
-
-            DISCUSSION:
-                 The Information Request/Reply pair was intended to
-                 support self-configuring systems such as diskless
-                 workstations, to allow them to discover their IP
-                 network numbers at boot time.  However, the RARP and
-                 BOOTP protocols provide better mechanisms for a host to
-                 discover its own IP address.
-
-         3.2.2.8  Timestamp and Timestamp Reply: RFC-792
-
-            A host MAY implement Timestamp and Timestamp Reply.  If they
-            are implemented, the following rules MUST be followed.
-
-
-
-
-Internet Engineering Task Force                                [Page 43]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-            o    The ICMP Timestamp server function returns a Timestamp
-                 Reply to every Timestamp message that is received.  If
-                 this function is implemented, it SHOULD be designed for
-                 minimum variability in delay (e.g., implemented in the
-                 kernel to avoid delay in scheduling a user process).
-
-            The following cases for Timestamp are to be handled
-            according to the corresponding rules for ICMP Echo:
-
-            o    An ICMP Timestamp Request message to an IP broadcast or
-                 IP multicast address MAY be silently discarded.
-
-            o    The IP source address in an ICMP Timestamp Reply MUST
-                 be the same as the specific-destination address of the
-                 corresponding Timestamp Request message.
-
-            o    If a Source-route option is received in an ICMP Echo
-                 Request, the return route MUST be reversed and used as
-                 a Source Route option for the Timestamp Reply message.
-
-            o    If a Record Route and/or Timestamp option is received
-                 in a Timestamp Request, this (these) option(s) SHOULD
-                 be updated to include the current host and included in
-                 the IP header of the Timestamp Reply message.
-
-            o    Incoming Timestamp Reply messages MUST be passed up to
-                 the ICMP user interface.
-
-            The preferred form for a timestamp value (the "standard
-            value") is in units of milliseconds since midnight Universal
-            Time.  However, it may be difficult to provide this value
-            with millisecond resolution.  For example, many systems use
-            clocks that update only at line frequency, 50 or 60 times
-            per second.  Therefore, some latitude is allowed in a
-            "standard value":
-
-            (a)  A "standard value" MUST be updated at least 15 times
-                 per second (i.e., at most the six low-order bits of the
-                 value may be undefined).
-
-            (b)  The accuracy of a "standard value" MUST approximate
-                 that of operator-set CPU clocks, i.e., correct within a
-                 few minutes.
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 44]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-         3.2.2.9  Address Mask Request/Reply: RFC-950
-
-            A host MUST support the first, and MAY implement all three,
-            of the following methods for determining the address mask(s)
-            corresponding to its IP address(es):
-
-            (1)  static configuration information;
-
-            (2)  obtaining the address mask(s) dynamically as a side-
-                 effect of the system initialization process (see
-                 [INTRO:1]); and
-
-            (3)  sending ICMP Address Mask Request(s) and receiving ICMP
-                 Address Mask Reply(s).
-
-            The choice of method to be used in a particular host MUST be
-            configurable.
-
-            When method (3), the use of Address Mask messages, is
-            enabled, then:
-
-            (a)  When it initializes, the host MUST broadcast an Address
-                 Mask Request message on the connected network
-                 corresponding to the IP address.  It MUST retransmit
-                 this message a small number of times if it does not
-                 receive an immediate Address Mask Reply.
-
-            (b)  Until it has received an Address Mask Reply, the host
-                 SHOULD assume a mask appropriate for the address class
-                 of the IP address, i.e., assume that the connected
-                 network is not subnetted.
-
-            (c)  The first Address Mask Reply message received MUST be
-                 used to set the address mask corresponding to the
-                 particular local IP address.  This is true even if the
-                 first Address Mask Reply message is "unsolicited", in
-                 which case it will have been broadcast and may arrive
-                 after the host has ceased to retransmit Address Mask
-                 Requests.  Once the mask has been set by an Address
-                 Mask Reply, later Address Mask Reply messages MUST be
-                 (silently) ignored.
-
-            Conversely, if Address Mask messages are disabled, then no
-            ICMP Address Mask Requests will be sent, and any ICMP
-            Address Mask Replies received for that local IP address MUST
-            be (silently) ignored.
-
-            A host SHOULD make some reasonableness check on any address
-
-
-
-Internet Engineering Task Force                                [Page 45]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-            mask it installs; see IMPLEMENTATION section below.
-
-            A system MUST NOT send an Address Mask Reply unless it is an
-            authoritative agent for address masks.  An authoritative
-            agent may be a host or a gateway, but it MUST be explicitly
-            configured as a address mask agent.  Receiving an address
-            mask via an Address Mask Reply does not give the receiver
-            authority and MUST NOT be used as the basis for issuing
-            Address Mask Replies.
-
-            With a statically configured address mask, there SHOULD be
-            an additional configuration flag that determines whether the
-            host is to act as an authoritative agent for this mask,
-            i.e., whether it will answer Address Mask Request messages
-            using this mask.
-
-            If it is configured as an agent, the host MUST broadcast an
-            Address Mask Reply for the mask on the appropriate interface
-            when it initializes.
-
-            See "System Initialization" in [INTRO:1] for more
-            information about the use of Address Mask Request/Reply
-            messages.
-
-            DISCUSSION
-                 Hosts that casually send Address Mask Replies with
-                 invalid address masks have often been a serious
-                 nuisance.  To prevent this, Address Mask Replies ought
-                 to be sent only by authoritative agents that have been
-                 selected by explicit administrative action.
-
-                 When an authoritative agent receives an Address Mask
-                 Request message, it will send a unicast Address Mask
-                 Reply to the source IP address.  If the network part of
-                 this address is zero (see (a) and (b) in 3.2.1.3), the
-                 Reply will be broadcast.
-
-                 Getting no reply to its Address Mask Request messages,
-                 a host will assume there is no agent and use an
-                 unsubnetted mask, but the agent may be only temporarily
-                 unreachable.  An agent will broadcast an unsolicited
-                 Address Mask Reply whenever it initializes, in order to
-                 update the masks of all hosts that have initialized in
-                 the meantime.
-
-            IMPLEMENTATION:
-                 The following reasonableness check on an address mask
-                 is suggested: the mask is not all 1 bits, and it is
-
-
-
-Internet Engineering Task Force                                [Page 46]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                 either zero or else the 8 highest-order bits are on.
-
-      3.2.3  Internet Group Management Protocol IGMP
-
-         IGMP [IP:4] is a protocol used between hosts and gateways on a
-         single network to establish hosts' membership in particular
-         multicast groups.  The gateways use this information, in
-         conjunction with a multicast routing protocol, to support IP
-         multicasting across the Internet.
-
-         At this time, implementation of IGMP is OPTIONAL; see Section
-         3.3.7 for more information.  Without IGMP, a host can still
-         participate in multicasting local to its connected networks.
-
-   3.3  SPECIFIC ISSUES
-
-      3.3.1  Routing Outbound Datagrams
-
-         The IP layer chooses the correct next hop for each datagram it
-         sends.  If the destination is on a connected network, the
-         datagram is sent directly to the destination host; otherwise,
-         it has to be routed to a gateway on a connected network.
-
-         3.3.1.1  Local/Remote Decision
-
-            To decide if the destination is on a connected network, the
-            following algorithm MUST be used [see IP:3]:
-
-            (a)  The address mask (particular to a local IP address for
-                 a multihomed host) is a 32-bit mask that selects the
-                 network number and subnet number fields of the
-                 corresponding IP address.
-
-            (b)  If the IP destination address bits extracted by the
-                 address mask match the IP source address bits extracted
-                 by the same mask, then the destination is on the
-                 corresponding connected network, and the datagram is to
-                 be transmitted directly to the destination host.
-
-            (c)  If not, then the destination is accessible only through
-                 a gateway.  Selection of a gateway is described below
-                 (3.3.1.2).
-
-            A special-case destination address is handled as follows:
-
-            *    For a limited broadcast or a multicast address, simply
-                 pass the datagram to the link layer for the appropriate
-                 interface.
-
-
-
-Internet Engineering Task Force                                [Page 47]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-            *    For a (network or subnet) directed broadcast, the
-                 datagram can use the standard routing algorithms.
-
-            The host IP layer MUST operate correctly in a minimal
-            network environment, and in particular, when there are no
-            gateways.  For example, if the IP layer of a host insists on
-            finding at least one gateway to initialize, the host will be
-            unable to operate on a single isolated broadcast net.
-
-         3.3.1.2  Gateway Selection
-
-            To efficiently route a series of datagrams to the same
-            destination, the source host MUST keep a "route cache" of
-            mappings to next-hop gateways.  A host uses the following
-            basic algorithm on this cache to route a datagram; this
-            algorithm is designed to put the primary routing burden on
-            the gateways [IP:11].
-
-            (a)  If the route cache contains no information for a
-                 particular destination, the host chooses a "default"
-                 gateway and sends the datagram to it.  It also builds a
-                 corresponding Route Cache entry.
-
-            (b)  If that gateway is not the best next hop to the
-                 destination, the gateway will forward the datagram to
-                 the best next-hop gateway and return an ICMP Redirect
-                 message to the source host.
-
-            (c)  When it receives a Redirect, the host updates the
-                 next-hop gateway in the appropriate route cache entry,
-                 so later datagrams to the same destination will go
-                 directly to the best gateway.
-
-            Since the subnet mask appropriate to the destination address
-            is generally not known, a Network Redirect message SHOULD be
-            treated identically to a Host Redirect message; i.e., the
-            cache entry for the destination host (only) would be updated
-            (or created, if an entry for that host did not exist) for
-            the new gateway.
-
-            DISCUSSION:
-                 This recommendation is to protect against gateways that
-                 erroneously send Network Redirects for a subnetted
-                 network, in violation of the gateway requirements
-                 [INTRO:2].
-
-            When there is no route cache entry for the destination host
-            address (and the destination is not on the connected
-
-
-
-Internet Engineering Task Force                                [Page 48]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-            network), the IP layer MUST pick a gateway from its list of
-            "default" gateways.  The IP layer MUST support multiple
-            default gateways.
-
-            As an extra feature, a host IP layer MAY implement a table
-            of "static routes".  Each such static route MAY include a
-            flag specifying whether it may be overridden by ICMP
-            Redirects.
-
-            DISCUSSION:
-                 A host generally needs to know at least one default
-                 gateway to get started.  This information can be
-                 obtained from a configuration file or else from the
-                 host startup sequence, e.g., the BOOTP protocol (see
-                 [INTRO:1]).
-
-                 It has been suggested that a host can augment its list
-                 of default gateways by recording any new gateways it
-                 learns about.  For example, it can record every gateway
-                 to which it is ever redirected.  Such a feature, while
-                 possibly useful in some circumstances, may cause
-                 problems in other cases (e.g., gateways are not all
-                 equal), and it is not recommended.
-
-                 A static route is typically a particular preset mapping
-                 from destination host or network into a particular
-                 next-hop gateway; it might also depend on the Type-of-
-                 Service (see next section).  Static routes would be set
-                 up by system administrators to override the normal
-                 automatic routing mechanism, to handle exceptional
-                 situations.  However, any static routing information is
-                 a potential source of failure as configurations change
-                 or equipment fails.
-
-         3.3.1.3  Route Cache
-
-            Each route cache entry needs to include the following
-            fields:
-
-            (1)  Local IP address (for a multihomed host)
-
-            (2)  Destination IP address
-
-            (3)  Type(s)-of-Service
-
-            (4)  Next-hop gateway IP address
-
-            Field (2) MAY be the full IP address of the destination
-
-
-
-Internet Engineering Task Force                                [Page 49]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-            host, or only the destination network number.  Field (3),
-            the TOS, SHOULD be included.
-
-            See Section 3.3.4.2 for a discussion of the implications of
-            multihoming for the lookup procedure in this cache.
-
-            DISCUSSION:
-                 Including the Type-of-Service field in the route cache
-                 and considering it in the host route algorithm will
-                 provide the necessary mechanism for the future when
-                 Type-of-Service routing is commonly used in the
-                 Internet.  See Section 3.2.1.6.
-
-                 Each route cache entry defines the endpoints of an
-                 Internet path.  Although the connecting path may change
-                 dynamically in an arbitrary way, the transmission
-                 characteristics of the path tend to remain
-                 approximately constant over a time period longer than a
-                 single typical host-host transport connection.
-                 Therefore, a route cache entry is a natural place to
-                 cache data on the properties of the path.  Examples of
-                 such properties might be the maximum unfragmented
-                 datagram size (see Section 3.3.3), or the average
-                 round-trip delay measured by a transport protocol.
-                 This data will generally be both gathered and used by a
-                 higher layer protocol, e.g., by TCP, or by an
-                 application using UDP.  Experiments are currently in
-                 progress on caching path properties in this manner.
-
-                 There is no consensus on whether the route cache should
-                 be keyed on destination host addresses alone, or allow
-                 both host and network addresses.  Those who favor the
-                 use of only host addresses argue that:
-
-                 (1)  As required in Section 3.3.1.2, Redirect messages
-                      will generally result in entries keyed on
-                      destination host addresses; the simplest and most
-                      general scheme would be to use host addresses
-                      always.
-
-                 (2)  The IP layer may not always know the address mask
-                      for a network address in a complex subnetted
-                      environment.
-
-                 (3)  The use of only host addresses allows the
-                      destination address to be used as a pure 32-bit
-                      number, which may allow the Internet architecture
-                      to be more easily extended in the future without
-
-
-
-Internet Engineering Task Force                                [Page 50]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                      any change to the hosts.
-
-                 The opposing view is that allowing a mixture of
-                 destination hosts and networks in the route cache:
-
-                 (1)  Saves memory space.
-
-                 (2)  Leads to a simpler data structure, easily
-                      combining the cache with the tables of default and
-                      static routes (see below).
-
-                 (3)  Provides a more useful place to cache path
-                      properties, as discussed earlier.
-
-
-            IMPLEMENTATION:
-                 The cache needs to be large enough to include entries
-                 for the maximum number of destination hosts that may be
-                 in use at one time.
-
-                 A route cache entry may also include control
-                 information used to choose an entry for replacement.
-                 This might take the form of a "recently used" bit, a
-                 use count, or a last-used timestamp, for example.  It
-                 is recommended that it include the time of last
-                 modification of the entry, for diagnostic purposes.
-
-                 An implementation may wish to reduce the overhead of
-                 scanning the route cache for every datagram to be
-                 transmitted.  This may be accomplished with a hash
-                 table to speed the lookup, or by giving a connection-
-                 oriented transport protocol a "hint" or temporary
-                 handle on the appropriate cache entry, to be passed to
-                 the IP layer with each subsequent datagram.
-
-                 Although we have described the route cache, the lists
-                 of default gateways, and a table of static routes as
-                 conceptually distinct, in practice they may be combined
-                 into a single "routing table" data structure.
-
-         3.3.1.4  Dead Gateway Detection
-
-            The IP layer MUST be able to detect the failure of a "next-
-            hop" gateway that is listed in its route cache and to choose
-            an alternate gateway (see Section 3.3.1.5).
-
-            Dead gateway detection is covered in some detail in RFC-816
-            [IP:11]. Experience to date has not produced a complete
-
-
-
-Internet Engineering Task Force                                [Page 51]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-            algorithm which is totally satisfactory, though it has
-            identified several forbidden paths and promising techniques.
-
-            *    A particular gateway SHOULD NOT be used indefinitely in
-                 the absence of positive indications that it is
-                 functioning.
-
-            *    Active probes such as "pinging" (i.e., using an ICMP
-                 Echo Request/Reply exchange) are expensive and scale
-                 poorly.  In particular, hosts MUST NOT actively check
-                 the status of a first-hop gateway by simply pinging the
-                 gateway continuously.
-
-            *    Even when it is the only effective way to verify a
-                 gateway's status, pinging MUST be used only when
-                 traffic is being sent to the gateway and when there is
-                 no other positive indication to suggest that the
-                 gateway is functioning.
-
-            *    To avoid pinging, the layers above and/or below the
-                 Internet layer SHOULD be able to give "advice" on the
-                 status of route cache entries when either positive
-                 (gateway OK) or negative (gateway dead) information is
-                 available.
-
-
-            DISCUSSION:
-                 If an implementation does not include an adequate
-                 mechanism for detecting a dead gateway and re-routing,
-                 a gateway failure may cause datagrams to apparently
-                 vanish into a "black hole".  This failure can be
-                 extremely confusing for users and difficult for network
-                 personnel to debug.
-
-                 The dead-gateway detection mechanism must not cause
-                 unacceptable load on the host, on connected networks,
-                 or on first-hop gateway(s).  The exact constraints on
-                 the timeliness of dead gateway detection and on
-                 acceptable load may vary somewhat depending on the
-                 nature of the host's mission, but a host generally
-                 needs to detect a failed first-hop gateway quickly
-                 enough that transport-layer connections will not break
-                 before an alternate gateway can be selected.
-
-                 Passing advice from other layers of the protocol stack
-                 complicates the interfaces between the layers, but it
-                 is the preferred approach to dead gateway detection.
-                 Advice can come from almost any part of the IP/TCP
-
-
-
-Internet Engineering Task Force                                [Page 52]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                 architecture, but it is expected to come primarily from
-                 the transport and link layers.  Here are some possible
-                 sources for gateway advice:
-
-                 o    TCP or any connection-oriented transport protocol
-                      should be able to give negative advice, e.g.,
-                      triggered by excessive retransmissions.
-
-                 o    TCP may give positive advice when (new) data is
-                      acknowledged.  Even though the route may be
-                      asymmetric, an ACK for new data proves that the
-                      acknowleged data must have been transmitted
-                      successfully.
-
-                 o    An ICMP Redirect message from a particular gateway
-                      should be used as positive advice about that
-                      gateway.
-
-                 o    Link-layer information that reliably detects and
-                      reports host failures (e.g., ARPANET Destination
-                      Dead messages) should be used as negative advice.
-
-                 o    Failure to ARP or to re-validate ARP mappings may
-                      be used as negative advice for the corresponding
-                      IP address.
-
-                 o    Packets arriving from a particular link-layer
-                      address are evidence that the system at this
-                      address is alive.  However, turning this
-                      information into advice about gateways requires
-                      mapping the link-layer address into an IP address,
-                      and then checking that IP address against the
-                      gateways pointed to by the route cache.  This is
-                      probably prohibitively inefficient.
-
-                 Note that positive advice that is given for every
-                 datagram received may cause unacceptable overhead in
-                 the implementation.
-
-                 While advice might be passed using required arguments
-                 in all interfaces to the IP layer, some transport and
-                 application layer protocols cannot deduce the correct
-                 advice.  These interfaces must therefore allow a
-                 neutral value for advice, since either always-positive
-                 or always-negative advice leads to incorrect behavior.
-
-                 There is another technique for dead gateway detection
-                 that has been commonly used but is not recommended.
-
-
-
-Internet Engineering Task Force                                [Page 53]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                 This technique depends upon the host passively
-                 receiving ("wiretapping") the Interior Gateway Protocol
-                 (IGP) datagrams that the gateways are broadcasting to
-                 each other.  This approach has the drawback that a host
-                 needs to recognize all the interior gateway protocols
-                 that gateways may use (see [INTRO:2]).  In addition, it
-                 only works on a broadcast network.
-
-                 At present, pinging (i.e., using ICMP Echo messages) is
-                 the mechanism for gateway probing when absolutely
-                 required.  A successful ping guarantees that the
-                 addressed interface and its associated machine are up,
-                 but it does not guarantee that the machine is a gateway
-                 as opposed to a host.  The normal inference is that if
-                 a Redirect or other evidence indicates that a machine
-                 was a gateway, successful pings will indicate that the
-                 machine is still up and hence still a gateway.
-                 However, since a host silently discards packets that a
-                 gateway would forward or redirect, this assumption
-                 could sometimes fail.  To avoid this problem, a new
-                 ICMP message under development will ask "are you a
-                 gateway?"
-
-            IMPLEMENTATION:
-                 The following specific algorithm has been suggested:
-
-                 o    Associate a "reroute timer" with each gateway
-                      pointed to by the route cache.  Initialize the
-                      timer to a value Tr, which must be small enough to
-                      allow detection of a dead gateway before transport
-                      connections time out.
-
-                 o    Positive advice would reset the reroute timer to
-                      Tr.  Negative advice would reduce or zero the
-                      reroute timer.
-
-                 o    Whenever the IP layer used a particular gateway to
-                      route a datagram, it would check the corresponding
-                      reroute timer.  If the timer had expired (reached
-                      zero), the IP layer would send a ping to the
-                      gateway, followed immediately by the datagram.
-
-                 o    The ping (ICMP Echo) would be sent again if
-                      necessary, up to N times.  If no ping reply was
-                      received in N tries, the gateway would be assumed
-                      to have failed, and a new first-hop gateway would
-                      be chosen for all cache entries pointing to the
-                      failed gateway.
-
-
-
-Internet Engineering Task Force                                [Page 54]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                 Note that the size of Tr is inversely related to the
-                 amount of advice available.  Tr should be large enough
-                 to insure that:
-
-                 *    Any pinging will be at a low level (e.g., <10%) of
-                      all packets sent to a gateway from the host, AND
-
-                 *    pinging is infrequent (e.g., every 3 minutes)
-
-                 Since the recommended algorithm is concerned with the
-                 gateways pointed to by route cache entries, rather than
-                 the cache entries themselves, a two level data
-                 structure (perhaps coordinated with ARP or similar
-                 caches) may be desirable for implementing a route
-                 cache.
-
-         3.3.1.5  New Gateway Selection
-
-            If the failed gateway is not the current default, the IP
-            layer can immediately switch to a default gateway.  If it is
-            the current default that failed, the IP layer MUST select a
-            different default gateway (assuming more than one default is
-            known) for the failed route and for establishing new routes.
-
-            DISCUSSION:
-                 When a gateway does fail, the other gateways on the
-                 connected network will learn of the failure through
-                 some inter-gateway routing protocol.  However, this
-                 will not happen instantaneously, since gateway routing
-                 protocols typically have a settling time of 30-60
-                 seconds.  If the host switches to an alternative
-                 gateway before the gateways have agreed on the failure,
-                 the new target gateway will probably forward the
-                 datagram to the failed gateway and send a Redirect back
-                 to the host pointing to the failed gateway (!).  The
-                 result is likely to be a rapid oscillation in the
-                 contents of the host's route cache during the gateway
-                 settling period.  It has been proposed that the dead-
-                 gateway logic should include some hysteresis mechanism
-                 to prevent such oscillations.  However, experience has
-                 not shown any harm from such oscillations, since
-                 service cannot be restored to the host until the
-                 gateways' routing information does settle down.
-
-            IMPLEMENTATION:
-                 One implementation technique for choosing a new default
-                 gateway is to simply round-robin among the default
-                 gateways in the host's list.  Another is to rank the
-
-
-
-Internet Engineering Task Force                                [Page 55]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                 gateways in priority order, and when the current
-                 default gateway is not the highest priority one, to
-                 "ping" the higher-priority gateways slowly to detect
-                 when they return to service.  This pinging can be at a
-                 very low rate, e.g., 0.005 per second.
-
-         3.3.1.6  Initialization
-
-            The following information MUST be configurable:
-
-            (1)  IP address(es).
-
-            (2)  Address mask(s).
-
-            (3)  A list of default gateways, with a preference level.
-
-            A manual method of entering this configuration data MUST be
-            provided.  In addition, a variety of methods can be used to
-            determine this information dynamically; see the section on
-            "Host Initialization" in [INTRO:1].
-
-            DISCUSSION:
-                 Some host implementations use "wiretapping" of gateway
-                 protocols on a broadcast network to learn what gateways
-                 exist.  A standard method for default gateway discovery
-                 is under development.
-
-      3.3.2  Reassembly
-
-         The IP layer MUST implement reassembly of IP datagrams.
-
-         We designate the largest datagram size that can be reassembled
-         by EMTU_R ("Effective MTU to receive"); this is sometimes
-         called the "reassembly buffer size".  EMTU_R MUST be greater
-         than or equal to 576, SHOULD be either configurable or
-         indefinite, and SHOULD be greater than or equal to the MTU of
-         the connected network(s).
-
-         DISCUSSION:
-              A fixed EMTU_R limit should not be built into the code
-              because some application layer protocols require EMTU_R
-              values larger than 576.
-
-         IMPLEMENTATION:
-              An implementation may use a contiguous reassembly buffer
-              for each datagram, or it may use a more complex data
-              structure that places no definite limit on the reassembled
-              datagram size; in the latter case, EMTU_R is said to be
-
-
-
-Internet Engineering Task Force                                [Page 56]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-              "indefinite".
-
-              Logically, reassembly is performed by simply copying each
-              fragment into the packet buffer at the proper offset.
-              Note that fragments may overlap if successive
-              retransmissions use different packetizing but the same
-              reassembly Id.
-
-              The tricky part of reassembly is the bookkeeping to
-              determine when all bytes of the datagram have been
-              reassembled.  We recommend Clark's algorithm [IP:10] that
-              requires no additional data space for the bookkeeping.
-              However, note that, contrary to [IP:10], the first
-              fragment header needs to be saved for inclusion in a
-              possible ICMP Time Exceeded (Reassembly Timeout) message.
-
-         There MUST be a mechanism by which the transport layer can
-         learn MMS_R, the maximum message size that can be received and
-         reassembled in an IP datagram (see GET_MAXSIZES calls in
-         Section 3.4).  If EMTU_R is not indefinite, then the value of
-         MMS_R is given by:
-
-            MMS_R = EMTU_R - 20
-
-         since 20 is the minimum size of an IP header.
-
-         There MUST be a reassembly timeout.  The reassembly timeout
-         value SHOULD be a fixed value, not set from the remaining TTL.
-         It is recommended that the value lie between 60 seconds and 120
-         seconds.  If this timeout expires, the partially-reassembled
-         datagram MUST be discarded and an ICMP Time Exceeded message
-         sent to the source host (if fragment zero has been received).
-
-         DISCUSSION:
-              The IP specification says that the reassembly timeout
-              should be the remaining TTL from the IP header, but this
-              does not work well because gateways generally treat TTL as
-              a simple hop count rather than an elapsed time.  If the
-              reassembly timeout is too small, datagrams will be
-              discarded unnecessarily, and communication may fail.  The
-              timeout needs to be at least as large as the typical
-              maximum delay across the Internet.  A realistic minimum
-              reassembly timeout would be 60 seconds.
-
-              It has been suggested that a cache might be kept of
-              round-trip times measured by transport protocols for
-              various destinations, and that these values might be used
-              to dynamically determine a reasonable reassembly timeout
-
-
-
-Internet Engineering Task Force                                [Page 57]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-              value.  Further investigation of this approach is
-              required.
-
-              If the reassembly timeout is set too high, buffer
-              resources in the receiving host will be tied up too long,
-              and the MSL (Maximum Segment Lifetime) [TCP:1] will be
-              larger than necessary.  The MSL controls the maximum rate
-              at which fragmented datagrams can be sent using distinct
-              values of the 16-bit Ident field; a larger MSL lowers the
-              maximum rate.  The TCP specification [TCP:1] arbitrarily
-              assumes a value of 2 minutes for MSL.  This sets an upper
-              limit on a reasonable reassembly timeout value.
-
-      3.3.3  Fragmentation
-
-         Optionally, the IP layer MAY implement a mechanism to fragment
-         outgoing datagrams intentionally.
-
-         We designate by EMTU_S ("Effective MTU for sending") the
-         maximum IP datagram size that may be sent, for a particular
-         combination of IP source and destination addresses and perhaps
-         TOS.
-
-         A host MUST implement a mechanism to allow the transport layer
-         to learn MMS_S, the maximum transport-layer message size that
-         may be sent for a given {source, destination, TOS} triplet (see
-         GET_MAXSIZES call in Section 3.4).  If no local fragmentation
-         is performed, the value of MMS_S will be:
-
-            MMS_S = EMTU_S - <IP header size>
-
-         and EMTU_S must be less than or equal to the MTU of the network
-         interface corresponding to the source address of the datagram.
-         Note that <IP header size> in this equation will be 20, unless
-         the IP reserves space to insert IP options for its own purposes
-         in addition to any options inserted by the transport layer.
-
-         A host that does not implement local fragmentation MUST ensure
-         that the transport layer (for TCP) or the application layer
-         (for UDP) obtains MMS_S from the IP layer and does not send a
-         datagram exceeding MMS_S in size.
-
-         It is generally desirable to avoid local fragmentation and to
-         choose EMTU_S low enough to avoid fragmentation in any gateway
-         along the path.  In the absence of actual knowledge of the
-         minimum MTU along the path, the IP layer SHOULD use
-         EMTU_S <= 576 whenever the destination address is not on a
-         connected network, and otherwise use the connected network's
-
-
-
-Internet Engineering Task Force                                [Page 58]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-         MTU.
-
-         The MTU of each physical interface MUST be configurable.
-
-         A host IP layer implementation MAY have a configuration flag
-         "All-Subnets-MTU", indicating that the MTU of the connected
-         network is to be used for destinations on different subnets
-         within the same network, but not for other networks.  Thus,
-         this flag causes the network class mask, rather than the subnet
-         address mask, to be used to choose an EMTU_S.  For a multihomed
-         host, an "All-Subnets-MTU" flag is needed for each network
-         interface.
-
-         DISCUSSION:
-              Picking the correct datagram size to use when sending data
-              is a complex topic [IP:9].
-
-              (a)  In general, no host is required to accept an IP
-                   datagram larger than 576 bytes (including header and
-                   data), so a host must not send a larger datagram
-                   without explicit knowledge or prior arrangement with
-                   the destination host.  Thus, MMS_S is only an upper
-                   bound on the datagram size that a transport protocol
-                   may send; even when MMS_S exceeds 556, the transport
-                   layer must limit its messages to 556 bytes in the
-                   absence of other knowledge about the destination
-                   host.
-
-              (b)  Some transport protocols (e.g., TCP) provide a way to
-                   explicitly inform the sender about the largest
-                   datagram the other end can receive and reassemble
-                   [IP:7].  There is no corresponding mechanism in the
-                   IP layer.
-
-                   A transport protocol that assumes an EMTU_R larger
-                   than 576 (see Section 3.3.2), can send a datagram of
-                   this larger size to another host that implements the
-                   same protocol.
-
-              (c)  Hosts should ideally limit their EMTU_S for a given
-                   destination to the minimum MTU of all the networks
-                   along the path, to avoid any fragmentation.  IP
-                   fragmentation, while formally correct, can create a
-                   serious transport protocol performance problem,
-                   because loss of a single fragment means all the
-                   fragments in the segment must be retransmitted
-                   [IP:9].
-
-
-
-
-Internet Engineering Task Force                                [Page 59]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-              Since nearly all networks in the Internet currently
-              support an MTU of 576 or greater, we strongly recommend
-              the use of 576 for datagrams sent to non-local networks.
-
-              It has been suggested that a host could determine the MTU
-              over a given path by sending a zero-offset datagram
-              fragment and waiting for the receiver to time out the
-              reassembly (which cannot complete!) and return an ICMP
-              Time Exceeded message.  This message would include the
-              largest remaining fragment header in its body.  More
-              direct mechanisms are being experimented with, but have
-              not yet been adopted (see e.g., RFC-1063).
-
-      3.3.4  Local Multihoming
-
-         3.3.4.1  Introduction
-
-            A multihomed host has multiple IP addresses, which we may
-            think of as "logical interfaces".  These logical interfaces
-            may be associated with one or more physical interfaces, and
-            these physical interfaces may be connected to the same or
-            different networks.
-
-            Here are some important cases of multihoming:
-
-            (a)  Multiple Logical Networks
-
-                 The Internet architects envisioned that each physical
-                 network would have a single unique IP network (or
-                 subnet) number.  However, LAN administrators have
-                 sometimes found it useful to violate this assumption,
-                 operating a LAN with multiple logical networks per
-                 physical connected network.
-
-                 If a host connected to such a physical network is
-                 configured to handle traffic for each of N different
-                 logical networks, then the host will have N logical
-                 interfaces.  These could share a single physical
-                 interface, or might use N physical interfaces to the
-                 same network.
-
-            (b)  Multiple Logical Hosts
-
-                 When a host has multiple IP addresses that all have the
-                 same <Network-number> part (and the same <Subnet-
-                 number> part, if any), the logical interfaces are known
-                 as "logical hosts".  These logical interfaces might
-                 share a single physical interface or might use separate
-
-
-
-Internet Engineering Task Force                                [Page 60]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                 physical interfaces to the same physical network.
-
-            (c)  Simple Multihoming
-
-                 In this case, each logical interface is mapped into a
-                 separate physical interface and each physical interface
-                 is connected to a different physical network.  The term
-                 "multihoming" was originally applied only to this case,
-                 but it is now applied more generally.
-
-                 A host with embedded gateway functionality will
-                 typically fall into the simple multihoming case.  Note,
-                 however, that a host may be simply multihomed without
-                 containing an embedded gateway, i.e., without
-                 forwarding datagrams from one connected network to
-                 another.
-
-                 This case presents the most difficult routing problems.
-                 The choice of interface (i.e., the choice of first-hop
-                 network) may significantly affect performance or even
-                 reachability of remote parts of the Internet.
-
-
-            Finally, we note another possibility that is NOT
-            multihoming:  one logical interface may be bound to multiple
-            physical interfaces, in order to increase the reliability or
-            throughput between directly connected machines by providing
-            alternative physical paths between them.  For instance, two
-            systems might be connected by multiple point-to-point links.
-            We call this "link-layer multiplexing".  With link-layer
-            multiplexing, the protocols above the link layer are unaware
-            that multiple physical interfaces are present; the link-
-            layer device driver is responsible for multiplexing and
-            routing packets across the physical interfaces.
-
-            In the Internet protocol architecture, a transport protocol
-            instance ("entity") has no address of its own, but instead
-            uses a single Internet Protocol (IP) address.  This has
-            implications for the IP, transport, and application layers,
-            and for the interfaces between them.  In particular, the
-            application software may have to be aware of the multiple IP
-            addresses of a multihomed host; in other cases, the choice
-            can be made within the network software.
-
-         3.3.4.2  Multihoming Requirements
-
-            The following general rules apply to the selection of an IP
-            source address for sending a datagram from a multihomed
-
-
-
-Internet Engineering Task Force                                [Page 61]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-            host.
-
-            (1)  If the datagram is sent in response to a received
-                 datagram, the source address for the response SHOULD be
-                 the specific-destination address of the request.  See
-                 Sections 4.1.3.5 and 4.2.3.7 and the "General Issues"
-                 section of [INTRO:1] for more specific requirements on
-                 higher layers.
-
-                 Otherwise, a source address must be selected.
-
-            (2)  An application MUST be able to explicitly specify the
-                 source address for initiating a connection or a
-                 request.
-
-            (3)  In the absence of such a specification, the networking
-                 software MUST choose a source address.  Rules for this
-                 choice are described below.
-
-
-            There are two key requirement issues related to multihoming:
-
-            (A)  A host MAY silently discard an incoming datagram whose
-                 destination address does not correspond to the physical
-                 interface through which it is received.
-
-            (B)  A host MAY restrict itself to sending (non-source-
-                 routed) IP datagrams only through the physical
-                 interface that corresponds to the IP source address of
-                 the datagrams.
-
-
-            DISCUSSION:
-                 Internet host implementors have used two different
-                 conceptual models for multihoming, briefly summarized
-                 in the following discussion.  This document takes no
-                 stand on which model is preferred; each seems to have a
-                 place.  This ambivalence is reflected in the issues (A)
-                 and (B) being optional.
-
-                 o    Strong ES Model
-
-                      The Strong ES (End System, i.e., host) model
-                      emphasizes the host/gateway (ES/IS) distinction,
-                      and would therefore substitute MUST for MAY in
-                      issues (A) and (B) above.  It tends to model a
-                      multihomed host as a set of logical hosts within
-                      the same physical host.
-
-
-
-Internet Engineering Task Force                                [Page 62]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                      With respect to (A), proponents of the Strong ES
-                      model note that automatic Internet routing
-                      mechanisms could not route a datagram to a
-                      physical interface that did not correspond to the
-                      destination address.
-
-                      Under the Strong ES model, the route computation
-                      for an outgoing datagram is the mapping:
-
-                         route(src IP addr, dest IP addr, TOS)
-                                                        -> gateway
-
-                      Here the source address is included as a parameter
-                      in order to select a gateway that is directly
-                      reachable on the corresponding physical interface.
-                      Note that this model logically requires that in
-                      general there be at least one default gateway, and
-                      preferably multiple defaults, for each IP source
-                      address.
-
-                 o    Weak ES Model
-
-                      This view de-emphasizes the ES/IS distinction, and
-                      would therefore substitute MUST NOT for MAY in
-                      issues (A) and (B).  This model may be the more
-                      natural one for hosts that wiretap gateway routing
-                      protocols, and is necessary for hosts that have
-                      embedded gateway functionality.
-
-                      The Weak ES Model may cause the Redirect mechanism
-                      to fail.  If a datagram is sent out a physical
-                      interface that does not correspond to the
-                      destination address, the first-hop gateway will
-                      not realize when it needs to send a Redirect.  On
-                      the other hand, if the host has embedded gateway
-                      functionality, then it has routing information
-                      without listening to Redirects.
-
-                      In the Weak ES model, the route computation for an
-                      outgoing datagram is the mapping:
-
-                         route(dest IP addr, TOS) -> gateway, interface
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 63]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-         3.3.4.3  Choosing a Source Address
-
-            DISCUSSION:
-                 When it sends an initial connection request (e.g., a
-                 TCP "SYN" segment) or a datagram service request (e.g.,
-                 a UDP-based query), the transport layer on a multihomed
-                 host needs to know which source address to use.  If the
-                 application does not specify it, the transport layer
-                 must ask the IP layer to perform the conceptual
-                 mapping:
-
-                     GET_SRCADDR(remote IP addr, TOS)
-                                               -> local IP address
-
-                 Here TOS is the Type-of-Service value (see Section
-                 3.2.1.6), and the result is the desired source address.
-                 The following rules are suggested for implementing this
-                 mapping:
-
-                 (a)  If the remote Internet address lies on one of the
-                      (sub-) nets to which the host is directly
-                      connected, a corresponding source address may be
-                      chosen, unless the corresponding interface is
-                      known to be down.
-
-                 (b)  The route cache may be consulted, to see if there
-                      is an active route to the specified destination
-                      network through any network interface; if so, a
-                      local IP address corresponding to that interface
-                      may be chosen.
-
-                 (c)  The table of static routes, if any (see Section
-                      3.3.1.2) may be similarly consulted.
-
-                 (d)  The default gateways may be consulted.  If these
-                      gateways are assigned to different interfaces, the
-                      interface corresponding to the gateway with the
-                      highest preference may be chosen.
-
-                 In the future, there may be a defined way for a
-                 multihomed host to ask the gateways on all connected
-                 networks for advice about the best network to use for a
-                 given destination.
-
-            IMPLEMENTATION:
-                 It will be noted that this process is essentially the
-                 same as datagram routing (see Section 3.3.1), and
-                 therefore hosts may be able to combine the
-
-
-
-Internet Engineering Task Force                                [Page 64]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                 implementation of the two functions.
-
-      3.3.5  Source Route Forwarding
-
-         Subject to restrictions given below, a host MAY be able to act
-         as an intermediate hop in a source route, forwarding a source-
-         routed datagram to the next specified hop.
-
-         However, in performing this gateway-like function, the host
-         MUST obey all the relevant rules for a gateway forwarding
-         source-routed datagrams [INTRO:2].  This includes the following
-         specific provisions, which override the corresponding host
-         provisions given earlier in this document:
-
-         (A)  TTL (ref. Section 3.2.1.7)
-
-              The TTL field MUST be decremented and the datagram perhaps
-              discarded as specified for a gateway in [INTRO:2].
-
-         (B)  ICMP Destination Unreachable (ref. Section 3.2.2.1)
-
-              A host MUST be able to generate Destination Unreachable
-              messages with the following codes:
-
-              4    (Fragmentation Required but DF Set) when a source-
-                   routed datagram cannot be fragmented to fit into the
-                   target network;
-
-              5    (Source Route Failed) when a source-routed datagram
-                   cannot be forwarded, e.g., because of a routing
-                   problem or because the next hop of a strict source
-                   route is not on a connected network.
-
-         (C)  IP Source Address (ref. Section 3.2.1.3)
-
-              A source-routed datagram being forwarded MAY (and normally
-              will) have a source address that is not one of the IP
-              addresses of the forwarding host.
-
-         (D)  Record Route Option (ref. Section 3.2.1.8d)
-
-              A host that is forwarding a source-routed datagram
-              containing a Record Route option MUST update that option,
-              if it has room.
-
-         (E)  Timestamp Option (ref. Section 3.2.1.8e)
-
-              A host that is forwarding a source-routed datagram
-
-
-
-Internet Engineering Task Force                                [Page 65]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-              containing a Timestamp Option MUST add the current
-              timestamp to that option, according to the rules for this
-              option.
-
-         To define the rules restricting host forwarding of source-
-         routed datagrams, we use the term "local source-routing" if the
-         next hop will be through the same physical interface through
-         which the datagram arrived; otherwise, it is "non-local
-         source-routing".
-
-         o    A host is permitted to perform local source-routing
-              without restriction.
-
-         o    A host that supports non-local source-routing MUST have a
-              configurable switch to disable forwarding, and this switch
-              MUST default to disabled.
-
-         o    The host MUST satisfy all gateway requirements for
-              configurable policy filters [INTRO:2] restricting non-
-              local forwarding.
-
-         If a host receives a datagram with an incomplete source route
-         but does not forward it for some reason, the host SHOULD return
-         an ICMP Destination Unreachable (code 5, Source Route Failed)
-         message, unless the datagram was itself an ICMP error message.
-
-      3.3.6  Broadcasts
-
-         Section 3.2.1.3 defined the four standard IP broadcast address
-         forms:
-
-           Limited Broadcast:  {-1, -1}
-
-           Directed Broadcast:  {<Network-number>,-1}
-
-           Subnet Directed Broadcast:
-                              {<Network-number>,<Subnet-number>,-1}
-
-           All-Subnets Directed Broadcast: {<Network-number>,-1,-1}
-
-         A host MUST recognize any of these forms in the destination
-         address of an incoming datagram.
-
-         There is a class of hosts* that use non-standard broadcast
-         address forms, substituting 0 for -1.  All hosts SHOULD
-_________________________
-*4.2BSD Unix and its derivatives, but not 4.3BSD.
-
-
-
-
-Internet Engineering Task Force                                [Page 66]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-         recognize and accept any of these non-standard broadcast
-         addresses as the destination address of an incoming datagram.
-         A host MAY optionally have a configuration option to choose the
-         0 or the -1 form of broadcast address, for each physical
-         interface, but this option SHOULD default to the standard (-1)
-         form.
-
-         When a host sends a datagram to a link-layer broadcast address,
-         the IP destination address MUST be a legal IP broadcast or IP
-         multicast address.
-
-         A host SHOULD silently discard a datagram that is received via
-         a link-layer broadcast (see Section 2.4) but does not specify
-         an IP multicast or broadcast destination address.
-
-         Hosts SHOULD use the Limited Broadcast address to broadcast to
-         a connected network.
-
-
-         DISCUSSION:
-              Using the Limited Broadcast address instead of a Directed
-              Broadcast address may improve system robustness.  Problems
-              are often caused by machines that do not understand the
-              plethora of broadcast addresses (see Section 3.2.1.3), or
-              that may have different ideas about which broadcast
-              addresses are in use.  The prime example of the latter is
-              machines that do not understand subnetting but are
-              attached to a subnetted net.  Sending a Subnet Broadcast
-              for the connected network will confuse those machines,
-              which will see it as a message to some other host.
-
-              There has been discussion on whether a datagram addressed
-              to the Limited Broadcast address ought to be sent from all
-              the interfaces of a multihomed host.  This specification
-              takes no stand on the issue.
-
-      3.3.7  IP Multicasting
-
-         A host SHOULD support local IP multicasting on all connected
-         networks for which a mapping from Class D IP addresses to
-         link-layer addresses has been specified (see below).  Support
-         for local IP multicasting includes sending multicast datagrams,
-         joining multicast groups and receiving multicast datagrams, and
-         leaving multicast groups.  This implies support for all of
-         [IP:4] except the IGMP protocol itself, which is OPTIONAL.
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 67]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-         DISCUSSION:
-              IGMP provides gateways that are capable of multicast
-              routing with the information required to support IP
-              multicasting across multiple networks.  At this time,
-              multicast-routing gateways are in the experimental stage
-              and are not widely available.  For hosts that are not
-              connected to networks with multicast-routing gateways or
-              that do not need to receive multicast datagrams
-              originating on other networks, IGMP serves no purpose and
-              is therefore optional for now.  However, the rest of
-              [IP:4] is currently recommended for the purpose of
-              providing IP-layer access to local network multicast
-              addressing, as a preferable alternative to local broadcast
-              addressing.  It is expected that IGMP will become
-              recommended at some future date, when multicast-routing
-              gateways have become more widely available.
-
-         If IGMP is not implemented, a host SHOULD still join the "all-
-         hosts" group (224.0.0.1) when the IP layer is initialized and
-         remain a member for as long as the IP layer is active.
-
-         DISCUSSION:
-              Joining the "all-hosts" group will support strictly local
-              uses of multicasting, e.g., a gateway discovery protocol,
-              even if IGMP is not implemented.
-
-         The mapping of IP Class D addresses to local addresses is
-         currently specified for the following types of networks:
-
-         o    Ethernet/IEEE 802.3, as defined in [IP:4].
-
-         o    Any network that supports broadcast but not multicast,
-              addressing: all IP Class D addresses map to the local
-              broadcast address.
-
-         o    Any type of point-to-point link (e.g., SLIP or HDLC
-              links): no mapping required.  All IP multicast datagrams
-              are sent as-is, inside the local framing.
-
-         Mappings for other types of networks will be specified in the
-         future.
-
-         A host SHOULD provide a way for higher-layer protocols or
-         applications to determine which of the host's connected
-         network(s) support IP multicast addressing.
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 68]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-      3.3.8  Error Reporting
-
-         Wherever practical, hosts MUST return ICMP error datagrams on
-         detection of an error, except in those cases where returning an
-         ICMP error message is specifically prohibited.
-
-         DISCUSSION:
-              A common phenomenon in datagram networks is the "black
-              hole disease": datagrams are sent out, but nothing comes
-              back.  Without any error datagrams, it is difficult for
-              the user to figure out what the problem is.
-
-   3.4  INTERNET/TRANSPORT LAYER INTERFACE
-
-      The interface between the IP layer and the transport layer MUST
-      provide full access to all the mechanisms of the IP layer,
-      including options, Type-of-Service, and Time-to-Live.  The
-      transport layer MUST either have mechanisms to set these interface
-      parameters, or provide a path to pass them through from an
-      application, or both.
-
-      DISCUSSION:
-           Applications are urged to make use of these mechanisms where
-           applicable, even when the mechanisms are not currently
-           effective in the Internet (e.g., TOS).  This will allow these
-           mechanisms to be immediately useful when they do become
-           effective, without a large amount of retrofitting of host
-           software.
-
-      We now describe a conceptual interface between the transport layer
-      and the IP layer, as a set of procedure calls.  This is an
-      extension of the information in Section 3.3 of RFC-791 [IP:1].
-
-
-      *    Send Datagram
-
-                SEND(src, dst, prot, TOS, TTL, BufPTR, len, Id, DF, opt
-                     => result )
-
-           where the parameters are defined in RFC-791.  Passing an Id
-           parameter is optional; see Section 3.2.1.5.
-
-
-      *    Receive Datagram
-
-                RECV(BufPTR, prot
-                     => result, src, dst, SpecDest, TOS, len, opt)
-
-
-
-
-Internet Engineering Task Force                                [Page 69]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-           All the parameters are defined in RFC-791, except for:
-
-                SpecDest = specific-destination address of datagram
-                            (defined in Section 3.2.1.3)
-
-           The result parameter dst contains the datagram's destination
-           address.  Since this may be a broadcast or multicast address,
-           the SpecDest parameter (not shown in RFC-791) MUST be passed.
-           The parameter opt contains all the IP options received in the
-           datagram; these MUST also be passed to the transport layer.
-
-
-      *    Select Source Address
-
-                GET_SRCADDR(remote, TOS)  -> local
-
-                remote = remote IP address
-                TOS = Type-of-Service
-                local = local IP address
-
-           See Section 3.3.4.3.
-
-
-      *    Find Maximum Datagram Sizes
-
-                GET_MAXSIZES(local, remote, TOS) -> MMS_R, MMS_S
-
-                MMS_R = maximum receive transport-message size.
-                MMS_S = maximum send transport-message size.
-               (local, remote, TOS defined above)
-
-           See Sections 3.3.2 and 3.3.3.
-
-
-      *    Advice on Delivery Success
-
-                ADVISE_DELIVPROB(sense, local, remote, TOS)
-
-           Here the parameter sense is a 1-bit flag indicating whether
-           positive or negative advice is being given; see the
-           discussion in Section 3.3.1.4. The other parameters were
-           defined earlier.
-
-
-      *    Send ICMP Message
-
-                SEND_ICMP(src, dst, TOS, TTL, BufPTR, len, Id, DF, opt)
-                     -> result
-
-
-
-Internet Engineering Task Force                                [Page 70]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                (Parameters defined in RFC-791).
-
-           Passing an Id parameter is optional; see Section 3.2.1.5.
-           The transport layer MUST be able to send certain ICMP
-           messages:  Port Unreachable or any of the query-type
-           messages.  This function could be considered to be a special
-           case of the SEND() call, of course; we describe it separately
-           for clarity.
-
-
-      *    Receive ICMP Message
-
-                RECV_ICMP(BufPTR ) -> result, src, dst, len, opt
-
-                (Parameters defined in RFC-791).
-
-           The IP layer MUST pass certain ICMP messages up to the
-           appropriate transport-layer routine.  This function could be
-           considered to be a special case of the RECV() call, of
-           course; we describe it separately for clarity.
-
-           For an ICMP error message, the data that is passed up MUST
-           include the original Internet header plus all the octets of
-           the original message that are included in the ICMP message.
-           This data will be used by the transport layer to locate the
-           connection state information, if any.
-
-           In particular, the following ICMP messages are to be passed
-           up:
-
-           o    Destination Unreachable
-
-           o    Source Quench
-
-           o    Echo Reply (to ICMP user interface, unless the Echo
-                Request originated in the IP layer)
-
-           o    Timestamp Reply (to ICMP user interface)
-
-           o    Time Exceeded
-
-
-      DISCUSSION:
-           In the future, there may be additions to this interface to
-           pass path data (see Section 3.3.1.3) between the IP and
-           transport layers.
-
-
-
-
-
-Internet Engineering Task Force                                [Page 71]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-   3.5  INTERNET LAYER REQUIREMENTS SUMMARY
-
-
-                                                 |        | | | |S| |
-                                                 |        | | | |H| |F
-                                                 |        | | | |O|M|o
-                                                 |        | |S| |U|U|o
-                                                 |        | |H| |L|S|t
-                                                 |        |M|O| |D|T|n
-                                                 |        |U|U|M| | |o
-                                                 |        |S|L|A|N|N|t
-                                                 |        |T|D|Y|O|O|t
-FEATURE                                          |SECTION | | | |T|T|e
--------------------------------------------------|--------|-|-|-|-|-|--
-                                                 |        | | | | | |
-Implement IP and ICMP                            |3.1     |x| | | | |
-Handle remote multihoming in application layer   |3.1     |x| | | | |
-Support local multihoming                        |3.1     | | |x| | |
-Meet gateway specs if forward datagrams          |3.1     |x| | | | |
-Configuration switch for embedded gateway        |3.1     |x| | | | |1
-   Config switch default to non-gateway          |3.1     |x| | | | |1
-   Auto-config based on number of interfaces     |3.1     | | | | |x|1
-Able to log discarded datagrams                  |3.1     | |x| | | |
-   Record in counter                             |3.1     | |x| | | |
-                                                 |        | | | | | |
-Silently discard Version != 4                    |3.2.1.1 |x| | | | |
-Verify IP checksum, silently discard bad dgram   |3.2.1.2 |x| | | | |
-Addressing:                                      |        | | | | | |
-  Subnet addressing (RFC-950)                    |3.2.1.3 |x| | | | |
-  Src address must be host's own IP address      |3.2.1.3 |x| | | | |
-  Silently discard datagram with bad dest addr   |3.2.1.3 |x| | | | |
-  Silently discard datagram with bad src addr    |3.2.1.3 |x| | | | |
-Support reassembly                               |3.2.1.4 |x| | | | |
-Retain same Id field in identical datagram       |3.2.1.5 | | |x| | |
-                                                 |        | | | | | |
-TOS:                                             |        | | | | | |
-  Allow transport layer to set TOS               |3.2.1.6 |x| | | | |
-  Pass received TOS up to transport layer        |3.2.1.6 | |x| | | |
-  Use RFC-795 link-layer mappings for TOS        |3.2.1.6 | | | |x| |
-TTL:                                             |        | | | | | |
-  Send packet with TTL of 0                      |3.2.1.7 | | | | |x|
-  Discard received packets with TTL < 2          |3.2.1.7 | | | | |x|
-  Allow transport layer to set TTL               |3.2.1.7 |x| | | | |
-  Fixed TTL is configurable                      |3.2.1.7 |x| | | | |
-                                                 |        | | | | | |
-IP Options:                                      |        | | | | | |
-  Allow transport layer to send IP options       |3.2.1.8 |x| | | | |
-  Pass all IP options rcvd to higher layer       |3.2.1.8 |x| | | | |
-
-
-
-Internet Engineering Task Force                                [Page 72]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-  IP layer silently ignore unknown options       |3.2.1.8 |x| | | | |
-  Security option                                |3.2.1.8a| | |x| | |
-  Send Stream Identifier option                  |3.2.1.8b| | | |x| |
-  Silently ignore Stream Identifer option        |3.2.1.8b|x| | | | |
-  Record Route option                            |3.2.1.8d| | |x| | |
-  Timestamp option                               |3.2.1.8e| | |x| | |
-Source Route Option:                             |        | | | | | |
-  Originate & terminate Source Route options     |3.2.1.8c|x| | | | |
-  Datagram with completed SR passed up to TL     |3.2.1.8c|x| | | | |
-  Build correct (non-redundant) return route     |3.2.1.8c|x| | | | |
-  Send multiple SR options in one header         |3.2.1.8c| | | | |x|
-                                                 |        | | | | | |
-ICMP:                                            |        | | | | | |
-  Silently discard ICMP msg with unknown type    |3.2.2   |x| | | | |
-  Include more than 8 octets of orig datagram    |3.2.2   | | |x| | |
-      Included octets same as received           |3.2.2   |x| | | | |
-  Demux ICMP Error to transport protocol         |3.2.2   |x| | | | |
-  Send ICMP error message with TOS=0             |3.2.2   | |x| | | |
-  Send ICMP error message for:                   |        | | | | | |
-   - ICMP error msg                              |3.2.2   | | | | |x|
-   - IP b'cast or IP m'cast                      |3.2.2   | | | | |x|
-   - Link-layer b'cast                           |3.2.2   | | | | |x|
-   - Non-initial fragment                        |3.2.2   | | | | |x|
-   - Datagram with non-unique src address        |3.2.2   | | | | |x|
-  Return ICMP error msgs (when not prohibited)   |3.3.8   |x| | | | |
-                                                 |        | | | | | |
-  Dest Unreachable:                              |        | | | | | |
-    Generate Dest Unreachable (code 2/3)         |3.2.2.1 | |x| | | |
-    Pass ICMP Dest Unreachable to higher layer   |3.2.2.1 |x| | | | |
-    Higher layer act on Dest Unreach             |3.2.2.1 | |x| | | |
-      Interpret Dest Unreach as only hint        |3.2.2.1 |x| | | | |
-  Redirect:                                      |        | | | | | |
-    Host send Redirect                           |3.2.2.2 | | | |x| |
-    Update route cache when recv Redirect        |3.2.2.2 |x| | | | |
-    Handle both Host and Net Redirects           |3.2.2.2 |x| | | | |
-    Discard illegal Redirect                     |3.2.2.2 | |x| | | |
-  Source Quench:                                 |        | | | | | |
-    Send Source Quench if buffering exceeded     |3.2.2.3 | | |x| | |
-    Pass Source Quench to higher layer           |3.2.2.3 |x| | | | |
-    Higher layer act on Source Quench            |3.2.2.3 | |x| | | |
-  Time Exceeded: pass to higher layer            |3.2.2.4 |x| | | | |
-  Parameter Problem:                             |        | | | | | |
-    Send Parameter Problem messages              |3.2.2.5 | |x| | | |
-    Pass Parameter Problem to higher layer       |3.2.2.5 |x| | | | |
-    Report Parameter Problem to user             |3.2.2.5 | | |x| | |
-                                                 |        | | | | | |
-  ICMP Echo Request or Reply:                    |        | | | | | |
-    Echo server and Echo client                  |3.2.2.6 |x| | | | |
-
-
-
-Internet Engineering Task Force                                [Page 73]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-    Echo client                                  |3.2.2.6 | |x| | | |
-    Discard Echo Request to broadcast address    |3.2.2.6 | | |x| | |
-    Discard Echo Request to multicast address    |3.2.2.6 | | |x| | |
-    Use specific-dest addr as Echo Reply src     |3.2.2.6 |x| | | | |
-    Send same data in Echo Reply                 |3.2.2.6 |x| | | | |
-    Pass Echo Reply to higher layer              |3.2.2.6 |x| | | | |
-    Reflect Record Route, Time Stamp options     |3.2.2.6 | |x| | | |
-    Reverse and reflect Source Route option      |3.2.2.6 |x| | | | |
-                                                 |        | | | | | |
-  ICMP Information Request or Reply:             |3.2.2.7 | | | |x| |
-  ICMP Timestamp and Timestamp Reply:            |3.2.2.8 | | |x| | |
-    Minimize delay variability                   |3.2.2.8 | |x| | | |1
-    Silently discard b'cast Timestamp            |3.2.2.8 | | |x| | |1
-    Silently discard m'cast Timestamp            |3.2.2.8 | | |x| | |1
-    Use specific-dest addr as TS Reply src       |3.2.2.8 |x| | | | |1
-    Reflect Record Route, Time Stamp options     |3.2.2.6 | |x| | | |1
-    Reverse and reflect Source Route option      |3.2.2.8 |x| | | | |1
-    Pass Timestamp Reply to higher layer         |3.2.2.8 |x| | | | |1
-    Obey rules for "standard value"              |3.2.2.8 |x| | | | |1
-                                                 |        | | | | | |
-  ICMP Address Mask Request and Reply:           |        | | | | | |
-    Addr Mask source configurable                |3.2.2.9 |x| | | | |
-    Support static configuration of addr mask    |3.2.2.9 |x| | | | |
-    Get addr mask dynamically during booting     |3.2.2.9 | | |x| | |
-    Get addr via ICMP Addr Mask Request/Reply    |3.2.2.9 | | |x| | |
-      Retransmit Addr Mask Req if no Reply       |3.2.2.9 |x| | | | |3
-      Assume default mask if no Reply            |3.2.2.9 | |x| | | |3
-      Update address mask from first Reply only  |3.2.2.9 |x| | | | |3
-    Reasonableness check on Addr Mask            |3.2.2.9 | |x| | | |
-    Send unauthorized Addr Mask Reply msgs       |3.2.2.9 | | | | |x|
-      Explicitly configured to be agent          |3.2.2.9 |x| | | | |
-    Static config=> Addr-Mask-Authoritative flag |3.2.2.9 | |x| | | |
-      Broadcast Addr Mask Reply when init.       |3.2.2.9 |x| | | | |3
-                                                 |        | | | | | |
-ROUTING OUTBOUND DATAGRAMS:                      |        | | | | | |
-  Use address mask in local/remote decision      |3.3.1.1 |x| | | | |
-  Operate with no gateways on conn network       |3.3.1.1 |x| | | | |
-  Maintain "route cache" of next-hop gateways    |3.3.1.2 |x| | | | |
-  Treat Host and Net Redirect the same           |3.3.1.2 | |x| | | |
-  If no cache entry, use default gateway         |3.3.1.2 |x| | | | |
-    Support multiple default gateways            |3.3.1.2 |x| | | | |
-  Provide table of static routes                 |3.3.1.2 | | |x| | |
-    Flag: route overridable by Redirects         |3.3.1.2 | | |x| | |
-  Key route cache on host, not net address       |3.3.1.3 | | |x| | |
-  Include TOS in route cache                     |3.3.1.3 | |x| | | |
-                                                 |        | | | | | |
-  Able to detect failure of next-hop gateway     |3.3.1.4 |x| | | | |
-  Assume route is good forever                   |3.3.1.4 | | | |x| |
-
-
-
-Internet Engineering Task Force                                [Page 74]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-  Ping gateways continuously                     |3.3.1.4 | | | | |x|
-  Ping only when traffic being sent              |3.3.1.4 |x| | | | |
-  Ping only when no positive indication          |3.3.1.4 |x| | | | |
-  Higher and lower layers give advice            |3.3.1.4 | |x| | | |
-  Switch from failed default g'way to another    |3.3.1.5 |x| | | | |
-  Manual method of entering config info          |3.3.1.6 |x| | | | |
-                                                 |        | | | | | |
-REASSEMBLY and FRAGMENTATION:                    |        | | | | | |
-  Able to reassemble incoming datagrams          |3.3.2   |x| | | | |
-    At least 576 byte datagrams                  |3.3.2   |x| | | | |
-    EMTU_R configurable or indefinite            |3.3.2   | |x| | | |
-  Transport layer able to learn MMS_R            |3.3.2   |x| | | | |
-  Send ICMP Time Exceeded on reassembly timeout  |3.3.2   |x| | | | |
-    Fixed reassembly timeout value               |3.3.2   | |x| | | |
-                                                 |        | | | | | |
-  Pass MMS_S to higher layers                    |3.3.3   |x| | | | |
-  Local fragmentation of outgoing packets        |3.3.3   | | |x| | |
-     Else don't send bigger than MMS_S           |3.3.3   |x| | | | |
-  Send max 576 to off-net destination            |3.3.3   | |x| | | |
-  All-Subnets-MTU configuration flag             |3.3.3   | | |x| | |
-                                                 |        | | | | | |
-MULTIHOMING:                                     |        | | | | | |
-  Reply with same addr as spec-dest addr         |3.3.4.2 | |x| | | |
-  Allow application to choose local IP addr      |3.3.4.2 |x| | | | |
-  Silently discard d'gram in "wrong" interface   |3.3.4.2 | | |x| | |
-  Only send d'gram through "right" interface     |3.3.4.2 | | |x| | |4
-                                                 |        | | | | | |
-SOURCE-ROUTE FORWARDING:                         |        | | | | | |
-  Forward datagram with Source Route option      |3.3.5   | | |x| | |1
-    Obey corresponding gateway rules             |3.3.5   |x| | | | |1
-      Update TTL by gateway rules                |3.3.5   |x| | | | |1
-      Able to generate ICMP err code 4, 5        |3.3.5   |x| | | | |1
-      IP src addr not local host                 |3.3.5   | | |x| | |1
-      Update Timestamp, Record Route options     |3.3.5   |x| | | | |1
-    Configurable switch for non-local SRing      |3.3.5   |x| | | | |1
-      Defaults to OFF                            |3.3.5   |x| | | | |1
-    Satisfy gwy access rules for non-local SRing |3.3.5   |x| | | | |1
-    If not forward, send Dest Unreach (cd 5)     |3.3.5   | |x| | | |2
-                                                 |        | | | | | |
-BROADCAST:                                       |        | | | | | |
-  Broadcast addr as IP source addr               |3.2.1.3 | | | | |x|
-  Receive 0 or -1 broadcast formats OK           |3.3.6   | |x| | | |
-  Config'ble option to send 0 or -1 b'cast       |3.3.6   | | |x| | |
-    Default to -1 broadcast                      |3.3.6   | |x| | | |
-  Recognize all broadcast address formats        |3.3.6   |x| | | | |
-  Use IP b'cast/m'cast addr in link-layer b'cast |3.3.6   |x| | | | |
-  Silently discard link-layer-only b'cast dg's   |3.3.6   | |x| | | |
-  Use Limited Broadcast addr for connected net   |3.3.6   | |x| | | |
-
-
-
-Internet Engineering Task Force                                [Page 75]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                                                 |        | | | | | |
-MULTICAST:                                       |        | | | | | |
-  Support local IP multicasting (RFC-1112)       |3.3.7   | |x| | | |
-  Support IGMP (RFC-1112)                        |3.3.7   | | |x| | |
-  Join all-hosts group at startup                |3.3.7   | |x| | | |
-  Higher layers learn i'face m'cast capability   |3.3.7   | |x| | | |
-                                                 |        | | | | | |
-INTERFACE:                                       |        | | | | | |
-  Allow transport layer to use all IP mechanisms |3.4     |x| | | | |
-  Pass interface ident up to transport layer     |3.4     |x| | | | |
-  Pass all IP options up to transport layer      |3.4     |x| | | | |
-  Transport layer can send certain ICMP messages |3.4     |x| | | | |
-  Pass spec'd ICMP messages up to transp. layer  |3.4     |x| | | | |
-     Include IP hdr+8 octets or more from orig.  |3.4     |x| | | | |
-  Able to leap tall buildings at a single bound  |3.5     | |x| | | |
-
-Footnotes:
-
-(1)  Only if feature is implemented.
-
-(2)  This requirement is overruled if datagram is an ICMP error message.
-
-(3)  Only if feature is implemented and is configured "on".
-
-(4)  Unless has embedded gateway functionality or is source routed.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 76]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- UDP             October 1989
-
-
-4. TRANSPORT PROTOCOLS
-
-   4.1  USER DATAGRAM PROTOCOL -- UDP
-
-      4.1.1  INTRODUCTION
-
-         The User Datagram Protocol UDP [UDP:1] offers only a minimal
-         transport service -- non-guaranteed datagram delivery -- and
-         gives applications direct access to the datagram service of the
-         IP layer.  UDP is used by applications that do not require the
-         level of service of TCP or that wish to use communications
-         services (e.g., multicast or broadcast delivery) not available
-         from TCP.
-
-         UDP is almost a null protocol; the only services it provides
-         over IP are checksumming of data and multiplexing by port
-         number.  Therefore, an application program running over UDP
-         must deal directly with end-to-end communication problems that
-         a connection-oriented protocol would have handled -- e.g.,
-         retransmission for reliable delivery, packetization and
-         reassembly, flow control, congestion avoidance, etc., when
-         these are required.  The fairly complex coupling between IP and
-         TCP will be mirrored in the coupling between UDP and many
-         applications using UDP.
-
-      4.1.2  PROTOCOL WALK-THROUGH
-
-         There are no known errors in the specification of UDP.
-
-      4.1.3  SPECIFIC ISSUES
-
-         4.1.3.1  Ports
-
-            UDP well-known ports follow the same rules as TCP well-known
-            ports; see Section 4.2.2.1 below.
-
-            If a datagram arrives addressed to a UDP port for which
-            there is no pending LISTEN call, UDP SHOULD send an ICMP
-            Port Unreachable message.
-
-         4.1.3.2  IP Options
-
-            UDP MUST pass any IP option that it receives from the IP
-            layer transparently to the application layer.
-
-            An application MUST be able to specify IP options to be sent
-            in its UDP datagrams, and UDP MUST pass these options to the
-            IP layer.
-
-
-
-Internet Engineering Task Force                                [Page 77]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- UDP             October 1989
-
-
-            DISCUSSION:
-                 At present, the only options that need be passed
-                 through UDP are Source Route, Record Route, and Time
-                 Stamp.  However, new options may be defined in the
-                 future, and UDP need not and should not make any
-                 assumptions about the format or content of options it
-                 passes to or from the application; an exception to this
-                 might be an IP-layer security option.
-
-                 An application based on UDP will need to obtain a
-                 source route from a request datagram and supply a
-                 reversed route for sending the corresponding reply.
-
-         4.1.3.3  ICMP Messages
-
-            UDP MUST pass to the application layer all ICMP error
-            messages that it receives from the IP layer.  Conceptually
-            at least, this may be accomplished with an upcall to the
-            ERROR_REPORT routine (see Section 4.2.4.1).
-
-            DISCUSSION:
-                 Note that ICMP error messages resulting from sending a
-                 UDP datagram are received asynchronously.  A UDP-based
-                 application that wants to receive ICMP error messages
-                 is responsible for maintaining the state necessary to
-                 demultiplex these messages when they arrive; for
-                 example, the application may keep a pending receive
-                 operation for this purpose.  The application is also
-                 responsible to avoid confusion from a delayed ICMP
-                 error message resulting from an earlier use of the same
-                 port(s).
-
-         4.1.3.4  UDP Checksums
-
-            A host MUST implement the facility to generate and validate
-            UDP checksums.  An application MAY optionally be able to
-            control whether a UDP checksum will be generated, but it
-            MUST default to checksumming on.
-
-            If a UDP datagram is received with a checksum that is non-
-            zero and invalid, UDP MUST silently discard the datagram.
-            An application MAY optionally be able to control whether UDP
-            datagrams without checksums should be discarded or passed to
-            the application.
-
-            DISCUSSION:
-                 Some applications that normally run only across local
-                 area networks have chosen to turn off UDP checksums for
-
-
-
-Internet Engineering Task Force                                [Page 78]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- UDP             October 1989
-
-
-                 efficiency.  As a result, numerous cases of undetected
-                 errors have been reported.  The advisability of ever
-                 turning off UDP checksumming is very controversial.
-
-            IMPLEMENTATION:
-                 There is a common implementation error in UDP
-                 checksums.  Unlike the TCP checksum, the UDP checksum
-                 is optional; the value zero is transmitted in the
-                 checksum field of a UDP header to indicate the absence
-                 of a checksum.  If the transmitter really calculates a
-                 UDP checksum of zero, it must transmit the checksum as
-                 all 1's (65535).  No special action is required at the
-                 receiver, since zero and 65535 are equivalent in 1's
-                 complement arithmetic.
-
-         4.1.3.5  UDP Multihoming
-
-            When a UDP datagram is received, its specific-destination
-            address MUST be passed up to the application layer.
-
-            An application program MUST be able to specify the IP source
-            address to be used for sending a UDP datagram or to leave it
-            unspecified (in which case the networking software will
-            choose an appropriate source address).  There SHOULD be a
-            way to communicate the chosen source address up to the
-            application layer (e.g, so that the application can later
-            receive a reply datagram only from the corresponding
-            interface).
-
-            DISCUSSION:
-                 A request/response application that uses UDP should use
-                 a source address for the response that is the same as
-                 the specific destination address of the request.  See
-                 the "General Issues" section of [INTRO:1].
-
-         4.1.3.6  Invalid Addresses
-
-            A UDP datagram received with an invalid IP source address
-            (e.g., a broadcast or multicast address) must be discarded
-            by UDP or by the IP layer (see Section 3.2.1.3).
-
-            When a host sends a UDP datagram, the source address MUST be
-            (one of) the IP address(es) of the host.
-
-      4.1.4  UDP/APPLICATION LAYER INTERFACE
-
-         The application interface to UDP MUST provide the full services
-         of the IP/transport interface described in Section 3.4 of this
-
-
-
-Internet Engineering Task Force                                [Page 79]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- UDP             October 1989
-
-
-         document.  Thus, an application using UDP needs the functions
-         of the GET_SRCADDR(), GET_MAXSIZES(), ADVISE_DELIVPROB(), and
-         RECV_ICMP() calls described in Section 3.4.  For example,
-         GET_MAXSIZES() can be used to learn the effective maximum UDP
-         maximum datagram size for a particular {interface,remote
-         host,TOS} triplet.
-
-         An application-layer program MUST be able to set the TTL and
-         TOS values as well as IP options for sending a UDP datagram,
-         and these values must be passed transparently to the IP layer.
-         UDP MAY pass the received TOS up to the application layer.
-
-      4.1.5  UDP REQUIREMENTS SUMMARY
-
-
-                                                 |        | | | |S| |
-                                                 |        | | | |H| |F
-                                                 |        | | | |O|M|o
-                                                 |        | |S| |U|U|o
-                                                 |        | |H| |L|S|t
-                                                 |        |M|O| |D|T|n
-                                                 |        |U|U|M| | |o
-                                                 |        |S|L|A|N|N|t
-                                                 |        |T|D|Y|O|O|t
-FEATURE                                          |SECTION | | | |T|T|e
--------------------------------------------------|--------|-|-|-|-|-|--
-                                                 |        | | | | | |
-    UDP                                          |        | | | | | |
--------------------------------------------------|--------|-|-|-|-|-|--
-                                                 |        | | | | | |
-UDP send Port Unreachable                        |4.1.3.1 | |x| | | |
-                                                 |        | | | | | |
-IP Options in UDP                                |        | | | | | |
- - Pass rcv'd IP options to applic layer         |4.1.3.2 |x| | | | |
- - Applic layer can specify IP options in Send   |4.1.3.2 |x| | | | |
- - UDP passes IP options down to IP layer        |4.1.3.2 |x| | | | |
-                                                 |        | | | | | |
-Pass ICMP msgs up to applic layer                |4.1.3.3 |x| | | | |
-                                                 |        | | | | | |
-UDP checksums:                                   |        | | | | | |
- - Able to generate/check checksum               |4.1.3.4 |x| | | | |
- - Silently discard bad checksum                 |4.1.3.4 |x| | | | |
- - Sender Option to not generate checksum        |4.1.3.4 | | |x| | |
-   - Default is to checksum                      |4.1.3.4 |x| | | | |
- - Receiver Option to require checksum           |4.1.3.4 | | |x| | |
-                                                 |        | | | | | |
-UDP Multihoming                                  |        | | | | | |
- - Pass spec-dest addr to application            |4.1.3.5 |x| | | | |
-
-
-
-Internet Engineering Task Force                                [Page 80]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- UDP             October 1989
-
-
- - Applic layer can specify Local IP addr        |4.1.3.5 |x| | | | |
- - Applic layer specify wild Local IP addr       |4.1.3.5 |x| | | | |
- - Applic layer notified of Local IP addr used   |4.1.3.5 | |x| | | |
-                                                 |        | | | | | |
-Bad IP src addr silently discarded by UDP/IP     |4.1.3.6 |x| | | | |
-Only send valid IP source address                |4.1.3.6 |x| | | | |
-UDP Application Interface Services               |        | | | | | |
-Full IP interface of 3.4 for application         |4.1.4   |x| | | | |
- - Able to spec TTL, TOS, IP opts when send dg   |4.1.4   |x| | | | |
- - Pass received TOS up to applic layer          |4.1.4   | | |x| | |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 81]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-   4.2  TRANSMISSION CONTROL PROTOCOL -- TCP
-
-      4.2.1  INTRODUCTION
-
-         The Transmission Control Protocol TCP [TCP:1] is the primary
-         virtual-circuit transport protocol for the Internet suite.  TCP
-         provides reliable, in-sequence delivery of a full-duplex stream
-         of octets (8-bit bytes).  TCP is used by those applications
-         needing reliable, connection-oriented transport service, e.g.,
-         mail (SMTP), file transfer (FTP), and virtual terminal service
-         (Telnet); requirements for these application-layer protocols
-         are described in [INTRO:1].
-
-      4.2.2  PROTOCOL WALK-THROUGH
-
-         4.2.2.1  Well-Known Ports: RFC-793 Section 2.7
-
-            DISCUSSION:
-                 TCP reserves port numbers in the range 0-255 for
-                 "well-known" ports, used to access services that are
-                 standardized across the Internet.  The remainder of the
-                 port space can be freely allocated to application
-                 processes.  Current well-known port definitions are
-                 listed in the RFC entitled "Assigned Numbers"
-                 [INTRO:6].  A prerequisite for defining a new well-
-                 known port is an RFC documenting the proposed service
-                 in enough detail to allow new implementations.
-
-                 Some systems extend this notion by adding a third
-                 subdivision of the TCP port space: reserved ports,
-                 which are generally used for operating-system-specific
-                 services.  For example, reserved ports might fall
-                 between 256 and some system-dependent upper limit.
-                 Some systems further choose to protect well-known and
-                 reserved ports by permitting only privileged users to
-                 open TCP connections with those port values.  This is
-                 perfectly reasonable as long as the host does not
-                 assume that all hosts protect their low-numbered ports
-                 in this manner.
-
-         4.2.2.2  Use of Push: RFC-793 Section 2.8
-
-            When an application issues a series of SEND calls without
-            setting the PUSH flag, the TCP MAY aggregate the data
-            internally without sending it.  Similarly, when a series of
-            segments is received without the PSH bit, a TCP MAY queue
-            the data internally without passing it to the receiving
-            application.
-
-
-
-Internet Engineering Task Force                                [Page 82]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-            The PSH bit is not a record marker and is independent of
-            segment boundaries.  The transmitter SHOULD collapse
-            successive PSH bits when it packetizes data, to send the
-            largest possible segment.
-
-            A TCP MAY implement PUSH flags on SEND calls.  If PUSH flags
-            are not implemented, then the sending TCP: (1) must not
-            buffer data indefinitely, and (2) MUST set the PSH bit in
-            the last buffered segment (i.e., when there is no more
-            queued data to be sent).
-
-            The discussion in RFC-793 on pages 48, 50, and 74
-            erroneously implies that a received PSH flag must be passed
-            to the application layer.  Passing a received PSH flag to
-            the application layer is now OPTIONAL.
-
-            An application program is logically required to set the PUSH
-            flag in a SEND call whenever it needs to force delivery of
-            the data to avoid a communication deadlock.  However, a TCP
-            SHOULD send a maximum-sized segment whenever possible, to
-            improve performance (see Section 4.2.3.4).
-
-            DISCUSSION:
-                 When the PUSH flag is not implemented on SEND calls,
-                 i.e., when the application/TCP interface uses a pure
-                 streaming model, responsibility for aggregating any
-                 tiny data fragments to form reasonable sized segments
-                 is partially borne by the application layer.
-
-                 Generally, an interactive application protocol must set
-                 the PUSH flag at least in the last SEND call in each
-                 command or response sequence.  A bulk transfer protocol
-                 like FTP should set the PUSH flag on the last segment
-                 of a file or when necessary to prevent buffer deadlock.
-
-                 At the receiver, the PSH bit forces buffered data to be
-                 delivered to the application (even if less than a full
-                 buffer has been received). Conversely, the lack of a
-                 PSH bit can be used to avoid unnecessary wakeup calls
-                 to the application process; this can be an important
-                 performance optimization for large timesharing hosts.
-                 Passing the PSH bit to the receiving application allows
-                 an analogous optimization within the application.
-
-         4.2.2.3  Window Size: RFC-793 Section 3.1
-
-            The window size MUST be treated as an unsigned number, or
-            else large window sizes will appear like negative windows
-
-
-
-Internet Engineering Task Force                                [Page 83]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-            and TCP will not work.  It is RECOMMENDED that
-            implementations reserve 32-bit fields for the send and
-            receive window sizes in the connection record and do all
-            window computations with 32 bits.
-
-            DISCUSSION:
-                 It is known that the window field in the TCP header is
-                 too small for high-speed, long-delay paths.
-                 Experimental TCP options have been defined to extend
-                 the window size; see for example [TCP:11].  In
-                 anticipation of the adoption of such an extension, TCP
-                 implementors should treat windows as 32 bits.
-
-         4.2.2.4  Urgent Pointer: RFC-793 Section 3.1
-
-            The second sentence is in error: the urgent pointer points
-            to the sequence number of the LAST octet (not LAST+1) in a
-            sequence of urgent data.  The description on page 56 (last
-            sentence) is correct.
-
-            A TCP MUST support a sequence of urgent data of any length.
-
-            A TCP MUST inform the application layer asynchronously
-            whenever it receives an Urgent pointer and there was
-            previously no pending urgent data, or whenever the Urgent
-            pointer advances in the data stream.  There MUST be a way
-            for the application to learn how much urgent data remains to
-            be read from the connection, or at least to determine
-            whether or not more urgent data remains to be read.
-
-            DISCUSSION:
-                 Although the Urgent mechanism may be used for any
-                 application, it is normally used to send "interrupt"-
-                 type commands to a Telnet program (see "Using Telnet
-                 Synch Sequence" section in [INTRO:1]).
-
-                 The asynchronous or "out-of-band" notification will
-                 allow the application to go into "urgent mode", reading
-                 data from the TCP connection.  This allows control
-                 commands to be sent to an application whose normal
-                 input buffers are full of unprocessed data.
-
-            IMPLEMENTATION:
-                 The generic ERROR-REPORT() upcall described in Section
-                 4.2.4.1 is a possible mechanism for informing the
-                 application of the arrival of urgent data.
-
-
-
-
-
-Internet Engineering Task Force                                [Page 84]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-         4.2.2.5  TCP Options: RFC-793 Section 3.1
-
-            A TCP MUST be able to receive a TCP option in any segment.
-            A TCP MUST ignore without error any TCP option it does not
-            implement, assuming that the option has a length field (all
-            TCP options defined in the future will have length fields).
-            TCP MUST be prepared to handle an illegal option length
-            (e.g., zero) without crashing; a suggested procedure is to
-            reset the connection and log the reason.
-
-         4.2.2.6  Maximum Segment Size Option: RFC-793 Section 3.1
-
-            TCP MUST implement both sending and receiving the Maximum
-            Segment Size option [TCP:4].
-
-            TCP SHOULD send an MSS (Maximum Segment Size) option in
-            every SYN segment when its receive MSS differs from the
-            default 536, and MAY send it always.
-
-            If an MSS option is not received at connection setup, TCP
-            MUST assume a default send MSS of 536 (576-40) [TCP:4].
-
-            The maximum size of a segment that TCP really sends, the
-            "effective send MSS," MUST be the smaller of the send MSS
-            (which reflects the available reassembly buffer size at the
-            remote host) and the largest size permitted by the IP layer:
-
-               Eff.snd.MSS =
-
-                  min(SendMSS+20, MMS_S) - TCPhdrsize - IPoptionsize
-
-            where:
-
-            *    SendMSS is the MSS value received from the remote host,
-                 or the default 536 if no MSS option is received.
-
-            *    MMS_S is the maximum size for a transport-layer message
-                 that TCP may send.
-
-            *    TCPhdrsize is the size of the TCP header; this is
-                 normally 20, but may be larger if TCP options are to be
-                 sent.
-
-            *    IPoptionsize is the size of any IP options that TCP
-                 will pass to the IP layer with the current message.
-
-
-            The MSS value to be sent in an MSS option must be less than
-
-
-
-Internet Engineering Task Force                                [Page 85]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-            or equal to:
-
-               MMS_R - 20
-
-            where MMS_R is the maximum size for a transport-layer
-            message that can be received (and reassembled).  TCP obtains
-            MMS_R and MMS_S from the IP layer; see the generic call
-            GET_MAXSIZES in Section 3.4.
-
-            DISCUSSION:
-                 The choice of TCP segment size has a strong effect on
-                 performance.  Larger segments increase throughput by
-                 amortizing header size and per-datagram processing
-                 overhead over more data bytes; however, if the packet
-                 is so large that it causes IP fragmentation, efficiency
-                 drops sharply if any fragments are lost [IP:9].
-
-                 Some TCP implementations send an MSS option only if the
-                 destination host is on a non-connected network.
-                 However, in general the TCP layer may not have the
-                 appropriate information to make this decision, so it is
-                 preferable to leave to the IP layer the task of
-                 determining a suitable MTU for the Internet path.  We
-                 therefore recommend that TCP always send the option (if
-                 not 536) and that the IP layer determine MMS_R as
-                 specified in 3.3.3 and 3.4.  A proposed IP-layer
-                 mechanism to measure the MTU would then modify the IP
-                 layer without changing TCP.
-
-         4.2.2.7  TCP Checksum: RFC-793 Section 3.1
-
-            Unlike the UDP checksum (see Section 4.1.3.4), the TCP
-            checksum is never optional.  The sender MUST generate it and
-            the receiver MUST check it.
-
-         4.2.2.8  TCP Connection State Diagram: RFC-793 Section 3.2,
-            page 23
-
-            There are several problems with this diagram:
-
-            (a)  The arrow from SYN-SENT to SYN-RCVD should be labeled
-                 with "snd SYN,ACK", to agree with the text on page 68
-                 and with Figure 8.
-
-            (b)  There could be an arrow from SYN-RCVD state to LISTEN
-                 state, conditioned on receiving a RST after a passive
-                 open (see text page 70).
-
-
-
-
-Internet Engineering Task Force                                [Page 86]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-            (c)  It is possible to go directly from FIN-WAIT-1 to the
-                 TIME-WAIT state (see page 75 of the spec).
-
-
-         4.2.2.9  Initial Sequence Number Selection: RFC-793 Section
-            3.3, page 27
-
-            A TCP MUST use the specified clock-driven selection of
-            initial sequence numbers.
-
-         4.2.2.10  Simultaneous Open Attempts: RFC-793 Section 3.4, page
-            32
-
-            There is an error in Figure 8: the packet on line 7 should
-            be identical to the packet on line 5.
-
-            A TCP MUST support simultaneous open attempts.
-
-            DISCUSSION:
-                 It sometimes surprises implementors that if two
-                 applications attempt to simultaneously connect to each
-                 other, only one connection is generated instead of two.
-                 This was an intentional design decision; don't try to
-                 "fix" it.
-
-         4.2.2.11  Recovery from Old Duplicate SYN: RFC-793 Section 3.4,
-            page 33
-
-            Note that a TCP implementation MUST keep track of whether a
-            connection has reached SYN_RCVD state as the result of a
-            passive OPEN or an active OPEN.
-
-         4.2.2.12  RST Segment: RFC-793 Section 3.4
-
-            A TCP SHOULD allow a received RST segment to include data.
-
-            DISCUSSION
-                 It has been suggested that a RST segment could contain
-                 ASCII text that encoded and explained the cause of the
-                 RST.  No standard has yet been established for such
-                 data.
-
-         4.2.2.13  Closing a Connection: RFC-793 Section 3.5
-
-            A TCP connection may terminate in two ways: (1) the normal
-            TCP close sequence using a FIN handshake, and (2) an "abort"
-            in which one or more RST segments are sent and the
-            connection state is immediately discarded.  If a TCP
-
-
-
-Internet Engineering Task Force                                [Page 87]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-            connection is closed by the remote site, the local
-            application MUST be informed whether it closed normally or
-            was aborted.
-
-            The normal TCP close sequence delivers buffered data
-            reliably in both directions.  Since the two directions of a
-            TCP connection are closed independently, it is possible for
-            a connection to be "half closed," i.e., closed in only one
-            direction, and a host is permitted to continue sending data
-            in the open direction on a half-closed connection.
-
-            A host MAY implement a "half-duplex" TCP close sequence, so
-            that an application that has called CLOSE cannot continue to
-            read data from the connection.  If such a host issues a
-            CLOSE call while received data is still pending in TCP, or
-            if new data is received after CLOSE is called, its TCP
-            SHOULD send a RST to show that data was lost.
-
-            When a connection is closed actively, it MUST linger in
-            TIME-WAIT state for a time 2xMSL (Maximum Segment Lifetime).
-            However, it MAY accept a new SYN from the remote TCP to
-            reopen the connection directly from TIME-WAIT state, if it:
-
-            (1)  assigns its initial sequence number for the new
-                 connection to be larger than the largest sequence
-                 number it used on the previous connection incarnation,
-                 and
-
-            (2)  returns to TIME-WAIT state if the SYN turns out to be
-                 an old duplicate.
-
-
-            DISCUSSION:
-                 TCP's full-duplex data-preserving close is a feature
-                 that is not included in the analogous ISO transport
-                 protocol TP4.
-
-                 Some systems have not implemented half-closed
-                 connections, presumably because they do not fit into
-                 the I/O model of their particular operating system.  On
-                 these systems, once an application has called CLOSE, it
-                 can no longer read input data from the connection; this
-                 is referred to as a "half-duplex" TCP close sequence.
-
-                 The graceful close algorithm of TCP requires that the
-                 connection state remain defined on (at least)  one end
-                 of the connection, for a timeout period of 2xMSL, i.e.,
-                 4 minutes.  During this period, the (remote socket,
-
-
-
-Internet Engineering Task Force                                [Page 88]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-                 local socket) pair that defines the connection is busy
-                 and cannot be reused.  To shorten the time that a given
-                 port pair is tied up, some TCPs allow a new SYN to be
-                 accepted in TIME-WAIT state.
-
-         4.2.2.14  Data Communication: RFC-793 Section 3.7, page 40
-
-            Since RFC-793 was written, there has been extensive work on
-            TCP algorithms to achieve efficient data communication.
-            Later sections of the present document describe required and
-            recommended TCP algorithms to determine when to send data
-            (Section 4.2.3.4), when to send an acknowledgment (Section
-            4.2.3.2), and when to update the window (Section 4.2.3.3).
-
-            DISCUSSION:
-                 One important performance issue is "Silly Window
-                 Syndrome" or "SWS" [TCP:5], a stable pattern of small
-                 incremental window movements resulting in extremely
-                 poor TCP performance.  Algorithms to avoid SWS are
-                 described below for both the sending side (Section
-                 4.2.3.4) and the receiving side (Section 4.2.3.3).
-
-                 In brief, SWS is caused by the receiver advancing the
-                 right window edge whenever it has any new buffer space
-                 available to receive data and by the sender using any
-                 incremental window, no matter how small, to send more
-                 data [TCP:5].  The result can be a stable pattern of
-                 sending tiny data segments, even though both sender and
-                 receiver have a large total buffer space for the
-                 connection.  SWS can only occur during the transmission
-                 of a large amount of data; if the connection goes
-                 quiescent, the problem will disappear.  It is caused by
-                 typical straightforward implementation of window
-                 management, but the sender and receiver algorithms
-                 given below will avoid it.
-
-                 Another important TCP performance issue is that some
-                 applications, especially remote login to character-at-
-                 a-time hosts, tend to send streams of one-octet data
-                 segments.  To avoid deadlocks, every TCP SEND call from
-                 such applications must be "pushed", either explicitly
-                 by the application or else implicitly by TCP.  The
-                 result may be a stream of TCP segments that contain one
-                 data octet each, which makes very inefficient use of
-                 the Internet and contributes to Internet congestion.
-                 The Nagle Algorithm described in Section 4.2.3.4
-                 provides a simple and effective solution to this
-                 problem.  It does have the effect of clumping
-
-
-
-Internet Engineering Task Force                                [Page 89]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-                 characters over Telnet connections; this may initially
-                 surprise users accustomed to single-character echo, but
-                 user acceptance has not been a problem.
-
-                 Note that the Nagle algorithm and the send SWS
-                 avoidance algorithm play complementary roles in
-                 improving performance.  The Nagle algorithm discourages
-                 sending tiny segments when the data to be sent
-                 increases in small increments, while the SWS avoidance
-                 algorithm discourages small segments resulting from the
-                 right window edge advancing in small increments.
-
-                 A careless implementation can send two or more
-                 acknowledgment segments per data segment received.  For
-                 example, suppose the receiver acknowledges every data
-                 segment immediately.  When the application program
-                 subsequently consumes the data and increases the
-                 available receive buffer space again, the receiver may
-                 send a second acknowledgment segment to update the
-                 window at the sender.  The extreme case occurs with
-                 single-character segments on TCP connections using the
-                 Telnet protocol for remote login service.  Some
-                 implementations have been observed in which each
-                 incoming 1-character segment generates three return
-                 segments: (1) the acknowledgment, (2) a one byte
-                 increase in the window, and (3) the echoed character,
-                 respectively.
-
-         4.2.2.15  Retransmission Timeout: RFC-793 Section 3.7, page 41
-
-            The algorithm suggested in RFC-793 for calculating the
-            retransmission timeout is now known to be inadequate; see
-            Section 4.2.3.1 below.
-
-            Recent work by Jacobson [TCP:7] on Internet congestion and
-            TCP retransmission stability has produced a transmission
-            algorithm combining "slow start" with "congestion
-            avoidance".  A TCP MUST implement this algorithm.
-
-            If a retransmitted packet is identical to the original
-            packet (which implies not only that the data boundaries have
-            not changed, but also that the window and acknowledgment
-            fields of the header have not changed), then the same IP
-            Identification field MAY be used (see Section 3.2.1.5).
-
-            IMPLEMENTATION:
-                 Some TCP implementors have chosen to "packetize" the
-                 data stream, i.e., to pick segment boundaries when
-
-
-
-Internet Engineering Task Force                                [Page 90]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-                 segments are originally sent and to queue these
-                 segments in a "retransmission queue" until they are
-                 acknowledged.  Another design (which may be simpler) is
-                 to defer packetizing until each time data is
-                 transmitted or retransmitted, so there will be no
-                 segment retransmission queue.
-
-                 In an implementation with a segment retransmission
-                 queue, TCP performance may be enhanced by repacketizing
-                 the segments awaiting acknowledgment when the first
-                 retransmission timeout occurs.  That is, the
-                 outstanding segments that fitted would be combined into
-                 one maximum-sized segment, with a new IP Identification
-                 value.  The TCP would then retain this combined segment
-                 in the retransmit queue until it was acknowledged.
-                 However, if the first two segments in the
-                 retransmission queue totalled more than one maximum-
-                 sized segment, the TCP would retransmit only the first
-                 segment using the original IP Identification field.
-
-         4.2.2.16  Managing the Window: RFC-793 Section 3.7, page 41
-
-            A TCP receiver SHOULD NOT shrink the window, i.e., move the
-            right window edge to the left.  However, a sending TCP MUST
-            be robust against window shrinking, which may cause the
-            "useable window" (see Section 4.2.3.4) to become negative.
-
-            If this happens, the sender SHOULD NOT send new data, but
-            SHOULD retransmit normally the old unacknowledged data
-            between SND.UNA and SND.UNA+SND.WND.  The sender MAY also
-            retransmit old data beyond SND.UNA+SND.WND, but SHOULD NOT
-            time out the connection if data beyond the right window edge
-            is not acknowledged.  If the window shrinks to zero, the TCP
-            MUST probe it in the standard way (see next Section).
-
-            DISCUSSION:
-                 Many TCP implementations become confused if the window
-                 shrinks from the right after data has been sent into a
-                 larger window.  Note that TCP has a heuristic to select
-                 the latest window update despite possible datagram
-                 reordering; as a result, it may ignore a window update
-                 with a smaller window than previously offered if
-                 neither the sequence number nor the acknowledgment
-                 number is increased.
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 91]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-         4.2.2.17  Probing Zero Windows: RFC-793 Section 3.7, page 42
-
-            Probing of zero (offered) windows MUST be supported.
-
-            A TCP MAY keep its offered receive window closed
-            indefinitely.  As long as the receiving TCP continues to
-            send acknowledgments in response to the probe segments, the
-            sending TCP MUST allow the connection to stay open.
-
-            DISCUSSION:
-                 It is extremely important to remember that ACK
-                 (acknowledgment) segments that contain no data are not
-                 reliably transmitted by TCP.  If zero window probing is
-                 not supported, a connection may hang forever when an
-                 ACK segment that re-opens the window is lost.
-
-                 The delay in opening a zero window generally occurs
-                 when the receiving application stops taking data from
-                 its TCP.  For example, consider a printer daemon
-                 application, stopped because the printer ran out of
-                 paper.
-
-            The transmitting host SHOULD send the first zero-window
-            probe when a zero window has existed for the retransmission
-            timeout period (see Section 4.2.2.15), and SHOULD increase
-            exponentially the interval between successive probes.
-
-            DISCUSSION:
-                 This procedure minimizes delay if the zero-window
-                 condition is due to a lost ACK segment containing a
-                 window-opening update.  Exponential backoff is
-                 recommended, possibly with some maximum interval not
-                 specified here.  This procedure is similar to that of
-                 the retransmission algorithm, and it may be possible to
-                 combine the two procedures in the implementation.
-
-         4.2.2.18  Passive OPEN Calls:  RFC-793 Section 3.8
-
-            Every passive OPEN call either creates a new connection
-            record in LISTEN state, or it returns an error; it MUST NOT
-            affect any previously created connection record.
-
-            A TCP that supports multiple concurrent users MUST provide
-            an OPEN call that will functionally allow an application to
-            LISTEN on a port while a connection block with the same
-            local port is in SYN-SENT or SYN-RECEIVED state.
-
-            DISCUSSION:
-
-
-
-Internet Engineering Task Force                                [Page 92]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-                 Some applications (e.g., SMTP servers) may need to
-                 handle multiple connection attempts at about the same
-                 time.  The probability of a connection attempt failing
-                 is reduced by giving the application some means of
-                 listening for a new connection at the same time that an
-                 earlier connection attempt is going through the three-
-                 way handshake.
-
-            IMPLEMENTATION:
-                 Acceptable implementations of concurrent opens may
-                 permit multiple passive OPEN calls, or they may allow
-                 "cloning" of LISTEN-state connections from a single
-                 passive OPEN call.
-
-         4.2.2.19  Time to Live: RFC-793 Section 3.9, page 52
-
-            RFC-793 specified that TCP was to request the IP layer to
-            send TCP segments with TTL = 60.  This is obsolete; the TTL
-            value used to send TCP segments MUST be configurable.  See
-            Section 3.2.1.7 for discussion.
-
-         4.2.2.20  Event Processing: RFC-793 Section 3.9
-
-            While it is not strictly required, a TCP SHOULD be capable
-            of queueing out-of-order TCP segments.  Change the "may" in
-            the last sentence of the first paragraph on page 70 to
-            "should".
-
-            DISCUSSION:
-                 Some small-host implementations have omitted segment
-                 queueing because of limited buffer space.  This
-                 omission may be expected to adversely affect TCP
-                 throughput, since loss of a single segment causes all
-                 later segments to appear to be "out of sequence".
-
-            In general, the processing of received segments MUST be
-            implemented to aggregate ACK segments whenever possible.
-            For example, if the TCP is processing a series of queued
-            segments, it MUST process them all before sending any ACK
-            segments.
-
-            Here are some detailed error corrections and notes on the
-            Event Processing section of RFC-793.
-
-            (a)  CLOSE Call, CLOSE-WAIT state, p. 61: enter LAST-ACK
-                 state, not CLOSING.
-
-            (b)  LISTEN state, check for SYN (pp. 65, 66): With a SYN
-
-
-
-Internet Engineering Task Force                                [Page 93]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-                 bit, if the security/compartment or the precedence is
-                 wrong for the segment, a reset is sent.  The wrong form
-                 of reset is shown in the text; it should be:
-
-                   <SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>
-
-
-            (c)  SYN-SENT state, Check for SYN, p. 68: When the
-                 connection enters ESTABLISHED state, the following
-                 variables must be set:
-                    SND.WND <- SEG.WND
-                    SND.WL1 <- SEG.SEQ
-                    SND.WL2 <- SEG.ACK
-
-
-            (d)  Check security and precedence, p. 71: The first heading
-                 "ESTABLISHED STATE" should really be a list of all
-                 states other than SYN-RECEIVED: ESTABLISHED, FIN-WAIT-
-                 1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, and
-                 TIME-WAIT.
-
-            (e)  Check SYN bit, p. 71:  "In SYN-RECEIVED state and if
-                 the connection was initiated with a passive OPEN, then
-                 return this connection to the LISTEN state and return.
-                 Otherwise...".
-
-            (f)  Check ACK field, SYN-RECEIVED state, p. 72: When the
-                 connection enters ESTABLISHED state, the variables
-                 listed in (c) must be set.
-
-            (g)  Check ACK field, ESTABLISHED state, p. 72: The ACK is a
-                 duplicate if SEG.ACK =< SND.UNA (the = was omitted).
-                 Similarly, the window should be updated if: SND.UNA =<
-                 SEG.ACK =< SND.NXT.
-
-            (h)  USER TIMEOUT, p. 77:
-
-                 It would be better to notify the application of the
-                 timeout rather than letting TCP force the connection
-                 closed.  However, see also Section 4.2.3.5.
-
-
-         4.2.2.21  Acknowledging Queued Segments: RFC-793 Section 3.9
-
-            A TCP MAY send an ACK segment acknowledging RCV.NXT when a
-            valid segment arrives that is in the window but not at the
-            left window edge.
-
-
-
-
-Internet Engineering Task Force                                [Page 94]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-            DISCUSSION:
-                 RFC-793 (see page 74) was ambiguous about whether or
-                 not an ACK segment should be sent when an out-of-order
-                 segment was received, i.e., when SEG.SEQ was unequal to
-                 RCV.NXT.
-
-                 One reason for ACKing out-of-order segments might be to
-                 support an experimental algorithm known as "fast
-                 retransmit".   With this algorithm, the sender uses the
-                 "redundant" ACK's to deduce that a segment has been
-                 lost before the retransmission timer has expired.  It
-                 counts the number of times an ACK has been received
-                 with the same value of SEG.ACK and with the same right
-                 window edge.  If more than a threshold number of such
-                 ACK's is received, then the segment containing the
-                 octets starting at SEG.ACK is assumed to have been lost
-                 and is retransmitted, without awaiting a timeout.  The
-                 threshold is chosen to compensate for the maximum
-                 likely segment reordering in the Internet.  There is
-                 not yet enough experience with the fast retransmit
-                 algorithm to determine how useful it is.
-
-      4.2.3  SPECIFIC ISSUES
-
-         4.2.3.1  Retransmission Timeout Calculation
-
-            A host TCP MUST implement Karn's algorithm and Jacobson's
-            algorithm for computing the retransmission timeout ("RTO").
-
-            o    Jacobson's algorithm for computing the smoothed round-
-                 trip ("RTT") time incorporates a simple measure of the
-                 variance [TCP:7].
-
-            o    Karn's algorithm for selecting RTT measurements ensures
-                 that ambiguous round-trip times will not corrupt the
-                 calculation of the smoothed round-trip time [TCP:6].
-
-            This implementation also MUST include "exponential backoff"
-            for successive RTO values for the same segment.
-            Retransmission of SYN segments SHOULD use the same algorithm
-            as data segments.
-
-            DISCUSSION:
-                 There were two known problems with the RTO calculations
-                 specified in RFC-793.  First, the accurate measurement
-                 of RTTs is difficult when there are retransmissions.
-                 Second, the algorithm to compute the smoothed round-
-                 trip time is inadequate [TCP:7], because it incorrectly
-
-
-
-Internet Engineering Task Force                                [Page 95]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-                 assumed that the variance in RTT values would be small
-                 and constant.  These problems were solved by Karn's and
-                 Jacobson's algorithm, respectively.
-
-                 The performance increase resulting from the use of
-                 these improvements varies from noticeable to dramatic.
-                 Jacobson's algorithm for incorporating the measured RTT
-                 variance is especially important on a low-speed link,
-                 where the natural variation of packet sizes causes a
-                 large variation in RTT.  One vendor found link
-                 utilization on a 9.6kb line went from 10% to 90% as a
-                 result of implementing Jacobson's variance algorithm in
-                 TCP.
-
-            The following values SHOULD be used to initialize the
-            estimation parameters for a new connection:
-
-            (a)  RTT = 0 seconds.
-
-            (b)  RTO = 3 seconds.  (The smoothed variance is to be
-                 initialized to the value that will result in this RTO).
-
-            The recommended upper and lower bounds on the RTO are known
-            to be inadequate on large internets.  The lower bound SHOULD
-            be measured in fractions of a second (to accommodate high
-            speed LANs) and the upper bound should be 2*MSL, i.e., 240
-            seconds.
-
-            DISCUSSION:
-                 Experience has shown that these initialization values
-                 are reasonable, and that in any case the Karn and
-                 Jacobson algorithms make TCP behavior reasonably
-                 insensitive to the initial parameter choices.
-
-         4.2.3.2  When to Send an ACK Segment
-
-            A host that is receiving a stream of TCP data segments can
-            increase efficiency in both the Internet and the hosts by
-            sending fewer than one ACK (acknowledgment) segment per data
-            segment received; this is known as a "delayed ACK" [TCP:5].
-
-            A TCP SHOULD implement a delayed ACK, but an ACK should not
-            be excessively delayed; in particular, the delay MUST be
-            less than 0.5 seconds, and in a stream of full-sized
-            segments there SHOULD be an ACK for at least every second
-            segment.
-
-            DISCUSSION:
-
-
-
-Internet Engineering Task Force                                [Page 96]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-                 A delayed ACK gives the application an opportunity to
-                 update the window and perhaps to send an immediate
-                 response.  In particular, in the case of character-mode
-                 remote login, a delayed ACK can reduce the number of
-                 segments sent by the server by a factor of 3 (ACK,
-                 window update, and echo character all combined in one
-                 segment).
-
-                 In addition, on some large multi-user hosts, a delayed
-                 ACK can substantially reduce protocol processing
-                 overhead by reducing the total number of packets to be
-                 processed [TCP:5].  However, excessive delays on ACK's
-                 can disturb the round-trip timing and packet "clocking"
-                 algorithms [TCP:7].
-
-         4.2.3.3  When to Send a Window Update
-
-            A TCP MUST include a SWS avoidance algorithm in the receiver
-            [TCP:5].
-
-            IMPLEMENTATION:
-                 The receiver's SWS avoidance algorithm determines when
-                 the right window edge may be advanced; this is
-                 customarily known as "updating the window".  This
-                 algorithm combines with the delayed ACK algorithm (see
-                 Section 4.2.3.2) to determine when an ACK segment
-                 containing the current window will really be sent to
-                 the receiver.  We use the notation of RFC-793; see
-                 Figures 4 and 5 in that document.
-
-                 The solution to receiver SWS is to avoid advancing the
-                 right window edge RCV.NXT+RCV.WND in small increments,
-                 even if data is received from the network in small
-                 segments.
-
-                 Suppose the total receive buffer space is RCV.BUFF.  At
-                 any given moment, RCV.USER octets of this total may be
-                 tied up with data that has been received and
-                 acknowledged but which the user process has not yet
-                 consumed.  When the connection is quiescent, RCV.WND =
-                 RCV.BUFF and RCV.USER = 0.
-
-                 Keeping the right window edge fixed as data arrives and
-                 is acknowledged requires that the receiver offer less
-                 than its full buffer space, i.e., the receiver must
-                 specify a RCV.WND that keeps RCV.NXT+RCV.WND constant
-                 as RCV.NXT increases.  Thus, the total buffer space
-                 RCV.BUFF is generally divided into three parts:
-
-
-
-Internet Engineering Task Force                                [Page 97]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-
-                 |<------- RCV.BUFF ---------------->|
-                      1             2            3
-             ----|---------|------------------|------|----
-                        RCV.NXT               ^
-                                           (Fixed)
-
-             1 - RCV.USER =  data received but not yet consumed;
-             2 - RCV.WND =   space advertised to sender;
-             3 - Reduction = space available but not yet
-                             advertised.
-
-
-                 The suggested SWS avoidance algorithm for the receiver
-                 is to keep RCV.NXT+RCV.WND fixed until the reduction
-                 satisfies:
-
-                      RCV.BUFF - RCV.USER - RCV.WND  >=
-
-                             min( Fr * RCV.BUFF, Eff.snd.MSS )
-
-                 where Fr is a fraction whose recommended value is 1/2,
-                 and Eff.snd.MSS is the effective send MSS for the
-                 connection (see Section 4.2.2.6).  When the inequality
-                 is satisfied, RCV.WND is set to RCV.BUFF-RCV.USER.
-
-                 Note that the general effect of this algorithm is to
-                 advance RCV.WND in increments of Eff.snd.MSS (for
-                 realistic receive buffers:  Eff.snd.MSS < RCV.BUFF/2).
-                 Note also that the receiver must use its own
-                 Eff.snd.MSS, assuming it is the same as the sender's.
-
-         4.2.3.4  When to Send Data
-
-            A TCP MUST include a SWS avoidance algorithm in the sender.
-
-            A TCP SHOULD implement the Nagle Algorithm [TCP:9] to
-            coalesce short segments.  However, there MUST be a way for
-            an application to disable the Nagle algorithm on an
-            individual connection.  In all cases, sending data is also
-            subject to the limitation imposed by the Slow Start
-            algorithm (Section 4.2.2.15).
-
-            DISCUSSION:
-                 The Nagle algorithm is generally as follows:
-
-                      If there is unacknowledged data (i.e., SND.NXT >
-                      SND.UNA), then the sending TCP buffers all user
-
-
-
-Internet Engineering Task Force                                [Page 98]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-                      data (regardless of the PSH bit), until the
-                      outstanding data has been acknowledged or until
-                      the TCP can send a full-sized segment (Eff.snd.MSS
-                      bytes; see Section 4.2.2.6).
-
-                 Some applications (e.g., real-time display window
-                 updates) require that the Nagle algorithm be turned
-                 off, so small data segments can be streamed out at the
-                 maximum rate.
-
-            IMPLEMENTATION:
-                 The sender's SWS avoidance algorithm is more difficult
-                 than the receivers's, because the sender does not know
-                 (directly) the receiver's total buffer space RCV.BUFF.
-                 An approach which has been found to work well is for
-                 the sender to calculate Max(SND.WND), the maximum send
-                 window it has seen so far on the connection, and to use
-                 this value as an estimate of RCV.BUFF.  Unfortunately,
-                 this can only be an estimate; the receiver may at any
-                 time reduce the size of RCV.BUFF.  To avoid a resulting
-                 deadlock, it is necessary to have a timeout to force
-                 transmission of data, overriding the SWS avoidance
-                 algorithm.  In practice, this timeout should seldom
-                 occur.
-
-                 The "useable window" [TCP:5] is:
-
-                      U = SND.UNA + SND.WND - SND.NXT
-
-                 i.e., the offered window less the amount of data sent
-                 but not acknowledged.  If D is the amount of data
-                 queued in the sending TCP but not yet sent, then the
-                 following set of rules is recommended.
-
-                 Send data:
-
-                 (1)  if a maximum-sized segment can be sent, i.e, if:
-
-                           min(D,U) >= Eff.snd.MSS;
-
-
-                 (2)  or if the data is pushed and all queued data can
-                      be sent now, i.e., if:
-
-                          [SND.NXT = SND.UNA and] PUSHED and D <= U
-
-                      (the bracketed condition is imposed by the Nagle
-                      algorithm);
-
-
-
-Internet Engineering Task Force                                [Page 99]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-                 (3)  or if at least a fraction Fs of the maximum window
-                      can be sent, i.e., if:
-
-                          [SND.NXT = SND.UNA and]
-
-                                  min(D.U) >= Fs * Max(SND.WND);
-
-
-                 (4)  or if data is PUSHed and the override timeout
-                      occurs.
-
-                 Here Fs is a fraction whose recommended value is 1/2.
-                 The override timeout should be in the range 0.1 - 1.0
-                 seconds.  It may be convenient to combine this timer
-                 with the timer used to probe zero windows (Section
-                 4.2.2.17).
-
-                 Finally, note that the SWS avoidance algorithm just
-                 specified is to be used instead of the sender-side
-                 algorithm contained in [TCP:5].
-
-         4.2.3.5  TCP Connection Failures
-
-            Excessive retransmission of the same segment by TCP
-            indicates some failure of the remote host or the Internet
-            path.  This failure may be of short or long duration.  The
-            following procedure MUST be used to handle excessive
-            retransmissions of data segments [IP:11]:
-
-            (a)  There are two thresholds R1 and R2 measuring the amount
-                 of retransmission that has occurred for the same
-                 segment.  R1 and R2 might be measured in time units or
-                 as a count of retransmissions.
-
-            (b)  When the number of transmissions of the same segment
-                 reaches or exceeds threshold R1, pass negative advice
-                 (see Section 3.3.1.4) to the IP layer, to trigger
-                 dead-gateway diagnosis.
-
-            (c)  When the number of transmissions of the same segment
-                 reaches a threshold R2 greater than R1, close the
-                 connection.
-
-            (d)  An application MUST be able to set the value for R2 for
-                 a particular connection.  For example, an interactive
-                 application might set R2 to "infinity," giving the user
-                 control over when to disconnect.
-
-
-
-
-Internet Engineering Task Force                               [Page 100]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-            (d)  TCP SHOULD inform the application of the delivery
-                 problem (unless such information has been disabled by
-                 the application; see Section 4.2.4.1), when R1 is
-                 reached and before R2.  This will allow a remote login
-                 (User Telnet) application program to inform the user,
-                 for example.
-
-            The value of R1 SHOULD correspond to at least 3
-            retransmissions, at the current RTO.  The value of R2 SHOULD
-            correspond to at least 100 seconds.
-
-            An attempt to open a TCP connection could fail with
-            excessive retransmissions of the SYN segment or by receipt
-            of a RST segment or an ICMP Port Unreachable.  SYN
-            retransmissions MUST be handled in the general way just
-            described for data retransmissions, including notification
-            of the application layer.
-
-            However, the values of R1 and R2 may be different for SYN
-            and data segments.  In particular, R2 for a SYN segment MUST
-            be set large enough to provide retransmission of the segment
-            for at least 3 minutes.  The application can close the
-            connection (i.e., give up on the open attempt) sooner, of
-            course.
-
-            DISCUSSION:
-                 Some Internet paths have significant setup times, and
-                 the number of such paths is likely to increase in the
-                 future.
-
-         4.2.3.6  TCP Keep-Alives
-
-            Implementors MAY include "keep-alives" in their TCP
-            implementations, although this practice is not universally
-            accepted.  If keep-alives are included, the application MUST
-            be able to turn them on or off for each TCP connection, and
-            they MUST default to off.
-
-            Keep-alive packets MUST only be sent when no data or
-            acknowledgement packets have been received for the
-            connection within an interval.  This interval MUST be
-            configurable and MUST default to no less than two hours.
-
-            It is extremely important to remember that ACK segments that
-            contain no data are not reliably transmitted by TCP.
-            Consequently, if a keep-alive mechanism is implemented it
-            MUST NOT interpret failure to respond to any specific probe
-            as a dead connection.
-
-
-
-Internet Engineering Task Force                               [Page 101]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-            An implementation SHOULD send a keep-alive segment with no
-            data; however, it MAY be configurable to send a keep-alive
-            segment containing one garbage octet, for compatibility with
-            erroneous TCP implementations.
-
-            DISCUSSION:
-                 A "keep-alive" mechanism periodically probes the other
-                 end of a connection when the connection is otherwise
-                 idle, even when there is no data to be sent.  The TCP
-                 specification does not include a keep-alive mechanism
-                 because it could:  (1) cause perfectly good connections
-                 to break during transient Internet failures; (2)
-                 consume unnecessary bandwidth ("if no one is using the
-                 connection, who cares if it is still good?"); and (3)
-                 cost money for an Internet path that charges for
-                 packets.
-
-                 Some TCP implementations, however, have included a
-                 keep-alive mechanism.  To confirm that an idle
-                 connection is still active, these implementations send
-                 a probe segment designed to elicit a response from the
-                 peer TCP.  Such a segment generally contains SEG.SEQ =
-                 SND.NXT-1 and may or may not contain one garbage octet
-                 of data.  Note that on a quiet connection SND.NXT =
-                 RCV.NXT, so that this SEG.SEQ will be outside the
-                 window.  Therefore, the probe causes the receiver to
-                 return an acknowledgment segment, confirming that the
-                 connection is still live.  If the peer has dropped the
-                 connection due to a network partition or a crash, it
-                 will respond with a RST instead of an acknowledgment
-                 segment.
-
-                 Unfortunately, some misbehaved TCP implementations fail
-                 to respond to a segment with SEG.SEQ = SND.NXT-1 unless
-                 the segment contains data.  Alternatively, an
-                 implementation could determine whether a peer responded
-                 correctly to keep-alive packets with no garbage data
-                 octet.
-
-                 A TCP keep-alive mechanism should only be invoked in
-                 server applications that might otherwise hang
-                 indefinitely and consume resources unnecessarily if a
-                 client crashes or aborts a connection during a network
-                 failure.
-
-
-
-
-
-
-
-Internet Engineering Task Force                               [Page 102]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-         4.2.3.7  TCP Multihoming
-
-            If an application on a multihomed host does not specify the
-            local IP address when actively opening a TCP connection,
-            then the TCP MUST ask the IP layer to select a local IP
-            address before sending the (first) SYN.  See the function
-            GET_SRCADDR() in Section 3.4.
-
-            At all other times, a previous segment has either been sent
-            or received on this connection, and TCP MUST use the same
-            local address is used that was used in those previous
-            segments.
-
-         4.2.3.8  IP Options
-
-            When received options are passed up to TCP from the IP
-            layer, TCP MUST ignore options that it does not understand.
-
-            A TCP MAY support the Time Stamp and Record Route options.
-
-            An application MUST be able to specify a source route when
-            it actively opens a TCP connection, and this MUST take
-            precedence over a source route received in a datagram.
-
-            When a TCP connection is OPENed passively and a packet
-            arrives with a completed IP Source Route option (containing
-            a return route), TCP MUST save the return route and use it
-            for all segments sent on this connection.  If a different
-            source route arrives in a later segment, the later
-            definition SHOULD override the earlier one.
-
-         4.2.3.9  ICMP Messages
-
-            TCP MUST act on an ICMP error message passed up from the IP
-            layer, directing it to the connection that created the
-            error.  The necessary demultiplexing information can be
-            found in the IP header contained within the ICMP message.
-
-            o    Source Quench
-
-                 TCP MUST react to a Source Quench by slowing
-                 transmission on the connection.  The RECOMMENDED
-                 procedure is for a Source Quench to trigger a "slow
-                 start," as if a retransmission timeout had occurred.
-
-            o    Destination Unreachable -- codes 0, 1, 5
-
-                 Since these Unreachable messages indicate soft error
-
-
-
-Internet Engineering Task Force                               [Page 103]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-                 conditions, TCP MUST NOT abort the connection, and it
-                 SHOULD make the information available to the
-                 application.
-
-                 DISCUSSION:
-                      TCP could report the soft error condition directly
-                      to the application layer with an upcall to the
-                      ERROR_REPORT routine, or it could merely note the
-                      message and report it to the application only when
-                      and if the TCP connection times out.
-
-            o    Destination Unreachable -- codes 2-4
-
-                 These are hard error conditions, so TCP SHOULD abort
-                 the connection.
-
-            o    Time Exceeded -- codes 0, 1
-
-                 This should be handled the same way as Destination
-                 Unreachable codes 0, 1, 5 (see above).
-
-            o    Parameter Problem
-
-                 This should be handled the same way as Destination
-                 Unreachable codes 0, 1, 5 (see above).
-
-
-         4.2.3.10  Remote Address Validation
-
-            A TCP implementation MUST reject as an error a local OPEN
-            call for an invalid remote IP address (e.g., a broadcast or
-            multicast address).
-
-            An incoming SYN with an invalid source address must be
-            ignored either by TCP or by the IP layer (see Section
-            3.2.1.3).
-
-            A TCP implementation MUST silently discard an incoming SYN
-            segment that is addressed to a broadcast or multicast
-            address.
-
-         4.2.3.11  TCP Traffic Patterns
-
-            IMPLEMENTATION:
-                 The TCP protocol specification [TCP:1] gives the
-                 implementor much freedom in designing the algorithms
-                 that control the message flow over the connection --
-                 packetizing, managing the window, sending
-
-
-
-Internet Engineering Task Force                               [Page 104]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-                 acknowledgments, etc.  These design decisions are
-                 difficult because a TCP must adapt to a wide range of
-                 traffic patterns.  Experience has shown that a TCP
-                 implementor needs to verify the design on two extreme
-                 traffic patterns:
-
-                 o    Single-character Segments
-
-                      Even if the sender is using the Nagle Algorithm,
-                      when a TCP connection carries remote login traffic
-                      across a low-delay LAN the receiver will generally
-                      get a stream of single-character segments.  If
-                      remote terminal echo mode is in effect, the
-                      receiver's system will generally echo each
-                      character as it is received.
-
-                 o    Bulk Transfer
-
-                      When TCP is used for bulk transfer, the data
-                      stream should be made up (almost) entirely of
-                      segments of the size of the effective MSS.
-                      Although TCP uses a sequence number space with
-                      byte (octet) granularity, in bulk-transfer mode
-                      its operation should be as if TCP used a sequence
-                      space that counted only segments.
-
-                 Experience has furthermore shown that a single TCP can
-                 effectively and efficiently handle these two extremes.
-
-                 The most important tool for verifying a new TCP
-                 implementation is a packet trace program.  There is a
-                 large volume of experience showing the importance of
-                 tracing a variety of traffic patterns with other TCP
-                 implementations and studying the results carefully.
-
-
-         4.2.3.12  Efficiency
-
-            IMPLEMENTATION:
-                 Extensive experience has led to the following
-                 suggestions for efficient implementation of TCP:
-
-                 (a)  Don't Copy Data
-
-                      In bulk data transfer, the primary CPU-intensive
-                      tasks are copying data from one place to another
-                      and checksumming the data.  It is vital to
-                      minimize the number of copies of TCP data.  Since
-
-
-
-Internet Engineering Task Force                               [Page 105]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-                      the ultimate speed limitation may be fetching data
-                      across the memory bus, it may be useful to combine
-                      the copy with checksumming, doing both with a
-                      single memory fetch.
-
-                 (b)  Hand-Craft the Checksum Routine
-
-                      A good TCP checksumming routine is typically two
-                      to five times faster than a simple and direct
-                      implementation of the definition.  Great care and
-                      clever coding are often required and advisable to
-                      make the checksumming code "blazing fast".  See
-                      [TCP:10].
-
-                 (c)  Code for the Common Case
-
-                      TCP protocol processing can be complicated, but
-                      for most segments there are only a few simple
-                      decisions to be made.  Per-segment processing will
-                      be greatly speeded up by coding the main line to
-                      minimize the number of decisions in the most
-                      common case.
-
-
-      4.2.4  TCP/APPLICATION LAYER INTERFACE
-
-         4.2.4.1  Asynchronous Reports
-
-            There MUST be a mechanism for reporting soft TCP error
-            conditions to the application.  Generically, we assume this
-            takes the form of an application-supplied ERROR_REPORT
-            routine that may be upcalled [INTRO:7] asynchronously from
-            the transport layer:
-
-               ERROR_REPORT(local connection name, reason, subreason)
-
-            The precise encoding of the reason and subreason parameters
-            is not specified here.  However, the conditions that are
-            reported asynchronously to the application MUST include:
-
-            *    ICMP error message arrived (see 4.2.3.9)
-
-            *    Excessive retransmissions (see 4.2.3.5)
-
-            *    Urgent pointer advance (see 4.2.2.4).
-
-            However, an application program that does not want to
-            receive such ERROR_REPORT calls SHOULD be able to
-
-
-
-Internet Engineering Task Force                               [Page 106]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-            effectively disable these calls.
-
-            DISCUSSION:
-                 These error reports generally reflect soft errors that
-                 can be ignored without harm by many applications.  It
-                 has been suggested that these error report calls should
-                 default to "disabled," but this is not required.
-
-         4.2.4.2  Type-of-Service
-
-            The application layer MUST be able to specify the Type-of-
-            Service (TOS) for segments that are sent on a connection.
-            It not required, but the application SHOULD be able to
-            change the TOS during the connection lifetime.  TCP SHOULD
-            pass the current TOS value without change to the IP layer,
-            when it sends segments on the connection.
-
-            The TOS will be specified independently in each direction on
-            the connection, so that the receiver application will
-            specify the TOS used for ACK segments.
-
-            TCP MAY pass the most recently received TOS up to the
-            application.
-
-            DISCUSSION
-                 Some applications (e.g., SMTP) change the nature of
-                 their communication during the lifetime of a
-                 connection, and therefore would like to change the TOS
-                 specification.
-
-                 Note also that the OPEN call specified in RFC-793
-                 includes a parameter ("options") in which the caller
-                 can specify IP options such as source route, record
-                 route, or timestamp.
-
-         4.2.4.3  Flush Call
-
-            Some TCP implementations have included a FLUSH call, which
-            will empty the TCP send queue of any data for which the user
-            has issued SEND calls but which is still to the right of the
-            current send window.  That is, it flushes as much queued
-            send data as possible without losing sequence number
-            synchronization.  This is useful for implementing the "abort
-            output" function of Telnet.
-
-
-
-
-
-
-
-Internet Engineering Task Force                               [Page 107]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-         4.2.4.4  Multihoming
-
-            The user interface outlined in sections 2.7 and 3.8 of RFC-
-            793 needs to be extended for multihoming.  The OPEN call
-            MUST have an optional parameter:
-
-                OPEN( ... [local IP address,] ... )
-
-            to allow the specification of the local IP address.
-
-            DISCUSSION:
-                 Some TCP-based applications need to specify the local
-                 IP address to be used to open a particular connection;
-                 FTP is an example.
-
-            IMPLEMENTATION:
-                 A passive OPEN call with a specified "local IP address"
-                 parameter will await an incoming connection request to
-                 that address.  If the parameter is unspecified, a
-                 passive OPEN will await an incoming connection request
-                 to any local IP address, and then bind the local IP
-                 address of the connection to the particular address
-                 that is used.
-
-                 For an active OPEN call, a specified "local IP address"
-                 parameter will be used for opening the connection.  If
-                 the parameter is unspecified, the networking software
-                 will choose an appropriate local IP address (see
-                 Section 3.3.4.2) for the connection
-
-      4.2.5  TCP REQUIREMENT SUMMARY
-
-                                                 |        | | | |S| |
-                                                 |        | | | |H| |F
-                                                 |        | | | |O|M|o
-                                                 |        | |S| |U|U|o
-                                                 |        | |H| |L|S|t
-                                                 |        |M|O| |D|T|n
-                                                 |        |U|U|M| | |o
-                                                 |        |S|L|A|N|N|t
-                                                 |        |T|D|Y|O|O|t
-FEATURE                                          |SECTION | | | |T|T|e
--------------------------------------------------|--------|-|-|-|-|-|--
-                                                 |        | | | | | |
-Push flag                                        |        | | | | | |
-  Aggregate or queue un-pushed data              |4.2.2.2 | | |x| | |
-  Sender collapse successive PSH flags           |4.2.2.2 | |x| | | |
-  SEND call can specify PUSH                     |4.2.2.2 | | |x| | |
-
-
-
-Internet Engineering Task Force                               [Page 108]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-    If cannot: sender buffer indefinitely        |4.2.2.2 | | | | |x|
-    If cannot: PSH last segment                  |4.2.2.2 |x| | | | |
-  Notify receiving ALP of PSH                    |4.2.2.2 | | |x| | |1
-  Send max size segment when possible            |4.2.2.2 | |x| | | |
-                                                 |        | | | | | |
-Window                                           |        | | | | | |
-  Treat as unsigned number                       |4.2.2.3 |x| | | | |
-  Handle as 32-bit number                        |4.2.2.3 | |x| | | |
-  Shrink window from right                       |4.2.2.16| | | |x| |
-  Robust against shrinking window                |4.2.2.16|x| | | | |
-  Receiver's window closed indefinitely          |4.2.2.17| | |x| | |
-  Sender probe zero window                       |4.2.2.17|x| | | | |
-    First probe after RTO                        |4.2.2.17| |x| | | |
-    Exponential backoff                          |4.2.2.17| |x| | | |
-  Allow window stay zero indefinitely            |4.2.2.17|x| | | | |
-  Sender timeout OK conn with zero wind          |4.2.2.17| | | | |x|
-                                                 |        | | | | | |
-Urgent Data                                      |        | | | | | |
-  Pointer points to last octet                   |4.2.2.4 |x| | | | |
-  Arbitrary length urgent data sequence          |4.2.2.4 |x| | | | |
-  Inform ALP asynchronously of urgent data       |4.2.2.4 |x| | | | |1
-  ALP can learn if/how much urgent data Q'd      |4.2.2.4 |x| | | | |1
-                                                 |        | | | | | |
-TCP Options                                      |        | | | | | |
-  Receive TCP option in any segment              |4.2.2.5 |x| | | | |
-  Ignore unsupported options                     |4.2.2.5 |x| | | | |
-  Cope with illegal option length                |4.2.2.5 |x| | | | |
-  Implement sending & receiving MSS option       |4.2.2.6 |x| | | | |
-  Send MSS option unless 536                     |4.2.2.6 | |x| | | |
-  Send MSS option always                         |4.2.2.6 | | |x| | |
-  Send-MSS default is 536                        |4.2.2.6 |x| | | | |
-  Calculate effective send seg size              |4.2.2.6 |x| | | | |
-                                                 |        | | | | | |
-TCP Checksums                                    |        | | | | | |
-  Sender compute checksum                        |4.2.2.7 |x| | | | |
-  Receiver check checksum                        |4.2.2.7 |x| | | | |
-                                                 |        | | | | | |
-Use clock-driven ISN selection                   |4.2.2.9 |x| | | | |
-                                                 |        | | | | | |
-Opening Connections                              |        | | | | | |
-  Support simultaneous open attempts             |4.2.2.10|x| | | | |
-  SYN-RCVD remembers last state                  |4.2.2.11|x| | | | |
-  Passive Open call interfere with others        |4.2.2.18| | | | |x|
-  Function: simultan. LISTENs for same port      |4.2.2.18|x| | | | |
-  Ask IP for src address for SYN if necc.        |4.2.3.7 |x| | | | |
-    Otherwise, use local addr of conn.           |4.2.3.7 |x| | | | |
-  OPEN to broadcast/multicast IP Address         |4.2.3.14| | | | |x|
-  Silently discard seg to bcast/mcast addr       |4.2.3.14|x| | | | |
-
-
-
-Internet Engineering Task Force                               [Page 109]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-                                                 |        | | | | | |
-Closing Connections                              |        | | | | | |
-  RST can contain data                           |4.2.2.12| |x| | | |
-  Inform application of aborted conn             |4.2.2.13|x| | | | |
-  Half-duplex close connections                  |4.2.2.13| | |x| | |
-    Send RST to indicate data lost               |4.2.2.13| |x| | | |
-  In TIME-WAIT state for 2xMSL seconds           |4.2.2.13|x| | | | |
-    Accept SYN from TIME-WAIT state              |4.2.2.13| | |x| | |
-                                                 |        | | | | | |
-Retransmissions                                  |        | | | | | |
-  Jacobson Slow Start algorithm                  |4.2.2.15|x| | | | |
-  Jacobson Congestion-Avoidance algorithm        |4.2.2.15|x| | | | |
-  Retransmit with same IP ident                  |4.2.2.15| | |x| | |
-  Karn's algorithm                               |4.2.3.1 |x| | | | |
-  Jacobson's RTO estimation alg.                 |4.2.3.1 |x| | | | |
-  Exponential backoff                            |4.2.3.1 |x| | | | |
-  SYN RTO calc same as data                      |4.2.3.1 | |x| | | |
-  Recommended initial values and bounds          |4.2.3.1 | |x| | | |
-                                                 |        | | | | | |
-Generating ACK's:                                |        | | | | | |
-  Queue out-of-order segments                    |4.2.2.20| |x| | | |
-  Process all Q'd before send ACK                |4.2.2.20|x| | | | |
-  Send ACK for out-of-order segment              |4.2.2.21| | |x| | |
-  Delayed ACK's                                  |4.2.3.2 | |x| | | |
-    Delay < 0.5 seconds                          |4.2.3.2 |x| | | | |
-    Every 2nd full-sized segment ACK'd           |4.2.3.2 |x| | | | |
-  Receiver SWS-Avoidance Algorithm               |4.2.3.3 |x| | | | |
-                                                 |        | | | | | |
-Sending data                                     |        | | | | | |
-  Configurable TTL                               |4.2.2.19|x| | | | |
-  Sender SWS-Avoidance Algorithm                 |4.2.3.4 |x| | | | |
-  Nagle algorithm                                |4.2.3.4 | |x| | | |
-    Application can disable Nagle algorithm      |4.2.3.4 |x| | | | |
-                                                 |        | | | | | |
-Connection Failures:                             |        | | | | | |
-  Negative advice to IP on R1 retxs              |4.2.3.5 |x| | | | |
-  Close connection on R2 retxs                   |4.2.3.5 |x| | | | |
-  ALP can set R2                                 |4.2.3.5 |x| | | | |1
-  Inform ALP of  R1<=retxs<R2                    |4.2.3.5 | |x| | | |1
-  Recommended values for R1, R2                  |4.2.3.5 | |x| | | |
-  Same mechanism for SYNs                        |4.2.3.5 |x| | | | |
-    R2 at least 3 minutes for SYN                |4.2.3.5 |x| | | | |
-                                                 |        | | | | | |
-Send Keep-alive Packets:                         |4.2.3.6 | | |x| | |
-  - Application can request                      |4.2.3.6 |x| | | | |
-  - Default is "off"                             |4.2.3.6 |x| | | | |
-  - Only send if idle for interval               |4.2.3.6 |x| | | | |
-  - Interval configurable                        |4.2.3.6 |x| | | | |
-
-
-
-Internet Engineering Task Force                               [Page 110]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-  - Default at least 2 hrs.                      |4.2.3.6 |x| | | | |
-  - Tolerant of lost ACK's                       |4.2.3.6 |x| | | | |
-                                                 |        | | | | | |
-IP Options                                       |        | | | | | |
-  Ignore options TCP doesn't understand          |4.2.3.8 |x| | | | |
-  Time Stamp support                             |4.2.3.8 | | |x| | |
-  Record Route support                           |4.2.3.8 | | |x| | |
-  Source Route:                                  |        | | | | | |
-    ALP can specify                              |4.2.3.8 |x| | | | |1
-      Overrides src rt in datagram               |4.2.3.8 |x| | | | |
-    Build return route from src rt               |4.2.3.8 |x| | | | |
-    Later src route overrides                    |4.2.3.8 | |x| | | |
-                                                 |        | | | | | |
-Receiving ICMP Messages from IP                  |4.2.3.9 |x| | | | |
-  Dest. Unreach (0,1,5) => inform ALP            |4.2.3.9 | |x| | | |
-  Dest. Unreach (0,1,5) => abort conn            |4.2.3.9 | | | | |x|
-  Dest. Unreach (2-4) => abort conn              |4.2.3.9 | |x| | | |
-  Source Quench => slow start                    |4.2.3.9 | |x| | | |
-  Time Exceeded => tell ALP, don't abort         |4.2.3.9 | |x| | | |
-  Param Problem => tell ALP, don't abort         |4.2.3.9 | |x| | | |
-                                                 |        | | | | | |
-Address Validation                               |        | | | | | |
-  Reject OPEN call to invalid IP address         |4.2.3.10|x| | | | |
-  Reject SYN from invalid IP address             |4.2.3.10|x| | | | |
-  Silently discard SYN to bcast/mcast addr       |4.2.3.10|x| | | | |
-                                                 |        | | | | | |
-TCP/ALP Interface Services                       |        | | | | | |
-  Error Report mechanism                         |4.2.4.1 |x| | | | |
-  ALP can disable Error Report Routine           |4.2.4.1 | |x| | | |
-  ALP can specify TOS for sending                |4.2.4.2 |x| | | | |
-    Passed unchanged to IP                       |4.2.4.2 | |x| | | |
-  ALP can change TOS during connection           |4.2.4.2 | |x| | | |
-  Pass received TOS up to ALP                    |4.2.4.2 | | |x| | |
-  FLUSH call                                     |4.2.4.3 | | |x| | |
-  Optional local IP addr parm. in OPEN           |4.2.4.4 |x| | | | |
--------------------------------------------------|--------|-|-|-|-|-|--
--------------------------------------------------|--------|-|-|-|-|-|--
-
-FOOTNOTES:
-
-(1)  "ALP" means Application-Layer program.
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                               [Page 111]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-5.  REFERENCES
-
-INTRODUCTORY REFERENCES
-
-
-[INTRO:1] "Requirements for Internet Hosts -- Application and Support,"
-     IETF Host Requirements Working Group, R. Braden, Ed., RFC-1123,
-     October 1989.
-
-[INTRO:2]  "Requirements for Internet Gateways,"  R. Braden and J.
-     Postel, RFC-1009, June 1987.
-
-[INTRO:3]  "DDN Protocol Handbook," NIC-50004, NIC-50005, NIC-50006,
-     (three volumes), SRI International, December 1985.
-
-[INTRO:4]  "Official Internet Protocols," J. Reynolds and J. Postel,
-     RFC-1011, May 1987.
-
-     This document is republished periodically with new RFC numbers; the
-     latest version must be used.
-
-[INTRO:5]  "Protocol Document Order Information," O. Jacobsen and J.
-     Postel, RFC-980, March 1986.
-
-[INTRO:6]  "Assigned Numbers," J. Reynolds and J. Postel, RFC-1010, May
-     1987.
-
-     This document is republished periodically with new RFC numbers; the
-     latest version must be used.
-
-[INTRO:7] "Modularity and Efficiency in Protocol Implementations," D.
-     Clark, RFC-817, July 1982.
-
-[INTRO:8] "The Structuring of Systems Using Upcalls," D. Clark, 10th ACM
-     SOSP, Orcas Island, Washington, December 1985.
-
-
-Secondary References:
-
-
-[INTRO:9]  "A Protocol for Packet Network Intercommunication," V. Cerf
-     and R. Kahn, IEEE Transactions on Communication, May 1974.
-
-[INTRO:10]  "The ARPA Internet Protocol," J. Postel, C. Sunshine, and D.
-     Cohen, Computer Networks, Vol. 5, No. 4, July 1981.
-
-[INTRO:11]  "The DARPA Internet Protocol Suite," B. Leiner, J. Postel,
-     R. Cole and D. Mills, Proceedings INFOCOM 85, IEEE, Washington DC,
-
-
-
-Internet Engineering Task Force                               [Page 112]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-     March 1985.  Also in: IEEE Communications Magazine, March 1985.
-     Also available as ISI-RS-85-153.
-
-[INTRO:12] "Final Text of DIS8473, Protocol for Providing the
-     Connectionless Mode Network Service," ANSI, published as RFC-994,
-     March 1986.
-
-[INTRO:13] "End System to Intermediate System Routing Exchange
-     Protocol," ANSI X3S3.3, published as RFC-995, April 1986.
-
-
-LINK LAYER REFERENCES
-
-
-[LINK:1] "Trailer Encapsulations," S. Leffler and M. Karels, RFC-893,
-     April 1984.
-
-[LINK:2] "An Ethernet Address Resolution Protocol," D. Plummer, RFC-826,
-     November 1982.
-
-[LINK:3] "A Standard for the Transmission of IP Datagrams over Ethernet
-     Networks," C. Hornig, RFC-894, April 1984.
-
-[LINK:4] "A Standard for the Transmission of IP Datagrams over IEEE 802
-     "Networks," J. Postel and J. Reynolds, RFC-1042, February 1988.
-
-     This RFC contains a great deal of information of importance to
-     Internet implementers planning to use IEEE 802 networks.
-
-
-IP LAYER REFERENCES
-
-
-[IP:1] "Internet Protocol (IP)," J. Postel, RFC-791, September 1981.
-
-[IP:2] "Internet Control Message Protocol (ICMP)," J. Postel, RFC-792,
-     September 1981.
-
-[IP:3] "Internet Standard Subnetting Procedure," J. Mogul and J. Postel,
-     RFC-950, August 1985.
-
-[IP:4]  "Host Extensions for IP Multicasting," S. Deering, RFC-1112,
-     August 1989.
-
-[IP:5] "Military Standard Internet Protocol," MIL-STD-1777, Department
-     of Defense, August 1983.
-
-     This specification, as amended by RFC-963, is intended to describe
-
-
-
-Internet Engineering Task Force                               [Page 113]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-     the Internet Protocol but has some serious omissions (e.g., the
-     mandatory subnet extension [IP:3] and the optional multicasting
-     extension [IP:4]).  It is also out of date.  If there is a
-     conflict, RFC-791, RFC-792, and RFC-950 must be taken as
-     authoritative, while the present document is authoritative over
-     all.
-
-[IP:6] "Some Problems with the Specification of the Military Standard
-     Internet Protocol," D. Sidhu, RFC-963, November 1985.
-
-[IP:7] "The TCP Maximum Segment Size and Related Topics," J. Postel,
-     RFC-879, November 1983.
-
-     Discusses and clarifies the relationship between the TCP Maximum
-     Segment Size option and the IP datagram size.
-
-[IP:8] "Internet Protocol Security Options,"  B. Schofield, RFC-1108,
-     October 1989.
-
-[IP:9] "Fragmentation Considered Harmful," C. Kent and J. Mogul, ACM
-     SIGCOMM-87, August 1987.  Published as ACM Comp Comm Review, Vol.
-     17, no. 5.
-
-     This useful paper discusses the problems created by Internet
-     fragmentation and presents alternative solutions.
-
-[IP:10] "IP Datagram Reassembly Algorithms," D. Clark, RFC-815, July
-     1982.
-
-     This and the following paper should be read by every implementor.
-
-[IP:11] "Fault Isolation and Recovery," D. Clark, RFC-816, July 1982.
-
-SECONDARY IP REFERENCES:
-
-
-[IP:12] "Broadcasting Internet Datagrams in the Presence of Subnets," J.
-     Mogul, RFC-922, October 1984.
-
-[IP:13] "Name, Addresses, Ports, and Routes," D. Clark, RFC-814, July
-     1982.
-
-[IP:14] "Something a Host Could Do with Source Quench: The Source Quench
-     Introduced Delay (SQUID)," W. Prue and J. Postel, RFC-1016, July
-     1987.
-
-     This RFC first described directed broadcast addresses.  However,
-     the bulk of the RFC is concerned with gateways, not hosts.
-
-
-
-Internet Engineering Task Force                               [Page 114]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-UDP REFERENCES:
-
-
-[UDP:1] "User Datagram Protocol," J. Postel, RFC-768, August 1980.
-
-
-TCP REFERENCES:
-
-
-[TCP:1] "Transmission Control Protocol," J. Postel, RFC-793, September
-     1981.
-
-
-[TCP:2] "Transmission Control Protocol," MIL-STD-1778, US Department of
-     Defense, August 1984.
-
-     This specification as amended by RFC-964 is intended to describe
-     the same protocol as RFC-793 [TCP:1].  If there is a conflict,
-     RFC-793 takes precedence, and the present document is authoritative
-     over both.
-
-
-[TCP:3] "Some Problems with the Specification of the Military Standard
-     Transmission Control Protocol," D. Sidhu and T. Blumer, RFC-964,
-     November 1985.
-
-
-[TCP:4] "The TCP Maximum Segment Size and Related Topics," J. Postel,
-     RFC-879, November 1983.
-
-
-[TCP:5] "Window and Acknowledgment Strategy in TCP," D. Clark, RFC-813,
-     July 1982.
-
-
-[TCP:6] "Round Trip Time Estimation," P. Karn & C. Partridge, ACM
-     SIGCOMM-87, August 1987.
-
-
-[TCP:7] "Congestion Avoidance and Control," V. Jacobson, ACM SIGCOMM-88,
-     August 1988.
-
-
-SECONDARY TCP REFERENCES:
-
-
-[TCP:8] "Modularity and Efficiency in Protocol Implementation," D.
-     Clark, RFC-817, July 1982.
-
-
-
-Internet Engineering Task Force                               [Page 115]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-[TCP:9] "Congestion Control in IP/TCP," J. Nagle, RFC-896, January 1984.
-
-
-[TCP:10] "Computing the Internet Checksum," R. Braden, D. Borman, and C.
-     Partridge, RFC-1071, September 1988.
-
-
-[TCP:11] "TCP Extensions for Long-Delay Paths," V. Jacobson & R. Braden,
-     RFC-1072, October 1988.
-
-
-Security Considerations
-
-   There are many security issues in the communication layers of host
-   software, but a full discussion is beyond the scope of this RFC.
-
-   The Internet architecture generally provides little protection
-   against spoofing of IP source addresses, so any security mechanism
-   that is based upon verifying the IP source address of a datagram
-   should be treated with suspicion.  However, in restricted
-   environments some source-address checking may be possible.  For
-   example, there might be a secure LAN whose gateway to the rest of the
-   Internet discarded any incoming datagram with a source address that
-   spoofed the LAN address.  In this case, a host on the LAN could use
-   the source address to test for local vs. remote source.  This problem
-   is complicated by source routing, and some have suggested that
-   source-routed datagram forwarding by hosts (see Section 3.3.5) should
-   be outlawed for security reasons.
-
-   Security-related issues are mentioned in sections concerning the IP
-   Security option (Section 3.2.1.8), the ICMP Parameter Problem message
-   (Section 3.2.2.5), IP options in UDP datagrams (Section 4.1.3.2), and
-   reserved TCP ports (Section 4.2.2.1).
-
-Author's Address
-
-   Robert Braden
-   USC/Information Sciences Institute
-   4676 Admiralty Way
-   Marina del Rey, CA 90292-6695
-
-   Phone: (213) 822 1511
-
-   EMail: Braden@ISI.EDU
-
-
-
-
-
-
-
-Internet Engineering Task Force                               [Page 116]
-
diff --git a/contrib/bind9/doc/rfc/rfc1123.txt b/contrib/bind9/doc/rfc/rfc1123.txt
deleted file mode 100644
index 51cdf83..0000000
--- a/contrib/bind9/doc/rfc/rfc1123.txt
+++ /dev/null
@@ -1,5782 +0,0 @@
-
-
-
-
-
-
-Network Working Group                    Internet Engineering Task Force
-Request for Comments: 1123                             R. Braden, Editor
-                                                            October 1989
-
-
-       Requirements for Internet Hosts -- Application and Support
-
-Status of This Memo
-
-   This RFC is an official specification for the Internet community.  It
-   incorporates by reference, amends, corrects, and supplements the
-   primary protocol standards documents relating to hosts.  Distribution
-   of this document is unlimited.
-
-Summary
-
-   This RFC is one of a pair that defines and discusses the requirements
-   for Internet host software.  This RFC covers the application and
-   support protocols; its companion RFC-1122 covers the communication
-   protocol layers: link layer, IP layer, and transport layer.
-
-
-
-                           Table of Contents
-
-
-
-
-   1.  INTRODUCTION ...............................................    5
-      1.1  The Internet Architecture ..............................    6
-      1.2  General Considerations .................................    6
-         1.2.1  Continuing Internet Evolution .....................    6
-         1.2.2  Robustness Principle ..............................    7
-         1.2.3  Error Logging .....................................    8
-         1.2.4  Configuration .....................................    8
-      1.3  Reading this Document ..................................   10
-         1.3.1  Organization ......................................   10
-         1.3.2  Requirements ......................................   10
-         1.3.3  Terminology .......................................   11
-      1.4  Acknowledgments ........................................   12
-
-   2.  GENERAL ISSUES .............................................   13
-      2.1  Host Names and Numbers .................................   13
-      2.2  Using Domain Name Service ..............................   13
-      2.3  Applications on Multihomed hosts .......................   14
-      2.4  Type-of-Service ........................................   14
-      2.5  GENERAL APPLICATION REQUIREMENTS SUMMARY ...............   15
-
-
-
-
-Internet Engineering Task Force                                 [Page 1]
-
-
-
-
-RFC1123                       INTRODUCTION                  October 1989
-
-
-   3.  REMOTE LOGIN -- TELNET PROTOCOL ............................   16
-      3.1  INTRODUCTION ...........................................   16
-      3.2  PROTOCOL WALK-THROUGH ..................................   16
-         3.2.1  Option Negotiation ................................   16
-         3.2.2  Telnet Go-Ahead Function ..........................   16
-         3.2.3  Control Functions .................................   17
-         3.2.4  Telnet "Synch" Signal .............................   18
-         3.2.5  NVT Printer and Keyboard ..........................   19
-         3.2.6  Telnet Command Structure ..........................   20
-         3.2.7  Telnet Binary Option ..............................   20
-         3.2.8  Telnet Terminal-Type Option .......................   20
-      3.3  SPECIFIC ISSUES ........................................   21
-         3.3.1  Telnet End-of-Line Convention .....................   21
-         3.3.2  Data Entry Terminals ..............................   23
-         3.3.3  Option Requirements ...............................   24
-         3.3.4  Option Initiation .................................   24
-         3.3.5  Telnet Linemode Option ............................   25
-      3.4  TELNET/USER INTERFACE ..................................   25
-         3.4.1  Character Set Transparency ........................   25
-         3.4.2  Telnet Commands ...................................   26
-         3.4.3  TCP Connection Errors .............................   26
-         3.4.4  Non-Default Telnet Contact Port ...................   26
-         3.4.5  Flushing Output ...................................   26
-      3.5.  TELNET REQUIREMENTS SUMMARY ...........................   27
-
-   4.  FILE TRANSFER ..............................................   29
-      4.1  FILE TRANSFER PROTOCOL -- FTP ..........................   29
-         4.1.1  INTRODUCTION ......................................   29
-         4.1.2.  PROTOCOL WALK-THROUGH ............................   29
-            4.1.2.1  LOCAL Type ...................................   29
-            4.1.2.2  Telnet Format Control ........................   30
-            4.1.2.3  Page Structure ...............................   30
-            4.1.2.4  Data Structure Transformations ...............   30
-            4.1.2.5  Data Connection Management ...................   31
-            4.1.2.6  PASV Command .................................   31
-            4.1.2.7  LIST and NLST Commands .......................   31
-            4.1.2.8  SITE Command .................................   32
-            4.1.2.9  STOU Command .................................   32
-            4.1.2.10  Telnet End-of-line Code .....................   32
-            4.1.2.11  FTP Replies .................................   33
-            4.1.2.12  Connections .................................   34
-            4.1.2.13  Minimum Implementation; RFC-959 Section .....   34
-         4.1.3  SPECIFIC ISSUES ...................................   35
-            4.1.3.1  Non-standard Command Verbs ...................   35
-            4.1.3.2  Idle Timeout .................................   36
-            4.1.3.3  Concurrency of Data and Control ..............   36
-            4.1.3.4  FTP Restart Mechanism ........................   36
-         4.1.4  FTP/USER INTERFACE ................................   39
-
-
-
-Internet Engineering Task Force                                 [Page 2]
-
-
-
-
-RFC1123                       INTRODUCTION                  October 1989
-
-
-            4.1.4.1  Pathname Specification .......................   39
-            4.1.4.2  "QUOTE" Command ..............................   40
-            4.1.4.3  Displaying Replies to User ...................   40
-            4.1.4.4  Maintaining Synchronization ..................   40
-         4.1.5   FTP REQUIREMENTS SUMMARY .........................   41
-      4.2  TRIVIAL FILE TRANSFER PROTOCOL -- TFTP .................   44
-         4.2.1  INTRODUCTION ......................................   44
-         4.2.2  PROTOCOL WALK-THROUGH .............................   44
-            4.2.2.1  Transfer Modes ...............................   44
-            4.2.2.2  UDP Header ...................................   44
-         4.2.3  SPECIFIC ISSUES ...................................   44
-            4.2.3.1  Sorcerer's Apprentice Syndrome ...............   44
-            4.2.3.2  Timeout Algorithms ...........................   46
-            4.2.3.3  Extensions ...................................   46
-            4.2.3.4  Access Control ...............................   46
-            4.2.3.5  Broadcast Request ............................   46
-         4.2.4  TFTP REQUIREMENTS SUMMARY .........................   47
-
-   5.  ELECTRONIC MAIL -- SMTP and RFC-822 ........................   48
-      5.1  INTRODUCTION ...........................................   48
-      5.2  PROTOCOL WALK-THROUGH ..................................   48
-         5.2.1  The SMTP Model ....................................   48
-         5.2.2  Canonicalization ..................................   49
-         5.2.3  VRFY and EXPN Commands ............................   50
-         5.2.4  SEND, SOML, and SAML Commands .....................   50
-         5.2.5  HELO Command ......................................   50
-         5.2.6  Mail Relay ........................................   51
-         5.2.7  RCPT Command ......................................   52
-         5.2.8  DATA Command ......................................   53
-         5.2.9  Command Syntax ....................................   54
-         5.2.10  SMTP Replies .....................................   54
-         5.2.11  Transparency .....................................   55
-         5.2.12  WKS Use in MX Processing .........................   55
-         5.2.13  RFC-822 Message Specification ....................   55
-         5.2.14  RFC-822 Date and Time Specification ..............   55
-         5.2.15  RFC-822 Syntax Change ............................   56
-         5.2.16  RFC-822  Local-part ..............................   56
-         5.2.17  Domain Literals ..................................   57
-         5.2.18  Common Address Formatting Errors .................   58
-         5.2.19  Explicit Source Routes ...........................   58
-      5.3  SPECIFIC ISSUES ........................................   59
-         5.3.1  SMTP Queueing Strategies ..........................   59
-            5.3.1.1 Sending Strategy ..............................   59
-            5.3.1.2  Receiving strategy ...........................   61
-         5.3.2  Timeouts in SMTP ..................................   61
-         5.3.3  Reliable Mail Receipt .............................   63
-         5.3.4  Reliable Mail Transmission ........................   63
-         5.3.5  Domain Name Support ...............................   65
-
-
-
-Internet Engineering Task Force                                 [Page 3]
-
-
-
-
-RFC1123                       INTRODUCTION                  October 1989
-
-
-         5.3.6  Mailing Lists and Aliases .........................   65
-         5.3.7  Mail Gatewaying ...................................   66
-         5.3.8  Maximum Message Size ..............................   68
-      5.4  SMTP REQUIREMENTS SUMMARY ..............................   69
-
-   6. SUPPORT SERVICES ............................................   72
-      6.1 DOMAIN NAME TRANSLATION .................................   72
-         6.1.1 INTRODUCTION .......................................   72
-         6.1.2  PROTOCOL WALK-THROUGH .............................   72
-            6.1.2.1  Resource Records with Zero TTL ...............   73
-            6.1.2.2  QCLASS Values ................................   73
-            6.1.2.3  Unused Fields ................................   73
-            6.1.2.4  Compression ..................................   73
-            6.1.2.5  Misusing Configuration Info ..................   73
-         6.1.3  SPECIFIC ISSUES ...................................   74
-            6.1.3.1  Resolver Implementation ......................   74
-            6.1.3.2  Transport Protocols ..........................   75
-            6.1.3.3  Efficient Resource Usage .....................   77
-            6.1.3.4  Multihomed Hosts .............................   78
-            6.1.3.5  Extensibility ................................   79
-            6.1.3.6  Status of RR Types ...........................   79
-            6.1.3.7  Robustness ...................................   80
-            6.1.3.8  Local Host Table .............................   80
-         6.1.4  DNS USER INTERFACE ................................   81
-            6.1.4.1  DNS Administration ...........................   81
-            6.1.4.2  DNS User Interface ...........................   81
-            6.1.4.3 Interface Abbreviation Facilities .............   82
-         6.1.5  DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY ...........   84
-      6.2  HOST INITIALIZATION ....................................   87
-         6.2.1  INTRODUCTION ......................................   87
-         6.2.2  REQUIREMENTS ......................................   87
-            6.2.2.1  Dynamic Configuration ........................   87
-            6.2.2.2  Loading Phase ................................   89
-      6.3  REMOTE MANAGEMENT ......................................   90
-         6.3.1  INTRODUCTION ......................................   90
-         6.3.2  PROTOCOL WALK-THROUGH .............................   90
-         6.3.3  MANAGEMENT REQUIREMENTS SUMMARY ...................   92
-
-   7.  REFERENCES .................................................   93
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                 [Page 4]
-
-
-
-
-RFC1123                       INTRODUCTION                  October 1989
-
-
-1.  INTRODUCTION
-
-   This document is one of a pair that defines and discusses the
-   requirements for host system implementations of the Internet protocol
-   suite.  This RFC covers the applications layer and support protocols.
-   Its companion RFC, "Requirements for Internet Hosts -- Communications
-   Layers" [INTRO:1] covers the lower layer protocols: transport layer,
-   IP layer, and link layer.
-
-   These documents are intended to provide guidance for vendors,
-   implementors, and users of Internet communication software.  They
-   represent the consensus of a large body of technical experience and
-   wisdom, contributed by members of the Internet research and vendor
-   communities.
-
-   This RFC enumerates standard protocols that a host connected to the
-   Internet must use, and it incorporates by reference the RFCs and
-   other documents describing the current specifications for these
-   protocols.  It corrects errors in the referenced documents and adds
-   additional discussion and guidance for an implementor.
-
-   For each protocol, this document also contains an explicit set of
-   requirements, recommendations, and options.  The reader must
-   understand that the list of requirements in this document is
-   incomplete by itself; the complete set of requirements for an
-   Internet host is primarily defined in the standard protocol
-   specification documents, with the corrections, amendments, and
-   supplements contained in this RFC.
-
-   A good-faith implementation of the protocols that was produced after
-   careful reading of the RFC's and with some interaction with the
-   Internet technical community, and that followed good communications
-   software engineering practices, should differ from the requirements
-   of this document in only minor ways.  Thus, in many cases, the
-   "requirements" in this RFC are already stated or implied in the
-   standard protocol documents, so that their inclusion here is, in a
-   sense, redundant.  However, they were included because some past
-   implementation has made the wrong choice, causing problems of
-   interoperability, performance, and/or robustness.
-
-   This document includes discussion and explanation of many of the
-   requirements and recommendations.  A simple list of requirements
-   would be dangerous, because:
-
-   o    Some required features are more important than others, and some
-        features are optional.
-
-   o    There may be valid reasons why particular vendor products that
-
-
-
-Internet Engineering Task Force                                 [Page 5]
-
-
-
-
-RFC1123                       INTRODUCTION                  October 1989
-
-
-        are designed for restricted contexts might choose to use
-        different specifications.
-
-   However, the specifications of this document must be followed to meet
-   the general goal of arbitrary host interoperation across the
-   diversity and complexity of the Internet system.  Although most
-   current implementations fail to meet these requirements in various
-   ways, some minor and some major, this specification is the ideal
-   towards which we need to move.
-
-   These requirements are based on the current level of Internet
-   architecture.  This document will be updated as required to provide
-   additional clarifications or to include additional information in
-   those areas in which specifications are still evolving.
-
-   This introductory section begins with general advice to host software
-   vendors, and then gives some guidance on reading the rest of the
-   document.  Section 2 contains general requirements that may be
-   applicable to all application and support protocols.  Sections 3, 4,
-   and 5 contain the requirements on protocols for the three major
-   applications: Telnet, file transfer, and electronic mail,
-   respectively. Section 6 covers the support applications: the domain
-   name system, system initialization, and management.  Finally, all
-   references will be found in Section 7.
-
-   1.1  The Internet Architecture
-
-      For a brief introduction to the Internet architecture from a host
-      viewpoint, see Section 1.1 of [INTRO:1].  That section also
-      contains recommended references for general background on the
-      Internet architecture.
-
-   1.2  General Considerations
-
-      There are two important lessons that vendors of Internet host
-      software have learned and which a new vendor should consider
-      seriously.
-
-      1.2.1  Continuing Internet Evolution
-
-         The enormous growth of the Internet has revealed problems of
-         management and scaling in a large datagram-based packet
-         communication system.  These problems are being addressed, and
-         as a result there will be continuing evolution of the
-         specifications described in this document.  These changes will
-         be carefully planned and controlled, since there is extensive
-         participation in this planning by the vendors and by the
-         organizations responsible for operations of the networks.
-
-
-
-Internet Engineering Task Force                                 [Page 6]
-
-
-
-
-RFC1123                       INTRODUCTION                  October 1989
-
-
-         Development, evolution, and revision are characteristic of
-         computer network protocols today, and this situation will
-         persist for some years.  A vendor who develops computer
-         communication software for the Internet protocol suite (or any
-         other protocol suite!) and then fails to maintain and update
-         that software for changing specifications is going to leave a
-         trail of unhappy customers.  The Internet is a large
-         communication network, and the users are in constant contact
-         through it.  Experience has shown that knowledge of
-         deficiencies in vendor software propagates quickly through the
-         Internet technical community.
-
-      1.2.2  Robustness Principle
-
-         At every layer of the protocols, there is a general rule whose
-         application can lead to enormous benefits in robustness and
-         interoperability:
-
-                "Be liberal in what you accept, and
-                 conservative in what you send"
-
-         Software should be written to deal with every conceivable
-         error, no matter how unlikely; sooner or later a packet will
-         come in with that particular combination of errors and
-         attributes, and unless the software is prepared, chaos can
-         ensue.  In general, it is best to assume that the network is
-         filled with malevolent entities that will send in packets
-         designed to have the worst possible effect.  This assumption
-         will lead to suitable protective design, although the most
-         serious problems in the Internet have been caused by
-         unenvisaged mechanisms triggered by low-probability events;
-         mere human malice would never have taken so devious a course!
-
-         Adaptability to change must be designed into all levels of
-         Internet host software.  As a simple example, consider a
-         protocol specification that contains an enumeration of values
-         for a particular header field -- e.g., a type field, a port
-         number, or an error code; this enumeration must be assumed to
-         be incomplete.  Thus, if a protocol specification defines four
-         possible error codes, the software must not break when a fifth
-         code shows up.  An undefined code might be logged (see below),
-         but it must not cause a failure.
-
-         The second part of the principle is almost as important:
-         software on other hosts may contain deficiencies that make it
-         unwise to exploit legal but obscure protocol features.  It is
-         unwise to stray far from the obvious and simple, lest untoward
-         effects result elsewhere.  A corollary of this is "watch out
-
-
-
-Internet Engineering Task Force                                 [Page 7]
-
-
-
-
-RFC1123                       INTRODUCTION                  October 1989
-
-
-         for misbehaving hosts"; host software should be prepared, not
-         just to survive other misbehaving hosts, but also to cooperate
-         to limit the amount of disruption such hosts can cause to the
-         shared communication facility.
-
-      1.2.3  Error Logging
-
-         The Internet includes a great variety of host and gateway
-         systems, each implementing many protocols and protocol layers,
-         and some of these contain bugs and mis-features in their
-         Internet protocol software.  As a result of complexity,
-         diversity, and distribution of function, the diagnosis of user
-         problems is often very difficult.
-
-         Problem diagnosis will be aided if host implementations include
-         a carefully designed facility for logging erroneous or
-         "strange" protocol events.  It is important to include as much
-         diagnostic information as possible when an error is logged.  In
-         particular, it is often useful to record the header(s) of a
-         packet that caused an error.  However, care must be taken to
-         ensure that error logging does not consume prohibitive amounts
-         of resources or otherwise interfere with the operation of the
-         host.
-
-         There is a tendency for abnormal but harmless protocol events
-         to overflow error logging files; this can be avoided by using a
-         "circular" log, or by enabling logging only while diagnosing a
-         known failure.  It may be useful to filter and count duplicate
-         successive messages.  One strategy that seems to work well is:
-         (1) always count abnormalities and make such counts accessible
-         through the management protocol (see Section 6.3); and (2)
-         allow the logging of a great variety of events to be
-         selectively enabled.  For example, it might useful to be able
-         to "log everything" or to "log everything for host X".
-
-         Note that different managements may have differing policies
-         about the amount of error logging that they want normally
-         enabled in a host.  Some will say, "if it doesn't hurt me, I
-         don't want to know about it", while others will want to take a
-         more watchful and aggressive attitude about detecting and
-         removing protocol abnormalities.
-
-      1.2.4  Configuration
-
-         It would be ideal if a host implementation of the Internet
-         protocol suite could be entirely self-configuring.  This would
-         allow the whole suite to be implemented in ROM or cast into
-         silicon, it would simplify diskless workstations, and it would
-
-
-
-Internet Engineering Task Force                                 [Page 8]
-
-
-
-
-RFC1123                       INTRODUCTION                  October 1989
-
-
-         be an immense boon to harried LAN administrators as well as
-         system vendors.  We have not reached this ideal; in fact, we
-         are not even close.
-
-         At many points in this document, you will find a requirement
-         that a parameter be a configurable option.  There are several
-         different reasons behind such requirements.  In a few cases,
-         there is current uncertainty or disagreement about the best
-         value, and it may be necessary to update the recommended value
-         in the future.  In other cases, the value really depends on
-         external factors -- e.g., the size of the host and the
-         distribution of its communication load, or the speeds and
-         topology of nearby networks -- and self-tuning algorithms are
-         unavailable and may be insufficient.  In some cases,
-         configurability is needed because of administrative
-         requirements.
-
-         Finally, some configuration options are required to communicate
-         with obsolete or incorrect implementations of the protocols,
-         distributed without sources, that unfortunately persist in many
-         parts of the Internet.  To make correct systems coexist with
-         these faulty systems, administrators often have to "mis-
-         configure" the correct systems.  This problem will correct
-         itself gradually as the faulty systems are retired, but it
-         cannot be ignored by vendors.
-
-         When we say that a parameter must be configurable, we do not
-         intend to require that its value be explicitly read from a
-         configuration file at every boot time.  We recommend that
-         implementors set up a default for each parameter, so a
-         configuration file is only necessary to override those defaults
-         that are inappropriate in a particular installation.  Thus, the
-         configurability requirement is an assurance that it will be
-         POSSIBLE to override the default when necessary, even in a
-         binary-only or ROM-based product.
-
-         This document requires a particular value for such defaults in
-         some cases.  The choice of default is a sensitive issue when
-         the configuration item controls the accommodation to existing
-         faulty systems.  If the Internet is to converge successfully to
-         complete interoperability, the default values built into
-         implementations must implement the official protocol, not
-         "mis-configurations" to accommodate faulty implementations.
-         Although marketing considerations have led some vendors to
-         choose mis-configuration defaults, we urge vendors to choose
-         defaults that will conform to the standard.
-
-         Finally, we note that a vendor needs to provide adequate
-
-
-
-Internet Engineering Task Force                                 [Page 9]
-
-
-
-
-RFC1123                       INTRODUCTION                  October 1989
-
-
-         documentation on all configuration parameters, their limits and
-         effects.
-
-
-   1.3  Reading this Document
-
-      1.3.1  Organization
-
-         In general, each major section is organized into the following
-         subsections:
-
-         (1)  Introduction
-
-         (2)  Protocol Walk-Through -- considers the protocol
-              specification documents section-by-section, correcting
-              errors, stating requirements that may be ambiguous or
-              ill-defined, and providing further clarification or
-              explanation.
-
-         (3)  Specific Issues -- discusses protocol design and
-              implementation issues that were not included in the walk-
-              through.
-
-         (4)  Interfaces -- discusses the service interface to the next
-              higher layer.
-
-         (5)  Summary -- contains a summary of the requirements of the
-              section.
-
-         Under many of the individual topics in this document, there is
-         parenthetical material labeled "DISCUSSION" or
-         "IMPLEMENTATION".  This material is intended to give
-         clarification and explanation of the preceding requirements
-         text.  It also includes some suggestions on possible future
-         directions or developments.  The implementation material
-         contains suggested approaches that an implementor may want to
-         consider.
-
-         The summary sections are intended to be guides and indexes to
-         the text, but are necessarily cryptic and incomplete.  The
-         summaries should never be used or referenced separately from
-         the complete RFC.
-
-      1.3.2  Requirements
-
-         In this document, the words that are used to define the
-         significance of each particular requirement are capitalized.
-         These words are:
-
-
-
-Internet Engineering Task Force                                [Page 10]
-
-
-
-
-RFC1123                       INTRODUCTION                  October 1989
-
-
-         *    "MUST"
-
-              This word or the adjective "REQUIRED" means that the item
-              is an absolute requirement of the specification.
-
-         *    "SHOULD"
-
-              This word or the adjective "RECOMMENDED" means that there
-              may exist valid reasons in particular circumstances to
-              ignore this item, but the full implications should be
-              understood and the case carefully weighed before choosing
-              a different course.
-
-         *    "MAY"
-
-              This word or the adjective "OPTIONAL" means that this item
-              is truly optional.  One vendor may choose to include the
-              item because a particular marketplace requires it or
-              because it enhances the product, for example; another
-              vendor may omit the same item.
-
-
-         An implementation is not compliant if it fails to satisfy one
-         or more of the MUST requirements for the protocols it
-         implements.  An implementation that satisfies all the MUST and
-         all the SHOULD requirements for its protocols is said to be
-         "unconditionally compliant"; one that satisfies all the MUST
-         requirements but not all the SHOULD requirements for its
-         protocols is said to be "conditionally compliant".
-
-      1.3.3  Terminology
-
-         This document uses the following technical terms:
-
-         Segment
-              A segment is the unit of end-to-end transmission in the
-              TCP protocol.  A segment consists of a TCP header followed
-              by application data.  A segment is transmitted by
-              encapsulation in an IP datagram.
-
-         Message
-              This term is used by some application layer protocols
-              (particularly SMTP) for an application data unit.
-
-         Datagram
-              A [UDP] datagram is the unit of end-to-end transmission in
-              the UDP protocol.
-
-
-
-
-Internet Engineering Task Force                                [Page 11]
-
-
-
-
-RFC1123                       INTRODUCTION                  October 1989
-
-
-         Multihomed
-              A host is said to be multihomed if it has multiple IP
-              addresses to connected networks.
-
-
-
-   1.4  Acknowledgments
-
-      This document incorporates contributions and comments from a large
-      group of Internet protocol experts, including representatives of
-      university and research labs, vendors, and government agencies.
-      It was assembled primarily by the Host Requirements Working Group
-      of the Internet Engineering Task Force (IETF).
-
-      The Editor would especially like to acknowledge the tireless
-      dedication of the following people, who attended many long
-      meetings and generated 3 million bytes of electronic mail over the
-      past 18 months in pursuit of this document: Philip Almquist, Dave
-      Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve
-      Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore),
-      John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG),
-      Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge
-      (BBN), Drew Perkins (CMU), and James Van Bokkelen (FTP Software).
-
-      In addition, the following people made major contributions to the
-      effort: Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia
-      (BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA),
-      Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL),
-      John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill
-      Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul
-      (DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue
-      Technology), and Mike StJohns (DCA).  The following also made
-      significant contributions to particular areas: Eric Allman
-      (Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic
-      (Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn
-      (IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann
-      (Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun
-      Welch (Ohio State), Bill Westfield (Cisco), and Rayan Zachariassen
-      (Toronto).
-
-      We are grateful to all, including any contributors who may have
-      been inadvertently omitted from this list.
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 12]
-
-
-
-
-RFC1123              APPLICATIONS LAYER -- GENERAL          October 1989
-
-
-2.  GENERAL ISSUES
-
-   This section contains general requirements that may be applicable to
-   all application-layer protocols.
-
-   2.1  Host Names and Numbers
-
-      The syntax of a legal Internet host name was specified in RFC-952
-      [DNS:4].  One aspect of host name syntax is hereby changed: the
-      restriction on the first character is relaxed to allow either a
-      letter or a digit.  Host software MUST support this more liberal
-      syntax.
-
-      Host software MUST handle host names of up to 63 characters and
-      SHOULD handle host names of up to 255 characters.
-
-      Whenever a user inputs the identity of an Internet host, it SHOULD
-      be possible to enter either (1) a host domain name or (2) an IP
-      address in dotted-decimal ("#.#.#.#") form.  The host SHOULD check
-      the string syntactically for a dotted-decimal number before
-      looking it up in the Domain Name System.
-
-      DISCUSSION:
-           This last requirement is not intended to specify the complete
-           syntactic form for entering a dotted-decimal host number;
-           that is considered to be a user-interface issue.  For
-           example, a dotted-decimal number must be enclosed within
-           "[ ]" brackets for SMTP mail (see Section 5.2.17).  This
-           notation could be made universal within a host system,
-           simplifying the syntactic checking for a dotted-decimal
-           number.
-
-           If a dotted-decimal number can be entered without such
-           identifying delimiters, then a full syntactic check must be
-           made, because a segment of a host domain name is now allowed
-           to begin with a digit and could legally be entirely numeric
-           (see Section 6.1.2.4).  However, a valid host name can never
-           have the dotted-decimal form #.#.#.#, since at least the
-           highest-level component label will be alphabetic.
-
-   2.2  Using Domain Name Service
-
-      Host domain names MUST be translated to IP addresses as described
-      in Section 6.1.
-
-      Applications using domain name services MUST be able to cope with
-      soft error conditions.  Applications MUST wait a reasonable
-      interval between successive retries due to a soft error, and MUST
-
-
-
-Internet Engineering Task Force                                [Page 13]
-
-
-
-
-RFC1123              APPLICATIONS LAYER -- GENERAL          October 1989
-
-
-      allow for the possibility that network problems may deny service
-      for hours or even days.
-
-      An application SHOULD NOT rely on the ability to locate a WKS
-      record containing an accurate listing of all services at a
-      particular host address, since the WKS RR type is not often used
-      by Internet sites.  To confirm that a service is present, simply
-      attempt to use it.
-
-   2.3  Applications on Multihomed hosts
-
-      When the remote host is multihomed, the name-to-address
-      translation will return a list of alternative IP addresses.  As
-      specified in Section 6.1.3.4, this list should be in order of
-      decreasing preference.  Application protocol implementations
-      SHOULD be prepared to try multiple addresses from the list until
-      success is obtained.  More specific requirements for SMTP are
-      given in Section 5.3.4.
-
-      When the local host is multihomed, a UDP-based request/response
-      application SHOULD send the response with an IP source address
-      that is the same as the specific destination address of the UDP
-      request datagram.  The "specific destination address" is defined
-      in the "IP Addressing" section of the companion RFC [INTRO:1].
-
-      Similarly, a server application that opens multiple TCP
-      connections to the same client SHOULD use the same local IP
-      address for all.
-
-   2.4  Type-of-Service
-
-      Applications MUST select appropriate TOS values when they invoke
-      transport layer services, and these values MUST be configurable.
-      Note that a TOS value contains 5 bits, of which only the most-
-      significant 3 bits are currently defined; the other two bits MUST
-      be zero.
-
-      DISCUSSION:
-           As gateway algorithms are developed to implement Type-of-
-           Service, the recommended values for various application
-           protocols may change.  In addition, it is likely that
-           particular combinations of users and Internet paths will want
-           non-standard TOS values.  For these reasons, the TOS values
-           must be configurable.
-
-           See the latest version of the "Assigned Numbers" RFC
-           [INTRO:5] for the recommended TOS values for the major
-           application protocols.
-
-
-
-Internet Engineering Task Force                                [Page 14]
-
-
-
-
-RFC1123              APPLICATIONS LAYER -- GENERAL          October 1989
-
-
-   2.5  GENERAL APPLICATION REQUIREMENTS SUMMARY
-
-                                               |          | | | |S| |
-                                               |          | | | |H| |F
-                                               |          | | | |O|M|o
-                                               |          | |S| |U|U|o
-                                               |          | |H| |L|S|t
-                                               |          |M|O| |D|T|n
-                                               |          |U|U|M| | |o
-                                               |          |S|L|A|N|N|t
-                                               |          |T|D|Y|O|O|t
-FEATURE                                        |SECTION   | | | |T|T|e
------------------------------------------------|----------|-|-|-|-|-|--
-                                               |          | | | | | |
-User interfaces:                               |          | | | | | |
-  Allow host name to begin with digit          |2.1       |x| | | | |
-  Host names of up to 635 characters           |2.1       |x| | | | |
-  Host names of up to 255 characters           |2.1       | |x| | | |
-  Support dotted-decimal host numbers          |2.1       | |x| | | |
-  Check syntactically for dotted-dec first     |2.1       | |x| | | |
-                                               |          | | | | | |
-Map domain names per Section 6.1               |2.2       |x| | | | |
-Cope with soft DNS errors                      |2.2       |x| | | | |
-   Reasonable interval between retries         |2.2       |x| | | | |
-   Allow for long outages                      |2.2       |x| | | | |
-Expect WKS records to be available             |2.2       | | | |x| |
-                                               |          | | | | | |
-Try multiple addr's for remote multihomed host |2.3       | |x| | | |
-UDP reply src addr is specific dest of request |2.3       | |x| | | |
-Use same IP addr for related TCP connections   |2.3       | |x| | | |
-Specify appropriate TOS values                 |2.4       |x| | | | |
-  TOS values configurable                      |2.4       |x| | | | |
-  Unused TOS bits zero                         |2.4       |x| | | | |
-                                               |          | | | | | |
-                                               |          | | | | | |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 15]
-
-
-
-
-RFC1123                  REMOTE LOGIN -- TELNET             October 1989
-
-
-3.  REMOTE LOGIN -- TELNET PROTOCOL
-
-   3.1  INTRODUCTION
-
-      Telnet is the standard Internet application protocol for remote
-      login.  It provides the encoding rules to link a user's
-      keyboard/display on a client ("user") system with a command
-      interpreter on a remote server system.  A subset of the Telnet
-      protocol is also incorporated within other application protocols,
-      e.g., FTP and SMTP.
-
-      Telnet uses a single TCP connection, and its normal data stream
-      ("Network Virtual Terminal" or "NVT" mode) is 7-bit ASCII with
-      escape sequences to embed control functions.  Telnet also allows
-      the negotiation of many optional modes and functions.
-
-      The primary Telnet specification is to be found in RFC-854
-      [TELNET:1], while the options are defined in many other RFCs; see
-      Section 7 for references.
-
-   3.2  PROTOCOL WALK-THROUGH
-
-      3.2.1  Option Negotiation: RFC-854, pp. 2-3
-
-         Every Telnet implementation MUST include option negotiation and
-         subnegotiation machinery [TELNET:2].
-
-         A host MUST carefully follow the rules of RFC-854 to avoid
-         option-negotiation loops.  A host MUST refuse (i.e, reply
-         WONT/DONT to a DO/WILL) an unsupported option.  Option
-         negotiation SHOULD continue to function (even if all requests
-         are refused) throughout the lifetime of a Telnet connection.
-
-         If all option negotiations fail, a Telnet implementation MUST
-         default to, and support, an NVT.
-
-         DISCUSSION:
-              Even though more sophisticated "terminals" and supporting
-              option negotiations are becoming the norm, all
-              implementations must be prepared to support an NVT for any
-              user-server communication.
-
-      3.2.2  Telnet Go-Ahead Function: RFC-854, p. 5, and RFC-858
-
-         On a host that never sends the Telnet command Go Ahead (GA),
-         the Telnet Server MUST attempt to negotiate the Suppress Go
-         Ahead option (i.e., send "WILL Suppress Go Ahead").  A User or
-         Server Telnet MUST always accept negotiation of the Suppress Go
-
-
-
-Internet Engineering Task Force                                [Page 16]
-
-
-
-
-RFC1123                  REMOTE LOGIN -- TELNET             October 1989
-
-
-         Ahead option.
-
-         When it is driving a full-duplex terminal for which GA has no
-         meaning, a User Telnet implementation MAY ignore GA commands.
-
-         DISCUSSION:
-              Half-duplex ("locked-keyboard") line-at-a-time terminals
-              for which the Go-Ahead mechanism was designed have largely
-              disappeared from the scene.  It turned out to be difficult
-              to implement sending the Go-Ahead signal in many operating
-              systems, even some systems that support native half-duplex
-              terminals.  The difficulty is typically that the Telnet
-              server code does not have access to information about
-              whether the user process is blocked awaiting input from
-              the Telnet connection, i.e., it cannot reliably determine
-              when to send a GA command.  Therefore, most Telnet Server
-              hosts do not send GA commands.
-
-              The effect of the rules in this section is to allow either
-              end of a Telnet connection to veto the use of GA commands.
-
-              There is a class of half-duplex terminals that is still
-              commercially important: "data entry terminals," which
-              interact in a full-screen manner.  However, supporting
-              data entry terminals using the Telnet protocol does not
-              require the Go Ahead signal; see Section 3.3.2.
-
-      3.2.3  Control Functions: RFC-854, pp. 7-8
-
-         The list of Telnet commands has been extended to include EOR
-         (End-of-Record), with code 239 [TELNET:9].
-
-         Both User and Server Telnets MAY support the control functions
-         EOR, EC, EL, and Break, and MUST support AO, AYT, DM, IP, NOP,
-         SB, and SE.
-
-         A host MUST be able to receive and ignore any Telnet control
-         functions that it does not support.
-
-         DISCUSSION:
-              Note that a Server Telnet is required to support the
-              Telnet IP (Interrupt Process) function, even if the server
-              host has an equivalent in-stream function (e.g., Control-C
-              in many systems).  The Telnet IP function may be stronger
-              than an in-stream interrupt command, because of the out-
-              of-band effect of TCP urgent data.
-
-              The EOR control function may be used to delimit the
-
-
-
-Internet Engineering Task Force                                [Page 17]
-
-
-
-
-RFC1123                  REMOTE LOGIN -- TELNET             October 1989
-
-
-              stream.  An important application is data entry terminal
-              support (see Section 3.3.2).  There was concern that since
-              EOR had not been defined in RFC-854, a host that was not
-              prepared to correctly ignore unknown Telnet commands might
-              crash if it received an EOR.  To protect such hosts, the
-              End-of-Record option [TELNET:9] was introduced; however, a
-              properly implemented Telnet program will not require this
-              protection.
-
-      3.2.4  Telnet "Synch" Signal: RFC-854, pp. 8-10
-
-         When it receives "urgent" TCP data, a User or Server Telnet
-         MUST discard all data except Telnet commands until the DM (and
-         end of urgent) is reached.
-
-         When it sends Telnet IP (Interrupt Process), a User Telnet
-         SHOULD follow it by the Telnet "Synch" sequence, i.e., send as
-         TCP urgent data the sequence "IAC IP IAC DM".  The TCP urgent
-         pointer points to the DM octet.
-
-         When it receives a Telnet IP command, a Server Telnet MAY send
-         a Telnet "Synch" sequence back to the user, to flush the output
-         stream.  The choice ought to be consistent with the way the
-         server operating system behaves when a local user interrupts a
-         process.
-
-         When it receives a Telnet AO command, a Server Telnet MUST send
-         a Telnet "Synch" sequence back to the user, to flush the output
-         stream.
-
-         A User Telnet SHOULD have the capability of flushing output
-         when it sends a Telnet IP; see also Section 3.4.5.
-
-         DISCUSSION:
-              There are three possible ways for a User Telnet to flush
-              the stream of server output data:
-
-              (1)  Send AO after IP.
-
-                   This will cause the server host to send a "flush-
-                   buffered-output" signal to its operating system.
-                   However, the AO may not take effect locally, i.e.,
-                   stop terminal output at the User Telnet end, until
-                   the Server Telnet has received and processed the AO
-                   and has sent back a "Synch".
-
-              (2)  Send DO TIMING-MARK [TELNET:7] after IP, and discard
-                   all output locally until a WILL/WONT TIMING-MARK is
-
-
-
-Internet Engineering Task Force                                [Page 18]
-
-
-
-
-RFC1123                  REMOTE LOGIN -- TELNET             October 1989
-
-
-                   received from the Server Telnet.
-
-                   Since the DO TIMING-MARK will be processed after the
-                   IP at the server, the reply to it should be in the
-                   right place in the output data stream.  However, the
-                   TIMING-MARK will not send a "flush buffered output"
-                   signal to the server operating system.  Whether or
-                   not this is needed is dependent upon the server
-                   system.
-
-              (3)  Do both.
-
-              The best method is not entirely clear, since it must
-              accommodate a number of existing server hosts that do not
-              follow the Telnet standards in various ways.  The safest
-              approach is probably to provide a user-controllable option
-              to select (1), (2), or (3).
-
-      3.2.5  NVT Printer and Keyboard: RFC-854, p. 11
-
-         In NVT mode, a Telnet SHOULD NOT send characters with the
-         high-order bit 1, and MUST NOT send it as a parity bit.
-         Implementations that pass the high-order bit to applications
-         SHOULD negotiate binary mode (see Section 3.2.6).
-
-
-         DISCUSSION:
-              Implementors should be aware that a strict reading of
-              RFC-854 allows a client or server expecting NVT ASCII to
-              ignore characters with the high-order bit set.  In
-              general, binary mode is expected to be used for
-              transmission of an extended (beyond 7-bit) character set
-              with Telnet.
-
-              However, there exist applications that really need an 8-
-              bit NVT mode, which is currently not defined, and these
-              existing applications do set the high-order bit during
-              part or all of the life of a Telnet connection.  Note that
-              binary mode is not the same as 8-bit NVT mode, since
-              binary mode turns off end-of-line processing.  For this
-              reason, the requirements on the high-order bit are stated
-              as SHOULD, not MUST.
-
-              RFC-854 defines a minimal set of properties of a "network
-              virtual terminal" or NVT; this is not meant to preclude
-              additional features in a real terminal.  A Telnet
-              connection is fully transparent to all 7-bit ASCII
-              characters, including arbitrary ASCII control characters.
-
-
-
-Internet Engineering Task Force                                [Page 19]
-
-
-
-
-RFC1123                  REMOTE LOGIN -- TELNET             October 1989
-
-
-              For example, a terminal might support full-screen commands
-              coded as ASCII escape sequences; a Telnet implementation
-              would pass these sequences as uninterpreted data.  Thus,
-              an NVT should not be conceived as a terminal type of a
-              highly-restricted device.
-
-      3.2.6  Telnet Command Structure: RFC-854, p. 13
-
-         Since options may appear at any point in the data stream, a
-         Telnet escape character (known as IAC, with the value 255) to
-         be sent as data MUST be doubled.
-
-      3.2.7  Telnet Binary Option: RFC-856
-
-         When the Binary option has been successfully negotiated,
-         arbitrary 8-bit characters are allowed.  However, the data
-         stream MUST still be scanned for IAC characters, any embedded
-         Telnet commands MUST be obeyed, and data bytes equal to IAC
-         MUST be doubled.  Other character processing (e.g., replacing
-         CR by CR NUL or by CR LF) MUST NOT be done.  In particular,
-         there is no end-of-line convention (see Section 3.3.1) in
-         binary mode.
-
-         DISCUSSION:
-              The Binary option is normally negotiated in both
-              directions, to change the Telnet connection from NVT mode
-              to "binary mode".
-
-              The sequence IAC EOR can be used to delimit blocks of data
-              within a binary-mode Telnet stream.
-
-      3.2.8  Telnet Terminal-Type Option: RFC-1091
-
-         The Terminal-Type option MUST use the terminal type names
-         officially defined in the Assigned Numbers RFC [INTRO:5], when
-         they are available for the particular terminal.  However, the
-         receiver of a Terminal-Type option MUST accept any name.
-
-         DISCUSSION:
-              RFC-1091 [TELNET:10] updates an earlier version of the
-              Terminal-Type option defined in RFC-930.  The earlier
-              version allowed a server host capable of supporting
-              multiple terminal types to learn the type of a particular
-              client's terminal, assuming that each physical terminal
-              had an intrinsic type.  However, today a "terminal" is
-              often really a terminal emulator program running in a PC,
-              perhaps capable of emulating a range of terminal types.
-              Therefore, RFC-1091 extends the specification to allow a
-
-
-
-Internet Engineering Task Force                                [Page 20]
-
-
-
-
-RFC1123                  REMOTE LOGIN -- TELNET             October 1989
-
-
-              more general terminal-type negotiation between User and
-              Server Telnets.
-
-   3.3  SPECIFIC ISSUES
-
-      3.3.1  Telnet End-of-Line Convention
-
-         The Telnet protocol defines the sequence CR LF to mean "end-
-         of-line".  For terminal input, this corresponds to a command-
-         completion or "end-of-line" key being pressed on a user
-         terminal; on an ASCII terminal, this is the CR key, but it may
-         also be labelled "Return" or "Enter".
-
-         When a Server Telnet receives the Telnet end-of-line sequence
-         CR LF as input from a remote terminal, the effect MUST be the
-         same as if the user had pressed the "end-of-line" key on a
-         local terminal.  On server hosts that use ASCII, in particular,
-         receipt of the Telnet sequence CR LF must cause the same effect
-         as a local user pressing the CR key on a local terminal.  Thus,
-         CR LF and CR NUL MUST have the same effect on an ASCII server
-         host when received as input over a Telnet connection.
-
-         A User Telnet MUST be able to send any of the forms: CR LF, CR
-         NUL, and LF.  A User Telnet on an ASCII host SHOULD have a
-         user-controllable mode to send either CR LF or CR NUL when the
-         user presses the "end-of-line" key, and CR LF SHOULD be the
-         default.
-
-         The Telnet end-of-line sequence CR LF MUST be used to send
-         Telnet data that is not terminal-to-computer (e.g., for Server
-         Telnet sending output, or the Telnet protocol incorporated
-         another application protocol).
-
-         DISCUSSION:
-              To allow interoperability between arbitrary Telnet clients
-              and servers, the Telnet protocol defined a standard
-              representation for a line terminator.  Since the ASCII
-              character set includes no explicit end-of-line character,
-              systems have chosen various representations, e.g., CR, LF,
-              and the sequence CR LF.  The Telnet protocol chose the CR
-              LF sequence as the standard for network transmission.
-
-              Unfortunately, the Telnet protocol specification in RFC-
-              854 [TELNET:1] has turned out to be somewhat ambiguous on
-              what character(s) should be sent from client to server for
-              the "end-of-line" key.  The result has been a massive and
-              continuing interoperability headache, made worse by
-              various faulty implementations of both User and Server
-
-
-
-Internet Engineering Task Force                                [Page 21]
-
-
-
-
-RFC1123                  REMOTE LOGIN -- TELNET             October 1989
-
-
-              Telnets.
-
-              Although the Telnet protocol is based on a perfectly
-              symmetric model, in a remote login session the role of the
-              user at a terminal differs from the role of the server
-              host.  For example, RFC-854 defines the meaning of CR, LF,
-              and CR LF as output from the server, but does not specify
-              what the User Telnet should send when the user presses the
-              "end-of-line" key on the terminal; this turns out to be
-              the point at issue.
-
-              When a user presses the "end-of-line" key, some User
-              Telnet implementations send CR LF, while others send CR
-              NUL (based on a different interpretation of the same
-              sentence in RFC-854).  These will be equivalent for a
-              correctly-implemented ASCII server host, as discussed
-              above.  For other servers, a mode in the User Telnet is
-              needed.
-
-              The existence of User Telnets that send only CR NUL when
-              CR is pressed creates a dilemma for non-ASCII hosts: they
-              can either treat CR NUL as equivalent to CR LF in input,
-              thus precluding the possibility of entering a "bare" CR,
-              or else lose complete interworking.
-
-              Suppose a user on host A uses Telnet to log into a server
-              host B, and then execute B's User Telnet program to log
-              into server host C.  It is desirable for the Server/User
-              Telnet combination on B to be as transparent as possible,
-              i.e., to appear as if A were connected directly to C.  In
-              particular, correct implementation will make B transparent
-              to Telnet end-of-line sequences, except that CR LF may be
-              translated to CR NUL or vice versa.
-
-         IMPLEMENTATION:
-              To understand Telnet end-of-line issues, one must have at
-              least a general model of the relationship of Telnet to the
-              local operating system.  The Server Telnet process is
-              typically coupled into the terminal driver software of the
-              operating system as a pseudo-terminal.  A Telnet end-of-
-              line sequence received by the Server Telnet must have the
-              same effect as pressing the end-of-line key on a real
-              locally-connected terminal.
-
-              Operating systems that support interactive character-at-
-              a-time applications (e.g., editors) typically have two
-              internal modes for their terminal I/O: a formatted mode,
-              in which local conventions for end-of-line and other
-
-
-
-Internet Engineering Task Force                                [Page 22]
-
-
-
-
-RFC1123                  REMOTE LOGIN -- TELNET             October 1989
-
-
-              formatting rules have been applied to the data stream, and
-              a "raw" mode, in which the application has direct access
-              to every character as it was entered.  A Server Telnet
-              must be implemented in such a way that these modes have
-              the same effect for remote as for local terminals.  For
-              example, suppose a CR LF or CR NUL is received by the
-              Server Telnet on an ASCII host.  In raw mode, a CR
-              character is passed to the application; in formatted mode,
-              the local system's end-of-line convention is used.
-
-      3.3.2  Data Entry Terminals
-
-         DISCUSSION:
-              In addition to the line-oriented and character-oriented
-              ASCII terminals for which Telnet was designed, there are
-              several families of video display terminals that are
-              sometimes known as "data entry terminals" or DETs.  The
-              IBM 3270 family is a well-known example.
-
-              Two Internet protocols have been designed to support
-              generic DETs: SUPDUP [TELNET:16, TELNET:17], and the DET
-              option [TELNET:18, TELNET:19].  The DET option drives a
-              data entry terminal over a Telnet connection using (sub-)
-              negotiation.  SUPDUP is a completely separate terminal
-              protocol, which can be entered from Telnet by negotiation.
-              Although both SUPDUP and the DET option have been used
-              successfully in particular environments, neither has
-              gained general acceptance or wide implementation.
-
-              A different approach to DET interaction has been developed
-              for supporting the IBM 3270 family through Telnet,
-              although the same approach would be applicable to any DET.
-              The idea is to enter a "native DET" mode, in which the
-              native DET input/output stream is sent as binary data.
-              The Telnet EOR command is used to delimit logical records
-              (e.g., "screens") within this binary stream.
-
-         IMPLEMENTATION:
-              The rules for entering and leaving native DET mode are as
-              follows:
-
-              o    The Server uses the Terminal-Type option [TELNET:10]
-                   to learn that the client is a DET.
-
-              o    It is conventional, but not required, that both ends
-                   negotiate the EOR option [TELNET:9].
-
-              o    Both ends negotiate the Binary option [TELNET:3] to
-
-
-
-Internet Engineering Task Force                                [Page 23]
-
-
-
-
-RFC1123                  REMOTE LOGIN -- TELNET             October 1989
-
-
-                   enter native DET mode.
-
-              o    When either end negotiates out of binary mode, the
-                   other end does too, and the mode then reverts to
-                   normal NVT.
-
-
-      3.3.3  Option Requirements
-
-         Every Telnet implementation MUST support the Binary option
-         [TELNET:3] and the Suppress Go Ahead option [TELNET:5], and
-         SHOULD support the Echo [TELNET:4], Status [TELNET:6], End-of-
-         Record [TELNET:9], and Extended Options List [TELNET:8]
-         options.
-
-         A User or Server Telnet SHOULD support the Window Size Option
-         [TELNET:12] if the local operating system provides the
-         corresponding capability.
-
-         DISCUSSION:
-              Note that the End-of-Record option only signifies that a
-              Telnet can receive a Telnet EOR without crashing;
-              therefore, every Telnet ought to be willing to accept
-              negotiation of the End-of-Record option.  See also the
-              discussion in Section 3.2.3.
-
-      3.3.4  Option Initiation
-
-         When the Telnet protocol is used in a client/server situation,
-         the server SHOULD initiate negotiation of the terminal
-         interaction mode it expects.
-
-         DISCUSSION:
-              The Telnet protocol was defined to be perfectly
-              symmetrical, but its application is generally asymmetric.
-              Remote login has been known to fail because NEITHER side
-              initiated negotiation of the required non-default terminal
-              modes.  It is generally the server that determines the
-              preferred mode, so the server needs to initiate the
-              negotiation; since the negotiation is symmetric, the user
-              can also initiate it.
-
-         A client (User Telnet) SHOULD provide a means for users to
-         enable and disable the initiation of option negotiation.
-
-         DISCUSSION:
-              A user sometimes needs to connect to an application
-              service (e.g., FTP or SMTP) that uses Telnet for its
-
-
-
-Internet Engineering Task Force                                [Page 24]
-
-
-
-
-RFC1123                  REMOTE LOGIN -- TELNET             October 1989
-
-
-              control stream but does not support Telnet options.  User
-              Telnet may be used for this purpose if initiation of
-              option negotiation is  disabled.
-
-      3.3.5  Telnet Linemode Option
-
-         DISCUSSION:
-              An important new Telnet option, LINEMODE [TELNET:12], has
-              been proposed.  The LINEMODE option provides a standard
-              way for a User Telnet and a Server Telnet to agree that
-              the client rather than the server will perform terminal
-              character processing.  When the client has prepared a
-              complete line of text, it will send it to the server in
-              (usually) one TCP packet.  This option will greatly
-              decrease the packet cost of Telnet sessions and will also
-              give much better user response over congested or long-
-              delay networks.
-
-              The LINEMODE option allows dynamic switching between local
-              and remote character processing.  For example, the Telnet
-              connection will automatically negotiate into single-
-              character mode while a full screen editor is running, and
-              then return to linemode when the editor is finished.
-
-              We expect that when this RFC is released, hosts should
-              implement the client side of this option, and may
-              implement the server side of this option.  To properly
-              implement the server side, the server needs to be able to
-              tell the local system not to do any input character
-              processing, but to remember its current terminal state and
-              notify the Server Telnet process whenever the state
-              changes.  This will allow password echoing and full screen
-              editors to be handled properly, for example.
-
-   3.4  TELNET/USER INTERFACE
-
-      3.4.1  Character Set Transparency
-
-         User Telnet implementations SHOULD be able to send or receive
-         any 7-bit ASCII character.  Where possible, any special
-         character interpretations by the user host's operating system
-         SHOULD be bypassed so that these characters can conveniently be
-         sent and received on the connection.
-
-         Some character value MUST be reserved as "escape to command
-         mode"; conventionally, doubling this character allows it to be
-         entered as data.  The specific character used SHOULD be user
-         selectable.
-
-
-
-Internet Engineering Task Force                                [Page 25]
-
-
-
-
-RFC1123                  REMOTE LOGIN -- TELNET             October 1989
-
-
-         On binary-mode connections, a User Telnet program MAY provide
-         an escape mechanism for entering arbitrary 8-bit values, if the
-         host operating system doesn't allow them to be entered directly
-         from the keyboard.
-
-         IMPLEMENTATION:
-              The transparency issues are less pressing on servers, but
-              implementors should take care in dealing with issues like:
-              masking off parity bits (sent by an older, non-conforming
-              client) before they reach programs that expect only NVT
-              ASCII, and properly handling programs that request 8-bit
-              data streams.
-
-      3.4.2  Telnet Commands
-
-         A User Telnet program MUST provide a user the capability of
-         entering any of the Telnet control functions IP, AO, or AYT,
-         and SHOULD provide the capability of entering EC, EL, and
-         Break.
-
-      3.4.3  TCP Connection Errors
-
-         A User Telnet program SHOULD report to the user any TCP errors
-         that are reported by the transport layer (see "TCP/Application
-         Layer Interface" section in [INTRO:1]).
-
-      3.4.4  Non-Default Telnet Contact Port
-
-         A User Telnet program SHOULD allow the user to optionally
-         specify a non-standard contact port number at the Server Telnet
-         host.
-
-      3.4.5  Flushing Output
-
-         A User Telnet program SHOULD provide the user the ability to
-         specify whether or not output should be flushed when an IP is
-         sent; see Section 3.2.4.
-
-         For any output flushing scheme that causes the User Telnet to
-         flush output locally until a Telnet signal is received from the
-         Server, there SHOULD be a way for the user to manually restore
-         normal output, in case the Server fails to send the expected
-         signal.
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 26]
-
-
-
-
-RFC1123                  REMOTE LOGIN -- TELNET             October 1989
-
-
-   3.5.  TELNET REQUIREMENTS SUMMARY
-
-
-                                                 |        | | | |S| |
-                                                 |        | | | |H| |F
-                                                 |        | | | |O|M|o
-                                                 |        | |S| |U|U|o
-                                                 |        | |H| |L|S|t
-                                                 |        |M|O| |D|T|n
-                                                 |        |U|U|M| | |o
-                                                 |        |S|L|A|N|N|t
-                                                 |        |T|D|Y|O|O|t
-FEATURE                                          |SECTION | | | |T|T|e
--------------------------------------------------|--------|-|-|-|-|-|--
-                                                 |        | | | | | |
-Option Negotiation                               |3.2.1   |x| | | | |
-  Avoid negotiation loops                        |3.2.1   |x| | | | |
-  Refuse unsupported options                     |3.2.1   |x| | | | |
-  Negotiation OK anytime on connection           |3.2.1   | |x| | | |
-  Default to NVT                                 |3.2.1   |x| | | | |
-  Send official name in Term-Type option         |3.2.8   |x| | | | |
-  Accept any name in Term-Type option            |3.2.8   |x| | | | |
-  Implement Binary, Suppress-GA options          |3.3.3   |x| | | | |
-  Echo, Status, EOL, Ext-Opt-List options        |3.3.3   | |x| | | |
-  Implement Window-Size option if appropriate    |3.3.3   | |x| | | |
-  Server initiate mode negotiations              |3.3.4   | |x| | | |
-  User can enable/disable init negotiations      |3.3.4   | |x| | | |
-                                                 |        | | | | | |
-Go-Aheads                                        |        | | | | | |
-  Non-GA server negotiate SUPPRESS-GA option     |3.2.2   |x| | | | |
-  User or Server accept SUPPRESS-GA option       |3.2.2   |x| | | | |
-  User Telnet ignore GA's                        |3.2.2   | | |x| | |
-                                                 |        | | | | | |
-Control Functions                                |        | | | | | |
-  Support SE NOP DM IP AO AYT SB                 |3.2.3   |x| | | | |
-  Support EOR EC EL Break                        |3.2.3   | | |x| | |
-  Ignore unsupported control functions           |3.2.3   |x| | | | |
-  User, Server discard urgent data up to DM      |3.2.4   |x| | | | |
-  User Telnet send "Synch" after IP, AO, AYT     |3.2.4   | |x| | | |
-  Server Telnet reply Synch to IP                |3.2.4   | | |x| | |
-  Server Telnet reply Synch to AO                |3.2.4   |x| | | | |
-  User Telnet can flush output when send IP      |3.2.4   | |x| | | |
-                                                 |        | | | | | |
-Encoding                                         |        | | | | | |
-  Send high-order bit in NVT mode                |3.2.5   | | | |x| |
-  Send high-order bit as parity bit              |3.2.5   | | | | |x|
-  Negot. BINARY if pass high-ord. bit to applic  |3.2.5   | |x| | | |
-  Always double IAC data byte                    |3.2.6   |x| | | | |
-
-
-
-Internet Engineering Task Force                                [Page 27]
-
-
-
-
-RFC1123                  REMOTE LOGIN -- TELNET             October 1989
-
-
-  Double IAC data byte in binary mode            |3.2.7   |x| | | | |
-  Obey Telnet cmds in binary mode                |3.2.7   |x| | | | |
-  End-of-line, CR NUL in binary mode             |3.2.7   | | | | |x|
-                                                 |        | | | | | |
-End-of-Line                                      |        | | | | | |
-  EOL at Server same as local end-of-line        |3.3.1   |x| | | | |
-  ASCII Server accept CR LF or CR NUL for EOL    |3.3.1   |x| | | | |
-  User Telnet able to send CR LF, CR NUL, or LF  |3.3.1   |x| | | | |
-    ASCII user able to select CR LF/CR NUL       |3.3.1   | |x| | | |
-    User Telnet default mode is CR LF            |3.3.1   | |x| | | |
-  Non-interactive uses CR LF for EOL             |3.3.1   |x| | | | |
-                                                 |        | | | | | |
-User Telnet interface                            |        | | | | | |
-  Input & output all 7-bit characters            |3.4.1   | |x| | | |
-  Bypass local op sys interpretation             |3.4.1   | |x| | | |
-  Escape character                               |3.4.1   |x| | | | |
-     User-settable escape character              |3.4.1   | |x| | | |
-  Escape to enter 8-bit values                   |3.4.1   | | |x| | |
-  Can input IP, AO, AYT                          |3.4.2   |x| | | | |
-  Can input EC, EL, Break                        |3.4.2   | |x| | | |
-  Report TCP connection errors to user           |3.4.3   | |x| | | |
-  Optional non-default contact port              |3.4.4   | |x| | | |
-  Can spec: output flushed when IP sent          |3.4.5   | |x| | | |
-  Can manually restore output mode               |3.4.5   | |x| | | |
-                                                 |        | | | | | |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 28]
-
-
-
-
-RFC1123                   FILE TRANSFER -- FTP              October 1989
-
-
-4.  FILE TRANSFER
-
-   4.1  FILE TRANSFER PROTOCOL -- FTP
-
-      4.1.1  INTRODUCTION
-
-         The File Transfer Protocol FTP is the primary Internet standard
-         for file transfer.  The current specification is contained in
-         RFC-959 [FTP:1].
-
-         FTP uses separate simultaneous TCP connections for control and
-         for data transfer.  The FTP protocol includes many features,
-         some of which are not commonly implemented.  However, for every
-         feature in FTP, there exists at least one implementation.  The
-         minimum implementation defined in RFC-959 was too small, so a
-         somewhat larger minimum implementation is defined here.
-
-         Internet users have been unnecessarily burdened for years by
-         deficient FTP implementations.  Protocol implementors have
-         suffered from the erroneous opinion that implementing FTP ought
-         to be a small and trivial task.  This is wrong, because FTP has
-         a user interface, because it has to deal (correctly) with the
-         whole variety of communication and operating system errors that
-         may occur, and because it has to handle the great diversity of
-         real file systems in the world.
-
-      4.1.2.  PROTOCOL WALK-THROUGH
-
-         4.1.2.1  LOCAL Type: RFC-959 Section 3.1.1.4
-
-            An FTP program MUST support TYPE I ("IMAGE" or binary type)
-            as well as TYPE L 8 ("LOCAL" type with logical byte size 8).
-            A machine whose memory is organized into m-bit words, where
-            m is not a multiple of 8, MAY also support TYPE L m.
-
-            DISCUSSION:
-                 The command "TYPE L 8" is often required to transfer
-                 binary data between a machine whose memory is organized
-                 into (e.g.) 36-bit words and a machine with an 8-bit
-                 byte organization.  For an 8-bit byte machine, TYPE L 8
-                 is equivalent to IMAGE.
-
-                 "TYPE L m" is sometimes specified to the FTP programs
-                 on two m-bit word machines to ensure the correct
-                 transfer of a native-mode binary file from one machine
-                 to the other.  However, this command should have the
-                 same effect on these machines as "TYPE I".
-
-
-
-
-Internet Engineering Task Force                                [Page 29]
-
-
-
-
-RFC1123                   FILE TRANSFER -- FTP              October 1989
-
-
-         4.1.2.2  Telnet Format Control: RFC-959 Section 3.1.1.5.2
-
-            A host that makes no distinction between TYPE N and TYPE T
-            SHOULD implement TYPE T to be identical to TYPE N.
-
-            DISCUSSION:
-                 This provision should ease interoperation with hosts
-                 that do make this distinction.
-
-                 Many hosts represent text files internally as strings
-                 of ASCII characters, using the embedded ASCII format
-                 effector characters (LF, BS, FF, ...) to control the
-                 format when a file is printed.  For such hosts, there
-                 is no distinction between "print" files and other
-                 files.  However, systems that use record structured
-                 files typically need a special format for printable
-                 files (e.g., ASA carriage control).   For the latter
-                 hosts, FTP allows a choice of TYPE N or TYPE T.
-
-         4.1.2.3  Page Structure: RFC-959 Section 3.1.2.3 and Appendix I
-
-            Implementation of page structure is NOT RECOMMENDED in
-            general. However, if a host system does need to implement
-            FTP for "random access" or "holey" files, it MUST use the
-            defined page structure format rather than define a new
-            private FTP format.
-
-         4.1.2.4  Data Structure Transformations: RFC-959 Section 3.1.2
-
-            An FTP transformation between record-structure and file-
-            structure SHOULD be invertible, to the extent possible while
-            making the result useful on the target host.
-
-            DISCUSSION:
-                 RFC-959 required strict invertibility between record-
-                 structure and file-structure, but in practice,
-                 efficiency and convenience often preclude it.
-                 Therefore, the requirement is being relaxed.  There are
-                 two different objectives for transferring a file:
-                 processing it on the target host, or just storage.  For
-                 storage, strict invertibility is important.  For
-                 processing, the file created on the target host needs
-                 to be in the format expected by application programs on
-                 that host.
-
-                 As an example of the conflict, imagine a record-
-                 oriented operating system that requires some data files
-                 to have exactly 80 bytes in each record.  While STORing
-
-
-
-Internet Engineering Task Force                                [Page 30]
-
-
-
-
-RFC1123                   FILE TRANSFER -- FTP              October 1989
-
-
-                 a file on such a host, an FTP Server must be able to
-                 pad each line or record to 80 bytes; a later retrieval
-                 of such a file cannot be strictly invertible.
-
-         4.1.2.5  Data Connection Management: RFC-959 Section 3.3
-
-            A User-FTP that uses STREAM mode SHOULD send a PORT command
-            to assign a non-default data port before each transfer
-            command is issued.
-
-            DISCUSSION:
-                 This is required because of the long delay after a TCP
-                 connection is closed until its socket pair can be
-                 reused, to allow multiple transfers during a single FTP
-                 session.  Sending a port command can avoided if a
-                 transfer mode other than stream is used, by leaving the
-                 data transfer connection open between transfers.
-
-         4.1.2.6  PASV Command: RFC-959 Section 4.1.2
-
-            A server-FTP MUST implement the PASV command.
-
-            If multiple third-party transfers are to be executed during
-            the same session, a new PASV command MUST be issued before
-            each transfer command, to obtain a unique port pair.
-
-            IMPLEMENTATION:
-                 The format of the 227 reply to a PASV command is not
-                 well standardized.  In particular, an FTP client cannot
-                 assume that the parentheses shown on page 40 of RFC-959
-                 will be present (and in fact, Figure 3 on page 43 omits
-                 them).  Therefore, a User-FTP program that interprets
-                 the PASV reply must scan the reply for the first digit
-                 of the host and port numbers.
-
-                 Note that the host number h1,h2,h3,h4 is the IP address
-                 of the server host that is sending the reply, and that
-                 p1,p2 is a non-default data transfer port that PASV has
-                 assigned.
-
-         4.1.2.7  LIST and NLST Commands: RFC-959 Section 4.1.3
-
-            The data returned by an NLST command MUST contain only a
-            simple list of legal pathnames, such that the server can use
-            them directly as the arguments of subsequent data transfer
-            commands for the individual files.
-
-            The data returned by a LIST or NLST command SHOULD use an
-
-
-
-Internet Engineering Task Force                                [Page 31]
-
-
-
-
-RFC1123                   FILE TRANSFER -- FTP              October 1989
-
-
-            implied TYPE AN, unless the current type is EBCDIC, in which
-            case an implied TYPE EN SHOULD be used.
-
-            DISCUSSION:
-                 Many FTP clients support macro-commands that will get
-                 or put files matching a wildcard specification, using
-                 NLST to obtain a list of pathnames.  The expansion of
-                 "multiple-put" is local to the client, but "multiple-
-                 get" requires cooperation by the server.
-
-                 The implied type for LIST and NLST is designed to
-                 provide compatibility with existing User-FTPs, and in
-                 particular with multiple-get commands.
-
-         4.1.2.8  SITE Command: RFC-959 Section 4.1.3
-
-            A Server-FTP SHOULD use the SITE command for non-standard
-            features, rather than invent new private commands or
-            unstandardized extensions to existing commands.
-
-         4.1.2.9  STOU Command: RFC-959 Section 4.1.3
-
-            The STOU command stores into a uniquely named file.  When it
-            receives an STOU command, a Server-FTP MUST return the
-            actual file name in the "125 Transfer Starting" or the "150
-            Opening Data Connection" message that precedes the transfer
-            (the 250 reply code mentioned in RFC-959 is incorrect).  The
-            exact format of these messages is hereby defined to be as
-            follows:
-
-                125 FILE: pppp
-                150 FILE: pppp
-
-            where pppp represents the unique pathname of the file that
-            will be written.
-
-         4.1.2.10  Telnet End-of-line Code: RFC-959, Page 34
-
-            Implementors MUST NOT assume any correspondence between READ
-            boundaries on the control connection and the Telnet EOL
-            sequences (CR LF).
-
-            DISCUSSION:
-                 Thus, a server-FTP (or User-FTP) must continue reading
-                 characters from the control connection until a complete
-                 Telnet EOL sequence is encountered, before processing
-                 the command (or response, respectively).  Conversely, a
-                 single READ from the control connection may include
-
-
-
-Internet Engineering Task Force                                [Page 32]
-
-
-
-
-RFC1123                   FILE TRANSFER -- FTP              October 1989
-
-
-                 more than one FTP command.
-
-         4.1.2.11  FTP Replies: RFC-959 Section 4.2, Page 35
-
-            A Server-FTP MUST send only correctly formatted replies on
-            the control connection.  Note that RFC-959 (unlike earlier
-            versions of the FTP spec) contains no provision for a
-            "spontaneous" reply message.
-
-            A Server-FTP SHOULD use the reply codes defined in RFC-959
-            whenever they apply.  However, a server-FTP MAY use a
-            different reply code when needed, as long as the general
-            rules of Section 4.2 are followed. When the implementor has
-            a choice between a 4xx and 5xx reply code, a Server-FTP
-            SHOULD send a 4xx (temporary failure) code when there is any
-            reasonable possibility that a failed FTP will succeed a few
-            hours later.
-
-            A User-FTP SHOULD generally use only the highest-order digit
-            of a 3-digit reply code for making a procedural decision, to
-            prevent difficulties when a Server-FTP uses non-standard
-            reply codes.
-
-            A User-FTP MUST be able to handle multi-line replies.  If
-            the implementation imposes a limit on the number of lines
-            and if this limit is exceeded, the User-FTP MUST recover,
-            e.g., by ignoring the excess lines until the end of the
-            multi-line reply is reached.
-
-            A User-FTP SHOULD NOT interpret a 421 reply code ("Service
-            not available, closing control connection") specially, but
-            SHOULD detect closing of the control connection by the
-            server.
-
-            DISCUSSION:
-                 Server implementations that fail to strictly follow the
-                 reply rules often cause FTP user programs to hang.
-                 Note that RFC-959 resolved ambiguities in the reply
-                 rules found in earlier FTP specifications and must be
-                 followed.
-
-                 It is important to choose FTP reply codes that properly
-                 distinguish between temporary and permanent failures,
-                 to allow the successful use of file transfer client
-                 daemons.  These programs depend on the reply codes to
-                 decide whether or not to retry a failed transfer; using
-                 a permanent failure code (5xx) for a temporary error
-                 will cause these programs to give up unnecessarily.
-
-
-
-Internet Engineering Task Force                                [Page 33]
-
-
-
-
-RFC1123                   FILE TRANSFER -- FTP              October 1989
-
-
-                 When the meaning of a reply matches exactly the text
-                 shown in RFC-959, uniformity will be enhanced by using
-                 the RFC-959 text verbatim.  However, a Server-FTP
-                 implementor is encouraged to choose reply text that
-                 conveys specific system-dependent information, when
-                 appropriate.
-
-         4.1.2.12  Connections: RFC-959 Section 5.2
-
-            The words "and the port used" in the second paragraph of
-            this section of RFC-959 are erroneous (historical), and they
-            should be ignored.
-
-            On a multihomed server host, the default data transfer port
-            (L-1) MUST be associated with the same local IP address as
-            the corresponding control connection to port L.
-
-            A user-FTP MUST NOT send any Telnet controls other than
-            SYNCH and IP on an FTP control connection. In particular, it
-            MUST NOT attempt to negotiate Telnet options on the control
-            connection.  However, a server-FTP MUST be capable of
-            accepting and refusing Telnet negotiations (i.e., sending
-            DONT/WONT).
-
-            DISCUSSION:
-                 Although the RFC says: "Server- and User- processes
-                 should follow the conventions for the Telnet
-                 protocol...[on the control connection]", it is not the
-                 intent that Telnet option negotiation is to be
-                 employed.
-
-         4.1.2.13  Minimum Implementation; RFC-959 Section 5.1
-
-            The following commands and options MUST be supported by
-            every server-FTP and user-FTP, except in cases where the
-            underlying file system or operating system does not allow or
-            support a particular command.
-
-                 Type: ASCII Non-print, IMAGE, LOCAL 8
-                 Mode: Stream
-                 Structure: File, Record*
-                 Commands:
-                    USER, PASS, ACCT,
-                    PORT, PASV,
-                    TYPE, MODE, STRU,
-                    RETR, STOR, APPE,
-                    RNFR, RNTO, DELE,
-                    CWD,  CDUP, RMD,  MKD,  PWD,
-
-
-
-Internet Engineering Task Force                                [Page 34]
-
-
-
-
-RFC1123                   FILE TRANSFER -- FTP              October 1989
-
-
-                    LIST, NLST,
-                    SYST, STAT,
-                    HELP, NOOP, QUIT.
-
-            *Record structure is REQUIRED only for hosts whose file
-            systems support record structure.
-
-            DISCUSSION:
-                 Vendors are encouraged to implement a larger subset of
-                 the protocol.  For example, there are important
-                 robustness features in the protocol (e.g., Restart,
-                 ABOR, block mode) that would be an aid to some Internet
-                 users but are not widely implemented.
-
-                 A host that does not have record structures in its file
-                 system may still accept files with STRU R, recording
-                 the byte stream literally.
-
-      4.1.3  SPECIFIC ISSUES
-
-         4.1.3.1  Non-standard Command Verbs
-
-            FTP allows "experimental" commands, whose names begin with
-            "X".  If these commands are subsequently adopted as
-            standards, there may still be existing implementations using
-            the "X" form.  At present, this is true for the directory
-            commands:
-
-                RFC-959   "Experimental"
-
-                  MKD        XMKD
-                  RMD        XRMD
-                  PWD        XPWD
-                  CDUP       XCUP
-                  CWD        XCWD
-
-            All FTP implementations SHOULD recognize both forms of these
-            commands, by simply equating them with extra entries in the
-            command lookup table.
-
-            IMPLEMENTATION:
-                 A User-FTP can access a server that supports only the
-                 "X" forms by implementing a mode switch, or
-                 automatically using the following procedure: if the
-                 RFC-959 form of one of the above commands is rejected
-                 with a 500 or 502 response code, then try the
-                 experimental form; any other response would be passed
-                 to the user.
-
-
-
-Internet Engineering Task Force                                [Page 35]
-
-
-
-
-RFC1123                   FILE TRANSFER -- FTP              October 1989
-
-
-         4.1.3.2  Idle Timeout
-
-            A Server-FTP process SHOULD have an idle timeout, which will
-            terminate the process and close the control connection if
-            the server is inactive (i.e., no command or data transfer in
-            progress) for a long period of time.  The idle timeout time
-            SHOULD be configurable, and the default should be at least 5
-            minutes.
-
-            A client FTP process ("User-PI" in RFC-959) will need
-            timeouts on responses only if it is invoked from a program.
-
-            DISCUSSION:
-                 Without a timeout, a Server-FTP process may be left
-                 pending indefinitely if the corresponding client
-                 crashes without closing the control connection.
-
-         4.1.3.3  Concurrency of Data and Control
-
-            DISCUSSION:
-                 The intent of the designers of FTP was that a user
-                 should be able to send a STAT command at any time while
-                 data transfer was in progress and that the server-FTP
-                 would reply immediately with status -- e.g., the number
-                 of bytes transferred so far.  Similarly, an ABOR
-                 command should be possible at any time during a data
-                 transfer.
-
-                 Unfortunately, some small-machine operating systems
-                 make such concurrent programming difficult, and some
-                 other implementers seek minimal solutions, so some FTP
-                 implementations do not allow concurrent use of the data
-                 and control connections.  Even such a minimal server
-                 must be prepared to accept and defer a STAT or ABOR
-                 command that arrives during data transfer.
-
-         4.1.3.4  FTP Restart Mechanism
-
-            The description of the 110 reply on pp. 40-41 of RFC-959 is
-            incorrect; the correct description is as follows.  A restart
-            reply message, sent over the control connection from the
-            receiving FTP to the User-FTP, has the format:
-
-                110 MARK ssss = rrrr
-
-            Here:
-
-            *    ssss is a text string that appeared in a Restart Marker
-
-
-
-Internet Engineering Task Force                                [Page 36]
-
-
-
-
-RFC1123                   FILE TRANSFER -- FTP              October 1989
-
-
-                 in the data stream and encodes a position in the
-                 sender's file system;
-
-            *    rrrr encodes the corresponding position in the
-                 receiver's file system.
-
-            The encoding, which is specific to a particular file system
-            and network implementation, is always generated and
-            interpreted by the same system, either sender or receiver.
-
-            When an FTP that implements restart receives a Restart
-            Marker in the data stream, it SHOULD force the data to that
-            point to be written to stable storage before encoding the
-            corresponding position rrrr.  An FTP sending Restart Markers
-            MUST NOT assume that 110 replies will be returned
-            synchronously with the data, i.e., it must not await a 110
-            reply before sending more data.
-
-            Two new reply codes are hereby defined for errors
-            encountered in restarting a transfer:
-
-              554 Requested action not taken: invalid REST parameter.
-
-                 A 554 reply may result from a FTP service command that
-                 follows a REST command.  The reply indicates that the
-                 existing file at the Server-FTP cannot be repositioned
-                 as specified in the REST.
-
-              555 Requested action not taken: type or stru mismatch.
-
-                 A 555 reply may result from an APPE command or from any
-                 FTP service command following a REST command.  The
-                 reply indicates that there is some mismatch between the
-                 current transfer parameters (type and stru) and the
-                 attributes of the existing file.
-
-            DISCUSSION:
-                 Note that the FTP Restart mechanism requires that Block
-                 or Compressed mode be used for data transfer, to allow
-                 the Restart Markers to be included within the data
-                 stream.  The frequency of Restart Markers can be low.
-
-                 Restart Markers mark a place in the data stream, but
-                 the receiver may be performing some transformation on
-                 the data as it is stored into stable storage.  In
-                 general, the receiver's encoding must include any state
-                 information necessary to restart this transformation at
-                 any point of the FTP data stream.  For example, in TYPE
-
-
-
-Internet Engineering Task Force                                [Page 37]
-
-
-
-
-RFC1123                   FILE TRANSFER -- FTP              October 1989
-
-
-                 A transfers, some receiver hosts transform CR LF
-                 sequences into a single LF character on disk.   If a
-                 Restart Marker happens to fall between CR and LF, the
-                 receiver must encode in rrrr that the transfer must be
-                 restarted in a "CR has been seen and discarded" state.
-
-                 Note that the Restart Marker is required to be encoded
-                 as a string of printable ASCII characters, regardless
-                 of the type of the data.
-
-                 RFC-959 says that restart information is to be returned
-                 "to the user".  This should not be taken literally.  In
-                 general, the User-FTP should save the restart
-                 information (ssss,rrrr) in stable storage, e.g., append
-                 it to a restart control file.  An empty restart control
-                 file should be created when the transfer first starts
-                 and deleted automatically when the transfer completes
-                 successfully.  It is suggested that this file have a
-                 name derived in an easily-identifiable manner from the
-                 name of the file being transferred and the remote host
-                 name; this is analogous to the means used by many text
-                 editors for naming "backup" files.
-
-                 There are three cases for FTP restart.
-
-                 (1)  User-to-Server Transfer
-
-                      The User-FTP puts Restart Markers <ssss> at
-                      convenient places in the data stream.  When the
-                      Server-FTP receives a Marker, it writes all prior
-                      data to disk, encodes its file system position and
-                      transformation state as rrrr, and returns a "110
-                      MARK ssss = rrrr" reply over the control
-                      connection.  The User-FTP appends the pair
-                      (ssss,rrrr) to its restart control file.
-
-                      To restart the transfer, the User-FTP fetches the
-                      last (ssss,rrrr) pair from the restart control
-                      file, repositions its local file system and
-                      transformation state using ssss, and sends the
-                      command "REST rrrr" to the Server-FTP.
-
-                 (2)  Server-to-User Transfer
-
-                      The Server-FTP puts Restart Markers <ssss> at
-                      convenient places in the data stream.  When the
-                      User-FTP receives a Marker, it writes all prior
-                      data to disk, encodes its file system position and
-
-
-
-Internet Engineering Task Force                                [Page 38]
-
-
-
-
-RFC1123                   FILE TRANSFER -- FTP              October 1989
-
-
-                      transformation state as rrrr, and appends the pair
-                      (rrrr,ssss) to its restart control file.
-
-                      To restart the transfer, the User-FTP fetches the
-                      last (rrrr,ssss) pair from the restart control
-                      file, repositions its local file system and
-                      transformation state using rrrr, and sends the
-                      command "REST ssss" to the Server-FTP.
-
-                 (3)  Server-to-Server ("Third-Party") Transfer
-
-                      The sending Server-FTP puts Restart Markers <ssss>
-                      at convenient places in the data stream.  When it
-                      receives a Marker, the receiving Server-FTP writes
-                      all prior data to disk, encodes its file system
-                      position and transformation state as rrrr, and
-                      sends a "110 MARK ssss = rrrr" reply over the
-                      control connection to the User.  The User-FTP
-                      appends the pair (ssss,rrrr) to its restart
-                      control file.
-
-                      To restart the transfer, the User-FTP fetches the
-                      last (ssss,rrrr) pair from the restart control
-                      file, sends "REST ssss" to the sending Server-FTP,
-                      and sends "REST rrrr" to the receiving Server-FTP.
-
-
-      4.1.4  FTP/USER INTERFACE
-
-         This section discusses the user interface for a User-FTP
-         program.
-
-         4.1.4.1  Pathname Specification
-
-            Since FTP is intended for use in a heterogeneous
-            environment, User-FTP implementations MUST support remote
-            pathnames as arbitrary character strings, so that their form
-            and content are not limited by the conventions of the local
-            operating system.
-
-            DISCUSSION:
-                 In particular, remote pathnames can be of arbitrary
-                 length, and all the printing ASCII characters as well
-                 as space (0x20) must be allowed.  RFC-959 allows a
-                 pathname to contain any 7-bit ASCII character except CR
-                 or LF.
-
-
-
-
-
-Internet Engineering Task Force                                [Page 39]
-
-
-
-
-RFC1123                   FILE TRANSFER -- FTP              October 1989
-
-
-         4.1.4.2  "QUOTE" Command
-
-            A User-FTP program MUST implement a "QUOTE" command that
-            will pass an arbitrary character string to the server and
-            display all resulting response messages to the user.
-
-            To make the "QUOTE" command useful, a User-FTP SHOULD send
-            transfer control commands to the server as the user enters
-            them, rather than saving all the commands and sending them
-            to the server only when a data transfer is started.
-
-            DISCUSSION:
-                 The "QUOTE" command is essential to allow the user to
-                 access servers that require system-specific commands
-                 (e.g., SITE or ALLO), or to invoke new or optional
-                 features that are not implemented by the User-FTP.  For
-                 example, "QUOTE" may be used to specify "TYPE A T" to
-                 send a print file to hosts that require the
-                 distinction, even if the User-FTP does not recognize
-                 that TYPE.
-
-         4.1.4.3  Displaying Replies to User
-
-            A User-FTP SHOULD display to the user the full text of all
-            error reply messages it receives.  It SHOULD have a
-            "verbose" mode in which all commands it sends and the full
-            text and reply codes it receives are displayed, for
-            diagnosis of problems.
-
-         4.1.4.4  Maintaining Synchronization
-
-            The state machine in a User-FTP SHOULD be forgiving of
-            missing and unexpected reply messages, in order to maintain
-            command synchronization with the server.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 40]
-
-
-
-
-RFC1123                   FILE TRANSFER -- FTP              October 1989
-
-
-      4.1.5   FTP REQUIREMENTS SUMMARY
-
-                                           |               | | | |S| |
-                                           |               | | | |H| |F
-                                           |               | | | |O|M|o
-                                           |               | |S| |U|U|o
-                                           |               | |H| |L|S|t
-                                           |               |M|O| |D|T|n
-                                           |               |U|U|M| | |o
-                                           |               |S|L|A|N|N|t
-                                           |               |T|D|Y|O|O|t
-FEATURE                                    |SECTION        | | | |T|T|e
--------------------------------------------|---------------|-|-|-|-|-|--
-Implement TYPE T if same as TYPE N         |4.1.2.2        | |x| | | |
-File/Record transform invertible if poss.  |4.1.2.4        | |x| | | |
-User-FTP send PORT cmd for stream mode     |4.1.2.5        | |x| | | |
-Server-FTP implement PASV                  |4.1.2.6        |x| | | | |
-  PASV is per-transfer                     |4.1.2.6        |x| | | | |
-NLST reply usable in RETR cmds             |4.1.2.7        |x| | | | |
-Implied type for LIST and NLST             |4.1.2.7        | |x| | | |
-SITE cmd for non-standard features         |4.1.2.8        | |x| | | |
-STOU cmd return pathname as specified      |4.1.2.9        |x| | | | |
-Use TCP READ boundaries on control conn.   |4.1.2.10       | | | | |x|
-                                           |               | | | | | |
-Server-FTP send only correct reply format  |4.1.2.11       |x| | | | |
-Server-FTP use defined reply code if poss. |4.1.2.11       | |x| | | |
-  New reply code following Section 4.2     |4.1.2.11       | | |x| | |
-User-FTP use only high digit of reply      |4.1.2.11       | |x| | | |
-User-FTP handle multi-line reply lines     |4.1.2.11       |x| | | | |
-User-FTP handle 421 reply specially        |4.1.2.11       | | | |x| |
-                                           |               | | | | | |
-Default data port same IP addr as ctl conn |4.1.2.12       |x| | | | |
-User-FTP send Telnet cmds exc. SYNCH, IP   |4.1.2.12       | | | | |x|
-User-FTP negotiate Telnet options          |4.1.2.12       | | | | |x|
-Server-FTP handle Telnet options           |4.1.2.12       |x| | | | |
-Handle "Experimental" directory cmds       |4.1.3.1        | |x| | | |
-Idle timeout in server-FTP                 |4.1.3.2        | |x| | | |
-    Configurable idle timeout              |4.1.3.2        | |x| | | |
-Receiver checkpoint data at Restart Marker |4.1.3.4        | |x| | | |
-Sender assume 110 replies are synchronous  |4.1.3.4        | | | | |x|
-                                           |               | | | | | |
-Support TYPE:                              |               | | | | | |
-  ASCII - Non-Print (AN)                   |4.1.2.13       |x| | | | |
-  ASCII - Telnet (AT) -- if same as AN     |4.1.2.2        | |x| | | |
-  ASCII - Carriage Control (AC)            |959 3.1.1.5.2  | | |x| | |
-  EBCDIC - (any form)                      |959 3.1.1.2    | | |x| | |
-  IMAGE                                    |4.1.2.1        |x| | | | |
-  LOCAL 8                                  |4.1.2.1        |x| | | | |
-
-
-
-Internet Engineering Task Force                                [Page 41]
-
-
-
-
-RFC1123                   FILE TRANSFER -- FTP              October 1989
-
-
-  LOCAL m                                  |4.1.2.1        | | |x| | |2
-                                           |               | | | | | |
-Support MODE:                              |               | | | | | |
-  Stream                                   |4.1.2.13       |x| | | | |
-  Block                                    |959 3.4.2      | | |x| | |
-                                           |               | | | | | |
-Support STRUCTURE:                         |               | | | | | |
-  File                                     |4.1.2.13       |x| | | | |
-  Record                                   |4.1.2.13       |x| | | | |3
-  Page                                     |4.1.2.3        | | | |x| |
-                                           |               | | | | | |
-Support commands:                          |               | | | | | |
-  USER                                     |4.1.2.13       |x| | | | |
-  PASS                                     |4.1.2.13       |x| | | | |
-  ACCT                                     |4.1.2.13       |x| | | | |
-  CWD                                      |4.1.2.13       |x| | | | |
-  CDUP                                     |4.1.2.13       |x| | | | |
-  SMNT                                     |959 5.3.1      | | |x| | |
-  REIN                                     |959 5.3.1      | | |x| | |
-  QUIT                                     |4.1.2.13       |x| | | | |
-                                           |               | | | | | |
-  PORT                                     |4.1.2.13       |x| | | | |
-  PASV                                     |4.1.2.6        |x| | | | |
-  TYPE                                     |4.1.2.13       |x| | | | |1
-  STRU                                     |4.1.2.13       |x| | | | |1
-  MODE                                     |4.1.2.13       |x| | | | |1
-                                           |               | | | | | |
-  RETR                                     |4.1.2.13       |x| | | | |
-  STOR                                     |4.1.2.13       |x| | | | |
-  STOU                                     |959 5.3.1      | | |x| | |
-  APPE                                     |4.1.2.13       |x| | | | |
-  ALLO                                     |959 5.3.1      | | |x| | |
-  REST                                     |959 5.3.1      | | |x| | |
-  RNFR                                     |4.1.2.13       |x| | | | |
-  RNTO                                     |4.1.2.13       |x| | | | |
-  ABOR                                     |959 5.3.1      | | |x| | |
-  DELE                                     |4.1.2.13       |x| | | | |
-  RMD                                      |4.1.2.13       |x| | | | |
-  MKD                                      |4.1.2.13       |x| | | | |
-  PWD                                      |4.1.2.13       |x| | | | |
-  LIST                                     |4.1.2.13       |x| | | | |
-  NLST                                     |4.1.2.13       |x| | | | |
-  SITE                                     |4.1.2.8        | | |x| | |
-  STAT                                     |4.1.2.13       |x| | | | |
-  SYST                                     |4.1.2.13       |x| | | | |
-  HELP                                     |4.1.2.13       |x| | | | |
-  NOOP                                     |4.1.2.13       |x| | | | |
-                                           |               | | | | | |
-
-
-
-Internet Engineering Task Force                                [Page 42]
-
-
-
-
-RFC1123                   FILE TRANSFER -- FTP              October 1989
-
-
-User Interface:                            |               | | | | | |
-  Arbitrary pathnames                      |4.1.4.1        |x| | | | |
-  Implement "QUOTE" command                |4.1.4.2        |x| | | | |
-  Transfer control commands immediately    |4.1.4.2        | |x| | | |
-  Display error messages to user           |4.1.4.3        | |x| | | |
-    Verbose mode                           |4.1.4.3        | |x| | | |
-  Maintain synchronization with server     |4.1.4.4        | |x| | | |
-
-Footnotes:
-
-(1)  For the values shown earlier.
-
-(2)  Here m is number of bits in a memory word.
-
-(3)  Required for host with record-structured file system, optional
-     otherwise.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 43]
-
-
-
-
-RFC1123                  FILE TRANSFER -- TFTP              October 1989
-
-
-   4.2  TRIVIAL FILE TRANSFER PROTOCOL -- TFTP
-
-      4.2.1  INTRODUCTION
-
-         The Trivial File Transfer Protocol TFTP is defined in RFC-783
-         [TFTP:1].
-
-         TFTP provides its own reliable delivery with UDP as its
-         transport protocol, using a simple stop-and-wait acknowledgment
-         system.  Since TFTP has an effective window of only one 512
-         octet segment, it can provide good performance only over paths
-         that have a small delay*bandwidth product.  The TFTP file
-         interface is very simple, providing no access control or
-         security.
-
-         TFTP's most important application is bootstrapping a host over
-         a local network, since it is simple and small enough to be
-         easily implemented in EPROM [BOOT:1, BOOT:2].  Vendors are
-         urged to support TFTP for booting.
-
-      4.2.2  PROTOCOL WALK-THROUGH
-
-         The TFTP specification [TFTP:1] is written in an open style,
-         and does not fully specify many parts of the protocol.
-
-         4.2.2.1  Transfer Modes: RFC-783, Page 3
-
-            The transfer mode "mail" SHOULD NOT be supported.
-
-         4.2.2.2  UDP Header: RFC-783, Page 17
-
-            The Length field of a UDP header is incorrectly defined; it
-            includes the UDP header length (8).
-
-      4.2.3  SPECIFIC ISSUES
-
-         4.2.3.1  Sorcerer's Apprentice Syndrome
-
-            There is a serious bug, known as the "Sorcerer's Apprentice
-            Syndrome," in the protocol specification.  While it does not
-            cause incorrect operation of the transfer (the file will
-            always be transferred correctly if the transfer completes),
-            this bug may cause excessive retransmission, which may cause
-            the transfer to time out.
-
-            Implementations MUST contain the fix for this problem: the
-            sender (i.e., the side originating the DATA packets) must
-            never resend the current DATA packet on receipt of a
-
-
-
-Internet Engineering Task Force                                [Page 44]
-
-
-
-
-RFC1123                  FILE TRANSFER -- TFTP              October 1989
-
-
-            duplicate ACK.
-
-            DISCUSSION:
-                 The bug is caused by the protocol rule that either
-                 side, on receiving an old duplicate datagram, may
-                 resend the current datagram.  If a packet is delayed in
-                 the network but later successfully delivered after
-                 either side has timed out and retransmitted a packet, a
-                 duplicate copy of the response may be generated.  If
-                 the other side responds to this duplicate with a
-                 duplicate of its own, then every datagram will be sent
-                 in duplicate for the remainder of the transfer (unless
-                 a datagram is lost, breaking the repetition).  Worse
-                 yet, since the delay is often caused by congestion,
-                 this duplicate transmission will usually causes more
-                 congestion, leading to more delayed packets, etc.
-
-                 The following example may help to clarify this problem.
-
-                     TFTP A                  TFTP B
-
-                 (1)  Receive ACK X-1
-                      Send DATA X
-                 (2)                          Receive DATA X
-                                              Send ACK X
-                        (ACK X is delayed in network,
-                         and  A times out):
-                 (3)  Retransmit DATA X
-
-                 (4)                          Receive DATA X again
-                                              Send ACK X again
-                 (5)  Receive (delayed) ACK X
-                      Send DATA X+1
-                 (6)                          Receive DATA X+1
-                                              Send ACK X+1
-                 (7)  Receive ACK X again
-                      Send DATA X+1 again
-                 (8)                          Receive DATA X+1 again
-                                              Send ACK X+1 again
-                 (9)  Receive ACK X+1
-                      Send DATA X+2
-                 (10)                         Receive DATA X+2
-                                              Send ACK X+3
-                 (11) Receive ACK X+1 again
-                      Send DATA X+2 again
-                 (12)                         Receive DATA X+2 again
-                                              Send ACK X+3 again
-
-
-
-
-Internet Engineering Task Force                                [Page 45]
-
-
-
-
-RFC1123                  FILE TRANSFER -- TFTP              October 1989
-
-
-                 Notice that once the delayed ACK arrives, the protocol
-                 settles down to duplicate all further packets
-                 (sequences 5-8 and 9-12).  The problem is caused not by
-                 either side timing out, but by both sides
-                 retransmitting the current packet when they receive a
-                 duplicate.
-
-                 The fix is to break the retransmission loop, as
-                 indicated above.  This is analogous to the behavior of
-                 TCP.  It is then possible to remove the retransmission
-                 timer on the receiver, since the resent ACK will never
-                 cause any action; this is a useful simplification where
-                 TFTP is used in a bootstrap program.  It is OK to allow
-                 the timer to remain, and it may be helpful if the
-                 retransmitted ACK replaces one that was genuinely lost
-                 in the network.  The sender still requires a retransmit
-                 timer, of course.
-
-         4.2.3.2  Timeout Algorithms
-
-            A TFTP implementation MUST use an adaptive timeout.
-
-            IMPLEMENTATION:
-                 TCP retransmission algorithms provide a useful base to
-                 work from.  At least an exponential backoff of
-                 retransmission timeout is necessary.
-
-         4.2.3.3  Extensions
-
-            A variety of non-standard extensions have been made to TFTP,
-            including additional transfer modes and a secure operation
-            mode (with passwords).  None of these have been
-            standardized.
-
-         4.2.3.4  Access Control
-
-            A server TFTP implementation SHOULD include some
-            configurable access control over what pathnames are allowed
-            in TFTP operations.
-
-         4.2.3.5  Broadcast Request
-
-            A TFTP request directed to a broadcast address SHOULD be
-            silently ignored.
-
-            DISCUSSION:
-                 Due to the weak access control capability of TFTP,
-                 directed broadcasts of TFTP requests to random networks
-
-
-
-Internet Engineering Task Force                                [Page 46]
-
-
-
-
-RFC1123                  FILE TRANSFER -- TFTP              October 1989
-
-
-                 could create a significant security hole.
-
-      4.2.4  TFTP REQUIREMENTS SUMMARY
-
-                                                 |        | | | |S| |
-                                                 |        | | | |H| |F
-                                                 |        | | | |O|M|o
-                                                 |        | |S| |U|U|o
-                                                 |        | |H| |L|S|t
-                                                 |        |M|O| |D|T|n
-                                                 |        |U|U|M| | |o
-                                                 |        |S|L|A|N|N|t
-                                                 |        |T|D|Y|O|O|t
-FEATURE                                          |SECTION | | | |T|T|e
--------------------------------------------------|--------|-|-|-|-|-|--
-Fix Sorcerer's Apprentice Syndrome               |4.2.3.1 |x| | | | |
-Transfer modes:                                  |        | | | | | |
-  netascii                                       |RFC-783 |x| | | | |
-  octet                                          |RFC-783 |x| | | | |
-  mail                                           |4.2.2.1 | | | |x| |
-  extensions                                     |4.2.3.3 | | |x| | |
-Use adaptive timeout                             |4.2.3.2 |x| | | | |
-Configurable access control                      |4.2.3.4 | |x| | | |
-Silently ignore broadcast request                |4.2.3.5 | |x| | | |
--------------------------------------------------|--------|-|-|-|-|-|--
--------------------------------------------------|--------|-|-|-|-|-|--
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 47]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-5.  ELECTRONIC MAIL -- SMTP and RFC-822
-
-   5.1  INTRODUCTION
-
-      In the TCP/IP protocol suite, electronic mail in a format
-      specified in RFC-822 [SMTP:2] is transmitted using the Simple Mail
-      Transfer Protocol (SMTP) defined in RFC-821 [SMTP:1].
-
-      While SMTP has remained unchanged over the years, the Internet
-      community has made several changes in the way SMTP is used.  In
-      particular, the conversion to the Domain Name System (DNS) has
-      caused changes in address formats and in mail routing.  In this
-      section, we assume familiarity with the concepts and terminology
-      of the DNS, whose requirements are given in Section 6.1.
-
-      RFC-822 specifies the Internet standard format for electronic mail
-      messages.  RFC-822 supercedes an older standard, RFC-733, that may
-      still be in use in a few places, although it is obsolete.  The two
-      formats are sometimes referred to simply by number ("822" and
-      "733").
-
-      RFC-822 is used in some non-Internet mail environments with
-      different mail transfer protocols than SMTP, and SMTP has also
-      been adapted for use in some non-Internet environments.  Note that
-      this document presents the rules for the use of SMTP and RFC-822
-      for the Internet environment only; other mail environments that
-      use these protocols may be expected to have their own rules.
-
-   5.2  PROTOCOL WALK-THROUGH
-
-      This section covers both RFC-821 and RFC-822.
-
-      The SMTP specification in RFC-821 is clear and contains numerous
-      examples, so implementors should not find it difficult to
-      understand.  This section simply updates or annotates portions of
-      RFC-821 to conform with current usage.
-
-      RFC-822 is a long and dense document, defining a rich syntax.
-      Unfortunately, incomplete or defective implementations of RFC-822
-      are common.  In fact, nearly all of the many formats of RFC-822
-      are actually used, so an implementation generally needs to
-      recognize and correctly interpret all of the RFC-822 syntax.
-
-      5.2.1  The SMTP Model: RFC-821 Section 2
-
-         DISCUSSION:
-              Mail is sent by a series of request/response transactions
-              between a client, the "sender-SMTP," and a server, the
-
-
-
-Internet Engineering Task Force                                [Page 48]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-              "receiver-SMTP".  These transactions pass (1) the message
-              proper, which is composed of header and body, and (2) SMTP
-              source and destination addresses, referred to as the
-              "envelope".
-
-              The SMTP programs are analogous to Message Transfer Agents
-              (MTAs) of X.400.  There will be another level of protocol
-              software, closer to the end user, that is responsible for
-              composing and analyzing RFC-822 message headers; this
-              component is known as the "User Agent" in X.400, and we
-              use that term in this document.  There is a clear logical
-              distinction between the User Agent and the SMTP
-              implementation, since they operate on different levels of
-              protocol.  Note, however, that this distinction is may not
-              be exactly reflected the structure of typical
-              implementations of Internet mail.  Often there is a
-              program known as the "mailer" that implements SMTP and
-              also some of the User Agent functions; the rest of the
-              User Agent functions are included in a user interface used
-              for entering and reading mail.
-
-              The SMTP envelope is constructed at the originating site,
-              typically by the User Agent when the message is first
-              queued for the Sender-SMTP program.  The envelope
-              addresses may be derived from information in the message
-              header, supplied by the user interface (e.g., to implement
-              a bcc: request), or derived from local configuration
-              information (e.g., expansion of a mailing list).  The SMTP
-              envelope cannot in general be re-derived from the header
-              at a later stage in message delivery, so the envelope is
-              transmitted separately from the message itself using the
-              MAIL and RCPT commands of SMTP.
-
-              The text of RFC-821 suggests that mail is to be delivered
-              to an individual user at a host.  With the advent of the
-              domain system and of mail routing using mail-exchange (MX)
-              resource records, implementors should now think of
-              delivering mail to a user at a domain, which may or may
-              not be a particular host.  This DOES NOT change the fact
-              that SMTP is a host-to-host mail exchange protocol.
-
-      5.2.2  Canonicalization: RFC-821 Section 3.1
-
-         The domain names that a Sender-SMTP sends in MAIL and RCPT
-         commands MUST have been  "canonicalized," i.e., they must be
-         fully-qualified principal names or domain literals, not
-         nicknames or domain abbreviations.  A canonicalized name either
-         identifies a host directly or is an MX name; it cannot be a
-
-
-
-Internet Engineering Task Force                                [Page 49]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-         CNAME.
-
-      5.2.3  VRFY and EXPN Commands: RFC-821 Section 3.3
-
-         A receiver-SMTP MUST implement VRFY and SHOULD implement EXPN
-         (this requirement overrides RFC-821).  However, there MAY be
-         configuration information to disable VRFY and EXPN in a
-         particular installation; this might even allow EXPN to be
-         disabled for selected lists.
-
-         A new reply code is defined for the VRFY command:
-
-              252 Cannot VRFY user (e.g., info is not local), but will
-                  take message for this user and attempt delivery.
-
-         DISCUSSION:
-              SMTP users and administrators make regular use of these
-              commands for diagnosing mail delivery problems.  With the
-              increasing use of multi-level mailing list expansion
-              (sometimes more than two levels), EXPN has been
-              increasingly important for diagnosing inadvertent mail
-              loops.  On the other hand,  some feel that EXPN represents
-              a significant privacy, and perhaps even a security,
-              exposure.
-
-      5.2.4  SEND, SOML, and SAML Commands: RFC-821 Section 3.4
-
-         An SMTP MAY implement the commands to send a message to a
-         user's terminal: SEND, SOML, and SAML.
-
-         DISCUSSION:
-              It has been suggested that the use of mail relaying
-              through an MX record is inconsistent with the intent of
-              SEND to deliver a message immediately and directly to a
-              user's terminal.  However, an SMTP receiver that is unable
-              to write directly to the user terminal can return a "251
-              User Not Local" reply to the RCPT following a SEND, to
-              inform the originator of possibly deferred delivery.
-
-      5.2.5  HELO Command: RFC-821 Section 3.5
-
-         The sender-SMTP MUST ensure that the <domain> parameter in a
-         HELO command is a valid principal host domain name for the
-         client host.  As a result, the receiver-SMTP will not have to
-         perform MX resolution on this name in order to validate the
-         HELO parameter.
-
-         The HELO receiver MAY verify that the HELO parameter really
-
-
-
-Internet Engineering Task Force                                [Page 50]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-         corresponds to the IP address of the sender.  However, the
-         receiver MUST NOT refuse to accept a message, even if the
-         sender's HELO command fails verification.
-
-         DISCUSSION:
-              Verifying the HELO parameter requires a domain name lookup
-              and may therefore take considerable time.  An alternative
-              tool for tracking bogus mail sources is suggested below
-              (see "DATA Command").
-
-              Note also that the HELO argument is still required to have
-              valid <domain> syntax, since it will appear in a Received:
-              line; otherwise, a 501 error is to be sent.
-
-         IMPLEMENTATION:
-              When HELO parameter validation fails, a suggested
-              procedure is to insert a note about the unknown
-              authenticity of the sender into the message header (e.g.,
-              in the "Received:"  line).
-
-      5.2.6  Mail Relay: RFC-821 Section 3.6
-
-         We distinguish three types of mail (store-and-) forwarding:
-
-         (1)  A simple forwarder or "mail exchanger" forwards a message
-              using private knowledge about the recipient; see section
-              3.2 of RFC-821.
-
-         (2)  An SMTP mail "relay" forwards a message within an SMTP
-              mail environment as the result of an explicit source route
-              (as defined in section 3.6 of RFC-821).  The SMTP relay
-              function uses the "@...:" form of source route from RFC-
-              822 (see Section 5.2.19 below).
-
-         (3)  A mail "gateway" passes a message between different
-              environments.  The rules for mail gateways are discussed
-              below in Section 5.3.7.
-
-         An Internet host that is forwarding a message but is not a
-         gateway to a different mail environment (i.e., it falls under
-         (1) or (2)) SHOULD NOT alter any existing header fields,
-         although the host will add an appropriate Received: line as
-         required in Section 5.2.8.
-
-         A Sender-SMTP SHOULD NOT send a RCPT TO: command containing an
-         explicit source route using the "@...:" address form.  Thus,
-         the relay function defined in section  3.6 of RFC-821 should
-         not be used.
-
-
-
-Internet Engineering Task Force                                [Page 51]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-         DISCUSSION:
-              The intent is to discourage all source routing and to
-              abolish explicit source routing for mail delivery within
-              the Internet environment.  Source-routing is unnecessary;
-              the simple target address "user@domain" should always
-              suffice.  This is the result of an explicit architectural
-              decision to use universal naming rather than source
-              routing for mail.  Thus, SMTP provides end-to-end
-              connectivity, and the DNS provides globally-unique,
-              location-independent names.  MX records handle the major
-              case where source routing might otherwise be needed.
-
-         A receiver-SMTP MUST accept the explicit source route syntax in
-         the envelope, but it MAY implement the relay function as
-         defined in section 3.6 of RFC-821.  If it does not implement
-         the relay function, it SHOULD attempt to deliver the message
-         directly to the host to the right of the right-most "@" sign.
-
-         DISCUSSION:
-              For example, suppose a host that does not implement the
-              relay function receives a message with the SMTP command:
-              "RCPT TO:<@ALPHA,@BETA:joe@GAMMA>", where ALPHA, BETA, and
-              GAMMA represent domain names.  Rather than immediately
-              refusing the message with a 550 error reply as suggested
-              on page 20 of RFC-821, the host should try to forward the
-              message to GAMMA directly, using: "RCPT TO:<joe@GAMMA>".
-              Since this host does not support relaying, it is not
-              required to update the reverse path.
-
-              Some have suggested that source routing may be needed
-              occasionally for manually routing mail around failures;
-              however, the reality and importance of this need is
-              controversial.  The use of explicit SMTP mail relaying for
-              this purpose is discouraged, and in fact it may not be
-              successful, as many host systems do not support it.  Some
-              have used the "%-hack" (see Section 5.2.16) for this
-              purpose.
-
-      5.2.7  RCPT Command: RFC-821 Section 4.1.1
-
-         A host that supports a receiver-SMTP MUST support the reserved
-         mailbox "Postmaster".
-
-         The receiver-SMTP MAY verify RCPT parameters as they arrive;
-         however, RCPT responses MUST NOT be delayed beyond a reasonable
-         time (see Section 5.3.2).
-
-         Therefore, a "250 OK" response to a RCPT does not necessarily
-
-
-
-Internet Engineering Task Force                                [Page 52]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-         imply that the delivery address(es) are valid.  Errors found
-         after message acceptance will be reported by mailing a
-         notification message to an appropriate address (see Section
-         5.3.3).
-
-         DISCUSSION:
-              The set of conditions under which a RCPT parameter can be
-              validated immediately is an engineering design choice.
-              Reporting destination mailbox errors to the Sender-SMTP
-              before mail is transferred is generally desirable to save
-              time and network bandwidth, but this advantage is lost if
-              RCPT verification is lengthy.
-
-              For example, the receiver can verify immediately any
-              simple local reference, such as a single locally-
-              registered mailbox.  On the other hand, the "reasonable
-              time" limitation generally implies deferring verification
-              of a mailing list until after the message has been
-              transferred and accepted, since verifying a large mailing
-              list can take a very long time.  An implementation might
-              or might not choose to defer validation of addresses that
-              are non-local and therefore require a DNS lookup.  If a
-              DNS lookup is performed but a soft domain system error
-              (e.g., timeout) occurs, validity must be assumed.
-
-      5.2.8  DATA Command: RFC-821 Section 4.1.1
-
-         Every receiver-SMTP (not just one that "accepts a message for
-         relaying or for final delivery" [SMTP:1]) MUST insert a
-         "Received:" line at the beginning of a message.  In this line,
-         called a "time stamp line" in RFC-821:
-
-         *    The FROM field SHOULD contain both (1) the name of the
-              source host as presented in the HELO command and (2) a
-              domain literal containing the IP address of the source,
-              determined from the TCP connection.
-
-         *    The ID field MAY contain an "@" as suggested in RFC-822,
-              but this is not required.
-
-         *    The FOR field MAY contain a list of <path> entries when
-              multiple RCPT commands have been given.
-
-
-         An Internet mail program MUST NOT change a Received: line that
-         was previously added to the message header.
-
-
-
-
-
-Internet Engineering Task Force                                [Page 53]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-         DISCUSSION:
-              Including both the source host and the IP source address
-              in the Received: line may provide enough information for
-              tracking illicit mail sources and eliminate a need to
-              explicitly verify the HELO parameter.
-
-              Received: lines are primarily intended for humans tracing
-              mail routes, primarily of diagnosis of faults.  See also
-              the discussion under 5.3.7.
-
-         When the receiver-SMTP makes "final delivery" of a message,
-         then it MUST pass the MAIL FROM: address from the SMTP envelope
-         with the message, for use if an error notification message must
-         be sent later (see Section 5.3.3).  There is an analogous
-         requirement when gatewaying from the Internet into a different
-         mail environment; see Section 5.3.7.
-
-         DISCUSSION:
-              Note that the final reply to the DATA command depends only
-              upon the successful transfer and storage of the message.
-              Any problem with the destination address(es) must either
-              (1) have been reported in an SMTP error reply to the RCPT
-              command(s), or (2) be reported in a later error message
-              mailed to the originator.
-
-         IMPLEMENTATION:
-              The MAIL FROM: information may be passed as a parameter or
-              in a Return-Path: line inserted at the beginning of the
-              message.
-
-      5.2.9  Command Syntax: RFC-821 Section 4.1.2
-
-         The syntax shown in RFC-821 for the MAIL FROM: command omits
-         the case of an empty path:  "MAIL FROM: <>" (see RFC-821 Page
-         15).  An empty reverse path MUST be supported.
-
-      5.2.10  SMTP Replies:  RFC-821 Section 4.2
-
-         A receiver-SMTP SHOULD send only the reply codes listed in
-         section 4.2.2 of RFC-821 or in this document.  A receiver-SMTP
-         SHOULD use the text shown in examples in RFC-821 whenever
-         appropriate.
-
-         A sender-SMTP MUST determine its actions only by the reply
-         code, not by the text (except for 251 and 551 replies); any
-         text, including no text at all, must be acceptable.  The space
-         (blank) following the reply code is considered part of the
-         text.  Whenever possible, a sender-SMTP SHOULD test only the
-
-
-
-Internet Engineering Task Force                                [Page 54]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-         first digit of the reply code, as specified in Appendix E of
-         RFC-821.
-
-         DISCUSSION:
-              Interoperability problems have arisen with SMTP systems
-              using reply codes that are not listed explicitly in RFC-
-              821 Section 4.3 but are legal according to the theory of
-              reply codes explained in Appendix E.
-
-      5.2.11  Transparency: RFC-821 Section 4.5.2
-
-         Implementors MUST be sure that their mail systems always add
-         and delete periods to ensure message transparency.
-
-      5.2.12  WKS Use in MX Processing: RFC-974, p. 5
-
-         RFC-974 [SMTP:3] recommended that the domain system be queried
-         for WKS ("Well-Known Service") records, to verify that each
-         proposed mail target does support SMTP.  Later experience has
-         shown that WKS is not widely supported, so the WKS step in MX
-         processing SHOULD NOT be used.
-
-      The following are notes on RFC-822, organized by section of that
-      document.
-
-      5.2.13  RFC-822 Message Specification: RFC-822 Section 4
-
-         The syntax shown for the Return-path line omits the possibility
-         of a null return path, which is used to prevent looping of
-         error notifications (see Section 5.3.3).  The complete syntax
-         is:
-
-             return = "Return-path"  ":" route-addr
-                    / "Return-path"  ":" "<" ">"
-
-         The set of optional header fields is hereby expanded to include
-         the Content-Type field defined in RFC-1049 [SMTP:7].  This
-         field "allows mail reading systems to automatically identify
-         the type of a structured message body and to process it for
-         display accordingly".  [SMTP:7]  A User Agent MAY support this
-         field.
-
-      5.2.14  RFC-822 Date and Time Specification: RFC-822 Section 5
-
-         The syntax for the date is hereby changed to:
-
-            date = 1*2DIGIT month 2*4DIGIT
-
-
-
-
-Internet Engineering Task Force                                [Page 55]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-         All mail software SHOULD use 4-digit years in dates, to ease
-         the transition to the next century.
-
-         There is a strong trend towards the use of numeric timezone
-         indicators, and implementations SHOULD use numeric timezones
-         instead of timezone names.  However, all implementations MUST
-         accept either notation.  If timezone names are used, they MUST
-         be exactly as defined in RFC-822.
-
-         The military time zones are specified incorrectly in RFC-822:
-         they count the wrong way from UT (the signs are reversed).  As
-         a result, military time zones in RFC-822 headers carry no
-         information.
-
-         Finally, note that there is a typo in the definition of "zone"
-         in the syntax summary of appendix D; the correct definition
-         occurs in Section 3 of RFC-822.
-
-      5.2.15  RFC-822 Syntax Change: RFC-822 Section 6.1
-
-         The syntactic definition of "mailbox" in RFC-822 is hereby
-         changed to:
-
-            mailbox =  addr-spec            ; simple address
-                    / [phrase] route-addr   ; name & addr-spec
-
-         That is, the phrase preceding a route address is now OPTIONAL.
-         This change makes the following header field legal, for
-         example:
-
-             From: <craig@nnsc.nsf.net>
-
-      5.2.16  RFC-822  Local-part: RFC-822 Section 6.2
-
-         The basic mailbox address specification has the form: "local-
-         part@domain".  Here "local-part", sometimes called the "left-
-         hand side" of the address, is domain-dependent.
-
-         A host that is forwarding the message but is not the
-         destination host implied by the right-hand side "domain" MUST
-         NOT interpret or modify the "local-part" of the address.
-
-         When mail is to be gatewayed from the Internet mail environment
-         into a foreign mail environment (see Section 5.3.7), routing
-         information for that foreign environment MAY be embedded within
-         the "local-part" of the address.  The gateway will then
-         interpret this local part appropriately for the foreign mail
-         environment.
-
-
-
-Internet Engineering Task Force                                [Page 56]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-         DISCUSSION:
-              Although source routes are discouraged within the Internet
-              (see Section 5.2.6), there are non-Internet mail
-              environments whose delivery mechanisms do depend upon
-              source routes.  Source routes for extra-Internet
-              environments can generally be buried in the "local-part"
-              of the address (see Section 5.2.16) while mail traverses
-              the Internet.  When the mail reaches the appropriate
-              Internet mail gateway, the gateway will interpret the
-              local-part and build the necessary address or route for
-              the target mail environment.
-
-              For example, an Internet host might send mail to:
-              "a!b!c!user@gateway-domain".  The complex local part
-              "a!b!c!user" would be uninterpreted within the Internet
-              domain, but could be parsed and understood by the
-              specified mail gateway.
-
-              An embedded source route is sometimes encoded in the
-              "local-part" using "%" as a right-binding routing
-              operator.  For example, in:
-
-                 user%domain%relay3%relay2@relay1
-
-              the "%" convention implies that the mail is to be routed
-              from "relay1" through "relay2", "relay3", and finally to
-              "user" at "domain".  This is commonly known as the "%-
-              hack".  It is suggested that "%" have lower precedence
-              than any other routing operator (e.g., "!") hidden in the
-              local-part; for example, "a!b%c" would be interpreted as
-              "(a!b)%c".
-
-              Only the target host (in this case, "relay1") is permitted
-              to analyze the local-part "user%domain%relay3%relay2".
-
-      5.2.17  Domain Literals: RFC-822 Section 6.2.3
-
-         A mailer MUST be able to accept and parse an Internet domain
-         literal whose content ("dtext"; see RFC-822) is a dotted-
-         decimal host address.  This satisfies the requirement of
-         Section 2.1 for the case of mail.
-
-         An SMTP MUST accept and recognize a domain literal for any of
-         its own IP addresses.
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 57]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-      5.2.18  Common Address Formatting Errors: RFC-822 Section 6.1
-
-         Errors in formatting or parsing 822 addresses are unfortunately
-         common.  This section mentions only the most common errors.  A
-         User Agent MUST accept all valid RFC-822 address formats, and
-         MUST NOT generate illegal address syntax.
-
-         o    A common error is to leave out the semicolon after a group
-              identifier.
-
-         o    Some systems fail to fully-qualify domain names in
-              messages they generate.  The right-hand side of an "@"
-              sign in a header address field MUST be a fully-qualified
-              domain name.
-
-              For example, some systems fail to fully-qualify the From:
-              address; this prevents a "reply" command in the user
-              interface from automatically constructing a return
-              address.
-
-              DISCUSSION:
-                   Although RFC-822 allows the local use of abbreviated
-                   domain names within a domain, the application of
-                   RFC-822 in Internet mail does not allow this.  The
-                   intent is that an Internet host must not send an SMTP
-                   message header containing an abbreviated domain name
-                   in an address field.  This allows the address fields
-                   of the header to be passed without alteration across
-                   the Internet, as required in Section 5.2.6.
-
-         o    Some systems mis-parse multiple-hop explicit source routes
-              such as:
-
-                  @relay1,@relay2,@relay3:user@domain.
-
-
-         o    Some systems over-qualify domain names by adding a
-              trailing dot to some or all domain names in addresses or
-              message-ids.  This violates RFC-822 syntax.
-
-
-      5.2.19  Explicit Source Routes: RFC-822 Section 6.2.7
-
-         Internet host software SHOULD NOT create an RFC-822 header
-         containing an address with an explicit source route, but MUST
-         accept such headers for compatibility with earlier systems.
-
-         DISCUSSION:
-
-
-
-Internet Engineering Task Force                                [Page 58]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-              In an understatement, RFC-822 says "The use of explicit
-              source routing is discouraged".  Many hosts implemented
-              RFC-822 source routes incorrectly, so the syntax cannot be
-              used unambiguously in practice.  Many users feel the
-              syntax is ugly.  Explicit source routes are not needed in
-              the mail envelope for delivery; see Section 5.2.6.  For
-              all these reasons, explicit source routes using the RFC-
-              822 notations are not to be used in Internet mail headers.
-
-              As stated in Section 5.2.16, it is necessary to allow an
-              explicit source route to be buried in the local-part of an
-              address, e.g., using the "%-hack", in order to allow mail
-              to be gatewayed into another environment in which explicit
-              source routing is necessary.  The vigilant will observe
-              that there is no way for a User Agent to detect and
-              prevent the use of such implicit source routing when the
-              destination is within the Internet.  We can only
-              discourage source routing of any kind within the Internet,
-              as unnecessary and undesirable.
-
-   5.3  SPECIFIC ISSUES
-
-      5.3.1  SMTP Queueing Strategies
-
-         The common structure of a host SMTP implementation includes
-         user mailboxes, one or more areas for queueing messages in
-         transit, and one or more daemon processes for sending and
-         receiving mail.  The exact structure will vary depending on the
-         needs of the users on the host and the number and size of
-         mailing lists supported by the host.  We describe several
-         optimizations that have proved helpful, particularly for
-         mailers supporting high traffic levels.
-
-         Any queueing strategy MUST include:
-
-         o    Timeouts on all activities.  See Section 5.3.2.
-
-         o    Never sending error messages in response to error
-              messages.
-
-
-         5.3.1.1 Sending Strategy
-
-            The general model of a sender-SMTP is one or more processes
-            that periodically attempt to transmit outgoing mail.  In a
-            typical system, the program that composes a message has some
-            method for requesting immediate attention for a new piece of
-            outgoing mail, while mail that cannot be transmitted
-
-
-
-Internet Engineering Task Force                                [Page 59]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-            immediately MUST be queued and periodically retried by the
-            sender.  A mail queue entry will include not only the
-            message itself but also the envelope information.
-
-            The sender MUST delay retrying a particular destination
-            after one attempt has failed.  In general, the retry
-            interval SHOULD be at least 30 minutes; however, more
-            sophisticated and variable strategies will be beneficial
-            when the sender-SMTP can determine the reason for non-
-            delivery.
-
-            Retries continue until the message is transmitted or the
-            sender gives up; the give-up time generally needs to be at
-            least 4-5 days.  The parameters to the retry algorithm MUST
-            be configurable.
-
-            A sender SHOULD keep a list of hosts it cannot reach and
-            corresponding timeouts, rather than just retrying queued
-            mail items.
-
-            DISCUSSION:
-                 Experience suggests that failures are typically
-                 transient (the target system has crashed), favoring a
-                 policy of two connection attempts in the first hour the
-                 message is in the queue, and then backing off to once
-                 every two or three hours.
-
-                 The sender-SMTP can shorten the queueing delay by
-                 cooperation with the receiver-SMTP.  In particular, if
-                 mail is received from a particular address, it is good
-                 evidence that any mail queued for that host can now be
-                 sent.
-
-                 The strategy may be further modified as a result of
-                 multiple addresses per host (see Section 5.3.4), to
-                 optimize delivery time vs. resource usage.
-
-                 A sender-SMTP may have a large queue of messages for
-                 each unavailable destination host, and if it retried
-                 all these messages in every retry cycle, there would be
-                 excessive Internet overhead and the daemon would be
-                 blocked for a long period.  Note that an SMTP can
-                 generally determine that a delivery attempt has failed
-                 only after a timeout of a minute or more; a one minute
-                 timeout per connection will result in a very large
-                 delay if it is repeated for dozens or even hundreds of
-                 queued messages.
-
-
-
-
-Internet Engineering Task Force                                [Page 60]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-            When the same message is to be delivered to several users on
-            the same host, only one copy of the message SHOULD be
-            transmitted.  That is, the sender-SMTP should use the
-            command sequence: RCPT, RCPT,... RCPT, DATA instead of the
-            sequence: RCPT, DATA, RCPT, DATA,... RCPT, DATA.
-            Implementation of this efficiency feature is strongly urged.
-
-            Similarly, the sender-SMTP MAY support multiple concurrent
-            outgoing mail transactions to achieve timely delivery.
-            However, some limit SHOULD be imposed to protect the host
-            from devoting all its resources to mail.
-
-            The use of the different addresses of a multihomed host is
-            discussed below.
-
-         5.3.1.2  Receiving strategy
-
-            The receiver-SMTP SHOULD attempt to keep a pending listen on
-            the SMTP port at all times.  This will require the support
-            of multiple incoming TCP connections for SMTP.  Some limit
-            MAY be imposed.
-
-            IMPLEMENTATION:
-                 When the receiver-SMTP receives mail from a particular
-                 host address, it could notify the sender-SMTP to retry
-                 any mail pending for that host address.
-
-      5.3.2  Timeouts in SMTP
-
-         There are two approaches to timeouts in the sender-SMTP:  (a)
-         limit the time for each SMTP command separately, or (b) limit
-         the time for the entire SMTP dialogue for a single mail
-         message.  A sender-SMTP SHOULD use option (a), per-command
-         timeouts.  Timeouts SHOULD be easily reconfigurable, preferably
-         without recompiling the SMTP code.
-
-         DISCUSSION:
-              Timeouts are an essential feature of an SMTP
-              implementation.  If the timeouts are too long (or worse,
-              there are no timeouts), Internet communication failures or
-              software bugs in receiver-SMTP programs can tie up SMTP
-              processes indefinitely.  If the timeouts are too short,
-              resources will be wasted with attempts that time out part
-              way through message delivery.
-
-              If option (b) is used, the timeout has to be very large,
-              e.g., an hour, to allow time to expand very large mailing
-              lists.  The timeout may also need to increase linearly
-
-
-
-Internet Engineering Task Force                                [Page 61]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-              with the size of the message, to account for the time to
-              transmit a very large message.  A large fixed timeout
-              leads to two problems:  a failure can still tie up the
-              sender for a very long time, and very large messages may
-              still spuriously time out (which is a wasteful failure!).
-
-              Using the recommended option (a), a timer is set for each
-              SMTP command and for each buffer of the data transfer.
-              The latter means that the overall timeout is inherently
-              proportional to the size of the message.
-
-         Based on extensive experience with busy mail-relay hosts, the
-         minimum per-command timeout values SHOULD be as follows:
-
-         o    Initial 220 Message: 5 minutes
-
-              A Sender-SMTP process needs to distinguish between a
-              failed TCP connection and a delay in receiving the initial
-              220 greeting message.  Many receiver-SMTPs will accept a
-              TCP connection but delay delivery of the 220 message until
-              their system load will permit more mail to be processed.
-
-         o    MAIL Command: 5 minutes
-
-
-         o    RCPT Command: 5 minutes
-
-              A longer timeout would be required if processing of
-              mailing lists and aliases were not deferred until after
-              the message was accepted.
-
-         o    DATA Initiation: 2 minutes
-
-              This is while awaiting the "354 Start Input" reply to a
-              DATA command.
-
-         o    Data Block: 3 minutes
-
-              This is while awaiting the completion of each TCP SEND
-              call transmitting a chunk of data.
-
-         o    DATA Termination: 10 minutes.
-
-              This is while awaiting the "250 OK" reply. When the
-              receiver gets the final period terminating the message
-              data, it typically performs processing to deliver the
-              message to a user mailbox.  A spurious timeout at this
-              point would be very wasteful, since the message has been
-
-
-
-Internet Engineering Task Force                                [Page 62]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-              successfully sent.
-
-         A receiver-SMTP SHOULD have a timeout of at least 5 minutes
-         while it is awaiting the next command from the sender.
-
-      5.3.3  Reliable Mail Receipt
-
-         When the receiver-SMTP accepts a piece of mail (by sending a
-         "250 OK" message in response to DATA), it is accepting
-         responsibility for delivering or relaying the message.  It must
-         take this responsibility seriously, i.e., it MUST NOT lose the
-         message for frivolous reasons, e.g., because the host later
-         crashes or because of a predictable resource shortage.
-
-         If there is a delivery failure after acceptance of a message,
-         the receiver-SMTP MUST formulate and mail a notification
-         message.  This notification MUST be sent using a null ("<>")
-         reverse path in the envelope; see Section 3.6 of RFC-821.  The
-         recipient of this notification SHOULD be the address from the
-         envelope return path (or the Return-Path: line).  However, if
-         this address is null ("<>"),  the receiver-SMTP MUST NOT send a
-         notification.  If the address is an explicit source route, it
-         SHOULD be stripped down to its final hop.
-
-         DISCUSSION:
-              For example, suppose that an error notification must be
-              sent for a message that arrived with:
-              "MAIL FROM:<@a,@b:user@d>".  The notification message
-              should be sent to: "RCPT TO:<user@d>".
-
-              Some delivery failures after the message is accepted by
-              SMTP will be unavoidable.  For example, it may be
-              impossible for the receiver-SMTP to validate all the
-              delivery addresses in RCPT command(s) due to a "soft"
-              domain system error or because the target is a mailing
-              list (see earlier discussion of RCPT).
-
-         To avoid receiving duplicate messages as the result of
-         timeouts, a receiver-SMTP MUST seek to minimize the time
-         required to respond to the final "." that ends a message
-         transfer.  See RFC-1047 [SMTP:4] for a discussion of this
-         problem.
-
-      5.3.4  Reliable Mail Transmission
-
-         To transmit a message, a sender-SMTP determines the IP address
-         of the target host from the destination address in the
-         envelope.  Specifically, it maps the string to the right of the
-
-
-
-Internet Engineering Task Force                                [Page 63]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-         "@" sign into an IP address.  This mapping or the transfer
-         itself may fail with a soft error, in which case the sender-
-         SMTP will requeue the outgoing mail for a later retry, as
-         required in Section 5.3.1.1.
-
-         When it succeeds, the mapping can result in a list of
-         alternative delivery addresses rather than a single address,
-         because of (a) multiple MX records, (b) multihoming, or both.
-         To provide reliable mail transmission, the sender-SMTP MUST be
-         able to try (and retry) each of the addresses in this list in
-         order, until a delivery attempt succeeds.  However, there MAY
-         also be a configurable limit on the number of alternate
-         addresses that can be tried.  In any case, a host SHOULD try at
-         least two addresses.
-
-         The following information is to be used to rank the host
-         addresses:
-
-         (1)  Multiple MX Records -- these contain a preference
-              indication that should be used in sorting.  If there are
-              multiple destinations with the same preference and there
-              is no clear reason to favor one (e.g., by address
-              preference), then the sender-SMTP SHOULD pick one at
-              random to spread the load across multiple mail exchanges
-              for a specific organization; note that this is a
-              refinement of the procedure in [DNS:3].
-
-         (2)  Multihomed host -- The destination host (perhaps taken
-              from the preferred MX record) may be multihomed, in which
-              case the domain name resolver will return a list of
-              alternative IP addresses.  It is the responsibility of the
-              domain name resolver interface (see Section 6.1.3.4 below)
-              to have ordered this list by decreasing preference, and
-              SMTP MUST try them in the order presented.
-
-         DISCUSSION:
-              Although the capability to try multiple alternative
-              addresses is required, there may be circumstances where
-              specific installations want to limit or disable the use of
-              alternative addresses.  The question of whether a sender
-              should attempt retries using the different addresses of a
-              multihomed host has been controversial.  The main argument
-              for using the multiple addresses is that it maximizes the
-              probability of timely delivery, and indeed sometimes the
-              probability of any delivery; the counter argument is that
-              it may result in unnecessary resource use.
-
-              Note that resource use is also strongly determined by the
-
-
-
-Internet Engineering Task Force                                [Page 64]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-              sending strategy discussed in Section 5.3.1.
-
-      5.3.5  Domain Name Support
-
-         SMTP implementations MUST use the mechanism defined in Section
-         6.1 for mapping between domain names and IP addresses.  This
-         means that every Internet SMTP MUST include support for the
-         Internet DNS.
-
-         In particular, a sender-SMTP MUST support the MX record scheme
-         [SMTP:3].  See also Section 7.4 of [DNS:2] for information on
-         domain name support for SMTP.
-
-      5.3.6  Mailing Lists and Aliases
-
-         An SMTP-capable host SHOULD support both the alias and the list
-         form of address expansion for multiple delivery.  When a
-         message is delivered or forwarded to each address of an
-         expanded list form, the return address in the envelope
-         ("MAIL FROM:") MUST be changed to be the address of a person
-         who administers the list, but the message header MUST be left
-         unchanged; in particular, the "From" field of the message is
-         unaffected.
-
-         DISCUSSION:
-              An important mail facility is a mechanism for multi-
-              destination delivery of a single message, by transforming
-              or "expanding" a pseudo-mailbox address into a list of
-              destination mailbox addresses.  When a message is sent to
-              such a pseudo-mailbox (sometimes called an "exploder"),
-              copies are forwarded or redistributed to each mailbox in
-              the expanded list.  We classify such a pseudo-mailbox as
-              an "alias" or a "list", depending upon the expansion
-              rules:
-
-              (a)  Alias
-
-                   To expand an alias, the recipient mailer simply
-                   replaces the pseudo-mailbox address in the envelope
-                   with each of the expanded addresses in turn; the rest
-                   of the envelope and the message body are left
-                   unchanged.  The message is then delivered or
-                   forwarded to each expanded address.
-
-              (b)  List
-
-                   A mailing list may be said to operate by
-                   "redistribution" rather than by "forwarding".  To
-
-
-
-Internet Engineering Task Force                                [Page 65]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-                   expand a list, the recipient mailer replaces the
-                   pseudo-mailbox address in the envelope with each of
-                   the expanded addresses in turn. The return address in
-                   the envelope is changed so that all error messages
-                   generated by the final deliveries will be returned to
-                   a list administrator, not to the message originator,
-                   who generally has no control over the contents of the
-                   list and will typically find error messages annoying.
-
-
-      5.3.7  Mail Gatewaying
-
-         Gatewaying mail between different mail environments, i.e.,
-         different mail formats and protocols, is complex and does not
-         easily yield to standardization.  See for example [SMTP:5a],
-         [SMTP:5b].  However, some general requirements may be given for
-         a gateway between the Internet and another mail environment.
-
-         (A)  Header fields MAY be rewritten when necessary as messages
-              are gatewayed across mail environment boundaries.
-
-              DISCUSSION:
-                   This may involve interpreting the local-part of the
-                   destination address, as suggested in Section 5.2.16.
-
-                   The other mail systems gatewayed to the Internet
-                   generally use a subset of RFC-822 headers, but some
-                   of them do not have an equivalent to the SMTP
-                   envelope.  Therefore, when a message leaves the
-                   Internet environment, it may be necessary to fold the
-                   SMTP envelope information into the message header.  A
-                   possible solution would be to create new header
-                   fields to carry the envelope information (e.g., "X-
-                   SMTP-MAIL:" and "X-SMTP-RCPT:"); however, this would
-                   require changes in mail programs in the foreign
-                   environment.
-
-         (B)  When forwarding a message into or out of the Internet
-              environment, a gateway MUST prepend a Received: line, but
-              it MUST NOT alter in any way a Received: line that is
-              already in the header.
-
-              DISCUSSION:
-                   This requirement is a subset of the general
-                   "Received:" line requirement of Section 5.2.8; it is
-                   restated here for emphasis.
-
-                   Received: fields of messages originating from other
-
-
-
-Internet Engineering Task Force                                [Page 66]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-                   environments may not conform exactly to RFC822.
-                   However, the most important use of Received: lines is
-                   for debugging mail faults, and this debugging can be
-                   severely hampered by well-meaning gateways that try
-                   to "fix" a Received: line.
-
-                   The gateway is strongly encouraged to indicate the
-                   environment and protocol in the "via" clauses of
-                   Received field(s) that it supplies.
-
-         (C)  From the Internet side, the gateway SHOULD accept all
-              valid address formats in SMTP commands and in RFC-822
-              headers, and all valid RFC-822 messages.  Although a
-              gateway must accept an RFC-822 explicit source route
-              ("@...:" format) in either the RFC-822 header or in the
-              envelope, it MAY or may not act on the source route; see
-              Sections 5.2.6 and 5.2.19.
-
-              DISCUSSION:
-                   It is often tempting to restrict the range of
-                   addresses accepted at the mail gateway to simplify
-                   the translation into addresses for the remote
-                   environment.  This practice is based on the
-                   assumption that mail users have control over the
-                   addresses their mailers send to the mail gateway.  In
-                   practice, however, users have little control over the
-                   addresses that are finally sent; their mailers are
-                   free to change addresses into any legal RFC-822
-                   format.
-
-         (D)  The gateway MUST ensure that all header fields of a
-              message that it forwards into the Internet meet the
-              requirements for Internet mail.  In particular, all
-              addresses in "From:", "To:", "Cc:", etc., fields must be
-              transformed (if necessary) to satisfy RFC-822 syntax, and
-              they must be effective and useful for sending replies.
-
-
-         (E)  The translation algorithm used to convert mail from the
-              Internet protocols to another environment's protocol
-              SHOULD try to ensure that error messages from the foreign
-              mail environment are delivered to the return path from the
-              SMTP envelope, not to the sender listed in the "From:"
-              field of the RFC-822 message.
-
-              DISCUSSION:
-                   Internet mail lists usually place the address of the
-                   mail list maintainer in the envelope but leave the
-
-
-
-Internet Engineering Task Force                                [Page 67]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-                   original message header intact (with the "From:"
-                   field containing the original sender).  This yields
-                   the behavior the average recipient expects: a reply
-                   to the header gets sent to the original sender, not
-                   to a mail list maintainer; however, errors get sent
-                   to the maintainer (who can fix the problem) and not
-                   the sender (who probably cannot).
-
-         (F)  Similarly, when forwarding a message from another
-              environment into the Internet, the gateway SHOULD set the
-              envelope return path in accordance with an error message
-              return address, if any, supplied by the foreign
-              environment.
-
-
-      5.3.8  Maximum Message Size
-
-         Mailer software MUST be able to send and receive messages of at
-         least 64K bytes in length (including header), and a much larger
-         maximum size is highly desirable.
-
-         DISCUSSION:
-              Although SMTP does not define the maximum size of a
-              message, many systems impose implementation limits.
-
-              The current de facto minimum limit in the Internet is 64K
-              bytes.  However, electronic mail is used for a variety of
-              purposes that create much larger messages.  For example,
-              mail is often used instead of FTP for transmitting ASCII
-              files, and in particular to transmit entire documents.  As
-              a result, messages can be 1 megabyte or even larger.  We
-              note that the present document together with its lower-
-              layer companion contains 0.5 megabytes.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 68]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-   5.4  SMTP REQUIREMENTS SUMMARY
-
-                                               |          | | | |S| |
-                                               |          | | | |H| |F
-                                               |          | | | |O|M|o
-                                               |          | |S| |U|U|o
-                                               |          | |H| |L|S|t
-                                               |          |M|O| |D|T|n
-                                               |          |U|U|M| | |o
-                                               |          |S|L|A|N|N|t
-                                               |          |T|D|Y|O|O|t
-FEATURE                                        |SECTION   | | | |T|T|e
------------------------------------------------|----------|-|-|-|-|-|--
-                                               |          | | | | | |
-RECEIVER-SMTP:                                 |          | | | | | |
-  Implement VRFY                               |5.2.3     |x| | | | |
-  Implement EXPN                               |5.2.3     | |x| | | |
-    EXPN, VRFY configurable                    |5.2.3     | | |x| | |
-  Implement SEND, SOML, SAML                   |5.2.4     | | |x| | |
-  Verify HELO parameter                        |5.2.5     | | |x| | |
-    Refuse message with bad HELO               |5.2.5     | | | | |x|
-  Accept explicit src-route syntax in env.     |5.2.6     |x| | | | |
-  Support "postmaster"                         |5.2.7     |x| | | | |
-  Process RCPT when received (except lists)    |5.2.7     | | |x| | |
-      Long delay of RCPT responses             |5.2.7     | | | | |x|
-                                               |          | | | | | |
-  Add Received: line                           |5.2.8     |x| | | | |
-      Received: line include domain literal    |5.2.8     | |x| | | |
-  Change previous Received: line               |5.2.8     | | | | |x|
-  Pass Return-Path info (final deliv/gwy)      |5.2.8     |x| | | | |
-  Support empty reverse path                   |5.2.9     |x| | | | |
-  Send only official reply codes               |5.2.10    | |x| | | |
-  Send text from RFC-821 when appropriate      |5.2.10    | |x| | | |
-  Delete "." for transparency                  |5.2.11    |x| | | | |
-  Accept and recognize self domain literal(s)  |5.2.17    |x| | | | |
-                                               |          | | | | | |
-  Error message about error message            |5.3.1     | | | | |x|
-  Keep pending listen on SMTP port             |5.3.1.2   | |x| | | |
-  Provide limit on recv concurrency            |5.3.1.2   | | |x| | |
-  Wait at least 5 mins for next sender cmd     |5.3.2     | |x| | | |
-  Avoidable delivery failure after "250 OK"    |5.3.3     | | | | |x|
-  Send error notification msg after accept     |5.3.3     |x| | | | |
-    Send using null return path                |5.3.3     |x| | | | |
-    Send to envelope return path               |5.3.3     | |x| | | |
-    Send to null address                       |5.3.3     | | | | |x|
-    Strip off explicit src route               |5.3.3     | |x| | | |
-  Minimize acceptance delay (RFC-1047)         |5.3.3     |x| | | | |
------------------------------------------------|----------|-|-|-|-|-|--
-
-
-
-Internet Engineering Task Force                                [Page 69]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-                                               |          | | | | | |
-SENDER-SMTP:                                   |          | | | | | |
-  Canonicalized domain names in MAIL, RCPT     |5.2.2     |x| | | | |
-  Implement SEND, SOML, SAML                   |5.2.4     | | |x| | |
-  Send valid principal host name in HELO       |5.2.5     |x| | | | |
-  Send explicit source route in RCPT TO:       |5.2.6     | | | |x| |
-  Use only reply code to determine action      |5.2.10    |x| | | | |
-  Use only high digit of reply code when poss. |5.2.10    | |x| | | |
-  Add "." for transparency                     |5.2.11    |x| | | | |
-                                               |          | | | | | |
-  Retry messages after soft failure            |5.3.1.1   |x| | | | |
-    Delay before retry                         |5.3.1.1   |x| | | | |
-    Configurable retry parameters              |5.3.1.1   |x| | | | |
-    Retry once per each queued dest host       |5.3.1.1   | |x| | | |
-  Multiple RCPT's for same DATA                |5.3.1.1   | |x| | | |
-  Support multiple concurrent transactions     |5.3.1.1   | | |x| | |
-    Provide limit on concurrency               |5.3.1.1   | |x| | | |
-                                               |          | | | | | |
-  Timeouts on all activities                   |5.3.1     |x| | | | |
-    Per-command timeouts                       |5.3.2     | |x| | | |
-    Timeouts easily reconfigurable             |5.3.2     | |x| | | |
-    Recommended times                          |5.3.2     | |x| | | |
-  Try alternate addr's in order                |5.3.4     |x| | | | |
-    Configurable limit on alternate tries      |5.3.4     | | |x| | |
-    Try at least two alternates                |5.3.4     | |x| | | |
-  Load-split across equal MX alternates        |5.3.4     | |x| | | |
-  Use the Domain Name System                   |5.3.5     |x| | | | |
-    Support MX records                         |5.3.5     |x| | | | |
-    Use WKS records in MX processing           |5.2.12    | | | |x| |
------------------------------------------------|----------|-|-|-|-|-|--
-                                               |          | | | | | |
-MAIL FORWARDING:                               |          | | | | | |
-  Alter existing header field(s)               |5.2.6     | | | |x| |
-  Implement relay function: 821/section 3.6    |5.2.6     | | |x| | |
-    If not, deliver to RHS domain              |5.2.6     | |x| | | |
-  Interpret 'local-part' of addr               |5.2.16    | | | | |x|
-                                               |          | | | | | |
-MAILING LISTS AND ALIASES                      |          | | | | | |
-  Support both                                 |5.3.6     | |x| | | |
-  Report mail list error to local admin.       |5.3.6     |x| | | | |
-                                               |          | | | | | |
-MAIL GATEWAYS:                                 |          | | | | | |
-  Embed foreign mail route in local-part       |5.2.16    | | |x| | |
-  Rewrite header fields when necessary         |5.3.7     | | |x| | |
-  Prepend Received: line                       |5.3.7     |x| | | | |
-  Change existing Received: line               |5.3.7     | | | | |x|
-  Accept full RFC-822 on Internet side         |5.3.7     | |x| | | |
-  Act on RFC-822 explicit source route         |5.3.7     | | |x| | |
-
-
-
-Internet Engineering Task Force                                [Page 70]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-  Send only valid RFC-822 on Internet side     |5.3.7     |x| | | | |
-  Deliver error msgs to envelope addr          |5.3.7     | |x| | | |
-  Set env return path from err return addr     |5.3.7     | |x| | | |
-                                               |          | | | | | |
-USER AGENT -- RFC-822                          |          | | | | | |
-  Allow user to enter <route> address          |5.2.6     | | | |x| |
-  Support RFC-1049 Content Type field          |5.2.13    | | |x| | |
-  Use 4-digit years                            |5.2.14    | |x| | | |
-  Generate numeric timezones                   |5.2.14    | |x| | | |
-  Accept all timezones                         |5.2.14    |x| | | | |
-  Use non-num timezones from RFC-822           |5.2.14    |x| | | | |
-  Omit phrase before route-addr                |5.2.15    | | |x| | |
-  Accept and parse dot.dec. domain literals    |5.2.17    |x| | | | |
-  Accept all RFC-822 address formats           |5.2.18    |x| | | | |
-  Generate invalid RFC-822 address format      |5.2.18    | | | | |x|
-  Fully-qualified domain names in header       |5.2.18    |x| | | | |
-  Create explicit src route in header          |5.2.19    | | | |x| |
-  Accept explicit src route in header          |5.2.19    |x| | | | |
-                                               |          | | | | | |
-Send/recv at least 64KB messages               |5.3.8     |x| | | | |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 71]
-
-
-
-
-RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
-
-
-6. SUPPORT SERVICES
-
-   6.1 DOMAIN NAME TRANSLATION
-
-      6.1.1 INTRODUCTION
-
-         Every host MUST implement a resolver for the Domain Name System
-         (DNS), and it MUST implement a mechanism using this DNS
-         resolver to convert host names to IP addresses and vice-versa
-         [DNS:1, DNS:2].
-
-         In addition to the DNS, a host MAY also implement a host name
-         translation mechanism that searches a local Internet host
-         table.  See Section 6.1.3.8 for more information on this
-         option.
-
-         DISCUSSION:
-              Internet host name translation was originally performed by
-              searching local copies of a table of all hosts.  This
-              table became too large to update and distribute in a
-              timely manner and too large to fit into many hosts, so the
-              DNS was invented.
-
-              The DNS creates a distributed database used primarily for
-              the translation between host names and host addresses.
-              Implementation of DNS software is required.  The DNS
-              consists of two logically distinct parts: name servers and
-              resolvers (although implementations often combine these
-              two logical parts in the interest of efficiency) [DNS:2].
-
-              Domain name servers store authoritative data about certain
-              sections of the database and answer queries about the
-              data.  Domain resolvers query domain name servers for data
-              on behalf of user processes.  Every host therefore needs a
-              DNS resolver; some host machines will also need to run
-              domain name servers.  Since no name server has complete
-              information, in general it is necessary to obtain
-              information from more than one name server to resolve a
-              query.
-
-      6.1.2  PROTOCOL WALK-THROUGH
-
-         An implementor must study references [DNS:1] and [DNS:2]
-         carefully.  They provide a thorough description of the theory,
-         protocol, and implementation of the domain name system, and
-         reflect several years of experience.
-
-
-
-
-
-Internet Engineering Task Force                                [Page 72]
-
-
-
-
-RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
-
-
-         6.1.2.1  Resource Records with Zero TTL: RFC-1035 Section 3.2.1
-
-            All DNS name servers and resolvers MUST properly handle RRs
-            with a zero TTL: return the RR to the client but do not
-            cache it.
-
-            DISCUSSION:
-                 Zero TTL values are interpreted to mean that the RR can
-                 only be used for the transaction in progress, and
-                 should not be cached; they are useful for extremely
-                 volatile data.
-
-         6.1.2.2  QCLASS Values: RFC-1035 Section 3.2.5
-
-            A query with "QCLASS=*" SHOULD NOT be used unless the
-            requestor is seeking data from more than one class.  In
-            particular, if the requestor is only interested in Internet
-            data types, QCLASS=IN MUST be used.
-
-         6.1.2.3  Unused Fields: RFC-1035 Section 4.1.1
-
-            Unused fields in a query or response message MUST be zero.
-
-         6.1.2.4  Compression: RFC-1035 Section 4.1.4
-
-            Name servers MUST use compression in responses.
-
-            DISCUSSION:
-                 Compression is essential to avoid overflowing UDP
-                 datagrams; see Section 6.1.3.2.
-
-         6.1.2.5  Misusing Configuration Info: RFC-1035 Section 6.1.2
-
-            Recursive name servers and full-service resolvers generally
-            have some configuration information containing hints about
-            the location of root or local name servers.  An
-            implementation MUST NOT include any of these hints in a
-            response.
-
-            DISCUSSION:
-                 Many implementors have found it convenient to store
-                 these hints as if they were cached data, but some
-                 neglected to ensure that this "cached data" was not
-                 included in responses.  This has caused serious
-                 problems in the Internet when the hints were obsolete
-                 or incorrect.
-
-
-
-
-
-Internet Engineering Task Force                                [Page 73]
-
-
-
-
-RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
-
-
-      6.1.3  SPECIFIC ISSUES
-
-         6.1.3.1  Resolver Implementation
-
-            A name resolver SHOULD be able to multiplex concurrent
-            requests if the host supports concurrent processes.
-
-            In implementing a DNS resolver, one of two different models
-            MAY optionally be chosen: a full-service resolver, or a stub
-            resolver.
-
-
-            (A)  Full-Service Resolver
-
-                 A full-service resolver is a complete implementation of
-                 the resolver service, and is capable of dealing with
-                 communication failures, failure of individual name
-                 servers, location of the proper name server for a given
-                 name, etc.  It must satisfy the following requirements:
-
-                 o    The resolver MUST implement a local caching
-                      function to avoid repeated remote access for
-                      identical requests, and MUST time out information
-                      in the cache.
-
-                 o    The resolver SHOULD be configurable with start-up
-                      information pointing to multiple root name servers
-                      and multiple name servers for the local domain.
-                      This insures that the resolver will be able to
-                      access the whole name space in normal cases, and
-                      will be able to access local domain information
-                      should the local network become disconnected from
-                      the rest of the Internet.
-
-
-            (B)  Stub Resolver
-
-                 A "stub resolver" relies on the services of a recursive
-                 name server on the connected network or a "nearby"
-                 network.  This scheme allows the host to pass on the
-                 burden of the resolver function to a name server on
-                 another host.  This model is often essential for less
-                 capable hosts, such as PCs, and is also recommended
-                 when the host is one of several workstations on a local
-                 network, because it allows all of the workstations to
-                 share the cache of the recursive name server and hence
-                 reduce the number of domain requests exported by the
-                 local network.
-
-
-
-Internet Engineering Task Force                                [Page 74]
-
-
-
-
-RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
-
-
-                 At a minimum, the stub resolver MUST be capable of
-                 directing its requests to redundant recursive name
-                 servers.  Note that recursive name servers are allowed
-                 to restrict the sources of requests that they will
-                 honor, so the host administrator must verify that the
-                 service will be provided.  Stub resolvers MAY implement
-                 caching if they choose, but if so, MUST timeout cached
-                 information.
-
-
-         6.1.3.2  Transport Protocols
-
-            DNS resolvers and recursive servers MUST support UDP, and
-            SHOULD support TCP, for sending (non-zone-transfer) queries.
-            Specifically, a DNS resolver or server that is sending a
-            non-zone-transfer query MUST send a UDP query first.  If the
-            Answer section of the response is truncated and if the
-            requester supports TCP, it SHOULD try the query again using
-            TCP.
-
-            DNS servers MUST be able to service UDP queries and SHOULD
-            be able to service TCP queries.  A name server MAY limit the
-            resources it devotes to TCP queries, but it SHOULD NOT
-            refuse to service a TCP query just because it would have
-            succeeded with UDP.
-
-            Truncated responses MUST NOT be saved (cached) and later
-            used in such a way that the fact that they are truncated is
-            lost.
-
-            DISCUSSION:
-                 UDP is preferred over TCP for queries because UDP
-                 queries have much lower overhead, both in packet count
-                 and in connection state.  The use of UDP is essential
-                 for heavily-loaded servers, especially the root
-                 servers.  UDP also offers additional robustness, since
-                 a resolver can attempt several UDP queries to different
-                 servers for the cost of a single TCP query.
-
-                 It is possible for a DNS response to be truncated,
-                 although this is a very rare occurrence in the present
-                 Internet DNS.  Practically speaking, truncation cannot
-                 be predicted, since it is data-dependent.  The
-                 dependencies include the number of RRs in the answer,
-                 the size of each RR, and the savings in space realized
-                 by the name compression algorithm.  As a rule of thumb,
-                 truncation in NS and MX lists should not occur for
-                 answers containing 15 or fewer RRs.
-
-
-
-Internet Engineering Task Force                                [Page 75]
-
-
-
-
-RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
-
-
-                 Whether it is possible to use a truncated answer
-                 depends on the application.  A mailer must not use a
-                 truncated MX response, since this could lead to mail
-                 loops.
-
-                 Responsible practices can make UDP suffice in the vast
-                 majority of cases.  Name servers must use compression
-                 in responses.  Resolvers must differentiate truncation
-                 of the Additional section of a response (which only
-                 loses extra information) from truncation of the Answer
-                 section (which for MX records renders the response
-                 unusable by mailers).  Database administrators should
-                 list only a reasonable number of primary names in lists
-                 of name servers, MX alternatives, etc.
-
-                 However, it is also clear that some new DNS record
-                 types defined in the future will contain information
-                 exceeding the 512 byte limit that applies to UDP, and
-                 hence will require TCP.  Thus, resolvers and name
-                 servers should implement TCP services as a backup to
-                 UDP today, with the knowledge that they will require
-                 the TCP service in the future.
-
-            By private agreement, name servers and resolvers MAY arrange
-            to use TCP for all traffic between themselves.  TCP MUST be
-            used for zone transfers.
-
-            A DNS server MUST have sufficient internal concurrency that
-            it can continue to process UDP queries while awaiting a
-            response or performing a zone transfer on an open TCP
-            connection [DNS:2].
-
-            A server MAY support a UDP query that is delivered using an
-            IP broadcast or multicast address.  However, the Recursion
-            Desired bit MUST NOT be set in a query that is multicast,
-            and MUST be ignored by name servers receiving queries via a
-            broadcast or multicast address.  A host that sends broadcast
-            or multicast DNS queries SHOULD send them only as occasional
-            probes, caching the IP address(es) it obtains from the
-            response(s) so it can normally send unicast queries.
-
-            DISCUSSION:
-                 Broadcast or (especially) IP multicast can provide a
-                 way to locate nearby name servers without knowing their
-                 IP addresses in advance.  However, general broadcasting
-                 of recursive queries can result in excessive and
-                 unnecessary load on both network and servers.
-
-
-
-
-Internet Engineering Task Force                                [Page 76]
-
-
-
-
-RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
-
-
-         6.1.3.3  Efficient Resource Usage
-
-            The following requirements on servers and resolvers are very
-            important to the health of the Internet as a whole,
-            particularly when DNS services are invoked repeatedly by
-            higher level automatic servers, such as mailers.
-
-            (1)  The resolver MUST implement retransmission controls to
-                 insure that it does not waste communication bandwidth,
-                 and MUST impose finite bounds on the resources consumed
-                 to respond to a single request.  See [DNS:2] pages 43-
-                 44 for specific recommendations.
-
-            (2)  After a query has been retransmitted several times
-                 without a response, an implementation MUST give up and
-                 return a soft error to the application.
-
-            (3)  All DNS name servers and resolvers SHOULD cache
-                 temporary failures, with a timeout period of the order
-                 of minutes.
-
-                 DISCUSSION:
-                      This will prevent applications that immediately
-                      retry soft failures (in violation of Section 2.2
-                      of this document) from generating excessive DNS
-                      traffic.
-
-            (4)  All DNS name servers and resolvers SHOULD cache
-                 negative responses that indicate the specified name, or
-                 data of the specified type, does not exist, as
-                 described in [DNS:2].
-
-            (5)  When a DNS server or resolver retries a UDP query, the
-                 retry interval SHOULD be constrained by an exponential
-                 backoff algorithm, and SHOULD also have upper and lower
-                 bounds.
-
-                 IMPLEMENTATION:
-                      A measured RTT and variance (if available) should
-                      be used to calculate an initial retransmission
-                      interval.  If this information is not available, a
-                      default of no less than 5 seconds should be used.
-                      Implementations may limit the retransmission
-                      interval, but this limit must exceed twice the
-                      Internet maximum segment lifetime plus service
-                      delay at the name server.
-
-            (6)  When a resolver or server receives a Source Quench for
-
-
-
-Internet Engineering Task Force                                [Page 77]
-
-
-
-
-RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
-
-
-                 a query it has issued, it SHOULD take steps to reduce
-                 the rate of querying that server in the near future.  A
-                 server MAY ignore a Source Quench that it receives as
-                 the result of sending a response datagram.
-
-                 IMPLEMENTATION:
-                      One recommended action to reduce the rate is to
-                      send the next query attempt to an alternate
-                      server, if there is one available.  Another is to
-                      backoff the retry interval for the same server.
-
-
-         6.1.3.4  Multihomed Hosts
-
-            When the host name-to-address function encounters a host
-            with multiple addresses, it SHOULD rank or sort the
-            addresses using knowledge of the immediately connected
-            network number(s) and any other applicable performance or
-            history information.
-
-            DISCUSSION:
-                 The different addresses of a multihomed host generally
-                 imply different Internet paths, and some paths may be
-                 preferable to others in performance, reliability, or
-                 administrative restrictions.  There is no general way
-                 for the domain system to determine the best path.  A
-                 recommended approach is to base this decision on local
-                 configuration information set by the system
-                 administrator.
-
-            IMPLEMENTATION:
-                 The following scheme has been used successfully:
-
-                 (a)  Incorporate into the host configuration data a
-                      Network-Preference List, that is simply a list of
-                      networks in preferred order.  This list may be
-                      empty if there is no preference.
-
-                 (b)  When a host name is mapped into a list of IP
-                      addresses, these addresses should be sorted by
-                      network number, into the same order as the
-                      corresponding networks in the Network-Preference
-                      List.  IP addresses whose networks do not appear
-                      in the Network-Preference List should be placed at
-                      the end of the list.
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 78]
-
-
-
-
-RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
-
-
-         6.1.3.5  Extensibility
-
-            DNS software MUST support all well-known, class-independent
-            formats [DNS:2], and SHOULD be written to minimize the
-            trauma associated with the introduction of new well-known
-            types and local experimentation with non-standard types.
-
-            DISCUSSION:
-                 The data types and classes used by the DNS are
-                 extensible, and thus new types will be added and old
-                 types deleted or redefined.  Introduction of new data
-                 types ought to be dependent only upon the rules for
-                 compression of domain names inside DNS messages, and
-                 the translation between printable (i.e., master file)
-                 and internal formats for Resource Records (RRs).
-
-                 Compression relies on knowledge of the format of data
-                 inside a particular RR.  Hence compression must only be
-                 used for the contents of well-known, class-independent
-                 RRs, and must never be used for class-specific RRs or
-                 RR types that are not well-known.  The owner name of an
-                 RR is always eligible for compression.
-
-                 A name server may acquire, via zone transfer, RRs that
-                 the server doesn't know how to convert to printable
-                 format.  A resolver can receive similar information as
-                 the result of queries.  For proper operation, this data
-                 must be preserved, and hence the implication is that
-                 DNS software cannot use textual formats for internal
-                 storage.
-
-                 The DNS defines domain name syntax very generally -- a
-                 string of labels each containing up to 63 8-bit octets,
-                 separated by dots, and with a maximum total of 255
-                 octets.  Particular applications of the DNS are
-                 permitted to further constrain the syntax of the domain
-                 names they use, although the DNS deployment has led to
-                 some applications allowing more general names.  In
-                 particular, Section 2.1 of this document liberalizes
-                 slightly the syntax of a legal Internet host name that
-                 was defined in RFC-952 [DNS:4].
-
-         6.1.3.6  Status of RR Types
-
-            Name servers MUST be able to load all RR types except MD and
-            MF from configuration files.  The MD and MF types are
-            obsolete and MUST NOT be implemented; in particular, name
-            servers MUST NOT load these types from configuration files.
-
-
-
-Internet Engineering Task Force                                [Page 79]
-
-
-
-
-RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
-
-
-            DISCUSSION:
-                 The RR types MB, MG, MR, NULL, MINFO and RP are
-                 considered experimental, and applications that use the
-                 DNS cannot expect these RR types to be supported by
-                 most domains.  Furthermore these types are subject to
-                 redefinition.
-
-                 The TXT and WKS RR types have not been widely used by
-                 Internet sites; as a result, an application cannot rely
-                 on the the existence of a TXT or WKS RR in most
-                 domains.
-
-         6.1.3.7  Robustness
-
-            DNS software may need to operate in environments where the
-            root servers or other servers are unavailable due to network
-            connectivity or other problems.  In this situation, DNS name
-            servers and resolvers MUST continue to provide service for
-            the reachable part of the name space, while giving temporary
-            failures for the rest.
-
-            DISCUSSION:
-                 Although the DNS is meant to be used primarily in the
-                 connected Internet, it should be possible to use the
-                 system in networks which are unconnected to the
-                 Internet.  Hence implementations must not depend on
-                 access to root servers before providing service for
-                 local names.
-
-         6.1.3.8  Local Host Table
-
-            DISCUSSION:
-                 A host may use a local host table as a backup or
-                 supplement to the DNS.  This raises the question of
-                 which takes precedence, the DNS or the host table; the
-                 most flexible approach would make this a configuration
-                 option.
-
-                 Typically, the contents of such a supplementary host
-                 table will be determined locally by the site.  However,
-                 a publically-available table of Internet hosts is
-                 maintained by the DDN Network Information Center (DDN
-                 NIC), with a format documented in [DNS:4].  This table
-                 can be retrieved from the DDN NIC using a protocol
-                 described in [DNS:5].  It must be noted that this table
-                 contains only a small fraction of all Internet hosts.
-                 Hosts using this protocol to retrieve the DDN NIC host
-                 table should use the VERSION command to check if the
-
-
-
-Internet Engineering Task Force                                [Page 80]
-
-
-
-
-RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
-
-
-                 table has changed before requesting the entire table
-                 with the ALL command.  The VERSION identifier should be
-                 treated as an arbitrary string and tested only for
-                 equality; no numerical sequence may be assumed.
-
-                 The DDN NIC host table includes administrative
-                 information that is not needed for host operation and
-                 is therefore not currently included in the DNS
-                 database; examples include network and gateway entries.
-                 However, much of this additional information will be
-                 added to the DNS in the future.  Conversely, the DNS
-                 provides essential services (in particular, MX records)
-                 that are not available from the DDN NIC host table.
-
-      6.1.4  DNS USER INTERFACE
-
-         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].
-
-         6.1.4.2  DNS User Interface
-
-            Hosts MUST provide an interface to the DNS for all
-            application programs running on the host.  This interface
-            will typically direct requests to a system process to
-            perform the resolver function [DNS:1, 6.1:2].
-
-            At a minimum, the basic interface MUST support a request for
-            all information of a specific type and class associated with
-            a specific name, and it MUST return either all of the
-            requested information, a hard error code, or a soft error
-            indication.  When there is no error, the basic interface
-            returns the complete response information without
-            modification, deletion, or ordering, so that the basic
-            interface will not need to be changed to accommodate new
-            data types.
-
-            DISCUSSION:
-                 The soft error indication is an essential part of the
-                 interface, since it may not always be possible to
-                 access particular information from the DNS; see Section
-                 6.1.3.3.
-
-
-
-Internet Engineering Task Force                                [Page 81]
-
-
-
-
-RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
-
-
-            A host MAY provide other DNS interfaces tailored to
-            particular functions, transforming the raw domain data into
-            formats more suited to these functions.  In particular, a
-            host MUST provide a DNS interface to facilitate translation
-            between host addresses and host names.
-
-         6.1.4.3 Interface Abbreviation Facilities
-
-            User interfaces MAY provide a method for users to enter
-            abbreviations for commonly-used names.  Although the
-            definition of such methods is outside of the scope of the
-            DNS specification, certain rules are necessary to insure
-            that these methods allow access to the entire DNS name space
-            and to prevent excessive use of Internet resources.
-
-            If an abbreviation method is provided, then:
-
-            (a)  There MUST be some convention for denoting that a name
-                 is already complete, so that the abbreviation method(s)
-                 are suppressed.  A trailing dot is the usual method.
-
-            (b)  Abbreviation expansion MUST be done exactly once, and
-                 MUST be done in the context in which the name was
-                 entered.
-
-
-            DISCUSSION:
-                 For example, if an abbreviation is used in a mail
-                 program for a destination, the abbreviation should be
-                 expanded into a full domain name and stored in the
-                 queued message with an indication that it is already
-                 complete.  Otherwise, the abbreviation might be
-                 expanded with a mail system search list, not the
-                 user's, or a name could grow due to repeated
-                 canonicalizations attempts interacting with wildcards.
-
-            The two most common abbreviation methods are:
-
-            (1)  Interface-level aliases
-
-                 Interface-level aliases are conceptually implemented as
-                 a list of alias/domain name pairs. The list can be
-                 per-user or per-host, and separate lists can be
-                 associated with different functions, e.g. one list for
-                 host name-to-address translation, and a different list
-                 for mail domains.  When the user enters a name, the
-                 interface attempts to match the name to the alias
-                 component of a list entry, and if a matching entry can
-
-
-
-Internet Engineering Task Force                                [Page 82]
-
-
-
-
-RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
-
-
-                 be found, the name is replaced by the domain name found
-                 in the pair.
-
-                 Note that interface-level aliases and CNAMEs are
-                 completely separate mechanisms; interface-level aliases
-                 are a local matter while CNAMEs are an Internet-wide
-                 aliasing mechanism which is a required part of any DNS
-                 implementation.
-
-            (2)  Search Lists
-
-                 A search list is conceptually implemented as an ordered
-                 list of domain names.  When the user enters a name, the
-                 domain names in the search list are used as suffixes to
-                 the user-supplied name, one by one, until a domain name
-                 with the desired associated data is found, or the
-                 search list is exhausted.  Search lists often contain
-                 the name of the local host's parent domain or other
-                 ancestor domains.  Search lists are often per-user or
-                 per-process.
-
-                 It SHOULD be possible for an administrator to disable a
-                 DNS search-list facility.  Administrative denial may be
-                 warranted in some cases, to prevent abuse of the DNS.
-
-                 There is danger that a search-list mechanism will
-                 generate excessive queries to the root servers while
-                 testing whether user input is a complete domain name,
-                 lacking a final period to mark it as complete.  A
-                 search-list mechanism MUST have one of, and SHOULD have
-                 both of, the following two provisions to prevent this:
-
-                 (a)  The local resolver/name server can implement
-                      caching  of negative responses (see Section
-                      6.1.3.3).
-
-                 (b)  The search list expander can require two or more
-                      interior dots in a generated domain name before it
-                      tries using the name in a query to non-local
-                      domain servers, such as the root.
-
-                 DISCUSSION:
-                      The intent of this requirement is to avoid
-                      excessive delay for the user as the search list is
-                      tested, and more importantly to prevent excessive
-                      traffic to the root and other high-level servers.
-                      For example, if the user supplied a name "X" and
-                      the search list contained the root as a component,
-
-
-
-Internet Engineering Task Force                                [Page 83]
-
-
-
-
-RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
-
-
-                      a query would have to consult a root server before
-                      the next search list alternative could be tried.
-                      The resulting load seen by the root servers and
-                      gateways near the root would be multiplied by the
-                      number of hosts in the Internet.
-
-                      The negative caching alternative limits the effect
-                      to the first time a name is used.  The interior
-                      dot rule is simpler to implement but can prevent
-                      easy use of some top-level names.
-
-
-      6.1.5  DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY
-
-                                               |           | | | |S| |
-                                               |           | | | |H| |F
-                                               |           | | | |O|M|o
-                                               |           | |S| |U|U|o
-                                               |           | |H| |L|S|t
-                                               |           |M|O| |D|T|n
-                                               |           |U|U|M| | |o
-                                               |           |S|L|A|N|N|t
-                                               |           |T|D|Y|O|O|t
-FEATURE                                        |SECTION    | | | |T|T|e
------------------------------------------------|-----------|-|-|-|-|-|--
-GENERAL ISSUES                                 |           | | | | | |
-                                               |           | | | | | |
-Implement DNS name-to-address conversion       |6.1.1      |x| | | | |
-Implement DNS address-to-name conversion       |6.1.1      |x| | | | |
-Support conversions using host table           |6.1.1      | | |x| | |
-Properly handle RR with zero TTL               |6.1.2.1    |x| | | | |
-Use QCLASS=* unnecessarily                     |6.1.2.2    | |x| | | |
-  Use QCLASS=IN for Internet class             |6.1.2.2    |x| | | | |
-Unused fields zero                             |6.1.2.3    |x| | | | |
-Use compression in responses                   |6.1.2.4    |x| | | | |
-                                               |           | | | | | |
-Include config info in responses               |6.1.2.5    | | | | |x|
-Support all well-known, class-indep. types     |6.1.3.5    |x| | | | |
-Easily expand type list                        |6.1.3.5    | |x| | | |
-Load all RR types (except MD and MF)           |6.1.3.6    |x| | | | |
-Load MD or MF type                             |6.1.3.6    | | | | |x|
-Operate when root servers, etc. unavailable    |6.1.3.7    |x| | | | |
------------------------------------------------|-----------|-|-|-|-|-|--
-RESOLVER ISSUES:                               |           | | | | | |
-                                               |           | | | | | |
-Resolver support multiple concurrent requests  |6.1.3.1    | |x| | | |
-Full-service resolver:                         |6.1.3.1    | | |x| | |
-  Local caching                                |6.1.3.1    |x| | | | |
-
-
-
-Internet Engineering Task Force                                [Page 84]
-
-
-
-
-RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
-
-
-  Information in local cache times out         |6.1.3.1    |x| | | | |
-  Configurable with starting info              |6.1.3.1    | |x| | | |
-Stub resolver:                                 |6.1.3.1    | | |x| | |
-  Use redundant recursive name servers         |6.1.3.1    |x| | | | |
-  Local caching                                |6.1.3.1    | | |x| | |
-  Information in local cache times out         |6.1.3.1    |x| | | | |
-Support for remote multi-homed hosts:          |           | | | | | |
-  Sort multiple addresses by preference list   |6.1.3.4    | |x| | | |
-                                               |           | | | | | |
------------------------------------------------|-----------|-|-|-|-|-|--
-TRANSPORT PROTOCOLS:                           |           | | | | | |
-                                               |           | | | | | |
-Support UDP queries                            |6.1.3.2    |x| | | | |
-Support TCP queries                            |6.1.3.2    | |x| | | |
-  Send query using UDP first                   |6.1.3.2    |x| | | | |1
-  Try TCP if UDP answers are truncated         |6.1.3.2    | |x| | | |
-Name server limit TCP query resources          |6.1.3.2    | | |x| | |
-  Punish unnecessary TCP query                 |6.1.3.2    | | | |x| |
-Use truncated data as if it were not           |6.1.3.2    | | | | |x|
-Private agreement to use only TCP              |6.1.3.2    | | |x| | |
-Use TCP for zone transfers                     |6.1.3.2    |x| | | | |
-TCP usage not block UDP queries                |6.1.3.2    |x| | | | |
-Support broadcast or multicast queries         |6.1.3.2    | | |x| | |
-  RD bit set in query                          |6.1.3.2    | | | | |x|
-  RD bit ignored by server is b'cast/m'cast    |6.1.3.2    |x| | | | |
-  Send only as occasional probe for addr's     |6.1.3.2    | |x| | | |
------------------------------------------------|-----------|-|-|-|-|-|--
-RESOURCE USAGE:                                |           | | | | | |
-                                               |           | | | | | |
-Transmission controls, per [DNS:2]             |6.1.3.3    |x| | | | |
-  Finite bounds per request                    |6.1.3.3    |x| | | | |
-Failure after retries => soft error            |6.1.3.3    |x| | | | |
-Cache temporary failures                       |6.1.3.3    | |x| | | |
-Cache negative responses                       |6.1.3.3    | |x| | | |
-Retries use exponential backoff                |6.1.3.3    | |x| | | |
-  Upper, lower bounds                          |6.1.3.3    | |x| | | |
-Client handle Source Quench                    |6.1.3.3    | |x| | | |
-Server ignore Source Quench                    |6.1.3.3    | | |x| | |
------------------------------------------------|-----------|-|-|-|-|-|--
-USER INTERFACE:                                |           | | | | | |
-                                               |           | | | | | |
-All programs have access to DNS interface      |6.1.4.2    |x| | | | |
-Able to request all info for given name        |6.1.4.2    |x| | | | |
-Returns complete info or error                 |6.1.4.2    |x| | | | |
-Special interfaces                             |6.1.4.2    | | |x| | |
-  Name<->Address translation                   |6.1.4.2    |x| | | | |
-                                               |           | | | | | |
-Abbreviation Facilities:                       |6.1.4.3    | | |x| | |
-
-
-
-Internet Engineering Task Force                                [Page 85]
-
-
-
-
-RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
-
-
-  Convention for complete names                |6.1.4.3    |x| | | | |
-  Conversion exactly once                      |6.1.4.3    |x| | | | |
-  Conversion in proper context                 |6.1.4.3    |x| | | | |
-  Search list:                                 |6.1.4.3    | | |x| | |
-    Administrator can disable                  |6.1.4.3    | |x| | | |
-    Prevention of excessive root queries       |6.1.4.3    |x| | | | |
-      Both methods                             |6.1.4.3    | |x| | | |
------------------------------------------------|-----------|-|-|-|-|-|--
------------------------------------------------|-----------|-|-|-|-|-|--
-
-1.   Unless there is private agreement between particular resolver and
-     particular server.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 86]
-
-
-
-
-RFC1123            SUPPORT SERVICES -- INITIALIZATION       October 1989
-
-
-   6.2  HOST INITIALIZATION
-
-      6.2.1  INTRODUCTION
-
-         This section discusses the initialization of host software
-         across a connected network, or more generally across an
-         Internet path.  This is necessary for a diskless host, and may
-         optionally be used for a host with disk drives.  For a diskless
-         host, the initialization process is called "network booting"
-         and is controlled by a bootstrap program located in a boot ROM.
-
-         To initialize a diskless host across the network, there are two
-         distinct phases:
-
-         (1)  Configure the IP layer.
-
-              Diskless machines often have no permanent storage in which
-              to store network configuration information, so that
-              sufficient configuration information must be obtained
-              dynamically to support the loading phase that follows.
-              This information must include at least the IP addresses of
-              the host and of the boot server.  To support booting
-              across a gateway, the address mask and a list of default
-              gateways are also required.
-
-         (2)  Load the host system code.
-
-              During the loading phase, an appropriate file transfer
-              protocol is used to copy the system code across the
-              network from the boot server.
-
-         A host with a disk may perform the first step, dynamic
-         configuration.  This is important for microcomputers, whose
-         floppy disks allow network configuration information to be
-         mistakenly duplicated on more than one host.  Also,
-         installation of new hosts is much simpler if they automatically
-         obtain their configuration information from a central server,
-         saving administrator time and decreasing the probability of
-         mistakes.
-
-      6.2.2  REQUIREMENTS
-
-         6.2.2.1  Dynamic Configuration
-
-            A number of protocol provisions have been made for dynamic
-            configuration.
-
-            o    ICMP Information Request/Reply messages
-
-
-
-Internet Engineering Task Force                                [Page 87]
-
-
-
-
-RFC1123            SUPPORT SERVICES -- INITIALIZATION       October 1989
-
-
-                 This obsolete message pair was designed to allow a host
-                 to find the number of the network it is on.
-                 Unfortunately, it was useful only if the host already
-                 knew the host number part of its IP address,
-                 information that hosts requiring dynamic configuration
-                 seldom had.
-
-            o    Reverse Address Resolution Protocol (RARP) [BOOT:4]
-
-                 RARP is a link-layer protocol for a broadcast medium
-                 that allows a host to find its IP address given its
-                 link layer address.  Unfortunately, RARP does not work
-                 across IP gateways and therefore requires a RARP server
-                 on every network.  In addition, RARP does not provide
-                 any other configuration information.
-
-            o    ICMP Address Mask Request/Reply messages
-
-                 These ICMP messages allow a host to learn the address
-                 mask for a particular network interface.
-
-            o    BOOTP Protocol [BOOT:2]
-
-                 This protocol allows a host to determine the IP
-                 addresses of the local host and the boot server, the
-                 name of an appropriate boot file, and optionally the
-                 address mask and list of default gateways.  To locate a
-                 BOOTP server, the host broadcasts a BOOTP request using
-                 UDP.  Ad hoc gateway extensions have been used to
-                 transmit the BOOTP broadcast through gateways, and in
-                 the future the IP Multicasting facility will provide a
-                 standard mechanism for this purpose.
-
-
-            The suggested approach to dynamic configuration is to use
-            the BOOTP protocol with the extensions defined in "BOOTP
-            Vendor Information Extensions" RFC-1084 [BOOT:3].  RFC-1084
-            defines some important general (not vendor-specific)
-            extensions.  In particular, these extensions allow the
-            address mask to be supplied in BOOTP; we RECOMMEND that the
-            address mask be supplied in this manner.
-
-            DISCUSSION:
-                 Historically, subnetting was defined long after IP, and
-                 so a separate mechanism (ICMP Address Mask messages)
-                 was designed to supply the address mask to a host.
-                 However, the IP address mask and the corresponding IP
-                 address conceptually form a pair, and for operational
-
-
-
-Internet Engineering Task Force                                [Page 88]
-
-
-
-
-RFC1123            SUPPORT SERVICES -- INITIALIZATION       October 1989
-
-
-                 simplicity they ought to be defined at the same time
-                 and by the same mechanism, whether a configuration file
-                 or a dynamic mechanism like BOOTP.
-
-                 Note that BOOTP is not sufficiently general to specify
-                 the configurations of all interfaces of a multihomed
-                 host.  A multihomed host must either use BOOTP
-                 separately for each interface, or configure one
-                 interface using BOOTP to perform the loading, and
-                 perform the complete initialization from a file later.
-
-                 Application layer configuration information is expected
-                 to be obtained from files after loading of the system
-                 code.
-
-         6.2.2.2  Loading Phase
-
-            A suggested approach for the loading phase is to use TFTP
-            [BOOT:1] between the IP addresses established by BOOTP.
-
-            TFTP to a broadcast address SHOULD NOT be used, for reasons
-            explained in Section 4.2.3.4.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 89]
-
-
-
-
-RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
-
-
-   6.3  REMOTE MANAGEMENT
-
-      6.3.1  INTRODUCTION
-
-         The Internet community has recently put considerable effort
-         into the development of network management protocols.  The
-         result has been a two-pronged approach [MGT:1, MGT:6]:  the
-         Simple Network Management Protocol (SNMP) [MGT:4] and the
-         Common Management Information Protocol over TCP (CMOT) [MGT:5].
-
-         In order to be managed using SNMP or CMOT, a host will need to
-         implement an appropriate management agent.  An Internet host
-         SHOULD include an agent for either SNMP or CMOT.
-
-         Both SNMP and CMOT operate on a Management Information Base
-         (MIB) that defines a collection of management values.  By
-         reading and setting these values, a remote application may
-         query and change the state of the managed system.
-
-         A standard MIB [MGT:3] has been defined for use by both
-         management protocols, using data types defined by the Structure
-         of Management Information (SMI) defined in [MGT:2].  Additional
-         MIB variables can be introduced under the "enterprises" and
-         "experimental" subtrees of the MIB naming space [MGT:2].
-
-         Every protocol module in the host SHOULD implement the relevant
-         MIB variables.  A host SHOULD implement the MIB variables as
-         defined in the most recent standard MIB, and MAY implement
-         other MIB variables when appropriate and useful.
-
-      6.3.2  PROTOCOL WALK-THROUGH
-
-         The MIB is intended to cover both hosts and gateways, although
-         there may be detailed differences in MIB application to the two
-         cases.  This section contains the appropriate interpretation of
-         the MIB for hosts.  It is likely that later versions of the MIB
-         will include more entries for host management.
-
-         A managed host must implement the following groups of MIB
-         object definitions: System, Interfaces, Address Translation,
-         IP, ICMP, TCP, and UDP.
-
-         The following specific interpretations apply to hosts:
-
-         o    ipInHdrErrors
-
-              Note that the error "time-to-live exceeded" can occur in a
-              host only when it is forwarding a source-routed datagram.
-
-
-
-Internet Engineering Task Force                                [Page 90]
-
-
-
-
-RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
-
-
-         o    ipOutNoRoutes
-
-              This object counts datagrams discarded because no route
-              can be found.  This may happen in a host if all the
-              default gateways in the host's configuration are down.
-
-         o    ipFragOKs, ipFragFails, ipFragCreates
-
-              A host that does not implement intentional fragmentation
-              (see "Fragmentation" section of [INTRO:1]) MUST return the
-              value zero for these three objects.
-
-         o    icmpOutRedirects
-
-              For a host, this object MUST always be zero, since hosts
-              do not send Redirects.
-
-         o    icmpOutAddrMaskReps
-
-              For a host, this object MUST always be zero, unless the
-              host is an authoritative source of address mask
-              information.
-
-         o    ipAddrTable
-
-              For a host, the "IP Address Table" object is effectively a
-              table of logical interfaces.
-
-         o    ipRoutingTable
-
-              For a host, the "IP Routing Table" object is effectively a
-              combination of the host's Routing Cache and the static
-              route table described in "Routing Outbound Datagrams"
-              section of [INTRO:1].
-
-              Within each ipRouteEntry, ipRouteMetric1...4 normally will
-              have no meaning for a host and SHOULD always be -1, while
-              ipRouteType will normally have the value "remote".
-
-              If destinations on the connected network do not appear in
-              the Route Cache (see "Routing Outbound Datagrams section
-              of [INTRO:1]), there will be no entries with ipRouteType
-              of "direct".
-
-
-         DISCUSSION:
-              The current MIB does not include Type-of-Service in an
-              ipRouteEntry, but a future revision is expected to make
-
-
-
-Internet Engineering Task Force                                [Page 91]
-
-
-
-
-RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
-
-
-              this addition.
-
-              We also expect the MIB to be expanded to allow the remote
-              management of applications (e.g., the ability to partially
-              reconfigure mail systems).  Network service applications
-              such as mail systems should therefore be written with the
-              "hooks" for remote management.
-
-      6.3.3  MANAGEMENT REQUIREMENTS SUMMARY
-
-                                               |           | | | |S| |
-                                               |           | | | |H| |F
-                                               |           | | | |O|M|o
-                                               |           | |S| |U|U|o
-                                               |           | |H| |L|S|t
-                                               |           |M|O| |D|T|n
-                                               |           |U|U|M| | |o
-                                               |           |S|L|A|N|N|t
-                                               |           |T|D|Y|O|O|t
-FEATURE                                        |SECTION    | | | |T|T|e
------------------------------------------------|-----------|-|-|-|-|-|--
-Support SNMP or CMOT agent                     |6.3.1      | |x| | | |
-Implement specified objects in standard MIB    |6.3.1      | |x| | | |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 92]
-
-
-
-
-RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
-
-
-7.  REFERENCES
-
-   This section lists the primary references with which every
-   implementer must be thoroughly familiar.  It also lists some
-   secondary references that are suggested additional reading.
-
-   INTRODUCTORY REFERENCES:
-
-
-   [INTRO:1] "Requirements for Internet Hosts -- Communication Layers,"
-        IETF Host Requirements Working Group, R. Braden, Ed., RFC-1122,
-        October 1989.
-
-   [INTRO:2]  "DDN Protocol Handbook," NIC-50004, NIC-50005, NIC-50006,
-        (three volumes), SRI International, December 1985.
-
-   [INTRO:3]  "Official Internet Protocols," J. Reynolds and J. Postel,
-        RFC-1011, May 1987.
-
-        This document is republished periodically with new RFC numbers;
-        the latest version must be used.
-
-   [INTRO:4]  "Protocol Document Order Information," O. Jacobsen and J.
-        Postel, RFC-980, March 1986.
-
-   [INTRO:5]  "Assigned Numbers," J. Reynolds and J. Postel, RFC-1010,
-        May 1987.
-
-        This document is republished periodically with new RFC numbers;
-        the latest version must be used.
-
-
-   TELNET REFERENCES:
-
-
-   [TELNET:1]  "Telnet Protocol Specification," J. Postel and J.
-        Reynolds, RFC-854, May 1983.
-
-   [TELNET:2]  "Telnet Option Specification," J. Postel and J. Reynolds,
-        RFC-855, May 1983.
-
-   [TELNET:3]  "Telnet Binary Transmission," J. Postel and J. Reynolds,
-        RFC-856, May 1983.
-
-   [TELNET:4]  "Telnet Echo Option," J. Postel and J. Reynolds, RFC-857,
-        May 1983.
-
-   [TELNET:5]  "Telnet Suppress Go Ahead Option," J. Postel and J.
-
-
-
-Internet Engineering Task Force                                [Page 93]
-
-
-
-
-RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
-
-
-        Reynolds, RFC-858, May 1983.
-
-   [TELNET:6]  "Telnet Status Option," J. Postel and J. Reynolds, RFC-
-        859, May 1983.
-
-   [TELNET:7]  "Telnet Timing Mark Option," J. Postel and J. Reynolds,
-        RFC-860, May 1983.
-
-   [TELNET:8]  "Telnet Extended Options List," J. Postel and J.
-        Reynolds, RFC-861, May 1983.
-
-   [TELNET:9]  "Telnet End-Of-Record Option," J. Postel, RFC-855,
-        December 1983.
-
-   [TELNET:10] "Telnet Terminal-Type Option," J. VanBokkelen, RFC-1091,
-        February 1989.
-
-        This document supercedes RFC-930.
-
-   [TELNET:11] "Telnet Window Size Option," D. Waitzman, RFC-1073,
-        October 1988.
-
-   [TELNET:12] "Telnet Linemode Option," D. Borman, RFC-1116, August
-        1989.
-
-   [TELNET:13] "Telnet Terminal Speed Option," C. Hedrick, RFC-1079,
-        December 1988.
-
-   [TELNET:14] "Telnet Remote Flow Control Option," C. Hedrick, RFC-
-        1080, November 1988.
-
-
-   SECONDARY TELNET REFERENCES:
-
-
-   [TELNET:15] "Telnet Protocol," MIL-STD-1782, U.S. Department of
-        Defense, May 1984.
-
-        This document is intended to describe the same protocol as RFC-
-        854.  In case of conflict, RFC-854 takes precedence, and the
-        present document takes precedence over both.
-
-   [TELNET:16] "SUPDUP Protocol," M. Crispin, RFC-734, October 1977.
-
-   [TELNET:17] "Telnet SUPDUP Option," M. Crispin, RFC-736, October
-        1977.
-
-   [TELNET:18] "Data Entry Terminal Option," J. Day, RFC-732, June 1977.
-
-
-
-Internet Engineering Task Force                                [Page 94]
-
-
-
-
-RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
-
-
-   [TELNET:19] "TELNET Data Entry Terminal option -- DODIIS
-        Implementation," A. Yasuda and T. Thompson, RFC-1043, February
-        1988.
-
-
-   FTP REFERENCES:
-
-
-   [FTP:1]  "File Transfer Protocol," J. Postel and J. Reynolds, RFC-
-        959, October 1985.
-
-   [FTP:2]  "Document File Format Standards," J. Postel, RFC-678,
-        December 1974.
-
-   [FTP:3]  "File Transfer Protocol," MIL-STD-1780, U.S. Department of
-        Defense, May 1984.
-
-        This document is based on an earlier version of the FTP
-        specification (RFC-765) and is obsolete.
-
-
-   TFTP REFERENCES:
-
-
-   [TFTP:1]  "The TFTP Protocol Revision 2," K. Sollins, RFC-783, June
-        1981.
-
-
-   MAIL REFERENCES:
-
-
-   [SMTP:1]  "Simple Mail Transfer Protocol," J. Postel, RFC-821, August
-        1982.
-
-   [SMTP:2]  "Standard For The Format of ARPA Internet Text Messages,"
-        D. Crocker, RFC-822, August 1982.
-
-        This document obsoleted an earlier specification, RFC-733.
-
-   [SMTP:3]  "Mail Routing and the Domain System," C. Partridge, RFC-
-        974, January 1986.
-
-        This RFC describes the use of MX records, a mandatory extension
-        to the mail delivery process.
-
-   [SMTP:4]  "Duplicate Messages and SMTP," C. Partridge, RFC-1047,
-        February 1988.
-
-
-
-
-Internet Engineering Task Force                                [Page 95]
-
-
-
-
-RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
-
-
-   [SMTP:5a]  "Mapping between X.400 and RFC 822," S. Kille, RFC-987,
-        June 1986.
-
-   [SMTP:5b]  "Addendum to RFC-987," S. Kille, RFC-???, September 1987.
-
-        The two preceding RFC's define a proposed standard for
-        gatewaying mail between the Internet and the X.400 environments.
-
-   [SMTP:6]  "Simple Mail Transfer Protocol,"  MIL-STD-1781, U.S.
-        Department of Defense, May 1984.
-
-        This specification is intended to describe the same protocol as
-        does RFC-821.  However, MIL-STD-1781 is incomplete; in
-        particular, it does not include MX records [SMTP:3].
-
-   [SMTP:7]  "A Content-Type Field for Internet Messages," M. Sirbu,
-        RFC-1049, March 1988.
-
-
-   DOMAIN NAME SYSTEM REFERENCES:
-
-
-   [DNS:1]  "Domain Names - Concepts and Facilities," P. Mockapetris,
-        RFC-1034, November 1987.
-
-        This document and the following one obsolete RFC-882, RFC-883,
-        and RFC-973.
-
-   [DNS:2]  "Domain Names - Implementation and Specification," RFC-1035,
-        P. Mockapetris, November 1987.
-
-
-   [DNS:3]  "Mail Routing and the Domain System," C. Partridge, RFC-974,
-        January 1986.
-
-
-   [DNS:4]  "DoD Internet Host Table Specification," K. Harrenstein,
-        RFC-952, M. Stahl, E. Feinler, October 1985.
-
-        SECONDARY DNS REFERENCES:
-
-
-   [DNS:5]  "Hostname Server," K. Harrenstein, M. Stahl, E. Feinler,
-        RFC-953, October 1985.
-
-   [DNS:6]  "Domain Administrators Guide," M. Stahl, RFC-1032, November
-        1987.
-
-
-
-
-Internet Engineering Task Force                                [Page 96]
-
-
-
-
-RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
-
-
-   [DNS:7]  "Domain Administrators Operations Guide," M. Lottor, RFC-
-        1033, November 1987.
-
-   [DNS:8]  "The Domain Name System Handbook," Vol. 4 of Internet
-        Protocol Handbook, NIC 50007, SRI Network Information Center,
-        August 1989.
-
-
-   SYSTEM INITIALIZATION REFERENCES:
-
-
-   [BOOT:1] "Bootstrap Loading Using TFTP," R. Finlayson, RFC-906, June
-        1984.
-
-   [BOOT:2] "Bootstrap Protocol (BOOTP)," W. Croft and J. Gilmore, RFC-
-        951, September 1985.
-
-   [BOOT:3] "BOOTP Vendor Information Extensions," J. Reynolds, RFC-
-        1084, December 1988.
-
-        Note: this RFC revised and obsoleted RFC-1048.
-
-   [BOOT:4] "A Reverse Address Resolution Protocol," R. Finlayson, T.
-        Mann, J. Mogul, and M. Theimer, RFC-903, June 1984.
-
-
-   MANAGEMENT REFERENCES:
-
-
-   [MGT:1]  "IAB Recommendations for the Development of Internet Network
-        Management Standards," V. Cerf, RFC-1052, April 1988.
-
-   [MGT:2]  "Structure and Identification of Management Information for
-        TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1065,
-        August 1988.
-
-   [MGT:3]  "Management Information Base for Network Management of
-        TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1066,
-        August 1988.
-
-   [MGT:4]  "A Simple Network Management Protocol," J. Case, M. Fedor,
-        M. Schoffstall, and C. Davin, RFC-1098, April 1989.
-
-   [MGT:5]  "The Common Management Information Services and Protocol
-        over TCP/IP," U. Warrier and L. Besaw, RFC-1095, April 1989.
-
-   [MGT:6]  "Report of the Second Ad Hoc Network Management Review
-        Group," V. Cerf, RFC-1109, August 1989.
-
-
-
-Internet Engineering Task Force                                [Page 97]
-
-
-
-
-RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
-
-
-Security Considerations
-
-   There are many security issues in the application and support
-   programs of host software, but a full discussion is beyond the scope
-   of this RFC.  Security-related issues are mentioned in sections
-   concerning TFTP (Sections 4.2.1, 4.2.3.4, 4.2.3.5), the SMTP VRFY and
-   EXPN commands (Section 5.2.3), the SMTP HELO command (5.2.5), and the
-   SMTP DATA command (Section 5.2.8).
-
-Author's Address
-
-   Robert Braden
-   USC/Information Sciences Institute
-   4676 Admiralty Way
-   Marina del Rey, CA 90292-6695
-
-   Phone: (213) 822 1511
-
-   EMail: Braden@ISI.EDU
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 98]
-
diff --git a/contrib/bind9/doc/rfc/rfc1183.txt b/contrib/bind9/doc/rfc/rfc1183.txt
deleted file mode 100644
index 6f08044..0000000
--- a/contrib/bind9/doc/rfc/rfc1183.txt
+++ /dev/null
@@ -1,619 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        C. Everhart
-Request for Comments: 1183                                      Transarc
-Updates: RFCs 1034, 1035                                      L. Mamakos
-                                                  University of Maryland
-                                                              R. Ullmann
-                                                          Prime Computer
-                                                  P. Mockapetris, Editor
-                                                                     ISI
-                                                            October 1990
-
-
-                         New DNS RR Definitions
-
-Status of this Memo
-
-   This memo defines five new DNS types for experimental purposes.  This
-   RFC describes an Experimental Protocol for the Internet community,
-   and requests discussion and suggestions for improvements.
-   Distribution of this memo is unlimited.
-
-Table of Contents
-
-   Introduction....................................................    1
-   1. AFS Data Base location.......................................    2
-   2. Responsible Person...........................................    3
-   2.1. Identification of the guilty party.........................    3
-   2.2. The Responsible Person RR..................................    4
-   3. X.25 and ISDN addresses, Route Binding.......................    6
-   3.1. The X25 RR.................................................    6
-   3.2. The ISDN RR................................................    7
-   3.3. The Route Through RR.......................................    8
-   REFERENCES and BIBLIOGRAPHY.....................................    9
-   Security Considerations.........................................   10
-   Authors' Addresses..............................................   11
-
-Introduction
-
-   This RFC defines the format of new Resource Records (RRs) for the
-   Domain Name System (DNS), and reserves corresponding DNS type
-   mnemonics and numerical codes.  The definitions are in three
-   independent sections: (1) location of AFS database servers, (2)
-   location of responsible persons, and (3) representation of X.25 and
-   ISDN addresses and route binding.  All are experimental.
-
-   This RFC assumes that the reader is familiar with the DNS [3,4].  The
-   data shown is for pedagogical use and does not necessarily reflect
-   the real Internet.
-
-
-
-
-Everhart, Mamakos, Ullmann & Mockapetris                        [Page 1]
-
-RFC 1183                 New DNS RR Definitions             October 1990
-
-
-1. AFS Data Base location
-
-   This section defines an extension of the DNS to locate servers both
-   for AFS (AFS is a registered trademark of Transarc Corporation) and
-   for the Open Software Foundation's (OSF) Distributed Computing
-   Environment (DCE) authenticated naming system using HP/Apollo's NCA,
-   both to be components of the OSF DCE.  The discussion assumes that
-   the reader is familiar with AFS [5] and NCA [6].
-
-   The AFS (originally the Andrew File System) system uses the DNS to
-   map from a domain name to the name of an AFS cell database server.
-   The DCE Naming service uses the DNS for a similar function: mapping
-   from the domain name of a cell to authenticated name servers for that
-   cell.  The method uses a new RR type with mnemonic AFSDB and type
-   code of 18 (decimal).
-
-   AFSDB has the following format:
-
-   <owner> <ttl> <class> AFSDB <subtype> <hostname>
-
-   Both RDATA fields are required in all AFSDB RRs.  The <subtype> field
-   is a 16 bit integer.  The <hostname> field is a domain name of a host
-   that has a server for the cell named by the owner name of the RR.
-
-   The format of the AFSDB RR is class insensitive.  AFSDB records cause
-   type A additional section processing for <hostname>.  This, in fact,
-   is the rationale for using a new type code, rather than trying to
-   build the same functionality with TXT RRs.
-
-   Note that the format of AFSDB in a master file is identical to MX.
-   For purposes of the DNS itself, the subtype is merely an integer.
-   The present subtype semantics are discussed below, but changes are
-   possible and will be announced in subsequent RFCs.
-
-   In the case of subtype 1, the host has an AFS version 3.0 Volume
-   Location Server for the named AFS cell.  In the case of subtype 2,
-   the host has an authenticated name server holding the cell-root
-   directory node for the named DCE/NCA cell.
-
-   The use of subtypes is motivated by two considerations.  First, the
-   space of DNS RR types is limited.  Second, the services provided are
-   sufficiently distinct that it would continue to be confusing for a
-   client to attempt to connect to a cell's servers using the protocol
-   for one service, if the cell offered only the other service.
-
-   As an example of the use of this RR, suppose that the Toaster
-   Corporation has deployed AFS 3.0 but not (yet) the OSF's DCE.  Their
-   cell, named toaster.com, has three "AFS 3.0 cell database server"
-
-
-
-Everhart, Mamakos, Ullmann & Mockapetris                        [Page 2]
-
-RFC 1183                 New DNS RR Definitions             October 1990
-
-
-   machines: bigbird.toaster.com, ernie.toaster.com, and
-   henson.toaster.com.  These three machines would be listed in three
-   AFSDB RRs.  These might appear in a master file as:
-
-   toaster.com.   AFSDB   1 bigbird.toaster.com.
-   toaster.com.   AFSDB   1 ernie.toaster.com.
-   toaster.com.   AFSDB   1 henson.toaster.com.
-
-   As another example use of this RR, suppose that Femto College (domain
-   name femto.edu) has deployed DCE, and that their DCE cell root
-   directory is served by processes running on green.femto.edu and
-   turquoise.femto.edu.  Furthermore, their DCE file servers also run
-   AFS 3.0-compatible volume location servers, on the hosts
-   turquoise.femto.edu and orange.femto.edu.  These machines would be
-   listed in four AFSDB RRs, which might appear in a master file as:
-
-   femto.edu.   AFSDB   2 green.femto.edu.
-   femto.edu.   AFSDB   2 turquoise.femto.edu.
-   femto.edu.   AFSDB   1 turquoise.femto.edu.
-   femto.edu.   AFSDB   1 orange.femto.edu.
-
-2. Responsible Person
-
-   The purpose of this section is to provide a standard method for
-   associating responsible person identification to any name in the DNS.
-
-   The domain name system functions as a distributed database which
-   contains many different form of information.  For a particular name
-   or host, you can discover it's Internet address, mail forwarding
-   information, hardware type and operating system among others.
-
-   A key aspect of the DNS is that the tree-structured namespace can be
-   divided into pieces, called zones, for purposes of distributing
-   control and responsibility.  The responsible person for zone database
-   purposes is named in the SOA RR for that zone.  This section
-   describes an extension which allows different responsible persons to
-   be specified for different names in a zone.
-
-2.1. Identification of the guilty party
-
-   Often it is desirable to be able to identify the responsible entity
-   for a particular host.  When that host is down or malfunctioning, it
-   is difficult to contact those parties which might resolve or repair
-   the host.  Mail sent to POSTMASTER may not reach the person in a
-   timely fashion.  If the host is one of a multitude of workstations,
-   there may be no responsible person which can be contacted on that
-   host.
-
-
-
-
-Everhart, Mamakos, Ullmann & Mockapetris                        [Page 3]
-
-RFC 1183                 New DNS RR Definitions             October 1990
-
-
-   The POSTMASTER mailbox on that host continues to be a good contact
-   point for mail problems, and the zone contact in the SOA record for
-   database problem, but the RP record allows us to associate a mailbox
-   to entities that don't receive mail or are not directly connected
-   (namespace-wise) to the problem (e.g., GATEWAY.ISI.EDU might want to
-   point at HOTLINE@BBN.COM, and GATEWAY doesn't get mail, nor does the
-   ISI zone administrator have a clue about fixing gateways).
-
-2.2. The Responsible Person RR
-
-   The method uses a new RR type with mnemonic RP and type code of 17
-   (decimal).
-
-   RP has the following format:
-
-   <owner> <ttl> <class> RP <mbox-dname> <txt-dname>
-
-   Both RDATA fields are required in all RP RRs.
-
-   The first field, <mbox-dname>, is a domain name that specifies the
-   mailbox for the responsible person.  Its format in master files uses
-   the DNS convention for mailbox encoding, identical to that used for
-   the RNAME mailbox field in the SOA RR.  The root domain name (just
-   ".") may be specified for <mbox-dname> to indicate that no mailbox is
-   available.
-
-   The second field, <txt-dname>, is a domain name for which TXT RR's
-   exist.  A subsequent query can be performed to retrieve the
-   associated TXT resource records at <txt-dname>.  This provides a
-   level of indirection so that the entity can be referred to from
-   multiple places in the DNS.  The root domain name (just ".") may be
-   specified for <txt-dname> to indicate that the TXT_DNAME is absent,
-   and no associated TXT RR exists.
-
-   The format of the RP RR is class insensitive.  RP records cause no
-   additional section processing.  (TXT additional section processing
-   for <txt-dname> is allowed as an option, but only if it is disabled
-   for the root, i.e., ".").
-
-   The Responsible Person RR can be associated with any node in the
-   Domain Name System hierarchy, not just at the leaves of the tree.
-
-   The TXT RR associated with the TXT_DNAME contain free format text
-   suitable for humans.  Refer to [4] for more details on the TXT RR.
-
-   Multiple RP records at a single name may be present in the database.
-   They should have identical TTLs.
-
-
-
-
-Everhart, Mamakos, Ullmann & Mockapetris                        [Page 4]
-
-RFC 1183                 New DNS RR Definitions             October 1990
-
-
-   EXAMPLES
-
-   Some examples of how the RP record might be used.
-
-   sayshell.umd.edu. A     128.8.1.14
-                     MX    10 sayshell.umd.edu.
-                     HINFO NeXT UNIX
-                     WKS   128.8.1.14 tcp ftp telnet smtp
-                     RP    louie.trantor.umd.edu.  LAM1.people.umd.edu.
-
-   LAM1.people.umd.edu. TXT (
-         "Louis A. Mamakos, (301) 454-2946, don't call me at home!" )
-
-   In this example, the responsible person's mailbox for the host
-   SAYSHELL.UMD.EDU is louie@trantor.umd.edu.  The TXT RR at
-   LAM1.people.umd.edu provides additional information and advice.
-
-   TERP.UMD.EDU.    A     128.8.10.90
-                    MX    10 128.8.10.90
-                    HINFO MICROVAX-II UNIX
-                    WKS   128.8.10.90 udp domain
-                    WKS   128.8.10.90 tcp ftp telnet smtp domain
-                    RP    louie.trantor.umd.edu. LAM1.people.umd.edu.
-                    RP    root.terp.umd.edu. ops.CS.UMD.EDU.
-
-   TRANTOR.UMD.EDU. A     128.8.10.14
-                    MX    10 trantor.umd.edu.
-                    HINFO MICROVAX-II UNIX
-                    WKS   128.8.10.14 udp domain
-                    WKS   128.8.10.14 tcp ftp telnet smtp domain
-                    RP    louie.trantor.umd.edu. LAM1.people.umd.edu.
-                    RP    petry.netwolf.umd.edu. petry.people.UMD.EDU.
-                    RP    root.trantor.umd.edu. ops.CS.UMD.EDU.
-                    RP    gregh.sunset.umd.edu.  .
-
-   LAM1.people.umd.edu.  TXT   "Louis A. Mamakos (301) 454-2946"
-   petry.people.umd.edu. TXT   "Michael G. Petry (301) 454-2946"
-   ops.CS.UMD.EDU.       TXT   "CS Operations Staff (301) 454-2943"
-
-   This set of resource records has two hosts, TRANTOR.UMD.EDU and
-   TERP.UMD.EDU, as well as a number of TXT RRs.  Note that TERP.UMD.EDU
-   and TRANTOR.UMD.EDU both reference the same pair of TXT resource
-   records, although the mail box names (root.terp.umd.edu and
-   root.trantor.umd.edu) differ.
-
-   Here, we obviously care much more if the machine flakes out, as we've
-   specified four persons which might want to be notified of problems or
-   other events involving TRANTOR.UMD.EDU.  In this example, the last RP
-
-
-
-Everhart, Mamakos, Ullmann & Mockapetris                        [Page 5]
-
-RFC 1183                 New DNS RR Definitions             October 1990
-
-
-   RR for TRANTOR.UMD.EDU specifies a mailbox (gregh.sunset.umd.edu),
-   but no associated TXT RR.
-
-3. X.25 and ISDN addresses, Route Binding
-
-   This section describes an experimental representation of X.25 and
-   ISDN addresses in the DNS, as well as a route binding method,
-   analogous to the MX for mail routing, for very large scale networks.
-
-   There are several possible uses, all experimental at this time.
-   First, the RRs provide simple documentation of the correct addresses
-   to use in static configurations of IP/X.25 [11] and SMTP/X.25 [12].
-
-   The RRs could also be used automatically by an internet network-layer
-   router, typically IP.  The procedure would be to map IP address to
-   domain name, then name to canonical name if needed, then following RT
-   records, and finally attempting an IP/X.25 call to the address found.
-   Alternately, configured domain names could be resolved to identify IP
-   to X.25/ISDN bindings for a static but periodically refreshed routing
-   table.
-
-   This provides a function similar to ARP for wide area non-broadcast
-   networks that will scale well to a network with hundreds of millions
-   of hosts.
-
-   Also, a standard address binding reference will facilitate other
-   experiments in the use of X.25 and ISDN, especially in serious
-   inter-operability testing.  The majority of work in such a test is
-   establishing the n-squared entries in static tables.
-
-   Finally, the RRs are intended for use in a proposal [13] by one of
-   the authors for a possible next-generation internet.
-
-3.1. The X25 RR
-
-   The X25 RR is defined with mnemonic X25 and type code 19 (decimal).
-
-   X25 has the following format:
-
-   <owner> <ttl> <class> X25 <PSDN-address>
-
-   <PSDN-address> is required in all X25 RRs.
-
-   <PSDN-address> identifies the PSDN (Public Switched Data Network)
-   address in the X.121 [10] numbering plan associated with <owner>.
-   Its format in master files is a <character-string> syntactically
-   identical to that used in TXT and HINFO.
-
-
-
-
-Everhart, Mamakos, Ullmann & Mockapetris                        [Page 6]
-
-RFC 1183                 New DNS RR Definitions             October 1990
-
-
-   The format of X25 is class insensitive.  X25 RRs cause no additional
-   section processing.
-
-   The <PSDN-address> is a string of decimal digits, beginning with the
-   4 digit DNIC (Data Network Identification Code), as specified in
-   X.121. National prefixes (such as a 0) MUST NOT be used.
-
-   For example:
-
-   Relay.Prime.COM.  X25       311061700956
-
-3.2. The ISDN RR
-
-   The ISDN RR is defined with mnemonic ISDN and type code 20 (decimal).
-
-   An ISDN (Integrated Service Digital Network) number is simply a
-   telephone number.  The intent of the members of the CCITT is to
-   upgrade all telephone and data network service to a common service.
-
-   The numbering plan (E.163/E.164) is the same as the familiar
-   international plan for POTS (an un-official acronym, meaning Plain
-   Old Telephone Service).  In E.166, CCITT says "An E.163/E.164
-   telephony subscriber may become an ISDN subscriber without a number
-   change."
-
-   ISDN has the following format:
-
-   <owner> <ttl> <class> ISDN <ISDN-address> <sa>
-
-   The <ISDN-address> field is required; <sa> is optional.
-
-   <ISDN-address> identifies the ISDN number of <owner> and DDI (Direct
-   Dial In) if any, as defined by E.164 [8] and E.163 [7], the ISDN and
-   PSTN (Public Switched Telephone Network) numbering plan.  E.163
-   defines the country codes, and E.164 the form of the addresses.  Its
-   format in master files is a <character-string> syntactically
-   identical to that used in TXT and HINFO.
-
-   <sa> specifies the subaddress (SA).  The format of <sa> in master
-   files is a <character-string> syntactically identical to that used in
-   TXT and HINFO.
-
-   The format of ISDN is class insensitive.  ISDN RRs cause no
-   additional section processing.
-
-   The <ISDN-address> is a string of characters, normally decimal
-   digits, beginning with the E.163 country code and ending with the DDI
-   if any.  Note that ISDN, in Q.931, permits any IA5 character in the
-
-
-
-Everhart, Mamakos, Ullmann & Mockapetris                        [Page 7]
-
-RFC 1183                 New DNS RR Definitions             October 1990
-
-
-   general case.
-
-   The <sa> is a string of hexadecimal digits.  For digits 0-9, the
-   concrete encoding in the Q.931 call setup information element is
-   identical to BCD.
-
-   For example:
-
-   Relay.Prime.COM.   IN   ISDN      150862028003217
-   sh.Prime.COM.      IN   ISDN      150862028003217 004
-
-   (Note: "1" is the country code for the North American Integrated
-   Numbering Area, i.e., the system of "area codes" familiar to people
-   in those countries.)
-
-   The RR data is the ASCII representation of the digits.  It is encoded
-   as one or two <character-string>s, i.e., count followed by
-   characters.
-
-   CCITT recommendation E.166 [9] defines prefix escape codes for the
-   representation of ISDN (E.163/E.164) addresses in X.121, and PSDN
-   (X.121) addresses in E.164.  It specifies that the exact codes are a
-   "national matter", i.e., different on different networks.  A host
-   connected to the ISDN may be able to use both the X25 and ISDN
-   addresses, with the local prefix added.
-
-3.3. The Route Through RR
-
-   The Route Through RR is defined with mnemonic RT and type code 21
-   (decimal).
-
-   The RT resource record provides a route-through binding for hosts
-   that do not have their own direct wide area network addresses.  It is
-   used in much the same way as the MX RR.
-
-   RT has the following format:
-
-   <owner> <ttl> <class> RT <preference> <intermediate-host>
-
-   Both RDATA fields are required in all RT RRs.
-
-   The first field, <preference>, is a 16 bit integer, representing the
-   preference of the route.  Smaller numbers indicate more preferred
-   routes.
-
-   <intermediate-host> is the domain name of a host which will serve as
-   an intermediate in reaching the host specified by <owner>.  The DNS
-   RRs associated with <intermediate-host> are expected to include at
-
-
-
-Everhart, Mamakos, Ullmann & Mockapetris                        [Page 8]
-
-RFC 1183                 New DNS RR Definitions             October 1990
-
-
-   least one A, X25, or ISDN record.
-
-   The format of the RT RR is class insensitive.  RT records cause type
-   X25, ISDN, and A additional section processing for <intermediate-
-   host>.
-
-   For example,
-
-   sh.prime.com.      IN   RT   2    Relay.Prime.COM.
-                      IN   RT   10   NET.Prime.COM.
-   *.prime.com.       IN   RT   90   Relay.Prime.COM.
-
-   When a host is looking up DNS records to attempt to route a datagram,
-   it first looks for RT records for the destination host, which point
-   to hosts with address records (A, X25, ISDN) compatible with the wide
-   area networks available to the host.  If it is itself in the set of
-   RT records, it discards any RTs with preferences higher or equal to
-   its own.  If there are no (remaining) RTs, it can then use address
-   records of the destination itself.
-
-   Wild-card RTs are used exactly as are wild-card MXs.  RT's do not
-   "chain"; that is, it is not valid to use the RT RRs found for a host
-   referred to by an RT.
-
-   The concrete encoding is identical to the MX RR.
-
-REFERENCES and BIBLIOGRAPHY
-
-   [1] Stahl, M., "Domain Administrators Guide", RFC 1032, Network
-       Information Center, SRI International, November 1987.
-
-   [2] Lottor, M., "Domain Administrators Operations Guide", RFC 1033,
-       Network Information Center, SRI International, November, 1987.
-
-   [3] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC
-       1034, USC/Information Sciences Institute, November 1987.
-
-   [4] Mockapetris, P., "Domain Names - Implementation and
-       Specification", RFC 1035, USC/Information Sciences Institute,
-       November 1987.
-
-   [5] Spector A., and M. Kazar, "Uniting File Systems", UNIX Review,
-       7(3), pp. 61-69, March 1989.
-
-   [6] Zahn, et al., "Network Computing Architecture", Prentice-Hall,
-       1989.
-
-   [7] International Telegraph and Telephone Consultative Committee,
-
-
-
-Everhart, Mamakos, Ullmann & Mockapetris                        [Page 9]
-
-RFC 1183                 New DNS RR Definitions             October 1990
-
-
-       "Numbering Plan for the International Telephone Service", CCITT
-       Recommendations E.163., IXth Plenary Assembly, Melbourne, 1988,
-       Fascicle II.2 ("Blue Book").
-
-   [8] International Telegraph and Telephone Consultative Committee,
-       "Numbering Plan for the ISDN Era", CCITT Recommendations E.164.,
-       IXth Plenary Assembly, Melbourne, 1988, Fascicle II.2 ("Blue
-       Book").
-
-   [9] International Telegraph and Telephone Consultative Committee.
-       "Numbering Plan Interworking in the ISDN Era", CCITT
-       Recommendations E.166., IXth Plenary Assembly, Melbourne, 1988,
-       Fascicle II.2 ("Blue Book").
-
-  [10] International Telegraph and Telephone Consultative Committee,
-       "International Numbering Plan for the Public Data Networks",
-       CCITT Recommendations X.121., IXth Plenary Assembly, Melbourne,
-       1988, Fascicle VIII.3 ("Blue Book"); provisional, Geneva, 1978;
-       amended, Geneva, 1980, Malaga-Torremolinos, 1984 and Melborne,
-       1988.
-
-  [11] Korb, J., "Standard for the Transmission of IP datagrams Over
-       Public Data Networks", RFC 877, Purdue University, September
-       1983.
-
-  [12] Ullmann, R., "SMTP on X.25", RFC 1090, Prime Computer, February
-       1989.
-
-  [13] Ullmann, R., "TP/IX: The Next Internet", Prime Computer
-       (unpublished), July 1990.
-
-  [14] Mockapetris, P., "DNS Encoding of Network Names and Other Types",
-       RFC 1101, USC/Information Sciences Institute, April 1989.
-
-Security Considerations
-
-   Security issues are not addressed in this memo.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Everhart, Mamakos, Ullmann & Mockapetris                       [Page 10]
-
-RFC 1183                 New DNS RR Definitions             October 1990
-
-
-Authors' Addresses
-
-   Craig F. Everhart
-   Transarc Corporation
-   The Gulf Tower
-   707 Grant Street
-   Pittsburgh, PA  15219
-
-   Phone: +1 412 338 4467
-
-   EMail: Craig_Everhart@transarc.com
-
-
-   Louis A. Mamakos
-   Network Infrastructure Group
-   Computer Science Center
-   University of Maryland
-   College Park, MD 20742-2411
-
-   Phone: +1-301-405-7836
-
-   Email: louie@Sayshell.UMD.EDU
-
-
-   Robert Ullmann 10-30
-   Prime Computer, Inc.
-   500 Old Connecticut Path
-   Framingham, MA 01701
-
-   Phone: +1 508 620 2800 ext 1736
-
-   Email: Ariel@Relay.Prime.COM
-
-
-   Paul Mockapetris
-   USC Information Sciences Institute
-   4676 Admiralty Way
-   Marina del Rey, CA 90292
-
-   Phone: 213-822-1511
-
-   EMail: pvm@isi.edu
-
-
-
-
-
-
-
-
-
-Everhart, Mamakos, Ullmann & Mockapetris                       [Page 11]
-
\ No newline at end of file
diff --git a/contrib/bind9/doc/rfc/rfc1348.txt b/contrib/bind9/doc/rfc/rfc1348.txt
deleted file mode 100644
index d9e5dea..0000000
--- a/contrib/bind9/doc/rfc/rfc1348.txt
+++ /dev/null
@@ -1,227 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         B. Manning
-Request for Comments: 1348                               Rice University
-Updates: RFCs 1034, 1035                                       July 1992
-
-
-                              DNS NSAP RRs
-
-Status of this Memo
-
-   This memo defines an Experimental Protocol for the Internet
-   community.  Discussion and suggestions for improvement are requested.
-   Please refer to the current edition of the "IAB Official Protocol
-   Standards" for the standardization state and status of this protocol.
-   Distribution of this memo is unlimited.
-
-Table of Contents
-
-   Introduction .....................................................  1
-   Background .......................................................  1
-   NSAP RR ..........................................................  2
-   NSAP-PTR RR ......................................................  2
-   REFERENCES and BIBLIOGRAPHY ......................................  3
-   Security Considerations ..........................................  4
-   Author's Address .................................................  4
-
-Introduction
-
-   This RFC defines the format of two new Resource Records (RRs) for the
-   Domain Name System (DNS), and reserves corresponding DNS type
-   mnemonic and numerical codes.  This format may be used with the any
-   proposal that has variable length addresses, but is targeted for CLNP
-   use.
-
-   This memo assumes that the reader is familiar with the DNS [3,4].
-
-Background
-
-   This section describes an experimental representation of NSAP
-   addresses in the DNS. There are several reasons to take this approch.
-   First, it provides simple documentation of the correct addresses to
-   use in static configurations of CLNP compliant hosts and routers.
-
-   NSAP support requires that a new DNS resource record entry type
-   ("NSAP") be defined, to store longer Internet (i.e., NSAP) addresses.
-   This resource record allows mapping from DNS names to NSAP addresses,
-   and will contain entries for systems which are able to run Internet
-   applications, over TCP or UDP, over CLNP.
-
-
-
-
-Manning                                                         [Page 1]
-
-RFC 1348                      DNS NSAP RRs                     July 1992
-
-
-   The backward translation (from NSAP address to DNS name) is
-   facilitated by definition of an associated resource record. This
-   resource record is known as "NSAP-PTR", and is used in a manner
-   analogous to the existing "in-addr.arpa".
-
-   These RRs are intended for use in a proposal [6] by one of the
-   members of the NOOP WG to address the next-generation internet.
-
-The NSAP RR
-
-   The NSAP RR is defined with mnemonic NSAP and type code 22 (decimal).
-
-   An NSAP (Network Service Access Protocol) number is a unique string
-   to OSI transport service.
-
-   The numbering plan follows RFC 1237 and associated OSI definitions
-   for NSAP format.
-
-   NSAP has the following format:
-
-   <owner> <ttl> <class> NSAP <length> <NSAP-address>
-
-   All fields are required.
-
-   <length> identifies the number of octets in the <NSAP-address> as
-   defined by the various national and international authorities.
-
-   <NSAP-address> enumerates the actual octet values assigned by the
-   assigning authority.  Its format in master files is a <character-
-   string> syntactically identical to that used in TXT and HINFO.
-
-   The format of NSAP is class insensitive.  NSAP RR causes no
-   additional section processing.
-
-   For example:
-
-foo.bar.com.    IN  NSAP   21 47000580ffff000000321099991111222233334444
-host.school.de  IN  NSAP   17 39276f3100111100002222333344449876
-
-   The RR data is the ASCII representation of the digits.  It is encoded
-   as two <character-strings>, i.e., count followed by characters.
-
-The NSAP-PTR RR
-
-   The NSAP-PTR RR is defined with mnemonic NSAP-PTR and a type code 23
-   (decimal).
-
-   Its function is analogous to the PTR record used for IP addresses
-
-
-
-Manning                                                         [Page 2]
-
-RFC 1348                      DNS NSAP RRs                     July 1992
-
-
-   [4,7].
-
-   NSAP-PTR has the following format:
-
-   <NSAP-suffix> <ttl> <class> NSAP-PTR <owner>
-
-   All fields are required.
-
-   <NSAP-suffix> enumerates the actual octet values assigned by the
-   assigning authority for the LOCAL network.  Its format in master
-   files is a <character-string> syntactically identical to that used in
-   TXT and HINFO.
-
-   The format of NSAP-PTR is class insensitive.  NSAP-PTR RR causes no
-   additional section processing.
-
-   For example:
-
-   In net ff08000574.nsap-in-addr.arpa:
-
-   444433332222111199990123000000ff    NSAP-PTR   foo.bar.com.
-
-   Or in net 11110031f67293.nsap-in-addr.arpa:
-
-   67894444333322220000  NSAP-PTR        host.school.de.
-
-   The RR data is the ASCII representation of the digits.  It is encoded
-   as a <character-string>.
-
-REFERENCES and BIBLIOGRAPHY
-
-   [1] Stahl, M., "Domain Administrators Guide", RFC 1032, Network
-       Information Center, SRI International, November 1987.
-
-   [2] Lottor, M., "Domain Administrators Operations Guide", RFC 1033,
-       Network Information Center, SRI International, November, 1987.
-
-   [3] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC
-       1034, USC/Information Sciences Institute, November 1987.
-
-   [4] Mockapetris, P., "Domain Names - Implementation and
-       Specification", RFC 1035, USC/Information Sciences Institute,
-       November 1987.
-
-   [5] Colella, R., Gardner, E., and R. Callon, "Guidelines for OSI
-       NSAP Allocation in the Internet", RFC 1237, NIST, Mitre, DEC,
-       July 1991.
-
-
-
-
-Manning                                                         [Page 3]
-
-RFC 1348                      DNS NSAP RRs                     July 1992
-
-
-   [6] Callon, R., "TCP and UDP with Bigger Addresses (TUBA),
-       A Simple Proposal for Internet Addressing and Routing",
-       Digital Equipment Corporation, RFC 1347, June 1992.
-
-   [7] Mockapetris, P., "DNS Encoding of Network Names and Other Types",
-       RFC 1101, USC/Information Sciences Institute, April 1989.
-
-   [8] ISO/IEC.  Information Processing Systems -- Data Communications
-       -- Network Service Definition Addendum 2: Network Layer Address-
-       ing. International Standard 8348/Addendum 2, ISO/IEC JTC 1,
-       Switzerland, 1988.
-
-   [9] Bryant, P., "NSAPs", PB660, IPTAG/92/23, SCIENCE AND ENGINEERING
-       RESEARCH COUNCIL, RUTHERFORD APPLETON LABORATORY May 1992.
-
-Security Considerations
-
-   Security issues are not addressed in this memo.
-
-Author's Address
-
-   Bill Manning
-   Rice University - ONCS
-   PO Box 1892
-   6100 South Main
-   Houston, Texas  77251-1892
-
-   Phone: +1.713.285.5415
-   EMail: bmanning@rice.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Manning                                                         [Page 4]
-
\ No newline at end of file
diff --git a/contrib/bind9/doc/rfc/rfc1535.txt b/contrib/bind9/doc/rfc/rfc1535.txt
deleted file mode 100644
index 03bddee..0000000
--- a/contrib/bind9/doc/rfc/rfc1535.txt
+++ /dev/null
@@ -1,283 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          E. Gavron
-Request for Comments: 1535                            ACES Research Inc.
-Category: Informational                                     October 1993
-
-
-              A Security Problem and Proposed Correction
-                   With Widely Deployed DNS Software
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard.  Distribution of this memo is
-   unlimited.
-
-Abstract
-
-   This document discusses a flaw in some of the currently distributed
-   name resolver clients.  The flaw exposes a security weakness related
-   to the search heuristic invoked by these same resolvers when users
-   provide a partial domain name, and which is easy to exploit (although
-   not by the masses).  This document points out the flaw, a case in
-   point, and a solution.
-
-Background
-
-   Current Domain Name Server clients are designed to ease the burden of
-   remembering IP dotted quad addresses.  As such they translate human-
-   readable names into addresses and other resource records.  Part of
-   the translation process includes understanding and dealing with
-   hostnames that are not fully qualified domain names (FQDNs).
-
-   An absolute "rooted" FQDN is of the format {name}{.} A non "rooted"
-   domain name is of the format {name}
-
-   A domain name may have many parts and typically these include the
-   host, domain, and type.  Example:  foobar.company.com or
-   fooschool.university.edu.
-
-Flaw
-
-   The problem with most widely distributed resolvers based on the BSD
-   BIND resolver is that they attempt to resolve a partial name by
-   processing a search list of partial domains to be added to portions
-   of the specified host name until a DNS record is found.  This
-   "feature" is disabled by default in the official BIND 4.9.2 release.
-
-   Example: A TELNET attempt by    User@Machine.Tech.ACES.COM
-                             to    UnivHost.University.EDU
-
-
-
-Gavron                                                          [Page 1]
-
-RFC 1535               DNS Software Enhancements            October 1993
-
-
-   The resolver client will realize that since "UnivHost.University.EDU"
-   does not end with a ".", it is not an absolute "rooted" FQDN.  It
-   will then try the following combinations until a resource record is
-   found:
-
-                UnivHost.University.EDU.Tech.ACES.COM.
-                UnivHost.University.EDU.ACES.COM.
-                UnivHost.University.EDU.COM.
-                UnivHost.University.EDU.
-
-Security Issue
-
-   After registering the EDU.COM domain, it was discovered that an
-   unliberal application of one wildcard CNAME record would cause *all*
-   connects from any .COM site to any .EDU site to terminate at one
-   target machine in the private edu.com sub-domain.
-
-   Further, discussion reveals that specific hostnames registered in
-   this private subdomain, or any similarly named subdomain may be used
-   to spoof a host.
-
-        Example:        harvard.edu.com.        CNAME   targethost
-
-   Thus all connects to Harvard.edu from all .com sites would end up at
-   targthost, a machine which could provide a Harvard.edu login banner.
-
-   This is clearly unacceptable.  Further, it could only be made worse
-   with domains like COM.EDU, MIL.GOV, GOV.COM, etc.
-
-Public vs. Local Name Space Administration
-
-   The specification of the Domain Name System and the software that
-   implements it provides an undifferentiated hierarchy which permits
-   delegation of administration for subordinate portions of the name
-   space.  Actual administration of the name space is divided between
-   "public" and "local" portions.  Public administration pertains to all
-   top-level domains, such as .COM and .EDU.  For some domains, it also
-   pertains to some number of sub-domain levels.  The multi-level nature
-   of the public administration is most evident for top-level domains
-   for countries.  For example in the Fully Qualified Domain Name,
-   dbc.mtview.ca.us., the portion "mtview.ca.us" represents three levels
-   of public administration.  Only the left-most portion is subject to
-   local administration.
-
-
-
-
-
-
-
-
-Gavron                                                          [Page 2]
-
-RFC 1535               DNS Software Enhancements            October 1993
-
-
-   The danger of the heuristic search common in current practise is that
-   it it is possible to "intercept" the search by matching against an
-   unintended value while walking up the search list.  While this is
-   potentially dangerous at any level, it is entirely unacceptable when
-   the error impacts users outside of a local administration.
-
-   When attempting to resolve a partial domain name, DNS resolvers use
-   the Domain Name of the searching host for deriving the search list.
-   Existing DNS resolvers do not distinguish the portion of that name
-   which is in the locally administered scope from the part that is
-   publically administered.
-
-Solution(s)
-
-   At a minimum, DNS resolvers must honor the BOUNDARY between local and
-   public administration, by limiting any search lists to locally-
-   administered portions of the Domain Name space.  This requires a
-   parameter which shows the scope of the name space controlled by the
-   local administrator.
-
-   This would permit progressive searches from the most qualified to
-   less qualified up through the locally controlled domain, but not
-   beyond.
-
-   For example, if the local user were trying to reach:
-
-        User@chief.admin.DESERTU.EDU from
-        starburst,astro.DESERTU.EDU,
-
-   it is reasonable to permit the user to enter just chief.admin, and
-   for the search to cover:
-
-        chief.admin.astro.DESERTU.EDU
-        chief.admin.DESERTU.EDU
-
-   but not
-
-        chief.admin.EDU
-
-   In this case, the value of "search" should be set to "DESERTU.EDU"
-   because that's the scope of the name space controlled by the local
-   DNS administrator.
-
-   This is more than a mere optimization hack.  The local administrator
-   has control over the assignment of names within the locally
-   administered domain, so the administrator can make sure that
-   abbreviations result in the right thing.  Outside of the local
-   control, users are necessarily at risk.
-
-
-
-Gavron                                                          [Page 3]
-
-RFC 1535               DNS Software Enhancements            October 1993
-
-
-   A more stringent mechanism is implemented in BIND 4.9.2, to respond
-   to this problem:
-
-   The DNS Name resolver clients narrows its IMPLICIT search list IF ANY
-   to only try the first and the last of the examples shown.
-
-   Any additional search alternatives must be configured into the
-   resolver EXPLICITLY.
-
-   DNS Name resolver software SHOULD NOT use implicit search lists in
-   attempts to resolve partial names into absolute FQDNs other than the
-   hosts's immediate parent domain.
-
-   Resolvers which continue to use implicit search lists MUST limit
-   their scope to locally administered sub-domains.
-
-   DNS Name resolver software SHOULD NOT come pre-configured with
-   explicit search lists that perpetuate this problem.
-
-   Further, in any event where a "." exists in a specified name it
-   should be assumed to be a fully qualified domain name (FQDN) and
-   SHOULD be tried as a rooted name first.
-
-   Example:  Given  user@a.b.c.d connecting to e.f.g.h  only two tries
-             should be attempted as a result of using an implicit
-             search list:
-
-                e.f.g.h.  and e.f.g.h.b.c.d.
-
-             Given user@a.b.c.d. connecting to host those same two
-             tries would appear as:
-
-                x.b.c.d.  and x.
-
-   Some organizations make regular use of multi-part, partially
-   qualified Domain Names.  For example, host foo.loc1.org.city.state.us
-   might be used to making references to bar.loc2, or mumble.loc3, all
-   of which refer to whatever.locN.org.city.state.us
-
-   The stringent implicit search rules for BIND 4.9.2 will now cause
-   these searches to fail.  To return the ability for them to succeed,
-   configuration of the client resolvers must be changed to include an
-   explicit search rule for org.city.state.us.  That is, it must contain
-   an explicit rule for any -- and each -- portion of the locally-
-   administered sub-domain that it wishes to have as part of the search
-   list.
-
-
-
-
-
-Gavron                                                          [Page 4]
-
-RFC 1535               DNS Software Enhancements            October 1993
-
-
-References
-
-   [1] Mockapetris, P., "Domain Names Concepts and Facilities", STD 13,
-       RFC 1034, USC/Information Sciences Institute, November 1987.
-
-   [2] Mockapetris, P., "Domain Names Implementation and Specification",
-       STD 13, RFC 1035, USC/Information Sciences Institute, November
-       1987.
-
-   [3] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
-       974, CSNET CIC BBN, January 1986.
-
-   [4] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. Miller,
-       "Common DNS Implementation Errors and Suggested Fixes", RFC 1536,
-       USC/Information Sciences Institute, USC, October 1993.
-
-   [5] Beertema, P., "Common DNS Data File Configuration Errors", RFC
-       1537, CWI, October 1993.
-
-Security Considerations
-
-   This memo indicates vulnerabilities with all too-forgiving DNS
-   clients.  It points out a correction that would eliminate the future
-   potential of the problem.
-
-Author's Address
-
-   Ehud Gavron
-   ACES Research Inc.
-   PO Box 14546
-   Tucson, AZ 85711
-
-   Phone: (602) 743-9841
-   EMail: gavron@aces.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gavron                                                          [Page 5]
-
diff --git a/contrib/bind9/doc/rfc/rfc1536.txt b/contrib/bind9/doc/rfc/rfc1536.txt
deleted file mode 100644
index 5ff2b25..0000000
--- a/contrib/bind9/doc/rfc/rfc1536.txt
+++ /dev/null
@@ -1,675 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                           A. Kumar
-Request for Comments: 1536                                     J. Postel
-Category: Informational                                        C. Neuman
-                                                                     ISI
-                                                               P. Danzig
-                                                               S. Miller
-                                                                     USC
-                                                            October 1993
-
-
-          Common DNS Implementation Errors and Suggested Fixes
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard.  Distribution of this memo is
-   unlimited.
-
-Abstract
-
-   This memo describes common errors seen in DNS implementations and
-   suggests some fixes. Where applicable, violations of recommendations
-   from STD 13, RFC 1034 and STD 13, RFC 1035 are mentioned. The memo
-   also describes, where relevant, the algorithms followed in BIND
-   (versions 4.8.3 and 4.9 which the authors referred to) to serve as an
-   example.
-
-Introduction
-
-   The last few years have seen, virtually, an explosion of DNS traffic
-   on the NSFnet backbone. Various DNS implementations and various
-   versions of these implementations interact with each other, producing
-   huge amounts of unnecessary traffic. Attempts are being made by
-   researchers all over the internet, to document the nature of these
-   interactions, the symptomatic traffic patterns and to devise remedies
-   for the sick pieces of software.
-
-   This draft is an attempt to document fixes for known DNS problems so
-   people know what problems to watch out for and how to repair broken
-   software.
-
-1. Fast Retransmissions
-
-   DNS implements the classic request-response scheme of client-server
-   interaction. UDP is, therefore, the chosen protocol for communication
-   though TCP is used for zone transfers. The onus of requerying in case
-   no response is seen in a "reasonable" period of time, lies with the
-   client. Although RFC 1034 and 1035 do not recommend any
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller                          [Page 1]
-
-RFC 1536            Common DNS Implementation Errors        October 1993
-
-
-   retransmission policy, RFC 1035 does recommend that the resolvers
-   should cycle through a list of servers. Both name servers and stub
-   resolvers should, therefore, implement some kind of a retransmission
-   policy based on round trip time estimates of the name servers. The
-   client should back-off exponentially, probably to a maximum timeout
-   value.
-
-   However, clients might not implement either of the two. They might
-   not wait a sufficient amount of time before retransmitting or they
-   might not back-off their inter-query times sufficiently.
-
-   Thus, what the server would see will be a series of queries from the
-   same querying entity, spaced very close together. Of course, a
-   correctly implemented server discards all duplicate queries but the
-   queries contribute to wide-area traffic, nevertheless.
-
-   We classify a retransmission of a query as a pure Fast retry timeout
-   problem when a series of query packets meet the following conditions.
-
-      a. Query packets are seen within a time less than a "reasonable
-         waiting period" of each other.
-
-      b. No response to the original query was seen i.e., we see two or
-         more queries, back to back.
-
-      c. The query packets share the same query identifier.
-
-      d. The server eventually responds to the query.
-
-A GOOD IMPLEMENTATION:
-
-   BIND (we looked at versions 4.8.3 and 4.9) implements a good
-   retransmission algorithm which solves or limits all of these
-   problems.  The Berkeley stub-resolver queries servers at an interval
-   that starts at the greater of 4 seconds and 5 seconds divided by the
-   number of servers the resolver queries. The resolver cycles through
-   servers and at the end of a cycle, backs off the time out
-   exponentially.
-
-   The Berkeley full-service resolver (built in with the program
-   "named") starts with a time-out equal to the greater of 4 seconds and
-   two times the round-trip time estimate of the server.  The time-out
-   is backed off with each cycle, exponentially, to a ceiling value of
-   45 seconds.
-
-
-
-
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller                          [Page 2]
-
-RFC 1536            Common DNS Implementation Errors        October 1993
-
-
-FIXES:
-
-      a. Estimate round-trip times or set a reasonably high initial
-         time-out.
-
-      b. Back-off timeout periods exponentially.
-
-      c. Yet another fundamental though difficult fix is to send the
-         client an acknowledgement of a query, with a round-trip time
-         estimate.
-
-   Since UDP is used, no response is expected by the client until the
-   query is complete.  Thus, it is less likely to have information about
-   previous packets on which to estimate its back-off time.  Unless, you
-   maintain state across queries, so subsequent queries to the same
-   server use information from previous queries.  Unfortunately, such
-   estimates are likely to be inaccurate for chained requests since the
-   variance is likely to be high.
-
-   The fix chosen in the ARDP library used by Prospero is that the
-   server will send an initial acknowledgement to the client in those
-   cases where the server expects the query to take a long time (as
-   might be the case for chained queries).  This initial acknowledgement
-   can include an expected time to wait before retrying.
-
-   This fix is more difficult since it requires that the client software
-   also be trained to expect the acknowledgement packet. This, in an
-   internet of millions of hosts is at best a hard problem.
-
-2. Recursion Bugs
-
-   When a server receives a client request, it first looks up its zone
-   data and the cache to check if the query can be answered. If the
-   answer is unavailable in either place, the server seeks names of
-   servers that are more likely to have the information, in its cache or
-   zone data. It then does one of two things. If the client desires the
-   server to recurse and the server architecture allows recursion, the
-   server chains this request to these known servers closest to the
-   queried name. If the client doesn't seek recursion or if the server
-   cannot handle recursion, it returns the list of name servers to the
-   client assuming the client knows what to do with these records.
-
-   The client queries this new list of name servers to get either the
-   answer, or names of another set of name servers to query. This
-   process repeats until the client is satisfied. Servers might also go
-   through this chaining process if the server returns a CNAME record
-   for the queried name. Some servers reprocess this name to try and get
-   the desired record type.
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller                          [Page 3]
-
-RFC 1536            Common DNS Implementation Errors        October 1993
-
-
-   However, in certain cases, this chain of events may not be good. For
-   example, a broken or malicious name server might list itself as one
-   of the name servers to query again. The unsuspecting client resends
-   the same query to the same server.
-
-   In another situation, more difficult to detect, a set of servers
-   might form a loop wherein A refers to B and B refers to A. This loop
-   might involve more than two servers.
-
-   Yet another error is where the client does not know how to process
-   the list of name servers returned, and requeries the same server
-   since that is one (of the few) servers it knows.
-
-   We, therefore, classify recursion bugs into three distinct
-   categories:
-
-      a. Ignored referral: Client did not know how to handle NS records
-         in the AUTHORITY section.
-
-      b. Too many referrals: Client called on a server too many times,
-         beyond a "reasonable" number, with same query. This is
-         different from a Fast retransmission problem and a Server
-         Failure detection problem in that a response is seen for every
-         query.  Also, the identifiers are always different. It implies
-         client is in a loop and should have detected that and broken
-         it.  (RFC 1035 mentions that client should not recurse beyond
-         a certain depth.)
-
-      c. Malicious Server: a server refers to itself in the authority
-         section. If a server does not have an answer now, it is very
-         unlikely it will be any better the next time you query it,
-         specially when it claims to be authoritative over a domain.
-
-      RFC 1034 warns against such situations, on page 35.
-
-      "Bound the amount of work (packets sent, parallel processes
-       started) so that a request can't get into an infinite loop or
-       start off a chain reaction of requests or queries with other
-       implementations EVEN IF SOMEONE HAS INCORRECTLY CONFIGURED
-       SOME DATA."
-
-A GOOD IMPLEMENTATION:
-
-   BIND fixes at least one of these problems. It places an upper limit
-   on the number of recursive queries it will make, to answer a
-   question.  It chases a maximum of 20 referral links and 8 canonical
-   name translations.
-
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller                          [Page 4]
-
-RFC 1536            Common DNS Implementation Errors        October 1993
-
-
-FIXES:
-
-      a. Set an upper limit on the number of referral links and CNAME
-         links you are willing to chase.
-
-         Note that this is not guaranteed to break only recursion loops.
-         It could, in a rare case, prune off a very long search path,
-         prematurely.  We know, however, with high probability, that if
-         the number of links cross a certain metric (two times the depth
-         of the DNS tree), it is a recursion problem.
-
-      b. Watch out for self-referring servers. Avoid them whenever
-         possible.
-
-      c. Make sure you never pass off an authority NS record with your
-         own name on it!
-
-      d. Fix clients to accept iterative answers from servers not built
-         to provide recursion. Such clients should either be happy with
-         the non-authoritative answer or be willing to chase the
-         referral links themselves.
-
-3. Zero Answer Bugs:
-
-   Name servers sometimes return an authoritative NOERROR with no
-   ANSWER, AUTHORITY or ADDITIONAL records. This happens when the
-   queried name is valid but it does not have a record of the desired
-   type. Of course, the server has authority over the domain.
-
-   However, once again, some implementations of resolvers do not
-   interpret this kind of a response reasonably. They always expect an
-   answer record when they see an authoritative NOERROR. These entities
-   continue to resend their queries, possibly endlessly.
-
-A GOOD IMPLEMENTATION
-
-   BIND resolver code does not query a server more than 3 times. If it
-   is unable to get an answer from 4 servers, querying them three times
-   each, it returns error.
-
-   Of course, it treats a zero-answer response the way it should be
-   treated; with respect!
-
-FIXES:
-
-      a. Set an upper limit on the number of retransmissions for a given
-         query, at the very least.
-
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller                          [Page 5]
-
-RFC 1536            Common DNS Implementation Errors        October 1993
-
-
-      b. Fix resolvers to interpret such a response as an authoritative
-         statement of non-existence of the record type for the given
-         name.
-
-4. Inability to detect server failure:
-
-   Servers in the internet are not very reliable (they go down every
-   once in a while) and resolvers are expected to adapt to the changed
-   scenario by not querying the server for a while. Thus, when a server
-   does not respond to a query, resolvers should try another server.
-   Also, non-stub resolvers should update their round trip time estimate
-   for the server to a large value so that server is not tried again
-   before other, faster servers.
-
-   Stub resolvers, however, cycle through a fixed set of servers and if,
-   unfortunately, a server is down while others do not respond for other
-   reasons (high load, recursive resolution of query is taking more time
-   than the resolver's time-out, ....), the resolver queries the dead
-   server again! In fact, some resolvers might not set an upper limit on
-   the number of query retransmissions they will send and continue to
-   query dead servers indefinitely.
-
-   Name servers running system or chained queries might also suffer from
-   the same problem. They store names of servers they should query for a
-   given domain. They cycle through these names and in case none of them
-   answers, hit each one more than one. It is, once again, important
-   that there be an upper limit on the number of retransmissions, to
-   prevent network overload.
-
-   This behavior is clearly in violation of the dictum in RFC 1035 (page
-   46)
-
-      "If a resolver gets a server error or other bizarre response
-       from a name server, it should remove it from SLIST, and may
-       wish to schedule an immediate transmission to the next
-       candidate server address."
-
-   Removal from SLIST implies that the server is not queried again for
-   some time.
-
-   Correctly implemented full-service resolvers should, as pointed out
-   before, update round trip time values for servers that do not respond
-   and query them only after other, good servers. Full-service resolvers
-   might, however, not follow any of these common sense directives. They
-   query dead servers, and they query them endlessly.
-
-
-
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller                          [Page 6]
-
-RFC 1536            Common DNS Implementation Errors        October 1993
-
-
-A GOOD IMPLEMENTATION:
-
-   BIND places an upper limit on the number of times it queries a
-   server.  Both the stub-resolver and the full-service resolver code do
-   this.  Also, since the full-service resolver estimates round-trip
-   times and sorts name server addresses by these estimates, it does not
-   query a dead server again, until and unless all the other servers in
-   the list are dead too!  Further, BIND implements exponential back-off
-   too.
-
-FIXES:
-
-      a. Set an upper limit on number of retransmissions.
-
-      b. Measure round-trip time from servers (some estimate is better
-         than none). Treat no response as a "very large" round-trip
-         time.
-
-      c. Maintain a weighted rtt estimate and decay the "large" value
-         slowly, with time, so that the server is eventually tested
-         again, but not after an indefinitely long period.
-
-      d. Follow an exponential back-off scheme so that even if you do
-         not restrict the number of queries, you do not overload the
-         net excessively.
-
-5. Cache Leaks:
-
-   Every resource record returned by a server is cached for TTL seconds,
-   where the TTL value is returned with the RR. Full-service (or stub)
-   resolvers cache the RR and answer any queries based on this cached
-   information, in the future, until the TTL expires. After that, one
-   more query to the wide-area network gets the RR in cache again.
-
-   Full-service resolvers might not implement this caching mechanism
-   well. They might impose a limit on the cache size or might not
-   interpret the TTL value correctly. In either case, queries repeated
-   within a TTL period of a RR constitute a cache leak.
-
-A GOOD/BAD IMPLEMENTATION:
-
-   BIND has no restriction on the cache size and the size is governed by
-   the limits on the virtual address space of the machine it is running
-   on. BIND caches RRs for the duration of the TTL returned with each
-   record.
-
-   It does, however, not follow the RFCs with respect to interpretation
-   of a 0 TTL value. If a record has a TTL value of 0 seconds, BIND uses
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller                          [Page 7]
-
-RFC 1536            Common DNS Implementation Errors        October 1993
-
-
-   the minimum TTL value, for that zone, from the SOA record and caches
-   it for that duration. This, though it saves some traffic on the
-   wide-area network, is not correct behavior.
-
-FIXES:
-
-      a. Look over your caching mechanism to ensure TTLs are interpreted
-         correctly.
-
-      b. Do not restrict cache sizes (come on, memory is cheap!).
-         Expired entries are reclaimed periodically, anyway. Of course,
-         the cache size is bound to have some physical limit. But, when
-         possible, this limit should be large (run your name server on
-         a machine with a large amount of physical memory).
-
-      c. Possibly, a mechanism is needed to flush the cache, when it is
-         known or even suspected that the information has changed.
-
-6. Name Error Bugs:
-
-   This bug is very similar to the Zero Answer bug. A server returns an
-   authoritative NXDOMAIN when the queried name is known to be bad, by
-   the server authoritative for the domain, in the absence of negative
-   caching. This authoritative NXDOMAIN response is usually accompanied
-   by the SOA record for the domain, in the authority section.
-
-   Resolvers should recognize that the name they queried for was a bad
-   name and should stop querying further.
-
-   Some resolvers might, however, not interpret this correctly and
-   continue to query servers, expecting an answer record.
-
-   Some applications, in fact, prompt NXDOMAIN answers! When given a
-   perfectly good name to resolve, they append the local domain to it
-   e.g., an application in the domain "foo.bar.com", when trying to
-   resolve the name "usc.edu" first tries "usc.edu.foo.bar.com", then
-   "usc.edu.bar.com" and finally the good name "usc.edu". This causes at
-   least two queries that return NXDOMAIN, for every good query. The
-   problem is aggravated since the negative answers from the previous
-   queries are not cached.  When the same name is sought again, the
-   process repeats.
-
-   Some DNS resolver implementations suffer from this problem, too. They
-   append successive sub-parts of the local domain using an implicit
-   searchlist mechanism, when certain conditions are satisfied and try
-   the original name, only when this first set of iterations fails. This
-   behavior recently caused pandemonium in the Internet when the domain
-   "edu.com" was registered and a wildcard "CNAME" record placed at the
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller                          [Page 8]
-
-RFC 1536            Common DNS Implementation Errors        October 1993
-
-
-   top level. All machines from "com" domains trying to connect to hosts
-   in the "edu" domain ended up with connections to the local machine in
-   the "edu.com" domain!
-
-GOOD/BAD IMPLEMENTATIONS:
-
-   Some local versions of BIND already implement negative caching. They
-   typically cache negative answers with a very small TTL, sufficient to
-   answer a burst of queries spaced close together, as is typically
-   seen.
-
-   The next official public release of BIND (4.9.2) will have negative
-   caching as an ifdef'd feature.
-
-   The BIND resolver appends local domain to the given name, when one of
-   two conditions is met:
-
-      i.  The name has no periods and the flag RES_DEFNAME is set.
-      ii. There is no trailing period and the flag RES_DNSRCH is set.
-
-   The flags RES_DEFNAME and RES_DNSRCH are default resolver options, in
-   BIND, but can be changed at compile time.
-
-   Only if the name, so generated, returns an NXDOMAIN is the original
-   name tried as a Fully Qualified Domain Name. And only if it contains
-   at least one period.
-
-FIXES:
-
-      a. Fix the resolver code.
-
-      b. Negative Caching. Negative caching servers will restrict the
-         traffic seen on the wide-area network, even if not curb it
-         altogether.
-
-      c. Applications and resolvers should not append the local domain to
-         names they seek to resolve, as far as possible. Names
-         interspersed with periods should be treated as Fully Qualified
-         Domain Names.
-
-         In other words, Use searchlists only when explicitly specified.
-         No implicit searchlists should be used. A name that contains
-         any dots should first be tried as a FQDN and if that fails, with
-         the local domain name (or searchlist if specified) appended. A
-         name containing no dots can be appended with the searchlist right
-         away, but once again, no implicit searchlists should be used.
-
-
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller                          [Page 9]
-
-RFC 1536            Common DNS Implementation Errors        October 1993
-
-
-   Associated with the name error bug is another problem where a server
-   might return an authoritative NXDOMAIN, although the name is valid. A
-   secondary server, on start-up, reads the zone information from the
-   primary, through a zone transfer. While it is in the process of
-   loading the zones, it does not have information about them, although
-   it is authoritative for them.  Thus, any query for a name in that
-   domain is answered with an NXDOMAIN response code. This problem might
-   not be disastrous were it not for negative caching servers that cache
-   this answer and so propagate incorrect information over the internet.
-
-BAD IMPLEMENTATION:
-
-   BIND apparently suffers from this problem.
-
-   Also, a new name added to the primary database will take a while to
-   propagate to the secondaries. Until that time, they will return
-   NXDOMAIN answers for a good name. Negative caching servers store this
-   answer, too and aggravate this problem further. This is probably a
-   more general DNS problem but is apparently more harmful in this
-   situation.
-
-FIX:
-
-      a. Servers should start answering only after loading all the zone
-         data. A failed server is better than a server handing out
-         incorrect information.
-
-      b. Negative cache records for a very small time, sufficient only
-         to ward off a burst of requests for the same bad name. This
-         could be related to the round-trip time of the server from
-         which the negative answer was received. Alternatively, a
-         statistical measure of the amount of time for which queries
-         for such names are received could be used. Minimum TTL value
-         from the SOA record is not advisable since they tend to be
-         pretty large.
-
-      c. A "PUSH" (or, at least, a "NOTIFY") mechanism should be allowed
-         and implemented, to allow the primary server to inform
-         secondaries that the database has been modified since it last
-         transferred zone data.  To alleviate the problem of "too many
-         zone transfers" that this might cause, Incremental Zone
-         Transfers should also be part of DNS.  Also, the primary should
-         not NOTIFY/PUSH with every update but bunch a good number
-         together.
-
-
-
-
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller                         [Page 10]
-
-RFC 1536            Common DNS Implementation Errors        October 1993
-
-
-7. Format Errors:
-
-   Some resolvers issue query packets that do not necessarily conform to
-   standards as laid out in the relevant RFCs. This unnecessarily
-   increases net traffic and wastes server time.
-
-FIXES:
-
-      a. Fix resolvers.
-
-      b. Each resolver verify format of packets before sending them out,
-         using a mechanism outside of the resolver. This is, obviously,
-         needed only if step 1 cannot be followed.
-
-References
-
-   [1] Mockapetris, P., "Domain Names Concepts and Facilities", STD 13,
-       RFC 1034, USC/Information Sciences Institute, November 1987.
-
-   [2] Mockapetris, P., "Domain Names Implementation and Specification",
-       STD 13, RFC 1035, USC/Information Sciences Institute, November
-       1987.
-
-   [3] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
-       974, CSNET CIC BBN, January 1986.
-
-   [4] Gavron, E., "A Security Problem and Proposed Correction With
-       Widely Deployed DNS Software", RFC 1535, ACES Research Inc.,
-       October 1993.
-
-   [5] Beertema, P., "Common DNS Data File Configuration Errors", RFC
-       1537, CWI, October 1993.
-
-Security Considerations
-
-   Security issues are not discussed in this memo.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller                         [Page 11]
-
-RFC 1536            Common DNS Implementation Errors        October 1993
-
-
-Authors' Addresses
-
-   Anant Kumar
-   USC Information Sciences Institute
-   4676 Admiralty Way
-   Marina Del Rey CA 90292-6695
-
-   Phone:(310) 822-1511
-   FAX:  (310) 823-6741
-   EMail: anant@isi.edu
-
-
-   Jon Postel
-   USC Information Sciences Institute
-   4676 Admiralty Way
-   Marina Del Rey CA 90292-6695
-
-   Phone:(310) 822-1511
-   FAX:  (310) 823-6714
-   EMail: postel@isi.edu
-
-
-   Cliff Neuman
-   USC Information Sciences Institute
-   4676 Admiralty Way
-   Marina Del Rey CA 90292-6695
-
-   Phone:(310) 822-1511
-   FAX:  (310) 823-6714
-   EMail: bcn@isi.edu
-
-
-   Peter Danzig
-   Computer Science Department
-   University of Southern California
-   University Park
-
-   EMail: danzig@caldera.usc.edu
-
-
-   Steve Miller
-   Computer Science Department
-   University of Southern California
-   University Park
-   Los Angeles CA 90089
-
-   EMail: smiller@caldera.usc.edu
-
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller                         [Page 12]
-
diff --git a/contrib/bind9/doc/rfc/rfc1537.txt b/contrib/bind9/doc/rfc/rfc1537.txt
deleted file mode 100644
index 81b9768..0000000
--- a/contrib/bind9/doc/rfc/rfc1537.txt
+++ /dev/null
@@ -1,507 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        P. Beertema
-Request for Comments: 1537                                           CWI
-Category: Informational                                     October 1993
-
-
-               Common DNS Data File Configuration Errors
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard.  Distribution of this memo is
-   unlimited.
-
-Abstract
-
-   This memo describes errors often found in DNS data files. It points
-   out common mistakes system administrators tend to make and why they
-   often go unnoticed for long periods of time.
-
-Introduction
-
-   Due to the lack of extensive documentation and automated tools, DNS
-   zone files have mostly been configured by system administrators, by
-   hand. Some of the rules for writing the data files are rather subtle
-   and a few common mistakes are seen in domains worldwide.
-
-   This document is an attempt to list "surprises" that administrators
-   might find hidden in their zone files. It describes the symptoms of
-   the malady and prescribes medicine to cure that. It also gives some
-   general recommendations and advice on specific nameserver and zone
-   file issues and on the (proper) use of the Domain Name System.
-
-1. SOA records
-
-   A problem I've found in quite some nameservers is that the various
-   timers have been set (far) too low. Especially for top level domain
-   nameservers this causes unnecessary traffic over international and
-   intercontinental links.
-
-   Unfortunately the examples given in the BIND manual, in RFC's and in
-   some expert documents give those very short timer values, and that's
-   most likely what people have modeled their SOA records after.
-
-   First of all a short explanation of the timers used in the SOA
-   record:
-
-
-
-
-
-
-Beertema                                                        [Page 1]
-
-RFC 1537       Common DNS Data File Configuration Errors    October 1993
-
-
-        - Refresh: The SOA record of the primary server is checked
-                   every "refresh" time by the secondary servers;
-                   if it has changed, a zone transfer is done.
-
-        - Retry: If a secondary server cannot reach the primary
-                 server, it tries it again every "retry" time.
-
-        - Expire: If for "expire" time the primary server cannot
-                  be reached, all information about the zone is
-                  invalidated on the secondary servers (i.e., they
-                  are no longer authoritative for that zone).
-
-        - Minimum TTL: The default TTL value for all records in the
-                       zone file; a different TTL value may be given
-                       explicitly in a record when necessary.
-                       (This timer is named "Minimum", and that's
-                       what it's function should be according to
-                       STD 13, RFC 1035, but most (all?)
-                       implementations take it as the default value
-                       exported with records without an explicit TTL
-                       value).
-
-   For top level domain servers I would recommend the following values:
-
-          86400 ; Refresh     24 hours
-           7200 ; Retry        2 hours
-        2592000 ; Expire      30 days
-         345600 ; Minimum TTL  4 days
-
-   For other servers I would suggest:
-
-          28800 ; Refresh     8 hours
-           7200 ; Retry       2 hours
-         604800 ; Expire      7 days
-          86400 ; Minimum TTL 1 day
-
-   but here the frequency of changes, the required speed of propagation,
-   the reachability of the primary server etc. play a role in optimizing
-   the timer values.
-
-2. Glue records
-
-   Quite often, people put unnecessary glue (A) records in their zone
-   files. Even worse is that I've even seen *wrong* glue records for an
-   external host in a primary zone file! Glue records need only be in a
-   zone file if the server host is within the zone and there is no A
-   record for that host elsewhere in the zone file.
-
-
-
-
-Beertema                                                        [Page 2]
-
-RFC 1537       Common DNS Data File Configuration Errors    October 1993
-
-
-   Old BIND versions ("native" 4.8.3 and older versions) showed the
-   problem that wrong glue records could enter secondary servers in a
-   zone transfer.
-
-3. "Secondary server surprise"
-
-   I've seen it happen on various occasions that hosts got bombarded by
-   nameserver requests without knowing why. On investigation it turned
-   out then that such a host was supposed to (i.e., the information was
-   in the root servers) run secondary for some domain (or reverse (in-
-   addr.arpa)) domain, without that host's nameserver manager having
-   been asked or even been told so!
-
-   Newer BIND versions (4.9 and later) solved this problem.  At the same
-   time though the fix has the disadvantage that it's far less easy to
-   spot this problem.
-
-   Practice has shown that most domain registrars accept registrations
-   of nameservers without checking if primary (!) and secondary servers
-   have been set up, informed, or even asked.  It should also be noted
-   that a combination of long-lasting unreachability of primary
-   nameservers, (therefore) expiration of zone information, plus static
-   IP routing, can lead to massive network traffic that can fill up
-   lines completely.
-
-4. "MX records surprise"
-
-   In a sense similar to point 3. Sometimes nameserver managers enter MX
-   records in their zone files that point to external hosts, without
-   first asking or even informing the systems managers of those external
-   hosts.  This has to be fought out between the nameserver manager and
-   the systems managers involved. Only as a last resort, if really
-   nothing helps to get the offending records removed, can the systems
-   manager turn to the naming authority of the domain above the
-   offending domain to get the problem sorted out.
-
-5. "Name extension surprise"
-
-   Sometimes one encounters weird names, which appear to be an external
-   name extended with a local domain. This is caused by forgetting to
-   terminate a name with a dot: names in zone files that don't end with
-   a dot are always expanded with the name of the current zone (the
-   domain that the zone file stands for or the last $ORIGIN).
-
-   Example: zone file for foo.xx:
-
-   pqr          MX 100  relay.yy.
-   xyz          MX 100  relay.yy           (no trailing dot!)
-
-
-
-Beertema                                                        [Page 3]
-
-RFC 1537       Common DNS Data File Configuration Errors    October 1993
-
-
-   When fully written out this stands for:
-
-      pqr.foo.xx.  MX 100  relay.yy.
-      xyz.foo.xx.  MX 100  relay.yy.foo.xx.   (name extension!)
-
-6. Missing secondary servers
-
-   It is required that there be a least 2 nameservers for a domain. For
-   obvious reasons the nameservers for top level domains need to be very
-   well reachable from all over the Internet. This implies that there
-   must be more than just 2 of them; besides, most of the (secondary)
-   servers should be placed at "strategic" locations, e.g., close to a
-   point where international and/or intercontinental lines come
-   together.  To keep things manageable, there shouldn't be too many
-   servers for a domain either.
-
-   Important aspects in selecting the location of primary and secondary
-   servers are reliability (network, host) and expedient contacts: in
-   case of problems, changes/fixes must be carried out quickly.  It
-   should be considered logical that primary servers for European top
-   level domains should run on a host in Europe, preferably (if
-   possible) in the country itself. For each top level domain there
-   should be 2 secondary servers in Europe and 2 in the USA, but there
-   may of course be more on either side.  An excessive number of
-   nameservers is not a good idea though; a recommended maximum is 7
-   nameservers.  In Europe, EUnet has offered to run secondary server
-   for each European top level domain.
-
-7. Wildcard MX records
-
-   Wildcard MX records should be avoided where possible. They often
-   cause confusion and errors: especially beginning nameserver managers
-   tend to overlook the fact that a host/domain listed with ANY type of
-   record in a zone file is NOT covered by an overall wildcard MX record
-   in that zone; this goes not only for simple domain/host names, but
-   also for names that cover one or more domains. Take the following
-   example in zone foo.bar:
-
-         *            MX 100  mailhost
-         pqr          MX 100  mailhost
-         abc.def      MX 100  mailhost
-
-   This makes pqr.foo.bar, def.foo.bar and abd.def.foo.bar valid
-   domains, but the wildcard MX record covers NONE of them, nor anything
-   below them.  To cover everything by MX records, the required entries
-   are:
-
-
-
-
-
-Beertema                                                        [Page 4]
-
-RFC 1537       Common DNS Data File Configuration Errors    October 1993
-
-
-         *            MX 100  mailhost
-         pqr          MX 100  mailhost
-         *.pqr        MX 100  mailhost
-         abc.def      MX 100  mailhost
-         *.def        MX 100  mailhost
-         *.abc.def    MX 100  mailhost
-
-   An overall wildcard MX record is almost never useful.
-
-   In particular the zone file of a top level domain should NEVER
-   contain only an overall wildcard MX record (*.XX). The effect of such
-   a wildcard MX record can be that mail is unnecessarily sent across
-   possibly expensive links, only to fail at the destination or gateway
-   that the record points to. Top level domain zone files should
-   explicitly list at least all the officially registered primary
-   subdomains.
-
-   Whereas overall wildcard MX records should be avoided, wildcard MX
-   records are acceptable as an explicit part of subdomain entries,
-   provided they are allowed under a given subdomain (to be determined
-   by the naming authority for that domain).
-
-   Example:
-
-         foo.xx.      MX 100  gateway.xx.
-                      MX 200  fallback.yy.
-         *.foo.xx.    MX 100  gateway.xx.
-                      MX 200  fallback.yy.
-8. Hostnames
-
-   People appear to sometimes look only at STD 11, RFC 822 to determine
-   whether a particular hostname is correct or not. Hostnames should
-   strictly conform to the syntax given in STD 13, RFC 1034 (page 11),
-   with *addresses* in addition conforming to RFC 822. As an example
-   take "c&w.blues" which is perfectly legal according to RFC 822, but
-   which can have quite surprising effects on particular systems, e.g.,
-   "telnet c&w.blues" on a Unix system.
-
-9. HINFO records
-
-   There appears to be a common misunderstanding that one of the data
-   fields (usually the second field) in HINFO records is optional. A
-   recent scan of all reachable nameservers in only one country revealed
-   some 300 incomplete HINFO records. Specifying two data fields in a
-   HINFO record is mandatory (RFC 1033), but note that this does *not*
-   mean that HINFO records themselves are mandatory.
-
-
-
-
-
-Beertema                                                        [Page 5]
-
-RFC 1537       Common DNS Data File Configuration Errors    October 1993
-
-
-10. Safety measures and specialties
-
-   Nameservers and resolvers aren't flawless. Bogus queries should be
-   kept from being forwarded to the root servers, since they'll only
-   lead to unnecessary intercontinental traffic. Known bogus queries
-   that can easily be dealt with locally are queries for 0 and broadcast
-   addresses.  To catch such queries, every nameserver should run
-   primary for the 0.in-addr.arpa and 255.in-addr.arpa zones; the zone
-   files need only contain a SOA and an NS record.
-
-   Also each nameserver should run primary for 0.0.127.in-addr.arpa;
-   that zone file should contain a SOA and NS record and an entry:
-
-         1    PTR     localhost.
-
-   There has been extensive discussion about whether or not to append
-   the local domain to it. The conclusion was that "localhost." would be
-   the best solution; reasons given were:
-
-   - "localhost" itself is used and expected to work on some systems.
-
-   - translating 127.0.0.1 into "localhost.my_domain" can cause some
-     software to connect to itself using the loopback interface when
-     it didn't want to.
-
-   Note that all domains that contain hosts should have a "localhost" A
-   record in them.
-
-   People maintaining zone files with the Serial number given in dotted
-   decimal notation (e.g., when SCCS is used to maintain the files)
-   should beware of a bug in all BIND versions: if the serial number is
-   in Release.Version (dotted decimal) notation, then it is virtually
-   impossible to change to a higher release: because of the wrong way
-   that notation is turned into an integer, it results in a serial
-   number that is LOWER than that of the former release.
-
-   For this reason and because the Serial is an (unsigned) integer
-   according to STD 13, RFC 1035, it is recommended not to use the
-   dotted decimal notation. A recommended notation is to use the date
-   (yyyymmdd), if necessary with an extra digit (yyyymmddn) if there is
-   or can be more than one change per day in a zone file.
-
-   Very old versions of DNS resolver code have a bug that causes queries
-   for A records with domain names like "192.16.184.3" to go out. This
-   happens when users type in IP addresses and the resolver code does
-   not catch this case before sending out a DNS query. This problem has
-   been fixed in all resolver implementations known to us but if it
-   still pops up it is very serious because all those queries will go to
-
-
-
-Beertema                                                        [Page 6]
-
-RFC 1537       Common DNS Data File Configuration Errors    October 1993
-
-
-   the root servers looking for top level domains like "3" etc. It is
-   strongly recommended to install the latest (publicly) available BIND
-   version plus all available patches to get rid of these and other
-   problems.
-
-   Running secondary nameserver off another secondary nameserver is
-   possible, but not recommended unless really necessary: there are
-   known cases where it has led to problems like bogus TTL values. This
-   can be caused by older or flawed implementations, but secondary
-   nameservers in principle should always transfer their zones from the
-   official primary nameserver.
-
-11. Some general points
-
-   The Domain Name System and nameserver are purely technical tools, not
-   meant in any way to exert control or impose politics. The function of
-   a naming authority is that of a clearing house. Anyone registering a
-   subdomain under a particular (top level) domain becomes naming
-   authority and therewith the sole responsible for that subdomain.
-   Requests to enter MX or NS records concerning such a subdomain
-   therefore always MUST be honored by the registrar of the next higher
-   domain.
-
-   Examples of practices that are not allowed are:
-
-      - imposing specific mail routing (MX records) when registering
-        a subdomain.
-
-      - making registration of a subdomain dependent on to the use of
-        certain networks or services.
-
-      - using TXT records as a means of (free) commercial advertising.
-
-   In the latter case a network service provider could decide to cut off
-   a particular site until the offending TXT records have been removed
-   from the site's zone file.
-
-   Of course there are obvious cases where a naming authority can refuse
-   to register a particular subdomain and can require a proposed name to
-   be changed in order to get it registered (think of DEC trying to
-   register a domain IBM.XX).
-
-   There are also cases were one has to probe the authority of the
-   person: sending in the application - not every systems manager should
-   be able to register a domain name for a whole university.  The naming
-   authority can impose certain extra rules as long as they don't
-   violate or conflict with the rights and interest of the registrars of
-   subdomains; a top level domain registrar may e.g., require that there
-
-
-
-Beertema                                                        [Page 7]
-
-RFC 1537       Common DNS Data File Configuration Errors    October 1993
-
-
-   be primary subdomain "ac" and "co" only and that subdomains be
-   registered under those primary subdomains.
-
-   The naming authority can also interfere in exceptional cases like the
-   one mentioned in point 4, e.g., by temporarily removing a domain's
-   entry from the nameserver zone files; this of course should be done
-   only with extreme care and only as a last resort.
-
-   When adding NS records for subdomains, top level domain nameserver
-   managers should realize that the people setting up the nameserver for
-   a subdomain often are rather inexperienced and can make mistakes that
-   can easily lead to the subdomain becoming completely unreachable or
-   that can cause unnecessary DNS traffic (see point 1). It is therefore
-   highly recommended that, prior to entering such an NS record, the
-   (top level) nameserver manager does a couple of sanity checks on the
-   new nameserver (SOA record and timers OK?, MX records present where
-   needed? No obvious errors made? Listed secondary servers
-   operational?). Things that cannot be caught though by such checks
-   are:
-
-      - resolvers set up to use external hosts as nameservers
-
-      - nameservers set up to use external hosts as forwarders
-        without permission from those hosts.
-
-   Care should also be taken when registering 2-letter subdomains.
-   Although this is allowed, an implication is that abbreviated
-   addressing (see STD 11, RFC 822, paragraph 6.2.2) is not possible in
-   and under that subdomain.  When requested to register such a domain,
-   one should always notify the people of this consequence. As an
-   example take the name "cs", which is commonly used for Computer
-   Science departments: it is also the name of the top level domain for
-   Czecho-Slovakia, so within the domain cs.foo.bar the user@host.cs is
-   ambiguous in that in can denote both a user on the host
-   host.cs.foo.bar and a user on the host "host" in Czecho-Slovakia.
-   (This example does not take into account the recent political changes
-   in the mentioned country).
-
-References
-
-   [1] Mockapetris, P., "Domain Names Concepts and Facilities", STD 13,
-       RFC 1034, USC/Information Sciences Institute, November 1987.
-
-   [2] Mockapetris, P., "Domain Names Implementation and Specification",
-       STD 13, RFC 1035, USC/Information Sciences Institute, November
-       1987.
-
-
-
-
-
-Beertema                                                        [Page 8]
-
-RFC 1537       Common DNS Data File Configuration Errors    October 1993
-
-
-   [3] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
-       974, CSNET CIC BBN, January 1986.
-
-   [4] Gavron, E., "A Security Problem and Proposed Correction With
-       Widely Deployed DNS Software", RFC 1535, ACES Research Inc.,
-       October 1993.
-
-   [5] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. Miller,
-       "Common DNS Implementation Errors and Suggested Fixes", RFC 1536,
-       USC/Information Sciences Institute, USC, October 1993.
-
-Security Considerations
-
-   Security issues are not discussed in this memo.
-
-Author's Address
-
-   Piet Beertema
-   CWI
-   Kruislaan 413
-   NL-1098 SJ Amsterdam
-   The Netherlands
-
-   Phone: +31 20 592 4112
-   FAX:   +31 20 592 4199
-   EMail: Piet.Beertema@cwi.nl
-
-
-Editor's Address
-
-   Anant Kumar
-   USC Information Sciences Institute
-   4676 Admiralty Way
-   Marina Del Rey CA 90292-6695
-
-   Phone:(310) 822-1511
-   FAX:  (310) 823-6741
-   EMail: anant@isi.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-Beertema                                                        [Page 9]
-
\ No newline at end of file
diff --git a/contrib/bind9/doc/rfc/rfc1591.txt b/contrib/bind9/doc/rfc/rfc1591.txt
deleted file mode 100644
index 89e0a25..0000000
--- a/contrib/bind9/doc/rfc/rfc1591.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          J. Postel
-Request for Comments: 1591                                           ISI
-Category: Informational                                       March 1994
-
-
-              Domain Name System Structure and Delegation
-
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  This memo
-   does not specify an Internet standard of any kind.  Distribution of
-   this memo is unlimited.
-
-1. Introduction
-
-   This memo provides some information on the structure of the names in
-   the Domain Name System (DNS), specifically the top-level domain
-   names; and on the administration of domains.  The Internet Assigned
-   Numbers Authority (IANA) is the overall authority for the IP
-   Addresses, the Domain Names, and many other parameters, used in the
-   Internet.  The day-to-day responsibility for the assignment of IP
-   Addresses, Autonomous System Numbers, and most top and second level
-   Domain Names are handled by the Internet Registry (IR) and regional
-   registries.
-
-2.  The Top Level Structure of the Domain Names
-
-   In the Domain Name System (DNS) naming of computers there is a
-   hierarchy of names.  The root of system is unnamed.  There are a set
-   of what are called "top-level domain names" (TLDs).  These are the
-   generic TLDs (EDU, COM, NET, ORG, GOV, MIL, and INT), and the two
-   letter country codes from ISO-3166.  It is extremely unlikely that
-   any other TLDs will be created.
-
-   Under each TLD may be created a hierarchy of names.  Generally, under
-   the generic TLDs the structure is very flat.  That is, many
-   organizations are registered directly under the TLD, and any further
-   structure is up to the individual organizations.
-
-   In the country TLDs, there is a wide variation in the structure, in
-   some countries the structure is very flat, in others there is
-   substantial structural organization.  In some country domains the
-   second levels are generic categories (such as, AC, CO, GO, and RE),
-   in others they are based on political geography, and in still others,
-   organization names are listed directly under the country code.  The
-   organization for the US country domain is described in RFC 1480 [1].
-
-
-
-
-Postel                                                          [Page 1]
-
-RFC 1591      Domain Name System Structure and Delegation     March 1994
-
-
-   Each of the generic TLDs was created for a general category of
-   organizations.  The country code domains (for example, FR, NL, KR,
-   US) are each organized by an administrator for that country.  These
-   administrators may further delegate the management of portions of the
-   naming tree.  These administrators are performing a public service on
-   behalf of the Internet community.  Descriptions of the generic
-   domains and the US country domain follow.
-
-   Of these generic domains, five are international in nature, and two
-   are restricted to use by entities in the United States.
-
-   World Wide Generic Domains:
-
-   COM - This domain is intended for commercial entities, that is
-         companies.  This domain has grown very large and there is
-         concern about the administrative load and system performance if
-         the current growth pattern is continued.  Consideration is
-         being taken to subdivide the COM domain and only allow future
-         commercial registrations in the subdomains.
-
-   EDU - This domain was originally intended for all educational
-         institutions.  Many Universities, colleges, schools,
-         educational service organizations, and educational consortia
-         have registered here.  More recently a decision has been taken
-         to limit further registrations to 4 year colleges and
-         universities.  Schools and 2-year colleges will be registered
-         in the country domains (see US Domain, especially K12 and CC,
-         below).
-
-   NET - This domain is intended to hold only the computers of network
-         providers, that is the NIC and NOC computers, the
-         administrative computers, and the network node computers.  The
-         customers of the network provider would have domain names of
-         their own (not in the NET TLD).
-
-   ORG - This domain is intended as the miscellaneous TLD for
-         organizations that didn't fit anywhere else.  Some non-
-         government organizations may fit here.
-
-   INT - This domain is for organizations established by international
-         treaties, or international databases.
-
-   United States Only Generic Domains:
-
-   GOV - This domain was originally intended for any kind of government
-         office or agency.  More recently a decision was taken to
-         register only agencies of the US Federal government in this
-         domain.  State and local agencies are registered in the country
-
-
-
-Postel                                                          [Page 2]
-
-RFC 1591      Domain Name System Structure and Delegation     March 1994
-
-
-         domains (see US Domain, below).
-
-   MIL - This domain is used by the US military.
-
-   Example country code Domain:
-
-   US - As an example of a country domain, the US domain provides for
-        the registration of all kinds of entities in the United States
-        on the basis of political geography, that is, a hierarchy of
-        <entity-name>.<locality>.<state-code>.US.  For example,
-        "IBM.Armonk.NY.US".  In addition, branches of the US domain are
-        provided within each state for schools (K12), community colleges
-        (CC), technical schools (TEC), state government agencies
-        (STATE), councils of governments (COG),libraries (LIB), museums
-        (MUS), and several other generic types of entities (see RFC 1480
-        for details [1]).
-
-   To find a contact for a TLD use the "whois" program to access the
-   database on the host rs.internic.net.  Append "-dom" to the name of
-   TLD you are interested in.  For example:
-
-                       whois -h rs.internic.net us-dom
-      or
-                       whois -h rs.internic.net edu-dom
-
-3.  The Administration of Delegated Domains
-
-   The Internet Assigned Numbers Authority (IANA) is responsible for the
-   overall coordination and management of the Domain Name System (DNS),
-   and especially the delegation of portions of the name space called
-   top-level domains.  Most of these top-level domains are two-letter
-   country codes taken from the ISO standard 3166.
-
-   A central Internet Registry (IR) has been selected and designated to
-   handled the bulk of the day-to-day administration of the Domain Name
-   System.  Applications for new top-level domains (for example, country
-   code domains) are handled by the IR with consultation with the IANA.
-   The central IR is INTERNIC.NET.  Second level domains in COM, EDU,
-   ORG, NET, and GOV are registered by the Internet Registry at the
-   InterNIC.  The second level domains in the MIL are registered by the
-   DDN registry at NIC.DDN.MIL.  Second level names in INT are
-   registered by the PVM at ISI.EDU.
-
-   While all requests for new top-level domains must be sent to the
-   Internic (at hostmaster@internic.net), the regional registries are
-   often enlisted to assist in the administration of the DNS, especially
-   in solving problems with a country administration.  Currently, the
-   RIPE NCC is the regional registry for Europe and the APNIC is the
-
-
-
-Postel                                                          [Page 3]
-
-RFC 1591      Domain Name System Structure and Delegation     March 1994
-
-
-   regional registry for the Asia-Pacific region, while the INTERNIC
-   administers the North America region, and all the as yet undelegated
-   regions.
-
-      The contact mailboxes for these regional registries are:
-
-         INTERNIC        hostmaster@internic.net
-         APNIC           hostmaster@apnic.net
-         RIPE NCC        ncc@ripe.net
-
-   The policy concerns involved when a new top-level domain is
-   established are described in the following.  Also mentioned are
-   concerns raised when it is necessary to change the delegation of an
-   established domain from one party to another.
-
-   A new top-level domain is usually created and its management
-   delegated to a "designated manager" all at once.
-
-   Most of these same concerns are relevant when a sub-domain is
-   delegated and in general the principles described here apply
-   recursively to all delegations of the Internet DNS name space.
-
-   The major concern in selecting a designated manager for a domain is
-   that it be able to carry out the necessary responsibilities, and have
-   the ability to do a equitable, just, honest, and competent job.
-
-   1) The key requirement is that for each domain there be a designated
-      manager for supervising that domain's name space.  In the case of
-      top-level domains that are country codes this means that there is
-      a manager that supervises the domain names and operates the domain
-      name system in that country.
-
-      The manager must, of course, be on the Internet.  There must be
-      Internet Protocol (IP) connectivity to the nameservers and email
-      connectivity to the management and staff of the manager.
-
-      There must be an administrative contact and a technical contact
-      for each domain.  For top-level domains that are country codes at
-      least the administrative contact must reside in the country
-      involved.
-
-   2) These designated authorities are trustees for the delegated
-      domain, and have a duty to serve the community.
-
-      The designated manager is the trustee of the top-level domain for
-      both the nation, in the case of a country code, and the global
-      Internet community.
-
-
-
-
-Postel                                                          [Page 4]
-
-RFC 1591      Domain Name System Structure and Delegation     March 1994
-
-
-      Concerns about "rights" and "ownership" of domains are
-      inappropriate.  It is appropriate to be concerned about
-      "responsibilities" and "service" to the community.
-
-   3) The designated manager must be equitable to all groups in the
-      domain that request domain names.
-
-      This means that the same rules are applied to all requests, all
-      requests must be processed in a non-discriminatory fashion, and
-      academic and commercial (and other) users are treated on an equal
-      basis.  No bias shall be shown regarding requests that may come
-      from customers of some other business related to the manager --
-      e.g., no preferential service for customers of a particular data
-      network provider.  There can be no requirement that a particular
-      mail system (or other application), protocol, or product be used.
-
-      There are no requirements on subdomains of top-level domains
-      beyond the requirements on higher-level domains themselves.  That
-      is, the requirements in this memo are applied recursively.  In
-      particular, all subdomains shall be allowed to operate their own
-      domain name servers, providing in them whatever information the
-      subdomain manager sees fit (as long as it is true and correct).
-
-   4) Significantly interested parties in the domain should agree that
-      the designated manager is the appropriate party.
-
-      The IANA tries to have any contending parties reach agreement
-      among themselves, and generally takes no action to change things
-      unless all the contending parties agree; only in cases where the
-      designated manager has substantially mis-behaved would the IANA
-      step in.
-
-      However, it is also appropriate for interested parties to have
-      some voice in selecting the designated manager.
-
-      There are two cases where the IANA and the central IR may
-      establish a new top-level domain and delegate only a portion of
-      it: (1) there are contending parties that cannot agree, or (2) the
-      applying party may not be able to represent or serve the whole
-      country.  The later case sometimes arises when a party outside a
-      country is trying to be helpful in getting networking started in a
-      country -- this is sometimes called a "proxy" DNS service.
-
-      The Internet DNS Names Review Board (IDNB), a committee
-      established by the IANA, will act as a review panel for cases in
-      which the parties can not reach agreement among themselves.  The
-      IDNB's decisions will be binding.
-
-
-
-
-Postel                                                          [Page 5]
-
-RFC 1591      Domain Name System Structure and Delegation     March 1994
-
-
-   5) The designated manager must do a satisfactory job of operating the
-      DNS service for the domain.
-
-      That is, the actual management of the assigning of domain names,
-      delegating subdomains and operating nameservers must be done with
-      technical competence.  This includes keeping the central IR (in
-      the case of top-level domains) or other higher-level domain
-      manager advised of the status of the domain, responding to
-      requests in a timely manner, and operating the database with
-      accuracy, robustness, and resilience.
-
-      There must be a primary and a secondary nameserver that have IP
-      connectivity to the Internet and can be easily checked for
-      operational status and database accuracy by the IR and the IANA.
-
-      In cases when there are persistent problems with the proper
-      operation of a domain, the delegation may be revoked, and possibly
-      delegated to another designated manager.
-
-   6) For any transfer of the designated manager trusteeship from one
-      organization to another, the higher-level domain manager (the IANA
-      in the case of top-level domains) must receive communications from
-      both the old organization and the new organization that assure the
-      IANA that the transfer in mutually agreed, and that the new
-      organization understands its responsibilities.
-
-      It is also very helpful for the IANA to receive communications
-      from other parties that may be concerned or affected by the
-      transfer.
-
-4. Rights to Names
-
-   1) Names and Trademarks
-
-      In case of a dispute between domain name registrants as to the
-      rights to a particular name, the registration authority shall have
-      no role or responsibility other than to provide the contact
-      information to both parties.
-
-      The registration of a domain name does not have any Trademark
-      status.  It is up to the requestor to be sure he is not violating
-      anyone else's Trademark.
-
-   2) Country Codes
-
-      The IANA is not in the business of deciding what is and what is
-      not a country.
-
-
-
-
-Postel                                                          [Page 6]
-
-RFC 1591      Domain Name System Structure and Delegation     March 1994
-
-
-      The selection of the ISO 3166 list as a basis for country code
-      top-level domain names was made with the knowledge that ISO has a
-      procedure for determining which entities should be and should not
-      be on that list.
-
-5. Security Considerations
-
-   Security issues are not discussed in this memo.
-
-6. Acknowledgements
-
-   Many people have made comments on draft version of these descriptions
-   and procedures.  Steve Goldstein and John Klensin have been
-   particularly helpful.
-
-7. Author's Address
-
-   Jon Postel
-   USC/Information Sciences Institute
-   4676 Admiralty Way
-   Marina del Rey, CA  90292
-
-   Phone: 310-822-1511
-   Fax:   310-823-6714
-   EMail: Postel@ISI.EDU
-
-7. References
-
-   [1] Cooper, A., and J. Postel, "The US Domain", RFC 1480,
-       USC/Information Sciences Institute, June 1993.
-
-   [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
-       USC/Information Sciences Institute, July 1992.
-
-   [3] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
-       13, RFC 1034, USC/Information Sciences Institute, November 1987.
-
-   [4] Mockapetris, P., "Domain Names - Implementation and
-       Specification", STD 13, RFC 1035, USC/Information Sciences
-       Institute, November 1987.
-
-   [6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
-       974, CSNET CIC BBN, January 1986.
-
-   [7] Braden, R., Editor, "Requirements for Internet Hosts --
-       Application and Support", STD 3, RFC 1123, Internet Engineering
-       Task Force, October 1989.
-
-
-
-
-Postel                                                          [Page 7]
-
diff --git a/contrib/bind9/doc/rfc/rfc1611.txt b/contrib/bind9/doc/rfc/rfc1611.txt
deleted file mode 100644
index ed5b93a..0000000
--- a/contrib/bind9/doc/rfc/rfc1611.txt
+++ /dev/null
@@ -1,1683 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         R. Austein
-Request for Comments: 1611               Epilogue Technology Corporation
-Category: Standards Track                                     J. Saperia
-                                           Digital Equipment Corporation
-                                                                May 1994
-
-                       DNS Server MIB Extensions
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Table of Contents
-
-   1. Introduction ..............................................    1
-   2. The SNMPv2 Network Management Framework ...................    2
-   2.1 Object Definitions .......................................    2
-   3. Overview ..................................................    2
-   3.1 Resolvers ................................................    3
-   3.2 Name Servers .............................................    3
-   3.3 Selected Objects .........................................    4
-   3.4 Textual Conventions ......................................    4
-   4. Definitions ...............................................    5
-   5. Acknowledgements ..........................................   28
-   6. References ................................................   28
-   7. Security Considerations ...................................   29
-   8. Authors' Addresses ........................................   30
-
-1.  Introduction
-
-   This memo defines a portion of the Management Information Base (MIB)
-   for use with network management protocols in the Internet community.
-   In particular, it describes a set of extensions which instrument DNS
-   name server functions.  This memo was produced by the DNS working
-   group.
-
-   With the adoption of the Internet-standard Network Management
-   Framework [4,5,6,7], and with a large number of vendor
-   implementations of these standards in commercially available
-   products, it became possible to provide a higher level of effective
-   network management in TCP/IP-based internets than was previously
-   available.  With the growth in the use of these standards, it has
-   become possible to consider the management of other elements of the
-   infrastructure beyond the basic TCP/IP protocols.  A key element of
-
-
-
-Austein & Saperia                                               [Page 1]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-   the TCP/IP infrastructure is the DNS.
-
-   Up to this point there has been no mechanism to integrate the
-   management of the DNS with SNMP-based managers.  This memo provides
-   the mechanisms by which IP-based management stations can effectively
-   manage DNS name server software in an integrated fashion.
-
-   We have defined DNS MIB objects to be used in conjunction with the
-   Internet MIB to allow access to and control of DNS name server
-   software via SNMP by the Internet community.
-
-2.  The SNMPv2 Network Management Framework
-
-   The SNMPv2 Network Management Framework consists of four major
-   components.  They are:
-
-      o  RFC 1442 which defines the SMI, the mechanisms used for
-         describing and naming objects for the purpose of management.
-
-      o  STD 17, RFC 1213 defines MIB-II, the core set of managed objects
-         for the Internet suite of protocols.
-
-      o  RFC 1445 which defines the administrative and other architectural
-         aspects of the framework.
-
-      o  RFC 1448 which defines the protocol used for network access to
-         managed objects.
-
-      The Framework permits new objects to be defined for the purpose of
-      experimentation and evaluation.
-
-2.1.  Object Definitions
-
-   Managed objects are accessed via a virtual information store, termed
-   the Management Information Base or MIB.  Objects in the MIB are
-   defined using the subset of Abstract Syntax Notation One (ASN.1)
-   defined in the SMI.  In particular, each object object type is named
-   by an OBJECT IDENTIFIER, an administratively assigned name.  The
-   object type together with an object instance serves to uniquely
-   identify a specific instantiation of the object.  For human
-   convenience, we often use a textual string, termed the descriptor, to
-   refer to the object type.
-
-3.  Overview
-
-   In theory, the DNS world is pretty simple.  There are two kinds of
-   entities: resolvers and name servers.  Resolvers ask questions.  Name
-   servers answer them.  The real world, however, is not so simple.
-
-
-
-Austein & Saperia                                               [Page 2]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-   Implementors have made widely differing choices about how to divide
-   DNS functions between resolvers and servers.  They have also
-   constructed various sorts of exotic hybrids.  The most difficult task
-   in defining this MIB was to accommodate this wide range of entities
-   without having to come up with a separate MIB for each.
-
-   We divided up the various DNS functions into two, non-overlapping
-   classes, called "resolver functions" and "name server functions."  A
-   DNS entity that performs what we define as resolver functions
-   contains a resolver, and therefore must implement the MIB groups
-   required of all resolvers which are defined in a separate MIB Module.
-   A DNS entity which implements name server functions is considered to
-   be a name server, and must implement the MIB groups required for name
-   servers in this module.  If the same piece of software performs both
-   resolver and server functions, we imagine that it contains both a
-   resolver and a server and would thus implement both the DNS Server
-   and DNS Resolver MIBs.
-
-3.1.  Resolvers
-
-   In our model, a resolver is a program (or piece thereof) which
-   obtains resource records from servers.  Normally it does so at the
-   behest of an application, but may also do so as part of its own
-   operation.  A resolver sends DNS protocol queries and receives DNS
-   protocol replies.  A resolver neither receives queries nor sends
-   replies.  A full service resolver is one that knows how to resolve
-   queries: it obtains the needed resource records by contacting a
-   server authoritative for the records desired.  A stub resolver does
-   not know how to resolve queries: it sends all queries to a local name
-   server, setting the "recursion desired" flag to indicate that it
-   hopes that the name server will be willing to resolve the query.  A
-   resolver may (optionally) have a cache for remembering previously
-   acquired resource records.  It may also have a negative cache for
-   remembering names or data that have been determined not to exist.
-
-3.2.  Name Servers
-
-   A name server is a program (or piece thereof) that provides resource
-   records to resolvers.  All references in this document to "a name
-   server" imply "the name server's role"; in some cases the name
-   server's role and the resolver's role might be combined into a single
-   program.  A name server receives DNS protocol queries and sends DNS
-   protocol replies.  A name server neither sends queries nor receives
-   replies.  As a consequence, name servers do not have caches.
-   Normally, a name server would expect to receive only those queries to
-   which it could respond with authoritative information.  However, if a
-   name server receives a query that it cannot respond to with purely
-   authoritative information, it may choose to try to obtain the
-
-
-
-Austein & Saperia                                               [Page 3]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-   necessary additional information from a resolver which may or may not
-   be a separate process.
-
-3.3.  Selected Objects
-
-   Many of the objects included in this memo have been created from
-   information contained in the DNS specifications [1,2], as amended and
-   clarified by subsequent host requirements documents [3].  Other
-   objects have been created based on experience with existing DNS
-   management tools, expected operational needs, the statistics
-   generated by existing DNS implementations, and the configuration
-   files used by existing DNS implementations.  These objects have been
-   ordered into groups as follows:
-
-      o  Server Configuration Group
-
-      o  Server Counter Group
-
-      o  Server Optional Counter Group
-
-      o  Server Zone Group
-
-   This information has been converted into a standard form using the
-   SNMPv2 SMI defined in [9].  For the most part, the descriptions are
-   influenced by the DNS related RFCs noted above.  For example, the
-   descriptions for counters used for the various types of queries of
-   DNS records are influenced by the definitions used for the various
-   record types found in [2].
-
-3.4.  Textual Conventions
-
-   Several conceptual data types have been introduced as a textual
-   conventions in this DNS MIB document.  These additions will
-   facilitate the common understanding of information used by the DNS.
-   No changes to the SMI or the SNMP are necessary to support these
-   conventions.
-
-   Readers familiar with MIBs designed to manage entities in the lower
-   layers of the Internet protocol suite may be surprised at the number
-   of non-enumerated integers used in this MIB to represent values such
-   as DNS RR class and type numbers.  The reason for this choice is
-   simple: the DNS itself is designed as an extensible protocol,
-   allowing new classes and types of resource records to be added to the
-   protocol without recoding the core DNS software.  Using non-
-   enumerated integers to represent these data types in this MIB allows
-   the MIB to accommodate these changes as well.
-
-
-
-
-
-Austein & Saperia                                               [Page 4]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-4.  Definitions
-
-   DNS-SERVER-MIB DEFINITIONS ::= BEGIN
-
-   IMPORTS
-       mib-2
-           FROM RFC-1213
-       MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY,
-       IpAddress, Counter32, Gauge32
-           FROM SNMPv2-SMI
-       TEXTUAL-CONVENTION, RowStatus, DisplayString, TruthValue
-           FROM SNMPv2-TC
-       MODULE-COMPLIANCE, OBJECT-GROUP
-           FROM SNMPv2-CONF;
-
-   dns OBJECT-IDENTITY
-       STATUS  current
-       DESCRIPTION
-               "The OID assigned to DNS MIB work by the IANA."
-       ::= { mib-2 32 }
-
-   dnsServMIB MODULE-IDENTITY
-       LAST-UPDATED "9401282251Z"
-       ORGANIZATION "IETF DNS Working Group"
-       CONTACT-INFO
-               "       Rob Austein
-               Postal: Epilogue Technology Corporation
-                       268 Main Street, Suite 283
-                       North Reading, MA 10864
-                       US
-                  Tel: +1 617 245 0804
-                  Fax: +1 617 245 8122
-               E-Mail: sra@epilogue.com
-
-                       Jon Saperia
-               Postal: Digital Equipment Corporation
-                       110 Spit Brook Road
-                       ZKO1-3/H18
-                       Nashua, NH 03062-2698
-                       US
-                  Tel: +1 603 881 0480
-                  Fax: +1 603 881 0120
-                Email: saperia@zko.dec.com"
-       DESCRIPTION
-               "The MIB module for entities implementing the server side
-               of the Domain Name System (DNS) protocol."
-       ::= { dns 1 }
-
-
-
-
-Austein & Saperia                                               [Page 5]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-   dnsServMIBObjects       OBJECT IDENTIFIER ::= { dnsServMIB 1 }
-
-   -- (Old-style) groups in the DNS server MIB.
-
-   dnsServConfig           OBJECT IDENTIFIER ::= { dnsServMIBObjects 1 }
-   dnsServCounter          OBJECT IDENTIFIER ::= { dnsServMIBObjects 2 }
-   dnsServOptCounter       OBJECT IDENTIFIER ::= { dnsServMIBObjects 3 }
-   dnsServZone             OBJECT IDENTIFIER ::= { dnsServMIBObjects 4 }
-
-
-   -- Textual conventions
-
-   DnsName ::= TEXTUAL-CONVENTION
-       -- A DISPLAY-HINT would be nice, but difficult to express.
-       STATUS  current
-       DESCRIPTION
-               "A DNS name is a sequence of labels.  When DNS names are
-               displayed, the boundaries between labels are typically
-               indicated by dots (e.g. `Acme' and `COM' are labels in
-               the name `Acme.COM').  In the DNS protocol, however, no
-               such separators are needed because each label is encoded
-               as a length octet followed by the indicated number of
-               octets of label.  For example, `Acme.COM' is encoded as
-               the octet sequence { 4, 'A', 'c', 'm', 'e', 3, 'C', 'O',
-               'M', 0 } (the final 0 is the length of the name of the
-               root domain, which appears implicitly at the end of any
-               DNS name).  This MIB uses the same encoding as the DNS
-               protocol.
-
-               A DnsName must always be a fully qualified name.  It is
-               an error to encode a relative domain name as a DnsName
-               without first making it a fully qualified name."
-       REFERENCE
-               "RFC-1034 section 3.1."
-       SYNTAX  OCTET STRING (SIZE (0..255))
-
-   DnsNameAsIndex ::= TEXTUAL-CONVENTION
-       STATUS  current
-       DESCRIPTION
-               "This textual convention is like a DnsName, but is used
-               as an index componant in tables.  Alphabetic characters
-               in names of this type are restricted to uppercase: the
-               characters 'a' through 'z' are mapped to the characters
-               'A' through 'Z'.  This restriction is intended to make
-               the lexical ordering imposed by SNMP useful when applied
-               to DNS names.
-
-               Note that it is theoretically possible for a valid DNS
-
-
-
-Austein & Saperia                                               [Page 6]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-               name to exceed the allowed length of an SNMP object
-               identifer, and thus be impossible to represent in tables
-               in this MIB that are indexed by DNS name.  Sampling of
-               DNS names in current use on the Internet suggests that
-               this limit does not pose a serious problem in practice."
-       REFERENCE
-               "RFC-1034 section 3.1, RFC-1448 section 4.1."
-       SYNTAX  DnsName
-
-   DnsClass ::= TEXTUAL-CONVENTION
-       DISPLAY-HINT "2d"
-       STATUS  current
-       DESCRIPTION
-               "This data type is used to represent the class values
-               which appear in Resource Records in the DNS.  A 16-bit
-               unsigned integer is used to allow room for new classes
-               of records to be defined.  Existing standard classes are
-               listed in the DNS specifications."
-       REFERENCE
-               "RFC-1035 section 3.2.4."
-       SYNTAX  INTEGER (0..65535)
-
-   DnsType ::= TEXTUAL-CONVENTION
-       DISPLAY-HINT "2d"
-       STATUS  current
-       DESCRIPTION
-               "This data type is used to represent the type values
-               which appear in Resource Records in the DNS.  A 16-bit
-               unsigned integer is used to allow room for new record
-               types to be defined.  Existing standard types are listed
-               in the DNS specifications."
-       REFERENCE
-               "RFC-1035 section 3.2.2."
-       SYNTAX  INTEGER (0..65535)
-
-   DnsQClass ::= TEXTUAL-CONVENTION
-       DISPLAY-HINT "2d"
-       STATUS  current
-       DESCRIPTION
-               "This data type is used to represent the QClass values
-               which appear in Resource Records in the DNS.  A 16-bit
-               unsigned integer is used to allow room for new QClass
-               records to be defined.  Existing standard QClasses are
-               listed in the DNS specification."
-       REFERENCE
-               "RFC-1035 section 3.2.5."
-       SYNTAX  INTEGER (0..65535)
-
-
-
-
-Austein & Saperia                                               [Page 7]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-   DnsQType ::= TEXTUAL-CONVENTION
-       DISPLAY-HINT "2d"
-       STATUS  current
-       DESCRIPTION
-               "This data type is used to represent the QType values
-               which appear in Resource Records in the DNS.  A 16-bit
-               unsigned integer is used to allow room for new QType
-               records to be defined.  Existing standard QTypes are
-               listed in the DNS specification."
-       REFERENCE
-               "RFC-1035 section 3.2.3."
-       SYNTAX  INTEGER (0..65535)
-
-   DnsTime ::= TEXTUAL-CONVENTION
-       DISPLAY-HINT "4d"
-       STATUS  current
-       DESCRIPTION
-               "DnsTime values are 32-bit unsigned integers which
-               measure time in seconds."
-       REFERENCE
-               "RFC-1035."
-       SYNTAX  Gauge32
-
-
-   DnsOpCode ::= TEXTUAL-CONVENTION
-       STATUS  current
-       DESCRIPTION
-               "This textual convention is used to represent the DNS
-               OPCODE values used in the header section of DNS
-               messages.  Existing standard OPCODE values are listed in
-               the DNS specifications."
-       REFERENCE
-               "RFC-1035 section 4.1.1."
-       SYNTAX  INTEGER (0..15)
-
-   DnsRespCode ::= TEXTUAL-CONVENTION
-       STATUS  current
-       DESCRIPTION
-               "This data type is used to represent the DNS RCODE value
-               in DNS response messages.  Existing standard RCODE
-               values are listed in the DNS specifications."
-       REFERENCE
-               "RFC-1035 section 4.1.1."
-       SYNTAX  INTEGER (0..15)
-
-
-
-
-
-
-
-Austein & Saperia                                               [Page 8]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-   -- Server Configuration Group
-
-   dnsServConfigImplementIdent OBJECT-TYPE
-       SYNTAX      DisplayString
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "The implementation identification string for the DNS
-               server software in use on the system, for example;
-               `FNS-2.1'"
-       ::= { dnsServConfig 1 }
-
-   dnsServConfigRecurs  OBJECT-TYPE
-       SYNTAX      INTEGER { available(1),
-                             restricted(2),
-                             unavailable(3) }
-       MAX-ACCESS  read-write
-       STATUS      current
-       DESCRIPTION
-               "This represents the recursion services offered by this
-               name server.  The values that can be read or written
-               are:
-
-               available(1) - performs recursion on requests from
-               clients.
-
-               restricted(2) - recursion is performed on requests only
-               from certain clients, for example; clients on an access
-               control list.
-
-               unavailable(3) - recursion is not available."
-        ::= { dnsServConfig 2 }
-
-   dnsServConfigUpTime OBJECT-TYPE
-       SYNTAX      DnsTime
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "If the server has a persistent state (e.g., a process),
-               this value will be the time elapsed since it started.
-               For software without persistant state, this value will
-               be zero."
-       ::= { dnsServConfig 3 }
-
-   dnsServConfigResetTime OBJECT-TYPE
-       SYNTAX      DnsTime
-       MAX-ACCESS  read-only
-       STATUS      current
-
-
-
-Austein & Saperia                                               [Page 9]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-       DESCRIPTION
-               "If the server has a persistent state (e.g., a process)
-               and supports a `reset' operation (e.g., can be told to
-               re-read configuration files), this value will be the
-               time elapsed since the last time the name server was
-               `reset.'  For software that does not have persistence or
-               does not support a `reset' operation, this value will be
-               zero."
-       ::= { dnsServConfig 4 }
-
-   dnsServConfigReset OBJECT-TYPE
-       SYNTAX      INTEGER { other(1),
-                             reset(2),
-                             initializing(3),
-                             running(4) }
-       MAX-ACCESS  read-write
-       STATUS      current
-       DESCRIPTION
-               "Status/action object to reinitialize any persistant name
-               server state.  When set to reset(2), any persistant
-               name server state (such as a process) is reinitialized as
-               if the name server had just been started.  This value
-               will never be returned by a read operation.  When read,
-               one of the following values will be returned:
-                   other(1) - server in some unknown state;
-                   initializing(3) - server (re)initializing;
-                   running(4) - server currently running."
-       ::= { dnsServConfig 5 }
-
-
-   -- Server Counter Group
-
-   dnsServCounterAuthAns OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of queries which were authoritatively answered."
-       ::= { dnsServCounter 2 }
-
-   dnsServCounterAuthNoNames OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of queries for which `authoritative no such name'
-               responses were made."
-       ::= { dnsServCounter 3 }
-
-
-
-Austein & Saperia                                              [Page 10]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-   dnsServCounterAuthNoDataResps OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of queries for which `authoritative no such data'
-               (empty answer) responses were made."
-       ::= { dnsServCounter 4 }
-
-   dnsServCounterNonAuthDatas OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of queries which were non-authoritatively
-               answered (cached data)."
-       ::= { dnsServCounter 5 }
-
-   dnsServCounterNonAuthNoDatas OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of queries which were non-authoritatively
-               answered with no data (empty answer)."
-       ::= { dnsServCounter 6 }
-
-   dnsServCounterReferrals OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests that were referred to other servers."
-       ::= { dnsServCounter 7 }
-
-   dnsServCounterErrors OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests the server has processed that were
-               answered with errors (RCODE values other than 0 and 3)."
-       REFERENCE
-               "RFC-1035 section 4.1.1."
-       ::= { dnsServCounter 8 }
-
-   dnsServCounterRelNames OBJECT-TYPE
-       SYNTAX      Counter32
-
-
-
-Austein & Saperia                                              [Page 11]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests received by the server for names that
-               are only 1 label long (text form - no internal dots)."
-       ::= { dnsServCounter 9 }
-
-   dnsServCounterReqRefusals OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of DNS requests refused by the server."
-       ::= { dnsServCounter 10 }
-
-   dnsServCounterReqUnparses OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests received which were unparseable."
-       ::= { dnsServCounter 11 }
-
-   dnsServCounterOtherErrors OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests which were aborted for other (local)
-               server errors."
-       ::= { dnsServCounter 12 }
-
-   -- DNS Server Counter Table
-
-   dnsServCounterTable OBJECT-TYPE
-       SYNTAX      SEQUENCE OF DnsServCounterEntry
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "Counter information broken down by DNS class and type."
-       ::= { dnsServCounter 13 }
-
-   dnsServCounterEntry OBJECT-TYPE
-       SYNTAX      DnsServCounterEntry
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "This table contains count information for each DNS class
-
-
-
-Austein & Saperia                                              [Page 12]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-               and type value known to the server.  The index allows
-               management software to to create indices to the table to
-               get the specific information desired, e.g., number of
-               queries over UDP for records with type value `A' which
-               came to this server.  In order to prevent an
-               uncontrolled expansion of rows in the table; if
-               dnsServCounterRequests is 0 and dnsServCounterResponses
-               is 0, then the row does not exist and `no such' is
-               returned when the agent is queried for such instances."
-       INDEX     { dnsServCounterOpCode,
-                   dnsServCounterQClass,
-                   dnsServCounterQType,
-                   dnsServCounterTransport }
-       ::= { dnsServCounterTable 1 }
-
-   DnsServCounterEntry ::=
-       SEQUENCE {
-           dnsServCounterOpCode
-               DnsOpCode,
-           dnsServCounterQClass
-               DnsClass,
-           dnsServCounterQType
-               DnsType,
-           dnsServCounterTransport
-               INTEGER,
-           dnsServCounterRequests
-               Counter32,
-           dnsServCounterResponses
-               Counter32
-           }
-
-   dnsServCounterOpCode OBJECT-TYPE
-       SYNTAX      DnsOpCode
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "The DNS OPCODE being counted in this row of the table."
-       ::= { dnsServCounterEntry 1 }
-
-   dnsServCounterQClass OBJECT-TYPE
-       SYNTAX      DnsClass
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "The class of record being counted in this row of the
-               table."
-       ::= { dnsServCounterEntry 2 }
-
-
-
-
-Austein & Saperia                                              [Page 13]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-   dnsServCounterQType OBJECT-TYPE
-       SYNTAX      DnsType
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "The type of record which is being counted in this row in
-               the table."
-       ::= { dnsServCounterEntry 3 }
-
-   dnsServCounterTransport OBJECT-TYPE
-       SYNTAX      INTEGER { udp(1), tcp(2), other(3) }
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "A value of udp(1) indicates that the queries reported on
-               this row were sent using UDP.
-
-               A value of tcp(2) indicates that the queries reported on
-               this row were sent using TCP.
-
-               A value of other(3) indicates that the queries reported
-               on this row were sent using a transport that was neither
-               TCP nor UDP."
-       ::= { dnsServCounterEntry 4 }
-
-   dnsServCounterRequests OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests (queries) that have been recorded in
-               this row of the table."
-       ::= { dnsServCounterEntry 5 }
-
-   dnsServCounterResponses OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of responses made by the server since
-               initialization for the kind of query identified on this
-               row of the table."
-       ::= { dnsServCounterEntry 6 }
-
-
-
-
-
-
-
-
-Austein & Saperia                                              [Page 14]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-   -- Server Optional Counter Group
-
-   -- The Server Optional Counter Group is intended for those systems
-   -- which make distinctions between the different sources of the DNS
-   -- queries as defined below.
-   --
-   -- Objects in this group are implemented on servers which distinguish
-   -- between queries which originate from the same host as the server,
-   -- queries from one of an arbitrary group of hosts that are on an
-   -- access list defined by the server, and queries from hosts that do
-   -- not fit either of these descriptions.
-   --
-   -- The objects found in the Server Counter group are totals.  Thus if
-   -- one wanted to identify, for example, the number of queries from
-   -- `remote' hosts which have been given authoritative answers, one
-   -- would subtract the current values of ServOptCounterFriendsAuthAns
-   -- and ServOptCounterSelfAuthAns from servCounterAuthAns.
-   --
-   -- The purpose of these distinctions is to allow for implementations
-   -- to group queries and responses on this basis.  One way in which
-   -- servers may make these distinctions is by looking at the source IP
-   -- address of the DNS query.  If the source of the query is `your
-   -- own' then the query should be counted as `yourself' (local host).
-   -- If the source of the query matches an `access list,' the query
-   -- came from a friend.  What constitutes an `access list' is
-   -- implementation dependent and could be as simple as a rule that all
-   -- hosts on the same IP network as the DNS server are classed
-   -- `friends.'
-   --
-   -- In order to avoid double counting, the following rules apply:
-   --
-   -- 1. No host is in more than one of the three groups defined above.
-   --
-   -- 2. All queries from the local host are always counted in the
-   --    `yourself' group regardless of what the access list, if any,
-   --    says.
-   --
-   -- 3. The access list should not define `your friends' in such a way
-   --    that it includes all hosts.   That is, not everybody is your
-   --    `friend.'
-
-   dnsServOptCounterSelfAuthAns OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests the server has processed which
-               originated from a resolver on the same host for which
-
-
-
-Austein & Saperia                                              [Page 15]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-               there has been an authoritative answer."
-       ::= { dnsServOptCounter 1 }
-
-   dnsServOptCounterSelfAuthNoNames OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests the server has processed which
-               originated from a resolver on the same host for which
-               there has been an authoritative no such name answer
-               given."
-       ::= { dnsServOptCounter 2 }
-
-   dnsServOptCounterSelfAuthNoDataResps OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests the server has processed which
-               originated from a resolver on the same host for which
-               there has been an authoritative no such data answer
-               (empty answer) made."
-       ::= { dnsServOptCounter 3 }
-
-   dnsServOptCounterSelfNonAuthDatas OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests the server has processed which
-               originated from a resolver on the same host for which a
-               non-authoritative answer (cached data) was made."
-       ::= { dnsServOptCounter 4 }
-
-   dnsServOptCounterSelfNonAuthNoDatas OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests the server has processed which
-               originated from a resolver on the same host for which a
-               `non-authoritative, no such data' response was made
-               (empty answer)."
-       ::= { dnsServOptCounter 5 }
-
-   dnsServOptCounterSelfReferrals OBJECT-TYPE
-       SYNTAX      Counter32
-
-
-
-Austein & Saperia                                              [Page 16]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of queries the server has processed which
-               originated from a resolver on the same host and were
-               referred to other servers."
-       ::= { dnsServOptCounter 6 }
-
-   dnsServOptCounterSelfErrors OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests the server has processed which
-               originated from a resolver on the same host which have
-               been answered with errors (RCODEs other than 0 and 3)."
-       REFERENCE
-               "RFC-1035 section 4.1.1."
-       ::= { dnsServOptCounter 7 }
-
-   dnsServOptCounterSelfRelNames OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests received for names that are only 1
-               label long (text form - no internal dots) the server has
-               processed which originated from a resolver on the same
-               host."
-       ::= { dnsServOptCounter 8 }
-
-   dnsServOptCounterSelfReqRefusals OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of DNS requests refused by the server which
-               originated from a resolver on the same host."
-       ::= { dnsServOptCounter 9 }
-
-   dnsServOptCounterSelfReqUnparses OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests received which were unparseable and
-               which originated from a resolver on the same host."
-       ::= { dnsServOptCounter 10 }
-
-
-
-Austein & Saperia                                              [Page 17]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-   dnsServOptCounterSelfOtherErrors OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests which were aborted for other (local)
-               server errors and which originated on the same host."
-       ::= { dnsServOptCounter 11 }
-
-   dnsServOptCounterFriendsAuthAns OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of queries originating from friends which were
-               authoritatively answered.  The definition of friends is
-               a locally defined matter."
-       ::= { dnsServOptCounter 12 }
-
-   dnsServOptCounterFriendsAuthNoNames OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of queries originating from friends, for which
-               authoritative `no such name' responses were made.  The
-               definition of friends is a locally defined matter."
-       ::= { dnsServOptCounter 13 }
-
-   dnsServOptCounterFriendsAuthNoDataResps OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of queries originating from friends for which
-               authoritative no such data (empty answer) responses were
-               made.  The definition of friends is a locally defined
-               matter."
-       ::= { dnsServOptCounter 14 }
-
-   dnsServOptCounterFriendsNonAuthDatas OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of queries originating from friends which were
-               non-authoritatively answered (cached data). The
-               definition of friends is a locally defined matter."
-
-
-
-Austein & Saperia                                              [Page 18]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-       ::= { dnsServOptCounter 15 }
-
-   dnsServOptCounterFriendsNonAuthNoDatas OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of queries originating from friends which were
-               non-authoritatively answered with no such data (empty
-               answer)."
-       ::= { dnsServOptCounter 16 }
-
-   dnsServOptCounterFriendsReferrals OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests which originated from friends that
-               were referred to other servers.  The definition of
-               friends is a locally defined matter."
-       ::= { dnsServOptCounter 17 }
-
-   dnsServOptCounterFriendsErrors OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests the server has processed which
-               originated from friends and were answered with errors
-               (RCODE values other than 0 and 3).  The definition of
-               friends is a locally defined matter."
-       REFERENCE
-               "RFC-1035 section 4.1.1."
-       ::= { dnsServOptCounter 18 }
-
-   dnsServOptCounterFriendsRelNames OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests received for names from friends that
-               are only 1 label long (text form - no internal dots) the
-               server has processed."
-       ::= { dnsServOptCounter 19 }
-
-   dnsServOptCounterFriendsReqRefusals OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-
-
-
-Austein & Saperia                                              [Page 19]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-       STATUS      current
-       DESCRIPTION
-               "Number of DNS requests refused by the server which were
-               received from `friends'."
-       ::= { dnsServOptCounter 20 }
-
-   dnsServOptCounterFriendsReqUnparses OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests received which were unparseable and
-               which originated from `friends'."
-       ::= { dnsServOptCounter 21 }
-
-   dnsServOptCounterFriendsOtherErrors OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests which were aborted for other (local)
-               server errors and which originated from `friends'."
-       ::= { dnsServOptCounter 22 }
-
-
-   -- Server Zone Group
-
-   -- DNS Management Zone Configuration Table
-
-   -- This table contains zone configuration information.
-
-   dnsServZoneTable OBJECT-TYPE
-       SYNTAX      SEQUENCE OF DnsServZoneEntry
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "Table of zones for which this name server provides
-               information.  Each of the zones may be loaded from stable
-               storage via an implementation-specific mechanism or may
-               be obtained from another name server via a zone transfer.
-
-               If name server doesn't load any zones, this table is
-               empty."
-       ::= { dnsServZone 1 }
-
-   dnsServZoneEntry OBJECT-TYPE
-       SYNTAX      DnsServZoneEntry
-       MAX-ACCESS  not-accessible
-
-
-
-Austein & Saperia                                              [Page 20]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-       STATUS      current
-       DESCRIPTION
-               "An entry in the name server zone table.  New rows may be
-               added either via SNMP or by the name server itself."
-       INDEX     { dnsServZoneName,
-                   dnsServZoneClass }
-       ::= { dnsServZoneTable 1 }
-
-   DnsServZoneEntry ::=
-       SEQUENCE {
-           dnsServZoneName
-               DnsNameAsIndex,
-           dnsServZoneClass
-               DnsClass,
-           dnsServZoneLastReloadSuccess
-               DnsTime,
-           dnsServZoneLastReloadAttempt
-               DnsTime,
-           dnsServZoneLastSourceAttempt
-               IpAddress,
-           dnsServZoneStatus
-               RowStatus,
-           dnsServZoneSerial
-               Counter32,
-           dnsServZoneCurrent
-               TruthValue,
-           dnsServZoneLastSourceSuccess
-               IpAddress
-       }
-
-   dnsServZoneName OBJECT-TYPE
-       SYNTAX      DnsNameAsIndex
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "DNS name of the zone described by this row of the table.
-               This is the owner name of the SOA RR that defines the
-               top of the zone. This is name is in uppercase:
-               characters 'a' through 'z' are mapped to 'A' through 'Z'
-               in order to make the lexical ordering useful."
-       ::= { dnsServZoneEntry 1 }
-
-   dnsServZoneClass OBJECT-TYPE
-       SYNTAX      DnsClass
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "DNS class of the RRs in this zone."
-
-
-
-Austein & Saperia                                              [Page 21]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-       ::= { dnsServZoneEntry 2 }
-
-   dnsServZoneLastReloadSuccess OBJECT-TYPE
-       SYNTAX      DnsTime
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Elapsed time in seconds since last successful reload of
-               this zone."
-       ::= { dnsServZoneEntry 3 }
-
-   dnsServZoneLastReloadAttempt OBJECT-TYPE
-       SYNTAX      DnsTime
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Elapsed time in seconds since last attempted reload of
-               this zone."
-       ::= { dnsServZoneEntry 4 }
-
-   dnsServZoneLastSourceAttempt OBJECT-TYPE
-       SYNTAX      IpAddress
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "IP address of host from which most recent zone transfer
-               of this zone was attempted.  This value should match the
-               value of dnsServZoneSourceSuccess if the attempt was
-               succcessful.  If zone transfer has not been attempted
-               within the memory of this name server, this value should
-               be 0.0.0.0."
-       ::= { dnsServZoneEntry 5 }
-
-   dnsServZoneStatus OBJECT-TYPE
-       SYNTAX      RowStatus
-       MAX-ACCESS  read-create
-       STATUS      current
-       DESCRIPTION
-               "The status of the information represented in this row of
-               the table."
-       ::= { dnsServZoneEntry 6 }
-
-   dnsServZoneSerial OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Zone serial number (from the SOA RR) of the zone
-
-
-
-Austein & Saperia                                              [Page 22]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-               represented by this row of the table.  If the zone has
-               not been successfully loaded within the memory of this
-               name server, the value of this variable is zero."
-       ::= { dnsServZoneEntry 7 }
-
-   dnsServZoneCurrent OBJECT-TYPE
-       SYNTAX      TruthValue
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Whether the server's copy of the zone represented by
-               this row of the table is currently valid.  If the zone
-               has never been successfully loaded or has expired since
-               it was last succesfully loaded, this variable will have
-               the value false(2), otherwise this variable will have
-               the value true(1)."
-       ::= { dnsServZoneEntry 8 }
-
-   dnsServZoneLastSourceSuccess OBJECT-TYPE
-       SYNTAX      IpAddress
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "IP address of host which was the source of the most
-               recent successful zone transfer for this zone.  If
-               unknown (e.g., zone has never been successfully
-               transfered) or irrelevant (e.g., zone was loaded from
-               stable storage), this value should be 0.0.0.0."
-       ::= { dnsServZoneEntry 9 }
-
-   -- DNS Zone Source Table
-
-   dnsServZoneSrcTable OBJECT-TYPE
-       SYNTAX      SEQUENCE OF DnsServZoneSrcEntry
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "This table is a list of IP addresses from which the
-               server will attempt to load zone information using DNS
-               zone transfer operations.  A reload may occur due to SNMP
-               operations that create a row in dnsServZoneTable or a
-               SET to object dnsServZoneReload.  This table is only
-               used when the zone is loaded via zone transfer."
-       ::= { dnsServZone 2 }
-
-   dnsServZoneSrcEntry OBJECT-TYPE
-       SYNTAX      DnsServZoneSrcEntry
-       MAX-ACCESS  not-accessible
-
-
-
-Austein & Saperia                                              [Page 23]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-       STATUS      current
-       DESCRIPTION
-               "An entry in the name server zone source table."
-       INDEX     { dnsServZoneSrcName,
-                   dnsServZoneSrcClass,
-                   dnsServZoneSrcAddr }
-       ::= { dnsServZoneSrcTable 1 }
-
-   DnsServZoneSrcEntry ::=
-       SEQUENCE {
-           dnsServZoneSrcName
-               DnsNameAsIndex,
-           dnsServZoneSrcClass
-               DnsClass,
-           dnsServZoneSrcAddr
-               IpAddress,
-           dnsServZoneSrcStatus
-               RowStatus
-       }
-
-   dnsServZoneSrcName OBJECT-TYPE
-       SYNTAX      DnsNameAsIndex
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "DNS name of the zone to which this entry applies."
-       ::= { dnsServZoneSrcEntry 1 }
-
-   dnsServZoneSrcClass OBJECT-TYPE
-       SYNTAX      DnsClass
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "DNS class of zone to which this entry applies."
-       ::= { dnsServZoneSrcEntry 2 }
-
-   dnsServZoneSrcAddr OBJECT-TYPE
-       SYNTAX      IpAddress
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "IP address of name server host from which this zone
-               might be obtainable."
-       ::= { dnsServZoneSrcEntry 3 }
-
-   dnsServZoneSrcStatus OBJECT-TYPE
-       SYNTAX      RowStatus
-       MAX-ACCESS  read-create
-
-
-
-Austein & Saperia                                              [Page 24]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-       STATUS      current
-       DESCRIPTION
-               "The status of the information represented in this row of
-               the table."
-       ::= { dnsServZoneSrcEntry 4 }
-
-
-   -- SNMPv2 groups.
-
-   dnsServMIBGroups        OBJECT IDENTIFIER ::= { dnsServMIB 2 }
-
-   dnsServConfigGroup OBJECT-GROUP
-       OBJECTS   { dnsServConfigImplementIdent,
-                   dnsServConfigRecurs,
-                   dnsServConfigUpTime,
-                   dnsServConfigResetTime,
-                   dnsServConfigReset }
-       STATUS      current
-       DESCRIPTION
-               "A collection of objects providing basic configuration
-               control of a DNS name server."
-       ::= { dnsServMIBGroups 1 }
-
-   dnsServCounterGroup OBJECT-GROUP
-       OBJECTS   { dnsServCounterAuthAns,
-                   dnsServCounterAuthNoNames,
-                   dnsServCounterAuthNoDataResps,
-                   dnsServCounterNonAuthDatas,
-                   dnsServCounterNonAuthNoDatas,
-                   dnsServCounterReferrals,
-                   dnsServCounterErrors,
-                   dnsServCounterRelNames,
-                   dnsServCounterReqRefusals,
-                   dnsServCounterReqUnparses,
-                   dnsServCounterOtherErrors,
-                   dnsServCounterOpCode,
-                   dnsServCounterQClass,
-                   dnsServCounterQType,
-                   dnsServCounterTransport,
-                   dnsServCounterRequests,
-                   dnsServCounterResponses }
-       STATUS      current
-       DESCRIPTION
-               "A collection of objects providing basic instrumentation
-               of a DNS name server."
-       ::= { dnsServMIBGroups 2 }
-
-
-
-
-
-Austein & Saperia                                              [Page 25]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-   dnsServOptCounterGroup OBJECT-GROUP
-       OBJECTS   { dnsServOptCounterSelfAuthAns,
-                   dnsServOptCounterSelfAuthNoNames,
-                   dnsServOptCounterSelfAuthNoDataResps,
-                   dnsServOptCounterSelfNonAuthDatas,
-                   dnsServOptCounterSelfNonAuthNoDatas,
-                   dnsServOptCounterSelfReferrals,
-                   dnsServOptCounterSelfErrors,
-                   dnsServOptCounterSelfRelNames,
-                   dnsServOptCounterSelfReqRefusals,
-                   dnsServOptCounterSelfReqUnparses,
-                   dnsServOptCounterSelfOtherErrors,
-                   dnsServOptCounterFriendsAuthAns,
-                   dnsServOptCounterFriendsAuthNoNames,
-                   dnsServOptCounterFriendsAuthNoDataResps,
-                   dnsServOptCounterFriendsNonAuthDatas,
-                   dnsServOptCounterFriendsNonAuthNoDatas,
-                   dnsServOptCounterFriendsReferrals,
-                   dnsServOptCounterFriendsErrors,
-                   dnsServOptCounterFriendsRelNames,
-                   dnsServOptCounterFriendsReqRefusals,
-                   dnsServOptCounterFriendsReqUnparses,
-                   dnsServOptCounterFriendsOtherErrors }
-       STATUS      current
-       DESCRIPTION
-               "A collection of objects providing extended
-               instrumentation of a DNS name server."
-       ::= { dnsServMIBGroups 3 }
-
-   dnsServZoneGroup OBJECT-GROUP
-       OBJECTS   { dnsServZoneName,
-                   dnsServZoneClass,
-                   dnsServZoneLastReloadSuccess,
-                   dnsServZoneLastReloadAttempt,
-                   dnsServZoneLastSourceAttempt,
-                   dnsServZoneLastSourceSuccess,
-                   dnsServZoneStatus,
-                   dnsServZoneSerial,
-                   dnsServZoneCurrent,
-                   dnsServZoneSrcName,
-                   dnsServZoneSrcClass,
-                   dnsServZoneSrcAddr,
-                   dnsServZoneSrcStatus }
-       STATUS      current
-       DESCRIPTION
-               "A collection of objects providing configuration control
-               of a DNS name server which loads authoritative zones."
-       ::= { dnsServMIBGroups 4 }
-
-
-
-Austein & Saperia                                              [Page 26]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-   -- Compliances.
-
-   dnsServMIBCompliances OBJECT IDENTIFIER ::= { dnsServMIB 3 }
-
-   dnsServMIBCompliance MODULE-COMPLIANCE
-       STATUS      current
-       DESCRIPTION
-               "The compliance statement for agents implementing the DNS
-               name server MIB extensions."
-       MODULE -- This MIB module
-           MANDATORY-GROUPS { dnsServConfigGroup, dnsServCounterGroup }
-           GROUP   dnsServOptCounterGroup
-           DESCRIPTION
-               "The server optional counter group is unconditionally
-               optional."
-           GROUP   dnsServZoneGroup
-           DESCRIPTION
-               "The server zone group is mandatory for any name server
-               that acts as an authoritative server for any DNS zone."
-           OBJECT  dnsServConfigRecurs
-           MIN-ACCESS      read-only
-           DESCRIPTION
-               "This object need not be writable."
-           OBJECT  dnsServConfigReset
-           MIN-ACCESS      read-only
-           DESCRIPTION
-               "This object need not be writable."
-       ::= { dnsServMIBCompliances 1 }
-
-   END
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein & Saperia                                              [Page 27]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-5.  Acknowledgements
-
-   This document is the result of work undertaken the by DNS working
-   group.  The authors would particularly like to thank the following
-   people for their contributions to this document: Philip Almquist,
-   Frank Kastenholz (FTP Software), Joe Peck (DEC), Dave Perkins
-   (SynOptics), Win Treese (DEC), and Mimi Zohar (IBM).
-
-6.  References
-
-   [1] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
-       13, RFC 1034, USC/Information Sciences Institute, November 1987.
-
-   [2] Mockapetris, P., "Domain Names -- Implementation and
-       Specification", STD 13, RFC 1035, USC/Information Sciences
-       Institute, November 1987.
-
-   [3] Braden, R., Editor, "Requirements for Internet Hosts --
-       Application and Support, STD 3, RFC 1123, USC/Information
-       Sciences Institute, October 1989.
-
-   [4] Rose, M., and K. McCloghrie, "Structure and Identification of
-       Management Information for TCP/IP-based internets", STD 16, RFC
-       1155, Performance Systems International, Hughes LAN Systems, May
-       1990.
-
-   [5] McCloghrie, K., and M. Rose, "Management Information Base for
-       Network Management of TCP/IP-based internets", RFC 1156, Hughes
-       LAN Systems, Performance Systems International, May 1990.
-
-   [6] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
-       Network Management Protocol", STD 15, RFC 1157, SNMP Research,
-       Performance Systems International, Performance Systems
-       International, MIT Laboratory for Computer Science, May 1990.
-
-   [7] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
-       STD 16, RFC 1212, Performance Systems International, Hughes LAN
-       Systems, March 1991.
-
-   [8] McCloghrie, K., and M. Rose, Editors, "Management Information
-       Base for Network Management of TCP/IP-based internets: MIB-II",
-       STD 17, RFC 1213, Hughes LAN Systems, Performance Systems
-       International, March 1991.
-
-   [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure
-       of Management Information for version 2 of the Simple Network
-       Management Protocol (SNMPv2)", RFC 1442, SNMP Research, Inc.,
-       Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon
-
-
-
-Austein & Saperia                                              [Page 28]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-       University, April 1993.
-
-  [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual
-       Conventions for version 2 of the the Simple Network Management
-       Protocol (SNMPv2)", RFC 1443, SNMP Research, Inc., Hughes LAN
-       Systems, Dover Beach Consulting, Inc., Carnegie Mellon
-       University, April 1993.
-
-  [11] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
-       "Conformance Statements for version 2 of the the Simple Network
-       Management Protocol (SNMPv2)", RFC 1444, SNMP Research, Inc.,
-       Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon
-       University, April 1993.
-
-  [12] Galvin, J., and K. McCloghrie, "Administrative Model for version
-       2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445,
-       Trusted Information Systems, Hughes LAN Systems, April 1993.
-
-  [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol
-       Operations for version 2 of the Simple Network Management
-       Protocol (SNMPv2)", RFC 1448, SNMP Research, Inc., Hughes LAN
-       Systems, Dover Beach Consulting, Inc., Carnegie Mellon
-       University, April 1993.
-
-  [14] "Information processing systems - Open Systems Interconnection -
-       Specification of Abstract Syntax Notation One (ASN.1)",
-       International Organization for Standardization, International
-       Standard 8824, December 1987.
-
-7.  Security Considerations
-
-   Security issues are not discussed in this memo.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein & Saperia                                              [Page 29]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-8.  Authors' Addresses
-
-   Rob Austein
-   Epilogue Technology Corporation
-   268 Main Street, Suite 283
-   North Reading, MA 01864
-   USA
-
-   Phone: +1-617-245-0804
-   Fax:   +1-617-245-8122
-   EMail: sra@epilogue.com
-
-
-   Jon Saperia
-   Digital Equipment Corporation
-   110 Spit Brook Road
-   ZKO1-3/H18
-   Nashua, NH 03062-2698
-   USA
-
-   Phone: +1-603-881-0480
-   Fax:   +1-603-881-0120
-   EMail: saperia@zko.dec.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein & Saperia                                              [Page 30]
-
diff --git a/contrib/bind9/doc/rfc/rfc1612.txt b/contrib/bind9/doc/rfc/rfc1612.txt
deleted file mode 100644
index 4ef23b0..0000000
--- a/contrib/bind9/doc/rfc/rfc1612.txt
+++ /dev/null
@@ -1,1795 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         R. Austein
-Request for Comments: 1612               Epilogue Technology Corporation
-Category: Standards Track                                     J. Saperia
-                                           Digital Equipment Corporation
-                                                                May 1994
-
-
-                      DNS Resolver MIB Extensions
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Table of Contents
-
-   1. Introduction ..............................................    1
-   2. The SNMPv2 Network Management Framework ...................    2
-   2.1 Object Definitions .......................................    2
-   3. Overview ..................................................    2
-   3.1 Resolvers ................................................    3
-   3.2 Name Servers .............................................    3
-   3.3 Selected Objects .........................................    4
-   3.4 Textual Conventions ......................................    4
-   4. Definitions ...............................................    5
-   5. Acknowledgements ..........................................   30
-   6. References ................................................   30
-   7. Security Considerations ...................................   32
-   8. Authors' Addresses ........................................   32
-
-1.  Introduction
-
-   This memo defines a portion of the Management Information Base (MIB)
-   for use with network management protocols in the Internet community.
-   In particular, it describes a set of extensions which instrument DNS
-   resolver functions.  This memo was produced by the DNS working group.
-
-   With the adoption of the Internet-standard Network Management
-   Framework [4,5,6,7], and with a large number of vendor
-   implementations of these standards in commercially available
-   products, it became possible to provide a higher level of effective
-   network management in TCP/IP-based internets than was previously
-   available.  With the growth in the use of these standards, it has
-   become possible to consider the management of other elements of the
-   infrastructure beyond the basic TCP/IP protocols.  A key element of
-
-
-
-Austein & Saperia                                               [Page 1]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-   the TCP/IP infrastructure is the DNS.
-
-   Up to this point there has been no mechanism to integrate the
-   management of the DNS with SNMP-based managers.  This memo provides
-   the mechanisms by which IP-based management stations can effectively
-   manage DNS resolver software in an integrated fashion.
-
-   We have defined DNS MIB objects to be used in conjunction with the
-   Internet MIB to allow access to and control of DNS resolver software
-   via SNMP by the Internet community.
-
-2.  The SNMPv2 Network Management Framework
-
-   The SNMPv2 Network Management Framework consists of four major
-   components.  They are:
-
-      o  RFC 1442 which defines the SMI, the mechanisms used for
-         describing and naming objects for the purpose of management.
-
-      o  STD 17, RFC 1213 defines MIB-II, the core set of managed
-         objects for the Internet suite of protocols.
-
-      o  RFC 1445 which defines the administrative and other
-         architectural aspects of the framework.
-
-      o  RFC 1448 which defines the protocol used for network access to
-         managed objects.
-
-   The Framework permits new objects to be defined for the purpose of
-   experimentation and evaluation.
-
-2.1.  Object Definitions
-
-   Managed objects are accessed via a virtual information store, termed
-   the Management Information Base or MIB.  Objects in the MIB are
-   defined using the subset of Abstract Syntax Notation One (ASN.1)
-   defined in the SMI.  In particular, each object object type is named
-   by an OBJECT IDENTIFIER, an administratively assigned name.  The
-   object type together with an object instance serves to uniquely
-   identify a specific instantiation of the object.  For human
-   convenience, we often use a textual string, termed the descriptor, to
-   refer to the object type.
-
-3.  Overview
-
-   In theory, the DNS world is pretty simple.  There are two kinds of
-   entities: resolvers and name servers.  Resolvers ask questions.  Name
-   servers answer them.  The real world, however, is not so simple.
-
-
-
-Austein & Saperia                                               [Page 2]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-   Implementors have made widely differing choices about how to divide
-   DNS functions between resolvers and servers.  They have also
-   constructed various sorts of exotic hybrids.  The most difficult task
-   in defining this MIB was to accommodate this wide range of entities
-   without having to come up with a separate MIB for each.
-
-   We divided up the various DNS functions into two, non-overlapping
-   classes, called "resolver functions" and "name server functions."  A
-   DNS entity that performs what we define as resolver functions
-   contains a resolver, and therefore must implement the MIB groups
-   required of all resolvers which are defined in this module.  Some
-   resolvers also implement "optional" functions such as a cache, in
-   which case they must also implement the cache group contained in this
-   MIB.  A DNS entity which implements name server functions is
-   considered to be a name server, and must implement the MIB groups
-   required for name servers which are defined in a separate module.  If
-   the same piece of software performs both resolver and server
-   functions, we imagine that it contains both a resolver and a server
-   and would thus implement both the DNS Server and DNS Resolver MIBs.
-
-3.1.  Resolvers
-
-   In our model, a resolver is a program (or piece thereof) which
-   obtains resource records from servers.  Normally it does so at the
-   behest of an application, but may also do so as part of its own
-   operation.  A resolver sends DNS protocol queries and receives DNS
-   protocol replies.  A resolver neither receives queries nor sends
-   replies.  A full service resolver is one that knows how to resolve
-   queries: it obtains the needed resource records by contacting a
-   server authoritative for the records desired.  A stub resolver does
-   not know how to resolve queries: it sends all queries to a local name
-   server, setting the "recursion desired" flag to indicate that it
-   hopes that the name server will be willing to resolve the query.  A
-   resolver may (optionally) have a cache for remembering previously
-   acquired resource records.  It may also have a negative cache for
-   remembering names or data that have been determined not to exist.
-
-3.2.  Name Servers
-
-   A name server is a program (or piece thereof) that provides resource
-   records to resolvers.  All references in this document to "a name
-   server" imply "the name server's role"; in some cases the name
-   server's role and the resolver's role might be combined into a single
-   program.  A name server receives DNS protocol queries and sends DNS
-   protocol replies.  A name server neither sends queries nor receives
-   replies.  As a consequence, name servers do not have caches.
-   Normally, a name server would expect to receive only those queries to
-   which it could respond with authoritative information.  However, if a
-
-
-
-Austein & Saperia                                               [Page 3]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-   name server receives a query that it cannot respond to with purely
-   authoritative information, it may choose to try to obtain the
-   necessary additional information from a resolver which may or may not
-   be a separate process.
-
-3.3.  Selected Objects
-
-   Many of the objects included in this memo have been created from
-   information contained in the DNS specifications [1,2], as amended and
-   clarified by subsequent host requirements documents [3].  Other
-   objects have been created based on experience with existing DNS
-   management tools, expected operational needs, the statistics
-   generated by existing DNS implementations, and the configuration
-   files used by existing DNS implementations.  These objects have been
-   ordered into groups as follows:
-
-         o  Resolver Configuration Group
-
-         o  Resolver Counter Group
-
-         o  Resolver Lame Delegation Group
-
-         o  Resolver Cache Group
-
-         o  Resolver Negative Cache Group
-
-         o  Resolver Optional Counter Group
-
-   This information has been converted into a standard form using the
-   SNMPv2 SMI defined in [9].  For the most part, the descriptions are
-   influenced by the DNS related RFCs noted above.  For example, the
-   descriptions for counters used for the various types of queries of
-   DNS records are influenced by the definitions used for the various
-   record types found in [2].
-
-3.4.  Textual Conventions
-
-   Several conceptual data types have been introduced as a textual
-   conventions in the DNS Server MIB document and have been imported
-   into this MIB module.  These additions will facilitate the common
-   understanding of information used by the DNS.  No changes to the SMI
-   or the SNMP are necessary to support these conventions.
-
-   Readers familiar with MIBs designed to manage entities in the lower
-   layers of the Internet protocol suite may be surprised at the number
-   of non-enumerated integers used in this MIB to represent values such
-   as DNS RR class and type numbers.  The reason for this choice is
-   simple: the DNS itself is designed as an extensible protocol,
-
-
-
-Austein & Saperia                                               [Page 4]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-   allowing new classes and types of resource records to be added to the
-   protocol without recoding the core DNS software.  Using non-
-   enumerated integers to represent these data types in this MIB allows
-   the MIB to accommodate these changes as well.
-
-4.  Definitions
-
-   DNS-RESOLVER-MIB DEFINITIONS ::= BEGIN
-
-   IMPORTS
-       MODULE-IDENTITY, OBJECT-TYPE, IpAddress, Counter32, Integer32
-           FROM SNMPv2-SMI
-       TEXTUAL-CONVENTION, RowStatus, DisplayString
-           FROM SNMPv2-TC
-       MODULE-COMPLIANCE, OBJECT-GROUP
-           FROM SNMPv2-CONF
-       dns, DnsName, DnsNameAsIndex, DnsClass, DnsType, DnsQClass,
-       DnsQType, DnsTime, DnsOpCode, DnsRespCode
-           FROM DNS-SERVER-MIB;
-
-   -- DNS Resolver MIB
-
-   dnsResMIB MODULE-IDENTITY
-       LAST-UPDATED "9401282250Z"
-       ORGANIZATION "IETF DNS Working Group"
-       CONTACT-INFO
-               "       Rob Austein
-               Postal: Epilogue Technology Corporation
-                       268 Main Street, Suite 283
-                       North Reading, MA 10864
-                       US
-                  Tel: +1 617 245 0804
-                  Fax: +1 617 245 8122
-               E-Mail: sra@epilogue.com
-
-                       Jon Saperia
-               Postal: Digital Equipment Corporation
-                       110 Spit Brook Road
-                       ZKO1-3/H18
-                       Nashua, NH 03062-2698
-                       US
-                  Tel: +1 603 881 0480
-                  Fax: +1 603 881 0120
-               E-mail: saperia@zko.dec.com"
-       DESCRIPTION
-               "The MIB module for entities implementing the client
-               (resolver) side of the Domain Name System (DNS)
-               protocol."
-
-
-
-Austein & Saperia                                               [Page 5]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-       ::= { dns 2 }
-
-   dnsResMIBObjects        OBJECT IDENTIFIER ::= { dnsResMIB 1 }
-
-   -- (Old-style) groups in the DNS resolver MIB.
-
-   dnsResConfig            OBJECT IDENTIFIER ::= { dnsResMIBObjects 1 }
-   dnsResCounter           OBJECT IDENTIFIER ::= { dnsResMIBObjects 2 }
-   dnsResLameDelegation    OBJECT IDENTIFIER ::= { dnsResMIBObjects 3 }
-   dnsResCache             OBJECT IDENTIFIER ::= { dnsResMIBObjects 4 }
-   dnsResNCache            OBJECT IDENTIFIER ::= { dnsResMIBObjects 5 }
-   dnsResOptCounter        OBJECT IDENTIFIER ::= { dnsResMIBObjects 6 }
-
-
-   -- Resolver Configuration Group
-
-   dnsResConfigImplementIdent OBJECT-TYPE
-       SYNTAX      DisplayString
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "The implementation identification string for the
-               resolver software in use on the system, for example;
-               `RES-2.1'"
-       ::= { dnsResConfig 1 }
-
-   dnsResConfigService OBJECT-TYPE
-       SYNTAX      INTEGER { recursiveOnly(1),
-                             iterativeOnly(2),
-                             recursiveAndIterative(3) }
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Kind of DNS resolution service provided:
-
-               recursiveOnly(1) indicates a stub resolver.
-
-               iterativeOnly(2) indicates a normal full service
-               resolver.
-
-               recursiveAndIterative(3) indicates a full-service
-               resolver which performs a mix of recursive and iterative
-               queries."
-        ::= { dnsResConfig 2 }
-
-   dnsResConfigMaxCnames OBJECT-TYPE
-       SYNTAX      INTEGER (0..2147483647)
-       MAX-ACCESS  read-write
-
-
-
-Austein & Saperia                                               [Page 6]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-       STATUS      current
-       DESCRIPTION
-               "Limit on how many CNAMEs the resolver should allow
-               before deciding that there's a CNAME loop.  Zero means
-               that resolver has no explicit CNAME limit."
-       REFERENCE
-               "RFC-1035 section 7.1."
-       ::= { dnsResConfig 3 }
-
-   -- DNS Resolver Safety Belt Table
-
-   dnsResConfigSbeltTable OBJECT-TYPE
-       SYNTAX      SEQUENCE OF DnsResConfigSbeltEntry
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "Table of safety belt information used by the resolver
-               when it hasn't got any better idea of where to send a
-               query, such as when the resolver is booting or is a stub
-               resolver."
-       ::= { dnsResConfig 4 }
-
-   dnsResConfigSbeltEntry OBJECT-TYPE
-       SYNTAX      DnsResConfigSbeltEntry
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "An entry in the resolver's Sbelt table.
-               Rows may be created or deleted at any time by the DNS
-               resolver and by SNMP SET requests.  Whether the values
-               changed via SNMP are saved in stable storage across
-               `reset' operations is implementation-specific."
-       INDEX     { dnsResConfigSbeltAddr,
-                   dnsResConfigSbeltSubTree,
-                   dnsResConfigSbeltClass }
-       ::= { dnsResConfigSbeltTable 1 }
-
-   DnsResConfigSbeltEntry ::=
-       SEQUENCE {
-           dnsResConfigSbeltAddr
-               IpAddress,
-           dnsResConfigSbeltName
-               DnsName,
-           dnsResConfigSbeltRecursion
-               INTEGER,
-           dnsResConfigSbeltPref
-               INTEGER,
-           dnsResConfigSbeltSubTree
-
-
-
-Austein & Saperia                                               [Page 7]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-               DnsNameAsIndex,
-           dnsResConfigSbeltClass
-               DnsClass,
-           dnsResConfigSbeltStatus
-               RowStatus
-       }
-
-   dnsResConfigSbeltAddr OBJECT-TYPE
-       SYNTAX      IpAddress
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "The IP address of the Sbelt name server identified by
-               this row of the table."
-       ::= { dnsResConfigSbeltEntry 1 }
-
-   dnsResConfigSbeltName OBJECT-TYPE
-       SYNTAX      DnsName
-       MAX-ACCESS  read-create
-       STATUS      current
-       DESCRIPTION
-               "The DNS name of a Sbelt nameserver identified by this
-               row of the table.  A zero-length string indicates that
-               the name is not known by the resolver."
-       ::= { dnsResConfigSbeltEntry 2 }
-
-   dnsResConfigSbeltRecursion OBJECT-TYPE
-       SYNTAX      INTEGER { iterative(1),
-                             recursive(2),
-                             recursiveAndIterative(3) }
-       MAX-ACCESS  read-create
-       STATUS      current
-       DESCRIPTION
-               "Kind of queries resolver will be sending to the name
-               server identified in this row of the table:
-
-               iterative(1) indicates that resolver will be directing
-               iterative queries to this name server (RD bit turned
-               off).
-
-               recursive(2) indicates that resolver will be directing
-               recursive queries to this name server (RD bit turned
-               on).
-
-               recursiveAndIterative(3) indicates that the resolver
-               will be directing both recursive and iterative queries
-               to the server identified in this row of the table."
-        ::= { dnsResConfigSbeltEntry 3 }
-
-
-
-Austein & Saperia                                               [Page 8]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-   dnsResConfigSbeltPref OBJECT-TYPE
-       SYNTAX      INTEGER (0..2147483647)
-       MAX-ACCESS  read-create
-       STATUS      current
-       DESCRIPTION
-               "This value identifies the preference for the name server
-               identified in this row of the table.  The lower the
-               value, the more desirable the resolver considers this
-               server."
-        ::= { dnsResConfigSbeltEntry 4 }
-
-   dnsResConfigSbeltSubTree OBJECT-TYPE
-       SYNTAX      DnsNameAsIndex
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "Queries sent to the name server identified by this row
-               of the table are limited to those for names in the name
-               subtree identified by this variable.  If no such
-               limitation applies, the value of this variable is the
-               name of the root domain (a DNS name consisting of a
-               single zero octet)."
-       ::= { dnsResConfigSbeltEntry 5 }
-
-   dnsResConfigSbeltClass OBJECT-TYPE
-       SYNTAX      DnsClass
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "The class of DNS queries that will be sent to the server
-               identified by this row of the table."
-       ::= { dnsResConfigSbeltEntry 6 }
-
-   dnsResConfigSbeltStatus OBJECT-TYPE
-       SYNTAX      RowStatus
-       MAX-ACCESS  read-create
-       STATUS      current
-       DESCRIPTION
-               "Row status column for this row of the Sbelt table."
-       ::= { dnsResConfigSbeltEntry 7 }
-
-   dnsResConfigUpTime OBJECT-TYPE
-       SYNTAX      DnsTime
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "If the resolver has a persistent state (e.g., a
-               process), this value will be the time elapsed since it
-
-
-
-Austein & Saperia                                               [Page 9]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-               started.  For software without persistant state, this
-               value will be 0."
-       ::= { dnsResConfig 5 }
-
-   dnsResConfigResetTime OBJECT-TYPE
-       SYNTAX      DnsTime
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "If the resolver has a persistent state (e.g., a process)
-               and supports a `reset' operation (e.g., can be told to
-               re-read configuration files), this value will be the
-               time elapsed since the last time the resolver was
-               `reset.'  For software that does not have persistence or
-               does not support a `reset' operation, this value will be
-               zero."
-       ::= { dnsResConfig 6 }
-
-   dnsResConfigReset OBJECT-TYPE
-       SYNTAX      INTEGER { other(1),
-                             reset(2),
-                             initializing(3),
-                             running(4) }
-       MAX-ACCESS  read-write
-       STATUS      current
-       DESCRIPTION
-               "Status/action object to reinitialize any persistant
-               resolver state.  When set to reset(2), any persistant
-               resolver state (such as a process) is reinitialized as if
-               the resolver had just been started.  This value will
-               never be returned by a read operation.  When read, one of
-               the following values will be returned:
-                   other(1) - resolver in some unknown state;
-                   initializing(3) - resolver (re)initializing;
-                   running(4) - resolver currently running."
-       ::= { dnsResConfig 7 }
-
-
-   -- Resolver Counters Group
-
-   -- Resolver Counter Table
-
-   dnsResCounterByOpcodeTable OBJECT-TYPE
-       SYNTAX      SEQUENCE OF DnsResCounterByOpcodeEntry
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "Table of the current count of resolver queries and
-
-
-
-Austein & Saperia                                              [Page 10]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-               answers."
-       ::= { dnsResCounter 3 }
-
-   dnsResCounterByOpcodeEntry OBJECT-TYPE
-       SYNTAX      DnsResCounterByOpcodeEntry
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "Entry in the resolver counter table.  Entries are
-               indexed by DNS OpCode."
-       INDEX     { dnsResCounterByOpcodeCode }
-       ::= { dnsResCounterByOpcodeTable 1 }
-
-   DnsResCounterByOpcodeEntry ::=
-       SEQUENCE {
-           dnsResCounterByOpcodeCode
-               DnsOpCode,
-           dnsResCounterByOpcodeQueries
-               Counter32,
-           dnsResCounterByOpcodeResponses
-               Counter32
-       }
-
-   dnsResCounterByOpcodeCode OBJECT-TYPE
-       SYNTAX      DnsOpCode
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "The index to this table.  The OpCodes that have already
-               been defined are found in RFC-1035."
-       REFERENCE
-               "RFC-1035 section 4.1.1."
-       ::= { dnsResCounterByOpcodeEntry 1 }
-
-   dnsResCounterByOpcodeQueries OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Total number of queries that have sent out by the
-               resolver since initialization for the OpCode which is
-               the index to this row of the table."
-       ::= { dnsResCounterByOpcodeEntry 2 }
-
-   dnsResCounterByOpcodeResponses OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-
-
-
-Austein & Saperia                                              [Page 11]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-       DESCRIPTION
-               "Total number of responses that have been received by the
-               resolver since initialization for the OpCode which is
-               the index to this row of the table."
-       ::= { dnsResCounterByOpcodeEntry 3 }
-
-   -- Resolver Response Code Counter Table
-
-   dnsResCounterByRcodeTable OBJECT-TYPE
-       SYNTAX      SEQUENCE OF DnsResCounterByRcodeEntry
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "Table of the current count of responses to resolver
-               queries."
-       ::= { dnsResCounter 4 }
-
-   dnsResCounterByRcodeEntry OBJECT-TYPE
-       SYNTAX      DnsResCounterByRcodeEntry
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "Entry in the resolver response table.  Entries are
-               indexed by DNS response code."
-       INDEX     { dnsResCounterByRcodeCode }
-       ::= { dnsResCounterByRcodeTable 1 }
-
-   DnsResCounterByRcodeEntry ::=
-       SEQUENCE {
-           dnsResCounterByRcodeCode
-               DnsRespCode,
-           dnsResCounterByRcodeResponses
-               Counter32
-       }
-
-   dnsResCounterByRcodeCode OBJECT-TYPE
-       SYNTAX      DnsRespCode
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "The index to this table.  The Response Codes that have
-               already been defined are found in RFC-1035."
-       REFERENCE
-               "RFC-1035 section 4.1.1."
-       ::= { dnsResCounterByRcodeEntry 1 }
-
-
-
-
-
-
-Austein & Saperia                                              [Page 12]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-   dnsResCounterByRcodeResponses OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of responses the resolver has received for the
-               response code value which identifies this row of the
-               table."
-       ::= { dnsResCounterByRcodeEntry 2 }
-
-   -- Additional DNS Resolver Counter Objects
-
-   dnsResCounterNonAuthDataResps OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests made by the resolver for which a
-               non-authoritative answer (cached data) was received."
-       ::= { dnsResCounter 5 }
-
-   dnsResCounterNonAuthNoDataResps OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests made by the resolver for which a
-               non-authoritative answer - no such data response (empty
-               answer) was received."
-       ::= { dnsResCounter 6 }
-
-   dnsResCounterMartians OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of responses received which were received from
-               servers that the resolver does not think it asked."
-       ::= { dnsResCounter 7 }
-
-   dnsResCounterRecdResponses OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of responses received to all queries."
-       ::= { dnsResCounter 8 }
-
-
-
-
-Austein & Saperia                                              [Page 13]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-   dnsResCounterUnparseResps OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of responses received which were unparseable."
-       ::= { dnsResCounter 9 }
-
-   dnsResCounterFallbacks OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of times the resolver had to fall back to its
-               seat belt information."
-       ::= { dnsResCounter 10 }
-
-
-   -- Lame Delegation Group
-
-   dnsResLameDelegationOverflows OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of times the resolver attempted to add an entry
-               to the Lame Delegation table but was unable to for some
-               reason such as space constraints."
-       ::= { dnsResLameDelegation 1 }
-
-   -- Lame Delegation Table
-
-   dnsResLameDelegationTable OBJECT-TYPE
-       SYNTAX      SEQUENCE OF DnsResLameDelegationEntry
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "Table of name servers returning lame delegations.
-
-               A lame delegation has occured when a parent zone
-               delegates authority for a child zone to a server that
-               appears not to think that it is authoritative for the
-               child zone in question."
-       ::= { dnsResLameDelegation 2 }
-
-   dnsResLameDelegationEntry OBJECT-TYPE
-       SYNTAX      DnsResLameDelegationEntry
-       MAX-ACCESS  not-accessible
-
-
-
-Austein & Saperia                                              [Page 14]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-       STATUS      current
-       DESCRIPTION
-               "Entry in lame delegation table.  Only the resolver may
-               create rows in this table.  SNMP SET requests may be used
-               to delete rows."
-       INDEX     { dnsResLameDelegationSource,
-                   dnsResLameDelegationName,
-                   dnsResLameDelegationClass }
-       ::= { dnsResLameDelegationTable 1 }
-
-   DnsResLameDelegationEntry ::=
-       SEQUENCE {
-           dnsResLameDelegationSource
-               IpAddress,
-           dnsResLameDelegationName
-               DnsNameAsIndex,
-           dnsResLameDelegationClass
-               DnsClass,
-           dnsResLameDelegationCounts
-               Counter32,
-           dnsResLameDelegationStatus
-               RowStatus
-       }
-
-   dnsResLameDelegationSource OBJECT-TYPE
-       SYNTAX      IpAddress
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "Source of lame delegation."
-       ::= { dnsResLameDelegationEntry 1 }
-
-   dnsResLameDelegationName OBJECT-TYPE
-       SYNTAX      DnsNameAsIndex
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "DNS name for which lame delegation was received."
-       ::= { dnsResLameDelegationEntry 2 }
-
-   dnsResLameDelegationClass OBJECT-TYPE
-       SYNTAX      DnsClass
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "DNS class of received lame delegation."
-       ::= { dnsResLameDelegationEntry 3 }
-
-
-
-
-Austein & Saperia                                              [Page 15]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-   dnsResLameDelegationCounts OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "How many times this lame delegation has been received."
-       ::= { dnsResLameDelegationEntry 4 }
-
-   dnsResLameDelegationStatus OBJECT-TYPE
-       SYNTAX      RowStatus
-       MAX-ACCESS  read-write
-       STATUS      current
-       DESCRIPTION
-               "Status column for the lame delegation table.  Since only
-               the agent (DNS resolver) creates rows in this table, the
-               only values that a manager may write to this variable
-               are active(1) and destroy(6)."
-       ::= { dnsResLameDelegationEntry 5 }
-
-
-   -- Resolver Cache Group
-
-   dnsResCacheStatus OBJECT-TYPE
-       SYNTAX      INTEGER { enabled(1), disabled(2), clear(3) }
-       MAX-ACCESS  read-write
-       STATUS      current
-       DESCRIPTION
-               "Status/action for the resolver's cache.
-
-               enabled(1) means that the use of the cache is allowed.
-               Query operations can return this state.
-
-               disabled(2) means that the cache is not being used.
-               Query operations can return this state.
-
-               Setting this variable to clear(3) deletes the entire
-               contents of the resolver's cache, but does not otherwise
-               change the resolver's state.  The status will retain its
-               previous value from before the clear operation (i.e.,
-               enabled(1) or disabled(2)).  The value of clear(3) can
-               NOT be returned by a query operation."
-       ::= { dnsResCache 1 }
-
-   dnsResCacheMaxTTL OBJECT-TYPE
-       SYNTAX      DnsTime
-       MAX-ACCESS  read-write
-       STATUS      current
-       DESCRIPTION
-
-
-
-Austein & Saperia                                              [Page 16]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-               "Maximum Time-To-Live for RRs in this cache.  If the
-               resolver does not implement a TTL ceiling, the value of
-               this field should be zero."
-       ::= { dnsResCache 2 }
-
-   dnsResCacheGoodCaches OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of RRs the resolver has cached successfully."
-       ::= { dnsResCache 3 }
-
-   dnsResCacheBadCaches OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of RRs the resolver has refused to cache because
-               they appear to be dangerous or irrelevant.  E.g., RRs
-               with suspiciously high TTLs, unsolicited root
-               information, or that just don't appear to be relevant to
-               the question the resolver asked."
-       ::= { dnsResCache 4 }
-
-   -- Resolver Cache Table
-
-   dnsResCacheRRTable OBJECT-TYPE
-       SYNTAX      SEQUENCE OF DnsResCacheRREntry
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "This table contains information about all the resource
-               records currently in the resolver's cache."
-       ::= { dnsResCache 5 }
-
-   dnsResCacheRREntry OBJECT-TYPE
-       SYNTAX      DnsResCacheRREntry
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "An entry in the resolvers's cache.  Rows may be created
-               only by the resolver.  SNMP SET requests may be used to
-               delete rows."
-       INDEX     { dnsResCacheRRName,
-                   dnsResCacheRRClass,
-                   dnsResCacheRRType,
-                   dnsResCacheRRIndex }
-
-
-
-Austein & Saperia                                              [Page 17]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-       ::= { dnsResCacheRRTable 1 }
-
-   DnsResCacheRREntry ::=
-       SEQUENCE {
-           dnsResCacheRRName
-               DnsNameAsIndex,
-           dnsResCacheRRClass
-               DnsClass,
-           dnsResCacheRRType
-               DnsType,
-           dnsResCacheRRTTL
-               DnsTime,
-           dnsResCacheRRElapsedTTL
-               DnsTime,
-           dnsResCacheRRSource
-               IpAddress,
-           dnsResCacheRRData
-               OCTET STRING,
-           dnsResCacheRRStatus
-               RowStatus,
-           dnsResCacheRRIndex
-               Integer32,
-           dnsResCacheRRPrettyName
-               DnsName
-       }
-
-   dnsResCacheRRName OBJECT-TYPE
-       SYNTAX      DnsNameAsIndex
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "Owner name of the Resource Record in the cache which is
-               identified in this row of the table.  As described in
-               RFC-1034, the owner of the record is the domain name
-               were the RR is found."
-       REFERENCE
-               "RFC-1034 section 3.6."
-       ::= { dnsResCacheRREntry 1 }
-
-   dnsResCacheRRClass OBJECT-TYPE
-       SYNTAX      DnsClass
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "DNS class of the Resource Record in the cache which is
-               identified in this row of the table."
-       ::= { dnsResCacheRREntry 2 }
-
-
-
-
-Austein & Saperia                                              [Page 18]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-   dnsResCacheRRType OBJECT-TYPE
-       SYNTAX      DnsType
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "DNS type of the Resource Record in the cache which is
-               identified in this row of the table."
-       ::= { dnsResCacheRREntry 3 }
-
-   dnsResCacheRRTTL OBJECT-TYPE
-       SYNTAX      DnsTime
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Time-To-Live of RR in DNS cache.  This is the initial
-               TTL value which was received with the RR when it was
-               originally received."
-       ::= { dnsResCacheRREntry 4 }
-
-   dnsResCacheRRElapsedTTL OBJECT-TYPE
-       SYNTAX      DnsTime
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Elapsed seconds since RR was received."
-       ::= { dnsResCacheRREntry 5 }
-
-   dnsResCacheRRSource OBJECT-TYPE
-       SYNTAX      IpAddress
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Host from which RR was received, 0.0.0.0 if unknown."
-       ::= { dnsResCacheRREntry 6 }
-
-   dnsResCacheRRData OBJECT-TYPE
-       SYNTAX      OCTET STRING
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "RDATA portion of a cached RR.  The value is in the
-               format defined for the particular DNS class and type of
-               the resource record."
-       REFERENCE
-               "RFC-1035 section 3.2.1."
-       ::= { dnsResCacheRREntry 7 }
-
-
-
-
-
-Austein & Saperia                                              [Page 19]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-   dnsResCacheRRStatus OBJECT-TYPE
-       SYNTAX      RowStatus
-       MAX-ACCESS  read-write
-       STATUS      current
-       DESCRIPTION
-               "Status column for the resolver cache table.  Since only
-               the agent (DNS resolver) creates rows in this table, the
-               only values that a manager may write to this variable
-               are active(1) and destroy(6)."
-       ::= { dnsResCacheRREntry 8 }
-
-   dnsResCacheRRIndex OBJECT-TYPE
-       SYNTAX      Integer32
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "A value which makes entries in the table unique when the
-               other index values (dnsResCacheRRName,
-               dnsResCacheRRClass, and dnsResCacheRRType) do not
-               provide a unique index."
-       ::= { dnsResCacheRREntry 9 }
-
-   dnsResCacheRRPrettyName OBJECT-TYPE
-       SYNTAX      DnsName
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Name of the RR at this row in the table.  This is
-               identical to the dnsResCacheRRName variable, except that
-               character case is preserved in this variable, per DNS
-               conventions."
-       REFERENCE
-               "RFC-1035 section 2.3.3."
-       ::= { dnsResCacheRREntry 10 }
-
-   -- Resolver Negative Cache Group
-
-   dnsResNCacheStatus OBJECT-TYPE
-       SYNTAX      INTEGER { enabled(1), disabled(2), clear(3) }
-       MAX-ACCESS  read-write
-       STATUS      current
-       DESCRIPTION
-               "Status/action for the resolver's negative response
-               cache.
-
-               enabled(1) means that the use of the negative response
-               cache is allowed.  Query operations can return this
-               state.
-
-
-
-Austein & Saperia                                              [Page 20]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-               disabled(2) means that the negative response cache is
-               not being used.  Query operations can return this state.
-
-               Setting this variable to clear(3) deletes the entire
-               contents of the resolver's negative response cache.  The
-               status will retain its previous value from before the
-               clear operation (i.e., enabled(1) or disabled(2)).  The
-               value of clear(3) can NOT be returned by a query
-               operation."
-       ::= { dnsResNCache 1 }
-
-   dnsResNCacheMaxTTL OBJECT-TYPE
-       SYNTAX      DnsTime
-       MAX-ACCESS  read-write
-       STATUS      current
-       DESCRIPTION
-               "Maximum Time-To-Live for cached authoritative errors.
-               If the resolver does not implement a TTL ceiling, the
-               value of this field should be zero."
-       ::= { dnsResNCache 2 }
-
-   dnsResNCacheGoodNCaches OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of authoritative errors the resolver has cached
-               successfully."
-       ::= { dnsResNCache 3 }
-
-   dnsResNCacheBadNCaches OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of authoritative errors the resolver would have
-               liked to cache but was unable to because the appropriate
-               SOA RR was not supplied or looked suspicious."
-       REFERENCE
-               "RFC-1034 section 4.3.4."
-       ::= { dnsResNCache 4 }
-
-   -- Resolver Negative Cache Table
-
-   dnsResNCacheErrTable OBJECT-TYPE
-       SYNTAX      SEQUENCE OF DnsResNCacheErrEntry
-       MAX-ACCESS  not-accessible
-       STATUS      current
-
-
-
-Austein & Saperia                                              [Page 21]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-       DESCRIPTION
-               "The resolver's negative response cache.  This table
-               contains information about authoritative errors that
-               have been cached by the resolver."
-       ::= { dnsResNCache 5 }
-
-   dnsResNCacheErrEntry OBJECT-TYPE
-       SYNTAX      DnsResNCacheErrEntry
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "An entry in the resolver's negative response cache
-               table.  Only the resolver can create rows.  SNMP SET
-               requests may be used to delete rows."
-       INDEX     { dnsResNCacheErrQName,
-                   dnsResNCacheErrQClass,
-                   dnsResNCacheErrQType,
-                   dnsResNCacheErrIndex }
-       ::= { dnsResNCacheErrTable 1 }
-
-   DnsResNCacheErrEntry ::=
-       SEQUENCE {
-           dnsResNCacheErrQName
-               DnsNameAsIndex,
-           dnsResNCacheErrQClass
-               DnsQClass,
-           dnsResNCacheErrQType
-               DnsQType,
-           dnsResNCacheErrTTL
-               DnsTime,
-           dnsResNCacheErrElapsedTTL
-               DnsTime,
-           dnsResNCacheErrSource
-               IpAddress,
-           dnsResNCacheErrCode
-               INTEGER,
-           dnsResNCacheErrStatus
-               RowStatus,
-           dnsResNCacheErrIndex
-               Integer32,
-           dnsResNCacheErrPrettyName
-               DnsName
-       }
-
-   dnsResNCacheErrQName OBJECT-TYPE
-       SYNTAX      DnsNameAsIndex
-       MAX-ACCESS  not-accessible
-       STATUS      current
-
-
-
-Austein & Saperia                                              [Page 22]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-       DESCRIPTION
-               "QNAME associated with a cached authoritative error."
-       REFERENCE
-               "RFC-1034 section 3.7.1."
-       ::= { dnsResNCacheErrEntry 1 }
-
-   dnsResNCacheErrQClass OBJECT-TYPE
-       SYNTAX      DnsQClass
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "DNS QCLASS associated with a cached authoritative
-               error."
-       ::= { dnsResNCacheErrEntry 2 }
-
-   dnsResNCacheErrQType OBJECT-TYPE
-       SYNTAX      DnsQType
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "DNS QTYPE associated with a cached authoritative error."
-       ::= { dnsResNCacheErrEntry 3 }
-
-   dnsResNCacheErrTTL OBJECT-TYPE
-       SYNTAX      DnsTime
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Time-To-Live of a cached authoritative error at the time
-               of the error, it should not be decremented by the number
-               of seconds since it was received.  This should be the
-               TTL as copied from the MINIMUM field of the SOA that
-               accompanied the authoritative error, or a smaller value
-               if the resolver implements a ceiling on negative
-               response cache TTLs."
-       REFERENCE
-               "RFC-1034 section 4.3.4."
-       ::= { dnsResNCacheErrEntry 4 }
-
-   dnsResNCacheErrElapsedTTL OBJECT-TYPE
-       SYNTAX      DnsTime
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Elapsed seconds since authoritative error was received."
-       ::= { dnsResNCacheErrEntry 5 }
-
-
-
-
-
-Austein & Saperia                                              [Page 23]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-   dnsResNCacheErrSource OBJECT-TYPE
-       SYNTAX      IpAddress
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Host which sent the authoritative error, 0.0.0.0 if
-               unknown."
-       ::= { dnsResNCacheErrEntry 6 }
-
-   dnsResNCacheErrCode OBJECT-TYPE
-       SYNTAX      INTEGER { nonexistantName(1), noData(2), other(3) }
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "The authoritative error that has been cached:
-
-               nonexistantName(1) indicates an authoritative name error
-               (RCODE = 3).
-
-               noData(2) indicates an authoritative response with no
-               error (RCODE = 0) and no relevant data.
-
-               other(3) indicates some other cached authoritative
-               error.  At present, no such errors are known to exist."
-       ::= { dnsResNCacheErrEntry 7 }
-
-   dnsResNCacheErrStatus OBJECT-TYPE
-       SYNTAX      RowStatus
-       MAX-ACCESS  read-write
-       STATUS      current
-       DESCRIPTION
-               "Status column for the resolver negative response cache
-               table.  Since only the agent (DNS resolver) creates rows
-               in this table, the only values that a manager may write
-               to this variable are active(1) and destroy(6)."
-       ::= { dnsResNCacheErrEntry 8 }
-
-   dnsResNCacheErrIndex OBJECT-TYPE
-       SYNTAX      Integer32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "A value which makes entries in the table unique when the
-               other index values (dnsResNCacheErrQName,
-               dnsResNCacheErrQClass, and dnsResNCacheErrQType) do not
-               provide a unique index."
-       ::= { dnsResNCacheErrEntry 9 }
-
-
-
-
-Austein & Saperia                                              [Page 24]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-   dnsResNCacheErrPrettyName OBJECT-TYPE
-       SYNTAX      DnsName
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "QNAME associated with this row in the table.  This is
-               identical to the dnsResNCacheErrQName variable, except
-               that character case is preserved in this variable, per
-               DNS conventions."
-       REFERENCE
-               "RFC-1035 section 2.3.3."
-       ::= { dnsResNCacheErrEntry 10 }
-
-
-   -- Resolver Optional Counters Group
-
-   dnsResOptCounterReferals OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of responses which were received from servers
-               redirecting query to another server."
-       ::= { dnsResOptCounter 1 }
-
-   dnsResOptCounterRetrans OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number requests retransmitted for all reasons."
-       ::= { dnsResOptCounter 2 }
-
-   dnsResOptCounterNoResponses OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of queries that were retransmitted because of no
-               response."
-       ::= { dnsResOptCounter 3 }
-
-   dnsResOptCounterRootRetrans OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of queries that were retransmitted that were to
-
-
-
-Austein & Saperia                                              [Page 25]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-               root servers."
-       ::= { dnsResOptCounter 4 }
-
-   dnsResOptCounterInternals OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests internally generated by the
-               resolver."
-       ::= { dnsResOptCounter 5 }
-
-   dnsResOptCounterInternalTimeOuts OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests internally generated which timed
-               out."
-       ::= { dnsResOptCounter 6 }
-
-
-   -- SNMPv2 groups.
-
-   dnsResMIBGroups         OBJECT IDENTIFIER ::= { dnsResMIB 2 }
-
-   dnsResConfigGroup OBJECT-GROUP
-       OBJECTS   { dnsResConfigImplementIdent,
-                   dnsResConfigService,
-                   dnsResConfigMaxCnames,
-                   dnsResConfigSbeltAddr,
-                   dnsResConfigSbeltName,
-                   dnsResConfigSbeltRecursion,
-                   dnsResConfigSbeltPref,
-                   dnsResConfigSbeltSubTree,
-                   dnsResConfigSbeltClass,
-                   dnsResConfigSbeltStatus,
-                   dnsResConfigUpTime,
-                   dnsResConfigResetTime }
-       STATUS      current
-       DESCRIPTION
-               "A collection of objects providing basic configuration
-               information for a DNS resolver implementation."
-       ::= { dnsResMIBGroups 1 }
-
-   dnsResCounterGroup OBJECT-GROUP
-       OBJECTS   { dnsResCounterByOpcodeCode,
-                   dnsResCounterByOpcodeQueries,
-
-
-
-Austein & Saperia                                              [Page 26]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-                   dnsResCounterByOpcodeResponses,
-                   dnsResCounterByRcodeCode,
-                   dnsResCounterByRcodeResponses,
-                   dnsResCounterNonAuthDataResps,
-                   dnsResCounterNonAuthNoDataResps,
-                   dnsResCounterMartians,
-                   dnsResCounterRecdResponses,
-                   dnsResCounterUnparseResps,
-                   dnsResCounterFallbacks }
-       STATUS      current
-       DESCRIPTION
-               "A collection of objects providing basic instrumentation
-               of a DNS resolver implementation."
-       ::= { dnsResMIBGroups 2 }
-
-   dnsResLameDelegationGroup OBJECT-GROUP
-       OBJECTS   { dnsResLameDelegationOverflows,
-                   dnsResLameDelegationSource,
-                   dnsResLameDelegationName,
-                   dnsResLameDelegationClass,
-                   dnsResLameDelegationCounts,
-                   dnsResLameDelegationStatus }
-       STATUS      current
-       DESCRIPTION
-               "A collection of objects providing instrumentation of
-               `lame delegation' failures."
-       ::= { dnsResMIBGroups 3 }
-
-
-   dnsResCacheGroup OBJECT-GROUP
-       OBJECTS   { dnsResCacheStatus,
-                   dnsResCacheMaxTTL,
-                   dnsResCacheGoodCaches,
-                   dnsResCacheBadCaches,
-                   dnsResCacheRRName,
-                   dnsResCacheRRClass,
-                   dnsResCacheRRType,
-                   dnsResCacheRRTTL,
-                   dnsResCacheRRElapsedTTL,
-                   dnsResCacheRRSource,
-                   dnsResCacheRRData,
-                   dnsResCacheRRStatus,
-                   dnsResCacheRRIndex,
-                   dnsResCacheRRPrettyName }
-       STATUS      current
-       DESCRIPTION
-               "A collection of objects providing access to and control
-               of a DNS resolver's cache."
-
-
-
-Austein & Saperia                                              [Page 27]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-       ::= { dnsResMIBGroups 4 }
-
-   dnsResNCacheGroup OBJECT-GROUP
-       OBJECTS   { dnsResNCacheStatus,
-                   dnsResNCacheMaxTTL,
-                   dnsResNCacheGoodNCaches,
-                   dnsResNCacheBadNCaches,
-                   dnsResNCacheErrQName,
-                   dnsResNCacheErrQClass,
-                   dnsResNCacheErrQType,
-                   dnsResNCacheErrTTL,
-                   dnsResNCacheErrElapsedTTL,
-                   dnsResNCacheErrSource,
-                   dnsResNCacheErrCode,
-                   dnsResNCacheErrStatus,
-                   dnsResNCacheErrIndex,
-                   dnsResNCacheErrPrettyName }
-       STATUS      current
-       DESCRIPTION
-               "A collection of objects providing access to and control
-               of a DNS resolver's negative response cache."
-       ::= { dnsResMIBGroups 5 }
-
-   dnsResOptCounterGroup OBJECT-GROUP
-       OBJECTS   { dnsResOptCounterReferals,
-                   dnsResOptCounterRetrans,
-                   dnsResOptCounterNoResponses,
-                   dnsResOptCounterRootRetrans,
-                   dnsResOptCounterInternals,
-                   dnsResOptCounterInternalTimeOuts }
-       STATUS      current
-       DESCRIPTION
-               "A collection of objects providing further
-               instrumentation applicable to many but not all DNS
-               resolvers."
-       ::= { dnsResMIBGroups 6 }
-
-
-   -- Compliances.
-
-   dnsResMIBCompliances OBJECT IDENTIFIER ::= { dnsResMIB 3 }
-
-   dnsResMIBCompliance MODULE-COMPLIANCE
-       STATUS      current
-       DESCRIPTION
-               "The compliance statement for agents implementing the DNS
-               resolver MIB extensions."
-       MODULE -- This MIB module
-
-
-
-Austein & Saperia                                              [Page 28]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-           MANDATORY-GROUPS { dnsResConfigGroup, dnsResCounterGroup }
-           GROUP   dnsResCacheGroup
-           DESCRIPTION
-               "The resolver cache group is mandatory for resolvers that
-               implement a cache."
-           GROUP   dnsResNCacheGroup
-           DESCRIPTION
-               "The resolver negative cache group is mandatory for
-               resolvers that implement a negative response cache."
-           GROUP   dnsResLameDelegationGroup
-           DESCRIPTION
-               "The lame delegation group is unconditionally optional."
-           GROUP   dnsResOptCounterGroup
-           DESCRIPTION
-               "The optional counters group is unconditionally
-               optional."
-           OBJECT  dnsResConfigMaxCnames
-           MIN-ACCESS      read-only
-           DESCRIPTION
-               "This object need not be writable."
-           OBJECT  dnsResConfigSbeltName
-           MIN-ACCESS      read-only
-           DESCRIPTION
-               "This object need not be writable."
-           OBJECT  dnsResConfigSbeltRecursion
-           MIN-ACCESS      read-only
-           DESCRIPTION
-               "This object need not be writable."
-           OBJECT  dnsResConfigSbeltPref
-           MIN-ACCESS      read-only
-           DESCRIPTION
-               "This object need not be writable."
-           OBJECT  dnsResConfigReset
-           MIN-ACCESS      read-only
-           DESCRIPTION
-               "This object need not be writable."
-           OBJECT  dnsResCacheStatus
-           MIN-ACCESS      read-only
-           DESCRIPTION
-               "This object need not be writable."
-           OBJECT  dnsResCacheMaxTTL
-           MIN-ACCESS      read-only
-           DESCRIPTION
-               "This object need not be writable."
-           OBJECT  dnsResNCacheStatus
-           MIN-ACCESS      read-only
-           DESCRIPTION
-               "This object need not be writable."
-
-
-
-Austein & Saperia                                              [Page 29]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-           OBJECT  dnsResNCacheMaxTTL
-           MIN-ACCESS      read-only
-           DESCRIPTION
-               "This object need not be writable."
-       ::= { dnsResMIBCompliances 1 }
-
-   END
-
-5.  Acknowledgements
-
-   This document is the result of work undertaken the by DNS working
-   group.  The authors would particularly like to thank the following
-   people for their contributions to this document: Philip Almquist,
-   Frank Kastenholz (FTP Software), Joe Peck (DEC), Dave Perkins
-   (SynOptics), Win Treese (DEC), and Mimi Zohar (IBM).
-
-6.  References
-
-   [1] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
-       13, RFC 1034, USC/Information Sciences Institute, November 1987.
-
-   [2] Mockapetris, P., "Domain Names -- Implementation and
-       Specification", STD 13, RFC 1035, USC/Information Sciences
-       Institute, November 1987.
-
-   [3] Braden, R., Editor, "Requirements for Internet Hosts --
-       Application and Support, STD 3, RFC 1123, USC/Information
-       Sciences Institute, October 1989.
-
-   [4] Rose, M., and K. McCloghrie, "Structure and Identification of
-       Management Information for TCP/IP-based internets", STD 16, RFC
-       1155, Performance Systems International, Hughes LAN Systems, May
-       1990.
-
-   [5] McCloghrie, K., and M. Rose, "Management Information Base for
-       Network Management of TCP/IP-based internets", RFC 1156, Hughes
-       LAN Systems, Performance Systems International, May 1990.
-
-   [6] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
-       Network Management Protocol", STD 15, RFC 1157, SNMP Research,
-       Performance Systems International, Performance Systems
-       International, MIT Laboratory for Computer Science, May 1990.
-
-   [7] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
-       STD 16, RFC 1212, Performance Systems International, Hughes LAN
-       Systems, March 1991.
-
-
-
-
-
-Austein & Saperia                                              [Page 30]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-   [8] McCloghrie, K., and M. Rose, "Management Information Base for
-       Network Management of TCP/IP-based internets: MIB-II", STD 17,
-       RFC 1213, Hughes LAN Systems, Performance Systems International,
-       March 1991.
-
-   [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure
-       of Management Information for version 2 of the Simple Network
-       Management Protocol (SNMPv2)", RFC 1442, SNMP Research, Inc.,
-       Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon
-       University, April 1993.
-
-  [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual
-       Conventions for version 2 of the the Simple Network Management
-       Protocol (SNMPv2)", RFC 1443, SNMP Research, Inc., Hughes LAN
-       Systems, Dover Beach Consulting, Inc., Carnegie Mellon
-       University, April 1993.
-
-  [11] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
-       "Conformance Statements for version 2 of the the Simple Network
-       Management Protocol (SNMPv2)", RFC 1444, SNMP Research, Inc.,
-       Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon
-       University, April 1993.
-
-  [12] Galvin, J., and K. McCloghrie, "Administrative Model for version
-       2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445,
-       Trusted Information Systems, Hughes LAN Systems, April 1993.
-
-  [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol
-       Operations for version 2 of the Simple Network Management
-       Protocol (SNMPv2)", RFC 1448, SNMP Research, Inc., Hughes LAN
-       Systems, Dover Beach Consulting, Inc., Carnegie Mellon
-       University, April 1993.
-
-  [14] "Information processing systems - Open Systems Interconnection -
-       Specification of Abstract Syntax Notation One (ASN.1)",
-       International Organization for Standardization, International
-       Standard 8824, December 1987.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein & Saperia                                              [Page 31]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-7.  Security Considerations
-
-   Security issues are not discussed in this memo.
-
-8.  Authors' Addresses
-
-   Rob Austein
-   Epilogue Technology Corporation
-   268 Main Street, Suite 283
-   North Reading, MA 01864
-   USA
-
-   Phone: +1-617-245-0804
-   Fax:   +1-617-245-8122
-   EMail: sra@epilogue.com
-
-
-   Jon Saperia
-   Digital Equipment Corporation
-   110 Spit Brook Road
-   ZKO1-3/H18
-   Nashua, NH 03062-2698
-   USA
-
-   Phone: +1-603-881-0480
-   Fax:   +1-603-881-0120
-   EMail: saperia@zko.dec.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein & Saperia                                              [Page 32]
-
diff --git a/contrib/bind9/doc/rfc/rfc1706.txt b/contrib/bind9/doc/rfc/rfc1706.txt
deleted file mode 100644
index 5b5d821..0000000
--- a/contrib/bind9/doc/rfc/rfc1706.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         B. Manning
-Request for Comments: 1706                                           ISI
-Obsoletes: 1637, 1348                                         R. Colella
-Category: Informational                                             NIST
-                                                            October 1994
-
-
-                       DNS NSAP Resource Records
-
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  This memo
-   does not specify an Internet standard of any kind.  Distribution of
-   this memo is unlimited.
-
-Abstract
-
-   OSI lower layer protocols, comprising the connectionless network
-   protocol (CLNP) and supporting routing protocols, are deployed in
-   some parts of the global Internet.  Maintenance and debugging of CLNP
-   connectivity is greatly aided by support in the Domain Name System
-   (DNS) for mapping between names and NSAP addresses.
-
-   This document defines the format of one new Resource Record (RR) for
-   the DNS for domain name-to-NSAP mapping. The RR may be used with any
-   NSAP address format.
-
-   NSAP-to-name translation is accomplished through use of the PTR RR
-   (see STD 13, RFC 1035 for a description of the PTR RR). This paper
-   describes how PTR RRs are used to support this translation.
-
-   This document obsoletes RFC 1348 and RFC 1637.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Manning & Colella                                               [Page 1]
-
-RFC 1706                      DNS NSAP RRs                  October 1994
-
-
-1.  Introduction
-
-   OSI lower layer protocols, comprising the connectionless network
-   protocol (CLNP) [5] and supporting routing protocols, are deployed in
-   some parts of the global Internet.  Maintenance and debugging of CLNP
-   connectivity is greatly aided by support in the Domain Name System
-   (DNS) [7] [8] for mapping between names and NSAP (network service
-   access point) addresses [6] [Note: NSAP and NSAP address are used
-   interchangeably throughout this memo].
-
-   This document defines the format of one new Resource Record (RR) for
-   the DNS for domain name-to-NSAP mapping. The RR may be used with any
-   NSAP address format.
-
-   NSAP-to-name translation is accomplished through use of the PTR RR
-   (see RFC 1035 for a description of the PTR RR). This paper describes
-   how PTR RRs are used to support this translation.
-
-   This memo assumes that the reader is familiar with the DNS. Some
-   familiarity with NSAPs is useful; see [1] or Annex A of [6] for
-   additional information.
-
-2.  Background
-
-   The reason for defining DNS mappings for NSAPs is to support the
-   existing CLNP deployment in the Internet.  Debugging with CLNP ping
-   and traceroute has become more difficult with only numeric NSAPs as
-   the scale of deployment has increased. Current debugging is supported
-   by maintaining and exchanging a configuration file with name/NSAP
-   mappings similar in function to hosts.txt. This suffers from the lack
-   of a central coordinator for this file and also from the perspective
-   of scaling.  The former describes the most serious short-term
-   problem. Scaling of a hosts.txt-like solution has well-known long-
-   term scaling difficiencies.
-
-3.  Scope
-
-   The methods defined in this paper are applicable to all NSAP formats.
-
-   As a point of reference, there is a distinction between registration
-   and publication of addresses. For IP addresses, the IANA is the root
-   registration authority and the DNS a publication method. For NSAPs,
-   Annex A of the network service definition, ISO8348 [6], describes the
-   root registration authority and this memo defines how the DNS is used
-   as a publication method.
-
-
-
-
-
-
-Manning & Colella                                               [Page 2]
-
-RFC 1706                      DNS NSAP RRs                  October 1994
-
-
-4.  Structure of NSAPs
-
-   NSAPs are hierarchically structured to allow distributed
-   administration and efficient routing. Distributed administration
-   permits subdelegated addressing authorities to, as allowed by the
-   delegator, further structure the portion of the NSAP space under
-   their delegated control.  Accomodating this distributed authority
-   requires that there be little or no a priori knowledge of the
-   structure of NSAPs built into DNS resolvers and servers.
-
-   For the purposes of this memo, NSAPs can be thought of as a tree of
-   identifiers. The root of the tree is ISO8348 [6], and has as its
-   immediately registered subordinates the one-octet Authority and
-   Format Identifiers (AFIs) defined there. The size of subsequently-
-   defined fields depends on which branch of the tree is taken. The
-   depth of the tree varies according to the authority responsible for
-   defining subsequent fields.
-
-   An example is the authority under which U.S. GOSIP defines NSAPs [2].
-   Under the AFI of 47, NIST (National Institute of Standards and
-   Technology) obtained a value of 0005 (the AFI of 47 defines the next
-   field as being two octets consisting of four BCD digits from the
-   International Code Designator space [3]). NIST defined the subsequent
-   fields in [2], as shown in Figure 1. The field immediately following
-   0005 is a format identifier for the rest of the U.S. GOSIP NSAP
-   structure, with a hex value of 80. Following this is the three-octet
-   field, values for which are allocated to network operators; the
-   registration authority for this field is delegated to GSA (General
-   Services Administration).
-
-   The last octet of the NSAP is the NSelector (NSel). In practice, the
-   NSAP minus the NSel identifies the CLNP protocol machine on a given
-   system, and the NSel identifies the CLNP user. Since there can be
-   more than one CLNP user (meaning multiple NSel values for a given
-   "base" NSAP), the representation of the NSAP should be CLNP-user
-   independent. To achieve this, an NSel value of zero shall be used
-   with all NSAP values stored in the DNS. An NSAP with NSel=0
-   identifies the network layer itself. It is left to the application
-   retrieving the NSAP to determine the appropriate value to use in that
-   instance of communication.
-
-   When CLNP is used to support TCP and UDP services, the NSel value
-   used is the appropriate IP PROTO value as registered with the IANA.
-   For "standard" OSI, the selection of NSel values is left as a matter
-   of local administration. Administrators of systems that support the
-   OSI transport protocol [4] in addition to TCP/UDP must select NSels
-   for use by OSI Transport that do not conflict with the IP PROTO
-   values.
-
-
-
-Manning & Colella                                               [Page 3]
-
-RFC 1706                      DNS NSAP RRs                  October 1994
-
-
-              |--------------|
-              | <-- IDP -->  |
-              |--------------|-------------------------------------|
-              | AFI |  IDI   |            <-- DSP -->              |
-              |-----|--------|-------------------------------------|
-              | 47  |  0005  | DFI | AA |Rsvd | RD |Area | ID |Sel |
-              |-----|--------|-----|----|-----|----|-----|----|----|
-       octets |  1  |   2    |  1  | 3  |  2  | 2  |  2  | 6  | 1  |
-              |-----|--------|-----|----|-----|----|-----|----|----|
-
-                    IDP    Initial Domain Part
-                    AFI    Authority and Format Identifier
-                    IDI    Initial Domain Identifier
-                    DSP    Domain Specific Part
-                    DFI    DSP Format Identifier
-                    AA     Administrative Authority
-                    Rsvd   Reserved
-                    RD     Routing Domain Identifier
-                    Area   Area Identifier
-                    ID     System Identifier
-                    SEL    NSAP Selector
-
-                  Figure 1: GOSIP Version 2 NSAP structure.
-
-
-   In the NSAP RRs in Master Files and in the printed text in this memo,
-   NSAPs are often represented as a string of "."-separated hex values.
-   The values correspond to convenient divisions of the NSAP to make it
-   more readable. For example, the "."-separated fields might correspond
-   to the NSAP fields as defined by the appropriate authority (RARE,
-   U.S. GOSIP, ANSI, etc.). The use of this notation is strictly for
-   readability. The "."s do not appear in DNS packets and DNS servers
-   can ignore them when reading Master Files. For example, a printable
-   representation of the first four fields of a U.S. GOSIP NSAP might
-   look like
-
-                             47.0005.80.005a00
-
-   and a full U.S. GOSIP NSAP might appear as
-
-             47.0005.80.005a00.0000.1000.0020.00800a123456.00.
-
-   Other NSAP formats have different lengths and different
-   administratively defined field widths to accomodate different
-   requirements. For more information on NSAP formats in use see RFC
-   1629 [1].
-
-
-
-
-
-Manning & Colella                                               [Page 4]
-
-RFC 1706                      DNS NSAP RRs                  October 1994
-
-
-5.  The NSAP RR
-
-   The NSAP RR is defined with mnemonic "NSAP" and TYPE code 22
-   (decimal) and is used to map from domain names to NSAPs. Name-to-NSAP
-   mapping in the DNS using the NSAP RR operates analogously to IP
-   address lookup. A query is generated by the resolver requesting an
-   NSAP RR for a provided domain name.
-
-   NSAP RRs conform to the top level RR format and semantics as defined
-   in Section 3.2.1 of RFC 1035.
-
-                                            1  1  1  1  1  1
-              0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
-           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-           |                                               |
-           /                                               /
-           /                        NAME                   /
-           |                                               |
-           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-           |                    TYPE = NSAP                |
-           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-           |                    CLASS = IN                 |
-           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-           |                        TTL                    |
-           |                                               |
-           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-           |                      RDLENGTH                 |
-           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-           /                       RDATA                   /
-           /                                               /
-           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-   where:
-
-   *  NAME: an owner name, i.e., the name of the node to which this
-      resource record pertains.
-
-   *  TYPE: two octets containing the NSAP RR TYPE code of 22 (decimal).
-
-   *  CLASS: two octets containing the RR IN CLASS code of 1.
-
-   *  TTL: a 32 bit signed integer that specifies the time interval in
-      seconds that the resource record may be cached before the source
-      of the information should again be consulted. Zero values are
-      interpreted to mean that the RR can only be used for the
-      transaction in progress, and should not be cached. For example,
-      SOA records are always distributed with a zero TTL to prohibit
-      caching. Zero values can also be used for extremely volatile data.
-
-
-
-Manning & Colella                                               [Page 5]
-
-RFC 1706                      DNS NSAP RRs                  October 1994
-
-
-   *  RDLENGTH: an unsigned 16 bit integer that specifies the length in
-      octets of the RDATA field.
-
-   *  RDATA: a variable length string of octets containing the NSAP.
-      The value is the binary encoding of the NSAP as it would appear in
-      the CLNP source or destination address field. A typical example of
-      such an NSAP (in hex) is shown below. For this NSAP, RDLENGTH is
-      20 (decimal); "."s have been omitted to emphasize that they don't
-      appear in the DNS packets.
-
-                 39840f80005a0000000001e13708002010726e00
-
-   NSAP RRs cause no additional section processing.
-
-6.  NSAP-to-name Mapping Using the PTR RR
-
-   The PTR RR is defined in RFC 1035. This RR is typically used under
-   the "IN-ADDR.ARPA" domain to map from IPv4 addresses to domain names.
-
-   Similarly, the PTR RR is used to map from NSAPs to domain names under
-   the "NSAP.INT" domain. A domain name is generated from the NSAP
-   according to the rules described below. A query is sent by the
-   resolver requesting a PTR RR for the provided domain name.
-
-   A domain name is generated from an NSAP by reversing the hex nibbles
-   of the NSAP, treating each nibble as a separate subdomain, and
-   appending the top-level subdomain name "NSAP.INT" to it. For example,
-   the domain name used in the reverse lookup for the NSAP
-
-             47.0005.80.005a00.0000.0001.e133.ffffff000162.00
-
-   would appear as
-
-     0.0.2.6.1.0.0.0.f.f.f.f.f.f.3.3.1.e.1.0.0.0.0.0.0.0.0.0.a.5.0.0. \
-                         0.8.5.0.0.0.7.4.NSAP.INT.
-
-   [Implementation note: For sanity's sake user interfaces should be
-   designed to allow users to enter NSAPs using their natural order,
-   i.e., as they are typically written on paper. Also, arbitrary "."s
-   should be allowed (and ignored) on input.]
-
-7.  Master File Format
-
-   The format of NSAP RRs (and NSAP-related PTR RRs) in Master Files
-   conforms to Section 5, "Master Files," of RFC 1035. Below are
-   examples of the use of these RRs in Master Files to support name-to-
-   NSAP and NSAP-to-name mapping.
-
-
-
-
-Manning & Colella                                               [Page 6]
-
-RFC 1706                      DNS NSAP RRs                  October 1994
-
-
-   The NSAP RR introduces a new hex string format for the RDATA field.
-   The format is "0x" (i.e., a zero followed by an 'x' character)
-   followed by a variable length string of hex characters (0 to 9, a to
-   f). The hex string is case-insensitive. "."s (i.e., periods) may be
-   inserted in the hex string anywhere after the "0x" for readability.
-   The "."s have no significance other than for readability and are not
-   propagated in the protocol (e.g., queries or zone transfers).
-
-
-   ;;;;;;
-   ;;;;;; Master File for domain nsap.nist.gov.
-   ;;;;;;
-
-
-   @      IN     SOA    emu.ncsl.nist.gov.  root.emu.ncsl.nist.gov. (
-                                     1994041800   ; Serial  - date
-                                     1800         ; Refresh - 30 minutes
-                                     300          ; Retry   - 5 minutes
-                                     604800       ; Expire  - 7 days
-                                     3600 )       ; Minimum - 1 hour
-          IN     NS     emu.ncsl.nist.gov.
-          IN     NS     tuba.nsap.lanl.gov.
-   ;
-   ;
-   $ORIGIN nsap.nist.gov.
-   ;
-   ;     hosts
-   ;
-   bsdi1    IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000161.00
-            IN  A     129.6.224.161
-            IN  HINFO PC_486    BSDi1.1
-   ;
-   bsdi2    IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000162.00
-            IN  A     129.6.224.162
-            IN  HINFO PC_486    BSDi1.1
-   ;
-   cursive  IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000171.00
-            IN  A     129.6.224.171
-            IN  HINFO PC_386    DOS_5.0/NCSA_Telnet(TUBA)
-   ;
-   infidel  IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000164.00
-            IN  A     129.6.55.164
-            IN  HINFO PC/486    BSDi1.0(TUBA)
-   ;
-   ;     routers
-   ;
-   cisco1   IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.aaaaaa000151.00
-            IN  A     129.6.224.151
-
-
-
-Manning & Colella                                               [Page 7]
-
-RFC 1706                      DNS NSAP RRs                  October 1994
-
-
-            IN  A     129.6.225.151
-            IN  A     129.6.229.151
-   ;
-   3com1    IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.aaaaaa000111.00
-            IN  A     129.6.224.111
-            IN  A     129.6.225.111
-            IN  A     129.6.228.111
-
-
-
-
-   ;;;;;;
-   ;;;;;; Master File for reverse mapping of NSAPs under the
-   ;;;;;;     NSAP prefix:
-   ;;;;;;
-   ;;;;;;          47.0005.80.005a00.0000.0001.e133
-   ;;;;;;
-
-
-   @      IN     SOA    emu.ncsl.nist.gov.  root.emu.ncsl.nist.gov. (
-                                     1994041800   ; Serial  - date
-                                     1800         ; Refresh - 30 minutes
-                                     300          ; Retry   - 5 minutes
-                                     604800       ; Expire  - 7 days
-                                     3600 )       ; Minimum - 1 hour
-          IN     NS     emu.ncsl.nist.gov.
-          IN     NS     tuba.nsap.lanl.gov.
-   ;
-   ;
-   $ORIGIN 3.3.1.e.1.0.0.0.0.0.0.0.0.0.a.5.0.0.0.8.5.0.0.0.7.4.NSAP.INT.
-   ;
-   0.0.1.6.1.0.0.0.f.f.f.f.f.f  IN    PTR  bsdi1.nsap.nist.gov.
-   ;
-   0.0.2.6.1.0.0.0.f.f.f.f.f.f  IN    PTR  bsdi2.nsap.nist.gov.
-   ;
-   0.0.1.7.1.0.0.0.f.f.f.f.f.f  IN    PTR  cursive.nsap.nist.gov.
-   ;
-   0.0.4.6.1.0.0.0.f.f.f.f.f.f  IN    PTR  infidel.nsap.nist.gov.
-   ;
-   0.0.1.5.1.0.0.0.a.a.a.a.a.a  IN    PTR  cisco1.nsap.nist.gov.
-   ;
-   0.0.1.1.1.0.0.0.a.a.a.a.a.a  IN    PTR  3com1.nsap.nist.gov.
-
-8.  Security Considerations
-
-   Security issues are not discussed in this memo.
-
-
-
-
-
-Manning & Colella                                               [Page 8]
-
-RFC 1706                      DNS NSAP RRs                  October 1994
-
-
-9.  Authors' Addresses
-
-   Bill Manning
-   USC/Information Sciences Institute
-   4676 Admiralty Way
-   Marina del Rey, CA. 90292
-   USA
-
-   Phone: +1.310.822.1511
-   EMail: bmanning@isi.edu
-
-
-   Richard Colella
-   National Institute of Standards and Technology
-   Technology/B217
-   Gaithersburg, MD 20899
-   USA
-
-   Phone: +1 301-975-3627
-   Fax: +1 301 590-0932
-   EMail: colella@nist.gov
-
-10.  References
-
-   [1] Colella, R., Gardner, E., Callon, R., and Y. Rekhter, "Guidelines
-       for OSI NSAP Allocation inh the Internet", RFC 1629, NIST,
-       Wellfleet, Mitre, T.J. Watson Research Center, IBM Corp., May
-       1994.
-
-   [2] GOSIP Advanced Requirements Group.  Government Open Systems
-       Interconnection Profile (GOSIP) Version 2. Federal Information
-       Processing Standard 146-1, U.S. Department of Commerce, National
-       Institute of Standards and Technology, Gaithersburg, MD, April
-       1991.
-
-   [3] ISO/IEC.  Data interchange - structures for the identification of
-       organization.  International Standard 6523, ISO/IEC JTC 1,
-       Switzerland, 1984.
-
-   [4] ISO/IEC. Connection oriented transport protocol specification.
-       International Standard 8073, ISO/IEC JTC 1, Switzerland, 1986.
-
-   [5] ISO/IEC.  Protocol for Providing the Connectionless-mode Network
-       Service.  International Standard 8473, ISO/IEC JTC 1,
-       Switzerland, 1986.
-
-
-
-
-
-
-Manning & Colella                                               [Page 9]
-
-RFC 1706                      DNS NSAP RRs                  October 1994
-
-
-   [6] ISO/IEC. Information Processing Systems -- Data Communications --
-       Network Service Definition.  International Standard 8348, ISO/IEC
-       JTC 1, Switzerland, 1993.
-
-   [7] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
-       13, RFC 1034, USC/Information Sciences Institute, November 1987.
-
-   [8] Mockapetris, P., "Domain Names -- Implementation and
-       Specification", STD 13, RFC 1035, USC/Information Sciences
-       Institute, November 1987.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Manning & Colella                                              [Page 10]
-
diff --git a/contrib/bind9/doc/rfc/rfc1712.txt b/contrib/bind9/doc/rfc/rfc1712.txt
deleted file mode 100644
index 40d8857..0000000
--- a/contrib/bind9/doc/rfc/rfc1712.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         C. Farrell
-Request for Comments: 1712                                    M. Schulze
-Category: Experimental                                       S. Pleitner
-                                                              D. Baldoni
-                                         Curtin University of Technology
-                                                           November 1994
-
-
-                 DNS Encoding of Geographical Location
-
-Status of this Memo
-
-   This memo defines an Experimental Protocol for the Internet
-   community.  This memo does not specify an Internet standard of any
-   kind.  Discussion and suggestions for improvement are requested.
-   Distribution of this memo is unlimited.
-
-Abstract
-
-   This document defines the format of a new Resource Record (RR) for
-   the Domain Naming System (DNS), and reserves a corresponding DNS type
-   mnemonic and numerical code.  This definition deals with associating
-   geographical host location mappings to host names within a domain.
-   The data shown in this document is fictitious and does not
-   necessarily reflect the real Internet.
-
-1. Introduction
-
-   It has been a long standing problem to relate IP numbers to
-   geographical locations. The availability of Geographical location
-   information has immediate applications in network management.  Such
-   information can be used to supplement the data already provided by
-   utilities such as whois [Har85], traceroute [VJ89], and nslookup
-   [UCB89].  The usefulness and functionality of these already widely
-   used tools would be greatly enhanced by the provision of reliable
-   geographical location information.
-
-   The ideal way to manage and maintain a database of information, such
-   as geographical location of internet hosts, is to delegate
-   responsibility to local domain administrators. A large distributed
-   database could be implemented with a simple mechanism for updating
-   the local information.  A query mechanism also has to be available
-   for checking local entries, as well as inquiring about data from
-   non-local domains.
-
-
-
-
-
-
-
-Farrell, Schulze, Pleitner & Baldoni                            [Page 1]
-
-RFC 1712         DNS Encoding of Geographical Location     November 1994
-
-
-2. Background
-
-   The Internet continues to grow at an ever increasing rate with IP
-   numbers allocated on a first-come-first-serve basis.  Deciding when
-   and how to setup a database of geographical information about
-   internet hosts presented a number of options.  The uumap project
-   [UU85] was the first serious attempt to collect geographical location
-   data from sites and store it centrally.  This project met with
-   limited success because of the difficulty in maintaining and updating
-   a large central database.  Another problem was the lack of tools for
-   the checking the data supplied, this problem resulted in some
-   erroneous data entering the database.
-
-2.1 SNMP:
-
-   Using an SNMP get request on the sysLocation MIB (Management
-   Information Base) variable was also an option, however this would
-   require the host to be running an appropriate agent with public read
-   access.  It was also felt that MIB data should reflect local
-   management data (e.g., "this" host is on level 5 room 74) rather than
-   a hosts geographical position.  This view is supported in the
-   examples given in literature in this area [ROSE91].
-
-2.2 X500:
-
-   The X.500 Directory service [X.500.88] defined as part of the ISO
-   standards also appears as a potential provider of geographical
-   location data. However due to the limited implementations of this
-   service it was decided to defer this until this service gains wider
-   use and acceptance within the Internet community.
-
-2.3 BIND:
-
-   The DNS [Mock87a][Mock87b] represents an existing system ideally
-   suited to the provision of host specific information. The DNS is a
-   widely used and well-understood mechanism for providing a distributed
-   database of such information and its extensible nature allows it to
-   be used to disseminate virtually any information.  The most commonly
-   used DNS implementation is the Berkeley Internet Name Domain server
-   BIND [UCB89].  The information we wished to make available needed to
-   be updated locally but available globally; a perfect match with the
-   services provided by the DNS. Current DNS servers provide a variety
-   of useful information about hosts in their domain but lack the
-   ability to report a host's geographical location.
-
-
-
-
-
-
-
-Farrell, Schulze, Pleitner & Baldoni                            [Page 2]
-
-RFC 1712         DNS Encoding of Geographical Location     November 1994
-
-
-3. RDATA Format
-
-        MSB                                        LSB
-        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-        /                 LONGITUDE                  /
-        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-        /                  LATITUDE                  /
-        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-        /                  ALTITUDE                  /
-        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-   where:
-
-   LONGITUDE The real number describing the longitude encoded as a
-             printable string. The precision is limited by 256 charcters
-             within the range -90..90 degrees. Positive numbers
-             indicate locations north of the equator.
-
-   LATITUDE The real number describing the latitude encoded as a
-            printable string. The precision is limited by 256 charcters
-            within the range -180..180 degrees. Positive numbers
-            indicate locations east of the prime meridian.
-
-   ALTITUDE The real number describing the altitude (in meters) from
-            mean sea-level encoded as a printable string. The precision
-            is limited by 256 charcters. Positive numbers indicate
-            locations above mean sea-level.
-
-   Latitude/Longitude/Altitude values are encoded as strings as to avoid
-   the precision limitations imposed by encoding as unsigned integers.
-   Although this might not be considered optimal, it allows for a very
-   high degree of precision with an acceptable average encoded record
-   length.
-
-4. The GPOS RR
-
-   The geographical location is defined with the mnemonic GPOS and type
-   code 27.
-
-   GPOS has the following format:
-           <owner> <ttl> <class> GPOS <longitude> <latitude> <altitude>
-
-   A floating point format was chosen to specify geographical locations
-   for reasons of simplicity.  This also guarantees a concise
-   unambiguous description of a location by enforcing three compulsory
-   numerical values to be specified.
-
-
-
-
-
-Farrell, Schulze, Pleitner & Baldoni                            [Page 3]
-
-RFC 1712         DNS Encoding of Geographical Location     November 1994
-
-
-   The owner, ttl, and class fields are optional and default to the last
-   defined value if omitted. The longitude is a floating point number
-   ranging from -90 to 90 with positive values indicating locations
-   north of the equator.  For example Perth, Western Australia is
-   located at 32^ 7` 19" south of the equator which would be specified
-   as -32.68820.  The latitude is a number ranging from -180.0 to 180.0.
-   For example Perth, Western Australia is located at 116^ 2' 25" east
-   of the prime meridian which would be specified as 116.86520.  Curtin
-   University, Perth is also 10 meters above sea-level.
-
-   The valid GPOS record for a host at Curtin University in  Perth
-   Western Australia would therefore be:
-
-                GPOS -32.6882 116.8652 10.0
-
-   There is no limit imposed on the number of decimal places, although
-   the length of the encoded string is limited to 256 characters for
-   each field. It is also suggested that administrators limit their
-   entries to the minimum number of necessary characters in each field.
-
-5. Master File Format
-
-   Each host requires its own GPOS field in the corresponding  DNS RR to
-   explicitly specify its geographical location and altitude.  If the
-   GPOS field is omitted, a DNS enquiry will return no position
-   information for that host.
-
-   Consider the following example:
-
-; Authoritative data for cs.curtin.edu.au.
-;
-@     IN    SOA     marsh.cs.curtin.edu.au. postmaster.cs.curtin.edu.au.
-                (
-                        94070503        ; Serial (yymmddnn)
-                        10800           ; Refresh (3 hours)
-                        3600            ; Retry (1 hour)
-                        3600000         ; Expire (1000 hours)
-                        86400           ; Minimum (24 hours)
-                )
-
-                IN      NS      marsh.cs.curtin.edu.au.
-
-marsh           IN      A       134.7.1.1
-                IN      MX      0       marsh
-                IN      HINFO   SGI-Indigo IRIX-4.0.5F
-                IN      GPOS    -32.6882 116.8652 10.0
-ftp             IN      CNAME   marsh
-
-
-
-
-Farrell, Schulze, Pleitner & Baldoni                            [Page 4]
-
-RFC 1712         DNS Encoding of Geographical Location     November 1994
-
-
-lillee          IN      A       134.7.1.2
-                IN      MX      0       marsh
-                IN      HINFO   SGI-Indigo IRIX-4.0.5F
-                IN      GPOS    -32.6882 116.8652 10.0
-
-hinault         IN      A       134.7.1.23
-                IN      MX      0       marsh
-                IN      HINFO   SUN-IPC SunOS-4.1.3
-                IN      GPOS    -22.6882 116.8652 250.0
-
-merckx          IN      A       134.7.1.24
-                IN      MX      0       marsh
-                IN      HINFO   SUN-IPC SunOS-4.1.1
-
-ambrose         IN      A       134.7.1.99
-                IN      MX      0       marsh
-                IN      HINFO   SGI-CHALLENGE_L IRIX-5.2
-                IN      GPOS    -32.6882 116.8652 10.0
-
-   The hosts marsh, lillee, and ambrose are all at the same geographical
-   location, Perth Western Australia (-32.68820 116.86520). The host
-   hinault is at a different geographical location, 10 degrees north of
-   Perth in the mountains (-22.6882 116.8652 250.0). For security
-   reasons we do not wish to give the location of the host merckx.
-
-   Although the GPOS clause is not a standard entry within BIND
-   configuration files, most vendor implementations seem to ignore
-   whatever is not understood upon startup of the DNS.  Usually this
-   will result in a number of warnings appearing in system log files,
-   but in no way alters naming information or impedes the DNS from
-   performing its normal duties.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Farrell, Schulze, Pleitner & Baldoni                            [Page 5]
-
-RFC 1712         DNS Encoding of Geographical Location     November 1994
-
-
-7. References
-
-   [ROSE91]        Rose M., "The Simple Book: An Introduction to
-                   Management of TCP/IP-based Internets", Prentice-Hall,
-                   Englewood Cliffs, New Jersey, 1991.
-
-   [X.500.88]      CCITT: The Directory - Overview of Concepts, Models
-                   and Services", Recommendations X.500 - X.521.
-
-   [Har82]         Harrenstein K, Stahl M., and E. Feinler,
-                   "NICNAME/WHOIS" RFC 812, SRI NIC, March 1982.
-
-   [Mock87a]       Mockapetris P., "Domain Names - Concepts and
-                   Facilities", STD 13, RFC 1034, USC/Information
-                   Sciences Institute, November 1987.
-
-   [Mock87b]       Mockapetris P., "Domain Names - Implementation and
-                   Specification", STD 13, RFC 1035, USC/Information
-                   Sciences Institute, November 1987.
-
-   [FRB93]         Ford P., Rekhter Y., and H-W. Braun, "Improving the
-                   Routing and Addressing of IP", IEEE Network
-                   Vol.7, No. 3, pp. 11-15, May 1993.
-
-   [VJ89]          Jacobsen V., "The Traceroute(8) Manual Page",
-                   Lawrence Berkeley Laboratory, Berkeley,
-                   CA, February 1989.
-
-   [UCB89]         University of California, "BIND: Berkeley Internet
-                   Name Domain Server", 1989.
-   [UU85]          UUCP Mapping Project, Software available via
-                   anonymous FTP from ftp.uu.net., 1985.
-
-8. Security Considerations
-
-   Once information has been entered into the DNS, it is considered
-   public.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Farrell, Schulze, Pleitner & Baldoni                            [Page 6]
-
-RFC 1712         DNS Encoding of Geographical Location     November 1994
-
-
-9. Authors' Addresses
-
-   Craig Farrell
-   Department of Computer Science
-   Curtin University of technology
-   GPO Box U1987 Perth,
-   Western Australia
-
-   EMail: craig@cs.curtin.edu.au
-
-
-   Mike Schulze
-   Department of Computer Science
-   Curtin University of technology
-   GPO Box U1987 Perth,
-   Western Australia
-
-   EMail: mike@cs.curtin.edu.au
-
-
-   Scott Pleitner
-   Department of Computer Science
-   Curtin University of technology
-   GPO Box U1987 Perth,
-   Western Australia
-
-   EMail: pleitner@cs.curtin.edu.au
-
-
-   Daniel Baldoni
-   Department of Computer Science
-   Curtin University of technology
-   GPO Box U1987 Perth,
-   Western Australia
-
-   EMail: flint@cs.curtin.edu.au
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Farrell, Schulze, Pleitner & Baldoni                            [Page 7]
-
diff --git a/contrib/bind9/doc/rfc/rfc1750.txt b/contrib/bind9/doc/rfc/rfc1750.txt
deleted file mode 100644
index 56d478c..0000000
--- a/contrib/bind9/doc/rfc/rfc1750.txt
+++ /dev/null
@@ -1,1683 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                   D. Eastlake, 3rd
-Request for Comments: 1750                                           DEC
-Category: Informational                                       S. Crocker
-                                                               Cybercash
-                                                             J. Schiller
-                                                                     MIT
-                                                           December 1994
-
-
-                Randomness Recommendations for Security
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  This memo
-   does not specify an Internet standard of any kind.  Distribution of
-   this memo is unlimited.
-
-Abstract
-
-   Security systems today are built on increasingly strong cryptographic
-   algorithms that foil pattern analysis attempts. However, the security
-   of these systems is dependent on generating secret quantities for
-   passwords, cryptographic keys, and similar quantities.  The use of
-   pseudo-random processes to generate secret quantities can result in
-   pseudo-security.  The sophisticated attacker of these security
-   systems may find it easier to reproduce the environment that produced
-   the secret quantities, searching the resulting small set of
-   possibilities, than to locate the quantities in the whole of the
-   number space.
-
-   Choosing random quantities to foil a resourceful and motivated
-   adversary is surprisingly difficult.  This paper points out many
-   pitfalls in using traditional pseudo-random number generation
-   techniques for choosing such quantities.  It recommends the use of
-   truly random hardware techniques and shows that the existing hardware
-   on many systems can be used for this purpose.  It provides
-   suggestions to ameliorate the problem when a hardware solution is not
-   available.  And it gives examples of how large such quantities need
-   to be for some particular applications.
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake, Crocker & Schiller                                    [Page 1]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-Acknowledgements
-
-   Comments on this document that have been incorporated were received
-   from (in alphabetic order) the following:
-
-        David M. Balenson (TIS)
-        Don Coppersmith (IBM)
-        Don T. Davis (consultant)
-        Carl Ellison (Stratus)
-        Marc Horowitz (MIT)
-        Christian Huitema (INRIA)
-        Charlie Kaufman (IRIS)
-        Steve Kent (BBN)
-        Hal Murray (DEC)
-        Neil Haller (Bellcore)
-        Richard Pitkin (DEC)
-        Tim Redmond (TIS)
-        Doug Tygar (CMU)
-
-Table of Contents
-
-   1. Introduction........................................... 3
-   2. Requirements........................................... 4
-   3. Traditional Pseudo-Random Sequences.................... 5
-   4. Unpredictability....................................... 7
-   4.1 Problems with Clocks and Serial Numbers............... 7
-   4.2 Timing and Content of External Events................  8
-   4.3 The Fallacy of Complex Manipulation..................  8
-   4.4 The Fallacy of Selection from a Large Database.......  9
-   5. Hardware for Randomness............................... 10
-   5.1 Volume Required...................................... 10
-   5.2 Sensitivity to Skew.................................. 10
-   5.2.1 Using Stream Parity to De-Skew..................... 11
-   5.2.2 Using Transition Mappings to De-Skew............... 12
-   5.2.3 Using FFT to De-Skew............................... 13
-   5.2.4 Using Compression to De-Skew....................... 13
-   5.3 Existing Hardware Can Be Used For Randomness......... 14
-   5.3.1 Using Existing Sound/Video Input................... 14
-   5.3.2 Using Existing Disk Drives......................... 14
-   6. Recommended Non-Hardware Strategy..................... 14
-   6.1 Mixing Functions..................................... 15
-   6.1.1 A Trivial Mixing Function.......................... 15
-   6.1.2 Stronger Mixing Functions.......................... 16
-   6.1.3 Diff-Hellman as a Mixing Function.................. 17
-   6.1.4 Using a Mixing Function to Stretch Random Bits..... 17
-   6.1.5 Other Factors in Choosing a Mixing Function........ 18
-   6.2 Non-Hardware Sources of Randomness................... 19
-   6.3 Cryptographically Strong Sequences................... 19
-
-
-
-Eastlake, Crocker & Schiller                                    [Page 2]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   6.3.1 Traditional Strong Sequences....................... 20
-   6.3.2 The Blum Blum Shub Sequence Generator.............. 21
-   7. Key Generation Standards.............................. 22
-   7.1 US DoD Recommendations for Password Generation....... 23
-   7.2 X9.17 Key Generation................................. 23
-   8. Examples of Randomness Required....................... 24
-   8.1  Password Generation................................. 24
-   8.2 A Very High Security Cryptographic Key............... 25
-   8.2.1 Effort per Key Trial............................... 25
-   8.2.2 Meet in the Middle Attacks......................... 26
-   8.2.3 Other Considerations............................... 26
-   9. Conclusion............................................ 27
-   10. Security Considerations.............................. 27
-   References............................................... 28
-   Authors' Addresses....................................... 30
-
-1. Introduction
-
-   Software cryptography is coming into wider use.  Systems like
-   Kerberos, PEM, PGP, etc. are maturing and becoming a part of the
-   network landscape [PEM].  These systems provide substantial
-   protection against snooping and spoofing.  However, there is a
-   potential flaw.  At the heart of all cryptographic systems is the
-   generation of secret, unguessable (i.e., random) numbers.
-
-   For the present, the lack of generally available facilities for
-   generating such unpredictable numbers is an open wound in the design
-   of cryptographic software.  For the software developer who wants to
-   build a key or password generation procedure that runs on a wide
-   range of hardware, the only safe strategy so far has been to force
-   the local installation to supply a suitable routine to generate
-   random numbers.  To say the least, this is an awkward, error-prone
-   and unpalatable solution.
-
-   It is important to keep in mind that the requirement is for data that
-   an adversary has a very low probability of guessing or determining.
-   This will fail if pseudo-random data is used which only meets
-   traditional statistical tests for randomness or which is based on
-   limited range sources, such as clocks.  Frequently such random
-   quantities are determinable by an adversary searching through an
-   embarrassingly small space of possibilities.
-
-   This informational document suggests techniques for producing random
-   quantities that will be resistant to such attack.  It recommends that
-   future systems include hardware random number generation or provide
-   access to existing hardware that can be used for this purpose.  It
-   suggests methods for use if such hardware is not available.  And it
-   gives some estimates of the number of random bits required for sample
-
-
-
-Eastlake, Crocker & Schiller                                    [Page 3]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   applications.
-
-2. Requirements
-
-   Probably the most commonly encountered randomness requirement today
-   is the user password. This is usually a simple character string.
-   Obviously, if a password can be guessed, it does not provide
-   security.  (For re-usable passwords, it is desirable that users be
-   able to remember the password.  This may make it advisable to use
-   pronounceable character strings or phrases composed on ordinary
-   words.  But this only affects the format of the password information,
-   not the requirement that the password be very hard to guess.)
-
-   Many other requirements come from the cryptographic arena.
-   Cryptographic techniques can be used to provide a variety of services
-   including confidentiality and authentication.  Such services are
-   based on quantities, traditionally called "keys", that are unknown to
-   and unguessable by an adversary.
-
-   In some cases, such as the use of symmetric encryption with the one
-   time pads [CRYPTO*] or the US Data Encryption Standard [DES], the
-   parties who wish to communicate confidentially and/or with
-   authentication must all know the same secret key.  In other cases,
-   using what are called asymmetric or "public key" cryptographic
-   techniques, keys come in pairs.  One key of the pair is private and
-   must be kept secret by one party, the other is public and can be
-   published to the world.  It is computationally infeasible to
-   determine the private key from the public key [ASYMMETRIC, CRYPTO*].
-
-   The frequency and volume of the requirement for random quantities
-   differs greatly for different cryptographic systems.  Using pure RSA
-   [CRYPTO*], random quantities are required when the key pair is
-   generated, but thereafter any number of messages can be signed
-   without any further need for randomness.  The public key Digital
-   Signature Algorithm that has been proposed by the US National
-   Institute of Standards and Technology (NIST) requires good random
-   numbers for each signature.  And encrypting with a one time pad, in
-   principle the strongest possible encryption technique, requires a
-   volume of randomness equal to all the messages to be processed.
-
-   In most of these cases, an adversary can try to determine the
-   "secret" key by trial and error.  (This is possible as long as the
-   key is enough smaller than the message that the correct key can be
-   uniquely identified.)  The probability of an adversary succeeding at
-   this must be made acceptably low, depending on the particular
-   application.  The size of the space the adversary must search is
-   related to the amount of key "information" present in the information
-   theoretic sense [SHANNON].  This depends on the number of different
-
-
-
-Eastlake, Crocker & Schiller                                    [Page 4]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   secret values possible and the probability of each value as follows:
-
-                      -----
-                       \
-        Bits-of-info =  \  - p   * log  ( p  )
-                        /     i       2    i
-                       /
-                      -----
-
-   where i varies from 1 to the number of possible secret values and p
-   sub i is the probability of the value numbered i.  (Since p sub i is
-   less than one, the log will be negative so each term in the sum will
-   be non-negative.)
-
-   If there are 2^n different values of equal probability, then n bits
-   of information are present and an adversary would, on the average,
-   have to try half of the values, or 2^(n-1) , before guessing the
-   secret quantity.  If the probability of different values is unequal,
-   then there is less information present and fewer guesses will, on
-   average, be required by an adversary.  In particular, any values that
-   the adversary can know are impossible, or are of low probability, can
-   be initially ignored by an adversary, who will search through the
-   more probable values first.
-
-   For example, consider a cryptographic system that uses 56 bit keys.
-   If these 56 bit keys are derived by using a fixed pseudo-random
-   number generator that is seeded with an 8 bit seed, then an adversary
-   needs to search through only 256 keys (by running the pseudo-random
-   number generator with every possible seed), not the 2^56 keys that
-   may at first appear to be the case. Only 8 bits of "information" are
-   in these 56 bit keys.
-
-3. Traditional Pseudo-Random Sequences
-
-   Most traditional sources of random numbers use deterministic sources
-   of "pseudo-random" numbers.  These typically start with a "seed"
-   quantity and use numeric or logical operations to produce a sequence
-   of values.
-
-   [KNUTH] has a classic exposition on pseudo-random numbers.
-   Applications he mentions are simulation of natural phenomena,
-   sampling, numerical analysis, testing computer programs, decision
-   making, and games.  None of these have the same characteristics as
-   the sort of security uses we are talking about.  Only in the last two
-   could there be an adversary trying to find the random quantity.
-   However, in these cases, the adversary normally has only a single
-   chance to use a guessed value.  In guessing passwords or attempting
-   to break an encryption scheme, the adversary normally has many,
-
-
-
-Eastlake, Crocker & Schiller                                    [Page 5]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   perhaps unlimited, chances at guessing the correct value and should
-   be assumed to be aided by a computer.
-
-   For testing the "randomness" of numbers, Knuth suggests a variety of
-   measures including statistical and spectral.  These tests check
-   things like autocorrelation between different parts of a "random"
-   sequence or distribution of its values.  They could be met by a
-   constant stored random sequence, such as the "random" sequence
-   printed in the CRC Standard Mathematical Tables [CRC].
-
-   A typical pseudo-random number generation technique, known as a
-   linear congruence pseudo-random number generator, is modular
-   arithmetic where the N+1th value is calculated from the Nth value by
-
-        V    = ( V  * a + b )(Mod c)
-         N+1      N
-
-   The above technique has a strong relationship to linear shift
-   register pseudo-random number generators, which are well understood
-   cryptographically [SHIFT*].  In such generators bits are introduced
-   at one end of a shift register as the Exclusive Or (binary sum
-   without carry) of bits from selected fixed taps into the register.
-
-   For example:
-
-      +----+     +----+     +----+                      +----+
-      | B  | <-- | B  | <-- | B  | <--  . . . . . . <-- | B  | <-+
-      |  0 |     |  1 |     |  2 |                      |  n |   |
-      +----+     +----+     +----+                      +----+   |
-        |                     |            |                     |
-        |                     |            V                  +-----+
-        |                     V            +----------------> |     |
-        V                     +-----------------------------> | XOR |
-        +---------------------------------------------------> |     |
-                                                              +-----+
-
-
-       V    = ( ( V  * 2 ) + B .xor. B ... )(Mod 2^n)
-        N+1         N         0       2
-
-   The goodness of traditional pseudo-random number generator algorithms
-   is measured by statistical tests on such sequences.  Carefully chosen
-   values of the initial V and a, b, and c or the placement of shift
-   register tap in the above simple processes can produce excellent
-   statistics.
-
-
-
-
-
-
-Eastlake, Crocker & Schiller                                    [Page 6]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   These sequences may be adequate in simulations (Monte Carlo
-   experiments) as long as the sequence is orthogonal to the structure
-   of the space being explored.  Even there, subtle patterns may cause
-   problems.  However, such sequences are clearly bad for use in
-   security applications.  They are fully predictable if the initial
-   state is known.  Depending on the form of the pseudo-random number
-   generator, the sequence may be determinable from observation of a
-   short portion of the sequence [CRYPTO*, STERN].  For example, with
-   the generators above, one can determine V(n+1) given knowledge of
-   V(n).  In fact, it has been shown that with these techniques, even if
-   only one bit of the pseudo-random values is released, the seed can be
-   determined from short sequences.
-
-   Not only have linear congruent generators been broken, but techniques
-   are now known for breaking all polynomial congruent generators
-   [KRAWCZYK].
-
-4. Unpredictability
-
-   Randomness in the traditional sense described in section 3 is NOT the
-   same as the unpredictability required for security use.
-
-   For example, use of a widely available constant sequence, such as
-   that from the CRC tables, is very weak against an adversary. Once
-   they learn of or guess it, they can easily break all security, future
-   and past, based on the sequence [CRC].  Yet the statistical
-   properties of these tables are good.
-
-   The following sections describe the limitations of some randomness
-   generation techniques and sources.
-
-4.1 Problems with Clocks and Serial Numbers
-
-   Computer clocks, or similar operating system or hardware values,
-   provide significantly fewer real bits of unpredictability than might
-   appear from their specifications.
-
-   Tests have been done on clocks on numerous systems and it was found
-   that their behavior can vary widely and in unexpected ways.  One
-   version of an operating system running on one set of hardware may
-   actually provide, say, microsecond resolution in a clock while a
-   different configuration of the "same" system may always provide the
-   same lower bits and only count in the upper bits at much lower
-   resolution.  This means that successive reads on the clock may
-   produce identical values even if enough time has passed that the
-   value "should" change based on the nominal clock resolution. There
-   are also cases where frequently reading a clock can produce
-   artificial sequential values because of extra code that checks for
-
-
-
-Eastlake, Crocker & Schiller                                    [Page 7]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   the clock being unchanged between two reads and increases it by one!
-   Designing portable application code to generate unpredictable numbers
-   based on such system clocks is particularly challenging because the
-   system designer does not always know the properties of the system
-   clocks that the code will execute on.
-
-   Use of a hardware serial number such as an Ethernet address may also
-   provide fewer bits of uniqueness than one would guess.  Such
-   quantities are usually heavily structured and subfields may have only
-   a limited range of possible values or values easily guessable based
-   on approximate date of manufacture or other data.  For example, it is
-   likely that most of the Ethernet cards installed on Digital Equipment
-   Corporation (DEC) hardware within DEC were manufactured by DEC
-   itself, which significantly limits the range of built in addresses.
-
-   Problems such as those described above related to clocks and serial
-   numbers make code to produce unpredictable quantities difficult if
-   the code is to be ported across a variety of computer platforms and
-   systems.
-
-4.2 Timing and Content of External Events
-
-   It is possible to measure the timing and content of mouse movement,
-   key strokes, and similar user events.  This is a reasonable source of
-   unguessable data with some qualifications.  On some machines, inputs
-   such as key strokes are buffered.  Even though the user's inter-
-   keystroke timing may have sufficient variation and unpredictability,
-   there might not be an easy way to access that variation.  Another
-   problem is that no standard method exists to sample timing details.
-   This makes it hard to build standard software intended for
-   distribution to a large range of machines based on this technique.
-
-   The amount of mouse movement or the keys actually hit are usually
-   easier to access than timings but may yield less unpredictability as
-   the user may provide highly repetitive input.
-
-   Other external events, such as network packet arrival times, can also
-   be used with care.  In particular, the possibility of manipulation of
-   such times by an adversary must be considered.
-
-4.3 The Fallacy of Complex Manipulation
-
-   One strategy which may give a misleading appearance of
-   unpredictability is to take a very complex algorithm (or an excellent
-   traditional pseudo-random number generator with good statistical
-   properties) and calculate a cryptographic key by starting with the
-   current value of a computer system clock as the seed.  An adversary
-   who knew roughly when the generator was started would have a
-
-
-
-Eastlake, Crocker & Schiller                                    [Page 8]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   relatively small number of seed values to test as they would know
-   likely values of the system clock.  Large numbers of pseudo-random
-   bits could be generated but the search space an adversary would need
-   to check could be quite small.
-
-   Thus very strong and/or complex manipulation of data will not help if
-   the adversary can learn what the manipulation is and there is not
-   enough unpredictability in the starting seed value.  Even if they can
-   not learn what the manipulation is, they may be able to use the
-   limited number of results stemming from a limited number of seed
-   values to defeat security.
-
-   Another serious strategy error is to assume that a very complex
-   pseudo-random number generation algorithm will produce strong random
-   numbers when there has been no theory behind or analysis of the
-   algorithm.  There is a excellent example of this fallacy right near
-   the beginning of chapter 3 in [KNUTH] where the author describes a
-   complex algorithm.  It was intended that the machine language program
-   corresponding to the algorithm would be so complicated that a person
-   trying to read the code without comments wouldn't know what the
-   program was doing.  Unfortunately, actual use of this algorithm
-   showed that it almost immediately converged to a single repeated
-   value in one case and a small cycle of values in another case.
-
-   Not only does complex manipulation not help you if you have a limited
-   range of seeds but blindly chosen complex manipulation can destroy
-   the randomness in a good seed!
-
-4.4 The Fallacy of Selection from a Large Database
-
-   Another strategy that can give a misleading appearance of
-   unpredictability is selection of a quantity randomly from a database
-   and assume that its strength is related to the total number of bits
-   in the database.  For example, typical USENET servers as of this date
-   process over 35 megabytes of information per day.  Assume a random
-   quantity was selected by fetching 32 bytes of data from a random
-   starting point in this data.  This does not yield 32*8 = 256 bits
-   worth of unguessability.  Even after allowing that much of the data
-   is human language and probably has more like 2 or 3 bits of
-   information per byte, it doesn't yield 32*2.5 = 80 bits of
-   unguessability.  For an adversary with access to the same 35
-   megabytes the unguessability rests only on the starting point of the
-   selection.  That is, at best, about 25 bits of unguessability in this
-   case.
-
-   The same argument applies to selecting sequences from the data on a
-   CD ROM or Audio CD recording or any other large public database.  If
-   the adversary has access to the same database, this "selection from a
-
-
-
-Eastlake, Crocker & Schiller                                    [Page 9]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   large volume of data" step buys very little.  However, if a selection
-   can be made from data to which the adversary has no access, such as
-   system buffers on an active multi-user system, it may be of some
-   help.
-
-5. Hardware for Randomness
-
-   Is there any hope for strong portable randomness in the future?
-   There might be.  All that's needed is a physical source of
-   unpredictable numbers.
-
-   A thermal noise or radioactive decay source and a fast, free-running
-   oscillator would do the trick directly [GIFFORD].  This is a trivial
-   amount of hardware, and could easily be included as a standard part
-   of a computer system's architecture.  Furthermore, any system with a
-   spinning disk or the like has an adequate source of randomness
-   [DAVIS].  All that's needed is the common perception among computer
-   vendors that this small additional hardware and the software to
-   access it is necessary and useful.
-
-5.1 Volume Required
-
-   How much unpredictability is needed?  Is it possible to quantify the
-   requirement in, say, number of random bits per second?
-
-   The answer is not very much is needed.  For DES, the key is 56 bits
-   and, as we show in an example in Section 8, even the highest security
-   system is unlikely to require a keying material of over 200 bits.  If
-   a series of keys are needed, it can be generated from a strong random
-   seed using a cryptographically strong sequence as explained in
-   Section 6.3.  A few hundred random bits generated once a day would be
-   enough using such techniques.  Even if the random bits are generated
-   as slowly as one per second and it is not possible to overlap the
-   generation process, it should be tolerable in high security
-   applications to wait 200 seconds occasionally.
-
-   These numbers are trivial to achieve.  It could be done by a person
-   repeatedly tossing a coin.  Almost any hardware process is likely to
-   be much faster.
-
-5.2 Sensitivity to Skew
-
-   Is there any specific requirement on the shape of the distribution of
-   the random numbers?  The good news is the distribution need not be
-   uniform.  All that is needed is a conservative estimate of how non-
-   uniform it is to bound performance.  Two simple techniques to de-skew
-   the bit stream are given below and stronger techniques are mentioned
-   in Section 6.1.2 below.
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 10]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-5.2.1 Using Stream Parity to De-Skew
-
-   Consider taking a sufficiently long string of bits and map the string
-   to "zero" or "one".  The mapping will not yield a perfectly uniform
-   distribution, but it can be as close as desired.  One mapping that
-   serves the purpose is to take the parity of the string.  This has the
-   advantages that it is robust across all degrees of skew up to the
-   estimated maximum skew and is absolutely trivial to implement in
-   hardware.
-
-   The following analysis gives the number of bits that must be sampled:
-
-   Suppose the ratio of ones to zeros is 0.5 + e : 0.5 - e, where e is
-   between 0 and 0.5 and is a measure of the "eccentricity" of the
-   distribution.  Consider the distribution of the parity function of N
-   bit samples.  The probabilities that the parity will be one or zero
-   will be the sum of the odd or even terms in the binomial expansion of
-   (p + q)^N, where p = 0.5 + e, the probability of a one, and q = 0.5 -
-   e, the probability of a zero.
-
-   These sums can be computed easily as
-
-                         N            N
-        1/2 * ( ( p + q )  + ( p - q )  )
-   and
-                         N            N
-        1/2 * ( ( p + q )  - ( p - q )  ).
-
-   (Which one corresponds to the probability the parity will be 1
-   depends on whether N is odd or even.)
-
-   Since p + q = 1 and p - q = 2e, these expressions reduce to
-
-                       N
-        1/2 * [1 + (2e) ]
-   and
-                       N
-        1/2 * [1 - (2e) ].
-
-   Neither of these will ever be exactly 0.5 unless e is zero, but we
-   can bring them arbitrarily close to 0.5.  If we want the
-   probabilities to be within some delta d of 0.5, i.e. then
-
-                            N
-        ( 0.5 + ( 0.5 * (2e)  ) )  <  0.5 + d.
-
-
-
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 11]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   Solving for N yields N > log(2d)/log(2e).  (Note that 2e is less than
-   1, so its log is negative.  Division by a negative number reverses
-   the sense of an inequality.)
-
-   The following table gives the length of the string which must be
-   sampled for various degrees of skew in order to come within 0.001 of
-   a 50/50 distribution.
-
-                       +---------+--------+-------+
-                       | Prob(1) |    e   |    N  |
-                       +---------+--------+-------+
-                       |   0.5   |  0.00  |    1  |
-                       |   0.6   |  0.10  |    4  |
-                       |   0.7   |  0.20  |    7  |
-                       |   0.8   |  0.30  |   13  |
-                       |   0.9   |  0.40  |   28  |
-                       |   0.95  |  0.45  |   59  |
-                       |   0.99  |  0.49  |  308  |
-                       +---------+--------+-------+
-
-   The last entry shows that even if the distribution is skewed 99% in
-   favor of ones, the parity of a string of 308 samples will be within
-   0.001 of a 50/50 distribution.
-
-5.2.2 Using Transition Mappings to De-Skew
-
-   Another technique, originally due to von Neumann [VON NEUMANN], is to
-   examine a bit stream as a sequence of non-overlapping pairs. You
-   could then discard any 00 or 11 pairs found, interpret 01 as a 0 and
-   10 as a 1.  Assume the probability of a 1 is 0.5+e and the
-   probability of a 0 is 0.5-e where e is the eccentricity of the source
-   and described in the previous section.  Then the probability of each
-   pair is as follows:
-
-            +------+-----------------------------------------+
-            | pair |            probability                  |
-            +------+-----------------------------------------+
-            |  00  | (0.5 - e)^2          =  0.25 - e + e^2  |
-            |  01  | (0.5 - e)*(0.5 + e)  =  0.25     - e^2  |
-            |  10  | (0.5 + e)*(0.5 - e)  =  0.25     - e^2  |
-            |  11  | (0.5 + e)^2          =  0.25 + e + e^2  |
-            +------+-----------------------------------------+
-
-   This technique will completely eliminate any bias but at the expense
-   of taking an indeterminate number of input bits for any particular
-   desired number of output bits.  The probability of any particular
-   pair being discarded is 0.5 + 2e^2 so the expected number of input
-   bits to produce X output bits is X/(0.25 - e^2).
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 12]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   This technique assumes that the bits are from a stream where each bit
-   has the same probability of being a 0 or 1 as any other bit in the
-   stream and that bits are not correlated, i.e., that the bits are
-   identical independent distributions.  If alternate bits were from two
-   correlated sources, for example, the above analysis breaks down.
-
-   The above technique also provides another illustration of how a
-   simple statistical analysis can mislead if one is not always on the
-   lookout for patterns that could be exploited by an adversary.  If the
-   algorithm were mis-read slightly so that overlapping successive bits
-   pairs were used instead of non-overlapping pairs, the statistical
-   analysis given is the same; however, instead of provided an unbiased
-   uncorrelated series of random 1's and 0's, it instead produces a
-   totally predictable sequence of exactly alternating 1's and 0's.
-
-5.2.3 Using FFT to De-Skew
-
-   When real world data consists of strongly biased or correlated bits,
-   it may still contain useful amounts of randomness.  This randomness
-   can be extracted through use of the discrete Fourier transform or its
-   optimized variant, the FFT.
-
-   Using the Fourier transform of the data, strong correlations can be
-   discarded.  If adequate data is processed and remaining correlations
-   decay, spectral lines approaching statistical independence and
-   normally distributed randomness can be produced [BRILLINGER].
-
-5.2.4 Using Compression to De-Skew
-
-   Reversible compression techniques also provide a crude method of de-
-   skewing a skewed bit stream.  This follows directly from the
-   definition of reversible compression and the formula in Section 2
-   above for the amount of information in a sequence.  Since the
-   compression is reversible, the same amount of information must be
-   present in the shorter output than was present in the longer input.
-   By the Shannon information equation, this is only possible if, on
-   average, the probabilities of the different shorter sequences are
-   more uniformly distributed than were the probabilities of the longer
-   sequences.  Thus the shorter sequences are de-skewed relative to the
-   input.
-
-   However, many compression techniques add a somewhat predicatable
-   preface to their output stream and may insert such a sequence again
-   periodically in their output or otherwise introduce subtle patterns
-   of their own.  They should be considered only a rough technique
-   compared with those described above or in Section 6.1.2.  At a
-   minimum, the beginning of the compressed sequence should be skipped
-   and only later bits used for applications requiring random bits.
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 13]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-5.3 Existing Hardware Can Be Used For Randomness
-
-   As described below, many computers come with hardware that can, with
-   care, be used to generate truly random quantities.
-
-5.3.1 Using Existing Sound/Video Input
-
-   Increasingly computers are being built with inputs that digitize some
-   real world analog source, such as sound from a microphone or video
-   input from a camera.  Under appropriate circumstances, such input can
-   provide reasonably high quality random bits.  The "input" from a
-   sound digitizer with no source plugged in or a camera with the lens
-   cap on, if the system has enough gain to detect anything, is
-   essentially thermal noise.
-
-   For example, on a SPARCstation, one can read from the /dev/audio
-   device with nothing plugged into the microphone jack.  Such data is
-   essentially random noise although it should not be trusted without
-   some checking in case of hardware failure.  It will, in any case,
-   need to be de-skewed as described elsewhere.
-
-   Combining this with compression to de-skew one can, in UNIXese,
-   generate a huge amount of medium quality random data by doing
-
-        cat /dev/audio | compress - >random-bits-file
-
-5.3.2 Using Existing Disk Drives
-
-   Disk drives have small random fluctuations in their rotational speed
-   due to chaotic air turbulence [DAVIS].  By adding low level disk seek
-   time instrumentation to a system, a series of measurements can be
-   obtained that include this randomness. Such data is usually highly
-   correlated so that significant processing is needed, including FFT
-   (see section 5.2.3).  Nevertheless experimentation has shown that,
-   with such processing, disk drives easily produce 100 bits a minute or
-   more of excellent random data.
-
-   Partly offsetting this need for processing is the fact that disk
-   drive failure will normally be rapidly noticed.  Thus, problems with
-   this method of random number generation due to hardware failure are
-   very unlikely.
-
-6. Recommended Non-Hardware Strategy
-
-   What is the best overall strategy for meeting the requirement for
-   unguessable random numbers in the absence of a reliable hardware
-   source?  It is to obtain random input from a large number of
-   uncorrelated sources and to mix them with a strong mixing function.
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 14]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   Such a function will preserve the randomness present in any of the
-   sources even if other quantities being combined are fixed or easily
-   guessable.  This may be advisable even with a good hardware source as
-   hardware can also fail, though this should be weighed against any
-   increase in the chance of overall failure due to added software
-   complexity.
-
-6.1 Mixing Functions
-
-   A strong mixing function is one which combines two or more inputs and
-   produces an output where each output bit is a different complex non-
-   linear function of all the input bits.  On average, changing any
-   input bit will change about half the output bits.  But because the
-   relationship is complex and non-linear, no particular output bit is
-   guaranteed to change when any particular input bit is changed.
-
-   Consider the problem of converting a stream of bits that is skewed
-   towards 0 or 1 to a shorter stream which is more random, as discussed
-   in Section 5.2 above.  This is simply another case where a strong
-   mixing function is desired, mixing the input bits to produce a
-   smaller number of output bits.  The technique given in Section 5.2.1
-   of using the parity of a number of bits is simply the result of
-   successively Exclusive Or'ing them which is examined as a trivial
-   mixing function immediately below.  Use of stronger mixing functions
-   to extract more of the randomness in a stream of skewed bits is
-   examined in Section 6.1.2.
-
-6.1.1 A Trivial Mixing Function
-
-   A trivial example for single bit inputs is the Exclusive Or function,
-   which is equivalent to addition without carry, as show in the table
-   below.  This is a degenerate case in which the one output bit always
-   changes for a change in either input bit.  But, despite its
-   simplicity, it will still provide a useful illustration.
-
-                   +-----------+-----------+----------+
-                   |  input 1  |  input 2  |  output  |
-                   +-----------+-----------+----------+
-                   |     0     |     0     |     0    |
-                   |     0     |     1     |     1    |
-                   |     1     |     0     |     1    |
-                   |     1     |     1     |     0    |
-                   +-----------+-----------+----------+
-
-   If inputs 1 and 2 are uncorrelated and combined in this fashion then
-   the output will be an even better (less skewed) random bit than the
-   inputs.  If we assume an "eccentricity" e as defined in Section 5.2
-   above, then the output eccentricity relates to the input eccentricity
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 15]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   as follows:
-
-        e       = 2 * e        * e
-         output        input 1    input 2
-
-   Since e is never greater than 1/2, the eccentricity is always
-   improved except in the case where at least one input is a totally
-   skewed constant.  This is illustrated in the following table where
-   the top and left side values are the two input eccentricities and the
-   entries are the output eccentricity:
-
-     +--------+--------+--------+--------+--------+--------+--------+
-     |    e   |  0.00  |  0.10  |  0.20  |  0.30  |  0.40  |  0.50  |
-     +--------+--------+--------+--------+--------+--------+--------+
-     |  0.00  |  0.00  |  0.00  |  0.00  |  0.00  |  0.00  |  0.00  |
-     |  0.10  |  0.00  |  0.02  |  0.04  |  0.06  |  0.08  |  0.10  |
-     |  0.20  |  0.00  |  0.04  |  0.08  |  0.12  |  0.16  |  0.20  |
-     |  0.30  |  0.00  |  0.06  |  0.12  |  0.18  |  0.24  |  0.30  |
-     |  0.40  |  0.00  |  0.08  |  0.16  |  0.24  |  0.32  |  0.40  |
-     |  0.50  |  0.00  |  0.10  |  0.20  |  0.30  |  0.40  |  0.50  |
-     +--------+--------+--------+--------+--------+--------+--------+
-
-   However, keep in mind that the above calculations assume that the
-   inputs are not correlated.  If the inputs were, say, the parity of
-   the number of minutes from midnight on two clocks accurate to a few
-   seconds, then each might appear random if sampled at random intervals
-   much longer than a minute.  Yet if they were both sampled and
-   combined with xor, the result would be zero most of the time.
-
-6.1.2 Stronger Mixing Functions
-
-   The US Government Data Encryption Standard [DES] is an example of a
-   strong mixing function for multiple bit quantities.  It takes up to
-   120 bits of input (64 bits of "data" and 56 bits of "key") and
-   produces 64 bits of output each of which is dependent on a complex
-   non-linear function of all input bits.  Other strong encryption
-   functions with this characteristic can also be used by considering
-   them to mix all of their key and data input bits.
-
-   Another good family of mixing functions are the "message digest" or
-   hashing functions such as The US Government Secure Hash Standard
-   [SHS] and the MD2, MD4, MD5 [MD2, MD4, MD5] series.  These functions
-   all take an arbitrary amount of input and produce an output mixing
-   all the input bits. The MD* series produce 128 bits of output and SHS
-   produces 160 bits.
-
-
-
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 16]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   Although the message digest functions are designed for variable
-   amounts of input, DES and other encryption functions can also be used
-   to combine any number of inputs.  If 64 bits of output is adequate,
-   the inputs can be packed into a 64 bit data quantity and successive
-   56 bit keys, padding with zeros if needed, which are then used to
-   successively encrypt using DES in Electronic Codebook Mode [DES
-   MODES].  If more than 64 bits of output are needed, use more complex
-   mixing.  For example, if inputs are packed into three quantities, A,
-   B, and C, use DES to encrypt A with B as a key and then with C as a
-   key to produce the 1st part of the output, then encrypt B with C and
-   then A for more output and, if necessary, encrypt C with A and then B
-   for yet more output.  Still more output can be produced by reversing
-   the order of the keys given above to stretch things. The same can be
-   done with the hash functions by hashing various subsets of the input
-   data to produce multiple outputs.  But keep in mind that it is
-   impossible to get more bits of "randomness" out than are put in.
-
-   An example of using a strong mixing function would be to reconsider
-   the case of a string of 308 bits each of which is biased 99% towards
-   zero.  The parity technique given in Section 5.2.1 above reduced this
-   to one bit with only a 1/1000 deviance from being equally likely a
-   zero or one.  But, applying the equation for information given in
-   Section 2, this 308 bit sequence has 5 bits of information in it.
-   Thus hashing it with SHS or MD5 and taking the bottom 5 bits of the
-   result would yield 5 unbiased random bits as opposed to the single
-   bit given by calculating the parity of the string.
-
-6.1.3 Diffie-Hellman as a Mixing Function
-
-   Diffie-Hellman exponential key exchange is a technique that yields a
-   shared secret between two parties that can be made computationally
-   infeasible for a third party to determine even if they can observe
-   all the messages between the two communicating parties.  This shared
-   secret is a mixture of initial quantities generated by each of them
-   [D-H].  If these initial quantities are random, then the shared
-   secret contains the combined randomness of them both, assuming they
-   are uncorrelated.
-
-6.1.4 Using a Mixing Function to Stretch Random Bits
-
-   While it is not necessary for a mixing function to produce the same
-   or fewer bits than its inputs, mixing bits cannot "stretch" the
-   amount of random unpredictability present in the inputs.  Thus four
-   inputs of 32 bits each where there is 12 bits worth of
-   unpredicatability (such as 4,096 equally probable values) in each
-   input cannot produce more than 48 bits worth of unpredictable output.
-   The output can be expanded to hundreds or thousands of bits by, for
-   example, mixing with successive integers, but the clever adversary's
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 17]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   search space is still 2^48 possibilities.  Furthermore, mixing to
-   fewer bits than are input will tend to strengthen the randomness of
-   the output the way using Exclusive Or to produce one bit from two did
-   above.
-
-   The last table in Section 6.1.1 shows that mixing a random bit with a
-   constant bit with Exclusive Or will produce a random bit.  While this
-   is true, it does not provide a way to "stretch" one random bit into
-   more than one.  If, for example, a random bit is mixed with a 0 and
-   then with a 1, this produces a two bit sequence but it will always be
-   either 01 or 10.  Since there are only two possible values, there is
-   still only the one bit of original randomness.
-
-6.1.5 Other Factors in Choosing a Mixing Function
-
-   For local use, DES has the advantages that it has been widely tested
-   for flaws, is widely documented, and is widely implemented with
-   hardware and software implementations available all over the world
-   including source code available by anonymous FTP.  The SHS and MD*
-   family are younger algorithms which have been less tested but there
-   is no particular reason to believe they are flawed.  Both MD5 and SHS
-   were derived from the earlier MD4 algorithm.  They all have source
-   code available by anonymous FTP [SHS, MD2, MD4, MD5].
-
-   DES and SHS have been vouched for the the US National Security Agency
-   (NSA) on the basis of criteria that primarily remain secret.  While
-   this is the cause of much speculation and doubt, investigation of DES
-   over the years has indicated that NSA involvement in modifications to
-   its design, which originated with IBM, was primarily to strengthen
-   it.  No concealed or special weakness has been found in DES.  It is
-   almost certain that the NSA modification to MD4 to produce the SHS
-   similarly strengthened the algorithm, possibly against threats not
-   yet known in the public cryptographic community.
-
-   DES, SHS, MD4, and MD5 are royalty free for all purposes.  MD2 has
-   been freely licensed only for non-profit use in connection with
-   Privacy Enhanced Mail [PEM].  Between the MD* algorithms, some people
-   believe that, as with "Goldilocks and the Three Bears", MD2 is strong
-   but too slow, MD4 is fast but too weak, and MD5 is just right.
-
-   Another advantage of the MD* or similar hashing algorithms over
-   encryption algorithms is that they are not subject to the same
-   regulations imposed by the US Government prohibiting the unlicensed
-   export or import of encryption/decryption software and hardware.  The
-   same should be true of DES rigged to produce an irreversible hash
-   code but most DES packages are oriented to reversible encryption.
-
-
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 18]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-6.2 Non-Hardware Sources of Randomness
-
-   The best source of input for mixing would be a hardware randomness
-   such as disk drive timing affected by air turbulence, audio input
-   with thermal noise, or radioactive decay.  However, if that is not
-   available there are other possibilities.  These include system
-   clocks, system or input/output buffers, user/system/hardware/network
-   serial numbers and/or addresses and timing, and user input.
-   Unfortunately, any of these sources can produce limited or
-   predicatable values under some circumstances.
-
-   Some of the sources listed above would be quite strong on multi-user
-   systems where, in essence, each user of the system is a source of
-   randomness.  However, on a small single user system, such as a
-   typical IBM PC or Apple Macintosh, it might be possible for an
-   adversary to assemble a similar configuration.  This could give the
-   adversary inputs to the mixing process that were sufficiently
-   correlated to those used originally as to make exhaustive search
-   practical.
-
-   The use of multiple random inputs with a strong mixing function is
-   recommended and can overcome weakness in any particular input.  For
-   example, the timing and content of requested "random" user keystrokes
-   can yield hundreds of random bits but conservative assumptions need
-   to be made.  For example, assuming a few bits of randomness if the
-   inter-keystroke interval is unique in the sequence up to that point
-   and a similar assumption if the key hit is unique but assuming that
-   no bits of randomness are present in the initial key value or if the
-   timing or key value duplicate previous values.  The results of mixing
-   these timings and characters typed could be further combined with
-   clock values and other inputs.
-
-   This strategy may make practical portable code to produce good random
-   numbers for security even if some of the inputs are very weak on some
-   of the target systems.  However, it may still fail against a high
-   grade attack on small single user systems, especially if the
-   adversary has ever been able to observe the generation process in the
-   past.  A hardware based random source is still preferable.
-
-6.3 Cryptographically Strong Sequences
-
-   In cases where a series of random quantities must be generated, an
-   adversary may learn some values in the sequence.  In general, they
-   should not be able to predict other values from the ones that they
-   know.
-
-
-
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 19]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   The correct technique is to start with a strong random seed, take
-   cryptographically strong steps from that seed [CRYPTO2, CRYPTO3], and
-   do not reveal the complete state of the generator in the sequence
-   elements.  If each value in the sequence can be calculated in a fixed
-   way from the previous value, then when any value is compromised, all
-   future values can be determined.  This would be the case, for
-   example, if each value were a constant function of the previously
-   used values, even if the function were a very strong, non-invertible
-   message digest function.
-
-   It should be noted that if your technique for generating a sequence
-   of key values is fast enough, it can trivially be used as the basis
-   for a confidentiality system.  If two parties use the same sequence
-   generating technique and start with the same seed material, they will
-   generate identical sequences.  These could, for example, be xor'ed at
-   one end with data being send, encrypting it, and xor'ed with this
-   data as received, decrypting it due to the reversible properties of
-   the xor operation.
-
-6.3.1 Traditional Strong Sequences
-
-   A traditional way to achieve a strong sequence has been to have the
-   values be produced by hashing the quantities produced by
-   concatenating the seed with successive integers or the like and then
-   mask the values obtained so as to limit the amount of generator state
-   available to the adversary.
-
-   It may also be possible to use an "encryption" algorithm with a
-   random key and seed value to encrypt and feedback some or all of the
-   output encrypted value into the value to be encrypted for the next
-   iteration.  Appropriate feedback techniques will usually be
-   recommended with the encryption algorithm.  An example is shown below
-   where shifting and masking are used to combine the cypher output
-   feedback.  This type of feedback is recommended by the US Government
-   in connection with DES [DES MODES].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 20]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-      +---------------+
-      |       V       |
-      |  |     n      |
-      +--+------------+
-            |      |           +---------+
-            |      +---------> |         |      +-----+
-         +--+                  | Encrypt | <--- | Key |
-         |           +-------- |         |      +-----+
-         |           |         +---------+
-         V           V
-      +------------+--+
-      |      V     |  |
-      |       n+1     |
-      +---------------+
-
-   Note that if a shift of one is used, this is the same as the shift
-   register technique described in Section 3 above but with the all
-   important difference that the feedback is determined by a complex
-   non-linear function of all bits rather than a simple linear or
-   polynomial combination of output from a few bit position taps.
-
-   It has been shown by Donald W. Davies that this sort of shifted
-   partial output feedback significantly weakens an algorithm compared
-   will feeding all of the output bits back as input.  In particular,
-   for DES, repeated encrypting a full 64 bit quantity will give an
-   expected repeat in about 2^63 iterations.  Feeding back anything less
-   than 64 (and more than 0) bits will give an expected repeat in
-   between 2**31 and 2**32 iterations!
-
-   To predict values of a sequence from others when the sequence was
-   generated by these techniques is equivalent to breaking the
-   cryptosystem or inverting the "non-invertible" hashing involved with
-   only partial information available.  The less information revealed
-   each iteration, the harder it will be for an adversary to predict the
-   sequence.  Thus it is best to use only one bit from each value.  It
-   has been shown that in some cases this makes it impossible to break a
-   system even when the cryptographic system is invertible and can be
-   broken if all of each generated value was revealed.
-
-6.3.2 The Blum Blum Shub Sequence Generator
-
-   Currently the generator which has the strongest public proof of
-   strength is called the Blum Blum Shub generator after its inventors
-   [BBS].  It is also very simple and is based on quadratic residues.
-   It's only disadvantage is that is is computationally intensive
-   compared with the traditional techniques give in 6.3.1 above.  This
-   is not a serious draw back if it is used for moderately infrequent
-   purposes, such as generating session keys.
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 21]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   Simply choose two large prime numbers, say p and q, which both have
-   the property that you get a remainder of 3 if you divide them by 4.
-   Let n = p * q.  Then you choose a random number x relatively prime to
-   n.  The initial seed for the generator and the method for calculating
-   subsequent values are then
-
-                   2
-        s    =  ( x  )(Mod n)
-         0
-
-                   2
-        s    = ( s   )(Mod n)
-         i+1      i
-
-   You must be careful to use only a few bits from the bottom of each s.
-   It is always safe to use only the lowest order bit.  If you use no
-   more than the
-
-                  log  ( log  ( s  ) )
-                     2      2    i
-
-   low order bits, then predicting any additional bits from a sequence
-   generated in this manner is provable as hard as factoring n.  As long
-   as the initial x is secret, you can even make n public if you want.
-
-   An intersting characteristic of this generator is that you can
-   directly calculate any of the s values.  In particular
-
-                     i
-               ( ( 2  )(Mod (( p - 1 ) * ( q - 1 )) ) )
-      s  = ( s                                          )(Mod n)
-       i      0
-
-   This means that in applications where many keys are generated in this
-   fashion, it is not necessary to save them all.  Each key can be
-   effectively indexed and recovered from that small index and the
-   initial s and n.
-
-7. Key Generation Standards
-
-   Several public standards are now in place for the generation of keys.
-   Two of these are described below.  Both use DES but any equally
-   strong or stronger mixing function could be substituted.
-
-
-
-
-
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 22]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-7.1 US DoD Recommendations for Password Generation
-
-   The United States Department of Defense has specific recommendations
-   for password generation [DoD].  They suggest using the US Data
-   Encryption Standard [DES] in Output Feedback Mode [DES MODES] as
-   follows:
-
-        use an initialization vector determined from
-             the system clock,
-             system ID,
-             user ID, and
-             date and time;
-        use a key determined from
-             system interrupt registers,
-             system status registers, and
-             system counters; and,
-        as plain text, use an external randomly generated 64 bit
-        quantity such as 8 characters typed in by a system
-        administrator.
-
-   The password can then be calculated from the 64 bit "cipher text"
-   generated in 64-bit Output Feedback Mode.  As many bits as are needed
-   can be taken from these 64 bits and expanded into a pronounceable
-   word, phrase, or other format if a human being needs to remember the
-   password.
-
-7.2 X9.17 Key Generation
-
-   The American National Standards Institute has specified a method for
-   generating a sequence of keys as follows:
-
-        s  is the initial 64 bit seed
-         0
-
-        g  is the sequence of generated 64 bit key quantities
-         n
-
-        k is a random key reserved for generating this key sequence
-
-        t is the time at which a key is generated to as fine a resolution
-            as is available (up to 64 bits).
-
-        DES ( K, Q ) is the DES encryption of quantity Q with key K
-
-
-
-
-
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 23]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-        g    = DES ( k, DES ( k, t ) .xor. s  )
-         n                                  n
-
-        s    = DES ( k, DES ( k, t ) .xor. g  )
-         n+1                                n
-
-   If g sub n is to be used as a DES key, then every eighth bit should
-   be adjusted for parity for that use but the entire 64 bit unmodified
-   g should be used in calculating the next s.
-
-8. Examples of Randomness Required
-
-   Below are two examples showing rough calculations of needed
-   randomness for security.  The first is for moderate security
-   passwords while the second assumes a need for a very high security
-   cryptographic key.
-
-8.1  Password Generation
-
-   Assume that user passwords change once a year and it is desired that
-   the probability that an adversary could guess the password for a
-   particular account be less than one in a thousand.  Further assume
-   that sending a password to the system is the only way to try a
-   password.  Then the crucial question is how often an adversary can
-   try possibilities.  Assume that delays have been introduced into a
-   system so that, at most, an adversary can make one password try every
-   six seconds.  That's 600 per hour or about 15,000 per day or about
-   5,000,000 tries in a year.  Assuming any sort of monitoring, it is
-   unlikely someone could actually try continuously for a year.  In
-   fact, even if log files are only checked monthly, 500,000 tries is
-   more plausible before the attack is noticed and steps taken to change
-   passwords and make it harder to try more passwords.
-
-   To have a one in a thousand chance of guessing the password in
-   500,000 tries implies a universe of at least 500,000,000 passwords or
-   about 2^29.  Thus 29 bits of randomness are needed. This can probably
-   be achieved using the US DoD recommended inputs for password
-   generation as it has 8 inputs which probably average over 5 bits of
-   randomness each (see section 7.1).  Using a list of 1000 words, the
-   password could be expressed as a three word phrase (1,000,000,000
-   possibilities) or, using case insensitive letters and digits, six
-   would suffice ((26+10)^6 = 2,176,782,336 possibilities).
-
-   For a higher security password, the number of bits required goes up.
-   To decrease the probability by 1,000 requires increasing the universe
-   of passwords by the same factor which adds about 10 bits.  Thus to
-   have only a one in a million chance of a password being guessed under
-   the above scenario would require 39 bits of randomness and a password
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 24]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   that was a four word phrase from a 1000 word list or eight
-   letters/digits.  To go to a one in 10^9 chance, 49 bits of randomness
-   are needed implying a five word phrase or ten letter/digit password.
-
-   In a real system, of course, there are also other factors.  For
-   example, the larger and harder to remember passwords are, the more
-   likely users are to write them down resulting in an additional risk
-   of compromise.
-
-8.2 A Very High Security Cryptographic Key
-
-   Assume that a very high security key is needed for symmetric
-   encryption / decryption between two parties.  Assume an adversary can
-   observe communications and knows the algorithm being used.  Within
-   the field of random possibilities, the adversary can try key values
-   in hopes of finding the one in use.  Assume further that brute force
-   trial of keys is the best the adversary can do.
-
-8.2.1 Effort per Key Trial
-
-   How much effort will it take to try each key?  For very high security
-   applications it is best to assume a low value of effort.  Even if it
-   would clearly take tens of thousands of computer cycles or more to
-   try a single key, there may be some pattern that enables huge blocks
-   of key values to be tested with much less effort per key.  Thus it is
-   probably best to assume no more than a couple hundred cycles per key.
-   (There is no clear lower bound on this as computers operate in
-   parallel on a number of bits and a poor encryption algorithm could
-   allow many keys or even groups of keys to be tested in parallel.
-   However, we need to assume some value and can hope that a reasonably
-   strong algorithm has been chosen for our hypothetical high security
-   task.)
-
-   If the adversary can command a highly parallel processor or a large
-   network of work stations, 2*10^10 cycles per second is probably a
-   minimum assumption for availability today.  Looking forward just a
-   couple years, there should be at least an order of magnitude
-   improvement.  Thus assuming 10^9 keys could be checked per second or
-   3.6*10^11 per hour or 6*10^13 per week or 2.4*10^14 per month is
-   reasonable.  This implies a need for a minimum of 51 bits of
-   randomness in keys to be sure they cannot be found in a month.  Even
-   then it is possible that, a few years from now, a highly determined
-   and resourceful adversary could break the key in 2 weeks (on average
-   they need try only half the keys).
-
-
-
-
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 25]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-8.2.2 Meet in the Middle Attacks
-
-   If chosen or known plain text and the resulting encrypted text are
-   available, a "meet in the middle" attack is possible if the structure
-   of the encryption algorithm allows it.  (In a known plain text
-   attack, the adversary knows all or part of the messages being
-   encrypted, possibly some standard header or trailer fields.  In a
-   chosen plain text attack, the adversary can force some chosen plain
-   text to be encrypted, possibly by "leaking" an exciting text that
-   would then be sent by the adversary over an encrypted channel.)
-
-   An oversimplified explanation of the meet in the middle attack is as
-   follows: the adversary can half-encrypt the known or chosen plain
-   text with all possible first half-keys, sort the output, then half-
-   decrypt the encoded text with all the second half-keys.  If a match
-   is found, the full key can be assembled from the halves and used to
-   decrypt other parts of the message or other messages.  At its best,
-   this type of attack can halve the exponent of the work required by
-   the adversary while adding a large but roughly constant factor of
-   effort.  To be assured of safety against this, a doubling of the
-   amount of randomness in the key to a minimum of 102 bits is required.
-
-   The meet in the middle attack assumes that the cryptographic
-   algorithm can be decomposed in this way but we can not rule that out
-   without a deep knowledge of the algorithm.  Even if a basic algorithm
-   is not subject to a meet in the middle attack, an attempt to produce
-   a stronger algorithm by applying the basic algorithm twice (or two
-   different algorithms sequentially) with different keys may gain less
-   added security than would be expected.  Such a composite algorithm
-   would be subject to a meet in the middle attack.
-
-   Enormous resources may be required to mount a meet in the middle
-   attack but they are probably within the range of the national
-   security services of a major nation.  Essentially all nations spy on
-   other nations government traffic and several nations are believed to
-   spy on commercial traffic for economic advantage.
-
-8.2.3 Other Considerations
-
-   Since we have not even considered the possibilities of special
-   purpose code breaking hardware or just how much of a safety margin we
-   want beyond our assumptions above, probably a good minimum for a very
-   high security cryptographic key is 128 bits of randomness which
-   implies a minimum key length of 128 bits.  If the two parties agree
-   on a key by Diffie-Hellman exchange [D-H], then in principle only
-   half of this randomness would have to be supplied by each party.
-   However, there is probably some correlation between their random
-   inputs so it is probably best to assume that each party needs to
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 26]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   provide at least 96 bits worth of randomness for very high security
-   if Diffie-Hellman is used.
-
-   This amount of randomness is beyond the limit of that in the inputs
-   recommended by the US DoD for password generation and could require
-   user typing timing, hardware random number generation, or other
-   sources.
-
-   It should be noted that key length calculations such at those above
-   are controversial and depend on various assumptions about the
-   cryptographic algorithms in use.  In some cases, a professional with
-   a deep knowledge of code breaking techniques and of the strength of
-   the algorithm in use could be satisfied with less than half of the
-   key size derived above.
-
-9. Conclusion
-
-   Generation of unguessable "random" secret quantities for security use
-   is an essential but difficult task.
-
-   We have shown that hardware techniques to produce such randomness
-   would be relatively simple.  In particular, the volume and quality
-   would not need to be high and existing computer hardware, such as
-   disk drives, can be used.  Computational techniques are available to
-   process low quality random quantities from multiple sources or a
-   larger quantity of such low quality input from one source and produce
-   a smaller quantity of higher quality, less predictable key material.
-   In the absence of hardware sources of randomness, a variety of user
-   and software sources can frequently be used instead with care;
-   however, most modern systems already have hardware, such as disk
-   drives or audio input, that could be used to produce high quality
-   randomness.
-
-   Once a sufficient quantity of high quality seed key material (a few
-   hundred bits) is available, strong computational techniques are
-   available to produce cryptographically strong sequences of
-   unpredicatable quantities from this seed material.
-
-10. Security Considerations
-
-   The entirety of this document concerns techniques and recommendations
-   for generating unguessable "random" quantities for use as passwords,
-   cryptographic keys, and similar security uses.
-
-
-
-
-
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 27]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-References
-
-   [ASYMMETRIC] - Secure Communications and Asymmetric Cryptosystems,
-   edited by Gustavus J. Simmons, AAAS Selected Symposium 69, Westview
-   Press, Inc.
-
-   [BBS] - A Simple Unpredictable Pseudo-Random Number Generator, SIAM
-   Journal on Computing, v. 15, n. 2, 1986, L. Blum, M. Blum, & M. Shub.
-
-   [BRILLINGER] - Time Series: Data Analysis and Theory, Holden-Day,
-   1981, David Brillinger.
-
-   [CRC] - C.R.C. Standard Mathematical Tables, Chemical Rubber
-   Publishing Company.
-
-   [CRYPTO1] - Cryptography: A Primer, A Wiley-Interscience Publication,
-   John Wiley & Sons, 1981, Alan G. Konheim.
-
-   [CRYPTO2] - Cryptography:  A New Dimension in Computer Data Security,
-   A Wiley-Interscience Publication, John Wiley & Sons, 1982, Carl H.
-   Meyer & Stephen M. Matyas.
-
-   [CRYPTO3] - Applied Cryptography: Protocols, Algorithms, and Source
-   Code in C, John Wiley & Sons, 1994, Bruce Schneier.
-
-   [DAVIS] - Cryptographic Randomness from Air Turbulence in Disk
-   Drives, Advances in Cryptology - Crypto '94, Springer-Verlag Lecture
-   Notes in Computer Science #839, 1984, Don Davis, Ross Ihaka, and
-   Philip Fenstermacher.
-
-   [DES] -  Data Encryption Standard, United States of America,
-   Department of Commerce, National Institute of Standards and
-   Technology, Federal Information Processing Standard (FIPS) 46-1.
-   - Data Encryption Algorithm, American National Standards Institute,
-   ANSI X3.92-1981.
-   (See also FIPS 112, Password Usage, which includes FORTRAN code for
-   performing DES.)
-
-   [DES MODES] - DES Modes of Operation, United States of America,
-   Department of Commerce, National Institute of Standards and
-   Technology, Federal Information Processing Standard (FIPS) 81.
-   - Data Encryption Algorithm - Modes of Operation, American National
-   Standards Institute, ANSI X3.106-1983.
-
-   [D-H] - New Directions in Cryptography, IEEE Transactions on
-   Information Technology, November, 1976, Whitfield Diffie and Martin
-   E. Hellman.
-
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 28]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   [DoD] - Password Management Guideline, United States of America,
-   Department of Defense, Computer Security Center, CSC-STD-002-85.
-   (See also FIPS 112, Password Usage, which incorporates CSC-STD-002-85
-   as one of its appendices.)
-
-   [GIFFORD] - Natural Random Number, MIT/LCS/TM-371, September 1988,
-   David K. Gifford
-
-   [KNUTH] - The Art of Computer Programming, Volume 2: Seminumerical
-   Algorithms, Chapter 3: Random Numbers. Addison Wesley Publishing
-   Company, Second Edition 1982, Donald E. Knuth.
-
-   [KRAWCZYK] - How to Predict Congruential Generators, Journal of
-   Algorithms, V. 13, N. 4, December 1992, H. Krawczyk
-
-   [MD2] - The MD2 Message-Digest Algorithm, RFC1319, April 1992, B.
-   Kaliski
-   [MD4] - The MD4 Message-Digest Algorithm, RFC1320, April 1992, R.
-   Rivest
-   [MD5] - The MD5 Message-Digest Algorithm, RFC1321, April 1992, R.
-   Rivest
-
-   [PEM] - RFCs 1421 through 1424:
-   - RFC 1424, Privacy Enhancement for Internet Electronic Mail: Part
-   IV: Key Certification and Related Services, 02/10/1993, B. Kaliski
-   - RFC 1423, Privacy Enhancement for Internet Electronic Mail: Part
-   III: Algorithms, Modes, and Identifiers, 02/10/1993, D. Balenson
-   - RFC 1422, Privacy Enhancement for Internet Electronic Mail: Part
-   II: Certificate-Based Key Management, 02/10/1993, S. Kent
-   - RFC 1421, Privacy Enhancement for Internet Electronic Mail: Part I:
-   Message Encryption and Authentication Procedures, 02/10/1993, J. Linn
-
-   [SHANNON] - The Mathematical Theory of Communication, University of
-   Illinois Press, 1963, Claude E. Shannon.  (originally from:  Bell
-   System Technical Journal, July and October 1948)
-
-   [SHIFT1] - Shift Register Sequences, Aegean Park Press, Revised
-   Edition 1982, Solomon W. Golomb.
-
-   [SHIFT2] - Cryptanalysis of Shift-Register Generated Stream Cypher
-   Systems, Aegean Park Press, 1984, Wayne G. Barker.
-
-   [SHS] - Secure Hash Standard, United States of American, National
-   Institute of Science and Technology, Federal Information Processing
-   Standard (FIPS) 180, April 1993.
-
-   [STERN] - Secret Linear Congruential Generators are not
-   Cryptograhically Secure, Proceedings of IEEE STOC, 1987, J. Stern.
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 29]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   [VON NEUMANN] - Various techniques used in connection with random
-   digits, von Neumann's Collected Works, Vol. 5, Pergamon Press, 1963,
-   J. von Neumann.
-
-Authors' Addresses
-
-   Donald E. Eastlake 3rd
-   Digital Equipment Corporation
-   550 King Street, LKG2-1/BB3
-   Littleton, MA 01460
-
-   Phone:   +1 508 486 6577(w)  +1 508 287 4877(h)
-   EMail:   dee@lkg.dec.com
-
-
-   Stephen D. Crocker
-   CyberCash Inc.
-   2086 Hunters Crest Way
-   Vienna, VA 22181
-
-   Phone:   +1 703-620-1222(w)  +1 703-391-2651 (fax)
-   EMail:   crocker@cybercash.com
-
-
-   Jeffrey I. Schiller
-   Massachusetts Institute of Technology
-   77 Massachusetts Avenue
-   Cambridge, MA 02139
-
-   Phone:   +1 617 253 0161(w)
-   EMail:   jis@mit.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 30]
-
diff --git a/contrib/bind9/doc/rfc/rfc1876.txt b/contrib/bind9/doc/rfc/rfc1876.txt
deleted file mode 100644
index a289cff..0000000
--- a/contrib/bind9/doc/rfc/rfc1876.txt
+++ /dev/null
@@ -1,1011 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                           C. Davis
-Request for Comments: 1876                             Kapor Enterprises
-Updates: 1034, 1035                                             P. Vixie
-Category: Experimental                                 Vixie Enterprises
-                                                              T. Goodwin
-                                                            FORE Systems
-                                                            I. Dickinson
-                                                   University of Warwick
-                                                            January 1996
-
-
- A Means for Expressing Location Information in the Domain Name System
-
-Status of this Memo
-
-   This memo defines an Experimental Protocol for the Internet
-   community.  This memo does not specify an Internet standard of any
-   kind.  Discussion and suggestions for improvement are requested.
-   Distribution of this memo is unlimited.
-
-1. Abstract
-
-   This memo defines a new DNS RR type for experimental purposes.  This
-   RFC describes a mechanism to allow the DNS to carry location
-   information about hosts, networks, and subnets.  Such information for
-   a small subset of hosts is currently contained in the flat-file UUCP
-   maps.  However, just as the DNS replaced the use of HOSTS.TXT to
-   carry host and network address information, it is possible to replace
-   the UUCP maps as carriers of location information.
-
-   This RFC defines the format of a new Resource Record (RR) for the
-   Domain Name System (DNS), and reserves a corresponding DNS type
-   mnemonic (LOC) and numerical code (29).
-
-   This RFC assumes that the reader is familiar with the DNS [RFC 1034,
-   RFC 1035].  The data shown in our examples is for pedagogical use and
-   does not necessarily reflect the real Internet.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Davis, et al                  Experimental                      [Page 1]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-2. RDATA Format
-
-       MSB                                           LSB
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      0|        VERSION        |         SIZE          |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      2|       HORIZ PRE       |       VERT PRE        |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      4|                   LATITUDE                    |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      6|                   LATITUDE                    |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      8|                   LONGITUDE                   |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-     10|                   LONGITUDE                   |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-     12|                   ALTITUDE                    |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-     14|                   ALTITUDE                    |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-   (octet)
-
-where:
-
-VERSION      Version number of the representation.  This must be zero.
-             Implementations are required to check this field and make
-             no assumptions about the format of unrecognized versions.
-
-SIZE         The diameter of a sphere enclosing the described entity, in
-             centimeters, expressed as a pair of four-bit unsigned
-             integers, each ranging from zero to nine, with the most
-             significant four bits representing the base and the second
-             number representing the power of ten by which to multiply
-             the base.  This allows sizes from 0e0 (<1cm) to 9e9
-             (90,000km) to be expressed.  This representation was chosen
-             such that the hexadecimal representation can be read by
-             eye; 0x15 = 1e5.  Four-bit values greater than 9 are
-             undefined, as are values with a base of zero and a non-zero
-             exponent.
-
-             Since 20000000m (represented by the value 0x29) is greater
-             than the equatorial diameter of the WGS 84 ellipsoid
-             (12756274m), it is therefore suitable for use as a
-             "worldwide" size.
-
-HORIZ PRE    The horizontal precision of the data, in centimeters,
-             expressed using the same representation as SIZE.  This is
-             the diameter of the horizontal "circle of error", rather
-
-
-
-Davis, et al                  Experimental                      [Page 2]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-             than a "plus or minus" value.  (This was chosen to match
-             the interpretation of SIZE; to get a "plus or minus" value,
-             divide by 2.)
-
-VERT PRE     The vertical precision of the data, in centimeters,
-             expressed using the sane representation as for SIZE.  This
-             is the total potential vertical error, rather than a "plus
-             or minus" value.  (This was chosen to match the
-             interpretation of SIZE; to get a "plus or minus" value,
-             divide by 2.)  Note that if altitude above or below sea
-             level is used as an approximation for altitude relative to
-             the [WGS 84] ellipsoid, the precision value should be
-             adjusted.
-
-LATITUDE     The latitude of the center of the sphere described by the
-             SIZE field, expressed as a 32-bit integer, most significant
-             octet first (network standard byte order), in thousandths
-             of a second of arc.  2^31 represents the equator; numbers
-             above that are north latitude.
-
-LONGITUDE    The longitude of the center of the sphere described by the
-             SIZE field, expressed as a 32-bit integer, most significant
-             octet first (network standard byte order), in thousandths
-             of a second of arc, rounded away from the prime meridian.
-             2^31 represents the prime meridian; numbers above that are
-             east longitude.
-
-ALTITUDE     The altitude of the center of the sphere described by the
-             SIZE field, expressed as a 32-bit integer, most significant
-             octet first (network standard byte order), in centimeters,
-             from a base of 100,000m below the [WGS 84] reference
-             spheroid used by GPS (semimajor axis a=6378137.0,
-             reciprocal flattening rf=298.257223563).  Altitude above
-             (or below) sea level may be used as an approximation of
-             altitude relative to the the [WGS 84] spheroid, though due
-             to the Earth's surface not being a perfect spheroid, there
-             will be differences.  (For example, the geoid (which sea
-             level approximates) for the continental US ranges from 10
-             meters to 50 meters below the [WGS 84] spheroid.
-             Adjustments to ALTITUDE and/or VERT PRE will be necessary
-             in most cases.  The Defense Mapping Agency publishes geoid
-             height values relative to the [WGS 84] ellipsoid.
-
-
-
-
-
-
-
-
-
-Davis, et al                  Experimental                      [Page 3]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-3. Master File Format
-
-   The LOC record is expressed in a master file in the following format:
-
-   <owner> <TTL> <class> LOC ( d1 [m1 [s1]] {"N"|"S"} d2 [m2 [s2]]
-                               {"E"|"W"} alt["m"] [siz["m"] [hp["m"]
-                               [vp["m"]]]] )
-
-   (The parentheses are used for multi-line data as specified in [RFC
-   1035] section 5.1.)
-
-   where:
-
-       d1:     [0 .. 90]            (degrees latitude)
-       d2:     [0 .. 180]           (degrees longitude)
-       m1, m2: [0 .. 59]            (minutes latitude/longitude)
-       s1, s2: [0 .. 59.999]        (seconds latitude/longitude)
-       alt:    [-100000.00 .. 42849672.95] BY .01 (altitude in meters)
-       siz, hp, vp: [0 .. 90000000.00] (size/precision in meters)
-
-   If omitted, minutes and seconds default to zero, size defaults to 1m,
-   horizontal precision defaults to 10000m, and vertical precision
-   defaults to 10m.  These defaults are chosen to represent typical
-   ZIP/postal code area sizes, since it is often easy to find
-   approximate geographical location by ZIP/postal code.
-
-4. Example Data
-
-;;;
-;;; note that these data would not all appear in one zone file
-;;;
-
-;; network LOC RR derived from ZIP data.  note use of precision defaults
-cambridge-net.kei.com.        LOC   42 21 54 N 71 06 18 W -24m 30m
-
-;; higher-precision host LOC RR.  note use of vertical precision default
-loiosh.kei.com.               LOC   42 21 43.952 N 71 5 6.344 W
-                                    -24m 1m 200m
-
-pipex.net.                    LOC   52 14 05 N 00 08 50 E 10m
-
-curtin.edu.au.                LOC   32 7 19 S 116 2 25 E 10m
-
-rwy04L.logan-airport.boston.  LOC   42 21 28.764 N 71 00 51.617 W
-                                    -44m 2000m
-
-
-
-
-
-
-Davis, et al                  Experimental                      [Page 4]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-5. Application use of the LOC RR
-
-5.1 Suggested Uses
-
-   Some uses for the LOC RR have already been suggested, including the
-   USENET backbone flow maps, a "visual traceroute" application showing
-   the geographical path of an IP packet, and network management
-   applications that could use LOC RRs to generate a map of hosts and
-   routers being managed.
-
-5.2 Search Algorithms
-
-   This section specifies how to use the DNS to translate domain names
-   and/or IP addresses into location information.
-
-   If an application wishes to have a "fallback" behavior, displaying a
-   less precise or larger area when a host does not have an associated
-   LOC RR, it MAY support use of the algorithm in section 5.2.3, as
-   noted in sections 5.2.1 and 5.2.2.  If fallback is desired, this
-   behaviour is the RECOMMENDED default, but in some cases it may need
-   to be modified based on the specific requirements of the application
-   involved.
-
-   This search algorithm is designed to allow network administrators to
-   specify the location of a network or subnet without requiring LOC RR
-   data for each individual host.  For example, a computer lab with 24
-   workstations, all of which are on the same subnet and in basically
-   the same location, would only need a LOC RR for the subnet.
-   (However, if the file server's location has been more precisely
-   measured, a separate LOC RR for it can be placed in the DNS.)
-
-5.2.1 Searching by Name
-
-   If the application is beginning with a name, rather than an IP
-   address (as the USENET backbone flow maps do), it MUST check for a
-   LOC RR associated with that name.  (CNAME records should be followed
-   as for any other RR type.)
-
-   If there is no LOC RR for that name, all A records (if any)
-   associated with the name MAY be checked for network (or subnet) LOC
-   RRs using the "Searching by Network or Subnet" algorithm (5.2.3).  If
-   multiple A records exist and have associated network or subnet LOC
-   RRs, the application may choose to use any, some, or all of the LOC
-   RRs found, possibly in combination.  It is suggested that multi-homed
-   hosts have LOC RRs for their name in the DNS to avoid any ambiguity
-   in these cases.
-
-
-
-
-
-Davis, et al                  Experimental                      [Page 5]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-   Note that domain names that do not have associated A records must
-   have a LOC RR associated with their name in order for location
-   information to be accessible.
-
-5.2.2 Searching by Address
-
-   If the application is beginning with an IP address (as a "visual
-   traceroute" application might be) it MUST first map the address to a
-   name using the IN-ADDR.ARPA namespace (see [RFC 1034], section
-   5.2.1), then check for a LOC RR associated with that name.
-
-   If there is no LOC RR for the name, the address MAY be checked for
-   network (or subnet) LOC RRs using the "Searching by Network or
-   Subnet" algorithm (5.2.3).
-
-5.2.3 Searching by Network or Subnet
-
-   Even if a host's name does not have any associated LOC RRs, the
-   network(s) or subnet(s) it is on may.  If the application wishes to
-   search for such less specific data, the following algorithm SHOULD be
-   followed to find a network or subnet LOC RR associated with the IP
-   address.  This algorithm is adapted slightly from that specified in
-   [RFC 1101], sections 4.3 and 4.4.
-
-   Since subnet LOC RRs are (if present) more specific than network LOC
-   RRs, it is best to use them if available.  In order to do so, we
-   build a stack of network and subnet names found while performing the
-   [RFC 1101] search, then work our way down the stack until a LOC RR is
-   found.
-
-   1. create a host-zero address using the network portion of the IP
-      address (one, two, or three bytes for class A, B, or C networks,
-      respectively).  For example, for the host 128.9.2.17, on the class
-      B network 128.9, this would result in the address "128.9.0.0".
-
-   2. Reverse the octets, suffix IN-ADDR.ARPA, and query for PTR and A
-      records.  Retrieve:
-
-               0.0.9.128.IN-ADDR.ARPA.  PTR    isi-net.isi.edu.
-                                        A      255.255.255.0
-
-      Push the name "isi-net.isi.edu" onto the stack of names to be
-      searched for LOC RRs later.
-
-
-
-
-
-
-
-
-Davis, et al                  Experimental                      [Page 6]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-   3. Since an A RR was found, repeat using mask from RR
-      (255.255.255.0), constructing a query for 0.2.9.128.IN-ADDR.ARPA.
-      Retrieve:
-
-               0.2.9.128.IN-ADDR.ARPA.  PTR    div2-subnet.isi.edu.
-                                        A      255.255.255.240
-
-      Push the name "div2-subnet.isi.edu" onto the stack of names to be
-      searched for LOC RRs later.
-
-   4. Since another A RR was found, repeat using mask 255.255.255.240
-      (x'FFFFFFF0'), constructing a query for 16.2.9.128.IN-ADDR.ARPA.
-      Retrieve:
-
-               16.2.9.128.IN-ADDR.ARPA. PTR    inc-subsubnet.isi.edu.
-
-      Push the name "inc-subsubnet.isi.edu" onto the stack of names to
-      be searched for LOC RRs later.
-
-   5. Since no A RR is present at 16.2.9.128.IN-ADDR.ARPA., there are no
-      more subnet levels to search.  We now pop the top name from the
-      stack and check for an associated LOC RR.  Repeat until a LOC RR
-      is found.
-
-      In this case, assume that inc-subsubnet.isi.edu does not have an
-      associated LOC RR, but that div2-subnet.isi.edu does.  We will
-      then use div2-subnet.isi.edu's LOC RR as an approximation of this
-      host's location.  (Note that even if isi-net.isi.edu has a LOC RR,
-      it will not be used if a subnet also has a LOC RR.)
-
-5.3 Applicability to non-IN Classes and non-IP Addresses
-
-   The LOC record is defined for all RR classes, and may be used with
-   non-IN classes such as HS and CH.  The semantics of such use are not
-   defined by this memo.
-
-   The search algorithm in section 5.2.3 may be adapted to other
-   addressing schemes by extending [RFC 1101]'s encoding of network
-   names to cover those schemes.  Such extensions are not defined by
-   this memo.
-
-
-
-
-
-
-
-
-
-
-
-Davis, et al                  Experimental                      [Page 7]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-6. References
-
-   [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
-              STD 13, RFC 1034, USC/Information Sciences Institute,
-              November 1987.
-
-   [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
-              Specification", STD 13, RFC 1035, USC/Information Sciences
-              Institute, November 1987.
-
-   [RFC 1101] Mockapetris, P., "DNS Encoding of Network Names and Other
-              Types", RFC 1101, USC/Information Sciences Institute,
-              April 1989.
-
-   [WGS 84] United States Department of Defense; DoD WGS-1984 - Its
-            Definition and Relationships with Local Geodetic Systems;
-            Washington, D.C.; 1985; Report AD-A188 815 DMA; 6127; 7-R-
-            138-R; CV, KV;
-
-7. Security Considerations
-
-   High-precision LOC RR information could be used to plan a penetration
-   of physical security, leading to potential denial-of-machine attacks.
-   To avoid any appearance of suggesting this method to potential
-   attackers, we declined the opportunity to name this RR "ICBM".
-
-8. Authors' Addresses
-
-   The authors as a group can be reached as <loc@pipex.net>.
-
-   Christopher Davis
-   Kapor Enterprises, Inc.
-   238 Main Street, Suite 400
-   Cambridge, MA 02142
-
-   Phone: +1 617 576 4532
-   EMail: ckd@kei.com
-
-
-   Paul Vixie
-   Vixie Enterprises
-   Star Route Box 159A
-   Woodside, CA 94062
-
-   Phone: +1 415 747 0204
-   EMail: paul@vix.com
-
-
-
-
-
-Davis, et al                  Experimental                      [Page 8]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-   Tim Goodwin
-   Public IP Exchange Ltd (PIPEX)
-   216 The Science Park
-   Cambridge CB4 4WA
-   UK
-
-   Phone: +44 1223 250250
-   EMail: tim@pipex.net
-
-
-   Ian Dickinson
-   FORE Systems
-   2475 The Crescent
-   Solihull Parkway
-   Birmingham Business Park
-   B37 7YE
-   UK
-
-   Phone: +44 121 717 4444
-   EMail: idickins@fore.co.uk
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Davis, et al                  Experimental                      [Page 9]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-Appendix A: Sample Conversion Routines
-
-/*
- * routines to convert between on-the-wire RR format and zone file
- * format.  Does not contain conversion to/from decimal degrees;
- * divide or multiply by 60*60*1000 for that.
- */
-
-static unsigned int poweroften[10] = {1, 10, 100, 1000, 10000, 100000,
-                                 1000000,10000000,100000000,1000000000};
-
-/* takes an XeY precision/size value, returns a string representation.*/
-static const char *
-precsize_ntoa(prec)
-        u_int8_t prec;
-{
-        static char retbuf[sizeof("90000000.00")];
-        unsigned long val;
-        int mantissa, exponent;
-
-        mantissa = (int)((prec >> 4) & 0x0f) % 10;
-        exponent = (int)((prec >> 0) & 0x0f) % 10;
-
-        val = mantissa * poweroften[exponent];
-
-        (void) sprintf(retbuf,"%d.%.2d", val/100, val%100);
-        return (retbuf);
-}
-
-/* converts ascii size/precision X * 10**Y(cm) to 0xXY. moves pointer.*/
-static u_int8_t
-precsize_aton(strptr)
-        char **strptr;
-{
-        unsigned int mval = 0, cmval = 0;
-        u_int8_t retval = 0;
-        register char *cp;
-        register int exponent;
-        register int mantissa;
-
-        cp = *strptr;
-
-        while (isdigit(*cp))
-                mval = mval * 10 + (*cp++ - '0');
-
-        if (*cp == '.') {               /* centimeters */
-                cp++;
-                if (isdigit(*cp)) {
-
-
-
-Davis, et al                  Experimental                     [Page 10]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-                        cmval = (*cp++ - '0') * 10;
-                        if (isdigit(*cp)) {
-                                cmval += (*cp++ - '0');
-                        }
-                }
-        }
-        cmval = (mval * 100) + cmval;
-
-        for (exponent = 0; exponent < 9; exponent++)
-                if (cmval < poweroften[exponent+1])
-                        break;
-
-        mantissa = cmval / poweroften[exponent];
-        if (mantissa > 9)
-                mantissa = 9;
-
-        retval = (mantissa << 4) | exponent;
-
-        *strptr = cp;
-
-        return (retval);
-}
-
-/* converts ascii lat/lon to unsigned encoded 32-bit number.
- *  moves pointer. */
-static u_int32_t
-latlon2ul(latlonstrptr,which)
-        char **latlonstrptr;
-        int *which;
-{
-        register char *cp;
-        u_int32_t retval;
-        int deg = 0, min = 0, secs = 0, secsfrac = 0;
-
-        cp = *latlonstrptr;
-
-        while (isdigit(*cp))
-                deg = deg * 10 + (*cp++ - '0');
-
-        while (isspace(*cp))
-                cp++;
-
-        if (!(isdigit(*cp)))
-                goto fndhemi;
-
-        while (isdigit(*cp))
-                min = min * 10 + (*cp++ - '0');
-
-
-
-
-Davis, et al                  Experimental                     [Page 11]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-        while (isspace(*cp))
-                cp++;
-
-        if (!(isdigit(*cp)))
-                goto fndhemi;
-
-        while (isdigit(*cp))
-                secs = secs * 10 + (*cp++ - '0');
-
-        if (*cp == '.') {               /* decimal seconds */
-                cp++;
-                if (isdigit(*cp)) {
-                        secsfrac = (*cp++ - '0') * 100;
-                        if (isdigit(*cp)) {
-                                secsfrac += (*cp++ - '0') * 10;
-                                if (isdigit(*cp)) {
-                                        secsfrac += (*cp++ - '0');
-                                }
-                        }
-                }
-        }
-
-        while (!isspace(*cp))   /* if any trailing garbage */
-                cp++;
-
-        while (isspace(*cp))
-                cp++;
-
- fndhemi:
-        switch (*cp) {
-        case 'N': case 'n':
-        case 'E': case 'e':
-                retval = ((unsigned)1<<31)
-                        + (((((deg * 60) + min) * 60) + secs) * 1000)
-                        + secsfrac;
-                break;
-        case 'S': case 's':
-        case 'W': case 'w':
-                retval = ((unsigned)1<<31)
-                        - (((((deg * 60) + min) * 60) + secs) * 1000)
-                        - secsfrac;
-                break;
-        default:
-                retval = 0;     /* invalid value -- indicates error */
-                break;
-        }
-
-        switch (*cp) {
-
-
-
-Davis, et al                  Experimental                     [Page 12]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-        case 'N': case 'n':
-        case 'S': case 's':
-                *which = 1;     /* latitude */
-                break;
-        case 'E': case 'e':
-        case 'W': case 'w':
-                *which = 2;     /* longitude */
-                break;
-        default:
-                *which = 0;     /* error */
-                break;
-        }
-
-        cp++;                   /* skip the hemisphere */
-
-        while (!isspace(*cp))   /* if any trailing garbage */
-                cp++;
-
-        while (isspace(*cp))    /* move to next field */
-                cp++;
-
-        *latlonstrptr = cp;
-
-        return (retval);
-}
-
-/* converts a zone file representation in a string to an RDATA
- * on-the-wire representation. */
-u_int32_t
-loc_aton(ascii, binary)
-        const char *ascii;
-        u_char *binary;
-{
-        const char *cp, *maxcp;
-        u_char *bcp;
-
-        u_int32_t latit = 0, longit = 0, alt = 0;
-        u_int32_t lltemp1 = 0, lltemp2 = 0;
-        int altmeters = 0, altfrac = 0, altsign = 1;
-        u_int8_t hp = 0x16;    /* default = 1e6 cm = 10000.00m = 10km */
-        u_int8_t vp = 0x13;    /* default = 1e3 cm = 10.00m */
-        u_int8_t siz = 0x12;   /* default = 1e2 cm = 1.00m */
-        int which1 = 0, which2 = 0;
-
-        cp = ascii;
-        maxcp = cp + strlen(ascii);
-
-        lltemp1 = latlon2ul(&cp, &which1);
-
-
-
-Davis, et al                  Experimental                     [Page 13]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-        lltemp2 = latlon2ul(&cp, &which2);
-
-        switch (which1 + which2) {
-        case 3:                 /* 1 + 2, the only valid combination */
-                if ((which1 == 1) && (which2 == 2)) { /* normal case */
-                        latit = lltemp1;
-                        longit = lltemp2;
-                } else if ((which1 == 2) && (which2 == 1)) {/*reversed*/
-                        longit = lltemp1;
-                        latit = lltemp2;
-                } else {        /* some kind of brokenness */
-                        return 0;
-                }
-                break;
-        default:                /* we didn't get one of each */
-                return 0;
-        }
-
-        /* altitude */
-        if (*cp == '-') {
-                altsign = -1;
-                cp++;
-        }
-
-        if (*cp == '+')
-                cp++;
-
-        while (isdigit(*cp))
-                altmeters = altmeters * 10 + (*cp++ - '0');
-
-        if (*cp == '.') {               /* decimal meters */
-                cp++;
-                if (isdigit(*cp)) {
-                        altfrac = (*cp++ - '0') * 10;
-                        if (isdigit(*cp)) {
-                                altfrac += (*cp++ - '0');
-                        }
-                }
-        }
-
-        alt = (10000000 + (altsign * (altmeters * 100 + altfrac)));
-
-        while (!isspace(*cp) && (cp < maxcp))
-                                           /* if trailing garbage or m */
-                cp++;
-
-        while (isspace(*cp) && (cp < maxcp))
-                cp++;
-
-
-
-Davis, et al                  Experimental                     [Page 14]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-        if (cp >= maxcp)
-                goto defaults;
-
-        siz = precsize_aton(&cp);
-
-        while (!isspace(*cp) && (cp < maxcp))/*if trailing garbage or m*/
-                cp++;
-
-        while (isspace(*cp) && (cp < maxcp))
-                cp++;
-
-        if (cp >= maxcp)
-                goto defaults;
-
-        hp = precsize_aton(&cp);
-
-        while (!isspace(*cp) && (cp < maxcp))/*if trailing garbage or m*/
-                cp++;
-
-        while (isspace(*cp) && (cp < maxcp))
-                cp++;
-
-        if (cp >= maxcp)
-                goto defaults;
-
-        vp = precsize_aton(&cp);
-
- defaults:
-
-        bcp = binary;
-        *bcp++ = (u_int8_t) 0;  /* version byte */
-        *bcp++ = siz;
-        *bcp++ = hp;
-        *bcp++ = vp;
-        PUTLONG(latit,bcp);
-        PUTLONG(longit,bcp);
-        PUTLONG(alt,bcp);
-
-        return (16);            /* size of RR in octets */
-}
-
-/* takes an on-the-wire LOC RR and prints it in zone file
- * (human readable) format. */
-char *
-loc_ntoa(binary,ascii)
-        const u_char *binary;
-        char *ascii;
-{
-
-
-
-Davis, et al                  Experimental                     [Page 15]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-        static char tmpbuf[255*3];
-
-        register char *cp;
-        register const u_char *rcp;
-
-        int latdeg, latmin, latsec, latsecfrac;
-        int longdeg, longmin, longsec, longsecfrac;
-        char northsouth, eastwest;
-        int altmeters, altfrac, altsign;
-
-        const int referencealt = 100000 * 100;
-
-        int32_t latval, longval, altval;
-        u_int32_t templ;
-        u_int8_t sizeval, hpval, vpval, versionval;
-
-        char *sizestr, *hpstr, *vpstr;
-
-        rcp = binary;
-        if (ascii)
-                cp = ascii;
-        else {
-                cp = tmpbuf;
-        }
-
-        versionval = *rcp++;
-
-        if (versionval) {
-                sprintf(cp,"; error: unknown LOC RR version");
-                return (cp);
-        }
-
-        sizeval = *rcp++;
-
-        hpval = *rcp++;
-        vpval = *rcp++;
-
-        GETLONG(templ,rcp);
-        latval = (templ - ((unsigned)1<<31));
-
-        GETLONG(templ,rcp);
-        longval = (templ - ((unsigned)1<<31));
-
-        GETLONG(templ,rcp);
-        if (templ < referencealt) { /* below WGS 84 spheroid */
-                altval = referencealt - templ;
-                altsign = -1;
-        } else {
-
-
-
-Davis, et al                  Experimental                     [Page 16]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-                altval = templ - referencealt;
-                altsign = 1;
-        }
-
-        if (latval < 0) {
-                northsouth = 'S';
-                latval = -latval;
-        }
-        else
-                northsouth = 'N';
-
-        latsecfrac = latval % 1000;
-        latval = latval / 1000;
-        latsec = latval % 60;
-        latval = latval / 60;
-        latmin = latval % 60;
-        latval = latval / 60;
-        latdeg = latval;
-
-        if (longval < 0) {
-                eastwest = 'W';
-                longval = -longval;
-        }
-        else
-                eastwest = 'E';
-
-        longsecfrac = longval % 1000;
-        longval = longval / 1000;
-        longsec = longval % 60;
-        longval = longval / 60;
-        longmin = longval % 60;
-        longval = longval / 60;
-        longdeg = longval;
-
-        altfrac = altval % 100;
-        altmeters = (altval / 100) * altsign;
-
-        sizestr = savestr(precsize_ntoa(sizeval));
-        hpstr = savestr(precsize_ntoa(hpval));
-        vpstr = savestr(precsize_ntoa(vpval));
-
-        sprintf(cp,
-                "%d %.2d %.2d.%.3d %c %d %.2d %.2d.%.3d %c %d.%.2dm
-                %sm %sm %sm",
-                latdeg, latmin, latsec, latsecfrac, northsouth,
-                longdeg, longmin, longsec, longsecfrac, eastwest,
-                altmeters, altfrac, sizestr, hpstr, vpstr);
-
-
-
-
-Davis, et al                  Experimental                     [Page 17]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-        free(sizestr);
-        free(hpstr);
-        free(vpstr);
-
-        return (cp);
-}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Davis, et al                  Experimental                     [Page 18]
-
diff --git a/contrib/bind9/doc/rfc/rfc1886.txt b/contrib/bind9/doc/rfc/rfc1886.txt
deleted file mode 100644
index 9874fdd..0000000
--- a/contrib/bind9/doc/rfc/rfc1886.txt
+++ /dev/null
@@ -1,268 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         S. Thomson
-Request for Comments: 1886                                      Bellcore
-Category: Standards Track                                     C. Huitema
-                                                                   INRIA
-                                                           December 1995
-
-
-                DNS Extensions to support IP version 6
-
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-
-Abstract
-
-   This document defines the changes that need to be made to the Domain
-   Name System to support hosts running IP version 6 (IPv6).  The
-   changes include a new resource record type to store an IPv6 address,
-   a new domain to support lookups based on an IPv6 address, and updated
-   definitions of existing query types that return Internet addresses as
-   part of additional section processing.  The extensions are designed
-   to be compatible with existing applications and, in particular, DNS
-   implementations themselves.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Thompson & Huitema          Standards Track                    [Page 1]
-
-RFC 1886                  IPv6 DNS Extensions              December 1995
-
-
-1. INTRODUCTION
-
-   Current support for the storage of Internet addresses in the Domain
-   Name System (DNS)[1,2] cannot easily be extended to support IPv6
-   addresses[3] since applications assume that address queries return
-   32-bit IPv4 addresses only.
-
-   To support the storage of IPv6 addresses we define the following
-   extensions:
-
-      o A new resource record type is defined to map a domain name to an
-        IPv6 address.
-
-      o A new domain is defined to support lookups based on address.
-
-      o Existing queries that perform additional section processing to
-        locate IPv4 addresses are redefined to perform additional
-        section processing on both IPv4 and IPv6 addresses.
-
-   The changes are designed to be compatible with existing software. The
-   existing support for IPv4 addresses is retained. Transition issues
-   related to the co-existence of both IPv4 and IPv6 addresses in DNS
-   are discussed in [4].
-
-
-2. NEW RESOURCE RECORD DEFINITION AND DOMAIN
-
-   A new record type is defined to store a host's IPv6 address. A host
-   that has more than one IPv6 address must have more than one such
-   record.
-
-
-2.1 AAAA record type
-
-   The AAAA resource record type is a new record specific to the
-   Internet class that stores a single IPv6 address.
-
-   The value of the type is 28 (decimal).
-
-
-2.2 AAAA data format
-
-   A 128 bit IPv6 address is encoded in the data portion of an AAAA
-   resource record in network byte order (high-order byte first).
-
-
-
-
-Thompson & Huitema          Standards Track                    [Page 2]
-
-RFC 1886                  IPv6 DNS Extensions              December 1995
-
-
-2.3 AAAA query
-
-   An AAAA query for a specified domain name in the Internet class
-   returns all associated AAAA resource records in the answer section of
-   a response.
-
-   A type AAAA query does not perform additional section processing.
-
-
-2.4 Textual format of AAAA records
-
-   The textual representation of the data portion of the AAAA resource
-   record used in a master database file is the textual representation
-   of a IPv6 address as defined in [3].
-
-
-2.5 IP6.INT Domain
-
-   A special domain is defined to look up a record given an address. The
-   intent of this domain is to provide a way of mapping an IPv6 address
-   to a host name, although it may be used for other purposes as well.
-   The domain is rooted at IP6.INT.
-
-   An IPv6 address is represented as a name in the IP6.INT domain by a
-   sequence of nibbles separated by dots with the suffix ".IP6.INT". The
-   sequence of nibbles is encoded in reverse order, i.e. the low-order
-   nibble is encoded first, followed by the next low-order nibble and so
-   on. Each nibble is represented by a hexadecimal digit. For example,
-   the inverse lookup domain name corresponding to the address
-
-       4321:0:1:2:3:4:567:89ab
-
-   would be
-
-b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.INT.
-
-
-
-3. MODIFICATIONS TO EXISTING QUERY TYPES
-
-   All existing query types that perform type A additional section
-   processing, i.e. name server (NS), mail exchange (MX) and mailbox
-   (MB) query types, must be redefined to perform both type A and type
-   AAAA additional section processing. These new definitions mean that a
-   name server must add any relevant IPv4 addresses and any relevant
-
-
-
-Thompson & Huitema          Standards Track                    [Page 3]
-
-RFC 1886                  IPv6 DNS Extensions              December 1995
-
-
-   IPv6 addresses available locally to the additional section of a
-   response when processing any one of the above queries.
-
-
-4. SECURITY CONSIDERATIONS
-
-   Security issues are not discussed in this memo.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Thompson & Huitema          Standards Track                    [Page 4]
-
-RFC 1886                  IPv6 DNS Extensions              December 1995
-
-
-5. REFERENCES
-
-
-   [1]  Mockapetris, P., "Domain Names - Concepts and Facilities", STD
-        13, RFC 1034, USC/Information Sciences Institute, November 1987.
-
-   [2]  Mockapetris, P., "Domain Names - Implementation and Specifica-
-        tion", STD 13, RFC 1035, USC/Information Sciences Institute,
-        November 1987.
-
-   [3]  Hinden, R., and S. Deering, Editors, "IP Version 6 Addressing
-        Architecture", RFC 1884, Ipsilon Networks, Xerox PARC, December
-        1995.
-
-
-   [4]  Gilligan, R., and E. Nordmark, "Transition Mechanisms for IPv6
-        Hosts and Routers", Work in Progress.
-
-
-Authors' Addresses
-
-   Susan Thomson
-   Bellcore
-   MRE 2P343
-   445 South Street
-   Morristown, NJ 07960
-   U.S.A.
-
-   Phone: +1 201-829-4514
-   EMail: set@thumper.bellcore.com
-
-
-   Christian Huitema
-   INRIA, Sophia-Antipolis
-   2004 Route des Lucioles
-   BP 109
-   F-06561 Valbonne Cedex
-   France
-
-   Phone: +33 93 65 77 15
-   EMail: Christian.Huitema@MIRSA.INRIA.FR
-
-
-
-
-
-
-
-Thompson & Huitema          Standards Track                    [Page 5]
-
diff --git a/contrib/bind9/doc/rfc/rfc1982.txt b/contrib/bind9/doc/rfc/rfc1982.txt
deleted file mode 100644
index 5a34bc4..0000000
--- a/contrib/bind9/doc/rfc/rfc1982.txt
+++ /dev/null
@@ -1,394 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                             R. Elz
-Request for Comments: 1982                       University of Melbourne
-Updates: 1034, 1035                                              R. Bush
-Category: Standards Track                                    RGnet, Inc.
-                                                             August 1996
-
-
-                        Serial Number Arithmetic
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Abstract
-
-   This memo defines serial number arithmetic, as used in the Domain
-   Name System.  The DNS has long relied upon serial number arithmetic,
-   a concept which has never really been defined, certainly not in an
-   IETF document, though which has been widely understood.  This memo
-   supplies the missing definition.  It is intended to update RFC1034
-   and RFC1035.
-
-1. Introduction
-
-   The serial number field of the SOA resource record is defined in
-   RFC1035 as
-
-   SERIAL   The unsigned 32 bit version number of the original copy of
-            the zone.  Zone transfers preserve this value.  This value
-            wraps and should be compared using sequence space
-            arithmetic.
-
-   RFC1034 uses the same terminology when defining secondary server zone
-   consistency procedures.
-
-   Unfortunately the term "sequence space arithmetic" is not defined in
-   either RFC1034 or RFC1035, nor do any of their references provide
-   further information.
-
-   This phrase seems to have been intending to specify arithmetic as
-   used in TCP sequence numbers [RFC793], and defined in [IEN-74].
-
-   Unfortunately, the arithmetic defined in [IEN-74] is not adequate for
-   the purposes of the DNS, as no general comparison operator is
-
-
-
-Elz & Bush                  Standards Track                     [Page 1]
-
-RFC 1982                Serial Number Arithmetic             August 1996
-
-
-   defined.
-
-   To avoid further problems with this simple field, this document
-   defines the field and the operations available upon it.  This
-   definition is intended merely to clarify the intent of RFC1034 and
-   RFC1035, and is believed to generally agree with current
-   implementations.  However, older, superseded, implementations are
-   known to have treated the serial number as a simple unsigned integer,
-   with no attempt to implement any kind of "sequence space arithmetic",
-   however that may have been interpreted, and further, ignoring the
-   requirement that the value wraps.  Nothing can be done with these
-   implementations, beyond extermination.
-
-2. Serial Number Arithmetic
-
-   Serial numbers are formed from non-negative integers from a finite
-   subset of the range of all integer values.  The lowest integer in
-   every subset used for this purpose is zero, the maximum is always one
-   less than a power of two.
-
-   When considered as serial numbers however no value has any particular
-   significance, there is no minimum or maximum serial number, every
-   value has a successor and predecessor.
-
-   To define a serial number to be used in this way, the size of the
-   serial number space must be given.  This value, called "SERIAL_BITS",
-   gives the power of two which results in one larger than the largest
-   integer corresponding to a serial number value.  This also specifies
-   the number of bits required to hold every possible value of a serial
-   number of the defined type.  The operations permitted upon serial
-   numbers are defined in the following section.
-
-3. Operations upon the serial number
-
-   Only two operations are defined upon serial numbers, addition of a
-   positive integer of limited range, and comparison with another serial
-   number.
-
-3.1. Addition
-
-   Serial numbers may be incremented by the addition of a positive
-   integer n, where n is taken from the range of integers
-   [0 .. (2^(SERIAL_BITS - 1) - 1)].  For a sequence number s, the
-   result of such an addition, s', is defined as
-
-                   s' = (s + n) modulo (2 ^ SERIAL_BITS)
-
-
-
-
-
-Elz & Bush                  Standards Track                     [Page 2]
-
-RFC 1982                Serial Number Arithmetic             August 1996
-
-
-   where the addition and modulus operations here act upon values that
-   are non-negative values of unbounded size in the usual ways of
-   integer arithmetic.
-
-   Addition of a value outside the range
-   [0 .. (2^(SERIAL_BITS - 1) - 1)] is undefined.
-
-3.2. Comparison
-
-   Any two serial numbers, s1 and s2, may be compared.  The definition
-   of the result of this comparison is as follows.
-
-   For the purposes of this definition, consider two integers, i1 and
-   i2, from the unbounded set of non-negative integers, such that i1 and
-   s1 have the same numeric value, as do i2 and s2.  Arithmetic and
-   comparisons applied to i1 and i2 use ordinary unbounded integer
-   arithmetic.
-
-   Then, s1 is said to be equal to s2 if and only if i1 is equal to i2,
-   in all other cases, s1 is not equal to s2.
-
-   s1 is said to be less than s2 if, and only if, s1 is not equal to s2,
-   and
-
-        (i1 < i2 and i2 - i1 < 2^(SERIAL_BITS - 1)) or
-        (i1 > i2 and i1 - i2 > 2^(SERIAL_BITS - 1))
-
-   s1 is said to be greater than s2 if, and only if, s1 is not equal to
-   s2, and
-
-        (i1 < i2 and i2 - i1 > 2^(SERIAL_BITS - 1)) or
-        (i1 > i2 and i1 - i2 < 2^(SERIAL_BITS - 1))
-
-   Note that there are some pairs of values s1 and s2 for which s1 is
-   not equal to s2, but for which s1 is neither greater than, nor less
-   than, s2.  An attempt to use these ordering operators on such pairs
-   of values produces an undefined result.
-
-   The reason for this is that those pairs of values are such that any
-   simple definition that were to define s1 to be less than s2 where
-   (s1, s2) is such a pair, would also usually cause s2 to be less than
-   s1, when the pair is (s2, s1).  This would mean that the particular
-   order selected for a test could cause the result to differ, leading
-   to unpredictable implementations.
-
-   While it would be possible to define the test in such a way that the
-   inequality would not have this surprising property, while being
-   defined for all pairs of values, such a definition would be
-
-
-
-Elz & Bush                  Standards Track                     [Page 3]
-
-RFC 1982                Serial Number Arithmetic             August 1996
-
-
-   unnecessarily burdensome to implement, and difficult to understand,
-   and would still allow cases where
-
-        s1 < s2 and (s1 + 1) > (s2 + 1)
-
-   which is just as non-intuitive.
-
-   Thus the problem case is left undefined, implementations are free to
-   return either result, or to flag an error, and users must take care
-   not to depend on any particular outcome.  Usually this will mean
-   avoiding allowing those particular pairs of numbers to co-exist.
-
-   The relationships greater than or equal to, and less than or equal
-   to, follow in the natural way from the above definitions.
-
-4. Corollaries
-
-   These definitions give rise to some results of note.
-
-4.1. Corollary 1
-
-   For any sequence number s and any integer n such that addition of n
-   to s is well defined, (s + n) >= s.  Further (s + n) == s only when
-   n == 0, in all other defined cases, (s + n) > s.
-
-4.2. Corollary 2
-
-   If s' is the result of adding the non-zero integer n to the sequence
-   number s, and m is another integer from the range defined as able to
-   be added to a sequence number, and s" is the result of adding m to
-   s', then it is undefined whether s" is greater than, or less than s,
-   though it is known that s" is not equal to s.
-
-4.3. Corollary 3
-
-   If s" from the previous corollary is further incremented, then there
-   is no longer any known relationship between the result and s.
-
-4.4. Corollary 4
-
-   If in corollary 2 the value (n + m) is such that addition of the sum
-   to sequence number s would produce a defined result, then corollary 1
-   applies, and s" is known to be greater than s.
-
-
-
-
-
-
-
-
-Elz & Bush                  Standards Track                     [Page 4]
-
-RFC 1982                Serial Number Arithmetic             August 1996
-
-
-5. Examples
-
-5.1. A trivial example
-
-   The simplest meaningful serial number space has SERIAL_BITS == 2.  In
-   this space, the integers that make up the serial number space are 0,
-   1, 2, and 3.  That is, 3 == 2^SERIAL_BITS - 1.
-
-   In this space, the largest integer that it is meaningful to add to a
-   sequence number is 2^(SERIAL_BITS - 1) - 1, or 1.
-
-   Then, as defined 0+1 == 1, 1+1 == 2, 2+1 == 3, and 3+1 == 0.
-   Further, 1 > 0, 2 > 1, 3 > 2, and 0 > 3.  It is undefined whether
-   2 > 0 or 0 > 2, and whether 1 > 3 or 3 > 1.
-
-5.2. A slightly larger example
-
-   Consider the case where SERIAL_BITS == 8.  In this space the integers
-   that make up the serial number space are 0, 1, 2, ... 254, 255.
-   255 == 2^SERIAL_BITS - 1.
-
-   In this space, the largest integer that it is meaningful to add to a
-   sequence number is 2^(SERIAL_BITS - 1) - 1, or 127.
-
-   Addition is as expected in this space, for example: 255+1 == 0,
-   100+100 == 200, and 200+100 == 44.
-
-   Comparison is more interesting, 1 > 0, 44 > 0, 100 > 0, 100 > 44,
-   200 > 100, 255 > 200, 0 > 255, 100 > 255, 0 > 200, and 44 > 200.
-
-   Note that 100+100 > 100, but that (100+100)+100 < 100.  Incrementing
-   a serial number can cause it to become "smaller".  Of course,
-   incrementing by a smaller number will allow many more increments to
-   be made before this occurs.  However this is always something to be
-   aware of, it can cause surprising errors, or be useful as it is the
-   only defined way to actually cause a serial number to decrease.
-
-   The pairs of values 0 and 128, 1 and 129, 2 and 130, etc, to 127 and
-   255 are not equal, but in each pair, neither number is defined as
-   being greater than, or less than, the other.
-
-   It could be defined (arbitrarily) that 128 > 0, 129 > 1,
-   130 > 2, ..., 255 > 127, by changing the comparison operator
-   definitions, as mentioned above.  However note that that would cause
-   255 > 127, while (255 + 1) < (127 + 1), as 0 < 128.  Such a
-   definition, apart from being arbitrary, would also be more costly to
-   implement.
-
-
-
-
-Elz & Bush                  Standards Track                     [Page 5]
-
-RFC 1982                Serial Number Arithmetic             August 1996
-
-
-6. Citation
-
-   As this defined arithmetic may be useful for purposes other than for
-   the DNS serial number, it may be referenced as Serial Number
-   Arithmetic from RFC1982.  Any such reference shall be taken as
-   implying that the rules of sections 2 to 5 of this document apply to
-   the stated values.
-
-7. The DNS SOA serial number
-
-   The serial number in the DNS SOA Resource Record is a Serial Number
-   as defined above, with SERIAL_BITS being 32.  That is, the serial
-   number is a non negative integer with values taken from the range
-   [0 .. 4294967295].  That is, a 32 bit unsigned integer.
-
-   The maximum defined increment is 2147483647 (2^31 - 1).
-
-   Care should be taken that the serial number not be incremented, in
-   one or more steps, by more than this maximum within the period given
-   by the value of SOA.expire.  Doing so may leave some secondary
-   servers with out of date copies of the zone, but with a serial number
-   "greater" than that of the primary server.  Of course, special
-   circumstances may require this rule be set aside, for example, when
-   the serial number needs to be set lower for some reason.  If this
-   must be done, then take special care to verify that ALL servers have
-   correctly succeeded in following the primary server's serial number
-   changes, at each step.
-
-   Note that each, and every, increment to the serial number must be
-   treated as the start of a new sequence of increments for this
-   purpose, as well as being the continuation of all previous sequences
-   started within the period specified by SOA.expire.
-
-   Caution should also be exercised before causing the serial number to
-   be set to the value zero.  While this value is not in any way special
-   in serial number arithmetic, or to the DNS SOA serial number, many
-   DNS implementations have incorrectly treated zero as a special case,
-   with special properties, and unusual behaviour may be expected if
-   zero is used as a DNS SOA serial number.
-
-
-
-
-
-
-
-
-
-
-
-
-Elz & Bush                  Standards Track                     [Page 6]
-
-RFC 1982                Serial Number Arithmetic             August 1996
-
-
-8. Document Updates
-
-   RFC1034 and RFC1035 are to be treated as if the references to
-   "sequence space arithmetic" therein are replaced by references to
-   serial number arithmetic, as defined in this document.
-
-9. Security Considerations
-
-   This document does not consider security.
-
-   It is not believed that anything in this document adds to any
-   security issues that may exist with the DNS, nor does it do anything
-   to lessen them.
-
-References
-
-   [RFC1034]   Domain Names - Concepts and Facilities,
-               P. Mockapetris, STD 13, ISI, November 1987.
-
-   [RFC1035]   Domain Names - Implementation and Specification
-               P. Mockapetris, STD 13, ISI, November 1987
-
-   [RFC793]    Transmission Control protocol
-               Information Sciences Institute, STD 7, USC, September 1981
-
-   [IEN-74]    Sequence Number Arithmetic
-               William W. Plummer, BB&N Inc, September 1978
-
-Acknowledgements
-
-   Thanks to Rob Austein for suggesting clarification of the undefined
-   comparison operators, and to Michael Patton for attempting to locate
-   another reference for this procedure.  Thanks also to members of the
-   IETF DNSIND working group of 1995-6, in particular, Paul Mockapetris.
-
-Authors' Addresses
-
-   Robert Elz                     Randy Bush
-   Computer Science               RGnet, Inc.
-   University of Melbourne        10361 NE Sasquatch Lane
-   Parkville, Vic,  3052          Bainbridge Island, Washington,  98110
-   Australia.                     United States.
-
-   EMail: kre@munnari.OZ.AU       EMail: randy@psg.com
-
-
-
-
-
-
-
-Elz & Bush                  Standards Track                     [Page 7]
diff --git a/contrib/bind9/doc/rfc/rfc1995.txt b/contrib/bind9/doc/rfc/rfc1995.txt
deleted file mode 100644
index b50bdc6..0000000
--- a/contrib/bind9/doc/rfc/rfc1995.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                            M. Ohta
-Request for Comments: 1995                 Tokyo Institute of Technology
-Updates: 1035                                                August 1996
-Category: Standards Track
-
-
-                    Incremental Zone Transfer in DNS
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Abstract
-
-   This document proposes extensions to the DNS protocols to provide an
-   incremental zone transfer (IXFR) mechanism.
-
-1. Introduction
-
-   For rapid propagation of changes to a DNS database [STD13], it is
-   necessary to reduce latency by actively notifying servers of the
-   change.  This is accomplished by the NOTIFY extension of the DNS
-   [NOTIFY].
-
-   The current full zone transfer mechanism (AXFR) is not an efficient
-   means to propagate changes to a small part of a zone, as it transfers
-   the entire zone file.
-
-   Incremental transfer (IXFR) as proposed is a more efficient
-   mechanism, as it transfers only the changed portion(s) of a zone.
-
-   In this document, a secondary name server which requests IXFR is
-   called an IXFR client and a primary or secondary name server which
-   responds to the request is called an IXFR server.
-
-2. Brief Description of the Protocol
-
-   If an IXFR client, which likely has an older version of a zone,
-   thinks it needs new information about the zone (typically through SOA
-   refresh timeout or the NOTIFY mechanism), it sends an IXFR message
-   containing the SOA serial number of its, presumably outdated, copy of
-   the zone.
-
-
-
-
-
-Ohta                        Standards Track                     [Page 1]
-
-RFC 1995            Incremental Zone Transfer in DNS         August 1996
-
-
-   An IXFR server should keep record of the newest version of the zone
-   and the differences between that copy and several older versions.
-   When an IXFR request with an older version number is received, the
-   IXFR server needs to send only the differences required to make that
-   version current.  Alternatively, the server may choose to transfer
-   the entire zone just as in a normal full zone transfer.
-
-   When a zone has been updated, it should be saved in stable storage
-   before the new version is used to respond to IXFR (or AXFR) queries.
-   Otherwise, if the server crashes, data which is no longer available
-   may have been distributed to secondary servers, which can cause
-   persistent database inconsistencies.
-
-   If an IXFR query with the same or newer version number than that of
-   the server is received, it is replied to with a single SOA record of
-   the server's current version, just as in AXFR.
-
-   Transport of a query may be by either UDP or TCP.  If an IXFR query
-   is via UDP, the IXFR server may attempt to reply using UDP if the
-   entire response can be contained in a single DNS packet.  If the UDP
-   reply does not fit, the query is responded to with a single SOA
-   record of the server's current version to inform the client that a
-   TCP query should be initiated.
-
-   Thus, a client should first make an IXFR query using UDP.  If the
-   query type is not recognized by the server, an AXFR (preceded by a
-   UDP SOA query) should be tried, ensuring backward compatibility.  If
-   the query response is a single packet with the entire new zone, or if
-   the server does not have a newer version than the client, everything
-   is done.  Otherwise, a TCP IXFR query should be tried.
-
-   To ensure integrity, servers should use UDP checksums for all UDP
-   responses.  A cautious client which receives a UDP packet with a
-   checksum value of zero should ignore the result and try a TCP IXFR
-   instead.
-
-   The query type value of IXFR assigned by IANA is 251.
-
-3. Query Format
-
-   The IXFR query packet format is the same as that of a normal DNS
-   query, but with the query type being IXFR and the authority section
-   containing the SOA record of client's version of the zone.
-
-
-
-
-
-
-
-
-Ohta                        Standards Track                     [Page 2]
-
-RFC 1995            Incremental Zone Transfer in DNS         August 1996
-
-
-4. Response Format
-
-   If incremental zone transfer is not available, the entire zone is
-   returned.  The first and the last RR of the response is the SOA
-   record of the zone.  I.e. the behavior is the same as an AXFR
-   response except the query type is IXFR.
-
-   If incremental zone transfer is available, one or more difference
-   sequences is returned.  The list of difference sequences is preceded
-   and followed by a copy of the server's current version of the SOA.
-
-   Each difference sequence represents one update to the zone (one SOA
-   serial change) consisting of deleted RRs and added RRs.  The first RR
-   of the deleted RRs is the older SOA RR and the first RR of the added
-   RRs is the newer SOA RR.
-
-   Modification of an RR is performed first by removing the original RR
-   and then adding the modified one.
-
-   The sequences of differential information are ordered oldest first
-   newest last.  Thus, the differential sequences are the history of
-   changes made since the version known by the IXFR client up to the
-   server's current version.
-
-   RRs in the incremental transfer messages may be partial.  That is, if
-   a single RR of multiple RRs of the same RR type changes, only the
-   changed RR is transferred.
-
-   An IXFR client, should only replace an older version with a newer
-   version after all the differences have been successfully processed.
-
-   An incremental response is different from that of a non-incremental
-   response in that it begins with two SOA RRs, the server's current SOA
-   followed by the SOA of the client's version which is about to be
-   replaced.
-
-   5. Purging Strategy
-
-   An IXFR server can not be required to hold all previous versions
-   forever and may delete them anytime. In general, there is a trade-off
-   between the size of storage space and the possibility of using IXFR.
-
-   Information about older versions should be purged if the total length
-   of an IXFR response would be longer than that of an AXFR response.
-   Given that the purpose of IXFR is to reduce AXFR overhead, this
-   strategy is quite reasonable.  The strategy assures that the amount
-   of storage required is at most twice that of the current zone
-   information.
-
-
-
-Ohta                        Standards Track                     [Page 3]
-
-RFC 1995            Incremental Zone Transfer in DNS         August 1996
-
-
-   Information older than the SOA expire period may also be purged.
-
-6. Optional Condensation of Multiple Versions
-
-   An IXFR server may optionally condense multiple difference sequences
-   into a single difference sequence, thus, dropping information on
-   intermediate versions.
-
-   This may be beneficial if a lot of versions, not all of which are
-   useful, are generated. For example, if multiple ftp servers share a
-   single DNS name and the IP address associated with the name is
-   changed once a minute to balance load between the ftp servers, it is
-   not so important to keep track of all the history of changes.
-
-   But, this feature may not be so useful if an IXFR client has access
-   to two IXFR servers: A and B, with inconsistent condensation results.
-   The current version of the IXFR client, received from server A, may
-   be unknown to server B. In such a case, server B can not provide
-   incremental data from the unknown version and a full zone transfer is
-   necessary.
-
-   Condensation is completely optional. Clients can't detect from the
-   response whether the server has condensed the reply or not.
-
-   For interoperability, IXFR servers, including those without the
-   condensation feature, should not flag an error even if it receives a
-   client's IXFR request with a unknown version number and should,
-   instead, attempt to perform a full zone transfer.
-
-7. Example
-
-   Given the following three generations of data with the current serial
-   number of 3,
-
-      JAIN.AD.JP.         IN SOA NS.JAIN.AD.JP. mohta.jain.ad.jp. (
-                                        1 600 600 3600000 604800)
-                          IN NS  NS.JAIN.AD.JP.
-      NS.JAIN.AD.JP.      IN A   133.69.136.1
-      NEZU.JAIN.AD.JP.    IN A   133.69.136.5
-
-   NEZU.JAIN.AD.JP. is removed and JAIN-BB.JAIN.AD.JP. is added.
-
-      jain.ad.jp.         IN SOA ns.jain.ad.jp. mohta.jain.ad.jp. (
-                                        2 600 600 3600000 604800)
-                          IN NS  NS.JAIN.AD.JP.
-      NS.JAIN.AD.JP.      IN A   133.69.136.1
-      JAIN-BB.JAIN.AD.JP. IN A   133.69.136.4
-                          IN A   192.41.197.2
-
-
-
-Ohta                        Standards Track                     [Page 4]
-
-RFC 1995            Incremental Zone Transfer in DNS         August 1996
-
-
-   One of the IP addresses of JAIN-BB.JAIN.AD.JP. is changed.
-
-      JAIN.AD.JP.         IN SOA ns.jain.ad.jp. mohta.jain.ad.jp. (
-                                        3 600 600 3600000 604800)
-                          IN NS  NS.JAIN.AD.JP.
-      NS.JAIN.AD.JP.      IN A   133.69.136.1
-      JAIN-BB.JAIN.AD.JP. IN A   133.69.136.3
-                          IN A   192.41.197.2
-
-   The following IXFR query
-
-                 +---------------------------------------------------+
-      Header     | OPCODE=SQUERY                                     |
-                 +---------------------------------------------------+
-      Question   | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR          |
-                 +---------------------------------------------------+
-      Answer     | <empty>                                           |
-                 +---------------------------------------------------+
-      Authority  | JAIN.AD.JP.         IN SOA serial=1               |
-                 +---------------------------------------------------+
-      Additional | <empty>                                           |
-                 +---------------------------------------------------+
-
-   could be replied to with the following full zone transfer message:
-
-                 +---------------------------------------------------+
-      Header     | OPCODE=SQUERY, RESPONSE                           |
-                 +---------------------------------------------------+
-      Question   | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR          |
-                 +---------------------------------------------------+
-      Answer     | JAIN.AD.JP.         IN SOA serial=3               |
-                 | JAIN.AD.JP.         IN NS  NS.JAIN.AD.JP.         |
-                 | NS.JAIN.AD.JP.      IN A   133.69.136.1           |
-                 | JAIN-BB.JAIN.AD.JP. IN A   133.69.136.3           |
-                 | JAIN-BB.JAIN.AD.JP. IN A   192.41.197.2           |
-                 | JAIN.AD.JP.         IN SOA serial=3               |
-                 +---------------------------------------------------+
-      Authority  | <empty>                                           |
-                 +---------------------------------------------------+
-      Additional | <empty>                                           |
-                 +---------------------------------------------------+
-
-
-
-
-
-
-
-
-
-
-Ohta                        Standards Track                     [Page 5]
-
-RFC 1995            Incremental Zone Transfer in DNS         August 1996
-
-
-   or with the following incremental message:
-
-                 +---------------------------------------------------+
-      Header     | OPCODE=SQUERY, RESPONSE                           |
-                 +---------------------------------------------------+
-      Question   | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR          |
-                 +---------------------------------------------------+
-      Answer     | JAIN.AD.JP.         IN SOA serial=3               |
-                 | JAIN.AD.JP.         IN SOA serial=1               |
-                 | NEZU.JAIN.AD.JP.    IN A   133.69.136.5           |
-                 | JAIN.AD.JP.         IN SOA serial=2               |
-                 | JAIN-BB.JAIN.AD.JP. IN A   133.69.136.4           |
-                 | JAIN-BB.JAIN.AD.JP. IN A   192.41.197.2           |
-                 | JAIN.AD.JP.         IN SOA serial=2               |
-                 | JAIN-BB.JAIN.AD.JP. IN A   133.69.136.4           |
-                 | JAIN.AD.JP.         IN SOA serial=3               |
-                 | JAIN-BB.JAIN.AD.JP. IN A   133.69.136.3           |
-                 | JAIN.AD.JP.         IN SOA serial=3               |
-                 +---------------------------------------------------+
-      Authority  | <empty>                                           |
-                 +---------------------------------------------------+
-      Additional | <empty>                                           |
-                 +---------------------------------------------------+
-
-   or with the following condensed incremental message:
-
-                 +---------------------------------------------------+
-      Header     | OPCODE=SQUERY, RESPONSE                           |
-                 +---------------------------------------------------+
-      Question   | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR          |
-                 +---------------------------------------------------+
-      Answer     | JAIN.AD.JP.         IN SOA serial=3               |
-                 | JAIN.AD.JP.         IN SOA serial=1               |
-                 | NEZU.JAIN.AD.JP.    IN A   133.69.136.5           |
-                 | JAIN.AD.JP.         IN SOA serial=3               |
-                 | JAIN-BB.JAIN.AD.JP. IN A   133.69.136.3           |
-                 | JAIN-BB.JAIN.AD.JP. IN A   192.41.197.2           |
-                 | JAIN.AD.JP.         IN SOA serial=3               |
-                 +---------------------------------------------------+
-      Authority  | <empty>                                           |
-                 +---------------------------------------------------+
-      Additional | <empty>                                           |
-                 +---------------------------------------------------+
-
-
-
-
-
-
-
-
-Ohta                        Standards Track                     [Page 6]
-
-RFC 1995            Incremental Zone Transfer in DNS         August 1996
-
-
-   or, if UDP packet overflow occurs, with the following message:
-
-                 +---------------------------------------------------+
-      Header     | OPCODE=SQUERY, RESPONSE                           |
-                 +---------------------------------------------------+
-      Question   | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR          |
-                 +---------------------------------------------------+
-      Answer     | JAIN.AD.JP.         IN SOA serial=3               |
-                 +---------------------------------------------------+
-      Authority  | <empty>                                           |
-                 +---------------------------------------------------+
-      Additional | <empty>                                           |
-                 +---------------------------------------------------+
-
-8. Acknowledgements
-
-   The original idea of IXFR was conceived by Anant Kumar, Steve Hotz
-   and Jon Postel.
-
-   For the refinement of the protocol and documentation, many people
-   have contributed including, but not limited to, Anant Kumar, Robert
-   Austein, Paul Vixie, Randy Bush, Mark Andrews, Robert Elz and the
-   members of the IETF DNSIND working group.
-
-9. References
-
-   [NOTIFY] Vixie, P., "DNS NOTIFY: A Mechanism for Prompt
-   Notification of Zone Changes", RFC 1996, August 1996.
-
-   [STD13] Mockapetris, P., "Domain Name System", STD 13, RFC 1034 and
-   RFC 1035), November 1987.
-
-10. Security Considerations
-
-   Though DNS is related to several security problems, no attempt is
-   made to fix them in this document.
-
-   This document is believed to introduce no additional security
-   problems to the current DNS protocol.
-
-
-
-
-
-
-
-
-
-
-
-
-Ohta                        Standards Track                     [Page 7]
-
-RFC 1995            Incremental Zone Transfer in DNS         August 1996
-
-
-11. Author's Address
-
-   Masataka Ohta
-   Computer Center
-   Tokyo Institute of Technology
-   2-12-1, O-okayama, Meguro-ku, Tokyo 152, JAPAN
-
-   Phone: +81-3-5734-3299
-   Fax: +81-3-5734-3415
-   EMail: mohta@necom830.hpcl.titech.ac.jp
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ohta                        Standards Track                     [Page 8]
-
diff --git a/contrib/bind9/doc/rfc/rfc1996.txt b/contrib/bind9/doc/rfc/rfc1996.txt
deleted file mode 100644
index b08f200..0000000
--- a/contrib/bind9/doc/rfc/rfc1996.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                           P. Vixie
-Request for Comments: 1996                                           ISC
-Updates: 1035                                                August 1996
-Category: Standards Track
-
-
-    A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Abstract
-
-   This memo describes the NOTIFY opcode for DNS, by which a master
-   server advises a set of slave servers that the master's data has been
-   changed and that a query should be initiated to discover the new
-   data.
-
-1. Rationale and Scope
-
-   1.1. Slow propagation of new and changed data in a DNS zone can be
-   due to a zone's relatively long refresh times.  Longer refresh times
-   are beneficial in that they reduce load on the master servers, but
-   that benefit comes at the cost of long intervals of incoherence among
-   authority servers whenever the zone is updated.
-
-   1.2. The DNS NOTIFY transaction allows master servers to inform slave
-   servers when the zone has changed -- an interrupt as opposed to poll
-   model -- which it is hoped will reduce propagation delay while not
-   unduly increasing the masters' load.  This specification only allows
-   slaves to be notified of SOA RR changes, but the architechture of
-   NOTIFY is intended to be extensible to other RR types.
-
-   1.3. This document intentionally gives more definition to the roles
-   of "Master," "Slave" and "Stealth" servers, their enumeration in NS
-   RRs, and the SOA MNAME field.  In that sense, this document can be
-   considered an addendum to [RFC1035].
-
-
-
-
-
-
-
-
-
-Vixie                       Standards Track                     [Page 1]
-
-RFC 1996                       DNS NOTIFY                    August 1996
-
-
-2. Definitions and Invariants
-
-   2.1. The following definitions are used in this document:
-
-   Slave           an authoritative server which uses zone transfer to
-                   retrieve the zone.  All slave servers are named in
-                   the NS RRs for the zone.
-
-   Master          any authoritative server configured to be the source
-                   of zone transfer for one or more slave servers.
-
-   Primary Master  master server at the root of the zone transfer
-                   dependency graph.  The primary master is named in the
-                   zone's SOA MNAME field and optionally by an NS RR.
-                   There is by definition only one primary master server
-                   per zone.
-
-   Stealth         like a slave server except not listed in an NS RR for
-                   the zone.  A stealth server, unless explicitly
-                   configured to do otherwise, will set the AA bit in
-                   responses and be capable of acting as a master.  A
-                   stealth server will only be known by other servers if
-                   they are given static configuration data indicating
-                   its existence.
-
-   Notify Set      set of servers to be notified of changes to some
-                   zone.  Default is all servers named in the NS RRset,
-                   except for any server also named in the SOA MNAME.
-                   Some implementations will permit the name server
-                   administrator to override this set or add elements to
-                   it (such as, for example, stealth servers).
-
-   2.2. The zone's servers must be organized into a dependency graph
-   such that there is a primary master, and all other servers must use
-   AXFR or IXFR either from the primary master or from some slave which
-   is also a master.  No loops are permitted in the AXFR dependency
-   graph.
-
-3. NOTIFY Message
-
-   3.1. When a master has updated one or more RRs in which slave servers
-   may be interested, the master may send the changed RR's name, class,
-   type, and optionally, new RDATA(s), to each known slave server using
-   a best efforts protocol based on the NOTIFY opcode.
-
-   3.2. NOTIFY uses the DNS Message Format, although it uses only a
-   subset of the available fields.  Fields not otherwise described
-   herein are to be filled with binary zero (0), and implementations
-
-
-
-Vixie                       Standards Track                     [Page 2]
-
-RFC 1996                       DNS NOTIFY                    August 1996
-
-
-   must ignore all messages for which this is not the case.
-
-   3.3. NOTIFY is similar to QUERY in that it has a request message with
-   the header QR flag "clear" and a response message with QR "set".  The
-   response message contains no useful information, but its reception by
-   the master is an indication that the slave has received the NOTIFY
-   and that the master can remove the slave from any retry queue for
-   this NOTIFY event.
-
-   3.4. The transport protocol used for a NOTIFY transaction will be UDP
-   unless the master has reason to believe that TCP is necessary; for
-   example, if a firewall has been installed between master and slave,
-   and only TCP has been allowed; or, if the changed RR is too large to
-   fit in a UDP/DNS datagram.
-
-   3.5. If TCP is used, both master and slave must continue to offer
-   name service during the transaction, even when the TCP transaction is
-   not making progress.  The NOTIFY request is sent once, and a
-   "timeout" is said to have occurred if no NOTIFY response is received
-   within a reasonable interval.
-
-   3.6. If UDP is used, a master periodically sends a NOTIFY request to
-   a slave until either too many copies have been sent (a "timeout"), an
-   ICMP message indicating that the port is unreachable, or until a
-   NOTIFY response is received from the slave with a matching query ID,
-   QNAME, IP source address, and UDP source port number.
-
-   Note:
-      The interval between transmissions, and the total number of
-      retransmissions, should be operational parameters specifiable by
-      the name server administrator, perhaps on a per-zone basis.
-      Reasonable defaults are a 60 second interval (or timeout if
-      using TCP), and a maximum of 5 retransmissions (for UDP).  It is
-      considered reasonable to use additive or exponential backoff for
-      the retry interval.
-
-   3.7. A NOTIFY request has QDCOUNT>0, ANCOUNT>=0, AUCOUNT>=0,
-   ADCOUNT>=0.  If ANCOUNT>0, then the answer section represents an
-   unsecure hint at the new RRset for this <QNAME,QCLASS,QTYPE>.  A
-   slave receiving such a hint is free to treat equivilence of this
-   answer section with its local data as a "no further work needs to be
-   done" indication.  If ANCOUNT=0, or ANCOUNT>0 and the answer section
-   differs from the slave's local data, then the slave should query its
-   known masters to retrieve the new data.
-
-   3.8. In no case shall the answer section of a NOTIFY request be used
-   to update a slave's local data, or to indicate that a zone transfer
-   needs to be undertaken, or to change the slave's zone refresh timers.
-
-
-
-Vixie                       Standards Track                     [Page 3]
-
-RFC 1996                       DNS NOTIFY                    August 1996
-
-
-   Only a "data present; data same" condition can lead a slave to act
-   differently if ANCOUNT>0 than it would if ANCOUNT=0.
-
-   3.9. This version of the NOTIFY specification makes no use of the
-   authority or additional data sections, and so conforming
-   implementations should set AUCOUNT=0 and ADCOUNT=0 when transmitting
-   requests.  Since a future revision of this specification may define a
-   backwards compatible use for either or both of these sections,
-   current implementations must ignore these sections, but not the
-   entire message, if AUCOUNT>0 and/or ADCOUNT>0.
-
-   3.10. If a slave receives a NOTIFY request from a host that is not a
-   known master for the zone containing the QNAME, it should ignore the
-   request and produce an error message in its operations log.
-
-   Note:
-      This implies that slaves of a multihomed master must either know
-      their master by the "closest" of the master's interface
-      addresses, or must know all of the master's interface addresses.
-      Otherwise, a valid NOTIFY request might come from an address
-      that is not on the slave's state list of masters for the zone,
-      which would be an error.
-
-   3.11. The only defined NOTIFY event at this time is that the SOA RR
-   has changed.  Upon completion of a NOTIFY transaction for QTYPE=SOA,
-   the slave should behave as though the zone given in the QNAME had
-   reached its REFRESH interval (see [RFC1035]), i.e., it should query
-   its masters for the SOA of the zone given in the NOTIFY QNAME, and
-   check the answer to see if the SOA SERIAL has been incremented since
-   the last time the zone was fetched.  If so, a zone transfer (either
-   AXFR or IXFR) should be initiated.
-
-   Note:
-      Because a deep server dependency graph may have multiple paths
-      from the primary master to any given slave, it is possible that
-      a slave will receive a NOTIFY from one of its known masters even
-      though the rest of its known masters have not yet updated their
-      copies of the zone.  Therefore, when issuing a QUERY for the
-      zone's SOA, the query should be directed at the known master who
-      was the source of the NOTIFY event, and not at any of the other
-      known masters.  This represents a departure from [RFC1035],
-      which specifies that upon expiry of the SOA REFRESH interval,
-      all known masters should be queried in turn.
-
-   3.12. If a NOTIFY request is received by a slave who does not
-   implement the NOTIFY opcode, it will respond with a NOTIMP
-   (unimplemented feature error) message.  A master server who receives
-   such a NOTIMP should consider the NOTIFY transaction complete for
-
-
-
-Vixie                       Standards Track                     [Page 4]
-
-RFC 1996                       DNS NOTIFY                    August 1996
-
-
-   that slave.
-
-4. Details and Examples
-
-   4.1. Retaining query state information across host reboots is
-   optional, but it is reasonable to simply execute an SOA NOTIFY
-   transaction on each authority zone when a server first starts.
-
-   4.2. Each slave is likely to receive several copies of the same
-   NOTIFY request:  One from the primary master, and one from each other
-   slave as that slave transfers the new zone and notifies its potential
-   peers.  The NOTIFY protocol supports this multiplicity by requiring
-   that NOTIFY be sent by a slave/master only AFTER it has updated the
-   SOA RR or has determined that no update is necessary, which in
-   practice means after a successful zone transfer.  Thus, barring
-   delivery reordering, the last NOTIFY any slave receives will be the
-   one indicating the latest change.  Since a slave always requests SOAs
-   and AXFR/IXFRs only from its known masters, it will have an
-   opportunity to retry its QUERY for the SOA after each of its masters
-   have completed each zone update.
-
-   4.3. If a master server seeks to avoid causing a large number of
-   simultaneous outbound zone transfers, it may delay for an arbitrary
-   length of time before sending a NOTIFY message to any given slave.
-   It is expected that the time will be chosen at random, so that each
-   slave will begin its transfer at a unique time.  The delay shall not
-   in any case be longer than the SOA REFRESH time.
-
-   Note:
-      This delay should be a parameter that each primary master name
-      server can specify, perhaps on a per-zone basis.  Random delays
-      of between 30 and 60 seconds would seem adequate if the servers
-      share a LAN and the zones are of moderate size.
-
-   4.4. A slave which receives a valid NOTIFY should defer action on any
-   subsequent NOTIFY with the same <QNAME,QCLASS,QTYPE> until it has
-   completed the transaction begun by the first NOTIFY.  This duplicate
-   rejection is necessary to avoid having multiple notifications lead to
-   pummeling the master server.
-
-
-
-
-
-
-
-
-
-
-
-
-Vixie                       Standards Track                     [Page 5]
-
-RFC 1996                       DNS NOTIFY                    August 1996
-
-
-   4.5 Zone has Updated on Primary Master
-
-   Primary master sends a NOTIFY request to all servers named in Notify
-   Set.  The NOTIFY request has the following characteristics:
-
-      query ID:   (new)
-      op:         NOTIFY (4)
-      resp:       NOERROR
-      flags:      AA
-      qcount:     1
-      qname:      (zone name)
-      qclass:     (zone class)
-      qtype:      T_SOA
-
-   4.6 Zone has Updated on a Slave that is also a Master
-
-   As above in 4.5, except that this server's Notify Set may be
-   different from the Primary Master's due to optional static
-   specification of local stealth servers.
-
-   4.7 Slave Receives a NOTIFY Request from a Master
-
-   When a slave server receives a NOTIFY request from one of its locally
-   designated masters for the zone enclosing the given QNAME, with
-   QTYPE=SOA and QR=0, it should enter the state it would if the zone's
-   refresh timer had expired.  It will also send a NOTIFY response back
-   to the NOTIFY request's source, with the following characteristics:
-
-      query ID:   (same)
-      op:         NOTIFY (4)
-      resp:       NOERROR
-      flags:      QR AA
-      qcount:     1
-      qname:      (zone name)
-      qclass:     (zone class)
-      qtype:      T_SOA
-
-   This is intended to be identical to the NOTIFY request, except that
-   the QR bit is also set.  The query ID of the response must be the
-   same as was received in the request.
-
-   4.8 Master Receives a NOTIFY Response from Slave
-
-   When a master server receives a NOTIFY response, it deletes this
-   query from the retry queue, thus completing the "notification
-   process" of "this" RRset change to "that" server.
-
-
-
-
-
-Vixie                       Standards Track                     [Page 6]
-
-RFC 1996                       DNS NOTIFY                    August 1996
-
-
-5. Security Considerations
-
-   We believe that the NOTIFY operation's only security considerations
-   are:
-
-   1. That a NOTIFY request with a forged IP/UDP source address can
-      cause a slave to send spurious SOA queries to its masters,
-      leading to a benign denial of service attack if the forged
-      requests are sent very often.
-
-   2. That TCP spoofing could be used against a slave server given
-      NOTIFY as a means of synchronizing an SOA query and UDP/DNS
-      spoofing as a means of forcing a zone transfer.
-
-6. References
-
-   [RFC1035]
-      Mockapetris, P., "Domain Names - Implementation and
-      Specification", STD 13, RFC 1035, November 1987.
-
-   [IXFR]
-      Ohta, M., "Incremental Zone Transfer", RFC 1995, August 1996.
-
-7. Author's Address
-
-   Paul Vixie
-   Internet Software Consortium
-   Star Route Box 159A
-   Woodside, CA 94062
-
-   Phone: +1 415 747 0204
-   EMail: paul@vix.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Vixie                       Standards Track                     [Page 7]
-
diff --git a/contrib/bind9/doc/rfc/rfc2052.txt b/contrib/bind9/doc/rfc/rfc2052.txt
deleted file mode 100644
index 46ba362..0000000
--- a/contrib/bind9/doc/rfc/rfc2052.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                     A. Gulbrandsen
-Request for Comments: 2052                            Troll Technologies
-Updates: 1035, 1183                                             P. Vixie
-Category: Experimental                                 Vixie Enterprises
-                                                            October 1996
-
-
-       A DNS RR for specifying the location of services (DNS SRV)
-
-Status of this Memo
-
-   This memo defines an Experimental Protocol for the Internet
-   community.  This memo does not specify an Internet standard of any
-   kind.  Discussion and suggestions for improvement are requested.
-   Distribution of this memo is unlimited.
-
-Abstract
-
-   This document describes a DNS RR which specifies the location of the
-   server(s) for a specific protocol and domain (like a more general
-   form of MX).
-
-Overview and rationale
-
-   Currently, one must either know the exact address of a server to
-   contact it, or broadcast a question.  This has led to, for example,
-   ftp.whatever.com aliases, the SMTP-specific MX RR, and using MAC-
-   level broadcasts to locate servers.
-
-   The SRV RR allows administrators to use several servers for a single
-   domain, to move services from host to host with little fuss, and to
-   designate some hosts as primary servers for a service and others as
-   backups.
-
-   Clients ask for a specific service/protocol for a specific domain
-   (the word domain is used here in the strict RFC 1034 sense), and get
-   back the names of any available servers.
-
-Introductory example
-
-   When a SRV-cognizant web-browser wants to retrieve
-
-      http://www.asdf.com/
-
-   it does a lookup of
-
-      http.tcp.www.asdf.com
-
-
-
-
-Gulbrandsen & Vixie           Experimental                      [Page 1]
-
-RFC 2052                       DNS SRV RR                   October 1996
-
-
-   and retrieves the document from one of the servers in the reply.  The
-   example zone file near the end of the memo contains answering RRs for
-   this query.
-
-The format of the SRV RR
-
-   Here is the format of the SRV RR, whose DNS type code is 33:
-
-        Service.Proto.Name TTL Class SRV Priority Weight Port Target
-
-        (There is an example near the end of this document.)
-
-   Service
-        The symbolic name of the desired service, as defined in Assigned
-        Numbers or locally.
-
-        Some widely used services, notably POP, don't have a single
-        universal name.  If Assigned Numbers names the service
-        indicated, that name is the only name which is legal for SRV
-        lookups.  Only locally defined services may be named locally.
-        The Service is case insensitive.
-
-   Proto
-        TCP and UDP are at present the most useful values
-        for this field, though any name defined by Assigned Numbers or
-        locally may be used (as for Service).  The Proto is case
-        insensitive.
-
-   Name
-        The domain this RR refers to.  The SRV RR is unique in that the
-        name one searches for is not this name; the example near the end
-        shows this clearly.
-
-   TTL
-        Standard DNS meaning.
-
-   Class
-        Standard DNS meaning.
-
-   Priority
-        As for MX, the priority of this target host.  A client MUST
-        attempt to contact the target host with the lowest-numbered
-        priority it can reach; target hosts with the same priority
-        SHOULD be tried in pseudorandom order.  The range is 0-65535.
-
-
-
-
-
-
-
-Gulbrandsen & Vixie           Experimental                      [Page 2]
-
-RFC 2052                       DNS SRV RR                   October 1996
-
-
-   Weight
-        Load balancing mechanism.  When selecting a target host among
-        the those that have the same priority, the chance of trying this
-        one first SHOULD be proportional to its weight.  The range of
-        this number is 1-65535.  Domain administrators are urged to use
-        Weight 0 when there isn't any load balancing to do, to make the
-        RR easier to read for humans (less noisy).
-
-   Port
-        The port on this target host of this service.  The range is
-        0-65535.  This is often as specified in Assigned Numbers but
-        need not be.
-
-   Target
-        As for MX, the domain name of the target host.  There MUST be
-        one or more A records for this name. Implementors are urged, but
-        not required, to return the A record(s) in the Additional Data
-        section.  Name compression is to be used for this field.
-
-        A Target of "." means that the service is decidedly not
-        available at this domain.
-
-Domain administrator advice
-
-   Asking everyone to update their telnet (for example) clients when the
-   first internet site adds a SRV RR for Telnet/TCP is futile (even if
-   desirable).  Therefore SRV will have to coexist with A record lookups
-   for a long time, and DNS administrators should try to provide A
-   records to support old clients:
-
-      - Where the services for a single domain are spread over several
-        hosts, it seems advisable to have a list of A RRs at the same
-        DNS node as the SRV RR, listing reasonable (if perhaps
-        suboptimal) fallback hosts for Telnet, NNTP and other protocols
-        likely to be used with this name.  Note that some programs only
-        try the first address they get back from e.g. gethostbyname(),
-        and we don't know how widespread this behaviour is.
-
-      - Where one service is provided by several hosts, one can either
-        provide A records for all the hosts (in which case the round-
-        robin mechanism, where available, will share the load equally)
-        or just for one (presumably the fastest).
-
-      - If a host is intended to provide a service only when the main
-        server(s) is/are down, it probably shouldn't be listed in A
-        records.
-
-
-
-
-
-Gulbrandsen & Vixie           Experimental                      [Page 3]
-
-RFC 2052                       DNS SRV RR                   October 1996
-
-
-      - Hosts that are referenced by backup A records must use the port
-        number specified in Assigned Numbers for the service.
-
-   Currently there's a practical limit of 512 bytes for DNS replies.
-   Until all resolvers can handle larger responses, domain
-   administrators are strongly advised to keep their SRV replies below
-   512 bytes.
-
-   All round numbers, wrote Dr. Johnson, are false, and these numbers
-   are very round: A reply packet has a 30-byte overhead plus the name
-   of the service ("telnet.tcp.asdf.com" for instance); each SRV RR adds
-   20 bytes plus the name of the target host; each NS RR in the NS
-   section is 15 bytes plus the name of the name server host; and
-   finally each A RR in the additional data section is 20 bytes or so,
-   and there are A's for each SRV and NS RR mentioned in the answer.
-   This size estimate is extremely crude, but shouldn't underestimate
-   the actual answer size by much.  If an answer may be close to the
-   limit, using e.g. "dig" to look at the actual answer is a good idea.
-
-The "Weight" field
-
-   Weight, the load balancing field, is not quite satisfactory, but the
-   actual load on typical servers changes much too quickly to be kept
-   around in DNS caches.  It seems to the authors that offering
-   administrators a way to say "this machine is three times as fast as
-   that one" is the best that can practically be done.
-
-   The only way the authors can see of getting a "better" load figure is
-   asking a separate server when the client selects a server and
-   contacts it.  For short-lived services like SMTP an extra step in the
-   connection establishment seems too expensive, and for long-lived
-   services like telnet, the load figure may well be thrown off a minute
-   after the connection is established when someone else starts or
-   finishes a heavy job.
-
-The Port number
-
-   Currently, the translation from service name to port number happens
-   at the client, often using a file such as /etc/services.
-
-   Moving this information to the DNS makes it less necessary to update
-   these files on every single computer of the net every time a new
-   service is added, and makes it possible to move standard services out
-   of the "root-only" port range on unix
-
-
-
-
-
-
-
-Gulbrandsen & Vixie           Experimental                      [Page 4]
-
-RFC 2052                       DNS SRV RR                   October 1996
-
-
-Usage rules
-
-   A SRV-cognizant client SHOULD use this procedure to locate a list of
-   servers and connect to the preferred one:
-
-        Do a lookup for QNAME=service.protocol.target, QCLASS=IN,
-        QTYPE=SRV.
-
-        If the reply is NOERROR, ANCOUNT>0 and there is at least one SRV
-        RR which specifies the requested Service and Protocol in the
-        reply:
-
-             If there is precisely one SRV RR, and its Target is "."
-             (the root domain), abort.
-
-             Else, for all such RR's, build a list of (Priority, Weight,
-             Target) tuples
-
-             Sort the list by priority (lowest number first)
-
-             Create a new empty list
-
-             For each distinct priority level
-                  While there are still elements left at this priority
-                  level
-                       Select an element randomly, with probability
-                       Weight, and move it to the tail of the new list
-
-             For each element in the new list
-
-                  query the DNS for A RR's for the Target or use any
-                  RR's found in the Additional Data secion of the
-                  earlier SRV query.
-
-                  for each A RR found, try to connect to the (protocol,
-                  address, service).
-
-        else if the service desired is SMTP
-
-             skip to RFC 974 (MX).
-
-        else
-
-             Do a lookup for QNAME=target, QCLASS=IN, QTYPE=A
-
-             for each A RR found, try to connect to the (protocol,
-             address, service)
-
-
-
-
-Gulbrandsen & Vixie           Experimental                      [Page 5]
-
-RFC 2052                       DNS SRV RR                   October 1996
-
-
-   Notes:
-
-      - Port numbers SHOULD NOT be used in place of the symbolic service
-        or protocol names (for the same reason why variant names cannot
-        be allowed: Applications would have to do two or more lookups).
-
-      - If a truncated response comes back from an SRV query, and the
-        Additional Data section has at least one complete RR in it, the
-        answer MUST be considered complete and the client resolver
-        SHOULD NOT retry the query using TCP, but use normal UDP queries
-        for A RR's missing from the Additional Data section.
-
-      - A client MAY use means other than Weight to choose among target
-        hosts with equal Priority.
-
-      - A client MUST parse all of the RR's in the reply.
-
-      - If the Additional Data section doesn't contain A RR's for all
-        the SRV RR's and the client may want to connect to the target
-        host(s) involved, the client MUST look up the A RR(s).  (This
-        happens quite often when the A RR has shorter TTL than the SRV
-        or NS RR's.)
-
-      - A future standard could specify that a SRV RR whose Protocol was
-        TCP and whose Service was SMTP would override RFC 974's rules
-        with regard to the use of an MX RR.  This would allow firewalled
-        organizations with several SMTP relays to control the load
-        distribution using the Weight field.
-
-      - Future protocols could be designed to use SRV RR lookups as the
-        means by which clients locate their servers.
-
-Fictional example
-
-   This is (part of) the zone file for asdf.com, a still-unused domain:
-
-        $ORIGIN asdf.com.
-        @               SOA server.asdf.com. root.asdf.com. (
-                            1995032001 3600 3600 604800 86400 )
-                        NS  server.asdf.com.
-                        NS  ns1.ip-provider.net.
-                        NS  ns2.ip-provider.net.
-        ftp.tcp         SRV 0 0 21 server.asdf.com.
-        finger.tcp      SRV 0 0 79 server.asdf.com.
-        ; telnet - use old-slow-box or new-fast-box if either is
-        ; available, make three quarters of the logins go to
-        ; new-fast-box.
-        telnet.tcp      SRV 0 1 23 old-slow-box.asdf.com.
-
-
-
-Gulbrandsen & Vixie           Experimental                      [Page 6]
-
-RFC 2052                       DNS SRV RR                   October 1996
-
-
-                        SRV 0 3 23 new-fast-box.asdf.com.
-        ; if neither old-slow-box or new-fast-box is up, switch to
-        ; using the sysdmin's box and the server
-                        SRV 1 0 23 sysadmins-box.asdf.com.
-                        SRV 1 0 23 server.asdf.com.
-        ; HTTP - server is the main server, new-fast-box is the backup
-        ; (On new-fast-box, the HTTP daemon runs on port 8000)
-        http.tcp        SRV 0 0 80 server.asdf.com.
-                        SRV 10 0 8000 new-fast-box.asdf.com.
-        ; since we want to support both http://asdf.com/ and
-        ; http://www.asdf.com/ we need the next two RRs as well
-        http.tcp.www    SRV 0 0 80 server.asdf.com.
-                        SRV 10 0 8000 new-fast-box.asdf.com.
-        ; SMTP - mail goes to the server, and to the IP provider if
-        ; the net is down
-        smtp.tcp        SRV 0 0 25 server.asdf.com.
-                        SRV 1 0 25 mailhost.ip-provider.net.
-        @               MX  0 server.asdf.com.
-                        MX  1 mailhost.ip-provider.net.
-        ; NNTP - use the IP providers's NNTP server
-        nntp.tcp        SRV 0 0 119 nntphost.ip-provider.net.
-        ; IDB is an locally defined protocol
-        idb.tcp         SRV  0 0 2025 new-fast-box.asdf.com.
-        ; addresses
-        server          A   172.30.79.10
-        old-slow-box    A   172.30.79.11
-        sysadmins-box   A   172.30.79.12
-        new-fast-box    A   172.30.79.13
-        ; backup A records - new-fast-box and old-slow-box are
-        ; included, naturally, and server is too, but might go
-        ; if the load got too bad
-        @               A   172.30.79.10
-                        A   172.30.79.11
-                        A   172.30.79.13
-        ; backup A RR for www.asdf.com
-        www             A       172.30.79.10
-        ; NO other services are supported
-        *.tcp           SRV  0 0 0 .
-        *.udp           SRV  0 0 0 .
-
-   In this example, a telnet connection to "asdf.com." needs an SRV
-   lookup of "telnet.tcp.asdf.com." and possibly A lookups of "new-
-   fast-box.asdf.com." and/or the other hosts named.  The size of the
-   SRV reply is approximately 365 bytes:
-
-      30 bytes general overhead
-      20 bytes for the query string, "telnet.tcp.asdf.com."
-      130 bytes for 4 SRV RR's, 20 bytes each plus the lengths of "new-
-
-
-
-Gulbrandsen & Vixie           Experimental                      [Page 7]
-
-RFC 2052                       DNS SRV RR                   October 1996
-
-
-        fast-box", "old-slow-box", "server" and "sysadmins-box" -
-        "asdf.com" in the query section is quoted here and doesn't
-        need to be counted again.
-      75 bytes for 3 NS RRs, 15 bytes each plus the lengths of
-        "server", "ns1.ip-provider.net." and "ns2" - again, "ip-
-        provider.net." is quoted and only needs to be counted once.
-      120 bytes for the 6 A RR's mentioned by the SRV and NS RR's.
-
-Refererences
-
-   RFC 1918: Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G.,
-        and E.  Lear, "Address Allocation for Private Internets",
-        RFC 1918, February 1996.
-
-   RFC 1916 Berkowitz, H., Ferguson, P, Leland, W. and P. Nesser,
-        "Enterprise Renumbering: Experience and Information
-        Solicitation", RFC 1916, February 1996.
-
-   RFC 1912 Barr, D., "Common DNS Operational and Configuration
-        Errors", RFC 1912, February 1996.
-
-   RFC 1900: Carpenter, B., and Y. Rekhter, "Renumbering Needs Work",
-        RFC 1900, February 1996.
-
-   RFC 1920: Postel, J., "INTERNET OFFICIAL PROTOCOL STANDARDS",
-        STD 1, RFC 1920, March 1996.
-
-   RFC 1814: Gerich, E., "Unique Addresses are Good", RFC 1814, June
-             1995.
-
-   RFC 1794: Brisco, T., "DNS Support for Load Balancing", April 1995.
-
-   RFC 1713: Romao, A., "Tools for DNS debugging", November 1994.
-
-   RFC 1712: Farrell, C., Schulze, M., Pleitner, S., and D. Baldoni,
-        "DNS Encoding of Geographical Location", RFC 1712, November
-        1994.
-
-   RFC 1706: Manning, B. and R. Colella, "DNS NSAP Resource Records",
-        RFC 1706, October 1994.
-
-   RFC 1700: Reynolds, J., and J. Postel, "ASSIGNED NUMBERS",
-        STD 2, RFC 1700, October 1994.
-
-   RFC 1183: Ullmann, R., Mockapetris, P., Mamakos, L., and
-        C. Everhart, "New DNS RR Definitions", RFC 1183, November
-        1990.
-
-
-
-
-Gulbrandsen & Vixie           Experimental                      [Page 8]
-
-RFC 2052                       DNS SRV RR                   October 1996
-
-
-   RFC 1101: Mockapetris, P., "DNS encoding of network names and other
-        types", RFC 1101, April 1989.
-
-   RFC 1035: Mockapetris, P., "Domain names - implementation and
-        specification", STD 13, RFC 1035, November 1987.
-
-   RFC 1034: Mockapetris, P., "Domain names - concepts and
-        facilities", STD 13, RFC 1034, November 1987.
-
-   RFC 1033: Lottor, M., "Domain administrators operations guide",
-        RFC 1033, November 1987.
-
-   RFC 1032: Stahl, M., "Domain administrators guide", RFC 1032,
-        November 1987.
-
-   RFC 974: Partridge, C., "Mail routing and the domain system",
-        STD 14, RFC 974, January 1986.
-
-Security Considerations
-
-   The authors believes this RR to not cause any new security problems.
-   Some problems become more visible, though.
-
-      - The ability to specify ports on a fine-grained basis obviously
-        changes how a router can filter packets.  It becomes impossible
-        to block internal clients from accessing specific external
-        services, slightly harder to block internal users from running
-        unautorised services, and more important for the router
-        operations and DNS operations personnel to cooperate.
-
-      - There is no way a site can keep its hosts from being referenced
-        as servers (as, indeed, some sites become unwilling secondary
-        MXes today).  This could lead to denial of service.
-
-      - With SRV, DNS spoofers can supply false port numbers, as well as
-        host names and addresses.  The authors do not see any practical
-        effect of this.
-
-   We assume that as the DNS-security people invent new features, DNS
-   servers will return the relevant RRs in the Additional Data section
-   when answering an SRV query.
-
-
-
-
-
-
-
-
-
-
-Gulbrandsen & Vixie           Experimental                      [Page 9]
-
-RFC 2052                       DNS SRV RR                   October 1996
-
-
-Authors' Addresses
-
-   Arnt Gulbrandsen
-   Troll Tech
-   Postboks 6133 Etterstad
-   N-0602 Oslo
-   Norway
-
-   Phone: +47 22646966
-   EMail: agulbra@troll.no
-
-
-   Paul Vixie
-   Vixie Enterprises
-   Star Route 159A
-   Woodside, CA  94062
-
-   Phone: (415) 747-0204
-   EMail: paul@vix.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gulbrandsen & Vixie           Experimental                     [Page 10]
-
diff --git a/contrib/bind9/doc/rfc/rfc2104.txt b/contrib/bind9/doc/rfc/rfc2104.txt
deleted file mode 100644
index a205103..0000000
--- a/contrib/bind9/doc/rfc/rfc2104.txt
+++ /dev/null
@@ -1,620 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                       H. Krawczyk
-Request for Comments: 2104                                          IBM
-Category: Informational                                      M. Bellare
-                                                                   UCSD
-                                                             R. Canetti
-                                                                    IBM
-                                                          February 1997
-
-
-             HMAC: Keyed-Hashing for Message Authentication
-
-Status of This Memo
-
-   This memo provides information for the Internet community.  This memo
-   does not specify an Internet standard of any kind.  Distribution of
-   this memo is unlimited.
-
-Abstract
-
-   This document describes HMAC, a mechanism for message authentication
-   using cryptographic hash functions. HMAC can be used with any
-   iterative cryptographic hash function, e.g., MD5, SHA-1, in
-   combination with a secret shared key.  The cryptographic strength of
-   HMAC depends on the properties of the underlying hash function.
-
-1. Introduction
-
-   Providing a way to check the integrity of information transmitted
-   over or stored in an unreliable medium is a prime necessity in the
-   world of open computing and communications. Mechanisms that provide
-   such integrity check based on a secret key are usually called
-   "message authentication codes" (MAC). Typically, message
-   authentication codes are used between two parties that share a secret
-   key in order to validate information transmitted between these
-   parties. In this document we present such a MAC mechanism based on
-   cryptographic hash functions. This mechanism, called HMAC, is based
-   on work by the authors [BCK1] where the construction is presented and
-   cryptographically analyzed. We refer to that work for the details on
-   the rationale and security analysis of HMAC, and its comparison to
-   other keyed-hash methods.
-
-
-
-
-
-
-
-
-
-
-
-Krawczyk, et. al.            Informational                      [Page 1]
-
-RFC 2104                          HMAC                     February 1997
-
-
-   HMAC can be used in combination with any iterated cryptographic hash
-   function. MD5 and SHA-1 are examples of such hash functions. HMAC
-   also uses a secret key for calculation and verification of the
-   message authentication values. The main goals behind this
-   construction are
-
-   * To use, without modifications, available hash functions.
-     In particular, hash functions that perform well in software,
-     and for which code is freely and widely available.
-
-   * To preserve the original performance of the hash function without
-     incurring a significant degradation.
-
-   * To use and handle keys in a simple way.
-
-   * To have a well understood cryptographic analysis of the strength of
-     the authentication mechanism based on reasonable assumptions on the
-     underlying hash function.
-
-   * To allow for easy replaceability of the underlying hash function in
-     case that faster or more secure hash functions are found or
-     required.
-
-   This document specifies HMAC using a generic cryptographic hash
-   function (denoted by H). Specific instantiations of HMAC need to
-   define a particular hash function. Current candidates for such hash
-   functions include SHA-1 [SHA], MD5 [MD5], RIPEMD-128/160 [RIPEMD].
-   These different realizations of HMAC will be denoted by HMAC-SHA1,
-   HMAC-MD5, HMAC-RIPEMD, etc.
-
-   Note: To the date of writing of this document MD5 and SHA-1 are the
-   most widely used cryptographic hash functions. MD5 has been recently
-   shown to be vulnerable to collision search attacks [Dobb].  This
-   attack and other currently known weaknesses of MD5 do not compromise
-   the use of MD5 within HMAC as specified in this document (see
-   [Dobb]); however, SHA-1 appears to be a cryptographically stronger
-   function. To this date, MD5 can be considered for use in HMAC for
-   applications where the superior performance of MD5 is critical.   In
-   any case, implementers and users need to be aware of possible
-   cryptanalytic developments regarding any of these cryptographic hash
-   functions, and the eventual need to replace the underlying hash
-   function. (See section 6 for more information on the security of
-   HMAC.)
-
-
-
-
-
-
-
-
-Krawczyk, et. al.            Informational                      [Page 2]
-
-RFC 2104                          HMAC                     February 1997
-
-
-2. Definition of HMAC
-
-   The definition of HMAC requires a cryptographic hash function, which
-   we denote by H, and a secret key K. We assume H to be a cryptographic
-   hash function where data is hashed by iterating a basic compression
-   function on blocks of data.   We denote by B the byte-length of such
-   blocks (B=64 for all the above mentioned examples of hash functions),
-   and by L the byte-length of hash outputs (L=16 for MD5, L=20 for
-   SHA-1).  The authentication key K can be of any length up to B, the
-   block length of the hash function.  Applications that use keys longer
-   than B bytes will first hash the key using H and then use the
-   resultant L byte string as the actual key to HMAC. In any case the
-   minimal recommended length for K is L bytes (as the hash output
-   length). See section 3 for more information on keys.
-
-   We define two fixed and different strings ipad and opad as follows
-   (the 'i' and 'o' are mnemonics for inner and outer):
-
-                   ipad = the byte 0x36 repeated B times
-                  opad = the byte 0x5C repeated B times.
-
-   To compute HMAC over the data `text' we perform
-
-                    H(K XOR opad, H(K XOR ipad, text))
-
-   Namely,
-
-    (1) append zeros to the end of K to create a B byte string
-        (e.g., if K is of length 20 bytes and B=64, then K will be
-         appended with 44 zero bytes 0x00)
-    (2) XOR (bitwise exclusive-OR) the B byte string computed in step
-        (1) with ipad
-    (3) append the stream of data 'text' to the B byte string resulting
-        from step (2)
-    (4) apply H to the stream generated in step (3)
-    (5) XOR (bitwise exclusive-OR) the B byte string computed in
-        step (1) with opad
-    (6) append the H result from step (4) to the B byte string
-        resulting from step (5)
-    (7) apply H to the stream generated in step (6) and output
-        the result
-
-   For illustration purposes, sample code based on MD5 is provided as an
-   appendix.
-
-
-
-
-
-
-
-Krawczyk, et. al.            Informational                      [Page 3]
-
-RFC 2104                          HMAC                     February 1997
-
-
-3. Keys
-
-   The key for HMAC can be of any length (keys longer than B bytes are
-   first hashed using H).  However, less than L bytes is strongly
-   discouraged as it would decrease the security strength of the
-   function.  Keys longer than L bytes are acceptable but the extra
-   length would not significantly increase the function strength. (A
-   longer key may be advisable if the randomness of the key is
-   considered weak.)
-
-   Keys need to be chosen at random (or using a cryptographically strong
-   pseudo-random generator seeded with a random seed), and periodically
-   refreshed.  (Current attacks do not indicate a specific recommended
-   frequency for key changes as these attacks are practically
-   infeasible.  However, periodic key refreshment is a fundamental
-   security practice that helps against potential weaknesses of the
-   function and keys, and limits the damage of an exposed key.)
-
-4. Implementation Note
-
-   HMAC is defined in such a way that the underlying hash function H can
-   be used with no modification to its code. In particular, it uses the
-   function H with the pre-defined initial value IV (a fixed value
-   specified by each iterative hash function to initialize its
-   compression function).  However, if desired, a performance
-   improvement can be achieved at the cost of (possibly) modifying the
-   code of H to support variable IVs.
-
-   The idea is that the intermediate results of the compression function
-   on the B-byte blocks (K XOR ipad) and (K XOR opad) can be precomputed
-   only once at the time of generation of the key K, or before its first
-   use. These intermediate results are stored and then used to
-   initialize the IV of H each time that a message needs to be
-   authenticated.  This method saves, for each authenticated message,
-   the application of the compression function of H on two B-byte blocks
-   (i.e., on (K XOR ipad) and (K XOR opad)). Such a savings may be
-   significant when authenticating short streams of data.  We stress
-   that the stored intermediate values need to be treated and protected
-   the same as secret keys.
-
-   Choosing to implement HMAC in the above way is a decision of the
-   local implementation and has no effect on inter-operability.
-
-
-
-
-
-
-
-
-
-Krawczyk, et. al.            Informational                      [Page 4]
-
-RFC 2104                          HMAC                     February 1997
-
-
-5. Truncated output
-
-   A well-known practice with message authentication codes is to
-   truncate the output of the MAC and output only part of the bits
-   (e.g., [MM, ANSI]).  Preneel and van Oorschot [PV] show some
-   analytical advantages of truncating the output of hash-based MAC
-   functions. The results in this area are not absolute as for the
-   overall security advantages of truncation. It has advantages (less
-   information on the hash result available to an attacker) and
-   disadvantages (less bits to predict for the attacker).  Applications
-   of HMAC can choose to truncate the output of HMAC by outputting the t
-   leftmost bits of the HMAC computation for some parameter t (namely,
-   the computation is carried in the normal way as defined in section 2
-   above but the end result is truncated to t bits). We recommend that
-   the output length t be not less than half the length of the hash
-   output (to match the birthday attack bound) and not less than 80 bits
-   (a suitable lower bound on the number of bits that need to be
-   predicted by an attacker).  We propose denoting a realization of HMAC
-   that uses a hash function H with t bits of output as HMAC-H-t. For
-   example, HMAC-SHA1-80 denotes HMAC computed using the SHA-1 function
-   and with the output truncated to 80 bits.  (If the parameter t is not
-   specified, e.g. HMAC-MD5, then it is assumed that all the bits of the
-   hash are output.)
-
-6. Security
-
-   The security of the message authentication mechanism presented here
-   depends on cryptographic properties of the hash function H: the
-   resistance to collision finding (limited to the case where the
-   initial value is secret and random, and where the output of the
-   function is not explicitly available to the attacker), and the
-   message authentication property of the compression function of H when
-   applied to single blocks (in HMAC these blocks are partially unknown
-   to an attacker as they contain the result of the inner H computation
-   and, in particular, cannot be fully chosen by the attacker).
-
-   These properties, and actually stronger ones, are commonly assumed
-   for hash functions of the kind used with HMAC. In particular, a hash
-   function for which the above properties do not hold would become
-   unsuitable for most (probably, all) cryptographic applications,
-   including alternative message authentication schemes based on such
-   functions.  (For a complete analysis and rationale of the HMAC
-   function the reader is referred to [BCK1].)
-
-
-
-
-
-
-
-
-Krawczyk, et. al.            Informational                      [Page 5]
-
-RFC 2104                          HMAC                     February 1997
-
-
-   Given the limited confidence gained so far as for the cryptographic
-   strength of candidate hash functions, it is important to observe the
-   following two properties of the HMAC construction and its secure use
-   for message authentication:
-
-   1. The construction is independent of the details of the particular
-   hash function H in use and then the latter can be replaced by any
-   other secure (iterative) cryptographic hash function.
-
-   2. Message authentication, as opposed to encryption, has a
-   "transient" effect. A published breaking of a message authentication
-   scheme would lead to the replacement of that scheme, but would have
-   no adversarial effect on information authenticated in the past.  This
-   is in sharp contrast with encryption, where information encrypted
-   today may suffer from exposure in the future if, and when, the
-   encryption algorithm is broken.
-
-   The strongest attack known against HMAC is based on the frequency of
-   collisions for the hash function H ("birthday attack") [PV,BCK2], and
-   is totally impractical for minimally reasonable hash functions.
-
-   As an example, if we consider a hash function like MD5 where the
-   output length equals L=16 bytes (128 bits) the attacker needs to
-   acquire the correct message authentication tags computed (with the
-   _same_ secret key K!) on about 2**64 known plaintexts.  This would
-   require the processing of at least 2**64 blocks under H, an
-   impossible task in any realistic scenario (for a block length of 64
-   bytes this would take 250,000 years in a continuous 1Gbps link, and
-   without changing the secret key K during all this time).  This attack
-   could become realistic only if serious flaws in the collision
-   behavior of the function H are discovered (e.g.  collisions found
-   after 2**30 messages). Such a discovery would determine the immediate
-   replacement of the function H (the effects of such failure would be
-   far more severe for the traditional uses of H in the context of
-   digital signatures, public key certificates, etc.).
-
-   Note: this attack needs to be strongly contrasted with regular
-   collision attacks on cryptographic hash functions where no secret key
-   is involved and where 2**64 off-line parallelizable (!) operations
-   suffice to find collisions.  The latter attack is approaching
-   feasibility [VW] while the birthday attack on HMAC is totally
-   impractical.  (In the above examples, if one uses a hash function
-   with, say, 160 bit of output then 2**64 should be replaced by 2**80.)
-
-
-
-
-
-
-
-
-Krawczyk, et. al.            Informational                      [Page 6]
-
-RFC 2104                          HMAC                     February 1997
-
-
-   A correct implementation of the above construction, the choice of
-   random (or cryptographically pseudorandom) keys, a secure key
-   exchange mechanism, frequent key refreshments, and good secrecy
-   protection of keys are all essential ingredients for the security of
-   the integrity verification mechanism provided by HMAC.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Krawczyk, et. al.            Informational                      [Page 7]
-
-RFC 2104                          HMAC                     February 1997
-
-
-Appendix -- Sample Code
-
-   For the sake of illustration we provide the following sample code for
-   the implementation of HMAC-MD5 as well as some corresponding test
-   vectors (the code is based on MD5 code as described in [MD5]).
-
-/*
-** Function: hmac_md5
-*/
-
-void
-hmac_md5(text, text_len, key, key_len, digest)
-unsigned char*  text;                /* pointer to data stream */
-int             text_len;            /* length of data stream */
-unsigned char*  key;                 /* pointer to authentication key */
-int             key_len;             /* length of authentication key */
-caddr_t         digest;              /* caller digest to be filled in */
-
-{
-        MD5_CTX context;
-        unsigned char k_ipad[65];    /* inner padding -
-                                      * key XORd with ipad
-                                      */
-        unsigned char k_opad[65];    /* outer padding -
-                                      * key XORd with opad
-                                      */
-        unsigned char tk[16];
-        int i;
-        /* if key is longer than 64 bytes reset it to key=MD5(key) */
-        if (key_len > 64) {
-
-                MD5_CTX      tctx;
-
-                MD5Init(&tctx);
-                MD5Update(&tctx, key, key_len);
-                MD5Final(tk, &tctx);
-
-                key = tk;
-                key_len = 16;
-        }
-
-        /*
-         * the HMAC_MD5 transform looks like:
-         *
-         * MD5(K XOR opad, MD5(K XOR ipad, text))
-         *
-         * where K is an n byte key
-         * ipad is the byte 0x36 repeated 64 times
-
-
-
-Krawczyk, et. al.            Informational                      [Page 8]
-
-RFC 2104                          HMAC                     February 1997
-
-
-         * opad is the byte 0x5c repeated 64 times
-         * and text is the data being protected
-         */
-
-        /* start out by storing key in pads */
-        bzero( k_ipad, sizeof k_ipad);
-        bzero( k_opad, sizeof k_opad);
-        bcopy( key, k_ipad, key_len);
-        bcopy( key, k_opad, key_len);
-
-        /* XOR key with ipad and opad values */
-        for (i=0; i<64; i++) {
-                k_ipad[i] ^= 0x36;
-                k_opad[i] ^= 0x5c;
-        }
-        /*
-         * perform inner MD5
-         */
-        MD5Init(&context);                   /* init context for 1st
-                                              * pass */
-        MD5Update(&context, k_ipad, 64)      /* start with inner pad */
-        MD5Update(&context, text, text_len); /* then text of datagram */
-        MD5Final(digest, &context);          /* finish up 1st pass */
-        /*
-         * perform outer MD5
-         */
-        MD5Init(&context);                   /* init context for 2nd
-                                              * pass */
-        MD5Update(&context, k_opad, 64);     /* start with outer pad */
-        MD5Update(&context, digest, 16);     /* then results of 1st
-                                              * hash */
-        MD5Final(digest, &context);          /* finish up 2nd pass */
-}
-
-Test Vectors (Trailing '\0' of a character string not included in test):
-
-  key =         0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
-  key_len =     16 bytes
-  data =        "Hi There"
-  data_len =    8  bytes
-  digest =      0x9294727a3638bb1c13f48ef8158bfc9d
-
-  key =         "Jefe"
-  data =        "what do ya want for nothing?"
-  data_len =    28 bytes
-  digest =      0x750c783e6ab0b503eaa86e310a5db738
-
-  key =         0xAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
-
-
-
-Krawczyk, et. al.            Informational                      [Page 9]
-
-RFC 2104                          HMAC                     February 1997
-
-
-  key_len       16 bytes
-  data =        0xDDDDDDDDDDDDDDDDDDDD...
-                ..DDDDDDDDDDDDDDDDDDDD...
-                ..DDDDDDDDDDDDDDDDDDDD...
-                ..DDDDDDDDDDDDDDDDDDDD...
-                ..DDDDDDDDDDDDDDDDDDDD
-  data_len =    50 bytes
-  digest =      0x56be34521d144c88dbb8c733f0e8b3f6
-
-Acknowledgments
-
-   Pau-Chen Cheng, Jeff Kraemer, and Michael Oehler, have provided
-   useful comments on early drafts, and ran the first interoperability
-   tests of this specification. Jeff and Pau-Chen kindly provided the
-   sample code and test vectors that appear in the appendix.  Burt
-   Kaliski, Bart Preneel, Matt Robshaw, Adi Shamir, and Paul van
-   Oorschot have provided useful comments and suggestions during the
-   investigation of the HMAC construction.
-
-References
-
-   [ANSI]  ANSI X9.9, "American National Standard for Financial
-           Institution Message Authentication (Wholesale)," American
-           Bankers Association, 1981.   Revised 1986.
-
-   [Atk]   Atkinson, R., "IP Authentication Header", RFC 1826, August
-           1995.
-
-   [BCK1]  M. Bellare, R. Canetti, and H. Krawczyk,
-           "Keyed Hash Functions and Message Authentication",
-           Proceedings of Crypto'96, LNCS 1109, pp. 1-15.
-           (http://www.research.ibm.com/security/keyed-md5.html)
-
-   [BCK2]  M. Bellare, R. Canetti, and H. Krawczyk,
-           "Pseudorandom Functions Revisited: The Cascade Construction",
-           Proceedings of FOCS'96.
-
-   [Dobb]  H. Dobbertin, "The Status of MD5  After a Recent Attack",
-           RSA Labs' CryptoBytes, Vol. 2 No. 2, Summer 1996.
-           http://www.rsa.com/rsalabs/pubs/cryptobytes.html
-
-   [PV]    B. Preneel and P. van Oorschot, "Building fast MACs from hash
-           functions", Advances in Cryptology -- CRYPTO'95 Proceedings,
-           Lecture Notes in Computer Science, Springer-Verlag Vol.963,
-           1995, pp. 1-14.
-
-   [MD5]   Rivest, R., "The MD5 Message-Digest Algorithm",
-           RFC 1321, April 1992.
-
-
-
-Krawczyk, et. al.            Informational                     [Page 10]
-
-RFC 2104                          HMAC                     February 1997
-
-
-   [MM]    Meyer, S. and Matyas, S.M., Cryptography, New York Wiley,
-           1982.
-
-   [RIPEMD] H. Dobbertin, A. Bosselaers, and B. Preneel, "RIPEMD-160: A
-            strengthened version of RIPEMD", Fast Software Encryption,
-            LNCS Vol 1039, pp. 71-82.
-            ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/bosselae/ripemd/.
-
-   [SHA]   NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.
-
-   [Tsu]   G. Tsudik, "Message authentication with one-way hash
-           functions", In Proceedings of Infocom'92, May 1992.
-           (Also in "Access Control and Policy Enforcement in
-            Internetworks", Ph.D. Dissertation, Computer Science
-            Department, University of Southern California, April 1991.)
-
-   [VW]    P. van Oorschot and M. Wiener, "Parallel Collision
-           Search with Applications to Hash Functions and Discrete
-           Logarithms", Proceedings of the 2nd ACM Conf. Computer and
-           Communications Security, Fairfax, VA, November 1994.
-
-Authors' Addresses
-
-   Hugo Krawczyk
-   IBM T.J. Watson Research Center
-   P.O.Box 704
-   Yorktown Heights, NY 10598
-
-   EMail: hugo@watson.ibm.com
-
-   Mihir Bellare
-   Dept of Computer Science and Engineering
-   Mail Code 0114
-   University of California at San Diego
-   9500 Gilman Drive
-   La Jolla, CA 92093
-
-   EMail: mihir@cs.ucsd.edu
-
-   Ran Canetti
-   IBM T.J. Watson Research Center
-   P.O.Box 704
-   Yorktown Heights, NY 10598
-
-   EMail: canetti@watson.ibm.com
-
-
-
-
-
-
-Krawczyk, et. al.            Informational                     [Page 11]
-
-
diff --git a/contrib/bind9/doc/rfc/rfc2119.txt b/contrib/bind9/doc/rfc/rfc2119.txt
deleted file mode 100644
index e31fae4..0000000
--- a/contrib/bind9/doc/rfc/rfc2119.txt
+++ /dev/null
@@ -1,171 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         S. Bradner
-Request for Comments: 2119                            Harvard University
-BCP: 14                                                       March 1997
-Category: Best Current Practice
-
-
-        Key words for use in RFCs to Indicate Requirement Levels
-
-Status of this Memo
-
-   This document specifies an Internet Best Current Practices for the
-   Internet Community, and requests discussion and suggestions for
-   improvements.  Distribution of this memo is unlimited.
-
-Abstract
-
-   In many standards track documents several words are used to signify
-   the requirements in the specification.  These words are often
-   capitalized.  This document defines these words as they should be
-   interpreted in IETF documents.  Authors who follow these guidelines
-   should incorporate this phrase near the beginning of their document:
-
-      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
-      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
-      "OPTIONAL" in this document are to be interpreted as described in
-      RFC 2119.
-
-   Note that the force of these words is modified by the requirement
-   level of the document in which they are used.
-
-1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
-   definition is an absolute requirement of the specification.
-
-2. MUST NOT   This phrase, or the phrase "SHALL NOT", mean that the
-   definition is an absolute prohibition of the specification.
-
-3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
-   may exist valid reasons in particular circumstances to ignore a
-   particular item, but the full implications must be understood and
-   carefully weighed before choosing a different course.
-
-4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
-   there may exist valid reasons in particular circumstances when the
-   particular behavior is acceptable or even useful, but the full
-   implications should be understood and the case carefully weighed
-   before implementing any behavior described with this label.
-
-
-
-
-
-Bradner                  Best Current Practice                  [Page 1]
-
-RFC 2119                     RFC Key Words                    March 1997
-
-
-5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
-   truly optional.  One vendor may choose to include the item because a
-   particular marketplace requires it or because the vendor feels that
-   it enhances the product while another vendor may omit the same item.
-   An implementation which does not include a particular option MUST be
-   prepared to interoperate with another implementation which does
-   include the option, though perhaps with reduced functionality. In the
-   same vein an implementation which does include a particular option
-   MUST be prepared to interoperate with another implementation which
-   does not include the option (except, of course, for the feature the
-   option provides.)
-
-6. Guidance in the use of these Imperatives
-
-   Imperatives of the type defined in this memo must be used with care
-   and sparingly.  In particular, they MUST only be used where it is
-   actually required for interoperation or to limit behavior which has
-   potential for causing harm (e.g., limiting retransmisssions)  For
-   example, they must not be used to try to impose a particular method
-   on implementors where the method is not required for
-   interoperability.
-
-7. Security Considerations
-
-   These terms are frequently used to specify behavior with security
-   implications.  The effects on security of not implementing a MUST or
-   SHOULD, or doing something the specification says MUST NOT or SHOULD
-   NOT be done may be very subtle. Document authors should take the time
-   to elaborate the security implications of not following
-   recommendations or requirements as most implementors will not have
-   had the benefit of the experience and discussion that produced the
-   specification.
-
-8. Acknowledgments
-
-   The definitions of these terms are an amalgam of definitions taken
-   from a number of RFCs.  In addition, suggestions have been
-   incorporated from a number of people including Robert Ullmann, Thomas
-   Narten, Neal McBurnett, and Robert Elz.
-
-
-
-
-
-
-
-
-
-
-
-
-Bradner                  Best Current Practice                  [Page 2]
-
-RFC 2119                     RFC Key Words                    March 1997
-
-
-9. Author's Address
-
-      Scott Bradner
-      Harvard University
-      1350 Mass. Ave.
-      Cambridge, MA 02138
-
-      phone - +1 617 495 3864
-
-      email - sob@harvard.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bradner                  Best Current Practice                  [Page 3]
-
diff --git a/contrib/bind9/doc/rfc/rfc2133.txt b/contrib/bind9/doc/rfc/rfc2133.txt
deleted file mode 100644
index ea66cf0..0000000
--- a/contrib/bind9/doc/rfc/rfc2133.txt
+++ /dev/null
@@ -1,1795 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        R. Gilligan
-Request for Comments: 2133                                      Freegate
-Category: Informational                                       S. Thomson
-                                                                Bellcore
-                                                                J. Bound
-                                                                 Digital
-                                                              W. Stevens
-                                                              Consultant
-                                                              April 1997
-
-               Basic Socket Interface Extensions for IPv6
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  This memo
-   does not specify an Internet standard of any kind.  Distribution of
-   this memo is unlimited.
-
-Abstract
-
-   The de facto standard application program interface (API) for TCP/IP
-   applications is the "sockets" interface.  Although this API was
-   developed for Unix in the early 1980s it has also been implemented on
-   a wide variety of non-Unix systems.  TCP/IP applications written
-   using the sockets API have in the past enjoyed a high degree of
-   portability and we would like the same portability with IPv6
-   applications.  But changes are required to the sockets API to support
-   IPv6 and this memo describes these changes.  These include a new
-   socket address structure to carry IPv6 addresses, new address
-   conversion functions, and some new socket options.  These extensions
-   are designed to provide access to the basic IPv6 features required by
-   TCP and UDP applications, including multicasting, while introducing a
-   minimum of change into the system and providing complete
-   compatibility for existing IPv4 applications.  Additional extensions
-   for advanced IPv6 features (raw sockets and access to the IPv6
-   extension headers) are defined in another document [5].
-
-Table of Contents
-
-   1.  Introduction ................................................  2
-   2.  Design Considerations .......................................  3
-   2.1.  What Needs to be Changed ..................................  3
-   2.2.  Data Types ................................................  5
-   2.3.  Headers ...................................................  5
-   2.4.  Structures ................................................  5
-   3.  Socket Interface ............................................  5
-   3.1.  IPv6 Address Family and Protocol Family ...................  5
-   3.2.  IPv6 Address Structure ....................................  6
-
-
-
-Gilligan, et. al.            Informational                      [Page 1]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   3.3.  Socket Address Structure for 4.3BSD-Based Systems .........  6
-   3.4.  Socket Address Structure for 4.4BSD-Based Systems .........  7
-   3.5.  The Socket Functions ......................................  8
-   3.6.  Compatibility with IPv4 Applications ......................  9
-   3.7.  Compatibility with IPv4 Nodes .............................  9
-   3.8.  IPv6 Wildcard Address ..................................... 10
-   3.9.  IPv6 Loopback Address ..................................... 11
-   4.  Interface Identification .................................... 12
-   4.1.  Name-to-Index ............................................. 13
-   4.2.  Index-to-Name ............................................. 13
-   4.3.  Return All Interface Names and Indexes .................... 14
-   4.4.  Free Memory ............................................... 14
-   5.  Socket Options .............................................. 14
-   5.1.  Changing Socket Type ...................................... 15
-   5.2.  Unicast Hop Limit ......................................... 16
-   5.3.  Sending and Receiving Multicast Packets ................... 17
-   6.  Library Functions ........................................... 19
-   6.1.  Hostname-to-Address Translation ........................... 19
-   6.2.  Address To Hostname Translation ........................... 22
-   6.3.  Protocol-Independent Hostname and Service Name Translation  22
-   6.4.  Socket Address Structure to Hostname and Service Name ..... 25
-   6.5.  Address Conversion Functions .............................. 27
-   6.6.  Address Testing Macros .................................... 28
-   7.  Summary of New Definitions .................................. 29
-   8.  Security Considerations ..................................... 31
-   9.  Acknowledgments ............................................. 31
-   10.  References ................................................. 31
-   11.  Authors' Addresses ......................................... 32
-
-1.  Introduction
-
-   While IPv4 addresses are 32 bits long, IPv6 interfaces are identified
-   by 128-bit addresses.  The socket interface make the size of an IP
-   address quite visible to an application; virtually all TCP/IP
-   applications for BSD-based systems have knowledge of the size of an
-   IP address.  Those parts of the API that expose the addresses must be
-   changed to accommodate the larger IPv6 address size.  IPv6 also
-   introduces new features (e.g., flow label and priority), some of
-   which must be made visible to applications via the API.  This memo
-   defines a set of extensions to the socket interface to support the
-   larger address size and new features of IPv6.
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                      [Page 2]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-2.  Design Considerations
-
-   There are a number of important considerations in designing changes
-   to this well-worn API:
-
-   -  The API changes should provide both source and binary
-       compatibility for programs written to the original API.  That is,
-       existing program binaries should continue to operate when run on
-       a system supporting the new API.  In addition, existing
-       applications that are re-compiled and run on a system supporting
-       the new API should continue to operate.  Simply put, the API
-       changes for IPv6 should not break existing programs.
-
-   -  The changes to the API should be as small as possible in order to
-       simplify the task of converting existing IPv4 applications to
-       IPv6.
-
-   -  Where possible, applications should be able to use this API to
-       interoperate with both IPv6 and IPv4 hosts.  Applications should
-       not need to know which type of host they are communicating with.
-
-   -  IPv6 addresses carried in data structures should be 64-bit
-       aligned.  This is necessary in order to obtain optimum
-       performance on 64-bit machine architectures.
-
-   Because of the importance of providing IPv4 compatibility in the API,
-   these extensions are explicitly designed to operate on machines that
-   provide complete support for both IPv4 and IPv6.  A subset of this
-   API could probably be designed for operation on systems that support
-   only IPv6.  However, this is not addressed in this memo.
-
-2.1.  What Needs to be Changed
-
-   The socket interface API consists of a few distinct components:
-
-    -  Core socket functions.
-
-    -  Address data structures.
-
-    -  Name-to-address translation functions.
-
-    -  Address conversion functions.
-
-    The core socket functions -- those functions that deal with such
-    things as setting up and tearing down TCP connections, and sending
-    and receiving UDP packets -- were designed to be transport
-    independent.  Where protocol addresses are passed as function
-    arguments, they are carried via opaque pointers.  A protocol-specific
-
-
-
-Gilligan, et. al.            Informational                      [Page 3]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-    address data structure is defined for each protocol that the socket
-    functions support.  Applications must cast pointers to these
-    protocol-specific address structures into pointers to the generic
-    "sockaddr" address structure when using the socket functions.  These
-    functions need not change for IPv6, but a new IPv6-specific address
-    data structure is needed.
-
-    The "sockaddr_in" structure is the protocol-specific data structure
-    for IPv4.  This data structure actually includes 8-octets of unused
-    space, and it is tempting to try to use this space to adapt the
-    sockaddr_in structure to IPv6.  Unfortunately, the sockaddr_in
-    structure is not large enough to hold the 16-octet IPv6 address as
-    well as the other information (address family and port number) that
-    is needed.  So a new address data structure must be defined for IPv6.
-
-    The name-to-address translation functions in the socket interface are
-    gethostbyname() and gethostbyaddr().  These must be modified to
-    support IPv6 and the semantics defined must provide 100% backward
-    compatibility for all existing IPv4 applications, along with IPv6
-    support for new applications.  Additionally, the POSIX 1003.g work in
-    progress [4] specifies a new hostname-to-address translation function
-    which is protocol independent.  This function can also be used with
-    IPv6.
-
-    The address conversion functions -- inet_ntoa() and inet_addr() --
-    convert IPv4 addresses between binary and printable form.  These
-    functions are quite specific to 32-bit IPv4 addresses.  We have
-    designed two analogous functions that convert both IPv4 and IPv6
-    addresses, and carry an address type parameter so that they can be
-    extended to other protocol families as well.
-
-    Finally, a few miscellaneous features are needed to support IPv6.
-    New interfaces are needed to support the IPv6 flow label, priority,
-    and hop limit header fields.  New socket options are needed to
-    control the sending and receiving of IPv6 multicast packets.
-
-    The socket interface will be enhanced in the future to provide access
-    to other IPv6 features.  These extensions are described in [5].
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                      [Page 4]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-2.2.  Data Types
-
-   The data types of the structure elements given in this memo are
-   intended to be examples, not absolute requirements.  Whenever
-   possible, POSIX 1003.1g data types are used:  u_intN_t means an
-   unsigned integer of exactly N bits (e.g., u_int16_t) and u_intNm_t
-   means an unsigned integer of at least N bits (e.g., u_int32m_t).  We
-   also assume the argument data types from 1003.1g when possible (e.g.,
-    the final argument to setsockopt() is a size_t value).  Whenever
-   buffer sizes are specified, the POSIX 1003.1 size_t data type is used
-   (e.g., the two length arguments to getnameinfo()).
-
-2.3.  Headers
-
-   When function prototypes and structures are shown we show the headers
-   that must be #included to cause that item to be defined.
-
-2.4.  Structures
-
-   When structures are described the members shown are the ones that
-   must appear in an implementation.  Additional, nonstandard members
-   may also be defined by an implementation.
-
-   The ordering shown for the members of a structure is the recommended
-   ordering, given alignment considerations of multibyte members, but an
-   implementation may order the members differently.
-
-3.  Socket Interface
-
-   This section specifies the socket interface changes for IPv6.
-
-3.1.  IPv6 Address Family and Protocol Family
-
-   A new address family name, AF_INET6, is defined in <sys/socket.h>.
-   The AF_INET6 definition distinguishes between the original
-   sockaddr_in address data structure, and the new sockaddr_in6 data
-   structure.
-
-   A new protocol family name, PF_INET6, is defined in <sys/socket.h>.
-   Like most of the other protocol family names, this will usually be
-   defined to have the same value as the corresponding address family
-   name:
-
-       #define PF_INET6        AF_INET6
-
-   The PF_INET6 is used in the first argument to the socket() function
-   to indicate that an IPv6 socket is being created.
-
-
-
-
-Gilligan, et. al.            Informational                      [Page 5]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-3.2.  IPv6 Address Structure
-
-   A new data structure to hold a single IPv6 address is defined as
-    follows:
-
-       #include <netinet/in.h>
-
-       struct in6_addr {
-           u_int8_t  s6_addr[16];      /* IPv6 address */
-       }
-
-   This data structure contains an array of sixteen 8-bit elements,
-   which make up one 128-bit IPv6 address.  The IPv6 address is stored
-   in network byte order.
-
-3.3.  Socket Address Structure for 4.3BSD-Based Systems
-
-   In the socket interface, a different protocol-specific data structure
-   is defined to carry the addresses for each protocol suite.  Each
-   protocol-specific data structure is designed so it can be cast into a
-   protocol-independent data structure -- the "sockaddr" structure.
-   Each has a "family" field that overlays the "sa_family" of the
-   sockaddr data structure.  This field identifies the type of the data
-   structure.
-
-   The sockaddr_in structure is the protocol-specific address data
-   structure for IPv4.  It is used to pass addresses between
-   applications and the system in the socket functions.  The following
-   structure is defined to carry IPv6 addresses:
-
-       #include <netinet/in.h>
-
-       struct sockaddr_in6 {
-           u_int16m_t      sin6_family;    /* AF_INET6 */
-           u_int16m_t      sin6_port;      /* transport layer port # */
-           u_int32m_t      sin6_flowinfo;  /* IPv6 flow information */
-           struct in6_addr sin6_addr;      /* IPv6 address */
-       };
-
-   This structure is designed to be compatible with the sockaddr data
-   structure used in the 4.3BSD release.
-
-   The sin6_family field identifies this as a sockaddr_in6 structure.
-   This field overlays the sa_family field when the buffer is cast to a
-   sockaddr data structure.  The value of this field must be AF_INET6.
-
-
-
-
-
-
-Gilligan, et. al.            Informational                      [Page 6]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   The sin6_port field contains the 16-bit UDP or TCP port number.  This
-   field is used in the same way as the sin_port field of the
-   sockaddr_in structure.  The port number is stored in network byte
-   order.
-
-   The sin6_flowinfo field is a 32-bit field that contains two pieces of
-   information: the 24-bit IPv6 flow label and the 4-bit priority field.
-   The contents and interpretation of this member is unspecified at this
-   time.
-
-   The sin6_addr field is a single in6_addr structure (defined in the
-   previous section).  This field holds one 128-bit IPv6 address.  The
-   address is stored in network byte order.
-
-   The ordering of elements in this structure is specifically designed
-   so that the sin6_addr field will be aligned on a 64-bit boundary.
-   This is done for optimum performance on 64-bit architectures.
-
-   Notice that the sockaddr_in6 structure will normally be larger than
-   the generic sockaddr structure.  On many existing implementations the
-   sizeof(struct sockaddr_in) equals sizeof(struct sockaddr), with both
-   being 16 bytes.  Any existing code that makes this assumption needs
-   to be examined carefully when converting to IPv6.
-
-3.4.  Socket Address Structure for 4.4BSD-Based Systems
-
-   The 4.4BSD release includes a small, but incompatible change to the
-   socket interface.  The "sa_family" field of the sockaddr data
-   structure was changed from a 16-bit value to an 8-bit value, and the
-   space saved used to hold a length field, named "sa_len".  The
-   sockaddr_in6 data structure given in the previous section cannot be
-   correctly cast into the newer sockaddr data structure.  For this
-   reason, the following alternative IPv6 address data structure is
-   provided to be used on systems based on 4.4BSD:
-
-       #include <netinet/in.h>
-
-       #define SIN6_LEN
-
-       struct sockaddr_in6 {
-           u_char          sin6_len;       /* length of this struct */
-           u_char          sin6_family;    /* AF_INET6 */
-           u_int16m_t      sin6_port;      /* transport layer port # */
-           u_int32m_t      sin6_flowinfo;  /* IPv6 flow information */
-           struct in6_addr sin6_addr;      /* IPv6 address */
-       };
-
-
-
-
-
-Gilligan, et. al.            Informational                      [Page 7]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   The only differences between this data structure and the 4.3BSD
-   variant are the inclusion of the length field, and the change of the
-   family field to a 8-bit data type.  The definitions of all the other
-   fields are identical to the structure defined in the previous
-   section.
-
-   Systems that provide this version of the sockaddr_in6 data structure
-   must also declare SIN6_LEN as a result of including the
-   <netinet/in.h> header.  This macro allows applications to determine
-   whether they are being built on a system that supports the 4.3BSD or
-   4.4BSD variants of the data structure.
-
-3.5.  The Socket Functions
-
-   Applications call the socket() function to create a socket descriptor
-   that represents a communication endpoint.  The arguments to the
-   socket() function tell the system which protocol to use, and what
-   format address structure will be used in subsequent functions.  For
-   example, to create an IPv4/TCP socket, applications make the call:
-
-       s = socket(PF_INET, SOCK_STREAM, 0);
-
-   To create an IPv4/UDP socket, applications make the call:
-
-       s = socket(PF_INET, SOCK_DGRAM, 0);
-
-   Applications may create IPv6/TCP and IPv6/UDP sockets by simply using
-   the constant PF_INET6 instead of PF_INET in the first argument.  For
-   example, to create an IPv6/TCP socket, applications make the call:
-
-       s = socket(PF_INET6, SOCK_STREAM, 0);
-
-   To create an IPv6/UDP socket, applications make the call:
-
-       s = socket(PF_INET6, SOCK_DGRAM, 0);
-
-   Once the application has created a PF_INET6 socket, it must use the
-   sockaddr_in6 address structure when passing addresses in to the
-   system.  The functions that the application uses to pass addresses
-   into the system are:
-
-       bind()
-       connect()
-       sendmsg()
-       sendto()
-
-
-
-
-
-
-Gilligan, et. al.            Informational                      [Page 8]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   The system will use the sockaddr_in6 address structure to return
-   addresses to applications that are using PF_INET6 sockets.  The
-   functions that return an address from the system to an application
-   are:
-
-          accept()
-          recvfrom()
-          recvmsg()
-          getpeername()
-          getsockname()
-
-   No changes to the syntax of the socket functions are needed to
-   support IPv6, since all of the "address carrying" functions use an
-   opaque address pointer, and carry an address length as a function
-   argument.
-
-3.6.  Compatibility with IPv4 Applications
-
-   In order to support the large base of applications using the original
-   API, system implementations must provide complete source and binary
-   compatibility with the original API.  This means that systems must
-   continue to support PF_INET sockets and the sockaddr_in address
-   structure.  Applications must be able to create IPv4/TCP and IPv4/UDP
-   sockets using the PF_INET constant in the socket() function, as
-   described in the previous section.  Applications should be able to
-   hold a combination of IPv4/TCP, IPv4/UDP, IPv6/TCP and IPv6/UDP
-   sockets simultaneously within the same process.
-
-   Applications using the original API should continue to operate as
-   they did on systems supporting only IPv4.  That is, they should
-   continue to interoperate with IPv4 nodes.
-
-3.7.  Compatibility with IPv4 Nodes
-
-   The API also provides a different type of compatibility: the ability
-   for IPv6 applications to interoperate with IPv4 applications.  This
-   feature uses the IPv4-mapped IPv6 address format defined in the IPv6
-   addressing architecture specification [2].  This address format
-   allows the IPv4 address of an IPv4 node to be represented as an IPv6
-   address.  The IPv4 address is encoded into the low-order 32 bits of
-   the IPv6 address, and the high-order 96 bits hold the fixed prefix
-   0:0:0:0:0:FFFF.  IPv4-mapped addresses are written as follows:
-
-       ::FFFF:<IPv4-address>
-
-   These addresses are often generated automatically by the
-   gethostbyname() function when the specified host has only IPv4
-   addresses (as described in Section 6.1).
-
-
-
-Gilligan, et. al.            Informational                      [Page 9]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   Applications may use PF_INET6 sockets to open TCP connections to IPv4
-   nodes, or send UDP packets to IPv4 nodes, by simply encoding the
-   destination's IPv4 address as an IPv4-mapped IPv6 address, and
-   passing that address, within a sockaddr_in6 structure, in the
-   connect() or sendto() call.  When applications use PF_INET6 sockets
-   to accept TCP connections from IPv4 nodes, or receive UDP packets
-   from IPv4 nodes, the system returns the peer's address to the
-   application in the accept(), recvfrom(), or getpeername() call using
-   a sockaddr_in6 structure encoded this way.
-
-   Few applications will likely need to know which type of node they are
-   interoperating with.  However, for those applications that do need to
-   know, the IN6_IS_ADDR_V4MAPPED() macro, defined in Section 6.6, is
-   provided.
-
-3.8.  IPv6 Wildcard Address
-
-   While the bind() function allows applications to select the source IP
-   address of UDP packets and TCP connections, applications often want
-   the system to select the source address for them.  With IPv4, one
-   specifies the address as the symbolic constant INADDR_ANY (called the
-   "wildcard" address) in the bind() call, or simply omits the bind()
-   entirely.
-
-   Since the IPv6 address type is a structure (struct in6_addr), a
-   symbolic constant can be used to initialize an IPv6 address variable,
-   but cannot be used in an assignment.  Therefore systems provide the
-   IPv6 wildcard address in two forms.
-
-   The first version is a global variable named "in6addr_any" that is an
-   in6_addr structure.  The extern declaration for this variable is
-   defined in <netinet/in.h>:
-
-       extern const struct in6_addr in6addr_any;
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 10]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   Applications use in6addr_any similarly to the way they use INADDR_ANY
-   in IPv4.  For example, to bind a socket to port number 23, but let
-   the system select the source address, an application could use the
-   following code:
-
-       struct sockaddr_in6 sin6;
-        . . .
-       sin6.sin6_family = AF_INET6;
-       sin6.sin6_flowinfo = 0;
-       sin6.sin6_port = htons(23);
-       sin6.sin6_addr = in6addr_any;  /* structure assignment */
-        . . .
-       if (bind(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
-               . . .
-
-   The other version is a symbolic constant named IN6ADDR_ANY_INIT and
-   is defined in <netinet/in.h>.  This constant can be used to
-   initialize an in6_addr structure:
-
-       struct in6_addr anyaddr = IN6ADDR_ANY_INIT;
-
-   Note that this constant can be used ONLY at declaration time.  It can
-   not be used to assign a previously declared in6_addr structure.  For
-   example, the following code will not work:
-
-       /* This is the WRONG way to assign an unspecified address */
-       struct sockaddr_in6 sin6;
-        . . .
-       sin6.sin6_addr = IN6ADDR_ANY_INIT; /* will NOT compile */
-
-   Be aware that the IPv4 INADDR_xxx constants are all defined in host
-   byte order but the IPv6 IN6ADDR_xxx constants and the IPv6
-   in6addr_xxx externals are defined in network byte order.
-
-3.9.  IPv6 Loopback Address
-
-   Applications may need to send UDP packets to, or originate TCP
-   connections to, services residing on the local node.  In IPv4, they
-   can do this by using the constant IPv4 address INADDR_LOOPBACK in
-   their connect(), sendto(), or sendmsg() call.
-
-   IPv6 also provides a loopback address to contact local TCP and UDP
-   services.  Like the unspecified address, the IPv6 loopback address is
-   provided in two forms -- a global variable and a symbolic constant.
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 11]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   The global variable is an in6_addr structure named
-   "in6addr_loopback."  The extern declaration for this variable is
-   defined in <netinet/in.h>:
-
-       extern const struct in6_addr in6addr_loopback;
-
-   Applications use in6addr_loopback as they would use INADDR_LOOPBACK
-   in IPv4 applications (but beware of the byte ordering difference
-   mentioned at the end of the previous section).  For example, to open
-   a TCP connection to the local telnet server, an application could use
-   the following code:
-
-       struct sockaddr_in6 sin6;
-        . . .
-       sin6.sin6_family = AF_INET6;
-       sin6.sin6_flowinfo = 0;
-       sin6.sin6_port = htons(23);
-       sin6.sin6_addr = in6addr_loopback;  /* structure assignment */
-        . . .
-       if (connect(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
-               . . .
-
-   The symbolic constant is named IN6ADDR_LOOPBACK_INIT and is defined
-   in <netinet/in.h>.  It can be used at declaration time ONLY; for
-   example:
-
-       struct in6_addr loopbackaddr = IN6ADDR_LOOPBACK_INIT;
-
-   Like IN6ADDR_ANY_INIT, this constant cannot be used in an assignment
-   to a previously declared IPv6 address variable.
-
-4.  Interface Identification
-
-   This API uses an interface index (a small positive integer) to
-   identify the local interface on which a multicast group is joined
-   (Section 5.3).  Additionally, the advanced API [5] uses these same
-   interface indexes to identify the interface on which a datagram is
-   received, or to specify the interface on which a datagram is to be
-   sent.
-
-   Interfaces are normally known by names such as "le0", "sl1", "ppp2",
-   and the like.  On Berkeley-derived implementations, when an interface
-   is made known to the system, the kernel assigns a unique positive
-   integer value (called the interface index) to that interface.  These
-   are small positive integers that start at 1.  (Note that 0 is never
-   used for an interface index.)  There may be gaps so that there is no
-   current interface for a particular positive interface index.
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 12]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   This API defines two functions that map between an interface name and
-   index, a third function that returns all the interface names and
-   indexes, and a fourth function to return the dynamic memory allocated
-   by the previous function.  How these functions are implemented is
-   left up to the implementation.  4.4BSD implementations can implement
-   these functions using the existing sysctl() function with the
-   NET_RT_LIST command.  Other implementations may wish to use ioctl()
-   for this purpose.
-
-4.1.  Name-to-Index
-
-   The first function maps an interface name into its corresponding
-   index.
-
-       #include <net/if.h>
-
-       unsigned int  if_nametoindex(const char *ifname);
-
-   If the specified interface does not exist, the return value is 0.
-
-4.2.  Index-to-Name
-
-   The second function maps an interface index into its corresponding
-   name.
-
-       #include <net/if.h>
-
-       char  *if_indextoname(unsigned int ifindex, char *ifname);
-
-   The ifname argument must point to a buffer of at least IFNAMSIZ bytes
-   into which the interface name corresponding to the specified index is
-   returned.  (IFNAMSIZ is also defined in <net/if.h> and its value
-   includes a terminating null byte at the end of the interface name.)
-   This pointer is also the return value of the function.  If there is
-   no interface corresponding to the specified index, NULL is returned.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 13]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-4.3.  Return All Interface Names and Indexes
-
-   The final function returns an array of if_nameindex structures, one
-   structure per interface.
-
-       #include <net/if.h>
-
-       struct if_nameindex {
-         unsigned int   if_index;  /* 1, 2, ... */
-         char          *if_name;   /* null terminated name: "le0", ... */
-       };
-
-       struct if_nameindex  *if_nameindex(void);
-
-   The end of the array of structures is indicated by a structure with
-   an if_index of 0 and an if_name of NULL.  The function returns a NULL
-   pointer upon an error.
-
-   The memory used for this array of structures along with the interface
-   names pointed to by the if_name members is obtained dynamically.
-   This memory is freed by the next function.
-
-4.4.  Free Memory
-
-   The following function frees the dynamic memory that was allocated by
-   if_nameindex().
-
-       #include <net/if.h>
-
-       void  if_freenameindex(struct if_nameindex *ptr);
-
-   The argument to this function must be a pointer that was returned by
-   if_nameindex().
-
-5.  Socket Options
-
-   A number of new socket options are defined for IPv6.  All of these
-   new options are at the IPPROTO_IPV6 level.  That is, the "level"
-   parameter in the getsockopt() and setsockopt() calls is IPPROTO_IPV6
-   when using these options.  The constant name prefix IPV6_ is used in
-   all of the new socket options.  This serves to clearly identify these
-   options as applying to IPv6.
-
-   The declaration for IPPROTO_IPV6, the new IPv6 socket options, and
-   related constants defined in this section are obtained by including
-   the header <netinet/in.h>.
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 14]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-5.1.  Changing Socket Type
-
-   Unix allows open sockets to be passed between processes via the
-   exec() call and other means.  It is a relatively common application
-   practice to pass open sockets across exec() calls.  Thus it is
-   possible for an application using the original API to pass an open
-   PF_INET socket to an application that is expecting to receive a
-   PF_INET6 socket.  Similarly, it is possible for an application using
-   the extended API to pass an open PF_INET6 socket to an application
-   using the original API, which would be equipped only to deal with
-   PF_INET sockets.  Either of these cases could cause problems, because
-   the application that is passed the open socket might not know how to
-   decode the address structures returned in subsequent socket
-   functions.
-
-   To remedy this problem, a new setsockopt() option is defined that
-   allows an application to "convert" a PF_INET6 socket into a PF_INET
-   socket and vice versa.
-
-   An IPv6 application that is passed an open socket from an unknown
-   process may use the IPV6_ADDRFORM setsockopt() option to "convert"
-   the socket to PF_INET6.  Once that has been done, the system will
-   return sockaddr_in6 address structures in subsequent socket
-   functions.
-
-   An IPv6 application that is about to pass an open PF_INET6 socket to
-   a program that is not be IPv6 capable can "downgrade" the socket to
-   PF_INET before calling exec().  After that, the system will return
-   sockaddr_in address structures to the application that was exec()'ed.
-   Be aware that you cannot downgrade an IPv6 socket to an IPv4 socket
-   unless all nonwildcard addresses already associated with the IPv6
-   socket are IPv4-mapped IPv6 addresses.
-
-   The IPV6_ADDRFORM option is valid at both the IPPROTO_IP and
-   IPPROTO_IPV6 levels.  The only valid option values are PF_INET6 and
-   PF_INET.  For example, to convert a PF_INET6 socket to PF_INET, a
-   program would call:
-
-       int  addrform = PF_INET;
-
-       if (setsockopt(s, IPPROTO_IPV6, IPV6_ADDRFORM,
-                      (char *) &addrform, sizeof(addrform)) == -1)
-           perror("setsockopt IPV6_ADDRFORM");
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 15]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   An application may use IPV6_ADDRFORM with getsockopt() to learn
-   whether an open socket is a PF_INET of PF_INET6 socket.  For example:
-
-       int  addrform;
-       size_t  len = sizeof(addrform);
-
-       if (getsockopt(s, IPPROTO_IPV6, IPV6_ADDRFORM,
-                      (char *) &addrform, &len) == -1)
-           perror("getsockopt IPV6_ADDRFORM");
-       else if (addrform == PF_INET)
-           printf("This is an IPv4 socket.\n");
-       else if (addrform == PF_INET6)
-           printf("This is an IPv6 socket.\n");
-       else
-           printf("This system is broken.\n");
-
-5.2.  Unicast Hop Limit
-
-   A new setsockopt() option controls the hop limit used in outgoing
-   unicast IPv6 packets.  The name of this option is IPV6_UNICAST_HOPS,
-   and it is used at the IPPROTO_IPV6 layer.  The following example
-   illustrates how it is used:
-
-       int  hoplimit = 10;
-
-       if (setsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
-                      (char *) &hoplimit, sizeof(hoplimit)) == -1)
-           perror("setsockopt IPV6_UNICAST_HOPS");
-
-   When the IPV6_UNICAST_HOPS option is set with setsockopt(), the
-   option value given is used as the hop limit for all subsequent
-   unicast packets sent via that socket.  If the option is not set, the
-   system selects a default value.  The integer hop limit value (called
-   x) is interpreted as follows:
-
-       x < -1:        return an error of EINVAL
-       x == -1:       use kernel default
-       0 <= x <= 255: use x
-       x >= 256:      return an error of EINVAL
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 16]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   The IPV6_UNICAST_HOPS option may be used with getsockopt() to
-   determine the hop limit value that the system will use for subsequent
-   unicast packets sent via that socket.  For example:
-
-       int  hoplimit;
-       size_t  len = sizeof(hoplimit);
-
-       if (getsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
-                      (char *) &hoplimit, &len) == -1)
-           perror("getsockopt IPV6_UNICAST_HOPS");
-       else
-           printf("Using %d for hop limit.\n", hoplimit);
-
-5.3.  Sending and Receiving Multicast Packets
-
-   IPv6 applications may send UDP multicast packets by simply specifying
-   an IPv6 multicast address in the address argument of the sendto()
-   function.
-
-   Three socket options at the IPPROTO_IPV6 layer control some of the
-   parameters for sending multicast packets.  Setting these options is
-   not required:  applications may send multicast packets without using
-   these options.  The setsockopt() options for controlling the sending
-   of multicast packets are summarized below:
-
-       IPV6_MULTICAST_IF
-
-           Set the interface to use for outgoing multicast packets.  The
-           argument is the index of the interface to use.
-
-           Argument type: unsigned int
-
-       IPV6_MULTICAST_HOPS
-
-           Set the hop limit to use for outgoing multicast packets.
-           (Note a separate option - IPV6_UNICAST_HOPS - is provided to
-           set the hop limit to use for outgoing unicast packets.)  The
-           interpretation of the argument is the same as for the
-           IPV6_UNICAST_HOPS option:
-
-               x < -1:        return an error of EINVAL
-               x == -1:       use kernel default
-               0 <= x <= 255: use x
-               x >= 256:      return an error of EINVAL
-
-           Argument type: int
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 17]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-       IPV6_MULTICAST_LOOP
-
-           Controls whether outgoing multicast packets  sent  should  be
-           delivered  back  to the local application.  A toggle.  If the
-           option is set to 1, multicast packets are looped back.  If it
-           is set to 0, they are not.
-
-           Argument type: unsigned int
-
-   The reception of multicast packets is controlled by the two
-   setsockopt() options summarized below:
-
-       IPV6_ADD_MEMBERSHIP
-
-           Join a multicast group on a specified local interface.  If
-           the interface index is specified as 0, the kernel chooses the
-           local interface.  For example, some kernels look up the
-           multicast group in the normal IPv6 routing table and using
-           the resulting interface.
-
-           Argument type: struct ipv6_mreq
-
-       IPV6_DROP_MEMBERSHIP
-
-           Leave a multicast group on a specified interface.
-
-           Argument type: struct ipv6_mreq
-
-   The argument type of both of these options is the ipv6_mreq
-   structure, defined as:
-
-       #include <netinet/in.h>
-
-       struct ipv6_mreq {
-           struct in6_addr ipv6mr_multiaddr; /* IPv6 multicast addr */
-           unsigned int    ipv6mr_interface; /* interface index */
-       };
-
-   Note that to receive multicast datagrams a process must join the
-   multicast group and bind the UDP port to which datagrams will be
-   sent.  Some processes also bind the multicast group address to the
-   socket, in addition to the port, to prevent other datagrams destined
-   to that same port from being delivered to the socket.
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 18]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-6.  Library Functions
-
-   New library functions are needed to perform a variety of operations
-   with IPv6 addresses.  Functions are needed to lookup IPv6 addresses
-   in the Domain Name System (DNS).  Both forward lookup (hostname-to-
-   address translation) and reverse lookup (address-to-hostname
-   translation) need to be supported.  Functions are also needed to
-   convert IPv6 addresses between their binary and textual form.
-
-6.1.  Hostname-to-Address Translation
-
-   The commonly used function gethostbyname() remains unchanged as does
-   the hostent structure to which it returns a pointer.  Existing
-   applications that call this function continue to receive only IPv4
-   addresses that are the result of a query in the DNS for A records.
-   (We assume the DNS is being used; some environments may be using a
-   hosts file or some other name resolution system, either of which may
-   impede renumbering.  We also assume that the RES_USE_INET6 resolver
-   option is not set, which we describe in more detail shortly.)
-
-   Two new changes are made to support IPv6 addresses.  First, the
-   following function is new:
-
-       #include <sys/socket.h>
-       #include <netdb.h>
-
-       struct hostent *gethostbyname2(const char *name, int af);
-
-   The af argument specifies the address family.  The default operation
-   of this function is simple:
-
-    -  If the af argument is AF_INET, then a query is made for A
-       records.  If successful, IPv4 addresses are returned and the
-       h_length member of the hostent structure will be 4, else the
-       function returns a NULL pointer.
-
-    -  If the af argument is AF_INET6, then a query is made for AAAA
-       records.  If successful, IPv6 addresses are returned and the
-       h_length member of the hostent structure will be 16, else the
-       function returns a NULL pointer.
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 19]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   The second change, that provides additional functionality, is a new
-   resolver option RES_USE_INET6, which is defined as a result of
-   including the <resolv.h> header.  (This option is provided starting
-   with the BIND 4.9.4 release.)  There are three ways to set this
-   option.
-
-    -  The first way is
-
-           res_init();
-           _res.options |= RES_USE_INET6;
-
-       and then call either gethostbyname() or gethostbyname2().  This
-       option then affects only the process that is calling the
-       resolver.
-
-    -  The second way to set this option is to set the environment
-       variable RES_OPTIONS, as in RES_OPTIONS=inet6.  (This example is
-       for the Bourne and Korn shells.)  This method affects any
-       processes that see this environment variable.
-
-    -  The third way is to set this option in the resolver configuration
-       file (normally /etc/resolv.conf) and the option then affects all
-       applications on the host.  This final method should not be done
-       until all applications on the host are capable of dealing with
-       IPv6 addresses.
-
-   There is no priority among these three methods.  When the
-   RES_USE_INET6 option is set, two changes occur:
-
-    -  gethostbyname(host) first calls gethostbyname2(host, AF_INET6)
-       looking for AAAA records, and if this fails it then calls
-       gethostbyname2(host, AF_INET) looking for A records.
-
-    -  gethostbyname2(host, AF_INET) always returns IPv4-mapped IPv6
-       addresses with the h_length member of the hostent structure set
-       to 16.
-
-   An application must not enable the RES_USE_INET6 option until it is
-   prepared to deal with 16-byte addresses in the returned hostent
-   structure.
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 20]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   The following table summarizes the operation of the existing
-   gethostbyname() function, the new function gethostbyname2(), along
-   with the new resolver option RES_USE_INET6.
-
-+------------------+---------------------------------------------------+
-|                  |              RES_USE_INET6 option                 |
-|                  +-------------------------+-------------------------+
-|                  |          off            |           on            |
-+------------------+-------------------------+-------------------------+
-|                  |Search for A records.    |Search for AAAA records. |
-| gethostbyname    | If found, return IPv4   | If found, return IPv6   |
-| (host)           | addresses (h_length=4). | addresses (h_length=16).|
-|                  | Else error.             | Else search for A       |
-|                  |                         | records.  If found,     |
-|                  |Provides backward        | return IPv4-mapped IPv6 |
-|                  | compatibility with all  | addresses (h_length=16).|
-|                  | existing IPv4 appls.    | Else error.             |
-+------------------+-------------------------+-------------------------+
-|                  |Search for A records.    |Search for A records.    |
-| gethostbyname2   | If found, return IPv4   | If found, return        |
-| (host, AF_INET)  | addresses (h_length=4). | IPv4-mapped IPv6        |
-|                  | Else error.             | addresses (h_length=16).|
-|                  |                         | Else error.             |
-+------------------+-------------------------+-------------------------+
-|                  |Search for AAAA records. |Search for AAAA records. |
-| gethostbyname2   | If found, return IPv6   | If found, return IPv6   |
-| (host, AF_INET6) | addresses (h_length=16).| addresses (h_length=16).|
-|                  | Else error.             | Else error.             |
-+------------------+-------------------------+-------------------------+
-
-   It is expected that when a typical naive application that calls
-   gethostbyname() today is modified to use IPv6, it simply changes the
-   program to use IPv6 sockets and then enables the RES_USE_INET6
-   resolver option before calling gethostbyname().  This application
-   will then work with either IPv4 or IPv6 peers.
-
-   Note that gethostbyname() and gethostbyname2() are not thread-safe,
-   since both return a pointer to a static hostent structure.  But
-   several vendors have defined a thread-safe gethostbyname_r() function
-   that requires four additional arguments.  We expect these vendors to
-   also define a gethostbyname2_r() function.
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 21]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-6.2.  Address To Hostname Translation
-
-   The existing gethostbyaddr() function already requires an address
-   family argument and can therefore work with IPv6 addresses:
-
-       #include <sys/socket.h>
-       #include <netdb.h>
-
-       struct hostent *gethostbyaddr(const char *src, int len, int af);
-
-   One possible source of confusion is the handling of IPv4-mapped IPv6
-   addresses and IPv4-compatible IPv6 addresses.  This is addressed in
-   [6] and involves the following logic:
-
-    1.  If af is AF_INET6, and if len equals 16, and if the IPv6 address
-        is an IPv4-mapped IPv6 address or an IPv4-compatible IPv6
-        address, then skip over the first 12 bytes of the IPv6 address,
-        set af to AF_INET, and set len to 4.
-
-    2.  If af is AF_INET, then query for a PTR record in the in-
-        addr.arpa domain.
-
-    3.  If af is AF_INET6, then query for a PTR record in the ip6.int
-        domain.
-
-    4.  If the function is returning success, and if af equals AF_INET,
-        and if the RES_USE_INET6 option was set, then the single address
-        that is returned in the hostent structure (a copy of the first
-        argument to the function) is returned as an IPv4-mapped IPv6
-        address and the h_length member is set to 16.
-
-   All four steps listed are performed, in order.  The same caveats
-   regarding a thread-safe version of gethostbyname() that were made at
-   the end of the previous section apply here as well.
-
-6.3.  Protocol-Independent Hostname and Service Name Translation
-
-   Hostname-to-address translation is done in a protocol-independent
-   fashion using the getaddrinfo() function that is taken from the
-   Institute of Electrical and Electronic Engineers (IEEE) POSIX 1003.1g
-   (Protocol Independent Interfaces) work in progress specification [4].
-
-   The official specification for this function will be the final POSIX
-   standard.  We are providing this independent description of the
-   function because POSIX standards are not freely available (as are
-   IETF documents).  Should there be any discrepancies between this
-   description and the POSIX description, the POSIX description takes
-   precedence.
-
-
-
-Gilligan, et. al.            Informational                     [Page 22]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-       #include <sys/socket.h>
-       #include <netdb.h>
-
-       int getaddrinfo(const char *hostname, const char *servname,
-                       const struct addrinfo *hints,
-                       struct addrinfo **res);
-
-   The addrinfo structure is defined as:
-
-       #include <sys/socket.h>
-       #include <netdb.h>
-
-       struct addrinfo {
-         int     ai_flags;     /* AI_PASSIVE, AI_CANONNAME */
-         int     ai_family;    /* PF_xxx */
-         int     ai_socktype;  /* SOCK_xxx */
-         int     ai_protocol;  /* 0 or IPPROTO_xxx for IPv4 and IPv6 */
-         size_t  ai_addrlen;   /* length of ai_addr */
-         char   *ai_canonname; /* canonical name for hostname */
-         struct sockaddr  *ai_addr; /* binary address */
-         struct addrinfo  *ai_next; /* next structure in linked list */
-       };
-
-   The return value from the function is 0 upon success or a nonzero
-   error code.  The following names are the nonzero error codes from
-   getaddrinfo(), and are defined in <netdb.h>:
-
-       EAI_ADDRFAMILY  address family for hostname not supported
-       EAI_AGAIN       temporary failure in name resolution
-       EAI_BADFLAGS    invalid value for ai_flags
-       EAI_FAIL        non-recoverable failure in name resolution
-       EAI_FAMILY      ai_family not supported
-       EAI_MEMORY      memory allocation failure
-       EAI_NODATA      no address associated with hostname
-       EAI_NONAME      hostname nor servname provided, or not known
-       EAI_SERVICE     servname not supported for ai_socktype
-       EAI_SOCKTYPE    ai_socktype not supported
-       EAI_SYSTEM      system error returned in errno
-
-   The hostname and servname arguments are pointers to null-terminated
-   strings or NULL.  One or both of these two arguments must be a non-
-   NULL pointer.  In the normal client scenario, both the hostname and
-   servname are specified.  In the normal server scenario, only the
-   servname is specified.  A non-NULL hostname string can be either a
-   host name or a numeric host address string (i.e., a dotted-decimal
-   IPv4 address or an IPv6 hex address).  A non-NULL servname string can
-   be either a service name or a decimal port number.
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 23]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   The caller can optionally pass an addrinfo structure, pointed to by
-   the third argument, to provide hints concerning the type of socket
-   that the caller supports.  In this hints structure all members other
-   than ai_flags, ai_family, ai_socktype, and ai_protocol must be zero
-   or a NULL pointer.  A value of PF_UNSPEC for ai_family means the
-   caller will accept any protocol family.  A value of 0 for ai_socktype
-   means the caller will accept any socket type.  A value of 0 for
-   ai_protocol means the caller will accept any protocol.  For example,
-   if the caller handles only TCP and not UDP, then the ai_socktype
-   member of the hints structure should be set to SOCK_STREAM when
-   getaddrinfo() is called.  If the caller handles only IPv4 and not
-   IPv6, then the ai_family member of the hints structure should be set
-   to PF_INET when getaddrinfo() is called.  If the third argument to
-   getaddrinfo() is a NULL pointer, this is the same as if the caller
-   had filled in an addrinfo structure initialized to zero with
-   ai_family set to PF_UNSPEC.
-
-   Upon successful return a pointer to a linked list of one or more
-   addrinfo structures is returned through the final argument.  The
-   caller can process each addrinfo structure in this list by following
-   the ai_next pointer, until a NULL pointer is encountered.  In each
-   returned addrinfo structure the three members ai_family, ai_socktype,
-   and ai_protocol are the corresponding arguments for a call to the
-   socket() function.  In each addrinfo structure the ai_addr member
-   points to a filled-in socket address structure whose length is
-   specified by the ai_addrlen member.
-
-   If the AI_PASSIVE bit is set in the ai_flags member of the hints
-   structure, then the caller plans to use the returned socket address
-   structure in a call to bind().  In this case, if the hostname
-   argument is a NULL pointer, then the IP address portion of the socket
-   address structure will be set to INADDR_ANY for an IPv4 address or
-   IN6ADDR_ANY_INIT for an IPv6 address.
-
-   If the AI_PASSIVE bit is not set in the ai_flags member of the hints
-   structure, then the returned socket address structure will be ready
-   for a call to connect() (for a connection-oriented protocol) or
-   either connect(), sendto(), or sendmsg() (for a connectionless
-   protocol).  In this case, if the hostname argument is a NULL pointer,
-   then the IP address portion of the socket address structure will be
-   set to the loopback address.
-
-   If the AI_CANONNAME bit is set in the ai_flags member of the hints
-   structure, then upon successful return the ai_canonname member of the
-   first addrinfo structure in the linked list will point to a null-
-   terminated string containing the canonical name of the specified
-   hostname.
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 24]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   All of the information returned by getaddrinfo() is dynamically
-   allocated: the addrinfo structures, and the socket address structures
-   and canonical host name strings pointed to by the addrinfo
-   structures.  To return this information to the system the function
-   freeaddrinfo() is called:
-
-       #include <sys/socket.h>
-       #include <netdb.h>
-
-       void freeaddrinfo(struct addrinfo *ai);
-
-   The addrinfo structure pointed to by the ai argument is freed, along
-   with any dynamic storage pointed to by the structure.  This operation
-   is repeated until a NULL ai_next pointer is encountered.
-
-   To aid applications in printing error messages based on the EAI_xxx
-   codes returned by getaddrinfo(), the following function is defined.
-
-       #include <sys/socket.h>
-       #include <netdb.h>
-
-       char *gai_strerror(int ecode);
-
-   The argument is one of the EAI_xxx values defined earlier and the
-   eturn value points to a string describing the error.  If the argument
-   is not one of the EAI_xxx values, the function still returns a
-   pointer to a string whose contents indicate an unknown error.
-
-6.4.  Socket Address Structure to Hostname and Service Name
-
-   The POSIX 1003.1g specification includes no function to perform the
-   reverse conversion from getaddrinfo():  to look up a hostname and
-   service name, given the binary address and port.  Therefore, we
-   define the following function:
-
-       #include <sys/socket.h>
-       #include <netdb.h>
-
-       int getnameinfo(const struct sockaddr *sa, size_t salen,
-                       char *host, size_t hostlen,
-                       char *serv, size_t servlen,
-                       int flags);
-
-   This function looks up an IP address and port number provided by the
-   caller in the DNS and system-specific database, and returns text
-   strings for both in buffers provided by the caller.  The function
-   indicates successful completion by a zero return value; a non-zero
-   return value indicates failure.
-
-
-
-Gilligan, et. al.            Informational                     [Page 25]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   The first argument, sa, points to either a sockaddr_in structure (for
-   IPv4) or a sockaddr_in6 structure (for IPv6) that holds the IP
-   address and port number.  The salen argument gives the length of the
-   sockaddr_in or sockaddr_in6 structure.
-
-   The function returns the hostname associated with the IP address in
-   the buffer pointed to by the host argument.  The caller provides the
-   size of this buffer via the hostlen argument.  The service name
-   associated with the port number is returned in the buffer pointed to
-   by serv, and the servlen argument gives the length of this buffer.
-   The caller specifies not to return either string by providing a zero
-   value for the hostlen or servlen arguments.  Otherwise, the caller
-   must provide buffers large enough to hold the hostname and the
-   service name, including the terminating null characters.
-
-   Unfortunately most systems do not provide constants that specify the
-   maximum size of either a fully-qualified domain name or a service
-   name.  Therefore to aid the application in allocating buffers for
-   these two returned strings the following constants are defined in
-   <netdb.h>:
-
-       #define NI_MAXHOST  1025
-       #define NI_MAXSERV    32
-
-   The first value is actually defined as the constant MAXDNAME in
-   recent versions of BIND's <arpa/nameser.h> header (older versions of
-   BIND define this constant to be 256) and the second is a guess based
-   on the services listed in the current Assigned Numbers RFC.
-
-   The final argument is a flag that changes the default actions of this
-   function.  By default the fully-qualified domain name (FQDN) for the
-   host is looked up in the DNS and returned.  If the flag bit NI_NOFQDN
-   is set, only the hostname portion of the FQDN is returned for local
-   hosts.
-
-   If the flag bit NI_NUMERICHOST is set, or if the host's name cannot
-   be located in the DNS, the numeric form of the host's address is
-   returned instead of its name (e.g., by calling inet_ntop() instead of
-   gethostbyaddr()).  If the flag bit NI_NAMEREQD is set, an error is
-   returned if the host's name cannot be located in the DNS.
-
-   If the flag bit NI_NUMERICSERV is set, the numeric form of the
-   service address is returned (e.g., its port number) instead of its
-   name.  The two NI_NUMERICxxx flags are required to support the "-n"
-   flag that many commands provide.
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 26]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   A fifth flag bit, NI_DGRAM, specifies that the service is a datagram
-   service, and causes getservbyport() to be called with a second
-   argument of "udp" instead of its default of "tcp".  This is required
-   for the few ports (512-514) that have different services for UDP and
-   TCP.
-
-   These NI_xxx flags are defined in <netdb.h> along with the AI_xxx
-   flags already defined for getaddrinfo().
-
-6.5.  Address Conversion Functions
-
-   The two functions inet_addr() and inet_ntoa() convert an IPv4 address
-   between binary and text form.  IPv6 applications need similar
-   functions.  The following two functions convert both IPv6 and IPv4
-   addresses:
-
-       #include <sys/socket.h>
-       #include <arpa/inet.h>
-
-       int inet_pton(int af, const char *src, void *dst);
-
-       const char *inet_ntop(int af, const void *src,
-                             char *dst, size_t size);
-
-   The inet_pton() function converts an address in its standard text
-   presentation form into its numeric binary form.  The af argument
-   specifies the family of the address.  Currently the AF_INET and
-   AF_INET6 address families are supported.  The src argument points to
-   the string being passed in.  The dst argument points to a buffer into
-   which the function stores the numeric address.  The address is
-   returned in network byte order.  Inet_pton() returns 1 if the
-   conversion succeeds, 0 if the input is not a valid IPv4 dotted-
-   decimal string or a valid IPv6 address string, or -1 with errno set
-   to EAFNOSUPPORT if the af argument is unknown.  The calling
-   application must ensure that the buffer referred to by dst is large
-   enough to hold the numeric address (e.g., 4 bytes for AF_INET or 16
-   bytes for AF_INET6).
-
-   If the af argument is AF_INET, the function accepts a string in the
-   standard IPv4 dotted-decimal form:
-
-       ddd.ddd.ddd.ddd
-
-   where ddd is a one to three digit decimal number between 0 and 255.
-   Note that many implementations of the existing inet_addr() and
-   inet_aton() functions accept nonstandard input:  octal numbers,
-   hexadecimal numbers, and fewer than four numbers.  inet_pton() does
-   not accept these formats.
-
-
-
-Gilligan, et. al.            Informational                     [Page 27]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   If the af argument is AF_INET6, then the function accepts a string in
-   one of the standard IPv6 text forms defined in Section 2.2 of the
-   addressing architecture specification [2].
-
-   The inet_ntop() function converts a numeric address into a text
-   string suitable for presentation.  The af argument specifies the
-   family of the address.  This can be AF_INET or AF_INET6.  The src
-   argument points to a buffer holding an IPv4 address if the af
-   argument is AF_INET, or an IPv6 address if the af argument is
-   AF_INET6.  The dst argument points to a buffer where the function
-   will store the resulting text string.  The size argument specifies
-   the size of this buffer.  The application must specify a non-NULL dst
-   argument.  For IPv6 addresses, the buffer must be at least 46-octets.
-   For IPv4 addresses, the buffer must be at least 16-octets.  In order
-   to allow applications to easily declare buffers of the proper size to
-   store IPv4 and IPv6 addresses in string form, the following two
-   constants are defined in <netinet/in.h>:
-
-       #define INET_ADDRSTRLEN    16
-       #define INET6_ADDRSTRLEN   46
-
-   The inet_ntop() function returns a pointer to the buffer containing
-   the text string if the conversion succeeds, and NULL otherwise.  Upon
-   failure, errno is set to EAFNOSUPPORT if the af argument is invalid
-   or ENOSPC if the size of the result buffer is inadequate.
-
-6.6.  Address Testing Macros
-
-   The following macros can be used to test for special IPv6 addresses.
-
-       #include <netinet/in.h>
-
-       int  IN6_IS_ADDR_UNSPECIFIED (const struct in6_addr *);
-       int  IN6_IS_ADDR_LOOPBACK    (const struct in6_addr *);
-       int  IN6_IS_ADDR_MULTICAST   (const struct in6_addr *);
-       int  IN6_IS_ADDR_LINKLOCAL   (const struct in6_addr *);
-       int  IN6_IS_ADDR_SITELOCAL   (const struct in6_addr *);
-       int  IN6_IS_ADDR_V4MAPPED    (const struct in6_addr *);
-       int  IN6_IS_ADDR_V4COMPAT    (const struct in6_addr *);
-
-       int  IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
-       int  IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
-       int  IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
-       int  IN6_IS_ADDR_MC_ORGLOCAL (const struct in6_addr *);
-       int  IN6_IS_ADDR_MC_GLOBAL   (const struct in6_addr *);
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 28]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   The first seven macros return true if the address is of the specified
-   type, or false otherwise.  The last five test the scope of a
-   multicast address and return true if the address is a multicast
-   address of the specified scope or false if the address is either not
-   a multicast address or not of the specified scope.
-
-7.  Summary of New Definitions
-
-   The following list summarizes the constants, structure, and extern
-   definitions discussed in this memo, sorted by header.
-
-     <net/if.h>      IFNAMSIZ
-     <net/if.h>      struct if_nameindex{};
-
-     <netdb.h>       AI_CANONNAME
-     <netdb.h>       AI_PASSIVE
-     <netdb.h>       EAI_ADDRFAMILY
-     <netdb.h>       EAI_AGAIN
-     <netdb.h>       EAI_BADFLAGS
-     <netdb.h>       EAI_FAIL
-     <netdb.h>       EAI_FAMILY
-     <netdb.h>       EAI_MEMORY
-     <netdb.h>       EAI_NODATA
-     <netdb.h>       EAI_NONAME
-     <netdb.h>       EAI_SERVICE
-     <netdb.h>       EAI_SOCKTYPE
-     <netdb.h>       EAI_SYSTEM
-     <netdb.h>       NI_DGRAM
-     <netdb.h>       NI_MAXHOST
-     <netdb.h>       NI_MAXSERV
-     <netdb.h>       NI_NAMEREQD
-     <netdb.h>       NI_NOFQDN
-     <netdb.h>       NI_NUMERICHOST
-     <netdb.h>       NI_NUMERICSERV
-     <netdb.h>       struct addrinfo{};
-
-     <netinet/in.h>  IN6ADDR_ANY_INIT
-     <netinet/in.h>  IN6ADDR_LOOPBACK_INIT
-     <netinet/in.h>  INET6_ADDRSTRLEN
-     <netinet/in.h>  INET_ADDRSTRLEN
-     <netinet/in.h>  IPPROTO_IPV6
-     <netinet/in.h>  IPV6_ADDRFORM
-     <netinet/in.h>  IPV6_ADD_MEMBERSHIP
-     <netinet/in.h>  IPV6_DROP_MEMBERSHIP
-     <netinet/in.h>  IPV6_MULTICAST_HOPS
-     <netinet/in.h>  IPV6_MULTICAST_IF
-     <netinet/in.h>  IPV6_MULTICAST_LOOP
-     <netinet/in.h>  IPV6_UNICAST_HOPS
-
-
-
-Gilligan, et. al.            Informational                     [Page 29]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-     <netinet/in.h>  SIN6_LEN
-     <netinet/in.h>  extern const struct in6_addr in6addr_any;
-     <netinet/in.h>  extern const struct in6_addr in6addr_loopback;
-     <netinet/in.h>  struct in6_addr{};
-     <netinet/in.h>  struct ipv6_mreq{};
-     <netinet/in.h>  struct sockaddr_in6{};
-
-     <resolv.h>      RES_USE_INET6
-
-     <sys/socket.h>  AF_INET6
-     <sys/socket.h>  PF_INET6
-
-
-   The following list summarizes the function and macro prototypes
-   discussed in this memo, sorted by header.
-
-<arpa/inet.h>   int inet_pton(int, const char *, void *);
-<arpa/inet.h>   const char *inet_ntop(int, const void *,
-                                      char *, size_t);
-
-<net/if.h>      char *if_indextoname(unsigned int, char *);
-<net/if.h>      unsigned int if_nametoindex(const char *);
-<net/if.h>      void if_freenameindex(struct if_nameindex *);
-<net/if.h>      struct if_nameindex *if_nameindex(void);
-
-<netdb.h>       int getaddrinfo(const char *, const char *,
-                                const struct addrinfo *,
-                                struct addrinfo **);
-<netdb.h>       int getnameinfo(const struct sockaddr *, size_t,
-                                char *, size_t, char *, size_t, int);
-<netdb.h>       void freeaddrinfo(struct addrinfo *);
-<netdb.h>       char *gai_strerror(int);
-<netdb.h>       struct hostent *gethostbyname(const char *);
-<netdb.h>       struct hostent *gethostbyaddr(const char *, int, int);
-<netdb.h>       struct hostent *gethostbyname2(const char *, int);
-
-<netinet/in.h>  int IN6_IS_ADDR_LINKLOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_LOOPBACK(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MC_GLOBAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MC_ORGLOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MULTICAST(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_SITELOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_UNSPECIFIED(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_V4COMPAT(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_V4MAPPED(const struct in6_addr *);
-
-
-
-Gilligan, et. al.            Informational                     [Page 30]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-8.  Security Considerations
-
-   IPv6 provides a number of new security mechanisms, many of which need
-   to be accessible to applications.  A companion memo detailing the
-   extensions to the socket interfaces to support IPv6 security is being
-   written [3].
-
-9.  Acknowledgments
-
-   Thanks to the many people who made suggestions and provided feedback
-   to to the numerous revisions of this document, including: Werner
-   Almesberger, Ran Atkinson, Fred Baker, Dave Borman, Andrew Cherenson,
-   Alex Conta, Alan Cox, Steve Deering, Richard Draves, Francis Dupont,
-   Robert Elz, Marc Hasson, Tim Hartrick, Tom Herbert, Bob Hinden, Wan-
-   Yen Hsu, Christian Huitema, Koji Imada, Markus Jork, Ron Lee, Alan
-   Lloyd, Charles Lynn, Jack McCann, Dan McDonald, Dave Mitton, Thomas
-   Narten, Erik Nordmark, Josh Osborne, Craig Partridge, Jean-Luc
-   Richier, Erik Scoredos, Keith Sklower, Matt Thomas, Harvey Thompson,
-   Dean D. Throop, Karen Tracey, Glenn Trewitt, Paul Vixie, David
-   Waitzman, Carl Williams, and Kazuhiko Yamamoto,
-
-   The getaddrinfo() and getnameinfo() functions are taken from an
-   earlier Work in Progress by Keith Sklower.  As noted in that
-   document, William Durst, Steven Wise, Michael Karels, and Eric Allman
-   provided many useful discussions on the subject of protocol-
-   independent name-to-address translation, and reviewed early versions
-   of Keith Sklower's original proposal.  Eric Allman implemented the
-   first prototype of getaddrinfo().  The observation that specifying
-   the pair of name and service would suffice for connecting to a
-   service independent of protocol details was made by Marshall Rose in
-   a proposal to X/Open for a "Uniform Network Interface".
-
-   Craig Metz made many contributions to this document.  Ramesh Govindan
-   made a number of contributions and co-authored an earlier version of
-   this memo.
-
-10.  References
-
-   [1] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6)
-       Specification", RFC 1883, December 1995.
-
-   [2] Hinden, R., and S. Deering, "IP Version 6 Addressing Architecture",
-       RFC 1884, December 1995.
-
-   [3] McDonald, D., "A Simple IP Security API Extension to BSD Sockets",
-       Work in Progress.
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 31]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   [4] IEEE, "Protocol Independent Interfaces", IEEE Std 1003.1g, DRAFT
-       6.3, November 1995.
-
-   [5] Stevens, W., and M. Thomas, "Advanced Sockets API for IPv6",
-       Work in Progress.
-
-   [6] Vixie, P., "Reverse Name Lookups of Encapsulated IPv4 Addresses in
-       IPv6", Work in Progress.
-
-11.  Authors' Addresses
-
-    Robert E. Gilligan
-    Freegate Corporation
-    710 Lakeway Dr.  STE 230
-    Sunnyvale, CA 94086
-
-    Phone: +1 408 524 4804
-    EMail: gilligan@freegate.net
-
-
-    Susan Thomson
-    Bell Communications Research
-    MRE 2P-343, 445 South Street
-    Morristown, NJ 07960
-
-    Phone: +1 201 829 4514
-    EMail: set@thumper.bellcore.com
-
-
-    Jim Bound
-    Digital Equipment Corporation
-    110 Spitbrook Road ZK3-3/U14
-    Nashua, NH 03062-2698
-
-    Phone: +1 603 881 0400
-    Email: bound@zk3.dec.com
-
-
-    W. Richard Stevens
-    1202 E. Paseo del Zorro
-    Tucson, AZ 85718-2826
-
-    Phone: +1 520 297 9416
-    EMail: rstevens@kohala.com
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 32]
-
diff --git a/contrib/bind9/doc/rfc/rfc2136.txt b/contrib/bind9/doc/rfc/rfc2136.txt
deleted file mode 100644
index 4d62702..0000000
--- a/contrib/bind9/doc/rfc/rfc2136.txt
+++ /dev/null
@@ -1,1460 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                  P. Vixie, Editor
-Request for Comments: 2136                                          ISC
-Updates: 1035                                                S. Thomson
-Category: Standards Track                                      Bellcore
-                                                             Y. Rekhter
-                                                                  Cisco
-                                                               J. Bound
-                                                                    DEC
-                                                             April 1997
-
-         Dynamic Updates in the Domain Name System (DNS UPDATE)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Abstract
-
-   The Domain Name System was originally designed to support queries of
-   a statically configured database.  While the data was expected to
-   change, the frequency of those changes was expected to be fairly low,
-   and all updates were made as external edits to a zone's Master File.
-
-   Using this specification of the UPDATE opcode, it is possible to add
-   or delete RRs or RRsets from a specified zone.  Prerequisites are
-   specified separately from update operations, and can specify a
-   dependency upon either the previous existence or nonexistence of an
-   RRset, or the existence of a single RR.
-
-   UPDATE is atomic, i.e., all prerequisites must be satisfied or else
-   no update operations will take place.  There are no data dependent
-   error conditions defined after the prerequisites have been met.
-
-1 - Definitions
-
-   This document intentionally gives more definition to the roles of
-   "Master," "Slave," and "Primary Master" servers, and their
-   enumeration in NS RRs, and the SOA MNAME field.  In that sense, the
-   following server type definitions can be considered an addendum to
-   [RFC1035], and are intended to be consistent with [RFC1996]:
-
-      Slave           an authoritative server that uses AXFR or IXFR to
-                      retrieve the zone and is named in the zone's NS
-                      RRset.
-
-
-
-Vixie, et. al.              Standards Track                     [Page 1]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-      Master          an authoritative server configured to be the
-                      source of AXFR or IXFR data for one or more slave
-                      servers.
-
-      Primary Master  master server at the root of the AXFR/IXFR
-                      dependency graph.  The primary master is named in
-                      the zone's SOA MNAME field and optionally by an NS
-                      RR.  There is by definition only one primary master
-                      server per zone.
-
-   A domain name identifies a node within the domain name space tree
-   structure.  Each node has a set (possibly empty) of Resource Records
-   (RRs).  All RRs having the same NAME, CLASS and TYPE are called a
-   Resource Record Set (RRset).
-
-   The pseudocode used in this document is for example purposes only.
-   If it is found to disagree with the text, the text shall be
-   considered authoritative.  If the text is found to be ambiguous, the
-   pseudocode can be used to help resolve the ambiguity.
-
-   1.1 - Comparison Rules
-
-   1.1.1. Two RRs are considered equal if their NAME, CLASS, TYPE,
-   RDLENGTH and RDATA fields are equal.  Note that the time-to-live
-   (TTL) field is explicitly excluded from the comparison.
-
-   1.1.2. The rules for comparison of character strings in names are
-   specified in [RFC1035 2.3.3].
-
-   1.1.3. Wildcarding is disabled.  That is, a wildcard ("*") in an
-   update only matches a wildcard ("*") in the zone, and vice versa.
-
-   1.1.4. Aliasing is disabled: A CNAME in the zone matches a CNAME in
-   the update, and will not otherwise be followed.  All UPDATE
-   operations are done on the basis of canonical names.
-
-   1.1.5. The following RR types cannot be appended to an RRset.  If the
-   following comparison rules are met, then an attempt to add the new RR
-   will result in the replacement of the previous RR:
-
-      SOA    compare only NAME, CLASS and TYPE -- it is not possible to
-             have more than one SOA per zone, even if any of the data
-             fields differ.
-
-      WKS    compare only NAME, CLASS, TYPE, ADDRESS, and PROTOCOL
-             -- only one WKS RR is possible for this tuple, even if the
-             services masks differ.
-
-
-
-
-Vixie, et. al.              Standards Track                     [Page 2]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-      CNAME  compare only NAME, CLASS, and TYPE -- it is not possible
-             to have more than one CNAME RR, even if their data fields
-             differ.
-
-   1.2 - Glue RRs
-
-   For the purpose of determining whether a domain name used in the
-   UPDATE protocol is contained within a specified zone, a domain name
-   is "in" a zone if it is owned by that zone's domain name.  See
-   section 7.18 for details.
-
-   1.3 - New Assigned Numbers
-
-      CLASS = NONE (254)
-      RCODE = YXDOMAIN (6)
-      RCODE = YXRRSET (7)
-      RCODE = NXRRSET (8)
-      RCODE = NOTAUTH (9)
-      RCODE = NOTZONE (10)
-      Opcode = UPDATE (5)
-
-2 - Update Message Format
-
-   The DNS Message Format is defined by [RFC1035 4.1].  Some extensions
-   are necessary (for example, more error codes are possible under
-   UPDATE than under QUERY) and some fields must be overloaded (see
-   description of CLASS fields below).
-
-   The overall format of an UPDATE message is, following [ibid]:
-
-      +---------------------+
-      |        Header       |
-      +---------------------+
-      |         Zone        | specifies the zone to be updated
-      +---------------------+
-      |     Prerequisite    | RRs or RRsets which must (not) preexist
-      +---------------------+
-      |        Update       | RRs or RRsets to be added or deleted
-      +---------------------+
-      |   Additional Data   | additional data
-      +---------------------+
-
-
-
-
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                     [Page 3]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   The Header Section specifies that this message is an UPDATE, and
-   describes the size of the other sections.  The Zone Section names the
-   zone that is to be updated by this message.  The Prerequisite Section
-   specifies the starting invariants (in terms of zone content) required
-   for this update.  The Update Section contains the edits to be made,
-   and the Additional Data Section contains data which may be necessary
-   to complete, but is not part of, this update.
-
-   2.1 - Transport Issues
-
-   An update transaction may be carried in a UDP datagram, if the
-   request fits, or in a TCP connection (at the discretion of the
-   requestor).  When TCP is used, the message is in the format described
-   in [RFC1035 4.2.2].
-
-   2.2 - Message Header
-
-   The header of the DNS Message Format is defined by [RFC 1035 4.1].
-   Not all opcodes define the same set of flag bits, though as a
-   practical matter most of the bits defined for QUERY (in [ibid]) are
-   identically defined by the other opcodes.  UPDATE uses only one flag
-   bit (QR).
-
-   The DNS Message Format specifies record counts for its four sections
-   (Question, Answer, Authority, and Additional).  UPDATE uses the same
-   fields, and the same section formats, but the naming and use of these
-   sections differs as shown in the following modified header, after
-   [RFC1035 4.1.1]:
-
-                                      1  1  1  1  1  1
-        0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
-      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      |                      ID                       |
-      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      |QR|   Opcode  |          Z         |   RCODE   |
-      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      |                    ZOCOUNT                    |
-      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      |                    PRCOUNT                    |
-      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      |                    UPCOUNT                    |
-      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      |                    ADCOUNT                    |
-      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                     [Page 4]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   These fields are used as follows:
-
-   ID      A 16-bit identifier assigned by the entity that generates any
-           kind of request.  This identifier is copied in the
-           corresponding reply and can be used by the requestor to match
-           replies to outstanding requests, or by the server to detect
-           duplicated requests from some requestor.
-
-   QR      A one bit field that specifies whether this message is a
-           request (0), or a response (1).
-
-   Opcode  A four bit field that specifies the kind of request in this
-           message.  This value is set by the originator of a request
-           and copied into the response.  The Opcode value that
-           identifies an UPDATE message is five (5).
-
-   Z       Reserved for future use.  Should be zero (0) in all requests
-           and responses.  A non-zero Z field should be ignored by
-           implementations of this specification.
-
-   RCODE   Response code - this four bit field is undefined in requests
-           and set in responses.  The values and meanings of this field
-           within responses are as follows:
-
-              Mneumonic   Value   Description
-              ------------------------------------------------------------
-              NOERROR     0       No error condition.
-              FORMERR     1       The name server was unable to interpret
-                                  the request due to a format error.
-              SERVFAIL    2       The name server encountered an internal
-                                  failure while processing this request,
-                                  for example an operating system error
-                                  or a forwarding timeout.
-              NXDOMAIN    3       Some name that ought to exist,
-                                  does not exist.
-              NOTIMP      4       The name server does not support
-                                  the specified Opcode.
-              REFUSED     5       The name server refuses to perform the
-                                  specified operation for policy or
-                                  security reasons.
-              YXDOMAIN    6       Some name that ought not to exist,
-                                  does exist.
-              YXRRSET     7       Some RRset that ought not to exist,
-                                  does exist.
-              NXRRSET     8       Some RRset that ought to exist,
-                                  does not exist.
-
-
-
-
-
-Vixie, et. al.              Standards Track                     [Page 5]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-              NOTAUTH     9       The server is not authoritative for
-                                  the zone named in the Zone Section.
-              NOTZONE     10      A name used in the Prerequisite or
-                                  Update Section is not within the
-                                  zone denoted by the Zone Section.
-
-   ZOCOUNT The number of RRs in the Zone Section.
-
-   PRCOUNT The number of RRs in the Prerequisite Section.
-
-   UPCOUNT The number of RRs in the Update Section.
-
-   ADCOUNT The number of RRs in the Additional Data Section.
-
-   2.3 - Zone Section
-
-   The Zone Section has the same format as that specified in [RFC1035
-   4.1.2], with the fields redefined as follows:
-
-                                      1  1  1  1  1  1
-        0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
-      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      |                                               |
-      /                     ZNAME                     /
-      /                                               /
-      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      |                     ZTYPE                     |
-      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      |                     ZCLASS                    |
-      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-   UPDATE uses this section to denote the zone of the records being
-   updated.  All records to be updated must be in the same zone, and
-   therefore the Zone Section is allowed to contain exactly one record.
-   The ZNAME is the zone name, the ZTYPE must be SOA, and the ZCLASS is
-   the zone's class.
-
-   2.4 - Prerequisite Section
-
-   This section contains a set of RRset prerequisites which must be
-   satisfied at the time the UPDATE packet is received by the primary
-   master server.  The format of this section is as specified by
-   [RFC1035 4.1.3].  There are five possible sets of semantics that can
-   be expressed here, summarized as follows and then explained below.
-
-      (1)  RRset exists (value independent).  At least one RR with a
-           specified NAME and TYPE (in the zone and class specified by
-           the Zone Section) must exist.
-
-
-
-Vixie, et. al.              Standards Track                     [Page 6]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-      (2)  RRset exists (value dependent).  A set of RRs with a
-           specified NAME and TYPE exists and has the same members
-           with the same RDATAs as the RRset specified here in this
-           Section.
-
-      (3)  RRset does not exist.  No RRs with a specified NAME and TYPE
-          (in the zone and class denoted by the Zone Section) can exist.
-
-      (4)  Name is in use.  At least one RR with a specified NAME (in
-           the zone and class specified by the Zone Section) must exist.
-           Note that this prerequisite is NOT satisfied by empty
-           nonterminals.
-
-      (5)  Name is not in use.  No RR of any type is owned by a
-           specified NAME.  Note that this prerequisite IS satisfied by
-           empty nonterminals.
-
-   The syntax of these is as follows:
-
-   2.4.1 - RRset Exists (Value Independent)
-
-   At least one RR with a specified NAME and TYPE (in the zone and class
-   specified in the Zone Section) must exist.
-
-   For this prerequisite, a requestor adds to the section a single RR
-   whose NAME and TYPE are equal to that of the zone RRset whose
-   existence is required.  RDLENGTH is zero and RDATA is therefore
-   empty.  CLASS must be specified as ANY to differentiate this
-   condition from that of an actual RR whose RDLENGTH is naturally zero
-   (0) (e.g., NULL).  TTL is specified as zero (0).
-
-   2.4.2 - RRset Exists (Value Dependent)
-
-   A set of RRs with a specified NAME and TYPE exists and has the same
-   members with the same RDATAs as the RRset specified here in this
-   section.  While RRset ordering is undefined and therefore not
-   significant to this comparison, the sets be identical in their
-   extent.
-
-   For this prerequisite, a requestor adds to the section an entire
-   RRset whose preexistence is required.  NAME and TYPE are that of the
-   RRset being denoted.  CLASS is that of the zone.  TTL must be
-   specified as zero (0) and is ignored when comparing RRsets for
-   identity.
-
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                     [Page 7]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   2.4.3 - RRset Does Not Exist
-
-   No RRs with a specified NAME and TYPE (in the zone and class denoted
-   by the Zone Section) can exist.
-
-   For this prerequisite, a requestor adds to the section a single RR
-   whose NAME and TYPE are equal to that of the RRset whose nonexistence
-   is required.  The RDLENGTH of this record is zero (0), and RDATA
-   field is therefore empty.  CLASS must be specified as NONE in order
-   to distinguish this condition from a valid RR whose RDLENGTH is
-   naturally zero (0) (for example, the NULL RR).  TTL must be specified
-   as zero (0).
-
-   2.4.4 - Name Is In Use
-
-   Name is in use.  At least one RR with a specified NAME (in the zone
-   and class specified by the Zone Section) must exist.  Note that this
-   prerequisite is NOT satisfied by empty nonterminals.
-
-   For this prerequisite, a requestor adds to the section a single RR
-   whose NAME is equal to that of the name whose ownership of an RR is
-   required.  RDLENGTH is zero and RDATA is therefore empty.  CLASS must
-   be specified as ANY to differentiate this condition from that of an
-   actual RR whose RDLENGTH is naturally zero (0) (e.g., NULL).  TYPE
-   must be specified as ANY to differentiate this case from that of an
-   RRset existence test.  TTL is specified as zero (0).
-
-   2.4.5 - Name Is Not In Use
-
-   Name is not in use.  No RR of any type is owned by a specified NAME.
-   Note that this prerequisite IS satisfied by empty nonterminals.
-
-   For this prerequisite, a requestor adds to the section a single RR
-   whose NAME is equal to that of the name whose nonownership of any RRs
-   is required.  RDLENGTH is zero and RDATA is therefore empty.  CLASS
-   must be specified as NONE.  TYPE must be specified as ANY.  TTL must
-   be specified as zero (0).
-
-   2.5 - Update Section
-
-   This section contains RRs to be added to or deleted from the zone.
-   The format of this section is as specified by [RFC1035 4.1.3].  There
-   are four possible sets of semantics, summarized below and with
-   details to follow.
-
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                     [Page 8]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-      (1) Add RRs to an RRset.
-      (2) Delete an RRset.
-      (3) Delete all RRsets from a name.
-      (4) Delete an RR from an RRset.
-
-   The syntax of these is as follows:
-
-   2.5.1 - Add To An RRset
-
-   RRs are added to the Update Section whose NAME, TYPE, TTL, RDLENGTH
-   and RDATA are those being added, and CLASS is the same as the zone
-   class.  Any duplicate RRs will be silently ignored by the primary
-   master.
-
-   2.5.2 - Delete An RRset
-
-   One RR is added to the Update Section whose NAME and TYPE are those
-   of the RRset to be deleted.  TTL must be specified as zero (0) and is
-   otherwise not used by the primary master.  CLASS must be specified as
-   ANY.  RDLENGTH must be zero (0) and RDATA must therefore be empty.
-   If no such RRset exists, then this Update RR will be silently ignored
-   by the primary master.
-
-   2.5.3 - Delete All RRsets From A Name
-
-   One RR is added to the Update Section whose NAME is that of the name
-   to be cleansed of RRsets.  TYPE must be specified as ANY.  TTL must
-   be specified as zero (0) and is otherwise not used by the primary
-   master.  CLASS must be specified as ANY.  RDLENGTH must be zero (0)
-   and RDATA must therefore be empty.  If no such RRsets exist, then
-   this Update RR will be silently ignored by the primary master.
-
-   2.5.4 - Delete An RR From An RRset
-
-   RRs to be deleted are added to the Update Section.  The NAME, TYPE,
-   RDLENGTH and RDATA must match the RR being deleted.  TTL must be
-   specified as zero (0) and will otherwise be ignored by the primary
-   master.  CLASS must be specified as NONE to distinguish this from an
-   RR addition.  If no such RRs exist, then this Update RR will be
-   silently ignored by the primary master.
-
-
-
-
-
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                     [Page 9]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   2.6 - Additional Data Section
-
-   This section contains RRs which are related to the update itself, or
-   to new RRs being added by the update.  For example, out of zone glue
-   (A RRs referred to by new NS RRs) should be presented here.  The
-   server can use or ignore out of zone glue, at the discretion of the
-   server implementor.  The format of this section is as specified by
-   [RFC1035 4.1.3].
-
-3 - Server Behavior
-
-   A server, upon receiving an UPDATE request, will signal NOTIMP to the
-   requestor if the UPDATE opcode is not recognized or if it is
-   recognized but has not been implemented.  Otherwise, processing
-   continues as follows.
-
-   3.1 - Process Zone Section
-
-   3.1.1. The Zone Section is checked to see that there is exactly one
-   RR therein and that the RR's ZTYPE is SOA, else signal FORMERR to the
-   requestor.  Next, the ZNAME and ZCLASS are checked to see if the zone
-   so named is one of this server's authority zones, else signal NOTAUTH
-   to the requestor.  If the server is a zone slave, the request will be
-   forwarded toward the primary master.
-
-   3.1.2 - Pseudocode For Zone Section Processing
-
-      if (zcount != 1 || ztype != SOA)
-           return (FORMERR)
-      if (zone_type(zname, zclass) == SLAVE)
-           return forward()
-      if (zone_type(zname, zclass) == MASTER)
-           return update()
-      return (NOTAUTH)
-
-   Sections 3.2 through 3.8 describe the primary master's behaviour,
-   whereas Section 6 describes a forwarder's behaviour.
-
-   3.2 - Process Prerequisite Section
-
-   Next, the Prerequisite Section is checked to see that all
-   prerequisites are satisfied by the current state of the zone.  Using
-   the definitions expressed in Section 1.2, if any RR's NAME is not
-   within the zone specified in the Zone Section, signal NOTZONE to the
-   requestor.
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                    [Page 10]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   3.2.1. For RRs in this section whose CLASS is ANY, test to see that
-   TTL and RDLENGTH are both zero (0), else signal FORMERR to the
-   requestor.  If TYPE is ANY, test to see that there is at least one RR
-   in the zone whose NAME is the same as that of the Prerequisite RR,
-   else signal NXDOMAIN to the requestor.  If TYPE is not ANY, test to
-   see that there is at least one RR in the zone whose NAME and TYPE are
-   the same as that of the Prerequisite RR, else signal NXRRSET to the
-   requestor.
-
-   3.2.2. For RRs in this section whose CLASS is NONE, test to see that
-   the TTL and RDLENGTH are both zero (0), else signal FORMERR to the
-   requestor.  If the TYPE is ANY, test to see that there are no RRs in
-   the zone whose NAME is the same as that of the Prerequisite RR, else
-   signal YXDOMAIN to the requestor.  If the TYPE is not ANY, test to
-   see that there are no RRs in the zone whose NAME and TYPE are the
-   same as that of the Prerequisite RR, else signal YXRRSET to the
-   requestor.
-
-   3.2.3. For RRs in this section whose CLASS is the same as the ZCLASS,
-   test to see that the TTL is zero (0), else signal FORMERR to the
-   requestor.  Then, build an RRset for each unique <NAME,TYPE> and
-   compare each resulting RRset for set equality (same members, no more,
-   no less) with RRsets in the zone.  If any Prerequisite RRset is not
-   entirely and exactly matched by a zone RRset, signal NXRRSET to the
-   requestor.  If any RR in this section has a CLASS other than ZCLASS
-   or NONE or ANY, signal FORMERR to the requestor.
-
-   3.2.4 - Table Of Metavalues Used In Prerequisite Section
-
-   CLASS    TYPE     RDATA    Meaning
-   ------------------------------------------------------------
-   ANY      ANY      empty    Name is in use
-   ANY      rrset    empty    RRset exists (value independent)
-   NONE     ANY      empty    Name is not in use
-   NONE     rrset    empty    RRset does not exist
-   zone     rrset    rr       RRset exists (value dependent)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                    [Page 11]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   3.2.5 - Pseudocode for Prerequisite Section Processing
-
-      for rr in prerequisites
-           if (rr.ttl != 0)
-                return (FORMERR)
-           if (zone_of(rr.name) != ZNAME)
-                return (NOTZONE);
-           if (rr.class == ANY)
-                if (rr.rdlength != 0)
-                     return (FORMERR)
-                if (rr.type == ANY)
-                     if (!zone_name<rr.name>)
-                          return (NXDOMAIN)
-                else
-                     if (!zone_rrset<rr.name, rr.type>)
-                          return (NXRRSET)
-           if (rr.class == NONE)
-                if (rr.rdlength != 0)
-                     return (FORMERR)
-                if (rr.type == ANY)
-                     if (zone_name<rr.name>)
-                          return (YXDOMAIN)
-                else
-                     if (zone_rrset<rr.name, rr.type>)
-                          return (YXRRSET)
-           if (rr.class == zclass)
-                temp<rr.name, rr.type> += rr
-           else
-                return (FORMERR)
-
-      for rrset in temp
-           if (zone_rrset<rrset.name, rrset.type> != rrset)
-                return (NXRRSET)
-
-   3.3 - Check Requestor's Permissions
-
-   3.3.1. Next, the requestor's permission to update the RRs named in
-   the Update Section may be tested in an implementation dependent
-   fashion or using mechanisms specified in a subsequent Secure DNS
-   Update protocol.  If the requestor does not have permission to
-   perform these updates, the server may write a warning message in its
-   operations log, and may either signal REFUSED to the requestor, or
-   ignore the permission problem and proceed with the update.
-
-
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                    [Page 12]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   3.3.2. While the exact processing is implementation defined, if these
-   verification activities are to be performed, this is the point in the
-   server's processing where such performance should take place, since
-   if a REFUSED condition is encountered after an update has been
-   partially applied, it will be necessary to undo the partial update
-   and restore the zone to its original state before answering the
-   requestor.
-
-   3.3.3 - Pseudocode for Permission Checking
-
-      if (security policy exists)
-           if (this update is not permitted)
-                if (local option)
-                     log a message about permission problem
-                if (local option)
-                     return (REFUSED)
-
-   3.4 - Process Update Section
-
-   Next, the Update Section is processed as follows.
-
-   3.4.1 - Prescan
-
-   The Update Section is parsed into RRs and each RR's CLASS is checked
-   to see if it is ANY, NONE, or the same as the Zone Class, else signal
-   a FORMERR to the requestor.  Using the definitions in Section 1.2,
-   each RR's NAME must be in the zone specified by the Zone Section,
-   else signal NOTZONE to the requestor.
-
-   3.4.1.2. For RRs whose CLASS is not ANY, check the TYPE and if it is
-   ANY, AXFR, MAILA, MAILB, or any other QUERY metatype, or any
-   unrecognized type, then signal FORMERR to the requestor.  For RRs
-   whose CLASS is ANY or NONE, check the TTL to see that it is zero (0),
-   else signal a FORMERR to the requestor.  For any RR whose CLASS is
-   ANY, check the RDLENGTH to make sure that it is zero (0) (that is,
-   the RDATA field is empty), and that the TYPE is not AXFR, MAILA,
-   MAILB, or any other QUERY metatype besides ANY, or any unrecognized
-   type, else signal FORMERR to the requestor.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                    [Page 13]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   3.4.1.3 - Pseudocode For Update Section Prescan
-
-      [rr] for rr in updates
-           if (zone_of(rr.name) != ZNAME)
-                return (NOTZONE);
-           if (rr.class == zclass)
-                if (rr.type & ANY|AXFR|MAILA|MAILB)
-                     return (FORMERR)
-           elsif (rr.class == ANY)
-                if (rr.ttl != 0 || rr.rdlength != 0
-                    || rr.type & AXFR|MAILA|MAILB)
-                     return (FORMERR)
-           elsif (rr.class == NONE)
-                if (rr.ttl != 0 || rr.type & ANY|AXFR|MAILA|MAILB)
-                     return (FORMERR)
-           else
-                return (FORMERR)
-
-   3.4.2 - Update
-
-   The Update Section is parsed into RRs and these RRs are processed in
-   order.
-
-   3.4.2.1. If any system failure (such as an out of memory condition,
-   or a hardware error in persistent storage) occurs during the
-   processing of this section, signal SERVFAIL to the requestor and undo
-   all updates applied to the zone during this transaction.
-
-   3.4.2.2. Any Update RR whose CLASS is the same as ZCLASS is added to
-   the zone.  In case of duplicate RDATAs (which for SOA RRs is always
-   the case, and for WKS RRs is the case if the ADDRESS and PROTOCOL
-   fields both match), the Zone RR is replaced by Update RR.  If the
-   TYPE is SOA and there is no Zone SOA RR, or the new SOA.SERIAL is
-   lower (according to [RFC1982]) than or equal to the current Zone SOA
-   RR's SOA.SERIAL, the Update RR is ignored.  In the case of a CNAME
-   Update RR and a non-CNAME Zone RRset or vice versa, ignore the CNAME
-   Update RR, otherwise replace the CNAME Zone RR with the CNAME Update
-   RR.
-
-   3.4.2.3. For any Update RR whose CLASS is ANY and whose TYPE is ANY,
-   all Zone RRs with the same NAME are deleted, unless the NAME is the
-   same as ZNAME in which case only those RRs whose TYPE is other than
-   SOA or NS are deleted.  For any Update RR whose CLASS is ANY and
-   whose TYPE is not ANY all Zone RRs with the same NAME and TYPE are
-   deleted, unless the NAME is the same as ZNAME in which case neither
-   SOA or NS RRs will be deleted.
-
-
-
-
-
-Vixie, et. al.              Standards Track                    [Page 14]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   3.4.2.4. For any Update RR whose class is NONE, any Zone RR whose
-   NAME, TYPE, RDATA and RDLENGTH are equal to the Update RR is deleted,
-   unless the NAME is the same as ZNAME and either the TYPE is SOA or
-   the TYPE is NS and the matching Zone RR is the only NS remaining in
-   the RRset, in which case this Update RR is ignored.
-
-   3.4.2.5. Signal NOERROR to the requestor.
-
-   3.4.2.6 - Table Of Metavalues Used In Update Section
-
-   CLASS    TYPE     RDATA    Meaning
-   ---------------------------------------------------------
-   ANY      ANY      empty    Delete all RRsets from a name
-   ANY      rrset    empty    Delete an RRset
-   NONE     rrset    rr       Delete an RR from an RRset
-   zone     rrset    rr       Add to an RRset
-
-   3.4.2.7 - Pseudocode For Update Section Processing
-
-      [rr] for rr in updates
-           if (rr.class == zclass)
-                if (rr.type == CNAME)
-                     if (zone_rrset<rr.name, ~CNAME>)
-                          next [rr]
-                elsif (zone_rrset<rr.name, CNAME>)
-                     next [rr]
-                if (rr.type == SOA)
-                     if (!zone_rrset<rr.name, SOA> ||
-                         zone_rr<rr.name, SOA>.serial > rr.soa.serial)
-                          next [rr]
-                for zrr in zone_rrset<rr.name, rr.type>
-                     if (rr.type == CNAME || rr.type == SOA ||
-                         (rr.type == WKS && rr.proto == zrr.proto &&
-                          rr.address == zrr.address) ||
-                         rr.rdata == zrr.rdata)
-                          zrr = rr
-                          next [rr]
-                zone_rrset<rr.name, rr.type> += rr
-           elsif (rr.class == ANY)
-                if (rr.type == ANY)
-                     if (rr.name == zname)
-                          zone_rrset<rr.name, ~(SOA|NS)> = Nil
-                     else
-                          zone_rrset<rr.name, *> = Nil
-                elsif (rr.name == zname &&
-                       (rr.type == SOA || rr.type == NS))
-                     next [rr]
-                else
-
-
-
-Vixie, et. al.              Standards Track                    [Page 15]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-                     zone_rrset<rr.name, rr.type> = Nil
-           elsif (rr.class == NONE)
-                if (rr.type == SOA)
-                     next [rr]
-                if (rr.type == NS && zone_rrset<rr.name, NS> == rr)
-                     next [rr]
-                zone_rr<rr.name, rr.type, rr.data> = Nil
-      return (NOERROR)
-
-   3.5 - Stability
-
-   When a zone is modified by an UPDATE operation, the server must
-   commit the change to nonvolatile storage before sending a response to
-   the requestor or answering any queries or transfers for the modified
-   zone.  It is reasonable for a server to store only the update records
-   as long as a system reboot or power failure will cause these update
-   records to be incorporated into the zone the next time the server is
-   started.  It is also reasonable for the server to copy the entire
-   modified zone to nonvolatile storage after each update operation,
-   though this would have suboptimal performance for large zones.
-
-   3.6 - Zone Identity
-
-   If the zone's SOA SERIAL is changed by an update operation, that
-   change must be in a positive direction (using modulo 2**32 arithmetic
-   as specified by [RFC1982]).  Attempts to replace an SOA with one
-   whose SERIAL is less than the current one will be silently ignored by
-   the primary master server.
-
-   If the zone's SOA's SERIAL is not changed as a result of an update
-   operation, then the server shall increment it automatically before
-   the SOA or any changed name or RR or RRset is included in any
-   response or transfer.  The primary master server's implementor might
-   choose to autoincrement the SOA SERIAL if any of the following events
-   occurs:
-
-   (1)  Each update operation.
-
-   (2)  A name, RR or RRset in the zone has changed and has subsequently
-        been visible to a DNS client since the unincremented SOA was
-        visible to a DNS client, and the SOA is about to become visible
-        to a DNS client.
-
-   (3)  A configurable period of time has elapsed since the last update
-        operation.  This period shall be less than or equal to one third
-        of the zone refresh time, and the default shall be the lesser of
-        that maximum and 300 seconds.
-
-
-
-
-Vixie, et. al.              Standards Track                    [Page 16]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   (4)  A configurable number of updates has been applied since the last
-        SOA change.  The default value for this configuration parameter
-        shall be one hundred (100).
-
-   It is imperative that the zone's contents and the SOA's SERIAL be
-   tightly synchronized.  If the zone appears to change, the SOA must
-   appear to change as well.
-
-   3.7 - Atomicity
-
-   During the processing of an UPDATE transaction, the server must
-   ensure atomicity with respect to other (concurrent) UPDATE or QUERY
-   transactions.  No two transactions can be processed concurrently if
-   either depends on the final results of the other; in particular, a
-   QUERY should not be able to retrieve RRsets which have been partially
-   modified by a concurrent UPDATE, and an UPDATE should not be able to
-   start from prerequisites that might not still hold at the completion
-   of some other concurrent UPDATE.  Finally, if two UPDATE transactions
-   would modify the same names, RRs or RRsets, then such UPDATE
-   transactions must be serialized.
-
-   3.8 - Response
-
-   At the end of UPDATE processing, a response code will be known.  A
-   response message is generated by copying the ID and Opcode fields
-   from the request, and either copying the ZOCOUNT, PRCOUNT, UPCOUNT,
-   and ADCOUNT fields and associated sections, or placing zeros (0) in
-   the these "count" fields and not including any part of the original
-   update.  The QR bit is set to one (1), and the response is sent back
-   to the requestor.  If the requestor used UDP, then the response will
-   be sent to the requestor's source UDP port.  If the requestor used
-   TCP, then the response will be sent back on the requestor's open TCP
-   connection.
-
-4 - Requestor Behaviour
-
-   4.1. From a requestor's point of view, any authoritative server for
-   the zone can appear to be able to process update requests, even
-   though only the primary master server is actually able to modify the
-   zone's master file.  Requestors are expected to know the name of the
-   zone they intend to update and to know or be able to determine the
-   name servers for that zone.
-
-
-
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                    [Page 17]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   4.2. If update ordering is desired, the requestor will need to know
-   the value of the existing SOA RR.  Requestors who update the SOA RR
-   must update the SOA SERIAL field in a positive direction (as defined
-   by [RFC1982]) and also preserve the other SOA fields unless the
-   requestor's explicit intent is to change them.  The SOA SERIAL field
-   must never be set to zero (0).
-
-   4.3. If the requestor has reasonable cause to believe that all of a
-   zone's servers will be equally reachable, then it should arrange to
-   try the primary master server (as given by the SOA MNAME field if
-   matched by some NS NSDNAME) first to avoid unnecessary forwarding
-   inside the slave servers.  (Note that the primary master will in some
-   cases not be reachable by all requestors, due to firewalls or network
-   partitioning.)
-
-   4.4. Once the zone's name servers been found and possibly sorted so
-   that the ones more likely to be reachable and/or support the UPDATE
-   opcode are listed first, the requestor composes an UPDATE message of
-   the following form and sends it to the first name server on its list:
-
-      ID:                        (new)
-      Opcode:                    UPDATE
-      Zone zcount:               1
-      Zone zname:                (zone name)
-      Zone zclass:               (zone class)
-      Zone ztype:                T_SOA
-      Prerequisite Section:      (see previous text)
-      Update Section:            (see previous text)
-      Additional Data Section:   (empty)
-
-   4.5. If the requestor receives a response, and the response has an
-   RCODE other than SERVFAIL or NOTIMP, then the requestor returns an
-   appropriate response to its caller.
-
-   4.6. If a response is received whose RCODE is SERVFAIL or NOTIMP, or
-   if no response is received within an implementation dependent timeout
-   period, or if an ICMP error is received indicating that the server's
-   port is unreachable, then the requestor will delete the unusable
-   server from its internal name server list and try the next one,
-   repeating until the name server list is empty.  If the requestor runs
-   out of servers to try, an appropriate error will be returned to the
-   requestor's caller.
-
-
-
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                    [Page 18]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-5 - Duplicate Detection, Ordering and Mutual Exclusion
-
-   5.1. For correct operation, mechanisms may be needed to ensure
-   idempotence, order UPDATE requests and provide mutual exclusion.  An
-   UPDATE message or response might be delivered zero times, one time,
-   or multiple times.  Datagram duplication is of particular interest
-   since it covers the case of the so-called "replay attack" where a
-   correct request is duplicated maliciously by an intruder.
-
-   5.2. Multiple UPDATE requests or responses in transit might be
-   delivered in any order, due to network topology changes or load
-   balancing, or to multipath forwarding graphs wherein several slave
-   servers all forward to the primary master.  In some cases, it might
-   be required that the earlier update not be applied after the later
-   update, where "earlier" and "later" are defined by an external time
-   base visible to some set of requestors, rather than by the order of
-   request receipt at the primary master.
-
-   5.3. A requestor can ensure transaction idempotence by explicitly
-   deleting some "marker RR" (rather than deleting the RRset of which it
-   is a part) and then adding a new "marker RR" with a different RDATA
-   field.  The Prerequisite Section should specify that the original
-   "marker RR" must be present in order for this UPDATE message to be
-   accepted by the server.
-
-   5.4. If the request is duplicated by a network error, all duplicate
-   requests will fail since only the first will find the original
-   "marker RR" present and having its known previous value.  The
-   decisions of whether to use such a "marker RR" and what RR to use are
-   left up to the application programmer, though one obvious choice is
-   the zone's SOA RR as described below.
-
-   5.5. Requestors can ensure update ordering by externally
-   synchronizing their use of successive values of the "marker RR."
-   Mutual exclusion can be addressed as a degenerate case, in that a
-   single succession of the "marker RR" is all that is needed.
-
-   5.6. A special case where update ordering and datagram duplication
-   intersect is when an RR validly changes to some new value and then
-   back to its previous value.  Without a "marker RR" as described
-   above, this sequence of updates can leave the zone in an undefined
-   state if datagrams are duplicated.
-
-   5.7. To achieve an atomic multitransaction "read-modify-write" cycle,
-   a requestor could first retrieve the SOA RR, and build an UPDATE
-   message one of whose prerequisites was the old SOA RR.  It would then
-   specify updates that would delete this SOA RR and add a new one with
-   an incremented SOA SERIAL, along with whatever actual prerequisites
-
-
-
-Vixie, et. al.              Standards Track                    [Page 19]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   and updates were the object of the transaction.  If the transaction
-   succeeds, the requestor knows that the RRs being changed were not
-   otherwise altered by any other requestor.
-
-6 - Forwarding
-
-   When a zone slave forwards an UPDATE message upward toward the zone's
-   primary master server, it must allocate a new ID and prepare to enter
-   the role of "forwarding server," which is a requestor with respect to
-   the forward server.
-
-   6.1. The set of forward servers will be same as the set of servers
-   this zone slave would use as the source of AXFR or IXFR data.  So,
-   while the original requestor might have used the zone's NS RRset to
-   locate its update server, a forwarder always forwards toward its
-   designated zone master servers.
-
-   6.2. If the original requestor used TCP, then the TCP connection from
-   the requestor is still open and the forwarder must use TCP to forward
-   the message.  If the original requestor used UDP, the forwarder may
-   use either UDP or TCP to forward the message, at the whim of the
-   implementor.
-
-   6.3. It is reasonable for forward servers to be forwarders
-   themselves, if the AXFR dependency graph being followed is a deep one
-   involving firewalls and multiple connectivity realms.  In most cases
-   the AXFR dependency graph will be shallow and the forward server will
-   be the primary master server.
-
-   6.4. The forwarder will not respond to its requestor until it
-   receives a response from its forward server.  UPDATE transactions
-   involving forwarders are therefore time synchronized with respect to
-   the original requestor and the primary master server.
-
-   6.5. When there are multiple possible sources of AXFR data and
-   therefore multiple possible forward servers, a forwarder will use the
-   same fallback strategy with respect to connectivity or timeout errors
-   that it would use when performing an AXFR.  This is implementation
-   dependent.
-
-   6.6. When a forwarder receives a response from a forward server, it
-   copies this response into a new response message, assigns its
-   requestor's ID to that message, and sends the response back to the
-   requestor.
-
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                    [Page 20]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-7 - Design, Implementation, Operation, and Protocol Notes
-
-   Some of the principles which guided the design of this UPDATE
-   specification are as follows.  Note that these are not part of the
-   formal specification and any disagreement between this section and
-   any other section of this document should be resolved in favour of
-   the other section.
-
-   7.1. Using metavalues for CLASS is possible only because all RRs in
-   the packet are assumed to be in the same zone, and CLASS is an
-   attribute of a zone rather than of an RRset.  (It is for this reason
-   that the Zone Section is not optional.)
-
-   7.2. Since there are no data-present or data-absent errors possible
-   from processing the Update Section, any necessary data-present and
-   data- absent dependencies should be specified in the Prerequisite
-   Section.
-
-   7.3. The Additional Data Section can be used to supply a server with
-   out of zone glue that will be needed in referrals.  For example, if
-   adding a new NS RR to HOME.VIX.COM specifying a nameserver called
-   NS.AU.OZ, the A RR for NS.AU.OZ can be included in the Additional
-   Data Section.  Servers can use this information or ignore it, at the
-   discretion of the implementor.  We discourage caching this
-   information for use in subsequent DNS responses.
-
-   7.4. The Additional Data Section might be used if some of the RRs
-   later needed for Secure DNS Update are not actually zone updates, but
-   rather ancillary keys or signatures not intended to be stored in the
-   zone (as an update would be), yet necessary for validating the update
-   operation.
-
-   7.5. It is expected that in the absence of Secure DNS Update, a
-   server will only accept updates if they come from a source address
-   that has been statically configured in the server's description of a
-   primary master zone.  DHCP servers would be likely candidates for
-   inclusion in this statically configured list.
-
-   7.6. It is not possible to create a zone using this protocol, since
-   there is no provision for a slave server to be told who its master
-   servers are.  It is expected that this protocol will be extended in
-   the future to cover this case.  Therefore, at this time, the addition
-   of SOA RRs is unsupported.  For similar reasons, deletion of SOA RRs
-   is also unsupported.
-
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                    [Page 21]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   7.7. The prerequisite for specifying that a name own at least one RR
-   differs semantically from QUERY, in that QUERY would return
-   <NOERROR,ANCOUNT=0> rather than NXDOMAIN if queried for an RRset at
-   this name, while UPDATE's prerequisite condition [Section 2.4.4]
-   would NOT be satisfied.
-
-   7.8. It is possible for a UDP response to be lost in transit and for
-   a request to be retried due to a timeout condition.  In this case an
-   UPDATE that was successful the first time it was received by the
-   primary master might ultimately appear to have failed when the
-   response to a duplicate request is finally received by the requestor.
-   (This is because the original prerequisites may no longer be
-   satisfied after the update has been applied.)  For this reason,
-   requestors who require an accurate response code must use TCP.
-
-   7.9. Because a requestor who requires an accurate response code will
-   initiate their UPDATE transaction using TCP, a forwarder who receives
-   a request via TCP must forward it using TCP.
-
-   7.10. Deferral of SOA SERIAL autoincrements is made possible so that
-   serial numbers can be conserved and wraparound at 2**32 can be made
-   an infrequent occurance.  Visible (to DNS clients) SOA SERIALs need
-   to differ if the zone differs.  Note that the Authority Section SOA
-   in a QUERY response is a form of visibility, for the purposes of this
-   prerequisite.
-
-   7.11. A zone's SOA SERIAL should never be set to zero (0) due to
-   interoperability problems with some older but widely installed
-   implementations of DNS.  When incrementing an SOA SERIAL, if the
-   result of the increment is zero (0) (as will be true when wrapping
-   around 2**32), it is necessary to increment it again or set it to one
-   (1).  See [RFC1982] for more detail on this subject.
-
-   7.12. Due to the TTL minimalization necessary when caching an RRset,
-   it is recommended that all TTLs in an RRset be set to the same value.
-   While the DNS Message Format permits variant TTLs to exist in the
-   same RRset, and this variance can exist inside a zone, such variance
-   will have counterintuitive results and its use is discouraged.
-
-   7.13. Zone cut management presents some obscure corner cases to the
-   add and delete operations in the Update Section.  It is possible to
-   delete an NS RR as long as it is not the last NS RR at the root of a
-   zone.  If deleting all RRs from a name, SOA and NS RRs at the root of
-   a zone are unaffected.  If deleting RRsets, it is not possible to
-   delete either SOA or NS RRsets at the top of a zone.  An attempt to
-   add an SOA will be treated as a replace operation if an SOA already
-   exists, or as a no-op if the SOA would be new.
-
-
-
-
-Vixie, et. al.              Standards Track                    [Page 22]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   7.14. No semantic checking is required in the primary master server
-   when adding new RRs.  Therefore a requestor can cause CNAME or NS or
-   any other kind of RR to be added even if their target name does not
-   exist or does not have the proper RRsets to make the original RR
-   useful.  Primary master servers that DO implement this kind of
-   checking should take great care to avoid out-of-zone dependencies
-   (whose veracity cannot be authoritatively checked) and should
-   implement all such checking during the prescan phase.
-
-   7.15. Nonterminal or wildcard CNAMEs are not well specified by
-   [RFC1035] and their use will probably lead to unpredictable results.
-   Their use is discouraged.
-
-   7.16. Empty nonterminals (nodes with children but no RRs of their
-   own) will cause <NOERROR,ANCOUNT=0> responses to be sent in response
-   to a query of any type for that name.  There is no provision for
-   empty terminal nodes -- so if all RRs of a terminal node are deleted,
-   the name is no longer in use, and queries of any type for that name
-   will result in an NXDOMAIN response.
-
-   7.17. In a deep AXFR dependency graph, it has not historically been
-   an error for slaves to depend mutually upon each other.  This
-   configuration has been used to enable a zone to flow from the primary
-   master to all slaves even though not all slaves have continuous
-   connectivity to the primary master.  UPDATE's use of the AXFR
-   dependency graph for forwarding prohibits this kind of dependency
-   loop, since UPDATE forwarding has no loop detection analagous to the
-   SOA SERIAL pretest used by AXFR.
-
-   7.18. Previously existing names which are occluded by a new zone cut
-   are still considered part of the parent zone, for the purposes of
-   zone transfers, even though queries for such names will be referred
-   to the new subzone's servers.  If a zone cut is removed, all parent
-   zone names that were occluded by it will again become visible to
-   queries.  (This is a clarification of [RFC1034].)
-
-   7.19. If a server is authoritative for both a zone and its child,
-   then queries for names at the zone cut between them will be answered
-   authoritatively using only data from the child zone.  (This is a
-   clarification of [RFC1034].)
-
-
-
-
-
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                    [Page 23]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   7.20. Update ordering using the SOA RR is problematic since there is
-   no way to know which of a zone's NS RRs represents the primary
-   master, and the zone slaves can be out of date if their SOA.REFRESH
-   timers have not elapsed since the last time the zone was changed on
-   the primary master.  We recommend that a zone needing ordered updates
-   use only servers which implement NOTIFY (see [RFC1996]) and IXFR (see
-   [RFC1995]), and that a client receiving a prerequisite error while
-   attempting an ordered update simply retry after a random delay period
-   to allow the zone to settle.
-
-8 - Security Considerations
-
-   8.1. In the absence of [RFC2137] or equivilent technology, the
-   protocol described by this document makes it possible for anyone who
-   can reach an authoritative name server to alter the contents of any
-   zones on that server.  This is a serious increase in vulnerability
-   from the current technology.  Therefore it is very strongly
-   recommended that the protocols described in this document not be used
-   without [RFC2137] or other equivalently strong security measures,
-   e.g. IPsec.
-
-   8.2. A denial of service attack can be launched by flooding an update
-   forwarder with TCP sessions containing updates that the primary
-   master server will ultimately refuse due to permission problems.
-   This arises due to the requirement that an update forwarder receiving
-   a request via TCP use a synchronous TCP session for its forwarding
-   operation.  The connection management mechanisms of [RFC1035 4.2.2]
-   are sufficient to prevent large scale damage from such an attack, but
-   not to prevent some queries from going unanswered during the attack.
-
-Acknowledgements
-
-   We would like to thank the IETF DNSIND working group for their input
-   and assistance, in particular, Rob Austein, Randy Bush, Donald
-   Eastlake, Masataka Ohta, Mark Andrews, and Robert Elz.  Special
-   thanks to Bill Simpson, Ken Wallich and Bob Halley for reviewing this
-   document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                    [Page 24]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-References
-
-   [RFC1035]
-      Mockapetris, P., "Domain Names - Implementation and
-      Specification", STD 13, RFC 1035, USC/Information Sciences
-      Institute, November 1987.
-
-   [RFC1982]
-      Elz, R., "Serial Number Arithmetic", RFC 1982, University of
-      Melbourne, August 1996.
-
-   [RFC1995]
-      Ohta, M., "Incremental Zone Transfer", RFC 1995, Tokyo Institute
-      of Technology, August 1996.
-
-   [RFC1996]
-      Vixie, P., "A Mechanism for Prompt Notification of Zone Changes",
-      RFC 1996, Internet Software Consortium, August 1996.
-
-   [RFC2065]
-      Eastlake, D., and C. Kaufman, "Domain Name System Protocol
-      Security Extensions", RFC 2065, January 1997.
-
-   [RFC2137]
-      Eastlake, D., "Secure Domain Name System Dynamic Update", RFC
-      2137, April 1997.
-
-Authors' Addresses
-
-   Yakov Rekhter
-   Cisco Systems
-   170 West Tasman Drive
-   San Jose, CA 95134-1706
-
-   Phone: +1 914 528 0090
-   EMail: yakov@cisco.com
-
-
-   Susan Thomson
-   Bellcore
-   445 South Street
-   Morristown, NJ 07960
-
-   Phone: +1 201 829 4514
-   EMail: set@thumper.bellcore.com
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                    [Page 25]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   Jim Bound
-   Digital Equipment Corp.
-   110 Spitbrook Rd ZK3-3/U14
-   Nashua, NH 03062-2698
-
-   Phone: +1 603 881 0400
-   EMail: bound@zk3.dec.com
-
-
-   Paul Vixie
-   Internet Software Consortium
-   Star Route Box 159A
-   Woodside, CA 94062
-
-   Phone: +1 415 747 0204
-   EMail: paul@vix.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                    [Page 26]
-
-
diff --git a/contrib/bind9/doc/rfc/rfc2137.txt b/contrib/bind9/doc/rfc/rfc2137.txt
deleted file mode 100644
index ceb3613..0000000
--- a/contrib/bind9/doc/rfc/rfc2137.txt
+++ /dev/null
@@ -1,619 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                    D. Eastlake 3rd
-Request for Comments: 2137                               CyberCash, Inc.
-Updates: 1035                                                 April 1997
-Category: Standards Track
-
-
-                Secure Domain Name System Dynamic Update
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Abstract
-
-   Domain Name System (DNS) protocol extensions have been defined to
-   authenticate the data in DNS and provide key distribution services
-   [RFC2065].  DNS Dynamic Update operations have also been defined
-   [RFC2136], but without a detailed description of security for the
-   update operation.  This memo describes how to use DNSSEC digital
-   signatures covering requests and data to secure updates and restrict
-   updates to those authorized to perform them as indicated by the
-   updater's possession of cryptographic keys.
-
-Acknowledgements
-
-   The contributions of the following persons (who are listed in
-   alphabetic order) to this memo are gratefully acknowledged:
-
-         Olafur Gudmundsson (ogud@tis.com>
-         Charlie Kaufman <Charlie_Kaufman@iris.com>
-         Stuart Kwan <skwan@microsoft.com>
-         Edward Lewis <lewis@tis.com>
-
-Table of Contents
-
-      1. Introduction............................................2
-      1.1 Overview of DNS Dynamic Update.........................2
-      1.2 Overview of DNS Security...............................2
-      2. Two Basic Modes.........................................3
-      3. Keys....................................................5
-      3.1 Update Keys............................................6
-      3.1.1 Update Key Name Scope................................6
-      3.1.2 Update Key Class Scope...............................6
-      3.1.3 Update Key Signatory Field...........................6
-
-
-
-Eastlake                    Standards Track                     [Page 1]
-
-RFC 2137                         SDNSDU                       April 1997
-
-
-      3.2 Zone Keys and Update Modes.............................8
-      3.3 Wildcard Key Punch Through.............................9
-      4. Update Signatures.......................................9
-      4.1 Update Request Signatures..............................9
-      4.2 Update Data Signatures................................10
-      5. Security Considerations................................10
-      References................................................10
-      Author's Address..........................................11
-
-1. Introduction
-
-   Dynamic update operations have been defined for the Domain Name
-   System (DNS) in RFC 2136, but without a detailed description of
-   security for those updates.  Means of securing the DNS and using it
-   for key distribution have been defined in RFC 2065.
-
-   This memo proposes techniques based on the defined DNS security
-   mechanisms to authenticate DNS updates.
-
-   Familiarity with the DNS system [RFC 1034, 1035] is assumed.
-   Familiarity with the DNS security and dynamic update proposals will
-   be helpful.
-
-1.1 Overview of DNS Dynamic Update
-
-   DNS dynamic update defines a new DNS opcode, new DNS request and
-   response structure if that opcode is used, and new error codes.  An
-   update can specify complex combinations of deletion and insertion
-   (with or without pre-existence testing) of resource records (RRs)
-   with one or more owner names; however, all testing and changes for
-   any particular DNS update request are restricted to a single zone.
-   Updates occur at the primary server for a zone.
-
-   The primary server for a secure dynamic zone must increment the zone
-   SOA serial number when an update occurs or the next time the SOA is
-   retrieved if one or more updates have occurred since the previous SOA
-   retrieval and the updates themselves did not update the SOA.
-
-1.2 Overview of DNS Security
-
-   DNS security authenticates data in the DNS by also storing digital
-   signatures in the DNS as SIG resource records (RRs).  A SIG RR
-   provides a digital signature on the set of all RRs with the same
-   owner name and class as the SIG and whose type is the type covered by
-   the SIG.  The SIG RR cryptographically binds the covered RR set to
-   the signer, time signed, signature expiration date, etc.  There are
-   one or more keys associated with every secure zone and all data in
-   the secure zone is signed either by a zone key or by a dynamic update
-
-
-
-Eastlake                    Standards Track                     [Page 2]
-
-RFC 2137                         SDNSDU                       April 1997
-
-
-   key tracing its authority to a zone key.
-
-   DNS security also defines transaction SIGs and request SIGs.
-   Transaction SIGs appear at the end of a response.  Transaction SIGs
-   authenticate the response and bind it to the corresponding request
-   with the key of the host where the responding DNS server is.  Request
-   SIGs appear at the end of a request and authenticate the request with
-   the key of the submitting entity.
-
-   Request SIGs are the primary means of authenticating update requests.
-
-   DNS security also permits the storage of public keys in the DNS via
-   KEY RRs.  These KEY RRs are also, of course, authenticated by SIG
-   RRs.  KEY RRs for zones are stored in their superzone and subzone
-   servers, if any, so that the secure DNS tree of zones can be
-   traversed by a security aware resolver.
-
-2. Two Basic Modes
-
-   A dynamic secure zone is any secure DNS zone containing one or more
-   KEY RRs that can authorize dynamic updates, i.e., entity or user KEY
-   RRs with the signatory field non-zero, and whose zone KEY RR
-   signatory field indicates that updates are implemented. There are two
-   basic modes of dynamic secure zone which relate to the update
-   strategy, mode A and mode B.  A summary comparison table is given
-   below and then each mode is described.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 3]
-
-RFC 2137                         SDNSDU                       April 1997
-
-
-                   SUMMARY OF DYNAMIC SECURE ZONE MODES
-
-   CRITERIA:                |   MODE A           |   MODE B
-   =========================+====================+===================
-   Definition:              | Zone Key Off line  | Zone Key On line
-   =========================+====================+===================
-   Server Workload          |   Low              |   High
-   -------------------------+--------------------+-------------------
-   Static Data Security     |   Very High        |   Medium-High
-   -------------------------+--------------------+-------------------
-   Dynamic Data Security    |   Medium           |   Medium-High
-   -------------------------+--------------------+-------------------
-   Key Restrictions         |   Fine grain       |   Coarse grain
-   -------------------------+--------------------+-------------------
-   Dynamic Data Temporality |   Transient        |   Permanent
-   -------------------------+--------------------+-------------------
-   Dynamic Key Rollover     |   No               |   Yes
-   -------------------------+--------------------+-------------------
-
-   For mode A, the zone owner key and static zone master file are always
-   kept off-line for maximum security of the static zone contents.
-
-   As a consequence, any dynamicly added or changed RRs are signed in
-   the secure zone by their authorizing dynamic update key and they are
-   backed up, along with this SIG RR, in a separate online dynamic
-   master file.  In this type of zone, server computation is minimized
-   since the server need only check signatures on the update data and
-   request, which have already been signed by the updater, generally a
-   much faster operation than signing data.  However, the AXFR SIG and
-   NXT RRs which covers the zone under the zone key will not cover
-   dynamically added data.  Thus, for type A dynamic secure zones, zone
-   transfer security is not automatically provided for dynamically added
-   RRs, where they could be omitted, and authentication is not provided
-   for the server denial of the existence of a dynamically added type.
-   Because the dynamicly added RRs retain their update KEY signed SIG,
-   finer grained control of updates can be implemented via bits in the
-   KEY RR signatory field.  Because dynamic data is only stored in the
-   online dynamic master file and only authenticated by dynamic keys
-   which expire, updates are transient in nature.  Key rollover for an
-   entity that can authorize dynamic updates is more cumbersome since
-   the authority of their key must be traceable to a zone key and so, in
-   general, they must securely communicate a new key to the zone
-   authority for manual transfer to the off line static master file.
-   NOTE: for this mode the zone SOA must be signed by a dynamic update
-   key and that private key must be kept on line so that the SOA can be
-   changed for updates.
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 4]
-
-RFC 2137                         SDNSDU                       April 1997
-
-
-   For mode B, the zone owner key and master file are kept on-line at
-   the zone primary server. When authenticated updates succeed, SIGs
-   under the zone key for the resulting data (including the possible NXT
-   type bit map changes) are calculated and these SIG (and possible NXT)
-   changes are entered into the zone and the unified on-line master
-   file.  (The zone transfer AXFR SIG may be recalculated for each
-   update or on demand when a zone transfer is requested and it is out
-   of date.)
-
-   As a consequence, this mode requires considerably more computational
-   effort on the part of the server as the public/private keys are
-   generally arranged so that signing (calculating a SIG) is more effort
-   than verifying a signature.  The security of static data in the zone
-   is decreased because the ultimate state of the static data being
-   served and the ultimate zone authority private key are all on-line on
-   the net.  This means that if the primary server is subverted, false
-   data could be authenticated to secondaries and other
-   servers/resolvers.  On the other hand, this mode of operation means
-   that data added dynamically is more secure than in mode A.  Dynamic
-   data will be covered by the AXFR SIG and thus always protected during
-   zone transfers and will be included in NXT RRs so that it can be
-   falsely denied by a server only to the same extent that static data
-   can (i.e., if it is within a wild card scope). Because the zone key
-   is used to sign all the zone data, the information as to who
-   originated the current state of dynamic RR sets is lost, making
-   unavailable the effects of some of the update control bits in the KEY
-   RR signatory field.  In addition, the incorporation of the updates
-   into the primary master file and their authentication by the zone key
-   makes then permanent in nature.  Maintaining the zone key on-line
-   also means that dynamic update keys which are signed by the zone key
-   can be dynamically updated since the zone key is available to
-   dynamically sign new values.
-
-   NOTE:  The Mode A / Mode B distinction only effects the validation
-   and performance of update requests.  It has no effect on retrievals.
-   One reasonable operational scheme may be to keep a mostly static main
-   zone operating in Mode A and have one or more dynamic subzones
-   operating in Mode B.
-
-3. Keys
-
-   Dynamic update requests depend on update keys as described in section
-   3.1 below.  In addition, the zone secure dynamic update mode and
-   availability of some options is indicated in the zone key.  Finally,
-   a special rule is used in searching for KEYs to validate updates as
-   described in section 3.3.
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 5]
-
-RFC 2137                         SDNSDU                       April 1997
-
-
-3.1 Update Keys
-
-   All update requests to a secure zone must include signatures by one
-   or more key(s) that together can authorize that update.  In order for
-   the Domain Name System (DNS) server receiving the request to confirm
-   this, the key or keys must be available to and authenticated by that
-   server as a specially flagged KEY Resource Record.
-
-   The scope of authority of such keys is indicated by their KEY RR
-   owner name, class, and signatory field flags as described below. In
-   addition, such KEY RRs must be entity or user keys and not have the
-   authentication use prohibited bit on.  All parts of the actual update
-   must be within the scope of at least one of the keys used for a
-   request SIG on the update request as described in section 4.
-
-3.1.1 Update Key Name Scope
-
-   The owner name of any update authorizing KEY RR must (1) be the same
-   as the owner name of any RRs being added or deleted or (2) a wildcard
-   name including within its extended scope (see section 3.3) the name
-   of any RRs being added or deleted and those RRs must be in the same
-   zone.
-
-3.1.2 Update Key Class Scope
-
-   The class of any update authorizing KEY RR must be the same as the
-   class of any RR's being added or deleted.
-
-3.1.3 Update Key Signatory Field
-
-   The four bit "signatory field" (see RFC 2065) of any update
-   authorizing KEY RR must be non-zero.  The bits have the meanings
-   described below for non-zone keys (see section 3.2 for zone type
-   keys).
-
-                    UPDATE KEY RR SIGNATORY FIELD BITS
-
-         0           1           2           3
-   +-----------+-----------+-----------+-----------+
-   |   zone    |  strong   |  unique   |  general  |
-   +-----------+-----------+-----------+-----------+
-
-   Bit 0, zone control - If nonzero, this key is authorized to attach,
-        detach, and move zones by creating and deleting NS, glue A, and
-        zone KEY RR(s).  If zero, the key can not authorize any update
-        that would effect such RRs.  This bit is meaningful for both
-        type A and type B dynamic secure zones.
-
-
-
-
-Eastlake                    Standards Track                     [Page 6]
-
-RFC 2137                         SDNSDU                       April 1997
-
-
-        NOTE:  do not confuse the "zone" signatory field bit with the
-        "zone" key type bit.
-
-   Bit 1, strong update - If nonzero, this key is authorized to add and
-        delete RRs even if there are other RRs with the same owner name
-        and class that are authenticated by a SIG signed with a
-        different dynamic update KEY. If zero, the key can only
-        authorize updates where any existing RRs of the same owner and
-        class are authenticated by a SIG using the same key.  This bit
-        is meaningful only for type A dynamic zones and is ignored in
-        type B dynamic zones.
-
-        Keeping this bit zero on multiple KEY RRs with the same or
-        nested wild card owner names permits multiple entities to exist
-        that can create and delete names but can not effect RRs with
-        different owner names from any they created.  In effect, this
-        creates two levels of dynamic update key, strong and weak, where
-        weak keys are limited in interfering with each other but a
-        strong key can interfere with any weak keys or other strong
-        keys.
-
-   Bit 2, unique name update - If nonzero, this key is authorized to add
-        and update RRs for only a single owner name.  If there already
-        exist RRs with one or more names signed by this key, they may be
-        updated but no new name created until the number of existing
-        names is reduced to zero.  This bit is meaningful only for mode
-        A dynamic zones and is ignored in mode B dynamic zones. This bit
-        is meaningful only if the owner name is a wildcard.  (Any
-        dynamic update KEY with a non-wildcard name is, in effect, a
-        unique name update key.)
-
-        This bit can be used to restrict a KEY from flooding a zone with
-        new names.  In conjunction with a local administratively imposed
-        limit on the number of dynamic RRs with a particular name, it
-        can completely restrict a KEY from flooding a zone with RRs.
-
-   Bit 3, general update - The general update signatory field bit has no
-        special meaning.  If the other three bits are all zero, it must
-        be one so that the field is non-zero to designate that the key
-        is an update key.  The meaning of all values of the signatory
-        field with the general bit and one or more other signatory field
-        bits on is reserved.
-
-   All the signatory bit update authorizations described above only
-   apply if the update is within the name and class scope as per
-   sections 3.1.1 and 3.1.2.
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 7]
-
-RFC 2137                         SDNSDU                       April 1997
-
-
-3.2 Zone Keys and Update Modes
-
-   Zone type keys are automatically authorized to sign anything in their
-   zone, of course, regardless of the value of their signatory field.
-   For zone keys, the signatory field bits have different means than
-   they they do for update keys, as shown below.  The signatory field
-   MUST be zero if dynamic update is not supported for a zone and MUST
-   be non-zero if it is.
-
-                     ZONE KEY RR SIGNATORY FIELD BITS
-
-                  0           1           2           3
-            +-----------+-----------+-----------+-----------+
-            |   mode    |  strong   |  unique   |  general  |
-            +-----------+-----------+-----------+-----------+
-
-   Bit 0, mode - This bit indicates the update mode for this zone.  Zero
-        indicates mode A while a one indicates mode B.
-
-   Bit 1, strong update - If nonzero, this indicates that the "strong"
-        key feature described in section 3.1.3 above is implemented and
-        enabled for this secure zone.  If zero, the feature is not
-        available.  Has no effect if the zone is a mode B secure update
-        zone.
-
-   Bit 2, unique name update - If nonzero, this indicates that the
-        "unique name" feature described in section 3.1.3 above is
-        implemented and enabled for this secure zone.  If zero, this
-        feature is not available.  Has no effect if the zone is a mode B
-        secure update zone.
-
-   Bit 3, general - This bit has no special meeting.  If dynamic update
-        for a zone is supported and the other bits in the zone key
-        signatory field are zero, it must be a one.  The meaning of zone
-        keys where the signatory field has the general bit and one or
-        more other bits on is reserved.
-
-   If there are multiple dynamic update KEY RRs for a zone and zone
-   policy is in transition, they might have different non-zero signatory
-   fields.  In that case, strong and unique name restrictions must be
-   enforced as long as there is a non-expired zone key being advertised
-   that indicates mode A with the strong or unique name bit on
-   respectively.  Mode B updates MUST be supported as long as there is a
-   non-expired zone key that indicates mode B.  Mode A updates may be
-   treated as mode B updates at server option if non-expired zone keys
-   indicate that both are supported.
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 8]
-
-RFC 2137                         SDNSDU                       April 1997
-
-
-   A server that will be executing update operations on a zone, that is,
-   the primary master server, MUST not advertize a zone key that will
-   attract requests for a mode or features that it can not support.
-
-3.3 Wildcard Key Punch Through
-
-   Just as a zone key is valid throughout the entire zone, update keys
-   with wildcard names are valid throughout their extended scope, within
-   the zone. That is, they remain valid for any name that would match
-   them, even existing specific names within their apparent scope.
-
-   If this were not so, then whenever a name within a wildcard scope was
-   created by dynamic update, it would be necessary to first create a
-   copy of the KEY RR with this name, because otherwise the existence of
-   the more specific name would hide the authorizing KEY RR and would
-   make later updates impossible.  An updater could create such a KEY RR
-   but could not zone sign it with their authorizing signer.  They would
-   have to sign it with the same key using the wildcard name as signer.
-   Thus in creating, for example, one hundred type A RRs authorized by a
-   *.1.1.1.in-addr.arpa. KEY RR, without key punch through 100 As, 100
-   KEYs, and 200 SIGs would have to be created as opposed to merely 100
-   As and 100 SIGs with key punch through.
-
-4. Update Signatures
-
-   Two kinds of signatures can appear in updates.  Request signatures,
-   which are always required, cover the entire request and authenticate
-   the DNS header, including opcode, counts, etc., as well as the data.
-   Data signatures, on the other hand, appear only among the RRs to be
-   added and are only required for mode A operation.  These two types of
-   signatures are described further below.
-
-4.1 Update Request Signatures
-
-   An update can effect multiple owner names in a zone.  It may be that
-   these different names are covered by different dynamic update keys.
-   For every owner name effected, the updater must know a private key
-   valid for that name (and the zone's class) and must prove this by
-   appending request SIG RRs under each such key.
-
-   As specified in RFC 2065, a request signature is a SIG RR occurring
-   at the end of a request with a type covered field of zero.  For an
-   update, request signatures occur in the Additional information
-   section.  Each request SIG signs the entire request, including DNS
-   header, but excluding any other request SIG(s) and with the ARCOUNT
-   in the DNS header set to what it wold be without the request SIGs.
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 9]
-
-RFC 2137                         SDNSDU                       April 1997
-
-
-4.2 Update Data Signatures
-
-   Mode A dynamic secure zones require that the update requester provide
-   SIG RRs that will authenticate the after update state of all RR sets
-   that are changed by the update and are non-empty after the update.
-   These SIG RRs appear in the request as RRs to be added and the
-   request must delete any previous data SIG RRs that are invalidated by
-   the request.
-
-   In Mode B dynamic secure zones, all zone data is authenticated by
-   zone key SIG RRs.  In this case, data signatures need not be included
-   with the update.  A resolver can determine which mode an updatable
-   secure zone is using by examining the signatory field bits of the
-   zone KEY RR (see section 3.2).
-
-5. Security Considerations
-
-   Any zone permitting dynamic updates is inherently less secure than a
-   static secure zone maintained off line as recommended in RFC 2065. If
-   nothing else, secure dynamic update requires on line change to and
-   re-signing of the zone SOA resource record (RR) to increase the SOA
-   serial number.  This means that compromise of the primary server host
-   could lead to arbitrary serial number changes.
-
-   Isolation of dynamic RRs to separate zones from those holding most
-   static RRs can limit the damage that could occur from breach of a
-   dynamic zone's security.
-
-References
-
-   [RFC2065] Eastlake, D., and C. Kaufman, "Domain Name System Security
-   Extensions", RFC 2065, CyberCash, Iris, January 1997.
-
-   [RFC2136] Vixie, P., Editor, Thomson, T., Rekhter, Y., and J. Bound,
-   "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
-   April 1997.
-
-   [RFC1035] Mockapetris, P., "Domain Names - Implementation and
-   Specifications", STD 13, RFC 1035, November 1987.
-
-   [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
-   STD 13, RFC 1034, November 1987.
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 10]
-
-RFC 2137                         SDNSDU                       April 1997
-
-
-Author's Address
-
-   Donald E. Eastlake, 3rd
-   CyberCash, Inc.
-   318 Acton Street
-   Carlisle, MA 01741 USA
-
-   Phone:   +1 508-287-4877
-            +1 508-371-7148 (fax)
-            +1 703-620-4200 (main office, Reston, Virginia, USA)
-   EMail:   dee@cybercash.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 11]
-
diff --git a/contrib/bind9/doc/rfc/rfc2163.txt b/contrib/bind9/doc/rfc/rfc2163.txt
deleted file mode 100644
index 00fcee7..0000000
--- a/contrib/bind9/doc/rfc/rfc2163.txt
+++ /dev/null
@@ -1,1459 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                       C. Allocchio
-Request for Comments: 2163                                    GARR-Italy
-Obsoletes: 1664                                             January 1998
-Category: Standards Track
-
-
-                  Using the Internet DNS to Distribute
-            MIXER Conformant Global Address Mapping (MCGAM)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-Abstract
-
-   This memo is the complete technical specification to store in the
-   Internet Domain Name System (DNS) the mapping information (MCGAM)
-   needed by MIXER conformant e-mail gateways and other tools to map
-   RFC822 domain names into X.400 O/R names and vice versa.  Mapping
-   information can be managed in a distributed rather than a centralised
-   way. Organizations can publish their MIXER mapping or preferred
-   gateway routing information using just local resources (their local
-   DNS server), avoiding the need for a strong coordination with any
-   centralised organization. MIXER conformant gateways and tools located
-   on Internet hosts can retrieve the mapping information querying the
-   DNS instead of having fixed tables which need to be centrally updated
-   and distributed.
-
-   This memo obsoletes RFC1664. It includes the changes introduced by
-   MIXER specification with respect to RFC1327: the new 'gate1' (O/R
-   addresses to domain) table is fully supported. Full backward
-   compatibility with RFC1664 specification is mantained, too.
-
-   RFC1664 was a joint effort of IETF X400 operation working group
-   (x400ops) and TERENA (formely named "RARE") Mail and Messaging
-   working group (WG-MSG). This update was performed by the IETF MIXER
-   working group.
-
-
-
-
-
-
-Allocchio                   Standards Track                     [Page 1]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-1. Introduction
-
-   The connectivity between the Internet SMTP mail and other mail
-   services, including the Internet X.400 mail and the commercial X.400
-   service providers, is assured by the Mail eXchanger (MX) record
-   information distributed via the Internet Domain Name System (DNS). A
-   number of documents then specify in details how to convert or encode
-   addresses from/to RFC822 style to the other mail system syntax.
-   However, only conversion methods provide, via some algorithm or a set
-   of mapping rules, a smooth translation, resulting in addresses
-   indistinguishable from the native ones in both RFC822 and foreign
-   world.
-
-   MIXER describes a set of mappings (MIXER Conformant Global Address
-   Mapping - MCGAM) which will enable interworking between systems
-   operating the CCITT X.400 (1984/88/92) Recommendations and systems
-   using using the RFC822 mail protocol, or protocols derived from
-   RFC822. That document addresses conversion of services, addresses,
-   message envelopes, and message bodies between the two mail systems.
-   This document is concerned with one aspect of MIXER: the mechanism
-   for mapping between X.400 O/R addresses and RFC822 domain names. As
-   described in Appendix F of MIXER, implementation of the mappings
-   requires a database which maps between X.400 O/R addresses and domain
-   names; in RFC1327 this database was statically defined.
-
-   The original approach in RFC1327 required many efforts to maintain
-   the correct mapping: all the gateways needed to get coherent tables
-   to apply the same mappings, the conversion tables had to be
-   distributed among all the operational gateways, and also every update
-   needed to be distributed.
-
-   The concept of mapping rules distribution and use has been revised in
-   the new MIXER specification, introducing the concept of MIXER
-   Conformant Global Address Mapping (MCGAM). A MCGAM does not need to
-   be globally installed by any MIXER conformant gateway in the world
-   any more. However MIXER requires now efficient methods to publish its
-   MCGAM.
-
-   Static tables are one of the possible methods to publish MCGAM.
-   However this static mechanism requires quite a long time to be spent
-   modifying and distributing the information, putting heavy constraints
-   on the time schedule of every update.  In fact it does not appear
-   efficient compared to the Internet Domain Name Service (DNS).  More
-   over it does not look feasible to distribute the database to a large
-   number of other useful applications, like local address converters,
-   e-mail User Agents or any other tool requiring the mapping rules to
-   produce correct results.
-
-
-
-
-Allocchio                   Standards Track                     [Page 2]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   Two much more efficient methods are proposed by MIXER for publication
-   of MCGAM: the Internet DNS and X.500. This memo is the complete
-   technical specification for publishing MCGAM via Internet DNS.
-
-   A first proposal to use the Internet DNS to store, retrieve and
-   maintain those mappings was introduced by two of the authors of
-   RFC1664 (B. Cole and R. Hagens) adopting two new DNS resource record
-   (RR)  types: TO-X400 and TO-822. This proposal now adopts a more
-   complete strategy, and requires one new RR only. The distribution of
-   MCGAMs via DNS is in fact an important service for the whole Internet
-   community: it completes the information given by MX resource record
-   and it allows to produce clean addresses when messages are exchanged
-   among the Internet RFC822 world and the X.400 one (both Internet and
-   Public X.400 service providers).
-
-   A first experiment in using the DNS without expanding the current set
-   of RR and using available ones was deployed by some of the authors of
-   RFC1664 at the time of its development. The existing PTR resource
-   records were used to store the mapping rules, and a new DNS tree was
-   created under the ".it" top level domain. The result of the
-   experiment was positive, and a few test applications ran under this
-   provisional set up. This test was also very useful in order to define
-   a possible migration strategy during the deployment of the new DNS
-   containing the new RR. The Internet DNS nameservers wishing to
-   provide this mapping information need in fact to be modified to
-   support the new RR type, and in the real Internet, due to the large
-   number of different implementations, this takes some time.
-
-   The basic idea is to adopt a new DNS RR to store the mapping
-   information. The RFC822 to X.400 mapping rules (including the so
-   called 'gate2' rules) will be stored in the ordinary DNS tree, while
-   the definition of a new branch of the name space defined under each
-   national top level domain is envisaged in order to contain the X.400
-   to RFC822 mappings ('table1' and 'gate1'). A "two-way" mapping
-   resolution schema is thus fully implemented.
-
-   The creation of the new domain name space representing the X.400 O/R
-   names structure also provides the chance to use the DNS to distribute
-   dynamically other X.400 related information, thus solving other
-   efficiency problems currently affecting the X.400 MHS service.
-
-   In this paper we will adopt the MCGAM syntax, showing how it can be
-   stored into the Internet DNS.
-
-
-
-
-
-
-
-
-Allocchio                   Standards Track                     [Page 3]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-1.1 Definitions syntax
-
-   The definitions in this document is given in BNF-like syntax, using
-   the following conventions:
-
-      |   means choice
-      \   is used for continuation of a definition over several lines
-      []  means optional
-      {}  means repeated one or more times
-
-   The definitions, however, are detailed only until a certain level,
-   and below it self-explaining character text strings will be used.
-
-2. Motivation
-
-   Implementations of MIXER gateways require that a database store
-   address mapping information for X.400 and RFC822. This information
-   must be made available (published) to all MIXER gateways. In the
-   Internet community, the DNS has proven to be a practical mean for
-   providing a distributed name service. Advantages of using a DNS based
-   system over a table based approach for mapping between O/R addresses
-   and domain names are:
-
-     - It avoids fetching and storing of entire mapping tables by every
-       host that wishes to implement MIXER gateways and/or tools
-
-     - Modifications to the DNS based mapping information can be made
-       available in a more timely manner than with a table driven
-       approach.
-
-     - It allows full authority delegation, in agreement with the
-       Internet regionalization process.
-
-     - Table management is not necessarily required for DNS-based
-       MIXER gateways.
-
-     - One can determine the mappings in use by a remote gateway by
-       querying the DNS (remote debugging).
-
-   Also many other tools, like address converters and User Agents can
-   take advantage of the real-time availability of MIXER tables,
-   allowing a much easier maintenance of the information.
-
-3. The domain space for X.400 O/R name addresses
-
-   Usual domain names (the ones normally used as the global part of an
-   RFC822 e-mail address) and their associated information, i.e., host
-   IP addresses, mail exchanger names, etc., are stored in the DNS as a
-
-
-
-Allocchio                   Standards Track                     [Page 4]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   distributed database under a number of top-level domains. Some top-
-   level domains are used for traditional categories or international
-   organisations (EDU, COM, NET, ORG, INT, MIL...). On the other hand
-   any country has its own two letter ISO country code as top-level
-   domain (FR, DE, GB, IT, RU, ...), including "US" for USA.  The
-   special top-level/second-level couple IN-ADDR.ARPA is used to store
-   the IP address to domain name relationship. This memo defines in the
-   above structure the appropriate way to locate the X.400 O/R name
-   space, thus enabling to store in DNS the MIXER mappings (MCGAMs).
-
-   The MIXER mapping information is composed by four tables:
-
-    - 'table1' and 'gate1' gives the translation from X.400 to RFC822;
-    - 'table2' and 'gate2' tables map RFC822 into X.400.
-
-   Each mapping table is composed by mapping rules, and a single mapping
-   rule is composed by a keyword (the argument of the mapping function
-   derived from the address to be translated) and a translator (the
-   mapping function parameter):
-
-                            keyword#translator#
-
-   the '#' sign is a delimiter enclosing the translator. An example:
-
-                 foo.bar.us#PRMD$foo\.bar.ADMD$intx.C$us#
-
-   Local mappings are not intended for use outside their restricted
-   environment, thus they should not be included in DNS. If local
-   mappings are used, they should be stored using static local tables,
-   exactly as local static host tables can be used with DNS.
-
-   The keyword of a 'table2' and 'gate2' table entry is a valid RFC822
-   domain; thus the usual domain name space can be used without problems
-   to store these entries.
-   On the other hand, the keyword of a 'table1' and 'gate1' entry
-   belongs to the X.400 O/R name space. The X.400 O/R name space does
-   not usually fit into the usual domain name space, although there are
-   a number of similarities; a new name structure is thus needed to
-   represent it. This new name structure contains the X.400 mail
-   domains.
-
-   To ensure the correct functioning of the DNS system, the new X.400
-   name structure must be hooked to the existing domain name space in a
-   way which respects the existing name hierarchy.
-
-   A possible solution was to create another special branch, starting
-   from the root of the DNS tree, somehow similar to the in-addr.arpa
-   tree. This idea would have required to establish a central authority
-
-
-
-Allocchio                   Standards Track                     [Page 5]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   to coordinate at international level the management of each national
-   X.400 name tree, including the X.400 public service providers. This
-   coordination problem is a heavy burden if approached globally. More
-   over the X.400 name structure is very 'country oriented': thus while
-   it requires a coordination at national level, it does not have
-   concepts like the international root. In fact the X.400 international
-   service is based  on a large number of bilateral agreements, and only
-   within some communities an international coordination service exists.
-
-   The X.400 two letter ISO country codes, however, are the same used
-   for the RFC822 country top-level domains and this gives us an
-   appropriate hook to insert the new branches. The proposal is, in
-   fact, to create under each national top level ISO country code a new
-   branch in the name space. This branch represents exactly the X.400
-   O/R name structure as defined in each single country, following the
-   ADMD, PRMD, O, OU hierarchy. A unique reserved label 'X42D' is placed
-   under each country top-level domain, and hence the national X.400
-   name space derives its own structure:
-
-                                    . (root)
-                                    |
-      +-----------------+-----------+--------+-----------------+...
-      |                 |                    |                 |
-     edu                it                   us                fr
-      |                 |                    |                 |
-  +---+---+...    +-----+-----+...     +-----+-----+...     +--+---+...
-  |       |       |     |     |        |     |     |        |      |
- ...     ...     cnr   X42D  infn      va    ca   X42D     X42D  inria
-                        |                    |     |        |
-           +------------+------------+...   ...   ...  +----+-------+...
-           |            |            |                 |            |
-    ADMD-PtPostel  ADMD-garr  ADMD-Master400        ADMD-atlas  ADMD-red
-                        |            |                 |            |
-             +----------+----+...   ...        +-------+------+... ...
-             |               |                 |              |
-         PRMD-infn       PRMD-STET        PRMD-Telecom   PRMD-Renault
-             |               |                 |              |
-            ...             ...               ...            ...
-
-
-   The creation of the X.400 new name tree at national level solves the
-   problem of the international coordination. Actually the coordination
-   problem is just moved at national level, but it thus becomes easier
-   to solve. The coordination at national level between the X.400
-   communities and the Internet world is already a requirement for the
-   creation of the national static MIXER mapping tables; the use of the
-   Internet DNS gives further motivations for this coordination.
-
-
-
-
-Allocchio                   Standards Track                     [Page 6]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   The coordination at national level also fits in the new concept of
-   MCGAM pubblication. The DNS in fact allows a step by step authority
-   distribution, up to a final complete delegation: thus organizations
-   whishing to publish their MCGAM just need to receive delegation also
-   for their branch of the new X.400 name space. A further advantage of
-   the national based solution is to allow each country to set up its
-   own X.400 name structure in DNS and to deploy its own authority
-   delegation according to its local time scale and requirements, with
-   no loss of global service in the mean time. And last, placing the new
-   X.400 name tree and coordination process at national level fits into
-   the Internet regionalization and internationalisation process, as it
-   requires local bodies to take care of local coordination problems.
-
-   The DNS name space thus contains completely the information required
-   by an e-mail gateway or tool to perform the X.400-RFC822 mapping: a
-   simple query to the nearest nameserver provides it. Moreover there is
-   no more any need to store, maintain and distribute manually any
-   mapping table. The new X.400 name space can also contain further
-   information about the X.400 community, as DNS allows for it a
-   complete set of resource records, and thus it allows further
-   developments. This set of RRs in the new X.400 name space must be
-   considered 'reserved' and thus not used until further specifications.
-
-   The construction of the new domain space trees will follow the same
-   procedures used when organising at first the already existing DNS
-   space: at first the information will be stored in a quite centralised
-   way, and distribution of authority will be gradually achieved. A
-   separate document will describe the implementation phase and the
-   methods to assure a smooth introduction of the new service.
-
-4. The new DNS resource record for MIXER mapping rules: PX
-
-   The specification of the Internet DNS (RFC1035) provides a number of
-   specific resource records (RRs) to contain specific pieces of
-   information. In particular they contain the Mail eXchanger (MX) RR
-   and the host Address (A) records which are used by the Internet SMTP
-   mailers. As we will store the RFC822 to X.400 mapping information in
-   the already existing DNS name tree, we need to define a new DNS RR in
-   order to avoid any possible clash or misuse of already existing data
-   structures. The same new RR will also be used to store the mappings
-   from X.400 to RFC822. More over the mapping information, i.e., the
-   MCGAMs, has a specific format and syntax which require an appropriate
-   data structure and processing. A further advantage of defining a new
-   RR is the ability to include flexibility for some eventual future
-   development.
-
-
-
-
-
-
-Allocchio                   Standards Track                     [Page 7]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   The definition of the new 'PX' DNS resource record is:
-
-      class:        IN   (Internet)
-
-      name:         PX   (pointer to X.400/RFC822 mapping information)
-
-      value:        26
-
-   The PX RDATA format is:
-
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-          |                  PREFERENCE                   |
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-          /                    MAP822                     /
-          /                                               /
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-          /                    MAPX400                    /
-          /                                               /
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-   where:
-
-   PREFERENCE   A 16 bit integer which specifies the preference given to
-                this RR among others at the same owner.  Lower values
-                are preferred;
-
-   MAP822       A <domain-name> element containing <rfc822-domain>, the
-                RFC822 part of the MCGAM;
-
-   MAPX400      A <domain-name> element containing the value of
-                <x400-in-domain-syntax> derived from the X.400 part of
-                the MCGAM (see sect. 4.2);
-
-   PX records cause no additional section processing. The PX RR format
-   is the usual one:
-
-             <name> [<class>] [<TTL>] <type> <RDATA>
-
-   When we store in DNS a 'table1' or a 'gate1' entry, then <name> will
-   be an X.400 mail domain name in DNS syntax (see sect. 4.2). When we
-   store a 'table2' or a 'gate2' table entry, <name> will be an RFC822
-   mail domain name, including both fully qualified DNS domains and mail
-   only domains (MX-only domains). All normal DNS conventions, like
-   default values, wildcards, abbreviations and message compression,
-   apply also for all the components of the PX RR. In particular <name>,
-   MAP822 and MAPX400, as <domain-name> elements, must have the final
-   "." (root) when they are fully qualified.
-
-
-
-
-Allocchio                   Standards Track                     [Page 8]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-4.1 Additional features of the PX resource record
-
-   The definition of the RDATA for the PX resource record, and the fact
-   that DNS allows a distinction between an exact value and a wildcard
-   match for the <name> parameter, represent an extension of the MIXER
-   specification for mapping rules. In fact, any MCGAM entry is an
-   implicit wildcard entry, i.e., the rule
-
-      net2.it#PRMD$net2.ADMD$p400.C$it#
-
-   covers any RFC822 domain ending with 'net2.it', unless more detailed
-   rules for some subdomain in 'net2.it' are present. Thus there is no
-   possibility to specify explicitly a MCGAM as an exact match only
-   rule. In DNS an entry like
-
-      *.net2.it.   IN  PX  10   net2.it.  PRMD-net2.ADMD-p400.C-it.
-
-   specify the usual wildcard match as for MIXER tables. However an
-   entry like
-
-      ab.net2.it.  IN  PX  10   ab.net2.it.  O-ab.PRMD-net2.ADMDb.C-it.
-
-   is valid only for an exact match of 'ab.net2.it' RFC822 domain.
-
-   Note also that in DNS syntax there is no '#' delimiter around MAP822
-   and MAPX400 fields: the syntax defined in sect. 4.2 in fact does not
-   allow the <blank> (ASCII decimal 32) character within these fields,
-   making unneeded the use of an explicit delimiter as required in the
-   MIXER original syntax.
-
-   Another extension to the MIXER specifications is the PREFERENCE value
-   defined as part of the PX RDATA section. This numeric value has
-   exactly the same meaning than the similar one used for the MX RR. It
-   is thus possible to specify more than one single mapping for a domain
-   (both from RFC822 to X.400 and vice versa), giving as the preference
-   order. In MIXER static tables, however, you cannot specify more than
-   one mapping per each RFC822 domain, and the same restriction apply
-   for any X.400 domain mapping to an RFC822 one.
-
-   More over, in the X.400 recommendations a note suggests than an
-   ADMD=<blank> should be reserved for some special cases. Various
-   national functional profile specifications for an X.400 MHS states
-   that if an X.400 PRMD is reachable via any of its national ADMDs,
-   independently of its actual single or multiple connectivity with
-   them, it should use ADMD=<blank> to advertise this fact. Again, if a
-   PRMD has no connections to any ADMD it should use ADMD=0 to notify
-   its status, etc. However, in most of the current real situations, the
-   ADMD service providers do not accept messages coming from their
-
-
-
-Allocchio                   Standards Track                     [Page 9]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   subscribers if they have a blank ADMD, forcing them to have their own
-   ADMD value. In such a situation there are problems in indicating
-   properly the actually working mappings for domains with multiple
-   connectivity. The PX RDATA 'PREFERENCE' extension was introduced to
-   take in consideration these problems.
-
-   However, as these extensions are not available with MIXER static
-   tables, it is strongly discouraged to use them when interworking with
-   any table based gateway or application. The extensions were in fact
-   introduced just to add more flexibility, like the PREFERENCE value,
-    or they were already implicit in the DNS mechanism, like the
-   wildcard specification. They should be used very carefully or just
-   considered 'reserved for future use'. In particular, for current use,
-   the PREFERENCE value in the PX record specification should be fixed
-   to a value of 50, and only wildcard specifications should be used
-   when specifying <name> values.
-
-4.2 The DNS syntax for an X.400 'domain'
-
-   The syntax definition of the MCGAM rules is defined in appendix F of
-   that document. However that syntax is not very human oriented and
-   contains a number of characters which have a special meaning in other
-   fields of the Internet DNS. Thus in order to avoid any possible
-   problem, especially due to some old DNS implementations still being
-   used in the Internet, we define a syntax for the X.400 part of any
-   MCGAM rules (and hence for any X.400 O/R name) which makes it
-   compatible with a <domain-name> element, i.e.,
-
-   <domain-name>    ::= <subdomain> | " "
-   <subdomain>      ::= <label> | <label> "." <subdomain>
-   <label>          ::= <alphanum>|
-                        <alphanum> {<alphanumhyphen>} <alphanum>
-   <alphanum>       ::= "0".."9" | "A".."Z" | "a".."z"
-   <alphanumhyphen> ::= "0".."9" | "A".."Z" | "a".."z" | "-"
-
-   (see RFC1035, section 2.3.1, page 8).  The legal character set for
-   <label> does not correspond to the IA5 Printablestring one used in
-   MIXER to define MCGAM rules. However a very simple "escape mechanism"
-   can be applied in order to bypass the problem. We can in fact simply
-   describe the X.400 part of a MCGAM rule format as:
-
-     <map-rule>   ::= <map-elem> | <map-elem> { "." <map-elem> }
-     <map-elem>   ::= <attr-label> "$" <attr-value>
-     <attr-label> ::= "C" | "ADMD" | "PRMD" | "O" | "OU"
-     <attr-value> ::= " " | "@" | IA5-Printablestring
-
-
-
-
-
-
-Allocchio                   Standards Track                    [Page 10]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   As you can notice <domain-name> and <map-rule> look similar, and also
-   <label> and <map-elem> look the same. If we define the correct method
-   to transform a <map-elem> into a <label> and vice versa the problem
-   to write a MCGAM rule in <domain-name> syntax is solved.
-
-   The RFC822 domain part of any MCGAM rule is of course already in
-   <domain-name> syntax, and thus remains unchanged.
-
-   In particular, in a 'table1' or 'gate1' mapping rule the 'keyword'
-   value must be converted into <x400-in-domain-syntax> (X.400 mail DNS
-   mail domain), while the 'translator' value is already a valid RFC822
-   domain.  Vice versa in a 'table2' or 'gate2' mapping rule, the
-   'translator' must be converted into <x400-in-domain-syntax>, while
-   the 'keyword' is already a valid RFC822 domain.
-
-4.2.1 IA5-Printablestring to <alphanumhyphen> mappings
-
-   The problem of unmatching IA5-Printablestring and <label> character
-   set definition is solved by a simple character mapping rule: whenever
-   an IA5 character does not belong to <alphanumhyphen>, then it is
-   mapped using its 3 digit decimal ASCII code, enclosed in hyphens. A
-   small set of special rules is also defined for the most frequent
-   cases. Moreover some frequent characters combinations used in MIXER
-   rules are also mapped as special cases.
-
-   Let's then define the following simple rules:
-
-    MCGAM rule            DNS store translation    conditions
-    -----------------------------------------------------------------
-    <attr-label>$@        <attr-label>             missing attribute
-    <attr-label>$<blank>  <attr-label>"b"          blank attribute
-    <attr-label>$xxx      <attr-label>-xxx         elsewhere
-
-   Non <alphanumhyphen> characters in <attr-value>:
-
-    MCGAM rule            DNS store translation    conditions
-    -----------------------------------------------------------------
-    -                     -h-                      hyphen
-    \.                    -d-                      quoted dot
-    <blank>               -b-                      blank
-    <non A/N character>   -<3digit-decimal>-       elsewhere
-
-   If the DNS store translation of <attr-value> happens to end with an
-   hyphen, then this last hyphen is omitted.
-
-   Let's now have some examples:
-
-
-
-
-
-Allocchio                   Standards Track                    [Page 11]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-    MCGAM rule            DNS store translation    conditions
-    -----------------------------------------------------------------
-    PRMD$@                PRMD                     missing attribute
-    ADMD$<blank>          ADMDb                    blank attribute
-    ADMD$400-net          ADMD-400-h-net           hyphen mapping
-    PRMD$UK\.BD           PRMD-UK-d-BD             quoted dot mapping
-    O$ACME Inc\.          O-ACME-b-Inc-d           blank & final hyphen
-    PRMD$main-400-a       PRMD-main-h-400-h-a      hyphen mapping
-    O$-123-b              O--h-123-h-b             hyphen mapping
-    OU$123-x              OU-123-h-x               hyphen mapping
-    PRMD$Adis+co          PRMD-Adis-043-co         3digit mapping
-
-   Thus, an X.400 part from a MCGAM like
-
-     OU$uuu.O$@.PRMD$ppp\.rrr.ADMD$aaa ddd-mmm.C$cc
-
-   translates to
-
-     OU-uuu.O.PRMD-ppp-d-rrr.ADMD-aaa-b-ddd-h-mmm.C-cc
-
-   Another example:
-
-     OU$sales dept\..O$@.PRMD$ACME.ADMD$ .C$GB
-
-   translates to
-
-     OU-sales-b-dept-d.O.PRMD-ACME.ADMDb.C-GB
-
-4.2.2 Flow chart
-
-   In order to achieve the proper DNS store translations of the X.400
-   part of a MCGAM or any other X.400 O/R name, some software tools will
-   be used. It is in fact evident that the above rules for converting
-   mapping table from MIXER to DNS format (and vice versa) are not user
-   friendly enough to think of a human made conversion.
-
-   To help in designing such tools, we describe hereunder a small flow
-   chart. The fundamental rule to be applied during translation is,
-   however, the following:
-
-      "A string must be parsed from left to right, moving appropriately
-      the pointer in order not to consider again the already translated
-      left section of the string in subsequent analysis."
-
-
-
-
-
-
-
-
-Allocchio                   Standards Track                    [Page 12]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   Flow chart 1 - Translation from MIXER to DNS format:
-
-                 parse  single attribute
-              (enclosed in "." separators)
-                           |
-            (yes)  ---  <label>$@ ?  ---  (no)
-              |                             |
-        map to <label>        (no)  <label>$<blank> ?  (yes)
-              |                 |                        |
-              |           map to <label>-        map to <label>"b"
-              |                 |                        |
-              |           map "\." to -d-                |
-              |                 |                        |
-              |           map "-" to -h-                 |
-              |                 |                        |
-              |    map non A/N char to -<3digit>-        |
-  restart     |                 |                        |
-     ^        |      remove (if any) last "-"            |
-     |        |                 |                        |
-     |        \------->     add a  "."    <--------------/
-     |                          |
-     \----------  take  next  attribute  (if  any)
-
-
-   Flow chart 2 - Translation from DNS to MIXER format:
-
-
-                parse single attribute
-            (enclosed in "." separators)
-                          |
-            (yes) ---- <label> ? ---- (no)
-              |                          |
-      map to <label>$@        (no) <label>"b" ? (yes)
-              |                 |                 |
-              |           map to <label>$    map to <label>$<blank>
-              |                 |                 |
-              |           map -d- to "\."         |
-              |                 |                 |
-              |           map -h- to "-"          |
-              |                 |                 |
-              |           map -b- to " "          |
-  restart     |                 |                 |
-     ^        |   map -<3digit>- to non A/N char  |
-     |        |                 |                 |
-     |        \-------->   add a "."   <----------/
-     |                         |
-     \------------- take next attribute (if any)
-
-
-
-
-Allocchio                   Standards Track                    [Page 13]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   Note that the above flow charts deal with the translation of the
-   attributes syntax, only.
-
-4.2.3 The Country Code convention in the <name> value.
-
-   The RFC822 domain space and the X.400 O/R address space, as said in
-   section 3, have one specific common feature: the X.400 ISO country
-   codes are the same as the RFC822 ISO top level domains for countries.
-   In the previous sections we have also defined a method to write in
-   <domain-name> syntax any X.400 domain, while in section 3 we
-   described the new name space starting at each country top level
-   domain under the X42D.cc (where 'cc' is then two letter ISO country
-   code).
-
-   The <name> value for a 'table1' or 'gate1' entry in DNS should thus
-   be derived from the X.400 domain value, translated to <domain-name>
-   syntax, adding the 'X42D.cc.' post-fix to it, i.e.,
-
-     ADMD$acme.C$fr
-
-   produces in <domain-name> syntax the key:
-
-     ADMD-acme.C-fr
-
-   which is post-fixed by 'X42D.fr.' resulting in:
-
-     ADMD-acme.C-fr.X42D.fr.
-
-   However, due to the identical encoding for X.400 country codes and
-   RFC822 country top level domains, the string 'C-fr.X42D.fr.' is
-   clearly redundant.
-
-   We thus define the 'Country Code convention' for the <name> key,
-   i.e.,
-
-     "The C-cc section of an X.400 domain in <domain-name> syntax must
-     be omitted when creating a <name> key, as it is identical to the
-     top level country code used to identify the DNS zone where the
-     information is stored".
-
-   Thus we obtain the following <name> key examples:
-
-   X.400 domain                       DNS <name> key
-   --------------------------------------------------------------------
-   ADMD$acme.C$fr                     ADMD-acme.X42D.fr.
-   PRMD$ux\.av.ADMD$ .C$gb            PRMD-ux-d-av.ADMDb.X42D.gb.
-   PRMD$ppb.ADMD$Dat 400.C$de         PRMD-ppb.ADMD-Dat-b-400.X42D.de.
-
-
-
-
-Allocchio                   Standards Track                    [Page 14]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-4.3 Creating the appropriate DNS files
-
-   Using MIXER's assumption of an asymmetric mapping between X.400 and
-   RFC822 addresses, two separate relations are required to store the
-   mapping database: MIXER 'table1' and MIXER 'table2'; thus also in DNS
-   we will maintain the two different sections, even if they will both
-   use the PX resource record. More over MIXER also specify two
-   additional tables: MIXER 'gate1' and 'gate2' tables. These additional
-   tables, however, have the same syntax rules than MIXER 'table1' and
-   'table2' respectively, and thus the same translation procedure as
-   'table1' and 'table2' will be applied; some details about the MIXER
-   'gate1' and 'gate2' tables are discussed in section 4.4.
-
-   Let's now check how to create, from an MCGAM entry, the appropriate
-   DNS entry in a DNS data file. We can again define an MCGAM entry as
-   defined in appendix F of that document as:
-
-     <x400-domain>#<rfc822-domain>#  (case A: 'table1' and 'gate1'
-     entry)
-
-   and
-
-     <rfc822-domain>#<x400-domain>#  (case B: 'table2' and 'gate2'
-     entry)
-
-   The two cases must be considered separately. Let's consider case A.
-
-    - take <x400-domain> and translate it into <domain-name> syntax,
-     obtaining <x400-in-domain-syntax>;
-    - create the <name> key from <x400-in-domain-syntax> i.e., apply
-     the Country Code convention described in sect. 4.2.3;
-    - construct the DNS PX record as:
-
-      *.<name>  IN  PX  50  <rfc822-domain>  <x400-in-domain-syntax>
-
-   Please note that within PX RDATA the <rfc822-domain> precedes the
-   <x400-in-domain-syntax> also for a 'table1' and 'gate1' entry.
-
-   an example: from the 'table1' rule
-
-     PRMD$ab.ADMD$ac.C$fr#ab.fr#
-
-   we obtain
-
-     *.PRMD-ab.ADMD-ac.X42D.fr. IN PX 50  ab.fr.  PRMD-ab.ADMD-ac.C-fr.
-
-   Note that <name>, <rfc822-domain> and <x400-in-domain-syntax> are
-   fully qualified <domain-name> elements, thus ending with a ".".
-
-
-
-Allocchio                   Standards Track                    [Page 15]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   Let's now consider case B.
-
-    - take <rfc822-domain> as <name> key;
-    - translate <x400-domain> into <x400-in-domain-syntax>;
-    - construct the DNS PX record as:
-
-     *.<name>  IN  PX  50  <rfc822-domain>  <x400-in-domain-syntax>
-
-   an example: from the 'table2' rule
-
-     ab.fr#PRMD$ab.ADMD$ac.C$fr#
-
-   we obtain
-
-     *.ab.fr.  IN  PX  50  ab.fr.  PRMD-ab.ADMD-ac.C-fr.
-
-   Again note the fully qualified <domain-name> elements.
-
-   A file containing the MIXER mapping rules and MIXER 'gate1' and
-   'gate2' table written in DNS format will look like the following
-   fictious example:
-
-     !
-     ! MIXER table 1: X.400 --> RFC822
-     !
-     *.ADMD-acme.X42D.it.               IN  PX  50  it. ADMD-acme.C-it.
-     *.PRMD-accred.ADMD-tx400.X42D.it.  IN  PX  50   \
-                                accred.it. PRMD-accred.ADMD-tx400.C-it.
-     *.O-u-h-newcity.PRMD-x4net.ADMDb.X42D.it.  IN  PX  50   \
-                       cs.ncty.it. O-u-h-newcity.PRMD-x4net.ADMDb.C-it.
-     !
-     ! MIXER table 2: RFC822 --> X.400
-     !
-     *.nrc.it.    IN  PX  50   nrc.it. PRMD-nrc.ADMD-acme.C-it.
-     *.ninp.it.   IN  PX  50   ninp.it. O.PRMD-ninp.ADMD-acme.C-it.
-     *.bd.it.     IN  PX  50   bd.it. PRMD-uk-d-bd.ADMDb.C-it.
-     !
-     ! MIXER Gate 1 Table
-     !
-     *.ADMD-XKW-h-Mail.X42D.it.         IN  PX  50   \
-                            XKW-gateway.it. ADMD-XKW-h-Mail.C-it.G.
-     *.PRMD-Super-b-Inc.ADMDb.X42D.it.  IN  PX  50   \
-                            GlobalGw.it. PRMD-Super-b-Inc.ADMDb.C-it.G.
-     !
-     ! MIXER Gate 2 Table
-     !
-     my.it.  IN PX 50  my.it. OU-int-h-gw.O.PRMD-ninp.ADMD-acme.C-it.G.
-     co.it.  IN PX 50  co.it. O-mhs-h-relay.PRMD-x4net.ADMDb.C-it.G.
-
-
-
-Allocchio                   Standards Track                    [Page 16]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   (here the "\" indicates continuation on the same line, as wrapping is
-   done only due to typographical reasons).
-
-   Note the special suffix ".G." on the right side of the 'gate1' and
-   'gate2' Tables section whose aim is described in section 4.4. The
-   corresponding MIXER tables are:
-
-     #
-     # MIXER table 1: X.400 --> RFC822
-     #
-     ADMD$acme.C$it#it#
-     PRMD$accred.ADMD$tx400.C$it#accred.it#
-     O$u-newcity.PRMD$x4net.ADMD$ .C$it#cs.ncty.it#
-     #
-     # MIXER table 2: RFC822 --> X.400
-     #
-     nrc.it#PRMD$nrc.ADMD$acme.C$it#
-     ninp.it#O.PRMD$ninp.ADMD$acme.C$it#
-     bd.it#PRMD$uk\.bd.ADMD$ .C$it#
-     #
-     # MIXER Gate 1 Table
-     #
-     ADMD$XKW-Mail.C$it#XKW-gateway.it#
-     PRMD$Super Inc.ADMD$ .C$it#GlobalGw.it#
-     #
-     # MIXER Gate 2 Table
-     #
-     my.it#OU$int-gw.O$@.PRMD$ninp.ADMD$acme.C$it#
-     co.it#O$mhs-relay.PRMD$x4net.ADMD$ .C$t#
-
-4.4 Storing the MIXER 'gate1' and 'gate2' tables
-
-   Section 4.3.4 of MIXER also specify how an address should be
-   converted between RFC822 and X.400 in case a complete mapping is
-   impossible. To allow the use of DDAs for non mappable domains, the
-   MIXER 'gate2' table is thus introduced.
-
-   In a totally similar way, when an X.400 address cannot be completely
-   converted in RFC822, section 4.3.5 of MIXER specifies how to encode
-   (LHS encoding) the address itself, pointing then to the appropriate
-   MIXER conformant gateway, indicated in the MIXER 'gate1' table.
-
-   DNS must store and distribute also these 'gate1' and 'gate2' data.
-
-   One of the major features of the DNS is the ability to distribute the
-   authority: a certain site runs the "primary" nameserver for one
-   determined sub-tree and thus it is also the only place allowed to
-   update information regarding that sub-tree. This fact allows, in our
-
-
-
-Allocchio                   Standards Track                    [Page 17]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   case, a further additional feature to the table based approach. In
-   fact we can avoid one possible ambiguity about the use of the 'gate1'
-   and 'gate2' tables (and thus of LHS and DDAs encoding).
-
-   The authority maintaining a DNS entry in the usual RFC822 domain
-   space is the only one allowed to decide if its domain should be
-   mapped using Standard Attributes (SA) syntax or Domain Defined
-   Attributes (DDA) one. If the authority decides that its RFC822 domain
-   should be mapped using SA, then the PX RDATA will be a 'table2'
-   entry, otherwise it will be a 'gate2' table entry. Thus for an RFC822
-   domain we cannot have any more two possible entries, one from 'table2
-   and another one from 'gate2' table, and the action for a gateway
-   results clearly stated.
-
-   Similarly, the authority mantaining a DNS entry in the new X.400 name
-   space is the only one allowed to decide if its X.400 domain should be
-   mapped using SA syntax or Left Hand Side (LHS) encoding. If the
-   authority decides that its X.400 domain should be mapped using SA,
-   then the PX RDATA will be a 'table1' entry, otherwise it will be a
-   'gate1' table entry. Thus also for an X.400 domain we cannot have any
-   more two possible entries, one from 'table1' and another one from
-   'gate1' table, and the action for a gateway results clearly stated.
-
-   The MIXER 'gate1' table syntax is actually identical to MIXER
-   'table1', and 'gate2' table syntax is identical to MIXER 'table2'.
-   Thus the same syntax translation rules from MIXER to DNS format can
-   be applied in both cases. However a gateway or any other application
-   must know if the answer it got from DNS contains some 'table1',
-   'table2' or some 'gate1', 'gate2' table information. This is easily
-   obtained flagging with an additional ".G." post-fix the PX RDATA
-   value when it contains a 'gate1' or 'gate2' table entry. The example
-   in section 4.3 shows clearly the result. As any X.400 O/R domain must
-   end with a country code ("C-xx" in our DNS syntax) the additional
-   ".G." creates no conflicts or ambiguities at all. This postfix must
-   obviously be removed before using the MIXER 'gate1' or 'gate2' table
-   data.
-
-5. Finding MIXER mapping information from DNS
-
-   The MIXER mapping information is stored in DNS both in the normal
-   RFC822 domain name space, and in the newly defined X.400 name space.
-   The information, stored in PX resource records, does not represent a
-   full RFC822 or X.400 O/R address: it is a template which specifies
-   the fields of the domain that are used by the mapping algorithm.
-
-   When mapping information is stored in the DNS, queries to the DNS are
-   issued whenever an iterative search through the mapping table would
-   be performed (MIXER: section 4.3.4, State I; section 4.3.5, mapping
-
-
-
-Allocchio                   Standards Track                    [Page 18]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   B). Due to the DNS search mechanism, DNS by itself returns the
-   longest possible match in the stored mapping rule with a single
-   query, thus no iteration and/or multiple queries are needed. As
-   specified in MIXER, a search of the mapping table will result in
-   either success (mapping found) or failure (query failed, mapping not
-   found).
-
-   When a DNS query is issued, a third possible result is timeout. If
-   the result is timeout, the gateway operation is delayed and then
-   retried at a later time. A result of success or failure is processed
-   according to the algorithms specified in MIXER. If a DNS error code
-   is returned, an error message should be logged and the gateway
-   operation is delayed as for timeout. These pathological situations,
-   however, should be avoided with a careful duplication and chaching
-   mechanism which DNS itself provides.
-
-   Searching the nameserver which can authoritatively solve the query is
-   automatically performed by the DNS distributed name service.
-
-5.1 A DNS query example
-
-   An MIXER mail-gateway located in the Internet, when translating
-   addresses from RFC822 to X.400, can get information about the MCGAM
-   rule asking the DNS. As an example, when translating the address
-   SUN.CCE.NRC.IT, the gateway will just query DNS for the associated PX
-   resource record. The DNS should contain a PX record like this:
-
-   *.cce.nrc.it.  IN PX 50   cce.nrc.it.  O-cce.PRMD-nrc.ADMD-acme.C-it.
-
-   The first query will return immediately the appropriate mapping rule
-   in DNS store format.
-
-   There is no ".G." at the end of the obtained PX RDATA value, thus
-   applying the syntax translation specified in paragraph 4.2 the MIXER
-   Table 2 mapping rule will be obtained.
-
-   Let's now take another example where a 'gate2' table rule is
-   returned.  If we are looking for an RFC822 domain ending with top
-   level domain "MW", and the DNS contains a PX record like this,
-
-      *.mw.   IN  PX  50  mw.  O-cce.PRMD-nrc.ADMD-acme.C-it.G.
-
-   DNS will return 'mw.' and 'O-cce.PRMD-nrc.ADMD-acme.C-it.G.', i.e., a
-   'gate2' table entry in DNS store format. Dropping the final ".G." and
-   applying the syntax translation specified in paragraph 4.2 the
-   original rule will be available. More over, the ".G." flag also tells
-   the gateway to use DDA encoding for the inquired RFC822 domain.
-
-
-
-
-Allocchio                   Standards Track                    [Page 19]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   On the other hand, translating from X.400 to RFC822 the address
-
-      C=de; ADMD=pkz; PRMD=nfc; O=top;
-
-   the mail gateway should convert the syntax according to paragraph
-   4.2, apply the 'Country code convention' described in 4.2.3 to derive
-   the appropriate DNS translation of the X.400 O/R name and then query
-   DNS for the corresponding PX resource record. The obtained record for
-   which the PX record must be queried is thus:
-
-      O-top.PRMD-nfc.ADMD-pkz.X42D.de.
-
-   The DNS could contain:
-
-      *.ADMD-pkz.X42D.de.  IN  PX  50  pkz.de.  ADMD-pkz.C-de.
-
-   Assuming that there are not more specific records in DNS, the
-   wildcard mechanism will return the MIXER 'table1' rule in encoded
-   format.
-
-   Finally, an example where a 'gate1' rule is involved. If we are
-   looking for an X.400 domain ending with ADMD=PWT400; C=US; , and the
-   DNS contains a PX record like this,
-
-      *.ADMD-PWT400.X42D.us.  IN  PX  50  intGw.com. ADMD-PWT400.C-us.G.
-
-   DNS will return 'intGw.com.' and 'ADMD-PWT400.C-us.G.', i.e., a
-   'gate1' table entry in DNS store format. Dropping the final ".G." and
-   applying the syntax translation specified in paragraph 4.2 the
-   original rule will be available. More over, the ".G." flag also tells
-   the gateway to use LHS encoding for the inquired X.400 domain.
-
-6. Administration of mapping information
-
-   The DNS, using the PX RR, is able to distribute the MCGAM rules to
-   all MIXER gateways located on the Internet. However, not all MIXER
-   gateways will be able to use the Internet DNS. It is expected that
-   some gateways in a particular management domain will conform to one
-   of the following models:
-
-     (a) Table-based, (b) DNS-based, (c) X.500-based
-
-   Table-based management domains will continue to publish their MCGAM
-   rules and retrieve the mapping tables via the International Mapping
-   Table coordinator, manually or via some automated procedures. Their
-   MCGAM information can be made available also in DNS by the
-   appropriate DNS authorities, using the same mechanism already in
-   place for MX records: if a branch has not yet in place its own DNS
-
-
-
-Allocchio                   Standards Track                    [Page 20]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   server, some higher authority in the DNS tree will provide the
-   service for it. A transition procedure similar to the one used to
-   migrate from the 'hosts.txt' tables to DNS can be applied also to the
-   deployment phase of this specification. An informational document
-   describing the implementation phase and the detailed coordination
-   procedures is expected.
-
-   Another distributed directory service which can distribute the MCGAM
-   information is X.500. Coordination with table-based domains can be
-   obtained in an identical way as for the DNS case.
-
-   Coordination of MCGAM information between DNS and X.500 is more
-   complex, as it requies some kind of uploading information between the
-   two systems. The ideal solution is a dynamic alignment mechanism
-   which transparently makes the DNS mapping information available in
-   X.500 and vice versa. Some work in this specific field is already
-   being done [see Costa] which can result in a global transparent
-   directory service, where the information is stored in DNS or in
-   X.500, but is visible completely by any of the two systems.
-
-   However we must remind that MIXER concept of MCGAM rules publication
-   is different from the old RFC1327 concept of globally distributed,
-   coordinated and unique mapping rules. In fact MIXER does not requires
-   any more for any conformant gateway or tool to know the complete set
-   of MCGAM: it only requires to use some set (eventually empty) of
-   valid MCGAM rules, published either by Tables, DNS or X.500
-   mechanisms or any combination of these methods. More over MIXER
-   specifies that also incomplete sets of MCGAM can be used, and
-   supplementary local unpublished (but valid) MCGAM can also be used.
-   As a consequence, the problem of coordination between the three
-   systems proposed by MIXER for MCGAM publication is non essential, and
-   important only for efficient operational matters. It does not in fact
-   affect the correct behaviour of MIXER conformant gateways and tools.
-
-7. Conclusion
-
-   The introduction of the new PX resource record and the definition of
-   the X.400 O/R name space in the DNS structure provide a good
-   repository for MCGAM information. The mapping information is stored
-   in the DNS tree structure so that it can be easily obtained using the
-   DNS distributed name service. At the same time the definition of the
-   appropriate DNS space for X.400 O/R names provide a repository where
-   to store and distribute some other X.400 MHS information. The use of
-   the DNS has many known advantages in storing, managing and updating
-   the information. A successful number of tests were been performed
-   under the provisional top level domain "X400.IT" when RFC1664 was
-   developed, and their results confirmed the advantages of the method.
-   Operational exeprience for over 2 years with RFC1664 specification
-
-
-
-Allocchio                   Standards Track                    [Page 21]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   confirmed the feasibility of the method, and helped identifying some
-   operational procedures to deploy the insertion of MCGAM into DNS.
-
-   Software to query the DNS and then to convert between the textual
-   representation of DNS resource records and the address format defined
-   in MIXER was developed with RFC1664. This software also allows a
-   smooth implementation and deployment period, eventually taking care
-   of the transition phase. This software can be easily used (with
-   little or null modification) also for this updated specification,
-   supporting the new 'gate1' MIXER table. DNS software implementations
-   supporting RFC1664 also supports with no modification this memo new
-   specification.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Allocchio                   Standards Track                    [Page 22]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   A further informational document describing operational and
-   implementation of the service is expected.
-
-8. Acknowledgements
-
-   We wish to thanks all those who contributed to the discussion and
-   revision of this document: many of their ideas and suggestions
-   constitute essential parts of this work. In particular thanks to Jon
-   Postel, Paul Mockapetris, Rob Austin and the whole IETF x400ops,
-   TERENA wg-msg and IETF namedroppers groups. A special mention to
-   Christian Huitema for his fundamental contribution to this work.
-
-   This document is a revision of RFC1664, edited by one of its authors
-   on behalf of the IETF MIXER working group. The current editor wishes
-   to thank here also the authors of RFC1664:
-
-     Antonio Blasco Bonito     RFC822: bonito@cnuce.cnr.it
-     CNUCE - CNR               X.400:  C=it;A=garr;P=cnr;
-     Reparto infr. reti                O=cnuce;S=bonito;
-     Viale S. Maria 36
-     I 56126 Pisa
-     Italy
-
-
-     Bruce Cole                RFC822: bcole@cisco.com
-     Cisco Systems Inc.        X.400:  C=us;A= ;P=Internet;
-     P.O. Box 3075                     DD.rfc-822=bcole(a)cisco.com;
-     1525 O'Brien Drive
-     Menlo Park, CA 94026
-     U.S.A.
-
-
-     Silvia Giordano           RFC822: giordano@cscs.ch
-     Centro Svizzero di        X.400:  C=ch;A=arcom;P=switch;O=cscs;
-     Calcolo Scientifico               S=giordano;
-     Via Cantonale
-     CH 6928 Manno
-     Switzerland
-
-
-     Robert Hagens                   RFC822: hagens@ans.net
-     Advanced Network and Services   X.400:  C=us;A= ;P=Internet;
-     1875 Campus Commons Drive               DD.rfc-822=hagens(a)ans.net;
-     Reston, VA 22091
-     U.S.A.
-
-
-
-
-
-
-Allocchio                   Standards Track                    [Page 23]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-9. References
-
-   [CCITT] CCITT SG 5/VII, "Recommendation X.400, Message Handling
-       Systems: System Model - Service Elements", October 1988.
-
-   [RFC 1327] Kille, S., "Mapping between X.400(1988)/ISO 10021 and RFC
-       822", RFC 1327, March 1992.
-
-   [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
-       STD 13, RFC 1034, USC/Information Sciences Institute, November
-       1987.
-
-   [RFC 1035] Mockapetris, P., "Domain names - Implementation and
-       Specification", STD 13, RFC 1035, USC/Information Sciences
-       Institute, November 1987.
-
-   [RFC 1033] Lottor, M., "Domain Administrators Operation Guide", RFC
-       1033, SRI International, November 1987.
-
-   [RFC 2156] Kille, S. E., " MIXER (Mime Internet X.400 Enhanced
-       Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156,
-       January 1998.
-
-   [Costa] Costa, A., Macedo, J., and V. Freitas, "Accessing and
-       Managing DNS Information in the X.500 Directory", Proceeding of
-       the 4th Joint European Networking Conference, Trondheim, NO, May
-       1993.
-
-10. Security Considerations
-
-   This document specifies a means by which DNS "PX" records can direct
-   the translation between X.400 and Internet mail addresses.
-
-   This can indirectly affect the routing of mail across an gateway
-   between X.400 and Internet Mail.  A succesful attack on this service
-   could cause incorrect translation of an originator address (thus
-   "forging" the originator address), or incorrect translation of a
-   recipient address (thus directing the mail to an unauthorized
-   recipient, or making it appear to an authorized recipient, that the
-   message was intended for recipients other than those chosen by the
-   originator) or could force the mail path via some particular gateway
-   or message transfer agent where mail security can be affected by
-   compromised software.
-
-
-
-
-
-
-
-
-Allocchio                   Standards Track                    [Page 24]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   There are several means by which an attacker might be able to deliver
-   incorrect PX records to a client.  These include: (a) compromise of a
-   DNS server,  (b) generating a counterfeit response to a client's DNS
-   query, (c) returning incorrect "additional information" in response
-   to an unrelated query.
-
-   Clients using PX records SHOULD ensure that routing and address
-   translations are based only on authoritative answers.  Once DNS
-   Security mechanisms [RFC 2065] become more widely deployed, clients
-   SHOULD employ those mechanisms to verify the authenticity and
-   integrity of PX records.
-
-11. Author's Address
-
-   Claudio Allocchio
-   Sincrotrone Trieste
-   SS 14 Km 163.5 Basovizza
-   I 34012 Trieste
-   Italy
-
-   RFC822: Claudio.Allocchio@elettra.trieste.it
-   X.400:  C=it;A=garr;P=Trieste;O=Elettra;
-   S=Allocchio;G=Claudio;
-   Phone:  +39 40 3758523
-   Fax:    +39 40 3758565
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Allocchio                   Standards Track                    [Page 25]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-12.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Allocchio                   Standards Track                    [Page 26]
-
diff --git a/contrib/bind9/doc/rfc/rfc2168.txt b/contrib/bind9/doc/rfc/rfc2168.txt
deleted file mode 100644
index 3eed1bd..0000000
--- a/contrib/bind9/doc/rfc/rfc2168.txt
+++ /dev/null
@@ -1,1123 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                       R. Daniel
-Request for Comments: 2168             Los Alamos National Laboratory
-Category: Experimental                                    M. Mealling
-                                              Network Solutions, Inc.
-                                                            June 1997
-
-
-               Resolution of Uniform Resource Identifiers
-                      using the Domain Name System
-
-Status of this Memo
-===================
-
-   This memo defines an Experimental Protocol for the Internet
-   community.  This memo does not specify an Internet standard of any
-   kind.  Discussion and suggestions for improvement are requested.
-   Distribution of this memo is unlimited.
-
-Abstract:
-=========
-
-   Uniform Resource Locators (URLs) are the foundation of the World Wide
-   Web, and are a vital Internet technology. However, they have proven
-   to be brittle in practice. The basic problem is that URLs typically
-   identify a particular path to a file on a particular host. There is
-   no graceful way of changing the path or host once the URL has been
-   assigned. Neither is there a graceful way of replicating the resource
-   located by the URL to achieve better network utilization and/or fault
-   tolerance. Uniform Resource Names (URNs) have been hypothesized as a
-   adjunct to URLs that would overcome such problems. URNs and URLs are
-   both instances of a broader class of identifiers known as Uniform
-   Resource Identifiers (URIs).
-
-   The requirements document for URN resolution systems[15] defines the
-   concept of a "resolver discovery service". This document describes
-   the first, experimental, RDS. It is implemented by a new DNS Resource
-   Record, NAPTR (Naming Authority PoinTeR), that provides rules for
-   mapping parts of URIs to domain names.  By changing the mapping
-   rules, we can change the host that is contacted to resolve a URI.
-   This will allow a more graceful handling of URLs over long time
-   periods, and forms the foundation for a new proposal for Uniform
-   Resource Names.
-
-
-
-
-
-
-
-
-
-Daniel & Mealling             Experimental                      [Page 1]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-   In addition to locating resolvers, the NAPTR provides for other
-   naming systems to be grandfathered into the URN world, provides
-   independence between the name assignment system and the resolution
-   protocol system, and allows multiple services (Name to Location, Name
-   to Description, Name to Resource, ...) to be offered.  In conjunction
-   with the SRV RR, the NAPTR record allows those services to be
-   replicated for the purposes of fault tolerance and load balancing.
-
-Introduction:
-=============
-
-   Uniform Resource Locators have been a significant advance in
-   retrieving Internet-accessible resources. However, their  brittle
-   nature over time has been recognized for several years. The Uniform
-   Resource Identifier working group proposed the development of Uniform
-   Resource Names to serve as persistent, location-independent
-   identifiers for Internet resources in order to overcome most of the
-   problems with URLs. RFC-1737 [1] sets forth requirements on URNs.
-
-   During the lifetime of the URI-WG, a number of URN proposals were
-   generated. The developers of several of those proposals met in a
-   series of meetings, resulting in a compromise known as the Knoxville
-   framework.  The major principle behind the Knoxville framework is
-   that the resolution system must be separate from the way names are
-   assigned. This is in marked contrast to most URLs, which identify the
-   host to contact and the protocol to use. Readers are referred to [2]
-   for background on the Knoxville framework and for additional
-   information on the context and purpose of this proposal.
-
-   Separating the way names are resolved from the way they are
-   constructed provides several benefits. It allows multiple naming
-   approaches and resolution approaches to compete, as it allows
-   different protocols and resolvers to be used. There is just one
-   problem with such a separation - how do we resolve a name when it
-   can't give us directions to its resolver?
-
-   For the short term, DNS is the obvious candidate for the resolution
-   framework, since it is widely deployed and understood. However, it is
-   not appropriate to use DNS to maintain information on a per-resource
-   basis. First of all, DNS was never intended to handle that many
-   records. Second, the limited record size is inappropriate for catalog
-   information. Third, domain names are not appropriate as URNs.
-
-   Therefore our approach is to use DNS to locate "resolvers" that can
-   provide information on individual resources, potentially including
-   the resource itself. To accomplish this, we "rewrite" the URI into a
-   domain name following the rules provided in NAPTR records. Rewrite
-   rules provide considerable power, which is important when trying to
-
-
-
-Daniel & Mealling             Experimental                      [Page 2]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-   meet the goals listed above. However, collections of rules can become
-   difficult to understand. To lessen this problem, the NAPTR rules are
-   *always* applied to the original URI, *never* to the output of
-   previous rules.
-
-   Locating a resolver through the rewrite procedure may take multiple
-   steps, but the beginning is always the same. The start of the URI is
-   scanned to extract its colon-delimited prefix. (For URNs, the prefix
-   is always "urn:" and we extract the following colon-delimited
-   namespace identifier [3]). NAPTR resolution begins by taking the
-   extracted string, appending the well-known suffix ".urn.net", and
-   querying the DNS for NAPTR records at that domain name.  Based on the
-   results of this query, zero or more additional DNS queries may be
-   needed to locate resolvers for the URI. The details of the
-   conversation between the client and the resolver thus located are
-   outside the bounds of this draft. Three brief examples of this
-   procedure are given in the next section.
-
-   The NAPTR RR provides the level of indirection needed to keep the
-   naming system independent of the resolution system, its protocols,
-   and services.  Coupled with the new SRV resource record proposal[4]
-   there is also the potential for replicating the resolver on multiple
-   hosts, overcoming some of the most significant problems of URLs. This
-   is an important and subtle point. Not only do the NAPTR and SRV
-   records allow us to replicate the resource, we can replicate the
-   resolvers that know about the replicated resource. Preventing a
-   single point of failure at the resolver level is a significant
-   benefit. Separating the resolution procedure from the way names are
-   constructed has additional benefits.  Different resolution procedures
-   can be used over time, and resolution procedures that are determined
-   to be useful can be extended to deal with additional namespaces.
-
-Caveats
-=======
-
-   The NAPTR proposal is the first resolution procedure to be considered
-   by the URN-WG. There are several concerns about the proposal which
-   have motivated the group to recommend it for publication as an
-   Experimental rather than a standards-track RFC.
-
-   First, URN resolution is new to the IETF and we wish to gain
-   operational experience before recommending any procedure for the
-   standards track. Second, the NAPTR proposal is based on DNS and
-   consequently inherits concerns about security and administration. The
-   recent advancement of the DNSSEC and secure update drafts to Proposed
-   Standard reduce these concerns, but we wish to experiment with those
-   new capabilities in the context of URN administration.  A third area
-   of concern is the potential for a noticeable impact on the DNS.  We
-
-
-
-Daniel & Mealling             Experimental                      [Page 3]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-   believe that the proposal makes appropriate use of caching and
-   additional information, but it is best to go slow where the potential
-   for impact on a core system like the DNS is concerned. Fourth, the
-   rewrite rules in the NAPTR proposal are based on regular expressions.
-   Since regular expressions are difficult for humans to construct
-   correctly, concerns exist about the usability and maintainability of
-   the rules. This is especially true where international character sets
-   are concerned. Finally, the URN-WG is developing a requirements
-   document for URN Resolution Services[15], but that document is not
-   complete. That document needs to precede any resolution service
-   proposals on the standards track.
-
-Terminology
-===========
-
-   "Must" or "Shall" - Software that does not behave in the manner that
-              this document says it must is not conformant to this
-              document.
-   "Should" - Software that does not follow the behavior that this
-              document says it should may still be conformant, but is
-              probably broken in some fundamental way.
-   "May" -    Implementations may or may not provide the described
-              behavior, while still remaining conformant to this
-              document.
-
-Brief overview and examples of the NAPTR RR:
-============================================
-
-   A detailed description of the NAPTR RR will be given later, but to
-   give a flavor for the proposal we first give a simple description of
-   the record and three examples of its use.
-
-   The key fields in the NAPTR RR are order, preference, service, flags,
-   regexp, and replacement:
-
-   * The order field specifies the order in which records MUST be
-     processed when multiple NAPTR records are returned in response to a
-     single query.  A naming authority may have delegated a portion of
-     its namespace to another agency. Evaluating the NAPTR records in
-     the correct order is necessary for delegation to work properly.
-
-   * The preference field specifies the order in which records SHOULD be
-     processed when multiple NAPTR records have the same value of
-     "order".  This field lets a service provider specify the order in
-     which resolvers are contacted, so that more capable machines are
-     contacted in preference to less capable ones.
-
-
-
-
-
-Daniel & Mealling             Experimental                      [Page 4]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-   * The service field specifies the resolution protocol and resolution
-     service(s) that will be available if the rewrite specified by the
-     regexp or replacement fields is applied. Resolution protocols are
-     the protocols used to talk with a resolver. They will be specified
-     in other documents, such as [5]. Resolution services are operations
-     such as N2R (URN to Resource), N2L (URN to URL), N2C (URN to URC),
-     etc.  These will be discussed in the URN Resolution Services
-     document[6], and their behavior in a particular resolution protocol
-     will be given in the specification for that protocol (see [5] for a
-     concrete example).
-
-   * The flags field contains modifiers that affect what happens in the
-     next DNS lookup, typically for optimizing the process. Flags may
-     also affect the interpretation of the other fields in the record,
-     therefore, clients MUST skip NAPTR records which contain an unknown
-     flag value.
-
-   * The regexp field is one of two fields used for the rewrite rules,
-     and is the core concept of the NAPTR record. The regexp field is a
-     String containing a sed-like substitution expression. (The actual
-     grammar for the substitution expressions is given later in this
-     draft). The substitution expression is applied to the original URN
-     to determine the next domain name to be queried. The regexp field
-     should be used when the domain name to be generated is conditional
-     on information in the URI. If the next domain name is always known,
-     which is anticipated to be a common occurrence, the replacement
-     field should be used instead.
-
-   * The replacement field is the other field that may be used for the
-     rewrite rule. It is an optimization of the rewrite process for the
-     case where the next domain name is fixed instead of being
-     conditional on the content of the URI. The replacement field is a
-     domain name (subject to compression if a DNS sender knows that a
-     given recipient is able to decompress names in this RR type's RDATA
-     field). If the rewrite is more complex than a simple substitution
-     of a domain name, the replacement field should be set to . and the
-     regexp field used.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daniel & Mealling             Experimental                      [Page 5]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-   Note that the client applies all the substitutions and performs all
-   lookups, they are not performed in the DNS servers. Note also that it
-   is the belief of the developers of this document that regexps should
-   rarely be used. The replacement field seems adequate for the vast
-   majority of situations. Regexps are only necessary when portions of a
-   namespace are to be delegated to different resolvers. Finally, note
-   that the regexp and replacement fields are, at present, mutually
-   exclusive. However, developers of client software should be aware
-   that a new flag might be defined which requires values in both
-   fields.
-
-Example 1
----------
-
-   Consider a URN that uses the hypothetical DUNS namespace. DUNS
-   numbers are identifiers for approximately 30 million registered
-   businesses around the world, assigned and maintained by Dunn and
-   Bradstreet. The URN might look like:
-
-                   urn:duns:002372413:annual-report-1997
-
-   The first step in the resolution process is to find out about the
-   DUNS namespace. The namespace identifier, "duns", is extracted from
-   the URN, prepended to urn.net, and the NAPTRs for duns.urn.net looked
-   up. It might return records of the form:
-
-duns.urn.net
-;;      order pref flags service          regexp        replacement
- IN NAPTR 100  10  "s" "dunslink+N2L+N2C" ""  dunslink.udp.isi.dandb.com
- IN NAPTR 100  20  "s" "rcds+N2C"         ""  rcds.udp.isi.dandb.com
- IN NAPTR 100  30  "s" "http+N2L+N2C+N2R" ""  http.tcp.isi.dandb.com
-
-   The order field contains equal values, indicating that no name
-   delegation order has to be followed. The preference field indicates
-   that the provider would like clients to use the special dunslink
-   protocol, followed by the RCDS protocol, and that HTTP is offered as
-   a last resort. All the records specify the "s" flag, which will be
-   explained momentarily.  The service fields say that if we speak
-   dunslink, we will be able to issue either the N2L or N2C requests to
-   obtain a URL or a URC (description) of the resource. The Resource
-   Cataloging and Distribution Service (RCDS)[7] could be used to get a
-   URC for the resource, while HTTP could be used to get a URL, URC, or
-   the resource itself.  All the records supply the next domain name to
-   query, none of them need to be rewritten with the aid of regular
-   expressions.
-
-
-
-
-
-
-Daniel & Mealling             Experimental                      [Page 6]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-   The general case might require multiple NAPTR rewrites to locate a
-   resolver, but eventually we will come to the "terminal NAPTR". Once
-   we have the terminal NAPTR, our next probe into the DNS will be for a
-   SRV or A record instead of another NAPTR. Rather than probing for a
-   non-existent NAPTR record to terminate the loop, the flags field is
-   used to indicate a terminal lookup. If it has a value of "s", the
-   next lookup should be for SRV RRs, "a" denotes that A records should
-   sought.  A "p" flag is also provided to indicate that the next action
-   is Protocol-specific, but that looking up another NAPTR will not be
-   part of it.
-
-   Since our example RR specified the "s" flag, it was terminal.
-   Assuming our client does not know the dunslink protocol, our next
-   action is to lookup SRV RRs for rcds.udp.isi.dandb.com, which will
-   tell us hosts that can provide the necessary resolution service. That
-   lookup might return:
-
-    ;;                          Pref Weight Port Target
-    rcds.udp.isi.dandb.com IN SRV 0    0    1000 defduns.isi.dandb.com
-                           IN SRV 0    0    1000 dbmirror.com.au
-                           IN SRV 0    0    1000 ukmirror.com.uk
-
-   telling us three hosts that could actually do the resolution, and
-   giving us the port we should use to talk to their RCDS server.  (The
-   reader is referred to the SRV proposal [4] for the interpretation of
-   the fields above).
-
-   There is opportunity for significant optimization here. We can return
-   the SRV records as additional information for terminal NAPTRs (and
-   the A records as additional information for those SRVs). While this
-   recursive provision of additional information is not explicitly
-   blessed in the DNS specifications, it is not forbidden, and BIND does
-   take advantage of it [8]. This is a significant optimization. In
-   conjunction with a long TTL for *.urn.net records, the average number
-   of probes to DNS for resolving DUNS URNs would approach one.
-   Therefore, DNS server implementors SHOULD provide additional
-   information with NAPTR responses. The additional information will be
-   either SRV or A records.  If SRV records are available, their A
-   records should be provided as recursive additional information.
-
-   Note that the example NAPTR records above are intended to represent
-   the reply the client will see. They are not quite identical to what
-   the domain administrator would put into the zone files. For one
-   thing, the administrator should supply the trailing '.' character on
-   any FQDNs.
-
-
-
-
-
-
-Daniel & Mealling             Experimental                      [Page 7]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-Example 2
----------
-
-   Consider a URN namespace based on MIME Content-Ids. The URN might
-   look like this:
-
-                 urn:cid:199606121851.1@mordred.gatech.edu
-
-   (Note that this example is chosen for pedagogical purposes, and does
-   not conform to the recently-approved CID URL scheme.)
-
-   The first step in the resolution process is to find out about the CID
-   namespace. The namespace identifier, cid, is extracted from the URN,
-   prepended to urn.net, and the NAPTR for cid.urn.net looked up. It
-   might return records of the form:
-
- cid.urn.net
-  ;;       order pref flags service        regexp           replacement
-   IN NAPTR 100   10   ""  ""  "/urn:cid:.+@([^\.]+\.)(.*)$/\2/i"    .
-
-   We have only one NAPTR response, so ordering the responses is not a
-   problem.  The replacement field is empty, so we check the regexp
-   field and use the pattern provided there. We apply that regexp to the
-   entire URN to see if it matches, which it does.  The \2 part of the
-   substitution expression returns the string "gatech.edu". Since the
-   flags field does not contain "s" or "a", the lookup is not terminal
-   and our next probe to DNS is for more NAPTR records:
-   lookup(query=NAPTR, "gatech.edu").
-
-   Note that the rule does not extract the full domain name from the
-   CID, instead it assumes the CID comes from a host and extracts its
-   domain.  While all hosts, such as mordred, could have their very own
-   NAPTR, maintaining those records for all the machines at a site as
-   large as Georgia Tech would be an intolerable burden. Wildcards are
-   not appropriate here since they only return results when there is no
-   exactly matching names already in the system.
-
-   The record returned from the query on "gatech.edu" might look like:
-
-gatech.edu IN NAPTR
-;;       order pref flags service           regexp  replacement
-  IN NAPTR 100  50  "s"  "z3950+N2L+N2C"     ""    z3950.tcp.gatech.edu
-  IN NAPTR 100  50  "s"  "rcds+N2C"          ""    rcds.udp.gatech.edu
-  IN NAPTR 100  50  "s"  "http+N2L+N2C+N2R"  ""    http.tcp.gatech.edu
-
-
-
-
-
-
-
-Daniel & Mealling             Experimental                      [Page 8]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-   Continuing with our example, we note that the values of the order and
-   preference fields are equal in all records, so the client is free to
-   pick any record. The flags field tells us that these are the last
-   NAPTR patterns we should see, and after the rewrite (a simple
-   replacement in this case) we should look up SRV records to get
-   information on the hosts that can provide the necessary service.
-
-   Assuming we prefer the Z39.50 protocol, our lookup might return:
-
-   ;;                        Pref Weight   Port Target
-   z3950.tcp.gatech.edu IN SRV 0    0      1000 z3950.gatech.edu
-                        IN SRV 0    0      1000 z3950.cc.gatech.edu
-                        IN SRV 0    0      1000 z3950.uga.edu
-
-   telling us three hosts that could actually do the resolution, and
-   giving us the port we should use to talk to their Z39.50 server.
-
-   Recall that the regular expression used \2 to extract a domain name
-   from the CID, and \. for matching the literal '.' characters
-   seperating the domain name components. Since '\' is the escape
-   character, literal occurances of a backslash must be escaped by
-   another backslash. For the case of the cid.urn.net record above, the
-   regular expression entered into the zone file should be
-   "/urn:cid:.+@([^\\.]+\\.)(.*)$/\\2/i".  When the client code actually
-   receives the record, the pattern will have been converted to
-   "/urn:cid:.+@([^.]+\.)(.*)$/\2/i".
-
-Example 3
----------
-
-   Even if URN systems were in place now, there would still be a
-   tremendous number of URLs.  It should be possible to develop a URN
-   resolution system that can also provide location independence for
-   those URLs.  This is related to the requirement in [1] to be able to
-   grandfather in names from other naming systems, such as ISO Formal
-   Public Identifiers, Library of Congress Call Numbers, ISBNs, ISSNs,
-   etc.
-
-   The NAPTR RR could also be used for URLs that have already been
-   assigned.  Assume we have the URL for a very popular piece of
-   software that the publisher wishes to mirror at multiple sites around
-   the world:
-
-        http://www.foo.com/software/latest-beta.exe
-
-
-
-
-
-
-
-Daniel & Mealling             Experimental                      [Page 9]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-   We extract the prefix, "http", and lookup NAPTR records for
-   http.urn.net. This might return a record of the form
-
-   http.urn.net IN NAPTR
-   ;;  order   pref flags service      regexp             replacement
-        100     90   ""      ""   "!http://([^/:]+)!\1!i"       .
-
-   This expression returns everything after the first double slash and
-   before the next slash or colon. (We use the '!' character to delimit
-   the parts of the substitution expression. Otherwise we would have to
-   use backslashes to escape the forward slashes, and would have a
-   regexp in the zone file that looked like
-   "/http:\\/\\/([^\\/:]+)/\\1/i".).
-
-   Applying this pattern to the URL extracts "www.foo.com". Looking up
-   NAPTR records for that might return:
-
-   www.foo.com
-   ;;       order pref flags   service  regexp     replacement
-    IN NAPTR 100  100  "s"   "http+L2R"   ""    http.tcp.foo.com
-    IN NAPTR 100  100  "s"   "ftp+L2R"    ""    ftp.tcp.foo.com
-
-   Looking up SRV records for http.tcp.foo.com would return information
-   on the hosts that foo.com has designated to be its mirror sites. The
-   client can then pick one for the user.
-
-NAPTR RR Format
-===============
-
-   The format of the NAPTR RR is given below. The DNS type code for
-   NAPTR is 35.
-
-       Domain TTL Class Order Preference Flags Service Regexp
-       Replacement
-
-   where:
-
-   Domain
-          The domain name this resource record refers to.
-   TTL
-          Standard DNS Time To Live field
-   Class
-          Standard DNS meaning
-
-
-
-
-
-
-
-
-Daniel & Mealling             Experimental                     [Page 10]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-   Order
-          A 16-bit integer specifying the order in which the NAPTR
-          records MUST be processed to ensure correct delegation of
-          portions of the namespace over time. Low numbers are processed
-          before high numbers, and once a NAPTR is found that "matches"
-          a URN, the client MUST NOT consider any NAPTRs with a higher
-          value for order.
-
-   Preference
-          A 16-bit integer which specifies the order in which NAPTR
-          records with equal "order" values SHOULD be processed, low
-          numbers being processed before high numbers.  This is similar
-          to the preference field in an MX record, and is used so domain
-          administrators can direct clients towards more capable hosts
-          or lighter weight protocols.
-
-   Flags
-          A String giving flags to control aspects of the rewriting and
-          interpretation of the fields in the record. Flags are single
-          characters from the set [A-Z0-9]. The case of the alphabetic
-          characters is not significant.
-
-          At this time only three flags, "S", "A", and "P", are defined.
-          "S" means that the next lookup should be for SRV records
-          instead of NAPTR records. "A" means that the next lookup
-          should be for A records. The "P" flag says that the remainder
-          of the resolution shall be carried out in a Protocol-specific
-          fashion, and we should not do any more DNS queries.
-
-          The remaining alphabetic flags are reserved. The numeric flags
-          may be used for local experimentation. The S, A, and P flags
-          are all mutually exclusive, and resolution libraries MAY
-          signal an error if more than one is given. (Experimental code
-          and code for assisting in the creation of NAPTRs would be more
-          likely to signal such an error than a client such as a
-          browser). We anticipate that multiple flags will be allowed in
-          the future, so implementers MUST NOT assume that the flags
-          field can only contain 0 or 1 characters. Finally, if a client
-          encounters a record with an unknown flag, it MUST ignore it
-          and move to the next record. This test takes precedence even
-          over the "order" field. Since flags can control the
-          interpretation placed on fields, a novel flag might change the
-          interpretation of the regexp and/or replacement fields such
-          that it is impossible to determine if a record matched a URN.
-
-
-
-
-
-
-
-Daniel & Mealling             Experimental                     [Page 11]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-   Service
-          Specifies the resolution service(s) available down this
-          rewrite path. It may also specify the particular protocol that
-          is used to talk with a resolver. A protocol MUST be specified
-          if the flags field states that the NAPTR is terminal. If a
-          protocol is specified, but the flags field does not state that
-          the NAPTR is terminal, the next lookup MUST be for a NAPTR.
-          The client MAY choose not to perform the next lookup if the
-          protocol is unknown, but that behavior MUST NOT be relied
-          upon.
-
-          The service field may take any of the values below (using the
-          Augmented BNF of RFC 822[9]):
-
-           service_field = [ [protocol] *("+" rs)]
-           protocol      = ALPHA *31ALPHANUM
-           rs            = ALPHA *31ALPHANUM
-        // The protocol and rs fields are limited to 32
-        // characters and must start with an alphabetic.
-        // The current set of "known" strings are:
-        // protocol      = "rcds" / "thttp" / "hdl" / "rwhois" / "z3950"
-        // rs            = "N2L" / "N2Ls" / "N2R" / "N2Rs" / "N2C"
-        //               / "N2Ns" / "L2R" / "L2Ns" / "L2Ls" / "L2C"
-
-          i.e. an optional protocol specification followed by 0 or more
-          resolution services. Each resolution service is indicated by
-          an initial '+' character.
-
-          Note that the empty string is also a valid service field. This
-          will typically be seen at the top levels of a namespace, when
-          it is impossible to know what services and protocols will be
-          offered by a particular publisher within that name space.
-
-          At this time the known protocols are rcds[7], hdl[10] (binary,
-          UDP-based protocols),  thttp[5] (a textual, TCP-based
-          protocol), rwhois[11] (textual, UDP or TCP based), and
-          Z39.50[12] (binary, TCP-based). More will be allowed later.
-          The names of the protocols must be formed from the characters
-          [a-Z0-9]. Case of the characters is not significant.
-
-          The service requests currently allowed will be described in
-          more detail in [6], but in brief they are:
-                N2L  - Given a URN, return a URL
-                N2Ls - Given a URN, return a set of URLs
-                N2R  - Given a URN, return an instance of the resource.
-                N2Rs - Given a URN, return multiple instances of the
-                       resource, typically encoded using
-                       multipart/alternative.
-
-
-
-Daniel & Mealling             Experimental                     [Page 12]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-                N2C  - Given a URN, return a collection of meta-
-                       information on the named resource. The format of
-                       this response is the subject of another document.
-                N2Ns - Given a URN, return all URNs that are also
-                       identifers for the resource.
-                L2R  - Given a URL, return the resource.
-                L2Ns - Given a URL, return all the URNs that are
-                       identifiers for the resource.
-                L2Ls - Given a URL, return all the URLs for instances of
-                       of the same resource.
-                L2C  - Given a URL, return a description of the
-                       resource.
-
-          The actual format of the service request and response will be
-          determined by the resolution protocol, and is the subject for
-          other documents (e.g. [5]). Protocols need not offer all
-          services. The labels for service requests shall be formed from
-          the set of characters [A-Z0-9]. The case of the alphabetic
-          characters is not significant.
-
-   Regexp
-          A STRING containing a substitution expression that is applied
-          to the original URI in order to construct the next domain name
-          to lookup. The grammar of the substitution expression is given
-          in the next section.
-
-   Replacement
-          The next NAME to query for NAPTR, SRV, or A records depending
-          on the value of the flags field. As mentioned above, this may
-          be compressed.
-
-Substitution Expression Grammar:
-================================
-
-   The content of the regexp field is a substitution expression. True
-   sed(1) substitution expressions are not appropriate for use in this
-   application for a variety of reasons, therefore the contents of the
-   regexp field MUST follow the grammar below:
-
-subst_expr   = delim-char  ere  delim-char  repl  delim-char  *flags
-delim-char   = "/" / "!" / ... (Any non-digit or non-flag character other
-               than backslash '\'. All occurances of a delim_char in a
-               subst_expr must be the same character.)
-ere          = POSIX Extended Regular Expression (see [13], section
-               2.8.4)
-repl         = dns_str /  backref / repl dns_str  / repl backref
-dns_str      = 1*DNS_CHAR
-backref      = "\" 1POS_DIGIT
-
-
-
-Daniel & Mealling             Experimental                     [Page 13]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-flags        = "i"
-DNS_CHAR     = "-" / "0" / ... / "9" / "a" / ... / "z" / "A" / ... / "Z"
-POS_DIGIT    = "1" / "2" / ... / "9"  ; 0 is not an allowed backref
-value domain name (see RFC-1123 [14]).
-
-   The result of applying the substitution expression to the original
-   URI MUST result in a string that obeys the syntax for DNS host names
-   [14]. Since it is possible for the regexp field to be improperly
-   specified, such that a non-conforming host name can be constructed,
-   client software SHOULD verify that the result is a legal host name
-   before making queries on it.
-
-   Backref expressions in the repl portion of the substitution
-   expression are replaced by the (possibly empty) string of characters
-   enclosed by '(' and ')' in the ERE portion of the substitution
-   expression. N is a single digit from 1 through 9, inclusive. It
-   specifies the N'th backref expression, the one that begins with the
-   N'th '(' and continues to the matching ')'.  For example, the ERE
-                      (A(B(C)DE)(F)G)
-   has backref expressions:
-                      \1  = ABCDEFG
-                      \2  = BCDE
-                      \3  = C
-                      \4  = F
-                 \5..\9  = error - no matching subexpression
-
-   The "i" flag indicates that the ERE matching SHALL be performed in a
-   case-insensitive fashion. Furthermore, any backref replacements MAY
-   be normalized to lower case when the "i" flag is given.
-
-   The first character in the substitution expression shall be used as
-   the character that delimits the components of the substitution
-   expression.  There must be exactly three non-escaped occurrences of
-   the delimiter character in a substitution expression. Since escaped
-   occurrences of the delimiter character will be interpreted as
-   occurrences of that character, digits MUST NOT be used as delimiters.
-   Backrefs would be confused with literal digits were this allowed.
-   Similarly, if flags are specified in the substitution expression, the
-   delimiter character must not also be a flag character.
-
-
-
-
-
-
-
-
-
-
-
-
-Daniel & Mealling             Experimental                     [Page 14]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-Advice to domain administrators:
-================================
-
-   Beware of regular expressions. Not only are they a pain to get
-   correct on their own, but there is the previously mentioned
-   interaction with DNS. Any backslashes in a regexp must be entered
-   twice in a zone file in order to appear once in a query response.
-   More seriously, the need for double backslashes has probably not been
-   tested by all implementors of DNS servers. We anticipate that urn.net
-   will be the heaviest user of regexps. Only when delegating portions
-   of namespaces should the typical domain administrator need to use
-   regexps.
-
-   On a related note, beware of interactions with the shell when
-   manipulating regexps from the command line. Since '\' is a common
-   escape character in shells, there is a good chance that when you
-   think you are saying "\\" you are actually saying "\".  Similar
-   caveats apply to characters such as
-
-   The "a" flag allows the next lookup to be for A records rather than
-   SRV records. Since there is no place for a port specification in the
-   NAPTR record, when the "A" flag is used the specified protocol must
-   be running on its default port.
-
-   The URN Sytnax draft defines a canonical form for each URN, which
-   requires %encoding characters outside a limited repertoire. The
-   regular expressions MUST be written to operate on that canonical
-   form. Since international character sets will end up with extensive
-   use of %encoded characters, regular expressions operating on them
-   will be essentially impossible to read or write by hand.
-
-Usage
-=====
-
-   For the edification of implementers, pseudocode for a client routine
-   using NAPTRs is given below. This code is provided merely as a
-   convience, it does not have any weight as a standard way to process
-   NAPTR records. Also, as is the case with pseudocode, it has never
-   been executed and may contain logical errors. You have been warned.
-
-    //
-    // findResolver(URN)
-    // Given a URN, find a host that can resolve it.
-    //
-    findResolver(string URN) {
-      // prepend prefix to urn.net
-      sprintf(key, "%s.urn.net", extractNS(URN));
-      do {
-
-
-
-Daniel & Mealling             Experimental                     [Page 15]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-        rewrite_flag = false;
-        terminal = false;
-        if (key has been seen) {
-          quit with a loop detected error
-        }
-        add key to list of "seens"
-        records = lookup(type=NAPTR, key); // get all NAPTR RRs for 'key'
-
-        discard any records with an unknown value in the "flags" field.
-        sort NAPTR records by "order" field and "preference" field
-            (with "order" being more significant than "preference").
-        n_naptrs = number of NAPTR records in response.
-        curr_order = records[0].order;
-        max_order = records[n_naptrs-1].order;
-
-        // Process current batch of NAPTRs according to "order" field.
-        for (j=0; j < n_naptrs && records[j].order <= max_order; j++) {
-          if (unknown_flag) // skip this record and go to next one
-             continue;
-          newkey = rewrite(URN, naptr[j].replacement, naptr[j].regexp);
-          if (!newkey) // Skip to next record if the rewrite didn't
-             match continue;
-          // We did do a rewrite, shrink max_order to current value
-          // so that delegation works properly
-          max_order = naptr[j].order;
-          // Will we know what to do with the protocol and services
-          // specified in the NAPTR? If not, try next record.
-          if(!isKnownProto(naptr[j].services)) {
-            continue;
-          }
-          if(!isKnownService(naptr[j].services)) {
-            continue;
-          }
-
-          // At this point we have a successful rewrite and we will
-          // know how to speak the protocol and request a known
-          // resolution service. Before we do the next lookup, check
-          // some optimization possibilities.
-
-          if (strcasecmp(flags, "S")
-           || strcasecmp(flags, "P"))
-           || strcasecmp(flags, "A")) {
-             terminal = true;
-             services = naptr[j].services;
-             addnl = any SRV and/or A records returned as additional
-                     info for naptr[j].
-          }
-          key = newkey;
-
-
-
-Daniel & Mealling             Experimental                     [Page 16]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-          rewriteflag = true;
-          break;
-        }
-      } while (rewriteflag && !terminal);
-
-      // Did we not find our way to a resolver?
-      if (!rewrite_flag) {
-         report an error
-         return NULL;
-      }
-
-
-      // Leave rest to another protocol?
-      if (strcasecmp(flags, "P")) {
-         return key as host to talk to;
-      }
-
-      // If not, keep plugging
-      if (!addnl) { // No SRVs came in as additional info, look them up
-        srvs = lookup(type=SRV, key);
-      }
-
-      sort SRV records by preference, weight, ...
-      foreach (SRV record) { // in order of preference
-        try contacting srv[j].target using the protocol and one of the
-            resolution service requests from the "services" field of the
-            last NAPTR record.
-        if (successful)
-          return (target, protocol, service);
-          // Actually we would probably return a result, but this
-          // code was supposed to just tell us a good host to talk to.
-      }
-      die with an "unable to find a host" error;
-    }
-
-Notes:
-======
-
-     -  A client MUST process multiple NAPTR records in the order
-        specified by the "order" field, it MUST NOT simply use the first
-        record that provides a known protocol and service combination.
-
-
-
-
-
-
-
-
-
-
-Daniel & Mealling             Experimental                     [Page 17]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-     -  If a record at a particular order matches the URI, but the
-        client doesn't know the specified protocol and service, the
-        client SHOULD continue to examine records that have the same
-        order. The client MUST NOT consider records with a higher value
-        of order. This is necessary to make delegation of portions of
-        the namespace work.  The order field is what lets site
-        administrators say "all requests for URIs matching pattern x go
-        to server 1, all others go to server 2".
-        (A match is defined as:
-          1)  The NAPTR provides a replacement domain name
-          or
-          2) The regular expression matches the URN
-           )
-
-     -  When multiple RRs have the same "order", the client should use
-        the value of the preference field to select the next NAPTR to
-        consider. However, because of preferred protocols or services,
-        estimates of network distance and bandwidth, etc. clients may
-        use different criteria to sort the records.
-     -  If the lookup after a rewrite fails, clients are strongly
-        encouraged to report a failure, rather than backing up to pursue
-        other rewrite paths.
-     -  When a namespace is to be delegated among a set of resolvers,
-        regexps must be used. Each regexp appears in a separate NAPTR
-        RR.  Administrators should do as little delegation as possible,
-        because of limitations on the size of DNS responses.
-     -  Note that SRV RRs impose additional requirements on clients.
-
-Acknowledgments:
-=================
-
-   The editors would like to thank Keith Moore for all his consultations
-   during the development of this draft. We would also like to thank
-   Paul Vixie for his assistance in debugging our implementation, and
-   his answers on our questions. Finally, we would like to acknowledge
-   our enormous intellectual debt to the participants in the Knoxville
-   series of meetings, as well as to the participants in the URI and URN
-   working groups.
-
-References:
-===========
-
-   [1]  Sollins, Karen and Larry Masinter, "Functional Requirements
-        for Uniform Resource Names", RFC-1737, Dec. 1994.
-
-   [2]  The URN Implementors, Uniform Resource Names: A Progress Report,
-        http://www.dlib.org/dlib/february96/02arms.html, D-Lib Magazine,
-        February 1996.
-
-
-
-Daniel & Mealling             Experimental                     [Page 18]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-   [3]  Moats, Ryan, "URN Syntax", RFC-2141, May 1997.
-
-   [4]  Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying
-        the location of services (DNS SRV)", RFC-2052, October 1996.
-
-   [5]  Daniel, Jr., Ron, "A Trivial Convention for using HTTP in URN
-        Resolution", RFC-2169, June 1997.
-
-   [6]  URN-WG, "URN Resolution Services", Work in Progress.
-
-   [7]  Moore, Keith,  Shirley Browne, Jason Cox, and Jonathan Gettler,
-        Resource Cataloging and Distribution System, Technical Report
-        CS-97-346, University of Tennessee, Knoxville, December 1996
-
-   [8]  Paul Vixie, personal communication.
-
-   [9]  Crocker, Dave H. "Standard for the Format of ARPA Internet Text
-        Messages", RFC-822, August 1982.
-
-   [10] Orth, Charles and Bill Arms; Handle Resolution Protocol
-        Specification, http://www.handle.net/docs/client_spec.html
-
-   [11] Williamson, S., M. Kosters, D. Blacka, J. Singh, K. Zeilstra,
-        "Referral Whois Protocol (RWhois)", RFC-2167, June 1997.
-
-   [12] Information Retrieval (Z39.50): Application Service Definition
-        and Protocol Specification, ANSI/NISO Z39.50-1995, July 1995.
-
-   [13] IEEE Standard for Information Technology - Portable Operating
-        System Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1);
-        IEEE Std 1003.2-1992; The Institute of Electrical and
-        Electronics Engineers; New York; 1993. ISBN:1-55937-255-9
-
-   [14] Braden, R., "Requirements for Internet Hosts - Application and
-        and Support", RFC-1123, Oct. 1989.
-
-   [15] Sollins, Karen, "Requirements and a Framework for URN Resolution
-        Systems", November 1996, Work in Progress.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daniel & Mealling             Experimental                     [Page 19]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-Security Considerations
-=======================
-
-   The use of "urn.net" as the registry for URN namespaces is subject to
-   denial of service attacks, as well as other DNS spoofing attacks. The
-   interactions with DNSSEC are currently being studied. It is expected
-   that NAPTR records will be signed with SIG records once the DNSSEC
-   work is deployed.
-
-   The rewrite rules make identifiers from other namespaces subject to
-   the same attacks as normal domain names. Since they have not been
-   easily resolvable before, this may or may not be considered a
-   problem.
-
-   Regular expressions should be checked for sanity, not blindly passed
-   to something like PERL.
-
-   This document has discussed a way of locating a resolver, but has not
-   discussed any detail of how the communication with the resolver takes
-   place. There are significant security considerations attached to the
-   communication with a resolver. Those considerations are outside the
-   scope of this document, and must be addressed by the specifications
-   for particular resolver communication protocols.
-
-Author Contact Information:
-===========================
-
-   Ron Daniel
-   Los Alamos National Laboratory
-   MS B287
-   Los Alamos, NM, USA, 87545
-   voice:  +1 505 665 0597
-   fax:    +1 505 665 4939
-   email:  rdaniel@lanl.gov
-
-
-   Michael Mealling
-   Network Solutions
-   505 Huntmar Park Drive
-   Herndon, VA  22070
-   voice: (703) 742-0400
-   fax: (703) 742-9552
-   email: michaelm@internic.net
-   URL: http://www.netsol.com/
-
-
-
-
-
-
-
-Daniel & Mealling             Experimental                     [Page 20]
-
diff --git a/contrib/bind9/doc/rfc/rfc2181.txt b/contrib/bind9/doc/rfc/rfc2181.txt
deleted file mode 100644
index 7899e1c..0000000
--- a/contrib/bind9/doc/rfc/rfc2181.txt
+++ /dev/null
@@ -1,842 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                             R. Elz
-Request for Comments: 2181                       University of Melbourne
-Updates: 1034, 1035, 1123                                        R. Bush
-Category: Standards Track                                    RGnet, Inc.
-                                                               July 1997
-
-
-                Clarifications to the DNS Specification
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-1. Abstract
-
-   This document considers some areas that have been identified as
-   problems with the specification of the Domain Name System, and
-   proposes remedies for the defects identified.  Eight separate issues
-   are considered:
-
-     + IP packet header address usage from multi-homed servers,
-     + TTLs in sets of records with the same name, class, and type,
-     + correct handling of zone cuts,
-     + three minor issues concerning SOA records and their use,
-     + the precise definition of the Time to Live (TTL)
-     + Use of the TC (truncated) header bit
-     + the issue of what is an authoritative, or canonical, name,
-     + and the issue of what makes a valid DNS label.
-
-   The first six of these are areas where the correct behaviour has been
-   somewhat unclear, we seek to rectify that.  The other two are already
-   adequately specified, however the specifications seem to be sometimes
-   ignored.  We seek to reinforce the existing specifications.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Elz & Bush                  Standards Track                     [Page 1]
-
-RFC 2181        Clarifications to the DNS Specification        July 1997
-
-
-
-
-Contents
-
-    1  Abstract  ...................................................   1
-    2  Introduction  ...............................................   2
-    3  Terminology  ................................................   3
-    4  Server Reply Source Address Selection  ......................   3
-    5  Resource Record Sets  .......................................   4
-    6  Zone Cuts  ..................................................   8
-    7  SOA RRs  ....................................................  10
-    8  Time to Live (TTL)  .........................................  10
-    9  The TC (truncated) header bit  ..............................  11
-   10  Naming issues  ..............................................  11
-   11  Name syntax  ................................................  13
-   12  Security Considerations  ....................................  14
-   13  References  .................................................  14
-   14  Acknowledgements  ...........................................  15
-   15  Authors' Addresses  .........................................  15
-
-
-
-
-2. Introduction
-
-   Several problem areas in the Domain Name System specification
-   [RFC1034, RFC1035] have been noted through the years [RFC1123].  This
-   document addresses several additional problem areas.  The issues here
-   are independent.  Those issues are the question of which source
-   address a multi-homed DNS server should use when replying to a query,
-   the issue of differing TTLs for DNS records with the same label,
-   class and type, and the issue of canonical names, what they are, how
-   CNAME records relate, what names are legal in what parts of the DNS,
-   and what is the valid syntax of a DNS name.
-
-   Clarifications to the DNS specification to avoid these problems are
-   made in this memo.  A minor ambiguity in RFC1034 concerned with SOA
-   records is also corrected, as is one in the definition of the TTL
-   (Time To Live) and some possible confusion in use of the TC bit.
-
-
-
-
-
-
-
-
-
-
-
-
-Elz & Bush                  Standards Track                     [Page 2]
-
-RFC 2181        Clarifications to the DNS Specification        July 1997
-
-
-3. Terminology
-
-   This memo does not use the oft used expressions MUST, SHOULD, MAY, or
-   their negative forms.  In some sections it may seem that a
-   specification is worded mildly, and hence some may infer that the
-   specification is optional.  That is not correct.  Anywhere that this
-   memo suggests that some action should be carried out, or must be
-   carried out, or that some behaviour is acceptable, or not, that is to
-   be considered as a fundamental aspect of this specification,
-   regardless of the specific words used.  If some behaviour or action
-   is truly optional, that will be clearly specified by the text.
-
-4. Server Reply Source Address Selection
-
-   Most, if not all, DNS clients, expect the address from which a reply
-   is received to be the same address as that to which the query
-   eliciting the reply was sent.  This is true for servers acting as
-   clients for the purposes of recursive query resolution, as well as
-   simple resolver clients.  The address, along with the identifier (ID)
-   in the reply is used for disambiguating replies, and filtering
-   spurious responses.  This may, or may not, have been intended when
-   the DNS was designed, but is now a fact of life.
-
-   Some multi-homed hosts running DNS servers generate a reply using a
-   source address that is not the same as the destination address from
-   the client's request packet.  Such replies will be discarded by the
-   client because the source address of the reply does not match that of
-   a host to which the client sent the original request.  That is, it
-   appears to be an unsolicited response.
-
-4.1. UDP Source Address Selection
-
-   To avoid these problems, servers when responding to queries using UDP
-   must cause the reply to be sent with the source address field in the
-   IP header set to the address that was in the destination address
-   field of the IP header of the packet containing the query causing the
-   response.  If this would cause the response to be sent from an IP
-   address that is not permitted for this purpose, then the response may
-   be sent from any legal IP address allocated to the server.  That
-   address should be chosen to maximise the possibility that the client
-   will be able to use it for further queries.  Servers configured in
-   such a way that not all their addresses are equally reachable from
-   all potential clients need take particular care when responding to
-   queries sent to anycast, multicast, or similar, addresses.
-
-
-
-
-
-
-
-Elz & Bush                  Standards Track                     [Page 3]
-
-RFC 2181        Clarifications to the DNS Specification        July 1997
-
-
-4.2. Port Number Selection
-
-   Replies to all queries must be directed to the port from which they
-   were sent.  When queries are received via TCP this is an inherent
-   part of the transport protocol.  For queries received by UDP the
-   server must take note of the source port and use that as the
-   destination port in the response.  Replies should always be sent from
-   the port to which they were directed.  Except in extraordinary
-   circumstances, this will be the well known port assigned for DNS
-   queries [RFC1700].
-
-5. Resource Record Sets
-
-   Each DNS Resource Record (RR) has a label, class, type, and data.  It
-   is meaningless for two records to ever have label, class, type and
-   data all equal - servers should suppress such duplicates if
-   encountered.  It is however possible for most record types to exist
-   with the same label, class and type, but with different data.  Such a
-   group of records is hereby defined to be a Resource Record Set
-   (RRSet).
-
-5.1. Sending RRs from an RRSet
-
-   A query for a specific (or non-specific) label, class, and type, will
-   always return all records in the associated RRSet - whether that be
-   one or more RRs.  The response must be marked as "truncated" if the
-   entire RRSet will not fit in the response.
-
-5.2. TTLs of RRs in an RRSet
-
-   Resource Records also have a time to live (TTL).  It is possible for
-   the RRs in an RRSet to have different TTLs.  No uses for this have
-   been found that cannot be better accomplished in other ways.  This
-   can, however, cause partial replies (not marked "truncated") from a
-   caching server, where the TTLs for some but not all the RRs in the
-   RRSet have expired.
-
-   Consequently the use of differing TTLs in an RRSet is hereby
-   deprecated, the TTLs of all RRs in an RRSet must be the same.
-
-   Should a client receive a response containing RRs from an RRSet with
-   differing TTLs, it should treat this as an error.  If the RRSet
-   concerned is from a non-authoritative source for this data, the
-   client should simply ignore the RRSet, and if the values were
-   required, seek to acquire them from an authoritative source.  Clients
-   that are configured to send all queries to one, or more, particular
-   servers should treat those servers as authoritative for this purpose.
-   Should an authoritative source send such a malformed RRSet, the
-
-
-
-Elz & Bush                  Standards Track                     [Page 4]
-
-RFC 2181        Clarifications to the DNS Specification        July 1997
-
-
-   client should treat the RRs for all purposes as if all TTLs in the
-   RRSet had been set to the value of the lowest TTL in the RRSet.  In
-   no case may a server send an RRSet with TTLs not all equal.
-
-5.3. DNSSEC Special Cases
-
-   Two of the record types added by DNS Security (DNSSEC) [RFC2065]
-   require special attention when considering the formation of Resource
-   Record Sets.  Those are the SIG and NXT records.  It should be noted
-   that DNS Security is still very new, and there is, as yet, little
-   experience with it.  Readers should be prepared for the information
-   related to DNSSEC contained in this document to become outdated as
-   the DNS Security specification matures.
-
-5.3.1. SIG records and RRSets
-
-   A SIG record provides signature (validation) data for another RRSet
-   in the DNS.  Where a zone has been signed, every RRSet in the zone
-   will have had a SIG record associated with it.  The data type of the
-   RRSet is included in the data of the SIG RR, to indicate with which
-   particular RRSet this SIG record is associated.  Were the rules above
-   applied, whenever a SIG record was included with a response to
-   validate that response, the SIG records for all other RRSets
-   associated with the appropriate node would also need to be included.
-   In some cases, this could be a very large number of records, not
-   helped by their being rather large RRs.
-
-   Thus, it is specifically permitted for the authority section to
-   contain only those SIG RRs with the "type covered" field equal to the
-   type field of an answer being returned.  However, where SIG records
-   are being returned in the answer section, in response to a query for
-   SIG records, or a query for all records associated with a name
-   (type=ANY) the entire SIG RRSet must be included, as for any other RR
-   type.
-
-   Servers that receive responses containing SIG records in the
-   authority section, or (probably incorrectly) as additional data, must
-   understand that the entire RRSet has almost certainly not been
-   included.  Thus, they must not cache that SIG record in a way that
-   would permit it to be returned should a query for SIG records be
-   received at that server.  RFC2065 actually requires that SIG queries
-   be directed only to authoritative servers to avoid the problems that
-   could be caused here, and while servers exist that do not understand
-   the special properties of SIG records, this will remain necessary.
-   However, careful design of SIG record processing in new
-   implementations should permit this restriction to be relaxed in the
-   future, so resolvers do not need to treat SIG record queries
-   specially.
-
-
-
-Elz & Bush                  Standards Track                     [Page 5]
-
-RFC 2181        Clarifications to the DNS Specification        July 1997
-
-
-   It has been occasionally stated that a received request for a SIG
-   record should be forwarded to an authoritative server, rather than
-   being answered from data in the cache.  This is not necessary - a
-   server that has the knowledge of SIG as a special case for processing
-   this way would be better to correctly cache SIG records, taking into
-   account their characteristics.  Then the server can determine when it
-   is safe to reply from the cache, and when the answer is not available
-   and the query must be forwarded.
-
-5.3.2. NXT RRs
-
-   Next Resource Records (NXT) are even more peculiar.  There will only
-   ever be one NXT record in a zone for a particular label, so
-   superficially, the RRSet problem is trivial.  However, at a zone cut,
-   both the parent zone, and the child zone (superzone and subzone in
-   RFC2065 terminology) will have NXT records for the same name.  Those
-   two NXT records do not form an RRSet, even where both zones are
-   housed at the same server.  NXT RRSets always contain just a single
-   RR.  Where both NXT records are visible, two RRSets exist.  However,
-   servers are not required to treat this as a special case when
-   receiving NXT records in a response.  They may elect to notice the
-   existence of two different NXT RRSets, and treat that as they would
-   two different RRSets of any other type.  That is, cache one, and
-   ignore the other.  Security aware servers will need to correctly
-   process the NXT record in the received response though.
-
-5.4. Receiving RRSets
-
-   Servers must never merge RRs from a response with RRs in their cache
-   to form an RRSet.  If a response contains data that would form an
-   RRSet with data in a server's cache the server must either ignore the
-   RRs in the response, or discard the entire RRSet currently in the
-   cache, as appropriate.  Consequently the issue of TTLs varying
-   between the cache and a response does not cause concern, one will be
-   ignored.  That is, one of the data sets is always incorrect if the
-   data from an answer differs from the data in the cache.  The
-   challenge for the server is to determine which of the data sets is
-   correct, if one is, and retain that, while ignoring the other.  Note
-   that if a server receives an answer containing an RRSet that is
-   identical to that in its cache, with the possible exception of the
-   TTL value, it may, optionally, update the TTL in its cache with the
-   TTL of the received answer.  It should do this if the received answer
-   would be considered more authoritative (as discussed in the next
-   section) than the previously cached answer.
-
-
-
-
-
-
-
-Elz & Bush                  Standards Track                     [Page 6]
-
-RFC 2181        Clarifications to the DNS Specification        July 1997
-
-
-5.4.1. Ranking data
-
-   When considering whether to accept an RRSet in a reply, or retain an
-   RRSet already in its cache instead, a server should consider the
-   relative likely trustworthiness of the various data.  An
-   authoritative answer from a reply should replace cached data that had
-   been obtained from additional information in an earlier reply.
-   However additional information from a reply will be ignored if the
-   cache contains data from an authoritative answer or a zone file.
-
-   The accuracy of data available is assumed from its source.
-   Trustworthiness shall be, in order from most to least:
-
-     + Data from a primary zone file, other than glue data,
-     + Data from a zone transfer, other than glue,
-     + The authoritative data included in the answer section of an
-       authoritative reply.
-     + Data from the authority section of an authoritative answer,
-     + Glue from a primary zone, or glue from a zone transfer,
-     + Data from the answer section of a non-authoritative answer, and
-       non-authoritative data from the answer section of authoritative
-       answers,
-     + Additional information from an authoritative answer,
-       Data from the authority section of a non-authoritative answer,
-       Additional information from non-authoritative answers.
-
-   Note that the answer section of an authoritative answer normally
-   contains only authoritative data.  However when the name sought is an
-   alias (see section 10.1.1) only the record describing that alias is
-   necessarily authoritative.  Clients should assume that other records
-   may have come from the server's cache.  Where authoritative answers
-   are required, the client should query again, using the canonical name
-   associated with the alias.
-
-   Unauthenticated RRs received and cached from the least trustworthy of
-   those groupings, that is data from the additional data section, and
-   data from the authority section of a non-authoritative answer, should
-   not be cached in such a way that they would ever be returned as
-   answers to a received query.  They may be returned as additional
-   information where appropriate.  Ignoring this would allow the
-   trustworthiness of relatively untrustworthy data to be increased
-   without cause or excuse.
-
-   When DNS security [RFC2065] is in use, and an authenticated reply has
-   been received and verified, the data thus authenticated shall be
-   considered more trustworthy than unauthenticated data of the same
-   type.  Note that throughout this document, "authoritative" means a
-   reply with the AA bit set.  DNSSEC uses trusted chains of SIG and KEY
-
-
-
-Elz & Bush                  Standards Track                     [Page 7]
-
-RFC 2181        Clarifications to the DNS Specification        July 1997
-
-
-   records to determine the authenticity of data, the AA bit is almost
-   irrelevant.  However DNSSEC aware servers must still correctly set
-   the AA bit in responses to enable correct operation with servers that
-   are not security aware (almost all currently).
-
-   Note that, glue excluded, it is impossible for data from two
-   correctly configured primary zone files, two correctly configured
-   secondary zones (data from zone transfers) or data from correctly
-   configured primary and secondary zones to ever conflict.  Where glue
-   for the same name exists in multiple zones, and differs in value, the
-   nameserver should select data from a primary zone file in preference
-   to secondary, but otherwise may choose any single set of such data.
-   Choosing that which appears to come from a source nearer the
-   authoritative data source may make sense where that can be
-   determined.  Choosing primary data over secondary allows the source
-   of incorrect glue data to be discovered more readily, when a problem
-   with such data exists.  Where a server can detect from two zone files
-   that one or more are incorrectly configured, so as to create
-   conflicts, it should refuse to load the zones determined to be
-   erroneous, and issue suitable diagnostics.
-
-   "Glue" above includes any record in a zone file that is not properly
-   part of that zone, including nameserver records of delegated sub-
-   zones (NS records), address records that accompany those NS records
-   (A, AAAA, etc), and any other stray data that might appear.
-
-5.5. Sending RRSets (reprise)
-
-   A Resource Record Set should only be included once in any DNS reply.
-   It may occur in any of the Answer, Authority, or Additional
-   Information sections, as required.  However it should not be repeated
-   in the same, or any other, section, except where explicitly required
-   by a specification.  For example, an AXFR response requires the SOA
-   record (always an RRSet containing a single RR) be both the first and
-   last record of the reply.  Where duplicates are required this way,
-   the TTL transmitted in each case must be the same.
-
-6. Zone Cuts
-
-   The DNS tree is divided into "zones", which are collections of
-   domains that are treated as a unit for certain management purposes.
-   Zones are delimited by "zone cuts".  Each zone cut separates a
-   "child" zone (below the cut) from a "parent" zone (above the cut).
-   The domain name that appears at the top of a zone (just below the cut
-   that separates the zone from its parent) is called the zone's
-   "origin".  The name of the zone is the same as the name of the domain
-   at the zone's origin.  Each zone comprises that subset of the DNS
-   tree that is at or below the zone's origin, and that is above the
-
-
-
-Elz & Bush                  Standards Track                     [Page 8]
-
-RFC 2181        Clarifications to the DNS Specification        July 1997
-
-
-   cuts that separate the zone from its children (if any).  The
-   existence of a zone cut is indicated in the parent zone by the
-   existence of NS records specifying the origin of the child zone.  A
-   child zone does not contain any explicit reference to its parent.
-
-6.1. Zone authority
-
-   The authoritative servers for a zone are enumerated in the NS records
-   for the origin of the zone, which, along with a Start of Authority
-   (SOA) record are the mandatory records in every zone.  Such a server
-   is authoritative for all resource records in a zone that are not in
-   another zone.  The NS records that indicate a zone cut are the
-   property of the child zone created, as are any other records for the
-   origin of that child zone, or any sub-domains of it.  A server for a
-   zone should not return authoritative answers for queries related to
-   names in another zone, which includes the NS, and perhaps A, records
-   at a zone cut, unless it also happens to be a server for the other
-   zone.
-
-   Other than the DNSSEC cases mentioned immediately below, servers
-   should ignore data other than NS records, and necessary A records to
-   locate the servers listed in the NS records, that may happen to be
-   configured in a zone at a zone cut.
-
-6.2. DNSSEC issues
-
-   The DNS security mechanisms [RFC2065] complicate this somewhat, as
-   some of the new resource record types added are very unusual when
-   compared with other DNS RRs.  In particular the NXT ("next") RR type
-   contains information about which names exist in a zone, and hence
-   which do not, and thus must necessarily relate to the zone in which
-   it exists.  The same domain name may have different NXT records in
-   the parent zone and the child zone, and both are valid, and are not
-   an RRSet.  See also section 5.3.2.
-
-   Since NXT records are intended to be automatically generated, rather
-   than configured by DNS operators, servers may, but are not required
-   to, retain all differing NXT records they receive regardless of the
-   rules in section 5.4.
-
-   For a secure parent zone to securely indicate that a subzone is
-   insecure, DNSSEC requires that a KEY RR indicating that the subzone
-   is insecure, and the parent zone's authenticating SIG RR(s) be
-   present in the parent zone, as they by definition cannot be in the
-   subzone.  Where a subzone is secure, the KEY and SIG records will be
-   present, and authoritative, in that zone, but should also always be
-   present in the parent zone (if secure).
-
-
-
-
-Elz & Bush                  Standards Track                     [Page 9]
-
-RFC 2181        Clarifications to the DNS Specification        July 1997
-
-
-   Note that in none of these cases should a server for the parent zone,
-   not also being a server for the subzone, set the AA bit in any
-   response for a label at a zone cut.
-
-7. SOA RRs
-
-   Three minor issues concerning the Start of Zone of Authority (SOA)
-   Resource Record need some clarification.
-
-7.1. Placement of SOA RRs in authoritative answers
-
-   RFC1034, in section 3.7, indicates that the authority section of an
-   authoritative answer may contain the SOA record for the zone from
-   which the answer was obtained.  When discussing negative caching,
-   RFC1034 section 4.3.4 refers to this technique but mentions the
-   additional section of the response.  The former is correct, as is
-   implied by the example shown in section 6.2.5 of RFC1034.  SOA
-   records, if added, are to be placed in the authority section.
-
-7.2. TTLs on SOA RRs
-
-   It may be observed that in section 3.2.1 of RFC1035, which defines
-   the format of a Resource Record, that the definition of the TTL field
-   contains a throw away line which states that the TTL of an SOA record
-   should always be sent as zero to prevent caching.  This is mentioned
-   nowhere else, and has not generally been implemented.
-   Implementations should not assume that SOA records will have a TTL of
-   zero, nor are they required to send SOA records with a TTL of zero.
-
-7.3. The SOA.MNAME field
-
-   It is quite clear in the specifications, yet seems to have been
-   widely ignored, that the MNAME field of the SOA record should contain
-   the name of the primary (master) server for the zone identified by
-   the SOA.  It should not contain the name of the zone itself.  That
-   information would be useless, as to discover it, one needs to start
-   with the domain name of the SOA record - that is the name of the
-   zone.
-
-8. Time to Live (TTL)
-
-   The definition of values appropriate to the TTL field in STD 13 is
-   not as clear as it could be, with respect to how many significant
-   bits exist, and whether the value is signed or unsigned.  It is
-   hereby specified that a TTL value is an unsigned number, with a
-   minimum value of 0, and a maximum value of 2147483647.  That is, a
-   maximum of 2^31 - 1.  When transmitted, this value shall be encoded
-   in the less significant 31 bits of the 32 bit TTL field, with the
-
-
-
-Elz & Bush                  Standards Track                    [Page 10]
-
-RFC 2181        Clarifications to the DNS Specification        July 1997
-
-
-   most significant, or sign, bit set to zero.
-
-   Implementations should treat TTL values received with the most
-   significant bit set as if the entire value received was zero.
-
-   Implementations are always free to place an upper bound on any TTL
-   received, and treat any larger values as if they were that upper
-   bound.  The TTL specifies a maximum time to live, not a mandatory
-   time to live.
-
-9. The TC (truncated) header bit
-
-   The TC bit should be set in responses only when an RRSet is required
-   as a part of the response, but could not be included in its entirety.
-   The TC bit should not be set merely because some extra information
-   could have been included, but there was insufficient room.  This
-   includes the results of additional section processing.  In such cases
-   the entire RRSet that will not fit in the response should be omitted,
-   and the reply sent as is, with the TC bit clear.  If the recipient of
-   the reply needs the omitted data, it can construct a query for that
-   data and send that separately.
-
-   Where TC is set, the partial RRSet that would not completely fit may
-   be left in the response.  When a DNS client receives a reply with TC
-   set, it should ignore that response, and query again, using a
-   mechanism, such as a TCP connection, that will permit larger replies.
-
-10. Naming issues
-
-   It has sometimes been inferred from some sections of the DNS
-   specification [RFC1034, RFC1035] that a host, or perhaps an interface
-   of a host, is permitted exactly one authoritative, or official, name,
-   called the canonical name.  There is no such requirement in the DNS.
-
-10.1. CNAME resource records
-
-   The DNS CNAME ("canonical name") record exists to provide the
-   canonical name associated with an alias name.  There may be only one
-   such canonical name for any one alias.  That name should generally be
-   a name that exists elsewhere in the DNS, though there are some rare
-   applications for aliases with the accompanying canonical name
-   undefined in the DNS.  An alias name (label of a CNAME record) may,
-   if DNSSEC is in use, have SIG, NXT, and KEY RRs, but may have no
-   other data.  That is, for any label in the DNS (any domain name)
-   exactly one of the following is true:
-
-
-
-
-
-
-Elz & Bush                  Standards Track                    [Page 11]
-
-RFC 2181        Clarifications to the DNS Specification        July 1997
-
-
-     + one CNAME record exists, optionally accompanied by SIG, NXT, and
-       KEY RRs,
-     + one or more records exist, none being CNAME records,
-     + the name exists, but has no associated RRs of any type,
-     + the name does not exist at all.
-
-10.1.1. CNAME terminology
-
-   It has been traditional to refer to the label of a CNAME record as "a
-   CNAME".  This is unfortunate, as "CNAME" is an abbreviation of
-   "canonical name", and the label of a CNAME record is most certainly
-   not a canonical name.  It is, however, an entrenched usage.  Care
-   must therefore be taken to be very clear whether the label, or the
-   value (the canonical name) of a CNAME resource record is intended.
-   In this document, the label of a CNAME resource record will always be
-   referred to as an alias.
-
-10.2. PTR records
-
-   Confusion about canonical names has lead to a belief that a PTR
-   record should have exactly one RR in its RRSet.  This is incorrect,
-   the relevant section of RFC1034 (section 3.6.2) indicates that the
-   value of a PTR record should be a canonical name.  That is, it should
-   not be an alias.  There is no implication in that section that only
-   one PTR record is permitted for a name.  No such restriction should
-   be inferred.
-
-   Note that while the value of a PTR record must not be an alias, there
-   is no requirement that the process of resolving a PTR record not
-   encounter any aliases.  The label that is being looked up for a PTR
-   value might have a CNAME record.  That is, it might be an alias.  The
-   value of that CNAME RR, if not another alias, which it should not be,
-   will give the location where the PTR record is found.  That record
-   gives the result of the PTR type lookup.  This final result, the
-   value of the PTR RR, is the label which must not be an alias.
-
-10.3. MX and NS records
-
-   The domain name used as the value of a NS resource record, or part of
-   the value of a MX resource record must not be an alias.  Not only is
-   the specification clear on this point, but using an alias in either
-   of these positions neither works as well as might be hoped, nor well
-   fulfills the ambition that may have led to this approach.  This
-   domain name must have as its value one or more address records.
-   Currently those will be A records, however in the future other record
-   types giving addressing information may be acceptable.  It can also
-   have other RRs, but never a CNAME RR.
-
-
-
-
-Elz & Bush                  Standards Track                    [Page 12]
-
-RFC 2181        Clarifications to the DNS Specification        July 1997
-
-
-   Searching for either NS or MX records causes "additional section
-   processing" in which address records associated with the value of the
-   record sought are appended to the answer.  This helps avoid needless
-   extra queries that are easily anticipated when the first was made.
-
-   Additional section processing does not include CNAME records, let
-   alone the address records that may be associated with the canonical
-   name derived from the alias.  Thus, if an alias is used as the value
-   of an NS or MX record, no address will be returned with the NS or MX
-   value.  This can cause extra queries, and extra network burden, on
-   every query.  It is trivial for the DNS administrator to avoid this
-   by resolving the alias and placing the canonical name directly in the
-   affected record just once when it is updated or installed.  In some
-   particular hard cases the lack of the additional section address
-   records in the results of a NS lookup can cause the request to fail.
-
-11. Name syntax
-
-   Occasionally it is assumed that the Domain Name System serves only
-   the purpose of mapping Internet host names to data, and mapping
-   Internet addresses to host names.  This is not correct, the DNS is a
-   general (if somewhat limited) hierarchical database, and can store
-   almost any kind of data, for almost any purpose.
-
-   The DNS itself places only one restriction on the particular labels
-   that can be used to identify resource records.  That one restriction
-   relates to the length of the label and the full name.  The length of
-   any one label is limited to between 1 and 63 octets.  A full domain
-   name is limited to 255 octets (including the separators).  The zero
-   length full name is defined as representing the root of the DNS tree,
-   and is typically written and displayed as ".".  Those restrictions
-   aside, any binary string whatever can be used as the label of any
-   resource record.  Similarly, any binary string can serve as the value
-   of any record that includes a domain name as some or all of its value
-   (SOA, NS, MX, PTR, CNAME, and any others that may be added).
-   Implementations of the DNS protocols must not place any restrictions
-   on the labels that can be used.  In particular, DNS servers must not
-   refuse to serve a zone because it contains labels that might not be
-   acceptable to some DNS client programs.  A DNS server may be
-   configurable to issue warnings when loading, or even to refuse to
-   load, a primary zone containing labels that might be considered
-   questionable, however this should not happen by default.
-
-   Note however, that the various applications that make use of DNS data
-   can have restrictions imposed on what particular values are
-   acceptable in their environment.  For example, that any binary label
-   can have an MX record does not imply that any binary name can be used
-   as the host part of an e-mail address.  Clients of the DNS can impose
-
-
-
-Elz & Bush                  Standards Track                    [Page 13]
-
-RFC 2181        Clarifications to the DNS Specification        July 1997
-
-
-   whatever restrictions are appropriate to their circumstances on the
-   values they use as keys for DNS lookup requests, and on the values
-   returned by the DNS.  If the client has such restrictions, it is
-   solely responsible for validating the data from the DNS to ensure
-   that it conforms before it makes any use of that data.
-
-   See also [RFC1123] section 6.1.3.5.
-
-12. Security Considerations
-
-   This document does not consider security.
-
-   In particular, nothing in section 4 is any way related to, or useful
-   for, any security related purposes.
-
-   Section 5.4.1 is also not related to security.  Security of DNS data
-   will be obtained by the Secure DNS [RFC2065], which is mostly
-   orthogonal to this memo.
-
-   It is not believed that anything in this document adds to any
-   security issues that may exist with the DNS, nor does it do anything
-   to that will necessarily lessen them.  Correct implementation of the
-   clarifications in this document might play some small part in
-   limiting the spread of non-malicious bad data in the DNS, but only
-   DNSSEC can help with deliberate attempts to subvert DNS data.
-
-13. References
-
-   [RFC1034]   Mockapetris, P., "Domain Names - Concepts and Facilities",
-               STD 13, RFC 1034, November 1987.
-
-   [RFC1035]   Mockapetris, P., "Domain Names - Implementation and
-               Specification", STD 13, RFC 1035, November 1987.
-
-   [RFC1123]   Braden, R., "Requirements for Internet Hosts - application
-               and support", STD 3, RFC 1123, January 1989.
-
-   [RFC1700]   Reynolds, J., Postel, J., "Assigned Numbers",
-               STD 2, RFC 1700, October 1994.
-
-   [RFC2065]   Eastlake, D., Kaufman, C., "Domain Name System Security
-               Extensions", RFC 2065, January 1997.
-
-
-
-
-
-
-
-
-
-Elz & Bush                  Standards Track                    [Page 14]
-
-RFC 2181        Clarifications to the DNS Specification        July 1997
-
-
-14. Acknowledgements
-
-   This memo arose from discussions in the DNSIND working group of the
-   IETF in 1995 and 1996, the members of that working group are largely
-   responsible for the ideas captured herein.  Particular thanks to
-   Donald E. Eastlake, 3rd, and Olafur Gudmundsson, for help with the
-   DNSSEC issues in this document, and to John Gilmore for pointing out
-   where the clarifications were not necessarily clarifying.  Bob Halley
-   suggested clarifying the placement of SOA records in authoritative
-   answers, and provided the references.  Michael Patton, as usual, and
-   Mark Andrews, Alan Barrett and Stan Barber provided much assistance
-   with many details.  Josh Littlefield helped make sure that the
-   clarifications didn't cause problems in some irritating corner cases.
-
-15. Authors' Addresses
-
-   Robert Elz
-   Computer Science
-   University of Melbourne
-   Parkville, Victoria, 3052
-   Australia.
-
-   EMail: kre@munnari.OZ.AU
-
-
-   Randy Bush
-   RGnet, Inc.
-   5147 Crystal Springs Drive NE
-   Bainbridge Island, Washington,  98110
-   United States.
-
-   EMail: randy@psg.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Elz & Bush                  Standards Track                    [Page 15]
diff --git a/contrib/bind9/doc/rfc/rfc2230.txt b/contrib/bind9/doc/rfc/rfc2230.txt
deleted file mode 100644
index 03995fe..0000000
--- a/contrib/bind9/doc/rfc/rfc2230.txt
+++ /dev/null
@@ -1,619 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         R. Atkinson
-Request for Comments: 2230                                            NRL
-Category: Informational                                     November 1997
-
-
-               Key Exchange Delegation Record for the DNS
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1997).  All Rights Reserved.
-
-ABSTRACT
-
-   This note describes a mechanism whereby authorisation for one node to
-   act as key exchanger for a second node is delegated and made
-   available via the Secure DNS.  This mechanism is intended to be used
-   only with the Secure DNS.  It can be used with several security
-   services.  For example, a system seeking to use IP Security [RFC-
-   1825, RFC-1826, RFC-1827] to protect IP packets for a given
-   destination can use this mechanism to determine the set of authorised
-   remote key exchanger systems for that destination.
-
-1. INTRODUCTION
-
-
-   The Domain Name System (DNS) is the standard way that Internet nodes
-   locate information about addresses, mail exchangers, and other data
-   relating to remote Internet nodes. [RFC-1035, RFC-1034] More
-   recently, Eastlake and Kaufman have defined standards-track security
-   extensions to the DNS. [RFC-2065] These security extensions can be
-   used to authenticate signed DNS data records and can also be used to
-   store signed public keys in the DNS.
-
-   The KX record is useful in providing an authenticatible method of
-   delegating authorisation for one node to provide key exchange
-   services on behalf of one or more, possibly different, nodes.  This
-   note specifies the syntax and semantics of the KX record, which is
-   currently in limited deployment in certain IP-based networks.  The
-
-
-
-
-
-
-
-Atkinson                     Informational                      [Page 1]
-
-RFC 2230           DNS Key Exchange Delegation Record      November 1997
-
-
-   reader is assumed to be familiar with the basics of DNS, including
-   familiarity with [RFC-1035, RFC-1034].  This document is not on the
-   IETF standards-track and does not specify any level of standard.
-   This document merely provides information for the Internet community.
-
-1.1 Identity Terminology
-
-   This document relies upon the concept of "identity domination".  This
-   concept might be new to the reader and so is explained in this
-   section.  The subject of endpoint naming for security associations
-   has historically been somewhat contentious.  This document takes no
-   position on what forms of identity should be used.  In a network,
-   there are several forms of identity that are possible.
-
-   For example, IP Security has defined notions of identity that
-   include: IP Address, IP Address Range, Connection ID, Fully-Qualified
-   Domain Name (FQDN), and User with Fully Qualified Domain Name (USER
-   FQDN).
-
-   A USER FQDN identity dominates a FQDN identity.  A FQDN identity in
-   turn dominates an IP Address identity.  Similarly, a Connection ID
-   dominates an IP Address identity.  An IP Address Range dominates each
-   IP Address identity for each IP address within that IP address range.
-   Also, for completeness, an IP Address identity is considered to
-   dominate itself.
-
-2. APPROACH
-
-   This document specifies a new kind of DNS Resource Record (RR), known
-   as the Key Exchanger (KX) record.  A Key Exchanger Record has the
-   mnemonic "KX" and the type code of 36.  Each KX record is associated
-   with a fully-qualified domain name.  The KX record is modeled on the
-   MX record described in [Part86]. Any given domain, subdomain, or host
-   entry in the DNS might have a KX record.
-
-2.1 IPsec Examples
-
-   In these two examples, let S be the originating node and let D be the
-   destination node.  S2 is another node on the same subnet as S.  D2 is
-   another node on the same subnet as D.  R1 and R2 are IPsec-capable
-   routers.  The path from S to D goes via first R1 and later R2.  The
-   return path from D to S goes via first R2 and later R1.
-
-   IETF-standard IP Security uses unidirectional Security Associations
-   [RFC-1825].  Therefore, a typical IP session will use a pair of
-   related Security Associations, one in each direction.  The examples
-   below talk about how to setup an example Security Association, but in
-   practice a pair of matched Security Associations will normally be
-
-
-
-Atkinson                     Informational                      [Page 2]
-
-RFC 2230           DNS Key Exchange Delegation Record      November 1997
-
-
-   used.
-
-2.1.1 Subnet-to-Subnet Example
-
-   If neither S nor D implements IPsec, security can still be provided
-   between R1 and R2 by building a secure tunnel.  This can use either
-   AH or ESP.
-
-       S ---+                                          +----D
-            |                                          |
-            +- R1 -----[zero or more routers]-------R2-+
-            |                                          |
-       S2---+                                          +----D2
-
-       Figure 1:  Network Diagram for Subnet-to-Subnet Example
-
-   In this example, R1 makes the policy decision to provide the IPsec
-   service for traffic from R1 destined for R2.  Once R1 has decided
-   that the packet from S to D should be protected, it performs a secure
-   DNS lookup for the records associated with domain D.  If R1 only
-   knows the IP address for D, then a secure reverse DNS lookup will be
-   necessary to determine the domain D, before that forward secure DNS
-   lookup for records associated with domain D.  If these DNS records of
-   domain D include a KX record for the IPsec service, then R1 knows
-   which set of nodes are authorised key exchanger nodes for the
-   destination D.
-
-   In this example, let there be at least one KX record for D and let
-   the most preferred KX record for D point at R2.  R1 then selects a
-   key exchanger (in this example, R2) for D from the list obtained from
-   the secure DNS.  Then R1 initiates a key management session with that
-   key exchanger (in this example, R2) to setup an IPsec Security
-   Association between R1 and D.  In this example, R1 knows (either by
-   seeing an outbound packet arriving from S destined to D or via other
-   methods) that S will be sending traffic to D.  In this example R1's
-   policy requires that traffic from S to D should be segregated at
-   least on a host-to-host basis, so R1 desires an IPsec Security
-   Association with source identity that dominates S, proxy identity
-   that dominates R1, and destination identity that dominates R2.
-
-   In turn, R2 is able to authenticate the delegation of Key Exchanger
-   authorisation for target S to R1 by making an authenticated forward
-   DNS lookup for KX records associated with S and verifying that at
-   least one such record points to R1.  The identity S is typically
-   given to R2 as part of the key management process between R1 and R2.
-
-
-
-
-
-
-Atkinson                     Informational                      [Page 3]
-
-RFC 2230           DNS Key Exchange Delegation Record      November 1997
-
-
-   If D initially only knows the IP address of S, then it will need to
-   perform a secure reverse DNS lookup to obtain the fully-qualified
-   domain name for S prior to that secure forward DNS lookup.
-
-   If R2 does not receive an authenticated DNS response indicating that
-   R1 is an authorised key exchanger for S, then D will not accept the
-   SA negotiation from R1 on behalf of identity S.
-
-   If the proposed IPsec Security Association is acceptable to both R1
-   and R2, each of which might have separate policies, then they create
-   that IPsec Security Association via Key Management.
-
-   Note that for unicast traffic, Key Management will typically also
-   setup a separate (but related) IPsec Security Association for the
-   return traffic.  That return IPsec Security Association will have
-   equivalent identities.  In this example, that return IPsec Security
-   Association will have a source identity that dominates D, a proxy
-   identity that dominates R2, and a destination identity that dominates
-   R1.
-
-   Once the IPsec Security Association has been created, then R1 uses it
-   to protect traffic from S destined for D via a secure tunnel that
-   originates at R1 and terminates at R2.  For the case of unicast, R2
-   will use the return IPsec Security Association to protect traffic
-   from D destined for S via a secure tunnel that originates at R2 and
-   terminates at R1.
-
-2.1.2 Subnet-to-Host Example
-
-   Consider the case where D and R1 implement IPsec, but S does not
-   implement IPsec, which is an interesting variation on the previous
-   example.  This example is shown in Figure 2 below.
-
-       S ---+
-            |
-            +- R1 -----[zero or more routers]-------D
-            |
-       S2---+
-
-       Figure 2:  Network Diagram for Subnet-to-Host Example
-
-   In this example, R1 makes the policy decision that IP Security is
-   needed for the packet travelling from S to D.  Then, R1 performs the
-   secure DNS lookup for D and determines that D is its own key
-   exchanger, either from the existence of a KX record for D pointing to
-   D or from an authenticated DNS response indicating that no KX record
-   exists for D.  If R1 does not initially know the domain name of D,
-   then prior to the above forward secure DNS lookup, R1 performs a
-
-
-
-Atkinson                     Informational                      [Page 4]
-
-RFC 2230           DNS Key Exchange Delegation Record      November 1997
-
-
-   secure reverse DNS lookup on the IP address of D to determine the
-   fully-qualified domain name for that IP address.  R1 then initiates
-   key management with D to create an IPsec Security Association on
-   behalf of S.
-
-   In turn, D can verify that R1 is authorised to create an IPsec
-   Security Association on behalf of S by performing a DNS KX record
-   lookup for target S.  R1 usually provides identity S to D via key
-   management.  If D only has the IP address of S, then D will need to
-   perform a secure reverse lookup on the IP address of S to determine
-   domain name S prior to the secure forward DNS lookup on S to locate
-   the KX records for S.
-
-   If D does not receive an authenticated DNS response indicating that
-   R1 is an authorised key exchanger for S, then D will not accept the
-   SA negotiation from R1 on behalf of identity S.
-
-   If the IPsec Security Association is successfully established between
-   R1 and D, that IPsec Security Association has a source identity that
-   dominates S's IP address, a proxy identity that dominates R1's IP
-   address, and a destination identity that dominates D's IP address.
-
-   Finally, R1 begins providing the security service for packets from S
-   that transit R1 destined for D.  When D receives such packets, D
-   examines the SA information during IPsec input processing and sees
-   that R1's address is listed as valid proxy address for that SA and
-   that S is the source address for that SA.  Hence, D knows at input
-   processing time that R1 is authorised to provide security on behalf
-   of S.  Therefore packets coming from R1 with valid IP security that
-   claim to be from S are trusted by D to have really come from S.
-
-2.1.3 Host to Subnet Example
-
-   Now consider the above case from D's perspective (i.e. where D is
-   sending IP packets to S).  This variant is sometimes known as the
-   Mobile Host or "roadwarrier" case. The same basic concepts apply, but
-   the details are covered here in hope of improved clarity.
-
-       S ---+
-            |
-            +- R1 -----[zero or more routers]-------D
-            |
-       S2---+
-
-       Figure 3:  Network Diagram for Host-to-Subnet Example
-
-
-
-
-
-
-Atkinson                     Informational                      [Page 5]
-
-RFC 2230           DNS Key Exchange Delegation Record      November 1997
-
-
-   In this example, D makes the policy decision that IP Security is
-   needed for the packets from D to S.  Then D performs the secure DNS
-   lookup for S and discovers that a KX record for S exists and points
-   at R1.  If D only has the IP address of S, then it performs a secure
-   reverse DNS lookup on the IP address of S prior to the forward secure
-   DNS lookup for S.
-
-   D then initiates key management with R1, where R1 is acting on behalf
-   of S, to create an appropriate Security Association.  Because D is
-   acting as its own key exchanger, R1 does not need to perform a secure
-   DNS lookup for KX records associated with D.
-
-   D and R1 then create an appropriate IPsec Security Security
-   Association.  This IPsec Security Association is setup as a secure
-   tunnel with a source identity that dominates D's IP Address and a
-   destination identity that dominates R1's IP Address.  Because D
-   performs IPsec for itself, no proxy identity is needed in this IPsec
-   Security Association.  If the proxy identity is non-null in this
-   situation, then the proxy identity must dominate D's IP Address.
-
-   Finally, D sends secured IP packets to R1.  R1 receives those
-   packets, provides IPsec input processing (including appropriate
-   inner/outer IP address validation), and forwards valid packets along
-   to S.
-
-2.2 Other Examples
-
-   This mechanism can be extended for use with other services as well.
-   To give some insight into other possible uses, this section discusses
-   use of KX records in environments using a Key Distribution Center
-   (KDC), such as Kerberos [KN93], and a possible use of KX records in
-   conjunction with mobile nodes accessing the network via a dialup
-   service.
-
-2.2.1 KDC Examples
-
-   This example considers the situation of a destination node
-   implementing IPsec that can only obtain its Security Association
-   information from a Key Distribution Center (KDC).  Let the KDC
-   implement both the KDC protocol and also a non-KDC key management
-   protocol (e.g. ISAKMP).  In such a case, each client node of the KDC
-   might have its own KX record pointing at the KDC so that nodes not
-   implementing the KDC protocol can still create Security Associations
-   with each of the client nodes of the KDC.
-
-   In the event the session initiator were not using the KDC but the
-   session target was an IPsec node that only used the KDC, the
-   initiator would find the KX record for the target pointing at the
-
-
-
-Atkinson                     Informational                      [Page 6]
-
-RFC 2230           DNS Key Exchange Delegation Record      November 1997
-
-
-   KDC.  Then, the external key management exchange (e.g. ISAKMP) would
-   be between the initiator and the KDC.  Then the KDC would distribute
-   the IPsec SA to the KDC-only IPsec node using the KDC.  The IPsec
-   traffic itself could travel directly between the initiator and the
-   destination node.
-
-   In the event the initiator node could only use the KDC and the target
-   were not using the KDC, the initiator would send its request for a
-   key to the KDC.  The KDC would then initiate an external key
-   management exchange (e.g. ISAKMP) with a node that the target's KX
-   record(s) pointed to, on behalf of the initiator node.
-
-   The target node could verify that the KDC were allowed to proxy for
-   the initiator node by looking up the KX records for the initiator
-   node and finding a KX record for the initiator that listed the KDC.
-
-   Then the external key exchange would be performed between the KDC and
-   the target node.  Then the KDC would distribute the resulting IPsec
-   Security Association to the initiator.  Again, IPsec traffic itself
-   could travel directly between the initiator and the destination.
-
-2.2.2 Dial-Up Host Example
-
-   This example outlines a possible use of KX records with mobile hosts
-   that dial into the network via PPP and are dynamically assigned an IP
-   address and domain-name at dial-in time.
-
-   Consider the situation where each mobile node is dynamically assigned
-   both a domain name and an IP address at the time that node dials into
-   the network.  Let the policy require that each mobile node act as its
-   own Key Exchanger.  In this case, it is important that dial-in nodes
-   use addresses from one or more well known IP subnets or address pools
-   dedicated to dial-in access.  If that is true, then no KX record or
-   other action is needed to ensure that each node will act as its own
-   Key Exchanger because lack of a KX record indicates that the node is
-   its own Key Exchanger.
-
-   Consider the situation where the mobile node's domain name remains
-   constant but its IP address changes.  Let the policy require that
-   each mobile node act as its own Key Exchanger.  In this case, there
-   might be operational problems when another node attempts to perform a
-   secure reverse DNS lookup on the IP address to determine the
-   corresponding domain name.  The authenticated DNS binding (in the
-   form of a PTR record) between the mobile node's currently assigned IP
-   address and its permanent domain name will need to be securely
-   updated each time the node is assigned a new IP address.  There are
-   no mechanisms for accomplishing this that are both IETF-standard and
-   widely deployed as of the time this note was written.  Use of Dynamic
-
-
-
-Atkinson                     Informational                      [Page 7]
-
-RFC 2230           DNS Key Exchange Delegation Record      November 1997
-
-
-   DNS Update without authentication is a significant security risk and
-   hence is not recommended for this situation.
-
-3. SYNTAX OF KX RECORD
-
-   A KX record has the DNS TYPE of "KX" and a numeric value of 36.  A KX
-   record is a member of the Internet ("IN") CLASS in the DNS.  Each KX
-   record is associated with a <domain-name> entry in the DNS.  A KX
-   record has the following textual syntax:
-
-        <domain-name>  IN  KX  <preference> <domain-name>
-
-   For this description, let the <domain-name> item to the left of the
-   "KX" string be called <domain-name 1> and the <domain-name> item to
-   the right of the "KX" string be called <domain-name 2>.  <preference>
-   is a non-negative integer.
-
-   Internet nodes about to initiate a key exchange with <domain-name 1>
-   should instead contact <domain-name 2> to initiate the key exchange
-   for a security service between the initiator and <domain-name 2>.  If
-   more than one KX record exists for <domain-name 1>, then the
-   <preference> field is used to indicate preference among the systems
-   delegated to.  Lower values are preferred over higher values.  The
-   <domain-name 2> is authorised to provide key exchange services on
-   behalf of <domain-name 1>.  The <domain-name 2> MUST have a CNAME
-   record, an A record, or an AAAA record associated with it.
-
-3.1 KX RDATA format
-
-   The KX DNS record has the following RDATA format:
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                  PREFERENCE                   |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                   EXCHANGER                   /
-    /                                               /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-   where:
-
-   PREFERENCE      A 16 bit non-negative integer which specifies the
-                   preference given to this RR among other KX records
-                   at the same owner.  Lower values are preferred.
-
-   EXCHANGER       A <domain-name> which specifies a host willing to
-                   act as a mail exchange for the owner name.
-
-
-
-
-
-Atkinson                     Informational                      [Page 8]
-
-RFC 2230           DNS Key Exchange Delegation Record      November 1997
-
-
-   KX records MUST cause type A additional section processing for the
-   host specified by EXCHANGER.  In the event that the host processing
-   the DNS transaction supports IPv6, KX records MUST also cause type
-   AAAA additional section processing.
-
-   The KX RDATA field MUST NOT be compressed.
-
-4. SECURITY CONSIDERATIONS
-
-   KX records MUST always be signed using the method(s) defined by the
-   DNS Security extensions specified in [RFC-2065].  All unsigned KX
-   records MUST be ignored because of the security vulnerability caused
-   by assuming that unsigned records are valid.  All signed KX records
-   whose signatures do not correctly validate MUST be ignored because of
-   the potential security vulnerability in trusting an invalid KX
-   record.
-
-   KX records MUST be ignored by systems not implementing Secure DNS
-   because such systems have no mechanism to authenticate the KX record.
-
-   If a node does not have a permanent DNS entry and some form of
-   Dynamic DNS Update is in use, then those dynamic DNS updates MUST be
-   fully authenticated to prevent an adversary from injecting false DNS
-   records (especially the KX, A, and PTR records) into the Domain Name
-   System.  If false records were inserted into the DNS without being
-   signed by the Secure DNS mechanisms, then a denial-of-service attack
-   results.  If false records were inserted into the DNS and were
-   (erroneously) signed by the signing authority, then an active attack
-   results.
-
-   Myriad serious security vulnerabilities can arise if the restrictions
-   throuhout this document are not strictly adhered to.  Implementers
-   should carefully consider the openly published issues relating to DNS
-   security [Bell95,Vixie95] as they build their implementations.
-   Readers should also consider the security considerations discussed in
-   the DNS Security Extensions document [RFC-2065].
-
-5. REFERENCES
-
-
-   [RFC-1825]  Atkinson, R., "IP Authentication Header", RFC 1826,
-               August 1995.
-
-   [RFC-1827]  Atkinson, R., "IP Encapsulating Security Payload",
-               RFC 1827, August 1995.
-
-
-
-
-
-
-Atkinson                     Informational                      [Page 9]
-
-RFC 2230           DNS Key Exchange Delegation Record      November 1997
-
-
-   [Bell95] Bellovin, S., "Using the Domain Name System for System
-            Break-ins", Proceedings of 5th USENIX UNIX Security
-            Symposium, USENIX Association, Berkeley, CA, June 1995.
-            ftp://ftp.research.att.com/dist/smb/dnshack.ps
-
-   [RFC-2065]  Eastlake, D., and C. Kaufman, "Domain Name System
-               Security Extensions", RFC 2065, January 1997.
-
-   [RFC-1510]  Kohl J., and C. Neuman, "The Kerberos Network
-               Authentication Service", RFC 1510, September 1993.
-
-   [RFC-1035]  Mockapetris, P., "Domain names - implementation and
-               specification", STD 13, RFC 1035, November 1987.
-
-   [RFC-1034]  Mockapetris, P., "Domain names - concepts and
-               facilities", STD 13, RFC 1034, November 1987.
-
-   [Vixie95] P. Vixie, "DNS and BIND Security Issues", Proceedings of
-             the 5th USENIX UNIX Security Symposium, USENIX
-             Association, Berkeley, CA, June 1995.
-             ftp://ftp.vix.com/pri/vixie/bindsec.psf
-
-ACKNOWLEDGEMENTS
-
-   Development of this DNS record was primarily performed during 1993
-   through 1995.  The author's work on this was sponsored jointly by the
-   Computing Systems Technology Office (CSTO) of the Advanced Research
-   Projects Agency (ARPA) and by the Information Security Program Office
-   (PD71E), Space & Naval Warface Systems Command (SPAWAR).  In that
-   era, Dave Mihelcic and others provided detailed review and
-   constructive feedback.  More recently, Bob Moscowitz and Todd Welch
-   provided detailed review and constructive feedback of a work in
-   progress version of this document.
-
-AUTHOR'S ADDRESS
-
-   Randall Atkinson
-   Code 5544
-   Naval Research Laboratory
-   4555 Overlook Avenue, SW
-   Washington, DC 20375-5337
-
-   Phone: (DSN) 354-8590
-   EMail: atkinson@itd.nrl.navy.mil
-
-
-
-
-
-
-
-Atkinson                     Informational                     [Page 10]
-
-RFC 2230           DNS Key Exchange Delegation Record      November 1997
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (1997).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implmentation may be prepared, copied, published
-   andand distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Atkinson                     Informational                     [Page 11]
-
diff --git a/contrib/bind9/doc/rfc/rfc2308.txt b/contrib/bind9/doc/rfc/rfc2308.txt
deleted file mode 100644
index 9123a95..0000000
--- a/contrib/bind9/doc/rfc/rfc2308.txt
+++ /dev/null
@@ -1,1067 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          M. Andrews
-Request for Comments: 2308                                          CSIRO
-Updates: 1034, 1035                                            March 1998
-Category: Standards Track
-
-
-              Negative Caching of DNS Queries (DNS NCACHE)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-Abstract
-
-   [RFC1034] provided a description of how to cache negative responses.
-   It however had a fundamental flaw in that it did not allow a name
-   server to hand out those cached responses to other resolvers, thereby
-   greatly reducing the effect of the caching.  This document addresses
-   issues raise in the light of experience and replaces [RFC1034 Section
-   4.3.4].
-
-   Negative caching was an optional part of the DNS specification and
-   deals with the caching of the non-existence of an RRset [RFC2181] or
-   domain name.
-
-   Negative caching is useful as it reduces the response time for
-   negative answers.  It also reduces the number of messages that have
-   to be sent between resolvers and name servers hence overall network
-   traffic.  A large proportion of DNS traffic on the Internet could be
-   eliminated if all resolvers implemented negative caching.  With this
-   in mind negative caching should no longer be seen as an optional part
-   of a DNS resolver.
-
-
-
-
-
-
-
-
-
-
-
-Andrews                     Standards Track                     [Page 1]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-1 - Terminology
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-   "Negative caching" - the storage of knowledge that something does not
-   exist.  We can store the knowledge that a record has a particular
-   value.  We can also do the reverse, that is, to store the knowledge
-   that a record does not exist.  It is the storage of knowledge that
-   something does not exist, cannot or does not give an answer that we
-   call negative caching.
-
-   "QNAME" - the name in the query section of an answer, or where this
-   resolves to a CNAME, or CNAME chain, the data field of the last
-   CNAME.  The last CNAME in this sense is that which contains a value
-   which does not resolve to another CNAME.  Implementations should note
-   that including CNAME records in responses in order, so that the first
-   has the label from the query section, and then each in sequence has
-   the label from the data section of the previous (where more than one
-   CNAME is needed) allows the sequence to be processed in one pass, and
-   considerably eases the task of the receiver.  Other relevant records
-   (such as SIG RRs [RFC2065]) can be interspersed amongst the CNAMEs.
-
-   "NXDOMAIN" - an alternate expression for the "Name Error" RCODE as
-   described in [RFC1035 Section 4.1.1] and the two terms are used
-   interchangeably in this document.
-
-   "NODATA" - a pseudo RCODE which indicates that the name is valid, for
-   the given class, but are no records of the given type.  A NODATA
-   response has to be inferred from the answer.
-
-   "FORWARDER" - a nameserver used to resolve queries instead of
-   directly using the authoritative nameserver chain.  The forwarder
-   typically either has better access to the internet, or maintains a
-   bigger cache which may be shared amongst many resolvers.  How a
-   server is identified as a FORWARDER, or knows it is a FORWARDER is
-   outside the scope of this document.  However if you are being used as
-   a forwarder the query will have the recursion desired flag set.
-
-   An understanding of [RFC1034], [RFC1035] and [RFC2065] is expected
-   when reading this document.
-
-
-
-
-
-
-
-
-
-Andrews                     Standards Track                     [Page 2]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-2 - Negative Responses
-
-   The most common negative responses indicate that a particular RRset
-   does not exist in the DNS.  The first sections of this document deal
-   with this case.  Other negative responses can indicate failures of a
-   nameserver, those are dealt with in section 7 (Other Negative
-   Responses).
-
-   A negative response is indicated by one of the following conditions:
-
-2.1 - Name Error
-
-   Name errors (NXDOMAIN) are indicated by the presence of "Name Error"
-   in the RCODE field.  In this case the domain referred to by the QNAME
-   does not exist.  Note: the answer section may have SIG and CNAME RRs
-   and the authority section may have SOA, NXT [RFC2065] and SIG RRsets.
-
-   It is possible to distinguish between a referral and a NXDOMAIN
-   response by the presense of NXDOMAIN in the RCODE regardless of the
-   presence of NS or SOA records in the authority section.
-
-   NXDOMAIN responses can be categorised into four types by the contents
-   of the authority section.  These are shown below along with a
-   referral for comparison.  Fields not mentioned are not important in
-   terms of the examples.
-
-           NXDOMAIN RESPONSE: TYPE 1.
-
-           Header:
-               RDCODE=NXDOMAIN
-           Query:
-               AN.EXAMPLE. A
-           Answer:
-               AN.EXAMPLE. CNAME TRIPPLE.XX.
-           Authority:
-               XX. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
-               XX. NS NS1.XX.
-               XX. NS NS2.XX.
-           Additional:
-               NS1.XX. A 127.0.0.2
-               NS2.XX. A 127.0.0.3
-
-           NXDOMAIN RESPONSE: TYPE 2.
-
-           Header:
-               RDCODE=NXDOMAIN
-           Query:
-               AN.EXAMPLE. A
-
-
-
-Andrews                     Standards Track                     [Page 3]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-           Answer:
-               AN.EXAMPLE. CNAME TRIPPLE.XX.
-           Authority:
-               XX. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
-           Additional:
-               <empty>
-
-           NXDOMAIN RESPONSE: TYPE 3.
-
-           Header:
-               RDCODE=NXDOMAIN
-           Query:
-               AN.EXAMPLE. A
-           Answer:
-               AN.EXAMPLE. CNAME TRIPPLE.XX.
-           Authority:
-               <empty>
-           Additional:
-               <empty>
-
-           NXDOMAIN RESPONSE: TYPE 4
-
-           Header:
-               RDCODE=NXDOMAIN
-           Query:
-               AN.EXAMPLE. A
-           Answer:
-               AN.EXAMPLE. CNAME TRIPPLE.XX.
-           Authority:
-               XX. NS NS1.XX.
-               XX. NS NS2.XX.
-           Additional:
-               NS1.XX. A 127.0.0.2
-               NS2.XX. A 127.0.0.3
-
-           REFERRAL RESPONSE.
-
-           Header:
-               RDCODE=NOERROR
-           Query:
-               AN.EXAMPLE. A
-           Answer:
-               AN.EXAMPLE. CNAME TRIPPLE.XX.
-           Authority:
-               XX. NS NS1.XX.
-               XX. NS NS2.XX.
-           Additional:
-               NS1.XX. A 127.0.0.2
-
-
-
-Andrews                     Standards Track                     [Page 4]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-               NS2.XX. A 127.0.0.3
-
-   Note, in the four examples of NXDOMAIN responses, it is known that
-   the name "AN.EXAMPLE." exists, and has as its value a CNAME record.
-   The NXDOMAIN refers to "TRIPPLE.XX", which is then known not to
-   exist.  On the other hand, in the referral example, it is shown that
-   "AN.EXAMPLE" exists, and has a CNAME RR as its value, but nothing is
-   known one way or the other about the existence of "TRIPPLE.XX", other
-   than that "NS1.XX" or "NS2.XX" can be consulted as the next step in
-   obtaining information about it.
-
-   Where no CNAME records appear, the NXDOMAIN response refers to the
-   name in the label of the RR in the question section.
-
-2.1.1 Special Handling of Name Error
-
-   This section deals with errors encountered when implementing negative
-   caching of NXDOMAIN responses.
-
-   There are a large number of resolvers currently in existence that
-   fail to correctly detect and process all forms of NXDOMAIN response.
-   Some resolvers treat a TYPE 1 NXDOMAIN response as a referral.  To
-   alleviate this problem it is recommended that servers that are
-   authoritative for the NXDOMAIN response only send TYPE 2 NXDOMAIN
-   responses, that is the authority section contains a SOA record and no
-   NS records.  If a non- authoritative server sends a type 1 NXDOMAIN
-   response to one of these old resolvers, the result will be an
-   unnecessary query to an authoritative server.  This is undesirable,
-   but not fatal except when the server is being used a FORWARDER.  If
-   however the resolver is using the server as a FORWARDER to such a
-   resolver it will be necessary to disable the sending of TYPE 1
-   NXDOMAIN response to it, use TYPE 2 NXDOMAIN instead.
-
-   Some resolvers incorrectly continue processing if the authoritative
-   answer flag is not set, looping until the query retry threshold is
-   exceeded and then returning SERVFAIL.  This is a problem when your
-   nameserver is listed as a FORWARDER for such resolvers.  If the
-   nameserver is used as a FORWARDER by such resolver, the authority
-   flag will have to be forced on for NXDOMAIN responses to these
-   resolvers.  In practice this causes no problems even if turned on
-   always, and has been the default behaviour in BIND from 4.9.3
-   onwards.
-
-2.2 - No Data
-
-   NODATA is indicated by an answer with the RCODE set to NOERROR and no
-   relevant answers in the answer section.  The authority section will
-   contain an SOA record, or there will be no NS records there.
-
-
-
-Andrews                     Standards Track                     [Page 5]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-   NODATA responses have to be algorithmically determined from the
-   response's contents as there is no RCODE value to indicate NODATA.
-   In some cases to determine with certainty that NODATA is the correct
-   response it can be necessary to send another query.
-
-   The authority section may contain NXT and SIG RRsets in addition to
-   NS and SOA records.  CNAME and SIG records may exist in the answer
-   section.
-
-   It is possible to distinguish between a NODATA and a referral
-   response by the presence of a SOA record in the authority section or
-   the absence of NS records in the authority section.
-
-   NODATA responses can be categorised into three types by the contents
-   of the authority section.  These are shown below along with a
-   referral for comparison.  Fields not mentioned are not important in
-   terms of the examples.
-
-           NODATA RESPONSE: TYPE 1.
-
-           Header:
-               RDCODE=NOERROR
-           Query:
-               ANOTHER.EXAMPLE. A
-           Answer:
-               <empty>
-           Authority:
-               EXAMPLE. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
-               EXAMPLE. NS NS1.XX.
-               EXAMPLE. NS NS2.XX.
-           Additional:
-               NS1.XX. A 127.0.0.2
-               NS2.XX. A 127.0.0.3
-
-           NO DATA RESPONSE: TYPE 2.
-
-           Header:
-               RDCODE=NOERROR
-           Query:
-               ANOTHER.EXAMPLE. A
-           Answer:
-               <empty>
-           Authority:
-               EXAMPLE. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
-           Additional:
-               <empty>
-
-
-
-
-
-Andrews                     Standards Track                     [Page 6]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-           NO DATA RESPONSE: TYPE 3.
-
-           Header:
-               RDCODE=NOERROR
-           Query:
-               ANOTHER.EXAMPLE. A
-           Answer:
-               <empty>
-           Authority:
-               <empty>
-           Additional:
-               <empty>
-
-           REFERRAL RESPONSE.
-
-           Header:
-               RDCODE=NOERROR
-           Query:
-               ANOTHER.EXAMPLE. A
-           Answer:
-               <empty>
-           Authority:
-               EXAMPLE. NS NS1.XX.
-               EXAMPLE. NS NS2.XX.
-           Additional:
-               NS1.XX. A 127.0.0.2
-               NS2.XX. A 127.0.0.3
-
-
-   These examples, unlike the NXDOMAIN examples above, have no CNAME
-   records, however they could, in just the same way that the NXDOMAIN
-   examples did, in which case it would be the value of the last CNAME
-   (the QNAME) for which NODATA would be concluded.
-
-2.2.1 - Special Handling of No Data
-
-   There are a large number of resolvers currently in existence that
-   fail to correctly detect and process all forms of NODATA response.
-   Some resolvers treat a TYPE 1 NODATA response as a referral.  To
-   alleviate this problem it is recommended that servers that are
-   authoritative for the NODATA response only send TYPE 2 NODATA
-   responses, that is the authority section contains a SOA record and no
-   NS records.  Sending a TYPE 1 NODATA response from a non-
-   authoritative server to one of these resolvers will only result in an
-   unnecessary query.  If a server is listed as a FORWARDER for another
-   resolver it may also be necessary to disable the sending of TYPE 1
-   NODATA response for non-authoritative NODATA responses.
-
-
-
-
-Andrews                     Standards Track                     [Page 7]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-   Some name servers fail to set the RCODE to NXDOMAIN in the presence
-   of CNAMEs in the answer section.  If a definitive NXDOMAIN / NODATA
-   answer is required in this case the resolver must query again using
-   the QNAME as the query label.
-
-3 - Negative Answers from Authoritative Servers
-
-   Name servers authoritative for a zone MUST include the SOA record of
-   the zone in the authority section of the response when reporting an
-   NXDOMAIN or indicating that no data of the requested type exists.
-   This is required so that the response may be cached.  The TTL of this
-   record is set from the minimum of the MINIMUM field of the SOA record
-   and the TTL of the SOA itself, and indicates how long a resolver may
-   cache the negative answer.  The TTL SIG record associated with the
-   SOA record should also be trimmed in line with the SOA's TTL.
-
-   If the containing zone is signed [RFC2065] the SOA and appropriate
-   NXT and SIG records MUST be added.
-
-4 - SOA Minimum Field
-
-   The SOA minimum field has been overloaded in the past to have three
-   different meanings, the minimum TTL value of all RRs in a zone, the
-   default TTL of RRs which did not contain a TTL value and the TTL of
-   negative responses.
-
-   Despite being the original defined meaning, the first of these, the
-   minimum TTL value of all RRs in a zone, has never in practice been
-   used and is hereby deprecated.
-
-   The second, the default TTL of RRs which contain no explicit TTL in
-   the master zone file, is relevant only at the primary server.  After
-   a zone transfer all RRs have explicit TTLs and it is impossible to
-   determine whether the TTL for a record was explicitly set or derived
-   from the default after a zone transfer.  Where a server does not
-   require RRs to include the TTL value explicitly, it should provide a
-   mechanism, not being the value of the MINIMUM field of the SOA
-   record, from which the missing TTL values are obtained.  How this is
-   done is implementation dependent.
-
-   The Master File format [RFC 1035 Section 5] is extended to include
-   the following directive:
-
-                           $TTL <TTL> [comment]
-
-
-
-
-
-
-
-Andrews                     Standards Track                     [Page 8]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-   All resource records appearing after the directive, and which do not
-   explicitly include a TTL value, have their TTL set to the TTL given
-   in the $TTL directive.  SIG records without a explicit TTL get their
-   TTL from the "original TTL" of the SIG record [RFC 2065 Section 4.5].
-
-   The remaining of the current meanings, of being the TTL to be used
-   for negative responses, is the new defined meaning of the SOA minimum
-   field.
-
-5 - Caching Negative Answers
-
-   Like normal answers negative answers have a time to live (TTL).  As
-   there is no record in the answer section to which this TTL can be
-   applied, the TTL must be carried by another method.  This is done by
-   including the SOA record from the zone in the authority section of
-   the reply.  When the authoritative server creates this record its TTL
-   is taken from the minimum of the SOA.MINIMUM field and SOA's TTL.
-   This TTL decrements in a similar manner to a normal cached answer and
-   upon reaching zero (0) indicates the cached negative answer MUST NOT
-   be used again.
-
-   A negative answer that resulted from a name error (NXDOMAIN) should
-   be cached such that it can be retrieved and returned in response to
-   another query for the same <QNAME, QCLASS> that resulted in the
-   cached negative response.
-
-   A negative answer that resulted from a no data error (NODATA) should
-   be cached such that it can be retrieved and returned in response to
-   another query for the same <QNAME, QTYPE, QCLASS> that resulted in
-   the cached negative response.
-
-   The NXT record, if it exists in the authority section of a negative
-   answer received, MUST be stored such that it can be be located and
-   returned with SOA record in the authority section, as should any SIG
-   records in the authority section.  For NXDOMAIN answers there is no
-   "necessary" obvious relationship between the NXT records and the
-   QNAME.  The NXT record MUST have the same owner name as the query
-   name for NODATA responses.
-
-   Negative responses without SOA records SHOULD NOT be cached as there
-   is no way to prevent the negative responses looping forever between a
-   pair of servers even with a short TTL.
-
-   Despite the DNS forming a tree of servers, with various mis-
-   configurations it is possible to form a loop in the query graph, e.g.
-   two servers listing each other as forwarders, various lame server
-   configurations.  Without a TTL count down a cache negative response
-
-
-
-
-Andrews                     Standards Track                     [Page 9]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-   when received by the next server would have its TTL reset.  This
-   negative indication could then live forever circulating between the
-   servers involved.
-
-   As with caching positive responses it is sensible for a resolver to
-   limit for how long it will cache a negative response as the protocol
-   supports caching for up to 68 years.  Such a limit should not be
-   greater than that applied to positive answers and preferably be
-   tunable.  Values of one to three hours have been found to work well
-   and would make sensible a default.  Values exceeding one day have
-   been found to be problematic.
-
-6 - Negative answers from the cache
-
-   When a server, in answering a query, encounters a cached negative
-   response it MUST add the cached SOA record to the authority section
-   of the response with the TTL decremented by the amount of time it was
-   stored in the cache.  This allows the NXDOMAIN / NODATA response to
-   time out correctly.
-
-   If a NXT record was cached along with SOA record it MUST be added to
-   the authority section.  If a SIG record was cached along with a NXT
-   record it SHOULD be added to the authority section.
-
-   As with all answers coming from the cache, negative answers SHOULD
-   have an implicit referral built into the answer.  This enables the
-   resolver to locate an authoritative source.  An implicit referral is
-   characterised by NS records in the authority section referring the
-   resolver towards a authoritative source.  NXDOMAIN types 1 and 4
-   responses contain implicit referrals as does NODATA type 1 response.
-
-7 - Other Negative Responses
-
-   Caching of other negative responses is not covered by any existing
-   RFC.  There is no way to indicate a desired TTL in these responses.
-   Care needs to be taken to ensure that there are not forwarding loops.
-
-7.1 Server Failure (OPTIONAL)
-
-   Server failures fall into two major classes.  The first is where a
-   server can determine that it has been misconfigured for a zone.  This
-   may be where it has been listed as a server, but not configured to be
-   a server for the zone, or where it has been configured to be a server
-   for the zone, but cannot obtain the zone data for some reason.  This
-   can occur either because the zone file does not exist or contains
-   errors, or because another server from which the zone should have
-   been available either did not respond or was unable or unwilling to
-   supply the zone.
-
-
-
-Andrews                     Standards Track                    [Page 10]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-   The second class is where the server needs to obtain an answer from
-   elsewhere, but is unable to do so, due to network failures, other
-   servers that don't reply, or return server failure errors, or
-   similar.
-
-   In either case a resolver MAY cache a server failure response.  If it
-   does so it MUST NOT cache it for longer than five (5) minutes, and it
-   MUST be cached against the specific query tuple <query name, type,
-   class, server IP address>.
-
-7.2 Dead / Unreachable Server (OPTIONAL)
-
-   Dead / Unreachable servers are servers that fail to respond in any
-   way to a query or where the transport layer has provided an
-   indication that the server does not exist or is unreachable.  A
-   server may be deemed to be dead or unreachable if it has not
-   responded to an outstanding query within 120 seconds.
-
-   Examples of transport layer indications are:
-
-      ICMP error messages indicating host, net or port unreachable.
-      TCP resets
-      IP stack error messages providing similar indications to those above.
-
-   A server MAY cache a dead server indication.  If it does so it MUST
-   NOT be deemed dead for longer than five (5) minutes.  The indication
-   MUST be stored against query tuple <query name, type, class, server
-   IP address> unless there was a transport layer indication that the
-   server does not exist, in which case it applies to all queries to
-   that specific IP address.
-
-8 - Changes from RFC 1034
-
-   Negative caching in resolvers is no-longer optional, if a resolver
-   caches anything it must also cache negative answers.
-
-   Non-authoritative negative answers MAY be cached.
-
-   The SOA record from the authority section MUST be cached.  Name error
-   indications must be cached against the tuple <query name, QCLASS>.
-   No data indications must be cached against <query name, QTYPE,
-   QCLASS> tuple.
-
-   A cached SOA record must be added to the response.  This was
-   explicitly not allowed because previously the distinction between a
-   normal cached SOA record, and the SOA cached as a result of a
-   negative response was not made, and simply extracting a normal cached
-   SOA and adding that to a cached negative response causes problems.
-
-
-
-Andrews                     Standards Track                    [Page 11]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-   The $TTL TTL directive was added to the master file format.
-
-9 - History of Negative Caching
-
-   This section presents a potted history of negative caching in the DNS
-   and forms no part of the technical specification of negative caching.
-
-   It is interesting to note that the same concepts were re-invented in
-   both the CHIVES and BIND servers.
-
-   The history of the early CHIVES work (Section 9.1) was supplied by
-   Rob Austein <sra@epilogue.com> and is reproduced here in the form in
-   which he supplied it [MPA].
-
-   Sometime around the spring of 1985, I mentioned to Paul Mockapetris
-   that our experience with his JEEVES DNS resolver had pointed out the
-   need for some kind of negative caching scheme.  Paul suggested that
-   we simply cache authoritative errors, using the SOA MINIMUM value for
-   the zone that would have contained the target RRs.  I'm pretty sure
-   that this conversation took place before RFC-973 was written, but it
-   was never clear to me whether this idea was something that Paul came
-   up with on the spot in response to my question or something he'd
-   already been planning to put into the document that became RFC-973.
-   In any case, neither of us was entirely sure that the SOA MINIMUM
-   value was really the right metric to use, but it was available and
-   was under the control of the administrator of the target zone, both
-   of which seemed to us at the time to be important feature.
-
-   Late in 1987, I released the initial beta-test version of CHIVES, the
-   DNS resolver I'd written to replace Paul's JEEVES resolver.  CHIVES
-   included a search path mechanism that was used pretty heavily at
-   several sites (including my own), so CHIVES also included a negative
-   caching mechanism based on SOA MINIMUM values.  The basic strategy
-   was to cache authoritative error codes keyed by the exact query
-   parameters (QNAME, QCLASS, and QTYPE), with a cache TTL equal to the
-   SOA MINIMUM value.  CHIVES did not attempt to track down SOA RRs if
-   they weren't supplied in the authoritative response, so it never
-   managed to completely eliminate the gratuitous DNS error message
-   traffic, but it did help considerably.  Keep in mind that this was
-   happening at about the same time as the near-collapse of the ARPANET
-   due to congestion caused by exponential growth and the the "old"
-   (pre-VJ) TCP retransmission algorithm, so negative caching resulted
-   in drasticly better DNS response time for our users, mailer daemons,
-   etcetera.
-
-
-
-
-
-
-
-Andrews                     Standards Track                    [Page 12]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-   As far as I know, CHIVES was the first resolver to implement negative
-   caching.  CHIVES was developed during the twilight years of TOPS-20,
-   so it never ran on very many machines, but the few machines that it
-   did run on were the ones that were too critical to shut down quickly
-   no matter how much it cost to keep them running.  So what few users
-   we did have tended to drive CHIVES pretty hard.  Several interesting
-   bits of DNS technology resulted from that, but the one that's
-   relevant here is the MAXTTL configuration parameter.
-
-   Experience with JEEVES had already shown that RRs often showed up
-   with ridiculously long TTLs (99999999 was particularly popular for
-   many years, due to bugs in the code and documentation of several
-   early versions of BIND), and that robust software that blindly
-   believed such TTLs could create so many strange failures that it was
-   often necessary to reboot the resolver frequently just to clear this
-   garbage out of the cache.  So CHIVES had a configuration parameter
-   "MAXTTL", which specified the maximum "reasonable" TTL in a received
-   RR.  RRs with TTLs greater than MAXTTL would either have their TTLs
-   reduced to MAXTTL or would be discarded entirely, depending on the
-   setting of another configuration parameter.
-
-   When we started getting field experience with CHIVES's negative
-   caching code, it became clear that the SOA MINIMUM value was often
-   large enough to cause the same kinds of problems for negative caching
-   as the huge TTLs in RRs had for normal caching (again, this was in
-   part due to a bug in several early versions of BIND, where a
-   secondary server would authoritatively deny all knowledge of its
-   zones if it couldn't contact the primaries on reboot).  So we started
-   running the negative cache TTLs through the MAXTTL check too, and
-   continued to experiment.
-
-   The configuration that seemed to work best on WSMR-SIMTEL20.ARMY.MIL
-   (last of the major Internet TOPS-20 machines to be shut down, thus
-   the last major user of CHIVES, thus the place where we had the
-   longest experimental baseline) was to set MAXTTL to about three days.
-   Most of the traffic initiated by SIMTEL20 in its last years was
-   mail-related, and the mail queue timeout was set to one week, so this
-   gave a "stuck" message several tries at complete DNS resolution,
-   without bogging down the system with a lot of useless queries.  Since
-   (for reasons that now escape me) we only had the single MAXTTL
-   parameter rather than separate ones for positive and negative
-   caching, it's not clear how much effect this setting of MAXTTL had on
-   the negative caching code.
-
-   CHIVES also included a second, somewhat controversial mechanism which
-   took the place of negative caching in some cases.  The CHIVES
-   resolver daemon could be configured to load DNS master files, giving
-   it the ability to act as what today would be called a "stealth
-
-
-
-Andrews                     Standards Track                    [Page 13]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-   secondary".  That is, when configured in this way, the resolver had
-   direct access to authoritative information for heavily-used zones.
-   The search path mechanisms in CHIVES reflected this: there were
-   actually two separate search paths, one of which only searched local
-   authoritative zone data, and one which could generate normal
-   iterative queries.  This cut down on the need for negative caching in
-   cases where usage was predictably heavy (e.g., the resolver on
-   XX.LCS.MIT.EDU always loaded the zone files for both LCS.MIT.EDU and
-   AI.MIT.EDU and put both of these suffixes into the "local" search
-   path, since between them the hosts in these two zones accounted for
-   the bulk of the DNS traffic).  Not all sites running CHIVES chose to
-   use this feature; C.CS.CMU.EDU, for example, chose to use the
-   "remote" search path for everything because there were too many
-   different sub-zones at CMU for zone shadowing to be practical for
-   them, so they relied pretty heavily on negative caching even for
-   local traffic.
-
-   Overall, I still think the basic design we used for negative caching
-   was pretty reasonable: the zone administrator specified how long to
-   cache negative answers, and the resolver configuration chose the
-   actual cache time from the range between zero and the period
-   specified by the zone administrator.  There are a lot of details I'd
-   do differently now (like using a new SOA field instead of overloading
-   the MINIMUM field), but after more than a decade, I'd be more worried
-   if we couldn't think of at least a few improvements.
-
-9.2 BIND
-
-   While not the first attempt to get negative caching into BIND, in
-   July 1993, BIND 4.9.2 ALPHA, Anant Kumar of ISI supplied code that
-   implemented, validation and negative caching (NCACHE).  This code had
-   a 10 minute TTL for negative caching and only cached the indication
-   that there was a negative response, NXDOMAIN or NOERROR_NODATA. This
-   is the origin of the NODATA pseudo response code mentioned above.
-
-   Mark Andrews of CSIRO added code (RETURNSOA) that stored the SOA
-   record such that it could be retrieved by a similar query.  UUnet
-   complained that they were getting old answers after loading a new
-   zone, and the option was turned off, BIND 4.9.3-alpha5, April 1994.
-   In reality this indicated that the named needed to purge the space
-   the zone would occupy.  Functionality to do this was added in BIND
-   4.9.3 BETA11 patch2, December 1994.
-
-   RETURNSOA was re-enabled by default, BIND 4.9.5-T1A, August 1996.
-
-
-
-
-
-
-
-Andrews                     Standards Track                    [Page 14]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-10 Example
-
-   The following example is based on a signed zone that is empty apart
-   from the nameservers.  We will query for WWW.XX.EXAMPLE showing
-   initial response and again 10 minutes later.  Note 1: during the
-   intervening 10 minutes the NS records for XX.EXAMPLE have expired.
-   Note 2: the TTL of the SIG records are not explicitly set in the zone
-   file and are hence the TTL of the RRset they are the signature for.
-
-        Zone File:
-
-        $TTL 86400
-        $ORIGIN XX.EXAMPLE.
-        @       IN      SOA     NS1.XX.EXAMPLE. HOSTMATER.XX.EXAMPLE. (
-                                1997102000      ; serial
-                                1800    ; refresh (30 mins)
-                                900     ; retry (15 mins)
-                                604800  ; expire (7 days)
-                                1200 ) ; minimum (20 mins)
-                IN      SIG     SOA ...
-          1200  IN      NXT     NS1.XX.EXAMPLE. A NXT SIG SOA NS KEY
-                IN      SIG     NXT ... XX.EXAMPLE. ...
-           300  IN      NS      NS1.XX.EXAMPLE.
-           300  IN      NS      NS2.XX.EXAMPLE.
-                IN      SIG     NS ... XX.EXAMPLE. ...
-                IN      KEY     0x4100 1 1 ...
-                IN      SIG     KEY ... XX.EXAMPLE. ...
-                IN      SIG     KEY ... EXAMPLE. ...
-        NS1     IN      A       10.0.0.1
-                IN      SIG     A ... XX.EXAMPLE. ...
-          1200  IN      NXT     NS2.XX.EXAMPLE. A NXT SIG
-                IN      SIG     NXT ...
-        NS2     IN      A       10.0.0.2
-                IN      SIG     A ... XX.EXAMPLE. ...
-          1200  IN      NXT     XX.EXAMPLE. A NXT SIG
-                IN      SIG     NXT ... XX.EXAMPLE. ...
-
-        Initial Response:
-
-        Header:
-            RDCODE=NXDOMAIN, AA=1, QR=1, TC=0
-        Query:
-            WWW.XX.EXAMPLE. IN A
-        Answer:
-            <empty>
-        Authority:
-            XX.EXAMPLE.      1200 IN SOA NS1.XX.EXAMPLE. ...
-            XX.EXAMPLE.      1200 IN SIG SOA ... XX.EXAMPLE. ...
-
-
-
-Andrews                     Standards Track                    [Page 15]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-            NS2.XX.EXAMPLE.  1200 IN NXT XX.EXAMPLE. NXT A NXT SIG
-            NS2.XX.EXAMPLE.  1200 IN SIG NXT ... XX.EXAMPLE. ...
-            XX.EXAMPLE.     86400 IN NS  NS1.XX.EXAMPLE.
-            XX.EXAMPLE.     86400 IN NS  NS2.XX.EXAMPLE.
-            XX.EXAMPLE.     86400 IN SIG NS ... XX.EXAMPLE. ...
-        Additional
-            XX.EXAMPLE.     86400 IN KEY 0x4100 1 1 ...
-            XX.EXAMPLE.     86400 IN SIG KEY ... EXAMPLE. ...
-            NS1.XX.EXAMPLE. 86400 IN A   10.0.0.1
-            NS1.XX.EXAMPLE. 86400 IN SIG A ... XX.EXAMPLE. ...
-            NS2.XX.EXAMPLE. 86400 IN A   10.0.0.2
-            NS3.XX.EXAMPLE. 86400 IN SIG A ... XX.EXAMPLE. ...
-
-         After 10 Minutes:
-
-         Header:
-             RDCODE=NXDOMAIN, AA=0, QR=1, TC=0
-         Query:
-             WWW.XX.EXAMPLE. IN A
-         Answer:
-             <empty>
-         Authority:
-             XX.EXAMPLE.       600 IN SOA NS1.XX.EXAMPLE. ...
-             XX.EXAMPLE.       600 IN SIG SOA ... XX.EXAMPLE. ...
-             NS2.XX.EXAMPLE.   600 IN NXT XX.EXAMPLE. NXT A NXT SIG
-             NS2.XX.EXAMPLE.   600 IN SIG NXT ... XX.EXAMPLE. ...
-             EXAMPLE.        65799 IN NS  NS1.YY.EXAMPLE.
-             EXAMPLE.        65799 IN NS  NS2.YY.EXAMPLE.
-             EXAMPLE.        65799 IN SIG NS ... XX.EXAMPLE. ...
-         Additional
-             XX.EXAMPLE.     65800 IN KEY 0x4100 1 1 ...
-             XX.EXAMPLE.     65800 IN SIG KEY ... EXAMPLE. ...
-             NS1.YY.EXAMPLE. 65799 IN A   10.100.0.1
-             NS1.YY.EXAMPLE. 65799 IN SIG A ... EXAMPLE. ...
-             NS2.YY.EXAMPLE. 65799 IN A   10.100.0.2
-             NS3.YY.EXAMPLE. 65799 IN SIG A ... EXAMPLE. ...
-             EXAMPLE.        65799 IN KEY 0x4100 1 1 ...
-             EXAMPLE.        65799 IN SIG KEY ... . ...
-
-
-11 Security Considerations
-
-   It is believed that this document does not introduce any significant
-   additional security threats other that those that already exist when
-   using data from the DNS.
-
-
-
-
-
-
-Andrews                     Standards Track                    [Page 16]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-   With negative caching it might be possible to propagate a denial of
-   service attack by spreading a NXDOMAIN message with a very high TTL.
-   Without negative caching that would be much harder.  A similar effect
-   could be achieved previously by spreading a bad A record, so that the
-   server could not be reached - which is almost the same.  It has the
-   same effect as far as what the end user is able to do, but with a
-   different psychological effect.  With the bad A, I feel "damn the
-   network is broken again" and try again tomorrow.  With the "NXDOMAIN"
-   I feel "Oh, they've turned off the server and it doesn't exist any
-   more" and probably never bother trying this server again.
-
-   A practical example of this is a SMTP server where this behaviour is
-   encoded.  With a NXDOMAIN attack the mail message would bounce
-   immediately, where as with a bad A attack the mail would be queued
-   and could potentially get through after the attack was suspended.
-
-   For such an attack to be successful, the NXDOMAIN indiction must be
-   injected into a parent server (or a busy caching resolver).  One way
-   this might be done by the use of a CNAME which results in the parent
-   server querying an attackers server.  Resolvers that wish to prevent
-   such attacks can query again the final QNAME ignoring any NS data in
-   the query responses it has received for this query.
-
-   Implementing TTL sanity checking will reduce the effectiveness of
-   such an attack, because a successful attack would require re-
-   injection of the bogus data at more frequent intervals.
-
-   DNS Security [RFC2065] provides a mechanism to verify whether a
-   negative response is valid or not, through the use of NXT and SIG
-   records.  This document supports the use of that mechanism by
-   promoting the transmission of the relevant security records even in a
-   non security aware server.
-
-Acknowledgments
-
-   I would like to thank Rob Austein for his history of the CHIVES
-   nameserver. The DNSIND working group, in particular Robert Elz for
-   his valuable technical and editorial contributions to this document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Andrews                     Standards Track                    [Page 17]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-References
-
-   [RFC1034]
-           Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES,"
-           STD 13, RFC 1034, November 1987.
-
-   [RFC1035]
-           Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND
-           SPECIFICATION," STD 13, RFC 1035, November 1987.
-
-   [RFC2065]
-           Eastlake, D., and C. Kaufman, "Domain Name System Security
-           Extensions," RFC 2065, January 1997.
-
-   [RFC2119]
-           Bradner, S., "Key words for use in RFCs to Indicate
-           Requirement Levels," BCP 14, RFC 2119, March 1997.
-
-   [RFC2181]
-           Elz, R., and R. Bush, "Clarifications to the DNS
-           Specification," RFC 2181, July 1997.
-
-Author's Address
-
-   Mark Andrews
-   CSIRO - Mathematical and Information Sciences
-   Locked Bag 17
-   North Ryde NSW 2113
-   AUSTRALIA
-
-   Phone: +61 2 9325 3148
-   EMail: Mark.Andrews@cmis.csiro.au
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Andrews                     Standards Track                    [Page 18]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Andrews                     Standards Track                    [Page 19]
-
diff --git a/contrib/bind9/doc/rfc/rfc2317.txt b/contrib/bind9/doc/rfc/rfc2317.txt
deleted file mode 100644
index c17bb41..0000000
--- a/contrib/bind9/doc/rfc/rfc2317.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         H. Eidnes
-Request for Comments: 2317                                 SINTEF RUNIT
-BCP: 20                                                     G. de Groot
-Category: Best Current Practice          Berkeley Software Design, Inc.
-                                                               P. Vixie
-                                           Internet Software Consortium
-                                                             March 1998
-
-
-                   Classless IN-ADDR.ARPA delegation
-
-Status of this Memo
-
-   This document specifies an Internet Best Current Practices for the
-   Internet Community, and requests discussion and suggestions for
-   improvements.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-2. Introduction
-
-   This document describes a way to do IN-ADDR.ARPA delegation on non-
-   octet boundaries for address spaces covering fewer than 256
-   addresses.  The proposed method should thus remove one of the
-   objections to subnet on non-octet boundaries but perhaps more
-   significantly, make it possible to assign IP address space in smaller
-   chunks than 24-bit prefixes, without losing the ability to delegate
-   authority for the corresponding IN-ADDR.ARPA mappings.  The proposed
-   method is fully compatible with the original DNS lookup mechanisms
-   specified in [1], i.e. there is no need to modify the lookup
-   algorithm used, and there should be no need to modify any software
-   which does DNS lookups.
-
-   The document also discusses some operational considerations to
-   provide some guidance in implementing this method.
-
-3. Motivation
-
-   With the proliferation of classless routing technology, it has become
-   feasible to assign address space on non-octet boundaries.  In case of
-   a very small organization with only a few hosts, assigning a full
-   24-bit prefix (what was traditionally referred to as a "class C
-   network number") often leads to inefficient address space
-   utilization.
-
-
-
-
-
-Eidnes, et. al.          Best Current Practice                  [Page 1]
-
-RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998
-
-
-   One of the problems encountered when assigning a longer prefix (less
-   address space) is that it seems impossible for such an organization
-   to maintain its own reverse ("IN-ADDR.ARPA") zone autonomously.  By
-   use of the reverse delegation method described below, the most
-   important objection to assignment of longer prefixes to unrelated
-   organizations can be removed.
-
-   Let us assume we have assigned the address spaces to three different
-   parties as follows:
-
-           192.0.2.0/25   to organization A
-           192.0.2.128/26 to organization B
-           192.0.2.192/26 to organization C
-
-   In the classical approach, this would lead to a single zone like
-   this:
-
-   $ORIGIN 2.0.192.in-addr.arpa.
-   ;
-   1               PTR     host1.A.domain.
-   2               PTR     host2.A.domain.
-   3               PTR     host3.A.domain.
-   ;
-   129             PTR     host1.B.domain.
-   130             PTR     host2.B.domain.
-   131             PTR     host3.B.domain.
-   ;
-   193             PTR     host1.C.domain.
-   194             PTR     host2.C.domain.
-   195             PTR     host3.C.domain.
-
-   The administration of this zone is problematic.  Authority for this
-   zone can only be delegated once, and this usually translates into
-   "this zone can only be administered by one organization."  The other
-   organizations with address space that corresponds to entries in this
-   zone would thus have to depend on another organization for their
-   address to name translation.  With the proposed method, this
-   potential problem can be avoided.
-
-4. Classless IN-ADDR.ARPA delegation
-
-   Since a single zone can only be delegated once, we need more points
-   to do delegation on to solve the problem above.  These extra points
-   of delegation can be introduced by extending the IN-ADDR.ARPA tree
-   downwards, e.g. by using the first address or the first address and
-   the network mask length (as shown below) in the corresponding address
-
-
-
-
-
-Eidnes, et. al.          Best Current Practice                  [Page 2]
-
-RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998
-
-
-   space to form the the first component in the name for the zones.  The
-   following four zone files show how the problem in the motivation
-   section could be solved using this method.
-
-   $ORIGIN 2.0.192.in-addr.arpa.
-   @       IN      SOA     my-ns.my.domain. hostmaster.my.domain. (...)
-   ;...
-   ;  <<0-127>> /25
-   0/25            NS      ns.A.domain.
-   0/25            NS      some.other.name.server.
-   ;
-   1               CNAME   1.0/25.2.0.192.in-addr.arpa.
-   2               CNAME   2.0/25.2.0.192.in-addr.arpa.
-   3               CNAME   3.0/25.2.0.192.in-addr.arpa.
-   ;
-   ;  <<128-191>> /26
-   128/26          NS      ns.B.domain.
-   128/26          NS      some.other.name.server.too.
-   ;
-   129             CNAME   129.128/26.2.0.192.in-addr.arpa.
-   130             CNAME   130.128/26.2.0.192.in-addr.arpa.
-   131             CNAME   131.128/26.2.0.192.in-addr.arpa.
-   ;
-   ;  <<192-255>> /26
-   192/26          NS      ns.C.domain.
-   192/26          NS      some.other.third.name.server.
-   ;
-   193             CNAME   193.192/26.2.0.192.in-addr.arpa.
-   194             CNAME   194.192/26.2.0.192.in-addr.arpa.
-   195             CNAME   195.192/26.2.0.192.in-addr.arpa.
-
-   $ORIGIN 0/25.2.0.192.in-addr.arpa.
-   @       IN      SOA     ns.A.domain. hostmaster.A.domain. (...)
-   @               NS      ns.A.domain.
-   @               NS      some.other.name.server.
-   ;
-   1               PTR     host1.A.domain.
-   2               PTR     host2.A.domain.
-   3               PTR     host3.A.domain.
-
-
-
-
-
-
-
-
-
-
-
-
-Eidnes, et. al.          Best Current Practice                  [Page 3]
-
-RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998
-
-
-   $ORIGIN 128/26.2.0.192.in-addr.arpa.
-   @       IN      SOA     ns.B.domain. hostmaster.B.domain. (...)
-   @               NS      ns.B.domain.
-   @               NS      some.other.name.server.too.
-   ;
-   129             PTR     host1.B.domain.
-   130             PTR     host2.B.domain.
-   131             PTR     host3.B.domain.
-
-
-   $ORIGIN 192/26.2.0.192.in-addr.arpa.
-   @       IN      SOA     ns.C.domain. hostmaster.C.domain. (...)
-   @               NS      ns.C.domain.
-   @               NS      some.other.third.name.server.
-   ;
-   193             PTR     host1.C.domain.
-   194             PTR     host2.C.domain.
-   195             PTR     host3.C.domain.
-
-   For each size-256 chunk split up using this method, there is a need
-   to install close to 256 CNAME records in the parent zone.  Some
-   people might view this as ugly; we will not argue that particular
-   point.  It is however quite easy to automatically generate the CNAME
-   resource records in the parent zone once and for all, if the way the
-   address space is partitioned is known.
-
-   The advantage of this approach over the other proposed approaches for
-   dealing with this problem is that there should be no need to modify
-   any already-deployed software.  In particular, the lookup mechanism
-   in the DNS does not have to be modified to accommodate this splitting
-   of the responsibility for the IPv4 address to name translation on
-   "non-dot" boundaries.  Furthermore, this technique has been in use
-   for several years in many installations, apparently with no ill
-   effects.
-
-   As usual, a resource record like
-
-   $ORIGIN 2.0.192.in-addr.arpa.
-   129             CNAME   129.128/26.2.0.192.in-addr.arpa.
-
-   can be convienently abbreviated to
-
-   $ORIGIN 2.0.192.in-addr.arpa.
-   129             CNAME   129.128/26
-
-
-
-
-
-
-
-Eidnes, et. al.          Best Current Practice                  [Page 4]
-
-RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998
-
-
-   Some DNS implementations are not kind to special characters in domain
-   names, e.g. the "/" used in the above examples.  As [3] makes clear,
-   these are legal, though some might feel unsightly.  Because these are
-   not host names the restriction of [2] does not apply.  Modern clients
-   and servers have an option to act in the liberal and correct fashion.
-
-   The examples here use "/" because it was felt to be more visible and
-   pedantic reviewers felt that the 'these are not hostnames' argument
-   needed to be repeated.  We advise you not to be so pedantic, and to
-   not precisely copy the above examples, e.g.  substitute a more
-   conservative character, such as hyphen, for "/".
-
-5. Operational considerations
-
-   This technique is intended to be used for delegating address spaces
-   covering fewer than 256 addresses.  For delegations covering larger
-   blocks of addresses the traditional methods (multiple delegations)
-   can be used instead.
-
-5.1 Recommended secondary name service
-
-   Some older versions of name server software will make no effort to
-   find and return the pointed-to name in CNAME records if the pointed-
-   to name is not already known locally as cached or as authoritative
-   data.  This can cause some confusion in resolvers, as only the CNAME
-   record will be returned in the response.  To avoid this problem it is
-   recommended that the authoritative name servers for the delegating
-   zone (the zone containing all the CNAME records) all run as slave
-   (secondary) name servers for the "child" zones delegated and pointed
-   into via the CNAME records.
-
-5.2 Alternative naming conventions
-
-   As a result of this method, the location of the zone containing the
-   actual PTR records is no longer predefined.  This gives flexibility
-   and some examples will be presented here.
-
-   An alternative to using the first address, or the first address and
-   the network mask length in the corresponding address space, to name
-   the new zones is to use some other (non-numeric) name.  Thus it is
-   also possible to point to an entirely different part of the DNS tree
-   (i.e. outside of the IN-ADDR.ARPA tree).  It would be necessary to
-   use one of these alternate methods if two organizations somehow
-   shared the same physical subnet (and corresponding IP address space)
-   with no "neat" alignment of the addresses, but still wanted to
-   administrate their own IN-ADDR.ARPA mappings.
-
-
-
-
-
-Eidnes, et. al.          Best Current Practice                  [Page 5]
-
-RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998
-
-
-   The following short example shows how you can point out of the IN-
-   ADDR.ARPA tree:
-
-   $ORIGIN 2.0.192.in-addr.arpa.
-   @       IN      SOA     my-ns.my.domain. hostmaster.my.domain. (...)
-   ; ...
-   1               CNAME   1.A.domain.
-   2               CNAME   2.A.domain.
-   ; ...
-   129             CNAME   129.B.domain.
-   130             CNAME   130.B.domain.
-   ;
-
-
-   $ORIGIN A.domain.
-   @       IN      SOA     my-ns.A.domain. hostmaster.A.domain. (...)
-   ; ...
-   ;
-   host1           A       192.0.2.1
-   1               PTR     host1
-   ;
-   host2           A       192.0.2.2
-   2               PTR     host2
-   ;
-
-   etc.
-
-   This way you can actually end up with the name->address and the
-   (pointed-to) address->name mapping data in the same zone file - some
-   may view this as an added bonus as no separate set of secondaries for
-   the reverse zone is required.  Do however note that the traversal via
-   the IN-ADDR.ARPA tree will still be done, so the CNAME records
-   inserted there need to point in the right direction for this to work.
-
-   Sketched below is an alternative approach using the same solution:
-
-   $ORIGIN 2.0.192.in-addr.arpa.
-   @                  SOA     my-ns.my.domain. hostmaster.my.domain. (...)
-   ; ...
-   1                  CNAME   1.2.0.192.in-addr.A.domain.
-   2                  CNAME   2.2.0.192.in-addr.A.domain.
-
-   $ORIGIN A.domain.
-   @                  SOA     my-ns.A.domain. hostmaster.A.domain. (...)
-   ; ...
-   ;
-   host1              A       192.0.2.1
-   1.2.0.192.in-addr  PTR     host1
-
-
-
-Eidnes, et. al.          Best Current Practice                  [Page 6]
-
-RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998
-
-
-   host2              A       192.0.2.2
-   2.2.0.192.in-addr  PTR     host2
-
-   It is clear that many possibilities exist which can be adapted to the
-   specific requirements of the situation at hand.
-
-5.3 Other operational issues
-
-   Note that one cannot provide CNAME referrals twice for the same
-   address space, i.e. you cannot allocate a /25 prefix to one
-   organisation, and run IN-ADDR.ARPA this way, and then have the
-   organisation subnet the /25 into longer prefixes, and attempt to
-   employ the same technique to give each subnet control of its own
-   number space. This would result in a CNAME record pointing to a CNAME
-   record, which may be less robust overall.
-
-   Unfortunately, some old beta releases of the popular DNS name server
-   implementation BIND 4.9.3 had a bug which caused problems if a CNAME
-   record was encountered when a reverse lookup was made.  The beta
-   releases involved have since been obsoleted, and this issue is
-   resolved in the released code.  Some software manufacturers have
-   included the defective beta code in their product. In the few cases
-   we know of, patches from the manufacturers are available or planned
-   to replace the obsolete beta code involved.
-
-6. Security Considerations
-
-   With this scheme, the "leaf sites" will need to rely on one more site
-   running their DNS name service correctly than they would be if they
-   had a /24 allocation of their own, and this may add an extra
-   component which will need to work for reliable name resolution.
-
-   Other than that, the authors are not aware of any additional security
-   issues introduced by this mechanism.
-
-7. Conclusion
-
-   The suggested scheme gives more flexibility in delegating authority
-   in the IN-ADDR.ARPA domain, thus making it possible to assign address
-   space more efficiently without losing the ability to delegate the DNS
-   authority over the corresponding address to name mappings.
-
-8. Acknowledgments
-
-   Glen A. Herrmannsfeldt described this trick on comp.protocols.tcp-
-   ip.domains some time ago.  Alan Barrett and Sam Wilson provided
-   valuable comments on the newsgroup.
-
-
-
-
-Eidnes, et. al.          Best Current Practice                  [Page 7]
-
-RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998
-
-
-   We would like to thank Rob Austein, Randy Bush, Matt Crawford, Robert
-   Elz, Glen A. Herrmannsfeldt, Daniel Karrenberg, David Kessens, Tony
-   Li, Paul Mockapetris, Eric Wassenaar, Michael Patton, Hans Maurer,
-   and Peter Koch for their review and constructive comments.
-
-9. References
-
-   [1]  Mockapetris, P., "Domain Names - Concepts and Facilities",
-        STD 13, RFC 1034, November 1987.
-
-   [2]  Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet Host
-        Table Specification", RFC 952, October 1985.
-
-   [3]  Elz, R., and R. Bush, "Clarifications to the DNS
-        Specification", RFC 2181, July 1997.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eidnes, et. al.          Best Current Practice                  [Page 8]
-
-RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998
-
-
-10. Authors' Addresses
-
-   Havard Eidnes
-   SINTEF RUNIT
-   N-7034 Trondheim
-   Norway
-
-   Phone: +47 73 59 44 68
-   Fax: +47 73 59 17 00
-   EMail: Havard.Eidnes@runit.sintef.no
-
-
-   Geert Jan de Groot
-   Berkeley Software Design, Inc. (BSDI)
-   Hendrik Staetslaan 69
-   5622 HM Eindhoven
-   The Netherlands
-
-   Phone: +31 40 2960509
-   Fax:   +31 40 2960309
-   EMail: GeertJan.deGroot@bsdi.com
-
-
-   Paul Vixie
-   Internet Software Consortium
-   Star Route Box 159A
-   Woodside, CA 94062
-   USA
-
-   Phone: +1 415 747 0204
-   EMail: paul@vix.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eidnes, et. al.          Best Current Practice                  [Page 9]
-
-RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998
-
-
-11.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eidnes, et. al.          Best Current Practice                 [Page 10]
-
diff --git a/contrib/bind9/doc/rfc/rfc2373.txt b/contrib/bind9/doc/rfc/rfc2373.txt
deleted file mode 100644
index 59fcff8..0000000
--- a/contrib/bind9/doc/rfc/rfc2373.txt
+++ /dev/null
@@ -1,1459 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        R. Hinden
-Request for Comments: 2373                                       Nokia
-Obsoletes: 1884                                             S. Deering
-Category: Standards Track                                Cisco Systems
-							     July 1998
-
-                  IP Version 6 Addressing Architecture
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-Abstract
-
-   This specification defines the addressing architecture of the IP
-   Version 6 protocol [IPV6].  The document includes the IPv6 addressing
-   model, text representations of IPv6 addresses, definition of IPv6
-   unicast addresses, anycast addresses, and multicast addresses, and an
-   IPv6 node's required addresses.
-
-Table of Contents
-
-   1. Introduction.................................................2
-   2. IPv6 Addressing..............................................2
-      2.1 Addressing Model.........................................3
-      2.2 Text Representation of Addresses.........................3
-      2.3 Text Representation of Address Prefixes..................5
-      2.4 Address Type Representation..............................6
-      2.5 Unicast Addresses........................................7
-        2.5.1 Interface Identifiers................................8
-        2.5.2 The Unspecified Address..............................9
-        2.5.3 The Loopback Address.................................9
-        2.5.4 IPv6 Addresses with Embedded IPv4 Addresses.........10
-        2.5.5 NSAP Addresses......................................10
-        2.5.6 IPX Addresses.......................................10
-        2.5.7 Aggregatable Global Unicast Addresses...............11
-        2.5.8 Local-use IPv6 Unicast Addresses....................11
-      2.6 Anycast Addresses.......................................12
-        2.6.1 Required Anycast Address............................13
-      2.7 Multicast Addresses.....................................14
-
-
-
-Hinden & Deering            Standards Track                     [Page 1]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-        2.7.1 Pre-Defined Multicast Addresses.....................15
-        2.7.2 Assignment of New IPv6 Multicast Addresses..........17
-      2.8 A Node's Required Addresses.............................17
-   3. Security Considerations.....................................18
-   APPENDIX A: Creating EUI-64 based Interface Identifiers........19
-   APPENDIX B: ABNF Description of Text Representations...........22
-   APPENDIX C: CHANGES FROM RFC-1884..............................23
-   REFERENCES.....................................................24
-   AUTHORS' ADDRESSES.............................................25
-   FULL COPYRIGHT STATEMENT.......................................26
-
-
-1.0 INTRODUCTION
-
-   This specification defines the addressing architecture of the IP
-   Version 6 protocol.  It includes a detailed description of the
-   currently defined address formats for IPv6 [IPV6].
-
-   The authors would like to acknowledge the contributions of Paul
-   Francis, Scott Bradner, Jim Bound, Brian Carpenter, Matt Crawford,
-   Deborah Estrin, Roger Fajman, Bob Fink, Peter Ford, Bob Gilligan,
-   Dimitry Haskin, Tom Harsch, Christian Huitema, Tony Li, Greg
-   Minshall, Thomas Narten, Erik Nordmark, Yakov Rekhter, Bill Simpson,
-   and Sue Thomson.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC 2119].
-
-2.0 IPv6 ADDRESSING
-
-   IPv6 addresses are 128-bit identifiers for interfaces and sets of
-   interfaces.  There are three types of addresses:
-
-     Unicast:   An identifier for a single interface.  A packet sent to
-                a unicast address is delivered to the interface
-                identified by that address.
-
-     Anycast:   An identifier for a set of interfaces (typically
-                belonging to different nodes).  A packet sent to an
-                anycast address is delivered to one of the interfaces
-                identified by that address (the "nearest" one, according
-                to the routing protocols' measure of distance).
-
-     Multicast: An identifier for a set of interfaces (typically
-                belonging to different nodes).  A packet sent to a
-                multicast address is delivered to all interfaces
-                identified by that address.
-
-
-
-Hinden & Deering            Standards Track                     [Page 2]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-   There are no broadcast addresses in IPv6, their function being
-   superseded by multicast addresses.
-
-   In this document, fields in addresses are given a specific name, for
-   example "subscriber".  When this name is used with the term "ID" for
-   identifier after the name (e.g., "subscriber ID"), it refers to the
-   contents of the named field.  When it is used with the term "prefix"
-   (e.g.  "subscriber prefix") it refers to all of the address up to and
-   including this field.
-
-   In IPv6, all zeros and all ones are legal values for any field,
-   unless specifically excluded.  Specifically, prefixes may contain
-   zero-valued fields or end in zeros.
-
-2.1 Addressing Model
-
-   IPv6 addresses of all types are assigned to interfaces, not nodes.
-   An IPv6 unicast address refers to a single interface.  Since each
-   interface belongs to a single node, any of that node's interfaces'
-   unicast addresses may be used as an identifier for the node.
-
-   All interfaces are required to have at least one link-local unicast
-   address (see section 2.8 for additional required addresses).  A
-   single interface may also be assigned multiple IPv6 addresses of any
-   type (unicast, anycast, and multicast) or scope.  Unicast addresses
-   with scope greater than link-scope are not needed for interfaces that
-   are not used as the origin or destination of any IPv6 packets to or
-   from non-neighbors.  This is sometimes convenient for point-to-point
-   interfaces.  There is one exception to this addressing model:
-
-     An unicast address or a set of unicast addresses may be assigned to
-     multiple physical interfaces if the implementation treats the
-     multiple physical interfaces as one interface when presenting it to
-     the internet layer.  This is useful for load-sharing over multiple
-     physical interfaces.
-
-   Currently IPv6 continues the IPv4 model that a subnet prefix is
-   associated with one link.  Multiple subnet prefixes may be assigned
-   to the same link.
-
-2.2 Text Representation of Addresses
-
-   There are three conventional forms for representing IPv6 addresses as
-   text strings:
-
-   1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the
-      hexadecimal values of the eight 16-bit pieces of the address.
-      Examples:
-
-
-
-Hinden & Deering            Standards Track                     [Page 3]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-         FEDC:BA98:7654:3210:FEDC:BA98:7654:3210
-
-         1080:0:0:0:8:800:200C:417A
-
-      Note that it is not necessary to write the leading zeros in an
-      individual field, but there must be at least one numeral in every
-      field (except for the case described in 2.).
-
-   2. Due to some methods of allocating certain styles of IPv6
-      addresses, it will be common for addresses to contain long strings
-      of zero bits.  In order to make writing addresses containing zero
-      bits easier a special syntax is available to compress the zeros.
-      The use of "::" indicates multiple groups of 16-bits of zeros.
-      The "::" can only appear once in an address.  The "::" can also be
-      used to compress the leading and/or trailing zeros in an address.
-
-      For example the following addresses:
-
-         1080:0:0:0:8:800:200C:417A  a unicast address
-         FF01:0:0:0:0:0:0:101        a multicast address
-         0:0:0:0:0:0:0:1             the loopback address
-         0:0:0:0:0:0:0:0             the unspecified addresses
-
-      may be represented as:
-
-         1080::8:800:200C:417A       a unicast address
-         FF01::101                   a multicast address
-         ::1                         the loopback address
-         ::                          the unspecified addresses
-
-   3. An alternative form that is sometimes more convenient when dealing
-      with a mixed environment of IPv4 and IPv6 nodes is
-      x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of
-      the six high-order 16-bit pieces of the address, and the 'd's are
-      the decimal values of the four low-order 8-bit pieces of the
-      address (standard IPv4 representation).  Examples:
-
-         0:0:0:0:0:0:13.1.68.3
-
-         0:0:0:0:0:FFFF:129.144.52.38
-
-      or in compressed form:
-
-         ::13.1.68.3
-
-         ::FFFF:129.144.52.38
-
-
-
-
-
-Hinden & Deering            Standards Track                     [Page 4]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-2.3 Text Representation of Address Prefixes
-
-   The text representation of IPv6 address prefixes is similar to the
-   way IPv4 addresses prefixes are written in CIDR notation.  An IPv6
-   address prefix is represented by the notation:
-
-      ipv6-address/prefix-length
-
-   where
-
-      ipv6-address    is an IPv6 address in any of the notations listed
-                      in section 2.2.
-
-      prefix-length   is a decimal value specifying how many of the
-                      leftmost contiguous bits of the address comprise
-                      the prefix.
-
-   For example, the following are legal representations of the 60-bit
-   prefix 12AB00000000CD3 (hexadecimal):
-
-      12AB:0000:0000:CD30:0000:0000:0000:0000/60
-      12AB::CD30:0:0:0:0/60
-      12AB:0:0:CD30::/60
-
-   The following are NOT legal representations of the above prefix:
-
-      12AB:0:0:CD3/60   may drop leading zeros, but not trailing zeros,
-                        within any 16-bit chunk of the address
-
-      12AB::CD30/60     address to left of "/" expands to
-                        12AB:0000:0000:0000:0000:000:0000:CD30
-
-      12AB::CD3/60      address to left of "/" expands to
-                        12AB:0000:0000:0000:0000:000:0000:0CD3
-
-   When writing both a node address and a prefix of that node address
-   (e.g., the node's subnet prefix), the two can combined as follows:
-
-      the node address      12AB:0:0:CD30:123:4567:89AB:CDEF
-      and its subnet number 12AB:0:0:CD30::/60
-
-      can be abbreviated as 12AB:0:0:CD30:123:4567:89AB:CDEF/60
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                     [Page 5]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-2.4 Address Type Representation
-
-   The specific type of an IPv6 address is indicated by the leading bits
-   in the address.  The variable-length field comprising these leading
-   bits is called the Format Prefix (FP).  The initial allocation of
-   these prefixes is as follows:
-
-    Allocation                            Prefix         Fraction of
-                                          (binary)       Address Space
-    -----------------------------------   --------       -------------
-    Reserved                              0000 0000      1/256
-    Unassigned                            0000 0001      1/256
-
-    Reserved for NSAP Allocation          0000 001       1/128
-    Reserved for IPX Allocation           0000 010       1/128
-
-    Unassigned                            0000 011       1/128
-    Unassigned                            0000 1         1/32
-    Unassigned                            0001           1/16
-
-    Aggregatable Global Unicast Addresses 001            1/8
-    Unassigned                            010            1/8
-    Unassigned                            011            1/8
-    Unassigned                            100            1/8
-    Unassigned                            101            1/8
-    Unassigned                            110            1/8
-
-    Unassigned                            1110           1/16
-    Unassigned                            1111 0         1/32
-    Unassigned                            1111 10        1/64
-    Unassigned                            1111 110       1/128
-    Unassigned                            1111 1110 0    1/512
-
-    Link-Local Unicast Addresses          1111 1110 10   1/1024
-    Site-Local Unicast Addresses          1111 1110 11   1/1024
-
-    Multicast Addresses                   1111 1111      1/256
-
-    Notes:
-
-      (1) The "unspecified address" (see section 2.5.2), the loopback
-          address (see section 2.5.3), and the IPv6 Addresses with
-          Embedded IPv4 Addresses (see section 2.5.4), are assigned out
-          of the 0000 0000 format prefix space.
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                     [Page 6]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-      (2) The format prefixes 001 through 111, except for Multicast
-          Addresses (1111 1111), are all required to have to have 64-bit
-          interface identifiers in EUI-64 format.  See section 2.5.1 for
-          definitions.
-
-   This allocation supports the direct allocation of aggregation
-   addresses, local use addresses, and multicast addresses.  Space is
-   reserved for NSAP addresses and IPX addresses.  The remainder of the
-   address space is unassigned for future use.  This can be used for
-   expansion of existing use (e.g., additional aggregatable addresses,
-   etc.) or new uses (e.g., separate locators and identifiers).  Fifteen
-   percent of the address space is initially allocated.  The remaining
-   85% is reserved for future use.
-
-   Unicast addresses are distinguished from multicast addresses by the
-   value of the high-order octet of the addresses: a value of FF
-   (11111111) identifies an address as a multicast address; any other
-   value identifies an address as a unicast address.  Anycast addresses
-   are taken from the unicast address space, and are not syntactically
-   distinguishable from unicast addresses.
-
-2.5 Unicast Addresses
-
-   IPv6 unicast addresses are aggregatable with contiguous bit-wise
-   masks similar to IPv4 addresses under Class-less Interdomain Routing
-   [CIDR].
-
-   There are several forms of unicast address assignment in IPv6,
-   including the global aggregatable global unicast address, the NSAP
-   address, the IPX hierarchical address, the site-local address, the
-   link-local address, and the IPv4-capable host address.  Additional
-   address types can be defined in the future.
-
-   IPv6 nodes may have considerable or little knowledge of the internal
-   structure of the IPv6 address, depending on the role the node plays
-   (for instance, host versus router).  At a minimum, a node may
-   consider that unicast addresses (including its own) have no internal
-   structure:
-
-   |                           128 bits                              |
-   +-----------------------------------------------------------------+
-   |                          node address                           |
-   +-----------------------------------------------------------------+
-
-   A slightly sophisticated host (but still rather simple) may
-   additionally be aware of subnet prefix(es) for the link(s) it is
-   attached to, where different addresses may have different values for
-   n:
-
-
-
-Hinden & Deering            Standards Track                     [Page 7]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-   |                         n bits                 |   128-n bits   |
-   +------------------------------------------------+----------------+
-   |                   subnet prefix                | interface ID   |
-   +------------------------------------------------+----------------+
-
-   Still more sophisticated hosts may be aware of other hierarchical
-   boundaries in the unicast address.  Though a very simple router may
-   have no knowledge of the internal structure of IPv6 unicast
-   addresses, routers will more generally have knowledge of one or more
-   of the hierarchical boundaries for the operation of routing
-   protocols.  The known boundaries will differ from router to router,
-   depending on what positions the router holds in the routing
-   hierarchy.
-
-2.5.1 Interface Identifiers
-
-   Interface identifiers in IPv6 unicast addresses are used to identify
-   interfaces on a link.  They are required to be unique on that link.
-   They may also be unique over a broader scope.  In many cases an
-   interface's identifier will be the same as that interface's link-
-   layer address.  The same interface identifier may be used on multiple
-   interfaces on a single node.
-
-   Note that the use of the same interface identifier on multiple
-   interfaces of a single node does not affect the interface
-   identifier's global uniqueness or each IPv6 addresses global
-   uniqueness created using that interface identifier.
-
-   In a number of the format prefixes (see section 2.4) Interface IDs
-   are required to be 64 bits long and to be constructed in IEEE EUI-64
-   format [EUI64].  EUI-64 based Interface identifiers may have global
-   scope when a global token is available (e.g., IEEE 48bit MAC) or may
-   have local scope where a global token is not available (e.g., serial
-   links, tunnel end-points, etc.).  It is required that the "u" bit
-   (universal/local bit in IEEE EUI-64 terminology) be inverted when
-   forming the interface identifier from the EUI-64.  The "u" bit is set
-   to one (1) to indicate global scope, and it is set to zero (0) to
-   indicate local scope.  The first three octets in binary of an EUI-64
-   identifier are as follows:
-
-       0       0 0       1 1       2
-      |0       7 8       5 6       3|
-      +----+----+----+----+----+----+
-      |cccc|ccug|cccc|cccc|cccc|cccc|
-      +----+----+----+----+----+----+
-
-
-
-
-
-
-Hinden & Deering            Standards Track                     [Page 8]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-   written in Internet standard bit-order , where "u" is the
-   universal/local bit, "g" is the individual/group bit, and "c" are the
-   bits of the company_id.  Appendix A: "Creating EUI-64 based Interface
-   Identifiers" provides examples on the creation of different EUI-64
-   based interface identifiers.
-
-   The motivation for inverting the "u" bit when forming the interface
-   identifier is to make it easy for system administrators to hand
-   configure local scope identifiers when hardware tokens are not
-   available.  This is expected to be case for serial links, tunnel end-
-   points, etc.  The alternative would have been for these to be of the
-   form 0200:0:0:1, 0200:0:0:2, etc., instead of the much simpler ::1,
-   ::2, etc.
-
-   The use of the universal/local bit in the IEEE EUI-64 identifier is
-   to allow development of future technology that can take advantage of
-   interface identifiers with global scope.
-
-   The details of forming interface identifiers are defined in the
-   appropriate "IPv6 over <link>" specification such as "IPv6 over
-   Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc.
-
-2.5.2 The Unspecified Address
-
-   The address 0:0:0:0:0:0:0:0 is called the unspecified address.  It
-   must never be assigned to any node.  It indicates the absence of an
-   address.  One example of its use is in the Source Address field of
-   any IPv6 packets sent by an initializing host before it has learned
-   its own address.
-
-   The unspecified address must not be used as the destination address
-   of IPv6 packets or in IPv6 Routing Headers.
-
-2.5.3 The Loopback Address
-
-   The unicast address 0:0:0:0:0:0:0:1 is called the loopback address.
-   It may be used by a node to send an IPv6 packet to itself.  It may
-   never be assigned to any physical interface.  It may be thought of as
-   being associated with a virtual interface (e.g., the loopback
-   interface).
-
-   The loopback address must not be used as the source address in IPv6
-   packets that are sent outside of a single node.  An IPv6 packet with
-   a destination address of loopback must never be sent outside of a
-   single node and must never be forwarded by an IPv6 router.
-
-
-
-
-
-
-Hinden & Deering            Standards Track                     [Page 9]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-2.5.4 IPv6 Addresses with Embedded IPv4 Addresses
-
-   The IPv6 transition mechanisms [TRAN] include a technique for hosts
-   and routers to dynamically tunnel IPv6 packets over IPv4 routing
-   infrastructure.  IPv6 nodes that utilize this technique are assigned
-   special IPv6 unicast addresses that carry an IPv4 address in the low-
-   order 32-bits.  This type of address is termed an "IPv4-compatible
-   IPv6 address" and has the format:
-
-   |                80 bits               | 16 |      32 bits        |
-   +--------------------------------------+--------------------------+
-   |0000..............................0000|0000|    IPv4 address     |
-   +--------------------------------------+----+---------------------+
-
-   A second type of IPv6 address which holds an embedded IPv4 address is
-   also defined.  This address is used to represent the addresses of
-   IPv4-only nodes (those that *do not* support IPv6) as IPv6 addresses.
-   This type of address is termed an "IPv4-mapped IPv6 address" and has
-   the format:
-
-   |                80 bits               | 16 |      32 bits        |
-   +--------------------------------------+--------------------------+
-   |0000..............................0000|FFFF|    IPv4 address     |
-   +--------------------------------------+----+---------------------+
-
-2.5.5 NSAP Addresses
-
-   This mapping of NSAP address into IPv6 addresses is defined in
-   [NSAP].  This document recommends that network implementors who have
-   planned or deployed an OSI NSAP addressing plan, and who wish to
-   deploy or transition to IPv6, should redesign a native IPv6
-   addressing plan to meet their needs.  However, it also defines a set
-   of mechanisms for the support of OSI NSAP addressing in an IPv6
-   network.  These mechanisms are the ones that must be used if such
-   support is required.  This document also defines a mapping of IPv6
-   addresses within the OSI address format, should this be required.
-
-2.5.6 IPX Addresses
-
-   This mapping of IPX address into IPv6 addresses is as follows:
-
-   |   7   |                   121 bits                              |
-   +-------+---------------------------------------------------------+
-   |0000010|                 to be defined                           |
-   +-------+---------------------------------------------------------+
-
-   The draft definition, motivation, and usage are under study.
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 10]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-2.5.7 Aggregatable Global Unicast Addresses
-
-   The global aggregatable global unicast address is defined in [AGGR].
-   This address format is designed to support both the current provider
-   based aggregation and a new type of aggregation called exchanges.
-   The combination will allow efficient routing aggregation for both
-   sites which connect directly to providers and who connect to
-   exchanges.  Sites will have the choice to connect to either type of
-   aggregation point.
-
-   The IPv6 aggregatable global unicast address format is as follows:
-
-   | 3|  13 | 8 |   24   |   16   |          64 bits               |
-   +--+-----+---+--------+--------+--------------------------------+
-   |FP| TLA |RES|  NLA   |  SLA   |         Interface ID           |
-   |  | ID  |   |  ID    |  ID    |                                |
-   +--+-----+---+--------+--------+--------------------------------+
-
-   Where
-
-      001          Format Prefix (3 bit) for Aggregatable Global
-                   Unicast Addresses
-      TLA ID       Top-Level Aggregation Identifier
-      RES          Reserved for future use
-      NLA ID       Next-Level Aggregation Identifier
-      SLA ID       Site-Level Aggregation Identifier
-      INTERFACE ID Interface Identifier
-
-   The contents, field sizes, and assignment rules are defined in
-   [AGGR].
-
-2.5.8 Local-Use IPv6 Unicast Addresses
-
-   There are two types of local-use unicast addresses defined.  These
-   are Link-Local and Site-Local.  The Link-Local is for use on a single
-   link and the Site-Local is for use in a single site.  Link-Local
-   addresses have the following format:
-
-   |   10     |
-   |  bits    |        54 bits          |          64 bits           |
-   +----------+-------------------------+----------------------------+
-   |1111111010|           0             |       interface ID         |
-   +----------+-------------------------+----------------------------+
-
-   Link-Local addresses are designed to be used for addressing on a
-   single link for purposes such as auto-address configuration, neighbor
-   discovery, or when no routers are present.
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 11]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-   Routers must not forward any packets with link-local source or
-   destination addresses to other links.
-
-   Site-Local addresses have the following format:
-
-   |   10     |
-   |  bits    |   38 bits   |  16 bits  |         64 bits            |
-   +----------+-------------+-----------+----------------------------+
-   |1111111011|    0        | subnet ID |       interface ID         |
-   +----------+-------------+-----------+----------------------------+
-
-   Site-Local addresses are designed to be used for addressing inside of
-   a site without the need for a global prefix.
-
-   Routers must not forward any packets with site-local source or
-   destination addresses outside of the site.
-
-2.6 Anycast Addresses
-
-   An IPv6 anycast address is an address that is assigned to more than
-   one interface (typically belonging to different nodes), with the
-   property that a packet sent to an anycast address is routed to the
-   "nearest" interface having that address, according to the routing
-   protocols' measure of distance.
-
-   Anycast addresses are allocated from the unicast address space, using
-   any of the defined unicast address formats.  Thus, anycast addresses
-   are syntactically indistinguishable from unicast addresses.  When a
-   unicast address is assigned to more than one interface, thus turning
-   it into an anycast address, the nodes to which the address is
-   assigned must be explicitly configured to know that it is an anycast
-   address.
-
-   For any assigned anycast address, there is a longest address prefix P
-   that identifies the topological region in which all interfaces
-   belonging to that anycast address reside.  Within the region
-   identified by P, each member of the anycast set must be advertised as
-   a separate entry in the routing system (commonly referred to as a
-   "host route"); outside the region identified by P, the anycast
-   address may be aggregated into the routing advertisement for prefix
-   P.
-
-   Note that in, the worst case, the prefix P of an anycast set may be
-   the null prefix, i.e., the members of the set may have no topological
-   locality.  In that case, the anycast address must be advertised as a
-   separate routing entry throughout the entire internet, which presents
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 12]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-   a severe scaling limit on how many such "global" anycast sets may be
-   supported.  Therefore, it is expected that support for global anycast
-   sets may be unavailable or very restricted.
-
-   One expected use of anycast addresses is to identify the set of
-   routers belonging to an organization providing internet service.
-   Such addresses could be used as intermediate addresses in an IPv6
-   Routing header, to cause a packet to be delivered via a particular
-   aggregation or sequence of aggregations.  Some other possible uses
-   are to identify the set of routers attached to a particular subnet,
-   or the set of routers providing entry into a particular routing
-   domain.
-
-   There is little experience with widespread, arbitrary use of internet
-   anycast addresses, and some known complications and hazards when
-   using them in their full generality [ANYCST].  Until more experience
-   has been gained and solutions agreed upon for those problems, the
-   following restrictions are imposed on IPv6 anycast addresses:
-
-      o An anycast address must not be used as the source address of an
-        IPv6 packet.
-
-      o An anycast address must not be assigned to an IPv6 host, that
-        is, it may be assigned to an IPv6 router only.
-
-2.6.1 Required Anycast Address
-
-   The Subnet-Router anycast address is predefined.  Its format is as
-   follows:
-
-   |                         n bits                 |   128-n bits   |
-   +------------------------------------------------+----------------+
-   |                   subnet prefix                | 00000000000000 |
-   +------------------------------------------------+----------------+
-
-   The "subnet prefix" in an anycast address is the prefix which
-   identifies a specific link.  This anycast address is syntactically
-   the same as a unicast address for an interface on the link with the
-   interface identifier set to zero.
-
-   Packets sent to the Subnet-Router anycast address will be delivered
-   to one router on the subnet.  All routers are required to support the
-   Subnet-Router anycast addresses for the subnets which they have
-   interfaces.
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 13]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-   The subnet-router anycast address is intended to be used for
-   applications where a node needs to communicate with one of a set of
-   routers on a remote subnet.  For example when a mobile host needs to
-   communicate with one of the mobile agents on its "home" subnet.
-
-2.7 Multicast Addresses
-
-   An IPv6 multicast address is an identifier for a group of nodes.  A
-   node may belong to any number of multicast groups.  Multicast
-   addresses have the following format:
-
-   |   8    |  4 |  4 |                  112 bits                   |
-   +------ -+----+----+---------------------------------------------+
-   |11111111|flgs|scop|                  group ID                   |
-   +--------+----+----+---------------------------------------------+
-
-      11111111 at the start of the address identifies the address as
-      being a multicast address.
-
-                                    +-+-+-+-+
-      flgs is a set of 4 flags:     |0|0|0|T|
-                                    +-+-+-+-+
-
-         The high-order 3 flags are reserved, and must be initialized to
-         0.
-
-         T = 0 indicates a permanently-assigned ("well-known") multicast
-         address, assigned by the global internet numbering authority.
-
-         T = 1 indicates a non-permanently-assigned ("transient")
-         multicast address.
-
-      scop is a 4-bit multicast scope value used to limit the scope of
-      the multicast group.  The values are:
-
-         0  reserved
-         1  node-local scope
-         2  link-local scope
-         3  (unassigned)
-         4  (unassigned)
-         5  site-local scope
-         6  (unassigned)
-         7  (unassigned)
-         8  organization-local scope
-         9  (unassigned)
-         A  (unassigned)
-         B  (unassigned)
-         C  (unassigned)
-
-
-
-Hinden & Deering            Standards Track                    [Page 14]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-         D  (unassigned)
-         E  global scope
-         F  reserved
-
-      group ID identifies the multicast group, either permanent or
-      transient, within the given scope.
-
-   The "meaning" of a permanently-assigned multicast address is
-   independent of the scope value.  For example, if the "NTP servers
-   group" is assigned a permanent multicast address with a group ID of
-   101 (hex), then:
-
-      FF01:0:0:0:0:0:0:101 means all NTP servers on the same node as the
-      sender.
-
-      FF02:0:0:0:0:0:0:101 means all NTP servers on the same link as the
-      sender.
-
-      FF05:0:0:0:0:0:0:101 means all NTP servers at the same site as the
-      sender.
-
-      FF0E:0:0:0:0:0:0:101 means all NTP servers in the internet.
-
-   Non-permanently-assigned multicast addresses are meaningful only
-   within a given scope.  For example, a group identified by the non-
-   permanent, site-local multicast address FF15:0:0:0:0:0:0:101 at one
-   site bears no relationship to a group using the same address at a
-   different site, nor to a non-permanent group using the same group ID
-   with different scope, nor to a permanent group with the same group
-   ID.
-
-   Multicast addresses must not be used as source addresses in IPv6
-   packets or appear in any routing header.
-
-2.7.1 Pre-Defined Multicast Addresses
-
-   The following well-known multicast addresses are pre-defined:
-
-      Reserved Multicast Addresses:   FF00:0:0:0:0:0:0:0
-                                      FF01:0:0:0:0:0:0:0
-                                      FF02:0:0:0:0:0:0:0
-                                      FF03:0:0:0:0:0:0:0
-                                      FF04:0:0:0:0:0:0:0
-                                      FF05:0:0:0:0:0:0:0
-                                      FF06:0:0:0:0:0:0:0
-                                      FF07:0:0:0:0:0:0:0
-                                      FF08:0:0:0:0:0:0:0
-                                      FF09:0:0:0:0:0:0:0
-
-
-
-Hinden & Deering            Standards Track                    [Page 15]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-                                      FF0A:0:0:0:0:0:0:0
-                                      FF0B:0:0:0:0:0:0:0
-                                      FF0C:0:0:0:0:0:0:0
-                                      FF0D:0:0:0:0:0:0:0
-                                      FF0E:0:0:0:0:0:0:0
-                                      FF0F:0:0:0:0:0:0:0
-
-   The above multicast addresses are reserved and shall never be
-   assigned to any multicast group.
-
-      All Nodes Addresses:    FF01:0:0:0:0:0:0:1
-                              FF02:0:0:0:0:0:0:1
-
-   The above multicast addresses identify the group of all IPv6 nodes,
-   within scope 1 (node-local) or 2 (link-local).
-
-      All Routers Addresses:   FF01:0:0:0:0:0:0:2
-                               FF02:0:0:0:0:0:0:2
-                               FF05:0:0:0:0:0:0:2
-
-   The above multicast addresses identify the group of all IPv6 routers,
-   within scope 1 (node-local), 2 (link-local), or 5 (site-local).
-
-      Solicited-Node Address:  FF02:0:0:0:0:1:FFXX:XXXX
-
-   The above multicast address is computed as a function of a node's
-   unicast and anycast addresses.  The solicited-node multicast address
-   is formed by taking the low-order 24 bits of the address (unicast or
-   anycast) and appending those bits to the prefix
-   FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the
-   range
-
-      FF02:0:0:0:0:1:FF00:0000
-
-   to
-
-      FF02:0:0:0:0:1:FFFF:FFFF
-
-   For example, the solicited node multicast address corresponding to
-   the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C.  IPv6
-   addresses that differ only in the high-order bits, e.g. due to
-   multiple high-order prefixes associated with different aggregations,
-   will map to the same solicited-node address thereby reducing the
-   number of multicast addresses a node must join.
-
-   A node is required to compute and join the associated Solicited-Node
-   multicast addresses for every unicast and anycast address it is
-   assigned.
-
-
-
-Hinden & Deering            Standards Track                    [Page 16]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-2.7.2 Assignment of New IPv6 Multicast Addresses
-
-   The current approach [ETHER] to map IPv6 multicast addresses into
-   IEEE 802 MAC addresses takes the low order 32 bits of the IPv6
-   multicast address and uses it to create a MAC address.  Note that
-   Token Ring networks are handled differently.  This is defined in
-   [TOKEN].  Group ID's less than or equal to 32 bits will generate
-   unique MAC addresses.  Due to this new IPv6 multicast addresses
-   should be assigned so that the group identifier is always in the low
-   order 32 bits as shown in the following:
-
-   |   8    |  4 |  4 |          80 bits          |     32 bits     |
-   +------ -+----+----+---------------------------+-----------------+
-   |11111111|flgs|scop|   reserved must be zero   |    group ID     |
-   +--------+----+----+---------------------------+-----------------+
-
-   While this limits the number of permanent IPv6 multicast groups to
-   2^32 this is unlikely to be a limitation in the future.  If it
-   becomes necessary to exceed this limit in the future multicast will
-   still work but the processing will be sightly slower.
-
-   Additional IPv6 multicast addresses are defined and registered by the
-   IANA [MASGN].
-
-2.8 A Node's Required Addresses
-
-   A host is required to recognize the following addresses as
-   identifying itself:
-
-      o Its Link-Local Address for each interface
-      o Assigned Unicast Addresses
-      o Loopback Address
-      o All-Nodes Multicast Addresses
-      o Solicited-Node Multicast Address for each of its assigned
-        unicast and anycast addresses
-      o Multicast Addresses of all other groups to which the host
-        belongs.
-
-   A router is required to recognize all addresses that a host is
-   required to recognize, plus the following addresses as identifying
-   itself:
-
-      o The Subnet-Router anycast addresses for the interfaces it is
-        configured to act as a router on.
-      o All other Anycast addresses with which the router has been
-        configured.
-      o All-Routers Multicast Addresses
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 17]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-      o Multicast Addresses of all other groups to which the router
-        belongs.
-
-   The only address prefixes which should be predefined in an
-   implementation are the:
-
-      o Unspecified Address
-      o Loopback Address
-      o Multicast Prefix (FF)
-      o Local-Use Prefixes (Link-Local and Site-Local)
-      o Pre-Defined Multicast Addresses
-      o IPv4-Compatible Prefixes
-
-   Implementations should assume all other addresses are unicast unless
-   specifically configured (e.g., anycast addresses).
-
-3. Security Considerations
-
-   IPv6 addressing documents do not have any direct impact on Internet
-   infrastructure security.  Authentication of IPv6 packets is defined
-   in [AUTH].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 18]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-APPENDIX A : Creating EUI-64 based Interface Identifiers
---------------------------------------------------------
-
-   Depending on the characteristics of a specific link or node there are
-   a number of approaches for creating EUI-64 based interface
-   identifiers.  This appendix describes some of these approaches.
-
-Links or Nodes with EUI-64 Identifiers
-
-   The only change needed to transform an EUI-64 identifier to an
-   interface identifier is to invert the "u" (universal/local) bit.  For
-   example, a globally unique EUI-64 identifier of the form:
-
-   |0              1|1              3|3              4|4              6|
-   |0              5|6              1|2              7|8              3|
-   +----------------+----------------+----------------+----------------+
-   |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
-   +----------------+----------------+----------------+----------------+
-
-   where "c" are the bits of the assigned company_id, "0" is the value
-   of the universal/local bit to indicate global scope, "g" is
-   individual/group bit, and "m" are the bits of the manufacturer-
-   selected extension identifier.  The IPv6 interface identifier would
-   be of the form:
-
-   |0              1|1              3|3              4|4              6|
-   |0              5|6              1|2              7|8              3|
-   +----------------+----------------+----------------+----------------+
-   |cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
-   +----------------+----------------+----------------+----------------+
-
-   The only change is inverting the value of the universal/local bit.
-
-Links or Nodes with IEEE 802 48 bit MAC's
-
-   [EUI64] defines a method to create a EUI-64 identifier from an IEEE
-   48bit MAC identifier.  This is to insert two octets, with hexadecimal
-   values of 0xFF and 0xFE, in the middle of the 48 bit MAC (between the
-   company_id and vendor supplied id).  For example the 48 bit MAC with
-   global scope:
-
-   |0              1|1              3|3              4|
-   |0              5|6              1|2              7|
-   +----------------+----------------+----------------+
-   |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|
-   +----------------+----------------+----------------+
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 19]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-   where "c" are the bits of the assigned company_id, "0" is the value
-   of the universal/local bit to indicate global scope, "g" is
-   individual/group bit, and "m" are the bits of the manufacturer-
-   selected extension identifier.  The interface identifier would be of
-   the form:
-
-   |0              1|1              3|3              4|4              6|
-   |0              5|6              1|2              7|8              3|
-   +----------------+----------------+----------------+----------------+
-   |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm|
-   +----------------+----------------+----------------+----------------+
-
-   When IEEE 802 48bit MAC addresses are available (on an interface or a
-   node), an implementation should use them to create interface
-   identifiers due to their availability and uniqueness properties.
-
-Links with Non-Global Identifiers
-
-   There are a number of types of links that, while multi-access, do not
-   have globally unique link identifiers.  Examples include LocalTalk
-   and Arcnet.  The method to create an EUI-64 formatted identifier is
-   to take the link identifier (e.g., the LocalTalk 8 bit node
-   identifier) and zero fill it to the left.  For example a LocalTalk 8
-   bit node identifier of hexadecimal value 0x4F results in the
-   following interface identifier:
-
-   |0              1|1              3|3              4|4              6|
-   |0              5|6              1|2              7|8              3|
-   +----------------+----------------+----------------+----------------+
-   |0000000000000000|0000000000000000|0000000000000000|0000000001001111|
-   +----------------+----------------+----------------+----------------+
-
-   Note that this results in the universal/local bit set to "0" to
-   indicate local scope.
-
-Links without Identifiers
-
-   There are a number of links that do not have any type of built-in
-   identifier.  The most common of these are serial links and configured
-   tunnels.  Interface identifiers must be chosen that are unique for
-   the link.
-
-   When no built-in identifier is available on a link the preferred
-   approach is to use a global interface identifier from another
-   interface or one which is assigned to the node itself.  To use this
-   approach no other interface connecting the same node to the same link
-   may use the same identifier.
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 20]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-   If there is no global interface identifier available for use on the
-   link the implementation needs to create a local scope interface
-   identifier.  The only requirement is that it be unique on the link.
-   There are many possible approaches to select a link-unique interface
-   identifier.  They include:
-
-      Manual Configuration
-      Generated Random Number
-      Node Serial Number (or other node-specific token)
-
-   The link-unique interface identifier should be generated in a manner
-   that it does not change after a reboot of a node or if interfaces are
-   added or deleted from the node.
-
-   The selection of the appropriate algorithm is link and implementation
-   dependent.  The details on forming interface identifiers are defined
-   in the appropriate "IPv6 over <link>" specification.  It is strongly
-   recommended that a collision detection algorithm be implemented as
-   part of any automatic algorithm.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 21]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-APPENDIX B: ABNF Description of Text Representations
-----------------------------------------------------
-
-   This appendix defines the text representation of IPv6 addresses and
-   prefixes in Augmented BNF [ABNF] for reference purposes.
-
-      IPv6address = hexpart [ ":" IPv4address ]
-      IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
-
-      IPv6prefix  = hexpart "/" 1*2DIGIT
-
-      hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ]
-      hexseq  = hex4 *( ":" hex4)
-      hex4    = 1*4HEXDIG
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 22]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-APPENDIX C: CHANGES FROM RFC-1884
----------------------------------
-
-   The following changes were made from RFC-1884 "IP Version 6
-   Addressing Architecture":
-
-      - Added an appendix providing a ABNF description of text
-        representations.
-      - Clarification that link unique identifiers not change after
-        reboot or other interface reconfigurations.
-      - Clarification of Address Model based on comments.
-      - Changed aggregation format terminology to be consistent with
-        aggregation draft.
-      - Added text to allow interface identifier to be used on more than
-        one interface on same node.
-      - Added rules for defining new multicast addresses.
-      - Added appendix describing procedures for creating EUI-64 based
-        interface ID's.
-      - Added notation for defining IPv6 prefixes.
-      - Changed solicited node multicast definition to use a longer
-        prefix.
-      - Added site scope all routers multicast address.
-      - Defined Aggregatable Global Unicast Addresses to use "001" Format
-        Prefix.
-      - Changed "010" (Provider-Based Unicast) and "100" (Reserved for
-        Geographic) Format Prefixes to Unassigned.
-      - Added section on Interface ID definition for unicast addresses.
-        Requires use of EUI-64 in range of format prefixes and rules for
-        setting global/local scope bit in EUI-64.
-      - Updated NSAP text to reflect working in RFC1888.
-      - Removed protocol specific IPv6 multicast addresses (e.g., DHCP)
-        and referenced the IANA definitions.
-      - Removed section "Unicast Address Example".  Had become OBE.
-      - Added new and updated references.
-      - Minor text clarifications and improvements.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 23]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-REFERENCES
-
-   [ABNF]    Crocker, D., and P. Overell, "Augmented BNF for
-             Syntax Specifications: ABNF", RFC 2234, November 1997.
-
-   [AGGR]    Hinden, R., O'Dell, M., and S. Deering, "An
-             Aggregatable Global Unicast Address Format", RFC 2374, July
-             1998.
-
-   [AUTH]    Atkinson, R., "IP Authentication Header", RFC 1826, August
-             1995.
-
-   [ANYCST]  Partridge, C., Mendez, T., and W. Milliken, "Host
-             Anycasting Service", RFC 1546, November 1993.
-
-   [CIDR]    Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless
-             Inter-Domain Routing (CIDR): An Address Assignment and
-             Aggregation Strategy", RFC 1519, September 1993.
-
-   [ETHER]   Crawford, M., "Transmission of IPv6 Pacekts over Ethernet
-             Networks", Work in Progress.
-
-   [EUI64]   IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
-             Registration Authority",
-             http://standards.ieee.org/db/oui/tutorials/EUI64.html,
-             March 1997.
-
-   [FDDI]    Crawford, M., "Transmission of IPv6 Packets over FDDI
-             Networks", Work in Progress.
-
-   [IPV6]    Deering, S., and R. Hinden, Editors, "Internet Protocol,
-             Version 6 (IPv6) Specification", RFC 1883, December 1995.
-
-   [MASGN]   Hinden, R., and S. Deering, "IPv6 Multicast Address
-             Assignments", RFC 2375, July 1998.
-
-   [NSAP]    Bound, J., Carpenter, B., Harrington, D., Houldsworth, J.,
-             and A. Lloyd, "OSI NSAPs and IPv6", RFC 1888, August 1996.
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [TOKEN]   Thomas, S., "Transmission of IPv6 Packets over Token Ring
-             Networks", Work in Progress.
-
-   [TRAN]    Gilligan, R., and E. Nordmark, "Transition Mechanisms for
-             IPv6 Hosts and Routers", RFC 1993, April 1996.
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 24]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-AUTHORS' ADDRESSES
-
-   Robert M. Hinden
-   Nokia
-   232 Java Drive
-   Sunnyvale, CA 94089
-   USA
-
-   Phone: +1 408 990-2004
-   Fax:   +1 408 743-5677
-   EMail: hinden@iprg.nokia.com
-
-
-   Stephen E. Deering
-   Cisco Systems, Inc.
-   170 West Tasman Drive
-   San Jose, CA 95134-1706
-   USA
-
-   Phone: +1 408 527-8213
-   Fax:   +1 408 527-8254
-   EMail: deering@cisco.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 25]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 26]
-
diff --git a/contrib/bind9/doc/rfc/rfc2374.txt b/contrib/bind9/doc/rfc/rfc2374.txt
deleted file mode 100644
index e3c7f0d..0000000
--- a/contrib/bind9/doc/rfc/rfc2374.txt
+++ /dev/null
@@ -1,675 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        R. Hinden
-Request for Comments: 2374                                       Nokia
-Obsoletes: 2073                                              M. O'Dell
-Category: Standards Track                                        UUNET
-                                                            S. Deering
-                                                                 Cisco
-                                                             July 1998
-
-
-           An IPv6 Aggregatable Global Unicast Address Format
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-1.0 Introduction
-
-   This document defines an IPv6 aggregatable global unicast address
-   format for use in the Internet.  The address format defined in this
-   document is consistent with the IPv6 Protocol [IPV6] and the "IPv6
-   Addressing Architecture" [ARCH].  It is designed to facilitate
-   scalable Internet routing.
-
-   This documented replaces RFC 2073, "An IPv6 Provider-Based Unicast
-   Address Format".  RFC 2073 will become historic.  The Aggregatable
-   Global Unicast Address Format is an improvement over RFC 2073 in a
-   number of areas.  The major changes include removal of the registry
-   bits because they are not needed for route aggregation, support of
-   EUI-64 based interface identifiers, support of provider and exchange
-   based aggregation, separation of public and site topology, and new
-   aggregation based terminology.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC 2119].
-
-
-
-
-
-
-
-
-Hinden, et. al.             Standards Track                     [Page 1]
-
-RFC 2374           IPv6 Global Unicast Address Format          July 1998
-
-
-2.0 Overview of the IPv6 Address
-
-   IPv6 addresses are 128-bit identifiers for interfaces and sets of
-   interfaces.  There are three types of addresses: Unicast, Anycast,
-   and Multicast.  This document defines a specific type of Unicast
-   address.
-
-   In this document, fields in addresses are given specific names, for
-   example "subnet".  When this name is used with the term "ID" (for
-   "identifier") after the name (e.g., "subnet ID"), it refers to the
-   contents of the named field.  When it is used with the term "prefix"
-   (e.g.  "subnet prefix") it refers to all of the addressing bits to
-   the left of and including this field.
-
-   IPv6 unicast addresses are designed assuming that the Internet
-   routing system makes forwarding decisions based on a "longest prefix
-   match" algorithm on arbitrary bit boundaries and does not have any
-   knowledge of the internal structure of IPv6 addresses.  The structure
-   in IPv6 addresses is for assignment and allocation.  The only
-   exception to this is the distinction made between unicast and
-   multicast addresses.
-
-   The specific type of an IPv6 address is indicated by the leading bits
-   in the address.  The variable-length field comprising these leading
-   bits is called the Format Prefix (FP).
-
-   This document defines an address format for the 001 (binary) Format
-   Prefix for Aggregatable Global Unicast addresses. The same address
-   format could be used for other Format Prefixes, as long as these
-   Format Prefixes also identify IPv6 unicast addresses.  Only the "001"
-   Format Prefix is defined here.
-
-3.0 IPv6 Aggregatable Global Unicast Address Format
-
-   This document defines an address format for the IPv6 aggregatable
-   global unicast address assignment.  The authors believe that this
-   address format will be widely used for IPv6 nodes connected to the
-   Internet.  This address format is designed to support both the
-   current provider-based aggregation and a new type of exchange-based
-   aggregation.  The combination will allow efficient routing
-   aggregation for sites that connect directly to providers and for
-   sites that connect to exchanges.  Sites will have the choice to
-   connect to either type of aggregation entity.
-
-
-
-
-
-
-
-
-Hinden, et. al.             Standards Track                     [Page 2]
-
-RFC 2374           IPv6 Global Unicast Address Format          July 1998
-
-
-   While this address format is designed to support exchange-based
-   aggregation (in addition to current provider-based aggregation) it is
-   not dependent on exchanges for it's overall route aggregation
-   properties.  It will provide efficient route aggregation with only
-   provider-based aggregation.
-
-   Aggregatable addresses are organized into a three level hierarchy:
-
-      - Public Topology
-      - Site Topology
-      - Interface Identifier
-
-   Public topology is the collection of providers and exchanges who
-   provide public Internet transit services.  Site topology is local to
-   a specific site or organization which does not provide public transit
-   service to nodes outside of the site.  Interface identifiers identify
-   interfaces on links.
-
-        ______________                  ______________
-    --+/              \+--------------+/              \+----------
-      (       P1       )    +----+    (       P3       )  +----+
-      +\______________/     |    |----+\______________/+--|    |--
-      |                  +--| X1 |                       +| X2 |
-      | ______________  /   |    |-+    ______________  / |    |--
-      +/              \+    +-+--+  \  /              \+  +----+
-      (       P2       )     / \     +(      P4        )
-    --+\______________/     /   \      \______________/
-           |               /     \           |      |
-           |              /       |          |      |
-           |             /        |          |      |
-          _|_          _/_       _|_        _|_    _|_
-         /   \        /   \     /   \      /   \  /   \
-        ( S.A )      ( S.B )   ( P5  )    ( P6  )( S.C )
-         \___/        \___/     \___/      \___/  \___/
-                                  |          / \
-                                 _|_       _/_  \   ___
-                                /   \     /   \  +-/   \
-                               ( S.D )   ( S.E )  ( S.F )
-                                \___/     \___/    \___/
-
-   As shown in the figure above, the aggregatable address format is
-   designed to support long-haul providers (shown as P1, P2, P3, and
-   P4), exchanges (shown as X1 and X2), multiple levels of providers
-   (shown at P5 and P6), and subscribers (shown as S.x) Exchanges
-   (unlike current NAPs, FIXes, etc.) will allocate IPv6 addresses.
-   Organizations who connect to these exchanges will also subscribe
-   (directly, indirectly via the exchange, etc.) for long-haul service
-   from one or more long-haul providers.  Doing so, they will achieve
-
-
-
-Hinden, et. al.             Standards Track                     [Page 3]
-
-RFC 2374           IPv6 Global Unicast Address Format          July 1998
-
-
-   addressing independence from long-haul transit providers.  They will
-   be able to change long-haul providers without having to renumber
-   their organization.  They can also be multihomed via the exchange to
-   more than one long-haul provider without having to have address
-   prefixes from each long-haul provider.  Note that the mechanisms used
-   for this type of provider selection and portability are not discussed
-   in the document.
-
-3.1 Aggregatable Global Unicast Address Structure
-
-   The aggregatable global unicast address format is as follows:
-
-     | 3|  13 | 8 |   24   |   16   |          64 bits               |
-     +--+-----+---+--------+--------+--------------------------------+
-     |FP| TLA |RES|  NLA   |  SLA   |         Interface ID           |
-     |  | ID  |   |  ID    |  ID    |                                |
-     +--+-----+---+--------+--------+--------------------------------+
-
-     <--Public Topology--->   Site
-                           <-------->
-                            Topology
-                                     <------Interface Identifier----->
-
-   Where
-
-      FP           Format Prefix (001)
-      TLA ID       Top-Level Aggregation Identifier
-      RES          Reserved for future use
-      NLA ID       Next-Level Aggregation Identifier
-      SLA ID       Site-Level Aggregation Identifier
-      INTERFACE ID Interface Identifier
-
-   The following sections specify each part of the IPv6 Aggregatable
-   Global Unicast address format.
-
-3.2 Top-Level Aggregation ID
-
-   Top-Level Aggregation Identifiers (TLA ID) are the top level in the
-   routing hierarchy.  Default-free routers must have a routing table
-   entry for every active TLA ID and will probably have additional
-   entries providing routing information for the TLA ID in which they
-   are located.  They may have additional entries in order to optimize
-   routing for their specific topology, but the routing topology at all
-   levels must be designed to minimize the number of additional entries
-   fed into the default free routing tables.
-
-
-
-
-
-
-Hinden, et. al.             Standards Track                     [Page 4]
-
-RFC 2374           IPv6 Global Unicast Address Format          July 1998
-
-
-   This addressing format supports 8,192 (2^13) TLA ID's.  Additional
-   TLA ID's may be added by either growing the TLA field to the right
-   into the reserved field or by using this format for additional format
-   prefixes.
-
-   The issues relating to TLA ID assignment are beyond the scope of this
-   document.  They will be described in a document under preparation.
-
-3.3 Reserved
-
-   The Reserved field is reserved for future use and must be set to
-   zero.
-
-   The Reserved field allows for future growth of the TLA and NLA fields
-   as appropriate.  See section 4.0 for a discussion.
-
-3.4 Next-Level Aggregation Identifier
-
-   Next-Level Aggregation Identifier's are used by organizations
-   assigned a TLA ID to create an addressing hierarchy and to identify
-   sites.  The organization can assign the top part of the NLA ID in a
-   manner to create an addressing hierarchy appropriate to its network.
-   It can use the remainder of the bits in the field to identify sites
-   it wishes to serve.  This is shown as follows:
-
-      |  n  |      24-n bits     |   16   |    64 bits      |
-      +-----+--------------------+--------+-----------------+
-      |NLA1 |      Site ID       | SLA ID | Interface ID    |
-      +-----+--------------------+--------+-----------------+
-
-   Each organization assigned a TLA ID receives 24 bits of NLA ID space.
-   This NLA ID space allows each organization to provide service to
-   approximately as many organizations as the current IPv4 Internet can
-   support total networks.
-
-   Organizations assigned TLA ID's may also support NLA ID's in their
-   own Site ID space.  This allows the organization assigned a TLA ID to
-   provide service to organizations providing public transit service and
-   to organizations who do not provide public transit service.  These
-   organizations receiving an NLA ID may also choose to use their Site
-   ID space to support other NLA ID's.  This is shown as follows:
-
-
-
-
-
-
-
-
-
-
-Hinden, et. al.             Standards Track                     [Page 5]
-
-RFC 2374           IPv6 Global Unicast Address Format          July 1998
-
-
-   |  n  |      24-n bits     |   16   |    64 bits      |
-   +-----+--------------------+--------+-----------------+
-   |NLA1 |      Site ID       | SLA ID | Interface ID    |
-   +-----+--------------------+--------+-----------------+
-
-         |  m  |    24-n-m    |   16   |    64 bits      |
-         +-----+--------------+--------+-----------------+
-         |NLA2 |   Site ID    | SLA ID | Interface ID    |
-         +-----+--------------+--------+-----------------+
-
-               |  o  |24-n-m-o|   16   |    64 bits      |
-               +-----+--------+--------+-----------------+
-               |NLA3 | Site ID| SLA ID | Interface ID    |
-               +-----+--------+--------+-----------------+
-
-   The design of the bit layout of the NLA ID space for a specific TLA
-   ID is left to the organization responsible for that TLA ID.  Likewise
-   the design of the bit layout of the next level NLA ID is the
-   responsibility of the previous level NLA ID.  It is recommended that
-   organizations assigning NLA address space use "slow start" allocation
-   procedures similar to [RFC2050].
-
-   The design of an NLA ID allocation plan is a tradeoff between routing
-   aggregation efficiency and flexibility.  Creating hierarchies allows
-   for greater amount of aggregation and results in smaller routing
-   tables.  Flat NLA ID assignment provides for easier allocation and
-   attachment flexibility, but results in larger routing tables.
-
-3.5 Site-Level Aggregation Identifier
-
-   The SLA ID field is used by an individual organization to create its
-   own local addressing hierarchy and to identify subnets.  This is
-   analogous to subnets in IPv4 except that each organization has a much
-   greater number of subnets.  The 16 bit SLA ID field support 65,535
-   individual subnets.
-
-   Organizations may choose to either route their SLA ID "flat" (e.g.,
-   not create any logical relationship between the SLA identifiers that
-   results in larger routing tables), or to create a two or more level
-   hierarchy (that results in smaller routing tables) in the SLA ID
-   field.  The latter is shown as follows:
-
-
-
-
-
-
-
-
-
-
-Hinden, et. al.             Standards Track                     [Page 6]
-
-RFC 2374           IPv6 Global Unicast Address Format          July 1998
-
-
-   |  n  |   16-n     |              64 bits                |
-   +-----+------------+-------------------------------------+
-   |SLA1 |   Subnet   |            Interface ID             |
-   +-----+------------+-------------------------------------+
-
-         | m  |16-n-m |              64 bits                |
-         +----+-------+-------------------------------------+
-         |SLA2|Subnet |            Interface ID             |
-         +----+-------+-------------------------------------+
-
-   The approach chosen for structuring an SLA ID field is the
-   responsibility of the individual organization.
-
-   The number of subnets supported in this address format should be
-   sufficient for all but the largest of organizations.  Organizations
-   which need additional subnets can arrange with the organization they
-   are obtaining Internet service from to obtain additional site
-   identifiers and use this to create additional subnets.
-
-3.6 Interface ID
-
-   Interface identifiers are used to identify interfaces on a link.
-   They are required to be unique on that link.  They may also be unique
-   over a broader scope.  In many cases an interfaces identifier will be
-   the same or be based on the interface's link-layer address.
-   Interface IDs used in the aggregatable global unicast address format
-   are required to be 64 bits long and to be constructed in IEEE EUI-64
-   format [EUI-64].  These identifiers may have global scope when a
-   global token (e.g., IEEE 48bit MAC) is available or may have local
-   scope where a global token is not available (e.g., serial links,
-   tunnel end-points, etc.).  The "u" bit (universal/local bit in IEEE
-   EUI-64 terminology) in the EUI-64 identifier must be set correctly,
-   as defined in [ARCH], to indicate global or local scope.
-
-   The procedures for creating EUI-64 based Interface Identifiers is
-   defined in [ARCH].  The details on forming interface identifiers is
-   defined in the appropriate "IPv6 over <link>" specification such as
-   "IPv6 over Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc.
-
-4.0 Technical Motivation
-
-   The design choices for the size of the fields in the aggregatable
-   address format were based on the need to meet a number of technical
-   requirements.  These are described in the following paragraphs.
-
-   The size of the Top-Level Aggregation Identifier is 13 bits.  This
-   allows for 8,192 TLA ID's.  This size was chosen to insure that the
-   default-free routing table in top level routers in the Internet is
-
-
-
-Hinden, et. al.             Standards Track                     [Page 7]
-
-RFC 2374           IPv6 Global Unicast Address Format          July 1998
-
-
-   kept within the limits, with a reasonable margin, of the current
-   routing technology.  The margin is important because default-free
-   routers will also carry a significant number of longer (i.e., more-
-   specific) prefixes for optimizing paths internal to a TLA and between
-   TLAs.
-
-   The important issue is not only the size of the default-free routing
-   table, but the complexity of the topology that determines the number
-   of copies of the default-free routes that a router must examine while
-   computing a forwarding table.  Current practice with IPv4 it is
-   common to see a prefix announced fifteen times via different paths.
-
-   The complexity of Internet topology is very likely to increase in the
-   future.  It is important that IPv6 default-free routing support
-   additional complexity as well as a considerably larger internet.
-
-   It should be noted for comparison that at the time of this writing
-   (spring, 1998) the IPv4 default-free routing table contains
-   approximately 50,000 prefixes.  While this shows that it is possible
-   to support more routes than 8,192 it is matter of debate if the
-   number of prefixes supported today in IPv4 is already too high for
-   current routing technology.  There are serious issues of route
-   stability as well as cases of providers not supporting all top level
-   prefixes.  The technical requirement was to pick a TLA ID size that
-   was below, with a reasonable margin, what was being done with IPv4.
-
-   The choice of 13 bits for the TLA field was an engineering
-   compromise.  Fewer bits would have been too small by not supporting
-   enough top level organizations.  More bits would have exceeded what
-   can be reasonably accommodated, with a reasonable margin, with
-   current routing technology in order to deal with the issues described
-   in the previous paragraphs.
-
-   If in the future, routing technology improves to support a larger
-   number of top level routes in the default-free routing tables there
-   are two choices on how to increase the number TLA identifiers.  The
-   first is to expand the TLA ID field into the reserved field.  This
-   would increase the number of TLA ID's to approximately 2 million.
-   The second approach is to allocate another format prefix (FP) for use
-   with this address format.  Either or a combination of these
-   approaches allows the number of TLA ID's to increase significantly.
-
-   The size of the Reserved field is 8 bits.  This size was chosen to
-   allow significant growth of either the TLA ID and/or the NLA ID
-   fields.
-
-   The size of the Next-Level Aggregation Identifier field is 24 bits.
-
-
-
-
-Hinden, et. al.             Standards Track                     [Page 8]
-
-RFC 2374           IPv6 Global Unicast Address Format          July 1998
-
-
-   This allows for approximately sixteen million NLA ID's if used in a
-   flat manner.  Used hierarchically it allows for a complexity roughly
-   equivalent to the IPv4 address space (assuming an average network
-   size of 254 interfaces).  If in the future additional room for
-   complexity is needed in the NLA ID, this may be accommodated by
-   extending the NLA ID into the Reserved field.
-
-   The size of the Site-Level Aggregation Identifier field is 16 bits.
-   This supports 65,535 individual subnets per site.  The design goal
-   for the size of this field was to be sufficient for all but the
-   largest of organizations.  Organizations which need additional
-   subnets can arrange with the organization they are obtaining Internet
-   service from to obtain additional site identifiers and use this to
-   create additional subnets.
-
-   The Site-Level Aggregation Identifier field was given a fixed size in
-   order to force the length of all prefixes identifying a particular
-   site to be the same length (i.e., 48 bits).  This facilitates
-   movement of sites in the topology (e.g., changing service providers
-   and multi-homing to multiple service providers).
-
-   The Interface ID Interface Identifier field is 64 bits.  This size
-   was chosen to meet the requirement specified in [ARCH] to support
-   EUI-64 based Interface Identifiers.
-
-5.0 Acknowledgments
-
-   The authors would like to express our thanks to Thomas Narten, Bob
-   Fink, Matt Crawford, Allison Mankin, Jim Bound, Christian Huitema,
-   Scott Bradner, Brian Carpenter, John Stewart, and Daniel Karrenberg
-   for their review and constructive comments.
-
-6.0 References
-
-   [ALLOC]   IAB and IESG, "IPv6 Address Allocation Management",
-             RFC 1881, December 1995.
-
-   [ARCH]    Hinden, R., "IP Version 6 Addressing Architecture",
-             RFC 2373, July 1998.
-
-   [AUTH]    Atkinson, R., "IP Authentication Header", RFC 1826, August
-             1995.
-
-   [AUTO]    Thompson, S., and T. Narten., "IPv6 Stateless Address
-             Autoconfiguration", RFC 1971, August 1996.
-
-   [ETHER]   Crawford, M., "Transmission of IPv6 Packets over Ethernet
-             Networks", Work in Progress.
-
-
-
-Hinden, et. al.             Standards Track                     [Page 9]
-
-RFC 2374           IPv6 Global Unicast Address Format          July 1998
-
-
-   [EUI64]   IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
-             Registration Authority",
-             http://standards.ieee.org/db/oui/tutorials/EUI64.html,
-             March 1997.
-
-   [FDDI]    Crawford, M., "Transmission of IPv6 Packets over FDDI
-             Networks", Work in Progress.
-
-   [IPV6]    Deering, S., and R. Hinden, "Internet Protocol, Version 6
-             (IPv6) Specification", RFC 1883, December 1995.
-
-   [RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D.,
-             and J. Postel, "Internet Registry IP Allocation
-             Guidelines", BCP 12, RFC 1466, November 1996.
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-7.0 Security Considerations
-
-   IPv6 addressing documents do not have any direct impact on Internet
-   infrastructure security.  Authentication of IPv6 packets is defined
-   in [AUTH].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden, et. al.             Standards Track                    [Page 10]
-
-RFC 2374           IPv6 Global Unicast Address Format          July 1998
-
-
-8.0 Authors' Addresses
-
-   Robert M. Hinden
-   Nokia
-   232 Java Drive
-   Sunnyvale, CA 94089
-   USA
-
-   Phone: 1 408 990-2004
-   EMail: hinden@iprg.nokia.com
-
-
-   Mike O'Dell
-   UUNET Technologies, Inc.
-   3060 Williams Drive
-   Fairfax, VA 22030
-   USA
-
-   Phone: 1 703 206-5890
-   EMail: mo@uunet.uu.net
-
-
-   Stephen E. Deering
-   Cisco Systems, Inc.
-   170 West Tasman Drive
-   San Jose, CA 95134-1706
-   USA
-
-   Phone: 1 408 527-8213
-   EMail: deering@cisco.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden, et. al.             Standards Track                    [Page 11]
-
-RFC 2374           IPv6 Global Unicast Address Format          July 1998
-
-
-9.0  Full Copyright Statement
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden, et. al.             Standards Track                    [Page 12]
-
diff --git a/contrib/bind9/doc/rfc/rfc2375.txt b/contrib/bind9/doc/rfc/rfc2375.txt
deleted file mode 100644
index a1fe8b9..0000000
--- a/contrib/bind9/doc/rfc/rfc2375.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         R. Hinden
-Request for Comments: 2375                             Ipsilon Networks
-Category: Informational                                      S. Deering
-                                                                  Cisco
-                                                              July 1998
-
-
-                   IPv6 Multicast Address Assignments
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-1.0 Introduction
-
-   This document defines the initial assignment of IPv6 multicast
-   addresses.  It is based on the "IP Version 6 Addressing Architecture"
-   [ADDARCH] and current IPv4 multicast address assignment found in
-   <ftp://venera.isi.edu/in-notes/iana/assignments/multicast-addresses>.
-   It adapts the IPv4 assignments that are relevant to IPv6 assignments.
-   IPv4 assignments that were not relevant were not converted into IPv6
-   assignments.  Comments are solicited on this conversion.
-
-   All other IPv6 multicast addresses are reserved.
-
-   Sections 2 and 3 specify reserved and preassigned IPv6 multicast
-   addresses.
-
-   [ADDRARCH] defines rules for assigning new IPv6 multicast addresses.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC 2119].
-
-2. Fixed Scope Multicast Addresses
-
-   These permanently assigned multicast addresses are valid over a
-   specified scope value.
-
-
-
-
-
-
-
-Hinden & Deering             Informational                      [Page 1]
-
-RFC 2375           IPv6 Multicast Address Assignments          July 1998
-
-
-2.1 Node-Local Scope
-
-   FF01:0:0:0:0:0:0:1     All Nodes Address                  [ADDARCH]
-   FF01:0:0:0:0:0:0:2     All Routers Address                [ADDARCH]
-
-2.2 Link-Local Scope
-
-   FF02:0:0:0:0:0:0:1     All Nodes Address                  [ADDARCH]
-   FF02:0:0:0:0:0:0:2     All Routers Address                [ADDARCH]
-   FF02:0:0:0:0:0:0:3     Unassigned                             [JBP]
-   FF02:0:0:0:0:0:0:4     DVMRP Routers                  [RFC1075,JBP]
-   FF02:0:0:0:0:0:0:5     OSPFIGP                        [RFC2328,Moy]
-   FF02:0:0:0:0:0:0:6     OSPFIGP Designated Routers     [RFC2328,Moy]
-   FF02:0:0:0:0:0:0:7     ST Routers                    [RFC1190,KS14]
-   FF02:0:0:0:0:0:0:8     ST Hosts                      [RFC1190,KS14]
-   FF02:0:0:0:0:0:0:9     RIP Routers                        [RFC2080]
-   FF02:0:0:0:0:0:0:A     EIGRP Routers                    [Farinacci]
-   FF02:0:0:0:0:0:0:B     Mobile-Agents                 [Bill Simpson]
-
-   FF02:0:0:0:0:0:0:D     All PIM Routers                  [Farinacci]
-   FF02:0:0:0:0:0:0:E     RSVP-ENCAPSULATION                  [Braden]
-
-   FF02:0:0:0:0:0:1:1     Link Name                       [Harrington]
-   FF02:0:0:0:0:0:1:2     All-dhcp-agents              [Bound,Perkins]
-
-   FF02:0:0:0:0:1:FFXX:XXXX     Solicited-Node Address       [ADDARCH]
-
-2.3 Site-Local Scope
-
-   FF05:0:0:0:0:0:0:2       All Routers Address              [ADDARCH]
-
-   FF05:0:0:0:0:0:1:3       All-dhcp-servers           [Bound,Perkins]
-   FF05:0:0:0:0:0:1:4       All-dhcp-relays            [Bound,Perkins]
-   FF05:0:0:0:0:0:1:1000    Service Location                 [RFC2165]
-    -FF05:0:0:0:0:0:1:13FF
-
-3.0 All Scope Multicast Addresses
-
-   These permanently assigned multicast addresses are valid over all
-   scope ranges.  This is shown by an "X" in the scope field of the
-   address that means any legal scope value.
-
-   Note that, as defined in [ADDARCH], IPv6 multicast addresses which
-   are only different in scope represent different groups.  Nodes must
-   join each group individually.
-
-   The IPv6 multicast addresses with variable scope are as follows:
-
-
-
-
-Hinden & Deering             Informational                      [Page 2]
-
-RFC 2375           IPv6 Multicast Address Assignments          July 1998
-
-
-   FF0X:0:0:0:0:0:0:0     Reserved Multicast Address         [ADDARCH]
-
-   FF0X:0:0:0:0:0:0:100   VMTP Managers Group           [RFC1045,DRC3]
-   FF0X:0:0:0:0:0:0:101   Network Time Protocol (NTP)   [RFC1119,DLM1]
-   FF0X:0:0:0:0:0:0:102   SGI-Dogfight                           [AXC]
-   FF0X:0:0:0:0:0:0:103   Rwhod                                  [SXD]
-   FF0X:0:0:0:0:0:0:104   VNP                                   [DRC3]
-   FF0X:0:0:0:0:0:0:105   Artificial Horizons - Aviator          [BXF]
-   FF0X:0:0:0:0:0:0:106   NSS - Name Service Server             [BXS2]
-   FF0X:0:0:0:0:0:0:107   AUDIONEWS - Audio News Multicast      [MXF2]
-   FF0X:0:0:0:0:0:0:108   SUN NIS+ Information Service          [CXM3]
-   FF0X:0:0:0:0:0:0:109   MTP Multicast Transport Protocol       [SXA]
-   FF0X:0:0:0:0:0:0:10A   IETF-1-LOW-AUDIO                       [SC3]
-   FF0X:0:0:0:0:0:0:10B   IETF-1-AUDIO                           [SC3]
-   FF0X:0:0:0:0:0:0:10C   IETF-1-VIDEO                           [SC3]
-   FF0X:0:0:0:0:0:0:10D   IETF-2-LOW-AUDIO                       [SC3]
-   FF0X:0:0:0:0:0:0:10E   IETF-2-AUDIO                           [SC3]
-   FF0X:0:0:0:0:0:0:10F   IETF-2-VIDEO                           [SC3]
-
-   FF0X:0:0:0:0:0:0:110   MUSIC-SERVICE             [Guido van Rossum]
-   FF0X:0:0:0:0:0:0:111   SEANET-TELEMETRY             [Andrew Maffei]
-   FF0X:0:0:0:0:0:0:112   SEANET-IMAGE                 [Andrew Maffei]
-   FF0X:0:0:0:0:0:0:113   MLOADD                              [Braden]
-   FF0X:0:0:0:0:0:0:114   any private experiment                 [JBP]
-   FF0X:0:0:0:0:0:0:115   DVMRP on MOSPF                         [Moy]
-   FF0X:0:0:0:0:0:0:116   SVRLOC                            [Veizades]
-   FF0X:0:0:0:0:0:0:117   XINGTV                      <hgxing@aol.com>
-   FF0X:0:0:0:0:0:0:118   microsoft-ds         <arnoldm@microsoft.com>
-   FF0X:0:0:0:0:0:0:119   nbc-pro           <bloomer@birch.crd.ge.com>
-   FF0X:0:0:0:0:0:0:11A   nbc-pfn           <bloomer@birch.crd.ge.com>
-   FF0X:0:0:0:0:0:0:11B   lmsc-calren-1                         [Uang]
-   FF0X:0:0:0:0:0:0:11C   lmsc-calren-2                         [Uang]
-   FF0X:0:0:0:0:0:0:11D   lmsc-calren-3                         [Uang]
-   FF0X:0:0:0:0:0:0:11E   lmsc-calren-4                         [Uang]
-   FF0X:0:0:0:0:0:0:11F   ampr-info                          [Janssen]
-
-   FF0X:0:0:0:0:0:0:120   mtrace                              [Casner]
-   FF0X:0:0:0:0:0:0:121   RSVP-encap-1                        [Braden]
-   FF0X:0:0:0:0:0:0:122   RSVP-encap-2                        [Braden]
-   FF0X:0:0:0:0:0:0:123   SVRLOC-DA                         [Veizades]
-   FF0X:0:0:0:0:0:0:124   rln-server                            [Kean]
-   FF0X:0:0:0:0:0:0:125   proshare-mc                          [Lewis]
-   FF0X:0:0:0:0:0:0:126   dantz                               [Yackle]
-   FF0X:0:0:0:0:0:0:127   cisco-rp-announce                [Farinacci]
-   FF0X:0:0:0:0:0:0:128   cisco-rp-discovery               [Farinacci]
-   FF0X:0:0:0:0:0:0:129   gatekeeper                            [Toga]
-   FF0X:0:0:0:0:0:0:12A   iberiagames                        [Marocho]
-
-
-
-
-Hinden & Deering             Informational                      [Page 3]
-
-RFC 2375           IPv6 Multicast Address Assignments          July 1998
-
-
-   FF0X:0:0:0:0:0:0:201  "rwho" Group (BSD) (unofficial)         [JBP]
-   FF0X:0:0:0:0:0:0:202   SUN RPC PMAPPROC_CALLIT               [BXE1]
-
-   FF0X:0:0:0:0:0:2:0000
-    -FF0X:0:0:0:0:0:2:7FFD  Multimedia Conference Calls          [SC3]
-   FF0X:0:0:0:0:0:2:7FFE    SAPv1 Announcements                  [SC3]
-   FF0X:0:0:0:0:0:2:7FFF    SAPv0 Announcements (deprecated)     [SC3]
-   FF0X:0:0:0:0:0:2:8000
-    -FF0X:0:0:0:0:0:2:FFFF  SAP Dynamic Assignments              [SC3]
-
-5.0 References
-
-   [ADDARCH] Hinden, R., and S. Deering, "IP Version 6 Addressing
-             Architecture", RFC 2373, July 1998.
-
-   [AUTORFC] Thompson, S., and T. Narten, "IPv6 Stateless Address
-             Autoconfiguration", RFC 1971, August 1996.
-
-   [ETHER]   Crawford, M., "Transmission of IPv6 Packets over Ethernet
-             Networks", Work in Progress.
-
-   [RFC1045] Cheriton, D., "VMTP: Versatile Message Transaction Protocol
-             Specification", RFC 1045, February 1988.
-
-   [RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance
-             Vector Multicast Routing Protocol", RFC 1075, November
-             1988.
-
-   [RFC1112] Deering, S., "Host Extensions for IP Multicasting", STD 5,
-             RFC 1112, Stanford University, August 1989.
-
-   [RFC1119] Mills, D., "Network Time Protocol (Version 1),
-             Specification and Implementation", STD 12, RFC 1119, July
-             1988.
-
-   [RFC1190] Topolcic, C., Editor, "Experimental Internet Stream
-             Protocol, Version 2 (ST-II)", RFC 1190, October 1990.
-
-   [RFC2080] Malkin, G., and R. Minnear, "RIPng for IPv6", RFC 2080,
-             January 1997.
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2165] Veizades, J., Guttman, E., Perkins, C., and S. Kaplan
-             "Service Location Protocol", RFC 2165 June 1997.
-
-   [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
-
-
-
-Hinden & Deering             Informational                      [Page 4]
-
-RFC 2375           IPv6 Multicast Address Assignments          July 1998
-
-
-6. People
-
-   <arnoldm@microsoft.com>
-
-   [AXC] Andrew Cherenson <arc@SGI.COM>
-
-   [Braden] Bob Braden, <braden@isi.edu>, April 1996.
-
-   [Bob Brenner]
-
-   [Bressler] David J. Bressler, <bressler@tss.com>, April 1996.
-
-   <bloomer@birch.crd.ge.com>
-
-   [Bound] Jim Bound <bound@zk3.dec.com>
-
-   [BXE1] Brendan Eic <brendan@illyria.wpd.sgi.com>
-
-   [BXF] Bruce Factor <ahi!bigapple!bruce@uunet.UU.NET>
-
-   [BXS2] Bill Schilit <schilit@parc.xerox.com>
-
-   [Casner] Steve Casner, <casner@isi.edu>, January 1995.
-
-   [CXM3] Chuck McManis <cmcmanis@sun.com>
-
-   [Tim Clark]
-
-   [DLM1] David Mills <Mills@HUEY.UDEL.EDU>
-
-   [DRC3] Dave Cheriton <cheriton@PESCADERO.STANFORD.EDU>
-
-   [DXS3] Daniel Steinber <Daniel.Steinberg@Eng.Sun.COM>
-
-   [Farinacci] Dino Farinacci, <dino@cisco.com>
-
-   [GSM11] Gary S. Malkin <GMALKIN@XYLOGICS.COM>
-
-   [Harrington] Dan Harrington, <dan@lucent.com>, July 1996.
-
-   <hgxing@aol.com>
-
-   [IANA] IANA <iana@iana.org>
-
-   [Janssen] Rob Janssen, <rob@pe1chl.ampr.org>, January 1995.
-
-   [JBP] Jon Postel <postel@isi.edu>
-
-
-
-
-Hinden & Deering             Informational                      [Page 5]
-
-RFC 2375           IPv6 Multicast Address Assignments          July 1998
-
-
-   [JXM1] Jim Miner <miner@star.com>
-
-   [Kean] Brian Kean, <bkean@dca.com>, August 1995.
-
-   [KS14] <mystery contact>
-
-   [Lee] Choon Lee, <cwl@nsd.3com.com>, April 1996.
-
-   [Lewis] Mark Lewis, <Mark_Lewis@ccm.jf.intel.com>, October 1995.
-
-   [Malamud] Carl Malamud, <carl@radio.com>, January 1996.
-
-   [Andrew Maffei]
-
-   [Marohco] Jose Luis Marocho, <73374.313@compuserve.com>, July 1996.
-
-   [Moy] John Moy <jmoy@casc.com>
-
-   [MXF2] Martin Forssen <maf@dtek.chalmers.se>
-
-   [Perkins] Charlie Perkins, <cperkins@corp.sun.com>
-
-   [Guido van Rossum]
-
-   [SC3] Steve Casner <casner@isi.edu>
-
-   [Simpson] Bill Simpson <bill.simpson@um.cc.umich.edu> November 1994.
-
-   [Joel Snyder]
-
-   [SXA] Susie Armstrong <Armstrong.wbst128@XEROX.COM>
-
-   [SXD] Steve Deering <deering@PARC.XEROX.COM>
-
-   [tynan] Dermot Tynan, <dtynan@claddagh.ie>, August 1995.
-
-   [Toga] Jim Toga, <jtoga@ibeam.jf.intel.com>, May 1996.
-
-   [Uang] Yea Uang <uang@force.decnet.lockheed.com> November 1994.
-
-   [Veizades] John Veizades,  <veizades@tgv.com>, May 1995.
-
-   [Yackle] Dotty Yackle, <ditty_yackle@dantz.com>, February 1996.
-
-
-
-
-
-
-
-
-Hinden & Deering             Informational                      [Page 6]
-
-RFC 2375           IPv6 Multicast Address Assignments          July 1998
-
-
-7.0 Security Considerations
-
-   This document defines the initial assignment of IPv6 multicast
-   addresses.  As such it does not directly impact the security of the
-   Internet infrastructure or its applications.
-
-8.0 Authors' Addresses
-
-   Robert M. Hinden
-   Ipsilon Networks, Inc.
-   232 Java Drive
-   Sunnyvale, CA 94089
-   USA
-
-   Phone: +1 415 990 2004
-   EMail: hinden@ipsilon.com
-
-
-   Stephen E. Deering
-   Cisco Systems, Inc.
-   170 West Tasman Drive
-   San Jose, CA 95134-1706
-   USA
-
-   Phone: +1 408 527-8213
-   EMail: deering@cisco.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering             Informational                      [Page 7]
-
-RFC 2375           IPv6 Multicast Address Assignments          July 1998
-
-
-9.0  Full Copyright Statement
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering             Informational                      [Page 8]
-
diff --git a/contrib/bind9/doc/rfc/rfc2418.txt b/contrib/bind9/doc/rfc/rfc2418.txt
deleted file mode 100644
index 9bdb2c5..0000000
--- a/contrib/bind9/doc/rfc/rfc2418.txt
+++ /dev/null
@@ -1,1459 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         S. Bradner
-Request for Comments: 2418                                        Editor
-Obsoletes: 1603                                       Harvard University
-BCP: 25                                                   September 1998
-Category: Best Current Practice
-
-
-                           IETF Working Group
-                       Guidelines and Procedures
-
-Status of this Memo
-
-   This document specifies an Internet Best Current Practices for the
-   Internet Community, and requests discussion and suggestions for
-   improvements.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-Abstract
-
-   The Internet Engineering Task Force (IETF) has responsibility for
-   developing and reviewing specifications intended as Internet
-   Standards. IETF activities are organized into working groups (WGs).
-   This document describes the guidelines and procedures for formation
-   and operation of IETF working groups. It also describes the formal
-   relationship between IETF participants WG and the Internet
-   Engineering Steering Group (IESG) and the basic duties of IETF
-   participants, including WG Chairs, WG participants, and IETF Area
-   Directors.
-
-Table of Contents
-
-   Abstract .........................................................  1
-   1. Introduction ..................................................  2
-     1.1. IETF approach to standardization ..........................  4
-     1.2. Roles within a Working Group ..............................  4
-   2. Working group formation .......................................  4
-     2.1. Criteria for formation ....................................  4
-     2.2. Charter ...................................................  6
-     2.3. Charter review & approval .................................  8
-     2.4. Birds of a feather (BOF) ..................................  9
-   3. Working Group Operation ....................................... 10
-     3.1. Session planning .......................................... 11
-     3.2. Session venue ............................................. 11
-     3.3. Session management ........................................ 13
-     3.4. Contention and appeals .................................... 15
-
-
-
-Bradner                  Best Current Practice                  [Page 1]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   4. Working Group Termination ..................................... 15
-   5. Rechartering a Working Group .................................. 15
-   6. Staff Roles ................................................... 16
-     6.1. WG Chair .................................................. 16
-     6.2. WG Secretary .............................................. 18
-     6.3. Document Editor ........................................... 18
-     6.4. WG Facilitator ............................................ 18
-     6.5. Design teams .............................................. 19
-     6.6. Working Group Consultant .................................. 19
-     6.7. Area Director ............................................. 19
-   7. Working Group Documents ....................................... 19
-     7.1. Session documents ......................................... 19
-     7.2. Internet-Drafts (I-D) ..................................... 19
-     7.3. Request For Comments (RFC) ................................ 20
-     7.4. Working Group Last-Call ................................... 20
-     7.5. Submission of documents ................................... 21
-   8. Review of documents ........................................... 21
-   9. Security Considerations ....................................... 22
-   10. Acknowledgments .............................................. 23
-   11. References ................................................... 23
-   12. Editor's Address ............................................. 23
-   Appendix:  Sample Working Group Charter .......................... 24
-   Full Copyright Statement ......................................... 26
-
-1. Introduction
-
-   The Internet, a loosely-organized international collaboration of
-   autonomous, interconnected networks, supports host-to-host
-   communication through voluntary adherence to open protocols and
-   procedures defined by Internet Standards.  There are also many
-   isolated interconnected networks, which are not connected to the
-   global Internet but use the Internet Standards. Internet Standards
-   are developed in the Internet Engineering Task Force (IETF).  This
-   document defines guidelines and procedures for IETF working groups.
-   The Internet Standards Process of the IETF is defined in [1]. The
-   organizations involved in the IETF Standards Process are described in
-   [2] as are the roles of specific individuals.
-
-   The IETF is a large, open community of network designers, operators,
-   vendors, users, and researchers concerned with the Internet and the
-   technology used on it. The primary activities of the IETF are
-   performed by committees known as working groups. There are currently
-   more than 100 working groups. (See the IETF web page for an up-to-
-   date list of IETF Working Groups - http://www.ietf.org.) Working
-   groups tend to have a narrow focus and a lifetime bounded by the
-   completion of a specific set of tasks, although there are exceptions.
-
-
-
-
-
-Bradner                  Best Current Practice                  [Page 2]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   For management purposes, the IETF working groups are collected
-   together into areas, with each area having a separate focus.  For
-   example, the security area deals with the development of security-
-   related technology.  Each IETF area is managed by one or two Area
-   Directors (ADs).  There are currently 8 areas in the IETF but the
-   number changes from time to time.  (See the IETF web page for a list
-   of the current areas, the Area Directors for each area, and a list of
-   which working groups are assigned to each area.)
-
-   In many areas, the Area Directors have formed an advisory group or
-   directorate.  These comprise experienced members of the IETF and the
-   technical community represented by the area.  The specific name and
-   the details of the role for each group differ from area to area, but
-   the primary intent is that these groups assist the Area Director(s),
-   e.g., with the review of specifications produced in the area.
-
-   The IETF area directors are selected by a nominating committee, which
-   also selects an overall chair for the IETF.  The nominations process
-   is described in [3].
-
-   The area directors sitting as a body, along with the IETF Chair,
-   comprise the Internet Engineering Steering Group (IESG). The IETF
-   Executive Director is an ex-officio participant of the IESG, as are
-   the IAB Chair and a designated Internet Architecture Board (IAB)
-   liaison.  The IESG approves IETF Standards and approves the
-   publication of other IETF documents.  (See [1].)
-
-   A small IETF Secretariat provides staff and administrative support
-   for the operation of the IETF.
-
-   There is no formal membership in the IETF.  Participation is open to
-   all.  This participation may be by on-line contribution, attendance
-   at face-to-face sessions, or both.  Anyone from the Internet
-   community who has the time and interest is urged to participate in
-   IETF meetings and any of its on-line working group discussions.
-   Participation is by individual technical contributors, rather than by
-   formal representatives of organizations.
-
-   This document defines procedures and guidelines for the formation and
-   operation of working groups in the IETF. It defines the relations of
-   working groups to other bodies within the IETF. The duties of working
-   group Chairs and Area Directors with respect to the operation of the
-   working group are also defined.  When used in this document the key
-   words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
-   "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be
-   interpreted as described in RFC 2119 [6].  RFC 2119 defines the use
-   of these key words to help make the intent of standards track
-   documents as clear as possible.  The same key words are used in this
-
-
-
-Bradner                  Best Current Practice                  [Page 3]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   document to help smooth WG operation and reduce the chance for
-   confusion about the processes.
-
-1.1. IETF approach to standardization
-
-   Familiarity with The Internet Standards Process [1] is essential for
-   a complete understanding of the philosophy, procedures and guidelines
-   described in this document.
-
-1.2. Roles within a Working Group
-
-   The document, "Organizations Involved in the IETF Standards Process"
-   [2] describes the roles of a number of individuals within a working
-   group, including the working group chair and the document editor.
-   These descriptions are expanded later in this document.
-
-2. Working group formation
-
-   IETF working groups (WGs) are the primary mechanism for development
-   of IETF specifications and guidelines, many of which are intended to
-   be standards or recommendations. A working group may be established
-   at the initiative of an Area Director or it may be initiated by an
-   individual or group of individuals. Anyone interested in creating an
-   IETF working group MUST obtain the advice and consent of the IETF
-   Area Director(s) in whose area the working group would fall and MUST
-   proceed through the formal steps detailed in this section.
-
-   Working groups are typically created to address a specific problem or
-   to produce one or more specific deliverables (a guideline, standards
-   specification, etc.).  Working groups are generally expected to be
-   short-lived in nature.  Upon completion of its goals and achievement
-   of its objectives, the working group is terminated. A working group
-   may also be terminated for other reasons (see section 4).
-   Alternatively, with the concurrence of the IESG, Area Director, the
-   WG Chair, and the WG participants, the objectives or assignment of
-   the working group may be extended by modifying the working group's
-   charter through a rechartering process (see section 5).
-
-2.1. Criteria for formation
-
-   When determining whether it is appropriate to create a working group,
-   the Area Director(s) and the IESG will consider several issues:
-
-    - Are the issues that the working group plans to address clear and
-      relevant to the Internet community?
-
-    - Are the goals specific and reasonably achievable, and achievable
-      within a reasonable time frame?
-
-
-
-Bradner                  Best Current Practice                  [Page 4]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-    - What are the risks and urgency of the work, to determine the level
-      of effort required?
-
-    - Do the working group's activities overlap with those of another
-      working group?  If so, it may still be appropriate to create the
-      working group, but this question must be considered carefully by
-      the Area Directors as subdividing efforts often dilutes the
-      available technical expertise.
-
-    - Is there sufficient interest within the IETF in the working
-      group's topic with enough people willing to expend the effort to
-      produce the desired result (e.g., a protocol specification)?
-      Working groups require considerable effort, including management
-      of the working group process, editing of working group documents,
-      and contributing to the document text.  IETF experience suggests
-      that these roles typically cannot all be handled by one person; a
-      minimum of four or five active participants in the management
-      positions are typically required in addition to a minimum of one
-      or two dozen people that will attend the working group meetings
-      and contribute on the mailing list.  NOTE: The interest must be
-      broad enough that a working group would not be seen as merely the
-      activity of a single vendor.
-
-    - Is there enough expertise within the IETF in the working group's
-      topic, and are those people interested in contributing in the
-      working group?
-
-    - Does a base of interested consumers (end-users) appear to exist
-      for the planned work?  Consumer interest can be measured by
-      participation of end-users within the IETF process, as well as by
-      less direct means.
-
-    - Does the IETF have a reasonable role to play in the determination
-      of the technology?  There are many Internet-related technologies
-      that may be interesting to IETF members but in some cases the IETF
-      may not be in a position to effect the course of the technology in
-      the "real world".  This can happen, for example, if the technology
-      is being developed by another standards body or an industry
-      consortium.
-
-    - Are all known intellectual property rights relevant to the
-      proposed working group's efforts issues understood?
-
-    - Is the proposed work plan an open IETF effort or is it an attempt
-      to "bless" non-IETF technology where the effect of input from IETF
-      participants may be limited?
-
-
-
-
-
-Bradner                  Best Current Practice                  [Page 5]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-    - Is there a good understanding of any existing work that is
-      relevant to the topics that the proposed working group is to
-      pursue?  This includes work within the IETF and elsewhere.
-
-    - Do the working group's goals overlap with known work in another
-      standards body, and if so is adequate liaison in place?
-
-   Considering the above criteria, the Area Director(s), using his or
-   her best judgement, will decide whether to pursue the formation of
-   the group through the chartering process.
-
-2.2. Charter
-
-   The formation of a working group requires a charter which is
-   primarily negotiated between a prospective working group Chair and
-   the relevant Area Director(s), although final approval is made by the
-   IESG with advice from the Internet Architecture Board (IAB).  A
-   charter is a contract between a working group and the IETF to perform
-   a set of tasks.  A charter:
-
-   1. Lists relevant administrative information for the working group;
-   2. Specifies the direction or objectives of the working group and
-      describes the approach that will be taken to achieve the goals;
-      and
-   3. Enumerates a set of milestones together with time frames for their
-      completion.
-
-   When the prospective Chair(s), the Area Director and the IETF
-   Secretariat are satisfied with the charter form and content, it
-   becomes the basis for forming a working group. Note that an Area
-   Director MAY require holding an exploratory Birds of a Feather (BOF)
-   meeting, as described below, to gage the level of support for a
-   working group before submitting the charter to the IESG and IAB for
-   approval.
-
-   Charters may be renegotiated periodically to reflect the current
-   status, organization or goals of the working group (see section 5).
-   Hence, a charter is a contract between the IETF and the working group
-   which is committing to meet explicit milestones and delivering
-   specific "products".
-
-   Specifically, each charter consists of the following sections:
-
-   Working group name
-      A working group name should be reasonably descriptive or
-      identifiable. Additionally, the group shall define an acronym
-      (maximum 8 printable ASCII characters) to reference the group in
-      the IETF directories, mailing lists, and general documents.
-
-
-
-Bradner                  Best Current Practice                  [Page 6]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   Chair(s)
-      The working group may have one or more Chairs to perform the
-      administrative functions of the group. The email address(es) of
-      the Chair(s) shall be included.  Generally, a working group is
-      limited to two chairs.
-
-   Area and Area Director(s)
-      The name of the IETF area with which the working group is
-      affiliated and the name and electronic mail address of the
-      associated Area Director(s).
-
-   Responsible Area Director
-      The Area Director who acts as the primary IESG contact for the
-      working group.
-
-   Mailing list
-      An IETF working group MUST have a general Internet mailing list.
-      Most of the work of an IETF working group will be conducted on the
-      mailing list. The working group charter MUST include:
-
-      1. The address to which a participant sends a subscription request
-         and the procedures to follow when subscribing,
-
-      2. The address to which a participant sends submissions and
-         special procedures, if any, and
-
-      3. The location of the mailing list archive. A message archive
-         MUST be maintained in a public place which can be accessed via
-         FTP or via the web.
-
-         As a service to the community, the IETF Secretariat operates a
-         mailing list archive for working group mailing lists. In order
-         to take advantage of this service, working group mailing lists
-         MUST include the address "wg_acronym-archive@lists.ietf.org"
-         (where "wg_acronym" is the working group acronym) in the
-         mailing list in order that a copy of all mailing list messages
-         be recorded in the Secretariat's archive.  Those archives are
-         located at ftp://ftp.ietf.org/ietf-mail-archive.  For
-         robustness, WGs SHOULD maintain an additional archive separate
-         from that maintained by the Secretariat.
-
-   Description of working group
-      The focus and intent of the group shall be set forth briefly. By
-      reading this section alone, an individual should be able to decide
-      whether this group is relevant to their own work. The first
-      paragraph must give a brief summary of the problem area, basis,
-      goal(s) and approach(es) planned for the working group.  This
-      paragraph can be used as an overview of the working group's
-
-
-
-Bradner                  Best Current Practice                  [Page 7]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-      effort.
-
-      To facilitate evaluation of the intended work and to provide on-
-      going guidance to the working group, the charter must describe the
-      problem being solved and should discuss objectives and expected
-      impact with respect to:
-
-         - Architecture
-         - Operations
-         - Security
-         - Network management
-         - Scaling
-         - Transition (where applicable)
-
-   Goals and milestones
-      The working group charter MUST establish a timetable for specific
-      work items.  While this may be renegotiated over time, the list of
-      milestones and dates facilitates the Area Director's tracking of
-      working group progress and status, and it is indispensable to
-      potential participants identifying the critical moments for input.
-      Milestones shall consist of deliverables that can be qualified as
-      showing specific achievement; e.g., "Internet-Draft finished" is
-      fine, but "discuss via email" is not. It is helpful to specify
-      milestones for every 3-6 months, so that progress can be gauged
-      easily.  This milestone list is expected to be updated
-      periodically (see section 5).
-
-      An example of a WG charter is included as Appendix A.
-
-2.3. Charter review & approval
-
-   Proposed working groups often comprise technically competent
-   participants who are not familiar with the history of Internet
-   architecture or IETF processes.  This can, unfortunately, lead to
-   good working group consensus about a bad design.  To facilitate
-   working group efforts, an Area Director may assign a Consultant from
-   among the ranks of senior IETF participants.  (Consultants are
-   described in section 6.)  At the discretion of the Area Director,
-   approval of a new WG may be withheld in the absence of sufficient
-   consultant resources.
-
-   Once the Area Director (and the Area Directorate, as the Area
-   Director deems appropriate) has approved the working group charter,
-   the charter is submitted for review by the IAB and approval by the
-   IESG.  After a review period of at least a week the proposed charter
-   is posted to the IETF-announce mailing list as a public notice that
-   the formation of the working group is being considered.  At the same
-   time the proposed charter is also posted to the "new-work" mailing
-
-
-
-Bradner                  Best Current Practice                  [Page 8]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   list.  This mailing list has been created to let qualified
-   representatives from other standards organizations know about pending
-   IETF working groups.  After another review period lasting at least a
-   week the IESG MAY approve the charter as-is, it MAY request that
-   changes be made in the charter, or MAY decline to approve chartering
-   of the working group
-
-   If the IESG approves the formation of the working group it remands
-   the approved charter to the IETF Secretariat who records and enters
-   the information into the IETF tracking database.  The working group
-   is announced to the IETF-announce a by the IETF Secretariat.
-
-2.4. Birds of a Feather (BOF)
-
-   Often it is not clear whether an issue merits the formation of a
-   working group.  To facilitate exploration of the issues the IETF
-   offers the possibility of a Birds of a Feather (BOF) session, as well
-   as the early formation of an email list for preliminary discussion.
-   In addition, a BOF may serve as a forum for a single presentation or
-   discussion, without any intent to form a working group.
-
-   A BOF is a session at an IETF meeting which permits "market research"
-   and technical "brainstorming".  Any individual may request permission
-   to hold a BOF on a subject. The request MUST be filed with a relevant
-   Area Director who must approve a BOF before it can be scheduled. The
-   person who requests the BOF may be asked to serve as Chair of the
-   BOF.
-
-   The Chair of the BOF is also responsible for providing a report on
-   the outcome of the BOF.  If the Area Director approves, the BOF is
-   then scheduled by submitting a request to agenda@ietf.org with copies
-   to the Area Director(s). A BOF description and agenda are required
-   before a BOF can be scheduled.
-
-   Available time for BOFs is limited, and BOFs are held at the
-   discretion of the ADs for an area.  The AD(s) may require additional
-   assurances before authorizing a BOF.  For example,
-
-    - The Area Director MAY require the establishment of an open email
-      list prior to authorizing a BOF.  This permits initial exchanges
-      and sharing of framework, vocabulary and approaches, in order to
-      make the time spent in the BOF more productive.
-
-    - The Area Director MAY require that a BOF be held, prior to
-      establishing a working group (see section 2.2).
-
-    - The Area Director MAY require that there be a draft of the WG
-      charter prior to holding a BOF.
-
-
-
-Bradner                  Best Current Practice                  [Page 9]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-    - The Area Director MAY require that a BOF not be held until an
-      Internet-Draft describing the proposed technology has been
-      published so it can be used as a basis for discussion in the BOF.
-
-   In general, a BOF on a particular topic is held only once (ONE slot
-   at one IETF Plenary meeting). Under unusual circumstances Area
-   Directors may, at their discretion, allow a BOF to meet for a second
-   time. BOFs are not permitted to meet three times.  Note that all
-   other things being equal, WGs will be given priority for meeting
-   space over BOFs.  Also, occasionally BOFs may be held for other
-   purposes than to discuss formation of a working group.
-
-   Usually the outcome of a BOF will be one of the following:
-
-    - There was enough interest and focus in the subject to warrant the
-      formation of a WG;
-
-    - While there was a reasonable level of interest expressed in the
-      BOF some other criteria for working group formation was not met
-      (see section 2.1).
-
-    - The discussion came to a fruitful conclusion, with results to be
-      written down and published, however there is no need to establish
-      a WG; or
-
-    - There was not enough interest in the subject to warrant the
-      formation of a WG.
-
-3.  Working Group Operation
-
-   The IETF has basic requirements for open and fair participation and
-   for thorough consideration of technical alternatives.  Within those
-   constraints, working groups are autonomous and each determines most
-   of the details of its own operation with respect to session
-   participation, reaching closure, etc. The core rule for operation is
-   that acceptance or agreement is achieved via working group "rough
-   consensus".  WG participants should specifically note the
-   requirements for disclosure of conflicts of interest in [2].
-
-   A number of procedural questions and issues will arise over time, and
-   it is the function of the Working Group Chair(s) to manage the group
-   process, keeping in mind that the overall purpose of the group is to
-   make progress towards reaching rough consensus in realizing the
-   working group's goals and objectives.
-
-   There are few hard and fast rules on organizing or conducting working
-   group activities, but a set of guidelines and practices has evolved
-   over time that have proven successful. These are listed here, with
-
-
-
-Bradner                  Best Current Practice                 [Page 10]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   actual choices typically determined by the working group participants
-   and the Chair(s).
-
-3.1. Session planning
-
-   For coordinated, structured WG interactions, the Chair(s) MUST
-   publish a draft agenda well in advance of the actual session. The
-   agenda should contain at least:
-
-   - The items for discussion;
-   - The estimated time necessary per item; and
-   - A clear indication of what documents the participants will need to
-     read before the session in order to be well prepared.
-
-   Publication of the working group agenda shall include sending a copy
-   of the agenda to the working group mailing list and to
-   agenda@ietf.org.
-
-   All working group actions shall be taken in a public forum, and wide
-   participation is encouraged. A working group will conduct much of its
-   business via electronic mail distribution lists but may meet
-   periodically to discuss and review task status and progress, to
-   resolve specific issues and to direct future activities.  IETF
-   Plenary meetings are the primary venue for these face-to-face working
-   group sessions, and it is common (though not required) that active
-   "interim" face-to-face meetings, telephone conferences, or video
-   conferences may also be held.  Interim meetings are subject to the
-   same rules for advance notification, reporting, open participation,
-   and process, which apply to other working group meetings.
-
-   All working group sessions (including those held outside of the IETF
-   meetings) shall be reported by making minutes available.  These
-   minutes should include the agenda for the session, an account of the
-   discussion including any decisions made, and a list of attendees. The
-   Working Group Chair is responsible for insuring that session minutes
-   are written and distributed, though the actual task may be performed
-   by someone designated by the Working Group Chair. The minutes shall
-   be submitted in printable ASCII text for publication in the IETF
-   Proceedings, and for posting in the IETF Directories and are to be
-   sent to: minutes@ietf.org
-
-3.2. Session venue
-
-   Each working group will determine the balance of email and face-to-
-   face sessions that is appropriate for achieving its milestones.
-   Electronic mail permits the widest participation; face-to-face
-   meetings often permit better focus and therefore can be more
-   efficient for reaching a consensus among a core of the working group
-
-
-
-Bradner                  Best Current Practice                 [Page 11]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   participants.  In determining the balance, the WG must ensure that
-   its process does not serve to exclude contribution by email-only
-   participants.  Decisions reached during a face-to-face meeting about
-   topics or issues which have not been discussed on the mailing list,
-   or are significantly different from previously arrived mailing list
-   consensus MUST be reviewed on the mailing list.
-
-   IETF Meetings
-   If a WG needs a session at an IETF meeting, the Chair must apply for
-   time-slots as soon as the first announcement of that IETF meeting is
-   made by the IETF Secretariat to the WG-chairs list.  Session time is
-   a scarce resource at IETF meetings, so placing requests early will
-   facilitate schedule coordination for WGs requiring the same set of
-   experts.
-
-   The application for a WG session at an IETF meeting MUST be made to
-   the IETF Secretariat at the address agenda@ietf.org.  Some Area
-   Directors may want to coordinate WG sessions in their area and
-   request that time slots be coordinated through them.  If this is the
-   case it will be noted in the IETF meeting announcement. A WG
-   scheduling request MUST contain:
-
-   - The working group name and full title;
-   - The amount of time requested;
-   - The rough outline of the WG agenda that is expected to be covered;
-   - The estimated number of people that will attend the WG session;
-   - Related WGs that should not be scheduled for the same time slot(s);
-     and
-   - Optionally a request can be added for the WG session to be
-     transmitted over the Internet in audio and video.
-
-   NOTE: While open discussion and contribution is essential to working
-   group success, the Chair is responsible for ensuring forward
-   progress.  When acceptable to the WG, the Chair may call for
-   restricted participation (but not restricted attendance!) at IETF
-   working group sessions for the purpose of achieving progress. The
-   Working Group Chair then has the authority to refuse to grant the
-   floor to any individual who is unprepared or otherwise covering
-   inappropriate material, or who, in the opinion of the Chair is
-   disrupting the WG process.  The Chair should consult with the Area
-   Director(s) if the individual persists in disruptive behavior.
-
-   On-line
-   It can be quite useful to conduct email exchanges in the same manner
-   as a face-to-face session, with published schedule and agenda, as
-   well as on-going summarization and consensus polling.
-
-
-
-
-
-Bradner                  Best Current Practice                 [Page 12]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   Many working group participants hold that mailing list discussion is
-   the best place to consider and resolve issues and make decisions. The
-   choice of operational style is made by the working group itself.  It
-   is important to note, however, that Internet email discussion is
-   possible for a much wider base of interested persons than is
-   attendance at IETF meetings, due to the time and expense required to
-   attend.
-
-   As with face-to-face sessions occasionally one or more individuals
-   may engage in behavior on a mailing list which disrupts the WG's
-   progress.  In these cases the Chair should attempt to discourage the
-   behavior by communication directly with the offending individual
-   rather than on the open mailing list.  If the behavior persists then
-   the Chair must involve the Area Director in the issue.  As a last
-   resort and after explicit warnings, the Area Director, with the
-   approval of the IESG, may request that the mailing list maintainer
-   block the ability of the offending individual to post to the mailing
-   list. (If the mailing list software permits this type of operation.)
-   Even if this is done, the individual must not be prevented from
-   receiving messages posted to the list.  Other methods of mailing list
-   control may be considered but must be approved by the AD(s) and the
-   IESG.
-
-3.3. Session management
-
-   Working groups make decisions through a "rough consensus" process.
-   IETF consensus does not require that all participants agree although
-   this is, of course, preferred.  In general, the dominant view of the
-   working group shall prevail.  (However, it must be noted that
-   "dominance" is not to be determined on the basis of volume or
-   persistence, but rather a more general sense of agreement.) Consensus
-   can be determined by a show of hands, humming, or any other means on
-   which the WG agrees (by rough consensus, of course).  Note that 51%
-   of the working group does not qualify as "rough consensus" and 99% is
-   better than rough.  It is up to the Chair to determine if rough
-   consensus has been reached.
-
-   It can be particularly challenging to gauge the level of consensus on
-   a mailing list.  There are two different cases where a working group
-   may be trying to understand the level of consensus via a mailing list
-   discussion. But in both cases the volume of messages on a topic is
-   not, by itself, a good indicator of consensus since one or two
-   individuals may be generating much of the traffic.
-
-   In the case where a consensus which has been reached during a face-
-   to-face meeting is being verified on a mailing list the people who
-   were in the meeting and expressed agreement must be taken into
-   account.  If there were 100 people in a meeting and only a few people
-
-
-
-Bradner                  Best Current Practice                 [Page 13]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   on the mailing list disagree with the consensus of the meeting then
-   the consensus should be seen as being verified.  Note that enough
-   time should be given to the verification process for the mailing list
-   readers to understand and consider any objections that may be raised
-   on the list.  The normal two week last-call period should be
-   sufficient for this.
-
-   The other case is where the discussion has been held entirely over
-   the mailing list.  The determination of the level of consensus may be
-   harder to do in this case since most people subscribed to mailing
-   lists do not actively participate in discussions on the list. It is
-   left to the discretion of the working group chair how to evaluate the
-   level of consensus.  The most common method used is for the working
-   group chair to state what he or she believes to be the consensus view
-   and. at the same time, requests comments from the list about the
-   stated conclusion.
-
-   The challenge to managing working group sessions is to balance the
-   need for open and fair consideration of the issues against the need
-   to make forward progress.  The working group, as a whole, has the
-   final responsibility for striking this balance.  The Chair has the
-   responsibility for overseeing the process but may delegate direct
-   process management to a formally-designated Facilitator.
-
-   It is occasionally appropriate to revisit a topic, to re-evaluate
-   alternatives or to improve the group's understanding of a relevant
-   decision.  However, unnecessary repeated discussions on issues can be
-   avoided if the Chair makes sure that the main arguments in the
-   discussion (and the outcome) are summarized and archived after a
-   discussion has come to conclusion. It is also good practice to note
-   important decisions/consensus reached by email in the minutes of the
-   next 'live' session, and to summarize briefly the decision-making
-   history in the final documents the WG produces.
-
-   To facilitate making forward progress, a Working Group Chair may wish
-   to decide to reject or defer the input from a member, based upon the
-   following criteria:
-
-   Old
-   The input pertains to a topic that already has been resolved and is
-   redundant with information previously available;
-
-   Minor
-   The input is new and pertains to a topic that has already been
-   resolved, but it is felt to be of minor import to the existing
-   decision;
-
-
-
-
-
-Bradner                  Best Current Practice                 [Page 14]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   Timing
-   The input pertains to a topic that the working group has not yet
-   opened for discussion; or
-
-   Scope
-   The input is outside of the scope of the working group charter.
-
-3.4. Contention and appeals
-
-   Disputes are possible at various stages during the IETF process. As
-   much as possible the process is designed so that compromises can be
-   made, and genuine consensus achieved; however, there are times when
-   even the most reasonable and knowledgeable people are unable to
-   agree.  To achieve the goals of openness and fairness, such conflicts
-   must be resolved by a process of open review and discussion.
-
-   Formal procedures for requesting a review of WG, Chair, Area Director
-   or IESG actions and conducting appeals are documented in The Internet
-   Standards Process [1].
-
-4. Working Group Termination
-
-   Working groups are typically chartered to accomplish a specific task
-   or tasks.  After the tasks are complete, the group will be disbanded.
-   However, if a WG produces a Proposed or Draft Standard, the WG will
-   frequently become dormant rather than disband (i.e., the WG will no
-   longer conduct formal activities, but the mailing list will remain
-   available to review the work as it moves to Draft Standard and
-   Standard status.)
-
-   If, at some point, it becomes evident that a working group is unable
-   to complete the work outlined in the charter, or if the assumptions
-   which that work was based have been modified in discussion or by
-   experience, the Area Director, in consultation with the working group
-   can either:
-
-   1. Recharter to refocus its tasks,
-   2. Choose new Chair(s), or
-   3. Disband.
-
-   If the working group disagrees with the Area Director's choice, it
-   may appeal to the IESG (see section 3.4).
-
-5. Rechartering a Working Group
-
-   Updated milestones are renegotiated with the Area Director and the
-   IESG, as needed, and then are submitted to the IESG Secretariat:
-   iesg-secretary@ietf.org.
-
-
-
-Bradner                  Best Current Practice                 [Page 15]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   Rechartering (other than revising milestones) a working group follows
-   the same procedures that the initial chartering does (see section 2).
-   The revised charter must be submitted to the IESG and IAB for
-   approval.  As with the initial chartering, the IESG may approve new
-   charter as-is, it may request that changes be made in the new charter
-   (including having the Working Group continue to use the old charter),
-   or it may decline to approve the rechartered working group.  In the
-   latter case, the working group is disbanded.
-
-6. Staff Roles
-
-   Working groups require considerable care and feeding.  In addition to
-   general participation, successful working groups benefit from the
-   efforts of participants filling specific functional roles.  The Area
-   Director must agree to the specific people performing the WG Chair,
-   and Working Group Consultant roles, and they serve at the discretion
-   of the Area Director.
-
-6.1. WG Chair
-
-   The Working Group Chair is concerned with making forward progress
-   through a fair and open process, and has wide discretion in the
-   conduct of WG business.  The Chair must ensure that a number of tasks
-   are performed, either directly or by others assigned to the tasks.
-
-   The Chair has the responsibility and the authority to make decisions,
-   on behalf of the working group, regarding all matters of working
-   group process and staffing, in conformance with the rules of the
-   IETF.  The AD has the authority and the responsibility to assist in
-   making those decisions at the request of the Chair or when
-   circumstances warrant such an intervention.
-
-   The Chair's responsibility encompasses at least the following:
-
-   Ensure WG process and content management
-
-      The Chair has ultimate responsibility for ensuring that a working
-      group achieves forward progress and meets its milestones.  The
-      Chair is also responsible to ensure that the working group
-      operates in an open and fair manner.  For some working groups,
-      this can be accomplished by having the Chair perform all
-      management-related activities.  In other working groups --
-      particularly those with large or divisive participation -- it is
-      helpful to allocate process and/or secretarial functions to other
-      participants.  Process management pertains strictly to the style
-      of working group interaction and not to its content. It ensures
-      fairness and detects redundancy.  The secretarial function
-      encompasses document editing.  It is quite common for a working
-
-
-
-Bradner                  Best Current Practice                 [Page 16]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-      group to assign the task of specification Editor to one or two
-      participants.  Sometimes, they also are part of the design team,
-      described below.
-
-   Moderate the WG email list
-
-      The Chair should attempt to ensure that the discussions on this
-      list are relevant and that they converge to consensus agreements.
-      The Chair should make sure that discussions on the list are
-      summarized and that the outcome is well documented (to avoid
-      repetition).  The Chair also may choose to schedule organized on-
-      line "sessions" with agenda and deliverables.  These can be
-      structured as true meetings, conducted over the course of several
-      days (to allow participation across the Internet).
-
-      Organize, prepare and chair face-to-face and on-line formal
-      sessions.
-
-   Plan WG Sessions
-
-      The Chair must plan and announce all WG sessions well in advance
-      (see section 3.1).
-
-   Communicate results of sessions
-
-      The Chair and/or Secretary must ensure that minutes of a session
-      are taken and that an attendance list is circulated (see section
-      3.1).
-
-      Immediately after a session, the WG Chair MUST provide the Area
-      Director with a very short report (approximately one paragraph,
-      via email) on the session.
-
-   Distribute the workload
-
-      Of course, each WG will have participants who may not be able (or
-      want) to do any work at all. Most of the time the bulk of the work
-      is done by a few dedicated participants. It is the task of the
-      Chair to motivate enough experts to allow for a fair distribution
-      of the workload.
-
-   Document development
-
-      Working groups produce documents and documents need authors. The
-      Chair must make sure that authors of WG documents incorporate
-      changes as agreed to by the WG (see section 6.3).
-
-
-
-
-
-Bradner                  Best Current Practice                 [Page 17]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   Document publication
-
-      The Chair and/or Document Editor will work with the RFC Editor to
-      ensure document conformance with RFC publication requirements [5]
-      and to coordinate any editorial changes suggested by the RFC
-      Editor.  A particular concern is that all participants are working
-      from the same version of a document at the same time.
-
-   Document implementations
-
-      Under the procedures described in [1], the Chair is responsible
-      for documenting the specific implementations which qualify the
-      specification for Draft or Internet Standard status along with
-      documentation about testing of the interoperation of these
-      implementations.
-
-6.2. WG Secretary
-
-   Taking minutes and editing working group documents often is performed
-   by a specifically-designated participant or set of participants.  In
-   this role, the Secretary's job is to record WG decisions, rather than
-   to perform basic specification.
-
-6.3. Document Editor
-
-   Most IETF working groups focus their efforts on a document, or set of
-   documents, that capture the results of the group's work.  A working
-   group generally designates a person or persons to serve as the Editor
-   for a particular document.  The Document Editor is responsible for
-   ensuring that the contents of the document accurately reflect the
-   decisions that have been made by the working group.
-
-   As a general practice, the Working Group Chair and Document Editor
-   positions are filled by different individuals to help ensure that the
-   resulting documents accurately reflect the consensus of the working
-   group and that all processes are followed.
-
-6.4. WG Facilitator
-
-   When meetings tend to become distracted or divisive, it often is
-   helpful to assign the task of "process management" to one
-   participant.  Their job is to oversee the nature, rather than the
-   content, of participant interactions.  That is, they attend to the
-   style of the discussion and to the schedule of the agenda, rather
-   than making direct technical contributions themselves.
-
-
-
-
-
-
-Bradner                  Best Current Practice                 [Page 18]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-6.5. Design teams
-
-   It is often useful, and perhaps inevitable, for a sub-group of a
-   working group to develop a proposal to solve a particular problem.
-   Such a sub-group is called a design team.  In order for a design team
-   to remain small and agile, it is acceptable to have closed membership
-   and private meetings.  Design teams may range from an informal chat
-   between people in a hallway to a formal set of expert volunteers that
-   the WG chair or AD appoints to attack a controversial problem.  The
-   output of a design team is always subject to approval, rejection or
-   modification by the WG as a whole.
-
-6.6. Working Group Consultant
-
-   At the discretion of the Area Director, a Consultant may be assigned
-   to a working group.  Consultants have specific technical background
-   appropriate to the WG and experience in Internet architecture and
-   IETF process.
-
-6.7. Area Director
-
-   Area Directors are responsible for ensuring that working groups in
-   their area produce coherent, coordinated, architecturally consistent
-   and timely output as a contribution to the overall results of the
-   IETF.
-
-7.  Working Group Documents
-
-7.1. Session documents
-
-   All relevant documents to be discussed at a session should be
-   published and available as Internet-Drafts at least two weeks before
-   a session starts.  Any document which does not meet this publication
-   deadline can only be discussed in a working group session with the
-   specific approval of the working group chair(s).  Since it is
-   important that working group members have adequate time to review all
-   documents, granting such an exception should only be done under
-   unusual conditions.  The final session agenda should be posted to the
-   working group mailing list at least two weeks before the session and
-   sent at that time to agenda@ietf.org for publication on the IETF web
-   site.
-
-7.2. Internet-Drafts (I-D)
-
-   The Internet-Drafts directory is provided to working groups as a
-   resource for posting and disseminating in-process copies of working
-   group documents. This repository is replicated at various locations
-   around the Internet. It is encouraged that draft documents be posted
-
-
-
-Bradner                  Best Current Practice                 [Page 19]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   as soon as they become reasonably stable.
-
-   It is stressed here that Internet-Drafts are working documents and
-   have no official standards status whatsoever. They may, eventually,
-   turn into a standards-track document or they may sink from sight.
-   Internet-Drafts are submitted to: internet-drafts@ietf.org
-
-   The format of an Internet-Draft must be the same as for an RFC [2].
-   Further, an I-D must contain:
-
-   - Beginning, standard, boilerplate text which is provided by the
-     Secretariat on their web site and in the ftp directory;
-   - The I-D filename; and
-   - The expiration date for the I-D.
-
-   Complete specification of requirements for an Internet-Draft are
-   found in the file "1id-guidelines.txt" in the Internet-Drafts
-   directory at an Internet Repository site.  The organization of the
-   Internet-Drafts directory is found in the file "1id-organization" in
-   the Internet-Drafts directory at an Internet Repository site.  This
-   file also contains the rules for naming Internet-Drafts.  (See [1]
-   for more information about Internet-Drafts.)
-
-7.3. Request For Comments (RFC)
-
-   The work of an IETF working group often results in publication of one
-   or more documents, as part of the Request For Comments (RFCs) [1]
-   series. This series is the archival publication record for the
-   Internet community. A document can be written by an individual in a
-   working group, by a group as a whole with a designated Editor, or by
-   others not involved with the IETF.
-
-   NOTE: The RFC series is a publication mechanism only and publication
-   does not determine the IETF status of a document.  Status is
-   determined through separate, explicit status labels assigned by the
-   IESG on behalf of the IETF.  In other words, the reader is reminded
-   that all Internet Standards are published as RFCs, but NOT all RFCs
-   specify standards [4].
-
-7.4. Working Group Last-Call
-
-   When a WG decides that a document is ready for publication it may be
-   submitted to the IESG for consideration. In most cases the
-   determination that a WG feels that a document is ready for
-   publication is done by the WG Chair issuing a working group Last-
-   Call.  The decision to issue a working group Last-Call is at the
-   discretion of the WG Chair working with the Area Director.  A working
-   group Last-Call serves the same purpose within a working group that
-
-
-
-Bradner                  Best Current Practice                 [Page 20]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   an IESG Last-Call does in the broader IETF community (see [1]).
-
-7.5. Submission of documents
-
-   Once that a WG has determined at least rough consensus exists within
-   the WG for the advancement of a document the following must be done:
-
-   - The version of the relevant document exactly as agreed to by the WG
-     MUST be in the Internet-Drafts directory.
-
-   - The relevant document MUST be formatted according to section 7.3.
-
-   - The WG Chair MUST send email to the relevant Area Director.  A copy
-     of the request MUST be also sent to the IESG Secretariat.  The mail
-     MUST contain the reference to the document's ID filename, and the
-     action requested.  The copy of the message to the IESG Secretariat
-     is to ensure that the request gets recorded by the Secretariat so
-     that they can monitor the progress of the document through the
-     process.
-
-   Unless returned by the IESG to the WG for further development,
-   progressing of the document is then the responsibility of the IESG.
-   After IESG approval, responsibility for final disposition is the
-   joint responsibility of the RFC Editor, the WG Chair and the Document
-   Editor.
-
-8. Review of documents
-
-   The IESG reviews all documents submitted for publication as RFCs.
-   Usually minimal IESG review is necessary in the case of a submission
-   from a WG intended as an Informational or Experimental RFC. More
-   extensive review is undertaken in the case of standards-track
-   documents.
-
-   Prior to the IESG beginning their deliberations on standards-track
-   documents, IETF Secretariat will issue a "Last-Call" to the IETF
-   mailing list (see [1]). This Last Call will announce the intention of
-   the IESG to consider the document, and it will solicit final comments
-   from the IETF within a period of two weeks.  It is important to note
-   that a Last-Call is intended as a brief, final check with the
-   Internet community, to make sure that no important concerns have been
-   missed or misunderstood. The Last-Call should not serve as a more
-   general, in-depth review.
-
-   The IESG review takes into account responses to the Last-Call and
-   will lead to one of these possible conclusions:
-
-
-
-
-
-Bradner                  Best Current Practice                 [Page 21]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   1. The document is accepted as is for the status requested.
-      This fact will be announced by the IETF Secretariat to the IETF
-      mailing list and to the RFC Editor.
-
-   2. The document is accepted as-is but not for the status requested.
-      This fact will be announced by the IETF Secretariat to the IETF
-      mailing list and to the RFC Editor (see [1] for more details).
-
-   3. Changes regarding content are suggested to the author(s)/WG.
-      Suggestions from the IESG must be clear and direct, so as to
-      facilitate working group and author correction of the
-      specification.  If the author(s)/WG can explain to the
-      satisfaction of the IESG why the changes are not necessary, the
-      document will be accepted for publication as under point 1, above.
-      If the changes are made the revised document may be resubmitted
-      for IESG review.
-
-   4. Changes are suggested by the IESG and a change in status is
-      recommended.
-      The process described above for 3 and 2 are followed in that
-      order.
-
-   5. The document is rejected.
-      Any document rejection will be accompanied by specific and
-      thorough arguments from the IESG. Although the IETF and working
-      group process is structured such that this alternative is not
-      likely to arise for documents coming from a working group, the
-      IESG has the right and responsibility to reject documents that the
-      IESG feels are fatally flawed in some way.
-
-      If any individual or group of individuals feels that the review
-      treatment has been unfair, there is the opportunity to make a
-      procedural complaint. The mechanism for this type of complaints is
-      described in [1].
-
-9. Security Considerations
-
-   Documents describing IETF processes, such as this one, do not have an
-   impact on the security of the network infrastructure or of Internet
-   applications.
-
-   It should be noted that all IETF working groups are required to
-   examine and understand the security implications of any technology
-   they develop.  This analysis must be included in any resulting RFCs
-   in a Security Considerations section.  Note that merely noting a
-   significant security hole is no longer sufficient.  IETF developed
-   technologies should not add insecurity to the environment in which
-   they are run.
-
-
-
-Bradner                  Best Current Practice                 [Page 22]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-10. Acknowledgments
-
-   This revision of this document relies heavily on the previous version
-   (RFC 1603) which was edited by Erik Huizer and Dave Crocker.  It has
-   been reviewed by the Poisson Working Group.
-
-11. References
-
-   [1] Bradner, S., Editor, "The Internet Standards Process -- Revision
-       3", BCP 9, RFC 2026, October 1996.
-
-   [2] Hovey, R., and S. Bradner, "The Organizations involved in the
-       IETF Standards Process", BCP 11, RFC 2028, October 1996.
-
-   [3] Gavin, J., "IAB and IESG Selection, Confirmation, and Recall
-       Process: Operation of the Nominating and Recall Committees", BCP
-       10, RFC 2282, February 1998.
-
-   [4] Huitema, C., J. Postel, S. Crocker, "Not all RFCs are Standards",
-       RFC 1796, April 1995.
-
-   [5] Postel, J., and J. Reynolds, "Instructions to RFC Authors", RFC
-       2223, October 1997.
-
-   [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
-       Level", BCP 14, RFC 2119, March 1997.
-
-
-12. Editor's Address
-
-   Scott Bradner
-   Harvard University
-   1350 Mass Ave.
-   Cambridge MA
-   02138
-   USA
-
-   Phone +1 617 495 3864
-   EMail: sob@harvard.edu
-
-
-
-
-
-
-
-
-
-
-
-
-Bradner                  Best Current Practice                 [Page 23]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   Appendix:  Sample Working Group Charter
-
-   Working Group Name:
-        IP Telephony (iptel)
-
-   IETF Area:
-        Transport Area
-
-   Chair(s):
-        Jonathan Rosenberg <jdrosen@bell-labs.com>
-
-   Transport Area Director(s):
-        Scott Bradner <sob@harvard.edu>
-        Allyn Romanow <allyn@mci.net>
-
-   Responsible Area Director:
-        Allyn Romanow <allyn@mci.net>
-
-   Mailing Lists:
-        General Discussion:iptel@lists.research.bell-labs.com
-        To Subscribe: iptel-request@lists.research.bell-labs.com
-        Archive: http://www.bell-labs.com/mailing-lists/siptel
-
-   Description of Working Group:
-
-   Before Internet telephony can become a widely deployed service, a
-   number of protocols must be deployed. These include signaling and
-   capabilities exchange, but also include a number of "peripheral"
-   protocols for providing related services.
-
-   The primary purpose of this working group is to develop two such
-   supportive protocols and a frameword document. They are:
-
-   1. Call Processing Syntax. When a call is setup between two
-   endpoints, the signaling will generally pass through several servers
-   (such as an H.323 gatekeeper) which are responsible for forwarding,
-   redirecting, or proxying the signaling messages. For example, a user
-   may make a call to j.doe@bigcompany.com. The signaling message to
-   initiate the call will arrive at some server at bigcompany. This
-   server can inform the caller that the callee is busy, forward the
-   call initiation request to another server closer to the user, or drop
-   the call completely (among other possibilities). It is very desirable
-   to allow the callee to provide input to this process, guiding the
-   server in its decision on how to act. This can enable a wide variety
-   of advanced personal mobility and call agent services.
-
-
-
-
-
-
-Bradner                  Best Current Practice                 [Page 24]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   Such preferences can be expressed in a call processing syntax, which
-   can be authored by the user (or generated automatically by some
-   tool), and then uploaded to the server. The group will develop this
-   syntax, and specify means of securely transporting and extending it.
-   The result will be a single standards track RFC.
-
-   2. In addition, the group will write a service model document, which
-   describes the services that are enabled by the call processing
-   syntax, and discusses how the syntax can be used. This document will
-   result in a single RFC.
-
-   3. Gateway Attribute Distribution Protocol. When making a call
-   between an IP host and a PSTN user, a telephony gateway must be used.
-   The selection of such gateways can be based on many criteria,
-   including client expressed preferences, service provider preferences,
-   and availability of gateways, in addition to destination telephone
-   number.  Since gateways outside of the hosts' administrative domain
-   might be used, a protocol is required to allow gateways in remote
-   domains to distribute their attributes (such as PSTN connectivity,
-   supported codecs, etc.) to entities in other domains which must make
-   a selection of a gateway. The protocol must allow for scalable,
-   bandwidth efficient, and very secure transmission of these
-   attributes. The group will investigate and design a protocol for this
-   purpose, generate an Internet Draft, and advance it to RFC as
-   appropriate.
-
-   Goals and Milestones:
-
-   May 98    Issue first Internet-Draft on service framework
-   Jul 98    Submit framework ID to IESG for publication as an RFC.
-   Aug 98    Issue first Internet-Draft on Call Processing Syntax
-   Oct 98    Submit Call processing syntax to IESG for consideration
-             as a Proposed Standard.
-   Dec 98    Achieve consensus on basics of gateway attribute
-             distribution protocol
-   Jan 99    Submit Gateway Attribute Distribution protocol to IESG
-             for consideration as a RFC (info, exp, stds track TB
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bradner                  Best Current Practice                 [Page 25]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bradner                  Best Current Practice                 [Page 26]
-
diff --git a/contrib/bind9/doc/rfc/rfc2535.txt b/contrib/bind9/doc/rfc/rfc2535.txt
deleted file mode 100644
index fe0b3d0..0000000
--- a/contrib/bind9/doc/rfc/rfc2535.txt
+++ /dev/null
@@ -1,2635 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         D. Eastlake
-Request for Comments: 2535                                            IBM
-Obsoletes: 2065                                                March 1999
-Updates: 2181, 1035, 1034
-Category: Standards Track
-
-                 Domain Name System Security Extensions
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-Abstract
-
-   Extensions to the Domain Name System (DNS) are described that provide
-   data integrity and authentication to security aware resolvers and
-   applications through the use of cryptographic digital signatures.
-   These digital signatures are included in secured zones as resource
-   records.  Security can also be provided through non-security aware
-   DNS servers in some cases.
-
-   The extensions provide for the storage of authenticated public keys
-   in the DNS.  This storage of keys can support general public key
-   distribution services as well as DNS security.  The stored keys
-   enable security aware resolvers to learn the authenticating key of
-   zones in addition to those for which they are initially configured.
-   Keys associated with DNS names can be retrieved to support other
-   protocols.  Provision is made for a variety of key types and
-   algorithms.
-
-   In addition, the security extensions provide for the optional
-   authentication of DNS protocol transactions and requests.
-
-   This document incorporates feedback on RFC 2065 from early
-   implementers and potential users.
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 1]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-Acknowledgments
-
-   The significant contributions and suggestions of the following
-   persons (in alphabetic order) to DNS security are gratefully
-   acknowledged:
-
-      James M. Galvin
-      John Gilmore
-      Olafur Gudmundsson
-      Charlie Kaufman
-      Edward Lewis
-      Thomas Narten
-      Radia J. Perlman
-      Jeffrey I. Schiller
-      Steven (Xunhua) Wang
-      Brian Wellington
-
-Table of Contents
-
-   Abstract...................................................1
-   Acknowledgments............................................2
-   1. Overview of Contents....................................4
-   2. Overview of the DNS Extensions..........................5
-   2.1 Services Not Provided..................................5
-   2.2 Key Distribution.......................................5
-   2.3 Data Origin Authentication and Integrity...............6
-   2.3.1 The SIG Resource Record..............................7
-   2.3.2 Authenticating Name and Type Non-existence...........7
-   2.3.3 Special Considerations With Time-to-Live.............7
-   2.3.4 Special Considerations at Delegation Points..........8
-   2.3.5 Special Considerations with CNAME....................8
-   2.3.6 Signers Other Than The Zone..........................9
-   2.4 DNS Transaction and Request Authentication.............9
-   3. The KEY Resource Record................................10
-   3.1 KEY RDATA format......................................10
-   3.1.1 Object Types, DNS Names, and Keys...................11
-   3.1.2 The KEY RR Flag Field...............................11
-   3.1.3 The Protocol Octet..................................13
-   3.2 The KEY Algorithm Number Specification................14
-   3.3 Interaction of Flags, Algorithm, and Protocol Bytes...15
-   3.4 Determination of Zone Secure/Unsecured Status.........15
-   3.5 KEY RRs in the Construction of Responses..............17
-   4. The SIG Resource Record................................17
-   4.1 SIG RDATA Format......................................17
-   4.1.1 Type Covered Field..................................18
-   4.1.2 Algorithm Number Field..............................18
-   4.1.3 Labels Field........................................18
-   4.1.4 Original TTL Field..................................19
-
-
-
-Eastlake                    Standards Track                     [Page 2]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   4.1.5 Signature Expiration and Inception Fields...........19
-   4.1.6 Key Tag Field.......................................20
-   4.1.7 Signer's Name Field.................................20
-   4.1.8 Signature Field.....................................20
-   4.1.8.1 Calculating Transaction and Request SIGs..........21
-   4.2 SIG RRs in the Construction of Responses..............21
-   4.3 Processing Responses and SIG RRs......................22
-   4.4 Signature Lifetime, Expiration, TTLs, and Validity....23
-   5. Non-existent Names and Types...........................24
-   5.1 The NXT Resource Record...............................24
-   5.2 NXT RDATA Format......................................25
-   5.3 Additional Complexity Due to Wildcards................26
-   5.4 Example...............................................26
-   5.5 Special Considerations at Delegation Points...........27
-   5.6 Zone Transfers........................................27
-   5.6.1 Full Zone Transfers.................................28
-   5.6.2 Incremental Zone Transfers..........................28
-   6. How to Resolve Securely and the AD and CD Bits.........29
-   6.1 The AD and CD Header Bits.............................29
-   6.2 Staticly Configured Keys..............................31
-   6.3 Chaining Through The DNS..............................31
-   6.3.1 Chaining Through KEYs...............................31
-   6.3.2 Conflicting Data....................................33
-   6.4 Secure Time...........................................33
-   7. ASCII Representation of Security RRs...................34
-   7.1 Presentation of KEY RRs...............................34
-   7.2 Presentation of SIG RRs...............................35
-   7.3 Presentation of NXT RRs...............................36
-   8. Canonical Form and Order of Resource Records...........36
-   8.1 Canonical RR Form.....................................36
-   8.2 Canonical DNS Name Order..............................37
-   8.3 Canonical RR Ordering Within An RRset.................37
-   8.4 Canonical Ordering of RR Types........................37
-   9. Conformance............................................37
-   9.1 Server Conformance....................................37
-   9.2 Resolver Conformance..................................38
-   10. Security Considerations...............................38
-   11. IANA Considerations...................................39
-   References................................................39
-   Author's Address..........................................41
-   Appendix A: Base 64 Encoding..............................42
-   Appendix B: Changes from RFC 2065.........................44
-   Appendix C: Key Tag Calculation...........................46
-   Full Copyright Statement..................................47
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 3]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-1. Overview of Contents
-
-   This document standardizes extensions of the Domain Name System (DNS)
-   protocol to support DNS security and public key distribution. It
-   assumes that the reader is familiar with the Domain Name System,
-   particularly as described in RFCs 1033, 1034, 1035 and later RFCs. An
-   earlier version of these extensions appears in RFC 2065.  This
-   replacement for that RFC incorporates early implementation experience
-   and requests from  potential users.
-
-   Section 2 provides an overview of the extensions and the key
-   distribution, data origin authentication, and transaction and request
-   security they provide.
-
-   Section 3 discusses the KEY resource record, its structure, and use
-   in DNS responses.  These resource records represent the public keys
-   of entities named in the DNS and are used for key distribution.
-
-   Section 4 discusses the SIG digital signature resource record, its
-   structure, and use in DNS responses.  These resource records are used
-   to authenticate other resource records in the DNS and optionally to
-   authenticate DNS transactions and requests.
-
-   Section 5 discusses the NXT resource record (RR) and its use in DNS
-   responses including full and incremental zone transfers.  The NXT RR
-   permits authenticated denial of the existence of a name or of an RR
-   type for an existing name.
-
-   Section 6 discusses how a resolver can be configured with a starting
-   key or keys and proceed to securely resolve DNS requests.
-   Interactions between resolvers and servers are discussed for various
-   combinations of security aware and security non-aware.  Two
-   additional DNS header bits are defined for signaling between
-   resolvers and servers.
-
-   Section 7 describes the ASCII representation of the security resource
-   records for use in master files and elsewhere.
-
-   Section 8 defines the canonical form and order of RRs for DNS
-   security purposes.
-
-   Section 9 defines levels of conformance for resolvers and servers.
-
-   Section 10 provides a few paragraphs on overall security
-   considerations.
-
-   Section 11 specified IANA considerations for allocation of additional
-   values of paramters defined in this document.
-
-
-
-Eastlake                    Standards Track                     [Page 4]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   Appendix A gives details of base 64 encoding which is used in the
-   file representation of some RRs defined in this document.
-
-   Appendix B summarizes changes between this memo and RFC 2065.
-
-   Appendix C specified how to calculate the simple checksum used as a
-   key tag in most SIG RRs.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-2. Overview of the DNS Extensions
-
-   The Domain Name System (DNS) protocol security extensions provide
-   three distinct services: key distribution as described in Section 2.2
-   below, data origin authentication as described in Section 2.3 below,
-   and transaction and request authentication, described in Section 2.4
-   below.
-
-   Special considerations related to "time to live", CNAMEs, and
-   delegation points are also discussed in Section 2.3.
-
-2.1 Services Not Provided
-
-   It is part of the design philosophy of the DNS that the data in it is
-   public and that the DNS gives the same answers to all inquirers.
-   Following this philosophy, no attempt has been made to include any
-   sort of access control lists or other means to differentiate
-   inquirers.
-
-   No effort has been made to provide for any confidentiality for
-   queries or responses.  (This service may be available via IPSEC [RFC
-   2401], TLS, or other security protocols.)
-
-   Protection is not provided against denial of service.
-
-2.2 Key Distribution
-
-   A resource record format is defined to associate keys with DNS names.
-   This permits the DNS to be used as a public key distribution
-   mechanism in support of DNS security itself and other protocols.
-
-   The syntax of a KEY resource record (RR) is described in Section 3.
-   It includes an algorithm identifier, the actual public key
-   parameter(s), and a variety of flags including those indicating the
-   type of entity the key is associated with and/or asserting that there
-   is no key associated with that entity.
-
-
-
-Eastlake                    Standards Track                     [Page 5]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   Under conditions described in Section 3.5, security aware DNS servers
-   will automatically attempt to return KEY resources as additional
-   information, along with those resource records actually requested, to
-   minimize the number of queries needed.
-
-2.3 Data Origin Authentication and Integrity
-
-   Authentication is provided by associating with resource record sets
-   (RRsets [RFC 2181]) in the DNS cryptographically generated digital
-   signatures. Commonly, there will be a single private key that
-   authenticates an entire zone but there might be multiple keys for
-   different algorithms, signers, etc. If a security aware resolver
-   reliably learns a public key of the zone, it can authenticate, for
-   signed data read from that zone, that it is properly authorized.  The
-   most secure implementation is for the zone private key(s) to be kept
-   off-line and used to re-sign all of the records in the zone
-   periodically.  However, there are cases, for example dynamic update
-   [RFCs 2136, 2137], where DNS private keys need to be on-line [RFC
-   2541].
-
-   The data origin authentication key(s) are associated with the zone
-   and not with the servers that store copies of the data.  That means
-   compromise of a secondary server or, if the key(s) are kept off line,
-   even the primary server for a zone, will not necessarily affect the
-   degree of assurance that a resolver has that it can determine whether
-   data is genuine.
-
-   A resolver could learn a public key of a zone either by reading it
-   from the DNS or by having it staticly configured.  To reliably learn
-   a public key by reading it from the DNS, the key itself must be
-   signed with a key the resolver trusts. The resolver must be
-   configured with at least a public key which authenticates one zone as
-   a starting point. From there, it can securely read public keys of
-   other zones, if the intervening zones in the DNS tree are secure and
-   their signed keys accessible.
-
-   Adding data origin authentication and integrity requires no change to
-   the "on-the-wire" DNS protocol beyond the addition of the signature
-   resource type and the key resource type needed for key distribution.
-   (Data non-existence authentication also requires the NXT RR as
-   described in 2.3.2.)  This service can be supported by existing
-   resolver and caching server implementations so long as they can
-   support the additional resource types (see Section 9). The one
-   exception is that CNAME referrals in a secure zone can not be
-   authenticated if they are from non-security aware servers (see
-   Section 2.3.5).
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 6]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   If signatures are separately retrieved and verified when retrieving
-   the information they authenticate, there will be more trips to the
-   server and performance will suffer.  Security aware servers mitigate
-   that degradation by attempting to send the signature(s) needed (see
-   Section 4.2).
-
-2.3.1 The SIG Resource Record
-
-   The syntax of a SIG resource record (signature) is described in
-   Section 4.  It cryptographicly binds the RRset being signed to the
-   signer and a validity interval.
-
-   Every name in a secured zone will have associated with it at least
-   one SIG resource record for each resource type under that name except
-   for glue address RRs and delegation point NS RRs.  A security aware
-   server will attempt to return, with RRs retrieved, the corresponding
-   SIGs.  If a server is not security aware, the resolver must retrieve
-   all the SIG records for a name and select the one or ones that sign
-   the resource record set(s) that resolver is interested in.
-
-2.3.2 Authenticating Name and Type Non-existence
-
-   The above security mechanism only provides a way to sign existing
-   RRsets in a zone.  "Data origin" authentication is not obviously
-   provided for the non-existence of a domain name in a zone or the
-   non-existence of a type for an existing name.  This gap is filled by
-   the NXT RR which authenticatably asserts a range of non-existent
-   names in a zone and the non-existence of types for the existing name
-   just before that range.
-
-   Section 5 below covers the NXT RR.
-
-2.3.3 Special Considerations With Time-to-Live
-
-   A digital signature will fail to verify if any change has occurred to
-   the data between the time it was originally signed and the time the
-   signature is verified.  This conflicts with our desire to have the
-   time-to-live (TTL) field of resource records tick down while they are
-   cached.
-
-   This could be avoided by leaving the time-to-live out of the digital
-   signature, but that would allow unscrupulous servers to set
-   arbitrarily long TTL values undetected.  Instead, we include the
-   "original" TTL in the signature and communicate that data along with
-   the current TTL. Unscrupulous servers under this scheme can
-   manipulate the TTL but a security aware resolver will bound the TTL
-   value it uses at the original signed value.  Separately, signatures
-   include a signature inception time and a signature expiration time. A
-
-
-
-Eastlake                    Standards Track                     [Page 7]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   resolver that knows the absolute time can determine securely whether
-   a signature is in effect.  It is not possible to rely solely on the
-   signature expiration as a substitute for the TTL, however, since the
-   TTL is primarily a database consistency mechanism and non-security
-   aware servers that depend on TTL must still be supported.
-
-2.3.4 Special Considerations at Delegation Points
-
-   DNS security would like to view each zone as a unit of data
-   completely under the control of the zone owner with each entry
-   (RRset) signed by a special private key held by the zone manager.
-   But the DNS protocol views the leaf nodes in a zone, which are also
-   the apex nodes of a subzone (i.e., delegation points), as "really"
-   belonging to the subzone.  These nodes occur in two master files and
-   might have RRs signed by both the upper and lower zone's keys. A
-   retrieval could get a mixture of these RRs and SIGs, especially since
-   one server could be serving both the zone above and below a
-   delegation point. [RFC 2181]
-
-   There MUST be a zone KEY RR, signed by its superzone, for every
-   subzone if the superzone is secure. This will normally appear in the
-   subzone and may also be included in the superzone.  But, in the case
-   of an unsecured subzone which can not or will not be modified to add
-   any security RRs, a KEY declaring the subzone to be unsecured MUST
-   appear with the superzone signature in the superzone, if the
-   superzone is secure. For all but one other RR type the data from the
-   subzone is more authoritative so only the subzone KEY RR should be
-   signed in the superzone if it appears there. The NS and any glue
-   address RRs SHOULD only be signed in the subzone. The SOA and any
-   other RRs that have the zone name as owner should appear only in the
-   subzone and thus are signed only there. The NXT RR type is the
-   exceptional case that will always appear differently and
-   authoritatively in both the superzone and subzone, if both are
-   secure, as described in Section 5.
-
-2.3.5 Special Considerations with CNAME
-
-   There is a problem when security related RRs with the same owner name
-   as a CNAME RR are retrieved from a non-security-aware server. In
-   particular, an initial retrieval for the CNAME or any other type may
-   not retrieve any associated SIG, KEY, or NXT RR. For retrieved types
-   other than CNAME, it will retrieve that type at the target name of
-   the CNAME (or chain of CNAMEs) and will also return the CNAME.  In
-   particular, a specific retrieval for type SIG will not get the SIG,
-   if any, at the original CNAME domain name but rather a SIG at the
-   target name.
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 8]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   Security aware servers must be used to securely CNAME in DNS.
-   Security aware servers MUST (1) allow KEY, SIG, and NXT RRs along
-   with CNAME RRs, (2) suppress CNAME processing on retrieval of these
-   types as well as on retrieval of the type CNAME, and (3)
-   automatically return SIG RRs authenticating the CNAME or CNAMEs
-   encountered in resolving a query.  This is a change from the previous
-   DNS standard [RFCs 1034/1035] which prohibited any other RR type at a
-   node where a CNAME RR was present.
-
-2.3.6 Signers Other Than The Zone
-
-   There are cases where the signer in a SIG resource record is other
-   than one of the private key(s) used to authenticate a zone.
-
-   One is for support of dynamic update [RFC 2136] (or future requests
-   which require secure authentication) where an entity is permitted to
-   authenticate/update its records [RFC 2137] and the zone is operating
-   in a mode where the zone key is not on line. The public key of the
-   entity must be present in the DNS and be signed by a zone level key
-   but the other RR(s) may be signed with the entity's key.
-
-   A second case is support of transaction and request authentication as
-   described in Section 2.4.
-
-   In additions, signatures can be included on resource records within
-   the DNS for use by applications other than DNS. DNS related
-   signatures authenticate that data originated with the authority of a
-   zone owner or that a request or transaction originated with the
-   relevant entity. Other signatures can provide other types of
-   assurances.
-
-2.4 DNS Transaction and Request Authentication
-
-   The data origin authentication service described above protects
-   retrieved resource records and the non-existence of resource records
-   but provides no protection for DNS requests or for message headers.
-
-   If header bits are falsely set by a bad server, there is little that
-   can be done.  However, it is possible to add transaction
-   authentication.  Such authentication means that a resolver can be
-   sure it is at least getting messages from the server it thinks it
-   queried and that the response is from the query it sent (i.e., that
-   these messages have not been diddled in transit).  This is
-   accomplished by optionally adding a special SIG resource record at
-   the end of the reply which digitally signs the concatenation of the
-   server's response and the resolver's query.
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 9]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   Requests can also be authenticated by including a special SIG RR at
-   the end of the request.  Authenticating requests serves no function
-   in older DNS servers and requests with a non-empty additional
-   information section produce error returns or may even be ignored by
-   many of them. However, this syntax for signing requests is defined as
-   a way of authenticating secure dynamic update requests [RFC 2137] or
-   future requests requiring authentication.
-
-   The private keys used in transaction security belong to the entity
-   composing the reply, not to the zone involved.  Request
-   authentication may also involve the private key of the host or other
-   entity composing the request or other private keys depending on the
-   request authority it is sought to establish. The corresponding public
-   key(s) are normally stored in and retrieved from the DNS for
-   verification.
-
-   Because requests and replies are highly variable, message
-   authentication SIGs can not be pre-calculated.  Thus it will be
-   necessary to keep the private key on-line, for example in software or
-   in a directly connected piece of hardware.
-
-3. The KEY Resource Record
-
-   The KEY resource record (RR) is used to store a public key that is
-   associated with a Domain Name System (DNS) name.  This can be the
-   public key of a zone, a user, or a host or other end entity. Security
-   aware DNS implementations MUST be designed to handle at least two
-   simultaneously valid keys of the same type associated with the same
-   name.
-
-   The type number for the KEY RR is 25.
-
-   A KEY RR is, like any other RR, authenticated by a SIG RR.  KEY RRs
-   must be signed by a zone level key.
-
-3.1 KEY RDATA format
-
-   The RDATA for a KEY RR consists of flags, a protocol octet, the
-   algorithm number octet, and the public key itself.  The format is as
-   follows:
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 10]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |             flags             |    protocol   |   algorithm   |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                                                               /
-   /                          public key                           /
-   /                                                               /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
-
-   The KEY RR is not intended for storage of certificates and a separate
-   certificate RR has been developed for that purpose, defined in [RFC
-   2538].
-
-   The meaning of the KEY RR owner name, flags, and protocol octet are
-   described in Sections 3.1.1 through 3.1.5 below.  The flags and
-   algorithm must be examined before any data following the algorithm
-   octet as they control the existence and format of any following data.
-   The algorithm and public key fields are described in Section 3.2.
-   The format of the public key is algorithm dependent.
-
-   KEY RRs do not specify their validity period but their authenticating
-   SIG RR(s) do as described in Section 4 below.
-
-3.1.1 Object Types, DNS Names, and Keys
-
-   The public key in a KEY RR is for the object named in the owner name.
-
-   A DNS name may refer to three different categories of things.  For
-   example, foo.host.example could be (1) a zone, (2) a host or other
-   end entity , or (3) the mapping into a DNS name of the user or
-   account foo@host.example.  Thus, there are flag bits, as described
-   below, in the KEY RR to indicate with which of these roles the owner
-   name and public key are associated.  Note that an appropriate zone
-   KEY RR MUST occur at the apex node of a secure zone and zone KEY RRs
-   occur only at delegation points.
-
-3.1.2 The KEY RR Flag Field
-
-   In the "flags" field:
-
-     0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
-   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-   |  A/C  | Z | XT| Z | Z | NAMTYP| Z | Z | Z | Z |      SIG      |
-   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-
-   Bit 0 and 1 are the key "type" bits whose values have the following
-   meanings:
-
-
-
-Eastlake                    Standards Track                    [Page 11]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-           10: Use of the key is prohibited for authentication.
-           01: Use of the key is prohibited for confidentiality.
-           00: Use of the key for authentication and/or confidentiality
-               is permitted. Note that DNS security makes use of keys
-               for authentication only. Confidentiality use flagging is
-               provided for use of keys in other protocols.
-               Implementations not intended to support key distribution
-               for confidentiality MAY require that the confidentiality
-               use prohibited bit be on for keys they serve.
-           11: If both bits are one, the "no key" value, there is no key
-               information and the RR stops after the algorithm octet.
-               By the use of this "no key" value, a signed KEY RR can
-               authenticatably assert that, for example, a zone is not
-               secured.  See section 3.4 below.
-
-   Bits 2 is reserved and must be zero.
-
-   Bits 3 is reserved as a flag extension bit.  If it is a one, a second
-          16 bit flag field is added after the algorithm octet and
-          before the key data.  This bit MUST NOT be set unless one or
-          more such additional bits have been defined and are non-zero.
-
-   Bits 4-5 are reserved and must be zero.
-
-   Bits 6 and 7 form a field that encodes the name type. Field values
-   have the following meanings:
-
-           00: indicates that this is a key associated with a "user" or
-               "account" at an end entity, usually a host.  The coding
-               of the owner name is that used for the responsible
-               individual mailbox in the SOA and RP RRs: The owner name
-               is the user name as the name of a node under the entity
-               name.  For example, "j_random_user" on
-               host.subdomain.example could have a public key associated
-               through a KEY RR with name
-               j_random_user.host.subdomain.example.  It could be used
-               in a security protocol where authentication of a user was
-               desired.  This key might be useful in IP or other
-               security for a user level service such a telnet, ftp,
-               rlogin, etc.
-           01: indicates that this is a zone key for the zone whose name
-               is the KEY RR owner name.  This is the public key used
-               for the primary DNS security feature of data origin
-               authentication.  Zone KEY RRs occur only at delegation
-               points.
-           10: indicates that this is a key associated with the non-zone
-               "entity" whose name is the RR owner name.  This will
-               commonly be a host but could, in some parts of the DNS
-
-
-
-Eastlake                    Standards Track                    [Page 12]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-               tree, be some other type of entity such as a telephone
-               number [RFC 1530] or numeric IP address.  This is the
-               public key used in connection with DNS request and
-               transaction authentication services.  It could also be
-               used in an IP-security protocol where authentication at
-               the host, rather than user, level was desired, such as
-               routing, NTP, etc.
-           11: reserved.
-
-   Bits 8-11 are reserved and must be zero.
-
-   Bits 12-15 are the "signatory" field.  If non-zero, they indicate
-              that the key can validly sign things as specified in DNS
-              dynamic update [RFC 2137].  Note that zone keys (see bits
-              6 and 7 above) always have authority to sign any RRs in
-              the zone regardless of the value of the signatory field.
-
-3.1.3 The Protocol Octet
-
-   It is anticipated that keys stored in DNS will be used in conjunction
-   with a variety of Internet protocols.  It is intended that the
-   protocol octet and possibly some of the currently unused (must be
-   zero) bits in the KEY RR flags as specified in the future will be
-   used to indicate a key's validity for different protocols.
-
-   The following values of the Protocol Octet are reserved as indicated:
-
-        VALUE   Protocol
-
-          0      -reserved
-          1     TLS
-          2     email
-          3     dnssec
-          4     IPSEC
-         5-254   - available for assignment by IANA
-        255     All
-
-   In more detail:
-        1 is reserved for use in connection with TLS.
-        2 is reserved for use in connection with email.
-        3 is used for DNS security.  The protocol field SHOULD be set to
-          this value for zone keys and other keys used in DNS security.
-          Implementations that can determine that a key is a DNS
-          security key by the fact that flags label it a zone key or the
-          signatory flag field is non-zero are NOT REQUIRED to check the
-          protocol field.
-        4 is reserved to refer to the Oakley/IPSEC [RFC 2401] protocol
-          and indicates that this key is valid for use in conjunction
-
-
-
-Eastlake                    Standards Track                    [Page 13]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-          with that security standard.  This key could be used in
-          connection with secured communication on behalf of an end
-          entity or user whose name is the owner name of the KEY RR if
-          the entity or user flag bits are set.  The presence of a KEY
-          resource with this protocol value is an assertion that the
-          host speaks Oakley/IPSEC.
-        255 indicates that the key can be used in connection with any
-          protocol for which KEY RR protocol octet values have been
-          defined.  The use of this value is discouraged and the use of
-          different keys for different protocols is encouraged.
-
-3.2 The KEY Algorithm Number Specification
-
-   This octet is the key algorithm parallel to the same field for the
-   SIG resource as described in Section 4.1.  The following values are
-   assigned:
-
-   VALUE   Algorithm
-
-     0      - reserved, see Section 11
-     1     RSA/MD5 [RFC 2537] - recommended
-     2     Diffie-Hellman [RFC 2539] - optional, key only
-     3     DSA [RFC 2536] - MANDATORY
-     4     reserved for elliptic curve crypto
-   5-251    - available, see Section 11
-   252     reserved for indirect keys
-   253     private - domain name (see below)
-   254     private - OID (see below)
-   255      - reserved, see Section 11
-
-   Algorithm specific formats and procedures are given in separate
-   documents.  The mandatory to implement for interoperability algorithm
-   is number 3, DSA.  It is recommended that the RSA/MD5 algorithm,
-   number 1, also be implemented.  Algorithm 2 is used to indicate
-   Diffie-Hellman keys and algorithm 4 is reserved for elliptic curve.
-
-   Algorithm number 252 indicates an indirect key format where the
-   actual key material is elsewhere.  This format is to be defined in a
-   separate document.
-
-   Algorithm numbers 253 and 254 are reserved for private use and will
-   never be assigned a specific algorithm.  For number 253, the public
-   key area and the signature begin with a wire encoded domain name.
-   Only local domain name compression is permitted.  The domain name
-   indicates the private algorithm to use and the remainder of the
-   public key area is whatever is required by that algorithm.  For
-   number 254, the public key area for the KEY RR and the signature
-   begin with an unsigned length byte followed by a BER encoded Object
-
-
-
-Eastlake                    Standards Track                    [Page 14]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   Identifier (ISO OID) of that length.  The OID indicates the private
-   algorithm in use and the remainder of the area is whatever is
-   required by that algorithm.  Entities should only use domain names
-   and OIDs they control to designate their private algorithms.
-
-   Values 0 and 255 are reserved but the value 0 is used in the
-   algorithm field when that field is not used.  An example is in a KEY
-   RR with the top two flag bits on, the "no-key" value, where no key is
-   present.
-
-3.3 Interaction of Flags, Algorithm, and Protocol Bytes
-
-   Various combinations of the no-key type flags, algorithm byte,
-   protocol byte, and any future assigned protocol indicating flags are
-   possible.  The meaning of these combinations is indicated below:
-
-   NK = no key type (flags bits 0 and 1 on)
-   AL = algorithm byte
-   PR = protocols indicated by protocol byte or future assigned flags
-
-   x represents any valid non-zero value(s).
-
-    AL  PR   NK  Meaning
-     0   0   0   Illegal, claims key but has bad algorithm field.
-     0   0   1   Specifies total lack of security for owner zone.
-     0   x   0   Illegal, claims key but has bad algorithm field.
-     0   x   1   Specified protocols unsecured, others may be secure.
-     x   0   0   Gives key but no protocols to use it.
-     x   0   1   Denies key for specific algorithm.
-     x   x   0   Specifies key for protocols.
-     x   x   1   Algorithm not understood for protocol.
-
-3.4 Determination of Zone Secure/Unsecured Status
-
-   A zone KEY RR with the "no-key" type field value (both key type flag
-   bits 0 and 1 on) indicates that the zone named is unsecured while a
-   zone KEY RR with a key present indicates that the zone named is
-   secure.  The secured versus unsecured status of a zone may vary with
-   different cryptographic algorithms.  Even for the same algorithm,
-   conflicting zone KEY RRs may be present.
-
-   Zone KEY RRs, like all RRs, are only trusted if they are
-   authenticated by a SIG RR whose signer field is a signer for which
-   the resolver has a public key they trust and where resolver policy
-   permits that signer to sign for the KEY owner name.  Untrusted zone
-   KEY RRs MUST be ignored in determining the security status of the
-   zone.  However, there can be multiple sets of trusted zone KEY RRs
-   for a zone with different algorithms, signers, etc.
-
-
-
-Eastlake                    Standards Track                    [Page 15]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   For any particular algorithm, zones can be (1) secure, indicating
-   that any retrieved RR must be authenticated by a SIG RR or it will be
-   discarded as bogus, (2) unsecured, indicating that SIG RRs are not
-   expected or required for RRs retrieved from the zone, or (3)
-   experimentally secure, which indicates that SIG RRs might or might
-   not be present but must be checked if found.  The status of a zone is
-   determined as follows:
-
-   1. If, for a zone and algorithm, every trusted zone KEY RR for the
-      zone says there is no key for that zone, it is unsecured for that
-      algorithm.
-
-   2. If, there is at least one trusted no-key zone KEY RR and one
-      trusted key specifying zone KEY RR, then that zone is only
-      experimentally secure for the algorithm.  Both authenticated and
-      non-authenticated RRs for it should be accepted by the resolver.
-
-   3. If every trusted zone KEY RR that the zone and algorithm has is
-      key specifying, then it is secure for that algorithm and only
-      authenticated RRs from it will be accepted.
-
-   Examples:
-
-   (1)  A resolver initially trusts only signatures by the superzone of
-   zone Z within the DNS hierarchy.  Thus it will look only at the KEY
-   RRs that are signed by the superzone.  If it finds only no-key KEY
-   RRs, it will assume the zone is not secure.  If it finds only key
-   specifying KEY RRs, it will assume the zone is secure and reject any
-   unsigned responses.  If it finds both, it will assume the zone is
-   experimentally secure
-
-   (2)  A resolver trusts the superzone of zone Z (to which it got
-   securely from its local zone) and a third party, cert-auth.example.
-   When considering data from zone Z, it may be signed by the superzone
-   of Z, by cert-auth.example, by both, or by neither.  The following
-   table indicates whether zone Z will be considered secure,
-   experimentally secure, or unsecured, depending on the signed zone KEY
-   RRs for Z;
-
-                      c e r t - a u t h . e x a m p l e
-
-        KEY RRs|   None    |  NoKeys   |  Mixed   |   Keys   |
-     S       --+-----------+-----------+----------+----------+
-     u  None   | illegal   | unsecured | experim. | secure   |
-     p       --+-----------+-----------+----------+----------+
-     e  NoKeys | unsecured | unsecured | experim. | secure   |
-     r       --+-----------+-----------+----------+----------+
-     Z  Mixed  | experim.  | experim.  | experim. | secure   |
-
-
-
-Eastlake                    Standards Track                    [Page 16]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-     o       --+-----------+-----------+----------+----------+
-     n  Keys   | secure    | secure    | secure   | secure   |
-     e         +-----------+-----------+----------+----------+
-
-3.5 KEY RRs in the Construction of Responses
-
-   An explicit request for KEY RRs does not cause any special additional
-   information processing except, of course, for the corresponding SIG
-   RR from a security aware server (see Section 4.2).
-
-   Security aware DNS servers include KEY RRs as additional information
-   in responses, where a KEY is available, in the following cases:
-
-   (1) On the retrieval of SOA or NS RRs, the KEY RRset with the same
-   name (perhaps just a zone key) SHOULD be included as additional
-   information if space is available. If not all additional information
-   will fit, type A and AAAA glue RRs have higher priority than KEY
-   RR(s).
-
-   (2) On retrieval of type A or AAAA RRs, the KEY RRset with the same
-   name (usually just a host RR and NOT the zone key (which usually
-   would have a different name)) SHOULD be included if space is
-   available.  On inclusion of A or AAAA RRs as additional information,
-   the KEY RRset with the same name should also be included but with
-   lower priority than the A or AAAA RRs.
-
-4. The SIG Resource Record
-
-   The SIG or "signature" resource record (RR) is the fundamental way
-   that data is authenticated in the secure Domain Name System (DNS). As
-   such it is the heart of the security provided.
-
-   The SIG RR unforgably authenticates an RRset [RFC 2181] of a
-   particular type, class, and name and binds it to a time interval and
-   the signer's domain name.  This is done using cryptographic
-   techniques and the signer's private key.  The signer is frequently
-   the owner of the zone from which the RR originated.
-
-   The type number for the SIG RR type is 24.
-
-4.1 SIG RDATA Format
-
-   The RDATA portion of a SIG RR is as shown below.  The integrity of
-   the RDATA information is protected by the signature field.
-
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 17]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-                           1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |        type covered           |  algorithm    |     labels    |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |                         original TTL                          |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |                      signature expiration                     |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |                      signature inception                      |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |            key  tag           |                               |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         signer's name         +
-      |                                                               /
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/
-      /                                                               /
-      /                            signature                          /
-      /                                                               /
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-4.1.1 Type Covered Field
-
-   The "type covered" is the type of the other RRs covered by this SIG.
-
-4.1.2 Algorithm Number Field
-
-   This octet is as described in section 3.2.
-
-4.1.3 Labels Field
-
-   The "labels" octet is an unsigned count of how many labels there are
-   in the original SIG RR owner name not counting the null label for
-   root and not counting any initial "*" for a wildcard.  If a secured
-   retrieval is the result of wild card substitution, it is necessary
-   for the resolver to use the original form of the name in verifying
-   the digital signature.  This field makes it easy to determine the
-   original form.
-
-   If, on retrieval, the RR appears to have a longer name than indicated
-   by "labels", the resolver can tell it is the result of wildcard
-   substitution.  If the RR owner name appears to be shorter than the
-   labels count, the SIG RR must be considered corrupt and ignored.  The
-   maximum number of labels allowed in the current DNS is 127 but the
-   entire octet is reserved and would be required should DNS names ever
-   be expanded to 255 labels.  The following table gives some examples.
-   The value of "labels" is at the top, the retrieved owner name on the
-   left, and the table entry is the name to use in signature
-   verification except that "bad" means the RR is corrupt.
-
-
-
-Eastlake                    Standards Track                    [Page 18]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   labels= |  0  |   1  |    2   |      3   |      4   |
-   --------+-----+------+--------+----------+----------+
-          .|   . | bad  |  bad   |    bad   |    bad   |
-         d.|  *. |   d. |  bad   |    bad   |    bad   |
-       c.d.|  *. | *.d. |   c.d. |    bad   |    bad   |
-     b.c.d.|  *. | *.d. | *.c.d. |   b.c.d. |    bad   |
-   a.b.c.d.|  *. | *.d. | *.c.d. | *.b.c.d. | a.b.c.d. |
-
-4.1.4 Original TTL Field
-
-   The "original TTL" field is included in the RDATA portion to avoid
-   (1) authentication problems that caching servers would otherwise
-   cause by decrementing the real TTL field and (2) security problems
-   that unscrupulous servers could otherwise cause by manipulating the
-   real TTL field.  This original TTL is protected by the signature
-   while the current TTL field is not.
-
-   NOTE:  The "original TTL" must be restored into the covered RRs when
-   the signature is verified (see Section 8).  This generaly implies
-   that all RRs for a particular type, name, and class, that is, all the
-   RRs in any particular RRset, must have the same TTL to start with.
-
-4.1.5 Signature Expiration and Inception Fields
-
-   The SIG is valid from the "signature inception" time until the
-   "signature expiration" time.  Both are unsigned numbers of seconds
-   since the start of 1 January 1970, GMT, ignoring leap seconds.  (See
-   also Section 4.4.)  Ring arithmetic is used as for DNS SOA serial
-   numbers [RFC 1982] which means that these times can never be more
-   than about 68 years in the past or the future.  This means that these
-   times are ambiguous modulo ~136.09 years.  However there is no
-   security flaw because keys are required to be changed to new random
-   keys by [RFC 2541] at least every five years.  This means that the
-   probability that the same key is in use N*136.09 years later should
-   be the same as the probability that a random guess will work.
-
-   A SIG RR may have an expiration time numerically less than the
-   inception time if the expiration time is near the 32 bit wrap around
-   point and/or the signature is long lived.
-
-   (To prevent misordering of network requests to update a zone
-   dynamically, monotonically increasing "signature inception" times may
-   be necessary.)
-
-   A secure zone must be considered changed for SOA serial number
-   purposes not only when its data is updated but also when new SIG RRs
-   are inserted (ie, the zone or any part of it is re-signed).
-
-
-
-
-Eastlake                    Standards Track                    [Page 19]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-4.1.6 Key Tag Field
-
-   The "key Tag" is a two octet quantity that is used to efficiently
-   select between multiple keys which may be applicable and thus check
-   that a public key about to be used for the computationally expensive
-   effort to check the signature is possibly valid.  For algorithm 1
-   (MD5/RSA) as defined in [RFC 2537], it is the next to the bottom two
-   octets of the public key modulus needed to decode the signature
-   field.  That is to say, the most significant 16 of the least
-   significant 24 bits of the modulus in network (big endian) order. For
-   all other algorithms, including private algorithms, it is calculated
-   as a simple checksum of the KEY RR as described in Appendix C.
-
-4.1.7 Signer's Name Field
-
-   The "signer's name" field is the domain name of the signer generating
-   the SIG RR.  This is the owner name of the public KEY RR that can be
-   used to verify the signature.  It is frequently the zone which
-   contained the RRset being authenticated.  Which signers should be
-   authorized to sign what is a significant resolver policy question as
-   discussed in Section 6. The signer's name may be compressed with
-   standard DNS name compression when being transmitted over the
-   network.
-
-4.1.8 Signature Field
-
-   The actual signature portion of the SIG RR binds the other RDATA
-   fields to the RRset of the "type covered" RRs with that owner name
-   and class.  This covered RRset is thereby authenticated.  To
-   accomplish this, a data sequence is constructed as follows:
-
-         data = RDATA | RR(s)...
-
-   where "|" is concatenation,
-
-   RDATA is the wire format of all the RDATA fields in the SIG RR itself
-   (including the canonical form of the signer's name) before but not
-   including the signature, and
-
-   RR(s) is the RRset of the RR(s) of the type covered with the same
-   owner name and class as the SIG RR in canonical form and order as
-   defined in Section 8.
-
-   How this data sequence is processed into the signature is algorithm
-   dependent.  These algorithm dependent formats and procedures are
-   described in separate documents (Section 3.2).
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 20]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   SIGs SHOULD NOT be included in a zone for any "meta-type" such as
-   ANY, AXFR, etc. (but see section 5.6.2 with regard to IXFR).
-
-4.1.8.1 Calculating Transaction and Request SIGs
-
-   A response message from a security aware server may optionally
-   contain a special SIG at the end of the additional information
-   section to authenticate the transaction.
-
-   This SIG has a "type covered" field of zero, which is not a valid RR
-   type.  It is calculated by using a "data" (see Section 4.1.8) of the
-   entire preceding DNS reply message, including DNS header but not the
-   IP header and before the reply RR counts have been adjusted for the
-   inclusion of any transaction SIG, concatenated with the entire DNS
-   query message that produced this response, including the query's DNS
-   header and any request SIGs but not its IP header.  That is
-
-      data = full response (less transaction SIG) | full query
-
-   Verification of the transaction SIG (which is signed by the server
-   host key, not the zone key) by the requesting resolver shows that the
-   query and response were not tampered with in transit, that the
-   response corresponds to the intended query, and that the response
-   comes from the queried server.
-
-   A DNS request may be optionally signed by including one or more SIGs
-   at the end of the query. Such SIGs are identified by having a "type
-   covered" field of zero. They sign the preceding DNS request message
-   including DNS header but not including the IP header or any request
-   SIGs at the end and before the request RR counts have been adjusted
-   for the inclusions of any request SIG(s).
-
-   WARNING: Request SIGs are unnecessary for any currently defined
-   request other than update [RFC 2136, 2137] and will cause some old
-   DNS servers to give an error return or ignore a query.  However, such
-   SIGs may in the future be needed for other requests.
-
-   Except where needed to authenticate an update or similar privileged
-   request, servers are not required to check request SIGs.
-
-4.2 SIG RRs in the Construction of Responses
-
-   Security aware DNS servers SHOULD, for every authenticated RRset the
-   query will return, attempt to send the available SIG RRs which
-   authenticate the requested RRset.  The following rules apply to the
-   inclusion of SIG RRs in responses:
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 21]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-     1. when an RRset is placed in a response, its SIG RR has a higher
-        priority for inclusion than additional RRs that may need to be
-        included.  If space does not permit its inclusion, the response
-        MUST be considered truncated except as provided in 2 below.
-
-     2. When a SIG RR is present in the zone for an additional
-        information section RR, the response MUST NOT be considered
-        truncated merely because space does not permit the inclusion of
-        the SIG RR with the additional information.
-
-     3. SIGs to authenticate glue records and NS RRs for subzones at a
-        delegation point are unnecessary and MUST NOT be sent.
-
-     4. If a SIG covers any RR that would be in the answer section of
-        the response, its automatic inclusion MUST be in the answer
-        section.  If it covers an RR that would appear in the authority
-        section, its automatic inclusion MUST be in the authority
-        section.  If it covers an RR that would appear in the additional
-        information section it MUST appear in the additional information
-        section.  This is a change in the existing standard [RFCs 1034,
-        1035] which contemplates only NS and SOA RRs in the authority
-        section.
-
-     5. Optionally, DNS transactions may be authenticated by a SIG RR at
-        the end of the response in the additional information section
-        (Section 4.1.8.1).  Such SIG RRs are signed by the DNS server
-        originating the response.  Although the signer field MUST be a
-        name of the originating server host, the owner name, class, TTL,
-        and original TTL, are meaningless.  The class and TTL fields
-        SHOULD be zero.  To conserve space, the owner name SHOULD be
-        root (a single zero octet).  If transaction authentication is
-        desired, that SIG RR must be considered the highest priority for
-        inclusion.
-
-4.3 Processing Responses and SIG RRs
-
-   The following rules apply to the processing of SIG RRs included in a
-   response:
-
-     1. A security aware resolver that receives a response from a
-        security aware server via a secure communication with the AD bit
-        (see Section 6.1) set, MAY choose to accept the RRs as received
-        without verifying the zone SIG RRs.
-
-     2. In other cases, a security aware resolver SHOULD verify the SIG
-        RRs for the RRs of interest.  This may involve initiating
-        additional queries for SIG or KEY RRs, especially in the case of
-
-
-
-
-Eastlake                    Standards Track                    [Page 22]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-        getting a response from a server that does not implement
-        security.  (As explained in 2.3.5 above, it will not be possible
-        to secure CNAMEs being served up by non-secure resolvers.)
-
-        NOTE: Implementers might expect the above SHOULD to be a MUST.
-        However, local policy or the calling application may not require
-        the security services.
-
-     3. If SIG RRs are received in response to a user query explicitly
-        specifying the SIG type, no special processing is required.
-
-   If the message does not pass integrity checks or the SIG does not
-   check against the signed RRs, the SIG RR is invalid and should be
-   ignored.  If all of the SIG RR(s) purporting to authenticate an RRset
-   are invalid, then the RRset is not authenticated.
-
-   If the SIG RR is the last RR in a response in the additional
-   information section and has a type covered of zero, it is a
-   transaction signature of the response and the query that produced the
-   response.  It MAY be optionally checked and the message rejected if
-   the checks fail.  But even if the checks succeed, such a transaction
-   authentication SIG does NOT directly authenticate any RRs in the
-   message.  Only a proper SIG RR signed by the zone or a key tracing
-   its authority to the zone or to static resolver configuration can
-   directly authenticate RRs, depending on resolver policy (see Section
-   6).  If a resolver does not implement transaction and/or request
-   SIGs, it MUST ignore them without error.
-
-   If all checks indicate that the SIG RR is valid then RRs verified by
-   it should be considered authenticated.
-
-4.4 Signature Lifetime, Expiration, TTLs, and Validity
-
-   Security aware servers MUST NOT consider SIG RRs to authenticate
-   anything before their signature inception or after its expiration
-   time (see also Section 6).  Security aware servers MUST NOT consider
-   any RR to be authenticated after all its signatures have expired.
-   When a secure server caches authenticated data, if the TTL would
-   expire at a time further in the future than the authentication
-   expiration time, the server SHOULD trim the TTL in the cache entry
-   not to extent beyond the authentication expiration time.  Within
-   these constraints, servers should continue to follow DNS TTL aging.
-   Thus authoritative servers should continue to follow the zone refresh
-   and expire parameters and a non-authoritative server should count
-   down the TTL and discard RRs when the TTL is zero (even for a SIG
-   that has not yet reached its authentication expiration time).  In
-   addition, when RRs are transmitted in a query response, the TTL
-
-
-
-
-Eastlake                    Standards Track                    [Page 23]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   should be trimmed so that current time plus the TTL does not extend
-   beyond the authentication expiration time.  Thus, in general, the TTL
-   on a transmitted RR would be
-
-      min(authExpTim,max(zoneMinTTL,min(originalTTL,currentTTL)))
-
-   When signatures are generated, signature expiration times should be
-   set far enough in the future that it is quite certain that new
-   signatures can be generated before the old ones expire.  However,
-   setting expiration too far into the future could mean a long time to
-   flush any bad data or signatures that may have been generated.
-
-   It is recommended that signature lifetime be a small multiple of the
-   TTL (ie, 4 to 16 times the TTL) but not less than a reasonable
-   maximum re-signing interval and not less than the zone expiry time.
-
-5. Non-existent Names and Types
-
-   The SIG RR mechanism described in Section 4 above provides strong
-   authentication of RRs that exist in a zone.  But it is not clear
-   above how to verifiably deny the existence of a name in a zone or a
-   type for an existent name.
-
-   The nonexistence of a name in a zone is indicated by the NXT ("next")
-   RR for a name interval containing the nonexistent name. An NXT RR or
-   RRs and its or their SIG(s) are returned in the authority section,
-   along with the error, if the server is security aware.  The same is
-   true for a non-existent type under an existing name except that there
-   is no error indication other than an empty answer section
-   accompanying the NXT(s). This is a change in the existing standard
-   [RFCs 1034/1035] which contemplates only NS and SOA RRs in the
-   authority section. NXT RRs will also be returned if an explicit query
-   is made for the NXT type.
-
-   The existence of a complete set of NXT records in a zone means that
-   any query for any name and any type to a security aware server
-   serving the zone will result in an reply containing at least one
-   signed RR unless it is a query for delegation point NS or glue A or
-   AAAA RRs.
-
-5.1 The NXT Resource Record
-
-   The NXT resource record is used to securely indicate that RRs with an
-   owner name in a certain name interval do not exist in a zone and to
-   indicate what RR types are present for an existing name.
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 24]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   The owner name of the NXT RR is an existing name in the zone.  It's
-   RDATA is a "next" name and a type bit map. Thus the NXT RRs in a zone
-   create a chain of all of the literal owner names in that zone,
-   including unexpanded wildcards but omitting the owner name of glue
-   address records unless they would otherwise be included. This implies
-   a canonical ordering of all domain names in a zone as described in
-   Section 8. The presence of the NXT RR means that no name between its
-   owner name and the name in its RDATA area exists and that no other
-   types exist under its owner name.
-
-   There is a potential problem with the last NXT in a zone as it wants
-   to have an owner name which is the last existing name in canonical
-   order, which is easy, but it is not obvious what name to put in its
-   RDATA to indicate the entire remainder of the name space.  This is
-   handled by treating the name space as circular and putting the zone
-   name in the RDATA of the last NXT in a zone.
-
-   The NXT RRs for a zone SHOULD be automatically calculated and added
-   to the zone when SIGs are added.  The NXT RR's TTL SHOULD NOT exceed
-   the zone minimum TTL.
-
-   The type number for the NXT RR is 30.
-
-   NXT RRs are only signed by zone level keys.
-
-5.2 NXT RDATA Format
-
-   The RDATA for an NXT RR consists simply of a domain name followed by
-   a bit map, as shown below.
-
-                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                  next domain name                             /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                    type bit map                               /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   The NXT RR type bit map format currently defined is one bit per RR
-   type present for the owner name.  A one bit indicates that at least
-   one RR of that type is present for the owner name.  A zero indicates
-   that no such RR is present.  All bits not specified because they are
-   beyond the end of the bit map are assumed to be zero.  Note that bit
-   30, for NXT, will always be on so the minimum bit map length is
-   actually four octets. Trailing zero octets are prohibited in this
-   format.  The first bit represents RR type zero (an illegal type which
-   can not be present) and so will be zero in this format.  This format
-   is not used if there exists an RR with a type number greater than
-
-
-
-Eastlake                    Standards Track                    [Page 25]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   127.  If the zero bit of the type bit map is a one, it indicates that
-   a different format is being used which will always be the case if a
-   type number greater than 127 is present.
-
-   The domain name may be compressed with standard DNS name compression
-   when being transmitted over the network.  The size of the bit map can
-   be inferred from the RDLENGTH and the length of the next domain name.
-
-5.3 Additional Complexity Due to Wildcards
-
-   Proving that a non-existent name response is correct or that a
-   wildcard expansion response is correct makes things a little more
-   complex.
-
-   In particular, when a non-existent name response is returned, an NXT
-   must be returned showing that the exact name queried did not exist
-   and, in general, one or more additional NXT's need to be returned to
-   also prove that there wasn't a wildcard whose expansion should have
-   been returned. (There is no need to return multiple copies of the
-   same NXT.) These NXTs, if any, are returned in the authority section
-   of the response.
-
-   Furthermore, if a wildcard expansion is returned in a response, in
-   general one or more NXTs needs to also be returned in the authority
-   section to prove that no more specific name (including possibly more
-   specific wildcards in the zone) existed on which the response should
-   have been based.
-
-5.4 Example
-
-   Assume zone foo.nil has entries for
-
-          big.foo.nil,
-          medium.foo.nil.
-          small.foo.nil.
-          tiny.foo.nil.
-
-   Then a query to a security aware server for huge.foo.nil would
-   produce an error reply with an RCODE of NXDOMAIN and the authority
-   section data including something like the following:
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 26]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   foo.nil.    NXT big.foo.nil NS KEY SOA NXT ;prove no *.foo.nil
-   foo.nil.    SIG NXT 1 2 ( ;type-cov=NXT, alg=1, labels=2
-                    19970102030405 ;signature expiration
-                    19961211100908 ;signature inception
-                    2143           ;key identifier
-                    foo.nil.       ;signer
-   AIYADP8d3zYNyQwW2EM4wXVFdslEJcUx/fxkfBeH1El4ixPFhpfHFElxbvKoWmvjDTCm
-   fiYy2X+8XpFjwICHc398kzWsTMKlxovpz2FnCTM= ;signature (640 bits)
-                          )
-   big.foo.nil. NXT medium.foo.nil. A MX SIG NXT ;prove no huge.foo.nil
-   big.foo.nil. SIG NXT 1 3 ( ;type-cov=NXT, alg=1, labels=3
-                    19970102030405 ;signature expiration
-                    19961211100908 ;signature inception
-                    2143           ;key identifier
-                    foo.nil.       ;signer
-    MxFcby9k/yvedMfQgKzhH5er0Mu/vILz45IkskceFGgiWCn/GxHhai6VAuHAoNUz4YoU
-    1tVfSCSqQYn6//11U6Nld80jEeC8aTrO+KKmCaY= ;signature (640 bits)
-                             )
-   Note that this response implies that big.foo.nil is an existing name
-   in the zone and thus has other RR types associated with it than NXT.
-   However, only the NXT (and its SIG) RR appear in the response to this
-   query for huge.foo.nil, which is a non-existent name.
-
-5.5 Special Considerations at Delegation Points
-
-   A name (other than root) which is the head of a zone also appears as
-   the leaf in a superzone.  If both are secure, there will always be
-   two different NXT RRs with the same name.  They can be easily
-   distinguished by their signers, the next domain name fields, the
-   presence of the SOA type bit, etc.  Security aware servers should
-   return the correct NXT automatically when required to authenticate
-   the non-existence of a name and both NXTs, if available, on explicit
-   query for type NXT.
-
-   Non-security aware servers will never automatically return an NXT and
-   some old implementations may only return the NXT from the subzone on
-   explicit queries.
-
-5.6 Zone Transfers
-
-   The subsections below describe how full and incremental zone
-   transfers are secured.
-
-   SIG RRs secure all authoritative RRs transferred for both full and
-   incremental [RFC 1995] zone transfers.  NXT RRs are an essential
-   element in secure zone transfers and assure that every authoritative
-   name and type will be present; however, if there are multiple SIGs
-   with the same name and type covered, a subset of the SIGs could be
-
-
-
-Eastlake                    Standards Track                    [Page 27]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   sent as long as at least one is present and, in the case of unsigned
-   delegation point NS or glue A or AAAA RRs a subset of these RRs or
-   simply a modified set could be sent as long as at least one of each
-   type is included.
-
-   When an incremental or full zone transfer request is received with
-   the same or newer version number than that of the server's copy of
-   the zone, it is replied to with just the SOA RR of the server's
-   current version and the SIG RRset verifying that SOA RR.
-
-   The complete NXT chains specified in this document enable a resolver
-   to obtain, by successive queries chaining through NXTs, all of the
-   names in a zone even if zone transfers are prohibited.  Different
-   format NXTs may be specified in the future to avoid this.
-
-5.6.1 Full Zone Transfers
-
-   To provide server authentication that a complete transfer has
-   occurred, transaction authentication SHOULD be used on full zone
-   transfers.  This provides strong server based protection for the
-   entire zone in transit.
-
-5.6.2 Incremental Zone Transfers
-
-   Individual RRs in an incremental (IXFR) transfer [RFC 1995] can be
-   verified in the same way as for a full zone transfer and the
-   integrity of the NXT name chain and correctness of the NXT type bits
-   for the zone after the incremental RR deletes and adds can check each
-   disjoint area of the zone updated.  But the completeness of an
-   incremental transfer can not be confirmed because usually neither the
-   deleted RR section nor the added RR section has a compete zone NXT
-   chain.  As a result, a server which securely supports IXFR must
-   handle IXFR SIG RRs for each incremental transfer set that it
-   maintains.
-
-   The IXFR SIG is calculated over the incremental zone update
-   collection of RRs in the order in which it is transmitted: old SOA,
-   then deleted RRs, then new SOA and added RRs.  Within each section,
-   RRs must be ordered as specified in Section 8.  If condensation of
-   adjacent incremental update sets is done by the zone owner, the
-   original IXFR SIG for each set included in the condensation must be
-   discarded and a new on IXFR SIG calculated to cover the resulting
-   condensed set.
-
-   The IXFR SIG really belongs to the zone as a whole, not to the zone
-   name.  Although it SHOULD be correct for the zone name, the labels
-   field of an IXFR SIG is otherwise meaningless.  The IXFR SIG is only
-   sent as part of an incremental zone transfer.  After validation of
-
-
-
-Eastlake                    Standards Track                    [Page 28]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   the IXFR SIG, the transferred RRs MAY be considered valid without
-   verification of the internal SIGs if such trust in the server
-   conforms to local policy.
-
-6. How to Resolve Securely and the AD and CD Bits
-
-   Retrieving or resolving secure data from the Domain Name System (DNS)
-   involves starting with one or more trusted public keys that have been
-   staticly configured at the resolver.  With starting trusted keys, a
-   resolver willing to perform cryptography can progress securely
-   through the secure DNS structure to the zone of interest as described
-   in Section 6.3. Such trusted public keys would normally be configured
-   in a manner similar to that described in Section 6.2.  However, as a
-   practical matter, a security aware resolver would still gain some
-   confidence in the results it returns even if it was not configured
-   with any keys but trusted what it got from a local well known server
-   as if it were staticly configured.
-
-   Data stored at a security aware server needs to be internally
-   categorized as Authenticated, Pending, or Insecure. There is also a
-   fourth transient state of Bad which indicates that all SIG checks
-   have explicitly failed on the data. Such Bad data is not retained at
-   a security aware server. Authenticated means that the data has a
-   valid SIG under a KEY traceable via a chain of zero or more SIG and
-   KEY RRs allowed by the resolvers policies to a KEY staticly
-   configured at the resolver. Pending data has no authenticated SIGs
-   and at least one additional SIG the resolver is still trying to
-   authenticate.  Insecure data is data which it is known can never be
-   either Authenticated or found Bad in the zone where it was found
-   because it is in or has been reached via a unsecured zone or because
-   it is unsigned glue address or delegation point NS data. Behavior in
-   terms of control of and flagging based on such data labels is
-   described in Section 6.1.
-
-   The proper validation of signatures requires a reasonably secure
-   shared opinion of the absolute time between resolvers and servers as
-   described in Section 6.4.
-
-6.1 The AD and CD Header Bits
-
-   Two previously unused bits are allocated out of the DNS
-   query/response format header. The AD (authentic data) bit indicates
-   in a response that all the data included in the answer and authority
-   portion of the response has been authenticated by the server
-   according to the policies of that server. The CD (checking disabled)
-   bit indicates in a query that Pending (non-authenticated) data is
-   acceptable to the resolver sending the query.
-
-
-
-
-Eastlake                    Standards Track                    [Page 29]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   These bits are allocated from the previously must-be-zero Z field as
-   follows:
-
-                                           1  1  1  1  1  1
-             0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
-            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-            |                      ID                       |
-            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-            |QR|   Opcode  |AA|TC|RD|RA| Z|AD|CD|   RCODE   |
-            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-            |                    QDCOUNT                    |
-            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-            |                    ANCOUNT                    |
-            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-            |                    NSCOUNT                    |
-            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-            |                    ARCOUNT                    |
-            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-   These bits are zero in old servers and resolvers.  Thus the responses
-   of old servers are not flagged as authenticated to security aware
-   resolvers and queries from non-security aware resolvers do not assert
-   the checking disabled bit and thus will be answered by security aware
-   servers only with Authenticated or Insecure data. Security aware
-   resolvers MUST NOT trust the AD bit unless they trust the server they
-   are talking to and either have a secure path to it or use DNS
-   transaction security.
-
-   Any security aware resolver willing to do cryptography SHOULD assert
-   the CD bit on all queries to permit it to impose its own policies and
-   to reduce DNS latency time by allowing security aware servers to
-   answer with Pending data.
-
-   Security aware servers MUST NOT return Bad data.  For non-security
-   aware resolvers or security aware resolvers requesting service by
-   having the CD bit clear, security aware servers MUST return only
-   Authenticated or Insecure data in the answer and authority sections
-   with the AD bit set in the response. Security aware servers SHOULD
-   return Pending data, with the AD bit clear in the response, to
-   security aware resolvers requesting this service by asserting the CD
-   bit in their request.  The AD bit MUST NOT be set on a response
-   unless all of the RRs in the answer and authority sections of the
-   response are either Authenticated or Insecure.  The AD bit does not
-   cover the additional information section.
-
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 30]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-6.2 Staticly Configured Keys
-
-   The public key to authenticate a zone SHOULD be defined in local
-   configuration files before that zone is loaded at the primary server
-   so the zone can be authenticated.
-
-   While it might seem logical for everyone to start with a public key
-   associated with the root zone and staticly configure this in every
-   resolver, this has problems.  The logistics of updating every DNS
-   resolver in the world should this key ever change would be severe.
-   Furthermore, many organizations will explicitly wish their "interior"
-   DNS implementations to completely trust only their own DNS servers.
-   Interior resolvers of such organizations can then go through the
-   organization's zone servers to access data outside the organization's
-   domain and need not be configured with keys above the organization's
-   DNS apex.
-
-   Host resolvers that are not part of a larger organization may be
-   configured with a key for the domain of their local ISP whose
-   recursive secure DNS caching server they use.
-
-6.3 Chaining Through The DNS
-
-   Starting with one or more trusted keys for any zone, it should be
-   possible to retrieve signed keys for that zone's subzones which have
-   a key. A secure sub-zone is indicated by a KEY RR with non-null key
-   information appearing with the NS RRs in the sub-zone and which may
-   also be present in the parent.  These make it possible to descend
-   within the tree of zones.
-
-6.3.1 Chaining Through KEYs
-
-   In general, some RRset that you wish to validate in the secure DNS
-   will be signed by one or more SIG RRs.  Each of these SIG RRs has a
-   signer under whose name is stored the public KEY to use in
-   authenticating the SIG.  Each of those KEYs will, generally, also be
-   signed with a SIG.  And those SIGs will have signer names also
-   referring to KEYs.  And so on. As a result, authentication leads to
-   chains of alternating SIG and KEY RRs with the first SIG signing the
-   original data whose authenticity is to be shown and the final KEY
-   being some trusted key staticly configured at the resolver performing
-   the authentication.
-
-   In testing such a chain, the validity periods of the SIGs encountered
-   must be intersected to determine the validity period of the
-   authentication of the data, a purely algorithmic process. In
-   addition, the validation of each SIG over the data with reference to
-   a KEY must meet the objective cryptographic test implied by the
-
-
-
-Eastlake                    Standards Track                    [Page 31]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   cryptographic algorithm used (although even here the resolver may
-   have policies as to trusted algorithms and key lengths).  Finally,
-   the judgement that a SIG with a particular signer name can
-   authenticate data (possibly a KEY RRset) with a particular owner
-   name, is primarily a policy question.  Ultimately, this is a policy
-   local to the resolver and any clients that depend on that resolver's
-   decisions.  It is, however, recommended, that the policy below be
-   adopted:
-
-        Let A < B mean that A is a shorter domain name than B formed by
-        dropping one or more whole labels from the left end of B, i.e.,
-        A is a direct or indirect superdomain of B.  Let A = B mean that
-        A and B are the same domain name (i.e., are identical after
-        letter case canonicalization).  Let A > B mean that A is a
-        longer domain name than B formed by adding one or more whole
-        labels on the left end of B, i.e., A is a direct or indirect
-        subdomain of B
-
-        Let Static be the owner names of the set of staticly configured
-        trusted keys at a resolver.
-
-        Then Signer is a valid signer name for a SIG authenticating an
-        RRset (possibly a KEY RRset) with owner name Owner at the
-        resolver if any of the following three rules apply:
-
-        (1) Owner > or = Signer (except that if Signer is root, Owner
-        must be root or a top level domain name).  That is, Owner is the
-        same as or a subdomain of Signer.
-
-        (2) ( Owner < Signer ) and ( Signer > or = some Static ).  That
-        is, Owner is a superdomain of Signer and Signer is staticly
-        configured or a subdomain of a staticly configured key.
-
-        (3) Signer = some Static.  That is, the signer is exactly some
-        staticly configured key.
-
-   Rule 1 is the rule for descending the DNS tree and includes a special
-   prohibition on the root zone key due to the restriction that the root
-   zone be only one label deep.  This is the most fundamental rule.
-
-   Rule 2 is the rule for ascending the DNS tree from one or more
-   staticly configured keys.  Rule 2 has no effect if only root zone
-   keys are staticly configured.
-
-   Rule 3 is a rule permitting direct cross certification.  Rule 3 has
-   no effect if only root zone keys are staticly configured.
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 32]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   Great care should be taken that the consequences have been fully
-   considered before making any local policy adjustments to these rules
-   (other than dispensing with rules 2 and 3 if only root zone keys are
-   staticly configured).
-
-6.3.2 Conflicting Data
-
-   It is possible that there will be multiple SIG-KEY chains that appear
-   to authenticate conflicting RRset answers to the same query.  A
-   resolver should choose only the most reliable answer to return and
-   discard other data.  This choice of most reliable is a matter of
-   local policy which could take into account differing trust in
-   algorithms, key sizes, staticly configured keys, zones traversed,
-   etc.  The technique given below is recommended for taking into
-   account SIG-KEY chain length.
-
-   A resolver should keep track of the number of successive secure zones
-   traversed from a staticly configured key starting point to any secure
-   zone it can reach.  In general, the lower such a distance number is,
-   the greater the confidence in the data.  Staticly configured data
-   should be given a distance number of zero.  If a query encounters
-   different Authenticated data for the same query with different
-   distance values, that with a larger value should be ignored unless
-   some other local policy covers the case.
-
-   A security conscious resolver should completely refuse to step from a
-   secure zone into a unsecured zone unless the unsecured zone is
-   certified to be non-secure by the presence of an authenticated KEY RR
-   for the unsecured zone with the no-key type value.  Otherwise the
-   resolver is getting bogus or spoofed data.
-
-   If legitimate unsecured zones are encountered in traversing the DNS
-   tree, then no zone can be trusted as secure that can be reached only
-   via information from such non-secure zones. Since the unsecured zone
-   data could have been spoofed, the "secure" zone reached via it could
-   be counterfeit.  The "distance" to data in such zones or zones
-   reached via such zones could be set to 256 or more as this exceeds
-   the largest possible distance through secure zones in the DNS.
-
-6.4 Secure Time
-
-   Coordinated interpretation of the time fields in SIG RRs requires
-   that reasonably consistent time be available to the hosts
-   implementing the DNS security extensions.
-
-   A variety of time synchronization protocols exist including the
-   Network Time Protocol (NTP [RFC 1305, 2030]).  If such protocols are
-   used, they MUST be used securely so that time can not be spoofed.
-
-
-
-Eastlake                    Standards Track                    [Page 33]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   Otherwise, for example, a host could get its clock turned back and
-   might then believe old SIG RRs, and the data they authenticate, which
-   were valid but are no longer.
-
-7. ASCII Representation of Security RRs
-
-   This section discusses the format for master file and other ASCII
-   presentation of the three DNS security resource records.
-
-   The algorithm field in KEY and SIG RRs can be represented as either
-   an unsigned integer or symbolicly.  The following initial symbols are
-   defined as indicated:
-
-        Value  Symbol
-
-        001    RSAMD5
-        002    DH
-        003    DSA
-        004    ECC
-        252    INDIRECT
-        253    PRIVATEDNS
-        254    PRIVATEOID
-
-7.1 Presentation of KEY RRs
-
-   KEY RRs may appear as single logical lines in a zone data master file
-   [RFC 1033].
-
-   The flag field is represented as an unsigned integer or a sequence of
-   mnemonics as follows separated by instances of the verticle bar ("|")
-   character:
-
-     BIT  Mnemonic  Explanation
-    0-1           key type
-        NOCONF    =1 confidentiality use prohibited
-        NOAUTH    =2 authentication use prohibited
-        NOKEY     =3 no key present
-    2   FLAG2     - reserved
-    3   EXTEND    flags extension
-    4   FLAG4     - reserved
-    5   FLAG5     - reserved
-    6-7           name type
-        USER      =0 (default, may be omitted)
-        ZONE      =1
-        HOST      =2 (host or other end entity)
-        NTYP3     - reserved
-    8   FLAG8     - reserved
-    9   FLAG9     - reserved
-
-
-
-Eastlake                    Standards Track                    [Page 34]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   10   FLAG10    - reserved
-   11   FLAG11    - reserved
-   12-15          signatory field, values 0 to 15
-            can be represented by SIG0, SIG1, ... SIG15
-
-   No flag mnemonic need be present if the bit or field it represents is
-   zero.
-
-   The protocol octet can be represented as either an unsigned integer
-   or symbolicly.  The following initial symbols are defined:
-
-        000    NONE
-        001    TLS
-        002    EMAIL
-        003    DNSSEC
-        004    IPSEC
-        255    ALL
-
-   Note that if the type flags field has the NOKEY value, nothing
-   appears after the algorithm octet.
-
-   The remaining public key portion is represented in base 64 (see
-   Appendix A) and may be divided up into any number of white space
-   separated substrings, down to single base 64 digits, which are
-   concatenated to obtain the full signature.  These substrings can span
-   lines using the standard parenthesis.
-
-   Note that the public key may have internal sub-fields but these do
-   not appear in the master file representation.  For example, with
-   algorithm 1 there is a public exponent size, then a public exponent,
-   and then a modulus.  With algorithm 254, there will be an OID size,
-   an OID, and algorithm dependent information. But in both cases only a
-   single logical base 64 string will appear in the master file.
-
-7.2 Presentation of SIG RRs
-
-   A data SIG RR may be represented as a single logical line in a zone
-   data file [RFC 1033] but there are some special considerations as
-   described below.  (It does not make sense to include a transaction or
-   request authenticating SIG RR in a file as they are a transient
-   authentication that covers data including an ephemeral transaction
-   number and so must be calculated in real time.)
-
-   There is no particular problem with the signer, covered type, and
-   times.  The time fields appears in the form YYYYMMDDHHMMSS where YYYY
-   is the year, the first MM is the month number (01-12), DD is the day
-   of the month (01-31), HH is the hour in 24 hours notation (00-23),
-   the second MM is the minute (00-59), and SS is the second (00-59).
-
-
-
-Eastlake                    Standards Track                    [Page 35]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   The original TTL field appears as an unsigned integer.
-
-   If the original TTL, which applies to the type signed, is the same as
-   the TTL of the SIG RR itself, it may be omitted.  The date field
-   which follows it is larger than the maximum possible TTL so there is
-   no ambiguity.
-
-   The "labels" field appears as an unsigned integer.
-
-   The key tag appears as an unsigned number.
-
-   However, the signature itself can be very long.  It is the last data
-   field and is represented in base 64 (see Appendix A) and may be
-   divided up into any number of white space separated substrings, down
-   to single base 64 digits, which are concatenated to obtain the full
-   signature.  These substrings can be split between lines using the
-   standard parenthesis.
-
-7.3 Presentation of NXT RRs
-
-   NXT RRs do not appear in original unsigned zone master files since
-   they should be derived from the zone as it is being signed.  If a
-   signed file with NXTs added is printed or NXTs are printed by
-   debugging code, they appear as the next domain name followed by the
-   RR type present bits as an unsigned interger or sequence of RR
-   mnemonics.
-
-8. Canonical Form and Order of Resource Records
-
-   This section specifies, for purposes of domain name system (DNS)
-   security, the canonical form of resource records (RRs), their name
-   order, and their overall order.  A canonical name order is necessary
-   to construct the NXT name chain.  A canonical form and ordering
-   within an RRset is necessary in consistently constructing and
-   verifying SIG RRs.  A canonical ordering of types within a name is
-   required in connection with incremental transfer (Section 5.6.2).
-
-8.1 Canonical RR Form
-
-   For purposes of DNS security, the canonical form for an RR is the
-   wire format of the RR with domain names (1) fully expanded (no name
-   compression via pointers), (2) all domain name letters set to lower
-   case, (3) owner name wild cards in master file form (no substitution
-   made for *), and (4) the original TTL substituted for the current
-   TTL.
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 36]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-8.2 Canonical DNS Name Order
-
-   For purposes of DNS security, the canonical ordering of owner names
-   is to sort individual labels as unsigned left justified octet strings
-   where the absence of a octet sorts before a zero value octet and
-   upper case letters are treated as lower case letters.  Names in a
-   zone are sorted by sorting on the highest level label and then,
-   within those names with the same highest level label by the next
-   lower label, etc. down to leaf node labels.  Within a zone, the zone
-   name itself always exists and all other names are the zone name with
-   some prefix of lower level labels.  Thus the zone name itself always
-   sorts first.
-
-   Example:
-          foo.example
-          a.foo.example
-          yljkjljk.a.foo.example
-          Z.a.foo.example
-          zABC.a.FOO.EXAMPLE
-          z.foo.example
-          *.z.foo.example
-          \200.z.foo.example
-
-8.3 Canonical RR Ordering Within An RRset
-
-   Within any particular owner name and type, RRs are sorted by RDATA as
-   a left justified unsigned octet sequence where the absence of an
-   octet sorts before the zero octet.
-
-8.4 Canonical Ordering of RR Types
-
-   When RRs of the same name but different types must be ordered, they
-   are ordered by type, considering the type to be an unsigned integer,
-   except that SIG RRs are placed immediately after the type they cover.
-   Thus, for example, an A record would be put before an MX record
-   because A is type 1 and MX is type 15 but if both were signed, the
-   order would be A < SIG(A) < MX < SIG(MX).
-
-9. Conformance
-
-   Levels of server and resolver conformance are defined below.
-
-9.1 Server Conformance
-
-   Two levels of server conformance for DNS security are defined as
-   follows:
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 37]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   BASIC:  Basic server compliance is the ability to store and retrieve
-   (including zone transfer) SIG, KEY, and NXT RRs.  Any secondary or
-   caching server for a secure zone MUST have at least basic compliance
-   and even then some things, such as secure CNAMEs, will not work
-   without full compliance.
-
-   FULL:  Full server compliance adds the following to basic compliance:
-   (1) ability to read SIG, KEY, and NXT RRs in zone files and (2)
-   ability, given a zone file and private key, to add appropriate SIG
-   and NXT RRs, possibly via a separate application, (3) proper
-   automatic inclusion of SIG, KEY, and NXT RRs in responses, (4)
-   suppression of CNAME following on retrieval of the security type RRs,
-   (5) recognize the CD query header bit and set the AD query header
-   bit, as appropriate, and (6) proper handling of the two NXT RRs at
-   delegation points.  Primary servers for secure zones MUST be fully
-   compliant and for complete secure operation, all secondary, caching,
-   and other servers handling the zone SHOULD be fully compliant as
-   well.
-
-9.2 Resolver Conformance
-
-   Two levels of resolver compliance (including the resolver portion of
-   a server) are defined for DNS Security:
-
-   BASIC: A basic compliance resolver can handle SIG, KEY, and NXT RRs
-   when they are explicitly requested.
-
-   FULL: A fully compliant resolver (1) understands KEY, SIG, and NXT
-   RRs including verification of SIGs at least for the mandatory
-   algorithm, (2) maintains appropriate information in its local caches
-   and database to indicate which RRs have been authenticated and to
-   what extent they have been authenticated, (3) performs additional
-   queries as necessary to attempt to obtain KEY, SIG, or NXT RRs when
-   needed, (4) normally sets the CD query header bit on its queries.
-
-10. Security Considerations
-
-   This document specifies extensions to the Domain Name System (DNS)
-   protocol to provide data integrity and data origin authentication,
-   public key distribution, and optional transaction and request
-   security.
-
-   It should be noted that, at most, these extensions guarantee the
-   validity of resource records, including KEY resource records,
-   retrieved from the DNS.  They do not magically solve other security
-   problems.  For example, using secure DNS you can have high confidence
-   in the IP address you retrieve for a host name; however, this does
-   not stop someone for substituting an unauthorized host at that
-
-
-
-Eastlake                    Standards Track                    [Page 38]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   address or capturing packets sent to that address and falsely
-   responding with packets apparently from that address.  Any reasonably
-   complete security system will require the protection of many
-   additional facets of the Internet beyond DNS.
-
-   The implementation of NXT RRs as described herein enables a resolver
-   to determine all the names in a zone even if zone transfers are
-   prohibited (section 5.6).  This is an active area of work and may
-   change.
-
-   A number of precautions in DNS implementation have evolved over the
-   years to harden the insecure DNS against spoofing.  These precautions
-   should not be abandoned but should be considered to provide
-   additional protection in case of key compromise in secure DNS.
-
-11. IANA Considerations
-
-   KEY RR flag bits 2 and 8-11 and all flag extension field bits can be
-   assigned by IETF consensus as defined in RFC 2434.  The remaining
-   values of the NAMTYP flag field and flag bits 4 and 5 (which could
-   conceivably become an extension of the NAMTYP field) can only be
-   assigned by an IETF Standards Action [RFC 2434].
-
-   Algorithm numbers 5 through 251 are available for assignment should
-   sufficient reason arise.  However, the designation of a new algorithm
-   could have a major impact on interoperability and requires an IETF
-   Standards Action [RFC 2434].  The existence of the private algorithm
-   types 253 and 254 should satify most needs for private or proprietary
-   algorithms.
-
-   Additional values of the Protocol Octet (5-254) can be assigned by
-   IETF Consensus [RFC 2434].
-
-   The meaning of the first bit of the NXT RR "type bit map" being a one
-   can only be assigned by a standards action.
-
-References
-
-   [RFC 1033]  Lottor, M., "Domain Administrators Operations Guide", RFC
-               1033, November 1987.
-
-   [RFC 1034]  Mockapetris, P., "Domain Names - Concepts and
-               Facilities", STD 13, RFC 1034, November 1987.
-
-   [RFC 1035]  Mockapetris, P., "Domain Names - Implementation and
-               Specifications", STD 13, RFC 1035, November 1987.
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 39]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   [RFC 1305]  Mills, D., "Network Time Protocol (v3)", RFC 1305, March
-               1992.
-
-   [RFC 1530]  Malamud, C. and M. Rose, "Principles of Operation for the
-               TPC.INT Subdomain: General Principles and Policy", RFC
-               1530, October 1993.
-
-   [RFC 2401]  Kent, S. and R. Atkinson, "Security Architecture for the
-               Internet Protocol", RFC 2401, November 1998.
-
-   [RFC 1982]  Elz, R. and R. Bush, "Serial Number Arithmetic", RFC
-               1982, September 1996.
-
-   [RFC 1995]  Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
-               August 1996.
-
-   [RFC 2030]  Mills, D., "Simple Network Time Protocol (SNTP) Version 4
-               for IPv4, IPv6 and OSI", RFC 2030, October 1996.
-
-   [RFC 2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
-               Extensions (MIME) Part One: Format of Internet Message
-               Bodies", RFC 2045, November 1996.
-
-   [RFC 2065]  Eastlake, D. and C. Kaufman, "Domain Name System Security
-               Extensions", RFC 2065, January 1997.
-
-   [RFC 2119]  Bradner, S., "Key words for use in RFCs to Indicate
-               Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC 2136]  Vixie, P., Thomson, S., Rekhter, Y. and J. Bound,
-               "Dynamic Updates in the Domain Name System (DNS UPDATE)",
-               RFC 2136, April 1997.
-
-   [RFC 2137]  Eastlake, D., "Secure Domain Name System Dynamic Update",
-               RFC 2137, April 1997.
-
-   [RFC 2181]  Elz, R. and R. Bush, "Clarifications to the DNS
-               Specification", RFC 2181, July 1997.
-
-   [RFC 2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
-               IANA Considerations Section in RFCs", BCP 26, RFC 2434,
-               October 1998.
-
-   [RFC 2537]  Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name
-               System (DNS)", RFC 2537, March 1999.
-
-   [RFC 2539]  Eastlake, D., "Storage of Diffie-Hellman Keys in the
-               Domain Name System (DNS)", RFC 2539, March 1999.
-
-
-
-Eastlake                    Standards Track                    [Page 40]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   [RFC 2536]  Eastlake, D., "DSA KEYs and SIGs in the Domain Name
-               System (DNS)", RFC 2536, March 1999.
-
-   [RFC 2538]  Eastlake, D. and O. Gudmundsson, "Storing Certificates in
-               the Domain Name System", RFC 2538, March 1999.
-
-   [RFC 2541]  Eastlake, D., "DNS Operational Security Considerations",
-               RFC 2541, March 1999.
-
-   [RSA FAQ] - RSADSI Frequently Asked Questions periodic posting.
-
-Author's Address
-
-   Donald E. Eastlake 3rd
-   IBM
-   65 Shindegan Hill Road
-   RR #1
-   Carmel, NY 10512
-
-   Phone:   +1-914-784-7913 (w)
-            +1-914-276-2668 (h)
-   Fax:     +1-914-784-3833 (w-fax)
-   EMail:   dee3@us.ibm.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 41]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-Appendix A: Base 64 Encoding
-
-   The following encoding technique is taken from [RFC 2045] by N.
-   Borenstein and N. Freed.  It is reproduced here in an edited form for
-   convenience.
-
-   A 65-character subset of US-ASCII is used, enabling 6 bits to be
-   represented per printable character. (The extra 65th character, "=",
-   is used to signify a special processing function.)
-
-   The encoding process represents 24-bit groups of input bits as output
-   strings of 4 encoded characters. Proceeding from left to right, a
-   24-bit input group is formed by concatenating 3 8-bit input groups.
-   These 24 bits are then treated as 4 concatenated 6-bit groups, each
-   of which is translated into a single digit in the base 64 alphabet.
-
-   Each 6-bit group is used as an index into an array of 64 printable
-   characters. The character referenced by the index is placed in the
-   output string.
-
-                         Table 1: The Base 64 Alphabet
-
-      Value Encoding  Value Encoding  Value Encoding  Value Encoding
-          0 A            17 R            34 i            51 z
-          1 B            18 S            35 j            52 0
-          2 C            19 T            36 k            53 1
-          3 D            20 U            37 l            54 2
-          4 E            21 V            38 m            55 3
-          5 F            22 W            39 n            56 4
-          6 G            23 X            40 o            57 5
-          7 H            24 Y            41 p            58 6
-          8 I            25 Z            42 q            59 7
-          9 J            26 a            43 r            60 8
-         10 K            27 b            44 s            61 9
-         11 L            28 c            45 t            62 +
-         12 M            29 d            46 u            63 /
-         13 N            30 e            47 v
-         14 O            31 f            48 w         (pad) =
-         15 P            32 g            49 x
-         16 Q            33 h            50 y
-
-   Special processing is performed if fewer than 24 bits are available
-   at the end of the data being encoded.  A full encoding quantum is
-   always completed at the end of a quantity.  When fewer than 24 input
-   bits are available in an input group, zero bits are added (on the
-   right) to form an integral number of 6-bit groups.  Padding at the
-   end of the data is performed using the '=' character.  Since all base
-   64 input is an integral number of octets, only the following cases
-
-
-
-Eastlake                    Standards Track                    [Page 42]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   can arise: (1) the final quantum of encoding input is an integral
-   multiple of 24 bits; here, the final unit of encoded output will be
-   an integral multiple of 4 characters with no "=" padding, (2) the
-   final quantum of encoding input is exactly 8 bits; here, the final
-   unit of encoded output will be two characters followed by two "="
-   padding characters, or (3) the final quantum of encoding input is
-   exactly 16 bits; here, the final unit of encoded output will be three
-   characters followed by one "=" padding character.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 43]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-Appendix B: Changes from RFC 2065
-
-   This section summarizes the most important changes that have been
-   made since RFC 2065.
-
-   1. Most of Section 7 of [RFC 2065] called "Operational
-      Considerations", has been removed and may be made into a separate
-      document [RFC 2541].
-
-   2. The KEY RR has been changed by (2a) eliminating the "experimental"
-      flag as unnecessary, (2b) reserving a flag  bit for flags
-      expansion, (2c) more compactly encoding a number of bit fields in
-      such a way as to leave unchanged bits actually used by the limited
-      code currently deployed, (2d) eliminating the IPSEC and email flag
-      bits which are replaced by values of the protocol field and adding
-      a protocol field value for DNS security itself, (2e) adding
-      material to indicate that zone KEY RRs occur only at delegation
-      points, and (2f) removing the description of the RSA/MD5 algorithm
-      to a separate document [RFC 2537].  Section 3.4 describing the
-      meaning of various combinations of "no-key" and key present KEY
-      RRs has been added and the secure / unsecure status of a zone has
-      been clarified as being per algorithm.
-
-   3. The SIG RR has been changed by (3a) renaming the "time signed"
-      field to be the "signature inception" field, (3b) clarifying that
-      signature expiration and inception use serial number ring
-      arithmetic, (3c) changing the definition of the key footprint/tag
-      for algorithms other than 1 and adding Appendix C to specify its
-      calculation.  In addition, the SIG covering type AXFR has been
-      eliminated while one covering IXFR [RFC 1995] has been added (see
-      section 5.6).
-
-   4. Algorithm 3, the DSA algorithm, is now designated as the mandatory
-      to implement algorithm.  Algorithm 1, the RSA/MD5 algorithm, is
-      now a recommended option.  Algorithm 2 and 4 are designated as the
-      Diffie-Hellman key and elliptic cryptography algorithms
-      respectively, all to be defined in separate documents. Algorithm
-      code point 252 is designated to indicate "indirect" keys, to be
-      defined in a separate document, where the actual key is elsewhere.
-      Both the KEY and SIG RR definitions have been simplified by
-      eliminating the "null" algorithm 253 as defined in [RFC 2065].
-      That algorithm had been included because at the time it was
-      thought it might be useful in DNS dynamic update [RFC 2136]. It
-      was in fact not so used and it is dropped to simplify DNS
-      security.  Howver, that algorithm number has been re-used to
-      indicate private algorithms where a domain name specifies the
-      algorithm.
-
-
-
-
-Eastlake                    Standards Track                    [Page 44]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   5. The NXT RR has been changed so that (5a) the NXT RRs in a zone
-      cover all names, including wildcards as literal names without
-      expansion, except for glue address records whose names would not
-      otherwise appear, (5b) all NXT bit map areas whose first octet has
-      bit zero set have been reserved for future definition, (5c) the
-      number of and circumstances under which an NXT must be returned in
-      connection with wildcard names has been extended, and (5d) in
-      connection with the bit map, references to the WKS RR have been
-      removed and verticle bars ("|") have been added between the RR
-      type mnemonics in the ASCII representation.
-
-   6. Information on the canonical form and ordering of RRs has been
-      moved into a separate Section 8.
-
-   7. A subsection covering incremental and full zone transfer has been
-      added in Section 5.
-
-   8. Concerning DNS chaining: Further specification and policy
-      recommendations on secure resolution have been added, primarily in
-      Section 6.3.1.  It is now clearly stated that authenticated data
-      has a validity period of the intersection of the validity periods
-      of the SIG RRs in its authentication chain.  The requirement to
-      staticly configure a superzone's key signed by a zone in all of
-      the zone's authoritative servers has been removed.  The
-      recommendation to continue DNS security checks in a secure island
-      of DNS data that is separated from other parts of the DNS tree by
-      insecure zones and does not contain a zone for which a key has
-      been staticly configured was dropped.
-
-   9. It was clarified that the presence of the AD bit in a response
-      does not apply to the additional information section or to glue
-      address or delegation point NS RRs.  The AD bit only indicates
-      that the answer and authority sections of the response are
-      authoritative.
-
-   10. It is now required that KEY RRs and NXT RRs be signed only with
-       zone-level keys.
-
-   11.  Add IANA Considerations section and references to RFC 2434.
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 45]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-Appendix C: Key Tag Calculation
-
-   The key tag field in the SIG RR is just a means of more efficiently
-   selecting the correct KEY RR to use when there is more than one KEY
-   RR candidate available, for example, in verifying a signature.  It is
-   possible for more than one candidate key to have the same tag, in
-   which case each must be tried until one works or all fail.  The
-   following reference implementation of how to calculate the Key Tag,
-   for all algorithms other than algorithm 1, is in ANSI C.  It is coded
-   for clarity, not efficiency.  (See section 4.1.6 for how to determine
-   the Key Tag of an algorithm 1 key.)
-
-   /* assumes int is at least 16 bits
-      first byte of the key tag is the most significant byte of return
-      value
-      second byte of the key tag is the least significant byte of
-      return value
-      */
-
-   int keytag (
-
-           unsigned char key[],  /* the RDATA part of the KEY RR */
-           unsigned int keysize, /* the RDLENGTH */
-           )
-   {
-   long int    ac;    /* assumed to be 32 bits or larger */
-
-   for ( ac = 0, i = 0; i < keysize; ++i )
-       ac += (i&1) ? key[i] : key[i]<<8;
-   ac += (ac>>16) & 0xFFFF;
-   return ac & 0xFFFF;
-   }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 46]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 47]
-
diff --git a/contrib/bind9/doc/rfc/rfc2536.txt b/contrib/bind9/doc/rfc/rfc2536.txt
deleted file mode 100644
index 88be242..0000000
--- a/contrib/bind9/doc/rfc/rfc2536.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        D. EastLake
-Request for Comments: 2536                                           IBM
-Category: Standards Track                                     March 1999
-
-
-           DSA KEYs and SIGs in the Domain Name System (DNS)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-Abstract
-
-   A standard method for storing US Government Digital Signature
-   Algorithm keys and signatures in the Domain Name System is described
-   which utilizes DNS KEY and SIG resource records.
-
-Table of Contents
-
-   Abstract...................................................1
-   1. Introduction............................................1
-   2. DSA KEY Resource Records................................2
-   3. DSA SIG Resource Records................................3
-   4. Performance Considerations..............................3
-   5. Security Considerations.................................4
-   6. IANA Considerations.....................................4
-   References.................................................5
-   Author's Address...........................................5
-   Full Copyright Statement...................................6
-
-1. Introduction
-
-   The Domain Name System (DNS) is the global hierarchical replicated
-   distributed database system for Internet addressing, mail proxy, and
-   other information. The DNS has been extended to include digital
-   signatures and cryptographic keys as described in [RFC 2535].  Thus
-   the DNS can now be secured and can be used for secure key
-   distribution.
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 1]
-
-RFC 2536                     DSA in the DNS                   March 1999
-
-
-   This document describes how to store US Government Digital Signature
-   Algorithm (DSA) keys and signatures in the DNS.  Familiarity with the
-   US Digital Signature Algorithm is assumed [Schneier].  Implementation
-   of DSA is mandatory for DNS security.
-
-2. DSA KEY Resource Records
-
-   DSA public keys are stored in the DNS as KEY RRs using algorithm
-   number 3 [RFC 2535].  The structure of the algorithm specific portion
-   of the RDATA part of this RR is as shown below.  These fields, from Q
-   through Y are the "public key" part of the DSA KEY RR.
-
-   The period of key validity is not in the KEY RR but is indicated by
-   the SIG RR(s) which signs and authenticates the KEY RR(s) at that
-   domain name.
-
-           Field     Size
-           -----     ----
-            T         1  octet
-            Q        20  octets
-            P        64 + T*8  octets
-            G        64 + T*8  octets
-            Y        64 + T*8  octets
-
-   As described in [FIPS 186] and [Schneier]: T is a key size parameter
-   chosen such that 0 <= T <= 8.  (The meaning for algorithm 3 if the T
-   octet is greater than 8 is reserved and the remainder of the RDATA
-   portion may have a different format in that case.)  Q is a prime
-   number selected at key generation time such that 2**159 < Q < 2**160
-   so Q is always 20 octets long and, as with all other fields, is
-   stored in "big-endian" network order.  P, G, and Y are calculated as
-   directed by the FIPS 186 key generation algorithm [Schneier].  P is
-   in the range 2**(511+64T) < P < 2**(512+64T) and so is 64 + 8*T
-   octets long.  G and Y are quantities modulus P and so can be up to
-   the same length as P and are allocated fixed size fields with the
-   same number of octets as P.
-
-   During the key generation process, a random number X must be
-   generated such that 1 <= X <= Q-1.  X is the private key and is used
-   in the final step of public key generation where Y is computed as
-
-             Y = G**X mod P
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 2]
-
-RFC 2536                     DSA in the DNS                   March 1999
-
-
-3. DSA SIG Resource Records
-
-   The signature portion of the SIG RR RDATA area, when using the US
-   Digital Signature Algorithm, is shown below with fields in the order
-   they occur.  See [RFC 2535] for fields in the SIG RR RDATA which
-   precede the signature itself.
-
-           Field     Size
-           -----     ----
-            T         1 octet
-            R        20 octets
-            S        20 octets
-
-   The data signed is determined as specified in [RFC 2535].  Then the
-   following steps are taken, as specified in [FIPS 186], where Q, P, G,
-   and Y are as specified in the public key [Schneier]:
-
-           hash = SHA-1 ( data )
-
-           Generate a random K such that 0 < K < Q.
-
-           R = ( G**K mod P ) mod Q
-
-           S = ( K**(-1) * (hash + X*R) ) mod Q
-
-   Since Q is 160 bits long, R and S can not be larger than 20 octets,
-   which is the space allocated.
-
-   T is copied from the public key.  It is not logically necessary in
-   the SIG but is present so that values of T > 8 can more conveniently
-   be used as an escape for extended versions of DSA or other algorithms
-   as later specified.
-
-4. Performance Considerations
-
-   General signature generation speeds are roughly the same for RSA [RFC
-   2537] and DSA.  With sufficient pre-computation, signature generation
-   with DSA is faster than RSA.  Key generation is also faster for DSA.
-   However, signature verification is an order of magnitude slower than
-   RSA when the RSA public exponent is chosen to be small as is
-   recommended for KEY RRs used in domain name system (DNS) data
-   authentication.
-
-   Current DNS implementations are optimized for small transfers,
-   typically less than 512 bytes including overhead.  While larger
-   transfers will perform correctly and work is underway to make larger
-   transfers more efficient, it is still advisable at this time to make
-   reasonable efforts to minimize the size of KEY RR sets stored within
-
-
-
-Eastlake                    Standards Track                     [Page 3]
-
-RFC 2536                     DSA in the DNS                   March 1999
-
-
-   the DNS consistent with adequate security.  Keep in mind that in a
-   secure zone, at least one authenticating SIG RR will also be
-   returned.
-
-5. Security Considerations
-
-   Many of the general security consideration in [RFC 2535] apply.  Keys
-   retrieved from the DNS should not be trusted unless (1) they have
-   been securely obtained from a secure resolver or independently
-   verified by the user and (2) this secure resolver and secure
-   obtainment or independent verification conform to security policies
-   acceptable to the user.  As with all cryptographic algorithms,
-   evaluating the necessary strength of the key is essential and
-   dependent on local policy.
-
-   The key size limitation of a maximum of 1024 bits ( T = 8 ) in the
-   current DSA standard may limit the security of DSA.  For particularly
-   critical applications, implementors are encouraged to consider the
-   range of available algorithms and key sizes.
-
-   DSA assumes the ability to frequently generate high quality random
-   numbers.  See [RFC 1750] for guidance.  DSA is designed so that if
-   manipulated rather than random numbers are used, very high bandwidth
-   covert channels are possible.  See [Schneier] and more recent
-   research.  The leakage of an entire DSA private key in only two DSA
-   signatures has been demonstrated.  DSA provides security only if
-   trusted implementations, including trusted random number generation,
-   are used.
-
-6. IANA Considerations
-
-   Allocation of meaning to values of the T parameter that are not
-   defined herein requires an IETF standards actions.  It is intended
-   that values unallocated herein be used to cover future extensions of
-   the DSS standard.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 4]
-
-RFC 2536                     DSA in the DNS                   March 1999
-
-
-References
-
-   [FIPS 186]   U.S. Federal Information Processing Standard: Digital
-                Signature Standard.
-
-   [RFC 1034]   Mockapetris, P., "Domain Names - Concepts and
-                Facilities", STD 13, RFC 1034, November 1987.
-
-   [RFC 1035]   Mockapetris, P., "Domain Names - Implementation and
-                Specification", STD 13, RFC 1035, November 1987.
-
-   [RFC 1750]   Eastlake, D., Crocker, S. and J. Schiller, "Randomness
-                Recommendations for Security", RFC 1750, December 1994.
-
-   [RFC 2535]   Eastlake, D., "Domain Name System Security Extensions",
-                RFC 2535, March 1999.
-
-   [RFC 2537]   Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name
-                System (DNS)", RFC 2537, March 1999.
-
-   [Schneier]   Schneier, B., "Applied Cryptography Second Edition:
-                protocols, algorithms, and source code in C", 1996.
-
-Author's Address
-
-   Donald E. Eastlake 3rd
-   IBM
-   65 Shindegan Hill Road, RR #1
-   Carmel, NY 10512
-
-   Phone:   +1-914-276-2668(h)
-            +1-914-784-7913(w)
-   Fax:     +1-914-784-3833(w)
-   EMail:   dee3@us.ibm.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 5]
-
-RFC 2536                     DSA in the DNS                   March 1999
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 6]
-
diff --git a/contrib/bind9/doc/rfc/rfc2537.txt b/contrib/bind9/doc/rfc/rfc2537.txt
deleted file mode 100644
index cb75cf5..0000000
--- a/contrib/bind9/doc/rfc/rfc2537.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        D. Eastlake
-Request for Comments: 2537                                           IBM
-Category: Standards Track                                     March 1999
-
-
-         RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-Abstract
-
-   A standard method for storing RSA keys and and RSA/MD5 based
-   signatures in the Domain Name System is described which utilizes DNS
-   KEY and SIG resource records.
-
-Table of Contents
-
-   Abstract...................................................1
-   1. Introduction............................................1
-   2. RSA Public KEY Resource Records.........................2
-   3. RSA/MD5 SIG Resource Records............................2
-   4. Performance Considerations..............................3
-   5. Security Considerations.................................4
-   References.................................................4
-   Author's Address...........................................5
-   Full Copyright Statement...................................6
-
-1. Introduction
-
-   The Domain Name System (DNS) is the global hierarchical replicated
-   distributed database system for Internet addressing, mail proxy, and
-   other information. The DNS has been extended to include digital
-   signatures and cryptographic keys as described in [RFC 2535].  Thus
-   the DNS can now be secured and used for secure key distribution.
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 1]
-
-RFC 2537            RSA/MD5 KEYs and SIGs in the DNS          March 1999
-
-
-   This document describes how to store RSA keys and and RSA/MD5 based
-   signatures in the DNS.  Familiarity with the RSA algorithm is assumed
-   [Schneier].  Implementation of the RSA algorithm in DNS is
-   recommended.
-
-   The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
-   in this document are to be interpreted as described in RFC 2119.
-
-2. RSA Public KEY Resource Records
-
-   RSA public keys are stored in the DNS as KEY RRs using algorithm
-   number 1 [RFC 2535].  The structure of the algorithm specific portion
-   of the RDATA part of such RRs is as shown below.
-
-           Field             Size
-           -----             ----
-           exponent length   1 or 3 octets (see text)
-           exponent          as specified by length field
-           modulus           remaining space
-
-   For interoperability, the exponent and modulus are each currently
-   limited to 4096 bits in length.  The public key exponent is a
-   variable length unsigned integer.  Its length in octets is
-   represented as one octet if it is in the range of 1 to 255 and by a
-   zero octet followed by a two octet unsigned length if it is longer
-   than 255 bytes.  The public key modulus field is a multiprecision
-   unsigned integer.  The length of the modulus can be determined from
-   the RDLENGTH and the preceding RDATA fields including the exponent.
-   Leading zero octets are prohibited in the exponent and modulus.
-
-3. RSA/MD5 SIG Resource Records
-
-   The signature portion of the SIG RR RDATA area, when using the
-   RSA/MD5 algorithm, is calculated as shown below.  The data signed is
-   determined as specified in [RFC 2535].  See [RFC 2535] for fields in
-   the SIG RR RDATA which precede the signature itself.
-
-
-     hash = MD5 ( data )
-
-     signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n)
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 2]
-
-RFC 2537            RSA/MD5 KEYs and SIGs in the DNS          March 1999
-
-
-   where MD5 is the message digest algorithm documented in [RFC 1321],
-   "|" is concatenation, "e" is the private key exponent of the signer,
-   and "n" is the modulus of the signer's public key.  01, FF, and 00
-   are fixed octets of the corresponding hexadecimal value. "prefix" is
-   the ASN.1 BER MD5 algorithm designator prefix specified in [RFC
-   2437], that is,
-
-      hex 3020300c06082a864886f70d020505000410 [NETSEC].
-
-   This prefix is included to make it easier to use RSAREF (or similar
-   packages such as EuroRef).  The FF octet MUST be repeated the maximum
-   number of times such that the value of the quantity being
-   exponentiated is the same length in octets as the value of n.
-
-   (The above specifications are identical to the corresponding part of
-   Public Key Cryptographic Standard #1 [RFC 2437].)
-
-   The size of n, including most and least significant bits (which will
-   be 1) MUST be not less than 512 bits and not more than 4096 bits.  n
-   and e SHOULD be chosen such that the public exponent is small.
-
-   Leading zero bytes are permitted in the RSA/MD5 algorithm signature.
-
-   A public exponent of 3 minimizes the effort needed to verify a
-   signature.  Use of 3 as the public exponent is weak for
-   confidentiality uses since, if the same data can be collected
-   encrypted under three different keys with an exponent of 3 then,
-   using the Chinese Remainder Theorem [NETSEC], the original plain text
-   can be easily recovered.  This weakness is not significant for DNS
-   security because we seek only authentication, not confidentiality.
-
-4. Performance Considerations
-
-   General signature generation speeds are roughly the same for RSA and
-   DSA [RFC 2536].  With sufficient pre-computation, signature
-   generation with DSA is faster than RSA.  Key generation is also
-   faster for DSA.  However, signature verification is an order of
-   magnitude slower with DSA when the RSA public exponent is chosen to
-   be small as is recommended for KEY RRs used in domain name system
-   (DNS) data authentication.
-
-   Current DNS implementations are optimized for small transfers,
-   typically less than 512 bytes including overhead.  While larger
-   transfers will perform correctly and work is underway to make larger
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 3]
-
-RFC 2537            RSA/MD5 KEYs and SIGs in the DNS          March 1999
-
-
-   transfers more efficient, it is still advisable at this time to make
-   reasonable efforts to minimize the size of KEY RR sets stored within
-   the DNS consistent with adequate security.  Keep in mind that in a
-   secure zone, at least one authenticating SIG RR will also be
-   returned.
-
-5. Security Considerations
-
-   Many of the general security consideration in [RFC 2535] apply.  Keys
-   retrieved from the DNS should not be trusted unless (1) they have
-   been securely obtained from a secure resolver or independently
-   verified by the user and (2) this secure resolver and secure
-   obtainment or independent verification conform to security policies
-   acceptable to the user.  As with all cryptographic algorithms,
-   evaluating the necessary strength of the key is essential and
-   dependent on local policy.
-
-   For interoperability, the RSA key size is limited to 4096 bits.  For
-   particularly critical applications, implementors are encouraged to
-   consider the range of available algorithms and key sizes.
-
-References
-
-   [NETSEC]     Kaufman, C., Perlman, R. and M. Speciner, "Network
-                Security: PRIVATE Communications in a PUBLIC World",
-                Series in Computer Networking and Distributed
-                Communications, 1995.
-
-   [RFC 2437]   Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
-                Specifications Version 2.0", RFC 2437, October 1998.
-
-   [RFC 1034]   Mockapetris, P., "Domain Names - Concepts and
-                Facilities", STD 13, RFC 1034, November 1987.
-
-   [RFC 1035]   Mockapetris, P., "Domain Names - Implementation and
-                Specification", STD 13, RFC 1035, November 1987.
-
-   [RFC 1321]   Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321
-                April 1992.
-
-   [RFC 2535]   Eastlake, D., "Domain Name System Security Extensions",
-                RFC 2535, March 1999.
-
-   [RFC 2536]   EastLake, D., "DSA KEYs and SIGs in the Domain Name
-                System (DNS)", RFC 2536, March 1999.
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 4]
-
-RFC 2537            RSA/MD5 KEYs and SIGs in the DNS          March 1999
-
-
-   [Schneier]   Bruce Schneier, "Applied Cryptography Second Edition:
-                protocols, algorithms, and source code in C", 1996, John
-                Wiley and Sons, ISBN 0-471-11709-9.
-
-Author's Address
-
-   Donald E. Eastlake 3rd
-   IBM
-   65 Shindegan Hill Road, RR #1
-   Carmel, NY 10512
-
-   Phone:   +1-914-276-2668(h)
-            +1-914-784-7913(w)
-   Fax:     +1-914-784-3833(w)
-   EMail:   dee3@us.ibm.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 5]
-
-RFC 2537            RSA/MD5 KEYs and SIGs in the DNS          March 1999
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 6]
-
diff --git a/contrib/bind9/doc/rfc/rfc2538.txt b/contrib/bind9/doc/rfc/rfc2538.txt
deleted file mode 100644
index c53e3ef..0000000
--- a/contrib/bind9/doc/rfc/rfc2538.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        D. Eastlake
-Request for Comments: 2538                                           IBM
-Category: Standards Track                                 O. Gudmundsson
-                                                                TIS Labs
-                                                              March 1999
-
-
-          Storing Certificates in the Domain Name System (DNS)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-Abstract
-
-   Cryptographic public key are frequently published and their
-   authenticity demonstrated by certificates.  A CERT resource record
-   (RR) is defined so that such certificates and related certificate
-   revocation lists can be stored in the Domain Name System (DNS).
-
-Table of Contents
-
-   Abstract...................................................1
-   1. Introduction............................................2
-   2. The CERT Resource Record................................2
-   2.1 Certificate Type Values................................3
-   2.2 Text Representation of CERT RRs........................4
-   2.3 X.509 OIDs.............................................4
-   3. Appropriate Owner Names for CERT RRs....................5
-   3.1 X.509 CERT RR Names....................................5
-   3.2 PGP CERT RR Names......................................6
-   4. Performance Considerations..............................6
-   5. IANA Considerations.....................................7
-   6. Security Considerations.................................7
-   References.................................................8
-   Authors' Addresses.........................................9
-   Full Copyright Notice.....................................10
-
-
-
-
-
-
-Eastlake & Gudmundsson      Standards Track                     [Page 1]
-
-RFC 2538            Storing Certificates in the DNS           March 1999
-
-
-1. Introduction
-
-   Public keys are frequently published in the form of a certificate and
-   their authenticity is commonly demonstrated by certificates and
-   related certificate revocation lists (CRLs).  A certificate is a
-   binding, through a cryptographic digital signature, of a public key,
-   a validity interval and/or conditions, and identity, authorization,
-   or other information. A certificate revocation list is a list of
-   certificates that are revoked, and incidental information, all signed
-   by the signer (issuer) of the revoked certificates. Examples are
-   X.509 certificates/CRLs in the X.500 directory system or PGP
-   certificates/revocations used by PGP software.
-
-   Section 2 below specifies a CERT resource record (RR) for the storage
-   of certificates in the Domain Name System.
-
-   Section 3 discusses appropriate owner names for CERT RRs.
-
-   Sections 4, 5, and 6 below cover performance, IANA, and security
-   considerations, respectively.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-2. The CERT Resource Record
-
-   The CERT resource record (RR) has the structure given below.  Its RR
-   type code is 37.
-
-                         1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |             type              |             key tag           |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |   algorithm   |                                               /
-    +---------------+            certificate or CRL                 /
-    /                                                               /
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
-
-   The type field is the certificate type as define in section 2.1
-   below.
-
-   The algorithm field has the same meaning as the algorithm field in
-   KEY and SIG RRs [RFC 2535] except that a zero algorithm field
-   indicates the algorithm is unknown to a secure DNS, which may simply
-   be the result of the algorithm not having been standardized for
-   secure DNS.
-
-
-
-Eastlake & Gudmundsson      Standards Track                     [Page 2]
-
-RFC 2538            Storing Certificates in the DNS           March 1999
-
-
-   The key tag field is the 16 bit value computed for the key embedded
-   in the certificate as specified in the DNSSEC Standard [RFC 2535].
-   This field is used as an efficiency measure to pick which CERT RRs
-   may be applicable to a particular key.  The key tag can be calculated
-   for the key in question and then only CERT RRs with the same key tag
-   need be examined. However, the key must always be transformed to the
-   format it would have as the public key portion of a KEY RR before the
-   key tag is computed.  This is only possible if the key is applicable
-   to an algorithm (and limits such as key size limits) defined for DNS
-   security.  If it is not, the algorithm field MUST BE zero and the tag
-   field is meaningless and SHOULD BE zero.
-
-2.1 Certificate Type Values
-
-   The following values are defined or reserved:
-
-    Value  Mnemonic  Certificate Type
-    -----  --------  ----------- ----
-        0            reserved
-        1   PKIX     X.509 as per PKIX
-        2   SPKI     SPKI cert
-        3   PGP      PGP cert
-    4-252            available for IANA assignment
-      253   URI      URI private
-      254   OID      OID private
-    255-65534        available for IANA assignment
-    65535            reserved
-
-   The PKIX type is reserved to indicate an X.509 certificate conforming
-   to the profile being defined by the IETF PKIX working group.  The
-   certificate section will start with a one byte unsigned OID length
-   and then an X.500 OID indicating the nature of the remainder of the
-   certificate section (see 2.3 below).  (NOTE: X.509 certificates do
-   not include their X.500 directory type designating OID as a prefix.)
-
-   The SPKI type is reserved to indicate a certificate formated as to be
-   specified by the IETF SPKI working group.
-
-   The PGP type indicates a Pretty Good Privacy certificate as described
-   in RFC 2440 and its extensions and successors.
-
-   The URI private type indicates a certificate format defined by an
-   absolute URI.  The certificate portion of the CERT RR MUST begin with
-   a null terminated URI [RFC 2396] and the data after the null is the
-   private format certificate itself.  The URI SHOULD be such that a
-   retrieval from it will lead to documentation on the format of the
-   certificate.  Recognition of private certificate types need not be
-   based on URI equality but can use various forms of pattern matching
-
-
-
-Eastlake & Gudmundsson      Standards Track                     [Page 3]
-
-RFC 2538            Storing Certificates in the DNS           March 1999
-
-
-   so that, for example, subtype or version information can also be
-   encoded into the URI.
-
-   The OID private type indicates a private format certificate specified
-   by a an ISO OID prefix.  The certificate section will start with a
-   one byte unsigned OID length and then a BER encoded OID indicating
-   the nature of the remainder of the certificate section.  This can be
-   an X.509 certificate format or some other format.  X.509 certificates
-   that conform to the IETF PKIX profile SHOULD be indicated by the PKIX
-   type, not the OID private type.  Recognition of private certificate
-   types need not be based on OID equality but can use various forms of
-   pattern matching such as OID prefix.
-
-2.2 Text Representation of CERT RRs
-
-   The RDATA portion of a CERT RR has the type field as an unsigned
-   integer or as a mnemonic symbol as listed in section 2.1 above.
-
-   The key tag field is represented as an unsigned integer.
-
-   The algorithm field is represented as an unsigned integer or a
-   mnemonic symbol as listed in [RFC 2535].
-
-   The certificate / CRL portion is represented in base 64 and may be
-   divided up into any number of white space separated substrings, down
-   to single base 64 digits, which are concatenated to obtain the full
-   signature.  These substrings can span lines using the standard
-   parenthesis.
-
-   Note that the certificate / CRL portion may have internal sub-fields
-   but these do not appear in the master file representation.  For
-   example, with type 254, there will be an OID size, an OID, and then
-   the certificate / CRL proper. But only a single logical base 64
-   string will appear in the text representation.
-
-2.3 X.509 OIDs
-
-   OIDs have been defined in connection with the X.500 directory for
-   user certificates, certification authority certificates, revocations
-   of certification authority, and revocations of user certificates.
-   The following table lists the OIDs, their BER encoding, and their
-   length prefixed hex format for use in CERT RRs:
-
-
-
-
-
-
-
-
-
-Eastlake & Gudmundsson      Standards Track                     [Page 4]
-
-RFC 2538            Storing Certificates in the DNS           March 1999
-
-
-    id-at-userCertificate
-        = { joint-iso-ccitt(2) ds(5) at(4) 36 }
-           == 0x 03 55 04 24
-    id-at-cACertificate
-        = { joint-iso-ccitt(2) ds(5) at(4) 37 }
-           == 0x 03 55 04 25
-    id-at-authorityRevocationList
-        = { joint-iso-ccitt(2) ds(5) at(4) 38 }
-           == 0x 03 55 04 26
-    id-at-certificateRevocationList
-        = { joint-iso-ccitt(2) ds(5) at(4) 39 }
-           == 0x 03 55 04 27
-
-3. Appropriate Owner Names for CERT RRs
-
-   It is recommended that certificate CERT RRs be stored under a domain
-   name related to their subject, i.e., the name of the entity intended
-   to control the private key corresponding to the public key being
-   certified.  It is recommended that certificate revocation list CERT
-   RRs be stored under a domain name related to their issuer.
-
-   Following some of the guidelines below may result in the use in DNS
-   names of characters that require DNS quoting which is to use a
-   backslash followed by the octal representation of the ASCII code for
-   the character such as \000 for NULL.
-
-3.1 X.509 CERT RR Names
-
-   Some X.509 versions permit multiple names to be associated with
-   subjects and issuers under "Subject Alternate Name" and "Issuer
-   Alternate Name".  For example, x.509v3 has such Alternate Names with
-   an ASN.1 specification as follows:
-
-         GeneralName ::= CHOICE {
-            otherName                  [0] INSTANCE OF OTHER-NAME,
-            rfc822Name                 [1] IA5String,
-            dNSName                    [2] IA5String,
-            x400Address                [3] EXPLICIT OR-ADDRESS.&Type,
-            directoryName              [4] EXPLICIT Name,
-            ediPartyName               [5] EDIPartyName,
-            uniformResourceIdentifier  [6] IA5String,
-            iPAddress                  [7] OCTET STRING,
-            registeredID               [8] OBJECT IDENTIFIER
-         }
-
-   The recommended locations of CERT storage are as follows, in priority
-   order:
-
-
-
-
-Eastlake & Gudmundsson      Standards Track                     [Page 5]
-
-RFC 2538            Storing Certificates in the DNS           March 1999
-
-
-   (1) If a domain name is included in the identification in the
-       certificate or CRL, that should be used.
-   (2) If a domain name is not included but an IP address is included,
-       then the translation of that IP address into the appropriate
-       inverse domain name should be used.
-   (3) If neither of the above it used but a URI containing a domain
-       name is present, that domain name should be used.
-   (4) If none of the above is included but a character string name is
-       included, then it should be treated as described for PGP names in
-       3.2 below.
-   (5) If none of the above apply, then the distinguished name (DN)
-       should be mapped into a domain name as specified in RFC 2247.
-
-   Example 1: Assume that an X.509v3 certificate is issued to /CN=John
-   Doe/DC=Doe/DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative
-   names of (a) string "John (the Man) Doe", (b) domain name john-
-   doe.com, and (c) uri <https://www.secure.john-doe.com:8080/>.  Then
-   the storage locations recommended, in priority order, would be
-       (1) john-doe.com,
-       (2) www.secure.john-doe.com, and
-       (3) Doe.com.xy.
-
-   Example 2:  Assume that an X.509v3 certificate is issued to /CN=James
-   Hacker/L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names
-   of (a) domain name widget.foo.example, (b) IPv4 address
-   10.251.13.201, and (c) string "James Hacker
-   <hacker@mail.widget.foo.example>".  Then the storage locations
-   recommended, in priority order, would be
-        (1) widget.foo.example,
-        (2) 201.13.251.10.in-addr.arpa, and
-        (3) hacker.mail.widget.foo.example.
-
-3.2 PGP CERT RR Names
-
-   PGP signed keys (certificates) use a general character string User ID
-   [RFC 2440]. However, it is recommended by PGP that such names include
-   the RFC 822 email address of the party, as in "Leslie Example
-   <Leslie@host.example>".  If such a format is used, the CERT should be
-   under the standard translation of the email address into a domain
-   name, which would be leslie.host.example in this case.  If no RFC 822
-   name can be extracted from the string name no specific domain name is
-   recommended.
-
-4. Performance Considerations
-
-   Current Domain Name System (DNS) implementations are optimized for
-   small transfers, typically not more than 512 bytes including
-   overhead.  While larger transfers will perform correctly and work is
-
-
-
-Eastlake & Gudmundsson      Standards Track                     [Page 6]
-
-RFC 2538            Storing Certificates in the DNS           March 1999
-
-
-   underway to make larger transfers more efficient, it is still
-   advisable at this time to make every reasonable effort to minimize
-   the size of certificates stored within the DNS.  Steps that can be
-   taken may include using the fewest possible optional or extensions
-   fields and using short field values for variable length fields that
-   must be included.
-
-5. IANA Considerations
-
-   Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can
-   only be assigned by an IETF standards action [RFC 2434] (and this
-   document assigns 0x0001 through 0x0003 and 0x00FD and 0x00FE).
-   Certificate types 0x0100 through 0xFEFF are assigned through IETF
-   Consensus [RFC 2434] based on RFC documentation of the certificate
-   type.  The availability of private types under 0x00FD and 0x00FE
-   should satisfy most requirements for proprietary or private types.
-
-6. Security Considerations
-
-   By definition, certificates contain their own authenticating
-   signature.  Thus it is reasonable to store certificates in non-secure
-   DNS zones or to retrieve certificates from DNS with DNS security
-   checking not implemented or deferred for efficiency.  The results MAY
-   be trusted if the certificate chain is verified back to a known
-   trusted key and this conforms with the user's security policy.
-
-   Alternatively, if certificates are retrieved from a secure DNS zone
-   with DNS security checking enabled and are verified by DNS security,
-   the key within the retrieved certificate MAY be trusted without
-   verifying the certificate chain if this conforms with the user's
-   security policy.
-
-   CERT RRs are not used in connection with securing the DNS security
-   additions so there are no security considerations related to CERT RRs
-   and securing the DNS itself.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake & Gudmundsson      Standards Track                     [Page 7]
-
-RFC 2538            Storing Certificates in the DNS           March 1999
-
-
-References
-
-   RFC 1034   Mockapetris, P., "Domain Names - Concepts and Facilities",
-              STD 13, RFC 1034, November 1987.
-
-   RFC 1035   Mockapetris, P., "Domain Names - Implementation and
-              Specifications", STD 13, RFC 1035, November 1987.
-
-   RFC 2119   Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   RFC 2247   Kille, S., Wahl, M., Grimstad, A., Huber, R. and S.
-              Sataluri, "Using Domains in LDAP/X.500 Distinguished
-              Names", RFC 2247, January 1998.
-
-   RFC 2396   Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
-              Resource Identifiers (URI): Generic Syntax", RFC 2396,
-              August 1998.
-
-   RFC 2440   Callas, J., Donnerhacke, L., Finney, H. and R.  Thayer,
-              "OpenPGP Message Format", RFC 2240, November 1998.
-
-   RFC 2434   Narten, T. and H. Alvestrand, "Guidelines for Writing an
-              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
-              October 1998.
-
-   RFC 2535   Eastlake, D., "Domain Name System (DNS) Security
-              Extensions", RFC 2535, March 1999.
-
-   RFC 2459   Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
-              X.509 Public Key Infrastructure Certificate and CRL
-              Profile", RFC 2459, January 1999.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake & Gudmundsson      Standards Track                     [Page 8]
-
-RFC 2538            Storing Certificates in the DNS           March 1999
-
-
-Authors' Addresses
-
-   Donald E. Eastlake 3rd
-   IBM
-   65 Shindegan Hill Road
-   RR#1
-   Carmel, NY 10512 USA
-
-   Phone:   +1-914-784-7913 (w)
-            +1-914-276-2668 (h)
-   Fax:     +1-914-784-3833 (w-fax)
-   EMail:   dee3@us.ibm.com
-
-
-   Olafur Gudmundsson
-   TIS Labs at Network Associates
-   3060 Washington Rd, Route 97
-   Glenwood MD 21738
-
-   Phone: +1 443-259-2389
-   EMail: ogud@tislabs.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake & Gudmundsson      Standards Track                     [Page 9]
-
-RFC 2538            Storing Certificates in the DNS           March 1999
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake & Gudmundsson      Standards Track                    [Page 10]
-
diff --git a/contrib/bind9/doc/rfc/rfc2539.txt b/contrib/bind9/doc/rfc/rfc2539.txt
deleted file mode 100644
index cf32523..0000000
--- a/contrib/bind9/doc/rfc/rfc2539.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        D. Eastlake
-Request for Comments: 2539                                           IBM
-Category: Standards Track                                     March 1999
-
-
-     Storage of Diffie-Hellman Keys in the Domain Name System (DNS)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-Abstract
-
-   A standard method for storing Diffie-Hellman keys in the Domain Name
-   System is described which utilizes DNS KEY resource records.
-
-Acknowledgements
-
-   Part of the format for Diffie-Hellman keys and the description
-   thereof was taken from a work in progress by:
-
-      Ashar Aziz <ashar.aziz@eng.sun.com>
-      Tom Markson <markson@incog.com>
-      Hemma Prafullchandra <hemma@eng.sun.com>
-
-   In addition, the following person provided useful comments that have
-   been incorporated:
-
-      Ran Atkinson <rja@inet.org>
-      Thomas Narten <narten@raleigh.ibm.com>
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 1]
-
-RFC 2539             Diffie-Hellman Keys in the DNS           March 1999
-
-
-Table of Contents
-
-   Abstract...................................................1
-   Acknowledgements...........................................1
-   1. Introduction............................................2
-   1.1 About This Document....................................2
-   1.2 About Diffie-Hellman...................................2
-   2. Diffie-Hellman KEY Resource Records.....................3
-   3. Performance Considerations..............................4
-   4. IANA Considerations.....................................4
-   5. Security Considerations.................................4
-   References.................................................5
-   Author's Address...........................................5
-   Appendix A: Well known prime/generator pairs...............6
-   A.1. Well-Known Group 1:  A 768 bit prime..................6
-   A.2. Well-Known Group 2:  A 1024 bit prime.................6
-   Full Copyright Notice......................................7
-
-1. Introduction
-
-   The Domain Name System (DNS) is the current global hierarchical
-   replicated distributed database system for Internet addressing, mail
-   proxy, and similar information. The DNS has been extended to include
-   digital signatures and cryptographic keys as described in [RFC 2535].
-   Thus the DNS can now be used for secure key distribution.
-
-1.1 About This Document
-
-   This document describes how to store Diffie-Hellman keys in the DNS.
-   Familiarity with the Diffie-Hellman key exchange algorithm is assumed
-   [Schneier].
-
-1.2 About Diffie-Hellman
-
-   Diffie-Hellman requires two parties to interact to derive keying
-   information which can then be used for authentication.  Since DNS SIG
-   RRs are primarily used as stored authenticators of zone information
-   for many different resolvers, no Diffie-Hellman algorithm SIG RR is
-   defined. For example, assume that two parties have local secrets "i"
-   and "j".  Assume they each respectively calculate X and Y as follows:
-
-                X = g**i ( mod p ) Y = g**j ( mod p )
-
-   They exchange these quantities and then each calculates a Z as
-   follows:
-
-                Zi = Y**i ( mod p ) Zj = X**j ( mod p )
-
-
-
-
-Eastlake                    Standards Track                     [Page 2]
-
-RFC 2539             Diffie-Hellman Keys in the DNS           March 1999
-
-
-   shared secret between the two parties that an adversary who does not
-   know i or j will not be able to learn from the exchanged messages
-   (unless the adversary can derive i or j by performing a discrete
-   logarithm mod p which is hard for strong p and g).
-
-   The private key for each party is their secret i (or j).  The public
-   key is the pair p and g, which must be the same for the parties, and
-   their individual X (or Y).
-
-2. Diffie-Hellman KEY Resource Records
-
-   Diffie-Hellman keys are stored in the DNS as KEY RRs using algorithm
-   number 2.  The structure of the RDATA portion of this RR is as shown
-   below.  The first 4 octets, including the flags, protocol, and
-   algorithm fields are common to all KEY RRs as described in [RFC
-   2535].  The remainder, from prime length through public value is the
-   "public key" part of the KEY RR. The period of key validity is not in
-   the KEY RR but is indicated by the SIG RR(s) which signs and
-   authenticates the KEY RR(s) at that domain name.
-
-                         1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |           KEY flags           |    protocol   |  algorithm=2  |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |     prime length (or flag)    |  prime (p) (or special)       /
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    /  prime (p)  (variable length) |       generator length        |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    | generator (g) (variable length)                               |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |     public value length       | public value (variable length)/
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    /  public value (g^i mod p)    (variable length)                |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   Prime length is length of the Diffie-Hellman prime (p) in bytes if it
-   is 16 or greater.  Prime contains the binary representation of the
-   Diffie-Hellman prime with most significant byte first (i.e., in
-   network order). If "prime length" field is 1 or 2, then the "prime"
-   field is actually an unsigned index into a table of 65,536
-   prime/generator pairs and the generator length SHOULD be zero.  See
-   Appedix A for defined table entries and Section 4 for information on
-   allocating additional table entries.  The meaning of a zero or 3
-   through 15 value for "prime length" is reserved.
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 3]
-
-RFC 2539             Diffie-Hellman Keys in the DNS           March 1999
-
-
-   Generator length is the length of the generator (g) in bytes.
-   Generator is the binary representation of generator with most
-   significant byte first.  PublicValueLen is the Length of the Public
-   Value (g**i (mod p)) in bytes.  PublicValue is the binary
-   representation of the DH public value with most significant byte
-   first.
-
-   The corresponding algorithm=2 SIG resource record is not used so no
-   format for it is defined.
-
-3. Performance Considerations
-
-   Current DNS implementations are optimized for small transfers,
-   typically less than 512 bytes including overhead.  While larger
-   transfers will perform correctly and work is underway to make larger
-   transfers more efficient, it is still advisable to make reasonable
-   efforts to minimize the size of KEY RR sets stored within the DNS
-   consistent with adequate security.  Keep in mind that in a secure
-   zone, an authenticating SIG RR will also be returned.
-
-4. IANA Considerations
-
-   Assignment of meaning to Prime Lengths of 0 and 3 through 15 requires
-   an IETF consensus.
-
-   Well known prime/generator pairs number 0x0000 through 0x07FF can
-   only be assigned by an IETF standards action and this Proposed
-   Standard assigns 0x0001 through 0x0002. Pairs number 0s0800 through
-   0xBFFF can be assigned based on RFC documentation.  Pairs number
-   0xC000 through 0xFFFF are available for private use and are not
-   centrally coordinated. Use of such private pairs outside of a closed
-   environment may result in conflicts.
-
-5. Security Considerations
-
-   Many of the general security consideration in [RFC 2535] apply.  Keys
-   retrieved from the DNS should not be trusted unless (1) they have
-   been securely obtained from a secure resolver or independently
-   verified by the user and (2) this secure resolver and secure
-   obtainment or independent verification conform to security policies
-   acceptable to the user.  As with all cryptographic algorithms,
-   evaluating the necessary strength of the key is important and
-   dependent on local policy.
-
-   In addition, the usual Diffie-Hellman key strength considerations
-   apply. (p-1)/2 should also be prime, g should be primitive mod p, p
-   should be "large", etc.  [Schneier]
-
-
-
-
-Eastlake                    Standards Track                     [Page 4]
-
-RFC 2539             Diffie-Hellman Keys in the DNS           March 1999
-
-
-References
-
-   [RFC 1034]   Mockapetris, P., "Domain Names - Concepts and
-                Facilities", STD 13, RFC 1034, November 1987.
-
-   [RFC 1035]   Mockapetris, P., "Domain Names - Implementation and
-                Specification", STD 13, RFC 1035, November 1987.
-
-   [RFC 2535]   Eastlake, D., "Domain Name System Security Extensions",
-                RFC 2535, March 1999.
-
-   [Schneier]   Bruce Schneier, "Applied Cryptography: Protocols,
-                Algorithms, and Source Code in C", 1996, John Wiley and
-                Sons
-
-Author's Address
-
-   Donald E. Eastlake 3rd
-   IBM
-   65 Shindegan Hill Road, RR #1
-   Carmel, NY 10512
-
-   Phone:   +1-914-276-2668(h)
-            +1-914-784-7913(w)
-   Fax:     +1-914-784-3833(w)
-   EMail:   dee3@us.ibm.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 5]
-
-RFC 2539             Diffie-Hellman Keys in the DNS           March 1999
-
-
-Appendix A: Well known prime/generator pairs
-
-   These numbers are copied from the IPSEC effort where the derivation
-   of these values is more fully explained and additional information is
-   available.  Richard Schroeppel performed all the mathematical and
-   computational work for this appendix.
-
-A.1. Well-Known Group 1:  A 768 bit prime
-
-   The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }.  Its
-   decimal value is
-          155251809230070893513091813125848175563133404943451431320235
-          119490296623994910210725866945387659164244291000768028886422
-          915080371891804634263272761303128298374438082089019628850917
-          0691316593175367469551763119843371637221007210577919
-
-   Prime modulus: Length (32 bit words): 24, Data (hex):
-            FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
-            29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
-            EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
-            E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF
-
-   Generator: Length (32 bit words): 1, Data (hex): 2
-
-A.2. Well-Known Group 2:  A 1024 bit prime
-
-   The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
-   Its decimal value is
-         179769313486231590770839156793787453197860296048756011706444
-         423684197180216158519368947833795864925541502180565485980503
-         646440548199239100050792877003355816639229553136239076508735
-         759914822574862575007425302077447712589550957937778424442426
-         617334727629299387668709205606050270810842907692932019128194
-         467627007
-
-   Prime modulus:  Length (32 bit words): 32, Data (hex):
-            FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
-            29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
-            EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
-            E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
-            EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
-            FFFFFFFF FFFFFFFF
-
-   Generator: Length (32 bit words):  1, Data (hex): 2
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 6]
-
-RFC 2539             Diffie-Hellman Keys in the DNS           March 1999
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 7]
-
diff --git a/contrib/bind9/doc/rfc/rfc2540.txt b/contrib/bind9/doc/rfc/rfc2540.txt
deleted file mode 100644
index 6314806..0000000
--- a/contrib/bind9/doc/rfc/rfc2540.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        D. Eastlake
-Request for Comments: 2540                                           IBM
-Category: Experimental                                        March 1999
-
-
-             Detached Domain Name System (DNS) Information
-
-Status of this Memo
-
-   This memo defines an Experimental Protocol for the Internet
-   community.  It does not specify an Internet standard of any kind.
-   Discussion and suggestions for improvement are requested.
-   Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-Abstract
-
-   A standard format is defined for representing detached DNS
-   information.  This is anticipated to be of use for storing
-   information retrieved from the Domain Name System (DNS), including
-   security information, in archival contexts or contexts not connected
-   to the Internet.
-
-Table of Contents
-
-   Abstract...................................................1
-   1. Introduction............................................1
-   2. General Format..........................................2
-   2.1 Binary Format..........................................3
-   2.2. Text Format...........................................4
-   3. Usage Example...........................................4
-   4. IANA Considerations.....................................4
-   5. Security Considerations.................................4
-   References.................................................5
-   Author's Address...........................................5
-   Full Copyright Statement...................................6
-
-1. Introduction
-
-   The Domain Name System (DNS) is a replicated hierarchical distributed
-   database system [RFC 1034, 1035] that can provide highly available
-   service.  It provides the operational basis for Internet host name to
-   address translation, automatic SMTP mail routing, and other basic
-   Internet functions.  The DNS has been extended as described in [RFC
-   2535] to permit the general storage of public cryptographic keys in
-
-
-
-Eastlake                      Experimental                      [Page 1]
-
-RFC 2540                Detached DNS Information              March 1999
-
-
-   the DNS and to enable the authentication of information retrieved
-   from the DNS though digital signatures.
-
-   The DNS was not originally designed for storage of information
-   outside of the active zones and authoritative master files that are
-   part of the connected DNS.  However there may be cases where this is
-   useful, particularly in connection with archived security
-   information.
-
-2. General Format
-
-   The formats used for detached Domain Name System (DNS) information
-   are similar to those used for connected DNS information. The primary
-   difference is that elements of the connected DNS system (unless they
-   are an authoritative server for the zone containing the information)
-   are required to count down the Time To Live (TTL) associated with
-   each DNS Resource Record (RR) and discard them (possibly fetching a
-   fresh copy) when the TTL reaches zero.  In contrast to this, detached
-   information may be stored in a off-line file, where it can not be
-   updated, and perhaps used to authenticate historic data or it might
-   be received via non-DNS protocols long after it was retrieved from
-   the DNS.  Therefore, it is not practical to count down detached DNS
-   information TTL and it may be necessary to keep the data beyond the
-   point where the TTL (which is defined as an unsigned field) would
-   underflow.  To preserve information as to the freshness of this
-   detached data, it is accompanied by its retrieval time.
-
-   Whatever retrieves the information from the DNS must associate this
-   retrieval time with it.  The retrieval time remains fixed thereafter.
-   When the current time minus the retrieval time exceeds the TTL for
-   any particular detached RR, it is no longer a valid copy within the
-   normal connected DNS scheme.  This may make it invalid in context for
-   some detached purposes as well.  If the RR is a SIG (signature) RR it
-   also has an expiration time.  Regardless of the TTL, it and any RRs
-   it signs can not be considered authenticated after the signature
-   expiration time.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                      Experimental                      [Page 2]
-
-RFC 2540                Detached DNS Information              March 1999
-
-
-2.1 Binary Format
-
-   The standard binary format for detached DNS information is as
-   follows:
-
-                         1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |                      first retrieval time                     |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |          RR count             |                               |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     Resource Records (RRs)    |
-    /                                                               /
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
-    |                       next retrieval time                     |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |          RR count             |                               |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     Resource Records (RRs)    |
-    /                                                               /
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    /                              ...                              /
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |     hex 20    |
-    +-+-+-+-+-+-+-+-+
-
-   Retrieval time - the time that the immediately following information
-       was obtained from the connected DNS system.  It is an unsigned
-       number of seconds since the start of 1 January 1970, GMT,
-       ignoring leap seconds, in network (big-endian) order.  Note that
-       this time can not be before the initial proposal of this
-       standard.  Therefore, the initial byte of an actual retrieval
-       time, considered as a 32 bit unsigned quantity, would always be
-       larger than 20 hex.  The end of detached DNS information is
-       indicated by a "retrieval time" field initial byte equal to 0x20.
-       Use of a "retrieval time" field with a leading unsigned byte of
-       zero indicates a 64 bit (actually 8 leading zero bits plus a 56
-       bit quantity).  This 64 bit format will be required when
-       retrieval time is larger than 0xFFFFFFFF, which is some time in
-       the year 2106.  The meaning of retrieval times with an initial
-       byte between 0x01 and 0x1F is reserved (see section 5).
-       Retrieval times will not generally be 32 bit aligned with respect
-       to each other due to the variable length nature of RRs.
-
-   RR count - an unsigned integer number (with bytes in network order)
-       of following resource records retrieved at the preceding
-       retrieval time.
-
-
-
-
-
-Eastlake                      Experimental                      [Page 3]
-
-RFC 2540                Detached DNS Information              March 1999
-
-
-   Resource Records - the actual data which is in the same format as if
-       it were being transmitted in a DNS response.  In particular, name
-       compression via pointers is permitted with the origin at the
-       beginning of the particular detached information data section,
-       just after the RR count.
-
-2.2. Text Format
-
-   The standard text format for detached DNS information is as
-   prescribed for zone master files [RFC 1035] except that the $INCLUDE
-   control entry is prohibited and the new $DATE entry is required
-   (unless the information set is empty). $DATE is followed by the date
-   and time that the following information was obtained from the DNS
-   system as described for retrieval time in section 2.1 above.  It is
-   in the text format YYYYMMDDHHMMSS where YYYY is the year (which may
-   be more than four digits to cover years after 9999), the first MM is
-   the month number (01-12), DD is the day of the month (01-31), HH is
-   the hour in 24 hours notation (00-23), the second MM is the minute
-   (00-59), and SS is the second (00-59).  Thus a $DATE must appear
-   before the first RR and at every change in retrieval time through the
-   detached information.
-
-3. Usage Example
-
-   A document might be authenticated by a key retrieved from the DNS in
-   a KEY resource record (RR).  To later prove the authenticity of this
-   document, it would be desirable to preserve the KEY RR for that
-   public key, the SIG RR signing that KEY RR, the KEY RR for the key
-   used to authenticate that SIG, and so on through SIG and KEY RRs
-   until a well known trusted key is reached, perhaps the key for the
-   DNS root or some third party authentication service. (In some cases
-   these KEY RRs will actually be sets of KEY RRs with the same owner
-   and class because SIGs actually sign such record sets.)
-
-   This information could be preserved as a set of detached DNS
-   information blocks.
-
-4. IANA Considerations
-
-   Allocation of meanings to retrieval time fields with a initial byte
-   of between 0x01 and 0x1F requires an IETF consensus.
-
-5. Security Considerations
-
-   The entirety of this document concerns a means to represent detached
-   DNS information.  Such detached resource records may be security
-   relevant and/or secured information as described in [RFC 2535].  The
-   detached format provides no overall security for sets of detached
-
-
-
-Eastlake                      Experimental                      [Page 4]
-
-RFC 2540                Detached DNS Information              March 1999
-
-
-   information or for the association between retrieval time and
-   information.  This can be provided by wrapping the detached
-   information format with some other form of signature.  However, if
-   the detached information is accompanied by SIG RRs, its validity
-   period is indicated in those SIG RRs so the retrieval time might be
-   of secondary importance.
-
-References
-
-   [RFC 1034]   Mockapetris, P., "Domain Names - Concepts and
-                Facilities", STD 13, RFC 1034, November 1987.
-
-   [RFC 1035]   Mockapetris, P., " Domain Names - Implementation and
-                Specifications", STD 13, RFC 1035, November 1987.
-
-   [RFC 2535]   Eastlake, D., "Domain Name System Security Extensions",
-                RFC 2535, March 1999.
-
-Author's Address
-
-   Donald E. Eastlake 3rd
-   IBM
-   65 Shindegan Hill Road, RR #1
-   Carmel, NY 10512
-
-   Phone:   +1-914-276-2668(h)
-            +1-914-784-7913(w)
-   Fax:     +1-914-784-3833(w)
-   EMail:   dee3@us.ibm.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                      Experimental                      [Page 5]
-
-RFC 2540                Detached DNS Information              March 1999
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                      Experimental                      [Page 6]
-
diff --git a/contrib/bind9/doc/rfc/rfc2541.txt b/contrib/bind9/doc/rfc/rfc2541.txt
deleted file mode 100644
index a62ed2b..0000000
--- a/contrib/bind9/doc/rfc/rfc2541.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        D. Eastlake
-Request for Comments: 2541                                           IBM
-Category: Informational                                       March 1999
-
-
-                DNS Security Operational Considerations
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-Abstract
-
-   Secure DNS is based on cryptographic techniques.  A necessary part of
-   the strength of these techniques is careful attention to the
-   operational aspects of key and signature generation, lifetime, size,
-   and storage.  In addition, special attention must be paid to the
-   security of the high level zones, particularly the root zone.  This
-   document discusses these operational aspects for keys and signatures
-   used in connection with the KEY and SIG DNS resource records.
-
-Acknowledgments
-
-   The contributions and suggestions of the following persons (in
-   alphabetic order) are gratefully acknowledged:
-
-         John Gilmore
-         Olafur Gudmundsson
-         Charlie Kaufman
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                     Informational                      [Page 1]
-
-RFC 2541        DNS Security Operational Considerations       March 1999
-
-
-Table of Contents
-
-   Abstract...................................................1
-   Acknowledgments............................................1
-   1. Introduction............................................2
-   2. Public/Private Key Generation...........................2
-   3. Public/Private Key Lifetimes............................2
-   4. Public/Private Key Size Considerations..................3
-   4.1 RSA Key Sizes..........................................3
-   4.2 DSS Key Sizes..........................................4
-   5. Private Key Storage.....................................4
-   6. High Level Zones, The Root Zone, and The Meta-Root Key..5
-   7. Security Considerations.................................5
-   References.................................................6
-   Author's Address...........................................6
-   Full Copyright Statement...................................7
-
-1. Introduction
-
-   This document describes operational considerations for the
-   generation, lifetime, size, and storage of DNS cryptographic keys and
-   signatures for use in the KEY and SIG resource records [RFC 2535].
-   Particular attention is paid to high level zones and the root zone.
-
-2. Public/Private Key Generation
-
-   Careful generation of all keys is a sometimes overlooked but
-   absolutely essential element in any cryptographically secure system.
-   The strongest algorithms used with the longest keys are still of no
-   use if an adversary can guess enough to lower the size of the likely
-   key space so that it can be exhaustively searched.  Technical
-   suggestions for the generation of random keys will be found in [RFC
-   1750].
-
-   Long term keys are particularly sensitive as they will represent a
-   more valuable target and be subject to attack for a longer time than
-   short period keys.  It is strongly recommended that long term key
-   generation occur off-line in a manner isolated from the network via
-   an air gap or, at a minimum, high level secure hardware.
-
-3. Public/Private Key Lifetimes
-
-   No key should be used forever.  The longer a key is in use, the
-   greater the probability that it will have been compromised through
-   carelessness, accident, espionage, or cryptanalysis.  Furthermore, if
-
-
-
-
-
-
-Eastlake                     Informational                      [Page 2]
-
-RFC 2541        DNS Security Operational Considerations       March 1999
-
-
-   key rollover is a rare event, there is an increased risk that, when
-   the time does come to change the key, no one at the site will
-   remember how to do it or operational problems will have developed in
-   the key rollover procedures.
-
-   While public key lifetime is a matter of local policy, these
-   considerations imply that, unless there are extraordinary
-   circumstances, no long term key should have a lifetime significantly
-   over four years.  In fact, a reasonable guideline for long term keys
-   that are kept off-line and carefully guarded is a 13 month lifetime
-   with the intent that they be replaced every year.  A reasonable
-   maximum lifetime for keys that are used for transaction security or
-   the like and are kept on line is 36 days with the intent that they be
-   replaced monthly or more often.  In many cases, a key lifetime of
-   somewhat over a day may be reasonable.
-
-   On the other hand, public keys with too short a lifetime can lead to
-   excessive resource consumption in re-signing data and retrieving
-   fresh information because cached information becomes stale.  In the
-   Internet environment, almost all public keys should have lifetimes no
-   shorter than three minutes, which is a reasonable estimate of maximum
-   packet delay even in unusual circumstances.
-
-4. Public/Private Key Size Considerations
-
-   There are a number of factors that effect public key size choice for
-   use in the DNS security extension.  Unfortunately, these factors
-   usually do not all point in the same direction.  Choice of zone key
-   size should generally be made by the zone administrator depending on
-   their local conditions.
-
-   For most schemes, larger keys are more secure but slower.  In
-   addition, larger keys increase the size of the KEY and SIG RRs.  This
-   increases the chance of DNS UDP packet overflow and the possible
-   necessity for using higher overhead TCP in responses.
-
-4.1 RSA Key Sizes
-
-   Given a small public exponent, verification (the most common
-   operation) for the MD5/RSA algorithm will vary roughly with the
-   square of the modulus length, signing will vary with the cube of the
-   modulus length, and key generation (the least common operation) will
-   vary with the fourth power of the modulus length.  The current best
-   algorithms for factoring a modulus and breaking RSA security vary
-   roughly with the 1.6 power of the modulus itself.  Thus going from a
-   640 bit modulus to a 1280 bit modulus only increases the verification
-   time by a factor of 4 but may increase the work factor of breaking
-   the key by over 2^900.
-
-
-
-Eastlake                     Informational                      [Page 3]
-
-RFC 2541        DNS Security Operational Considerations       March 1999
-
-
-   The recommended minimum RSA algorithm modulus size is 704 bits which
-   is believed by the author to be secure at this time.  But high level
-   zones in the DNS tree may wish to set a higher minimum, perhaps 1000
-   bits, for security reasons.  (Since the United States National
-   Security Agency generally permits export of encryption systems using
-   an RSA modulus of up to 512 bits, use of that small a modulus, i.e.
-   n, must be considered weak.)
-
-   For an RSA key used only to secure data and not to secure other keys,
-   704 bits should be adequate at this time.
-
-4.2 DSS Key Sizes
-
-   DSS keys are probably roughly as strong as an RSA key of the same
-   length but DSS signatures are significantly smaller.
-
-5. Private Key Storage
-
-   It is recommended that, where possible, zone private keys and the
-   zone file master copy be kept and used in off-line, non-network
-   connected, physically secure machines only.  Periodically an
-   application can be run to add authentication to a zone by adding SIG
-   and NXT RRs and adding no-key type KEY RRs for subzones/algorithms
-   where a real KEY RR for the subzone with that algorithm is not
-   provided. Then the augmented file can be transferred, perhaps by
-   sneaker-net, to the networked zone primary server machine.
-
-   The idea is to have a one way information flow to the network to
-   avoid the possibility of tampering from the network.  Keeping the
-   zone master file on-line on the network and simply cycling it through
-   an off-line signer does not do this.  The on-line version could still
-   be tampered with if the host it resides on is compromised.  For
-   maximum security, the master copy of the zone file should be off net
-   and should not be updated based on an unsecured network mediated
-   communication.
-
-   This is not possible if the zone is to be dynamically updated
-   securely [RFC 2137]. At least a private key capable of updating the
-   SOA and NXT chain must be on line in that case.
-
-   Secure resolvers must be configured with some trusted on-line public
-   key information (or a secure path to such a resolver) or they will be
-   unable to authenticate.  Although on line, this public key
-   information must be protected or it could be altered so that spoofed
-   DNS data would appear authentic.
-
-
-
-
-
-
-Eastlake                     Informational                      [Page 4]
-
-RFC 2541        DNS Security Operational Considerations       March 1999
-
-
-   Non-zone private keys, such as host or user keys, generally have to
-   be kept on line to be used for real-time purposes such as DNS
-   transaction security.
-
-6. High Level Zones, The Root Zone, and The Meta-Root Key
-
-   Higher level zones are generally more sensitive than lower level
-   zones.  Anyone controlling or breaking the security of a zone thereby
-   obtains authority over all of its subdomains (except in the case of
-   resolvers that have locally configured the public key of a
-   subdomain).  Therefore, extra care should be taken with high level
-   zones and strong keys used.
-
-   The root zone is the most critical of all zones.  Someone controlling
-   or compromising the security of the root zone would control the
-   entire DNS name space of all resolvers using that root zone (except
-   in the case of resolvers that have locally configured the public key
-   of a subdomain). Therefore, the utmost care must be taken in the
-   securing of the root zone. The strongest and most carefully handled
-   keys should be used.  The root zone private key should always be kept
-   off line.
-
-   Many resolvers will start at a root server for their access to and
-   authentication of DNS data.  Securely updating an enormous population
-   of resolvers around the world will be extremely difficult.  Yet the
-   guidelines in section 3 above would imply that the root zone private
-   key be changed annually or more often and if it were staticly
-   configured at all these resolvers, it would have to be updated when
-   changed.
-
-   To permit relatively frequent change to the root zone key yet
-   minimize exposure of the ultimate key of the DNS tree, there will be
-   a "meta-root" key used very rarely and then only to sign a sequence
-   of regular root key RRsets with overlapping time validity periods
-   that are to be rolled out. The root zone contains the meta-root and
-   current regular root KEY RR(s) signed by SIG RRs under both the
-   meta-root and other root private key(s) themselves.
-
-   The utmost security in the storage and use of the meta-root key is
-   essential.  The exact techniques are precautions to be used are
-   beyond the scope of this document.  Because of its special position,
-   it may be best to continue with the same meta-root key for an
-   extended period of time such as ten to fifteen years.
-
-7. Security Considerations
-
-   The entirety of this document is concerned with operational
-   considerations of public/private key pair DNS Security.
-
-
-
-Eastlake                     Informational                      [Page 5]
-
-RFC 2541        DNS Security Operational Considerations       March 1999
-
-
-References
-
-   [RFC 1034]   Mockapetris, P., "Domain Names - Concepts and
-                Facilities", STD 13, RFC 1034, November 1987.
-
-   [RFC 1035]   Mockapetris, P., "Domain Names - Implementation and
-                Specifications", STD 13, RFC 1035, November 1987.
-
-   [RFC 1750]   Eastlake, D., Crocker, S. and J. Schiller, "Randomness
-                Requirements for Security", RFC 1750, December 1994.
-
-   [RFC 2065]   Eastlake, D. and C. Kaufman, "Domain Name System
-                Security Extensions", RFC 2065, January 1997.
-
-   [RFC 2137]   Eastlake, D., "Secure Domain Name System Dynamic
-                Update", RFC 2137, April 1997.
-
-   [RFC 2535]   Eastlake, D., "Domain Name System Security Extensions",
-                RFC 2535, March 1999.
-
-   [RSA FAQ]    RSADSI Frequently Asked Questions periodic posting.
-
-Author's Address
-
-   Donald E. Eastlake 3rd
-   IBM
-   65 Shindegan Hill Road, RR #1
-   Carmel, NY 10512
-
-   Phone:   +1-914-276-2668(h)
-            +1-914-784-7913(w)
-   Fax:     +1-914-784-3833(w)
-   EMail:   dee3@us.ibm.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                     Informational                      [Page 6]
-
-RFC 2541        DNS Security Operational Considerations       March 1999
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                     Informational                      [Page 7]
-
diff --git a/contrib/bind9/doc/rfc/rfc2553.txt b/contrib/bind9/doc/rfc/rfc2553.txt
deleted file mode 100644
index 6989bf3..0000000
--- a/contrib/bind9/doc/rfc/rfc2553.txt
+++ /dev/null
@@ -1,2299 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        R. Gilligan
-Request for Comments: 2553                                      FreeGate
-Obsoletes: 2133                                               S. Thomson
-Category: Informational                                         Bellcore
-                                                                J. Bound
-                                                                  Compaq
-                                                              W. Stevens
-                                                              Consultant
-                                                              March 1999
-
-
-               Basic Socket Interface Extensions for IPv6
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-Abstract
-
-   The de facto standard application program interface (API) for TCP/IP
-   applications is the "sockets" interface.  Although this API was
-   developed for Unix in the early 1980s it has also been implemented on
-   a wide variety of non-Unix systems.  TCP/IP applications written
-   using the sockets API have in the past enjoyed a high degree of
-   portability and we would like the same portability with IPv6
-   applications.  But changes are required to the sockets API to support
-   IPv6 and this memo describes these changes.  These include a new
-   socket address structure to carry IPv6 addresses, new address
-   conversion functions, and some new socket options.  These extensions
-   are designed to provide access to the basic IPv6 features required by
-   TCP and UDP applications, including multicasting, while introducing a
-   minimum of change into the system and providing complete
-   compatibility for existing IPv4 applications.  Additional extensions
-   for advanced IPv6 features (raw sockets and access to the IPv6
-   extension headers) are defined in another document [4].
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                      [Page 1]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-Table of Contents
-
-   1. Introduction.................................................3
-   2. Design Considerations........................................3
-   2.1 What Needs to be Changed....................................4
-   2.2 Data Types..................................................5
-   2.3 Headers.....................................................5
-   2.4 Structures..................................................5
-   3. Socket Interface.............................................6
-   3.1 IPv6 Address Family and Protocol Family.....................6
-   3.2 IPv6 Address Structure......................................6
-   3.3 Socket Address Structure for 4.3BSD-Based Systems...........7
-   3.4 Socket Address Structure for 4.4BSD-Based Systems...........8
-   3.5 The Socket Functions........................................9
-   3.6 Compatibility with IPv4 Applications.......................10
-   3.7 Compatibility with IPv4 Nodes..............................10
-   3.8 IPv6 Wildcard Address......................................11
-   3.9 IPv6 Loopback Address......................................12
-   3.10 Portability Additions.....................................13
-   4. Interface Identification....................................16
-   4.1 Name-to-Index..............................................16
-   4.2 Index-to-Name..............................................17
-   4.3 Return All Interface Names and Indexes.....................17
-   4.4 Free Memory................................................18
-   5. Socket Options..............................................18
-   5.1 Unicast Hop Limit..........................................18
-   5.2 Sending and Receiving Multicast Packets....................19
-   6. Library Functions...........................................21
-   6.1 Nodename-to-Address Translation............................21
-   6.2 Address-To-Nodename Translation............................24
-   6.3 Freeing memory for getipnodebyname and getipnodebyaddr.....26
-   6.4 Protocol-Independent Nodename and Service Name Translation.26
-   6.5 Socket Address Structure to Nodename and Service Name......29
-   6.6 Address Conversion Functions...............................31
-   6.7 Address Testing Macros.....................................32
-   7. Summary of New Definitions..................................33
-   8. Security Considerations.....................................35
-   9. Year 2000 Considerations....................................35
-   Changes From RFC 2133..........................................35
-   Acknowledgments................................................38
-   References.....................................................39
-   Authors' Addresses.............................................40
-   Full Copyright Statement.......................................41
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                      [Page 2]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-1. Introduction
-
-   While IPv4 addresses are 32 bits long, IPv6 interfaces are identified
-   by 128-bit addresses.  The socket interface makes the size of an IP
-   address quite visible to an application; virtually all TCP/IP
-   applications for BSD-based systems have knowledge of the size of an
-   IP address.  Those parts of the API that expose the addresses must be
-   changed to accommodate the larger IPv6 address size.  IPv6 also
-   introduces new features (e.g., traffic class and flowlabel), some of
-   which must be made visible to applications via the API.  This memo
-   defines a set of extensions to the socket interface to support the
-   larger address size and new features of IPv6.
-
-2. Design Considerations
-
-   There are a number of important considerations in designing changes
-   to this well-worn API:
-
-      - The API changes should provide both source and binary
-        compatibility for programs written to the original API.  That
-        is, existing program binaries should continue to operate when
-        run on a system supporting the new API.  In addition, existing
-        applications that are re-compiled and run on a system supporting
-        the new API should continue to operate.  Simply put, the API
-        changes for IPv6 should not break existing programs.  An
-        additonal mechanism for implementations to verify this is to
-        verify the new symbols are protected by Feature Test Macros as
-        described in IEEE Std 1003.1.  (Such Feature Test Macros are not
-        defined by this RFC.)
-
-      - The changes to the API should be as small as possible in order
-        to simplify the task of converting existing IPv4 applications to
-        IPv6.
-
-      - Where possible, applications should be able to use this API to
-        interoperate with both IPv6 and IPv4 hosts.  Applications should
-        not need to know which type of host they are communicating with.
-
-      - IPv6 addresses carried in data structures should be 64-bit
-        aligned.  This is necessary in order to obtain optimum
-        performance on 64-bit machine architectures.
-
-   Because of the importance of providing IPv4 compatibility in the API,
-   these extensions are explicitly designed to operate on machines that
-   provide complete support for both IPv4 and IPv6.  A subset of this
-   API could probably be designed for operation on systems that support
-   only IPv6.  However, this is not addressed in this memo.
-
-
-
-
-Gilligan, et. al.            Informational                      [Page 3]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-2.1 What Needs to be Changed
-
-   The socket interface API consists of a few distinct components:
-
-      -  Core socket functions.
-
-      -  Address data structures.
-
-      -  Name-to-address translation functions.
-
-      -  Address conversion functions.
-
-   The core socket functions -- those functions that deal with such
-   things as setting up and tearing down TCP connections, and sending
-   and receiving UDP packets -- were designed to be transport
-   independent.  Where protocol addresses are passed as function
-   arguments, they are carried via opaque pointers.  A protocol-specific
-   address data structure is defined for each protocol that the socket
-   functions support.  Applications must cast pointers to these
-   protocol-specific address structures into pointers to the generic
-   "sockaddr" address structure when using the socket functions.  These
-   functions need not change for IPv6, but a new IPv6-specific address
-   data structure is needed.
-
-   The "sockaddr_in" structure is the protocol-specific data structure
-   for IPv4.  This data structure actually includes 8-octets of unused
-   space, and it is tempting to try to use this space to adapt the
-   sockaddr_in structure to IPv6.  Unfortunately, the sockaddr_in
-   structure is not large enough to hold the 16-octet IPv6 address as
-   well as the other information (address family and port number) that
-   is needed.  So a new address data structure must be defined for IPv6.
-
-   IPv6 addresses are scoped [2] so they could be link-local, site,
-   organization, global, or other scopes at this time undefined.  To
-   support applications that want to be able to identify a set of
-   interfaces for a specific scope, the IPv6 sockaddr_in structure must
-   support a field that can be used by an implementation to identify a
-   set of interfaces identifying the scope for an IPv6 address.
-
-   The name-to-address translation functions in the socket interface are
-   gethostbyname() and gethostbyaddr().  These are left as is and new
-   functions are defined to support IPv4 and IPv6.  Additionally, the
-   POSIX 1003.g draft [3] specifies a new nodename-to-address
-   translation function which is protocol independent.  This function
-   can also be used with IPv4 and IPv6.
-
-
-
-
-
-
-Gilligan, et. al.            Informational                      [Page 4]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   The address conversion functions -- inet_ntoa() and inet_addr() --
-   convert IPv4 addresses between binary and printable form.  These
-   functions are quite specific to 32-bit IPv4 addresses.  We have
-   designed two analogous functions that convert both IPv4 and IPv6
-   addresses, and carry an address type parameter so that they can be
-   extended to other protocol families as well.
-
-   Finally, a few miscellaneous features are needed to support IPv6.
-   New interfaces are needed to support the IPv6 traffic class, flow
-   label, and hop limit header fields.  New socket options are needed to
-   control the sending and receiving of IPv6 multicast packets.
-
-   The socket interface will be enhanced in the future to provide access
-   to other IPv6 features.  These extensions are described in [4].
-
-2.2 Data Types
-
-   The data types of the structure elements given in this memo are
-   intended to be examples, not absolute requirements.  Whenever
-   possible, data types from Draft 6.6 (March 1997) of POSIX 1003.1g are
-   used: uintN_t means an unsigned integer of exactly N bits (e.g.,
-   uint16_t).  We also assume the argument data types from 1003.1g when
-   possible (e.g., the final argument to setsockopt() is a size_t
-   value).  Whenever buffer sizes are specified, the POSIX 1003.1 size_t
-   data type is used (e.g., the two length arguments to getnameinfo()).
-
-2.3 Headers
-
-   When function prototypes and structures are shown we show the headers
-   that must be #included to cause that item to be defined.
-
-2.4 Structures
-
-   When structures are described the members shown are the ones that
-   must appear in an implementation.  Additional, nonstandard members
-   may also be defined by an implementation.  As an additional
-   precaution nonstandard members could be verified by Feature Test
-   Macros as described in IEEE Std 1003.1.  (Such Feature Test Macros
-   are not defined by this RFC.)
-
-   The ordering shown for the members of a structure is the recommended
-   ordering, given alignment considerations of multibyte members, but an
-   implementation may order the members differently.
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                      [Page 5]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-3. Socket Interface
-
-   This section specifies the socket interface changes for IPv6.
-
-3.1 IPv6 Address Family and Protocol Family
-
-   A new address family name, AF_INET6, is defined in <sys/socket.h>.
-   The AF_INET6 definition distinguishes between the original
-   sockaddr_in address data structure, and the new sockaddr_in6 data
-   structure.
-
-   A new protocol family name, PF_INET6, is defined in <sys/socket.h>.
-   Like most of the other protocol family names, this will usually be
-   defined to have the same value as the corresponding address family
-   name:
-
-      #define PF_INET6        AF_INET6
-
-   The PF_INET6 is used in the first argument to the socket() function
-   to indicate that an IPv6 socket is being created.
-
-3.2 IPv6 Address Structure
-
-   A new in6_addr structure holds a single IPv6 address and is defined
-   as a result of including <netinet/in.h>:
-
-      struct in6_addr {
-          uint8_t  s6_addr[16];      /* IPv6 address */
-      };
-
-   This data structure contains an array of sixteen 8-bit elements,
-   which make up one 128-bit IPv6 address.  The IPv6 address is stored
-   in network byte order.
-
-   The structure in6_addr above is usually implemented with an embedded
-   union with extra fields that force the desired alignment level in a
-   manner similar to BSD implementations of "struct in_addr". Those
-   additional implementation details are omitted here for simplicity.
-
-   An example is as follows:
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                      [Page 6]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   struct in6_addr {
-        union {
-            uint8_t  _S6_u8[16];
-            uint32_t _S6_u32[4];
-            uint64_t _S6_u64[2];
-        } _S6_un;
-   };
-   #define s6_addr _S6_un._S6_u8
-
-3.3 Socket Address Structure for 4.3BSD-Based Systems
-
-   In the socket interface, a different protocol-specific data structure
-   is defined to carry the addresses for each protocol suite.  Each
-   protocol- specific data structure is designed so it can be cast into a
-   protocol- independent data structure -- the "sockaddr" structure.
-   Each has a "family" field that overlays the "sa_family" of the
-   sockaddr data structure.  This field identifies the type of the data
-   structure.
-
-   The sockaddr_in structure is the protocol-specific address data
-   structure for IPv4.  It is used to pass addresses between applications
-   and the system in the socket functions.  The following sockaddr_in6
-   structure holds IPv6 addresses and is defined as a result of including
-   the <netinet/in.h> header:
-
-struct sockaddr_in6 {
-    sa_family_t     sin6_family;    /* AF_INET6 */
-    in_port_t       sin6_port;      /* transport layer port # */
-    uint32_t        sin6_flowinfo;  /* IPv6 traffic class & flow info */
-    struct in6_addr sin6_addr;      /* IPv6 address */
-    uint32_t        sin6_scope_id;  /* set of interfaces for a scope */
-};
-
-   This structure is designed to be compatible with the sockaddr data
-   structure used in the 4.3BSD release.
-
-   The sin6_family field identifies this as a sockaddr_in6 structure.
-   This field overlays the sa_family field when the buffer is cast to a
-   sockaddr data structure.  The value of this field must be AF_INET6.
-
-   The sin6_port field contains the 16-bit UDP or TCP port number.  This
-   field is used in the same way as the sin_port field of the
-   sockaddr_in structure.  The port number is stored in network byte
-   order.
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                      [Page 7]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   The sin6_flowinfo field is a 32-bit field that contains two pieces of
-   information: the traffic class and the flow label.  The contents and
-   interpretation of this member is specified in [1].  The sin6_flowinfo
-   field SHOULD be set to zero by an implementation prior to using the
-   sockaddr_in6 structure by an application on receive operations.
-
-   The sin6_addr field is a single in6_addr structure (defined in the
-   previous section).  This field holds one 128-bit IPv6 address.  The
-   address is stored in network byte order.
-
-   The ordering of elements in this structure is specifically designed
-   so that when sin6_addr field is aligned on a 64-bit boundary, the
-   start of the structure will also be aligned on a 64-bit boundary.
-   This is done for optimum performance on 64-bit architectures.
-
-   The sin6_scope_id field is a 32-bit integer that identifies a set of
-   interfaces as appropriate for the scope of the address carried in the
-   sin6_addr field.  For a link scope sin6_addr sin6_scope_id would be
-   an interface index.  For a site scope sin6_addr, sin6_scope_id would
-   be a site identifier.  The mapping of sin6_scope_id to an interface
-   or set of interfaces is left to implementation and future
-   specifications on the subject of site identifiers.
-
-   Notice that the sockaddr_in6 structure will normally be larger than
-   the generic sockaddr structure.  On many existing implementations the
-   sizeof(struct sockaddr_in) equals sizeof(struct sockaddr), with both
-   being 16 bytes.  Any existing code that makes this assumption needs
-   to be examined carefully when converting to IPv6.
-
-3.4 Socket Address Structure for 4.4BSD-Based Systems
-
-   The 4.4BSD release includes a small, but incompatible change to the
-   socket interface.  The "sa_family" field of the sockaddr data
-   structure was changed from a 16-bit value to an 8-bit value, and the
-   space saved used to hold a length field, named "sa_len".  The
-   sockaddr_in6 data structure given in the previous section cannot be
-   correctly cast into the newer sockaddr data structure.  For this
-   reason, the following alternative IPv6 address data structure is
-   provided to be used on systems based on 4.4BSD.  It is defined as a
-   result of including the <netinet/in.h> header.
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                      [Page 8]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-struct sockaddr_in6 {
-    uint8_t         sin6_len;       /* length of this struct */
-    sa_family_t     sin6_family;    /* AF_INET6 */
-    in_port_t       sin6_port;      /* transport layer port # */
-    uint32_t        sin6_flowinfo;  /* IPv6 flow information */
-    struct in6_addr sin6_addr;      /* IPv6 address */
-    uint32_t        sin6_scope_id;  /* set of interfaces for a scope */
-};
-
-   The only differences between this data structure and the 4.3BSD
-   variant are the inclusion of the length field, and the change of the
-   family field to a 8-bit data type.  The definitions of all the other
-   fields are identical to the structure defined in the previous
-   section.
-
-   Systems that provide this version of the sockaddr_in6 data structure
-   must also declare SIN6_LEN as a result of including the
-   <netinet/in.h> header.  This macro allows applications to determine
-   whether they are being built on a system that supports the 4.3BSD or
-   4.4BSD variants of the data structure.
-
-3.5 The Socket Functions
-
-   Applications call the socket() function to create a socket descriptor
-   that represents a communication endpoint.  The arguments to the
-   socket() function tell the system which protocol to use, and what
-   format address structure will be used in subsequent functions.  For
-   example, to create an IPv4/TCP socket, applications make the call:
-
-      s = socket(PF_INET, SOCK_STREAM, 0);
-
-   To create an IPv4/UDP socket, applications make the call:
-
-      s = socket(PF_INET, SOCK_DGRAM, 0);
-
-   Applications may create IPv6/TCP and IPv6/UDP sockets by simply using
-   the constant PF_INET6 instead of PF_INET in the first argument.  For
-   example, to create an IPv6/TCP socket, applications make the call:
-
-      s = socket(PF_INET6, SOCK_STREAM, 0);
-
-   To create an IPv6/UDP socket, applications make the call:
-
-      s = socket(PF_INET6, SOCK_DGRAM, 0);
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                      [Page 9]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   Once the application has created a PF_INET6 socket, it must use the
-   sockaddr_in6 address structure when passing addresses in to the
-   system.  The functions that the application uses to pass addresses
-   into the system are:
-
-      bind()
-      connect()
-      sendmsg()
-      sendto()
-
-   The system will use the sockaddr_in6 address structure to return
-   addresses to applications that are using PF_INET6 sockets.  The
-   functions that return an address from the system to an application
-   are:
-
-      accept()
-      recvfrom()
-      recvmsg()
-      getpeername()
-      getsockname()
-
-   No changes to the syntax of the socket functions are needed to
-   support IPv6, since all of the "address carrying" functions use an
-   opaque address pointer, and carry an address length as a function
-   argument.
-
-3.6 Compatibility with IPv4 Applications
-
-   In order to support the large base of applications using the original
-   API, system implementations must provide complete source and binary
-   compatibility with the original API.  This means that systems must
-   continue to support PF_INET sockets and the sockaddr_in address
-   structure.  Applications must be able to create IPv4/TCP and IPv4/UDP
-   sockets using the PF_INET constant in the socket() function, as
-   described in the previous section.  Applications should be able to
-   hold a combination of IPv4/TCP, IPv4/UDP, IPv6/TCP and IPv6/UDP
-   sockets simultaneously within the same process.
-
-   Applications using the original API should continue to operate as
-   they did on systems supporting only IPv4.  That is, they should
-   continue to interoperate with IPv4 nodes.
-
-3.7 Compatibility with IPv4 Nodes
-
-   The API also provides a different type of compatibility: the ability
-   for IPv6 applications to interoperate with IPv4 applications.  This
-   feature uses the IPv4-mapped IPv6 address format defined in the IPv6
-   addressing architecture specification [2].  This address format
-
-
-
-Gilligan, et. al.            Informational                     [Page 10]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   allows the IPv4 address of an IPv4 node to be represented as an IPv6
-   address.  The IPv4 address is encoded into the low-order 32 bits of
-   the IPv6 address, and the high-order 96 bits hold the fixed prefix
-   0:0:0:0:0:FFFF.  IPv4- mapped addresses are written as follows:
-
-      ::FFFF:<IPv4-address>
-
-   These addresses can be generated automatically by the
-   getipnodebyname() function when the specified host has only IPv4
-   addresses (as described in Section 6.1).
-
-   Applications may use PF_INET6 sockets to open TCP connections to IPv4
-   nodes, or send UDP packets to IPv4 nodes, by simply encoding the
-   destination's IPv4 address as an IPv4-mapped IPv6 address, and
-   passing that address, within a sockaddr_in6 structure, in the
-   connect() or sendto() call.  When applications use PF_INET6 sockets
-   to accept TCP connections from IPv4 nodes, or receive UDP packets
-   from IPv4 nodes, the system returns the peer's address to the
-   application in the accept(), recvfrom(), or getpeername() call using
-   a sockaddr_in6 structure encoded this way.
-
-   Few applications will likely need to know which type of node they are
-   interoperating with.  However, for those applications that do need to
-   know, the IN6_IS_ADDR_V4MAPPED() macro, defined in Section 6.7, is
-   provided.
-
-3.8 IPv6 Wildcard Address
-
-   While the bind() function allows applications to select the source IP
-   address of UDP packets and TCP connections, applications often want
-   the system to select the source address for them.  With IPv4, one
-   specifies the address as the symbolic constant INADDR_ANY (called the
-   "wildcard" address) in the bind() call, or simply omits the bind()
-   entirely.
-
-   Since the IPv6 address type is a structure (struct in6_addr), a
-   symbolic constant can be used to initialize an IPv6 address variable,
-   but cannot be used in an assignment.  Therefore systems provide the
-   IPv6 wildcard address in two forms.
-
-   The first version is a global variable named "in6addr_any" that is an
-   in6_addr structure.  The extern declaration for this variable is
-   defined in <netinet/in.h>:
-
-      extern const struct in6_addr in6addr_any;
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 11]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   Applications use in6addr_any similarly to the way they use INADDR_ANY
-   in IPv4.  For example, to bind a socket to port number 23, but let
-   the system select the source address, an application could use the
-   following code:
-
-      struct sockaddr_in6 sin6;
-       . . .
-      sin6.sin6_family = AF_INET6;
-      sin6.sin6_flowinfo = 0;
-      sin6.sin6_port = htons(23);
-      sin6.sin6_addr = in6addr_any;  /* structure assignment */
-       . . .
-      if (bind(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
-              . . .
-
-   The other version is a symbolic constant named IN6ADDR_ANY_INIT and
-   is defined in <netinet/in.h>.  This constant can be used to
-   initialize an in6_addr structure:
-
-      struct in6_addr anyaddr = IN6ADDR_ANY_INIT;
-
-   Note that this constant can be used ONLY at declaration time.  It can
-   not be used to assign a previously declared in6_addr structure.  For
-   example, the following code will not work:
-
-      /* This is the WRONG way to assign an unspecified address */
-      struct sockaddr_in6 sin6;
-       . . .
-      sin6.sin6_addr = IN6ADDR_ANY_INIT; /* will NOT compile */
-
-   Be aware that the IPv4 INADDR_xxx constants are all defined in host
-   byte order but the IPv6 IN6ADDR_xxx constants and the IPv6
-   in6addr_xxx externals are defined in network byte order.
-
-3.9 IPv6 Loopback Address
-
-   Applications may need to send UDP packets to, or originate TCP
-   connections to, services residing on the local node.  In IPv4, they
-   can do this by using the constant IPv4 address INADDR_LOOPBACK in
-   their connect(), sendto(), or sendmsg() call.
-
-   IPv6 also provides a loopback address to contact local TCP and UDP
-   services.  Like the unspecified address, the IPv6 loopback address is
-   provided in two forms -- a global variable and a symbolic constant.
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 12]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   The global variable is an in6_addr structure named
-   "in6addr_loopback."  The extern declaration for this variable is
-   defined in <netinet/in.h>:
-
-      extern const struct in6_addr in6addr_loopback;
-
-   Applications use in6addr_loopback as they would use INADDR_LOOPBACK
-   in IPv4 applications (but beware of the byte ordering difference
-   mentioned at the end of the previous section).  For example, to open
-   a TCP connection to the local telnet server, an application could use
-   the following code:
-
-      struct sockaddr_in6 sin6;
-       . . .
-      sin6.sin6_family = AF_INET6;
-      sin6.sin6_flowinfo = 0;
-      sin6.sin6_port = htons(23);
-      sin6.sin6_addr = in6addr_loopback;  /* structure assignment */
-       . . .
-      if (connect(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
-              . . .
-
-   The symbolic constant is named IN6ADDR_LOOPBACK_INIT and is defined
-   in <netinet/in.h>.  It can be used at declaration time ONLY; for
-   example:
-
-      struct in6_addr loopbackaddr = IN6ADDR_LOOPBACK_INIT;
-
-   Like IN6ADDR_ANY_INIT, this constant cannot be used in an assignment
-   to a previously declared IPv6 address variable.
-
-3.10 Portability Additions
-
-   One simple addition to the sockets API that can help application
-   writers is the "struct sockaddr_storage". This data structure can
-   simplify writing code portable across multiple address families and
-   platforms.  This data structure is designed with the following goals.
-
-      - It has a large enough implementation specific maximum size to
-        store the desired set of protocol specific socket address data
-        structures. Specifically, it is at least large enough to
-        accommodate sockaddr_in and sockaddr_in6 and possibly other
-        protocol specific socket addresses too.
-      - It is aligned at an appropriate boundary so protocol specific
-        socket address data structure pointers can be cast to it and
-        access their fields without alignment problems. (e.g. pointers
-        to sockaddr_in6 and/or sockaddr_in can be cast to it and access
-        fields without alignment problems).
-
-
-
-Gilligan, et. al.            Informational                     [Page 13]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-      - It has the initial field(s) isomorphic to the fields of the
-        "struct sockaddr" data structure on that implementation which
-        can be used as a discriminants for deriving the protocol in use.
-        These initial field(s) would on most implementations either be a
-        single field of type "sa_family_t" (isomorphic to sa_family
-        field, 16 bits) or two fields of type uint8_t and sa_family_t
-        respectively, (isomorphic to sa_len and sa_family_t, 8 bits
-        each).
-
-   An example implementation design of such a data structure would be as
-   follows.
-
-/*
- * Desired design of maximum size and alignment
- */
-#define _SS_MAXSIZE    128  /* Implementation specific max size */
-#define _SS_ALIGNSIZE  (sizeof (int64_t))
-                         /* Implementation specific desired alignment */
-/*
- * Definitions used for sockaddr_storage structure paddings design.
- */
-#define _SS_PAD1SIZE   (_SS_ALIGNSIZE - sizeof (sa_family_t))
-#define _SS_PAD2SIZE   (_SS_MAXSIZE - (sizeof (sa_family_t)+
-                              _SS_PAD1SIZE + _SS_ALIGNSIZE))
-struct sockaddr_storage {
-    sa_family_t  __ss_family;     /* address family */
-    /* Following fields are implementation specific */
-    char      __ss_pad1[_SS_PAD1SIZE];
-              /* 6 byte pad, this is to make implementation
-              /* specific pad up to alignment field that */
-              /* follows explicit in the data structure */
-    int64_t   __ss_align;     /* field to force desired structure */
-               /* storage alignment */
-    char      __ss_pad2[_SS_PAD2SIZE];
-              /* 112 byte pad to achieve desired size, */
-              /* _SS_MAXSIZE value minus size of ss_family */
-              /* __ss_pad1, __ss_align fields is 112 */
-};
-
-   On implementations where sockaddr data structure includes a "sa_len",
-   field this data structure would look like this:
-
-/*
- * Definitions used for sockaddr_storage structure paddings design.
- */
-#define _SS_PAD1SIZE (_SS_ALIGNSIZE -
-                            (sizeof (uint8_t) + sizeof (sa_family_t))
-#define _SS_PAD2SIZE (_SS_MAXSIZE - (sizeof (sa_family_t)+
-
-
-
-Gilligan, et. al.            Informational                     [Page 14]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-                              _SS_PAD1SIZE + _SS_ALIGNSIZE))
-struct sockaddr_storage {
-    uint8_t      __ss_len;        /* address length */
-    sa_family_t  __ss_family;     /* address family */
-    /* Following fields are implementation specific */
-    char         __ss_pad1[_SS_PAD1SIZE];
-                  /* 6 byte pad, this is to make implementation
-                  /* specific pad up to alignment field that */
-                  /* follows explicit in the data structure */
-    int64_t      __ss_align;  /* field to force desired structure */
-                  /* storage alignment */
-    char         __ss_pad2[_SS_PAD2SIZE];
-                  /* 112 byte pad to achieve desired size, */
-                  /* _SS_MAXSIZE value minus size of ss_len, */
-                  /* __ss_family, __ss_pad1, __ss_align fields is 112 */
-};
-
-   The above example implementation illustrates a data structure which
-   will align on a 64 bit boundary. An implementation specific field
-   "__ss_align" along "__ss_pad1" is used to force a 64-bit alignment
-   which covers proper alignment good enough for needs of sockaddr_in6
-   (IPv6), sockaddr_in (IPv4) address data structures.  The size of
-   padding fields __ss_pad1 depends on the chosen alignment boundary.
-   The size of padding field __ss_pad2 depends on the value of overall
-   size chosen for the total size of the structure. This size and
-   alignment are represented in the above example by implementation
-   specific (not required) constants _SS_MAXSIZE (chosen value 128) and
-   _SS_ALIGNMENT (with chosen value 8).  Constants _SS_PAD1SIZE (derived
-   value 6) and _SS_PAD2SIZE (derived value 112) are also for
-   illustration and not required.  The implementation specific
-   definitions and structure field names above start with an underscore
-   to denote implementation private namespace.  Portable code is not
-   expected to access or reference those fields or constants.
-
-   The sockaddr_storage structure solves the problem of declaring
-   storage for automatic variables which is large enough and aligned
-   enough for storing socket address data structure of any family. For
-   example, code with a file descriptor and without the context of the
-   address family can pass a pointer to a variable of this type where a
-   pointer to a socket address structure is expected in calls such as
-   getpeername() and determine the address family by accessing the
-   received content after the call.
-
-   The sockaddr_storage structure may also be useful and applied to
-   certain other interfaces where a generic socket address large enough
-   and aligned for use with multiple address families may be needed. A
-   discussion of those interfaces is outside the scope of this document.
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 15]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   Also, much existing code assumes that any socket address structure
-   can fit in a generic sockaddr structure.  While this has been true
-   for IPv4 socket address structures, it has always been false for Unix
-   domain socket address structures (but in practice this has not been a
-   problem) and it is also false for IPv6 socket address structures
-   (which can be a problem).
-
-   So now an application can do the following:
-
-      struct sockaddr_storage __ss;
-      struct sockaddr_in6 *sin6;
-      sin6 = (struct sockaddr_in6 *) &__ss;
-
-4. Interface Identification
-
-   This API uses an interface index (a small positive integer) to
-   identify the local interface on which a multicast group is joined
-   (Section 5.3).  Additionally, the advanced API [4] uses these same
-   interface indexes to identify the interface on which a datagram is
-   received, or to specify the interface on which a datagram is to be
-   sent.
-
-   Interfaces are normally known by names such as "le0", "sl1", "ppp2",
-   and the like.  On Berkeley-derived implementations, when an interface
-   is made known to the system, the kernel assigns a unique positive
-   integer value (called the interface index) to that interface.  These
-   are small positive integers that start at 1.  (Note that 0 is never
-   used for an interface index.) There may be gaps so that there is no
-   current interface for a particular positive interface index.
-
-   This API defines two functions that map between an interface name and
-   index, a third function that returns all the interface names and
-   indexes, and a fourth function to return the dynamic memory allocated
-   by the previous function.  How these functions are implemented is
-   left up to the implementation.  4.4BSD implementations can implement
-   these functions using the existing sysctl() function with the
-   NET_RT_IFLIST command.  Other implementations may wish to use ioctl()
-   for this purpose.
-
-4.1 Name-to-Index
-
-   The first function maps an interface name into its corresponding
-   index.
-
-      #include <net/if.h>
-
-      unsigned int  if_nametoindex(const char *ifname);
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 16]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   If the specified interface name does not exist, the return value is
-   0, and errno is set to ENXIO.  If there was a system error (such as
-   running out of memory), the return value is 0 and errno is set to the
-   proper value (e.g., ENOMEM).
-
-4.2 Index-to-Name
-
-   The second function maps an interface index into its corresponding
-   name.
-
-      #include <net/if.h>
-
-      char  *if_indextoname(unsigned int ifindex, char *ifname);
-
-   The ifname argument must point to a buffer of at least IF_NAMESIZE
-   bytes into which the interface name corresponding to the specified
-   index is returned.  (IF_NAMESIZE is also defined in <net/if.h> and
-   its value includes a terminating null byte at the end of the
-   interface name.) This pointer is also the return value of the
-   function.  If there is no interface corresponding to the specified
-   index, NULL is returned, and errno is set to ENXIO, if there was a
-   system error (such as running out of memory), if_indextoname returns
-   NULL and errno would be set to the proper value (e.g., ENOMEM).
-
-4.3 Return All Interface Names and Indexes
-
-   The if_nameindex structure holds the information about a single
-   interface and is defined as a result of including the <net/if.h>
-   header.
-
-      struct if_nameindex {
-        unsigned int   if_index;  /* 1, 2, ... */
-        char          *if_name;   /* null terminated name: "le0", ... */
-      };
-
-   The final function returns an array of if_nameindex structures, one
-   structure per interface.
-
-      struct if_nameindex  *if_nameindex(void);
-
-   The end of the array of structures is indicated by a structure with
-   an if_index of 0 and an if_name of NULL.  The function returns a NULL
-   pointer upon an error, and would set errno to the appropriate value.
-
-   The memory used for this array of structures along with the interface
-   names pointed to by the if_name members is obtained dynamically.
-   This memory is freed by the next function.
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 17]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-4.4 Free Memory
-
-   The following function frees the dynamic memory that was allocated by
-   if_nameindex().
-
-      #include <net/if.h>
-
-      void  if_freenameindex(struct if_nameindex *ptr);
-
-   The argument to this function must be a pointer that was returned by
-   if_nameindex().
-
-   Currently net/if.h doesn't have prototype definitions for functions
-   and it is recommended that these definitions be defined in net/if.h
-   as well and the struct if_nameindex{}.
-
-5. Socket Options
-
-   A number of new socket options are defined for IPv6.  All of these
-   new options are at the IPPROTO_IPV6 level.  That is, the "level"
-   parameter in the getsockopt() and setsockopt() calls is IPPROTO_IPV6
-   when using these options.  The constant name prefix IPV6_ is used in
-   all of the new socket options.  This serves to clearly identify these
-   options as applying to IPv6.
-
-   The declaration for IPPROTO_IPV6, the new IPv6 socket options, and
-   related constants defined in this section are obtained by including
-   the header <netinet/in.h>.
-
-5.1 Unicast Hop Limit
-
-   A new setsockopt() option controls the hop limit used in outgoing
-   unicast IPv6 packets.  The name of this option is IPV6_UNICAST_HOPS,
-   and it is used at the IPPROTO_IPV6 layer.  The following example
-   illustrates how it is used:
-
-      int  hoplimit = 10;
-
-      if (setsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
-                     (char *) &hoplimit, sizeof(hoplimit)) == -1)
-          perror("setsockopt IPV6_UNICAST_HOPS");
-
-   When the IPV6_UNICAST_HOPS option is set with setsockopt(), the
-   option value given is used as the hop limit for all subsequent
-   unicast packets sent via that socket.  If the option is not set, the
-   system selects a default value.  The integer hop limit value (called
-   x) is interpreted as follows:
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 18]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-      x < -1:        return an error of EINVAL
-      x == -1:       use kernel default
-      0 <= x <= 255: use x
-      x >= 256:      return an error of EINVAL
-
-   The IPV6_UNICAST_HOPS option may be used with getsockopt() to
-   determine the hop limit value that the system will use for subsequent
-   unicast packets sent via that socket.  For example:
-
-      int  hoplimit;
-      size_t  len = sizeof(hoplimit);
-
-      if (getsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
-                     (char *) &hoplimit, &len) == -1)
-          perror("getsockopt IPV6_UNICAST_HOPS");
-      else
-          printf("Using %d for hop limit.\n", hoplimit);
-
-5.2 Sending and Receiving Multicast Packets
-
-   IPv6 applications may send UDP multicast packets by simply specifying
-   an IPv6 multicast address in the address argument of the sendto()
-   function.
-
-   Three socket options at the IPPROTO_IPV6 layer control some of the
-   parameters for sending multicast packets.  Setting these options is
-   not required: applications may send multicast packets without using
-   these options.  The setsockopt() options for controlling the sending
-   of multicast packets are summarized below.  These three options can
-   also be used with getsockopt().
-
-      IPV6_MULTICAST_IF
-
-         Set the interface to use for outgoing multicast packets.  The
-         argument is the index of the interface to use.
-
-         Argument type: unsigned int
-
-      IPV6_MULTICAST_HOPS
-
-         Set the hop limit to use for outgoing multicast packets.  (Note
-         a separate option - IPV6_UNICAST_HOPS - is provided to set the
-         hop limit to use for outgoing unicast packets.)
-
-         The interpretation of the argument is the same as for the
-         IPV6_UNICAST_HOPS option:
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 19]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-           x < -1:        return an error of EINVAL
-           x == -1:       use kernel default
-           0 <= x <= 255: use x
-           x >= 256:      return an error of EINVAL
-
-           If IPV6_MULTICAST_HOPS is not set, the default is 1
-           (same as IPv4 today)
-
-         Argument type: int
-
-      IPV6_MULTICAST_LOOP
-
-         If a multicast datagram is sent to a group to which the sending
-         host itself belongs (on the outgoing interface), a copy of the
-         datagram is looped back by the IP layer for local delivery if
-         this option is set to 1.  If this option is set to 0 a copy
-         is not looped back.  Other option values return an error of
-         EINVAL.
-
-         If IPV6_MULTICAST_LOOP is not set, the default is 1 (loopback;
-         same as IPv4 today).
-
-         Argument type: unsigned int
-
-   The reception of multicast packets is controlled by the two
-   setsockopt() options summarized below.  An error of EOPNOTSUPP is
-   returned if these two options are used with getsockopt().
-
-      IPV6_JOIN_GROUP
-
-         Join a multicast group on a specified local interface.  If the
-         interface index is specified as 0, the kernel chooses the local
-         interface.  For example, some kernels look up the multicast
-         group in the normal IPv6 routing table and using the resulting
-         interface.
-
-         Argument type: struct ipv6_mreq
-
-      IPV6_LEAVE_GROUP
-
-         Leave a multicast group on a specified interface.
-
-         Argument type: struct ipv6_mreq
-
-   The argument type of both of these options is the ipv6_mreq structure,
-   defined as a result of including the <netinet/in.h> header;
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 20]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   struct ipv6_mreq {
-       struct in6_addr ipv6mr_multiaddr; /* IPv6 multicast addr */
-       unsigned int    ipv6mr_interface; /* interface index */
-   };
-
-   Note that to receive multicast datagrams a process must join the
-   multicast group and bind the UDP port to which datagrams will be
-   sent.  Some processes also bind the multicast group address to the
-   socket, in addition to the port, to prevent other datagrams destined
-   to that same port from being delivered to the socket.
-
-6. Library Functions
-
-   New library functions are needed to perform a variety of operations
-   with IPv6 addresses.  Functions are needed to lookup IPv6 addresses
-   in the Domain Name System (DNS).  Both forward lookup (nodename-to-
-   address translation) and reverse lookup (address-to-nodename
-   translation) need to be supported.  Functions are also needed to
-   convert IPv6 addresses between their binary and textual form.
-
-   We note that the two existing functions, gethostbyname() and
-   gethostbyaddr(), are left as-is.  New functions are defined to handle
-   both IPv4 and IPv6 addresses.
-
-6.1 Nodename-to-Address Translation
-
-   The commonly used function gethostbyname() is inadequate for many
-   applications, first because it provides no way for the caller to
-   specify anything about the types of addresses desired (IPv4 only,
-   IPv6 only, IPv4-mapped IPv6 are OK, etc.), and second because many
-   implementations of this function are not thread safe.  RFC 2133
-   defined a function named gethostbyname2() but this function was also
-   inadequate, first because its use required setting a global option
-   (RES_USE_INET6) when IPv6 addresses were required, and second because
-   a flag argument is needed to provide the caller with additional
-   control over the types of addresses required.
-
-   The following function is new and must be thread safe:
-
-   #include <sys/socket.h>
-   #include <netdb.h>
-
-   struct hostent *getipnodebyname(const char *name, int af, int flags
-                                       int *error_num);
-
-   The name argument can be either a node name or a numeric address
-   string (i.e., a dotted-decimal IPv4 address or an IPv6 hex address).
-   The af argument specifies the address family, either AF_INET or
-
-
-
-Gilligan, et. al.            Informational                     [Page 21]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   AF_INET6. The error_num value is returned to the caller, via a
-   pointer, with the appropriate error code in error_num, to support
-   thread safe error code returns.  error_num will be set to one of the
-   following values:
-
-      HOST_NOT_FOUND
-
-         No such host is known.
-
-      NO_ADDRESS
-
-         The server recognised the request and the name but no address is
-         available.  Another type of request to the name server for the
-         domain might return an answer.
-
-      NO_RECOVERY
-
-         An unexpected server failure occurred which cannot be recovered.
-
-      TRY_AGAIN
-
-         A temporary and possibly transient error occurred, such as a
-         failure of a server to respond.
-
-   The flags argument specifies the types of addresses that are searched
-   for, and the types of addresses that are returned.  We note that a
-   special flags value of AI_DEFAULT (defined below) should handle most
-   applications.
-
-   That is, porting simple applications to use IPv6 replaces the call
-
-      hptr = gethostbyname(name);
-
-   with
-
-      hptr = getipnodebyname(name, AF_INET6, AI_DEFAULT, &error_num);
-
-   and changes any subsequent error diagnosis code to use error_num
-   instead of externally declared variables, such as h_errno.
-
-   Applications desiring finer control over the types of addresses
-   searched for and returned, can specify other combinations of the
-   flags argument.
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 22]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   A flags of 0 implies a strict interpretation of the af argument:
-
-      - If flags is 0 and af is AF_INET, then the caller wants only
-        IPv4 addresses.  A query is made for A records.  If successful,
-        the IPv4 addresses are returned and the h_length member of the
-        hostent structure will be 4, else the function returns a NULL
-        pointer.
-
-      -  If flags is 0 and if af is AF_INET6, then the caller wants only
-        IPv6 addresses.  A query is made for AAAA records.  If
-        successful, the IPv6 addresses are returned and the h_length
-        member of the hostent structure will be 16, else the function
-        returns a NULL pointer.
-
-   Other constants can be logically-ORed into the flags argument, to
-   modify the behavior of the function.
-
-      - If the AI_V4MAPPED flag is specified along with an af of
-        AF_INET6, then the caller will accept IPv4-mapped IPv6
-        addresses.  That is, if no AAAA records are found then a query
-        is made for A records and any found are returned as IPv4-mapped
-        IPv6 addresses (h_length will be 16).  The AI_V4MAPPED flag is
-        ignored unless af equals AF_INET6.
-
-      - The AI_ALL flag is used in conjunction with the AI_V4MAPPED
-        flag, and is only used with the IPv6 address family.  When AI_ALL
-        is logically or'd with AI_V4MAPPED flag then the caller wants
-        all addresses: IPv6 and IPv4-mapped IPv6.  A query is first made
-        for AAAA records and if successful, the IPv6 addresses are
-        returned. Another query is then made for A records and any found
-        are returned as IPv4-mapped IPv6 addresses. h_length will be 16.
-        Only if both queries fail does the function return a NULL pointer.
-        This flag is ignored unless af equals AF_INET6.
-
-      - The AI_ADDRCONFIG flag specifies that a query for AAAA records
-        should occur only if the node has at least one IPv6 source
-        address configured and a query for A records should occur only
-        if the node has at least one IPv4 source address configured.
-
-        For example, if the node has no IPv6 source addresses
-        configured, and af equals AF_INET6, and the node name being
-        looked up has both AAAA and A records, then:
-
-            (a) if only AI_ADDRCONFIG is specified, the function
-                returns a NULL pointer;
-            (b) if AI_ADDRCONFIG | AI_V4MAPPED is specified, the A
-                records are returned as IPv4-mapped IPv6 addresses;
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 23]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   The special flags value of AI_DEFAULT is defined as
-
-      #define  AI_DEFAULT  (AI_V4MAPPED | AI_ADDRCONFIG)
-
-   We noted that the getipnodebyname() function must allow the name
-   argument to be either a node name or a literal address string (i.e.,
-   a dotted-decimal IPv4 address or an IPv6 hex address).  This saves
-   applications from having to call inet_pton() to handle literal
-   address strings.
-
-   There are four scenarios based on the type of literal address string
-   and the value of the af argument.
-
-   The two simple cases are:
-
-   When name is a dotted-decimal IPv4 address and af equals AF_INET, or
-   when name is an IPv6 hex address and af equals AF_INET6.  The members
-   of the returned hostent structure are: h_name points to a copy of the
-   name argument, h_aliases is a NULL pointer, h_addrtype is a copy of
-   the af argument, h_length is either 4 (for AF_INET) or 16 (for
-   AF_INET6), h_addr_list[0] is a pointer to the 4-byte or 16-byte
-   binary address, and h_addr_list[1] is a NULL pointer.
-
-   When name is a dotted-decimal IPv4 address and af equals AF_INET6,
-   and flags equals AI_V4MAPPED, an IPv4-mapped IPv6 address is
-   returned:  h_name points to an IPv6 hex address containing the IPv4-
-   mapped IPv6 address, h_aliases is a NULL pointer, h_addrtype is
-   AF_INET6, h_length is 16, h_addr_list[0] is a pointer to the 16-byte
-   binary address, and h_addr_list[1] is a NULL pointer.  If AI_V4MAPPED
-   is set (with or without AI_ALL) return IPv4-mapped otherwise return
-   NULL.
-
-   It is an error when name is an IPv6 hex address and af equals
-   AF_INET.  The function's return value is a NULL pointer and error_num
-   equals HOST_NOT_FOUND.
-
-6.2 Address-To-Nodename Translation
-
-   The following function has the same arguments as the existing
-   gethostbyaddr() function, but adds an error number.
-
-      #include <sys/socket.h> #include <netdb.h>
-
-      struct hostent *getipnodebyaddr(const void *src, size_t len,
-                                          int af, int *error_num);
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 24]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   As with getipnodebyname(), getipnodebyaddr() must be thread safe.
-   The error_num value is returned to the caller with the appropriate
-   error code, to support thread safe error code returns.  The following
-   error conditions may be returned for error_num:
-
-      HOST_NOT_FOUND
-
-         No such host is known.
-
-      NO_ADDRESS
-
-         The server recognized the request and the name but no address
-         is available.  Another type of request to the name server for
-         the domain might return an answer.
-
-      NO_RECOVERY
-
-         An unexpected server failure occurred which cannot be
-         recovered.
-
-      TRY_AGAIN
-
-         A temporary and possibly transient error occurred, such as a
-         failure of a server to respond.
-
-   One possible source of confusion is the handling of IPv4-mapped IPv6
-   addresses and IPv4-compatible IPv6 addresses, but the following logic
-   should apply.
-
-      1.  If af is AF_INET6, and if len equals 16, and if the IPv6
-          address is an IPv4-mapped IPv6 address or an IPv4-compatible
-          IPv6 address, then skip over the first 12 bytes of the IPv6
-          address, set af to AF_INET, and set len to 4.
-
-      2.  If af is AF_INET, lookup the name for the given IPv4 address
-          (e.g., query for a PTR record in the in-addr.arpa domain).
-
-      3.  If af is AF_INET6, lookup the name for the given IPv6 address
-          (e.g., query for a PTR record in the ip6.int domain).
-
-      4.  If the function is returning success, then the single address
-          that is returned in the hostent structure is a copy of the
-          first argument to the function with the same address family
-          that was passed as an argument to this function.
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 25]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   All four steps listed are performed, in order.  Also note that the
-   IPv6 hex addresses "::" and "::1" MUST NOT be treated as IPv4-
-   compatible addresses, and if the address is "::", HOST_NOT_FOUND MUST
-   be returned and a query of the address not performed.
-
-   Also for the macro in section 6.7 IN6_IS_ADDR_V4COMPAT MUST return
-   false for "::" and "::1".
-
-6.3 Freeing memory for getipnodebyname and getipnodebyaddr
-
-   The hostent structure does not change from its existing definition.
-   This structure, and the information pointed to by this structure, are
-   dynamically allocated by getipnodebyname and getipnodebyaddr.  The
-   following function frees this memory:
-
-      #include <netdb.h>
-
-      void freehostent(struct hostent *ptr);
-
-6.4 Protocol-Independent Nodename and Service Name Translation
-
-   Nodename-to-address translation is done in a protocol-independent
-   fashion using the getaddrinfo() function that is taken from the
-   Institute of Electrical and Electronic Engineers (IEEE) POSIX 1003.1g
-   (Protocol Independent Interfaces) draft specification [3].
-
-   The official specification for this function will be the final POSIX
-   standard, with the following additional requirements:
-
-      -  getaddrinfo() (along with the getnameinfo() function described
-         in the next section) must be thread safe.
-
-      -  The AI_NUMERICHOST is new with this document.
-
-      -  All fields in socket address structures returned by
-         getaddrinfo() that are not filled in through an explicit
-         argument (e.g., sin6_flowinfo and sin_zero) must be set to 0.
-         (This makes it easier to compare socket address structures.)
-
-      -  getaddrinfo() must fill in the length field of a socket address
-         structure (e.g., sin6_len) on systems that support this field.
-
-   We are providing this independent description of the function because
-   POSIX standards are not freely available (as are IETF documents).
-
-      #include <sys/socket.h>
-      #include <netdb.h>
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 26]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-      int getaddrinfo(const char *nodename, const char *servname,
-                      const struct addrinfo *hints,
-                      struct addrinfo **res);
-
-   The addrinfo structure is defined as a result of including the
-   <netdb.h> header.
-
-  struct addrinfo {
-    int     ai_flags;     /* AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST */
-    int     ai_family;    /* PF_xxx */
-    int     ai_socktype;  /* SOCK_xxx */
-    int     ai_protocol;  /* 0 or IPPROTO_xxx for IPv4 and IPv6 */
-    size_t  ai_addrlen;   /* length of ai_addr */
-    char   *ai_canonname; /* canonical name for nodename */
-    struct sockaddr  *ai_addr; /* binary address */
-    struct addrinfo  *ai_next; /* next structure in linked list */
-  };
-
-   The return value from the function is 0 upon success or a nonzero
-   error code.  The following names are the nonzero error codes from
-   getaddrinfo(), and are defined in <netdb.h>:
-
-      EAI_ADDRFAMILY  address family for nodename not supported
-      EAI_AGAIN       temporary failure in name resolution
-      EAI_BADFLAGS    invalid value for ai_flags
-      EAI_FAIL        non-recoverable failure in name resolution
-      EAI_FAMILY      ai_family not supported
-      EAI_MEMORY      memory allocation failure
-      EAI_NODATA      no address associated with nodename
-      EAI_NONAME      nodename nor servname provided, or not known
-      EAI_SERVICE     servname not supported for ai_socktype
-      EAI_SOCKTYPE    ai_socktype not supported
-      EAI_SYSTEM      system error returned in errno
-
-   The nodename and servname arguments are pointers to null-terminated
-   strings or NULL.  One or both of these two arguments must be a non-
-   NULL pointer.  In the normal client scenario, both the nodename and
-   servname are specified.  In the normal server scenario, only the
-   servname is specified.  A non-NULL nodename string can be either a
-   node name or a numeric host address string (i.e., a dotted-decimal
-   IPv4 address or an IPv6 hex address).  A non-NULL servname string can
-   be either a service name or a decimal port number.
-
-   The caller can optionally pass an addrinfo structure, pointed to by
-   the third argument, to provide hints concerning the type of socket
-   that the caller supports.  In this hints structure all members other
-   than ai_flags, ai_family, ai_socktype, and ai_protocol must be zero
-   or a NULL pointer.  A value of PF_UNSPEC for ai_family means the
-
-
-
-Gilligan, et. al.            Informational                     [Page 27]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   caller will accept any protocol family.  A value of 0 for ai_socktype
-   means the caller will accept any socket type.  A value of 0 for
-   ai_protocol means the caller will accept any protocol.  For example,
-   if the caller handles only TCP and not UDP, then the ai_socktype
-   member of the hints structure should be set to SOCK_STREAM when
-   getaddrinfo() is called.  If the caller handles only IPv4 and not
-   IPv6, then the ai_family member of the hints structure should be set
-   to PF_INET when getaddrinfo() is called.  If the third argument to
-   getaddrinfo() is a NULL pointer, this is the same as if the caller
-   had filled in an addrinfo structure initialized to zero with
-   ai_family set to PF_UNSPEC.
-
-   Upon successful return a pointer to a linked list of one or more
-   addrinfo structures is returned through the final argument.  The
-   caller can process each addrinfo structure in this list by following
-   the ai_next pointer, until a NULL pointer is encountered.  In each
-   returned addrinfo structure the three members ai_family, ai_socktype,
-   and ai_protocol are the corresponding arguments for a call to the
-   socket() function.  In each addrinfo structure the ai_addr member
-   points to a filled-in socket address structure whose length is
-   specified by the ai_addrlen member.
-
-   If the AI_PASSIVE bit is set in the ai_flags member of the hints
-   structure, then the caller plans to use the returned socket address
-   structure in a call to bind().  In this case, if the nodename
-   argument is a NULL pointer, then the IP address portion of the socket
-   address structure will be set to INADDR_ANY for an IPv4 address or
-   IN6ADDR_ANY_INIT for an IPv6 address.
-
-   If the AI_PASSIVE bit is not set in the ai_flags member of the hints
-   structure, then the returned socket address structure will be ready
-   for a call to connect() (for a connection-oriented protocol) or
-   either connect(), sendto(), or sendmsg() (for a connectionless
-   protocol).  In this case, if the nodename argument is a NULL pointer,
-   then the IP address portion of the socket address structure will be
-   set to the loopback address.
-
-   If the AI_CANONNAME bit is set in the ai_flags member of the hints
-   structure, then upon successful return the ai_canonname member of the
-   first addrinfo structure in the linked list will point to a null-
-   terminated string containing the canonical name of the specified
-   nodename.
-
-   If the AI_NUMERICHOST bit is set in the ai_flags member of the hints
-   structure, then a non-NULL nodename string must be a numeric host
-   address string.  Otherwise an error of EAI_NONAME is returned.  This
-   flag prevents any type of name resolution service (e.g., the DNS)
-   from being called.
-
-
-
-Gilligan, et. al.            Informational                     [Page 28]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   All of the information returned by getaddrinfo() is dynamically
-   allocated: the addrinfo structures, and the socket address structures
-   and canonical node name strings pointed to by the addrinfo
-   structures.  To return this information to the system the function
-   freeaddrinfo() is called:
-
-      #include <sys/socket.h> #include <netdb.h>
-
-      void freeaddrinfo(struct addrinfo *ai);
-
-   The addrinfo structure pointed to by the ai argument is freed, along
-   with any dynamic storage pointed to by the structure.  This operation
-   is repeated until a NULL ai_next pointer is encountered.
-
-   To aid applications in printing error messages based on the EAI_xxx
-   codes returned by getaddrinfo(), the following function is defined.
-
-      #include <sys/socket.h> #include <netdb.h>
-
-      char *gai_strerror(int ecode);
-
-   The argument is one of the EAI_xxx values defined earlier and the
-   return value points to a string describing the error.  If the
-   argument is not one of the EAI_xxx values, the function still returns
-   a pointer to a string whose contents indicate an unknown error.
-
-6.5 Socket Address Structure to Nodename and Service Name
-
-   The POSIX 1003.1g specification includes no function to perform the
-   reverse conversion from getaddrinfo(): to look up a nodename and
-   service name, given the binary address and port.  Therefore, we
-   define the following function:
-
-      #include <sys/socket.h>
-      #include <netdb.h>
-
-      int getnameinfo(const struct sockaddr *sa, socklen_t salen,
-                      char *host, size_t hostlen,
-                      char *serv, size_t servlen,
-                      int flags);
-
-   This function looks up an IP address and port number provided by the
-   caller in the DNS and system-specific database, and returns text
-   strings for both in buffers provided by the caller.  The function
-   indicates successful completion by a zero return value; a non-zero
-   return value indicates failure.
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 29]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   The first argument, sa, points to either a sockaddr_in structure (for
-   IPv4) or a sockaddr_in6 structure (for IPv6) that holds the IP
-   address and port number.  The salen argument gives the length of the
-   sockaddr_in or sockaddr_in6 structure.
-
-   The function returns the nodename associated with the IP address in
-   the buffer pointed to by the host argument.  The caller provides the
-   size of this buffer via the hostlen argument.  The service name
-   associated with the port number is returned in the buffer pointed to
-   by serv, and the servlen argument gives the length of this buffer.
-   The caller specifies not to return either string by providing a zero
-   value for the hostlen or servlen arguments.  Otherwise, the caller
-   must provide buffers large enough to hold the nodename and the
-   service name, including the terminating null characters.
-
-   Unfortunately most systems do not provide constants that specify the
-   maximum size of either a fully-qualified domain name or a service
-   name.  Therefore to aid the application in allocating buffers for
-   these two returned strings the following constants are defined in
-   <netdb.h>:
-
-      #define NI_MAXHOST  1025
-      #define NI_MAXSERV    32
-
-   The first value is actually defined as the constant MAXDNAME in recent
-   versions of BIND's <arpa/nameser.h> header (older versions of BIND
-   define this constant to be 256) and the second is a guess based on the
-   services listed in the current Assigned Numbers RFC.
-
-   The final argument is a flag that changes the default actions of this
-   function.  By default the fully-qualified domain name (FQDN) for the
-   host is looked up in the DNS and returned.  If the flag bit NI_NOFQDN
-   is set, only the nodename portion of the FQDN is returned for local
-   hosts.
-
-   If the flag bit NI_NUMERICHOST is set, or if the host's name cannot be
-   located in the DNS, the numeric form of the host's address is returned
-   instead of its name (e.g., by calling inet_ntop() instead of
-   getipnodebyaddr()).  If the flag bit NI_NAMEREQD is set, an error is
-   returned if the host's name cannot be located in the DNS.
-
-   If the flag bit NI_NUMERICSERV is set, the numeric form of the service
-   address is returned (e.g., its port number) instead of its name.  The
-   two NI_NUMERICxxx flags are required to support the "-n" flag that
-   many commands provide.
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 30]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   A fifth flag bit, NI_DGRAM, specifies that the service is a datagram
-   service, and causes getservbyport() to be called with a second
-   argument of "udp" instead of its default of "tcp".  This is required
-   for the few ports (e.g. 512-514) that have different services for UDP
-   and TCP.
-
-   These NI_xxx flags are defined in <netdb.h> along with the AI_xxx
-   flags already defined for getaddrinfo().
-
-6.6 Address Conversion Functions
-
-   The two functions inet_addr() and inet_ntoa() convert an IPv4 address
-   between binary and text form.  IPv6 applications need similar
-   functions.  The following two functions convert both IPv6 and IPv4
-   addresses:
-
-      #include <sys/socket.h>
-      #include <arpa/inet.h>
-
-      int inet_pton(int af, const char *src, void *dst);
-
-      const char *inet_ntop(int af, const void *src,
-                            char *dst, size_t size);
-
-   The inet_pton() function converts an address in its standard text
-   presentation form into its numeric binary form.  The af argument
-   specifies the family of the address.  Currently the AF_INET and
-   AF_INET6 address families are supported.  The src argument points to
-   the string being passed in.  The dst argument points to a buffer into
-   which the function stores the numeric address.  The address is
-   returned in network byte order.  Inet_pton() returns 1 if the
-   conversion succeeds, 0 if the input is not a valid IPv4 dotted-
-   decimal string or a valid IPv6 address string, or -1 with errno set
-   to EAFNOSUPPORT if the af argument is unknown.  The calling
-   application must ensure that the buffer referred to by dst is large
-   enough to hold the numeric address (e.g., 4 bytes for AF_INET or 16
-   bytes for AF_INET6).
-
-   If the af argument is AF_INET, the function accepts a string in the
-   standard IPv4 dotted-decimal form:
-
-      ddd.ddd.ddd.ddd
-
-   where ddd is a one to three digit decimal number between 0 and 255.
-   Note that many implementations of the existing inet_addr() and
-   inet_aton() functions accept nonstandard input: octal numbers,
-   hexadecimal numbers, and fewer than four numbers.  inet_pton() does
-   not accept these formats.
-
-
-
-Gilligan, et. al.            Informational                     [Page 31]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   If the af argument is AF_INET6, then the function accepts a string in
-   one of the standard IPv6 text forms defined in Section 2.2 of the
-   addressing architecture specification [2].
-
-   The inet_ntop() function converts a numeric address into a text
-   string suitable for presentation.  The af argument specifies the
-   family of the address.  This can be AF_INET or AF_INET6.  The src
-   argument points to a buffer holding an IPv4 address if the af
-   argument is AF_INET, or an IPv6 address if the af argument is
-   AF_INET6, the address must be in network byte order.  The dst
-   argument points to a buffer where the function will store the
-   resulting text string.  The size argument specifies the size of this
-   buffer.  The application must specify a non-NULL dst argument.  For
-   IPv6 addresses, the buffer must be at least 46-octets.  For IPv4
-   addresses, the buffer must be at least 16-octets.  In order to allow
-   applications to easily declare buffers of the proper size to store
-   IPv4 and IPv6 addresses in string form, the following two constants
-   are defined in <netinet/in.h>:
-
-      #define INET_ADDRSTRLEN    16
-      #define INET6_ADDRSTRLEN   46
-
-   The inet_ntop() function returns a pointer to the buffer containing
-   the text string if the conversion succeeds, and NULL otherwise.  Upon
-   failure, errno is set to EAFNOSUPPORT if the af argument is invalid or
-   ENOSPC if the size of the result buffer is inadequate.
-
-6.7 Address Testing Macros
-
-   The following macros can be used to test for special IPv6 addresses.
-
-      #include <netinet/in.h>
-
-      int  IN6_IS_ADDR_UNSPECIFIED (const struct in6_addr *);
-      int  IN6_IS_ADDR_LOOPBACK    (const struct in6_addr *);
-      int  IN6_IS_ADDR_MULTICAST   (const struct in6_addr *);
-      int  IN6_IS_ADDR_LINKLOCAL   (const struct in6_addr *);
-      int  IN6_IS_ADDR_SITELOCAL   (const struct in6_addr *);
-      int  IN6_IS_ADDR_V4MAPPED    (const struct in6_addr *);
-      int  IN6_IS_ADDR_V4COMPAT    (const struct in6_addr *);
-
-      int  IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
-      int  IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
-      int  IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
-      int  IN6_IS_ADDR_MC_ORGLOCAL (const struct in6_addr *);
-      int  IN6_IS_ADDR_MC_GLOBAL   (const struct in6_addr *);
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 32]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   The first seven macros return true if the address is of the specified
-   type, or false otherwise.  The last five test the scope of a
-   multicast address and return true if the address is a multicast
-   address of the specified scope or false if the address is either not
-   a multicast address or not of the specified scope.  Note that
-   IN6_IS_ADDR_LINKLOCAL and IN6_IS_ADDR_SITELOCAL return true only for
-   the two local-use IPv6 unicast addresses.  These two macros do not
-   return true for IPv6 multicast addresses of either link-local scope
-   or site-local scope.
-
-7. Summary of New Definitions
-
-   The following list summarizes the constants, structure, and extern
-   definitions discussed in this memo, sorted by header.
-
-      <net/if.h>      IF_NAMESIZE
-      <net/if.h>      struct if_nameindex{};
-
-      <netdb.h>       AI_ADDRCONFIG
-      <netdb.h>       AI_DEFAULT
-      <netdb.h>       AI_ALL
-      <netdb.h>       AI_CANONNAME
-      <netdb.h>       AI_NUMERICHOST
-      <netdb.h>       AI_PASSIVE
-      <netdb.h>       AI_V4MAPPED
-      <netdb.h>       EAI_ADDRFAMILY
-      <netdb.h>       EAI_AGAIN
-      <netdb.h>       EAI_BADFLAGS
-      <netdb.h>       EAI_FAIL
-      <netdb.h>       EAI_FAMILY
-      <netdb.h>       EAI_MEMORY
-      <netdb.h>       EAI_NODATA
-      <netdb.h>       EAI_NONAME
-      <netdb.h>       EAI_SERVICE
-      <netdb.h>       EAI_SOCKTYPE
-      <netdb.h>       EAI_SYSTEM
-      <netdb.h>       NI_DGRAM
-      <netdb.h>       NI_MAXHOST
-      <netdb.h>       NI_MAXSERV
-      <netdb.h>       NI_NAMEREQD
-      <netdb.h>       NI_NOFQDN
-      <netdb.h>       NI_NUMERICHOST
-      <netdb.h>       NI_NUMERICSERV
-      <netdb.h>       struct addrinfo{};
-
-      <netinet/in.h>  IN6ADDR_ANY_INIT
-      <netinet/in.h>  IN6ADDR_LOOPBACK_INIT
-      <netinet/in.h>  INET6_ADDRSTRLEN
-
-
-
-Gilligan, et. al.            Informational                     [Page 33]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-      <netinet/in.h>  INET_ADDRSTRLEN
-      <netinet/in.h>  IPPROTO_IPV6
-      <netinet/in.h>  IPV6_JOIN_GROUP
-      <netinet/in.h>  IPV6_LEAVE_GROUP
-      <netinet/in.h>  IPV6_MULTICAST_HOPS
-      <netinet/in.h>  IPV6_MULTICAST_IF
-      <netinet/in.h>  IPV6_MULTICAST_LOOP
-      <netinet/in.h>  IPV6_UNICAST_HOPS
-      <netinet/in.h>  SIN6_LEN
-      <netinet/in.h>  extern const struct in6_addr in6addr_any;
-      <netinet/in.h>  extern const struct in6_addr in6addr_loopback;
-      <netinet/in.h>  struct in6_addr{};
-      <netinet/in.h>  struct ipv6_mreq{};
-      <netinet/in.h>  struct sockaddr_in6{};
-
-      <sys/socket.h>  AF_INET6
-      <sys/socket.h>  PF_INET6
-      <sys/socket.h>  struct sockaddr_storage;
-
-   The following list summarizes the function and macro prototypes
-   discussed in this memo, sorted by header.
-
-<arpa/inet.h>   int inet_pton(int, const char *, void *);
-<arpa/inet.h>   const char *inet_ntop(int, const void *,
-                                      char *, size_t);
-
-<net/if.h>      char *if_indextoname(unsigned int, char *);
-<net/if.h>      unsigned int if_nametoindex(const char *);
-<net/if.h>      void if_freenameindex(struct if_nameindex *);
-<net/if.h>      struct if_nameindex *if_nameindex(void);
-
-<netdb.h>       int getaddrinfo(const char *, const char *,
-                                const struct addrinfo *,
-                                struct addrinfo **);
-<netdb.h>       int getnameinfo(const struct sockaddr *, socklen_t,
-                                char *, size_t, char *, size_t, int);
-<netdb.h>       void freeaddrinfo(struct addrinfo *);
-<netdb.h>       char *gai_strerror(int);
-<netdb.h>       struct hostent *getipnodebyname(const char *, int, int,
-                                       int *);
-<netdb.h>       struct hostent *getipnodebyaddr(const void *, size_t,
-                                       int, int *);
-<netdb.h>       void freehostent(struct hostent *);
-
-<netinet/in.h>  int IN6_IS_ADDR_LINKLOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_LOOPBACK(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MC_GLOBAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
-
-
-
-Gilligan, et. al.            Informational                     [Page 34]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-<netinet/in.h>  int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MC_ORGLOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MULTICAST(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_SITELOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_UNSPECIFIED(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_V4COMPAT(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_V4MAPPED(const struct in6_addr *);
-
-8. Security Considerations
-
-   IPv6 provides a number of new security mechanisms, many of which need
-   to be accessible to applications.  Companion memos detailing the
-   extensions to the socket interfaces to support IPv6 security are
-   being written.
-
-9. Year 2000 Considerations
-
-   There are no issues for this memo concerning the Year 2000 issue
-   regarding the use of dates.
-
-Changes From RFC 2133
-
-   Changes made in the March 1998 Edition (-01 draft):
-
-      Changed all "hostname" to "nodename" for consistency with other
-      IPv6 documents.
-
-      Section 3.3: changed comment for sin6_flowinfo to be "traffic
-      class & flow info" and updated corresponding text description to
-      current definition of these two fields.
-
-      Section 3.10 ("Portability Additions") is new.
-
-      Section 6: a new paragraph was added reiterating that the existing
-      gethostbyname() and gethostbyaddr() are not changed.
-
-      Section 6.1: change gethostbyname3() to getnodebyname().  Add
-      AI_DEFAULT to handle majority of applications.  Renamed
-      AI_V6ADDRCONFIG to AI_ADDRCONFIG and define it for A records and
-      IPv4 addresses too.  Defined exactly what getnodebyname() must
-      return if the name argument is a numeric address string.
-
-      Section 6.2: change gethostbyaddr() to getnodebyaddr().  Reword
-      items 2 and 3 in the description of how to handle IPv4-mapped and
-      IPv4- compatible addresses to "lookup a name" for a given address,
-      instead of specifying what type of DNS query to issue.
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 35]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-      Section 6.3: added two more requirements to getaddrinfo().
-
-      Section 7: added the following constants to the list for
-      <netdb.h>:  AI_ADDRCONFIG, AI_ALL, and AI_V4MAPPED.  Add union
-      sockaddr_union and SA_LEN to the lists for <sys/socket.h>.
-
-      Updated references.
-
-   Changes made in the November 1997 Edition (-00 draft):
-
-      The data types have been changed to conform with Draft 6.6 of the
-      Posix 1003.1g standard.
-
-      Section 3.2: data type of s6_addr changed to "uint8_t".
-
-      Section 3.3: data type of sin6_family changed to "sa_family_t".
-      data type of sin6_port changed to "in_port_t", data type of
-      sin6_flowinfo changed to "uint32_t".
-
-      Section 3.4: same as Section 3.3, plus data type of sin6_len
-      changed to "uint8_t".
-
-      Section 6.2: first argument of gethostbyaddr() changed from "const
-      char *" to "const void *" and second argument changed from "int"
-      to "size_t".
-
-      Section 6.4: second argument of getnameinfo() changed from
-      "size_t" to "socklen_t".
-
-      The wording was changed when new structures were defined, to be
-      more explicit as to which header must be included to define the
-      structure:
-
-      Section 3.2 (in6_addr{}), Section 3.3 (sockaddr_in6{}), Section
-      3.4 (sockaddr_in6{}), Section 4.3 (if_nameindex{}), Section 5.3
-      (ipv6_mreq{}), and Section 6.3 (addrinfo{}).
-
-      Section 4: NET_RT_LIST changed to NET_RT_IFLIST.
-
-      Section 5.1: The IPV6_ADDRFORM socket option was removed.
-
-      Section 5.3: Added a note that an option value other than 0 or 1
-      for IPV6_MULTICAST_LOOP returns an error.  Added a note that
-      IPV6_MULTICAST_IF, IPV6_MULTICAST_HOPS, and IPV6_MULTICAST_LOOP
-      can also be used with getsockopt(), but IPV6_ADD_MEMBERSHIP and
-      IPV6_DROP_MEMBERSHIP cannot be used with getsockopt().
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 36]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-      Section 6.1: Removed the description of gethostbyname2() and its
-      associated RES_USE_INET6 option, replacing it with
-      gethostbyname3().
-
-      Section 6.2: Added requirement that gethostbyaddr() be thread
-      safe.  Reworded step 4 to avoid using the RES_USE_INET6 option.
-
-      Section 6.3: Added the requirement that getaddrinfo() and
-      getnameinfo() be thread safe.  Added the AI_NUMERICHOST flag.
-
-      Section 6.6: Added clarification about IN6_IS_ADDR_LINKLOCAL and
-      IN6_IS_ADDR_SITELOCAL macros.
-
-   Changes made to the draft -01 specification Sept 98
-
-      Changed priority to traffic class in the spec.
-
-      Added the need for scope identification in section 2.1.
-
-      Added sin6_scope_id to struct sockaddr_in6 in sections 3.3 and
-      3.4.
-
-      Changed 3.10 to use generic storage structure to support holding
-      IPv6 addresses and removed the SA_LEN macro.
-
-      Distinguished between invalid input parameters and system failures
-      for Interface Identification in Section 4.1 and 4.2.
-
-      Added defaults for multicast operations in section 5.2 and changed
-      the names from ADD to JOIN and DROP to LEAVE to be consistent with
-      IPv6 multicast terminology.
-
-      Changed getnodebyname to getipnodebyname, getnodebyaddr to
-      getipnodebyaddr, and added MT safe error code to function
-      parameters in section 6.
-
-      Moved freehostent to its own sub-section after getipnodebyaddr now
-      6.3 (so this bumps all remaining sections in section 6.
-
-      Clarified the use of AI_ALL and AI_V4MAPPED that these are
-      dependent on the AF parameter and must be used as a conjunction in
-      section 6.1.
-
-      Removed the restriction that literal addresses cannot be used with
-      a flags argument in section 6.1.
-
-      Added Year 2000 Section to the draft
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 37]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-      Deleted Reference to the following because the attached is deleted
-      from the ID directory and has expired.  But the logic from the
-      aforementioned draft still applies, so that was kept in Section
-      6.2 bullets after 3rd paragraph.
-
-      [7]  P. Vixie, "Reverse Name Lookups of Encapsulated IPv4
-           Addresses in IPv6", Internet-Draft, <draft-vixie-ipng-
-           ipv4ptr-00.txt>, May 1996.
-
-      Deleted the following reference as it is no longer referenced.
-      And the draft has expired.
-
-      [3]  D. McDonald, "A Simple IP Security API Extension to BSD
-           Sockets", Internet-Draft, <draft-mcdonald-simple-ipsec-api-
-           01.txt>, March 1997.
-
-      Deleted the following reference as it is no longer referenced.
-
-      [4]  C. Metz, "Network Security API for Sockets",
-           Internet-Draft, <draft-metz-net-security-api-01.txt>, January
-           1998.
-
-      Update current references to current status.
-
-      Added alignment notes for in6_addr and sin6_addr.
-
-      Clarified further that AI_V4MAPPED must be used with a dotted IPv4
-      literal address for getipnodebyname(), when address family is
-      AF_INET6.
-
-      Added text to clarify "::" and "::1" when used by
-      getipnodebyaddr().
-
-Acknowledgments
-
-   Thanks to the many people who made suggestions and provided feedback
-   to this document, including: Werner Almesberger, Ran Atkinson, Fred
-   Baker, Dave Borman, Andrew Cherenson, Alex Conta, Alan Cox, Steve
-   Deering, Richard Draves, Francis Dupont, Robert Elz, Marc Hasson, Tom
-   Herbert, Bob Hinden, Wan-Yen Hsu, Christian Huitema, Koji Imada,
-   Markus Jork, Ron Lee, Alan Lloyd, Charles Lynn, Dan McDonald, Dave
-   Mitton, Thomas Narten, Josh Osborne, Craig Partridge, Jean-Luc
-   Richier, Erik Scoredos, Keith Sklower, Matt Thomas, Harvey Thompson,
-   Dean D. Throop, Karen Tracey, Glenn Trewitt, Paul Vixie, David
-   Waitzman, Carl Williams, and Kazu Yamamoto,
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 38]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   The getaddrinfo() and getnameinfo() functions are taken from an
-   earlier Internet Draft by Keith Sklower.  As noted in that draft,
-   William Durst, Steven Wise, Michael Karels, and Eric Allman provided
-   many useful discussions on the subject of protocol-independent name-
-   to-address translation, and reviewed early versions of Keith
-   Sklower's original proposal.  Eric Allman implemented the first
-   prototype of getaddrinfo().  The observation that specifying the pair
-   of name and service would suffice for connecting to a service
-   independent of protocol details was made by Marshall Rose in a
-   proposal to X/Open for a "Uniform Network Interface".
-
-   Craig Metz, Jack McCann, Erik Nordmark, Tim Hartrick, and Mukesh
-   Kacker made many contributions to this document.  Ramesh Govindan
-   made a number of contributions and co-authored an earlier version of
-   this memo.
-
-References
-
-   [1]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
-        Specification", RFC 2460, December 1998.
-
-   [2]  Hinden, R. and S. Deering, "IP Version 6 Addressing
-        Architecture", RFC 2373, July 1998.
-
-   [3]  IEEE, "Protocol Independent Interfaces", IEEE Std 1003.1g, DRAFT
-        6.6, March 1997.
-
-   [4]  Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6", RFC
-        2292, February 1998.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 39]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-Authors' Addresses
-
-   Robert E. Gilligan
-   FreeGate Corporation
-   1208 E. Arques Ave.
-   Sunnyvale, CA 94086
-
-   Phone: +1 408 617 1004
-   EMail: gilligan@freegate.com
-
-
-   Susan Thomson
-   Bell Communications Research
-   MRE 2P-343, 445 South Street
-   Morristown, NJ 07960
-
-   Phone: +1 201 829 4514
-   EMail: set@thumper.bellcore.com
-
-
-   Jim Bound
-   Compaq Computer Corporation
-   110 Spitbrook Road ZK3-3/U14
-   Nashua, NH 03062-2698
-
-   Phone: +1 603 884 0400
-   EMail: bound@zk3.dec.com
-
-
-   W. Richard Stevens
-   1202 E. Paseo del Zorro
-   Tucson, AZ 85718-2826
-
-   Phone: +1 520 297 9416
-   EMail: rstevens@kohala.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 40]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 41]
-
diff --git a/contrib/bind9/doc/rfc/rfc2671.txt b/contrib/bind9/doc/rfc/rfc2671.txt
deleted file mode 100644
index ec05f80..0000000
--- a/contrib/bind9/doc/rfc/rfc2671.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                            P. Vixie
-Request for Comments: 2671                                            ISC
-Category: Standards Track                                     August 1999
-
-
-                  Extension Mechanisms for DNS (EDNS0)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-Abstract
-
-   The Domain Name System's wire protocol includes a number of fixed
-   fields whose range has been or soon will be exhausted and does not
-   allow clients to advertise their capabilities to servers.  This
-   document describes backward compatible mechanisms for allowing the
-   protocol to grow.
-
-1 - Rationale and Scope
-
-1.1. DNS (see [RFC1035]) specifies a Message Format and within such
-     messages there are standard formats for encoding options, errors,
-     and name compression.  The maximum allowable size of a DNS Message
-     is fixed.  Many of DNS's protocol limits are too small for uses
-     which are or which are desired to become common.  There is no way
-     for implementations to advertise their capabilities.
-
-1.2. Existing clients will not know how to interpret the protocol
-     extensions detailed here.  In practice, these clients will be
-     upgraded when they have need of a new feature, and only new
-     features will make use of the extensions.  We must however take
-     account of client behaviour in the face of extra fields, and design
-     a fallback scheme for interoperability with these clients.
-
-
-
-
-
-
-
-
-
-Vixie                       Standards Track                     [Page 1]
-
-RFC 2671          Extension Mechanisms for DNS (EDNS0)       August 1999
-
-
-2 - Affected Protocol Elements
-
-2.1. The DNS Message Header's (see [RFC1035 4.1.1]) second full 16-bit
-     word is divided into a 4-bit OPCODE, a 4-bit RCODE, and a number of
-     1-bit flags.  The original reserved Z bits have been allocated to
-     various purposes, and most of the RCODE values are now in use.
-     More flags and more possible RCODEs are needed.
-
-2.2. The first two bits of a wire format domain label are used to denote
-     the type of the label.  [RFC1035 4.1.4] allocates two of the four
-     possible types and reserves the other two.  Proposals for use of
-     the remaining types far outnumber those available.  More label
-     types are needed.
-
-2.3. DNS Messages are limited to 512 octets in size when sent over UDP.
-     While the minimum maximum reassembly buffer size still allows a
-     limit of 512 octets of UDP payload, most of the hosts now connected
-     to the Internet are able to reassemble larger datagrams.  Some
-     mechanism must be created to allow requestors to advertise larger
-     buffer sizes to responders.
-
-3 - Extended Label Types
-
-3.1. The "0 1" label type will now indicate an extended label type,
-     whose value is encoded in the lower six bits of the first octet of
-     a label.  All subsequently developed label types should be encoded
-     using an extended label type.
-
-3.2. The "1 1 1 1 1 1" extended label type will be reserved for future
-     expansion of the extended label type code space.
-
-4 - OPT pseudo-RR
-
-4.1. One OPT pseudo-RR can be added to the additional data section of
-     either a request or a response.  An OPT is called a pseudo-RR
-     because it pertains to a particular transport level message and not
-     to any actual DNS data.  OPT RRs shall never be cached, forwarded,
-     or stored in or loaded from master files.  The quantity of OPT
-     pseudo-RRs per message shall be either zero or one, but not
-     greater.
-
-4.2. An OPT RR has a fixed part and a variable set of options expressed
-     as {attribute, value} pairs.  The fixed part holds some DNS meta
-     data and also a small collection of new protocol elements which we
-     expect to be so popular that it would be a waste of wire space to
-     encode them as {attribute, value} pairs.
-
-
-
-
-
-Vixie                       Standards Track                     [Page 2]
-
-RFC 2671          Extension Mechanisms for DNS (EDNS0)       August 1999
-
-
-4.3. The fixed part of an OPT RR is structured as follows:
-
-     Field Name   Field Type     Description
-     ------------------------------------------------------
-     NAME         domain name    empty (root domain)
-     TYPE         u_int16_t      OPT
-     CLASS        u_int16_t      sender's UDP payload size
-     TTL          u_int32_t      extended RCODE and flags
-     RDLEN        u_int16_t      describes RDATA
-     RDATA        octet stream   {attribute,value} pairs
-
-4.4. The variable part of an OPT RR is encoded in its RDATA and is
-     structured as zero or more of the following:
-
-                +0 (MSB)                            +1 (LSB)
-     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-  0: |                          OPTION-CODE                          |
-     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-  2: |                         OPTION-LENGTH                         |
-     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-  4: |                                                               |
-     /                          OPTION-DATA                          /
-     /                                                               /
-     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-
-   OPTION-CODE    (Assigned by IANA.)
-
-   OPTION-LENGTH  Size (in octets) of OPTION-DATA.
-
-   OPTION-DATA    Varies per OPTION-CODE.
-
-4.5. The sender's UDP payload size (which OPT stores in the RR CLASS
-     field) is the number of octets of the largest UDP payload that can
-     be reassembled and delivered in the sender's network stack.  Note
-     that path MTU, with or without fragmentation, may be smaller than
-     this.
-
-4.5.1. Note that a 512-octet UDP payload requires a 576-octet IP
-       reassembly buffer.  Choosing 1280 on an Ethernet connected
-       requestor would be reasonable.  The consequence of choosing too
-       large a value may be an ICMP message from an intermediate
-       gateway, or even a silent drop of the response message.
-
-4.5.2. Both requestors and responders are advised to take account of the
-       path's discovered MTU (if already known) when considering message
-       sizes.
-
-
-
-
-
-Vixie                       Standards Track                     [Page 3]
-
-RFC 2671          Extension Mechanisms for DNS (EDNS0)       August 1999
-
-
-4.5.3. The requestor's maximum payload size can change over time, and
-       should therefore not be cached for use beyond the transaction in
-       which it is advertised.
-
-4.5.4. The responder's maximum payload size can change over time, but
-       can be reasonably expected to remain constant between two
-       sequential transactions; for example, a meaningless QUERY to
-       discover a responder's maximum UDP payload size, followed
-       immediately by an UPDATE which takes advantage of this size.
-       (This is considered preferrable to the outright use of TCP for
-       oversized requests, if there is any reason to suspect that the
-       responder implements EDNS, and if a request will not fit in the
-       default 512 payload size limit.)
-
-4.5.5. Due to transaction overhead, it is unwise to advertise an
-       architectural limit as a maximum UDP payload size.  Just because
-       your stack can reassemble 64KB datagrams, don't assume that you
-       want to spend more than about 4KB of state memory per ongoing
-       transaction.
-
-4.6. The extended RCODE and flags (which OPT stores in the RR TTL field)
-     are structured as follows:
-
-                 +0 (MSB)                            +1 (LSB)
-      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-   0: |         EXTENDED-RCODE        |            VERSION            |
-      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-   2: |                               Z                               |
-      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-
-   EXTENDED-RCODE  Forms upper 8 bits of extended 12-bit RCODE.  Note
-                   that EXTENDED-RCODE value "0" indicates that an
-                   unextended RCODE is in use (values "0" through "15").
-
-   VERSION         Indicates the implementation level of whoever sets
-                   it.  Full conformance with this specification is
-                   indicated by version "0."  Requestors are encouraged
-                   to set this to the lowest implemented level capable
-                   of expressing a transaction, to minimize the
-                   responder and network load of discovering the
-                   greatest common implementation level between
-                   requestor and responder.  A requestor's version
-                   numbering strategy should ideally be a run time
-                   configuration option.
-
-                   If a responder does not implement the VERSION level
-                   of the request, then it answers with RCODE=BADVERS.
-                   All responses will be limited in format to the
-
-
-
-Vixie                       Standards Track                     [Page 4]
-
-RFC 2671          Extension Mechanisms for DNS (EDNS0)       August 1999
-
-
-                   VERSION level of the request, but the VERSION of each
-                   response will be the highest implementation level of
-                   the responder.  In this way a requestor will learn
-                   the implementation level of a responder as a side
-                   effect of every response, including error responses,
-                   including RCODE=BADVERS.
-
-   Z               Set to zero by senders and ignored by receivers,
-                   unless modified in a subsequent specification.
-
-5 - Transport Considerations
-
-5.1. The presence of an OPT pseudo-RR in a request should be taken as an
-     indication that the requestor fully implements the given version of
-     EDNS, and can correctly understand any response that conforms to
-     that feature's specification.
-
-5.2. Lack of use of these features in a request must be taken as an
-     indication that the requestor does not implement any part of this
-     specification and that the responder may make no use of any
-     protocol extension described here in its response.
-
-5.3. Responders who do not understand these protocol extensions are
-     expected to send a response with RCODE NOTIMPL, FORMERR, or
-     SERVFAIL.  Therefore use of extensions should be "probed" such that
-     a responder who isn't known to support them be allowed a retry with
-     no extensions if it responds with such an RCODE.  If a responder's
-     capability level is cached by a requestor, a new probe should be
-     sent periodically to test for changes to responder capability.
-
-6 - Security Considerations
-
-     Requestor-side specification of the maximum buffer size may open a
-     new DNS denial of service attack if responders can be made to send
-     messages which are too large for intermediate gateways to forward,
-     thus leading to potential ICMP storms between gateways and
-     responders.
-
-7 - IANA Considerations
-
-     The IANA has assigned RR type code 41 for OPT.
-
-     It is the recommendation of this document and its working group
-     that IANA create a registry for EDNS Extended Label Types, for EDNS
-     Option Codes, and for EDNS Version Numbers.
-
-     This document assigns label type 0b01xxxxxx as "EDNS Extended Label
-     Type."  We request that IANA record this assignment.
-
-
-
-Vixie                       Standards Track                     [Page 5]
-
-RFC 2671          Extension Mechanisms for DNS (EDNS0)       August 1999
-
-
-     This document assigns extended label type 0bxx111111 as "Reserved
-     for future extended label types."  We request that IANA record this
-     assignment.
-
-     This document assigns option code 65535 to "Reserved for future
-     expansion."
-
-     This document expands the RCODE space from 4 bits to 12 bits.  This
-     will allow IANA to assign more than the 16 distinct RCODE values
-     allowed in [RFC1035].
-
-     This document assigns EDNS Extended RCODE "16" to "BADVERS".
-
-     IESG approval should be required to create new entries in the EDNS
-     Extended Label Type or EDNS Version Number registries, while any
-     published RFC (including Informational, Experimental, or BCP)
-     should be grounds for allocation of an EDNS Option Code.
-
-8 - Acknowledgements
-
-     Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley,
-     Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, and Thomas
-     Narten were each instrumental in creating and refining this
-     specification.
-
-9 - References
-
-    [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
-               Specification", STD 13, RFC 1035, November 1987.
-
-10 - Author's Address
-
-   Paul Vixie
-   Internet Software Consortium
-   950 Charter Street
-   Redwood City, CA 94063
-
-   Phone: +1 650 779 7001
-   EMail: vixie@isc.org
-
-
-
-
-
-
-
-
-
-
-
-
-Vixie                       Standards Track                     [Page 6]
-
-RFC 2671          Extension Mechanisms for DNS (EDNS0)       August 1999
-
-
-11 - Full Copyright Statement
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Vixie                       Standards Track                     [Page 7]
-
diff --git a/contrib/bind9/doc/rfc/rfc2672.txt b/contrib/bind9/doc/rfc/rfc2672.txt
deleted file mode 100644
index 1103016..0000000
--- a/contrib/bind9/doc/rfc/rfc2672.txt
+++ /dev/null
@@ -1,507 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        M. Crawford
-Request for Comments: 2672                                      Fermilab
-Category: Standards Track                                    August 1999
-
-
-                   Non-Terminal DNS Name Redirection
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-1.  Introduction
-
-   This document defines a new DNS Resource Record called "DNAME", which
-   provides the capability to map an entire subtree of the DNS name
-   space to another domain.  It differs from the CNAME record which maps
-   a single node of the name space.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [KWORD].
-
-2.  Motivation
-
-   This Resource Record and its processing rules were conceived as a
-   solution to the problem of maintaining address-to-name mappings in a
-   context of network renumbering.  Without the DNAME mechanism, an
-   authoritative DNS server for the address-to-name mappings of some
-   network must be reconfigured when that network is renumbered.  With
-   DNAME, the zone can be constructed so that it needs no modification
-   when renumbered.  DNAME can also be useful in other situations, such
-   as when an organizational unit is renamed.
-
-3. The DNAME Resource Record
-
-   The DNAME RR has mnemonic DNAME and type code 39 (decimal).
-
-
-
-
-
-
-
-Crawford                    Standards Track                     [Page 1]
-
-RFC 2672           Non-Terminal DNS Name Redirection         August 1999
-
-
-   DNAME has the following format:
-
-      <owner> <ttl> <class> DNAME <target>
-
-   The format is not class-sensitive.  All fields are required.  The
-   RDATA field <target> is a <domain-name> [DNSIS].
-
-   The DNAME RR causes type NS additional section processing.
-
-   The effect of the DNAME record is the substitution of the record's
-   <target> for its <owner> as a suffix of a domain name.  A "no-
-   descendants" limitation governs the use of DNAMEs in a zone file:
-
-      If a DNAME RR is present at a node N, there may be other data at N
-      (except a CNAME or another DNAME), but there MUST be no data at
-      any descendant of N.  This restriction applies only to records of
-      the same class as the DNAME record.
-
-   This rule assures predictable results when a DNAME record is cached
-   by a server which is not authoritative for the record's zone.  It
-   MUST be enforced when authoritative zone data is loaded.  Together
-   with the rules for DNS zone authority [DNSCLR] it implies that DNAME
-   and NS records can only coexist at the top of a zone which has only
-   one node.
-
-   The compression scheme of [DNSIS] MUST NOT be applied to the RDATA
-   portion of a DNAME record unless the sending server has some way of
-   knowing that the receiver understands the DNAME record format.
-   Signalling such understanding is expected to be the subject of future
-   DNS Extensions.
-
-   Naming loops can be created with DNAME records or a combination of
-   DNAME and CNAME records, just as they can with CNAME records alone.
-   Resolvers, including resolvers embedded in DNS servers, MUST limit
-   the resources they devote to any query.  Implementors should note,
-   however, that fairly lengthy chains of DNAME records may be valid.
-
-4.  Query Processing
-
-   To exploit the DNAME mechanism the name resolution algorithms [DNSCF]
-   must be modified slightly for both servers and resolvers.
-
-   Both modified algorithms incorporate the operation of making a
-   substitution on a name (either QNAME or SNAME) under control of a
-   DNAME record.  This operation will be referred to as "the DNAME
-   substitution".
-
-
-
-
-
-Crawford                    Standards Track                     [Page 2]
-
-RFC 2672           Non-Terminal DNS Name Redirection         August 1999
-
-
-4.1.  Processing by Servers
-
-   For a server performing non-recursive service steps 3.c and 4 of
-   section 4.3.2 [DNSCF] are changed to check for a DNAME record before
-   checking for a wildcard ("*") label, and to return certain DNAME
-   records from zone data and the cache.
-
-   DNS clients sending Extended DNS [EDNS0] queries with Version 0 or
-   non-extended queries are presumed not to understand the semantics of
-   the DNAME record, so a server which implements this specification,
-   when answering a non-extended query, SHOULD synthesize a CNAME record
-   for each DNAME record encountered during query processing to help the
-   client reach the correct DNS data.  The behavior of clients and
-   servers under Extended DNS versions greater than 0 will be specified
-   when those versions are defined.
-
-   The synthesized CNAME RR, if provided, MUST have
-
-      The same CLASS as the QCLASS of the query,
-
-      TTL equal to zero,
-
-      An <owner> equal to the QNAME in effect at the moment the DNAME RR
-      was encountered, and
-
-      An RDATA field containing the new QNAME formed by the action of
-      the DNAME substitution.
-
-   If the server has the appropriate key on-line [DNSSEC, SECDYN], it
-   MAY generate and return a SIG RR for the synthesized CNAME RR.
-
-   The revised server algorithm is:
-
-   1. Set or clear the value of recursion available in the response
-      depending on whether the name server is willing to provide
-      recursive service.  If recursive service is available and
-      requested via the RD bit in the query, go to step 5, otherwise
-      step 2.
-
-   2. Search the available zones for the zone which is the nearest
-      ancestor to QNAME.  If such a zone is found, go to step 3,
-      otherwise step 4.
-
-   3. Start matching down, label by label, in the zone.  The matching
-      process can terminate several ways:
-
-
-
-
-
-
-Crawford                    Standards Track                     [Page 3]
-
-RFC 2672           Non-Terminal DNS Name Redirection         August 1999
-
-
-      a. If the whole of QNAME is matched, we have found the node.
-
-         If the data at the node is a CNAME, and QTYPE doesn't match
-         CNAME, copy the CNAME RR into the answer section of the
-         response, change QNAME to the canonical name in the CNAME RR,
-         and go back to step 1.
-
-         Otherwise, copy all RRs which match QTYPE into the answer
-         section and go to step 6.
-
-      b. If a match would take us out of the authoritative data, we have
-         a referral.  This happens when we encounter a node with NS RRs
-         marking cuts along the bottom of a zone.
-
-         Copy the NS RRs for the subzone into the authority section of
-         the reply.  Put whatever addresses are available into the
-         additional section, using glue RRs if the addresses are not
-         available from authoritative data or the cache.  Go to step 4.
-
-      c. If at some label, a match is impossible (i.e., the
-         corresponding label does not exist), look to see whether the
-         last label matched has a DNAME record.
-
-         If a DNAME record exists at that point, copy that record into
-         the answer section.  If substitution of its <target> for its
-         <owner> in QNAME would overflow the legal size for a <domain-
-         name>, set RCODE to YXDOMAIN [DNSUPD] and exit; otherwise
-         perform the substitution and continue.  If the query was not
-         extended [EDNS0] with a Version indicating understanding of the
-         DNAME record, the server SHOULD synthesize a CNAME record as
-         described above and include it in the answer section.  Go back
-         to step 1.
-
-         If there was no DNAME record, look to see if the "*" label
-         exists.
-
-         If the "*" label does not exist, check whether the name we are
-         looking for is the original QNAME in the query or a name we
-         have followed due to a CNAME.  If the name is original, set an
-         authoritative name error in the response and exit.  Otherwise
-         just exit.
-
-         If the "*" label does exist, match RRs at that node against
-         QTYPE.  If any match, copy them into the answer section, but
-         set the owner of the RR to be QNAME, and not the node with the
-         "*" label.  Go to step 6.
-
-
-
-
-
-Crawford                    Standards Track                     [Page 4]
-
-RFC 2672           Non-Terminal DNS Name Redirection         August 1999
-
-
-   4. Start matching down in the cache.  If QNAME is found in the cache,
-      copy all RRs attached to it that match QTYPE into the answer
-      section.  If QNAME is not found in the cache but a DNAME record is
-      present at an ancestor of QNAME, copy that DNAME record into the
-      answer section.  If there was no delegation from authoritative
-      data, look for the best one from the cache, and put it in the
-      authority section.  Go to step 6.
-
-   5. Use the local resolver or a copy of its algorithm (see resolver
-      section of this memo) to answer the query.  Store the results,
-      including any intermediate CNAMEs and DNAMEs, in the answer
-      section of the response.
-
-   6. Using local data only, attempt to add other RRs which may be
-      useful to the additional section of the query.  Exit.
-
-   Note that there will be at most one ancestor with a DNAME as
-   described in step 4 unless some zone's data is in violation of the
-   no-descendants limitation in section 3.  An implementation might take
-   advantage of this limitation by stopping the search of step 3c or
-   step 4 when a DNAME record is encountered.
-
-4.2.  Processing by Resolvers
-
-   A resolver or a server providing recursive service must be modified
-   to treat a DNAME as somewhat analogous to a CNAME.  The resolver
-   algorithm of [DNSCF] section 5.3.3 is modified to renumber step 4.d
-   as 4.e and insert a new 4.d.  The complete algorithm becomes:
-
-   1. See if the answer is in local information, and if so return it to
-      the client.
-
-   2. Find the best servers to ask.
-
-   3. Send them queries until one returns a response.
-
-   4. Analyze the response, either:
-
-      a. if the response answers the question or contains a name error,
-         cache the data as well as returning it back to the client.
-
-      b. if the response contains a better delegation to other servers,
-         cache the delegation information, and go to step 2.
-
-      c. if the response shows a CNAME and that is not the answer
-         itself, cache the CNAME, change the SNAME to the canonical name
-         in the CNAME RR and go to step 1.
-
-
-
-
-Crawford                    Standards Track                     [Page 5]
-
-RFC 2672           Non-Terminal DNS Name Redirection         August 1999
-
-
-      d. if the response shows a DNAME and that is not the answer
-         itself, cache the DNAME.  If substitution of the DNAME's
-         <target> for its <owner> in the SNAME would overflow the legal
-         size for a <domain-name>, return an implementation-dependent
-         error to the application; otherwise perform the substitution
-         and go to step 1.
-
-      e. if the response shows a server failure or other bizarre
-         contents, delete the server from the SLIST and go back to step
-         3.
-
-   A resolver or recursive server which understands DNAME records but
-   sends non-extended queries MUST augment step 4.c by deleting from the
-   reply any CNAME records which have an <owner> which is a subdomain of
-   the <owner> of any DNAME record in the response.
-
-5.  Examples of Use
-
-5.1.  Organizational Renaming
-
-   If an organization with domain name FROBOZZ.EXAMPLE became part of an
-   organization with domain name ACME.EXAMPLE, it might ease transition
-   by placing information such as this in its old zone.
-
-       frobozz.example.  DNAME    frobozz-division.acme.example.
-                         MX       10       mailhub.acme.example.
-
-   The response to an extended recursive query for www.frobozz.example
-   would contain, in the answer section, the DNAME record shown above
-   and the relevant RRs for www.frobozz-division.acme.example.
-
-5.2.  Classless Delegation of Shorter Prefixes
-
-   The classless scheme for in-addr.arpa delegation [INADDR] can be
-   extended to prefixes shorter than 24 bits by use of the DNAME record.
-   For example, the prefix 192.0.8.0/22 can be delegated by the
-   following records.
-
-       $ORIGIN 0.192.in-addr.arpa.
-       8/22    NS       ns.slash-22-holder.example.
-       8       DNAME    8.8/22
-       9       DNAME    9.8/22
-       10      DNAME    10.8/22
-       11      DNAME    11.8/22
-
-
-
-
-
-
-
-Crawford                    Standards Track                     [Page 6]
-
-RFC 2672           Non-Terminal DNS Name Redirection         August 1999
-
-
-   A typical entry in the resulting reverse zone for some host with
-   address 192.0.9.33 might be
-
-       $ORIGIN 8/22.0.192.in-addr.arpa.
-       33.9    PTR     somehost.slash-22-holder.example.
-
-   The same advisory remarks concerning the choice of the "/" character
-   apply here as in [INADDR].
-
-5.3.  Network Renumbering Support
-
-   If IPv4 network renumbering were common, maintenance of address space
-   delegation could be simplified by using DNAME records instead of NS
-   records to delegate.
-
-      $ORIGIN new-style.in-addr.arpa.
-      189.190           DNAME    in-addr.example.net.
-
-      $ORIGIN in-addr.example.net.
-      188               DNAME    in-addr.customer.example.
-
-      $ORIGIN in-addr.customer.example.
-      1                 PTR      www.customer.example.
-      2                 PTR      mailhub.customer.example.
-      ; etc ...
-
-   This would allow the address space 190.189.0.0/16 assigned to the ISP
-   "example.net" to be changed without the necessity of altering the
-   zone files describing the use of that space by the ISP and its
-   customers.
-
-   Renumbering IPv4 networks is currently so arduous a task that
-   updating the DNS is only a small part of the labor, so this scheme
-   may have a low value.  But it is hoped that in IPv6 the renumbering
-   task will be quite different and the DNAME mechanism may play a
-   useful part.
-
-6.  IANA Considerations
-
-   This document defines a new DNS Resource Record type with the
-   mnemonic DNAME and type code 39 (decimal).  The naming/numbering
-   space is defined in [DNSIS].  This name and number have already been
-   registered with the IANA.
-
-
-
-
-
-
-
-
-Crawford                    Standards Track                     [Page 7]
-
-RFC 2672           Non-Terminal DNS Name Redirection         August 1999
-
-
-7.  Security Considerations
-
-   The DNAME record is similar to the CNAME record with regard to the
-   consequences of insertion of a spoofed record into a DNS server or
-   resolver, differing in that the DNAME's effect covers a whole subtree
-   of the name space.  The facilities of [DNSSEC] are available to
-   authenticate this record type.
-
-8.  References
-
-   [DNSCF]  Mockapetris, P., "Domain names - concepts and facilities",
-            STD 13, RFC 1034, November 1987.
-
-   [DNSCLR] Elz, R. and R. Bush, "Clarifications to the DNS
-            Specification", RFC 2181, July 1997.
-
-   [DNSIS]  Mockapetris, P., "Domain names - implementation and
-            specification", STD 13, RFC 1035, November 1987.
-
-   [DNSSEC] Eastlake, 3rd, D. and C. Kaufman, "Domain Name System
-            Security Extensions", RFC 2065, January 1997.
-
-   [DNSUPD] Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound,
-            "Dynamic Updates in the Domain Name System", RFC 2136, April
-            1997.
-
-   [EDNS0]  Vixie, P., "Extensions mechanisms for DNS (EDNS0)", RFC
-            2671, August 1999.
-
-   [INADDR] Eidnes, H., de Groot, G. and P. Vixie, "Classless IN-
-            ADDR.ARPA delegation", RFC 2317, March 1998.
-
-   [KWORD]  Bradner, S., "Key words for use in RFCs to Indicate
-            Requirement Levels," BCP 14, RFC 2119, March 1997.
-
-   [SECDYN] D. Eastlake, 3rd, "Secure Domain Name System Dynamic
-            Update", RFC 2137, April 1997.
-
-9.  Author's Address
-
-   Matt Crawford
-   Fermilab MS 368
-   PO Box 500
-   Batavia, IL 60510
-   USA
-
-   Phone: +1 630 840-3461
-   EMail: crawdad@fnal.gov
-
-
-
-Crawford                    Standards Track                     [Page 8]
-
-RFC 2672           Non-Terminal DNS Name Redirection         August 1999
-
-
-10.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crawford                    Standards Track                     [Page 9]
-
diff --git a/contrib/bind9/doc/rfc/rfc2673.txt b/contrib/bind9/doc/rfc/rfc2673.txt
deleted file mode 100644
index 19d272e..0000000
--- a/contrib/bind9/doc/rfc/rfc2673.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        M. Crawford
-Request for Comments: 2673                                      Fermilab
-Category: Standards Track                                    August 1999
-
-
-                Binary Labels in the Domain Name System
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-1.  Introduction and Terminology
-
-   This document defines a "Bit-String Label" which may appear within
-   domain names.  This new label type compactly represents a sequence of
-   "One-Bit Labels" and enables resource records to be stored at any
-   bit-boundary in a binary-named section of the domain name tree.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [KWORD].
-
-2.  Motivation
-
-   Binary labels are intended to efficiently solve the problem of
-   storing data and delegating authority on arbitrary boundaries when
-   the structure of underlying name space is most naturally represented
-   in binary.
-
-3.  Label Format
-
-   Up to 256 One-Bit Labels can be grouped into a single Bit-String
-   Label.  Within a Bit-String Label the most significant or "highest
-   level" bit appears first.  This is unlike the ordering of DNS labels
-   themselves, which has the least significant or "lowest level" label
-   first.  Nonetheless, this ordering seems to be the most natural and
-   efficient for representing binary labels.
-
-
-
-
-
-
-Crawford                    Standards Track                     [Page 1]
-
-RFC 2673        Binary Labels in the Domain Name System      August 1999
-
-
-   Among consecutive Bit-String Labels, the bits in the first-appearing
-   label are less significant or "at a lower level" than the bits in
-   subsequent Bit-String Labels, just as ASCII labels are ordered.
-
-3.1.  Encoding
-
-      0                   1                   2
-      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2     . . .
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+
-     |0 1|    ELT    |     Count     |           Label ...         |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+
-
-   (Each tic mark represents one bit.)
-
-
-   ELT       000001 binary, the six-bit extended label type [EDNS0]
-             assigned to the Bit-String Label.
-
-   Count     The number of significant bits in the Label field.  A Count
-             value of zero indicates that 256 bits are significant.
-             (Thus the null label representing the DNS root cannot be
-             represented as a Bit String Label.)
-
-   Label     The bit string representing a sequence of One-Bit Labels,
-             with the most significant bit first.  That is, the One-Bit
-             Label in position 17 in the diagram above represents a
-             subdomain of the domain represented by the One-Bit Label in
-             position 16, and so on.
-
-             The Label field is padded on the right with zero to seven
-             pad bits to make the entire field occupy an integral number
-             of octets.  These pad bits MUST be zero on transmission and
-             ignored on reception.
-
-   A sequence of bits may be split into two or more Bit-String Labels,
-   but the division points have no significance and need not be
-   preserved.  An excessively clever server implementation might split
-   Bit-String Labels so as to maximize the effectiveness of message
-   compression [DNSIS].  A simpler server might divide Bit-String Labels
-   at zone boundaries, if any zone boundaries happen to fall between
-   One-Bit Labels.
-
-3.2.  Textual Representation
-
-   A Bit-String Label is represented in text -- in a zone file, for
-   example -- as a <bit-spec> surrounded by the delimiters "\[" and "]".
-   The <bit-spec> is either a dotted quad or a base indicator and a
-   sequence of digits appropriate to that base, optionally followed by a
-
-
-
-Crawford                    Standards Track                     [Page 2]
-
-RFC 2673        Binary Labels in the Domain Name System      August 1999
-
-
-   slash and a length.  The base indicators are "b", "o" and "x",
-   denoting base 2, 8 and 16 respectively.  The length counts the
-   significant bits and MUST be between 1 and 32, inclusive, after a
-   dotted quad, or between 1 and 256, inclusive, after one of the other
-   forms.  If the length is omitted, the implicit length is 32 for a
-   dotted quad or 1, 3 or 4 times the number of binary, octal or
-   hexadecimal digits supplied, respectively, for the other forms.
-
-   In augmented Backus-Naur form [ABNF],
-
-     bit-string-label =  "\[" bit-spec "]"
-
-     bit-spec         =  bit-data [ "/" length ]
-                       / dotted-quad [ "/" slength ]
-
-     bit-data         =  "x" 1*64HEXDIG
-                       / "o" 1*86OCTDIG
-                       / "b" 1*256BIT
-
-     dotted-quad      =  decbyte "." decbyte "." decbyte "." decbyte
-
-     decbyte          =  1*3DIGIT
-
-     length           =  NZDIGIT *2DIGIT
-
-     slength          =  NZDIGIT [ DIGIT ]
-
-     OCTDIG           =  %x30-37
-
-     NZDIGIT          =  %x31-39
-
-   If a <length> is present, the number of digits in the <bit-data> MUST
-   be just sufficient to contain the number of bits specified by the
-   <length>.  If there are insignificant bits in a final hexadecimal or
-   octal digit, they MUST be zero.  A <dotted-quad> always has all four
-   parts even if the associated <slength> is less than 24, but, like the
-   other forms, insignificant bits MUST be zero.
-
-   Each number represented by a <decbyte> must be between 0 and 255,
-   inclusive.
-
-   The number represented by <length> must be between 1 and 256
-   inclusive.
-
-   The number represented by <slength> must be between 1 and 32
-   inclusive.
-
-
-
-
-
-Crawford                    Standards Track                     [Page 3]
-
-RFC 2673        Binary Labels in the Domain Name System      August 1999
-
-
-   When the textual form of a Bit-String Label is generated by machine,
-   the length SHOULD be explicit, not implicit.
-
-3.2.1.  Examples
-
-   The following four textual forms represent the same Bit-String Label.
-
-                             \[b11010000011101]
-                             \[o64072/14]
-                             \[xd074/14]
-                             \[208.116.0.0/14]
-
-   The following represents two consecutive Bit-String Labels which
-   denote the same relative point in the DNS tree as any of the above
-   single Bit-String Labels.
-
-                             \[b11101].\[o640]
-
-3.3.  Canonical Representation and Sort Order
-
-   Both the wire form and the text form of binary labels have a degree
-   of flexibility in their grouping into multiple consecutive Bit-String
-   Labels.  For generating and checking DNS signature records [DNSSEC]
-   binary labels must be in a predictable form.  This canonical form is
-   defined as the form which has the fewest possible Bit-String Labels
-   and in which all except possibly the first (least significant) label
-   in any sequence of consecutive Bit-String Labels is of maximum
-   length.
-
-   For example, the canonical form of any sequence of up to 256 One-Bit
-   Labels has a single Bit-String Label, and the canonical form of a
-   sequence of 513 to 768 One-Bit Labels has three Bit-String Labels of
-   which the second and third contain 256 label bits.
-
-   The canonical sort order of domain names [DNSSEC] is extended to
-   encompass binary labels as follows.  Sorting is still label-by-label,
-   from most to least significant, where a label may now be a One-Bit
-   Label or a standard (code 00) label.  Any One-Bit Label sorts before
-   any standard label, and a 0 bit sorts before a 1 bit.  The absence of
-   a label sorts before any label, as specified in [DNSSEC].
-
-
-
-
-
-
-
-
-
-
-
-Crawford                    Standards Track                     [Page 4]
-
-RFC 2673        Binary Labels in the Domain Name System      August 1999
-
-
-   For example, the following domain names are correctly sorted.
-
-                         foo.example
-                         \[b1].foo.example
-                         \[b100].foo.example
-                         \[b101].foo.example
-                         bravo.\[b10].foo.example
-                         alpha.foo.example
-
-4.  Processing Rules
-
-   A One-Bit Label never matches any other kind of label.  In
-   particular, the DNS labels represented by the single ASCII characters
-   "0" and "1" do not match One-Bit Labels represented by the bit values
-   0 and 1.
-
-5.  Discussion
-
-   A Count of zero in the wire-form represents a 256-bit sequence, not
-   to optimize that particular case, but to make it completely
-   impossible to have a zero-bit label.
-
-6.  IANA Considerations
-
-   This document defines one Extended Label Type, termed the Bit-String
-   Label, and requests registration of the code point 000001 binary in
-   the space defined by [EDNS0].
-
-7.  Security Considerations
-
-   All security considerations which apply to traditional ASCII DNS
-   labels apply equally to binary labels.  he canonicalization and
-   sorting rules of section 3.3 allow these to be addressed by DNS
-   Security [DNSSEC].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crawford                    Standards Track                     [Page 5]
-
-RFC 2673        Binary Labels in the Domain Name System      August 1999
-
-
-8.  References
-
-   [ABNF]   Crocker, D. and P. Overell, "Augmented BNF for Syntax
-            Specifications: ABNF", RFC 2234, November 1997.
-
-   [DNSIS]  Mockapetris, P., "Domain names - implementation and
-            specification", STD 13, RFC 1035, November 1987.
-
-   [DNSSEC] Eastlake, D., 3rd, C. Kaufman, "Domain Name System Security
-            Extensions", RFC 2065, January 1997
-
-   [EDNS0]  Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC 2671,
-            August 1999.
-
-   [KWORD]  Bradner, S., "Key words for use in RFCs to Indicate
-            Requirement Levels," BCP 14, RFC 2119, March 1997.
-
-9.  Author's Address
-
-   Matt Crawford
-   Fermilab MS 368
-   PO Box 500
-   Batavia, IL 60510
-   USA
-
-   Phone: +1 630 840-3461
-   EMail: crawdad@fnal.gov
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crawford                    Standards Track                     [Page 6]
-
-RFC 2673        Binary Labels in the Domain Name System      August 1999
-
-
-10.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crawford                    Standards Track                     [Page 7]
-
diff --git a/contrib/bind9/doc/rfc/rfc2782.txt b/contrib/bind9/doc/rfc/rfc2782.txt
deleted file mode 100644
index 1827f10..0000000
--- a/contrib/bind9/doc/rfc/rfc2782.txt
+++ /dev/null
@@ -1,675 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                     A. Gulbrandsen
-Request for Comments: 2782                            Troll Technologies
-Obsoletes: 2052                                                 P. Vixie
-Category: Standards Track                   Internet Software Consortium
-                                                               L. Esibov
-                                                         Microsoft Corp.
-                                                           February 2000
-
-
-       A DNS RR for specifying the location of services (DNS SRV)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-Abstract
-
-   This document describes a DNS RR which specifies the location of the
-   server(s) for a specific protocol and domain.
-
-Overview and rationale
-
-   Currently, one must either know the exact address of a server to
-   contact it, or broadcast a question.
-
-   The SRV RR allows administrators to use several servers for a single
-   domain, to move services from host to host with little fuss, and to
-   designate some hosts as primary servers for a service and others as
-   backups.
-
-   Clients ask for a specific service/protocol for a specific domain
-   (the word domain is used here in the strict RFC 1034 sense), and get
-   back the names of any available servers.
-
-   Note that where this document refers to "address records", it means A
-   RR's, AAAA RR's, or their most modern equivalent.
-
-
-
-
-
-
-
-Gulbrandsen, et al.         Standards Track                     [Page 1]
-
-RFC 2782                       DNS SRV RR                  February 2000
-
-
-Definitions
-
-   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY"
-   used in this document are to be interpreted as specified in [BCP 14].
-   Other terms used in this document are defined in the DNS
-   specification, RFC 1034.
-
-Applicability Statement
-
-   In general, it is expected that SRV records will be used by clients
-   for applications where the relevant protocol specification indicates
-   that clients should use the SRV record. Such specification MUST
-   define the symbolic name to be used in the Service field of the SRV
-   record as described below. It also MUST include security
-   considerations. Service SRV records SHOULD NOT be used in the absence
-   of such specification.
-
-Introductory example
-
-   If a SRV-cognizant LDAP client wants to discover a LDAP server that
-   supports TCP protocol and provides LDAP service for the domain
-   example.com., it does a lookup of
-
-      _ldap._tcp.example.com
-
-   as described in [ARM].  The example zone file near the end of this
-   memo contains answering RRs for an SRV query.
-
-   Note: LDAP is chosen as an example for illustrative purposes only,
-   and the LDAP examples used in this document should not be considered
-   a definitive statement on the recommended way for LDAP to use SRV
-   records. As described in the earlier applicability section, consult
-   the appropriate LDAP documents for the recommended procedures.
-
-The format of the SRV RR
-
-   Here is the format of the SRV RR, whose DNS type code is 33:
-
-        _Service._Proto.Name TTL Class SRV Priority Weight Port Target
-
-        (There is an example near the end of this document.)
-
-   Service
-        The symbolic name of the desired service, as defined in Assigned
-        Numbers [STD 2] or locally.  An underscore (_) is prepended to
-        the service identifier to avoid collisions with DNS labels that
-        occur in nature.
-
-
-
-
-Gulbrandsen, et al.         Standards Track                     [Page 2]
-
-RFC 2782                       DNS SRV RR                  February 2000
-
-
-        Some widely used services, notably POP, don't have a single
-        universal name.  If Assigned Numbers names the service
-        indicated, that name is the only name which is legal for SRV
-        lookups.  The Service is case insensitive.
-
-   Proto
-        The symbolic name of the desired protocol, with an underscore
-        (_) prepended to prevent collisions with DNS labels that occur
-        in nature.  _TCP and _UDP are at present the most useful values
-        for this field, though any name defined by Assigned Numbers or
-        locally may be used (as for Service).  The Proto is case
-        insensitive.
-
-   Name
-        The domain this RR refers to.  The SRV RR is unique in that the
-        name one searches for is not this name; the example near the end
-        shows this clearly.
-
-   TTL
-        Standard DNS meaning [RFC 1035].
-
-   Class
-        Standard DNS meaning [RFC 1035].   SRV records occur in the IN
-        Class.
-
-   Priority
-        The priority of this target host.  A client MUST attempt to
-        contact the target host with the lowest-numbered priority it can
-        reach; target hosts with the same priority SHOULD be tried in an
-        order defined by the weight field.  The range is 0-65535.  This
-        is a 16 bit unsigned integer in network byte order.
-
-   Weight
-        A server selection mechanism.  The weight field specifies a
-        relative weight for entries with the same priority. Larger
-        weights SHOULD be given a proportionately higher probability of
-        being selected. The range of this number is 0-65535.  This is a
-        16 bit unsigned integer in network byte order.  Domain
-        administrators SHOULD use Weight 0 when there isn't any server
-        selection to do, to make the RR easier to read for humans (less
-        noisy).  In the presence of records containing weights greater
-        than 0, records with weight 0 should have a very small chance of
-        being selected.
-
-        In the absence of a protocol whose specification calls for the
-        use of other weighting information, a client arranges the SRV
-        RRs of the same Priority in the order in which target hosts,
-
-
-
-
-Gulbrandsen, et al.         Standards Track                     [Page 3]
-
-RFC 2782                       DNS SRV RR                  February 2000
-
-
-        specified by the SRV RRs, will be contacted. The following
-        algorithm SHOULD be used to order the SRV RRs of the same
-        priority:
-
-        To select a target to be contacted next, arrange all SRV RRs
-        (that have not been ordered yet) in any order, except that all
-        those with weight 0 are placed at the beginning of the list.
-
-        Compute the sum of the weights of those RRs, and with each RR
-        associate the running sum in the selected order. Then choose a
-        uniform random number between 0 and the sum computed
-        (inclusive), and select the RR whose running sum value is the
-        first in the selected order which is greater than or equal to
-        the random number selected. The target host specified in the
-        selected SRV RR is the next one to be contacted by the client.
-        Remove this SRV RR from the set of the unordered SRV RRs and
-        apply the described algorithm to the unordered SRV RRs to select
-        the next target host.  Continue the ordering process until there
-        are no unordered SRV RRs.  This process is repeated for each
-        Priority.
-
-   Port
-        The port on this target host of this service.  The range is 0-
-        65535.  This is a 16 bit unsigned integer in network byte order.
-        This is often as specified in Assigned Numbers but need not be.
-
-   Target
-        The domain name of the target host.  There MUST be one or more
-        address records for this name, the name MUST NOT be an alias (in
-        the sense of RFC 1034 or RFC 2181).  Implementors are urged, but
-        not required, to return the address record(s) in the Additional
-        Data section.  Unless and until permitted by future standards
-        action, name compression is not to be used for this field.
-
-        A Target of "." means that the service is decidedly not
-        available at this domain.
-
-Domain administrator advice
-
-   Expecting everyone to update their client applications when the first
-   server publishes a SRV RR is futile (even if desirable).  Therefore
-   SRV would have to coexist with address record lookups for existing
-   protocols, and DNS administrators should try to provide address
-   records to support old clients:
-
-      - Where the services for a single domain are spread over several
-        hosts, it seems advisable to have a list of address records at
-        the same DNS node as the SRV RR, listing reasonable (if perhaps
-
-
-
-Gulbrandsen, et al.         Standards Track                     [Page 4]
-
-RFC 2782                       DNS SRV RR                  February 2000
-
-
-        suboptimal) fallback hosts for Telnet, NNTP and other protocols
-        likely to be used with this name.  Note that some programs only
-        try the first address they get back from e.g. gethostbyname(),
-        and we don't know how widespread this behavior is.
-
-      - Where one service is provided by several hosts, one can either
-        provide address records for all the hosts (in which case the
-        round-robin mechanism, where available, will share the load
-        equally) or just for one (presumably the fastest).
-
-      - If a host is intended to provide a service only when the main
-        server(s) is/are down, it probably shouldn't be listed in
-        address records.
-
-      - Hosts that are referenced by backup address records must use the
-        port number specified in Assigned Numbers for the service.
-
-      - Designers of future protocols for which "secondary servers" is
-        not useful (or meaningful) may choose to not use SRV's support
-        for secondary servers.  Clients for such protocols may use or
-        ignore SRV RRs with Priority higher than the RR with the lowest
-        Priority for a domain.
-
-   Currently there's a practical limit of 512 bytes for DNS replies.
-   Until all resolvers can handle larger responses, domain
-   administrators are strongly advised to keep their SRV replies below
-   512 bytes.
-
-   All round numbers, wrote Dr. Johnson, are false, and these numbers
-   are very round: A reply packet has a 30-byte overhead plus the name
-   of the service ("_ldap._tcp.example.com" for instance); each SRV RR
-   adds 20 bytes plus the name of the target host; each NS RR in the NS
-   section is 15 bytes plus the name of the name server host; and
-   finally each A RR in the additional data section is 20 bytes or so,
-   and there are A's for each SRV and NS RR mentioned in the answer.
-   This size estimate is extremely crude, but shouldn't underestimate
-   the actual answer size by much.  If an answer may be close to the
-   limit, using a DNS query tool (e.g. "dig") to look at the actual
-   answer is a good idea.
-
-The "Weight" field
-
-   Weight, the server selection field, is not quite satisfactory, but
-   the actual load on typical servers changes much too quickly to be
-   kept around in DNS caches.  It seems to the authors that offering
-   administrators a way to say "this machine is three times as fast as
-   that one" is the best that can practically be done.
-
-
-
-
-Gulbrandsen, et al.         Standards Track                     [Page 5]
-
-RFC 2782                       DNS SRV RR                  February 2000
-
-
-   The only way the authors can see of getting a "better" load figure is
-   asking a separate server when the client selects a server and
-   contacts it.  For short-lived services an extra step in the
-   connection establishment seems too expensive, and for long-lived
-   services, the load figure may well be thrown off a minute after the
-   connection is established when someone else starts or finishes a
-   heavy job.
-
-   Note: There are currently various experiments at providing relative
-   network proximity estimation, available bandwidth estimation, and
-   similar services.  Use of the SRV record with such facilities, and in
-   particular the interpretation of the Weight field when these
-   facilities are used, is for further study.  Weight is only intended
-   for static, not dynamic, server selection.  Using SRV weight for
-   dynamic server selection would require assigning unreasonably short
-   TTLs to the SRV RRs, which would limit the usefulness of the DNS
-   caching mechanism, thus increasing overall network load and
-   decreasing overall reliability.  Server selection via SRV is only
-   intended to express static information such as "this server has a
-   faster CPU than that one" or "this server has a much better network
-   connection than that one".
-
-The Port number
-
-   Currently, the translation from service name to port number happens
-   at the client, often using a file such as /etc/services.
-
-   Moving this information to the DNS makes it less necessary to update
-   these files on every single computer of the net every time a new
-   service is added, and makes it possible to move standard services out
-   of the "root-only" port range on unix.
-
-Usage rules
-
-   A SRV-cognizant client SHOULD use this procedure to locate a list of
-   servers and connect to the preferred one:
-
-        Do a lookup for QNAME=_service._protocol.target, QCLASS=IN,
-        QTYPE=SRV.
-
-        If the reply is NOERROR, ANCOUNT>0 and there is at least one
-        SRV RR which specifies the requested Service and Protocol in
-        the reply:
-
-            If there is precisely one SRV RR, and its Target is "."
-            (the root domain), abort.
-
-
-
-
-
-Gulbrandsen, et al.         Standards Track                     [Page 6]
-
-RFC 2782                       DNS SRV RR                  February 2000
-
-
-            Else, for all such RR's, build a list of (Priority, Weight,
-            Target) tuples
-
-            Sort the list by priority (lowest number first)
-
-            Create a new empty list
-
-            For each distinct priority level
-                While there are still elements left at this priority
-                level
-
-                    Select an element as specified above, in the
-                    description of Weight in "The format of the SRV
-                    RR" Section, and move it to the tail of the new
-                    list
-
-            For each element in the new list
-
-                query the DNS for address records for the Target or
-                use any such records found in the Additional Data
-                section of the earlier SRV response.
-
-                for each address record found, try to connect to the
-               (protocol, address, service).
-
-        else
-
-            Do a lookup for QNAME=target, QCLASS=IN, QTYPE=A
-
-            for each address record found, try to connect to the
-           (protocol, address, service)
-
-Notes:
-
-   - Port numbers SHOULD NOT be used in place of the symbolic service
-     or protocol names (for the same reason why variant names cannot
-     be allowed: Applications would have to do two or more lookups).
-
-   - If a truncated response comes back from an SRV query, the rules
-     described in [RFC 2181] shall apply.
-
-   - A client MUST parse all of the RR's in the reply.
-
-   - If the Additional Data section doesn't contain address records
-     for all the SRV RR's and the client may want to connect to the
-     target host(s) involved, the client MUST look up the address
-     record(s).  (This happens quite often when the address record
-     has shorter TTL than the SRV or NS RR's.)
-
-
-
-Gulbrandsen, et al.         Standards Track                     [Page 7]
-
-RFC 2782                       DNS SRV RR                  February 2000
-
-
-   - Future protocols could be designed to use SRV RR lookups as the
-     means by which clients locate their servers.
-
-Fictional example
-
-   This example uses fictional service "foobar" as an aid in
-   understanding SRV records. If ever service "foobar" is implemented,
-   it is not intended that it will necessarily use SRV records.  This is
-   (part of) the zone file for example.com, a still-unused domain:
-
-      $ORIGIN example.com.
-      @               SOA server.example.com. root.example.com. (
-                          1995032001 3600 3600 604800 86400 )
-                      NS  server.example.com.
-                      NS  ns1.ip-provider.net.
-                      NS  ns2.ip-provider.net.
-      ; foobar - use old-slow-box or new-fast-box if either is
-      ; available, make three quarters of the logins go to
-      ; new-fast-box.
-      _foobar._tcp    SRV 0 1 9 old-slow-box.example.com.
-                       SRV 0 3 9 new-fast-box.example.com.
-      ; if neither old-slow-box or new-fast-box is up, switch to
-      ; using the sysdmin's box and the server
-                       SRV 1 0 9 sysadmins-box.example.com.
-                       SRV 1 0 9 server.example.com.
-      server           A   172.30.79.10
-      old-slow-box     A   172.30.79.11
-      sysadmins-box    A   172.30.79.12
-      new-fast-box     A   172.30.79.13
-      ; NO other services are supported
-      *._tcp          SRV  0 0 0 .
-      *._udp          SRV  0 0 0 .
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gulbrandsen, et al.         Standards Track                     [Page 8]
-
-RFC 2782                       DNS SRV RR                  February 2000
-
-
-   In this example, a client of the "foobar" service in the
-   "example.com." domain needs an SRV lookup of
-   "_foobar._tcp.example.com." and possibly A lookups of "new-fast-
-   box.example.com." and/or the other hosts named.  The size of the SRV
-   reply is approximately 365 bytes:
-
-      30 bytes general overhead
-      20 bytes for the query string, "_foobar._tcp.example.com."
-      130 bytes for 4 SRV RR's, 20 bytes each plus the lengths of "new-
-        fast-box", "old-slow-box", "server" and "sysadmins-box" -
-        "example.com" in the query section is quoted here and doesn't
-        need to be counted again.
-      75 bytes for 3 NS RRs, 15 bytes each plus the lengths of "server",
-        "ns1.ip-provider.net." and "ns2" - again, "ip-provider.net." is
-        quoted and only needs to be counted once.
-      120 bytes for the 6 address records (assuming IPv4 only) mentioned
-        by the SRV and NS RR's.
-
-IANA Considerations
-
-   The IANA has assigned RR type value 33 to the SRV RR.  No other IANA
-   services are required by this document.
-
-Changes from RFC 2052
-
-   This document obsoletes RFC 2052.   The major change from that
-   previous, experimental, version of this specification is that now the
-   protocol and service labels are prepended with an underscore, to
-   lower the probability of an accidental clash with a similar name used
-   for unrelated purposes.  Aside from that, changes are only intended
-   to increase the clarity and completeness of the document. This
-   document especially clarifies the use of the Weight field of the SRV
-   records.
-
-Security Considerations
-
-   The authors believe this RR to not cause any new security problems.
-   Some problems become more visible, though.
-
-   - The ability to specify ports on a fine-grained basis obviously
-     changes how a router can filter packets.  It becomes impossible
-     to block internal clients from accessing specific external
-     services, slightly harder to block internal users from running
-     unauthorized services, and more important for the router
-     operations and DNS operations personnel to cooperate.
-
-   - There is no way a site can keep its hosts from being referenced
-     as servers.  This could lead to denial of service.
-
-
-
-Gulbrandsen, et al.         Standards Track                     [Page 9]
-
-RFC 2782                       DNS SRV RR                  February 2000
-
-
-   - With SRV, DNS spoofers can supply false port numbers, as well as
-     host names and addresses.   Because this vulnerability exists
-     already, with names and addresses, this is not a new
-     vulnerability, merely a slightly extended one, with little
-     practical effect.
-
-References
-
-   STD 2:    Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
-             1700, October 1994.
-
-   RFC 1034: Mockapetris, P., "Domain names - concepts and facilities",
-             STD 13, RFC 1034, November 1987.
-
-   RFC 1035: Mockapetris, P., "Domain names - Implementation and
-             Specification", STD 13, RFC 1035, November 1987.
-
-   RFC 974:  Partridge, C., "Mail routing and the domain system", STD
-             14, RFC 974, January 1986.
-
-   BCP 14:   Bradner, S., "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   RFC 2181: Elz, R. and R. Bush, "Clarifications to the DNS
-             Specification", RFC 2181, July 1997.
-
-   RFC 2219: Hamilton, M. and R. Wright, "Use of DNS Aliases for Network
-             Services", BCP 17, RFC 2219, October 1997.
-
-   BCP 14:   Bradner, S., "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   ARM:      Armijo, M., Esibov, L. and P. Leach, "Discovering LDAP
-             Services with DNS", Work in Progress.
-
-   KDC-DNS:  Hornstein, K. and J. Altman, "Distributing Kerberos KDC and
-             Realm Information with DNS", Work in Progress.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gulbrandsen, et al.         Standards Track                    [Page 10]
-
-RFC 2782                       DNS SRV RR                  February 2000
-
-
-Acknowledgements
-
-   The algorithm used to select from the weighted SRV RRs of equal
-   priority is adapted from one supplied by Dan Bernstein.
-
-Authors' Addresses
-
-   Arnt Gulbrandsen
-   Troll Tech
-   Waldemar Thranes gate 98B
-   N-0175 Oslo, Norway
-
-   Fax:   +47 22806380
-   Phone: +47 22806390
-   EMail: arnt@troll.no
-
-
-   Paul Vixie
-   Internet Software Consortium
-   950 Charter Street
-   Redwood City, CA 94063
-
-   Phone: +1 650 779 7001
-
-
-   Levon Esibov
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA 98052
-
-   EMail: levone@microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gulbrandsen, et al.         Standards Track                    [Page 11]
-
-RFC 2782                       DNS SRV RR                  February 2000
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gulbrandsen, et al.         Standards Track                    [Page 12]
-
diff --git a/contrib/bind9/doc/rfc/rfc2825.txt b/contrib/bind9/doc/rfc/rfc2825.txt
deleted file mode 100644
index fd8ef7c..0000000
--- a/contrib/bind9/doc/rfc/rfc2825.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-

-

-

-

-

-

-Network Working Group                  Internet Architecture Board (IAB)

-Request for Comments: 2825                             L. Daigle, Editor

-Category: Informational                                         May 2000

-

-

-         A Tangled Web: Issues of I18N, Domain Names, and the

-                        Other Internet protocols

-

-Status of this Memo

-

-   This memo provides information for the Internet community.  It does

-   not specify an Internet standard of any kind.  Distribution of this

-   memo is unlimited.

-

-Copyright Notice

-

-   Copyright (C) The Internet Society (2000).  All Rights Reserved.

-

-Abstract

-

-   The goals of the work to "internationalize" Internet protocols

-   include providing all users of the Internet with the capability of

-   using their own language and its standard character set to express

-   themselves, write names, and to navigate the network. This impacts

-   the domain names visible in e-mail addresses and so many of today's

-   URLs used to locate information on the World Wide Web, etc.  However,

-   domain names are used by Internet protocols that are used across

-   national boundaries. These services must interoperate worldwide, or

-   we risk isolating components of the network from each other along

-   locale boundaries.  This type of isolation could impede not only

-   communications among people, but opportunities of the areas involved

-   to participate effectively in e-commerce, distance learning, and

-   other activities at an international scale, thereby retarding

-   economic development.

-

-   There are several proposals for internationalizing domain names,

-   however it it is still to be determined whether any of them will

-   ensure this interoperability and global reach while addressing

-   visible-name representation.  Some of them obviously do not. This

-   document does not attempt to review any specific proposals, as that

-   is the work of the Internationalized Domain Name (IDN) Working Group

-   of the IETF, which is tasked with evaluating them in consideration of

-   the continued global network interoperation that is the deserved

-   expectation of all Internet users.

-

-

-

-

-

-

-

-IAB                          Informational                      [Page 1]

-

-RFC 2825   Issues: I18N, Domain Names, and Internet Protocols   May 2000

-

-

-   This document is a statement by the Internet Architecture Board. It

-   is not a protocol specification, but an attempt to clarify the range

-   of architectural issues that the internationalization of domain names

-   faces.

-

-1. A Definition of Success

-

-   The Internationalized Domain Names (IDN) Working Group is one

-   component of the IETF's continuing comprehensive effort to

-   internationalize language representation facilities in the protocols

-   that support the global functioning of the Internet.

-

-   In keeping with the principles of rough consensus, running code,

-   architectural integrity, and in the interest of ensuring the global

-   stability of the Internet, the IAB emphasizes that all solutions

-   proposed to the (IDN) Working Group will have to be evaluated not

-   only on their individual technical features, but also in terms of

-   impact on existing standards and operations of the Internet and the

-   total effect for end-users: solutions must not cause users to become

-   more isolated from their global neighbors even if they appear to

-   solve a local problem.  In some cases, existing protocols have

-   limitations on allowable characters, and in other cases

-   implementations of protocols used in the core of the Internet (beyond

-   individual organizations) have in practice not implemented all the

-   requisite options of the standards.

-

-2. Technical Challenges within the Domain Name System (DNS)

-

-   In many technical respects, the IDN work is not different from any

-   other effort to enable multiple character set representations in

-   textual elements that were traditionally restricted to English

-   language characters.

-

-   One aspect of the challenge is to decide how to represent the names

-   users want in the DNS in a way that is clear, technically feasible,

-   and ensures that a name always means the same thing.  Several

-   proposals have been suggested to address these issues.

-

-   These issues are being outlined in more detail in the IDN WG's

-   evolving draft requirements document; further discussion is deferred

-   to the WG and its documents.

-

-3. Integrating with Current Realities

-

-   Nevertheless, issues faced by the IDN working group are complex and

-   intricately intertwined with other operational components of the

-   Internet.  A key challenge in evaluating any proposed solution is the

-   analysis of the impact on existing critical operational standards

-

-

-

-IAB                          Informational                      [Page 2]

-

-RFC 2825   Issues: I18N, Domain Names, and Internet Protocols   May 2000

-

-

-   which use fully-qualified domain names [RFC1034], or simply host

-   names [RFC1123].  Standards-changes can be effected, but the best

-   path forward is one that takes into account current realities and

-   (re)deployment latencies. In the Internet's global context, it is not

-   enough to update a few isolated systems, or even most of the systems

-   in a country or region.  Deployment must be nearly universal in order

-   to avoid the creation of "islands" of interoperation that provide

-   users with less access to and connection from the rest of the world.

-

-   These are not esoteric or ephemeral concerns.  Some specific issues

-   have already been identified as part of the IDN WG's efforts.  These

-   include (but are not limited to) the following examples.

-

-3.1 Domain Names and E-mail

-

-   As indicated in the IDN WG's draft requirements document, the issue

-   goes beyond standardization of DNS usage.  Electronic mail has long

-   been one of the most-used and most important applications of the

-   Internet.  Internet e-mail is also used as the bridge that permits

-   the users of a variety of local and proprietary mail systems to

-   communicate. The standard protocols that define its use (e.g., SMTP

-   [RFC821, RFC822] and MIME [RFC2045]) do not permit the full range of

-   characters allowed in the DNS specification. Certain characters are

-   not allowed in e-mail address domain portions of these

-   specifications.  Some mailers, built to adhere to these

-   specifications, are known to fail when on mail having non-ASCII

-   domain names in its address -- by discarding, misrouting or damaging

-   the mail.  Thus, it's not possible to simply switch to

-   internationalized domain names and expect global e-mail to continue

-   to work until most of the servers in the world are upgraded.

-

-3.2 Domain Names and Routing

-

-   At a lower level, the Routing Policy Specification Language (RPLS)

-   [RFC2622] makes use of "named objects" -- and inherits object naming

-   restrictions from older standards ([RFC822] for the same e-mail

-   address restrictions, [RFC1034] for hostnames).  This means that

-   until routing registries and their protocols are updated, it is not

-   possible to enter or retrieve network descriptions utilizing

-   internationalized domain names.

-

-3.3 Domain Names and Network Management

-

-   Also, the Simple Network Management Protocol (SNMP) uses the textual

-   representation defined in [RFC2579].  While that specification does

-   allow for UTF-8-based domain names, an informal survey of deployed

-   implementations of software libraries being used to build SNMP-

-   compliant software uncovered the fact that few (if any) implement it.

-

-

-

-IAB                          Informational                      [Page 3]

-

-RFC 2825   Issues: I18N, Domain Names, and Internet Protocols   May 2000

-

-

-   This may cause inability to enter or display correct data in network

-   management tools, if such names are internationalized domain names.

-

-3.4 Domain Names and Security

-

-   Critical components of Internet public key technologies (PKIX,

-   [RFC2459], IKE [RFC2409]) rely heavily on identification of servers

-   (hostnames, or fully qualified domain names) and users (e-mail

-   addresses).  Failure to respect the character restrictions in these

-   protocols will impact security tools built to use them -- Transport

-   Layer Security protocol (TLS, [RFC2246]), and IPsec [RFC2401] to name

-   two.

-

-   Failure may not be obvious.  For example, in TLS, it is common usage

-   for a server to display a certificate containing a domain name

-   purporting to be the domain name of the server, which the client can

-   then match with the server name he thought he used to reach the

-   service.

-

-   Unless comparison of domain names is properly defined, the client may

-   either fail to match the domain name of a legitimate server, or match

-   incorrectly the domain name of a server performing a man-in-the-

-   middle attack.  Either failure could enable attacks on systems that

-   are now impossible or at least far more difficult.

-

-4. Conclusion

-

-   It is therefore clear that, although there are many possible ways to

-   assign internationalized names that are compatible with today's DNS

-   (or a version that is easily-deployable in the near future), not all

-   of them are compatible with the full range of necessary networking

-   tools.  When designing a solution for internationalization of domain

-   names, the effects on the current Internet must be carefully

-   evaluated. Some types of solutions proposed would, if put into effect

-   immediately, cause Internet communications to fail in ways that would

-   be hard to detect by and pose problems for those who deploy the new

-   services, but also for those who do not; this would have the effect

-   of cutting those who deploy them off from effective use of the

-   Internet.

-

-   The IDN WG has been identified as the appropriate forum for

-   identifying and discussing solutions for such potential

-   interoperability issues.

-

-   Experience with deployment of other protocols has indicated that it

-   will take years before a new protocol or enhancement is used all over

-   the Internet.  So far, the IDN WG has benefited from proposed

-   solutions from all quarters, including organizations hoping to

-

-

-

-IAB                          Informational                      [Page 4]

-

-RFC 2825   Issues: I18N, Domain Names, and Internet Protocols   May 2000

-

-

-   provide services that address visible-name representation and

-   registration -- continuing this process with the aim of getting a

-   single, scalable and deployable solution to this problem is the only

-   way to ensure the continued global interoperation that is the

-   deserved expectation of all Internet users.

-

-5. Security Considerations

-

-   In general, assignment and use of names does not raise any special

-   security problems.  However, as noted above, some existing security

-   mechanisms are reliant on the current specification of domain names

-   and may not be expected to work, as is, with Internationalized domain

-   names.  Additionally, deployment of non-standard systems (e.g., in

-   response to current pressures to address national or regional

-   characterset representation) might result in name strings that are

-   not globally unique, thereby opening up the possibility of "spoofing"

-   hosts from one domain in another, as described in [RFC2826].

-

-6. Acknowledgements

-

-   This document is the outcome of the joint effort of the members of

-   the IAB.  Additionally, valuable remarks were provided by Randy Bush,

-   Patrik Faltstrom, Ted Hardie, Paul Hoffman, and Mark Kosters.

-

-7. References

-

-   [RFC821]  Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC

-             821, August 1982.

-

-   [RFC822]  Crocker, D., "Standard for the Format of ARPA Internet Text

-             Messages", STD 11, RFC 822, August 1982.

-

-   [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",

-             STD 13, RFC 1034, November 1987.

-

-   [RFC1123] Braden, R., "Requirements for Internet Hosts -- Application

-             and Support", STD 3, RFC 1123, November 1989.

-

-   [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the

-             Internet Protocol", RFC 2401, November 1998.

-

-   [RFC2409] Harkins, D and D. Carrel, "The Internet Key Exchange

-             (IKE)", RFC 2409, November 1998.

-

-   [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail

-             Extensions (MIME) Part One:  Format of Internet Message

-             Bodies", RFC 2045, November 1996.

-

-

-

-

-IAB                          Informational                      [Page 5]

-

-RFC 2825   Issues: I18N, Domain Names, and Internet Protocols   May 2000

-

-

-   [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",

-             RFC 2246, January 1999.

-

-   [RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet

-             X.509 Public Key Infrastructure Certificate and CRL

-             Profile", RFC 2459, January 1999.

-

-   [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.

-             and M. Rose, "Textual Conventions for SMIv2", RFC 2579,

-             April 1999.

-

-   [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,

-             Meyer, D., Bates, T., Karrenberg, D. and M. Terpstra,

-             "Routing Policy Specification Language (RPSL)", RFC 2622,

-             June 1999.

-

-   [RFC2826] IAB, "IAB Technical Comment on the Unique DNS Root", RFC

-             2826, May 2000.

-

-8. Author's Address

-

-   Internet Architecture Board

-

-   EMail:  iab@iab.org

-

-

-   Membership at time this document was completed:

-

-      Harald Alvestrand

-      Ran Atkinson

-      Rob Austein

-      Brian Carpenter

-      Steve Bellovin

-      Jon Crowcroft

-      Leslie Daigle

-      Steve Deering

-      Tony Hain

-      Geoff Huston

-      John Klensin

-      Henning Schulzrinne

-

-

-

-

-

-

-

-

-

-

-

-IAB                          Informational                      [Page 6]

-

-RFC 2825   Issues: I18N, Domain Names, and Internet Protocols   May 2000

-

-

-9. Full Copyright Statement

-

-   Copyright (C) The Internet Society (2000).  All Rights Reserved.

-

-   This document and translations of it may be copied and furnished to

-   others, and derivative works that comment on or otherwise explain it

-   or assist in its implementation may be prepared, copied, published

-   and distributed, in whole or in part, without restriction of any

-   kind, provided that the above copyright notice and this paragraph are

-   included on all such copies and derivative works.  However, this

-   document itself may not be modified in any way, such as by removing

-   the copyright notice or references to the Internet Society or other

-   Internet organizations, except as needed for the purpose of

-   developing Internet standards in which case the procedures for

-   copyrights defined in the Internet Standards process must be

-   followed, or as required to translate it into languages other than

-   English.

-

-   The limited permissions granted above are perpetual and will not be

-   revoked by the Internet Society or its successors or assigns.

-

-   This document and the information contained herein is provided on an

-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING

-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING

-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION

-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF

-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

-

-Acknowledgement

-

-   Funding for the RFC Editor function is currently provided by the

-   Internet Society.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-IAB                          Informational                      [Page 7]

-

diff --git a/contrib/bind9/doc/rfc/rfc2826.txt b/contrib/bind9/doc/rfc/rfc2826.txt
deleted file mode 100644
index b4d8869..0000000
--- a/contrib/bind9/doc/rfc/rfc2826.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-

-

-

-

-

-

-Network Working Group                        Internet Architecture Board

-Request for Comments: 2826                                      May 2000

-Category: Informational

-

-

-              IAB Technical Comment on the Unique DNS Root

-

-Status of this Memo

-

-   This memo provides information for the Internet community.  It does

-   not specify an Internet standard of any kind.  Distribution of this

-   memo is unlimited.

-

-Copyright Notice

-

-   Copyright (C) The Internet Society (2000).  All Rights Reserved.

-

-Summary

-

-   To remain a global network, the Internet requires the existence of a

-   globally unique public name space.  The DNS name space is a

-   hierarchical name space derived from a single, globally unique root.

-   This is a technical constraint inherent in the design of the DNS.

-   Therefore it is not technically feasible for there to be more than

-   one root in the public DNS.  That one root must be supported by a set

-   of coordinated root servers administered by a unique naming

-   authority.

-

-   Put simply, deploying multiple public DNS roots would raise a very

-   strong possibility that users of different ISPs who click on the same

-   link on a web page could end up at different destinations, against

-   the will of the web page designers.

-

-   This does not preclude private networks from operating their own

-   private name spaces, but if they wish to make use of names uniquely

-   defined for the global Internet, they have to fetch that information

-   from the global DNS naming hierarchy, and in particular from the

-   coordinated root servers of the global DNS naming hierarchy.

-

-1.  Detailed Explanation

-

-   There are several distinct reasons why the DNS requires a single root

-   in order to operate properly.

-

-1.1.  Maintenance of a Common Symbol Set

-

-   Effective communications between two parties requires two essential

-   preconditions:

-

-

-

-IAB                          Informational                      [Page 1]

-

-RFC 2826      IAB Technical Comment on the Unique DNS Root      May 2000

-

-

-   -  The existence of a common symbol set, and

-

-   -  The existence of a common semantic interpretation of these

-      symbols.

-

-   Failure to meet the first condition implies a failure to communicate

-   at all, while failure to meet the second implies that the meaning of

-   the communication is lost.

-

-   In the case of a public communications system this condition of a

-   common symbol set with a common semantic interpretation must be

-   further strengthened to that of a unique symbol set with a unique

-   semantic interpretation.  This condition of uniqueness allows any

-   party to initiate a communication that can be received and understood

-   by any other party.  Such a condition rules out the ability to define

-   a symbol within some bounded context.  In such a case, once the

-   communication moves out of the context of interpretation in which it

-   was defined, the meaning of the symbol becomes lost.

-

-   Within public digital communications networks such as the Internet

-   this requirement for a uniquely defined symbol set with a uniquely

-   defined meaning exists at many levels, commencing with the binary

-   encoding scheme, extending to packet headers and payload formats and

-   the protocol that an application uses to interact.  In each case a

-   variation of the symbol set or a difference of interpretation of the

-   symbols being used within the interaction causes a protocol failure,

-   and the communication fails.  The property of uniqueness allows a

-   symbol to be used unambiguously in any context, allowing the symbol

-   to be passed on, referred to, and reused, while still preserving the

-   meaning of the original use.

-

-   The DNS fulfills an essential role within the Internet protocol

-   environment, allowing network locations to be referred to using a

-   label other than a protocol address.  As with any other such symbol

-   set, DNS names are designed to be globally unique, that is, for any

-   one DNS name at any one time there must be a single set of DNS

-   records uniquely describing protocol addresses, network resources and

-   services associated with that DNS name.  All of the applications

-   deployed on the Internet which use the DNS assume this, and Internet

-   users expect such behavior from DNS names.  Names are then constant

-   symbols, whose interpretation does not specifically require knowledge

-   of the context of any individual party.  A DNS name can be passed

-   from one party to another without altering the semantic intent of the

-   name.

-

-   Since the DNS is hierarchically structured into domains, the

-   uniqueness requirement for DNS names in their entirety implies that

-   each of the names (sub-domains) defined within a domain has a unique

-

-

-

-IAB                          Informational                      [Page 2]

-

-RFC 2826      IAB Technical Comment on the Unique DNS Root      May 2000

-

-

-   meaning (i.e., set of DNS records) within that domain.  This is as

-   true for the root domain as for any other DNS domain.  The

-   requirement for uniqueness within a domain further implies that there

-   be some mechanism to prevent name conflicts within a domain.  In DNS

-   this is accomplished by assigning a single owner or maintainer to

-   every domain, including the root domain, who is responsible for

-   ensuring that each sub-domain of that domain has the proper records

-   associated with it.  This is a technical requirement, not a policy

-   choice.

-

-1.2.  Coordination of Updates

-

-   Both the design and implementations of the DNS protocol are heavily

-   based on the assumption that there is a single owner or maintainer

-   for every domain, and that any set of resources records associated

-   with a domain is modified in a single-copy serializable fashion.

-   That is, even assuming that a single domain could somehow be "shared"

-   by uncooperating parties, there is no means within the DNS protocol

-   by which a user or client could discover, and choose between,

-   conflicting definitions of a DNS name made by different parties.  The

-   client will simply return the first set of resource records that it

-   finds that matches the requested domain, and assume that these are

-   valid.  This protocol is embedded in the operating software of

-   hundreds of millions of computer systems, and is not easily updated

-   to support a shared domain scenario.

-

-   Moreover, even supposing that some other means of resolving

-   conflicting definitions could be provided in the future, it would

-   have to be based on objective rules established in advance.  For

-   example, zone A.B could declare that naming authority Y had been

-   delegated all subdomains of A.B with an odd number of characters, and

-   that naming authority Z had been delegated authority to define

-   subdomains of A.B with an even number of characters.  Thus, a single

-   set of rules would have to be agreed to prevent Y and Z from making

-   conflicting assignments, and with this train of actions a single

-   unique space has been created in any case.  Even this would not allow

-   multiple non-cooperating authorities to assign arbitrary sub-domains

-   within a single domain.

-

-   It seems that a degree of cooperation and agreed technical rules are

-   required in order to guarantee the uniqueness of names.  In the DNS,

-   these rules are established independently for each part of the naming

-   hierarchy, and the root domain is no exception.  Thus, there must be

-   a generally agreed single set of rules for the root.

-

-

-

-

-

-

-

-IAB                          Informational                      [Page 3]

-

-RFC 2826      IAB Technical Comment on the Unique DNS Root      May 2000

-

-

-1.3.  Difficulty of Relocating the Root Zone

-

-   There is one specific technical respect in which the root zone

-   differs from all other DNS zones: the addresses of the name servers

-   for the root zone come primarily from out-of-band information.  This

-   out-of-band information is often poorly maintained and, unlike all

-   other data in the DNS, the out-of-band information has no automatic

-   timeout mechanism.  It is not uncommon for this information to be

-   years out of date at many sites.

-

-   Like any other zone, the root zone contains a set of "name server"

-   resource records listing its servers, but a resolver with no valid

-   addresses for the current set of root servers will never be able to

-   obtain these records.  More insidiously, a resolver that has a mixed

-   set of partially valid and partially stale out-of-band configuration

-   information will not be able to tell which are the "real" root

-   servers if it gets back conflicting answers; thus, it is very

-   difficult to revoke the status of a malicious root server, or even to

-   route around a buggy root server.

-

-   In effect, every full-service resolver in the world "delegates" the

-   root of the public tree to the public root server(s) of its choice.

-

-   As a direct consequence, any change to the list of IP addresses that

-   specify the public root zone is significantly more difficult than

-   changing any other aspect of the DNS delegation chain.   Thus,

-   stability of the system calls for extremely conservative and cautious

-   management of the public root zone: the frequency of updates to the

-   root zone must be kept low, and the servers for the root zone must be

-   closely coordinated.

-

-   These problems can be ameliorated to some extent by the DNS Security

-   Extensions [DNSSEC], but a similar out-of-band configuration problem

-   exists for the cryptographic signature key to the root zone, so the

-   root zone still requires tight coupling and coordinated management

-   even in the presence of DNSSEC.

-

-2.  Conclusion

-

-   The DNS type of unique naming and name-mapping system may not be

-   ideal for a number of purposes for which it was never designed, such

-   a locating information when the user doesn't precisely know the

-   correct names.  As the Internet continues to expand, we would expect

-   directory systems to evolve which can assist the user in dealing with

-   vague or ambiguous references.  To preserve the many important

-   features of the DNS and its multiple record types -- including the

-   Internet's equivalent of telephone number portability -- we would

-   expect the result of directory lookups and identification of the

-

-

-

-IAB                          Informational                      [Page 4]

-

-RFC 2826      IAB Technical Comment on the Unique DNS Root      May 2000

-

-

-   correct names for a particular purpose to be unique DNS names that

-   are then resolved normally, rather than having directory systems

-   "replace" the DNS.

-

-   There is no getting away from the unique root of the public DNS.

-

-3.  Security Considerations

-

-   This memo does not introduce any new security issues, but it does

-   attempt to identify some of the problems inherent in a family of

-   recurring technically naive proposals.

-

-4.  IANA Considerations

-

-   This memo is not intended to create any new issues for IANA.

-

-5.  References

-

-   [DNS-CONCEPTS]        Mockapetris, P., "Domain Names - Concepts and

-                         Facilities", STD 13, RFC 1034, November 1987.

-

-   [DNS-IMPLEMENTATION]  Mockapetris, P., "Domain Names - Implementation

-                         and Specification", STD 13, RFC 1035, November

-                         1987.

-

-   [DNSSEC]              Eastlake, D., "Domain Name System Security

-                         Extensions", RFC 2535, March 1999.

-

-6.  Author's Address

-

-   Internet Architecture Board

-

-   EMail: iab@iab.org

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-IAB                          Informational                      [Page 5]

-

-RFC 2826      IAB Technical Comment on the Unique DNS Root      May 2000

-

-

-7.  Full Copyright Statement

-

-   Copyright (C) The Internet Society (2000).  All Rights Reserved.

-

-   This document and translations of it may be copied and furnished to

-   others, and derivative works that comment on or otherwise explain it

-   or assist in its implementation may be prepared, copied, published

-   and distributed, in whole or in part, without restriction of any

-   kind, provided that the above copyright notice and this paragraph are

-   included on all such copies and derivative works.  However, this

-   document itself may not be modified in any way, such as by removing

-   the copyright notice or references to the Internet Society or other

-   Internet organizations, except as needed for the purpose of

-   developing Internet standards in which case the procedures for

-   copyrights defined in the Internet Standards process must be

-   followed, or as required to translate it into languages other than

-   English.

-

-   The limited permissions granted above are perpetual and will not be

-   revoked by the Internet Society or its successors or assigns.

-

-   This document and the information contained herein is provided on an

-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING

-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING

-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION

-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF

-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

-

-Acknowledgement

-

-   Funding for the RFC Editor function is currently provided by the

-   Internet Society.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-IAB                          Informational                      [Page 6]

-

diff --git a/contrib/bind9/doc/rfc/rfc2845.txt b/contrib/bind9/doc/rfc/rfc2845.txt
deleted file mode 100644
index aa9f385..0000000
--- a/contrib/bind9/doc/rfc/rfc2845.txt
+++ /dev/null
@@ -1,843 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                             P. Vixie
-Request for Comments: 2845                                             ISC
-Category: Standards Track                                   O. Gudmundsson
-Updates: 1035                                                     NAI Labs
-                                                           D. Eastlake 3rd
-                                                                  Motorola
-                                                             B. Wellington
-                                                                   Nominum
-                                                                  May 2000
-
-
-          Secret Key Transaction Authentication for DNS (TSIG)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-Abstract
-
-   This protocol allows for transaction level authentication using
-   shared secrets and one way hashing.  It can be used to authenticate
-   dynamic updates as coming from an approved client, or to authenticate
-   responses as coming from an approved recursive name server.
-
-   No provision has been made here for distributing the shared secrets;
-   it is expected that a network administrator will statically configure
-   name servers and clients using some out of band mechanism such as
-   sneaker-net until a secure automated mechanism for key distribution
-   is available.
-
-1 - Introduction
-
-   1.1. The Domain Name System (DNS) [RFC1034, RFC1035] is a replicated
-   hierarchical distributed database system that provides information
-   fundamental to Internet operations, such as name <=> address
-   translation and mail handling information.  DNS has recently been
-   extended [RFC2535] to provide for data origin authentication, and
-   public key distribution, all based on public key cryptography and
-   public key based digital signatures.  To be practical, this form of
-
-
-
-
-Vixie, et al.               Standards Track                     [Page 1]
-
-RFC 2845                        DNS TSIG                        May 2000
-
-
-   security generally requires extensive local caching of keys and
-   tracing of authentication through multiple keys and signatures to a
-   pre-trusted locally configured key.
-
-   1.2. One difficulty with the [RFC2535] scheme is that common DNS
-   implementations include simple "stub" resolvers which do not have
-   caches.  Such resolvers typically rely on a caching DNS server on
-   another host.  It is impractical for these stub resolvers to perform
-   general [RFC2535] authentication and they would naturally depend on
-   their caching DNS server to perform such services for them.  To do so
-   securely requires secure communication of queries and responses.
-   [RFC2535] provides public key transaction signatures to support this,
-   but such signatures are very expensive computationally to generate.
-   In general, these require the same complex public key logic that is
-   impractical for stubs.  This document specifies use of a message
-   authentication code (MAC), specifically HMAC-MD5 (a keyed hash
-   function), to provide an efficient means of point-to-point
-   authentication and integrity checking for transactions.
-
-   1.3. A second area where use of straight [RFC2535] public key based
-   mechanisms may be impractical is authenticating dynamic update
-   [RFC2136] requests.  [RFC2535] provides for request signatures but
-   with [RFC2535] they, like transaction signatures, require
-   computationally expensive public key cryptography and complex
-   authentication logic.  Secure Domain Name System Dynamic Update
-   ([RFC2137]) describes how different keys are used in dynamically
-   updated zones.  This document's secret key based MACs can be used to
-   authenticate DNS update requests as well as transaction responses,
-   providing a lightweight alternative to the protocol described by
-   [RFC2137].
-
-   1.4. A further use of this mechanism is to protect zone transfers.
-   In this case the data covered would be the whole zone transfer
-   including any glue records sent.  The protocol described by [RFC2535]
-   does not protect glue records and unsigned records unless SIG(0)
-   (transaction signature) is used.
-
-   1.5. The authentication mechanism proposed in this document uses
-   shared secret keys to establish a trust relationship between two
-   entities.  Such keys must be protected in a fashion similar to
-   private keys, lest a third party masquerade as one of the intended
-   parties (forge MACs).  There is an urgent need to provide simple and
-   efficient authentication between clients and local servers and this
-   proposal addresses that need.  This proposal is unsuitable for
-   general server to server authentication for servers which speak with
-   many other servers, since key management would become unwieldy with
-
-
-
-
-
-Vixie, et al.               Standards Track                     [Page 2]
-
-RFC 2845                        DNS TSIG                        May 2000
-
-
-   the number of shared keys going up quadratically.  But it is suitable
-   for many resolvers on hosts that only talk to a few recursive
-   servers.
-
-   1.6. A server acting as an indirect caching resolver -- a "forwarder"
-   in common usage -- might use transaction-based authentication when
-   communicating with its small number of preconfigured "upstream"
-   servers.  Other uses of DNS secret key authentication and possible
-   systems for automatic secret key distribution may be proposed in
-   separate future documents.
-
-   1.7. New Assigned Numbers
-
-      RRTYPE = TSIG (250)
-      ERROR = 0..15 (a DNS RCODE)
-      ERROR = 16 (BADSIG)
-      ERROR = 17 (BADKEY)
-      ERROR = 18 (BADTIME)
-
-   1.8. The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED",  and
-   "MAY" in this document are to be interpreted as described in [RFC
-   2119].
-
-2 - TSIG RR Format
-
-   2.1 TSIG RR Type
-
-   To provide secret key authentication, we use a new RR type whose
-   mnemonic is TSIG and whose type code is 250.  TSIG is a meta-RR and
-   MUST not be cached.  TSIG RRs are used for authentication between DNS
-   entities that have established a shared secret key.  TSIG RRs are
-   dynamically computed to cover a particular DNS transaction and are
-   not DNS RRs in the usual sense.
-
-   2.2 TSIG Calculation
-
-   As the TSIG RRs are related to one DNS request/response, there is no
-   value in storing or retransmitting them, thus the TSIG RR is
-   discarded once it has been used to authenticate a DNS message.  The
-   only message digest algorithm specified in this document is "HMAC-
-   MD5" (see [RFC1321], [RFC2104]).  The "HMAC-MD5" algorithm is
-   mandatory to implement for interoperability.  Other algorithms can be
-   specified at a later date.  Names and definitions of new algorithms
-   MUST be registered with IANA.  All multi-octet integers in the TSIG
-   record are sent in network byte order (see [RFC1035 2.3.2]).
-
-
-
-
-
-
-Vixie, et al.               Standards Track                     [Page 3]
-
-RFC 2845                        DNS TSIG                        May 2000
-
-
-   2.3. Record Format
-
-    NAME The name of the key used in domain name syntax.  The name
-         should reflect the names of the hosts and uniquely identify
-         the key among a set of keys these two hosts may share at any
-         given time.  If hosts A.site.example and B.example.net share a
-         key, possibilities for the key name include
-         <id>.A.site.example, <id>.B.example.net, and
-         <id>.A.site.example.B.example.net.  It should be possible for
-         more than one key to be in simultaneous use among a set of
-         interacting hosts.  The name only needs to be meaningful to
-         the communicating hosts but a meaningful mnemonic name as
-         above is strongly recommended.
-
-         The name may be used as a local index to the key involved and
-         it is recommended that it be globally unique.  Where a key is
-         just shared between two hosts, its name actually only need
-         only be meaningful to them but it is recommended that the key
-         name be mnemonic and incorporate the resolver and server host
-         names in that order.
-
-    TYPE TSIG (250: Transaction SIGnature)
-
-    CLASS ANY
-
-    TTL  0
-
-    RdLen (variable)
-
-    RDATA
-
-      Field Name       Data Type      Notes
-      --------------------------------------------------------------
-      Algorithm Name   domain-name    Name of the algorithm
-                                      in domain name syntax.
-      Time Signed      u_int48_t      seconds since 1-Jan-70 UTC.
-      Fudge            u_int16_t      seconds of error permitted
-                                      in Time Signed.
-      MAC Size         u_int16_t      number of octets in MAC.
-      MAC              octet stream   defined by Algorithm Name.
-      Original ID      u_int16_t      original message ID
-      Error            u_int16_t      expanded RCODE covering
-                                      TSIG processing.
-      Other Len        u_int16_t      length, in octets, of
-                                      Other Data.
-      Other Data       octet stream   empty unless Error == BADTIME
-
-
-
-
-
-Vixie, et al.               Standards Track                     [Page 4]
-
-RFC 2845                        DNS TSIG                        May 2000
-
-
-   2.4. Example
-
-      NAME   HOST.EXAMPLE.
-
-      TYPE   TSIG
-
-      CLASS  ANY
-
-      TTL    0
-
-      RdLen  as appropriate
-
-      RDATA
-
-         Field Name       Contents
-         -------------------------------------
-         Algorithm Name   SAMPLE-ALG.EXAMPLE.
-         Time Signed      853804800
-         Fudge            300
-         MAC Size         as appropriate
-         MAC              as appropriate
-         Original ID      as appropriate
-         Error            0 (NOERROR)
-         Other Len        0
-         Other Data       empty
-
-3 - Protocol Operation
-
-   3.1. Effects of adding TSIG to outgoing message
-
-   Once the outgoing message has been constructed, the keyed message
-   digest operation can be performed.  The resulting message digest will
-   then be stored in a TSIG which is appended to the additional data
-   section (the ARCOUNT is incremented to reflect this).  If the TSIG
-   record cannot be added without causing the message to be truncated,
-   the server MUST alter the response so that a TSIG can be included.
-   This response consists of only the question and a TSIG record, and
-   has the TC bit set and RCODE 0 (NOERROR).  The client SHOULD at this
-   point retry the request using TCP (per [RFC1035 4.2.2]).
-
-   3.2. TSIG processing on incoming messages
-
-   If an incoming message contains a TSIG record, it MUST be the last
-   record in the additional section.  Multiple TSIG records are not
-   allowed.  If a TSIG record is present in any other position, the
-   packet is dropped and a response with RCODE 1 (FORMERR) MUST be
-   returned.  Upon receipt of a message with a correctly placed TSIG RR,
-   the TSIG RR is copied to a safe location, removed from the DNS
-
-
-
-Vixie, et al.               Standards Track                     [Page 5]
-
-RFC 2845                        DNS TSIG                        May 2000
-
-
-   Message, and decremented out of the DNS message header's ARCOUNT.  At
-   this point the keyed message digest operation is performed.  If the
-   algorithm name or key name is unknown to the recipient, or if the
-   message digests do not match, the whole DNS message MUST be
-   discarded.  If the message is a query, a response with RCODE 9
-   (NOTAUTH) MUST be sent back to the originator with TSIG ERROR 17
-   (BADKEY) or TSIG ERROR 16 (BADSIG).  If no key is available to sign
-   this message it MUST be sent unsigned (MAC size == 0 and empty MAC).
-   A message to the system operations log SHOULD be generated, to warn
-   the operations staff of a possible security incident in progress.
-   Care should be taken to ensure that logging of this type of event
-   does not open the system to a denial of service attack.
-
-   3.3. Time values used in TSIG calculations
-
-   The data digested includes the two timer values in the TSIG header in
-   order to defend against replay attacks.  If this were not done, an
-   attacker could replay old messages but update the "Time Signed" and
-   "Fudge" fields to make the message look new.  This data is named
-   "TSIG Timers", and for the purpose of digest calculation they are
-   invoked in their "on the wire" format, in the following order: first
-   Time Signed, then Fudge.  For example:
-
-Field Name    Value       Wire Format         Meaning
-----------------------------------------------------------------------
-Time Signed   853804800   00 00 32 e4 07 00   Tue Jan 21 00:00:00 1997
-Fudge         300         01 2C               5 minutes
-
-   3.4. TSIG Variables and Coverage
-
-   When generating or verifying the contents of a TSIG record, the
-   following data are digested, in network byte order or wire format, as
-   appropriate:
-
-   3.4.1. DNS Message
-
-   A whole and complete DNS message in wire format, before the TSIG RR
-   has been added to the additional data section and before the DNS
-   Message Header's ARCOUNT field has been incremented to contain the
-   TSIG RR.  If the message ID differs from the original message ID, the
-   original message ID is substituted for the message ID.  This could
-   happen when forwarding a dynamic update request, for example.
-
-
-
-
-
-
-
-
-
-Vixie, et al.               Standards Track                     [Page 6]
-
-RFC 2845                        DNS TSIG                        May 2000
-
-
-   3.4.2. TSIG Variables
-
-Source       Field Name       Notes
------------------------------------------------------------------------
-TSIG RR      NAME             Key name, in canonical wire format
-TSIG RR      CLASS            (Always ANY in the current specification)
-TSIG RR      TTL              (Always 0 in the current specification)
-TSIG RDATA   Algorithm Name   in canonical wire format
-TSIG RDATA   Time Signed      in network byte order
-TSIG RDATA   Fudge            in network byte order
-TSIG RDATA   Error            in network byte order
-TSIG RDATA   Other Len        in network byte order
-TSIG RDATA   Other Data       exactly as transmitted
-
-   The RR RDLEN and RDATA MAC Length are not included in the hash since
-   they are not guaranteed to be knowable before the MAC is generated.
-
-   The Original ID field is not included in this section, as it has
-   already been substituted for the message ID in the DNS header and
-   hashed.
-
-   For each label type, there must be a defined "Canonical wire format"
-   that specifies how to express a label in an unambiguous way.  For
-   label type 00, this is defined in [RFC2535], for label type 01, this
-   is defined in [RFC2673].  The use of label types other than 00 and 01
-   is not defined for this specification.
-
-   3.4.3. Request MAC
-
-   When generating the MAC to be included in a response, the request MAC
-   must be included in the digest.  The request's MAC is digested in
-   wire format, including the following fields:
-
-   Field        Type           Description
-   ---------------------------------------------------
-   MAC Length   u_int16_t      in network byte order
-   MAC Data     octet stream   exactly as transmitted
-
-   3.5. Padding
-
-   Digested components are fed into the hashing function as a continuous
-   octet stream with no interfield padding.
-
-
-
-
-
-
-
-
-
-Vixie, et al.               Standards Track                     [Page 7]
-
-RFC 2845                        DNS TSIG                        May 2000
-
-
-4 - Protocol Details
-
-   4.1. TSIG generation on requests
-
-   Client performs the message digest operation and appends a TSIG
-   record to the additional data section and transmits the request to
-   the server.  The client MUST store the message digest from the
-   request while awaiting an answer.  The digest components for a
-   request are:
-
-      DNS Message (request)
-      TSIG Variables (request)
-
-   Note that some older name servers will not accept requests with a
-   nonempty additional data section.  Clients SHOULD only attempt signed
-   transactions with servers who are known to support TSIG and share
-   some secret key with the client -- so, this is not a problem in
-   practice.
-
-   4.2. TSIG on Answers
-
-   When a server has generated a response to a signed request, it signs
-   the response using the same algorithm and key.  The server MUST not
-   generate a signed response to an unsigned request.  The digest
-   components are:
-
-      Request MAC
-      DNS Message (response)
-      TSIG Variables (response)
-
-   4.3. TSIG on TSIG Error returns
-
-   When a server detects an error relating to the key or MAC, the server
-   SHOULD send back an unsigned error message (MAC size == 0 and empty
-   MAC).  If an error is detected relating to the TSIG validity period,
-   the server SHOULD send back a signed error message.  The digest
-   components are:
-
-      Request MAC (if the request MAC validated)
-      DNS Message (response)
-      TSIG Variables (response)
-
-   The reason that the request is not included in this digest in some
-   cases is to make it possible for the client to verify the error.  If
-   the error is not a TSIG error the response MUST be generated as
-   specified in [4.2].
-
-
-
-
-
-Vixie, et al.               Standards Track                     [Page 8]
-
-RFC 2845                        DNS TSIG                        May 2000
-
-
-   4.4. TSIG on TCP connection
-
-   A DNS TCP session can include multiple DNS envelopes.  This is, for
-   example, commonly used by zone transfer.  Using TSIG on such a
-   connection can protect the connection from hijacking and provide data
-   integrity.  The TSIG MUST be included on the first and last DNS
-   envelopes.  It can be optionally placed on any intermediary
-   envelopes.  It is expensive to include it on every envelopes, but it
-   MUST be placed on at least every 100'th envelope.  The first envelope
-   is processed as a standard answer, and subsequent messages have the
-   following digest components:
-
-      Prior Digest (running)
-      DNS Messages (any unsigned messages since the last TSIG)
-      TSIG Timers (current message)
-
-   This allows the client to rapidly detect when the session has been
-   altered; at which point it can close the connection and retry.  If a
-   client TSIG verification fails, the client MUST close the connection.
-   If the client does not receive TSIG records frequently enough (as
-   specified above) it SHOULD assume the connection has been hijacked
-   and it SHOULD close the connection.  The client SHOULD treat this the
-   same way as they would any other interrupted transfer (although the
-   exact behavior is not specified).
-
-   4.5. Server TSIG checks
-
-   Upon receipt of a message, server will check if there is a TSIG RR.
-   If one exists, the server is REQUIRED to return a TSIG RR in the
-   response.  The server MUST perform the following checks in the
-   following order, check KEY, check TIME values, check MAC.
-
-   4.5.1. KEY check and error handling
-
-   If a non-forwarding server does not recognize the key used by the
-   client, the server MUST generate an error response with RCODE 9
-   (NOTAUTH) and TSIG ERROR 17 (BADKEY).  This response MUST be unsigned
-   as specified in [4.3].  The server SHOULD log the error.
-
-   4.5.2. TIME check and error handling
-
-   If the server time is outside the time interval specified by the
-   request (which is: Time Signed, plus/minus Fudge), the server MUST
-   generate an error response with RCODE 9 (NOTAUTH) and TSIG ERROR 18
-   (BADTIME).  The server SHOULD also cache the most recent time signed
-   value in a message generated by a key, and SHOULD return BADTIME if a
-   message received later has an earlier time signed value.  A response
-   indicating a BADTIME error MUST be signed by the same key as the
-
-
-
-Vixie, et al.               Standards Track                     [Page 9]
-
-RFC 2845                        DNS TSIG                        May 2000
-
-
-   request.  It MUST include the client's current time in the time
-   signed field, the server's current time (a u_int48_t) in the other
-   data field, and 6 in the other data length field.  This is done so
-   that the client can verify a message with a BADTIME error without the
-   verification failing due to another BADTIME error.  The data signed
-   is specified in [4.3].  The server SHOULD log the error.
-
-   4.5.3. MAC check and error handling
-
-   If a TSIG fails to verify, the server MUST generate an error response
-   as specified in [4.3] with RCODE 9 (NOTAUTH) and TSIG ERROR 16
-   (BADSIG).  This response MUST be unsigned as specified in [4.3].  The
-   server SHOULD log the error.
-
-   4.6. Client processing of answer
-
-   When a client receives a response from a server and expects to see a
-   TSIG, it first checks if the TSIG RR is present in the response.
-   Otherwise, the response is treated as having a format error and
-   discarded.  The client then extracts the TSIG, adjusts the ARCOUNT,
-   and calculates the keyed digest in the same way as the server.  If
-   the TSIG does not validate, that response MUST be discarded, unless
-   the RCODE is 9 (NOTAUTH), in which case the client SHOULD attempt to
-   verify the response as if it were a TSIG Error response, as specified
-   in [4.3].  A message containing an unsigned TSIG record or a TSIG
-   record which fails verification SHOULD not be considered an
-   acceptable response; the client SHOULD log an error and continue to
-   wait for a signed response until the request times out.
-
-   4.6.1. Key error handling
-
-   If an RCODE on a response is 9 (NOTAUTH), and the response TSIG
-   validates, and the TSIG key is different from the key used on the
-   request, then this is a KEY error.  The client MAY retry the request
-   using the key specified by the server.  This should never occur, as a
-   server MUST NOT sign a response with a different key than signed the
-   request.
-
-   4.6.2. Time error handling
-
-   If the response RCODE is 9 (NOTAUTH) and the TSIG ERROR is 18
-   (BADTIME), or the current time does not fall in the range specified
-   in the TSIG record, then this is a TIME error.  This is an indication
-   that the client and server clocks are not synchronized.  In this case
-   the client SHOULD log the event.  DNS resolvers MUST NOT adjust any
-   clocks in the client based on BADTIME errors, but the server's time
-   in the other data field SHOULD be logged.
-
-
-
-
-Vixie, et al.               Standards Track                    [Page 10]
-
-RFC 2845                        DNS TSIG                        May 2000
-
-
-   4.6.3. MAC error handling
-
-   If the response RCODE is 9 (NOTAUTH) and TSIG ERROR is 16 (BADSIG),
-   this is a MAC error, and client MAY retry the request with a new
-   request ID but it would be better to try a different shared key if
-   one is available.  Client SHOULD keep track of how many MAC errors
-   are associated with each key.  Clients SHOULD log this event.
-
-   4.7. Special considerations for forwarding servers
-
-   A server acting as a forwarding server of a DNS message SHOULD check
-   for the existence of a TSIG record.  If the name on the TSIG is not
-   of a secret that the server shares with the originator the server
-   MUST forward the message unchanged including the TSIG.  If the name
-   of the TSIG is of a key this server shares with the originator, it
-   MUST process the TSIG.  If the TSIG passes all checks, the forwarding
-   server MUST, if possible, include a TSIG of his own, to the
-   destination or the next forwarder.  If no transaction security is
-   available to the destination and the response has the AD flag (see
-   [RFC2535]), the forwarder MUST unset the AD flag before adding the
-   TSIG to the answer.
-
-5 - Shared Secrets
-
-   5.1. Secret keys are very sensitive information and all available
-   steps should be taken to protect them on every host on which they are
-   stored.  Generally such hosts need to be physically protected.  If
-   they are multi-user machines, great care should be taken that
-   unprivileged users have no access to keying material.  Resolvers
-   often run unprivileged, which means all users of a host would be able
-   to see whatever configuration data is used by the resolver.
-
-   5.2. A name server usually runs privileged, which means its
-   configuration data need not be visible to all users of the host.  For
-   this reason, a host that implements transaction-based authentication
-   should probably be configured with a "stub resolver" and a local
-   caching and forwarding name server.  This presents a special problem
-   for [RFC2136] which otherwise depends on clients to communicate only
-   with a zone's authoritative name servers.
-
-   5.3. Use of strong random shared secrets is essential to the security
-   of TSIG.  See [RFC1750] for a discussion of this issue.  The secret
-   should be at least as long as the keyed message digest, i.e. 16 bytes
-   for HMAC-MD5 or 20 bytes for HMAC-SHA1.
-
-
-
-
-
-
-
-Vixie, et al.               Standards Track                    [Page 11]
-
-RFC 2845                        DNS TSIG                        May 2000
-
-
-6 - Security Considerations
-
-   6.1. The approach specified here is computationally much less
-   expensive than the signatures specified in [RFC2535].  As long as the
-   shared secret key is not compromised, strong authentication is
-   provided for the last hop from a local name server to the user
-   resolver.
-
-   6.2. Secret keys should be changed periodically.  If the client host
-   has been compromised, the server should suspend the use of all
-   secrets known to that client.  If possible, secrets should be stored
-   in encrypted form.  Secrets should never be transmitted in the clear
-   over any network.  This document does not address the issue on how to
-   distribute secrets. Secrets should never be shared by more than two
-   entities.
-
-   6.3. This mechanism does not authenticate source data, only its
-   transmission between two parties who share some secret.  The original
-   source data can come from a compromised zone master or can be
-   corrupted during transit from an authentic zone master to some
-   "caching forwarder."  However, if the server is faithfully performing
-   the full [RFC2535] security checks, then only security checked data
-   will be available to the client.
-
-   6.4. A fudge value that is too large may leave the server open to
-   replay attacks.  A fudge value that is too small may cause failures
-   if machines are not time synchronized or there are unexpected network
-   delays.  The recommended value in most situation is 300 seconds.
-
-7 - IANA Considerations
-
-   IANA is expected to create and maintain a registry of algorithm names
-   to be used as "Algorithm Names" as defined in Section 2.3.  The
-   initial value should be "HMAC-MD5.SIG-ALG.REG.INT".  Algorithm names
-   are text strings encoded using the syntax of a domain name.  There is
-   no structure required other than names for different algorithms must
-   be unique when compared as DNS names, i.e., comparison is case
-   insensitive.  Note that the initial value mentioned above is not a
-   domain name, and therefore need not be a registered name within the
-   DNS.  New algorithms are assigned using the IETF Consensus policy
-   defined in RFC 2434. The algorithm name HMAC-MD5.SIG-ALG.REG.INT
-   looks like a FQDN for historical reasons; future algorithm names are
-   expected to be simple (i.e., single-component) names.
-
-
-
-
-
-
-
-
-Vixie, et al.               Standards Track                    [Page 12]
-
-RFC 2845                        DNS TSIG                        May 2000
-
-
-   IANA is expected to create and maintain a registry of "TSIG Error
-   values" to be used for "Error" values as defined in section 2.3.
-   Initial values should be those defined in section 1.7.  New TSIG
-   error codes for the TSIG error field are assigned using the IETF
-   Consensus policy defined in RFC 2434.
-
-8 - References
-
-   [RFC1034]  Mockapetris, P., "Domain Names - Concepts and Facilities",
-              STD 13, RFC 1034, November 1987.
-
-   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
-              Specification", STD 13, RFC 1034, November 1987.
-
-   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
-              April 1992.
-
-   [RFC1750]  Eastlake, D., Crocker, S. and J. Schiller, "Randomness
-              Recommendations for Security", RFC 1750, December 1995.
-
-   [RFC2104]  Krawczyk, H., Bellare, M. and R. Canetti, "HMAC-MD5:
-              Keyed-MD5 for Message Authentication", RFC 2104, February
-              1997.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y. and J. Bound "Dynamic
-              Updates in the Domain Name System", RFC 2136, April 1997.
-
-   [RFC2137]  Eastlake 3rd, D., "Secure Domain Name System Dynamic
-              Update", RFC 2137, April 1997.
-
-   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
-              RFC 2535, March 1999.
-
-   [RFC2673]  Crawford, M., "Binary Labels in the Domain Name System",
-              RFC 2673, August 1999.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Vixie, et al.               Standards Track                    [Page 13]
-
-RFC 2845                        DNS TSIG                        May 2000
-
-
-9 - Authors' Addresses
-
-   Paul Vixie
-   Internet Software Consortium
-   950 Charter Street
-   Redwood City, CA 94063
-
-   Phone: +1 650 779 7001
-   EMail: vixie@isc.org
-
-
-   Olafur Gudmundsson
-   NAI Labs
-   3060 Washington Road, Route 97
-   Glenwood, MD 21738
-
-   Phone: +1 443 259 2389
-   EMail: ogud@tislabs.com
-
-
-   Donald E. Eastlake 3rd
-   Motorola
-   140 Forest Avenue
-   Hudson, MA 01749 USA
-
-   Phone: +1 508 261 5434
-   EMail: dee3@torque.pothole.com
-
-
-   Brian Wellington
-   Nominum, Inc.
-   950 Charter Street
-   Redwood City, CA 94063
-
-   Phone: +1 650 779 6022
-   EMail: Brian.Wellington@nominum.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Vixie, et al.               Standards Track                    [Page 14]
-
-RFC 2845                        DNS TSIG                        May 2000
-
-
-10  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Vixie, et al.               Standards Track                    [Page 15]
-
diff --git a/contrib/bind9/doc/rfc/rfc2874.txt b/contrib/bind9/doc/rfc/rfc2874.txt
deleted file mode 100644
index 915c104..0000000
--- a/contrib/bind9/doc/rfc/rfc2874.txt
+++ /dev/null
@@ -1,1123 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        M. Crawford
-Request for Comments: 2874                                      Fermilab
-Category: Standards Track                                     C. Huitema
-                                                   Microsoft Corporation
-                                                               July 2000
-
-
-   DNS Extensions to Support IPv6 Address Aggregation and Renumbering
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-Abstract
-
-   This document defines changes to the Domain Name System to support
-   renumberable and aggregatable IPv6 addressing.  The changes include a
-   new resource record type to store an IPv6 address in a manner which
-   expedites network renumbering and updated definitions of existing
-   query types that return Internet addresses as part of additional
-   section processing.
-
-   For lookups keyed on IPv6 addresses (often called reverse lookups),
-   this document defines a new zone structure which allows a zone to be
-   used without modification for parallel copies of an address space (as
-   for a multihomed provider or site) and across network renumbering
-   events.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crawford, et al.            Standards Track                     [Page 1]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-Table of Contents
-
-   1.  Introduction ...............................................  2
-   2.  Overview ...................................................  3
-       2.1.  Name-to-Address Lookup ...............................  4
-       2.2.  Underlying Mechanisms for Reverse Lookups ............  4
-           2.2.1.  Delegation on Arbitrary Boundaries .............  4
-           2.2.2.  Reusable Zones .................................  5
-   3.  Specifications .............................................  5
-       3.1.  The A6 Record Type ...................................  5
-           3.1.1.  Format .........................................  6
-           3.1.2.  Processing .....................................  6
-           3.1.3.  Textual Representation .........................  7
-           3.1.4.  Name Resolution Procedure ......................  7
-       3.2.  Zone Structure for Reverse Lookups ...................  7
-   4.  Modifications to Existing Query Types ......................  8
-   5.  Usage Illustrations ........................................  8
-       5.1.  A6 Record Chains .....................................  9
-           5.1.1.  Authoritative Data .............................  9
-           5.1.2.  Glue ........................................... 10
-           5.1.3.  Variations ..................................... 12
-       5.2.  Reverse Mapping Zones ................................ 13
-           5.2.1.  The TLA level .................................. 13
-           5.2.2.  The ISP level .................................. 13
-           5.2.3.  The Site Level ................................. 13
-       5.3.  Lookups .............................................. 14
-       5.4.  Operational Note ..................................... 15
-   6.  Transition from RFC 1886 and Deployment Notes .............. 15
-       6.1.  Transition from AAAA and Coexistence with A Records .. 16
-       6.2.  Transition from Nibble Labels to Binary Labels ....... 17
-   7.  Security Considerations .................................... 17
-   8.  IANA Considerations ........................................ 17
-   9.  Acknowledgments ............................................ 18
-   10.  References ................................................ 18
-   11.  Authors' Addresses ........................................ 19
-   12.  Full Copyright Statement .................................. 20
-
-1.  Introduction
-
-   Maintenance of address information in the DNS is one of several
-   obstacles which have prevented site and provider renumbering from
-   being feasible in IP version 4.  Arguments about the importance of
-   network renumbering for the preservation of a stable routing system
-   and for other purposes may be read in [RENUM1, RENUM2, RENUM3].  To
-   support the storage of IPv6 addresses without impeding renumbering we
-   define the following extensions.
-
-
-
-
-
-Crawford, et al.            Standards Track                     [Page 2]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-   o  A new resource record type, "A6", is defined to map a domain name
-      to an IPv6 address, with a provision for indirection for leading
-      "prefix" bits.
-
-   o  Existing queries that perform additional section processing to
-      locate IPv4 addresses are redefined to do that processing for both
-      IPv4 and IPv6 addresses.
-
-   o  A new domain, IP6.ARPA, is defined to support lookups based on
-      IPv6 address.
-
-   o  A new prefix-delegation method is defined, relying on new DNS
-      features [BITLBL, DNAME].
-
-   The changes are designed to be compatible with existing application
-   programming interfaces.  The existing support for IPv4 addresses is
-   retained.  Transition issues related to the coexistence of both IPv4
-   and IPv6 addresses in DNS are discussed in [TRANS].
-
-   This memo proposes a replacement for the specification in RFC 1886
-   [AAAA] and a departure from current implementation practices.  The
-   changes are designed to facilitate network renumbering and
-   multihoming.  Domains employing the A6 record for IPv6 addresses can
-   insert automatically-generated AAAA records in zone files to ease
-   transition.  It is expected that after a reasonable period, RFC 1886
-   will become Historic.
-
-   The next three major sections of this document are an overview of the
-   facilities defined or employed by this specification, the
-   specification itself, and examples of use.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [KWORD].  The key word
-   "SUGGESTED" signifies a strength between MAY and SHOULD: it is
-   believed that compliance with the suggestion has tangible benefits in
-   most instances.
-
-2.  Overview
-
-   This section provides an overview of the DNS facilities for storage
-   of IPv6 addresses and for lookups based on IPv6 address, including
-   those defined here and elsewhere.
-
-
-
-
-
-
-
-
-Crawford, et al.            Standards Track                     [Page 3]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-2.1.  Name-to-Address Lookup
-
-   IPv6 addresses are stored in one or more A6 resource records.  A
-   single A6 record may include a complete IPv6 address, or a contiguous
-   portion of an address and information leading to one or more
-   prefixes.  Prefix information comprises a prefix length and a DNS
-   name which is in turn the owner of one or more A6 records defining
-   the prefix or prefixes which are needed to form one or more complete
-   IPv6 addresses.  When the prefix length is zero, no DNS name is
-   present and all the leading bits of the address are significant.
-   There may be multiple levels of indirection and the existence of
-   multiple A6 records at any level multiplies the number of IPv6
-   addresses which are formed.
-
-   An application looking up an IPv6 address will generally cause the
-   DNS resolver to access several A6 records, and multiple IPv6
-   addresses may be returned even if the queried name was the owner of
-   only one A6 record.  The authenticity of the returned address(es)
-   cannot be directly verified by DNS Security [DNSSEC].  The A6 records
-   which contributed to the address(es) may of course be verified if
-   signed.
-
-   Implementers are reminded of the necessity to limit the amount of
-   work a resolver will perform in response to a client request.  This
-   principle MUST be extended to also limit the generation of DNS
-   requests in response to one name-to-address (or address-to-name)
-   lookup request.
-
-2.2.  Underlying Mechanisms for Reverse Lookups
-
-   This section describes the new DNS features which this document
-   exploits.  This section is an overview, not a specification of those
-   features.  The reader is directed to the referenced documents for
-   more details on each.
-
-2.2.1.  Delegation on Arbitrary Boundaries
-
-   This new scheme for reverse lookups relies on a new type of DNS label
-   called the "bit-string label" [BITLBL].  This label compactly
-   represents an arbitrary string of bits which is treated as a
-   hierarchical sequence of one-bit domain labels.  Resource records can
-   thereby be stored at arbitrary bit-boundaries.
-
-   Examples in section 5 will employ the following textual
-   representation for bit-string labels, which is a subset of the syntax
-   defined in [BITLBL].  A base indicator "x" for hexadecimal and a
-   sequence of hexadecimal digits is enclosed between "\[" and "]".  The
-   bits denoted by the digits represent a sequence of one-bit domain
-
-
-
-Crawford, et al.            Standards Track                     [Page 4]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-   labels ordered from most to least significant.  (This is the opposite
-   of the order they would appear if listed one bit at a time, but it
-   appears to be a convenient notation.)  The digit string may be
-   followed by a slash ("/") and a decimal count.  If omitted, the
-   implicit count is equal to four times the number of hexadecimal
-   digits.
-
-   Consecutive bit-string labels are equivalent (up to the limit imposed
-   by the size of the bit count field) to a single bit-string label
-   containing all the bits of the consecutive labels in the proper
-   order.  As an example, either of the following domain names could be
-   used in a QCLASS=IN, QTYPE=PTR query to find the name of the node
-   with IPv6 address 3ffe:7c0:40:9:a00:20ff:fe81:2b32.
-
-    \[x3FFE07C0004000090A0020FFFE812B32/128].IP6.ARPA.
-
-    \[x0A0020FFFE812B32/64].\[x0009/16].\[x3FFE07C00040/48].IP6.ARPA.
-
-2.2.2.  Reusable Zones
-
-   DNS address space delegation is implemented not by zone cuts and NS
-   records, but by a new analogue to the CNAME record, called the DNAME
-   resource record [DNAME].  The DNAME record provides alternate naming
-   to an entire subtree of the domain name space, rather than to a
-   single node.  It causes some suffix of a queried name to be
-   substituted with a name from the DNAME record's RDATA.
-
-   For example, a resolver or server providing recursion, while looking
-   up a QNAME a.b.c.d.e.f may encounter a DNAME record
-
-                        d.e.f.     DNAME     w.xy.
-
-   which will cause it to look for a.b.c.w.xy.
-
-3.  Specifications
-
-3.1.  The A6 Record Type
-
-   The A6 record type is specific to the IN (Internet) class and has
-   type number 38 (decimal).
-
-
-
-
-
-
-
-
-
-
-
-Crawford, et al.            Standards Track                     [Page 5]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-3.1.1.  Format
-
-   The RDATA portion of the A6 record contains two or three fields.
-
-           +-----------+------------------+-------------------+
-           |Prefix len.|  Address suffix  |    Prefix name    |
-           | (1 octet) |  (0..16 octets)  |  (0..255 octets)  |
-           +-----------+------------------+-------------------+
-
-   o  A prefix length, encoded as an eight-bit unsigned integer with
-      value between 0 and 128 inclusive.
-
-   o  An IPv6 address suffix, encoded in network order (high-order octet
-      first).  There MUST be exactly enough octets in this field to
-      contain a number of bits equal to 128 minus prefix length, with 0
-      to 7 leading pad bits to make this field an integral number of
-      octets.  Pad bits, if present, MUST be set to zero when loading a
-      zone file and ignored (other than for SIG [DNSSEC] verification)
-      on reception.
-
-   o  The name of the prefix, encoded as a domain name.  By the rules of
-      [DNSIS], this name MUST NOT be compressed.
-
-   The domain name component SHALL NOT be present if the prefix length
-   is zero.  The address suffix component SHALL NOT be present if the
-   prefix length is 128.
-
-   It is SUGGESTED that an A6 record intended for use as a prefix for
-   other A6 records have all the insignificant trailing bits in its
-   address suffix field set to zero.
-
-3.1.2.  Processing
-
-   A query with QTYPE=A6 causes type A6 and type NS additional section
-   processing for the prefix names, if any, in the RDATA field of the A6
-   records in the answer section.  This processing SHOULD be recursively
-   applied to the prefix names of A6 records included as additional
-   data.  When space in the reply packet is a limit, inclusion of
-   additional A6 records takes priority over NS records.
-
-   It is an error for an A6 record with prefix length L1 > 0 to refer to
-   a domain name which owns an A6 record with a prefix length L2 > L1.
-   If such a situation is encountered by a resolver, the A6 record with
-   the offending (larger) prefix length MUST be ignored.  Robustness
-   precludes signaling an error if addresses can still be formed from
-   valid A6 records, but it is SUGGESTED that zone maintainers from time
-   to time check all the A6 records their zones reference.
-
-
-
-
-Crawford, et al.            Standards Track                     [Page 6]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-3.1.3.  Textual Representation
-
-   The textual representation of the RDATA portion of the A6 resource
-   record in a zone file comprises two or three fields separated by
-   whitespace.
-
-   o  A prefix length, represented as a decimal number between 0 and 128
-      inclusive,
-
-   o  the textual representation of an IPv6 address as defined in
-      [AARCH] (although some leading and/or trailing bits may not be
-      significant),
-
-   o  a domain name, if the prefix length is not zero.
-
-   The domain name MUST be absent if the prefix length is zero.  The
-   IPv6 address MAY be be absent if the prefix length is 128.  A number
-   of leading address bits equal to the prefix length SHOULD be zero,
-   either implicitly (through the :: notation) or explicitly, as
-   specified in section 3.1.1.
-
-3.1.4.  Name Resolution Procedure
-
-   To obtain the IPv6 address or addresses which belong to a given name,
-   a DNS client MUST obtain one or more complete chains of A6 records,
-   each chain beginning with a record owned by the given name and
-   including a record owned by the prefix name in that record, and so on
-   recursively, ending with an A6 record with a prefix length of zero.
-   One IPv6 address is formed from one such chain by taking the value of
-   each bit position from the earliest A6 record in the chain which
-   validly covers that position, as indicated by the prefix length.  The
-   set of all IPv6 addresses for the given name comprises the addresses
-   formed from all complete chains of A6 records beginning at that name,
-   discarding records which have invalid prefix lengths as defined in
-   section 3.1.2.
-
-   If some A6 queries fail and others succeed, a client might obtain a
-   non-empty but incomplete set of IPv6 addresses for a host.  In many
-   situations this may be acceptable.  The completeness of a set of A6
-   records may always be determined by inspection.
-
-3.2.  Zone Structure for Reverse Lookups
-
-   Very little of the new scheme's data actually appears under IP6.ARPA;
-   only the first level of delegation needs to be under that domain.
-   More levels of delegation could be placed under IP6.ARPA if some
-   top-level delegations were done via NS records instead of DNAME
-   records, but this would incur some cost in renumbering ease at the
-
-
-
-Crawford, et al.            Standards Track                     [Page 7]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-   level of TLAs [AGGR].  Therefore, it is declared here that all
-   address space delegations SHOULD be done by the DNAME mechanism
-   rather than NS.
-
-   In addition, since uniformity in deployment will simplify maintenance
-   of address delegations, it is SUGGESTED that address and prefix
-   information be stored immediately below a DNS label "IP6".  Stated
-   another way, conformance with this suggestion would mean that "IP6"
-   is the first label in the RDATA field of DNAME records which support
-   IPv6 reverse lookups.
-
-   When any "reserved" or "must be zero" bits are adjacent to a
-   delegation boundary, the higher-level entity MUST retain those bits
-   in its own control and delegate only the bits over which the lower-
-   level entity has authority.
-
-   To find the name of a node given its IPv6 address, a DNS client MUST
-   perform a query with QCLASS=IN, QTYPE=PTR on the name formed from the
-   128 bit address as one or more bit-string labels [BITLBL], followed
-   by the two standard labels "IP6.ARPA".  If recursive service was not
-   obtained from a server and the desired PTR record was not returned,
-   the resolver MUST handle returned DNAME records as specified in
-   [DNAME], and NS records as specified in [DNSCF], and iterate.
-
-4.  Modifications to Existing Query Types
-
-   All existing query types that perform type A additional section
-   processing, i.e. the name server (NS), mail exchange (MX), and
-   mailbox (MB) query types, and the experimental AFS data base (AFSDB)
-   and route through (RT) types, must be redefined to perform type A, A6
-   and AAAA additional section processing, with type A having the
-   highest priority for inclusion and type AAAA the lowest.  This
-   redefinition means that a name server may add any relevant IPv4 and
-   IPv6 address information available locally to the additional section
-   of a response when processing any one of the above queries.  The
-   recursive inclusion of A6 records referenced by A6 records already
-   included in the additional section is OPTIONAL.
-
-5.  Usage Illustrations
-
-   This section provides examples of use of the mechanisms defined in
-   the previous section.  All addresses and domains mentioned here are
-   intended to be fictitious and for illustrative purposes only.
-   Example delegations will be on 4-bit boundaries solely for
-   readability; this specification is indifferent to bit alignment.
-
-   Use of the IPv6 aggregatable address format [AGGR] is assumed in the
-   examples.
-
-
-
-Crawford, et al.            Standards Track                     [Page 8]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-5.1.  A6 Record Chains
-
-   Let's take the example of a site X that is multi-homed to two
-   "intermediate" providers A and B.  The provider A is itself multi-
-   homed to two "transit" providers, C and D.  The provider B gets its
-   transit service from a single provider, E.  For simplicity suppose
-   that C, D and E all belong to the same top-level aggregate (TLA) with
-   identifier (including format prefix) '2345', and the TLA authority at
-   ALPHA-TLA.ORG assigns to C, D and E respectively the next level
-   aggregate (NLA) prefixes 2345:00C0::/28, 2345:00D0::/28 and
-   2345:000E::/32.
-
-   C assigns the NLA prefix 2345:00C1:CA00::/40 to A, D assigns the
-   prefix 2345:00D2:DA00::/40 to A and E assigns 2345:000E:EB00::/40 to
-   B.
-
-   A assigns to X the subscriber identification '11' and B assigns the
-   subscriber identification '22'.  As a result, the site X inherits
-   three address prefixes:
-
-   o  2345:00C1:CA11::/48 from A, for routes through C.
-   o  2345:00D2:DA11::/48 from A, for routes through D.
-   o  2345:000E:EB22::/48 from B, for routes through E.
-
-   Let us suppose that N is a node in the site X, that it is assigned to
-   subnet number 1 in this site, and that it uses the interface
-   identifier '1234:5678:9ABC:DEF0'.  In our configuration, this node
-   will have three addresses:
-
-   o  2345:00C1:CA11:0001:1234:5678:9ABC:DEF0
-   o  2345:00D2:DA11:0001:1234:5678:9ABC:DEF0
-   o  2345:000E:EB22:0001:1234:5678:9ABC:DEF0
-
-5.1.1.  Authoritative Data
-
-   We will assume that the site X is represented in the DNS by the
-   domain name X.EXAMPLE, while A, B, C, D and E are represented by
-   A.NET, B.NET, C.NET, D.NET and E.NET.  In each of these domains, we
-   assume a subdomain "IP6" that will hold the corresponding prefixes.
-   The node N is identified by the domain name N.X.EXAMPLE.  The
-   following records would then appear in X's DNS.
-
-          $ORIGIN X.EXAMPLE.
-          N            A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6
-          SUBNET-1.IP6 A6 48 0:0:0:1::  IP6
-          IP6          A6 48 0::0       SUBSCRIBER-X.IP6.A.NET.
-          IP6          A6 48 0::0       SUBSCRIBER-X.IP6.B.NET.
-
-
-
-
-Crawford, et al.            Standards Track                     [Page 9]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-   And elsewhere there would appear
-
-        SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.C.NET.
-        SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.D.NET.
-
-        SUBSCRIBER-X.IP6.B.NET. A6 40 0:0:0022:: B-NET.IP6.E.NET.
-
-        A.NET.IP6.C.NET. A6 28 0:0001:CA00:: C.NET.ALPHA-TLA.ORG.
-
-        A.NET.IP6.D.NET. A6 28 0:0002:DA00:: D.NET.ALPHA-TLA.ORG.
-
-        B-NET.IP6.E.NET. A6 32 0:0:EB00::    E.NET.ALPHA-TLA.ORG.
-
-        C.NET.ALPHA-TLA.ORG. A6 0 2345:00C0::
-        D.NET.ALPHA-TLA.ORG. A6 0 2345:00D0::
-        E.NET.ALPHA-TLA.ORG. A6 0 2345:000E::
-
-5.1.2.  Glue
-
-   When, as is common, some or all DNS servers for X.EXAMPLE are within
-   the X.EXAMPLE zone itself, the top-level zone EXAMPLE must carry
-   enough "glue" information to enable DNS clients to reach those
-   nameservers.  This is true in IPv6 just as in IPv4.  However, the A6
-   record affords the DNS administrator some choices.  The glue could be
-   any of
-
-   o  a minimal set of A6 records duplicated from the X.EXAMPLE zone,
-
-   o  a (possibly smaller) set of records which collapse the structure
-      of that minimal set,
-
-   o  or a set of A6 records with prefix length zero, giving the entire
-      global addresses of the servers.
-
-   The trade-off is ease of maintenance against robustness.  The best
-   and worst of both may be had together by implementing either the
-   first or second option together with the third.  To illustrate the
-   glue options, suppose that X.EXAMPLE is served by two nameservers
-   NS1.X.EXAMPLE and NS2.X.EXAMPLE, having interface identifiers
-   ::1:11:111:1111 and ::2:22:222:2222 on subnets 1 and 2 respectively.
-   Then the top-level zone EXAMPLE would include one (or more) of the
-   following sets of A6 records as glue.
-
-
-
-
-
-
-
-
-
-Crawford, et al.            Standards Track                    [Page 10]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-   $ORIGIN EXAMPLE.            ; first option
-   X               NS NS1.X
-                   NS NS2.X
-   NS1.X           A6 64 ::1:11:111:1111 SUBNET-1.IP6.X
-   NS2.X           A6 64 ::2:22:222:2222 SUBNET-2.IP6.X
-   SUBNET-1.IP6.X  A6 48 0:0:0:1::       IP6.X
-   SUBNET-2.IP6.X  A6 48 0:0:0:2::       IP6.X
-   IP6.X           A6 48 0::0            SUBSCRIBER-X.IP6.A.NET.
-   IP6.X           A6 48 0::0            SUBSCRIBER-X.IP6.B.NET.
-
-
-   $ORIGIN EXAMPLE.            ; second option
-   X               NS NS1.X
-                   NS NS2.X
-   NS1.X           A6 48 ::1:1:11:111:1111 SUBSCRIBER-X.IP6.A.NET.
-                   A6 48 ::1:1:11:111:1111 SUBSCRIBER-X.IP6.B.NET.
-   NS2.X           A6 48 ::2:2:22:222:2222 SUBSCRIBER-X.IP6.A.NET.
-                   A6 48 ::2:2:22:222:2222 SUBSCRIBER-X.IP6.B.NET.
-
-
-   $ORIGIN EXAMPLE.            ; third option
-   X               NS NS1.X
-                   NS NS2.X
-   NS1.X           A6 0  2345:00C1:CA11:1:1:11:111:1111
-                   A6 0  2345:00D2:DA11:1:1:11:111:1111
-                   A6 0  2345:000E:EB22:1:1:11:111:1111
-   NS2.X           A6 0  2345:00C1:CA11:2:2:22:222:2222
-                   A6 0  2345:00D2:DA11:2:2:22:222:2222
-                   A6 0  2345:000E:EB22:2:2:22:222:2222
-
-   The first and second glue options are robust against renumbering of
-   X.EXAMPLE's prefixes by providers A.NET and B.NET, but will fail if
-   those providers' own DNS is unreachable.  The glue records of the
-   third option are robust against DNS failures elsewhere than the zones
-   EXAMPLE and X.EXAMPLE themselves, but must be updated when X's
-   address space is renumbered.
-
-   If the EXAMPLE zone includes redundant glue, for instance the union
-   of the A6 records of the first and third options, then under normal
-   circumstances duplicate IPv6 addresses will be derived by DNS
-   clients.  But if provider DNS fails, addresses will still be obtained
-   from the zero-prefix-length records, while if the EXAMPLE zone lags
-   behind a renumbering of X.EXAMPLE, half of the addresses obtained by
-   DNS clients will still be up-to-date.
-
-   The zero-prefix-length glue records can of course be automatically
-   generated and/or checked in practice.
-
-
-
-
-Crawford, et al.            Standards Track                    [Page 11]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-5.1.3.  Variations
-
-   Several more-or-less arbitrary assumptions are reflected in the above
-   structure.  All of the following choices could have been made
-   differently, according to someone's notion of convenience or an
-   agreement between two parties.
-
-      First, that site X has chosen to put subnet information in a
-      separate A6 record rather than incorporate it into each node's A6
-      records.
-
-      Second, that site X is referred to as "SUBSCRIBER-X" by both of
-      its providers A and B.
-
-      Third, that site X chose to indirect its provider information
-      through A6 records at IP6.X.EXAMPLE containing no significant
-      bits.  An alternative would have been to replicate each subnet
-      record for each provider.
-
-      Fourth, B and E used a slightly different prefix naming convention
-      between themselves than did A, C and D.  Each hierarchical pair of
-      network entities must arrange this naming between themselves.
-
-      Fifth, that the upward prefix referral chain topped out at ALPHA-
-      TLA.ORG.  There could have been another level which assigned the
-      TLA values and holds A6 records containing those bits.
-
-   Finally, the above structure reflects an assumption that address
-   fields assigned by a given entity are recorded only in A6 records
-   held by that entity.  Those bits could be entered into A6 records in
-   the lower-level entity's zone instead, thus:
-
-                IP6.X.EXAMPLE. A6 40 0:0:11::   IP6.A.NET.
-                IP6.X.EXAMPLE. A6 40 0:0:22::   IP6.B.NET.
-
-                IP6.A.NET.     A6 28 0:1:CA00:: IP6.C.NET.
-                and so on.
-
-   Or the higher-level entities could hold both sorts of A6 records
-   (with different DNS owner names) and allow the lower-level entities
-   to choose either mode of A6 chaining.  But the general principle of
-   avoiding data duplication suggests that the proper place to store
-   assigned values is with the entity that assigned them.
-
-   It is possible, but not necessarily recommended, for a zone
-   maintainer to forego the renumbering support afforded by the chaining
-   of A6 records and to record entire IPv6 addresses within one zone
-   file.
-
-
-
-Crawford, et al.            Standards Track                    [Page 12]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-5.2.  Reverse Mapping Zones
-
-   Supposing that address space assignments in the TLAs with Format
-   Prefix (001) binary and IDs 0345, 0678 and 09AB were maintained in
-   zones called ALPHA-TLA.ORG, BRAVO-TLA.ORG and CHARLIE-TLA.XY, then
-   the IP6.ARPA zone would include
-
-               $ORIGIN IP6.ARPA.
-               \[x234500/24]   DNAME   IP6.ALPHA-TLA.ORG.
-               \[x267800/24]   DNAME   IP6.BRAVO-TLA.ORG.
-               \[x29AB00/24]   DNAME   IP6.CHARLIE-TLA.XY.
-
-   Eight trailing zero bits have been included in each TLA ID to reflect
-   the eight reserved bits in the current aggregatable global unicast
-   addresses format [AGGR].
-
-5.2.1.  The TLA level
-
-   ALPHA-TLA's assignments to network providers C, D and E are reflected
-   in the reverse data as follows.
-
-              \[xC/4].IP6.ALPHA-TLA.ORG.   DNAME  IP6.C.NET.
-              \[xD/4].IP6.ALPHA-TLA.ORG.   DNAME  IP6.D.NET.
-              \[x0E/8].IP6.ALPHA-TLA.ORG.  DNAME  IP6.E.NET.
-
-5.2.2.  The ISP level
-
-   The providers A through E carry the following delegation information
-   in their zone files.
-
-               \[x1CA/12].IP6.C.NET.  DNAME  IP6.A.NET.
-               \[x2DA/12].IP6.D.NET.  DNAME  IP6.A.NET.
-               \[xEB/8].IP6.E.NET.    DNAME  IP6.B.NET.
-               \[x11/8].IP6.A.NET.    DNAME  IP6.X.EXAMPLE.
-               \[x22/8].IP6.B.NET.    DNAME  IP6.X.EXAMPLE.
-
-   Note that some domain names appear in the RDATA of more than one
-   DNAME record.  In those cases, one zone is being used to map multiple
-   prefixes.
-
-5.2.3.  The Site Level
-
-   Consider the customer X.EXAMPLE using IP6.X.EXAMPLE for address-to-
-   name translations.  This domain is now referenced by two different
-   DNAME records held by two different providers.
-
-
-
-
-
-
-Crawford, et al.            Standards Track                    [Page 13]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-           $ORIGIN IP6.X.EXAMPLE.
-           \[x0001/16]                    DNAME   SUBNET-1
-           \[x123456789ABCDEF0].SUBNET-1  PTR     N.X.EXAMPLE.
-           and so on.
-
-   SUBNET-1 need not have been named in a DNAME record; the subnet bits
-   could have been joined with the interface identifier.  But if subnets
-   are treated alike in both the A6 records and in the reverse zone, it
-   will always be possible to keep the forward and reverse definition
-   data for each prefix in one zone.
-
-5.3.  Lookups
-
-   A DNS resolver looking for a hostname for the address
-   2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 would acquire certain of the
-   DNAME records shown above and would form new queries.  Assuming that
-   it began the process knowing servers for IP6.ARPA, but that no server
-   it consulted provided recursion and none had other useful additional
-   information cached, the sequence of queried names and responses would
-   be (all with QCLASS=IN, QTYPE=PTR):
-
-   To a server for IP6.ARPA:
-   QNAME=\[x234500C1CA110001123456789ABCDEF0/128].IP6.ARPA.
-
-        Answer:
-        \[x234500/24].IP6.ARPA. DNAME IP6.ALPHA-TLA.ORG.
-
-   To a server for IP6.ALPHA-TLA.ORG:
-   QNAME=\[xC1CA110001123456789ABCDEF0/104].IP6.ALPHA-TLA.ORG.
-
-        Answer:
-        \[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET.
-
-   To a server for IP6.C.NET.:
-   QNAME=\[x1CA110001123456789ABCDEF0/100].IP6.C.NET.
-
-        Answer:
-        \[x1CA/12].IP6.C.NET. DNAME IP6.A.NET.
-
-   To a server for IP6.A.NET.:
-   QNAME=\[x110001123456789ABCDEF0/88].IP6.A.NET.
-
-        Answer:
-        \[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE.
-
-   To a server for IP6.X.EXAMPLE.:
-   QNAME=\[x0001123456789ABCDEF0/80].IP6.X.EXAMPLE.
-
-
-
-
-Crawford, et al.            Standards Track                    [Page 14]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-        Answer:
-        \[x0001/16].IP6.X.EXAMPLE. DNAME SUBNET-1.IP6.X.EXAMPLE.
-        \[x123456789ABCDEF0/64].SUBNET-1.X.EXAMPLE. PTR N.X.EXAMPLE.
-
-   All the DNAME (and NS) records acquired along the way can be cached
-   to expedite resolution of addresses topologically near to this
-   address.  And if another global address of N.X.EXAMPLE were resolved
-   within the TTL of the final PTR record, that record would not have to
-   be fetched again.
-
-5.4.  Operational Note
-
-   In the illustrations in section 5.1, hierarchically adjacent
-   entities, such as a network provider and a customer, must agree on a
-   DNS name which will own the definition of the delegated prefix(es).
-   One simple convention would be to use a bit-string label representing
-   exactly the bits which are assigned to the lower-level entity by the
-   higher.  For example, "SUBSCRIBER-X" could be replaced by "\[x11/8]".
-   This would place the A6 record(s) defining the delegated prefix at
-   exactly the same point in the DNS tree as the DNAME record associated
-   with that delegation.  The cost of this simplification is that the
-   lower-level zone must update its upward-pointing A6 records when it
-   is renumbered.  This cost may be found quite acceptable in practice.
-
-6.  Transition from RFC 1886 and Deployment Notes
-
-   When prefixes have been "delegated upward" with A6 records, the
-   number of DNS resource records required to establish a single IPv6
-   address increases by some non-trivial factor.  Those records will
-   typically, but not necessarily, come from different DNS zones (which
-   can independently suffer failures for all the usual reasons).  When
-   obtaining multiple IPv6 addresses together, this increase in RR count
-   will be proportionally less -- and the total size of a DNS reply
-   might even decrease -- if the addresses are topologically clustered.
-   But the records could still easily exceed the space available in a
-   UDP response which returns a large RRset [DNSCLAR] to an MX, NS, or
-   SRV query, for example.  The possibilities for overall degradation of
-   performance and reliability of DNS lookups are numerous, and increase
-   with the number of prefix delegations involved, especially when those
-   delegations point to records in other zones.
-
-   DNS Security [DNSSEC] addresses the trustworthiness of cached data,
-   which is a problem intrinsic to DNS, but the cost of applying this to
-   an IPv6 address is multiplied by a factor which may be greater than
-   the number of prefix delegations involved if different signature
-   chains must be verified for different A6 records.  If a trusted
-   centralized caching server (as in [TSIG], for example) is used, this
-   cost might be amortized to acceptable levels.  One new phenomenon is
-
-
-
-Crawford, et al.            Standards Track                    [Page 15]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-   the possibility that IPv6 addresses may be formed from a A6 records
-   from a combination of secure and unsecured zones.
-
-   Until more deployment experience is gained with the A6 record, it is
-   recommended that prefix delegations be limited to one or two levels.
-   A reasonable phasing-in mechanism would be to start with no prefix
-   delegations (all A6 records having prefix length 0) and then to move
-   to the use of a single level of delegation within a single zone.  (If
-   the TTL of the "prefix" A6 records is kept to an appropriate duration
-   the capability for rapid renumbering is not lost.)  More aggressively
-   flexible delegation could be introduced for a subset of hosts for
-   experimentation.
-
-6.1.  Transition from AAAA and Coexistence with A Records
-
-   Administrators of zones which contain A6 records can easily
-   accommodate deployed resolvers which understand AAAA records but not
-   A6 records.  Such administrators can do automatic generation of AAAA
-   records for all of a zone's names which own A6 records by a process
-   which mimics the resolution of a hostname to an IPv6 address (see
-   section 3.1.4).  Attention must be paid to the TTL assigned to a
-   generated AAAA record, which MUST be no more than the minimum of the
-   TTLs of the A6 records that were used to form the IPv6 address in
-   that record.  For full robustness, those A6 records which were in
-   different zones should be monitored for changes (in TTL or RDATA)
-   even when there are no changes to zone for which AAAA records are
-   being generated.  If the zone is secure [DNSSEC], the generated AAAA
-   records MUST be signed along with the rest of the zone data.
-
-   A zone-specific heuristic MAY be used to avoid generation of AAAA
-   records for A6 records which record prefixes, although such
-   superfluous records would be relatively few in number and harmless.
-   Examples of such heuristics include omitting A6 records with a prefix
-   length less than the largest value found in the zone file, or records
-   with an address suffix field with a certain number of trailing zero
-   bits.
-
-   On the client side, when looking up and IPv6 address, the order of A6
-   and AAAA queries MAY be configurable to be one of: A6, then AAAA;
-   AAAA, then A6; A6 only; or both in parallel.  The default order (or
-   only order, if not configurable) MUST be to try A6 first, then AAAA.
-   If and when the AAAA becomes deprecated a new document will change
-   the default.
-
-   The guidelines and options for precedence between IPv4 and IPv6
-   addresses are specified in [TRANS].  All mentions of AAAA records in
-   that document are henceforth to be interpreted as meaning A6 and/or
-   AAAA records in the order specified in the previous paragraph.
-
-
-
-Crawford, et al.            Standards Track                    [Page 16]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-6.2.  Transition from Nibble Labels to Binary Labels
-
-   Implementations conforming to RFC 1886 [AAAA] perform reverse lookups
-   as follows:
-
-      An IPv6 address is represented as a name in the IP6.INT domain by
-      a sequence of nibbles separated by dots with the suffix
-      ".IP6.INT". The sequence of nibbles is encoded in reverse order,
-      i.e. the low-order nibble is encoded first, followed by the next
-      low-order nibble and so on. Each nibble is represented by a
-      hexadecimal digit. For example, a name for the address
-      2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 of the example in section
-      5.3 would be sought at the DNS name "0.f.e.d.c.b.a.9.-
-      8.7.6.5.4.3.2.1.1.0.0.0.1.1.a.c.1.c.0.0.5.4.3.2.ip6.int."
-
-   Implementations conforming to this specification will perform a
-   lookup of a binary label in IP6.ARPA as specified in Section 3.2.  It
-   is RECOMMENDED that for a transition period implementations first
-   lookup the binary label in IP6.ARPA and if this fails try to lookup
-   the 'nibble' label in IP6.INT.
-
-7.  Security Considerations
-
-   The signing authority [DNSSEC] for the A6 records which determine an
-   IPv6 address is distributed among several entities, reflecting the
-   delegation path of the address space which that address occupies.
-   DNS Security is fully applicable to bit-string labels and DNAME
-   records.  And just as in IPv4, verification of name-to-address
-   mappings is logically independent of verification of address-to-name
-   mappings.
-
-   With or without DNSSEC, the incomplete but non-empty address set
-   scenario of section 3.1.4 could be caused by selective interference
-   with DNS lookups.  If in some situation this would be more harmful
-   than complete DNS failure, it might be mitigated on the client side
-   by refusing to act on an incomplete set, or on the server side by
-   listing all addresses in A6 records with prefix length 0.
-
-8.  IANA Considerations
-
-   The A6 resource record has been assigned a Type value of 38.
-
-
-
-
-
-
-
-
-
-
-Crawford, et al.            Standards Track                    [Page 17]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-9.  Acknowledgments
-
-   The authors would like to thank the following persons for valuable
-   discussions and reviews:  Mark Andrews, Rob Austein, Jim Bound, Randy
-   Bush, Brian Carpenter, David Conrad, Steve Deering, Francis Dupont,
-   Robert Elz, Bob Fink, Olafur Gudmundsson, Bob Halley, Bob Hinden,
-   Edward Lewis, Bill Manning, Keith Moore, Thomas Narten, Erik
-   Nordmark, Mike O'Dell, Michael Patton and Ken Powell.
-
-10.  References
-
-   [AAAA]    Thomson, S. and C. Huitema, "DNS Extensions to support IP
-             version 6, RFC 1886, December 1995.
-
-   [AARCH]   Hinden, R. and S. Deering, "IP Version 6 Addressing
-             Architecture", RFC 2373, July 1998.
-
-   [AGGR]    Hinden, R., O'Dell, M. and S. Deering, "An IPv6
-             Aggregatable Global Unicast Address Format", RFC 2374, July
-             1998.
-
-   [BITLBL]  Crawford, M., "Binary Labels in the Domain Name System",
-             RFC 2673, August 1999.
-
-   [DNAME]   Crawford, M., "Non-Terminal DNS Name Redirection", RFC
-             2672, August 1999.
-
-   [DNSCLAR] Elz, R. and R. Bush, "Clarifications to the DNS
-             Specification", RFC 2181, July 1997.
-
-   [DNSIS]   Mockapetris, P., "Domain names - implementation and
-             specification", STD 13, RFC 1035, November 1987.
-
-   [DNSSEC]  Eastlake, D. 3rd and C. Kaufman, "Domain Name System
-             Security Extensions", RFC 2535, March 1999.
-
-   [KWORD]   Bradner, S., "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RENUM1]  Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC
-             1900, February 1996.
-
-   [RENUM2]  Ferguson, P. and H. Berkowitz, "Network Renumbering
-             Overview:  Why would I want it and what is it anyway?", RFC
-             2071, January 1997.
-
-   [RENUM3]  Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address
-             Behaviour Today", RFC 2101, February 1997.
-
-
-
-Crawford, et al.            Standards Track                    [Page 18]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-   [TRANS]   Gilligan, R. and E. Nordmark, "Transition Mechanisms for
-             IPv6 Hosts and Routers", RFC 1933, April 1996.
-
-   [TSIG]    Vixie, P., Gudmundsson, O., Eastlake, D. 3rd and B.
-             Wellington, "Secret Key Transaction Authentication for DNS
-             (TSIG)", RFC 2845, May 2000.
-
-11.  Authors' Addresses
-
-   Matt Crawford
-   Fermilab
-   MS 368
-   PO Box 500
-   Batavia, IL 60510
-   USA
-
-   Phone: +1 630 840-3461
-   EMail: crawdad@fnal.gov
-
-
-   Christian Huitema
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA 98052-6399
-
-   EMail: huitema@microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crawford, et al.            Standards Track                    [Page 19]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-12.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crawford, et al.            Standards Track                    [Page 20]
-
diff --git a/contrib/bind9/doc/rfc/rfc2915.txt b/contrib/bind9/doc/rfc/rfc2915.txt
deleted file mode 100644
index 2022ba1..0000000
--- a/contrib/bind9/doc/rfc/rfc2915.txt
+++ /dev/null
@@ -1,1011 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         M. Mealling
-Request for Comments: 2915                        Network Solutions, Inc.
-Updates: 2168                                                   R. Daniel
-Category: Standards Track                                DATAFUSION, Inc.
-                                                           September 2000
-
-
-        The Naming Authority Pointer (NAPTR) DNS Resource Record
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2000). All Rights Reserved.
-
-Abstract
-
-   This document describes a Domain Name System (DNS) resource record
-   which specifies a regular expression based rewrite rule that, when
-   applied to an existing string, will produce a new domain label or
-   Uniform Resource Identifier (URI).  Depending on the value of the
-   flags field of the resource record, the resulting domain label or URI
-   may be used in subsequent queries for the Naming Authority Pointer
-   (NAPTR) resource records (to delegate the name lookup) or as the
-   output of the entire process for which this system is used (a
-   resolution server for URI resolution, a service URI for ENUM style
-   e.164 number to URI mapping, etc).
-
-   This allows the DNS to be used to lookup services for a wide variety
-   of resource names (including URIs) which are not in domain name
-   syntax.  Reasons for doing this range from URN Resource Discovery
-   Systems to moving out-of-date services to new domains.
-
-   This document updates the portions of RFC 2168 specifically dealing
-   with the definition of the NAPTR records and how other, non-URI
-   specific applications, might use NAPTR.
-
-
-
-
-
-
-
-
-
-Mealling & Daniel           Standards Track                     [Page 1]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .   2
-   2.  NAPTR RR Format  . . . . . . . . . . . . . . . . . . . . . .   3
-   3.  Substitution Expression Grammar  . . . . . . . . . . . . . .   7
-   4.  The Basic NAPTR Algorithm  . . . . . . . . . . . . . . . . .   8
-   5.  Concerning How NAPTR Uses SRV Records  . . . . . . . . . . .   9
-   6.  Application Specifications . . . . . . . . . . . . . . . . .  10
-   7.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . .  10
-   7.1 Example 1  . . . . . . . . . . . . . . . . . . . . . . . . .  10
-   7.2 Example 2  . . . . . . . . . . . . . . . . . . . . . . . . .  12
-   7.3 Example 3  . . . . . . . . . . . . . . . . . . . . . . . . .  13
-   8.  DNS Packet Format  . . . . . . . . . . . . . . . . . . . . .  13
-   9.  Master File Format . . . . . . . . . . . . . . . . . . . . .  14
-   10. Advice for DNS Administrators  . . . . . . . . . . . . . . .  14
-   11. Notes  . . . . . . . . . . . . . . . . . . . . . . . . . . .  15
-   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . .  15
-   13. Security Considerations  . . . . . . . . . . . . . . . . . .  15
-   14. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  16
-       References . . . . . . . . . . . . . . . . . . . . . . . . .  16
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  17
-       Full Copyright Statement . . . . . . . . . . . . . . . . . .  18
-
-1. Introduction
-
-   This RR was originally produced by the URN Working Group [3] as a way
-   to encode rule-sets in DNS so that the delegated sections of a URI
-   could be decomposed in such a way that they could be changed and re-
-   delegated over time.  The result was a Resource Record that included
-   a regular expression that would be used by a client program to
-   rewrite a string into a domain name.  Regular expressions were chosen
-   for their compactness to expressivity ratio allowing for a great deal
-   of information to be encoded in a rather small DNS packet.
-
-   The function of rewriting a string according to the rules in a record
-   has usefulness in several different applications.  This document
-   defines the basic assumptions to which all of those applications must
-   adhere to.  It does not define the reasons the rewrite is used, what
-   the expected outcomes are, or what they are used for.  Those are
-   specified by applications that define how they use the NAPTR record
-   and algorithms within their contexts.
-
-   Flags and other fields are also specified in the RR to control the
-   rewrite procedure in various ways or to provide information on how to
-   communicate with the host at the domain name that was the result of
-   the rewrite.
-
-
-
-
-
-Mealling & Daniel           Standards Track                     [Page 2]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-   The final result is a RR that has several fields that interact in a
-   non-trivial but implementable way.  This document specifies those
-   fields and their values.
-
-   This document does not define applications that utilizes this rewrite
-   functionality. Instead it specifies just the mechanics of how it is
-   done.  Why its done, what the rules concerning the inputs, and the
-   types of rules used are reserved for other documents that fully
-   specify a particular application.  This separation is due to several
-   different applications all wanting to take advantage of the rewrite
-   rule lookup process.  Each one has vastly different reasons for why
-   and how it uses the service, thus requiring that the definition of
-   the service be generic.
-
-      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
-      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
-      in this document are to be interpreted as described in RFC 2119.
-
-      All references to Uniform Resource Identifiers in this document
-      adhere to the 'absoluteURI' production of the "Collected ABNF"
-      found in RFC 2396 [9].  Specifically, the semantics of URI
-      References do not apply since the concept of a Base makes no sense
-      here.
-
-2. NAPTR RR Format
-
-   The format of the NAPTR RR is given below.  The DNS type code [1] for
-   NAPTR is 35.
-
-   Domain TTL Class Type Order Preference Flags Service Regexp
-   Replacement
-
-   Domain
-      The domain name to which this resource record refers.  This is the
-      'key' for this entry in the rule database.  This value will either
-      be the first well known key (<something>.uri.arpa for example) or
-      a new key that is the output of a replacement or regexp rewrite.
-      Beyond this, it has the standard DNS requirements [1].
-
-   TTL
-      Standard DNS meaning [1].
-
-   Class
-      Standard DNS meaning [1].
-
-   Type
-      The Type Code [1] for NAPTR is 35.
-
-
-
-
-Mealling & Daniel           Standards Track                     [Page 3]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-   Order
-      A 16-bit unsigned integer specifying the order in which the NAPTR
-      records MUST be processed to ensure the correct ordering of
-      rules.  Low numbers are processed before high numbers, and once a
-      NAPTR is found whose rule "matches" the target, the client MUST
-      NOT consider any NAPTRs with a higher value for order (except as
-      noted below for the Flags field).
-
-   Preference
-      A 16-bit unsigned integer that specifies the order in which NAPTR
-      records with equal "order" values SHOULD be processed, low
-      numbers being processed before high numbers.  This is similar to
-      the preference field in an MX record, and is used so domain
-      administrators can direct clients towards more capable hosts or
-      lighter weight protocols.  A client MAY look at records with
-      higher preference values if it has a good reason to do so such as
-      not understanding the preferred protocol or service.
-
-      The important difference between Order and Preference is that
-      once a match is found the client MUST NOT consider records with a
-      different Order but they MAY process records with the same Order
-      but different Preferences.  I.e., Preference is used to give weight
-      to rules that are considered the same from an authority
-      standpoint but not from a simple load balancing standpoint.
-
-   Flags
-      A <character-string> containing flags to control aspects of the
-      rewriting and interpretation of the fields in the record.  Flags
-      are single characters from the set [A-Z0-9].  The case of the
-      alphabetic characters is not significant.
-
-      At this time only four flags, "S", "A", "U", and "P", are
-      defined.  The "S", "A" and "U" flags denote a terminal lookup.
-      This means that this NAPTR record is the last one and that the
-      flag determines what the next stage should be.  The "S" flag
-      means that the next lookup should be for SRV records [4].  See
-      Section 5 for additional information on how NAPTR uses the SRV
-      record type.  "A" means that the next lookup should be for either
-      an A, AAAA, or A6 record.  The "U" flag means that the next step
-      is not a DNS lookup but that the output of the Regexp field is an
-      URI that adheres to the 'absoluteURI' production found in the
-      ABNF of RFC 2396 [9].  Since there may be applications that use
-      NAPTR to also lookup aspects of URIs, implementors should be
-      aware that this may cause loop conditions and should act
-      accordingly.
-
-
-
-
-
-
-Mealling & Daniel           Standards Track                     [Page 4]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-      The "P" flag says that the remainder of the application side
-      algorithm shall be carried out in a Protocol-specific fashion.
-      The new set of rules is identified by the Protocol specified in
-      the Services field.  The record that contains the 'P' flag is the
-      last record that is interpreted by the rules specified in this
-      document.  The new rules are dependent on the application for
-      which they are being used and the protocol specified.  For
-      example, if the application is a URI RDS and the protocol is WIRE
-      then the new set of rules are governed by the algorithms
-      surrounding the WIRE HTTP specification and not this document.
-
-      The remaining alphabetic flags are reserved for future versions
-      of the NAPTR specification.  The numeric flags may be used for
-      local experimentation.  The S, A, U and P flags are all mutually
-      exclusive, and resolution libraries MAY signal an error if more
-      than one is given.  (Experimental code and code for assisting in
-      the creation of NAPTRs would be more likely to signal such an
-      error than a client such as a browser).  It is anticipated that
-      multiple flags will be allowed in the future, so implementers
-      MUST NOT assume that the flags field can only contain 0 or 1
-      characters.  Finally, if a client encounters a record with an
-      unknown flag, it MUST ignore it and move to the next record.  This
-      test takes precedence even over the "order" field.  Since flags
-      can control the interpretation placed on fields, a novel flag
-      might change the interpretation of the regexp and/or replacement
-      fields such that it is impossible to determine if a record
-      matched a given target.
-
-      The "S", "A", and "U"  flags are called 'terminal' flags since
-      they halt the looping rewrite algorithm.  If those flags are not
-      present, clients may assume that another NAPTR RR exists at the
-      domain name produced by the current rewrite rule.  Since the "P"
-      flag specifies a new algorithm, it may or may not be 'terminal'.
-      Thus, the client cannot assume that another NAPTR exists since
-      this case is determined elsewhere.
-
-      DNS servers MAY interpret these flags and values and use that
-      information to include appropriate SRV and A,AAAA, or A6 records
-      in the additional information portion of the DNS packet.  Clients
-      are encouraged to check for additional information but are not
-      required to do so.
-
-   Service
-      Specifies the service(s) available down this rewrite path.  It may
-      also specify the particular protocol that is used to talk with a
-      service.  A protocol MUST be specified if the flags field states
-      that the NAPTR is terminal.  If a protocol is specified, but the
-      flags field does not state that the NAPTR is terminal, the next
-
-
-
-Mealling & Daniel           Standards Track                     [Page 5]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-      lookup MUST be for a NAPTR.  The client MAY choose not to perform
-      the next lookup if the protocol is unknown, but that behavior
-      MUST NOT be relied upon.
-
-      The service field may take any of the values below (using the
-      Augmented BNF of RFC 2234 [5]):
-
-                 service_field = [ [protocol] *("+" rs)]
-                 protocol      = ALPHA *31ALPHANUM
-                 rs            = ALPHA *31ALPHANUM
-                 ; The protocol and rs fields are limited to 32
-                 ; characters and must start with an alphabetic.
-
-      For example, an optional protocol specification followed by 0 or
-      more resolution services.  Each resolution service is indicated by
-      an initial '+' character.
-
-      Note that the empty string is also a valid service field.  This
-      will typically be seen at the beginning of a series of rules,
-      when it is impossible to know what services and protocols will be
-      offered by a particular service.
-
-      The actual format of the service request and response will be
-      determined by the resolution protocol, and is the subject for
-      other documents.  Protocols need not offer all services.  The
-      labels for service requests shall be formed from the set of
-      characters [A-Z0-9].  The case of the alphabetic characters is
-      not significant.
-
-      The list of "valid" protocols for any given NAPTR record is any
-      protocol that implements some or all of the services defined for
-      a NAPTR application.  Currently, THTTP [6] is the only protocol
-      that is known to make that claim at the time of publication.  Any
-      other protocol that is to be used must have documentation
-      specifying:
-
-      *  how it implements the services of the application
-
-      *  how it is to appear in the NAPTR record (i.e., the string id
-         of the protocol)
-
-      The list of valid Resolution Services is defined by the documents
-      that specify individual NAPTR based applications.
-
-      It is worth noting that the interpretation of this field is
-      subject to being changed by new flags, and that the current
-      specification is oriented towards telling clients how to talk
-      with a URN resolver.
-
-
-
-Mealling & Daniel           Standards Track                     [Page 6]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-   Regexp
-      A STRING containing a substitution expression that is applied to
-      the original string held by the client in order to construct the
-      next domain name to lookup.  The grammar of the substitution
-      expression is given in the next section.
-
-      The regular expressions MUST NOT be used in a cumulative fashion,
-      that is, they should only be applied to the original string held
-      by the client, never to the domain name produced by a previous
-      NAPTR rewrite.  The latter is tempting in some applications but
-      experience has shown such use to be extremely fault sensitive,
-      very error prone, and extremely difficult to debug.
-
-   Replacement
-      The next NAME to query for NAPTR, SRV, or address records
-      depending on the value of the flags field.  This MUST be a fully
-      qualified domain-name. Unless and until permitted by future
-      standards action, name compression is not to be used for this
-      field.
-
-3. Substitution Expression Grammar
-
-   The content of the regexp field is a substitution expression.  True
-   sed(1) and Perl style substitution expressions are not appropriate
-   for use in this application for a variety of reasons stemming from
-   internationalization requirements and backref limitations, therefore
-   the contents of the regexp field MUST follow the grammar below:
-
-subst_expr   = delim-char  ere  delim-char  repl  delim-char  *flags
-delim-char   = "/" / "!" / ... <Any non-digit or non-flag character
-               other than backslash '\'. All occurances of a delim_char
-               in a subst_expr must be the same character.>
-ere          = POSIX Extended Regular Expression
-repl         = 1 * ( OCTET /  backref )
-backref      = "\" 1POS_DIGIT
-flags        = "i"
-POS_DIGIT    = %x31-39                 ; 0 is not an allowed backref
-
-   The definition of a POSIX Extended Regular Expression can be found in
-   [8], section 2.8.4.
-
-   The result of applying the substitution expression to the original
-   URI MUST result in either a string that obeys the syntax for DNS
-   domain-names [1] or a URI [9] if the Flags field contains a 'u'.
-   Since it is possible for the regexp field to be improperly specified,
-   such that a non-conforming domain-name can be constructed, client
-   software SHOULD verify that the result is a legal DNS domain-name
-   before making queries on it.
-
-
-
-Mealling & Daniel           Standards Track                     [Page 7]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-   Backref expressions in the repl portion of the substitution
-   expression are replaced by the (possibly empty) string of characters
-   enclosed by '(' and ')' in the ERE portion of the substitution
-   expression. N is a single digit from 1 through 9, inclusive.  It
-   specifies the N'th backref expression, the one that begins with the
-   N'th '(' and continues to the matching ')'.  For example, the ERE
-
-                            (A(B(C)DE)(F)G)
-
-         has backref expressions:
-
-                            \1  = ABCDEFG
-                            \2  = BCDE
-                            \3  = C
-                            \4  = F
-                            \5..\9  = error - no matching subexpression
-
-   The "i" flag indicates that the ERE matching SHALL be performed in a
-   case-insensitive fashion. Furthermore, any backref replacements MAY
-   be normalized to lower case when the "i" flag is given.
-
-   The first character in the substitution expression shall be used as
-   the character that delimits the components of the substitution
-   expression.  There must be exactly three non-escaped occurrences of
-   the delimiter character in a substitution expression.  Since escaped
-   occurrences of the delimiter character will be interpreted as
-   occurrences of that character, digits MUST NOT be used as delimiters.
-   Backrefs would be confused with literal digits were this allowed.
-   Similarly, if flags are specified in the substitution expression, the
-   delimiter character must not also be a flag character.
-
-4. The Basic NAPTR Algorithm
-
-   The behavior and meaning of the flags and services assume an
-   algorithm where the output of one rewrite is a new key that points to
-   another rule.  This looping algorithm allows NAPTR records to
-   incrementally specify a complete rule.  These incremental rules can
-   be delegated which allows other entities to specify rules so that one
-   entity does not need to understand _all_ rules.
-
-   The algorithm starts with a string and some known key (domain).
-   NAPTR records for this key are retrieved, those with unknown Flags or
-   inappropriate Services are discarded and the remaining records are
-   sorted by their Order field.  Within each value of Order, the records
-   are further sorted by the Preferences field.
-
-   The records are examined in sorted order until a matching record is
-   found.  A record is considered a match iff:
-
-
-
-Mealling & Daniel           Standards Track                     [Page 8]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-   o  it has a Replacement field value instead of a Regexp field value.
-
-   o  or the Regexp field matches the string held by the client.
-
-   The first match MUST be the match that is used.  Once a match is
-   found, the Services field is examined for whether or not this rule
-   advances toward the desired result.  If so, the rule is applied to
-   the target string.  If not, the process halts.  The domain that
-   results from the regular expression is then used as the domain of the
-   next loop through the NAPTR algorithm.  Note that the same target
-   string is used throughout the algorithm.
-
-   This looping is extremely important since it is the method by which
-   complex rules are broken down into manageable delegated chunks.  The
-   flags fields simply determine at which point the looping should stop
-   (or other specialized behavior).
-
-   Since flags are valid at any level of the algorithm, the degenerative
-   case is to never loop but to look up the NAPTR and then stop.  In
-   many specialized cases this is all that is needed.  Implementors
-   should be aware that the degenerative case should not become the
-   common case.
-
-5. Concerning How NAPTR Uses SRV Records
-
-   When the SRV record type was originally specified it assumed that the
-   client did not know the specific domain-name before hand.  The client
-   would construct a domain-name more in the form of a question than the
-   usual case of knowing ahead of time that the domain-name should
-   exist.  I.e., if the client wants to know if there is a TCP based
-   HTTP server running at a particular domain, the client would
-   construct the domain-name _http._tcp.somedomain.com and ask the DNS
-   if that records exists. The underscores are used to avoid collisions
-   with potentially 'real' domain-names.
-
-   In the case of NAPTR, the actual domain-name is specified by the
-   various fields in the NAPTR record.  In this case the client isn't
-   asking a question but is instead attempting to get at information
-   that it has been told exists in an SRV record at that particular
-   domain-name.  While this usage of SRV is slightly different than the
-   SRV authors originally intended it does not break any of the
-   assumptions concerning what SRV contains.  Also, since the NAPTR
-   explicitly spells out the domain-name for which an SRV exists, that
-   domain-name MUST be used in SRV queries with NO transformations.  Any
-   given NAPTR record may result in a domain-name to be used for SRV
-   queries that may or may not contain the SRV standardized underscore
-
-
-
-
-
-Mealling & Daniel           Standards Track                     [Page 9]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-   characters.  NAPTR applications that make use of SRV MUST NOT attempt
-   to understand these domains or use them according to how the SRV
-   specification structures its query domains.
-
-6. Application Specifications
-
-   It should be noted that the NAPTR algorithm is the basic assumption
-   about how NAPTR works.  The reasons for the rewrite and the expected
-   output and its use are specified by documents that define what
-   applications the NAPTR record and algorithm are used for.  Any
-   document that defines such an application must define the following:
-
-   o  The first known domain-name or how to build it
-
-   o  The valid Services and Protocols
-
-   o  What the expected use is for the output of the last rewrite
-
-   o  The validity and/or behavior of any 'P' flag protocols.
-
-   o  The general semantics surrounding why and how NAPTR and its
-      algorithm are being used.
-
-7. Examples
-
-   NOTE: These are examples only.  They are taken from ongoing work and
-   may not represent the end result of that work. They are here for
-   pedagogical reasons only.
-
-7.1 Example 1
-
-   NAPTR was originally specified for use with the a Uniform Resource
-   Name Resolver Discovery System.  This example details how a
-   particular URN would use the NAPTR record to find a resolver service.
-
-   Consider a URN namespace based on MIME Content-Ids.  The URN might
-   look like this:
-
-      urn:cid:39CB83F7.A8450130@fake.gatech.edu
-
-   (Note that this example is chosen for pedagogical purposes, and does
-   not conform to the CID URL scheme.)
-
-   The first step in the resolution process is to find out about the CID
-   namespace.  The namespace identifier [3], 'cid', is extracted from
-   the URN, prepended to urn.arpa. 'cid.urn.arpa' then becomes the first
-   'known' key in the NAPTR algorithm.  The NAPTR records for
-   cid.urn.arpa looked up and return a single record:
-
-
-
-Mealling & Daniel           Standards Track                    [Page 10]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-   cid.urn.arpa.
-   ;;       order pref flags service        regexp           replacement
-   IN NAPTR 100   10   ""  ""  "/urn:cid:.+@([^\.]+\.)(.*)$/\2/i"    .
-
-   There is only one NAPTR response, so ordering the responses is not a
-   problem.  The replacement field is empty, so the pattern provided in
-   the regexp field is used.  We apply that regexp to the entire URN to
-   see if it matches, which it does.  The \2 part of the substitution
-   expression returns the string "gatech.edu".  Since the flags field
-   does not contain "s" or "a", the lookup is not terminal and our next
-   probe to DNS is for more NAPTR records where the new domain is '
-   gatech.edu' and the string is the same string as before.
-
-   Note that the rule does not extract the full domain name from the
-   CID, instead it assumes the CID comes from a host and extracts its
-   domain.  While all hosts, such as mordred, could have their very own
-   NAPTR, maintaining those records for all the machines at a site as
-   large as Georgia Tech would be an intolerable burden.  Wildcards are
-   not appropriate here since they only return results when there is no
-   exactly matching names already in the system.
-
-   The record returned from the query on "gatech.edu" might look like:
-
-;;       order pref flags service           regexp  replacement
- IN NAPTR 100  50  "s"  "z3950+I2L+I2C"     ""  _z3950._tcp.gatech.edu.
- IN NAPTR 100  50  "s"  "rcds+I2C"          ""  _rcds._udp.gatech.edu.
- IN NAPTR 100  50  "s"  "http+I2L+I2C+I2R"  ""  _http._tcp.gatech.edu.
-
-   Continuing with the example, note that the values of the order and
-   preference fields are equal in all records, so the client is free to
-   pick any record.  The flags field tells us that these are the last
-   NAPTR patterns we should see, and after the rewrite (a simple
-   replacement in this case) we should look up SRV records to get
-   information on the hosts that can provide the necessary service.
-
-   Assuming we prefer the Z39.50 protocol, our lookup might return:
-
- ;;                        Pref Weight   Port Target
- _z3950._tcp.gatech.edu. IN SRV 0    0      1000 z3950.gatech.edu.
-                         IN SRV 0    0      1000 z3950.cc.gatech.edu.
-                         IN SRV 0    0      1000 z3950.uga.edu.
-
-   telling us three hosts that could actually do the resolution, and
-   giving us the port we should use to talk to their Z39.50 server.
-
-   Recall that the regular expression used \2 to extract a domain name
-   from the CID, and \. for matching the literal '.' characters
-   separating the domain name components. Since '\' is the escape
-
-
-
-Mealling & Daniel           Standards Track                    [Page 11]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-   character, literal occurances of a backslash must be escaped by
-   another backslash.  For the case of the cid.urn.arpa record above,
-   the regular expression entered into the master file should be
-   "/urn:cid:.+@([^\\.]+\\.)(.*)$/\\2/i".  When the client code actually
-   receives the record, the pattern will have been converted to
-   "/urn:cid:.+@([^\.]+\.)(.*)$/\2/i".
-
-7.2 Example 2
-
-   Even if URN systems were in place now, there would still be a
-   tremendous number of URLs.  It should be possible to develop a URN
-   resolution system that can also provide location independence for
-   those URLs.  This is related to the requirement that URNs be able to
-   grandfather in names from other naming systems, such as ISO Formal
-   Public Identifiers, Library of Congress Call Numbers, ISBNs, ISSNs,
-   etc.
-
-   The NAPTR RR could also be used for URLs that have already been
-   assigned.  Assume we have the URL for a very popular piece of
-   software that the publisher wishes to mirror at multiple sites around
-   the world:
-
-   Using the rules specified for this application we extract the prefix,
-   "http", and lookup NAPTR records for http.uri.arpa.  This might
-   return a record of the form
-
-     http.uri.arpa. IN NAPTR
-     ;;  order   pref flags service      regexp             replacement
-          100     90   ""      ""   "!http://([^/:]+)!\1!i"       .
-
-   This expression returns everything after the first double slash and
-   before the next slash or colon.  (We use the '!' character to delimit
-   the parts of the substitution expression.  Otherwise we would have to
-   use backslashes to escape the forward slashes and would have a regexp
-   in the zone file that looked like "/http:\\/\\/([^\\/:]+)/\\1/i".).
-
-   Applying this pattern to the URL extracts "www.foo.com".  Looking up
-   NAPTR records for that might return:
-
-     www.foo.com.
-     ;;       order pref flags   service  regexp     replacement
-      IN NAPTR 100  100  "s"   "http+I2R"   ""    _http._tcp.foo.com.
-      IN NAPTR 100  100  "s"   "ftp+I2R"    ""    _ftp._tcp.foo.com.
-
-   Looking up SRV records for http.tcp.foo.com would return information
-   on the hosts that foo.com has designated to be its mirror sites.  The
-   client can then pick one for the user.
-
-
-
-
-Mealling & Daniel           Standards Track                    [Page 12]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-7.3 Example 3
-
-   A non-URI example is the ENUM application which uses a NAPTR record
-   to map an e.164 telephone number to a URI.  In order to convert the
-   phone number to a domain name for the first iteration all characters
-   other than digits are removed from the the telephone number, the
-   entire number is inverted, periods are put between each digit and the
-   string ".e164.arpa" is put on the left-hand side.  For example, the
-   E.164 phone number "+1-770-555-1212" converted to a domain-name it
-   would be "2.1.2.1.5.5.5.0.7.7.1.e164.arpa."
-
-   For this example telephone number we might get back the following
-   NAPTR records:
-
-$ORIGIN 2.1.2.1.5.5.5.0.7.7.1.e164.arpa.
- IN NAPTR 100 10 "u" "sip+E2U"  "!^.*$!sip:information@tele2.se!"     .
- IN NAPTR 102 10 "u" "mailto+E2U" "!^.*$!mailto:information@tele2.se!"  .
-
-   This application uses the same 'u' flag as the URI Resolution
-   application. This flag states that the Rule is terminal and that the
-   output is a URI which contains the information needed to contact that
-   telephone service.  ENUM also uses the same format for its Service
-   field except that it defines the 'E2U' service instead of the 'I2*'
-   services that URI resolution uses.  The example above states that the
-   available protocols used to access that telephone's service are
-   either the Session Initiation Protocol or SMTP mail.
-
-8. DNS Packet Format
-
-         The packet format for the NAPTR record is:
-
-                                          1  1  1  1  1  1
-            0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-          |                     ORDER                     |
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-          |                   PREFERENCE                  |
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-          /                     FLAGS                     /
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-          /                   SERVICES                    /
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-          /                    REGEXP                     /
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-          /                  REPLACEMENT                  /
-          /                                               /
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-
-
-
-Mealling & Daniel           Standards Track                    [Page 13]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-    where:
-
-   FLAGS A <character-string> which contains various flags.
-
-   SERVICES A <character-string> which contains protocol and service
-      identifiers.
-
-   REGEXP A <character-string> which contains a regular expression.
-
-   REPLACEMENT A <domain-name> which specifies the new value in the
-      case where the regular expression is a simple replacement
-      operation.
-
-   <character-string> and <domain-name> as used here are defined in
-   RFC1035 [1].
-
-9. Master File Format
-
-   The master file format follows the standard rules in RFC-1035 [1].
-   Order and preference, being 16-bit unsigned integers, shall be an
-   integer between 0 and 65535.  The Flags and Services and Regexp
-   fields are all quoted <character-string>s.  Since the Regexp field
-   can contain numerous backslashes and thus should be treated with
-   care.  See Section 10 for how to correctly enter and escape the
-   regular expression.
-
-10. Advice for DNS Administrators
-
-   Beware of regular expressions.  Not only are they difficult to get
-   correct on their own, but there is the previously mentioned
-   interaction with DNS.  Any backslashes in a regexp must be entered
-   twice in a zone file in order to appear once in a query response.
-   More seriously, the need for double backslashes has probably not been
-   tested by all implementors of DNS servers.
-
-   The "a" flag allows the next lookup to be for address records (A,
-   AAAA, A6) rather than SRV records.  Since there is no place for a
-   port specification in the NAPTR record, when the "A" flag is used the
-   specified protocol must be running on its default port.
-
-   The URN Syntax draft defines a canonical form for each URN, which
-   requires %encoding characters outside a limited repertoire.  The
-   regular expressions MUST be written to operate on that canonical
-   form.  Since international character sets will end up with extensive
-   use of %encoded characters, regular expressions operating on them
-   will be essentially impossible to read or write by hand.
-
-
-
-
-
-Mealling & Daniel           Standards Track                    [Page 14]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-11. Notes
-
-   o  A client MUST process multiple NAPTR records in the order
-      specified by the "order" field, it MUST NOT simply use the first
-      record that provides a known protocol and service combination.
-
-   o  When multiple RRs have the same "order" and all other criteria
-      being equal, the client should use the value of the preference
-      field to select the next NAPTR to consider.  However, because it
-      will often be the case where preferred protocols or services
-      exist, clients may use this additional criteria to sort
-      the records.
-
-   o  If the lookup after a rewrite fails, clients are strongly
-      encouraged to report a failure, rather than backing up to pursue
-      other rewrite paths.
-
-   o  Note that SRV RRs impose additional requirements on clients.
-
-12. IANA Considerations
-
-   The only registration function that impacts the IANA is for the
-   values that are standardized for the Services and Flags fields.  To
-   extend the valid values of the Flags field beyond what is specified
-   in this document requires a published specification that is approved
-   by the IESG.
-
-   The values for the Services field will be determined by the
-   application that makes use of the NAPTR record.  Those values must be
-   specified in a published specification and approved by the IESG.
-
-13. Security Considerations
-
-   The interactions with DNSSEC are currently being studied.  It is
-   expected that NAPTR records will be signed with SIG records once the
-   DNSSEC work is deployed.
-
-   The rewrite rules make identifiers from other namespaces subject to
-   the same attacks as normal domain names.  Since they have not been
-   easily resolvable before, this may or may not be considered a
-   problem.
-
-   Regular expressions should be checked for sanity, not blindly passed
-   to something like PERL.
-
-   This document has discussed a way of locating a service, but has not
-   discussed any detail of how the communication with that service takes
-   place.  There are significant security considerations attached to the
-
-
-
-Mealling & Daniel           Standards Track                    [Page 15]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-   communication with a service.  Those considerations are outside the
-   scope of this document, and must be addressed by the specifications
-   for particular communication protocols.
-
-14. Acknowledgments
-
-   The editors would like to thank Keith Moore for all his consultations
-   during the development of this memo.  We would also like to thank
-   Paul Vixie for his assistance in debugging our implementation, and
-   his answers on our questions.  Finally, we would like to acknowledge
-   our enormous intellectual debt to the participants in the Knoxville
-   series of meetings, as well as to the participants in the URI and URN
-   working groups.
-
-References
-
-   [1]  Mockapetris, P., "Domain names - implementation and
-        specification", STD 13, RFC 1035, November 1987.
-
-   [2]  Mockapetris, P., "Domain names - concepts and facilities", STD
-        13, RFC 1034, November 1987.
-
-   [3]  Moats, R., "URN Syntax", RFC 2141, May 1997.
-
-   [4]  Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
-        specifying the location of services (DNS SRV)", RFC 2782,
-        February 2000.
-
-   [5]  Crocker, D., "Augmented BNF for Syntax Specifications: ABNF",
-        RFC 2234, November 1997.
-
-   [6]  Daniel, R., "A Trivial Convention for using HTTP in URN
-        Resolution", RFC 2169, June 1997.
-
-   [7]  Daniel, R. and M. Mealling, "Resolution of Uniform Resource
-        Identifiers using the Domain Name System", RFC 2168, June 1997.
-
-   [8]  IEEE, "IEEE Standard for Information Technology - Portable
-        Operating System Interface (POSIX) - Part 2: Shell and Utilities
-        (Vol. 1)", IEEE Std 1003.2-1992, January 1993.
-
-   [9]  Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform
-        Resource Identifiers (URI): Generic Syntax", RFC 2396, August
-        1998.
-
-
-
-
-
-
-
-Mealling & Daniel           Standards Track                    [Page 16]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-Authors' Addresses
-
-   Michael Mealling
-   Network Solutions, Inc.
-   505 Huntmar Park Drive
-   Herndon, VA  22070
-   US
-
-   Phone: +1 770 921 2251
-   EMail: michaelm@netsol.com
-   URI:   http://www.netsol.com
-
-
-   Ron Daniel
-   DATAFUSION, Inc.
-   139 Townsend Street, Ste. 100
-   San Francisco, CA  94107
-   US
-
-   Phone: +1 415 222 0100
-   EMail: rdaniel@datafusion.net
-   URI:   http://www.datafusion.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mealling & Daniel           Standards Track                    [Page 17]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mealling & Daniel           Standards Track                    [Page 18]
-
diff --git a/contrib/bind9/doc/rfc/rfc2929.txt b/contrib/bind9/doc/rfc/rfc2929.txt
deleted file mode 100644
index f055968..0000000
--- a/contrib/bind9/doc/rfc/rfc2929.txt
+++ /dev/null
@@ -1,675 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                   D. Eastlake, 3rd
-Request for Comments: 2929                                      Motorola
-BCP: 42                                              E. Brunner-Williams
-Category: Best Current Practice                                   Engage
-                                                              B. Manning
-                                                                     ISI
-                                                          September 2000
-
-              Domain Name System (DNS) IANA Considerations
-
-Status of this Memo
-
-   This document specifies an Internet Best Current Practices for the
-   Internet Community, and requests discussion and suggestions for
-   improvements.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-Abstract
-
-   Internet Assigned Number Authority (IANA) parameter assignment
-   considerations are given for the allocation of Domain Name System
-   (DNS) classes, Resource Record (RR) types, operation codes, error
-   codes, etc.
-
-Table of Contents
-
-   1. Introduction.................................................  2
-   2. DNS Query/Response Headers...................................  2
-   2.1 One Spare Bit?..............................................  3
-   2.2 Opcode Assignment...........................................  3
-   2.3 RCODE Assignment............................................  4
-   3. DNS Resource Records.........................................  5
-   3.1 RR TYPE IANA Considerations.................................  6
-   3.1.1 Special Note on the OPT RR................................  7
-   3.2 RR CLASS IANA Considerations................................  7
-   3.3 RR NAME Considerations......................................  8
-   4. Security Considerations......................................  9
-   References......................................................  9
-   Authors' Addresses.............................................. 11
-   Full Copyright Statement........................................ 12
-
-
-
-
-
-
-
-
-Eastlake, et al.         Best Current Practice                  [Page 1]
-
-RFC 2929                DNS IANA Considerations           September 2000
-
-
-1. Introduction
-
-   The Domain Name System (DNS) provides replicated distributed secure
-   hierarchical databases which hierarchically store "resource records"
-   (RRs) under domain names.
-
-   This data is structured into CLASSes and zones which can be
-   independently maintained.  See [RFC 1034, 1035, 2136, 2181, 2535]
-   familiarity with which is assumed.
-
-   This document covers, either directly or by reference, general IANA
-   parameter assignment considerations applying across DNS query and
-   response headers and all RRs.  There may be additional IANA
-   considerations that apply to only a particular RR type or
-   query/response opcode.  See the specific RFC defining that RR type or
-   query/response opcode for such considerations if they have been
-   defined.
-
-   IANA currently maintains a web page of DNS parameters.  See
-   <http://www.iana.org/numbers.htm>.
-
-   "IETF Standards Action", "IETF Consensus", "Specification Required",
-   and "Private Use" are as defined in [RFC 2434].
-
-2. DNS Query/Response Headers
-
-   The header for DNS queries and responses contains field/bits in the
-   following diagram taken from [RFC 2136, 2535]:
-
-                                           1  1  1  1  1  1
-             0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
-            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-            |                      ID                       |
-            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-            |QR|   Opcode  |AA|TC|RD|RA| Z|AD|CD|   RCODE   |
-            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-            |                QDCOUNT/ZOCOUNT                |
-            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-            |                ANCOUNT/PRCOUNT                |
-            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-            |                NSCOUNT/UPCOUNT                |
-            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-            |                    ARCOUNT                    |
-            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-   The ID field identifies the query and is echoed in the response so
-   they can be matched.
-
-
-
-
-Eastlake, et al.         Best Current Practice                  [Page 2]
-
-RFC 2929                DNS IANA Considerations           September 2000
-
-
-   The QR bit indicates whether the header is for a query or a response.
-
-   The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful
-   only in queries or only in responses, depending on the bit.  However,
-   many DNS implementations copy the query header as the initial value
-   of the response header without clearing bits.  Thus any attempt to
-   use a "query" bit with a different meaning in a response or to define
-   a query meaning for a "response" bit is dangerous given existing
-   implementation.  Such meanings may only be assigned by an IETF
-   Standards Action.
-
-   The unsigned fields query count (QDCOUNT), answer count (ANCOUNT),
-   authority count (NSCOUNT), and additional information count (ARCOUNT)
-   express the number of records in each section for all opcodes except
-   Update.  These fields have the same structure and data type for
-   Update but are instead the counts for the zone (ZOCOUNT),
-   prerequisite (PRCOUNT), update (UPCOUNT), and additional information
-   (ARCOUNT) sections.
-
-2.1 One Spare Bit?
-
-   There have been ancient DNS implementations for which the Z bit being
-   on in a query meant that only a response from the primary server for
-   a zone is acceptable.  It is believed that current DNS
-   implementations ignore this bit.
-
-   Assigning a meaning to the Z bit requires an IETF Standards Action.
-
-2.2 Opcode Assignment
-
-   New OpCode assignments require an IETF Standards Action.
-
-   Currently DNS OpCodes are assigned as follows:
-
-       OpCode Name                      Reference
-
-        0     Query                     [RFC 1035]
-        1     IQuery  (Inverse Query)   [RFC 1035]
-        2     Status                    [RFC 1035]
-        3     available for assignment
-        4     Notify                    [RFC 1996]
-        5     Update                    [RFC 2136]
-       6-15   available for assignment
-
-
-
-
-
-
-
-
-Eastlake, et al.         Best Current Practice                  [Page 3]
-
-RFC 2929                DNS IANA Considerations           September 2000
-
-
-2.3 RCODE Assignment
-
-   It would appear from the DNS header above that only four bits of
-   RCODE, or response/error code are available.  However, RCODEs can
-   appear not only at the top level of a DNS response but also inside
-   OPT RRs [RFC 2671], TSIG RRs [RFC 2845], and TKEY RRs [RFC 2930].
-   The OPT RR provides an eight bit extension resulting in a 12 bit
-   RCODE field and the TSIG and TKEY RRs have a 16 bit RCODE field.
-
-   Error codes appearing in the DNS header and in these three RR types
-   all refer to the same error code space with the single exception of
-   error code 16 which has a different meaning in the OPT RR from its
-   meaning in other contexts.  See table below.
-
-   RCODE   Name    Description                        Reference
-   Decimal
-     Hexadecimal
-    0    NoError   No Error                           [RFC 1035]
-    1    FormErr   Format Error                       [RFC 1035]
-    2    ServFail  Server Failure                     [RFC 1035]
-    3    NXDomain  Non-Existent Domain                [RFC 1035]
-    4    NotImp    Not Implemented                    [RFC 1035]
-    5    Refused   Query Refused                      [RFC 1035]
-    6    YXDomain  Name Exists when it should not     [RFC 2136]
-    7    YXRRSet   RR Set Exists when it should not   [RFC 2136]
-    8    NXRRSet   RR Set that should exist does not  [RFC 2136]
-    9    NotAuth   Server Not Authoritative for zone  [RFC 2136]
-   10    NotZone   Name not contained in zone         [RFC 2136]
-   11-15           available for assignment
-   16    BADVERS   Bad OPT Version                    [RFC 2671]
-   16    BADSIG    TSIG Signature Failure             [RFC 2845]
-   17    BADKEY    Key not recognized                 [RFC 2845]
-   18    BADTIME   Signature out of time window       [RFC 2845]
-   19    BADMODE   Bad TKEY Mode                      [RFC 2930]
-   20    BADNAME   Duplicate key name                 [RFC 2930]
-   21    BADALG    Algorithm not supported            [RFC 2930]
-   22-3840         available for assignment
-     0x0016-0x0F00
-   3841-4095       Private Use
-     0x0F01-0x0FFF
-   4096-65535      available for assignment
-     0x1000-0xFFFF
-
-   Since it is important that RCODEs be understood for interoperability,
-   assignment of new RCODE listed above as "available for assignment"
-   requires an IETF Consensus.
-
-
-
-
-
-Eastlake, et al.         Best Current Practice                  [Page 4]
-
-RFC 2929                DNS IANA Considerations           September 2000
-
-
-3. DNS Resource Records
-
-   All RRs have the same top level format shown in the figure below
-   taken from [RFC 1035]:
-
-                                         1  1  1  1  1  1
-           0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
-         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-         |                                               |
-         /                                               /
-         /                      NAME                     /
-         |                                               |
-         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-         |                      TYPE                     |
-         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-         |                     CLASS                     |
-         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-         |                      TTL                      |
-         |                                               |
-         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-         |                   RDLENGTH                    |
-         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
-         /                     RDATA                     /
-         /                                               /
-         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-   NAME is an owner name, i.e., the name of the node to which this
-   resource record pertains.  NAMEs are specific to a CLASS as described
-   in section 3.2.  NAMEs consist of an ordered sequence of one or more
-   labels each of which has a label type [RFC 1035, 2671].
-
-   TYPE is a two octet unsigned integer containing one of the RR TYPE
-   codes.  See section 3.1.
-
-   CLASS is a two octet unsigned integer containing one of the RR CLASS
-   codes.  See section 3.2.
-
-   TTL is a four octet (32 bit) bit unsigned integer that specifies the
-   number of seconds that the resource record may be cached before the
-   source of the information should again be consulted.  Zero is
-   interpreted to mean that the RR can only be used for the transaction
-   in progress.
-
-   RDLENGTH is an unsigned 16 bit integer that specifies the length in
-   octets of the RDATA field.
-
-
-
-
-
-
-Eastlake, et al.         Best Current Practice                  [Page 5]
-
-RFC 2929                DNS IANA Considerations           September 2000
-
-
-   RDATA is a variable length string of octets that constitutes the
-   resource.  The format of this information varies according to the
-   TYPE and in some cases the CLASS of the resource record.
-
-3.1 RR TYPE IANA Considerations
-
-   There are three subcategories of RR TYPE numbers: data TYPEs, QTYPEs,
-   and MetaTYPEs.
-
-   Data TYPEs are the primary means of storing data.  QTYPES can only be
-   used in queries.  Meta-TYPEs designate transient data associated with
-   an particular DNS message and in some cases can also be used in
-   queries.  Thus far, data TYPEs have been assigned from 1 upwards plus
-   the block from 100 through 103 while Q and Meta Types have been
-   assigned from 255 downwards (except for the OPT Meta-RR which is
-   assigned TYPE 41).  There have been DNS implementations which made
-   caching decisions based on the top bit of the bottom byte of the RR
-   TYPE.
-
-   There are currently three Meta-TYPEs assigned: OPT [RFC 2671], TSIG
-   [RFC 2845], and TKEY [RFC 2930].
-
-   There are currently five QTYPEs assigned: * (all), MAILA, MAILB,
-   AXFR, and IXFR.
-
-   Considerations for the allocation of new RR TYPEs are as follows:
-
-     Decimal
-   Hexadecimal
-
-     0
-   0x0000 - TYPE zero is used as a special indicator for the SIG RR [RFC
-          2535] and in other circumstances and must never be allocated
-          for ordinary use.
-
-     1 - 127
-   0x0001 - 0x007F - remaining TYPEs in this range are assigned for data
-          TYPEs by IETF Consensus.
-
-     128 - 255
-   0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and
-          Meta TYPEs by IETF Consensus.
-
-     256 - 32767
-   0x0100 - 0x7FFF - assigned for data, Q, or Meta TYPE use by IETF
-          Consensus.
-
-
-
-
-
-Eastlake, et al.         Best Current Practice                  [Page 6]
-
-RFC 2929                DNS IANA Considerations           September 2000
-
-
-     32768 - 65279
-   0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434].
-
-     65280 - 65535
-   0xFF00 - 0xFFFF - Private Use.
-
-3.1.1 Special Note on the OPT RR
-
-   The OPT (OPTion) RR, number 41, is specified in [RFC 2671].  Its
-   primary purpose is to extend the effective field size of various DNS
-   fields including RCODE, label type, flag bits, and RDATA size.  In
-   particular, for resolvers and servers that recognize it, it extends
-   the RCODE field from 4 to 12 bits.
-
-3.2 RR CLASS IANA Considerations
-
-   DNS CLASSes have been little used but constitute another dimension of
-   the DNS distributed database.  In particular, there is no necessary
-   relationship between the name space or root servers for one CLASS and
-   those for another CLASS.  The same name can have completely different
-   meanings in different CLASSes although the label types are the same
-   and the null label is usable only as root in every CLASS.  However,
-   as global networking and DNS have evolved, the IN, or Internet, CLASS
-   has dominated DNS use.
-
-   There are two subcategories of DNS CLASSes: normal data containing
-   classes and QCLASSes that are only meaningful in queries or updates.
-
-   The current CLASS assignments and considerations for future
-   assignments are as follows:
-
-     Decimal
-   Hexadecimal
-
-     0
-   0x0000 - assignment requires an IETF Standards Action.
-
-     1
-   0x0001 - Internet (IN).
-
-     2
-   0x0002 - available for assignment by IETF Consensus as a data CLASS.
-
-     3
-   0x0003 - Chaos (CH) [Moon 1981].
-
-     4
-   0x0004 - Hesiod (HS) [Dyer 1987].
-
-
-
-Eastlake, et al.         Best Current Practice                  [Page 7]
-
-RFC 2929                DNS IANA Considerations           September 2000
-
-
-     5 - 127
-   0x0005 - 0x007F - available for assignment by IETF Consensus as data
-          CLASSes only.
-
-     128 - 253
-   0x0080 - 0x00FD - available for assignment by IETF Consensus as
-          QCLASSes only.
-
-     254
-   0x00FE - QCLASS None [RFC 2136].
-
-     255
-   0x00FF - QCLASS Any [RFC 1035].
-
-     256 - 32767
-   0x0100 - 0x7FFF - assigned by IETF Consensus.
-
-     32768 - 65280
-   0x8000 - 0xFEFF - assigned based on Specification Required as defined
-          in [RFC 2434].
-
-     65280 - 65534
-   0xFF00 - 0xFFFE - Private Use.
-
-     65535
-   0xFFFF - can only be assigned by an IETF Standards Action.
-
-3.3 RR NAME Considerations
-
-   DNS NAMEs are sequences of labels [RFC 1035].  The last label in each
-   NAME is "ROOT" which is the zero length label.  By definition, the
-   null or ROOT label can not be used for any other NAME purpose.
-
-   At the present time, there are two categories of label types, data
-   labels and compression labels.  Compression labels are pointers to
-   data labels elsewhere within an RR or DNS message and are intended to
-   shorten the wire encoding of NAMEs.  The two existing data label
-   types are sometimes referred to as Text and Binary.  Text labels can,
-   in fact, include any octet value including zero octets but most
-   current uses involve only [US-ASCII].  For retrieval, Text labels are
-   defined to treat ASCII upper and lower case letter codes as matching.
-   Binary labels are bit sequences [RFC 2673].
-
-   IANA considerations for label types are given in [RFC 2671].
-
-
-
-
-
-
-
-Eastlake, et al.         Best Current Practice                  [Page 8]
-
-RFC 2929                DNS IANA Considerations           September 2000
-
-
-   NAMEs are local to a CLASS.  The Hesiod [Dyer 1987] and Chaos [Moon
-   1981] CLASSes are essentially for local use.  The IN or Internet
-   CLASS is thus the only DNS CLASS in global use on the Internet at
-   this time.
-
-   A somewhat dated description of name allocation in the IN Class is
-   given in [RFC 1591].  Some information on reserved top level domain
-   names is in Best Current Practice 32 [RFC 2606].
-
-4. Security Considerations
-
-   This document addresses IANA considerations in the allocation of
-   general DNS parameters, not security.  See [RFC 2535] for secure DNS
-   considerations.
-
-References
-
-   [Dyer 1987] Dyer, S., and F. Hsu, "Hesiod", Project Athena Technical
-               Plan - Name Service, April 1987,
-
-   [Moon 1981] D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts
-               Institute of Technology Artificial Intelligence
-               Laboratory, June 1981.
-
-   [RFC 1034]  Mockapetris, P., "Domain Names - Concepts and
-               Facilities", STD 13, RFC 1034, November 1987.
-
-   [RFC 1035]  Mockapetris, P., "Domain Names - Implementation and
-               Specifications", STD 13, RFC 1035, November 1987.
-
-   [RFC 1591]  Postel, J., "Domain Name System Structure and
-               Delegation", RFC 1591, March 1994.
-
-   [RFC 1996]  Vixie, P., "A Mechanism for Prompt Notification of Zone
-               Changes (DNS NOTIFY)", RFC 1996, August 1996.
-
-   [RFC 2136]  Vixie, P., Thomson, S., Rekhter, Y. and J. Bound,
-               "Dynamic Updates in the Domain Name System (DNS UPDATE)",
-               RFC 2136, April 1997.
-
-   [RFC 2181]  Elz, R. and R. Bush, "Clarifications to the DNS
-               Specification", RFC 2181, July 1997.
-
-   [RFC 2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
-               IANA Considerations Section in RFCs", BCP 26, RFC 2434,
-               October 1998.
-
-
-
-
-
-Eastlake, et al.         Best Current Practice                  [Page 9]
-
-RFC 2929                DNS IANA Considerations           September 2000
-
-
-   [RFC 2535]  Eastlake, D., "Domain Name System Security Extensions",
-               RFC 2535, March 1999.
-
-   [RFC 2606]  Eastlake, D. and A. Panitz, "Reserved Top Level DNS
-               Names", RFC 2606, June 1999.
-
-   [RFC 2671]  Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC
-               2671, August 1999.
-
-   [RFC 2672]  Crawford, M., "Non-Terminal DNS Name Redirection", RFC
-               2672, August 1999.
-
-   [RFC 2673]  Crawford, M., "Binary Labels in the Domain Name System",
-               RFC 2673, August 1999.
-
-   [RFC 2845]  Vixie, P., Gudmundsson, O., Eastlake, D. and B.
-               Wellington, "Secret Key Transaction Authentication for
-               DNS (TSIG)", RFC 2845, May 2000.
-
-   [RFC 2930]  Eastlake, D., "Secret Key Establishment for DNS (TKEY
-               RR)", RFC 2930, September 2000.
-
-   [US-ASCII]  ANSI, "USA Standard Code for Information Interchange",
-               X3.4, American National Standards Institute: New York,
-               1968.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake, et al.         Best Current Practice                 [Page 10]
-
-RFC 2929                DNS IANA Considerations           September 2000
-
-
-Authors' Addresses
-
-   Donald E. Eastlake 3rd
-   Motorola
-   140 Forest Avenue
-   Hudson, MA 01749 USA
-
-   Phone: +1-978-562-2827 (h)
-          +1-508-261-5434 (w)
-   Fax:   +1-508-261-4447 (w)
-   EMail: Donald.Eastlake@motorola.com
-
-
-   Eric Brunner-Williams
-   Engage
-   100 Brickstone Square, 2nd Floor
-   Andover, MA 01810
-
-   Phone: +1-207-797-0525 (h)
-          +1-978-684-7796 (w)
-   Fax:   +1-978-684-3118
-   EMail: brunner@engage.com
-
-
-   Bill Manning
-   USC/ISI
-   4676 Admiralty Way, #1001
-   Marina del Rey, CA 90292 USA
-
-   Phone: +1-310-822-1511
-   EMail: bmanning@isi.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake, et al.         Best Current Practice                 [Page 11]
-
-RFC 2929                DNS IANA Considerations           September 2000
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake, et al.         Best Current Practice                 [Page 12]
-
diff --git a/contrib/bind9/doc/rfc/rfc2930.txt b/contrib/bind9/doc/rfc/rfc2930.txt
deleted file mode 100644
index f99573d..0000000
--- a/contrib/bind9/doc/rfc/rfc2930.txt
+++ /dev/null
@@ -1,899 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                   D. Eastlake, 3rd
-Request for Comments: 2930                                      Motorola
-Category: Standards Track                                 September 2000
-
-
-               Secret Key Establishment for DNS (TKEY RR)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-Abstract
-
-   [RFC 2845] provides a means of authenticating Domain Name System
-   (DNS) queries and responses using shared secret keys via the
-   Transaction Signature (TSIG) resource record (RR).  However, it
-   provides no mechanism for setting up such keys other than manual
-   exchange. This document describes a Transaction Key (TKEY) RR that
-   can be used in a number of different modes to establish shared secret
-   keys between a DNS resolver and server.
-
-Acknowledgments
-
-   The comments and ideas of the following persons (listed in alphabetic
-   order) have been incorporated herein and are gratefully acknowledged:
-
-         Olafur Gudmundsson (TIS)
-
-         Stuart Kwan (Microsoft)
-
-         Ed Lewis (TIS)
-
-         Erik Nordmark (SUN)
-
-         Brian Wellington (Nominum)
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 1]
-
-RFC 2930                    The DNS TKEY RR               September 2000
-
-
-Table of Contents
-
-   1. Introduction...............................................  2
-   1.1 Overview of Contents......................................  3
-   2. The TKEY Resource Record...................................  4
-   2.1 The Name Field............................................  4
-   2.2 The TTL Field.............................................  5
-   2.3 The Algorithm Field.......................................  5
-   2.4 The Inception and Expiration Fields.......................  5
-   2.5 The Mode Field............................................  5
-   2.6 The Error Field...........................................  6
-   2.7 The Key Size and Data Fields..............................  6
-   2.8 The Other Size and Data Fields............................  6
-   3. General TKEY Considerations................................  7
-   4. Exchange via Resolver Query................................  8
-   4.1 Query for Diffie-Hellman Exchanged Keying.................  8
-   4.2 Query for TKEY Deletion...................................  9
-   4.3 Query for GSS-API Establishment........................... 10
-   4.4 Query for Server Assigned Keying.......................... 10
-   4.5 Query for Resolver Assigned Keying........................ 11
-   5. Spontaneous Server Inclusion............................... 12
-   5.1 Spontaneous Server Key Deletion........................... 12
-   6. Methods of Encryption...................................... 12
-   7. IANA Considerations........................................ 13
-   8. Security Considerations.................................... 13
-   References.................................................... 14
-   Author's Address.............................................. 15
-   Full Copyright Statement...................................... 16
-
-1. Introduction
-
-   The Domain Name System (DNS) is a hierarchical, distributed, highly
-   available database used for bi-directional mapping between domain
-   names and addresses, for email routing, and for other information
-   [RFC 1034, 1035].  It has been extended to provide for public key
-   security and dynamic update [RFC 2535, RFC 2136].  Familiarity with
-   these RFCs is assumed.
-
-   [RFC 2845] provides a means of efficiently authenticating DNS
-   messages using shared secret keys via the TSIG resource record (RR)
-   but provides no mechanism for setting up such keys other than manual
-   exchange. This document specifies a TKEY RR that can be used in a
-   number of different modes to establish and delete such shared secret
-   keys between a DNS resolver and server.
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 2]
-
-RFC 2930                    The DNS TKEY RR               September 2000
-
-
-   Note that TKEY established keying material and TSIGs that use it are
-   associated with DNS servers or resolvers.  They are not associated
-   with zones.  They may be used to authenticate queries and responses
-   but they do not provide zone based DNS data origin or denial
-   authentication [RFC 2535].
-
-   Certain modes of TKEY perform encryption which may affect their
-   export or import status for some countries.  The affected modes
-   specified in this document are the server assigned mode and the
-   resolver assigned mode.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC 2119].
-
-   In all cases herein, the term "resolver" includes that part of a
-   server which may make full and incremental [RFC 1995] zone transfer
-   queries, forwards recursive queries, etc.
-
-1.1 Overview of Contents
-
-   Section 2 below specifies the TKEY RR and provides a description of
-   and considerations for its constituent fields.
-
-   Section 3 describes general principles of operations with TKEY.
-
-   Section 4 discusses key agreement and deletion via DNS requests with
-   the Query opcode for RR type TKEY.  This method is applicable to all
-   currently defined TKEY modes, although in some cases it is not what
-   would intuitively be called a "query".
-
-   Section 5 discusses spontaneous inclusion of TKEY RRs in responses by
-   servers which is currently used only for key deletion.
-
-   Section 6 describes encryption methods for transmitting secret key
-   information. In this document these are used only for the server
-   assigned mode and the resolver assigned mode.
-
-   Section 7 covers IANA considerations in assignment of TKEY modes.
-
-   Finally, Section 8 provides the required security considerations
-   section.
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 3]
-
-RFC 2930                    The DNS TKEY RR               September 2000
-
-
-2. The TKEY Resource Record
-
-   The TKEY resource record (RR) has the structure given below.  Its RR
-   type code is 249.
-
-      Field       Type         Comment
-      -----       ----         -------
-
-      NAME         domain      see description below
-      TTYPE        u_int16_t   TKEY = 249
-      CLASS        u_int16_t   ignored, SHOULD be 255 (ANY)
-      TTL          u_int32_t   ignored, SHOULD be zero
-      RDLEN        u_int16_t   size of RDATA
-      RDATA:
-       Algorithm:   domain
-       Inception:   u_int32_t
-       Expiration:  u_int32_t
-       Mode:        u_int16_t
-       Error:       u_int16_t
-       Key Size:    u_int16_t
-       Key Data:    octet-stream
-       Other Size:  u_int16_t
-       Other Data:  octet-stream  undefined by this specification
-
-2.1 The Name Field
-
-   The Name field relates to naming keys.  Its meaning differs somewhat
-   with mode and context as explained in subsequent sections.
-
-   At any DNS server or resolver only one octet string of keying
-   material may be in place for any particular key name.  An attempt to
-   establish another set of keying material at a server for an existing
-   name returns a BADNAME error.
-
-   For a TKEY with a non-root name appearing in a query, the TKEY RR
-   name SHOULD be a domain locally unique at the resolver, less than 128
-   octets long in wire encoding, and meaningful to the resolver to
-   assist in distinguishing keys and/or key agreement sessions.   For
-   TKEY(s) appearing in a response to a query, the TKEY RR name SHOULD
-   be a globally unique server assigned domain.
-
-   A reasonable key naming strategy is as follows:
-
-      If the key is generated as the result of a query with root as its
-      owner name, then the server SHOULD create a globally unique domain
-      name, to be the key name, by suffixing a pseudo-random [RFC 1750]
-      label with a domain name of the server.  For example
-      89n3mDgX072pp.server1.example.com.  If generation of a new
-
-
-
-Eastlake                    Standards Track                     [Page 4]
-
-RFC 2930                    The DNS TKEY RR               September 2000
-
-
-      pseudo-random name in each case is an excessive computation load
-      or entropy drain, a serial number prefix can be added to a fixed
-      pseudo-random name generated an DNS server start time, such as
-      1001.89n3mDgX072pp.server1.example.com.
-
-      If the key is generated as the result of a query with a non-root
-      name, say 789.resolver.example.net, then use the concatenation of
-      that with a name of the server.  For example
-      789.resolver.example.net.server1.example.com.
-
-2.2 The TTL Field
-
-   The TTL field is meaningless in TKEY RRs. It SHOULD always be zero to
-   be sure that older DNS implementations do not cache TKEY RRs.
-
-2.3 The Algorithm Field
-
-   The algorithm name is in the form of a domain name with the same
-   meaning as in [RFC 2845].  The algorithm determines how the secret
-   keying material agreed to using the TKEY RR is actually used to
-   derive the algorithm specific key.
-
-2.4 The Inception and Expiration Fields
-
-   The inception time and expiration times are in number of seconds
-   since the beginning of 1 January 1970 GMT ignoring leap seconds
-   treated as modulo 2**32 using ring arithmetic [RFC 1982]. In messages
-   between a DNS resolver and a DNS server where these fields are
-   meaningful, they are either the requested validity interval for the
-   keying material asked for or specify the validity interval of keying
-   material provided.
-
-   To avoid different interpretations of the inception and expiration
-   times in TKEY RRs, resolvers and servers exchanging them must have
-   the same idea of what time it is.  One way of doing this is with the
-   NTP protocol [RFC 2030] but that or any other time synchronization
-   used for this purpose MUST be done securely.
-
-2.5 The Mode Field
-
-   The mode field specifies the general scheme for key agreement or the
-   purpose of the TKEY DNS message.  Servers and resolvers supporting
-   this specification MUST implement the Diffie-Hellman key agreement
-   mode and the key deletion mode for queries.  All other modes are
-   OPTIONAL.  A server supporting TKEY that receives a TKEY request with
-   a mode it does not support returns the BADMODE error.  The following
-   values of the Mode octet are defined, available, or reserved:
-
-
-
-
-Eastlake                    Standards Track                     [Page 5]
-
-RFC 2930                    The DNS TKEY RR               September 2000
-
-
-         Value    Description
-         -----    -----------
-          0        - reserved, see section 7
-          1       server assignment
-          2       Diffie-Hellman exchange
-          3       GSS-API negotiation
-          4       resolver assignment
-          5       key deletion
-         6-65534   - available, see section 7
-         65535     - reserved, see section 7
-
-2.6 The Error Field
-
-   The error code field is an extended RCODE.  The following values are
-   defined:
-
-         Value   Description
-         -----   -----------
-          0       - no error
-          1-15   a non-extended RCODE
-          16     BADSIG   (TSIG)
-          17     BADKEY   (TSIG)
-          18     BADTIME  (TSIG)
-          19     BADMODE
-          20     BADNAME
-          21     BADALG
-
-   When the TKEY Error Field is non-zero in a response to a TKEY query,
-   the DNS header RCODE field indicates no error. However, it is
-   possible if a TKEY is spontaneously included in a response the TKEY
-   RR and DNS header error field could have unrelated non-zero error
-   codes.
-
-2.7 The Key Size and Data Fields
-
-   The key data size field is an unsigned 16 bit integer in network
-   order which specifies the size of the key exchange data field in
-   octets. The meaning of this data depends on the mode.
-
-2.8 The Other Size and Data Fields
-
-   The Other Size and Other Data fields are not used in this
-   specification but may be used in future extensions.  The RDLEN field
-   MUST equal the length of the RDATA section through the end of Other
-   Data or the RR is to be considered malformed and rejected.
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 6]
-
-RFC 2930                    The DNS TKEY RR               September 2000
-
-
-3. General TKEY Considerations
-
-   TKEY is a meta-RR that is not stored or cached in the DNS and does
-   not appear in zone files.  It supports a variety of modes for the
-   establishment and deletion of shared secret keys information between
-   DNS resolvers and servers.  The establishment of such a shared key
-   requires that state be maintained at both ends and the allocation of
-   the resources to maintain such state may require mutual agreement. In
-   the absence of willingness to provide such state, servers MUST return
-   errors such as NOTIMP or REFUSED for an attempt to use TKEY and
-   resolvers are free to ignore any TKEY RRs they receive.
-
-   The shared secret keying material developed by using TKEY is a plain
-   octet sequence.  The means by which this shared secret keying
-   material, exchanged via TKEY, is actually used in any particular TSIG
-   algorithm is algorithm dependent and is defined in connection with
-   that algorithm.  For example, see [RFC 2104] for how TKEY agreed
-   shared secret keying material is used in the HMAC-MD5 algorithm or
-   other HMAC algorithms.
-
-   There MUST NOT be more than one TKEY RR in a DNS query or response.
-
-   Except for GSS-API mode, TKEY responses MUST always have DNS
-   transaction authentication to protect the integrity of any keying
-   data, error codes, etc.  This authentication MUST use a previously
-   established secret (TSIG) or public (SIG(0) [RFC 2931]) key and MUST
-   NOT use any key that the response to be verified is itself providing.
-
-   TKEY queries MUST be authenticated for all modes except GSS-API and,
-   under some circumstances, server assignment mode.  In particular, if
-   the query for a server assigned key is for a key to assert some
-   privilege, such as update authority, then the query must be
-   authenticated to avoid spoofing.  However, if the key is just to be
-   used for transaction security, then spoofing will lead at worst to
-   denial of service.  Query authentication SHOULD use an established
-   secret (TSIG) key authenticator if available.  Otherwise, it must use
-   a public (SIG(0)) key signature.  It MUST NOT use any key that the
-   query is itself providing.
-
-   In the absence of required TKEY authentication, a NOTAUTH error MUST
-   be returned.
-
-   To avoid replay attacks, it is necessary that a TKEY response or
-   query not be valid if replayed on the order of 2**32 second (about
-   136 years), or a multiple thereof, later.  To accomplish this, the
-   keying material used in any TSIG or SIG(0) RR that authenticates a
-   TKEY message MUST NOT have a lifetime of more then 2**31 - 1 seconds
-
-
-
-
-Eastlake                    Standards Track                     [Page 7]
-
-RFC 2930                    The DNS TKEY RR               September 2000
-
-
-   (about 68 years).  Thus, on attempted replay, the authenticating TSIG
-   or SIG(0) RR will not be verifiable due to key expiration and the
-   replay will fail.
-
-4. Exchange via Resolver Query
-
-   One method for a resolver and a server to agree about shared secret
-   keying material for use in TSIG is through DNS requests from the
-   resolver which are syntactically DNS queries for type TKEY.  Such
-   queries MUST be accompanied by a TKEY RR in the additional
-   information section to indicate the mode in use and accompanied by
-   other information where required.
-
-   Type TKEY queries SHOULD NOT be flagged as recursive and servers MAY
-   ignore the recursive header bit in TKEY queries they receive.
-
-4.1 Query for Diffie-Hellman Exchanged Keying
-
-   Diffie-Hellman (DH) key exchange is a means whereby two parties can
-   derive some shared secret information without requiring any secrecy
-   of the messages they exchange [Schneier].  Provisions have been made
-   for the storage of DH public keys in the DNS [RFC 2539].
-
-   A resolver sends a query for type TKEY accompanied by a TKEY RR in
-   the additional information section specifying the Diffie-Hellman mode
-   and accompanied by a KEY RR also in the additional information
-   section specifying a resolver Diffie-Hellman key.  The TKEY RR
-   algorithm field is set to the authentication algorithm the resolver
-   plans to use. The "key data" provided in the TKEY is used as a random
-   [RFC 1750] nonce to avoid always deriving the same keying material
-   for the same pair of DH KEYs.
-
-   The server response contains a TKEY in its answer section with the
-   Diffie-Hellman mode. The "key data" provided in this TKEY is used as
-   an additional nonce to avoid always deriving the same keying material
-   for the same pair of DH KEYs. If the TKEY error field is non-zero,
-   the query failed for the reason given. FORMERR is given if the query
-   included no DH KEY and BADKEY is given if the query included an
-   incompatible DH KEY.
-
-   If the TKEY error field is zero, the resolver supplied Diffie-Hellman
-   KEY RR SHOULD be echoed in the additional information section and a
-   server Diffie-Hellman KEY RR will also be present in the answer
-   section of the response.  Both parties can then calculate the same
-   shared secret quantity from the pair of Diffie-Hellman (DH) keys used
-   [Schneier] (provided these DH keys use the same generator and
-   modulus) and the data in the TKEY RRs.  The TKEY RR data is mixed
-   with the DH result as follows:
-
-
-
-Eastlake                    Standards Track                     [Page 8]
-
-RFC 2930                    The DNS TKEY RR               September 2000
-
-
-      keying material =
-           XOR ( DH value, MD5 ( query data | DH value ) |
-                           MD5 ( server data | DH value ) )
-
-   Where XOR is an exclusive-OR operation and "|" is byte-stream
-   concatenation.  The shorter of the two operands to XOR is byte-wise
-   left justified and padded with zero-valued bytes to match the length
-   of the other operand.  "DH value" is the Diffie-Hellman value derived
-   from the KEY RRs. Query data and server data are the values sent in
-   the TKEY RR data fields.  These "query data" and "server data" nonces
-   are suffixed by the DH value, digested by MD5, the results
-   concatenated, and then XORed with the DH value.
-
-   The inception and expiry times in the query TKEY RR are those
-   requested for the keying material.  The inception and expiry times in
-   the response TKEY RR are the maximum period the server will consider
-   the keying material valid.  Servers may pre-expire keys so this is
-   not a guarantee.
-
-4.2 Query for TKEY Deletion
-
-   Keys established via TKEY can be treated as soft state.  Since DNS
-   transactions are originated by the resolver, the resolver can simply
-   toss keys, although it may have to go through another key exchange if
-   it later needs one.  Similarly, the server can discard keys although
-   that will result in an error on receiving a query with a TSIG using
-   the discarded key.
-
-   To avoid attempted reliance in requests on keys no longer in effect,
-   servers MUST implement key deletion whereby the server "discards" a
-   key on receipt from a resolver of an authenticated delete request for
-   a TKEY RR with the key's name.  If the server has no record of a key
-   with that name, it returns BADNAME.
-
-   Key deletion TKEY queries MUST be authenticated.  This authentication
-   MAY be a TSIG RR using the key to be deleted.
-
-   For querier assigned and Diffie-Hellman keys, the server MUST truly
-   "discard" all active state associated with the key.  For server
-   assigned keys, the server MAY simply mark the key as no longer
-   retained by the client and may re-send it in response to a future
-   query for server assigned keying material.
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 9]
-
-RFC 2930                    The DNS TKEY RR               September 2000
-
-
-4.3 Query for GSS-API Establishment
-
-   This mode is described in a separate document under preparation which
-   should be seen for the full description.  Basically the resolver and
-   server can exchange queries and responses for type TKEY with a TKEY
-   RR specifying the GSS-API mode in the additional information section
-   and a GSS-API token in the key data portion of the TKEY RR.
-
-   Any issues of possible encryption of parts the GSS-API token data
-   being transmitted are handled by the GSS-API level.  In addition, the
-   GSS-API level provides its own authentication so that this mode of
-   TKEY query and response MAY be, but do not need to be, authenticated
-   with TSIG RR or SIG(0) RR [RFC 2931].
-
-   The inception and expiry times in a GSS-API mode TKEY RR are ignored.
-
-4.4 Query for Server Assigned Keying
-
-   Optionally, the server can assign keying for the resolver.  It is
-   sent to the resolver encrypted under a resolver public key.  See
-   section 6 for description of encryption methods.
-
-   A resolver sends a query for type TKEY accompanied by a TKEY RR
-   specifying the "server assignment" mode and a resolver KEY RR to be
-   used in encrypting the response, both in the additional information
-   section. The TKEY algorithm field is set to the authentication
-   algorithm the resolver plans to use.  It is RECOMMENDED that any "key
-   data" provided in the query TKEY RR by the resolver be strongly mixed
-   by the server with server generated randomness [RFC 1750] to derive
-   the keying material to be used.  The KEY RR that appears in the query
-   need not be accompanied by a SIG(KEY) RR.  If the query is
-   authenticated by the resolver with a TSIG RR [RFC 2845] or SIG(0) RR
-   and that authentication is verified, then any SIG(KEY) provided in
-   the query SHOULD be ignored.  The KEY RR in such a query SHOULD have
-   a name that corresponds to the resolver but it is only essential that
-   it be a public key for which the resolver has the corresponding
-   private key so it can decrypt the response data.
-
-   The server response contains a TKEY RR in its answer section with the
-   server assigned mode and echoes the KEY RR provided in the query in
-   its additional information section.
-
-   If the response TKEY error field is zero, the key data portion of the
-   response TKEY RR will be the server assigned keying data encrypted
-   under the public key in the resolver provided KEY RR.  In this case,
-   the owner name of the answer TKEY RR will be the server assigned name
-   of the key.
-
-
-
-
-Eastlake                    Standards Track                    [Page 10]
-
-RFC 2930                    The DNS TKEY RR               September 2000
-
-
-   If the error field of the response TKEY is non-zero, the query failed
-   for the reason given.  FORMERR is given if the query specified no
-   encryption key.
-
-   The inception and expiry times in the query TKEY RR are those
-   requested for the keying material.  The inception and expiry times in
-   the response TKEY are the maximum period the server will consider the
-   keying material valid.  Servers may pre-expire keys so this is not a
-   guarantee.
-
-   The resolver KEY RR MUST be authenticated, through the authentication
-   of this query with a TSIG or SIG(0) or the signing of the resolver
-   KEY with a SIG(KEY).  Otherwise, an attacker can forge a resolver KEY
-   for which they know the private key, and thereby the attacker could
-   obtain a valid shared secret key from the server.
-
-4.5 Query for Resolver Assigned Keying
-
-   Optionally, a server can accept resolver assigned keys.  The keying
-   material MUST be encrypted under a server key for protection in
-   transmission as described in Section 6.
-
-   The resolver sends a TKEY query with a TKEY RR that specifies the
-   encrypted keying material and a KEY RR specifying the server public
-   key used to encrypt the data, both in the additional information
-   section.  The name of the key and the keying data are completely
-   controlled by the sending resolver so a globally unique key name
-   SHOULD be used.  The KEY RR used MUST be one for which the server has
-   the corresponding private key, or it will not be able to decrypt the
-   keying material and will return a FORMERR. It is also important that
-   no untrusted party (preferably no other party than the server) has
-   the private key corresponding to the KEY RR because, if they do, they
-   can capture the messages to the server, learn the shared secret, and
-   spoof valid TSIGs.
-
-   The query TKEY RR inception and expiry give the time period the
-   querier intends to consider the keying material valid.  The server
-   can return a lesser time interval to advise that it will not maintain
-   state for that long and can pre-expire keys in any case.
-
-   This mode of query MUST be authenticated with a TSIG or SIG(0).
-   Otherwise, an attacker can forge a resolver assigned TKEY query, and
-   thereby the attacker could specify a shared secret key that would be
-   accepted, used, and honored by the server.
-
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 11]
-
-RFC 2930                    The DNS TKEY RR               September 2000
-
-
-5. Spontaneous Server Inclusion
-
-   A DNS server may include a TKEY RR spontaneously as additional
-   information in responses.  This SHOULD only be done if the server
-   knows the querier understands TKEY and has this option implemented.
-   This technique can be used to delete a key and may be specified for
-   modes defined in the future.  A disadvantage of this technique is
-   that there is no way for the server to get any error or success
-   indication back and, in the case of UDP, no way to even know if the
-   DNS response reached the resolver.
-
-5.1 Spontaneous Server Key Deletion
-
-   A server can optionally tell a client that it has deleted a secret
-   key by spontaneously including a TKEY RR in the additional
-   information section of a response with the key's name and specifying
-   the key deletion mode.  Such a response SHOULD be authenticated.  If
-   authenticated, it "deletes" the key with the given name.  The
-   inception and expiry times of the delete TKEY RR are ignored. Failure
-   by a client to receive or properly process such additional
-   information in a response would mean that the client might use a key
-   that the server had discarded and would then get an error indication.
-
-   For server assigned and Diffie-Hellman keys, the client MUST
-   "discard" active state associated with the key.  For querier assigned
-   keys, the querier MAY simply mark the key as no longer retained by
-   the server and may re-send it in a future query specifying querier
-   assigned keying material.
-
-6. Methods of Encryption
-
-   For the server assigned and resolver assigned key agreement modes,
-   the keying material is sent within the key data field of a TKEY RR
-   encrypted under the public key in an accompanying KEY RR [RFC 2535].
-   This KEY RR MUST be for a public key algorithm where the public and
-   private keys can be used for encryption and the corresponding
-   decryption which recovers the originally encrypted data.  The KEY RR
-   SHOULD correspond to a name for the decrypting resolver/server such
-   that the decrypting process has access to the corresponding private
-   key to decrypt the data.  The secret keying material being sent will
-   generally be fairly short, usually less than 256 bits, because that
-   is adequate for very strong protection with modern keyed hash or
-   symmetric algorithms.
-
-   If the KEY RR specifies the RSA algorithm, then the keying material
-   is encrypted as per the description of RSAES-PKCS1-v1_5 encryption in
-   PKCS#1 [RFC 2437].  (Note, the secret keying material being sent is
-   directly RSA encrypted in PKCS#1 format. It is not "enveloped" under
-
-
-
-Eastlake                    Standards Track                    [Page 12]
-
-RFC 2930                    The DNS TKEY RR               September 2000
-
-
-   some other symmetric algorithm.)  In the unlikely event that the
-   keying material will not fit within one RSA modulus of the chosen
-   public key, additional RSA encryption blocks are included.  The
-   length of each block is clear from the public RSA key specified and
-   the RSAES-PKCS1-v1_5 padding makes it clear what part of the
-   encrypted data is actually keying material and what part is
-   formatting or the required at least eight bytes of random [RFC 1750]
-   padding.
-
-7. IANA Considerations
-
-   This section is to be interpreted as provided in [RFC 2434].
-
-   Mode field values 0x0000 and 0xFFFF are reserved.
-
-   Mode field values 0x0001 through 0x00FF, and 0XFF00 through 0XFFFE
-   can only be assigned by an IETF Standards Action.
-
-   Mode field values 0x0100 through 0x0FFF and 0xF0000 through 0xFEFF
-   are allocated by IESG approval or IETF consensus.
-
-   Mode field values 0x1000 through 0xEFFF are allocated based on
-   Specification Required as defined in [RFC 2434].
-
-   Mode values should not be changed when the status of their use
-   changes.  For example, a mode value assigned based just on providing
-   a specification should not be changed later just because that use's
-   status is changed to standards track.
-
-   The following assignments are documented herein:
-
-      RR Type 249 for TKEY.
-
-      TKEY Modes 1 through 5 as listed in section 2.5.
-
-      Extended RCODE Error values of 19, 20, and 21 as listed in section
-      2.6.
-
-8. Security Considerations
-
-   The entirety of this specification is concerned with the secure
-   establishment of a shared secret between DNS clients and servers in
-   support of TSIG [RFC 2845].
-
-   Protection against denial of service via the use of TKEY is not
-   provided.
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 13]
-
-RFC 2930                    The DNS TKEY RR               September 2000
-
-
-References
-
-   [Schneier] Bruce Schneier, "Applied Cryptography: Protocols,
-              Algorithms, and Source Code in C", 1996, John Wiley and
-              Sons
-
-   [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
-              STD 13, RFC 1034, November 1987.
-
-   [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
-              Specifications", STD 13, RFC 1035, November 1987.
-
-   [RFC 1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
-              Recommendations for Security", RFC 1750, December 1994.
-
-   [RFC 1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
-              September 1996.
-
-   [RFC 1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
-              August 1996.
-
-   [RFC 2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4
-              for IPv4, IPv6 and OSI", RFC 2030, October 1996.
-
-   [RFC 2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:  Keyed-
-              Hashing for Message Authentication", RFC 2104, February
-              1997.
-
-   [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC 2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
-              Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
-              April 1997.
-
-   [RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
-              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
-              October 1998.
-
-   [RFC 2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
-              Specifications Version 2.0", RFC 2437, October 1998.
-
-   [RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
-              RFC 2535, March 1999.
-
-   [RFC 2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the
-              Domain Name System (DNS)", RFC 2539, March 1999.
-
-
-
-
-Eastlake                    Standards Track                    [Page 14]
-
-RFC 2930                    The DNS TKEY RR               September 2000
-
-
-   [RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B.
-              Wellington, "Secret Key Transaction Authentication for DNS
-              (TSIG)", RFC 2845, May 2000.
-
-   [RFC 2931] Eastlake, D., "DNS Request and Transaction Signatures
-              (SIG(0)s )", RFC 2931, September 2000.
-
-Author's Address
-
-   Donald E. Eastlake 3rd
-   Motorola
-   140 Forest Avenue
-   Hudson, MA 01749 USA
-
-   Phone: +1 978-562-2827 (h)
-          +1 508-261-5434 (w)
-   Fax:   +1 508-261-4447 (w)
-   EMail: Donald.Eastlake@motorola.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 15]
-
-RFC 2930                    The DNS TKEY RR               September 2000
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 16]
-
diff --git a/contrib/bind9/doc/rfc/rfc2931.txt b/contrib/bind9/doc/rfc/rfc2931.txt
deleted file mode 100644
index 84cc97e..0000000
--- a/contrib/bind9/doc/rfc/rfc2931.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                    D. Eastlake 3rd
-Request for Comments: 2931                                      Motorola
-Updates: 2535                                             September 2000
-Category: Standards Track
-
-
-           DNS Request and Transaction Signatures ( SIG(0)s )
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-Abstract
-
-   Extensions to the Domain Name System (DNS) are described in [RFC
-   2535] that can provide data origin and transaction integrity and
-   authentication to security aware resolvers and applications through
-   the use of cryptographic digital signatures.
-
-   Implementation experience has indicated the need for minor but non-
-   interoperable changes in Request and Transaction signature resource
-   records ( SIG(0)s ).  These changes are documented herein.
-
-Acknowledgments
-
-   The contributions and suggestions of the following persons (in
-   alphabetic order) to this memo are gratefully acknowledged:
-
-         Olafur Gudmundsson
-
-         Ed Lewis
-
-         Erik Nordmark
-
-         Brian Wellington
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 1]
-
-RFC 2931                       DNS SIG(0)                 September 2000
-
-
-Table of Contents
-
-   1. Introduction.................................................  2
-   2. SIG(0) Design Rationale......................................  3
-   2.1 Transaction Authentication..................................  3
-   2.2 Request Authentication......................................  3
-   2.3 Keying......................................................  3
-   2.4 Differences Between TSIG and SIG(0).........................  4
-   3. The SIG(0) Resource Record...................................  4
-   3.1 Calculating Request and Transaction SIGs....................  5
-   3.2 Processing Responses and SIG(0) RRs.........................  6
-   3.3 SIG(0) Lifetime and Expiration..............................  7
-   4. Security Considerations......................................  7
-   5. IANA Considerations..........................................  7
-   References......................................................  7
-   Author's Address................................................  8
-   Appendix: SIG(0) Changes from RFC 2535..........................  9
-   Full Copyright Statement........................................ 10
-
-1. Introduction
-
-   This document makes minor but non-interoperable changes to part of
-   [RFC 2535], familiarity with which is assumed, and includes
-   additional explanatory text.  These changes concern SIG Resource
-   Records (RRs) that are used to digitally sign DNS requests and
-   transactions / responses.  Such a resource record, because it has a
-   type covered field of zero, is frequently called a SIG(0). The
-   changes are based on implementation and attempted implementation
-   experience with TSIG [RFC 2845] and the [RFC 2535] specification for
-   SIG(0).
-
-   Sections of [RFC 2535] updated are all of 4.1.8.1 and parts of 4.2
-   and 4.3.  No changes are made herein related to the KEY or NXT RRs or
-   to the processing involved with data origin and denial authentication
-   for DNS data.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC 2119].
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 2]
-
-RFC 2931                       DNS SIG(0)                 September 2000
-
-
-2. SIG(0) Design Rationale
-
-   SIG(0) provides protection for DNS transactions and requests that is
-   not provided by the regular SIG, KEY, and NXT RRs specified in [RFC
-   2535].  The authenticated data origin services of secure DNS either
-   provide protected data resource records (RRs) or authenticatably deny
-   their nonexistence.  These services provide no protection for glue
-   records, DNS requests, no protection for message headers on requests
-   or responses, and no protection of the overall integrity of a
-   response.
-
-2.1 Transaction Authentication
-
-   Transaction authentication means that a requester can be sure it is
-   at least getting the messages from the server it queried and that the
-   received messages are in response to the query it sent.  This is
-   accomplished by optionally adding either a TSIG RR [RFC 2845] or, as
-   described herein, a SIG(0) resource record at the end of the response
-   which digitally signs the concatenation of the server's response and
-   the corresponding resolver query.
-
-2.2 Request Authentication
-
-   Requests can also be authenticated by including a TSIG or, as
-   described herein, a special SIG(0) RR at the end of the request.
-   Authenticating requests serves no function in DNS servers that
-   predate the specification of dynamic update.  Requests with a non-
-   empty additional information section produce error returns or may
-   even be ignored by a few such older DNS servers. However, this syntax
-   for signing requests is defined for authenticating dynamic update
-   requests [RFC 2136], TKEY requests [RFC 2930], or future requests
-   requiring authentication.
-
-2.3 Keying
-
-   The private keys used in transaction security belong to the host
-   composing the DNS response message, not to the zone involved.
-   Request authentication may also involve the private key of the host
-   or other entity composing the request or of a zone to be affected by
-   the request or other private keys depending on the request authority
-   it is sought to establish. The corresponding public key(s) are
-   normally stored in and retrieved from the DNS for verification as KEY
-   RRs with a protocol byte of 3 (DNSSEC) or 255 (ANY).
-
-   Because requests and replies are highly variable, message
-   authentication SIGs can not be pre-calculated.  Thus it will be
-   necessary to keep the private key on-line, for example in software or
-   in a directly connected piece of hardware.
-
-
-
-Eastlake                    Standards Track                     [Page 3]
-
-RFC 2931                       DNS SIG(0)                 September 2000
-
-
-2.4 Differences Between TSIG and SIG(0)
-
-   There are significant differences between TSIG and SIG(0).
-
-   Because TSIG involves secret keys installed at both the requester and
-   server the presence of such a key implies that the other party
-   understands TSIG and very likely has the same key installed.
-   Furthermore, TSIG uses keyed hash authentication codes which are
-   relatively inexpensive to compute.  Thus it is common to authenticate
-   requests with TSIG and responses are authenticated with TSIG if the
-   corresponding request is authenticated.
-
-   SIG(0) on the other hand, uses public key authentication, where the
-   public keys are stored in DNS as KEY RRs and a private key is stored
-   at the signer.  Existence of such a KEY RR does not necessarily imply
-   implementation of SIG(0).  In addition, SIG(0) involves relatively
-   expensive public key cryptographic operations that should be
-   minimized and the verification of a SIG(0) involves obtaining and
-   verifying the corresponding KEY which can be an expensive and lengthy
-   operation.  Indeed, a policy of using SIG(0) on all requests and
-   verifying it before responding would, for some configurations, lead
-   to a deadly embrace with the attempt to obtain and verify the KEY
-   needed to authenticate the request SIG(0) resulting in additional
-   requests accompanied by a SIG(0) leading to further requests
-   accompanied by a SIG(0), etc.  Furthermore, omitting SIG(0)s when not
-   required on requests halves the number of public key operations
-   required by the transaction.
-
-   For these reasons, SIG(0)s SHOULD only be used on requests when
-   necessary to authenticate that the requester has some required
-   privilege or identity.  SIG(0)s on replies are defined in such a way
-   as to not require a SIG(0) on the corresponding request and still
-   provide transaction protection.  For other replies, whether they are
-   authenticated by the server or required to be authenticated by the
-   requester SHOULD be a local configuration option.
-
-3. The SIG(0) Resource Record
-
-   The structure of and type number of SIG resource records (RRs) is
-   given in [RFC 2535] Section 4.1.  However all of Section 4.1.8.1 and
-   the parts of Sections 4.2 and 4.3 related to SIG(0) should be
-   considered replaced by the material below.  Any conflict between [RFC
-   2535] and this document concerning SIG(0) RRs should be resolved in
-   favor of this document.
-
-   For all transaction SIG(0)s, the signer field MUST be a name of the
-   originating host and there MUST be a KEY RR at that name with the
-   public key corresponding to the private key used to calculate the
-
-
-
-Eastlake                    Standards Track                     [Page 4]
-
-RFC 2931                       DNS SIG(0)                 September 2000
-
-
-   signature.  (The host domain name used may be the inverse IP address
-   mapping name for an IP address of the host if the relevant KEY is
-   stored there.)
-
-   For all SIG(0) RRs, the owner name, class, TTL, and original TTL, are
-   meaningless.  The TTL fields SHOULD be zero and the CLASS field
-   SHOULD be ANY.  To conserve space, the owner name SHOULD be root (a
-   single zero octet).  When SIG(0) authentication on a response is
-   desired, that SIG RR MUST be considered the highest priority of any
-   additional information for inclusion in the response. If the SIG(0)
-   RR cannot be added without causing the message to be truncated, the
-   server MUST alter the response so that a SIG(0) can be included.
-   This response consists of only the question and a SIG(0) record, and
-   has the TC bit set and RCODE 0 (NOERROR).  The client should at this
-   point retry the request using TCP.
-
-3.1 Calculating Request and Transaction SIGs
-
-   A DNS request may be optionally signed by including one SIG(0)s at
-   the end of the query additional information section.  Such a SIG is
-   identified by having a "type covered" field of zero. It signs the
-   preceding DNS request message including DNS header but not including
-   the UDP/IP header and before the request RR counts have been adjusted
-   for the inclusions of the request SIG(0).
-
-   It is calculated by using a "data" (see [RFC 2535], Section 4.1.8) of
-   (1) the SIG's RDATA section entirely omitting (not just zeroing) the
-   signature subfield itself, (2) the DNS query messages, including DNS
-   header, but not the UDP/IP header and before the reply RR counts have
-   been adjusted for the inclusion of the SIG(0).  That is
-
-      data = RDATA | request - SIG(0)
-
-   where "|" is concatenation and RDATA is the RDATA of the SIG(0) being
-   calculated less the signature itself.
-
-   Similarly, a SIG(0) can be used to secure a response and the request
-   that produced it.  Such transaction signatures are calculated by
-   using a "data" of (1) the SIG's RDATA section omitting the signature
-   itself, (2) the entire DNS query message that produced this response,
-   including the query's DNS header but not its UDP/IP header, and (3)
-   the entire DNS response message, including DNS header but not the
-   UDP/IP header and before the response RR counts have been adjusted
-   for the inclusion of the SIG(0).
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 5]
-
-RFC 2931                       DNS SIG(0)                 September 2000
-
-
-   That is
-
-      data = RDATA | full query | response - SIG(0)
-
-   where "|" is concatenation and RDATA is the RDATA of the SIG(0) being
-   calculated less the signature itself.
-
-   Verification of a response SIG(0) (which is signed by the server host
-   key, not the zone key) by the requesting resolver shows that the
-   query and response were not tampered with in transit, that the
-   response corresponds to the intended query, and that the response
-   comes from the queried server.
-
-   In the case of a DNS message via TCP, a SIG(0) on the first data
-   packet is calculated with "data" as above and for each subsequent
-   packet, it is calculated as follows:
-
-      data = RDATA | DNS payload - SIG(0) | previous packet
-
-   where "|" is concatenations, RDATA is as above, and previous packet
-   is the previous DNS payload including DNS header and the SIG(0) but
-   not the TCP/IP header.  Support of SIG(0) for TCP is OPTIONAL.  As an
-   alternative, TSIG may be used after, if necessary, setting up a key
-   with TKEY [RFC 2930].
-
-   Except where needed to authenticate an update, TKEY, or similar
-   privileged request, servers are not required to check a request
-   SIG(0).
-
-   Note: requests and responses can either have a single TSIG or one
-   SIG(0) but not both a TSIG and a SIG(0).
-
-3.2 Processing Responses and SIG(0) RRs
-
-   If a SIG RR is at the end of the additional information section of a
-   response and has a type covered of zero, it is a transaction
-   signature covering the response and the query that produced the
-   response.  For TKEY responses, it MUST be checked and the message
-   rejected if the checks fail unless otherwise specified for the TKEY
-   mode in use.  For all other responses, it MAY be checked and the
-   message rejected if the checks fail.
-
-   If a response's SIG(0) check succeed, such a transaction
-   authentication SIG does NOT directly authenticate the validity any
-   data-RRs in the message.  However, it authenticates that they were
-   sent by the queried server and have not been diddled.  (Only a proper
-   SIG(0) RR signed by the zone or a key tracing its authority to the
-   zone or to static resolver configuration can directly authenticate
-
-
-
-Eastlake                    Standards Track                     [Page 6]
-
-RFC 2931                       DNS SIG(0)                 September 2000
-
-
-   data-RRs, depending on resolver policy.) If a resolver or server does
-   not implement transaction and/or request SIGs, it MUST ignore them
-   without error where they are optional and treat them as failing where
-   they are required.
-
-3.3 SIG(0) Lifetime and Expiration
-
-   The inception and expiration times in SIG(0)s are for the purpose of
-   resisting replay attacks.  They should be set to form a time bracket
-   such that messages outside that bracket can be ignored.  In IP
-   networks, this time bracket should not normally extend further than 5
-   minutes into the past and 5 minutes into the future.
-
-4. Security Considerations
-
-   No additional considerations beyond those in [RFC 2535].
-
-   The inclusion of the SIG(0) inception and expiration time under the
-   signature improves resistance to replay attacks.
-
-5. IANA Considerations
-
-   No new parameters are created or parameter values assigned by this
-   document.
-
-References
-
-   [RFC 1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
-              September 1996.
-
-   [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC 2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
-              Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
-              April 1997.
-
-   [RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
-              RFC 2535, March 1999.
-
-   [RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B.
-              Wellington, "Secret Key Transaction Signatures for DNS
-              (TSIG)", RFC 2845, May 2000.
-
-   [RFC 2930] Eastlake, D., "Secret Key Establishment for DNS (RR)", RFC
-              2930, September 2000.
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 7]
-
-RFC 2931                       DNS SIG(0)                 September 2000
-
-
-Author's Address
-
-   Donald E. Eastlake 3rd
-   Motorola
-   140 Forest Avenue
-   Hudson, MA 01749 USA
-
-   Phone: +1-978-562-2827(h)
-          +1-508-261-5434(w)
-   Fax:   +1 978-567-7941(h)
-          +1-508-261-4447(w)
-   EMail: Donald.Eastlake@motorola.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 8]
-
-RFC 2931                       DNS SIG(0)                 September 2000
-
-
-Appendix: SIG(0) Changes from RFC 2535
-
-   Add explanatory text concerning the differences between TSIG and
-   SIG(0).
-
-   Change the data over which SIG(0) is calculated to include the SIG(0)
-   RDATA other than the signature itself so as to secure the signature
-   inception and expiration times and resist replay attacks.  Specify
-   SIG(0) for TCP.
-
-   Add discussion of appropriate inception and expiration times for
-   SIG(0).
-
-   Add wording to indicate that either a TSIG or one or more SIG(0)s may
-   be present but not both.
-
-   Reword some areas for clarity.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 9]
-
-RFC 2931                       DNS SIG(0)                 September 2000
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 10]
-
diff --git a/contrib/bind9/doc/rfc/rfc3007.txt b/contrib/bind9/doc/rfc/rfc3007.txt
deleted file mode 100644
index 1697475..0000000
--- a/contrib/bind9/doc/rfc/rfc3007.txt
+++ /dev/null
@@ -1,507 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                      B. Wellington
-Request for Comments: 3007                                       Nominum
-Updates: 2535, 2136                                        November 2000
-Obsoletes: 2137
-Category: Standards Track
-
-
-             Secure Domain Name System (DNS) Dynamic Update
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-Abstract
-
-   This document proposes a method for performing secure Domain Name
-   System (DNS) dynamic updates.  The method described here is intended
-   to be flexible and useful while requiring as few changes to the
-   protocol as possible.  The authentication of the dynamic update
-   message is separate from later DNSSEC validation of the data.  Secure
-   communication based on authenticated requests and transactions is
-   used to provide authorization.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [RFC2119].
-
-1 - Introduction
-
-   This document defines a means to secure dynamic updates of the Domain
-   Name System (DNS), allowing only authorized sources to make changes
-   to a zone's contents.  The existing unsecured dynamic update
-   operations form the basis for this work.
-
-   Familiarity with the DNS system [RFC1034, RFC1035] and dynamic update
-   [RFC2136] is helpful and is assumed by this document.  In addition,
-   knowledge of DNS security extensions [RFC2535], SIG(0) transaction
-   security [RFC2535, RFC2931], and TSIG transaction security [RFC2845]
-   is recommended.
-
-
-
-
-Wellington                  Standards Track                     [Page 1]
-
-RFC 3007                 Secure Dynamic Update             November 2000
-
-
-   This document updates portions of RFC 2535, in particular section
-   3.1.2, and RFC 2136.  This document obsoletes RFC 2137, an alternate
-   proposal for secure dynamic update, due to implementation experience.
-
-1.1 - Overview of DNS Dynamic Update
-
-   DNS dynamic update defines a new DNS opcode and a new interpretation
-   of the DNS message if that opcode is used.  An update can specify
-   insertions or deletions of data, along with prerequisites necessary
-   for the updates to occur.  All tests and changes for a DNS update
-   request are restricted to a single zone, and are performed at the
-   primary server for the zone.  The primary server for a dynamic zone
-   must increment the zone SOA serial number when an update occurs or
-   before the next retrieval of the SOA.
-
-1.2 - Overview of DNS Transaction Security
-
-   Exchanges of DNS messages which include TSIG [RFC2845] or SIG(0)
-   [RFC2535, RFC2931] records allow two DNS entities to authenticate DNS
-   requests and responses sent between them.  A TSIG MAC (message
-   authentication code) is derived from a shared secret, and a SIG(0) is
-   generated from a private key whose public counterpart is stored in
-   DNS.  In both cases, a record containing the message signature/MAC is
-   included as the final resource record in a DNS message.  Keyed
-   hashes, used in TSIG, are inexpensive to calculate and verify.
-   Public key encryption, as used in SIG(0), is more scalable as the
-   public keys are stored in DNS.
-
-1.3 - Comparison of data authentication and message authentication
-
-   Message based authentication, using TSIG or SIG(0), provides
-   protection for the entire message with a single signing and single
-   verification which, in the case of TSIG, is a relatively inexpensive
-   MAC creation and check.  For update requests, this signature can
-   establish, based on policy or key negotiation, the authority to make
-   the request.
-
-   DNSSEC SIG records can be used to protect the integrity of individual
-   RRs or RRsets in a DNS message with the authority of the zone owner.
-   However, this cannot sufficiently protect the dynamic update request.
-
-   Using SIG records to secure RRsets in an update request is
-   incompatible with the design of update, as described below, and would
-   in any case require multiple expensive public key signatures and
-   verifications.
-
-
-
-
-
-
-Wellington                  Standards Track                     [Page 2]
-
-RFC 3007                 Secure Dynamic Update             November 2000
-
-
-   SIG records do not cover the message header, which includes record
-   counts.  Therefore, it is possible to maliciously insert or remove
-   RRsets in an update request without causing a verification failure.
-
-   If SIG records were used to protect the prerequisite section, it
-   would be impossible to determine whether the SIGs themselves were a
-   prerequisite or simply used for validation.
-
-   In the update section of an update request, signing requests to add
-   an RRset is straightforward, and this signature could be permanently
-   used to protect the data, as specified in [RFC2535].  However, if an
-   RRset is deleted, there is no data for a SIG to cover.
-
-1.4 - Data and message signatures
-
-   As specified in [RFC3008], the DNSSEC validation process performed by
-   a resolver MUST NOT process any non-zone keys unless local policy
-   dictates otherwise.  When performing secure dynamic update, all zone
-   data modified in a signed zone MUST be signed by a relevant zone key.
-   This completely disassociates authentication of an update request
-   from authentication of the data itself.
-
-   The primary usefulness of host and user keys, with respect to DNSSEC,
-   is to authenticate messages, including dynamic updates.  Thus, host
-   and user keys MAY be used to generate SIG(0) records to authenticate
-   updates and MAY be used in the TKEY [RFC2930] process to generate
-   TSIG shared secrets.  In both cases, no SIG records generated by
-   non-zone keys will be used in a DNSSEC validation process unless
-   local policy dictates.
-
-   Authentication of data, once it is present in DNS, only involves
-   DNSSEC zone keys and signatures generated by them.
-
-1.5 - Signatory strength
-
-   [RFC2535, section 3.1.2] defines the signatory field of a key as the
-   final 4 bits of the flags field, but does not define its value.  This
-   proposal leaves this field undefined.  Updating [RFC2535], this field
-   SHOULD be set to 0 in KEY records, and MUST be ignored.
-
-2 - Authentication
-
-   TSIG or SIG(0) records MUST be included in all secure dynamic update
-   messages.  This allows the server to verifiably determine the
-   originator of a message.  If the message contains authentication in
-   the form of a SIG(0), the identity of the sender (that is, the
-   principal) is the owner of the KEY RR that generated the SIG(0).  If
-   the message contains a TSIG generated by a statically configured
-
-
-
-Wellington                  Standards Track                     [Page 3]
-
-RFC 3007                 Secure Dynamic Update             November 2000
-
-
-   shared secret, the principal is the same as or derived from the
-   shared secret name.  If the message contains a TSIG generated by a
-   dynamically configured shared secret, the principal is the same as
-   the one that authenticated the TKEY process; if the TKEY process was
-   unauthenticated, no information is known about the principal, and the
-   associated TSIG shared secret MUST NOT be used for secure dynamic
-   update.
-
-   SIG(0) signatures SHOULD NOT be generated by zone keys, since
-   transactions are initiated by a host or user, not a zone.
-
-   DNSSEC SIG records (other than SIG(0)) MAY be included in an update
-   message, but MUST NOT be used to authenticate the update request.
-
-   If an update fails because it is signed with an unauthorized key, the
-   server MUST indicate failure by returning a message with RCODE
-   REFUSED.  Other TSIG, SIG(0), or dynamic update errors are returned
-   as specified in the appropriate protocol description.
-
-3 - Policy
-
-   All policy is configured by the zone administrator and enforced by
-   the zone's primary name server.  Policy dictates the authorized
-   actions that an authenticated principal can take.  Policy checks are
-   based on the principal and the desired action, where the principal is
-   derived from the message signing key and applied to dynamic update
-   messages signed with that key.
-
-   The server's policy defines criteria which determine if the key used
-   to sign the update is permitted to perform the requested updates.  By
-   default, a principal MUST NOT be permitted to make any changes to
-   zone data; any permissions MUST be enabled though configuration.
-
-   The policy is fully implemented in the primary zone server's
-   configuration for several reasons.  This removes limitations imposed
-   by encoding policy into a fixed number of bits (such as the KEY RR's
-   signatory field).  Policy is only relevant in the server applying it,
-   so there is no reason to expose it.  Finally, a change in policy or a
-   new type of policy should not affect the DNS protocol or data format,
-   and should not cause interoperability failures.
-
-3.1 - Standard policies
-
-   Implementations SHOULD allow access control policies to use the
-   principal as an authorization token, and MAY also allow policies to
-   grant permission to a signed message regardless of principal.
-
-
-
-
-
-Wellington                  Standards Track                     [Page 4]
-
-RFC 3007                 Secure Dynamic Update             November 2000
-
-
-   A common practice would be to restrict the permissions of a principal
-   by domain name.  That is, a principal could be permitted to add,
-   delete, or modify entries corresponding to one or more domain names.
-   Implementations SHOULD allow per-name access control, and SHOULD
-   provide a concise representation of the principal's own name, its
-   subdomains, and all names in the zone.
-
-   Additionally, a server SHOULD allow restricting updates by RR type,
-   so that a principal could add, delete, or modify specific record
-   types at certain names.  Implementations SHOULD allow per-type access
-   control, and SHOULD provide concise representations of all types and
-   all "user" types, where a user type is defined as one that does not
-   affect the operation of DNS itself.
-
-3.1.1 - User types
-
-   User types include all data types except SOA, NS, SIG, and NXT.  SOA
-   and NS records SHOULD NOT be modified by normal users, since these
-   types create or modify delegation points.  The addition of SIG
-   records can lead to attacks resulting in additional workload for
-   resolvers, and the deletion of SIG records could lead to extra work
-   for the server if the zone SIG was deleted.  Note that these records
-   are not forbidden, but not recommended for normal users.
-
-   NXT records MUST NOT be created, modified, or deleted by dynamic
-   update, as their update may cause instability in the protocol.  This
-   is an update to RFC 2136.
-
-   Issues concerning updates of KEY records are discussed in the
-   Security Considerations section.
-
-3.2 - Additional policies
-
-   Users are free to implement any policies.  Policies may be as
-   specific or general as desired, and as complex as desired.  They may
-   depend on the principal or any other characteristics of the signed
-   message.
-
-4 - Interaction with DNSSEC
-
-   Although this protocol does not change the way updates to secure
-   zones are processed, there are a number of issues that should be
-   clarified.
-
-
-
-
-
-
-
-
-Wellington                  Standards Track                     [Page 5]
-
-RFC 3007                 Secure Dynamic Update             November 2000
-
-
-4.1 - Adding SIGs
-
-   An authorized update request MAY include SIG records with each RRset.
-   Since SIG records (except SIG(0) records) MUST NOT be used for
-   authentication of the update message, they are not required.
-
-   If a principal is authorized to update SIG records and there are SIG
-   records in the update, the SIG records are added without
-   verification.  The server MAY examine SIG records and drop SIGs with
-   a temporal validity period in the past.
-
-4.2 - Deleting SIGs
-
-   If a principal is authorized to update SIG records and the update
-   specifies the deletion of SIG records, the server MAY choose to
-   override the authority and refuse the update.  For example, the
-   server may allow all SIG records not generated by a zone key to be
-   deleted.
-
-4.3 - Non-explicit updates to SIGs
-
-   If the updated zone is secured, the RRset affected by an update
-   operation MUST, at the completion of the update, be signed in
-   accordance with the zone's signing policy.  This will usually require
-   one or more SIG records to be generated by one or more zone keys
-   whose private components MUST be online [RFC3008].
-
-   When the contents of an RRset are updated, the server MAY delete all
-   associated SIG records, since they will no longer be valid.
-
-4.4 - Effects on the zone
-
-   If any changes are made, the server MUST, if necessary, generate a
-   new SOA record and new NXT records, and sign these with the
-   appropriate zone keys.  Changes to NXT records by secure dynamic
-   update are explicitly forbidden.  SOA updates are allowed, since the
-   maintenance of SOA parameters is outside of the scope of the DNS
-   protocol.
-
-5 - Security Considerations
-
-   This document requires that a zone key and possibly other
-   cryptographic secret material be held in an on-line, network-
-   connected host, most likely a name server.  This material is at the
-   mercy of host security to remain a secret.  Exposing this secret puts
-   DNS data at risk of masquerade attacks.  The data at risk is that in
-   both zones served by the machine and delegated from this machine.
-
-
-
-
-Wellington                  Standards Track                     [Page 6]
-
-RFC 3007                 Secure Dynamic Update             November 2000
-
-
-   Allowing updates of KEY records may lead to undesirable results,
-   since a principal may be allowed to insert a public key without
-   holding the private key, and possibly masquerade as the key owner.
-
-6 - Acknowledgements
-
-   The author would like to thank the following people for review and
-   informative comments (in alphabetical order):
-
-   Harald Alvestrand
-   Donald Eastlake
-   Olafur Gudmundsson
-   Andreas Gustafsson
-   Bob Halley
-   Stuart Kwan
-   Ed Lewis
-
-7 - References
-
-   [RFC1034]  Mockapetris, P., "Domain Names - Concepts and Facilities",
-              STD 13, RFC 1034, November 1987.
-
-   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
-              Specification", STD 13, RFC 1035, November 1987.
-
-   [RFC2136]  Vixie (Ed.), P., Thomson, S., Rekhter, Y. and J. Bound,
-              "Dynamic Updates in the Domain Name System", RFC 2136,
-              April 1997.
-
-   [RFC2137]  Eastlake, D., "Secure Domain Name System Dynamic Update",
-              RFC 2137, April 1997.
-
-   [RFC2535]  Eastlake, G., "Domain Name System Security Extensions",
-              RFC 2535, March 1999.
-
-   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D. and B.
-              Wellington, "Secret Key Transaction Signatures for DNS
-              (TSIG)", RFC 2845, May 2000.
-
-   [RFC2930]  Eastlake, D., "Secret Key Establishment for DNS (TKEY
-              RR)", RFC 2930, September 2000.
-
-   [RFC2931]  Eastlake, D., "DNS Request and Transaction Signatures
-              (SIG(0)s)", RFC 2931, September 2000.
-
-   [RFC3008]  Wellington, B., "Domain Name System Security (DNSSEC)
-              Signing Authority", RFC 3008, November 2000.
-
-
-
-
-Wellington                  Standards Track                     [Page 7]
-
-RFC 3007                 Secure Dynamic Update             November 2000
-
-
-8 - Author's Address
-
-   Brian Wellington
-   Nominum, Inc.
-   950 Charter Street
-   Redwood City, CA 94063
-
-   Phone: +1 650 381 6022
-   EMail: Brian.Wellington@nominum.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wellington                  Standards Track                     [Page 8]
-
-RFC 3007                 Secure Dynamic Update             November 2000
-
-
-9.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wellington                  Standards Track                     [Page 9]
-
diff --git a/contrib/bind9/doc/rfc/rfc3008.txt b/contrib/bind9/doc/rfc/rfc3008.txt
deleted file mode 100644
index 08a4a8f..0000000
--- a/contrib/bind9/doc/rfc/rfc3008.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                      B. Wellington
-Request for Comments: 3008                                       Nominum
-Updates: 2535                                              November 2000
-Category: Standards Track
-
-
-         Domain Name System Security (DNSSEC) Signing Authority
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-Abstract
-
-   This document proposes a revised model of Domain Name System Security
-   (DNSSEC) Signing Authority.  The revised model is designed to clarify
-   earlier documents and add additional restrictions to simplify the
-   secure resolution process.  Specifically, this affects the
-   authorization of keys to sign sets of records.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [RFC2119].
-
-1 - Introduction
-
-   This document defines additional restrictions on DNSSEC signatures
-   (SIG) records relating to their authority to sign associated data.
-   The intent is to establish a standard policy followed by a secure
-   resolver; this policy can be augmented by local rules.  This builds
-   upon [RFC2535], updating section 2.3.6 of that document.
-
-   The most significant change is that in a secure zone, zone data is
-   required to be signed by the zone key.
-
-   Familiarity with the DNS system [RFC1034, RFC1035] and the DNS
-   security extensions [RFC2535] is assumed.
-
-
-
-
-
-
-Wellington                  Standards Track                     [Page 1]
-
-RFC 3008                DNSSEC Signing Authority           November 2000
-
-
-2 - The SIG Record
-
-   A SIG record is normally associated with an RRset, and "covers" (that
-   is, demonstrates the authenticity and integrity of) the RRset.  This
-   is referred to as a "data SIG".  Note that there can be multiple SIG
-   records covering an RRset, and the same validation process should be
-   repeated for each of them.  Some data SIGs are considered "material",
-   that is, relevant to a DNSSEC capable resolver, and some are
-   "immaterial" or "extra-DNSSEC", as they are not relevant to DNSSEC
-   validation.  Immaterial SIGs may have application defined roles.  SIG
-   records may exist which are not bound to any RRset; these are also
-   considered immaterial.  The validation process determines which SIGs
-   are material; once a SIG is shown to be immaterial, no other
-   validation is necessary.
-
-   SIGs may also be used for transaction security.  In this case, a SIG
-   record with a type covered field of 0 is attached to a message, and
-   is used to protect message integrity.  This is referred to as a
-   SIG(0) [RFC2535, RFC2931].
-
-   The following sections define requirements for all of the fields of a
-   SIG record.  These requirements MUST be met in order for a DNSSEC
-   capable resolver to process this signature.  If any of these
-   requirements are not met, the SIG cannot be further processed.
-   Additionally, once a KEY has been identified as having generated this
-   SIG, there are requirements that it MUST meet.
-
-2.1 - Type Covered
-
-   For a data SIG, the type covered MUST be the same as the type of data
-   in the associated RRset.  For a SIG(0), the type covered MUST be 0.
-
-2.2 - Algorithm Number
-
-   The algorithm specified in a SIG MUST be recognized by the client,
-   and it MUST be an algorithm that has a defined SIG rdata format.
-
-2.3 - Labels
-
-   The labels count MUST be less than or equal to the number of labels
-   in the SIG owner name, as specified in [RFC2535, section 4.1.3].
-
-2.4 - Original TTL
-
-   The original TTL MUST be greater than or equal to the TTL of the SIG
-   record itself, since the TTL cannot be increased by intermediate
-   servers.  This field can be ignored for SIG(0) records.
-
-
-
-
-Wellington                  Standards Track                     [Page 2]
-
-RFC 3008                DNSSEC Signing Authority           November 2000
-
-
-2.5 - Signature Expiration and Inception
-
-   The current time at the time of validation MUST lie within the
-   validity period bounded by the inception and expiration times.
-
-2.6 - Key Tag
-
-   There are no restrictions on the Key Tag field, although it is
-   possible that future algorithms will impose constraints.
-
-2.7 - Signer's Name
-
-   The signer's name field of a data SIG MUST contain the name of the
-   zone to which the data and signature belong.  The combination of
-   signer's name, key tag, and algorithm MUST identify a zone key if the
-   SIG is to be considered material.  The only exception that the
-   signer's name field in a SIG KEY at a zone apex SHOULD contain the
-   parent zone's name, unless the KEY set is self-signed.  This document
-   defines a standard policy for DNSSEC validation; local policy may
-   override the standard policy.
-
-   There are no restrictions on the signer field of a SIG(0) record.
-   The combination of signer's name, key tag, and algorithm MUST
-   identify a key if this SIG(0) is to be processed.
-
-2.8 - Signature
-
-   There are no restrictions on the signature field.  The signature will
-   be verified at some point, but does not need to be examined prior to
-   verification unless a future algorithm imposes constraints.
-
-3 - The Signing KEY Record
-
-   Once a signature has been examined and its fields validated (but
-   before the signature has been verified), the resolver attempts to
-   locate a KEY that matches the signer name, key tag, and algorithm
-   fields in the SIG.  If one is not found, the SIG cannot be verified
-   and is considered immaterial.  If KEYs are found, several fields of
-   the KEY record MUST have specific values if the SIG is to be
-   considered material and authorized.  If there are multiple KEYs, the
-   following checks are performed on all of them, as there is no way to
-   determine which one generated the signature until the verification is
-   performed.
-
-
-
-
-
-
-
-
-Wellington                  Standards Track                     [Page 3]
-
-RFC 3008                DNSSEC Signing Authority           November 2000
-
-
-3.1 - Type Flags
-
-   The signing KEY record MUST have a flags value of 00 or 01
-   (authentication allowed, confidentiality optional) [RFC2535, 3.1.2].
-   A DNSSEC resolver MUST only trust signatures generated by keys that
-   are permitted to authenticate data.
-
-3.2 - Name Flags
-
-   The interpretation of this field is considerably different for data
-   SIGs and SIG(0) records.
-
-3.2.1 - Data SIG
-
-   If the SIG record covers an RRset, the name type of the associated
-   KEY MUST be 01 (zone) [RFC2535, 3.1.2].  This updates RFC 2535,
-   section 2.3.6.  The DNSSEC validation process performed by a resolver
-   MUST ignore all keys that are not zone keys unless local policy
-   dictates otherwise.
-
-   The primary reason that RFC 2535 allows host and user keys to
-   generate material DNSSEC signatures is to allow dynamic update
-   without online zone keys; that is, avoid storing private keys in an
-   online server.  The desire to avoid online signing keys cannot be
-   achieved, though, because they are necessary to sign NXT and SOA sets
-   [RFC3007].  These online zone keys can sign any incoming data.
-   Removing the goal of having no online keys removes the reason to
-   allow host and user keys to generate material signatures.
-
-   Limiting material signatures to zone keys simplifies the validation
-   process.  The length of the verification chain is bounded by the
-   name's label depth.  The authority of a key is clearly defined; a
-   resolver does not need to make a potentially complicated decision to
-   determine whether a key has the proper authority to sign data.
-
-   Finally, there is no additional flexibility granted by allowing
-   host/user key generated material signatures.  As long as users and
-   hosts have the ability to authenticate update requests to the primary
-   zone server, signatures by zone keys are sufficient to protect the
-   integrity of the data to the world at large.
-
-3.2.2 - SIG(0)
-
-   If the SIG record is a SIG(0) protecting a message, the name type of
-   the associated KEY SHOULD be 00 (user) or 10 (host/entity).
-   Transactions are initiated by a host or user, not a zone, so zone
-   keys SHOULD not generate SIG(0) records.
-
-
-
-
-Wellington                  Standards Track                     [Page 4]
-
-RFC 3008                DNSSEC Signing Authority           November 2000
-
-
-   A client is either explicitly executed by a user or on behalf of a
-   host, therefore the name type of a SIG(0) generated by a client
-   SHOULD be either user or host.  A nameserver is associated with a
-   host, and its use of SIG(0) is not associated with a particular zone,
-   so the name type of a SIG(0) generated by a nameserver SHOULD be
-   host.
-
-3.3 - Signatory Flags
-
-   This document does not assign any values to the signatory field, nor
-   require any values to be present.
-
-3.4 - Protocol
-
-   The signing KEY record MUST have a protocol value of 3 (DNSSEC) or
-   255 (ALL).  If a key is not specified for use with DNSSEC, a DNSSEC
-   resolver MUST NOT trust any signature that it generates.
-
-3.5 - Algorithm Number
-
-   The algorithm field MUST be identical to that of the generated SIG
-   record, and MUST meet all requirements for an algorithm value in a
-   SIG record.
-
-4 - Security Considerations
-
-   This document defines a standard baseline for a DNSSEC capable
-   resolver.  This is necessary for a thorough security analysis of
-   DNSSEC, if one is to be done.
-
-   Specifically, this document places additional restrictions on SIG
-   records that a resolver must validate before the signature can be
-   considered worthy of DNSSEC trust.  This simplifies the protocol,
-   making it more robust and able to withstand scrutiny by the security
-   community.
-
-5 - Acknowledgements
-
-   The author would like to thank the following people for review and
-   informative comments (in alphabetical order):
-
-   Olafur Gudmundsson
-   Ed Lewis
-
-
-
-
-
-
-
-
-Wellington                  Standards Track                     [Page 5]
-
-RFC 3008                DNSSEC Signing Authority           November 2000
-
-
-6 - References
-
-   [RFC1034]  Mockapetris, P., "Domain Names - Concepts and Facilities",
-              STD 13, RFC 1034, November 1987.
-
-   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
-              Specification", STD 13, RFC 1035, November 1987.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2136]  Vixie (Ed.), P., Thomson, S., Rekhter, Y. and J. Bound,
-              "Dynamic Updates in the Domain Name System", RFC 2136,
-              April 1997.
-
-   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
-              RFC 2535, March 1999.
-
-   [RFC2931]  Eastlake, D., "DNS Request and Transaction Signatures
-              (SIG(0)s )", RFC 2931, September 2000.
-
-   [RFC3007]      Wellington, B., "Simple Secure Domain Name System
-              (DNS) Dynamic Update", RFC 3007, November 2000.
-
-7 - Author's Address
-
-   Brian Wellington
-   Nominum, Inc.
-   950 Charter Street
-   Redwood City, CA 94063
-
-   Phone: +1 650 381 6022
-   EMail: Brian.Wellington@nominum.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wellington                  Standards Track                     [Page 6]
-
-RFC 3008                DNSSEC Signing Authority           November 2000
-
-
-8  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wellington                  Standards Track                     [Page 7]
-
diff --git a/contrib/bind9/doc/rfc/rfc3071.txt b/contrib/bind9/doc/rfc/rfc3071.txt
deleted file mode 100644
index 2c4d52f..0000000
--- a/contrib/bind9/doc/rfc/rfc3071.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         J. Klensin
-Request for Comments: 3071                                 February 2001
-Category: Informational
-
-
-      Reflections on the DNS, RFC 1591, and Categories of Domains
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-Abstract
-
-   RFC 1591, "Domain Name System Structure and Delegation", laid out the
-   basic administrative design and principles for the allocation and
-   administration of domains, from the top level down.  It was written
-   before the introduction of the world wide web (WWW) and rapid growth
-   of the Internet put significant market, social, and political
-   pressure on domain name allocations.  In recent years, 1591 has been
-   cited by all sides in various debates, and attempts have been made by
-   various bodies to update it or adjust its provisions, sometimes under
-   pressures that have arguably produced policies that are less well
-   thought out than the original.  Some of those efforts have begun from
-   misconceptions about the provisions of 1591 or the motivation for
-   those provisions.  The current directions of the Internet Corporation
-   for Assigned Names and Numbers (ICANN) and other groups who now
-   determine the Domain Name System (DNS) policy directions appear to be
-   drifting away from the policies and philosophy of 1591.  This
-   document is being published primarily for historical context and
-   comparative purposes, essentially to document some thoughts about how
-   1591 might have been interpreted and adjusted by the Internet
-   Assigned Numbers Authority (IANA) and ICANN to better reflect today's
-   world while retaining characteristics and policies that have proven
-   to be effective in supporting Internet growth and stability.  An
-   earlier variation of this memo was submitted to ICANN as a comment on
-   its evolving Top-level Domain (TLD) policies.
-
-
-
-
-
-
-
-
-
-Klensin                      Informational                      [Page 1]
-
-RFC 3071          Reflections on the DNS and RFC 1591      February 2001
-
-
-1.  Introduction
-
-   RFC 1591 [1] has been heavily discussed and referenced in the last
-   year or two, especially in discussions within ICANN and its
-   predecessors about the creation, delegation, and management of top-
-   level domains.  In particular, the ICANN Domain Name Supporting
-   Organization (DNSO), and especially its ccTLD constituency, have been
-   the home of many discussions in which 1591 and interpretations of it
-   have been cited in support of a variety of sometimes-contradictory
-   positions.  During that period, other discussions have gone on to try
-   to reconstruct the thinking that went into RFC 1591.  Those in turn
-   have led me and others to muse on how that original thinking might
-   relate to some of the issues being raised.  1591 is, I believe, one
-   of Jon Postel's masterpieces, drawing together very different
-   philosophies (e.g., his traditional view that people are basically
-   reasonable and will do the right thing if told what it is with some
-   stronger mechanisms when that model is not successful) into a single
-   whole.
-
-   RFC 1591 was written in the context of the assumption that what it
-   described as generic TLDs would be bound to policies and categories
-   of registration (see the "This domain is intended..."  text in
-   section 2) while ccTLDs were expected to be used primarily to support
-   users and uses within and for a country and its residents.  The
-   notion that different domains would be run in different ways --albeit
-   within the broad contexts of "public service on behalf of the
-   Internet community" and "trustee... for the global Internet
-   community"-- was considered a design feature and a safeguard against
-   a variety of potential abuses.  Obviously the world has changed in
-   many ways in the seven or eight years since 1591 was written.  In
-   particular, the Internet has become more heavily used and, because
-   the design of the world wide web has put domain names in front of
-   users, top-level domain names and registrations in them have been
-   heavily in demand: not only has the number of hosts increased
-   dramatically during that time, but the ratio between registered
-   domain names and physical hosts has increased very significantly.
-
-   The issues 1591 attempted to address when it was written and those we
-   face today have not changed significantly in principle.  But one
-   alternative to present trends would be to take a step back to refine
-   it into a model that can function effectively today.  Therefore, it
-   may be useful to try to reconstruct 1591's principles and think about
-   their applicability today as a model that could continue to be
-   applied: not because it is historically significant, but because many
-   of its elements have proven to work reasonably well, even in
-   difficult situations.  In particular, for many domains (some in
-   1591's "generic" list and others in its "country code" category) the
-   notion of "public service" --expected then to imply being carried out
-
-
-
-Klensin                      Informational                      [Page 2]
-
-RFC 3071          Reflections on the DNS and RFC 1591      February 2001
-
-
-   at no or minimal cost to the users, not merely on a non-profit
-   basis-- has yielded to profitability calculations.  And, in most of
-   the rest, considerations of at least calculating and recovering costs
-   have crept in.  While many of us feel some nostalgia for the old
-   system, it is clear that its days are waning if not gone: perhaps the
-   public service notions as understood when 1591 was written just don't
-   scale to rapid internet growth and very large numbers of
-   yregistrations.
-
-   In particular, some ccTLDs have advertised for registrations outside
-   the designated countries (or other entities), while others have made
-   clear decisions to allow registrations by non-nationals.  These
-   decisions and others have produced protests from many sides,
-   suggesting, in turn, that a recategorization is in order.  For
-   example, we have heard concerns by governments and managers of
-   traditional, "public service", in-country, ccTLDs about excessive
-   ICANN interference and fears of being forced to conform to
-   internationally-set policies for dispute resolution when their
-   domestic ones are considered more appropriate.  We have also heard
-   concerns from registrars and operators of externally-marketed ccTLDs
-   about unreasonable government interference and from gTLD registrars
-   and registries about unreasonable competition from aggressively
-   marketed ccTLDs.  The appropriate distinction is no longer between
-   what RFC 1591 described as "generic" TLDs (but which were really
-   intended to be "purpose-specific", a term I will use again below) and
-   ccTLDs but among:
-
-      (i) true "generic" TLDs, in which any registration is acceptable
-      and, ordinarily, registrations from all sources are actively
-      promoted.  This list currently includes (the formerly purpose-
-      specific) COM, NET, and ORG, and some ccTLDs.  There have been
-      proposals from time to time for additional TLDs of this variety in
-      which, as with COM (and, more recently, NET and ORG) anyone
-      (generally subject only to name conflicts and national law) could
-      register who could pay the fees.
-
-      (ii) purpose-specific TLDs, in which registration is accepted only
-      from organizations or individuals meeting particular
-      qualifications, but where those qualifications are not tied to
-      national boundaries.  This list currently includes INT, EDU, the
-      infrastructure domain ARPA, and, arguably, the specialized US
-      Government TLDs MIL and GOV.  There have been proposals from time
-      to time for other international TLDs of this variety, e.g., for
-      medical entities such as physicians and hospitals and for museums.
-      ICANN has recently approved several TLDs of this type and
-      describes them as "sponsored" TLDs.
-
-
-
-
-
-Klensin                      Informational                      [Page 3]
-
-RFC 3071          Reflections on the DNS and RFC 1591      February 2001
-
-
-      (iii) Country domains, operated according to the original
-      underlying assumptions of 1591, i.e., registrants are largely
-      expected to be people or other entities within the country.  While
-      external registrations might be accepted by some of these, the
-      country does not aggressively advertise for such registrations,
-      nor does anyone expect to derive significant fee revenue from
-      them.  All current domains in this category are ccTLDs, but not
-      all ccTLDs are in this category.
-
-   These categories are clearly orthogonal to the association between
-   the use of the IS 3166-1 registered code list [2] and two-letter
-   "country" domain names.  If that relationship is to be maintained
-   (and I believe it is desirable), the only inherent requirement is
-   that no two-letter TLDs be created except from that list (in order to
-   avoid future conflicts).  ICANN should control the allocation and
-   delegation of TLDs using these, and other, criteria, but only
-   registered 3166-1 two letter codes should be used as two-letter TLDs.
-
-2. Implications of the Categories
-
-   If we had adopted this type of three-way categorization and could
-   make it work, I believe it would have presented several opportunities
-   for ICANN and the community more generally to reduce controversies
-   and move forward.  Of course, there will be cases where the
-   categorization of a particular domain and its operating style will
-   not be completely clear-cut (see section 3, below).  But having ICANN
-   work out procedures for dealing with those (probably few) situations
-   appears preferable to strategies that would tend to propel ICANN into
-   areas that are beyond its competence or that might require
-   significant expansion of its mandate.
-
-   First, the internally-operated ccTLDs (category iii above) should not
-   be required to have much interaction with ICANN or vice versa.  Once
-   a domain of this sort is established and delegated, and assuming that
-   the "admin contact in the country" rule is strictly observed, the
-   domain should be able to function effectively without ICANN
-   intervention or oversight.  In particular, while a country might
-   choose to adopt the general ICANN policies about dispute resolution
-   or name management, issues that arise in these areas might equally
-   well be dealt with exclusively under applicable national laws.  If a
-   domain chooses to use ICANN services that cost resources to provide,
-   it should contribute to ICANN's support, but, if it does not, ICANN
-   should not presume to charge it for other than a reasonable fraction
-   of the costs to ICANN of operating the root, root servers, and any
-   directory systems that are generally agreed upon to be necessary and
-   in which the domain participates.
-
-
-
-
-
-Klensin                      Informational                      [Page 4]
-
-RFC 3071          Reflections on the DNS and RFC 1591      February 2001
-
-
-   By contrast, ccTLDs operated as generic domains ought to be treated
-   as generic domains.  ICANN dispute resolution and name management
-   policies and any special rules developed to protect the Internet
-   public in multiple registrar or registry situations should reasonably
-   apply.
-
-3.  Telling TLD types apart
-
-   If appropriate policies are adopted, ccTLDs operated as generic
-   domains (category (i) above) and those operated as country domains
-   (category (iii) above) ought to be able to be self-identified.  There
-   are several criteria that could be applied to make this
-   determination.  For example, either a domain is aggressively seeking
-   outside registrations or it is not and either the vast majority of
-   registrants in a domain are in-country or they are not.  One could
-   also think of this as the issue of having some tangible level of
-   presence in the jurisdiction - e.g., is the administrative contact
-   subject, in practical terms, to the in-country laws, or are the
-   registration rules such that it is reasonably likely that a court in
-   the jurisdiction of the country associated with the domain can
-   exercise jurisdiction and enforce a judgment against the registrant.
-
-   One (fairly non-intrusive) rule ICANN might well impose on all top-
-   level domains is that they identify and publish the policies they
-   intend to use.  E.g., registrants in a domain that will use the laws
-   of one particular country to resolve disputes should have a
-   reasonable opportunity to understand those policies prior to
-   registration and to make other arrangements (e.g., to register
-   elsewhere) if that mechanism for dispute resolution is not
-   acceptable.  Giving IANA (as the root registrar) incorrect
-   information about the purpose and use of a domain should be subject
-   to challenge, and should be grounds for reviewing the appropriateness
-   of the domain delegation, just as not acting consistently and
-   equitably provides such grounds under the original provisions of RFC
-   1591.
-
-   In order to ensure the availability of accurate and up-to-date
-   registration information the criteria must be consistent, and
-   consistent with more traditional gTLDs, for all nominally country
-   code domains operating as generic TLDs.
-
-4. The role of ICANN in country domains
-
-   ICANN (and IANA) should, as described above, have as little
-   involvement as possible in the direction of true country [code]
-   domains (i.e., category (iii)).  There is no particular reason why
-
-
-
-
-
-Klensin                      Informational                      [Page 5]
-
-RFC 3071          Reflections on the DNS and RFC 1591      February 2001
-
-
-   these domains should be subject to ICANN regulation beyond the basic
-   principles of 1591 and associated arrangements needed to ensure
-   Internet interoperability and stability.
-
-   ICANN's avoiding such involvement strengthens it: the desirability of
-   avoiding collisions with national sovereignty, determinations about
-   government legitimacy, and the authority of someone purportedly
-   writing on behalf of a government, is as important today as it was
-   when 1591 was written.  The alternatives take us quickly from
-   "administration" into "internet governance" or, in the case of
-   determining which claimant is the legitimate government of a country,
-   "international relations", and the reasons for not moving in that
-   particular direction are legion.
-
-5. The role of governments
-
-   The history of IANA strategy in handling ccTLDs included three major
-   "things to avoid" considerations:
-
-      * Never get involved in determining which entities were countries
-        and which ones were not.
-
-      * Never get involved in determining who was, or was not, the
-        legitimate government of a country.  And, more generally, avoid
-        deciding what entity --government, religion, commercial,
-        academic, etc.-- has what legitimacy or rights.
-
-      * If possible, never become involved in in-country disputes.
-        Instead, very strongly encourage internal parties to work
-        problems out among themselves.  At most, adopt a role as
-        mediator and educator, rather than judge, unless abuses are very
-        clear and clearly will not be settled by any internal mechanism.
-
-   All three considerations were obviously intended to avoid IANA's
-   being dragged into a political morass in which it had (and, I
-   suggest, has) no competence to resolve the issues and could only get
-   bogged down.  The first consideration was the most visible (and the
-   easiest) and was implemented by strict and careful adherence (see
-   below) to the ISO 3166 registered Country Code list.  If an entity
-   had a code, it was eligible to be registered with a TLD (although
-   IANA was free to apply additional criteria-most of them stated in
-   1591).  If it did not, there were no exceptions: the applicant's only
-   recourse was a discussion with the 3166 Registration Authority (now
-   Maintenance Agency, often known just as "3166/MA") or the UN
-   Statistical Office (now Statistics Bureau), not with IANA.
-
-
-
-
-
-
-Klensin                      Informational                      [Page 6]
-
-RFC 3071          Reflections on the DNS and RFC 1591      February 2001
-
-
-   There are actually five ccTLD exceptions to the strict rules.  One,
-   "UK", is historical: it predates the adoption of ISO 3166 for this
-   purpose.  The others --Ascension Island, Guernsey, Isle of Man, and
-   Jersey --are arguably, at least in retrospect, just mistakes.
-   Regardless of the historical reasons (about which there has been much
-   speculation), it is almost certainly the case that the right way to
-   handle mistakes of this sort is to acknowledge them and move on,
-   rather than trying to use them as precedents to justify more
-   mistakes.
-
-   This, obviously, is also the argument against use of the "reserved"
-   list (technically internal to the 3166 maintenance activity, and not
-   part of the Standard): since IANA (or ICANN) can ask that a name be
-   placed on that list, there is no rule of an absolute determination by
-   an external organization.  Purported countries can come to ICANN,
-   insist on having delegations made and persuade ICANN to ask that the
-   names be reserved.  Then, since the reserved name would exist, they
-   could insist that the domain be delegated.  Worse, someone could use
-   another organization to request reservation of the name by 3166/MA;
-   once it was reserved, ICANN might be hard-pressed not to do the
-   delegation.  Of course, ICANN could (and probably would be forced to)
-   adopt additional criteria other than appearance on the "reserved
-   list" in order to delegate such domains.  But those criteria would
-   almost certainly be nearly equivalent to determining which applicants
-   were legitimate and stable enough to be considered a country, the
-   exact decision process that 1591 strove to avoid.
-
-   The other two considerations were more subtle and not always
-   successful: from time to time, both before and after the formal
-   policy shifted toward "governments could have their way", IANA
-   received letters from people purporting to be competent government
-   authorities asking for changes.  Some of them turned out later to not
-   have that authority or appropriate qualifications.  The assumption of
-   1591 itself was that, if the "administrative contact in country" rule
-   was strictly observed, as was the rule that delegation changes
-   requested by the administrative contact would be honored, then, if a
-   government _really_ wanted to assert itself, it could pressure the
-   administrative contact into requesting the changes it wanted, using
-   whatever would pass for due process in that country.  And the ability
-   to apply that process and pressure would effectively determine who
-   was the government and who wasn't, and would do so far more
-   effectively than any IANA evaluation of, e.g., whether the letterhead
-   on a request looked authentic (and far more safely for ICANN than
-   asking the opinion of any particular other government or selection of
-   governments).
-
-
-
-
-
-
-Klensin                      Informational                      [Page 7]
-
-RFC 3071          Reflections on the DNS and RFC 1591      February 2001
-
-
-   Specific language in 1591 permitted IANA to adopt a "work it out
-   yourselves; if we have to decide, we will strive for a solution that
-   is not satisfactory to any party" stance.  That approach was used
-   successfully, along with large doses of education, on many occasions
-   over the years, to avoid IANA's having to assume the role of judge
-   between conflicting parties.
-
-   Similar principles could be applied to the boundary between country-
-   code-based generic TLDs and country domains.  Different countries,
-   under different circumstances, might prefer to operate the ccTLD
-   either as a national service or as a profit center where the
-   "customers" were largely external.  Whatever decisions were made
-   historically, general Internet stability argues that changes should
-   not be made lightly.  At the same time, if a government wishes to
-   make a change, the best mechanism for doing so is not to involve
-   ICANN in a potential determination of legitimacy (or even to have
-   ICANN's Government Advisory Committee (GAC) try to formally make that
-   decision for individual countries) but for the relevant government to
-   use its own procedures to persuade the administrative contact to
-   request the change and for IANA to promptly and efficiently carry out
-   requests made by administrative contacts.
-
-6. Implications for the current ICANN DNSO structure.
-
-   The arguments by some of the ccTLD administrators that they are
-   different from the rest of the ICANN and DNSO structures are (in this
-   model) correct: they are different.  The ccTLDs that are operating as
-   generic TLDs should be separated from the ccTLD constituency and
-   joined to the gTLD constituency.  The country ccTLDs should be
-   separated from ICANN's immediate Supporting Organization structure,
-   and operate in a parallel and advisory capacity to ICANN, similar to
-   the arrangements used with the GAC.  The DNSO and country TLDs should
-   not be required to interact with each other except on a mutually
-   voluntary basis and, if ICANN needs interaction or advice from some
-   of all of those TLDs, it would be more appropriate to get it in the
-   form of an advisory body like the GAC rather than as DNSO
-   constituency.
-
-7. References
-
-   [1] Postel, J., "Domain Name System Structure and Delegation", RFC
-       1591, March 1994.
-
-   [2] ISO 3166. ISO 3166-1. Codes for the representation of names of
-       countries and their subdivisions - Part 1: Country codes (1997).
-
-
-
-
-
-
-Klensin                      Informational                      [Page 8]
-
-RFC 3071          Reflections on the DNS and RFC 1591      February 2001
-
-
-8. Acknowledgements and disclaimer
-
-   These reflections have been prepared in my individual capacity and do
-   not necessarily reflect the views of my past or present employers.
-   Several people, including Randy Bush, Theresa Swinehart, Zita Wenzel,
-   Geoff Huston, Havard Eidnes, and several anonymous reviewers, made
-   suggestions or offered editorial comments about earlier versions of
-   this document.  Cord Wischhoefer, of the ISO 3166/MA, was also kind
-   enough to look at the draft and supplied some useful details.  Those
-   comments contributed significantly to whatever clarity the document
-   has, but the author bears responsibility for the selection of
-   comments which were ultimately incorporated and the way in which the
-   conclusions were presented.
-
-9.  Security Considerations
-
-   This memo addresses the context for a set of administrative decisions
-   and procedures, and does not raise or address security issues.
-
-10. Author's Address
-
-   John C. Klensin
-   1770 Massachusetts Ave, Suite 322
-   Cambridge, MA 02140, USA
-
-   EMail: klensin@jck.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Klensin                      Informational                      [Page 9]
-
-RFC 3071          Reflections on the DNS and RFC 1591      February 2001
-
-
-11. Full Copyright Statement
-
-   Copyright (C) The Internet Society 2001. All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others provided that the above copyright notice and this paragraph
-   are included on all such copies.  However, this document itself may
-   not be modified in any way, such as by removing the copyright notice
-   or references to the Internet Society or other Internet
-   organizations, except as required to translate it into languages
-   other than English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR  IMPLIED, INCLUDING
-   BUT NOT  LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY  IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Klensin                      Informational                     [Page 10]
-
diff --git a/contrib/bind9/doc/rfc/rfc3090.txt b/contrib/bind9/doc/rfc/rfc3090.txt
deleted file mode 100644
index 08008f7..0000000
--- a/contrib/bind9/doc/rfc/rfc3090.txt
+++ /dev/null
@@ -1,619 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                           E. Lewis
-Request for Comments: 3090                                      NAI Labs
-Category: Standards Track                                     March 2001
-
-
-          DNS Security Extension Clarification on Zone Status
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-Abstract
-
-   The definition of a secured zone is presented, clarifying and
-   updating sections of RFC 2535.  RFC 2535 defines a zone to be secured
-   based on a per algorithm basis, e.g., a zone can be secured with RSA
-   keys, and not secured with DSA keys.  This document changes this to
-   define a zone to be secured or not secured regardless of the key
-   algorithm used (or not used).  To further simplify the determination
-   of a zone's status, "experimentally secure" status is deprecated.
-
-1 Introduction
-
-   Whether a DNS zone is "secured" or not is a question asked in at
-   least four contexts.  A zone administrator asks the question when
-   configuring a zone to use DNSSEC.  A dynamic update server asks the
-   question when an update request arrives, which may require DNSSEC
-   processing.  A delegating zone asks the question of a child zone when
-   the parent enters data indicating the status the child.  A resolver
-   asks the question upon receipt of data belonging to the zone.
-
-1.1 When a Zone's Status is Important
-
-   A zone administrator needs to be able to determine what steps are
-   needed to make the zone as secure as it can be.  Realizing that due
-   to the distributed nature of DNS and its administration, any single
-   zone is at the mercy of other zones when it comes to the appearance
-   of security.  This document will define what makes a zone qualify as
-   secure.
-
-
-
-
-Lewis                       Standards Track                     [Page 1]
-
-RFC 3090         DNS Security Extension on Zone Status        March 2001
-
-
-   A name server performing dynamic updates needs to know whether a zone
-   being updated is to have signatures added to the updated data, NXT
-   records applied, and other required processing.  In this case, it is
-   conceivable that the name server is configured with the knowledge,
-   but being able to determine the status of a zone by examining the
-   data is a desirable alternative to configuration parameters.
-
-   A delegating zone is required to indicate whether a child zone is
-   secured.  The reason for this requirement lies in the way in which a
-   resolver makes its own determination about a zone (next paragraph).
-   To shorten a long story, a parent needs to know whether a child
-   should be considered secured.  This is a two part question.  Under
-   what circumstances does a parent consider a child zone to be secure,
-   and how does a parent know if the child conforms?
-
-   A resolver needs to know if a zone is secured when the resolver is
-   processing data from the zone.  Ultimately, a resolver needs to know
-   whether or not to expect a usable signature covering the data.  How
-   this determination is done is out of the scope of this document,
-   except that, in some cases, the resolver will need to contact the
-   parent of the zone to see if the parent states that the child is
-   secured.
-
-1.2 Islands of Security
-
-   The goal of DNSSEC is to have each zone secured, from the root zone
-   and the top-level domains down the hierarchy to the leaf zones.
-   Transitioning from an unsecured DNS, as we have now, to a fully
-   secured - or "as much as will be secured" - tree will take some time.
-   During this time, DNSSEC will be applied in various locations in the
-   tree, not necessarily "top down."
-
-   For example, at a particular instant, the root zone and the "test."
-   TLD might be secured, but region1.test. might not be.  (For
-   reference, let's assume that region2.test. is secured.)  However,
-   subarea1.region1.test. may have gone through the process of becoming
-   secured, along with its delegations.  The dilemma here is that
-   subarea1 cannot get its zone keys properly signed as its parent zone,
-   region1, is not secured.
-
-   The colloquial phrase describing the collection of contiguous secured
-   zones at or below subarea1.region1.test. is an "island of security."
-   The only way in which a DNSSEC resolver will come to trust any data
-   from this island is if the resolver is pre-configured with the zone
-   key(s) for subarea1.region1.test., i.e., the root of the island of
-   security.  Other resolvers (not so configured) will recognize this
-   island as unsecured.
-
-
-
-
-Lewis                       Standards Track                     [Page 2]
-
-RFC 3090         DNS Security Extension on Zone Status        March 2001
-
-
-   An island of security begins with one zone whose public key is pre-
-   configured in resolvers.  Within this island are subzones which are
-   also secured.  The "bottom" of the island is defined by delegations
-   to unsecured zones.  One island may also be on top of another -
-   meaning that there is at least one unsecured zone between the bottom
-   of the upper island and the root of the lower secured island.
-
-   Although both subarea1.region1.test. and region2.test. have both been
-   properly brought to a secured state by the administering staff, only
-   the latter of the two is actually "globally" secured - in the sense
-   that all DNSSEC resolvers can and will verify its data.  The former,
-   subarea1, will be seen as secured by a subset of those resolvers,
-   just those appropriately configured.  This document refers to such
-   zones as being "locally" secured.
-
-   In RFC 2535, there is a provision for "certification authorities,"
-   entities that will sign public keys for zones such as subarea1.
-   There is another document, [RFC3008], that restricts this activity.
-   Regardless of the other document, resolvers would still need proper
-   configuration to be able to use the certification authority to verify
-   the data for the subarea1 island.
-
-1.2.1 Determining the closest security root
-
-   Given a domain, in order to determine whether it is secure or not,
-   the first step is to determine the closest security root.  The
-   closest security root is the top of an island of security whose name
-   has the most matching (in order from the root) right-most labels to
-   the given domain.
-
-   For example, given a name "sub.domain.testing.signed.exp.test.", and
-   given the secure roots "exp.test.", "testing.signed.exp.test." and
-   "not-the-same.xy.", the middle one is the closest.  The first secure
-   root shares 2 labels, the middle 4, and the last 0.
-
-   The reason why the closest is desired is to eliminate false senses of
-   insecurity because of a NULL key.  Continuing with the example, the
-   reason both "testing..." and "exp.test." are listed as secure root is
-   presumably because "signed.exp.test." is unsecured (has a NULL key).
-   If we started to descend from "exp.test." to our given domain
-   (sub...), we would encounter a NULL key and conclude that sub... was
-   unsigned.  However, if we descend from "testing..." and find keys
-   "domain...." then we can conclude that "sub..." is secured.
-
-   Note that this example assumes one-label deep zones, and assumes that
-   we do not configure overlapping islands of security.  To be clear,
-   the definition given should exclude "short.xy.test." from being a
-   closest security root for "short.xy." even though 2 labels match.
-
-
-
-Lewis                       Standards Track                     [Page 3]
-
-RFC 3090         DNS Security Extension on Zone Status        March 2001
-
-
-   Overlapping islands of security introduce no conceptually interesting
-   ideas and do not impact the protocol in anyway.  However, protocol
-   implementers are advised to make sure their code is not thrown for a
-   loop by overlaps.  Overlaps are sure to be configuration problems as
-   islands of security grow to encompass larger regions of the name
-   space.
-
-1.3 Parent Statement of Child Security
-
-   In 1.1 of this document, there is the comment "the parent states that
-   the child is secured."  This has caused quite a bit of confusion.
-
-   The need to have the parent "state" the status of a child is derived
-   from the following observation.  If you are looking to see if an
-   answer is secured, that it comes from an "island of security" and is
-   properly signed, you must begin at the (appropriate) root of the
-   island of security.
-
-   To find the answer you are inspecting, you may have to descend
-   through zones within the island of security.  Beginning with the
-   trusted root of the island, you descend into the next zone down.  As
-   you trust the upper zone, you need to get data from it about the next
-   zone down, otherwise there is a vulnerable point in which a zone can
-   be hijacked. When or if you reach a point of traversing from a
-   secured zone to an unsecured zone, you have left the island of
-   security and should conclude that the answer is unsecured.
-
-   However, in RFC 2535, section 2.3.4, these words seem to conflict
-   with the need to have the parent "state" something about a child:
-
-      There MUST be a zone KEY RR, signed by its superzone, for every
-      subzone if the superzone is secure.  This will normally appear in
-      the subzone and may also be included in the superzone.  But, in
-      the case of an unsecured subzone which can not or will not be
-      modified to add any security RRs, a KEY declaring the subzone to
-      be unsecured MUST appear with the superzone signature in the
-      superzone, if the superzone is secure.
-
-   The confusion here is that in RFC 2535, a secured parent states that
-   a child is secured by SAYING NOTHING ("may also be" as opposed to
-   "MUST also be").  This is counter intuitive, the fact that an absence
-   of data means something is "secured."  This notion, while acceptable
-   in a theoretic setting has met with some discomfort in an operation
-   setting.  However, the use of "silence" to state something does
-   indeed work in this case, so there hasn't been sufficient need
-   demonstrated to change the definition.
-
-
-
-
-
-Lewis                       Standards Track                     [Page 4]
-
-RFC 3090         DNS Security Extension on Zone Status        March 2001
-
-
-1.4 Impact on RFC 2535
-
-   This document updates sections of RFC 2535.  The definition of a
-   secured zone is an update to section 3.4 of the RFC.  Section 3.4 is
-   updated to eliminate the definition of experimental keys and
-   illustrate a way to still achieve the functionality they were
-   designed to provide.  Section 3.1.3 is updated by the specifying the
-   value of the protocol octet in a zone key.
-
-1.5 "MUST" and other key words
-
-   The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
-   in this document are to be interpreted as described in [RFC 2119].
-   Currently, only "MUST" is used in this document.
-
-2 Status of a Zone
-
-   In this section, rules governing a zone's DNSSEC status are
-   presented.  There are three levels of security defined: global,
-   local, and unsecured.  A zone is globally secure when it complies
-   with the strictest set of DNSSEC processing rules.  A zone is locally
-   secured when it is configured in such a way that only resolvers that
-   are appropriately configured see the zone as secured.  All other
-   zones are unsecured.
-
-   Note: there currently is no document completely defining DNSSEC
-   verification rules.  For the purposes of this document, the strictest
-   rules are assumed to state that the verification chain of zone keys
-   parallels the delegation tree up to the root zone.  (See 2.b below.)
-   This is not intended to disallow alternate verification paths, just
-   to establish a baseline definition.
-
-   To avoid repetition in the rules below, the following terms are
-   defined.
-
-   2.a Zone signing KEY RR - A KEY RR whose flag field has the value 01
-   for name type (indicating a zone key) and either value 00 or value 01
-   for key type (indicating a key permitted to authenticate data).  (See
-   RFC 2535, section 3.1.2).  The KEY RR also has a protocol octet value
-   of DNSSEC (3) or ALL (255).
-
-   The definition updates RFC 2535's definition of a zone key.  The
-   requirement that the protocol field be either DNSSEC or ALL is a new
-   requirement (a change to section 3.1.3.)
-
-   2.b On-tree Validation - The authorization model in which only the
-   parent zone is recognized to supply a DNSSEC-meaningful signature
-   that is used by a resolver to build a chain of trust from the child's
-
-
-
-Lewis                       Standards Track                     [Page 5]
-
-RFC 3090         DNS Security Extension on Zone Status        March 2001
-
-
-   keys to a recognized root of security.  The term "on-tree" refers to
-   following the DNS domain hierarchy (upwards) to reach a trusted key,
-   presumably the root key if no other key is available.  The term
-   "validation" refers to the digital signature by the parent to prove
-   the integrity, authentication and authorization of the child's key to
-   sign the child's zone data.
-
-   2.c Off-tree Validation - Any authorization model that permits domain
-   names other than the parent's to provide a signature over a child's
-   zone keys that will enable a resolver to trust the keys.
-
-2.1 Globally Secured
-
-   A globally secured zone, in a nutshell, is a zone that uses only
-   mandatory to implement algorithms (RFC 2535, section 3.2) and relies
-   on a key certification chain that parallels the delegation tree (on-
-   tree validation).  Globally secured zones are defined by the
-   following rules.
-
-   2.1.a. The zone's apex MUST have a KEY RR set.  There MUST be at
-   least one zone signing KEY RR (2.a) of a mandatory to implement
-   algorithm in the set.
-
-   2.1.b. The zone's apex KEY RR set MUST be signed by a private key
-   belonging to the parent zone.  The private key's public companion
-   MUST be a zone signing KEY RR (2.a) of a mandatory to implement
-   algorithm and owned by the parent's apex.
-
-   If a zone cannot get a conforming signature from the parent zone, the
-   child zone cannot be considered globally secured.  The only exception
-   to this is the root zone, for which there is no parent zone.
-
-   2.1.c. NXT records MUST be deployed throughout the zone.  (Clarifies
-   RFC 2535, section 2.3.2.)  Note: there is some operational discomfort
-   with the current NXT record.  This requirement is open to
-   modification when two things happen.  First, an alternate mechanism
-   to the NXT is defined and second, a means by which a zone can
-   indicate that it is using an alternate method.
-
-   2.1.d. Each RR set that qualifies for zone membership MUST be signed
-   by a key that is in the apex's KEY RR set and is a zone signing KEY
-   RR (2.a) of a mandatory to implement algorithm.  (Updates 2535,
-   section 2.3.1.)
-
-   Mentioned earlier, the root zone is a special case.  The root zone
-   will be considered to be globally secured provided that if conforms
-   to the rules for locally secured, with the exception that rule 2.1.a.
-   be also met (mandatory to implement requirement).
-
-
-
-Lewis                       Standards Track                     [Page 6]
-
-RFC 3090         DNS Security Extension on Zone Status        March 2001
-
-
-2.2 Locally Secured
-
-   The term "locally" stems from the likely hood that the only resolvers
-   to be configured for a particular zone will be resolvers "local" to
-   an organization.
-
-   A locally secured zone is a zone that complies with rules like those
-   for a globally secured zone with the following exceptions.  The
-   signing keys may be of an algorithm that is not mandatory to
-   implement and/or the verification of the zone keys in use may rely on
-   a verification chain that is not parallel to the delegation tree
-   (off-tree validation).
-
-   2.2.a. The zone's apex MUST have a KEY RR set.  There MUST be at
-   least one zone signing KEY RR (2.a) in the set.
-
-   2.2.b. The zone's apex KEY RR set MUST be signed by a private key and
-   one of the following two subclauses MUST hold true.
-
-   2.2.b.1 The private key's public companion MUST be pre-configured in
-   all the resolvers of interest.
-
-   2.2.b.2 The private key's public companion MUST be a zone signing KEY
-   RR (2.a) authorized to provide validation of the zone's apex KEY RR
-   set, as recognized by resolvers of interest.
-
-   The previous sentence is trying to convey the notion of using a
-   trusted third party to provide validation of keys.  If the domain
-   name owning the validating key is not the parent zone, the domain
-   name must represent someone the resolver trusts to provide
-   validation.
-
-   2.2.c. NXT records MUST be deployed throughout the zone.  Note: see
-   the discussion following 2.1.c.
-
-   2.2.d. Each RR set that qualifies for zone membership MUST be signed
-   by a key that is in the apex's KEY RR set and is a zone signing KEY
-   RR (2.a).  (Updates 2535, section 2.3.1.)
-
-2.3 Unsecured
-
-   All other zones qualify as unsecured.  This includes zones that are
-   designed to be experimentally secure, as defined in a later section
-   on that topic.
-
-
-
-
-
-
-
-Lewis                       Standards Track                     [Page 7]
-
-RFC 3090         DNS Security Extension on Zone Status        March 2001
-
-
-2.4 Wrap up
-
-   The designation of globally secured, locally secured, and unsecured
-   are merely labels to apply to zones, based on their contents.
-   Resolvers, when determining whether a signature is expected or not,
-   will only see a zone as secured or unsecured.
-
-   Resolvers that follow the most restrictive DNSSEC verification rules
-   will only see globally secured zones as secured, and all others as
-   unsecured, including zones which are locally secured.  Resolvers that
-   are not as restrictive, such as those that implement algorithms in
-   addition to the mandatory to implement algorithms, will see some
-   locally secured zones as secured.
-
-   The intent of the labels "global" and "local" is to identify the
-   specific attributes of a zone.  The words are chosen to assist in the
-   writing of a document recommending the actions a zone administrator
-   take in making use of the DNS security extensions.  The words are
-   explicitly not intended to convey a state of compliance with DNS
-   security standards.
-
-3 Experimental Status
-
-   The purpose of an experimentally secured zone is to facilitate the
-   migration from an unsecured zone to a secured zone.  This distinction
-   is dropped.
-
-   The objective of facilitating the migration can be achieved without a
-   special designation of an experimentally secure status.
-   Experimentally secured is a special case of locally secured.  A zone
-   administrator can achieve this by publishing a zone with signatures
-   and configuring a set of test resolvers with the corresponding public
-   keys.  Even if the public key is published in a KEY RR, as long as
-   there is no parent signature, the resolvers will need some pre-
-   configuration to know to process the signatures.  This allows a zone
-   to be secured with in the sphere of the experiment, yet still be
-   registered as unsecured in the general Internet.
-
-4 IANA Considerations
-
-   This document does not request any action from an assigned number
-   authority nor recommends any actions.
-
-
-
-
-
-
-
-
-
-Lewis                       Standards Track                     [Page 8]
-
-RFC 3090         DNS Security Extension on Zone Status        March 2001
-
-
-5 Security Considerations
-
-   Without a means to enforce compliance with specified protocols or
-   recommended actions, declaring a DNS zone to be "completely" secured
-   is impossible.  Even if, assuming an omnipotent view of DNS, one can
-   declare a zone to be properly configured for security, and all of the
-   zones up to the root too, a misbehaving resolver could be duped into
-   believing bad data.  If a zone and resolver comply, a non-compliant
-   or subverted parent could interrupt operations.  The best that can be
-   hoped for is that all parties are prepared to be judged secure and
-   that security incidents can be traced to the cause in short order.
-
-6 Acknowledgements
-
-   The need to refine the definition of a secured zone has become
-   apparent through the efforts of the participants at two DNSSEC
-   workshops, sponsored by the NIC-SE (.se registrar), CAIRN (a DARPA-
-   funded research network), and other workshops.  Further discussions
-   leading to the document include Olafur Gudmundsson, Russ Mundy,
-   Robert Watson, and Brian Wellington.  Roy Arends, Ted Lindgreen and
-   others have contributed significant input via the namedroppers
-   mailing list.
-
-7 References
-
-   [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
-             STD 13, RFC 1034, November 1987.
-
-   [RFC1035] Mockapetris, P., "Domain Names - Implementation and
-             Specification", STD 13, RFC 1035, November 1987.
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2136] Vixie, P., (Ed.), Thomson, S., Rekhter, Y. and J. Bound,
-             "Dynamic Updates in the Domain Name System", RFC 2136,
-             April 1997.
-
-   [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
-             2535, March 1999.
-
-   [RFC3007] Wellington, B., "Simple Secure Domain Name System (DNS)
-             Dynamic Update", RFC 3007, November 2000.
-
-   [RFC3008] Wellington, B., "Domain Name System Security (DNSSEC)
-             Signing Authority", RFC 3008, November 2000.
-
-
-
-
-
-Lewis                       Standards Track                     [Page 9]
-
-RFC 3090         DNS Security Extension on Zone Status        March 2001
-
-
-10 Author's Address
-
-   Edward Lewis
-   NAI Labs
-   3060 Washington Road Glenwood
-   MD 21738
-
-   Phone: +1 443 259 2352
-   EMail: lewis@tislabs.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lewis                       Standards Track                    [Page 10]
-
-RFC 3090         DNS Security Extension on Zone Status        March 2001
-
-
-11 Full Copyright Statement
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lewis                       Standards Track                    [Page 11]
-
diff --git a/contrib/bind9/doc/rfc/rfc3110.txt b/contrib/bind9/doc/rfc/rfc3110.txt
deleted file mode 100644
index 7646948..0000000
--- a/contrib/bind9/doc/rfc/rfc3110.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                    D. Eastlake 3rd
-Request for Comments: 3110                                      Motorola
-Obsoletes: 2537                                                 May 2001
-Category: Standards Track
-
-
-      RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-Abstract
-
-   This document describes how to produce RSA/SHA1 SIG resource records
-   (RRs) in Section 3 and, so as to completely replace RFC 2537,
-   describes how to produce RSA KEY RRs in Section 2.
-
-   Since the adoption of a Proposed Standard for RSA signatures in the
-   DNS (Domain Name Space), advances in hashing have been made.  A new
-   DNS signature algorithm is defined to make these advances available
-   in SIG RRs.  The use of the previously specified weaker mechanism is
-   deprecated.  The algorithm number of the RSA KEY RR is changed to
-   correspond to this new SIG algorithm.  No other changes are made to
-   DNS security.
-
-Acknowledgements
-
-   Material and comments from the following have been incorporated and
-   are gratefully acknowledged:
-
-      Olafur Gudmundsson
-
-      The IESG
-
-      Charlie Kaufman
-
-      Steve Wang
-
-
-
-
-
-D. Eastlake 3rd             Standards Track                     [Page 1]
-
-RFC 3110              RSA SIGs and KEYs in the DNS              May 2001
-
-
-Table of Contents
-
-   1. Introduction................................................... 2
-   2. RSA Public KEY Resource Records................................ 3
-   3. RSA/SHA1 SIG Resource Records.................................. 3
-   4. Performance Considerations..................................... 4
-   5. IANA Considerations............................................ 5
-   6. Security Considerations........................................ 5
-   References........................................................ 5
-   Author's Address.................................................. 6
-   Full Copyright Statement.......................................... 7
-
-1. Introduction
-
-   The Domain Name System (DNS) is the global hierarchical replicated
-   distributed database system for Internet addressing, mail proxy, and
-   other information [RFC1034, 1035, etc.].  The DNS has been extended
-   to include digital signatures and cryptographic keys as described in
-   [RFC2535].  Thus the DNS can now be secured and used for secure key
-   distribution.
-
-   Familiarity with the RSA and SHA-1 algorithms is assumed [Schneier,
-   FIP180] in this document.
-
-   RFC 2537 described how to store RSA keys and RSA/MD5 based signatures
-   in the DNS.  However, since the adoption of RFC 2537, continued
-   cryptographic research has revealed hints of weakness in the MD5
-   [RFC1321] algorithm used in RFC 2537.  The SHA1 Secure Hash Algorithm
-   [FIP180], which produces a larger hash, has been developed.  By now
-   there has been sufficient experience with SHA1 that it is generally
-   acknowledged to be stronger than MD5.  While this stronger hash is
-   probably not needed today in most secure DNS zones, critical zones
-   such a root, most top level domains, and some second and third level
-   domains, are sufficiently valuable targets that it would be negligent
-   not to provide what are generally agreed to be stronger mechanisms.
-   Furthermore, future advances in cryptanalysis and/or computer speeds
-   may require a stronger hash everywhere.  In addition, the additional
-   computation required by SHA1 above that required by MD5 is
-   insignificant compared with the computational effort required by the
-   RSA modular exponentiation.
-
-   This document describes how to produce RSA/SHA1 SIG RRs in Section 3
-   and, so as to completely replace RFC 2537, describes how to produce
-   RSA KEY RRs in Section 2.
-
-   Implementation of the RSA algorithm in DNS with SHA1 is MANDATORY for
-   DNSSEC.  The generation of RSA/MD5 SIG RRs as described in RFC 2537
-   is NOT RECOMMENDED.
-
-
-
-D. Eastlake 3rd             Standards Track                     [Page 2]
-
-RFC 3110              RSA SIGs and KEYs in the DNS              May 2001
-
-
-   The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", "NOT
-   RECOMMENDED", and "MAY" in this document are to be interpreted as
-   described in RFC 2119.
-
-2. RSA Public KEY Resource Records
-
-   RSA public keys are stored in the DNS as KEY RRs using algorithm
-   number 5 [RFC2535].  The structure of the algorithm specific portion
-   of the RDATA part of such RRs is as shown below.
-
-         Field             Size
-         -----             ----
-         exponent length   1 or 3 octets (see text)
-         exponent          as specified by length field
-         modulus           remaining space
-
-   For interoperability, the exponent and modulus are each limited to
-   4096 bits in length.  The public key exponent is a variable length
-   unsigned integer.  Its length in octets is represented as one octet
-   if it is in the range of 1 to 255 and by a zero octet followed by a
-   two octet unsigned length if it is longer than 255 bytes.  The public
-   key modulus field is a multiprecision unsigned integer.  The length
-   of the modulus can be determined from the RDLENGTH and the preceding
-   RDATA fields including the exponent.  Leading zero octets are
-   prohibited in the exponent and modulus.
-
-   Note: KEY RRs for use with RSA/SHA1 DNS signatures MUST use this
-   algorithm number (rather than the algorithm number specified in the
-   obsoleted RFC 2537).
-
-   Note: This changes the algorithm number for RSA KEY RRs to be the
-   same as the new algorithm number for RSA/SHA1 SIGs.
-
-3. RSA/SHA1 SIG Resource Records
-
-   RSA/SHA1 signatures are stored in the DNS using SIG resource records
-   (RRs) with algorithm number 5.
-
-   The signature portion of the SIG RR RDATA area, when using the
-   RSA/SHA1 algorithm, is calculated as shown below.  The data signed is
-   determined as specified in RFC 2535.  See RFC 2535 for fields in the
-   SIG RR RDATA which precede the signature itself.
-
-         hash = SHA1 ( data )
-
-         signature = ( 01 | FF* | 00 | prefix | hash ) ** e (mod n)
-
-
-
-
-
-D. Eastlake 3rd             Standards Track                     [Page 3]
-
-RFC 3110              RSA SIGs and KEYs in the DNS              May 2001
-
-
-   where SHA1 is the message digest algorithm documented in [FIP180],
-   "|" is concatenation, "e" is the private key exponent of the signer,
-   and "n" is the modulus of the signer's public key.  01, FF, and 00
-   are fixed octets of the corresponding hexadecimal value.  "prefix" is
-   the ASN.1 BER SHA1 algorithm designator prefix required in PKCS1
-   [RFC2437], that is,
-
-         hex 30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14
-
-   This prefix is included to make it easier to use standard
-   cryptographic libraries.  The FF octet MUST be repeated the maximum
-   number of times such that the value of the quantity being
-   exponentiated is one octet shorter than the value of n.
-
-   (The above specifications are identical to the corresponding parts of
-   Public Key Cryptographic Standard #1 [RFC2437].)
-
-   The size of "n", including most and least significant bits (which
-   will be 1) MUST be not less than 512 bits and not more than 4096
-   bits.  "n" and "e" SHOULD be chosen such that the public exponent is
-   small.  These are protocol limits.  For a discussion of key size see
-   RFC 2541.
-
-   Leading zero bytes are permitted in the RSA/SHA1 algorithm signature.
-
-4. Performance Considerations
-
-   General signature generation speeds are roughly the same for RSA and
-   DSA [RFC2536].  With sufficient pre-computation, signature generation
-   with DSA is faster than RSA.  Key generation is also faster for DSA.
-   However, signature verification is an order of magnitude slower with
-   DSA when the RSA public exponent is chosen to be small as is
-   recommended for KEY RRs used in domain name system (DNS) data
-   authentication.
-
-   A public exponent of 3 minimizes the effort needed to verify a
-   signature.  Use of 3 as the public exponent is weak for
-   confidentiality uses since, if the same data can be collected
-   encrypted under three different keys with an exponent of 3 then,
-   using the Chinese Remainder Theorem [NETSEC], the original plain text
-   can be easily recovered.  If a key is known to be used only for
-   authentication, as is the case with DNSSEC, then an exponent of 3 is
-   acceptable.  However other applications in the future may wish to
-   leverage DNS distributed keys for applications that do require
-   confidentiality.  For keys which might have such other uses, a more
-   conservative choice would be 65537 (F4, the fourth fermat number).
-
-
-
-
-
-D. Eastlake 3rd             Standards Track                     [Page 4]
-
-RFC 3110              RSA SIGs and KEYs in the DNS              May 2001
-
-
-   Current DNS implementations are optimized for small transfers,
-   typically less than 512 bytes including DNS overhead.  Larger
-   transfers will perform correctly and extensions have been
-   standardized [RFC2671] to make larger transfers more efficient, it is
-   still advisable at this time to make reasonable efforts to minimize
-   the size of KEY RR sets stored within the DNS consistent with
-   adequate security.  Keep in mind that in a secure zone, at least one
-   authenticating SIG RR will also be returned.
-
-5. IANA Considerations
-
-   The DNSSEC algorithm number 5 is allocated for RSA/SHA1 SIG RRs and
-   RSA KEY RRs.
-
-6. Security Considerations
-
-   Many of the general security considerations in RFC 2535 apply.  Keys
-   retrieved from the DNS should not be trusted unless (1) they have
-   been securely obtained from a secure resolver or independently
-   verified by the user and (2) this secure resolver and secure
-   obtainment or independent verification conform to security policies
-   acceptable to the user.  As with all cryptographic algorithms,
-   evaluating the necessary strength of the key is essential and
-   dependent on local policy.  For particularly critical applications,
-   implementers are encouraged to consider the range of available
-   algorithms and key sizes.  See also RFC 2541, "DNS Security
-   Operational Considerations".
-
-References
-
-   [FIP180]   U.S. Department of Commerce, "Secure Hash Standard", FIPS
-              PUB 180-1, 17 Apr 1995.
-
-   [NETSEC]   Network Security: PRIVATE Communications in a PUBLIC
-              World, Charlie Kaufman, Radia Perlman, & Mike Speciner,
-              Prentice Hall Series in Computer Networking and
-              Distributed Communications, 1995.
-
-   [RFC1034]  Mockapetris, P., "Domain Names - Concepts and Facilities",
-              STD 13, RFC 1034, November 1987.
-
-   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
-              Specification", STD 13, RFC 1035, November 1987.
-
-   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
-              April 1992.
-
-
-
-
-
-D. Eastlake 3rd             Standards Track                     [Page 5]
-
-RFC 3110              RSA SIGs and KEYs in the DNS              May 2001
-
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2437]  Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
-              Specifications Version 2.0", RFC 2437, October 1998.
-
-   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
-              RFC 2535, March 1999.
-
-   [RFC2536]  Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
-              (DNS)", RFC 2536, March 1999.
-
-   [RFC2537]  Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name
-              System (DNS)", RFC 2537, March 1999.
-
-   [RFC2541]  Eastlake, D., "DNS Security Operational Considerations",
-              RFC 2541, March 1999.
-
-   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
-              2671, August 1999.
-
-   [Schneier] Bruce Schneier, "Applied Cryptography Second Edition:
-              protocols, algorithms, and source code in C", 1996, John
-              Wiley and Sons, ISBN 0-471-11709-9.
-
-Author's Address
-
-   Donald E. Eastlake 3rd
-   Motorola
-   155 Beaver Street
-   Milford, MA 01757 USA
-
-   Phone:   +1-508-261-5434 (w)
-            +1-508-634-2066 (h)
-   Fax      +1-508-261-4777 (w)
-   EMail:   Donald.Eastlake@motorola.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd             Standards Track                     [Page 6]
-
-RFC 3110              RSA SIGs and KEYs in the DNS              May 2001
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd             Standards Track                     [Page 7]
-
diff --git a/contrib/bind9/doc/rfc/rfc3123.txt b/contrib/bind9/doc/rfc/rfc3123.txt
deleted file mode 100644
index 3b2fe00..0000000
--- a/contrib/bind9/doc/rfc/rfc3123.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                            P. Koch
-Request for Comments: 3123                        Universitaet Bielefeld
-Category: Experimental                                         June 2001
-
-
-          A DNS RR Type for Lists of Address Prefixes (APL RR)
-
-Status of this Memo
-
-   This memo defines an Experimental Protocol for the Internet
-   community.  It does not specify an Internet standard of any kind.
-   Discussion and suggestions for improvement are requested.
-   Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-Abstract
-
-   The Domain Name System (DNS) is primarily used to translate domain
-   names into IPv4 addresses using A RRs (Resource Records).  Several
-   approaches exist to describe networks or address ranges.  This
-   document specifies a new DNS RR type "APL" for address prefix lists.
-
-1. Conventions used in this document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-   Domain names herein are for explanatory purposes only and should not
-   be expected to lead to useful information in real life [RFC2606].
-
-2. Background
-
-   The Domain Name System [RFC1034], [RFC1035] provides a mechanism to
-   associate addresses and other Internet infrastructure elements with
-   hierarchically built domain names.  Various types of resource records
-   have been defined, especially those for IPv4 and IPv6 [RFC2874]
-   addresses.  In [RFC1101] a method is described to publish information
-   about the address space allocated to an organisation.  In older BIND
-   versions, a weak form of controlling access to zone data was
-   implemented using TXT RRs describing address ranges.
-
-   This document specifies a new RR type for address prefix lists.
-
-
-
-
-
-Koch                          Experimental                      [Page 1]
-
-RFC 3123                       DNS APL RR                      June 2001
-
-
-3. APL RR Type
-
-   An APL record has the DNS type of "APL" and a numeric value of 42
-   [IANA].  The APL RR is defined in the IN class only.  APL RRs cause
-   no additional section processing.
-
-4. APL RDATA format
-
-   The RDATA section consists of zero or more items (<apitem>) of the
-   form
-
-      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-      |                          ADDRESSFAMILY                        |
-      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-      |             PREFIX            | N |         AFDLENGTH         |
-      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-      /                            AFDPART                            /
-      |                                                               |
-      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-
-      ADDRESSFAMILY     16 bit unsigned value as assigned by IANA
-                        (see IANA Considerations)
-      PREFIX            8 bit unsigned binary coded prefix length.
-                        Upper and lower bounds and interpretation of
-                        this value are address family specific.
-      N                 negation flag, indicates the presence of the
-                        "!" character in the textual format.  It has
-                        the value "1" if the "!" was given, "0" else.
-      AFDLENGTH         length in octets of the following address
-                        family dependent part (7 bit unsigned).
-      AFDPART           address family dependent part.  See below.
-
-   This document defines the AFDPARTs for address families 1 (IPv4) and
-   2 (IPv6).  Future revisions may deal with additional address
-   families.
-
-4.1. AFDPART for IPv4
-
-   The encoding of an IPv4 address (address family 1) follows the
-   encoding specified for the A RR by [RFC1035], section 3.4.1.
-
-   PREFIX specifies the number of bits of the IPv4 address starting at
-   the most significant bit.  Legal values range from 0 to 32.
-
-   Trailing zero octets do not bear any information (e.g., there is no
-   semantic difference between 10.0.0.0/16 and 10/16) in an address
-   prefix, so the shortest possible AFDLENGTH can be used to encode it.
-   However, for DNSSEC [RFC2535] a single wire encoding must be used by
-
-
-
-Koch                          Experimental                      [Page 2]
-
-RFC 3123                       DNS APL RR                      June 2001
-
-
-   all.  Therefore the sender MUST NOT include trailing zero octets in
-   the AFDPART regardless of the value of PREFIX.  This includes cases
-   in which AFDLENGTH times 8 results in a value less than PREFIX.  The
-   AFDPART is padded with zero bits to match a full octet boundary.
-
-   An IPv4 AFDPART has a variable length of 0 to 4 octets.
-
-4.2. AFDPART for IPv6
-
-   The 128 bit IPv6 address (address family 2) is encoded in network
-   byte order (high-order byte first).
-
-   PREFIX specifies the number of bits of the IPv6 address starting at
-   the most significant bit.  Legal values range from 0 to 128.
-
-   With the same reasoning as in 4.1 above, the sender MUST NOT include
-   trailing zero octets in the AFDPART regardless of the value of
-   PREFIX.  This includes cases in which AFDLENGTH times 8 results in a
-   value less than PREFIX.  The AFDPART is padded with zero bits to
-   match a full octet boundary.
-
-   An IPv6 AFDPART has a variable length of 0 to 16 octets.
-
-5. Zone File Syntax
-
-   The textual representation of an APL RR in a DNS zone file is as
-   follows:
-
-   <owner>   IN   <TTL>   APL   {[!]afi:address/prefix}*
-
-   The data consists of zero or more strings of the address family
-   indicator <afi>, immediately followed by a colon ":", an address,
-   immediately followed by the "/" character, immediately followed by a
-   decimal numeric value for the prefix length.  Any such string may be
-   preceded by a "!" character.  The strings are separated by
-   whitespace.  The <afi> is the decimal numeric value of that
-   particular address family.
-
-5.1. Textual Representation of IPv4 Addresses
-
-   An IPv4 address in the <address> part of an <apitem> is in dotted
-   quad notation, just as in an A RR.  The <prefix> has values from the
-   interval 0..32 (decimal).
-
-
-
-
-
-
-
-
-Koch                          Experimental                      [Page 3]
-
-RFC 3123                       DNS APL RR                      June 2001
-
-
-5.2. Textual Representation of IPv6 Addresses
-
-   The representation of an IPv6 address in the <address> part of an
-   <apitem> follows [RFC2373], section 2.2.  Legal values for <prefix>
-   are from the interval 0..128 (decimal).
-
-6. APL RR usage
-
-   An APL RR with empty RDATA is valid and implements an empty list.
-   Multiple occurrences of the same <apitem> in a single APL RR are
-   allowed and MUST NOT be merged by a DNS server or resolver.
-   <apitems> MUST be kept in order and MUST NOT be rearranged or
-   aggregated.
-
-   A single APL RR may contain <apitems> belonging to different address
-   families.  The maximum number of <apitems> is upper bounded by the
-   available RDATA space.
-
-   RRSets consisting of more than one APL RR are legal but the
-   interpretation is left to the particular application.
-
-7. Applicability Statement
-
-   The APL RR defines a framework without specifying any particular
-   meaning for the list of prefixes.  It is expected that APL RRs will
-   be used in different application scenarios which have to be
-   documented separately.  Those scenarios may be distinguished by
-   characteristic prefixes placed in front of the DNS owner name.
-
-   An APL application specification MUST include information on
-
-   o  the characteristic prefix, if any
-
-   o  how to interpret APL RRSets consisting of more than one RR
-
-   o  how to interpret an empty APL RR
-
-   o  which address families are expected to appear in the APL RRs for
-      that application
-
-   o  how to deal with APL RR list elements which belong to other
-      address families, including those not yet defined
-
-   o  the exact semantics of list elements negated by the "!" character
-
-
-
-
-
-
-
-Koch                          Experimental                      [Page 4]
-
-RFC 3123                       DNS APL RR                      June 2001
-
-
-   Possible applications include the publication of address ranges
-   similar to [RFC1101], description of zones built following [RFC2317]
-   and in-band access control to limit general access or zone transfer
-   (AXFR) availability for zone data held in DNS servers.
-
-   The specification of particular application scenarios is out of the
-   scope of this document.
-
-8. Examples
-
-   The following examples only illustrate some of the possible usages
-   outlined in the previous section.  None of those applications are
-   hereby specified nor is it implied that any particular APL RR based
-   application does exist now or will exist in the future.
-
-  ; RFC 1101-like announcement of address ranges for foo.example
-  foo.example.             IN APL 1:192.168.32.0/21 !1:192.168.38.0/28
-
-  ; CIDR blocks covered by classless delegation
-  42.168.192.IN-ADDR.ARPA. IN APL ( 1:192.168.42.0/26 1:192.168.42.64/26
-                                  1:192.168.42.128/25 )
-
-  ; Zone transfer restriction
-  _axfr.sbo.example.       IN APL 1:127.0.0.1/32 1:172.16.64.0/22
-
-  ; List of address ranges for multicast
-  multicast.example.       IN APL 1:224.0.0.0/4  2:FF00:0:0:0:0:0:0:0/8
-
-   Note that since trailing zeroes are ignored in the first APL RR the
-   AFDLENGTH of both <apitems> is three.
-
-9. Security Considerations
-
-   Any information obtained from the DNS should be regarded as unsafe
-   unless techniques specified in [RFC2535] or [RFC2845] were used.  The
-   definition of a new RR type does not introduce security problems into
-   the DNS, but usage of information made available by APL RRs may
-   compromise security.  This includes disclosure of network topology
-   information and in particular the use of APL RRs to construct access
-   control lists.
-
-
-
-
-
-
-
-
-
-
-
-Koch                          Experimental                      [Page 5]
-
-RFC 3123                       DNS APL RR                      June 2001
-
-
-10. IANA Considerations
-
-   This section is to be interpreted as following [RFC2434].
-
-   This document does not define any new namespaces.  It uses the 16 bit
-   identifiers for address families maintained by IANA in
-   http://www.iana.org/numbers.html.
-
-   The IANA assigned numeric RR type value 42 for APL [IANA].
-
-11. Acknowledgements
-
-   The author would like to thank Mark Andrews, Olafur Gudmundsson, Ed
-   Lewis, Thomas Narten, Erik Nordmark, and Paul Vixie for their review
-   and constructive comments.
-
-12. References
-
-   [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
-             STD 13, RFC 1034, November 1987.
-
-   [RFC1035] Mockapetris, P., "Domain Names - Implementation and
-             Specification", STD 13, RFC 1035, November 1987.
-
-   [RFC1101] Mockapetris, P., "DNS Encoding of Network Names and Other
-             Types", RFC 1101, April 1989.
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
-             Specification", RFC 2181, July 1997.
-
-   [RFC2317] Eidnes, H., de Groot, G. and P. Vixie, "Classless IN-
-             ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998.
-
-   [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
-             Architecture", RFC 2373, July 1998.
-
-   [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
-             IANA Considerations Section in RFCs", BCP 26, RFC 2434,
-             October 1998.
-
-   [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
-             2535, March 1999.
-
-   [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names",
-             BCP 32, RFC 2606, June 1999.
-
-
-
-Koch                          Experimental                      [Page 6]
-
-RFC 3123                       DNS APL RR                      June 2001
-
-
-   [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
-             "Secret Key Transaction Authentication for DNS (TSIG)", RFC
-             2845, May 2000.
-
-   [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support
-             IPv6 Address Aggregation and Renumbering", RFC 2874, July
-             2000.
-
-   [IANA]    http://www.iana.org/assignments/dns-parameters
-
-13. Author's Address
-
-   Peter Koch
-   Universitaet Bielefeld
-   Technische Fakultaet
-   D-33594 Bielefeld
-   Germany
-
-   Phone: +49 521 106 2902
-   EMail: pk@TechFak.Uni-Bielefeld.DE
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Koch                          Experimental                      [Page 7]
-
-RFC 3123                       DNS APL RR                      June 2001
-
-
-14. Full Copyright Statement
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Koch                          Experimental                      [Page 8]
-
diff --git a/contrib/bind9/doc/rfc/rfc3152.txt b/contrib/bind9/doc/rfc/rfc3152.txt
deleted file mode 100644
index b226ce6..0000000
--- a/contrib/bind9/doc/rfc/rfc3152.txt
+++ /dev/null
@@ -1,227 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                            R. Bush
-Request for Comments: 3152                                         RGnet
-BCP: 49                                                      August 2001
-Updates: 2874, 2772, 2766, 2553, 1886
-Category: Best Current Practice
-
-
-                         Delegation of IP6.ARPA
-
-Status of this Memo
-
-   This document specifies an Internet Best Current Practices for the
-   Internet Community, and requests discussion and suggestions for
-   improvements.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-Abstract
-
-   This document discusses the need for delegation of the IP6.ARPA DNS
-   zone, and specifies a plan for the technical operation thereof.
-
-1. Why IP6.ARPA?
-
-   In the IPv6 address space, there is a need for 'reverse mapping' of
-   addresses to DNS names analogous to that provided by the IN-ADDR.ARPA
-   zone for IPv4.
-
-   The IAB recommended that the ARPA top level domain (the name is now
-   considered an acronym for "Address and Routing Parameters Area") be
-   used for technical infrastructure sub-domains when possible.  It is
-   already in use for IPv4 reverse mapping and has been established as
-   the location for E.164 numbering on the Internet [RFC2916 RFC3026].
-
-   IETF consensus was reached that the IP6.ARPA domain be used for
-   address to DNS name mapping for the IPv6 address space [RFC2874].
-
-2. Obsoleted Usage
-
-   This document deprecates references to IP6.INT in [RFC1886] section
-   2.5, [RFC2553] section 6.2.3, [RFC2766] section 4.1, [RFC2772]
-   section 7.1.c, and [RFC2874] section 2.5.
-
-   In this context, 'deprecate' means that the old usage is not
-   appropriate for new implementations, and IP6.INT will likely be
-   phased out in an orderly fashion.
-
-
-
-Bush                     Best Current Practice                  [Page 1]
-
-RFC 3152                 Delegation of IP6.ARPA              August 2001
-
-
-3. IANA Considerations
-
-   This memo requests that the IANA delegate the IP6.ARPA domain
-   following instructions to be provided by the IAB.  Names within this
-   zone are to be further delegated to the regional IP registries in
-   accordance with the delegation of IPv6 address space to those
-   registries.  The names allocated should be hierarchic in accordance
-   with the address space assignment.
-
-4. Security Considerations
-
-   While DNS spoofing of address to name mapping has been exploited in
-   IPv4, delegation of the IP6.ARPA zone creates no new threats to the
-   security of the internet.
-
-5. References
-
-   [RFC1886]   Thomson, S. and C. Huitema, "DNS Extensions to support IP
-               version 6", RFC 1886, December 1995.
-
-   [RFC2553]   Gilligan, R., Thomson, S., Bound, J. and W. Stevens,
-               "Basic Socket Interface Extensions for IPv6", RFC 2553,
-               March 1999.
-
-   [RFC2766]   Tsirtsis, G. and P. Srisuresh, "Network Address
-               Translation - Protocol Translation (NAT-PT)", RFC 2766,
-               February 2000.
-
-   [RFC2772]   Rockell, R. and R. Fink, "6Bone Backbone Routing
-               Guidelines", RFC 2772, February 2000.
-
-   [RFC2874]   Crawford, M. and C. Huitema, "DNS Extensions to Support
-               IPv6 Address Aggregation and Renumbering", RFC 2874, July
-               2001.
-
-   [RFC2916]   Faltstrom, P., "E.164 number and DNS", RFC 2916,
-               September 2000.
-
-   [RFC3026]   Blane, R., "Liaison to IETF/ISOC on ENUM", RFC 3026,
-               January 2001.
-
-
-
-
-
-
-
-
-
-
-
-Bush                     Best Current Practice                  [Page 2]
-
-RFC 3152                 Delegation of IP6.ARPA              August 2001
-
-
-6. Author's Address
-
-   Randy Bush
-   5147 Crystal Springs
-   Bainbridge Island, WA US-98110
-
-   Phone: +1 206 780 0431
-   EMail: randy@psg.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bush                     Best Current Practice                  [Page 3]
-
-RFC 3152                 Delegation of IP6.ARPA              August 2001
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bush                     Best Current Practice                  [Page 4]
-
diff --git a/contrib/bind9/doc/rfc/rfc3197.txt b/contrib/bind9/doc/rfc/rfc3197.txt
deleted file mode 100644
index 94cefa4..0000000
--- a/contrib/bind9/doc/rfc/rfc3197.txt
+++ /dev/null
@@ -1,283 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         R. Austein
-Request for Comments: 3197                                 InterNetShare
-Category: Informational                                    November 2001
-
-
-             Applicability Statement for DNS MIB Extensions
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-Abstract
-
-   This document explains why, after more than six years as proposed
-   standards, the DNS Server and Resolver MIB extensions were never
-   deployed, and recommends retiring these MIB extensions by moving them
-   to Historical status.
-
-1. History
-
-   The road to the DNS MIB extensions was paved with good intentions.
-
-   In retrospect, it's obvious that the working group never had much
-   agreement on what belonged in the MIB extensions, just that we should
-   have some.  This happened during the height of the craze for MIB
-   extensions in virtually every protocol that the IETF was working on
-   at the time, so the question of why we were doing this in the first
-   place never got a lot of scrutiny.  Very late in the development
-   cycle we discovered that much of the support for writing the MIB
-   extensions in the first place had come from people who wanted to use
-   SNMP SET operations to update DNS zones on the fly.  Examination of
-   the security model involved, however, led us to conclude that this
-   was not a good way to do dynamic update and that a separate DNS
-   Dynamic Update protocol would be necessary.
-
-   The MIB extensions started out being fairly specific to one
-   particular DNS implementation (BIND-4.8.3); as work progressed, the
-   BIND-specific portions were rewritten to be as implementation-neutral
-   as we knew how to make them, but somehow every revision of the MIB
-   extensions managed to create new counters that just happened to
-   closely match statistics kept by some version of BIND.  As a result,
-   the MIB extensions ended up being much too big, which raised a number
-
-
-
-Austein                      Informational                      [Page 1]
-
-RFC 3197      Applicability Statement - DNS MIB Extensions November 2001
-
-
-   of concerns with the network management directorate, but the WG
-   resisted every attempt to remove any of these variables.  In the end,
-   large portions of the MIB extensions were moved into optional groups
-   in an attempt to get the required subset down to a manageable size.
-
-   The DNS Server and Resolver MIB extensions were one of the first
-   attempts to write MIB extensions for a protocol usually considered to
-   be at the application layer.  Fairly early on it became clear that,
-   while it was certainly possible to write MIB extensions for DNS, the
-   SMI was not really designed with this sort of thing in mind.  A case
-   in point was the attempt to provide direct indexing into the caches
-   in the resolver MIB extensions: while arguably the only sane way to
-   do this for a large cache, this required much more complex indexing
-   clauses than is usual, and ended up running into known length limits
-   for object identifiers in some SNMP implementations.
-
-   Furthermore, the lack of either real proxy MIB support in SNMP
-   managers or a standard subagent protocol meant that there was no
-   reasonable way to implement the MIB extensions in the dominant
-   implementation (BIND).  When the AgentX subagent protocol was
-   developed a few years later, we initially hoped that this would
-   finally clear the way for an implementation of the DNS MIB
-   extensions, but by the time AgentX was a viable protocol it had
-   become clear that nobody really wanted to implement these MIB
-   extensions.
-
-   Finally, the MIB extensions took much too long to produce.  In
-   retrospect, this should have been a clear warning sign, particularly
-   when the WG had clearly become so tired of the project that the
-   authors found it impossible to elicit any comments whatsoever on the
-   documents.
-
-2. Lessons
-
-   Observations based on the preceding list of mistakes, for the benefit
-   of anyone else who ever attempts to write DNS MIB extensions again:
-
-   -  Define a clear set of goals before writing any MIB extensions.
-      Know who the constituency is and make sure that what you write
-      solves their problem.
-
-   -  Keep the MIB extensions short, and don't add variables just
-      because somebody in the WG thinks they'd be a cool thing to
-      measure.
-
-   -  If some portion of the task seems to be very hard to do within the
-      SMI, that's a strong hint that SNMP is not the right tool for
-      whatever it is that you're trying to do.
-
-
-
-Austein                      Informational                      [Page 2]
-
-RFC 3197      Applicability Statement - DNS MIB Extensions November 2001
-
-
-   -  If the entire project is taking too long, perhaps that's a hint
-      too.
-
-3. Recommendation
-
-   In view of the community's apparent total lack of interest in
-   deploying these MIB extensions, we recommend that RFCs 1611 and 1612
-   be reclassified as Historical documents.
-
-4. Security Considerations
-
-   Re-classifying an existing MIB document from Proposed Standard to
-   Historic should not have any negative impact on security for the
-   Internet.
-
-5. IANA Considerations
-
-   Getting rid of the DNS MIB extensions should not impose any new work
-   on IANA.
-
-6. Acknowledgments
-
-   The author would like to thank all the people who were involved in
-   this project over the years for their optimism and patience,
-   misguided though it may have been.
-
-7. References
-
-   [DNS-SERVER-MIB]     Austein, R. and J. Saperia, "DNS Server MIB
-                        Extensions", RFC 1611, May 1994.
-
-   [DNS-RESOLVER-MIB]   Austein, R. and J. Saperia, "DNS Resolver MIB
-                        Extensions", RFC 1612, May 1994.
-
-   [DNS-DYNAMIC-UPDATE] Vixie, P., Thomson, S., Rekhter, Y. and J.
-                        Bound, "Dynamic Updates in the Domain Name
-                        System (DNS UPDATE)", RFC 2136, April 1997.
-
-   [AGENTX]             Daniele, M., Wijnen, B., Ellison, M., and D.
-                        Francisco, "Agent Extensibility (AgentX)
-                        Protocol Version 1", RFC 2741, January 2000.
-
-
-
-
-
-
-
-
-
-
-Austein                      Informational                      [Page 3]
-
-RFC 3197      Applicability Statement - DNS MIB Extensions November 2001
-
-
-8. Author's Address
-
-   Rob Austein
-   InterNetShare, Incorporated
-   325M Sharon Park Drive, Suite 308
-   Menlo Park, CA  94025
-   USA
-
-   EMail: sra@hactrn.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein                      Informational                      [Page 4]
-
-RFC 3197      Applicability Statement - DNS MIB Extensions November 2001
-
-
-9. Full Copyright Statement
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein                      Informational                      [Page 5]
-
diff --git a/contrib/bind9/doc/rfc/rfc3225.txt b/contrib/bind9/doc/rfc/rfc3225.txt
deleted file mode 100644
index 13e6768..0000000
--- a/contrib/bind9/doc/rfc/rfc3225.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          D. Conrad
-Request for Comments: 3225                                 Nominum, Inc.
-Category: Standards Track                                  December 2001
-
-
-                 Indicating Resolver Support of DNSSEC
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-Abstract
-
-   In order to deploy DNSSEC (Domain Name System Security Extensions)
-   operationally, DNSSEC aware servers should only perform automatic
-   inclusion of DNSSEC RRs when there is an explicit indication that the
-   resolver can understand those RRs.  This document proposes the use of
-   a bit in the EDNS0 header to provide that explicit indication and
-   describes the necessary protocol changes to implement that
-   notification.
-
-1. Introduction
-
-   DNSSEC [RFC2535] has been specified to provide data integrity and
-   authentication to security aware resolvers and applications through
-   the use of cryptographic digital signatures.  However, as DNSSEC is
-   deployed, non-DNSSEC-aware clients will likely query DNSSEC-aware
-   servers.  In such situations, the DNSSEC-aware server (responding to
-   a request for data in a signed zone) will respond with SIG, KEY,
-   and/or NXT records.  For reasons described in the subsequent section,
-   such responses can have significant negative operational impacts for
-   the DNS infrastructure.
-
-   This document discusses a method to avoid these negative impacts,
-   namely DNSSEC-aware servers should only respond with SIG, KEY, and/or
-   NXT RRs when there is an explicit indication from the resolver that
-   it can understand those RRs.
-
-   For the purposes of this document, "DNSSEC security RRs" are
-   considered RRs of type SIG, KEY, or NXT.
-
-
-
-Conrad                      Standards Track                     [Page 1]
-
-RFC 3225         Indicating Resolver Support of DNSSEC     December 2001
-
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-2. Rationale
-
-   Initially, as DNSSEC is deployed, the vast majority of queries will
-   be from resolvers that are not DNSSEC aware and thus do not
-   understand or support the DNSSEC security RRs.  When a query from
-   such a resolver is received for a DNSSEC signed zone, the DNSSEC
-   specification indicates the nameserver must respond with the
-   appropriate DNSSEC security RRs.  As DNS UDP datagrams are limited to
-   512 bytes [RFC1035], responses including DNSSEC security RRs have a
-   high probability of resulting in a truncated response being returned
-   and the resolver retrying the query using TCP.
-
-   TCP DNS queries result in significant overhead due to connection
-   setup and teardown.  Operationally, the impact of these TCP queries
-   will likely be quite detrimental in terms of increased network
-   traffic (typically five packets for a single query/response instead
-   of two), increased latency resulting from the additional round trip
-   times, increased incidences of queries failing due to timeouts, and
-   significantly increased load on nameservers.
-
-   In addition, in preliminary and experimental deployment of DNSSEC,
-   there have been reports of non-DNSSEC aware resolvers being unable to
-   handle responses which contain DNSSEC security RRs, resulting in the
-   resolver failing (in the worst case) or entire responses being
-   ignored (in the better case).
-
-   Given these operational implications, explicitly notifying the
-   nameserver that the client is prepared to receive (if not understand)
-   DNSSEC security RRs would be prudent.
-
-   Client-side support of DNSSEC is assumed to be binary -- either the
-   client is willing to receive all DNSSEC security RRs or it is not
-   willing to accept any.  As such, a single bit is sufficient to
-   indicate client-side DNSSEC support.  As effective use of DNSSEC
-   implies the need of EDNS0 [RFC2671], bits in the "classic" (non-EDNS
-   enhanced DNS header) are scarce, and there may be situations in which
-   non-compliant caching or forwarding servers inappropriately copy data
-   from classic headers as queries are passed on to authoritative
-   servers, the use of a bit from the EDNS0 header is proposed.
-
-   An alternative approach would be to use the existence of an EDNS0
-   header as an implicit indication of client-side support of DNSSEC.
-   This approach was not chosen as there may be applications in which
-   EDNS0 is supported but in which the use of DNSSEC is inappropriate.
-
-
-
-Conrad                      Standards Track                     [Page 2]
-
-RFC 3225         Indicating Resolver Support of DNSSEC     December 2001
-
-
-3. Protocol Changes
-
-   The mechanism chosen for the explicit notification of the ability of
-   the client to accept (if not understand) DNSSEC security RRs is using
-   the most significant bit of the Z field on the EDNS0 OPT header in
-   the query.  This bit is referred to as the "DNSSEC OK" (DO) bit.  In
-   the context of the EDNS0 OPT meta-RR, the DO bit is the first bit of
-   the third and fourth bytes of the "extended RCODE and flags" portion
-   of the EDNS0 OPT meta-RR, structured as follows:
-
-                +0 (MSB)                +1 (LSB)
-         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      0: |   EXTENDED-RCODE      |       VERSION         |
-         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      2: |DO|                    Z                       |
-         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-   Setting the DO bit to one in a query indicates to the server that the
-   resolver is able to accept DNSSEC security RRs.  The DO bit cleared
-   (set to zero) indicates the resolver is unprepared to handle DNSSEC
-   security RRs and those RRs MUST NOT be returned in the response
-   (unless DNSSEC security RRs are explicitly queried for).  The DO bit
-   of the query MUST be copied in the response.
-
-   More explicitly, DNSSEC-aware nameservers MUST NOT insert SIG, KEY,
-   or NXT RRs to authenticate a response as specified in [RFC2535]
-   unless the DO bit was set on the request.  Security records that
-   match an explicit SIG, KEY, NXT, or ANY query, or are part of the
-   zone data for an AXFR or IXFR query, are included whether or not the
-   DO bit was set.
-
-   A recursive DNSSEC-aware server MUST set the DO bit on recursive
-   requests, regardless of the status of the DO bit on the initiating
-   resolver request.  If the initiating resolver request does not have
-   the DO bit set, the recursive DNSSEC-aware server MUST remove DNSSEC
-   security RRs before returning the data to the client, however cached
-   data MUST NOT be modified.
-
-   In the event a server returns a NOTIMP, FORMERR or SERVFAIL response
-   to a query that has the DO bit set, the resolver SHOULD NOT expect
-   DNSSEC security RRs and SHOULD retry the query without EDNS0 in
-   accordance with section 5.3 of [RFC2671].
-
-
-
-
-
-
-
-
-
-Conrad                      Standards Track                     [Page 3]
-
-RFC 3225         Indicating Resolver Support of DNSSEC     December 2001
-
-
-Security Considerations
-
-   The absence of DNSSEC data in response to a query with the DO bit set
-   MUST NOT be taken to mean no security information is available for
-   that zone as the response may be forged or a non-forged response of
-   an altered (DO bit cleared) query.
-
-IANA Considerations
-
-   EDNS0 [RFC2671] defines 16 bits as extended flags in the OPT record,
-   these bits are encoded into the TTL field of the OPT record (RFC2671
-   section 4.6).
-
-   This document reserves one of these bits as the OK bit.  It is
-   requested that the left most bit be allocated.  Thus the USE of the
-   OPT record TTL field would look like
-
-                +0 (MSB)                +1 (LSB)
-         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      0: |   EXTENDED-RCODE      |       VERSION         |
-         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      2: |DO|                    Z                       |
-         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-Acknowledgements
-
-   This document is based on a rough draft by Bob Halley with input from
-   Olafur Gudmundsson, Andreas Gustafsson, Brian Wellington, Randy Bush,
-   Rob Austein, Steve Bellovin, and Erik Nordmark.
-
-References
-
-   [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
-             STD 13, RFC 1034, November 1987.
-
-   [RFC1035] Mockapetris, P., "Domain Names - Implementation and
-             Specifications", STD 13, RFC 1035, November 1987.
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
-             2535, March 1999.
-
-   [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
-             2671, August 1999.
-
-
-
-
-
-Conrad                      Standards Track                     [Page 4]
-
-RFC 3225         Indicating Resolver Support of DNSSEC     December 2001
-
-
-Author's Address
-
-   David Conrad
-   Nominum Inc.
-   950 Charter Street
-   Redwood City, CA 94063
-   USA
-
-   Phone: +1 650 381 6003
-   EMail: david.conrad@nominum.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Conrad                      Standards Track                     [Page 5]
-
-RFC 3225         Indicating Resolver Support of DNSSEC     December 2001
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Conrad                      Standards Track                     [Page 6]
-
diff --git a/contrib/bind9/doc/rfc/rfc3226.txt b/contrib/bind9/doc/rfc/rfc3226.txt
deleted file mode 100644
index dac0e11..0000000
--- a/contrib/bind9/doc/rfc/rfc3226.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                     O. Gudmundsson
-Request for Comments: 3226                                 December 2001
-Updates: 2874, 2535
-Category: Standards Track
-
-
-   DNSSEC and IPv6 A6 aware server/resolver message size requirements
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-Abstract
-
-   This document mandates support for EDNS0 (Extension Mechanisms for
-   DNS) in DNS entities claiming to support either DNS Security
-   Extensions or A6 records.  This requirement is necessary because
-   these new features increase the size of DNS messages.  If EDNS0 is
-   not supported fall back to TCP will happen, having a detrimental
-   impact on query latency and DNS server load.  This document updates
-   RFC 2535 and RFC 2874, by adding new requirements.
-
-1.  Introduction
-
-   Familiarity with the DNS [RFC1034, RFC1035], DNS Security Extensions
-   [RFC2535], EDNS0 [RFC2671] and A6 [RFC2874] is helpful.
-
-   STD 13, RFC 1035 Section 2.3.4 requires that DNS messages over UDP
-   have a data payload of 512 octets or less.  Most DNS software today
-   will not accept larger UDP datagrams.  Any answer that requires more
-   than 512 octets, results in a partial and sometimes useless reply
-   with the Truncation Bit set; in most cases the requester will then
-   retry using TCP.  Furthermore, server delivery of truncated responses
-   varies widely and resolver handling of these responses also varies,
-   leading to additional inefficiencies in handling truncation.
-
-   Compared to UDP, TCP is an expensive protocol to use for a simple
-   transaction like DNS: a TCP connection requires 5 packets for setup
-   and tear down, excluding data packets, thus requiring at least 3
-   round trips on top of the one for the original UDP query.  The DNS
-
-
-
-Gudmundsson                 Standards Track                     [Page 1]
-
-RFC 3226            DNSSEC and IPv6 A6 requirements        December 2001
-
-
-   server also needs to keep a state of the connection during this
-   transaction.  Many DNS servers answer thousands of queries per
-   second, requiring them to use TCP will cause significant overhead and
-   delays.
-
-1.1.  Requirements
-
-   The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
-   in this document are to be interpreted as described in RFC 2119.
-
-2.  Motivating factors
-
-2.1.  DNSSEC motivations
-
-   DNSSEC [RFC2535] secures DNS by adding a Public Key signature on each
-   RR set.  These signatures range in size from about 80 octets to 800
-   octets, most are going to be in the range of 80 to 200 octets.  The
-   addition of signatures on each or most RR sets in an answer
-   significantly increases the size of DNS answers from secure zones.
-
-   For performance reasons and to reduce load on DNS servers, it is
-   important that security aware servers and resolvers get all the data
-   in Answer and Authority section in one query without truncation.
-   Sending Additional Data in the same query is helpful when the server
-   is authoritative for the data, and this reduces round trips.
-
-   DNSSEC OK[OK] specifies how a client can, using EDNS0, indicate that
-   it is interested in receiving DNSSEC records.  The OK bit does not
-   eliminate the need for large answers for DNSSEC capable clients.
-
-2.1.1.  Message authentication or TSIG motivation
-
-   TSIG [RFC2845] allows for the light weight authentication of DNS
-   messages, but increases the size of the messages by at least 70
-   octets.  DNSSEC specifies for computationally expensive message
-   authentication SIG(0) using a standard public key signature.  As only
-   one TSIG or SIG(0) can be attached to each DNS answer the size
-   increase of message authentication is not significant, but may still
-   lead to a truncation.
-
-2.2.  IPv6 Motivations
-
-   IPv6 addresses [RFC2874] are 128 bits and can be represented in the
-   DNS by multiple A6 records, each consisting of a domain name and a
-   bit field.  The domain name refers to an address prefix that may
-   require additional A6 RRs to be included in the answer.  Answers
-   where the queried name has multiple A6 addresses may overflow a 512-
-   octet UDP packet size.
-
-
-
-Gudmundsson                 Standards Track                     [Page 2]
-
-RFC 3226            DNSSEC and IPv6 A6 requirements        December 2001
-
-
-2.3.  Root server and TLD server motivations
-
-   The current number of root servers is limited to 13 as that is the
-   maximum number of name servers and their address records that fit in
-   one 512-octet answer for a SOA record.  If root servers start
-   advertising A6 or KEY records then the answer for the root NS records
-   will not fit in a single 512-octet DNS message, resulting in a large
-   number of TCP query connections to the root servers.  Even if all
-   client resolver query their local name server for information, there
-   are millions of these servers.  Each name server must periodically
-   update its information about the high level servers.
-
-   For redundancy, latency and load balancing reasons, large numbers of
-   DNS servers are required for some zones.  Since the root zone is used
-   by the entire net, it is important to have as many servers as
-   possible.  Large TLDs (and many high-visibility SLDs) often have
-   enough servers that either A6 or KEY records would cause the NS
-   response to overflow the 512 byte limit.  Note that these zones with
-   large numbers of servers are often exactly those zones that are
-   critical to network operation and that already sustain fairly high
-   loads.
-
-2.4.  UDP vs TCP for DNS messages
-
-   Given all these factors, it is essential that any implementation that
-   supports DNSSEC and or A6 be able to use larger DNS messages than 512
-   octets.
-
-   The original 512 restriction was put in place to reduce the
-   probability of fragmentation of DNS responses.  A fragmented UDP
-   message that suffers a loss of one of the fragments renders the
-   answer useless and the query must be retried.  A TCP connection
-   requires a larger number of round trips for establishment, data
-   transfer and tear down, but only the lost data segments are
-   retransmitted.
-
-   In the early days a number of IP implementations did not handle
-   fragmentation well, but all modern operating systems have overcome
-   that issue thus sending fragmented messages is fine from that
-   standpoint.  The open issue is the effect of losses on fragmented
-   messages.  If connection has high loss ratio only TCP will allow
-   reliable transfer of DNS data, most links have low loss ratios thus
-   sending fragmented UDP packet in one round trip is better than
-   establishing a TCP connection to transfer a few thousand octets.
-
-
-
-
-
-
-
-Gudmundsson                 Standards Track                     [Page 3]
-
-RFC 3226            DNSSEC and IPv6 A6 requirements        December 2001
-
-
-2.5.  EDNS0 and large UDP messages
-
-   EDNS0 [RFC2671] allows clients to declare the maximum size of UDP
-   message they are willing to handle.  Thus, if the expected answer is
-   between 512 octets and the maximum size that the client can accept,
-   the additional overhead of a TCP connection can be avoided.
-
-3.  Protocol changes:
-
-   This document updates RFC 2535 and RFC 2874, by adding new
-   requirements.
-
-   All RFC 2535 compliant servers and resolvers MUST support EDNS0 and
-   advertise message size of at least 1220 octets, but SHOULD advertise
-   message size of 4000.  This value might be too low to get full
-   answers for high level servers and successor of this document may
-   require a larger value.
-
-   All RFC 2874 compliant servers and resolver MUST support EDNS0 and
-   advertise message size of at least 1024 octets, but SHOULD advertise
-   message size of 2048.  The IPv6 datagrams should be 1024 octets,
-   unless the MTU of the path is known.  (Note that this is smaller than
-   the minimum IPv6 MTU to allow for some extension headers and/or
-   encapsulation without exceeding the minimum MTU.)
-
-   All RFC 2535 and RFC 2874 compliant entities MUST be able to handle
-   fragmented IPv4 and IPv6 UDP packets.
-
-   All hosts supporting both RFC 2535 and RFC 2874 MUST use the larger
-   required value in EDNS0 advertisements.
-
-4.  Acknowledgments
-
-   Harald Alvestrand, Rob Austein, Randy Bush, David Conrad, Andreas
-   Gustafsson, Jun-ichiro itojun Hagino, Bob Halley, Edward Lewis
-   Michael Patton and Kazu Yamamoto were instrumental in motivating and
-   shaping this document.
-
-5.  Security Considerations:
-
-   There are no additional security considerations other than those in
-   RFC 2671.
-
-6.  IANA Considerations:
-
-   None
-
-
-
-
-
-Gudmundsson                 Standards Track                     [Page 4]
-
-RFC 3226            DNSSEC and IPv6 A6 requirements        December 2001
-
-
-7.  References
-
-   [RFC1034]  Mockapetris, P., "Domain Names - Concepts and Facilities",
-              STD 13, RFC 1034, November 1987.
-
-   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
-              Specification", STD 13, RFC 1035, November 1987.
-
-   [RFC2535]  Eastlake, D. "Domain Name System Security Extensions", RFC
-              2535, March 1999.
-
-   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
-              2671, August 1999.
-
-   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D. and B.
-              Wellington, "Secret Key Transaction Authentication for DNS
-              (TSIG)", RFC 2845, May 2000.
-
-   [RFC2874]  Crawford, M. and C. Huitema, "DNS Extensions to Support
-              IPv6 Address Aggregation and Renumbering", RFC 2874, July
-              2000.
-
-   [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
-              3225, December 2001.
-
-8.  Author Address
-
-   Olafur Gudmundsson
-   3826 Legation Street, NW
-   Washington, DC 20015
-   USA
-
-   EMail: ogud@ogud.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gudmundsson                 Standards Track                     [Page 5]
-
-RFC 3226            DNSSEC and IPv6 A6 requirements        December 2001
-
-
-9.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gudmundsson                 Standards Track                     [Page 6]
-
diff --git a/contrib/bind9/doc/rfc/rfc3258.txt b/contrib/bind9/doc/rfc/rfc3258.txt
deleted file mode 100644
index dcd4b34..0000000
--- a/contrib/bind9/doc/rfc/rfc3258.txt
+++ /dev/null
@@ -1,619 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          T. Hardie
-Request for Comments: 3258                                 Nominum, Inc.
-Category: Informational                                       April 2002
-
-
-  Distributing Authoritative Name Servers via Shared Unicast Addresses
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-Abstract
-
-   This memo describes a set of practices intended to enable an
-   authoritative name server operator to provide access to a single
-   named server in multiple locations.  The primary motivation for the
-   development and deployment of these practices is to increase the
-   distribution of Domain Name System (DNS) servers to previously
-   under-served areas of the network topology and to reduce the latency
-   for DNS  query responses in those areas.
-
-1.  Introduction
-
-   This memo describes a set of practices intended to enable an
-   authoritative name server operator to provide access to a single
-   named server in multiple locations.  The primary motivation for the
-   development and deployment of these practices is to increase the
-   distribution of DNS servers to previously under-served areas of the
-   network topology and to reduce the latency for DNS query responses in
-   those areas.  This document presumes a one-to-one mapping between
-   named authoritative servers and administrative entities (operators).
-   This document contains no guidelines or recommendations for caching
-   name servers.  The shared unicast system described here is specific
-   to IPv4; applicability to IPv6 is an area for further study.  It
-   should also be noted that the system described here is related to
-   that described in [ANYCAST], but it does not require dedicated
-   address space, routing changes, or the other elements of a full
-   anycast infrastructure which that document describes.
-
-
-
-
-
-
-
-Hardie                       Informational                      [Page 1]
-
-RFC 3258        Distributing Authoritative Name Servers       April 2002
-
-
-2.  Architecture
-
-2.1 Server Requirements
-
-   Operators of authoritative name servers may wish to refer to
-   [SECONDARY] and [ROOT] for general guidance on appropriate practice
-   for authoritative name servers.  In addition to proper configuration
-   as a standard authoritative name server, each of the hosts
-   participating in a shared-unicast system should be configured with
-   two network interfaces.  These interfaces may be either two physical
-   interfaces or one physical interface mapped to two logical
-   interfaces.  One of the network interfaces should use the IPv4 shared
-   unicast address associated with the authoritative name server.  The
-   other interface, referred to as the administrative interface below,
-   should use a distinct IPv4 address specific to that host.  The host
-   should respond to DNS queries only on the shared-unicast interface.
-   In order to provide the most consistent set of responses from the
-   mesh of anycast hosts, it is good practice to limit responses on that
-   interface to zones for which the host is authoritative.
-
-2.2 Zone file delivery
-
-   In order to minimize the risk of man-in-the-middle attacks, zone
-   files should be delivered to the administrative interface of the
-   servers participating in the mesh.  Secure file transfer methods and
-   strong authentication should be used for all transfers.  If the hosts
-   in the mesh make their zones available for zone transfer, the
-   administrative interfaces should be used for those transfers as well,
-   in order to avoid the problems with potential routing changes for TCP
-   traffic noted in section 2.5 below.
-
-2.3 Synchronization
-
-   Authoritative name servers may be loosely or tightly synchronized,
-   depending on the practices set by the operating organization.  As
-   noted below in section 4.1.2, lack of synchronization among servers
-   using the same shared unicast address could create problems for some
-   users of this service.  In order to minimize that risk, switch-overs
-   from one data set to another data set should be coordinated as much
-   as possible.  The use of synchronized clocks on the participating
-   hosts and set times for switch-overs provides a basic level of
-   coordination.  A more complete coordination process would involve:
-
-      a) receipt of zones at a distribution host
-      b) confirmation of the integrity of zones received
-      c) distribution of the zones to all of the servers in the mesh
-      d) confirmation of the integrity of the zones at each server
-
-
-
-
-Hardie                       Informational                      [Page 2]
-
-RFC 3258        Distributing Authoritative Name Servers       April 2002
-
-
-      e) coordination of the switchover times for the servers in the
-         mesh
-      f) institution of a failure process to ensure that servers that
-         did not receive correct data or could not switchover to the new
-         data ceased to respond to incoming queries until the problem
-         could be resolved.
-
-   Depending on the size of the mesh, the distribution host may also be
-   a participant; for authoritative servers, it may also be the host on
-   which zones are generated.
-
-   This document presumes that the usual DNS failover methods are the
-   only ones used to ensure reachability of the data for clients.  It
-   does not advise that the routes be withdrawn in the case of failure;
-   it advises instead that the DNS process shutdown so that servers on
-   other addresses are queried.  This recommendation reflects a choice
-   between performance and operational complexity.  While it would be
-   possible to have some process withdraw the route for a specific
-   server instance when it is not available, there is considerable
-   operational complexity involved in ensuring that this occurs
-   reliably.  Given the existing DNS failover methods, the marginal
-   improvement in performance will not be sufficient to justify the
-   additional complexity for most uses.
-
-2.4 Server Placement
-
-   Though the geographic diversity of server placement helps reduce the
-   effects of service disruptions due to local problems, it is diversity
-   of placement in the network topology which is the driving force
-   behind these distribution practices.  Server placement should
-   emphasize that diversity.  Ideally, servers should be placed
-   topologically near the points at which the operator exchanges routes
-   and traffic with other networks.
-
-2.5 Routing
-
-   The organization administering the mesh of servers sharing a unicast
-   address must have an autonomous system number and speak BGP to its
-   peers.  To those peers, the organization announces a route to the
-   network containing the shared-unicast address of the name server.
-   The organization's border routers must then deliver the traffic
-   destined for the name server to the nearest instantiation.  Routing
-   to the administrative interfaces for the servers can use the normal
-   routing methods for the administering organization.
-
-   One potential problem with using shared unicast addresses is that
-   routers forwarding traffic to them may have more than one available
-   route, and those routes may, in fact, reach different instances of
-
-
-
-Hardie                       Informational                      [Page 3]
-
-RFC 3258        Distributing Authoritative Name Servers       April 2002
-
-
-   the shared unicast address.  Applications like the DNS, whose
-   communication typically consists of independent request-response
-   messages each fitting in a single UDP packet present no problem.
-   Other applications, in which multiple packets must reach the same
-   endpoint (e.g., TCP) may fail or present unworkable performance
-   characteristics in some circumstances.  Split-destination failures
-   may occur when a router does per-packet (or round-robin) load
-   sharing, a topology change occurs that changes the relative metrics
-   of two paths to the same anycast destination, etc.
-
-   Four things mitigate the severity of this problem.  The first is that
-   UDP is a fairly high proportion of the query traffic to name servers.
-   The second is that the aim of this proposal is to diversify
-   topological placement; for most users, this means that the
-   coordination of placement will ensure that new instances of a name
-   server will be at a significantly different cost metric from existing
-   instances.  Some set of users may end up in the middle, but that
-   should be relatively rare.  The third is that per packet load sharing
-   is only one of the possible load sharing mechanisms, and other
-   mechanisms are increasing in popularity.
-
-   Lastly, in the case where the traffic is TCP, per packet load sharing
-   is used, and equal cost routes to different instances of a name
-   server are available, any DNS implementation which measures the
-   performance of servers to select a preferred server will quickly
-   prefer a server for which this problem does not occur.  For the DNS
-   failover mechanisms to reliably avoid this problem, however, those
-   using shared unicast distribution mechanisms must take care that all
-   of the servers for a specific zone are not participants in the same
-   shared-unicast mesh.  To guard even against the case where multiple
-   meshes have a set of users affected by per packet load sharing along
-   equal cost routes, organizations implementing these practices should
-   always provide at least one authoritative server which is not a
-   participant in any shared unicast mesh.  Those deploying shared-
-   unicast meshes should note that any specific host may become
-   unreachable to a client should a server fail, a path fail, or the
-   route to that host be withdrawn.  These error conditions are,
-   however, not specific to shared-unicast distributions, but would
-   occur for standard unicast hosts.
-
-   Since ICMP response packets might go to a different member of the
-   mesh than that sending a packet, packets sent with a shared unicast
-   source address should also avoid using path MTU discovery.
-
-   Appendix A. contains an ASCII diagram of an example of a simple
-   implementation of this system.  In it, the odd numbered routers
-   deliver traffic to the shared-unicast interface network and filter
-   traffic from the administrative network; the even numbered routers
-
-
-
-Hardie                       Informational                      [Page 4]
-
-RFC 3258        Distributing Authoritative Name Servers       April 2002
-
-
-   deliver traffic to the administrative network and filter traffic from
-   the shared-unicast network.  These are depicted as separate routers
-   for the ease this gives in explanation, but they could easily be
-   separate interfaces on the same router.  Similarly, a local NTP
-   source is depicted for synchronization, but the level of
-   synchronization needed would not require that source to be either
-   local or a stratum one NTP server.
-
-3. Administration
-
-3.1 Points of Contact
-
-   A single point of contact for reporting problems is crucial to the
-   correct administration of this system.  If an external user of the
-   system needs to report a problem related to the service, there must
-   be no ambiguity about whom to contact.  If internal monitoring does
-   not indicate a problem, the contact may, of course, need to work with
-   the external user to identify which server generated the error.
-
-4. Security Considerations
-
-   As a core piece of Internet infrastructure, authoritative name
-   servers are common targets of attack.  The practices outlined here
-   increase the risk of certain kinds of attacks and reduce the risk of
-   others.
-
-4.1 Increased Risks
-
-4.1.1 Increase in physical servers
-
-   The architecture outlined in this document increases the number of
-   physical servers, which could increase the possibility that a server
-   mis-configuration will occur which allows for a security breach.  In
-   general, the entity administering a mesh should ensure that patches
-   and security mechanisms applied to a single member of the mesh are
-   appropriate for and applied to all of the members of a mesh.
-   "Genetic diversity" (code from different code bases) can be a useful
-   security measure in avoiding attacks based on vulnerabilities in a
-   specific code base; in order to ensure consistency of responses from
-   a single named server, however, that diversity should be applied to
-   different shared-unicast meshes or between a mesh and a related
-   unicast authoritative server.
-
-4.1.2 Data synchronization problems
-
-   The level of systemic synchronization described above should be
-   augmented by synchronization of the data present at each of the
-   servers.  While the DNS itself is a loosely coupled system, debugging
-
-
-
-Hardie                       Informational                      [Page 5]
-
-RFC 3258        Distributing Authoritative Name Servers       April 2002
-
-
-   problems with data in specific zones would be far more difficult if
-   two different servers sharing a single unicast address might return
-   different responses to the same query.  For example, if the data
-   associated with www.example.com has changed and the administrators of
-   the domain are testing for the changes at the example.com
-   authoritative name servers, they should not need to check each
-   instance of a named authoritative server.  The use of NTP to provide
-   a synchronized time for switch-over eliminates some aspects of this
-   problem, but mechanisms to handle failure during the switchover are
-   required.  In particular, a server which cannot make the switchover
-   must not roll-back to a previous version; it must cease to respond to
-   queries so that other servers are queried.
-
-4.1.3 Distribution risks
-
-   If the mechanism used to distribute zone files among the servers is
-   not well secured, a man-in-the-middle attack could result in the
-   injection of false information.  Digital signatures will alleviate
-   this risk, but encrypted transport and tight access lists are a
-   necessary adjunct to them.  Since zone files will be distributed to
-   the administrative interfaces of meshed servers, the access control
-   list for distribution of the zone files should include the
-   administrative interface of the server or servers, rather than their
-   shared unicast addresses.
-
-4.2 Decreased Risks
-
-   The increase in number of physical servers reduces the likelihood
-   that a denial-of-service attack will take out a significant portion
-   of the DNS infrastructure.  The increase in servers also reduces the
-   effect of machine crashes, fiber cuts, and localized disasters by
-   reducing the number of users dependent on a specific machine.
-
-5. Acknowledgments
-
-   Masataka Ohta, Bill Manning, Randy Bush, Chris Yarnell, Ray Plzak,
-   Mark Andrews, Robert Elz, Geoff Huston, Bill Norton, Akira Kato,
-   Suzanne Woolf, Bernard Aboba, Casey Ajalat, and Gunnar Lindberg all
-   provided input and commentary on this work.  The editor wishes to
-   remember in particular the contribution of the late Scott Tucker,
-   whose extensive systems experience and plain common sense both
-   contributed greatly to the editor's own deployment experience and are
-   missed by all who knew him.
-
-
-
-
-
-
-
-
-Hardie                       Informational                      [Page 6]
-
-RFC 3258        Distributing Authoritative Name Servers       April 2002
-
-
-6. References
-
-   [SECONDARY] Elz, R., Bush, R., Bradner, S. and M. Patton, "Selection
-               and Operation of Secondary DNS Servers", BCP 16, RFC
-               2182, July 1997.
-
-   [ROOT]      Bush, R., Karrenberg, D., Kosters, M. and R. Plzak, "Root
-               Name Server Operational Requirements", BCP 40, RFC 2870,
-               June 2000.
-
-   [ANYCAST]   Patridge, C., Mendez, T. and W. Milliken, "Host
-               Anycasting Service", RFC 1546, November 1993.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardie                       Informational                      [Page 7]
-
-RFC 3258        Distributing Authoritative Name Servers       April 2002
-
-
-Appendix A.
-
-       __________________
-Peer 1-|                |
-Peer 2-|                |
-Peer 3-|     Switch     |
-Transit|                |  _________                   _________
-etc    |                |--|Router1|---|----|----------|Router2|---WAN-|
-       |                |  ---------   |    |          ---------       |
-       |                |              |    |                          |
-       |                |              |    |                          |
-       ------------------            [NTP] [DNS]                       |
-                                                                       |
-                                                                       |
-                                                                       |
-                                                                       |
-       __________________                                              |
-Peer 1-|                |                                              |
-Peer 2-|                |                                              |
-Peer 3-|     Switch     |                                              |
-Transit|                |  _________                   _________       |
-etc    |                |--|Router3|---|----|----------|Router4|---WAN-|
-       |                |  ---------   |    |          ---------       |
-       |                |              |    |                          |
-       |                |              |    |                          |
-       ------------------            [NTP] [DNS]                       |
-                                                                       |
-                                                                       |
-                                                                       |
-                                                                       |
-       __________________                                              |
-Peer 1-|                |                                              |
-Peer 2-|                |                                              |
-Peer 3-|     Switch     |                                              |
-Transit|                |  _________                   _________       |
-etc    |                |--|Router5|---|----|----------|Router6|---WAN-|
-       |                |  ---------   |    |          ---------       |
-       |                |              |    |                          |
-       |                |              |    |                          |
-       ------------------            [NTP] [DNS]                       |
-                                                                       |
-                                                                       |
-                                                                       |
-
-
-
-
-
-
-
-
-Hardie                       Informational                      [Page 8]
-
-RFC 3258        Distributing Authoritative Name Servers       April 2002
-
-
-                                                                       |
-       __________________                                              |
-Peer 1-|                |                                              |
-Peer 2-|                |                                              |
-Peer 3-|     Switch     |                                              |
-Transit|                |  _________                   _________       |
-etc    |                |--|Router7|---|----|----------|Router8|---WAN-|
-       |                |  ---------   |    |          ---------
-       |                |              |    |
-       |                |              |    |
-       ------------------            [NTP] [DNS]
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardie                       Informational                      [Page 9]
-
-RFC 3258        Distributing Authoritative Name Servers       April 2002
-
-
-7. Editor's Address
-
-   Ted Hardie
-   Nominum, Inc.
-   2385 Bay Road.
-   Redwood City, CA 94063
-
-   Phone: 1.650.381.6226
-   EMail: Ted.Hardie@nominum.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardie                       Informational                     [Page 10]
-
-RFC 3258        Distributing Authoritative Name Servers       April 2002
-
-
-8.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardie                       Informational                     [Page 11]
-
diff --git a/contrib/bind9/doc/rfc/rfc3363.txt b/contrib/bind9/doc/rfc/rfc3363.txt
deleted file mode 100644
index 9d7a39c..0000000
--- a/contrib/bind9/doc/rfc/rfc3363.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                            R. Bush
-Request for Comments: 3363                                     A. Durand
-Updates: 2673, 2874                                              B. Fink
-Category: Informational                                   O. Gudmundsson
-                                                                 T. Hain
-                                                                 Editors
-                                                             August 2002
-
-
-            Representing Internet Protocol version 6 (IPv6)
-               Addresses in the Domain Name System (DNS)
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-Abstract
-
-   This document clarifies and updates the standards status of RFCs that
-   define direct and reverse map of IPv6 addresses in DNS.  This
-   document moves the A6 and Bit label specifications to experimental
-   status.
-
-1.  Introduction
-
-   The IETF had begun the process of standardizing two different address
-   formats for IPv6 addresses AAAA [RFC1886] and A6 [RFC2874] and both
-   are at proposed standard.  This had led to confusion and conflicts on
-   which one to deploy.  It is important for deployment that any
-   confusion in this area be cleared up, as there is a feeling in the
-   community that having more than one choice will lead to delays in the
-   deployment of IPv6.  The goal of this document is to clarify the
-   situation.
-
-   This document also discusses issues relating to the usage of Binary
-   Labels [RFC 2673] to support the reverse mapping of IPv6 addresses.
-
-   This document is based on extensive technical discussion on various
-   relevant working groups mailing lists and a joint DNSEXT and NGTRANS
-   meeting at the 51st IETF in August 2001.  This document attempts to
-   capture the sense of the discussions and reflect them in this
-   document to represent the consensus of the community.
-
-
-
-Bush, et. al.                Informational                      [Page 1]
-
-RFC 3363        Representation of IPv6 Addresses in DNS      August 2002
-
-
-   The main arguments and the issues are covered in a separate document
-   [RFC3364] that reflects the current understanding of the issues.
-   This document summarizes the outcome of these discussions.
-
-   The issue of the root of reverse IPv6 address map is outside the
-   scope of this document and is covered in a different document
-   [RFC3152].
-
-1.1 Standards Action Taken
-
-   This document changes the status of RFCs 2673 and 2874 from Proposed
-   Standard to Experimental.
-
-2.  IPv6 Addresses: AAAA RR vs A6 RR
-
-   Working group consensus as perceived by the chairs of the DNSEXT and
-   NGTRANS working groups is that:
-
-   a) AAAA records are preferable at the moment for production
-      deployment of IPv6, and
-
-   b) that A6 records have interesting properties that need to be better
-      understood before deployment.
-
-   c) It is not known if the benefits of A6 outweigh the costs and
-      risks.
-
-2.1 Rationale
-
-   There are several potential issues with A6 RRs that stem directly
-   from the feature that makes them different from AAAA RRs: the ability
-   to build up addresses via chaining.
-
-   Resolving a chain of A6 RRs involves resolving a series of what are
-   nearly-independent queries.  Each of these sub-queries takes some
-   non-zero amount of time, unless the answer happens to be in the
-   resolver's local cache already.  Other things being equal, we expect
-   that the time it takes to resolve an N-link chain of A6 RRs will be
-   roughly proportional to N.  What data we have suggests that users are
-   already impatient with the length of time it takes to resolve A RRs
-   in the IPv4 Internet, which suggests that users are not likely to be
-   patient with significantly longer delays in the IPv6 Internet, but
-   terminating queries prematurely is both a waste of resources and
-   another source of user frustration.  Thus, we are forced to conclude
-   that indiscriminate use of long A6 chains is likely to lead to
-   increased user frustration.
-
-
-
-
-
-Bush, et. al.                Informational                      [Page 2]
-
-RFC 3363        Representation of IPv6 Addresses in DNS      August 2002
-
-
-   The probability of failure during the process of resolving an N-link
-   A6 chain also appears to be roughly proportional to N, since each of
-   the queries involved in resolving an A6 chain has roughly the same
-   probability of failure as a single AAAA query.
-
-   Last, several of the most interesting potential applications for A6
-   RRs involve situations where the prefix name field in the A6 RR
-   points to a target that is not only outside the DNS zone containing
-   the A6 RR, but is administered by a different organization entirely.
-   While pointers out of zone are not a problem per se, experience both
-   with glue RRs and with PTR RRs in the IN-ADDR.ARPA tree suggests that
-   pointers to other organizations are often not maintained properly,
-   perhaps because they're less susceptible to automation than pointers
-   within a single organization would be.
-
-2.2 Recommended Standard Action
-
-   Based on the perceived consensus, this document recommends that RFC
-   1886 stay on standards track and be advanced, while moving RFC 2874
-   to Experimental status.
-
-3.  Bitlabels in the Reverse DNS Tree
-
-   RFC 2673 defines a new DNS label type.  This was the first new type
-   defined since RFC 1035 [RFC1035].  Since the development of 2673 it
-   has been learned that deployment of a new type is difficult since DNS
-   servers that do not support bitlabels reject queries containing bit
-   labels as being malformed.  The community has also indicated that
-   this new label type is not needed for mapping reverse addresses.
-
-3.1 Rationale
-
-   The hexadecimal text representation of IPv6 addresses appears to be
-   capable of expressing all of the delegation schemes that we expect to
-   be used in the DNS reverse tree.
-
-3.2 Recommended Standard Action
-
-   RFC 2673 standard status is to be changed from Proposed to
-   Experimental.  Future standardization of these documents is to be
-   done by the DNSEXT working group or its successor.
-
-
-
-
-
-
-
-
-
-
-Bush, et. al.                Informational                      [Page 3]
-
-RFC 3363        Representation of IPv6 Addresses in DNS      August 2002
-
-
-4.  DNAME in IPv6 Reverse Tree
-
-   The issues for DNAME in the reverse mapping tree appears to be
-   closely tied to the need to use fragmented A6 in the main tree: if
-   one is necessary, so is the other, and if one isn't necessary, the
-   other isn't either.  Therefore, in moving RFC 2874 to experimental,
-   the intent of this document is that use of DNAME RRs in the reverse
-   tree be deprecated.
-
-5.  Acknowledgments
-
-   This document is based on input from many members of the various IETF
-   working groups involved in this issues.  Special thanks go to the
-   people that prepared reading material for the joint DNSEXT and
-   NGTRANS working group meeting at the 51st IETF in London, Rob
-   Austein, Dan Bernstein, Matt Crawford, Jun-ichiro itojun Hagino,
-   Christian Huitema.  Number of other people have made number of
-   comments on mailing lists about this issue including Andrew W.
-   Barclay, Robert Elz, Johan Ihren, Edward Lewis, Bill Manning, Pekka
-   Savola, Paul Vixie.
-
-6.  Security Considerations
-
-   As this document specifies a course of action, there are no direct
-   security considerations.  There is an indirect security impact of the
-   choice, in that the relationship between A6 and DNSSEC is not well
-   understood throughout the community, while the choice of AAAA does
-   leads to a model for use of DNSSEC in IPv6 networks which parallels
-   current IPv4 practice.
-
-7.  IANA Considerations
-
-   None.
-
-Normative References
-
-   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
-              Specification", STD 13, RFC 1035, November 1987.
-
-   [RFC1886]  Thompson, S. and C. Huitema, "DNS Extensions to support IP
-              version 6", RFC 1886, December 1995.
-
-   [RFC2673]  Crawford, M., "Binary Labels in the Domain Name System",
-              RFC 2673, August 1999.
-
-   [RFC2874]  Crawford, M. and C. Huitema, "DNS Extensions to Support
-              IPv6 Address Aggregation and Renumbering", RFC 2874, July
-              2000.
-
-
-
-Bush, et. al.                Informational                      [Page 4]
-
-RFC 3363        Representation of IPv6 Addresses in DNS      August 2002
-
-
-   [RFC3152]  Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152
-              August 2001.
-
-Informative References
-
-   [RFC3364]  Austein, R., "Tradeoffs in Domain Name System (DNS)
-              Support for Internet Protocol version 6 (IPv6)", RFC 3364,
-              August 2002.
-
-Editors' Addresses
-
-   Randy Bush
-   EMail: randy@psg.com
-
-
-   Alain Durand
-   EMail: alain.durand@sun.com
-
-
-   Bob Fink
-   EMail: fink@es.net
-
-
-   Olafur Gudmundsson
-   EMail: ogud@ogud.com
-
-
-   Tony Hain
-   EMail: hain@tndh.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bush, et. al.                Informational                      [Page 5]
-
-RFC 3363        Representation of IPv6 Addresses in DNS      August 2002
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bush, et. al.                Informational                      [Page 6]
-
diff --git a/contrib/bind9/doc/rfc/rfc3364.txt b/contrib/bind9/doc/rfc/rfc3364.txt
deleted file mode 100644
index 189c0d2..0000000
--- a/contrib/bind9/doc/rfc/rfc3364.txt
+++ /dev/null
@@ -1,619 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         R. Austein
-Request for Comments: 3364                           Bourgeois Dilettant
-Updates: 2673, 2874                                          August 2002
-Category: Informational
-
-
-             Tradeoffs in Domain Name System (DNS) Support
-                 for Internet Protocol version 6 (IPv6)
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-Abstract
-
-   The IETF has two different proposals on the table for how to do DNS
-   support for IPv6, and has thus far failed to reach a clear consensus
-   on which approach is better.  This note attempts to examine the pros
-   and cons of each approach, in the hope of clarifying the debate so
-   that we can reach closure and move on.
-
-Introduction
-
-   RFC 1886 [RFC1886] specified straightforward mechanisms to support
-   IPv6 addresses in the DNS.  These mechanisms closely resemble the
-   mechanisms used to support IPv4, with a minor improvement to the
-   reverse mapping mechanism based on experience with CIDR.  RFC 1886 is
-   currently listed as a Proposed Standard.
-
-   RFC 2874 [RFC2874] specified enhanced mechanisms to support IPv6
-   addresses in the DNS.  These mechanisms provide new features that
-   make it possible for an IPv6 address stored in the DNS to be broken
-   up into multiple DNS resource records in ways that can reflect the
-   network topology underlying the address, thus making it possible for
-   the data stored in the DNS to reflect certain kinds of network
-   topology changes or routing architectures that are either impossible
-   or more difficult to represent without these mechanisms.  RFC 2874 is
-   also currently listed as a Proposed Standard.
-
-
-
-
-
-
-
-Austein                      Informational                      [Page 1]
-
-RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
-
-
-   Both of these Proposed Standards were the output of the IPNG Working
-   Group.  Both have been implemented, although implementation of
-   [RFC1886] is more widespread, both because it was specified earlier
-   and because it's simpler to implement.
-
-   There's little question that the mechanisms proposed in [RFC2874] are
-   more general than the mechanisms proposed in [RFC1886], and that
-   these enhanced mechanisms might be valuable if IPv6's evolution goes
-   in certain directions.  The questions are whether we really need the
-   more general mechanism, what new usage problems might come along with
-   the enhanced mechanisms, and what effect all this will have on IPv6
-   deployment.
-
-   The one thing on which there does seem to be widespread agreement is
-   that we should make up our minds about all this Real Soon Now.
-
-Main Advantages of Going with A6
-
-   While the A6 RR proposed in [RFC2874] is very general and provides a
-   superset of the functionality provided by the AAAA RR in [RFC1886],
-   many of the features of A6 can also be implemented with AAAA RRs via
-   preprocessing during zone file generation.
-
-   There is one specific area where A6 RRs provide something that cannot
-   be provided using AAAA RRs: A6 RRs can represent addresses in which a
-   prefix portion of the address can change without any action (or
-   perhaps even knowledge) by the parties controlling the DNS zone
-   containing the terminal portion (least significant bits) of the
-   address.  This includes both so-called "rapid renumbering" scenarios
-   (where an entire network's prefix may change very quickly) and
-   routing architectures such as the former "GSE" proposal [GSE] (where
-   the "routing goop" portion of an address may be subject to change
-   without warning).  A6 RRs do not completely remove the need to update
-   leaf zones during all renumbering events (for example, changing ISPs
-   would usually require a change to the upward delegation pointer), but
-   careful use of A6 RRs could keep the number of RRs that need to
-   change during such an event to a minimum.
-
-   Note that constructing AAAA RRs via preprocessing during zone file
-   generation requires exactly the sort of information that A6 RRs store
-   in the DNS.  This begs the question of where the hypothetical
-   preprocessor obtains that information if it's not getting it from the
-   DNS.
-
-   Note also that the A6 RR, when restricted to its zero-length-prefix
-   form ("A6 0"), is semantically equivalent to an AAAA RR (with one
-   "wasted" octet in the wire representation), so anything that can be
-   done with an AAAA RR can also be done with an A6 RR.
-
-
-
-Austein                      Informational                      [Page 2]
-
-RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
-
-
-Main Advantages of Going with AAAA
-
-   The AAAA RR proposed in [RFC1886], while providing only a subset of
-   the functionality provided by the A6 RR proposed in [RFC2874], has
-   two main points to recommend it:
-
-   - AAAA RRs are essentially identical (other than their length) to
-     IPv4's A RRs, so we have more than 15 years of experience to help
-     us predict the usage patterns, failure scenarios and so forth
-     associated with AAAA RRs.
-
-   - The AAAA RR is "optimized for read", in the sense that, by storing
-     a complete address rather than making the resolver fetch the
-     address in pieces, it minimizes the effort involved in fetching
-     addresses from the DNS (at the expense of increasing the effort
-     involved in injecting new data into the DNS).
-
-Less Compelling Arguments in Favor of A6
-
-   Since the A6 RR allows a zone administrator to write zone files whose
-   description of addresses maps to the underlying network topology, A6
-   RRs can be construed as a "better" way of representing addresses than
-   AAAA.  This may well be a useful capability, but in and of itself
-   it's more of an argument for better tools for zone administrators to
-   use when constructing zone files than a justification for changing
-   the resolution protocol used on the wire.
-
-Less Compelling Arguments in Favor of AAAA
-
-   Some of the pressure to go with AAAA instead of A6 appears to be
-   based on the wider deployment of AAAA.  Since it is possible to
-   construct transition tools (see discussion of AAAA synthesis, later
-   in this note), this does not appear to be a compelling argument if A6
-   provides features that we really need.
-
-   Another argument in favor of AAAA RRs over A6 RRs appears to be that
-   the A6 RR's advanced capabilities increase the number of ways in
-   which a zone administrator could build a non-working configuration.
-   While operational issues are certainly important, this is more of
-   argument that we need better tools for zone administrators than it is
-   a justification for turning away from A6 if A6 provides features that
-   we really need.
-
-
-
-
-
-
-
-
-
-Austein                      Informational                      [Page 3]
-
-RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
-
-
-Potential Problems with A6
-
-   The enhanced capabilities of the A6 RR, while interesting, are not in
-   themselves justification for choosing A6 if we don't really need
-   those capabilities.  The A6 RR is "optimized for write", in the sense
-   that, by making it possible to store fragmented IPv6 addresses in the
-   DNS, it makes it possible to reduce the effort that it takes to
-   inject new data into the DNS (at the expense of increasing the effort
-   involved in fetching data from the DNS).  This may be justified if we
-   expect the effort involved in maintaining AAAA-style DNS entries to
-   be prohibitive, but in general, we expect the DNS data to be read
-   more frequently than it is written, so we need to evaluate this
-   particular tradeoff very carefully.
-
-   There are also several potential issues with A6 RRs that stem
-   directly from the feature that makes them different from AAAA RRs:
-   the ability to build up address via chaining.
-
-   Resolving a chain of A6 RRs involves resolving a series of what are
-   almost independent queries, but not quite.  Each of these sub-queries
-   takes some non-zero amount of time, unless the answer happens to be
-   in the resolver's local cache already.  Assuming that resolving an
-   AAAA RR takes time T as a baseline, we can guess that, on the
-   average, it will take something approaching time N*T to resolve an
-   N-link chain of A6 RRs, although we would expect to see a fairly good
-   caching factor for the A6 fragments representing the more significant
-   bits of an address.  This leaves us with two choices, neither of
-   which is very good:  we can decrease the amount of time that the
-   resolver is willing to wait for each fragment, or we can increase the
-   amount of time that a resolver is willing to wait before returning
-   failure to a client.  What little data we have on this subject
-   suggests that users are already impatient with the length of time it
-   takes to resolve A RRs in the IPv4 Internet, which suggests that they
-   are not likely to be patient with significantly longer delays in the
-   IPv6 Internet.  At the same time, terminating queries prematurely is
-   both a waste of resources and another source of user frustration.
-   Thus, we are forced to conclude that indiscriminate use of long A6
-   chains is likely to lead to problems.
-
-   To make matters worse, the places where A6 RRs are likely to be most
-   critical for rapid renumbering or GSE-like routing are situations
-   where the prefix name field in the A6 RR points to a target that is
-   not only outside the DNS zone containing the A6 RR, but is
-   administered by a different organization (for example, in the case of
-   an end user's site, the prefix name will most likely point to a name
-   belonging to an ISP that provides connectivity for the site).  While
-   pointers out of zone are not a problem per se, pointers to other
-   organizations are somewhat more difficult to maintain and less
-
-
-
-Austein                      Informational                      [Page 4]
-
-RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
-
-
-   susceptible to automation than pointers within a single organization
-   would be.  Experience both with glue RRs and with PTR RRs in the IN-
-   ADDR.ARPA tree suggests that many zone administrators do not really
-   understand how to set up and maintain these pointers properly, and we
-   have no particular reason to believe that these zone administrators
-   will do a better job with A6 chains than they do today.  To be fair,
-   however, the alternative case of building AAAA RRs via preprocessing
-   before loading zones has many of the same problems; at best, one can
-   claim that using AAAA RRs for this purpose would allow DNS clients to
-   get the wrong answer somewhat more efficiently than with A6 RRs.
-
-   Finally, assuming near total ignorance of how likely a query is to
-   fail, the probability of failure with an N-link A6 chain would appear
-   to be roughly proportional to N, since each of the queries involved
-   in resolving an A6 chain would have the same probability of failure
-   as a single AAAA query.  Note again that this comment applies to
-   failures in the the process of resolving a query, not to the data
-   obtained via that process.  Arguably, in an ideal world, A6 RRs would
-   increase the probability of the answer a client (finally) gets being
-   right, assuming that nothing goes wrong in the query process, but we
-   have no real idea how to quantify that assumption at this point even
-   to the hand-wavey extent used elsewhere in this note.
-
-   One potential problem that has been raised in the past regarding A6
-   RRs turns out not to be a serious issue.  The A6 design includes the
-   possibility of there being more than one A6 RR matching the prefix
-   name portion of a leaf A6 RR.  That is, an A6 chain may not be a
-   simple linked list, it may in fact be a tree, where each branch
-   represents a possible prefix.  Some critics of A6 have been concerned
-   that this will lead to a wild expansion of queries, but this turns
-   out not to be a problem if a resolver simply follows the "bounded
-   work per query" rule described in RFC 1034 (page 35).  That rule
-   applies to all work resulting from attempts to process a query,
-   regardless of whether it's a simple query, a CNAME chain, an A6 tree,
-   or an infinite loop.  The client may not get back a useful answer in
-   cases where the zone has been configured badly, but a proper
-   implementation should not produce a query explosion as a result of
-   processing even the most perverse A6 tree, chain, or loop.
-
-Interactions with DNSSEC
-
-   One of the areas where AAAA and A6 RRs differ is in the precise
-   details of how they interact with DNSSEC.  The following comments
-   apply only to non-zero-prefix A6 RRs (A6 0 RRs, once again, are
-   semantically equivalent to AAAA RRs).
-
-
-
-
-
-
-Austein                      Informational                      [Page 5]
-
-RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
-
-
-   Other things being equal, the time it takes to re-sign all of the
-   addresses in a zone after a renumbering event is longer with AAAA RRs
-   than with A6 RRs (because each address record has to be re-signed
-   rather than just signing a common prefix A6 RR and a few A6 0 RRs
-   associated with the zone's name servers).  Note, however, that in
-   general this does not present a serious scaling problem, because the
-   re-signing is performed in the leaf zones.
-
-   Other things being equal, there's more work involved in verifying the
-   signatures received back for A6 RRs, because each address fragment
-   has a separate associated signature.  Similarly, a DNS message
-   containing a set of A6 address fragments and their associated
-   signatures will be larger than the equivalent packet with a single
-   AAAA (or A6 0) and a single associated signature.
-
-   Since AAAA RRs cannot really represent rapid renumbering or GSE-style
-   routing scenarios very well, it should not be surprising that DNSSEC
-   signatures of AAAA RRs are also somewhat problematic.  In cases where
-   the AAAA RRs would have to be changing very quickly to keep up with
-   prefix changes, the time required to re-sign the AAAA RRs may be
-   prohibitive.
-
-   Empirical testing by Bill Sommerfeld [Sommerfeld] suggests that
-   333MHz Celeron laptop with 128KB L2 cache and 64MB RAM running the
-   BIND-9 dnssec-signzone program under NetBSD can generate roughly 40
-   1024-bit RSA signatures per second.  Extrapolating from this,
-   assuming one A RR, one AAAA RR, and one NXT RR per host, this
-   suggests that it would take this laptop a few hours to sign a zone
-   listing 10**5 hosts, or about a day to sign a zone listing 10**6
-   hosts using AAAA RRs.
-
-   This suggests that the additional effort of re-signing a large zone
-   full of AAAA RRs during a re-numbering event, while noticeable, is
-   only likely to be prohibitive in the rapid renumbering case where
-   AAAA RRs don't work well anyway.
-
-Interactions with Dynamic Update
-
-   DNS dynamic update appears to work equally well for AAAA or A6 RRs,
-   with one minor exception: with A6 RRs, the dynamic update client
-   needs to know the prefix length and prefix name.  At present, no
-   mechanism exists to inform a dynamic update client of these values,
-   but presumably such a mechanism could be provided via an extension to
-   DHCP, or some other equivalent could be devised.
-
-
-
-
-
-
-
-Austein                      Informational                      [Page 6]
-
-RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
-
-
-Transition from AAAA to A6 Via AAAA Synthesis
-
-   While AAAA is at present more widely deployed than A6, it is possible
-   to transition from AAAA-aware DNS software to A6-aware DNS software.
-   A rough plan for this was presented at IETF-50 in Minneapolis and has
-   been discussed on the ipng mailing list.  So if the IETF concludes
-   that A6's enhanced capabilities are necessary, it should be possible
-   to transition from AAAA to A6.
-
-   The details of this transition have been left to a separate document,
-   but the general idea is that the resolver that is performing
-   iterative resolution on behalf of a DNS client program could
-   synthesize AAAA RRs representing the result of performing the
-   equivalent A6 queries.  Note that in this case it is not possible to
-   generate an equivalent DNSSEC signature for the AAAA RR, so clients
-   that care about performing DNSSEC validation for themselves would
-   have to issue A6 queries directly rather than relying on AAAA
-   synthesis.
-
-Bitlabels
-
-   While the differences between AAAA and A6 RRs have generated most of
-   the discussion to date, there are also two proposed mechanisms for
-   building the reverse mapping tree (the IPv6 equivalent of IPv4's IN-
-   ADDR.ARPA tree).
-
-   [RFC1886] proposes a mechanism very similar to the IN-ADDR.ARPA
-   mechanism used for IPv4 addresses: the RR name is the hexadecimal
-   representation of the IPv6 address, reversed and concatenated with a
-   well-known suffix, broken up with a dot between each hexadecimal
-   digit.  The resulting DNS names are somewhat tedious for humans to
-   type, but are very easy for programs to generate.  Making each
-   hexadecimal digit a separate label means that delegation on arbitrary
-   bit boundaries will result in a maximum of 16 NS RRsets per label
-   level; again, the mechanism is somewhat tedious for humans, but is
-   very easy to program.  As with IPv4's IN-ADDR.ARPA tree, the one
-   place where this scheme is weak is in handling delegations in the
-   least significant label; however, since there appears to be no real
-   need to delegate the least significant four bits of an IPv6 address,
-   this does not appear to be a serious restriction.
-
-   [RFC2874] proposed a radically different way of naming entries in the
-   reverse mapping tree: rather than using textual representations of
-   addresses, it proposes to use a new kind of DNS label (a "bit label")
-   to represent binary addresses directly in the DNS.  This has the
-   advantage of being significantly more compact than the textual
-   representation, and arguably might have been a better solution for
-   DNS to use for this purpose if it had been designed into the protocol
-
-
-
-Austein                      Informational                      [Page 7]
-
-RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
-
-
-   from the outset.  Unfortunately, experience to date suggests that
-   deploying a new DNS label type is very hard: all of the DNS name
-   servers that are authoritative for any portion of the name in
-   question must be upgraded before the new label type can be used, as
-   must any resolvers involved in the resolution process.  Any name
-   server that has not been upgraded to understand the new label type
-   will reject the query as being malformed.
-
-   Since the main benefit of the bit label approach appears to be an
-   ability that we don't really need (delegation in the least
-   significant four bits of an IPv6 address), and since the upgrade
-   problem is likely to render bit labels unusable until a significant
-   portion of the DNS code base has been upgraded, it is difficult to
-   escape the conclusion that the textual solution is good enough.
-
-DNAME RRs
-
-   [RFC2874] also proposes using DNAME RRs as a way of providing the
-   equivalent of A6's fragmented addresses in the reverse mapping tree.
-   That is, by using DNAME RRs, one can write zone files for the reverse
-   mapping tree that have the same ability to cope with rapid
-   renumbering or GSE-style routing that the A6 RR offers in the main
-   portion of the DNS tree.  Consequently, the need to use DNAME in the
-   reverse mapping tree appears to be closely tied to the need to use
-   fragmented A6 in the main tree: if one is necessary, so is the other,
-   and if one isn't necessary, the other isn't either.
-
-   Other uses have also been proposed for the DNAME RR, but since they
-   are outside the scope of the IPv6 address discussion, they will not
-   be addressed here.
-
-Recommendation
-
-   Distilling the above feature comparisons down to their key elements,
-   the important questions appear to be:
-
-   (a) Is IPv6 going to do rapid renumbering or GSE-like routing?
-
-   (b) Is the reverse mapping tree for IPv6 going to require delegation
-       in the least significant four bits of the address?
-
-   Question (a) appears to be the key to the debate.  This is really a
-   decision for the IPv6 community to make, not the DNS community.
-
-   Question (b) is also for the IPv6 community to make, but it seems
-   fairly obvious that the answer is "no".
-
-
-
-
-
-Austein                      Informational                      [Page 8]
-
-RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
-
-
-   Recommendations based on these questions:
-
-   (1) If the IPv6 working groups seriously intend to specify and deploy
-       rapid renumbering or GSE-like routing, we should transition to
-       using the A6 RR in the main tree and to using DNAME RRs as
-       necessary in the reverse tree.
-
-   (2) Otherwise, we should keep the simpler AAAA solution in the main
-       tree and should not use DNAME RRs in the reverse tree.
-
-   (3) In either case, the reverse tree should use the textual
-       representation described in [RFC1886] rather than the bit label
-       representation described in [RFC2874].
-
-   (4) If we do go to using A6 RRs in the main tree and to using DNAME
-       RRs in the reverse tree, we should write applicability statements
-       and implementation guidelines designed to discourage excessively
-       complex uses of these features; in general, any network that can
-       be described adequately using A6 0 RRs and without using DNAME
-       RRs should be described that way, and the enhanced features
-       should be used only when absolutely necessary, at least until we
-       have much more experience with them and have a better
-       understanding of their failure modes.
-
-Security Considerations
-
-   This note compares two mechanisms with similar security
-   characteristics, but there are a few security implications to the
-   choice between these two mechanisms:
-
-   (1) The two mechanisms have similar but not identical interactions
-       with DNSSEC.  Please see the section entitled "Interactions with
-       DNSSEC" (above) for a discussion of these issues.
-
-   (2) To the extent that operational complexity is the enemy of
-       security, the tradeoffs in operational complexity discussed
-       throughout this note have an impact on security.
-
-   (3) To the extent that protocol complexity is the enemy of security,
-       the additional protocol complexity of [RFC2874] as compared to
-       [RFC1886] has some impact on security.
-
-IANA Considerations
-
-   None, since all of these RR types have already been allocated.
-
-
-
-
-
-
-Austein                      Informational                      [Page 9]
-
-RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
-
-
-Acknowledgments
-
-   This note is based on a number of discussions both public and private
-   over a period of (at least) eight years, but particular thanks go to
-   Alain Durand, Bill Sommerfeld, Christian Huitema, Jun-ichiro itojun
-   Hagino, Mark Andrews, Matt Crawford, Olafur Gudmundsson, Randy Bush,
-   and Sue Thomson, none of whom are responsible for what the author did
-   with their ideas.
-
-References
-
-   [RFC1886]    Thomson, S. and C. Huitema, "DNS Extensions to support
-                IP version 6", RFC 1886, December 1995.
-
-   [RFC2874]    Crawford, M. and C. Huitema, "DNS Extensions to Support
-                IPv6 Address Aggregation and Renumbering", RFC 2874,
-                July 2000.
-
-   [Sommerfeld] Private message to the author from Bill Sommerfeld dated
-                21 March 2001, summarizing the result of experiments he
-                performed on a copy of the MIT.EDU zone.
-
-   [GSE]       "GSE" was an evolution of the so-called "8+8" proposal
-                discussed by the IPng working group in 1996 and 1997.
-                The GSE proposal itself was written up as an Internet-
-                Draft, which has long since expired.  Readers interested
-                in the details and history of GSE should review the IPng
-                working group's mailing list archives and minutes from
-                that period.
-
-Author's Address
-
-   Rob Austein
-
-   EMail: sra@hactrn.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein                      Informational                     [Page 10]
-
-RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein                      Informational                     [Page 11]
-
diff --git a/contrib/bind9/doc/rfc/rfc3425.txt b/contrib/bind9/doc/rfc/rfc3425.txt
deleted file mode 100644
index 707cafd..0000000
--- a/contrib/bind9/doc/rfc/rfc3425.txt
+++ /dev/null
@@ -1,283 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        D. Lawrence
-Request for Comments: 3425                                       Nominum
-Updates: 1035                                              November 2002
-Category: Standards Track
-
-
-                           Obsoleting IQUERY
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-Abstract
-
-   The IQUERY method of performing inverse DNS lookups, specified in RFC
-   1035, has not been generally implemented and has usually been
-   operationally disabled where it has been implemented.  Both reflect a
-   general view in the community that the concept was unwise and that
-   the widely-used alternate approach of using pointer (PTR) queries and
-   reverse-mapping records is preferable.  Consequently, this document
-   deprecates the IQUERY operation, declaring it entirely obsolete.
-   This document updates RFC 1035.
-
-1 - Introduction
-
-   As specified in RFC 1035 (section 6.4), the IQUERY operation for DNS
-   queries is used to look up the name(s) which are associated with the
-   given value.  The value being sought is provided in the query's
-   answer section and the response fills in the question section with
-   one or more 3-tuples of type, name and class.
-
-   As noted in [RFC1035], section 6.4.3, inverse query processing can
-   put quite an arduous burden on a server.  A server would need to
-   perform either an exhaustive search of its database or maintain a
-   separate database that is keyed by the values of the primary
-   database.  Both of these approaches could strain system resource use,
-   particularly for servers that are authoritative for millions of
-   names.
-
-
-
-
-
-Lawrence                    Standards Track                     [Page 1]
-
-RFC 3425                   Obsoleting IQUERY               November 2002
-
-
-   Response packets from these megaservers could be exceptionally large,
-   and easily run into megabyte sizes.  For example, using IQUERY to
-   find every domain that is delegated to one of the nameservers of a
-   large ISP could return tens of thousands of 3-tuples in the question
-   section.  This could easily be used to launch denial of service
-   attacks.
-
-   Operators of servers that do support IQUERY in some form (such as
-   very old BIND 4 servers) generally opt to disable it.  This is
-   largely due to bugs in insufficiently-exercised code, or concerns
-   about exposure of large blocks of names in their zones by probes such
-   as inverse MX queries.
-
-   IQUERY is also somewhat inherently crippled by being unable to tell a
-   requester where it needs to go to get the information that was
-   requested.  The answer is very specific to the single server that was
-   queried.  This is sometimes a handy diagnostic tool, but apparently
-   not enough so that server operators like to enable it, or request
-   implementation where it is lacking.
-
-   No known clients use IQUERY to provide any meaningful service.  The
-   only common reverse mapping support on the Internet, mapping address
-   records to names, is provided through the use of pointer (PTR)
-   records in the in-addr.arpa tree and has served the community well
-   for many years.
-
-   Based on all of these factors, this document recommends that the
-   IQUERY operation for DNS servers be officially obsoleted.
-
-2 - Requirements
-
-   The key word "SHOULD" in this document is to be interpreted as
-   described in BCP 14, RFC 2119, namely that there may exist valid
-   reasons to ignore a particular item, but the full implications must
-   be understood and carefully weighed before choosing a different
-   course.
-
-3 - Effect on RFC 1035
-
-   The effect of this document is to change the definition of opcode 1
-   from that originally defined in section 4.1.1 of RFC 1035, and to
-   entirely supersede section 6.4 (including subsections) of RFC 1035.
-
-   The definition of opcode 1 is hereby changed to:
-
-      "1               an inverse query (IQUERY) (obsolete)"
-
-
-
-
-
-Lawrence                    Standards Track                     [Page 2]
-
-RFC 3425                   Obsoleting IQUERY               November 2002
-
-
-   The text in section 6.4 of RFC 1035 is now considered obsolete.  The
-   following is an applicability statement regarding the IQUERY opcode:
-
-   Inverse queries using the IQUERY opcode were originally described as
-   the ability to look up the names that are associated with a
-   particular Resource Record (RR).  Their implementation was optional
-   and never achieved widespread use.  Therefore IQUERY is now obsolete,
-   and name servers SHOULD return a "Not Implemented" error when an
-   IQUERY request is received.
-
-4 - Security Considerations
-
-   Since this document obsoletes an operation that was once available,
-   it is conceivable that someone was using it as the basis of a
-   security policy.  However, since the most logical course for such a
-   policy to take in the face of a lack of positive response from a
-   server is to deny authentication/authorization, it is highly unlikely
-   that removing support for IQUERY will open any new security holes.
-
-   Note that if IQUERY is not obsoleted, securing the responses with DNS
-   Security (DNSSEC) is extremely difficult without out-on-the-fly
-   digital signing.
-
-5 - IANA Considerations
-
-   The IQUERY opcode of 1 should be permanently retired, not to be
-   assigned to any future opcode.
-
-6 - Acknowledgments
-
-   Olafur Gudmundsson instigated this action.  Matt Crawford, John
-   Klensin, Erik Nordmark and Keith Moore contributed some improved
-   wording in how to handle obsoleting functionality described by an
-   Internet Standard.
-
-7 - References
-
-   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
-              Specification", STD 13, RFC 1035, November 1987.
-
-   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
-              3", BCP 9, RFC 2026, October 1996.
-
-   [RFC2119]  Bradner, S., "Key Words for Use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-
-
-
-
-
-Lawrence                    Standards Track                     [Page 3]
-
-RFC 3425                   Obsoleting IQUERY               November 2002
-
-
-8 - Author's Address
-
-   David C Lawrence
-   Nominum, Inc.
-   2385 Bay Rd
-   Redwood City CA 94063
-   USA
-
-   Phone: +1.650.779.6042
-   EMail: tale@nominum.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lawrence                    Standards Track                     [Page 4]
-
-RFC 3425                   Obsoleting IQUERY               November 2002
-
-
-9 - Full Copyright Statement
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lawrence                    Standards Track                     [Page 5]
-
diff --git a/contrib/bind9/doc/rfc/rfc3445.txt b/contrib/bind9/doc/rfc/rfc3445.txt
deleted file mode 100644
index 67f9b2d..0000000
--- a/contrib/bind9/doc/rfc/rfc3445.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          D. Massey
-Request for Comments: 3445                                       USC/ISI
-Updates: 2535                                                    S. Rose
-Category: Standards Track                                           NIST
-                                                           December 2002
-
-
-           Limiting the Scope of the KEY Resource Record (RR)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-Abstract
-
-   This document limits the Domain Name System (DNS) KEY Resource Record
-   (RR) to only keys used by the Domain Name System Security Extensions
-   (DNSSEC).  The original KEY RR used sub-typing to store both DNSSEC
-   keys and arbitrary application keys.  Storing both DNSSEC and
-   application keys with the same record type is a mistake.  This
-   document removes application keys from the KEY record by redefining
-   the Protocol Octet field in the KEY RR Data.  As a result of removing
-   application keys, all but one of the flags in the KEY record become
-   unnecessary and are redefined.  Three existing application key sub-
-   types are changed to reserved, but the format of the KEY record is
-   not changed.  This document updates RFC 2535.
-
-1. Introduction
-
-   This document limits the scope of the KEY Resource Record (RR).  The
-   KEY RR was defined in [3] and used resource record sub-typing to hold
-   arbitrary public keys such as Email, IPSEC, DNSSEC, and TLS keys.
-   This document eliminates the existing Email, IPSEC, and TLS sub-types
-   and prohibits the introduction of new sub-types.  DNSSEC will be the
-   only allowable sub-type for the KEY RR (hence sub-typing is
-   essentially eliminated) and all but one of the KEY RR flags are also
-   eliminated.
-
-
-
-
-
-
-Massey & Rose               Standards Track                     [Page 1]
-
-RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
-
-
-   Section 2 presents the motivation for restricting the KEY record and
-   Section 3 defines the revised KEY RR.  Sections 4 and 5 summarize the
-   changes from RFC 2535 and discuss backwards compatibility.  It is
-   important to note that this document restricts the use of the KEY RR
-   and simplifies the flags, but does not change the definition or use
-   of DNSSEC keys.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [1].
-
-2. Motivation for Restricting the KEY RR
-
-   The KEY RR RDATA [3] consists of Flags, a Protocol Octet, an
-   Algorithm type, and a Public Key.  The Protocol Octet identifies the
-   KEY RR sub-type.  DNSSEC public keys are stored in the KEY RR using a
-   Protocol Octet value of 3.  Email, IPSEC, and TLS keys were also
-   stored in the KEY RR and used Protocol Octet values of 1,2, and 4
-   (respectively).  Protocol Octet values 5-254 were available for
-   assignment by IANA and values were requested (but not assigned) for
-   applications such as SSH.
-
-   Any use of sub-typing has inherent limitations.  A resolver can not
-   specify the desired sub-type in a DNS query and most DNS operations
-   apply only to resource records sets.  For example, a resolver can not
-   directly request the DNSSEC subtype KEY RRs.  Instead, the resolver
-   has to request all KEY RRs associated with a DNS name and then search
-   the set for the desired DNSSEC sub-type.  DNSSEC signatures also
-   apply to the set of all KEY RRs associated with the DNS name,
-   regardless of sub-type.
-
-   In the case of the KEY RR, the inherent sub-type limitations are
-   exacerbated since the sub-type is used to distinguish between DNSSEC
-   keys and application keys.  DNSSEC keys and application keys differ
-   in virtually every respect and Section 2.1 discusses these
-   differences in more detail.  Combining these very different types of
-   keys into a single sub-typed resource record adds unnecessary
-   complexity and increases the potential for implementation and
-   deployment errors.  Limited experimental deployment has shown that
-   application keys stored in KEY RRs are problematic.
-
-   This document addresses these issues by removing all application keys
-   from the KEY RR.  Note that the scope of this document is strictly
-   limited to the KEY RR and this document does not endorse or restrict
-   the storage of application keys in other, yet undefined, resource
-   records.
-
-
-
-
-
-Massey & Rose               Standards Track                     [Page 2]
-
-RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
-
-
-2.1 Differences Between DNSSEC and Application Keys
-
-   DNSSEC keys are an essential part of the DNSSEC protocol and are used
-   by both name servers and resolvers in order to perform DNS tasks.  A
-   DNS zone key, used to sign and authenticate RR sets, is the most
-   common example of a DNSSEC key.  SIG(0) [4] and TKEY [3]  also use
-   DNSSEC keys.
-
-   Application keys such as Email keys, IPSEC keys, and TLS keys are
-   simply another type of data.  These keys have no special meaning to a
-   name server or resolver.
-
-   The following table summarizes some of the differences between DNSSEC
-   keys and application keys:
-
-      1.  They serve different purposes.
-
-      2.  They are managed by different administrators.
-
-      3.  They are authenticated according to different rules.
-
-      4.  Nameservers use different rules when including them in
-          responses.
-
-      5.  Resolvers process them in different ways.
-
-      6.  Faults/key compromises have different consequences.
-
-   1.  The purpose of a DNSSEC key is to sign resource records
-   associated with a DNS zone (or generate DNS transaction signatures in
-   the case of SIG(0)/TKEY).  But the purpose of an application key is
-   specific to the application.  Application keys, such as PGP/email,
-   IPSEC, TLS, and SSH keys, are not a mandatory part of any zone and
-   the purpose and proper use of application keys is outside the scope
-   of DNS.
-
-   2.  DNSSEC keys are managed by DNS administrators, but application
-   keys are managed by application administrators.  The DNS zone
-   administrator determines the key lifetime, handles any suspected key
-   compromises, and manages any DNSSEC key changes.  Likewise, the
-   application administrator is responsible for the same functions for
-   the application keys related to the application.  For example, a user
-   typically manages her own PGP key and a server manages its own TLS
-   key.  Application key management tasks are outside the scope of DNS
-   administration.
-
-
-
-
-
-
-Massey & Rose               Standards Track                     [Page 3]
-
-RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
-
-
-   3.  DNSSEC zone keys are used to authenticate application keys, but
-   by definition, application keys are not allowed to authenticate DNS
-   zone keys.  A DNS zone key is either configured as a trusted key or
-   authenticated by constructing a chain of trust in the DNS hierarchy.
-   To participate in the chain of trust, a DNS zone needs to exchange
-   zone key information with its parent zone [3].  Application keys are
-   not configured as trusted keys in the DNS and are never part of any
-   DNS chain of trust.  Application key data is not needed by the parent
-   and does not need to be exchanged with the parent zone for secure DNS
-   resolution to work.  A resolver considers an application key RRset as
-   authenticated DNS information if it has a valid signature from the
-   local DNS zone keys, but applications could impose additional
-   security requirements before the application key is accepted as
-   authentic for use with the application.
-
-   4.  It may be useful for nameservers to include DNS zone keys in the
-   additional section of a response, but application keys are typically
-   not useful unless they have been specifically requested.  For
-   example, it could be useful to include the example.com zone key along
-   with a response that contains the www.example.com A record and SIG
-   record.  A secure resolver will need the example.com zone key in
-   order to check the SIG and authenticate the www.example.com A record.
-   It is typically not useful to include the IPSEC, email, and TLS keys
-   along with the A record.  Note that by placing application keys in
-   the KEY record, a resolver would need the IPSEC, email, TLS, and
-   other key associated with example.com if the resolver intends to
-   authenticate the example.com zone key (since signatures only apply to
-   the entire KEY RR set).  Depending on the number of protocols
-   involved, the KEY RR set could grow unwieldy for resolvers, and DNS
-   administrators to manage.
-
-   5.  DNS zone keys require special handling by resolvers, but
-   application keys are treated the same as any other type of DNS data.
-   The DNSSEC keys are of no value to end applications, unless the
-   applications plan to do their own DNS authentication.  By definition,
-   secure resolvers are not allowed to use application keys as part of
-   the authentication process.  Application keys have no unique meaning
-   to resolvers and are only useful to the application requesting the
-   key.  Note that if sub-types are used to identify the application
-   key, then either the interface to the resolver needs to specify the
-   sub-type or the application needs to be able to accept all KEY RRs
-   and pick out the desired sub-type.
-
-   6.  A fault or compromise of a DNS zone key can lead to invalid or
-   forged DNS data, but a fault or compromise of an application key
-   should have no impact on other DNS data.  Incorrectly adding or
-   changing a DNS zone key can invalidate all of the DNS data in the
-   zone and in all of its subzones.  By using a compromised key, an
-
-
-
-Massey & Rose               Standards Track                     [Page 4]
-
-RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
-
-
-   attacker can forge data from the effected zone and for any of its
-   sub-zones.  A fault or compromise of an application key has
-   implications for that application, but it should not have an impact
-   on the DNS.  Note that application key faults and key compromises can
-   have an impact on the entire DNS if the application key and DNS zone
-   keys are both stored in the KEY RR.
-
-   In summary, DNSSEC keys and application keys differ in most every
-   respect.  DNSSEC keys are an essential part of the DNS infrastructure
-   and require special handling by DNS administrators and DNS resolvers.
-   Application keys are simply another type of data and have no special
-   meaning to DNS administrators or resolvers.  These two different
-   types of data do not belong in the same resource record.
-
-3. Definition of the KEY RR
-
-   The KEY RR uses type 25 and is used as resource record for storing
-   DNSSEC keys.  The RDATA for a KEY RR consists of flags, a protocol
-   octet, the algorithm number octet, and the public key itself.  The
-   format is as follows:
-
-   ---------------------------------------------------------------------
-
-
-                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |              flags            |   protocol    |   algorithm   |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                                                               /
-   /                        public key                             /
-   /                                                               /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-                             KEY RR Format
-
-   ---------------------------------------------------------------------
-
-   In the flags field, all bits except bit 7 are reserved and MUST be
-   zero.  If Bit 7 (Zone bit) is set to 1, then the KEY is a DNS Zone
-   key.  If Bit 7 is set to 0, the KEY is not a zone key.  SIG(0)/TKEY
-   are examples of DNSSEC keys that are not zone keys.
-
-   The protocol field MUST be set to 3.
-
-   The algorithm and public key fields are not changed.
-
-
-
-
-
-Massey & Rose               Standards Track                     [Page 5]
-
-RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
-
-
-4. Changes from RFC 2535 KEY RR
-
-   The KEY RDATA format is not changed.
-
-   All flags except for the zone key flag are eliminated:
-
-      The A/C bits (bits 0 and 1) are eliminated.  They MUST be set to 0
-      and MUST be ignored by the receiver.
-
-      The extended flags bit (bit 3) is eliminated.  It MUST be set to 0
-      and MUST be ignored by the receiver.
-
-      The host/user bit (bit 6) is eliminated.  It MUST be set to 0 and
-      MUST be ignored by the receiver.
-
-      The zone bit (bit 7) remains unchanged.
-
-      The signatory field (bits 12-15) are eliminated by [5].  They MUST
-      be set to 0 and MUST be ignored by the receiver.
-
-      Bits 2,4,5,8,9,10,11 remain unchanged.  They are reserved, MUST be
-      set to zero and MUST be ignored by the receiver.
-
-   Assignment of any future KEY RR Flag values requires a standards
-   action.
-
-   All Protocol Octet values except DNSSEC (3) are eliminated:
-
-      Value 1 (Email) is renamed to RESERVED.
-
-      Value 2 (IPSEC) is renamed to RESERVED.
-
-      Value 3 (DNSSEC) is unchanged.
-
-      Value 4 (TLS) is renamed to RESERVED.
-
-      Value 5-254 remains unchanged (reserved).
-
-      Value 255 (ANY) is renamed to RESERVED.
-
-   The authoritative data for a zone MUST NOT include any KEY records
-   with a protocol octet other than 3.  The registry maintained by IANA
-   for protocol values is closed for new assignments.
-
-   Name servers and resolvers SHOULD accept KEY RR sets that contain KEY
-   RRs with a value other than 3.  If out of date DNS zones contain
-   deprecated KEY RRs with a protocol octet value other than 3, then
-   simply dropping the deprecated KEY RRs from the KEY RR set would
-
-
-
-Massey & Rose               Standards Track                     [Page 6]
-
-RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
-
-
-   invalidate any associated SIG record(s) and could create caching
-   consistency problems.  Note that KEY RRs with a protocol octet value
-   other than 3 MUST NOT be used to authenticate DNS data.
-
-   The algorithm and public key fields are not changed.
-
-5. Backward Compatibility
-
-   DNSSEC zone KEY RRs are not changed and remain backwards compatible.
-   A properly formatted RFC 2535 zone KEY would have all flag bits,
-   other than the Zone Bit (Bit 7), set to 0 and would have the Protocol
-   Octet set to 3.  This remains true under the restricted KEY.
-
-   DNSSEC non-zone KEY RRs (SIG(0)/TKEY keys) are backwards compatible,
-   but the distinction between host and user keys (flag bit 6) is lost.
-
-   No backwards compatibility is provided for application keys.  Any
-   Email, IPSEC, or TLS keys are now deprecated.  Storing application
-   keys in the KEY RR created problems such as keys at the apex and
-   large RR sets and some change in the definition and/or usage of the
-   KEY RR would have been required even if the approach described here
-   were not adopted.
-
-   Overall, existing nameservers and resolvers will continue to
-   correctly process KEY RRs with a sub-type of DNSSEC keys.
-
-6. Storing Application Keys in the DNS
-
-   The scope of this document is strictly limited to the KEY record.
-   This document prohibits storing application keys in the KEY record,
-   but it does not endorse or restrict the storing application keys in
-   other record types.  Other documents can describe how DNS handles
-   application keys.
-
-7. IANA Considerations
-
-   RFC 2535 created an IANA registry for DNS KEY RR Protocol Octet
-   values.  Values 1, 2, 3, 4, and 255 were assigned by RFC 2535 and
-   values 5-254 were made available for assignment by IANA.  This
-   document makes two sets of changes to this registry.
-
-   First, this document re-assigns DNS KEY RR Protocol Octet values 1,
-   2, 4, and 255 to "reserved".  DNS Key RR Protocol Octet Value 3
-   remains unchanged as "DNSSEC".
-
-
-
-
-
-
-
-Massey & Rose               Standards Track                     [Page 7]
-
-RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
-
-
-   Second, new values are no longer available for assignment by IANA and
-   this document closes the IANA registry for DNS KEY RR Protocol Octet
-   Values.  Assignment of any future KEY RR Protocol Octet values
-   requires a standards action.
-
-8. Security Considerations
-
-   This document eliminates potential security problems that could arise
-   due to the coupling of DNS zone keys and application keys.  Prior to
-   the change described in this document, a correctly authenticated KEY
-   set could include both application keys and DNSSEC keys.  This
-   document restricts the KEY RR to DNS security usage only.  This is an
-   attempt to simplify the security model and make it less user-error
-   prone.  If one of the application keys is compromised, it could be
-   used as a false zone key to create false DNS signatures (SIG
-   records).  Resolvers that do not carefully check the KEY sub-type
-   could believe these false signatures and incorrectly authenticate DNS
-   data.  With this change, application keys cannot appear in an
-   authenticated KEY set and this vulnerability is eliminated.
-
-   The format and correct usage of DNSSEC keys is not changed by this
-   document and no new security considerations are introduced.
-
-9. Normative References
-
-   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [2]  Eastlake, D., "Domain Name System Security Extensions", RFC
-        2535, March 1999.
-
-   [3]  Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC
-        2930, September 2000.
-
-   [4]  Eastlake, D., "DNS Request and Transaction Signatures
-        (SIG(0)s)", RFC 2931, September 2000.
-
-   [5]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
-        Update", RFC 3007, November 2000.
-
-
-
-
-
-
-
-
-
-
-
-
-Massey & Rose               Standards Track                     [Page 8]
-
-RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
-
-
-10. Authors' Addresses
-
-   Dan Massey
-   USC Information Sciences Institute
-   3811 N. Fairfax Drive
-   Arlington, VA  22203
-   USA
-
-   EMail: masseyd@isi.edu
-
-
-   Scott Rose
-   National Institute for Standards and Technology
-   100 Bureau Drive
-   Gaithersburg, MD  20899-3460
-   USA
-
-   EMail: scott.rose@nist.gov
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Massey & Rose               Standards Track                     [Page 9]
-
-RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
-
-
-11.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Massey & Rose               Standards Track                    [Page 10]
-
diff --git a/contrib/bind9/doc/rfc/rfc3467.txt b/contrib/bind9/doc/rfc/rfc3467.txt
deleted file mode 100644
index 37ac7ec..0000000
--- a/contrib/bind9/doc/rfc/rfc3467.txt
+++ /dev/null
@@ -1,1739 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         J. Klensin
-Request for Comments: 3467                                 February 2003
-Category: Informational
-
-
-                  Role of the Domain Name System (DNS)
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-Abstract
-
-   This document reviews the original function and purpose of the domain
-   name system (DNS).  It contrasts that history with some of the
-   purposes for which the DNS has recently been applied and some of the
-   newer demands being placed upon it or suggested for it.  A framework
-   for an alternative to placing these additional stresses on the DNS is
-   then outlined.  This document and that framework are not a proposed
-   solution, only a strong suggestion that the time has come to begin
-   thinking more broadly about the problems we are encountering and
-   possible approaches to solving them.
-
-Table of Contents
-
-   1.  Introduction and History .....................................  2
-      1.1 Context for DNS Development ...............................  3
-      1.2 Review of the DNS and Its Role as Designed ................  4
-      1.3 The Web and User-visible Domain Names .....................  6
-      1.4 Internet Applications Protocols and Their Evolution .......  7
-   2.  Signs of DNS Overloading .....................................  8
-   3.  Searching, Directories, and the DNS .......................... 12
-      3.1 Overview  ................................................. 12
-      3.2 Some Details and Comments ................................. 14
-   4.  Internationalization ......................................... 15
-      4.1 ASCII Isn't Just Because of English ....................... 16
-      4.2 The "ASCII Encoding" Approaches ........................... 17
-      4.3 "Stringprep" and Its Complexities ......................... 17
-      4.4 The Unicode Stability Problem ............................. 19
-      4.5 Audiences, End Users, and the User Interface Problem ...... 20
-      4.6 Business Cards and Other Natural Uses of Natural Languages. 22
-      4.7 ASCII Encodings and the Roman Keyboard Assumption ......... 22
-
-
-
-Klensin                      Informational                      [Page 1]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-      4.8 Intra-DNS Approaches for "Multilingual Names" ............. 23
-   5.  Search-based Systems: The Key Controversies .................. 23
-   6.  Security Considerations ...................................... 24
-   7.  References ................................................... 25
-      7.1 Normative References ...................................... 25
-      7.2 Explanatory and Informative References .................... 25
-   8.  Acknowledgements ............................................. 30
-   9.  Author's Address ............................................. 30
-   10. Full Copyright Statement ..................................... 31
-
-1. Introduction and History
-
-   The DNS was designed as a replacement for the older "host table"
-   system.  Both were intended to provide names for network resources at
-   a more abstract level than network (IP) addresses (see, e.g.,
-   [RFC625], [RFC811], [RFC819], [RFC830], [RFC882]).  In recent years,
-   the DNS has become a database of convenience for the Internet, with
-   many proposals to add new features.  Only some of these proposals
-   have been successful.  Often the main (or only) motivation for using
-   the DNS is because it exists and is widely deployed, not because its
-   existing structure, facilities, and content are appropriate for the
-   particular application of data involved.  This document reviews the
-   history of the DNS, including examination of some of those newer
-   applications.  It then argues that the overloading process is often
-   inappropriate.  Instead, it suggests that the DNS should be
-   supplemented by systems better matched to the intended applications
-   and outlines a framework and rationale for one such system.
-
-   Several of the comments that follow are somewhat revisionist.  Good
-   design and engineering often requires a level of intuition by the
-   designers about things that will be necessary in the future; the
-   reasons for some of these design decisions are not made explicit at
-   the time because no one is able to articulate them.  The discussion
-   below reconstructs some of the decisions about the Internet's primary
-   namespace (the "Class=IN" DNS) in the light of subsequent development
-   and experience.  In addition, the historical reasons for particular
-   decisions about the Internet were often severely underdocumented
-   contemporaneously and, not surprisingly, different participants have
-   different recollections about what happened and what was considered
-   important.  Consequently, the quasi-historical story below is just
-   one story.  There may be (indeed, almost certainly are) other stories
-   about how the DNS evolved to its present state, but those variants do
-   not invalidate the inferences and conclusions.
-
-   This document presumes a general understanding of the terminology of
-   RFC 1034 [RFC1034] or of any good DNS tutorial (see, e.g., [Albitz]).
-
-
-
-
-
-Klensin                      Informational                      [Page 2]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-1.1  Context for DNS Development
-
-   During the entire post-startup-period life of the ARPANET and nearly
-   the first decade or so of operation of the Internet, the list of host
-   names and their mapping to and from addresses was maintained in a
-   frequently-updated "host table" [RFC625], [RFC811], [RFC952].  The
-   names themselves were restricted to a subset of ASCII [ASCII] chosen
-   to avoid ambiguities in printed form, to permit interoperation with
-   systems using other character codings (notably EBCDIC), and to avoid
-   the "national use" code positions of ISO 646 [IS646].  These
-   restrictions later became collectively known as the "LDH" rules for
-   "letter-digit-hyphen", the permitted characters.  The table was just
-   a list with a common format that was eventually agreed upon; sites
-   were expected to frequently obtain copies of, and install, new
-   versions.  The host tables themselves were introduced to:
-
-   o  Eliminate the requirement for people to remember host numbers
-      (addresses).  Despite apparent experience to the contrary in the
-      conventional telephone system, numeric numbering systems,
-      including the numeric host number strategy, did not (and do not)
-      work well for more than a (large) handful of hosts.
-
-   o  Provide stability when addresses changed.  Since addresses -- to
-      some degree in the ARPANET and more importantly in the
-      contemporary Internet -- are a function of network topology and
-      routing, they often had to be changed when connectivity or
-      topology changed.  The names could be kept stable even as
-      addresses changed.
-
-   o  Provide the capability to have multiple addresses associated with
-      a given host to reflect different types of connectivity and
-      topology.  Use of names, rather than explicit addresses, avoided
-      the requirement that would otherwise exist for users and other
-      hosts to track these multiple host numbers and addresses and the
-      topological considerations for selecting one over others.
-
-   After several years of using the host table approach, the community
-   concluded that model did not scale adequately and that it would not
-   adequately support new service variations.  A number of discussions
-   and meetings were held which drew several ideas and incomplete
-   proposals together.  The DNS was the result of that effort.  It
-   continued to evolve during the design and initial implementation
-   period, with a number of documents recording the changes (see
-   [RFC819], [RFC830], and [RFC1034]).
-
-
-
-
-
-
-
-Klensin                      Informational                      [Page 3]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   The goals for the DNS included:
-
-   o  Preservation of the capabilities of the host table arrangements
-      (especially unique, unambiguous, host names),
-
-   o  Provision for addition of additional services (e.g., the special
-      record types for electronic mail routing which quickly followed
-      introduction of the DNS), and
-
-   o  Creation of a robust, hierarchical, distributed, name lookup
-      system to accomplish the other goals.
-
-   The DNS design also permitted distribution of name administration,
-   rather than requiring that each host be entered into a single,
-   central, table by a central administration.
-
-1.2 Review of the DNS and Its Role as Designed
-
-   The DNS was designed to identify network resources.  Although there
-   was speculation about including, e.g., personal names and email
-   addresses, it was not designed primarily to identify people, brands,
-   etc.  At the same time, the system was designed with the flexibility
-   to accommodate new data types and structures, both through the
-   addition of new record types to the initial "INternet" class, and,
-   potentially, through the introduction of new classes.  Since the
-   appropriate identifiers and content of those future extensions could
-   not be anticipated, the design provided that these fields could
-   contain any (binary) information, not just the restricted text forms
-   of the host table.
-
-   However, the DNS, as it is actually used, is intimately tied to the
-   applications and application protocols that utilize it, often at a
-   fairly low level.
-
-   In particular, despite the ability of the protocols and data
-   structures themselves to accommodate any binary representation, DNS
-   names as used were historically not even unrestricted ASCII, but a
-   very restricted subset of it, a subset that derives from the original
-   host table naming rules.  Selection of that subset was driven in part
-   by human factors considerations, including a desire to eliminate
-   possible ambiguities in an international context.  Hence character
-   codes that had international variations in interpretation were
-   excluded, the underscore character and case distinctions were
-   eliminated as being confusing (in the underscore's case, with the
-   hyphen character) when written or read by people, and so on.  These
-   considerations appear to be very similar to those that resulted in
-   similarly restricted character sets being used as protocol elements
-   in many ITU and ISO protocols (cf. [X29]).
-
-
-
-Klensin                      Informational                      [Page 4]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   Another assumption was that there would be a high ratio of physical
-   hosts to second level domains and, more generally, that the system
-   would be deeply hierarchical, with most systems (and names) at the
-   third level or below and a very large percentage of the total names
-   representing physical hosts.  There are domains that follow this
-   model: many university and corporate domains use fairly deep
-   hierarchies, as do a few country-oriented top level domains
-   ("ccTLDs").  Historically, the "US." domain has been an excellent
-   example of the deeply hierarchical approach.  However, by 1998,
-   comparison of several efforts to survey the DNS showed a count of SOA
-   records that approached (and may have passed) the number of distinct
-   hosts.  Looked at differently, we appear to be moving toward a
-   situation in which the number of delegated domains on the Internet is
-   approaching or exceeding the number of hosts, or at least the number
-   of hosts able to provide services to others on the network.  This
-   presumably results from synonyms or aliases that map a great many
-   names onto a smaller number of hosts.  While experience up to this
-   time has shown that the DNS is robust enough -- given contemporary
-   machines as servers and current bandwidth norms -- to be able to
-   continue to operate reasonably well when those historical assumptions
-   are not met (e.g., with a flat, structure under ".COM" containing
-   well over ten million delegated subdomains [COMSIZE]), it is still
-   useful to remember that the system could have been designed to work
-   optimally with a flat structure (and very large zones) rather than a
-   deeply hierarchical one, and was not.
-
-   Similarly, despite some early speculation about entering people's
-   names and email addresses into the DNS directly (e.g., see
-   [RFC1034]), electronic mail addresses in the Internet have preserved
-   the original, pre-DNS, "user (or mailbox) at location" conceptual
-   format rather than a flatter or strictly dot-separated one.
-   Location, in that instance, is a reference to a host. The sole
-   exception, at least in the "IN" class, has been one field of the SOA
-   record.
-
-   Both the DNS architecture itself and the two-level (host name and
-   mailbox name) provisions for email and similar functions (e.g., see
-   the finger protocol [FINGER]), also anticipated a relatively high
-   ratio of users to actual hosts.  Despite the observation in RFC 1034
-   that the DNS was expected to grow to be proportional to the number of
-   users (section 2.3), it has never been clear that the DNS was
-   seriously designed for, or could, scale to the order of magnitude of
-   number of users (or, more recently, products or document objects),
-   rather than that of physical hosts.
-
-   Just as was the case for the host table before it, the DNS provided
-   critical uniqueness for names, and universal accessibility to them,
-   as part of overall "single internet" and "end to end" models (cf.
-
-
-
-Klensin                      Informational                      [Page 5]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   [RFC2826]).  However, there are many signs that, as new uses evolved
-   and original assumptions were abused (if not violated outright), the
-   system was being stretched to, or beyond, its practical limits.
-
-   The original design effort that led to the DNS included examination
-   of the directory technologies available at the time.  The design
-   group concluded that the DNS design, with its simplifying assumptions
-   and restricted capabilities, would be feasible to deploy and make
-   adequately robust, which the more comprehensive directory approaches
-   were not.  At the same time, some of the participants feared that the
-   limitations might cause future problems; this document essentially
-   takes the position that they were probably correct.  On the other
-   hand, directory technology and implementations have evolved
-   significantly in the ensuing years: it may be time to revisit the
-   assumptions, either in the context of the two- (or more) level
-   mechanism contemplated by the rest of this document or, even more
-   radically, as a path toward a DNS replacement.
-
-1.3 The Web and User-visible Domain Names
-
-   From the standpoint of the integrity of the domain name system -- and
-   scaling of the Internet, including optimal accessibility to content
-   -- the web design decision to use "A record" domain names directly in
-   URLs, rather than some system of indirection, has proven to be a
-   serious mistake in several respects.  Convenience of typing, and the
-   desire to make domain names out of easily-remembered product names,
-   has led to a flattening of the DNS, with many people now perceiving
-   that second-level names under COM (or in some countries, second- or
-   third-level names under the relevant ccTLD) are all that is
-   meaningful.  This perception has been reinforced by some domain name
-   registrars [REGISTRAR] who have been anxious to "sell" additional
-   names.  And, of course, the perception that one needed a second-level
-   (or even top-level) domain per product, rather than having names
-   associated with a (usually organizational) collection of network
-   resources, has led to a rapid acceleration in the number of names
-   being registered.  That acceleration has, in turn, clearly benefited
-   registrars charging on a per-name basis, "cybersquatters", and others
-   in the business of "selling" names, but it has not obviously
-   benefited the Internet as a whole.
-
-   This emphasis on second-level domain names has also created a problem
-   for the trademark community.  Since the Internet is international,
-   and names are being populated in a flat and unqualified space,
-   similarly-named entities are in conflict even if there would
-   ordinarily be no chance of confusing them in the marketplace.  The
-   problem appears to be unsolvable except by a choice between draconian
-   measures.  These might include significant changes to the legislation
-   and conventions that govern disputes over "names" and "marks".  Or
-
-
-
-Klensin                      Informational                      [Page 6]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   they might result in a situation in which the "rights" to a name are
-   typically not settled using the subtle and traditional product (or
-   industry) type and geopolitical scope rules of the trademark system.
-   Instead they have depended largely on political or economic power,
-   e.g., the organization with the greatest resources to invest in
-   defending (or attacking) names will ultimately win out.  The latter
-   raises not only important issues of equity, but also the risk of
-   backlash as the numerous small players are forced to relinquish names
-   they find attractive and to adopt less-desirable naming conventions.
-
-   Independent of these sociopolitical problems, content distribution
-   issues have made it clear that it should be possible for an
-   organization to have copies of data it wishes to make available
-   distributed around the network, with a user who asks for the
-   information by name getting the topologically-closest copy.  This is
-   not possible with simple, as-designed, use of the DNS: DNS names
-   identify target resources or, in the case of email "MX" records, a
-   preferentially-ordered list of resources "closest" to a target (not
-   to the source/user).  Several technologies (and, in some cases,
-   corresponding business models) have arisen to work around these
-   problems, including intercepting and altering DNS requests so as to
-   point to other locations.
-
-   Additional implications are still being discovered and evaluated.
-
-   Approaches that involve interception of DNS queries and rewriting of
-   DNS names (or otherwise altering the resolution process based on the
-   topological location of the user) seem, however, to risk disrupting
-   end-to-end applications in the general case and raise many of the
-   issues discussed by the IAB in [IAB-OPES].  These problems occur even
-   if the rewriting machinery is accompanied by additional workarounds
-   for particular applications.  For example, security associations and
-   applications that need to identify "the same host" often run into
-   problems if DNS names or other references are changed in the network
-   without participation of the applications that are trying to invoke
-   the associated services.
-
-1.4 Internet Applications Protocols and Their Evolution
-
-   At the applications level, few of the protocols in active,
-   widespread, use on the Internet reflect either contemporary knowledge
-   in computer science or human factors or experience accumulated
-   through deployment and use.  Instead, protocols tend to be deployed
-   at a just-past-prototype level, typically including the types of
-   expedient compromises typical with prototypes.  If they prove useful,
-   the nature of the network permits very rapid dissemination (i.e.,
-   they fill a vacuum, even if a vacuum that no one previously knew
-   existed).  But, once the vacuum is filled, the installed base
-
-
-
-Klensin                      Informational                      [Page 7]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   provides its own inertia: unless the design is so seriously faulty as
-   to prevent effective use (or there is a widely-perceived sense of
-   impending disaster unless the protocol is replaced), future
-   developments must maintain backward compatibility and workarounds for
-   problematic characteristics rather than benefiting from redesign in
-   the light of experience.  Applications that are "almost good enough"
-   prevent development and deployment of high-quality replacements.
-
-   The DNS is both an illustration of, and an exception to, parts of
-   this pessimistic interpretation. It was a second-generation
-   development, with the host table system being seen as at the end of
-   its useful life.  There was a serious attempt made to reflect the
-   computing state of the art at the time.  However, deployment was much
-   slower than expected (and very painful for many sites) and some fixed
-   (although relaxed several times) deadlines from a central network
-   administration were necessary for deployment to occur at all.
-   Replacing it now, in order to add functionality, while it continues
-   to perform its core functions at least reasonably well, would
-   presumably be extremely difficult.
-
-   There are many, perhaps obvious, examples of this.  Despite many
-   known deficiencies and weaknesses of definition, the "finger" and
-   "whois" [WHOIS] protocols have not been replaced (despite many
-   efforts to update or replace the latter [WHOIS-UPDATE]).  The Telnet
-   protocol and its many options drove out the SUPDUP [RFC734] one,
-   which was arguably much better designed for a diverse collection of
-   network hosts.  A number of efforts to replace the email or file
-   transfer protocols with models which their advocates considered much
-   better have failed.  And, more recently and below the applications
-   level, there is some reason to believe that this resistance to change
-   has been one of the factors impeding IPv6 deployment.
-
-2. Signs of DNS Overloading
-
-   Parts of the historical discussion above identify areas in which the
-   DNS has become overloaded (semantically if not in the mechanical
-   ability to resolve names).  Despite this overloading, it appears that
-   DNS performance and reliability are still within an acceptable range:
-   there is little evidence of serious performance degradation.  Recent
-   proposals and mechanisms to better respond to overloading and scaling
-   issues have all focused on patching or working around limitations
-   that develop when the DNS is utilized for out-of-design functions,
-   rather than on dramatic rethinking of either DNS design or those
-   uses.  The number of these issues that have arisen at much the same
-   time may argue for just that type of rethinking, and not just for
-   adding complexity and attempting to incrementally alter the design
-   (see, for example, the discussion of simplicity in section 2 of
-   [RFC3439]).
-
-
-
-Klensin                      Informational                      [Page 8]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   For example:
-
-   o  While technical approaches such as larger and higher-powered
-      servers and more bandwidth, and legal/political mechanisms such as
-      dispute resolution policies, have arguably kept the problems from
-      becoming critical, the DNS has not proven adequately responsive to
-      business and individual needs to describe or identify things (such
-      as product names and names of individuals) other than strict
-      network resources.
-
-   o  While stacks have been modified to better handle multiple
-      addresses on a physical interface and some protocols have been
-      extended to include DNS names for determining context, the DNS
-      does not deal especially well with many names associated with a
-      given host (e.g., web hosting facilities with multiple domains on
-      a server).
-
-   o  Efforts to add names deriving from languages or character sets
-      based on other than simple ASCII and English-like names (see
-      below), or even to utilize complex company or product names
-      without the use of hierarchy, have created apparent requirements
-      for names (labels) that are over 63 octets long.  This requirement
-      will undoubtedly increase over time; while there are workarounds
-      to accommodate longer names, they impose their own restrictions
-      and cause their own problems.
-
-   o  Increasing commercialization of the Internet, and visibility of
-      domain names that are assumed to match names of companies or
-      products, has turned the DNS and DNS names into a trademark
-      battleground.  The traditional trademark system in (at least) most
-      countries makes careful distinctions about fields of
-      applicability.  When the space is flattened, without
-      differentiation by either geography or industry sector, not only
-      are there likely conflicts between "Joe's Pizza" (of Boston) and
-      "Joe's Pizza" (of San Francisco) but between both and "Joe's Auto
-      Repair" (of Los Angeles).  All three would like to control
-      "Joes.com" (and would prefer, if it were permitted by DNS naming
-      rules, to also spell it as "Joe's.com" and have both resolve the
-      same way) and may claim trademark rights to do so, even though
-      conflict or confusion would not occur with traditional trademark
-      principles.
-
-   o  Many organizations wish to have different web sites under the same
-      URL and domain name.  Sometimes this is to create local variations
-      -- the Widget Company might want to present different material to
-      a UK user relative to a US one -- and sometimes it is to provide
-      higher performance by supplying information from the server
-      topologically closest to the user.  If the name resolution
-
-
-
-Klensin                      Informational                      [Page 9]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-      mechanism is expected to provide this functionality, there are
-      three possible models (which might be combined):
-
-      -  supply information about multiple sites (or locations or
-         references).  Those sites would, in turn, provide information
-         associated with the name and sufficient site-specific
-         attributes to permit the application to make a sensible choice
-         of destination, or
-
-      -  accept client-site attributes and utilize them in the search
-         process, or
-
-      -  return different answers based on the location or identity of
-         the requestor.
-
-   While there are some tricks that can provide partial simulations of
-   these types of function, DNS responses cannot be reliably conditioned
-   in this way.
-
-   These, and similar, issues of performance or content choices can, of
-   course, be thought of as not involving the DNS at all.  For example,
-   the commonly-cited alternate approach of coupling these issues to
-   HTTP content negotiation (cf. [RFC2295]), requires that an HTTP
-   connection first be opened to some "common" or "primary" host so that
-   preferences can be negotiated and then the client redirected or sent
-   alternate data.  At least from the standpoint of improving
-   performance by accessing a "closer" location, both initially and
-   thereafter, this approach sacrifices the desired result before the
-   client initiates any action.  It could even be argued that some of
-   the characteristics of common content negotiation approaches are
-   workarounds for the non-optimal use of the DNS in web URLs.
-
-   o  Many existing and proposed systems for "finding things on the
-      Internet" require a true search capability in which near matches
-      can be reported to the user (or to some user agent with an
-      appropriate rule-set) and to which queries may be ambiguous or
-      fuzzy.  The DNS, by contrast, can accommodate only one set of
-      (quite rigid) matching rules.  Proposals to permit different rules
-      in different localities (e.g., matching rules that are TLD- or
-      zone-specific) help to identify the problem.  But they cannot be
-      applied directly to the DNS without either abandoning the desired
-      level of flexibility or isolating different parts of the Internet
-      from each other (or both).  Fuzzy or ambiguous searches are
-      desirable for resolution of names that might have spelling
-      variations and for names that can be resolved into different sets
-      of glyphs depending on context.  Especially when
-      internationalization is considered, variant name problems go
-      beyond simple differences in representation of a character or
-
-
-
-Klensin                      Informational                     [Page 10]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-      ordering of a string.  Instead, avoiding user astonishment and
-      confusion requires consideration of relationships such as
-      languages that can be written with different alphabets, Kanji-
-      Hiragana relationships, Simplified and Traditional Chinese, etc.
-      See [Seng] for a discussion and suggestions for addressing a
-      subset of these issues in the context of characters based on
-      Chinese ones.  But that document essentially illustrates the
-      difficulty of providing the type of flexible matching that would
-      be anticipated by users; instead, it tries to protect against the
-      worst types of confusion (and opportunities for fraud).
-
-   o  The historical DNS, and applications that make assumptions about
-      how it works, impose significant risk (or forces technical kludges
-      and consequent odd restrictions), when one considers adding
-      mechanisms for use with various multi-character-set and
-      multilingual "internationalization" systems.  See the IAB's
-      discussion of some of these issues [RFC2825] for more information.
-
-   o  In order to provide proper functionality to the Internet, the DNS
-      must have a single unique root (the IAB provides more discussion
-      of this issue [RFC2826]).  There are many desires for local
-      treatment of names or character sets that cannot be accommodated
-      without either multiple roots (e.g., a separate root for
-      multilingual names, proposed at various times by MINC [MINC] and
-      others), or mechanisms that would have similar effects in terms of
-      Internet fragmentation and isolation.
-
-   o  For some purposes, it is desirable to be able to search not only
-      an index entry (labels or fully-qualified names in the DNS case),
-      but their values or targets (DNS data).  One might, for example,
-      want to locate all of the host (and virtual host) names which
-      cause mail to be directed to a given server via MX records.  The
-      DNS does not support this capability (see the discussion in
-      [IQUERY]) and it can be simulated only by extracting all of the
-      relevant records (perhaps by zone transfer if the source permits
-      doing so, but that permission is becoming less frequently
-      available) and then searching a file built from those records.
-
-   o  Finally, as additional types of personal or identifying
-      information are added to the DNS, issues arise with protection of
-      that information.  There are increasing calls to make different
-      information available based on the credentials and authorization
-      of the source of the inquiry.  As with information keyed to site
-      locations or proximity (as discussed above), the DNS protocols
-      make providing these differentiated services quite difficult if
-      not impossible.
-
-
-
-
-
-Klensin                      Informational                     [Page 11]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   In each of these cases, it is, or might be, possible to devise ways
-   to trick the DNS system into supporting mechanisms that were not
-   designed into it.  Several ingenious solutions have been proposed in
-   many of these areas already, and some have been deployed into the
-   marketplace with some success.  But the price of each of these
-   changes is added complexity and, with it, added risk of unexpected
-   and destabilizing problems.
-
-   Several of the above problems are addressed well by a good directory
-   system (supported by the LDAP protocol or some protocol more
-   precisely suited to these specific applications) or searching
-   environment (such as common web search engines) although not by the
-   DNS.  Given the difficulty of deploying new applications discussed
-   above, an important question is whether the tricks and kludges are
-   bad enough, or will become bad enough as usage grows, that new
-   solutions are needed and can be deployed.
-
-3. Searching, Directories, and the DNS
-
-3.1 Overview
-
-   The constraints of the DNS and the discussion above suggest the
-   introduction of an intermediate protocol mechanism, referred to below
-   as a "search layer" or "searchable system".  The terms "directory"
-   and "directory system" are used interchangeably with "searchable
-   system" in this document, although the latter is far more precise.
-   Search layer proposals would use a two (or more) stage lookup, not
-   unlike several of the proposals for internationalized names in the
-   DNS (see section 4), but all operations but the final one would
-   involve searching other systems, rather than looking up identifiers
-   in the DNS itself.  As explained below, this would permit relaxation
-   of several constraints, leading to a more capable and comprehensive
-   overall system.
-
-   Ultimately, many of the issues with domain names arise as the result
-   of efforts to use the DNS as a directory.  While, at the time this
-   document was written, sufficient pressure or demand had not occurred
-   to justify a change, it was already quite clear that, as a directory
-   system, the DNS is a good deal less than ideal.  This document
-   suggests that there actually is a requirement for a directory system,
-   and that the right solution to a searchable system requirement is a
-   searchable system, not a series of DNS patches, kludges, or
-   workarounds.
-
-
-
-
-
-
-
-
-Klensin                      Informational                     [Page 12]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   The following points illustrate particular aspects of this
-   conclusion.
-
-   o  A directory system would not require imposition of particular
-      length limits on names.
-
-   o  A directory system could permit explicit association of
-      attributes, e.g., language and country, with a name, without
-      having to utilize trick encodings to incorporate that information
-      in DNS labels (or creating artificial hierarchy for doing so).
-
-   o  There is considerable experience (albeit not much of it very
-      successful) in doing fuzzy and "sonex" (similar-sounding) matching
-      in directory systems.  Moreover, it is plausible to think about
-      different matching rules for different areas and sets of names so
-      that these can be adapted to local cultural requirements.
-      Specifically, it might be possible to have a single form of a name
-      in a directory, but to have great flexibility about what queries
-      matched that name (and even have different variations in different
-      areas).  Of course, the more flexibility that a system provides,
-      the greater the possibility of real or imagined trademark
-      conflicts.  But the opportunity would exist to design a directory
-      structure that dealt with those issues in an intelligent way,
-      while DNS constraints almost certainly make a general and
-      equitable DNS-only solution impossible.
-
-   o  If a directory system is used to translate to DNS names, and then
-      DNS names are looked up in the normal fashion, it may be possible
-      to relax several of the constraints that have been traditional
-      (and perhaps necessary) with the DNS.  For example, reverse-
-      mapping of addresses to directory names may not be a requirement
-      even if mapping of addresses to DNS names continues to be, since
-      the DNS name(s) would (continue to) uniquely identify the host.
-
-   o  Solutions to multilingual transcription problems that are common
-      in "normal life" (e.g., two-sided business cards to be sure that
-      recipients trying to contact a person can access romanized
-      spellings and numbers if the original language is not
-      comprehensible to them) can be easily handled in a directory
-      system by inserting both sets of entries.
-
-   o  A directory system could be designed that would return, not a
-      single name, but a set of names paired with network-locational
-      information or other context-establishing attributes.  This type
-      of information might be of considerable use in resolving the
-      "nearest (or best) server for a particular named resource"
-
-
-
-
-
-Klensin                      Informational                     [Page 13]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-      problems that are a significant concern for organizations hosting
-      web and other sites that are accessed from a wide range of
-      locations and subnets.
-
-   o  Names bound to countries and languages might help to manage
-      trademark realities, while, as discussed in section 1.3 above, use
-      of the DNS in trademark-significant contexts tends to require
-      worldwide "flattening" of the trademark system.
-
-   Many of these issues are a consequence of another property of the
-   DNS:  names must be unique across the Internet.  The need to have a
-   system of unique identifiers is fairly obvious (see [RFC2826]).
-   However, if that requirement were to be eliminated in a search or
-   directory system that was visible to users instead of the DNS, many
-   difficult problems -- of both an engineering and a policy nature --
-   would be likely to vanish.
-
-3.2 Some Details and Comments
-
-   Almost any internationalization proposal for names that are in, or
-   map into, the DNS will require changing DNS resolver API calls
-   ("gethostbyname" or equivalent), or adding some pre-resolution
-   preparation mechanism, in almost all Internet applications -- whether
-   to cause the API to take a different character set (no matter how it
-   is then mapped into the bits used in the DNS or another system), to
-   accept or return more arguments with qualifying or identifying
-   information, or otherwise.  Once applications must be opened to make
-   such changes, it is a relatively small matter to switch from calling
-   into the DNS to calling a directory service and then the DNS (in many
-   situations, both actions could be accomplished in a single API call).
-
-   A directory approach can be consistent both with "flat" models and
-   multi-attribute ones.  The DNS requires strict hierarchies, limiting
-   its ability to differentiate among names by their properties.  By
-   contrast, modern directories can utilize independently-searched
-   attributes and other structured schema to provide flexibilities not
-   present in a strictly hierarchical system.
-
-   There is a strong historical argument for a single directory
-   structure (implying a need for mechanisms for registration,
-   delegation, etc.).  But a single structure is not a strict
-   requirement, especially if in-depth case analysis and design work
-   leads to the conclusion that reverse-mapping to directory names is
-   not a requirement (see section 5).  If a single structure is not
-   needed, then, unlike the DNS, there would be no requirement for a
-   global organization to authorize or delegate operation of portions of
-   the structure.
-
-
-
-
-Klensin                      Informational                     [Page 14]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   The "no single structure" concept could be taken further by moving
-   away from simple "names" in favor of, e.g., multiattribute,
-   multihierarchical, faceted systems in which most of the facets use
-   restricted vocabularies.  (These terms are fairly standard in the
-   information retrieval and classification system literature, see,
-   e.g., [IS5127].)  Such systems could be designed to avoid the need
-   for procedures to ensure uniqueness across, or even within, providers
-   and databases of the faceted entities for which the search is to be
-   performed.  (See [DNS-Search] for further discussion.)
-
-   While the discussion above includes very general comments about
-   attributes, it appears that only a very small number of attributes
-   would be needed.  The list would almost certainly include country and
-   language for internationalization purposes.  It might require
-   "charset" if we cannot agree on a character set and encoding,
-   although there are strong arguments for simply using ISO 10646 (also
-   known as Unicode or "UCS" (for Universal Character Set) [UNICODE],
-   [IS10646] coding in interchange.  Trademark issues might motivate
-   "commercial" and "non-commercial" (or other) attributes if they would
-   be helpful in bypassing trademark problems.  And applications to
-   resource location, such as those contemplated for Uniform Resource
-   Identifiers (URIs) [RFC2396, RFC3305] or the Service Location
-   Protocol [RFC2608], might argue for a few other attributes (as
-   outlined above).
-
-4.  Internationalization
-
-   Much of the thinking underlying this document was driven by
-   considerations of internationalizing the DNS or, more specifically,
-   providing access to the functions of the DNS from languages and
-   naming systems that cannot be accurately expressed in the traditional
-   DNS subset of ASCII.  Much of the relevant work was done in the
-   IETF's "Internationalized Domain Names" Working Group (IDN-WG),
-   although this document also draws on extensive parallel discussions
-   in other forums.  This section contains an evaluation of what was
-   learned as an "internationalized DNS" or "multilingual DNS" was
-   explored and suggests future steps based on that evaluation.
-
-   When the IDN-WG was initiated, it was obvious to several of the
-   participants that its first important task was an undocumented one:
-   to increase the understanding of the complexities of the problem
-   sufficiently that naive solutions could be rejected and people could
-   go to work on the harder problems.  The IDN-WG clearly accomplished
-   that task. The beliefs that the problems were simple, and in the
-   corresponding simplistic approaches and their promises of quick and
-   painless deployment, effectively disappeared as the WG's efforts
-   matured.
-
-
-
-
-Klensin                      Informational                     [Page 15]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   Some of the lessons learned from increased understanding and the
-   dissipation of naive beliefs should be taken as cautions by the wider
-   community: the problems are not simple. Specifically, extracting
-   small elements for solution rather than looking at whole systems, may
-   result in obscuring the problems but not solving any problem that is
-   worth the trouble.
-
-4.1 ASCII Isn't Just Because of English
-
-   The hostname rules chosen in the mid-70s weren't just "ASCII because
-   English uses ASCII", although that was a starting point.  We have
-   discovered that almost every other script (and even ASCII if we
-   permit the rest of the characters specified in the ISO 646
-   International Reference Version) is more complex than hostname-
-   restricted-ASCII (the "LDH" form, see section 1.1).  And ASCII isn't
-   sufficient to completely represent English -- there are several words
-   in the language that are correctly spelled only with characters or
-   diacritical marks that do not appear in ASCII.  With a broader
-   selection of scripts, in some examples, case mapping works from one
-   case to the other but is not reversible.  In others, there are
-   conventions about alternate ways to represent characters (in the
-   language, not [only] in character coding) that work most of the time,
-   but not always.  And there are issues in coding, with Unicode/10646
-   providing different ways to represent the same character
-   ("character", rather than "glyph", is used deliberately here).  And,
-   in still others, there are questions as to whether two glyphs
-   "match", which may be a distance-function question, not one with a
-   binary answer.  The IETF approach to these problems is to require
-   pre-matching canonicalization (see the "stringprep" discussion
-   below).
-
-   The IETF has resisted the temptations to either try to specify an
-   entirely new coded character set, or to pick and choose Unicode/10646
-   characters on a per-character basis rather than by using well-defined
-   blocks.  While it may appear that a character set designed to meet
-   Internet-specific needs would be very attractive, the IETF has never
-   had the expertise, resources, and representation from critically-
-   important communities to actually take on that job.  Perhaps more
-   important, a new effort might have chosen to make some of the many
-   complex tradeoffs differently than the Unicode committee did,
-   producing a code with somewhat different characteristics.  But there
-   is no evidence that doing so would produce a code with fewer problems
-   and side-effects.  It is much more likely that making tradeoffs
-   differently would simply result in a different set of problems, which
-   would be equally or more difficult.
-
-
-
-
-
-
-Klensin                      Informational                     [Page 16]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-4.2 The "ASCII Encoding" Approaches
-
-   While the DNS can handle arbitrary binary strings without known
-   internal problems (see [RFC2181]), some restrictions are imposed by
-   the requirement that text be interpreted in a case-independent way
-   ([RFC1034], [RFC1035]).  More important, most internet applications
-   assume the hostname-restricted "LDH" syntax that is specified in the
-   host table RFCs and as "prudent" in RFC 1035.  If those assumptions
-   are not met, many conforming implementations of those applications
-   may exhibit behavior that would surprise implementors and users.  To
-   avoid these potential problems, IETF internationalization work has
-   focused on "ASCII-Compatible Encodings" (ACE).  These encodings
-   preserve the LDH conventions in the DNS itself.  Implementations of
-   applications that have not been upgraded utilize the encoded forms,
-   while newer ones can be written to recognize the special codings and
-   map them into non-ASCII characters. These approaches are, however,
-   not problem-free even if human interface issues are ignored.  Among
-   other issues, they rely on what is ultimately a heuristic to
-   determine whether a DNS label is to be considered as an
-   internationalized name (i.e., encoded Unicode) or interpreted as an
-   actual LDH name in its own right.  And, while all determinations of
-   whether a particular query matches a stored object are traditionally
-   made by DNS servers, the ACE systems, when combined with the
-   complexities of international scripts and names, require that much of
-   the matching work be separated into a separate, client-side,
-   canonicalization or "preparation" process before the DNS matching
-   mechanisms are invoked [STRINGPREP].
-
-4.3 "Stringprep" and Its Complexities
-
-   As outlined above, the model for avoiding problems associated with
-   putting non-ASCII names in the DNS and elsewhere evolved into the
-   principle that strings are to be placed into the DNS only after being
-   passed through a string preparation function that eliminates or
-   rejects spurious character codes, maps some characters onto others,
-   performs some sequence canonicalization, and generally creates forms
-   that can be accurately compared.  The impact of this process on
-   hostname-restricted ASCII (i.e., "LDH") strings is trivial and
-   essentially adds only overhead.  For other scripts, the impact is, of
-   necessity, quite significant.
-
-   Although the general notion underlying stringprep is simple, the many
-   details are quite subtle and the associated tradeoffs are complex. A
-   design team worked on it for months, with considerable effort placed
-   into clarifying and fine-tuning the protocol and tables.  Despite
-   general agreement that the IETF would avoid getting into the business
-   of defining character sets, character codings, and the associated
-   conventions, the group several times considered and rejected special
-
-
-
-Klensin                      Informational                     [Page 17]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   treatment of code positions to more nearly match the distinctions
-   made by Unicode with user perceptions about similarities and
-   differences between characters.  But there were intense temptations
-   (and pressures) to incorporate language-specific or country-specific
-   rules.  Those temptations, even when resisted, were indicative of
-   parts of the ongoing controversy or of the basic unsuitability of the
-   DNS for fully internationalized names that are visible,
-   comprehensible, and predictable for end users.
-
-   There have also been controversies about how far one should go in
-   these processes of preparation and transformation and, ultimately,
-   about the validity of various analogies.  For example, each of the
-   following operations has been claimed to be similar to case-mapping
-   in ASCII:
-
-   o  stripping of vowels in Arabic or Hebrew
-
-   o  matching of "look-alike" characters such as upper-case Alpha in
-      Greek and upper-case A in Roman-based alphabets
-
-   o  matching of Traditional and Simplified Chinese characters that
-      represent the same words,
-
-   o  matching of Serbo-Croatian words whether written in Roman-derived
-      or Cyrillic characters
-
-   A decision to support any of these operations would have implications
-   for other scripts or languages and would increase the overall
-   complexity of the process.  For example, unless language-specific
-   information is somehow available, performing matching between
-   Traditional and Simplified Chinese has impacts on Japanese and Korean
-   uses of the same "traditional" characters (e.g., it would not be
-   appropriate to map Kanji into Simplified Chinese).
-
-   Even were the IDN-WG's other work to have been abandoned completely
-   or if it were to fail in the marketplace, the stringprep and nameprep
-   work will continue to be extremely useful, both in identifying issues
-   and problem code points and in providing a reasonable set of basic
-   rules.  Where problems remain, they are arguably not with nameprep,
-   but with the DNS-imposed requirement that its results, as with all
-   other parts of the matching and comparison process, yield a binary
-   "match or no match" answer, rather than, e.g., a value on a
-   similarity scale that can be evaluated by the user or by user-driven
-   heuristic functions.
-
-
-
-
-
-
-
-Klensin                      Informational                     [Page 18]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-4.4 The Unicode Stability Problem
-
-   ISO 10646 basically defines only code points, and not rules for using
-   or comparing the characters.  This is part of a long-standing
-   tradition with the work of what is now ISO/IEC JTC1/SC2: they have
-   performed code point assignments and have typically treated the ways
-   in which characters are used as beyond their scope.  Consequently,
-   they have not dealt effectively with the broader range of
-   internationalization issues.  By contrast, the Unicode Technical
-   Committee (UTC) has defined, in annexes and technical reports (see,
-   e.g., [UTR15]), some additional rules for canonicalization and
-   comparison.  Many of those rules and conventions have been factored
-   into the "stringprep" and "nameprep" work, but it is not
-   straightforward to make or define them in a fashion that is
-   sufficiently precise and permanent to be relied on by the DNS.
-
-   Perhaps more important, the discussions leading to nameprep also
-   identified several areas in which the UTC definitions are inadequate,
-   at least without additional information, to make matching precise and
-   unambiguous.  In some of these cases, the Unicode Standard permits
-   several alternate approaches, none of which are an exact and obvious
-   match to DNS needs.  That has left these sensitive choices up to
-   IETF, which lacks sufficient in-depth expertise, much less any
-   mechanism for deciding to optimize one language at the expense of
-   another.
-
-   For example, it is tempting to define some rules on the basis of
-   membership in particular scripts, or for punctuation characters, but
-   there is no precise definition of what characters belong to which
-   script or which ones are, or are not, punctuation.  The existence of
-   these areas of vagueness raises two issues: whether trying to do
-   precise matching at the character set level is actually possible
-   (addressed below) and whether driving toward more precision could
-   create issues that cause instability in the implementation and
-   resolution models for the DNS.
-
-   The Unicode definition also evolves.  Version 3.2 appeared shortly
-   after work on this document was initiated.  It added some characters
-   and functionality and included a few minor incompatible code point
-   changes.  IETF has secured an agreement about constraints on future
-   changes, but it remains to be seen how that agreement will work out
-   in practice.  The prognosis actually appears poor at this stage,
-   since UTC chose to ballot a recent possible change which should have
-   been prohibited by the agreement (the outcome of the ballot is not
-   relevant, only that the ballot was issued rather than having the
-   result be a foregone conclusion).  However, some members of the
-   community consider some of the changes between Unicode 3.0 and 3.1
-   and between 3.1 and 3.2, as well as this recent ballot, to be
-
-
-
-Klensin                      Informational                     [Page 19]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   evidence of instability and that these instabilities are better
-   handled in a system that can be more flexible about handling of
-   characters, scripts, and ancillary information than the DNS.
-
-   In addition, because the systems implications of internationalization
-   are considered out of scope in SC2, ISO/IEC JTC1 has assigned some of
-   those issues to its SC22/WG20 (the Internationalization working group
-   within the subcommittee that deals with programming languages,
-   systems, and environments).  WG20 has historically dealt with
-   internationalization issues thoughtfully and in depth, but its status
-   has several times been in doubt in recent years.  However, assignment
-   of these matters to WG20 increases the risk of eventual ISO
-   internationalization standards that specify different behavior than
-   the UTC specifications.
-
-4.5 Audiences, End Users, and the User Interface Problem
-
-   Part of what has "caused" the DNS internationalization problem, as
-   well as the DNS trademark problem and several others, is that we have
-   stopped thinking about "identifiers for objects" -- which normal
-   people are not expected to see -- and started thinking about "names"
-   -- strings that are expected not only to be readable, but to have
-   linguistically-sensible and culturally-dependent meaning to non-
-   specialist users.
-
-   Within the IETF, the IDN-WG, and sometimes other groups, avoided
-   addressing the implications of that transition by taking "outside our
-   scope -- someone else's problem" approaches or by suggesting that
-   people will just become accustomed to whatever conventions are
-   adopted.  The realities of user and vendor behavior suggest that
-   these approaches will not serve the Internet community well in the
-   long term:
-
-   o  If we want to make it a problem in a different part of the user
-      interface structure, we need to figure out where it goes in order
-      to have proof of concept of our solution.  Unlike vendors whose
-      sole [business] model is the selling or registering of names, the
-      IETF must produce solutions that actually work, in the
-      applications context as seen by the end user.
-
-   o  The principle that "they will get used to our conventions and
-      adapt" is fine if we are writing rules for programming languages
-      or an API.  But the conventions under discussion are not part of a
-      semi-mathematical system, they are deeply ingrained in culture.
-      No matter how often an English-speaking American is told that the
-      Internet requires that the correct spelling of "colour" be used,
-      he or she isn't going to be convinced. Getting a French-speaker in
-      Lyon to use exactly the same lexical conventions as a French-
-
-
-
-Klensin                      Informational                     [Page 20]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-      speaker in Quebec in order to accommodate the decisions of the
-      IETF or of a registrar or registry is just not likely.  "Montreal"
-      is either a misspelling or an anglicization of a similar word with
-      an acute accent mark over the "e" (i.e., using the Unicode
-      character U+00E9 or one of its equivalents). But global agreement
-      on a rule that will determine whether the two forms should match
-      -- and that won't astonish end users and speakers of one language
-      or the other -- is as unlikely as agreement on whether
-      "misspelling" or "anglicization" is the greater travesty.
-
-   More generally, it is not clear that the outcome of any conceivable
-   nameprep-like process is going to be good enough for practical,
-   user-level, use.  In the use of human languages by humans, there are
-   many cases in which things that do not match are nonetheless
-   interpreted as matching.  The Norwegian/Danish character that appears
-   in U+00F8 (visually, a lower case 'o' overstruck with a forward
-   slash) and the "o-umlaut" German character that appears in U+00F6
-   (visually, a lower case 'o' with diaeresis (or umlaut)) are clearly
-   different and no matching program should yield an "equal" comparison.
-   But they are more similar to each other than either of them is to,
-   e.g., "e".  Humans are able to mentally make the correction in
-   context, and do so easily, and they can be surprised if computers
-   cannot do so.  Worse, there is a Swedish character whose appearance
-   is identical to the German o-umlaut, and which shares code point
-   U+00F6, but that, if the languages are known and the sounds of the
-   letters or meanings of words including the character are considered,
-   actually should match the Norwegian/Danish use of U+00F8.
-
-   This text uses examples in Roman scripts because it is being written
-   in English and those examples are relatively easy to render.  But one
-   of the important lessons of the discussions about domain name
-   internationalization in recent years is that problems similar to
-   those described above exist in almost every language and script.
-   Each one has its idiosyncrasies, and each set of idiosyncracies is
-   tied to common usage and cultural issues that are very familiar in
-   the relevant group, and often deeply held as cultural values.  As
-   long as a schoolchild in the US can get a bad grade on a spelling
-   test for using a perfectly valid British spelling, or one in France
-   or Germany can get a poor grade for leaving off a diacritical mark,
-   there are issues with the relevant language.  Similarly, if children
-   in Egypt or Israel are taught that it is acceptable to write a word
-   with or without vowels or stress marks, but that, if those marks are
-   included, they must be the correct ones, or a user in Korea is
-   potentially offended or astonished by out-of-order sequences of Jamo,
-   systems based on character-at-a-time processing and simplistic
-   matching, with no contextual information, are not going to satisfy
-   user needs.
-
-
-
-
-Klensin                      Informational                     [Page 21]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   Users are demanding solutions that deal with language and culture.
-   Systems of identifier symbol-strings that serve specialists or
-   computers are, at best, a solution to a rather different (and, at the
-   time this document was written, somewhat ill-defined), problem.  The
-   recent efforts have made it ever more clear that, if we ignore the
-   distinction between the user requirements and narrowly-defined
-   identifiers, we are solving an insufficient problem.  And,
-   conversely, the approaches that have been proposed to approximate
-   solutions to the user requirement may be far more complex than simple
-   identifiers require.
-
-4.6 Business Cards and Other Natural Uses of Natural Languages
-
-   Over the last few centuries, local conventions have been established
-   in various parts of the world for dealing with multilingual
-   situations.  It may be helpful to examine some of these.  For
-   example, if one visits a country where the language is different from
-   ones own, business cards are often printed on two sides, one side in
-   each language.  The conventions are not completely consistent and the
-   technique assumes that recipients will be tolerant. Translations of
-   names or places are attempted in some situations and transliterations
-   in others.  Since it is widely understood that exact translations or
-   transliterations are often not possible, people typically smile at
-   errors, appreciate the effort, and move on.
-
-   The DNS situation differs from these practices in at least two ways.
-   Since a global solution is required, the business card would need a
-   number of sides approximating the number of languages in the world,
-   which is probably impossible without violating laws of physics.  More
-   important, the opportunities for tolerance don't exist:  the DNS
-   requires a exact match or the lookup fails.
-
-4.7 ASCII Encodings and the Roman Keyboard Assumption
-
-   Part of the argument for ACE-based solutions is that they provide an
-   escape for multilingual environments when applications have not been
-   upgraded.  When an older application encounters an ACE-based name,
-   the assumption is that the (admittedly ugly) ASCII-coded string will
-   be displayed and can be typed in.  This argument is reasonable from
-   the standpoint of mixtures of Roman-based alphabets, but may not be
-   relevant if user-level systems and devices are involved that do not
-   support the entry of Roman-based characters or which cannot
-   conveniently render such characters.  Such systems are few in the
-   world today, but the number can reasonably be expected to rise as the
-   Internet is increasingly used by populations whose primary concern is
-   with local issues, local information, and local languages.  It is,
-
-
-
-
-
-Klensin                      Informational                     [Page 22]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   for example, fairly easy to imagine populations who use Arabic or
-   Thai scripts and who do not have routine access to scripts or input
-   devices based on Roman-derived alphabets.
-
-4.8 Intra-DNS Approaches for "Multilingual Names"
-
-   It appears, from the cases above and others, that none of the intra-
-   DNS-based solutions for "multilingual names" are workable.  They rest
-   on too many assumptions that do not appear to be feasible -- that
-   people will adapt deeply-entrenched language habits to conventions
-   laid down to make the lives of computers easy; that we can make
-   "freeze it now, no need for changes in these areas" decisions about
-   Unicode and nameprep; that ACE will smooth over applications
-   problems, even in environments without the ability to key or render
-   Roman-based glyphs (or where user experience is such that such glyphs
-   cannot easily be distinguished from each other); that the Unicode
-   Consortium will never decide to repair an error in a way that creates
-   a risk of DNS incompatibility; that we can either deploy EDNS
-   [RFC2671] or that long names are not really important; that Japanese
-   and Chinese computer users (and others) will either give up their
-   local or IS 2022-based character coding solutions (for which addition
-   of a large fraction of a million new code points to Unicode is almost
-   certainly a necessary, but probably not sufficient, condition) or
-   build leakproof and completely accurate boundary conversion
-   mechanisms; that out of band or contextual information will always be
-   sufficient for the "map glyph onto script" problem; and so on.  In
-   each case, it is likely that about 80% or 90% of cases will work
-   satisfactorily, but it is unlikely that such partial solutions will
-   be good enough.  For example, suppose someone can spell her name 90%
-   correctly, or a company name is matched correctly 80% of the time but
-   the other 20% of attempts identify a competitor: are either likely to
-   be considered adequate?
-
-5. Search-based Systems: The Key Controversies
-
-   For many years, a common response to requirements to locate people or
-   resources on the Internet has been to invoke the term "directory".
-   While an in-depth analysis of the reasons would require a separate
-   document, the history of failure of these invocations has given
-   "directory" efforts a bad reputation.  The effort proposed here is
-   different from those predecessors for several reasons, perhaps the
-   most important of which is that it focuses on a fairly-well-
-   understood set of problems and needs, rather than on finding uses for
-   a particular technology.
-
-   As suggested in some of the text above, it is an open question as to
-   whether the needs of the community would be best served by a single
-   (even if functionally, and perhaps administratively, distributed)
-
-
-
-Klensin                      Informational                     [Page 23]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   directory with universal applicability, a single directory that
-   supports locally-tailored search (and, most important, matching)
-   functions, or multiple, locally-determined, directories.  Each has
-   its attractions.  Any but the first would essentially prevent
-   reverse-mapping (determination of the user-visible name of the host
-   or resource from target information such as an address or DNS name).
-   But reverse mapping has become less useful over the years --at least
-   to users -- as more and more names have been associated with many
-   host addresses and as CIDR [CIDR] has proven problematic for mapping
-   smaller address blocks to meaningful names.
-
-   Locally-tailored searches and mappings would permit national
-   variations on interpretation of which strings matched which other
-   ones, an arrangement that is especially important when different
-   localities apply different rules to, e.g., matching of characters
-   with and without diacriticals.  But, of course, this implies that a
-   URL may evaluate properly or not depending on either settings on a
-   client machine or the network connectivity of the user.  That is not,
-   in general, a desirable situation, since it implies that users could
-   not, in the general case, share URLs (or other host references) and
-   that a particular user might not be able to carry references from one
-   host or location to another.
-
-   And, of course, completely separate directories would permit
-   translation and transliteration functions to be embedded in the
-   directory, giving much of the Internet a different appearance
-   depending on which directory was chosen.  The attractions of this are
-   obvious, but, unless things were very carefully designed to preserve
-   uniqueness and precise identities at the right points (which may or
-   may not be possible), such a system would have many of the
-   difficulties associated with multiple DNS roots.
-
-   Finally, a system of separate directories and databases, if coupled
-   with removal of the DNS-imposed requirement for unique names, would
-   largely eliminate the need for a single worldwide authority to manage
-   the top of the naming hierarchy.
-
-6.  Security Considerations
-
-   The set of proposals implied by this document suggests an interesting
-   set of security issues (i.e., nothing important is ever easy).  A
-   directory system used for locating network resources would presumably
-   need to be as carefully protected against unauthorized changes as the
-   DNS itself.  There also might be new opportunities for problems in an
-   arrangement involving two or more (sub)layers, especially if such a
-   system were designed without central authority or uniqueness of
-   names.  It is uncertain how much greater those risks would be as
-   compared to a DNS lookup sequence that involved looking up one name,
-
-
-
-Klensin                      Informational                     [Page 24]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   getting back information, and then doing additional lookups
-   potentially in different subtrees.  That multistage lookup will often
-   be the case with, e.g., NAPTR records [RFC 2915] unless additional
-   restrictions are imposed.  But additional steps, systems, and
-   databases almost certainly involve some additional risks of
-   compromise.
-
-7.  References
-
-7.1 Normative References
-
-   None
-
-7.2 Explanatory and Informative References
-
-   [Albitz]       Any of the editions of Albitz, P. and C. Liu, DNS and
-                  BIND, O'Reilly and Associates, 1992, 1997, 1998, 2001.
-
-   [ASCII]        American National Standards Institute (formerly United
-                  States of America Standards Institute), X3.4, 1968,
-                  "USA Code for Information Interchange". ANSI X3.4-1968
-                  has been replaced by newer versions with slight
-                  modifications, but the 1968 version remains definitive
-                  for the Internet.  Some time after ASCII was first
-                  formulated as a standard, ISO adopted international
-                  standard 646, which uses ASCII as a base.  IS 646
-                  actually contained two code tables: an "International
-                  Reference Version" (often referenced as ISO 646-IRV)
-                  which was essentially identical to the ASCII of the
-                  time, and a "Basic Version" (ISO 646-BV), which
-                  designates a number of character positions for
-                  national use.
-
-   [CIDR]         Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless
-                  Inter-Domain Routing (CIDR): an Address Assignment and
-                  Aggregation Strategy", RFC 1519, September 1993.
-
-                  Eidnes, H., de Groot, G. and P. Vixie, "Classless IN-
-                  ADDR.ARPA delegation", RFC 2317, March 1998.
-
-   [COM-SIZE]     Size information supplied by Verisign Global Registry
-                  Services (the zone administrator, or "registry
-                  operator", for COM, see [REGISTRAR], below) to ICANN,
-                  third quarter 2002.
-
-   [DNS-Search]   Klensin, J., "A Search-based access model for the
-                  DNS", Work in Progress.
-
-
-
-
-Klensin                      Informational                     [Page 25]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   [FINGER]       Zimmerman, D., "The Finger User Information Protocol",
-                  RFC 1288, December 1991.
-
-                  Harrenstien, K., "NAME/FINGER Protocol", RFC 742,
-                  December 1977.
-
-   [IAB-OPES]     Floyd, S. and L. Daigle, "IAB Architectural and Policy
-                  Considerations for Open Pluggable Edge Services", RFC
-                  3238, January 2002.
-
-   [IQUERY]       Lawrence, D., "Obsoleting IQUERY", RFC 3425, November
-                  2002.
-
-   [IS646]        ISO/IEC 646:1991 Information technology -- ISO 7-bit
-                  coded character set for information interchange
-
-   [IS10646]      ISO/IEC 10646-1:2000 Information technology --
-                  Universal Multiple-Octet Coded Character Set (UCS) --
-                  Part 1: Architecture and Basic Multilingual Plane and
-                  ISO/IEC 10646-2:2001 Information technology --
-                  Universal Multiple-Octet Coded Character Set (UCS) --
-                  Part 2: Supplementary Planes
-
-   [MINC]         The Multilingual Internet Names Consortium,
-                  http://www.minc.org/ has been an early advocate for
-                  the importance of expansion of DNS names to
-                  accommodate non-ASCII characters.  Some of their
-                  specific proposals, while helping people to understand
-                  the problems better, were not compatible with the
-                  design of the DNS.
-
-   [NAPTR]        Mealling, M. and R. Daniel, "The Naming Authority
-                  Pointer (NAPTR) DNS Resource Record", RFC 2915,
-                  September 2000.
-
-                  Mealling, M., "Dynamic Delegation Discovery System
-                  (DDDS) Part One: The Comprehensive DDDS", RFC 3401,
-                  October 2002.
-
-                  Mealling, M., "Dynamic Delegation Discovery System
-                  (DDDS) Part Two: The Algorithm", RFC 3402, October
-                  2002.
-
-                  Mealling, M., "Dynamic Delegation Discovery System
-                  (DDDS) Part Three: The Domain Name System (DNS)
-                  Database", RFC 3403, October 2002.
-
-
-
-
-
-Klensin                      Informational                     [Page 26]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   [REGISTRAR]    In an early stage of the process that created the
-                  Internet Corporation for Assigned Names and Numbers
-                  (ICANN), a "Green Paper" was released by the US
-                  Government.   That paper introduced new terminology
-                  and some concepts not needed by traditional DNS
-                  operations.  The term "registry" was applied to the
-                  actual operator and database holder of a domain
-                  (typically at the top level, since the Green Paper was
-                  little concerned with anything else), while
-                  organizations that marketed names and made them
-                  available to "registrants" were known as "registrars".
-                  In the classic DNS model, the function of "zone
-                  administrator" encompassed both registry and registrar
-                  roles, although that model did not anticipate a
-                  commercial market in names.
-
-   [RFC625]       Kudlick, M. and E. Feinler, "On-line hostnames
-                  service", RFC 625, March 1974.
-
-   [RFC734]       Crispin, M., "SUPDUP Protocol", RFC 734, October 1977.
-
-   [RFC811]       Harrenstien, K., White, V. and E. Feinler, "Hostnames
-                  Server", RFC 811, March 1982.
-
-   [RFC819]       Su, Z. and J. Postel, "Domain naming convention for
-                  Internet user applications", RFC 819, August 1982.
-
-   [RFC830]       Su, Z., "Distributed system for Internet name
-                  service", RFC 830, October 1982.
-
-   [RFC882]       Mockapetris, P., "Domain names: Concepts and
-                  facilities", RFC 882, November 1983.
-
-   [RFC883]       Mockapetris, P., "Domain names: Implementation
-                  specification", RFC 883, November 1983.
-
-   [RFC952]       Harrenstien, K, Stahl, M. and E. Feinler, "DoD
-                  Internet host table specification", RFC 952, October
-                  1985.
-
-   [RFC953]       Harrenstien, K., Stahl, M. and E. Feinler, "HOSTNAME
-                  SERVER", RFC 953, October 1985.
-
-   [RFC1034]      Mockapetris, P., "Domain names, Concepts and
-                  facilities", STD 13, RFC 1034, November 1987.
-
-
-
-
-
-
-Klensin                      Informational                     [Page 27]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   [RFC1035]      Mockapetris, P., "Domain names - implementation and
-                  specification", STD 13, RFC 1035, November 1987.
-
-   [RFC1591]      Postel, J., "Domain Name System Structure and
-                  Delegation", RFC 1591, March 1994.
-
-   [RFC2181]      Elz, R. and  R. Bush, "Clarifications to the DNS
-                  Specification", RFC 2181, July 1997.
-
-   [RFC2295]      Holtman, K. and A. Mutz, "Transparent Content
-                  Negotiation in HTTP", RFC 2295, March 1998
-
-   [RFC2396]      Berners-Lee, T., Fielding, R. and L. Masinter,
-                  "Uniform Resource Identifiers (URI): Generic Syntax",
-                  RFC 2396, August 1998.
-
-   [RFC2608]      Guttman, E., Perkins, C., Veizades, J. and M. Day,
-                  "Service Location Protocol, Version 2", RFC 2608, June
-                  1999.
-
-   [RFC2671]      Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
-                  2671, August 1999.
-
-   [RFC2825]      IAB, Daigle, L., Ed., "A Tangled Web: Issues of I18N,
-                  Domain Names, and the Other Internet protocols", RFC
-                  2825, May 2000.
-
-   [RFC2826]      IAB, "IAB Technical Comment on the Unique DNS Root",
-                  RFC 2826, May 2000.
-
-   [RFC2972]      Popp, N., Mealling, M., Masinter, L. and K. Sollins,
-                  "Context and Goals for Common Name Resolution", RFC
-                  2972, October 2000.
-
-   [RFC3305]      Mealling, M. and R. Denenberg, Eds., "Report from the
-                  Joint W3C/IETF URI Planning Interest Group: Uniform
-                  Resource Identifiers (URIs), URLs, and Uniform
-                  Resource Names (URNs):  Clarifications and
-                  Recommendations", RFC 3305, August 2002.
-
-   [RFC3439]      Bush, R. and D. Meyer, "Some Internet Architectural
-                  Guidelines and Philosophy", RFC 3439, December 2002.
-
-   [Seng]         Seng, J., et al., Eds., "Internationalized Domain
-                  Names:  Registration and Administration Guideline for
-                  Chinese, Japanese, and Korean", Work in Progress.
-
-
-
-
-
-Klensin                      Informational                     [Page 28]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   [STRINGPREP]   Hoffman, P. and M. Blanchet, "Preparation of
-                  Internationalized Strings (stringprep)", RFC 3454,
-                  December 2002.
-
-                  The particular profile used for placing
-                  internationalized strings in the DNS is called
-                  "nameprep", described in Hoffman, P. and M. Blanchet,
-                  "Nameprep: A Stringprep Profile for Internationalized
-                  Domain Names", Work in Progress.
-
-   [TELNET]       Postel, J. and J. Reynolds, "Telnet Protocol
-                  Specification", STD 8, RFC 854, May 1983.
-
-                  Postel, J. and J. Reynolds, "Telnet Option
-                  Specifications", STD 8, RFC 855, May 1983.
-
-   [UNICODE]      The Unicode Consortium, The Unicode Standard, Version
-                  3.0, Addison-Wesley: Reading, MA, 2000.  Update to
-                  version 3.1, 2001.  Update to version 3.2, 2002.
-
-   [UTR15]        Davis, M. and M. Duerst, "Unicode Standard Annex #15:
-                  Unicode Normalization Forms", Unicode Consortium,
-                  March 2002.  An integral part of The Unicode Standard,
-                  Version 3.1.1.  Available at
-                  (http://www.unicode.org/reports/tr15/tr15-21.html).
-
-   [WHOIS]        Harrenstien, K, Stahl, M. and E. Feinler,
-                  "NICNAME/WHOIS", RFC 954, October 1985.
-
-   [WHOIS-UPDATE] Gargano, J. and K. Weiss, "Whois and Network
-                  Information Lookup Service, Whois++", RFC 1834, August
-                  1995.
-
-                  Weider, C., Fullton, J. and S. Spero, "Architecture of
-                  the Whois++ Index Service", RFC 1913, February 1996.
-
-                  Williamson, S., Kosters, M., Blacka, D., Singh, J. and
-                  K. Zeilstra, "Referral Whois (RWhois) Protocol V1.5",
-                  RFC 2167, June 1997;
-
-                  Daigle, L. and P. Faltstrom, "The
-                  application/whoispp-query Content-Type", RFC 2957,
-                  October 2000.
-
-                  Daigle, L. and P. Falstrom, "The application/whoispp-
-                  response Content-type", RFC 2958, October 2000.
-
-
-
-
-
-Klensin                      Informational                     [Page 29]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   [X29]          International Telecommuncations Union, "Recommendation
-                  X.29: Procedures for the exchange of control
-                  information and user data between a Packet
-                  Assembly/Disassembly (PAD) facility and a packet mode
-                  DTE or another PAD", December 1997.
-
-8. Acknowledgements
-
-   Many people have contributed to versions of this document or the
-   thinking that went into it.  The author would particularly like to
-   thank Harald Alvestrand, Rob Austein, Bob Braden, Vinton Cerf, Matt
-   Crawford, Leslie Daigle, Patrik Faltstrom, Eric A. Hall, Ted Hardie,
-   Paul Hoffman, Erik Nordmark, and Zita Wenzel for making specific
-   suggestions and/or challenging the assumptions and presentation of
-   earlier versions and suggesting ways to improve them.
-
-9. Author's Address
-
-   John C. Klensin
-   1770 Massachusetts Ave, #322
-   Cambridge, MA 02140
-
-   EMail: klensin+srch@jck.com
-
-   A mailing list has been initiated for discussion of the topics
-   discussed in this document, and closely-related issues, at
-   ietf-irnss@lists.elistx.com.  See http://lists.elistx.com/archives/
-   for subscription and archival information.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Klensin                      Informational                     [Page 30]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-10. Full Copyright Statement
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Klensin                      Informational                     [Page 31]
-
diff --git a/contrib/bind9/doc/rfc/rfc3490.txt b/contrib/bind9/doc/rfc/rfc3490.txt
deleted file mode 100644
index d2e0b3b..0000000
--- a/contrib/bind9/doc/rfc/rfc3490.txt
+++ /dev/null
@@ -1,1235 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                       P. Faltstrom
-Request for Comments: 3490                                         Cisco
-Category: Standards Track                                     P. Hoffman
-                                                              IMC & VPNC
-                                                             A. Costello
-                                                             UC Berkeley
-                                                              March 2003
-
-
-         Internationalizing Domain Names in Applications (IDNA)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-Abstract
-
-   Until now, there has been no standard method for domain names to use
-   characters outside the ASCII repertoire.  This document defines
-   internationalized domain names (IDNs) and a mechanism called
-   Internationalizing Domain Names in Applications (IDNA) for handling
-   them in a standard fashion.  IDNs use characters drawn from a large
-   repertoire (Unicode), but IDNA allows the non-ASCII characters to be
-   represented using only the ASCII characters already allowed in so-
-   called host names today.  This backward-compatible representation is
-   required in existing protocols like DNS, so that IDNs can be
-   introduced with no changes to the existing infrastructure.  IDNA is
-   only meant for processing domain names, not free text.
-
-Table of Contents
-
-   1. Introduction..................................................  2
-      1.1 Problem Statement.........................................  3
-      1.2 Limitations of IDNA.......................................  3
-      1.3 Brief overview for application developers.................  4
-   2. Terminology...................................................  5
-   3. Requirements and applicability................................  7
-      3.1 Requirements..............................................  7
-      3.2 Applicability.............................................  8
-         3.2.1. DNS resource records................................  8
-
-
-
-Faltstrom, et al.           Standards Track                     [Page 1]
-
-RFC 3490                          IDNA                        March 2003
-
-
-         3.2.2. Non-domain-name data types stored in domain names...  9
-   4. Conversion operations.........................................  9
-      4.1 ToASCII................................................... 10
-      4.2 ToUnicode................................................. 11
-   5. ACE prefix.................................................... 12
-   6. Implications for typical applications using DNS............... 13
-      6.1 Entry and display in applications......................... 14
-      6.2 Applications and resolver libraries....................... 15
-      6.3 DNS servers............................................... 15
-      6.4 Avoiding exposing users to the raw ACE encoding........... 16
-      6.5  DNSSEC authentication of IDN domain names................ 16
-   7. Name server considerations.................................... 17
-   8. Root server considerations.................................... 17
-   9. References.................................................... 18
-      9.1 Normative References...................................... 18
-      9.2 Informative References.................................... 18
-   10. Security Considerations...................................... 19
-   11. IANA Considerations.......................................... 20
-   12. Authors' Addresses........................................... 21
-   13. Full Copyright Statement..................................... 22
-
-1. Introduction
-
-   IDNA works by allowing applications to use certain ASCII name labels
-   (beginning with a special prefix) to represent non-ASCII name labels.
-   Lower-layer protocols need not be aware of this; therefore IDNA does
-   not depend on changes to any infrastructure.  In particular, IDNA
-   does not depend on any changes to DNS servers, resolvers, or protocol
-   elements, because the ASCII name service provided by the existing DNS
-   is entirely sufficient for IDNA.
-
-   This document does not require any applications to conform to IDNA,
-   but applications can elect to use IDNA in order to support IDN while
-   maintaining interoperability with existing infrastructure.  If an
-   application wants to use non-ASCII characters in domain names, IDNA
-   is the only currently-defined option.  Adding IDNA support to an
-   existing application entails changes to the application only, and
-   leaves room for flexibility in the user interface.
-
-   A great deal of the discussion of IDN solutions has focused on
-   transition issues and how IDN will work in a world where not all of
-   the components have been updated.  Proposals that were not chosen by
-   the IDN Working Group would depend on user applications, resolvers,
-   and DNS servers being updated in order for a user to use an
-   internationalized domain name.  Rather than rely on widespread
-   updating of all components, IDNA depends on updates to user
-   applications only; no changes are needed to the DNS protocol or any
-   DNS servers or the resolvers on user's computers.
-
-
-
-Faltstrom, et al.           Standards Track                     [Page 2]
-
-RFC 3490                          IDNA                        March 2003
-
-
-1.1 Problem Statement
-
-   The IDNA specification solves the problem of extending the repertoire
-   of characters that can be used in domain names to include the Unicode
-   repertoire (with some restrictions).
-
-   IDNA does not extend the service offered by DNS to the applications.
-   Instead, the applications (and, by implication, the users) continue
-   to see an exact-match lookup service.  Either there is a single
-   exactly-matching name or there is no match.  This model has served
-   the existing applications well, but it requires, with or without
-   internationalized domain names, that users know the exact spelling of
-   the domain names that the users type into applications such as web
-   browsers and mail user agents.  The introduction of the larger
-   repertoire of characters potentially makes the set of misspellings
-   larger, especially given that in some cases the same appearance, for
-   example on a business card, might visually match several Unicode code
-   points or several sequences of code points.
-
-   IDNA allows the graceful introduction of IDNs not only by avoiding
-   upgrades to existing infrastructure (such as DNS servers and mail
-   transport agents), but also by allowing some rudimentary use of IDNs
-   in applications by using the ASCII representation of the non-ASCII
-   name labels.  While such names are very user-unfriendly to read and
-   type, and hence are not suitable for user input, they allow (for
-   instance) replying to email and clicking on URLs even though the
-   domain name displayed is incomprehensible to the user.  In order to
-   allow user-friendly input and output of the IDNs, the applications
-   need to be modified to conform to this specification.
-
-   IDNA uses the Unicode character repertoire, which avoids the
-   significant delays that would be inherent in waiting for a different
-   and specific character set be defined for IDN purposes by some other
-   standards developing organization.
-
-1.2 Limitations of IDNA
-
-   The IDNA protocol does not solve all linguistic issues with users
-   inputting names in different scripts.  Many important language-based
-   and script-based mappings are not covered in IDNA and need to be
-   handled outside the protocol.  For example, names that are entered in
-   a mix of traditional and simplified Chinese characters will not be
-   mapped to a single canonical name.  Another example is Scandinavian
-   names that are entered with U+00F6 (LATIN SMALL LETTER O WITH
-   DIAERESIS) will not be mapped to U+00F8 (LATIN SMALL LETTER O WITH
-   STROKE).
-
-
-
-
-
-Faltstrom, et al.           Standards Track                     [Page 3]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   An example of an important issue that is not considered in detail in
-   IDNA is how to provide a high probability that a user who is entering
-   a domain name based on visual information (such as from a business
-   card or billboard) or aural information (such as from a telephone or
-   radio) would correctly enter the IDN.  Similar issues exist for ASCII
-   domain names, for example the possible visual confusion between the
-   letter 'O' and the digit zero, but the introduction of the larger
-   repertoire of characters creates more opportunities of similar
-   looking and similar sounding names.  Note that this is a complex
-   issue relating to languages, input methods on computers, and so on.
-   Furthermore, the kind of matching and searching necessary for a high
-   probability of success would not fit the role of the DNS and its
-   exact matching function.
-
-1.3 Brief overview for application developers
-
-   Applications can use IDNA to support internationalized domain names
-   anywhere that ASCII domain names are already supported, including DNS
-   master files and resolver interfaces.  (Applications can also define
-   protocols and interfaces that support IDNs directly using non-ASCII
-   representations.  IDNA does not prescribe any particular
-   representation for new protocols, but it still defines which names
-   are valid and how they are compared.)
-
-   The IDNA protocol is contained completely within applications.  It is
-   not a client-server or peer-to-peer protocol: everything is done
-   inside the application itself.  When used with a DNS resolver
-   library, IDNA is inserted as a "shim" between the application and the
-   resolver library.  When used for writing names into a DNS zone, IDNA
-   is used just before the name is committed to the zone.
-
-   There are two operations described in section 4 of this document:
-
-   -  The ToASCII operation is used before sending an IDN to something
-      that expects ASCII names (such as a resolver) or writing an IDN
-      into a place that expects ASCII names (such as a DNS master file).
-
-   -  The ToUnicode operation is used when displaying names to users,
-      for example names obtained from a DNS zone.
-
-   It is important to note that the ToASCII operation can fail.  If it
-   fails when processing a domain name, that domain name cannot be used
-   as an internationalized domain name and the application has to have
-   some method of dealing with this failure.
-
-   IDNA requires that implementations process input strings with
-   Nameprep [NAMEPREP], which is a profile of Stringprep [STRINGPREP],
-   and then with Punycode [PUNYCODE].  Implementations of IDNA MUST
-
-
-
-Faltstrom, et al.           Standards Track                     [Page 4]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   fully implement Nameprep and Punycode; neither Nameprep nor Punycode
-   are optional.
-
-2. Terminology
-
-   The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
-   and "MAY" in this document are to be interpreted as described in BCP
-   14, RFC 2119 [RFC2119].
-
-   A code point is an integer value associated with a character in a
-   coded character set.
-
-   Unicode [UNICODE] is a coded character set containing tens of
-   thousands of characters.  A single Unicode code point is denoted by
-   "U+" followed by four to six hexadecimal digits, while a range of
-   Unicode code points is denoted by two hexadecimal numbers separated
-   by "..", with no prefixes.
-
-   ASCII means US-ASCII [USASCII], a coded character set containing 128
-   characters associated with code points in the range 0..7F.  Unicode
-   is an extension of ASCII: it includes all the ASCII characters and
-   associates them with the same code points.
-
-   The term "LDH code points" is defined in this document to mean the
-   code points associated with ASCII letters, digits, and the hyphen-
-   minus; that is, U+002D, 30..39, 41..5A, and 61..7A. "LDH" is an
-   abbreviation for "letters, digits, hyphen".
-
-   [STD13] talks about "domain names" and "host names", but many people
-   use the terms interchangeably.  Further, because [STD13] was not
-   terribly clear, many people who are sure they know the exact
-   definitions of each of these terms disagree on the definitions.  In
-   this document the term "domain name" is used in general.  This
-   document explicitly cites [STD3] whenever referring to the host name
-   syntax restrictions defined therein.
-
-   A label is an individual part of a domain name.  Labels are usually
-   shown separated by dots; for example, the domain name
-   "www.example.com" is composed of three labels: "www", "example", and
-   "com".  (The zero-length root label described in [STD13], which can
-   be explicit as in "www.example.com." or implicit as in
-   "www.example.com", is not considered a label in this specification.)
-   IDNA extends the set of usable characters in labels that are text.
-   For the rest of this document, the term "label" is shorthand for
-   "text label", and "every label" means "every text label".
-
-
-
-
-
-
-Faltstrom, et al.           Standards Track                     [Page 5]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   An "internationalized label" is a label to which the ToASCII
-   operation (see section 4) can be applied without failing (with the
-   UseSTD3ASCIIRules flag unset).  This implies that every ASCII label
-   that satisfies the [STD13] length restriction is an internationalized
-   label.  Therefore the term "internationalized label" is a
-   generalization, embracing both old ASCII labels and new non-ASCII
-   labels.  Although most Unicode characters can appear in
-   internationalized labels, ToASCII will fail for some input strings,
-   and such strings are not valid internationalized labels.
-
-   An "internationalized domain name" (IDN) is a domain name in which
-   every label is an internationalized label.  This implies that every
-   ASCII domain name is an IDN (which implies that it is possible for a
-   name to be an IDN without it containing any non-ASCII characters).
-   This document does not attempt to define an "internationalized host
-   name".  Just as has been the case with ASCII names, some DNS zone
-   administrators may impose restrictions, beyond those imposed by DNS
-   or IDNA, on the characters or strings that may be registered as
-   labels in their zones.  Such restrictions have no impact on the
-   syntax or semantics of DNS protocol messages; a query for a name that
-   matches no records will yield the same response regardless of the
-   reason why it is not in the zone.  Clients issuing queries or
-   interpreting responses cannot be assumed to have any knowledge of
-   zone-specific restrictions or conventions.
-
-   In IDNA, equivalence of labels is defined in terms of the ToASCII
-   operation, which constructs an ASCII form for a given label, whether
-   or not the label was already an ASCII label.  Labels are defined to
-   be equivalent if and only if their ASCII forms produced by ToASCII
-   match using a case-insensitive ASCII comparison.  ASCII labels
-   already have a notion of equivalence: upper case and lower case are
-   considered equivalent.  The IDNA notion of equivalence is an
-   extension of that older notion.  Equivalent labels in IDNA are
-   treated as alternate forms of the same label, just as "foo" and "Foo"
-   are treated as alternate forms of the same label.
-
-   To allow internationalized labels to be handled by existing
-   applications, IDNA uses an "ACE label" (ACE stands for ASCII
-   Compatible Encoding).  An ACE label is an internationalized label
-   that can be rendered in ASCII and is equivalent to an
-   internationalized label that cannot be rendered in ASCII.  Given any
-   internationalized label that cannot be rendered in ASCII, the ToASCII
-   operation will convert it to an equivalent ACE label (whereas an
-   ASCII label will be left unaltered by ToASCII).  ACE labels are
-   unsuitable for display to users.  The ToUnicode operation will
-   convert any label to an equivalent non-ACE label.  In fact, an ACE
-   label is formally defined to be any label that the ToUnicode
-   operation would alter (whereas non-ACE labels are left unaltered by
-
-
-
-Faltstrom, et al.           Standards Track                     [Page 6]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   ToUnicode).  Every ACE label begins with the ACE prefix specified in
-   section 5.  The ToASCII and ToUnicode operations are specified in
-   section 4.
-
-   The "ACE prefix" is defined in this document to be a string of ASCII
-   characters that appears at the beginning of every ACE label.  It is
-   specified in section 5.
-
-   A "domain name slot" is defined in this document to be a protocol
-   element or a function argument or a return value (and so on)
-   explicitly designated for carrying a domain name.  Examples of domain
-   name slots include: the QNAME field of a DNS query; the name argument
-   of the gethostbyname() library function; the part of an email address
-   following the at-sign (@) in the From: field of an email message
-   header; and the host portion of the URI in the src attribute of an
-   HTML <IMG> tag.  General text that just happens to contain a domain
-   name is not a domain name slot; for example, a domain name appearing
-   in the plain text body of an email message is not occupying a domain
-   name slot.
-
-   An "IDN-aware domain name slot" is defined in this document to be a
-   domain name slot explicitly designated for carrying an
-   internationalized domain name as defined in this document.  The
-   designation may be static (for example, in the specification of the
-   protocol or interface) or dynamic (for example, as a result of
-   negotiation in an interactive session).
-
-   An "IDN-unaware domain name slot" is defined in this document to be
-   any domain name slot that is not an IDN-aware domain name slot.
-   Obviously, this includes any domain name slot whose specification
-   predates IDNA.
-
-3. Requirements and applicability
-
-3.1 Requirements
-
-   IDNA conformance means adherence to the following four requirements:
-
-   1) Whenever dots are used as label separators, the following
-      characters MUST be recognized as dots: U+002E (full stop), U+3002
-      (ideographic full stop), U+FF0E (fullwidth full stop), U+FF61
-      (halfwidth ideographic full stop).
-
-   2) Whenever a domain name is put into an IDN-unaware domain name slot
-      (see section 2), it MUST contain only ASCII characters.  Given an
-      internationalized domain name (IDN), an equivalent domain name
-      satisfying this requirement can be obtained by applying the
-
-
-
-
-Faltstrom, et al.           Standards Track                     [Page 7]
-
-RFC 3490                          IDNA                        March 2003
-
-
-      ToASCII operation (see section 4) to each label and, if dots are
-      used as label separators, changing all the label separators to
-      U+002E.
-
-   3) ACE labels obtained from domain name slots SHOULD be hidden from
-      users when it is known that the environment can handle the non-ACE
-      form, except when the ACE form is explicitly requested.  When it
-      is not known whether or not the environment can handle the non-ACE
-      form, the application MAY use the non-ACE form (which might fail,
-      such as by not being displayed properly), or it MAY use the ACE
-      form (which will look unintelligle to the user).  Given an
-      internationalized domain name, an equivalent domain name
-      containing no ACE labels can be obtained by applying the ToUnicode
-      operation (see section 4) to each label.  When requirements 2 and
-      3 both apply, requirement 2 takes precedence.
-
-   4) Whenever two labels are compared, they MUST be considered to match
-      if and only if they are equivalent, that is, their ASCII forms
-      (obtained by applying ToASCII) match using a case-insensitive
-      ASCII comparison.  Whenever two names are compared, they MUST be
-      considered to match if and only if their corresponding labels
-      match, regardless of whether the names use the same forms of label
-      separators.
-
-3.2 Applicability
-
-   IDNA is applicable to all domain names in all domain name slots
-   except where it is explicitly excluded.
-
-   This implies that IDNA is applicable to many protocols that predate
-   IDNA.  Note that IDNs occupying domain name slots in those protocols
-   MUST be in ASCII form (see section 3.1, requirement 2).
-
-3.2.1. DNS resource records
-
-   IDNA does not apply to domain names in the NAME and RDATA fields of
-   DNS resource records whose CLASS is not IN.  This exclusion applies
-   to every non-IN class, present and future, except where future
-   standards override this exclusion by explicitly inviting the use of
-   IDNA.
-
-   There are currently no other exclusions on the applicability of IDNA
-   to DNS resource records; it depends entirely on the CLASS, and not on
-   the TYPE.  This will remain true, even as new types are defined,
-   unless there is a compelling reason for a new type to complicate
-   matters by imposing type-specific rules.
-
-
-
-
-
-Faltstrom, et al.           Standards Track                     [Page 8]
-
-RFC 3490                          IDNA                        March 2003
-
-
-3.2.2. Non-domain-name data types stored in domain names
-
-   Although IDNA enables the representation of non-ASCII characters in
-   domain names, that does not imply that IDNA enables the
-   representation of non-ASCII characters in other data types that are
-   stored in domain names.  For example, an email address local part is
-   sometimes stored in a domain label (hostmaster@example.com would be
-   represented as hostmaster.example.com in the RDATA field of an SOA
-   record).  IDNA does not update the existing email standards, which
-   allow only ASCII characters in local parts.  Therefore, unless the
-   email standards are revised to invite the use of IDNA for local
-   parts, a domain label that holds the local part of an email address
-   SHOULD NOT begin with the ACE prefix, and even if it does, it is to
-   be interpreted literally as a local part that happens to begin with
-   the ACE prefix.
-
-4. Conversion operations
-
-   An application converts a domain name put into an IDN-unaware slot or
-   displayed to a user.  This section specifies the steps to perform in
-   the conversion, and the ToASCII and ToUnicode operations.
-
-   The input to ToASCII or ToUnicode is a single label that is a
-   sequence of Unicode code points (remember that all ASCII code points
-   are also Unicode code points).  If a domain name is represented using
-   a character set other than Unicode or US-ASCII, it will first need to
-   be transcoded to Unicode.
-
-   Starting from a whole domain name, the steps that an application
-   takes to do the conversions are:
-
-   1) Decide whether the domain name is a "stored string" or a "query
-      string" as described in [STRINGPREP].  If this conversion follows
-      the "queries" rule from [STRINGPREP], set the flag called
-      "AllowUnassigned".
-
-   2) Split the domain name into individual labels as described in
-      section 3.1.  The labels do not include the separator.
-
-   3) For each label, decide whether or not to enforce the restrictions
-      on ASCII characters in host names [STD3].  (Applications already
-      faced this choice before the introduction of IDNA, and can
-      continue to make the decision the same way they always have; IDNA
-      makes no new recommendations regarding this choice.)  If the
-      restrictions are to be enforced, set the flag called
-      "UseSTD3ASCIIRules" for that label.
-
-
-
-
-
-Faltstrom, et al.           Standards Track                     [Page 9]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   4) Process each label with either the ToASCII or the ToUnicode
-      operation as appropriate.  Typically, you use the ToASCII
-      operation if you are about to put the name into an IDN-unaware
-      slot, and you use the ToUnicode operation if you are displaying
-      the name to a user; section 3.1 gives greater detail on the
-      applicable requirements.
-
-   5) If ToASCII was applied in step 4 and dots are used as label
-      separators, change all the label separators to U+002E (full stop).
-
-   The following two subsections define the ToASCII and ToUnicode
-   operations that are used in step 4.
-
-   This description of the protocol uses specific procedure names, names
-   of flags, and so on, in order to facilitate the specification of the
-   protocol.  These names, as well as the actual steps of the
-   procedures, are not required of an implementation.  In fact, any
-   implementation which has the same external behavior as specified in
-   this document conforms to this specification.
-
-4.1 ToASCII
-
-   The ToASCII operation takes a sequence of Unicode code points that
-   make up one label and transforms it into a sequence of code points in
-   the ASCII range (0..7F).  If ToASCII succeeds, the original sequence
-   and the resulting sequence are equivalent labels.
-
-   It is important to note that the ToASCII operation can fail.  ToASCII
-   fails if any step of it fails.  If any step of the ToASCII operation
-   fails on any label in a domain name, that domain name MUST NOT be
-   used as an internationalized domain name.  The method for dealing
-   with this failure is application-specific.
-
-   The inputs to ToASCII are a sequence of code points, the
-   AllowUnassigned flag, and the UseSTD3ASCIIRules flag.  The output of
-   ToASCII is either a sequence of ASCII code points or a failure
-   condition.
-
-   ToASCII never alters a sequence of code points that are all in the
-   ASCII range to begin with (although it could fail).  Applying the
-   ToASCII operation multiple times has exactly the same effect as
-   applying it just once.
-
-   ToASCII consists of the following steps:
-
-   1. If the sequence contains any code points outside the ASCII range
-      (0..7F) then proceed to step 2, otherwise skip to step 3.
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 10]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   2. Perform the steps specified in [NAMEPREP] and fail if there is an
-      error.  The AllowUnassigned flag is used in [NAMEPREP].
-
-   3. If the UseSTD3ASCIIRules flag is set, then perform these checks:
-
-     (a) Verify the absence of non-LDH ASCII code points; that is, the
-         absence of 0..2C, 2E..2F, 3A..40, 5B..60, and 7B..7F.
-
-     (b) Verify the absence of leading and trailing hyphen-minus; that
-         is, the absence of U+002D at the beginning and end of the
-         sequence.
-
-   4. If the sequence contains any code points outside the ASCII range
-      (0..7F) then proceed to step 5, otherwise skip to step 8.
-
-   5. Verify that the sequence does NOT begin with the ACE prefix.
-
-   6. Encode the sequence using the encoding algorithm in [PUNYCODE] and
-      fail if there is an error.
-
-   7. Prepend the ACE prefix.
-
-   8. Verify that the number of code points is in the range 1 to 63
-      inclusive.
-
-4.2 ToUnicode
-
-   The ToUnicode operation takes a sequence of Unicode code points that
-   make up one label and returns a sequence of Unicode code points.  If
-   the input sequence is a label in ACE form, then the result is an
-   equivalent internationalized label that is not in ACE form, otherwise
-   the original sequence is returned unaltered.
-
-   ToUnicode never fails.  If any step fails, then the original input
-   sequence is returned immediately in that step.
-
-   The ToUnicode output never contains more code points than its input.
-   Note that the number of octets needed to represent a sequence of code
-   points depends on the particular character encoding used.
-
-   The inputs to ToUnicode are a sequence of code points, the
-   AllowUnassigned flag, and the UseSTD3ASCIIRules flag.  The output of
-   ToUnicode is always a sequence of Unicode code points.
-
-   1. If all code points in the sequence are in the ASCII range (0..7F)
-      then skip to step 3.
-
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 11]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   2. Perform the steps specified in [NAMEPREP] and fail if there is an
-      error.  (If step 3 of ToASCII is also performed here, it will not
-      affect the overall behavior of ToUnicode, but it is not
-      necessary.)  The AllowUnassigned flag is used in [NAMEPREP].
-
-   3. Verify that the sequence begins with the ACE prefix, and save a
-      copy of the sequence.
-
-   4. Remove the ACE prefix.
-
-   5. Decode the sequence using the decoding algorithm in [PUNYCODE] and
-      fail if there is an error.  Save a copy of the result of this
-      step.
-
-   6. Apply ToASCII.
-
-   7. Verify that the result of step 6 matches the saved copy from step
-      3, using a case-insensitive ASCII comparison.
-
-   8. Return the saved copy from step 5.
-
-5. ACE prefix
-
-   The ACE prefix, used in the conversion operations (section 4), is two
-   alphanumeric ASCII characters followed by two hyphen-minuses.  It
-   cannot be any of the prefixes already used in earlier documents,
-   which includes the following: "bl--", "bq--", "dq--", "lq--", "mq--",
-   "ra--", "wq--" and "zq--".  The ToASCII and ToUnicode operations MUST
-   recognize the ACE prefix in a case-insensitive manner.
-
-   The ACE prefix for IDNA is "xn--" or any capitalization thereof.
-
-   This means that an ACE label might be "xn--de-jg4avhby1noc0d", where
-   "de-jg4avhby1noc0d" is the part of the ACE label that is generated by
-   the encoding steps in [PUNYCODE].
-
-   While all ACE labels begin with the ACE prefix, not all labels
-   beginning with the ACE prefix are necessarily ACE labels.  Non-ACE
-   labels that begin with the ACE prefix will confuse users and SHOULD
-   NOT be allowed in DNS zones.
-
-
-
-
-
-
-
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 12]
-
-RFC 3490                          IDNA                        March 2003
-
-
-6. Implications for typical applications using DNS
-
-   In IDNA, applications perform the processing needed to input
-   internationalized domain names from users, display internationalized
-   domain names to users, and process the inputs and outputs from DNS
-   and other protocols that carry domain names.
-
-   The components and interfaces between them can be represented
-   pictorially as:
-
-                    +------+
-                    | User |
-                    +------+
-                       ^
-                       | Input and display: local interface methods
-                       | (pen, keyboard, glowing phosphorus, ...)
-   +-------------------|-------------------------------+
-   |                   v                               |
-   |          +-----------------------------+          |
-   |          |        Application          |          |
-   |          |   (ToASCII and ToUnicode    |          |
-   |          |      operations may be      |          |
-   |          |        called here)         |          |
-   |          +-----------------------------+          |
-   |                   ^        ^                      | End system
-   |                   |        |                      |
-   | Call to resolver: |        | Application-specific |
-   |              ACE  |        | protocol:            |
-   |                   v        | ACE unless the       |
-   |           +----------+     | protocol is updated  |
-   |           | Resolver |     | to handle other      |
-   |           +----------+     | encodings            |
-   |                 ^          |                      |
-   +-----------------|----------|----------------------+
-       DNS protocol: |          |
-                 ACE |          |
-                     v          v
-          +-------------+    +---------------------+
-          | DNS servers |    | Application servers |
-          +-------------+    +---------------------+
-
-   The box labeled "Application" is where the application splits a
-   domain name into labels, sets the appropriate flags, and performs the
-   ToASCII and ToUnicode operations.  This is described in section 4.
-
-
-
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 13]
-
-RFC 3490                          IDNA                        March 2003
-
-
-6.1 Entry and display in applications
-
-   Applications can accept domain names using any character set or sets
-   desired by the application developer, and can display domain names in
-   any charset.  That is, the IDNA protocol does not affect the
-   interface between users and applications.
-
-   An IDNA-aware application can accept and display internationalized
-   domain names in two formats: the internationalized character set(s)
-   supported by the application, and as an ACE label.  ACE labels that
-   are displayed or input MUST always include the ACE prefix.
-   Applications MAY allow input and display of ACE labels, but are not
-   encouraged to do so except as an interface for special purposes,
-   possibly for debugging, or to cope with display limitations as
-   described in section 6.4..  ACE encoding is opaque and ugly, and
-   should thus only be exposed to users who absolutely need it.  Because
-   name labels encoded as ACE name labels can be rendered either as the
-   encoded ASCII characters or the proper decoded characters, the
-   application MAY have an option for the user to select the preferred
-   method of display; if it does, rendering the ACE SHOULD NOT be the
-   default.
-
-   Domain names are often stored and transported in many places.  For
-   example, they are part of documents such as mail messages and web
-   pages.  They are transported in many parts of many protocols, such as
-   both the control commands and the RFC 2822 body parts of SMTP, and
-   the headers and the body content in HTTP.  It is important to
-   remember that domain names appear both in domain name slots and in
-   the content that is passed over protocols.
-
-   In protocols and document formats that define how to handle
-   specification or negotiation of charsets, labels can be encoded in
-   any charset allowed by the protocol or document format.  If a
-   protocol or document format only allows one charset, the labels MUST
-   be given in that charset.
-
-   In any place where a protocol or document format allows transmission
-   of the characters in internationalized labels, internationalized
-   labels SHOULD be transmitted using whatever character encoding and
-   escape mechanism that the protocol or document format uses at that
-   place.
-
-   All protocols that use domain name slots already have the capacity
-   for handling domain names in the ASCII charset.  Thus, ACE labels
-   (internationalized labels that have been processed with the ToASCII
-   operation) can inherently be handled by those protocols.
-
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 14]
-
-RFC 3490                          IDNA                        March 2003
-
-
-6.2 Applications and resolver libraries
-
-   Applications normally use functions in the operating system when they
-   resolve DNS queries.  Those functions in the operating system are
-   often called "the resolver library", and the applications communicate
-   with the resolver libraries through a programming interface (API).
-
-   Because these resolver libraries today expect only domain names in
-   ASCII, applications MUST prepare labels that are passed to the
-   resolver library using the ToASCII operation.  Labels received from
-   the resolver library contain only ASCII characters; internationalized
-   labels that cannot be represented directly in ASCII use the ACE form.
-   ACE labels always include the ACE prefix.
-
-   An operating system might have a set of libraries for performing the
-   ToASCII operation.  The input to such a library might be in one or
-   more charsets that are used in applications (UTF-8 and UTF-16 are
-   likely candidates for almost any operating system, and script-
-   specific charsets are likely for localized operating systems).
-
-   IDNA-aware applications MUST be able to work with both non-
-   internationalized labels (those that conform to [STD13] and [STD3])
-   and internationalized labels.
-
-   It is expected that new versions of the resolver libraries in the
-   future will be able to accept domain names in other charsets than
-   ASCII, and application developers might one day pass not only domain
-   names in Unicode, but also in local script to a new API for the
-   resolver libraries in the operating system.  Thus the ToASCII and
-   ToUnicode operations might be performed inside these new versions of
-   the resolver libraries.
-
-   Domain names passed to resolvers or put into the question section of
-   DNS requests follow the rules for "queries" from [STRINGPREP].
-
-6.3 DNS servers
-
-   Domain names stored in zones follow the rules for "stored strings"
-   from [STRINGPREP].
-
-   For internationalized labels that cannot be represented directly in
-   ASCII, DNS servers MUST use the ACE form produced by the ToASCII
-   operation.  All IDNs served by DNS servers MUST contain only ASCII
-   characters.
-
-   If a signaling system which makes negotiation possible between old
-   and new DNS clients and servers is standardized in the future, the
-   encoding of the query in the DNS protocol itself can be changed from
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 15]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   ACE to something else, such as UTF-8.  The question whether or not
-   this should be used is, however, a separate problem and is not
-   discussed in this memo.
-
-6.4 Avoiding exposing users to the raw ACE encoding
-
-   Any application that might show the user a domain name obtained from
-   a domain name slot, such as from gethostbyaddr or part of a mail
-   header, will need to be updated if it is to prevent users from seeing
-   the ACE.
-
-   If an application decodes an ACE name using ToUnicode but cannot show
-   all of the characters in the decoded name, such as if the name
-   contains characters that the output system cannot display, the
-   application SHOULD show the name in ACE format (which always includes
-   the ACE prefix) instead of displaying the name with the replacement
-   character (U+FFFD).  This is to make it easier for the user to
-   transfer the name correctly to other programs.  Programs that by
-   default show the ACE form when they cannot show all the characters in
-   a name label SHOULD also have a mechanism to show the name that is
-   produced by the ToUnicode operation with as many characters as
-   possible and replacement characters in the positions where characters
-   cannot be displayed.
-
-   The ToUnicode operation does not alter labels that are not valid ACE
-   labels, even if they begin with the ACE prefix.  After ToUnicode has
-   been applied, if a label still begins with the ACE prefix, then it is
-   not a valid ACE label, and is not equivalent to any of the
-   intermediate Unicode strings constructed by ToUnicode.
-
-6.5  DNSSEC authentication of IDN domain names
-
-   DNS Security [RFC2535] is a method for supplying cryptographic
-   verification information along with DNS messages.  Public Key
-   Cryptography is used in conjunction with digital signatures to
-   provide a means for a requester of domain information to authenticate
-   the source of the data.  This ensures that it can be traced back to a
-   trusted source, either directly, or via a chain of trust linking the
-   source of the information to the top of the DNS hierarchy.
-
-   IDNA specifies that all internationalized domain names served by DNS
-   servers that cannot be represented directly in ASCII must use the ACE
-   form produced by the ToASCII operation.  This operation must be
-   performed prior to a zone being signed by the private key for that
-   zone.  Because of this ordering, it is important to recognize that
-   DNSSEC authenticates the ASCII domain name, not the Unicode form or
-
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 16]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   the mapping between the Unicode form and the ASCII form.  In the
-   presence of DNSSEC, this is the name that MUST be signed in the zone
-   and MUST be validated against.
-
-   One consequence of this for sites deploying IDNA in the presence of
-   DNSSEC is that any special purpose proxies or forwarders used to
-   transform user input into IDNs must be earlier in the resolution flow
-   than DNSSEC authenticating nameservers for DNSSEC to work.
-
-7. Name server considerations
-
-   Existing DNS servers do not know the IDNA rules for handling non-
-   ASCII forms of IDNs, and therefore need to be shielded from them.
-   All existing channels through which names can enter a DNS server
-   database (for example, master files [STD13] and DNS update messages
-   [RFC2136]) are IDN-unaware because they predate IDNA, and therefore
-   requirement 2 of section 3.1 of this document provides the needed
-   shielding, by ensuring that internationalized domain names entering
-   DNS server databases through such channels have already been
-   converted to their equivalent ASCII forms.
-
-   It is imperative that there be only one ASCII encoding for a
-   particular domain name.  Because of the design of the ToASCII and
-   ToUnicode operations, there are no ACE labels that decode to ASCII
-   labels, and therefore name servers cannot contain multiple ASCII
-   encodings of the same domain name.
-
-   [RFC2181] explicitly allows domain labels to contain octets beyond
-   the ASCII range (0..7F), and this document does not change that.
-   Note, however, that there is no defined interpretation of octets
-   80..FF as characters.  If labels containing these octets are returned
-   to applications, unpredictable behavior could result.  The ASCII form
-   defined by ToASCII is the only standard representation for
-   internationalized labels in the current DNS protocol.
-
-8. Root server considerations
-
-   IDNs are likely to be somewhat longer than current domain names, so
-   the bandwidth needed by the root servers is likely to go up by a
-   small amount.  Also, queries and responses for IDNs will probably be
-   somewhat longer than typical queries today, so more queries and
-   responses may be forced to go to TCP instead of UDP.
-
-
-
-
-
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 17]
-
-RFC 3490                          IDNA                        March 2003
-
-
-9. References
-
-9.1 Normative References
-
-   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
-                Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of
-                Internationalized Strings ("stringprep")", RFC 3454,
-                December 2002.
-
-   [NAMEPREP]   Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
-                Profile for Internationalized Domain Names (IDN)", RFC
-                3491, March 2003.
-
-   [PUNYCODE]   Costello, A., "Punycode: A Bootstring encoding of
-                Unicode for use with Internationalized Domain Names in
-                Applications (IDNA)", RFC 3492, March 2003.
-
-   [STD3]       Braden, R., "Requirements for Internet Hosts --
-                Communication Layers", STD 3, RFC 1122, and
-                "Requirements for Internet Hosts -- Application and
-                Support", STD 3, RFC 1123, October 1989.
-
-   [STD13]      Mockapetris, P., "Domain names - concepts and
-                facilities", STD 13, RFC 1034 and "Domain names -
-                implementation and specification", STD 13, RFC 1035,
-                November 1987.
-
-9.2 Informative References
-
-   [RFC2535]    Eastlake, D., "Domain Name System Security Extensions",
-                RFC 2535, March 1999.
-
-   [RFC2181]    Elz, R. and R. Bush, "Clarifications to the DNS
-                Specification", RFC 2181, July 1997.
-
-   [UAX9]       Unicode Standard Annex #9, The Bidirectional Algorithm,
-                <http://www.unicode.org/unicode/reports/tr9/>.
-
-   [UNICODE]    The Unicode Consortium. The Unicode Standard, Version
-                3.2.0 is defined by The Unicode Standard, Version 3.0
-                (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
-                as amended by the Unicode Standard Annex #27: Unicode
-                3.1 (http://www.unicode.org/reports/tr27/) and by the
-                Unicode Standard Annex #28: Unicode 3.2
-                (http://www.unicode.org/reports/tr28/).
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 18]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   [USASCII]    Cerf, V., "ASCII format for Network Interchange", RFC
-                20, October 1969.
-
-10. Security Considerations
-
-   Security on the Internet partly relies on the DNS.  Thus, any change
-   to the characteristics of the DNS can change the security of much of
-   the Internet.
-
-   This memo describes an algorithm which encodes characters that are
-   not valid according to STD3 and STD13 into octet values that are
-   valid.  No security issues such as string length increases or new
-   allowed values are introduced by the encoding process or the use of
-   these encoded values, apart from those introduced by the ACE encoding
-   itself.
-
-   Domain names are used by users to identify and connect to Internet
-   servers.  The security of the Internet is compromised if a user
-   entering a single internationalized name is connected to different
-   servers based on different interpretations of the internationalized
-   domain name.
-
-   When systems use local character sets other than ASCII and Unicode,
-   this specification leaves the the problem of transcoding between the
-   local character set and Unicode up to the application.  If different
-   applications (or different versions of one application) implement
-   different transcoding rules, they could interpret the same name
-   differently and contact different servers.  This problem is not
-   solved by security protocols like TLS that do not take local
-   character sets into account.
-
-   Because this document normatively refers to [NAMEPREP], [PUNYCODE],
-   and [STRINGPREP], it includes the security considerations from those
-   documents as well.
-
-   If or when this specification is updated to use a more recent Unicode
-   normalization table, the new normalization table will need to be
-   compared with the old to spot backwards incompatible changes.  If
-   there are such changes, they will need to be handled somehow, or
-   there will be security as well as operational implications.  Methods
-   to handle the conflicts could include keeping the old normalization,
-   or taking care of the conflicting characters by operational means, or
-   some other method.
-
-   Implementations MUST NOT use more recent normalization tables than
-   the one referenced from this document, even though more recent tables
-   may be provided by operating systems.  If an application is unsure of
-   which version of the normalization tables are in the operating
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 19]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   system, the application needs to include the normalization tables
-   itself.  Using normalization tables other than the one referenced
-   from this specification could have security and operational
-   implications.
-
-   To help prevent confusion between characters that are visually
-   similar, it is suggested that implementations provide visual
-   indications where a domain name contains multiple scripts.  Such
-   mechanisms can also be used to show when a name contains a mixture of
-   simplified and traditional Chinese characters, or to distinguish zero
-   and one from O and l.  DNS zone adminstrators may impose restrictions
-   (subject to the limitations in section 2) that try to minimize
-   homographs.
-
-   Domain names (or portions of them) are sometimes compared against a
-   set of privileged or anti-privileged domains.  In such situations it
-   is especially important that the comparisons be done properly, as
-   specified in section 3.1 requirement 4.  For labels already in ASCII
-   form, the proper comparison reduces to the same case-insensitive
-   ASCII comparison that has always been used for ASCII labels.
-
-   The introduction of IDNA means that any existing labels that start
-   with the ACE prefix and would be altered by ToUnicode will
-   automatically be ACE labels, and will be considered equivalent to
-   non-ASCII labels, whether or not that was the intent of the zone
-   adminstrator or registrant.
-
-11. IANA Considerations
-
-   IANA has assigned the ACE prefix in consultation with the IESG.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 20]
-
-RFC 3490                          IDNA                        March 2003
-
-
-12. Authors' Addresses
-
-   Patrik Faltstrom
-   Cisco Systems
-   Arstaangsvagen 31 J
-   S-117 43 Stockholm  Sweden
-
-   EMail: paf@cisco.com
-
-
-   Paul Hoffman
-   Internet Mail Consortium and VPN Consortium
-   127 Segre Place
-   Santa Cruz, CA  95060  USA
-
-   EMail: phoffman@imc.org
-
-
-   Adam M. Costello
-   University of California, Berkeley
-
-   URL: http://www.nicemice.net/amc/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 21]
-
-RFC 3490                          IDNA                        March 2003
-
-
-13. Full Copyright Statement
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 22]
-
diff --git a/contrib/bind9/doc/rfc/rfc3491.txt b/contrib/bind9/doc/rfc/rfc3491.txt
deleted file mode 100644
index dbc86c7..0000000
--- a/contrib/bind9/doc/rfc/rfc3491.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         P. Hoffman
-Request for Comments: 3491                                    IMC & VPNC
-Category: Standards Track                                    M. Blanchet
-                                                                Viagenie
-                                                              March 2003
-
-
-                   Nameprep: A Stringprep Profile for
-                  Internationalized Domain Names (IDN)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-Abstract
-
-   This document describes how to prepare internationalized domain name
-   (IDN) labels in order to increase the likelihood that name input and
-   name comparison work in ways that make sense for typical users
-   throughout the world.  This profile of the stringprep protocol is
-   used as part of a suite of on-the-wire protocols for
-   internationalizing the Domain Name System (DNS).
-
-1. Introduction
-
-   This document specifies processing rules that will allow users to
-   enter internationalized domain names (IDNs) into applications and
-   have the highest chance of getting the content of the strings
-   correct.  It is a profile of stringprep [STRINGPREP].  These
-   processing rules are only intended for internationalized domain
-   names, not for arbitrary text.
-
-   This profile defines the following, as required by [STRINGPREP].
-
-   -  The intended applicability of the profile: internationalized
-      domain names processed by IDNA.
-
-   -  The character repertoire that is the input and output to
-      stringprep:  Unicode 3.2, specified in section 2.
-
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 1]
-
-RFC 3491                      IDN Nameprep                    March 2003
-
-
-   -  The mappings used: specified in section 3.
-
-   -  The Unicode normalization used: specified in section 4.
-
-   -  The characters that are prohibited as output: specified in section
-      5.
-
-   -  Bidirectional character handling: specified in section 6.
-
-1.1 Interaction of protocol parts
-
-   Nameprep is used by the IDNA [IDNA] protocol for preparing domain
-   names; it is not designed for any other purpose.  It is explicitly
-   not designed for processing arbitrary free text and SHOULD NOT be
-   used for that purpose.  Nameprep is a profile of Stringprep
-   [STRINGPREP].  Implementations of Nameprep MUST fully implement
-   Stringprep.
-
-   Nameprep is used to process domain name labels, not domain names.
-   IDNA calls nameprep for each label in a domain name, not for the
-   whole domain name.
-
-1.2 Terminology
-
-   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
-   in this document are to be interpreted as described in BCP 14, RFC
-   2119 [RFC2119].
-
-2. Character Repertoire
-
-   This profile uses Unicode 3.2, as defined in [STRINGPREP] Appendix A.
-
-3. Mapping
-
-   This profile specifies mapping using the following tables from
-   [STRINGPREP]:
-
-   Table B.1
-   Table B.2
-
-4. Normalization
-
-   This profile specifies using Unicode normalization form KC, as
-   described in [STRINGPREP].
-
-
-
-
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 2]
-
-RFC 3491                      IDN Nameprep                    March 2003
-
-
-5. Prohibited Output
-
-   This profile specifies prohibiting using the following tables from
-   [STRINGPREP]:
-
-   Table C.1.2
-   Table C.2.2
-   Table C.3
-   Table C.4
-   Table C.5
-   Table C.6
-   Table C.7
-   Table C.8
-   Table C.9
-
-   IMPORTANT NOTE: This profile MUST be used with the IDNA protocol.
-   The IDNA protocol has additional prohibitions that are checked
-   outside of this profile.
-
-6. Bidirectional characters
-
-   This profile specifies checking bidirectional strings as described in
-   [STRINGPREP] section 6.
-
-7. Unassigned Code Points in Internationalized Domain Names
-
-   If the processing in [IDNA] specifies that a list of unassigned code
-   points be used, the system uses table A.1 from [STRINGPREP] as its
-   list of unassigned code points.
-
-8. References
-
-8.1 Normative References
-
-   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
-                Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of
-                Internationalized Strings ("stringprep")", RFC 3454,
-                December 2002.
-
-   [IDNA]       Faltstrom, P., Hoffman, P. and A. Costello,
-                "Internationalizing Domain Names in Applications
-                (IDNA)", RFC 3490, March 2003.
-
-
-
-
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 3]
-
-RFC 3491                      IDN Nameprep                    March 2003
-
-
-8.2 Informative references
-
-   [STD13]      Mockapetris, P., "Domain names - concepts and
-                facilities", STD 13, RFC 1034, and "Domain names -
-                implementation and specification", STD 13, RFC 1035,
-                November 1987.
-
-9. Security Considerations
-
-   The Unicode and ISO/IEC 10646 repertoires have many characters that
-   look similar.  In many cases, users of security protocols might do
-   visual matching, such as when comparing the names of trusted third
-   parties.  Because it is impossible to map similar-looking characters
-   without a great deal of context such as knowing the fonts used,
-   stringprep does nothing to map similar-looking characters together
-   nor to prohibit some characters because they look like others.
-
-   Security on the Internet partly relies on the DNS.  Thus, any change
-   to the characteristics of the DNS can change the security of much of
-   the Internet.
-
-   Domain names are used by users to connect to Internet servers.  The
-   security of the Internet would be compromised if a user entering a
-   single internationalized name could be connected to different servers
-   based on different interpretations of the internationalized domain
-   name.
-
-   Current applications might assume that the characters allowed in
-   domain names will always be the same as they are in [STD13].  This
-   document vastly increases the number of characters available in
-   domain names.  Every program that uses "special" characters in
-   conjunction with domain names may be vulnerable to attack based on
-   the new characters allowed by this specification.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 4]
-
-RFC 3491                      IDN Nameprep                    March 2003
-
-
-10. IANA Considerations
-
-   This is a profile of stringprep.  It has been registered by the IANA
-   in the stringprep profile registry
-   (www.iana.org/assignments/stringprep-profiles).
-
-      Name of this profile:
-         Nameprep
-
-      RFC in which the profile is defined:
-         This document.
-
-      Indicator whether or not this is the newest version of the
-      profile:
-         This is the first version of Nameprep.
-
-11. Acknowledgements
-
-   Many people from the IETF IDN Working Group and the Unicode Technical
-   Committee contributed ideas that went into this document.
-
-   The IDN Nameprep design team made many useful changes to the
-   document.  That team and its advisors include:
-
-      Asmus Freytag
-      Cathy Wissink
-      Francois Yergeau
-      James Seng
-      Marc Blanchet
-      Mark Davis
-      Martin Duerst
-      Patrik Faltstrom
-      Paul Hoffman
-
-   Additional significant improvements were proposed by:
-
-      Jonathan Rosenne
-      Kent Karlsson
-      Scott Hollenbeck
-      Dave Crocker
-      Erik Nordmark
-      Matitiahu Allouche
-
-
-
-
-
-
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 5]
-
-RFC 3491                      IDN Nameprep                    March 2003
-
-
-12. Authors' Addresses
-
-   Paul Hoffman
-   Internet Mail Consortium and VPN Consortium
-   127 Segre Place
-   Santa Cruz, CA  95060 USA
-
-   EMail: paul.hoffman@imc.org and paul.hoffman@vpnc.org
-
-
-   Marc Blanchet
-   Viagenie inc.
-   2875 boul. Laurier, bur. 300
-   Ste-Foy, Quebec, Canada, G1V 2M2
-
-   EMail: Marc.Blanchet@viagenie.qc.ca
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 6]
-
-RFC 3491                      IDN Nameprep                    March 2003
-
-
-13.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 7]
-
diff --git a/contrib/bind9/doc/rfc/rfc3492.txt b/contrib/bind9/doc/rfc/rfc3492.txt
deleted file mode 100644
index e72ad81..0000000
--- a/contrib/bind9/doc/rfc/rfc3492.txt
+++ /dev/null
@@ -1,1963 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        A. Costello
-Request for Comments: 3492                 Univ. of California, Berkeley
-Category: Standards Track                                     March 2003
-
-
-              Punycode: A Bootstring encoding of Unicode
-       for Internationalized Domain Names in Applications (IDNA)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-Abstract
-
-   Punycode is a simple and efficient transfer encoding syntax designed
-   for use with Internationalized Domain Names in Applications (IDNA).
-   It uniquely and reversibly transforms a Unicode string into an ASCII
-   string.  ASCII characters in the Unicode string are represented
-   literally, and non-ASCII characters are represented by ASCII
-   characters that are allowed in host name labels (letters, digits, and
-   hyphens).  This document defines a general algorithm called
-   Bootstring that allows a string of basic code points to uniquely
-   represent any string of code points drawn from a larger set.
-   Punycode is an instance of Bootstring that uses particular parameter
-   values specified by this document, appropriate for IDNA.
-
-Table of Contents
-
-   1. Introduction...............................................2
-       1.1 Features..............................................2
-       1.2 Interaction of protocol parts.........................3
-   2. Terminology................................................3
-   3. Bootstring description.....................................4
-       3.1 Basic code point segregation..........................4
-       3.2 Insertion unsort coding...............................4
-       3.3 Generalized variable-length integers..................5
-       3.4 Bias adaptation.......................................7
-   4. Bootstring parameters......................................8
-   5. Parameter values for Punycode..............................8
-   6. Bootstring algorithms......................................9
-
-
-
-Costello                    Standards Track                     [Page 1]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-       6.1 Bias adaptation function.............................10
-       6.2 Decoding procedure...................................11
-       6.3 Encoding procedure...................................12
-       6.4 Overflow handling....................................13
-   7. Punycode examples.........................................14
-       7.1 Sample strings.......................................14
-       7.2 Decoding traces......................................17
-       7.3 Encoding traces......................................19
-   8. Security Considerations...................................20
-   9. References................................................21
-       9.1 Normative References.................................21
-       9.2 Informative References...............................21
-   A. Mixed-case annotation.....................................22
-   B. Disclaimer and license....................................22
-   C. Punycode sample implementation............................23
-   Author's Address.............................................34
-   Full Copyright Statement.....................................35
-
-1. Introduction
-
-   [IDNA] describes an architecture for supporting internationalized
-   domain names.  Labels containing non-ASCII characters can be
-   represented by ACE labels, which begin with a special ACE prefix and
-   contain only ASCII characters.  The remainder of the label after the
-   prefix is a Punycode encoding of a Unicode string satisfying certain
-   constraints.  For the details of the prefix and constraints, see
-   [IDNA] and [NAMEPREP].
-
-   Punycode is an instance of a more general algorithm called
-   Bootstring, which allows strings composed from a small set of "basic"
-   code points to uniquely represent any string of code points drawn
-   from a larger set.  Punycode is Bootstring with particular parameter
-   values appropriate for IDNA.
-
-1.1 Features
-
-   Bootstring has been designed to have the following features:
-
-   *  Completeness:  Every extended string (sequence of arbitrary code
-      points) can be represented by a basic string (sequence of basic
-      code points).  Restrictions on what strings are allowed, and on
-      length, can be imposed by higher layers.
-
-   *  Uniqueness:  There is at most one basic string that represents a
-      given extended string.
-
-   *  Reversibility:  Any extended string mapped to a basic string can
-      be recovered from that basic string.
-
-
-
-Costello                    Standards Track                     [Page 2]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   *  Efficient encoding:  The ratio of basic string length to extended
-      string length is small.  This is important in the context of
-      domain names because RFC 1034 [RFC1034] restricts the length of a
-      domain label to 63 characters.
-
-   *  Simplicity:  The encoding and decoding algorithms are reasonably
-      simple to implement.  The goals of efficiency and simplicity are
-      at odds; Bootstring aims at a good balance between them.
-
-   *  Readability:  Basic code points appearing in the extended string
-      are represented as themselves in the basic string (although the
-      main purpose is to improve efficiency, not readability).
-
-   Punycode can also support an additional feature that is not used by
-   the ToASCII and ToUnicode operations of [IDNA].  When extended
-   strings are case-folded prior to encoding, the basic string can use
-   mixed case to tell how to convert the folded string into a mixed-case
-   string.  See appendix A "Mixed-case annotation".
-
-1.2 Interaction of protocol parts
-
-   Punycode is used by the IDNA protocol [IDNA] for converting domain
-   labels into ASCII; it is not designed for any other purpose.  It is
-   explicitly not designed for processing arbitrary free text.
-
-2. Terminology
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in BCP 14, RFC 2119
-   [RFC2119].
-
-   A code point is an integral value associated with a character in a
-   coded character set.
-
-   As in the Unicode Standard [UNICODE], Unicode code points are denoted
-   by "U+" followed by four to six hexadecimal digits, while a range of
-   code points is denoted by two hexadecimal numbers separated by "..",
-   with no prefixes.
-
-   The operators div and mod perform integer division; (x div y) is the
-   quotient of x divided by y, discarding the remainder, and (x mod y)
-   is the remainder, so (x div y) * y + (x mod y) == x.  Bootstring uses
-   these operators only with nonnegative operands, so the quotient and
-   remainder are always nonnegative.
-
-   The break statement jumps out of the innermost loop (as in C).
-
-
-
-
-Costello                    Standards Track                     [Page 3]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   An overflow is an attempt to compute a value that exceeds the maximum
-   value of an integer variable.
-
-3. Bootstring description
-
-   Bootstring represents an arbitrary sequence of code points (the
-   "extended string") as a sequence of basic code points (the "basic
-   string").  This section describes the representation.  Section 6
-   "Bootstring algorithms" presents the algorithms as pseudocode.
-   Sections 7.1 "Decoding traces" and 7.2 "Encoding traces" trace the
-   algorithms for sample inputs.
-
-   The following sections describe the four techniques used in
-   Bootstring.  "Basic code point segregation" is a very simple and
-   efficient encoding for basic code points occurring in the extended
-   string: they are simply copied all at once.  "Insertion unsort
-   coding" encodes the non-basic code points as deltas, and processes
-   the code points in numerical order rather than in order of
-   appearance, which typically results in smaller deltas.  The deltas
-   are represented as "generalized variable-length integers", which use
-   basic code points to represent nonnegative integers.  The parameters
-   of this integer representation are dynamically adjusted using "bias
-   adaptation", to improve efficiency when consecutive deltas have
-   similar magnitudes.
-
-3.1 Basic code point segregation
-
-   All basic code points appearing in the extended string are
-   represented literally at the beginning of the basic string, in their
-   original order, followed by a delimiter if (and only if) the number
-   of basic code points is nonzero.  The delimiter is a particular basic
-   code point, which never appears in the remainder of the basic string.
-   The decoder can therefore find the end of the literal portion (if
-   there is one) by scanning for the last delimiter.
-
-3.2 Insertion unsort coding
-
-   The remainder of the basic string (after the last delimiter if there
-   is one) represents a sequence of nonnegative integral deltas as
-   generalized variable-length integers, described in section 3.3.  The
-   meaning of the deltas is best understood in terms of the decoder.
-
-   The decoder builds the extended string incrementally.  Initially, the
-   extended string is a copy of the literal portion of the basic string
-   (excluding the last delimiter).  The decoder inserts non-basic code
-   points, one for each delta, into the extended string, ultimately
-   arriving at the final decoded string.
-
-
-
-
-Costello                    Standards Track                     [Page 4]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   At the heart of this process is a state machine with two state
-   variables: an index i and a counter n.  The index i refers to a
-   position in the extended string; it ranges from 0 (the first
-   position) to the current length of the extended string (which refers
-   to a potential position beyond the current end).  If the current
-   state is <n,i>, the next state is <n,i+1> if i is less than the
-   length of the extended string, or <n+1,0> if i equals the length of
-   the extended string.  In other words, each state change causes i to
-   increment, wrapping around to zero if necessary, and n counts the
-   number of wrap-arounds.
-
-   Notice that the state always advances monotonically (there is no way
-   for the decoder to return to an earlier state).  At each state, an
-   insertion is either performed or not performed.  At most one
-   insertion is performed in a given state.  An insertion inserts the
-   value of n at position i in the extended string.  The deltas are a
-   run-length encoding of this sequence of events: they are the lengths
-   of the runs of non-insertion states preceeding the insertion states.
-   Hence, for each delta, the decoder performs delta state changes, then
-   an insertion, and then one more state change.  (An implementation
-   need not perform each state change individually, but can instead use
-   division and remainder calculations to compute the next insertion
-   state directly.)  It is an error if the inserted code point is a
-   basic code point (because basic code points were supposed to be
-   segregated as described in section 3.1).
-
-   The encoder's main task is to derive the sequence of deltas that will
-   cause the decoder to construct the desired string.  It can do this by
-   repeatedly scanning the extended string for the next code point that
-   the decoder would need to insert, and counting the number of state
-   changes the decoder would need to perform, mindful of the fact that
-   the decoder's extended string will include only those code points
-   that have already been inserted.  Section 6.3 "Encoding procedure"
-   gives a precise algorithm.
-
-3.3 Generalized variable-length integers
-
-   In a conventional integer representation the base is the number of
-   distinct symbols for digits, whose values are 0 through base-1.  Let
-   digit_0 denote the least significant digit, digit_1 the next least
-   significant, and so on.  The value represented is the sum over j of
-   digit_j * w(j), where w(j) = base^j is the weight (scale factor) for
-   position j.  For example, in the base 8 integer 437, the digits are
-   7, 3, and 4, and the weights are 1, 8, and 64, so the value is 7 +
-   3*8 + 4*64 = 287.  This representation has two disadvantages:  First,
-   there are multiple encodings of each value (because there can be
-   extra zeros in the most significant positions), which is inconvenient
-
-
-
-
-Costello                    Standards Track                     [Page 5]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   when unique encodings are needed.  Second, the integer is not self-
-   delimiting, so if multiple integers are concatenated the boundaries
-   between them are lost.
-
-   The generalized variable-length representation solves these two
-   problems.  The digit values are still 0 through base-1, but now the
-   integer is self-delimiting by means of thresholds t(j), each of which
-   is in the range 0 through base-1.  Exactly one digit, the most
-   significant, satisfies digit_j < t(j).  Therefore, if several
-   integers are concatenated, it is easy to separate them, starting with
-   the first if they are little-endian (least significant digit first),
-   or starting with the last if they are big-endian (most significant
-   digit first).  As before, the value is the sum over j of digit_j *
-   w(j), but the weights are different:
-
-      w(0) = 1
-      w(j) = w(j-1) * (base - t(j-1)) for j > 0
-
-   For example, consider the little-endian sequence of base 8 digits
-   734251...  Suppose the thresholds are 2, 3, 5, 5, 5, 5...  This
-   implies that the weights are 1, 1*(8-2) = 6, 6*(8-3) = 30, 30*(8-5) =
-   90, 90*(8-5) = 270, and so on.  7 is not less than 2, and 3 is not
-   less than 3, but 4 is less than 5, so 4 is the last digit.  The value
-   of 734 is 7*1 + 3*6 + 4*30 = 145.  The next integer is 251, with
-   value 2*1 + 5*6 + 1*30 = 62.  Decoding this representation is very
-   similar to decoding a conventional integer:  Start with a current
-   value of N = 0 and a weight w = 1.  Fetch the next digit d and
-   increase N by d * w.  If d is less than the current threshold (t)
-   then stop, otherwise increase w by a factor of (base - t), update t
-   for the next position, and repeat.
-
-   Encoding this representation is similar to encoding a conventional
-   integer:  If N < t then output one digit for N and stop, otherwise
-   output the digit for t + ((N - t) mod (base - t)), then replace N
-   with (N - t) div (base - t), update t for the next position, and
-   repeat.
-
-   For any particular set of values of t(j), there is exactly one
-   generalized variable-length representation of each nonnegative
-   integral value.
-
-   Bootstring uses little-endian ordering so that the deltas can be
-   separated starting with the first.  The t(j) values are defined in
-   terms of the constants base, tmin, and tmax, and a state variable
-   called bias:
-
-      t(j) = base * (j + 1) - bias,
-      clamped to the range tmin through tmax
-
-
-
-Costello                    Standards Track                     [Page 6]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   The clamping means that if the formula yields a value less than tmin
-   or greater than tmax, then t(j) = tmin or tmax, respectively.  (In
-   the pseudocode in section 6 "Bootstring algorithms", the expression
-   base * (j + 1) is denoted by k for performance reasons.)  These t(j)
-   values cause the representation to favor integers within a particular
-   range determined by the bias.
-
-3.4 Bias adaptation
-
-   After each delta is encoded or decoded, bias is set for the next
-   delta as follows:
-
-   1. Delta is scaled in order to avoid overflow in the next step:
-
-         let delta = delta div 2
-
-      But when this is the very first delta, the divisor is not 2, but
-      instead a constant called damp.  This compensates for the fact
-      that the second delta is usually much smaller than the first.
-
-   2. Delta is increased to compensate for the fact that the next delta
-      will be inserting into a longer string:
-
-         let delta = delta + (delta div numpoints)
-
-      numpoints is the total number of code points encoded/decoded so
-      far (including the one corresponding to this delta itself, and
-      including the basic code points).
-
-   3. Delta is repeatedly divided until it falls within a threshold, to
-      predict the minimum number of digits needed to represent the next
-      delta:
-
-         while delta > ((base - tmin) * tmax) div 2
-         do let delta = delta div (base - tmin)
-
-   4. The bias is set:
-
-         let bias =
-           (base * the number of divisions performed in step 3) +
-           (((base - tmin + 1) * delta) div (delta + skew))
-
-      The motivation for this procedure is that the current delta
-      provides a hint about the likely size of the next delta, and so
-      t(j) is set to tmax for the more significant digits starting with
-      the one expected to be last, tmin for the less significant digits
-      up through the one expected to be third-last, and somewhere
-      between tmin and tmax for the digit expected to be second-last
-
-
-
-Costello                    Standards Track                     [Page 7]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-      (balancing the hope of the expected-last digit being unnecessary
-      against the danger of it being insufficient).
-
-4. Bootstring parameters
-
-   Given a set of basic code points, one needs to be designated as the
-   delimiter.  The base cannot be greater than the number of
-   distinguishable basic code points remaining.  The digit-values in the
-   range 0 through base-1 need to be associated with distinct non-
-   delimiter basic code points.  In some cases multiple code points need
-   to have the same digit-value; for example, uppercase and lowercase
-   versions of the same letter need to be equivalent if basic strings
-   are case-insensitive.
-
-   The initial value of n cannot be greater than the minimum non-basic
-   code point that could appear in extended strings.
-
-   The remaining five parameters (tmin, tmax, skew, damp, and the
-   initial value of bias) need to satisfy the following constraints:
-
-      0 <= tmin <= tmax <= base-1
-      skew >= 1
-      damp >= 2
-      initial_bias mod base <= base - tmin
-
-   Provided the constraints are satisfied, these five parameters affect
-   efficiency but not correctness.  They are best chosen empirically.
-
-   If support for mixed-case annotation is desired (see appendix A),
-   make sure that the code points corresponding to 0 through tmax-1 all
-   have both uppercase and lowercase forms.
-
-5. Parameter values for Punycode
-
-   Punycode uses the following Bootstring parameter values:
-
-      base         = 36
-      tmin         = 1
-      tmax         = 26
-      skew         = 38
-      damp         = 700
-      initial_bias = 72
-      initial_n    = 128 = 0x80
-
-   Although the only restriction Punycode imposes on the input integers
-   is that they be nonnegative, these parameters are especially designed
-   to work well with Unicode [UNICODE] code points, which are integers
-   in the range 0..10FFFF (but not D800..DFFF, which are reserved for
-
-
-
-Costello                    Standards Track                     [Page 8]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   use by the UTF-16 encoding of Unicode).  The basic code points are
-   the ASCII [ASCII] code points (0..7F), of which U+002D (-) is the
-   delimiter, and some of the others have digit-values as follows:
-
-      code points    digit-values
-      ------------   ----------------------
-      41..5A (A-Z) =  0 to 25, respectively
-      61..7A (a-z) =  0 to 25, respectively
-      30..39 (0-9) = 26 to 35, respectively
-
-   Using hyphen-minus as the delimiter implies that the encoded string
-   can end with a hyphen-minus only if the Unicode string consists
-   entirely of basic code points, but IDNA forbids such strings from
-   being encoded.  The encoded string can begin with a hyphen-minus, but
-   IDNA prepends a prefix.  Therefore IDNA using Punycode conforms to
-   the RFC 952 rule that host name labels neither begin nor end with a
-   hyphen-minus [RFC952].
-
-   A decoder MUST recognize the letters in both uppercase and lowercase
-   forms (including mixtures of both forms).  An encoder SHOULD output
-   only uppercase forms or only lowercase forms, unless it uses mixed-
-   case annotation (see appendix A).
-
-   Presumably most users will not manually write or type encoded strings
-   (as opposed to cutting and pasting them), but those who do will need
-   to be alert to the potential visual ambiguity between the following
-   sets of characters:
-
-      G 6
-      I l 1
-      O 0
-      S 5
-      U V
-      Z 2
-
-   Such ambiguities are usually resolved by context, but in a Punycode
-   encoded string there is no context apparent to humans.
-
-6. Bootstring algorithms
-
-   Some parts of the pseudocode can be omitted if the parameters satisfy
-   certain conditions (for which Punycode qualifies).  These parts are
-   enclosed in {braces}, and notes immediately following the pseudocode
-   explain the conditions under which they can be omitted.
-
-
-
-
-
-
-
-Costello                    Standards Track                     [Page 9]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   Formally, code points are integers, and hence the pseudocode assumes
-   that arithmetic operations can be performed directly on code points.
-   In some programming languages, explicit conversion between code
-   points and integers might be necessary.
-
-6.1 Bias adaptation function
-
-   function adapt(delta,numpoints,firsttime):
-     if firsttime then let delta = delta div damp
-     else let delta = delta div 2
-     let delta = delta + (delta div numpoints)
-     let k = 0
-     while delta > ((base - tmin) * tmax) div 2 do begin
-       let delta = delta div (base - tmin)
-       let k = k + base
-     end
-     return k + (((base - tmin + 1) * delta) div (delta + skew))
-
-   It does not matter whether the modifications to delta and k inside
-   adapt() affect variables of the same name inside the
-   encoding/decoding procedures, because after calling adapt() the
-   caller does not read those variables before overwriting them.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Costello                    Standards Track                    [Page 10]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-6.2 Decoding procedure
-
-   let n = initial_n
-   let i = 0
-   let bias = initial_bias
-   let output = an empty string indexed from 0
-   consume all code points before the last delimiter (if there is one)
-     and copy them to output, fail on any non-basic code point
-   if more than zero code points were consumed then consume one more
-     (which will be the last delimiter)
-   while the input is not exhausted do begin
-     let oldi = i
-     let w = 1
-     for k = base to infinity in steps of base do begin
-       consume a code point, or fail if there was none to consume
-       let digit = the code point's digit-value, fail if it has none
-       let i = i + digit * w, fail on overflow
-       let t = tmin if k <= bias {+ tmin}, or
-               tmax if k >= bias + tmax, or k - bias otherwise
-       if digit < t then break
-       let w = w * (base - t), fail on overflow
-     end
-     let bias = adapt(i - oldi, length(output) + 1, test oldi is 0?)
-     let n = n + i div (length(output) + 1), fail on overflow
-     let i = i mod (length(output) + 1)
-     {if n is a basic code point then fail}
-     insert n into output at position i
-     increment i
-   end
-
-   The full statement enclosed in braces (checking whether n is a basic
-   code point) can be omitted if initial_n exceeds all basic code points
-   (which is true for Punycode), because n is never less than initial_n.
-
-   In the assignment of t, where t is clamped to the range tmin through
-   tmax, "+ tmin" can always be omitted.  This makes the clamping
-   calculation incorrect when bias < k < bias + tmin, but that cannot
-   happen because of the way bias is computed and because of the
-   constraints on the parameters.
-
-   Because the decoder state can only advance monotonically, and there
-   is only one representation of any delta, there is therefore only one
-   encoded string that can represent a given sequence of integers.  The
-   only error conditions are invalid code points, unexpected end-of-
-   input, overflow, and basic code points encoded using deltas instead
-   of appearing literally.  If the decoder fails on these errors as
-   shown above, then it cannot produce the same output for two distinct
-   inputs.  Without this property it would have been necessary to re-
-
-
-
-Costello                    Standards Track                    [Page 11]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   encode the output and verify that it matches the input in order to
-   guarantee the uniqueness of the encoding.
-
-6.3 Encoding procedure
-
-   let n = initial_n
-   let delta = 0
-   let bias = initial_bias
-   let h = b = the number of basic code points in the input
-   copy them to the output in order, followed by a delimiter if b > 0
-   {if the input contains a non-basic code point < n then fail}
-   while h < length(input) do begin
-     let m = the minimum {non-basic} code point >= n in the input
-     let delta = delta + (m - n) * (h + 1), fail on overflow
-     let n = m
-     for each code point c in the input (in order) do begin
-       if c < n {or c is basic} then increment delta, fail on overflow
-       if c == n then begin
-         let q = delta
-         for k = base to infinity in steps of base do begin
-           let t = tmin if k <= bias {+ tmin}, or
-                   tmax if k >= bias + tmax, or k - bias otherwise
-           if q < t then break
-           output the code point for digit t + ((q - t) mod (base - t))
-           let q = (q - t) div (base - t)
-         end
-         output the code point for digit q
-         let bias = adapt(delta, h + 1, test h equals b?)
-         let delta = 0
-         increment h
-       end
-     end
-     increment delta and n
-   end
-
-   The full statement enclosed in braces (checking whether the input
-   contains a non-basic code point less than n) can be omitted if all
-   code points less than initial_n are basic code points (which is true
-   for Punycode if code points are unsigned).
-
-   The brace-enclosed conditions "non-basic" and "or c is basic" can be
-   omitted if initial_n exceeds all basic code points (which is true for
-   Punycode), because the code point being tested is never less than
-   initial_n.
-
-   In the assignment of t, where t is clamped to the range tmin through
-   tmax, "+ tmin" can always be omitted.  This makes the clamping
-   calculation incorrect when bias < k < bias + tmin, but that cannot
-
-
-
-Costello                    Standards Track                    [Page 12]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   happen because of the way bias is computed and because of the
-   constraints on the parameters.
-
-   The checks for overflow are necessary to avoid producing invalid
-   output when the input contains very large values or is very long.
-
-   The increment of delta at the bottom of the outer loop cannot
-   overflow because delta < length(input) before the increment, and
-   length(input) is already assumed to be representable.  The increment
-   of n could overflow, but only if h == length(input), in which case
-   the procedure is finished anyway.
-
-6.4 Overflow handling
-
-   For IDNA, 26-bit unsigned integers are sufficient to handle all valid
-   IDNA labels without overflow, because any string that needed a 27-bit
-   delta would have to exceed either the code point limit (0..10FFFF) or
-   the label length limit (63 characters).  However, overflow handling
-   is necessary because the inputs are not necessarily valid IDNA
-   labels.
-
-   If the programming language does not provide overflow detection, the
-   following technique can be used.  Suppose A, B, and C are
-   representable nonnegative integers and C is nonzero.  Then A + B
-   overflows if and only if B > maxint - A, and A + (B * C) overflows if
-   and only if B > (maxint - A) div C, where maxint is the greatest
-   integer for which maxint + 1 cannot be represented.  Refer to
-   appendix C "Punycode sample implementation" for demonstrations of
-   this technique in the C language.
-
-   The decoding and encoding algorithms shown in sections 6.2 and 6.3
-   handle overflow by detecting it whenever it happens.  Another
-   approach is to enforce limits on the inputs that prevent overflow
-   from happening.  For example, if the encoder were to verify that no
-   input code points exceed M and that the input length does not exceed
-   L, then no delta could ever exceed (M - initial_n) * (L + 1), and
-   hence no overflow could occur if integer variables were capable of
-   representing values that large.  This prevention approach would
-   impose more restrictions on the input than the detection approach
-   does, but might be considered simpler in some programming languages.
-
-   In theory, the decoder could use an analogous approach, limiting the
-   number of digits in a variable-length integer (that is, limiting the
-   number of iterations in the innermost loop).  However, the number of
-   digits that suffice to represent a given delta can sometimes
-   represent much larger deltas (because of the adaptation), and hence
-   this approach would probably need integers wider than 32 bits.
-
-
-
-
-Costello                    Standards Track                    [Page 13]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   Yet another approach for the decoder is to allow overflow to occur,
-   but to check the final output string by re-encoding it and comparing
-   to the decoder input.  If and only if they do not match (using a
-   case-insensitive ASCII comparison) overflow has occurred.  This
-   delayed-detection approach would not impose any more restrictions on
-   the input than the immediate-detection approach does, and might be
-   considered simpler in some programming languages.
-
-   In fact, if the decoder is used only inside the IDNA ToUnicode
-   operation [IDNA], then it need not check for overflow at all, because
-   ToUnicode performs a higher level re-encoding and comparison, and a
-   mismatch has the same consequence as if the Punycode decoder had
-   failed.
-
-7. Punycode examples
-
-7.1 Sample strings
-
-   In the Punycode encodings below, the ACE prefix is not shown.
-   Backslashes show where line breaks have been inserted in strings too
-   long for one line.
-
-   The first several examples are all translations of the sentence "Why
-   can't they just speak in <language>?" (courtesy of Michael Kaplan's
-   "provincial" page [PROVINCIAL]).  Word breaks and punctuation have
-   been removed, as is often done in domain names.
-
-   (A) Arabic (Egyptian):
-       u+0644 u+064A u+0647 u+0645 u+0627 u+0628 u+062A u+0643 u+0644
-       u+0645 u+0648 u+0634 u+0639 u+0631 u+0628 u+064A u+061F
-       Punycode: egbpdaj6bu4bxfgehfvwxn
-
-   (B) Chinese (simplified):
-       u+4ED6 u+4EEC u+4E3A u+4EC0 u+4E48 u+4E0D u+8BF4 u+4E2D u+6587
-       Punycode: ihqwcrb4cv8a8dqg056pqjye
-
-   (C) Chinese (traditional):
-       u+4ED6 u+5011 u+7232 u+4EC0 u+9EBD u+4E0D u+8AAA u+4E2D u+6587
-       Punycode: ihqwctvzc91f659drss3x8bo0yb
-
-   (D) Czech: Pro<ccaron>prost<ecaron>nemluv<iacute><ccaron>esky
-       U+0050 u+0072 u+006F u+010D u+0070 u+0072 u+006F u+0073 u+0074
-       u+011B u+006E u+0065 u+006D u+006C u+0075 u+0076 u+00ED u+010D
-       u+0065 u+0073 u+006B u+0079
-       Punycode: Proprostnemluvesky-uyb24dma41a
-
-
-
-
-
-
-Costello                    Standards Track                    [Page 14]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   (E) Hebrew:
-       u+05DC u+05DE u+05D4 u+05D4 u+05DD u+05E4 u+05E9 u+05D5 u+05D8
-       u+05DC u+05D0 u+05DE u+05D3 u+05D1 u+05E8 u+05D9 u+05DD u+05E2
-       u+05D1 u+05E8 u+05D9 u+05EA
-       Punycode: 4dbcagdahymbxekheh6e0a7fei0b
-
-   (F) Hindi (Devanagari):
-       u+092F u+0939 u+0932 u+094B u+0917 u+0939 u+093F u+0928 u+094D
-       u+0926 u+0940 u+0915 u+094D u+092F u+094B u+0902 u+0928 u+0939
-       u+0940 u+0902 u+092C u+094B u+0932 u+0938 u+0915 u+0924 u+0947
-       u+0939 u+0948 u+0902
-       Punycode: i1baa7eci9glrd9b2ae1bj0hfcgg6iyaf8o0a1dig0cd
-
-   (G) Japanese (kanji and hiragana):
-       u+306A u+305C u+307F u+3093 u+306A u+65E5 u+672C u+8A9E u+3092
-       u+8A71 u+3057 u+3066 u+304F u+308C u+306A u+3044 u+306E u+304B
-       Punycode: n8jok5ay5dzabd5bym9f0cm5685rrjetr6pdxa
-
-   (H) Korean (Hangul syllables):
-       u+C138 u+ACC4 u+C758 u+BAA8 u+B4E0 u+C0AC u+B78C u+B4E4 u+C774
-       u+D55C u+AD6D u+C5B4 u+B97C u+C774 u+D574 u+D55C u+B2E4 u+BA74
-       u+C5BC u+B9C8 u+B098 u+C88B u+C744 u+AE4C
-       Punycode: 989aomsvi5e83db1d2a355cv1e0vak1dwrv93d5xbh15a0dt30a5j\
-                 psd879ccm6fea98c
-
-   (I) Russian (Cyrillic):
-       U+043F u+043E u+0447 u+0435 u+043C u+0443 u+0436 u+0435 u+043E
-       u+043D u+0438 u+043D u+0435 u+0433 u+043E u+0432 u+043E u+0440
-       u+044F u+0442 u+043F u+043E u+0440 u+0443 u+0441 u+0441 u+043A
-       u+0438
-       Punycode: b1abfaaepdrnnbgefbaDotcwatmq2g4l
-
-   (J) Spanish: Porqu<eacute>nopuedensimplementehablarenEspa<ntilde>ol
-       U+0050 u+006F u+0072 u+0071 u+0075 u+00E9 u+006E u+006F u+0070
-       u+0075 u+0065 u+0064 u+0065 u+006E u+0073 u+0069 u+006D u+0070
-       u+006C u+0065 u+006D u+0065 u+006E u+0074 u+0065 u+0068 u+0061
-       u+0062 u+006C u+0061 u+0072 u+0065 u+006E U+0045 u+0073 u+0070
-       u+0061 u+00F1 u+006F u+006C
-       Punycode: PorqunopuedensimplementehablarenEspaol-fmd56a
-
-   (K) Vietnamese:
-       T<adotbelow>isaoh<odotbelow>kh<ocirc>ngth<ecirchookabove>ch\
-       <ihookabove>n<oacute>iti<ecircacute>ngVi<ecircdotbelow>t
-       U+0054 u+1EA1 u+0069 u+0073 u+0061 u+006F u+0068 u+1ECD u+006B
-       u+0068 u+00F4 u+006E u+0067 u+0074 u+0068 u+1EC3 u+0063 u+0068
-       u+1EC9 u+006E u+00F3 u+0069 u+0074 u+0069 u+1EBF u+006E u+0067
-       U+0056 u+0069 u+1EC7 u+0074
-       Punycode: TisaohkhngthchnitingVit-kjcr8268qyxafd2f1b9g
-
-
-
-Costello                    Standards Track                    [Page 15]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   The next several examples are all names of Japanese music artists,
-   song titles, and TV programs, just because the author happens to have
-   them handy (but Japanese is useful for providing examples of single-
-   row text, two-row text, ideographic text, and various mixtures
-   thereof).
-
-   (L) 3<nen>B<gumi><kinpachi><sensei>
-       u+0033 u+5E74 U+0042 u+7D44 u+91D1 u+516B u+5148 u+751F
-       Punycode: 3B-ww4c5e180e575a65lsy2b
-
-   (M) <amuro><namie>-with-SUPER-MONKEYS
-       u+5B89 u+5BA4 u+5948 u+7F8E u+6075 u+002D u+0077 u+0069 u+0074
-       u+0068 u+002D U+0053 U+0055 U+0050 U+0045 U+0052 u+002D U+004D
-       U+004F U+004E U+004B U+0045 U+0059 U+0053
-       Punycode: -with-SUPER-MONKEYS-pc58ag80a8qai00g7n9n
-
-   (N) Hello-Another-Way-<sorezore><no><basho>
-       U+0048 u+0065 u+006C u+006C u+006F u+002D U+0041 u+006E u+006F
-       u+0074 u+0068 u+0065 u+0072 u+002D U+0057 u+0061 u+0079 u+002D
-       u+305D u+308C u+305E u+308C u+306E u+5834 u+6240
-       Punycode: Hello-Another-Way--fc4qua05auwb3674vfr0b
-
-   (O) <hitotsu><yane><no><shita>2
-       u+3072 u+3068 u+3064 u+5C4B u+6839 u+306E u+4E0B u+0032
-       Punycode: 2-u9tlzr9756bt3uc0v
-
-   (P) Maji<de>Koi<suru>5<byou><mae>
-       U+004D u+0061 u+006A u+0069 u+3067 U+004B u+006F u+0069 u+3059
-       u+308B u+0035 u+79D2 u+524D
-       Punycode: MajiKoi5-783gue6qz075azm5e
-
-   (Q) <pafii>de<runba>
-       u+30D1 u+30D5 u+30A3 u+30FC u+0064 u+0065 u+30EB u+30F3 u+30D0
-       Punycode: de-jg4avhby1noc0d
-
-   (R) <sono><supiido><de>
-       u+305D u+306E u+30B9 u+30D4 u+30FC u+30C9 u+3067
-       Punycode: d9juau41awczczp
-
-   The last example is an ASCII string that breaks the existing rules
-   for host name labels.  (It is not a realistic example for IDNA,
-   because IDNA never encodes pure ASCII labels.)
-
-   (S) -> $1.00 <-
-       u+002D u+003E u+0020 u+0024 u+0031 u+002E u+0030 u+0030 u+0020
-       u+003C u+002D
-       Punycode: -> $1.00 <--
-
-
-
-
-Costello                    Standards Track                    [Page 16]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-7.2 Decoding traces
-
-   In the following traces, the evolving state of the decoder is shown
-   as a sequence of hexadecimal values, representing the code points in
-   the extended string.  An asterisk appears just after the most
-   recently inserted code point, indicating both n (the value preceeding
-   the asterisk) and i (the position of the value just after the
-   asterisk).  Other numerical values are decimal.
-
-   Decoding trace of example B from section 7.1:
-
-   n is 128, i is 0, bias is 72
-   input is "ihqwcrb4cv8a8dqg056pqjye"
-   there is no delimiter, so extended string starts empty
-   delta "ihq" decodes to 19853
-   bias becomes 21
-   4E0D *
-   delta "wc" decodes to 64
-   bias becomes 20
-   4E0D 4E2D *
-   delta "rb" decodes to 37
-   bias becomes 13
-   4E3A * 4E0D 4E2D
-   delta "4c" decodes to 56
-   bias becomes 17
-   4E3A 4E48 * 4E0D 4E2D
-   delta "v8a" decodes to 599
-   bias becomes 32
-   4E3A 4EC0 * 4E48 4E0D 4E2D
-   delta "8d" decodes to 130
-   bias becomes 23
-   4ED6 * 4E3A 4EC0 4E48 4E0D 4E2D
-   delta "qg" decodes to 154
-   bias becomes 25
-   4ED6 4EEC * 4E3A 4EC0 4E48 4E0D 4E2D
-   delta "056p" decodes to 46301
-   bias becomes 84
-   4ED6 4EEC 4E3A 4EC0 4E48 4E0D 4E2D 6587 *
-   delta "qjye" decodes to 88531
-   bias becomes 90
-   4ED6 4EEC 4E3A 4EC0 4E48 4E0D 8BF4 * 4E2D 6587
-
-
-
-
-
-
-
-
-
-
-Costello                    Standards Track                    [Page 17]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   Decoding trace of example L from section 7.1:
-
-   n is 128, i is 0, bias is 72
-   input is "3B-ww4c5e180e575a65lsy2b"
-   literal portion is "3B-", so extended string starts as:
-   0033 0042
-   delta "ww4c" decodes to 62042
-   bias becomes 27
-   0033 0042 5148 *
-   delta "5e" decodes to 139
-   bias becomes 24
-   0033 0042 516B * 5148
-   delta "180e" decodes to 16683
-   bias becomes 67
-   0033 5E74 * 0042 516B 5148
-   delta "575a" decodes to 34821
-   bias becomes 82
-   0033 5E74 0042 516B 5148 751F *
-   delta "65l" decodes to 14592
-   bias becomes 67
-   0033 5E74 0042 7D44 * 516B 5148 751F
-   delta "sy2b" decodes to 42088
-   bias becomes 84
-   0033 5E74 0042 7D44 91D1 * 516B 5148 751F
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Costello                    Standards Track                    [Page 18]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-7.3 Encoding traces
-
-   In the following traces, code point values are hexadecimal, while
-   other numerical values are decimal.
-
-   Encoding trace of example B from section 7.1:
-
-   bias is 72
-   input is:
-   4ED6 4EEC 4E3A 4EC0 4E48 4E0D 8BF4 4E2D 6587
-   there are no basic code points, so no literal portion
-   next code point to insert is 4E0D
-   needed delta is 19853, encodes as "ihq"
-   bias becomes 21
-   next code point to insert is 4E2D
-   needed delta is 64, encodes as "wc"
-   bias becomes 20
-   next code point to insert is 4E3A
-   needed delta is 37, encodes as "rb"
-   bias becomes 13
-   next code point to insert is 4E48
-   needed delta is 56, encodes as "4c"
-   bias becomes 17
-   next code point to insert is 4EC0
-   needed delta is 599, encodes as "v8a"
-   bias becomes 32
-   next code point to insert is 4ED6
-   needed delta is 130, encodes as "8d"
-   bias becomes 23
-   next code point to insert is 4EEC
-   needed delta is 154, encodes as "qg"
-   bias becomes 25
-   next code point to insert is 6587
-   needed delta is 46301, encodes as "056p"
-   bias becomes 84
-   next code point to insert is 8BF4
-   needed delta is 88531, encodes as "qjye"
-   bias becomes 90
-   output is "ihqwcrb4cv8a8dqg056pqjye"
-
-
-
-
-
-
-
-
-
-
-
-
-Costello                    Standards Track                    [Page 19]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   Encoding trace of example L from section 7.1:
-
-   bias is 72
-   input is:
-   0033 5E74 0042 7D44 91D1 516B 5148 751F
-   basic code points (0033, 0042) are copied to literal portion: "3B-"
-   next code point to insert is 5148
-   needed delta is 62042, encodes as "ww4c"
-   bias becomes 27
-   next code point to insert is 516B
-   needed delta is 139, encodes as "5e"
-   bias becomes 24
-   next code point to insert is 5E74
-   needed delta is 16683, encodes as "180e"
-   bias becomes 67
-   next code point to insert is 751F
-   needed delta is 34821, encodes as "575a"
-   bias becomes 82
-   next code point to insert is 7D44
-   needed delta is 14592, encodes as "65l"
-   bias becomes 67
-   next code point to insert is 91D1
-   needed delta is 42088, encodes as "sy2b"
-   bias becomes 84
-   output is "3B-ww4c5e180e575a65lsy2b"
-
-8. Security Considerations
-
-   Users expect each domain name in DNS to be controlled by a single
-   authority.  If a Unicode string intended for use as a domain label
-   could map to multiple ACE labels, then an internationalized domain
-   name could map to multiple ASCII domain names, each controlled by a
-   different authority, some of which could be spoofs that hijack
-   service requests intended for another.  Therefore Punycode is
-   designed so that each Unicode string has a unique encoding.
-
-   However, there can still be multiple Unicode representations of the
-   "same" text, for various definitions of "same".  This problem is
-   addressed to some extent by the Unicode standard under the topic of
-   canonicalization, and this work is leveraged for domain names by
-   Nameprep [NAMEPREP].
-
-
-
-
-
-
-
-
-
-
-Costello                    Standards Track                    [Page 20]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-9. References
-
-9.1 Normative References
-
-   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
-                Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-9.2 Informative References
-
-   [RFC952]     Harrenstien, K., Stahl, M. and E. Feinler, "DOD Internet
-                Host Table Specification", RFC 952, October 1985.
-
-   [RFC1034]    Mockapetris, P., "Domain Names - Concepts and
-                Facilities", STD 13, RFC 1034, November 1987.
-
-   [IDNA]       Faltstrom, P., Hoffman, P. and A. Costello,
-                "Internationalizing Domain Names in Applications
-                (IDNA)", RFC 3490, March 2003.
-
-   [NAMEPREP]   Hoffman, P. and  M. Blanchet, "Nameprep: A Stringprep
-                Profile for Internationalized Domain Names (IDN)", RFC
-                3491, March 2003.
-
-   [ASCII]      Cerf, V., "ASCII format for Network Interchange", RFC
-                20, October 1969.
-
-   [PROVINCIAL] Kaplan, M., "The 'anyone can be provincial!' page",
-                http://www.trigeminal.com/samples/provincial.html.
-
-   [UNICODE]    The Unicode Consortium, "The Unicode Standard",
-                http://www.unicode.org/unicode/standard/standard.html.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Costello                    Standards Track                    [Page 21]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-A. Mixed-case annotation
-
-   In order to use Punycode to represent case-insensitive strings,
-   higher layers need to case-fold the strings prior to Punycode
-   encoding.  The encoded string can use mixed case as an annotation
-   telling how to convert the folded string into a mixed-case string for
-   display purposes.  Note, however, that mixed-case annotation is not
-   used by the ToASCII and ToUnicode operations specified in [IDNA], and
-   therefore implementors of IDNA can disregard this appendix.
-
-   Basic code points can use mixed case directly, because the decoder
-   copies them verbatim, leaving lowercase code points lowercase, and
-   leaving uppercase code points uppercase.  Each non-basic code point
-   is represented by a delta, which is represented by a sequence of
-   basic code points, the last of which provides the annotation.  If it
-   is uppercase, it is a suggestion to map the non-basic code point to
-   uppercase (if possible); if it is lowercase, it is a suggestion to
-   map the non-basic code point to lowercase (if possible).
-
-   These annotations do not alter the code points returned by decoders;
-   the annotations are returned separately, for the caller to use or
-   ignore.  Encoders can accept annotations in addition to code points,
-   but the annotations do not alter the output, except to influence the
-   uppercase/lowercase form of ASCII letters.
-
-   Punycode encoders and decoders need not support these annotations,
-   and higher layers need not use them.
-
-B. Disclaimer and license
-
-   Regarding this entire document or any portion of it (including the
-   pseudocode and C code), the author makes no guarantees and is not
-   responsible for any damage resulting from its use.  The author grants
-   irrevocable permission to anyone to use, modify, and distribute it in
-   any way that does not diminish the rights of anyone else to use,
-   modify, and distribute it, provided that redistributed derivative
-   works do not contain misleading author or version information.
-   Derivative works need not be licensed under similar terms.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Costello                    Standards Track                    [Page 22]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-C. Punycode sample implementation
-
-/*
-punycode.c from RFC 3492
-http://www.nicemice.net/idn/
-Adam M. Costello
-http://www.nicemice.net/amc/
-
-This is ANSI C code (C89) implementing Punycode (RFC 3492).
-
-*/
-
-
-/************************************************************/
-/* Public interface (would normally go in its own .h file): */
-
-#include <limits.h>
-
-enum punycode_status {
-  punycode_success,
-  punycode_bad_input,   /* Input is invalid.                       */
-  punycode_big_output,  /* Output would exceed the space provided. */
-  punycode_overflow     /* Input needs wider integers to process.  */
-};
-
-#if UINT_MAX >= (1 << 26) - 1
-typedef unsigned int punycode_uint;
-#else
-typedef unsigned long punycode_uint;
-#endif
-
-enum punycode_status punycode_encode(
-  punycode_uint input_length,
-  const punycode_uint input[],
-  const unsigned char case_flags[],
-  punycode_uint *output_length,
-  char output[] );
-
-    /* punycode_encode() converts Unicode to Punycode.  The input     */
-    /* is represented as an array of Unicode code points (not code    */
-    /* units; surrogate pairs are not allowed), and the output        */
-    /* will be represented as an array of ASCII code points.  The     */
-    /* output string is *not* null-terminated; it will contain        */
-    /* zeros if and only if the input contains zeros.  (Of course     */
-    /* the caller can leave room for a terminator and add one if      */
-    /* needed.)  The input_length is the number of code points in     */
-    /* the input.  The output_length is an in/out argument: the       */
-    /* caller passes in the maximum number of code points that it     */
-
-
-
-Costello                    Standards Track                    [Page 23]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-    /* can receive, and on successful return it will contain the      */
-    /* number of code points actually output.  The case_flags array   */
-    /* holds input_length boolean values, where nonzero suggests that */
-    /* the corresponding Unicode character be forced to uppercase     */
-    /* after being decoded (if possible), and zero suggests that      */
-    /* it be forced to lowercase (if possible).  ASCII code points    */
-    /* are encoded literally, except that ASCII letters are forced    */
-    /* to uppercase or lowercase according to the corresponding       */
-    /* uppercase flags.  If case_flags is a null pointer then ASCII   */
-    /* letters are left as they are, and other code points are        */
-    /* treated as if their uppercase flags were zero.  The return     */
-    /* value can be any of the punycode_status values defined above   */
-    /* except punycode_bad_input; if not punycode_success, then       */
-    /* output_size and output might contain garbage.                  */
-
-enum punycode_status punycode_decode(
-  punycode_uint input_length,
-  const char input[],
-  punycode_uint *output_length,
-  punycode_uint output[],
-  unsigned char case_flags[] );
-
-    /* punycode_decode() converts Punycode to Unicode.  The input is  */
-    /* represented as an array of ASCII code points, and the output   */
-    /* will be represented as an array of Unicode code points.  The   */
-    /* input_length is the number of code points in the input.  The   */
-    /* output_length is an in/out argument: the caller passes in      */
-    /* the maximum number of code points that it can receive, and     */
-    /* on successful return it will contain the actual number of      */
-    /* code points output.  The case_flags array needs room for at    */
-    /* least output_length values, or it can be a null pointer if the */
-    /* case information is not needed.  A nonzero flag suggests that  */
-    /* the corresponding Unicode character be forced to uppercase     */
-    /* by the caller (if possible), while zero suggests that it be    */
-    /* forced to lowercase (if possible).  ASCII code points are      */
-    /* output already in the proper case, but their flags will be set */
-    /* appropriately so that applying the flags would be harmless.    */
-    /* The return value can be any of the punycode_status values      */
-    /* defined above; if not punycode_success, then output_length,    */
-    /* output, and case_flags might contain garbage.  On success, the */
-    /* decoder will never need to write an output_length greater than */
-    /* input_length, because of how the encoding is defined.          */
-
-/**********************************************************/
-/* Implementation (would normally go in its own .c file): */
-
-#include <string.h>
-
-
-
-
-Costello                    Standards Track                    [Page 24]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-/*** Bootstring parameters for Punycode ***/
-
-enum { base = 36, tmin = 1, tmax = 26, skew = 38, damp = 700,
-       initial_bias = 72, initial_n = 0x80, delimiter = 0x2D };
-
-/* basic(cp) tests whether cp is a basic code point: */
-#define basic(cp) ((punycode_uint)(cp) < 0x80)
-
-/* delim(cp) tests whether cp is a delimiter: */
-#define delim(cp) ((cp) == delimiter)
-
-/* decode_digit(cp) returns the numeric value of a basic code */
-/* point (for use in representing integers) in the range 0 to */
-/* base-1, or base if cp is does not represent a value.       */
-
-static punycode_uint decode_digit(punycode_uint cp)
-{
-  return  cp - 48 < 10 ? cp - 22 :  cp - 65 < 26 ? cp - 65 :
-          cp - 97 < 26 ? cp - 97 :  base;
-}
-
-/* encode_digit(d,flag) returns the basic code point whose value      */
-/* (when used for representing integers) is d, which needs to be in   */
-/* the range 0 to base-1.  The lowercase form is used unless flag is  */
-/* nonzero, in which case the uppercase form is used.  The behavior   */
-/* is undefined if flag is nonzero and digit d has no uppercase form. */
-
-static char encode_digit(punycode_uint d, int flag)
-{
-  return d + 22 + 75 * (d < 26) - ((flag != 0) << 5);
-  /*  0..25 map to ASCII a..z or A..Z */
-  /* 26..35 map to ASCII 0..9         */
-}
-
-/* flagged(bcp) tests whether a basic code point is flagged */
-/* (uppercase).  The behavior is undefined if bcp is not a  */
-/* basic code point.                                        */
-
-#define flagged(bcp) ((punycode_uint)(bcp) - 65 < 26)
-
-/* encode_basic(bcp,flag) forces a basic code point to lowercase */
-/* if flag is zero, uppercase if flag is nonzero, and returns    */
-/* the resulting code point.  The code point is unchanged if it  */
-/* is caseless.  The behavior is undefined if bcp is not a basic */
-/* code point.                                                   */
-
-static char encode_basic(punycode_uint bcp, int flag)
-{
-
-
-
-Costello                    Standards Track                    [Page 25]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-  bcp -= (bcp - 97 < 26) << 5;
-  return bcp + ((!flag && (bcp - 65 < 26)) << 5);
-}
-
-/*** Platform-specific constants ***/
-
-/* maxint is the maximum value of a punycode_uint variable: */
-static const punycode_uint maxint = -1;
-/* Because maxint is unsigned, -1 becomes the maximum value. */
-
-/*** Bias adaptation function ***/
-
-static punycode_uint adapt(
-  punycode_uint delta, punycode_uint numpoints, int firsttime )
-{
-  punycode_uint k;
-
-  delta = firsttime ? delta / damp : delta >> 1;
-  /* delta >> 1 is a faster way of doing delta / 2 */
-  delta += delta / numpoints;
-
-  for (k = 0;  delta > ((base - tmin) * tmax) / 2;  k += base) {
-    delta /= base - tmin;
-  }
-
-  return k + (base - tmin + 1) * delta / (delta + skew);
-}
-
-/*** Main encode function ***/
-
-enum punycode_status punycode_encode(
-  punycode_uint input_length,
-  const punycode_uint input[],
-  const unsigned char case_flags[],
-  punycode_uint *output_length,
-  char output[] )
-{
-  punycode_uint n, delta, h, b, out, max_out, bias, j, m, q, k, t;
-
-  /* Initialize the state: */
-
-  n = initial_n;
-  delta = out = 0;
-  max_out = *output_length;
-  bias = initial_bias;
-
-  /* Handle the basic code points: */
-
-
-
-
-Costello                    Standards Track                    [Page 26]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-  for (j = 0;  j < input_length;  ++j) {
-    if (basic(input[j])) {
-      if (max_out - out < 2) return punycode_big_output;
-      output[out++] =
-        case_flags ?  encode_basic(input[j], case_flags[j]) : input[j];
-    }
-    /* else if (input[j] < n) return punycode_bad_input; */
-    /* (not needed for Punycode with unsigned code points) */
-  }
-
-  h = b = out;
-
-  /* h is the number of code points that have been handled, b is the  */
-  /* number of basic code points, and out is the number of characters */
-  /* that have been output.                                           */
-
-  if (b > 0) output[out++] = delimiter;
-
-  /* Main encoding loop: */
-
-  while (h < input_length) {
-    /* All non-basic code points < n have been     */
-    /* handled already.  Find the next larger one: */
-
-    for (m = maxint, j = 0;  j < input_length;  ++j) {
-      /* if (basic(input[j])) continue; */
-      /* (not needed for Punycode) */
-      if (input[j] >= n && input[j] < m) m = input[j];
-    }
-
-    /* Increase delta enough to advance the decoder's    */
-    /* <n,i> state to <m,0>, but guard against overflow: */
-
-    if (m - n > (maxint - delta) / (h + 1)) return punycode_overflow;
-    delta += (m - n) * (h + 1);
-    n = m;
-
-    for (j = 0;  j < input_length;  ++j) {
-      /* Punycode does not need to check whether input[j] is basic: */
-      if (input[j] < n /* || basic(input[j]) */ ) {
-        if (++delta == 0) return punycode_overflow;
-      }
-
-      if (input[j] == n) {
-        /* Represent delta as a generalized variable-length integer: */
-
-        for (q = delta, k = base;  ;  k += base) {
-          if (out >= max_out) return punycode_big_output;
-
-
-
-Costello                    Standards Track                    [Page 27]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-          t = k <= bias /* + tmin */ ? tmin :     /* +tmin not needed */
-              k >= bias + tmax ? tmax : k - bias;
-          if (q < t) break;
-          output[out++] = encode_digit(t + (q - t) % (base - t), 0);
-          q = (q - t) / (base - t);
-        }
-
-        output[out++] = encode_digit(q, case_flags && case_flags[j]);
-        bias = adapt(delta, h + 1, h == b);
-        delta = 0;
-        ++h;
-      }
-    }
-
-    ++delta, ++n;
-  }
-
-  *output_length = out;
-  return punycode_success;
-}
-
-/*** Main decode function ***/
-
-enum punycode_status punycode_decode(
-  punycode_uint input_length,
-  const char input[],
-  punycode_uint *output_length,
-  punycode_uint output[],
-  unsigned char case_flags[] )
-{
-  punycode_uint n, out, i, max_out, bias,
-                 b, j, in, oldi, w, k, digit, t;
-
-  /* Initialize the state: */
-
-  n = initial_n;
-  out = i = 0;
-  max_out = *output_length;
-  bias = initial_bias;
-
-  /* Handle the basic code points:  Let b be the number of input code */
-  /* points before the last delimiter, or 0 if there is none, then    */
-  /* copy the first b code points to the output.                      */
-
-  for (b = j = 0;  j < input_length;  ++j) if (delim(input[j])) b = j;
-  if (b > max_out) return punycode_big_output;
-
-  for (j = 0;  j < b;  ++j) {
-
-
-
-Costello                    Standards Track                    [Page 28]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-    if (case_flags) case_flags[out] = flagged(input[j]);
-    if (!basic(input[j])) return punycode_bad_input;
-    output[out++] = input[j];
-  }
-
-  /* Main decoding loop:  Start just after the last delimiter if any  */
-  /* basic code points were copied; start at the beginning otherwise. */
-
-  for (in = b > 0 ? b + 1 : 0;  in < input_length;  ++out) {
-
-    /* in is the index of the next character to be consumed, and */
-    /* out is the number of code points in the output array.     */
-
-    /* Decode a generalized variable-length integer into delta,  */
-    /* which gets added to i.  The overflow checking is easier   */
-    /* if we increase i as we go, then subtract off its starting */
-    /* value at the end to obtain delta.                         */
-
-    for (oldi = i, w = 1, k = base;  ;  k += base) {
-      if (in >= input_length) return punycode_bad_input;
-      digit = decode_digit(input[in++]);
-      if (digit >= base) return punycode_bad_input;
-      if (digit > (maxint - i) / w) return punycode_overflow;
-      i += digit * w;
-      t = k <= bias /* + tmin */ ? tmin :     /* +tmin not needed */
-          k >= bias + tmax ? tmax : k - bias;
-      if (digit < t) break;
-      if (w > maxint / (base - t)) return punycode_overflow;
-      w *= (base - t);
-    }
-
-    bias = adapt(i - oldi, out + 1, oldi == 0);
-
-    /* i was supposed to wrap around from out+1 to 0,   */
-    /* incrementing n each time, so we'll fix that now: */
-
-    if (i / (out + 1) > maxint - n) return punycode_overflow;
-    n += i / (out + 1);
-    i %= (out + 1);
-
-    /* Insert n at position i of the output: */
-
-    /* not needed for Punycode: */
-    /* if (decode_digit(n) <= base) return punycode_invalid_input; */
-    if (out >= max_out) return punycode_big_output;
-
-    if (case_flags) {
-      memmove(case_flags + i + 1, case_flags + i, out - i);
-
-
-
-Costello                    Standards Track                    [Page 29]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-      /* Case of last character determines uppercase flag: */
-      case_flags[i] = flagged(input[in - 1]);
-    }
-
-    memmove(output + i + 1, output + i, (out - i) * sizeof *output);
-    output[i++] = n;
-  }
-
-  *output_length = out;
-  return punycode_success;
-}
-
-/******************************************************************/
-/* Wrapper for testing (would normally go in a separate .c file): */
-
-#include <assert.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-
-/* For testing, we'll just set some compile-time limits rather than */
-/* use malloc(), and set a compile-time option rather than using a  */
-/* command-line option.                                             */
-
-enum {
-  unicode_max_length = 256,
-  ace_max_length = 256
-};
-
-static void usage(char **argv)
-{
-  fprintf(stderr,
-    "\n"
-    "%s -e reads code points and writes a Punycode string.\n"
-    "%s -d reads a Punycode string and writes code points.\n"
-    "\n"
-    "Input and output are plain text in the native character set.\n"
-    "Code points are in the form u+hex separated by whitespace.\n"
-    "Although the specification allows Punycode strings to contain\n"
-    "any characters from the ASCII repertoire, this test code\n"
-    "supports only the printable characters, and needs the Punycode\n"
-    "string to be followed by a newline.\n"
-    "The case of the u in u+hex is the force-to-uppercase flag.\n"
-    , argv[0], argv[0]);
-  exit(EXIT_FAILURE);
-}
-
-static void fail(const char *msg)
-
-
-
-Costello                    Standards Track                    [Page 30]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-{
-  fputs(msg,stderr);
-  exit(EXIT_FAILURE);
-}
-
-static const char too_big[] =
-  "input or output is too large, recompile with larger limits\n";
-static const char invalid_input[] = "invalid input\n";
-static const char overflow[] = "arithmetic overflow\n";
-static const char io_error[] = "I/O error\n";
-
-/* The following string is used to convert printable */
-/* characters between ASCII and the native charset:  */
-
-static const char print_ascii[] =
-  "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"
-  "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"
-  " !\"#$%&'()*+,-./"
-  "0123456789:;<=>?"
-  "@ABCDEFGHIJKLMNO"
-  "PQRSTUVWXYZ[\\]^_"
-  "`abcdefghijklmno"
-  "pqrstuvwxyz{|}~\n";
-
-int main(int argc, char **argv)
-{
-  enum punycode_status status;
-  int r;
-  unsigned int input_length, output_length, j;
-  unsigned char case_flags[unicode_max_length];
-
-  if (argc != 2) usage(argv);
-  if (argv[1][0] != '-') usage(argv);
-  if (argv[1][2] != 0) usage(argv);
-
-  if (argv[1][1] == 'e') {
-    punycode_uint input[unicode_max_length];
-    unsigned long codept;
-    char output[ace_max_length+1], uplus[3];
-    int c;
-
-    /* Read the input code points: */
-
-    input_length = 0;
-
-    for (;;) {
-      r = scanf("%2s%lx", uplus, &codept);
-      if (ferror(stdin)) fail(io_error);
-
-
-
-Costello                    Standards Track                    [Page 31]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-      if (r == EOF || r == 0) break;
-
-      if (r != 2 || uplus[1] != '+' || codept > (punycode_uint)-1) {
-        fail(invalid_input);
-      }
-
-      if (input_length == unicode_max_length) fail(too_big);
-
-      if (uplus[0] == 'u') case_flags[input_length] = 0;
-      else if (uplus[0] == 'U') case_flags[input_length] = 1;
-      else fail(invalid_input);
-
-      input[input_length++] = codept;
-    }
-
-    /* Encode: */
-
-    output_length = ace_max_length;
-    status = punycode_encode(input_length, input, case_flags,
-                             &output_length, output);
-    if (status == punycode_bad_input) fail(invalid_input);
-    if (status == punycode_big_output) fail(too_big);
-    if (status == punycode_overflow) fail(overflow);
-    assert(status == punycode_success);
-
-    /* Convert to native charset and output: */
-
-    for (j = 0;  j < output_length;  ++j) {
-      c = output[j];
-      assert(c >= 0 && c <= 127);
-      if (print_ascii[c] == 0) fail(invalid_input);
-      output[j] = print_ascii[c];
-    }
-
-    output[j] = 0;
-    r = puts(output);
-    if (r == EOF) fail(io_error);
-    return EXIT_SUCCESS;
-  }
-
-  if (argv[1][1] == 'd') {
-    char input[ace_max_length+2], *p, *pp;
-    punycode_uint output[unicode_max_length];
-
-    /* Read the Punycode input string and convert to ASCII: */
-
-    fgets(input, ace_max_length+2, stdin);
-    if (ferror(stdin)) fail(io_error);
-
-
-
-Costello                    Standards Track                    [Page 32]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-    if (feof(stdin)) fail(invalid_input);
-    input_length = strlen(input) - 1;
-    if (input[input_length] != '\n') fail(too_big);
-    input[input_length] = 0;
-
-    for (p = input;  *p != 0;  ++p) {
-      pp = strchr(print_ascii, *p);
-      if (pp == 0) fail(invalid_input);
-      *p = pp - print_ascii;
-    }
-
-    /* Decode: */
-
-    output_length = unicode_max_length;
-    status = punycode_decode(input_length, input, &output_length,
-                             output, case_flags);
-    if (status == punycode_bad_input) fail(invalid_input);
-    if (status == punycode_big_output) fail(too_big);
-    if (status == punycode_overflow) fail(overflow);
-    assert(status == punycode_success);
-
-    /* Output the result: */
-
-    for (j = 0;  j < output_length;  ++j) {
-      r = printf("%s+%04lX\n",
-                 case_flags[j] ? "U" : "u",
-                 (unsigned long) output[j] );
-      if (r < 0) fail(io_error);
-    }
-
-    return EXIT_SUCCESS;
-  }
-
-  usage(argv);
-  return EXIT_SUCCESS;  /* not reached, but quiets compiler warning */
-}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Costello                    Standards Track                    [Page 33]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-Author's Address
-
-   Adam M. Costello
-   University of California, Berkeley
-   http://www.nicemice.net/amc/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Costello                    Standards Track                    [Page 34]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Costello                    Standards Track                    [Page 35]
-
diff --git a/contrib/bind9/doc/rfc/rfc3493.txt b/contrib/bind9/doc/rfc/rfc3493.txt
deleted file mode 100644
index 5fea6c1..0000000
--- a/contrib/bind9/doc/rfc/rfc3493.txt
+++ /dev/null
@@ -1,2187 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        R. Gilligan
-Request for Comments: 3493                                Intransa, Inc.
-Obsoletes: 2553                                               S. Thomson
-Category: Informational                                            Cisco
-                                                                J. Bound
-                                                               J. McCann
-                                                         Hewlett-Packard
-                                                              W. Stevens
-                                                           February 2003
-
-
-               Basic Socket Interface Extensions for IPv6
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-Abstract
-
-   The de facto standard Application Program Interface (API) for TCP/IP
-   applications is the "sockets" interface.  Although this API was
-   developed for Unix in the early 1980s it has also been implemented on
-   a wide variety of non-Unix systems.  TCP/IP applications written
-   using the sockets API have in the past enjoyed a high degree of
-   portability and we would like the same portability with IPv6
-   applications.  But changes are required to the sockets API to support
-   IPv6 and this memo describes these changes.  These include a new
-   socket address structure to carry IPv6 addresses, new address
-   conversion functions, and some new socket options.  These extensions
-   are designed to provide access to the basic IPv6 features required by
-   TCP and UDP applications, including multicasting, while introducing a
-   minimum of change into the system and providing complete
-   compatibility for existing IPv4 applications.  Additional extensions
-   for advanced IPv6 features (raw sockets and access to the IPv6
-   extension headers) are defined in another document.
-
-
-
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                      [Page 1]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-Table of Contents
-
-   1.  Introduction................................................3
-   2.  Design Considerations.......................................4
-       2.1  What Needs to be Changed...............................4
-       2.2  Data Types.............................................6
-       2.3  Headers................................................6
-       2.4  Structures.............................................6
-   3.  Socket Interface............................................6
-       3.1  IPv6 Address Family and Protocol Family................6
-       3.2  IPv6 Address Structure.................................7
-       3.3  Socket Address Structure for 4.3BSD-Based Systems......7
-       3.4  Socket Address Structure for 4.4BSD-Based Systems......9
-       3.5  The Socket Functions...................................9
-       3.6  Compatibility with IPv4 Applications..................10
-       3.7  Compatibility with IPv4 Nodes.........................11
-       3.8  IPv6 Wildcard Address.................................11
-       3.9  IPv6 Loopback Address.................................13
-       3.10 Portability Additions.................................14
-   4.  Interface Identification...................................16
-       4.1  Name-to-Index.........................................17
-       4.2  Index-to-Name.........................................17
-       4.3  Return All Interface Names and Indexes................18
-       4.4  Free Memory...........................................18
-   5.  Socket Options.............................................18
-       5.1  Unicast Hop Limit.....................................19
-       5.2  Sending and Receiving Multicast Packets...............19
-       5.3  IPV6_V6ONLY option for AF_INET6 Sockets...............22
-   6.  Library Functions..........................................22
-       6.1  Protocol-Independent Nodename and
-            Service Name Translation..............................23
-       6.2  Socket Address Structure to Node Name
-            and Service Name......................................28
-       6.3  Address Conversion Functions..........................31
-       6.4  Address Testing Macros................................33
-   7.  Summary of New Definitions.................................33
-   8.  Security Considerations....................................35
-   9.  Changes from RFC 2553......................................35
-   10. Acknowledgments............................................36
-   11. References.................................................37
-   12. Authors' Addresses.........................................38
-   13. Full Copyright Statement...................................39
-
-
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                      [Page 2]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-1. Introduction
-
-   While IPv4 addresses are 32 bits long, IPv6 addresses are 128 bits
-   long.  The socket interface makes the size of an IP address quite
-   visible to an application; virtually all TCP/IP applications for
-   BSD-based systems have knowledge of the size of an IP address.  Those
-   parts of the API that expose the addresses must be changed to
-   accommodate the larger IPv6 address size.  IPv6 also introduces new
-   features, some of which must be made visible to applications via the
-   API.  This memo defines a set of extensions to the socket interface
-   to support the larger address size and new features of IPv6.  It
-   defines "basic" extensions that are of use to a broad range of
-   applications.  A companion document, the "advanced" API [4], covers
-   extensions that are of use to more specialized applications, examples
-   of which include routing daemons, and the "ping" and "traceroute"
-   utilities.
-
-   The development of this API was started in 1994 in the IETF IPng
-   working group.  The API has evolved over the years, published first
-   in RFC 2133, then again in RFC 2553, and reaching its final form in
-   this document.
-
-   As the API matured and stabilized, it was incorporated into the Open
-   Group's Networking Services (XNS) specification, issue 5.2, which was
-   subsequently incorporated into a joint Open Group/IEEE/ISO standard
-   [3].
-
-   Effort has been made to ensure that this document and [3] contain the
-   same information with regard to the API definitions.  However, the
-   reader should note that this document is for informational purposes
-   only, and that the official standard specification of the sockets API
-   is [3].
-
-   It is expected that any future standardization work on this API would
-   be done by the Open Group Base Working Group [6].
-
-   It should also be noted that this document describes only those
-   portions of the API needed for IPv4 and IPv6 communications.  Other
-   potential uses of the API, for example the use of getaddrinfo() and
-   getnameinfo() with the AF_UNIX address family, are beyond the scope
-   of this document.
-
-
-
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                      [Page 3]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-2. Design Considerations
-
-   There are a number of important considerations in designing changes
-   to this well-worn API:
-
-   -  The API changes should provide both source and binary
-      compatibility for programs written to the original API.  That is,
-      existing program binaries should continue to operate when run on a
-      system supporting the new API.  In addition, existing applications
-      that are re-compiled and run on a system supporting the new API
-      should continue to operate.  Simply put, the API changes for IPv6
-      should not break existing programs.  An additional mechanism for
-      implementations to verify this is to verify the new symbols are
-      protected by Feature Test Macros as described in [3].  (Such
-      Feature Test Macros are not defined by this RFC.)
-
-   -  The changes to the API should be as small as possible in order to
-      simplify the task of converting existing IPv4 applications to
-      IPv6.
-
-   -  Where possible, applications should be able to use this API to
-      interoperate with both IPv6 and IPv4 hosts.  Applications should
-      not need to know which type of host they are communicating with.
-
-   -  IPv6 addresses carried in data structures should be 64-bit
-      aligned.  This is necessary in order to obtain optimum performance
-      on 64-bit machine architectures.
-
-   Because of the importance of providing IPv4 compatibility in the API,
-   these extensions are explicitly designed to operate on machines that
-   provide complete support for both IPv4 and IPv6.  A subset of this
-   API could probably be designed for operation on systems that support
-   only IPv6.  However, this is not addressed in this memo.
-
-2.1 What Needs to be Changed
-
-   The socket interface API consists of a few distinct components:
-
-   -  Core socket functions.
-
-   -  Address data structures.
-
-   -  Name-to-address translation functions.
-
-   -  Address conversion functions.
-
-
-
-
-
-
-Gilligan, et al.             Informational                      [Page 4]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   The core socket functions -- those functions that deal with such
-   things as setting up and tearing down TCP connections, and sending
-   and receiving UDP packets -- were designed to be transport
-   independent.  Where protocol addresses are passed as function
-   arguments, they are carried via opaque pointers.  A protocol-specific
-   address data structure is defined for each protocol that the socket
-   functions support.  Applications must cast pointers to these
-   protocol-specific address structures into pointers to the generic
-   "sockaddr" address structure when using the socket functions.  These
-   functions need not change for IPv6, but a new IPv6-specific address
-   data structure is needed.
-
-   The "sockaddr_in" structure is the protocol-specific data structure
-   for IPv4.  This data structure actually includes 8-octets of unused
-   space, and it is tempting to try to use this space to adapt the
-   sockaddr_in structure to IPv6.  Unfortunately, the sockaddr_in
-   structure is not large enough to hold the 16-octet IPv6 address as
-   well as the other information (address family and port number) that
-   is needed.  So a new address data structure must be defined for IPv6.
-
-   IPv6 addresses are scoped [2] so they could be link-local, site,
-   organization, global, or other scopes at this time undefined.  To
-   support applications that want to be able to identify a set of
-   interfaces for a specific scope, the IPv6 sockaddr_in structure must
-   support a field that can be used by an implementation to identify a
-   set of interfaces identifying the scope for an IPv6 address.
-
-   The IPv4 name-to-address translation functions in the socket
-   interface are gethostbyname() and gethostbyaddr().  These are left as
-   is, and new functions are defined which support both IPv4 and IPv6.
-
-   The IPv4 address conversion functions -- inet_ntoa() and inet_addr()
-   -- convert IPv4 addresses between binary and printable form.  These
-   functions are quite specific to 32-bit IPv4 addresses.  We have
-   designed two analogous functions that convert both IPv4 and IPv6
-   addresses, and carry an address type parameter so that they can be
-   extended to other protocol families as well.
-
-   Finally, a few miscellaneous features are needed to support IPv6.  A
-   new interface is needed to support the IPv6 hop limit header field.
-   New socket options are needed to control the sending and receiving of
-   IPv6 multicast packets.
-
-   The socket interface will be enhanced in the future to provide access
-   to other IPv6 features.  Some of these extensions are described in
-   [4].
-
-
-
-
-
-Gilligan, et al.             Informational                      [Page 5]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-2.2 Data Types
-
-   The data types of the structure elements given in this memo are
-   intended to track the relevant standards.  uintN_t means an unsigned
-   integer of exactly N bits (e.g., uint16_t).  The sa_family_t and
-   in_port_t types are defined in [3].
-
-2.3 Headers
-
-   When function prototypes and structures are shown we show the headers
-   that must be #included to cause that item to be defined.
-
-2.4 Structures
-
-   When structures are described the members shown are the ones that
-   must appear in an implementation.  Additional, nonstandard members
-   may also be defined by an implementation.  As an additional
-   precaution nonstandard members could be verified by Feature Test
-   Macros as described in [3].  (Such Feature Test Macros are not
-   defined by this RFC.)
-
-   The ordering shown for the members of a structure is the recommended
-   ordering, given alignment considerations of multibyte members, but an
-   implementation may order the members differently.
-
-3. Socket Interface
-
-   This section specifies the socket interface changes for IPv6.
-
-3.1 IPv6 Address Family and Protocol Family
-
-   A new address family name, AF_INET6, is defined in <sys/socket.h>.
-   The AF_INET6 definition distinguishes between the original
-   sockaddr_in address data structure, and the new sockaddr_in6 data
-   structure.
-
-   A new protocol family name, PF_INET6, is defined in <sys/socket.h>.
-   Like most of the other protocol family names, this will usually be
-   defined to have the same value as the corresponding address family
-   name:
-
-      #define PF_INET6        AF_INET6
-
-   The AF_INET6 is used in the first argument to the socket() function
-   to indicate that an IPv6 socket is being created.
-
-
-
-
-
-
-Gilligan, et al.             Informational                      [Page 6]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-3.2 IPv6 Address Structure
-
-   A new in6_addr structure holds a single IPv6 address and is defined
-   as a result of including <netinet/in.h>:
-
-      struct in6_addr {
-          uint8_t  s6_addr[16];      /* IPv6 address */
-      };
-
-   This data structure contains an array of sixteen 8-bit elements,
-   which make up one 128-bit IPv6 address.  The IPv6 address is stored
-   in network byte order.
-
-   The structure in6_addr above is usually implemented with an embedded
-   union with extra fields that force the desired alignment level in a
-   manner similar to BSD implementations of "struct in_addr".  Those
-   additional implementation details are omitted here for simplicity.
-
-   An example is as follows:
-
-   struct in6_addr {
-        union {
-            uint8_t  _S6_u8[16];
-            uint32_t _S6_u32[4];
-            uint64_t _S6_u64[2];
-        } _S6_un;
-   };
-   #define s6_addr _S6_un._S6_u8
-
-3.3 Socket Address Structure for 4.3BSD-Based Systems
-
-   In the socket interface, a different protocol-specific data structure
-   is defined to carry the addresses for each protocol suite.  Each
-   protocol-specific data structure is designed so it can be cast into a
-   protocol-independent data structure -- the "sockaddr" structure.
-   Each has a "family" field that overlays the "sa_family" of the
-   sockaddr data structure.  This field identifies the type of the data
-   structure.
-
-   The sockaddr_in structure is the protocol-specific address data
-   structure for IPv4.  It is used to pass addresses between
-   applications and the system in the socket functions.  The following
-   sockaddr_in6 structure holds IPv6 addresses and is defined as a
-   result of including the <netinet/in.h> header:
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                      [Page 7]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-struct sockaddr_in6 {
-    sa_family_t     sin6_family;    /* AF_INET6 */
-    in_port_t       sin6_port;      /* transport layer port # */
-    uint32_t        sin6_flowinfo;  /* IPv6 flow information */
-    struct in6_addr sin6_addr;      /* IPv6 address */
-    uint32_t        sin6_scope_id;  /* set of interfaces for a scope */
-};
-
-   This structure is designed to be compatible with the sockaddr data
-   structure used in the 4.3BSD release.
-
-   The sin6_family field identifies this as a sockaddr_in6 structure.
-   This field overlays the sa_family field when the buffer is cast to a
-   sockaddr data structure.  The value of this field must be AF_INET6.
-
-   The sin6_port field contains the 16-bit UDP or TCP port number.  This
-   field is used in the same way as the sin_port field of the
-   sockaddr_in structure.  The port number is stored in network byte
-   order.
-
-   The sin6_flowinfo field is a 32-bit field intended to contain flow-
-   related information.  The exact way this field is mapped to or from a
-   packet is not currently specified.  Until such time as its use is
-   specified, applications should set this field to zero when
-   constructing a sockaddr_in6, and ignore this field in a sockaddr_in6
-   structure constructed by the system.
-
-   The sin6_addr field is a single in6_addr structure (defined in the
-   previous section).  This field holds one 128-bit IPv6 address.  The
-   address is stored in network byte order.
-
-   The ordering of elements in this structure is specifically designed
-   so that when sin6_addr field is aligned on a 64-bit boundary, the
-   start of the structure will also be aligned on a 64-bit boundary.
-   This is done for optimum performance on 64-bit architectures.
-
-   The sin6_scope_id field is a 32-bit integer that identifies a set of
-   interfaces as appropriate for the scope [2] of the address carried in
-   the sin6_addr field.  The mapping of sin6_scope_id to an interface or
-   set of interfaces is left to implementation and future specifications
-   on the subject of scoped addresses.
-
-   Notice that the sockaddr_in6 structure will normally be larger than
-   the generic sockaddr structure.  On many existing implementations the
-   sizeof(struct sockaddr_in) equals sizeof(struct sockaddr), with both
-   being 16 bytes.  Any existing code that makes this assumption needs
-   to be examined carefully when converting to IPv6.
-
-
-
-
-Gilligan, et al.             Informational                      [Page 8]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-3.4 Socket Address Structure for 4.4BSD-Based Systems
-
-   The 4.4BSD release includes a small, but incompatible change to the
-   socket interface.  The "sa_family" field of the sockaddr data
-   structure was changed from a 16-bit value to an 8-bit value, and the
-   space saved used to hold a length field, named "sa_len".  The
-   sockaddr_in6 data structure given in the previous section cannot be
-   correctly cast into the newer sockaddr data structure.  For this
-   reason, the following alternative IPv6 address data structure is
-   provided to be used on systems based on 4.4BSD.  It is defined as a
-   result of including the <netinet/in.h> header.
-
-struct sockaddr_in6 {
-    uint8_t         sin6_len;       /* length of this struct */
-    sa_family_t     sin6_family;    /* AF_INET6 */
-    in_port_t       sin6_port;      /* transport layer port # */
-    uint32_t        sin6_flowinfo;  /* IPv6 flow information */
-    struct in6_addr sin6_addr;      /* IPv6 address */
-    uint32_t        sin6_scope_id;  /* set of interfaces for a scope */
-};
-
-   The only differences between this data structure and the 4.3BSD
-   variant are the inclusion of the length field, and the change of the
-   family field to a 8-bit data type.  The definitions of all the other
-   fields are identical to the structure defined in the previous
-   section.
-
-   Systems that provide this version of the sockaddr_in6 data structure
-   must also declare SIN6_LEN as a result of including the
-   <netinet/in.h> header.  This macro allows applications to determine
-   whether they are being built on a system that supports the 4.3BSD or
-   4.4BSD variants of the data structure.
-
-3.5 The Socket Functions
-
-   Applications call the socket() function to create a socket descriptor
-   that represents a communication endpoint.  The arguments to the
-   socket() function tell the system which protocol to use, and what
-   format address structure will be used in subsequent functions.  For
-   example, to create an IPv4/TCP socket, applications make the call:
-
-      s = socket(AF_INET, SOCK_STREAM, 0);
-
-   To create an IPv4/UDP socket, applications make the call:
-
-      s = socket(AF_INET, SOCK_DGRAM, 0);
-
-
-
-
-
-Gilligan, et al.             Informational                      [Page 9]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   Applications may create IPv6/TCP and IPv6/UDP sockets (which may also
-   handle IPv4 communication as described in section 3.7) by simply
-   using the constant AF_INET6 instead of AF_INET in the first argument.
-   For example, to create an IPv6/TCP socket, applications make the
-   call:
-
-      s = socket(AF_INET6, SOCK_STREAM, 0);
-
-   To create an IPv6/UDP socket, applications make the call:
-
-      s = socket(AF_INET6, SOCK_DGRAM, 0);
-
-   Once the application has created a AF_INET6 socket, it must use the
-   sockaddr_in6 address structure when passing addresses in to the
-   system.  The functions that the application uses to pass addresses
-   into the system are:
-
-      bind()
-      connect()
-      sendmsg()
-      sendto()
-
-   The system will use the sockaddr_in6 address structure to return
-   addresses to applications that are using AF_INET6 sockets.  The
-   functions that return an address from the system to an application
-   are:
-
-      accept()
-      recvfrom()
-      recvmsg()
-      getpeername()
-      getsockname()
-
-   No changes to the syntax of the socket functions are needed to
-   support IPv6, since all of the "address carrying" functions use an
-   opaque address pointer, and carry an address length as a function
-   argument.
-
-3.6 Compatibility with IPv4 Applications
-
-   In order to support the large base of applications using the original
-   API, system implementations must provide complete source and binary
-   compatibility with the original API.  This means that systems must
-   continue to support AF_INET sockets and the sockaddr_in address
-   structure.  Applications must be able to create IPv4/TCP and IPv4/UDP
-   sockets using the AF_INET constant in the socket() function, as
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 10]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   described in the previous section.  Applications should be able to
-   hold a combination of IPv4/TCP, IPv4/UDP, IPv6/TCP and IPv6/UDP
-   sockets simultaneously within the same process.
-
-   Applications using the original API should continue to operate as
-   they did on systems supporting only IPv4.  That is, they should
-   continue to interoperate with IPv4 nodes.
-
-3.7 Compatibility with IPv4 Nodes
-
-   The API also provides a different type of compatibility: the ability
-   for IPv6 applications to interoperate with IPv4 applications.  This
-   feature uses the IPv4-mapped IPv6 address format defined in the IPv6
-   addressing architecture specification [2].  This address format
-   allows the IPv4 address of an IPv4 node to be represented as an IPv6
-   address.  The IPv4 address is encoded into the low-order 32 bits of
-   the IPv6 address, and the high-order 96 bits hold the fixed prefix
-   0:0:0:0:0:FFFF.  IPv4-mapped addresses are written as follows:
-
-      ::FFFF:<IPv4-address>
-
-   These addresses can be generated automatically by the getaddrinfo()
-   function, as described in Section 6.1.
-
-   Applications may use AF_INET6 sockets to open TCP connections to IPv4
-   nodes, or send UDP packets to IPv4 nodes, by simply encoding the
-   destination's IPv4 address as an IPv4-mapped IPv6 address, and
-   passing that address, within a sockaddr_in6 structure, in the
-   connect() or sendto() call.  When applications use AF_INET6 sockets
-   to accept TCP connections from IPv4 nodes, or receive UDP packets
-   from IPv4 nodes, the system returns the peer's address to the
-   application in the accept(), recvfrom(), or getpeername() call using
-   a sockaddr_in6 structure encoded this way.
-
-   Few applications will likely need to know which type of node they are
-   interoperating with.  However, for those applications that do need to
-   know, the IN6_IS_ADDR_V4MAPPED() macro, defined in Section 6.4, is
-   provided.
-
-3.8 IPv6 Wildcard Address
-
-   While the bind() function allows applications to select the source IP
-   address of UDP packets and TCP connections, applications often want
-   the system to select the source address for them.  With IPv4, one
-   specifies the address as the symbolic constant INADDR_ANY (called the
-   "wildcard" address) in the bind() call, or simply omits the bind()
-   entirely.
-
-
-
-
-Gilligan, et al.             Informational                     [Page 11]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   Since the IPv6 address type is a structure (struct in6_addr), a
-   symbolic constant can be used to initialize an IPv6 address variable,
-   but cannot be used in an assignment.  Therefore systems provide the
-   IPv6 wildcard address in two forms.
-
-   The first version is a global variable named "in6addr_any" that is an
-   in6_addr structure.  The extern declaration for this variable is
-   defined in <netinet/in.h>:
-
-      extern const struct in6_addr in6addr_any;
-
-   Applications use in6addr_any similarly to the way they use INADDR_ANY
-   in IPv4.  For example, to bind a socket to port number 23, but let
-   the system select the source address, an application could use the
-   following code:
-
-      struct sockaddr_in6 sin6;
-       . . .
-      sin6.sin6_family = AF_INET6;
-      sin6.sin6_flowinfo = 0;
-      sin6.sin6_port = htons(23);
-      sin6.sin6_addr = in6addr_any;  /* structure assignment */
-       . . .
-      if (bind(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
-              . . .
-
-   The other version is a symbolic constant named IN6ADDR_ANY_INIT and
-   is defined in <netinet/in.h>.  This constant can be used to
-   initialize an in6_addr structure:
-
-      struct in6_addr anyaddr = IN6ADDR_ANY_INIT;
-
-   Note that this constant can be used ONLY at declaration time.  It can
-   not be used to assign a previously declared in6_addr structure.  For
-   example, the following code will not work:
-
-      /* This is the WRONG way to assign an unspecified address */
-      struct sockaddr_in6 sin6;
-       . . .
-      sin6.sin6_addr = IN6ADDR_ANY_INIT; /* will NOT compile */
-
-   Be aware that the IPv4 INADDR_xxx constants are all defined in host
-   byte order but the IPv6 IN6ADDR_xxx constants and the IPv6
-   in6addr_xxx externals are defined in network byte order.
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 12]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-3.9 IPv6 Loopback Address
-
-   Applications may need to send UDP packets to, or originate TCP
-   connections to, services residing on the local node.  In IPv4, they
-   can do this by using the constant IPv4 address INADDR_LOOPBACK in
-   their connect(), sendto(), or sendmsg() call.
-
-   IPv6 also provides a loopback address to contact local TCP and UDP
-   services.  Like the unspecified address, the IPv6 loopback address is
-   provided in two forms -- a global variable and a symbolic constant.
-
-   The global variable is an in6_addr structure named
-   "in6addr_loopback."  The extern declaration for this variable is
-   defined in <netinet/in.h>:
-
-      extern const struct in6_addr in6addr_loopback;
-
-   Applications use in6addr_loopback as they would use INADDR_LOOPBACK
-   in IPv4 applications (but beware of the byte ordering difference
-   mentioned at the end of the previous section).  For example, to open
-   a TCP connection to the local telnet server, an application could use
-   the following code:
-
-   struct sockaddr_in6 sin6;
-    . . .
-   sin6.sin6_family = AF_INET6;
-   sin6.sin6_flowinfo = 0;
-   sin6.sin6_port = htons(23);
-   sin6.sin6_addr = in6addr_loopback;  /* structure assignment */
-    . . .
-   if (connect(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
-           . . .
-
-   The symbolic constant is named IN6ADDR_LOOPBACK_INIT and is defined
-   in <netinet/in.h>.  It can be used at declaration time ONLY; for
-   example:
-
-      struct in6_addr loopbackaddr = IN6ADDR_LOOPBACK_INIT;
-
-   Like IN6ADDR_ANY_INIT, this constant cannot be used in an assignment
-   to a previously declared IPv6 address variable.
-
-
-
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 13]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-3.10 Portability Additions
-
-   One simple addition to the sockets API that can help application
-   writers is the "struct sockaddr_storage".  This data structure can
-   simplify writing code that is portable across multiple address
-   families and platforms.  This data structure is designed with the
-   following goals.
-
-   - Large enough to accommodate all supported protocol-specific address
-      structures.
-
-   - Aligned at an appropriate boundary so that pointers to it can be
-      cast as pointers to protocol specific address structures and used
-      to access the fields of those structures without alignment
-      problems.
-
-   The sockaddr_storage structure contains field ss_family which is of
-   type sa_family_t.  When a sockaddr_storage structure is cast to a
-   sockaddr structure, the ss_family field of the sockaddr_storage
-   structure maps onto the sa_family field of the sockaddr structure.
-   When a sockaddr_storage structure is cast as a protocol specific
-   address structure, the ss_family field maps onto a field of that
-   structure that is of type sa_family_t and that identifies the
-   protocol's address family.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 14]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   An example implementation design of such a data structure would be as
-   follows.
-
-/*
- * Desired design of maximum size and alignment
- */
-#define _SS_MAXSIZE    128  /* Implementation specific max size */
-#define _SS_ALIGNSIZE  (sizeof (int64_t))
-                         /* Implementation specific desired alignment */
-/*
- * Definitions used for sockaddr_storage structure paddings design.
- */
-#define _SS_PAD1SIZE   (_SS_ALIGNSIZE - sizeof (sa_family_t))
-#define _SS_PAD2SIZE   (_SS_MAXSIZE - (sizeof (sa_family_t) +
-                              _SS_PAD1SIZE + _SS_ALIGNSIZE))
-struct sockaddr_storage {
-    sa_family_t  ss_family;     /* address family */
-    /* Following fields are implementation specific */
-    char      __ss_pad1[_SS_PAD1SIZE];
-              /* 6 byte pad, this is to make implementation
-              /* specific pad up to alignment field that */
-              /* follows explicit in the data structure */
-    int64_t   __ss_align;     /* field to force desired structure */
-               /* storage alignment */
-    char      __ss_pad2[_SS_PAD2SIZE];
-              /* 112 byte pad to achieve desired size, */
-              /* _SS_MAXSIZE value minus size of ss_family */
-              /* __ss_pad1, __ss_align fields is 112 */
-};
-
-   The above example implementation illustrates a data structure which
-   will align on a 64-bit boundary.  An implementation-specific field
-   "__ss_align" along with "__ss_pad1" is used to force a 64-bit
-   alignment which covers proper alignment good enough for the needs of
-   sockaddr_in6 (IPv6), sockaddr_in (IPv4) address data structures.  The
-   size of padding field __ss_pad1 depends on the chosen alignment
-   boundary.  The size of padding field __ss_pad2 depends on the value
-   of overall size chosen for the total size of the structure.  This
-   size and alignment are represented in the above example by
-   implementation specific (not required) constants _SS_MAXSIZE (chosen
-   value 128) and _SS_ALIGNSIZE (with chosen value 8).  Constants
-   _SS_PAD1SIZE (derived value 6) and _SS_PAD2SIZE (derived value 112)
-   are also for illustration and not required.  The derived values
-   assume sa_family_t is 2 bytes.  The implementation specific
-   definitions and structure field names above start with an underscore
-   to denote implementation private namespace.  Portable code is not
-   expected to access or reference those fields or constants.
-
-
-
-
-Gilligan, et al.             Informational                     [Page 15]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   On implementations where the sockaddr data structure includes a
-   "sa_len" field this data structure would look like this:
-
-/*
- * Definitions used for sockaddr_storage structure paddings design.
- */
-#define _SS_PAD1SIZE (_SS_ALIGNSIZE -
-                            (sizeof (uint8_t) + sizeof (sa_family_t))
-#define _SS_PAD2SIZE (_SS_MAXSIZE -
-                            (sizeof (uint8_t) + sizeof (sa_family_t) +
-                             _SS_PAD1SIZE + _SS_ALIGNSIZE))
-struct sockaddr_storage {
-    uint8_t      ss_len;        /* address length */
-    sa_family_t  ss_family;     /* address family */
-    /* Following fields are implementation specific */
-    char         __ss_pad1[_SS_PAD1SIZE];
-                  /* 6 byte pad, this is to make implementation
-                  /* specific pad up to alignment field that */
-                  /* follows explicit in the data structure */
-    int64_t      __ss_align;  /* field to force desired structure */
-                  /* storage alignment */
-    char         __ss_pad2[_SS_PAD2SIZE];
-                  /* 112 byte pad to achieve desired size, */
-                  /* _SS_MAXSIZE value minus size of ss_len, */
-                  /* __ss_family, __ss_pad1, __ss_align fields is 112 */
-};
-
-4. Interface Identification
-
-   This API uses an interface index (a small positive integer) to
-   identify the local interface on which a multicast group is joined
-   (Section 5.2).  Additionally, the advanced API [4] uses these same
-   interface indexes to identify the interface on which a datagram is
-   received, or to specify the interface on which a datagram is to be
-   sent.
-
-   Interfaces are normally known by names such as "le0", "sl1", "ppp2",
-   and the like.  On Berkeley-derived implementations, when an interface
-   is made known to the system, the kernel assigns a unique positive
-   integer value (called the interface index) to that interface.  These
-   are small positive integers that start at 1.  (Note that 0 is never
-   used for an interface index.)  There may be gaps so that there is no
-   current interface for a particular positive interface index.
-
-   This API defines two functions that map between an interface name and
-   index, a third function that returns all the interface names and
-   indexes, and a fourth function to return the dynamic memory allocated
-   by the previous function.  How these functions are implemented is
-
-
-
-Gilligan, et al.             Informational                     [Page 16]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   left up to the implementation.  4.4BSD implementations can implement
-   these functions using the existing sysctl() function with the
-   NET_RT_IFLIST command.  Other implementations may wish to use ioctl()
-   for this purpose.
-
-4.1 Name-to-Index
-
-   The first function maps an interface name into its corresponding
-   index.
-
-      #include <net/if.h>
-
-      unsigned int  if_nametoindex(const char *ifname);
-
-   If ifname is the name of an interface, the if_nametoindex() function
-   shall return the interface index corresponding to name ifname;
-   otherwise, it shall return zero.  No errors are defined.
-
-4.2 Index-to-Name
-
-   The second function maps an interface index into its corresponding
-   name.
-
-      #include <net/if.h>
-
-      char  *if_indextoname(unsigned int ifindex, char *ifname);
-
-   When this function is called, the ifname argument shall point to a
-   buffer of at least IF_NAMESIZE bytes.  The function shall place in
-   this buffer the name of the interface with index ifindex.
-   (IF_NAMESIZE is also defined in <net/if.h> and its value includes a
-   terminating null byte at the end of the interface name.)  If ifindex
-   is an interface index, then the function shall return the value
-   supplied in ifname, which points to a buffer now containing the
-   interface name.  Otherwise, the function shall return a NULL pointer
-   and set errno to indicate the error.  If there is no interface
-   corresponding to the specified index, errno is set to ENXIO.  If
-   there was a system error (such as running out of memory), errno would
-   be set to the proper value (e.g., ENOMEM).
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 17]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-4.3 Return All Interface Names and Indexes
-
-   The if_nameindex structure holds the information about a single
-   interface and is defined as a result of including the <net/if.h>
-   header.
-
-   struct if_nameindex {
-     unsigned int   if_index;  /* 1, 2, ... */
-     char          *if_name;   /* null terminated name: "le0", ... */
-   };
-
-   The final function returns an array of if_nameindex structures, one
-   structure per interface.
-
-      #include <net/if.h>
-
-      struct if_nameindex  *if_nameindex(void);
-
-   The end of the array of structures is indicated by a structure with
-   an if_index of 0 and an if_name of NULL.  The function returns a NULL
-   pointer upon an error, and would set errno to the appropriate value.
-
-   The memory used for this array of structures along with the interface
-   names pointed to by the if_name members is obtained dynamically.
-   This memory is freed by the next function.
-
-4.4 Free Memory
-
-   The following function frees the dynamic memory that was allocated by
-   if_nameindex().
-
-      #include <net/if.h>
-
-      void  if_freenameindex(struct if_nameindex *ptr);
-
-   The ptr argument shall be a pointer that was returned by
-   if_nameindex().  After if_freenameindex() has been called, the
-   application shall not use the array of which ptr is the address.
-
-5. Socket Options
-
-   A number of new socket options are defined for IPv6.  All of these
-   new options are at the IPPROTO_IPV6 level.  That is, the "level"
-   parameter in the getsockopt() and setsockopt() calls is IPPROTO_IPV6
-   when using these options.  The constant name prefix IPV6_ is used in
-   all of the new socket options.  This serves to clearly identify these
-   options as applying to IPv6.
-
-
-
-
-Gilligan, et al.             Informational                     [Page 18]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   The declaration for IPPROTO_IPV6, the new IPv6 socket options, and
-   related constants defined in this section are obtained by including
-   the header <netinet/in.h>.
-
-5.1 Unicast Hop Limit
-
-   A new setsockopt() option controls the hop limit used in outgoing
-   unicast IPv6 packets.  The name of this option is IPV6_UNICAST_HOPS,
-   and it is used at the IPPROTO_IPV6 layer.  The following example
-   illustrates how it is used:
-
-   int  hoplimit = 10;
-
-   if (setsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
-                  (char *) &hoplimit, sizeof(hoplimit)) == -1)
-       perror("setsockopt IPV6_UNICAST_HOPS");
-
-   When the IPV6_UNICAST_HOPS option is set with setsockopt(), the
-   option value given is used as the hop limit for all subsequent
-   unicast packets sent via that socket.  If the option is not set, the
-   system selects a default value.  The integer hop limit value (called
-   x) is interpreted as follows:
-
-      x < -1:        return an error of EINVAL
-      x == -1:       use kernel default
-      0 <= x <= 255: use x
-      x >= 256:      return an error of EINVAL
-
-   The IPV6_UNICAST_HOPS option may be used with getsockopt() to
-   determine the hop limit value that the system will use for subsequent
-   unicast packets sent via that socket.  For example:
-
-      int  hoplimit;
-      socklen_t  len = sizeof(hoplimit);
-
-      if (getsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
-                     (char *) &hoplimit, &len) == -1)
-          perror("getsockopt IPV6_UNICAST_HOPS");
-      else
-          printf("Using %d for hop limit.\n", hoplimit);
-
-5.2 Sending and Receiving Multicast Packets
-
-   IPv6 applications may send multicast packets by simply specifying an
-   IPv6 multicast address as the destination address, for example in the
-   destination address argument of the sendto() function.
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 19]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   Three socket options at the IPPROTO_IPV6 layer control some of the
-   parameters for sending multicast packets.  Setting these options is
-   not required: applications may send multicast packets without using
-   these options.  The setsockopt() options for controlling the sending
-   of multicast packets are summarized below.  These three options can
-   also be used with getsockopt().
-
-      IPV6_MULTICAST_IF
-
-         Set the interface to use for outgoing multicast packets.  The
-         argument is the index of the interface to use.  If the
-         interface index is specified as zero, the system selects the
-         interface (for example, by looking up the address in a routing
-         table and using the resulting interface).
-
-         Argument type: unsigned int
-
-      IPV6_MULTICAST_HOPS
-
-         Set the hop limit to use for outgoing multicast packets.  (Note
-         a separate option - IPV6_UNICAST_HOPS - is provided to set the
-         hop limit to use for outgoing unicast packets.)
-
-         The interpretation of the argument is the same as for the
-         IPV6_UNICAST_HOPS option:
-
-            x < -1:        return an error of EINVAL
-            x == -1:       use kernel default
-            0 <= x <= 255: use x
-            x >= 256:      return an error of EINVAL
-
-            If IPV6_MULTICAST_HOPS is not set, the default is 1
-            (same as IPv4 today)
-
-         Argument type: int
-
-      IPV6_MULTICAST_LOOP
-
-         If a multicast datagram is sent to a group to which the sending
-         host itself belongs (on the outgoing interface), a copy of the
-         datagram is looped back by the IP layer for local delivery if
-         this option is set to 1.  If this option is set to 0 a copy is
-         not looped back.  Other option values return an error of
-         EINVAL.
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 20]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-         If IPV6_MULTICAST_LOOP is not set, the default is 1 (loopback;
-         same as IPv4 today).
-
-         Argument type: unsigned int
-
-   The reception of multicast packets is controlled by the two
-   setsockopt() options summarized below.  An error of EOPNOTSUPP is
-   returned if these two options are used with getsockopt().
-
-      IPV6_JOIN_GROUP
-
-         Join a multicast group on a specified local interface.
-         If the interface index is specified as 0,
-         the kernel chooses the local interface.
-         For example, some kernels look up the multicast group
-         in the normal IPv6 routing table and use the resulting
-         interface.
-
-         Argument type: struct ipv6_mreq
-
-      IPV6_LEAVE_GROUP
-
-         Leave a multicast group on a specified interface.
-         If the interface index is specified as 0, the system
-         may choose a multicast group membership to drop by
-         matching the multicast address only.
-
-         Argument type: struct ipv6_mreq
-
-   The argument type of both of these options is the ipv6_mreq
-   structure, defined as a result of including the <netinet/in.h>
-   header;
-
-   struct ipv6_mreq {
-       struct in6_addr ipv6mr_multiaddr; /* IPv6 multicast addr */
-       unsigned int    ipv6mr_interface; /* interface index */
-   };
-
-   Note that to receive multicast datagrams a process must join the
-   multicast group to which datagrams will be sent.  UDP applications
-   must also bind the UDP port to which datagrams will be sent.  Some
-   processes also bind the multicast group address to the socket, in
-   addition to the port, to prevent other datagrams destined to that
-   same port from being delivered to the socket.
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 21]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-5.3 IPV6_V6ONLY option for AF_INET6 Sockets
-
-   This socket option restricts AF_INET6 sockets to IPv6 communications
-   only.  As stated in section <3.7 Compatibility with IPv4 Nodes>,
-   AF_INET6 sockets may be used for both IPv4 and IPv6 communications.
-   Some applications may want to restrict their use of an AF_INET6
-   socket to IPv6 communications only.  For these applications the
-   IPV6_V6ONLY socket option is defined.  When this option is turned on,
-   the socket can be used to send and receive IPv6 packets only.  This
-   is an IPPROTO_IPV6 level option.  This option takes an int value.
-   This is a boolean option.  By default this option is turned off.
-
-   Here is an example of setting this option:
-
-      int on = 1;
-
-      if (setsockopt(s, IPPROTO_IPV6, IPV6_V6ONLY,
-                     (char *)&on, sizeof(on)) == -1)
-          perror("setsockopt IPV6_V6ONLY");
-      else
-          printf("IPV6_V6ONLY set\n");
-
-   Note - This option has no effect on the use of IPv4 Mapped addresses
-   which enter a node as a valid IPv6 addresses for IPv6 communications
-   as defined by Stateless IP/ICMP Translation Algorithm (SIIT) [5].
-
-   An example use of this option is to allow two versions of the same
-   server process to run on the same port, one providing service over
-   IPv6, the other providing the same service over IPv4.
-
-6. Library Functions
-
-   New library functions are needed to perform a variety of operations
-   with IPv6 addresses.  Functions are needed to lookup IPv6 addresses
-   in the Domain Name System (DNS).  Both forward lookup (nodename-to-
-   address translation) and reverse lookup (address-to-nodename
-   translation) need to be supported.  Functions are also needed to
-   convert IPv6 addresses between their binary and textual form.
-
-   We note that the two existing functions, gethostbyname() and
-   gethostbyaddr(), are left as-is.  New functions are defined to handle
-   both IPv4 and IPv6 addresses.
-
-   The commonly used function gethostbyname() is inadequate for many
-   applications, first because it provides no way for the caller to
-   specify anything about the types of addresses desired (IPv4 only,
-   IPv6 only, IPv4-mapped IPv6 are OK, etc.), and second because many
-   implementations of this function are not thread safe.  RFC 2133
-
-
-
-Gilligan, et al.             Informational                     [Page 22]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   defined a function named gethostbyname2() but this function was also
-   inadequate, first because its use required setting a global option
-   (RES_USE_INET6) when IPv6 addresses were required, and second because
-   a flag argument is needed to provide the caller with additional
-   control over the types of addresses required.  The gethostbyname2()
-   function was deprecated in RFC 2553 and is no longer part of the
-   basic API.
-
-6.1 Protocol-Independent Nodename and Service Name Translation
-
-   Nodename-to-address translation is done in a protocol-independent
-   fashion using the getaddrinfo() function.
-
-#include <sys/socket.h>
-#include <netdb.h>
-
-
-int getaddrinfo(const char *nodename, const char *servname,
-                const struct addrinfo *hints, struct addrinfo **res);
-
-void freeaddrinfo(struct addrinfo *ai);
-
-struct addrinfo {
-  int     ai_flags;     /* AI_PASSIVE, AI_CANONNAME,
-                           AI_NUMERICHOST, .. */
-  int     ai_family;    /* AF_xxx */
-  int     ai_socktype;  /* SOCK_xxx */
-  int     ai_protocol;  /* 0 or IPPROTO_xxx for IPv4 and IPv6 */
-  socklen_t  ai_addrlen;   /* length of ai_addr */
-  char   *ai_canonname; /* canonical name for nodename */
-  struct sockaddr  *ai_addr; /* binary address */
-  struct addrinfo  *ai_next; /* next structure in linked list */
-};
-
-   The getaddrinfo() function translates the name of a service location
-   (for example, a host name) and/or a service name and returns a set of
-   socket addresses and associated information to be used in creating a
-   socket with which to address the specified service.
-
-   The nodename and servname arguments are either null pointers or
-   pointers to null-terminated strings.  One or both of these two
-   arguments must be a non-null pointer.
-
-   The format of a valid name depends on the address family or families.
-   If a specific family is not given and the name could be interpreted
-   as valid within multiple supported families, the implementation will
-   attempt to resolve the name in all supported families and, in absence
-   of errors, one or more results shall be returned.
-
-
-
-Gilligan, et al.             Informational                     [Page 23]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   If the nodename argument is not null, it can be a descriptive name or
-   can be an address string.  If the specified address family is
-   AF_INET, AF_INET6, or AF_UNSPEC, valid descriptive names include host
-   names. If the specified address family is AF_INET or AF_UNSPEC,
-   address strings using Internet standard dot notation as specified in
-   inet_addr() are valid.  If the specified address family is AF_INET6
-   or AF_UNSPEC, standard IPv6 text forms described in inet_pton() are
-   valid.
-
-   If nodename is not null, the requested service location is named by
-   nodename; otherwise, the requested service location is local to the
-   caller.
-
-   If servname is null, the call shall return network-level addresses
-   for the specified nodename.  If servname is not null, it is a null-
-   terminated character string identifying the requested service.  This
-   can be either a descriptive name or a numeric representation suitable
-   for use with the address family or families.  If the specified
-   address family is AF_INET, AF_INET6 or AF_UNSPEC, the service can be
-   specified as a string specifying a decimal port number.
-
-   If the argument hints is not null, it refers to a structure
-   containing input values that may direct the operation by providing
-   options and by limiting the returned information to a specific socket
-   type, address family and/or protocol.  In this hints structure every
-   member other than ai_flags, ai_family, ai_socktype and ai_protocol
-   shall be set to zero or a null pointer.  A value of AF_UNSPEC for
-   ai_family means that the caller shall accept any address family.  A
-   value of zero for ai_socktype means that the caller shall accept any
-   socket type.  A value of zero for ai_protocol means that the caller
-   shall accept any protocol.  If hints is a null pointer, the behavior
-   shall be as if it referred to a structure containing the value zero
-   for the ai_flags, ai_socktype and ai_protocol fields, and AF_UNSPEC
-   for the ai_family field.
-
-   Note:
-
-   1. If the caller handles only TCP and not UDP, for example, then the
-      ai_protocol member of the hints structure should be set to
-      IPPROTO_TCP when getaddrinfo() is called.
-
-   2. If the caller handles only IPv4 and not IPv6, then the ai_family
-      member of the hints structure should be set to AF_INET when
-      getaddrinfo() is called.
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 24]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   The ai_flags field to which hints parameter points shall be set to
-   zero or be the bitwise-inclusive OR of one or more of the values
-   AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST, AI_NUMERICSERV,
-   AI_V4MAPPED, AI_ALL, and AI_ADDRCONFIG.
-
-   If the AI_PASSIVE flag is specified, the returned address information
-   shall be suitable for use in binding a socket for accepting incoming
-   connections for the specified service (i.e., a call to bind()).  In
-   this case, if the nodename argument is null, then the IP address
-   portion of the socket address structure shall be set to INADDR_ANY
-   for an IPv4 address or IN6ADDR_ANY_INIT for an IPv6 address.  If the
-   AI_PASSIVE flag is not specified, the returned address information
-   shall be suitable for a call to connect() (for a connection-mode
-   protocol) or for a call to connect(), sendto() or sendmsg() (for a
-   connectionless protocol).  In this case, if the nodename argument is
-   null, then the IP address portion of the socket address structure
-   shall be set to the loopback address.  This flag is ignored if the
-   nodename argument is not null.
-
-   If the AI_CANONNAME flag is specified and the nodename argument is
-   not null, the function shall attempt to determine the canonical name
-   corresponding to nodename (for example, if nodename is an alias or
-   shorthand notation for a complete name).
-
-   If the AI_NUMERICHOST flag is specified, then a non-null nodename
-   string supplied shall be a numeric host address string.  Otherwise,
-   an [EAI_NONAME] error is returned.  This flag shall prevent any type
-   of name resolution service (for example, the DNS) from being invoked.
-
-   If the AI_NUMERICSERV flag is specified, then a non-null servname
-   string supplied shall be a numeric port string.  Otherwise, an
-   [EAI_NONAME] error shall be returned.  This flag shall prevent any
-   type of name resolution service (for example, NIS+) from being
-   invoked.
-
-   If the AI_V4MAPPED flag is specified along with an ai_family of
-   AF_INET6, then getaddrinfo() shall return IPv4-mapped IPv6 addresses
-   on finding no matching IPv6 addresses (ai_addrlen shall be 16).
-
-      For example, when using the DNS, if no AAAA records are found then
-      a query is made for A records and any found are returned as IPv4-
-      mapped IPv6 addresses.
-
-   The AI_V4MAPPED flag shall be ignored unless ai_family equals
-   AF_INET6.
-
-   If the AI_ALL flag is used with the AI_V4MAPPED flag, then
-   getaddrinfo() shall return all matching IPv6 and IPv4 addresses.
-
-
-
-Gilligan, et al.             Informational                     [Page 25]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-      For example, when using the DNS, queries are made for both AAAA
-      records and A records, and getaddrinfo() returns the combined
-      results of both queries.  Any IPv4 addresses found are returned as
-      IPv4-mapped IPv6 addresses.
-
-   The AI_ALL flag without the AI_V4MAPPED flag is ignored.
-
-      Note:
-
-      When ai_family is not specified (AF_UNSPEC), AI_V4MAPPED and
-      AI_ALL flags will only be used if AF_INET6 is supported.
-
-   If the AI_ADDRCONFIG flag is specified, IPv4 addresses shall be
-   returned only if an IPv4 address is configured on the local system,
-   and IPv6 addresses shall be returned only if an IPv6 address is
-   configured on the local system.  The loopback address is not
-   considered for this case as valid as a configured address.
-
-      For example, when using the DNS, a query for AAAA records should
-      occur only if the node has at least one IPv6 address configured
-      (other than IPv6 loopback) and a query for A records should occur
-      only if the node has at least one IPv4 address configured (other
-      than the IPv4 loopback).
-
-   The ai_socktype field to which argument hints points specifies the
-   socket type for the service, as defined for socket().  If a specific
-   socket type is not given (for example, a value of zero) and the
-   service name could be interpreted as valid with multiple supported
-   socket types, the implementation shall attempt to resolve the service
-   name for all supported socket types and, in the absence of errors,
-   all possible results shall be returned.  A non-zero socket type value
-   shall limit the returned information to values with the specified
-   socket type.
-
-   If the ai_family field to which hints points has the value AF_UNSPEC,
-   addresses shall be returned for use with any address family that can
-   be used with the specified nodename and/or servname.  Otherwise,
-   addresses shall be returned for use only with the specified address
-   family.  If ai_family is not AF_UNSPEC and ai_protocol is not zero,
-   then addresses are returned for use only with the specified address
-   family and protocol; the value of ai_protocol shall be interpreted as
-   in a call to the socket() function with the corresponding values of
-   ai_family and ai_protocol.
-
-   The freeaddrinfo() function frees one or more addrinfo structures
-   returned by getaddrinfo(), along with any additional storage
-   associated with those structures (for example, storage pointed to by
-   the ai_canonname and ai_addr fields; an application must not
-
-
-
-Gilligan, et al.             Informational                     [Page 26]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   reference this storage after the associated addrinfo structure has
-   been freed).  If the ai_next field of the structure is not null, the
-   entire list of structures is freed.  The freeaddrinfo() function must
-   support the freeing of arbitrary sublists of an addrinfo list
-   originally returned by getaddrinfo().
-
-   Functions getaddrinfo() and freeaddrinfo() must be thread-safe.
-
-   A zero return value for getaddrinfo() indicates successful
-   completion; a non-zero return value indicates failure.  The possible
-   values for the failures are listed below under Error Return Values.
-
-   Upon successful return of getaddrinfo(), the location to which res
-   points shall refer to a linked list of addrinfo structures, each of
-   which shall specify a socket address and information for use in
-   creating a socket with which to use that socket address.  The list
-   shall include at least one addrinfo structure.  The ai_next field of
-   each structure contains a pointer to the next structure on the list,
-   or a null pointer if it is the last structure on the list.  Each
-   structure on the list shall include values for use with a call to the
-   socket() function, and a socket address for use with the connect()
-   function or, if the AI_PASSIVE flag was specified, for use with the
-   bind() function.  The fields ai_family, ai_socktype, and ai_protocol
-   shall be usable as the arguments to the socket() function to create a
-   socket suitable for use with the returned address.  The fields
-   ai_addr and ai_addrlen are usable as the arguments to the connect()
-   or bind() functions with such a socket, according to the AI_PASSIVE
-   flag.
-
-   If nodename is not null, and if requested by the AI_CANONNAME flag,
-   the ai_canonname field of the first returned addrinfo structure shall
-   point to a null-terminated string containing the canonical name
-   corresponding to the input nodename; if the canonical name is not
-   available, then ai_canonname shall refer to the nodename argument or
-   a string with the same contents.  The contents of the ai_flags field
-   of the returned structures are undefined.
-
-   All fields in socket address structures returned by getaddrinfo()
-   that are not filled in through an explicit argument (for example,
-   sin6_flowinfo) shall be set to zero.
-
-   Note: This makes it easier to compare socket address structures.
-
-
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 27]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   Error Return Values:
-
-   The getaddrinfo() function shall fail and return the corresponding
-   value if:
-
-   [EAI_AGAIN]     The name could not be resolved at this time.  Future
-                   attempts may succeed.
-
-   [EAI_BADFLAGS]  The flags parameter had an invalid value.
-
-   [EAI_FAIL]      A non-recoverable error occurred when attempting to
-                   resolve the name.
-
-   [EAI_FAMILY]    The address family was not recognized.
-
-   [EAI_MEMORY]    There was a memory allocation failure when trying to
-                   allocate storage for the return value.
-
-   [EAI_NONAME]    The name does not resolve for the supplied
-                   parameters.  Neither nodename nor servname were
-                   supplied.  At least one of these must be supplied.
-
-   [EAI_SERVICE]   The service passed was not recognized for the
-                   specified socket type.
-
-   [EAI_SOCKTYPE]  The intended socket type was not recognized.
-
-   [EAI_SYSTEM]    A system error occurred; the error code can be found
-                   in errno.
-
-   The gai_strerror() function provides a descriptive text string
-   corresponding to an EAI_xxx error value.
-
-      #include <netdb.h>
-
-      const char *gai_strerror(int ecode);
-
-   The argument is one of the EAI_xxx values defined for the
-   getaddrinfo() and getnameinfo() functions.  The return value points
-   to a string describing the error.  If the argument is not one of the
-   EAI_xxx values, the function still returns a pointer to a string
-   whose contents indicate an unknown error.
-
-6.2 Socket Address Structure to Node Name and Service Name
-
-   The getnameinfo() function is used to translate the contents of a
-   socket address structure to a node name and/or service name.
-
-
-
-
-Gilligan, et al.             Informational                     [Page 28]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   #include <sys/socket.h>
-   #include <netdb.h>
-
-   int getnameinfo(const struct sockaddr *sa, socklen_t salen,
-                       char *node, socklen_t nodelen,
-                       char *service, socklen_t servicelen,
-                         int flags);
-
-   The getnameinfo() function shall translate a socket address to a node
-   name and service location, all of which are defined as in
-   getaddrinfo().
-
-   The sa argument points to a socket address structure to be
-   translated.
-
-   The salen argument holds the size of the socket address structure
-   pointed to by sa.
-
-   If the socket address structure contains an IPv4-mapped IPv6 address
-   or an IPv4-compatible IPv6 address, the implementation shall extract
-   the embedded IPv4 address and lookup the node name for that IPv4
-   address.
-
-      Note: The IPv6 unspecified address ("::") and the IPv6 loopback
-      address ("::1") are not IPv4-compatible addresses.  If the address
-      is the IPv6 unspecified address ("::"), a lookup is not performed,
-      and the [EAI_NONAME] error is returned.
-
-   If the node argument is non-NULL and the nodelen argument is nonzero,
-   then the node argument points to a buffer able to contain up to
-   nodelen characters that receives the node name as a null-terminated
-   string.  If the node argument is NULL or the nodelen argument is
-   zero, the node name shall not be returned.  If the node's name cannot
-   be located, the numeric form of the node's address is returned
-   instead of its name.
-
-   If the service argument is non-NULL and the servicelen argument is
-   non-zero, then the service argument points to a buffer able to
-   contain up to servicelen bytes that receives the service name as a
-   null-terminated string.  If the service argument is NULL or the
-   servicelen argument is zero, the service name shall not be returned.
-   If the service's name cannot be located, the numeric form of the
-   service address (for example, its port number) shall be returned
-   instead of its name.
-
-   The arguments node and service cannot both be NULL.
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 29]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   The flags argument is a flag that changes the default actions of the
-   function.  By default the fully-qualified domain name (FQDN) for the
-   host shall be returned, but:
-
-   -  If the flag bit NI_NOFQDN is set, only the node name portion of
-      the FQDN shall be returned for local hosts.
-
-   -  If the flag bit NI_NUMERICHOST is set, the numeric form of the
-      host's address shall be returned instead of its name, under all
-      circumstances.
-
-   -  If the flag bit NI_NAMEREQD is set, an error shall be returned if
-      the host's name cannot be located.
-
-   -  If the flag bit NI_NUMERICSERV is set, the numeric form of the
-      service address shall be returned (for example, its port number)
-      instead of its name, under all circumstances.
-
-   -  If the flag bit NI_DGRAM is set, this indicates that the service
-      is a datagram service (SOCK_DGRAM).  The default behavior shall
-      assume that the service is a stream service (SOCK_STREAM).
-
-   Note:
-
-   1. The NI_NUMERICxxx flags are required to support the "-n" flags
-      that many commands provide.
-
-   2. The NI_DGRAM flag is required for the few AF_INET and AF_INET6
-      port numbers (for example, [512,514]) that represent different
-      services for UDP and TCP.
-
-   The getnameinfo() function shall be thread safe.
-
-   A zero return value for getnameinfo() indicates successful
-   completion; a non-zero return value indicates failure.
-
-   Upon successful completion, getnameinfo() shall return the node and
-   service names, if requested, in the buffers provided.  The returned
-   names are always null-terminated strings.
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 30]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   Error Return Values:
-
-   The getnameinfo() function shall fail and return the corresponding
-   value if:
-
-   [EAI_AGAIN]    The name could not be resolved at this time.
-                  Future attempts may succeed.
-
-   [EAI_BADFLAGS] The flags had an invalid value.
-
-   [EAI_FAIL]     A non-recoverable error occurred.
-
-   [EAI_FAMILY]   The address family was not recognized or the address
-                  length was invalid for the specified family.
-
-   [EAI_MEMORY]   There was a memory allocation failure.
-
-   [EAI_NONAME]   The name does not resolve for the supplied parameters.
-                  NI_NAMEREQD is set and the host's name cannot be
-                  located, or both nodename and servname were null.
-
-   [EAI_OVERFLOW] An argument buffer overflowed.
-
-   [EAI_SYSTEM]   A system error occurred.  The error code can be found
-                  in errno.
-
-6.3 Address Conversion Functions
-
-   The two IPv4 functions inet_addr() and inet_ntoa() convert an IPv4
-   address between binary and text form.  IPv6 applications need similar
-   functions.  The following two functions convert both IPv6 and IPv4
-   addresses:
-
-   #include <arpa/inet.h>
-
-   int inet_pton(int af, const char *src, void *dst);
-
-   const char *inet_ntop(int af, const void *src,
-                            char *dst, socklen_t size);
-
-   The inet_pton() function shall convert an address in its standard
-   text presentation form into its numeric binary form.  The af argument
-   shall specify the family of the address.  The AF_INET and AF_INET6
-   address families shall be supported.  The src argument points to the
-   string being passed in.  The dst argument points to a buffer into
-   which the function stores the numeric address; this shall be large
-   enough to hold the numeric address (32 bits for AF_INET, 128 bits for
-   AF_INET6).  The inet_pton() function shall return 1 if the conversion
-
-
-
-Gilligan, et al.             Informational                     [Page 31]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   succeeds, with the address pointed to by dst in network byte order.
-   It shall return 0 if the input is not a valid IPv4 dotted-decimal
-   string or a valid IPv6 address string, or -1 with errno set to
-   EAFNOSUPPORT if the af argument is unknown.
-
-   If the af argument of inet_pton() is AF_INET, the src string shall be
-   in the standard IPv4 dotted-decimal form:
-
-      ddd.ddd.ddd.ddd
-
-   where "ddd" is a one to three digit decimal number between 0 and 255.
-   The inet_pton() function does not accept other formats (such as the
-   octal numbers, hexadecimal numbers, and fewer than four numbers that
-   inet_addr() accepts).
-
-   If the af argument of inet_pton() is AF_INET6, the src string shall
-   be in one of the standard IPv6 text forms defined in Section 2.2 of
-   the addressing architecture specification [2].
-
-   The inet_ntop() function shall convert a numeric address into a text
-   string suitable for presentation.  The af argument shall specify the
-   family of the address.  This can be AF_INET or AF_INET6.  The src
-   argument points to a buffer holding an IPv4 address if the af
-   argument is AF_INET, or an IPv6 address if the af argument is
-   AF_INET6; the address must be in network byte order.  The dst
-   argument points to a buffer where the function stores the resulting
-   text string; it shall not be NULL.  The size argument specifies the
-   size of this buffer, which shall be large enough to hold the text
-   string (INET_ADDRSTRLEN characters for IPv4, INET6_ADDRSTRLEN
-   characters for IPv6).
-
-   In order to allow applications to easily declare buffers of the
-   proper size to store IPv4 and IPv6 addresses in string form, the
-   following two constants are defined in <netinet/in.h>:
-
-      #define INET_ADDRSTRLEN    16
-      #define INET6_ADDRSTRLEN   46
-
-   The inet_ntop() function shall return a pointer to the buffer
-   containing the text string if the conversion succeeds, and NULL
-   otherwise.  Upon failure, errno is set to EAFNOSUPPORT if the af
-   argument is invalid or ENOSPC if the size of the result buffer is
-   inadequate.
-
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 32]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-6.4 Address Testing Macros
-
-   The following macros can be used to test for special IPv6 addresses.
-
-   #include <netinet/in.h>
-
-   int  IN6_IS_ADDR_UNSPECIFIED (const struct in6_addr *);
-   int  IN6_IS_ADDR_LOOPBACK    (const struct in6_addr *);
-   int  IN6_IS_ADDR_MULTICAST   (const struct in6_addr *);
-   int  IN6_IS_ADDR_LINKLOCAL   (const struct in6_addr *);
-   int  IN6_IS_ADDR_SITELOCAL   (const struct in6_addr *);
-   int  IN6_IS_ADDR_V4MAPPED    (const struct in6_addr *);
-   int  IN6_IS_ADDR_V4COMPAT    (const struct in6_addr *);
-
-   int  IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
-   int  IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
-   int  IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
-   int  IN6_IS_ADDR_MC_ORGLOCAL (const struct in6_addr *);
-   int  IN6_IS_ADDR_MC_GLOBAL   (const struct in6_addr *);
-
-   The first seven macros return true if the address is of the specified
-   type, or false otherwise.  The last five test the scope of a
-   multicast address and return true if the address is a multicast
-   address of the specified scope or false if the address is either not
-   a multicast address or not of the specified scope.
-
-   Note that IN6_IS_ADDR_LINKLOCAL and IN6_IS_ADDR_SITELOCAL return true
-   only for the two types of local-use IPv6 unicast addresses (Link-
-   Local and Site-Local) defined in [2], and that by this definition,
-   the IN6_IS_ADDR_LINKLOCAL macro returns false for the IPv6 loopback
-   address (::1).  These two macros do not return true for IPv6
-   multicast addresses of either link-local scope or site-local scope.
-
-7. Summary of New Definitions
-
-   The following list summarizes the constants, structure, and extern
-   definitions discussed in this memo, sorted by header.
-
-<net/if.h>      IF_NAMESIZE
-<net/if.h>      struct if_nameindex{};
-
-<netdb.h>       AI_ADDRCONFIG
-<netdb.h>       AI_ALL
-<netdb.h>       AI_CANONNAME
-<netdb.h>       AI_NUMERICHOST
-<netdb.h>       AI_NUMERICSERV
-<netdb.h>       AI_PASSIVE
-<netdb.h>       AI_V4MAPPED
-
-
-
-Gilligan, et al.             Informational                     [Page 33]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-<netdb.h>       EAI_AGAIN
-<netdb.h>       EAI_BADFLAGS
-<netdb.h>       EAI_FAIL
-<netdb.h>       EAI_FAMILY
-<netdb.h>       EAI_MEMORY
-<netdb.h>       EAI_NONAME
-<netdb.h>       EAI_OVERFLOW
-<netdb.h>       EAI_SERVICE
-<netdb.h>       EAI_SOCKTYPE
-<netdb.h>       EAI_SYSTEM
-<netdb.h>       NI_DGRAM
-<netdb.h>       NI_NAMEREQD
-<netdb.h>       NI_NOFQDN
-<netdb.h>       NI_NUMERICHOST
-<netdb.h>       NI_NUMERICSERV
-<netdb.h>       struct addrinfo{};
-
-<netinet/in.h>  IN6ADDR_ANY_INIT
-<netinet/in.h>  IN6ADDR_LOOPBACK_INIT
-<netinet/in.h>  INET6_ADDRSTRLEN
-<netinet/in.h>  INET_ADDRSTRLEN
-<netinet/in.h>  IPPROTO_IPV6
-<netinet/in.h>  IPV6_JOIN_GROUP
-<netinet/in.h>  IPV6_LEAVE_GROUP
-<netinet/in.h>  IPV6_MULTICAST_HOPS
-<netinet/in.h>  IPV6_MULTICAST_IF
-<netinet/in.h>  IPV6_MULTICAST_LOOP
-<netinet/in.h>  IPV6_UNICAST_HOPS
-<netinet/in.h>  IPV6_V6ONLY
-<netinet/in.h>  SIN6_LEN
-<netinet/in.h>  extern const struct in6_addr in6addr_any;
-<netinet/in.h>  extern const struct in6_addr in6addr_loopback;
-<netinet/in.h>  struct in6_addr{};
-<netinet/in.h>  struct ipv6_mreq{};
-<netinet/in.h>  struct sockaddr_in6{};
-
-<sys/socket.h>  AF_INET6
-<sys/socket.h>  PF_INET6
-<sys/socket.h>  struct sockaddr_storage;
-
-   The following list summarizes the function and macro prototypes
-   discussed in this memo, sorted by header.
-
-<arpa/inet.h>   int inet_pton(int, const char *, void *);
-<arpa/inet.h>   const char *inet_ntop(int, const void *,
-                               char *, socklen_t);
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 34]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-<net/if.h>      char *if_indextoname(unsigned int, char *);
-<net/if.h>      unsigned int if_nametoindex(const char *);
-<net/if.h>      void if_freenameindex(struct if_nameindex *);
-<net/if.h>      struct if_nameindex *if_nameindex(void);
-
-<netdb.h>       int getaddrinfo(const char *, const char *,
-                                const struct addrinfo *,
-                                struct addrinfo **);
-<netdb.h>       int getnameinfo(const struct sockaddr *, socklen_t,
-                  char *, socklen_t, char *, socklen_t, int);
-<netdb.h>       void freeaddrinfo(struct addrinfo *);
-<netdb.h>       const char *gai_strerror(int);
-
-<netinet/in.h>  int IN6_IS_ADDR_LINKLOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_LOOPBACK(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MC_GLOBAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MC_ORGLOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MULTICAST(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_SITELOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_UNSPECIFIED(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_V4COMPAT(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_V4MAPPED(const struct in6_addr *);
-
-8. Security Considerations
-
-   IPv6 provides a number of new security mechanisms, many of which need
-   to be accessible to applications.  Companion memos detailing the
-   extensions to the socket interfaces to support IPv6 security are
-   being written.
-
-9. Changes from RFC 2553
-
-   1. Add brief description of the history of this API and its relation
-      to the Open Group/IEEE/ISO standards.
-
-   2. Alignments with [3].
-
-   3. Removed all references to getipnodebyname() and getipnodebyaddr(),
-      which are deprecated in favor of getaddrinfo() and getnameinfo().
-
-   4. Added IPV6_V6ONLY IP level socket option to permit nodes to not
-      process IPv4 packets as IPv4 Mapped addresses in implementations.
-
-   5. Added SIIT to references and added new contributors.
-
-
-
-
-Gilligan, et al.             Informational                     [Page 35]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   6. In previous versions of this specification, the sin6_flowinfo
-      field was associated with the IPv6 traffic class and flow label,
-      but its usage was not completely specified.  The complete
-      definition of the sin6_flowinfo field, including its association
-      with the traffic class or flow label, is now deferred to a future
-      specification.
-
-10. Acknowledgments
-
-   This specification's evolution and completeness were significantly
-   influenced by the efforts of Richard Stevens, who has passed on.
-   Richard's wisdom and talent made the specification what it is today.
-   The co-authors will long think of Richard with great respect.
-
-   Thanks to the many people who made suggestions and provided feedback
-   to this document, including:
-
-   Werner Almesberger, Ran Atkinson, Fred Baker, Dave Borman, Andrew
-   Cherenson, Alex Conta, Alan Cox, Steve Deering, Richard Draves,
-   Francis Dupont, Robert Elz, Brian Haberman, Jun-ichiro itojun Hagino,
-   Marc Hasson, Tom Herbert, Bob Hinden, Wan-Yen Hsu, Christian Huitema,
-   Koji Imada, Markus Jork, Ron Lee, Alan Lloyd, Charles Lynn, Dan
-   McDonald, Dave Mitton, Finnbarr Murphy, Thomas Narten, Josh Osborne,
-   Craig Partridge, Jean-Luc Richier, Bill Sommerfield, Erik Scoredos,
-   Keith Sklower, JINMEI Tatuya, Dave Thaler, Matt Thomas, Harvey
-   Thompson, Dean D. Throop, Karen Tracey, Glenn Trewitt, Paul Vixie,
-   David Waitzman, Carl Williams, Kazu Yamamoto, Vlad Yasevich, Stig
-   Venaas, and Brian Zill.
-
-   The getaddrinfo() and getnameinfo() functions are taken from an
-   earlier document by Keith Sklower.  As noted in that document,
-   William Durst, Steven Wise, Michael Karels, and Eric Allman provided
-   many useful discussions on the subject of protocol-independent name-
-   to-address translation, and reviewed early versions of Keith
-   Sklower's original proposal.  Eric Allman implemented the first
-   prototype of getaddrinfo().  The observation that specifying the pair
-   of name and service would suffice for connecting to a service
-   independent of protocol details was made by Marshall Rose in a
-   proposal to X/Open for a "Uniform Network Interface".
-
-   Craig Metz, Jack McCann, Erik Nordmark, Tim Hartrick, and Mukesh
-   Kacker made many contributions to this document.  Ramesh Govindan
-   made a number of contributions and co-authored an earlier version of
-   this memo.
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 36]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-11. References
-
-   [1]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
-        Specification", RFC 2460, December 1998.
-
-   [2]  Hinden, R. and S. Deering, "IP Version 6 Addressing
-        Architecture", RFC 2373, July 1998.
-
-   [3]  IEEE Std. 1003.1-2001 Standard for Information Technology --
-        Portable Operating System Interface (POSIX). Open Group
-        Technical Standard: Base Specifications, Issue 6, December 2001.
-        ISO/IEC 9945:2002.  http://www.opengroup.org/austin
-
-   [4]  Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6", RFC
-        2292, February 1998.
-
-   [5]  Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)",
-        RFC 2765, February 2000.
-
-   [6]  The Open Group Base Working Group
-        http://www.opengroup.org/platform/base.html
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 37]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-12. Authors' Addresses
-
-   Bob Gilligan
-   Intransa, Inc.
-   2870 Zanker Rd.
-   San Jose, CA 95134
-
-   Phone: 408-678-8647
-   EMail: gilligan@intransa.com
-
-
-   Susan Thomson
-   Cisco Systems
-   499 Thornall Street, 8th floor
-   Edison, NJ 08837
-
-   Phone: 732-635-3086
-   EMail:  sethomso@cisco.com
-
-
-   Jim Bound
-   Hewlett-Packard Company
-   110 Spitbrook Road ZKO3-3/W20
-   Nashua, NH 03062
-
-   Phone: 603-884-0062
-   EMail: Jim.Bound@hp.com
-
-
-   Jack McCann
-   Hewlett-Packard Company
-   110 Spitbrook Road ZKO3-3/W20
-   Nashua, NH 03062
-
-   Phone: 603-884-2608
-   EMail: Jack.McCann@hp.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 38]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-13. Full Copyright Statement
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 39]
-
diff --git a/contrib/bind9/doc/rfc/rfc3513.txt b/contrib/bind9/doc/rfc/rfc3513.txt
deleted file mode 100644
index 49c0fa4..0000000
--- a/contrib/bind9/doc/rfc/rfc3513.txt
+++ /dev/null
@@ -1,1459 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          R. Hinden
-Request for Comments: 3513                                         Nokia
-Obsoletes: 2373                                               S. Deering
-Category: Standards Track                                  Cisco Systems
-                                                              April 2003
-
-
-       Internet Protocol Version 6 (IPv6) Addressing Architecture
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-Abstract
-
-   This specification defines the addressing architecture of the IP
-   Version 6 (IPv6) protocol.  The document includes the IPv6 addressing
-   model, text representations of IPv6 addresses, definition of IPv6
-   unicast addresses, anycast addresses, and multicast addresses, and an
-   IPv6 node's required addresses.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                     [Page 1]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-Table of Contents
-
-   1. Introduction.................................................3
-   2. IPv6 Addressing..............................................3
-      2.1 Addressing Model.........................................4
-      2.2 Text Representation of Addresses.........................4
-      2.3 Text Representation of Address Prefixes..................5
-      2.4 Address Type Identification..............................6
-      2.5 Unicast Addresses........................................7
-          2.5.1 Interface Identifiers..............................8
-          2.5.2 The Unspecified Address............................9
-          2.5.3 The Loopback Address...............................9
-          2.5.4 Global Unicast Addresses..........................10
-          2.5.5 IPv6 Addresses with Embedded IPv4 Addresses.......10
-          2.5.6 Local-use IPv6 Unicast Addresses..................11
-      2.6 Anycast Addresses.......................................12
-          2.6.1 Required Anycast Address..........................13
-      2.7 Multicast Addresses.....................................13
-          2.7.1 Pre-Defined Multicast Addresses...................15
-      2.8 A Node's Required Addresses.............................17
-   3. Security Considerations.....................................17
-   4. IANA Considerations.........................................18
-   5. References..................................................19
-      5.1 Normative References....................................19
-      5.2 Informative References..................................19
-   APPENDIX A: Creating Modified EUI-64 format Interface IDs......21
-   APPENDIX B: Changes from RFC-2373..............................24
-   Authors' Addresses.............................................25
-   Full Copyright Statement.......................................26
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                     [Page 2]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-1.  Introduction
-
-   This specification defines the addressing architecture of the IP
-   Version 6 (IPv6) protocol.  It includes the basic formats for the
-   various types of IPv6 addresses (unicast, anycast, and multicast).
-
-   The authors would like to acknowledge the contributions of Paul
-   Francis, Scott Bradner, Jim Bound, Brian Carpenter, Matt Crawford,
-   Deborah Estrin, Roger Fajman, Bob Fink, Peter Ford, Bob Gilligan,
-   Dimitry Haskin, Tom Harsch, Christian Huitema, Tony Li, Greg
-   Minshall, Thomas Narten, Erik Nordmark, Yakov Rekhter, Bill Simpson,
-   Sue Thomson, Markku Savela, and Larry Masinter.
-
-2. IPv6 Addressing
-
-   IPv6 addresses are 128-bit identifiers for interfaces and sets of
-   interfaces (where "interface" is as defined in section 2 of [IPV6]).
-   There are three types of addresses:
-
-   Unicast:   An identifier for a single interface.  A packet sent to a
-              unicast address is delivered to the interface identified
-              by that address.
-
-   Anycast:   An identifier for a set of interfaces (typically belonging
-              to different nodes).  A packet sent to an anycast address
-              is delivered to one of the interfaces identified by that
-              address (the "nearest" one, according to the routing
-              protocols' measure of distance).
-
-   Multicast: An identifier for a set of interfaces (typically belonging
-              to different nodes).  A packet sent to a multicast address
-              is delivered to all interfaces identified by that address.
-
-   There are no broadcast addresses in IPv6, their function being
-   superseded by multicast addresses.
-
-   In this document, fields in addresses are given a specific name, for
-   example "subnet".  When this name is used with the term "ID" for
-   identifier after the name (e.g., "subnet ID"), it refers to the
-   contents of the named field.  When it is used with the term "prefix"
-   (e.g., "subnet prefix") it refers to all of the address from the left
-   up to and including this field.
-
-   In IPv6, all zeros and all ones are legal values for any field,
-   unless specifically excluded.  Specifically, prefixes may contain, or
-   end with, zero-valued fields.
-
-
-
-
-
-Hinden & Deering            Standards Track                     [Page 3]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-2.1 Addressing Model
-
-   IPv6 addresses of all types are assigned to interfaces, not nodes.
-   An IPv6 unicast address refers to a single interface.  Since each
-   interface belongs to a single node, any of that node's interfaces'
-   unicast addresses may be used as an identifier for the node.
-
-   All interfaces are required to have at least one link-local unicast
-   address (see section 2.8 for additional required addresses).  A
-   single interface may also have multiple IPv6 addresses of any type
-   (unicast, anycast, and multicast) or scope.  Unicast addresses with
-   scope greater than link-scope are not needed for interfaces that are
-   not used as the origin or destination of any IPv6 packets to or from
-   non-neighbors.  This is sometimes convenient for point-to-point
-   interfaces.  There is one exception to this addressing model:
-
-      A unicast address or a set of unicast addresses may be assigned to
-      multiple physical interfaces if the implementation treats the
-      multiple physical interfaces as one interface when presenting it
-      to the internet layer.  This is useful for load-sharing over
-      multiple physical interfaces.
-
-   Currently IPv6 continues the IPv4 model that a subnet prefix is
-   associated with one link.  Multiple subnet prefixes may be assigned
-   to the same link.
-
-2.2 Text Representation of Addresses
-
-   There are three conventional forms for representing IPv6 addresses as
-   text strings:
-
-   1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the
-      hexadecimal values of the eight 16-bit pieces of the address.
-
-      Examples:
-
-         FEDC:BA98:7654:3210:FEDC:BA98:7654:3210
-
-         1080:0:0:0:8:800:200C:417A
-
-      Note that it is not necessary to write the leading zeros in an
-      individual field, but there must be at least one numeral in every
-      field (except for the case described in 2.).
-
-   2. Due to some methods of allocating certain styles of IPv6
-      addresses, it will be common for addresses to contain long strings
-      of zero bits.  In order to make writing addresses containing zero
-      bits easier a special syntax is available to compress the zeros.
-
-
-
-Hinden & Deering            Standards Track                     [Page 4]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-      The use of "::" indicates one or more groups of 16 bits of zeros.
-      The "::" can only appear once in an address.  The "::" can also be
-      used to compress leading or trailing zeros in an address.
-
-      For example, the following addresses:
-
-         1080:0:0:0:8:800:200C:417A  a unicast address
-         FF01:0:0:0:0:0:0:101        a multicast address
-         0:0:0:0:0:0:0:1             the loopback address
-         0:0:0:0:0:0:0:0             the unspecified addresses
-
-      may be represented as:
-
-         1080::8:800:200C:417A       a unicast address
-         FF01::101                   a multicast address
-         ::1                         the loopback address
-         ::                          the unspecified addresses
-
-   3. An alternative form that is sometimes more convenient when dealing
-      with a mixed environment of IPv4 and IPv6 nodes is
-      x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of
-      the six high-order 16-bit pieces of the address, and the 'd's are
-      the decimal values of the four low-order 8-bit pieces of the
-      address (standard IPv4 representation).  Examples:
-
-         0:0:0:0:0:0:13.1.68.3
-
-         0:0:0:0:0:FFFF:129.144.52.38
-
-      or in compressed form:
-
-         ::13.1.68.3
-
-         ::FFFF:129.144.52.38
-
-2.3 Text Representation of Address Prefixes
-
-   The text representation of IPv6 address prefixes is similar to the
-   way IPv4 addresses prefixes are written in CIDR notation [CIDR].  An
-   IPv6 address prefix is represented by the notation:
-
-      ipv6-address/prefix-length
-
-   where
-
-      ipv6-address    is an IPv6 address in any of the notations listed
-                      in section 2.2.
-
-
-
-
-Hinden & Deering            Standards Track                     [Page 5]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-      prefix-length   is a decimal value specifying how many of the
-                      leftmost contiguous bits of the address comprise
-                      the prefix.
-
-   For example, the following are legal representations of the 60-bit
-   prefix 12AB00000000CD3 (hexadecimal):
-
-      12AB:0000:0000:CD30:0000:0000:0000:0000/60
-      12AB::CD30:0:0:0:0/60
-      12AB:0:0:CD30::/60
-
-   The following are NOT legal representations of the above prefix:
-
-      12AB:0:0:CD3/60   may drop leading zeros, but not trailing zeros,
-                        within any 16-bit chunk of the address
-
-      12AB::CD30/60     address to left of "/" expands to
-                        12AB:0000:0000:0000:0000:000:0000:CD30
-
-      12AB::CD3/60      address to left of "/" expands to
-                        12AB:0000:0000:0000:0000:000:0000:0CD3
-
-   When writing both a node address and a prefix of that node address
-   (e.g., the node's subnet prefix), the two can combined as follows:
-
-      the node address      12AB:0:0:CD30:123:4567:89AB:CDEF
-      and its subnet number 12AB:0:0:CD30::/60
-
-      can be abbreviated as 12AB:0:0:CD30:123:4567:89AB:CDEF/60
-
-2.4 Address Type Identification
-
-   The type of an IPv6 address is identified by the high-order bits of
-   the address, as follows:
-
-   Address type         Binary prefix        IPv6 notation   Section
-   ------------         -------------        -------------   -------
-   Unspecified          00...0  (128 bits)   ::/128          2.5.2
-   Loopback             00...1  (128 bits)   ::1/128         2.5.3
-   Multicast            11111111             FF00::/8        2.7
-   Link-local unicast   1111111010           FE80::/10       2.5.6
-   Site-local unicast   1111111011           FEC0::/10       2.5.6
-   Global unicast       (everything else)
-
-   Anycast addresses are taken from the unicast address spaces (of any
-   scope) and are not syntactically distinguishable from unicast
-   addresses.
-
-
-
-
-Hinden & Deering            Standards Track                     [Page 6]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-   The general format of global unicast addresses is described in
-   section 2.5.4.  Some special-purpose subtypes of global unicast
-   addresses which contain embedded IPv4 addresses (for the purposes of
-   IPv4-IPv6 interoperation) are described in section 2.5.5.
-
-   Future specifications may redefine one or more sub-ranges of the
-   global unicast space for other purposes, but unless and until that
-   happens, implementations must treat all addresses that do not start
-   with any of the above-listed prefixes as global unicast addresses.
-
-2.5 Unicast Addresses
-
-   IPv6 unicast addresses are aggregable with prefixes of arbitrary
-   bit-length similar to IPv4 addresses under Classless Interdomain
-   Routing.
-
-   There are several types of unicast addresses in IPv6, in particular
-   global unicast, site-local unicast, and link-local unicast.  There
-   are also some special-purpose subtypes of global unicast, such as
-   IPv6 addresses with embedded IPv4 addresses or encoded NSAP
-   addresses.  Additional address types or subtypes can be defined in
-   the future.
-
-   IPv6 nodes may have considerable or little knowledge of the internal
-   structure of the IPv6 address, depending on the role the node plays
-   (for instance, host versus router).  At a minimum, a node may
-   consider that unicast addresses (including its own) have no internal
-   structure:
-
-   |                           128 bits                              |
-   +-----------------------------------------------------------------+
-   |                          node address                           |
-   +-----------------------------------------------------------------+
-
-   A slightly sophisticated host (but still rather simple) may
-   additionally be aware of subnet prefix(es) for the link(s) it is
-   attached to, where different addresses may have different values for
-   n:
-
-   |                         n bits                 |   128-n bits   |
-   +------------------------------------------------+----------------+
-   |                   subnet prefix                | interface ID   |
-   +------------------------------------------------+----------------+
-
-   Though a very simple router may have no knowledge of the internal
-   structure of IPv6 unicast addresses, routers will more generally have
-   knowledge of one or more of the hierarchical boundaries for the
-   operation of routing protocols.  The known boundaries will differ
-
-
-
-Hinden & Deering            Standards Track                     [Page 7]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-   from router to router, depending on what positions the router holds
-   in the routing hierarchy.
-
-2.5.1 Interface Identifiers
-
-   Interface identifiers in IPv6 unicast addresses are used to identify
-   interfaces on a link.  They are required to be unique within a subnet
-   prefix.  It is recommended that the same interface identifier not be
-   assigned to different nodes on a link.  They may also be unique over
-   a broader scope.  In some cases an interface's identifier will be
-   derived directly from that interface's link-layer address.  The same
-   interface identifier may be used on multiple interfaces on a single
-   node, as long as they are attached to different subnets.
-
-   Note that the uniqueness of interface identifiers is independent of
-   the uniqueness of IPv6 addresses.  For example, a global unicast
-   address may be created with a non-global scope interface identifier
-   and a site-local address may be created with a global scope interface
-   identifier.
-
-   For all unicast addresses, except those that start with binary value
-   000, Interface IDs are required to be 64 bits long and to be
-   constructed in Modified EUI-64 format.
-
-   Modified EUI-64 format based Interface identifiers may have global
-   scope when derived from a global token (e.g., IEEE 802 48-bit MAC or
-   IEEE EUI-64 identifiers [EUI64]) or may have local scope where a
-   global token is not available (e.g., serial links, tunnel end-points,
-   etc.) or where global tokens are undesirable (e.g., temporary tokens
-   for privacy [PRIV]).
-
-   Modified EUI-64 format interface identifiers are formed by inverting
-   the "u" bit (universal/local bit in IEEE EUI-64 terminology) when
-   forming the interface identifier from IEEE EUI-64 identifiers.  In
-   the resulting Modified EUI-64 format the "u" bit is set to one (1) to
-   indicate global scope, and it is set to zero (0) to indicate local
-   scope.  The first three octets in binary of an IEEE EUI-64 identifier
-   are as follows:
-
-       0       0 0       1 1       2
-      |0       7 8       5 6       3|
-      +----+----+----+----+----+----+
-      |cccc|ccug|cccc|cccc|cccc|cccc|
-      +----+----+----+----+----+----+
-
-   written in Internet standard bit-order , where "u" is the
-   universal/local bit, "g" is the individual/group bit, and "c" are the
-   bits of the company_id.  Appendix A: "Creating Modified EUI-64 format
-
-
-
-Hinden & Deering            Standards Track                     [Page 8]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-   Interface Identifiers" provides examples on the creation of Modified
-   EUI-64 format based interface identifiers.
-
-   The motivation for inverting the "u" bit when forming an interface
-   identifier is to make it easy for system administrators to hand
-   configure non-global identifiers when hardware tokens are not
-   available.  This is expected to be case for serial links, tunnel end-
-   points, etc.  The alternative would have been for these to be of the
-   form 0200:0:0:1, 0200:0:0:2, etc., instead of the much simpler 1, 2,
-   etc.
-
-   The use of the universal/local bit in the Modified EUI-64 format
-   identifier is to allow development of future technology that can take
-   advantage of interface identifiers with global scope.
-
-   The details of forming interface identifiers are defined in the
-   appropriate "IPv6 over <link>" specification such as "IPv6 over
-   Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc.
-
-2.5.2 The Unspecified Address
-
-   The address 0:0:0:0:0:0:0:0 is called the unspecified address.  It
-   must never be assigned to any node.  It indicates the absence of an
-   address.  One example of its use is in the Source Address field of
-   any IPv6 packets sent by an initializing host before it has learned
-   its own address.
-
-   The unspecified address must not be used as the destination address
-   of IPv6 packets or in IPv6 Routing Headers.  An IPv6 packet with a
-   source address of unspecified must never be forwarded by an IPv6
-   router.
-
-2.5.3 The Loopback Address
-
-   The unicast address 0:0:0:0:0:0:0:1 is called the loopback address.
-   It may be used by a node to send an IPv6 packet to itself.  It may
-   never be assigned to any physical interface.   It is treated as
-   having link-local scope, and may be thought of as the link-local
-   unicast address of a virtual interface (typically called "the
-   loopback interface") to an imaginary link that goes nowhere.
-
-   The loopback address must not be used as the source address in IPv6
-   packets that are sent outside of a single node.  An IPv6 packet with
-   a destination address of loopback must never be sent outside of a
-   single node and must never be forwarded by an IPv6 router.  A packet
-   received on an interface with destination address of loopback must be
-   dropped.
-
-
-
-
-Hinden & Deering            Standards Track                     [Page 9]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-2.5.4 Global Unicast Addresses
-
-   The general format for IPv6 global unicast addresses is as follows:
-
-   |         n bits         |   m bits  |       128-n-m bits         |
-   +------------------------+-----------+----------------------------+
-   | global routing prefix  | subnet ID |       interface ID         |
-   +------------------------+-----------+----------------------------+
-
-   where the global routing prefix is a (typically hierarchically-
-   structured) value assigned to a site (a cluster of subnets/links),
-   the subnet ID is an identifier of a link within the site, and the
-   interface ID is as defined in section 2.5.1.
-
-   All global unicast addresses other than those that start with binary
-   000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as
-   described in section 2.5.1.  Global unicast addresses that start with
-   binary 000 have no such constraint on the size or structure of the
-   interface ID field.
-
-   Examples of global unicast addresses that start with binary 000 are
-   the IPv6 address with embedded IPv4 addresses described in section
-   2.5.5 and the IPv6 address containing encoded NSAP addresses
-   specified in [NSAP].  An example of global addresses starting with a
-   binary value other than 000 (and therefore having a 64-bit interface
-   ID field) can be found in [AGGR].
-
-2.5.5 IPv6 Addresses with Embedded IPv4 Addresses
-
-   The IPv6 transition mechanisms [TRAN] include a technique for hosts
-   and routers to dynamically tunnel IPv6 packets over IPv4 routing
-   infrastructure.  IPv6 nodes that use this technique are assigned
-   special IPv6 unicast addresses that carry a global IPv4 address in
-   the low-order 32 bits.  This type of address is termed an "IPv4-
-   compatible IPv6 address" and has the format:
-
-   |                80 bits               | 16 |      32 bits        |
-   +--------------------------------------+--------------------------+
-   |0000..............................0000|0000|    IPv4 address     |
-   +--------------------------------------+----+---------------------+
-
-   Note: The IPv4 address used in the "IPv4-compatible IPv6 address"
-   must be a globally-unique IPv4 unicast address.
-
-   A second type of IPv6 address which holds an embedded IPv4 address is
-   also defined.  This address type is used to represent the addresses
-   of IPv4 nodes as IPv6 addresses.  This type of address is termed an
-   "IPv4-mapped IPv6 address" and has the format:
-
-
-
-Hinden & Deering            Standards Track                    [Page 10]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-   |                80 bits               | 16 |      32 bits        |
-   +--------------------------------------+--------------------------+
-   |0000..............................0000|FFFF|    IPv4 address     |
-   +--------------------------------------+----+---------------------+
-
-2.5.6 Local-Use IPv6 Unicast Addresses
-
-   There are two types of local-use unicast addresses defined.  These
-   are Link-Local and Site-Local.  The Link-Local is for use on a single
-   link and the Site-Local is for use in a single site.  Link-Local
-   addresses have the following format:
-
-   |   10     |
-   |  bits    |         54 bits         |          64 bits           |
-   +----------+-------------------------+----------------------------+
-   |1111111010|           0             |       interface ID         |
-   +----------+-------------------------+----------------------------+
-
-   Link-Local addresses are designed to be used for addressing on a
-   single link for purposes such as automatic address configuration,
-   neighbor discovery, or when no routers are present.
-
-   Routers must not forward any packets with link-local source or
-   destination addresses to other links.
-
-   Site-Local addresses have the following format:
-
-   |   10     |
-   |  bits    |         54 bits         |         64 bits            |
-   +----------+-------------------------+----------------------------+
-   |1111111011|        subnet ID        |       interface ID         |
-   +----------+-------------------------+----------------------------+
-
-   Site-local addresses are designed to be used for addressing inside of
-   a site without the need for a global prefix.  Although a subnet ID
-   may be up to 54-bits long, it is expected that globally-connected
-   sites will use the same subnet IDs for site-local and global
-   prefixes.
-
-   Routers must not forward any packets with site-local source or
-   destination addresses outside of the site.
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 11]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-2.6 Anycast Addresses
-
-   An IPv6 anycast address is an address that is assigned to more than
-   one interface (typically belonging to different nodes), with the
-   property that a packet sent to an anycast address is routed to the
-   "nearest" interface having that address, according to the routing
-   protocols' measure of distance.
-
-   Anycast addresses are allocated from the unicast address space, using
-   any of the defined unicast address formats.  Thus, anycast addresses
-   are syntactically indistinguishable from unicast addresses.  When a
-   unicast address is assigned to more than one interface, thus turning
-   it into an anycast address, the nodes to which the address is
-   assigned must be explicitly configured to know that it is an anycast
-   address.
-
-   For any assigned anycast address, there is a longest prefix P of that
-   address that identifies the topological region in which all
-   interfaces belonging to that anycast address reside.  Within the
-   region identified by P, the anycast address must be maintained as a
-   separate entry in the routing system (commonly referred to as a "host
-   route"); outside the region identified by P, the anycast address may
-   be aggregated into the routing entry for prefix P.
-
-   Note that in the worst case, the prefix P of an anycast set may be
-   the null prefix, i.e., the members of the set may have no topological
-   locality.  In that case, the anycast address must be maintained as a
-   separate routing entry throughout the entire internet, which presents
-   a severe scaling limit on how many such "global" anycast sets may be
-   supported.  Therefore, it is expected that support for global anycast
-   sets may be unavailable or very restricted.
-
-   One expected use of anycast addresses is to identify the set of
-   routers belonging to an organization providing internet service.
-   Such addresses could be used as intermediate addresses in an IPv6
-   Routing header, to cause a packet to be delivered via a particular
-   service provider or sequence of service providers.
-
-   Some other possible uses are to identify the set of routers attached
-   to a particular subnet, or the set of routers providing entry into a
-   particular routing domain.
-
-   There is little experience with widespread, arbitrary use of internet
-   anycast addresses, and some known complications and hazards when
-   using them in their full generality [ANYCST].  Until more experience
-   has been gained and solutions are specified, the following
-   restrictions are imposed on IPv6 anycast addresses:
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 12]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-   o  An anycast address must not be used as the source address of an
-      IPv6 packet.
-
-   o  An anycast address must not be assigned to an IPv6 host, that is,
-      it may be assigned to an IPv6 router only.
-
-2.6.1 Required Anycast Address
-
-   The Subnet-Router anycast address is predefined.  Its format is as
-   follows:
-
-   |                         n bits                 |   128-n bits   |
-   +------------------------------------------------+----------------+
-   |                   subnet prefix                | 00000000000000 |
-   +------------------------------------------------+----------------+
-
-   The "subnet prefix" in an anycast address is the prefix which
-   identifies a specific link.  This anycast address is syntactically
-   the same as a unicast address for an interface on the link with the
-   interface identifier set to zero.
-
-   Packets sent to the Subnet-Router anycast address will be delivered
-   to one router on the subnet.  All routers are required to support the
-   Subnet-Router anycast addresses for the subnets to which they have
-   interfaces.
-
-   The subnet-router anycast address is intended to be used for
-   applications where a node needs to communicate with any one of the
-   set of routers.
-
-2.7 Multicast Addresses
-
-   An IPv6 multicast address is an identifier for a group of interfaces
-   (typically on different nodes).  An interface may belong to any
-   number of multicast groups.  Multicast addresses have the following
-   format:
-
-   |   8    |  4 |  4 |                  112 bits                   |
-   +------ -+----+----+---------------------------------------------+
-   |11111111|flgs|scop|                  group ID                   |
-   +--------+----+----+---------------------------------------------+
-
-         binary 11111111 at the start of the address identifies the
-         address as being a multicast address.
-
-                                       +-+-+-+-+
-         flgs is a set of 4 flags:     |0|0|0|T|
-                                       +-+-+-+-+
-
-
-
-Hinden & Deering            Standards Track                    [Page 13]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-            The high-order 3 flags are reserved, and must be initialized
-            to 0.
-
-            T = 0 indicates a permanently-assigned ("well-known")
-            multicast address, assigned by the Internet Assigned Number
-            Authority (IANA).
-
-            T = 1 indicates a non-permanently-assigned ("transient")
-            multicast address.
-
-         scop is a 4-bit multicast scope value used to limit the scope
-         of the multicast group.  The values are:
-
-            0  reserved
-            1  interface-local scope
-            2  link-local scope
-            3  reserved
-            4  admin-local scope
-            5  site-local scope
-            6  (unassigned)
-            7  (unassigned)
-            8  organization-local scope
-            9  (unassigned)
-            A  (unassigned)
-            B  (unassigned)
-            C  (unassigned)
-            D  (unassigned)
-            E  global scope
-            F  reserved
-
-            interface-local scope spans only a single interface on a
-            node, and is useful only for loopback transmission of
-            multicast.
-
-            link-local and site-local multicast scopes span the same
-            topological regions as the corresponding unicast scopes.
-
-            admin-local scope is the smallest scope that must be
-            administratively configured, i.e., not automatically derived
-            from physical connectivity or other, non- multicast-related
-            configuration.
-
-            organization-local scope is intended to span multiple sites
-            belonging to a single organization.
-
-            scopes labeled "(unassigned)" are available for
-            administrators to define additional multicast regions.
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 14]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-         group ID identifies the multicast group, either permanent or
-         transient, within the given scope.
-
-   The "meaning" of a permanently-assigned multicast address is
-   independent of the scope value.  For example, if the "NTP servers
-   group" is assigned a permanent multicast address with a group ID of
-   101 (hex), then:
-
-      FF01:0:0:0:0:0:0:101 means all NTP servers on the same interface
-      (i.e., the same node) as the sender.
-
-      FF02:0:0:0:0:0:0:101 means all NTP servers on the same link as the
-      sender.
-
-      FF05:0:0:0:0:0:0:101 means all NTP servers in the same site as the
-      sender.
-
-      FF0E:0:0:0:0:0:0:101 means all NTP servers in the internet.
-
-   Non-permanently-assigned multicast addresses are meaningful only
-   within a given scope.  For example, a group identified by the non-
-   permanent, site-local multicast address FF15:0:0:0:0:0:0:101 at one
-   site bears no relationship to a group using the same address at a
-   different site, nor to a non-permanent group using the same group ID
-   with different scope, nor to a permanent group with the same group
-   ID.
-
-   Multicast addresses must not be used as source addresses in IPv6
-   packets or appear in any Routing header.
-
-   Routers must not forward any multicast packets beyond of the scope
-   indicated by the scop field in the destination multicast address.
-
-   Nodes must not originate a packet to a multicast address whose scop
-   field contains the reserved value 0; if such a packet is received, it
-   must be silently dropped.  Nodes should not originate a packet to a
-   multicast address whose scop field contains the reserved value F; if
-   such a packet is sent or received, it must be treated the same as
-   packets destined to a global (scop E) multicast address.
-
-2.7.1 Pre-Defined Multicast Addresses
-
-   The following well-known multicast addresses are pre-defined.  The
-   group ID's defined in this section are defined for explicit scope
-   values.
-
-   Use of these group IDs for any other scope values, with the T flag
-   equal to 0, is not allowed.
-
-
-
-Hinden & Deering            Standards Track                    [Page 15]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-      Reserved Multicast Addresses:   FF00:0:0:0:0:0:0:0
-                                      FF01:0:0:0:0:0:0:0
-                                      FF02:0:0:0:0:0:0:0
-                                      FF03:0:0:0:0:0:0:0
-                                      FF04:0:0:0:0:0:0:0
-                                      FF05:0:0:0:0:0:0:0
-                                      FF06:0:0:0:0:0:0:0
-                                      FF07:0:0:0:0:0:0:0
-                                      FF08:0:0:0:0:0:0:0
-                                      FF09:0:0:0:0:0:0:0
-                                      FF0A:0:0:0:0:0:0:0
-                                      FF0B:0:0:0:0:0:0:0
-                                      FF0C:0:0:0:0:0:0:0
-                                      FF0D:0:0:0:0:0:0:0
-                                      FF0E:0:0:0:0:0:0:0
-                                      FF0F:0:0:0:0:0:0:0
-
-   The above multicast addresses are reserved and shall never be
-   assigned to any multicast group.
-
-      All Nodes Addresses:    FF01:0:0:0:0:0:0:1
-                              FF02:0:0:0:0:0:0:1
-
-   The above multicast addresses identify the group of all IPv6 nodes,
-   within scope 1 (interface-local) or 2 (link-local).
-
-      All Routers Addresses:   FF01:0:0:0:0:0:0:2
-                               FF02:0:0:0:0:0:0:2
-                               FF05:0:0:0:0:0:0:2
-
-   The above multicast addresses identify the group of all IPv6 routers,
-   within scope 1 (interface-local), 2 (link-local), or 5 (site-local).
-
-      Solicited-Node Address:  FF02:0:0:0:0:1:FFXX:XXXX
-
-   Solicited-node multicast address are computed as a function of a
-   node's unicast and anycast addresses.  A solicited-node multicast
-   address is formed by taking the low-order 24 bits of an address
-   (unicast or anycast) and appending those bits to the prefix
-   FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the
-   range
-
-      FF02:0:0:0:0:1:FF00:0000
-
-   to
-
-      FF02:0:0:0:0:1:FFFF:FFFF
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 16]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-   For example, the solicited node multicast address corresponding to
-   the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C.  IPv6
-   addresses that differ only in the high-order bits, e.g., due to
-   multiple high-order prefixes associated with different aggregations,
-   will map to the same solicited-node address thereby, reducing the
-   number of multicast addresses a node must join.
-
-   A node is required to compute and join (on the appropriate interface)
-   the associated Solicited-Node multicast addresses for every unicast
-   and anycast address it is assigned.
-
-2.8 A Node's Required Addresses
-
-   A host is required to recognize the following addresses as
-   identifying itself:
-
-      o  Its required Link-Local Address for each interface.
-      o  Any additional Unicast and Anycast Addresses that have been
-         configured for the node's interfaces (manually or
-         automatically).
-      o  The loopback address.
-      o  The All-Nodes Multicast Addresses defined in section 2.7.1.
-      o  The Solicited-Node Multicast Address for each of its unicast
-         and anycast addresses.
-      o  Multicast Addresses of all other groups to which the node
-         belongs.
-
-   A router is required to recognize all addresses that a host is
-   required to recognize, plus the following addresses as identifying
-   itself:
-
-      o  The Subnet-Router Anycast Addresses for all interfaces for
-         which it is configured to act as a router.
-      o  All other Anycast Addresses with which the router has been
-         configured.
-      o  The All-Routers Multicast Addresses defined in section 2.7.1.
-
-3. Security Considerations
-
-   IPv6 addressing documents do not have any direct impact on Internet
-   infrastructure security.  Authentication of IPv6 packets is defined
-   in [AUTH].
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 17]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-4. IANA Considerations
-
-   The table and notes at http://www.isi.edu/in-
-   notes/iana/assignments/ipv6-address-space.txt should be replaced with
-   the following:
-
-   INTERNET PROTOCOL VERSION 6 ADDRESS SPACE
-
-   The initial assignment of IPv6 address space is as follows:
-
-   Allocation                            Prefix         Fraction of
-                                         (binary)       Address Space
-   -----------------------------------   --------       -------------
-   Unassigned (see Note 1 below)         0000 0000      1/256
-   Unassigned                            0000 0001      1/256
-   Reserved for NSAP Allocation          0000 001       1/128 [RFC1888]
-   Unassigned                            0000 01        1/64
-   Unassigned                            0000 1         1/32
-   Unassigned                            0001           1/16
-   Global Unicast                        001            1/8   [RFC2374]
-   Unassigned                            010            1/8
-   Unassigned                            011            1/8
-   Unassigned                            100            1/8
-   Unassigned                            101            1/8
-   Unassigned                            110            1/8
-   Unassigned                            1110           1/16
-   Unassigned                            1111 0         1/32
-   Unassigned                            1111 10        1/64
-   Unassigned                            1111 110       1/128
-   Unassigned                            1111 1110 0    1/512
-   Link-Local Unicast Addresses          1111 1110 10   1/1024
-   Site-Local Unicast Addresses          1111 1110 11   1/1024
-   Multicast Addresses                   1111 1111      1/256
-
-   Notes:
-
-   1. The "unspecified address", the "loopback address", and the IPv6
-      Addresses with Embedded IPv4 Addresses are assigned out of the
-      0000 0000 binary prefix space.
-
-   2. For now, IANA should limit its allocation of IPv6 unicast address
-      space to the range of addresses that start with binary value 001.
-      The rest of the global unicast address space (approximately 85% of
-      the IPv6 address space) is reserved for future definition and use,
-      and is not to be assigned by IANA at this time.
-
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 18]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-5.  References
-
-5.1  Normative References
-
-   [IPV6]    Deering, S. and R. Hinden, "Internet Protocol, Version 6
-             (IPv6) Specification", RFC 2460, December 1998.
-
-   [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
-             3", BCP 9 , RFC 2026, October 1996.
-
-5.2  Informative References
-
-   [ANYCST]  Partridge, C., Mendez, T. and W. Milliken, "Host Anycasting
-             Service", RFC 1546, November 1993.
-
-   [AUTH]    Kent, S. and R. Atkinson, "IP Authentication Header", RFC
-             2402, November 1998.
-
-   [AGGR]    Hinden, R., O'Dell, M. and S. Deering, "An Aggregatable
-             Global Unicast Address Format", RFC 2374, July 1998.
-
-   [CIDR]    Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless
-             Inter-Domain Routing (CIDR): An Address Assignment and
-             Aggregation Strategy", RFC 1519, September 1993.
-
-   [ETHER]   Crawford, M., "Transmission of IPv6 Packets over Ethernet
-             Networks", RFC 2464, December 1998.
-
-   [EUI64]   IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
-             Registration Authority",
-             http://standards.ieee.org/regauth/oui/tutorials/EUI64.html,
-             March 1997.
-
-   [FDDI]    Crawford, M., "Transmission of IPv6 Packets over FDDI
-             Networks", RFC 2467, December 1998.
-
-   [MASGN]   Hinden, R. and S. Deering, "IPv6 Multicast Address
-             Assignments", RFC 2375, July 1998.
-
-   [NSAP]    Bound, J., Carpenter, B., Harrington, D., Houldsworth, J.
-             and A. Lloyd, "OSI NSAPs and IPv6", RFC 1888, August 1996.
-
-   [PRIV]    Narten, T. and R. Draves, "Privacy Extensions for Stateless
-             Address Autoconfiguration in IPv6", RFC 3041, January 2001.
-
-   [TOKEN]   Crawford, M., Narten, T. and S. Thomas, "Transmission of
-             IPv6 Packets over Token Ring Networks", RFC 2470, December
-             1998.
-
-
-
-Hinden & Deering            Standards Track                    [Page 19]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-   [TRAN]    Gilligan, R. and E. Nordmark, "Transition Mechanisms for
-             IPv6 Hosts and Routers", RFC 2893, August 2000.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 20]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-APPENDIX A: Creating Modified EUI-64 format Interface Identifiers
-
-   Depending on the characteristics of a specific link or node there are
-   a number of approaches for creating Modified EUI-64 format interface
-   identifiers.  This appendix describes some of these approaches.
-
-Links or Nodes with IEEE EUI-64 Identifiers
-
-   The only change needed to transform an IEEE EUI-64 identifier to an
-   interface identifier is to invert the "u" (universal/local) bit.  For
-   example, a globally unique IEEE EUI-64 identifier of the form:
-
-   |0              1|1              3|3              4|4              6|
-   |0              5|6              1|2              7|8              3|
-   +----------------+----------------+----------------+----------------+
-   |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
-   +----------------+----------------+----------------+----------------+
-
-   where "c" are the bits of the assigned company_id, "0" is the value
-   of the universal/local bit to indicate global scope, "g" is
-   individual/group bit, and "m" are the bits of the manufacturer-
-   selected extension identifier.  The IPv6 interface identifier would
-   be of the form:
-
-   |0              1|1              3|3              4|4              6|
-   |0              5|6              1|2              7|8              3|
-   +----------------+----------------+----------------+----------------+
-   |cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
-   +----------------+----------------+----------------+----------------+
-
-   The only change is inverting the value of the universal/local bit.
-
-Links or Nodes with IEEE 802 48 bit MAC's
-
-   [EUI64] defines a method to create a IEEE EUI-64 identifier from an
-   IEEE 48bit MAC identifier.  This is to insert two octets, with
-   hexadecimal values of 0xFF and 0xFE, in the middle of the 48 bit MAC
-   (between the company_id and vendor supplied id).  For example, the 48
-   bit IEEE MAC with global scope:
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 21]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-   |0              1|1              3|3              4|
-   |0              5|6              1|2              7|
-   +----------------+----------------+----------------+
-   |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|
-   +----------------+----------------+----------------+
-
-   where "c" are the bits of the assigned company_id, "0" is the value
-   of the universal/local bit to indicate global scope, "g" is
-   individual/group bit, and "m" are the bits of the manufacturer-
-   selected extension identifier.  The interface identifier would be of
-   the form:
-
-   |0              1|1              3|3              4|4              6|
-   |0              5|6              1|2              7|8              3|
-   +----------------+----------------+----------------+----------------+
-   |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm|
-   +----------------+----------------+----------------+----------------+
-
-   When IEEE 802 48bit MAC addresses are available (on an interface or a
-   node), an implementation may use them to create interface identifiers
-   due to their availability and uniqueness properties.
-
-Links with Other Kinds of Identifiers
-
-   There are a number of types of links that have link-layer interface
-   identifiers other than IEEE EIU-64 or IEEE 802 48-bit MACs.  Examples
-   include LocalTalk and Arcnet.  The method to create an Modified EUI-
-   64 format identifier is to take the link identifier (e.g., the
-   LocalTalk 8 bit node identifier) and zero fill it to the left.  For
-   example, a LocalTalk 8 bit node identifier of hexadecimal value 0x4F
-   results in the following interface identifier:
-
-   |0              1|1              3|3              4|4              6|
-   |0              5|6              1|2              7|8              3|
-   +----------------+----------------+----------------+----------------+
-   |0000000000000000|0000000000000000|0000000000000000|0000000001001111|
-   +----------------+----------------+----------------+----------------+
-
-   Note that this results in the universal/local bit set to "0" to
-   indicate local scope.
-
-Links without Identifiers
-
-   There are a number of links that do not have any type of built-in
-   identifier.  The most common of these are serial links and configured
-   tunnels.  Interface identifiers must be chosen that are unique within
-   a subnet-prefix.
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 22]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-   When no built-in identifier is available on a link the preferred
-   approach is to use a global interface identifier from another
-   interface or one which is assigned to the node itself.  When using
-   this approach no other interface connecting the same node to the same
-   subnet-prefix may use the same identifier.
-
-   If there is no global interface identifier available for use on the
-   link the implementation needs to create a local-scope interface
-   identifier.  The only requirement is that it be unique within a
-   subnet prefix.  There are many possible approaches to select a
-   subnet-prefix-unique interface identifier.  These include:
-
-      Manual Configuration
-      Node Serial Number
-      Other node-specific token
-
-   The subnet-prefix-unique interface identifier should be generated in
-   a manner that it does not change after a reboot of a node or if
-   interfaces are added or deleted from the node.
-
-   The selection of the appropriate algorithm is link and implementation
-   dependent.  The details on forming interface identifiers are defined
-   in the appropriate "IPv6 over <link>" specification.  It is strongly
-   recommended that a collision detection algorithm be implemented as
-   part of any automatic algorithm.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 23]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-APPENDIX B: Changes from RFC-2373
-
-   The following changes were made from RFC-2373 "IP Version 6
-   Addressing Architecture":
-
-   -  Clarified text in section 2.2 to allow "::" to represent one or
-      more groups of 16 bits of zeros.
-   -  Changed uniqueness requirement of Interface Identifiers from
-      unique on a link to unique within a subnet prefix.  Also added a
-      recommendation that the same interface identifier not be assigned
-      to different machines on a link.
-   -  Change site-local format to make the subnet ID field 54-bit long
-      and remove the 38-bit zero's field.
-   -  Added description of multicast scop values and rules to handle the
-      reserved scop value 0.
-   -  Revised sections 2.4 and 2.5.6 to simplify and clarify how
-      different address types  are identified.  This was done to insure
-      that implementations do not build in any knowledge about global
-      unicast format prefixes.  Changes include:
-         o  Removed Format Prefix (FP) terminology
-         o  Revised list of address types to only include exceptions to
-            global unicast and a singe entry that identifies everything
-            else as Global Unicast.
-         o  Removed list of defined prefix exceptions from section 2.5.6
-            as it is now the main part of section 2.4.
-   -  Clarified text relating to EUI-64 identifiers to distinguish
-      between IPv6's "Modified EUI-64 format" identifiers and IEEE EUI-
-      64 identifiers.
-   -  Combined the sections on the Global Unicast Addresses and NSAP
-      Addresses into a single section on Global Unicast Addresses,
-      generalized the Global Unicast format, and cited [AGGR] and [NSAP]
-      as examples.
-   -  Reordered sections 2.5.4 and 2.5.5.
-   -  Removed section 2.7.2 Assignment of New IPv6 Multicast Addresses
-      because this is being redefined elsewhere.
-   -  Added an IANA considerations section that updates the IANA IPv6
-      address allocations and documents the NSAP and AGGR allocations.
-   -  Added clarification that the "IPv4-compatible IPv6 address" must
-      use global IPv4 unicast addresses.
-   -  Divided references in to normative and non-normative sections.
-   -  Added reference to [PRIV] in section 2.5.1
-   -  Added clarification that routers must not forward multicast
-      packets outside of the scope indicated in the multicast address.
-   -  Added clarification that routers must not forward packets with
-       source address of the unspecified address.
-   -  Added clarification that routers must drop packets received on an
-      interface with destination address of loopback.
-   -  Clarified the definition of IPv4-mapped addresses.
-
-
-
-Hinden & Deering            Standards Track                    [Page 24]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-   -  Removed the ABNF Description of Text Representations Appendix.
-   -  Removed the address block reserved for IPX addresses.
-   -  Multicast scope changes:
-         o  Changed name of scope value 1 from "node-local" to
-            "interface-local"
-         o  Defined scope value 4 as "admin-local"
-   -  Corrected reference to RFC1933 and updated references.
-   -  Many small changes to clarify and make the text more consistent.
-
-Authors' Addresses
-
-   Robert M. Hinden
-   Nokia
-   313 Fairchild Drive
-   Mountain View, CA 94043
-   USA
-
-   Phone: +1 650 625-2004
-   EMail: hinden@iprg.nokia.com
-
-
-   Stephen E. Deering
-   Cisco Systems, Inc.
-   170 West Tasman Drive
-   San Jose, CA 95134-1706
-   USA
-
-   Phone: +1 408 527-8213
-   EMail: deering@cisco.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 25]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 26]
-
diff --git a/contrib/bind9/doc/rfc/rfc3596.txt b/contrib/bind9/doc/rfc/rfc3596.txt
deleted file mode 100644
index f65690c..0000000
--- a/contrib/bind9/doc/rfc/rfc3596.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         S. Thomson
-Request for Comments: 3596                                         Cisco
-Obsoletes: 3152, 1886                                         C. Huitema
-Category: Standards Track                                      Microsoft
-                                                              V. Ksinant
-                                                                   6WIND
-                                                              M. Souissi
-                                                                   AFNIC
-                                                            October 2003
-
-
-                 DNS Extensions to Support IP Version 6
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-Abstract
-
-   This document defines the changes that need to be made to the Domain
-   Name System (DNS) to support hosts running IP version 6 (IPv6).  The
-   changes include a resource record type to store an IPv6 address, a
-   domain to support lookups based on an IPv6 address, and updated
-   definitions of existing query types that return Internet addresses as
-   part of additional section processing.  The extensions are designed
-   to be compatible with existing applications and, in particular, DNS
-   implementations themselves.
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
-   2.  New resource record definition and domain. . . . . . . . . . .  2
-       2.1.  AAAA record type . . . . . . . . . . . . . . . . . . . .  3
-       2.2.  AAAA data format . . . . . . . . . . . . . . . . . . . .  3
-       2.3.  AAAA query . . . . . . . . . . . . . . . . . . . . . . .  3
-       2.4.  Textual format of AAAA records . . . . . . . . . . . . .  3
-       2.5.  IP6.ARPA domain. . . . . . . . . . . . . . . . . . . . .  3
-   3.  Modifications to existing query types. . . . . . . . . . . . .  4
-   4.  Security Considerations. . . . . . . . . . . . . . . . . . . .  4
-   5.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . .  4
-
-
-
-Thomson, et al.             Standards Track                     [Page 1]
-
-RFC 3596             DNS Extensions to Support IPv6         October 2003
-
-
-   6.  Intellectual Property Statement. . . . . . . . . . . . . . . .  4
-   Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . .  5
-   Appendix A: Changes from RFC 1886. . . . . . . . . . . . . . . . .  6
-   Normative References . . . . . . . . . . . . . . . . . . . . . . .  6
-   Informative References . . . . . . . . . . . . . . . . . . . . . .  6
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  7
-   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . .  8
-
-1. Introduction
-
-   Current support for the storage of Internet addresses in the Domain
-   Name System (DNS) [1,2] cannot easily be extended to support IPv6
-   addresses [3] since applications assume that address queries return
-   32-bit IPv4 addresses only.
-
-   To support the storage of IPv6 addresses in the DNS, this document
-   defines the following extensions:
-
-      o A resource record type is defined to map a domain name to an
-        IPv6 address.
-
-      o A domain is defined to support lookups based on address.
-
-      o Existing queries that perform additional section processing to
-        locate IPv4 addresses are redefined to perform additional
-        section processing on both IPv4 and IPv6 addresses.
-
-   The changes are designed to be compatible with existing software.
-   The existing support for IPv4 addresses is retained.  Transition
-   issues related to the co-existence of both IPv4 and IPv6 addresses in
-   the DNS are discussed in [4].
-
-   The IP protocol version used for querying resource records is
-   independent of the protocol version of the resource records; e.g.,
-   IPv4 transport can be used to query IPv6 records and vice versa.
-
-   This document combines RFC 1886 [5] and changes to RFC 1886 made by
-   RFC 3152 [6], obsoleting both.  Changes mainly consist in replacing
-   the IP6.INT domain by IP6.ARPA as defined in RFC 3152.
-
-2. New resource record definition and domain
-
-   A record type is defined to store a host's IPv6 address.  A host that
-   has more than one IPv6 address must have more than one such record.
-
-
-
-
-
-
-
-Thomson, et al.             Standards Track                     [Page 2]
-
-RFC 3596             DNS Extensions to Support IPv6         October 2003
-
-
-2.1 AAAA record type
-
-   The AAAA resource record type is a record specific to the Internet
-   class that stores a single IPv6 address.
-
-   The IANA assigned value of the type is 28 (decimal).
-
-2.2 AAAA data format
-
-   A 128 bit IPv6 address is encoded in the data portion of an AAAA
-   resource record in network byte order (high-order byte first).
-
-2.3 AAAA query
-
-   An AAAA query for a specified domain name in the Internet class
-   returns all associated AAAA resource records in the answer section of
-   a response.
-
-   A type AAAA query does not trigger additional section processing.
-
-2.4 Textual format of AAAA records
-
-   The textual representation of the data portion of the AAAA resource
-   record used in a master database file is the textual representation
-   of an IPv6 address as defined in [3].
-
-2.5 IP6.ARPA Domain
-
-   A special domain is defined to look up a record given an IPv6
-   address.  The intent of this domain is to provide a way of mapping an
-   IPv6 address to a host name, although it may be used for other
-   purposes as well.  The domain is rooted at IP6.ARPA.
-
-   An IPv6 address is represented as a name in the IP6.ARPA domain by a
-   sequence of nibbles separated by dots with the suffix ".IP6.ARPA".
-   The sequence of nibbles is encoded in reverse order, i.e., the
-   low-order nibble is encoded first, followed by the next low-order
-   nibble and so on.  Each nibble is represented by a hexadecimal digit.
-   For example, the reverse lookup domain name corresponding to the
-   address
-
-       4321:0:1:2:3:4:567:89ab
-
-   would be
-
-   b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.
-                                                                  ARPA.
-
-
-
-
-Thomson, et al.             Standards Track                     [Page 3]
-
-RFC 3596             DNS Extensions to Support IPv6         October 2003
-
-
-3. Modifications to existing query types
-
-   All existing query types that perform type A additional section
-   processing, i.e., name server (NS), location of services (SRV) and
-   mail exchange (MX) query types, must be redefined to perform both
-   type A and type AAAA additional section processing.  These
-   definitions mean that a name server must add any relevant IPv4
-   addresses and any relevant IPv6 addresses available locally to the
-   additional section of a response when processing any one of the above
-   queries.
-
-4. Security Considerations
-
-   Any information obtained from the DNS must be regarded as unsafe
-   unless techniques specified in [7] or [8] are used.  The definitions
-   of the AAAA record type and of the IP6.ARPA domain do not change the
-   model for use of these techniques.
-
-   So, this specification is not believed to cause any new security
-   problems, nor to solve any existing ones.
-
-5. IANA Considerations
-
-   There are no IANA assignments to be performed.
-
-6. Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   intellectual property or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; neither does it represent that it
-   has made any effort to identify any such rights.  Information on the
-   IETF's procedures with respect to rights in standards-track and
-   standards-related documentation can be found in BCP-11.  Copies of
-   claims of rights made available for publication and any assurances of
-   licenses to be made available, or the result of an attempt made to
-   obtain a general license or permission for the use of such
-   proprietary rights by implementors or users of this specification can
-   be obtained from the IETF Secretariat.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights which may cover technology that may be required to practice
-   this standard.  Please address the information to the IETF Executive
-   Director.
-
-
-
-
-
-Thomson, et al.             Standards Track                     [Page 4]
-
-RFC 3596             DNS Extensions to Support IPv6         October 2003
-
-
-Acknowledgments
-
-   Vladimir Ksinant and Mohsen Souissi would like to thank Sebastien
-   Barbin (IRISA), Luc Beloeil (France Telecom R&D), Jean-Mickael Guerin
-   (6WIND), Vincent Levigneron (AFNIC), Alain Ritoux (6WIND), Frederic
-   Roudaut (IRISA) and G6 group for their help during the RFC 1886
-   Interop tests sessions.
-
-   Many thanks to Alain Durand and Olafur Gudmundsson for their support.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Thomson, et al.             Standards Track                     [Page 5]
-
-RFC 3596             DNS Extensions to Support IPv6         October 2003
-
-
-Appendix A: Changes from RFC 1886
-
-   The following changes were made from RFC 1886 "DNS Extensions to
-   support IP version 6":
-
-   - Replaced the "IP6.INT" domain by "IP6.ARPA".
-   - Mentioned SRV query types in section 3 "MODIFICATIONS TO
-     EXISTING QUERY TYPES"
-   - Added security considerations.
-   - Updated references :
-     * From RFC 1884 to RFC 3513 (IP Version 6 Addressing
-       Architecture).
-     * From "work in progress" to RFC 2893 (Transition Mechanisms for
-       IPv6 Hosts and Routers).
-     * Added reference to RFC 1886, RFC 3152, RFC 2535 and RFC 2845.
-   - Updated document abstract
-   - Added table of contents
-   - Added full copyright statement
-   - Added IANA considerations section
-   - Added Intellectual Property Statement
-
-Normative References
-
-   [1]  Mockapetris, P., "Domain Names - Concepts and Facilities", STD
-        13, RFC 1034, November 1987.
-
-   [2]  Mockapetris, P., "Domain Names - Implementation and
-        Specification", STD 13, RFC 1035, November 1987.
-
-   [3]  Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
-        Addressing Architecture", RFC 3513, April 2003.
-
-Informative References
-
-   [4]  Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6
-        Hosts and Routers", RFC 2893, August 2000.
-
-   [5]  Thomson, S. and C. Huitema, "DNS Extensions to support IP
-        version 6", RFC 1886, December 1995.
-
-   [6]  Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, August
-        2001.
-
-   [7]  Eastlake, D., "Domain Name System Security Extensions", RFC
-        2535, March 1999
-
-
-
-
-
-
-Thomson, et al.             Standards Track                     [Page 6]
-
-RFC 3596             DNS Extensions to Support IPv6         October 2003
-
-
-   [8]  Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
-        "Secret Key Transaction Authentication for DNS (TSIG)", RFC
-        2845, May 2000.
-
-Authors' Addresses
-
-   Susan Thomson
-   Cisco Systems
-   499 Thornall Street, 8th floor
-   Edison, NJ 08837
-
-   Phone: +1 732-635-3086
-   EMail:  sethomso@cisco.com
-
-
-   Christian Huitema
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA 98052-6399
-
-   EMail: huitema@microsoft.com
-
-
-   Vladimir Ksinant
-   6WIND S.A.
-   Immeuble Central Gare - Bat.C
-   1, place Charles de Gaulle
-   78180, Montigny-Le-Bretonneux - France
-
-   Phone: +33 1 39 30 92 36
-   EMail: vladimir.ksinant@6wind.com
-
-
-   Mohsen Souissi
-   AFNIC
-   Immeuble International
-   2, rue Stephenson,
-   78181, Saint-Quentin en Yvelines Cedex - France
-
-   Phone: +33 1 39 30 83 40
-   EMail: Mohsen.Souissi@nic.fr
-
-
-
-
-
-
-
-
-
-
-Thomson, et al.             Standards Track                     [Page 7]
-
-RFC 3596             DNS Extensions to Support IPv6         October 2003
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assignees.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Thomson, et al.             Standards Track                     [Page 8]
-
diff --git a/contrib/bind9/doc/rfc/rfc3597.txt b/contrib/bind9/doc/rfc/rfc3597.txt
deleted file mode 100644
index 19e9a55..0000000
--- a/contrib/bind9/doc/rfc/rfc3597.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                      A. Gustafsson
-Request for Comments: 3597                                  Nominum Inc.
-Category: Standards Track                                 September 2003
-
-
-           Handling of Unknown DNS Resource Record (RR) Types
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-Abstract
-
-   Extending the Domain Name System (DNS) with new Resource Record (RR)
-   types currently requires changes to name server software.  This
-   document specifies the changes necessary to allow future DNS
-   implementations to handle new RR types transparently.
-
-1.  Introduction
-
-   The DNS is designed to be extensible to support new services through
-   the introduction of new resource record (RR) types.  In practice,
-   deploying a new RR type currently requires changes to the name server
-   software not only at the authoritative DNS server that is providing
-   the new information and the client making use of it, but also at all
-   slave servers for the zone containing it, and in some cases also at
-   caching name servers and forwarders used by the client.
-
-   Because the deployment of new server software is slow and expensive,
-   the potential of the DNS in supporting new services has never been
-   fully realized.  This memo proposes changes to name servers and to
-   procedures for defining new RR types aimed at simplifying the future
-   deployment of new RR types.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC 2119].
-
-
-
-
-
-
-Gustafsson                  Standards Track                     [Page 1]
-
-RFC 3597            Handling of Unknown DNS RR Types      September 2003
-
-
-2.  Definition
-
-   An "RR of unknown type" is an RR whose RDATA format is not known to
-   the DNS implementation at hand, and whose type is not an assigned
-   QTYPE or Meta-TYPE as specified in [RFC 2929] (section 3.1) nor
-   within the range reserved in that section for assignment only to
-   QTYPEs and Meta-TYPEs.  Such an RR cannot be converted to a type-
-   specific text format, compressed, or otherwise handled in a type-
-   specific way.
-
-   In the case of a type whose RDATA format is class specific, an RR is
-   considered to be of unknown type when the RDATA format for that
-   combination of type and class is not known.
-
-3.  Transparency
-
-   To enable new RR types to be deployed without server changes, name
-   servers and resolvers MUST handle RRs of unknown type transparently.
-   That is, they must treat the RDATA section of such RRs as
-   unstructured binary data, storing and transmitting it without change
-   [RFC1123].
-
-   To ensure the correct operation of equality comparison (section 6)
-   and of the DNSSEC canonical form (section 7) when an RR type is known
-   to some but not all of the servers involved, servers MUST also
-   exactly preserve the RDATA of RRs of known type, except for changes
-   due to compression or decompression where allowed by section 4 of
-   this memo.  In particular, the character case of domain names that
-   are not subject to compression MUST be preserved.
-
-4.  Domain Name Compression
-
-   RRs containing compression pointers in the RDATA part cannot be
-   treated transparently, as the compression pointers are only
-   meaningful within the context of a DNS message.  Transparently
-   copying the RDATA into a new DNS message would cause the compression
-   pointers to point at the corresponding location in the new message,
-   which now contains unrelated data.  This would cause the compressed
-   name to be corrupted.
-
-   To avoid such corruption, servers MUST NOT compress domain names
-   embedded in the RDATA of types that are class-specific or not well-
-   known.  This requirement was stated in [RFC1123] without defining the
-   term "well-known"; it is hereby specified that only the RR types
-   defined in [RFC1035] are to be considered "well-known".
-
-
-
-
-
-
-Gustafsson                  Standards Track                     [Page 2]
-
-RFC 3597            Handling of Unknown DNS RR Types      September 2003
-
-
-   The specifications of a few existing RR types have explicitly allowed
-   compression contrary to this specification: [RFC2163] specified that
-   compression applies to the PX RR, and [RFC2535] allowed compression
-   in SIG RRs and NXT RRs records.  Since this specification disallows
-   compression in these cases, it is an update to [RFC2163] (section 4)
-   and [RFC2535] (sections 4.1.7 and 5.2).
-
-   Receiving servers MUST decompress domain names in RRs of well-known
-   type, and SHOULD also decompress RRs of type RP, AFSDB, RT, SIG, PX,
-   NXT, NAPTR, and SRV (although the current specification of the SRV RR
-   in [RFC2782] prohibits compression, [RFC2052] mandated it, and some
-   servers following that earlier specification are still in use).
-
-   Future specifications for new RR types that contain domain names
-   within their RDATA MUST NOT allow the use of name compression for
-   those names, and SHOULD explicitly state that the embedded domain
-   names MUST NOT be compressed.
-
-   As noted in [RFC1123], the owner name of an RR is always eligible for
-   compression.
-
-5.  Text Representation
-
-   In the "type" field of a master file line, an unknown RR type is
-   represented by the word "TYPE" immediately followed by the decimal RR
-   type number, with no intervening whitespace.  In the "class" field,
-   an unknown class is similarly represented as the word "CLASS"
-   immediately followed by the decimal class number.
-
-   This convention allows types and classes to be distinguished from
-   each other and from TTL values, allowing the "[<TTL>] [<class>]
-   <type> <RDATA>" and "[<class>] [<TTL>] <type> <RDATA>" forms of
-   [RFC1035] to both be unambiguously parsed.
-
-   The RDATA section of an RR of unknown type is represented as a
-   sequence of white space separated words as follows:
-
-      The special token \# (a backslash immediately followed by a hash
-      sign), which identifies the RDATA as having the generic encoding
-      defined herein rather than a traditional type-specific encoding.
-
-      An unsigned decimal integer specifying the RDATA length in octets.
-
-      Zero or more words of hexadecimal data encoding the actual RDATA
-      field, each containing an even number of hexadecimal digits.
-
-   If the RDATA is of zero length, the text representation contains only
-   the \# token and the single zero representing the length.
-
-
-
-Gustafsson                  Standards Track                     [Page 3]
-
-RFC 3597            Handling of Unknown DNS RR Types      September 2003
-
-
-   An implementation MAY also choose to represent some RRs of known type
-   using the above generic representations for the type, class and/or
-   RDATA, which carries the benefit of making the resulting master file
-   portable to servers where these types are unknown.  Using the generic
-   representation for the RDATA of an RR of known type can also be
-   useful in the case of an RR type where the text format varies
-   depending on a version, protocol, or similar field (or several)
-   embedded in the RDATA when such a field has a value for which no text
-   format is known, e.g., a LOC RR [RFC1876] with a VERSION other than
-   0.
-
-   Even though an RR of known type represented in the \# format is
-   effectively treated as an unknown type for the purpose of parsing the
-   RDATA text representation, all further processing by the server MUST
-   treat it as a known type and take into account any applicable type-
-   specific rules regarding compression, canonicalization, etc.
-
-   The following are examples of RRs represented in this manner,
-   illustrating various combinations of generic and type-specific
-   encodings for the different fields of the master file format:
-
-      a.example.   CLASS32     TYPE731         \# 6 abcd (
-                                               ef 01 23 45 )
-      b.example.   HS          TYPE62347       \# 0
-      e.example.   IN          A               \# 4 0A000001
-      e.example.   CLASS1      TYPE1           10.0.0.2
-
-6.  Equality Comparison
-
-   Certain DNS protocols, notably Dynamic Update [RFC2136], require RRs
-   to be compared for equality.  Two RRs of the same unknown type are
-   considered equal when their RDATA is bitwise equal.  To ensure that
-   the outcome of the comparison is identical whether the RR is known to
-   the server or not, specifications for new RR types MUST NOT specify
-   type-specific comparison rules.
-
-   This implies that embedded domain names, being included in the
-   overall bitwise comparison, are compared in a case-sensitive manner.
-
-   As a result, when a new RR type contains one or more embedded domain
-   names, it is possible to have multiple RRs owned by the same name
-   that differ only in the character case of the embedded domain
-   name(s).  This is similar to the existing possibility of multiple TXT
-   records differing only in character case, and not expected to cause
-   any problems in practice.
-
-
-
-
-
-
-Gustafsson                  Standards Track                     [Page 4]
-
-RFC 3597            Handling of Unknown DNS RR Types      September 2003
-
-
-7.  DNSSEC Canonical Form and Ordering
-
-   DNSSEC defines a canonical form and ordering for RRs [RFC2535]
-   (section 8.1).  In that canonical form, domain names embedded in the
-   RDATA are converted to lower case.
-
-   The downcasing is necessary to ensure the correctness of DNSSEC
-   signatures when case distinctions in domain names are lost due to
-   compression, but since it requires knowledge of the presence and
-   position of embedded domain names, it cannot be applied to unknown
-   types.
-
-   To ensure continued consistency of the canonical form of RR types
-   where compression is allowed, and for continued interoperability with
-   existing implementations that already implement the [RFC2535]
-   canonical form and apply it to their known RR types, the canonical
-   form remains unchanged for all RR types whose whose initial
-   publication as an RFC was prior to the initial publication of this
-   specification as an RFC (RFC 3597).
-
-   As a courtesy to implementors, it is hereby noted that the complete
-   set of such previously published RR types that contain embedded
-   domain names, and whose DNSSEC canonical form therefore involves
-   downcasing according to the DNS rules for character comparisons,
-   consists of the RR types NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
-   HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV,
-   DNAME, and A6.
-
-   This document specifies that for all other RR types (whether treated
-   as unknown types or treated as known types according to an RR type
-   definition RFC more recent than RFC 3597), the canonical form is such
-   that no downcasing of embedded domain names takes place, and
-   otherwise identical to the canonical form specified in [RFC2535]
-   section 8.1.
-
-   Note that the owner name is always set to lower case according to the
-   DNS rules for character comparisons, regardless of the RR type.
-
-   The DNSSEC canonical RR ordering is as specified in [RFC2535] section
-   8.3, where the octet sequence is the canonical form as revised by
-   this specification.
-
-8.  Additional Section Processing
-
-   Unknown RR types cause no additional section processing.  Future RR
-   type specifications MAY specify type-specific additional section
-   processing rules, but any such processing MUST be optional as it can
-   only be performed by servers for which the RR type in case is known.
-
-
-
-Gustafsson                  Standards Track                     [Page 5]
-
-RFC 3597            Handling of Unknown DNS RR Types      September 2003
-
-
-9.  IANA Considerations
-
-   This document does not require any IANA actions.
-
-10.  Security Considerations
-
-   This specification is not believed to cause any new security
-   problems, nor to solve any existing ones.
-
-11.  Normative References
-
-   [RFC1034]   Mockapetris, P., "Domain Names - Concepts and
-               Facilities", STD 13, RFC 1034, November 1987.
-
-   [RFC1035]   Mockapetris, P., "Domain Names - Implementation and
-               Specifications", STD 13, RFC 1035, November 1987.
-
-   [RFC1123]   Braden, R., Ed., "Requirements for Internet Hosts --
-               Application and Support", STD 3, RFC 1123, October 1989.
-
-   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
-               Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2535]   Eastlake, D., "Domain Name System Security Extensions",
-               RFC 2535, March 1999.
-
-   [RFC2163]   Allocchio, C., "Using the Internet DNS to Distribute
-               MIXER Conformant Global Address Mapping (MCGAM)", RFC
-               2163, January 1998.
-
-   [RFC2929]   Eastlake, D., Brunner-Williams, E. and B. Manning,
-               "Domain Name System (DNS) IANA Considerations", BCP 42,
-               RFC 2929, September 2000.
-
-12.  Informative References
-
-   [RFC1876]   Davis, C., Vixie, P., Goodwin, T. and I. Dickinson, "A
-               Means for Expressing Location Information in the Domain
-               Name System", RFC 1876, January 1996.
-
-   [RFC2052]   Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying
-               the location of services (DNS SRV)", RFC 2052, October
-               1996.
-
-   [RFC2136]   Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound,
-               "Dynamic Updates in the Domain Name System (DNS UPDATE)",
-               RFC 2136, April 1997.
-
-
-
-
-Gustafsson                  Standards Track                     [Page 6]
-
-RFC 3597            Handling of Unknown DNS RR Types      September 2003
-
-
-   [RFC2782]   Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
-               specifying the location of services (DNS SRV)", RFC 2782,
-               February 2000.
-
-13.  Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   intellectual property or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; neither does it represent that it
-   has made any effort to identify any such rights.  Information on the
-   IETF's procedures with respect to rights in standards-track and
-   standards-related documentation can be found in BCP-11.  Copies of
-   claims of rights made available for publication and any assurances of
-   licenses to be made available, or the result of an attempt made to
-   obtain a general license or permission for the use of such
-   proprietary rights by implementors or users of this specification can
-   be obtained from the IETF Secretariat.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights which may cover technology that may be required to practice
-   this standard.  Please address the information to the IETF Executive
-   Director.
-
-14.  Author's Address
-
-   Andreas Gustafsson
-   Nominum, Inc.
-   2385 Bay Rd
-   Redwood City, CA 94063
-   USA
-
-   Phone: +1 650 381 6004
-   EMail: gson@nominum.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gustafsson                  Standards Track                     [Page 7]
-
-RFC 3597            Handling of Unknown DNS RR Types      September 2003
-
-
-15.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assignees.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gustafsson                  Standards Track                     [Page 8]
-
diff --git a/contrib/bind9/doc/rfc/rfc3645.txt b/contrib/bind9/doc/rfc/rfc3645.txt
deleted file mode 100644
index 6126678..0000000
--- a/contrib/bind9/doc/rfc/rfc3645.txt
+++ /dev/null
@@ -1,1459 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                            S. Kwan
-Request for Comments: 3645                                       P. Garg
-Updates: 2845                                                  J. Gilroy
-Category: Standards Track                                      L. Esibov
-                                                             J. Westhead
-                                                         Microsoft Corp.
-                                                                 R. Hall
-                                                     Lucent Technologies
-                                                            October 2003
-
-
-                 Generic Security Service Algorithm for
-        Secret Key Transaction Authentication for DNS (GSS-TSIG)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-Abstract
-
-   The Secret Key Transaction Authentication for DNS (TSIG) protocol
-   provides transaction level authentication for DNS.  TSIG is
-   extensible through the definition of new algorithms.  This document
-   specifies an algorithm based on the Generic Security Service
-   Application Program Interface (GSS-API) (RFC2743).  This document
-   updates RFC 2845.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kwan, et al.                Standards Track                     [Page 1]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
-   2.  Algorithm Overview . . . . . . . . . . . . . . . . . . . . . .  3
-       2.1.  GSS Details. . . . . . . . . . . . . . . . . . . . . . .  4
-       2.2.  Modifications to the TSIG protocol (RFC 2845). . . . . .  4
-   3.  Client Protocol Details. . . . . . . . . . . . . . . . . . . .  5
-       3.1.  Negotiating Context. . . . . . . . . . . . . . . . . . .  5
-           3.1.1.  Call GSS_Init_sec_context. . . . . . . . . . . . .  6
-           3.1.2.  Send TKEY Query to Server. . . . . . . . . . . . .  8
-           3.1.3.  Receive TKEY Query-Response from Server. . . . . .  8
-       3.2.  Context Established. . . . . . . . . . . . . . . . . . . 11
-           3.2.1.  Terminating a Context. . . . . . . . . . . . . . . 11
-   4.  Server Protocol Details. . . . . . . . . . . . . . . . . . . . 12
-       4.1.  Negotiating Context. . . . . . . . . . . . . . . . . . . 12
-           4.1.1.  Receive TKEY Query from Client . . . . . . . . . . 12
-           4.1.2.  Call GSS_Accept_sec_context. . . . . . . . . . . . 12
-           4.1.3.  Send TKEY Query-Response to Client . . . . . . . . 13
-       4.2.  Context Established. . . . . . . . . . . . . . . . . . . 15
-           4.2.1.  Terminating a Context. . . . . . . . . . . . . . . 15
-   5.  Sending and Verifying Signed Messages. . . . . . . . . . . . . 15
-       5.1.  Sending a Signed Message - Call GSS_GetMIC . . . . . . . 15
-       5.2.  Verifying a Signed Message - Call GSS_VerifyMIC. . . . . 16
-   6.  Example usage of GSS-TSIG algorithm. . . . . . . . . . . . . . 18
-   7.  Security Considerations. . . . . . . . . . . . . . . . . . . . 22
-   8.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 22
-   9.  Conformance. . . . . . . . . . . . . . . . . . . . . . . . . . 22
-   10. Intellectual Property Statement. . . . . . . . . . . . . . . . 23
-   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
-   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
-       12.1.  Normative References. . . . . . . . . . . . . . . . . . 24
-       12.2.  Informative References. . . . . . . . . . . . . . . . . 24
-   13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
-   14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 26
-
-1.  Introduction
-
-   The Secret Key Transaction Authentication for DNS (TSIG) [RFC2845]
-   protocol was developed to provide a lightweight authentication and
-   integrity of messages between two DNS entities, such as client and
-   server or server and server.  TSIG can be used to protect dynamic
-   update messages, authenticate regular message or to off-load
-   complicated DNSSEC [RFC2535] processing from a client to a server and
-   still allow the client to be assured of the integrity of the answers.
-
-
-
-
-
-
-
-Kwan, et al.                Standards Track                     [Page 2]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-   The TSIG protocol [RFC2845] is extensible through the definition of
-   new algorithms.  This document specifies an algorithm based on the
-   Generic Security Service Application Program Interface (GSS-API)
-   [RFC2743].  GSS-API is a framework that provides an abstraction of
-   security to the application protocol developer.  The security
-   services offered can include authentication, integrity, and
-   confidentiality.
-
-   The GSS-API framework has several benefits:
-
-   *  Mechanism and protocol independence.  The underlying mechanisms
-      that realize the security services can be negotiated on the fly
-      and varied over time.  For example, a client and server MAY use
-      Kerberos [RFC1964] for one transaction, whereas that same server
-      MAY use SPKM [RFC2025] with a different client.
-
-   *  The protocol developer is removed from the responsibility of
-      creating and managing a security infrastructure.  For example, the
-      developer does not need to create new key distribution or key
-      management systems.  Instead the developer relies on the security
-      service mechanism to manage this on its behalf.
-
-   The scope of this document is limited to the description of an
-   authentication mechanism only.  It does not discuss and/or propose an
-   authorization mechanism.  Readers that are unfamiliar with GSS-API
-   concepts are encouraged to read the characteristics and concepts
-   section of [RFC2743] before examining this protocol in detail.  It is
-   also assumed that the reader is familiar with [RFC2845], [RFC2930],
-   [RFC1034] and [RFC1035].
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
-   "RECOMMENDED", and "MAY" in this document are to be interpreted as
-   described in BCP 14, RFC 2119 [RFC2119].
-
-2.  Algorithm Overview
-
-   In GSS, client and server interact to create a "security context".
-   The security context can be used to create and verify transaction
-   signatures on messages between the two parties.  A unique security
-   context is required for each unique connection between client and
-   server.
-
-   Creating a security context involves a negotiation between client and
-   server.  Once a context has been established, it has a finite
-   lifetime for which it can be used to secure messages.  Thus there are
-   three states of a context associated with a connection:
-
-
-
-
-
-Kwan, et al.                Standards Track                     [Page 3]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-                              +----------+
-                              |          |
-                              V          |
-                      +---------------+  |
-                      | Uninitialized |  |
-                      |               |  |
-                      +---------------+  |
-                              |          |
-                              V          |
-                      +---------------+  |
-                      | Negotiating   |  |
-                      | Context       |  |
-                      +---------------+  |
-                              |          |
-                              V          |
-                      +---------------+  |
-                      | Context       |  |
-                      | Established   |  |
-                      +---------------+  |
-                              |          |
-                              +----------+
-
-   Every connection begins in the uninitialized state.
-
-2.1.  GSS Details
-
-   Client and server MUST be locally authenticated and have acquired
-   default credentials before using this protocol as specified in
-   Section 1.1.1 "Credentials" in RFC 2743 [RFC2743].
-
-   The GSS-TSIG algorithm consists of two stages:
-
-   I.  Establish security context.  The Client and Server use the
-       GSS_Init_sec_context and GSS_Accept_sec_context APIs to generate
-       the tokens that they pass to each other using [RFC2930] as a
-       transport mechanism.
-
-   II. Once the security context is established it is used to generate
-       and verify signatures using GSS_GetMIC and GSS_VerifyMIC APIs.
-       These signatures are exchanged by the Client and Server as a part
-       of the TSIG records exchanged in DNS messages sent between the
-       Client and Server, as described in [RFC2845].
-
-2.2.  Modifications to the TSIG protocol (RFC 2845)
-
-   Modification to RFC 2845 allows use of TSIG through signing server's
-   response in an explicitly specified place in multi message exchange
-   between two DNS entities even if client's request wasn't signed.
-
-
-
-Kwan, et al.                Standards Track                     [Page 4]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-   Specifically, Section 4.2 of RFC 2845 MUST be modified as follows:
-
-   Replace:
-      "The server MUST not generate a signed response to an unsigned
-      request."
-
-   With:
-      "The server MUST not generate a signed response to an unsigned
-      request, except in case of response to client's unsigned TKEY
-      query if secret key is established on server side after server
-      processed client's query.  Signing responses to unsigned TKEY
-      queries MUST be explicitly specified in the description of an
-      individual secret key establishment algorithm."
-
-3.  Client Protocol Details
-
-   A unique context is required for each server to which the client
-   sends secure messages.  A context is identified by a context handle.
-   A client maintains a mapping of servers to handles:
-
-      (target_name, key_name, context_handle)
-
-   The value key_name also identifies a context handle.  The key_name is
-   the owner name of the TKEY and TSIG records sent between a client and
-   a server to indicate to each other which context MUST be used to
-   process the current request.
-
-   DNS client and server MAY use various underlying security mechanisms
-   to establish security context as described in sections 3 and 4.  At
-   the same time, in order to guarantee interoperability between DNS
-   clients and servers that support GSS-TSIG it is REQUIRED that
-   security mechanism used by client enables use of Kerberos v5 (see
-   Section 9 for more information).
-
-3.1.  Negotiating Context
-
-   In GSS, establishing a security context involves the passing of
-   opaque tokens between the client and the server.  The client
-   generates the initial token and sends it to the server.  The server
-   processes the token and if necessary, returns a subsequent token to
-   the client.  The client processes this token, and so on, until the
-   negotiation is complete.  The number of times the client and server
-   exchange tokens depends on the underlying security mechanism.  A
-   completed negotiation results in a context handle.
-
-
-
-
-
-
-
-Kwan, et al.                Standards Track                     [Page 5]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-   The TKEY resource record [RFC2930] is used as the vehicle to transfer
-   tokens between client and server.  The TKEY record is a general
-   mechanism for establishing secret keys for use with TSIG.  For more
-   information, see [RFC2930].
-
-3.1.1.  Call GSS_Init_sec_context
-
-   To obtain the first token to be sent to a server, a client MUST call
-   GSS_Init_sec_context API.
-
-   The following input parameters MUST be used.  The outcome of the call
-   is indicated with the output values below.  Consult Sections 2.2.1,
-   "GSS_Init_sec_context call", of [RFC2743] for syntax definitions.
-
-   INPUTS
-     CREDENTIAL HANDLE claimant_cred_handle = NULL (NULL specifies "use
-         default").  Client MAY instead specify some other valid
-         handle to its credentials.
-     CONTEXT HANDLE input_context_handle  = 0
-     INTERNAL NAME  targ_name             = "DNS@<target_server_name>"
-     OBJECT IDENTIFIER mech_type          = Underlying security
-         mechanism chosen by implementers.  To guarantee
-         interoperability of the implementations of the GSS-TSIG
-         mechanism client MUST specify a valid underlying security
-         mechanism that enables use of Kerberos v5 (see Section 9 for
-         more information).
-     OCTET STRING   input_token           = NULL
-     BOOLEAN        replay_det_req_flag   = TRUE
-     BOOLEAN        mutual_req_flag       = TRUE
-     BOOLEAN        deleg_req_flag        = TRUE
-     BOOLEAN        sequence_req_flag     = TRUE
-     BOOLEAN        anon_req_flag         = FALSE
-     BOOLEAN        integ_req_flag        = TRUE
-     INTEGER        lifetime_req          = 0 (0 requests a default
-         value).  Client MAY instead specify another upper bound for the
-         lifetime of the context to be established in seconds.
-     OCTET STRING   chan_bindings         = Any valid channel bindings
-         as specified in Section 1.1.6 "Channel Bindings" in [RFC2743]
-
-   OUTPUTS
-     INTEGER        major_status
-     CONTEXT HANDLE output_context_handle
-     OCTET STRING   output_token
-     BOOLEAN        replay_det_state
-     BOOLEAN        mutual_state
-     INTEGER        minor_status
-     OBJECT IDENTIFIER mech_type
-     BOOLEAN        deleg_state
-
-
-
-Kwan, et al.                Standards Track                     [Page 6]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-     BOOLEAN        sequence_state
-     BOOLEAN        anon_state
-     BOOLEAN        trans_state
-     BOOLEAN        prot_ready_state
-     BOOLEAN        conf_avail
-     BOOLEAN        integ_avail
-     INTEGER        lifetime_rec
-
-   If returned major_status is set to one of the following errors:
-
-     GSS_S_DEFECTIVE_TOKEN
-     GSS_S_DEFECTIVE_CREDENTIAL
-     GSS_S_BAD_SIG (GSS_S_BAD_MIC)
-     GSS_S_NO_CRED
-     GSS_S_CREDENTIALS_EXPIRED
-     GSS_S_BAD_BINDINGS
-     GSS_S_OLD_TOKEN
-     GSS_S_DUPLICATE_TOKEN
-     GSS_S_NO_CONTEXT
-     GSS_S_BAD_NAMETYPE
-     GSS_S_BAD_NAME
-     GSS_S_BAD_MECH
-     GSS_S_FAILURE
-
-   then the client MUST abandon the algorithm and MUST NOT use the GSS-
-   TSIG algorithm to establish this security context.  This document
-   does not prescribe which other mechanism could be used to establish a
-   security context.  Next time when this client needs to establish
-   security context, the client MAY use GSS-TSIG algorithm.
-
-   Success values of major_status are GSS_S_CONTINUE_NEEDED and
-   GSS_S_COMPLETE.  The exact success code is important during later
-   processing.
-
-   The values of replay_det_state and mutual_state indicate if the
-   security package provides replay detection and mutual authentication,
-   respectively.  If returned major_status is GSS_S_COMPLETE AND one or
-   both of these values are FALSE, the client MUST abandon this
-   algorithm.
-
-   Client's behavior MAY depend on other OUTPUT parameters according to
-   the policy local to the client.
-
-   The handle output_context_handle is unique to this negotiation and is
-   stored in the client's mapping table as the context_handle that maps
-   to target_name.
-
-
-
-
-
-Kwan, et al.                Standards Track                     [Page 7]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-3.1.2.  Send TKEY Query to Server
-
-   An opaque output_token returned by GSS_Init_sec_context is
-   transmitted to the server in a query request with QTYPE=TKEY.  The
-   token itself will be placed in a Key Data field of the RDATA field in
-   the TKEY resource record in the additional records section of the
-   query.  The owner name of the TKEY resource record set queried for
-   and the owner name of the supplied TKEY resource record in the
-   additional records section MUST be the same.  This name uniquely
-   identifies the security context to both the client and server, and
-   thus the client SHOULD use a value which is globally unique as
-   described in [RFC2930].  To achieve global uniqueness, the name MAY
-   contain a UUID/GUID [ISO11578].
-
-      TKEY Record
-        NAME = client-generated globally unique domain name string
-               (as described in [RFC2930])
-        RDATA
-           Algorithm Name      = gss-tsig
-           Mode                = 3 (GSS-API negotiation - per [RFC2930])
-           Key Size            = size of output_token in octets
-           Key Data            = output_token
-
-   The remaining fields in the TKEY RDATA, i.e., Inception, Expiration,
-   Error, Other Size and Data Fields, MUST be set according to
-   [RFC2930].
-
-   The query is transmitted to the server.
-
-   Note: if the original client call to GSS_Init_sec_context returned
-   any major_status other than GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE,
-   then the client MUST NOT send TKEY query.  Client's behavior in this
-   case is described above in Section 3.1.1.
-
-3.1.3.  Receive TKEY Query-Response from Server
-
-   Upon the reception of the TKEY query the DNS server MUST respond
-   according to the description in Section 4.  This section specifies
-   the behavior of the client after it receives the matching response to
-   its query.
-
-   The next processing step depends on the value of major_status from
-   the most recent call that client performed to GSS_Init_sec_context:
-   either GSS_S_COMPLETE or GSS_S_CONTINUE.
-
-
-
-
-
-
-
-Kwan, et al.                Standards Track                     [Page 8]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-3.1.3.1.  Value of major_status == GSS_S_COMPLETE
-
-   If the last call to GSS_Init_sec_context yielded a major_status value
-   of GSS_S_COMPLETE and a non-NULL output_token was sent to the server,
-   then the client side component of the negotiation is complete and the
-   client is awaiting confirmation from the server.
-
-   Confirmation is in the form of a query response with RCODE=NOERROR
-   and with the last client supplied TKEY record in the answer section
-   of the query.  The response MUST be signed with a TSIG record.  Note
-   that the server is allowed to sign a response to unsigned client's
-   query due to modification to the RFC 2845 specified in Section 2.2
-   above.  The signature in the TSIG record MUST be verified using the
-   procedure detailed in section 5, Sending and Verifying Signed
-   Messages.  If the response is not signed, OR if the response is
-   signed but the signature is invalid, then an attacker has tampered
-   with the message in transit or has attempted to send the client a
-   false response.  In this case, the client MAY continue waiting for a
-   response to its last TKEY query until the time period since the
-   client sent last TKEY query expires.  Such a time period is specified
-   by the policy local to the client.  This is a new option that allows
-   the DNS client to accept multiple answers for one query ID and select
-   one (not necessarily the first one) based on some criteria.
-
-   If the signature is verified, the context state is advanced to
-   Context Established.  Proceed to section 3.2 for usage of the
-   security context.
-
-3.1.3.2.  Value of major_status == GSS_S_CONTINUE_NEEDED
-
-   If the last call to GSS_Init_sec_context yielded a major_status value
-   of GSS_S_CONTINUE_NEEDED, then the negotiation is not yet complete.
-   The server will return to the client a query response with a TKEY
-   record in the Answer section.  If the DNS message error is not
-   NO_ERROR or error field in the TKEY record is not 0 (i.e., no error),
-   then the client MUST abandon this negotiation sequence.  The client
-   MUST delete an active context by calling GSS_Delete_sec_context
-   providing the associated context_handle.  The client MAY repeat the
-   negotiation sequence starting with the uninitialized state as
-   described in section 3.1.  To prevent infinite looping the number of
-   attempts to establish a security context MUST be limited to ten or
-   less.
-
-   If the DNS message error is NO_ERROR and the error field in the TKEY
-   record is 0 (i.e., no error), then the client MUST pass a token
-   specified in the Key Data field in the TKEY resource record to
-
-
-
-
-
-Kwan, et al.                Standards Track                     [Page 9]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-   GSS_Init_sec_context using the same parameters values as in previous
-   call except values for CONTEXT HANDLE input_context_handle and OCTET
-   STRING input_token as described below:
-
-   INPUTS
-     CONTEXT HANDLE input_context_handle  = context_handle (this is the
-          context_handle corresponding to the key_name which is the
-          owner name of the TKEY record in the answer section in the
-          TKEY query response)
-
-     OCTET STRING   input_token           = token from Key field of
-                                            TKEY record
-
-   Depending on the following OUTPUT values of GSS_Init_sec_context
-
-        INTEGER        major_status
-        OCTET STRING   output_token
-
-   the client MUST take one of the following actions:
-
-   If OUTPUT major_status is set to one of the following values:
-
-        GSS_S_DEFECTIVE_TOKEN
-        GSS_S_DEFECTIVE_CREDENTIAL
-        GSS_S_BAD_SIG (GSS_S_BAD_MIC)
-        GSS_S_NO_CRED
-        GSS_S_CREDENTIALS_EXPIRED
-        GSS_S_BAD_BINDINGS
-        GSS_S_OLD_TOKEN
-        GSS_S_DUPLICATE_TOKEN
-        GSS_S_NO_CONTEXT
-        GSS_S_BAD_NAMETYPE
-        GSS_S_BAD_NAME
-        GSS_S_BAD_MECH
-        GSS_S_FAILURE
-
-   the client MUST abandon this negotiation sequence.  This means that
-   the client MUST delete an active context by calling
-   GSS_Delete_sec_context providing the associated context_handle.  The
-   client MAY repeat the negotiation sequence starting with the
-   uninitialized state as described in section 3.1.  To prevent infinite
-   looping the number of attempts to establish a security context MUST
-   be limited to ten or less.
-
-   If OUTPUT major_status is GSS_S_CONTINUE_NEEDED OR GSS_S_COMPLETE
-   then client MUST act as described below.
-
-
-
-
-
-Kwan, et al.                Standards Track                    [Page 10]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-   If the response from the server was signed, and the OUTPUT
-   major_status is GSS_S_COMPLETE,then the signature in the TSIG record
-   MUST be verified using the procedure detailed in section 5, Sending
-   and Verifying Signed Messages.  If the signature is invalid, then the
-   client MUST abandon this negotiation sequence.  This means that the
-   client MUST delete an active context by calling
-   GSS_Delete_sec_context providing the associated context_handle.  The
-   client MAY repeat the negotiation sequence starting with the
-   uninitialized state as described in section 3.1.  To prevent infinite
-   looping the number of attempts to establish a security context MUST
-   be limited to ten or less.
-
-   If major_status is GSS_S_CONTINUE_NEEDED the negotiation is not yet
-   finished.  The token output_token MUST be passed to the server in a
-   TKEY record by repeating the negotiation sequence beginning with
-   section 3.1.2.  The client MUST place a limit on the number of
-   continuations in a context negotiation to prevent endless looping.
-   Such limit SHOULD NOT exceed value of 10.
-
-   If major_status is GSS_S_COMPLETE and output_token is non-NULL, the
-   client-side component of the negotiation is complete but the token
-   output_token MUST be passed to the server by repeating the
-   negotiation sequence beginning with section 3.1.2.
-
-   If major_status is GSS_S_COMPLETE and output_token is NULL, context
-   negotiation is complete.  The context state is advanced to Context
-   Established.  Proceed to section 3.2 for usage of the security
-   context.
-
-3.2.  Context Established
-
-   When context negotiation is complete, the handle context_handle MUST
-   be used for the generation and verification of transaction
-   signatures.
-
-   The procedures for sending and receiving signed messages are
-   described in section 5, Sending and Verifying Signed Messages.
-
-3.2.1.  Terminating a Context
-
-   When the client is not intended to continue using the established
-   security context, the client SHOULD delete an active context by
-   calling GSS_Delete_sec_context providing the associated
-   context_handle, AND client SHOULD delete the established context on
-   the DNS server by using TKEY RR with the Mode field set to 5, i.e.,
-   "key deletion" [RFC2930].
-
-
-
-
-
-Kwan, et al.                Standards Track                    [Page 11]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-4.  Server Protocol Details
-
-   As on the client-side, the result of a successful context negotiation
-   is a context handle used in future generation and verification of the
-   transaction signatures.
-
-   A server MAY be managing several contexts with several clients.
-   Clients identify their contexts by providing a key name in their
-   request.  The server maintains a mapping of key names to handles:
-
-      (key_name, context_handle)
-
-4.1.  Negotiating Context
-
-   A server MUST recognize TKEY queries as security context negotiation
-   messages.
-
-4.1.1.  Receive TKEY Query from Client
-
-   Upon receiving a query with QTYPE = TKEY, the server MUST examine
-   whether the Mode and Algorithm Name fields of the TKEY record in the
-   additional records section of the message contain values of 3 and
-   gss-tsig, respectively.  If they do, then the (key_name,
-   context_handle) mapping table is searched for the key_name matching
-   the owner name of the TKEY record in the additional records section
-   of the query.  If the name is found in the table and the security
-   context for this name is established and not expired, then the server
-   MUST respond to the query with BADNAME error in the TKEY error field.
-   If the name is found in the table and the security context is not
-   established, the corresponding context_handle is used in subsequent
-   GSS operations.  If the name is found but the security context is
-   expired, then the server deletes this security context, as described
-   in Section 4.2.1, and interprets this query as a start of new
-   security context negotiation and performs operations described in
-   Section 4.1.2 and 4.1.3.  If the name is not found, then the server
-   interprets this query as a start of new security context negotiation
-   and performs operations described in Section 4.1.2 and 4.1.3.
-
-4.1.2.  Call GSS_Accept_sec_context
-
-   The server performs its side of a context negotiation by calling
-   GSS_Accept_sec_context.  The following input parameters MUST be used.
-   The outcome of the call is indicated with the output values below.
-   Consult Sections 2.2.2 "GSS_Accept_sec_context call" of the RFC 2743
-   [RFC2743] for syntax definitions.
-
-
-
-
-
-
-Kwan, et al.                Standards Track                    [Page 12]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-   INPUTS
-     CONTEXT HANDLE input_context_handle  = 0 if new negotiation,
-                                            context_handle matching
-                                         key_name if ongoing negotiation
-     OCTET STRING   input_token           = token specified in the Key
-           field from TKEY RR (from Additional records Section of
-           the client's query)
-
-     CREDENTIAL HANDLE acceptor_cred_handle = NULL (NULL specifies "use
-           default").  Server MAY instead specify some other valid
-           handle to its credentials.
-     OCTET STRING   chan_bindings          = Any valid channel bindings
-           as specified in Section 1.1.6 "Channel Bindings" in [RFC2743]
-
-   OUTPUTS
-     INTEGER        major_status
-     CONTEXT_HANDLE output_context_handle
-     OCTET STRING   output_token
-     INTEGER        minor_status
-     INTERNAL NAME  src_name
-     OBJECT IDENTIFIER  mech_type
-     BOOLEAN        deleg_state
-     BOOLEAN        mutual_state
-     BOOLEAN        replay_det_state
-     BOOLEAN        sequence_state
-     BOOLEAN        anon_state
-     BOOLEAN        trans_state
-     BOOLEAN        prot_ready_state
-     BOOLEAN        conf_avail
-     BOOLEAN        integ_avail
-     INTEGER        lifetime_rec
-     CONTEXT_HANDLE delegated_cred_handle
-
-   If this is the first call to GSS_Accept_sec_context in a new
-   negotiation, then output_context_handle is stored in the server's
-   key-mapping table as the context_handle that maps to the name of the
-   TKEY record.
-
-4.1.3.  Send TKEY Query-Response to Client
-
-   The server MUST respond to the client with a TKEY query response with
-   RCODE = NOERROR, that contains a TKEY record in the answer section.
-
-   If OUTPUT major_status is one of the following errors the error field
-   in the TKEY record set to BADKEY.
-
-
-
-
-
-
-Kwan, et al.                Standards Track                    [Page 13]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-        GSS_S_DEFECTIVE_TOKEN
-        GSS_S_DEFECTIVE_CREDENTIAL
-        GSS_S_BAD_SIG (GSS_S_BAD_MIC)
-        GSS_S_DUPLICATE_TOKEN
-        GSS_S_OLD_TOKEN
-        GSS_S_NO_CRED
-        GSS_S_CREDENTIALS_EXPIRED
-        GSS_S_BAD_BINDINGS
-        GSS_S_NO_CONTEXT
-        GSS_S_BAD_MECH
-        GSS_S_FAILURE
-
-   If OUTPUT major_status is set to  GSS_S_COMPLETE or
-   GSS_S_CONTINUE_NEEDED then server MUST act as described below.
-
-   If major_status is GSS_S_COMPLETE the server component of the
-   negotiation is finished.  If output_token is non-NULL, then it MUST
-   be returned to the client in a Key Data field of the RDATA in TKEY.
-   The error field in the TKEY record is set to NOERROR.  The message
-   MUST be signed with a TSIG record as described in section 5, Sending
-   and Verifying Signed Messages.  Note that server is allowed to sign a
-   response to unsigned client's query due to modification to the RFC
-   2845 specified in Section 2.2 above.  The context state is advanced
-   to Context Established.  Section 4.2 discusses the usage of the
-   security context.
-
-   If major_status is GSS_S_COMPLETE and output_token is NULL, then the
-   TKEY record received from the client MUST be returned in the Answer
-   section of the response.  The message MUST be signed with a TSIG
-   record as described in section 5, Sending and Verifying Signed
-   Messages.  Note that server is allowed to sign a response to unsigned
-   client's query due to modification to the RFC 2845 specified in
-   section 2.2 above.  The context state is advanced to Context
-   Established.  Section 4.2 discusses the usage of the security
-   context.
-
-   If major_status is GSS_S_CONTINUE_NEEDED, the server component of the
-   negotiation is not yet finished.  The server responds to the TKEY
-   query with a standard query response, placing in the answer section a
-   TKEY record containing output_token in the Key Data RDATA field.  The
-   error field in the TKEY record is set to NOERROR.  The server MUST
-   limit the number of times that a given context is allowed to repeat,
-   to prevent endless looping.  Such limit SHOULD NOT exceed value of
-   10.
-
-
-
-
-
-
-
-Kwan, et al.                Standards Track                    [Page 14]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-   In all cases, except if major_status is GSS_S_COMPLETE and
-   output_token is NULL, other TKEY record fields MUST contain the
-   following values:
-
-        NAME = key_name
-        RDATA
-           Algorithm Name      = gss-tsig
-           Mode                = 3 (GSS-API negotiation - per [RFC2930])
-           Key Size            = size of output_token in octets
-
-   The remaining fields in the TKEY RDATA, i.e., Inception, Expiration,
-   Error, Other Size and Data Fields, MUST be set according to
-   [RFC2930].
-
-4.2.  Context Established
-
-   When context negotiation is complete, the handle context_handle is
-   used for the generation and verification of transaction signatures.
-   The handle is valid for a finite amount of time determined by the
-   underlying security mechanism.  A server MAY unilaterally terminate a
-   context at any time (see section 4.2.1).
-
-   Server SHOULD limit the amount of memory used to cache established
-   contexts.
-
-   The procedures for sending and receiving signed messages are given in
-   section 5, Sending and Verifying Signed Messages.
-
-4.2.1.  Terminating a Context
-
-   A server can terminate any established context at any time.  The
-   server MAY hint to the client that the context is being deleted by
-   including a TKEY RR in a response with the Mode field set to 5, i.e.,
-   "key deletion" [RFC2930].  An active context is deleted by calling
-   GSS_Delete_sec_context providing the associated context_handle.
-
-5.  Sending and Verifying Signed Messages
-
-5.1.  Sending a Signed Message - Call GSS_GetMIC
-
-   The procedure for sending a signature-protected message is specified
-   in [RFC2845].  The data to be passed to the signature routine
-   includes the whole DNS message with specific TSIG variables appended.
-   For the exact format, see [RFC2845].  For this protocol, use the
-   following TSIG variable values:
-
-
-
-
-
-
-Kwan, et al.                Standards Track                    [Page 15]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-      TSIG Record
-        NAME = key_name that identifies this context
-        RDATA
-           Algorithm Name = gss-tsig
-
-   Assign the remaining fields in the TSIG RDATA appropriate values as
-   described in [RFC2845].
-
-   The signature is generated by calling GSS_GetMIC.  The following
-   input parameters MUST be used.  The outcome of the call is indicated
-   with the output values specified below.  Consult Sections 2.3.1
-   "GSS_GetMIC call" of the RFC 2743[RFC2743] for syntax definitions.
-
-   INPUTS
-     CONTEXT HANDLE context_handle = context_handle for key_name
-     OCTET STRING   message        = outgoing message plus TSIG
-                                     variables (per [RFC2845])
-     INTEGER qop_req               = 0 (0 requests a default
-         value).  Caller MAY instead specify other valid value (for
-         details see Section 1.2.4 in [RFC2743])
-
-   OUTPUTS
-     INTEGER        major_status
-     INTEGER        minor_status
-     OCTET STRING   per_msg_token
-
-   If major_status is GSS_S_COMPLETE, then signature generation
-   succeeded.  The signature in per_msg_token is inserted into the
-   Signature field of the TSIG RR and the message is transmitted.
-
-   If major_status is GSS_S_CONTEXT_EXPIRED, GSS_S_CREDENTIALS_EXPIRED
-   or GSS_S_FAILURE the caller MUST delete the security context, return
-   to the uninitialized state and SHOULD negotiate a new security
-   context, as described above in Section 3.1
-
-   If major_status is GSS_S_NO_CONTEXT, the caller MUST remove the entry
-   for key_name from the (target_ name, key_name, context_handle)
-   mapping table, return to the uninitialized state and SHOULD negotiate
-   a new security context, as described above in Section 3.1
-
-   If major_status is GSS_S_BAD_QOP, the caller SHOULD repeat the
-   GSS_GetMIC call with allowed QOP value.  The number of such
-   repetitions MUST be limited to prevent infinite loops.
-
-5.2.  Verifying a Signed Message - Call GSS_VerifyMIC
-
-   The procedure for verifying a signature-protected message is
-   specified in [RFC2845].
-
-
-
-Kwan, et al.                Standards Track                    [Page 16]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-   The NAME of the TSIG record determines which context_handle maps to
-   the context that MUST be used to verify the signature.  If the NAME
-   does not map to an established context, the server MUST send a
-   standard TSIG error response to the client indicating BADKEY in the
-   TSIG error field (as described in [RFC2845]).
-
-   For the GSS algorithm, a signature is verified by using
-   GSS_VerifyMIC:
-
-   INPUTS
-     CONTEXT HANDLE context_handle = context_handle for key_name
-     OCTET STRING   message        = incoming message plus TSIG
-                                     variables (per [RFC2845])
-     OCTET STRING   per_msg_token  = Signature field from TSIG RR
-
-   OUTPUTS
-     INTEGER        major_status
-     INTEGER        minor_status
-     INTEGER        qop_state
-
-   If major_status is GSS_S_COMPLETE, the signature is authentic and the
-   message was delivered intact.  Per [RFC2845], the timer values of the
-   TSIG record MUST also be valid before considering the message to be
-   authentic.  The caller MUST not act on the request or response in the
-   message until these checks are verified.
-
-   When a server is processing a client request, the server MUST send a
-   standard TSIG error response to the client indicating BADKEY in the
-   TSIG error field as described in [RFC2845], if major_status is set to
-   one of the following values
-
-        GSS_S_DEFECTIVE_TOKEN
-        GSS_S_BAD_SIG (GSS_S_BAD_MIC)
-        GSS_S_DUPLICATE_TOKEN
-        GSS_S_OLD_TOKEN
-        GSS_S_UNSEQ_TOKEN
-        GSS_S_GAP_TOKEN
-        GSS_S_CONTEXT_EXPIRED
-        GSS_S_NO_CONTEXT
-        GSS_S_FAILURE
-
-   If the timer values of the TSIG record are invalid, the message MUST
-   NOT be considered authentic.  If this error checking fails when a
-   server is processing a client request, the appropriate error response
-   MUST be sent to the client according to [RFC2845].
-
-
-
-
-
-
-Kwan, et al.                Standards Track                    [Page 17]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-6.  Example usage of GSS-TSIG algorithm
-
-   This Section describes an example where a Client, client.example.com,
-   and a Server, server.example.com, establish a security context
-   according to the algorithm described above.
-
-  I.  Client initializes security context negotiation
-
-  To establish a security context with a server, server.example.com, the
-  Client calls GSS_Init_sec_context with the following parameters.
-  (Note that some INPUT and OUTPUT parameters not critical for this
-  algorithm are not described in this example.)
-
-     CONTEXT HANDLE input_context_handle  = 0
-     INTERNAL NAME  targ_name             = "DNS@server.example.com"
-     OCTET STRING   input_token           = NULL
-     BOOLEAN        replay_det_req_flag   = TRUE
-     BOOLEAN        mutual_req_flag       = TRUE
-
-  The OUTPUTS parameters returned by GSS_Init_sec_context include
-     INTEGER        major_status = GSS_S_CONTINUE_NEEDED
-     CONTEXT HANDLE output_context_handle context_handle
-     OCTET STRING   output_token output_token
-     BOOLEAN        replay_det_state = TRUE
-     BOOLEAN        mutual_state = TRUE
-
-  Client verifies that replay_det_state and mutual_state values are
-  TRUE.  Since the major_status is GSS_S_CONTINUE_NEEDED, which is a
-  success OUTPUT major_status value, client stores context_handle that
-  maps to "DNS@server.example.com" and proceeds to the next step.
-
-  II.  Client sends a query with QTYPE = TKEY to server
-
-  Client sends a query with QTYPE = TKEY for a client-generated globally
-  unique domain name string, 789.client.example.com.server.example.com.
-  Query contains a TKEY record in its Additional records section with
-  the following fields.  (Note that some fields not specific to this
-  algorithm are not specified.)
-
-     NAME = 789.client.example.com.server.example.com.
-     RDATA
-        Algorithm Name      = gss-tsig
-        Mode                = 3 (GSS-API negotiation - per [RFC2930])
-        Key Size            = size of output_token in octets
-        Key Data            = output_token
-
-
-
-
-
-
-Kwan, et al.                Standards Track                    [Page 18]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-  After the key_name 789.client.example.com.server.example.com.
-  is generated it is stored in the client's (target_name, key_name,
-  context_handle) mapping table.
-
-  III.  Server receives a query with QTYPE = TKEY
-
-  When server receives a query with QTYPE = TKEY, the server verifies
-  that Mode and Algorithm fields in the TKEY record in the Additional
-  records section of the query are set to 3 and "gss-tsig" respectively.
-  It finds that the key_name 789.client.example.com.server.example.com.
-  is not listed in its (key_name, context_handle) mapping table.
-
-  IV.  Server calls GSS_Accept_sec_context
-
-  To continue security context negotiation server calls
-  GSS_Accept_sec_context with the following parameters.  (Note that
-  some INPUT and OUTPUT parameters not critical for this algorithm
-  are not described in this example.)
-
-   INPUTS
-     CONTEXT HANDLE input_context_handle  = 0
-     OCTET STRING   input_token           = token specified in the Key
-                              field from TKEY RR (from Additional
-                              records section of the client's query)
-
-  The OUTPUTS parameters returned by GSS_Accept_sec_context include
-     INTEGER        major_status = GSS_S_CONTINUE_NEEDED
-     CONTEXT_HANDLE output_context_handle context_handle
-     OCTET STRING   output_token output_token
-
-  Server stores the mapping of the
-  789.client.example.com.server.example.com. to OUTPUT context_handle
-  in its (key_name, context_handle) mapping table.
-
-  V.  Server responds to the TKEY query
-
-  Since the major_status = GSS_S_CONTINUE_NEEDED in the last server's
-  call to GSS_Accept_sec_context, the server responds to the TKEY query
-  placing in the answer section a TKEY record containing output_token in
-  the Key Data RDATA field.  The error field in the TKEY record is set
-  to 0.  The RCODE in the query response is set to NOERROR.
-
-  VI.  Client processes token returned by server
-
-  When the client receives the TKEY query response from the server, the
-  client calls GSS_Init_sec_context with the following parameters.
-  (Note that some INPUT and OUTPUT parameters not critical for this
-  algorithm are not described in this example.)
-
-
-
-Kwan, et al.                Standards Track                    [Page 19]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-     CONTEXT HANDLE input_context_handle  = the context_handle stored
-          in the client's mapping table entry (DNS@server.example.com.,
-          789.client.example.com.server.example.com., context_handle)
-     INTERNAL NAME  targ_name             = "DNS@server.example.com"
-     OCTET STRING   input_token           = token from Key field of TKEY
-          record from the Answer section of the server's response
-     BOOLEAN        replay_det_req_flag   = TRUE
-     BOOLEAN        mutual_req_flag       = TRUE
-
-  The OUTPUTS parameters returned by GSS_Init_sec_context include
-     INTEGER        major_status = GSS_S_COMPLETE
-     CONTEXT HANDLE output_context_handle = context_handle
-     OCTET STRING   output_token = output_token
-     BOOLEAN        replay_det_state = TRUE
-     BOOLEAN        mutual_state = TRUE
-
-  Since the major_status is set to GSS_S_COMPLETE the client side
-  security context is established, but since the output_token is not
-  NULL client MUST send a TKEY query to the server as described below.
-
-  VII.  Client sends a query with QTYPE = TKEY to server
-
-  Client sends to the server a TKEY query for the
-  789.client.example.com.server.example.com. name.  Query contains a
-  TKEY record in its Additional records section with the following
-  fields.  (Note that some INPUT and OUTPUT parameters not critical to
-  this algorithm are not described in this example.)
-
-     NAME = 789.client.example.com.server.example.com.
-     RDATA
-        Algorithm Name      = gss-tsig
-        Mode                = 3 (GSS-API negotiation - per [RFC2930])
-        Key Size            = size of output_token in octets
-        Key Data            = output_token
-
-  VIII.  Server receives a TKEY query
-
-  When the server receives a TKEY query, the server verifies that Mode
-  and Algorithm fields in the TKEY record in the Additional records
-  section of the query are set to 3 and gss-tsig, respectively.  It
-  finds that the key_name 789.client.example.com.server.example.com. is
-  listed in its (key_name, context_handle) mapping table.
-
-
-
-
-
-
-
-
-
-Kwan, et al.                Standards Track                    [Page 20]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-  IX.  Server calls GSS_Accept_sec_context
-
-  To continue security context negotiation server calls
-  GSS_Accept_sec_context with the following parameters (Note that some
-  INPUT and OUTPUT parameters not critical for this algorithm are not
-  described in this example)
-
-   INPUTS
-     CONTEXT HANDLE input_context_handle  = context_handle from the
-           (789.client.example.com.server.example.com., context_handle)
-           entry in the server's mapping table
-     OCTET STRING   input_token           = token specified in the Key
-           field of TKEY RR (from Additional records Section of
-           the client's query)
-
-  The OUTPUTS parameters returned by GSS_Accept_sec_context include
-     INTEGER        major_status = GSS_S_COMPLETE
-     CONTEXT_HANDLE output_context_handle = context_handle
-     OCTET STRING   output_token = NULL
-
-  Since major_status = GSS_S_COMPLETE, the security context on the
-  server side is established, but the server still needs to respond to
-  the client's TKEY query, as described below.  The security context
-  state is advanced to Context Established.
-
-  X.  Server responds to the TKEY query
-
-  Since the major_status = GSS_S_COMPLETE in the last server's call to
-  GSS_Accept_sec_context and the output_token is NULL, the server
-  responds to the TKEY query placing in the answer section a TKEY record
-  that was sent by the client in the Additional records section of the
-  client's latest TKEY query.  In addition, this server places a
-  TSIG record in additional records section of its response.  Server
-  calls GSS_GetMIC to generate a signature to include it in the TSIG
-  record.  The server specifies the following GSS_GetMIC INPUT
-  parameters:
-
-     CONTEXT HANDLE context_handle = context_handle from the
-           (789.client.example.com.server.example.com., context_handle)
-           entry in the server's mapping table
-     OCTET STRING   message        = outgoing message plus TSIG
-                                   variables (as described in [RFC2845])
-
-  The OUTPUTS parameters returned by GSS_GetMIC include
-     INTEGER        major_status = GSS_S_COMPLETE
-     OCTET STRING   per_msg_token
-
-  Signature field in the TSIG record is set to per_msg_token.
-
-
-
-Kwan, et al.                Standards Track                    [Page 21]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-  XI.  Client processes token returned by server
-
-  Client receives the TKEY query response from the server.  Since the
-  major_status was GSS_S_COMPLETE in the last client's call to
-  GSS_Init_sec_context, the client verifies that the server's response
-  is signed.  To validate the signature, the client calls
-  GSS_VerifyMIC with the following parameters:
-
-   INPUTS
-     CONTEXT HANDLE context_handle = context_handle for
-                  789.client.example.com.server.example.com. key_name
-     OCTET STRING   message        = incoming message plus TSIG
-                                  variables (as described in [RFC2845])
-     OCTET STRING   per_msg_token  = Signature field from TSIG RR
-                  included in the server's query response
-
-  Since the OUTPUTS parameter major_status = GSS_S_COMPLETE, the
-  signature is validated, security negotiation is complete and the
-  security context state is advanced to Context Established.  These
-  client and server will use the established security context to sign
-  and validate the signatures when they exchange packets with each
-  other until the context expires.
-
-7.  Security Considerations
-
-   This document describes a protocol for DNS security using GSS-API.
-   The security provided by this protocol is only as effective as the
-   security provided by the underlying GSS mechanisms.
-
-   All the security considerations from RFC 2845, RFC 2930 and RFC 2743
-   apply to the protocol described in this document.
-
-8.  IANA Considerations
-
-   The IANA has reserved the TSIG Algorithm name gss-tsig for the use in
-   the Algorithm fields of TKEY and TSIG resource records.  This
-   Algorithm name refers to the algorithm described in this document.
-   The requirement to have this name registered with IANA is specified
-   in RFC 2845.
-
-9.  Conformance
-
-   The GSS API using SPNEGO [RFC2478] provides maximum flexibility to
-   choose the underlying security mechanisms that enables security
-   context negotiation.  GSS API using SPNEGO [RFC2478] enables client
-   and server to negotiate and choose such underlying security
-   mechanisms on the fly.  To support such flexibility, DNS clients and
-   servers SHOULD specify SPNEGO mech_type in their GSS API calls.  At
-
-
-
-Kwan, et al.                Standards Track                    [Page 22]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-   the same time, in order to guarantee interoperability between DNS
-   clients and servers that support GSS-TSIG it is required that
-
-   -  DNS servers specify SPNEGO mech_type
-   -  GSS APIs called by DNS client support Kerberos v5
-   -  GSS APIs called by DNS server support SPNEGO [RFC2478] and
-      Kerberos v5.
-
-   In addition to these, GSS APIs used by DNS client and server MAY also
-   support other underlying security mechanisms.
-
-10.  Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   intellectual property or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; neither does it represent that it
-   has made any effort to identify any such rights.  Information on the
-   IETF's procedures with respect to rights in standards-track and
-   standards-related documentation can be found in BCP-11.  Copies of
-   claims of rights made available for publication and any assurances of
-   licenses to be made available, or the result of an attempt made to
-   obtain a general license or permission for the use of such
-   proprietary rights by implementors or users of this specification can
-   be obtained from the IETF Secretariat.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights which may cover technology that may be required to practice
-   this standard.  Please address the information to the IETF Executive
-   Director.
-
-11.  Acknowledgements
-
-   The authors of this document would like to thank the following people
-   for their contribution to this specification:  Chuck Chan, Mike
-   Swift, Ram Viswanathan, Olafur Gudmundsson, Donald E. Eastlake, 3rd
-   and Erik Nordmark.
-
-
-
-
-
-
-
-
-
-
-
-
-Kwan, et al.                Standards Track                    [Page 23]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-12.  References
-
-12.1.  Normative References
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
-             Negotiation Mechanism", RFC 2478, December 1998.
-
-   [RFC2743] Linn, J., "Generic Security Service Application Program
-             Interface, Version 2 , Update 1", RFC 2743, January 2000.
-
-   [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D. and B.
-             Wellington, "Secret Key Transaction Authentication for DNS
-             (TSIG)", RFC 2845, May 2000.
-
-   [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
-             RR)", RFC 2930, September 2000.
-
-12.2.  Informative References
-
-
-   [ISO11578] "Information technology", "Open Systems Interconnection",
-              "Remote Procedure Call", ISO/IEC 11578:1996,
-              http://www.iso.ch/cate/d2229.html.
-
-   [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
-             STD 13, RFC 1034, November 1987.
-
-   [RFC1035] Mockapetris, P., "Domain Names - Implementation and
-             Specification", STD 13, RFC 1034, November 1987.
-
-   [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC
-             1964, June 1996.
-
-   [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism
-             (SPKM)", RFC 2025, October 1996.
-
-   [RFC2137] Eastlake 3rd, D., "Secure Domain Name System Dynamic
-             Update", RFC 2137, April 1997.
-
-   [RFC2535] Eastlake 3rd, D., "Domain Name System Security Extensions",
-             RFC 2535, March 1999.
-
-
-
-
-
-
-
-Kwan, et al.                Standards Track                    [Page 24]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-13.  Authors' Addresses
-
-   Stuart Kwan
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   USA
-   EMail: skwan@microsoft.com
-
-   Praerit Garg
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   USA
-   EMail: praeritg@microsoft.com
-
-   James Gilroy
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   USA
-   EMail: jamesg@microsoft.com
-
-   Levon Esibov
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   USA
-   EMail: levone@microsoft.com
-
-   Randy Hall
-   Lucent Technologies
-   400 Lapp Road
-   Malvern PA 19355
-   USA
-   EMail: randyhall@lucent.com
-
-   Jeff Westhead
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   USA
-   EMail: jwesth@microsoft.com
-
-
-
-
-
-
-
-
-Kwan, et al.                Standards Track                    [Page 25]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-14.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assignees.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kwan, et al.                Standards Track                    [Page 26]
-
diff --git a/contrib/bind9/doc/rfc/rfc3655.txt b/contrib/bind9/doc/rfc/rfc3655.txt
deleted file mode 100644
index 13e586b..0000000
--- a/contrib/bind9/doc/rfc/rfc3655.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                      B. Wellington
-Request for Comments: 3655                                O. Gudmundsson
-Updates: 2535                                              November 2003
-Category: Standards Track
-
-
-            Redefinition of DNS Authenticated Data (AD) bit
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-Abstract
-
-   This document alters the specification defined in RFC 2535.  Based on
-   implementation experience, the Authenticated Data (AD) bit in the DNS
-   header is not useful.  This document redefines the AD bit such that
-   it is only set if all answers or records proving that no answers
-   exist in the response has been cryptographically verified or
-   otherwise meets the server's local security policy.
-
-1.  Introduction
-
-   Familiarity with the DNS system [RFC1035] and DNS security extensions
-   [RFC2535] is helpful but not necessary.
-
-   As specified in RFC 2535 (section 6.1), the AD (Authenticated Data)
-   bit indicates in a response that all data included in the answer and
-   authority sections of the response have been authenticated by the
-   server according to the policies of that server.  This is not
-   especially useful in practice, since a conformant server SHOULD never
-   reply with data that failed its security policy.
-
-   This document redefines the AD bit such that it is only set if all
-   data in the response has been cryptographically verified or otherwise
-   meets the server's local security policy.  Thus, neither a response
-   containing properly delegated insecure data, nor a server configured
-   without DNSSEC keys, will have the AD set.  As before, data that
-   failed to verify will not be returned.  An application running on a
-   host that has a trust relationship with the server performing the
-
-
-
-Wellington & Gudmundsson    Standards Track                     [Page 1]
-
-RFC 3655               Redefinition of DNS AD bit          November 2003
-
-
-   recursive query can now use the value of the AD bit to determine
-   whether the data is secure.
-
-1.1.  Motivation
-
-   A full DNSSEC capable resolver called directly from an application
-   can return to the application the security status of the RRsets in
-   the answer.  However, most applications use a limited stub resolver
-   that relies on an external recursive name server which incorporates a
-   full resolver.  The recursive nameserver can use the AD bit in a
-   response to indicate the security status of the data in the answer,
-   and the local resolver can pass this information to the application.
-   The application in this context can be either a human using a DNS
-   tool or a software application.
-
-   The AD bit SHOULD be used by the local resolver if and only if it has
-   been explicitly configured to trust the remote resolver.  The AD bit
-   SHOULD be ignored when the recursive name server is not trusted.
-
-   An alternate solution would be to embed a full DNSSEC resolver into
-   every application, but this has several disadvantages.
-
-   -  DNSSEC validation is both CPU and network intensive, and caching
-      SHOULD be used whenever possible.
-
-   -  DNSSEC requires non-trivial configuration - the root key must be
-      configured, as well as keys for any "islands of security" that
-      will exist until DNSSEC is fully deployed.  The number of
-      configuration points should be minimized.
-
-1.2.  Requirements
-
-   The key words "MAY", "MAY NOT" "MUST", "MUST NOT", "SHOULD", "SHOULD
-   NOT", "RECOMMENDED", in this document are to be interpreted as
-   described in BCP 14, RFC 2119 [RFC2119].
-
-1.3.  Updated documents and sections
-
-   The definition of the AD bit in RFC 2535, Section 6.1, is changed.
-
-2.  Setting of AD bit
-
-   The presence of the CD (Checking Disabled) bit in a query does not
-   affect the setting of the AD bit in the response.  If the CD bit is
-   set, the server will not perform checking, but SHOULD still set the
-   AD bit if the data has already been cryptographically verified or
-
-
-
-
-
-Wellington & Gudmundsson    Standards Track                     [Page 2]
-
-RFC 3655               Redefinition of DNS AD bit          November 2003
-
-
-   complies with local policy.  The AD bit MUST only be set if DNSSEC
-   records have been requested via the DO bit [RFC3225] and relevant SIG
-   records are returned.
-
-2.1.  Setting of AD bit by recursive servers
-
-   Section 6.1 of RFC 2535 says:
-
-   "The AD bit MUST NOT be set on a response unless all of the RRs in
-   the answer and authority sections of the response are either
-   Authenticated or Insecure."
-
-   The replacement text reads:
-
-   "The AD bit MUST NOT be set on a response unless all of the RRsets in
-   the answer and authority sections of the response are Authenticated."
-
-   "The AD bit SHOULD be set if and only if all RRs in the answer
-   section and any relevant negative response RRs in the authority
-   section are Authenticated."
-
-   A recursive DNS server following this modified specification will
-   only set the AD bit when it has cryptographically verified the data
-   in the answer.
-
-2.2.  Setting of AD bit by authoritative servers
-
-   A primary server for a secure zone MAY have the policy of treating
-   authoritative secure zones as Authenticated.  Secondary servers MAY
-   have the same policy, but SHOULD NOT consider zone data Authenticated
-   unless the zone was transferred securely and/or the data was
-   verified.  An authoritative server MUST only set the AD bit for
-   authoritative answers from a secure zone if it has been explicitly
-   configured to do so.  The default for this behavior SHOULD be off.
-
-   Note that having the AD bit clear on an authoritative answer is
-   normal and expected behavior.
-
-2.2.1.  Justification for setting AD bit w/o verifying data
-
-   The setting of the AD bit by authoritative servers affects only the
-   small set of resolvers that are configured to directly query and
-   trust authoritative servers.  This only affects servers that function
-   as both recursive and authoritative.  Iterative resolvers SHOULD
-   ignore the AD bit.
-
-   The cost of verifying all signatures on load by an authoritative
-   server can be high and increases the delay before it can begin
-
-
-
-Wellington & Gudmundsson    Standards Track                     [Page 3]
-
-RFC 3655               Redefinition of DNS AD bit          November 2003
-
-
-   answering queries.  Verifying signatures at query time is also
-   expensive and could lead to resolvers timing out on many queries
-   after the server reloads zones.
-
-   Organizations requiring that all DNS responses contain
-   cryptographically verified data will need to separate the
-   authoritative name server and signature verification functions, since
-   name servers are not required to validate signatures of data for
-   which they are authoritative.
-
-3.  Interpretation of the AD bit
-
-   A response containing data marked Insecure in the answer or authority
-   section MUST never have the AD bit set.  In this case, the resolver
-   SHOULD treat the data as Insecure whether or not SIG records are
-   present.
-
-   A resolver MUST NOT blindly trust the AD bit unless it communicates
-   with a recursive nameserver over a secure transport mechanism or
-   using a message authentication such as TSIG [RFC2845] or SIG(0)
-   [RFC2931] and is explicitly configured to trust this recursive name
-   server.
-
-4.  Applicability statement
-
-   The AD bit is intended to allow the transmission of the indication
-   that a resolver has verified the DNSSEC signatures accompanying the
-   records in the Answer and Authority section.  The AD bit MUST only be
-   trusted when the end consumer of the DNS data has confidence that the
-   intermediary resolver setting the AD bit is trustworthy.  This can
-   only be accomplished via an out of band mechanism such as:
-
-   -  Fiat: An organization that can dictate whether it is OK to trust
-      certain DNS servers.
-
-   -  Personal: Because of a personal relationship or the reputation of
-      a recursive nameserver operator, a DNS consumer can decide to
-      trust that recursive nameserver.
-
-   -  Knowledge: If a recursive nameserver operator posts the configured
-      policy of a recursive nameserver, a consumer can decide that
-      recursive nameserver is trustworthy.
-
-   In the absence of one or more of these factors AD bit from a
-   recursive name server SHOULD NOT be trusted.  For example, home users
-   frequently depend on their ISP to provide recursive DNS service; it
-
-
-
-
-
-Wellington & Gudmundsson    Standards Track                     [Page 4]
-
-RFC 3655               Redefinition of DNS AD bit          November 2003
-
-
-   is not advisable to trust these recursive nameservers.  A
-   roaming/traveling host SHOULD not use recursive DNS servers offered
-   by DHCP when looking up information where security status matters.
-
-   In the latter two cases, the end consumer must also completely trust
-   the path to the trusted recursive name servers, or a secure transport
-   must be employed to protect the traffic.
-
-   When faced with a situation where there are no satisfactory recursive
-   nameservers available, running one locally is RECOMMENDED.  This has
-   the advantage that it can be trusted, and the AD bit can still be
-   used to allow applications to use stub resolvers.
-
-5.  Security Considerations
-
-   This document redefines a bit in the DNS header.  If a resolver
-   trusts the value of the AD bit, it must be sure that the responder is
-   using the updated definition, which is any DNS server/resolver
-   supporting the DO bit [RFC3225].
-
-   Authoritative servers can be explicitly configured to set the AD bit
-   on answers without doing cryptographic checks.  This behavior MUST be
-   off by default.  The only affected resolvers are those that directly
-   query and trust the authoritative server, and this functionality
-   SHOULD only be used on servers that act both as authoritative and
-   recursive name servers.
-
-   Resolvers (full or stub) that blindly trust the AD bit without
-   knowing the security policy of the server generating the answer can
-   not be considered security aware.
-
-   A resolver MUST NOT blindly trust the AD bit unless it communicates
-   such as IPsec, or using message authentication such as TSIG [RFC2845]
-   or SIG(0) [RFC2931].  In addition, the resolver must have been
-   explicitly configured to trust this recursive name server.
-
-6.  IANA Considerations
-
-   None.
-
-7.  Internationalization Considerations
-
-   None.  This document does not change any textual data in any
-   protocol.
-
-
-
-
-
-
-
-Wellington & Gudmundsson    Standards Track                     [Page 5]
-
-RFC 3655               Redefinition of DNS AD bit          November 2003
-
-
-8.  Intellectual Property Rights Notice
-
-   The IETF takes no position regarding the validity or scope of any
-   intellectual property or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; neither does it represent that it
-   has made any effort to identify any such rights.  Information on the
-   IETF's procedures with respect to rights in standards-track and
-   standards-related documentation can be found in BCP-11.  Copies of
-   claims of rights made available for publication and any assurances of
-   licenses to be made available, or the result of an attempt made to
-   obtain a general license or permission for the use of such
-   proprietary rights by implementors or users of this specification can
-   be obtained from the IETF Secretariat.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights which may cover technology that may be required to practice
-   this standard.  Please address the information to the IETF Executive
-   Director.
-
-9.  Acknowledgments
-
-   The following people have provided input on this document: Robert
-   Elz, Andreas Gustafsson, Bob Halley, Steven Jacob, Erik Nordmark,
-   Edward Lewis, Jakob Schlyter, Roy Arends, Ted Lindgreen.
-
-10.  Normative References
-
-   [RFC1035] Mockapetris, P., "Domain Names - Implementation and
-             Specification", STD 13, RFC 1035, November 1987.
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
-             2535, March 1999.
-
-   [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D. and B.
-             Wellington, "Secret Key Transaction Authentication for DNS
-             (TSIG)", RFC 2845, May 2000.
-
-   [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
-             (SIG(0))", RFC 2931, September 2000.
-
-   [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
-             3225, December 2001.
-
-
-
-Wellington & Gudmundsson    Standards Track                     [Page 6]
-
-RFC 3655               Redefinition of DNS AD bit          November 2003
-
-
-11.  Authors' Addresses
-
-   Brian Wellington
-   Nominum Inc.
-   2385 Bay Road
-   Redwood City, CA, 94063
-   USA
-
-   EMail: Brian.Wellington@nominum.com
-
-
-   Olafur Gudmundsson
-   3821 Village Park Drive
-   Chevy Chase, MD, 20815
-   USA
-
-   EMail: ogud@ogud.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wellington & Gudmundsson    Standards Track                     [Page 7]
-
-RFC 3655               Redefinition of DNS AD bit          November 2003
-
-
-12.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assignees.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wellington & Gudmundsson    Standards Track                     [Page 8]
-
diff --git a/contrib/bind9/doc/rfc/rfc3658.txt b/contrib/bind9/doc/rfc/rfc3658.txt
deleted file mode 100644
index 88cfb5a..0000000
--- a/contrib/bind9/doc/rfc/rfc3658.txt
+++ /dev/null
@@ -1,1067 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                     O. Gudmundsson
-Request for Comments: 3658                                 December 2003
-Updates: 3090, 3008, 2535, 1035
-Category: Standards Track
-
-
-              Delegation Signer (DS) Resource Record (RR)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-Abstract
-
-   The delegation signer (DS) resource record (RR) is inserted at a zone
-   cut (i.e., a delegation point) to indicate that the delegated zone is
-   digitally signed and that the delegated zone recognizes the indicated
-   key as a valid zone key for the delegated zone.  The DS RR is a
-   modification to the DNS Security Extensions definition, motivated by
-   operational considerations.  The intent is to use this resource
-   record as an explicit statement about the delegation, rather than
-   relying on inference.
-
-   This document defines the DS RR, gives examples of how it is used and
-   describes the implications on resolvers.  This change is not
-   backwards compatible with RFC 2535.  This document updates RFC 1035,
-   RFC 2535, RFC 3008 and RFC 3090.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gudmundsson                 Standards Track                     [Page 1]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-Table of Contents
-
-   1.  Introduction. . . . . . . . . . . . . . . . . . . . . . . . .   3
-       1.2.  Reserved Words. . . . . . . . . . . . . . . . . . . . .   4
-   2.  Specification of the Delegation key Signer. . . . . . . . . .   4
-       2.1.  Delegation Signer Record Model. . . . . . . . . . . . .   4
-       2.2.  Protocol Change . . . . . . . . . . . . . . . . . . . .   5
-             2.2.1.  RFC 2535 2.3.4 and 3.4: Special Considerations
-                     at Delegation Points  . . . . . . . . . . . . .   6
-                     2.2.1.1. Special processing for DS queries. . .   6
-                     2.2.1.2. Special processing when child and an
-                              ancestor share nameserver. . . . . . .   7
-                     2.2.1.3. Modification on use of KEY RR in the
-                              construction of Responses. . . . . . .   8
-             2.2.2.  Signer's Name (replaces RFC3008 section 2.7). .   9
-             2.2.3.  Changes to RFC 3090 . . . . . . . . . . . . . .   9
-                     2.2.3.1. RFC 3090: Updates to section 1:
-                              Introduction . . . . . . . . . . . . .   9
-                     2.2.3.2. RFC 3090 section 2.1: Globally
-                              Secured. . . . . . . . . . . . . . . .  10
-                     2.2.3.3. RFC 3090 section 3: Experimental
-                              Status . . . . . . . . . . . . . . . .  10
-             2.2.4.  NULL KEY elimination. . . . . . . . . . . . . .  10
-       2.3.  Comments on Protocol Changes. . . . . . . . . . . . . .  10
-       2.4.  Wire Format of the DS record. . . . . . . . . . . . . .  11
-             2.4.1.  Justifications for Fields . . . . . . . . . . .  12
-       2.5.  Presentation Format of the DS Record. . . . . . . . . .  12
-       2.6.  Transition Issues for Installed Base. . . . . . . . . .  12
-             2.6.1.  Backwards compatibility with RFC 2535 and
-                     RFC 1035. . . . . . . . . . . . . . . . . . . .  12
-       2.7.  KEY and corresponding DS record example . . . . . . . .  13
-   3.  Resolver. . . . . . . . . . . . . . . . . . . . . . . . . . .  14
-       3.1.  DS Example" . . . . . . . . . . . . . . . . . . . . . .  14
-       3.2.  Resolver Cost Estimates for DS Records" . . . . . . . .  15
-   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
-   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
-   6.  Intellectual Property Statement . . . . . . . . . . . . . . .  16
-   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  17
-   8.  References. . . . . . . . . . . . . . . . . . . . . . . . . .  17
-       8.1.  Normative References. . . . . . . . . . . . . . . . . .  17
-       8.2.  Informational References. . . . . . . . . . . . . . . .  17
-   9.  Author's Address. . . . . . . . . . . . . . . . . . . . . . .  18
-   10. Full Copyright Statement. . . . . . . . . . . . . . . . . . .  19
-
-
-
-
-
-
-
-
-Gudmundsson                 Standards Track                     [Page 2]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-1.  Introduction
-
-   Familiarity with the DNS system [RFC1035], DNS security extensions
-   [RFC2535], and DNSSEC terminology [RFC3090] is important.
-
-   Experience shows that when the same data can reside in two
-   administratively different DNS zones, the data frequently gets out of
-   sync.  The presence of an NS RRset in a zone anywhere other than at
-   the apex indicates a zone cut or delegation.  The RDATA of the NS
-   RRset specifies the authoritative nameservers for the delegated or
-   "child" zone.  Based on actual measurements, 10-30% of all
-   delegations on the Internet have differing NS RRsets at parent and
-   child.  There are a number of reasons for this, including a lack of
-   communication between parent and child and bogus name servers being
-   listed to meet registry requirements.
-
-   DNSSEC [RFC2535, RFC3008, RFC3090] specifies that a child zone needs
-   to have its KEY RRset signed by its parent to create a verifiable
-   chain of KEYs.  There has been some debate on where the signed KEY
-   RRset should reside, whether at the child [RFC2535] or at the parent.
-   If the KEY RRset resides at the child, maintaining the signed KEY
-   RRset in the child requires frequent two-way communication between
-   the two parties.  First, the child transmits the KEY RRset to the
-   parent and then the parent sends the signature(s) to the child.
-   Storing the KEY RRset at the parent was thought to simplify the
-   communication.
-
-   DNSSEC [RFC2535] requires that the parent store a NULL KEY record for
-   an unsecure child zone to indicate that the child is unsecure.  A
-   NULL KEY record is a waste: an entire signed RRset is used to
-   communicate effectively one bit of information - that the child is
-   unsecure. Chasing down NULL KEY RRsets complicates the resolution
-   process in many cases, because nameservers for both parent and child
-   need to be queried for the KEY RRset if the child nameserver does not
-   return it.  Storing the KEY RRset only in the parent zone simplifies
-   this and would allow the elimination of the NULL KEY RRsets entirely.
-   For large delegation zones, the cost of NULL keys is a significant
-   barrier to deployment.
-
-   Prior to the restrictions imposed by RFC 3445 [RFC3445], another
-   implication of the DNSSEC key model is that the KEY record could be
-   used to store public keys for other protocols in addition to DNSSEC
-   keys.  There are a number of potential problems with this, including:
-
-   1. The KEY RRset can become quite large if many applications and
-      protocols store their keys at the zone apex.  Possible protocols
-      are IPSEC, HTTP, SMTP, SSH and others that use public key
-      cryptography.
-
-
-
-Gudmundsson                 Standards Track                     [Page 3]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-   2. The KEY RRset may require frequent updates.
-
-   3. The probability of compromised or lost keys, which trigger
-      emergency key roll-over procedures, increases.
-
-   4. The parent may refuse to sign KEY RRsets with non-DNSSEC zone
-      keys.
-
-   5. The parent may not meet the child's expectations of turnaround
-      time for resigning the KEY RRset.
-
-   Given these reasons, SIG@parent isn't any better than SIG/KEY@Child.
-
-1.2.  Reserved Words
-
-   The key words "MAY", "MAY NOT", "MUST", "MUST NOT", "REQUIRED",
-   "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be
-   interpreted as described in BCP 14, RFC 2119 [RFC2119].
-
-2.  Specification of the Delegation key Signer
-
-   This section defines the Delegation Signer (DS) RR type (type code
-   43) and the changes to DNS to accommodate it.
-
-2.1.  Delegation Signer Record Model
-
-   This document presents a replacement for the DNSSEC KEY record chain
-   of trust [RFC2535] that uses a new RR that resides only at the
-   parent.  This record identifies the key(s) that the child uses to
-   self-sign its own KEY RRset.
-
-   Even though DS identifies two roles for KEYs, Key Signing Key (KSK)
-   and Zone Signing Key (ZSK), there is no requirement that zone uses
-   two different keys for these roles.  It is expected that many small
-   zones will only use one key, while larger zones will be more likely
-   to use multiple keys.
-
-   The chain of trust is now established by verifying the parent KEY
-   RRset, the DS RRset from the parent and the KEY RRset at the child.
-   This is cryptographically equivalent to using just KEY records.
-
-   Communication between the parent and child is greatly reduced, since
-   the child only needs to notify the parent about changes in keys that
-   sign its apex KEY RRset.  The parent is ignorant of all other keys in
-   the child's apex KEY RRset.  Furthermore, the child maintains full
-   control over the apex KEY RRset and its content.  The child can
-   maintain any policies regarding its KEY usage for DNSSEC with minimal
-   impact on the parent.  Thus, if the child wants to have frequent key
-
-
-
-Gudmundsson                 Standards Track                     [Page 4]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-   roll-over for its DNS zone keys, the parent does not need to be aware
-   of it.  The child can use one key to sign only its apex KEY RRset and
-   a different key to sign the other RRsets in the zone.
-
-   This model fits well with a slow roll out of DNSSEC and the islands
-   of security model.  In this model, someone who trusts "good.example."
-   can preconfigure a key from "good.example." as a trusted key, and
-   from then on trusts any data signed by that key or that has a chain
-   of trust to that key.  If "example." starts advertising DS records,
-   "good.example." does not have to change operations by suspending
-   self-signing.  DS records can be used in configuration files to
-   identify trusted keys instead of KEY records.  Another significant
-   advantage is that the amount of information stored in large
-   delegation zones is reduced: rather than the NULL KEY record at every
-   unsecure delegation demanded by RFC 2535, only secure delegations
-   require additional information in the form of a signed DS RRset.
-
-   The main disadvantage of this approach is that verifying a zone's KEY
-   RRset requires two signature verification operations instead of the
-   one in RFC 2535 chain of trust.  There is no impact on the number of
-   signatures verified for other types of RRsets.
-
-2.2.  Protocol Change
-
-   All DNS servers and resolvers that support DS MUST support the OK bit
-   [RFC3225] and a larger message size [RFC3226].  In order for a
-   delegation to be considered secure the delegation MUST contain a DS
-   RRset.  If a query contains the OK bit, a nameserver returning a
-   referral for the delegation MUST include the following RRsets in the
-   authority section in this order:
-
-   If DS RRset is present:
-      parent's copy of child's NS RRset
-      DS and SIG(DS)
-
-   If no DS RRset is present:
-      parent's copy of child's NS RRset
-      parent's zone NXT and SIG(NXT)
-
-   This increases the size of referral messages, possibly causing some
-   or all glue to be omitted.  If the DS or NXT RRsets with signatures
-   do not fit in the DNS message, the TC bit MUST be set.  Additional
-   section processing is not changed.
-
-   A DS RRset accompanying a NS RRset indicates that the child zone is
-   secure.  If a NS RRset exists without a DS RRset, the child zone is
-   unsecure (from the parents point of view).  DS RRsets MUST NOT appear
-   at non-delegation points or at a zone's apex.
-
-
-
-Gudmundsson                 Standards Track                     [Page 5]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-   Section 2.2.1 defines special considerations related to authoritative
-   nameservers responding to DS queries and replaces RFC 2535 sections
-   2.3.4 and 3.4.  Section 2.2.2 replaces RFC 3008 section 2.7, and
-   section 2.2.3 updates RFC 3090.
-
-2.2.1.  RFC 2535 2.3.4 and 3.4: Special Considerations at Delegation
-        Points
-
-   DNS security views each zone as a unit of data completely under the
-   control of the zone owner with each entry (RRset) signed by a special
-   private key held by the zone manager.  But the DNS protocol views the
-   leaf nodes in a zone that are also the apex nodes of a child zone
-   (i.e., delegation points) as "really" belonging to the child zone.
-   The corresponding domain names appear in two master files and might
-   have RRsets signed by both the parent and child zones' keys.  A
-   retrieval could get a mixture of these RRsets and SIGs, especially
-   since one nameserver could be serving both the zone above and below a
-   delegation point [RFC2181].
-
-   Each DS RRset stored in the parent zone MUST be signed by at least
-   one of the parent zone's private keys.  The parent zone MUST NOT
-   contain a KEY RRset at any delegation point.  Delegations in the
-   parent MAY contain only the following RR types: NS, DS, NXT and SIG.
-   The NS RRset MUST NOT be signed.  The NXT RRset is the exceptional
-   case: it will always appear differently and authoritatively in both
-   the parent and child zones, if both are secure.
-
-   A secure zone MUST contain a self-signed KEY RRset at its apex.  Upon
-   verifying the DS RRset from the parent, a resolver MAY trust any KEY
-   identified in the DS RRset as a valid signer of the child's apex KEY
-   RRset.  Resolvers configured to trust one of the keys signing the KEY
-   RRset MAY now treat any data signed by the zone keys in the KEY RRset
-   as secure.  In all other cases, resolvers MUST consider the zone
-   unsecure.
-
-   An authoritative nameserver queried for type DS MUST return the DS
-   RRset in the answer section.
-
-2.2.1.1.  Special processing for DS queries
-
-   When a nameserver is authoritative for the parent zone at a
-   delegation point and receives a query for the DS record at that name,
-   it MUST answer based on data in the parent zone, return DS or
-   negative answer.  This is true whether or not it is also
-   authoritative for the child zone.
-
-
-
-
-
-
-Gudmundsson                 Standards Track                     [Page 6]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-   When the nameserver is authoritative for the child zone at a
-   delegation point but not the parent zone, there is no natural
-   response, since the child zone is not authoritative for the DS record
-   at the zone's apex.  As these queries are only expected to originate
-   from recursive nameservers which are not DS-aware, the authoritative
-   nameserver MUST answer with:
-
-      RCODE:             NOERROR
-      AA bit:            set
-      Answer Section:    Empty
-      Authority Section: SOA [+ SIG(SOA) + NXT + SIG(NXT)]
-
-   That is, it answers as if it is authoritative and the DS record does
-   not exist.  DS-aware recursive nameservers will query the parent zone
-   at delegation points, so will not be affected by this.
-
-   A nameserver authoritative for only the child zone, that is also a
-   caching server MAY (if the RD bit is set in the query) perform
-   recursion to find the DS record at the delegation point, or MAY
-   return the DS record from its cache.  In this case, the AA bit MUST
-   NOT be set in the response.
-
-2.2.1.2.  Special processing when child and an ancestor share
-          nameserver
-
-   Special rules are needed to permit DS RR aware nameservers to
-   gracefully interact with older caches which otherwise might falsely
-   label a nameserver as lame because of the placement of the DS RR set.
-
-   Such a situation might arise when a nameserver is authoritative for
-   both a zone and it's grandparent, but not the parent.  This sounds
-   like an obscure example, but it is very real.  The root zone is
-   currently served on 13 machines, and "root-servers.net." is served on
-   4 of the 13, but "net." is severed on different nameservers.
-
-   When a nameserver receives a query for (<QNAME>, DS, <QCLASS>), the
-   response MUST be determined from reading these rules in order:
-
-   1) If the nameserver is authoritative for the zone that holds the DS
-      RR set (i.e., the zone that delegates <QNAME>, a.k.a. the "parent"
-      zone), the response contains the DS RR set as an authoritative
-      answer.
-
-   2) If the nameserver is offering recursive service and the RD bit is
-      set in the query, the nameserver performs the query itself
-      (according to the rules for resolvers described below) and returns
-      its findings.
-
-
-
-
-Gudmundsson                 Standards Track                     [Page 7]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-   3) If the nameserver is authoritative for the zone that holds the
-      <QNAME>'s SOA RR set, the response is an authoritative negative
-      answer as described in 2.2.1.1.
-
-   4) If the nameserver is authoritative for a zone or zones above the
-      QNAME, a referral to the most enclosing (deepest match) zone's
-      servers is made.
-
-   5) If the nameserver is not authoritative for any part of the QNAME,
-      a response indicating a lame nameserver for QNAME is given.
-
-   Using these rules will require some special processing on the part of
-   a DS RR aware resolver.  To illustrate this, an example is used.
-
-   Assuming a nameserver is authoritative for roots.example.net. and for
-   the root zone but not the intervening two zones (or the intervening
-   two label deep zone).  Assume that QNAME=roots.example.net.,
-   QTYPE=DS, and QCLASS=IN.
-
-   The resolver will issue this request (assuming no cached data)
-   expecting a referral to a nameserver for .net.  Instead, rule number
-   3 above applies and a negative answer is returned by the nameserver.
-   The reaction by the resolver is not to accept this answer as final,
-   as it can determine from the SOA RR in the negative answer the
-   context within which the nameserver has answered.
-
-   A solution would be to instruct the resolver to hunt for the
-   authoritative zone of the data in a brute force manner.
-
-   This can be accomplished by taking the owner name of the returned SOA
-   RR and striping off enough left-hand labels until a successful NS
-   response is obtained.  A successful response here means that the
-   answer has NS records in it.  (Entertaining the possibility that a
-   cut point can be two labels down in a zone.)
-
-   Returning to the example, the response will include a negative answer
-   with either the SOA RR for "roots.example.net." or "example.net."
-   depending on whether roots.example.net is a delegated domain.  In
-   either case, removing the left most label of the SOA owner name will
-   lead to the location of the desired data.
-
-2.2.1.3.  Modification on use of KEY RR in the construction of Responses
-
-   This section updates RFC 2535 section 3.5 by replacing it with the
-   following:
-
-
-
-
-
-
-Gudmundsson                 Standards Track                     [Page 8]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-   A query for KEY RR MUST NOT trigger any additional section
-   processing.  Security aware resolvers will include corresponding SIG
-   records in the answer section.
-
-   KEY records SHOULD NOT be added to the additional records section in
-   response to any query.
-
-   RFC 2535 specified that KEY records be added to the additional
-   section when SOA or NS records were included in an answer.  This was
-   done to reduce round trips (in the case of SOA) and to force out NULL
-   KEYs (in the NS case).  As this document obsoletes NULL keys, there
-   is no need for the inclusion of KEYs with NSs.  Furthermore, as SOAs
-   are included in the authority section of negative answers, including
-   the KEYs each time will cause redundant transfers of KEYs.
-
-   RFC 2535 section 3.5 also included a rule for adding the KEY RRset to
-   the response for a query for A and AAAA types.  As Restrict KEY
-   [RFC3445] eliminated use of KEY RR by all applications, this rule is
-   no longer needed.
-
-2.2.2.  Signer's Name (replaces RFC 3008 section 2.7)
-
-   The signer's name field of a SIG RR MUST contain the name of the zone
-   to which the data and signature belong.  The combination of signer's
-   name, key tag, and algorithm MUST identify a zone key if the SIG is
-   to be considered material.  This document defines a standard policy
-   for DNSSEC validation; local policy MAY override the standard policy.
-
-   There are no restrictions on the signer field of a SIG(0) record. The
-   combination of signer's name, key tag, and algorithm MUST identify a
-   key if this SIG(0) is to be processed.
-
-2.2.3.  Changes to RFC 3090
-
-   A number of sections in RFC 3090 need to be updated to reflect the DS
-   record.
-
-2.2.3.1.  RFC 3090: Updates to section 1: Introduction
-
-   Most of the text is still relevant but the words "NULL key" are to be
-   replaced with "missing DS RRset".  In section 1.3, the last three
-   paragraphs discuss the confusion in sections of RFC 2535 that are
-   replaced in section 2.2.1 above.  Therefore, these paragraphs are now
-   obsolete.
-
-
-
-
-
-
-
-Gudmundsson                 Standards Track                     [Page 9]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-2.2.3.2.  RFC 3090 section 2.1: Globally Secured
-
-   Rule 2.1.b is replaced by the following rule:
-
-   2.1.b. The KEY RRset at a zone's apex MUST be self-signed by a
-   private key whose public counterpart MUST appear in a zone signing
-   KEY RR (2.a) owned by the zone's apex and specifying a mandatory-to-
-   implement algorithm.  This KEY RR MUST be identified by a DS RR in a
-   signed DS RRset in the parent zone.
-
-   If a zone cannot get its parent to advertise a DS record for it, the
-   child zone cannot be considered globally secured.  The only exception
-   to this is the root zone, for which there is no parent zone.
-
-2.2.3.3.  RFC 3090 section 3: Experimental Status.
-
-   The only difference between experimental status and globally secured
-   is the missing DS RRset in the parent zone.  All locally secured
-   zones are experimental.
-
-2.2.4.  NULL KEY elimination
-
-   RFC 3445 section 3 eliminates the top two bits in the flags field of
-   KEY RR.  These two bits were used to indicate NULL KEY or NO KEY. RFC
-   3090 defines that zone as either secure or not and these rules
-   eliminate the need to put NULL keys in the zone apex to indicate that
-   the zone is not secured for a algorithm.  Along with this document,
-   these other two eliminate all uses for the NULL KEY.  This document
-   obsoletes NULL KEY.
-
-2.3.  Comments on Protocol Changes
-
-   Over the years, there have been various discussions surrounding the
-   DNS delegation model, declaring it to be broken because there is no
-   good way to assert if a delegation exists.  In the RFC 2535 version
-   of DNSSEC, the presence of the NS bit in the NXT bit map proves there
-   is a delegation at this name.  Something more explicit is required
-   and the DS record addresses this need for secure delegations.
-
-   The DS record is a major change to DNS: it is the first resource
-   record that can appear only on the upper side of a delegation.
-   Adding it will cause interoperability problems and requires a flag
-   day for DNSSEC.  Many old nameservers and resolvers MUST be upgraded
-   to take advantage of DS.  Some old nameservers will be able to be
-   authoritative for zones with DS records but will not add the NXT or
-   DS records to the authority section.  The same is true for caching
-   nameservers; in fact, some might even refuse to pass on the DS or NXT
-   records.
-
-
-
-Gudmundsson                 Standards Track                    [Page 10]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-2.4.  Wire Format of the DS record
-
-   The DS (type=43) record contains these fields: key tag, algorithm,
-   digest type, and the digest of a public key KEY record that is
-   allowed and/or used to sign the child's apex KEY RRset.  Other keys
-   MAY sign the child's apex KEY RRset.
-
-                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |           key tag             |  algorithm    |  Digest type  |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                digest  (length depends on type)               |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                (SHA-1 digest is 20 bytes)                     |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                                                               |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
-   |                                                               |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
-   |                                                               |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   The key tag is calculated as specified in RFC 2535.  Algorithm MUST
-   be allowed to sign DNS data.  The digest type is an identifier for
-   the digest algorithm used.  The digest is calculated over the
-   canonical name of the delegated domain name followed by the whole
-   RDATA of the KEY record (all four fields).
-
-      digest = hash( canonical FQDN on KEY RR | KEY_RR_rdata)
-
-      KEY_RR_rdata = Flags | Protocol | Algorithm | Public Key
-
-   Digest type value 0 is reserved, value 1 is SHA-1, and reserving
-   other types requires IETF standards action.  For interoperability
-   reasons, keeping number of digest algorithms low is strongly
-   RECOMMENDED.  The only reason to reserve additional digest types is
-   to increase security.
-
-   DS records MUST point to zone KEY records that are allowed to
-   authenticate DNS data.  The indicated KEY records protocol field MUST
-   be set to 3; flag field bit 7 MUST be set to 1.  The value of other
-   flag bits is not significant for the purposes of this document.
-
-   The size of the DS RDATA for type 1 (SHA-1) is 24 bytes, regardless
-   of key size.  New digest types probably will have larger digests.
-
-
-
-
-
-Gudmundsson                 Standards Track                    [Page 11]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-2.4.1.  Justifications for Fields
-
-   The algorithm and key tag fields are present to allow resolvers to
-   quickly identify the candidate KEY records to examine.  SHA-1 is a
-   strong cryptographic checksum: it is computationally infeasible for
-   an attacker to generate a KEY record that has the same SHA-1 digest.
-   Combining the name of the key and the key rdata as input to the
-   digest provides stronger assurance of the binding.  Having the key
-   tag in the DS record adds greater assurance than the SHA-1 digest
-   alone, as there are now two different mapping functions.
-
-   This format allows concise representation of the keys that the child
-   will use, thus keeping down the size of the answer for the
-   delegation, reducing the probability of DNS message overflow.  The
-   SHA-1 hash is strong enough to uniquely identify the key and is
-   similar to the PGP key footprint.  The digest type field is present
-   for possible future expansion.
-
-   The DS record is well suited to listing trusted keys for islands of
-   security in configuration files.
-
-2.5.  Presentation Format of the DS Record
-
-   The presentation format of the DS record consists of three numbers
-   (key tag, algorithm, and digest type) followed by the digest itself
-   presented in hex:
-
-      example.   DS  12345 3 1 123456789abcdef67890123456789abcdef67890
-
-2.6.  Transition Issues for Installed Base
-
-   No backwards compatibility with RFC 2535 is provided.
-
-   RFC 2535-compliant resolvers will assume that all DS-secured
-   delegations are locally secure.  This is bad, but the DNSEXT Working
-   Group has determined that rather than dealing with both RFC 2535-
-   secured zones and DS-secured zones, a rapid adoption of DS is
-   preferable.  Thus, the only option for early adopters is to upgrade
-   to DS as soon as possible.
-
-2.6.1.  Backwards compatibility with RFC 2535 and RFC 1035
-
-   This section documents how a resolver determines the type of
-   delegation.
-
-
-
-
-
-
-
-Gudmundsson                 Standards Track                    [Page 12]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-   RFC 1035 delegation (in parent) has:
-
-   RFC 1035           NS
-
-   RFC 2535 adds the following two cases:
-
-   Secure RFC 2535:   NS + NXT + SIG(NXT)
-                      NXT bit map contains: NS SIG NXT
-   Unsecure RFC 2535: NS + KEY + SIG(KEY) + NXT + SIG(NXT)
-                      NXT bit map contains: NS SIG KEY NXT
-                      KEY must be a NULL key.
-
-   DNSSEC with DS has the following two states:
-
-   Secure DS:         NS + DS + SIG(DS)
-                      NXT bit map contains: NS SIG NXT DS
-   Unsecure DS:       NS + NXT + SIG(NXT)
-                      NXT bit map contains: NS SIG NXT
-
-   It is difficult for a resolver to determine if a delegation is secure
-   RFC 2535 or unsecure DS.  This could be overcome by adding a flag to
-   the NXT bit map, but only upgraded resolvers would understand this
-   flag, anyway.  Having both parent and child signatures for a KEY
-   RRset might allow old resolvers to accept a zone as secure, but the
-   cost of doing this for a long time is much higher than just
-   prohibiting RFC 2535-style signatures at child zone apexes and
-   forcing rapid deployment of DS-enabled nameservers and resolvers.
-
-   RFC 2535 and DS can, in theory, be deployed in parallel, but this
-   would require resolvers to deal with RFC 2535 configurations forever.
-   This document obsoletes the NULL KEY in parent zones, which is a
-   difficult enough change that to cause a flag day.
-
-2.7.  KEY and corresponding DS record example
-
-   This is an example of a KEY record and the corresponding DS record.
-
-   dskey.example. KEY  256 3 1 (
-                  AQPwHb4UL1U9RHaU8qP+Ts5bVOU1s7fYbj2b3CCbzNdj
-                  4+/ECd18yKiyUQqKqQFWW5T3iVc8SJOKnueJHt/Jb/wt
-                  ) ; key id = 28668
-             DS   28668 1  1  49FD46E6C4B45C55D4AC69CBD3CD34AC1AFE51DE
-
-
-
-
-
-
-
-
-
-Gudmundsson                 Standards Track                    [Page 13]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-3.  Resolver
-
-3.1.  DS Example
-
-   To create a chain of trust, a resolver goes from trusted KEY to DS to
-   KEY.
-
-      Assume the key for domain "example." is trusted.  Zone "example."
-      contains at least the following records:
-      example.          SOA     <soa stuff>
-      example.          NS       ns.example.
-      example.          KEY     <stuff>
-      example.          NXT      secure.example. NS SOA KEY SIG NXT
-      example.          SIG(SOA)
-      example.          SIG(NS)
-      example.          SIG(NXT)
-      example.          SIG(KEY)
-      secure.example.   NS      ns1.secure.example.
-      secure.example.   DS      tag=12345 alg=3 digest_type=1 <foofoo>
-      secure.example.   NXT     unsecure.example. NS SIG NXT DS
-      secure.example.   SIG(NXT)
-      secure.example.   SIG(DS)
-      unsecure.example  NS      ns1.unsecure.example.
-      unsecure.example. NXT     example. NS SIG NXT
-      unsecure.example. SIG(NXT)
-
-      In zone "secure.example." following records exist:
-      secure.example.   SOA      <soa stuff>
-      secure.example.   NS       ns1.secure.example.
-      secure.example.   KEY      <tag=12345 alg=3>
-      secure.example.   KEY      <tag=54321 alg=5>
-      secure.example.   NXT      <nxt stuff>
-      secure.example.   SIG(KEY) <key-tag=12345 alg=3>
-      secure.example.   SIG(SOA) <key-tag=54321 alg=5>
-      secure.example.   SIG(NS)  <key-tag=54321 alg=5>
-      secure.example.   SIG(NXT) <key-tag=54321 alg=5>
-
-   In this example, the private key for "example." signs the DS record
-   for "secure.example.", making that a secure delegation.  The DS
-   record states which key is expected to sign the KEY RRset at
-   "secure.example.".  Here "secure.example." signs its KEY RRset with
-   the KEY identified in the DS RRset, thus the KEY RRset is validated
-   and trusted.
-
-   This example has only one DS record for the child, but parents MUST
-   allow multiple DS records to facilitate key roll-over and multiple
-   KEY algorithms.
-
-
-
-
-Gudmundsson                 Standards Track                    [Page 14]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-   The resolver determines the security status of "unsecure.example." by
-   examining the parent zone's NXT record for this name.  The absence of
-   the DS bit indicates an unsecure delegation.  Note the NXT record
-   SHOULD only be examined after verifying the corresponding signature.
-
-3.2.  Resolver Cost Estimates for DS Records
-
-   From a RFC 2535 recursive resolver point of view, for each delegation
-   followed to chase down an answer, one KEY RRset has to be verified.
-   Additional RRsets might also need to be verified based on local
-   policy (e.g., the contents of the NS RRset).  Once the resolver gets
-   to the appropriate delegation, validating the answer might require
-   verifying one or more signatures.  A simple A record lookup requires
-   at least N delegations to be verified and one RRset.  For a DS-
-   enabled recursive resolver, the cost is 2N+1.  For an MX record,
-   where the target of the MX record is in the same zone as the MX
-   record, the costs are N+2 and 2N+2, for RFC 2535 and DS,
-   respectively.  In the case of a negative answer, the same ratios hold
-   true.
-
-   The recursive resolver has to do an extra query to get the DS record,
-   which will increase the overall cost of resolving this question, but
-   it will never be worse than chasing down NULL KEY records from the
-   parent in RFC 2535 DNSSEC.
-
-   DS adds processing overhead on resolvers and increases the size of
-   delegation answers, but much less than storing signatures in the
-   parent zone.
-
-4.  Security Considerations
-
-   This document proposes a change to the validation chain of KEY
-   records in DNSSEC.  The change is not believed to reduce security in
-   the overall system.  In RFC 2535 DNSSEC, the child zone has to
-   communicate keys to its parent and prudent parents will require some
-   authentication with that transaction.  The modified protocol will
-   require the same authentication, but allows the child to exert more
-   local control over its own KEY RRset.
-
-   There is a remote possibility that an attacker could generate a valid
-   KEY that matches all the DS fields, of a specific DS set, and thus
-   forge data from the child.  This possibility is considered
-   impractical, as on average more than
-
-      2 ^ (160 - <Number of keys in DS set>)
-
-   keys would have to be generated before a match would be found.
-
-
-
-
-Gudmundsson                 Standards Track                    [Page 15]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-   An attacker that wants to match any DS record will have to generate
-   on average at least 2^80 keys.
-
-   The DS record represents a change to the DNSSEC protocol and there is
-   an installed base of implementations, as well as textbooks on how to
-   set up secure delegations.  Implementations that do not understand
-   the DS record will not be able to follow the KEY to DS to KEY chain
-   and will consider all zones secured that way as unsecure.
-
-5.  IANA Considerations
-
-   IANA has allocated an RR type code for DS from the standard RR type
-   space (type 43).
-
-   IANA has established a new registry for the DS RR type for digest
-   algorithms.  Defined types are:
-
-      0 is Reserved,
-      1 is SHA-1.
-
-   Adding new reservations requires IETF standards action.
-
-6.  Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   intellectual property or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; neither does it represent that it
-   has made any effort to identify any such rights.  Information on the
-   IETF's procedures with respect to rights in standards-track and
-   standards-related documentation can be found in BCP-11.  Copies of
-   claims of rights made available for publication and any assurances of
-   licenses to be made available, or the result of an attempt made to
-   obtain a general license or permission for the use of such
-   proprietary rights by implementors or users of this specification can
-   be obtained from the IETF Secretariat.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights which may cover technology that may be required to practice
-   this standard.  Please address the information to the IETF Executive
-   Director.
-
-
-
-
-
-
-
-
-Gudmundsson                 Standards Track                    [Page 16]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-7.  Acknowledgments
-
-   Over the last few years a number of people have contributed ideas
-   that are captured in this document.  The core idea of using one key
-   to sign only the KEY RRset comes from discussions with Bill Manning
-   and Perry Metzger on how to put in a single root key in all
-   resolvers. Alexis Yushin, Brian Wellington, Sam Weiler, Paul Vixie,
-   Jakob Schlyter, Scott Rose, Edward Lewis, Lars-Johan Liman, Matt
-   Larson, Mark Kosters, Dan Massey, Olaf Kolman, Phillip Hallam-Baker,
-   Miek Gieben, Havard Eidnes, Donald Eastlake 3rd., Randy Bush, David
-   Blacka, Steve Bellovin, Rob Austein, Derek Atkins, Roy Arends, Mark
-   Andrews, Harald Alvestrand, and others have provided useful comments.
-
-8.  References
-
-8.1.  Normative References
-
-   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
-              Specification", STD 13, RFC 1035, November 1987.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
-              RFC 2535, March 1999.
-
-   [RFC3008]  Wellington, B., "Domain Name System Security (DNSSEC)
-              Signing Authority", RFC 3008, November 2000.
-
-   [RFC3090]  Lewis, E., "DNS Security Extension Clarification on Zone
-              Status", RFC 3090, March 2001.
-
-   [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
-              3225, December 2001.
-
-   [RFC3445]  Massey, D. and S. Rose, "Limiting the scope of the KEY
-              Resource Record (RR)", RFC 3445, December 2002.
-
-8.2.  Informational References
-
-   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
-              Specification", RFC 2181, July 1997.
-
-   [RFC3226]  Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
-              message size requirements", RFC 3226, December 2001.
-
-
-
-
-
-
-Gudmundsson                 Standards Track                    [Page 17]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-9.  Author's Address
-
-   Olafur Gudmundsson
-   3821 Village Park Drive
-   Chevy Chase, MD,  20815
-
-   EMail: ds-rfc@ogud.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gudmundsson                 Standards Track                    [Page 18]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-10.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assignees.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gudmundsson                 Standards Track                    [Page 19]
-
diff --git a/contrib/bind9/doc/rfc/rfc3757.txt b/contrib/bind9/doc/rfc/rfc3757.txt
deleted file mode 100644
index 31890a4..0000000
--- a/contrib/bind9/doc/rfc/rfc3757.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         O. Kolkman
-Request for Comments: 3757                                      RIPE NCC
-Updates: 3755, 2535                                          J. Schlyter
-Category: Standards Track                                         NIC-SE
-                                                                E. Lewis
-                                                                    ARIN
-                                                              April 2004
-
-
-         Domain Name System KEY (DNSKEY) Resource Record (RR)
-                     Secure Entry Point (SEP) Flag
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-Abstract
-
-   With the Delegation Signer (DS) resource record (RR), the concept of
-   a public key acting as a secure entry point (SEP) has been
-   introduced.  During exchanges of public keys with the parent there is
-   a need to differentiate SEP keys from other public keys in the Domain
-   Name System KEY (DNSKEY) resource record set.  A flag bit in the
-   DNSKEY RR is defined to indicate that DNSKEY is to be used as a SEP.
-   The flag bit is intended to assist in operational procedures to
-   correctly generate DS resource records, or to indicate what DNSKEYs
-   are intended for static configuration.  The flag bit is not to be
-   used in the DNS verification protocol.  This document updates RFC
-   2535 and RFC 3755.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman, et al.              Standard Track                     [Page 1]
-
-RFC 3757                   DNSKEY RR SEP Flag                 April 2004
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
-   2.  The Secure Entry Point (SEP) Flag. . . . . . . . . . . . . . .  4
-   3.  DNSSEC Protocol Changes. . . . . . . . . . . . . . . . . . . .  4
-   4.  Operational Guidelines . . . . . . . . . . . . . . . . . . . .  4
-   5.  Security Considerations. . . . . . . . . . . . . . . . . . . .  5
-   6.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . .  6
-   7.  Internationalization Considerations. . . . . . . . . . . . . .  6
-   8.  Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . .  6
-   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  6
-       9.1.  Normative References . . . . . . . . . . . . . . . . . .  6
-       9.2.  Informative References . . . . . . . . . . . . . . . . .  6
-   10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  7
-   11. Full Copyright Statement . . . . . . . . . . . . . . . . . . .  8
-
-1.  Introduction
-
-   "All keys are equal but some keys are more equal than others" [6].
-
-   With the definition of the Delegation Signer Resource Record (DS RR)
-   [5], it has become important to differentiate between the keys in the
-   DNSKEY RR set that are (to be) pointed to by parental DS RRs and the
-   other keys in the DNSKEY RR set.  We refer to these public keys as
-   Secure Entry Point (SEP) keys.  A SEP key either used to generate a
-   DS RR or is distributed to resolvers that use the key as the root of
-   a trusted subtree [3].
-
-   In early deployment tests, the use of two (kinds of) key pairs for
-   each zone has been prevalent.  For one kind of key pair the private
-   key is used to sign just the zone's DNSKEY resource record (RR) set.
-   Its public key is intended to be referenced by a DS RR at the parent
-   or configured statically in a resolver.  The private key of the other
-   kind of key pair is used to sign the rest of the zone's data sets.
-   The former key pair is called a key-signing key (KSK) and the latter
-   is called a zone-signing key (ZSK).  In practice there have been
-   usually one of each kind of key pair, but there will be multiples of
-   each at times.
-
-   It should be noted that division of keys pairs into KSK's and ZSK's
-   is not mandatory in any definition of DNSSEC, not even with the
-   introduction of the DS RR.  But, in testing, this distinction has
-   been helpful when designing key roll over (key super-cession)
-   schemes.  Given that the distinction has proven helpful, the labels
-   KSK and ZSK have begun to stick.
-
-
-
-
-
-
-Kolkman, et al.              Standard Track                     [Page 2]
-
-RFC 3757                   DNSKEY RR SEP Flag                 April 2004
-
-
-   There is a need to differentiate the public keys for the key pairs
-   that are used for key signing from keys that are not used key signing
-   (KSKs vs ZSKs).  This need is driven by knowing which DNSKEYs are to
-   be sent for generating DS RRs, which DNSKEYs are to be distributed to
-   resolvers, and which keys are fed to the signer application at the
-   appropriate time.
-
-   In other words, the SEP bit provides an in-band method to communicate
-   a DNSKEY RR's intended use to third parties.  As an example we
-   present 3 use cases in which the bit is useful:
-
-      The parent is a registry, the parent and the child use secured DNS
-      queries and responses, with a preexisting trust-relation, or plain
-      DNS over a secured channel to exchange the child's DNSKEY RR sets.
-      Since a DNSKEY RR set will contain a complete DNSKEY RRset the SEP
-      bit can be used to isolate the DNSKEYs for which a DS RR needs to
-      be created.
-
-      An administrator has configured a DNSKEY as root for a trusted
-      subtree into security aware resolver.  Using a special purpose
-      tool that queries for the KEY RRs from that domain's apex, the
-      administrator will be able to notice the roll over of the trusted
-      anchor by a change of the subset of KEY RRs with the DS flag set.
-
-      A signer might use the SEP bit on the public key to determine
-      which private key to use to exclusively sign the DNSKEY RRset and
-      which private key to use to sign the other RRsets in the zone.
-
-   As demonstrated in the above examples it is important to be able to
-   differentiate the SEP keys from the other keys in a DNSKEY RR set in
-   the flow between signer and (parental) key-collector and in the flow
-   between the signer and the resolver configuration.  The SEP flag is
-   to be of no interest to the flow between the verifier and the
-   authoritative data store.
-
-   The reason for the term "SEP" is a result of the observation that the
-   distinction between KSK and ZSK key pairs is made by the signer, a
-   key pair could be used as both a KSK and a ZSK at the same time.  To
-   be clear, the term SEP was coined to lessen the confusion caused by
-   the overlap.  (Once this label was applied, it had the side effect of
-   removing the temptation to have both a KSK flag bit and a ZSK flag
-   bit.)
-
-   The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED",
-   "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be
-   interpreted as described in BCP 14, RFC 2119 [1].
-
-
-
-
-
-Kolkman, et al.              Standard Track                     [Page 3]
-
-RFC 3757                   DNSKEY RR SEP Flag                 April 2004
-
-
-2.  The Secure Entry Point (SEP) Flag
-
-                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |              flags          |S|   protocol    |   algorithm   |
-   |                             |E|               |               |
-   |                             |P|               |               |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                                                               /
-   /                        public key                             /
-   /                                                               /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-                          DNSKEY RR Format
-   This document assigns the 15th bit in the flags field as the secure
-   entry point (SEP) bit.  If the bit is set to 1 the key is intended to
-   be used as secure entry point key.  One SHOULD NOT assign special
-   meaning to the key if the bit is set to 0.  Operators can recognize
-   the secure entry point key by the even or odd-ness of the decimal
-   representation of the flag field.
-
-3.  DNSSEC Protocol Changes
-
-   The bit MUST NOT be used during the resolving and verification
-   process.  The SEP flag is only used to provide a hint about the
-   different administrative properties of the key and therefore the use
-   of the SEP flag does not change the DNS resolution protocol or the
-   resolution process.
-
-4.  Operational Guidelines
-
-   The SEP bit is set by the key-pair-generator and MAY be used by the
-   zone signer to decide whether the public part of the key pair is to
-   be prepared for input to a DS RR generation function.  The SEP bit is
-   recommended to be set (to 1) whenever the public key of the key pair
-   will be distributed to the parent zone to build the authentication
-   chain or if the public key is to be distributed for static
-   configuration in verifiers.
-
-   When a key pair is created, the operator needs to indicate whether
-   the SEP bit is to be set in the DNSKEY RR.  As the SEP bit is within
-   the data that is used to compute the 'key tag field' in the SIG RR,
-   changing the SEP bit will change the identity of the key within DNS.
-   In other words, once a key is used to generate signatures, the
-   setting of the SEP bit is to remain constant.  If not, a verifier
-   will not be able to find the relevant KEY RR.
-
-
-
-
-Kolkman, et al.              Standard Track                     [Page 4]
-
-RFC 3757                   DNSKEY RR SEP Flag                 April 2004
-
-
-   When signing a zone, it is intended that the key(s) with the SEP bit
-   set (if such keys exist) are used to sign the KEY RR set of the zone.
-   The same key can be used to sign the rest of the zone data too.  It
-   is conceivable that not all keys with a SEP bit set will sign the
-   DNSKEY RR set, such keys might be pending retirement or not yet in
-   use.
-
-   When verifying a RR set, the SEP bit is not intended to play a role.
-   How the key is used by the verifier is not intended to be a
-   consideration at key creation time.
-
-   Although the SEP flag provides a hint on which public key is to be
-   used as trusted root, administrators can choose to ignore the fact
-   that a DNSKEY has its SEP bit set or not when configuring a trusted
-   root for their resolvers.
-
-   Using the SEP flag a key roll over can be automated.  The parent can
-   use an existing trust relation to verify DNSKEY RR sets in which a
-   new DNSKEY RR with the SEP flag appears.
-
-5.  Security Considerations
-
-   As stated in Section 3 the flag is not to be used in the resolution
-   protocol or to determine the security status of a key.  The flag is
-   to be used for administrative purposes only.
-
-   No trust in a key should be inferred from this flag - trust MUST be
-   inferred from an existing chain of trust or an out-of-band exchange.
-
-   Since this flag might be used for automating public key exchanges, we
-   think the following consideration is in place.
-
-   Automated mechanisms for roll over of the DS RR might be vulnerable
-   to a class of replay attacks.  This might happen after a public key
-   exchange where a DNSKEY RR set, containing two DNSKEY RRs with the
-   SEP flag set, is sent to the parent.  The parent verifies the DNSKEY
-   RR set with the existing trust relation and creates the new DS RR
-   from the DNSKEY RR that the current DS RR is not pointing to.  This
-   key exchange might be replayed.  Parents are encouraged to implement
-   a replay defense.  A simple defense can be based on a registry of
-   keys that have been used to generate DS RRs during the most recent
-   roll over.  These same considerations apply to entities that
-   configure keys in resolvers.
-
-
-
-
-
-
-
-
-Kolkman, et al.              Standard Track                     [Page 5]
-
-RFC 3757                   DNSKEY RR SEP Flag                 April 2004
-
-
-6.  IANA Considerations
-
-   IANA has assigned the 15th bit in the DNSKEY Flags Registry (see
-   Section 4.3 of [4]) as the Secure Entry Point (SEP) bit.
-
-7.  Internationalization Considerations
-
-   Although SEP is a popular acronym in many different languages, there
-   are no internationalization considerations.
-
-8.  Acknowledgments
-
-   The ideas documented in this document are inspired by communications
-   we had with numerous people and ideas published by other folk.  Among
-   others Mark Andrews, Rob Austein, Miek Gieben, Olafur Gudmundsson,
-   Daniel Karrenberg, Dan Massey, Scott Rose, Marcos Sanz and Sam Weiler
-   have contributed ideas and provided feedback.
-
-   This document saw the light during a workshop on DNSSEC operations
-   hosted by USC/ISI in August 2002.
-
-9.  References
-
-9.1.  Normative References
-
-   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [2]  Eastlake, D., "Domain Name System Security Extensions", RFC
-        2535, March 1999.
-
-   [3]  Lewis, E., "DNS Security Extension Clarification on Zone
-        Status", RFC 3090, March 2001.
-
-   [4]  Weiler, S., "Legacy Resolver Compatibility for Delegation Signer
-        (DS)", RFC 3755, April 2004.
-
-9.2.  Informative References
-
-   [5]  Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
-        RFC 3658, December 2003.
-
-   [6]  Orwell, G. and R. Steadman (illustrator), "Animal Farm; a Fairy
-        Story", ISBN 0151002177 (50th anniversary edition), April 1996.
-
-
-
-
-
-
-
-Kolkman, et al.              Standard Track                     [Page 6]
-
-RFC 3757                   DNSKEY RR SEP Flag                 April 2004
-
-
-10.  Authors' Addresses
-
-   Olaf M. Kolkman
-   RIPE NCC
-   Singel 256
-   Amsterdam  1016 AB
-   NL
-
-   Phone: +31 20 535 4444
-   EMail: olaf@ripe.net
-   URI:   http://www.ripe.net/
-
-
-   Jakob Schlyter
-   NIC-SE
-   Box 5774
-   SE-114 87 Stockholm
-   Sweden
-
-   EMail: jakob@nic.se
-   URI:   http://www.nic.se/
-
-
-   Edward P. Lewis
-   ARIN
-   3635 Concorde Parkway Suite 200
-   Chantilly, VA  20151
-   US
-
-   Phone: +1 703 227 9854
-   EMail: edlewis@arin.net
-   URI:   http://www.arin.net/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman, et al.              Standard Track                     [Page 7]
-
-RFC 3757                   DNSKEY RR SEP Flag                 April 2004
-
-
-11.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78 and
-   except as set forth therein, the authors retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
-   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
-   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
-   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed
-   to pertain to the implementation or use of the technology
-   described in this document or the extent to which any license
-   under such rights might or might not be available; nor does it
-   represent that it has made any independent effort to identify any
-   such rights.  Information on the procedures with respect to
-   rights in RFC documents can be found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use
-   of such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository
-   at http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention
-   any copyrights, patents or patent applications, or other
-   proprietary rights that may cover technology that may be required
-   to implement this standard.  Please address the information to the
-   IETF at ietf-ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-Kolkman, et al.              Standard Track                     [Page 8]
-
diff --git a/contrib/bind9/doc/rfc/rfc3833.txt b/contrib/bind9/doc/rfc/rfc3833.txt
deleted file mode 100644
index 8ce4d34..0000000
--- a/contrib/bind9/doc/rfc/rfc3833.txt
+++ /dev/null
@@ -1,899 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          D. Atkins
-Request for Comments: 3833                              IHTFP Consulting
-Category: Informational                                       R. Austein
-                                                                     ISC
-                                                             August 2004
-
-
-            Threat Analysis of the Domain Name System (DNS)
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).
-
-Abstract
-
-   Although the DNS Security Extensions (DNSSEC) have been under
-   development for most of the last decade, the IETF has never written
-   down the specific set of threats against which DNSSEC is designed to
-   protect.  Among other drawbacks, this cart-before-the-horse situation
-   has made it difficult to determine whether DNSSEC meets its design
-   goals, since its design goals are not well specified.  This note
-   attempts to document some of the known threats to the DNS, and, in
-   doing so, attempts to measure to what extent (if any) DNSSEC is a
-   useful tool in defending against these threats.
-
-1. Introduction
-
-   The earliest organized work on DNSSEC within the IETF was an open
-   design team meeting organized by members of the DNS working group in
-   November 1993 at the 28th IETF meeting in Houston.  The broad
-   outlines of DNSSEC as we know it today are already clear in Jim
-   Galvin's summary of the results of that meeting [Galvin93]:
-
-   - While some participants in the meeting were interested in
-     protecting against disclosure of DNS data to unauthorized parties,
-     the design team made an explicit decision that "DNS data is
-     `public'", and ruled all threats of data disclosure explicitly out
-     of scope for DNSSEC.
-
-   - While some participants in the meeting were interested in
-     authentication of DNS clients and servers as a basis for access
-     control, this work was also ruled out of scope for DNSSEC per se.
-
-
-
-Atkins & Austein             Informational                      [Page 1]
-
-RFC 3833                  DNS Threat Analysis                August 2004
-
-
-   - Backwards compatibility and co-existence with "insecure DNS" was
-     listed as an explicit requirement.
-
-   - The resulting list of desired security services was
-     1) data integrity, and
-     2) data origin authentication.
-
-   - The design team noted that a digital signature mechanism would
-     support the desired services.
-
-   While a number of detail decisions were yet to be made (and in some
-   cases remade after implementation experience) over the subsequent
-   decade, the basic model and design goals have remained fixed.
-
-   Nowhere, however, does any of the DNSSEC work attempt to specify in
-   any detail the sorts of attacks against which DNSSEC is intended to
-   protect, or the reasons behind the list of desired security services
-   that came out of the Houston meeting.  For that, we have to go back
-   to a paper originally written by Steve Bellovin in 1990 but not
-   published until 1995, for reasons that Bellovin explained in the
-   paper's epilogue [Bellovin95].
-
-   While it may seem a bit strange to publish the threat analysis a
-   decade after starting work on the protocol designed to defend against
-   it, that is, nevertheless, what this note attempts to do.  Better
-   late than never.
-
-   This note assumes that the reader is familiar with both the DNS and
-   with DNSSEC, and does not attempt to provide a tutorial on either.
-   The DNS documents most relevant to the subject of this note are:
-   [RFC1034], [RFC1035], section 6.1 of [RFC1123], [RFC2181], [RFC2308],
-   [RFC2671], [RFC2845], [RFC2930], [RFC3007], and [RFC2535].
-
-   For purposes of discussion, this note uses the term "DNSSEC" to refer
-   to the core hierarchical public key and signature mechanism specified
-   in the DNSSEC documents, and refers to TKEY and TSIG as separate
-   mechanisms, even though channel security mechanisms such as TKEY and
-   TSIG are also part of the larger problem of "securing DNS" and thus
-   are often considered part of the overall set of "DNS security
-   extensions".  This is an arbitrary distinction that in part reflects
-   the way in which the protocol has evolved (introduction of a
-   putatively simpler channel security model for certain operations such
-   as zone transfers and dynamic update requests), and perhaps should be
-   changed in a future revision of this note.
-
-
-
-
-
-
-
-Atkins & Austein             Informational                      [Page 2]
-
-RFC 3833                  DNS Threat Analysis                August 2004
-
-
-2.  Known Threats
-
-   There are several distinct classes of threats to the DNS, most of
-   which are DNS-related instances of more general problems, but a few
-   of which are specific to peculiarities of the DNS protocol.
-
-2.1.  Packet Interception
-
-   Some of the simplest threats against DNS are various forms of packet
-   interception: monkey-in-the-middle attacks, eavesdropping on requests
-   combined with spoofed responses that beat the real response back to
-   the resolver, and so forth.  In any of these scenarios, the attacker
-   can simply tell either party (usually the resolver) whatever it wants
-   that party to believe.  While packet interception attacks are far
-   from unique to DNS, DNS's usual behavior of sending an entire query
-   or response in a single unsigned, unencrypted UDP packet makes these
-   attacks particularly easy for any bad guy with the ability to
-   intercept packets on a shared or transit network.
-
-   To further complicate things, the DNS query the attacker intercepts
-   may just be a means to an end for the attacker: the attacker might
-   even choose to return the correct result in the answer section of a
-   reply message while using other parts of the message to set the stage
-   for something more complicated, for example, a name chaining attack
-   (see section 2.3).
-
-   While it certainly would be possible to sign DNS messages using a
-   channel security mechanism such as TSIG or IPsec, or even to encrypt
-   them using IPsec, this would not be a very good solution for
-   interception attacks.  First, this approach would impose a fairly
-   high processing cost per DNS message, as well as a very high cost
-   associated with establishing and maintaining bilateral trust
-   relationships between all the parties that might be involved in
-   resolving any particular query.  For heavily used name servers (such
-   as the servers for the root zone), this cost would almost certainly
-   be prohibitively high.  Even more important, however, is that the
-   underlying trust model in such a design would be wrong, since at best
-   it would only provide a hop-by-hop integrity check on DNS messages
-   and would not provide any sort of end-to-end integrity check between
-   the producer of DNS data (the zone administrator) and the consumer of
-   DNS data (the application that triggered the query).
-
-   By contrast, DNSSEC (when used properly) does provide an end-to-end
-   data integrity check, and is thus a much better solution for this
-   class of problems during basic DNS lookup operations.
-
-
-
-
-
-
-Atkins & Austein             Informational                      [Page 3]
-
-RFC 3833                  DNS Threat Analysis                August 2004
-
-
-   TSIG does have its place in corners of the DNS protocol where there's
-   a specific trust relationship between a particular client and a
-   particular server, such as zone transfer, dynamic update, or a
-   resolver (stub or otherwise) that is not going to check all the
-   DNSSEC signatures itself.
-
-   Note that DNSSEC does not provide any protection against modification
-   of the DNS message header, so any properly paranoid resolver must:
-
-   - Perform all of the DNSSEC signature checking on its own,
-
-   - Use TSIG (or some equivalent mechanism) to ensure the integrity of
-     its communication with whatever name servers it chooses to trust,
-     or
-
-   - Resign itself to the possibility of being attacked via packet
-     interception (and via other techniques discussed below).
-
-2.2.  ID Guessing and Query Prediction
-
-   Since DNS is for the most part used over UDP/IP, it is relatively
-   easy for an attacker to generate packets which will match the
-   transport protocol parameters.  The ID field in the DNS header is
-   only a 16-bit field and the server UDP port associated with DNS is a
-   well-known value, so there are only 2**32 possible combinations of ID
-   and client UDP port for a given client and server.  This is not a
-   particularly large range, and is not sufficient to protect against a
-   brute force search; furthermore, in practice both the client UDP port
-   and the ID can often be predicted from previous traffic, and it is
-   not uncommon for the client port to be a known fixed value as well
-   (due to firewalls or other restrictions), thus frequently reducing
-   the search space to a range smaller than 2**16.
-
-   By itself, ID guessing is not enough to allow an attacker to inject
-   bogus data, but combined with knowledge (or guesses) about QNAMEs and
-   QTYPEs for which a resolver might be querying, this leaves the
-   resolver only weakly defended against injection of bogus responses.
-
-   Since this attack relies on predicting a resolver's behavior, it's
-   most likely to be successful when the victim is in a known state,
-   whether because the victim rebooted recently, or because the victim's
-   behavior has been influenced by some other action by the attacker, or
-   because the victim is responding (in a predictable way) to some third
-   party action known to the attacker.
-
-
-
-
-
-
-
-Atkins & Austein             Informational                      [Page 4]
-
-RFC 3833                  DNS Threat Analysis                August 2004
-
-
-   This attack is both more and less difficult for the attacker than the
-   simple interception attack described above: more difficult, because
-   the attack only works when the attacker guesses correctly; less
-   difficult, because the attacker doesn't need to be on a transit or
-   shared network.
-
-   In most other respects, this attack is similar to a packet
-   interception attack.  A resolver that checks DNSSEC signatures will
-   be able to detect the forged response; resolvers that do not perform
-   DNSSEC signature checking themselves should use TSIG or some
-   equivalent mechanism to ensure the integrity of their communication
-   with a recursive name server that does perform DNSSEC signature
-   checking.
-
-2.3.  Name Chaining
-
-   Perhaps the most interesting class of DNS-specific threats are the
-   name chaining attacks.  These are a subset of a larger class of
-   name-based attacks, sometimes called "cache poisoning" attacks.  Most
-   name-based attacks can be partially mitigated by the long-standing
-   defense of checking RRs in response messages for relevance to the
-   original query, but such defenses do not catch name chaining attacks.
-   There are several variations on the basic attack, but what they all
-   have in common is that they all involve DNS RRs whose RDATA portion
-   (right hand side) includes a DNS name (or, in a few cases, something
-   that is not a DNS name but which directly maps to a DNS name).  Any
-   such RR is, at least in principle, a hook that lets an attacker feed
-   bad data into a victim's cache, thus potentially subverting
-   subsequent decisions based on DNS names.
-
-   The worst examples in this class of RRs are CNAME, NS, and DNAME RRs
-   because they can redirect a victim's query to a location of the
-   attacker's choosing.  RRs like MX and SRV are somewhat less
-   dangerous, but in principle they can also be used to trigger further
-   lookups at a location of the attacker's choosing.  Address RR types
-   such as A or AAAA don't have DNS names in their RDATA, but since the
-   IN-ADDR.ARPA and IP6.ARPA trees are indexed using a DNS encoding of
-   IPv4 and IPv6 addresses, these record types can also be used in a
-   name chaining attack.
-
-   The general form of a name chaining attack is something like this:
-
-   - Victim issues a query, perhaps at the instigation of the attacker
-     or some third party; in some cases the query itself may be
-     unrelated to the name under attack (that is, the attacker is just
-     using this query as a means to inject false information about some
-     other name).
-
-
-
-
-Atkins & Austein             Informational                      [Page 5]
-
-RFC 3833                  DNS Threat Analysis                August 2004
-
-
-   - Attacker injects response, whether via packet interception, query
-     guessing, or by being a legitimate name server that's involved at
-     some point in the process of answering the query that the victim
-     issued.
-
-   - Attacker's response includes one or more RRs with DNS names in
-     their RDATA; depending on which particular form this attack takes,
-     the object may be to inject false data associated with those names
-     into the victim's cache via the Additional section of this
-     response, or may be to redirect the next stage of the query to a
-     server of the attacker's choosing (in order to inject more complex
-     lies into the victim's cache than will fit easily into a single
-     response, or in order to place the lies in the Authority or Answer
-     section of a response where they will have a better chance of
-     sneaking past a resolver's defenses).
-
-   Any attacker who can insert resource records into a victim's cache
-   can almost certainly do some kind of damage, so there are cache
-   poisoning attacks which are not name chaining attacks in the sense
-   discussed here.  However, in the case of name chaining attacks, the
-   cause and effect relationship between the initial attack and the
-   eventual result may be significantly more complex than in the other
-   forms of cache poisoning, so name chaining attacks merit special
-   attention.
-
-   The common thread in all of the name chaining attacks is that
-   response messages allow the attacker to introduce arbitrary DNS names
-   of the attacker's choosing and provide further information that the
-   attacker claims is associated with those names; unless the victim has
-   better knowledge of the data associated with those names, the victim
-   is going to have a hard time defending against this class of attacks.
-
-   This class of attack is particularly insidious given that it's quite
-   easy for an attacker to provoke a victim into querying for a
-   particular name of the attacker's choosing, for example, by embedding
-   a link to a 1x1-pixel "web bug" graphic in a piece of Text/HTML mail
-   to the victim.  If the victim's mail reading program attempts to
-   follow such a link, the result will be a DNS query for a name chosen
-   by the attacker.
-
-   DNSSEC should provide a good defense against most (all?) variations
-   on this class of attack.  By checking signatures, a resolver can
-   determine whether the data associated with a name really was inserted
-   by the delegated authority for that portion of the DNS name space.
-   More precisely, a resolver can determine whether the entity that
-   injected the data had access to an allegedly secret key whose
-
-
-
-
-
-Atkins & Austein             Informational                      [Page 6]
-
-RFC 3833                  DNS Threat Analysis                August 2004
-
-
-   corresponding public key appears at an expected location in the DNS
-   name space with an expected chain of parental signatures that start
-   with a public key of which the resolver has prior knowledge.
-
-   DNSSEC signatures do not cover glue records, so there's still a
-   possibility of a name chaining attack involving glue, but with DNSSEC
-   it is possible to detect the attack by temporarily accepting the glue
-   in order to fetch the signed authoritative version of the same data,
-   then checking the signatures on the authoritative version.
-
-2.4.  Betrayal By Trusted Server
-
-   Another variation on the packet interception attack is the trusted
-   server that turns out not to be so trustworthy, whether by accident
-   or by intent.  Many client machines are only configured with stub
-   resolvers, and use trusted servers to perform all of their DNS
-   queries on their behalf.  In many cases the trusted server is
-   furnished by the user's ISP and advertised to the client via DHCP or
-   PPP options.  Besides accidental betrayal of this trust relationship
-   (via server bugs, successful server break-ins, etc), the server
-   itself may be configured to give back answers that are not what the
-   user would expect, whether in an honest attempt to help the user or
-   to promote some other goal such as furthering a business partnership
-   between the ISP and some third party.
-
-   This problem is particularly acute for frequent travelers who carry
-   their own equipment and expect it to work in much the same way
-   wherever they go.  Such travelers need trustworthy DNS service
-   without regard to who operates the network into which their equipment
-   is currently plugged or what brand of middle boxes the local
-   infrastructure might use.
-
-   While the obvious solution to this problem would be for the client to
-   choose a more trustworthy server, in practice this may not be an
-   option for the client.  In many network environments a client machine
-   has only a limited set of recursive name servers from which to
-   choose, and none of them may be particularly trustworthy.  In extreme
-   cases, port filtering or other forms of packet interception may
-   prevent the client host from being able to run an iterative resolver
-   even if the owner of the client machine is willing and able to do so.
-   Thus, while the initial source of this problem is not a DNS protocol
-   attack per se, this sort of betrayal is a threat to DNS clients, and
-   simply switching to a different recursive name server is not an
-   adequate defense.
-
-   Viewed strictly from the DNS protocol standpoint, the only difference
-   between this sort of betrayal and a packet interception attack is
-   that in this case the client has voluntarily sent its request to the
-
-
-
-Atkins & Austein             Informational                      [Page 7]
-
-RFC 3833                  DNS Threat Analysis                August 2004
-
-
-   attacker.  The defense against this is the same as with a packet
-   interception attack: the resolver must either check DNSSEC signatures
-   itself or use TSIG (or equivalent) to authenticate the server that it
-   has chosen to trust.  Note that use of TSIG does not by itself
-   guarantee that a name server is at all trustworthy: all TSIG can do
-   is help a resolver protect its communication with a name server that
-   it has already decided to trust for other reasons.  Protecting a
-   resolver's communication with a server that's giving out bogus
-   answers is not particularly useful.
-
-   Also note that if the stub resolver does not trust the name server
-   that is doing work on its behalf and wants to check the DNSSEC
-   signatures itself, the resolver really does need to have independent
-   knowledge of the DNSSEC public key(s) it needs in order to perform
-   the check.  Usually the public key for the root zone is enough, but
-   in some cases knowledge of additional keys may also be appropriate.
-
-   It is difficult to escape the conclusion that a properly paranoid
-   resolver must always perform its own signature checking, and that
-   this rule even applies to stub resolvers.
-
-2.5.  Denial of Service
-
-   As with any network service (or, indeed, almost any service of any
-   kind in any domain of discourse), DNS is vulnerable to denial of
-   service attacks.  DNSSEC does not help this, and may in fact make the
-   problem worse for resolvers that check signatures, since checking
-   signatures both increases the processing cost per DNS message and in
-   some cases can also increase the number of messages needed to answer
-   a query.  TSIG (and similar mechanisms) have equivalent problems.
-
-   DNS servers are also at risk of being used as denial of service
-   amplifiers, since DNS response packets tend to be significantly
-   longer than DNS query packets.  Unsurprisingly, DNSSEC doesn't help
-   here either.
-
-2.6.  Authenticated Denial of Domain Names
-
-   Much discussion has taken place over the question of authenticated
-   denial of domain names.  The particular question is whether there is
-   a requirement for authenticating the non-existence of a name.  The
-   issue is whether the resolver should be able to detect when an
-   attacker removes RRs from a response.
-
-   General paranoia aside, the existence of RR types whose absence
-   causes an action other than immediate failure (such as missing MX and
-   SRV RRs, which fail over to A RRs) constitutes a real threat.
-   Arguably, in some cases, even the absence of an RR might be
-
-
-
-Atkins & Austein             Informational                      [Page 8]
-
-RFC 3833                  DNS Threat Analysis                August 2004
-
-
-   considered a problem.  The question remains: how serious is this
-   threat?  Clearly the threat does exist; general paranoia says that
-   some day it'll be on the front page of some major newspaper, even if
-   we cannot conceive of a plausible scenario involving this attack
-   today.  This implies that some mitigation of this risk is required.
-
-   Note that it's necessary to prove the non-existence of applicable
-   wildcard RRs as part of the authenticated denial mechanism, and that,
-   in a zone that is more than one label deep, such a proof may require
-   proving the non-existence of multiple discrete sets of wildcard RRs.
-
-   DNSSEC does include mechanisms which make it possible to determine
-   which authoritative names exist in a zone, and which authoritative
-   resource record types exist at those names.  The DNSSEC protections
-   do not cover non-authoritative data such as glue records.
-
-2.7.  Wildcards
-
-   Much discussion has taken place over whether and how to provide data
-   integrity and data origin authentication for "wildcard" DNS names.
-   Conceptually, RRs with wildcard names are patterns for synthesizing
-   RRs on the fly according to the matching rules described in section
-   4.3.2 of RFC 1034.  While the rules that control the behavior of
-   wildcard names have a few quirks that can make them a trap for the
-   unwary zone administrator, it's clear that a number of sites make
-   heavy use of wildcard RRs, particularly wildcard MX RRs.
-
-   In order to provide the desired services for wildcard RRs, we need to
-   do two things:
-
-   - We need a way to attest to the existence of the wildcard RR itself
-     (that is, we need to show that the synthesis rule exists), and
-
-   - We need a way to attest to the non-existence of any RRs which, if
-     they existed, would make the wildcard RR irrelevant according to
-     the synthesis rules that govern the way in which wildcard RRs are
-     used (that is, we need to show that the synthesis rule is
-     applicable).
-
-   Note that this makes the wildcard mechanisms dependent upon the
-   authenticated denial mechanism described in the previous section.
-
-   DNSSEC includes mechanisms along the lines described above, which
-   make it possible for a resolver to verify that a name server applied
-   the wildcard expansion rules correctly when generating an answer.
-
-
-
-
-
-
-Atkins & Austein             Informational                      [Page 9]
-
-RFC 3833                  DNS Threat Analysis                August 2004
-
-
-3.  Weaknesses of DNSSEC
-
-   DNSSEC has some problems of its own:
-
-   - DNSSEC is complex to implement and includes some nasty edge cases
-     at the zone cuts that require very careful coding.  Testbed
-     experience to date suggests that trivial zone configuration errors
-     or expired keys can cause serious problems for a DNSSEC-aware
-     resolver, and that the current protocol's error reporting
-     capabilities may leave something to be desired.
-
-   - DNSSEC significantly increases the size of DNS response packets;
-     among other issues, this makes DNSSEC-aware DNS servers even more
-     effective as denial of service amplifiers.
-
-   - DNSSEC answer validation increases the resolver's work load, since
-     a DNSSEC-aware resolver will need to perform signature validation
-     and in some cases will also need to issue further queries.  This
-     increased workload will also increase the time it takes to get an
-     answer back to the original DNS client, which is likely to trigger
-     both timeouts and re-queries in some cases.  Arguably, many current
-     DNS clients are already too impatient even before taking the
-     further delays that DNSSEC will impose into account, but that topic
-     is beyond the scope of this note.
-
-   - Like DNS itself, DNSSEC's trust model is almost totally
-     hierarchical.  While DNSSEC does allow resolvers to have special
-     additional knowledge of public keys beyond those for the root, in
-     the general case the root key is the one that matters.  Thus any
-     compromise in any of the zones between the root and a particular
-     target name can damage DNSSEC's ability to protect the integrity of
-     data owned by that target name.  This is not a change, since
-     insecure DNS has the same model.
-
-   - Key rollover at the root is really hard.  Work to date has not even
-     come close to adequately specifying how the root key rolls over, or
-     even how it's configured in the first place.
-
-   - DNSSEC creates a requirement of loose time synchronization between
-     the validating resolver and the entity creating the DNSSEC
-     signatures.  Prior to DNSSEC, all time-related actions in DNS could
-     be performed by a machine that only knew about "elapsed" or
-     "relative" time.  Because the validity period of a DNSSEC signature
-     is based on "absolute" time, a validating resolver must have the
-     same concept of absolute time as the zone signer in order to
-     determine whether the signature is within its validity period or
-     has expired.  An attacker that can change a resolver's opinion of
-     the current absolute time can fool the resolver using expired
-
-
-
-Atkins & Austein             Informational                     [Page 10]
-
-RFC 3833                  DNS Threat Analysis                August 2004
-
-
-     signatures.  An attacker that can change the zone signer's opinion
-     of the current absolute time can fool the zone signer into
-     generating signatures whose validity period does not match what the
-     signer intended.
-
-   - The possible existence of wildcard RRs in a zone complicates the
-     authenticated denial mechanism considerably.  For most of the
-     decade that DNSSEC has been under development these issues were
-     poorly understood.  At various times there have been questions as
-     to whether the authenticated denial mechanism is completely
-     airtight and whether it would be worthwhile to optimize the
-     authenticated denial mechanism for the common case in which
-     wildcards are not present in a zone.  However, the main problem is
-     just the inherent complexity of the wildcard mechanism itself.
-     This complexity probably makes the code for generating and checking
-     authenticated denial attestations somewhat fragile, but since the
-     alternative of giving up wildcards entirely is not practical due to
-     widespread use, we are going to have to live with wildcards. The
-     question just becomes one of whether or not the proposed
-     optimizations would make DNSSEC's mechanisms more or less fragile.
-
-   - Even with DNSSEC, the class of attacks discussed in section 2.4 is
-     not easy to defeat.  In order for DNSSEC to be effective in this
-     case, it must be possible to configure the resolver to expect
-     certain categories of DNS records to be signed.  This may require
-     manual configuration of the resolver, especially during the initial
-     DNSSEC rollout period when the resolver cannot reasonably expect
-     the root and TLD zones to be signed.
-
-4.  Topics for Future Work
-
-   This section lists a few subjects not covered above which probably
-   need additional study, additional mechanisms, or both.
-
-4.1.  Interactions With Other Protocols
-
-   The above discussion has concentrated exclusively on attacks within
-   the boundaries of the DNS protocol itself, since those are (some of)
-   the problems against which DNSSEC was intended to protect.  There
-   are, however, other potential problems at the boundaries where DNS
-   interacts with other protocols.
-
-4.2.  Securing DNS Dynamic Update
-
-   DNS dynamic update opens a number of potential problems when combined
-   with DNSSEC.  Dynamic update of a non-secure zone can use TSIG to
-   authenticate the updating client to the server.  While TSIG does not
-   scale very well (it requires manual configuration of shared keys
-
-
-
-Atkins & Austein             Informational                     [Page 11]
-
-RFC 3833                  DNS Threat Analysis                August 2004
-
-
-   between the DNS name server and each TSIG client), it works well in a
-   limited or closed environment such as a DHCP server updating a local
-   DNS name server.
-
-   Major issues arise when trying to use dynamic update on a secure
-   zone.  TSIG can similarly be used in a limited fashion to
-   authenticate the client to the server, but TSIG only protects DNS
-   transactions, not the actual data, and the TSIG is not inserted into
-   the DNS zone, so resolvers cannot use the TSIG as a way of verifying
-   the changes to the zone.  This means that either:
-
-   a) The updating client must have access to a zone-signing key in
-      order to sign the update before sending it to the server, or
-
-   b) The DNS name server must have access to an online zone-signing key
-      in order to sign the update.
-
-   In either case, a zone-signing key must be available to create signed
-   RRsets to place in the updated zone.  The fact that this key must be
-   online (or at least available) is a potential security risk.
-
-   Dynamic update also requires an update to the SERIAL field of the
-   zone's SOA RR.  In theory, this could also be handled via either of
-   the above options, but in practice (a) would almost certainly be
-   extremely fragile, so (b) is the only workable mechanism.
-
-   There are other threats in terms of describing the policy of who can
-   make what changes to which RRsets in the zone.  The current access
-   control scheme in Secure Dynamic Update is fairly limited.  There is
-   no way to give fine-grained access to updating DNS zone information
-   to multiple entities, each of whom may require different kinds of
-   access.  For example, Alice may need to be able to add new nodes to
-   the zone or change existing nodes, but not remove them; Bob may need
-   to be able to remove zones but not add them; Carol may need to be
-   able to add, remove, or modify nodes, but only A records.
-
-   Scaling properties of the key management problem here are a
-   particular concern that needs more study.
-
-4.3.  Securing DNS Zone Replication
-
-   As discussed in previous sections, DNSSEC per se attempts to provide
-   data integrity and data origin authentication services on top of the
-   normal DNS query protocol.  Using the terminology discussed in
-   [RFC3552], DNSSEC provides "object security" for the normal DNS query
-   protocol.  For purposes of replicating entire DNS zones, however,
-   DNSSEC does not provide object security, because zones include
-   unsigned NS RRs and glue at delegation points.  Use of TSIG to
-
-
-
-Atkins & Austein             Informational                     [Page 12]
-
-RFC 3833                  DNS Threat Analysis                August 2004
-
-
-   protect zone transfer (AXFR or IXFR) operations provides "channel
-   security", but still does not provide object security for complete
-   zones. The trust relationships involved in zone transfer are still
-   very much a hop-by-hop matter of name server operators trusting other
-   name server operators rather than an end-to-end matter of name server
-   operators trusting zone administrators.
-
-   Zone object security was not an explicit design goal of DNSSEC, so
-   failure to provide this service should not be a surprise.
-   Nevertheless, there are some zone replication scenarios for which
-   this would be a very useful additional service, so this seems like a
-   useful area for future work.  In theory it should not be difficult to
-   add zone object security as a backwards compatible enhancement to the
-   existing DNSSEC model, but the DNSEXT WG has not yet discussed either
-   the desirability of or the requirements for such an enhancement.
-
-5.  Conclusion
-
-   Based on the above analysis, the DNSSEC extensions do appear to solve
-   a set of problems that do need to be solved, and are worth deploying.
-
-Security Considerations
-
-   This entire document is about security considerations of the DNS.
-   The authors believe that deploying DNSSEC will help to address some,
-   but not all, of the known threats to the DNS.
-
-Acknowledgments
-
-   This note is based both on previous published works by others and on
-   a number of discussions both public and private over a period of many
-   years, but particular thanks go to
-
-   Jaap Akkerhuis,
-   Steve Bellovin,
-   Dan Bernstein,
-   Randy Bush,
-   Steve Crocker,
-   Olafur Gudmundsson,
-   Russ Housley,
-   Rip Loomis,
-   Allison Mankin,
-   Paul Mockapetris,
-   Thomas Narten
-   Mans Nilsson,
-   Pekka Savola,
-   Paul Vixie,
-   Xunhua Wang,
-
-
-
-Atkins & Austein             Informational                     [Page 13]
-
-RFC 3833                  DNS Threat Analysis                August 2004
-
-
-   and any other members of the DNS, DNSSEC, DNSIND, and DNSEXT working
-   groups whose names and contributions the authors have forgotten, none
-   of whom are responsible for what the authors did with their ideas.
-
-   As with any work of this nature, the authors of this note acknowledge
-   that we are standing on the toes of those who have gone before us.
-   Readers interested in this subject may also wish to read
-   [Bellovin95], [Schuba93], and [Vixie95].
-
-Normative References
-
-   [RFC1034]    Mockapetris, P., "Domain names - concepts and
-                facilities", STD 13, RFC 1034, November 1987.
-
-   [RFC1035]    Mockapetris, P., "Domain names - implementation and
-                specification", STD 13, RFC 1035, November 1987.
-
-   [RFC1123]    Braden, R., "Requirements for Internet Hosts -
-                Application and Support", STD 3, RFC 1123, October 1989.
-
-   [RFC2181]    Elz, R. and R. Bush, "Clarifications to the DNS
-                Specification", RFC 2181, July 1997.
-
-   [RFC2308]    Andrews, M., "Negative Caching of DNS Queries (DNS
-                NCACHE)", RFC 2308, March 1998.
-
-   [RFC2671]    Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
-                2671, August 1999.
-
-   [RFC2845]    Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
-                Wellington, "Secret Key Transaction Authentication for
-                DNS (TSIG)", RFC 2845, May 2000.
-
-   [RFC2930]    Eastlake 3rd, D., "Secret Key Establishment for DNS
-                (TKEY RR)", RFC 2930, September 2000.
-
-   [RFC3007]    Wellington, B., "Secure Domain Name System (DNS) Dynamic
-                Update", RFC 3007, November 2000.
-
-   [RFC2535]    Eastlake 3rd, D., "Domain Name System Security
-                Extensions", RFC 2535, March 1999.
-
-
-
-
-
-
-
-
-
-
-Atkins & Austein             Informational                     [Page 14]
-
-RFC 3833                  DNS Threat Analysis                August 2004
-
-
-Informative References
-
-   [RFC3552]    Rescorla, E. and B. Korver, "Guidelines for Writing RFC
-                Text on Security Considerations", BCP 72, RFC 3552, July
-                2003.
-
-   [Bellovin95] Bellovin, S., "Using the Domain Name System for System
-                Break-Ins", Proceedings of the Fifth Usenix Unix
-                Security Symposium, June 1995.
-
-   [Galvin93]   Design team meeting summary message posted to dns-
-                security@tis.com mailing list by Jim Galvin on 19
-                November 1993.
-
-   [Schuba93]   Schuba, C., "Addressing Weaknesses in the Domain Name
-                System Protocol", Master's thesis, Purdue University
-                Department of Computer Sciences,  August 1993.
-
-   [Vixie95]    Vixie, P, "DNS and BIND Security Issues", Proceedings of
-                the Fifth Usenix Unix Security Symposium, June 1995.
-
-Authors' Addresses
-
-   Derek Atkins
-   IHTFP Consulting, Inc.
-   6 Farragut Ave
-   Somerville, MA  02144
-   USA
-
-   EMail: derek@ihtfp.com
-
-
-   Rob Austein
-   Internet Systems Consortium
-   950 Charter Street
-   Redwood City, CA 94063
-   USA
-
-   EMail: sra@isc.org
-
-
-
-
-
-
-
-
-
-
-
-
-Atkins & Austein             Informational                     [Page 15]
-
-RFC 3833                  DNS Threat Analysis                August 2004
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-Atkins & Austein             Informational                     [Page 16]
-
diff --git a/contrib/bind9/doc/rfc/rfc3845.txt b/contrib/bind9/doc/rfc/rfc3845.txt
deleted file mode 100644
index 9887a20..0000000
--- a/contrib/bind9/doc/rfc/rfc3845.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                   J. Schlyter, Ed.
-Request for Comments: 3845                                   August 2004
-Updates: 3755, 2535
-Category: Standards Track
-
-
-          DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).
-
-Abstract
-
-   This document redefines the wire format of the "Type Bit Map" field
-   in the DNS NextSECure (NSEC) resource record RDATA format to cover
-   the full resource record (RR) type space.
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
-   2.  The NSEC Resource Record . . . . . . . . . . . . . . . . . . .  2
-       2.1.  NSEC RDATA Wire Format . . . . . . . . . . . . . . . . .  3
-             2.1.1.  The Next Domain Name Field . . . . . . . . . . .  3
-             2.1.2.  The List of Type Bit Map(s) Field  . . . . . . .  3
-             2.1.3.  Inclusion of Wildcard Names in NSEC RDATA  . . .  4
-       2.2.  The NSEC RR Presentation Format  . . . . . . . . . . . .  4
-       2.3.  NSEC RR Example  . . . . . . . . . . . . . . . . . . . .  5
-   3.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  5
-   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  5
-   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  6
-       5.1.  Normative References . . . . . . . . . . . . . . . . . .  6
-       5.2.  Informative References . . . . . . . . . . . . . . . . .  6
-   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  6
-   7.  Author's Address . . . . . . . . . . . . . . . . . . . . . . .  6
-   8.  Full Copyright Statement . . . . . . . . . . . . . . . . . . .  7
-
-
-
-
-
-
-
-Schlyter, Ed.               Standards Track                     [Page 1]
-
-RFC 3845                DNSSEC NSEC RDATA Format             August 2004
-
-
-1.  Introduction
-
-   The DNS [6][7] NSEC [5] Resource Record (RR) is used for
-   authenticated proof of the non-existence of DNS owner names and
-   types.  The NSEC RR is based on the NXT RR as described in RFC 2535
-   [2], and is similar except for the name and typecode.  The RDATA
-   format for the NXT RR has the limitation in that the RDATA could only
-   carry information about the existence of the first 127 types.  RFC
-   2535 did reserve a bit to specify an extension mechanism, but the
-   mechanism was never actually defined.
-
-   In order to avoid needing to develop an extension mechanism into a
-   deployed base of DNSSEC aware servers and resolvers once the first
-   127 type codes are allocated, this document redefines the wire format
-   of the "Type Bit Map" field in the NSEC RDATA to cover the full RR
-   type space.
-
-   This document introduces a new format for the type bit map.  The
-   properties of the type bit map format are that it can cover the full
-   possible range of typecodes, that it is relatively economical in the
-   amount of space it uses for the common case of a few types with an
-   owner name, that it can represent owner names with all possible types
-   present in packets of approximately 8.5 kilobytes, and that the
-   representation is simple to implement.  Efficient searching of the
-   type bitmap for the presence of certain types is not a requirement.
-
-   For convenience and completeness, this document presents the syntax
-   and semantics for the NSEC RR based on the specification in RFC 2535
-   [2] and as updated by RFC 3755 [5], thereby not introducing changes
-   except for the syntax of the type bit map.
-
-   This document updates RFC 2535 [2] and RFC 3755 [5].
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in BCP 14, RFC 2119 [1].
-
-2.  The NSEC Resource Record
-
-   The NSEC resource record lists two separate things: the owner name of
-   the next RRset in the canonical ordering of the zone, and the set of
-   RR types present at the NSEC RR's owner name.  The complete set of
-   NSEC RRs in a zone indicate which RRsets exist in a zone, and form a
-   chain of owner names in the zone.  This information is used to
-   provide authenticated denial of existence for DNS data, as described
-   in RFC 2535 [2].
-
-   The type value for the NSEC RR is 47.
-
-
-
-Schlyter, Ed.               Standards Track                     [Page 2]
-
-RFC 3845                DNSSEC NSEC RDATA Format             August 2004
-
-
-   The NSEC RR RDATA format is class independent and defined for all
-   classes.
-
-   The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL
-   field.  This is in the spirit of negative caching [8].
-
-2.1.  NSEC RDATA Wire Format
-
-   The RDATA of the NSEC RR is as shown below:
-
-                         1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    /                      Next Domain Name                         /
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    /                   List of Type Bit Map(s)                     /
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-2.1.1.  The Next Domain Name Field
-
-   The Next Domain Name field contains the owner name of the next RR in
-   the canonical ordering of the zone.  The value of the Next Domain
-   Name field in the last NSEC record in the zone is the name of the
-   zone apex (the owner name of the zone's SOA RR).
-
-   A sender MUST NOT use DNS name compression on the Next Domain Name
-   field when transmitting an NSEC RR.
-
-   Owner names of RRsets that are not authoritative for the given zone
-   (such as glue records) MUST NOT be listed in the Next Domain Name
-   unless at least one authoritative RRset exists at the same owner
-   name.
-
-2.1.2.  The List of Type Bit Map(s) Field
-
-   The RR type space is split into 256 window blocks, each representing
-   the low-order 8 bits of the 16-bit RR type space.  Each block that
-   has at least one active RR type is encoded using a single octet
-   window number (from 0 to 255), a single octet bitmap length (from 1
-   to 32) indicating the number of octets used for the window block's
-   bitmap, and up to 32 octets (256 bits) of bitmap.
-
-   Window blocks are present in the NSEC RR RDATA in increasing
-   numerical order.
-
-   "|" denotes concatenation
-
-   Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) +
-
-
-
-Schlyter, Ed.               Standards Track                     [Page 3]
-
-RFC 3845                DNSSEC NSEC RDATA Format             August 2004
-
-
-   Each bitmap encodes the low-order 8 bits of RR types within the
-   window block, in network bit order.  The first bit is bit 0.  For
-   window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds
-   to RR type 2 (NS), and so forth.  For window block 1, bit 1
-   corresponds to RR type 257, and bit 2 to RR type 258.  If a bit is
-   set to 1, it indicates that an RRset of that type is present for the
-   NSEC RR's owner name.  If a bit is set to 0, it indicates that no
-   RRset of that type is present for the NSEC RR's owner name.
-
-   Since bit 0 in window block 0 refers to the non-existing RR type 0,
-   it MUST be set to 0.  After verification, the validator MUST ignore
-   the value of bit 0 in window block 0.
-
-   Bits representing Meta-TYPEs or QTYPEs, as specified in RFC 2929 [3]
-   (section 3.1), or within the range reserved for assignment only to
-   QTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear in
-   zone data.  If encountered, they must be ignored upon reading.
-
-   Blocks with no types present MUST NOT be included.  Trailing zero
-   octets in the bitmap MUST be omitted.  The length of each block's
-   bitmap is determined by the type code with the largest numerical
-   value within that block, among the set of RR types present at the
-   NSEC RR's owner name.  Trailing zero octets not specified MUST be
-   interpreted as zero octets.
-
-2.1.3.  Inclusion of Wildcard Names in NSEC RDATA
-
-   If a wildcard owner name appears in a zone, the wildcard label ("*")
-   is treated as a literal symbol and is treated the same as any other
-   owner name for purposes of generating NSEC RRs.  Wildcard owner names
-   appear in the Next Domain Name field without any wildcard expansion.
-   RFC 2535 [2] describes the impact of wildcards on authenticated
-   denial of existence.
-
-2.2.  The NSEC RR Presentation Format
-
-   The presentation format of the RDATA portion is as follows:
-
-   The Next Domain Name field is represented as a domain name.
-
-   The List of Type Bit Map(s) Field is represented as a sequence of RR
-   type mnemonics.  When the mnemonic is not known, the TYPE
-   representation as described in RFC 3597 [4] (section 5) MUST be used.
-
-
-
-
-
-
-
-
-Schlyter, Ed.               Standards Track                     [Page 4]
-
-RFC 3845                DNSSEC NSEC RDATA Format             August 2004
-
-
-2.3.  NSEC RR Example
-
-   The following NSEC RR identifies the RRsets associated with
-   alfa.example.com. and the next authoritative name after
-   alfa.example.com.
-
-   alfa.example.com. 86400 IN NSEC host.example.com. A MX RRSIG NSEC
-   TYPE1234
-
-   The first four text fields specify the name, TTL, Class, and RR type
-   (NSEC).  The entry host.example.com. is the next authoritative name
-   after alfa.example.com. in canonical order.  The A, MX, RRSIG, NSEC,
-   and TYPE1234 mnemonics indicate there are A, MX, RRSIG, NSEC, and
-   TYPE1234 RRsets associated with the name alfa.example.com.
-
-   The RDATA section of the NSEC RR above would be encoded as:
-
-      0x04 'h'  'o'  's'  't'
-      0x07 'e'  'x'  'a'  'm'  'p'  'l'  'e'
-      0x03 'c'  'o'  'm'  0x00
-      0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03
-      0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00
-      0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
-      0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
-      0x00 0x00 0x00 0x00 0x20
-
-   Assuming that the resolver can authenticate this NSEC record, it
-   could be used to prove that beta.example.com does not exist, or could
-   be used to prove that there is no AAAA record associated with
-   alfa.example.com.  Authenticated denial of existence is discussed in
-   RFC 2535 [2].
-
-3.  IANA Considerations
-
-   This document introduces no new IANA considerations, because all of
-   the protocol parameters used in this document have already been
-   assigned by RFC 3755 [5].
-
-4.  Security Considerations
-
-   The update of the RDATA format and encoding does not affect the
-   security of the use of NSEC RRs.
-
-
-
-
-
-
-
-
-
-Schlyter, Ed.               Standards Track                     [Page 5]
-
-RFC 3845                DNSSEC NSEC RDATA Format             August 2004
-
-
-5.  References
-
-5.1.  Normative References
-
-   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [2]  Eastlake 3rd, D., "Domain Name System Security Extensions", RFC
-        2535, March 1999.
-
-   [3]  Eastlake 3rd, D., Brunner-Williams, E., and B. Manning, "Domain
-        Name System (DNS) IANA Considerations", BCP 42, RFC 2929,
-        September 2000.
-
-   [4]  Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
-        Types", RFC 3597, September 2003.
-
-   [5]  Weiler, S., "Legacy Resolver Compatibility for Delegation Signer
-        (DS)", RFC 3755, May 2004.
-
-5.2.  Informative References
-
-   [6]  Mockapetris, P., "Domain names - concepts and facilities", STD
-        13, RFC 1034, November 1987.
-
-   [7]  Mockapetris, P., "Domain names - implementation and
-        specification", STD 13, RFC 1035, November 1987.
-
-   [8]  Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC
-        2308, March 1998.
-
-6.  Acknowledgements
-
-   The encoding described in this document was initially proposed by
-   Mark Andrews.  Other encodings where proposed by David Blacka and
-   Michael Graff.
-
-7.  Author's Address
-
-   Jakob Schlyter (editor)
-   NIC-SE
-   Box 5774
-   Stockholm  SE-114 87
-   Sweden
-
-   EMail: jakob@nic.se
-   URI: http://www.nic.se/
-
-
-
-
-Schlyter, Ed.               Standards Track                     [Page 6]
-
-RFC 3845                DNSSEC NSEC RDATA Format             August 2004
-
-
-8.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2004).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
-   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
-   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
-   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the IETF's procedures with respect to rights in IETF Documents can
-   be found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Schlyter, Ed.               Standards Track                     [Page 7]
-
diff --git a/contrib/bind9/doc/rfc/rfc3901.txt b/contrib/bind9/doc/rfc/rfc3901.txt
deleted file mode 100644
index 43b7356..0000000
--- a/contrib/bind9/doc/rfc/rfc3901.txt
+++ /dev/null
@@ -1,283 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          A. Durand
-Request for Comments: 3901                        SUN Microsystems, Inc.
-BCP: 91                                                         J. Ihren
-Category: Best Current Practice                               Autonomica
-                                                          September 2004
-
-
-               DNS IPv6 Transport Operational Guidelines
-
-Status of this Memo
-
-   This document specifies an Internet Best Current Practices for the
-   Internet Community, and requests discussion and suggestions for
-   improvements.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).
-
-Abstract
-
-   This memo provides guidelines and Best Current Practice for operating
-   DNS in a world where queries and responses are carried in a mixed
-   environment of IPv4 and IPv6 networks.
-
-1.  Introduction to the Problem of Name Space Fragmentation:
-    following the referral chain
-
-   A resolver that tries to look up a name starts out at the root, and
-   follows referrals until it is referred to a name server that is
-   authoritative for the name.  If somewhere down the chain of referrals
-   it is referred to a name server that is only accessible over a
-   transport which the resolver cannot use, the resolver is unable to
-   finish the task.
-
-   When the Internet moves from IPv4 to a mixture of IPv4 and IPv6 it is
-   only a matter of time until this starts to happen.  The complete DNS
-   hierarchy then starts to fragment into a graph where authoritative
-   name servers for certain nodes are only accessible over a certain
-   transport.  The concern is that a resolver using only a particular
-   version of IP and querying information about another node using the
-   same version of IP can not do it because somewhere in the chain of
-   servers accessed during the resolution process, one or more of them
-   will only be accessible with the other version of IP.
-
-   With all DNS data only available over IPv4 transport everything is
-   simple.  IPv4 resolvers can use the intended mechanism of following
-   referrals from the root and down while IPv6 resolvers have to work
-
-
-
-Durand & Ihren           Best Current Practice                  [Page 1]
-
-RFC 3901             DNS IPv6 Transport Guidelines        September 2004
-
-
-   through a "translator", i.e., they have to use a recursive name
-   server on a so-called "dual stack" host as a "forwarder" since they
-   cannot access the DNS data directly.
-
-   With all DNS data only available over IPv6 transport everything would
-   be equally simple, with the exception of IPv4 recursive name servers
-   having to switch to a forwarding configuration.
-
-   However, the second situation will not arise in the foreseeable
-   future.  Instead, the transition will be from IPv4 only to a mixture
-   of IPv4 and IPv6, with three categories of DNS data depending on
-   whether the information is available only over IPv4 transport, only
-   over IPv6 or both.
-
-   Having DNS data available on both transports is the best situation.
-   The major question is how to ensure that it becomes the norm as
-   quickly as possible.  However, while it is obvious that some DNS data
-   will only be available over v4 transport for a long time it is also
-   obvious that it is important to avoid fragmenting the name space
-   available to IPv4 only hosts.  For example, during transition it is
-   not acceptable to break the name space that we presently have
-   available for IPv4-only hosts.
-
-2.  Terminology
-
-   The phrase "IPv4 name server" indicates a name server available over
-   IPv4 transport.  It does not imply anything about what DNS [1,2] data
-   is served.  Likewise, "IPv6 [4,5,6] name server" indicates a name
-   server available over IPv6 transport.  The phrase "dual-stack name
-   server" indicates a name server that is actually configured to run
-   both protocols, IPv4 and IPv6, and not merely a server running on a
-   system capable of running both but actually configured to run only
-   one.
-
-3.  Policy Based Avoidance of Name Space Fragmentation
-
-   Today there are only a few DNS "zones" on the public Internet that
-   are available over IPv6 transport, and most of them can be regarded
-   as "experimental".  However, as soon as the root and top level
-   domains are available over IPv6 transport, it is reasonable to expect
-   that it will become more common to have zones served by IPv6 servers.
-
-   Having those zones served only by IPv6-only name server would not be
-   a good development, since this will fragment the previously
-   unfragmented IPv4 name space and there are strong reasons to find a
-   mechanism to avoid it.
-
-
-
-
-
-Durand & Ihren           Best Current Practice                  [Page 2]
-
-RFC 3901             DNS IPv6 Transport Guidelines        September 2004
-
-
-   The recommended approach to maintain name space continuity is to use
-   administrative policies, as described in the next section.
-
-4.  DNS IPv6 Transport recommended Guidelines
-
-   In order to preserve name space continuity, the following
-   administrative policies are recommended:
-
-      - every recursive name server SHOULD be either IPv4-only or dual
-        stack,
-
-         This rules out IPv6-only recursive servers.  However, one might
-         design configurations where a chain of IPv6-only name server
-         forward queries to a set of dual stack recursive name server
-         actually performing those recursive queries.
-
-      - every DNS zone SHOULD be served by at least one IPv4-reachable
-        authoritative name server.
-
-         This rules out DNS zones served only by IPv6-only authoritative
-         name servers.
-
-   Note: zone validation processes SHOULD ensure that there is at least
-   one IPv4 address record available for the name servers of any child
-   delegations within the zone.
-
-5.  Security Considerations
-
-   The guidelines described in this memo introduce no new security
-   considerations into the DNS protocol or associated operational
-   scenarios.
-
-6.  Acknowledgment
-
-   This document is the result of many conversations that happened in
-   the DNS community at IETF and elsewhere since 2001.  During that
-   period of time, a number of Internet drafts have been published to
-   clarify various aspects of the issues at stake.  This document
-   focuses on the conclusion of those discussions.
-
-   The authors would like to acknowledge the role of Pekka Savola in his
-   thorough review of the document.
-
-
-
-
-
-
-
-
-
-Durand & Ihren           Best Current Practice                  [Page 3]
-
-RFC 3901             DNS IPv6 Transport Guidelines        September 2004
-
-
-7.  Normative References
-
-   [1]  Mockapetris, P., "Domain names - concepts and facilities", STD
-        13, RFC 1034, November 1987.
-
-   [2]  Mockapetris, P., "Domain names - implementation and
-        specification", STD 13, RFC 1035, November 1987.
-
-   [3]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
-        9, RFC 2026, October 1996.
-
-   [4]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
-        Specification", RFC 2460, December 1998.
-
-   [5]  Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
-        Addressing Architecture", RFC 3513, April 2003.
-
-   [6]  Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS
-        Extensions to Support IP Version 6", RFC 3596, October 2003.
-
-8.  Authors' Addresses
-
-   Alain Durand
-   SUN Microsystems, Inc
-   17 Network circle UMPK17-202
-   Menlo Park, CA, 94025
-   USA
-
-   EMail: Alain.Durand@sun.com
-
-
-   Johan Ihren
-   Autonomica
-   Bellmansgatan 30
-   SE-118 47 Stockholm
-   Sweden
-
-   EMail: johani@autonomica.se
-
-
-
-
-
-
-
-
-
-
-
-
-
-Durand & Ihren           Best Current Practice                  [Page 4]
-
-RFC 3901             DNS IPv6 Transport Guidelines        September 2004
-
-
-9.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2004).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
-   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
-   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
-   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the IETF's procedures with respect to rights in IETF Documents can
-   be found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Durand & Ihren           Best Current Practice                  [Page 5]
-
diff --git a/contrib/bind9/doc/rfc/rfc4025.txt b/contrib/bind9/doc/rfc/rfc4025.txt
deleted file mode 100644
index 92e7f40..0000000
--- a/contrib/bind9/doc/rfc/rfc4025.txt
+++ /dev/null
@@ -1,675 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                      M. Richardson
-Request for Comments: 4025                                           SSW
-Category: Standards Track                                   February 2005
-
-
-           A Method for Storing IPsec Keying Material in DNS
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document describes a new resource record for the Domain Name
-   System (DNS).  This record may be used to store public keys for use
-   in IP security (IPsec) systems.  The record also includes provisions
-   for indicating what system should be contacted when an IPsec tunnel
-   is established with the entity in question.
-
-   This record replaces the functionality of the sub-type #4 of the KEY
-   Resource Record, which has been obsoleted by RFC 3445.
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
-       1.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . .  2
-       1.2.  Use of DNS Address-to-Name Maps (IN-ADDR.ARPA and
-             IP6.ARPA)  . . . . . . . . . . . . . . . . . . . . . . .  3
-       1.3.  Usage Criteria . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Storage Formats  . . . . . . . . . . . . . . . . . . . . . . .  3
-       2.1.  IPSECKEY RDATA Format  . . . . . . . . . . . . . . . . .  3
-       2.2.  RDATA Format - Precedence  . . . . . . . . . . . . . . .  4
-       2.3.  RDATA Format - Gateway Type  . . . . . . . . . . . . . .  4
-       2.4.  RDATA Format - Algorithm Type  . . . . . . . . . . . . .  4
-       2.5.  RDATA Format - Gateway . . . . . . . . . . . . . . . . .  5
-       2.6.  RDATA Format - Public Keys . . . . . . . . . . . . . . .  5
-   3.  Presentation Formats . . . . . . . . . . . . . . . . . . . . .  6
-       3.1.  Representation of IPSECKEY RRs . . . . . . . . . . . . .  6
-       3.2.  Examples . . . . . . . . . . . . . . . . . . . . . . . .  6
-   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
-
-
-
-Richardson                  Standards Track                     [Page 1]
-
-RFC 4025          Storing IPsec Keying Material in DNS     February 2005
-
-
-       4.1.  Active Attacks Against Unsecured IPSECKEY Resource
-             Records  . . . . . . . . . . . . . . . . . . . . . . . .  8
-             4.1.1.  Active Attacks Against IPSECKEY Keying
-                     Materials. . . . . . . . . . . . . . . . . . . .  8
-             4.1.2.  Active Attacks Against IPSECKEY Gateway
-                     Material. . . . . . . . . . . . . . . . . . . .   8
-   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
-   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
-   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
-       7.1.  Normative References . . . . . . . . . . . . . . . . . . 10
-       7.2.  Informative References . . . . . . . . . . . . . . . . . 10
-   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
-   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 12
-
-1.  Introduction
-
-   Suppose a host wishes (or is required by policy) to establish an
-   IPsec tunnel with some remote entity on the network prior to allowing
-   normal communication to take place.  In many cases, this end system
-   will be able to determine the DNS name for the remote entity (either
-   by having the DNS name given explicitly, by performing a DNS PTR
-   query for a particular IP address, or through some other means, e.g.,
-   by extracting the DNS portion of a "user@FQDN" name for a remote
-   entity).  In these cases, the host will need to obtain a public key
-   to authenticate the remote entity, and may also need some guidance
-   about whether it should contact the entity directly or use another
-   node as a gateway to the target entity.  The IPSECKEY RR provides a
-   mechanism for storing such information.
-
-   The type number for the IPSECKEY RR is 45.
-
-   This record replaces the functionality of the sub-type #4 of the KEY
-   Resource Record, which has been obsoleted by RFC 3445 [11].
-
-1.1.  Overview
-
-   The IPSECKEY resource record (RR) is used to publish a public key
-   that is to be associated with a Domain Name System (DNS) [1] name for
-   use with the IPsec protocol suite.  This can be the public key of a
-   host, network, or application (in the case of per-port keying).
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [3].
-
-
-
-
-
-
-
-Richardson                  Standards Track                     [Page 2]
-
-RFC 4025          Storing IPsec Keying Material in DNS     February 2005
-
-
-1.2.  Use of DNS Address-to-Name Maps (IN-ADDR.ARPA and IP6.ARPA)
-
-   Often a security gateway will only have access to the IP address of
-   the node with which communication is desired and will not know any
-   other name for the target node.  Because of this, frequently the best
-   way of looking up IPSECKEY RRs will be by using the IP address as an
-   index into one of the reverse mapping trees (IN-ADDR.ARPA for IPv4 or
-   IP6.ARPA for IPv6).
-
-   The lookup is done in the fashion usual for PTR records.  The IP
-   address' octets (IPv4) or nibbles (IPv6) are reversed and looked up
-   with the appropriate suffix.  Any CNAMEs or DNAMEs found MUST be
-   followed.
-
-   Note: even when the IPsec function is contained in the end-host,
-   often only the application will know the forward name used.  Although
-   the case where the application knows the forward name is common, the
-   user could easily have typed in a literal IP address.  This storage
-   mechanism does not preclude using the forward name when it is
-   available but does not require it.
-
-1.3.  Usage Criteria
-
-   An IPSECKEY resource record SHOULD be used in combination with DNSSEC
-   [8] unless some other means of authenticating the IPSECKEY resource
-   record is available.
-
-   It is expected that there will often be multiple IPSECKEY resource
-   records at the same name.  This will be due to the presence of
-   multiple gateways and a need to roll over keys.
-
-   This resource record is class independent.
-
-2.  Storage Formats
-
-2.1.  IPSECKEY RDATA Format
-
-   The RDATA for an IPSECKEY RR consists of a precedence value, a
-   gateway type, a public key, algorithm type, and an optional gateway
-   address.
-
-
-
-
-
-
-
-
-
-
-
-Richardson                  Standards Track                     [Page 3]
-
-RFC 4025          Storing IPsec Keying Material in DNS     February 2005
-
-
-       0                   1                   2                   3
-       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |  precedence   | gateway type  |  algorithm  |     gateway     |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------+                 +
-      ~                            gateway                            ~
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |                                                               /
-      /                          public key                           /
-      /                                                               /
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
-
-2.2.  RDATA Format - Precedence
-
-   This is an 8-bit precedence for this record.  It is interpreted in
-   the same way as the PREFERENCE field described in section 3.3.9 of
-   RFC 1035 [2].
-
-   Gateways listed in IPSECKEY records with lower precedence are to be
-   attempted first.  Where there is a tie in precedence, the order
-   should be non-deterministic.
-
-2.3.  RDATA Format - Gateway Type
-
-   The gateway type field indicates the format of the information that
-   is stored in the gateway field.
-
-   The following values are defined:
-   0  No gateway is present.
-   1  A 4-byte IPv4 address is present.
-   2  A 16-byte IPv6 address is present.
-   3  A wire-encoded domain name is present.  The wire-encoded format is
-      self-describing, so the length is implicit.  The domain name MUST
-      NOT be compressed.  (See Section 3.3 of RFC 1035 [2].)
-
-2.4.  RDATA Format - Algorithm Type
-
-   The algorithm type field identifies the public key's cryptographic
-   algorithm and determines the format of the public key field.
-
-   A value of 0 indicates that no key is present.
-
-   The following values are defined:
-   1  A DSA key is present, in the format defined in RFC 2536 [9].
-   2  A RSA key is present, in the format defined in RFC 3110 [10].
-
-
-
-
-
-
-Richardson                  Standards Track                     [Page 4]
-
-RFC 4025          Storing IPsec Keying Material in DNS     February 2005
-
-
-2.5.  RDATA Format - Gateway
-
-   The gateway field indicates a gateway to which an IPsec tunnel may be
-   created in order to reach the entity named by this resource record.
-
-   There are three formats:
-
-   A 32-bit IPv4 address is present in the gateway field.  The data
-   portion is an IPv4 address as described in section 3.4.1 of RFC 1035
-   [2].  This is a 32-bit number in network byte order.
-
-   A 128-bit IPv6 address is present in the gateway field.  The data
-   portion is an IPv6 address as described in section 2.2 of RFC 3596
-   [12].  This is a 128-bit number in network byte order.
-
-   The gateway field is a normal wire-encoded domain name, as described
-   in section 3.3 of RFC 1035 [2].  Compression MUST NOT be used.
-
-2.6.  RDATA Format - Public Keys
-
-   Both the public key types defined in this document (RSA and DSA)
-   inherit their public key formats from the corresponding KEY RR
-   formats.  Specifically, the public key field contains the
-   algorithm-specific portion of the KEY RR RDATA, which is all the KEY
-   RR DATA after the first four octets.  This is the same portion of the
-   KEY RR that must be specified by documents that define a DNSSEC
-   algorithm.  Those documents also specify a message digest to be used
-   for generation of SIG RRs; that specification is not relevant for
-   IPSECKEY RRs.
-
-   Future algorithms, if they are to be used by both DNSSEC (in the KEY
-   RR) and IPSECKEY, are likely to use the same public key encodings in
-   both records.  Unless otherwise specified, the IPSECKEY public key
-   field will contain the algorithm-specific portion of the KEY RR RDATA
-   for the corresponding algorithm.  The algorithm must still be
-   designated for use by IPSECKEY, and an IPSECKEY algorithm type number
-   (which might be different from the DNSSEC algorithm number) must be
-   assigned to it.
-
-   The DSA key format is defined in RFC 2536 [9]
-
-   The RSA key format is defined in RFC 3110 [10], with the following
-   changes:
-
-   The earlier definition of RSA/MD5 in RFC 2065 [4] limited the
-   exponent and modulus to 2552 bits in length.  RFC 3110 extended that
-   limit to 4096 bits for RSA/SHA1 keys.  The IPSECKEY RR imposes no
-   length limit on RSA public keys, other than the 65535 octet limit
-
-
-
-Richardson                  Standards Track                     [Page 5]
-
-RFC 4025          Storing IPsec Keying Material in DNS     February 2005
-
-
-   imposed by the two-octet length encoding.  This length extension is
-   applicable only to IPSECKEY; it is not applicable to KEY RRs.
-
-3.  Presentation Formats
-
-3.1.  Representation of IPSECKEY RRs
-
-   IPSECKEY RRs may appear in a zone data master file.  The precedence,
-   gateway type, algorithm, and gateway fields are REQUIRED.  The base64
-   encoded public key block is OPTIONAL; if it is not present, the
-   public key field of the resource record MUST be construed to be zero
-   octets in length.
-
-   The algorithm field is an unsigned integer.  No mnemonics are
-   defined.
-
-   If no gateway is to be indicated, then the gateway type field MUST be
-   zero, and the gateway field MUST be "."
-
-   The Public Key field is represented as a Base64 encoding of the
-   Public Key.  Whitespace is allowed within the Base64 text.  For a
-   definition of Base64 encoding, see RFC 3548 [6], Section 5.2.
-
-   The general presentation for the record is as follows:
-
-   IN     IPSECKEY ( precedence gateway-type algorithm
-                     gateway base64-encoded-public-key )
-
-3.2.  Examples
-
-   An example of a node, 192.0.2.38, that will accept IPsec tunnels on
-   its own behalf.
-
-   38.2.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 1 2
-                    192.0.2.38
-                    AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
-
-   An example of a node, 192.0.2.38, that has published its key only.
-
-   38.2.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 0 2
-                    .
-                    AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
-
-
-
-
-
-
-
-
-
-Richardson                  Standards Track                     [Page 6]
-
-RFC 4025          Storing IPsec Keying Material in DNS     February 2005
-
-
-   An example of a node, 192.0.2.38, that has delegated authority to the
-   node 192.0.2.3.
-
-   38.2.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 1 2
-                    192.0.2.3
-                    AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
-
-   An example of a node, 192.0.1.38 that has delegated authority to the
-   node with the identity "mygateway.example.com".
-
-   38.1.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 3 2
-                    mygateway.example.com.
-                    AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
-
-   An example of a node, 2001:0DB8:0200:1:210:f3ff:fe03:4d0, that has
-   delegated authority to the node 2001:0DB8:c000:0200:2::1
-
-   $ORIGIN 1.0.0.0.0.0.2.8.B.D.0.1.0.0.2.ip6.arpa.
-   0.d.4.0.3.0.e.f.f.f.3.f.0.1.2.0 7200 IN     IPSECKEY ( 10 2 2
-                    2001:0DB8:0:8002::2000:1
-                    AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
-
-4.  Security Considerations
-
-   This entire memo pertains to the provision of public keying material
-   for use by key management protocols such as ISAKMP/IKE (RFC 2407)
-   [7].
-
-   The IPSECKEY resource record contains information that SHOULD be
-   communicated to the end client in an integral fashion; i.e., free
-   from modification.  The form of this channel is up to the consumer of
-   the data; there must be a trust relationship between the end consumer
-   of this resource record and the server.  This relationship may be
-   end-to-end DNSSEC validation, a TSIG or SIG(0) channel to another
-   secure source, a secure local channel on the host, or some
-   combination of the above.
-
-   The keying material provided by the IPSECKEY resource record is not
-   sensitive to passive attacks.  The keying material may be freely
-   disclosed to any party without any impact on the security properties
-   of the resulting IPsec session.  IPsec and IKE provide defense
-   against both active and passive attacks.
-
-   Any derivative specification that makes use of this resource record
-   MUST carefully document its trust model and why the trust model of
-   DNSSEC is appropriate, if that is the secure channel used.
-
-
-
-
-
-Richardson                  Standards Track                     [Page 7]
-
-RFC 4025          Storing IPsec Keying Material in DNS     February 2005
-
-
-   An active attack on the DNS that caused the wrong IP address to be
-   retrieved (via forged address), and therefore the wrong QNAME to be
-   queried, would also result in a man-in-the-middle attack.  This
-   situation is independent of whether the IPSECKEY RR is used.
-
-4.1.  Active Attacks Against Unsecured IPSECKEY Resource Records
-
-   This section deals with active attacks against the DNS.  These
-   attacks require that DNS requests and responses be intercepted and
-   changed.  DNSSEC is designed to defend against attacks of this kind.
-   This section deals with the situation in which DNSSEC is not
-   available.  This is not the recommended deployment scenario.
-
-4.1.1.  Active Attacks Against IPSECKEY Keying Materials
-
-   The first kind of active attack is when the attacker replaces the
-   keying material with either a key under its control or with garbage.
-
-   The gateway field is either untouched or is null.  The IKE
-   negotiation will therefore occur with the original end-system.  For
-   this attack to succeed, the attacker must perform a man-in-the-middle
-   attack on the IKE negotiation.  This attack requires that the
-   attacker be able to intercept and modify packets on the forwarding
-   path for the IKE and data packets.
-
-   If the attacker is not able to perform this man-in-the-middle attack
-   on the IKE negotiation, then a denial of service will result, as the
-   IKE negotiation will fail.
-
-   If the attacker is not only able to mount active attacks against DNS
-   but also in a position to perform a man-in-the-middle attack on IKE
-   and IPsec negotiations, then the attacker will be able to compromise
-   the resulting IPsec channel.  Note that an attacker must be able to
-   perform active DNS attacks on both sides of the IKE negotiation for
-   this to succeed.
-
-4.1.2.  Active Attacks Against IPSECKEY Gateway Material
-
-   The second kind of active attack is one in which the attacker
-   replaces the gateway address to point to a node under the attacker's
-   control.  The attacker then either replaces the public key or removes
-   it.  If the public key were removed, then the attacker could provide
-   an accurate public key of its own in a second record.
-
-   This second form creates a simple man-in-the-middle attacks since the
-   attacker can then create a second tunnel to the real destination.
-   Note that, as before, this requires that the attacker also mount an
-   active attack against the responder.
-
-
-
-Richardson                  Standards Track                     [Page 8]
-
-RFC 4025          Storing IPsec Keying Material in DNS     February 2005
-
-
-   Note that the man-in-the-middle cannot just forward cleartext packets
-   to the original destination.  While the destination may be willing to
-   speak in the clear, replying to the original sender, the sender will
-   already have created a policy expecting ciphertext.  Thus, the
-   attacker will need to intercept traffic in both directions.  In some
-   cases, the attacker may be able to accomplish the full intercept by
-   use of Network Address/Port Translation (NAT/NAPT) technology.
-
-   This attack is easier than the first one because the attacker does
-   NOT need to be on the end-to-end forwarding path.  The attacker need
-   only be able to modify DNS replies.  This can be done by packet
-   modification, by various kinds of race attacks, or through methods
-   that pollute DNS caches.
-
-   If the end-to-end integrity of the IPSECKEY RR is suspect, the end
-   client MUST restrict its use of the IPSECKEY RR to cases where the RR
-   owner name matches the content of the gateway field.  As the RR owner
-   name is assumed when the gateway field is null, a null gateway field
-   is considered a match.
-
-   Thus, any records obtained under unverified conditions (e.g., no
-   DNSSEC or trusted path to source) that have a non-null gateway field
-   MUST be ignored.
-
-   This restriction eliminates attacks against the gateway field, which
-   are considered much easier, as the attack does not need to be on the
-   forwarding path.
-
-   In the case of an IPSECKEY RR with a value of three in its gateway
-   type field, the gateway field contains a domain name.  The subsequent
-   query required to translate that name into an IP address or IPSECKEY
-   RR will also be subject to man-in-the-middle attacks.  If the
-   end-to-end integrity of this second query is suspect, then the
-   provisions above also apply.  The IPSECKEY RR MUST be ignored
-   whenever the resulting gateway does not match the QNAME of the
-   original IPSECKEY RR query.
-
-5.  IANA Considerations
-
-   This document updates the IANA Registry for DNS Resource Record Types
-   by assigning type 45 to the IPSECKEY record.
-
-   This document creates two new IANA registries, both specific to the
-   IPSECKEY Resource Record:
-
-   This document creates an IANA registry for the algorithm type field.
-
-
-
-
-
-Richardson                  Standards Track                     [Page 9]
-
-RFC 4025          Storing IPsec Keying Material in DNS     February 2005
-
-
-   Values 0, 1, and 2 are defined in Section 2.4.  Algorithm numbers 3
-   through 255 can be assigned by IETF Consensus (see RFC 2434 [5]).
-
-   This document creates an IANA registry for the gateway type field.
-
-   Values 0, 1, 2, and 3 are defined in Section 2.3.  Gateway type
-   numbers 4 through 255 can be assigned by Standards Action (see RFC
-   2434 [5]).
-
-6.  Acknowledgements
-
-   My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig, Rob
-   Austein, and Olafur Gudmundsson, who reviewed this document
-   carefully.  Additional thanks to Olafur Gurmundsson for a reference
-   implementation.
-
-7.  References
-
-7.1.  Normative References
-
-   [1]  Mockapetris, P., "Domain names - concepts and facilities", STD
-        13, RFC 1034, November 1987.
-
-   [2]  Mockapetris, P., "Domain names - implementation and
-        specification", STD 13, RFC 1035, November 1987.
-
-   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [4]  Eastlake 3rd, D. and C. Kaufman, "Domain Name System Security
-        Extensions", RFC 2065, January 1997.
-
-   [5]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
-        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
-
-   [6]  Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
-        RFC 3548, July 2003.
-
-7.2.  Informative References
-
-   [7]  Piper, D., "The Internet IP Security Domain of Interpretation
-        for ISAKMP", RFC 2407, November 1998.
-
-   [8]  Eastlake 3rd, D., "Domain Name System Security Extensions", RFC
-        2535, March 1999.
-
-   [9]  Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name System
-        (DNS)", RFC 2536, March 1999.
-
-
-
-Richardson                  Standards Track                    [Page 10]
-
-RFC 4025          Storing IPsec Keying Material in DNS     February 2005
-
-
-   [10] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
-        Name System (DNS)", RFC 3110, May 2001.
-
-   [11] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
-        Record (RR)", RFC 3445, December 2002.
-
-   [12] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS
-        Extensions to Support IP Version 6", RFC 3596, October 2003.
-
-Author's Address
-
-   Michael C. Richardson
-   Sandelman Software Works
-   470 Dawson Avenue
-   Ottawa, ON  K1Z 5V7
-   CA
-
-   EMail: mcr@sandelman.ottawa.on.ca
-   URI:   http://www.sandelman.ottawa.on.ca/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Richardson                  Standards Track                    [Page 11]
-
-RFC 4025          Storing IPsec Keying Material in DNS     February 2005
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2005).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the IETF's procedures with respect to rights in IETF Documents can
-   be found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Richardson                  Standards Track                    [Page 12]
-
diff --git a/contrib/bind9/doc/rfc/rfc4033.txt b/contrib/bind9/doc/rfc/rfc4033.txt
deleted file mode 100644
index 7f0a464..0000000
--- a/contrib/bind9/doc/rfc/rfc4033.txt
+++ /dev/null
@@ -1,1179 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          R. Arends
-Request for Comments: 4033                          Telematica Instituut
-Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658,                R. Austein
-           3755, 3757, 3845                                          ISC
-Updates: 1034, 1035, 2136, 2181, 2308, 3225,                   M. Larson
-         3007, 3597, 3226                                       VeriSign
-Category: Standards Track                                      D. Massey
-                                               Colorado State University
-                                                                 S. Rose
-                                                                    NIST
-                                                              March 2005
-
-
-               DNS Security Introduction and Requirements
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   The Domain Name System Security Extensions (DNSSEC) add data origin
-   authentication and data integrity to the Domain Name System.  This
-   document introduces these extensions and describes their capabilities
-   and limitations.  This document also discusses the services that the
-   DNS security extensions do and do not provide.  Last, this document
-   describes the interrelationships between the documents that
-   collectively describe DNSSEC.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                     [Page 1]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .   2
-   2.  Definitions of Important DNSSEC Terms  . . . . . . . . . . .   3
-   3.  Services Provided by DNS Security  . . . . . . . . . . . . .   7
-       3.1.  Data Origin Authentication and Data Integrity  . . . .   7
-       3.2.  Authenticating Name and Type Non-Existence . . . . . .   9
-   4.  Services Not Provided by DNS Security  . . . . . . . . . . .   9
-   5.  Scope of the DNSSEC Document Set and Last Hop Issues . . . .   9
-   6.  Resolver Considerations  . . . . . . . . . . . . . . . . . .  10
-   7.  Stub Resolver Considerations . . . . . . . . . . . . . . . .  11
-   8.  Zone Considerations  . . . . . . . . . . . . . . . . . . . .  12
-       8.1.  TTL Values vs. RRSIG Validity Period . . . . . . . . .  13
-       8.2.  New Temporal Dependency Issues for Zones . . . . . . .  13
-   9.  Name Server Considerations . . . . . . . . . . . . . . . . .  13
-   10. DNS Security Document Family . . . . . . . . . . . . . . . .  14
-   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . .  15
-   12. Security Considerations  . . . . . . . . . . . . . . . . . .  15
-   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  17
-   14. References . . . . . . . . . . . . . . . . . . . . . . . . .  17
-       14.1. Normative References . . . . . . . . . . . . . . . . .  17
-       14.2. Informative References . . . . . . . . . . . . . . . .  18
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .  20
-   Full Copyright Statement . . . . . . . . . . . . . . . . . . . .  21
-
-1.  Introduction
-
-   This document introduces the Domain Name System Security Extensions
-   (DNSSEC).  This document and its two companion documents ([RFC4034]
-   and [RFC4035]) update, clarify, and refine the security extensions
-   defined in [RFC2535] and its predecessors.  These security extensions
-   consist of a set of new resource record types and modifications to
-   the existing DNS protocol ([RFC1035]).  The new records and protocol
-   modifications are not fully described in this document, but are
-   described in a family of documents outlined in Section 10.  Sections
-   3 and 4 describe the capabilities and limitations of the security
-   extensions in greater detail.  Section 5 discusses the scope of the
-   document set.  Sections 6, 7, 8, and 9 discuss the effect that these
-   security extensions will have on resolvers, stub resolvers, zones,
-   and name servers.
-
-   This document and its two companions obsolete [RFC2535], [RFC3008],
-   [RFC3090], [RFC3445], [RFC3655], [RFC3658], [RFC3755], [RFC3757], and
-   [RFC3845].  This document set also updates but does not obsolete
-   [RFC1034], [RFC1035], [RFC2136], [RFC2181], [RFC2308], [RFC3225],
-   [RFC3007], [RFC3597], and the portions of [RFC3226] that deal with
-   DNSSEC.
-
-
-
-
-Arends, et al.              Standards Track                     [Page 2]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-   The DNS security extensions provide origin authentication and
-   integrity protection for DNS data, as well as a means of public key
-   distribution.  These extensions do not provide confidentiality.
-
-2.  Definitions of Important DNSSEC Terms
-
-   This section defines a number of terms used in this document set.
-   Because this is intended to be useful as a reference while reading
-   the rest of the document set, first-time readers may wish to skim
-   this section quickly, read the rest of this document, and then come
-   back to this section.
-
-   Authentication Chain: An alternating sequence of DNS public key
-      (DNSKEY) RRsets and Delegation Signer (DS) RRsets forms a chain of
-      signed data, with each link in the chain vouching for the next.  A
-      DNSKEY RR is used to verify the signature covering a DS RR and
-      allows the DS RR to be authenticated.  The DS RR contains a hash
-      of another DNSKEY RR and this new DNSKEY RR is authenticated by
-      matching the hash in the DS RR.  This new DNSKEY RR in turn
-      authenticates another DNSKEY RRset and, in turn, some DNSKEY RR in
-      this set may be used to authenticate another DS RR, and so forth
-      until the chain finally ends with a DNSKEY RR whose corresponding
-      private key signs the desired DNS data.  For example, the root
-      DNSKEY RRset can be used to authenticate the DS RRset for
-      "example."  The "example." DS RRset contains a hash that matches
-      some "example." DNSKEY, and this DNSKEY's corresponding private
-      key signs the "example." DNSKEY RRset.  Private key counterparts
-      of the "example." DNSKEY RRset sign data records such as
-      "www.example." and DS RRs for delegations such as
-      "subzone.example."
-
-   Authentication Key: A public key that a security-aware resolver has
-      verified and can therefore use to authenticate data.  A
-      security-aware resolver can obtain authentication keys in three
-      ways.  First, the resolver is generally configured to know about
-      at least one public key; this configured data is usually either
-      the public key itself or a hash of the public key as found in the
-      DS RR (see "trust anchor").  Second, the resolver may use an
-      authenticated public key to verify a DS RR and the DNSKEY RR to
-      which the DS RR refers.  Third, the resolver may be able to
-      determine that a new public key has been signed by the private key
-      corresponding to another public key that the resolver has
-      verified.  Note that the resolver must always be guided by local
-      policy when deciding whether to authenticate a new public key,
-      even if the local policy is simply to authenticate any new public
-      key for which the resolver is able verify the signature.
-
-
-
-
-
-Arends, et al.              Standards Track                     [Page 3]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-   Authoritative RRset: Within the context of a particular zone, an
-      RRset is "authoritative" if and only if the owner name of the
-      RRset lies within the subset of the name space that is at or below
-      the zone apex and at or above the cuts that separate the zone from
-      its children, if any.  All RRsets at the zone apex are
-      authoritative, except for certain RRsets at this domain name that,
-      if present, belong to this zone's parent.  These RRset could
-      include a DS RRset, the NSEC RRset referencing this DS RRset (the
-      "parental NSEC"), and RRSIG RRs associated with these RRsets, all
-      of which are authoritative in the parent zone.  Similarly, if this
-      zone contains any delegation points, only the parental NSEC RRset,
-      DS RRsets, and any RRSIG RRs associated with these RRsets are
-      authoritative for this zone.
-
-   Delegation Point: Term used to describe the name at the parental side
-      of a zone cut.  That is, the delegation point for "foo.example"
-      would be the foo.example node in the "example" zone (as opposed to
-      the zone apex of the "foo.example" zone).  See also zone apex.
-
-   Island of Security: Term used to describe a signed, delegated zone
-      that does not have an authentication chain from its delegating
-      parent.  That is, there is no DS RR containing a hash of a DNSKEY
-      RR for the island in its delegating parent zone (see [RFC4034]).
-      An island of security is served by security-aware name servers and
-      may provide authentication chains to any delegated child zones.
-      Responses from an island of security or its descendents can only
-      be authenticated if its authentication keys can be authenticated
-      by some trusted means out of band from the DNS protocol.
-
-   Key Signing Key (KSK): An authentication key that corresponds to a
-      private key used to sign one or more other authentication keys for
-      a given zone.  Typically, the private key corresponding to a key
-      signing key will sign a zone signing key, which in turn has a
-      corresponding private key that will sign other zone data.  Local
-      policy may require that the zone signing key be changed
-      frequently, while the key signing key may have a longer validity
-      period in order to provide a more stable secure entry point into
-      the zone.  Designating an authentication key as a key signing key
-      is purely an operational issue: DNSSEC validation does not
-      distinguish between key signing keys and other DNSSEC
-      authentication keys, and it is possible to use a single key as
-      both a key signing key and a zone signing key.  Key signing keys
-      are discussed in more detail in [RFC3757].  Also see zone signing
-      key.
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                     [Page 4]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-   Non-Validating Security-Aware Stub Resolver: A security-aware stub
-      resolver that trusts one or more security-aware recursive name
-      servers to perform most of the tasks discussed in this document
-      set on its behalf.  In particular, a non-validating security-aware
-      stub resolver is an entity that sends DNS queries, receives DNS
-      responses, and is capable of establishing an appropriately secured
-      channel to a security-aware recursive name server that will
-      provide these services on behalf of the security-aware stub
-      resolver.  See also security-aware stub resolver, validating
-      security-aware stub resolver.
-
-   Non-Validating Stub Resolver: A less tedious term for a
-      non-validating security-aware stub resolver.
-
-   Security-Aware Name Server: An entity acting in the role of a name
-      server (defined in section 2.4 of [RFC1034]) that understands the
-      DNS security extensions defined in this document set.  In
-      particular, a security-aware name server is an entity that
-      receives DNS queries, sends DNS responses, supports the EDNS0
-      ([RFC2671]) message size extension and the DO bit ([RFC3225]), and
-      supports the RR types and message header bits defined in this
-      document set.
-
-   Security-Aware Recursive Name Server: An entity that acts in both the
-      security-aware name server and security-aware resolver roles.  A
-      more cumbersome but equivalent phrase would be "a security-aware
-      name server that offers recursive service".
-
-   Security-Aware Resolver: An entity acting in the role of a resolver
-      (defined in section 2.4 of [RFC1034]) that understands the DNS
-      security extensions defined in this document set.  In particular,
-      a security-aware resolver is an entity that sends DNS queries,
-      receives DNS responses, supports the EDNS0 ([RFC2671]) message
-      size extension and the DO bit ([RFC3225]), and is capable of using
-      the RR types and message header bits defined in this document set
-      to provide DNSSEC services.
-
-   Security-Aware Stub Resolver: An entity acting in the role of a stub
-      resolver (defined in section 5.3.1 of [RFC1034]) that has enough
-      of an understanding the DNS security extensions defined in this
-      document set to provide additional services not available from a
-      security-oblivious stub resolver.  Security-aware stub resolvers
-      may be either "validating" or "non-validating", depending on
-      whether the stub resolver attempts to verify DNSSEC signatures on
-      its own or trusts a friendly security-aware name server to do so.
-      See also validating stub resolver, non-validating stub resolver.
-
-
-
-
-
-Arends, et al.              Standards Track                     [Page 5]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-   Security-Oblivious <anything>: An <anything> that is not
-      "security-aware".
-
-   Signed Zone: A zone whose RRsets are signed and that contains
-      properly constructed DNSKEY, Resource Record Signature (RRSIG),
-      Next Secure (NSEC), and (optionally) DS records.
-
-   Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR.  A
-      validating security-aware resolver uses this public key or hash as
-      a starting point for building the authentication chain to a signed
-      DNS response.  In general, a validating resolver will have to
-      obtain the initial values of its trust anchors via some secure or
-      trusted means outside the DNS protocol.  Presence of a trust
-      anchor also implies that the resolver should expect the zone to
-      which the trust anchor points to be signed.
-
-   Unsigned Zone: A zone that is not signed.
-
-   Validating Security-Aware Stub Resolver: A security-aware resolver
-      that sends queries in recursive mode but that performs signature
-      validation on its own rather than just blindly trusting an
-      upstream security-aware recursive name server.  See also
-      security-aware stub resolver, non-validating security-aware stub
-      resolver.
-
-   Validating Stub Resolver: A less tedious term for a validating
-      security-aware stub resolver.
-
-   Zone Apex: Term used to describe the name at the child's side of a
-      zone cut.  See also delegation point.
-
-   Zone Signing Key (ZSK): An authentication key that corresponds to a
-      private key used to sign a zone.  Typically, a zone signing key
-      will be part of the same DNSKEY RRset as the key signing key whose
-      corresponding private key signs this DNSKEY RRset, but the zone
-      signing key is used for a slightly different purpose and may
-      differ from the key signing key in other ways, such as validity
-      lifetime.  Designating an authentication key as a zone signing key
-      is purely an operational issue; DNSSEC validation does not
-      distinguish between zone signing keys and other DNSSEC
-      authentication keys, and it is possible to use a single key as
-      both a key signing key and a zone signing key.  See also key
-      signing key.
-
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                     [Page 6]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-3.  Services Provided by DNS Security
-
-   The Domain Name System (DNS) security extensions provide origin
-   authentication and integrity assurance services for DNS data,
-   including mechanisms for authenticated denial of existence of DNS
-   data.  These mechanisms are described below.
-
-   These mechanisms require changes to the DNS protocol.  DNSSEC adds
-   four new resource record types: Resource Record Signature (RRSIG),
-   DNS Public Key (DNSKEY), Delegation Signer (DS), and Next Secure
-   (NSEC).  It also adds two new message header bits: Checking Disabled
-   (CD) and Authenticated Data (AD).  In order to support the larger DNS
-   message sizes that result from adding the DNSSEC RRs, DNSSEC also
-   requires EDNS0 support ([RFC2671]).  Finally, DNSSEC requires support
-   for the DNSSEC OK (DO) EDNS header bit ([RFC3225]) so that a
-   security-aware resolver can indicate in its queries that it wishes to
-   receive DNSSEC RRs in response messages.
-
-   These services protect against most of the threats to the Domain Name
-   System described in [RFC3833].  Please see Section 12 for a
-   discussion of the limitations of these extensions.
-
-3.1.  Data Origin Authentication and Data Integrity
-
-   DNSSEC provides authentication by associating cryptographically
-   generated digital signatures with DNS RRsets.  These digital
-   signatures are stored in a new resource record, the RRSIG record.
-   Typically, there will be a single private key that signs a zone's
-   data, but multiple keys are possible.  For example, there may be keys
-   for each of several different digital signature algorithms.  If a
-   security-aware resolver reliably learns a zone's public key, it can
-   authenticate that zone's signed data.  An important DNSSEC concept is
-   that the key that signs a zone's data is associated with the zone
-   itself and not with the zone's authoritative name servers.  (Public
-   keys for DNS transaction authentication mechanisms may also appear in
-   zones, as described in [RFC2931], but DNSSEC itself is concerned with
-   object security of DNS data, not channel security of DNS
-   transactions.  The keys associated with transaction security may be
-   stored in different RR types.  See [RFC3755] for details.)
-
-   A security-aware resolver can learn a zone's public key either by
-   having a trust anchor configured into the resolver or by normal DNS
-   resolution.  To allow the latter, public keys are stored in a new
-   type of resource record, the DNSKEY RR.  Note that the private keys
-   used to sign zone data must be kept secure and should be stored
-   offline when practical.  To discover a public key reliably via DNS
-   resolution, the target key itself has to be signed by either a
-   configured authentication key or another key that has been
-
-
-
-Arends, et al.              Standards Track                     [Page 7]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-   authenticated previously.  Security-aware resolvers authenticate zone
-   information by forming an authentication chain from a newly learned
-   public key back to a previously known authentication public key,
-   which in turn either has been configured into the resolver or must
-   have been learned and verified previously.  Therefore, the resolver
-   must be configured with at least one trust anchor.
-
-   If the configured trust anchor is a zone signing key, then it will
-   authenticate the associated zone; if the configured key is a key
-   signing key, it will authenticate a zone signing key.  If the
-   configured trust anchor is the hash of a key rather than the key
-   itself, the resolver may have to obtain the key via a DNS query.  To
-   help security-aware resolvers establish this authentication chain,
-   security-aware name servers attempt to send the signature(s) needed
-   to authenticate a zone's public key(s) in the DNS reply message along
-   with the public key itself, provided that there is space available in
-   the message.
-
-   The Delegation Signer (DS) RR type simplifies some of the
-   administrative tasks involved in signing delegations across
-   organizational boundaries.  The DS RRset resides at a delegation
-   point in a parent zone and indicates the public key(s) corresponding
-   to the private key(s) used to self-sign the DNSKEY RRset at the
-   delegated child zone's apex.  The administrator of the child zone, in
-   turn, uses the private key(s) corresponding to one or more of the
-   public keys in this DNSKEY RRset to sign the child zone's data.  The
-   typical authentication chain is therefore
-   DNSKEY->[DS->DNSKEY]*->RRset, where "*" denotes zero or more
-   DS->DNSKEY subchains.  DNSSEC permits more complex authentication
-   chains, such as additional layers of DNSKEY RRs signing other DNSKEY
-   RRs within a zone.
-
-   A security-aware resolver normally constructs this authentication
-   chain from the root of the DNS hierarchy down to the leaf zones based
-   on configured knowledge of the public key for the root.  Local
-   policy, however, may also allow a security-aware resolver to use one
-   or more configured public keys (or hashes of public keys) other than
-   the root public key, may not provide configured knowledge of the root
-   public key, or may prevent the resolver from using particular public
-   keys for arbitrary reasons, even if those public keys are properly
-   signed with verifiable signatures.  DNSSEC provides mechanisms by
-   which a security-aware resolver can determine whether an RRset's
-   signature is "valid" within the meaning of DNSSEC.  In the final
-   analysis, however, authenticating both DNS keys and data is a matter
-   of local policy, which may extend or even override the protocol
-   extensions defined in this document set.  See Section 5 for further
-   discussion.
-
-
-
-
-Arends, et al.              Standards Track                     [Page 8]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-3.2.  Authenticating Name and Type Non-Existence
-
-   The security mechanism described in Section 3.1 only provides a way
-   to sign existing RRsets in a zone.  The problem of providing negative
-   responses with the same level of authentication and integrity
-   requires the use of another new resource record type, the NSEC
-   record.  The NSEC record allows a security-aware resolver to
-   authenticate a negative reply for either name or type non-existence
-   with the same mechanisms used to authenticate other DNS replies.  Use
-   of NSEC records requires a canonical representation and ordering for
-   domain names in zones.  Chains of NSEC records explicitly describe
-   the gaps, or "empty space", between domain names in a zone and list
-   the types of RRsets present at existing names.  Each NSEC record is
-   signed and authenticated using the mechanisms described in Section
-   3.1.
-
-4.  Services Not Provided by DNS Security
-
-   DNS was originally designed with the assumptions that the DNS will
-   return the same answer to any given query regardless of who may have
-   issued the query, and that all data in the DNS is thus visible.
-   Accordingly, DNSSEC is not designed to provide confidentiality,
-   access control lists, or other means of differentiating between
-   inquirers.
-
-   DNSSEC provides no protection against denial of service attacks.
-   Security-aware resolvers and security-aware name servers are
-   vulnerable to an additional class of denial of service attacks based
-   on cryptographic operations.  Please see Section 12 for details.
-
-   The DNS security extensions provide data and origin authentication
-   for DNS data.  The mechanisms outlined above are not designed to
-   protect operations such as zone transfers and dynamic update
-   ([RFC2136], [RFC3007]).  Message authentication schemes described in
-   [RFC2845] and [RFC2931] address security operations that pertain to
-   these transactions.
-
-5.  Scope of the DNSSEC Document Set and Last Hop Issues
-
-   The specification in this document set defines the behavior for zone
-   signers and security-aware name servers and resolvers in such a way
-   that the validating entities can unambiguously determine the state of
-   the data.
-
-   A validating resolver can determine the following 4 states:
-
-   Secure: The validating resolver has a trust anchor, has a chain of
-      trust, and is able to verify all the signatures in the response.
-
-
-
-Arends, et al.              Standards Track                     [Page 9]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-   Insecure: The validating resolver has a trust anchor, a chain of
-      trust, and, at some delegation point, signed proof of the
-      non-existence of a DS record.  This indicates that subsequent
-      branches in the tree are provably insecure.  A validating resolver
-      may have a local policy to mark parts of the domain space as
-      insecure.
-
-   Bogus: The validating resolver has a trust anchor and a secure
-      delegation indicating that subsidiary data is signed, but the
-      response fails to validate for some reason: missing signatures,
-      expired signatures, signatures with unsupported algorithms, data
-      missing that the relevant NSEC RR says should be present, and so
-      forth.
-
-   Indeterminate: There is no trust anchor that would indicate that a
-      specific portion of the tree is secure.  This is the default
-      operation mode.
-
-   This specification only defines how security-aware name servers can
-   signal non-validating stub resolvers that data was found to be bogus
-   (using RCODE=2, "Server Failure"; see [RFC4035]).
-
-   There is a mechanism for security-aware name servers to signal
-   security-aware stub resolvers that data was found to be secure (using
-   the AD bit; see [RFC4035]).
-
-   This specification does not define a format for communicating why
-   responses were found to be bogus or marked as insecure.  The current
-   signaling mechanism does not distinguish between indeterminate and
-   insecure states.
-
-   A method for signaling advanced error codes and policy between a
-   security-aware stub resolver and security-aware recursive nameservers
-   is a topic for future work, as is the interface between a security-
-   aware resolver and the applications that use it.  Note, however, that
-   the lack of the specification of such communication does not prohibit
-   deployment of signed zones or the deployment of security aware
-   recursive name servers that prohibit propagation of bogus data to the
-   applications.
-
-6.  Resolver Considerations
-
-   A security-aware resolver has to be able to perform cryptographic
-   functions necessary to verify digital signatures using at least the
-   mandatory-to-implement algorithm(s).  Security-aware resolvers must
-   also be capable of forming an authentication chain from a newly
-   learned zone back to an authentication key, as described above.  This
-   process might require additional queries to intermediate DNS zones to
-
-
-
-Arends, et al.              Standards Track                    [Page 10]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-   obtain necessary DNSKEY, DS, and RRSIG records.  A security-aware
-   resolver should be configured with at least one trust anchor as the
-   starting point from which it will attempt to establish authentication
-   chains.
-
-   If a security-aware resolver is separated from the relevant
-   authoritative name servers by a recursive name server or by any sort
-   of intermediary device that acts as a proxy for DNS, and if the
-   recursive name server or intermediary device is not security-aware,
-   the security-aware resolver may not be capable of operating in a
-   secure mode.  For example, if a security-aware resolver's packets are
-   routed through a network address translation (NAT) device that
-   includes a DNS proxy that is not security-aware, the security-aware
-   resolver may find it difficult or impossible to obtain or validate
-   signed DNS data.  The security-aware resolver may have a particularly
-   difficult time obtaining DS RRs in such a case, as DS RRs do not
-   follow the usual DNS rules for ownership of RRs at zone cuts.  Note
-   that this problem is not specific to NATs: any security-oblivious DNS
-   software of any kind between the security-aware resolver and the
-   authoritative name servers will interfere with DNSSEC.
-
-   If a security-aware resolver must rely on an unsigned zone or a name
-   server that is not security aware, the resolver may not be able to
-   validate DNS responses and will need a local policy on whether to
-   accept unverified responses.
-
-   A security-aware resolver should take a signature's validation period
-   into consideration when determining the TTL of data in its cache, to
-   avoid caching signed data beyond the validity period of the
-   signature.  However, it should also allow for the possibility that
-   the security-aware resolver's own clock is wrong.  Thus, a
-   security-aware resolver that is part of a security-aware recursive
-   name server will have to pay careful attention to the DNSSEC
-   "checking disabled" (CD) bit ([RFC4034]).  This is in order to avoid
-   blocking valid signatures from getting through to other
-   security-aware resolvers that are clients of this recursive name
-   server.  See [RFC4035] for how a secure recursive server handles
-   queries with the CD bit set.
-
-7.  Stub Resolver Considerations
-
-   Although not strictly required to do so by the protocol, most DNS
-   queries originate from stub resolvers.  Stub resolvers, by
-   definition, are minimal DNS resolvers that use recursive query mode
-   to offload most of the work of DNS resolution to a recursive name
-   server.  Given the widespread use of stub resolvers, the DNSSEC
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 11]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-   architecture has to take stub resolvers into account, but the
-   security features needed in a stub resolver differ in some respects
-   from those needed in a security-aware iterative resolver.
-
-   Even a security-oblivious stub resolver may benefit from DNSSEC if
-   the recursive name servers it uses are security-aware, but for the
-   stub resolver to place any real reliance on DNSSEC services, the stub
-   resolver must trust both the recursive name servers in question and
-   the communication channels between itself and those name servers.
-   The first of these issues is a local policy issue: in essence, a
-   security-oblivious stub resolver has no choice but to place itself at
-   the mercy of the recursive name servers that it uses, as it does not
-   perform DNSSEC validity checks on its own.  The second issue requires
-   some kind of channel security mechanism; proper use of DNS
-   transaction authentication mechanisms such as SIG(0) ([RFC2931]) or
-   TSIG ([RFC2845]) would suffice, as would appropriate use of IPsec.
-   Particular implementations may have other choices available, such as
-   operating system specific interprocess communication mechanisms.
-   Confidentiality is not needed for this channel, but data integrity
-   and message authentication are.
-
-   A security-aware stub resolver that does trust both its recursive
-   name servers and its communication channel to them may choose to
-   examine the setting of the Authenticated Data (AD) bit in the message
-   header of the response messages it receives.  The stub resolver can
-   use this flag bit as a hint to find out whether the recursive name
-   server was able to validate signatures for all of the data in the
-   Answer and Authority sections of the response.
-
-   There is one more step that a security-aware stub resolver can take
-   if, for whatever reason, it is not able to establish a useful trust
-   relationship with the recursive name servers that it uses: it can
-   perform its own signature validation by setting the Checking Disabled
-   (CD) bit in its query messages.  A validating stub resolver is thus
-   able to treat the DNSSEC signatures as trust relationships between
-   the zone administrators and the stub resolver itself.
-
-8.  Zone Considerations
-
-   There are several differences between signed and unsigned zones.  A
-   signed zone will contain additional security-related records (RRSIG,
-   DNSKEY, DS, and NSEC records).  RRSIG and NSEC records may be
-   generated by a signing process prior to serving the zone.  The RRSIG
-   records that accompany zone data have defined inception and
-   expiration times that establish a validity period for the signatures
-   and the zone data the signatures cover.
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 12]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-8.1.  TTL Values vs. RRSIG Validity Period
-
-   It is important to note the distinction between a RRset's TTL value
-   and the signature validity period specified by the RRSIG RR covering
-   that RRset.  DNSSEC does not change the definition or function of the
-   TTL value, which is intended to maintain database coherency in
-   caches.  A caching resolver purges RRsets from its cache no later
-   than the end of the time period specified by the TTL fields of those
-   RRsets, regardless of whether the resolver is security-aware.
-
-   The inception and expiration fields in the RRSIG RR ([RFC4034]), on
-   the other hand, specify the time period during which the signature
-   can be used to validate the covered RRset.  The signatures associated
-   with signed zone data are only valid for the time period specified by
-   these fields in the RRSIG RRs in question.  TTL values cannot extend
-   the validity period of signed RRsets in a resolver's cache, but the
-   resolver may use the time remaining before expiration of the
-   signature validity period of a signed RRset as an upper bound for the
-   TTL of the signed RRset and its associated RRSIG RR in the resolver's
-   cache.
-
-8.2.  New Temporal Dependency Issues for Zones
-
-   Information in a signed zone has a temporal dependency that did not
-   exist in the original DNS protocol.  A signed zone requires regular
-   maintenance to ensure that each RRset in the zone has a current valid
-   RRSIG RR.  The signature validity period of an RRSIG RR is an
-   interval during which the signature for one particular signed RRset
-   can be considered valid, and the signatures of different RRsets in a
-   zone may expire at different times.  Re-signing one or more RRsets in
-   a zone will change one or more RRSIG RRs, which will in turn require
-   incrementing the zone's SOA serial number to indicate that a zone
-   change has occurred and re-signing the SOA RRset itself.  Thus,
-   re-signing any RRset in a zone may also trigger DNS NOTIFY messages
-   and zone transfer operations.
-
-9.  Name Server Considerations
-
-   A security-aware name server should include the appropriate DNSSEC
-   records (RRSIG, DNSKEY, DS, and NSEC) in all responses to queries
-   from resolvers that have signaled their willingness to receive such
-   records via use of the DO bit in the EDNS header, subject to message
-   size limitations.  Because inclusion of these DNSSEC RRs could easily
-   cause UDP message truncation and fallback to TCP, a security-aware
-   name server must also support the EDNS "sender's UDP payload"
-   mechanism.
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 13]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-   If possible, the private half of each DNSSEC key pair should be kept
-   offline, but this will not be possible for a zone for which DNS
-   dynamic update has been enabled.  In the dynamic update case, the
-   primary master server for the zone will have to re-sign the zone when
-   it is updated, so the private key corresponding to the zone signing
-   key will have to be kept online.  This is an example of a situation
-   in which the ability to separate the zone's DNSKEY RRset into zone
-   signing key(s) and key signing key(s) may be useful, as the key
-   signing key(s) in such a case can still be kept offline and may have
-   a longer useful lifetime than the zone signing key(s).
-
-   By itself, DNSSEC is not enough to protect the integrity of an entire
-   zone during zone transfer operations, as even a signed zone contains
-   some unsigned, nonauthoritative data if the zone has any children.
-   Therefore, zone maintenance operations will require some additional
-   mechanisms (most likely some form of channel security, such as TSIG,
-   SIG(0), or IPsec).
-
-10.  DNS Security Document Family
-
-   The DNSSEC document set can be partitioned into several main groups,
-   under the larger umbrella of the DNS base protocol documents.
-
-   The "DNSSEC protocol document set" refers to the three documents that
-   form the core of the DNS security extensions:
-
-   1.  DNS Security Introduction and Requirements (this document)
-
-   2.  Resource Records for DNS Security Extensions [RFC4034]
-
-   3.  Protocol Modifications for the DNS Security Extensions [RFC4035]
-
-   Additionally, any document that would add to or change the core DNS
-   Security extensions would fall into this category.  This includes any
-   future work on the communication between security-aware stub
-   resolvers and upstream security-aware recursive name servers.
-
-   The "Digital Signature Algorithm Specification" document set refers
-   to the group of documents that describe how specific digital
-   signature algorithms should be implemented to fit the DNSSEC resource
-   record format.  Each document in this set deals with a specific
-   digital signature algorithm.  Please see the appendix on "DNSSEC
-   Algorithm and Digest Types" in [RFC4034] for a list of the algorithms
-   that were defined when this core specification was written.
-
-   The "Transaction Authentication Protocol" document set refers to the
-   group of documents that deal with DNS message authentication,
-   including secret key establishment and verification.  Although not
-
-
-
-Arends, et al.              Standards Track                    [Page 14]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-   strictly part of the DNSSEC specification as defined in this set of
-   documents, this group is noted because of its relationship to DNSSEC.
-
-   The final document set, "New Security Uses", refers to documents that
-   seek to use proposed DNS Security extensions for other security
-   related purposes.  DNSSEC does not provide any direct security for
-   these new uses but may be used to support them.  Documents that fall
-   in this category include those describing the use of DNS in the
-   storage and distribution of certificates ([RFC2538]).
-
-11.  IANA Considerations
-
-   This overview document introduces no new IANA considerations.  Please
-   see [RFC4034] for a complete review of the IANA considerations
-   introduced by DNSSEC.
-
-12.  Security Considerations
-
-   This document introduces DNS security extensions and describes the
-   document set that contains the new security records and DNS protocol
-   modifications.  The extensions provide data origin authentication and
-   data integrity using digital signatures over resource record sets.
-   This section discusses the limitations of these extensions.
-
-   In order for a security-aware resolver to validate a DNS response,
-   all zones along the path from the trusted starting point to the zone
-   containing the response zones must be signed, and all name servers
-   and resolvers involved in the resolution process must be
-   security-aware, as defined in this document set.  A security-aware
-   resolver cannot verify responses originating from an unsigned zone,
-   from a zone not served by a security-aware name server, or for any
-   DNS data that the resolver is only able to obtain through a recursive
-   name server that is not security-aware.  If there is a break in the
-   authentication chain such that a security-aware resolver cannot
-   obtain and validate the authentication keys it needs, then the
-   security-aware resolver cannot validate the affected DNS data.
-
-   This document briefly discusses other methods of adding security to a
-   DNS query, such as using a channel secured by IPsec or using a DNS
-   transaction authentication mechanism such as TSIG ([RFC2845]) or
-   SIG(0) ([RFC2931]), but transaction security is not part of DNSSEC
-   per se.
-
-   A non-validating security-aware stub resolver, by definition, does
-   not perform DNSSEC signature validation on its own and thus is
-   vulnerable both to attacks on (and by) the security-aware recursive
-   name servers that perform these checks on its behalf and to attacks
-   on its communication with those security-aware recursive name
-
-
-
-Arends, et al.              Standards Track                    [Page 15]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-   servers.  Non-validating security-aware stub resolvers should use
-   some form of channel security to defend against the latter threat.
-   The only known defense against the former threat would be for the
-   security-aware stub resolver to perform its own signature validation,
-   at which point, again by definition, it would no longer be a
-   non-validating security-aware stub resolver.
-
-   DNSSEC does not protect against denial of service attacks.  DNSSEC
-   makes DNS vulnerable to a new class of denial of service attacks
-   based on cryptographic operations against security-aware resolvers
-   and security-aware name servers, as an attacker can attempt to use
-   DNSSEC mechanisms to consume a victim's resources.  This class of
-   attacks takes at least two forms.  An attacker may be able to consume
-   resources in a security-aware resolver's signature validation code by
-   tampering with RRSIG RRs in response messages or by constructing
-   needlessly complex signature chains.  An attacker may also be able to
-   consume resources in a security-aware name server that supports DNS
-   dynamic update, by sending a stream of update messages that force the
-   security-aware name server to re-sign some RRsets in the zone more
-   frequently than would otherwise be necessary.
-
-   Due to a deliberate design choice, DNSSEC does not provide
-   confidentiality.
-
-   DNSSEC introduces the ability for a hostile party to enumerate all
-   the names in a zone by following the NSEC chain.  NSEC RRs assert
-   which names do not exist in a zone by linking from existing name to
-   existing name along a canonical ordering of all the names within a
-   zone.  Thus, an attacker can query these NSEC RRs in sequence to
-   obtain all the names in a zone.  Although this is not an attack on
-   the DNS itself, it could allow an attacker to map network hosts or
-   other resources by enumerating the contents of a zone.
-
-   DNSSEC introduces significant additional complexity to the DNS and
-   thus introduces many new opportunities for implementation bugs and
-   misconfigured zones.  In particular, enabling DNSSEC signature
-   validation in a resolver may cause entire legitimate zones to become
-   effectively unreachable due to DNSSEC configuration errors or bugs.
-
-   DNSSEC does not protect against tampering with unsigned zone data.
-   Non-authoritative data at zone cuts (glue and NS RRs in the parent
-   zone) are not signed.  This does not pose a problem when validating
-   the authentication chain, but it does mean that the non-authoritative
-   data itself is vulnerable to tampering during zone transfer
-   operations.  Thus, while DNSSEC can provide data origin
-   authentication and data integrity for RRsets, it cannot do so for
-   zones, and other mechanisms (such as TSIG, SIG(0), or IPsec) must be
-   used to protect zone transfer operations.
-
-
-
-Arends, et al.              Standards Track                    [Page 16]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-   Please see [RFC4034] and [RFC4035] for additional security
-   considerations.
-
-13.  Acknowledgements
-
-   This document was created from the input and ideas of the members of
-   the DNS Extensions Working Group.  Although explicitly listing
-   everyone who has contributed during the decade in which DNSSEC has
-   been under development would be impossible, the editors would
-   particularly like to thank the following people for their
-   contributions to and comments on this document set: Jaap Akkerhuis,
-   Mark Andrews, Derek Atkins, Roy Badami, Alan Barrett, Dan Bernstein,
-   David Blacka, Len Budney, Randy Bush, Francis Dupont, Donald
-   Eastlake, Robert Elz, Miek Gieben, Michael Graff, Olafur Gudmundsson,
-   Gilles Guette, Andreas Gustafsson, Jun-ichiro Itojun Hagino, Phillip
-   Hallam-Baker, Bob Halley, Ted Hardie, Walter Howard, Greg Hudson,
-   Christian Huitema, Johan Ihren, Stephen Jacob, Jelte Jansen, Simon
-   Josefsson, Andris Kalnozols, Peter Koch, Olaf Kolkman, Mark Kosters,
-   Suresh Krishnaswamy, Ben Laurie, David Lawrence, Ted Lemon, Ed Lewis,
-   Ted Lindgreen, Josh Littlefield, Rip Loomis, Bill Manning, Russ
-   Mundy, Thomas Narten, Mans Nilsson, Masataka Ohta, Mike Patton, Rob
-   Payne, Jim Reid, Michael Richardson, Erik Rozendaal, Marcos Sanz,
-   Pekka Savola, Jakob Schlyter, Mike StJohns, Paul Vixie, Sam Weiler,
-   Brian Wellington, and Suzanne Woolf.
-
-   No doubt the above list is incomplete.  We apologize to anyone we
-   left out.
-
-14.  References
-
-14.1.  Normative References
-
-   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
-              STD 13, RFC 1034, November 1987.
-
-   [RFC1035]  Mockapetris, P., "Domain names - implementation and
-              specification", STD 13, RFC 1035, November 1987.
-
-   [RFC2535]  Eastlake 3rd, D., "Domain Name System Security
-              Extensions", RFC 2535, March 1999.
-
-   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
-              2671, August 1999.
-
-   [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
-              3225, December 2001.
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 17]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-   [RFC3226]  Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
-              message size requirements", RFC 3226, December 2001.
-
-   [RFC3445]  Massey, D. and S. Rose, "Limiting the Scope of the KEY
-              Resource Record (RR)", RFC 3445, December 2002.
-
-   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Resource Records for DNS Security Extensions", RFC
-              4034, March 2005.
-
-   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Protocol Modifications for the DNS Security
-              Extensions", RFC 4035, March 2005.
-
-14.2.  Informative References
-
-   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
-              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
-              RFC 2136, April 1997.
-
-   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
-              Specification", RFC 2181, July 1997.
-
-   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
-              NCACHE)", RFC 2308, March 1998.
-
-   [RFC2538]  Eastlake 3rd, D. and O. Gudmundsson, "Storing Certificates
-              in the Domain Name System (DNS)", RFC 2538, March 1999.
-
-   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
-              Wellington, "Secret Key Transaction Authentication for DNS
-              (TSIG)", RFC 2845, May 2000.
-
-   [RFC2931]  Eastlake 3rd, D., "DNS Request and Transaction Signatures
-              ( SIG(0)s )", RFC 2931, September 2000.
-
-   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
-              Update", RFC 3007, November 2000.
-
-   [RFC3008]  Wellington, B., "Domain Name System Security (DNSSEC)
-              Signing Authority", RFC 3008, November 2000.
-
-   [RFC3090]  Lewis, E., "DNS Security Extension Clarification on Zone
-              Status", RFC 3090, March 2001.
-
-   [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
-              (RR) Types", RFC 3597, September 2003.
-
-
-
-
-Arends, et al.              Standards Track                    [Page 18]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-   [RFC3655]  Wellington, B. and O. Gudmundsson, "Redefinition of DNS
-              Authenticated Data (AD) bit", RFC 3655, November 2003.
-
-   [RFC3658]  Gudmundsson, O., "Delegation Signer (DS) Resource Record
-              (RR)", RFC 3658, December 2003.
-
-   [RFC3755]  Weiler, S., "Legacy Resolver Compatibility for Delegation
-              Signer (DS)", RFC 3755, May 2004.
-
-   [RFC3757]  Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name
-              System KEY (DNSKEY) Resource Record (RR) Secure Entry
-              Point (SEP) Flag", RFC 3757, April 2004.
-
-   [RFC3833]  Atkins, D. and R. Austein, "Threat Analysis of the Domain
-              Name System (DNS)", RFC 3833, August 2004.
-
-   [RFC3845]  Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC)
-              RDATA Format", RFC 3845, August 2004.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 19]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-Authors' Addresses
-
-   Roy Arends
-   Telematica Instituut
-   Brouwerijstraat 1
-   7523 XC  Enschede
-   NL
-
-   EMail: roy.arends@telin.nl
-
-
-   Rob Austein
-   Internet Systems Consortium
-   950 Charter Street
-   Redwood City, CA  94063
-   USA
-
-   EMail: sra@isc.org
-
-
-   Matt Larson
-   VeriSign, Inc.
-   21345 Ridgetop Circle
-   Dulles, VA  20166-6503
-   USA
-
-   EMail: mlarson@verisign.com
-
-
-   Dan Massey
-   Colorado State University
-   Department of Computer Science
-   Fort Collins, CO 80523-1873
-
-   EMail: massey@cs.colostate.edu
-
-
-   Scott Rose
-   National Institute for Standards and Technology
-   100 Bureau Drive
-   Gaithersburg, MD  20899-8920
-   USA
-
-   EMail: scott.rose@nist.gov
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 20]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2005).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 21]
-
diff --git a/contrib/bind9/doc/rfc/rfc4034.txt b/contrib/bind9/doc/rfc/rfc4034.txt
deleted file mode 100644
index 6a12c6b..0000000
--- a/contrib/bind9/doc/rfc/rfc4034.txt
+++ /dev/null
@@ -1,1627 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          R. Arends
-Request for Comments: 4034                          Telematica Instituut
-Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658,                R. Austein
-           3755, 3757, 3845                                          ISC
-Updates: 1034, 1035, 2136, 2181, 2308, 3225,                   M. Larson
-         3007, 3597, 3226                                       VeriSign
-Category: Standards Track                                      D. Massey
-                                               Colorado State University
-                                                                 S. Rose
-                                                                    NIST
-                                                              March 2005
-
-
-            Resource Records for the DNS Security Extensions
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document is part of a family of documents that describe the DNS
-   Security Extensions (DNSSEC).  The DNS Security Extensions are a
-   collection of resource records and protocol modifications that
-   provide source authentication for the DNS.  This document defines the
-   public key (DNSKEY), delegation signer (DS), resource record digital
-   signature (RRSIG), and authenticated denial of existence (NSEC)
-   resource records.  The purpose and format of each resource record is
-   described in detail, and an example of each resource record is given.
-
-   This document obsoletes RFC 2535 and incorporates changes from all
-   updates to RFC 2535.
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                     [Page 1]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
-       1.1.  Background and Related Documents . . . . . . . . . . .  3
-       1.2.  Reserved Words . . . . . . . . . . . . . . . . . . . .  3
-   2.  The DNSKEY Resource Record . . . . . . . . . . . . . . . . .  4
-       2.1.  DNSKEY RDATA Wire Format . . . . . . . . . . . . . . .  4
-             2.1.1.  The Flags Field. . . . . . . . . . . . . . . .  4
-             2.1.2.  The Protocol Field . . . . . . . . . . . . . .  5
-             2.1.3.  The Algorithm Field. . . . . . . . . . . . . .  5
-             2.1.4.  The Public Key Field . . . . . . . . . . . . .  5
-             2.1.5.  Notes on DNSKEY RDATA Design . . . . . . . . .  5
-       2.2.  The DNSKEY RR Presentation Format. . . . . . . . . . .  5
-       2.3.  DNSKEY RR Example  . . . . . . . . . . . . . . . . . .  6
-   3.  The RRSIG Resource Record  . . . . . . . . . . . . . . . . .  6
-       3.1.  RRSIG RDATA Wire Format. . . . . . . . . . . . . . . .  7
-             3.1.1.  The Type Covered Field . . . . . . . . . . . .  7
-             3.1.2.  The Algorithm Number Field . . . . . . . . . .  8
-             3.1.3.  The Labels Field . . . . . . . . . . . . . . .  8
-             3.1.4.  Original TTL Field . . . . . . . . . . . . . .  8
-             3.1.5.  Signature Expiration and Inception Fields. . .  9
-             3.1.6.  The Key Tag Field. . . . . . . . . . . . . . .  9
-             3.1.7.  The Signer's Name Field. . . . . . . . . . . .  9
-             3.1.8.  The Signature Field. . . . . . . . . . . . . .  9
-       3.2.  The RRSIG RR Presentation Format . . . . . . . . . . . 10
-       3.3.  RRSIG RR Example . . . . . . . . . . . . . . . . . . . 11
-   4.  The NSEC Resource Record . . . . . . . . . . . . . . . . . . 12
-       4.1.  NSEC RDATA Wire Format . . . . . . . . . . . . . . . . 13
-             4.1.1.  The Next Domain Name Field . . . . . . . . . . 13
-             4.1.2.  The Type Bit Maps Field. . . . . . . . . . . . 13
-             4.1.3.  Inclusion of Wildcard Names in NSEC RDATA. . . 14
-       4.2.  The NSEC RR Presentation Format. . . . . . . . . . . . 14
-       4.3.  NSEC RR Example. . . . . . . . . . . . . . . . . . . . 15
-   5.  The DS Resource Record . . . . . . . . . . . . . . . . . . . 15
-       5.1.  DS RDATA Wire Format . . . . . . . . . . . . . . . . . 16
-             5.1.1.  The Key Tag Field. . . . . . . . . . . . . . . 16
-             5.1.2.  The Algorithm Field. . . . . . . . . . . . . . 16
-             5.1.3.  The Digest Type Field. . . . . . . . . . . . . 17
-             5.1.4.  The Digest Field . . . . . . . . . . . . . . . 17
-       5.2.  Processing of DS RRs When Validating Responses . . . . 17
-       5.3.  The DS RR Presentation Format. . . . . . . . . . . . . 17
-       5.4.  DS RR Example. . . . . . . . . . . . . . . . . . . . . 18
-   6.  Canonical Form and Order of Resource Records . . . . . . . . 18
-       6.1.  Canonical DNS Name Order . . . . . . . . . . . . . . . 18
-       6.2.  Canonical RR Form. . . . . . . . . . . . . . . . . . . 19
-       6.3.  Canonical RR Ordering within an RRset. . . . . . . . . 20
-   7.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . 20
-   8.  Security Considerations. . . . . . . . . . . . . . . . . . . 21
-
-
-
-Arends, et al.              Standards Track                     [Page 2]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
-   10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
-       10.1. Normative References . . . . . . . . . . . . . . . . . 22
-       10.2. Informative References . . . . . . . . . . . . . . . . 23
-   A.  DNSSEC Algorithm and Digest Types. . . . . . . . . . . . . . 24
-       A.1.  DNSSEC Algorithm Types . . . . . . . . . . . . . . . . 24
-             A.1.1.  Private Algorithm Types. . . . . . . . . . . . 25
-       A.2.  DNSSEC Digest Types. . . . . . . . . . . . . . . . . . 25
-   B.  Key Tag Calculation. . . . . . . . . . . . . . . . . . . . . 25
-       B.1.  Key Tag for Algorithm 1 (RSA/MD5). . . . . . . . . . . 27
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
-   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 29
-
-1.  Introduction
-
-   The DNS Security Extensions (DNSSEC) introduce four new DNS resource
-   record types: DNS Public Key (DNSKEY), Resource Record Signature
-   (RRSIG), Next Secure (NSEC), and Delegation Signer (DS).  This
-   document defines the purpose of each resource record (RR), the RR's
-   RDATA format, and its presentation format (ASCII representation).
-
-1.1.  Background and Related Documents
-
-   This document is part of a family of documents defining DNSSEC, which
-   should be read together as a set.
-
-   [RFC4033] contains an introduction to DNSSEC and definition of common
-   terms; the reader is assumed to be familiar with this document.
-   [RFC4033] also contains a list of other documents updated by and
-   obsoleted by this document set.
-
-   [RFC4035] defines the DNSSEC protocol operations.
-
-   The reader is also assumed to be familiar with the basic DNS concepts
-   described in [RFC1034], [RFC1035], and the subsequent documents that
-   update them, particularly [RFC2181] and [RFC2308].
-
-   This document defines the DNSSEC resource records.  All numeric DNS
-   type codes given in this document are decimal integers.
-
-1.2.  Reserved Words
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-Arends, et al.              Standards Track                     [Page 3]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-2.  The DNSKEY Resource Record
-
-   DNSSEC uses public key cryptography to sign and authenticate DNS
-   resource record sets (RRsets).  The public keys are stored in DNSKEY
-   resource records and are used in the DNSSEC authentication process
-   described in [RFC4035]: A zone signs its authoritative RRsets by
-   using a private key and stores the corresponding public key in a
-   DNSKEY RR.  A resolver can then use the public key to validate
-   signatures covering the RRsets in the zone, and thus to authenticate
-   them.
-
-   The DNSKEY RR is not intended as a record for storing arbitrary
-   public keys and MUST NOT be used to store certificates or public keys
-   that do not directly relate to the DNS infrastructure.
-
-   The Type value for the DNSKEY RR type is 48.
-
-   The DNSKEY RR is class independent.
-
-   The DNSKEY RR has no special TTL requirements.
-
-2.1.  DNSKEY RDATA Wire Format
-
-   The RDATA for a DNSKEY RR consists of a 2 octet Flags Field, a 1
-   octet Protocol Field, a 1 octet Algorithm Field, and the Public Key
-   Field.
-
-                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |              Flags            |    Protocol   |   Algorithm   |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   /                                                               /
-   /                            Public Key                         /
-   /                                                               /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-2.1.1.  The Flags Field
-
-   Bit 7 of the Flags field is the Zone Key flag.  If bit 7 has value 1,
-   then the DNSKEY record holds a DNS zone key, and the DNSKEY RR's
-   owner name MUST be the name of a zone.  If bit 7 has value 0, then
-   the DNSKEY record holds some other type of DNS public key and MUST
-   NOT be used to verify RRSIGs that cover RRsets.
-
-   Bit 15 of the Flags field is the Secure Entry Point flag, described
-   in [RFC3757].  If bit 15 has value 1, then the DNSKEY record holds a
-   key intended for use as a secure entry point.  This flag is only
-
-
-
-Arends, et al.              Standards Track                     [Page 4]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-   intended to be a hint to zone signing or debugging software as to the
-   intended use of this DNSKEY record; validators MUST NOT alter their
-   behavior during the signature validation process in any way based on
-   the setting of this bit.  This also means that a DNSKEY RR with the
-   SEP bit set would also need the Zone Key flag set in order to be able
-   to generate signatures legally.  A DNSKEY RR with the SEP set and the
-   Zone Key flag not set MUST NOT be used to verify RRSIGs that cover
-   RRsets.
-
-   Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon
-   creation of the DNSKEY RR and MUST be ignored upon receipt.
-
-2.1.2.  The Protocol Field
-
-   The Protocol Field MUST have value 3, and the DNSKEY RR MUST be
-   treated as invalid during signature verification if it is found to be
-   some value other than 3.
-
-2.1.3.  The Algorithm Field
-
-   The Algorithm field identifies the public key's cryptographic
-   algorithm and determines the format of the Public Key field.  A list
-   of DNSSEC algorithm types can be found in Appendix A.1
-
-2.1.4.  The Public Key Field
-
-   The Public Key Field holds the public key material.  The format
-   depends on the algorithm of the key being stored and is described in
-   separate documents.
-
-2.1.5.  Notes on DNSKEY RDATA Design
-
-   Although the Protocol Field always has value 3, it is retained for
-   backward compatibility with early versions of the KEY record.
-
-2.2.  The DNSKEY RR Presentation Format
-
-   The presentation format of the RDATA portion is as follows:
-
-   The Flag field MUST be represented as an unsigned decimal integer.
-   Given the currently defined flags, the possible values are: 0, 256,
-   and 257.
-
-   The Protocol Field MUST be represented as an unsigned decimal integer
-   with a value of 3.
-
-   The Algorithm field MUST be represented either as an unsigned decimal
-   integer or as an algorithm mnemonic as specified in Appendix A.1.
-
-
-
-Arends, et al.              Standards Track                     [Page 5]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-   The Public Key field MUST be represented as a Base64 encoding of the
-   Public Key.  Whitespace is allowed within the Base64 text.  For a
-   definition of Base64 encoding, see [RFC3548].
-
-2.3.  DNSKEY RR Example
-
-   The following DNSKEY RR stores a DNS zone key for example.com.
-
-   example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3
-                                          Cbl+BBZH4b/0PY1kxkmvHjcZc8no
-                                          kfzj31GajIQKY+5CptLr3buXA10h
-                                          WqTkF7H6RfoRqXQeogmMHfpftf6z
-                                          Mv1LyBUgia7za6ZEzOJBOztyvhjL
-                                          742iU/TpPSEDhm2SNKLijfUppn1U
-                                          aNvv4w==  )
-
-   The first four text fields specify the owner name, TTL, Class, and RR
-   type (DNSKEY).  Value 256 indicates that the Zone Key bit (bit 7) in
-   the Flags field has value 1.  Value 3 is the fixed Protocol value.
-   Value 5 indicates the public key algorithm.  Appendix A.1 identifies
-   algorithm type 5 as RSA/SHA1 and indicates that the format of the
-   RSA/SHA1 public key field is defined in [RFC3110].  The remaining
-   text is a Base64 encoding of the public key.
-
-3.  The RRSIG Resource Record
-
-   DNSSEC uses public key cryptography to sign and authenticate DNS
-   resource record sets (RRsets).  Digital signatures are stored in
-   RRSIG resource records and are used in the DNSSEC authentication
-   process described in [RFC4035].  A validator can use these RRSIG RRs
-   to authenticate RRsets from the zone.  The RRSIG RR MUST only be used
-   to carry verification material (digital signatures) used to secure
-   DNS operations.
-
-   An RRSIG record contains the signature for an RRset with a particular
-   name, class, and type.  The RRSIG RR specifies a validity interval
-   for the signature and uses the Algorithm, the Signer's Name, and the
-   Key Tag to identify the DNSKEY RR containing the public key that a
-   validator can use to verify the signature.
-
-   Because every authoritative RRset in a zone must be protected by a
-   digital signature, RRSIG RRs must be present for names containing a
-   CNAME RR.  This is a change to the traditional DNS specification
-   [RFC1034], which stated that if a CNAME is present for a name, it is
-   the only type allowed at that name.  A RRSIG and NSEC (see Section 4)
-   MUST exist for the same name as a CNAME resource record in a signed
-   zone.
-
-
-
-
-Arends, et al.              Standards Track                     [Page 6]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-   The Type value for the RRSIG RR type is 46.
-
-   The RRSIG RR is class independent.
-
-   An RRSIG RR MUST have the same class as the RRset it covers.
-
-   The TTL value of an RRSIG RR MUST match the TTL value of the RRset it
-   covers.  This is an exception to the [RFC2181] rules for TTL values
-   of individual RRs within a RRset: individual RRSIG RRs with the same
-   owner name will have different TTL values if the RRsets they cover
-   have different TTL values.
-
-3.1.  RRSIG RDATA Wire Format
-
-   The RDATA for an RRSIG RR consists of a 2 octet Type Covered field, a
-   1 octet Algorithm field, a 1 octet Labels field, a 4 octet Original
-   TTL field, a 4 octet Signature Expiration field, a 4 octet Signature
-   Inception field, a 2 octet Key tag, the Signer's Name field, and the
-   Signature field.
-
-                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |        Type Covered           |  Algorithm    |     Labels    |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                         Original TTL                          |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                      Signature Expiration                     |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                      Signature Inception                      |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |            Key Tag            |                               /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         Signer's Name         /
-   /                                                               /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   /                                                               /
-   /                            Signature                          /
-   /                                                               /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-3.1.1.  The Type Covered Field
-
-   The Type Covered field identifies the type of the RRset that is
-   covered by this RRSIG record.
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                     [Page 7]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-3.1.2.  The Algorithm Number Field
-
-   The Algorithm Number field identifies the cryptographic algorithm
-   used to create the signature.  A list of DNSSEC algorithm types can
-   be found in Appendix A.1
-
-3.1.3.  The Labels Field
-
-   The Labels field specifies the number of labels in the original RRSIG
-   RR owner name.  The significance of this field is that a validator
-   uses it to determine whether the answer was synthesized from a
-   wildcard.  If so, it can be used to determine what owner name was
-   used in generating the signature.
-
-   To validate a signature, the validator needs the original owner name
-   that was used to create the signature.  If the original owner name
-   contains a wildcard label ("*"), the owner name may have been
-   expanded by the server during the response process, in which case the
-   validator will have to reconstruct the original owner name in order
-   to validate the signature.  [RFC4035] describes how to use the Labels
-   field to reconstruct the original owner name.
-
-   The value of the Labels field MUST NOT count either the null (root)
-   label that terminates the owner name or the wildcard label (if
-   present).  The value of the Labels field MUST be less than or equal
-   to the number of labels in the RRSIG owner name.  For example,
-   "www.example.com." has a Labels field value of 3, and
-   "*.example.com." has a Labels field value of 2.  Root (".") has a
-   Labels field value of 0.
-
-   Although the wildcard label is not included in the count stored in
-   the Labels field of the RRSIG RR, the wildcard label is part of the
-   RRset's owner name when the signature is generated or verified.
-
-3.1.4.  Original TTL Field
-
-   The Original TTL field specifies the TTL of the covered RRset as it
-   appears in the authoritative zone.
-
-   The Original TTL field is necessary because a caching resolver
-   decrements the TTL value of a cached RRset.  In order to validate a
-   signature, a validator requires the original TTL.  [RFC4035]
-   describes how to use the Original TTL field value to reconstruct the
-   original TTL.
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                     [Page 8]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-3.1.5.  Signature Expiration and Inception Fields
-
-   The Signature Expiration and Inception fields specify a validity
-   period for the signature.  The RRSIG record MUST NOT be used for
-   authentication prior to the inception date and MUST NOT be used for
-   authentication after the expiration date.
-
-   The Signature Expiration and Inception field values specify a date
-   and time in the form of a 32-bit unsigned number of seconds elapsed
-   since 1 January 1970 00:00:00 UTC, ignoring leap seconds, in network
-   byte order.  The longest interval that can be expressed by this
-   format without wrapping is approximately 136 years.  An RRSIG RR can
-   have an Expiration field value that is numerically smaller than the
-   Inception field value if the expiration field value is near the
-   32-bit wrap-around point or if the signature is long lived.  Because
-   of this, all comparisons involving these fields MUST use "Serial
-   number arithmetic", as defined in [RFC1982].  As a direct
-   consequence, the values contained in these fields cannot refer to
-   dates more than 68 years in either the past or the future.
-
-3.1.6.  The Key Tag Field
-
-   The Key Tag field contains the key tag value of the DNSKEY RR that
-   validates this signature, in network byte order.  Appendix B explains
-   how to calculate Key Tag values.
-
-3.1.7.  The Signer's Name Field
-
-   The Signer's Name field value identifies the owner name of the DNSKEY
-   RR that a validator is supposed to use to validate this signature.
-   The Signer's Name field MUST contain the name of the zone of the
-   covered RRset.  A sender MUST NOT use DNS name compression on the
-   Signer's Name field when transmitting a RRSIG RR.
-
-3.1.8.  The Signature Field
-
-   The Signature field contains the cryptographic signature that covers
-   the RRSIG RDATA (excluding the Signature field) and the RRset
-   specified by the RRSIG owner name, RRSIG class, and RRSIG Type
-   Covered field.  The format of this field depends on the algorithm in
-   use, and these formats are described in separate companion documents.
-
-3.1.8.1.  Signature Calculation
-
-   A signature covers the RRSIG RDATA (excluding the Signature Field)
-   and covers the data RRset specified by the RRSIG owner name, RRSIG
-   class, and RRSIG Type Covered fields.  The RRset is in canonical form
-   (see Section 6), and the set RR(1),...RR(n) is signed as follows:
-
-
-
-Arends, et al.              Standards Track                     [Page 9]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-         signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) where
-
-            "|" denotes concatenation;
-
-            RRSIG_RDATA is the wire format of the RRSIG RDATA fields
-               with the Signer's Name field in canonical form and
-               the Signature field excluded;
-
-            RR(i) = owner | type | class | TTL | RDATA length | RDATA
-
-               "owner" is the fully qualified owner name of the RRset in
-               canonical form (for RRs with wildcard owner names, the
-               wildcard label is included in the owner name);
-
-               Each RR MUST have the same owner name as the RRSIG RR;
-
-               Each RR MUST have the same class as the RRSIG RR;
-
-               Each RR in the RRset MUST have the RR type listed in the
-               RRSIG RR's Type Covered field;
-
-               Each RR in the RRset MUST have the TTL listed in the
-               RRSIG Original TTL Field;
-
-               Any DNS names in the RDATA field of each RR MUST be in
-               canonical form; and
-
-               The RRset MUST be sorted in canonical order.
-
-   See Sections 6.2 and 6.3 for details on canonical form and ordering
-   of RRsets.
-
-3.2.  The RRSIG RR Presentation Format
-
-   The presentation format of the RDATA portion is as follows:
-
-   The Type Covered field is represented as an RR type mnemonic.  When
-   the mnemonic is not known, the TYPE representation as described in
-   [RFC3597], Section 5, MUST be used.
-
-   The Algorithm field value MUST be represented either as an unsigned
-   decimal integer or as an algorithm mnemonic, as specified in Appendix
-   A.1.
-
-   The Labels field value MUST be represented as an unsigned decimal
-   integer.
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 10]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-   The Original TTL field value MUST be represented as an unsigned
-   decimal integer.
-
-   The Signature Expiration Time and Inception Time field values MUST be
-   represented either as an unsigned decimal integer indicating seconds
-   since 1 January 1970 00:00:00 UTC, or in the form YYYYMMDDHHmmSS in
-   UTC, where:
-
-      YYYY is the year (0001-9999, but see Section 3.1.5);
-      MM is the month number (01-12);
-      DD is the day of the month (01-31);
-      HH is the hour, in 24 hour notation (00-23);
-      mm is the minute (00-59); and
-      SS is the second (00-59).
-
-   Note that it is always possible to distinguish between these two
-   formats because the YYYYMMDDHHmmSS format will always be exactly 14
-   digits, while the decimal representation of a 32-bit unsigned integer
-   can never be longer than 10 digits.
-
-   The Key Tag field MUST be represented as an unsigned decimal integer.
-
-   The Signer's Name field value MUST be represented as a domain name.
-
-   The Signature field is represented as a Base64 encoding of the
-   signature.  Whitespace is allowed within the Base64 text.  See
-   Section 2.2.
-
-3.3.  RRSIG RR Example
-
-   The following RRSIG RR stores the signature for the A RRset of
-   host.example.com:
-
-   host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 (
-                                  20030220173103 2642 example.com.
-                                  oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr
-                                  PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o
-                                  B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t
-                                  GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG
-                                  J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )
-
-   The first four fields specify the owner name, TTL, Class, and RR type
-   (RRSIG).  The "A" represents the Type Covered field.  The value 5
-   identifies the algorithm used (RSA/SHA1) to create the signature.
-   The value 3 is the number of Labels in the original owner name.  The
-   value 86400 in the RRSIG RDATA is the Original TTL for the covered A
-   RRset.  20030322173103 and 20030220173103 are the expiration and
-
-
-
-
-Arends, et al.              Standards Track                    [Page 11]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-   inception dates, respectively.  2642 is the Key Tag, and example.com.
-   is the Signer's Name.  The remaining text is a Base64 encoding of the
-   signature.
-
-   Note that combination of RRSIG RR owner name, class, and Type Covered
-   indicates that this RRSIG covers the "host.example.com" A RRset.  The
-   Label value of 3 indicates that no wildcard expansion was used.  The
-   Algorithm, Signer's Name, and Key Tag indicate that this signature
-   can be authenticated using an example.com zone DNSKEY RR whose
-   algorithm is 5 and whose key tag is 2642.
-
-4.  The NSEC Resource Record
-
-   The NSEC resource record lists two separate things: the next owner
-   name (in the canonical ordering of the zone) that contains
-   authoritative data or a delegation point NS RRset, and the set of RR
-   types present at the NSEC RR's owner name [RFC3845].  The complete
-   set of NSEC RRs in a zone indicates which authoritative RRsets exist
-   in a zone and also form a chain of authoritative owner names in the
-   zone.  This information is used to provide authenticated denial of
-   existence for DNS data, as described in [RFC4035].
-
-   Because every authoritative name in a zone must be part of the NSEC
-   chain, NSEC RRs must be present for names containing a CNAME RR.
-   This is a change to the traditional DNS specification [RFC1034],
-   which stated that if a CNAME is present for a name, it is the only
-   type allowed at that name.  An RRSIG (see Section 3) and NSEC MUST
-   exist for the same name as does a CNAME resource record in a signed
-   zone.
-
-   See [RFC4035] for discussion of how a zone signer determines
-   precisely which NSEC RRs it has to include in a zone.
-
-   The type value for the NSEC RR is 47.
-
-   The NSEC RR is class independent.
-
-   The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL
-   field.  This is in the spirit of negative caching ([RFC2308]).
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 12]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-4.1.  NSEC RDATA Wire Format
-
-   The RDATA of the NSEC RR is as shown below:
-
-                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   /                      Next Domain Name                         /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   /                       Type Bit Maps                           /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-4.1.1.  The Next Domain Name Field
-
-   The Next Domain field contains the next owner name (in the canonical
-   ordering of the zone) that has authoritative data or contains a
-   delegation point NS RRset; see Section 6.1 for an explanation of
-   canonical ordering.  The value of the Next Domain Name field in the
-   last NSEC record in the zone is the name of the zone apex (the owner
-   name of the zone's SOA RR).  This indicates that the owner name of
-   the NSEC RR is the last name in the canonical ordering of the zone.
-
-   A sender MUST NOT use DNS name compression on the Next Domain Name
-   field when transmitting an NSEC RR.
-
-   Owner names of RRsets for which the given zone is not authoritative
-   (such as glue records) MUST NOT be listed in the Next Domain Name
-   unless at least one authoritative RRset exists at the same owner
-   name.
-
-4.1.2.  The Type Bit Maps Field
-
-   The Type Bit Maps field identifies the RRset types that exist at the
-   NSEC RR's owner name.
-
-   The RR type space is split into 256 window blocks, each representing
-   the low-order 8 bits of the 16-bit RR type space.  Each block that
-   has at least one active RR type is encoded using a single octet
-   window number (from 0 to 255), a single octet bitmap length (from 1
-   to 32) indicating the number of octets used for the window block's
-   bitmap, and up to 32 octets (256 bits) of bitmap.
-
-   Blocks are present in the NSEC RR RDATA in increasing numerical
-   order.
-
-      Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
-
-      where "|" denotes concatenation.
-
-
-
-Arends, et al.              Standards Track                    [Page 13]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-   Each bitmap encodes the low-order 8 bits of RR types within the
-   window block, in network bit order.  The first bit is bit 0.  For
-   window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds
-   to RR type 2 (NS), and so forth.  For window block 1, bit 1
-   corresponds to RR type 257, and bit 2 to RR type 258.  If a bit is
-   set, it indicates that an RRset of that type is present for the NSEC
-   RR's owner name.  If a bit is clear, it indicates that no RRset of
-   that type is present for the NSEC RR's owner name.
-
-   Bits representing pseudo-types MUST be clear, as they do not appear
-   in zone data.  If encountered, they MUST be ignored upon being read.
-
-   Blocks with no types present MUST NOT be included.  Trailing zero
-   octets in the bitmap MUST be omitted.  The length of each block's
-   bitmap is determined by the type code with the largest numerical
-   value, within that block, among the set of RR types present at the
-   NSEC RR's owner name.  Trailing zero octets not specified MUST be
-   interpreted as zero octets.
-
-   The bitmap for the NSEC RR at a delegation point requires special
-   attention.  Bits corresponding to the delegation NS RRset and the RR
-   types for which the parent zone has authoritative data MUST be set;
-   bits corresponding to any non-NS RRset for which the parent is not
-   authoritative MUST be clear.
-
-   A zone MUST NOT include an NSEC RR for any domain name that only
-   holds glue records.
-
-4.1.3.  Inclusion of Wildcard Names in NSEC RDATA
-
-   If a wildcard owner name appears in a zone, the wildcard label ("*")
-   is treated as a literal symbol and is treated the same as any other
-   owner name for the purposes of generating NSEC RRs.  Wildcard owner
-   names appear in the Next Domain Name field without any wildcard
-   expansion.  [RFC4035] describes the impact of wildcards on
-   authenticated denial of existence.
-
-4.2.  The NSEC RR Presentation Format
-
-   The presentation format of the RDATA portion is as follows:
-
-   The Next Domain Name field is represented as a domain name.
-
-   The Type Bit Maps field is represented as a sequence of RR type
-   mnemonics.  When the mnemonic is not known, the TYPE representation
-   described in [RFC3597], Section 5, MUST be used.
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 14]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-4.3.  NSEC RR Example
-
-   The following NSEC RR identifies the RRsets associated with
-   alfa.example.com. and identifies the next authoritative name after
-   alfa.example.com.
-
-   alfa.example.com. 86400 IN NSEC host.example.com. (
-                                   A MX RRSIG NSEC TYPE1234 )
-
-   The first four text fields specify the name, TTL, Class, and RR type
-   (NSEC).  The entry host.example.com. is the next authoritative name
-   after alfa.example.com. in canonical order.  The A, MX, RRSIG, NSEC,
-   and TYPE1234 mnemonics indicate that there are A, MX, RRSIG, NSEC,
-   and TYPE1234 RRsets associated with the name alfa.example.com.
-
-   The RDATA section of the NSEC RR above would be encoded as:
-
-            0x04 'h'  'o'  's'  't'
-            0x07 'e'  'x'  'a'  'm'  'p'  'l'  'e'
-            0x03 'c'  'o'  'm'  0x00
-            0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03
-            0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00
-            0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
-            0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
-            0x00 0x00 0x00 0x00 0x20
-
-   Assuming that the validator can authenticate this NSEC record, it
-   could be used to prove that beta.example.com does not exist, or to
-   prove that there is no AAAA record associated with alfa.example.com.
-   Authenticated denial of existence is discussed in [RFC4035].
-
-5.  The DS Resource Record
-
-   The DS Resource Record refers to a DNSKEY RR and is used in the DNS
-   DNSKEY authentication process.  A DS RR refers to a DNSKEY RR by
-   storing the key tag, algorithm number, and a digest of the DNSKEY RR.
-   Note that while the digest should be sufficient to identify the
-   public key, storing the key tag and key algorithm helps make the
-   identification process more efficient.  By authenticating the DS
-   record, a resolver can authenticate the DNSKEY RR to which the DS
-   record points.  The key authentication process is described in
-   [RFC4035].
-
-   The DS RR and its corresponding DNSKEY RR have the same owner name,
-   but they are stored in different locations.  The DS RR appears only
-   on the upper (parental) side of a delegation, and is authoritative
-   data in the parent zone.  For example, the DS RR for "example.com" is
-   stored in the "com" zone (the parent zone) rather than in the
-
-
-
-Arends, et al.              Standards Track                    [Page 15]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-   "example.com" zone (the child zone).  The corresponding DNSKEY RR is
-   stored in the "example.com" zone (the child zone).  This simplifies
-   DNS zone management and zone signing but introduces special response
-   processing requirements for the DS RR; these are described in
-   [RFC4035].
-
-   The type number for the DS record is 43.
-
-   The DS resource record is class independent.
-
-   The DS RR has no special TTL requirements.
-
-5.1.  DS RDATA Wire Format
-
-   The RDATA for a DS RR consists of a 2 octet Key Tag field, a 1 octet
-   Algorithm field, a 1 octet Digest Type field, and a Digest field.
-
-                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |           Key Tag             |  Algorithm    |  Digest Type  |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   /                                                               /
-   /                            Digest                             /
-   /                                                               /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-5.1.1.  The Key Tag Field
-
-   The Key Tag field lists the key tag of the DNSKEY RR referred to by
-   the DS record, in network byte order.
-
-   The Key Tag used by the DS RR is identical to the Key Tag used by
-   RRSIG RRs.  Appendix B describes how to compute a Key Tag.
-
-5.1.2.  The Algorithm Field
-
-   The Algorithm field lists the algorithm number of the DNSKEY RR
-   referred to by the DS record.
-
-   The algorithm number used by the DS RR is identical to the algorithm
-   number used by RRSIG and DNSKEY RRs.  Appendix A.1 lists the
-   algorithm number types.
-
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 16]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-5.1.3.  The Digest Type Field
-
-   The DS RR refers to a DNSKEY RR by including a digest of that DNSKEY
-   RR.  The Digest Type field identifies the algorithm used to construct
-   the digest.  Appendix A.2 lists the possible digest algorithm types.
-
-5.1.4.  The Digest Field
-
-   The DS record refers to a DNSKEY RR by including a digest of that
-   DNSKEY RR.
-
-   The digest is calculated by concatenating the canonical form of the
-   fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA,
-   and then applying the digest algorithm.
-
-     digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA);
-
-      "|" denotes concatenation
-
-     DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key.
-
-   The size of the digest may vary depending on the digest algorithm and
-   DNSKEY RR size.  As of the time of this writing, the only defined
-   digest algorithm is SHA-1, which produces a 20 octet digest.
-
-5.2.  Processing of DS RRs When Validating Responses
-
-   The DS RR links the authentication chain across zone boundaries, so
-   the DS RR requires extra care in processing.  The DNSKEY RR referred
-   to in the DS RR MUST be a DNSSEC zone key.  The DNSKEY RR Flags MUST
-   have Flags bit 7 set.  If the DNSKEY flags do not indicate a DNSSEC
-   zone key, the DS RR (and the DNSKEY RR it references) MUST NOT be
-   used in the validation process.
-
-5.3.  The DS RR Presentation Format
-
-   The presentation format of the RDATA portion is as follows:
-
-   The Key Tag field MUST be represented as an unsigned decimal integer.
-
-   The Algorithm field MUST be represented either as an unsigned decimal
-   integer or as an algorithm mnemonic specified in Appendix A.1.
-
-   The Digest Type field MUST be represented as an unsigned decimal
-   integer.
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 17]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-   The Digest MUST be represented as a sequence of case-insensitive
-   hexadecimal digits.  Whitespace is allowed within the hexadecimal
-   text.
-
-5.4.  DS RR Example
-
-   The following example shows a DNSKEY RR and its corresponding DS RR.
-
-   dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
-                                             fwJr1AYtsmx3TGkJaNXVbfi/
-                                             2pHm822aJ5iI9BMzNXxeYCmZ
-                                             DRD99WYwYqUSdjMmmAphXdvx
-                                             egXd/M5+X7OrzKBaMbCVdFLU
-                                             Uh6DhweJBjEVv5f2wwjM9Xzc
-                                             nOf+EPbtG9DMBmADjFDc2w/r
-                                             ljwvFw==
-                                             ) ;  key id = 60485
-
-   dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A
-                                              98631FAD1A292118 )
-
-   The first four text fields specify the name, TTL, Class, and RR type
-   (DS).  Value 60485 is the key tag for the corresponding
-   "dskey.example.com." DNSKEY RR, and value 5 denotes the algorithm
-   used by this "dskey.example.com." DNSKEY RR.  The value 1 is the
-   algorithm used to construct the digest, and the rest of the RDATA
-   text is the digest in hexadecimal.
-
-6.  Canonical Form and Order of Resource Records
-
-   This section defines a canonical form for resource records, a
-   canonical ordering of DNS names, and a canonical ordering of resource
-   records within an RRset.  A canonical name order is required to
-   construct the NSEC name chain.  A canonical RR form and ordering
-   within an RRset are required in order to construct and verify RRSIG
-   RRs.
-
-6.1.  Canonical DNS Name Order
-
-   For the purposes of DNS security, owner names are ordered by treating
-   individual labels as unsigned left-justified octet strings.  The
-   absence of a octet sorts before a zero value octet, and uppercase
-   US-ASCII letters are treated as if they were lowercase US-ASCII
-   letters.
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 18]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-   To compute the canonical ordering of a set of DNS names, start by
-   sorting the names according to their most significant (rightmost)
-   labels.  For names in which the most significant label is identical,
-   continue sorting according to their next most significant label, and
-   so forth.
-
-   For example, the following names are sorted in canonical DNS name
-   order.  The most significant label is "example".  At this level,
-   "example" sorts first, followed by names ending in "a.example", then
-   by names ending "z.example".  The names within each level are sorted
-   in the same way.
-
-             example
-             a.example
-             yljkjljk.a.example
-             Z.a.example
-             zABC.a.EXAMPLE
-             z.example
-             \001.z.example
-             *.z.example
-             \200.z.example
-
-6.2.  Canonical RR Form
-
-   For the purposes of DNS security, the canonical form of an RR is the
-   wire format of the RR where:
-
-   1.  every domain name in the RR is fully expanded (no DNS name
-       compression) and fully qualified;
-
-   2.  all uppercase US-ASCII letters in the owner name of the RR are
-       replaced by the corresponding lowercase US-ASCII letters;
-
-   3.  if the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
-       HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX,
-       SRV, DNAME, A6, RRSIG, or NSEC, all uppercase US-ASCII letters in
-       the DNS names contained within the RDATA are replaced by the
-       corresponding lowercase US-ASCII letters;
-
-   4.  if the owner name of the RR is a wildcard name, the owner name is
-       in its original unexpanded form, including the "*" label (no
-       wildcard substitution); and
-
-   5.  the RR's TTL is set to its original value as it appears in the
-       originating authoritative zone or the Original TTL field of the
-       covering RRSIG RR.
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 19]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-6.3.  Canonical RR Ordering within an RRset
-
-   For the purposes of DNS security, RRs with the same owner name,
-   class, and type are sorted by treating the RDATA portion of the
-   canonical form of each RR as a left-justified unsigned octet sequence
-   in which the absence of an octet sorts before a zero octet.
-
-   [RFC2181] specifies that an RRset is not allowed to contain duplicate
-   records (multiple RRs with the same owner name, class, type, and
-   RDATA).  Therefore, if an implementation detects duplicate RRs when
-   putting the RRset in canonical form, it MUST treat this as a protocol
-   error.  If the implementation chooses to handle this protocol error
-   in the spirit of the robustness principle (being liberal in what it
-   accepts), it MUST remove all but one of the duplicate RR(s) for the
-   purposes of calculating the canonical form of the RRset.
-
-7.  IANA Considerations
-
-   This document introduces no new IANA considerations, as all of the
-   protocol parameters used in this document have already been assigned
-   by previous specifications.  However, since the evolution of DNSSEC
-   has been long and somewhat convoluted, this section attempts to
-   describe the current state of the IANA registries and other protocol
-   parameters that are (or once were) related to DNSSEC.
-
-   Please refer to [RFC4035] for additional IANA considerations.
-
-   DNS Resource Record Types: [RFC2535] assigned types 24, 25, and 30 to
-      the SIG, KEY, and NXT RRs, respectively.  [RFC3658] assigned DNS
-      Resource Record Type 43 to DS.  [RFC3755] assigned types 46, 47,
-      and 48 to the RRSIG, NSEC, and DNSKEY RRs, respectively.
-      [RFC3755] also marked type 30 (NXT) as Obsolete and restricted use
-      of types 24 (SIG) and 25 (KEY) to the "SIG(0)" transaction
-      security protocol described in [RFC2931] and to the transaction
-      KEY Resource Record described in [RFC2930].
-
-   DNS Security Algorithm Numbers: [RFC2535] created an IANA registry
-      for DNSSEC Resource Record Algorithm field numbers and assigned
-      values 1-4 and 252-255.  [RFC3110] assigned value 5.  [RFC3755]
-      altered this registry to include flags for each entry regarding
-      its use with the DNS security extensions.  Each algorithm entry
-      could refer to an algorithm that can be used for zone signing,
-      transaction security (see [RFC2931]), or both.  Values 6-251 are
-      available for assignment by IETF standards action ([RFC3755]).
-      See Appendix A for a full listing of the DNS Security Algorithm
-      Numbers entries at the time of this writing and their status for
-      use in DNSSEC.
-
-
-
-
-Arends, et al.              Standards Track                    [Page 20]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-      [RFC3658] created an IANA registry for DNSSEC DS Digest Types and
-      assigned value 0 to reserved and value 1 to SHA-1.
-
-   KEY Protocol Values: [RFC2535] created an IANA Registry for KEY
-      Protocol Values, but [RFC3445] reassigned all values other than 3
-      to reserved and closed this IANA registry.  The registry remains
-      closed, and all KEY and DNSKEY records are required to have a
-      Protocol Octet value of 3.
-
-   Flag bits in the KEY and DNSKEY RRs: [RFC3755] created an IANA
-      registry for the DNSSEC KEY and DNSKEY RR flag bits.  Initially,
-      this registry only contains assignments for bit 7 (the ZONE bit)
-      and bit 15 (the Secure Entry Point flag (SEP) bit; see [RFC3757]).
-      As stated in [RFC3755], bits 0-6 and 8-14 are available for
-      assignment by IETF Standards Action.
-
-8.  Security Considerations
-
-   This document describes the format of four DNS resource records used
-   by the DNS security extensions and presents an algorithm for
-   calculating a key tag for a public key.  Other than the items
-   described below, the resource records themselves introduce no
-   security considerations.  Please see [RFC4033] and [RFC4035] for
-   additional security considerations related to the use of these
-   records.
-
-   The DS record points to a DNSKEY RR by using a cryptographic digest,
-   the key algorithm type, and a key tag.  The DS record is intended to
-   identify an existing DNSKEY RR, but it is theoretically possible for
-   an attacker to generate a DNSKEY that matches all the DS fields.  The
-   probability of constructing a matching DNSKEY depends on the type of
-   digest algorithm in use.  The only currently defined digest algorithm
-   is SHA-1, and the working group believes that constructing a public
-   key that would match the algorithm, key tag, and SHA-1 digest given
-   in a DS record would be a sufficiently difficult problem that such an
-   attack is not a serious threat at this time.
-
-   The key tag is used to help select DNSKEY resource records
-   efficiently, but it does not uniquely identify a single DNSKEY
-   resource record.  It is possible for two distinct DNSKEY RRs to have
-   the same owner name, the same algorithm type, and the same key tag.
-   An implementation that uses only the key tag to select a DNSKEY RR
-   might select the wrong public key in some circumstances.  Please see
-   Appendix B for further details.
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 21]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-   The table of algorithms in Appendix A and the key tag calculation
-   algorithms in Appendix B include the RSA/MD5 algorithm for
-   completeness, but the RSA/MD5 algorithm is NOT RECOMMENDED, as
-   explained in [RFC3110].
-
-9.  Acknowledgements
-
-   This document was created from the input and ideas of the members of
-   the DNS Extensions Working Group and working group mailing list.  The
-   editors would like to express their thanks for the comments and
-   suggestions received during the revision of these security extension
-   specifications.  Although explicitly listing everyone who has
-   contributed during the decade in which DNSSEC has been under
-   development would be impossible, [RFC4033] includes a list of some of
-   the participants who were kind enough to comment on these documents.
-
-10.  References
-
-10.1.  Normative References
-
-   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
-              STD 13, RFC 1034, November 1987.
-
-   [RFC1035]  Mockapetris, P., "Domain names - implementation and
-              specification", STD 13, RFC 1035, November 1987.
-
-   [RFC1982]  Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
-              August 1996.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
-              Specification", RFC 2181, July 1997.
-
-   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
-              NCACHE)", RFC 2308, March 1998.
-
-   [RFC2536]  Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name
-              System (DNS)", RFC 2536, March 1999.
-
-   [RFC2931]  Eastlake 3rd, D., "DNS Request and Transaction Signatures
-              ( SIG(0)s )", RFC 2931, September 2000.
-
-   [RFC3110]  Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the
-              Domain Name System (DNS)", RFC 3110, May 2001.
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 22]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-   [RFC3445]  Massey, D. and S. Rose, "Limiting the Scope of the KEY
-              Resource Record (RR)", RFC 3445, December 2002.
-
-   [RFC3548]  Josefsson, S., "The Base16, Base32, and Base64 Data
-              Encodings", RFC 3548, July 2003.
-
-   [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
-              (RR) Types", RFC 3597, September 2003.
-
-   [RFC3658]  Gudmundsson, O., "Delegation Signer (DS) Resource Record
-              (RR)", RFC 3658, December 2003.
-
-   [RFC3755]  Weiler, S., "Legacy Resolver Compatibility for Delegation
-              Signer (DS)", RFC 3755, May 2004.
-
-   [RFC3757]  Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name
-              System KEY (DNSKEY) Resource Record (RR) Secure Entry
-              Point (SEP) Flag", RFC 3757, April 2004.
-
-   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "DNS Security Introduction and Requirements", RFC
-              4033, March 2005.
-
-   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Protocol Modifications for the DNS Security
-              Extensions", RFC 4035, March 2005.
-
-10.2.  Informative References
-
-   [RFC2535]  Eastlake 3rd, D., "Domain Name System Security
-              Extensions", RFC 2535, March 1999.
-
-   [RFC2537]  Eastlake 3rd, D., "RSA/MD5 KEYs and SIGs in the Domain
-              Name System (DNS)", RFC 2537, March 1999.
-
-   [RFC2539]  Eastlake 3rd, D., "Storage of Diffie-Hellman Keys in the
-              Domain Name System (DNS)", RFC 2539, March 1999.
-
-   [RFC2930]  Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
-              RR)", RFC 2930, September 2000.
-
-   [RFC3845]  Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC)
-              RDATA Format", RFC 3845, August 2004.
-
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 23]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-Appendix A.  DNSSEC Algorithm and Digest Types
-
-   The DNS security extensions are designed to be independent of the
-   underlying cryptographic algorithms.  The DNSKEY, RRSIG, and DS
-   resource records all use a DNSSEC Algorithm Number to identify the
-   cryptographic algorithm in use by the resource record.  The DS
-   resource record also specifies a Digest Algorithm Number to identify
-   the digest algorithm used to construct the DS record.  The currently
-   defined Algorithm and Digest Types are listed below.  Additional
-   Algorithm or Digest Types could be added as advances in cryptography
-   warrant them.
-
-   A DNSSEC aware resolver or name server MUST implement all MANDATORY
-   algorithms.
-
-A.1.  DNSSEC Algorithm Types
-
-   The DNSKEY, RRSIG, and DS RRs use an 8-bit number to identify the
-   security algorithm being used.  These values are stored in the
-   "Algorithm number" field in the resource record RDATA.
-
-   Some algorithms are usable only for zone signing (DNSSEC), some only
-   for transaction security mechanisms (SIG(0) and TSIG), and some for
-   both.  Those usable for zone signing may appear in DNSKEY, RRSIG, and
-   DS RRs.  Those usable for transaction security would be present in
-   SIG(0) and KEY RRs, as described in [RFC2931].
-
-                                Zone
-   Value Algorithm [Mnemonic]  Signing  References   Status
-   ----- -------------------- --------- ----------  ---------
-     0   reserved
-     1   RSA/MD5 [RSAMD5]         n      [RFC2537]  NOT RECOMMENDED
-     2   Diffie-Hellman [DH]      n      [RFC2539]   -
-     3   DSA/SHA-1 [DSA]          y      [RFC2536]  OPTIONAL
-     4   Elliptic Curve [ECC]              TBA       -
-     5   RSA/SHA-1 [RSASHA1]      y      [RFC3110]  MANDATORY
-   252   Indirect [INDIRECT]      n                  -
-   253   Private [PRIVATEDNS]     y      see below  OPTIONAL
-   254   Private [PRIVATEOID]     y      see below  OPTIONAL
-   255   reserved
-
-   6 - 251  Available for assignment by IETF Standards Action.
-
-
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 24]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-A.1.1.  Private Algorithm Types
-
-   Algorithm number 253 is reserved for private use and will never be
-   assigned to a specific algorithm.  The public key area in the DNSKEY
-   RR and the signature area in the RRSIG RR begin with a wire encoded
-   domain name, which MUST NOT be compressed.  The domain name indicates
-   the private algorithm to use, and the remainder of the public key
-   area is determined by that algorithm.  Entities should only use
-   domain names they control to designate their private algorithms.
-
-   Algorithm number 254 is reserved for private use and will never be
-   assigned to a specific algorithm.  The public key area in the DNSKEY
-   RR and the signature area in the RRSIG RR begin with an unsigned
-   length byte followed by a BER encoded Object Identifier (ISO OID) of
-   that length.  The OID indicates the private algorithm in use, and the
-   remainder of the area is whatever is required by that algorithm.
-   Entities should only use OIDs they control to designate their private
-   algorithms.
-
-A.2.  DNSSEC Digest Types
-
-   A "Digest Type" field in the DS resource record types identifies the
-   cryptographic digest algorithm used by the resource record.  The
-   following table lists the currently defined digest algorithm types.
-
-              VALUE   Algorithm                 STATUS
-                0      Reserved                   -
-                1      SHA-1                   MANDATORY
-              2-255    Unassigned                 -
-
-Appendix B.  Key Tag Calculation
-
-   The Key Tag field in the RRSIG and DS resource record types provides
-   a mechanism for selecting a public key efficiently.  In most cases, a
-   combination of owner name, algorithm, and key tag can efficiently
-   identify a DNSKEY record.  Both the RRSIG and DS resource records
-   have corresponding DNSKEY records.  The Key Tag field in the RRSIG
-   and DS records can be used to help select the corresponding DNSKEY RR
-   efficiently when more than one candidate DNSKEY RR is available.
-
-   However, it is essential to note that the key tag is not a unique
-   identifier.  It is theoretically possible for two distinct DNSKEY RRs
-   to have the same owner name, the same algorithm, and the same key
-   tag.  The key tag is used to limit the possible candidate keys, but
-   it does not uniquely identify a DNSKEY record.  Implementations MUST
-   NOT assume that the key tag uniquely identifies a DNSKEY RR.
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 25]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-   The key tag is the same for all DNSKEY algorithm types except
-   algorithm 1 (please see Appendix B.1 for the definition of the key
-   tag for algorithm 1).  The key tag algorithm is the sum of the wire
-   format of the DNSKEY RDATA broken into 2 octet groups.  First, the
-   RDATA (in wire format) is treated as a series of 2 octet groups.
-   These groups are then added together, ignoring any carry bits.
-
-   A reference implementation of the key tag algorithm is as an ANSI C
-   function is given below, with the RDATA portion of the DNSKEY RR is
-   used as input.  It is not necessary to use the following reference
-   code verbatim, but the numerical value of the Key Tag MUST be
-   identical to what the reference implementation would generate for the
-   same input.
-
-   Please note that the algorithm for calculating the Key Tag is almost
-   but not completely identical to the familiar ones-complement checksum
-   used in many other Internet protocols.  Key Tags MUST be calculated
-   using the algorithm described here rather than the ones complement
-   checksum.
-
-   The following ANSI C reference implementation calculates the value of
-   a Key Tag.  This reference implementation applies to all algorithm
-   types except algorithm 1 (see Appendix B.1).  The input is the wire
-   format of the RDATA portion of the DNSKEY RR.  The code is written
-   for clarity, not efficiency.
-
-   /*
-    * Assumes that int is at least 16 bits.
-    * First octet of the key tag is the most significant 8 bits of the
-    * return value;
-    * Second octet of the key tag is the least significant 8 bits of the
-    * return value.
-    */
-
-   unsigned int
-   keytag (
-           unsigned char key[],  /* the RDATA part of the DNSKEY RR */
-           unsigned int keysize  /* the RDLENGTH */
-          )
-   {
-           unsigned long ac;     /* assumed to be 32 bits or larger */
-           int i;                /* loop index */
-
-           for ( ac = 0, i = 0; i < keysize; ++i )
-                   ac += (i & 1) ? key[i] : key[i] << 8;
-           ac += (ac >> 16) & 0xFFFF;
-           return ac & 0xFFFF;
-   }
-
-
-
-Arends, et al.              Standards Track                    [Page 26]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-B.1.  Key Tag for Algorithm 1 (RSA/MD5)
-
-   The key tag for algorithm 1 (RSA/MD5) is defined differently from the
-   key tag for all other algorithms, for historical reasons.  For a
-   DNSKEY RR with algorithm 1, the key tag is defined to be the most
-   significant 16 bits of the least significant 24 bits in the public
-   key modulus (in other words, the 4th to last and 3rd to last octets
-   of the public key modulus).
-
-   Please note that Algorithm 1 is NOT RECOMMENDED.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 27]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-Authors' Addresses
-
-   Roy Arends
-   Telematica Instituut
-   Brouwerijstraat 1
-   7523 XC  Enschede
-   NL
-
-   EMail: roy.arends@telin.nl
-
-
-   Rob Austein
-   Internet Systems Consortium
-   950 Charter Street
-   Redwood City, CA  94063
-   USA
-
-   EMail: sra@isc.org
-
-
-   Matt Larson
-   VeriSign, Inc.
-   21345 Ridgetop Circle
-   Dulles, VA  20166-6503
-   USA
-
-   EMail: mlarson@verisign.com
-
-
-   Dan Massey
-   Colorado State University
-   Department of Computer Science
-   Fort Collins, CO 80523-1873
-
-   EMail: massey@cs.colostate.edu
-
-
-   Scott Rose
-   National Institute for Standards and Technology
-   100 Bureau Drive
-   Gaithersburg, MD  20899-8920
-   USA
-
-   EMail: scott.rose@nist.gov
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 28]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2005).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 29]
-
diff --git a/contrib/bind9/doc/rfc/rfc4035.txt b/contrib/bind9/doc/rfc/rfc4035.txt
deleted file mode 100644
index b701cd2..0000000
--- a/contrib/bind9/doc/rfc/rfc4035.txt
+++ /dev/null
@@ -1,2971 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          R. Arends
-Request for Comments: 4035                          Telematica Instituut
-Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658,                R. Austein
-           3755, 3757, 3845                                          ISC
-Updates: 1034, 1035, 2136, 2181, 2308, 3225,                   M. Larson
-         3007, 3597, 3226                                       VeriSign
-Category: Standards Track                                      D. Massey
-                                               Colorado State University
-                                                                 S. Rose
-                                                                    NIST
-                                                              March 2005
-
-
-         Protocol Modifications for the DNS Security Extensions
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document is part of a family of documents that describe the DNS
-   Security Extensions (DNSSEC).  The DNS Security Extensions are a
-   collection of new resource records and protocol modifications that
-   add data origin authentication and data integrity to the DNS.  This
-   document describes the DNSSEC protocol modifications.  This document
-   defines the concept of a signed zone, along with the requirements for
-   serving and resolving by using DNSSEC.  These techniques allow a
-   security-aware resolver to authenticate both DNS resource records and
-   authoritative DNS error indications.
-
-   This document obsoletes RFC 2535 and incorporates changes from all
-   updates to RFC 2535.
-
-
-
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                     [Page 1]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-       1.1.  Background and Related Documents . . . . . . . . . . . .  4
-       1.2.  Reserved Words . . . . . . . . . . . . . . . . . . . . .  4
-   2.  Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . .  4
-       2.1.  Including DNSKEY RRs in a Zone . . . . . . . . . . . . .  5
-       2.2.  Including RRSIG RRs in a Zone  . . . . . . . . . . . . .  5
-       2.3.  Including NSEC RRs in a Zone . . . . . . . . . . . . . .  6
-       2.4.  Including DS RRs in a Zone . . . . . . . . . . . . . . .  7
-       2.5.  Changes to the CNAME Resource Record.  . . . . . . . . .  7
-       2.6.  DNSSEC RR Types Appearing at Zone Cuts.  . . . . . . . .  8
-       2.7.  Example of a Secure Zone . . . . . . . . . . . . . . . .  8
-   3.  Serving  . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
-       3.1.  Authoritative Name Servers . . . . . . . . . . . . . . .  9
-             3.1.1.  Including RRSIG RRs in a Response  . . . . . . . 10
-             3.1.2.  Including DNSKEY RRs in a Response . . . . . . . 11
-             3.1.3.  Including NSEC RRs in a Response . . . . . . . . 11
-             3.1.4.  Including DS RRs in a Response . . . . . . . . . 14
-             3.1.5.  Responding to Queries for Type AXFR or IXFR  . . 15
-             3.1.6.  The AD and CD Bits in an Authoritative Response. 16
-       3.2.  Recursive Name Servers . . . . . . . . . . . . . . . . . 17
-             3.2.1.  The DO Bit . . . . . . . . . . . . . . . . . . . 17
-             3.2.2.  The CD Bit . . . . . . . . . . . . . . . . . . . 17
-             3.2.3.  The AD Bit . . . . . . . . . . . . . . . . . . . 18
-       3.3.  Example DNSSEC Responses . . . . . . . . . . . . . . . . 19
-   4.  Resolving  . . . . . . . . . . . . . . . . . . . . . . . . . . 19
-       4.1.  EDNS Support . . . . . . . . . . . . . . . . . . . . . . 19
-       4.2.  Signature Verification Support . . . . . . . . . . . . . 19
-       4.3.  Determining Security Status of Data  . . . . . . . . . . 20
-       4.4.  Configured Trust Anchors . . . . . . . . . . . . . . . . 21
-       4.5.  Response Caching . . . . . . . . . . . . . . . . . . . . 21
-       4.6.  Handling of the CD and AD Bits . . . . . . . . . . . . . 22
-       4.7.  Caching BAD Data . . . . . . . . . . . . . . . . . . . . 22
-       4.8.  Synthesized CNAMEs . . . . . . . . . . . . . . . . . . . 23
-       4.9.  Stub Resolvers . . . . . . . . . . . . . . . . . . . . . 23
-             4.9.1.  Handling of the DO Bit . . . . . . . . . . . . . 24
-             4.9.2.  Handling of the CD Bit . . . . . . . . . . . . . 24
-             4.9.3.  Handling of the AD Bit . . . . . . . . . . . . . 24
-   5.  Authenticating DNS Responses . . . . . . . . . . . . . . . . . 25
-       5.1.  Special Considerations for Islands of Security . . . . . 26
-       5.2.  Authenticating Referrals . . . . . . . . . . . . . . . . 26
-       5.3.  Authenticating an RRset with an RRSIG RR . . . . . . . . 28
-             5.3.1.  Checking the RRSIG RR Validity . . . . . . . . . 28
-             5.3.2.  Reconstructing the Signed Data . . . . . . . . . 29
-             5.3.3.  Checking the Signature . . . . . . . . . . . . . 31
-             5.3.4.  Authenticating a Wildcard Expanded RRset
-                     Positive Response. . . . . . . . . . . . . . . . 32
-
-
-
-Arends, et al.              Standards Track                     [Page 2]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-       5.4.  Authenticated Denial of Existence  . . . . . . . . . . . 32
-       5.5.  Resolver Behavior When Signatures Do Not Validate  . . . 33
-       5.6.  Authentication Example . . . . . . . . . . . . . . . . . 33
-   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 33
-   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 33
-   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
-   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
-       9.1.  Normative References . . . . . . . . . . . . . . . . . . 34
-       9.2.  Informative References . . . . . . . . . . . . . . . . . 35
-   A.  Signed Zone Example  . . . . . . . . . . . . . . . . . . . . . 36
-   B.  Example Responses  . . . . . . . . . . . . . . . . . . . . . . 41
-       B.1.  Answer . . . . . . . . . . . . . . . . . . . . . . . . . 41
-       B.2.  Name Error . . . . . . . . . . . . . . . . . . . . . . . 43
-       B.3.  No Data Error  . . . . . . . . . . . . . . . . . . . . . 44
-       B.4.  Referral to Signed Zone  . . . . . . . . . . . . . . . . 44
-       B.5.  Referral to Unsigned Zone  . . . . . . . . . . . . . . . 45
-       B.6.  Wildcard Expansion . . . . . . . . . . . . . . . . . . . 46
-       B.7.  Wildcard No Data Error . . . . . . . . . . . . . . . . . 47
-       B.8.  DS Child Zone No Data Error  . . . . . . . . . . . . . . 48
-   C.  Authentication Examples  . . . . . . . . . . . . . . . . . . . 49
-       C.1.  Authenticating an Answer . . . . . . . . . . . . . . . . 49
-             C.1.1.  Authenticating the Example DNSKEY RR . . . . . . 49
-       C.2.  Name Error . . . . . . . . . . . . . . . . . . . . . . . 50
-       C.3.  No Data Error  . . . . . . . . . . . . . . . . . . . . . 50
-       C.4.  Referral to Signed Zone  . . . . . . . . . . . . . . . . 50
-       C.5.  Referral to Unsigned Zone  . . . . . . . . . . . . . . . 51
-       C.6.  Wildcard Expansion . . . . . . . . . . . . . . . . . . . 51
-       C.7.  Wildcard No Data Error . . . . . . . . . . . . . . . . . 51
-       C.8.  DS Child Zone No Data Error  . . . . . . . . . . . . . . 51
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52
-   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 53
-
-1.  Introduction
-
-   The DNS Security Extensions (DNSSEC) are a collection of new resource
-   records and protocol modifications that add data origin
-   authentication and data integrity to the DNS.  This document defines
-   the DNSSEC protocol modifications.  Section 2 of this document
-   defines the concept of a signed zone and lists the requirements for
-   zone signing.  Section 3 describes the modifications to authoritative
-   name server behavior necessary for handling signed zones.  Section 4
-   describes the behavior of entities that include security-aware
-   resolver functions.  Finally, Section 5 defines how to use DNSSEC RRs
-   to authenticate a response.
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                     [Page 3]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-1.1.  Background and Related Documents
-
-   This document is part of a family of documents defining DNSSEC that
-   should be read together as a set.
-
-   [RFC4033] contains an introduction to DNSSEC and definitions of
-   common terms; the reader is assumed to be familiar with this
-   document.  [RFC4033] also contains a list of other documents updated
-   by and obsoleted by this document set.
-
-   [RFC4034] defines the DNSSEC resource records.
-
-   The reader is also assumed to be familiar with the basic DNS concepts
-   described in [RFC1034], [RFC1035], and the subsequent documents that
-   update them; particularly, [RFC2181] and [RFC2308].
-
-   This document defines the DNSSEC protocol operations.
-
-1.2.  Reserved Words
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-2.  Zone Signing
-
-   DNSSEC introduces the concept of signed zones.  A signed zone
-   includes DNS Public Key (DNSKEY), Resource Record Signature (RRSIG),
-   Next Secure (NSEC), and (optionally) Delegation Signer (DS) records
-   according to the rules specified in Sections 2.1, 2.2, 2.3, and 2.4,
-   respectively.  A zone that does not include these records according
-   to the rules in this section is an unsigned zone.
-
-   DNSSEC requires a change to the definition of the CNAME resource
-   record ([RFC1035]).  Section 2.5 changes the CNAME RR to allow RRSIG
-   and NSEC RRs to appear at the same owner name as does a CNAME RR.
-
-   DNSSEC specifies the placement of two new RR types, NSEC and DS,
-   which can be placed at the parental side of a zone cut (that is, at a
-   delegation point).  This is an exception to the general prohibition
-   against putting data in the parent zone at a zone cut.  Section 2.6
-   describes this change.
-
-
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                     [Page 4]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-2.1.  Including DNSKEY RRs in a Zone
-
-   To sign a zone, the zone's administrator generates one or more
-   public/private key pairs and uses the private key(s) to sign
-   authoritative RRsets in the zone.  For each private key used to
-   create RRSIG RRs in a zone, the zone SHOULD include a zone DNSKEY RR
-   containing the corresponding public key.  A zone key DNSKEY RR MUST
-   have the Zone Key bit of the flags RDATA field set (see Section 2.1.1
-   of [RFC4034]).  Public keys associated with other DNS operations MAY
-   be stored in DNSKEY RRs that are not marked as zone keys but MUST NOT
-   be used to verify RRSIGs.
-
-   If the zone administrator intends a signed zone to be usable other
-   than as an island of security, the zone apex MUST contain at least
-   one DNSKEY RR to act as a secure entry point into the zone.  This
-   secure entry point could then be used as the target of a secure
-   delegation via a corresponding DS RR in the parent zone (see
-   [RFC4034]).
-
-2.2.  Including RRSIG RRs in a Zone
-
-   For each authoritative RRset in a signed zone, there MUST be at least
-   one RRSIG record that meets the following requirements:
-
-   o  The RRSIG owner name is equal to the RRset owner name.
-
-   o  The RRSIG class is equal to the RRset class.
-
-   o  The RRSIG Type Covered field is equal to the RRset type.
-
-   o  The RRSIG Original TTL field is equal to the TTL of the RRset.
-
-   o  The RRSIG RR's TTL is equal to the TTL of the RRset.
-
-   o  The RRSIG Labels field is equal to the number of labels in the
-      RRset owner name, not counting the null root label and not
-      counting the leftmost label if it is a wildcard.
-
-   o  The RRSIG Signer's Name field is equal to the name of the zone
-      containing the RRset.
-
-   o  The RRSIG Algorithm, Signer's Name, and Key Tag fields identify a
-      zone key DNSKEY record at the zone apex.
-
-   The process for constructing the RRSIG RR for a given RRset is
-   described in [RFC4034].  An RRset MAY have multiple RRSIG RRs
-   associated with it.  Note that as RRSIG RRs are closely tied to the
-   RRsets whose signatures they contain, RRSIG RRs, unlike all other DNS
-
-
-
-Arends, et al.              Standards Track                     [Page 5]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   RR types, do not form RRsets.  In particular, the TTL values among
-   RRSIG RRs with a common owner name do not follow the RRset rules
-   described in [RFC2181].
-
-   An RRSIG RR itself MUST NOT be signed, as signing an RRSIG RR would
-   add no value and would create an infinite loop in the signing
-   process.
-
-   The NS RRset that appears at the zone apex name MUST be signed, but
-   the NS RRsets that appear at delegation points (that is, the NS
-   RRsets in the parent zone that delegate the name to the child zone's
-   name servers) MUST NOT be signed.  Glue address RRsets associated
-   with delegations MUST NOT be signed.
-
-   There MUST be an RRSIG for each RRset using at least one DNSKEY of
-   each algorithm in the zone apex DNSKEY RRset.  The apex DNSKEY RRset
-   itself MUST be signed by each algorithm appearing in the DS RRset
-   located at the delegating parent (if any).
-
-2.3.  Including NSEC RRs in a Zone
-
-   Each owner name in the zone that has authoritative data or a
-   delegation point NS RRset MUST have an NSEC resource record.  The
-   format of NSEC RRs and the process for constructing the NSEC RR for a
-   given name is described in [RFC4034].
-
-   The TTL value for any NSEC RR SHOULD be the same as the minimum TTL
-   value field in the zone SOA RR.
-
-   An NSEC record (and its associated RRSIG RRset) MUST NOT be the only
-   RRset at any particular owner name.  That is, the signing process
-   MUST NOT create NSEC or RRSIG RRs for owner name nodes that were not
-   the owner name of any RRset before the zone was signed.  The main
-   reasons for this are a desire for namespace consistency between
-   signed and unsigned versions of the same zone and a desire to reduce
-   the risk of response inconsistency in security oblivious recursive
-   name servers.
-
-   The type bitmap of every NSEC resource record in a signed zone MUST
-   indicate the presence of both the NSEC record itself and its
-   corresponding RRSIG record.
-
-   The difference between the set of owner names that require RRSIG
-   records and the set of owner names that require NSEC records is
-   subtle and worth highlighting.  RRSIG records are present at the
-   owner names of all authoritative RRsets.  NSEC records are present at
-   the owner names of all names for which the signed zone is
-   authoritative and also at the owner names of delegations from the
-
-
-
-Arends, et al.              Standards Track                     [Page 6]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   signed zone to its children.  Neither NSEC nor RRSIG records are
-   present (in the parent zone) at the owner names of glue address
-   RRsets.  Note, however, that this distinction is for the most part
-   visible only during the zone signing process, as NSEC RRsets are
-   authoritative data and are therefore signed.  Thus, any owner name
-   that has an NSEC RRset will have RRSIG RRs as well in the signed
-   zone.
-
-   The bitmap for the NSEC RR at a delegation point requires special
-   attention.  Bits corresponding to the delegation NS RRset and any
-   RRsets for which the parent zone has authoritative data MUST be set;
-   bits corresponding to any non-NS RRset for which the parent is not
-   authoritative MUST be clear.
-
-2.4.  Including DS RRs in a Zone
-
-   The DS resource record establishes authentication chains between DNS
-   zones.  A DS RRset SHOULD be present at a delegation point when the
-   child zone is signed.  The DS RRset MAY contain multiple records,
-   each referencing a public key in the child zone used to verify the
-   RRSIGs in that zone.  All DS RRsets in a zone MUST be signed, and DS
-   RRsets MUST NOT appear at a zone's apex.
-
-   A DS RR SHOULD point to a DNSKEY RR that is present in the child's
-   apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed
-   by the corresponding private key.  DS RRs that fail to meet these
-   conditions are not useful for validation, but because the DS RR and
-   its corresponding DNSKEY RR are in different zones, and because the
-   DNS is only loosely consistent, temporary mismatches can occur.
-
-   The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset
-   (that is, the NS RRset from the same zone containing the DS RRset).
-
-   Construction of a DS RR requires knowledge of the corresponding
-   DNSKEY RR in the child zone, which implies communication between the
-   child and parent zones.  This communication is an operational matter
-   not covered by this document.
-
-2.5.  Changes to the CNAME Resource Record
-
-   If a CNAME RRset is present at a name in a signed zone, appropriate
-   RRSIG and NSEC RRsets are REQUIRED at that name.  A KEY RRset at that
-   name for secure dynamic update purposes is also allowed ([RFC3007]).
-   Other types MUST NOT be present at that name.
-
-   This is a modification to the original CNAME definition given in
-   [RFC1034].  The original definition of the CNAME RR did not allow any
-   other types to coexist with a CNAME record, but a signed zone
-
-
-
-Arends, et al.              Standards Track                     [Page 7]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   requires NSEC and RRSIG RRs for every authoritative name.  To resolve
-   this conflict, this specification modifies the definition of the
-   CNAME resource record to allow it to coexist with NSEC and RRSIG RRs.
-
-2.6.  DNSSEC RR Types Appearing at Zone Cuts
-
-   DNSSEC introduced two new RR types that are unusual in that they can
-   appear at the parental side of a zone cut.  At the parental side of a
-   zone cut (that is, at a delegation point), NSEC RRs are REQUIRED at
-   the owner name.  A DS RR could also be present if the zone being
-   delegated is signed and seeks to have a chain of authentication to
-   the parent zone.  This is an exception to the original DNS
-   specification ([RFC1034]), which states that only NS RRsets could
-   appear at the parental side of a zone cut.
-
-   This specification updates the original DNS specification to allow
-   NSEC and DS RR types at the parent side of a zone cut.  These RRsets
-   are authoritative for the parent when they appear at the parent side
-   of a zone cut.
-
-2.7.  Example of a Secure Zone
-
-   Appendix A shows a complete example of a small signed zone.
-
-3.  Serving
-
-   This section describes the behavior of entities that include
-   security-aware name server functions.  In many cases such functions
-   will be part of a security-aware recursive name server, but a
-   security-aware authoritative name server has some of the same
-   requirements.  Functions specific to security-aware recursive name
-   servers are described in Section 3.2; functions specific to
-   authoritative servers are described in Section 3.1.
-
-   In the following discussion, the terms "SNAME", "SCLASS", and "STYPE"
-   are as used in [RFC1034].
-
-   A security-aware name server MUST support the EDNS0 ([RFC2671])
-   message size extension, MUST support a message size of at least 1220
-   octets, and SHOULD support a message size of 4000 octets.  As IPv6
-   packets can only be fragmented by the source host, a security aware
-   name server SHOULD take steps to ensure that UDP datagrams it
-   transmits over IPv6 are fragmented, if necessary, at the minimum IPv6
-   MTU, unless the path MTU is known.  Please see [RFC1122], [RFC2460],
-   and [RFC3226] for further discussion of packet size and fragmentation
-   issues.
-
-
-
-
-
-Arends, et al.              Standards Track                     [Page 8]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   A security-aware name server that receives a DNS query that does not
-   include the EDNS OPT pseudo-RR or that has the DO bit clear MUST
-   treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset and
-   MUST NOT perform any of the additional processing described below.
-   Because the DS RR type has the peculiar property of only existing in
-   the parent zone at delegation points, DS RRs always require some
-   special processing, as described in Section 3.1.4.1.
-
-   Security aware name servers that receive explicit queries for
-   security RR types that match the content of more than one zone that
-   it serves (for example, NSEC and RRSIG RRs above and below a
-   delegation point where the server is authoritative for both zones)
-   should behave self-consistently.  As long as the response is always
-   consistent for each query to the name server, the name server MAY
-   return one of the following:
-
-   o  The above-delegation RRsets.
-   o  The below-delegation RRsets.
-   o  Both above and below-delegation RRsets.
-   o  Empty answer section (no records).
-   o  Some other response.
-   o  An error.
-
-   DNSSEC allocates two new bits in the DNS message header: the CD
-   (Checking Disabled) bit and the AD (Authentic Data) bit.  The CD bit
-   is controlled by resolvers; a security-aware name server MUST copy
-   the CD bit from a query into the corresponding response.  The AD bit
-   is controlled by name servers; a security-aware name server MUST
-   ignore the setting of the AD bit in queries.  See Sections 3.1.6,
-   3.2.2, 3.2.3, 4, and 4.9 for details on the behavior of these bits.
-
-   A security aware name server that synthesizes CNAME RRs from DNAME
-   RRs as described in [RFC2672] SHOULD NOT generate signatures for the
-   synthesized CNAME RRs.
-
-3.1.  Authoritative Name Servers
-
-   Upon receiving a relevant query that has the EDNS ([RFC2671]) OPT
-   pseudo-RR DO bit ([RFC3225]) set, a security-aware authoritative name
-   server for a signed zone MUST include additional RRSIG, NSEC, and DS
-   RRs, according to the following rules:
-
-   o  RRSIG RRs that can be used to authenticate a response MUST be
-      included in the response according to the rules in Section 3.1.1.
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                     [Page 9]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   o  NSEC RRs that can be used to provide authenticated denial of
-      existence MUST be included in the response automatically according
-      to the rules in Section 3.1.3.
-
-   o  Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST
-      be included in referrals automatically according to the rules in
-      Section 3.1.4.
-
-   These rules only apply to responses where the semantics convey
-   information about the presence or absence of resource records.  That
-   is, these rules are not intended to rule out responses such as RCODE
-   4 ("Not Implemented") or RCODE 5 ("Refused").
-
-   DNSSEC does not change the DNS zone transfer protocol.  Section 3.1.5
-   discusses zone transfer requirements.
-
-3.1.1.  Including RRSIG RRs in a Response
-
-   When responding to a query that has the DO bit set, a security-aware
-   authoritative name server SHOULD attempt to send RRSIG RRs that a
-   security-aware resolver can use to authenticate the RRsets in the
-   response.  A name server SHOULD make every attempt to keep the RRset
-   and its associated RRSIG(s) together in a response.  Inclusion of
-   RRSIG RRs in a response is subject to the following rules:
-
-   o  When placing a signed RRset in the Answer section, the name server
-      MUST also place its RRSIG RRs in the Answer section.  The RRSIG
-      RRs have a higher priority for inclusion than any other RRsets
-      that may have to be included.  If space does not permit inclusion
-      of these RRSIG RRs, the name server MUST set the TC bit.
-
-   o  When placing a signed RRset in the Authority section, the name
-      server MUST also place its RRSIG RRs in the Authority section.
-      The RRSIG RRs have a higher priority for inclusion than any other
-      RRsets that may have to be included.  If space does not permit
-      inclusion of these RRSIG RRs, the name server MUST set the TC bit.
-
-   o  When placing a signed RRset in the Additional section, the name
-      server MUST also place its RRSIG RRs in the Additional section.
-      If space does not permit inclusion of both the RRset and its
-      associated RRSIG RRs, the name server MAY retain the RRset while
-      dropping the RRSIG RRs.  If this happens, the name server MUST NOT
-      set the TC bit solely because these RRSIG RRs didn't fit.
-
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 10]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-3.1.2.  Including DNSKEY RRs in a Response
-
-   When responding to a query that has the DO bit set and that requests
-   the SOA or NS RRs at the apex of a signed zone, a security-aware
-   authoritative name server for that zone MAY return the zone apex
-   DNSKEY RRset in the Additional section.  In this situation, the
-   DNSKEY RRset and associated RRSIG RRs have lower priority than does
-   any other information that would be placed in the additional section.
-   The name server SHOULD NOT include the DNSKEY RRset unless there is
-   enough space in the response message for both the DNSKEY RRset and
-   its associated RRSIG RR(s).  If there is not enough space to include
-   these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST
-   NOT set the TC bit solely because these RRs didn't fit (see Section
-   3.1.1).
-
-3.1.3.  Including NSEC RRs in a Response
-
-   When responding to a query that has the DO bit set, a security-aware
-   authoritative name server for a signed zone MUST include NSEC RRs in
-   each of the following cases:
-
-   No Data: The zone contains RRsets that exactly match <SNAME, SCLASS>
-      but does not contain any RRsets that exactly match <SNAME, SCLASS,
-      STYPE>.
-
-   Name Error: The zone does not contain any RRsets that match <SNAME,
-      SCLASS> either exactly or via wildcard name expansion.
-
-   Wildcard Answer: The zone does not contain any RRsets that exactly
-      match <SNAME, SCLASS> but does contain an RRset that matches
-      <SNAME, SCLASS, STYPE> via wildcard name expansion.
-
-   Wildcard No Data: The zone does not contain any RRsets that exactly
-      match <SNAME, SCLASS> and does contain one or more RRsets that
-      match <SNAME, SCLASS> via wildcard name expansion, but does not
-      contain any RRsets that match <SNAME, SCLASS, STYPE> via wildcard
-      name expansion.
-
-   In each of these cases, the name server includes NSEC RRs in the
-   response to prove that an exact match for <SNAME, SCLASS, STYPE> was
-   not present in the zone and that the response that the name server is
-   returning is correct given the data in the zone.
-
-
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 11]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-3.1.3.1.  Including NSEC RRs: No Data Response
-
-   If the zone contains RRsets matching <SNAME, SCLASS> but contains no
-   RRset matching <SNAME, SCLASS, STYPE>, then the name server MUST
-   include the NSEC RR for <SNAME, SCLASS> along with its associated
-   RRSIG RR(s) in the Authority section of the response (see Section
-   3.1.1).  If space does not permit inclusion of the NSEC RR or its
-   associated RRSIG RR(s), the name server MUST set the TC bit (see
-   Section 3.1.1).
-
-   Since the search name exists, wildcard name expansion does not apply
-   to this query, and a single signed NSEC RR suffices to prove that the
-   requested RR type does not exist.
-
-3.1.3.2.  Including NSEC RRs: Name Error Response
-
-   If the zone does not contain any RRsets matching <SNAME, SCLASS>
-   either exactly or via wildcard name expansion, then the name server
-   MUST include the following NSEC RRs in the Authority section, along
-   with their associated RRSIG RRs:
-
-   o  An NSEC RR proving that there is no exact match for <SNAME,
-      SCLASS>.
-
-   o  An NSEC RR proving that the zone contains no RRsets that would
-      match <SNAME, SCLASS> via wildcard name expansion.
-
-   In some cases, a single NSEC RR may prove both of these points.  If
-   it does, the name server SHOULD only include the NSEC RR and its
-   RRSIG RR(s) once in the Authority section.
-
-   If space does not permit inclusion of these NSEC and RRSIG RRs, the
-   name server MUST set the TC bit (see Section 3.1.1).
-
-   The owner names of these NSEC and RRSIG RRs are not subject to
-   wildcard name expansion when these RRs are included in the Authority
-   section of the response.
-
-   Note that this form of response includes cases in which SNAME
-   corresponds to an empty non-terminal name within the zone (a name
-   that is not the owner name for any RRset but that is the parent name
-   of one or more RRsets).
-
-3.1.3.3.  Including NSEC RRs: Wildcard Answer Response
-
-   If the zone does not contain any RRsets that exactly match <SNAME,
-   SCLASS> but does contain an RRset that matches <SNAME, SCLASS, STYPE>
-   via wildcard name expansion, the name server MUST include the
-
-
-
-Arends, et al.              Standards Track                    [Page 12]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   wildcard-expanded answer and the corresponding wildcard-expanded
-   RRSIG RRs in the Answer section and MUST include in the Authority
-   section an NSEC RR and associated RRSIG RR(s) proving that the zone
-   does not contain a closer match for <SNAME, SCLASS>.  If space does
-   not permit inclusion of the answer, NSEC and RRSIG RRs, the name
-   server MUST set the TC bit (see Section 3.1.1).
-
-3.1.3.4.  Including NSEC RRs: Wildcard No Data Response
-
-   This case is a combination of the previous cases.  The zone does not
-   contain an exact match for <SNAME, SCLASS>, and although the zone
-   does contain RRsets that match <SNAME, SCLASS> via wildcard
-   expansion, none of those RRsets matches STYPE.  The name server MUST
-   include the following NSEC RRs in the Authority section, along with
-   their associated RRSIG RRs:
-
-   o  An NSEC RR proving that there are no RRsets matching STYPE at the
-      wildcard owner name that matched <SNAME, SCLASS> via wildcard
-      expansion.
-
-   o  An NSEC RR proving that there are no RRsets in the zone that would
-      have been a closer match for <SNAME, SCLASS>.
-
-   In some cases, a single NSEC RR may prove both of these points.  If
-   it does, the name server SHOULD only include the NSEC RR and its
-   RRSIG RR(s) once in the Authority section.
-
-   The owner names of these NSEC and RRSIG RRs are not subject to
-   wildcard name expansion when these RRs are included in the Authority
-   section of the response.
-
-   If space does not permit inclusion of these NSEC and RRSIG RRs, the
-   name server MUST set the TC bit (see Section 3.1.1).
-
-3.1.3.5.  Finding the Right NSEC RRs
-
-   As explained above, there are several situations in which a
-   security-aware authoritative name server has to locate an NSEC RR
-   that proves that no RRsets matching a particular SNAME exist.
-   Locating such an NSEC RR within an authoritative zone is relatively
-   simple, at least in concept.  The following discussion assumes that
-   the name server is authoritative for the zone that would have held
-   the non-existent RRsets matching SNAME.  The algorithm below is
-   written for clarity, not for efficiency.
-
-   To find the NSEC that proves that no RRsets matching name N exist in
-   the zone Z that would have held them, construct a sequence, S,
-   consisting of the owner names of every RRset in Z, sorted into
-
-
-
-Arends, et al.              Standards Track                    [Page 13]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   canonical order ([RFC4034]), with no duplicate names.  Find the name
-   M that would have immediately preceded N in S if any RRsets with
-   owner name N had existed.  M is the owner name of the NSEC RR that
-   proves that no RRsets exist with owner name N.
-
-   The algorithm for finding the NSEC RR that proves that a given name
-   is not covered by any applicable wildcard is similar but requires an
-   extra step.  More precisely, the algorithm for finding the NSEC
-   proving that no RRsets exist with the applicable wildcard name is
-   precisely the same as the algorithm for finding the NSEC RR that
-   proves that RRsets with any other owner name do not exist.  The part
-   that's missing is a method of determining the name of the non-
-   existent applicable wildcard.  In practice, this is easy, because the
-   authoritative name server has already checked for the presence of
-   precisely this wildcard name as part of step (1)(c) of the normal
-   lookup algorithm described in Section 4.3.2 of [RFC1034].
-
-3.1.4.  Including DS RRs in a Response
-
-   When responding to a query that has the DO bit set, a security-aware
-   authoritative name server returning a referral includes DNSSEC data
-   along with the NS RRset.
-
-   If a DS RRset is present at the delegation point, the name server
-   MUST return both the DS RRset and its associated RRSIG RR(s) in the
-   Authority section along with the NS RRset.
-
-   If no DS RRset is present at the delegation point, the name server
-   MUST return both the NSEC RR that proves that the DS RRset is not
-   present and the NSEC RR's associated RRSIG RR(s) along with the NS
-   RRset.  The name server MUST place the NS RRset before the NSEC RRset
-   and its associated RRSIG RR(s).
-
-   Including these DS, NSEC, and RRSIG RRs increases the size of
-   referral messages and may cause some or all glue RRs to be omitted.
-   If space does not permit inclusion of the DS or NSEC RRset and
-   associated RRSIG RRs, the name server MUST set the TC bit (see
-   Section 3.1.1).
-
-3.1.4.1.  Responding to Queries for DS RRs
-
-   The DS resource record type is unusual in that it appears only on the
-   parent zone's side of a zone cut.  For example, the DS RRset for the
-   delegation of "foo.example" is stored in the "example" zone rather
-   than in the "foo.example" zone.  This requires special processing
-   rules for both name servers and resolvers, as the name server for the
-   child zone is authoritative for the name at the zone cut by the
-   normal DNS rules but the child zone does not contain the DS RRset.
-
-
-
-Arends, et al.              Standards Track                    [Page 14]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   A security-aware resolver sends queries to the parent zone when
-   looking for a needed DS RR at a delegation point (see Section 4.2).
-   However, special rules are necessary to avoid confusing
-   security-oblivious resolvers which might become involved in
-   processing such a query (for example, in a network configuration that
-   forces a security-aware resolver to channel its queries through a
-   security-oblivious recursive name server).  The rest of this section
-   describes how a security-aware name server processes DS queries in
-   order to avoid this problem.
-
-   The need for special processing by a security-aware name server only
-   arises when all the following conditions are met:
-
-   o  The name server has received a query for the DS RRset at a zone
-      cut.
-
-   o  The name server is authoritative for the child zone.
-
-   o  The name server is not authoritative for the parent zone.
-
-   o  The name server does not offer recursion.
-
-   In all other cases, the name server either has some way of obtaining
-   the DS RRset or could not have been expected to have the DS RRset
-   even by the pre-DNSSEC processing rules, so the name server can
-   return either the DS RRset or an error response according to the
-   normal processing rules.
-
-   If all the above conditions are met, however, the name server is
-   authoritative for SNAME but cannot supply the requested RRset.  In
-   this case, the name server MUST return an authoritative "no data"
-   response showing that the DS RRset does not exist in the child zone's
-   apex.  See Appendix B.8 for an example of such a response.
-
-3.1.5.  Responding to Queries for Type AXFR or IXFR
-
-   DNSSEC does not change the DNS zone transfer process.  A signed zone
-   will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these
-   records have no special meaning with respect to a zone transfer
-   operation.
-
-   An authoritative name server is not required to verify that a zone is
-   properly signed before sending or accepting a zone transfer.
-   However, an authoritative name server MAY choose to reject the entire
-   zone transfer if the zone fails to meet any of the signing
-   requirements described in Section 2.  The primary objective of a zone
-   transfer is to ensure that all authoritative name servers have
-   identical copies of the zone.  An authoritative name server that
-
-
-
-Arends, et al.              Standards Track                    [Page 15]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   chooses to perform its own zone validation MUST NOT selectively
-   reject some RRs and accept others.
-
-   DS RRsets appear only on the parental side of a zone cut and are
-   authoritative data in the parent zone.  As with any other
-   authoritative RRset, the DS RRset MUST be included in zone transfers
-   of the zone in which the RRset is authoritative data.  In the case of
-   the DS RRset, this is the parent zone.
-
-   NSEC RRs appear in both the parent and child zones at a zone cut and
-   are authoritative data in both the parent and child zones.  The
-   parental and child NSEC RRs at a zone cut are never identical to each
-   other, as the NSEC RR in the child zone's apex will always indicate
-   the presence of the child zone's SOA RR whereas the parental NSEC RR
-   at the zone cut will never indicate the presence of an SOA RR.  As
-   with any other authoritative RRs, NSEC RRs MUST be included in zone
-   transfers of the zone in which they are authoritative data.  The
-   parental NSEC RR at a zone cut MUST be included in zone transfers of
-   the parent zone, and the NSEC at the zone apex of the child zone MUST
-   be included in zone transfers of the child zone.
-
-   RRSIG RRs appear in both the parent and child zones at a zone cut and
-   are authoritative in whichever zone contains the authoritative RRset
-   for which the RRSIG RR provides the signature.  That is, the RRSIG RR
-   for a DS RRset or a parental NSEC RR at a zone cut will be
-   authoritative in the parent zone, and the RRSIG for any RRset in the
-   child zone's apex will be authoritative in the child zone.  Parental
-   and child RRSIG RRs at a zone cut will never be identical to each
-   other, as the Signer's Name field of an RRSIG RR in the child zone's
-   apex will indicate a DNSKEY RR in the child zone's apex whereas the
-   same field of a parental RRSIG RR at the zone cut will indicate a
-   DNSKEY RR in the parent zone's apex.  As with any other authoritative
-   RRs, RRSIG RRs MUST be included in zone transfers of the zone in
-   which they are authoritative data.
-
-3.1.6.  The AD and CD Bits in an Authoritative Response
-
-   The CD and AD bits are designed for use in communication between
-   security-aware resolvers and security-aware recursive name servers.
-   These bits are for the most part not relevant to query processing by
-   security-aware authoritative name servers.
-
-   A security-aware name server does not perform signature validation
-   for authoritative data during query processing, even when the CD bit
-   is clear.  A security-aware name server SHOULD clear the CD bit when
-   composing an authoritative response.
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 16]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   A security-aware name server MUST NOT set the AD bit in a response
-   unless the name server considers all RRsets in the Answer and
-   Authority sections of the response to be authentic.  A security-aware
-   name server's local policy MAY consider data from an authoritative
-   zone to be authentic without further validation.  However, the name
-   server MUST NOT do so unless the name server obtained the
-   authoritative zone via secure means (such as a secure zone transfer
-   mechanism) and MUST NOT do so unless this behavior has been
-   configured explicitly.
-
-   A security-aware name server that supports recursion MUST follow the
-   rules for the CD and AD bits given in Section 3.2 when generating a
-   response that involves data obtained via recursion.
-
-3.2.  Recursive Name Servers
-
-   As explained in [RFC4033], a security-aware recursive name server is
-   an entity that acts in both the security-aware name server and
-   security-aware resolver roles.  This section uses the terms "name
-   server side" and "resolver side" to refer to the code within a
-   security-aware recursive name server that implements the
-   security-aware name server role and the code that implements the
-   security-aware resolver role, respectively.
-
-   The resolver side follows the usual rules for caching and negative
-   caching that would apply to any security-aware resolver.
-
-3.2.1.  The DO Bit
-
-   The resolver side of a security-aware recursive name server MUST set
-   the DO bit when sending requests, regardless of the state of the DO
-   bit in the initiating request received by the name server side.  If
-   the DO bit in an initiating query is not set, the name server side
-   MUST strip any authenticating DNSSEC RRs from the response but MUST
-   NOT strip any DNSSEC RR types that the initiating query explicitly
-   requested.
-
-3.2.2.  The CD Bit
-
-   The CD bit exists in order to allow a security-aware resolver to
-   disable signature validation in a security-aware name server's
-   processing of a particular query.
-
-   The name server side MUST copy the setting of the CD bit from a query
-   to the corresponding response.
-
-   The name server side of a security-aware recursive name server MUST
-   pass the state of the CD bit to the resolver side along with the rest
-
-
-
-Arends, et al.              Standards Track                    [Page 17]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   of an initiating query, so that the resolver side will know whether
-   it is required to verify the response data it returns to the name
-   server side.  If the CD bit is set, it indicates that the originating
-   resolver is willing to perform whatever authentication its local
-   policy requires.  Thus, the resolver side of the recursive name
-   server need not perform authentication on the RRsets in the response.
-   When the CD bit is set, the recursive name server SHOULD, if
-   possible, return the requested data to the originating resolver, even
-   if the recursive name server's local authentication policy would
-   reject the records in question.  That is, by setting the CD bit, the
-   originating resolver has indicated that it takes responsibility for
-   performing its own authentication, and the recursive name server
-   should not interfere.
-
-   If the resolver side implements a BAD cache (see Section 4.7) and the
-   name server side receives a query that matches an entry in the
-   resolver side's BAD cache, the name server side's response depends on
-   the state of the CD bit in the original query.  If the CD bit is set,
-   the name server side SHOULD return the data from the BAD cache; if
-   the CD bit is not set, the name server side MUST return RCODE 2
-   (server failure).
-
-   The intent of the above rule is to provide the raw data to clients
-   that are capable of performing their own signature verification
-   checks while protecting clients that depend on the resolver side of a
-   security-aware recursive name server to perform such checks.  Several
-   of the possible reasons why signature validation might fail involve
-   conditions that may not apply equally to the recursive name server
-   and the client that invoked it.  For example, the recursive name
-   server's clock may be set incorrectly, or the client may have
-   knowledge of a relevant island of security that the recursive name
-   server does not share.  In such cases, "protecting" a client that is
-   capable of performing its own signature validation from ever seeing
-   the "bad" data does not help the client.
-
-3.2.3.  The AD Bit
-
-   The name server side of a security-aware recursive name server MUST
-   NOT set the AD bit in a response unless the name server considers all
-   RRsets in the Answer and Authority sections of the response to be
-   authentic.  The name server side SHOULD set the AD bit if and only if
-   the resolver side considers all RRsets in the Answer section and any
-   relevant negative response RRs in the Authority section to be
-   authentic.  The resolver side MUST follow the procedure described in
-   Section 5 to determine whether the RRs in question are authentic.
-   However, for backward compatibility, a recursive name server MAY set
-   the AD bit when a response includes unsigned CNAME RRs if those CNAME
-
-
-
-
-Arends, et al.              Standards Track                    [Page 18]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   RRs demonstrably could have been synthesized from an authentic DNAME
-   RR that is also included in the response according to the synthesis
-   rules described in [RFC2672].
-
-3.3.  Example DNSSEC Responses
-
-   See Appendix B for example response packets.
-
-4.  Resolving
-
-   This section describes the behavior of entities that include
-   security-aware resolver functions.  In many cases such functions will
-   be part of a security-aware recursive name server, but a stand-alone
-   security-aware resolver has many of the same requirements.  Functions
-   specific to security-aware recursive name servers are described in
-   Section 3.2.
-
-4.1.  EDNS Support
-
-   A security-aware resolver MUST include an EDNS ([RFC2671]) OPT
-   pseudo-RR with the DO ([RFC3225]) bit set when sending queries.
-
-   A security-aware resolver MUST support a message size of at least
-   1220 octets, SHOULD support a message size of 4000 octets, and MUST
-   use the "sender's UDP payload size" field in the EDNS OPT pseudo-RR
-   to advertise the message size that it is willing to accept.  A
-   security-aware resolver's IP layer MUST handle fragmented UDP packets
-   correctly regardless of whether any such fragmented packets were
-   received via IPv4 or IPv6.  Please see [RFC1122], [RFC2460], and
-   [RFC3226] for discussion of these requirements.
-
-4.2.  Signature Verification Support
-
-   A security-aware resolver MUST support the signature verification
-   mechanisms described in Section 5 and SHOULD apply them to every
-   received response, except when:
-
-   o  the security-aware resolver is part of a security-aware recursive
-      name server, and the response is the result of recursion on behalf
-      of a query received with the CD bit set;
-
-   o  the response is the result of a query generated directly via some
-      form of application interface that instructed the security-aware
-      resolver not to perform validation for this query; or
-
-   o  validation for this query has been disabled by local policy.
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 19]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   A security-aware resolver's support for signature verification MUST
-   include support for verification of wildcard owner names.
-
-   Security-aware resolvers MAY query for missing security RRs in an
-   attempt to perform validation; implementations that choose to do so
-   must be aware that the answers received may not be sufficient to
-   validate the original response.  For example, a zone update may have
-   changed (or deleted) the desired information between the original and
-   follow-up queries.
-
-   When attempting to retrieve missing NSEC RRs that reside on the
-   parental side at a zone cut, a security-aware iterative-mode resolver
-   MUST query the name servers for the parent zone, not the child zone.
-
-   When attempting to retrieve a missing DS, a security-aware
-   iterative-mode resolver MUST query the name servers for the parent
-   zone, not the child zone.  As explained in Section 3.1.4.1,
-   security-aware name servers need to apply special processing rules to
-   handle the DS RR, and in some situations the resolver may also need
-   to apply special rules to locate the name servers for the parent zone
-   if the resolver does not already have the parent's NS RRset.  To
-   locate the parent NS RRset, the resolver can start with the
-   delegation name, strip off the leftmost label, and query for an NS
-   RRset by that name.  If no NS RRset is present at that name, the
-   resolver then strips off the leftmost remaining label and retries the
-   query for that name, repeating this process of walking up the tree
-   until it either finds the NS RRset or runs out of labels.
-
-4.3.  Determining Security Status of Data
-
-   A security-aware resolver MUST be able to determine whether it should
-   expect a particular RRset to be signed.  More precisely, a
-   security-aware resolver must be able to distinguish between four
-   cases:
-
-   Secure: An RRset for which the resolver is able to build a chain of
-      signed DNSKEY and DS RRs from a trusted security anchor to the
-      RRset.  In this case, the RRset should be signed and is subject to
-      signature validation, as described above.
-
-   Insecure: An RRset for which the resolver knows that it has no chain
-      of signed DNSKEY and DS RRs from any trusted starting point to the
-      RRset.  This can occur when the target RRset lies in an unsigned
-      zone or in a descendent of an unsigned zone.  In this case, the
-      RRset may or may not be signed, but the resolver will not be able
-      to verify the signature.
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 20]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   Bogus: An RRset for which the resolver believes that it ought to be
-      able to establish a chain of trust but for which it is unable to
-      do so, either due to signatures that for some reason fail to
-      validate or due to missing data that the relevant DNSSEC RRs
-      indicate should be present.  This case may indicate an attack but
-      may also indicate a configuration error or some form of data
-      corruption.
-
-   Indeterminate: An RRset for which the resolver is not able to
-      determine whether the RRset should be signed, as the resolver is
-      not able to obtain the necessary DNSSEC RRs.  This can occur when
-      the security-aware resolver is not able to contact security-aware
-      name servers for the relevant zones.
-
-4.4.  Configured Trust Anchors
-
-   A security-aware resolver MUST be capable of being configured with at
-   least one trusted public key or DS RR and SHOULD be capable of being
-   configured with multiple trusted public keys or DS RRs.  Since a
-   security-aware resolver will not be able to validate signatures
-   without such a configured trust anchor, the resolver SHOULD have some
-   reasonably robust mechanism for obtaining such keys when it boots;
-   examples of such a mechanism would be some form of non-volatile
-   storage (such as a disk drive) or some form of trusted local network
-   configuration mechanism.
-
-   Note that trust anchors also cover key material that is updated in a
-   secure manner.  This secure manner could be through physical media, a
-   key exchange protocol, or some other out-of-band means.
-
-4.5.  Response Caching
-
-   A security-aware resolver SHOULD cache each response as a single
-   atomic entry containing the entire answer, including the named RRset
-   and any associated DNSSEC RRs.  The resolver SHOULD discard the
-   entire atomic entry when any of the RRs contained in it expire.  In
-   most cases the appropriate cache index for the atomic entry will be
-   the triple <QNAME, QTYPE, QCLASS>, but in cases such as the response
-   form described in Section 3.1.3.2 the appropriate cache index will be
-   the double <QNAME,QCLASS>.
-
-   The reason for these recommendations is that, between the initial
-   query and the expiration of the data from the cache, the
-   authoritative data might have been changed (for example, via dynamic
-   update).
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 21]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   There are two situations for which this is relevant:
-
-   1.  By using the RRSIG record, it is possible to deduce that an
-       answer was synthesized from a wildcard.  A security-aware
-       recursive name server could store this wildcard data and use it
-       to generate positive responses to queries other than the name for
-       which the original answer was first received.
-
-   2.  NSEC RRs received to prove the non-existence of a name could be
-       reused by a security-aware resolver to prove the non-existence of
-       any name in the name range it spans.
-
-   In theory, a resolver could use wildcards or NSEC RRs to generate
-   positive and negative responses (respectively) until the TTL or
-   signatures on the records in question expire.  However, it seems
-   prudent for resolvers to avoid blocking new authoritative data or
-   synthesizing new data on their own.  Resolvers that follow this
-   recommendation will have a more consistent view of the namespace.
-
-4.6.  Handling of the CD and AD Bits
-
-   A security-aware resolver MAY set a query's CD bit in order to
-   indicate that the resolver takes responsibility for performing
-   whatever authentication its local policy requires on the RRsets in
-   the response.  See Section 3.2 for the effect this bit has on the
-   behavior of security-aware recursive name servers.
-
-   A security-aware resolver MUST clear the AD bit when composing query
-   messages to protect against buggy name servers that blindly copy
-   header bits that they do not understand from the query message to the
-   response message.
-
-   A resolver MUST disregard the meaning of the CD and AD bits in a
-   response unless the response was obtained by using a secure channel
-   or the resolver was specifically configured to regard the message
-   header bits without using a secure channel.
-
-4.7.  Caching BAD Data
-
-   While many validation errors will be transient, some are likely to be
-   more persistent, such as those caused by administrative error
-   (failure to re-sign a zone, clock skew, and so forth).  Since
-   requerying will not help in these cases, validating resolvers might
-   generate a significant amount of unnecessary DNS traffic as a result
-   of repeated queries for RRsets with persistent validation failures.
-
-   To prevent such unnecessary DNS traffic, security-aware resolvers MAY
-   cache data with invalid signatures, with some restrictions.
-
-
-
-Arends, et al.              Standards Track                    [Page 22]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   Conceptually, caching such data is similar to negative caching
-   ([RFC2308]), except that instead of caching a valid negative
-   response, the resolver is caching the fact that a particular answer
-   failed to validate.  This document refers to a cache of data with
-   invalid signatures as a "BAD cache".
-
-   Resolvers that implement a BAD cache MUST take steps to prevent the
-   cache from being useful as a denial-of-service attack amplifier,
-   particularly the following:
-
-   o  Since RRsets that fail to validate do not have trustworthy TTLs,
-      the implementation MUST assign a TTL.  This TTL SHOULD be small,
-      in order to mitigate the effect of caching the results of an
-      attack.
-
-   o  In order to prevent caching of a transient validation failure
-      (which might be the result of an attack), resolvers SHOULD track
-      queries that result in validation failures and SHOULD only answer
-      from the BAD cache after the number of times that responses to
-      queries for that particular <QNAME, QTYPE, QCLASS> have failed to
-      validate exceeds a threshold value.
-
-   Resolvers MUST NOT return RRsets from the BAD cache unless the
-   resolver is not required to validate the signatures of the RRsets in
-   question under the rules given in Section 4.2 of this document.  See
-   Section 3.2.2 for discussion of how the responses returned by a
-   security-aware recursive name server interact with a BAD cache.
-
-4.8.  Synthesized CNAMEs
-
-   A validating security-aware resolver MUST treat the signature of a
-   valid signed DNAME RR as also covering unsigned CNAME RRs that could
-   have been synthesized from the DNAME RR, as described in [RFC2672],
-   at least to the extent of not rejecting a response message solely
-   because it contains such CNAME RRs.  The resolver MAY retain such
-   CNAME RRs in its cache or in the answers it hands back, but is not
-   required to do so.
-
-4.9.  Stub Resolvers
-
-   A security-aware stub resolver MUST support the DNSSEC RR types, at
-   least to the extent of not mishandling responses just because they
-   contain DNSSEC RRs.
-
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 23]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-4.9.1.  Handling of the DO Bit
-
-   A non-validating security-aware stub resolver MAY include the DNSSEC
-   RRs returned by a security-aware recursive name server as part of the
-   data that the stub resolver hands back to the application that
-   invoked it, but is not required to do so.  A non-validating stub
-   resolver that seeks to do this will need to set the DO bit in order
-   to receive DNSSEC RRs from the recursive name server.
-
-   A validating security-aware stub resolver MUST set the DO bit,
-   because otherwise it will not receive the DNSSEC RRs it needs to
-   perform signature validation.
-
-4.9.2.  Handling of the CD Bit
-
-   A non-validating security-aware stub resolver SHOULD NOT set the CD
-   bit when sending queries unless it is requested by the application
-   layer, as by definition, a non-validating stub resolver depends on
-   the security-aware recursive name server to perform validation on its
-   behalf.
-
-   A validating security-aware stub resolver SHOULD set the CD bit,
-   because otherwise the security-aware recursive name server will
-   answer the query using the name server's local policy, which may
-   prevent the stub resolver from receiving data that would be
-   acceptable to the stub resolver's local policy.
-
-4.9.3.  Handling of the AD Bit
-
-   A non-validating security-aware stub resolver MAY chose to examine
-   the setting of the AD bit in response messages that it receives in
-   order to determine whether the security-aware recursive name server
-   that sent the response claims to have cryptographically verified the
-   data in the Answer and Authority sections of the response message.
-   Note, however, that the responses received by a security-aware stub
-   resolver are heavily dependent on the local policy of the
-   security-aware recursive name server.  Therefore, there may be little
-   practical value in checking the status of the AD bit, except perhaps
-   as a debugging aid.  In any case, a security-aware stub resolver MUST
-   NOT place any reliance on signature validation allegedly performed on
-   its behalf, except when the security-aware stub resolver obtained the
-   data in question from a trusted security-aware recursive name server
-   via a secure channel.
-
-   A validating security-aware stub resolver SHOULD NOT examine the
-   setting of the AD bit in response messages, as, by definition, the
-   stub resolver performs its own signature validation regardless of the
-   setting of the AD bit.
-
-
-
-Arends, et al.              Standards Track                    [Page 24]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-5.  Authenticating DNS Responses
-
-   To use DNSSEC RRs for authentication, a security-aware resolver
-   requires configured knowledge of at least one authenticated DNSKEY or
-   DS RR.  The process for obtaining and authenticating this initial
-   trust anchor is achieved via some external mechanism.  For example, a
-   resolver could use some off-line authenticated exchange to obtain a
-   zone's DNSKEY RR or to obtain a DS RR that identifies and
-   authenticates a zone's DNSKEY RR.  The remainder of this section
-   assumes that the resolver has somehow obtained an initial set of
-   trust anchors.
-
-   An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY
-   RRset.  To authenticate an apex DNSKEY RRset by using an initial key,
-   the resolver MUST:
-
-   1.  verify that the initial DNSKEY RR appears in the apex DNSKEY
-       RRset, and that the DNSKEY RR has the Zone Key Flag (DNSKEY RDATA
-       bit 7) set; and
-
-   2.  verify that there is some RRSIG RR that covers the apex DNSKEY
-       RRset, and that the combination of the RRSIG RR and the initial
-       DNSKEY RR authenticates the DNSKEY RRset.  The process for using
-       an RRSIG RR to authenticate an RRset is described in Section 5.3.
-
-   Once the resolver has authenticated the apex DNSKEY RRset by using an
-   initial DNSKEY RR, delegations from that zone can be authenticated by
-   using DS RRs.  This allows a resolver to start from an initial key
-   and use DS RRsets to proceed recursively down the DNS tree, obtaining
-   other apex DNSKEY RRsets.  If the resolver were configured with a
-   root DNSKEY RR, and if every delegation had a DS RR associated with
-   it, then the resolver could obtain and validate any apex DNSKEY
-   RRset.  The process of using DS RRs to authenticate referrals is
-   described in Section 5.2.
-
-   Section 5.3 shows how the resolver can use DNSKEY RRs in the apex
-   DNSKEY RRset and RRSIG RRs from the zone to authenticate any other
-   RRsets in the zone once the resolver has authenticated a zone's apex
-   DNSKEY RRset.  Section 5.4 shows how the resolver can use
-   authenticated NSEC RRsets from the zone to prove that an RRset is not
-   present in the zone.
-
-   When a resolver indicates support for DNSSEC (by setting the DO bit),
-   a security-aware name server should attempt to provide the necessary
-   DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3).
-   However, a security-aware resolver may still receive a response that
-   lacks the appropriate DNSSEC RRs, whether due to configuration issues
-   such as an upstream security-oblivious recursive name server that
-
-
-
-Arends, et al.              Standards Track                    [Page 25]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   accidentally interferes with DNSSEC RRs or due to a deliberate attack
-   in which an adversary forges a response, strips DNSSEC RRs from a
-   response, or modifies a query so that DNSSEC RRs appear not to be
-   requested.  The absence of DNSSEC data in a response MUST NOT by
-   itself be taken as an indication that no authentication information
-   exists.
-
-   A resolver SHOULD expect authentication information from signed
-   zones.  A resolver SHOULD believe that a zone is signed if the
-   resolver has been configured with public key information for the
-   zone, or if the zone's parent is signed and the delegation from the
-   parent contains a DS RRset.
-
-5.1.  Special Considerations for Islands of Security
-
-   Islands of security (see [RFC4033]) are signed zones for which it is
-   not possible to construct an authentication chain to the zone from
-   its parent.  Validating signatures within an island of security
-   requires that the validator have some other means of obtaining an
-   initial authenticated zone key for the island.  If a validator cannot
-   obtain such a key, it SHOULD switch to operating as if the zones in
-   the island of security are unsigned.
-
-   All the normal processes for validating responses apply to islands of
-   security.  The only difference between normal validation and
-   validation within an island of security is in how the validator
-   obtains a trust anchor for the authentication chain.
-
-5.2.  Authenticating Referrals
-
-   Once the apex DNSKEY RRset for a signed parent zone has been
-   authenticated, DS RRsets can be used to authenticate the delegation
-   to a signed child zone.  A DS RR identifies a DNSKEY RR in the child
-   zone's apex DNSKEY RRset and contains a cryptographic digest of the
-   child zone's DNSKEY RR.  Use of a strong cryptographic digest
-   algorithm ensures that it is computationally infeasible for an
-   adversary to generate a DNSKEY RR that matches the digest.  Thus,
-   authenticating the digest allows a resolver to authenticate the
-   matching DNSKEY RR.  The resolver can then use this child DNSKEY RR
-   to authenticate the entire child apex DNSKEY RRset.
-
-   Given a DS RR for a delegation, the child zone's apex DNSKEY RRset
-   can be authenticated if all of the following hold:
-
-   o  The DS RR has been authenticated using some DNSKEY RR in the
-      parent's apex DNSKEY RRset (see Section 5.3).
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 26]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   o  The Algorithm and Key Tag in the DS RR match the Algorithm field
-      and the key tag of a DNSKEY RR in the child zone's apex DNSKEY
-      RRset, and, when the DNSKEY RR's owner name and RDATA are hashed
-      using the digest algorithm specified in the DS RR's Digest Type
-      field, the resulting digest value matches the Digest field of the
-      DS RR.
-
-   o  The matching DNSKEY RR in the child zone has the Zone Flag bit
-      set, the corresponding private key has signed the child zone's
-      apex DNSKEY RRset, and the resulting RRSIG RR authenticates the
-      child zone's apex DNSKEY RRset.
-
-   If the referral from the parent zone did not contain a DS RRset, the
-   response should have included a signed NSEC RRset proving that no DS
-   RRset exists for the delegated name (see Section 3.1.4).  A
-   security-aware resolver MUST query the name servers for the parent
-   zone for the DS RRset if the referral includes neither a DS RRset nor
-   a NSEC RRset proving that the DS RRset does not exist (see Section
-   4).
-
-   If the validator authenticates an NSEC RRset that proves that no DS
-   RRset is present for this zone, then there is no authentication path
-   leading from the parent to the child.  If the resolver has an initial
-   DNSKEY or DS RR that belongs to the child zone or to any delegation
-   below the child zone, this initial DNSKEY or DS RR MAY be used to
-   re-establish an authentication path.  If no such initial DNSKEY or DS
-   RR exists, the validator cannot authenticate RRsets in or below the
-   child zone.
-
-   If the validator does not support any of the algorithms listed in an
-   authenticated DS RRset, then the resolver has no supported
-   authentication path leading from the parent to the child.  The
-   resolver should treat this case as it would the case of an
-   authenticated NSEC RRset proving that no DS RRset exists, as
-   described above.
-
-   Note that, for a signed delegation, there are two NSEC RRs associated
-   with the delegated name.  One NSEC RR resides in the parent zone and
-   can be used to prove whether a DS RRset exists for the delegated
-   name.  The second NSEC RR resides in the child zone and identifies
-   which RRsets are present at the apex of the child zone.  The parent
-   NSEC RR and child NSEC RR can always be distinguished because the SOA
-   bit will be set in the child NSEC RR and clear in the parent NSEC RR.
-   A security-aware resolver MUST use the parent NSEC RR when attempting
-   to prove that a DS RRset does not exist.
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 27]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   If the resolver does not support any of the algorithms listed in an
-   authenticated DS RRset, then the resolver will not be able to verify
-   the authentication path to the child zone.  In this case, the
-   resolver SHOULD treat the child zone as if it were unsigned.
-
-5.3.  Authenticating an RRset with an RRSIG RR
-
-   A validator can use an RRSIG RR and its corresponding DNSKEY RR to
-   attempt to authenticate RRsets.  The validator first checks the RRSIG
-   RR to verify that it covers the RRset, has a valid time interval, and
-   identifies a valid DNSKEY RR.  The validator then constructs the
-   canonical form of the signed data by appending the RRSIG RDATA
-   (excluding the Signature Field) with the canonical form of the
-   covered RRset.  Finally, the validator uses the public key and
-   signature to authenticate the signed data.  Sections 5.3.1, 5.3.2,
-   and 5.3.3 describe each step in detail.
-
-5.3.1.  Checking the RRSIG RR Validity
-
-   A security-aware resolver can use an RRSIG RR to authenticate an
-   RRset if all of the following conditions hold:
-
-   o  The RRSIG RR and the RRset MUST have the same owner name and the
-      same class.
-
-   o  The RRSIG RR's Signer's Name field MUST be the name of the zone
-      that contains the RRset.
-
-   o  The RRSIG RR's Type Covered field MUST equal the RRset's type.
-
-   o  The number of labels in the RRset owner name MUST be greater than
-      or equal to the value in the RRSIG RR's Labels field.
-
-   o  The validator's notion of the current time MUST be less than or
-      equal to the time listed in the RRSIG RR's Expiration field.
-
-   o  The validator's notion of the current time MUST be greater than or
-      equal to the time listed in the RRSIG RR's Inception field.
-
-   o  The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST
-      match the owner name, algorithm, and key tag for some DNSKEY RR in
-      the zone's apex DNSKEY RRset.
-
-   o  The matching DNSKEY RR MUST be present in the zone's apex DNSKEY
-      RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7)
-      set.
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 28]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   It is possible for more than one DNSKEY RR to match the conditions
-   above.  In this case, the validator cannot predetermine which DNSKEY
-   RR to use to authenticate the signature, and it MUST try each
-   matching DNSKEY RR until either the signature is validated or the
-   validator has run out of matching public keys to try.
-
-   Note that this authentication process is only meaningful if the
-   validator authenticates the DNSKEY RR before using it to validate
-   signatures.  The matching DNSKEY RR is considered to be authentic if:
-
-   o  the apex DNSKEY RRset containing the DNSKEY RR is considered
-      authentic; or
-
-   o  the RRset covered by the RRSIG RR is the apex DNSKEY RRset itself,
-      and the DNSKEY RR either matches an authenticated DS RR from the
-      parent zone or matches a trust anchor.
-
-5.3.2.  Reconstructing the Signed Data
-
-   Once the RRSIG RR has met the validity requirements described in
-   Section 5.3.1, the validator has to reconstruct the original signed
-   data.  The original signed data includes RRSIG RDATA (excluding the
-   Signature field) and the canonical form of the RRset.  Aside from
-   being ordered, the canonical form of the RRset might also differ from
-   the received RRset due to DNS name compression, decremented TTLs, or
-   wildcard expansion.  The validator should use the following to
-   reconstruct the original signed data:
-
-         signed_data = RRSIG_RDATA | RR(1) | RR(2)...  where
-
-            "|" denotes concatenation
-
-            RRSIG_RDATA is the wire format of the RRSIG RDATA fields
-               with the Signature field excluded and the Signer's Name
-               in canonical form.
-
-            RR(i) = name | type | class | OrigTTL | RDATA length | RDATA
-
-               name is calculated according to the function below
-
-               class is the RRset's class
-
-               type is the RRset type and all RRs in the class
-
-               OrigTTL is the value from the RRSIG Original TTL field
-
-               All names in the RDATA field are in canonical form
-
-
-
-
-Arends, et al.              Standards Track                    [Page 29]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-               The set of all RR(i) is sorted into canonical order.
-
-            To calculate the name:
-               let rrsig_labels = the value of the RRSIG Labels field
-
-               let fqdn = RRset's fully qualified domain name in
-                               canonical form
-
-               let fqdn_labels = Label count of the fqdn above.
-
-               if rrsig_labels = fqdn_labels,
-                   name = fqdn
-
-               if rrsig_labels < fqdn_labels,
-                  name = "*." | the rightmost rrsig_label labels of the
-                                fqdn
-
-               if rrsig_labels > fqdn_labels
-                  the RRSIG RR did not pass the necessary validation
-                  checks and MUST NOT be used to authenticate this
-                  RRset.
-
-   The canonical forms for names and RRsets are defined in [RFC4034].
-
-   NSEC RRsets at a delegation boundary require special processing.
-   There are two distinct NSEC RRsets associated with a signed delegated
-   name.  One NSEC RRset resides in the parent zone, and specifies which
-   RRsets are present at the parent zone.  The second NSEC RRset resides
-   at the child zone and identifies which RRsets are present at the apex
-   in the child zone.  The parent NSEC RRset and child NSEC RRset can
-   always be distinguished as only a child NSEC RR will indicate that an
-   SOA RRset exists at the name.  When reconstructing the original NSEC
-   RRset for the delegation from the parent zone, the NSEC RRs MUST NOT
-   be combined with NSEC RRs from the child zone.  When reconstructing
-   the original NSEC RRset for the apex of the child zone, the NSEC RRs
-   MUST NOT be combined with NSEC RRs from the parent zone.
-
-   Note that each of the two NSEC RRsets at a delegation point has a
-   corresponding RRSIG RR with an owner name matching the delegated
-   name, and each of these RRSIG RRs is authoritative data associated
-   with the same zone that contains the corresponding NSEC RRset.  If
-   necessary, a resolver can tell these RRSIG RRs apart by checking the
-   Signer's Name field.
-
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 30]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-5.3.3.  Checking the Signature
-
-   Once the resolver has validated the RRSIG RR as described in Section
-   5.3.1 and reconstructed the original signed data as described in
-   Section 5.3.2, the validator can attempt to use the cryptographic
-   signature to authenticate the signed data, and thus (finally!)
-   authenticate the RRset.
-
-   The Algorithm field in the RRSIG RR identifies the cryptographic
-   algorithm used to generate the signature.  The signature itself is
-   contained in the Signature field of the RRSIG RDATA, and the public
-   key used to verify the signature is contained in the Public Key field
-   of the matching DNSKEY RR(s) (found in Section 5.3.1).  [RFC4034]
-   provides a list of algorithm types and provides pointers to the
-   documents that define each algorithm's use.
-
-   Note that it is possible for more than one DNSKEY RR to match the
-   conditions in Section 5.3.1.  In this case, the validator can only
-   determine which DNSKEY RR is correct by trying each matching public
-   key until the validator either succeeds in validating the signature
-   or runs out of keys to try.
-
-   If the Labels field of the RRSIG RR is not equal to the number of
-   labels in the RRset's fully qualified owner name, then the RRset is
-   either invalid or the result of wildcard expansion.  The resolver
-   MUST verify that wildcard expansion was applied properly before
-   considering the RRset to be authentic.  Section 5.3.4 describes how
-   to determine whether a wildcard was applied properly.
-
-   If other RRSIG RRs also cover this RRset, the local resolver security
-   policy determines whether the resolver also has to test these RRSIG
-   RRs and how to resolve conflicts if these RRSIG RRs lead to differing
-   results.
-
-   If the resolver accepts the RRset as authentic, the validator MUST
-   set the TTL of the RRSIG RR and each RR in the authenticated RRset to
-   a value no greater than the minimum of:
-
-   o  the RRset's TTL as received in the response;
-
-   o  the RRSIG RR's TTL as received in the response;
-
-   o  the value in the RRSIG RR's Original TTL field; and
-
-   o  the difference of the RRSIG RR's Signature Expiration time and the
-      current time.
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 31]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-5.3.4.  Authenticating a Wildcard Expanded RRset Positive Response
-
-   If the number of labels in an RRset's owner name is greater than the
-   Labels field of the covering RRSIG RR, then the RRset and its
-   covering RRSIG RR were created as a result of wildcard expansion.
-   Once the validator has verified the signature, as described in
-   Section 5.3, it must take additional steps to verify the non-
-   existence of an exact match or closer wildcard match for the query.
-   Section 5.4 discusses these steps.
-
-   Note that the response received by the resolver should include all
-   NSEC RRs needed to authenticate the response (see Section 3.1.3).
-
-5.4.  Authenticated Denial of Existence
-
-   A resolver can use authenticated NSEC RRs to prove that an RRset is
-   not present in a signed zone.  Security-aware name servers should
-   automatically include any necessary NSEC RRs for signed zones in
-   their responses to security-aware resolvers.
-
-   Denial of existence is determined by the following rules:
-
-   o  If the requested RR name matches the owner name of an
-      authenticated NSEC RR, then the NSEC RR's type bit map field lists
-      all RR types present at that owner name, and a resolver can prove
-      that the requested RR type does not exist by checking for the RR
-      type in the bit map.  If the number of labels in an authenticated
-      NSEC RR's owner name equals the Labels field of the covering RRSIG
-      RR, then the existence of the NSEC RR proves that wildcard
-      expansion could not have been used to match the request.
-
-   o  If the requested RR name would appear after an authenticated NSEC
-      RR's owner name and before the name listed in that NSEC RR's Next
-      Domain Name field according to the canonical DNS name order
-      defined in [RFC4034], then no RRsets with the requested name exist
-      in the zone.  However, it is possible that a wildcard could be
-      used to match the requested RR owner name and type, so proving
-      that the requested RRset does not exist also requires proving that
-      no possible wildcard RRset exists that could have been used to
-      generate a positive response.
-
-   In addition, security-aware resolvers MUST authenticate the NSEC
-   RRsets that comprise the non-existence proof as described in Section
-   5.3.
-
-   To prove the non-existence of an RRset, the resolver must be able to
-   verify both that the queried RRset does not exist and that no
-   relevant wildcard RRset exists.  Proving this may require more than
-
-
-
-Arends, et al.              Standards Track                    [Page 32]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   one NSEC RRset from the zone.  If the complete set of necessary NSEC
-   RRsets is not present in a response (perhaps due to message
-   truncation), then a security-aware resolver MUST resend the query in
-   order to attempt to obtain the full collection of NSEC RRs necessary
-   to verify the non-existence of the requested RRset.  As with all DNS
-   operations, however, the resolver MUST bound the work it puts into
-   answering any particular query.
-
-   Since a validated NSEC RR proves the existence of both itself and its
-   corresponding RRSIG RR, a validator MUST ignore the settings of the
-   NSEC and RRSIG bits in an NSEC RR.
-
-5.5.  Resolver Behavior When Signatures Do Not Validate
-
-   If for whatever reason none of the RRSIGs can be validated, the
-   response SHOULD be considered BAD.  If the validation was being done
-   to service a recursive query, the name server MUST return RCODE 2 to
-   the originating client.  However, it MUST return the full response if
-   and only if the original query had the CD bit set.  Also see Section
-   4.7 on caching responses that do not validate.
-
-5.6.  Authentication Example
-
-   Appendix C shows an example of the authentication process.
-
-6.  IANA Considerations
-
-   [RFC4034] contains a review of the IANA considerations introduced by
-   DNSSEC.  The following are additional IANA considerations discussed
-   in this document:
-
-   [RFC2535] reserved the CD and AD bits in the message header.  The
-   meaning of the AD bit was redefined in [RFC3655], and the meaning of
-   both the CD and AD bit are restated in this document.  No new bits in
-   the DNS message header are defined in this document.
-
-   [RFC2671] introduced EDNS, and [RFC3225] reserved the DNSSEC OK bit
-   and defined its use.  The use is restated but not altered in this
-   document.
-
-7.  Security Considerations
-
-   This document describes how the DNS security extensions use public
-   key cryptography to sign and authenticate DNS resource record sets.
-   Please see [RFC4033] for terminology and general security
-   considerations related to DNSSEC; see [RFC4034] for considerations
-   specific to the DNSSEC resource record types.
-
-
-
-
-Arends, et al.              Standards Track                    [Page 33]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   An active attacker who can set the CD bit in a DNS query message or
-   the AD bit in a DNS response message can use these bits to defeat the
-   protection that DNSSEC attempts to provide to security-oblivious
-   recursive-mode resolvers.  For this reason, use of these control bits
-   by a security-aware recursive-mode resolver requires a secure
-   channel.  See Sections 3.2.2 and 4.9 for further discussion.
-
-   The protocol described in this document attempts to extend the
-   benefits of DNSSEC to security-oblivious stub resolvers.  However, as
-   recovery from validation failures is likely to be specific to
-   particular applications, the facilities that DNSSEC provides for stub
-   resolvers may prove inadequate.  Operators of security-aware
-   recursive name servers will have to pay close attention to the
-   behavior of the applications that use their services when choosing a
-   local validation policy; failure to do so could easily result in the
-   recursive name server accidentally denying service to the clients it
-   is intended to support.
-
-8.  Acknowledgements
-
-   This document was created from the input and ideas of the members of
-   the DNS Extensions Working Group and working group mailing list.  The
-   editors would like to express their thanks for the comments and
-   suggestions received during the revision of these security extension
-   specifications.  Although explicitly listing everyone who has
-   contributed during the decade in which DNSSEC has been under
-   development would be impossible, [RFC4033] includes a list of some of
-   the participants who were kind enough to comment on these documents.
-
-9.  References
-
-9.1.  Normative References
-
-   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
-              STD 13, RFC 1034, November 1987.
-
-   [RFC1035]  Mockapetris, P., "Domain names - implementation and
-              specification", STD 13, RFC 1035, November 1987.
-
-   [RFC1122]  Braden, R., "Requirements for Internet Hosts -
-              Communication Layers", STD 3, RFC 1122, October 1989.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
-              Specification", RFC 2181, July 1997.
-
-
-
-
-Arends, et al.              Standards Track                    [Page 34]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
-              (IPv6) Specification", RFC 2460, December 1998.
-
-   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
-              2671, August 1999.
-
-   [RFC2672]  Crawford, M., "Non-Terminal DNS Name Redirection", RFC
-              2672, August 1999.
-
-   [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
-              3225, December 2001.
-
-   [RFC3226]  Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
-              message size requirements", RFC 3226, December 2001.
-
-   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "DNS Security Introduction and Requirements", RFC
-              4033, March 2005.
-
-   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Resource Records for DNS Security Extensions", RFC
-              4034, March 2005.
-
-9.2.  Informative References
-
-   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
-              NCACHE)", RFC 2308, March 1998.
-
-   [RFC2535]  Eastlake 3rd, D., "Domain Name System Security
-              Extensions", RFC 2535, March 1999.
-
-   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
-              Update", RFC 3007, November 2000.
-
-   [RFC3655]  Wellington, B. and O. Gudmundsson, "Redefinition of DNS
-              Authenticated Data (AD) bit", RFC 3655, November 2003.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 35]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-Appendix A.  Signed Zone Example
-
-   The following example shows a (small) complete signed zone.
-
-   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
-                              1081539377
-                              3600
-                              300
-                              3600000
-                              3600
-                              )
-                  3600 RRSIG  SOA 5 1 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
-                              7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
-                              vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
-                              DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
-                              jV7j86HyQgM5e7+miRAz8V01b0I= )
-                  3600 NS     ns1.example.
-                  3600 NS     ns2.example.
-                  3600 RRSIG  NS 5 1 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
-                              EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
-                              4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
-                              RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
-                              0HjMeRaZB/FRPGfJPajngcq6Kwg= )
-                  3600 MX     1 xx.example.
-                  3600 RRSIG  MX 5 1 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              HyDHYVT5KHSZ7HtO/vypumPmSZQrcOP3tzWB
-                              2qaKkHVPfau/DgLgS/IKENkYOGL95G4N+NzE
-                              VyNU8dcTOckT+ChPcGeVjguQ7a3Ao9Z/ZkUO
-                              6gmmUW4b89rz1PUxW4jzUxj66PTwoVtUU/iM
-                              W6OISukd1EQt7a0kygkg+PEDxdI= )
-                  3600 NSEC   a.example. NS SOA MX RRSIG NSEC DNSKEY
-                  3600 RRSIG  NSEC 5 1 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
-                              FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
-                              Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
-                              SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
-                              jfFJ5arXf4nPxp/kEowGgBRzY/U= )
-                  3600 DNSKEY 256 3 5 (
-                              AQOy1bZVvpPqhg4j7EJoM9rI3ZmyEx2OzDBV
-                              rZy/lvI5CQePxXHZS4i8dANH4DX3tbHol61e
-                              k8EFMcsGXxKciJFHyhl94C+NwILQdzsUlSFo
-                              vBZsyl/NX6yEbtw/xN9ZNcrbYvgjjZ/UVPZI
-
-
-
-Arends, et al.              Standards Track                    [Page 36]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-                              ySFNsgEYvh0z2542lzMKR4Dh8uZffQ==
-                              )
-                  3600 DNSKEY 257 3 5 (
-                              AQOeX7+baTmvpVHb2CcLnL1dMRWbuscRvHXl
-                              LnXwDzvqp4tZVKp1sZMepFb8MvxhhW3y/0QZ
-                              syCjczGJ1qk8vJe52iOhInKROVLRwxGpMfzP
-                              RLMlGybr51bOV/1se0ODacj3DomyB4QB5gKT
-                              Yot/K9alk5/j8vfd4jWCWD+E1Sze0Q==
-                              )
-                  3600 RRSIG  DNSKEY 5 1 3600 20040509183619 (
-                              20040409183619 9465 example.
-                              ZxgauAuIj+k1YoVEOSlZfx41fcmKzTFHoweZ
-                              xYnz99JVQZJ33wFS0Q0jcP7VXKkaElXk9nYJ
-                              XevO/7nAbo88iWsMkSpSR6jWzYYKwfrBI/L9
-                              hjYmyVO9m6FjQ7uwM4dCP/bIuV/DKqOAK9NY
-                              NC3AHfvCV1Tp4VKDqxqG7R5tTVM= )
-                  3600 RRSIG  DNSKEY 5 1 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              eGL0s90glUqcOmloo/2y+bSzyEfKVOQViD9Z
-                              DNhLz/Yn9CQZlDVRJffACQDAUhXpU/oP34ri
-                              bKBpysRXosczFrKqS5Oa0bzMOfXCXup9qHAp
-                              eFIku28Vqfr8Nt7cigZLxjK+u0Ws/4lIRjKk
-                              7z5OXogYVaFzHKillDt3HRxHIZM= )
-   a.example.     3600 IN NS  ns1.a.example.
-                  3600 IN NS  ns2.a.example.
-                  3600 DS     57855 5 1 (
-                              B6DCD485719ADCA18E5F3D48A2331627FDD3
-                              636B )
-                  3600 RRSIG  DS 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ
-                              oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH
-                              kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD
-                              EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/
-                              Fm+v6ccF2EGNLRiY08kdkz+XHHo= )
-                  3600 NSEC   ai.example. NS DS RRSIG NSEC
-                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              cOlYgqJLqlRqmBQ3iap2SyIsK4O5aqpKSoba
-                              U9fQ5SMApZmHfq3AgLflkrkXRXvgxTQSKkG2
-                              039/cRUs6Jk/25+fi7Xr5nOVJsb0lq4zsB3I
-                              BBdjyGDAHE0F5ROJj87996vJupdm1fbH481g
-                              sdkOW6Zyqtz3Zos8N0BBkEx+2G4= )
-   ns1.a.example. 3600 IN A   192.0.2.5
-   ns2.a.example. 3600 IN A   192.0.2.6
-   ai.example.    3600 IN A   192.0.2.9
-                  3600 RRSIG  A 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-
-
-
-Arends, et al.              Standards Track                    [Page 37]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-                              pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B
-                              ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd
-                              hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u
-                              ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy
-                              6zrTpg9FkS0XGVmYRvOTNYx2HvQ= )
-                  3600 HINFO  "KLH-10" "ITS"
-                  3600 RRSIG  HINFO 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              Iq/RGCbBdKzcYzlGE4ovbr5YcB+ezxbZ9W0l
-                              e/7WqyvhOO9J16HxhhL7VY/IKmTUY0GGdcfh
-                              ZEOCkf4lEykZF9NPok1/R/fWrtzNp8jobuY7
-                              AZEcZadp1WdDF3jc2/ndCa5XZhLKD3JzOsBw
-                              FvL8sqlS5QS6FY/ijFEDnI4RkZA= )
-                  3600 AAAA   2001:db8::f00:baa9
-                  3600 RRSIG  AAAA 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK
-                              kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh
-                              1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T
-                              cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2
-                              sZM6QjBBLmukH30+w1z3h8PUP2o= )
-                  3600 NSEC   b.example. A HINFO AAAA RRSIG NSEC
-                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              QoshyPevLcJ/xcRpEtMft1uoIrcrieVcc9pG
-                              CScIn5Glnib40T6ayVOimXwdSTZ/8ISXGj4p
-                              P8Sh0PlA6olZQ84L453/BUqB8BpdOGky4hsN
-                              3AGcLEv1Gr0QMvirQaFcjzOECfnGyBm+wpFL
-                              AhS+JOVfDI/79QtyTI0SaDWcg8U= )
-   b.example.     3600 IN NS  ns1.b.example.
-                  3600 IN NS  ns2.b.example.
-                  3600 NSEC   ns1.example. NS RRSIG NSEC
-                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
-                              9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
-                              xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
-                              0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
-                              vhRXgWT7OuFXldoCG6TfVFMs9xE= )
-   ns1.b.example. 3600 IN A   192.0.2.7
-   ns2.b.example. 3600 IN A   192.0.2.8
-   ns1.example.   3600 IN A   192.0.2.1
-                  3600 RRSIG  A 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet
-                              5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06
-                              im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+
-                              +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK
-
-
-
-Arends, et al.              Standards Track                    [Page 38]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-                              v/iVXSYC0b7mPSU+EOlknFpVECs= )
-                  3600 NSEC   ns2.example. A RRSIG NSEC
-                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8
-                              1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB
-                              jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq
-                              ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8
-                              IZaIGBLryQWGLw6Y6X8dqhlnxJM= )
-   ns2.example.   3600 IN A   192.0.2.2
-                  3600 RRSIG  A 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq
-                              Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu
-                              yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO
-                              6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq
-                              rdhx8SZ0yy4ObIRzIzvBFLiSS8o= )
-                  3600 NSEC   *.w.example. A RRSIG NSEC
-                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              N0QzHvaJf5NRw1rE9uxS1Ltb2LZ73Qb9bKGE
-                              VyaISkqzGpP3jYJXZJPVTq4UVEsgT3CgeHvb
-                              3QbeJ5Dfb2V9NGCHj/OvF/LBxFFWwhLwzngH
-                              l+bQAgAcMsLu/nL3nDi1y/JSQjAcdZNDl4bw
-                              Ymx28EtgIpo9A0qmP08rMBqs1Jw= )
-   *.w.example.   3600 IN MX  1 ai.example.
-                  3600 RRSIG  MX 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2
-                              f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc
-                              tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X
-                              TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw
-                              4kX18MMR34i8lC36SR5xBni8vHI= )
-                  3600 NSEC   x.w.example. MX RRSIG NSEC
-                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9
-                              HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU
-                              5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx
-                              91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8
-                              s1InQ2UoIv6tJEaaKkP701j8OLA= )
-   x.w.example.   3600 IN MX  1 xx.example.
-                  3600 RRSIG  MX 5 3 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1
-                              XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP
-                              H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I
-                              kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1
-
-
-
-Arends, et al.              Standards Track                    [Page 39]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-                              jNSlwZ2mSWKHfxFQxPtLj8s32+k= )
-                  3600 NSEC   x.y.w.example. MX RRSIG NSEC
-                  3600 RRSIG  NSEC 5 3 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              aRbpHftxggzgMXdDlym9SsADqMZovZZl2QWK
-                              vw8J0tZEUNQByH5Qfnf5N1FqH/pS46UA7A4E
-                              mcWBN9PUA1pdPY6RVeaRlZlCr1IkVctvbtaI
-                              NJuBba/VHm+pebTbKcAPIvL9tBOoh+to1h6e
-                              IjgiM8PXkBQtxPq37wDKALkyn7Q= )
-   x.y.w.example. 3600 IN MX  1 xx.example.
-                  3600 RRSIG  MX 5 4 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              k2bJHbwP5LH5qN4is39UiPzjAWYmJA38Hhia
-                              t7i9t7nbX/e0FPnvDSQXzcK7UL+zrVA+3MDj
-                              q1ub4q3SZgcbLMgexxIW3Va//LVrxkP6Xupq
-                              GtOB9prkK54QTl/qZTXfMQpW480YOvVknhvb
-                              +gLcMZBnHJ326nb/TOOmrqNmQQE= )
-                  3600 NSEC   xx.example. MX RRSIG NSEC
-                  3600 RRSIG  NSEC 5 4 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
-                              ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
-                              xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
-                              a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
-                              QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
-   xx.example.    3600 IN A   192.0.2.10
-                  3600 RRSIG  A 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP
-                              7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa
-                              0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y
-                              VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx
-                              kbIDV6GPPSZVusnZU6OMgdgzHV4= )
-                  3600 HINFO  "KLH-10" "TOPS-20"
-                  3600 RRSIG  HINFO 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              GY2PLSXmMHkWHfLdggiox8+chWpeMNJLkML0
-                              t+U/SXSUsoUdR91KNdNUkTDWamwcF8oFRjhq
-                              BcPZ6EqrF+vl5v5oGuvSF7U52epfVTC+wWF8
-                              3yCUeUw8YklhLWlvk8gQ15YKth0ITQy8/wI+
-                              RgNvuwbioFSEuv2pNlkq0goYxNY= )
-                  3600 AAAA   2001:db8::f00:baaa
-                  3600 RRSIG  AAAA 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C
-                              aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z
-                              ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr
-                              U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/
-
-
-
-Arends, et al.              Standards Track                    [Page 40]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-                              xS9cL2QgW7FChw16mzlkH6/vsfs= )
-                  3600 NSEC   example. A HINFO AAAA RRSIG NSEC
-                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              ZFWUln6Avc8bmGl5GFjD3BwT530DUZKHNuoY
-                              9A8lgXYyrxu+pqgFiRVbyZRQvVB5pccEOT3k
-                              mvHgEa/HzbDB4PIYY79W+VHrgOxzdQGGCZzi
-                              asXrpSGOWwSOElghPnMIi8xdF7qtCntr382W
-                              GghLahumFIpg4MO3LS/prgzVVWo= )
-
-   The apex DNSKEY set includes two DNSKEY RRs, and the DNSKEY RDATA
-   Flags indicate that each of these DNSKEY RRs is a zone key.  One of
-   these DNSKEY RRs also has the SEP flag set and has been used to sign
-   the apex DNSKEY RRset; this is the key that should be hashed to
-   generate a DS record to be inserted into the parent zone.  The other
-   DNSKEY is used to sign all the other RRsets in the zone.
-
-   The zone includes a wildcard entry, "*.w.example".  Note that the
-   name "*.w.example" is used in constructing NSEC chains, and that the
-   RRSIG covering the "*.w.example" MX RRset has a label count of 2.
-
-   The zone also includes two delegations.  The delegation to
-   "b.example" includes an NS RRset, glue address records, and an NSEC
-   RR; note that only the NSEC RRset is signed.  The delegation to
-   "a.example" provides a DS RR; note that only the NSEC and DS RRsets
-   are signed.
-
-Appendix B.  Example Responses
-
-   The examples in this section show response messages using the signed
-   zone example in Appendix A.
-
-B.1.  Answer
-
-   A successful query to an authoritative server.
-
-   ;; Header: QR AA DO RCODE=0
-   ;;
-   ;; Question
-   x.w.example.        IN MX
-
-   ;; Answer
-   x.w.example.   3600 IN MX  1 xx.example.
-   x.w.example.   3600 RRSIG  MX 5 3 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1
-                              XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP
-                              H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I
-
-
-
-Arends, et al.              Standards Track                    [Page 41]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-                              kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1
-                              jNSlwZ2mSWKHfxFQxPtLj8s32+k= )
-
-   ;; Authority
-   example.       3600 NS     ns1.example.
-   example.       3600 NS     ns2.example.
-   example.       3600 RRSIG  NS 5 1 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
-                              EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
-                              4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
-                              RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
-                              0HjMeRaZB/FRPGfJPajngcq6Kwg= )
-
-   ;; Additional
-   xx.example.    3600 IN A   192.0.2.10
-   xx.example.    3600 RRSIG  A 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP
-                              7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa
-                              0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y
-                              VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx
-                              kbIDV6GPPSZVusnZU6OMgdgzHV4= )
-   xx.example.    3600 AAAA   2001:db8::f00:baaa
-   xx.example.    3600 RRSIG  AAAA 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C
-                              aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z
-                              ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr
-                              U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/
-                              xS9cL2QgW7FChw16mzlkH6/vsfs= )
-   ns1.example.   3600 IN A   192.0.2.1
-   ns1.example.   3600 RRSIG  A 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet
-                              5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06
-                              im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+
-                              +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK
-                              v/iVXSYC0b7mPSU+EOlknFpVECs= )
-   ns2.example.   3600 IN A   192.0.2.2
-   ns2.example.   3600 RRSIG  A 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq
-                              Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu
-                              yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO
-                              6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq
-                              rdhx8SZ0yy4ObIRzIzvBFLiSS8o= )
-
-
-
-
-Arends, et al.              Standards Track                    [Page 42]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-B.2.  Name Error
-
-   An authoritative name error.  The NSEC RRs prove that the name does
-   not exist and that no covering wildcard exists.
-
-   ;; Header: QR AA DO RCODE=3
-   ;;
-   ;; Question
-   ml.example.         IN A
-
-   ;; Answer
-   ;; (empty)
-
-   ;; Authority
-   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
-                              1081539377
-                              3600
-                              300
-                              3600000
-                              3600
-                              )
-   example.       3600 RRSIG  SOA 5 1 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
-                              7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
-                              vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
-                              DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
-                              jV7j86HyQgM5e7+miRAz8V01b0I= )
-   b.example.     3600 NSEC   ns1.example. NS RRSIG NSEC
-   b.example.     3600 RRSIG  NSEC 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
-                              9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
-                              xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
-                              0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
-                              vhRXgWT7OuFXldoCG6TfVFMs9xE= )
-   example.       3600 NSEC   a.example. NS SOA MX RRSIG NSEC DNSKEY
-   example.       3600 RRSIG  NSEC 5 1 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
-                              FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
-                              Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
-                              SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
-                              jfFJ5arXf4nPxp/kEowGgBRzY/U= )
-
-   ;; Additional
-   ;; (empty)
-
-
-
-
-Arends, et al.              Standards Track                    [Page 43]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-B.3.  No Data Error
-
-   A "no data" response.  The NSEC RR proves that the name exists and
-   that the requested RR type does not.
-
-   ;; Header: QR AA DO RCODE=0
-   ;;
-   ;; Question
-   ns1.example.        IN MX
-
-   ;; Answer
-   ;; (empty)
-
-   ;; Authority
-   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
-                              1081539377
-                              3600
-                              300
-                              3600000
-                              3600
-                              )
-   example.       3600 RRSIG  SOA 5 1 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
-                              7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
-                              vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
-                              DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
-                              jV7j86HyQgM5e7+miRAz8V01b0I= )
-   ns1.example.   3600 NSEC   ns2.example. A RRSIG NSEC
-   ns1.example.   3600 RRSIG  NSEC 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8
-                              1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB
-                              jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq
-                              ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8
-                              IZaIGBLryQWGLw6Y6X8dqhlnxJM= )
-
-   ;; Additional
-   ;; (empty)
-
-B.4.  Referral to Signed Zone
-
-   Referral to a signed zone.  The DS RR contains the data which the
-   resolver will need to validate the corresponding DNSKEY RR in the
-   child zone's apex.
-
-   ;; Header: QR DO RCODE=0
-   ;;
-
-
-
-Arends, et al.              Standards Track                    [Page 44]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   ;; Question
-   mc.a.example.       IN MX
-
-   ;; Answer
-   ;; (empty)
-
-   ;; Authority
-   a.example.     3600 IN NS  ns1.a.example.
-   a.example.     3600 IN NS  ns2.a.example.
-   a.example.     3600 DS     57855 5 1 (
-                              B6DCD485719ADCA18E5F3D48A2331627FDD3
-                              636B )
-   a.example.     3600 RRSIG  DS 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ
-                              oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH
-                              kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD
-                              EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/
-                              Fm+v6ccF2EGNLRiY08kdkz+XHHo= )
-
-   ;; Additional
-   ns1.a.example. 3600 IN A   192.0.2.5
-   ns2.a.example. 3600 IN A   192.0.2.6
-
-B.5.  Referral to Unsigned Zone
-
-   Referral to an unsigned zone.  The NSEC RR proves that no DS RR for
-   this delegation exists in the parent zone.
-
-   ;; Header: QR DO RCODE=0
-   ;;
-   ;; Question
-   mc.b.example.       IN MX
-
-   ;; Answer
-   ;; (empty)
-
-   ;; Authority
-   b.example.     3600 IN NS  ns1.b.example.
-   b.example.     3600 IN NS  ns2.b.example.
-   b.example.     3600 NSEC   ns1.example. NS RRSIG NSEC
-   b.example.     3600 RRSIG  NSEC 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
-                              9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
-                              xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
-                              0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
-                              vhRXgWT7OuFXldoCG6TfVFMs9xE= )
-
-
-
-Arends, et al.              Standards Track                    [Page 45]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   ;; Additional
-   ns1.b.example. 3600 IN A   192.0.2.7
-   ns2.b.example. 3600 IN A   192.0.2.8
-
-B.6.  Wildcard Expansion
-
-   A successful query that was answered via wildcard expansion.  The
-   label count in the answer's RRSIG RR indicates that a wildcard RRset
-   was expanded to produce this response, and the NSEC RR proves that no
-   closer match exists in the zone.
-
-   ;; Header: QR AA DO RCODE=0
-   ;;
-   ;; Question
-   a.z.w.example.      IN MX
-
-   ;; Answer
-   a.z.w.example. 3600 IN MX  1 ai.example.
-   a.z.w.example. 3600 RRSIG  MX 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2
-                              f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc
-                              tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X
-                              TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw
-                              4kX18MMR34i8lC36SR5xBni8vHI= )
-
-   ;; Authority
-   example.       3600 NS     ns1.example.
-   example.       3600 NS     ns2.example.
-   example.       3600 RRSIG  NS 5 1 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
-                              EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
-                              4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
-                              RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
-                              0HjMeRaZB/FRPGfJPajngcq6Kwg= )
-   x.y.w.example. 3600 NSEC   xx.example. MX RRSIG NSEC
-   x.y.w.example. 3600 RRSIG  NSEC 5 4 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
-                              ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
-                              xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
-                              a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
-                              QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
-
-   ;; Additional
-   ai.example.    3600 IN A   192.0.2.9
-   ai.example.    3600 RRSIG  A 5 2 3600 20040509183619 (
-
-
-
-Arends, et al.              Standards Track                    [Page 46]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-                              20040409183619 38519 example.
-                              pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B
-                              ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd
-                              hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u
-                              ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy
-                              6zrTpg9FkS0XGVmYRvOTNYx2HvQ= )
-   ai.example.    3600 AAAA   2001:db8::f00:baa9
-   ai.example.    3600 RRSIG  AAAA 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK
-                              kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh
-                              1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T
-                              cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2
-                              sZM6QjBBLmukH30+w1z3h8PUP2o= )
-
-B.7.  Wildcard No Data Error
-
-   A "no data" response for a name covered by a wildcard.  The NSEC RRs
-   prove that the matching wildcard name does not have any RRs of the
-   requested type and that no closer match exists in the zone.
-
-   ;; Header: QR AA DO RCODE=0
-   ;;
-   ;; Question
-   a.z.w.example.      IN AAAA
-
-   ;; Answer
-   ;; (empty)
-
-   ;; Authority
-   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
-                              1081539377
-                              3600
-                              300
-                              3600000
-                              3600
-                              )
-   example.       3600 RRSIG  SOA 5 1 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
-                              7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
-                              vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
-                              DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
-                              jV7j86HyQgM5e7+miRAz8V01b0I= )
-   x.y.w.example. 3600 NSEC   xx.example. MX RRSIG NSEC
-   x.y.w.example. 3600 RRSIG  NSEC 5 4 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
-
-
-
-Arends, et al.              Standards Track                    [Page 47]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-                              ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
-                              xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
-                              a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
-                              QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
-   *.w.example.   3600 NSEC   x.w.example. MX RRSIG NSEC
-   *.w.example.   3600 RRSIG  NSEC 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9
-                              HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU
-                              5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx
-                              91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8
-                              s1InQ2UoIv6tJEaaKkP701j8OLA= )
-
-   ;; Additional
-   ;; (empty)
-
-B.8.  DS Child Zone No Data Error
-
-   A "no data" response for a QTYPE=DS query that was mistakenly sent to
-   a name server for the child zone.
-
-   ;; Header: QR AA DO RCODE=0
-   ;;
-   ;; Question
-   example.            IN DS
-
-   ;; Answer
-   ;; (empty)
-
-   ;; Authority
-   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
-                              1081539377
-                              3600
-                              300
-                              3600000
-                              3600
-                              )
-   example.       3600 RRSIG  SOA 5 1 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
-                              7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
-                              vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
-                              DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
-                              jV7j86HyQgM5e7+miRAz8V01b0I= )
-   example.       3600 NSEC   a.example. NS SOA MX RRSIG NSEC DNSKEY
-   example.       3600 RRSIG  NSEC 5 1 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
-
-
-
-Arends, et al.              Standards Track                    [Page 48]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-                              FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
-                              Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
-                              SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
-                              jfFJ5arXf4nPxp/kEowGgBRzY/U= )
-
-   ;; Additional
-   ;; (empty)
-
-Appendix C.  Authentication Examples
-
-   The examples in this section show how the response messages in
-   Appendix B are authenticated.
-
-C.1.  Authenticating an Answer
-
-   The query in Appendix B.1 returned an MX RRset for "x.w.example.com".
-   The corresponding RRSIG indicates that the MX RRset was signed by an
-   "example" DNSKEY with algorithm 5 and key tag 38519.  The resolver
-   needs the corresponding DNSKEY RR in order to authenticate this
-   answer.  The discussion below describes how a resolver might obtain
-   this DNSKEY RR.
-
-   The RRSIG indicates the original TTL of the MX RRset was 3600, and,
-   for the purpose of authentication, the current TTL is replaced by
-   3600.  The RRSIG labels field value of 3 indicates that the answer
-   was not the result of wildcard expansion.  The "x.w.example.com" MX
-   RRset is placed in canonical form, and, assuming the current time
-   falls between the signature inception and expiration dates, the
-   signature is authenticated.
-
-C.1.1.  Authenticating the Example DNSKEY RR
-
-   This example shows the logical authentication process that starts
-   from the a configured root DNSKEY (or DS RR) and moves down the tree
-   to authenticate the desired "example" DNSKEY RR.  Note that the
-   logical order is presented for clarity.  An implementation may choose
-   to construct the authentication as referrals are received or to
-   construct the authentication chain only after all RRsets have been
-   obtained, or in any other combination it sees fit.  The example here
-   demonstrates only the logical process and does not dictate any
-   implementation rules.
-
-   We assume the resolver starts with a configured DNSKEY RR for the
-   root zone (or a configured DS RR for the root zone).  The resolver
-   checks whether this configured DNSKEY RR is present in the root
-   DNSKEY RRset (or whether the DS RR matches some DNSKEY in the root
-   DNSKEY RRset), whether this DNSKEY RR has signed the root DNSKEY
-   RRset, and whether the signature lifetime is valid.  If all these
-
-
-
-Arends, et al.              Standards Track                    [Page 49]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   conditions are met, all keys in the DNSKEY RRset are considered
-   authenticated.  The resolver then uses one (or more) of the root
-   DNSKEY RRs to authenticate the "example" DS RRset.  Note that the
-   resolver may have to query the root zone to obtain the root DNSKEY
-   RRset or "example" DS RRset.
-
-   Once the DS RRset has been authenticated using the root DNSKEY, the
-   resolver checks the "example" DNSKEY RRset for some "example" DNSKEY
-   RR that matches one of the authenticated "example" DS RRs.  If such a
-   matching "example" DNSKEY is found, the resolver checks whether this
-   DNSKEY RR has signed the "example" DNSKEY RRset and the signature
-   lifetime is valid.  If these conditions are met, all keys in the
-   "example" DNSKEY RRset are considered authenticated.
-
-   Finally, the resolver checks that some DNSKEY RR in the "example"
-   DNSKEY RRset uses algorithm 5 and has a key tag of 38519.  This
-   DNSKEY is used to authenticate the RRSIG included in the response.
-   If multiple "example" DNSKEY RRs match this algorithm and key tag,
-   then each DNSKEY RR is tried, and the answer is authenticated if any
-   of the matching DNSKEY RRs validate the signature as described above.
-
-C.2.  Name Error
-
-   The query in Appendix B.2 returned NSEC RRs that prove that the
-   requested data does not exist and no wildcard applies.  The negative
-   reply is authenticated by verifying both NSEC RRs.  The NSEC RRs are
-   authenticated in a manner identical to that of the MX RRset discussed
-   above.
-
-C.3.  No Data Error
-
-   The query in Appendix B.3 returned an NSEC RR that proves that the
-   requested name exists, but the requested RR type does not exist.  The
-   negative reply is authenticated by verifying the NSEC RR.  The NSEC
-   RR is authenticated in a manner identical to that of the MX RRset
-   discussed above.
-
-C.4.  Referral to Signed Zone
-
-   The query in Appendix B.4 returned a referral to the signed
-   "a.example." zone.  The DS RR is authenticated in a manner identical
-   to that of the MX RRset discussed above.  This DS RR is used to
-   authenticate the "a.example" DNSKEY RRset.
-
-   Once the "a.example" DS RRset has been authenticated using the
-   "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset
-   for some "a.example" DNSKEY RR that matches the DS RR.  If such a
-   matching "a.example" DNSKEY is found, the resolver checks whether
-
-
-
-Arends, et al.              Standards Track                    [Page 50]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   this DNSKEY RR has signed the "a.example" DNSKEY RRset and whether
-   the signature lifetime is valid.  If all these conditions are met,
-   all keys in the "a.example" DNSKEY RRset are considered
-   authenticated.
-
-C.5.  Referral to Unsigned Zone
-
-   The query in Appendix B.5 returned a referral to an unsigned
-   "b.example." zone.  The NSEC proves that no authentication leads from
-   "example" to "b.example", and the NSEC RR is authenticated in a
-   manner identical to that of the MX RRset discussed above.
-
-C.6.  Wildcard Expansion
-
-   The query in Appendix B.6 returned an answer that was produced as a
-   result of wildcard expansion.  The answer section contains a wildcard
-   RRset expanded as it would be in a traditional DNS response, and the
-   corresponding RRSIG indicates that the expanded wildcard MX RRset was
-   signed by an "example" DNSKEY with algorithm 5 and key tag 38519.
-   The RRSIG indicates that the original TTL of the MX RRset was 3600,
-   and, for the purpose of authentication, the current TTL is replaced
-   by 3600.  The RRSIG labels field value of 2 indicates that the answer
-   is the result of wildcard expansion, as the "a.z.w.example" name
-   contains 4 labels.  The name "a.z.w.w.example" is replaced by
-   "*.w.example", the MX RRset is placed in canonical form, and,
-   assuming that the current time falls between the signature inception
-   and expiration dates, the signature is authenticated.
-
-   The NSEC proves that no closer match (exact or closer wildcard) could
-   have been used to answer this query, and the NSEC RR must also be
-   authenticated before the answer is considered valid.
-
-C.7.  Wildcard No Data Error
-
-   The query in Appendix B.7 returned NSEC RRs that prove that the
-   requested data does not exist and no wildcard applies.  The negative
-   reply is authenticated by verifying both NSEC RRs.
-
-C.8.  DS Child Zone No Data Error
-
-   The query in Appendix B.8 returned NSEC RRs that shows the requested
-   was answered by a child server ("example" server).  The NSEC RR
-   indicates the presence of an SOA RR, showing that the answer is from
-   the child .  Queries for the "example" DS RRset should be sent to the
-   parent servers ("root" servers).
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 51]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-Authors' Addresses
-
-   Roy Arends
-   Telematica Instituut
-   Brouwerijstraat 1
-   7523 XC  Enschede
-   NL
-
-   EMail: roy.arends@telin.nl
-
-
-   Rob Austein
-   Internet Systems Consortium
-   950 Charter Street
-   Redwood City, CA  94063
-   USA
-
-   EMail: sra@isc.org
-
-
-   Matt Larson
-   VeriSign, Inc.
-   21345 Ridgetop Circle
-   Dulles, VA  20166-6503
-   USA
-
-   EMail: mlarson@verisign.com
-
-
-   Dan Massey
-   Colorado State University
-   Department of Computer Science
-   Fort Collins, CO 80523-1873
-
-   EMail: massey@cs.colostate.edu
-
-
-   Scott Rose
-   National Institute for Standards and Technology
-   100 Bureau Drive
-   Gaithersburg, MD  20899-8920
-   USA
-
-   EMail: scott.rose@nist.gov
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 52]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2005).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 53]
-
diff --git a/contrib/bind9/doc/rfc/rfc4074.txt b/contrib/bind9/doc/rfc/rfc4074.txt
deleted file mode 100644
index d9252b3..0000000
--- a/contrib/bind9/doc/rfc/rfc4074.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                       Y. Morishita
-Request for Comments: 4074                                          JPRS
-Category: Informational                                        T. Jinmei
-                                                                 Toshiba
-                                                                May 2005
-
-
-       Common Misbehavior Against DNS Queries for IPv6 Addresses
-
-Status of This Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   There is some known misbehavior of DNS authoritative servers when
-   they are queried for AAAA resource records.  Such behavior can block
-   IPv4 communication that should actually be available, cause a
-   significant delay in name resolution, or even make a denial of
-   service attack.  This memo describes details of known cases and
-   discusses their effects.
-
-1.  Introduction
-
-   Many existing DNS clients (resolvers) that support IPv6 first search
-   for AAAA Resource Records (RRs) of a target host name, and then for A
-   RRs of the same name.  This fallback mechanism is based on the DNS
-   specifications, which if not obeyed by authoritative servers, can
-   produce unpleasant results.  In some cases, for example, a web
-   browser fails to connect to a web server it could otherwise reach.
-   In the following sections, this memo describes some typical cases of
-   such misbehavior and its (bad) effects.
-
-   Note that the misbehavior is not specific to AAAA RRs.  In fact, all
-   known examples also apply to the cases of queries for MX, NS, and SOA
-   RRs.  The authors believe this can be generalized for all types of
-   queries other than those for A RRs.  In this memo, however, we
-   concentrate on the case for AAAA queries, since the problem is
-   particularly severe for resolvers that support IPv6, which thus
-   affects many end users.  Resolvers at end users normally send A
-   and/or AAAA queries only, so the problem for the other cases is
-   relatively minor.
-
-
-
-Morishita & Jinmei           Informational                      [Page 1]
-
-RFC 4074         Common Misbehavior Against DNS Queries         May 2005
-
-
-2.  Network Model
-
-   In this memo, we assume a typical network model of name resolution
-   environment using DNS.  It consists of three components: stub
-   resolvers, caching servers, and authoritative servers.  A stub
-   resolver issues a recursive query to a caching server, which then
-   handles the entire name resolution procedure recursively.  The
-   caching server caches the result of the query and sends the result to
-   the stub resolver.  The authoritative servers respond to queries for
-   names for which they have the authority, normally in a non-recursive
-   manner.
-
-3.  Expected Behavior
-
-   Suppose that an authoritative server has an A RR but has no AAAA RR
-   for a host name.  Then, the server should return a response to a
-   query for an AAAA RR of the name with the response code (RCODE) being
-   0 (indicating no error) and with an empty answer section (see
-   Sections 4.3.2 and 6.2.4 of [1]).  Such a response indicates that
-   there is at least one RR of a different type than AAAA for the
-   queried name, and the stub resolver can then look for A RRs.
-
-   This way, the caching server can cache the fact that the queried name
-   has no AAAA RR (but may have other types of RRs), and thus improve
-   the response time to further queries for an AAAA RR of the name.
-
-4.  Problematic Behaviors
-
-   There are some known cases at authoritative servers that do not
-   conform to the expected behavior.  This section describes those
-   problematic cases.
-
-4.1.  Ignore Queries for AAAA
-
-   Some authoritative servers seem to ignore queries for an AAAA RR,
-   causing a delay at the stub resolver to fall back to a query for an A
-   RR.  This behavior may cause a fatal timeout at the resolver or at
-   the application that calls the resolver.  Even if the resolver
-   eventually falls back, the result can be an unacceptable delay for
-   the application user, especially with interactive applications like
-   web browsing.
-
-4.2.  Return "Name Error"
-
-   This type of server returns a response with RCODE 3 ("Name Error") to
-   a query for an AAAA RR, indicating that it does not have any RRs of
-   any type for the queried name.
-
-
-
-
-Morishita & Jinmei           Informational                      [Page 2]
-
-RFC 4074         Common Misbehavior Against DNS Queries         May 2005
-
-
-   With this response, the stub resolver may immediately give up and
-   never fall back.  Even if the resolver retries with a query for an A
-   RR, the negative response for the name has been cached in the caching
-   server, and the caching server will simply return the negative
-   response.  As a result, the stub resolver considers this to be a
-   fatal error in name resolution.
-
-   Several examples of this behavior are known to the authors.  As of
-   this writing, all have been fixed.
-
-4.3.  Return Other Erroneous Codes
-
-   Other authoritative servers return a response with erroneous response
-   codes other than RCODE 3 ("Name Error").  One such RCODE is 4 ("Not
-   Implemented"), indicating that the servers do not support the
-   requested type of query.
-
-   These cases are less harmful than the previous one; if the stub
-   resolver falls back to querying for an A RR, the caching server will
-   process the query correctly and return an appropriate response.
-
-   However, these can still cause a serious effect.  There was an
-   authoritative server implementation that returned RCODE 2 ("Server
-   failure") to queries for AAAA RRs.  One widely deployed mail server
-   implementation with a certain type of resolver library interpreted
-   this result as an indication of retry and did not fall back to
-   queries for A RRs, causing message delivery failure.
-
-   If the caching server receives a response with these response codes,
-   it does not cache the fact that the queried name has no AAAA RR,
-   resulting in redundant queries for AAAA RRs in the future.  The
-   behavior will waste network bandwidth and increase the load of the
-   authoritative server.
-
-   Using RCODE 1 ("Format error") would cause a similar effect, though
-   the authors have not seen such implementations yet.
-
-4.4.  Return a Broken Response
-
-   Another type of authoritative servers returns broken responses to
-   AAAA queries.  Returning a response whose RR type is AAAA with the
-   length of the RDATA being 4 bytes is a known behavior of this
-   category.  The 4-byte data looks like the IPv4 address of the queried
-   host name.
-
-
-
-
-
-
-
-Morishita & Jinmei           Informational                      [Page 3]
-
-RFC 4074         Common Misbehavior Against DNS Queries         May 2005
-
-
-   That is, the RR in the answer section would be described as follows:
-
-     www.bad.example. 600 IN AAAA 192.0.2.1
-
-   which is, of course, bogus (or at least meaningless).
-
-   A widely deployed caching server implementation transparently returns
-   the broken response (and caches it) to the stub resolver.  Another
-   known server implementation parses the response by itself, and sends
-   a separate response with RCODE 2 ("Server failure").
-
-   In either case, the broken response does not affect queries for an A
-   RR of the same name.  If the stub resolver falls back to A queries,
-   it will get an appropriate response.
-
-   The latter case, however, causes the same bad effect as that
-   described in the previous section: redundant queries for AAAA RRs.
-
-4.5.  Make Lame Delegation
-
-   Some authoritative servers respond to AAAA queries in a way that
-   causes lame delegation.  In this case, the parent zone specifies that
-   the authoritative server should have the authority of a zone, but the
-   server should not return an authoritative response for AAAA queries
-   within the zone (i.e., the AA bit in the response is not set).  On
-   the other hand, the authoritative server returns an authoritative
-   response for A queries.
-
-   When a caching server asks the server for AAAA RRs in the zone, it
-   recognizes the delegation is lame, and returns a response with RCODE
-   2 ("Server failure") to the stub resolver.
-
-   Furthermore, some caching servers record the authoritative server as
-   lame for the zone and will not use it for a certain period of time.
-   With this type of caching server, even if the stub resolver falls
-   back to querying for an A RR, the caching server will simply return a
-   response with RCODE 2, since all the servers are known to be "lame."
-
-   There is also an implementation that relaxes the behavior a little
-   bit.  It tries to avoid using the lame server, but continues to try
-   it as a last resort.  With this type of caching server, the stub
-   resolver will get a correct response if it falls back after Server
-   failure.  However, this still causes redundant AAAA queries, as
-   explained in the previous sections.
-
-
-
-
-
-
-
-Morishita & Jinmei           Informational                      [Page 4]
-
-RFC 4074         Common Misbehavior Against DNS Queries         May 2005
-
-
-5.  Security Considerations
-
-   The CERT/CC pointed out that the response with RCODE 3 ("Name
-   Error"), described in Section 4.2, can be used for a denial of
-   service attack [2].  The same argument applies to the case of "lame
-   delegation", described in Section 4.5, with a certain type of caching
-   server.
-
-6.  Acknowledgements
-
-   Erik Nordmark encouraged the authors to publish this document as an
-   RFC.  Akira Kato and Paul Vixie reviewed a preliminary version of
-   this document.  Pekka Savola carefully reviewed a previous version
-   and provided detailed comments.  Bill Fenner, Scott Hollenbeck,
-   Thomas Narten, and Alex Zinin reviewed and helped improve the
-   document at the last stage for publication.
-
-7.  Informative References
-
-   [1]  Mockapetris, P., "Domain names - concepts and facilities", STD
-        13, RFC 1034, November 1987.
-
-   [2]  The CERT Coordination Center, "Incorrect NXDOMAIN responses from
-        AAAA queries could cause denial-of-service conditions",
-        March 2003, <http://www.kb.cert.org/vuls/id/714121>.
-
-Authors' Addresses
-
-   MORISHITA Orange Yasuhiro
-   Research and Development Department, Japan Registry Services Co.,Ltd.
-   Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda
-   Chiyoda-ku, Tokyo  101-0065
-   Japan
-
-   EMail: yasuhiro@jprs.co.jp
-
-
-   JINMEI Tatuya
-   Corporate Research & Development Center, Toshiba Corporation
-   1 Komukai Toshiba-cho, Saiwai-ku
-   Kawasaki-shi, Kanagawa  212-8582
-   Japan
-
-   EMail: jinmei@isl.rdc.toshiba.co.jp
-
-
-
-
-
-
-
-Morishita & Jinmei           Informational                      [Page 5]
-
-RFC 4074         Common Misbehavior Against DNS Queries         May 2005
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2005).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Morishita & Jinmei           Informational                      [Page 6]
-
diff --git a/contrib/bind9/doc/rfc/rfc4159.txt b/contrib/bind9/doc/rfc/rfc4159.txt
deleted file mode 100644
index 1ab4bd1..0000000
--- a/contrib/bind9/doc/rfc/rfc4159.txt
+++ /dev/null
@@ -1,171 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          G. Huston
-Request for Comments: 4159                                         APNIC
-BCP: 109                                                     August 2005
-Category: Best Current Practice
-
-
-                        Deprecation of "ip6.int"
-
-Status of This Memo
-
-   This document specifies an Internet Best Current Practices for the
-   Internet Community, and requests discussion and suggestions for
-   improvements.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document advises of the deprecation of the use of "ip6.int" for
-   Standards Conformant IPv6 implementations.
-
-1.  IPv6 Standards Action
-
-   In August 2001 the IETF published [RFC3152], which advised that the
-   use of "ip6.int" as the domain for reverse-mapping of IPv6 addresses
-   to DNS names was deprecated.  The document noted that the use of
-   "ip6.int" would be phased out in an orderly fashion.
-
-   As of 1 September 2005, the IETF advises the community that the DNS
-   domain "ip6.int" should no longer be used to perform reverse mapping
-   of IPv6 addresses to domain names, and that the domain "ip6.arpa"
-   should be used henceforth, in accordance with the IANA Considerations
-   described in [RFC3596].  The domain "ip6.int" is deprecated, and its
-   use in IPv6 implementations that conform to the IPv6 Internet
-   Standards is discontinued.
-
-   The Regional Internet Registries (RIRs) are advised that maintenance
-   of delegation of entries in "ip6.int" is no longer required as part
-   of infrastructure services in support of Internet Standards
-   Conformant IPv6 implementations as of 1 September 2005.  The RIRs are
-   requested to work with their communities to adopt a schedule
-   regarding the cessation of support of registration services for the
-   "ip6.int" domain.
-
-
-
-
-
-
-Huston                   Best Current Practice                  [Page 1]
-
-RFC 4159                        ip6.int                      August 2005
-
-
-2.  IANA Considerations
-
-   IANA is advised that the "ip6.int" domain for reverse mapping of IPv6
-   addresses to domain names is no longer part of Internet Standards
-   Conformant support of IPv6 as of 1 September 2005.
-
-3.  Security Considerations
-
-   While DNS spoofing of address to name mapping has been exploited in
-   IPv4, removal of the "ip6.int" zone from the standard IPv6
-   specification creates no new threats to the security of the internet.
-
-4.  Acknowledgements
-
-   The document was prepared with the assistance of Kurt Lindqvist,
-   Thomas Narten, Paul Wilson, David Kessens, Bob Hinden, Brian
-   Haberman, and Bill Manning.
-
-5.  Normative References
-
-   [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152,
-             August 2001.
-
-   [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS
-             Extensions to Support IP Version 6", RFC 3596, October
-             2003.
-
-Author's Address
-
-   Geoff Huston
-   APNIC
-
-   EMail: gih@apnic.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Huston                   Best Current Practice                  [Page 2]
-
-RFC 4159                        ip6.int                      August 2005
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2005).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Huston                   Best Current Practice                  [Page 3]
-
diff --git a/contrib/bind9/doc/rfc/rfc4193.txt b/contrib/bind9/doc/rfc/rfc4193.txt
deleted file mode 100644
index 17e2c0b..0000000
--- a/contrib/bind9/doc/rfc/rfc4193.txt
+++ /dev/null
@@ -1,899 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          R. Hinden
-Request for Comments: 4193                                         Nokia
-Category: Standards Track                                    B. Haberman
-                                                                 JHU-APL
-                                                            October 2005
-
-
-                  Unique Local IPv6 Unicast Addresses
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document defines an IPv6 unicast address format that is globally
-   unique and is intended for local communications, usually inside of a
-   site.  These addresses are not expected to be routable on the global
-   Internet.
-
-Table of Contents
-
-   1. Introduction ....................................................2
-   2. Acknowledgements ................................................3
-   3. Local IPv6 Unicast Addresses ....................................3
-      3.1. Format .....................................................3
-           3.1.1. Background ..........................................4
-      3.2. Global ID ..................................................4
-           3.2.1. Locally Assigned Global IDs .........................5
-           3.2.2. Sample Code for Pseudo-Random Global ID Algorithm ...5
-           3.2.3. Analysis of the Uniqueness of Global IDs ............6
-      3.3. Scope Definition ...........................................6
-   4. Operational Guidelines ..........................................7
-      4.1. Routing ....................................................7
-      4.2. Renumbering and Site Merging ...............................7
-      4.3. Site Border Router and Firewall Packet Filtering ...........8
-      4.4. DNS Issues .................................................8
-      4.5. Application and Higher Level Protocol Issues ...............9
-      4.6. Use of Local IPv6 Addresses for Local Communication ........9
-      4.7. Use of Local IPv6 Addresses with VPNs .....................10
-
-
-
-Hinden & Haberman           Standards Track                     [Page 1]
-
-RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
-
-
-   5. Global Routing Considerations ..................................11
-      5.1. From the Standpoint of the Internet .......................11
-      5.2. From the Standpoint of a Site .............................11
-   6. Advantages and Disadvantages ...................................12
-      6.1. Advantages ................................................12
-      6.2. Disadvantages .............................................13
-   7. Security Considerations ........................................13
-   8. IANA Considerations ............................................13
-   9. References .....................................................13
-      9.1. Normative References ......................................13
-      9.2. Informative References ....................................14
-
-1.  Introduction
-
-   This document defines an IPv6 unicast address format that is globally
-   unique and is intended for local communications [IPV6].  These
-   addresses are called Unique Local IPv6 Unicast Addresses and are
-   abbreviated in this document as Local IPv6 addresses.  They are not
-   expected to be routable on the global Internet.  They are routable
-   inside of a more limited area such as a site.  They may also be
-   routed between a limited set of sites.
-
-   Local IPv6 unicast addresses have the following characteristics:
-
-      - Globally unique prefix (with high probability of uniqueness).
-
-      - Well-known prefix to allow for easy filtering at site
-        boundaries.
-
-      - Allow sites to be combined or privately interconnected without
-        creating any address conflicts or requiring renumbering of
-        interfaces that use these prefixes.
-
-      - Internet Service Provider independent and can be used for
-        communications inside of a site without having any permanent or
-        intermittent Internet connectivity.
-
-      - If accidentally leaked outside of a site via routing or DNS,
-        there is no conflict with any other addresses.
-
-      - In practice, applications may treat these addresses like global
-        scoped addresses.
-
-   This document defines the format of Local IPv6 addresses, how to
-   allocate them, and usage considerations including routing, site
-   border routers, DNS, application support, VPN usage, and guidelines
-   for how to use for local communication inside a site.
-
-
-
-
-Hinden & Haberman           Standards Track                     [Page 2]
-
-RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
-
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-2.  Acknowledgements
-
-   The underlying idea of creating Local IPv6 addresses described in
-   this document has been proposed a number of times by a variety of
-   people.  The authors of this document do not claim exclusive credit.
-   Credit goes to Brian Carpenter, Christian Huitema, Aidan Williams,
-   Andrew White, Charlie Perkins, and many others.  The authors would
-   also like to thank Brian Carpenter, Charlie Perkins, Harald
-   Alvestrand, Keith Moore, Margaret Wasserman, Shannon Behrens, Alan
-   Beard, Hans Kruse, Geoff Huston, Pekka Savola, Christian Huitema, Tim
-   Chown, Steve Bellovin, Alex Zinin, Tony Hain, Bill Fenner, Sam
-   Hartman, and Elwyn Davies for their comments and suggestions on this
-   document.
-
-3.  Local IPv6 Unicast Addresses
-
-3.1.  Format
-
-   The Local IPv6 addresses are created using a pseudo-randomly
-   allocated global ID.  They have the following format:
-
-      | 7 bits |1|  40 bits   |  16 bits  |          64 bits           |
-      +--------+-+------------+-----------+----------------------------+
-      | Prefix |L| Global ID  | Subnet ID |        Interface ID        |
-      +--------+-+------------+-----------+----------------------------+
-
-   Where:
-
-      Prefix            FC00::/7 prefix to identify Local IPv6 unicast
-                        addresses.
-
-      L                 Set to 1 if the prefix is locally assigned.
-                        Set to 0 may be defined in the future.  See
-                        Section 3.2 for additional information.
-
-      Global ID         40-bit global identifier used to create a
-                        globally unique prefix.  See Section 3.2 for
-                        additional information.
-
-      Subnet ID         16-bit Subnet ID is an identifier of a subnet
-                        within the site.
-
-      Interface ID      64-bit Interface ID as defined in [ADDARCH].
-
-
-
-
-Hinden & Haberman           Standards Track                     [Page 3]
-
-RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
-
-
-3.1.1.  Background
-
-   There were a range of choices available when choosing the size of the
-   prefix and Global ID field length.  There is a direct tradeoff
-   between having a Global ID field large enough to support foreseeable
-   future growth and not using too much of the IPv6 address space
-   needlessly.  A reasonable way of evaluating a specific field length
-   is to compare it to a projected 2050 world population of 9.3 billion
-   [POPUL] and the number of resulting /48 prefixes per person.  A range
-   of prefix choices is shown in the following table:
-
-    Prefix  Global ID     Number of          Prefixes    % of IPv6
-            Length        /48 Prefixes       per Person  Address Space
-
-    /11       37           137,438,953,472     15         0.049%
-    /10       38           274,877,906,944     30         0.098%
-    /9        39           549,755,813,888     59         0.195%
-    /8        40         1,099,511,627,776    118         0.391%
-    /7        41         2,199,023,255,552    236         0.781%
-    /6        42         4,398,046,511,104    473         1.563%
-
-   A very high utilization ratio of these allocations can be assumed
-   because the Global ID field does not require internal structure, and
-   there is no reason to be able to aggregate the prefixes.
-
-   The authors believe that a /7 prefix resulting in a 41-bit Global ID
-   space (including the L bit) is a good choice.  It provides for a
-   large number of assignments (i.e., 2.2 trillion) and at the same time
-   uses less than .8% of the total IPv6 address space.  It is unlikely
-   that this space will be exhausted.  If more than this were to be
-   needed, then additional IPv6 address space could be allocated for
-   this purpose.
-
-3.2.  Global ID
-
-   The allocation of Global IDs is pseudo-random [RANDOM].  They MUST
-   NOT be assigned sequentially or with well-known numbers.  This is to
-   ensure that there is not any relationship between allocations and to
-   help clarify that these prefixes are not intended to be routed
-   globally.  Specifically, these prefixes are not designed to
-   aggregate.
-
-   This document defines a specific local method to allocate Global IDs,
-   indicated by setting the L bit to 1.  Another method, indicated by
-   clearing the L bit, may be defined later.  Apart from the allocation
-   method, all Local IPv6 addresses behave and are treated identically.
-
-
-
-
-
-Hinden & Haberman           Standards Track                     [Page 4]
-
-RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
-
-
-   The local assignments are self-generated and do not need any central
-   coordination or assignment, but have an extremely high probability of
-   being unique.
-
-3.2.1.  Locally Assigned Global IDs
-
-   Locally assigned Global IDs MUST be generated with a pseudo-random
-   algorithm consistent with [RANDOM].  Section 3.2.2 describes a
-   suggested algorithm.  It is important that all sites generating
-   Global IDs use a functionally similar algorithm to ensure there is a
-   high probability of uniqueness.
-
-   The use of a pseudo-random algorithm to generate Global IDs in the
-   locally assigned prefix gives an assurance that any network numbered
-   using such a prefix is highly unlikely to have that address space
-   clash with any other network that has another locally assigned prefix
-   allocated to it.  This is a particularly useful property when
-   considering a number of scenarios including networks that merge,
-   overlapping VPN address space, or hosts mobile between such networks.
-
-3.2.2.  Sample Code for Pseudo-Random Global ID Algorithm
-
-   The algorithm described below is intended to be used for locally
-   assigned Global IDs.  In each case the resulting global ID will be
-   used in the appropriate prefix as defined in Section 3.2.
-
-     1) Obtain the current time of day in 64-bit NTP format [NTP].
-
-     2) Obtain an EUI-64 identifier from the system running this
-        algorithm.  If an EUI-64 does not exist, one can be created from
-        a 48-bit MAC address as specified in [ADDARCH].  If an EUI-64
-        cannot be obtained or created, a suitably unique identifier,
-        local to the node, should be used (e.g., system serial number).
-
-     3) Concatenate the time of day with the system-specific identifier
-        in order to create a key.
-
-     4) Compute an SHA-1 digest on the key as specified in [FIPS, SHA1];
-        the resulting value is 160 bits.
-
-     5) Use the least significant 40 bits as the Global ID.
-
-     6) Concatenate FC00::/7, the L bit set to 1, and the 40-bit Global
-        ID to create a Local IPv6 address prefix.
-
-   This algorithm will result in a Global ID that is reasonably unique
-   and can be used to create a locally assigned Local IPv6 address
-   prefix.
-
-
-
-Hinden & Haberman           Standards Track                     [Page 5]
-
-RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
-
-
-3.2.3.  Analysis of the Uniqueness of Global IDs
-
-   The selection of a pseudo random Global ID is similar to the
-   selection of an SSRC identifier in RTP/RTCP defined in Section 8.1 of
-   [RTP].  This analysis is adapted from that document.
-
-   Since Global IDs are chosen randomly (and independently), it is
-   possible that separate networks have chosen the same Global ID.  For
-   any given network, with one or more random Global IDs, that has
-   inter-connections to other such networks, having a total of N such
-   IDs, the probability that two or more of these IDs will collide can
-   be approximated using the formula:
-
-      P = 1 - exp(-N**2 / 2**(L+1))
-
-   where P is the probability of collision, N is the number of
-   interconnected Global IDs, and L is the length of the Global ID.
-
-   The following table shows the probability of a collision for a range
-   of connections using a 40-bit Global ID field.
-
-      Connections      Probability of Collision
-
-          2                1.81*10^-12
-         10                4.54*10^-11
-        100                4.54*10^-09
-       1000                4.54*10^-07
-      10000                4.54*10^-05
-
-   Based on this analysis, the uniqueness of locally generated Global
-   IDs is adequate for sites planning a small to moderate amount of
-   inter-site communication using locally generated Global IDs.
-
-3.3.  Scope Definition
-
-   By default, the scope of these addresses is global.  That is, they
-   are not limited by ambiguity like the site-local addresses defined in
-   [ADDARCH].  Rather, these prefixes are globally unique, and as such,
-   their applicability is greater than site-local addresses.  Their
-   limitation is in the routability of the prefixes, which is limited to
-   a site and any explicit routing agreements with other sites to
-   propagate them (also see Section 4.1).  Also, unlike site-locals, a
-   site may have more than one of these prefixes and use them at the
-   same time.
-
-
-
-
-
-
-
-Hinden & Haberman           Standards Track                     [Page 6]
-
-RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
-
-
-4.  Operational Guidelines
-
-   The guidelines in this section do not require any change to the
-   normal routing and forwarding functionality in an IPv6 host or
-   router.  These are configuration and operational usage guidelines.
-
-4.1.  Routing
-
-   Local IPv6 addresses are designed to be routed inside of a site in
-   the same manner as other types of unicast addresses.  They can be
-   carried in any IPv6 routing protocol without any change.
-
-   It is expected that they would share the same Subnet IDs with
-   provider-based global unicast addresses, if they were being used
-   concurrently [GLOBAL].
-
-   The default behavior of exterior routing protocol sessions between
-   administrative routing regions must be to ignore receipt of and not
-   advertise prefixes in the FC00::/7 block.  A network operator may
-   specifically configure prefixes longer than FC00::/7 for inter-site
-   communication.
-
-   If BGP is being used at the site border with an ISP, the default BGP
-   configuration must filter out any Local IPv6 address prefixes, both
-   incoming and outgoing.  It must be set both to keep any Local IPv6
-   address prefixes from being advertised outside of the site as well as
-   to keep these prefixes from being learned from another site.  The
-   exception to this is if there are specific /48 or longer routes
-   created for one or more Local IPv6 prefixes.
-
-   For link-state IGPs, it is suggested that a site utilizing IPv6 local
-   address prefixes be contained within one IGP domain or area.  By
-   containing an IPv6 local address prefix to a single link-state area
-   or domain, the distribution of prefixes can be controlled.
-
-4.2.  Renumbering and Site Merging
-
-   The use of Local IPv6 addresses in a site results in making
-   communication that uses these addresses independent of renumbering a
-   site's provider-based global addresses.
-
-   When merging multiple sites, the addresses created with these
-   prefixes are unlikely to need to be renumbered because all of the
-   addresses have a high probability of being unique.  Routes for each
-   specific prefix would have to be configured to allow routing to work
-   correctly between the formerly separate sites.
-
-
-
-
-
-Hinden & Haberman           Standards Track                     [Page 7]
-
-RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
-
-
-4.3.  Site Border Router and Firewall Packet Filtering
-
-   While no serious harm will be done if packets with these addresses
-   are sent outside of a site via a default route, it is recommended
-   that routers be configured by default to keep any packets with Local
-   IPv6 addresses from leaking outside of the site and to keep any site
-   prefixes from being advertised outside of their site.
-
-   Site border routers and firewalls should be configured to not forward
-   any packets with Local IPv6 source or destination addresses outside
-   of the site, unless they have been explicitly configured with routing
-   information about specific /48 or longer Local IPv6 prefixes.  This
-   will ensure that packets with Local IPv6 destination addresses will
-   not be forwarded outside of the site via a default route.  The
-   default behavior of these devices should be to install a "reject"
-   route for these prefixes.  Site border routers should respond with
-   the appropriate ICMPv6 Destination Unreachable message to inform the
-   source that the packet was not forwarded. [ICMPV6].  This feedback is
-   important to avoid transport protocol timeouts.
-
-   Routers that maintain peering arrangements between Autonomous Systems
-   throughout the Internet should obey the recommendations for site
-   border routers, unless configured otherwise.
-
-4.4.  DNS Issues
-
-   At the present time, AAAA and PTR records for locally assigned local
-   IPv6 addresses are not recommended to be installed in the global DNS.
-
-   For background on this recommendation, one of the concerns about
-   adding AAAA and PTR records to the global DNS for locally assigned
-   Local IPv6 addresses stems from the lack of complete assurance that
-   the prefixes are unique.  There is a small possibility that the same
-   locally assigned IPv6 Local addresses will be used by two different
-   organizations both claiming to be authoritative with different
-   contents.  In this scenario, it is likely there will be a connection
-   attempt to the closest host with the corresponding locally assigned
-   IPv6 Local address.  This may result in connection timeouts,
-   connection failures indicated by ICMP Destination Unreachable
-   messages, or successful connections to the wrong host.  Due to this
-   concern, adding AAAA records for these addresses to the global DNS is
-   thought to be unwise.
-
-   Reverse (address-to-name) queries for locally assigned IPv6 Local
-   addresses MUST NOT be sent to name servers for the global DNS, due to
-   the load that such queries would create for the authoritative name
-   servers for the ip6.arpa zone.  This form of query load is not
-   specific to locally assigned Local IPv6 addresses; any current form
-
-
-
-Hinden & Haberman           Standards Track                     [Page 8]
-
-RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
-
-
-   of local addressing creates additional load of this kind, due to
-   reverse queries leaking out of the site.  However, since allowing
-   such queries to escape from the site serves no useful purpose, there
-   is no good reason to make the existing load problems worse.
-
-   The recommended way to avoid sending such queries to nameservers for
-   the global DNS is for recursive name server implementations to act as
-   if they were authoritative for an empty d.f.ip6.arpa zone and return
-   RCODE 3 for any such query.  Implementations that choose this
-   strategy should allow it to be overridden, but returning an RCODE 3
-   response for such queries should be the default, both because this
-   will reduce the query load problem and also because, if the site
-   administrator has not set up the reverse tree corresponding to the
-   locally assigned IPv6 Local addresses in use, returning RCODE 3 is in
-   fact the correct answer.
-
-4.5.  Application and Higher Level Protocol Issues
-
-   Application and other higher level protocols can treat Local IPv6
-   addresses in the same manner as other types of global unicast
-   addresses.  No special handling is required.  This type of address
-   may not be reachable, but that is no different from other types of
-   IPv6 global unicast address.  Applications need to be able to handle
-   multiple addresses that may or may not be reachable at any point in
-   time.  In most cases, this complexity should be hidden in APIs.
-
-   From a host's perspective, the difference between Local IPv6 and
-   other types of global unicast addresses shows up as different
-   reachability and could be handled by default in that way.  In some
-   cases, it is better for nodes and applications to treat them
-   differently from global unicast addresses.  A starting point might be
-   to give them preference over global unicast, but fall back to global
-   unicast if a particular destination is found to be unreachable.  Much
-   of this behavior can be controlled by how they are allocated to nodes
-   and put into the DNS.  However, it is useful if a host can have both
-   types of addresses and use them appropriately.
-
-   Note that the address selection mechanisms of [ADDSEL], and in
-   particular the policy override mechanism replacing default address
-   selection, are expected to be used on a site where Local IPv6
-   addresses are configured.
-
-4.6.  Use of Local IPv6 Addresses for Local Communication
-
-   Local IPv6 addresses, like global scope unicast addresses, are only
-   assigned to nodes if their use has been enabled (via IPv6 address
-   autoconfiguration [ADDAUTO], DHCPv6 [DHCP6], or manually).  They are
-
-
-
-
-Hinden & Haberman           Standards Track                     [Page 9]
-
-RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
-
-
-   not created automatically in the way that IPv6 link-local addresses
-   are and will not appear or be used unless they are purposely
-   configured.
-
-   In order for hosts to autoconfigure Local IPv6 addresses, routers
-   have to be configured to advertise Local IPv6 /64 prefixes in router
-   advertisements, or a DHCPv6 server must have been configured to
-   assign them.  In order for a node to learn the Local IPv6 address of
-   another node, the Local IPv6 address must have been installed in a
-   naming system (e.g., DNS, proprietary naming system, etc.)  For these
-   reasons, controlling their usage in a site is straightforward.
-
-   To limit the use of Local IPv6 addresses the following guidelines
-   apply:
-
-      - Nodes that are to only be reachable inside of a site:  The local
-        DNS should be configured to only include the Local IPv6
-        addresses of these nodes.  Nodes with only Local IPv6 addresses
-        must not be installed in the global DNS.
-
-      - Nodes that are to be limited to only communicate with other
-        nodes in the site:  These nodes should be set to only
-        autoconfigure Local IPv6 addresses via [ADDAUTO] or to only
-        receive Local IPv6 addresses via [DHCP6].  Note: For the case
-        where both global and Local IPv6 prefixes are being advertised
-        on a subnet, this will require a switch in the devices to only
-        autoconfigure Local IPv6 addresses.
-
-      - Nodes that are to be reachable from inside of the site and from
-        outside of the site:  The DNS should be configured to include
-        the global addresses of these nodes.  The local DNS may be
-        configured to also include the Local IPv6 addresses of these
-        nodes.
-
-      - Nodes that can communicate with other nodes inside of the site
-        and outside of the site: These nodes should autoconfigure global
-        addresses via [ADDAUTO] or receive global address via [DHCP6].
-        They may also obtain Local IPv6 addresses via the same
-        mechanisms.
-
-4.7.  Use of Local IPv6 Addresses with VPNs
-
-   Local IPv6 addresses can be used for inter-site Virtual Private
-   Networks (VPN) if appropriate routes are set up.  Because the
-   addresses are unique, these VPNs will work reliably and without the
-   need for translation.  They have the additional property that they
-   will continue to work if the individual sites are renumbered or
-   merged.
-
-
-
-Hinden & Haberman           Standards Track                    [Page 10]
-
-RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
-
-
-5.  Global Routing Considerations
-
-   Section 4.1 provides operational guidelines that forbid default
-   routing of local addresses between sites.  Concerns were raised to
-   the IPv6 working group and to the IETF as a whole that sites may
-   attempt to use local addresses as globally routed provider-
-   independent addresses.  This section describes why using local
-   addresses as globally-routed provider-independent addresses is
-   unadvisable.
-
-5.1.  From the Standpoint of the Internet
-
-   There is a mismatch between the structure of IPv6 local addresses and
-   the normal IPv6 wide area routing model.  The /48 prefix of an IPv6
-   local addresses fits nowhere in the normal hierarchy of IPv6 unicast
-   addresses.  Normal IPv6 unicast addresses can be routed
-   hierarchically down to physical subnet (link) level and only have to
-   be flat-routed on the physical subnet.  IPv6 local addresses would
-   have to be flat-routed even over the wide area Internet.
-
-   Thus, packets whose destination address is an IPv6 local address
-   could be routed over the wide area only if the corresponding /48
-   prefix were carried by the wide area routing protocol in use, such as
-   BGP.  This contravenes the operational assumption that long prefixes
-   will be aggregated into many fewer short prefixes, to limit the table
-   size and convergence time of the routing protocol.  If a network uses
-   both normal IPv6 addresses [ADDARCH] and IPv6 local addresses, these
-   types of addresses will certainly not aggregate with each other,
-   since they differ from the most significant bit onwards.  Neither
-   will IPv6 local addresses aggregate with each other, due to their
-   random bit patterns.  This means that there would be a very
-   significant operational penalty for attempting to use IPv6 local
-   address prefixes generically with currently known wide area routing
-   technology.
-
-5.2.  From the Standpoint of a Site
-
-   There are a number of design factors in IPv6 local addresses that
-   reduce the likelihood that IPv6 local addresses will be used as
-   arbitrary global unicast addresses.  These include:
-
-      - The default rules to filter packets and routes make it very
-        difficult to use IPv6 local addresses for arbitrary use across
-        the Internet.  For a site to use them as general purpose unicast
-        addresses, it would have to make sure that the default rules
-        were not being used by all other sites and intermediate ISPs
-        used for their current and future communication.
-
-
-
-
-Hinden & Haberman           Standards Track                    [Page 11]
-
-RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
-
-
-      - They are not mathematically guaranteed to be unique and are not
-        registered in public databases.  Collisions, while highly
-        unlikely, are possible and a collision can compromise the
-        integrity of the communications.  The lack of public
-        registration creates operational problems.
-
-      - The addresses are allocated randomly.  If a site had multiple
-        prefixes that it wanted to be used globally, the cost of
-        advertising them would be very high because they could not be
-        aggregated.
-
-      - They have a long prefix (i.e., /48) so a single local address
-        prefix doesn't provide enough address space to be used
-        exclusively by the largest organizations.
-
-6.  Advantages and Disadvantages
-
-6.1.  Advantages
-
-   This approach has the following advantages:
-
-      - Provides Local IPv6 prefixes that can be used independently of
-        any provider-based IPv6 unicast address allocations.  This is
-        useful for sites not always connected to the Internet or sites
-        that wish to have a distinct prefix that can be used to localize
-        traffic inside of the site.
-
-      - Applications can treat these addresses in an identical manner as
-        any other type of global IPv6 unicast addresses.
-
-      - Sites can be merged without any renumbering of the Local IPv6
-        addresses.
-
-      - Sites can change their provider-based IPv6 unicast address
-        without disrupting any communication that uses Local IPv6
-        addresses.
-
-      - Well-known prefix that allows for easy filtering at site
-        boundary.
-
-      - Can be used for inter-site VPNs.
-
-      - If accidently leaked outside of a site via routing or DNS, there
-        is no conflict with any other addresses.
-
-
-
-
-
-
-
-Hinden & Haberman           Standards Track                    [Page 12]
-
-RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
-
-
-6.2.  Disadvantages
-
-   This approach has the following disadvantages:
-
-      - Not possible to route Local IPv6 prefixes on the global Internet
-        with current routing technology.  Consequentially, it is
-        necessary to have the default behavior of site border routers to
-        filter these addresses.
-
-      - There is a very low probability of non-unique locally assigned
-        Global IDs being generated by the algorithm in Section 3.2.3.
-        This risk can be ignored for all practical purposes, but it
-        leads to a theoretical risk of clashing address prefixes.
-
-7.  Security Considerations
-
-   Local IPv6 addresses do not provide any inherent security to the
-   nodes that use them.  They may be used with filters at site
-   boundaries to keep Local IPv6 traffic inside of the site, but this is
-   no more or less secure than filtering any other type of global IPv6
-   unicast addresses.
-
-   Local IPv6 addresses do allow for address-based security mechanisms,
-   including IPsec, across end to end VPN connections.
-
-8.  IANA Considerations
-
-   The IANA has assigned the FC00::/7 prefix to "Unique Local Unicast".
-
-9.  References
-
-9.1.  Normative References
-
-   [ADDARCH]  Hinden, R. and S. Deering, "Internet Protocol Version 6
-             (IPv6) Addressing Architecture", RFC 3513, April 2003.
-
-   [FIPS]    "Federal Information Processing Standards Publication",
-             (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995.
-
-   [GLOBAL]  Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
-             Unicast Address Format", RFC 3587, August 2003.
-
-   [ICMPV6]  Conta, A. and S. Deering, "Internet Control Message
-             Protocol (ICMPv6) for the Internet Protocol Version 6
-             (IPv6) Specification", RFC 2463, December 1998.
-
-
-
-
-
-
-Hinden & Haberman           Standards Track                    [Page 13]
-
-RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
-
-
-   [IPV6]    Deering, S. and R. Hinden, "Internet Protocol, Version 6
-             (IPv6) Specification", RFC 2460, December 1998.
-
-   [NTP]     Mills, D., "Network Time Protocol (Version 3)
-             Specification, Implementation and Analysis", RFC 1305,
-             March 1992.
-
-   [RANDOM]  Eastlake, D., 3rd, Schiller, J., and S. Crocker,
-             "Randomness Requirements for Security", BCP 106, RFC 4086,
-             June 2005.
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [SHA1]    Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
-             (SHA1)", RFC 3174, September 2001.
-
-9.2.  Informative References
-
-   [ADDAUTO] Thomson, S. and T. Narten, "IPv6 Stateless Address
-             Autoconfiguration", RFC 2462, December 1998.
-
-   [ADDSEL]  Draves, R., "Default Address Selection for Internet
-             Protocol version 6 (IPv6)", RFC 3484, February 2003.
-
-   [DHCP6]   Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and
-             M. Carney, "Dynamic Host Configuration Protocol for IPv6
-             (DHCPv6)", RFC 3315, July 2003.
-
-   [POPUL]   Population Reference Bureau, "World Population Data Sheet
-             of the Population Reference Bureau 2002",  August 2002.
-
-   [RTP]     Schulzrinne, H.,  Casner, S., Frederick, R., and V.
-             Jacobson, "RTP: A Transport Protocol for Real-Time
-             Applications", STD 64, RFC 3550, July 2003.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Haberman           Standards Track                    [Page 14]
-
-RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
-
-
-Authors' Addresses
-
-   Robert M. Hinden
-   Nokia
-   313 Fairchild Drive
-   Mountain View, CA 94043
-   USA
-
-   Phone: +1 650 625-2004
-   EMail: bob.hinden@nokia.com
-
-
-   Brian Haberman
-   Johns Hopkins University
-   Applied Physics Lab
-   11100 Johns Hopkins Road
-   Laurel, MD 20723
-   USA
-
-   Phone: +1 443 778 1319
-   EMail: brian@innovationslab.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Haberman           Standards Track                    [Page 15]
-
-RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2005).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Hinden & Haberman           Standards Track                    [Page 16]
-
diff --git a/contrib/bind9/doc/rfc/rfc4255.txt b/contrib/bind9/doc/rfc/rfc4255.txt
deleted file mode 100644
index f350b7a..0000000
--- a/contrib/bind9/doc/rfc/rfc4255.txt
+++ /dev/null
@@ -1,507 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        J. Schlyter
-Request for Comments: 4255                                       OpenSSH
-Category: Standards Track                                     W. Griffin
-                                                                  SPARTA
-                                                            January 2006
-
-
-   Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document describes a method of verifying Secure Shell (SSH) host
-   keys using Domain Name System Security (DNSSEC).  The document
-   defines a new DNS resource record that contains a standard SSH key
-   fingerprint.
-
-Table of Contents
-
-   1. Introduction ....................................................2
-   2. SSH Host Key Verification .......................................2
-      2.1. Method .....................................................2
-      2.2. Implementation Notes .......................................2
-      2.3. Fingerprint Matching .......................................3
-      2.4. Authentication .............................................3
-   3. The SSHFP Resource Record .......................................3
-      3.1. The SSHFP RDATA Format .....................................4
-           3.1.1. Algorithm Number Specification ......................4
-           3.1.2. Fingerprint Type Specification ......................4
-           3.1.3. Fingerprint .........................................5
-      3.2. Presentation Format of the SSHFP RR ........................5
-   4. Security Considerations .........................................5
-   5. IANA Considerations .............................................6
-   6. Normative References ............................................7
-   7. Informational References ........................................7
-   8. Acknowledgements ................................................8
-
-
-
-
-Schlyter & Griffin          Standards Track                     [Page 1]
-
-RFC 4255                DNS and SSH Fingerprints            January 2006
-
-
-1.  Introduction
-
-   The SSH [6] protocol provides secure remote login and other secure
-   network services over an insecure network.  The security of the
-   connection relies on the server authenticating itself to the client
-   as well as the user authenticating itself to the server.
-
-   If a connection is established to a server whose public key is not
-   already known to the client, a fingerprint of the key is presented to
-   the user for verification.  If the user decides that the fingerprint
-   is correct and accepts the key, the key is saved locally and used for
-   verification for all following connections.  While some security-
-   conscious users verify the fingerprint out-of-band before accepting
-   the key, many users blindly accept the presented key.
-
-   The method described here can provide out-of-band verification by
-   looking up a fingerprint of the server public key in the DNS [1][2]
-   and using DNSSEC [5] to verify the lookup.
-
-   In order to distribute the fingerprint using DNS, this document
-   defines a new DNS resource record, "SSHFP", to carry the fingerprint.
-
-   Basic understanding of the DNS system [1][2] and the DNS security
-   extensions [5] is assumed by this document.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [3].
-
-2.  SSH Host Key Verification
-
-2.1.  Method
-
-   Upon connection to an SSH server, the SSH client MAY look up the
-   SSHFP resource record(s) for the host it is connecting to.  If the
-   algorithm and fingerprint of the key received from the SSH server
-   match the algorithm and fingerprint of one of the SSHFP resource
-   record(s) returned from DNS, the client MAY accept the identity of
-   the server.
-
-2.2.  Implementation Notes
-
-   Client implementors SHOULD provide a configurable policy used to
-   select the order of methods used to verify a host key.  This document
-   defines one method: Fingerprint storage in DNS.  Another method
-   defined in the SSH Architecture [6] uses local files to store keys
-   for comparison.  Other methods that could be defined in the future
-   might include storing fingerprints in LDAP or other databases.  A
-
-
-
-Schlyter & Griffin          Standards Track                     [Page 2]
-
-RFC 4255                DNS and SSH Fingerprints            January 2006
-
-
-   configurable policy will allow administrators to determine which
-   methods they want to use and in what order the methods should be
-   prioritized.  This will allow administrators to determine how much
-   trust they want to place in the different methods.
-
-   One specific scenario for having a configurable policy is where
-   clients do not use fully qualified host names to connect to servers.
-   In this scenario, the implementation SHOULD verify the host key
-   against a local database before verifying the key via the fingerprint
-   returned from DNS.  This would help prevent an attacker from
-   injecting a DNS search path into the local resolver and forcing the
-   client to connect to a different host.
-
-2.3.  Fingerprint Matching
-
-   The public key and the SSHFP resource record are matched together by
-   comparing algorithm number and fingerprint.
-
-      The public key algorithm and the SSHFP algorithm number MUST
-      match.
-
-      A message digest of the public key, using the message digest
-      algorithm specified in the SSHFP fingerprint type, MUST match the
-      SSHFP fingerprint.
-
-2.4.  Authentication
-
-   A public key verified using this method MUST NOT be trusted if the
-   SSHFP resource record (RR) used for verification was not
-   authenticated by a trusted SIG RR.
-
-   Clients that do validate the DNSSEC signatures themselves SHOULD use
-   standard DNSSEC validation procedures.
-
-   Clients that do not validate the DNSSEC signatures themselves MUST
-   use a secure transport (e.g., TSIG [9], SIG(0) [10], or IPsec [8])
-   between themselves and the entity performing the signature
-   validation.
-
-3.  The SSHFP Resource Record
-
-   The SSHFP resource record (RR) is used to store a fingerprint of an
-   SSH public host key that is associated with a Domain Name System
-   (DNS) name.
-
-   The RR type code for the SSHFP RR is 44.
-
-
-
-
-
-Schlyter & Griffin          Standards Track                     [Page 3]
-
-RFC 4255                DNS and SSH Fingerprints            January 2006
-
-
-3.1.  The SSHFP RDATA Format
-
-   The RDATA for a SSHFP RR consists of an algorithm number, fingerprint
-   type and the fingerprint of the public host key.
-
-       1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |   algorithm   |    fp type    |                               /
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               /
-       /                                                               /
-       /                          fingerprint                          /
-       /                                                               /
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-3.1.1.  Algorithm Number Specification
-
-   This algorithm number octet describes the algorithm of the public
-   key.  The following values are assigned:
-
-          Value    Algorithm name
-          -----    --------------
-          0        reserved
-          1        RSA
-          2        DSS
-
-   Reserving other types requires IETF consensus [4].
-
-3.1.2.  Fingerprint Type Specification
-
-   The fingerprint type octet describes the message-digest algorithm
-   used to calculate the fingerprint of the public key.  The following
-   values are assigned:
-
-          Value    Fingerprint type
-          -----    ----------------
-          0        reserved
-          1        SHA-1
-
-   Reserving other types requires IETF consensus [4].
-
-   For interoperability reasons, as few fingerprint types as possible
-   should be reserved.  The only reason to reserve additional types is
-   to increase security.
-
-
-
-
-
-
-
-Schlyter & Griffin          Standards Track                     [Page 4]
-
-RFC 4255                DNS and SSH Fingerprints            January 2006
-
-
-3.1.3.  Fingerprint
-
-   The fingerprint is calculated over the public key blob as described
-   in [7].
-
-   The message-digest algorithm is presumed to produce an opaque octet
-   string output, which is placed as-is in the RDATA fingerprint field.
-
-3.2.  Presentation Format of the SSHFP RR
-
-   The RDATA of the presentation format of the SSHFP resource record
-   consists of two numbers (algorithm and fingerprint type) followed by
-   the fingerprint itself, presented in hex, e.g.:
-
-       host.example.  SSHFP 2 1 123456789abcdef67890123456789abcdef67890
-
-   The use of mnemonics instead of numbers is not allowed.
-
-4.  Security Considerations
-
-   Currently, the amount of trust a user can realistically place in a
-   server key is proportional to the amount of attention paid to
-   verifying that the public key presented actually corresponds to the
-   private key of the server.  If a user accepts a key without verifying
-   the fingerprint with something learned through a secured channel, the
-   connection is vulnerable to a man-in-the-middle attack.
-
-   The overall security of using SSHFP for SSH host key verification is
-   dependent on the security policies of the SSH host administrator and
-   DNS zone administrator (in transferring the fingerprint), detailed
-   aspects of how verification is done in the SSH implementation, and in
-   the client's diligence in accessing the DNS in a secure manner.
-
-   One such aspect is in which order fingerprints are looked up (e.g.,
-   first checking local file and then SSHFP).  We note that, in addition
-   to protecting the first-time transfer of host keys, SSHFP can
-   optionally be used for stronger host key protection.
-
-      If SSHFP is checked first, new SSH host keys may be distributed by
-      replacing the corresponding SSHFP in DNS.
-
-      If SSH host key verification can be configured to require SSHFP,
-      SSH host key revocation can be implemented by removing the
-      corresponding SSHFP from DNS.
-
-
-
-
-
-
-
-Schlyter & Griffin          Standards Track                     [Page 5]
-
-RFC 4255                DNS and SSH Fingerprints            January 2006
-
-
-   As stated in Section 2.2, we recommend that SSH implementors provide
-   a policy mechanism to control the order of methods used for host key
-   verification.  One specific scenario for having a configurable policy
-   is where clients use unqualified host names to connect to servers.
-   In this case, we recommend that SSH implementations check the host
-   key against a local database before verifying the key via the
-   fingerprint returned from DNS.  This would help prevent an attacker
-   from injecting a DNS search path into the local resolver and forcing
-   the client to connect to a different host.
-
-   A different approach to solve the DNS search path issue would be for
-   clients to use a trusted DNS search path, i.e., one not acquired
-   through DHCP or other autoconfiguration mechanisms.  Since there is
-   no way with current DNS lookup APIs to tell whether a search path is
-   from a trusted source, the entire client system would need to be
-   configured with this trusted DNS search path.
-
-   Another dependency is on the implementation of DNSSEC itself.  As
-   stated in Section 2.4, we mandate the use of secure methods for
-   lookup and that SSHFP RRs are authenticated by trusted SIG RRs.  This
-   is especially important if SSHFP is to be used as a basis for host
-   key rollover and/or revocation, as described above.
-
-   Since DNSSEC only protects the integrity of the host key fingerprint
-   after it is signed by the DNS zone administrator, the fingerprint
-   must be transferred securely from the SSH host administrator to the
-   DNS zone administrator.  This could be done manually between the
-   administrators or automatically using secure DNS dynamic update [11]
-   between the SSH server and the nameserver.  We note that this is no
-   different from other key enrollment situations, e.g., a client
-   sending a certificate request to a certificate authority for signing.
-
-5.  IANA Considerations
-
-   IANA has allocated the RR type code 44 for SSHFP from the standard RR
-   type space.
-
-   IANA has opened a new registry for the SSHFP RR type for public key
-   algorithms.  The defined types are:
-
-      0 is reserved
-      1 is RSA
-      2 is DSA
-
-   Adding new reservations requires IETF consensus [4].
-
-
-
-
-
-
-Schlyter & Griffin          Standards Track                     [Page 6]
-
-RFC 4255                DNS and SSH Fingerprints            January 2006
-
-
-   IANA has opened a new registry for the SSHFP RR type for fingerprint
-   types.  The defined types are:
-
-      0 is reserved
-      1 is SHA-1
-
-   Adding new reservations requires IETF consensus [4].
-
-6.  Normative References
-
-   [1]   Mockapetris, P., "Domain names - concepts and facilities", STD
-         13, RFC 1034, November 1987.
-
-   [2]   Mockapetris, P., "Domain names - implementation and
-         specification", STD 13, RFC 1035, November 1987.
-
-   [3]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
-         Levels", BCP 14, RFC 2119, March 1997.
-
-   [4]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
-         Considerations Section in RFCs", BCP 26, RFC 2434, October
-         1998.
-
-   [5]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "DNS Security Introduction and Requirements", RFC 4033, March
-         2005.
-
-         Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "Resource Records for the DNS Security Extensions", RFC 4034,
-         March 2005.
-
-         Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "Protocol Modifications for the DNS Security Extensions", RFC
-         4035, March 2005.
-
-   [6]   Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
-         Protocol Architecture", RFC 4251, January 2006.
-
-   [7]   Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
-         Transport Layer Protocol", RFC 4253, January 2006.
-
-7.  Informational References
-
-   [8]   Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document
-         Roadmap", RFC 2411, November 1998.
-
-
-
-
-
-
-Schlyter & Griffin          Standards Track                     [Page 7]
-
-RFC 4255                DNS and SSH Fingerprints            January 2006
-
-
-   [9]   Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
-         Wellington, "Secret Key Transaction Authentication for DNS
-         (TSIG)", RFC 2845, May 2000.
-
-   [10]  Eastlake 3rd, D., "DNS Request and Transaction Signatures
-         ( SIG(0)s )", RFC 2931, September 2000.
-
-   [11]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
-         Update", RFC 3007, November 2000.
-
-8.  Acknowledgements
-
-   The authors gratefully acknowledge, in no particular order, the
-   contributions of the following persons:
-
-      Martin Fredriksson
-
-      Olafur Gudmundsson
-
-      Edward Lewis
-
-      Bill Sommerfeld
-
-Authors' Addresses
-
-   Jakob Schlyter
-   OpenSSH
-   812 23rd Avenue SE
-   Calgary, Alberta  T2G 1N8
-   Canada
-
-   EMail: jakob@openssh.com
-   URI:   http://www.openssh.com/
-
-
-   Wesley Griffin
-   SPARTA
-   7075 Samuel Morse Drive
-   Columbia, MD  21046
-   USA
-
-   EMail: wgriffin@sparta.com
-   URI:   http://www.sparta.com/
-
-
-
-
-
-
-
-
-Schlyter & Griffin          Standards Track                     [Page 8]
-
-RFC 4255                DNS and SSH Fingerprints            January 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Schlyter & Griffin          Standards Track                     [Page 9]
-
diff --git a/contrib/bind9/doc/rfc/rfc4343.txt b/contrib/bind9/doc/rfc/rfc4343.txt
deleted file mode 100644
index 621420a..0000000
--- a/contrib/bind9/doc/rfc/rfc4343.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                    D. Eastlake 3rd
-Request for Comments: 4343                         Motorola Laboratories
-Updates: 1034, 1035, 2181                                   January 2006
-Category: Standards Track
-
-
-       Domain Name System (DNS) Case Insensitivity Clarification
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   Domain Name System (DNS) names are "case insensitive".  This document
-   explains exactly what that means and provides a clear specification
-   of the rules.  This clarification updates RFCs 1034, 1035, and 2181.
-
-Table of Contents
-
-   1. Introduction ....................................................2
-   2. Case Insensitivity of DNS Labels ................................2
-      2.1. Escaping Unusual DNS Label Octets ..........................2
-      2.2. Example Labels with Escapes ................................3
-   3. Name Lookup, Label Types, and CLASS .............................3
-      3.1. Original DNS Label Types ...................................4
-      3.2. Extended Label Type Case Insensitivity Considerations ......4
-      3.3. CLASS Case Insensitivity Considerations ....................4
-   4. Case on Input and Output ........................................5
-      4.1. DNS Output Case Preservation ...............................5
-      4.2. DNS Input Case Preservation ................................5
-   5. Internationalized Domain Names ..................................6
-   6. Security Considerations .........................................6
-   7. Acknowledgements ................................................7
-   Normative References................................................7
-   Informative References..............................................8
-
-
-
-
-
-
-
-Eastlake 3rd                Standards Track                     [Page 1]
-
-RFC 4343          DNS Case Insensitivity Clarification      January 2006
-
-
-1.  Introduction
-
-   The Domain Name System (DNS) is the global hierarchical replicated
-   distributed database system for Internet addressing, mail proxy, and
-   other information.  Each node in the DNS tree has a name consisting
-   of zero or more labels [STD13, RFC1591, RFC2606] that are treated in
-   a case insensitive fashion.  This document clarifies the meaning of
-   "case insensitive" for the DNS.  This clarification updates RFCs
-   1034, 1035 [STD13], and [RFC2181].
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-2.  Case Insensitivity of DNS Labels
-
-   DNS was specified in the era of [ASCII].  DNS names were expected to
-   look like most host names or Internet email address right halves (the
-   part after the at-sign, "@") or to be numeric, as in the in-addr.arpa
-   part of the DNS name space.  For example,
-
-       foo.example.net.
-       aol.com.
-       www.gnu.ai.mit.edu.
-   or  69.2.0.192.in-addr.arpa.
-
-   Case-varied alternatives to the above [RFC3092] would be DNS names
-   like
-
-       Foo.ExamplE.net.
-       AOL.COM.
-       WWW.gnu.AI.mit.EDU.
-   or  69.2.0.192.in-ADDR.ARPA.
-
-   However, the individual octets of which DNS names consist are not
-   limited to valid ASCII character codes.  They are 8-bit bytes, and
-   all values are allowed.  Many applications, however, interpret them
-   as ASCII characters.
-
-2.1.  Escaping Unusual DNS Label Octets
-
-   In Master Files [STD13] and other human-readable and -writable ASCII
-   contexts, an escape is needed for the byte value for period (0x2E,
-   ".") and all octet values outside of the inclusive range from 0x21
-   ("!") to 0x7E ("~").  That is to say, 0x2E and all octet values in
-   the two inclusive ranges from 0x00 to 0x20 and from 0x7F to 0xFF.
-
-
-
-
-
-Eastlake 3rd                Standards Track                     [Page 2]
-
-RFC 4343          DNS Case Insensitivity Clarification      January 2006
-
-
-   One typographic convention for octets that do not correspond to an
-   ASCII printing graphic is to use a back-slash followed by the value
-   of the octet as an unsigned integer represented by exactly three
-   decimal digits.
-
-   The same convention can be used for printing ASCII characters so that
-   they will be treated as a normal label character.  This includes the
-   back-slash character used in this convention itself, which can be
-   expressed as \092 or \\, and the special label separator period
-   ("."), which can be expressed as and \046 or \.  It is advisable to
-   avoid using a backslash to quote an immediately following non-
-   printing ASCII character code to avoid implementation difficulties.
-
-   A back-slash followed by only one or two decimal digits is undefined.
-   A back-slash followed by four decimal digits produces two octets, the
-   first octet having the value of the first three digits considered as
-   a decimal number, and the second octet being the character code for
-   the fourth decimal digit.
-
-2.2.  Example Labels with Escapes
-
-   The first example below shows embedded spaces and a period (".")
-   within a label.  The second one shows a 5-octet label where the
-   second octet has all bits zero, the third is a backslash, and the
-   fourth octet has all bits one.
-
-         Donald\032E\.\032Eastlake\0323rd.example.
-   and   a\000\\\255z.example.
-
-3.  Name Lookup, Label Types, and CLASS
-
-   According to the original DNS design decision, comparisons on name
-   lookup for DNS queries should be case insensitive [STD13].  That is
-   to say, a lookup string octet with a value in the inclusive range
-   from 0x41 to 0x5A, the uppercase ASCII letters, MUST match the
-   identical value and also match the corresponding value in the
-   inclusive range from 0x61 to 0x7A, the lowercase ASCII letters.  A
-   lookup string octet with a lowercase ASCII letter value MUST
-   similarly match the identical value and also match the corresponding
-   value in the uppercase ASCII letter range.
-
-   (Historical note: The terms "uppercase" and "lowercase" were invented
-   after movable type.  The terms originally referred to the two font
-   trays for storing, in partitioned areas, the different physical type
-   elements.  Before movable type, the nearest equivalent terms were
-   "majuscule" and "minuscule".)
-
-
-
-
-
-Eastlake 3rd                Standards Track                     [Page 3]
-
-RFC 4343          DNS Case Insensitivity Clarification      January 2006
-
-
-   One way to implement this rule would be to subtract 0x20 from all
-   octets in the inclusive range from 0x61 to 0x7A before comparing
-   octets.  Such an operation is commonly known as "case folding", but
-   implementation via case folding is not required.  Note that the DNS
-   case insensitivity does NOT correspond to the case folding specified
-   in [ISO-8859-1] or [ISO-8859-2].  For example, the octets 0xDD (\221)
-   and 0xFD (\253) do NOT match, although in other contexts, where they
-   are interpreted as the upper- and lower-case version of "Y" with an
-   acute accent, they might.
-
-3.1.  Original DNS Label Types
-
-   DNS labels in wire-encoded names have a type associated with them.
-   The original DNS standard [STD13] had only two types: ASCII labels,
-   with a length from zero to 63 octets, and indirect (or compression)
-   labels, which consist of an offset pointer to a name location
-   elsewhere in the wire encoding on a DNS message.  (The ASCII label of
-   length zero is reserved for use as the name of the root node of the
-   name tree.)  ASCII labels follow the ASCII case conventions described
-   herein and, as stated above, can actually contain arbitrary byte
-   values.  Indirect labels are, in effect, replaced by the name to
-   which they point, which is then treated with the case insensitivity
-   rules in this document.
-
-3.2.  Extended Label Type Case Insensitivity Considerations
-
-   DNS was extended by [RFC2671] so that additional label type numbers
-   would be available.  (The only such type defined so far is the BINARY
-   type [RFC2673], which is now Experimental [RFC3363].)
-
-   The ASCII case insensitivity conventions only apply to ASCII labels;
-   that is to say, label type 0x0, whether appearing directly or invoked
-   by indirect labels.
-
-3.3.  CLASS Case Insensitivity Considerations
-
-   As described in [STD13] and [RFC2929], DNS has an additional axis for
-   data location called CLASS.  The only CLASS in global use at this
-   time is the "IN" (Internet) CLASS.
-
-   The handling of DNS label case is not CLASS dependent.  With the
-   original design of DNS, it was intended that a recursive DNS resolver
-   be able to handle new CLASSes that were unknown at the time of its
-   implementation.  This requires uniform handling of label case
-   insensitivity.  Should it become desirable, for example, to allocate
-   a CLASS with "case sensitive ASCII labels", it would be necessary to
-   allocate a new label type for these labels.
-
-
-
-
-Eastlake 3rd                Standards Track                     [Page 4]
-
-RFC 4343          DNS Case Insensitivity Clarification      January 2006
-
-
-4.  Case on Input and Output
-
-   While ASCII label comparisons are case insensitive, [STD13] says case
-   MUST be preserved on output and preserved when convenient on input.
-   However, this means less than it would appear, since the preservation
-   of case on output is NOT required when output is optimized by the use
-   of indirect labels, as explained below.
-
-4.1.  DNS Output Case Preservation
-
-   [STD13] views the DNS namespace as a node tree.  ASCII output is as
-   if a name were marshaled by taking the label on the node whose name
-   is to be output, converting it to a typographically encoded ASCII
-   string, walking up the tree outputting each label encountered, and
-   preceding all labels but the first with a period (".").  Wire output
-   follows the same sequence, but each label is wire encoded, and no
-   periods are inserted.  No "case conversion" or "case folding" is done
-   during such output operations, thus "preserving" case.  However, to
-   optimize output, indirect labels may be used to point to names
-   elsewhere in the DNS answer.  In determining whether the name to be
-   pointed to (for example, the QNAME) is the "same" as the remainder of
-   the name being optimized, the case insensitive comparison specified
-   above is done.  Thus, such optimization may easily destroy the output
-   preservation of case.  This type of optimization is commonly called
-   "name compression".
-
-4.2.  DNS Input Case Preservation
-
-   Originally, DNS data came from an ASCII Master File as defined in
-   [STD13] or a zone transfer.  DNS Dynamic update and incremental zone
-   transfers [RFC1995] have been added as a source of DNS data [RFC2136,
-   RFC3007].  When a node in the DNS name tree is created by any of such
-   inputs, no case conversion is done.  Thus, the case of ASCII labels
-   is preserved if they are for nodes being created.  However, when a
-   name label is input for a node that already exists in DNS data being
-   held, the situation is more complex.  Implementations are free to
-   retain the case first loaded for such a label, to allow new input to
-   override the old case, or even to maintain separate copies preserving
-   the input case.
-
-   For example, if data with owner name "foo.bar.example" [RFC3092] is
-   loaded and then later data with owner name "xyz.BAR.example" is
-   input, the name of the label on the "bar.example" node (i.e., "bar")
-   might or might not be changed to "BAR" in the DNS stored data.  Thus,
-   later retrieval of data stored under "xyz.bar.example" in this case
-   can use "xyz.BAR.example" in all returned data, use "xyz.bar.example"
-   in all returned data, or even, when more than one RR is being
-   returned, use a mixture of these two capitalizations.  This last case
-
-
-
-Eastlake 3rd                Standards Track                     [Page 5]
-
-RFC 4343          DNS Case Insensitivity Clarification      January 2006
-
-
-   is unlikely, as optimization of answer length through indirect labels
-   tends to cause only one copy of the name tail ("bar.example" or
-   "BAR.example") to be used for all returned RRs.  Note that none of
-   this has any effect on the number or completeness of the RR set
-   returned, only on the case of the names in the RR set returned.
-
-   The same considerations apply when inputting multiple data records
-   with owner names differing only in case.  For example, if an "A"
-   record is the first resource record stored under owner name
-   "xyz.BAR.example" and then a second "A" record is stored under
-   "XYZ.BAR.example", the second MAY be stored with the first (lower
-   case initial label) name, the second MAY override the first so that
-   only an uppercase initial label is retained, or both capitalizations
-   MAY be kept in the DNS stored data.  In any case, a retrieval with
-   either capitalization will retrieve all RRs with either
-   capitalization.
-
-   Note that the order of insertion into a server database of the DNS
-   name tree nodes that appear in a Master File is not defined so that
-   the results of inconsistent capitalization in a Master File are
-   unpredictable output capitalization.
-
-5.  Internationalized Domain Names
-
-   A scheme has been adopted for "internationalized domain names" and
-   "internationalized labels" as described in [RFC3490, RFC3454,
-   RFC3491, and RFC3492].  It makes most of [UNICODE] available through
-   a separate application level transformation from internationalized
-   domain name to DNS domain name and from DNS domain name to
-   internationalized domain name.  Any case insensitivity that
-   internationalized domain names and labels have varies depending on
-   the script and is handled entirely as part of the transformation
-   described in [RFC3454] and [RFC3491], which should be seen for
-   further details.  This is not a part of the DNS as standardized in
-   STD 13.
-
-6.  Security Considerations
-
-   The equivalence of certain DNS label types with case differences, as
-   clarified in this document, can lead to security problems.  For
-   example, a user could be confused by believing that two domain names
-   differing only in case were actually different names.
-
-   Furthermore, a domain name may be used in contexts other than the
-   DNS.  It could be used as a case sensitive index into some database
-   or file system.  Or it could be interpreted as binary data by some
-   integrity or authentication code system.  These problems can usually
-   be handled by using a standardized or "canonical" form of the DNS
-
-
-
-Eastlake 3rd                Standards Track                     [Page 6]
-
-RFC 4343          DNS Case Insensitivity Clarification      January 2006
-
-
-   ASCII type labels; that is, always mapping the ASCII letter value
-   octets in ASCII labels to some specific pre-chosen case, either
-   uppercase or lower case.  An example of a canonical form for domain
-   names (and also a canonical ordering for them) appears in Section 6
-   of [RFC4034].  See also [RFC3597].
-
-   Finally, a non-DNS name may be stored into DNS with the false
-   expectation that case will always be preserved.  For example,
-   although this would be quite rare, on a system with case sensitive
-   email address local parts, an attempt to store two Responsible Person
-   (RP) [RFC1183] records that differed only in case would probably
-   produce unexpected results that might have security implications.
-   That is because the entire email address, including the possibly case
-   sensitive local or left-hand part, is encoded into a DNS name in a
-   readable fashion where the case of some letters might be changed on
-   output as described above.
-
-7.  Acknowledgements
-
-   The contributions to this document by Rob Austein, Olafur
-   Gudmundsson, Daniel J. Anderson, Alan Barrett, Marc Blanchet, Dana,
-   Andreas Gustafsson, Andrew Main, Thomas Narten, and Scott Seligman
-   are gratefully acknowledged.
-
-Normative References
-
-   [ASCII]      ANSI, "USA Standard Code for Information Interchange",
-                X3.4, American National Standards Institute: New York,
-                1968.
-
-   [RFC1995]    Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
-                August 1996.
-
-   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
-                Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2136]    Vixie, P., Thomson,  S., Rekhter, Y., and J. Bound,
-                "Dynamic Updates in the Domain Name System (DNS
-                UPDATE)", RFC 2136, April 1997.
-
-   [RFC2181]     Elz, R. and R. Bush, "Clarifications to the DNS
-                Specification", RFC 2181, July 1997.
-
-   [RFC3007]    Wellington, B., "Secure Domain Name System (DNS) Dynamic
-                Update", RFC 3007, November 2000.
-
-
-
-
-
-
-Eastlake 3rd                Standards Track                     [Page 7]
-
-RFC 4343          DNS Case Insensitivity Clarification      January 2006
-
-
-   [RFC3597]    Gustafsson, A., "Handling of Unknown DNS Resource Record
-                (RR) Types", RFC 3597, September 2003.
-
-   [RFC4034]    Arends, R., Austein, R., Larson, M., Massey, D., and S.
-                Rose, "Resource Records for the DNS Security
-                Extensions", RFC 4034, March 2005.
-
-   [STD13]      Mockapetris, P., "Domain names - concepts and
-                facilities", STD 13, RFC 1034, November 1987.
-
-                Mockapetris, P., "Domain names - implementation and
-                specification", STD 13, RFC 1035, November 1987.
-
-Informative References
-
-   [ISO-8859-1] International Standards Organization, Standard for
-                Character Encodings, Latin-1.
-
-   [ISO-8859-2] International Standards Organization, Standard for
-                Character Encodings, Latin-2.
-
-   [RFC1183]    Everhart, C., Mamakos, L., Ullmann, R., and P.
-                Mockapetris, "New DNS RR Definitions", RFC 1183, October
-                1990.
-
-   [RFC1591]    Postel, J., "Domain Name System Structure and
-                Delegation", RFC 1591, March 1994.
-
-   [RFC2606]    Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS
-                Names", BCP 32, RFC 2606, June 1999.
-
-   [RFC2929]    Eastlake 3rd, D., Brunner-Williams, E., and B. Manning,
-                "Domain Name System (DNS) IANA Considerations", BCP 42,
-                RFC 2929, September 2000.
-
-   [RFC2671]    Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
-                2671, August 1999.
-
-   [RFC2673]    Crawford, M., "Binary Labels in the Domain Name System",
-                RFC 2673, August 1999.
-
-   [RFC3092]    Eastlake 3rd, D., Manros, C., and E. Raymond, "Etymology
-                of "Foo"", RFC 3092, 1 April 2001.
-
-   [RFC3363]    Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
-                Hain, "Representing Internet Protocol version 6 (IPv6)
-                Addresses in the Domain Name System (DNS)", RFC 3363,
-                August 2002.
-
-
-
-Eastlake 3rd                Standards Track                     [Page 8]
-
-RFC 4343          DNS Case Insensitivity Clarification      January 2006
-
-
-   [RFC3454]    Hoffman, P. and M. Blanchet, "Preparation of
-                Internationalized Strings ("stringprep")", RFC 3454,
-                December 2002.
-
-   [RFC3490]    Faltstrom, P., Hoffman, P., and A. Costello,
-                "Internationalizing Domain Names in Applications
-                (IDNA)", RFC 3490, March 2003.
-
-   [RFC3491]    Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
-                Profile for Internationalized Domain Names (IDN)", RFC
-                3491, March 2003.
-
-   [RFC3492]    Costello, A., "Punycode: A Bootstring encoding of
-                Unicode for Internationalized Domain Names in
-                Applications (IDNA)", RFC 3492, March 2003.
-
-   [UNICODE]    The Unicode Consortium, "The Unicode Standard",
-                <http://www.unicode.org/unicode/standard/standard.html>.
-
-Author's Address
-
-   Donald E. Eastlake 3rd
-   Motorola Laboratories
-   155 Beaver Street
-   Milford, MA 01757 USA
-
-   Phone: +1 508-786-7554 (w)
-   EMail: Donald.Eastlake@motorola.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake 3rd                Standards Track                     [Page 9]
-
-RFC 4343          DNS Case Insensitivity Clarification      January 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Eastlake 3rd                Standards Track                    [Page 10]
-
diff --git a/contrib/bind9/doc/rfc/rfc4367.txt b/contrib/bind9/doc/rfc/rfc4367.txt
deleted file mode 100644
index f066b64..0000000
--- a/contrib/bind9/doc/rfc/rfc4367.txt
+++ /dev/null
@@ -1,955 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                  J. Rosenberg, Ed.
-Request for Comments: 4367                                           IAB
-Category: Informational                                    February 2006
-
-
-          What's in a Name: False Assumptions about DNS Names
-
-Status of This Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   The Domain Name System (DNS) provides an essential service on the
-   Internet, mapping structured names to a variety of data, usually IP
-   addresses.  These names appear in email addresses, Uniform Resource
-   Identifiers (URIs), and other application-layer identifiers that are
-   often rendered to human users.  Because of this, there has been a
-   strong demand to acquire names that have significance to people,
-   through equivalence to registered trademarks, company names, types of
-   services, and so on.  There is a danger in this trend; the humans and
-   automata that consume and use such names will associate specific
-   semantics with some names and thereby make assumptions about the
-   services that are, or should be, provided by the hosts associated
-   with the names.  Those assumptions can often be false, resulting in a
-   variety of failure conditions.  This document discusses this problem
-   in more detail and makes recommendations on how it can be avoided.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rosenberg                    Informational                      [Page 1]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-Table of Contents
-
-   1. Introduction ....................................................2
-   2. Target Audience .................................................4
-   3. Modeling Usage of the DNS .......................................4
-   4. Possible Assumptions ............................................5
-      4.1. By the User ................................................5
-      4.2. By the Client ..............................................6
-      4.3. By the Server ..............................................7
-   5. Consequences of False Assumptions ...............................8
-   6. Reasons Why the Assumptions Can Be False ........................9
-      6.1. Evolution ..................................................9
-      6.2. Leakage ...................................................10
-      6.3. Sub-Delegation ............................................10
-      6.4. Mobility ..................................................12
-      6.5. Human Error ...............................................12
-   7. Recommendations ................................................12
-   8. A Note on RFC 2219 and RFC 2782 ................................13
-   9. Security Considerations ........................................14
-   10. Acknowledgements ..............................................14
-   11. IAB Members ...................................................14
-   12. Informative References ........................................15
-
-1.  Introduction
-
-   The Domain Name System (DNS) [1] provides an essential service on the
-   Internet, mapping structured names to a variety of different types of
-   data.  Most often it is used to obtain the IP address of a host
-   associated with that name [2] [1] [3].  However, it can be used to
-   obtain other information, and proposals have been made for nearly
-   everything, including geographic information [4].
-
-   Domain names are most often used in identifiers used by application
-   protocols.  The most well known include email addresses and URIs,
-   such as the HTTP URL [5], Real Time Streaming Protocol (RTSP) URL
-   [6], and SIP URI [7].  These identifiers are ubiquitous, appearing on
-   business cards, web pages, street signs, and so on.  Because of this,
-   there has been a strong demand to acquire domain names that have
-   significance to people through equivalence to registered trademarks,
-   company names, types of services, and so on.  Such identifiers serve
-   many business purposes, including extension of brand, advertising,
-   and so on.
-
-   People often make assumptions about the type of service that is or
-   should be provided by a host associated with that name, based on
-   their expectations and understanding of what the name implies.  This,
-   in turn, triggers attempts by organizations to register domain names
-   based on that presumed user expectation.  Examples of this are the
-
-
-
-Rosenberg                    Informational                      [Page 2]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-   various proposals for a Top-Level Domain (TLD) that could be
-   associated with adult content [8], the requests for creation of TLDs
-   associated with mobile devices and services, and even phishing
-   attacks.
-
-   When these assumptions are codified into the behavior of an
-   automaton, such as an application client or server, as a result of
-   implementor choice, management directive, or domain owner policy, the
-   overall system can fail in various ways.  This document describes a
-   number of typical ways in which these assumptions can be codified,
-   how they can be wrong, the consequences of those mistakes, and the
-   recommended ways in which they can be avoided.
-
-   Section 4 describes some of the possible assumptions that clients,
-   servers, and people can make about a domain name.  In this context,
-   an "assumption" is defined as any behavior that is expected when
-   accessing a service at a domain name, even though the behavior is not
-   explicitly codified in protocol specifications.  Frequently, these
-   assumptions involve ignoring parts of a specification based on an
-   assumption that the client or server is deployed in an environment
-   that is more rigid than the specification allows.  Section 5
-   overviews some of the consequences of these false assumptions.
-   Generally speaking, these consequences can include a variety of
-   different interoperability failures, user experience failures, and
-   system failures.  Section 6 discusses why these assumptions can be
-   false from the very beginning or become false at some point in the
-   future.  Most commonly, they become false because the environment
-   changes in unexpected ways over time, and what was a valid assumption
-   before, no longer is.  Other times, the assumptions prove wrong
-   because they were based on the belief that a specific community of
-   clients and servers was participating, and an element outside of that
-   community began participating.
-
-   Section 7 then provides some recommendations.  These recommendations
-   encapsulate some of the engineering mantras that have been at the
-   root of Internet protocol design for decades.  These include:
-
-      Follow the specifications.
-
-      Use the capability negotiation techniques provided in the
-      protocols.
-
-      Be liberal in what you accept, and conservative in what you send.
-      [18]
-
-   Overall, automata should not change their behavior within a protocol
-   based on the domain name, or some component of the domain name, of
-   the host they are communicating with.
-
-
-
-Rosenberg                    Informational                      [Page 3]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-2.  Target Audience
-
-   This document has several audiences.  Firstly, it is aimed at
-   implementors who ultimately develop the software that make the false
-   assumptions that are the subject of this document.  The
-   recommendations described here are meant to reinforce the engineering
-   guidelines that are often understood by implementors, but frequently
-   forgotten as deadlines near and pressures mount.
-
-   The document is also aimed at technology managers, who often develop
-   the requirements that lead to these false assumptions.  For them,
-   this document serves as a vehicle for emphasizing the importance of
-   not taking shortcuts in the scope of applicability of a project.
-
-   Finally, this document is aimed at domain name policy makers and
-   administrators.  For them, it points out the perils in establishing
-   domain policies that get codified into the operation of applications
-   running within that domain.
-
-3.  Modeling Usage of the DNS
-
-
-                       +--------+
-                       |        |
-                       |        |
-                       |  DNS   |
-                       |Service |
-                       |        |
-                       +--------+
-                         ^   |
-                         |   |
-                         |   |
-                         |   |
-          /--\           |   |
-         |    |          |   V
-         |    |        +--------+                     +--------+
-          \--/         |        |                     |        |
-            |          |        |                     |        |
-         ---+---       | Client |-------------------->| Server |
-            |          |        |                     |        |
-            |          |        |                     |        |
-           /\          +--------+                     +--------+
-          /  \
-         /    \
-
-         User
-                                 Figure 1
-
-
-
-
-Rosenberg                    Informational                      [Page 4]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-   Figure 1 shows a simple conceptual model of how the DNS is used by
-   applications.  A user of the application obtains an identifier for
-   particular content or service it wishes to obtain.  This identifier
-   is often a URL or URI that contains a domain name.  The user enters
-   this identifier into its client application (for example, by typing
-   in the URL in a web browser window).  The client is the automaton (a
-   software and/or hardware system) that contacts a server for that
-   application in order to provide service to the user.  To do that, it
-   contacts a DNS server to resolve the domain name in the identifier to
-   an IP address.  It then contacts the server at that IP address.  This
-   simple model applies to application protocols such as HTTP [5], SIP
-   [7], RTSP [6], and SMTP [9].
-
-   >From this model, it is clear that three entities in the system can
-   potentially make false assumptions about the service provided by the
-   server.  The human user may form expectations relating to the content
-   of the service based on a parsing of the host name from which the
-   content originated.  The server might assume that the client
-   connecting to it supports protocols that it does not, can process
-   content that it cannot, or has capabilities that it does not.
-   Similarly, the client might assume that the server supports
-   protocols, content, or capabilities that it does not.  Furthermore,
-   applications can potentially contain a multiplicity of humans,
-   clients, and servers, all of which can independently make these false
-   assumptions.
-
-4.  Possible Assumptions
-
-   For each of the three elements, there are many types of false
-   assumptions that can be made.
-
-4.1.  By the User
-
-   The set of possible assumptions here is nearly boundless.  Users
-   might assume that an HTTP URL that looks like a company name maps to
-   a server run by that company.  They might assume that an email from a
-   email address in the .gov TLD is actually from a government employee.
-   They might assume that the content obtained from a web server within
-   a TLD labeled as containing adult materials (for example, .sex)
-   actually contains adult content [8].  These assumptions are
-   unavoidable, may all be false, and are not the focus of this
-   document.
-
-
-
-
-
-
-
-
-
-Rosenberg                    Informational                      [Page 5]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-4.2.  By the Client
-
-   Even though the client is an automaton, it can make some of the same
-   assumptions that a human user might make.  For example, many clients
-   assume that any host with a hostname that begins with "www" is a web
-   server, even though this assumption may be false.
-
-   In addition, the client concerns itself with the protocols needed to
-   communicate with the server.  As a result, it might make assumptions
-   about the operation of the protocols for communicating with the
-   server.  These assumptions manifest themselves in an implementation
-   when a standardized protocol negotiation technique defined by the
-   protocol is ignored, and instead, some kind of rule is coded into the
-   software that comes to its own conclusion about what the negotiation
-   would have determined.  The result is often a loss of
-   interoperability, degradation in reliability, and worsening of user
-   experience.
-
-   Authentication Algorithm: Though a protocol might support a
-      multiplicity of authentication techniques, a client might assume
-      that a server always supports one that is only optional according
-      to the protocol.  For example, a SIP client contacting a SIP
-      server in a domain that is apparently used to identify mobile
-      devices (for example, www.example.cellular) might assume that the
-      server supports the optional Authentication and Key Agreement
-      (AKA) digest technique [10], just because of the domain name that
-      was used to access the server.  As another example, a web client
-      might assume that a server with the name https.example.com
-      supports HTTP over Transport Layer Security (TLS) [16].
-
-   Data Formats: Though a protocol might allow a multiplicity of data
-      formats to be sent from the server to the client, the client might
-      assume a specific one, rather than using the content labeling and
-      negotiation capabilities of the underlying protocol.  For example,
-      an RTSP client might assume that all audio content delivered to it
-      from media.example.cellular uses a low-bandwidth codec.  As
-      another example, a mail client might assume that the contents of
-      messages it retrieves from a mail server at mail.example.cellular
-      are always text, instead of checking the MIME headers [11] in the
-      message in order to determine the actual content type.
-
-   Protocol Extensions: A client may attempt an operation on the server
-      that requires the server to support an optional protocol
-      extension.  However, rather than implementing the necessary
-      fallback logic, the client may falsely assume that the extension
-      is supported.  As an example, a SIP client that requires reliable
-      provisional responses to its request (RFC 3262 [17]) might assume
-      that this extension is supported on servers in the domain
-
-
-
-Rosenberg                    Informational                      [Page 6]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-      sip.example.telecom.  Furthermore, the client would not implement
-      the fallback behavior defined in RFC 3262, since it would assume
-      that all servers it will communicate with are in this domain and
-      that all therefore support this extension.  However, if the
-      assumptions prove wrong, the client is unable to make any phone
-      calls.
-
-   Languages: A client may support facilities for processing text
-      content differently depending on the language of the text.  Rather
-      than determining the language from markers in the message from the
-      server, the client might assume a language based on the domain
-      name.  This assumption can easily be wrong.  For example, a client
-      might assume that any text in a web page retrieved from a server
-      within the .de country code TLD (ccTLD) is in German, and attempt
-      a translation to Finnish.  This would fail dramatically if the
-      text was actually in French.  Unfortunately, this client behavior
-      is sometimes exhibited because the server has not properly labeled
-      the language of the content in the first place, often because the
-      server assumed such a labeling was not needed.  This is an example
-      of how these false assumptions can create vicious cycles.
-
-4.3.  By the Server
-
-   The server, like the client, is an automaton.  Let us consider one
-   servicing a particular domain -- www.company.cellular, for example.
-   It might assume that all clients connecting to this domain support
-   particular capabilities, rather than using the underlying protocol to
-   make this determination.  Some examples include:
-
-   Authentication Algorithm: The server can assume that a client
-      supports a particular, optional, authentication technique, and it
-      therefore does not support the mandatory one.
-
-   Language: The server can serve content in a particular language,
-      based on an assumption that clients accessing the domain speak a
-      particular language, or based on an assumption that clients coming
-      from a particular IP address speak a certain language.
-
-   Data Formats: The server can assume that the client supports a
-      particular set of MIME types and is only capable of sending ones
-      within that set.  When it generates content in a protocol
-      response, it ignores any content negotiation headers that were
-      present in the request.  For example, a web server might ignore
-      the Accept HTTP header field and send a specific image format.
-
-
-
-
-
-
-
-Rosenberg                    Informational                      [Page 7]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-   Protocol Extensions: The server might assume that the client supports
-      a particular optional protocol extension, and so it does not
-      support the fallback behavior necessary in the case where the
-      client does not.
-
-   Client Characteristics: The server might assume certain things about
-      the physical characteristics of its clients, such as memory
-      footprint, processing power, screen sizes, screen colors, pointing
-      devices, and so on.  Based on these assumptions, it might choose
-      specific behaviors when processing a request.  For example, a web
-      server might always assume that clients connect through cell
-      phones, and therefore return content that lacks images and is
-      tuned for such devices.
-
-5.  Consequences of False Assumptions
-
-   There are numerous negative outcomes that can arise from the various
-   false assumptions that users, servers, and clients can make.  These
-   include:
-
-   Interoperability Failure: In these cases, the client or server
-      assumed some kind of protocol operation, and this assumption was
-      wrong.  The result is that the two are unable to communicate, and
-      the user receives some kind of an error.  This represents a total
-      interoperability failure, manifesting itself as a lack of service
-      to users of the system.  Unfortunately, this kind of failure
-      persists.  Repeated attempts over time by the client to access the
-      service will fail.  Only a change in the server or client software
-      can fix this problem.
-
-   System Failure: In these cases, the client or server misinterpreted a
-      protocol operation, and this misinterpretation was serious enough
-      to uncover a bug in the implementation.  The bug causes a system
-      crash or some kind of outage, either transient or permanent (until
-      user reset).  If this failure occurs in a server, not only will
-      the connecting client lose service, but other clients attempting
-      to connect will not get service.  As an example, if a web server
-      assumes that content passed to it from a client (created, for
-      example, by a digital camera) is of a particular content type, and
-      it always passes image content to a codec for decompression prior
-      to storage, the codec might crash when it unexpectedly receives an
-      image compressed in a different format.  Of course, it might crash
-      even if the Content-Type was correct, but the compressed bitstream
-      was invalid.  False assumptions merely introduce additional
-      failure cases.
-
-
-
-
-
-
-Rosenberg                    Informational                      [Page 8]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-   Poor User Experience: In these cases, the client and server
-      communicate, but the user receives a diminished user experience.
-      For example, if a client on a PC connects to a web site that
-      provides content for mobile devices, the content may be
-      underwhelming when viewed on the PC.  Or, a client accessing a
-      streaming media service may receive content of very low bitrate,
-      even though the client supported better codecs.  Indeed, if a user
-      wishes to access content from both a cellular device and a PC
-      using a shared address book (that is, an address book shared
-      across multiple devices), the user would need two entries in that
-      address book, and would need to use the right one from the right
-      device.  This is a poor user experience.
-
-   Degraded Security: In these cases, a weaker security mechanism is
-      used than the one that ought to have been used.  As an example, a
-      server in a domain might assume that it is only contacted by
-      clients with a limited set of authentication algorithms, even
-      though the clients have been recently upgraded to support a
-      stronger set.
-
-6.  Reasons Why the Assumptions Can Be False
-
-   Assumptions made by clients and servers about the operation of
-   protocols when contacting a particular domain are brittle, and can be
-   wrong for many reasons.  On the server side, many of the assumptions
-   are based on the notion that a domain name will only be given to, or
-   used by, a restricted set of clients.  If the holder of the domain
-   name assumes something about those clients, and can assume that only
-   those clients use the domain name, then it can configure or program
-   the server to operate specifically for those clients.  Both parts of
-   this assumption can be wrong, as discussed in more detail below.
-
-   On the client side, the notion is similar, being based on the
-   assumption that a server within a particular domain will provide a
-   specific type of service.  Sub-delegation and evolution, both
-   discussed below, can make these assumptions wrong.
-
-6.1.  Evolution
-
-   The Internet and the devices that access it are constantly evolving,
-   often at a rapid pace.  Unfortunately, there is a tendency to build
-   for the here and now, and then worry about the future at a later
-   time.  Many of the assumptions above are predicated on
-   characteristics of today's clients and servers.  Support for specific
-   protocols, authentication techniques, or content are based on today's
-   standards and today's devices.  Even though they may, for the most
-   part, be true, they won't always be.  An excellent example is mobile
-   devices.  A server servicing a domain accessed by mobile devices
-
-
-
-Rosenberg                    Informational                      [Page 9]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-   might try to make assumptions about the protocols, protocol
-   extensions, security mechanisms, screen sizes, or processor power of
-   such devices.  However, all of these characteristics can and will
-   change over time.
-
-   When they do change, the change is usually evolutionary.  The result
-   is that the assumptions remain valid in some cases, but not in
-   others.  It is difficult to fix such systems, since it requires the
-   server to detect what type of client is connecting, and what its
-   capabilities are.  Unless the system is built and deployed with these
-   capability negotiation techniques built in to begin with, such
-   detection can be extremely difficult.  In fact, fixing it will often
-   require the addition of such capability negotiation features that, if
-   they had been in place and used to begin with, would have avoided the
-   problem altogether.
-
-6.2.  Leakage
-
-   Servers also make assumptions because of the belief that they will
-   only be accessed by specific clients, and in particular, those that
-   are configured or provisioned to use the domain name.  In essence,
-   there is an assumption of community -- that a specific community
-   knows and uses the domain name, while others outside of the community
-   do not.
-
-   The problem is that this notion of community is a false one.  The
-   Internet is global.  The DNS is global.  There is no technical
-   barrier that separates those inside of the community from those
-   outside.  The ease with which information propagates across the
-   Internet makes it extremely likely that such domain names will
-   eventually find their way into clients outside of the presumed
-   community.  The ubiquitous presence of domain names in various URI
-   formats, coupled with the ease of conveyance of URIs, makes such
-   leakage merely a matter of time.  Furthermore, since the DNS is
-   global, and since it can only have one root [12], it becomes possible
-   for clients outside of the community to search and find and use such
-   "special" domain names.
-
-   Indeed, this leakage is a strength of the Internet architecture, not
-   a weakness.  It enables global access to services from any client
-   with a connection to the Internet.  That, in turn, allows for rapid
-   growth in the number of customers for any particular service.
-
-6.3.  Sub-Delegation
-
-   Clients and users make assumptions about domains because of the
-   notion that there is some kind of centralized control that can
-   enforce those assumptions.  However, the DNS is not centralized; it
-
-
-
-Rosenberg                    Informational                     [Page 10]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-   is distributed.  If a domain doesn't delegate its sub-domains and has
-   its records within a single zone, it is possible to maintain a
-   centralized policy about operation of its domain.  However, once a
-   domain gets sufficiently large that the domain administrators begin
-   to delegate sub-domains to other authorities, it becomes increasingly
-   difficult to maintain any kind of central control on the nature of
-   the service provided in each sub-domain.
-
-   Similarly, the usage of domain names with human semantic connotation
-   tends to lead to a registration of multiple domains in which a
-   particular service is to run.  As an example, a service provider with
-   the name "example" might register and set up its services in
-   "example.com", "example.net", and generally example.foo for each foo
-   that is a valid TLD.  This, like sub-delegation, results in a growth
-   in the number of domains over which it is difficult to maintain
-   centralized control.
-
-   Not that it is not possible, since there are many examples of
-   successful administration of policies across sub-domains many levels
-   deep.  However, it takes an increasing amount of effort to ensure
-   this result, as it requires human intervention and the creation of
-   process and procedure.  Automated validation of adherence to policies
-   is very difficult to do, as there is no way to automatically verify
-   many policies that might be put into place.
-
-   A less costly process for providing centralized management of
-   policies is to just hope that any centralized policies are being
-   followed, and then wait for complaints or perform random audits.
-   Those approaches have many problems.
-
-   The invalidation of assumptions due to sub-delegation is discussed in
-   further detail in Section 4.1.3 of [8] and in Section 3.3 of [20].
-
-   As a result of the fragility of policy continuity across sub-
-   delegations, if a client or user assumes some kind of property
-   associated with a TLD (such as ".wifi"), it becomes increasingly more
-   likely with the number of sub-domains that this property will not
-   exist in a server identified by a particular name.  For example, in
-   "store.chain.company.provider.wifi", there may be four levels of
-   delegation from ".wifi", making it quite likely that, unless the
-   holder of ".wifi" is working diligently, the properties that the
-   holder of ".wifi" wishes to enforce are not present.  These
-   properties may not be present due to human error or due to a willful
-   decision not to adhere to them.
-
-
-
-
-
-
-
-Rosenberg                    Informational                     [Page 11]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-6.4.  Mobility
-
-   One of the primary value propositions of a hostname as an identifier
-   is its persistence.  A client can change IP addresses, yet still
-   retain a persistent identifier used by other hosts to reach it.
-   Because their value derives from their persistence, hostnames tend to
-   move with a host not just as it changes IP addresses, but as it
-   changes access network providers and technologies.  For this reason,
-   assumptions made about a host based on the presumed access network
-   corresponding to that hostname tend to be wrong over time.  As an
-   example, a PC might normally be connected to its broadband provider,
-   and through dynamic DNS have a hostname within the domain of that
-   provider.  However, one cannot assume that any host within that
-   network has access over a broadband link; the user could connect
-   their PC over a low-bandwidth wireless access network and still
-   retain its domain name.
-
-6.5.  Human Error
-
-   Of course, human error can be the source of errors in any system, and
-   the same is true here.  There are many examples relevant to the
-   problem under discussion.
-
-   A client implementation may make the assumption that, just because a
-   DNS SRV record exists for a particular protocol in a particular
-   domain, indicating that the service is available on some port, that
-   the service is, in fact, running there.  This assumption could be
-   wrong because the SRV records haven't been updated by the system
-   administrators to reflect the services currently running.  As another
-   example, a client might assume that a particular domain policy
-   applies to all sub-domains.  However, a system administrator might
-   have omitted to apply the policy to servers running in one of those
-   sub-domains.
-
-7.  Recommendations
-
-   Based on these problems, the clear conclusion is that clients,
-   servers, and users should not make assumptions on the nature of the
-   service provided to, or by, a domain.  More specifically, however,
-   the following can be said:
-
-   Follow the specifications: When specifications define mandatory
-      baseline procedures and formats, those should be implemented and
-      supported, even if the expectation is that optional procedures
-      will most often be used.  For example, if a specification mandates
-      a particular baseline authentication technique, but allows others
-      to be negotiated and used, implementations need to implement the
-      baseline authentication algorithm even if the other ones are used
-
-
-
-Rosenberg                    Informational                     [Page 12]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-      most of the time.  Put more simply, the behavior of the protocol
-      machinery should never change based on the domain name of the
-      host.
-
-   Use capability negotiation: Many protocols are engineered with
-      capability negotiation mechanisms.  For example, a content
-      negotiation framework has been defined for protocols using MIME
-      content [13] [14] [15].  SIP allows for clients to negotiate the
-      media types used in the multimedia session, as well as protocol
-      parameters.  HTTP allows for clients to negotiate the media types
-      returned in requests for content.  When such features are
-      available in a protocol, client and servers should make use of
-      them rather than making assumptions about supported capabilities.
-      A corollary is that protocol designers should include such
-      mechanisms when evolution is expected in the usage of the
-      protocol.
-
-   "Be liberal in what you accept, and conservative in what you send"
-      [18]:  This axiom of Internet protocol design is applicable here
-      as well.  Implementations should be prepared for the full breadth
-      of what a protocol allows another entity to send, rather than be
-      limiting in what it is willing to receive.
-
-   To summarize -- there is never a need to make assumptions.  Rather
-   than doing so, utilize the specifications and the negotiation
-   capabilities they provide, and the overall system will be robust and
-   interoperable.
-
-8.  A Note on RFC 2219 and RFC 2782
-
-   Based on the definition of an assumption given here, the behavior
-   hinted at by records in the DNS also represents an assumption.  RFC
-   2219 [19] defines well-known aliases that can be used to construct
-   domain names for reaching various well-known services in a domain.
-   This approach was later followed by the definition of a new resource
-   record, the SRV record [2], which specifies that a particular service
-   is running on a server in a domain.  Although both of these
-   mechanisms are useful as a hint that a particular service is running
-   in a domain, both of them represent assumptions that may be false.
-   However, they differ in the set of reasons why those assumptions
-   might be false.
-
-   A client that assumes that "ftp.example.com" is an FTP server may be
-   wrong because the presumed naming convention in RFC 2219 was not
-   known by, or not followed by, the owner of domain.com.  With RFC
-   2782, an SRV record for a particular service would be present only by
-   explicit choice of the domain administrator, and thus a client that
-
-
-
-
-Rosenberg                    Informational                     [Page 13]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-   assumes that the corresponding host provides this service would be
-   wrong only because of human error in configuration.  In this case,
-   the assumption is less likely to be wrong, but it certainly can be.
-
-   The only way to determine with certainty that a service is running on
-   a host is to initiate a connection to the port for that service, and
-   check.  Implementations need to be careful not to codify any
-   behaviors that cause failures should the information provided in the
-   record actually be false.  This borders on common sense for robust
-   implementations, but it is valuable to raise this point explicitly.
-
-9.  Security Considerations
-
-   One of the assumptions that can be made by clients or servers is the
-   availability and usage (or lack thereof) of certain security
-   protocols and algorithms.  For example, a client accessing a service
-   in a particular domain might assume a specific authentication
-   algorithm or hash function in the application protocol.  It is
-   possible that, over time, weaknesses are found in such a technique,
-   requiring usage of a different mechanism.  Similarly, a system might
-   start with an insecure mechanism, and then decide later on to use a
-   secure one.  In either case, assumptions made on security properties
-   can result in interoperability failures, or worse yet, providing
-   service in an insecure way, even though the client asked for, and
-   thought it would get, secure service.  These kinds of assumptions are
-   fundamentally unsound even if the records themselves are secured with
-   DNSSEC.
-
-10.  Acknowledgements
-
-   The IAB would like to thank John Klensin, Keith Moore and Peter Koch
-   for their comments.
-
-11.  IAB Members
-
-   Internet Architecture Board members at the time of writing of this
-   document are:
-
-      Bernard Aboba
-
-      Loa Andersson
-
-      Brian Carpenter
-
-      Leslie Daigle
-
-      Patrik Faltstrom
-
-
-
-
-Rosenberg                    Informational                     [Page 14]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-      Bob Hinden
-
-      Kurtis Lindqvist
-
-      David Meyer
-
-      Pekka Nikander
-
-      Eric Rescorla
-
-      Pete Resnick
-
-      Jonathan Rosenberg
-
-12.  Informative References
-
-   [1]   Mockapetris, P., "Domain names - concepts and facilities",
-         STD 13, RFC 1034, November 1987.
-
-   [2]   Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
-         specifying the location of services (DNS SRV)", RFC 2782,
-         February 2000.
-
-   [3]   Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
-         Three: The Domain Name System (DNS) Database", RFC 3403,
-         October 2002.
-
-   [4]   Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A Means
-         for Expressing Location Information in the Domain Name System",
-         RFC 1876, January 1996.
-
-   [5]   Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
-         Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
-         HTTP/1.1", RFC 2616, June 1999.
-
-   [6]   Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
-         Protocol (RTSP)", RFC 2326, April 1998.
-
-   [7]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
-         Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
-         Session Initiation Protocol", RFC 3261, June 2002.
-
-   [8]   Eastlake, D., ".sex Considered Dangerous", RFC 3675,
-         February 2004.
-
-   [9]   Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
-         April 2001.
-
-
-
-
-Rosenberg                    Informational                     [Page 15]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-   [10]  Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer
-         Protocol (HTTP) Digest Authentication Using Authentication and
-         Key Agreement (AKA)", RFC 3310, September 2002.
-
-   [11]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
-         Extensions (MIME) Part One: Format of Internet Message Bodies",
-         RFC 2045, November 1996.
-
-   [12]  Internet Architecture Board, "IAB Technical Comment on the
-         Unique DNS Root", RFC 2826, May 2000.
-
-   [13]  Klyne, G., "Indicating Media Features for MIME Content",
-         RFC 2912, September 2000.
-
-   [14]  Klyne, G., "A Syntax for Describing Media Feature Sets",
-         RFC 2533, March 1999.
-
-   [15]  Klyne, G., "Protocol-independent Content Negotiation
-         Framework", RFC 2703, September 1999.
-
-   [16]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
-
-   [17]  Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
-         Responses in Session Initiation Protocol (SIP)", RFC 3262,
-         June 2002.
-
-   [18]  Braden, R., "Requirements for Internet Hosts - Communication
-         Layers", STD 3, RFC 1122, October 1989.
-
-   [19]  Hamilton, M. and R. Wright, "Use of DNS Aliases for Network
-         Services", BCP 17, RFC 2219, October 1997.
-
-   [20]  Faltstrom, P., "Design Choices When Expanding DNS", Work in
-         Progress, June 2005.
-
-Author's Address
-
-   Jonathan Rosenberg, Editor
-   IAB
-   600 Lanidex Plaza
-   Parsippany, NJ  07054
-   US
-
-   Phone: +1 973 952-5000
-   EMail: jdrosen@cisco.com
-   URI:   http://www.jdrosen.net
-
-
-
-
-
-Rosenberg                    Informational                     [Page 16]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Rosenberg                    Informational                     [Page 17]
-
diff --git a/contrib/bind9/doc/rfc/rfc4398.txt b/contrib/bind9/doc/rfc/rfc4398.txt
deleted file mode 100644
index 6437436..0000000
--- a/contrib/bind9/doc/rfc/rfc4398.txt
+++ /dev/null
@@ -1,955 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                       S. Josefsson
-Request for Comments: 4398                                    March 2006
-Obsoletes: 2538
-Category: Standards Track
-
-
-          Storing Certificates in the Domain Name System (DNS)
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   Cryptographic public keys are frequently published, and their
-   authenticity is demonstrated by certificates.  A CERT resource record
-   (RR) is defined so that such certificates and related certificate
-   revocation lists can be stored in the Domain Name System (DNS).
-
-   This document obsoletes RFC 2538.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                   Standards Track                     [Page 1]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-Table of Contents
-
-   1. Introduction ....................................................3
-   2. The CERT Resource Record ........................................3
-      2.1. Certificate Type Values ....................................4
-      2.2. Text Representation of CERT RRs ............................6
-      2.3. X.509 OIDs .................................................6
-   3. Appropriate Owner Names for CERT RRs ............................7
-      3.1. Content-Based X.509 CERT RR Names ..........................8
-      3.2. Purpose-Based X.509 CERT RR Names ..........................9
-      3.3. Content-Based OpenPGP CERT RR Names ........................9
-      3.4. Purpose-Based OpenPGP CERT RR Names .......................10
-      3.5. Owner Names for IPKIX, ISPKI, IPGP, and IACPKIX ...........10
-   4. Performance Considerations .....................................11
-   5. Contributors ...................................................11
-   6. Acknowledgements ...............................................11
-   7. Security Considerations ........................................12
-   8. IANA Considerations ............................................12
-   9. Changes since RFC 2538 .........................................13
-   10. References ....................................................14
-      10.1. Normative References .....................................14
-      10.2. Informative References ...................................15
-   Appendix A.  Copying Conditions ...................................16
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                   Standards Track                     [Page 2]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-1.  Introduction
-
-   Public keys are frequently published in the form of a certificate,
-   and their authenticity is commonly demonstrated by certificates and
-   related certificate revocation lists (CRLs).  A certificate is a
-   binding, through a cryptographic digital signature, of a public key,
-   a validity interval and/or conditions, and identity, authorization,
-   or other information.  A certificate revocation list is a list of
-   certificates that are revoked, and of incidental information, all
-   signed by the signer (issuer) of the revoked certificates.  Examples
-   are X.509 certificates/CRLs in the X.500 directory system or OpenPGP
-   certificates/revocations used by OpenPGP software.
-
-   Section 2 specifies a CERT resource record (RR) for the storage of
-   certificates in the Domain Name System [1] [2].
-
-   Section 3 discusses appropriate owner names for CERT RRs.
-
-   Sections 4, 7, and 8 cover performance, security, and IANA
-   considerations, respectively.
-
-   Section 9 explains the changes in this document compared to RFC 2538.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [3].
-
-2.  The CERT Resource Record
-
-   The CERT resource record (RR) has the structure given below.  Its RR
-   type code is 37.
-
-                       1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |             type              |             key tag           |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |   algorithm   |                                               /
-   +---------------+            certificate or CRL                 /
-   /                                                               /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
-
-   The type field is the certificate type as defined in Section 2.1
-   below.
-
-   The key tag field is the 16-bit value computed for the key embedded
-   in the certificate, using the RRSIG Key Tag algorithm described in
-   Appendix B of [12].  This field is used as an efficiency measure to
-
-
-
-Josefsson                   Standards Track                     [Page 3]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-   pick which CERT RRs may be applicable to a particular key.  The key
-   tag can be calculated for the key in question, and then only CERT RRs
-   with the same key tag need to be examined.  Note that two different
-   keys can have the same key tag.  However, the key MUST be transformed
-   to the format it would have as the public key portion of a DNSKEY RR
-   before the key tag is computed.  This is only possible if the key is
-   applicable to an algorithm and complies to limits (such as key size)
-   defined for DNS security.  If it is not, the algorithm field MUST be
-   zero and the tag field is meaningless and SHOULD be zero.
-
-   The algorithm field has the same meaning as the algorithm field in
-   DNSKEY and RRSIG RRs [12], except that a zero algorithm field
-   indicates that the algorithm is unknown to a secure DNS, which may
-   simply be the result of the algorithm not having been standardized
-   for DNSSEC [11].
-
-2.1.  Certificate Type Values
-
-   The following values are defined or reserved:
-
-         Value  Mnemonic  Certificate Type
-         -----  --------  ----------------
-             0            Reserved
-             1  PKIX      X.509 as per PKIX
-             2  SPKI      SPKI certificate
-             3  PGP       OpenPGP packet
-             4  IPKIX     The URL of an X.509 data object
-             5  ISPKI     The URL of an SPKI certificate
-             6  IPGP      The fingerprint and URL of an OpenPGP packet
-             7  ACPKIX    Attribute Certificate
-             8  IACPKIX   The URL of an Attribute Certificate
-         9-252            Available for IANA assignment
-           253  URI       URI private
-           254  OID       OID private
-           255            Reserved
-     256-65279            Available for IANA assignment
-   65280-65534            Experimental
-         65535            Reserved
-
-   These values represent the initial content of the IANA registry; see
-   Section 8.
-
-   The PKIX type is reserved to indicate an X.509 certificate conforming
-   to the profile defined by the IETF PKIX working group [8].  The
-   certificate section will start with a one-octet unsigned OID length
-   and then an X.500 OID indicating the nature of the remainder of the
-
-
-
-
-
-Josefsson                   Standards Track                     [Page 4]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-   certificate section (see Section 2.3, below).  (NOTE: X.509
-   certificates do not include their X.500 directory-type-designating
-   OID as a prefix.)
-
-   The SPKI and ISPKI types are reserved to indicate the SPKI
-   certificate format [15], for use when the SPKI documents are moved
-   from experimental status.  The format for these two CERT RR types
-   will need to be specified later.
-
-   The PGP type indicates an OpenPGP packet as described in [5] and its
-   extensions and successors.  This is used to transfer public key
-   material and revocation signatures.  The data is binary and MUST NOT
-   be encoded into an ASCII armor.  An implementation SHOULD process
-   transferable public keys as described in Section 10.1 of [5], but it
-   MAY handle additional OpenPGP packets.
-
-   The ACPKIX type indicates an Attribute Certificate format [9].
-
-   The IPKIX and IACPKIX types indicate a URL that will serve the
-   content that would have been in the "certificate, CRL, or URL" field
-   of the corresponding type (PKIX or ACPKIX, respectively).
-
-   The IPGP type contains both an OpenPGP fingerprint for the key in
-   question, as well as a URL.  The certificate portion of the IPGP CERT
-   RR is defined as a one-octet fingerprint length, followed by the
-   OpenPGP fingerprint, followed by the URL.  The OpenPGP fingerprint is
-   calculated as defined in RFC 2440 [5].  A zero-length fingerprint or
-   a zero-length URL are legal, and indicate URL-only IPGP data or
-   fingerprint-only IPGP data, respectively.  A zero-length fingerprint
-   and a zero-length URL are meaningless and invalid.
-
-   The IPKIX, ISPKI, IPGP, and IACPKIX types are known as "indirect".
-   These types MUST be used when the content is too large to fit in the
-   CERT RR and MAY be used at the implementer's discretion.  They SHOULD
-   NOT be used where the DNS message is 512 octets or smaller and could
-   thus be expected to fit a UDP packet.
-
-   The URI private type indicates a certificate format defined by an
-   absolute URI.  The certificate portion of the CERT RR MUST begin with
-   a null-terminated URI [10], and the data after the null is the
-   private format certificate itself.  The URI SHOULD be such that a
-   retrieval from it will lead to documentation on the format of the
-   certificate.  Recognition of private certificate types need not be
-   based on URI equality but can use various forms of pattern matching
-   so that, for example, subtype or version information can also be
-   encoded into the URI.
-
-
-
-
-
-Josefsson                   Standards Track                     [Page 5]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-   The OID private type indicates a private format certificate specified
-   by an ISO OID prefix.  The certificate section will start with a
-   one-octet unsigned OID length and then a BER-encoded OID indicating
-   the nature of the remainder of the certificate section.  This can be
-   an X.509 certificate format or some other format.  X.509 certificates
-   that conform to the IETF PKIX profile SHOULD be indicated by the PKIX
-   type, not the OID private type.  Recognition of private certificate
-   types need not be based on OID equality but can use various forms of
-   pattern matching such as OID prefix.
-
-2.2.  Text Representation of CERT RRs
-
-   The RDATA portion of a CERT RR has the type field as an unsigned
-   decimal integer or as a mnemonic symbol as listed in Section 2.1,
-   above.
-
-   The key tag field is represented as an unsigned decimal integer.
-
-   The algorithm field is represented as an unsigned decimal integer or
-   a mnemonic symbol as listed in [12].
-
-   The certificate/CRL portion is represented in base 64 [16] and may be
-   divided into any number of white-space-separated substrings, down to
-   single base-64 digits, which are concatenated to obtain the full
-   signature.  These substrings can span lines using the standard
-   parenthesis.
-
-   Note that the certificate/CRL portion may have internal sub-fields,
-   but these do not appear in the master file representation.  For
-   example, with type 254, there will be an OID size, an OID, and then
-   the certificate/CRL proper.  However, only a single logical base-64
-   string will appear in the text representation.
-
-2.3.  X.509 OIDs
-
-   OIDs have been defined in connection with the X.500 directory for
-   user certificates, certification authority certificates, revocations
-   of certification authority, and revocations of user certificates.
-   The following table lists the OIDs, their BER encoding, and their
-   length-prefixed hex format for use in CERT RRs:
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                   Standards Track                     [Page 6]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-       id-at-userCertificate
-           = { joint-iso-ccitt(2) ds(5) at(4) 36 }
-              == 0x 03 55 04 24
-       id-at-cACertificate
-           = { joint-iso-ccitt(2) ds(5) at(4) 37 }
-              == 0x 03 55 04 25
-       id-at-authorityRevocationList
-           = { joint-iso-ccitt(2) ds(5) at(4) 38 }
-              == 0x 03 55 04 26
-       id-at-certificateRevocationList
-           = { joint-iso-ccitt(2) ds(5) at(4) 39 }
-              == 0x 03 55 04 27
-
-3.  Appropriate Owner Names for CERT RRs
-
-   It is recommended that certificate CERT RRs be stored under a domain
-   name related to their subject, i.e., the name of the entity intended
-   to control the private key corresponding to the public key being
-   certified.  It is recommended that certificate revocation list CERT
-   RRs be stored under a domain name related to their issuer.
-
-   Following some of the guidelines below may result in DNS names with
-   characters that require DNS quoting as per Section 5.1 of RFC 1035
-   [2].
-
-   The choice of name under which CERT RRs are stored is important to
-   clients that perform CERT queries.  In some situations, the clients
-   may not know all information about the CERT RR object it wishes to
-   retrieve.  For example, a client may not know the subject name of an
-   X.509 certificate, or the email address of the owner of an OpenPGP
-   key.  Further, the client might only know the hostname of a service
-   that uses X.509 certificates or the Key ID of an OpenPGP key.
-
-   Therefore, two owner name guidelines are defined: content-based owner
-   names and purpose-based owner names.  A content-based owner name is
-   derived from the content of the CERT RR data; for example, the
-   Subject field in an X.509 certificate or the User ID field in OpenPGP
-   keys.  A purpose-based owner name is a name that a client retrieving
-   CERT RRs ought to know already; for example, the host name of an
-   X.509 protected service or the Key ID of an OpenPGP key.  The
-   content-based and purpose-based owner name may be the same; for
-   example, when a client looks up a key based on the From: address of
-   an incoming email.
-
-   Implementations SHOULD use the purpose-based owner name guidelines
-   described in this document and MAY use CNAME RRs at content-based
-   owner names (or other names), pointing to the purpose-based owner
-   name.
-
-
-
-Josefsson                   Standards Track                     [Page 7]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-   Note that this section describes an application-based mapping from
-   the name space used in a certificate to the name space used by DNS.
-   The DNS does not infer any relationship amongst CERT resource records
-   based on similarities or differences of the DNS owner name(s) of CERT
-   resource records.  For example, if multiple labels are used when
-   mapping from a CERT identifier to a domain name, then care must be
-   taken in understanding wildcard record synthesis.
-
-3.1.  Content-Based X.509 CERT RR Names
-
-   Some X.509 versions, such as the PKIX profile of X.509 [8], permit
-   multiple names to be associated with subjects and issuers under
-   "Subject Alternative Name" and "Issuer Alternative Name".  For
-   example, the PKIX profile has such Alternate Names with an ASN.1
-   specification as follows:
-
-      GeneralName ::= CHOICE {
-           otherName                       [0]     OtherName,
-           rfc822Name                      [1]     IA5String,
-           dNSName                         [2]     IA5String,
-           x400Address                     [3]     ORAddress,
-           directoryName                   [4]     Name,
-           ediPartyName                    [5]     EDIPartyName,
-           uniformResourceIdentifier       [6]     IA5String,
-           iPAddress                       [7]     OCTET STRING,
-           registeredID                    [8]     OBJECT IDENTIFIER }
-
-   The recommended locations of CERT storage are as follows, in priority
-   order:
-
-   1.  If a domain name is included in the identification in the
-       certificate or CRL, that ought to be used.
-   2.  If a domain name is not included but an IP address is included,
-       then the translation of that IP address into the appropriate
-       inverse domain name ought to be used.
-   3.  If neither of the above is used, but a URI containing a domain
-       name is present, that domain name ought to be used.
-   4.  If none of the above is included but a character string name is
-       included, then it ought to be treated as described below for
-       OpenPGP names.
-   5.  If none of the above apply, then the distinguished name (DN)
-       ought to be mapped into a domain name as specified in [4].
-
-   Example 1: An X.509v3 certificate is issued to /CN=John Doe /DC=Doe/
-   DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative Names of (a)
-   string "John (the Man) Doe", (b) domain name john-doe.com, and (c)
-   URI <https://www.secure.john-doe.com:8080/>.  The storage locations
-   recommended, in priority order, would be
-
-
-
-Josefsson                   Standards Track                     [Page 8]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-   1.  john-doe.com,
-   2.  www.secure.john-doe.com, and
-   3.  Doe.com.xy.
-
-   Example 2: An X.509v3 certificate is issued to /CN=James Hacker/
-   L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names of (a)
-   domain name widget.foo.example, (b) IPv4 address 10.251.13.201, and
-   (c) string "James Hacker <hacker@mail.widget.foo.example>".  The
-   storage locations recommended, in priority order, would be
-
-   1.  widget.foo.example,
-   2.  201.13.251.10.in-addr.arpa, and
-   3.  hacker.mail.widget.foo.example.
-
-3.2.  Purpose-Based X.509 CERT RR Names
-
-   Due to the difficulty for clients that do not already possess a
-   certificate to reconstruct the content-based owner name,
-   purpose-based owner names are recommended in this section.
-   Recommendations for purpose-based owner names vary per scenario.  The
-   following table summarizes the purpose-based X.509 CERT RR owner name
-   guidelines for use with S/MIME [17], SSL/TLS [13], and IPsec [14]:
-
-    Scenario             Owner name
-    ------------------   ----------------------------------------------
-    S/MIME Certificate   Standard translation of an RFC 2822 email
-                         address.  Example: An S/MIME certificate for
-                         "postmaster@example.org" will use a standard
-                         hostname translation of the owner name,
-                         "postmaster.example.org".
-
-    TLS Certificate      Hostname of the TLS server.
-
-    IPsec Certificate    Hostname of the IPsec machine and/or, for IPv4
-                         or IPv6 addresses, the fully qualified domain
-                         name in the appropriate reverse domain.
-
-   An alternate approach for IPsec is to store raw public keys [18].
-
-3.3.  Content-Based OpenPGP CERT RR Names
-
-   OpenPGP signed keys (certificates) use a general character string
-   User ID [5].  However, it is recommended by OpenPGP that such names
-   include the RFC 2822 [7] email address of the party, as in "Leslie
-   Example <Leslie@host.example>".  If such a format is used, the CERT
-   ought to be under the standard translation of the email address into
-
-
-
-
-
-Josefsson                   Standards Track                     [Page 9]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-   a domain name, which would be leslie.host.example in this case.  If
-   no RFC 2822 name can be extracted from the string name, no specific
-   domain name is recommended.
-
-   If a user has more than one email address, the CNAME type can be used
-   to reduce the amount of data stored in the DNS.  For example:
-
-      $ORIGIN example.org.
-      smith        IN CERT PGP 0 0 <OpenPGP binary>
-      john.smith   IN CNAME smith
-      js           IN CNAME smith
-
-3.4.  Purpose-Based OpenPGP CERT RR Names
-
-   Applications that receive an OpenPGP packet containing encrypted or
-   signed data but do not know the email address of the sender will have
-   difficulties constructing the correct owner name and cannot use the
-   content-based owner name guidelines.  However, these clients commonly
-   know the key fingerprint or the Key ID.  The key ID is found in
-   OpenPGP packets, and the key fingerprint is commonly found in
-   auxiliary data that may be available.  In this case, use of an owner
-   name identical to the key fingerprint and the key ID expressed in
-   hexadecimal [16] is recommended.  For example:
-
-      $ORIGIN example.org.
-      0424D4EE81A0E3D119C6F835EDA21E94B565716F IN CERT PGP ...
-      F835EDA21E94B565716F                     IN CERT PGP ...
-      B565716F                                 IN CERT PGP ...
-
-   If the same key material is stored for several owner names, the use
-   of CNAME may help avoid data duplication.  Note that CNAME is not
-   always applicable, because it maps one owner name to the other for
-   all purposes, which may be sub-optimal when two keys with the same
-   Key ID are stored.
-
-3.5.  Owner Names for IPKIX, ISPKI, IPGP, and IACPKIX
-
-   These types are stored under the same owner names, both purpose- and
-   content-based, as the PKIX, SPKI, PGP, and ACPKIX types.
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                   Standards Track                    [Page 10]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-4.  Performance Considerations
-
-   The Domain Name System (DNS) protocol was designed for small
-   transfers, typically below 512 octets.  While larger transfers will
-   perform correctly and work is underway to make larger transfers more
-   efficient, it is still advisable at this time that every reasonable
-   effort be made to minimize the size of certificates stored within the
-   DNS.  Steps that can be taken may include using the fewest possible
-   optional or extension fields and using short field values for
-   necessary variable-length fields.
-
-   The RDATA field in the DNS protocol may only hold data of size 65535
-   octets (64kb) or less.  This means that each CERT RR MUST NOT contain
-   more than 64kb of payload, even if the corresponding certificate or
-   certificate revocation list is larger.  This document addresses this
-   by defining "indirect" data types for each normal type.
-
-   Deploying CERT RRs to support digitally signed email changes the
-   access patterns of DNS lookups from per-domain to per-user.  If
-   digitally signed email and a key/certificate lookup based on CERT RRs
-   are deployed on a wide scale, this may lead to an increased DNS load,
-   with potential performance and cache effectiveness consequences.
-   Whether or not this load increase will be noticeable is not known.
-
-5.  Contributors
-
-   The majority of this document is copied verbatim from RFC 2538, by
-   Donald Eastlake 3rd and Olafur Gudmundsson.
-
-6.  Acknowledgements
-
-   Thanks to David Shaw and Michael Graff for their contributions to
-   earlier works that motivated, and served as inspiration for, this
-   document.
-
-   This document was improved by suggestions and comments from Olivier
-   Dubuisson, Scott Hollenbeck, Russ Housley, Peter Koch, Olaf M.
-   Kolkman, Ben Laurie, Edward Lewis, John Loughney, Allison Mankin,
-   Douglas Otis, Marcos Sanz, Pekka Savola, Jason Sloderbeck, Samuel
-   Weiler, and Florian Weimer.  No doubt the list is incomplete.  We
-   apologize to anyone we left out.
-
-
-
-
-
-
-
-
-
-
-Josefsson                   Standards Track                    [Page 11]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-7.  Security Considerations
-
-   By definition, certificates contain their own authenticating
-   signatures.  Thus, it is reasonable to store certificates in
-   non-secure DNS zones or to retrieve certificates from DNS with DNS
-   security checking not implemented or deferred for efficiency.  The
-   results may be trusted if the certificate chain is verified back to a
-   known trusted key and this conforms with the user's security policy.
-
-   Alternatively, if certificates are retrieved from a secure DNS zone
-   with DNS security checking enabled and are verified by DNS security,
-   the key within the retrieved certificate may be trusted without
-   verifying the certificate chain if this conforms with the user's
-   security policy.
-
-   If an organization chooses to issue certificates for its employees,
-   placing CERT RRs in the DNS by owner name, and if DNSSEC (with NSEC)
-   is in use, it is possible for someone to enumerate all employees of
-   the organization.  This is usually not considered desirable, for the
-   same reason that enterprise phone listings are not often publicly
-   published and are even marked confidential.
-
-   Using the URI type introduces another level of indirection that may
-   open a new vulnerability.  One method of securing that indirection is
-   to include a hash of the certificate in the URI itself.
-
-   If DNSSEC is used, then the non-existence of a CERT RR and,
-   consequently, certificates or revocation lists can be securely
-   asserted.  Without DNSSEC, this is not possible.
-
-8.  IANA Considerations
-
-   The IANA has created a new registry for CERT RR: certificate types.
-   The initial contents of this registry is:
-
-       Decimal   Type     Meaning                           Reference
-       -------   ----     -------                           ---------
-             0            Reserved                          RFC 4398
-             1   PKIX     X.509 as per PKIX                 RFC 4398
-             2   SPKI     SPKI certificate                  RFC 4398
-             3   PGP      OpenPGP packet                    RFC 4398
-             4   IPKIX    The URL of an X.509 data object   RFC 4398
-             5   ISPKI    The URL of an SPKI certificate    RFC 4398
-             6   IPGP     The fingerprint and URL           RFC 4398
-                          of an OpenPGP packet
-             7   ACPKIX   Attribute Certificate             RFC 4398
-             8   IACPKIX  The URL of an Attribute           RFC 4398
-                             Certificate
-
-
-
-Josefsson                   Standards Track                    [Page 12]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-         9-252            Available for IANA assignment
-                             by IETF Standards action
-           253   URI      URI private                       RFC 4398
-           254   OID      OID private                       RFC 4398
-           255            Reserved                          RFC 4398
-     256-65279            Available for IANA assignment
-                          by IETF Consensus
-   65280-65534            Experimental                      RFC 4398
-         65535            Reserved                          RFC 4398
-
-   Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can
-   only be assigned by an IETF standards action [6].  This document
-   assigns 0x0001 through 0x0008 and 0x00FD and 0x00FE.  Certificate
-   types 0x0100 through 0xFEFF are assigned through IETF Consensus [6]
-   based on RFC documentation of the certificate type.  The availability
-   of private types under 0x00FD and 0x00FE ought to satisfy most
-   requirements for proprietary or private types.
-
-   The CERT RR reuses the DNS Security Algorithm Numbers registry.  In
-   particular, the CERT RR requires that algorithm number 0 remain
-   reserved, as described in Section 2.  The IANA will reference the
-   CERT RR as a user of this registry and value 0, in particular.
-
-9.  Changes since RFC 2538
-
-   1.   Editorial changes to conform with new document requirements,
-        including splitting reference section into two parts and
-        updating the references to point at latest versions, and to add
-        some additional references.
-   2.   Improve terminology.  For example replace "PGP" with "OpenPGP",
-        to align with RFC 2440.
-   3.   In Section 2.1, clarify that OpenPGP public key data are binary,
-        not the ASCII armored format, and reference 10.1 in RFC 2440 on
-        how to deal with OpenPGP keys, and acknowledge that
-        implementations may handle additional packet types.
-   4.   Clarify that integers in the representation format are decimal.
-   5.   Replace KEY/SIG with DNSKEY/RRSIG etc, to align with DNSSECbis
-        terminology.  Improve reference for Key Tag Algorithm
-        calculations.
-   6.   Add examples that suggest use of CNAME to reduce bandwidth.
-   7.   In Section 3, appended the last paragraphs that discuss
-        "content-based" vs "purpose-based" owner names.  Add Section 3.2
-        for purpose-based X.509 CERT owner names, and Section 3.4 for
-        purpose-based OpenPGP CERT owner names.
-   8.   Added size considerations.
-   9.   The SPKI types has been reserved, until RFC 2692/2693 is moved
-        from the experimental status.
-   10.  Added indirect types IPKIX, ISPKI, IPGP, and IACPKIX.
-
-
-
-Josefsson                   Standards Track                    [Page 13]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-   11.  An IANA registry of CERT type values was created.
-
-10.  References
-
-10.1.  Normative References
-
-   [1]   Mockapetris, P., "Domain names - concepts and facilities",
-         STD 13, RFC 1034, November 1987.
-
-   [2]   Mockapetris, P., "Domain names - implementation and
-         specification", STD 13, RFC 1035, November 1987.
-
-   [3]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
-         Levels", BCP 14, RFC 2119, March 1997.
-
-   [4]   Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. Sataluri,
-         "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247,
-         January 1998.
-
-   [5]   Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
-         "OpenPGP Message Format", RFC 2440, November 1998.
-
-   [6]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
-         Considerations Section in RFCs", BCP 26, RFC 2434,
-         October 1998.
-
-   [7]   Resnick, P., "Internet Message Format", RFC 2822, April 2001.
-
-   [8]   Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
-         Public Key Infrastructure Certificate and Certificate
-         Revocation List (CRL) Profile", RFC 3280, April 2002.
-
-   [9]   Farrell, S. and R. Housley, "An Internet Attribute Certificate
-         Profile for Authorization", RFC 3281, April 2002.
-
-   [10]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
-         Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
-         January 2005.
-
-   [11]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "DNS Security Introduction and Requirements", RFC 4033,
-         March 2005.
-
-   [12]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "Resource Records for the DNS Security Extensions", RFC 4034,
-         March 2005.
-
-
-
-
-
-Josefsson                   Standards Track                    [Page 14]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-10.2.  Informative References
-
-   [13]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
-         RFC 2246, January 1999.
-
-   [14]  Kent, S. and K. Seo, "Security Architecture for the Internet
-         Protocol", RFC 4301, December 2005.
-
-   [15]  Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B.,
-         and T. Ylonen, "SPKI Certificate Theory", RFC 2693,
-         September 1999.
-
-   [16]  Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
-         RFC 3548, July 2003.
-
-   [17]  Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
-         (S/MIME) Version 3.1 Message Specification", RFC 3851,
-         July 2004.
-
-   [18]  Richardson, M., "A Method for Storing IPsec Keying Material in
-         DNS", RFC 4025, March 2005.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                   Standards Track                    [Page 15]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-Appendix A.  Copying Conditions
-
-   Regarding the portion of this document that was written by Simon
-   Josefsson ("the author", for the remainder of this section), the
-   author makes no guarantees and is not responsible for any damage
-   resulting from its use.  The author grants irrevocable permission to
-   anyone to use, modify, and distribute it in any way that does not
-   diminish the rights of anyone else to use, modify, and distribute it,
-   provided that redistributed derivative works do not contain
-   misleading author or version information.  Derivative works need not
-   be licensed under similar terms.
-
-Author's Address
-
-   Simon Josefsson
-
-   EMail: simon@josefsson.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                   Standards Track                    [Page 16]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Josefsson                   Standards Track                    [Page 17]
-
diff --git a/contrib/bind9/doc/rfc/rfc4408.txt b/contrib/bind9/doc/rfc/rfc4408.txt
deleted file mode 100644
index bc1b3f5..0000000
--- a/contrib/bind9/doc/rfc/rfc4408.txt
+++ /dev/null
@@ -1,2691 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                            M. Wong
-Request for Comments: 4408                                    W. Schlitt
-Category: Experimental                                        April 2006
-
-
-                   Sender Policy Framework (SPF) for
-            Authorizing Use of Domains in E-Mail, Version 1
-
-Status of This Memo
-
-   This memo defines an Experimental Protocol for the Internet
-   community.  It does not specify an Internet standard of any kind.
-   Discussion and suggestions for improvement are requested.
-   Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-IESG Note
-
-   The following documents  (RFC 4405, RFC 4406, RFC 4407, and RFC 4408)
-   are published simultaneously as Experimental RFCs, although there is
-   no general technical consensus and efforts to reconcile the two
-   approaches have failed.  As such, these documents have not received
-   full IETF review and are published "AS-IS" to document the different
-   approaches as they were considered in the MARID working group.
-
-   The IESG takes no position about which approach is to be preferred
-   and cautions the reader that there are serious open issues for each
-   approach and concerns about using them in tandem.  The IESG believes
-   that documenting the different approaches does less harm than not
-   documenting them.
-
-   Note that the Sender ID experiment may use DNS records that may have
-   been created for the current SPF experiment or earlier versions in
-   this set of experiments.  Depending on the content of the record,
-   this may mean that Sender-ID heuristics would be applied incorrectly
-   to a message.  Depending on the actions associated by the recipient
-   with those heuristics, the message may not be delivered or may be
-   discarded on receipt.
-
-   Participants relying on Sender ID experiment DNS records are warned
-   that they may lose valid messages in this set of circumstances.
-   aParticipants publishing SPF experiment DNS records should consider
-   the advice given in section 3.4 of RFC 4406 and may wish to publish
-   both v=spf1 and spf2.0 records to avoid the conflict.
-
-
-
-
-Wong & Schlitt                Experimental                      [Page 1]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   Participants in the Sender-ID experiment need to be aware that the
-   way Resent-* header fields are used will result in failure to receive
-   legitimate email when interacting with standards-compliant systems
-   (specifically automatic forwarders which comply with the standards by
-   not adding Resent-* headers, and systems which comply with RFC 822
-   but have not yet implemented RFC 2822 Resent-* semantics).  It would
-   be inappropriate to advance Sender-ID on the standards track without
-   resolving this interoperability problem.
-
-   The community is invited to observe the success or failure of the two
-   approaches during the two years following publication, in order that
-   a community consensus can be reached in the future.
-
-Abstract
-
-   E-mail on the Internet can be forged in a number of ways.  In
-   particular, existing protocols place no restriction on what a sending
-   host can use as the reverse-path of a message or the domain given on
-   the SMTP HELO/EHLO commands.  This document describes version 1 of
-   the Sender Policy Framework (SPF) protocol, whereby a domain may
-   explicitly authorize the hosts that are allowed to use its domain
-   name, and a receiving host may check such authorization.
-
-Table of Contents
-
-   1. Introduction ....................................................4
-      1.1. Protocol Status ............................................4
-      1.2. Terminology ................................................5
-   2. Operation .......................................................5
-      2.1. The HELO Identity ..........................................5
-      2.2. The MAIL FROM Identity .....................................5
-      2.3. Publishing Authorization ...................................6
-      2.4. Checking Authorization .....................................6
-      2.5. Interpreting the Result ....................................7
-           2.5.1. None ................................................8
-           2.5.2. Neutral .............................................8
-           2.5.3. Pass ................................................8
-           2.5.4. Fail ................................................8
-           2.5.5. SoftFail ............................................9
-           2.5.6. TempError ...........................................9
-           2.5.7. PermError ...........................................9
-   3. SPF Records .....................................................9
-      3.1. Publishing ................................................10
-           3.1.1. DNS Resource Record Types ..........................10
-           3.1.2. Multiple DNS Records ...............................11
-           3.1.3. Multiple Strings in a Single DNS record ............11
-           3.1.4. Record Size ........................................11
-           3.1.5. Wildcard Records ...................................11
-
-
-
-Wong & Schlitt                Experimental                      [Page 2]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   4. The check_host() Function ......................................12
-      4.1. Arguments .................................................12
-      4.2. Results ...................................................13
-      4.3. Initial Processing ........................................13
-      4.4. Record Lookup .............................................13
-      4.5. Selecting Records .........................................13
-      4.6. Record Evaluation .........................................14
-           4.6.1. Term Evaluation ....................................14
-           4.6.2. Mechanisms .........................................15
-           4.6.3. Modifiers ..........................................15
-      4.7. Default Result ............................................16
-      4.8. Domain Specification ......................................16
-   5. Mechanism Definitions ..........................................16
-      5.1. "all" .....................................................17
-      5.2. "include" .................................................18
-      5.3. "a" .......................................................19
-      5.4. "mx" ......................................................20
-      5.5. "ptr" .....................................................20
-      5.6. "ip4" and "ip6" ...........................................21
-      5.7. "exists" ..................................................22
-   6. Modifier Definitions ...........................................22
-      6.1. redirect: Redirected Query ................................23
-      6.2. exp: Explanation ..........................................23
-   7. The Received-SPF Header Field ..................................25
-   8. Macros .........................................................27
-      8.1. Macro Definitions .........................................27
-      8.2. Expansion Examples ........................................30
-   9. Implications ...................................................31
-      9.1. Sending Domains ...........................................31
-      9.2. Mailing Lists .............................................32
-      9.3. Forwarding Services and Aliases ...........................32
-      9.4. Mail Services .............................................34
-      9.5. MTA Relays ................................................34
-   10. Security Considerations .......................................35
-      10.1. Processing Limits ........................................35
-      10.2. SPF-Authorized E-Mail May Contain Other False
-            Identities ...............................................37
-      10.3. Spoofed DNS and IP Data ..................................37
-      10.4. Cross-User Forgery .......................................37
-      10.5. Untrusted Information Sources ............................38
-      10.6. Privacy Exposure .........................................38
-   11. Contributors and Acknowledgements .............................38
-   12. IANA Considerations ...........................................39
-      12.1. The SPF DNS Record Type ..................................39
-      12.2. The Received-SPF Mail Header Field .......................39
-   13. References ....................................................39
-      13.1. Normative References .....................................39
-      13.2. Informative References ...................................40
-
-
-
-Wong & Schlitt                Experimental                      [Page 3]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   Appendix A.  Collected ABNF .......................................42
-   Appendix B.  Extended Examples ....................................44
-      B.1.  Simple Examples ..........................................44
-      B.2.  Multiple Domain Example ..................................45
-      B.3.  DNSBL Style Example ......................................46
-      B.4.  Multiple Requirements Example ............................46
-
-1.  Introduction
-
-   The current E-Mail infrastructure has the property that any host
-   injecting mail into the mail system can identify itself as any domain
-   name it wants.  Hosts can do this at a variety of levels: in
-   particular, the session, the envelope, and the mail headers.
-   Although this feature is desirable in some circumstances, it is a
-   major obstacle to reducing Unsolicited Bulk E-Mail (UBE, aka spam).
-   Furthermore, many domain name holders are understandably concerned
-   about the ease with which other entities may make use of their domain
-   names, often with malicious intent.
-
-   This document defines a protocol by which domain owners may authorize
-   hosts to use their domain name in the "MAIL FROM" or "HELO" identity.
-   Compliant domain holders publish Sender Policy Framework (SPF)
-   records specifying which hosts are permitted to use their names, and
-   compliant mail receivers use the published SPF records to test the
-   authorization of sending Mail Transfer Agents (MTAs) using a given
-   "HELO" or "MAIL FROM" identity during a mail transaction.
-
-   An additional benefit to mail receivers is that after the use of an
-   identity is verified, local policy decisions about the mail can be
-   made based on the sender's domain, rather than the host's IP address.
-   This is advantageous because reputation of domain names is likely to
-   be more accurate than reputation of host IP addresses.  Furthermore,
-   if a claimed identity fails verification, local policy can take
-   stronger action against such E-Mail, such as rejecting it.
-
-1.1.  Protocol Status
-
-   SPF has been in development since the summer of 2003 and has seen
-   deployment beyond the developers beginning in December 2003.  The
-   design of SPF slowly evolved until the spring of 2004 and has since
-   stabilized.  There have been quite a number of forms of SPF, some
-   written up as documents, some submitted as Internet Drafts, and many
-   discussed and debated in development forums.
-
-   The goal of this document is to clearly document the protocol defined
-   by earlier draft specifications of SPF as used in existing
-   implementations.  This conception of SPF is sometimes called "SPF
-   Classic".  It is understood that particular implementations and
-
-
-
-Wong & Schlitt                Experimental                      [Page 4]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   deployments may differ from, and build upon, this work.  It is hoped
-   that we have nonetheless captured the common understanding of SPF
-   version 1.
-
-1.2.  Terminology
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-   This document is concerned with the portion of a mail message
-   commonly called "envelope sender", "return path", "reverse path",
-   "bounce address", "2821 FROM", or "MAIL FROM".  Since these terms are
-   either not well defined or often used casually, this document defines
-   the "MAIL FROM" identity in Section 2.2.  Note that other terms that
-   may superficially look like the common terms, such as "reverse-path",
-   are used only with the defined meanings from normative documents.
-
-2.  Operation
-
-2.1.  The HELO Identity
-
-   The "HELO" identity derives from either the SMTP HELO or EHLO command
-   (see [RFC2821]).  These commands supply the SMTP client (sending
-   host) for the SMTP session.  Note that requirements for the domain
-   presented in the EHLO or HELO command are not always clear to the
-   sending party, and SPF clients must be prepared for the "HELO"
-   identity to be malformed or an IP address literal.  At the time of
-   this writing, many legitimate E-Mails are delivered with invalid HELO
-   domains.
-
-   It is RECOMMENDED that SPF clients not only check the "MAIL FROM"
-   identity, but also separately check the "HELO" identity by applying
-   the check_host() function (Section 4) to the "HELO" identity as the
-   <sender>.
-
-2.2.  The MAIL FROM Identity
-
-   The "MAIL FROM" identity derives from the SMTP MAIL command (see
-   [RFC2821]).  This command supplies the "reverse-path" for a message,
-   which generally consists of the sender mailbox, and is the mailbox to
-   which notification messages are to be sent if there are problems
-   delivering the message.
-
-   [RFC2821] allows the reverse-path to be null (see Section 4.5.5 in
-   RFC 2821).  In this case, there is no explicit sender mailbox, and
-   such a message can be assumed to be a notification message from the
-   mail system itself.  When the reverse-path is null, this document
-
-
-
-Wong & Schlitt                Experimental                      [Page 5]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   defines the "MAIL FROM" identity to be the mailbox composed of the
-   localpart "postmaster" and the "HELO" identity (which may or may not
-   have been checked separately before).
-
-   SPF clients MUST check the "MAIL FROM" identity.  SPF clients check
-   the "MAIL FROM" identity by applying the check_host() function to the
-   "MAIL FROM" identity as the <sender>.
-
-2.3.  Publishing Authorization
-
-   An SPF-compliant domain MUST publish a valid SPF record as described
-   in Section 3.  This record authorizes the use of the domain name in
-   the "HELO" and "MAIL FROM" identities by the MTAs it specifies.
-
-   If domain owners choose to publish SPF records, it is RECOMMENDED
-   that they end in "-all", or redirect to other records that do, so
-   that a definitive determination of authorization can be made.
-
-   Domain holders may publish SPF records that explicitly authorize no
-   hosts if mail should never originate using that domain.
-
-   When changing SPF records, care must be taken to ensure that there is
-   a transition period so that the old policy remains valid until all
-   legitimate E-Mail has been checked.
-
-2.4.  Checking Authorization
-
-   A mail receiver can perform a set of SPF checks for each mail message
-   it receives.  An SPF check tests the authorization of a client host
-   to emit mail with a given identity.  Typically, such checks are done
-   by a receiving MTA, but can be performed elsewhere in the mail
-   processing chain so long as the required information is available and
-   reliable.  At least the "MAIL FROM" identity MUST be checked, but it
-   is RECOMMENDED that the "HELO" identity also be checked beforehand.
-
-   Without explicit approval of the domain owner, checking other
-   identities against SPF version 1 records is NOT RECOMMENDED because
-   there are cases that are known to give incorrect results.  For
-   example, almost all mailing lists rewrite the "MAIL FROM" identity
-   (see Section 9.2), but some do not change any other identities in the
-   message.  The scenario described in Section 9.3, sub-section 1.2, is
-   another example.  Documents that define other identities should
-   define the method for explicit approval.
-
-   It is possible that mail receivers will use the SPF check as part of
-   a larger set of tests on incoming mail.  The results of other tests
-   may influence whether or not a particular SPF check is performed.
-   For example, finding the sending host's IP address on a local white
-
-
-
-Wong & Schlitt                Experimental                      [Page 6]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   list may cause all other tests to be skipped and all mail from that
-   host to be accepted.
-
-   When a mail receiver decides to perform an SPF check, it MUST use a
-   correctly-implemented check_host() function (Section 4) evaluated
-   with the correct parameters.  Although the test as a whole is
-   optional, once it has been decided to perform a test it must be
-   performed as specified so that the correct semantics are preserved
-   between publisher and receiver.
-
-   To make the test, the mail receiver MUST evaluate the check_host()
-   function with the arguments set as follows:
-
-   <ip>     - the IP address of the SMTP client that is emitting the
-              mail, either IPv4 or IPv6.
-
-   <domain> - the domain portion of the "MAIL FROM" or "HELO" identity.
-
-   <sender> - the "MAIL FROM" or "HELO" identity.
-
-   Note that the <domain> argument may not be a well-formed domain name.
-   For example, if the reverse-path was null, then the EHLO/HELO domain
-   is used, with its associated problems (see Section 2.1).  In these
-   cases, check_host() is defined in Section 4.3 to return a "None"
-   result.
-
-   Although invalid, malformed, or non-existent domains cause SPF checks
-   to return "None" because no SPF record can be found, it has long been
-   the policy of many MTAs to reject E-Mail from such domains,
-   especially in the case of invalid "MAIL FROM".  In order to prevent
-   the circumvention of SPF records, rejecting E-Mail from invalid
-   domains should be considered.
-
-   Implementations must take care to correctly extract the <domain> from
-   the data given with the SMTP MAIL FROM command as many MTAs will
-   still accept such things as source routes (see [RFC2821], Appendix
-   C), the %-hack (see [RFC1123]), and bang paths (see [RFC1983]).
-   These archaic features have been maliciously used to bypass security
-   systems.
-
-2.5.  Interpreting the Result
-
-   This section describes how software that performs the authorization
-   should interpret the results of the check_host() function.  The
-   authorization check SHOULD be performed during the processing of the
-   SMTP transaction that sends the mail.  This allows errors to be
-   returned directly to the sending MTA by way of SMTP replies.
-
-
-
-
-Wong & Schlitt                Experimental                      [Page 7]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   Performing the authorization after the SMTP transaction has finished
-   may cause problems, such as the following: (1) It may be difficult to
-   accurately extract the required information from potentially
-   deceptive headers; (2) legitimate E-Mail may fail because the
-   sender's policy may have since changed.
-
-   Generating non-delivery notifications to forged identities that have
-   failed the authorization check is generally abusive and against the
-   explicit wishes of the identity owner.
-
-2.5.1.  None
-
-   A result of "None" means that no records were published by the domain
-   or that no checkable sender domain could be determined from the given
-   identity.  The checking software cannot ascertain whether or not the
-   client host is authorized.
-
-2.5.2.  Neutral
-
-   The domain owner has explicitly stated that he cannot or does not
-   want to assert whether or not the IP address is authorized.  A
-   "Neutral" result MUST be treated exactly like the "None" result; the
-   distinction exists only for informational purposes.  Treating
-   "Neutral" more harshly than "None" would discourage domain owners
-   from testing the use of SPF records (see Section 9.1).
-
-2.5.3.  Pass
-
-   A "Pass" result means that the client is authorized to inject mail
-   with the given identity.  The domain can now, in the sense of
-   reputation, be considered responsible for sending the message.
-   Further policy checks can now proceed with confidence in the
-   legitimate use of the identity.
-
-2.5.4.  Fail
-
-   A "Fail" result is an explicit statement that the client is not
-   authorized to use the domain in the given identity.  The checking
-   software can choose to mark the mail based on this or to reject the
-   mail outright.
-
-   If the checking software chooses to reject the mail during the SMTP
-   transaction, then it SHOULD use an SMTP reply code of 550 (see
-   [RFC2821]) and, if supported, the 5.7.1 Delivery Status Notification
-   (DSN) code (see [RFC3464]), in addition to an appropriate reply text.
-   The check_host() function may return either a default explanation
-   string or one from the domain that published the SPF records (see
-   Section 6.2).  If the information does not originate with the
-
-
-
-Wong & Schlitt                Experimental                      [Page 8]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   checking software, it should be made clear that the text is provided
-   by the sender's domain.  For example:
-
-       550-5.7.1 SPF MAIL FROM check failed:
-       550-5.7.1 The domain example.com explains:
-       550 5.7.1 Please see http://www.example.com/mailpolicy.html
-
-2.5.5.  SoftFail
-
-   A "SoftFail" result should be treated as somewhere between a "Fail"
-   and a "Neutral".  The domain believes the host is not authorized but
-   is not willing to make that strong of a statement.  Receiving
-   software SHOULD NOT reject the message based solely on this result,
-   but MAY subject the message to closer scrutiny than normal.
-
-   The domain owner wants to discourage the use of this host and thus
-   desires limited feedback when a "SoftFail" result occurs.  For
-   example, the recipient's Mail User Agent (MUA) could highlight the
-   "SoftFail" status, or the receiving MTA could give the sender a
-   message using a technique called "greylisting" whereby the MTA can
-   issue an SMTP reply code of 451 (4.3.0 DSN code) with a note the
-   first time the message is received, but accept it the second time.
-
-2.5.6.  TempError
-
-   A "TempError" result means that the SPF client encountered a
-   transient error while performing the check.  Checking software can
-   choose to accept or temporarily reject the message.  If the message
-   is rejected during the SMTP transaction for this reason, the software
-   SHOULD use an SMTP reply code of 451 and, if supported, the 4.4.3 DSN
-   code.
-
-2.5.7.  PermError
-
-   A "PermError" result means that the domain's published records could
-   not be correctly interpreted.  This signals an error condition that
-   requires manual intervention to be resolved, as opposed to the
-   TempError result.  Be aware that if the domain owner uses macros
-   (Section 8), it is possible that this result is due to the checked
-   identities having an unexpected format.
-
-3.  SPF Records
-
-   An SPF record is a DNS Resource Record (RR) that declares which hosts
-   are, and are not, authorized to use a domain name for the "HELO" and
-   "MAIL FROM" identities.  Loosely, the record partitions all hosts
-   into permitted and not-permitted sets (though some hosts might fall
-   into neither category).
-
-
-
-Wong & Schlitt                Experimental                      [Page 9]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   The SPF record is a single string of text.  An example record is the
-   following:
-
-      v=spf1 +mx a:colo.example.com/28 -all
-
-   This record has a version of "spf1" and three directives: "+mx",
-   "a:colo.example.com/28" (the + is implied), and "-all".
-
-3.1.  Publishing
-
-   Domain owners wishing to be SPF compliant must publish SPF records
-   for the hosts that are used in the "MAIL FROM" and "HELO" identities.
-   The SPF records are placed in the DNS tree at the host name it
-   pertains to, not a subdomain under it, such as is done with SRV
-   records.  This is the same whether the TXT or SPF RR type (see
-   Section 3.1.1) is used.
-
-   The example above in Section 3 might be published via these lines in
-   a domain zone file:
-
-      example.com.          TXT "v=spf1 +mx a:colo.example.com/28 -all"
-      smtp-out.example.com. TXT "v=spf1 a -all"
-
-   When publishing via TXT records, beware of other TXT records
-   published there for other purposes.  They may cause problems with
-   size limits (see Section 3.1.4).
-
-3.1.1.  DNS Resource Record Types
-
-   This document defines a new DNS RR of type SPF, code 99.  The format
-   of this type is identical to the TXT RR [RFC1035].  For either type,
-   the character content of the record is encoded as [US-ASCII].
-
-   It is recognized that the current practice (using a TXT record) is
-   not optimal, but it is necessary because there are a number of DNS
-   server and resolver implementations in common use that cannot handle
-   the new RR type.  The two-record-type scheme provides a forward path
-   to the better solution of using an RR type reserved for this purpose.
-
-   An SPF-compliant domain name SHOULD have SPF records of both RR
-   types.  A compliant domain name MUST have a record of at least one
-   type.  If a domain has records of both types, they MUST have
-   identical content.  For example, instead of publishing just one
-   record as in Section 3.1 above, it is better to publish:
-
-      example.com. IN TXT "v=spf1 +mx a:colo.example.com/28 -all"
-      example.com. IN SPF "v=spf1 +mx a:colo.example.com/28 -all"
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 10]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   Example RRs in this document are shown with the TXT record type;
-   however, they could be published with the SPF type or with both
-   types.
-
-3.1.2.  Multiple DNS Records
-
-   A domain name MUST NOT have multiple records that would cause an
-   authorization check to select more than one record.  See Section 4.5
-   for the selection rules.
-
-3.1.3.  Multiple Strings in a Single DNS record
-
-   As defined in [RFC1035] sections 3.3.14 and 3.3, a single text DNS
-   record (either TXT or SPF RR types) can be composed of more than one
-   string.  If a published record contains multiple strings, then the
-   record MUST be treated as if those strings are concatenated together
-   without adding spaces.  For example:
-
-      IN TXT "v=spf1 .... first" "second string..."
-
-   MUST be treated as equivalent to
-
-      IN TXT "v=spf1 .... firstsecond string..."
-
-   SPF or TXT records containing multiple strings are useful in
-   constructing records that would exceed the 255-byte maximum length of
-   a string within a single TXT or SPF RR record.
-
-3.1.4.  Record Size
-
-   The published SPF record for a given domain name SHOULD remain small
-   enough that the results of a query for it will fit within 512 octets.
-   This will keep even older DNS implementations from falling over to
-   TCP.  Since the answer size is dependent on many things outside the
-   scope of this document, it is only possible to give this guideline:
-   If the combined length of the DNS name and the text of all the
-   records of a given type (TXT or SPF) is under 450 characters, then
-   DNS answers should fit in UDP packets.  Note that when computing the
-   sizes for queries of the TXT format, one must take into account any
-   other TXT records published at the domain name.  Records that are too
-   long to fit in a single UDP packet MAY be silently ignored by SPF
-   clients.
-
-3.1.5.  Wildcard Records
-
-   Use of wildcard records for publishing is not recommended.  Care must
-   be taken if wildcard records are used.  If a domain publishes
-   wildcard MX records, it may want to publish wildcard declarations,
-
-
-
-Wong & Schlitt                Experimental                     [Page 11]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   subject to the same requirements and problems.  In particular, the
-   declaration must be repeated for any host that has any RR records at
-   all, and for subdomains thereof.  For example, the example given in
-   [RFC1034], Section 4.3.3, could be extended with the following:
-
-       X.COM.          MX      10      A.X.COM
-       X.COM.          TXT     "v=spf1 a:A.X.COM -all"
-
-       *.X.COM.        MX      10      A.X.COM
-       *.X.COM.        TXT     "v=spf1 a:A.X.COM -all"
-
-       A.X.COM.        A       1.2.3.4
-       A.X.COM.        MX      10      A.X.COM
-       A.X.COM.        TXT     "v=spf1 a:A.X.COM -all"
-
-       *.A.X.COM.      MX      10      A.X.COM
-       *.A.X.COM.      TXT     "v=spf1 a:A.X.COM -all"
-
-   Notice that SPF records must be repeated twice for every name within
-   the domain: once for the name, and once with a wildcard to cover the
-   tree under the name.
-
-   Use of wildcards is discouraged in general as they cause every name
-   under the domain to exist and queries against arbitrary names will
-   never return RCODE 3 (Name Error).
-
-4.  The check_host() Function
-
-   The check_host() function fetches SPF records, parses them, and
-   interprets them to determine whether a particular host is or is not
-   permitted to send mail with a given identity.  Mail receivers that
-   perform this check MUST correctly evaluate the check_host() function
-   as described here.
-
-   Implementations MAY use a different algorithm than the canonical
-   algorithm defined here, so long as the results are the same in all
-   cases.
-
-4.1.  Arguments
-
-   The check_host() function takes these arguments:
-
-   <ip>     - the IP address of the SMTP client that is emitting the
-              mail, either IPv4 or IPv6.
-
-   <domain> - the domain that provides the sought-after authorization
-              information; initially, the domain portion of the "MAIL
-              FROM" or "HELO" identity.
-
-
-
-Wong & Schlitt                Experimental                     [Page 12]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   <sender> - the "MAIL FROM" or "HELO" identity.
-
-   The domain portion of <sender> will usually be the same as the
-   <domain> argument when check_host() is initially evaluated.  However,
-   this will generally not be true for recursive evaluations (see
-   Section 5.2 below).
-
-   Actual implementations of the check_host() function may need
-   additional arguments.
-
-4.2.  Results
-
-   The function check_host() can return one of several results described
-   in Section 2.5.  Based on the result, the action to be taken is
-   determined by the local policies of the receiver.
-
-4.3.  Initial Processing
-
-   If the <domain> is malformed (label longer than 63 characters, zero-
-   length label not at the end, etc.) or is not a fully qualified domain
-   name, or if the DNS lookup returns "domain does not exist" (RCODE 3),
-   check_host() immediately returns the result "None".
-
-   If the <sender> has no localpart, substitute the string "postmaster"
-   for the localpart.
-
-4.4.  Record Lookup
-
-   In accordance with how the records are published (see Section 3.1
-   above), a DNS query needs to be made for the <domain> name, querying
-   for either RR type TXT, SPF, or both.  If both SPF and TXT RRs are
-   looked up, the queries MAY be done in parallel.
-
-   If all DNS lookups that are made return a server failure (RCODE 2),
-   or other error (RCODE other than 0 or 3), or time out, then
-   check_host() exits immediately with the result "TempError".
-
-4.5.  Selecting Records
-
-   Records begin with a version section:
-
-   record           = version terms *SP
-   version          = "v=spf1"
-
-   Starting with the set of records that were returned by the lookup,
-   record selection proceeds in two steps:
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 13]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   1. Records that do not begin with a version section of exactly
-      "v=spf1" are discarded.  Note that the version section is
-      terminated either by an SP character or the end of the record.  A
-      record with a version section of "v=spf10" does not match and must
-      be discarded.
-
-   2. If any records of type SPF are in the set, then all records of
-      type TXT are discarded.
-
-   After the above steps, there should be exactly one record remaining
-   and evaluation can proceed.  If there are two or more records
-   remaining, then check_host() exits immediately with the result of
-   "PermError".
-
-   If no matching records are returned, an SPF client MUST assume that
-   the domain makes no SPF declarations.  SPF processing MUST stop and
-   return "None".
-
-4.6.  Record Evaluation
-
-   After one SPF record has been selected, the check_host() function
-   parses and interprets it to find a result for the current test.  If
-   there are any syntax errors, check_host() returns immediately with
-   the result "PermError".
-
-   Implementations MAY choose to parse the entire record first and
-   return "PermError" if the record is not syntactically well formed.
-   However, in all cases, any syntax errors anywhere in the record MUST
-   be detected.
-
-4.6.1.  Term Evaluation
-
-   There are two types of terms: mechanisms and modifiers.  A record
-   contains an ordered list of these as specified in the following
-   Augmented Backus-Naur Form (ABNF).
-
-   terms            = *( 1*SP ( directive / modifier ) )
-
-   directive        = [ qualifier ] mechanism
-   qualifier        = "+" / "-" / "?" / "~"
-   mechanism        = ( all / include
-                      / A / MX / PTR / IP4 / IP6 / exists )
-   modifier         = redirect / explanation / unknown-modifier
-   unknown-modifier = name "=" macro-string
-
-   name             = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." )
-
-   Most mechanisms allow a ":" or "/" character after the name.
-
-
-
-Wong & Schlitt                Experimental                     [Page 14]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   Modifiers always contain an equals ('=') character immediately after
-   the name, and before any ":" or "/" characters that may be part of
-   the macro-string.
-
-   Terms that do not contain any of "=", ":", or "/" are mechanisms, as
-   defined in Section 5.
-
-   As per the definition of the ABNF notation in [RFC4234], mechanism
-   and modifier names are case-insensitive.
-
-4.6.2.  Mechanisms
-
-   Each mechanism is considered in turn from left to right.  If there
-   are no more mechanisms, the result is specified in Section 4.7.
-
-   When a mechanism is evaluated, one of three things can happen: it can
-   match, not match, or throw an exception.
-
-   If it matches, processing ends and the qualifier value is returned as
-   the result of that record.  If it does not match, processing
-   continues with the next mechanism.  If it throws an exception,
-   mechanism processing ends and the exception value is returned.
-
-   The possible qualifiers, and the results they return are as follows:
-
-      "+" Pass
-      "-" Fail
-      "~" SoftFail
-      "?" Neutral
-
-   The qualifier is optional and defaults to "+".
-
-   When a mechanism matches and the qualifier is "-", then a "Fail"
-   result is returned and the explanation string is computed as
-   described in Section 6.2.
-
-   The specific mechanisms are described in Section 5.
-
-4.6.3.  Modifiers
-
-   Modifiers are not mechanisms: they do not return match or not-match.
-   Instead they provide additional information.  Although modifiers do
-   not directly affect the evaluation of the record, the "redirect"
-   modifier has an effect after all the mechanisms have been evaluated.
-
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 15]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-4.7.  Default Result
-
-   If none of the mechanisms match and there is no "redirect" modifier,
-   then the check_host() returns a result of "Neutral", just as if
-   "?all" were specified as the last directive.  If there is a
-   "redirect" modifier, check_host() proceeds as defined in Section 6.1.
-
-   Note that records SHOULD always use either a "redirect" modifier or
-   an "all" mechanism to explicitly terminate processing.
-
-   For example:
-
-      v=spf1 +mx -all
-   or
-      v=spf1 +mx redirect=_spf.example.com
-
-4.8.  Domain Specification
-
-   Several of these mechanisms and modifiers have a <domain-spec>
-   section.  The <domain-spec> string is macro expanded (see Section 8).
-   The resulting string is the common presentation form of a fully-
-   qualified DNS name: a series of labels separated by periods.  This
-   domain is called the <target-name> in the rest of this document.
-
-   Note: The result of the macro expansion is not subject to any further
-   escaping.  Hence, this facility cannot produce all characters that
-   are legal in a DNS label (e.g., the control characters).  However,
-   this facility is powerful enough to express legal host names and
-   common utility labels (such as "_spf") that are used in DNS.
-
-   For several mechanisms, the <domain-spec> is optional.  If it is not
-   provided, the <domain> is used as the <target-name>.
-
-5.  Mechanism Definitions
-
-   This section defines two types of mechanisms.
-
-   Basic mechanisms contribute to the language framework.  They do not
-   specify a particular type of authorization scheme.
-
-      all
-      include
-
-   Designated sender mechanisms are used to designate a set of <ip>
-   addresses as being permitted or not permitted to use the <domain> for
-   sending mail.
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 16]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-      a
-      mx
-      ptr
-      ip4
-      ip6
-      exists
-
-   The following conventions apply to all mechanisms that perform a
-   comparison between <ip> and an IP address at any point:
-
-   If no CIDR-length is given in the directive, then <ip> and the IP
-   address are compared for equality. (Here, CIDR is Classless Inter-
-   Domain Routing.)
-
-   If a CIDR-length is specified, then only the specified number of
-   high-order bits of <ip> and the IP address are compared for equality.
-
-   When any mechanism fetches host addresses to compare with <ip>, when
-   <ip> is an IPv4 address, A records are fetched, when <ip> is an IPv6
-   address, AAAA records are fetched.  Even if the SMTP connection is
-   via IPv6, an IPv4-mapped IPv6 IP address (see [RFC3513], Section
-   2.5.5) MUST still be considered an IPv4 address.
-
-   Several mechanisms rely on information fetched from DNS.  For these
-   DNS queries, except where noted, if the DNS server returns an error
-   (RCODE other than 0 or 3) or the query times out, the mechanism
-   throws the exception "TempError".  If the server returns "domain does
-   not exist" (RCODE 3), then evaluation of the mechanism continues as
-   if the server returned no error (RCODE 0) and zero answer records.
-
-5.1.  "all"
-
-   all              = "all"
-
-   The "all" mechanism is a test that always matches.  It is used as the
-   rightmost mechanism in a record to provide an explicit default.
-
-   For example:
-
-      v=spf1 a mx -all
-
-   Mechanisms after "all" will never be tested.  Any "redirect" modifier
-   (Section 6.1) has no effect when there is an "all" mechanism.
-
-
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 17]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-5.2.  "include"
-
-      include          = "include"  ":" domain-spec
-
-   The "include" mechanism triggers a recursive evaluation of
-   check_host().  The domain-spec is expanded as per Section 8.  Then
-   check_host() is evaluated with the resulting string as the <domain>.
-   The <ip> and <sender> arguments remain the same as in the current
-   evaluation of check_host().
-
-   In hindsight, the name "include" was poorly chosen.  Only the
-   evaluated result of the referenced SPF record is used, rather than
-   acting as if the referenced SPF record was literally included in the
-   first.  For example, evaluating a "-all" directive in the referenced
-   record does not terminate the overall processing and does not
-   necessarily result in an overall "Fail".  (Better names for this
-   mechanism would have been "if-pass", "on-pass", etc.)
-
-   The "include" mechanism makes it possible for one domain to designate
-   multiple administratively-independent domains.  For example, a vanity
-   domain "example.net" might send mail using the servers of
-   administratively-independent domains example.com and example.org.
-
-   Example.net could say
-
-      IN TXT "v=spf1 include:example.com include:example.org -all"
-
-   This would direct check_host() to, in effect, check the records of
-   example.com and example.org for a "Pass" result.  Only if the host
-   were not permitted for either of those domains would the result be
-   "Fail".
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 18]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   Whether this mechanism matches, does not match, or throws an
-   exception depends on the result of the recursive evaluation of
-   check_host():
-
-   +---------------------------------+---------------------------------+
-   | A recursive check_host() result | Causes the "include" mechanism  |
-   | of:                             | to:                             |
-   +---------------------------------+---------------------------------+
-   | Pass                            | match                           |
-   |                                 |                                 |
-   | Fail                            | not match                       |
-   |                                 |                                 |
-   | SoftFail                        | not match                       |
-   |                                 |                                 |
-   | Neutral                         | not match                       |
-   |                                 |                                 |
-   | TempError                       | throw TempError                 |
-   |                                 |                                 |
-   | PermError                       | throw PermError                 |
-   |                                 |                                 |
-   | None                            | throw PermError                 |
-   +---------------------------------+---------------------------------+
-
-   The "include" mechanism is intended for crossing administrative
-   boundaries.  Although it is possible to use includes to consolidate
-   multiple domains that share the same set of designated hosts, domains
-   are encouraged to use redirects where possible, and to minimize the
-   number of includes within a single administrative domain.  For
-   example, if example.com and example.org were managed by the same
-   entity, and if the permitted set of hosts for both domains was
-   "mx:example.com", it would be possible for example.org to specify
-   "include:example.com", but it would be preferable to specify
-   "redirect=example.com" or even "mx:example.com".
-
-5.3.  "a"
-
-   This mechanism matches if <ip> is one of the <target-name>'s IP
-   addresses.
-
-   A                = "a"      [ ":" domain-spec ] [ dual-cidr-length ]
-
-   An address lookup is done on the <target-name>.  The <ip> is compared
-   to the returned address(es).  If any address matches, the mechanism
-   matches.
-
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 19]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-5.4.  "mx"
-
-   This mechanism matches if <ip> is one of the MX hosts for a domain
-   name.
-
-   MX               = "mx"     [ ":" domain-spec ] [ dual-cidr-length ]
-
-   check_host() first performs an MX lookup on the <target-name>.  Then
-   it performs an address lookup on each MX name returned.  The <ip> is
-   compared to each returned IP address.  To prevent Denial of Service
-   (DoS) attacks, more than 10 MX names MUST NOT be looked up during the
-   evaluation of an "mx" mechanism (see Section 10).  If any address
-   matches, the mechanism matches.
-
-   Note regarding implicit MXs: If the <target-name> has no MX records,
-   check_host() MUST NOT pretend the target is its single MX, and MUST
-   NOT default to an A lookup on the <target-name> directly.  This
-   behavior breaks with the legacy "implicit MX" rule.  See [RFC2821],
-   Section 5.  If such behavior is desired, the publisher should specify
-   an "a" directive.
-
-5.5.  "ptr"
-
-   This mechanism tests whether the DNS reverse-mapping for <ip> exists
-   and correctly points to a domain name within a particular domain.
-
-   PTR              = "ptr"    [ ":" domain-spec ]
-
-   First, the <ip>'s name is looked up using this procedure: perform a
-   DNS reverse-mapping for <ip>, looking up the corresponding PTR record
-   in "in-addr.arpa." if the address is an IPv4 one and in "ip6.arpa."
-   if it is an IPv6 address.  For each record returned, validate the
-   domain name by looking up its IP address.  To prevent DoS attacks,
-   more than 10 PTR names MUST NOT be looked up during the evaluation of
-   a "ptr" mechanism (see Section 10).  If <ip> is among the returned IP
-   addresses, then that domain name is validated.  In pseudocode:
-
-   sending-domain_names := ptr_lookup(sending-host_IP); if more than 10
-   sending-domain_names are found, use at most 10.  for each name in
-   (sending-domain_names) {
-     IP_addresses := a_lookup(name);
-     if the sending-domain_IP is one of the IP_addresses {
-       validated-sending-domain_names += name;
-     } }
-
-   Check all validated domain names to see if they end in the
-   <target-name> domain.  If any do, this mechanism matches.  If no
-   validated domain name can be found, or if none of the validated
-
-
-
-Wong & Schlitt                Experimental                     [Page 20]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   domain names end in the <target-name>, this mechanism fails to match.
-   If a DNS error occurs while doing the PTR RR lookup, then this
-   mechanism fails to match.  If a DNS error occurs while doing an A RR
-   lookup, then that domain name is skipped and the search continues.
-
-   Pseudocode:
-
-   for each name in (validated-sending-domain_names) {
-     if name ends in <domain-spec>, return match.
-     if name is <domain-spec>, return match.
-   }
-   return no-match.
-
-   This mechanism matches if the <target-name> is either an ancestor of
-   a validated domain name or if the <target-name> and a validated
-   domain name are the same.  For example: "mail.example.com" is within
-   the domain "example.com", but "mail.bad-example.com" is not.
-
-   Note: Use of this mechanism is discouraged because it is slow, it is
-   not as reliable as other mechanisms in cases of DNS errors, and it
-   places a large burden on the arpa name servers.  If used, proper PTR
-   records must be in place for the domain's hosts and the "ptr"
-   mechanism should be one of the last mechanisms checked.
-
-5.6.  "ip4" and "ip6"
-
-   These mechanisms test whether <ip> is contained within a given IP
-   network.
-
-   IP4              = "ip4"      ":" ip4-network   [ ip4-cidr-length ]
-   IP6              = "ip6"      ":" ip6-network   [ ip6-cidr-length ]
-
-   ip4-cidr-length  = "/" 1*DIGIT
-   ip6-cidr-length  = "/" 1*DIGIT
-   dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
-
-   ip4-network      = qnum "." qnum "." qnum "." qnum
-   qnum             = DIGIT                 ; 0-9
-                      / %x31-39 DIGIT       ; 10-99
-                      / "1" 2DIGIT          ; 100-199
-                      / "2" %x30-34 DIGIT   ; 200-249
-                      / "25" %x30-35        ; 250-255
-            ; as per conventional dotted quad notation.  e.g., 192.0.2.0
-   ip6-network      = <as per [RFC 3513], section 2.2>
-            ; e.g., 2001:DB8::CD30
-
-   The <ip> is compared to the given network.  If CIDR-length high-order
-   bits match, the mechanism matches.
-
-
-
-Wong & Schlitt                Experimental                     [Page 21]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   If ip4-cidr-length is omitted, it is taken to be "/32".  If
-   ip6-cidr-length is omitted, it is taken to be "/128".  It is not
-   permitted to omit parts of the IP address instead of using CIDR
-   notations.  That is, use 192.0.2.0/24 instead of 192.0.2.
-
-5.7.  "exists"
-
-   This mechanism is used to construct an arbitrary domain name that is
-   used for a DNS A record query.  It allows for complicated schemes
-   involving arbitrary parts of the mail envelope to determine what is
-   permitted.
-
-   exists           = "exists"   ":" domain-spec
-
-   The domain-spec is expanded as per Section 8.  The resulting domain
-   name is used for a DNS A RR lookup.  If any A record is returned,
-   this mechanism matches.  The lookup type is A even when the
-   connection type is IPv6.
-
-   Domains can use this mechanism to specify arbitrarily complex
-   queries.  For example, suppose example.com publishes the record:
-
-      v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all
-
-   The <target-name> might expand to
-   "1.2.0.192.someuser._spf.example.com".  This makes fine-grained
-   decisions possible at the level of the user and client IP address.
-
-   This mechanism enables queries that mimic the style of tests that
-   existing anti-spam DNS blacklists (DNSBL) use.
-
-6.  Modifier Definitions
-
-   Modifiers are name/value pairs that provide additional information.
-   Modifiers always have an "=" separating the name and the value.
-
-   The modifiers defined in this document ("redirect" and "exp") MAY
-   appear anywhere in the record, but SHOULD appear at the end, after
-   all mechanisms.  Ordering of these two modifiers does not matter.
-   These two modifiers MUST NOT appear in a record more than once each.
-   If they do, then check_host() exits with a result of "PermError".
-
-   Unrecognized modifiers MUST be ignored no matter where in a record,
-   or how often.  This allows implementations of this document to
-   gracefully handle records with modifiers that are defined in other
-   specifications.
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 22]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-6.1.  redirect: Redirected Query
-
-   If all mechanisms fail to match, and a "redirect" modifier is
-   present, then processing proceeds as follows:
-
-   redirect         = "redirect" "=" domain-spec
-
-   The domain-spec portion of the redirect section is expanded as per
-   the macro rules in Section 8.  Then check_host() is evaluated with
-   the resulting string as the <domain>.  The <ip> and <sender>
-   arguments remain the same as current evaluation of check_host().
-
-   The result of this new evaluation of check_host() is then considered
-   the result of the current evaluation with the exception that if no
-   SPF record is found, or if the target-name is malformed, the result
-   is a "PermError" rather than "None".
-
-   Note that the newly-queried domain may itself specify redirect
-   processing.
-
-   This facility is intended for use by organizations that wish to apply
-   the same record to multiple domains.  For example:
-
-     la.example.com. TXT "v=spf1 redirect=_spf.example.com"
-     ny.example.com. TXT "v=spf1 redirect=_spf.example.com"
-     sf.example.com. TXT "v=spf1 redirect=_spf.example.com"
-   _spf.example.com. TXT "v=spf1 mx:example.com -all"
-
-   In this example, mail from any of the three domains is described by
-   the same record.  This can be an administrative advantage.
-
-   Note: In general, the domain "A" cannot reliably use a redirect to
-   another domain "B" not under the same administrative control.  Since
-   the <sender> stays the same, there is no guarantee that the record at
-   domain "B" will correctly work for mailboxes in domain "A",
-   especially if domain "B" uses mechanisms involving localparts.  An
-   "include" directive may be more appropriate.
-
-   For clarity, it is RECOMMENDED that any "redirect" modifier appear as
-   the very last term in a record.
-
-6.2.  exp: Explanation
-
-   explanation      = "exp" "=" domain-spec
-
-   If check_host() results in a "Fail" due to a mechanism match (such as
-   "-all"), and the "exp" modifier is present, then the explanation
-   string returned is computed as described below.  If no "exp" modifier
-
-
-
-Wong & Schlitt                Experimental                     [Page 23]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   is present, then either a default explanation string or an empty
-   explanation string may be returned.
-
-   The <domain-spec> is macro expanded (see Section 8) and becomes the
-   <target-name>.  The DNS TXT record for the <target-name> is fetched.
-
-   If <domain-spec> is empty, or there are any DNS processing errors
-   (any RCODE other than 0), or if no records are returned, or if more
-   than one record is returned, or if there are syntax errors in the
-   explanation string, then proceed as if no exp modifier was given.
-
-   The fetched TXT record's strings are concatenated with no spaces, and
-   then treated as an <explain-string>, which is macro-expanded.  This
-   final result is the explanation string.  Implementations MAY limit
-   the length of the resulting explanation string to allow for other
-   protocol constraints and/or reasonable processing limits.  Since the
-   explanation string is intended for an SMTP response and [RFC2821]
-   Section 2.4 says that responses are in [US-ASCII], the explanation
-   string is also limited to US-ASCII.
-
-   Software evaluating check_host() can use this string to communicate
-   information from the publishing domain in the form of a short message
-   or URL.  Software SHOULD make it clear that the explanation string
-   comes from a third party.  For example, it can prepend the macro
-   string "%{o} explains: " to the explanation, such as shown in Section
-   2.5.4.
-
-   Suppose example.com has this record:
-
-      v=spf1 mx -all exp=explain._spf.%{d}
-
-   Here are some examples of possible explanation TXT records at
-   explain._spf.example.com:
-
-      "Mail from example.com should only be sent by its own servers."
-         -- a simple, constant message
-
-      "%{i} is not one of %{d}'s designated mail servers."
-         -- a message with a little more information, including the IP
-            address that failed the check
-
-      "See http://%{d}/why.html?s=%{S}&i=%{I}"
-         -- a complicated example that constructs a URL with the
-            arguments to check_host() so that a web page can be
-            generated with detailed, custom instructions
-
-   Note: During recursion into an "include" mechanism, an exp= modifier
-   from the <target-name> MUST NOT be used.  In contrast, when executing
-
-
-
-Wong & Schlitt                Experimental                     [Page 24]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   a "redirect" modifier, an exp= modifier from the original domain MUST
-   NOT be used.
-
-7.  The Received-SPF Header Field
-
-   It is RECOMMENDED that SMTP receivers record the result of SPF
-   processing in the message header.  If an SMTP receiver chooses to do
-   so, it SHOULD use the "Received-SPF" header field defined here for
-   each identity that was checked.  This information is intended for the
-   recipient.  (Information intended for the sender is described in
-   Section 6.2, Explanation.)
-
-   The Received-SPF header field is a trace field (see [RFC2822] Section
-   3.6.7) and SHOULD be prepended to the existing header, above the
-   Received: field that is generated by the SMTP receiver.  It MUST
-   appear above all other Received-SPF fields in the message.  The
-   header field has the following format:
-
-   header-field     = "Received-SPF:" [CFWS] result FWS [comment FWS]
-                      [ key-value-list ] CRLF
-
-   result           = "Pass" / "Fail" / "SoftFail" / "Neutral" /
-                      "None" / "TempError" / "PermError"
-
-   key-value-list   = key-value-pair *( ";" [CFWS] key-value-pair )
-                      [";"]
-
-   key-value-pair   = key [CFWS] "=" ( dot-atom / quoted-string )
-
-   key              = "client-ip" / "envelope-from" / "helo" /
-                      "problem" / "receiver" / "identity" /
-                       mechanism / "x-" name / name
-
-   identity         = "mailfrom"   ; for the "MAIL FROM" identity
-                      / "helo"     ; for the "HELO" identity
-                      / name       ; other identities
-
-   dot-atom         = <unquoted word as per [RFC2822]>
-   quoted-string    = <quoted string as per [RFC2822]>
-   comment          = <comment string as per [RFC2822]>
-   CFWS             = <comment or folding white space as per [RFC2822]>
-   FWS              = <folding white space as per [RFC2822]>
-   CRLF             = <standard end-of-line token as per [RFC2822]>
-
-   The header field SHOULD include a "(...)" style <comment> after the
-   result, conveying supporting information for the result, such as
-   <ip>, <sender>, and <domain>.
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 25]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   The following key-value pairs are designed for later machine parsing.
-   SPF clients SHOULD give enough information so that the SPF results
-   can be verified.  That is, at least "client-ip", "helo", and, if the
-   "MAIL FROM" identity was checked, "envelope-from".
-
-   client-ip      the IP address of the SMTP client
-
-   envelope-from  the envelope sender mailbox
-
-   helo           the host name given in the HELO or EHLO command
-
-   mechanism      the mechanism that matched (if no mechanisms matched,
-                  substitute the word "default")
-
-   problem        if an error was returned, details about the error
-
-   receiver       the host name of the SPF client
-
-   identity       the identity that was checked; see the <identity> ABNF
-                  rule
-
-   Other keys may be defined by SPF clients.  Until a new key name
-   becomes widely accepted, new key names should start with "x-".
-
-   SPF clients MUST make sure that the Received-SPF header field does
-   not contain invalid characters, is not excessively long, and does not
-   contain malicious data that has been provided by the sender.
-
-   Examples of various header styles that could be generated are the
-   following:
-
-   Received-SPF: Pass (mybox.example.org: domain of
-    myname@example.com designates 192.0.2.1 as permitted sender)
-       receiver=mybox.example.org; client-ip=192.0.2.1;
-       envelope-from=<myname@example.com>; helo=foo.example.com;
-
-   Received-SPF: Fail (mybox.example.org: domain of
-                     myname@example.com does not designate
-                     192.0.2.1 as permitted sender)
-                     identity=mailfrom; client-ip=192.0.2.1;
-                     envelope-from=<myname@example.com>;
-
-
-
-
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 26]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-8.  Macros
-
-8.1.  Macro Definitions
-
-   Many mechanisms and modifiers perform macro expansion on part of the
-   term.
-
-   domain-spec      = macro-string domain-end
-   domain-end       = ( "." toplabel [ "." ] ) / macro-expand
-
-   toplabel         = ( *alphanum ALPHA *alphanum ) /
-                      ( 1*alphanum "-" *( alphanum / "-" ) alphanum )
-                      ; LDH rule plus additional TLD restrictions
-                      ; (see [RFC3696], Section 2)
-   alphanum         = ALPHA / DIGIT
-
-   explain-string   = *( macro-string / SP )
-
-   macro-string     = *( macro-expand / macro-literal )
-   macro-expand     = ( "%{" macro-letter transformers *delimiter "}" )
-                      / "%%" / "%_" / "%-"
-   macro-literal    = %x21-24 / %x26-7E
-                      ; visible characters except "%"
-   macro-letter     = "s" / "l" / "o" / "d" / "i" / "p" / "h" /
-                      "c" / "r" / "t"
-   transformers     = *DIGIT [ "r" ]
-   delimiter        = "." / "-" / "+" / "," / "/" / "_" / "="
-
-   A literal "%" is expressed by "%%".
-
-      "%_" expands to a single " " space.
-      "%-" expands to a URL-encoded space, viz., "%20".
-
-   The following macro letters are expanded in term arguments:
-
-      s = <sender>
-      l = local-part of <sender>
-      o = domain of <sender>
-      d = <domain>
-      i = <ip>
-      p = the validated domain name of <ip>
-      v = the string "in-addr" if <ip> is ipv4, or "ip6" if <ip> is ipv6
-      h = HELO/EHLO domain
-
-
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 27]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   The following macro letters are allowed only in "exp" text:
-
-      c = SMTP client IP (easily readable format)
-      r = domain name of host performing the check
-      t = current timestamp
-
-   A '%' character not followed by a '{', '%', '-', or '_' character is
-   a syntax error.  So
-
-      -exists:%(ir).sbl.spamhaus.example.org
-
-   is incorrect and will cause check_host() to return a "PermError".
-   Instead, say
-
-      -exists:%{ir}.sbl.spamhaus.example.org
-
-   Optional transformers are the following:
-
-      *DIGIT = zero or more digits
-      'r'    = reverse value, splitting on dots by default
-
-   If transformers or delimiters are provided, the replacement value for
-   a macro letter is split into parts.  After performing any reversal
-   operation and/or removal of left-hand parts, the parts are rejoined
-   using "." and not the original splitting characters.
-
-   By default, strings are split on "." (dots).  Note that no special
-   treatment is given to leading, trailing, or consecutive delimiters,
-   and so the list of parts may contain empty strings.  Older
-   implementations of SPF prohibit trailing dots in domain names, so
-   trailing dots should not be published by domain owners, although they
-   must be accepted by implementations conforming to this document.
-   Macros may specify delimiter characters that are used instead of ".".
-
-   The 'r' transformer indicates a reversal operation: if the client IP
-   address were 192.0.2.1, the macro %{i} would expand to "192.0.2.1"
-   and the macro %{ir} would expand to "1.2.0.192".
-
-   The DIGIT transformer indicates the number of right-hand parts to
-   use, after optional reversal.  If a DIGIT is specified, the value
-   MUST be nonzero.  If no DIGITs are specified, or if the value
-   specifies more parts than are available, all the available parts are
-   used.  If the DIGIT was 5, and only 3 parts were available, the macro
-   interpreter would pretend the DIGIT was 3.  Implementations MUST
-   support at least a value of 128, as that is the maximum number of
-   labels in a domain name.
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 28]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   The "s" macro expands to the <sender> argument.  It is an E-Mail
-   address with a localpart, an "@" character, and a domain.  The "l"
-   macro expands to just the localpart.  The "o" macro expands to just
-   the domain part.  Note that these values remain the same during
-   recursive and chained evaluations due to "include" and/or "redirect".
-   Note also that if the original <sender> had no localpart, the
-   localpart was set to "postmaster" in initial processing (see Section
-   4.3).
-
-   For IPv4 addresses, both the "i" and "c" macros expand to the
-   standard dotted-quad format.
-
-   For IPv6 addresses, the "i" macro expands to a dot-format address; it
-   is intended for use in %{ir}.  The "c" macro may expand to any of the
-   hexadecimal colon-format addresses specified in [RFC3513], Section
-   2.2.  It is intended for humans to read.
-
-   The "p" macro expands to the validated domain name of <ip>.  The
-   procedure for finding the validated domain name is defined in Section
-   5.5.  If the <domain> is present in the list of validated domains, it
-   SHOULD be used.  Otherwise, if a subdomain of the <domain> is
-   present, it SHOULD be used.  Otherwise, any name from the list may be
-   used.  If there are no validated domain names or if a DNS error
-   occurs, the string "unknown" is used.
-
-   The "r" macro expands to the name of the receiving MTA.  This SHOULD
-   be a fully qualified domain name, but if one does not exist (as when
-   the checking is done by a MUA) or if policy restrictions dictate
-   otherwise, the word "unknown" SHOULD be substituted.  The domain name
-   may be different from the name found in the MX record that the client
-   MTA used to locate the receiving MTA.
-
-   The "t" macro expands to the decimal representation of the
-   approximate number of seconds since the Epoch (Midnight, January 1,
-   1970, UTC).  This is the same value as is returned by the POSIX
-   time() function in most standards-compliant libraries.
-
-   When the result of macro expansion is used in a domain name query, if
-   the expanded domain name exceeds 253 characters (the maximum length
-   of a domain name), the left side is truncated to fit, by removing
-   successive domain labels until the total length does not exceed 253
-   characters.
-
-   Uppercased macros expand exactly as their lowercased equivalents, and
-   are then URL escaped.  URL escaping must be performed for characters
-   not in the "uric" set, which is defined in [RFC3986].
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 29]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   Note: Care must be taken so that macro expansion for legitimate
-   E-Mail does not exceed the 63-character limit on DNS labels.  The
-   localpart of E-Mail addresses, in particular, can have more than 63
-   characters between dots.
-
-   Note: Domains should avoid using the "s", "l", "o", or "h" macros in
-   conjunction with any mechanism directive.  Although these macros are
-   powerful and allow per-user records to be published, they severely
-   limit the ability of implementations to cache results of check_host()
-   and they reduce the effectiveness of DNS caches.
-
-   Implementations should be aware that if no directive processed during
-   the evaluation of check_host() contains an "s", "l", "o", or "h"
-   macro, then the results of the evaluation can be cached on the basis
-   of <domain> and <ip> alone for as long as the shortest Time To Live
-   (TTL) of all the DNS records involved.
-
-8.2.  Expansion Examples
-
-      The <sender> is strong-bad@email.example.com.
-      The IPv4 SMTP client IP is 192.0.2.3.
-      The IPv6 SMTP client IP is 2001:DB8::CB01.
-      The PTR domain name of the client IP is mx.example.org.
-
-   macro                       expansion
-   -------  ----------------------------
-   %{s}     strong-bad@email.example.com
-   %{o}                email.example.com
-   %{d}                email.example.com
-   %{d4}               email.example.com
-   %{d3}               email.example.com
-   %{d2}                     example.com
-   %{d1}                             com
-   %{dr}               com.example.email
-   %{d2r}                  example.email
-   %{l}                       strong-bad
-   %{l-}                      strong.bad
-   %{lr}                      strong-bad
-   %{lr-}                     bad.strong
-   %{l1r-}                        strong
-
-
-
-
-
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 30]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   macro-string                                               expansion
-   --------------------------------------------------------------------
-   %{ir}.%{v}._spf.%{d2}             3.2.0.192.in-addr._spf.example.com
-   %{lr-}.lp._spf.%{d2}                  bad.strong.lp._spf.example.com
-
-   %{lr-}.lp.%{ir}.%{v}._spf.%{d2}
-                       bad.strong.lp.3.2.0.192.in-addr._spf.example.com
-
-   %{ir}.%{v}.%{l1r-}.lp._spf.%{d2}
-                           3.2.0.192.in-addr.strong.lp._spf.example.com
-
-   %{d2}.trusted-domains.example.net
-                                example.com.trusted-domains.example.net
-
-   IPv6:
-   %{ir}.%{v}._spf.%{d2}                               1.0.B.C.0.0.0.0.
-   0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.ip6._spf.example.com
-
-9.  Implications
-
-   This section outlines the major implications that adoption of this
-   document will have on various entities involved in Internet E-Mail.
-   It is intended to make clear to the reader where this document
-   knowingly affects the operation of such entities.  This section is
-   not a "how-to" manual, or a "best practices" document, and it is not
-   a comprehensive list of what such entities should do in light of this
-   document.
-
-   This section is non-normative.
-
-9.1.  Sending Domains
-
-   Domains that wish to be compliant with this specification will need
-   to determine the list of hosts that they allow to use their domain
-   name in the "HELO" and "MAIL FROM" identities.  It is recognized that
-   forming such a list is not just a simple technical exercise, but
-   involves policy decisions with both technical and administrative
-   considerations.
-
-   It can be helpful to publish records that include a "tracking
-   exists:" mechanism.  By looking at the name server logs, a rough list
-   may then be generated.  For example:
-
-      v=spf1 exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} ?all
-
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 31]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-9.2.  Mailing Lists
-
-   Mailing lists must be aware of how they re-inject mail that is sent
-   to the list.  Mailing lists MUST comply with the requirements in
-   [RFC2821], Section 3.10, and [RFC1123], Section 5.3.6, that say that
-   the reverse-path MUST be changed to be the mailbox of a person or
-   other entity who administers the list.  Whereas the reasons for
-   changing the reverse-path are many and long-standing, SPF adds
-   enforcement to this requirement.
-
-   In practice, almost all mailing list software in use already complies
-   with this requirement.  Mailing lists that do not comply may or may
-   not encounter problems depending on how access to the list is
-   restricted.  Such lists that are entirely internal to a domain (only
-   people in the domain can send to or receive from the list) are not
-   affected.
-
-9.3.  Forwarding Services and Aliases
-
-   Forwarding services take mail that is received at a mailbox and
-   direct it to some external mailbox.  At the time of this writing, the
-   near-universal practice of such services is to use the original "MAIL
-   FROM" of a message when re-injecting it for delivery to the external
-   mailbox.  [RFC1123] and [RFC2821] describe this action as an "alias"
-   rather than a "mail list".  This means that the external mailbox's
-   MTA sees all such mail in a connection from a host of the forwarding
-   service, and so the "MAIL FROM" identity will not, in general, pass
-   authorization.
-
-   There are three places that techniques can be used to ameliorate this
-   problem.
-
-   1. The beginning, when E-Mail is first sent.
-
-       1. "Neutral" results could be given for IP addresses that may be
-          forwarders, instead of "Fail" results.  For example:
-
-             "v=spf1 mx -exists:%{ir}.sbl.spamhaus.example.org ?all"
-
-          This would cause a lookup on an anti-spam DNS blacklist
-          (DNSBL) and cause a result of "Fail" only for E-Mail coming
-          from listed sources.  All other E-Mail, including E-Mail sent
-          through forwarders, would receive a "Neutral" result.  By
-          checking the DNSBL after the known good sources, problems with
-          incorrect listing on the DNSBL are greatly reduced.
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 32]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-       2. The "MAIL FROM" identity could have additional information in
-          the localpart that cryptographically identifies the mail as
-          coming from an authorized source.  In this case, such an SPF
-          record could be used:
-
-             "v=spf1 mx exists:%{l}._spf_verify.%{d} -all"
-
-          Then, a specialized DNS server can be set up to serve the
-          _spf_verify subdomain that validates the localpart.  Although
-          this requires an extra DNS lookup, this happens only when the
-          E-Mail would otherwise be rejected as not coming from a known
-          good source.
-
-          Note that due to the 63-character limit for domain labels,
-          this approach only works reliably if the localpart signature
-          scheme is guaranteed either to only produce localparts with a
-          maximum of 63 characters or to gracefully handle truncated
-          localparts.
-
-       3. Similarly, a specialized DNS server could be set up that will
-          rate-limit the E-Mail coming from unexpected IP addresses.
-
-             "v=spf1 mx exists:%{ir}._spf_rate.%{d} -all"
-
-       4. SPF allows the creation of per-user policies for special
-          cases.  For example, the following SPF record and appropriate
-          wildcard DNS records can be used:
-
-                 "v=spf1 mx redirect=%{l1r+}._at_.%{o}._spf.%{d}"
-
-   2.  The middle, when E-Mail is forwarded.
-
-       1. Forwarding services can solve the problem by rewriting the
-          "MAIL FROM" to be in their own domain.  This means that mail
-          bounced from the external mailbox will have to be re-bounced
-          by the forwarding service.  Various schemes to do this exist
-          though they vary widely in complexity and resource
-          requirements on the part of the forwarding service.
-
-       2. Several popular MTAs can be forced from "alias" semantics to
-          "mailing list" semantics by configuring an additional alias
-          with "owner-" prepended to the original alias name (e.g., an
-          alias of "friends: george@example.com, fred@example.org" would
-          need another alias of the form "owner-friends:  localowner").
-
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 33]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   3. The end, when E-Mail is received.
-
-       1. If the owner of the external mailbox wishes to trust the
-          forwarding service, he can direct the external mailbox's MTA
-          to skip SPF tests when the client host belongs to the
-          forwarding service.
-
-       2. Tests against other identities, such as the "HELO" identity,
-          may be used to override a failed test against the "MAIL FROM"
-          identity.
-
-       3. For larger domains, it may not be possible to have a complete
-          or accurate list of forwarding services used by the owners of
-          the domain's mailboxes.  In such cases, whitelists of
-          generally-recognized forwarding services could be employed.
-
-9.4.  Mail Services
-
-   Service providers that offer mail services to third-party domains,
-   such as sending of bulk mail, may want to adjust their setup in light
-   of the authorization check described in this document.  If the "MAIL
-   FROM" identity used for such E-Mail uses the domain of the service
-   provider, then the provider needs only to ensure that its sending
-   host is authorized by its own SPF record, if any.
-
-   If the "MAIL FROM" identity does not use the mail service provider's
-   domain, then extra care must be taken.  The SPF record format has
-   several options for the third-party domain to authorize the service
-   provider's MTAs to send mail on its behalf.  For mail service
-   providers, such as ISPs, that have a wide variety of customers using
-   the same MTA, steps should be taken to prevent cross-customer forgery
-   (see Section 10.4).
-
-9.5.  MTA Relays
-
-   The authorization check generally precludes the use of arbitrary MTA
-   relays between sender and receiver of an E-Mail message.
-
-   Within an organization, MTA relays can be effectively deployed.
-   However, for purposes of this document, such relays are effectively
-   transparent.  The SPF authorization check is a check between border
-   MTAs of different domains.
-
-   For mail senders, this means that published SPF records must
-   authorize any MTAs that actually send across the Internet.  Usually,
-   these are just the border MTAs as internal MTAs simply forward mail
-   to these MTAs for delivery.
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 34]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   Mail receivers will generally want to perform the authorization check
-   at the border MTAs, specifically including all secondary MXs.  This
-   allows mail that fails to be rejected during the SMTP session rather
-   than bounced.  Internal MTAs then do not perform the authorization
-   test.  To perform the authorization test other than at the border,
-   the host that first transferred the message to the organization must
-   be determined, which can be difficult to extract from the message
-   header.  Testing other than at the border is not recommended.
-
-10.  Security Considerations
-
-10.1.  Processing Limits
-
-   As with most aspects of E-Mail, there are a number of ways that
-   malicious parties could use the protocol as an avenue for a
-   Denial-of-Service (DoS) attack.  The processing limits outlined here
-   are designed to prevent attacks such as the following:
-
-   o  A malicious party could create an SPF record with many references
-      to a victim's domain and send many E-Mails to different SPF
-      clients; those SPF clients would then create a DoS attack.  In
-      effect, the SPF clients are being used to amplify the attacker's
-      bandwidth by using fewer bytes in the SMTP session than are used
-      by the DNS queries.  Using SPF clients also allows the attacker to
-      hide the true source of the attack.
-
-   o  Whereas implementations of check_host() are supposed to limit the
-      number of DNS lookups, malicious domains could publish records
-      that exceed these limits in an attempt to waste computation effort
-      at their targets when they send them mail.  Malicious domains
-      could also design SPF records that cause particular
-      implementations to use excessive memory or CPU usage, or to
-      trigger bugs.
-
-   o  Malicious parties could send a large volume of mail purporting to
-      come from the intended target to a wide variety of legitimate mail
-      hosts.  These legitimate machines would then present a DNS load on
-      the target as they fetched the relevant records.
-
-   Of these, the case of a third party referenced in the SPF record is
-   the easiest for a DoS attack to effectively exploit.  As a result,
-   limits that may seem reasonable for an individual mail server can
-   still allow an unreasonable amount of bandwidth amplification.
-   Therefore, the processing limits need to be quite low.
-
-   SPF implementations MUST limit the number of mechanisms and modifiers
-   that do DNS lookups to at most 10 per SPF check, including any
-   lookups caused by the use of the "include" mechanism or the
-
-
-
-Wong & Schlitt                Experimental                     [Page 35]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   "redirect" modifier.  If this number is exceeded during a check, a
-   PermError MUST be returned.  The "include", "a", "mx", "ptr", and
-   "exists" mechanisms as well as the "redirect" modifier do count
-   against this limit.  The "all", "ip4", and "ip6" mechanisms do not
-   require DNS lookups and therefore do not count against this limit.
-   The "exp" modifier does not count against this limit because the DNS
-   lookup to fetch the explanation string occurs after the SPF record
-   has been evaluated.
-
-   When evaluating the "mx" and "ptr" mechanisms, or the %{p} macro,
-   there MUST be a limit of no more than 10 MX or PTR RRs looked up and
-   checked.
-
-   SPF implementations SHOULD limit the total amount of data obtained
-   from the DNS queries.  For example, when DNS over TCP or EDNS0 are
-   available, there may need to be an explicit limit to how much data
-   will be accepted to prevent excessive bandwidth usage or memory usage
-   and DoS attacks.
-
-   MTAs or other processors MAY also impose a limit on the maximum
-   amount of elapsed time to evaluate check_host().  Such a limit SHOULD
-   allow at least 20 seconds.  If such a limit is exceeded, the result
-   of authorization SHOULD be "TempError".
-
-   Domains publishing records SHOULD try to keep the number of "include"
-   mechanisms and chained "redirect" modifiers to a minimum.  Domains
-   SHOULD also try to minimize the amount of other DNS information
-   needed to evaluate a record.  This can be done by choosing directives
-   that require less DNS information and placing lower-cost mechanisms
-   earlier in the SPF record.
-
-   For example, consider a domain set up as follows:
-
-   example.com.      IN MX   10 mx.example.com.
-   mx.example.com.   IN A    192.0.2.1
-   a.example.com.    IN TXT  "v=spf1 mx:example.com -all"
-   b.example.com.    IN TXT  "v=spf1 a:mx.example.com -all"
-   c.example.com.    IN TXT  "v=spf1 ip4:192.0.2.1 -all"
-
-   Evaluating check_host() for the domain "a.example.com" requires the
-   MX records for "example.com", and then the A records for the listed
-   hosts.  Evaluating for "b.example.com" requires only the A records.
-   Evaluating for "c.example.com" requires none.
-
-   However, there may be administrative considerations: using "a" over
-   "ip4" allows hosts to be renumbered easily.  Using "mx" over "a"
-   allows the set of mail hosts to be changed easily.
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 36]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-10.2.  SPF-Authorized E-Mail May Contain Other False Identities
-
-   The "MAIL FROM" and "HELO" identity authorizations must not be
-   construed to provide more assurance than they do.  It is entirely
-   possible for a malicious sender to inject a message using his own
-   domain in the identities used by SPF, to have that domain's SPF
-   record authorize the sending host, and yet the message can easily
-   list other identities in its header.  Unless the user or the MUA
-   takes care to note that the authorized identity does not match the
-   other more commonly-presented identities (such as the From:  header
-   field), the user may be lulled into a false sense of security.
-
-10.3.  Spoofed DNS and IP Data
-
-   There are two aspects of this protocol that malicious parties could
-   exploit to undermine the validity of the check_host() function:
-
-   o  The evaluation of check_host() relies heavily on DNS.  A malicious
-      attacker could attack the DNS infrastructure and cause
-      check_host() to see spoofed DNS data, and then return incorrect
-      results.  This could include returning "Pass" for an <ip> value
-      where the actual domain's record would evaluate to "Fail".  See
-      [RFC3833] for a description of DNS weaknesses.
-
-   o  The client IP address, <ip>, is assumed to be correct.  A
-      malicious attacker could spoof TCP sequence numbers to make mail
-      appear to come from a permitted host for a domain that the
-      attacker is impersonating.
-
-10.4.  Cross-User Forgery
-
-   By definition, SPF policies just map domain names to sets of
-   authorized MTAs, not whole E-Mail addresses to sets of authorized
-   users.  Although the "l" macro (Section 8) provides a limited way to
-   define individual sets of authorized MTAs for specific E-Mail
-   addresses, it is generally impossible to verify, through SPF, the use
-   of specific E-Mail addresses by individual users of the same MTA.
-
-   It is up to mail services and their MTAs to directly prevent
-   cross-user forgery: based on SMTP AUTH ([RFC2554]), users should be
-   restricted to using only those E-Mail addresses that are actually
-   under their control (see [RFC4409], Section 6.1).  Another means to
-   verify the identity of individual users is message cryptography such
-   as PGP ([RFC2440]) or S/MIME ([RFC3851]).
-
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 37]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-10.5.  Untrusted Information Sources
-
-   SPF uses information supplied by third parties, such as the "HELO"
-   domain name, the "MAIL FROM" address, and SPF records.  This
-   information is then passed to the receiver in the Received-SPF: trace
-   fields and possibly returned to the client MTA in the form of an SMTP
-   rejection message.  This information must be checked for invalid
-   characters and excessively long lines.
-
-   When the authorization check fails, an explanation string may be
-   included in the reject response.  Both the sender and the rejecting
-   receiver need to be aware that the explanation was determined by the
-   publisher of the SPF record checked and, in general, not the
-   receiver.  The explanation may contain malicious URLs, or it may be
-   offensive or misleading.
-
-   This is probably less of a concern than it may initially seem since
-   such messages are returned to the sender, and the explanation strings
-   come from the sender policy published by the domain in the identity
-   claimed by that very sender.  As long as the DSN is not redirected to
-   someone other than the actual sender, the only people who see
-   malicious explanation strings are people whose messages claim to be
-   from domains that publish such strings in their SPF records.  In
-   practice, DSNs can be misdirected, such as when an MTA accepts an
-   E-Mail and then later generates a DSN to a forged address, or when an
-   E-Mail forwarder does not direct the DSN back to the original sender.
-
-10.6.  Privacy Exposure
-
-   Checking SPF records causes DNS queries to be sent to the domain
-   owner.  These DNS queries, especially if they are caused by the
-   "exists" mechanism, can contain information about who is sending
-   E-Mail and likely to which MTA the E-Mail is being sent.  This can
-   introduce some privacy concerns, which may be more or less of an
-   issue depending on local laws and the relationship between the domain
-   owner and the person sending the E-Mail.
-
-11.  Contributors and Acknowledgements
-
-   This document is largely based on the work of Meng Weng Wong and Mark
-   Lentczner.  Although, as this section acknowledges, many people have
-   contributed to this document, a very large portion of the writing and
-   editing are due to Meng and Mark.
-
-   This design owes a debt of parentage to [RMX] by Hadmut Danisch and
-   to [DMP] by Gordon Fecyk.  The idea of using a DNS record to check
-   the legitimacy of an E-Mail address traces its ancestry further back
-   through messages on the namedroppers mailing list by Paul Vixie
-
-
-
-Wong & Schlitt                Experimental                     [Page 38]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   [Vixie] (based on suggestion by Jim Miller) and by David Green
-   [Green].
-
-   Philip Gladstone contributed the concept of macros to the
-   specification, multiplying the expressiveness of the language and
-   making per-user and per-IP lookups possible.
-
-   The authors would also like to thank the literally hundreds of
-   individuals who have participated in the development of this design.
-   They are far too numerous to name, but they include the following:
-
-      The folks on the spf-discuss mailing list.
-      The folks on the SPAM-L mailing list.
-      The folks on the IRTF ASRG mailing list.
-      The folks on the IETF MARID mailing list.
-      The folks on #perl.
-
-12.  IANA Considerations
-
-12.1.  The SPF DNS Record Type
-
-   The IANA has assigned a new Resource Record Type and Qtype from the
-   DNS Parameters Registry for the SPF RR type with code 99.
-
-12.2.  The Received-SPF Mail Header Field
-
-   Per [RFC3864], the "Received-SPF:" header field is added to the IANA
-   Permanent Message Header Field Registry.  The following is the
-   registration template:
-
-      Header field name: Received-SPF
-      Applicable protocol: mail ([RFC2822])
-      Status: Experimental
-      Author/Change controller: IETF
-      Specification document(s): RFC 4408
-      Related information:
-      Requesting SPF Council review of any proposed changes and
-      additions to this field are recommended.  For information about
-      the SPF Council see http://www.openspf.org/Council
-
-13.  References
-
-13.1.  Normative References
-
-   [RFC1035]  Mockapetris, P., "Domain names - implementation and
-              specification", STD 13, RFC 1035, November 1987.
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 39]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   [RFC1123]  Braden, R., "Requirements for Internet Hosts - Application
-              and Support", STD 3, RFC 1123, October 1989.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
-              April 2001.
-
-   [RFC2822]  Resnick, P., "Internet Message Format", RFC 2822, April
-              2001.
-
-   [RFC3464]  Moore, K. and G. Vaudreuil, "An Extensible Message Format
-              for Delivery Status Notifications", RFC 3464, January
-              2003.
-
-   [RFC3513]  Hinden, R. and S. Deering, "Internet Protocol Version 6
-              (IPv6) Addressing Architecture", RFC 3513, April 2003.
-
-   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
-              Procedures for Message Header Fields", BCP 90, RFC 3864,
-              September 2004.
-
-   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
-              Resource Identifier (URI): Generic Syntax", STD 66, RFC
-              3986, January 2005.
-
-   [RFC4234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
-              Specifications: ABNF", RFC 4234, October 2005.
-
-   [US-ASCII] American National Standards Institute (formerly United
-              States of America Standards Institute), "USA Code for
-              Information Interchange, X3.4", 1968.
-
-   ANSI X3.4-1968 has been replaced by newer versions with slight
-              modifications, but the 1968 version remains definitive for
-              the Internet.
-
-13.2  Informative References
-
-   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
-              STD 13, RFC 1034, November 1987.
-
-   [RFC1983]  Malkin, G., "Internet Users' Glossary", RFC 1983, August
-              1996.
-
-   [RFC2440]  Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
-              "OpenPGP Message Format", RFC 2440, November 1998.
-
-
-
-Wong & Schlitt                Experimental                     [Page 40]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   [RFC2554]  Myers, J., "SMTP Service Extension for Authentication",
-              RFC 2554, March 1999.
-
-   [RFC3696]  Klensin, J., "Application Techniques for Checking and
-              Transformation of Names", RFC 3696, February 2004.
-
-   [RFC3833]  Atkins, D. and R. Austein, "Threat Analysis of the Domain
-              Name System (DNS)", RFC 3833, August 2004.
-
-   [RFC3851]  Ramsdell, B., "Secure/Multipurpose Internet Mail
-              Extensions (S/MIME) Version 3.1 Message Specification",
-              RFC 3851, July 2004.
-
-   [RFC4409]  Gellens, R. and J. Klensin, "Message Submission for Mail",
-              RFC 4409, April 2006.
-
-   [RMX]      Danish, H., "The RMX DNS RR Type for light weight sender
-              authentication", Work In Progress
-
-   [DMP]      Fecyk, G., "Designated Mailers Protocol", Work In Progress
-
-   [Vixie]    Vixie, P., "Repudiating MAIL FROM", 2002.
-
-   [Green]    Green, D., "Domain-Authorized SMTP Mail", 2002.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 41]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-Appendix A.  Collected ABNF
-
-   This section is normative and any discrepancies with the ABNF
-   fragments in the preceding text are to be resolved in favor of this
-   grammar.
-
-   See [RFC4234] for ABNF notation.  Please note that as per this ABNF
-   definition, literal text strings (those in quotes) are case-
-   insensitive.  Hence, "mx" matches "mx", "MX", "mX", and "Mx".
-
-   record           = version terms *SP
-   version          = "v=spf1"
-
-   terms            = *( 1*SP ( directive / modifier ) )
-
-   directive        = [ qualifier ] mechanism
-   qualifier        = "+" / "-" / "?" / "~"
-   mechanism        = ( all / include
-                      / A / MX / PTR / IP4 / IP6 / exists )
-
-   all              = "all"
-   include          = "include"  ":" domain-spec
-   A                = "a"      [ ":" domain-spec ] [ dual-cidr-length ]
-   MX               = "mx"     [ ":" domain-spec ] [ dual-cidr-length ]
-   PTR              = "ptr"    [ ":" domain-spec ]
-   IP4              = "ip4"      ":" ip4-network   [ ip4-cidr-length ]
-   IP6              = "ip6"      ":" ip6-network   [ ip6-cidr-length ]
-   exists           = "exists"   ":" domain-spec
-
-   modifier         = redirect / explanation / unknown-modifier
-   redirect         = "redirect" "=" domain-spec
-   explanation      = "exp" "=" domain-spec
-   unknown-modifier = name "=" macro-string
-
-   ip4-cidr-length  = "/" 1*DIGIT
-   ip6-cidr-length  = "/" 1*DIGIT
-   dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
-
-   ip4-network      = qnum "." qnum "." qnum "." qnum
-   qnum             = DIGIT                 ; 0-9
-                      / %x31-39 DIGIT       ; 10-99
-                      / "1" 2DIGIT          ; 100-199
-                      / "2" %x30-34 DIGIT   ; 200-249
-                      / "25" %x30-35        ; 250-255
-             ; conventional dotted quad notation.  e.g., 192.0.2.0
-   ip6-network      = <as per [RFC 3513], section 2.2>
-             ; e.g., 2001:DB8::CD30
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 42]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   domain-spec      = macro-string domain-end
-   domain-end       = ( "." toplabel [ "." ] ) / macro-expand
-   toplabel         = ( *alphanum ALPHA *alphanum ) /
-                      ( 1*alphanum "-" *( alphanum / "-" ) alphanum )
-                      ; LDH rule plus additional TLD restrictions
-                      ; (see [RFC3696], Section 2)
-
-   alphanum         = ALPHA / DIGIT
-
-   explain-string   = *( macro-string / SP )
-
-   macro-string     = *( macro-expand / macro-literal )
-   macro-expand     = ( "%{" macro-letter transformers *delimiter "}" )
-                      / "%%" / "%_" / "%-"
-   macro-literal    = %x21-24 / %x26-7E
-                      ; visible characters except "%"
-   macro-letter     = "s" / "l" / "o" / "d" / "i" / "p" / "h" /
-                      "c" / "r" / "t"
-   transformers     = *DIGIT [ "r" ]
-   delimiter        = "." / "-" / "+" / "," / "/" / "_" / "="
-
-   name             = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." )
-
-   header-field     = "Received-SPF:" [CFWS] result FWS [comment FWS]
-                      [ key-value-list ] CRLF
-
-   result           = "Pass" / "Fail" / "SoftFail" / "Neutral" /
-                      "None" / "TempError" / "PermError"
-
-   key-value-list   = key-value-pair *( ";" [CFWS] key-value-pair )
-                      [";"]
-
-   key-value-pair   = key [CFWS] "=" ( dot-atom / quoted-string )
-
-   key              = "client-ip" / "envelope-from" / "helo" /
-                      "problem" / "receiver" / "identity" /
-                       mechanism / "x-" name / name
-
-   identity         = "mailfrom"   ; for the "MAIL FROM" identity
-                      / "helo"     ; for the "HELO" identity
-                      / name       ; other identities
-
-   dot-atom         = <unquoted word as per [RFC2822]>
-   quoted-string    = <quoted string as per [RFC2822]>
-   comment          = <comment string as per [RFC2822]>
-   CFWS             = <comment or folding white space as per [RFC2822]>
-   FWS              = <folding white space as per [RFC2822]>
-   CRLF             = <standard end-of-line token as per [RFC2822]>
-
-
-
-Wong & Schlitt                Experimental                     [Page 43]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-Appendix B.  Extended Examples
-
-   These examples are based on the following DNS setup:
-
-   ; A domain with two mail servers, two hosts
-   ; and two servers at the domain name
-   $ORIGIN example.com.
-   @           MX  10 mail-a
-               MX  20 mail-b
-               A   192.0.2.10
-               A   192.0.2.11
-   amy         A   192.0.2.65
-   bob         A   192.0.2.66
-   mail-a      A   192.0.2.129
-   mail-b      A   192.0.2.130
-   www         CNAME example.com.
-
-   ; A related domain
-   $ORIGIN example.org.
-   @           MX  10 mail-c
-   mail-c      A   192.0.2.140
-
-   ; The reverse IP for those addresses
-   $ORIGIN 2.0.192.in-addr.arpa.
-   10          PTR example.com.
-   11          PTR example.com.
-   65          PTR amy.example.com.
-   66          PTR bob.example.com.
-   129         PTR mail-a.example.com.
-   130         PTR mail-b.example.com.
-   140         PTR mail-c.example.org.
-
-   ; A rogue reverse IP domain that claims to be
-   ; something it's not
-   $ORIGIN 0.0.10.in-addr.arpa.
-   4           PTR bob.example.com.
-
-B.1.  Simple Examples
-
-   These examples show various possible published records for
-   example.com and which values if <ip> would cause check_host() to
-   return "Pass".  Note that <domain> is "example.com".
-
-   v=spf1 +all
-      -- any <ip> passes
-
-   v=spf1 a -all
-      -- hosts 192.0.2.10 and 192.0.2.11 pass
-
-
-
-Wong & Schlitt                Experimental                     [Page 44]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   v=spf1 a:example.org -all
-      -- no sending hosts pass since example.org has no A records
-
-   v=spf1 mx -all
-      -- sending hosts 192.0.2.129 and 192.0.2.130 pass
-
-   v=spf1 mx:example.org -all
-      -- sending host 192.0.2.140 passes
-
-   v=spf1 mx mx:example.org -all
-      -- sending hosts 192.0.2.129, 192.0.2.130, and 192.0.2.140 pass
-
-   v=spf1 mx/30 mx:example.org/30 -all
-      -- any sending host in 192.0.2.128/30 or 192.0.2.140/30 passes
-
-   v=spf1 ptr -all
-      -- sending host 192.0.2.65 passes (reverse DNS is valid and is in
-         example.com)
-      -- sending host 192.0.2.140 fails (reverse DNS is valid, but not
-         in example.com)
-      -- sending host 10.0.0.4 fails (reverse IP is not valid)
-
-   v=spf1 ip4:192.0.2.128/28 -all
-      -- sending host 192.0.2.65 fails
-      -- sending host 192.0.2.129 passes
-
-B.2.  Multiple Domain Example
-
-   These examples show the effect of related records:
-
-      example.org: "v=spf1 include:example.com include:example.net -all"
-
-   This record would be used if mail from example.org actually came
-   through servers at example.com and example.net.  Example.org's
-   designated servers are the union of example.com's and example.net's
-   designated servers.
-
-      la.example.org: "v=spf1 redirect=example.org"
-      ny.example.org: "v=spf1 redirect=example.org"
-      sf.example.org: "v=spf1 redirect=example.org"
-
-   These records allow a set of domains that all use the same mail
-   system to make use of that mail system's record.  In this way, only
-   the mail system's record needs to be updated when the mail setup
-   changes.  These domains' records never have to change.
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 45]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-B.3.  DNSBL Style Example
-
-   Imagine that, in addition to the domain records listed above, there
-   are these:
-
-   $ORIGIN _spf.example.com.  mary.mobile-users                   A
-   127.0.0.2 fred.mobile-users                   A 127.0.0.2
-   15.15.168.192.joel.remote-users     A 127.0.0.2
-   16.15.168.192.joel.remote-users     A 127.0.0.2
-
-   The following records describe users at example.com who mail from
-   arbitrary servers, or who mail from personal servers.
-
-   example.com:
-
-   v=spf1 mx
-          include:mobile-users._spf.%{d}
-          include:remote-users._spf.%{d}
-          -all
-
-   mobile-users._spf.example.com:
-
-   v=spf1 exists:%{l1r+}.%{d}
-
-   remote-users._spf.example.com:
-
-   v=spf1 exists:%{ir}.%{l1r+}.%{d}
-
-B.4.  Multiple Requirements Example
-
-   Say that your sender policy requires both that the IP address is
-   within a certain range and that the reverse DNS for the IP matches.
-   This can be done several ways, including the following:
-
-   example.com.           SPF  ( "v=spf1 "
-                                 "-include:ip4._spf.%{d} "
-                                 "-include:ptr._spf.%{d} "
-                                 "+all" )
-   ip4._spf.example.com.  SPF  "v=spf1 -ip4:192.0.2.0/24 +all"
-   ptr._spf.example.com.  SPF  "v=spf1 -ptr +all"
-
-   This example shows how the "-include" mechanism can be useful, how an
-   SPF record that ends in "+all" can be very restrictive, and the use
-   of De Morgan's Law.
-
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 46]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-Authors' Addresses
-
-   Meng Weng Wong
-   Singapore
-
-   EMail: mengwong+spf@pobox.com
-
-
-   Wayne Schlitt
-   4615 Meredeth #9
-   Lincoln Nebraska, NE  68506
-   United States of America
-
-   EMail: wayne@schlitt.net
-   URI:   http://www.schlitt.net/spf/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 47]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 48]
-
diff --git a/contrib/bind9/doc/rfc/rfc4431.txt b/contrib/bind9/doc/rfc/rfc4431.txt
deleted file mode 100644
index 8b38872..0000000
--- a/contrib/bind9/doc/rfc/rfc4431.txt
+++ /dev/null
@@ -1,227 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         M. Andrews
-Request for Comments: 4431                   Internet Systems Consortium
-Category: Informational                                        S. Weiler
-                                                            SPARTA, Inc.
-                                                           February 2006
-
-
-       The DNSSEC Lookaside Validation (DLV) DNS Resource Record
-
-Status of This Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document defines a new DNS resource record, called the DNSSEC
-   Lookaside Validation (DLV) RR, for publishing DNSSEC trust anchors
-   outside of the DNS delegation chain.
-
-1.  Introduction
-
-   DNSSEC [1] [2] [3] authenticates DNS data by building public-key
-   signature chains along the DNS delegation chain from a trust anchor,
-   ideally a trust anchor for the DNS root.
-
-   This document defines a new resource record for publishing such trust
-   anchors outside of the DNS's normal delegation chain.  Use of these
-   records by DNSSEC validators is outside the scope of this document,
-   but it is expected that these records will help resolvers validate
-   DNSSEC-signed data from zones whose ancestors either aren't signed or
-   refuse to publish delegation signer (DS) records for their children.
-
-2.  DLV Resource Record
-
-   The DLV resource record has exactly the same wire and presentation
-   formats as the DS resource record, defined in RFC 4034, Section 5.
-   It uses the same IANA-assigned values in the algorithm and digest
-   type fields as the DS record.  (Those IANA registries are known as
-   the "DNS Security Algorithm Numbers" and "DS RR Type Algorithm
-   Numbers" registries.)
-
-
-
-
-
-Andrews & Weiler             Informational                      [Page 1]
-
-RFC 4431                  DLV Resource Record              February 2006
-
-
-   The DLV record is a normal DNS record type without any special
-   processing requirements.  In particular, the DLV record does not
-   inherit any of the special processing or handling requirements of the
-   DS record type (described in Section 3.1.4.1 of RFC 4035).  Unlike
-   the DS record, the DLV record may not appear on the parent's side of
-   a zone cut.  A DLV record may, however, appear at the apex of a zone.
-
-3.  Security Considerations
-
-   For authoritative servers and resolvers that do not attempt to use
-   DLV RRs as part of DNSSEC validation, there are no particular
-   security concerns -- DLV RRs are just like any other DNS data.
-
-   Software using DLV RRs as part of DNSSEC validation will almost
-   certainly want to impose constraints on their use, but those
-   constraints are best left to be described by the documents that more
-   fully describe the particulars of how the records are used.  At a
-   minimum, it would be unwise to use the records without some sort of
-   cryptographic authentication.  More likely than not, DNSSEC itself
-   will be used to authenticate the DLV RRs.  Depending on how a DLV RR
-   is used, failure to properly authenticate it could lead to
-   significant additional security problems including failure to detect
-   spoofed DNS data.
-
-   RFC 4034, Section 8, describes security considerations specific to
-   the DS RR.  Those considerations are equally applicable to DLV RRs.
-   Of particular note, the key tag field is used to help select DNSKEY
-   RRs efficiently, but it does not uniquely identify a single DNSKEY
-   RR.  It is possible for two distinct DNSKEY RRs to have the same
-   owner name, the same algorithm type, and the same key tag.  An
-   implementation that uses only the key tag to select a DNSKEY RR might
-   select the wrong public key in some circumstances.
-
-   For further discussion of the security implications of DNSSEC, see
-   RFC 4033, RFC 4034, and RFC 4035.
-
-4.  IANA Considerations
-
-   IANA has assigned DNS type code 32769 to the DLV resource record from
-   the Specification Required portion of the DNS Resource Record Type
-   registry, as defined in [4].
-
-   The DLV resource record reuses the same algorithm and digest type
-   registries already used for the DS resource record, currently known
-   as the "DNS Security Algorithm Numbers" and "DS RR Type Algorithm
-   Numbers" registries.
-
-
-
-
-
-Andrews & Weiler             Informational                      [Page 2]
-
-RFC 4431                  DLV Resource Record              February 2006
-
-
-5.  Normative References
-
-   [1]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "DNS Security Introduction and Requirements", RFC 4033,
-        March 2005.
-
-   [2]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Resource Records for the DNS Security Extensions", RFC 4034,
-        March 2005.
-
-   [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Protocol Modifications for the DNS Security Extensions",
-        RFC 4035, March 2005.
-
-   [4]  Eastlake, D., Brunner-Williams, E., and B. Manning, "Domain Name
-        System (DNS) IANA Considerations", BCP 42, RFC 2929,
-        September 2000.
-
-Authors' Addresses
-
-   Mark Andrews
-   Internet Systems Consortium
-   950 Charter St.
-   Redwood City, CA  94063
-   US
-
-   EMail: Mark_Andrews@isc.org
-
-
-   Samuel Weiler
-   SPARTA, Inc.
-   7075 Samuel Morse Drive
-   Columbia, Maryland  21046
-   US
-
-   EMail: weiler@tislabs.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Andrews & Weiler             Informational                      [Page 3]
-
-RFC 4431                  DLV Resource Record              February 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Andrews & Weiler             Informational                      [Page 4]
-
diff --git a/contrib/bind9/doc/rfc/rfc4470.txt b/contrib/bind9/doc/rfc/rfc4470.txt
deleted file mode 100644
index ac12d65..0000000
--- a/contrib/bind9/doc/rfc/rfc4470.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          S. Weiler
-Request for Comments: 4470                                  SPARTA, Inc.
-Updates: 4035, 4034                                             J. Ihren
-Category: Standards Track                                  Autonomica AB
-                                                              April 2006
-
-
-       Minimally Covering NSEC Records and DNSSEC On-line Signing
-
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document describes how to construct DNSSEC NSEC resource records
-   that cover a smaller range of names than called for by RFC 4034.  By
-   generating and signing these records on demand, authoritative name
-   servers can effectively stop the disclosure of zone contents
-   otherwise made possible by walking the chain of NSEC records in a
-   signed zone.
-
-Table of Contents
-
-   1. Introduction ....................................................1
-   2. Applicability of This Technique .................................2
-   3. Minimally Covering NSEC Records .................................2
-   4. Better Epsilon Functions ........................................4
-   5. Security Considerations .........................................5
-   6. Acknowledgements ................................................6
-   7. Normative References ............................................6
-
-1.  Introduction
-
-   With DNSSEC [1], an NSEC record lists the next instantiated name in
-   its zone, proving that no names exist in the "span" between the
-   NSEC's owner name and the name in the "next name" field.  In this
-   document, an NSEC record is said to "cover" the names between its
-   owner name and next name.
-
-
-
-Weiler & Ihren              Standards Track                     [Page 1]
-
-RFC 4470                      NSEC Epsilon                    April 2006
-
-
-   Through repeated queries that return NSEC records, it is possible to
-   retrieve all of the names in the zone, a process commonly called
-   "walking" the zone.  Some zone owners have policies forbidding zone
-   transfers by arbitrary clients; this side effect of the NSEC
-   architecture subverts those policies.
-
-   This document presents a way to prevent zone walking by constructing
-   NSEC records that cover fewer names.  These records can make zone
-   walking take approximately as many queries as simply asking for all
-   possible names in a zone, making zone walking impractical.  Some of
-   these records must be created and signed on demand, which requires
-   on-line private keys.  Anyone contemplating use of this technique is
-   strongly encouraged to review the discussion of the risks of on-line
-   signing in Section 5.
-
-1.2.  Keywords
-
-   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [4].
-
-2.  Applicability of This Technique
-
-   The technique presented here may be useful to a zone owner that wants
-   to use DNSSEC, is concerned about exposure of its zone contents via
-   zone walking, and is willing to bear the costs of on-line signing.
-
-   As discussed in Section 5, on-line signing has several security
-   risks, including an increased likelihood of private keys being
-   disclosed and an increased risk of denial of service attack.  Anyone
-   contemplating use of this technique is strongly encouraged to review
-   the discussion of the risks of on-line signing in Section 5.
-
-   Furthermore, at the time this document was published, the DNSEXT
-   working group was actively working on a mechanism to prevent zone
-   walking that does not require on-line signing (tentatively called
-   NSEC3).  The new mechanism is likely to expose slightly more
-   information about the zone than this technique (e.g., the number of
-   instantiated names), but it may be preferable to this technique.
-
-3.  Minimally Covering NSEC Records
-
-   This mechanism involves changes to NSEC records for instantiated
-   names, which can still be generated and signed in advance, as well as
-   the on-demand generation and signing of new NSEC records whenever a
-   name must be proven not to exist.
-
-
-
-
-
-Weiler & Ihren              Standards Track                     [Page 2]
-
-RFC 4470                      NSEC Epsilon                    April 2006
-
-
-   In the "next name" field of instantiated names' NSEC records, rather
-   than list the next instantiated name in the zone, list any name that
-   falls lexically after the NSEC's owner name and before the next
-   instantiated name in the zone, according to the ordering function in
-   RFC 4034 [2] Section 6.1.  This relaxes the requirement in Section
-   4.1.1 of RFC 4034 that the "next name" field contains the next owner
-   name in the zone.  This change is expected to be fully compatible
-   with all existing DNSSEC validators.  These NSEC records are returned
-   whenever proving something specifically about the owner name (e.g.,
-   that no resource records of a given type appear at that name).
-
-   Whenever an NSEC record is needed to prove the non-existence of a
-   name, a new NSEC record is dynamically produced and signed.  The new
-   NSEC record has an owner name lexically before the QNAME but
-   lexically following any existing name and a "next name" lexically
-   following the QNAME but before any existing name.
-
-   The generated NSEC record's type bitmap MUST have the RRSIG and NSEC
-   bits set and SHOULD NOT have any other bits set.  This relaxes the
-   requirement in Section 2.3 of RFC4035 that NSEC RRs not appear at
-   names that did not exist before the zone was signed.
-
-   The functions to generate the lexically following and proceeding
-   names need not be perfect or consistent, but the generated NSEC
-   records must not cover any existing names.  Furthermore, this
-   technique works best when the generated NSEC records cover as few
-   names as possible.  In this document, the functions that generate the
-   nearby names are called "epsilon" functions, a reference to the
-   mathematical convention of using the greek letter epsilon to
-   represent small deviations.
-
-   An NSEC record denying the existence of a wildcard may be generated
-   in the same way.  Since the NSEC record covering a non-existent
-   wildcard is likely to be used in response to many queries,
-   authoritative name servers using the techniques described here may
-   want to pregenerate or cache that record and its corresponding RRSIG.
-
-   For example, a query for an A record at the non-instantiated name
-   example.com might produce the following two NSEC records, the first
-   denying the existence of the name example.com and the second denying
-   the existence of a wildcard:
-
-          exampld.com 3600 IN NSEC example-.com ( RRSIG NSEC )
-
-          \).com 3600 IN NSEC +.com ( RRSIG NSEC )
-
-
-
-
-
-
-Weiler & Ihren              Standards Track                     [Page 3]
-
-RFC 4470                      NSEC Epsilon                    April 2006
-
-
-   Before answering a query with these records, an authoritative server
-   must test for the existence of names between these endpoints.  If the
-   generated NSEC would cover existing names (e.g., exampldd.com or
-   *bizarre.example.com), a better epsilon function may be used or the
-   covered name closest to the QNAME could be used as the NSEC owner
-   name or next name, as appropriate.  If an existing name is used as
-   the NSEC owner name, that name's real NSEC record MUST be returned.
-   Using the same example, assuming an exampldd.com delegation exists,
-   this record might be returned from the parent:
-
-          exampldd.com 3600 IN NSEC example-.com ( NS DS RRSIG NSEC )
-
-   Like every authoritative record in the zone, each generated NSEC
-   record MUST have corresponding RRSIGs generated using each algorithm
-   (but not necessarily each DNSKEY) in the zone's DNSKEY RRset, as
-   described in RFC 4035 [3] Section 2.2.  To minimize the number of
-   signatures that must be generated, a zone may wish to limit the
-   number of algorithms in its DNSKEY RRset.
-
-4.  Better Epsilon Functions
-
-   Section 6.1 of RFC 4034 defines a strict ordering of DNS names.
-   Working backward from that definition, it should be possible to
-   define epsilon functions that generate the immediately following and
-   preceding names, respectively.  This document does not define such
-   functions.  Instead, this section presents functions that come
-   reasonably close to the perfect ones.  As described above, an
-   authoritative server should still ensure than no generated NSEC
-   covers any existing name.
-
-   To increment a name, add a leading label with a single null (zero-
-   value) octet.
-
-   To decrement a name, decrement the last character of the leftmost
-   label, then fill that label to a length of 63 octets with octets of
-   value 255.  To decrement a null (zero-value) octet, remove the octet
-   -- if an empty label is left, remove the label.  Defining this
-   function numerically: fill the leftmost label to its maximum length
-   with zeros (numeric, not ASCII zeros) and subtract one.
-
-   In response to a query for the non-existent name foo.example.com,
-   these functions produce NSEC records of the following:
-
-
-
-
-
-
-
-
-
-Weiler & Ihren              Standards Track                     [Page 4]
-
-RFC 4470                      NSEC Epsilon                    April 2006
-
-
-     fon\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255.example.com 3600 IN NSEC \000.foo.example.com ( NSEC RRSIG )
-
-     \)\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255\255.example.com 3600 IN NSEC \000.*.example.com ( NSEC RRSIG )
-
-   The first of these NSEC RRs proves that no exact match for
-   foo.example.com exists, and the second proves that there is no
-   wildcard in example.com.
-
-   Both of these functions are imperfect: they do not take into account
-   constraints on number of labels in a name nor total length of a name.
-   As noted in the previous section, though, this technique does not
-   depend on the use of perfect epsilon functions: it is sufficient to
-   test whether any instantiated names fall into the span covered by the
-   generated NSEC and, if so, substitute those instantiated owner names
-   for the NSEC owner name or next name, as appropriate.
-
-5.  Security Considerations
-
-   This approach requires on-demand generation of RRSIG records.  This
-   creates several new vulnerabilities.
-
-   First, on-demand signing requires that a zone's authoritative servers
-   have access to its private keys.  Storing private keys on well-known
-   Internet-accessible servers may make them more vulnerable to
-   unintended disclosure.
-
-   Second, since generation of digital signatures tends to be
-   computationally demanding, the requirement for on-demand signing
-   makes authoritative servers vulnerable to a denial of service attack.
-
-   Last, if the epsilon functions are predictable, on-demand signing may
-   enable a chosen-plaintext attack on a zone's private keys.  Zones
-   using this approach should attempt to use cryptographic algorithms
-   that are resistant to chosen-plaintext attacks.  It is worth noting
-   that although DNSSEC has a "mandatory to implement" algorithm, that
-   is a requirement on resolvers and validators -- there is no
-   requirement that a zone be signed with any given algorithm.
-
-   The success of using minimally covering NSEC records to prevent zone
-   walking depends greatly on the quality of the epsilon functions
-
-
-
-Weiler & Ihren              Standards Track                     [Page 5]
-
-RFC 4470                      NSEC Epsilon                    April 2006
-
-
-   chosen.  An increment function that chooses a name obviously derived
-   from the next instantiated name may be easily reverse engineered,
-   destroying the value of this technique.  An increment function that
-   always returns a name close to the next instantiated name is likewise
-   a poor choice.  Good choices of epsilon functions are the ones that
-   produce the immediately following and preceding names, respectively,
-   though zone administrators may wish to use less perfect functions
-   that return more human-friendly names than the functions described in
-   Section 4 above.
-
-   Another obvious but misguided concern is the danger from synthesized
-   NSEC records being replayed.  It is possible for an attacker to
-   replay an old but still validly signed NSEC record after a new name
-   has been added in the span covered by that NSEC, incorrectly proving
-   that there is no record at that name.  This danger exists with DNSSEC
-   as defined in [3].  The techniques described here actually decrease
-   the danger, since the span covered by any NSEC record is smaller than
-   before.  Choosing better epsilon functions will further reduce this
-   danger.
-
-6.  Acknowledgements
-
-   Many individuals contributed to this design.  They include, in
-   addition to the authors of this document, Olaf Kolkman, Ed Lewis,
-   Peter Koch, Matt Larson, David Blacka, Suzanne Woolf, Jaap Akkerhuis,
-   Jakob Schlyter, Bill Manning, and Joao Damas.
-
-   In addition, the editors would like to thank Ed Lewis, Scott Rose,
-   and David Blacka for their careful review of the document.
-
-7.  Normative References
-
-   [1]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "DNS Security Introduction and Requirements", RFC 4033, March
-        2005.
-
-   [2]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Resource Records for the DNS Security Extensions", RFC 4034,
-        March 2005.
-
-   [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Protocol Modifications for the DNS Security Extensions", RFC
-        4035, March 2005.
-
-   [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-
-
-
-
-Weiler & Ihren              Standards Track                     [Page 6]
-
-RFC 4470                      NSEC Epsilon                    April 2006
-
-
-Authors' Addresses
-
-   Samuel Weiler
-   SPARTA, Inc.
-   7075 Samuel Morse Drive
-   Columbia, Maryland  21046
-   US
-
-   EMail: weiler@tislabs.com
-
-
-   Johan Ihren
-   Autonomica AB
-   Bellmansgatan 30
-   Stockholm  SE-118 47
-   Sweden
-
-   EMail: johani@autonomica.se
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler & Ihren              Standards Track                     [Page 7]
-
-RFC 4470                      NSEC Epsilon                    April 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Weiler & Ihren              Standards Track                     [Page 8]
-
diff --git a/contrib/bind9/doc/rfc/rfc4634.txt b/contrib/bind9/doc/rfc/rfc4634.txt
deleted file mode 100644
index b672df8..0000000
--- a/contrib/bind9/doc/rfc/rfc4634.txt
+++ /dev/null
@@ -1,6051 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                    D. Eastlake 3rd
-Request for Comments: 4634                                 Motorola Labs
-Updates: 3174                                                  T. Hansen
-Category: Informational                                        AT&T Labs
-                                                               July 2006
-
-
-              US Secure Hash Algorithms (SHA and HMAC-SHA)
-
-Status of This Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   The United States of America has adopted a suite of Secure Hash
-   Algorithms (SHAs), including four beyond SHA-1, as part of a Federal
-   Information Processing Standard (FIPS), specifically SHA-224 (RFC
-   3874), SHA-256, SHA-384, and SHA-512.  The purpose of this document
-   is to make source code performing these hash functions conveniently
-   available to the Internet community.  The sample code supports input
-   strings of arbitrary bit length.  SHA-1's sample code from RFC 3174
-   has also been updated to handle input strings of arbitrary bit
-   length.  Most of the text herein was adapted by the authors from FIPS
-   180-2.
-
-   Code to perform SHA-based HMACs, with arbitrary bit length text, is
-   also included.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                      [Page 1]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-Table of Contents
-
-   1. Overview of Contents ............................................3
-      1.1. License ....................................................4
-   2. Notation for Bit Strings and Integers ...........................4
-   3. Operations on Words .............................................5
-   4. Message Padding and Parsing .....................................6
-      4.1. SHA-224 and SHA-256 ........................................7
-      4.2. SHA-384 and SHA-512 ........................................8
-   5. Functions and Constants Used ....................................9
-      5.1. SHA-224 and SHA-256 ........................................9
-      5.2. SHA-384 and SHA-512 .......................................10
-   6. Computing the Message Digest ...................................11
-      6.1. SHA-224 and SHA-256 Initialization ........................11
-      6.2. SHA-224 and SHA-256 Processing ............................11
-      6.3. SHA-384 and SHA-512 Initialization ........................13
-      6.4. SHA-384 and SHA-512 Processing ............................14
-   7. SHA-Based HMACs ................................................15
-   8. C Code for SHAs ................................................15
-      8.1. The .h File ...............................................18
-      8.2. The SHA Code ..............................................24
-           8.2.1. sha1.c .............................................24
-           8.2.2. sha224-256.c .......................................33
-           8.2.3. sha384-512.c .......................................45
-           8.2.4. usha.c .............................................67
-           8.2.5. sha-private.h ......................................72
-      8.3. The HMAC Code .............................................73
-      8.4. The Test Driver ...........................................78
-   9. Security Considerations .......................................106
-   10. Normative References .........................................106
-   11. Informative References .......................................106
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                      [Page 2]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-1.  Overview of Contents
-
-   NOTE: Much of the text below is taken from [FIPS180-2] and assertions
-   therein of the security of the algorithms described are made by the
-   US Government, the author of [FIPS180-2], and not by the authors of
-   this document.
-
-   The text below specifies Secure Hash Algorithms, SHA-224 [RFC3874],
-   SHA-256, SHA-384, and SHA-512, for computing a condensed
-   representation of a message or a data file. (SHA-1 is specified in
-   [RFC3174].)  When a message of any length < 2^64 bits (for SHA-224
-   and SHA-256) or < 2^128 bits (for SHA-384 and SHA-512) is input to
-   one of these algorithms, the result is an output called a message
-   digest.  The message digests range in length from 224 to 512 bits,
-   depending on the algorithm.  Secure hash algorithms are typically
-   used with other cryptographic algorithms, such as digital signature
-   algorithms and keyed hash authentication codes, or in the generation
-   of random numbers [RFC4086].
-
-   The four algorithms specified in this document are called secure
-   because it is computationally infeasible to (1) find a message that
-   corresponds to a given message digest, or (2) find two different
-   messages that produce the same message digest.  Any change to a
-   message in transit will, with very high probability, result in a
-   different message digest.  This will result in a verification failure
-   when the secure hash algorithm is used with a digital signature
-   algorithm or a keyed-hash message authentication algorithm.
-
-   The code provided herein supports input strings of arbitrary bit
-   length.  SHA-1's sample code from [RFC3174] has also been updated to
-   handle input strings of arbitrary bit length.  See Section 1.1 for
-   license information for this code.
-
-   Section 2 below defines the terminology and functions used as
-   building blocks to form these algorithms.  Section 3 describes the
-   fundamental operations on words from which these algorithms are
-   built.  Section 4 describes how messages are padded up to an integral
-   multiple of the required block size and then parsed into blocks.
-   Section 5 defines the constants and the composite functions used to
-   specify these algorithms.  Section 6 gives the actual specification
-   for the SHA-224, SHA-256, SHA-384, and SHA-512 functions.  Section 7
-   provides pointers to the specification of HMAC keyed message
-   authentication codes based on the SHA algorithms.  Section 8 gives
-   sample code for the SHA algorithms and Section 9 code for SHA-based
-   HMACs.  The SHA-based HMACs will accept arbitrary bit length text.
-
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                      [Page 3]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-1.1.  License
-
-   Permission is granted for all uses, commercial and non-commercial, of
-   the sample code found in Section 8.  Royalty free license to use,
-   copy, modify and distribute the software found in Section 8 is
-   granted, provided that this document is identified in all material
-   mentioning or referencing this software, and provided that
-   redistributed derivative works do not contain misleading author or
-   version information.
-
-   The authors make no representations concerning either the
-   merchantability of this software or the suitability of this software
-   for any particular purpose.  It is provided "as is" without express
-   or implied warranty of any kind.
-
-2.  Notation for Bit Strings and Integers
-
-   The following terminology related to bit strings and integers will be
-   used:
-
-    a.  A hex digit is an element of the set {0, 1, ... , 9, A, ... ,
-        F}.  A hex digit is the representation of a 4-bit string.
-        Examples: 7 = 0111, A = 1010.
-
-    b.  A word equals a 32-bit or 64-bit string, which may be
-        represented as a sequence of 8 or 16 hex digits, respectively.
-        To convert a word to hex digits, each 4-bit string is converted
-        to its hex equivalent as described in (a) above.  Example:
-
-        1010 0001 0000 0011 1111 1110 0010 0011 = A103FE23.
-
-        Throughout this document, the "big-endian" convention is used
-        when expressing both 32-bit and 64-bit words, so that within
-        each word the most significant bit is shown in the left-most bit
-        position.
-
-    c.  An integer may be represented as a word or pair of words.
-
-        An integer between 0 and 2^32 - 1 inclusive may be represented
-        as a 32-bit word.  The least significant four bits of the
-        integer are represented by the right-most hex digit of the word
-        representation.  Example: the integer 291 = 2^8+2^5+2^1+2^0 =
-        256+32+2+1 is represented by the hex word 00000123.
-
-        The same holds true for an integer between 0 and 2^64-1
-        inclusive, which may be represented as a 64-bit word.
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                      [Page 4]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-        If Z is an integer, 0 <= z < 2^64, then z = (2^32)x + y where 0
-        <= x < 2^32 and 0 <= y < 2^32.  Since x and y can be represented
-        as words X and Y, respectively, z can be represented as the pair
-        of words (X,Y).
-
-    d.  block = 512-bit or 1024-bit string.  A block (e.g., B) may be
-        represented as a sequence of 32-bit or 64-bit words.
-
-3.  Operations on Words
-
-   The following logical operators will be applied to words in all four
-   hash operations specified herein.  SHA-224 and SHA-256 operate on
-   32-bit words, while SHA-384 and SHA-512 operate on 64-bit words.
-
-   In the operations below, x<<n is obtained as follows: discard the
-   left-most n bits of x and then pad the result with n zeroed bits on
-   the right (the result will still be the same number of bits).
-
-    a.  Bitwise logical word operations
-
-        X AND Y  =  bitwise logical "and" of  X and Y.
-
-        X OR Y   =  bitwise logical "inclusive-or" of X and Y.
-
-        X XOR Y  =  bitwise logical "exclusive-or" of X and Y.
-
-        NOT X    =  bitwise logical "complement" of X.
-
-        Example:
-                 01101100101110011101001001111011
-           XOR   01100101110000010110100110110111
-                 --------------------------------
-             =   00001001011110001011101111001100
-
-    b.  The operation X + Y is defined as follows: words X and Y
-        represent w-bit integers x and y, where 0 <= x < 2^w and
-        0 <= y < 2^w.  For positive integers n and m, let
-
-             n mod m
-
-        be the remainder upon dividing n by m.  Compute
-
-             z  =  (x + y) mod 2^w.
-
-        Then 0 <= z < 2^w.  Convert z to a word, Z, and define Z = X +
-        Y.
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                      [Page 5]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-    c.  The right shift operation SHR^n(x), where x is a w-bit word and
-        n is an integer with 0 <= n < w, is defined by
-
-             SHR^n(x) = x>>n
-
-    d.  The rotate right (circular right shift) operation ROTR^n(x),
-        where x is a w-bit word and n is an integer with 0 <= n < w, is
-        defined by
-
-             ROTR^n(x) = (x>>n) OR (x<<(w-n))
-
-    e.  The rotate left (circular left shift) operation ROTL^n(x), where
-        x is a w-bit word and n is an integer with 0 <= n < w, is
-        defined by
-
-             ROTL^n(X)  =  (x<<n) OR (x>>w-n)
-
-        Note the following equivalence relationships, where w is fixed
-        in each relationship:
-
-             ROTL^n(x) = ROTR^(w-x)(x)
-
-             ROTR^n(x) = ROTL^(w-n)(x)
-
-4.  Message Padding and Parsing
-
-   The hash functions specified herein are used to compute a message
-   digest for a message or data file that is provided as input.  The
-   message or data file should be considered to be a bit string.  The
-   length of the message is the number of bits in the message (the empty
-   message has length 0).  If the number of bits in a message is a
-   multiple of 8, for compactness we can represent the message in hex.
-   The purpose of message padding is to make the total length of a
-   padded message a multiple of 512 for SHA-224 and SHA-256 or a
-   multiple of 1024 for SHA-384 and SHA-512.
-
-   The following specifies how this padding shall be performed.  As a
-   summary, a "1" followed by a number of "0"s followed by a 64-bit or
-   128-bit integer are appended to the end of the message to produce a
-   padded message of length 512*n or 1024*n.  The minimum number of "0"s
-   necessary to meet this criterion is used.  The appended integer is
-   the length of the original message.  The padded message is then
-   processed by the hash function as n 512-bit or 1024-bit blocks.
-
-
-
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                      [Page 6]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-4.1.  SHA-224 and SHA-256
-
-   Suppose a message has length L < 2^64.  Before it is input to the
-   hash function, the message is padded on the right as follows:
-
-    a.  "1" is appended.  Example: if the original message is
-        "01010000", this is padded to "010100001".
-
-    b.  K "0"s are appended where K is the smallest, non-negative
-        solution to the equation
-
-             L + 1 + K = 448 (mod 512)
-
-    c.  Then append the 64-bit block that is L in binary representation.
-        After appending this block, the length of the message will be a
-        multiple of 512 bits.
-
-        Example:  Suppose the original message is the bit string
-
-             01100001 01100010 01100011 01100100 01100101
-
-        After step (a), this gives
-
-             01100001 01100010 01100011 01100100 01100101 1
-
-        Since L = 40, the number of bits in the above is 41 and K = 407
-        "0"s are appended, making the total now 448.  This gives the
-        following in hex:
-
-             61626364 65800000 00000000 00000000
-             00000000 00000000 00000000 00000000
-             00000000 00000000 00000000 00000000
-             00000000 00000000
-
-        The 64-bit representation of L = 40 is hex 00000000 00000028.
-        Hence the final padded message is the following hex:
-
-             61626364 65800000 00000000 00000000
-             00000000 00000000 00000000 00000000
-             00000000 00000000 00000000 00000000
-             00000000 00000000 00000000 00000028
-
-
-
-
-
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                      [Page 7]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-4.2.  SHA-384 and SHA-512
-
-   Suppose a message has length L < 2^128.  Before it is input to the
-   hash function, the message is padded on the right as follows:
-
-    a.  "1" is appended.  Example: if the original message is
-        "01010000", this is padded to "010100001".
-
-    b.  K "0"s are appended where K is the smallest, non-negative
-        solution to the equation
-
-             L + 1 + K = 896 (mod 1024)
-
-    c.  Then append the 128-bit block that is L in binary
-        representation.  After appending this block, the length of the
-        message will be a multiple of 1024 bits.
-
-        Example:  Suppose the original message is the bit string
-
-             01100001 01100010 01100011 01100100 01100101
-
-        After step (a) this gives
-
-             01100001 01100010 01100011 01100100 01100101 1
-
-        Since L = 40, the number of bits in the above is 41 and K = 855
-        "0"s are appended, making the total now 896.  This gives the
-        following in hex:
-
-             61626364 65800000 00000000 00000000
-             00000000 00000000 00000000 00000000
-             00000000 00000000 00000000 00000000
-             00000000 00000000 00000000 00000000
-             00000000 00000000 00000000 00000000
-             00000000 00000000 00000000 00000000
-             00000000 00000000 00000000 00000000
-
-        The 128-bit representation of L = 40 is hex 00000000 00000000
-        00000000 00000028.  Hence the final padded message is the
-        following hex:
-
-             61626364 65800000 00000000 00000000
-             00000000 00000000 00000000 00000000
-             00000000 00000000 00000000 00000000
-             00000000 00000000 00000000 00000000
-             00000000 00000000 00000000 00000000
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                      [Page 8]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-             00000000 00000000 00000000 00000000
-             00000000 00000000 00000000 00000000
-             00000000 00000000 00000000 00000028
-
-5.  Functions and Constants Used
-
-   The following subsections give the six logical functions and the
-   table of constants used in each of the hash functions.
-
-5.1.  SHA-224 and SHA-256
-
-   SHA-224 and SHA-256 use six logical functions, where each function
-   operates on 32-bit words, which are represented as x, y, and z.  The
-   result of each function is a new 32-bit word.
-
-        CH( x, y, z) = (x AND y) XOR ( (NOT x) AND z)
-
-        MAJ( x, y, z) = (x AND y) XOR (x AND z) XOR (y AND z)
-
-        BSIG0(x) = ROTR^2(x) XOR ROTR^13(x) XOR ROTR^22(x)
-
-        BSIG1(x) = ROTR^6(x) XOR ROTR^11(x) XOR ROTR^25(x)
-
-        SSIG0(x) = ROTR^7(x) XOR ROTR^18(x) XOR SHR^3(x)
-
-        SSIG1(x) = ROTR^17(x) XOR ROTR^19(x) XOR SHR^10(x)
-
-   SHA-224 and SHA-256 use the same sequence of sixty-four constant
-   32-bit words, K0, K1, ..., K63.  These words represent the first
-   thirty-two bits of the fractional parts of the cube roots of the
-   first sixty-four prime numbers.  In hex, these constant words are as
-   follows (from left to right):
-
-        428a2f98 71374491 b5c0fbcf e9b5dba5
-        3956c25b 59f111f1 923f82a4 ab1c5ed5
-        d807aa98 12835b01 243185be 550c7dc3
-        72be5d74 80deb1fe 9bdc06a7 c19bf174
-        e49b69c1 efbe4786 0fc19dc6 240ca1cc
-        2de92c6f 4a7484aa 5cb0a9dc 76f988da
-        983e5152 a831c66d b00327c8 bf597fc7
-        c6e00bf3 d5a79147 06ca6351 14292967
-        27b70a85 2e1b2138 4d2c6dfc 53380d13
-        650a7354 766a0abb 81c2c92e 92722c85
-        a2bfe8a1 a81a664b c24b8b70 c76c51a3
-        d192e819 d6990624 f40e3585 106aa070
-        19a4c116 1e376c08 2748774c 34b0bcb5
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                      [Page 9]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-        391c0cb3 4ed8aa4a 5b9cca4f 682e6ff3
-        748f82ee 78a5636f 84c87814 8cc70208
-        90befffa a4506ceb bef9a3f7 c67178f2
-
-5.2.  SHA-384 and SHA-512
-
-   SHA-384 and SHA-512 each use six logical functions, where each
-   function operates on 64-bit words, which are represented as x, y, and
-   z.  The result of each function is a new 64-bit word.
-
-        CH( x, y, z) = (x AND y) XOR ( (NOT x) AND z)
-
-        MAJ( x, y, z) = (x AND y) XOR (x AND z) XOR (y AND z)
-
-        BSIG0(x) = ROTR^28(x) XOR ROTR^34(x) XOR ROTR^39(x)
-
-        BSIG1(x) = ROTR^14(x) XOR ROTR^18(x) XOR ROTR^41(x)
-
-        SSIG0(x) = ROTR^1(x) XOR ROTR^8(x) XOR SHR^7(x)
-
-        SSIG1(x) = ROTR^19(x) XOR ROTR^61(x) XOR SHR^6(x)
-
-   SHA-384 and SHA-512 use the same sequence of eighty constant 64-bit
-   words, K0, K1, ... K79.  These words represent the first sixty-four
-   bits of the fractional parts of the cube roots of the first eighty
-   prime numbers.  In hex, these constant words are as follows (from
-   left to right):
-
-   428a2f98d728ae22 7137449123ef65cd b5c0fbcfec4d3b2f e9b5dba58189dbbc
-   3956c25bf348b538 59f111f1b605d019 923f82a4af194f9b ab1c5ed5da6d8118
-   d807aa98a3030242 12835b0145706fbe 243185be4ee4b28c 550c7dc3d5ffb4e2
-   72be5d74f27b896f 80deb1fe3b1696b1 9bdc06a725c71235 c19bf174cf692694
-   e49b69c19ef14ad2 efbe4786384f25e3 0fc19dc68b8cd5b5 240ca1cc77ac9c65
-   2de92c6f592b0275 4a7484aa6ea6e483 5cb0a9dcbd41fbd4 76f988da831153b5
-   983e5152ee66dfab a831c66d2db43210 b00327c898fb213f bf597fc7beef0ee4
-   c6e00bf33da88fc2 d5a79147930aa725 06ca6351e003826f 142929670a0e6e70
-   27b70a8546d22ffc 2e1b21385c26c926 4d2c6dfc5ac42aed 53380d139d95b3df
-   650a73548baf63de 766a0abb3c77b2a8 81c2c92e47edaee6 92722c851482353b
-   a2bfe8a14cf10364 a81a664bbc423001 c24b8b70d0f89791 c76c51a30654be30
-   d192e819d6ef5218 d69906245565a910 f40e35855771202a 106aa07032bbd1b8
-   19a4c116b8d2d0c8 1e376c085141ab53 2748774cdf8eeb99 34b0bcb5e19b48a8
-   391c0cb3c5c95a63 4ed8aa4ae3418acb 5b9cca4f7763e373 682e6ff3d6b2b8a3
-   748f82ee5defb2fc 78a5636f43172f60 84c87814a1f0ab72 8cc702081a6439ec
-   90befffa23631e28 a4506cebde82bde9 bef9a3f7b2c67915 c67178f2e372532b
-   ca273eceea26619c d186b8c721c0c207 eada7dd6cde0eb1e f57d4f7fee6ed178
-   06f067aa72176fba 0a637dc5a2c898a6 113f9804bef90dae 1b710b35131c471b
-   28db77f523047d84 32caab7b40c72493 3c9ebe0a15c9bebc 431d67c49c100d4c
-   4cc5d4becb3e42b6 597f299cfc657e2a 5fcb6fab3ad6faec 6c44198c4a475817
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 10]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-6.  Computing the Message Digest
-
-   The output of each of the secure hash functions, after being applied
-   to a message of N blocks, is the hash quantity H(N).  For SHA-224 and
-   SHA-256, H(i) can be considered to be eight 32-bit words, H(i)0,
-   H(i)1, ... H(i)7.  For SHA-384 and SHA-512, it can be considered to
-   be eight 64-bit words, H(i)0, H(i)1, ..., H(i)7.
-
-   As described below, the hash words are initialized, modified as each
-   message block is processed, and finally concatenated after processing
-   the last block to yield the output.  For SHA-256 and SHA-512, all of
-   the H(N) variables are concatenated while the SHA-224 and SHA-384
-   hashes are produced by omitting some from the final concatenation.
-
-6.1.  SHA-224 and SHA-256 Initialization
-
-   For SHA-224, the initial hash value, H(0), consists of the following
-   32-bit words in hex:
-
-        H(0)0 = c1059ed8
-        H(0)1 = 367cd507
-        H(0)2 = 3070dd17
-        H(0)3 = f70e5939
-        H(0)4 = ffc00b31
-        H(0)5 = 68581511
-        H(0)6 = 64f98fa7
-        H(0)7 = befa4fa4
-
-   For SHA-256, the initial hash value, H(0), consists of the following
-   eight 32-bit words, in hex.  These words were obtained by taking the
-   first thirty-two bits of the fractional parts of the square roots of
-   the first eight prime numbers.
-
-        H(0)0 = 6a09e667
-        H(0)1 = bb67ae85
-        H(0)2 = 3c6ef372
-        H(0)3 = a54ff53a
-        H(0)4 = 510e527f
-        H(0)5 = 9b05688c
-        H(0)6 = 1f83d9ab
-        H(0)7 = 5be0cd19
-
-6.2.  SHA-224 and SHA-256 Processing
-
-   SHA-224 and SHA-256 perform identical processing on messages blocks
-   and differ only in how H(0) is initialized and how they produce their
-   final output.  They may be used to hash a message, M, having a length
-   of L bits, where 0 <= L < 2^64.  The algorithm uses (1) a message
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 11]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-   schedule of sixty-four 32-bit words, (2) eight working variables of
-   32 bits each, and (3) a hash value of eight 32-bit words.
-
-   The words of the message schedule are labeled W0, W1, ..., W63.  The
-   eight working variables are labeled a, b, c, d, e, f, g, and h.  The
-   words of the hash value are labeled H(i)0, H(i)1, ..., H(i)7, which
-   will hold the initial hash value, H(0), replaced by each successive
-   intermediate hash value (after each message block is processed),
-   H(i), and ending with the final hash value, H(N), after all N blocks
-   are processed.  They also use two temporary words, T1 and T2.
-
-   The input message is padded as described in Section 4.1 above then
-   parsed into 512-bit blocks, which are considered to be composed of 16
-   32-bit words M(i)0, M(i)1, ..., M(i)15.  The following computations
-   are then performed for each of the N message blocks.  All addition is
-   performed modulo 2^32.
-
-   For i = 1 to N
-
-      1. Prepare the message schedule W:
-         For t = 0 to 15
-            Wt = M(i)t
-         For t = 16 to 63
-            Wt = SSIG1(W(t-2)) + W(t-7) + SSIG0(t-15) + W(t-16)
-
-      2. Initialize the working variables:
-         a = H(i-1)0
-         b = H(i-1)1
-         c = H(i-1)2
-         d = H(i-1)3
-         e = H(i-1)4
-         f = H(i-1)5
-         g = H(i-1)6
-         h = H(i-1)7
-
-      3. Perform the main hash computation:
-         For t = 0 to 63
-            T1 = h + BSIG1(e) + CH(e,f,g) + Kt + Wt
-            T2 = BSIG0(a) + MAJ(a,b,c)
-            h = g
-            g = f
-            f = e
-            e = d + T1
-            d = c
-            c = b
-            b = a
-            a = T1 + T2
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 12]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-      4. Compute the intermediate hash value H(i):
-         H(i)0 = a + H(i-1)0
-         H(i)1 = b + H(i-1)1
-         H(i)2 = c + H(i-1)2
-         H(i)3 = d + H(i-1)3
-         H(i)4 = e + H(i-1)4
-         H(i)5 = f + H(i-1)5
-         H(i)6 = g + H(i-1)6
-         H(i)7 = h + H(i-1)7
-
-   After the above computations have been sequentially performed for all
-   of the blocks in the message, the final output is calculated.  For
-   SHA-256, this is the concatenation of all of H(N)0, H(N)1, through
-   H(N)7.  For SHA-224, this is the concatenation of H(N)0, H(N)1,
-   through H(N)6.
-
-6.3.  SHA-384 and SHA-512 Initialization
-
-   For SHA-384, the initial hash value, H(0), consists of the following
-   eight 64-bit words, in hex.  These words were obtained by taking the
-   first sixty-four bits of the fractional parts of the square roots of
-   the ninth through sixteenth prime numbers.
-
-        H(0)0 = cbbb9d5dc1059ed8
-        H(0)1 = 629a292a367cd507
-        H(0)2 = 9159015a3070dd17
-        H(0)3 = 152fecd8f70e5939
-        H(0)4 = 67332667ffc00b31
-        H(0)5 = 8eb44a8768581511
-        H(0)6 = db0c2e0d64f98fa7
-        H(0)7 = 47b5481dbefa4fa4
-
-   For SHA-512, the initial hash value, H(0), consists of the following
-   eight 64-bit words, in hex.  These words were obtained by taking the
-   first sixty-four bits of the fractional parts of the square roots of
-   the first eight prime numbers.
-
-        H(0)0 = 6a09e667f3bcc908
-        H(0)1 = bb67ae8584caa73b
-        H(0)2 = 3c6ef372fe94f82b
-        H(0)3 = a54ff53a5f1d36f1
-        H(0)4 = 510e527fade682d1
-        H(0)5 = 9b05688c2b3e6c1f
-        H(0)6 = 1f83d9abfb41bd6b
-        H(0)7 = 5be0cd19137e2179
-
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 13]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-6.4.  SHA-384 and SHA-512 Processing
-
-   SHA-384 and SHA-512 perform identical processing on message blocks
-   and differ only in how H(0) is initialized and how they produce their
-   final output.  They may be used to hash a message, M, having a length
-   of L bits, where 0 <= L < 2^128.  The algorithm uses (1) a message
-   schedule of eighty 64-bit words, (2) eight working variables of 64
-   bits each, and (3) a hash value of eight 64-bit words.
-
-   The words of the message schedule are labeled W0, W1, ..., W79.  The
-   eight working variables are labeled a, b, c, d, e, f, g, and h.  The
-   words of the hash value are labeled H(i)0, H(i)1, ..., H(i)7, which
-   will hold the initial hash value, H(0), replaced by each successive
-   intermediate hash value (after each message block is processed),
-   H(i), and ending with the final hash value, H(N) after all N blocks
-   are processed.
-
-   The input message is padded as described in Section 4.2 above, then
-   parsed into 1024-bit blocks, which are considered to be composed of
-   16 64-bit words M(i)0, M(i)1, ..., M(i)15.  The following
-   computations are then performed for each of the N message blocks.
-   All addition is performed modulo 2^64.
-
-   For i = 1 to N
-
-      1. Prepare the message schedule W:
-         For t = 0 to 15
-            Wt = M(i)t
-         For t = 16 to 79
-            Wt = SSIG1(W(t-2)) + W(t-7) + SSIG0(t-15) + W(t-16)
-
-      2. Initialize the working variables:
-         a = H(i-1)0
-         b = H(i-1)1
-         c = H(i-1)2
-         d = H(i-1)3
-         e = H(i-1)4
-         f = H(i-1)5
-         g = H(i-1)6
-         h = H(i-1)7
-
-      3. Perform the main hash computation:
-         For t = 0 to 79
-            T1 = h + BSIG1(e) + CH(e,f,g) + Kt + Wt
-            T2 = BSIG0(a) + MAJ(a,b,c)
-            h = g
-            g = f
-            f = e
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 14]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-            e = d + T1
-            d = c
-            c = b
-            b = a
-            a = T1 + T2
-
-      4. Compute the intermediate hash value H(i):
-         H(i)0 = a + H(i-1)0
-         H(i)1 = b + H(i-1)1
-         H(i)2 = c + H(i-1)2
-         H(i)3 = d + H(i-1)3
-         H(i)4 = e + H(i-1)4
-         H(i)5 = f + H(i-1)5
-         H(i)6 = g + H(i-1)6
-         H(i)7 = h + H(i-1)7
-
-   After the above computations have been sequentially performed for all
-   of the blocks in the message, the final output is calculated.  For
-   SHA-512, this is the concatenation of all of H(N)0, H(N)1, through
-   H(N)7.  For SHA-384, this is the concatenation of H(N)0, H(N)1,
-   through H(N)5.
-
-7.  SHA-Based HMACs
-
-   HMAC is a method for computing a keyed MAC (message authentication
-   code) using a hash function as described in [RFC2104].  It uses a key
-   to mix in with the input text to produce the final hash.
-
-   Sample code is also provided, in Section 8.3 below, to perform HMAC
-   based on any of the SHA algorithms described herein.  The sample code
-   found in [RFC2104] was written in terms of a specified text size.
-   Since SHA is defined in terms of an arbitrary number of bits, the
-   sample HMAC code has been written to allow the text input to HMAC to
-   have an arbitrary number of octets and bits.  A fixed-length
-   interface is also provided.
-
-8.  C Code for SHAs
-
-   Below is a demonstration implementation of these secure hash
-   functions in C.  Section 8.1 contains the header file sha.h, which
-   declares all constants, structures, and functions used by the sha and
-   hmac functions.  Section 8.2 contains the C code for sha1.c,
-   sha224-256.c, sha384-512.c, and usha.c along with sha-private.h,
-   which provides some declarations common to all the sha functions.
-   Section 8.3 contains the C code for the hmac functions.  Section 8.4
-   contains a test driver to exercise the code.
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 15]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-   For each of the digest length $$$, there is the following set of
-   constants, a structure, and functions:
-
-   Constants:
-      SHA$$$HashSize      number of octets in the hash
-      SHA$$$HashSizeBits  number of bits in the hash
-      SHA$$$_Message_Block_Size
-                          number of octets used in the intermediate
-                          message blocks
-      shaSuccess = 0      constant returned by each function on success
-      shaNull = 1         constant returned by each function when
-                          presented with a null pointer parameter
-      shaInputTooLong = 2  constant returned by each function when the
-                          input data is too long
-      shaStateError       constant returned by each function when
-                          SHA$$$Input is called after SHA$$$FinalBits or
-                          SHA$$$Result.
-
-   Structure:
-      typedef SHA$$$Context
-                          an opaque structure holding the complete state
-                          for producing the hash
-
-   Functions:
-                  int SHA$$$Reset(SHA$$$Context *);
-            Reset the hash context state
-      int SHA$$$Input(SHA$$$Context *, const uint8_t *octets,
-                  unsigned int bytecount);
-            Incorporate bytecount octets into the hash.
-      int SHA$$$FinalBits(SHA$$$Context *, const uint8_t octet,
-                  unsigned int bitcount);
-            Incorporate bitcount bits into the hash.  The bits are in
-            the upper portion of the octet.  SHA$$$Input() cannot be
-            called after this.
-      int SHA$$$Result(SHA$$$Context *,
-                  uint8_t Message_Digest[SHA$$$HashSize]);
-            Do the final calculations on the hash and copy the value
-            into Message_Digest.
-
-   In addition, functions with the prefix USHA are provided that take a
-   SHAversion value (SHA$$$) to select the SHA function suite.  They add
-   the following constants, structure, and functions:
-
-   Constants:
-      shaBadParam         constant returned by USHA functions when
-                          presented with a bad SHAversion (SHA$$$)
-                          parameter
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 16]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-      SHA$$$              SHAversion enumeration values, used by usha
-                          and hmac functions to select the SHA function
-                          suite
-
-   Structure:
-      typedef USHAContext
-                          an opaque structure holding the complete state
-                          for producing the hash
-
-   Functions:
-      int USHAReset(USHAContext *, SHAversion whichSha);
-            Reset the hash context state.
-      int USHAInput(USHAContext *,
-                  const uint8_t *bytes, unsigned int bytecount);
-            Incorporate bytecount octets into the hash.
-      int USHAFinalBits(USHAContext *,
-                  const uint8_t bits, unsigned int bitcount);
-                  Incorporate bitcount bits into the hash.
-      int USHAResult(USHAContext *,
-                  uint8_t Message_Digest[USHAMaxHashSize]);
-            Do the final calculations on the hash and copy the value
-            into Message_Digest.  Octets in Message_Digest beyond
-      USHAHashSize(whichSha) are left untouched.
-                  int USHAHashSize(enum SHAversion whichSha);
-            The number of octets in the given hash.
-      int USHAHashSizeBits(enum SHAversion whichSha);
-            The number of bits in the given hash.
-      int USHABlockSize(enum SHAversion whichSha);
-            The internal block size for the given hash.
-
-   The hmac functions follow the same pattern to allow any length of
-   text input to be used.
-
-   Structure:
-      typedef HMACContext an opaque structure holding the complete state
-                          for producing the hash
-
-   Functions:
-      int hmacReset(HMACContext *ctx, enum SHAversion whichSha,
-                  const unsigned char *key, int key_len);
-            Reset the hash context state.
-      int hmacInput(HMACContext *ctx, const unsigned char *text,
-                  int text_len);
-            Incorporate text_len octets into the hash.
-      int hmacFinalBits(HMACContext *ctx, const uint8_t bits,
-                  unsigned int bitcount);
-            Incorporate bitcount bits into the hash.
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 17]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-      int hmacResult(HMACContext *ctx,
-                  uint8_t Message_Digest[USHAMaxHashSize]);
-            Do the final calculations on the hash and copy the value
-            into Message_Digest.  Octets in Message_Digest beyond
-            USHAHashSize(whichSha) are left untouched.
-
-   In addition, a combined interface is provided, similar to that shown
-   in RFC 2104, that allows a fixed-length text input to be used.
-
-      int hmac(SHAversion whichSha,
-                  const unsigned char *text, int text_len,
-                  const unsigned char *key, int key_len,
-                  uint8_t Message_Digest[USHAMaxHashSize]);
-            Calculate the given digest for the given text and key, and
-            return the resulting hash.  Octets in Message_Digest beyond
-            USHAHashSize(whichSha) are left untouched.
-
-8.1.  The .h File
-
-/**************************** sha.h ****************************/
-/******************* See RFC 4634 for details ******************/
-#ifndef _SHA_H_
-#define _SHA_H_
-
-/*
- *  Description:
- *      This file implements the Secure Hash Signature Standard
- *      algorithms as defined in the National Institute of Standards
- *      and Technology Federal Information Processing Standards
- *      Publication (FIPS PUB) 180-1 published on April 17, 1995, 180-2
- *      published on August 1, 2002, and the FIPS PUB 180-2 Change
- *      Notice published on February 28, 2004.
- *
- *      A combined document showing all algorithms is available at
- *              http://csrc.nist.gov/publications/fips/
- *              fips180-2/fips180-2withchangenotice.pdf
- *
- *      The five hashes are defined in these sizes:
- *              SHA-1           20 byte / 160 bit
- *              SHA-224         28 byte / 224 bit
- *              SHA-256         32 byte / 256 bit
- *              SHA-384         48 byte / 384 bit
- *              SHA-512         64 byte / 512 bit
- */
-
-#include <stdint.h>
-/*
- * If you do not have the ISO standard stdint.h header file, then you
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 18]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- * must typedef the following:
- *    name              meaning
- *  uint64_t         unsigned 64 bit integer
- *  uint32_t         unsigned 32 bit integer
- *  uint8_t          unsigned 8 bit integer (i.e., unsigned char)
- *  int_least16_t    integer of >= 16 bits
- *
- */
-
-#ifndef _SHA_enum_
-#define _SHA_enum_
-/*
- *  All SHA functions return one of these values.
- */
-enum {
-    shaSuccess = 0,
-    shaNull,            /* Null pointer parameter */
-    shaInputTooLong,    /* input data too long */
-    shaStateError,      /* called Input after FinalBits or Result */
-    shaBadParam         /* passed a bad parameter */
-};
-#endif /* _SHA_enum_ */
-
-/*
- *  These constants hold size information for each of the SHA
- *  hashing operations
- */
-enum {
-    SHA1_Message_Block_Size = 64, SHA224_Message_Block_Size = 64,
-    SHA256_Message_Block_Size = 64, SHA384_Message_Block_Size = 128,
-    SHA512_Message_Block_Size = 128,
-    USHA_Max_Message_Block_Size = SHA512_Message_Block_Size,
-
-    SHA1HashSize = 20, SHA224HashSize = 28, SHA256HashSize = 32,
-    SHA384HashSize = 48, SHA512HashSize = 64,
-    USHAMaxHashSize = SHA512HashSize,
-
-    SHA1HashSizeBits = 160, SHA224HashSizeBits = 224,
-    SHA256HashSizeBits = 256, SHA384HashSizeBits = 384,
-    SHA512HashSizeBits = 512, USHAMaxHashSizeBits = SHA512HashSizeBits
-};
-
-/*
- *  These constants are used in the USHA (unified sha) functions.
- */
-typedef enum SHAversion {
-    SHA1, SHA224, SHA256, SHA384, SHA512
-} SHAversion;
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 19]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-/*
- *  This structure will hold context information for the SHA-1
- *  hashing operation.
- */
-typedef struct SHA1Context {
-    uint32_t Intermediate_Hash[SHA1HashSize/4]; /* Message Digest */
-
-    uint32_t Length_Low;                /* Message length in bits */
-    uint32_t Length_High;               /* Message length in bits */
-
-    int_least16_t Message_Block_Index;  /* Message_Block array index */
-                                        /* 512-bit message blocks */
-    uint8_t Message_Block[SHA1_Message_Block_Size];
-
-    int Computed;                       /* Is the digest computed? */
-    int Corrupted;                      /* Is the digest corrupted? */
-} SHA1Context;
-
-/*
- *  This structure will hold context information for the SHA-256
- *  hashing operation.
- */
-typedef struct SHA256Context {
-    uint32_t Intermediate_Hash[SHA256HashSize/4]; /* Message Digest */
-
-    uint32_t Length_Low;                /* Message length in bits */
-    uint32_t Length_High;               /* Message length in bits */
-
-    int_least16_t Message_Block_Index;  /* Message_Block array index */
-                                        /* 512-bit message blocks */
-    uint8_t Message_Block[SHA256_Message_Block_Size];
-
-    int Computed;                       /* Is the digest computed? */
-    int Corrupted;                      /* Is the digest corrupted? */
-} SHA256Context;
-
-/*
- *  This structure will hold context information for the SHA-512
- *  hashing operation.
- */
-typedef struct SHA512Context {
-#ifdef USE_32BIT_ONLY
-    uint32_t Intermediate_Hash[SHA512HashSize/4]; /* Message Digest  */
-    uint32_t Length[4];                 /* Message length in bits */
-#else /* !USE_32BIT_ONLY */
-    uint64_t Intermediate_Hash[SHA512HashSize/8]; /* Message Digest */
-    uint64_t Length_Low, Length_High;   /* Message length in bits */
-#endif /* USE_32BIT_ONLY */
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 20]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-    int_least16_t Message_Block_Index;  /* Message_Block array index */
-                                        /* 1024-bit message blocks */
-    uint8_t Message_Block[SHA512_Message_Block_Size];
-
-    int Computed;                       /* Is the digest computed?*/
-    int Corrupted;                      /* Is the digest corrupted? */
-} SHA512Context;
-
-/*
- *  This structure will hold context information for the SHA-224
- *  hashing operation. It uses the SHA-256 structure for computation.
- */
-typedef struct SHA256Context SHA224Context;
-
-/*
- *  This structure will hold context information for the SHA-384
- *  hashing operation. It uses the SHA-512 structure for computation.
- */
-typedef struct SHA512Context SHA384Context;
-
-/*
- *  This structure holds context information for all SHA
- *  hashing operations.
- */
-typedef struct USHAContext {
-    int whichSha;               /* which SHA is being used */
-    union {
-      SHA1Context sha1Context;
-      SHA224Context sha224Context; SHA256Context sha256Context;
-      SHA384Context sha384Context; SHA512Context sha512Context;
-    } ctx;
-} USHAContext;
-
-/*
- *  This structure will hold context information for the HMAC
- *  keyed hashing operation.
- */
-typedef struct HMACContext {
-    int whichSha;               /* which SHA is being used */
-    int hashSize;               /* hash size of SHA being used */
-    int blockSize;              /* block size of SHA being used */
-    USHAContext shaContext;     /* SHA context */
-    unsigned char k_opad[USHA_Max_Message_Block_Size];
-                        /* outer padding - key XORd with opad */
-} HMACContext;
-
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 21]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-/*
- *  Function Prototypes
- */
-
-/* SHA-1 */
-extern int SHA1Reset(SHA1Context *);
-extern int SHA1Input(SHA1Context *, const uint8_t *bytes,
-                     unsigned int bytecount);
-extern int SHA1FinalBits(SHA1Context *, const uint8_t bits,
-                         unsigned int bitcount);
-extern int SHA1Result(SHA1Context *,
-                      uint8_t Message_Digest[SHA1HashSize]);
-
-/* SHA-224 */
-extern int SHA224Reset(SHA224Context *);
-extern int SHA224Input(SHA224Context *, const uint8_t *bytes,
-                       unsigned int bytecount);
-extern int SHA224FinalBits(SHA224Context *, const uint8_t bits,
-                           unsigned int bitcount);
-extern int SHA224Result(SHA224Context *,
-                        uint8_t Message_Digest[SHA224HashSize]);
-
-/* SHA-256 */
-extern int SHA256Reset(SHA256Context *);
-extern int SHA256Input(SHA256Context *, const uint8_t *bytes,
-                       unsigned int bytecount);
-extern int SHA256FinalBits(SHA256Context *, const uint8_t bits,
-                           unsigned int bitcount);
-extern int SHA256Result(SHA256Context *,
-                        uint8_t Message_Digest[SHA256HashSize]);
-
-/* SHA-384 */
-extern int SHA384Reset(SHA384Context *);
-extern int SHA384Input(SHA384Context *, const uint8_t *bytes,
-                       unsigned int bytecount);
-extern int SHA384FinalBits(SHA384Context *, const uint8_t bits,
-                           unsigned int bitcount);
-extern int SHA384Result(SHA384Context *,
-                        uint8_t Message_Digest[SHA384HashSize]);
-
-/* SHA-512 */
-extern int SHA512Reset(SHA512Context *);
-extern int SHA512Input(SHA512Context *, const uint8_t *bytes,
-                       unsigned int bytecount);
-extern int SHA512FinalBits(SHA512Context *, const uint8_t bits,
-                           unsigned int bitcount);
-extern int SHA512Result(SHA512Context *,
-                        uint8_t Message_Digest[SHA512HashSize]);
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 22]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-/* Unified SHA functions, chosen by whichSha */
-extern int USHAReset(USHAContext *, SHAversion whichSha);
-extern int USHAInput(USHAContext *,
-                     const uint8_t *bytes, unsigned int bytecount);
-extern int USHAFinalBits(USHAContext *,
-                         const uint8_t bits, unsigned int bitcount);
-extern int USHAResult(USHAContext *,
-                      uint8_t Message_Digest[USHAMaxHashSize]);
-extern int USHABlockSize(enum SHAversion whichSha);
-extern int USHAHashSize(enum SHAversion whichSha);
-extern int USHAHashSizeBits(enum SHAversion whichSha);
-
-/*
- * HMAC Keyed-Hashing for Message Authentication, RFC2104,
- * for all SHAs.
- * This interface allows a fixed-length text input to be used.
- */
-extern int hmac(SHAversion whichSha, /* which SHA algorithm to use */
-    const unsigned char *text,     /* pointer to data stream */
-    int text_len,                  /* length of data stream */
-    const unsigned char *key,      /* pointer to authentication key */
-    int key_len,                   /* length of authentication key */
-    uint8_t digest[USHAMaxHashSize]); /* caller digest to fill in */
-
-/*
- * HMAC Keyed-Hashing for Message Authentication, RFC2104,
- * for all SHAs.
- * This interface allows any length of text input to be used.
- */
-extern int hmacReset(HMACContext *ctx, enum SHAversion whichSha,
-                     const unsigned char *key, int key_len);
-extern int hmacInput(HMACContext *ctx, const unsigned char *text,
-                     int text_len);
-
-extern int hmacFinalBits(HMACContext *ctx, const uint8_t bits,
-                         unsigned int bitcount);
-extern int hmacResult(HMACContext *ctx,
-                      uint8_t digest[USHAMaxHashSize]);
-
-#endif /* _SHA_H_ */
-
-
-
-
-
-
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 23]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-8.2.  The SHA Code
-
-   This code is primarily intended as expository and could be optimized
-   further.  For example, the assignment rotations through the variables
-   a, b, ..., h could be treated as a cycle and the loop unrolled,
-   rather than doing the explicit copying.
-
-   Note that there are alternative representations of the Ch() and Maj()
-   functions controlled by an ifdef.
-
-8.2.1.  sha1.c
-
-/**************************** sha1.c ****************************/
-/******************** See RFC 4634 for details ******************/
-/*
- *  Description:
- *      This file implements the Secure Hash Signature Standard
- *      algorithms as defined in the National Institute of Standards
- *      and Technology Federal Information Processing Standards
- *      Publication (FIPS PUB) 180-1 published on April 17, 1995, 180-2
- *      published on August 1, 2002, and the FIPS PUB 180-2 Change
- *      Notice published on February 28, 2004.
- *
- *      A combined document showing all algorithms is available at
- *              http://csrc.nist.gov/publications/fips/
- *              fips180-2/fips180-2withchangenotice.pdf
- *
- *      The SHA-1 algorithm produces a 160-bit message digest for a
- *      given data stream.  It should take about 2**n steps to find a
- *      message with the same digest as a given message and
- *      2**(n/2) to find any two messages with the same digest,
- *      when n is the digest size in bits.  Therefore, this
- *      algorithm can serve as a means of providing a
- *      "fingerprint" for a message.
- *
- *  Portability Issues:
- *      SHA-1 is defined in terms of 32-bit "words".  This code
- *      uses <stdint.h> (included via "sha.h") to define 32 and 8
- *      bit unsigned integer types.  If your C compiler does not
- *      support 32 bit unsigned integers, this code is not
- *      appropriate.
- *
- *  Caveats:
- *      SHA-1 is designed to work with messages less than 2^64 bits
- *      long. This implementation uses SHA1Input() to hash the bits
- *      that are a multiple of the size of an 8-bit character, and then
- *      uses SHA1FinalBits() to hash the final few bits of the input.
- */
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 24]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-#include "sha.h"
-#include "sha-private.h"
-
-/*
- *  Define the SHA1 circular left shift macro
- */
-#define SHA1_ROTL(bits,word) \
-                (((word) << (bits)) | ((word) >> (32-(bits))))
-
-/*
- * add "length" to the length
- */
-static uint32_t addTemp;
-#define SHA1AddLength(context, length)                     \
-    (addTemp = (context)->Length_Low,                      \
-     (context)->Corrupted =                                \
-        (((context)->Length_Low += (length)) < addTemp) && \
-        (++(context)->Length_High == 0) ? 1 : 0)
-
-/* Local Function Prototypes */
-static void SHA1Finalize(SHA1Context *context, uint8_t Pad_Byte);
-static void SHA1PadMessage(SHA1Context *, uint8_t Pad_Byte);
-static void SHA1ProcessMessageBlock(SHA1Context *);
-
-/*
- *  SHA1Reset
- *
- *  Description:
- *      This function will initialize the SHA1Context in preparation
- *      for computing a new SHA1 message digest.
- *
- *  Parameters:
- *      context: [in/out]
- *          The context to reset.
- *
- *  Returns:
- *      sha Error Code.
- *
- */
-int SHA1Reset(SHA1Context *context)
-{
-    if (!context)
-        return shaNull;
-
-    context->Length_Low             = 0;
-    context->Length_High            = 0;
-    context->Message_Block_Index    = 0;
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 25]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-    /* Initial Hash Values: FIPS-180-2 section 5.3.1 */
-    context->Intermediate_Hash[0]   = 0x67452301;
-    context->Intermediate_Hash[1]   = 0xEFCDAB89;
-    context->Intermediate_Hash[2]   = 0x98BADCFE;
-    context->Intermediate_Hash[3]   = 0x10325476;
-    context->Intermediate_Hash[4]   = 0xC3D2E1F0;
-
-    context->Computed   = 0;
-    context->Corrupted  = 0;
-
-    return shaSuccess;
-}
-
-/*
- *  SHA1Input
- *
- *  Description:
- *      This function accepts an array of octets as the next portion
- *      of the message.
- *
- *  Parameters:
- *      context: [in/out]
- *          The SHA context to update
- *      message_array: [in]
- *          An array of characters representing the next portion of
- *          the message.
- *      length: [in]
- *          The length of the message in message_array
- *
- *  Returns:
- *      sha Error Code.
- *
- */
-int SHA1Input(SHA1Context *context,
-    const uint8_t *message_array, unsigned length)
-{
-  if (!length)
-    return shaSuccess;
-
-  if (!context || !message_array)
-    return shaNull;
-
-  if (context->Computed) {
-    context->Corrupted = shaStateError;
-    return shaStateError;
-  }
-
-  if (context->Corrupted)
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 26]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-     return context->Corrupted;
-
-  while (length-- && !context->Corrupted) {
-    context->Message_Block[context->Message_Block_Index++] =
-      (*message_array & 0xFF);
-
-    if (!SHA1AddLength(context, 8) &&
-      (context->Message_Block_Index == SHA1_Message_Block_Size))
-      SHA1ProcessMessageBlock(context);
-
-    message_array++;
-  }
-
-  return shaSuccess;
-}
-
-/*
- * SHA1FinalBits
- *
- * Description:
- *   This function will add in any final bits of the message.
- *
- * Parameters:
- *   context: [in/out]
- *     The SHA context to update
- *   message_bits: [in]
- *     The final bits of the message, in the upper portion of the
- *     byte. (Use 0b###00000 instead of 0b00000### to input the
- *     three bits ###.)
- *   length: [in]
- *     The number of bits in message_bits, between 1 and 7.
- *
- * Returns:
- *   sha Error Code.
- */
-int SHA1FinalBits(SHA1Context *context, const uint8_t message_bits,
-    unsigned int length)
-{
-  uint8_t masks[8] = {
-      /* 0 0b00000000 */ 0x00, /* 1 0b10000000 */ 0x80,
-      /* 2 0b11000000 */ 0xC0, /* 3 0b11100000 */ 0xE0,
-      /* 4 0b11110000 */ 0xF0, /* 5 0b11111000 */ 0xF8,
-      /* 6 0b11111100 */ 0xFC, /* 7 0b11111110 */ 0xFE
-  };
-  uint8_t markbit[8] = {
-      /* 0 0b10000000 */ 0x80, /* 1 0b01000000 */ 0x40,
-      /* 2 0b00100000 */ 0x20, /* 3 0b00010000 */ 0x10,
-      /* 4 0b00001000 */ 0x08, /* 5 0b00000100 */ 0x04,
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 27]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-      /* 6 0b00000010 */ 0x02, /* 7 0b00000001 */ 0x01
-  };
-
-  if (!length)
-    return shaSuccess;
-
-  if (!context)
-    return shaNull;
-
-  if (context->Computed || (length >= 8) || (length == 0)) {
-    context->Corrupted = shaStateError;
-    return shaStateError;
-  }
-
-  if (context->Corrupted)
-     return context->Corrupted;
-
-  SHA1AddLength(context, length);
-  SHA1Finalize(context,
-    (uint8_t) ((message_bits & masks[length]) | markbit[length]));
-
-  return shaSuccess;
-}
-
-/*
- * SHA1Result
- *
- * Description:
- *   This function will return the 160-bit message digest into the
- *   Message_Digest array provided by the caller.
- *   NOTE: The first octet of hash is stored in the 0th element,
- *      the last octet of hash in the 19th element.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to use to calculate the SHA-1 hash.
- *   Message_Digest: [out]
- *     Where the digest is returned.
- *
- * Returns:
- *   sha Error Code.
- *
- */
-int SHA1Result(SHA1Context *context,
-    uint8_t Message_Digest[SHA1HashSize])
-{
-  int i;
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 28]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  if (!context || !Message_Digest)
-    return shaNull;
-
-  if (context->Corrupted)
-    return context->Corrupted;
-
-  if (!context->Computed)
-    SHA1Finalize(context, 0x80);
-
-  for (i = 0; i < SHA1HashSize; ++i)
-    Message_Digest[i] = (uint8_t) (context->Intermediate_Hash[i>>2]
-              >> 8 * ( 3 - ( i & 0x03 ) ));
-
-  return shaSuccess;
-}
-
-/*
- * SHA1Finalize
- *
- * Description:
- *   This helper function finishes off the digest calculations.
- *
- * Parameters:
- *   context: [in/out]
- *     The SHA context to update
- *   Pad_Byte: [in]
- *     The last byte to add to the digest before the 0-padding
- *     and length. This will contain the last bits of the message
- *     followed by another single bit. If the message was an
- *     exact multiple of 8-bits long, Pad_Byte will be 0x80.
- *
- * Returns:
- *   sha Error Code.
- *
- */
-static void SHA1Finalize(SHA1Context *context, uint8_t Pad_Byte)
-{
-  int i;
-  SHA1PadMessage(context, Pad_Byte);
-  /* message may be sensitive, clear it out */
-  for (i = 0; i < SHA1_Message_Block_Size; ++i)
-    context->Message_Block[i] = 0;
-  context->Length_Low = 0;  /* and clear length */
-  context->Length_High = 0;
-  context->Computed = 1;
-}
-
-/*
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 29]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- * SHA1PadMessage
- *
- * Description:
- *   According to the standard, the message must be padded to an
- *   even 512 bits. The first padding bit must be a '1'. The last
- *   64 bits represent the length of the original message. All bits
- *   in between should be 0. This helper function will pad the
- *   message according to those rules by filling the Message_Block
- *   array accordingly. When it returns, it can be assumed that the
- *   message digest has been computed.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to pad
- *   Pad_Byte: [in]
- *     The last byte to add to the digest before the 0-padding
- *     and length. This will contain the last bits of the message
- *     followed by another single bit. If the message was an
- *     exact multiple of 8-bits long, Pad_Byte will be 0x80.
- *
- * Returns:
- *   Nothing.
- */
-static void SHA1PadMessage(SHA1Context *context, uint8_t Pad_Byte)
-{
-  /*
-   * Check to see if the current message block is too small to hold
-   * the initial padding bits and length. If so, we will pad the
-   * block, process it, and then continue padding into a second
-   * block.
-   */
-  if (context->Message_Block_Index >= (SHA1_Message_Block_Size - 8)) {
-    context->Message_Block[context->Message_Block_Index++] = Pad_Byte;
-    while (context->Message_Block_Index < SHA1_Message_Block_Size)
-      context->Message_Block[context->Message_Block_Index++] = 0;
-
-    SHA1ProcessMessageBlock(context);
-  } else
-    context->Message_Block[context->Message_Block_Index++] = Pad_Byte;
-
-  while (context->Message_Block_Index < (SHA1_Message_Block_Size - 8))
-    context->Message_Block[context->Message_Block_Index++] = 0;
-
-  /*
-   * Store the message length as the last 8 octets
-   */
-  context->Message_Block[56] = (uint8_t) (context->Length_High >> 24);
-  context->Message_Block[57] = (uint8_t) (context->Length_High >> 16);
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 30]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  context->Message_Block[58] = (uint8_t) (context->Length_High >> 8);
-  context->Message_Block[59] = (uint8_t) (context->Length_High);
-  context->Message_Block[60] = (uint8_t) (context->Length_Low >> 24);
-  context->Message_Block[61] = (uint8_t) (context->Length_Low >> 16);
-  context->Message_Block[62] = (uint8_t) (context->Length_Low >> 8);
-  context->Message_Block[63] = (uint8_t) (context->Length_Low);
-
-  SHA1ProcessMessageBlock(context);
-}
-
-/*
- * SHA1ProcessMessageBlock
- *
- * Description:
- *   This helper function will process the next 512 bits of the
- *   message stored in the Message_Block array.
- *
- * Parameters:
- *   None.
- *
- * Returns:
- *   Nothing.
- *
- * Comments:
- *   Many of the variable names in this code, especially the
- *   single character names, were used because those were the
- *   names used in the publication.
- */
-static void SHA1ProcessMessageBlock(SHA1Context *context)
-{
-  /* Constants defined in FIPS-180-2, section 4.2.1 */
-  const uint32_t K[4] = {
-      0x5A827999, 0x6ED9EBA1, 0x8F1BBCDC, 0xCA62C1D6
-  };
-  int        t;               /* Loop counter */
-  uint32_t   temp;            /* Temporary word value */
-  uint32_t   W[80];           /* Word sequence */
-  uint32_t   A, B, C, D, E;   /* Word buffers */
-
-  /*
-   * Initialize the first 16 words in the array W
-   */
-  for (t = 0; t < 16; t++) {
-    W[t]  = ((uint32_t)context->Message_Block[t * 4]) << 24;
-    W[t] |= ((uint32_t)context->Message_Block[t * 4 + 1]) << 16;
-    W[t] |= ((uint32_t)context->Message_Block[t * 4 + 2]) << 8;
-    W[t] |= ((uint32_t)context->Message_Block[t * 4 + 3]);
-  }
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 31]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  for (t = 16; t < 80; t++)
-    W[t] = SHA1_ROTL(1, W[t-3] ^ W[t-8] ^ W[t-14] ^ W[t-16]);
-
-  A = context->Intermediate_Hash[0];
-  B = context->Intermediate_Hash[1];
-  C = context->Intermediate_Hash[2];
-  D = context->Intermediate_Hash[3];
-  E = context->Intermediate_Hash[4];
-
-  for (t = 0; t < 20; t++) {
-    temp = SHA1_ROTL(5,A) + SHA_Ch(B, C, D) + E + W[t] + K[0];
-    E = D;
-    D = C;
-    C = SHA1_ROTL(30,B);
-    B = A;
-    A = temp;
-  }
-
-  for (t = 20; t < 40; t++) {
-    temp = SHA1_ROTL(5,A) + SHA_Parity(B, C, D) + E + W[t] + K[1];
-    E = D;
-    D = C;
-    C = SHA1_ROTL(30,B);
-    B = A;
-    A = temp;
-  }
-
-  for (t = 40; t < 60; t++) {
-    temp = SHA1_ROTL(5,A) + SHA_Maj(B, C, D) + E + W[t] + K[2];
-    E = D;
-    D = C;
-    C = SHA1_ROTL(30,B);
-    B = A;
-    A = temp;
-  }
-
-  for (t = 60; t < 80; t++) {
-    temp = SHA1_ROTL(5,A) + SHA_Parity(B, C, D) + E + W[t] + K[3];
-    E = D;
-    D = C;
-    C = SHA1_ROTL(30,B);
-    B = A;
-    A = temp;
-  }
-
-  context->Intermediate_Hash[0] += A;
-  context->Intermediate_Hash[1] += B;
-  context->Intermediate_Hash[2] += C;
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 32]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  context->Intermediate_Hash[3] += D;
-  context->Intermediate_Hash[4] += E;
-
-  context->Message_Block_Index = 0;
-}
-
-8.2.2.  sha224-256.c
-
-/*************************** sha224-256.c ***************************/
-/********************* See RFC 4634 for details *********************/
-/*
- * Description:
- *   This file implements the Secure Hash Signature Standard
- *   algorithms as defined in the National Institute of Standards
- *   and Technology Federal Information Processing Standards
- *   Publication (FIPS PUB) 180-1 published on April 17, 1995, 180-2
- *   published on August 1, 2002, and the FIPS PUB 180-2 Change
- *   Notice published on February 28, 2004.
- *
- *   A combined document showing all algorithms is available at
- *       http://csrc.nist.gov/publications/fips/
- *       fips180-2/fips180-2withchangenotice.pdf
- *
- *   The SHA-224 and SHA-256 algorithms produce 224-bit and 256-bit
- *   message digests for a given data stream. It should take about
- *   2**n steps to find a message with the same digest as a given
- *   message and 2**(n/2) to find any two messages with the same
- *   digest, when n is the digest size in bits. Therefore, this
- *   algorithm can serve as a means of providing a
- *   "fingerprint" for a message.
- *
- * Portability Issues:
- *   SHA-224 and SHA-256 are defined in terms of 32-bit "words".
- *   This code uses <stdint.h> (included via "sha.h") to define 32
- *   and 8 bit unsigned integer types. If your C compiler does not
- *   support 32 bit unsigned integers, this code is not
- *   appropriate.
- *
- * Caveats:
- *   SHA-224 and SHA-256 are designed to work with messages less
- *   than 2^64 bits long. This implementation uses SHA224/256Input()
- *   to hash the bits that are a multiple of the size of an 8-bit
- *   character, and then uses SHA224/256FinalBits() to hash the
- *   final few bits of the input.
- */
-
-#include "sha.h"
-#include "sha-private.h"
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 33]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-/* Define the SHA shift, rotate left and rotate right macro */
-#define SHA256_SHR(bits,word)      ((word) >> (bits))
-#define SHA256_ROTL(bits,word)                         \
-  (((word) << (bits)) | ((word) >> (32-(bits))))
-#define SHA256_ROTR(bits,word)                         \
-  (((word) >> (bits)) | ((word) << (32-(bits))))
-
-/* Define the SHA SIGMA and sigma macros */
-#define SHA256_SIGMA0(word)   \
-  (SHA256_ROTR( 2,word) ^ SHA256_ROTR(13,word) ^ SHA256_ROTR(22,word))
-#define SHA256_SIGMA1(word)   \
-  (SHA256_ROTR( 6,word) ^ SHA256_ROTR(11,word) ^ SHA256_ROTR(25,word))
-#define SHA256_sigma0(word)   \
-  (SHA256_ROTR( 7,word) ^ SHA256_ROTR(18,word) ^ SHA256_SHR( 3,word))
-#define SHA256_sigma1(word)   \
-  (SHA256_ROTR(17,word) ^ SHA256_ROTR(19,word) ^ SHA256_SHR(10,word))
-
-/*
- * add "length" to the length
- */
-static uint32_t addTemp;
-#define SHA224_256AddLength(context, length)               \
-  (addTemp = (context)->Length_Low, (context)->Corrupted = \
-    (((context)->Length_Low += (length)) < addTemp) &&     \
-    (++(context)->Length_High == 0) ? 1 : 0)
-
-/* Local Function Prototypes */
-static void SHA224_256Finalize(SHA256Context *context,
-  uint8_t Pad_Byte);
-static void SHA224_256PadMessage(SHA256Context *context,
-  uint8_t Pad_Byte);
-static void SHA224_256ProcessMessageBlock(SHA256Context *context);
-static int SHA224_256Reset(SHA256Context *context, uint32_t *H0);
-static int SHA224_256ResultN(SHA256Context *context,
-  uint8_t Message_Digest[], int HashSize);
-
-/* Initial Hash Values: FIPS-180-2 Change Notice 1 */
-static uint32_t SHA224_H0[SHA256HashSize/4] = {
-    0xC1059ED8, 0x367CD507, 0x3070DD17, 0xF70E5939,
-    0xFFC00B31, 0x68581511, 0x64F98FA7, 0xBEFA4FA4
-};
-
-/* Initial Hash Values: FIPS-180-2 section 5.3.2 */
-static uint32_t SHA256_H0[SHA256HashSize/4] = {
-  0x6A09E667, 0xBB67AE85, 0x3C6EF372, 0xA54FF53A,
-  0x510E527F, 0x9B05688C, 0x1F83D9AB, 0x5BE0CD19
-};
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 34]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-/*
- * SHA224Reset
- *
- * Description:
- *   This function will initialize the SHA384Context in preparation
- *   for computing a new SHA224 message digest.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to reset.
- *
- * Returns:
- *   sha Error Code.
- */
-int SHA224Reset(SHA224Context *context)
-{
-  return SHA224_256Reset(context, SHA224_H0);
-}
-
-/*
- * SHA224Input
- *
- * Description:
- *   This function accepts an array of octets as the next portion
- *   of the message.
- *
- * Parameters:
- *   context: [in/out]
- *     The SHA context to update
- *   message_array: [in]
- *     An array of characters representing the next portion of
- *     the message.
- *   length: [in]
- *     The length of the message in message_array
- *
- * Returns:
- *   sha Error Code.
- *
- */
-int SHA224Input(SHA224Context *context, const uint8_t *message_array,
-    unsigned int length)
-{
-  return SHA256Input(context, message_array, length);
-}
-
-/*
- * SHA224FinalBits
- *
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 35]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- * Description:
- *   This function will add in any final bits of the message.
- *
- * Parameters:
- *   context: [in/out]
- *     The SHA context to update
- *   message_bits: [in]
- *     The final bits of the message, in the upper portion of the
- *     byte. (Use 0b###00000 instead of 0b00000### to input the
- *     three bits ###.)
- *   length: [in]
- *     The number of bits in message_bits, between 1 and 7.
- *
- * Returns:
- *   sha Error Code.
- */
-int SHA224FinalBits( SHA224Context *context,
-    const uint8_t message_bits, unsigned int length)
-{
-  return SHA256FinalBits(context, message_bits, length);
-}
-
-/*
- * SHA224Result
- *
- * Description:
- *   This function will return the 224-bit message
- *   digest into the Message_Digest array provided by the caller.
- *   NOTE: The first octet of hash is stored in the 0th element,
- *      the last octet of hash in the 28th element.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to use to calculate the SHA hash.
- *   Message_Digest: [out]
- *     Where the digest is returned.
- *
- * Returns:
- *   sha Error Code.
- */
-int SHA224Result(SHA224Context *context,
-    uint8_t Message_Digest[SHA224HashSize])
-{
-  return SHA224_256ResultN(context, Message_Digest, SHA224HashSize);
-}
-
-/*
- * SHA256Reset
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 36]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- *
- * Description:
- *   This function will initialize the SHA256Context in preparation
- *   for computing a new SHA256 message digest.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to reset.
- *
- * Returns:
- *   sha Error Code.
- */
-int SHA256Reset(SHA256Context *context)
-{
-  return SHA224_256Reset(context, SHA256_H0);
-}
-
-/*
- * SHA256Input
- *
- * Description:
- *   This function accepts an array of octets as the next portion
- *   of the message.
- *
- * Parameters:
- *   context: [in/out]
- *     The SHA context to update
- *   message_array: [in]
- *     An array of characters representing the next portion of
- *     the message.
- *   length: [in]
- *     The length of the message in message_array
- *
- * Returns:
- *   sha Error Code.
- */
-int SHA256Input(SHA256Context *context, const uint8_t *message_array,
-    unsigned int length)
-{
-  if (!length)
-    return shaSuccess;
-
-  if (!context || !message_array)
-    return shaNull;
-
-  if (context->Computed) {
-    context->Corrupted = shaStateError;
-    return shaStateError;
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 37]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  }
-
-  if (context->Corrupted)
-     return context->Corrupted;
-
-  while (length-- && !context->Corrupted) {
-    context->Message_Block[context->Message_Block_Index++] =
-            (*message_array & 0xFF);
-
-    if (!SHA224_256AddLength(context, 8) &&
-      (context->Message_Block_Index == SHA256_Message_Block_Size))
-      SHA224_256ProcessMessageBlock(context);
-
-    message_array++;
-  }
-
-  return shaSuccess;
-
-}
-
-/*
- * SHA256FinalBits
- *
- * Description:
- *   This function will add in any final bits of the message.
- *
- * Parameters:
- *   context: [in/out]
- *     The SHA context to update
- *   message_bits: [in]
- *     The final bits of the message, in the upper portion of the
- *     byte. (Use 0b###00000 instead of 0b00000### to input the
- *     three bits ###.)
- *   length: [in]
- *     The number of bits in message_bits, between 1 and 7.
- *
- * Returns:
- *   sha Error Code.
- */
-int SHA256FinalBits(SHA256Context *context,
-    const uint8_t message_bits, unsigned int length)
-{
-  uint8_t masks[8] = {
-      /* 0 0b00000000 */ 0x00, /* 1 0b10000000 */ 0x80,
-      /* 2 0b11000000 */ 0xC0, /* 3 0b11100000 */ 0xE0,
-      /* 4 0b11110000 */ 0xF0, /* 5 0b11111000 */ 0xF8,
-      /* 6 0b11111100 */ 0xFC, /* 7 0b11111110 */ 0xFE
-  };
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 38]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  uint8_t markbit[8] = {
-      /* 0 0b10000000 */ 0x80, /* 1 0b01000000 */ 0x40,
-      /* 2 0b00100000 */ 0x20, /* 3 0b00010000 */ 0x10,
-      /* 4 0b00001000 */ 0x08, /* 5 0b00000100 */ 0x04,
-      /* 6 0b00000010 */ 0x02, /* 7 0b00000001 */ 0x01
-  };
-
-  if (!length)
-    return shaSuccess;
-
-  if (!context)
-    return shaNull;
-
-  if ((context->Computed) || (length >= 8) || (length == 0)) {
-    context->Corrupted = shaStateError;
-    return shaStateError;
-  }
-
-  if (context->Corrupted)
-    return context->Corrupted;
-
-  SHA224_256AddLength(context, length);
-  SHA224_256Finalize(context, (uint8_t)
-    ((message_bits & masks[length]) | markbit[length]));
-
-  return shaSuccess;
-}
-
-/*
- * SHA256Result
- *
- * Description:
- *   This function will return the 256-bit message
- *   digest into the Message_Digest array provided by the caller.
- *   NOTE: The first octet of hash is stored in the 0th element,
- *      the last octet of hash in the 32nd element.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to use to calculate the SHA hash.
- *   Message_Digest: [out]
- *     Where the digest is returned.
- *
- * Returns:
- *   sha Error Code.
- */
-int SHA256Result(SHA256Context *context, uint8_t Message_Digest[])
-{
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 39]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  return SHA224_256ResultN(context, Message_Digest, SHA256HashSize);
-}
-
-/*
- * SHA224_256Finalize
- *
- * Description:
- *   This helper function finishes off the digest calculations.
- *
- * Parameters:
- *   context: [in/out]
- *     The SHA context to update
- *   Pad_Byte: [in]
- *     The last byte to add to the digest before the 0-padding
- *     and length. This will contain the last bits of the message
- *     followed by another single bit. If the message was an
- *     exact multiple of 8-bits long, Pad_Byte will be 0x80.
- *
- * Returns:
- *   sha Error Code.
- */
-static void SHA224_256Finalize(SHA256Context *context,
-    uint8_t Pad_Byte)
-{
-  int i;
-  SHA224_256PadMessage(context, Pad_Byte);
-  /* message may be sensitive, so clear it out */
-  for (i = 0; i < SHA256_Message_Block_Size; ++i)
-    context->Message_Block[i] = 0;
-  context->Length_Low = 0;  /* and clear length */
-  context->Length_High = 0;
-  context->Computed = 1;
-}
-
-/*
- * SHA224_256PadMessage
- *
- * Description:
- *   According to the standard, the message must be padded to an
- *   even 512 bits. The first padding bit must be a '1'. The
- *   last 64 bits represent the length of the original message.
- *   All bits in between should be 0. This helper function will pad
- *   the message according to those rules by filling the
- *   Message_Block array accordingly. When it returns, it can be
- *   assumed that the message digest has been computed.
- *
- * Parameters:
- *   context: [in/out]
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 40]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- *     The context to pad
- *   Pad_Byte: [in]
- *     The last byte to add to the digest before the 0-padding
- *     and length. This will contain the last bits of the message
- *     followed by another single bit. If the message was an
- *     exact multiple of 8-bits long, Pad_Byte will be 0x80.
- *
- * Returns:
- *   Nothing.
- */
-static void SHA224_256PadMessage(SHA256Context *context,
-    uint8_t Pad_Byte)
-{
-  /*
-   * Check to see if the current message block is too small to hold
-   * the initial padding bits and length. If so, we will pad the
-   * block, process it, and then continue padding into a second
-   * block.
-   */
-  if (context->Message_Block_Index >= (SHA256_Message_Block_Size-8)) {
-    context->Message_Block[context->Message_Block_Index++] = Pad_Byte;
-    while (context->Message_Block_Index < SHA256_Message_Block_Size)
-      context->Message_Block[context->Message_Block_Index++] = 0;
-    SHA224_256ProcessMessageBlock(context);
-  } else
-    context->Message_Block[context->Message_Block_Index++] = Pad_Byte;
-
-  while (context->Message_Block_Index < (SHA256_Message_Block_Size-8))
-    context->Message_Block[context->Message_Block_Index++] = 0;
-
-  /*
-   * Store the message length as the last 8 octets
-   */
-  context->Message_Block[56] = (uint8_t)(context->Length_High >> 24);
-  context->Message_Block[57] = (uint8_t)(context->Length_High >> 16);
-  context->Message_Block[58] = (uint8_t)(context->Length_High >> 8);
-  context->Message_Block[59] = (uint8_t)(context->Length_High);
-  context->Message_Block[60] = (uint8_t)(context->Length_Low >> 24);
-  context->Message_Block[61] = (uint8_t)(context->Length_Low >> 16);
-  context->Message_Block[62] = (uint8_t)(context->Length_Low >> 8);
-  context->Message_Block[63] = (uint8_t)(context->Length_Low);
-
-  SHA224_256ProcessMessageBlock(context);
-}
-
-/*
- * SHA224_256ProcessMessageBlock
- *
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 41]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- * Description:
- *   This function will process the next 512 bits of the message
- *   stored in the Message_Block array.
- *
- * Parameters:
- *   context: [in/out]
- *     The SHA context to update
- *
- * Returns:
- *   Nothing.
- *
- * Comments:
- *   Many of the variable names in this code, especially the
- *   single character names, were used because those were the
- *   names used in the publication.
- */
-static void SHA224_256ProcessMessageBlock(SHA256Context *context)
-{
-  /* Constants defined in FIPS-180-2, section 4.2.2 */
-  static const uint32_t K[64] = {
-      0x428a2f98, 0x71374491, 0xb5c0fbcf, 0xe9b5dba5, 0x3956c25b,
-      0x59f111f1, 0x923f82a4, 0xab1c5ed5, 0xd807aa98, 0x12835b01,
-      0x243185be, 0x550c7dc3, 0x72be5d74, 0x80deb1fe, 0x9bdc06a7,
-      0xc19bf174, 0xe49b69c1, 0xefbe4786, 0x0fc19dc6, 0x240ca1cc,
-      0x2de92c6f, 0x4a7484aa, 0x5cb0a9dc, 0x76f988da, 0x983e5152,
-      0xa831c66d, 0xb00327c8, 0xbf597fc7, 0xc6e00bf3, 0xd5a79147,
-      0x06ca6351, 0x14292967, 0x27b70a85, 0x2e1b2138, 0x4d2c6dfc,
-      0x53380d13, 0x650a7354, 0x766a0abb, 0x81c2c92e, 0x92722c85,
-      0xa2bfe8a1, 0xa81a664b, 0xc24b8b70, 0xc76c51a3, 0xd192e819,
-      0xd6990624, 0xf40e3585, 0x106aa070, 0x19a4c116, 0x1e376c08,
-      0x2748774c, 0x34b0bcb5, 0x391c0cb3, 0x4ed8aa4a, 0x5b9cca4f,
-      0x682e6ff3, 0x748f82ee, 0x78a5636f, 0x84c87814, 0x8cc70208,
-      0x90befffa, 0xa4506ceb, 0xbef9a3f7, 0xc67178f2
-  };
-  int        t, t4;                   /* Loop counter */
-  uint32_t   temp1, temp2;            /* Temporary word value */
-  uint32_t   W[64];                   /* Word sequence */
-  uint32_t   A, B, C, D, E, F, G, H;  /* Word buffers */
-
-  /*
-   * Initialize the first 16 words in the array W
-   */
-  for (t = t4 = 0; t < 16; t++, t4 += 4)
-    W[t] = (((uint32_t)context->Message_Block[t4]) << 24) |
-           (((uint32_t)context->Message_Block[t4 + 1]) << 16) |
-           (((uint32_t)context->Message_Block[t4 + 2]) << 8) |
-           (((uint32_t)context->Message_Block[t4 + 3]));
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 42]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  for (t = 16; t < 64; t++)
-    W[t] = SHA256_sigma1(W[t-2]) + W[t-7] +
-        SHA256_sigma0(W[t-15]) + W[t-16];
-
-  A = context->Intermediate_Hash[0];
-  B = context->Intermediate_Hash[1];
-  C = context->Intermediate_Hash[2];
-  D = context->Intermediate_Hash[3];
-  E = context->Intermediate_Hash[4];
-  F = context->Intermediate_Hash[5];
-  G = context->Intermediate_Hash[6];
-  H = context->Intermediate_Hash[7];
-
-  for (t = 0; t < 64; t++) {
-    temp1 = H + SHA256_SIGMA1(E) + SHA_Ch(E,F,G) + K[t] + W[t];
-    temp2 = SHA256_SIGMA0(A) + SHA_Maj(A,B,C);
-    H = G;
-    G = F;
-    F = E;
-    E = D + temp1;
-    D = C;
-    C = B;
-    B = A;
-    A = temp1 + temp2;
-  }
-
-  context->Intermediate_Hash[0] += A;
-  context->Intermediate_Hash[1] += B;
-  context->Intermediate_Hash[2] += C;
-  context->Intermediate_Hash[3] += D;
-  context->Intermediate_Hash[4] += E;
-  context->Intermediate_Hash[5] += F;
-  context->Intermediate_Hash[6] += G;
-  context->Intermediate_Hash[7] += H;
-
-  context->Message_Block_Index = 0;
-}
-
-/*
- * SHA224_256Reset
- *
- * Description:
- *   This helper function will initialize the SHA256Context in
- *   preparation for computing a new SHA256 message digest.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to reset.
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 43]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- *   H0
- *     The initial hash value to use.
- *
- * Returns:
- *   sha Error Code.
- */
-static int SHA224_256Reset(SHA256Context *context, uint32_t *H0)
-{
-  if (!context)
-    return shaNull;
-
-  context->Length_Low           = 0;
-  context->Length_High          = 0;
-  context->Message_Block_Index  = 0;
-
-  context->Intermediate_Hash[0] = H0[0];
-  context->Intermediate_Hash[1] = H0[1];
-  context->Intermediate_Hash[2] = H0[2];
-  context->Intermediate_Hash[3] = H0[3];
-  context->Intermediate_Hash[4] = H0[4];
-  context->Intermediate_Hash[5] = H0[5];
-  context->Intermediate_Hash[6] = H0[6];
-  context->Intermediate_Hash[7] = H0[7];
-
-  context->Computed  = 0;
-  context->Corrupted = 0;
-
-  return shaSuccess;
-}
-
-/*
- * SHA224_256ResultN
- *
- * Description:
- *   This helper function will return the 224-bit or 256-bit message
- *   digest into the Message_Digest array provided by the caller.
- *   NOTE: The first octet of hash is stored in the 0th element,
- *      the last octet of hash in the 28th/32nd element.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to use to calculate the SHA hash.
- *   Message_Digest: [out]
- *     Where the digest is returned.
- *   HashSize: [in]
- *     The size of the hash, either 28 or 32.
- *
- * Returns:
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 44]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- *   sha Error Code.
- */
-static int SHA224_256ResultN(SHA256Context *context,
-    uint8_t Message_Digest[], int HashSize)
-{
-  int i;
-
-  if (!context || !Message_Digest)
-    return shaNull;
-
-  if (context->Corrupted)
-    return context->Corrupted;
-
-  if (!context->Computed)
-    SHA224_256Finalize(context, 0x80);
-
-  for (i = 0; i < HashSize; ++i)
-    Message_Digest[i] = (uint8_t)
-      (context->Intermediate_Hash[i>>2] >> 8 * ( 3 - ( i & 0x03 ) ));
-
-  return shaSuccess;
-}
-
-8.2.3.  sha384-512.c
-
-/*************************** sha384-512.c ***************************/
-/********************* See RFC 4634 for details *********************/
-/*
- * Description:
- *   This file implements the Secure Hash Signature Standard
- *   algorithms as defined in the National Institute of Standards
- *   and Technology Federal Information Processing Standards
- *   Publication (FIPS PUB) 180-1 published on April 17, 1995, 180-2
- *   published on August 1, 2002, and the FIPS PUB 180-2 Change
- *   Notice published on February 28, 2004.
- *
- *   A combined document showing all algorithms is available at
- *       http://csrc.nist.gov/publications/fips/
- *       fips180-2/fips180-2withchangenotice.pdf
- *
- *   The SHA-384 and SHA-512 algorithms produce 384-bit and 512-bit
- *   message digests for a given data stream. It should take about
- *   2**n steps to find a message with the same digest as a given
- *   message and 2**(n/2) to find any two messages with the same
- *   digest, when n is the digest size in bits. Therefore, this
- *   algorithm can serve as a means of providing a
- *   "fingerprint" for a message.
- *
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 45]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- * Portability Issues:
- *   SHA-384 and SHA-512 are defined in terms of 64-bit "words",
- *   but if USE_32BIT_ONLY is #defined, this code is implemented in
- *   terms of 32-bit "words". This code uses <stdint.h> (included
- *   via "sha.h") to define the 64, 32 and 8 bit unsigned integer
- *   types. If your C compiler does not support 64 bit unsigned
- *   integers, and you do not #define USE_32BIT_ONLY, this code is
- *   not appropriate.
- *
- * Caveats:
- *   SHA-384 and SHA-512 are designed to work with messages less
- *   than 2^128 bits long. This implementation uses
- *   SHA384/512Input() to hash the bits that are a multiple of the
- *   size of an 8-bit character, and then uses SHA384/256FinalBits()
- *   to hash the final few bits of the input.
- *
- */
-
-#include "sha.h"
-#include "sha-private.h"
-
-#ifdef USE_32BIT_ONLY
-/*
- * Define 64-bit arithmetic in terms of 32-bit arithmetic.
- * Each 64-bit number is represented in a 2-word array.
- * All macros are defined such that the result is the last parameter.
- */
-
-/*
- * Define shift, rotate left and rotate right functions
- */
-#define SHA512_SHR(bits, word, ret) (                          \
-    /* (((uint64_t)((word))) >> (bits)) */                     \
-    (ret)[0] = (((bits) < 32) && ((bits) >= 0)) ?              \
-      ((word)[0] >> (bits)) : 0,                               \
-    (ret)[1] = ((bits) > 32) ? ((word)[0] >> ((bits) - 32)) :  \
-      ((bits) == 32) ? (word)[0] :                             \
-      ((bits) >= 0) ?                                          \
-        (((word)[0] << (32 - (bits))) |                        \
-        ((word)[1] >> (bits))) : 0 )
-
-#define SHA512_SHL(bits, word, ret) (                          \
-    /* (((uint64_t)(word)) << (bits)) */                       \
-    (ret)[0] = ((bits) > 32) ? ((word)[1] << ((bits) - 32)) :  \
-         ((bits) == 32) ? (word)[1] :                          \
-         ((bits) >= 0) ?                                       \
-           (((word)[0] << (bits)) |                            \
-           ((word)[1] >> (32 - (bits)))) :                     \
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 46]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-         0,                                                    \
-    (ret)[1] = (((bits) < 32) && ((bits) >= 0)) ?              \
-        ((word)[1] << (bits)) : 0 )
-
-/*
- * Define 64-bit OR
- */
-#define SHA512_OR(word1, word2, ret) (                         \
-    (ret)[0] = (word1)[0] | (word2)[0],                        \
-    (ret)[1] = (word1)[1] | (word2)[1] )
-
-/*
- * Define 64-bit XOR
- */
-#define SHA512_XOR(word1, word2, ret) (                        \
-    (ret)[0] = (word1)[0] ^ (word2)[0],                        \
-    (ret)[1] = (word1)[1] ^ (word2)[1] )
-
-/*
- * Define 64-bit AND
- */
-#define SHA512_AND(word1, word2, ret) (                        \
-    (ret)[0] = (word1)[0] & (word2)[0],                        \
-    (ret)[1] = (word1)[1] & (word2)[1] )
-
-/*
- * Define 64-bit TILDA
- */
-#define SHA512_TILDA(word, ret)                                \
-  ( (ret)[0] = ~(word)[0], (ret)[1] = ~(word)[1] )
-
-/*
- * Define 64-bit ADD
- */
-#define SHA512_ADD(word1, word2, ret) (                        \
-    (ret)[1] = (word1)[1], (ret)[1] += (word2)[1],             \
-    (ret)[0] = (word1)[0] + (word2)[0] + ((ret)[1] < (word1)[1]) )
-
-/*
- * Add the 4word value in word2 to word1.
- */
-static uint32_t ADDTO4_temp, ADDTO4_temp2;
-#define SHA512_ADDTO4(word1, word2) (                          \
-    ADDTO4_temp = (word1)[3],                                  \
-    (word1)[3] += (word2)[3],                                  \
-    ADDTO4_temp2 = (word1)[2],                                 \
-    (word1)[2] += (word2)[2] + ((word1)[3] < ADDTO4_temp),     \
-    ADDTO4_temp = (word1)[1],                                  \
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 47]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-    (word1)[1] += (word2)[1] + ((word1)[2] < ADDTO4_temp2),    \
-    (word1)[0] += (word2)[0] + ((word1)[1] < ADDTO4_temp) )
-
-/*
- * Add the 2word value in word2 to word1.
- */
-static uint32_t ADDTO2_temp;
-#define SHA512_ADDTO2(word1, word2) (                          \
-    ADDTO2_temp = (word1)[1],                                  \
-    (word1)[1] += (word2)[1],                                  \
-    (word1)[0] += (word2)[0] + ((word1)[1] < ADDTO2_temp) )
-
-/*
- * SHA rotate   ((word >> bits) | (word << (64-bits)))
- */
-static uint32_t ROTR_temp1[2], ROTR_temp2[2];
-#define SHA512_ROTR(bits, word, ret) (                         \
-    SHA512_SHR((bits), (word), ROTR_temp1),                    \
-    SHA512_SHL(64-(bits), (word), ROTR_temp2),                 \
-    SHA512_OR(ROTR_temp1, ROTR_temp2, (ret)) )
-
-/*
- * Define the SHA SIGMA and sigma macros
- *  SHA512_ROTR(28,word) ^ SHA512_ROTR(34,word) ^ SHA512_ROTR(39,word)
- */
-static uint32_t SIGMA0_temp1[2], SIGMA0_temp2[2],
-  SIGMA0_temp3[2], SIGMA0_temp4[2];
-#define SHA512_SIGMA0(word, ret) (                             \
-    SHA512_ROTR(28, (word), SIGMA0_temp1),                     \
-    SHA512_ROTR(34, (word), SIGMA0_temp2),                     \
-    SHA512_ROTR(39, (word), SIGMA0_temp3),                     \
-    SHA512_XOR(SIGMA0_temp2, SIGMA0_temp3, SIGMA0_temp4),      \
-    SHA512_XOR(SIGMA0_temp1, SIGMA0_temp4, (ret)) )
-
-/*
- * SHA512_ROTR(14,word) ^ SHA512_ROTR(18,word) ^ SHA512_ROTR(41,word)
- */
-static uint32_t SIGMA1_temp1[2], SIGMA1_temp2[2],
-  SIGMA1_temp3[2], SIGMA1_temp4[2];
-#define SHA512_SIGMA1(word, ret) (                             \
-    SHA512_ROTR(14, (word), SIGMA1_temp1),                     \
-    SHA512_ROTR(18, (word), SIGMA1_temp2),                     \
-    SHA512_ROTR(41, (word), SIGMA1_temp3),                     \
-    SHA512_XOR(SIGMA1_temp2, SIGMA1_temp3, SIGMA1_temp4),      \
-    SHA512_XOR(SIGMA1_temp1, SIGMA1_temp4, (ret)) )
-
-/*
- * (SHA512_ROTR( 1,word) ^ SHA512_ROTR( 8,word) ^ SHA512_SHR( 7,word))
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 48]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- */
-static uint32_t sigma0_temp1[2], sigma0_temp2[2],
-  sigma0_temp3[2], sigma0_temp4[2];
-#define SHA512_sigma0(word, ret) (                             \
-    SHA512_ROTR( 1, (word), sigma0_temp1),                     \
-    SHA512_ROTR( 8, (word), sigma0_temp2),                     \
-    SHA512_SHR( 7, (word), sigma0_temp3),                      \
-    SHA512_XOR(sigma0_temp2, sigma0_temp3, sigma0_temp4),      \
-    SHA512_XOR(sigma0_temp1, sigma0_temp4, (ret)) )
-
-/*
- * (SHA512_ROTR(19,word) ^ SHA512_ROTR(61,word) ^ SHA512_SHR( 6,word))
- */
-static uint32_t sigma1_temp1[2], sigma1_temp2[2],
-  sigma1_temp3[2], sigma1_temp4[2];
-#define SHA512_sigma1(word, ret) (                             \
-    SHA512_ROTR(19, (word), sigma1_temp1),                     \
-    SHA512_ROTR(61, (word), sigma1_temp2),                     \
-    SHA512_SHR( 6, (word), sigma1_temp3),                      \
-    SHA512_XOR(sigma1_temp2, sigma1_temp3, sigma1_temp4),      \
-    SHA512_XOR(sigma1_temp1, sigma1_temp4, (ret)) )
-
-#undef SHA_Ch
-#undef SHA_Maj
-
-#ifndef USE_MODIFIED_MACROS
-/*
- * These definitions are the ones used in FIPS-180-2, section 4.1.3
- *  Ch(x,y,z)   ((x & y) ^ (~x & z))
- */
-static uint32_t Ch_temp1[2], Ch_temp2[2], Ch_temp3[2];
-#define SHA_Ch(x, y, z, ret) (                                 \
-    SHA512_AND(x, y, Ch_temp1),                                \
-    SHA512_TILDA(x, Ch_temp2),                                 \
-    SHA512_AND(Ch_temp2, z, Ch_temp3),                         \
-    SHA512_XOR(Ch_temp1, Ch_temp3, (ret)) )
-/*
- *  Maj(x,y,z)  (((x)&(y)) ^ ((x)&(z)) ^ ((y)&(z)))
- */
-static uint32_t Maj_temp1[2], Maj_temp2[2],
-  Maj_temp3[2], Maj_temp4[2];
-#define SHA_Maj(x, y, z, ret) (                                \
-    SHA512_AND(x, y, Maj_temp1),                               \
-    SHA512_AND(x, z, Maj_temp2),                               \
-    SHA512_AND(y, z, Maj_temp3),                               \
-    SHA512_XOR(Maj_temp2, Maj_temp3, Maj_temp4),               \
-    SHA512_XOR(Maj_temp1, Maj_temp4, (ret)) )
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 49]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-#else /* !USE_32BIT_ONLY */
-/*
- * These definitions are potentially faster equivalents for the ones
- * used in FIPS-180-2, section 4.1.3.
- *   ((x & y) ^ (~x & z)) becomes
- *   ((x & (y ^ z)) ^ z)
- */
-#define SHA_Ch(x, y, z, ret) (                                 \
-   (ret)[0] = (((x)[0] & ((y)[0] ^ (z)[0])) ^ (z)[0]),         \
-   (ret)[1] = (((x)[1] & ((y)[1] ^ (z)[1])) ^ (z)[1]) )
-
-/*
- *   ((x & y) ^ (x & z) ^ (y & z)) becomes
- *   ((x & (y | z)) | (y & z))
- */
-#define SHA_Maj(x, y, z, ret) (                                 \
-   ret[0] = (((x)[0] & ((y)[0] | (z)[0])) | ((y)[0] & (z)[0])), \
-   ret[1] = (((x)[1] & ((y)[1] | (z)[1])) | ((y)[1] & (z)[1])) )
-#endif /* USE_MODIFIED_MACROS */
-
-/*
- * add "length" to the length
- */
-static uint32_t addTemp[4] = { 0, 0, 0, 0 };
-#define SHA384_512AddLength(context, length) (                        \
-    addTemp[3] = (length), SHA512_ADDTO4((context)->Length, addTemp), \
-    (context)->Corrupted = (((context)->Length[3] == 0) &&            \
-       ((context)->Length[2] == 0) && ((context)->Length[1] == 0) &&  \
-       ((context)->Length[0] < 8)) ? 1 : 0 )
-
-/* Local Function Prototypes */
-static void SHA384_512Finalize(SHA512Context *context,
-  uint8_t Pad_Byte);
-static void SHA384_512PadMessage(SHA512Context *context,
-  uint8_t Pad_Byte);
-static void SHA384_512ProcessMessageBlock(SHA512Context *context);
-static int SHA384_512Reset(SHA512Context *context, uint32_t H0[]);
-static int SHA384_512ResultN( SHA512Context *context,
-  uint8_t Message_Digest[], int HashSize);
-
-/* Initial Hash Values: FIPS-180-2 sections 5.3.3 and 5.3.4 */
-static uint32_t SHA384_H0[SHA512HashSize/4] = {
-    0xCBBB9D5D, 0xC1059ED8, 0x629A292A, 0x367CD507, 0x9159015A,
-    0x3070DD17, 0x152FECD8, 0xF70E5939, 0x67332667, 0xFFC00B31,
-    0x8EB44A87, 0x68581511, 0xDB0C2E0D, 0x64F98FA7, 0x47B5481D,
-    0xBEFA4FA4
-};
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 50]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-static uint32_t SHA512_H0[SHA512HashSize/4] = {
-    0x6A09E667, 0xF3BCC908, 0xBB67AE85, 0x84CAA73B, 0x3C6EF372,
-    0xFE94F82B, 0xA54FF53A, 0x5F1D36F1, 0x510E527F, 0xADE682D1,
-    0x9B05688C, 0x2B3E6C1F, 0x1F83D9AB, 0xFB41BD6B, 0x5BE0CD19,
-    0x137E2179
-};
-
-#else /* !USE_32BIT_ONLY */
-
-/* Define the SHA shift, rotate left and rotate right macro */
-#define SHA512_SHR(bits,word)  (((uint64_t)(word)) >> (bits))
-#define SHA512_ROTR(bits,word) ((((uint64_t)(word)) >> (bits)) | \
-                                (((uint64_t)(word)) << (64-(bits))))
-
-/* Define the SHA SIGMA and sigma macros */
-#define SHA512_SIGMA0(word)   \
- (SHA512_ROTR(28,word) ^ SHA512_ROTR(34,word) ^ SHA512_ROTR(39,word))
-#define SHA512_SIGMA1(word)   \
- (SHA512_ROTR(14,word) ^ SHA512_ROTR(18,word) ^ SHA512_ROTR(41,word))
-#define SHA512_sigma0(word)   \
- (SHA512_ROTR( 1,word) ^ SHA512_ROTR( 8,word) ^ SHA512_SHR( 7,word))
-#define SHA512_sigma1(word)   \
- (SHA512_ROTR(19,word) ^ SHA512_ROTR(61,word) ^ SHA512_SHR( 6,word))
-
-/*
- * add "length" to the length
- */
-static uint64_t addTemp;
-#define SHA384_512AddLength(context, length)                   \
-   (addTemp = context->Length_Low, context->Corrupted =        \
-    ((context->Length_Low += length) < addTemp) &&             \
-    (++context->Length_High == 0) ? 1 : 0)
-
-/* Local Function Prototypes */
-static void SHA384_512Finalize(SHA512Context *context,
-  uint8_t Pad_Byte);
-static void SHA384_512PadMessage(SHA512Context *context,
-  uint8_t Pad_Byte);
-static void SHA384_512ProcessMessageBlock(SHA512Context *context);
-static int SHA384_512Reset(SHA512Context *context, uint64_t H0[]);
-static int SHA384_512ResultN(SHA512Context *context,
-  uint8_t Message_Digest[], int HashSize);
-
-/* Initial Hash Values: FIPS-180-2 sections 5.3.3 and 5.3.4 */
-static uint64_t SHA384_H0[] = {
-    0xCBBB9D5DC1059ED8ll, 0x629A292A367CD507ll, 0x9159015A3070DD17ll,
-    0x152FECD8F70E5939ll, 0x67332667FFC00B31ll, 0x8EB44A8768581511ll,
-    0xDB0C2E0D64F98FA7ll, 0x47B5481DBEFA4FA4ll
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 51]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-};
-static uint64_t SHA512_H0[] = {
-    0x6A09E667F3BCC908ll, 0xBB67AE8584CAA73Bll, 0x3C6EF372FE94F82Bll,
-    0xA54FF53A5F1D36F1ll, 0x510E527FADE682D1ll, 0x9B05688C2B3E6C1Fll,
-    0x1F83D9ABFB41BD6Bll, 0x5BE0CD19137E2179ll
-};
-
-#endif /* USE_32BIT_ONLY */
-
-/*
- * SHA384Reset
- *
- * Description:
- *   This function will initialize the SHA384Context in preparation
- *   for computing a new SHA384 message digest.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to reset.
- *
- * Returns:
- *   sha Error Code.
- *
- */
-int SHA384Reset(SHA384Context *context)
-{
-  return SHA384_512Reset(context, SHA384_H0);
-}
-
-/*
- * SHA384Input
- *
- * Description:
- *   This function accepts an array of octets as the next portion
- *   of the message.
- *
- * Parameters:
- *   context: [in/out]
- *     The SHA context to update
- *   message_array: [in]
- *     An array of characters representing the next portion of
- *     the message.
- *   length: [in]
- *     The length of the message in message_array
- *
- * Returns:
- *   sha Error Code.
- *
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 52]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- */
-int SHA384Input(SHA384Context *context,
-    const uint8_t *message_array, unsigned int length)
-{
-  return SHA512Input(context, message_array, length);
-}
-
-/*
- * SHA384FinalBits
- *
- * Description:
- *   This function will add in any final bits of the message.
- *
- * Parameters:
- *   context: [in/out]
- *     The SHA context to update
- *   message_bits: [in]
- *     The final bits of the message, in the upper portion of the
- *     byte. (Use 0b###00000 instead of 0b00000### to input the
- *     three bits ###.)
- *   length: [in]
- *     The number of bits in message_bits, between 1 and 7.
- *
- * Returns:
- *   sha Error Code.
- *
- */
-int SHA384FinalBits(SHA384Context *context,
-    const uint8_t message_bits, unsigned int length)
-{
-  return SHA512FinalBits(context, message_bits, length);
-}
-
-/*
- * SHA384Result
- *
- * Description:
- *   This function will return the 384-bit message
- *   digest into the Message_Digest array provided by the caller.
- *   NOTE: The first octet of hash is stored in the 0th element,
- *      the last octet of hash in the 48th element.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to use to calculate the SHA hash.
- *   Message_Digest: [out]
- *     Where the digest is returned.
- *
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 53]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- * Returns:
- *   sha Error Code.
- *
- */
-int SHA384Result(SHA384Context *context,
-    uint8_t Message_Digest[SHA384HashSize])
-{
-  return SHA384_512ResultN(context, Message_Digest, SHA384HashSize);
-}
-
-/*
- * SHA512Reset
- *
- * Description:
- *   This function will initialize the SHA512Context in preparation
- *   for computing a new SHA512 message digest.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to reset.
- *
- * Returns:
- *   sha Error Code.
- *
- */
-int SHA512Reset(SHA512Context *context)
-{
-  return SHA384_512Reset(context, SHA512_H0);
-}
-
-/*
- * SHA512Input
- *
- * Description:
- *   This function accepts an array of octets as the next portion
- *   of the message.
- *
- * Parameters:
- *   context: [in/out]
- *     The SHA context to update
- *   message_array: [in]
- *     An array of characters representing the next portion of
- *     the message.
- *   length: [in]
- *     The length of the message in message_array
- *
- * Returns:
- *   sha Error Code.
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 54]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- *
- */
-int SHA512Input(SHA512Context *context,
-        const uint8_t *message_array,
-        unsigned int length)
-{
-  if (!length)
-    return shaSuccess;
-
-  if (!context || !message_array)
-    return shaNull;
-
-  if (context->Computed) {
-    context->Corrupted = shaStateError;
-    return shaStateError;
-  }
-
-  if (context->Corrupted)
-     return context->Corrupted;
-
-  while (length-- && !context->Corrupted) {
-    context->Message_Block[context->Message_Block_Index++] =
-            (*message_array & 0xFF);
-
-    if (!SHA384_512AddLength(context, 8) &&
-      (context->Message_Block_Index == SHA512_Message_Block_Size))
-      SHA384_512ProcessMessageBlock(context);
-
-    message_array++;
-  }
-
-  return shaSuccess;
-}
-
-/*
- * SHA512FinalBits
- *
- * Description:
- *   This function will add in any final bits of the message.
- *
- * Parameters:
- *   context: [in/out]
- *     The SHA context to update
- *   message_bits: [in]
- *     The final bits of the message, in the upper portion of the
- *     byte. (Use 0b###00000 instead of 0b00000### to input the
- *     three bits ###.)
- *   length: [in]
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 55]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- *     The number of bits in message_bits, between 1 and 7.
- *
- * Returns:
- *   sha Error Code.
- *
- */
-int SHA512FinalBits(SHA512Context *context,
-    const uint8_t message_bits, unsigned int length)
-{
-  uint8_t masks[8] = {
-      /* 0 0b00000000 */ 0x00, /* 1 0b10000000 */ 0x80,
-      /* 2 0b11000000 */ 0xC0, /* 3 0b11100000 */ 0xE0,
-      /* 4 0b11110000 */ 0xF0, /* 5 0b11111000 */ 0xF8,
-      /* 6 0b11111100 */ 0xFC, /* 7 0b11111110 */ 0xFE
-  };
-  uint8_t markbit[8] = {
-      /* 0 0b10000000 */ 0x80, /* 1 0b01000000 */ 0x40,
-      /* 2 0b00100000 */ 0x20, /* 3 0b00010000 */ 0x10,
-      /* 4 0b00001000 */ 0x08, /* 5 0b00000100 */ 0x04,
-      /* 6 0b00000010 */ 0x02, /* 7 0b00000001 */ 0x01
-  };
-
-  if (!length)
-    return shaSuccess;
-
-  if (!context)
-    return shaNull;
-
-  if ((context->Computed) || (length >= 8) || (length == 0)) {
-    context->Corrupted = shaStateError;
-    return shaStateError;
-  }
-
-  if (context->Corrupted)
-     return context->Corrupted;
-
-  SHA384_512AddLength(context, length);
-  SHA384_512Finalize(context, (uint8_t)
-    ((message_bits & masks[length]) | markbit[length]));
-
-  return shaSuccess;
-}
-
-/*
- * SHA384_512Finalize
- *
- * Description:
- *   This helper function finishes off the digest calculations.
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 56]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- *
- * Parameters:
- *   context: [in/out]
- *     The SHA context to update
- *   Pad_Byte: [in]
- *     The last byte to add to the digest before the 0-padding
- *     and length. This will contain the last bits of the message
- *     followed by another single bit. If the message was an
- *     exact multiple of 8-bits long, Pad_Byte will be 0x80.
- *
- * Returns:
- *   sha Error Code.
- *
- */
-static void SHA384_512Finalize(SHA512Context *context,
-    uint8_t Pad_Byte)
-{
-  int_least16_t i;
-  SHA384_512PadMessage(context, Pad_Byte);
-  /* message may be sensitive, clear it out */
-  for (i = 0; i < SHA512_Message_Block_Size; ++i)
-    context->Message_Block[i] = 0;
-#ifdef USE_32BIT_ONLY    /* and clear length */
-  context->Length[0] = context->Length[1] = 0;
-  context->Length[2] = context->Length[3] = 0;
-#else /* !USE_32BIT_ONLY */
-  context->Length_Low = 0;
-  context->Length_High = 0;
-#endif /* USE_32BIT_ONLY */
-  context->Computed = 1;
-}
-
-/*
- * SHA512Result
- *
- * Description:
- *   This function will return the 512-bit message
- *   digest into the Message_Digest array provided by the caller.
- *   NOTE: The first octet of hash is stored in the 0th element,
- *      the last octet of hash in the 64th element.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to use to calculate the SHA hash.
- *   Message_Digest: [out]
- *     Where the digest is returned.
- *
- * Returns:
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 57]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- *   sha Error Code.
- *
- */
-int SHA512Result(SHA512Context *context,
-    uint8_t Message_Digest[SHA512HashSize])
-{
-  return SHA384_512ResultN(context, Message_Digest, SHA512HashSize);
-}
-
-/*
- * SHA384_512PadMessage
- *
- * Description:
- *   According to the standard, the message must be padded to an
- *   even 1024 bits. The first padding bit must be a '1'. The
- *   last 128 bits represent the length of the original message.
- *   All bits in between should be 0. This helper function will
- *   pad the message according to those rules by filling the
- *   Message_Block array accordingly. When it returns, it can be
- *   assumed that the message digest has been computed.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to pad
- *   Pad_Byte: [in]
- *     The last byte to add to the digest before the 0-padding
- *     and length. This will contain the last bits of the message
- *     followed by another single bit. If the message was an
- *     exact multiple of 8-bits long, Pad_Byte will be 0x80.
- *
- * Returns:
- *   Nothing.
- *
- */
-static void SHA384_512PadMessage(SHA512Context *context,
-    uint8_t Pad_Byte)
-{
-  /*
-   * Check to see if the current message block is too small to hold
-   * the initial padding bits and length. If so, we will pad the
-   * block, process it, and then continue padding into a second
-   * block.
-   */
-  if (context->Message_Block_Index >= (SHA512_Message_Block_Size-16)) {
-    context->Message_Block[context->Message_Block_Index++] = Pad_Byte;
-    while (context->Message_Block_Index < SHA512_Message_Block_Size)
-      context->Message_Block[context->Message_Block_Index++] = 0;
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 58]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-    SHA384_512ProcessMessageBlock(context);
-  } else
-    context->Message_Block[context->Message_Block_Index++] = Pad_Byte;
-
-  while (context->Message_Block_Index < (SHA512_Message_Block_Size-16))
-    context->Message_Block[context->Message_Block_Index++] = 0;
-
-  /*
-   * Store the message length as the last 16 octets
-   */
-#ifdef USE_32BIT_ONLY
-  context->Message_Block[112] = (uint8_t)(context->Length[0] >> 24);
-  context->Message_Block[113] = (uint8_t)(context->Length[0] >> 16);
-  context->Message_Block[114] = (uint8_t)(context->Length[0] >> 8);
-  context->Message_Block[115] = (uint8_t)(context->Length[0]);
-  context->Message_Block[116] = (uint8_t)(context->Length[1] >> 24);
-  context->Message_Block[117] = (uint8_t)(context->Length[1] >> 16);
-  context->Message_Block[118] = (uint8_t)(context->Length[1] >> 8);
-  context->Message_Block[119] = (uint8_t)(context->Length[1]);
-
-  context->Message_Block[120] = (uint8_t)(context->Length[2] >> 24);
-  context->Message_Block[121] = (uint8_t)(context->Length[2] >> 16);
-  context->Message_Block[122] = (uint8_t)(context->Length[2] >> 8);
-  context->Message_Block[123] = (uint8_t)(context->Length[2]);
-  context->Message_Block[124] = (uint8_t)(context->Length[3] >> 24);
-  context->Message_Block[125] = (uint8_t)(context->Length[3] >> 16);
-  context->Message_Block[126] = (uint8_t)(context->Length[3] >> 8);
-  context->Message_Block[127] = (uint8_t)(context->Length[3]);
-#else /* !USE_32BIT_ONLY */
-  context->Message_Block[112] = (uint8_t)(context->Length_High >> 56);
-  context->Message_Block[113] = (uint8_t)(context->Length_High >> 48);
-  context->Message_Block[114] = (uint8_t)(context->Length_High >> 40);
-  context->Message_Block[115] = (uint8_t)(context->Length_High >> 32);
-  context->Message_Block[116] = (uint8_t)(context->Length_High >> 24);
-  context->Message_Block[117] = (uint8_t)(context->Length_High >> 16);
-  context->Message_Block[118] = (uint8_t)(context->Length_High >> 8);
-  context->Message_Block[119] = (uint8_t)(context->Length_High);
-
-  context->Message_Block[120] = (uint8_t)(context->Length_Low >> 56);
-  context->Message_Block[121] = (uint8_t)(context->Length_Low >> 48);
-  context->Message_Block[122] = (uint8_t)(context->Length_Low >> 40);
-  context->Message_Block[123] = (uint8_t)(context->Length_Low >> 32);
-  context->Message_Block[124] = (uint8_t)(context->Length_Low >> 24);
-  context->Message_Block[125] = (uint8_t)(context->Length_Low >> 16);
-  context->Message_Block[126] = (uint8_t)(context->Length_Low >> 8);
-  context->Message_Block[127] = (uint8_t)(context->Length_Low);
-#endif /* USE_32BIT_ONLY */
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 59]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  SHA384_512ProcessMessageBlock(context);
-}
-
-/*
- * SHA384_512ProcessMessageBlock
- *
- * Description:
- *   This helper function will process the next 1024 bits of the
- *   message stored in the Message_Block array.
- *
- * Parameters:
- *   context: [in/out]
- *     The SHA context to update
- *
- * Returns:
- *   Nothing.
- *
- * Comments:
- *   Many of the variable names in this code, especially the
- *   single character names, were used because those were the
- *   names used in the publication.
- *
- *
- */
-static void SHA384_512ProcessMessageBlock(SHA512Context *context)
-{
-  /* Constants defined in FIPS-180-2, section 4.2.3 */
-#ifdef USE_32BIT_ONLY
-  static const uint32_t K[80*2] = {
-      0x428A2F98, 0xD728AE22, 0x71374491, 0x23EF65CD, 0xB5C0FBCF,
-      0xEC4D3B2F, 0xE9B5DBA5, 0x8189DBBC, 0x3956C25B, 0xF348B538,
-      0x59F111F1, 0xB605D019, 0x923F82A4, 0xAF194F9B, 0xAB1C5ED5,
-      0xDA6D8118, 0xD807AA98, 0xA3030242, 0x12835B01, 0x45706FBE,
-      0x243185BE, 0x4EE4B28C, 0x550C7DC3, 0xD5FFB4E2, 0x72BE5D74,
-      0xF27B896F, 0x80DEB1FE, 0x3B1696B1, 0x9BDC06A7, 0x25C71235,
-      0xC19BF174, 0xCF692694, 0xE49B69C1, 0x9EF14AD2, 0xEFBE4786,
-      0x384F25E3, 0x0FC19DC6, 0x8B8CD5B5, 0x240CA1CC, 0x77AC9C65,
-      0x2DE92C6F, 0x592B0275, 0x4A7484AA, 0x6EA6E483, 0x5CB0A9DC,
-      0xBD41FBD4, 0x76F988DA, 0x831153B5, 0x983E5152, 0xEE66DFAB,
-      0xA831C66D, 0x2DB43210, 0xB00327C8, 0x98FB213F, 0xBF597FC7,
-      0xBEEF0EE4, 0xC6E00BF3, 0x3DA88FC2, 0xD5A79147, 0x930AA725,
-      0x06CA6351, 0xE003826F, 0x14292967, 0x0A0E6E70, 0x27B70A85,
-      0x46D22FFC, 0x2E1B2138, 0x5C26C926, 0x4D2C6DFC, 0x5AC42AED,
-      0x53380D13, 0x9D95B3DF, 0x650A7354, 0x8BAF63DE, 0x766A0ABB,
-      0x3C77B2A8, 0x81C2C92E, 0x47EDAEE6, 0x92722C85, 0x1482353B,
-      0xA2BFE8A1, 0x4CF10364, 0xA81A664B, 0xBC423001, 0xC24B8B70,
-      0xD0F89791, 0xC76C51A3, 0x0654BE30, 0xD192E819, 0xD6EF5218,
-      0xD6990624, 0x5565A910, 0xF40E3585, 0x5771202A, 0x106AA070,
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 60]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-      0x32BBD1B8, 0x19A4C116, 0xB8D2D0C8, 0x1E376C08, 0x5141AB53,
-      0x2748774C, 0xDF8EEB99, 0x34B0BCB5, 0xE19B48A8, 0x391C0CB3,
-      0xC5C95A63, 0x4ED8AA4A, 0xE3418ACB, 0x5B9CCA4F, 0x7763E373,
-      0x682E6FF3, 0xD6B2B8A3, 0x748F82EE, 0x5DEFB2FC, 0x78A5636F,
-      0x43172F60, 0x84C87814, 0xA1F0AB72, 0x8CC70208, 0x1A6439EC,
-      0x90BEFFFA, 0x23631E28, 0xA4506CEB, 0xDE82BDE9, 0xBEF9A3F7,
-      0xB2C67915, 0xC67178F2, 0xE372532B, 0xCA273ECE, 0xEA26619C,
-      0xD186B8C7, 0x21C0C207, 0xEADA7DD6, 0xCDE0EB1E, 0xF57D4F7F,
-      0xEE6ED178, 0x06F067AA, 0x72176FBA, 0x0A637DC5, 0xA2C898A6,
-      0x113F9804, 0xBEF90DAE, 0x1B710B35, 0x131C471B, 0x28DB77F5,
-      0x23047D84, 0x32CAAB7B, 0x40C72493, 0x3C9EBE0A, 0x15C9BEBC,
-      0x431D67C4, 0x9C100D4C, 0x4CC5D4BE, 0xCB3E42B6, 0x597F299C,
-      0xFC657E2A, 0x5FCB6FAB, 0x3AD6FAEC, 0x6C44198C, 0x4A475817
-  };
-  int     t, t2, t8;                  /* Loop counter */
-  uint32_t  temp1[2], temp2[2],       /* Temporary word values */
-        temp3[2], temp4[2], temp5[2];
-  uint32_t  W[2*80];                  /* Word sequence */
-  uint32_t  A[2], B[2], C[2], D[2],   /* Word buffers */
-        E[2], F[2], G[2], H[2];
-
-  /* Initialize the first 16 words in the array W */
-  for (t = t2 = t8 = 0; t < 16; t++, t8 += 8) {
-    W[t2++] = ((((uint32_t)context->Message_Block[t8    ])) << 24) |
-              ((((uint32_t)context->Message_Block[t8 + 1])) << 16) |
-              ((((uint32_t)context->Message_Block[t8 + 2])) << 8) |
-              ((((uint32_t)context->Message_Block[t8 + 3])));
-    W[t2++] = ((((uint32_t)context->Message_Block[t8 + 4])) << 24) |
-              ((((uint32_t)context->Message_Block[t8 + 5])) << 16) |
-              ((((uint32_t)context->Message_Block[t8 + 6])) << 8) |
-              ((((uint32_t)context->Message_Block[t8 + 7])));
-  }
-
-  for (t = 16; t < 80; t++, t2 += 2) {
-    /* W[t] = SHA512_sigma1(W[t-2]) + W[t-7] +
-      SHA512_sigma0(W[t-15]) + W[t-16]; */
-    uint32_t *Wt2 = &W[t2-2*2];
-    uint32_t *Wt7 = &W[t2-7*2];
-    uint32_t *Wt15 = &W[t2-15*2];
-    uint32_t *Wt16 = &W[t2-16*2];
-    SHA512_sigma1(Wt2, temp1);
-    SHA512_ADD(temp1, Wt7, temp2);
-    SHA512_sigma0(Wt15, temp1);
-    SHA512_ADD(temp1, Wt16, temp3);
-    SHA512_ADD(temp2, temp3, &W[t2]);
-  }
-
-  A[0] = context->Intermediate_Hash[0];
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 61]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  A[1] = context->Intermediate_Hash[1];
-  B[0] = context->Intermediate_Hash[2];
-  B[1] = context->Intermediate_Hash[3];
-  C[0] = context->Intermediate_Hash[4];
-  C[1] = context->Intermediate_Hash[5];
-  D[0] = context->Intermediate_Hash[6];
-  D[1] = context->Intermediate_Hash[7];
-  E[0] = context->Intermediate_Hash[8];
-  E[1] = context->Intermediate_Hash[9];
-  F[0] = context->Intermediate_Hash[10];
-  F[1] = context->Intermediate_Hash[11];
-  G[0] = context->Intermediate_Hash[12];
-  G[1] = context->Intermediate_Hash[13];
-  H[0] = context->Intermediate_Hash[14];
-  H[1] = context->Intermediate_Hash[15];
-
-  for (t = t2 = 0; t < 80; t++, t2 += 2) {
-    /*
-     * temp1 = H + SHA512_SIGMA1(E) + SHA_Ch(E,F,G) + K[t] + W[t];
-     */
-    SHA512_SIGMA1(E,temp1);
-    SHA512_ADD(H, temp1, temp2);
-    SHA_Ch(E,F,G,temp3);
-    SHA512_ADD(temp2, temp3, temp4);
-    SHA512_ADD(&K[t2], &W[t2], temp5);
-    SHA512_ADD(temp4, temp5, temp1);
-    /*
-     * temp2 = SHA512_SIGMA0(A) + SHA_Maj(A,B,C);
-     */
-    SHA512_SIGMA0(A,temp3);
-    SHA_Maj(A,B,C,temp4);
-    SHA512_ADD(temp3, temp4, temp2);
-    H[0] = G[0]; H[1] = G[1];
-    G[0] = F[0]; G[1] = F[1];
-    F[0] = E[0]; F[1] = E[1];
-    SHA512_ADD(D, temp1, E);
-    D[0] = C[0]; D[1] = C[1];
-    C[0] = B[0]; C[1] = B[1];
-    B[0] = A[0]; B[1] = A[1];
-    SHA512_ADD(temp1, temp2, A);
-  }
-
-  SHA512_ADDTO2(&context->Intermediate_Hash[0], A);
-  SHA512_ADDTO2(&context->Intermediate_Hash[2], B);
-  SHA512_ADDTO2(&context->Intermediate_Hash[4], C);
-  SHA512_ADDTO2(&context->Intermediate_Hash[6], D);
-  SHA512_ADDTO2(&context->Intermediate_Hash[8], E);
-  SHA512_ADDTO2(&context->Intermediate_Hash[10], F);
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 62]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  SHA512_ADDTO2(&context->Intermediate_Hash[12], G);
-  SHA512_ADDTO2(&context->Intermediate_Hash[14], H);
-
-#else /* !USE_32BIT_ONLY */
-  static const uint64_t K[80] = {
-      0x428A2F98D728AE22ll, 0x7137449123EF65CDll, 0xB5C0FBCFEC4D3B2Fll,
-      0xE9B5DBA58189DBBCll, 0x3956C25BF348B538ll, 0x59F111F1B605D019ll,
-      0x923F82A4AF194F9Bll, 0xAB1C5ED5DA6D8118ll, 0xD807AA98A3030242ll,
-      0x12835B0145706FBEll, 0x243185BE4EE4B28Cll, 0x550C7DC3D5FFB4E2ll,
-      0x72BE5D74F27B896Fll, 0x80DEB1FE3B1696B1ll, 0x9BDC06A725C71235ll,
-      0xC19BF174CF692694ll, 0xE49B69C19EF14AD2ll, 0xEFBE4786384F25E3ll,
-      0x0FC19DC68B8CD5B5ll, 0x240CA1CC77AC9C65ll, 0x2DE92C6F592B0275ll,
-      0x4A7484AA6EA6E483ll, 0x5CB0A9DCBD41FBD4ll, 0x76F988DA831153B5ll,
-      0x983E5152EE66DFABll, 0xA831C66D2DB43210ll, 0xB00327C898FB213Fll,
-      0xBF597FC7BEEF0EE4ll, 0xC6E00BF33DA88FC2ll, 0xD5A79147930AA725ll,
-      0x06CA6351E003826Fll, 0x142929670A0E6E70ll, 0x27B70A8546D22FFCll,
-      0x2E1B21385C26C926ll, 0x4D2C6DFC5AC42AEDll, 0x53380D139D95B3DFll,
-      0x650A73548BAF63DEll, 0x766A0ABB3C77B2A8ll, 0x81C2C92E47EDAEE6ll,
-      0x92722C851482353Bll, 0xA2BFE8A14CF10364ll, 0xA81A664BBC423001ll,
-      0xC24B8B70D0F89791ll, 0xC76C51A30654BE30ll, 0xD192E819D6EF5218ll,
-      0xD69906245565A910ll, 0xF40E35855771202All, 0x106AA07032BBD1B8ll,
-      0x19A4C116B8D2D0C8ll, 0x1E376C085141AB53ll, 0x2748774CDF8EEB99ll,
-      0x34B0BCB5E19B48A8ll, 0x391C0CB3C5C95A63ll, 0x4ED8AA4AE3418ACBll,
-      0x5B9CCA4F7763E373ll, 0x682E6FF3D6B2B8A3ll, 0x748F82EE5DEFB2FCll,
-      0x78A5636F43172F60ll, 0x84C87814A1F0AB72ll, 0x8CC702081A6439ECll,
-      0x90BEFFFA23631E28ll, 0xA4506CEBDE82BDE9ll, 0xBEF9A3F7B2C67915ll,
-      0xC67178F2E372532Bll, 0xCA273ECEEA26619Cll, 0xD186B8C721C0C207ll,
-      0xEADA7DD6CDE0EB1Ell, 0xF57D4F7FEE6ED178ll, 0x06F067AA72176FBAll,
-      0x0A637DC5A2C898A6ll, 0x113F9804BEF90DAEll, 0x1B710B35131C471Bll,
-      0x28DB77F523047D84ll, 0x32CAAB7B40C72493ll, 0x3C9EBE0A15C9BEBCll,
-      0x431D67C49C100D4Cll, 0x4CC5D4BECB3E42B6ll, 0x597F299CFC657E2All,
-      0x5FCB6FAB3AD6FAECll, 0x6C44198C4A475817ll
-  };
-  int        t, t8;                   /* Loop counter */
-  uint64_t   temp1, temp2;            /* Temporary word value */
-  uint64_t   W[80];                   /* Word sequence */
-  uint64_t   A, B, C, D, E, F, G, H;  /* Word buffers */
-
-  /*
-   * Initialize the first 16 words in the array W
-   */
-  for (t = t8 = 0; t < 16; t++, t8 += 8)
-    W[t] = ((uint64_t)(context->Message_Block[t8  ]) << 56) |
-           ((uint64_t)(context->Message_Block[t8 + 1]) << 48) |
-           ((uint64_t)(context->Message_Block[t8 + 2]) << 40) |
-           ((uint64_t)(context->Message_Block[t8 + 3]) << 32) |
-           ((uint64_t)(context->Message_Block[t8 + 4]) << 24) |
-           ((uint64_t)(context->Message_Block[t8 + 5]) << 16) |
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 63]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-           ((uint64_t)(context->Message_Block[t8 + 6]) << 8) |
-           ((uint64_t)(context->Message_Block[t8 + 7]));
-
-  for (t = 16; t < 80; t++)
-    W[t] = SHA512_sigma1(W[t-2]) + W[t-7] +
-        SHA512_sigma0(W[t-15]) + W[t-16];
-
-  A = context->Intermediate_Hash[0];
-  B = context->Intermediate_Hash[1];
-  C = context->Intermediate_Hash[2];
-  D = context->Intermediate_Hash[3];
-  E = context->Intermediate_Hash[4];
-  F = context->Intermediate_Hash[5];
-  G = context->Intermediate_Hash[6];
-  H = context->Intermediate_Hash[7];
-
-  for (t = 0; t < 80; t++) {
-    temp1 = H + SHA512_SIGMA1(E) + SHA_Ch(E,F,G) + K[t] + W[t];
-    temp2 = SHA512_SIGMA0(A) + SHA_Maj(A,B,C);
-    H = G;
-    G = F;
-    F = E;
-    E = D + temp1;
-    D = C;
-    C = B;
-    B = A;
-    A = temp1 + temp2;
-  }
-
-  context->Intermediate_Hash[0] += A;
-  context->Intermediate_Hash[1] += B;
-  context->Intermediate_Hash[2] += C;
-  context->Intermediate_Hash[3] += D;
-  context->Intermediate_Hash[4] += E;
-  context->Intermediate_Hash[5] += F;
-  context->Intermediate_Hash[6] += G;
-  context->Intermediate_Hash[7] += H;
-#endif /* USE_32BIT_ONLY */
-
-  context->Message_Block_Index = 0;
-}
-
-/*
- * SHA384_512Reset
- *
- * Description:
- *   This helper function will initialize the SHA512Context in
- *   preparation for computing a new SHA384 or SHA512 message
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 64]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- *   digest.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to reset.
- *   H0
- *     The initial hash value to use.
- *
- * Returns:
- *   sha Error Code.
- *
- */
-#ifdef USE_32BIT_ONLY
-static int SHA384_512Reset(SHA512Context *context, uint32_t H0[])
-#else /* !USE_32BIT_ONLY */
-static int SHA384_512Reset(SHA512Context *context, uint64_t H0[])
-#endif /* USE_32BIT_ONLY */
-{
-  int i;
-  if (!context)
-    return shaNull;
-
-  context->Message_Block_Index = 0;
-
-#ifdef USE_32BIT_ONLY
-  context->Length[0] = context->Length[1] = 0;
-  context->Length[2] = context->Length[3] = 0;
-
-  for (i = 0; i < SHA512HashSize/4; i++)
-    context->Intermediate_Hash[i] = H0[i];
-#else /* !USE_32BIT_ONLY */
-  context->Length_High = context->Length_Low = 0;
-
-  for (i = 0; i < SHA512HashSize/8; i++)
-    context->Intermediate_Hash[i] = H0[i];
-#endif /* USE_32BIT_ONLY */
-
-  context->Computed = 0;
-  context->Corrupted = 0;
-
-  return shaSuccess;
-}
-
-/*
- * SHA384_512ResultN
- *
- * Description:
- *   This helper function will return the 384-bit or 512-bit message
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 65]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- *   digest into the Message_Digest array provided by the caller.
- *   NOTE: The first octet of hash is stored in the 0th element,
- *      the last octet of hash in the 48th/64th element.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to use to calculate the SHA hash.
- *   Message_Digest: [out]
- *     Where the digest is returned.
- *   HashSize: [in]
- *     The size of the hash, either 48 or 64.
- *
- * Returns:
- *   sha Error Code.
- *
- */
-static int SHA384_512ResultN(SHA512Context *context,
-    uint8_t Message_Digest[], int HashSize)
-{
-  int i;
-
-#ifdef USE_32BIT_ONLY
-  int i2;
-#endif /* USE_32BIT_ONLY */
-
-  if (!context || !Message_Digest)
-    return shaNull;
-
-  if (context->Corrupted)
-    return context->Corrupted;
-
-  if (!context->Computed)
-    SHA384_512Finalize(context, 0x80);
-
-#ifdef USE_32BIT_ONLY
-  for (i = i2 = 0; i < HashSize; ) {
-    Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2]>>24);
-    Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2]>>16);
-    Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2]>>8);
-    Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2++]);
-    Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2]>>24);
-    Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2]>>16);
-    Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2]>>8);
-    Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2++]);
-  }
-#else /* !USE_32BIT_ONLY */
-  for (i = 0; i < HashSize; ++i)
-    Message_Digest[i] = (uint8_t)
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 66]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-      (context->Intermediate_Hash[i>>3] >> 8 * ( 7 - ( i % 8 ) ));
-#endif /* USE_32BIT_ONLY */
-
-  return shaSuccess;
-}
-
-8.2.4.  usha.c
-
-/**************************** usha.c ****************************/
-/******************** See RFC 4634 for details ******************/
-/*
- *  Description:
- *     This file implements a unified interface to the SHA algorithms.
- */
-
-#include "sha.h"
-
-/*
- *  USHAReset
- *
- *  Description:
- *      This function will initialize the SHA Context in preparation
- *      for computing a new SHA message digest.
- *
- *  Parameters:
- *      context: [in/out]
- *          The context to reset.
- *      whichSha: [in]
- *          Selects which SHA reset to call
- *
- *  Returns:
- *      sha Error Code.
- *
- */
-int USHAReset(USHAContext *ctx, enum SHAversion whichSha)
-{
-  if (ctx) {
-    ctx->whichSha = whichSha;
-    switch (whichSha) {
-      case SHA1:   return SHA1Reset((SHA1Context*)&ctx->ctx);
-      case SHA224: return SHA224Reset((SHA224Context*)&ctx->ctx);
-      case SHA256: return SHA256Reset((SHA256Context*)&ctx->ctx);
-      case SHA384: return SHA384Reset((SHA384Context*)&ctx->ctx);
-      case SHA512: return SHA512Reset((SHA512Context*)&ctx->ctx);
-      default: return shaBadParam;
-    }
-  } else {
-    return shaNull;
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 67]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  }
-}
-
-/*
- *  USHAInput
- *
- *  Description:
- *      This function accepts an array of octets as the next portion
- *      of the message.
- *
- *  Parameters:
- *      context: [in/out]
- *          The SHA context to update
- *      message_array: [in]
- *          An array of characters representing the next portion of
- *          the message.
- *      length: [in]
- *          The length of the message in message_array
- *
- *  Returns:
- *      sha Error Code.
- *
- */
-int USHAInput(USHAContext *ctx,
-              const uint8_t *bytes, unsigned int bytecount)
-{
-  if (ctx) {
-    switch (ctx->whichSha) {
-      case SHA1:
-        return SHA1Input((SHA1Context*)&ctx->ctx, bytes, bytecount);
-      case SHA224:
-        return SHA224Input((SHA224Context*)&ctx->ctx, bytes,
-            bytecount);
-      case SHA256:
-        return SHA256Input((SHA256Context*)&ctx->ctx, bytes,
-            bytecount);
-      case SHA384:
-        return SHA384Input((SHA384Context*)&ctx->ctx, bytes,
-            bytecount);
-      case SHA512:
-        return SHA512Input((SHA512Context*)&ctx->ctx, bytes,
-            bytecount);
-      default: return shaBadParam;
-    }
-  } else {
-    return shaNull;
-  }
-}
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 68]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-/*
- * USHAFinalBits
- *
- * Description:
- *   This function will add in any final bits of the message.
- *
- * Parameters:
- *   context: [in/out]
- *     The SHA context to update
- *   message_bits: [in]
- *     The final bits of the message, in the upper portion of the
- *     byte. (Use 0b###00000 instead of 0b00000### to input the
- *     three bits ###.)
- *   length: [in]
- *     The number of bits in message_bits, between 1 and 7.
- *
- * Returns:
- *   sha Error Code.
- */
-int USHAFinalBits(USHAContext *ctx,
-                  const uint8_t bits, unsigned int bitcount)
-{
-  if (ctx) {
-    switch (ctx->whichSha) {
-      case SHA1:
-        return SHA1FinalBits((SHA1Context*)&ctx->ctx, bits, bitcount);
-      case SHA224:
-        return SHA224FinalBits((SHA224Context*)&ctx->ctx, bits,
-            bitcount);
-      case SHA256:
-        return SHA256FinalBits((SHA256Context*)&ctx->ctx, bits,
-            bitcount);
-      case SHA384:
-        return SHA384FinalBits((SHA384Context*)&ctx->ctx, bits,
-            bitcount);
-      case SHA512:
-        return SHA512FinalBits((SHA512Context*)&ctx->ctx, bits,
-            bitcount);
-      default: return shaBadParam;
-    }
-  } else {
-    return shaNull;
-  }
-}
-
-/*
- * USHAResult
- *
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 69]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- * Description:
- *   This function will return the 160-bit message digest into the
- *   Message_Digest array provided by the caller.
- *   NOTE: The first octet of hash is stored in the 0th element,
- *      the last octet of hash in the 19th element.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to use to calculate the SHA-1 hash.
- *   Message_Digest: [out]
- *     Where the digest is returned.
- *
- * Returns:
- *   sha Error Code.
- *
- */
-int USHAResult(USHAContext *ctx,
-               uint8_t Message_Digest[USHAMaxHashSize])
-{
-  if (ctx) {
-    switch (ctx->whichSha) {
-      case SHA1:
-        return SHA1Result((SHA1Context*)&ctx->ctx, Message_Digest);
-      case SHA224:
-        return SHA224Result((SHA224Context*)&ctx->ctx, Message_Digest);
-      case SHA256:
-        return SHA256Result((SHA256Context*)&ctx->ctx, Message_Digest);
-      case SHA384:
-        return SHA384Result((SHA384Context*)&ctx->ctx, Message_Digest);
-      case SHA512:
-        return SHA512Result((SHA512Context*)&ctx->ctx, Message_Digest);
-      default: return shaBadParam;
-    }
-  } else {
-    return shaNull;
-  }
-}
-
-/*
- * USHABlockSize
- *
- * Description:
- *   This function will return the blocksize for the given SHA
- *   algorithm.
- *
- * Parameters:
- *   whichSha:
- *     which SHA algorithm to query
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 70]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- *
- * Returns:
- *   block size
- *
- */
-int USHABlockSize(enum SHAversion whichSha)
-{
-  switch (whichSha) {
-    case SHA1:   return SHA1_Message_Block_Size;
-    case SHA224: return SHA224_Message_Block_Size;
-    case SHA256: return SHA256_Message_Block_Size;
-    case SHA384: return SHA384_Message_Block_Size;
-    default:
-    case SHA512: return SHA512_Message_Block_Size;
-  }
-}
-
-/*
- * USHAHashSize
- *
- * Description:
- *   This function will return the hashsize for the given SHA
- *   algorithm.
- *
- * Parameters:
- *   whichSha:
- *     which SHA algorithm to query
- *
- * Returns:
- *   hash size
- *
- */
-int USHAHashSize(enum SHAversion whichSha)
-{
-  switch (whichSha) {
-    case SHA1:   return SHA1HashSize;
-    case SHA224: return SHA224HashSize;
-    case SHA256: return SHA256HashSize;
-    case SHA384: return SHA384HashSize;
-    default:
-    case SHA512: return SHA512HashSize;
-  }
-}
-
-/*
- * USHAHashSizeBits
- *
- * Description:
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 71]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- *   This function will return the hashsize for the given SHA
- *   algorithm, expressed in bits.
- *
- * Parameters:
- *   whichSha:
- *     which SHA algorithm to query
- *
- * Returns:
- *   hash size in bits
- *
- */
-int USHAHashSizeBits(enum SHAversion whichSha)
-{
-  switch (whichSha) {
-    case SHA1:   return SHA1HashSizeBits;
-    case SHA224: return SHA224HashSizeBits;
-    case SHA256: return SHA256HashSizeBits;
-    case SHA384: return SHA384HashSizeBits;
-    default:
-    case SHA512: return SHA512HashSizeBits;
-  }
-}
-
-8.2.5.  sha-private.h
-
-/*************************** sha-private.h ***************************/
-/********************** See RFC 4634 for details *********************/
-#ifndef _SHA_PRIVATE__H
-#define _SHA_PRIVATE__H
-/*
- * These definitions are defined in FIPS-180-2, section 4.1.
- * Ch() and Maj() are defined identically in sections 4.1.1,
- * 4.1.2 and 4.1.3.
- *
- * The definitions used in FIPS-180-2 are as follows:
- */
-
-#ifndef USE_MODIFIED_MACROS
-#define SHA_Ch(x,y,z)        (((x) & (y)) ^ ((~(x)) & (z)))
-#define SHA_Maj(x,y,z)       (((x) & (y)) ^ ((x) & (z)) ^ ((y) & (z)))
-
-#else /* USE_MODIFIED_MACROS */
-/*
- * The following definitions are equivalent and potentially faster.
- */
-
-#define SHA_Ch(x, y, z)      (((x) & ((y) ^ (z))) ^ (z))
-#define SHA_Maj(x, y, z)     (((x) & ((y) | (z))) | ((y) & (z)))
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 72]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-#endif /* USE_MODIFIED_MACROS */
-
-#define SHA_Parity(x, y, z)  ((x) ^ (y) ^ (z))
-
-#endif /* _SHA_PRIVATE__H */
-
-8.3 The HMAC Code
-
-/**************************** hmac.c ****************************/
-/******************** See RFC 4634 for details ******************/
-/*
- *  Description:
- *      This file implements the HMAC algorithm (Keyed-Hashing for
- *      Message Authentication, RFC2104), expressed in terms of the
- *      various SHA algorithms.
- */
-
-#include "sha.h"
-
-/*
- *  hmac
- *
- *  Description:
- *      This function will compute an HMAC message digest.
- *
- *  Parameters:
- *      whichSha: [in]
- *          One of SHA1, SHA224, SHA256, SHA384, SHA512
- *      key: [in]
- *          The secret shared key.
- *      key_len: [in]
- *          The length of the secret shared key.
- *      message_array: [in]
- *          An array of characters representing the message.
- *      length: [in]
- *          The length of the message in message_array
- *      digest: [out]
- *          Where the digest is returned.
- *          NOTE: The length of the digest is determined by
- *              the value of whichSha.
- *
- *  Returns:
- *      sha Error Code.
- *
- */
-int hmac(SHAversion whichSha, const unsigned char *text, int text_len,
-    const unsigned char *key, int key_len,
-    uint8_t digest[USHAMaxHashSize])
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 73]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-{
-  HMACContext ctx;
-  return hmacReset(&ctx, whichSha, key, key_len) ||
-         hmacInput(&ctx, text, text_len) ||
-         hmacResult(&ctx, digest);
-}
-
-/*
- *  hmacReset
- *
- *  Description:
- *      This function will initialize the hmacContext in preparation
- *      for computing a new HMAC message digest.
- *
- *  Parameters:
- *      context: [in/out]
- *          The context to reset.
- *      whichSha: [in]
- *          One of SHA1, SHA224, SHA256, SHA384, SHA512
- *      key: [in]
- *          The secret shared key.
- *      key_len: [in]
- *          The length of the secret shared key.
- *
- *  Returns:
- *      sha Error Code.
- *
- */
-int hmacReset(HMACContext *ctx, enum SHAversion whichSha,
-    const unsigned char *key, int key_len)
-{
-  int i, blocksize, hashsize;
-
-  /* inner padding - key XORd with ipad */
-  unsigned char k_ipad[USHA_Max_Message_Block_Size];
-
-  /* temporary buffer when keylen > blocksize */
-  unsigned char tempkey[USHAMaxHashSize];
-
-  if (!ctx) return shaNull;
-
-  blocksize = ctx->blockSize = USHABlockSize(whichSha);
-  hashsize = ctx->hashSize = USHAHashSize(whichSha);
-
-  ctx->whichSha = whichSha;
-
-  /*
-   * If key is longer than the hash blocksize,
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 74]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-   * reset it to key = HASH(key).
-   */
-  if (key_len > blocksize) {
-    USHAContext tctx;
-    int err = USHAReset(&tctx, whichSha) ||
-              USHAInput(&tctx, key, key_len) ||
-              USHAResult(&tctx, tempkey);
-    if (err != shaSuccess) return err;
-
-    key = tempkey;
-    key_len = hashsize;
-  }
-
-  /*
-   * The HMAC transform looks like:
-   *
-   * SHA(K XOR opad, SHA(K XOR ipad, text))
-   *
-   * where K is an n byte key.
-   * ipad is the byte 0x36 repeated blocksize times
-   * opad is the byte 0x5c repeated blocksize times
-   * and text is the data being protected.
-   */
-
-  /* store key into the pads, XOR'd with ipad and opad values */
-  for (i = 0; i < key_len; i++) {
-    k_ipad[i] = key[i] ^ 0x36;
-    ctx->k_opad[i] = key[i] ^ 0x5c;
-  }
-  /* remaining pad bytes are '\0' XOR'd with ipad and opad values */
-  for ( ; i < blocksize; i++) {
-    k_ipad[i] = 0x36;
-    ctx->k_opad[i] = 0x5c;
-  }
-
-  /* perform inner hash */
-  /* init context for 1st pass */
-  return USHAReset(&ctx->shaContext, whichSha) ||
-         /* and start with inner pad */
-         USHAInput(&ctx->shaContext, k_ipad, blocksize);
-}
-
-/*
- *  hmacInput
- *
- *  Description:
- *      This function accepts an array of octets as the next portion
- *      of the message.
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 75]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- *
- *  Parameters:
- *      context: [in/out]
- *          The HMAC context to update
- *      message_array: [in]
- *          An array of characters representing the next portion of
- *          the message.
- *      length: [in]
- *          The length of the message in message_array
- *
- *  Returns:
- *      sha Error Code.
- *
- */
-int hmacInput(HMACContext *ctx, const unsigned char *text,
-    int text_len)
-{
-  if (!ctx) return shaNull;
-  /* then text of datagram */
-  return USHAInput(&ctx->shaContext, text, text_len);
-}
-
-/*
- * HMACFinalBits
- *
- * Description:
- *   This function will add in any final bits of the message.
- *
- * Parameters:
- *   context: [in/out]
- *     The HMAC context to update
- *   message_bits: [in]
- *     The final bits of the message, in the upper portion of the
- *     byte. (Use 0b###00000 instead of 0b00000### to input the
- *     three bits ###.)
- *   length: [in]
- *     The number of bits in message_bits, between 1 and 7.
- *
- * Returns:
- *   sha Error Code.
- */
-int hmacFinalBits(HMACContext *ctx,
-    const uint8_t bits,
-    unsigned int bitcount)
-{
-  if (!ctx) return shaNull;
-  /* then final bits of datagram */
-  return USHAFinalBits(&ctx->shaContext, bits, bitcount);
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 76]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-}
-
-/*
- * HMACResult
- *
- * Description:
- *   This function will return the N-byte message digest into the
- *   Message_Digest array provided by the caller.
- *   NOTE: The first octet of hash is stored in the 0th element,
- *      the last octet of hash in the Nth element.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to use to calculate the HMAC hash.
- *   digest: [out]
- *     Where the digest is returned.
- *   NOTE 2: The length of the hash is determined by the value of
- *      whichSha that was passed to hmacReset().
- *
- * Returns:
- *   sha Error Code.
- *
- */
-int hmacResult(HMACContext *ctx, uint8_t *digest)
-{
-  if (!ctx) return shaNull;
-
-  /* finish up 1st pass */
-  /* (Use digest here as a temporary buffer.) */
-  return USHAResult(&ctx->shaContext, digest) ||
-
-         /* perform outer SHA */
-         /* init context for 2nd pass */
-         USHAReset(&ctx->shaContext, ctx->whichSha) ||
-
-         /* start with outer pad */
-         USHAInput(&ctx->shaContext, ctx->k_opad, ctx->blockSize) ||
-
-         /* then results of 1st hash */
-         USHAInput(&ctx->shaContext, digest, ctx->hashSize) ||
-
-         /* finish up 2nd pass */
-         USHAResult(&ctx->shaContext, digest);
-}
-
-
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 77]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-8.4.  The Test Driver
-
-   The following code is a main program test driver to exercise the code
-   in sha1.c, sha224-256.c, and sha384-512.c.  The test driver can also
-   be used as a stand-alone program for generating the hashes.
-
-   See also [RFC2202], [RFC4231], and [SHAVS].
-
-/**************************** shatest.c ****************************/
-/********************* See RFC 4634 for details ********************/
-/*
- *  Description:
- *    This file will exercise the SHA code performing
- *      the three tests documented in FIPS PUB 180-2
- *        (http://csrc.nist.gov/publications/fips/
- *         fips180-2/fips180-2withchangenotice.pdf)
- *      one that calls SHAInput with an exact multiple of 512 bits
- *      the seven tests documented for each algorithm in
- *        "The Secure Hash Algorithm Validation System (SHAVS)",
- *        three of which are bit-level tests
- *        (http://csrc.nist.gov/cryptval/shs/SHAVS.pdf)
- *
- *    This file will exercise the HMAC SHA1 code performing
- *      the seven tests documented in RFCs 2202 and 4231.
- *
- *    To run the tests and just see PASSED/FAILED, use the -p option.
- *
- *    Other options exercise:
- *      hashing an arbitrary string
- *      hashing a file's contents
- *      a few error test checks
- *      printing the results in raw format
- *
- *  Portability Issues:
- *    None.
- *
- */
-
-#include <stdint.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#include <ctype.h>
-#include "sha.h"
-
-static int xgetopt(int argc, char **argv, const char *optstring);
-extern char *xoptarg;
-static int scasecmp(const char *s1, const char *s2);
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 78]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-/*
- *  Define patterns for testing
- */
-#define TEST1    "abc"
-#define TEST2_1  \
-        "abcdbcdecdefdefgefghfghighijhijkijkljklmklmnlmnomnopnopq"
-#define TEST2_2a \
-        "abcdefghbcdefghicdefghijdefghijkefghijklfghijklmghijklmn"
-#define TEST2_2b \
-        "hijklmnoijklmnopjklmnopqklmnopqrlmnopqrsmnopqrstnopqrstu"
-#define TEST2_2  TEST2_2a TEST2_2b
-#define TEST3    "a"                            /* times 1000000 */
-#define TEST4a   "01234567012345670123456701234567"
-#define TEST4b   "01234567012345670123456701234567"
-    /* an exact multiple of 512 bits */
-#define TEST4   TEST4a TEST4b                   /* times 10 */
-
-#define TEST7_1 \
-  "\x49\xb2\xae\xc2\x59\x4b\xbe\x3a\x3b\x11\x75\x42\xd9\x4a\xc8"
-#define TEST8_1 \
-  "\x9a\x7d\xfd\xf1\xec\xea\xd0\x6e\xd6\x46\xaa\x55\xfe\x75\x71\x46"
-#define TEST9_1 \
-  "\x65\xf9\x32\x99\x5b\xa4\xce\x2c\xb1\xb4\xa2\xe7\x1a\xe7\x02\x20" \
-  "\xaa\xce\xc8\x96\x2d\xd4\x49\x9c\xbd\x7c\x88\x7a\x94\xea\xaa\x10" \
-  "\x1e\xa5\xaa\xbc\x52\x9b\x4e\x7e\x43\x66\x5a\x5a\xf2\xcd\x03\xfe" \
-  "\x67\x8e\xa6\xa5\x00\x5b\xba\x3b\x08\x22\x04\xc2\x8b\x91\x09\xf4" \
-  "\x69\xda\xc9\x2a\xaa\xb3\xaa\x7c\x11\xa1\xb3\x2a"
-#define TEST10_1 \
-  "\xf7\x8f\x92\x14\x1b\xcd\x17\x0a\xe8\x9b\x4f\xba\x15\xa1\xd5\x9f" \
-  "\x3f\xd8\x4d\x22\x3c\x92\x51\xbd\xac\xbb\xae\x61\xd0\x5e\xd1\x15" \
-  "\xa0\x6a\x7c\xe1\x17\xb7\xbe\xea\xd2\x44\x21\xde\xd9\xc3\x25\x92" \
-  "\xbd\x57\xed\xea\xe3\x9c\x39\xfa\x1f\xe8\x94\x6a\x84\xd0\xcf\x1f" \
-  "\x7b\xee\xad\x17\x13\xe2\xe0\x95\x98\x97\x34\x7f\x67\xc8\x0b\x04" \
-  "\x00\xc2\x09\x81\x5d\x6b\x10\xa6\x83\x83\x6f\xd5\x56\x2a\x56\xca" \
-  "\xb1\xa2\x8e\x81\xb6\x57\x66\x54\x63\x1c\xf1\x65\x66\xb8\x6e\x3b" \
-  "\x33\xa1\x08\xb0\x53\x07\xc0\x0a\xff\x14\xa7\x68\xed\x73\x50\x60" \
-  "\x6a\x0f\x85\xe6\xa9\x1d\x39\x6f\x5b\x5c\xbe\x57\x7f\x9b\x38\x80" \
-  "\x7c\x7d\x52\x3d\x6d\x79\x2f\x6e\xbc\x24\xa4\xec\xf2\xb3\xa4\x27" \
-  "\xcd\xbb\xfb"
-#define TEST7_224 \
-  "\xf0\x70\x06\xf2\x5a\x0b\xea\x68\xcd\x76\xa2\x95\x87\xc2\x8d"
-#define TEST8_224 \
-  "\x18\x80\x40\x05\xdd\x4f\xbd\x15\x56\x29\x9d\x6f\x9d\x93\xdf\x62"
-#define TEST9_224 \
-  "\xa2\xbe\x6e\x46\x32\x81\x09\x02\x94\xd9\xce\x94\x82\x65\x69\x42" \
-  "\x3a\x3a\x30\x5e\xd5\xe2\x11\x6c\xd4\xa4\xc9\x87\xfc\x06\x57\x00" \
-  "\x64\x91\xb1\x49\xcc\xd4\xb5\x11\x30\xac\x62\xb1\x9d\xc2\x48\xc7" \
-  "\x44\x54\x3d\x20\xcd\x39\x52\xdc\xed\x1f\x06\xcc\x3b\x18\xb9\x1f" \
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 79]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  "\x3f\x55\x63\x3e\xcc\x30\x85\xf4\x90\x70\x60\xd2"
-#define TEST10_224 \
-  "\x55\xb2\x10\x07\x9c\x61\xb5\x3a\xdd\x52\x06\x22\xd1\xac\x97\xd5" \
-  "\xcd\xbe\x8c\xb3\x3a\xa0\xae\x34\x45\x17\xbe\xe4\xd7\xba\x09\xab" \
-  "\xc8\x53\x3c\x52\x50\x88\x7a\x43\xbe\xbb\xac\x90\x6c\x2e\x18\x37" \
-  "\xf2\x6b\x36\xa5\x9a\xe3\xbe\x78\x14\xd5\x06\x89\x6b\x71\x8b\x2a" \
-  "\x38\x3e\xcd\xac\x16\xb9\x61\x25\x55\x3f\x41\x6f\xf3\x2c\x66\x74" \
-  "\xc7\x45\x99\xa9\x00\x53\x86\xd9\xce\x11\x12\x24\x5f\x48\xee\x47" \
-  "\x0d\x39\x6c\x1e\xd6\x3b\x92\x67\x0c\xa5\x6e\xc8\x4d\xee\xa8\x14" \
-  "\xb6\x13\x5e\xca\x54\x39\x2b\xde\xdb\x94\x89\xbc\x9b\x87\x5a\x8b" \
-  "\xaf\x0d\xc1\xae\x78\x57\x36\x91\x4a\xb7\xda\xa2\x64\xbc\x07\x9d" \
-  "\x26\x9f\x2c\x0d\x7e\xdd\xd8\x10\xa4\x26\x14\x5a\x07\x76\xf6\x7c" \
-  "\x87\x82\x73"
-#define TEST7_256 \
-  "\xbe\x27\x46\xc6\xdb\x52\x76\x5f\xdb\x2f\x88\x70\x0f\x9a\x73"
-#define TEST8_256 \
-  "\xe3\xd7\x25\x70\xdc\xdd\x78\x7c\xe3\x88\x7a\xb2\xcd\x68\x46\x52"
-#define TEST9_256 \
-  "\x3e\x74\x03\x71\xc8\x10\xc2\xb9\x9f\xc0\x4e\x80\x49\x07\xef\x7c" \
-  "\xf2\x6b\xe2\x8b\x57\xcb\x58\xa3\xe2\xf3\xc0\x07\x16\x6e\x49\xc1" \
-  "\x2e\x9b\xa3\x4c\x01\x04\x06\x91\x29\xea\x76\x15\x64\x25\x45\x70" \
-  "\x3a\x2b\xd9\x01\xe1\x6e\xb0\xe0\x5d\xeb\xa0\x14\xeb\xff\x64\x06" \
-  "\xa0\x7d\x54\x36\x4e\xff\x74\x2d\xa7\x79\xb0\xb3"
-#define TEST10_256 \
-  "\x83\x26\x75\x4e\x22\x77\x37\x2f\x4f\xc1\x2b\x20\x52\x7a\xfe\xf0" \
-  "\x4d\x8a\x05\x69\x71\xb1\x1a\xd5\x71\x23\xa7\xc1\x37\x76\x00\x00" \
-  "\xd7\xbe\xf6\xf3\xc1\xf7\xa9\x08\x3a\xa3\x9d\x81\x0d\xb3\x10\x77" \
-  "\x7d\xab\x8b\x1e\x7f\x02\xb8\x4a\x26\xc7\x73\x32\x5f\x8b\x23\x74" \
-  "\xde\x7a\x4b\x5a\x58\xcb\x5c\x5c\xf3\x5b\xce\xe6\xfb\x94\x6e\x5b" \
-  "\xd6\x94\xfa\x59\x3a\x8b\xeb\x3f\x9d\x65\x92\xec\xed\xaa\x66\xca" \
-  "\x82\xa2\x9d\x0c\x51\xbc\xf9\x33\x62\x30\xe5\xd7\x84\xe4\xc0\xa4" \
-  "\x3f\x8d\x79\xa3\x0a\x16\x5c\xba\xbe\x45\x2b\x77\x4b\x9c\x71\x09" \
-  "\xa9\x7d\x13\x8f\x12\x92\x28\x96\x6f\x6c\x0a\xdc\x10\x6a\xad\x5a" \
-  "\x9f\xdd\x30\x82\x57\x69\xb2\xc6\x71\xaf\x67\x59\xdf\x28\xeb\x39" \
-  "\x3d\x54\xd6"
-#define TEST7_384 \
-  "\x8b\xc5\x00\xc7\x7c\xee\xd9\x87\x9d\xa9\x89\x10\x7c\xe0\xaa"
-#define TEST8_384 \
-  "\xa4\x1c\x49\x77\x79\xc0\x37\x5f\xf1\x0a\x7f\x4e\x08\x59\x17\x39"
-#define TEST9_384 \
-  "\x68\xf5\x01\x79\x2d\xea\x97\x96\x76\x70\x22\xd9\x3d\xa7\x16\x79" \
-  "\x30\x99\x20\xfa\x10\x12\xae\xa3\x57\xb2\xb1\x33\x1d\x40\xa1\xd0" \
-  "\x3c\x41\xc2\x40\xb3\xc9\xa7\x5b\x48\x92\xf4\xc0\x72\x4b\x68\xc8" \
-  "\x75\x32\x1a\xb8\xcf\xe5\x02\x3b\xd3\x75\xbc\x0f\x94\xbd\x89\xfe" \
-  "\x04\xf2\x97\x10\x5d\x7b\x82\xff\xc0\x02\x1a\xeb\x1c\xcb\x67\x4f" \
-  "\x52\x44\xea\x34\x97\xde\x26\xa4\x19\x1c\x5f\x62\xe5\xe9\xa2\xd8" \
-  "\x08\x2f\x05\x51\xf4\xa5\x30\x68\x26\xe9\x1c\xc0\x06\xce\x1b\xf6" \
-  "\x0f\xf7\x19\xd4\x2f\xa5\x21\xc8\x71\xcd\x23\x94\xd9\x6e\xf4\x46" \
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 80]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  "\x8f\x21\x96\x6b\x41\xf2\xba\x80\xc2\x6e\x83\xa9"
-#define TEST10_384 \
-  "\x39\x96\x69\xe2\x8f\x6b\x9c\x6d\xbc\xbb\x69\x12\xec\x10\xff\xcf" \
-  "\x74\x79\x03\x49\xb7\xdc\x8f\xbe\x4a\x8e\x7b\x3b\x56\x21\xdb\x0f" \
-  "\x3e\x7d\xc8\x7f\x82\x32\x64\xbb\xe4\x0d\x18\x11\xc9\xea\x20\x61" \
-  "\xe1\xc8\x4a\xd1\x0a\x23\xfa\xc1\x72\x7e\x72\x02\xfc\x3f\x50\x42" \
-  "\xe6\xbf\x58\xcb\xa8\xa2\x74\x6e\x1f\x64\xf9\xb9\xea\x35\x2c\x71" \
-  "\x15\x07\x05\x3c\xf4\xe5\x33\x9d\x52\x86\x5f\x25\xcc\x22\xb5\xe8" \
-  "\x77\x84\xa1\x2f\xc9\x61\xd6\x6c\xb6\xe8\x95\x73\x19\x9a\x2c\xe6" \
-  "\x56\x5c\xbd\xf1\x3d\xca\x40\x38\x32\xcf\xcb\x0e\x8b\x72\x11\xe8" \
-  "\x3a\xf3\x2a\x11\xac\x17\x92\x9f\xf1\xc0\x73\xa5\x1c\xc0\x27\xaa" \
-  "\xed\xef\xf8\x5a\xad\x7c\x2b\x7c\x5a\x80\x3e\x24\x04\xd9\x6d\x2a" \
-  "\x77\x35\x7b\xda\x1a\x6d\xae\xed\x17\x15\x1c\xb9\xbc\x51\x25\xa4" \
-  "\x22\xe9\x41\xde\x0c\xa0\xfc\x50\x11\xc2\x3e\xcf\xfe\xfd\xd0\x96" \
-  "\x76\x71\x1c\xf3\xdb\x0a\x34\x40\x72\x0e\x16\x15\xc1\xf2\x2f\xbc" \
-  "\x3c\x72\x1d\xe5\x21\xe1\xb9\x9b\xa1\xbd\x55\x77\x40\x86\x42\x14" \
-  "\x7e\xd0\x96"
-#define TEST7_512 \
-  "\x08\xec\xb5\x2e\xba\xe1\xf7\x42\x2d\xb6\x2b\xcd\x54\x26\x70"
-#define TEST8_512 \
-  "\x8d\x4e\x3c\x0e\x38\x89\x19\x14\x91\x81\x6e\x9d\x98\xbf\xf0\xa0"
-#define TEST9_512 \
-  "\x3a\xdd\xec\x85\x59\x32\x16\xd1\x61\x9a\xa0\x2d\x97\x56\x97\x0b" \
-  "\xfc\x70\xac\xe2\x74\x4f\x7c\x6b\x27\x88\x15\x10\x28\xf7\xb6\xa2" \
-  "\x55\x0f\xd7\x4a\x7e\x6e\x69\xc2\xc9\xb4\x5f\xc4\x54\x96\x6d\xc3" \
-  "\x1d\x2e\x10\xda\x1f\x95\xce\x02\xbe\xb4\xbf\x87\x65\x57\x4c\xbd" \
-  "\x6e\x83\x37\xef\x42\x0a\xdc\x98\xc1\x5c\xb6\xd5\xe4\xa0\x24\x1b" \
-  "\xa0\x04\x6d\x25\x0e\x51\x02\x31\xca\xc2\x04\x6c\x99\x16\x06\xab" \
-  "\x4e\xe4\x14\x5b\xee\x2f\xf4\xbb\x12\x3a\xab\x49\x8d\x9d\x44\x79" \
-  "\x4f\x99\xcc\xad\x89\xa9\xa1\x62\x12\x59\xed\xa7\x0a\x5b\x6d\xd4" \
-  "\xbd\xd8\x77\x78\xc9\x04\x3b\x93\x84\xf5\x49\x06"
-#define TEST10_512 \
-  "\xa5\x5f\x20\xc4\x11\xaa\xd1\x32\x80\x7a\x50\x2d\x65\x82\x4e\x31" \
-  "\xa2\x30\x54\x32\xaa\x3d\x06\xd3\xe2\x82\xa8\xd8\x4e\x0d\xe1\xde" \
-  "\x69\x74\xbf\x49\x54\x69\xfc\x7f\x33\x8f\x80\x54\xd5\x8c\x26\xc4" \
-  "\x93\x60\xc3\xe8\x7a\xf5\x65\x23\xac\xf6\xd8\x9d\x03\xe5\x6f\xf2" \
-  "\xf8\x68\x00\x2b\xc3\xe4\x31\xed\xc4\x4d\xf2\xf0\x22\x3d\x4b\xb3" \
-  "\xb2\x43\x58\x6e\x1a\x7d\x92\x49\x36\x69\x4f\xcb\xba\xf8\x8d\x95" \
-  "\x19\xe4\xeb\x50\xa6\x44\xf8\xe4\xf9\x5e\xb0\xea\x95\xbc\x44\x65" \
-  "\xc8\x82\x1a\xac\xd2\xfe\x15\xab\x49\x81\x16\x4b\xbb\x6d\xc3\x2f" \
-  "\x96\x90\x87\xa1\x45\xb0\xd9\xcc\x9c\x67\xc2\x2b\x76\x32\x99\x41" \
-  "\x9c\xc4\x12\x8b\xe9\xa0\x77\xb3\xac\xe6\x34\x06\x4e\x6d\x99\x28" \
-  "\x35\x13\xdc\x06\xe7\x51\x5d\x0d\x73\x13\x2e\x9a\x0d\xc6\xd3\xb1" \
-  "\xf8\xb2\x46\xf1\xa9\x8a\x3f\xc7\x29\x41\xb1\xe3\xbb\x20\x98\xe8" \
-  "\xbf\x16\xf2\x68\xd6\x4f\x0b\x0f\x47\x07\xfe\x1e\xa1\xa1\x79\x1b" \
-  "\xa2\xf3\xc0\xc7\x58\xe5\xf5\x51\x86\x3a\x96\xc9\x49\xad\x47\xd7" \
-  "\xfb\x40\xd2"
-#define SHA1_SEED "\xd0\x56\x9c\xb3\x66\x5a\x8a\x43\xeb\x6e\xa2\x3d" \
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 81]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  "\x75\xa3\xc4\xd2\x05\x4a\x0d\x7d"
-#define SHA224_SEED "\xd0\x56\x9c\xb3\x66\x5a\x8a\x43\xeb\x6e\xa2" \
-  "\x3d\x75\xa3\xc4\xd2\x05\x4a\x0d\x7d\x66\xa9\xca\x99\xc9\xce\xb0" \
-  "\x27"
-#define SHA256_SEED "\xf4\x1e\xce\x26\x13\xe4\x57\x39\x15\x69\x6b" \
-  "\x5a\xdc\xd5\x1c\xa3\x28\xbe\x3b\xf5\x66\xa9\xca\x99\xc9\xce\xb0" \
-  "\x27\x9c\x1c\xb0\xa7"
-#define SHA384_SEED "\x82\x40\xbc\x51\xe4\xec\x7e\xf7\x6d\x18\xe3" \
-  "\x52\x04\xa1\x9f\x51\xa5\x21\x3a\x73\xa8\x1d\x6f\x94\x46\x80\xd3" \
-  "\x07\x59\x48\xb7\xe4\x63\x80\x4e\xa3\xd2\x6e\x13\xea\x82\x0d\x65" \
-  "\xa4\x84\xbe\x74\x53"
-#define SHA512_SEED "\x47\x3f\xf1\xb9\xb3\xff\xdf\xa1\x26\x69\x9a" \
-  "\xc7\xef\x9e\x8e\x78\x77\x73\x09\x58\x24\xc6\x42\x55\x7c\x13\x99" \
-  "\xd9\x8e\x42\x20\x44\x8d\xc3\x5b\x99\xbf\xdd\x44\x77\x95\x43\x92" \
-  "\x4c\x1c\xe9\x3b\xc5\x94\x15\x38\x89\x5d\xb9\x88\x26\x1b\x00\x77" \
-  "\x4b\x12\x27\x20\x39"
-
-#define TESTCOUNT 10
-#define HASHCOUNT 5
-#define RANDOMCOUNT 4
-#define HMACTESTCOUNT 7
-
-#define PRINTNONE 0
-#define PRINTTEXT 1
-#define PRINTRAW 2
-#define PRINTHEX 3
-#define PRINTBASE64 4
-
-#define PRINTPASSFAIL 1
-#define PRINTFAIL 2
-
-#define length(x) (sizeof(x)-1)
-
-/* Test arrays for hashes. */
-struct hash {
-    const char *name;
-    SHAversion whichSha;
-    int hashsize;
-    struct {
-        const char *testarray;
-        int length;
-        long repeatcount;
-        int extrabits;
-        int numberExtrabits;
-        const char *resultarray;
-    } tests[TESTCOUNT];
-    const char *randomtest;
-    const char *randomresults[RANDOMCOUNT];
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 82]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-} hashes[HASHCOUNT] = {
-  { "SHA1", SHA1, SHA1HashSize,
-    {
-      /* 1 */ { TEST1, length(TEST1), 1, 0, 0,
-        "A9993E364706816ABA3E25717850C26C9CD0D89D" },
-      /* 2 */ { TEST2_1, length(TEST2_1), 1, 0, 0,
-        "84983E441C3BD26EBAAE4AA1F95129E5E54670F1" },
-      /* 3 */ { TEST3, length(TEST3), 1000000, 0, 0,
-        "34AA973CD4C4DAA4F61EEB2BDBAD27316534016F" },
-      /* 4 */ { TEST4, length(TEST4), 10, 0, 0,
-        "DEA356A2CDDD90C7A7ECEDC5EBB563934F460452" },
-      /* 5 */ { "", 0, 0, 0x98, 5,
-        "29826B003B906E660EFF4027CE98AF3531AC75BA" },
-      /* 6 */ { "\x5e", 1, 1, 0, 0,
-        "5E6F80A34A9798CAFC6A5DB96CC57BA4C4DB59C2" },
-      /* 7 */ { TEST7_1, length(TEST7_1), 1, 0x80, 3,
-        "6239781E03729919C01955B3FFA8ACB60B988340" },
-      /* 8 */ { TEST8_1, length(TEST8_1), 1, 0, 0,
-        "82ABFF6605DBE1C17DEF12A394FA22A82B544A35" },
-      /* 9 */ { TEST9_1, length(TEST9_1), 1, 0xE0, 3,
-        "8C5B2A5DDAE5A97FC7F9D85661C672ADBF7933D4" },
-      /* 10 */ { TEST10_1, length(TEST10_1), 1, 0, 0,
-        "CB0082C8F197D260991BA6A460E76E202BAD27B3" }
-    }, SHA1_SEED, { "E216836819477C7F78E0D843FE4FF1B6D6C14CD4",
-        "A2DBC7A5B1C6C0A8BCB7AAA41252A6A7D0690DBC",
-        "DB1F9050BB863DFEF4CE37186044E2EEB17EE013",
-        "127FDEDF43D372A51D5747C48FBFFE38EF6CDF7B"
-     } },
-  { "SHA224", SHA224, SHA224HashSize,
-    {
-      /* 1 */ { TEST1, length(TEST1), 1, 0, 0,
-        "23097D223405D8228642A477BDA255B32AADBCE4BDA0B3F7E36C9DA7" },
-      /* 2 */ { TEST2_1, length(TEST2_1), 1, 0, 0,
-        "75388B16512776CC5DBA5DA1FD890150B0C6455CB4F58B1952522525" },
-      /* 3 */ { TEST3, length(TEST3), 1000000, 0, 0,
-        "20794655980C91D8BBB4C1EA97618A4BF03F42581948B2EE4EE7AD67" },
-      /* 4 */ { TEST4, length(TEST4), 10, 0, 0,
-        "567F69F168CD7844E65259CE658FE7AADFA25216E68ECA0EB7AB8262" },
-      /* 5 */ { "", 0, 0, 0x68, 5,
-        "E3B048552C3C387BCAB37F6EB06BB79B96A4AEE5FF27F51531A9551C" },
-      /* 6 */ { "\x07", 1, 1, 0, 0,
-        "00ECD5F138422B8AD74C9799FD826C531BAD2FCABC7450BEE2AA8C2A" },
-      /* 7 */ { TEST7_224, length(TEST7_224), 1, 0xA0, 3,
-        "1B01DB6CB4A9E43DED1516BEB3DB0B87B6D1EA43187462C608137150" },
-      /* 8 */ { TEST8_224, length(TEST8_224), 1, 0, 0,
-        "DF90D78AA78821C99B40BA4C966921ACCD8FFB1E98AC388E56191DB1" },
-      /* 9 */ { TEST9_224, length(TEST9_224), 1, 0xE0, 3,
-        "54BEA6EAB8195A2EB0A7906A4B4A876666300EEFBD1F3B8474F9CD57" },
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 83]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-      /* 10 */ { TEST10_224, length(TEST10_224), 1, 0, 0,
-        "0B31894EC8937AD9B91BDFBCBA294D9ADEFAA18E09305E9F20D5C3A4" }
-    }, SHA224_SEED, { "100966A5B4FDE0B42E2A6C5953D4D7F41BA7CF79FD"
-        "2DF431416734BE", "1DCA396B0C417715DEFAAE9641E10A2E99D55A"
-        "BCB8A00061EB3BE8BD", "1864E627BDB2319973CD5ED7D68DA71D8B"
-        "F0F983D8D9AB32C34ADB34", "A2406481FC1BCAF24DD08E6752E844"
-        "709563FB916227FED598EB621F"
-     } },
-  { "SHA256", SHA256, SHA256HashSize,
-  {
-      /* 1 */ { TEST1, length(TEST1), 1, 0, 0, "BA7816BF8F01CFEA4141"
-        "40DE5DAE2223B00361A396177A9CB410FF61F20015AD" },
-      /* 2 */ { TEST2_1, length(TEST2_1), 1, 0, 0, "248D6A61D20638B8"
-        "E5C026930C3E6039A33CE45964FF2167F6ECEDD419DB06C1" },
-      /* 3 */ { TEST3, length(TEST3), 1000000, 0, 0, "CDC76E5C9914FB92"
-        "81A1C7E284D73E67F1809A48A497200E046D39CCC7112CD0" },
-      /* 4 */ { TEST4, length(TEST4), 10, 0, 0, "594847328451BDFA"
-        "85056225462CC1D867D877FB388DF0CE35F25AB5562BFBB5" },
-      /* 5 */ { "", 0, 0, 0x68, 5, "D6D3E02A31A84A8CAA9718ED6C2057BE"
-        "09DB45E7823EB5079CE7A573A3760F95" },
-      /* 6 */ { "\x19", 1, 1, 0, 0, "68AA2E2EE5DFF96E3355E6C7EE373E3D"
-        "6A4E17F75F9518D843709C0C9BC3E3D4" },
-      /* 7 */ { TEST7_256, length(TEST7_256), 1, 0x60, 3, "77EC1DC8"
-        "9C821FF2A1279089FA091B35B8CD960BCAF7DE01C6A7680756BEB972" },
-      /* 8 */ { TEST8_256, length(TEST8_256), 1, 0, 0, "175EE69B02BA"
-        "9B58E2B0A5FD13819CEA573F3940A94F825128CF4209BEABB4E8" },
-      /* 9 */ { TEST9_256, length(TEST9_256), 1, 0xA0, 3, "3E9AD646"
-        "8BBBAD2AC3C2CDC292E018BA5FD70B960CF1679777FCE708FDB066E9" },
-      /* 10 */ { TEST10_256, length(TEST10_256), 1, 0, 0, "97DBCA7D"
-        "F46D62C8A422C941DD7E835B8AD3361763F7E9B2D95F4F0DA6E1CCBC" },
-    }, SHA256_SEED, { "83D28614D49C3ADC1D6FC05DB5F48037C056F8D2A4CE44"
-        "EC6457DEA5DD797CD1", "99DBE3127EF2E93DD9322D6A07909EB33B6399"
-        "5E529B3F954B8581621BB74D39", "8D4BE295BB64661CA3C7EFD129A2F7"
-        "25B33072DBDDE32385B9A87B9AF88EA76F", "40AF5D3F9716B040DF9408"
-        "E31536B70FF906EC51B00447CA97D7DD97C12411F4"
-    } },
-  { "SHA384", SHA384, SHA384HashSize,
-    {
-      /* 1 */ { TEST1, length(TEST1), 1, 0, 0,
-        "CB00753F45A35E8BB5A03D699AC65007272C32AB0EDED163"
-        "1A8B605A43FF5BED8086072BA1E7CC2358BAECA134C825A7" },
-      /* 2 */ { TEST2_2, length(TEST2_2), 1, 0, 0,
-        "09330C33F71147E83D192FC782CD1B4753111B173B3B05D2"
-        "2FA08086E3B0F712FCC7C71A557E2DB966C3E9FA91746039" },
-      /* 3 */ { TEST3, length(TEST3), 1000000, 0, 0,
-        "9D0E1809716474CB086E834E310A4A1CED149E9C00F24852"
-        "7972CEC5704C2A5B07B8B3DC38ECC4EBAE97DDD87F3D8985" },
-      /* 4 */ { TEST4, length(TEST4), 10, 0, 0,
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 84]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-        "2FC64A4F500DDB6828F6A3430B8DD72A368EB7F3A8322A70"
-        "BC84275B9C0B3AB00D27A5CC3C2D224AA6B61A0D79FB4596" },
-      /* 5 */ { "", 0, 0, 0x10, 5,
-        "8D17BE79E32B6718E07D8A603EB84BA0478F7FCFD1BB9399"
-        "5F7D1149E09143AC1FFCFC56820E469F3878D957A15A3FE4" },
-      /* 6 */ { "\xb9", 1, 1, 0, 0,
-        "BC8089A19007C0B14195F4ECC74094FEC64F01F90929282C"
-        "2FB392881578208AD466828B1C6C283D2722CF0AD1AB6938" },
-      /* 7 */ { TEST7_384, length(TEST7_384), 1, 0xA0, 3,
-        "D8C43B38E12E7C42A7C9B810299FD6A770BEF30920F17532"
-        "A898DE62C7A07E4293449C0B5FA70109F0783211CFC4BCE3" },
-      /* 8 */ { TEST8_384, length(TEST8_384), 1, 0, 0,
-        "C9A68443A005812256B8EC76B00516F0DBB74FAB26D66591"
-        "3F194B6FFB0E91EA9967566B58109CBC675CC208E4C823F7" },
-      /* 9 */ { TEST9_384, length(TEST9_384), 1, 0xE0, 3,
-        "5860E8DE91C21578BB4174D227898A98E0B45C4C760F0095"
-        "49495614DAEDC0775D92D11D9F8CE9B064EEAC8DAFC3A297" },
-      /* 10 */ { TEST10_384, length(TEST10_384), 1, 0, 0,
-        "4F440DB1E6EDD2899FA335F09515AA025EE177A79F4B4AAF"
-        "38E42B5C4DE660F5DE8FB2A5B2FBD2A3CBFFD20CFF1288C0" }
-    }, SHA384_SEED, { "CE44D7D63AE0C91482998CF662A51EC80BF6FC68661A3C"
-        "57F87566112BD635A743EA904DEB7D7A42AC808CABE697F38F", "F9C6D2"
-        "61881FEE41ACD39E67AA8D0BAD507C7363EB67E2B81F45759F9C0FD7B503"
-        "DF1A0B9E80BDE7BC333D75B804197D", "D96512D8C9F4A7A4967A366C01"
-        "C6FD97384225B58343A88264847C18E4EF8AB7AEE4765FFBC3E30BD485D3"
-        "638A01418F", "0CA76BD0813AF1509E170907A96005938BC985628290B2"
-        "5FEF73CF6FAD68DDBA0AC8920C94E0541607B0915A7B4457F7"
-    } },
-  { "SHA512", SHA512, SHA512HashSize,
-    {
-      /* 1 */ { TEST1, length(TEST1), 1, 0, 0,
-        "DDAF35A193617ABACC417349AE20413112E6FA4E89A97EA2"
-        "0A9EEEE64B55D39A2192992A274FC1A836BA3C23A3FEEBBD"
-        "454D4423643CE80E2A9AC94FA54CA49F" },
-      /* 2 */ { TEST2_2, length(TEST2_2), 1, 0, 0,
-        "8E959B75DAE313DA8CF4F72814FC143F8F7779C6EB9F7FA1"
-        "7299AEADB6889018501D289E4900F7E4331B99DEC4B5433A"
-        "C7D329EEB6DD26545E96E55B874BE909" },
-       /* 3 */ { TEST3, length(TEST3), 1000000, 0, 0,
-        "E718483D0CE769644E2E42C7BC15B4638E1F98B13B204428"
-        "5632A803AFA973EBDE0FF244877EA60A4CB0432CE577C31B"
-        "EB009C5C2C49AA2E4EADB217AD8CC09B" },
-      /* 4 */ { TEST4, length(TEST4), 10, 0, 0,
-        "89D05BA632C699C31231DED4FFC127D5A894DAD412C0E024"
-        "DB872D1ABD2BA8141A0F85072A9BE1E2AA04CF33C765CB51"
-        "0813A39CD5A84C4ACAA64D3F3FB7BAE9" },
-      /* 5 */ { "", 0, 0, 0xB0, 5,
-        "D4EE29A9E90985446B913CF1D1376C836F4BE2C1CF3CADA0"
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 85]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-        "720A6BF4857D886A7ECB3C4E4C0FA8C7F95214E41DC1B0D2"
-        "1B22A84CC03BF8CE4845F34DD5BDBAD4" },
-      /* 6 */ { "\xD0", 1, 1, 0, 0,
-        "9992202938E882E73E20F6B69E68A0A7149090423D93C81B"
-        "AB3F21678D4ACEEEE50E4E8CAFADA4C85A54EA8306826C4A"
-        "D6E74CECE9631BFA8A549B4AB3FBBA15" },
-      /* 7 */ { TEST7_512, length(TEST7_512), 1, 0x80, 3,
-        "ED8DC78E8B01B69750053DBB7A0A9EDA0FB9E9D292B1ED71"
-        "5E80A7FE290A4E16664FD913E85854400C5AF05E6DAD316B"
-        "7359B43E64F8BEC3C1F237119986BBB6" },
-      /* 8 */ { TEST8_512, length(TEST8_512), 1, 0, 0,
-        "CB0B67A4B8712CD73C9AABC0B199E9269B20844AFB75ACBD"
-        "D1C153C9828924C3DDEDAAFE669C5FDD0BC66F630F677398"
-        "8213EB1B16F517AD0DE4B2F0C95C90F8" },
-      /* 9 */ { TEST9_512, length(TEST9_512), 1, 0x80, 3,
-        "32BA76FC30EAA0208AEB50FFB5AF1864FDBF17902A4DC0A6"
-        "82C61FCEA6D92B783267B21080301837F59DE79C6B337DB2"
-        "526F8A0A510E5E53CAFED4355FE7C2F1" },
-      /* 10 */ { TEST10_512, length(TEST10_512), 1, 0, 0,
-        "C665BEFB36DA189D78822D10528CBF3B12B3EEF726039909"
-        "C1A16A270D48719377966B957A878E720584779A62825C18"
-        "DA26415E49A7176A894E7510FD1451F5" }
-    }, SHA512_SEED, { "2FBB1E7E00F746BA514FBC8C421F36792EC0E11FF5EFC3"
-        "78E1AB0C079AA5F0F66A1E3EDBAEB4F9984BE14437123038A452004A5576"
-        "8C1FD8EED49E4A21BEDCD0", "25CBE5A4F2C7B1D7EF07011705D50C62C5"
-        "000594243EAFD1241FC9F3D22B58184AE2FEE38E171CF8129E29459C9BC2"
-        "EF461AF5708887315F15419D8D17FE7949", "5B8B1F2687555CE2D7182B"
-        "92E5C3F6C36547DA1C13DBB9EA4F73EA4CBBAF89411527906D35B1B06C1B"
-        "6A8007D05EC66DF0A406066829EAB618BDE3976515AAFC", "46E36B007D"
-        "19876CDB0B29AD074FE3C08CDD174D42169D6ABE5A1414B6E79707DF5877"
-        "6A98091CF431854147BB6D3C66D43BFBC108FD715BDE6AA127C2B0E79F"
-    }
-  }
-};
-
-/* Test arrays for HMAC. */
-struct hmachash {
-    const char *keyarray[5];
-    int keylength[5];
-    const char *dataarray[5];
-    int datalength[5];
-    const char *resultarray[5];
-    int resultlength[5];
-} hmachashes[HMACTESTCOUNT] = {
-  { /* 1 */ {
-      "\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b"
-      "\x0b\x0b\x0b\x0b\x0b"
-    }, { 20 }, {
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 86]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-      "\x48\x69\x20\x54\x68\x65\x72\x65" /* "Hi There" */
-    }, { 8 }, {
-      /* HMAC-SHA-1 */
-      "B617318655057264E28BC0B6FB378C8EF146BE00",
-      /* HMAC-SHA-224 */
-      "896FB1128ABBDF196832107CD49DF33F47B4B1169912BA4F53684B22",
-      /* HMAC-SHA-256 */
-      "B0344C61D8DB38535CA8AFCEAF0BF12B881DC200C9833DA726E9376C2E32"
-      "CFF7",
-      /* HMAC-SHA-384 */
-      "AFD03944D84895626B0825F4AB46907F15F9DADBE4101EC682AA034C7CEB"
-      "C59CFAEA9EA9076EDE7F4AF152E8B2FA9CB6",
-      /* HMAC-SHA-512 */
-      "87AA7CDEA5EF619D4FF0B4241A1D6CB02379F4E2CE4EC2787AD0B30545E1"
-      "7CDEDAA833B7D6B8A702038B274EAEA3F4E4BE9D914EEB61F1702E696C20"
-      "3A126854"
-    }, { SHA1HashSize, SHA224HashSize, SHA256HashSize,
-      SHA384HashSize, SHA512HashSize }
-  },
-  { /* 2 */ {
-      "\x4a\x65\x66\x65" /* "Jefe" */
-    }, { 4 }, {
-      "\x77\x68\x61\x74\x20\x64\x6f\x20\x79\x61\x20\x77\x61\x6e\x74"
-      "\x20\x66\x6f\x72\x20\x6e\x6f\x74\x68\x69\x6e\x67\x3f"
-      /* "what do ya want for nothing?" */
-    }, { 28 }, {
-      /* HMAC-SHA-1 */
-      "EFFCDF6AE5EB2FA2D27416D5F184DF9C259A7C79",
-      /* HMAC-SHA-224 */
-      "A30E01098BC6DBBF45690F3A7E9E6D0F8BBEA2A39E6148008FD05E44",
-      /* HMAC-SHA-256 */
-      "5BDCC146BF60754E6A042426089575C75A003F089D2739839DEC58B964EC"
-      "3843",
-      /* HMAC-SHA-384 */
-      "AF45D2E376484031617F78D2B58A6B1B9C7EF464F5A01B47E42EC3736322"
-      "445E8E2240CA5E69E2C78B3239ECFAB21649",
-      /* HMAC-SHA-512 */
-      "164B7A7BFCF819E2E395FBE73B56E0A387BD64222E831FD610270CD7EA25"
-      "05549758BF75C05A994A6D034F65F8F0E6FDCAEAB1A34D4A6B4B636E070A"
-      "38BCE737"
-    }, { SHA1HashSize, SHA224HashSize, SHA256HashSize,
-      SHA384HashSize, SHA512HashSize }
-  },
-  { /* 3 */
-    {
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa"
-    }, { 20 }, {
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 87]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-      "\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd"
-      "\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd"
-      "\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd"
-      "\xdd\xdd\xdd\xdd\xdd"
-    }, { 50 }, {
-      /* HMAC-SHA-1 */
-      "125D7342B9AC11CD91A39AF48AA17B4F63F175D3",
-      /* HMAC-SHA-224 */
-      "7FB3CB3588C6C1F6FFA9694D7D6AD2649365B0C1F65D69D1EC8333EA",
-      /* HMAC-SHA-256 */
-      "773EA91E36800E46854DB8EBD09181A72959098B3EF8C122D9635514CED5"
-      "65FE",
-      /* HMAC-SHA-384 */
-      "88062608D3E6AD8A0AA2ACE014C8A86F0AA635D947AC9FEBE83EF4E55966"
-      "144B2A5AB39DC13814B94E3AB6E101A34F27",
-      /* HMAC-SHA-512 */
-      "FA73B0089D56A284EFB0F0756C890BE9B1B5DBDD8EE81A3655F83E33B227"
-      "9D39BF3E848279A722C806B485A47E67C807B946A337BEE8942674278859"
-      "E13292FB"
-    }, { SHA1HashSize, SHA224HashSize, SHA256HashSize,
-      SHA384HashSize, SHA512HashSize }
-  },
-  { /* 4 */ {
-      "\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f"
-      "\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19"
-    }, { 25 }, {
-      "\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd"
-      "\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd"
-      "\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd"
-      "\xcd\xcd\xcd\xcd\xcd"
-    }, { 50 }, {
-      /* HMAC-SHA-1 */
-      "4C9007F4026250C6BC8414F9BF50C86C2D7235DA",
-      /* HMAC-SHA-224 */
-      "6C11506874013CAC6A2ABC1BB382627CEC6A90D86EFC012DE7AFEC5A",
-      /* HMAC-SHA-256 */
-      "82558A389A443C0EA4CC819899F2083A85F0FAA3E578F8077A2E3FF46729"
-      "665B",
-      /* HMAC-SHA-384 */
-      "3E8A69B7783C25851933AB6290AF6CA77A9981480850009CC5577C6E1F57"
-      "3B4E6801DD23C4A7D679CCF8A386C674CFFB",
-      /* HMAC-SHA-512 */
-      "B0BA465637458C6990E5A8C5F61D4AF7E576D97FF94B872DE76F8050361E"
-      "E3DBA91CA5C11AA25EB4D679275CC5788063A5F19741120C4F2DE2ADEBEB"
-      "10A298DD"
-    }, { SHA1HashSize, SHA224HashSize, SHA256HashSize,
-      SHA384HashSize, SHA512HashSize }
-  },
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 88]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  { /* 5 */ {
-      "\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c"
-      "\x0c\x0c\x0c\x0c\x0c"
-    }, { 20 }, {
-      "Test With Truncation"
-    }, { 20 }, {
-      /* HMAC-SHA-1 */
-      "4C1A03424B55E07FE7F27BE1",
-      /* HMAC-SHA-224 */
-      "0E2AEA68A90C8D37C988BCDB9FCA6FA8",
-      /* HMAC-SHA-256 */
-      "A3B6167473100EE06E0C796C2955552B",
-      /* HMAC-SHA-384 */
-      "3ABF34C3503B2A23A46EFC619BAEF897",
-      /* HMAC-SHA-512 */
-      "415FAD6271580A531D4179BC891D87A6"
-    }, { 12, 16, 16, 16, 16 }
-  },
-  { /* 6 */ {
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-    }, { 80, 131 }, {
-      "Test Using Larger Than Block-Size Key - Hash Key First"
-    }, { 54 }, {
-      /* HMAC-SHA-1 */
-      "AA4AE5E15272D00E95705637CE8A3B55ED402112",
-      /* HMAC-SHA-224 */
-      "95E9A0DB962095ADAEBE9B2D6F0DBCE2D499F112F2D2B7273FA6870E",
-      /* HMAC-SHA-256 */
-      "60E431591EE0B67F0D8A26AACBF5B77F8E0BC6213728C5140546040F0EE3"
-      "7F54",
-      /* HMAC-SHA-384 */
-      "4ECE084485813E9088D2C63A041BC5B44F9EF1012A2B588F3CD11F05033A"
-      "C4C60C2EF6AB4030FE8296248DF163F44952",
-      /* HMAC-SHA-512 */
-      "80B24263C7C1A3EBB71493C1DD7BE8B49B46D1F41B4AEEC1121B013783F8"
-      "F3526B56D037E05F2598BD0FD2215D6A1E5295E64F73F63F0AEC8B915A98"
-      "5D786598"
-    }, { SHA1HashSize, SHA224HashSize, SHA256HashSize,
-      SHA384HashSize, SHA512HashSize }
-  },
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 89]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  { /* 7 */ {
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-    }, { 80, 131 }, {
-      "Test Using Larger Than Block-Size Key and "
-      "Larger Than One Block-Size Data",
-      "\x54\x68\x69\x73\x20\x69\x73\x20\x61\x20\x74\x65\x73\x74\x20"
-      "\x75\x73\x69\x6e\x67\x20\x61\x20\x6c\x61\x72\x67\x65\x72\x20"
-      "\x74\x68\x61\x6e\x20\x62\x6c\x6f\x63\x6b\x2d\x73\x69\x7a\x65"
-      "\x20\x6b\x65\x79\x20\x61\x6e\x64\x20\x61\x20\x6c\x61\x72\x67"
-      "\x65\x72\x20\x74\x68\x61\x6e\x20\x62\x6c\x6f\x63\x6b\x2d\x73"
-      "\x69\x7a\x65\x20\x64\x61\x74\x61\x2e\x20\x54\x68\x65\x20\x6b"
-      "\x65\x79\x20\x6e\x65\x65\x64\x73\x20\x74\x6f\x20\x62\x65\x20"
-      "\x68\x61\x73\x68\x65\x64\x20\x62\x65\x66\x6f\x72\x65\x20\x62"
-      "\x65\x69\x6e\x67\x20\x75\x73\x65\x64\x20\x62\x79\x20\x74\x68"
-      "\x65\x20\x48\x4d\x41\x43\x20\x61\x6c\x67\x6f\x72\x69\x74\x68"
-      "\x6d\x2e"
-      /* "This is a test using a larger than block-size key and a "
-          "larger than block-size data. The key needs to be hashed "
-          "before being used by the HMAC algorithm." */
-    }, { 73, 152 }, {
-      /* HMAC-SHA-1 */
-      "E8E99D0F45237D786D6BBAA7965C7808BBFF1A91",
-      /* HMAC-SHA-224 */
-      "3A854166AC5D9F023F54D517D0B39DBD946770DB9C2B95C9F6F565D1",
-      /* HMAC-SHA-256 */
-      "9B09FFA71B942FCB27635FBCD5B0E944BFDC63644F0713938A7F51535C3A"
-      "35E2",
-      /* HMAC-SHA-384 */
-      "6617178E941F020D351E2F254E8FD32C602420FEB0B8FB9ADCCEBB82461E"
-      "99C5A678CC31E799176D3860E6110C46523E",
-      /* HMAC-SHA-512 */
-      "E37B6A775DC87DBAA4DFA9F96E5E3FFDDEBD71F8867289865DF5A32D20CD"
-      "C944B6022CAC3C4982B10D5EEB55C3E4DE15134676FB6DE0446065C97440"
-      "FA8C6A58"
-    }, { SHA1HashSize, SHA224HashSize, SHA256HashSize,
-      SHA384HashSize, SHA512HashSize }
-  }
-};
-
-/*
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 90]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- * Check the hash value against the expected string, expressed in hex
- */
-static const char hexdigits[] = "0123456789ABCDEF";
-int checkmatch(const unsigned char *hashvalue,
-  const char *hexstr, int hashsize)
-{
-  int i;
-  for (i = 0; i < hashsize; ++i) {
-    if (*hexstr++ != hexdigits[(hashvalue[i] >> 4) & 0xF])
-      return 0;
-    if (*hexstr++ != hexdigits[hashvalue[i] & 0xF]) return 0;
-  }
-  return 1;
-}
-
-/*
- * Print the string, converting non-printable characters to "."
- */
-void printstr(const char *str, int len)
-{
-  for ( ; len-- > 0; str++)
-    putchar(isprint((unsigned char)*str) ? *str : '.');
-}
-
-/*
- * Print the string, converting non-printable characters to hex "## ".
- */
-void printxstr(const char *str, int len)
-{
-  for ( ; len-- > 0; str++)
-    printf("%c%c ", hexdigits[(*str >> 4) & 0xF],
-      hexdigits[*str & 0xF]);
-}
-
-/*
- * Print a usage message.
- */
-void usage(const char *argv0)
-{
-  fprintf(stderr,
-    "Usage:\n"
-    "Common options: [-h hash] [-w|-x] [-H]\n"
-    "Standard tests:\n"
-      "\t%s [-m] [-l loopcount] [-t test#] [-e]\n"
-      "\t\t[-r randomseed] [-R randomloop-count] "
-        "[-p] [-P|-X]\n"
-    "Hash a string:\n"
-      "\t%s [-S expectedresult] -s hashstr [-k key]\n"
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 91]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-    "Hash a file:\n"
-      "\t%s [-S expectedresult] -f file [-k key]\n"
-    "Hash a file, ignoring whitespace:\n"
-      "\t%s [-S expectedresult] -F file [-k key]\n"
-    "Additional bits to add in: [-B bitcount -b bits]\n"
-    "-h\thash to test: "
-      "0|SHA1, 1|SHA224, 2|SHA256, 3|SHA384, 4|SHA512\n"
-    "-m\tperform hmac test\n"
-    "-k\tkey for hmac test\n"
-    "-t\ttest case to run, 1-10\n"
-    "-l\thow many times to run the test\n"
-    "-e\ttest error returns\n"
-    "-p\tdo not print results\n"
-    "-P\tdo not print PASSED/FAILED\n"
-    "-X\tprint FAILED, but not PASSED\n"
-    "-r\tseed for random test\n"
-    "-R\thow many times to run random test\n"
-    "-s\tstring to hash\n"
-    "-S\texpected result of hashed string, in hex\n"
-    "-w\toutput hash in raw format\n"
-    "-x\toutput hash in hex format\n"
-    "-B\t# extra bits to add in after string or file input\n"
-    "-b\textra bits to add (high order bits of #, 0# or 0x#)\n"
-    "-H\tinput hashstr or randomseed is in hex\n"
-    , argv0, argv0, argv0, argv0);
-  exit(1);
-}
-
-/*
- * Print the results and PASS/FAIL.
- */
-void printResult(uint8_t *Message_Digest, int hashsize,
-    const char *hashname, const char *testtype, const char *testname,
-    const char *resultarray, int printResults, int printPassFail)
-{
-  int i, k;
-  if (printResults == PRINTTEXT) {
-    putchar('\t');
-    for (i = 0; i < hashsize ; ++i) {
-      putchar(hexdigits[(Message_Digest[i] >> 4) & 0xF]);
-      putchar(hexdigits[Message_Digest[i] & 0xF]);
-      putchar(' ');
-    }
-    putchar('\n');
-  } else if (printResults == PRINTRAW) {
-    fwrite(Message_Digest, 1, hashsize, stdout);
-  } else if (printResults == PRINTHEX) {
-    for (i = 0; i < hashsize ; ++i) {
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 92]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-      putchar(hexdigits[(Message_Digest[i] >> 4) & 0xF]);
-      putchar(hexdigits[Message_Digest[i] & 0xF]);
-    }
-    putchar('\n');
-  }
-
-  if (printResults && resultarray) {
-    printf("    Should match:\n\t");
-    for (i = 0, k = 0; i < hashsize; i++, k += 2) {
-      putchar(resultarray[k]);
-      putchar(resultarray[k+1]);
-      putchar(' ');
-    }
-    putchar('\n');
-  }
-
-  if (printPassFail && resultarray) {
-    int ret = checkmatch(Message_Digest, resultarray, hashsize);
-    if ((printPassFail == PRINTPASSFAIL) || !ret)
-      printf("%s %s %s: %s\n", hashname, testtype, testname,
-        ret ? "PASSED" : "FAILED");
-  }
-}
-
-/*
- * Exercise a hash series of functions. The input is the testarray,
- * repeated repeatcount times, followed by the extrabits. If the
- * result is known, it is in resultarray in uppercase hex.
- */
-int hash(int testno, int loopno, int hashno,
-  const char *testarray, int length, long repeatcount,
-  int numberExtrabits, int extrabits, const unsigned char *keyarray,
-  int keylen, const char *resultarray, int hashsize, int printResults,
-  int printPassFail)
-{
-  USHAContext sha;
-  HMACContext hmac;
-  int err, i;
-  uint8_t Message_Digest[USHAMaxHashSize];
-  char buf[20];
-
-  if (printResults == PRINTTEXT) {
-    printf("\nTest %d: Iteration %d, Repeat %ld\n\t'", testno+1,
-      loopno, repeatcount);
-    printstr(testarray, length);
-    printf("'\n\t'");
-    printxstr(testarray, length);
-    printf("'\n");
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 93]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-    printf("    Length=%d bytes (%d bits), ", length, length * 8);
-    printf("ExtraBits %d: %2.2x\n", numberExtrabits, extrabits);
-  }
-
-  memset(&sha, '\343', sizeof(sha)); /* force bad data into struct */
-  memset(&hmac, '\343', sizeof(hmac));
-  err = keyarray ? hmacReset(&hmac, hashes[hashno].whichSha,
-                             keyarray, keylen) :
-                   USHAReset(&sha, hashes[hashno].whichSha);
-  if (err != shaSuccess) {
-    fprintf(stderr, "hash(): %sReset Error %d.\n",
-            keyarray ? "hmac" : "sha", err);
-    return err;
-  }
-
-  for (i = 0; i < repeatcount; ++i) {
-    err = keyarray ? hmacInput(&hmac, (const uint8_t *) testarray,
-                               length) :
-                     USHAInput(&sha, (const uint8_t *) testarray,
-                               length);
-    if (err != shaSuccess) {
-      fprintf(stderr, "hash(): %sInput Error %d.\n",
-              keyarray ? "hmac" : "sha", err);
-      return err;
-    }
-  }
-
-  if (numberExtrabits > 0) {
-    err = keyarray ? hmacFinalBits(&hmac, (uint8_t) extrabits,
-                                   numberExtrabits) :
-                     USHAFinalBits(&sha, (uint8_t) extrabits,
-                                   numberExtrabits);
-    if (err != shaSuccess) {
-      fprintf(stderr, "hash(): %sFinalBits Error %d.\n",
-              keyarray ? "hmac" : "sha", err);
-      return err;
-    }
-  }
-
-  err = keyarray ? hmacResult(&hmac, Message_Digest) :
-                   USHAResult(&sha, Message_Digest);
-  if (err != shaSuccess) {
-    fprintf(stderr, "hash(): %s Result Error %d, could not "
-      "compute message digest.\n", keyarray ? "hmac" : "sha", err);
-    return err;
-  }
-
-  sprintf(buf, "%d", testno+1);
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 94]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  printResult(Message_Digest, hashsize, hashes[hashno].name,
-    keyarray ? "hmac standard test" : "sha standard test", buf,
-    resultarray, printResults, printPassFail);
-
-  return err;
-}
-
-/*
- * Exercise a hash series of functions. The input is a filename.
- * If the result is known, it is in resultarray in uppercase hex.
- */
-int hashfile(int hashno, const char *hashfilename, int bits,
-  int bitcount, int skipSpaces, const unsigned char *keyarray,
-  int keylen, const char *resultarray, int hashsize,
-  int printResults, int printPassFail)
-{
-  USHAContext sha;
-  HMACContext hmac;
-  int err, nread, c;
-  unsigned char buf[4096];
-  uint8_t Message_Digest[USHAMaxHashSize];
-  unsigned char cc;
-  FILE *hashfp = (strcmp(hashfilename, "-") == 0) ? stdin :
-    fopen(hashfilename, "r");
-
-  if (!hashfp) {
-    fprintf(stderr, "cannot open file '%s'\n", hashfilename);
-    return shaStateError;
-  }
-
-  memset(&sha, '\343', sizeof(sha)); /* force bad data into struct */
-  memset(&hmac, '\343', sizeof(hmac));
-  err = keyarray ? hmacReset(&hmac, hashes[hashno].whichSha,
-                             keyarray, keylen) :
-                   USHAReset(&sha, hashes[hashno].whichSha);
-
-  if (err != shaSuccess) {
-    fprintf(stderr, "hashfile(): %sReset Error %d.\n",
-            keyarray ? "hmac" : "sha", err);
-    return err;
-  }
-
-  if (skipSpaces)
-    while ((c = getc(hashfp)) != EOF) {
-      if (!isspace(c)) {
-        cc = (unsigned char)c;
-        err = keyarray ? hmacInput(&hmac, &cc, 1) :
-                         USHAInput(&sha, &cc, 1);
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 95]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-        if (err != shaSuccess) {
-          fprintf(stderr, "hashfile(): %sInput Error %d.\n",
-                  keyarray ? "hmac" : "sha", err);
-          if (hashfp != stdin) fclose(hashfp);
-          return err;
-        }
-      }
-    }
-  else
-    while ((nread = fread(buf, 1, sizeof(buf), hashfp)) > 0) {
-      err = keyarray ? hmacInput(&hmac, buf, nread) :
-                       USHAInput(&sha, buf, nread);
-      if (err != shaSuccess) {
-        fprintf(stderr, "hashfile(): %s Error %d.\n",
-                keyarray ? "hmacInput" : "shaInput", err);
-        if (hashfp != stdin) fclose(hashfp);
-        return err;
-      }
-    }
-
-  if (bitcount > 0)
-    err = keyarray ? hmacFinalBits(&hmac, bits, bitcount) :
-                   USHAFinalBits(&sha, bits, bitcount);
-  if (err != shaSuccess) {
-    fprintf(stderr, "hashfile(): %s Error %d.\n",
-            keyarray ? "hmacResult" : "shaResult", err);
-    if (hashfp != stdin) fclose(hashfp);
-    return err;
-  }
-
-  err = keyarray ? hmacResult(&hmac, Message_Digest) :
-                   USHAResult(&sha, Message_Digest);
-  if (err != shaSuccess) {
-    fprintf(stderr, "hashfile(): %s Error %d.\n",
-            keyarray ? "hmacResult" : "shaResult", err);
-    if (hashfp != stdin) fclose(hashfp);
-    return err;
-  }
-
-  printResult(Message_Digest, hashsize, hashes[hashno].name, "file",
-    hashfilename, resultarray, printResults, printPassFail);
-
-  if (hashfp != stdin) fclose(hashfp);
-  return err;
-}
-
-/*
- * Exercise a hash series of functions through multiple permutations.
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 96]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- * The input is an initial seed. That seed is replicated 3 times.
- * For 1000 rounds, the previous three results are used as the input.
- * This result is then checked, and used to seed the next cycle.
- * If the result is known, it is in resultarrays in uppercase hex.
- */
-void randomtest(int hashno, const char *seed, int hashsize,
-    const char **resultarrays, int randomcount,
-    int printResults, int printPassFail)
-{
-  int i, j; char buf[20];
-  unsigned char SEED[USHAMaxHashSize], MD[1003][USHAMaxHashSize];
-
-  /* INPUT: Seed - A random seed n bits long */
-  memcpy(SEED, seed, hashsize);
-  if (printResults == PRINTTEXT) {
-    printf("%s random test seed= '", hashes[hashno].name);
-    printxstr(seed, hashsize);
-    printf("'\n");
-  }
-
-  for (j = 0; j < randomcount; j++) {
-    /* MD0 = MD1 = MD2 = Seed; */
-    memcpy(MD[0], SEED, hashsize);
-    memcpy(MD[1], SEED, hashsize);
-    memcpy(MD[2], SEED, hashsize);
-    for (i=3; i<1003; i++) {
-      /* Mi = MDi-3 || MDi-2 || MDi-1; */
-      USHAContext Mi;
-      memset(&Mi, '\343', sizeof(Mi)); /* force bad data into struct */
-      USHAReset(&Mi, hashes[hashno].whichSha);
-      USHAInput(&Mi, MD[i-3], hashsize);
-      USHAInput(&Mi, MD[i-2], hashsize);
-      USHAInput(&Mi, MD[i-1], hashsize);
-      /* MDi = SHA(Mi); */
-      USHAResult(&Mi, MD[i]);
-    }
-
-    /* MDj = Seed = MDi; */
-    memcpy(SEED, MD[i-1], hashsize);
-
-    /* OUTPUT: MDj */
-    sprintf(buf, "%d", j);
-    printResult(SEED, hashsize, hashes[hashno].name, "random test",
-      buf, resultarrays ? resultarrays[j] : 0, printResults,
-      (j < RANDOMCOUNT) ? printPassFail : 0);
-  }
-}
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 97]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-/*
- * Look up a hash name.
- */
-int findhash(const char *argv0, const char *opt)
-{
-  int i;
-  const char *names[HASHCOUNT][2] = {
-    { "0", "sha1" }, { "1", "sha224" }, { "2", "sha256" },
-    { "3", "sha384" }, { "4", "sha512" }
-  };
-
-  for (i = 0; i < HASHCOUNT; i++)
-    if ((strcmp(opt, names[i][0]) == 0) ||
-        (scasecmp(opt, names[i][1]) == 0))
-      return i;
-
-  fprintf(stderr, "%s: Unknown hash name: '%s'\n", argv0, opt);
-  usage(argv0);
-  return 0;
-}
-
-/*
- * Run some tests that should invoke errors.
- */
-void testErrors(int hashnolow, int hashnohigh, int printResults,
-    int printPassFail)
-{
-  USHAContext usha;
-  uint8_t Message_Digest[USHAMaxHashSize];
-  int hashno, err;
-
-  for (hashno = hashnolow; hashno <= hashnohigh; hashno++) {
-    memset(&usha, '\343', sizeof(usha)); /* force bad data */
-    USHAReset(&usha, hashno);
-    USHAResult(&usha, Message_Digest);
-    err = USHAInput(&usha, (const unsigned char *)"foo", 3);
-    if (printResults == PRINTTEXT)
-      printf ("\nError %d. Should be %d.\n", err, shaStateError);
-    if ((printPassFail == PRINTPASSFAIL) ||
-        ((printPassFail == PRINTFAIL) && (err != shaStateError)))
-      printf("%s se: %s\n", hashes[hashno].name,
-        (err == shaStateError) ? "PASSED" : "FAILED");
-
-    err = USHAFinalBits(&usha, 0x80, 3);
-    if (printResults == PRINTTEXT)
-      printf ("\nError %d. Should be %d.\n", err, shaStateError);
-    if ((printPassFail == PRINTPASSFAIL) ||
-        ((printPassFail == PRINTFAIL) && (err != shaStateError)))
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 98]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-      printf("%s se: %s\n", hashes[hashno].name,
-        (err == shaStateError) ? "PASSED" : "FAILED");
-
-    err = USHAReset(0, hashes[hashno].whichSha);
-    if (printResults == PRINTTEXT)
-       printf("\nError %d. Should be %d.\n", err, shaNull);
-    if ((printPassFail == PRINTPASSFAIL) ||
-        ((printPassFail == PRINTFAIL) && (err != shaNull)))
-       printf("%s usha null: %s\n", hashes[hashno].name,
-        (err == shaNull) ? "PASSED" : "FAILED");
-
-    switch (hashno) {
-      case SHA1: err = SHA1Reset(0); break;
-      case SHA224: err = SHA224Reset(0); break;
-      case SHA256: err = SHA256Reset(0); break;
-      case SHA384: err = SHA384Reset(0); break;
-      case SHA512: err = SHA512Reset(0); break;
-    }
-    if (printResults == PRINTTEXT)
-       printf("\nError %d. Should be %d.\n", err, shaNull);
-    if ((printPassFail == PRINTPASSFAIL) ||
-        ((printPassFail == PRINTFAIL) && (err != shaNull)))
-       printf("%s sha null: %s\n", hashes[hashno].name,
-        (err == shaNull) ? "PASSED" : "FAILED");
-  }
-}
-
-/* replace a hex string in place with its value */
-int unhexStr(char *hexstr)
-{
-  char *o = hexstr;
-  int len = 0, nibble1 = 0, nibble2 = 0;
-  if (!hexstr) return 0;
-  for ( ; *hexstr; hexstr++) {
-    if (isalpha((int)(unsigned char)(*hexstr))) {
-      nibble1 = tolower(*hexstr) - 'a' + 10;
-    } else if (isdigit((int)(unsigned char)(*hexstr))) {
-      nibble1 = *hexstr - '0';
-    } else {
-      printf("\nError: bad hex character '%c'\n", *hexstr);
-    }
-    if (!*++hexstr) break;
-    if (isalpha((int)(unsigned char)(*hexstr))) {
-      nibble2 = tolower(*hexstr) - 'a' + 10;
-    } else if (isdigit((int)(unsigned char)(*hexstr))) {
-      nibble2 = *hexstr - '0';
-    } else {
-      printf("\nError: bad hex character '%c'\n", *hexstr);
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 99]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-    }
-    *o++ = (char)((nibble1 << 4) | nibble2);
-    len++;
-  }
-  return len;
-}
-
-int main(int argc, char **argv)
-{
-  int i, err;
-  int loopno, loopnohigh = 1;
-  int hashno, hashnolow = 0, hashnohigh = HASHCOUNT - 1;
-  int testno, testnolow = 0, testnohigh;
-  int ntestnohigh = 0;
-  int printResults = PRINTTEXT;
-  int printPassFail = 1;
-  int checkErrors = 0;
-  char *hashstr = 0;
-  int hashlen = 0;
-  const char *resultstr = 0;
-  char *randomseedstr = 0;
-  int runHmacTests = 0;
-  char *hmacKey = 0;
-  int hmaclen = 0;
-  int randomcount = RANDOMCOUNT;
-  const char *hashfilename = 0;
-  const char *hashFilename = 0;
-  int extrabits = 0, numberExtrabits = 0;
-  int strIsHex = 0;
-
-  while ((i = xgetopt(argc, argv, "b:B:ef:F:h:Hk:l:mpPr:R:s:S:t:wxX"))
-         != -1)
-    switch (i) {
-      case 'b': extrabits = strtol(xoptarg, 0, 0); break;
-      case 'B': numberExtrabits = atoi(xoptarg); break;
-      case 'e': checkErrors = 1; break;
-      case 'f': hashfilename = xoptarg; break;
-      case 'F': hashFilename = xoptarg; break;
-      case 'h': hashnolow = hashnohigh = findhash(argv[0], xoptarg);
-        break;
-      case 'H': strIsHex = 1; break;
-      case 'k': hmacKey = xoptarg; hmaclen = strlen(xoptarg); break;
-      case 'l': loopnohigh = atoi(xoptarg); break;
-      case 'm': runHmacTests = 1; break;
-      case 'P': printPassFail = 0; break;
-      case 'p': printResults = PRINTNONE; break;
-      case 'R': randomcount = atoi(xoptarg); break;
-      case 'r': randomseedstr = xoptarg; break;
-
-
-
-Eastlake 3rd & Hansen        Informational                    [Page 100]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-      case 's': hashstr = xoptarg; hashlen = strlen(hashstr); break;
-      case 'S': resultstr = xoptarg; break;
-      case 't': testnolow = ntestnohigh = atoi(xoptarg) - 1; break;
-      case 'w': printResults = PRINTRAW; break;
-      case 'x': printResults = PRINTHEX; break;
-      case 'X': printPassFail = 2; break;
-      default: usage(argv[0]);
-      }
-
-  if (strIsHex) {
-    hashlen = unhexStr(hashstr);
-    unhexStr(randomseedstr);
-    hmaclen = unhexStr(hmacKey);
-  }
-  testnohigh = (ntestnohigh != 0) ? ntestnohigh:
-               runHmacTests ? (HMACTESTCOUNT-1) : (TESTCOUNT-1);
-  if ((testnolow < 0) ||
-      (testnohigh >= (runHmacTests ? HMACTESTCOUNT : TESTCOUNT)) ||
-      (hashnolow < 0) || (hashnohigh >= HASHCOUNT) ||
-      (hashstr && (testnolow == testnohigh)) ||
-      (randomcount < 0) ||
-      (resultstr && (!hashstr && !hashfilename && !hashFilename)) ||
-      ((runHmacTests || hmacKey) && randomseedstr) ||
-      (hashfilename && hashFilename))
-    usage(argv[0]);
-
-  /*
-   *  Perform SHA/HMAC tests
-   */
-  for (hashno = hashnolow; hashno <= hashnohigh; ++hashno) {
-    if (printResults == PRINTTEXT)
-      printf("Hash %s\n", hashes[hashno].name);
-    err = shaSuccess;
-
-    for (loopno = 1; (loopno <= loopnohigh) && (err == shaSuccess);
-         ++loopno) {
-      if (hashstr)
-        err = hash(0, loopno, hashno, hashstr, hashlen, 1,
-          numberExtrabits, extrabits, (const unsigned char *)hmacKey,
-          hmaclen, resultstr, hashes[hashno].hashsize, printResults,
-          printPassFail);
-
-      else if (randomseedstr)
-        randomtest(hashno, randomseedstr, hashes[hashno].hashsize, 0,
-          randomcount, printResults, printPassFail);
-
-      else if (hashfilename)
-        err = hashfile(hashno, hashfilename, extrabits,
-
-
-
-Eastlake 3rd & Hansen        Informational                    [Page 101]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-                       numberExtrabits, 0,
-                       (const unsigned char *)hmacKey, hmaclen,
-                       resultstr, hashes[hashno].hashsize,
-                       printResults, printPassFail);
-
-      else if (hashFilename)
-        err = hashfile(hashno, hashFilename, extrabits,
-                       numberExtrabits, 1,
-                       (const unsigned char *)hmacKey, hmaclen,
-                       resultstr, hashes[hashno].hashsize,
-                       printResults, printPassFail);
-
-      else /* standard tests */ {
-        for (testno = testnolow;
-             (testno <= testnohigh) && (err == shaSuccess); ++testno) {
-          if (runHmacTests) {
-            err = hash(testno, loopno, hashno,
-                       hmachashes[testno].dataarray[hashno] ?
-                       hmachashes[testno].dataarray[hashno] :
-                       hmachashes[testno].dataarray[1] ?
-                       hmachashes[testno].dataarray[1] :
-                       hmachashes[testno].dataarray[0],
-                       hmachashes[testno].datalength[hashno] ?
-                       hmachashes[testno].datalength[hashno] :
-                       hmachashes[testno].datalength[1] ?
-                       hmachashes[testno].datalength[1] :
-                       hmachashes[testno].datalength[0],
-                       1, 0, 0,
-                       (const unsigned char *)(
-                        hmachashes[testno].keyarray[hashno] ?
-                        hmachashes[testno].keyarray[hashno] :
-                        hmachashes[testno].keyarray[1] ?
-                        hmachashes[testno].keyarray[1] :
-                        hmachashes[testno].keyarray[0]),
-                       hmachashes[testno].keylength[hashno] ?
-                       hmachashes[testno].keylength[hashno] :
-                       hmachashes[testno].keylength[1] ?
-                       hmachashes[testno].keylength[1] :
-                       hmachashes[testno].keylength[0],
-                       hmachashes[testno].resultarray[hashno],
-                       hmachashes[testno].resultlength[hashno],
-                       printResults, printPassFail);
-          } else {
-            err = hash(testno, loopno, hashno,
-                       hashes[hashno].tests[testno].testarray,
-                       hashes[hashno].tests[testno].length,
-                       hashes[hashno].tests[testno].repeatcount,
-                       hashes[hashno].tests[testno].numberExtrabits,
-
-
-
-Eastlake 3rd & Hansen        Informational                    [Page 102]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-                       hashes[hashno].tests[testno].extrabits, 0, 0,
-                       hashes[hashno].tests[testno].resultarray,
-                       hashes[hashno].hashsize,
-                       printResults, printPassFail);
-          }
-        }
-
-        if (!runHmacTests) {
-          randomtest(hashno, hashes[hashno].randomtest,
-            hashes[hashno].hashsize, hashes[hashno].randomresults,
-            RANDOMCOUNT, printResults, printPassFail);
-        }
-      }
-    }
-  }
-
-  /* Test some error returns */
-  if (checkErrors) {
-    testErrors(hashnolow, hashnohigh, printResults, printPassFail);
-  }
-
-  return 0;
-}
-
-/*
- * Compare two strings, case independently.
- * Equivalent to strcasecmp() found on some systems.
- */
-int scasecmp(const char *s1, const char *s2)
-{
-  for (;;) {
-    char u1 = tolower(*s1++);
-    char u2 = tolower(*s2++);
-    if (u1 != u2)
-      return u1 - u2;
-    if (u1 == '\0')
-      return 0;
-   }
-}
-
-/*
- * This is a copy of getopt provided for those systems that do not
- * have it. The name was changed to xgetopt to not conflict on those
- * systems that do have it. Similarly, optarg, optind and opterr
- * were renamed to xoptarg, xoptind and xopterr.
- *
- * Copyright 1990, 1991, 1992 by the Massachusetts Institute of
- * Technology and UniSoft Group Limited.
-
-
-
-Eastlake 3rd & Hansen        Informational                    [Page 103]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- *
- * Permission to use, copy, modify, distribute, and sell this software
- * and its documentation for any purpose is hereby granted without fee,
- * provided that the above copyright notice appear in all copies and
- * that both that copyright notice and this permission notice appear in
- * supporting documentation, and that the names of MIT and UniSoft not
- * be used in advertising or publicity pertaining to distribution of
- * the software without specific, written prior permission.  MIT and
- * UniSoft make no representations about the suitability of this
- * software for any purpose.  It is provided "as is" without express
- * or implied warranty.
- *
- * $XConsortium: getopt.c,v 1.2 92/07/01 11:59:04 rws Exp $
- * NB: Reformatted to match above style.
- */
-
-char    *xoptarg;
-int     xoptind = 1;
-int     xopterr = 1;
-
-static int xgetopt(int argc, char **argv, const char *optstring)
-{
-  static int avplace;
-  char    *ap;
-  char    *cp;
-  int     c;
-
-  if (xoptind >= argc)
-    return EOF;
-
-  ap = argv[xoptind] + avplace;
-
-  /* At beginning of arg but not an option */
-  if (avplace == 0) {
-    if (ap[0] != '-')
-      return EOF;
-    else if (ap[1] == '-') {
-      /* Special end of options option */
-      xoptind++;
-      return EOF;
-    } else if (ap[1] == '\0')
-      return EOF;  /* single '-' is not allowed */
-  }
-
-  /* Get next letter */
-  avplace++;
-  c = *++ap;
-
-
-
-
-Eastlake 3rd & Hansen        Informational                    [Page 104]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  cp = strchr(optstring, c);
-  if (cp == NULL || c == ':') {
-    if (xopterr)
-      fprintf(stderr, "Unrecognised option -- %c\n", c);
-    return '?';
-  }
-
-  if (cp[1] == ':') {
-    /* There should be an option arg */
-    avplace = 0;
-    if (ap[1] == '\0') {
-      /* It is a separate arg */
-      if (++xoptind >= argc) {
-        if (xopterr)
-          fprintf(stderr, "Option requires an argument\n");
-        return '?';
-      }
-      xoptarg = argv[xoptind++];
-    } else {
-      /* is attached to option letter */
-      xoptarg = ap + 1;
-      ++xoptind;
-    }
-  } else {
-    /* If we are out of letters then go to next arg */
-    if (ap[1] == '\0') {
-      ++xoptind;
-      avplace = 0;
-    }
-
-    xoptarg = NULL;
-  }
-  return c;
-}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                    [Page 105]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-9.  Security Considerations
-
-   This document is intended to provides the Internet community
-   convenient access to source code that implements the United States of
-   America Federal Information Processing Standard Secure Hash
-   Algorithms (SHAs) [FIPS180-2] and HMACs based upon these one-way hash
-   functions.  See license in Section 1.1.  No independent assertion of
-   the security of this hash function by the authors for any particular
-   use is intended.
-
-10.  Normative References
-
-   [FIPS180-2] "Secure Hash Standard", United States of America,
-               National Institute of Standards and Technology, Federal
-               Information Processing Standard (FIPS) 180-2,
-               http://csrc.nist.gov/publications/fips/fips180-2/
-               fips180-2withchangenotice.pdf.
-
-   [RFC2104]   Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
-               Hashing for Message Authentication", RFC 2104, February
-               1997.
-
-11.  Informative References
-
-   [RFC2202]   Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and
-               HMAC-SHA-1", RFC 2202, September 1997.
-
-   [RFC3174]   Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm
-               1 (SHA1)", RFC 3174, September 2001.
-
-   [RFC3874]   Housley, R., "A 224-bit One-way Hash Function: SHA-224",
-               RFC 3874, September 2004.
-
-   [RFC4086]   Eastlake, D., 3rd, Schiller, J., and S. Crocker,
-               "Randomness Requirements for Security", BCP 106, RFC
-               4086, June 2005.
-
-   [RFC4231]   Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA-
-               224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", RFC
-               4231, December 2005.
-
-   [SHAVS]     "The Secure Hash Algorithm Validation System (SHAVS)",
-               http://csrc.nist.gov/cryptval/shs/SHAVS.pdf.
-
-
-
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                    [Page 106]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-Authors' Addresses
-
-   Donald E. Eastlake, 3rd
-   Motorola Laboratories
-   155 Beaver Street
-   Milford, MA 01757 USA
-
-   Phone: +1-508-786-7554 (w)
-   EMail: donald.eastlake@motorola.com
-
-
-   Tony Hansen
-   AT&T Laboratories
-   200 Laurel Ave.
-   Middletown, NJ 07748 USA
-
-   Phone: +1-732-420-8934 (w)
-   EMail: tony+shs@maillennium.att.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                    [Page 107]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                    [Page 108]
-
diff --git a/contrib/bind9/doc/rfc/rfc4641.txt b/contrib/bind9/doc/rfc/rfc4641.txt
deleted file mode 100644
index 0a013bc..0000000
--- a/contrib/bind9/doc/rfc/rfc4641.txt
+++ /dev/null
@@ -1,1963 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         O. Kolkman
-Request for Comments: 4641                                     R. Gieben
-Obsoletes: 2541                                               NLnet Labs
-Category: Informational                                   September 2006
-
-
-                      DNSSEC Operational Practices
-
-Status of This Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document describes a set of practices for operating the DNS with
-   security extensions (DNSSEC).  The target audience is zone
-   administrators deploying DNSSEC.
-
-   The document discusses operational aspects of using keys and
-   signatures in the DNS.  It discusses issues of key generation, key
-   storage, signature generation, key rollover, and related policies.
-
-   This document obsoletes RFC 2541, as it covers more operational
-   ground and gives more up-to-date requirements with respect to key
-   sizes and the new DNSSEC specification.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben             Informational                      [Page 1]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-Table of Contents
-
-   1. Introduction ....................................................3
-      1.1. The Use of the Term 'key' ..................................4
-      1.2. Time Definitions ...........................................4
-   2. Keeping the Chain of Trust Intact ...............................5
-   3. Keys Generation and Storage .....................................6
-      3.1. Zone and Key Signing Keys ..................................6
-           3.1.1. Motivations for the KSK and ZSK Separation ..........6
-           3.1.2. KSKs for High-Level Zones ...........................7
-      3.2. Key Generation .............................................8
-      3.3. Key Effectivity Period .....................................8
-      3.4. Key Algorithm ..............................................9
-      3.5. Key Sizes ..................................................9
-      3.6. Private Key Storage .......................................11
-   4. Signature Generation, Key Rollover, and Related Policies .......12
-      4.1. Time in DNSSEC ............................................12
-           4.1.1. Time Considerations ................................12
-      4.2. Key Rollovers .............................................14
-           4.2.1. Zone Signing Key Rollovers .........................14
-                  4.2.1.1. Pre-Publish Key Rollover ..................15
-                  4.2.1.2. Double Signature Zone Signing Key
-                           Rollover ..................................17
-                  4.2.1.3. Pros and Cons of the Schemes ..............18
-           4.2.2. Key Signing Key Rollovers ..........................18
-           4.2.3. Difference Between ZSK and KSK Rollovers ...........20
-           4.2.4. Automated Key Rollovers ............................21
-      4.3. Planning for Emergency Key Rollover .......................21
-           4.3.1. KSK Compromise .....................................22
-                  4.3.1.1. Keeping the Chain of Trust Intact .........22
-                  4.3.1.2. Breaking the Chain of Trust ...............23
-           4.3.2. ZSK Compromise .....................................23
-           4.3.3. Compromises of Keys Anchored in Resolvers ..........24
-      4.4. Parental Policies .........................................24
-           4.4.1. Initial Key Exchanges and Parental Policies
-                  Considerations .....................................24
-           4.4.2. Storing Keys or Hashes? ............................25
-           4.4.3. Security Lameness ..................................25
-           4.4.4. DS Signature Validity Period .......................26
-   5. Security Considerations ........................................26
-   6. Acknowledgments ................................................26
-   7. References .....................................................27
-      7.1. Normative References ......................................27
-      7.2. Informative References ....................................28
-   Appendix A. Terminology ...........................................30
-   Appendix B. Zone Signing Key Rollover How-To ......................31
-   Appendix C. Typographic Conventions ...............................32
-
-
-
-
-Kolkman & Gieben             Informational                      [Page 2]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-1.  Introduction
-
-   This document describes how to run a DNS Security (DNSSEC)-enabled
-   environment.  It is intended for operators who have knowledge of the
-   DNS (see RFC 1034 [1] and RFC 1035 [2]) and want to deploy DNSSEC.
-   See RFC 4033 [4] for an introduction to DNSSEC, RFC 4034 [5] for the
-   newly introduced Resource Records (RRs), and RFC 4035 [6] for the
-   protocol changes.
-
-   During workshops and early operational deployment tests, operators
-   and system administrators have gained experience about operating the
-   DNS with security extensions (DNSSEC).  This document translates
-   these experiences into a set of practices for zone administrators.
-   At the time of writing, there exists very little experience with
-   DNSSEC in production environments; this document should therefore
-   explicitly not be seen as representing 'Best Current Practices'.
-
-   The procedures herein are focused on the maintenance of signed zones
-   (i.e., signing and publishing zones on authoritative servers).  It is
-   intended that maintenance of zones such as re-signing or key
-   rollovers be transparent to any verifying clients on the Internet.
-
-   The structure of this document is as follows.  In Section 2, we
-   discuss the importance of keeping the "chain of trust" intact.
-   Aspects of key generation and storage of private keys are discussed
-   in Section 3; the focus in this section is mainly on the private part
-   of the key(s).  Section 4 describes considerations concerning the
-   public part of the keys.  Since these public keys appear in the DNS
-   one has to take into account all kinds of timing issues, which are
-   discussed in Section 4.1.  Section 4.2 and Section 4.3 deal with the
-   rollover, or supercession, of keys.  Finally, Section 4.4 discusses
-   considerations on how parents deal with their children's public keys
-   in order to maintain chains of trust.
-
-   The typographic conventions used in this document are explained in
-   Appendix C.
-
-   Since this is a document with operational suggestions and there are
-   no protocol specifications, the RFC 2119 [7] language does not apply.
-
-   This document obsoletes RFC 2541 [12] to reflect the evolution of the
-   underlying DNSSEC protocol since then.  Changes in the choice of
-   cryptographic algorithms, DNS record types and type names, and the
-   parent-child key and signature exchange demanded a major rewrite and
-   additional information and explanation.
-
-
-
-
-
-
-Kolkman & Gieben             Informational                      [Page 3]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-1.1.  The Use of the Term 'key'
-
-   It is assumed that the reader is familiar with the concept of
-   asymmetric keys on which DNSSEC is based (public key cryptography
-   [17]).  Therefore, this document will use the term 'key' rather
-   loosely.  Where it is written that 'a key is used to sign data' it is
-   assumed that the reader understands that it is the private part of
-   the key pair that is used for signing.  It is also assumed that the
-   reader understands that the public part of the key pair is published
-   in the DNSKEY Resource Record and that it is the public part that is
-   used in key exchanges.
-
-1.2.  Time Definitions
-
-   In this document, we will be using a number of time-related terms.
-   The following definitions apply:
-
-   o  "Signature validity period" The period that a signature is valid.
-      It starts at the time specified in the signature inception field
-      of the RRSIG RR and ends at the time specified in the expiration
-      field of the RRSIG RR.
-
-   o  "Signature publication period" Time after which a signature (made
-      with a specific key) is replaced with a new signature (made with
-      the same key).  This replacement takes place by publishing the
-      relevant RRSIG in the master zone file.  After one stops
-      publishing an RRSIG in a zone, it may take a while before the
-      RRSIG has expired from caches and has actually been removed from
-      the DNS.
-
-   o  "Key effectivity period" The period during which a key pair is
-      expected to be effective.  This period is defined as the time
-      between the first inception time stamp and the last expiration
-      date of any signature made with this key, regardless of any
-      discontinuity in the use of the key.  The key effectivity period
-      can span multiple signature validity periods.
-
-   o  "Maximum/Minimum Zone Time to Live (TTL)" The maximum or minimum
-      value of the TTLs from the complete set of RRs in a zone.  Note
-      that the minimum TTL is not the same as the MINIMUM field in the
-      SOA RR.  See [11] for more information.
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben             Informational                      [Page 4]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-2.  Keeping the Chain of Trust Intact
-
-   Maintaining a valid chain of trust is important because broken chains
-   of trust will result in data being marked as Bogus (as defined in [4]
-   Section 5), which may cause entire (sub)domains to become invisible
-   to verifying clients.  The administrators of secured zones have to
-   realize that their zone is, to verifying clients, part of a chain of
-   trust.
-
-   As mentioned in the introduction, the procedures herein are intended
-   to ensure that maintenance of zones, such as re-signing or key
-   rollovers, will be transparent to the verifying clients on the
-   Internet.
-
-   Administrators of secured zones will have to keep in mind that data
-   published on an authoritative primary server will not be immediately
-   seen by verifying clients; it may take some time for the data to be
-   transferred to other secondary authoritative nameservers and clients
-   may be fetching data from caching non-authoritative servers.  In this
-   light, note that the time for a zone transfer from master to slave is
-   negligible when using NOTIFY [9] and incremental transfer (IXFR) [8].
-   It increases when full zone transfers (AXFR) are used in combination
-   with NOTIFY.  It increases even more if you rely on full zone
-   transfers based on only the SOA timing parameters for refresh.
-
-   For the verifying clients, it is important that data from secured
-   zones can be used to build chains of trust regardless of whether the
-   data came directly from an authoritative server, a caching
-   nameserver, or some middle box.  Only by carefully using the
-   available timing parameters can a zone administrator ensure that the
-   data necessary for verification can be obtained.
-
-   The responsibility for maintaining the chain of trust is shared by
-   administrators of secured zones in the chain of trust.  This is most
-   obvious in the case of a 'key compromise' when a trade-off between
-   maintaining a valid chain of trust and replacing the compromised keys
-   as soon as possible must be made.  Then zone administrators will have
-   to make a trade-off, between keeping the chain of trust intact --
-   thereby allowing for attacks with the compromised key -- or
-   deliberately breaking the chain of trust and making secured
-   subdomains invisible to security-aware resolvers.  Also see Section
-   4.3.
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben             Informational                      [Page 5]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-3.  Keys Generation and Storage
-
-   This section describes a number of considerations with respect to the
-   security of keys.  It deals with the generation, effectivity period,
-   size, and storage of private keys.
-
-3.1.  Zone and Key Signing Keys
-
-   The DNSSEC validation protocol does not distinguish between different
-   types of DNSKEYs.  All DNSKEYs can be used during the validation.  In
-   practice, operators use Key Signing and Zone Signing Keys and use the
-   so-called Secure Entry Point (SEP) [3] flag to distinguish between
-   them during operations.  The dynamics and considerations are
-   discussed below.
-
-   To make zone re-signing and key rollover procedures easier to
-   implement, it is possible to use one or more keys as Key Signing Keys
-   (KSKs).  These keys will only sign the apex DNSKEY RRSet in a zone.
-   Other keys can be used to sign all the RRSets in a zone and are
-   referred to as Zone Signing Keys (ZSKs).  In this document, we assume
-   that KSKs are the subset of keys that are used for key exchanges with
-   the parent and potentially for configuration as trusted anchors --
-   the SEP keys.  In this document, we assume a one-to-one mapping
-   between KSK and SEP keys and we assume the SEP flag to be set on all
-   KSKs.
-
-3.1.1.  Motivations for the KSK and ZSK Separation
-
-   Differentiating between the KSK and ZSK functions has several
-   advantages:
-
-   o  No parent/child interaction is required when ZSKs are updated.
-
-   o  The KSK can be made stronger (i.e., using more bits in the key
-      material).  This has little operational impact since it is only
-      used to sign a small fraction of the zone data.  Also, the KSK is
-      only used to verify the zone's key set, not for other RRSets in
-      the zone.
-
-   o  As the KSK is only used to sign a key set, which is most probably
-      updated less frequently than other data in the zone, it can be
-      stored separately from and in a safer location than the ZSK.
-
-   o  A KSK can have a longer key effectivity period.
-
-   For almost any method of key management and zone signing, the KSK is
-   used less frequently than the ZSK.  Once a key set is signed with the
-   KSK, all the keys in the key set can be used as ZSKs.  If a ZSK is
-
-
-
-Kolkman & Gieben             Informational                      [Page 6]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-   compromised, it can be simply dropped from the key set.  The new key
-   set is then re-signed with the KSK.
-
-   Given the assumption that for KSKs the SEP flag is set, the KSK can
-   be distinguished from a ZSK by examining the flag field in the DNSKEY
-   RR.  If the flag field is an odd number it is a KSK.  If it is an
-   even number it is a ZSK.
-
-   The Zone Signing Key can be used to sign all the data in a zone on a
-   regular basis.  When a Zone Signing Key is to be rolled, no
-   interaction with the parent is needed.  This allows for signature
-   validity periods on the order of days.
-
-   The Key Signing Key is only to be used to sign the DNSKEY RRs in a
-   zone.  If a Key Signing Key is to be rolled over, there will be
-   interactions with parties other than the zone administrator.  These
-   can include the registry of the parent zone or administrators of
-   verifying resolvers that have the particular key configured as secure
-   entry points.  Hence, the key effectivity period of these keys can
-   and should be made much longer.  Although, given a long enough key,
-   the key effectivity period can be on the order of years, we suggest
-   planning for a key effectivity on the order of a few months so that a
-   key rollover remains an operational routine.
-
-3.1.2.  KSKs for High-Level Zones
-
-   Higher-level zones are generally more sensitive than lower-level
-   zones.  Anyone controlling or breaking the security of a zone thereby
-   obtains authority over all of its subdomains (except in the case of
-   resolvers that have locally configured the public key of a subdomain,
-   in which case this, and only this, subdomain wouldn't be affected by
-   the compromise of the parent zone).  Therefore, extra care should be
-   taken with high-level zones, and strong keys should be used.
-
-   The root zone is the most critical of all zones.  Someone controlling
-   or compromising the security of the root zone would control the
-   entire DNS namespace of all resolvers using that root zone (except in
-   the case of resolvers that have locally configured the public key of
-   a subdomain).  Therefore, the utmost care must be taken in the
-   securing of the root zone.  The strongest and most carefully handled
-   keys should be used.  The root zone private key should always be kept
-   off-line.
-
-   Many resolvers will start at a root server for their access to and
-   authentication of DNS data.  Securely updating the trust anchors in
-   an enormous population of resolvers around the world will be
-   extremely difficult.
-
-
-
-
-Kolkman & Gieben             Informational                      [Page 7]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-3.2.  Key Generation
-
-   Careful generation of all keys is a sometimes overlooked but
-   absolutely essential element in any cryptographically secure system.
-   The strongest algorithms used with the longest keys are still of no
-   use if an adversary can guess enough to lower the size of the likely
-   key space so that it can be exhaustively searched.  Technical
-   suggestions for the generation of random keys will be found in RFC
-   4086 [14].  One should carefully assess if the random number
-   generator used during key generation adheres to these suggestions.
-
-   Keys with a long effectivity period are particularly sensitive as
-   they will represent a more valuable target and be subject to attack
-   for a longer time than short-period keys.  It is strongly recommended
-   that long-term key generation occur off-line in a manner isolated
-   from the network via an air gap or, at a minimum, high-level secure
-   hardware.
-
-3.3.  Key Effectivity Period
-
-   For various reasons, keys in DNSSEC need to be changed once in a
-   while.  The longer a key is in use, the greater the probability that
-   it will have been compromised through carelessness, accident,
-   espionage, or cryptanalysis.  Furthermore, when key rollovers are too
-   rare an event, they will not become part of the operational habit and
-   there is risk that nobody on-site will remember the procedure for
-   rollover when the need is there.
-
-   From a purely operational perspective, a reasonable key effectivity
-   period for Key Signing Keys is 13 months, with the intent to replace
-   them after 12 months.  An intended key effectivity period of a month
-   is reasonable for Zone Signing Keys.
-
-   For key sizes that match these effectivity periods, see Section 3.5.
-
-   As argued in Section 3.1.2, securely updating trust anchors will be
-   extremely difficult.  On the other hand, the "operational habit"
-   argument does also apply to trust anchor reconfiguration.  If a short
-   key effectivity period is used and the trust anchor configuration has
-   to be revisited on a regular basis, the odds that the configuration
-   tends to be forgotten is smaller.  The trade-off is against a system
-   that is so dynamic that administrators of the validating clients will
-   not be able to follow the modifications.
-
-   Key effectivity periods can be made very short, as in a few minutes.
-   But when replacing keys one has to take the considerations from
-   Section 4.1 and Section 4.2 into account.
-
-
-
-
-Kolkman & Gieben             Informational                      [Page 8]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-3.4.  Key Algorithm
-
-   There are currently three different types of algorithms that can be
-   used in DNSSEC: RSA, DSA, and elliptic curve cryptography.  The
-   latter is fairly new and has yet to be standardized for usage in
-   DNSSEC.
-
-   RSA has been developed in an open and transparent manner.  As the
-   patent on RSA expired in 2000, its use is now also free.
-
-   DSA has been developed by the National Institute of Standards and
-   Technology (NIST).  The creation of signatures takes roughly the same
-   time as with RSA, but is 10 to 40 times as slow for verification
-   [17].
-
-   We suggest the use of RSA/SHA-1 as the preferred algorithm for the
-   key.  The current known attacks on RSA can be defeated by making your
-   key longer.  As the MD5 hashing algorithm is showing cracks, we
-   recommend the usage of SHA-1.
-
-   At the time of publication, it is known that the SHA-1 hash has
-   cryptanalysis issues.  There is work in progress on addressing these
-   issues.  We recommend the use of public key algorithms based on
-   hashes stronger than SHA-1 (e.g., SHA-256), as soon as these
-   algorithms are available in protocol specifications (see [19] and
-   [20]) and implementations.
-
-3.5.  Key Sizes
-
-   When choosing key sizes, zone administrators will need to take into
-   account how long a key will be used, how much data will be signed
-   during the key publication period (see Section 8.10 of [17]), and,
-   optionally, how large the key size of the parent is.  As the chain of
-   trust really is "a chain", there is not much sense in making one of
-   the keys in the chain several times larger then the others.  As
-   always, it's the weakest link that defines the strength of the entire
-   chain.  Also see Section 3.1.1 for a discussion of how keys serving
-   different roles (ZSK vs. KSK) may need different key sizes.
-
-   Generating a key of the correct size is a difficult problem; RFC 3766
-   [13] tries to deal with that problem.  The first part of the
-   selection procedure in Section 1 of the RFC states:
-
-      1. Determine the attack resistance necessary to satisfy the
-         security requirements of the application.  Do this by
-         estimating the minimum number of computer operations that the
-         attacker will be forced to do in order to compromise the
-
-
-
-
-Kolkman & Gieben             Informational                      [Page 9]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-         security of the system and then take the logarithm base two of
-         that number.  Call that logarithm value "n".
-
-         A 1996 report recommended 90 bits as a good all-around choice
-         for system security.  The 90 bit number should be increased by
-         about 2/3 bit/year, or about 96 bits in 2005.
-
-   [13] goes on to explain how this number "n" can be used to calculate
-   the key sizes in public key cryptography.  This culminated in the
-   table given below (slightly modified for our purpose):
-
-      +-------------+-----------+--------------+
-      | System      |           |              |
-      | requirement | Symmetric | RSA or DSA   |
-      | for attack  | key size  | modulus size |
-      | resistance  | (bits)    | (bits)       |
-      | (bits)      |           |              |
-      +-------------+-----------+--------------+
-      |     70      |     70    |      947     |
-      |     80      |     80    |     1228     |
-      |     90      |     90    |     1553     |
-      |    100      |    100    |     1926     |
-      |    150      |    150    |     4575     |
-      |    200      |    200    |     8719     |
-      |    250      |    250    |    14596     |
-      +-------------+-----------+--------------+
-
-   The key sizes given are rather large.  This is because these keys are
-   resilient against a trillionaire attacker.  Assuming this rich
-   attacker will not attack your key and that the key is rolled over
-   once a year, we come to the following recommendations about KSK
-   sizes: 1024 bits for low-value domains, 1300 bits for medium-value
-   domains, and 2048 bits for high-value domains.
-
-   Whether a domain is of low, medium, or high value depends solely on
-   the views of the zone owner.  One could, for instance, view leaf
-   nodes in the DNS as of low value, and top-level domains (TLDs) or the
-   root zone of high value.  The suggested key sizes should be safe for
-   the next 5 years.
-
-   As ZSKs can be rolled over more easily (and thus more often), the key
-   sizes can be made smaller.  But as said in the introduction of this
-   paragraph, making the ZSKs' key sizes too small (in relation to the
-   KSKs' sizes) doesn't make much sense.  Try to limit the difference in
-   size to about 100 bits.
-
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 10]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-   Note that nobody can see into the future and that these key sizes are
-   only provided here as a guide.  Further information can be found in
-   [16] and Section 7.5 of [17].  It should be noted though that [16] is
-   already considered overly optimistic about what key sizes are
-   considered safe.
-
-   One final note concerning key sizes.  Larger keys will increase the
-   sizes of the RRSIG and DNSKEY records and will therefore increase the
-   chance of DNS UDP packet overflow.  Also, the time it takes to
-   validate and create RRSIGs increases with larger keys, so don't
-   needlessly double your key sizes.
-
-3.6.  Private Key Storage
-
-   It is recommended that, where possible, zone private keys and the
-   zone file master copy that is to be signed be kept and used in off-
-   line, non-network-connected, physically secure machines only.
-   Periodically, an application can be run to add authentication to a
-   zone by adding RRSIG and NSEC RRs.  Then the augmented file can be
-   transferred.
-
-   When relying on dynamic update to manage a signed zone [10], be aware
-   that at least one private key of the zone will have to reside on the
-   master server.  This key is only as secure as the amount of exposure
-   the server receives to unknown clients and the security of the host.
-   Although not mandatory, one could administer the DNS in the following
-   way.  The master that processes the dynamic updates is unavailable
-   from generic hosts on the Internet, it is not listed in the NS RR
-   set, although its name appears in the SOA RRs MNAME field.  The
-   nameservers in the NS RRSet are able to receive zone updates through
-   NOTIFY, IXFR, AXFR, or an out-of-band distribution mechanism.  This
-   approach is known as the "hidden master" setup.
-
-   The ideal situation is to have a one-way information flow to the
-   network to avoid the possibility of tampering from the network.
-   Keeping the zone master file on-line on the network and simply
-   cycling it through an off-line signer does not do this.  The on-line
-   version could still be tampered with if the host it resides on is
-   compromised.  For maximum security, the master copy of the zone file
-   should be off-net and should not be updated based on an unsecured
-   network mediated communication.
-
-   In general, keeping a zone file off-line will not be practical and
-   the machines on which zone files are maintained will be connected to
-   a network.  Operators are advised to take security measures to shield
-   unauthorized access to the master copy.
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 11]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-   For dynamically updated secured zones [10], both the master copy and
-   the private key that is used to update signatures on updated RRs will
-   need to be on-line.
-
-4.  Signature Generation, Key Rollover, and Related Policies
-
-4.1.  Time in DNSSEC
-
-   Without DNSSEC, all times in the DNS are relative.  The SOA fields
-   REFRESH, RETRY, and EXPIRATION are timers used to determine the time
-   elapsed after a slave server synchronized with a master server.  The
-   Time to Live (TTL) value and the SOA RR minimum TTL parameter [11]
-   are used to determine how long a forwarder should cache data after it
-   has been fetched from an authoritative server.  By using a signature
-   validity period, DNSSEC introduces the notion of an absolute time in
-   the DNS.  Signatures in DNSSEC have an expiration date after which
-   the signature is marked as invalid and the signed data is to be
-   considered Bogus.
-
-4.1.1.  Time Considerations
-
-   Because of the expiration of signatures, one should consider the
-   following:
-
-   o  We suggest the Maximum Zone TTL of your zone data to be a fraction
-      of your signature validity period.
-
-         If the TTL would be of similar order as the signature validity
-         period, then all RRSets fetched during the validity period
-         would be cached until the signature expiration time.  Section
-         7.1 of [4] suggests that "the resolver may use the time
-         remaining before expiration of the signature validity period of
-         a signed RRSet as an upper bound for the TTL".  As a result,
-         query load on authoritative servers would peak at signature
-         expiration time, as this is also the time at which records
-         simultaneously expire from caches.
-
-         To avoid query load peaks, we suggest the TTL on all the RRs in
-         your zone to be at least a few times smaller than your
-         signature validity period.
-
-   o  We suggest the signature publication period to end at least one
-      Maximum Zone TTL duration before the end of the signature validity
-      period.
-
-
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 12]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-         Re-signing a zone shortly before the end of the signature
-         validity period may cause simultaneous expiration of data from
-         caches.  This in turn may lead to peaks in the load on
-         authoritative servers.
-
-   o  We suggest the Minimum Zone TTL to be long enough to both fetch
-      and verify all the RRs in the trust chain.  In workshop
-      environments, it has been demonstrated [18] that a low TTL (under
-      5 to 10 minutes) caused disruptions because of the following two
-      problems:
-
-         1.  During validation, some data may expire before the
-             validation is complete.  The validator should be able to
-             keep all data until it is completed.  This applies to all
-             RRs needed to complete the chain of trust: DSes, DNSKEYs,
-             RRSIGs, and the final answers, i.e., the RRSet that is
-             returned for the initial query.
-
-         2.  Frequent verification causes load on recursive nameservers.
-             Data at delegation points, DSes, DNSKEYs, and RRSIGs
-             benefit from caching.  The TTL on those should be
-             relatively long.
-
-   o  Slave servers will need to be able to fetch newly signed zones
-      well before the RRSIGs in the zone served by the slave server pass
-      their signature expiration time.
-
-         When a slave server is out of sync with its master and data in
-         a zone is signed by expired signatures, it may be better for
-         the slave server not to give out any answer.
-
-         Normally, a slave server that is not able to contact a master
-         server for an extended period will expire a zone.  When that
-         happens, the server will respond differently to queries for
-         that zone.  Some servers issue SERVFAIL, whereas others turn
-         off the 'AA' bit in the answers.  The time of expiration is set
-         in the SOA record and is relative to the last successful
-         refresh between the master and the slave servers.  There exists
-         no coupling between the signature expiration of RRSIGs in the
-         zone and the expire parameter in the SOA.
-
-         If the server serves a DNSSEC zone, then it may well happen
-         that the signatures expire well before the SOA expiration timer
-         counts down to zero.  It is not possible to completely prevent
-         this from happening by tweaking the SOA parameters.  However,
-         the effects can be minimized where the SOA expiration time is
-         equal to or shorter than the signature validity period.  The
-         consequence of an authoritative server not being able to update
-
-
-
-Kolkman & Gieben             Informational                     [Page 13]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-         a zone, whilst that zone includes expired signatures, is that
-         non-secure resolvers will continue to be able to resolve data
-         served by the particular slave servers while security-aware
-         resolvers will experience problems because of answers being
-         marked as Bogus.
-
-         We suggest the SOA expiration timer being approximately one
-         third or one fourth of the signature validity period.  It will
-         allow problems with transfers from the master server to be
-         noticed before the actual signature times out.  We also suggest
-         that operators of nameservers that supply secondary services
-         develop 'watch dogs' to spot upcoming signature expirations in
-         zones they slave, and take appropriate action.
-
-         When determining the value for the expiration parameter one has
-         to take the following into account: What are the chances that
-         all my secondaries expire the zone? How quickly can I reach an
-         administrator of secondary servers to load a valid zone?  These
-         questions are not DNSSEC specific but may influence the choice
-         of your signature validity intervals.
-
-4.2.  Key Rollovers
-
-   A DNSSEC key cannot be used forever (see Section 3.3).  So key
-   rollovers -- or supercessions, as they are sometimes called -- are a
-   fact of life when using DNSSEC.  Zone administrators who are in the
-   process of rolling their keys have to take into account that data
-   published in previous versions of their zone still lives in caches.
-   When deploying DNSSEC, this becomes an important consideration;
-   ignoring data that may be in caches may lead to loss of service for
-   clients.
-
-   The most pressing example of this occurs when zone material signed
-   with an old key is being validated by a resolver that does not have
-   the old zone key cached.  If the old key is no longer present in the
-   current zone, this validation fails, marking the data "Bogus".
-   Alternatively, an attempt could be made to validate data that is
-   signed with a new key against an old key that lives in a local cache,
-   also resulting in data being marked "Bogus".
-
-4.2.1.  Zone Signing Key Rollovers
-
-   For "Zone Signing Key rollovers", there are two ways to make sure
-   that during the rollover data still cached can be verified with the
-   new key sets or newly generated signatures can be verified with the
-   keys still in caches.  One schema, described in Section 4.2.1.2, uses
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 14]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-   double signatures; the other uses key pre-publication (Section
-   4.2.1.1).  The pros, cons, and recommendations are described in
-   Section 4.2.1.3.
-
-4.2.1.1.  Pre-Publish Key Rollover
-
-   This section shows how to perform a ZSK rollover without the need to
-   sign all the data in a zone twice -- the "pre-publish key rollover".
-   This method has advantages in the case of a key compromise.  If the
-   old key is compromised, the new key has already been distributed in
-   the DNS.  The zone administrator is then able to quickly switch to
-   the new key and remove the compromised key from the zone.  Another
-   major advantage is that the zone size does not double, as is the case
-   with the double signature ZSK rollover.  A small "how-to" for this
-   kind of rollover can be found in Appendix B.
-
-   Pre-publish key rollover involves four stages as follows:
-
-      ----------------------------------------------------------------
-      initial         new DNSKEY       new RRSIGs      DNSKEY removal
-      ----------------------------------------------------------------
-      SOA0            SOA1             SOA2            SOA3
-      RRSIG10(SOA0)   RRSIG10(SOA1)    RRSIG11(SOA2)   RRSIG11(SOA3)
-
-      DNSKEY1         DNSKEY1          DNSKEY1         DNSKEY1
-      DNSKEY10        DNSKEY10         DNSKEY10        DNSKEY11
-      DNSKEY11         DNSKEY11
-      RRSIG1 (DNSKEY) RRSIG1 (DNSKEY)  RRSIG1(DNSKEY)  RRSIG1 (DNSKEY)
-      RRSIG10(DNSKEY) RRSIG10(DNSKEY)  RRSIG11(DNSKEY) RRSIG11(DNSKEY)
-      ----------------------------------------------------------------
-
-                         Pre-Publish Key Rollover
-
-   initial: Initial version of the zone: DNSKEY 1 is the Key Signing
-      Key.  DNSKEY 10 is used to sign all the data of the zone, the Zone
-      Signing Key.
-
-   new DNSKEY: DNSKEY 11 is introduced into the key set.  Note that no
-      signatures are generated with this key yet, but this does not
-      secure against brute force attacks on the public key.  The minimum
-      duration of this pre-roll phase is the time it takes for the data
-      to propagate to the authoritative servers plus TTL value of the
-      key set.
-
-   new RRSIGs: At the "new RRSIGs" stage (SOA serial 2), DNSKEY 11 is
-      used to sign the data in the zone exclusively (i.e., all the
-      signatures from DNSKEY 10 are removed from the zone).  DNSKEY 10
-      remains published in the key set.  This way data that was loaded
-
-
-
-Kolkman & Gieben             Informational                     [Page 15]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-      into caches from version 1 of the zone can still be verified with
-      key sets fetched from version 2 of the zone.  The minimum time
-      that the key set including DNSKEY 10 is to be published is the
-      time that it takes for zone data from the previous version of the
-      zone to expire from old caches, i.e., the time it takes for this
-      zone to propagate to all authoritative servers plus the Maximum
-      Zone TTL value of any of the data in the previous version of the
-      zone.
-
-   DNSKEY removal: DNSKEY 10 is removed from the zone.  The key set, now
-      only containing DNSKEY 1 and DNSKEY 11, is re-signed with the
-      DNSKEY 1.
-
-   The above scheme can be simplified by always publishing the "future"
-   key immediately after the rollover.  The scheme would look as follows
-   (we show two rollovers); the future key is introduced in "new DNSKEY"
-   as DNSKEY 12 and again a newer one, numbered 13, in "new DNSKEY
-   (II)":
-
-      ----------------------------------------------------------------
-      initial             new RRSIGs          new DNSKEY
-      ----------------------------------------------------------------
-      SOA0                SOA1                SOA2
-      RRSIG10(SOA0)       RRSIG11(SOA1)       RRSIG11(SOA2)
-
-      DNSKEY1             DNSKEY1             DNSKEY1
-      DNSKEY10            DNSKEY10            DNSKEY11
-      DNSKEY11            DNSKEY11            DNSKEY12
-      RRSIG1(DNSKEY)      RRSIG1 (DNSKEY)     RRSIG1(DNSKEY)
-      RRSIG10(DNSKEY)     RRSIG11(DNSKEY)     RRSIG11(DNSKEY)
-      ----------------------------------------------------------------
-
-      ----------------------------------------------------------------
-      new RRSIGs (II)     new DNSKEY (II)
-      ----------------------------------------------------------------
-      SOA3                SOA4
-      RRSIG12(SOA3)       RRSIG12(SOA4)
-
-      DNSKEY1             DNSKEY1
-      DNSKEY11            DNSKEY12
-      DNSKEY12            DNSKEY13
-      RRSIG1(DNSKEY)      RRSIG1(DNSKEY)
-      RRSIG12(DNSKEY)     RRSIG12(DNSKEY)
-      ----------------------------------------------------------------
-
-              Pre-Publish Key Rollover, Showing Two Rollovers
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 16]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-   Note that the key introduced in the "new DNSKEY" phase is not used
-   for production yet; the private key can thus be stored in a
-   physically secure manner and does not need to be 'fetched' every time
-   a zone needs to be signed.
-
-4.2.1.2.  Double Signature Zone Signing Key Rollover
-
-   This section shows how to perform a ZSK key rollover using the double
-   zone data signature scheme, aptly named "double signature rollover".
-
-   During the "new DNSKEY" stage the new version of the zone file will
-   need to propagate to all authoritative servers and the data that
-   exists in (distant) caches will need to expire, requiring at least
-   the Maximum Zone TTL.
-
-   Double signature ZSK rollover involves three stages as follows:
-
-      ----------------------------------------------------------------
-      initial             new DNSKEY         DNSKEY removal
-      ----------------------------------------------------------------
-      SOA0                SOA1               SOA2
-      RRSIG10(SOA0)       RRSIG10(SOA1)      RRSIG11(SOA2)
-      RRSIG11(SOA1)
-
-      DNSKEY1             DNSKEY1            DNSKEY1
-      DNSKEY10            DNSKEY10           DNSKEY11
-      DNSKEY11
-      RRSIG1(DNSKEY)      RRSIG1(DNSKEY)     RRSIG1(DNSKEY)
-      RRSIG10(DNSKEY)     RRSIG10(DNSKEY)    RRSIG11(DNSKEY)
-      RRSIG11(DNSKEY)
-      ----------------------------------------------------------------
-
-                Double Signature Zone Signing Key Rollover
-
-   initial: Initial Version of the zone: DNSKEY 1 is the Key Signing
-      Key.  DNSKEY 10 is used to sign all the data of the zone, the Zone
-      Signing Key.
-
-   new DNSKEY: At the "New DNSKEY" stage (SOA serial 1) DNSKEY 11 is
-      introduced into the key set and all the data in the zone is signed
-      with DNSKEY 10 and DNSKEY 11.  The rollover period will need to
-      continue until all data from version 0 of the zone has expired
-      from remote caches.  This will take at least the Maximum Zone TTL
-      of version 0 of the zone.
-
-   DNSKEY removal: DNSKEY 10 is removed from the zone.  All the
-      signatures from DNSKEY 10 are removed from the zone.  The key set,
-      now only containing DNSKEY 11, is re-signed with DNSKEY 1.
-
-
-
-Kolkman & Gieben             Informational                     [Page 17]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-   At every instance, RRSIGs from the previous version of the zone can
-   be verified with the DNSKEY RRSet from the current version and the
-   other way around.  The data from the current version can be verified
-   with the data from the previous version of the zone.  The duration of
-   the "new DNSKEY" phase and the period between rollovers should be at
-   least the Maximum Zone TTL.
-
-   Making sure that the "new DNSKEY" phase lasts until the signature
-   expiration time of the data in initial version of the zone is
-   recommended.  This way all caches are cleared of the old signatures.
-   However, this duration could be considerably longer than the Maximum
-   Zone TTL, making the rollover a lengthy procedure.
-
-   Note that in this example we assumed that the zone was not modified
-   during the rollover.  New data can be introduced in the zone as long
-   as it is signed with both keys.
-
-4.2.1.3.  Pros and Cons of the Schemes
-
-   Pre-publish key rollover: This rollover does not involve signing the
-      zone data twice.  Instead, before the actual rollover, the new key
-      is published in the key set and thus is available for
-      cryptanalysis attacks.  A small disadvantage is that this process
-      requires four steps.  Also the pre-publish scheme involves more
-      parental work when used for KSK rollovers as explained in Section
-      4.2.3.
-
-   Double signature ZSK rollover: The drawback of this signing scheme is
-      that during the rollover the number of signatures in your zone
-      doubles; this may be prohibitive if you have very big zones.  An
-      advantage is that it only requires three steps.
-
-4.2.2.  Key Signing Key Rollovers
-
-   For the rollover of a Key Signing Key, the same considerations as for
-   the rollover of a Zone Signing Key apply.  However, we can use a
-   double signature scheme to guarantee that old data (only the apex key
-   set) in caches can be verified with a new key set and vice versa.
-   Since only the key set is signed with a KSK, zone size considerations
-   do not apply.
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 18]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-   --------------------------------------------------------------------
-       initial        new DNSKEY        DS change       DNSKEY removal
-   --------------------------------------------------------------------
-     Parent:
-       SOA0           -------->         SOA1            -------->
-       RRSIGpar(SOA0) -------->         RRSIGpar(SOA1)  -------->
-       DS1            -------->         DS2             -------->
-       RRSIGpar(DS)   -------->         RRSIGpar(DS)    -------->
-
-
-     Child:
-       SOA0            SOA1             -------->       SOA2
-       RRSIG10(SOA0)   RRSIG10(SOA1)    -------->       RRSIG10(SOA2)
-                                        -------->
-       DNSKEY1         DNSKEY1          -------->       DNSKEY2
-                       DNSKEY2          -------->
-       DNSKEY10        DNSKEY10         -------->       DNSKEY10
-       RRSIG1 (DNSKEY) RRSIG1 (DNSKEY)  -------->       RRSIG2 (DNSKEY)
-                       RRSIG2 (DNSKEY)  -------->
-       RRSIG10(DNSKEY) RRSIG10(DNSKEY)  -------->       RRSIG10(DNSKEY)
-   --------------------------------------------------------------------
-
-   Stages of Deployment for a Double Signature Key Signing Key Rollover
-
-   initial: Initial version of the zone.  The parental DS points to
-      DNSKEY1.  Before the rollover starts, the child will have to
-      verify what the TTL is of the DS RR that points to DNSKEY1 -- it
-      is needed during the rollover and we refer to the value as TTL_DS.
-
-   new DNSKEY: During the "new DNSKEY" phase, the zone administrator
-      generates a second KSK, DNSKEY2.  The key is provided to the
-      parent, and the child will have to wait until a new DS RR has been
-      generated that points to DNSKEY2.  After that DS RR has been
-      published on all servers authoritative for the parent's zone, the
-      zone administrator has to wait at least TTL_DS to make sure that
-      the old DS RR has expired from caches.
-
-   DS change: The parent replaces DS1 with DS2.
-
-   DNSKEY removal: DNSKEY1 has been removed.
-
-   The scenario above puts the responsibility for maintaining a valid
-   chain of trust with the child.  It also is based on the premise that
-   the parent only has one DS RR (per algorithm) per zone.  An
-   alternative mechanism has been considered.  Using an established
-   trust relation, the interaction can be performed in-band, and the
-   removal of the keys by the child can possibly be signaled by the
-   parent.  In this mechanism, there are periods where there are two DS
-
-
-
-Kolkman & Gieben             Informational                     [Page 19]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-   RRs at the parent.  Since at the moment of writing the protocol for
-   this interaction has not been developed, further discussion is out of
-   scope for this document.
-
-4.2.3.  Difference Between ZSK and KSK Rollovers
-
-   Note that KSK rollovers and ZSK rollovers are different in the sense
-   that a KSK rollover requires interaction with the parent (and
-   possibly replacing of trust anchors) and the ensuing delay while
-   waiting for it.
-
-   A zone key rollover can be handled in two different ways: pre-publish
-   (Section 4.2.1.1) and double signature (Section 4.2.1.2).
-
-   As the KSK is used to validate the key set and because the KSK is not
-   changed during a ZSK rollover, a cache is able to validate the new
-   key set of the zone.  The pre-publish method would also work for a
-   KSK rollover.  The records that are to be pre-published are the
-   parental DS RRs.  The pre-publish method has some drawbacks for KSKs.
-   We first describe the rollover scheme and then indicate these
-   drawbacks.
-
-   --------------------------------------------------------------------
-     initial         new DS           new DNSKEY      DS/DNSKEY removal
-   --------------------------------------------------------------------
-   Parent:
-     SOA0            SOA1             -------->       SOA2
-     RRSIGpar(SOA0)  RRSIGpar(SOA1)   -------->       RRSIGpar(SOA2)
-     DS1             DS1              -------->       DS2
-                     DS2              -------->
-     RRSIGpar(DS)    RRSIGpar(DS)     -------->       RRSIGpar(DS)
-
-
-   Child:
-     SOA0            -------->        SOA1            SOA1
-     RRSIG10(SOA0)   -------->        RRSIG10(SOA1)   RRSIG10(SOA1)
-                     -------->
-     DNSKEY1         -------->        DNSKEY2         DNSKEY2
-                     -------->
-     DNSKEY10        -------->        DNSKEY10        DNSKEY10
-     RRSIG1 (DNSKEY) -------->        RRSIG2(DNSKEY)  RRSIG2 (DNSKEY)
-     RRSIG10(DNSKEY) -------->        RRSIG10(DNSKEY) RRSIG10(DNSKEY)
-   --------------------------------------------------------------------
-
-      Stages of Deployment for a Pre-Publish Key Signing Key Rollover
-
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 20]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-   When the child zone wants to roll, it notifies the parent during the
-   "new DS" phase and submits the new key (or the corresponding DS) to
-   the parent.  The parent publishes DS1 and DS2, pointing to DNSKEY1
-   and DNSKEY2, respectively.  During the rollover ("new DNSKEY" phase),
-   which can take place as soon as the new DS set propagated through the
-   DNS, the child replaces DNSKEY1 with DNSKEY2.  Immediately after that
-   ("DS/DNSKEY removal" phase), it can notify the parent that the old DS
-   record can be deleted.
-
-   The drawbacks of this scheme are that during the "new DS" phase the
-   parent cannot verify the match between the DS2 RR and DNSKEY2 using
-   the DNS -- as DNSKEY2 is not yet published.  Besides, we introduce a
-   "security lame" key (see Section 4.4.3).  Finally, the child-parent
-   interaction consists of two steps.  The "double signature" method
-   only needs one interaction.
-
-4.2.4.  Automated Key Rollovers
-
-   As keys must be renewed periodically, there is some motivation to
-   automate the rollover process.  Consider the following:
-
-   o  ZSK rollovers are easy to automate as only the child zone is
-      involved.
-
-   o  A KSK rollover needs interaction between parent and child.  Data
-      exchange is needed to provide the new keys to the parent;
-      consequently, this data must be authenticated and integrity must
-      be guaranteed in order to avoid attacks on the rollover.
-
-4.3.  Planning for Emergency Key Rollover
-
-   This section deals with preparation for a possible key compromise.
-   Our advice is to have a documented procedure ready for when a key
-   compromise is suspected or confirmed.
-
-   When the private material of one of your keys is compromised it can
-   be used for as long as a valid trust chain exists.  A trust chain
-   remains intact for
-
-   o  as long as a signature over the compromised key in the trust chain
-      is valid,
-
-   o  as long as a parental DS RR (and signature) points to the
-      compromised key,
-
-   o  as long as the key is anchored in a resolver and is used as a
-      starting point for validation (this is generally the hardest to
-      update).
-
-
-
-Kolkman & Gieben             Informational                     [Page 21]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-   While a trust chain to your compromised key exists, your namespace is
-   vulnerable to abuse by anyone who has obtained illegitimate
-   possession of the key.  Zone operators have to make a trade-off if
-   the abuse of the compromised key is worse than having data in caches
-   that cannot be validated.  If the zone operator chooses to break the
-   trust chain to the compromised key, data in caches signed with this
-   key cannot be validated.  However, if the zone administrator chooses
-   to take the path of a regular rollover, the malicious key holder can
-   spoof data so that it appears to be valid.
-
-4.3.1.  KSK Compromise
-
-   A zone containing a DNSKEY RRSet with a compromised KSK is vulnerable
-   as long as the compromised KSK is configured as trust anchor or a
-   parental DS points to it.
-
-   A compromised KSK can be used to sign the key set of an attacker's
-   zone.  That zone could be used to poison the DNS.
-
-   Therefore, when the KSK has been compromised, the trust anchor or the
-   parental DS should be replaced as soon as possible.  It is local
-   policy whether to break the trust chain during the emergency
-   rollover.  The trust chain would be broken when the compromised KSK
-   is removed from the child's zone while the parent still has a DS
-   pointing to the compromised KSK (the assumption is that there is only
-   one DS at the parent.  If there are multiple DSes this does not apply
-   -- however the chain of trust of this particular key is broken).
-
-   Note that an attacker's zone still uses the compromised KSK and the
-   presence of a parental DS would cause the data in this zone to appear
-   as valid.  Removing the compromised key would cause the attacker's
-   zone to appear as valid and the child's zone as Bogus.  Therefore, we
-   advise not to remove the KSK before the parent has a DS to a new KSK
-   in place.
-
-4.3.1.1.  Keeping the Chain of Trust Intact
-
-   If we follow this advice, the timing of the replacement of the KSK is
-   somewhat critical.  The goal is to remove the compromised KSK as soon
-   as the new DS RR is available at the parent.  And also make sure that
-   the signature made with a new KSK over the key set with the
-   compromised KSK in it expires just after the new DS appears at the
-   parent, thus removing the old cruft in one swoop.
-
-   The procedure is as follows:
-
-   1.  Introduce a new KSK into the key set, keep the compromised KSK in
-       the key set.
-
-
-
-Kolkman & Gieben             Informational                     [Page 22]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-   2.  Sign the key set, with a short validity period.  The validity
-       period should expire shortly after the DS is expected to appear
-       in the parent and the old DSes have expired from caches.
-
-   3.  Upload the DS for this new key to the parent.
-
-   4.  Follow the procedure of the regular KSK rollover: Wait for the DS
-       to appear in the authoritative servers and then wait as long as
-       the TTL of the old DS RRs.  If necessary re-sign the DNSKEY RRSet
-       and modify/extend the expiration time.
-
-   5.  Remove the compromised DNSKEY RR from the zone and re-sign the
-       key set using your "normal" validity interval.
-
-   An additional danger of a key compromise is that the compromised key
-   could be used to facilitate a legitimate DNSKEY/DS rollover and/or
-   nameserver changes at the parent.  When that happens, the domain may
-   be in dispute.  An authenticated out-of-band and secure notify
-   mechanism to contact a parent is needed in this case.
-
-   Note that this is only a problem when the DNSKEY and or DS records
-   are used for authentication at the parent.
-
-4.3.1.2.  Breaking the Chain of Trust
-
-   There are two methods to break the chain of trust.  The first method
-   causes the child zone to appear 'Bogus' to validating resolvers.  The
-   other causes the child zone to appear 'insecure'.  These are
-   described below.
-
-   In the method that causes the child zone to appear 'Bogus' to
-   validating resolvers, the child zone replaces the current KSK with a
-   new one and re-signs the key set.  Next it sends the DS of the new
-   key to the parent.  Only after the parent has placed the new DS in
-   the zone is the child's chain of trust repaired.
-
-   An alternative method of breaking the chain of trust is by removing
-   the DS RRs from the parent zone altogether.  As a result, the child
-   zone would become insecure.
-
-4.3.2.  ZSK Compromise
-
-   Primarily because there is no parental interaction required when a
-   ZSK is compromised, the situation is less severe than with a KSK
-   compromise.  The zone must still be re-signed with a new ZSK as soon
-   as possible.  As this is a local operation and requires no
-   communication between the parent and child, this can be achieved
-   fairly quickly.  However, one has to take into account that just as
-
-
-
-Kolkman & Gieben             Informational                     [Page 23]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-   with a normal rollover the immediate disappearance of the old
-   compromised key may lead to verification problems.  Also note that as
-   long as the RRSIG over the compromised ZSK is not expired the zone
-   may be still at risk.
-
-4.3.3.  Compromises of Keys Anchored in Resolvers
-
-   A key can also be pre-configured in resolvers.  For instance, if
-   DNSSEC is successfully deployed the root key may be pre-configured in
-   most security aware resolvers.
-
-   If trust-anchor keys are compromised, the resolvers using these keys
-   should be notified of this fact.  Zone administrators may consider
-   setting up a mailing list to communicate the fact that a SEP key is
-   about to be rolled over.  This communication will of course need to
-   be authenticated, e.g., by using digital signatures.
-
-   End-users faced with the task of updating an anchored key should
-   always validate the new key.  New keys should be authenticated out-
-   of-band, for example, through the use of an announcement website that
-   is secured using secure sockets (TLS) [21].
-
-4.4.  Parental Policies
-
-4.4.1.  Initial Key Exchanges and Parental Policies Considerations
-
-   The initial key exchange is always subject to the policies set by the
-   parent.  When designing a key exchange policy one should take into
-   account that the authentication and authorization mechanisms used
-   during a key exchange should be as strong as the authentication and
-   authorization mechanisms used for the exchange of delegation
-   information between parent and child.  That is, there is no implicit
-   need in DNSSEC to make the authentication process stronger than it
-   was in DNS.
-
-   Using the DNS itself as the source for the actual DNSKEY material,
-   with an out-of-band check on the validity of the DNSKEY, has the
-   benefit that it reduces the chances of user error.  A DNSKEY query
-   tool can make use of the SEP bit [3] to select the proper key from a
-   DNSSEC key set, thereby reducing the chance that the wrong DNSKEY is
-   sent.  It can validate the self-signature over a key; thereby
-   verifying the ownership of the private key material.  Fetching the
-   DNSKEY from the DNS ensures that the chain of trust remains intact
-   once the parent publishes the DS RR indicating the child is secure.
-
-   Note: the out-of-band verification is still needed when the key
-   material is fetched via the DNS.  The parent can never be sure
-   whether or not the DNSKEY RRs have been spoofed.
-
-
-
-Kolkman & Gieben             Informational                     [Page 24]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-4.4.2.  Storing Keys or Hashes?
-
-   When designing a registry system one should consider which of the
-   DNSKEYs and/or the corresponding DSes to store.  Since a child zone
-   might wish to have a DS published using a message digest algorithm
-   not yet understood by the registry, the registry can't count on being
-   able to generate the DS record from a raw DNSKEY.  Thus, we recommend
-   that registry systems at least support storing DS records.
-
-   It may also be useful to store DNSKEYs, since having them may help
-   during troubleshooting and, as long as the child's chosen message
-   digest is supported, the overhead of generating DS records from them
-   is minimal.  Having an out-of-band mechanism, such as a registry
-   directory (e.g., Whois), to find out which keys are used to generate
-   DS Resource Records for specific owners and/or zones may also help
-   with troubleshooting.
-
-   The storage considerations also relate to the design of the customer
-   interface and the method by which data is transferred between
-   registrant and registry; Will the child zone administrator be able to
-   upload DS RRs with unknown hash algorithms or does the interface only
-   allow DNSKEYs?  In the registry-registrar model, one can use the
-   DNSSEC extensions to the Extensible Provisioning Protocol (EPP) [15],
-   which allows transfer of DS RRs and optionally DNSKEY RRs.
-
-4.4.3.  Security Lameness
-
-   Security lameness is defined as what happens when a parent has a DS
-   RR pointing to a non-existing DNSKEY RR.  When this happens, the
-   child's zone may be marked "Bogus" by verifying DNS clients.
-
-   As part of a comprehensive delegation check, the parent could, at key
-   exchange time, verify that the child's key is actually configured in
-   the DNS.  However, if a parent does not understand the hashing
-   algorithm used by child, the parental checks are limited to only
-   comparing the key id.
-
-   Child zones should be very careful in removing DNSKEY material,
-   specifically SEP keys, for which a DS RR exists.
-
-   Once a zone is "security lame", a fix (e.g., removing a DS RR) will
-   take time to propagate through the DNS.
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 25]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-4.4.4.  DS Signature Validity Period
-
-   Since the DS can be replayed as long as it has a valid signature, a
-   short signature validity period over the DS minimizes the time a
-   child is vulnerable in the case of a compromise of the child's
-   KSK(s).  A signature validity period that is too short introduces the
-   possibility that a zone is marked "Bogus" in case of a configuration
-   error in the signer.  There may not be enough time to fix the
-   problems before signatures expire.  Something as mundane as operator
-   unavailability during weekends shows the need for DS signature
-   validity periods longer than 2 days.  We recommend an absolute
-   minimum for a DS signature validity period of a few days.
-
-   The maximum signature validity period of the DS record depends on how
-   long child zones are willing to be vulnerable after a key compromise.
-   On the other hand, shortening the DS signature validity interval
-   increases the operational risk for the parent.  Therefore, the parent
-   may have policy to use a signature validity interval that is
-   considerably longer than the child would hope for.
-
-   A compromise between the operational constraints of the parent and
-   minimizing damage for the child may result in a DS signature validity
-   period somewhere between a week and months.
-
-   In addition to the signature validity period, which sets a lower
-   bound on the number of times the zone owner will need to sign the
-   zone data and which sets an upper bound to the time a child is
-   vulnerable after key compromise, there is the TTL value on the DS
-   RRs.  Shortening the TTL means that the authoritative servers will
-   see more queries.  But on the other hand, a short TTL lowers the
-   persistence of DS RRSets in caches thereby increasing the speed with
-   which updated DS RRSets propagate through the DNS.
-
-5.  Security Considerations
-
-   DNSSEC adds data integrity to the DNS.  This document tries to assess
-   the operational considerations to maintain a stable and secure DNSSEC
-   service.  Not taking into account the 'data propagation' properties
-   in the DNS will cause validation failures and may make secured zones
-   unavailable to security-aware resolvers.
-
-6.  Acknowledgments
-
-   Most of the ideas in this document were the result of collective
-   efforts during workshops, discussions, and tryouts.
-
-   At the risk of forgetting individuals who were the original
-   contributors of the ideas, we would like to acknowledge people who
-
-
-
-Kolkman & Gieben             Informational                     [Page 26]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-   were actively involved in the compilation of this document.  In
-   random order: Rip Loomis, Olafur Gudmundsson, Wesley Griffin, Michael
-   Richardson, Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette
-   Olivier Courtay, Sam Weiler, Jelte Jansen, Niall O'Reilly, Holger
-   Zuleger, Ed Lewis, Hilarie Orman, Marcos Sanz, and Peter Koch.
-
-   Some material in this document has been copied from RFC 2541 [12].
-
-   Mike StJohns designed the key exchange between parent and child
-   mentioned in the last paragraph of Section 4.2.2
-
-   Section 4.2.4 was supplied by G. Guette and O. Courtay.
-
-   Emma Bretherick, Adrian Bedford, and Lindy Foster corrected many of
-   the spelling and style issues.
-
-   Kolkman and Gieben take the blame for introducing all miscakes (sic).
-
-   While working on this document, Kolkman was employed by the RIPE NCC
-   and Gieben was employed by NLnet Labs.
-
-7.  References
-
-7.1.  Normative References
-
-   [1]   Mockapetris, P., "Domain names - concepts and facilities", STD
-         13, RFC 1034, November 1987.
-
-   [2]   Mockapetris, P., "Domain names - implementation and
-         specification", STD 13, RFC 1035, November 1987.
-
-   [3]   Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System
-         KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP)
-         Flag", RFC 3757, May 2004.
-
-   [4]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "DNS Security Introduction and Requirements", RFC 4033, March
-         2005.
-
-   [5]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "Resource Records for the DNS Security Extensions", RFC 4034,
-         March 2005.
-
-   [6]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "Protocol Modifications for the DNS Security Extensions", RFC
-         4035, March 2005.
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 27]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-7.2.  Informative References
-
-   [7]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
-         Levels", BCP 14, RFC 2119, March 1997.
-
-   [8]   Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August
-         1996.
-
-   [9]   Vixie, P., "A Mechanism for Prompt Notification of Zone Changes
-         (DNS NOTIFY)", RFC 1996, August 1996.
-
-   [10]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
-         Update", RFC 3007, November 2000.
-
-   [11]  Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
-         RFC 2308, March 1998.
-
-   [12]  Eastlake, D., "DNS Security Operational Considerations", RFC
-         2541, March 1999.
-
-   [13]  Orman, H. and P. Hoffman, "Determining Strengths For Public
-         Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766,
-         April 2004.
-
-   [14]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
-         Requirements for Security", BCP 106, RFC 4086, June 2005.
-
-   [15]  Hollenbeck, S., "Domain Name System (DNS) Security Extensions
-         Mapping for the Extensible Provisioning Protocol (EPP)", RFC
-         4310, December 2005.
-
-   [16]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
-         Sizes", The Journal of Cryptology 14 (255-293), 2001.
-
-   [17]  Schneier, B., "Applied Cryptography: Protocols, Algorithms, and
-         Source Code in C", ISBN (hardcover) 0-471-12845-7, ISBN
-         (paperback) 0-471-59756-2, Published by John Wiley & Sons Inc.,
-         1996.
-
-   [18]  Rose, S., "NIST DNSSEC workshop notes", June 2001.
-
-   [19]  Jansen, J., "Use of RSA/SHA-256 DNSKEY and RRSIG Resource
-         Records in DNSSEC", Work in Progress, January 2006.
-
-   [20]  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS)
-         Resource Records (RRs)", RFC 4509, May 2006.
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 28]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-   [21]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and
-         T. Wright, "Transport Layer Security (TLS) Extensions", RFC
-         4366, April 2006.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 29]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-Appendix A.  Terminology
-
-   In this document, there is some jargon used that is defined in other
-   documents.  In most cases, we have not copied the text from the
-   documents defining the terms but have given a more elaborate
-   explanation of the meaning.  Note that these explanations should not
-   be seen as authoritative.
-
-   Anchored key: A DNSKEY configured in resolvers around the globe.
-      This key is hard to update, hence the term anchored.
-
-   Bogus: Also see Section 5 of [4].  An RRSet in DNSSEC is marked
-      "Bogus" when a signature of an RRSet does not validate against a
-      DNSKEY.
-
-   Key Signing Key or KSK: A Key Signing Key (KSK) is a key that is used
-      exclusively for signing the apex key set.  The fact that a key is
-      a KSK is only relevant to the signing tool.
-
-   Key size: The term 'key size' can be substituted by 'modulus size'
-      throughout the document.  It is mathematically more correct to use
-      modulus size, but as this is a document directed at operators we
-      feel more at ease with the term key size.
-
-   Private and public keys: DNSSEC secures the DNS through the use of
-      public key cryptography.  Public key cryptography is based on the
-      existence of two (mathematically related) keys, a public key and a
-      private key.  The public keys are published in the DNS by use of
-      the DNSKEY Resource Record (DNSKEY RR).  Private keys should
-      remain private.
-
-   Key rollover: A key rollover (also called key supercession in some
-      environments) is the act of replacing one key pair with another at
-      the end of a key effectivity period.
-
-   Secure Entry Point (SEP) key: A KSK that has a parental DS record
-      pointing to it or is configured as a trust anchor.  Although not
-      required by the protocol, we recommend that the SEP flag [3] is
-      set on these keys.
-
-   Self-signature: This only applies to signatures over DNSKEYs; a
-      signature made with DNSKEY x, over DNSKEY x is called a self-
-      signature.  Note: without further information, self-signatures
-      convey no trust.  They are useful to check the authenticity of the
-      DNSKEY, i.e., they can be used as a hash.
-
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 30]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-   Singing the zone file: The term used for the event where an
-      administrator joyfully signs its zone file while producing melodic
-      sound patterns.
-
-   Signer: The system that has access to the private key material and
-      signs the Resource Record sets in a zone.  A signer may be
-      configured to sign only parts of the zone, e.g., only those RRSets
-      for which existing signatures are about to expire.
-
-   Zone Signing Key (ZSK): A key that is used for signing all data in a
-      zone.  The fact that a key is a ZSK is only relevant to the
-      signing tool.
-
-   Zone administrator: The 'role' that is responsible for signing a zone
-      and publishing it on the primary authoritative server.
-
-Appendix B.  Zone Signing Key Rollover How-To
-
-   Using the pre-published signature scheme and the most conservative
-   method to assure oneself that data does not live in caches, here
-   follows the "how-to".
-
-   Step 0: The preparation: Create two keys and publish both in your key
-      set.  Mark one of the keys "active" and the other "published".
-      Use the "active" key for signing your zone data.  Store the
-      private part of the "published" key, preferably off-line.  The
-      protocol does not provide for attributes to mark a key as active
-      or published.  This is something you have to do on your own,
-      through the use of a notebook or key management tool.
-
-   Step 1: Determine expiration: At the beginning of the rollover make a
-      note of the highest expiration time of signatures in your zone
-      file created with the current key marked as active.  Wait until
-      the expiration time marked in Step 1 has passed.
-
-   Step 2: Then start using the key that was marked "published" to sign
-      your data (i.e., mark it "active").  Stop using the key that was
-      marked "active"; mark it "rolled".
-
-   Step 3: It is safe to engage in a new rollover (Step 1) after at
-      least one signature validity period.
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 31]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-Appendix C.  Typographic Conventions
-
-   The following typographic conventions are used in this document:
-
-   Key notation: A key is denoted by DNSKEYx, where x is a number or an
-   identifier, x could be thought of as the key id.
-
-   RRSet notations: RRs are only denoted by the type.  All other
-   information -- owner, class, rdata, and TTL--is left out.  Thus:
-   "example.com 3600 IN A 192.0.2.1" is reduced to "A".  RRSets are a
-   list of RRs.  A example of this would be "A1, A2", specifying the
-   RRSet containing two "A" records.  This could again be abbreviated to
-   just "A".
-
-   Signature notation: Signatures are denoted as RRSIGx(RRSet), which
-   means that RRSet is signed with DNSKEYx.
-
-   Zone representation: Using the above notation we have simplified the
-   representation of a signed zone by leaving out all unnecessary
-   details such as the names and by representing all data by "SOAx"
-
-   SOA representation: SOAs are represented as SOAx, where x is the
-   serial number.
-
-   Using this notation the following signed zone:
-
-   example.net.      86400  IN SOA  ns.example.net. bert.example.net. (
-                            2006022100   ; serial
-                            86400        ; refresh (  24 hours)
-                            7200         ; retry   (   2 hours)
-                            3600000      ; expire  (1000 hours)
-                            28800 )      ; minimum (   8 hours)
-                     86400  RRSIG   SOA 5 2 86400 20130522213204 (
-                                  20130422213204 14 example.net.
-                                  cmL62SI6iAX46xGNQAdQ... )
-                     86400  NS      a.iana-servers.net.
-                     86400  NS      b.iana-servers.net.
-                     86400  RRSIG   NS 5 2 86400 20130507213204 (
-                                  20130407213204 14 example.net.
-                                  SO5epiJei19AjXoUpFnQ ... )
-                     86400  DNSKEY  256 3 5 (
-                                  EtRB9MP5/AvOuVO0I8XDxy0... ) ; id = 14
-                     86400  DNSKEY  257 3 5 (
-                                  gsPW/Yy19GzYIY+Gnr8HABU... ) ; id = 15
-                     86400  RRSIG   DNSKEY 5 2 86400 20130522213204 (
-                                  20130422213204 14 example.net.
-                                  J4zCe8QX4tXVGjV4e1r9... )
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 32]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-                     86400  RRSIG   DNSKEY 5 2 86400 20130522213204 (
-                                  20130422213204 15 example.net.
-                                  keVDCOpsSeDReyV6O... )
-                     86400  RRSIG   NSEC 5 2 86400 20130507213204 (
-                                  20130407213204 14 example.net.
-                                  obj3HEp1GjnmhRjX... )
-   a.example.net.    86400  IN TXT  "A label"
-                     86400  RRSIG   TXT 5 3 86400 20130507213204 (
-                                  20130407213204 14 example.net.
-                                  IkDMlRdYLmXH7QJnuF3v... )
-                     86400  NSEC    b.example.com. TXT RRSIG NSEC
-                     86400  RRSIG   NSEC 5 3 86400 20130507213204 (
-                                  20130407213204 14 example.net.
-                                  bZMjoZ3bHjnEz0nIsPMM... )
-                     ...
-
-   is reduced to the following representation:
-
-       SOA2006022100
-       RRSIG14(SOA2006022100)
-       DNSKEY14
-       DNSKEY15
-
-       RRSIG14(KEY)
-       RRSIG15(KEY)
-
-   The rest of the zone data has the same signature as the SOA record,
-   i.e., an RRSIG created with DNSKEY 14.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 33]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-Authors' Addresses
-
-   Olaf M. Kolkman
-   NLnet Labs
-   Kruislaan 419
-   Amsterdam  1098 VA
-   The Netherlands
-
-   EMail: olaf@nlnetlabs.nl
-   URI:   http://www.nlnetlabs.nl
-
-
-   R. (Miek) Gieben
-
-   EMail: miek@miek.nl
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 34]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 35]
-
diff --git a/contrib/bind9/doc/rfc/rfc952.txt b/contrib/bind9/doc/rfc/rfc952.txt
deleted file mode 100644
index 7df339a..0000000
--- a/contrib/bind9/doc/rfc/rfc952.txt
+++ /dev/null
@@ -1,340 +0,0 @@
-Network Working Group                               K. Harrenstien (SRI)
-Request for Comments: 952                                 M. Stahl (SRI)
-                                                        E. Feinler (SRI)
-Obsoletes:  RFC 810, 608                                    October 1985
-
-                 DOD INTERNET HOST TABLE SPECIFICATION
-
-
-STATUS OF THIS MEMO
-
-   This RFC is the official specification of the format of the Internet
-   Host Table.  This edition of the specification includes minor
-   revisions to RFC-810 which brings it up to date. Distribution of this
-   memo is unlimited.
-
-INTRODUCTION
-
-   The DoD Host Table is utilized by the DoD Hostname Server maintained
-   by the DDN Network Information Center (NIC) on behalf of the Defense
-   Communications Agency (DCA) [See RFC-953].
-
-LOCATION OF THE STANDARD DOD ONLINE HOST TABLE
-
-   A machine-translatable ASCII text version of the DoD Host Table is
-   online in the file NETINFO:HOSTS.TXT on the SRI-NIC host.  It can be
-   obtained via FTP from your local host by connecting to host
-   SRI-NIC.ARPA (26.0.0.73 or 10.0.0.51), logging in as user =
-   ANONYMOUS, password = GUEST, and retrieving the file
-   "NETINFO:HOSTS.TXT".  The same table may also be obtained via the NIC
-   Hostname Server, as described in RFC-953.  The latter method is
-   faster and easier, but requires a user program to make the necessary
-   connection to the Name Server.
-
-ASSUMPTIONS
-
-   1. A "name" (Net, Host, Gateway, or Domain name) is a text string up
-   to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus
-   sign (-), and period (.).  Note that periods are only allowed when
-   they serve to delimit components of "domain style names". (See
-   RFC-921, "Domain Name System Implementation Schedule", for
-   background).  No blank or space characters are permitted as part of a
-   name. No distinction is made between upper and lower case.  The first
-   character must be an alpha character.  The last character must not be
-   a minus sign or period.  A host which serves as a GATEWAY should have
-   "-GATEWAY" or "-GW" as part of its name.  Hosts which do not serve as
-   Internet gateways should not use "-GATEWAY" and "-GW" as part of
-   their names. A host which is a TAC should have "-TAC" as the last
-   part of its host name, if it is a DoD host.  Single character names
-   or nicknames are not allowed.
-
-   2. Internet Addresses are 32-bit addresses [See RFC-796].  In the
-
-
-Harrenstien & Stahl & Feinler                                   [Page 1]
-
-
-
-RFC 952                                                     October 1985
-DOD INTERNET HOST TABLE SPECIFICATION
-
-
-   host table described herein each address is represented by four
-   decimal numbers separated by a period.  Each decimal number
-   represents 1 octet.
-
-   3. If the first bit of the first octet of the address is 0 (zero),
-   then the next 7 bits of the first octet indicate the network number
-   (Class A Address).  If the first two bits are 1,0 (one,zero), then
-   the next 14 bits define the net number (Class B Address).  If the
-   first 3 bits are 1,1,0 (one,one,zero), then the next 21 bits define
-   the net number (Class C Address) [See RFC-943].
-
-      This is depicted in the following diagram:
-
-      +-+------------+--------------+--------------+--------------+
-      |0|  NET <-7-> |         LOCAL ADDRESS <-24->               |
-      +-+------------+--------------+--------------+--------------+
-
-      +---+----------+--------------+--------------+--------------+
-      |1 0|      NET  <-14->        |  LOCAL ADDRESS <-16->       |
-      +---+----------+--------------+--------------+--------------+
-
-      +-----+--------+--------------+--------------+--------------+
-      |1 1 0|            NET  <-21->               | LOCAL ADDRESS|
-      +-----+--------+--------------+--------------+--------------+
-
-   4. The LOCAL ADDRESS portion of the internet address identifies a
-   host within the network specified by the NET portion of the address.
-
-   5. The ARPANET and MILNET are both Class A networks.  The NET portion
-   is 10 decimal for ARPANET, 26 decimal for MILNET, and the LOCAL
-   ADDRESS maps as follows: the second octet identifies the physical
-   host, the third octet identifies the logical host, and the fourth
-   identifies the Packet Switching Node (PSN), formerly known as an
-   Interface Message Processor (IMP).
-
-      +-+------------+--------------+--------------+--------------+
-      |0|  10 or 26  |    HOST      | LOGICAL HOST |   PSN (IMP)  |
-      +-+------------+--------------+--------------+--------------+
-
-      (NOTE:  RFC-796 also describes the local address mappings for
-      several other networks.)
-
-   6. It is the responsibility of the users of this host table to
-   translate it into whatever format is needed for their purposes.
-
-   7. Names and addresses for DoD hosts and gateways will be negotiated
-   and registered with the DDN PMO, and subsequently with the NIC,
-
-
-Harrenstien & Stahl & Feinler                                   [Page 2]
-
-
-
-RFC 952                                                     October 1985
-DOD INTERNET HOST TABLE SPECIFICATION
-
-
-   before being used and before traffic is passed by a DoD host.  Names
-   and addresses for domains and networks are to be registered with the
-   DDN Network Information Center (HOSTMASTER@SRI-NIC.ARPA) or
-   800-235-3155.
-
-   The NIC will attempt to keep similar information for non-DoD networks
-   and hosts, if this information is provided, and as long as it is
-   needed, i.e., until intercommunicating network name servers are in
-   place.
-
-EXAMPLE OF HOST TABLE FORMAT
-
-   NET : 10.0.0.0 : ARPANET :
-   NET : 128.10.0.0 : PURDUE-CS-NET :
-   GATEWAY : 10.0.0.77, 18.10.0.4 : MIT-GW.ARPA,MIT-GATEWAY : PDP-11 :
-             MOS : IP/GW,EGP :
-   HOST : 26.0.0.73, 10.0.0.51 : SRI-NIC.ARPA,SRI-NIC,NIC : DEC-2060 :
-          TOPS20 :TCP/TELNET,TCP/SMTP,TCP/TIME,TCP/FTP,TCP/ECHO,ICMP :
-   HOST : 10.2.0.11 : SU-TAC.ARPA,SU-TAC : C/30 : TAC : TCP :
-
-SYNTAX AND CONVENTIONS
-
-   ; (semicolon)   is used to denote the beginning of a comment.
-                   Any text on a given line following a ';' is a
-                   comment, and not part of the host table.
-
-   NET             keyword introducing a network entry
-
-   GATEWAY         keyword introducing a gateway entry
-
-   HOST            keyword introducing a host entry
-
-   DOMAIN          keyword introducing a domain entry
-
-   :(colon)        is used as a field delimiter
-
-   ::(2 colons)    indicates a null field
-
-   ,(comma)        is used as a data element delimiter
-
-   XXX/YYY         indicates protocol information of the type
-                   TRANSPORT/SERVICE.
-
-      where TRANSPORT/SERVICE options are specified as
-
-         "FOO/BAR"       both transport and service known
-
-
-
-Harrenstien & Stahl & Feinler                                   [Page 3]
-
-
-
-RFC 952                                                     October 1985
-DOD INTERNET HOST TABLE SPECIFICATION
-
-
-         "FOO"           transport known; services not known
-
-         "BAR"           service is known, transport not known
-
-         NOTE:  See "Assigned Numbers" for specific options and acronyms
-         for machine types, operating systems, and protocol/services.
-
-   Each host table entry is an ASCII text string comprised of 6 fields,
-   where
-
-      Field 1         KEYWORD indicating whether this entry pertains to
-                      a NET, GATEWAY, HOST, or DOMAIN.  NET entries are
-                      assigned and cannot have alternate addresses or
-                      nicknames.  DOMAIN entries do not use fields 4, 5,
-                      or 6.
-
-      Field 2         Internet Address of Network, Gateway, or Host
-                      followed by alternate addresses.  Addresses for a
-                      Domain are those where a Domain Name Server exists
-                      for that domain.
-
-      Field 3         Official Name of Network, Gateway, Host, or Domain
-                      (with optional nicknames, where permitted).
-
-      Field 4         Machine Type
-
-      Field 5         Operating System
-
-      Field 6         Protocol List
-
-   Fields 4, 5 and 6 are optional.  For a Domain they are not used.
-
-   Fields 3-6, if included, pertain to the first address in Field 2.
-
-   'Blanks' (spaces and tabs) are ignored between data elements or
-   fields, but are disallowed within a data element.
-
-   Each entry ends with a colon.
-
-   The entries in the table are grouped by types in the order Domain,
-   Net, Gateway, and Host.  Within each type the ordering is
-   unspecified.
-
-   Note that although optional nicknames are allowed for hosts, they are
-   discouraged, except in the case where host names have been changed
-
-
-
-
-Harrenstien & Stahl & Feinler                                   [Page 4]
-
-
-
-RFC 952                                                     October 1985
-DOD INTERNET HOST TABLE SPECIFICATION
-
-
-   and both the new and the old names are maintained for a suitable
-   period of time to effect a smooth transition.  Nicknames are not
-   permitted for NET names.
-
-GRAMMATICAL HOST TABLE SPECIFICATION
-
-   A. Parsing grammar
-
-      <entry> ::= <keyword> ":" <addresses> ":" <names> [":" [<cputype>]
-         [":" [<opsys>]  [":" [<protocol list>] ]]] ":"
-      <addresses> ::= <address> *["," <address>]
-      <address> ::= <octet> "." <octet> "." <octet> "." <octet>
-      <octet> ::= <0 to 255 decimal>
-      <names> ::= <netname> | <gatename> | <domainname> *[","
-         <nicknames>]
-         | <official hostname> *["," <nicknames>]
-      <netname>  ::= <name>
-      <gatename> ::= <hname>
-      <domainname> ::= <hname>
-      <official hostname> ::= <hname>
-      <nickname> ::= <hname>
-      <protocol list> ::= <protocol spec> *["," <protocol spec>]
-      <protocol spec> ::= <transport name> "/" <service name>
-         | <raw protocol name>
-
-   B. Lexical grammar
-
-      <entry-field> ::= <entry-text> [<cr><lf> <blank> <entry-field>]
-      <entry-text>  ::= <print-char> *<text>
-      <blank> ::= <space-or-tab> [<blank>]
-      <keyword> ::= NET | GATEWAY | HOST | DOMAIN
-      <hname> ::= <name>*["."<name>]
-      <name>  ::= <let>[*[<let-or-digit-or-hyphen>]<let-or-digit>]
-      <cputype> ::= PDP-11/70 | DEC-1080 | C/30 | CDC-6400...etc.
-      <opsys>   ::= ITS | MULTICS | TOPS20 | UNIX...etc.
-      <transport name> ::= TCP | NCP | UDP | IP...etc.
-      <service name> ::= TELNET | FTP | SMTP | MTP...etc.
-      <raw protocol name> ::= <name>
-      <comment> ::= ";" <text><cr><lf>
-      <text>    ::= *[<print-char> | <blank>]
-      <print-char>  ::= <any printing char (not space or tab)>
-
-   Notes:
-
-      1. Zero or more 'blanks' between separators " , : " are allowed.
-      'Blanks' are spaces and tabs.
-
-
-
-Harrenstien & Stahl & Feinler                                   [Page 5]
-
-
-
-RFC 952                                                     October 1985
-DOD INTERNET HOST TABLE SPECIFICATION
-
-
-      2. Continuation lines are lines that begin with at least one
-      blank.  They may be used anywhere 'blanks' are legal to split an
-      entry across lines.
-
-BIBLIOGRAPHY
-
-   1. Feinler, E., Harrenstien, K., Su, Z. and White, V., "Official DoD
-      Internet Host Table Specification", RFC-810, Network Information
-      Center, SRI International, March 1982.
-
-   2. Harrenstien, K., Stahl, M., and Feinler, E., "Hostname Server",
-      RFC-953, Network Information Center, SRI International, October
-      1985.
-
-   3. Kudlick, M. "Host Names Online", RFC-608, Network Information
-      Center, SRI International, January 1973.
-
-   4. Postel, J., "Internet Protocol", RFC-791, Information Sciences
-      Institute, University of Southern California, Marina del Rey,
-      September 1981.
-
-   5. Postel, J., "Address Mappings", RFC-796, Information Sciences
-      Institute, University of Southern California, Marina del Rey,
-      September 1981.
-
-   6. Postel, J., "Domain Name System Implementation Schedule", RFC-921,
-      Information Sciences Institute, University of Southern California,
-      Marina del Rey, October 1984.
-
-   7. Reynolds, J. and Postel, J., "Assigned Numbers", RFC-943,
-      Information Sciences Institute, University of Southern California,
-      Marina del Rey, April 1985.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Harrenstien & Stahl & Feinler                                   [Page 6]
-